I’m using KDE 4.1rc on my i586 laptop, and wanted to install it on my x86_64 desktop. Unfortunately, the x86_64 repository does not seem to be as well maintained as the i586 and there are numerous missing dependencies when using the DEFAULT 1-click file. I noticed the files seem to be somewhat older than the i586 equivalents.
Is this normal for the x86_64 repos? Is is difficult to test x86_64?
Thanks
The 11.1alpha1 LiveCDs are dated the same
Both repos range 18 to 24 July.
Give them a day or so & they should be fine:)
There is usually a simple work thru on dependancy issues, just check carefully what they are and the options available. You could always post them here. Yast enables you to save the issues to a file which you can then copy here.
I’ll keep an eye on it and retry. The repositories were revised overnight, but the issue list is even longer. Today, it’s trying to install some i586 kde 4.1 packages, and thus require i586 packages that conflict with already installed x86_64 packages.
Thanks for the conflict list tip. Unfortunately it is far too long (32k) to post.
That’s odd. I use x86_64 and the only dependency issue I got while updating within the past few days was ktorrent needing an older version of kde4-base or something. My repos include KDE4:Factory: Desktop, KDE4:Factory:Community and KDE4:Factory:Extra-Apps - not sure if that makes a difference.
Index of /repositories/KDE:/KDE4:/Community/openSUSE_11.0_KDE4_Factory_Desktop
Index of /repositories/KDE:/KDE4:/Factory:/Desktop/openSUSE_11.0
Index of /repositories/KDE:/KDE4:/Factory:/Extra-Apps/openSUSE_11.0
these are the 3 repo’s for 4.1
check what you have, disable any others different to these.
The list may look long but it’s probably easier than you think
A tip is to use the option upgrade all unconditionally
click cancel and do the same in the next repo and the next, though you may not have any marked in one of them.
Then check again
If you still have errors. Just eread carefully what it says, there is usually an indication as to where the issue lies.
Anyway, you can try some options and see how it responds, sometimes that helps you see things better. Nothing actuall gets done at this point. So you can always just exit and discard changes, and try again.
I’m not near the machine now but I think the root problem was kdepimlibs in x86_64 is at version 12.8 and in i586 was at 12.9. For some reason the 12.8 build wasn’t acceptable and it tried to go with the i586 version. There were other issues, but those looked fixable.
caf4926 wrote:
>
> ‘Index of
> /repositories/KDE:/KDE4:/Community/openSUSE_11.0_KDE4_Factory_Desktop’
> (http://tinyurl.com/65tbsr)
> ‘Index of /repositories/KDE:/KDE4:/Factory:/Desktop/openSUSE_11.0’
> (http://tinyurl.com/5mxwaf)
> ‘Index of /repositories/KDE:/KDE4:/Factory:/Extra-Apps/openSUSE_11.0’
> (http://tinyurl.com/5t7aof)
>
> these are the 3 repo’s for 4.1
>
> check what you have, disable any others different to these.
>
> The list may look long but it’s probably easier than you think
>
> A tip is to use the option upgrade all unconditionally
> click cancel and do the same in the next repo and the next, though you
> may not have any marked in one of them.
>
> Then check again
>
> If you still have errors. Just eread carefully what it says, there is
> usually an indication as to where the issue lies.
> Anyway, you can try some options and see how it responds, sometimes
> that helps you see things better. Nothing actuall gets done at this
> point. So you can always just exit and discard changes, and try again.
>
>
who came up with the naming convention for “community” - it’s counter intuitive to the rest of the repos, is this the new standard?
–
Suse 11.0 x64, Kde 4.1beta (factory repo), Opera 9.x weekly
who came up with the naming convention for “community” - it’s counter intuitive to the rest of the repos, is this the new standard?
Good question. It did cause some mixed up penguins last week when it changed!
I was able to install KDE 4.1 tonight by manually adding individual packages from YaST. Everything seems to work properly, some nice fixes over the rc.
The 1-click installer is still broken; it reported numerous conflicts and missing dependencies (some of which made no sense).
I was using the correct repositories.
It’s an automated build-system, so it has nothing to do with one arch being better supported than the other.
The openSUSE build service is brilliant, but the one drawback is that if a package fails to build, it doesn’t prevent other packages from being built. So you wind up with dependency errors.
The other issue is that there are still some dependency conflicts with the original KDE 4.0 packages included in 11.0, in that if a package is missing (or failed to build) from the build-service for KDE 4.1, Yast will try to resolve using the existing 4.0 packages, which generally leads to heartbreak.
For instance, I ran into a case where ktorrent was installed for KDE 4.0 by default, but they changed the package name for KDE 4.1, which results in a slew of dependency errors when updating, and Yast attempts to downgrade. It’s nothing more than a burp that will eventually be addressed.
But as a rule of thumb, when Yast recommends deleting 100+ packages, it’s best not to permit it. Just click “do not install xxx” that is causing the error. This often happens when you see a package “requiring kde4-xxx < 4.0.60” or some such thing. It means that Yast is picking up the package from the base repositories, which it shouldn’t be doing for 4.1.
Just my 2c…
Cheers,
KV
KV is spot on.
So just be aware that you are venturing in to possible complications. It’s always wise to keep a rock steady backup desktop to fall back on. I have kde3. Although I use build service repos for kde3, it is such a stable system- it never seems to fail.
kde4.1 on the other hand is very new. Packages have been shunted around a bit too. It will all settle down in time.
You might still find some packages installed from 4.0.4 build service which are newer than those provided in the 4.1 factory repo - they will show RED in Yast - software management
You can safely update to roll them back
There are no failing packages for x86_64 or any other architecture. the issue seems to be an Zypp resolver bug for 11.0/x86_64.
In the current KDE:KDE4:Factory build is the version number same for both architectures so the buggy resolver will not suggest an architecture switch because he thinks “higher version is better”.