Hey, so we just tested our transition fedora-release package and trying to get new updates with a new key installed, and we're running into a traceback.
PackageKit-0.2.4-6.fc9.x86_64 is the package version
http://togami.com/~warren/fedora/fedora-release-9-3.transitiontest1.noarch.r... is the fedora-release package to install to get info about the new repo and new keys
http://fpaste.org/paste/5778 is the output of what happens when warren tries to install updates from the new location.
Any ideas?
Jesse Keating wrote:
Hey, so we just tested our transition fedora-release package and trying to get new updates with a new key installed, and we're running into a traceback.
PackageKit-0.2.4-6.fc9.x86_64 is the package version
http://togami.com/~warren/fedora/fedora-release-9-3.transitiontest1.noarch.r... is the fedora-release package to install to get info about the new repo and new keys
http://fpaste.org/paste/5778 is the output of what happens when warren tries to install updates from the new location.
Any ideas?
To give you an idea about the severity of this problem.
We cannot push any Fedora Updates until PK is fixed. If we push this fedora-release before PK is fixed, then GUI users will forever fail, requiring command line intervention to recover. We cannot subsequently push a fixed PK, because their old PK will crash here when attempting to update other packages in addition to the fixed PK.
PackageKit-0.2.4-4.fc9 Fedora 9 Updates
PK seems to be crashing here after it downloads packages, at the point where yum would ask if you want to install a new GPG key.
Oh damn. DrNick is reporting that his F9 PackageKit is asking him if he wants to import a key, but it seems to be stuck in a loop asking repeatedly for the same package. His next attempt got past that point to a PolicyKit dialog, then back into the fail loop.
PackageKit in F9 updates seems to be extremely broken. =(
Alternative Ugly Hack ===================== We are already very late in pushing updates, and there exists uncertainty about how long it would take to fix PK, and there are inherent risks in upgrading PK so hastily. So here is an alternative horrible hack that would allow us to push updates immediately.
fedora-release (transition package only) %post runs a script that forks itself into the background. That script waits for rpmdb to unlock, then imports the new key silently. Then the upgrade goes smoothly for all users no matter what version of PK they have.
fedora-release (new repo) This package removes the %post hack.
Assuming we can make this import safely, then we can have the oldrepos on the mirrors entirely empty, except for the transitional fedora-release package. This ugly hack has the benefit of being a lot simpler and easier to understand. The only trick is figuring out how the script can know when it is safe to import.
Which path should we take?
Warren Togami wtogami@redhat.com
On Sat, Sep 6, 2008 at 12:42 AM, Warren Togami wtogami@redhat.com wrote:
We cannot push any Fedora Updates until PK is fixed.
I built PackageKit and gnome-packagekit 0.3.1 for F-9 and it was able to import the new key and update my system. I'll leave it up to y'all whether it's a good idea to update PackageKit to 0.3.1 in F-9 to get the GPG key import working.
Jeffrey Ollie wrote:
On Sat, Sep 6, 2008 at 12:42 AM, Warren Togami wtogami@redhat.com wrote:
We cannot push any Fedora Updates until PK is fixed.
I built PackageKit and gnome-packagekit 0.3.1 for F-9 and it was able to import the new key and update my system. I'll leave it up to y'all whether it's a good idea to update PackageKit to 0.3.1 in F-9 to get the GPG key import working.
The key question is: What is the greater risk?
1) Upgrade PackageKit and trust that it works. Keep in mind that this key import function is really poorly tested at this point.
2) Write some horrible hack so fedora-release imports the new key itself after %post when rpmdb is unlocked.
Warren Togami wtogami@redhat.com
On Sat, 2008-09-06 at 03:21 -0400, Warren Togami wrote:
- Upgrade PackageKit and trust that it works. Keep in mind that this
key import function is really poorly tested at this point.
Right, the third option is to patch PackageKit so it hardcodes the new key and explains to the user why the key is being shown and that it's probably safe to agree. It won't be translated tho.
Richard.
On Sat, 2008-09-06 at 02:00 -0500, Jeffrey Ollie wrote:
I built PackageKit and gnome-packagekit 0.3.1 for F-9 and it was able to import the new key and update my system. I'll leave it up to y'all whether it's a good idea to update PackageKit to 0.3.1 in F-9 to get the GPG key import working.
The key import code isn't any different in 0.2.4-4 as 0.3.x -- so I'm slightly confused why one would work and not the other.
Richard.
On Fri, 2008-09-05 at 21:49 -0700, Jesse Keating wrote:
Hey, so we just tested our transition fedora-release package and trying to get new updates with a new key installed, and we're running into a traceback.
PackageKit-0.2.4-6.fc9.x86_64 is the package version
http://togami.com/~warren/fedora/fedora-release-9-3.transitiontest1.noarch.r... is the fedora-release package to install to get info about the new repo and new keys
http://fpaste.org/paste/5778 is the output of what happens when warren tries to install updates from the new location.
I've just tried this with a F9 install CD:
1. boot CD 2. yum update PackageKit 3. install fedora-release-9-3.transitiontest1.noarch.rpm 4. go to gpk-update-viewer 5. get key dialog with correct information 6. click okay 7. goto 5
Not cool. Looking at the output from /usr/sbin/packagekitd --verbose I can see it's trying to execute install-signature.py, which doesn't exist. I'm slightly confused why, as it existed in 0.1.x. I've released 0.2.5 upstream this morning, as it incorporated all 7 patches from the PackageKit-0.2.4-7 release, plus a few other trivial bugs from upstream. This is building as:
http://koji.fedoraproject.org/koji/taskinfo?taskID=810207 and http://koji.fedoraproject.org/koji/taskinfo?taskID=810221
8. install Packagekit-0.2.5-1 and gnome-packagekit-0.2.5-1 9. click okay 10. key is imported 11. update continues
I really can't reproduce that backtrace -- but I think I can work out what's happening. The 0.1.x versions of PackageKit didn't treat the finderprint return value as a function, but the 0.2.x version did (and the 0.2.x and 0.3.x code works). This leads me to come to the conclusion that you might have been running the old version of PackageKit (0.1.x or 0.2.4-3?), not the new version.
Could you please retry your tests with the 0.2.5-1 versions please?
Richard.
Richard Hughes wrote:
http://koji.fedoraproject.org/koji/taskinfo?taskID=810207 and http://koji.fedoraproject.org/koji/taskinfo?taskID=810221
- install Packagekit-0.2.5-1 and gnome-packagekit-0.2.5-1
- click okay
- key is imported
- update continues
Could you please retry your tests with the 0.2.5-1 versions please?
I tested PackageKit-0.2.5 and gnome-packagekit on two i386 F9 systems. It seems to DTRT.
Anybody have a F9 x86_64 system to test this on? This really should be verified.
Assuming this new PackageKit is good, then our next steps are: 1) Build final fedora-release packages for F8 and F9. This appears to be identical to the packages I built previously for testing, since no errors were discovered. 2) Sign this new fedora-release, PackageKit and gnome-packagekit with oldkey. 3) Erase everything in oldrepo updates for F8. Put new fedora-release there and createrepo. 4) Erase everything in oldrepo updates for F9. Put new fedora-release, PackageKit and gnome-packagekit there and createrepo. 5) Erase oldrepo contents of F8 and F9 updates-testing and create empty metadata there. 6) Send out announcement. 7) Push to mirrors.
Anyone see anything missing?
Warren Togami wtogami@redhat.com
Warren Togami wrote:
Richard Hughes wrote:
http://koji.fedoraproject.org/koji/taskinfo?taskID=810207 and http://koji.fedoraproject.org/koji/taskinfo?taskID=810221
- install Packagekit-0.2.5-1 and gnome-packagekit-0.2.5-1
- click okay
- key is imported
- update continues
Could you please retry your tests with the 0.2.5-1 versions please?
I tested PackageKit-0.2.5 and gnome-packagekit on two i386 F9 systems. It seems to DTRT.
Anybody have a F9 x86_64 system to test this on? This really should be verified.
Assuming this new PackageKit is good, then our next steps are:
- Build final fedora-release packages for F8 and F9. This appears to
be identical to the packages I built previously for testing, since no errors were discovered. 2) Sign this new fedora-release, PackageKit and gnome-packagekit with oldkey. 3) Erase everything in oldrepo updates for F8. Put new fedora-release there and createrepo. 4) Erase everything in oldrepo updates for F9. Put new fedora-release, PackageKit and gnome-packagekit there and createrepo. 5) Erase oldrepo contents of F8 and F9 updates-testing and create empty metadata there. 6) Send out announcement. 7) Push to mirrors.
Anyone see anything missing?
I tested this in the following scenarios: * i386 F9 + oldrepo updates on two systems. * x86_64 F9 + oldrepo updates.
Can anybody test this on F9 ppc, or F9 i386/x86_64 after a fresh GA install without updates?
Warren Togami wtogami@redhat.com
On Mon, 2008-09-08 at 11:36 -0400, Warren Togami wrote:
I tested this in the following scenarios:
- i386 F9 + oldrepo updates on two systems.
- x86_64 F9 + oldrepo updates.
Can anybody test this on F9 ppc, or F9 i386/x86_64 after a fresh GA install without updates?
I've got F9 (GA) installing on x86_64 and ppc64 right now. I'll let you know how it turns out.
-w
On Mon, 2008-09-08 at 11:36 -0400, Warren Togami wrote:
Can anybody test this on F9 ppc, or F9 i386/x86_64 after a fresh GA install without updates?
I'm testing on F9 i386 fresh install. I'll try PPC F9 once I can download an iso, unless somebody gets to it first.
rel-eng@lists.fedoraproject.org