Help testing a bugfix: is your update applet slow? (11.4/Factory)

If the updates applet is taking a while to find the updates, and then thinks a lot before starting the install, please help me test this patch.

https://bugzilla.novell.com/show_bug.cgi?id=679650

For 11.4 you can add this repository Index of /repositories/home:/dmacvicar:/branches:/openSUSE:/11.4:/Update/standard
and dup against it.

For GNOME 3.0 there is a repository that builds on top of GNOME 3.0 + 11.4 and also another one for pure Factory (do not add this url directly, but browse for one of the subfolders):

Index of /repositories/home:/dmacvicar:/branches:/GNOME:/Factory

a zypper dup --from this repository should upgrade your packagekit.

Before testing make sure of doing “killall packagekitd” as root.

The effects, if you have lot of repos should be the applet taking around 20 seconds to display the updates instead of several minutes (until the mouse cursor is not busy anymore).

Please leave any feedback in the bug itself or here.

Happy testing.

Has this something to do with PackageKit? And does the above install a new version of it? Then please be aware that the general advise here is not to use PackageKit at all. Thus I guess you should tell what errors are addressed in that new version. (And may be some explanation why we should use it at all, I e.g., am very satisfied with YaST/zypper).

It is a bug in the glue that makes PackageKit talk to ZYpp.

If you prefer to use zypper/YaST that is fine, but remember PackageKit frontends give an easy way to apply updates without being root and being desktop aware (battery, network). Not every user is a sysadmin.

And not less important. Consider that advice (avoiding PackageKit) something personal or popular in the forum, but it is in no case an official recommendation. At least not from the ZYpp developers.

And, yes, that help request was targeted at people using the desktop updaters.

It is a bug in the glue that makes PackageKit talk to ZYpp.

If you prefer to use zypper/YaST that is fine, but remember PackageKit frontends give an easy way to apply updates without being root and being desktop aware (battery, network). Not every user is a sysadmin.

And not less important. Consider that advice (avoiding PackageKit) something personal or popular in the forum, but it is in no case an official recommendation. At least not from the ZYpp developers.

And, yes, that help request was targeted at people using the desktop updaters.

On 07/27/2011 10:56 AM, dmacvicar wrote:
>
> Consider that advice (avoiding PackageKit)
> something personal or popular in the forum, but it is in no case an
> official recommendation.

i think the advice in the forum was because packagedkit didn’t work as
expected…

i hope your repairs pan out, and we can (those who wish) can return to
packagekit alerting us to needed updates, and then do them…if we want
them…

tell me please, will the package kit offered in this thread for testing
present a different list of updates available when compared to that of
YaST Online Updater (as did the one i removed some months back)?

[gotta run…maybe i install and test/answer myself this afternoon…]


DD
Caveat-Hardware-Software
openSUSE®, the “German Engineered Automobiles” of operating systems!

The first thing I found out about the KPackageKit applet is that it warned me about newer version available in all the repos I have enabled and not only about the Security/Recommended updates ones in the Update repo, which I consider a regression. Then when I tried to find out how to configure it, it showed all those repos and gave me the possibility not to look at those that I did not want to look at. At least that is what I thought. Then when I unchecked those, it asked me for the root password! I didn’t type that of course. There should be no need to be root to stop looking at repo contents. After further investigation I found out that it wanted to disable those repos instead off simply not look at what happens there. I was very glad I did not allow it to bork my repo list. I deinstalled KPackageKit and now check mannualy for the Security updates with YaST > Software > Online update instead of the earlier applet.

But that is all a bit off topic. I only wanted to warn you that PackageKit hasn’t a good reputation here (being this “officialy” or not) and that when you want people to test it, you should probably anounce more improvements then speed alone, because it borked several people’s system. And I doubt that those people want to test if PackageKit can now bork their system faster.

The fact that it shows also package updates was requested by many users, and it was kind of expected another bunch will complain. This is why it is configurable and was discussed here.

Go to /etc/PackageKit/ZYpp.conf and set:

[Updates] 
HidePackages=true

I also have to say that KPackageKit is still a bit immature compared to the GNOME counterpart, but it is getting better.

Apart of some bugs, PackageKit based tools are using ZYpp internally so the rest should produce the same results.

Duncan

It will also show package updates if you have custom repositories like packman, which you may turn off (see my reply below about HidePackages). I pushed for showing only maintenance updates, but we have too many users using lot of repositories who wanted to see newer packages.

On the other hand, it is just calling ZYpp internally.

If you see problems with the tool, please open bugs so that we can find patterns among users and trace those bugs down.

Duncan

I am afraid we are getting further and further away from your original quest to find volunteers for testing a newer faster version.

I repeat I only wanted to point out to you that you might get more volunteers if your new version (also) addresses the problems people have in using the product. All in the interest of the testing you want.

It was not my intention to make this thread a discussion about the value of the product and it’s value against the products we were used to when this product replaced it without almost any warning about it not doing the same things by default. Thus I will try to stop this discussion here (can be continued in a thread where those problems were the subject or in a new one), to give you a change to get your testing people.