Created attachment 395522 [details]
system logs

Created attachment 395524 [details]
pkmon output

Here is 'pkmon --verbose' output when I did exactly what is seen on the video (tried to update anaconda package).

Also I would like to note that when I try to update all the packages, the gpk-update-viewer just waits indefinitely, I have to press Quit.

Any progress on this?

Still a problem in desktop-x86_64-20100222.19.iso.

I'm seeing this to after a fresh install of F-13-Alpha-RC2 using a newly created user account.

No packages are listed when searching or selecting package groups in gpk-application.  I manually started 'pkmon --verbose' from a terminal window, and then gpk-application appears to show packages.

Could it be that pkmon crashed or failed to start?

This is fixed in gnome-packagekit and PackageKit Working their way through testing now.

(In reply to comment #6)
> This is fixed in gnome-packagekit and PackageKit Working their way through
> testing now.    

Still seeing problems testing after a fresh default install of F-13-Alpha-RC4-{i386,x86_64}.

This bug is in MODIFIED, yet there is no indication what version it's fixed in.  Hard to tell if the correct fix is included in RC4.

I can confirm the bug as well in RC4-i386

Oddly enough when I install F13 on real hardware I get the changelog/update information showing up, but the installation portion still fails...

I've retested on bare metal (i386 and x86_64), and after install ... I am able to login and apply software updates without error.

(In reply to comment #10)
> I've retested on bare metal (i386 and x86_64), and after install ... I am able
> to login and apply software updates without error.    

Correction, it says "Updates installed", but gnome-packagekit hasn't done anything.  It shows the same updates available when restarting, and yum check-update lists the same updates still.

PackageKit-0.6.2-0.1.20100225git.fc13.x86_64
gnome-packagekit-2.29.4-0.2.20100211git.fc13.x86_64

Created attachment 396676 [details]
pkmon --verbose

This is okay for me, I installed RC4 from the desktop live spin into an x86-64 virt-manager VM. Ran the update application. It correctly displayed all updates, with changelogs, and installed them. It then correctly showed that no more updates were available, when run again.

I just tried on RC4 inside KVM virtual x86-64 machine (installed, not live-cd) and the bug described above does not exhibit. The changelogs are correctly shown, and once the update is installed, it's not proposed to me any more.

As of today, on installed F13 Alpha RC 4 it shows changelogs and I also managed to install a single update just fine. However, when I tried to install all available updates, it again reported "All updates were installed." when nothing really happened.

I believe the problem may be connected to the current state of repository (sometime it works, sometime it doesn't). For example as of today the dependencies are broken for gimp and for openoffice.org. It may be relevant to gpk-update-viewer behaviour.

Created attachment 397099 [details]
yum update log

So I tried to upload all packages, and the beahaviour is the same as Kamil describes in #15. GUI tool says "All updates installed" but nothing really happens.

When I run yum-update, it ends with broken dependencies (log attached).

I belive, that gpk-update-viewer just is not able to digest this kind of faulty yum-update, so it says everything was installed, even though it was not.

sry guys - s/upload all packages/update all packages/ in #16

I have tested this thoroughly and I am absolutely positive that the problem happens only when gpk-update-viewer tries to update a package with broken dependencies. All other packages are updated just fine, but if in the set is a package with broken dependencies, then it almost immediately reports "Updates were installed." and quits (without installing anything). Case solved. (Now only to fix the problem).

I would  agree with the above assessment. I wasn't sure what I had done to fix my problem but I did run a yum update manually and removed open office that had problems and then was able to update the system later.. I didn't put 2 and 2 together because lots happened between the removal of open office and a second attempt at updating the system...

Is it as simple as that it's no longer doing the equivalent of --skip-broken by default? PK has always done this in the past (in contrast to yum).

I've just started seeing this issue, after having two days of successful updates with PK yesterday and the day before, so definitely some transience to this issue.

I think I can confirm Kamil's diagnosis. I did a 'yum upgrade' (well, actually 'yum --disableabunchofrepos upgrade' because Fusion still isn't working for F13, but hey) and it complained about kipi-plugins. So I removed that package, verified that 'yum upgrade' didn't complain any more and would have gone ahead, then ran the PK updater. Now it's working properly (in the middle of downloading packages ATM, didn't go that far before). So I believe Kamil's right: it doesn't work right if there's any dependency problems in the update set. It doesn't appear to do --skip-broken , and it obviously doesn't report the result correctly (it doesn't tell you there was a dependency problem and it couldn't do the update, it just claims it did the update).

Also the yum-langpacks plugin may be part of the problem. See bug #569352.

Today I have again seen gpk-update-viewer not displaying changelogs. After I have installed a single update it started to work.
Also for some reason I was able to apply all available updates via gpk-update-viewer, even though yum was showing me broken dependencies (??).

Weirder and weirder every day.

Moving back into ASSIGNED until we have a better understanding about the nature of the problem and where attempts to resolve the issue have been made.  

I've contacted Richard Hughes on #fedora-devel to see if has any insight into getting to the root of this problem.  Richard, is there information QA can provide to help isolate this failure?

(In reply to comment #24)
> Richard, is there information QA can
> provide to help isolate this failure?    

Does this bug ever happen if the yum-langpacks plugin is not installed?

yum-langpacks is in Group package 'Base' under 'Base system' Category at software selection step of anaconda. 

Today I installed RC4-i386 with yum-langpacks installed by default. To narrow down the cause, when I executed gpk-update-viewer, I only installed openoffice packages which were supposed to have problems. But actually they got installed successfully without this issue happening. After installation, the package list in GUI is updated automatically and doesn't contain openoffice any more. Openoffice packages have been updated (view by 'rpm -qa') and when I 'yum update' again, there are no broken dependencies and everything seems right...

Created attachment 397546 [details]
system logs when langpack plugin installed

Wow, my test result may get this issue more complicated... I installed RC4-i386 with yum-langpacks by default. This time I selected all updates to be installed. It took ages to download the packages and then asked me for authentication. After that, it shows "updates were installed" quickly without really updating. When I click ok, "segmentation fault" shown on console. Then I restarted gpk-update-viewer. But it's grey and nothing was displayed in the forms. 

So I rebooted pc and started gpk-update-viewer. I didn't do anything before this but it was able to update all packages without error.

/var/log/ is attached.

Same result for me now.  This problem is certainly a fun one :(

1. I installed a default Fedora-13-Alpha-RC4-x86_64 system (which includes yum-langpacks).  
2. After install, I created a new local user in firstboot
3. Login as new local user
4. Run gpk-update-viewer, and attempt to update

As expected, I was prompted for priv. escalation and the update proceeded as intended.  I think kparal was accurate in stating the this bug seems to be triggered by some condition present in the repos, which may be related to, or contributed by, yum-langpacks.

I'll continue attempting to retest this issue.  For now, I think we should begin documenting this behavior for any Alpha users.  Suggested workarounds include:

1. Removing yum-langpacks ?
2. Or, using yum from the command-line ?

(In reply to comment #28)
> Suggested workarounds include:

1. Removing yum-langpacks
2. Include http://lists.baseurl.org/pipermail/yum-devel/2010-March/006695.html in yum-utils f13-stable
3. Ensuring the repos do not have depsolve problems

Richard.

> 2. Include http://lists.baseurl.org/pipermail/yum-devel/2010-March/006695.html
> in yum-utils f13-stable

yum, not yum-utils :)

Prepared a CommonBugs entry attempting to explain the problem and suggested work arounds at https://fedoraproject.org/wiki/Common_F13_bugs#yum-langpacks

Moving to F13Beta per discussion at F-13-Alpha Readiness meeting.  For details, please see meeting minutes (http://meetbot.fedoraproject.org/fedora-meeting/2010-03-04/f-13-alpha-eng-readiness.2010-03-04-01.00.html).

A fix was ACK'd by skvidal and is in the yum 3.2.x tree:

http://yum.baseurl.org/gitweb?p=yum.git;a=commit;h=359ae828b915101116bb57fbe2645eae056c158b

I'm hitting this bug today without yum-langpacks installed at all :(

the current update set as reported by yum is http://fpaste.org/XNEw/ .

If I try to install updates via gnome-packagekit, I get the 'quickly reports all updates installed, nothing is actually done' symptom.

[root@adam Download]# rpm -qa | grep yum
yum-utils-1.1.26-1.fc13.noarch
PackageKit-yum-0.6.2-0.1.20100225git.fc13.x86_64
yum-presto-0.6.2-1.fc13.noarch
yum-3.2.26-4.fc13.noarch
yum-plugin-fastestmirror-1.1.26-1.fc13.noarch
anaconda-yum-plugins-1.0-5.fc12.noarch
PackageKit-yum-plugin-0.6.2-0.1.20100225git.fc13.x86_64
yum-metadata-parser-1.1.4-1.fc13.x86_64
yum-plugin-auto-update-debug-info-1.1.26-1.fc13.noarch

[root@adam Download]# rpm -qa | grep -i packagekit
gnome-packagekit-2.29.4-0.2.20100211git.fc13.x86_64
PackageKit-yum-0.6.2-0.1.20100225git.fc13.x86_64
PackageKit-0.6.2-0.1.20100225git.fc13.x86_64
PackageKit-device-rebind-0.6.2-0.1.20100225git.fc13.x86_64
PackageKit-debuginfo-0.6.2-0.1.20100225git.fc13.x86_64
PackageKit-qt-0.6.2-0.1.20100225git.fc13.x86_64
PackageKit-gstreamer-plugin-0.6.2-0.1.20100225git.fc13.x86_64
PackageKit-command-not-found-0.6.2-0.1.20100225git.fc13.x86_64
PackageKit-yum-plugin-0.6.2-0.1.20100225git.fc13.x86_64
PackageKit-glib-0.6.2-0.1.20100225git.fc13.x86_64
PackageKit-gtk-module-0.6.2-0.1.20100225git.fc13.x86_64
PackageKit-debug-install-0.6.2-0.1.20100225git.fc13.x86_64



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Updating to match latest experience. AFAICT, this happens whenever there is any dependency issue in the pending update set. PK is supposed to do the equivalent of yum --skip-broken to avoid this, but this doesn't appear to be working. When you hit this bug, yum --skip-broken can install the updates, but gpk-update-viewer runs, completes very quickly and claims the update was completed, without actually updating any package.

This is a Beta blocker as it actually matches an Alpha criterion, we only did not consider it an Alpha blocker as we incorrectly thought yum-langpacks had to be installed to trigger it.

Richard pushed an update he thought should fix this - gnome-packagekit-2.29.92-0.1.20100315git.fc13.x86_64 . However, with that installed (and packagekitd and gpk-update-icon restarted), I am seeing this problem again with today's update set.

Even more oddly, this time yum isn't showing any kind of dependency problem; I wouldn't have to use --skip-broken to complete the update, it seems.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Richard, your remote login to my system should still be available if you want to take a look, poke me on IRC if you need any privileges.

for the record, here's the list of updates at present:

 bodhi-client                     noarch 0.7.4-1.fc13    updates-testing   16 k
 cheese                           x86_64 2.29.92-2.fc13  updates-testing  430 k
 cheese-libs                      x86_64 2.29.92-2.fc13  updates-testing  4.1 M
 dosfstools                       x86_64 3.0.9-2.fc13    updates-testing   77 k
 dvb-apps                         x86_64 1.1.1-21.fc13   updates-testing  257 k
 ghostscript                      x86_64 8.71-9.fc13     updates-testing  4.5 M
 ghostscript-cups                 x86_64 8.71-9.fc13     updates-testing   44 k
 gnome-disk-utility               x86_64 2.30.0-1.fc13   updates-testing  273 k
 gnome-disk-utility-libs          x86_64 2.30.0-1.fc13   updates-testing  1.0 M
 gnome-disk-utility-ui-libs       x86_64 2.30.0-1.fc13   updates-testing  103 k
 gnome-icon-theme                 noarch 2.29.2-2.fc13   updates-testing  8.0 M
 libarchive                       x86_64 2.8.3-1.fc13    updates-testing  127 k
 libssh                           x86_64 0.4.2-1.fc13    updates-testing  105 k
 nautilus-sendto                  x86_64 2.28.3-1.fc13   updates-testing  163 k
 openldap                         x86_64 2.4.21-5.fc13   updates-testing  231 k
 openldap-clients                 x86_64 2.4.21-5.fc13   updates-testing  155 k
 openldap-devel                   x86_64 2.4.21-5.fc13   updates-testing  1.0 M
 phonon                           x86_64 4.4.0-1.fc13    updates-testing  155 k
 phonon-backend-xine              x86_64 4.4.0-1.fc13    updates-testing  156 k
 phonon-devel                     x86_64 4.4.0-1.fc13    updates-testing   69 k
 system-config-network            noarch 1.6.0-2.fc13    updates-testing  320 k
 system-config-network-tui        noarch 1.6.0-2.fc13    updates-testing  1.2 M
 udisks                           x86_64 1.0.0-1.fc13    updates-testing  172 k
 udisks-devel                     x86_64 1.0.0-1.fc13    updates-testing   68 k
 wxPython                         x86_64 2.8.10.1-2.fc13 updates-testing  8.5 M



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Adam, could you try this build please: http://koji.fedoraproject.org/koji/taskinfo?taskID=2069483 -- thanks.

unfortunately f13 rolled on since then, and I had an update set of 54 packages today which installed successfully with the old PackageKit - but only after failing once and then listing '108' updates, which were the same 54 updates listed twice. Running the update process a second time with gpk-update-viewer in that odd state seemed to work.

Anyway, I'll install that build and let you know if I see any problems with it, at least.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Hitting the bug again with today's update set :(. yum sees a dependency issue. gpk-update-viewer does the classic behaviour from above - runs through dep checks then jumps straight to 'All updates were installed successfully' without downloading or installing anything. yum output will be attached. hughsie, your login to my system is still valid.

Created attachment 402329 [details]
yum's interpretation of the troublesome update set

actually, I still seem to be running old PackageKit (not the build hughsie mentioned above), even though I was sure I updated it yesterday. That makes this a good test: I'll install the updated PackageKit stuff, and reboot and try again.

PackageKit-yum-plugin-0.6.2-1.fc13.x86_64
PackageKit-0.6.2-1.fc13.x86_64
PackageKit-command-not-found-0.6.2-1.fc13.x86_64
PackageKit-device-rebind-0.6.2-1.fc13.x86_64
PackageKit-debuginfo-0.6.2-1.fc13.x86_64
PackageKit-gstreamer-plugin-0.6.2-1.fc13.x86_64
PackageKit-glib-0.6.2-1.fc13.x86_64
PackageKit-yum-0.6.2-1.fc13.x86_64
PackageKit-debug-install-0.6.2-1.fc13.x86_64
PackageKit-qt-0.6.2-1.fc13.x86_64
PackageKit-gtk-module-0.6.2-1.fc13.x86_64
gnome-packagekit-2.29.92-0.1.20100315git.fc13.x86_64

looking good with the new PK - it's downloading packages, didn't do that before. will update if it completes.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

With the new PK, the update does run. The list of available packages goes quite wiggy during the process, though - half-way through, every update in the list is duplicated. When the update process completes, the 'A restart is required.' dialog pops up, but appears to be broken - you can't click anything. On further investigation, it turns out this is because another error dialog is blocking it, but is *behind* it: it has no window title and the text 'Could not get update details (newline) No results were returned.', and a Close button. There are two of these, I think. Closing both takes you back to the gpk-update-viewer window, which by now is saying 'There are 94 updates available' in bold at the top and '188 update selected' in the bottom right, and showing each one of 94 updates twice (for a total of 188). Even though all the updates have been installed. Quitting and restarting correctly shows just one update, the one which has the dependency issue and so wasn't installed.

So it more or less works, but it's rough :)

Preparing for blocker review tomorrow - I've been using the above PK build for a couple of days without issues other than those described above. Despite the roughness, this is certainly better than without the fixes. I think we should pull this build in for Beta if no-one else has problems with it.

We may also need yum 3.2.27-2...changelog is '- broke searching in PK, this patch fixes it.'



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Setting to ON_QA, there is a build going into updates-testing.

I do have the same problem！
Fedora 13

I'm happy with closing this once the newer PackageKit is in dist-f13, it's been working okay here. Anyone object?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

okay, no-one objected. clsoing.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers