[arch-dev-public] WARNING: [testing] broken due to openssl and heimdal rebuilds
Hi all, this is a warning for [testing] users not to update until the upcoming openssl/heimdal rebuilds are done. This will break a lot of important packages. I am bootstrapping openssl and rebuild the most imporant packages like pacman atm. I'll send another mail to the openssl-1.0.0 thread when you can start rebuilding. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Thu, 01 Apr 2010 03:05:28 +0200 schrieb Pierre Schmitz <pierre@archlinux.de>:
Hi all,
this is a warning for [testing] users not to update until the upcoming openssl/heimdal rebuilds are done. This will break a lot of important packages. I am bootstrapping openssl and rebuild the most imporant packages like pacman atm. I'll send another mail to the openssl-1.0.0 thread when you can start rebuilding.
Greetings,
Pierre
Most stuff seems usable again. One question: Because I have to rebuild all OpenOffice packages anyways I'd like to ask what you think about adding another rebuild cycle - ICU 4.4. http://www.archlinux.org/packages/extra/i686/icu/ Not too many packages seem to depend on it. Most time will be eaten by OOo. Objections? -Andy
On Fri, 2 Apr 2010 17:30:33 +0200, Andreas Radke <a.radke@arcor.de> wrote:
Am Thu, 01 Apr 2010 03:05:28 +0200 schrieb Pierre Schmitz <pierre@archlinux.de>:
Hi all,
this is a warning for [testing] users not to update until the upcoming openssl/heimdal rebuilds are done. This will break a lot of important packages. I am bootstrapping openssl and rebuild the most imporant packages like pacman atm. I'll send another mail to the openssl-1.0.0 thread when you can start rebuilding.
Greetings,
Pierre
Most stuff seems usable again.
One question: Because I have to rebuild all OpenOffice packages anyways I'd like to ask what you think about adding another rebuild cycle - ICU 4.4. http://www.archlinux.org/packages/extra/i686/icu/
Not too many packages seem to depend on it. Most time will be eaten by OOo.
Objections?
-Andy
Could you send me the changed so names or just the output of pacman -Qlp <pkg_ of the new pacakge so I can see which packages would be affected? (and to create a todo list to make the "big move" easier) -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 01.04.2010 03:05, schrieb Pierre Schmitz:
Hi all,
this is a warning for [testing] users not to update until the upcoming openssl/heimdal rebuilds are done. This will break a lot of important packages. I am bootstrapping openssl and rebuild the most imporant packages like pacman atm. I'll send another mail to the openssl-1.0.0 thread when you can start rebuilding.
Upgrading still fails: pacman itself works after the small upgrade. But all post-install scripts in the -Syu that use vercmp are broken. For example, kernel26 post-install failed on a -Syu for me.
On Tue, Apr 6, 2010 at 3:15 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 01.04.2010 03:05, schrieb Pierre Schmitz:
Hi all,
this is a warning for [testing] users not to update until the upcoming openssl/heimdal rebuilds are done. This will break a lot of important packages. I am bootstrapping openssl and rebuild the most imporant packages like pacman atm. I'll send another mail to the openssl-1.0.0 thread when you can start rebuilding.
Upgrading still fails: pacman itself works after the small upgrade. But all post-install scripts in the -Syu that use vercmp are broken. For example, kernel26 post-install failed on a -Syu for me.
I'm trying to figure out how this happens. pacman and vercmp should have idential link libraries, so if one works, the other should (and if one doesn't, the other shouldn't). Did you have pacman in SyncFirst, and did you do that? -Dan
Am 06.04.2010 22:22, schrieb Dan McGee:
I'm trying to figure out how this happens. pacman and vercmp should have idential link libraries, so if one works, the other should (and if one doesn't, the other shouldn't).
I am also confused. This might help: [2010-04-06 21:20] upgraded kernel26 (2.6.33.1-1 -> 2.6.33.2-1) [2010-04-06 21:20] upgraded kernel26-headers (2.6.33.1-1 -> 2.6.33.2-1) [2010-04-06 21:20] upgraded lib32-e2fsprogs (1.41.10-1 -> 1.41.11-1) [2010-04-06 21:20] upgraded libart-lgpl (2.3.20-1 -> 2.3.21-1) [2010-04-06 21:20] upgraded libfetch (2.30-1 -> 2.30-3) The vercmp trouble was at kernel26 post-install.
Did you have pacman in SyncFirst, and did you do that?
I have and I did.
On Tue, 6 Apr 2010 15:22:02 -0500, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, Apr 6, 2010 at 3:15 PM, Thomas Bächler <thomas@archlinux.org>
Upgrading still fails: pacman itself works after the small upgrade. But all post-install scripts in the -Syu that use vercmp are broken. For example, kernel26 post-install failed on a -Syu for me.
I'm trying to figure out how this happens. pacman and vercmp should have idential link libraries, so if one works, the other should (and if one doesn't, the other shouldn't).
I was able to reproduce this problem. Here it is: The first run of pacman -Syu will just update pacman which does not directly link to openssl. So the system will still be fine. The second run will update everything else. During this update openssl is updated. The prbolem is that libarchive and libfetch are not updated right after the new version of openssl is installed. This means that all install scripts calling vercmp will fail until the new libs are installed. This is some kind of general problem: the system may be inconsistent during the process of updating and install scripts will fail. In this case we need to make sure that libarchive and libfetch are updated right after openssl. This might be solved by increasing the versioned deps of pacman to libarchive/libfetch to their latest versions which should pull in the new openssl. The problem is that doing so the system is inconsistent/broken after the first -Syu run. @Dan: you told me it might be possible to just include the needed object files of libalpm into vercmp, so that it does not link against it anymore; maybe that would be a more elegant solution. (or include the needed code on source level? no idea how this was implemented) -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Tue, Apr 6, 2010 at 10:36 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
On Tue, 6 Apr 2010 15:22:02 -0500, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, Apr 6, 2010 at 3:15 PM, Thomas Bächler <thomas@archlinux.org>
Upgrading still fails: pacman itself works after the small upgrade. But all post-install scripts in the -Syu that use vercmp are broken. For example, kernel26 post-install failed on a -Syu for me.
I'm trying to figure out how this happens. pacman and vercmp should have idential link libraries, so if one works, the other should (and if one doesn't, the other shouldn't).
I was able to reproduce this problem. Here it is:
The first run of pacman -Syu will just update pacman which does not directly link to openssl. So the system will still be fine. The second run will update everything else. During this update openssl is updated. The prbolem is that libarchive and libfetch are not updated right after the new version of openssl is installed. This means that all install scripts calling vercmp will fail until the new libs are installed.
This is some kind of general problem: the system may be inconsistent during the process of updating and install scripts will fail. In this case we need to make sure that libarchive and libfetch are updated right after openssl. This might be solved by increasing the versioned deps of pacman to libarchive/libfetch to their latest versions which should pull in the new openssl. The problem is that doing so the system is inconsistent/broken after the first -Syu run.
All makes sense now. I'm just afraid of the inconsistent step you noted above, as I know I have caught myself in it before and it is quite painful to be in.
@Dan: you told me it might be possible to just include the needed object files of libalpm into vercmp, so that it does not link against it anymore; maybe that would be a more elegant solution. (or include the needed code on source level? no idea how this was implemented)
Yes, but this will not be a quick fix, but I should have something ready for the next release that will allow us to do this. -Dan
On Tue, Apr 6, 2010 at 10:36 PM, Pierre Schmitz <pierre@archlinux.de>
This is some kind of general problem: the system may be inconsistent during the process of updating and install scripts will fail. In this case we need to make sure that libarchive and libfetch are updated right after openssl. This might be solved by increasing the versioned deps of
On Tue, 6 Apr 2010 23:04:32 -0500, Dan McGee <dpmcgee@gmail.com> wrote: pacman
to libarchive/libfetch to their latest versions which should pull in the new openssl. The problem is that doing so the system is inconsistent/broken after the first -Syu run.
All makes sense now. I'm just afraid of the inconsistent step you noted above, as I know I have caught myself in it before and it is quite painful to be in.
I just tested what happens if I change pacman depends to "'libarchive>=2.8.3-3' 'libfetch>=2.30-3'". You need to run -Syu twice but everything works fine. The remaining problem is that if you use anything else than libfetch to get your packages (e.g. wget or curl) you wont be able to update because after the first run those apps are broken. But I still don't see any chance to solve this in a smooth way. So I would change the pacman package that way and post a news item and ask people to run -Syu twice and tell them that external download programs cannot be used. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 07/04/10 14:42, Pierre Schmitz wrote:
On Tue, Apr 6, 2010 at 10:36 PM, Pierre Schmitz<pierre@archlinux.de>
This is some kind of general problem: the system may be inconsistent during the process of updating and install scripts will fail. In this case we need to make sure that libarchive and libfetch are updated right after openssl. This might be solved by increasing the versioned deps of
On Tue, 6 Apr 2010 23:04:32 -0500, Dan McGee<dpmcgee@gmail.com> wrote: pacman
to libarchive/libfetch to their latest versions which should pull in the new openssl. The problem is that doing so the system is inconsistent/broken after the first -Syu run.
All makes sense now. I'm just afraid of the inconsistent step you noted above, as I know I have caught myself in it before and it is quite painful to be in.
I just tested what happens if I change pacman depends to "'libarchive>=2.8.3-3' 'libfetch>=2.30-3'". You need to run -Syu twice but everything works fine. The remaining problem is that if you use anything else than libfetch to get your packages (e.g. wget or curl) you wont be able to update because after the first run those apps are broken.
But I still don't see any chance to solve this in a smooth way. So I would change the pacman package that way and post a news item and ask people to run -Syu twice and tell them that external download programs cannot be used.
External downloaders can be used. It just has to be done as: pacman -Syuw pacman -Su Allan
On Wed, 07 Apr 2010 14:49:19 +1000, "Allan McRae" <allan@archlinux.org> wrote:
External downloaders can be used. It just has to be done as: pacman -Syuw pacman -Su
So SyncFirst is ignored when using -w? That's even better. So, one need to update in three simple steps then: :P pacman -Syuw pacman -Su pacman -Su -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 07/04/10 14:55, Pierre Schmitz wrote:
On Wed, 07 Apr 2010 14:49:19 +1000, "Allan McRae"<allan@archlinux.org> wrote:
External downloaders can be used. It just has to be done as: pacman -Syuw pacman -Su
So SyncFirst is ignored when using -w?
Yeah... maybe not, but the user can choose "N" when asked.
That's even better. So, one need to update in three simple steps then: :P pacman -Syuw pacman -Su pacman -Su
On Wed, Apr 7, 2010 at 12:01 AM, Allan McRae <allan@archlinux.org> wrote:
On 07/04/10 14:55, Pierre Schmitz wrote:
On Wed, 07 Apr 2010 14:49:19 +1000, "Allan McRae"<allan@archlinux.org> wrote:
External downloaders can be used. It just has to be done as: pacman -Syuw pacman -Su
So SyncFirst is ignored when using -w?
Yeah... maybe not, but the user can choose "N" when asked.
That's even better. So, one need to update in three simple steps then: :P pacman -Syuw pacman -Su pacman -Su
Thus the reason I didn't want those deps in there, it gets way too complex. When we roll this whole thing out, can we just post in the news that you should pay close attention to the output and likely will have to `pacman -S kernel26` (and anything else that errored) if you want to be sure things are working OK? Obviously not ideal. Especially now that we've tied a major kernel bump to this, hmm. -Dan
On Wed, 7 Apr 2010 06:42:29 -0500, Dan McGee <dpmcgee@gmail.com> wrote:
Thus the reason I didn't want those deps in there, it gets way too complex.
When we roll this whole thing out, can we just post in the news that you should pay close attention to the output and likely will have to `pacman -S kernel26` (and anything else that errored) if you want to be sure things are working OK? Obviously not ideal. Especially now that we've tied a major kernel bump to this, hmm.
I tried it in my vm which was a little older; in that case nearly all install scripts fail and you have to manually reinstall a lot of stuff. In a worst case your system wont boot anymore. That's why I would prefer the method I mentioned. -- Pierre Schmitz, https://users.archlinux.de/~pierre
participants (5)
-
Allan McRae
-
Andreas Radke
-
Dan McGee
-
Pierre Schmitz
-
Thomas Bächler