Re: F12 updates-testing issue: X flickers and fails to start
On Wed, 2009-12-09 at 12:20 -0700, Linuxguy123 wrote: On Wed, 2009-12-09 at 18:36 +0100, Kevin Kofler wrote: Linuxguy123 wrote: I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 Huh? One of these is a Nouveau bug, the other is a bug in the proprietary nvidia driver, both of them already happened with F12 as released, so these have absolutely nothing to do with this thread. That is what you say. How exactly did you determine that ? OR are you guessing ? The fact that it only broke for the reporter with an update from three days ago, but you had those problems in September and October. Seems pretty clear. It's not even the same problem description. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Wed, 9 Dec 2009 11:12:07 +0200 (EET) Pekka Savola wrote: Now gdm login however doesn't show my username and fingerprint login is no longer an option Looks like the issue with hal-0.5.14-1: https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12840 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Wed, 2009-12-09 at 10:36 +0100, Michal Schmidt wrote: On Wed, 9 Dec 2009 11:12:07 +0200 (EET) Pekka Savola wrote: Now gdm login however doesn't show my username and fingerprint login is no longer an option Looks like the issue with hal-0.5.14-1: https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12840 I think it has something to do with display power management and the monitor brightness level. I can replicate the behavior by simply adjusting the display brightness in a KDE session. I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Wed, 2009-12-09 at 06:27 -0700, Linuxguy123 wrote: On Wed, 2009-12-09 at 10:36 +0100, Michal Schmidt wrote: On Wed, 9 Dec 2009 11:12:07 +0200 (EET) Pekka Savola wrote: Now gdm login however doesn't show my username and fingerprint login is no longer an option Looks like the issue with hal-0.5.14-1: https://admin.fedoraproject.org/updates/F12/FEDORA-2009-12840 I think it has something to do with display power management and the monitor brightness level. I can replicate the behavior by simply adjusting the display brightness in a KDE session. I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 I recommend connecting an external monitor to see if the issue is display specific and have you tried ctrl-alt-F6 to get to a console at login and then going back to the X session with ctrl-alt-F1 ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
Linuxguy123 wrote: I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 Huh? One of these is a Nouveau bug, the other is a bug in the proprietary nvidia driver, both of them already happened with F12 as released, so these have absolutely nothing to do with this thread. These bugs filed by Rex Dieter about issues caused by HAL 0.5.14 are probably more relevant: https://bugzilla.redhat.com/show_bug.cgi?id=545258 https://bugzilla.redhat.com/show_bug.cgi?id=545639 Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Wed, 2009-12-09 at 18:36 +0100, Kevin Kofler wrote: Linuxguy123 wrote: I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 Huh? One of these is a Nouveau bug, the other is a bug in the proprietary nvidia driver, both of them already happened with F12 as released, so these have absolutely nothing to do with this thread. That is what you say. How exactly did you determine that ? OR are you guessing ? I say they have similar symptoms. I said they *might* be related. I bet my bugs have nothing to do with the nouveau or nvidia drivers. I've been saying that all along. I guess we will find out. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
F12 updates-testing issue: X flickers and fails to start
Hi, On my laptop, after F12 updates-testing update today, after reboot F logo shows but then the screen goes dark and starts flickering between various shades of dark (changing modes?) with intel graphics chipset (GM965/GL960). I'm only using 1024x768 resolution. Nomodeset or using a previous kernel didn't help. Booting to runlevel 3 and running system-config-display (--reconfig) resulted in the same. I've worked around the issue by yum history undo 1 which rolled back a couple of hundred packages. Any idea which package could be the culprit and I should file a bug against or to isolate it? Somehow I don't think this is necessarily an Xorg base or driver issue. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Tue, 2009-12-08 at 10:33 +0200, Pekka Savola wrote: Hi, On my laptop, after F12 updates-testing update today, after reboot F logo shows but then the screen goes dark and starts flickering between various shades of dark (changing modes?) with intel graphics chipset (GM965/GL960). I'm only using 1024x768 resolution. Nomodeset or using a previous kernel didn't help. Booting to runlevel 3 and running system-config-display (--reconfig) resulted in the same. I've worked around the issue by yum history undo 1 which rolled back a couple of hundred packages. Any idea which package could be the culprit and I should file a bug against or to isolate it? Somehow I don't think this is necessarily an Xorg base or driver issue. I'd start with xorg-x11-drv-intel. Update to the package set that caused the problem, then for the bug report attach the output of 'dmesg', your entire /var/log/Xorg.0.log file, and the output of 'lspci -nv'. Also indicate your kernel version, the version of xorg-x11-server-Xorg, and the version of xorg-x11-drv-intel. Dan -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Tue, 2009-12-08 at 01:50 -0800, Dan Williams wrote: On Tue, 2009-12-08 at 10:33 +0200, Pekka Savola wrote: Hi, On my laptop, after F12 updates-testing update today, after reboot F logo shows but then the screen goes dark and starts flickering between various shades of dark (changing modes?) with intel graphics chipset (GM965/GL960). I'm only using 1024x768 resolution. Nomodeset or using a previous kernel didn't help. Booting to runlevel 3 and running system-config-display (--reconfig) resulted in the same. I've worked around the issue by yum history undo 1 which rolled back a couple of hundred packages. Any idea which package could be the culprit and I should file a bug against or to isolate it? Somehow I don't think this is necessarily an Xorg base or driver issue. I'd start with xorg-x11-drv-intel. Update to the package set that caused the problem, then for the bug report attach the output of 'dmesg', your entire /var/log/Xorg.0.log file, and the output of 'lspci -nv'. Also indicate your kernel version, the version of xorg-x11-server-Xorg, and the version of xorg-x11-drv-intel. kernel is probably first up nowadays to blame for GPU bugs. File bugs against the X drivers generally though is easier for us to find them, kernel bug triage can be a long process. Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies with Fedora 11 updates-testing - 2009-11-11
On 11/12/2009 01:05 AM, Michael Schwendt wrote: The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: tremulous-1.1.0-8.fc11.i586 from fedora-11-i386 unresolved deps: libopenal.so.0 --- Seriously, can the openal maintainer please stop breaking the ABI in updates? This isn't the first time. Is there a real necessity to do so? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies with Fedora 11 updates-testing - 2009-11-11
Am 11.11.2009 21:16, schrieb Rahul Sundaram: On 11/12/2009 01:05 AM, Michael Schwendt wrote: The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: tremulous-1.1.0-8.fc11.i586 from fedora-11-i386 unresolved deps: libopenal.so.0 --- Seriously, can the openal maintainer please stop breaking the ABI in updates? This isn't the first time. Is there a real necessity to do so? Rahul I have forgoten that for F-11 some changes are needed in the spec file. I have fixed it and the new package is on the way. Sorry for the problems. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies with Fedora 11 updates-testing - 2009-11-11
On Wed, 11 Nov 2009 21:52:50 +0100, LinuxDonald wrote: Am 11.11.2009 21:16, schrieb Rahul Sundaram: On 11/12/2009 01:05 AM, Michael Schwendt wrote: The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: tremulous-1.1.0-8.fc11.i586 from fedora-11-i386 unresolved deps: libopenal.so.0 --- Seriously, can the openal maintainer please stop breaking the ABI in updates? This isn't the first time. Is there a real necessity to do so? Rahul I have forgoten that for F-11 some changes are needed in the spec file. I have fixed it and the new package is on the way. Sorry for the problems. Did you notice that the package still upgrades the library SONAME from libopenal.so.0 to libopenal.so.1? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies with Fedora 11 updates-testing - 2009-11-11
On Thu, Nov 12, 2009 at 01:46:44AM +0530, Rahul Sundaram wrote: On 11/12/2009 01:05 AM, Michael Schwendt wrote: The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: tremulous-1.1.0-8.fc11.i586 from fedora-11-i386 unresolved deps: libopenal.so.0 --- Seriously, can the openal maintainer please stop breaking the ABI in updates? This isn't the first time. Is there a real necessity to do so? Can someone give me a definitive answer on whether or not I need to rebuild tremulous and tremfusion with the new ABI? I'm willing to, I just need the confusion to go away. -- Ian Weller i...@ianweller.org Why, a four-year-old could understand this report. Find me a four-year-old child. I can't make head or tail out of it. -- Groucho Marx, Duck Soup pgpZalmmUgz8E.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies with Fedora 11 updates-testing - 2009-11-11
On Wed, 11 Nov 2009 15:36:38 -0600, Ian wrote:
Can someone give me a definitive answer on whether or not I need to
rebuild tremulous and tremfusion with the new ABI? I'm willing to, I
just need the confusion to go away.
No need to.
This was just the separate openal-soft package that is supposed to be
parallel-installable with the older openal instead of obsoleting it.
I've mentioned in the bodhi ticket that the packager could evaluate
%{fedora} in the spec file to avoid the error that has happened.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies with Fedora 11 updates-testing - 2009-11-11
Am 11.11.2009 22:39, schrieb Michael Schwendt:
On Wed, 11 Nov 2009 15:36:38 -0600, Ian wrote:
Can someone give me a definitive answer on whether or not I need to
rebuild tremulous and tremfusion with the new ABI? I'm willing to, I
just need the confusion to go away.
No need to.
This was just the separate openal-soft package that is supposed to be
parallel-installable with the older openal instead of obsoleting it.
I've mentioned in the bodhi ticket that the packager could evaluate
%{fedora} in the spec file to avoid the error that has happened.
It was my wrong on the Spec file for fedora 11.
I have created an new packaged that don't make any problems and it's
installable with openal.
Sorry for that :(
@Tremulos you not need rebuild it for fedora 11 you have rebuild that
game allready for f12 and that is okay :)
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies with Fedora 11 updates-testing - 2009-11-06
Michael Schwendt píše v Pá 06. 11. 2009 v 09:49 +: The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: qlandkartegt-0.16.0-1.fc11.i586 from fedora-updates-testing-11-i386 unresolved deps: libQMKToolBox.so libSerialPort.so package: qlandkartegt-0.16.0-1.fc11.ppc from fedora-updates-testing-11-ppc unresolved deps: libQMKToolBox.so libSerialPort.so package: qlandkartegt-0.16.0-1.fc11.ppc64 from fedora-updates-testing-11-ppc64 unresolved deps: libQMKToolBox.so()(64bit) libSerialPort.so()(64bit) package: qlandkartegt-0.16.0-1.fc11.x86_64 from fedora-updates-testing-11-x86_64 unresolved deps: libQMKToolBox.so()(64bit) libSerialPort.so()(64bit) Can someone help me to find out where these libraries are coming from? My repoqueries were unsuccessful. The qlandkartegt build is http://koji.fedoraproject.org/koji/buildinfo?buildID=138829 Thanks Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
Hi. On Thu, 15 Oct 2009 19:17:13 +0200, Jochen Schmitt wrote Yes, but you should make the dump with the dump utility of the new release to which you want to update. So version x.y+1 is unable to read a dump created by version x.y? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On Sat, Oct 17, 2009 at 14:16:13 +0200, Ralf Ertzinger fed...@camperquake.de wrote: Hi. On Thu, 15 Oct 2009 19:17:13 +0200, Jochen Schmitt wrote Yes, but you should make the dump with the dump utility of the new release to which you want to update. So version x.y+1 is unable to read a dump created by version x.y? They can read them, but sometimes there are new features and you can take advantage of them better during the dump. So that when you do the load into the new version, it will end up getting done better. I don't have a for sure example off hand, but I seem to remember that this was a good idea when schemas got added. Another possibility was that at some point dependency handling during dumps was improved (probably more than once) and that these additions were not backported to every version someone might have been using. Doing the dump with the later version might have saved you some hand tweaking of the table definitions (particularly when tables referenced each other) at some upgrade points. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Thu, Oct 15, 2009 at 10:51:20 -0500, chasd ch...@silveroaks.com wrote: Bruno Wolff III wrote: Postgres isn't even updatable. You need to do dumps before doing the upgrade. OK, maybe that isn't a good example then. However, using your comment, and turning my idea around, if PostgreSQL isn't upgradable, according to my idea it should be excluded by default in yum.conf to protect people from hosing their data during an upgrade. That doesn't make a lot of sense. I must not be thinking particularly well, so ignore me. Well I think that it is controlled by the packager. In a released Fedora version, you are only going to get bug fix updates, which don't have that issue. You do need to be careful doing upgrades because the base postgres version can change between Fedora versions. (You also need to be extra careful if you care about postgres while running rawhide.) After you have upgraded postgres it is too late to use the old data (though people are working on improvements on that front). So you need to be sure to do the dump before the upgrade. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On Thu, Oct 15, 2009 at 19:17:13 +0200, Jochen Schmitt joc...@herr-schmitt.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.10.2009 17:51, schrieb chasd: Postgres isn't even updatable. You need to do dumps before doing the upgrade. Yes, but you should make the dump with the dump utility of the new release to which you want to update. Yeah, but that's even harder in Fedora (because you need the new dump utility but the old server) and depending on what's changed may not buy you anything. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
Bruno Wolff III br...@wolff.to writes: Postgres isn't even updatable. You need to do dumps before doing the upgrade. So downgrades aren't too much worse than upgrades. (Though the new dumps might use new features that will need to get modified to make them readable by old versions.) Note that there is experimental support for in-place upgrades in PostgreSQL 8.4. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Updates-testing (was: Re: thunderbird upgrade - wtf?)
Charles Dostale wrote: MySQL and PostgreSQL come to mind. /etc/yum.conf might have nodowngrade=mysql-server postgresql- server in the default file. Seth Vidal wrote: I have no idea what that would do? just tell the user tough noogies? packagename can't be downgraded because of file format changes Essentially, yes, tough noogies. The alternative is for the downgrade to execute, and even tougher noogies. I guess the decision is which set of noogies is tougher, or more acceptable. I thought that if there were known corner cases where a downgrade was really, really a bad idea, yum could keep someone from shooting themselves in the foot. Maybe the current behavior that doesn't attempt to protect against known failures is better. -- Charles Dostale -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
Bruno Wolff III wrote: Postgres isn't even updatable. You need to do dumps before doing the upgrade. OK, maybe that isn't a good example then. However, using your comment, and turning my idea around, if PostgreSQL isn't upgradable, according to my idea it should be excluded by default in yum.conf to protect people from hosing their data during an upgrade. That doesn't make a lot of sense. I must not be thinking particularly well, so ignore me. -- Charles Dostale -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.10.2009 17:51, schrieb chasd: Postgres isn't even updatable. You need to do dumps before doing the upgrade. Yes, but you should make the dump with the dump utility of the new release to which you want to update. Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAkrXWQUACgkQZLAIBz9lVu/5HQP+INo/h8BFMrJ9IuQOqhXQEIUn nTcuB/W4qg7E+rlTt0Ljk5bWOBo4qpEJuxojdP0LXicPawADRlJSuZlEa13rDIPl oAxdZlPpbehSJBKvrCsS6PugFHIJ4uW+hIX6jexH15+2Gzw+QaO2khxbZoZw0B9Y lB8hfNl5731p00m4z08= =VKM0 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Updates-testing (was: Re: thunderbird upgrade - wtf?)
On 14/10/09 15:31, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? For me, there is a bit of a problem with updates-testing: the machine I work on is my primary desktop, and I'm extremely wary of getting myself into a situation I can't easily get out of. Now, you might argue that avoiding u-t is essentially avoiding the inevitable (and Tbird 3 has shown me that, so I agree), but it is riskier. What would sell me totally on u-t was if there was something where I can roll back bad packages. I'm pretty sure there are various obscure technical reasons why rolling back isn't possible in 100% of cases, but I don't think that's necessary. So long as it's in the high 90%s then it's good enough, and to be honest I would want to avoid testing updates I can't revert like the plague anyway: not being able to roll back to my mind is a good indicator of not being suitable for a stable release. In my ideal world, PackageKit would update my stuff with testing updates, and anything which broke could be reverted back to some previous date or something - either by package if I can identify it, or by actual last-known-good date. I'm sure that's a tonne of work, but that's the only way I can see the testing system making sense for people who rely on their Fedora desktop. Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 15:31, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? For me, there is a bit of a problem with updates-testing: the machine I work on is my primary desktop, and I'm extremely wary of getting myself into a situation I can't easily get out of. Now, you might argue that avoiding u-t is essentially avoiding the inevitable (and Tbird 3 has shown me that, so I agree), but it is riskier. What would sell me totally on u-t was if there was something where I can roll back bad packages. I'm pretty sure there are various obscure technical reasons why rolling back isn't possible in 100% of cases, but I don't think that's necessary. So long as it's in the high 90%s then it's good enough, and to be honest I would want to avoid testing updates I can't revert like the plague anyway: not being able to roll back to my mind is a good indicator of not being suitable for a stable release. In my ideal world, PackageKit would update my stuff with testing updates, and anything which broke could be reverted back to some previous date or something - either by package if I can identify it, or by actual last-known-good date. I'm sure that's a tonne of work, but that's the only way I can see the testing system making sense for people who rely on their Fedora desktop. yum downgrade pkgname it works fine for the simple-ish cases. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 15:31, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? For me, there is a bit of a problem with updates-testing: the machine I work on is my primary desktop, and I'm extremely wary of getting myself into a situation I can't easily get out of. Now, you might argue that avoiding u-t is essentially avoiding the inevitable (and Tbird 3 has shown me that, so I agree), but it is riskier. What would sell me totally on u-t was if there was something where I can roll back bad packages. I've suggested this very thing in a F-A-B thread this week. We, packagers, have no way to fix a mistake and very few things preventing us from making them: https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html -Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, Mike McGrath wrote: I've suggested this very thing in a F-A-B thread this week. We, packagers, have no way to fix a mistake and very few things preventing us from making them: https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html Seriously: yum downgrade and in F12 - try out things like the history undo options. there are lots of potential nasty situations that can happen but I think the general consensus was 'screw it, let the user sort it out if it breaks, which it often does not' generally, if the app you updated modifies its data format and cannot revert it then the user is SOL - but that's not _THAT_ common and when it does happen it's certainly not yum's fault. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On 14/10/09 16:49, Mike McGrath wrote: I've suggested this very thing in a F-A-B thread this week. We, packagers, have no way to fix a mistake and very few things preventing us from making them: https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html I love this! I would say having an experimental repo wouldn't be as good as having per-app repos: for me, there are apps I care about and want to test, and others I use infrequently and couldn't contribute much to. However, if on the other hand there was some way of marking out which packages I wanted to pull from experimental (or updates-testing for that matter), then well and good. I think experimental is needed, though. Some apps really need longer baking before getting into Fedora proper: Tbird 3 for me is an excellent example, although probably for the maintainer one which is much more obvious in hindsight. The change in mission makes a huge amount of sense (being usable, if not bug-free, has to be a top priority in my mind). For my money, a great proposal though, thanks. Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Personally, though, I would think that if that is a feature we're advertising then it should be policy that either a. package maintainers strive to ensure their packages are mainly downgradable (certainly within a stable release) or b. the packages are marked as don't downgrade me and yum/whatever issues the appropriate expletive when you try to do that. I would say again that any package update which cannot be downgraded would be one I would think hard about releasing into a stable Fedora. Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) That's pretty amusing considering PK cannot do much of anything on fedora w/o yum. It can't even fetch repodata. Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Then file an RFE with the PK folks. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Even with downgrade, that's a user action. If the user happens to know about it they'll be ok. I'm more interested in what options a packager has to fix problems like this. -Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On Wed, 14 Oct 2009, Mike McGrath wrote: On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Even with downgrade, that's a user action. If the user happens to know about it they'll be ok. I'm more interested in what options a packager has to fix problems like this. The packager can issue a new pkg which is the old pkg with a bumped epoch. then the user will get that in the next update. this is one of the reasons why epochs exist, ultimately. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On 10/14/2009 09:56 PM, Seth Vidal wrote: On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) That's pretty amusing considering PK cannot do much of anything on fedora w/o yum. It can't even fetch repodata. IIRC the wording has been fixed to not classify yum as legacy in recent PackageKit versions. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
What about using LVM to store a pre-update snapshot of your distro? (Separate root partition from /home and other stuff, of course. Roll back root). Highly inconvenient, but it would theoretically work... On Wed, Oct 14, 2009 at 11:54 AM, Seth Vidal skvi...@fedoraproject.org wrote: On Wed, 14 Oct 2009, Mike McGrath wrote: I've suggested this very thing in a F-A-B thread this week. We, packagers, have no way to fix a mistake and very few things preventing us from making them: https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html Seriously: yum downgrade and in F12 - try out things like the history undo options. there are lots of potential nasty situations that can happen but I think the general consensus was 'screw it, let the user sort it out if it breaks, which it often does not' generally, if the app you updated modifies its data format and cannot revert it then the user is SOL - but that's not _THAT_ common and when it does happen it's certainly not yum's fault. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, Jud Craft wrote: What about using LVM to store a pre-update snapshot of your distro? (Separate root partition from /home and other stuff, of course. Roll back root). Highly inconvenient, but it would theoretically work... It doesn't really help you when your data is modified by the update. example: installed: foo-1.0 data format: user:group:data:index:key update: foo-1.2 data is migrated forward from the old format to the new one, new format is stored in the same file but is: user:group,group,group,group:data:data:data:index (obviously I'm just making up the data format :) how do you roll back and not lose access to the data in that file? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On 10/14/2009 05:47 PM, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. Is there a thunderbird-2.0 package for F11? For me, all thunderbird-3.*'s in FC11 were simply too bugged to be usable (The UI changes are not an issue for me - for me, TB3 is simply too bugged to be usable). I already considered to add FC10's or CentOS's TB to a local repository and to look into ways to blacklist TB3 in yum. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On Wed, 14 Oct 2009, Ralf Corsepius wrote: On 10/14/2009 05:47 PM, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. Is there a thunderbird-2.0 package for F11? For me, all thunderbird-3.*'s in FC11 were simply too bugged to be usable (The UI changes are not an issue for me - for me, TB3 is simply too bugged to be usable). I already considered to add FC10's or CentOS's TB to a local repository and to look into ways to blacklist TB3 in yum. easy to blacklist it in yum add: exclude=thunderbird\* to fedora, updates and updates-testing repos. that should keep it out. might be some deps there too - I haven't looked closely. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On Wed, 2009-10-14 at 11:30 -0500, Mike McGrath wrote: On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Even with downgrade, that's a user action. If the user happens to know about it they'll be ok. I'm more interested in what options a packager has to fix problems like this. -Mike In this specific case, issue a bumped build of thunderbird with the UI settings defaulted to what they were before the change. New code, old UI. In the general case this could also be done, or a package could be reverted to older code, but with an epoch to ensure package ordering. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 2009-10-14 at 10:49 -0500, Mike McGrath wrote: have no way to fix a mistake That is complete bullshit. You have many ways to fix mistakes. Newer builds with patches, reverted code with epoch, newer upstream release to fix the mistake upstream, etc.. To say that there is no way to fix a mistake is insulting. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, Oct 14, 2009 at 1:08 PM, Jesse Keating wrote: Newer builds with patches, reverted code with epoch, newer upstream release to fix the mistake upstream, etc.. To say that there is no way to fix a mistake is insulting. I'd like to logic-link here with the following... On Wed, Oct 14, 2009 at 12:57 PM, Seth Vidal wrote: It doesn't really help you when your data is modified by the update. So if my LVM snapshot and revert entire Fedora installed idea is dismissed as still not perfect, why is just revert one package pushed as a legitimate alternative? They both suffer from the same problem -- new packages may cause changes in data that are not reversibly compatible with the old package, and mere package rollback is not useful. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, Oct 14, 2009 at 1:11 PM, Jud Craft wrote: They both suffer from the same problem -- new packages may cause changes in data that are not reversibly compatible with the old package, and mere package rollback is not useful. Of course, I imagine that any rollback system that doesn't involve user data will have the same problem, theoretically. That includes any backup system that treats system programs separate from user data, when in fact one DOES change the other. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, Oct 14, 2009 at 1:13 PM, Seth Vidal wrote: There's no perfect. we're just going for 'good enough', really. Ah, so package-rollback is shipped as the halfway-effective crutch, but it's so easy to implement we might as well offer it anyway solution. Or, the excellent implementation of an incomplete solution. [No offense to the infrastructure design of yum, just stating the obvious here.] On the side, I store all of my user data and documents separate from my own actual home partition, and with every install I just wipe the home, and then re-link my documents and data to it. This scheme works decently (application-specific schemas and configs that are subject to irreversible change are discarded and recreated). But it's a pain to compensate for an inconvenient reality (that I must continually reinstall my distribution as a Fedora user, and I'm tired of having to migrate user data, where even residual /home directories leave rot). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, Jud Craft wrote: On Wed, Oct 14, 2009 at 1:13 PM, Seth Vidal wrote: There's no perfect. we're just going for 'good enough', really. Ah, so package-rollback is shipped as the halfway-effective crutch, but it's so easy to implement we might as well offer it anyway solution. actually it is shipped as an easy win for simple update-is-broken-and-downgrading-is-painless cases which we run into all the time. Your suggestion of having an lvm snapshot is absolutely appropriate for those too - it just requires more thinking ahead of time when the system is being setup which a lot of users are not going to do. Or, the excellent implementation of an incomplete solution. [No offense to the infrastructure design of yum, just stating the obvious here.] There's no complete solution, really. We'd have to know an enormous amount about each update and what data it modifies to completely solve the problem and we just don't have that info and I doubt we could reasonably compile it for EVERY package we maintain. So we implement a reasonable partial solution and deal with the edge cases as they come. On the side, I store all of my user data and documents separate from my own actual home partition, and with every install I just wipe the home, and then re-link my documents and data to it. good choice. That's good planning. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
Le Mer 14 octobre 2009 19:11, Jud Craft a écrit : So if my LVM snapshot and revert entire Fedora installed idea is dismissed as still not perfect, why is just revert one package pushed as a legitimate alternative? Revert one package won't eat the data created while you used the new problem version. That's the problem with full-FS images: they do not distinguish between the different kinds of files. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On 10/14/2009 10:06 AM, Jesse Keating wrote: On Wed, 2009-10-14 at 11:30 -0500, Mike McGrath wrote: On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Even with downgrade, that's a user action. If the user happens to know about it they'll be ok. I'm more interested in what options a packager has to fix problems like this. -Mike In this specific case, issue a bumped build of thunderbird with the UI settings defaulted to what they were before the change. New code, old UI. Right. The defaults have been tweaked in https://admin.fedoraproject.org/updates/thunderbird-3.0-2.8.b4.fc11 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
Seth Vidal wrote: Seriously: yum downgrade and in F12 - try out things like the history undo options. there are lots of potential nasty situations that can happen but I think the general consensus was 'screw it, let the user sort it out if it breaks, which it often does not' generally, if the app you updated modifies its data format and cannot revert it then the user is SOL - but that's not _THAT_ common and when it does happen it's certainly not yum's fault. If it isn't that common, could yum have added directives to its configuration ( similar to exclude= ) ? This could increase the reliability of yum downgrade in the eyes of those that use it. MySQL and PostgreSQL come to mind. /etc/yum.conf might have nodowngrade=mysql-server postgresql-server in the default file. That's easier than carrying that info in the package or repo files. When additional packages are found to be not downgradable, they can be added to the list. Granted, if there are a lot of packages, that gets unwieldy. Also, it could break a downgrade transaction. -- Charles Dostale -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, chasd wrote: Seth Vidal wrote: Seriously: yum downgrade and in F12 - try out things like the history undo options. there are lots of potential nasty situations that can happen but I think the general consensus was 'screw it, let the user sort it out if it breaks, which it often does not' generally, if the app you updated modifies its data format and cannot revert it then the user is SOL - but that's not _THAT_ common and when it does happen it's certainly not yum's fault. If it isn't that common, could yum have added directives to its configuration ( similar to exclude= ) ? This could increase the reliability of yum downgrade in the eyes of those that use it. MySQL and PostgreSQL come to mind. /etc/yum.conf might have nodowngrade=mysql-server postgresql-server in the default file. That's easier than carrying that info in the package or repo files. When additional packages are found to be not downgradable, they can be added to the list. Granted, if there are a lot of packages, that gets unwieldy. Also, it could break a downgrade transaction. I have no idea what that would do? just tell the user tough noogies? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, Oct 14, 2009 at 13:55:13 -0500, chasd ch...@silveroaks.com wrote: MySQL and PostgreSQL come to mind. Postgres isn't even updatable. You need to do dumps before doing the upgrade. So downgrades aren't too much worse than upgrades. (Though the new dumps might use new features that will need to get modified to make them readable by old versions.) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Signing server? (Re: Updates testing for F-11)
Am Freitag, den 12.06.2009, 08:48 -0700 schrieb Toshio Kuratomi: On 06/12/2009 08:14 AM, Christoph Wickert wrote: Am Freitag, den 12.06.2009, 05:34 +0200 schrieb Kevin Kofler: I don't see what it buys our users if they get one big update over 2 small ones. In most cases the biggest part (consuming time and cpu cycles) of the updates is not installing them but everything else like checking for new packages, downloading the metadata, This portion of the list is saved. This part happens in the background without user's notice, so this portion irrelevant. calculating dependencies, downloading the packages and running the transaction test. Especially for small updates this takes much more time than the actual rpm -U part. But this portion of your list is dependent on the size of the transaction so it isn't going to halve the time to go from two small updates to a single large update here. But this is the portion that requires user interaction, what happens between the first update notice and the message that all updates were installed. So from a users POV the time is reduced dramatically. I think it could even more than halve because scriptlets are only running once instead of several times. -Toshio Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Signing server? (Re: Updates testing for F-11)
On Thu, Jun 11, 2009 at 08:54:19PM -0400, Josh Boyer wrote: On Thu, Jun 11, 2009 at 8:39 PM, Christoph Wickertchristoph.wick...@googlemail.com wrote: need it because things need to be predictable for package maintainers. Some updates are processed after a day, others not for two weeks. I'm a bit confused where your date is coming from. 2 weeks seems wrong lately. In fact, since I took over the push stuff, it's normally done daily or as often as the composes allow. Right now, the compose for f11-updates alone is 7-8 hours, so doing it daily often just doesn't work out. But 2 weeks seems wrong. Actually, mashing f11-updates last week took 11 hours. The entire push took about 22. luke -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Signing server? (Re: Updates testing for F-11)
On Fri, 12 Jun 2009, Luke Macken wrote: On Thu, Jun 11, 2009 at 08:54:19PM -0400, Josh Boyer wrote: On Thu, Jun 11, 2009 at 8:39 PM, Christoph Wickertchristoph.wick...@googlemail.com wrote: need it because things need to be predictable for package maintainers. Some updates are processed after a day, others not for two weeks. I'm a bit confused where your date is coming from. 2 weeks seems wrong lately. In fact, since I took over the push stuff, it's normally done daily or as often as the composes allow. Right now, the compose for f11-updates alone is 7-8 hours, so doing it daily often just doesn't work out. But 2 weeks seems wrong. Actually, mashing f11-updates last week took 11 hours. The entire push took about 22. seems like that is a creating prestodelta.xml bug that we're working on now. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Signing server? (Re: Updates testing for F-11)
Josh Boyer wrote: No. It simply is not possible. See my (and Luke's) email on how long a single push takes. Seth says the 22-hour run is a bug. If a run can be done in ~8 hours, that means an automated update procedure could do about 3 per day. But of course, if it takes one day, then let's do one per day. I'm not asking for the impossible. ;-) Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Signing server? (Re: Updates testing for F-11)
On Fri, Jun 12, 2009 at 9:14 AM, Kevin Koflerkevin.kof...@chello.at wrote: Josh Boyer wrote: No. It simply is not possible. See my (and Luke's) email on how long a single push takes. Seth says the 22-hour run is a bug. If a run can be done in ~8 hours, that means an automated update procedure could do about 3 per day. Theoretically, yes. In reality, probably not. At least not until we get some of the other items in place that would even make this remotely possible. Also, we need to fix the failure paths, which make things indeterminably slower. But of course, if it takes one day, then let's do one per day. I'm not asking for the impossible. ;-) I WAS doing one a day. In fact, until a week ago I was doing them as often as possible. I plan to pick that back up on Monday, as I'm only able to be online for about 5 min at a time until then. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Signing server? (Re: Updates testing for F-11)
Am Freitag, den 12.06.2009, 05:34 +0200 schrieb Kevin Kofler: Christoph Wickert wrote: IMO this is something we should discuss on this list. We need to find a fine balance between pushing updates in time to make maintainers happy and not too many updates for the users. Maybe something like security/urgent updates daily, everything else once or twice a week. But this needs further discussion. I don't see what it buys our users if they get one big update over 2 small ones. In most cases the biggest part (consuming time and cpu cycles) of the updates is not installing them but everything else like checking for new packages, downloading the metadata, calculating dependencies, downloading the packages and running the transaction test. Especially for small updates this takes much more time than the actual rpm -U part. Plus, it'd require us to distinguish urgent vs. not urgent updates, and causes big issues with urgent updates accidentally depending on non-urgent ones. Good point. I did not think of that because my updates usually are at the end of a dependency chain and if not, I put all packages that require each other into one big update. Maintainers should be smart enough to do it that way. Of course it would cause problems for people waiting for other packager's updates, but IMO this is no difference to the current situation: If you don't ask rel-eng for a build root overwrite, you have to wait until the dependencies are pushed before you can build you packages. Of course it would require some automatic dependency check from bodhi, but this is something we should look at anyway as the recent vte update shows. Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Signing server? (Re: Updates testing for F-11)
Christoph Wickert wrote: In most cases the biggest part (consuming time and cpu cycles) of the updates is not installing them but everything else like checking for new packages, downloading the metadata, calculating dependencies, downloading the packages and running the transaction test. Especially for small updates this takes much more time than the actual rpm -U part. If you include just the urgent stuff in daily updates, those will still be the same. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Signing server? (Re: Updates testing for F-11)
On 06/12/2009 08:14 AM, Christoph Wickert wrote: Am Freitag, den 12.06.2009, 05:34 +0200 schrieb Kevin Kofler: I don't see what it buys our users if they get one big update over 2 small ones. In most cases the biggest part (consuming time and cpu cycles) of the updates is not installing them but everything else like checking for new packages, downloading the metadata, This portion of the list is saved. calculating dependencies, downloading the packages and running the transaction test. Especially for small updates this takes much more time than the actual rpm -U part. But this portion of your list is dependent on the size of the transaction so it isn't going to halve the time to go from two small updates to a single large update here. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates testing for F-11
On Thu, Jun 11, 2009 at 12:20 AM, Bruno Wolff IIIbr...@wolff.to wrote: On Thu, Jun 11, 2009 at 07:44:24 +0530, Rahul Sundaram sunda...@fedoraproject.org wrote: On 06/11/2009 07:39 AM, Bojan Smojver wrote: Bojan Smojver bojan at rexursive.com writes: Maybe I missed something, but it seems that some updates that have been submitted for F-11 testing are still pending. Any ideas why that is? I meant to say, submitted over a week ago. They are probably waiting on rel-eng to sign the packages. If you can be more specific, it would be easier to tell you what the status is. It may also be a case of not wanting to produce more churn right at release time. Not really, but I like that theory so I will claim it's true. Unfortunately, rawhide has been taking multiple days to spit out. Combine that with the fact that the two people that do sign/push for updates were both in a FAD this week and you get a bit less response time. I tried to do an updates push earlier this week and it hit some errors. That needs to be fixed and resumed. I won't be able to get to this until Sunday at the earliest. If Jesse or Luke want to fix that up, it might help. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Signing server? (Re: Updates testing for F-11)
Am Donnerstag, den 11.06.2009, 20:54 -0400 schrieb Josh Boyer: On Thu, Jun 11, 2009 at 8:39 PM, Christoph Wickertchristoph.wick...@googlemail.com wrote: Some updates are processed after a day, others not for two weeks. I'm a bit confused where your date is coming from. 2 weeks seems wrong lately. In fact, since I took over the push stuff, it's normally done daily or as often as the composes allow. Right now, the compose for f11-updates alone is 7-8 hours, so doing it daily often just doesn't work out. But 2 weeks seems wrong. OK, 12 days to be correct. You said it will not happen before the weekend, and if it happens on Sunday, two of my requests have reached 12 days. Also, signing server won't really help any of the above. Especially at release time this is annoying as some of the packages I submitted were bugfixes I wanted to be in the Xfce Spin. Another package was renamed, if it got pushed in time this would have happend smoothly between releases. So any chance we get a more reliable push mechanism? If by reliable you mean auto-pushed, maybe. Two options: More manpower or automatic pushes. For me it is important that I get a time frame that I can count on. But that would need auto-sign and an agreed upon schedule for updates and code. IMO this is something we should discuss on this list. We need to find a fine balance between pushing updates in time to make maintainers happy and not too many updates for the users. Maybe something like security/urgent updates daily, everything else once or twice a week. But this needs further discussion. And right now, we have a number of things that cause backend failures which necessitates manually fixing them. If you'd like to volunteer to code on bodhi and fix some of these, it would be most welcome. With the number of people currently working on it (2-3), it will be a while before we get to that point. I will see what I can do, but currently I'm swamped with other things, both Fedora (LinuxTag Berlin) and $dayjob. Also it will take some time for me to get involved in infrastructure, but if possible, I'll do it. josh Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates testing for F-11
On Thu, Jun 11, 2009 at 01:37:08PM -0400, Josh Boyer wrote: I tried to do an updates push earlier this week and it hit some errors. That needs to be fixed and resumed. I won't be able to get to this until Sunday at the earliest. If Jesse or Luke want to fix that up, it might help. I fixed the errors. luke -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
F10 updates-testing - F11 updates-testing yum upgrade issue
When trying to do a yum upgrade from 10 updates-testing to 11 updates-testing, I get the following: This is due to F11 updates-testing 'vte' package including a newer version of libvte, but the previous version was not retained. Could someone push a rebuild of gnome-terminal, gnome-desktop-sharp, Terminal and grip ASAP (maybe other packages are affected as well) ? Error: Missing Dependency: libvte.so.9 is needed by package gnome-terminal-2.26.2-1.fc11.i586 (updates-testing) Error: Missing Dependency: libvte.so.9 is needed by package gnome-desktop-sharp-2.26.0-1.fc11.i586 (fedora) Error: Missing Dependency: libvte.so.9 is needed by package Terminal-0.2.12-1.fc11.i586 (fedora) Error: Missing Dependency: libvte.so.9 is needed by package Terminal-0.2.12-1.fc11.i586 (updates) Error: Missing Dependency: libvte.so.9 is needed by package 1:grip-3.2.0-26.fc11.i586 (fedora) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F10 updates-testing - F11 updates-testing yum upgrade issue
When trying to do a yum upgrade from 10 updates-testing to 11 updates-testing, I get the following: This is due to F11 updates-testing 'vte' package including a newer version of libvte, but the previous version was not retained. Could someone push a rebuild of gnome-terminal, gnome-desktop-sharp, Terminal and grip ASAP (maybe other packages are affected as well) ? Read the mailing list archives. This has already been addressed in the last day or so. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F10 updates-testing - F11 updates-testing yum upgrade issue
On Wed, 10 Jun 2009 12:20:42 +0300 (EEST), Pekka wrote: When trying to do a yum upgrade from 10 updates-testing to 11 updates-testing, I get the following: This is due to F11 updates-testing 'vte' package including a newer version of libvte, but the previous version was not retained. Could someone push a rebuild of gnome-terminal, gnome-desktop-sharp, Terminal and grip ASAP (maybe other packages are affected as well) ? Error: Missing Dependency: libvte.so.9 is needed by package gnome-terminal-2.26.2-1.fc11.i586 (updates-testing) Error: Missing Dependency: libvte.so.9 is needed by package gnome-desktop-sharp-2.26.0-1.fc11.i586 (fedora) Error: Missing Dependency: libvte.so.9 is needed by package Terminal-0.2.12-1.fc11.i586 (fedora) Error: Missing Dependency: libvte.so.9 is needed by package Terminal-0.2.12-1.fc11.i586 (updates) Error: Missing Dependency: libvte.so.9 is needed by package 1:grip-3.2.0-26.fc11.i586 (fedora) See the older threads about it. It's an accident, and btw, with a SONAME change like this in updates-testing, nobody could simply rebuild dependencies because koji buildroot override tags are needed first. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates testing for F-11
Bojan Smojver bojan at rexursive.com writes: Maybe I missed something, but it seems that some updates that have been submitted for F-11 testing are still pending. Any ideas why that is? I meant to say, submitted over a week ago. -- Bojan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates testing for F-11
Rahul Sundaram sundaram at fedoraproject.org writes: They are probably waiting on rel-eng to sign the packages. If you can be more specific, it would be easier to tell you what the status is. viewvc-1.1.1. Also, it would be good if various apr-util packages (from F-9 to F-11 could be pushed to testing). They contain security fixes. -- Bojan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates testing for F-11
On Thu, Jun 11, 2009 at 07:44:24 +0530, Rahul Sundaram sunda...@fedoraproject.org wrote: On 06/11/2009 07:39 AM, Bojan Smojver wrote: Bojan Smojver bojan at rexursive.com writes: Maybe I missed something, but it seems that some updates that have been submitted for F-11 testing are still pending. Any ideas why that is? I meant to say, submitted over a week ago. They are probably waiting on rel-eng to sign the packages. If you can be more specific, it would be easier to tell you what the status is. It may also be a case of not wanting to produce more churn right at release time. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
