On Tue, Jun 7, 2011 at 4:29 PM, Tom Gundersen wrote:

On Tue, Jun 7, 2011 at 4:35 PM, Allan McRae 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 09/06/11 07:20, Evangelos Foutras wrote:

On 7 June 2011 13: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

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

On 9 June 2011 00:58, Allan McRae wrote:

On 09/06/11 07:20, Evangelos Foutras wrote:

...

On 7 June 2011 13: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

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.

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

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

Another signoff for i686. Stéphane

On Tue, Jun 21, 2011 at 8:29 AM, Ionut Biru 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

On 21/06/11 19:47, Tom Gundersen wrote:

On Tue, Jun 21, 2011 at 8:29 AM, Ionut Biru 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 22/06/11 19:10, Tom Gundersen wrote:

On Wed, Jun 22, 2011 at 10:53 AM, Allan McRae 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 23/06/11 19:44, Tom Gundersen wrote:

On Thu, Jun 23, 2011 at 11:25 AM, Allan McRae 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 26/06/11 06:56, Tom Gundersen wrote:

On Sat, Jun 25, 2011 at 2:05 PM, Allan McRae wrote:

...

On 23/06/11 19:44, Tom Gundersen wrote:

...

On Thu, Jun 23, 2011 at 11:25 AM, Allan McRae 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