[arch-dev-public] [signoff] glibc-2.14 toolchain build
The glibc-2.14 toolchain update is in [testing]. Here is a summary of the changes. glibc-2.14-1 - major version release - add patch to fix libdl crash Note: The RPC implementation in libc is obsoleted. Old programs keep working but new programs cannot be linked with the routines in libc anymore. Programs in need of RPC functionality must be linked against TI-RPC. The TI-RPC implementation is IPv6 enabled and there are other benefits. Visible changes of this change include (obviously) the inability to link programs using RPC functions without referencing the TI-RPC library and the removal of the RPC headers from the glibc headers. linux-api-headers-2.6.29.1-1 - upstream update gcc-4.6.0-7 - just rebuilt binutils-2.21-9 - new snapshot from 2.21 branch (close to 2.21.1 release) valgrind-3.6.1-2 - rebuild This will sit in [testing] for a while to get some decent testing. The testsuites all look fine so I am not expecting too many issues... Allan
On 07/06/11 20:18, Allan McRae wrote:
The glibc-2.14 toolchain update is in [testing]. Here is a summary of the changes.
glibc-2.14-1 - major version release - add patch to fix libdl crash
Note:
The RPC implementation in libc is obsoleted. Old programs keep working but new programs cannot be linked with the routines in libc anymore. Programs in need of RPC functionality must be linked against TI-RPC. The TI-RPC implementation is IPv6 enabled and there are other benefits.
Visible changes of this change include (obviously) the inability to link programs using RPC functions without referencing the TI-RPC library and the removal of the RPC headers from the glibc headers.
This change results in build failures for the following [core] packages: FAIL: librpcsecgss FAIL: libtirpc FAIL: mkinitcpio-busybox FAIL: pam FAIL: rpcbind FAIL: xinetd I will look into these over the next couple of days. Also, some people are seeing segfaults in libresolv (__libc_res_nquery). So this will not be moving until the bug is fixed: https://bugs.archlinux.org/task/24615 . This is not an Arch specific issue... Allan
On Tue, Jun 7, 2011 at 4:35 PM, Allan McRae <allan@archlinux.org> wrote:
Also, some people are seeing segfaults in libresolv (__libc_res_nquery). So this will not be moving until the bug is fixed: https://bugs.archlinux.org/task/24615 . This is not an Arch specific issue...
I seem to be hit by this pretty badly (worse than I first reported on irc). At the moment pacman segfaults 100% of the time, so I'm not able to downgrade. So, beware of this if you are using [testing]. Cheers, Tom
On Tue, Jun 7, 2011 at 4:29 PM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Jun 7, 2011 at 4:35 PM, Allan McRae <allan@archlinux.org> wrote:
Also, some people are seeing segfaults in libresolv (__libc_res_nquery). So this will not be moving until the bug is fixed: https://bugs.archlinux.org/task/24615 . This is not an Arch specific issue...
I seem to be hit by this pretty badly (worse than I first reported on irc). At the moment pacman segfaults 100% of the time, so I'm not able to downgrade.
So, beware of this if you are using [testing].
It segfaults even if you do no network operation (e.g. -U <oldpkg>). Can you by chance get a gdb backtrace [1]? -Dan [1] $ sudo gdb --args pacman <command line args>
start continue (segfault occurs) bt full
On 7 June 2011 13:18, Allan McRae <allan@archlinux.org> wrote:
The glibc-2.14 toolchain update is in [testing]. Here is a summary of the changes.
glibc-2.14-1 - major version release - add patch to fix libdl crash
Looks like the glibc update will interfere with other rebuilds (e.g.: Perl). At least my pidgin package is affected, and will give "/lib/libc.so.6: version `GLIBC_2.14' not found" errors if moved to [extra] without glibc being moved to [core] at the same time. What's the preferred course of action we take here? Rebuild affected packages with the old glibc? Wait for glibc to move to [core] before moving the Perl rebuilds?
On 09/06/11 07:20, Evangelos Foutras wrote:
On 7 June 2011 13:18, Allan McRae<allan@archlinux.org> wrote:
The glibc-2.14 toolchain update is in [testing]. Here is a summary of the changes.
glibc-2.14-1 - major version release - add patch to fix libdl crash
Looks like the glibc update will interfere with other rebuilds (e.g.: Perl).
At least my pidgin package is affected, and will give "/lib/libc.so.6: version `GLIBC_2.14' not found" errors if moved to [extra] without glibc being moved to [core] at the same time.
What's the preferred course of action we take here? Rebuild affected packages with the old glibc? Wait for glibc to move to [core] before moving the Perl rebuilds?
I thought the perl rebuilds were done a long time before the glibc updated hit [testing], so they should be fine. I would not expect glibc to move any time soon given the crash we are currently seeing. Allan
2011/6/8 Allan McRae <allan@archlinux.org>:
On 09/06/11 07:20, Evangelos Foutras wrote:
On 7 June 2011 13:18, Allan McRae<allan@archlinux.org> wrote:
The glibc-2.14 toolchain update is in [testing]. Here is a summary of the changes.
glibc-2.14-1 - major version release - add patch to fix libdl crash
Looks like the glibc update will interfere with other rebuilds (e.g.: Perl).
At least my pidgin package is affected, and will give "/lib/libc.so.6: version `GLIBC_2.14' not found" errors if moved to [extra] without glibc being moved to [core] at the same time.
What's the preferred course of action we take here? Rebuild affected packages with the old glibc? Wait for glibc to move to [core] before moving the Perl rebuilds?
I thought the perl rebuilds were done a long time before the glibc updated hit [testing], so they should be fine.
I would not expect glibc to move any time soon given the crash we are currently seeing.
This is a good time to hi-jack this thread and pushing up you, to sign-off perl 5.14.0-1 .. Allan I will make an installation of i686 with frozenbubble, but it will be really helpful if you try to dig what's happening with frozenbubble with me (I have no error reported and the bugs reported on the bug tracker seems to be people which manually installed stuff from cpan).. Cheers -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
On 9 June 2011 00:58, Allan McRae <allan@archlinux.org> wrote:
On 09/06/11 07:20, Evangelos Foutras wrote:
On 7 June 2011 13:18, Allan McRae<allan@archlinux.org> wrote:
The glibc-2.14 toolchain update is in [testing]. Here is a summary of the changes.
glibc-2.14-1 - major version release - add patch to fix libdl crash
Looks like the glibc update will interfere with other rebuilds (e.g.: Perl).
At least my pidgin package is affected, and will give "/lib/libc.so.6: version `GLIBC_2.14' not found" errors if moved to [extra] without glibc being moved to [core] at the same time.
What's the preferred course of action we take here? Rebuild affected packages with the old glibc? Wait for glibc to move to [core] before moving the Perl rebuilds?
I thought the perl rebuilds were done a long time before the glibc updated hit [testing], so they should be fine.
Indeed there were done, but I updated pidgin yesterday and pushed new packages to both [testing] and [extra]. Below is the complete list of packages in [testing] that reference the GLIBC_2.14 symbol: ============================== [foutrelis@gerolde ~]$ echo -e "\n[testing]\n---------"; for pkg in /srv/ftp/testing/os/x86_64/*.pkg.tar.xz; do xzcat $pkg | grep -Fq GLIBC_2.14 && echo $(basename $pkg); done; echo -e "\n[community-testing]\n-------------------"; for pkg in /srv/ftp/community-testing/os/x86_64/*.pkg.tar.xz; do xzcat $pkg | grep -Fq GLIBC_2.14 && echo $(basename $pkg); done [testing] --------- binutils-2.21-9-x86_64.pkg.tar.xz finch-2.8.0-2-x86_64.pkg.tar.xz gcc-4.6.0-7-x86_64.pkg.tar.xz gcc-ada-4.6.0-7-x86_64.pkg.tar.xz gcc-fortran-4.6.0-7-x86_64.pkg.tar.xz gcc-go-4.6.0-7-x86_64.pkg.tar.xz gcc-libs-4.6.0-7-x86_64.pkg.tar.xz gcc-objc-4.6.0-7-x86_64.pkg.tar.xz glibc-2.14-1-x86_64.pkg.tar.xz libpurple-2.8.0-2-x86_64.pkg.tar.xz lirc-utils-1:0.9.0-3-x86_64.pkg.tar.xz mod_perl-2.0.5-3-x86_64.pkg.tar.xz pidgin-2.8.0-2-x86_64.pkg.tar.xz valgrind-3.6.1-2-x86_64.pkg.tar.xz [community-testing] ------------------- ============================== I guess I need to fix pidgin and mod_perl. lirc-utils appears to be affected too. (The rest are your packages so it's intended.) I will try to do these tomorrow in about 20-22 hours.
I would not expect glibc to move any time soon given the crash we are currently seeing.
That's going to be an issue if we need to use [testing] again while glibc remains there. Just something to keep in mind.
On 9 June 2011 02:21, Evangelos Foutras <foutrelis@gmail.com> wrote:
I guess I need to fix pidgin and mod_perl. lirc-utils appears to be affected too. (The rest are your packages so it's intended.)
I will try to do these tomorrow in about 20-22 hours.
Decided to just do them now (pidgin, mod_perl), as to not hold the Perl rebuilds from moving out of [testing].
glibc-2.14-2 is in [testing]. This reverts the patch that causes the segfaulting on what appears to be failed DNS lookups. If no issues are discovered with this package in the next day, I will be happy to move the toolchain from [testing]. So signoff away! Signoff both, Allan
On 11/06/11 18:54, Allan McRae wrote:
glibc-2.14-2 is in [testing]. This reverts the patch that causes the segfaulting on what appears to be failed DNS lookups.
If no issues are discovered with this package in the next day, I will be happy to move the toolchain from [testing]. So signoff away!
On second thoughts... I will probably not move this until I revert the patch that removes the RPC headers. libtirpc does not seem ready as a complete replacement (yet...) so not reverting that will cause us some issues in the short term. Allan
Try again with glibc-2.14-3 Changes in -3: - New upstream 2.14 branch snapshot (a couple of useful fixes have been added) - new upstream patch to properly fix the libdl crashes - redistriubte the rpc interface until libtirpc is ready as a genuine replacement... Signoff both, Allan
Le 18 juin 2011 02:17:42, Allan McRae a écrit :
Try again with glibc-2.14-3
Changes in -3: - New upstream 2.14 branch snapshot (a couple of useful fixes have been added) - new upstream patch to properly fix the libdl crashes - redistriubte the rpc interface until libtirpc is ready as a genuine replacement...
Signoff both, Allan
Nothing broken in my testing chroot and pam build again :) Signoff x86_64 Stéphane
Le 18 juin 2011 02:17:42, Allan McRae a écrit :
Try again with glibc-2.14-3
Changes in -3: - New upstream 2.14 branch snapshot (a couple of useful fixes have been added) - new upstream patch to properly fix the libdl crashes - redistriubte the rpc interface until libtirpc is ready as a genuine replacement...
Signoff both, Allan
Another signoff for i686. Stéphane
On 06/18/2011 09:17 AM, Allan McRae wrote:
Try again with glibc-2.14-3
Changes in -3: - New upstream 2.14 branch snapshot (a couple of useful fixes have been added) - new upstream patch to properly fix the libdl crashes - redistriubte the rpc interface until libtirpc is ready as a genuine replacement...
Signoff both, Allan
can you ping me when you want to move it? sign off i686 -- Ionuț
On Tue, Jun 21, 2011 at 8:29 AM, Ionut Biru <ibiru@archlinux.org> wrote:
On 06/18/2011 09:17 AM, Allan McRae wrote:
Try again with glibc-2.14-3
Changes in -3: - New upstream 2.14 branch snapshot (a couple of useful fixes have been added) - new upstream patch to properly fix the libdl crashes - redistriubte the rpc interface until libtirpc is ready as a genuine replacement...
Signoff both, Allan
can you ping me when you want to move it?
sign off i686
I'm still seeing lots of random crashes using testing. I have three machines with similar problems, but not identical. machine 1: amarok and konversation alwayl crashes, ktorrent does not machine 2: konversation and ktorrent both work fine machine 3: ktorrent always crashes All machines: pacman crashes some of the time (~50%), same with git. This is running kde-unstable on top of testing and all packages updated as of last night. Cheers, Tom
No crashes for me on x86_64 desktop + notebook. -Andy
On 21/06/11 19:47, Tom Gundersen wrote:
On Tue, Jun 21, 2011 at 8:29 AM, Ionut Biru<ibiru@archlinux.org> wrote:
On 06/18/2011 09:17 AM, Allan McRae wrote:
Try again with glibc-2.14-3
Changes in -3: - New upstream 2.14 branch snapshot (a couple of useful fixes have been added) - new upstream patch to properly fix the libdl crashes - redistriubte the rpc interface until libtirpc is ready as a genuine replacement...
Signoff both, Allan
can you ping me when you want to move it?
sign off i686
I'm still seeing lots of random crashes using testing. I have three machines with similar problems, but not identical.
machine 1: amarok and konversation alwayl crashes, ktorrent does not machine 2: konversation and ktorrent both work fine machine 3: ktorrent always crashes
All machines: pacman crashes some of the time (~50%), same with git.
This is running kde-unstable on top of testing and all packages updated as of last night.
Were they fixed with glibc-2.14-2? Allan
On Wed, Jun 22, 2011 at 10:53 AM, Allan McRae <allan@archlinux.org> wrote:
On 21/06/11 19:47, Tom Gundersen wrote:
I'm still seeing lots of random crashes using testing. I have three machines with similar problems, but not identical.
machine 1: amarok and konversation alwayl crashes, ktorrent does not machine 2: konversation and ktorrent both work fine machine 3: ktorrent always crashes
All machines: pacman crashes some of the time (~50%), same with git.
This is running kde-unstable on top of testing and all packages updated as of last night.
Were they fixed with glibc-2.14-2?
No. What can I do to help debugging? I have not yet tried to find the cause. I am using networkmanager with dnsmasq, as well as nss-mdns (avahi), but don't know if that is related. I'll be gone for most of the day, but should be back tonight (CEST) on IRC. -t
On 22/06/11 19:10, Tom Gundersen wrote:
On Wed, Jun 22, 2011 at 10:53 AM, Allan McRae<allan@archlinux.org> wrote:
On 21/06/11 19:47, Tom Gundersen wrote:
I'm still seeing lots of random crashes using testing. I have three machines with similar problems, but not identical.
machine 1: amarok and konversation alwayl crashes, ktorrent does not machine 2: konversation and ktorrent both work fine machine 3: ktorrent always crashes
All machines: pacman crashes some of the time (~50%), same with git.
This is running kde-unstable on top of testing and all packages updated as of last night.
Were they fixed with glibc-2.14-2?
No. What can I do to help debugging? I have not yet tried to find the cause. I am using networkmanager with dnsmasq, as well as nss-mdns (avahi), but don't know if that is related.
I'll be gone for most of the day, but should be back tonight (CEST) on IRC.
Ah... I remember your issue and it was different to the more common crash caused by that patch (assert hp1 != hp2 or something like that?). Other people are also seeing it too so I have backtraces to look into this. Allan
On Thu, Jun 23, 2011 at 11:25 AM, Allan McRae <allan@archlinux.org> wrote:
Ah... I remember your issue and it was different to the more common crash caused by that patch (assert hp1 != hp2 or something like that?).
Exactly: pacman: res_query.c:251: __libc_res_nquery: Assertion `hp != hp2' failed. -t
On 23/06/11 19:44, Tom Gundersen wrote:
On Thu, Jun 23, 2011 at 11:25 AM, Allan McRae<allan@archlinux.org> wrote:
Ah... I remember your issue and it was different to the more common crash caused by that patch (assert hp1 != hp2 or something like that?).
Exactly:
pacman: res_query.c:251: __libc_res_nquery: Assertion `hp != hp2' failed.
glibc-2.14-4 should "fix" this... not a real fix, but it should work. Give a signoff if all is OK. Allan
On Sat, Jun 25, 2011 at 2:05 PM, Allan McRae <allan@archlinux.org> wrote:
On 23/06/11 19:44, Tom Gundersen wrote:
On Thu, Jun 23, 2011 at 11:25 AM, Allan McRae<allan@archlinux.org> wrote:
Ah... I remember your issue and it was different to the more common crash caused by that patch (assert hp1 != hp2 or something like that?).
Exactly:
pacman: res_query.c:251: __libc_res_nquery: Assertion `hp != hp2' failed.
glibc-2.14-4 should "fix" this... not a real fix, but it should work.
Give a signoff if all is OK.
pacman synchronises without problems, and git works fine. I have not seen any other problems, so: signoff x86_64. -t
On 26/06/11 06:56, Tom Gundersen wrote:
On Sat, Jun 25, 2011 at 2:05 PM, Allan McRae<allan@archlinux.org> wrote:
On 23/06/11 19:44, Tom Gundersen wrote:
On Thu, Jun 23, 2011 at 11:25 AM, Allan McRae<allan@archlinux.org> wrote:
Ah... I remember your issue and it was different to the more common crash caused by that patch (assert hp1 != hp2 or something like that?).
Exactly:
pacman: res_query.c:251: __libc_res_nquery: Assertion `hp != hp2' failed.
glibc-2.14-4 should "fix" this... not a real fix, but it should work.
Give a signoff if all is OK.
pacman synchronises without problems, and git works fine.
I have not seen any other problems, so:
signoff x86_64.
Awesome. Anyone for a quick i686 signoff? It is time to move the toolchain to [core]! Allan
signoff i686 Rémy.
participants (9)
-
Allan McRae
-
Andreas Radke
-
Dan McGee
-
Evangelos Foutras
-
Ionut Biru
-
Rémy Oudompheng
-
Stéphane Gaudreault
-
Tom Gundersen
-
Ángel Velásquez