Created attachment 1014686 [details] journalctl of boot with affected update Description of problem: An offline-update failed to update libphodav-2.0-1.fc22.x86_64 which is obsoleting libphodav-1.0-0.4-5.fc22.x86_64. When this happens no update is installed. So it basicly blocks offline updates when there is some obsoleting update. Offline updates worked fine after I updated libphodav (the only obsoleting package in that update) with dnf and then performed offline update. output from journalctl with update information: pk-offline-update[867]: percentage 9% pk-offline-update[867]: percentage 10% pk-offline-update[867]: percentage 14% pk-offline-update[867]: sent msg to plymouth 'Installing Updates - 14%' pk-offline-update[867]: status request pk-offline-update[867]: percentage 15% pk-offline-update[867]: sent msg to plymouth 'Installing Updates - 15%' pk-offline-update[867]: percentage 17% pk-offline-update[867]: sent msg to plymouth 'Installing Updates - 17%' pk-offline-update[867]: status test-commit pk-offline-update[867]: status finished PackageKit[878]: update-packages transaction /6_dccdacdc from uid 0 finished with failed after 5282ms pk-offline-update[867]: writing failed results pk-offline-update[867]: failed to update system: Error running transaction: package libphodav-2.0-1.fc22.x86_64 is obsoleted by libphodav-2.0-1.fc22.x86_64 pk-offline-update[867]: rebooting pk-offline-update[867]: sent mode to plymouth 'shutdown' pk-offline-update[867]: sent msg to plymouth 'Rebooting after installing updates…' part of dnf history info last: Obsoleting libphodav-2.0-1.fc22.x86_64 @updates-testing Install libphodav-2.0-1.fc22.x86_64 @updates-testing Obsoleted libphodav-1.0-0.4-5.fc22.x86_64 (unknown) Version-Release number of selected component (if applicable): PackageKit-1.0.6-1.fc22.x86_64 How reproducible: always when updating obsoleting package Additional info: I propose this as beta blocker because it violates beta criterion: "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." But I vote -1 for Beta blocker +1 Final blocker because other updates work fine. Just small amount of updates will be affected and I don't think it is worth of blocking beta for this problem.
I'm really confused why libphodav obsoletes itself.
I can reproduce this easily. Just install F22 Beta RC2 Workstation and force and offline update. It fails with the error message above. (In reply to Petr Schindler from comment #0) > But I vote -1 for Beta blocker +1 Final blocker because other updates work > fine. Just small amount of updates will be affected and I don't think it is > worth of blocking beta for this problem. Petr wanted to say here that this will rarely happen. But unfortunately, it happened for Beta RC2. libphodav-1.0-0.4-5.fc22.x86_64 is baked into that image. And it means that users won't be available to update *at all*, unless packagekit is fixed *on the media* or libphodav-2.0-1.fc22.x86_64 is unpushed. So this seems to be an direct criterion violation. Note: F22 stable: libphodav-0.4-5.fc22 Beta RC2: libphodav-1.0-0.4-5.fc22 F22 updates-testing: libphodav-2.0-1.fc22 Two things - RC2 contains a non-stable package for some reason, and it's *name* is different (libphodav-1.0 is the name, 0.4 is the version). I guess that's why they obsolete it, because it happened to be a typo (version part of the name)?
It isn't Obsolete'ing itself here, though that is sometimes a valid use-case for changing subpackages. The case here, is the package *names* being Obsoletes:'d were libphodav-1.0 and libphodav-2.0 (arguably bad, and probably should have been caught during initial review). In particular, the Obsoletes in question are: Obsoletes: libphodav-2.0 <= 0:2.0-3 Obsoletes: libphodav2 <= 0:2.0-4 # no Provides for this one as ABI was broken Obsoletes: libphodav-1.0 <= 0:0.4-6 See also bug #1195913 on a little of the related history.
I think the update error can be worked around for now by fixing the Obsoletes in libphodav, so that it doesn't do self-obsoletes. This should hopefully make the packagekit offline updates work properly post-beta. Something like (untested): Obsoletes: libphodav2 <= 0:2.0-4 ==> Obsoletes: libphodav2 < 0:2.0-4 But for the final release, I think the packagekit offline updates needs a bit of love to make sure it properly handles obsoletes. From my poking around in the code today, this isn't entirely trivial, and I'd rather fix this post-beta where we have time to properly test the changes.
Kalev: well, that paste is from the master branch. So far as I can see, the F22 branch has only: %package -n libphodav Obsoletes: libphodav-1.0 <= 0:0.4-6 %package -n libphodav-devel Obsoletes: libphodav-1.0-devel <= 0:0.4-6 Those are the only two Obsoletes: lines in the spec. So, not sure what's going on, but it seems weird.
So still don't know what's going on here, but some more info: 22 Beta RC2 Workstation live has only one phodav-related package installed: libphodav-1.0-0.4-5.fc22. Note that this is *not* a 'non-stable package' as #c2 suggests. It is not version 1.0-0.4-5 of the package 'libphodav', but version 0.4-5 of the package 'libphodav-1.0', which is a sub-package of 'phodav': that is, it comes from the source package phodav-0.4-5.fc22, which is the current stable version. It is installed because spice-glib-0.27-5.fc22 and spice-gtk3-0.27-5.fc22 require it: [root@localhost liveuser]# rpm -q --requires spice-glib spice-gtk3 | grep pho libphodav-1.0.so.0()(64bit) libphodav-1.0.so.0(LIBPHODAV1_0.0)(64bit) libphodav-1.0.so.0()(64bit) [root@localhost liveuser]# rpm -q --whatprovides "libphodav-1.0.so.0()(64bit)" libphodav-1.0-0.4-5.fc22.x86_64 [root@localhost liveuser]# rpm -q --whatprovides "libphodav-1.0.so.0(LIBPHODAV1_0.0)(64bit)" libphodav-1.0-0.4-5.fc22.x86_64 When you try and do an update, I believe the trigger for the issue is that spice-glib and spice-gtk3 get updated. The relevant update is: https://admin.fedoraproject.org/updates/FEDORA-2015-5433/phodav-2.0-1.fc22,spice-gtk-0.28-2.fc22 Note that the package libphodav-2.0-1.fc22 is *not* directly an update for the package libphodav-1.0-0.4-5.fc22. Instead, it's the dependencies of the spice-gtk subpackages that change (this paste is from my desktop, which has already done the update with dnf): [adamw@adam tmp]$ rpm -q spice-gtk3 spice-glib spice-gtk3-0.28-2.fc22.x86_64 spice-glib-0.28-2.fc22.x86_64 [adamw@adam tmp]$ rpm -q --requires spice-gtk3 | grep pho libphodav-2.0.so.0()(64bit) [adamw@adam tmp]$ rpm -q --requires spice-glib | grep pho libphodav-2.0.so.0()(64bit) libphodav-2.0.so.0(LIBPHODAV1_0.0)(64bit) [adamw@adam tmp]$ rpm -q --whatprovides "libphodav-2.0.so.0()(64bit)" libphodav-2.0-1.fc22.x86_64 [adamw@adam tmp]$ rpm -q --whatprovides "libphodav-2.0.so.0(LIBPHODAV1_0.0)(64bit)" libphodav-2.0-1.fc22.x86_64 So the update should have libphodav-2.0-1.fc22 added to it to satisfy the dependencies of spice-gtk3 and spice-glib. As for the obsoletes, the spec file, koji, and rpm all agree that libphodav-2.0-1.fc22 obsoletes only one thing: [adamw@adam tmp]$ rpm -qp --obsoletes libphodav-2.0-1.fc22.x86_64.rpm libphodav-1.0 <= 0:0.4-6 So it is reasonable that the update transaction should install libphodav-2.0-1.fc22 and remove (as obsoleted, and no longer required by anything) libphodav-1.0-0.4-5.fc22 . I cannot find anything funky or overlapping in the Provides or Obsoletes of the two libphodav(-1.0) packages. libphodav-2.0-1.fc22 doesn't provide the thing it's obsoleting, libphodav-1.0 does not provide anything libphodav-2.0-1.fc22 provides, nothing like that. All the metadata looks pretty clean. I cannot find anything other than libphodav-2.0-1.fc22 from http://koji.fedoraproject.org/koji/buildinfo?buildID=625644 which has the apparent name 'libphodav-2.0-1.fc22' or would otherwise be involved in this; I wondered for a bit if we had a rogue 'libphodav-2.0' package lying around somewhere, but I can't find such a thing in F22. The 22 'stable' repo has phodav 0.4-5 in it, the 'updates-testing' remove has phodav 2.0-1.fc22 in it, that's all. [adamw@adam tmp]$ rpm -qp --obsoletes libphodav-2.0-1.fc22.x86_64.rpm libphodav-1.0 <= 0:0.4-6 [adamw@adam tmp]$ rpm -qp --provides libphodav-1.0-0.4-5.fc22.x86_64.rpm libphodav-1.0 = 0.4-5.fc22 libphodav-1.0(x86-64) = 0.4-5.fc22 libphodav-1.0.so.0()(64bit) libphodav-1.0.so.0(LIBPHODAV1_0.0)(64bit) [adamw@adam tmp]$ rpm -qp --obsoletes libphodav-1.0-0.4-5.fc22.x86_64.rpm [adamw@adam tmp]$ rpm -qp --requires libphodav-1.0-0.4-5.fc22.x86_64.rpm /sbin/ldconfig /sbin/ldconfig libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libgio-2.0.so.0()(64bit) libglib-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libpthread.so.0()(64bit) libsoup-2.4.so.1()(64bit) libxml2.so.2()(64bit) libxml2.so.2(LIBXML2_2.4.30)(64bit) libxml2.so.2(LIBXML2_2.6.0)(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) rpmlib(PayloadIsXz) <= 5.2-1 [adamw@adam tmp]$ rpm -qp --provides libphodav-2.0-1.fc22.x86_64.rpm libphodav = 2.0-1.fc22 libphodav(x86-64) = 2.0-1.fc22 libphodav-2.0.so.0()(64bit) libphodav-2.0.so.0(LIBPHODAV1_0.0)(64bit) [adamw@adam tmp]$ rpm -qp --obsoletes libphodav-2.0-1.fc22.x86_64.rpm libphodav-1.0 <= 0:0.4-6 [adamw@adam tmp]$ rpm -qp --requires libphodav-2.0-1.fc22.x86_64.rpm /sbin/ldconfig /sbin/ldconfig libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libgio-2.0.so.0()(64bit) libglib-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libpthread.so.0()(64bit) libsoup-2.4.so.1()(64bit) libxml2.so.2()(64bit) libxml2.so.2(LIBXML2_2.4.30)(64bit) libxml2.so.2(LIBXML2_2.6.0)(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 rtld(GNU_HASH)
Kalev notes: <kalev> adamw: re your last comment, one thing that sticks out there is the 0: epoch <kalev> I wonder if it's possible that this is messing something up? rpm -qp --obsoletes libphodav-2.0-1.fc22.x86_64.rpm libphodav-1.0 <= 0:0.4-6 <kalev> usually this is done without epoch, I believe i.e. the line should be: Obsoletes: libphodav-1.0 <= 0.4-6 I'm going to test this theory out.
That theory doesn't work unfortunately: I built a 2.0-1.1.fc22 with the Obsoletes: line changed, added it to a side repo, and tried an update, it still fails in the same way. I also confirmed that both yum and dnf work correctly. 'dnf update spice-gtk3': Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: libphodav x86_64 2.0-1.1.fc22 phodav 47 k replacing libphodav-1.0.x86_64 0.4-5.fc22 Upgrading: spice-glib x86_64 0.28-2.fc22 updates-testing 359 k spice-gtk3 x86_64 0.28-2.fc22 updates-testing 57 k Transaction Summary ================================================================================ Install 1 Package Upgrade 2 Packages 'yum update spice-gtk3': Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: libphodav x86_64 2.0-1.1.fc22 phodav 47 k replacing libphodav-1.0.x86_64 0.4-5.fc22 Updating: spice-gtk3 x86_64 0.28-2.fc22 updates-testing 57 k Updating for dependencies: spice-glib x86_64 0.28-2.fc22 updates-testing 359 k Transaction Summary ================================================================================ Install 1 Package Upgrade 1 Package (+1 Dependent package)
OK, I've got to the bottom of the problem now. It turned out to be an actual issue in the PackageKit stack after all. Unsure why it only came up now and not before -- could be that rpm in F22 is doing more checks for the transaction check compared to what the F21 rpm was doing.
libhif-0.2.0-2.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libhif-0.2.0-2.fc22
I'm +1 blocker on this, we've considered the 'graphical updates at Beta' criterion multiple times and accepted it. I was willing to consider various bits of chicanery we could do to try and resolve this without a respin, but they all seem to have issues, and Kalev's fix works for me, so I vote we do an RC3 with the fix.
sadly I am +1 also, while it has an easy workaround, many users are likely to go oh the updater is broken.
+1 blocker here as well.
:( +1 blocker
That's 4 +1s, marking as AcceptedBlocker. I'm just running some further tests on the update before requesting an RC3. Kalev says: <kalev> adamw: a small wrinkle is that the new libhif build doesn't work with the PackageKit that's in stable adamw: would be good to pull in PackageKit from https://admin.fedoraproject.org/updates/FEDORA-2015-5882 if you're taking libhif 0.2.0 but I tested with a clean Beta RC2 install and the updated libhif alone gave a successful offline update. I'm doing some further tests and trying to clarify with kalev now.
I have tested with RC2 + libhif-0.1.8-8.fc22, which should be included in RC3, and the offline update worked correctly. Waiting for someone to test with clean RC3 as well.
I tested this with RC3, offline updates worked as expected, system was updated.
libhif-0.1.8-8.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.