Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Tue, 21 Nov 2017, Aurelien Jarno wrote:

> On 2017-11-21 01:01, Mikulas Patocka wrote:
> > 
> > 
> > On Tue, 21 Nov 2017, Aurelien Jarno wrote:
> > 
> > > On 2017-11-21 00:12, Mikulas Patocka wrote:
> > > > 
> > > > 
> > > > On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> > > > 
> > > > > On 2017-11-20 19:13, Mikulas Patocka wrote:
> > > > > > Package: libc6-amd64
> > > > > > Version: 2.25-1
> > > > > > Severity: critical
> > > > > > Justification: breaks the whole system
> > > > > > 
> > > > > > Dear Maintainer,
> > > > > > 
> > > > > > *** Reporter, please consider answering these questions, where 
> > > > > > appropriate ***
> > > > > > 
> > > > > >* What led up to the situation?
> > > > > > 
> > > > > > I have a x86-64 system with i386 and x32 foreign architectures 
> > > > > > (because I
> > > > > > need to develop software for i386 and x32 architectures).
> > > > > > 
> > > > > >* What exactly did you do (or not do) that was effective (or
> > > > > >  ineffective)?
> > > > > > 
> > > > > > I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> > > > > > 
> > > > > >* What was the outcome of this action?
> > > > > > 
> > > > > > Halfway through apt upgrade it failed and I ended up with unusable 
> > > > > > system where
> > > > > > large number of binaries were segfauting on startup without doign 
> > > > > > anything.
> > > > > > 
> > > > > >* What outcome did you expect instead?
> > > > > > 
> > > > > > The upgrade to libc-2.25 should work.
> > > > > > 
> > > > > > 
> > > > > > The reason for the catastrophic failure is this:
> > > > > > 
> > > > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > > > 
> > > > > I guess you mean you have installed one of the two, not both.
> > > > > 
> > > > > > x86-64 libc in /lib64/). This package is not technically needed 
> > > > > > (because
> > > > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it 
> > > > > > is
> > > > > > installed nonetheless because of some dependencies.
> > > > > 
> > > > > Just to be clear, as said in my other email, this *is* technically
> > > > > needed as gcc-multilib is not able to make use of the libc in
> > > > > /lib/x86_64-linux-gnu.
> > > > > 
> > > > > > apt makes sure that all libc packages are upgraded at once to the 
> > > > > > same
> > > > > > version. However, during the upgrade process, the package
> > > > > > libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, 
> > > > > > we
> > > > > > temporarily have two libcs with different versions on the system, 
> > > > > > and this
> > > > > > mismatch makes most of the x86-64 binaries crash. Due to the 
> > > > > > crashes, the
> > > > > > upgrade doesn't proceed and it doesn't install the correct libc 
> > > > > > version in
> > > > > > /lib/x86_64-linux-gnu/.
> > > > > > 
> > > > > > The result is unusable system.
> > > > > 
> > > > > I have done some tests, and while I confirm that libc6-i386:amd64 is
> > > > 
> > > > The problem is with libc6-amd64:i386 or libc6-amd64:x32.
> > > > Not libc6-i386:amd64.
> > > 
> > > Yes, sorry about that, I really did the test with libc6-amd64:i386, but
> > > mixed it when typing the mail.
> > > 
> > > > I.e. use amd64 Debian Sid base installation, add foreign architectures 
> > > > i386 and x32 and use this /etc/apt/sources.list:
> > > > 
> > > > deb [ arch=i386,amd64 ] http://ftp.cz.debian.org/debian/ sid main 
> > > > contrib non-free
> > > > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unreleased main
> > > > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unstable main
> > > > 
> > > > > unpacked much before libc6:amd64, it doesn't cause any issue here.
> > > > > Indeed the search path in ld.so is to give higher priority to
> > > > > /lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
> > > > > libc6:amd64 in version 2.24 (using force-all), while keeping
> > > > > libc6-amd64:i386 in version 2.25.
> > > > > 
> > > > > The only way to change the priority of the two path is using a
> > > > > non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf 
> > > > > or
> > > > > /etc/ld.so.conf.d/*? Maybe you can share the content of this file and
> > > > > this directory.
> > > > 
> > > > On my system, there's a file 
> > > > /etc/ld.so.conf.d/zz_amd64-biarch-compat.conf 
> > > > containing:
> > > > 
> > > > # Legacy biarch compatibility support
> > > > /lib64
> > > > /usr/lib64
> > > > 
> > > > and /etc/ld.so.conf.d/zz_i386-biarch-compat.conf containing:
> > > > 
> > > > # Legacy biarch compatibility support
> > > > /lib32
> > > > /usr/lib32
> > > > 
> > > > These files are created by the packages libc6-i386:x32 and 
> > > > libc6-amd64:x32. They cause that /lib64 is preferred to 
> > > > /lib/x86_64-linux-gnu/. If I delete these files and run ldconfig, the 
> > > > linker will prefer /lib/x86_64-linux-gnu/.
> > > 
> > > Those files are installed with the zz_ prefix to make sure they are
> > > 

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-21 01:01, Mikulas Patocka wrote:
> 
> 
> On Tue, 21 Nov 2017, Aurelien Jarno wrote:
> 
> > On 2017-11-21 00:12, Mikulas Patocka wrote:
> > > 
> > > 
> > > On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> > > 
> > > > On 2017-11-20 19:13, Mikulas Patocka wrote:
> > > > > Package: libc6-amd64
> > > > > Version: 2.25-1
> > > > > Severity: critical
> > > > > Justification: breaks the whole system
> > > > > 
> > > > > Dear Maintainer,
> > > > > 
> > > > > *** Reporter, please consider answering these questions, where 
> > > > > appropriate ***
> > > > > 
> > > > >* What led up to the situation?
> > > > > 
> > > > > I have a x86-64 system with i386 and x32 foreign architectures 
> > > > > (because I
> > > > > need to develop software for i386 and x32 architectures).
> > > > > 
> > > > >* What exactly did you do (or not do) that was effective (or
> > > > >  ineffective)?
> > > > > 
> > > > > I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> > > > > 
> > > > >* What was the outcome of this action?
> > > > > 
> > > > > Halfway through apt upgrade it failed and I ended up with unusable 
> > > > > system where
> > > > > large number of binaries were segfauting on startup without doign 
> > > > > anything.
> > > > > 
> > > > >* What outcome did you expect instead?
> > > > > 
> > > > > The upgrade to libc-2.25 should work.
> > > > > 
> > > > > 
> > > > > The reason for the catastrophic failure is this:
> > > > > 
> > > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > > 
> > > > I guess you mean you have installed one of the two, not both.
> > > > 
> > > > > x86-64 libc in /lib64/). This package is not technically needed 
> > > > > (because
> > > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > > > installed nonetheless because of some dependencies.
> > > > 
> > > > Just to be clear, as said in my other email, this *is* technically
> > > > needed as gcc-multilib is not able to make use of the libc in
> > > > /lib/x86_64-linux-gnu.
> > > > 
> > > > > apt makes sure that all libc packages are upgraded at once to the same
> > > > > version. However, during the upgrade process, the package
> > > > > libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
> > > > > temporarily have two libcs with different versions on the system, and 
> > > > > this
> > > > > mismatch makes most of the x86-64 binaries crash. Due to the crashes, 
> > > > > the
> > > > > upgrade doesn't proceed and it doesn't install the correct libc 
> > > > > version in
> > > > > /lib/x86_64-linux-gnu/.
> > > > > 
> > > > > The result is unusable system.
> > > > 
> > > > I have done some tests, and while I confirm that libc6-i386:amd64 is
> > > 
> > > The problem is with libc6-amd64:i386 or libc6-amd64:x32.
> > > Not libc6-i386:amd64.
> > 
> > Yes, sorry about that, I really did the test with libc6-amd64:i386, but
> > mixed it when typing the mail.
> > 
> > > I.e. use amd64 Debian Sid base installation, add foreign architectures 
> > > i386 and x32 and use this /etc/apt/sources.list:
> > > 
> > > deb [ arch=i386,amd64 ] http://ftp.cz.debian.org/debian/ sid main contrib 
> > > non-free
> > > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unreleased main
> > > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unstable main
> > > 
> > > > unpacked much before libc6:amd64, it doesn't cause any issue here.
> > > > Indeed the search path in ld.so is to give higher priority to
> > > > /lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
> > > > libc6:amd64 in version 2.24 (using force-all), while keeping
> > > > libc6-amd64:i386 in version 2.25.
> > > > 
> > > > The only way to change the priority of the two path is using a
> > > > non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf or
> > > > /etc/ld.so.conf.d/*? Maybe you can share the content of this file and
> > > > this directory.
> > > 
> > > On my system, there's a file 
> > > /etc/ld.so.conf.d/zz_amd64-biarch-compat.conf 
> > > containing:
> > > 
> > > # Legacy biarch compatibility support
> > > /lib64
> > > /usr/lib64
> > > 
> > > and /etc/ld.so.conf.d/zz_i386-biarch-compat.conf containing:
> > > 
> > > # Legacy biarch compatibility support
> > > /lib32
> > > /usr/lib32
> > > 
> > > These files are created by the packages libc6-i386:x32 and 
> > > libc6-amd64:x32. They cause that /lib64 is preferred to 
> > > /lib/x86_64-linux-gnu/. If I delete these files and run ldconfig, the 
> > > linker will prefer /lib/x86_64-linux-gnu/.
> > 
> > Those files are installed with the zz_ prefix to make sure they are
> > included last, and therefore after x86_64-linux-gnu.conf. It seems to
> > be missing on your system and is probably the root of your problem. This
> > file is installed by libc6:amd64.
> > 
> > Aurelien
> 
> I have /etc/ld.so.conf.d/x86_64-linux-gnu.conf, it contains 
> # Multiarch support
> /lib/x86_64-linux-gnu
> 

Re: Bug#875927: perl: SIGUNUSED removal in glibc 2.26 changes PL_sig_name / SIG_SIZE

[Dominic Hargreaves]

On Sun, Nov 19, 2017 at 05:01:27PM +0200, Niko Tyni wrote:
> On Sun, Nov 19, 2017 at 02:38:40PM +0100, Aurelien Jarno wrote:
> 
> > Now that we have glibc 2.26 in experimental, can I ask about the status
> > of this issue? Do we have to add Breaks: against the affected perl
> > packages?
> 
> Thanks for the reminder.
> 
> I looked a bit at "fixing" libasync-interrupt-perl, noted that it uses
> SIG_SIZE for other things too and decided I don't want to spend my time
> on that.
> 
> My plan is to use the attached workaround, which should keep the ABI
> regardless of the glibc version. It should probably go to sid soon.
> 
> I don't think Breaks are needed. The issue only happens if the current
> perl gets built with the new glibc. Assuming we upload the workaround
> to sid before glibc 2.26, I think it should be fine.

Hello,

Nothing too much to add, but this sounds like a good idea.
Thanks for taking care of this!

Cheers,
Dominic.

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Tue, 21 Nov 2017, Aurelien Jarno wrote:

> On 2017-11-21 00:15, Mikulas Patocka wrote:
> > 
> > 
> > On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> > 
> > > On 2017-11-20 21:58, Mikulas Patocka wrote:
> > > > 
> > > > 
> > > > On Mon, 20 Nov 2017, Samuel Thibault wrote:
> > > > 
> > > > > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > > > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > > > > x86-64 libc in /lib64/). This package is not technically needed 
> > > > > > (because
> > > > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it 
> > > > > > is
> > > > > > installed nonetheless because of some dependencies.
> > > > > 
> > > > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not 
> > > > > new, I
> > > > > tried to do it in the past, just to see, with the same kind of effect 
> > > > > as
> > > > > you had.
> > > > > 
> > > > > The question is rather how that got pulled at all. What package thinks
> > > > > it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> > > > > (which should normally not get pulled either), I can see uc-echo which
> > > > > should rather use foreign dependencies, and :i386 multilib packages
> > > > > which don't really make sense to install either.
> > > > > 
> > > > > I don't remember whether it was tried to make libc6-amd64:i386 
> > > > > conflict
> > > > > with libc6:amd64 (and vice-versa for i386) to make sure that this
> > > > > doesn't happen by misfortune?
> > > > > 
> > > > > Samuel
> > > > 
> > > > libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, 
> > > > lib64asan3, 
> > > > lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, 
> > > > lib64itm1, 
> > > > lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64.
> > > > 
> > > > If you install gcc-7-multilib for non-default architecture (i386 or 
> > > > x32), 
> > > > it will inevitably pull libc6-amd64.
> > > 
> > > What's the point of doing that, as opposed for example building with
> > > -m32 or mx32?
> > 
> > The native x32 gcc binary is about 10% faster than the amd64 binary.
> 
> In that case you can install only gcc-7:x32 instead of gcc-7-multilib:x32,
> which won't pull libc6-amd64:x32.

But then, it won't be able to build i386 and amd64 binaries.

Mikulas

> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
> 

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Tue, 21 Nov 2017, Aurelien Jarno wrote:

> On 2017-11-21 00:12, Mikulas Patocka wrote:
> > 
> > 
> > On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> > 
> > > On 2017-11-20 19:13, Mikulas Patocka wrote:
> > > > Package: libc6-amd64
> > > > Version: 2.25-1
> > > > Severity: critical
> > > > Justification: breaks the whole system
> > > > 
> > > > Dear Maintainer,
> > > > 
> > > > *** Reporter, please consider answering these questions, where 
> > > > appropriate ***
> > > > 
> > > >* What led up to the situation?
> > > > 
> > > > I have a x86-64 system with i386 and x32 foreign architectures (because 
> > > > I
> > > > need to develop software for i386 and x32 architectures).
> > > > 
> > > >* What exactly did you do (or not do) that was effective (or
> > > >  ineffective)?
> > > > 
> > > > I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> > > > 
> > > >* What was the outcome of this action?
> > > > 
> > > > Halfway through apt upgrade it failed and I ended up with unusable 
> > > > system where
> > > > large number of binaries were segfauting on startup without doign 
> > > > anything.
> > > > 
> > > >* What outcome did you expect instead?
> > > > 
> > > > The upgrade to libc-2.25 should work.
> > > > 
> > > > 
> > > > The reason for the catastrophic failure is this:
> > > > 
> > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > 
> > > I guess you mean you have installed one of the two, not both.
> > > 
> > > > x86-64 libc in /lib64/). This package is not technically needed (because
> > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > > installed nonetheless because of some dependencies.
> > > 
> > > Just to be clear, as said in my other email, this *is* technically
> > > needed as gcc-multilib is not able to make use of the libc in
> > > /lib/x86_64-linux-gnu.
> > > 
> > > > apt makes sure that all libc packages are upgraded at once to the same
> > > > version. However, during the upgrade process, the package
> > > > libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
> > > > temporarily have two libcs with different versions on the system, and 
> > > > this
> > > > mismatch makes most of the x86-64 binaries crash. Due to the crashes, 
> > > > the
> > > > upgrade doesn't proceed and it doesn't install the correct libc version 
> > > > in
> > > > /lib/x86_64-linux-gnu/.
> > > > 
> > > > The result is unusable system.
> > > 
> > > I have done some tests, and while I confirm that libc6-i386:amd64 is
> > 
> > The problem is with libc6-amd64:i386 or libc6-amd64:x32.
> > Not libc6-i386:amd64.
> 
> Yes, sorry about that, I really did the test with libc6-amd64:i386, but
> mixed it when typing the mail.
> 
> > I.e. use amd64 Debian Sid base installation, add foreign architectures 
> > i386 and x32 and use this /etc/apt/sources.list:
> > 
> > deb [ arch=i386,amd64 ] http://ftp.cz.debian.org/debian/ sid main contrib 
> > non-free
> > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unreleased main
> > deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unstable main
> > 
> > > unpacked much before libc6:amd64, it doesn't cause any issue here.
> > > Indeed the search path in ld.so is to give higher priority to
> > > /lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
> > > libc6:amd64 in version 2.24 (using force-all), while keeping
> > > libc6-amd64:i386 in version 2.25.
> > > 
> > > The only way to change the priority of the two path is using a
> > > non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf or
> > > /etc/ld.so.conf.d/*? Maybe you can share the content of this file and
> > > this directory.
> > 
> > On my system, there's a file /etc/ld.so.conf.d/zz_amd64-biarch-compat.conf 
> > containing:
> > 
> > # Legacy biarch compatibility support
> > /lib64
> > /usr/lib64
> > 
> > and /etc/ld.so.conf.d/zz_i386-biarch-compat.conf containing:
> > 
> > # Legacy biarch compatibility support
> > /lib32
> > /usr/lib32
> > 
> > These files are created by the packages libc6-i386:x32 and 
> > libc6-amd64:x32. They cause that /lib64 is preferred to 
> > /lib/x86_64-linux-gnu/. If I delete these files and run ldconfig, the 
> > linker will prefer /lib/x86_64-linux-gnu/.
> 
> Those files are installed with the zz_ prefix to make sure they are
> included last, and therefore after x86_64-linux-gnu.conf. It seems to
> be missing on your system and is probably the root of your problem. This
> file is installed by libc6:amd64.
> 
> Aurelien

I have /etc/ld.so.conf.d/x86_64-linux-gnu.conf, it contains 
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

But nonetheless, the linker prefers libc from /lib64.

I have these files in /etc/ld.so.conf.d:

i386-linux-gnu.conf:# Multiarch support
i386-linux-gnu.conf:/lib/i386-linux-gnu
i386-linux-gnu.conf:/usr/lib/i386-linux-gnu
i386-linux-gnu.conf:/lib/i686-linux-gnu
i386-linux-gnu.conf:/usr/lib/i686-linux-gnu

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-21 00:12, Mikulas Patocka wrote:
> 
> 
> On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> 
> > On 2017-11-20 19:13, Mikulas Patocka wrote:
> > > Package: libc6-amd64
> > > Version: 2.25-1
> > > Severity: critical
> > > Justification: breaks the whole system
> > > 
> > > Dear Maintainer,
> > > 
> > > *** Reporter, please consider answering these questions, where 
> > > appropriate ***
> > > 
> > >* What led up to the situation?
> > > 
> > > I have a x86-64 system with i386 and x32 foreign architectures (because I
> > > need to develop software for i386 and x32 architectures).
> > > 
> > >* What exactly did you do (or not do) that was effective (or
> > >  ineffective)?
> > > 
> > > I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> > > 
> > >* What was the outcome of this action?
> > > 
> > > Halfway through apt upgrade it failed and I ended up with unusable system 
> > > where
> > > large number of binaries were segfauting on startup without doign 
> > > anything.
> > > 
> > >* What outcome did you expect instead?
> > > 
> > > The upgrade to libc-2.25 should work.
> > > 
> > > 
> > > The reason for the catastrophic failure is this:
> > > 
> > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > 
> > I guess you mean you have installed one of the two, not both.
> > 
> > > x86-64 libc in /lib64/). This package is not technically needed (because
> > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > installed nonetheless because of some dependencies.
> > 
> > Just to be clear, as said in my other email, this *is* technically
> > needed as gcc-multilib is not able to make use of the libc in
> > /lib/x86_64-linux-gnu.
> > 
> > > apt makes sure that all libc packages are upgraded at once to the same
> > > version. However, during the upgrade process, the package
> > > libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
> > > temporarily have two libcs with different versions on the system, and this
> > > mismatch makes most of the x86-64 binaries crash. Due to the crashes, the
> > > upgrade doesn't proceed and it doesn't install the correct libc version in
> > > /lib/x86_64-linux-gnu/.
> > > 
> > > The result is unusable system.
> > 
> > I have done some tests, and while I confirm that libc6-i386:amd64 is
> 
> The problem is with libc6-amd64:i386 or libc6-amd64:x32.
> Not libc6-i386:amd64.

Yes, sorry about that, I really did the test with libc6-amd64:i386, but
mixed it when typing the mail.

> I.e. use amd64 Debian Sid base installation, add foreign architectures 
> i386 and x32 and use this /etc/apt/sources.list:
> 
> deb [ arch=i386,amd64 ] http://ftp.cz.debian.org/debian/ sid main contrib 
> non-free
> deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unreleased main
> deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unstable main
> 
> > unpacked much before libc6:amd64, it doesn't cause any issue here.
> > Indeed the search path in ld.so is to give higher priority to
> > /lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
> > libc6:amd64 in version 2.24 (using force-all), while keeping
> > libc6-amd64:i386 in version 2.25.
> > 
> > The only way to change the priority of the two path is using a
> > non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf or
> > /etc/ld.so.conf.d/*? Maybe you can share the content of this file and
> > this directory.
> 
> On my system, there's a file /etc/ld.so.conf.d/zz_amd64-biarch-compat.conf 
> containing:
> 
> # Legacy biarch compatibility support
> /lib64
> /usr/lib64
> 
> and /etc/ld.so.conf.d/zz_i386-biarch-compat.conf containing:
> 
> # Legacy biarch compatibility support
> /lib32
> /usr/lib32
> 
> These files are created by the packages libc6-i386:x32 and 
> libc6-amd64:x32. They cause that /lib64 is preferred to 
> /lib/x86_64-linux-gnu/. If I delete these files and run ldconfig, the 
> linker will prefer /lib/x86_64-linux-gnu/.

Those files are installed with the zz_ prefix to make sure they are
included last, and therefore after x86_64-linux-gnu.conf. It seems to
be missing on your system and is probably the root of your problem. This
file is installed by libc6:amd64.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-21 00:15, Mikulas Patocka wrote:
> 
> 
> On Mon, 20 Nov 2017, Aurelien Jarno wrote:
> 
> > On 2017-11-20 21:58, Mikulas Patocka wrote:
> > > 
> > > 
> > > On Mon, 20 Nov 2017, Samuel Thibault wrote:
> > > 
> > > > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > > > x86-64 libc in /lib64/). This package is not technically needed 
> > > > > (because
> > > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > > > installed nonetheless because of some dependencies.
> > > > 
> > > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
> > > > tried to do it in the past, just to see, with the same kind of effect as
> > > > you had.
> > > > 
> > > > The question is rather how that got pulled at all. What package thinks
> > > > it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> > > > (which should normally not get pulled either), I can see uc-echo which
> > > > should rather use foreign dependencies, and :i386 multilib packages
> > > > which don't really make sense to install either.
> > > > 
> > > > I don't remember whether it was tried to make libc6-amd64:i386 conflict
> > > > with libc6:amd64 (and vice-versa for i386) to make sure that this
> > > > doesn't happen by misfortune?
> > > > 
> > > > Samuel
> > > 
> > > libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, 
> > > lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, 
> > > lib64itm1, 
> > > lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64.
> > > 
> > > If you install gcc-7-multilib for non-default architecture (i386 or x32), 
> > > it will inevitably pull libc6-amd64.
> > 
> > What's the point of doing that, as opposed for example building with
> > -m32 or mx32?
> 
> The native x32 gcc binary is about 10% faster than the amd64 binary.

In that case you can install only gcc-7:x32 instead of gcc-7-multilib:x32,
which won't pull libc6-amd64:x32.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Mon, 20 Nov 2017, Aurelien Jarno wrote:

> On 2017-11-20 21:58, Mikulas Patocka wrote:
> > 
> > 
> > On Mon, 20 Nov 2017, Samuel Thibault wrote:
> > 
> > > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > > x86-64 libc in /lib64/). This package is not technically needed (because
> > > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > > installed nonetheless because of some dependencies.
> > > 
> > > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
> > > tried to do it in the past, just to see, with the same kind of effect as
> > > you had.
> > > 
> > > The question is rather how that got pulled at all. What package thinks
> > > it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> > > (which should normally not get pulled either), I can see uc-echo which
> > > should rather use foreign dependencies, and :i386 multilib packages
> > > which don't really make sense to install either.
> > > 
> > > I don't remember whether it was tried to make libc6-amd64:i386 conflict
> > > with libc6:amd64 (and vice-versa for i386) to make sure that this
> > > doesn't happen by misfortune?
> > > 
> > > Samuel
> > 
> > libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, 
> > lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, lib64itm1, 
> > lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64.
> > 
> > If you install gcc-7-multilib for non-default architecture (i386 or x32), 
> > it will inevitably pull libc6-amd64.
> 
> What's the point of doing that, as opposed for example building with
> -m32 or mx32?

The native x32 gcc binary is about 10% faster than the amd64 binary.

> > If we removed libc6-amd64 at all, it would cause problems building amd64 
> > packages on i386 system. We could make those lib64* packages dependent on 
> > libc6:amd64 instead, but that would break if the user has i386 
> > installation and he doesn't have amd64 foreign architecture set up.
> > 
> > It would be best to set it up so that libc6-amd64 doesn't install any 
> > files only if libc6:amd64 is present. Could it be done with the deb 
> > format?
> 
> It's not something possible, and it's even more complicated than that.
> The current ugly way the multiarch + multilib is done, uses a different
> libc for linking and executing. So you definitely need to install both
> if you want to be able to build and execute code.
> 
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net

Mikulas

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Mon, 20 Nov 2017, Aurelien Jarno wrote:

> On 2017-11-20 19:13, Mikulas Patocka wrote:
> > Package: libc6-amd64
> > Version: 2.25-1
> > Severity: critical
> > Justification: breaks the whole system
> > 
> > Dear Maintainer,
> > 
> > *** Reporter, please consider answering these questions, where appropriate 
> > ***
> > 
> >* What led up to the situation?
> > 
> > I have a x86-64 system with i386 and x32 foreign architectures (because I
> > need to develop software for i386 and x32 architectures).
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> > I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> > 
> >* What was the outcome of this action?
> > 
> > Halfway through apt upgrade it failed and I ended up with unusable system 
> > where
> > large number of binaries were segfauting on startup without doign anything.
> > 
> >* What outcome did you expect instead?
> > 
> > The upgrade to libc-2.25 should work.
> > 
> > 
> > The reason for the catastrophic failure is this:
> > 
> > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> 
> I guess you mean you have installed one of the two, not both.
> 
> > x86-64 libc in /lib64/). This package is not technically needed (because
> > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > installed nonetheless because of some dependencies.
> 
> Just to be clear, as said in my other email, this *is* technically
> needed as gcc-multilib is not able to make use of the libc in
> /lib/x86_64-linux-gnu.
> 
> > apt makes sure that all libc packages are upgraded at once to the same
> > version. However, during the upgrade process, the package
> > libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
> > temporarily have two libcs with different versions on the system, and this
> > mismatch makes most of the x86-64 binaries crash. Due to the crashes, the
> > upgrade doesn't proceed and it doesn't install the correct libc version in
> > /lib/x86_64-linux-gnu/.
> > 
> > The result is unusable system.
> 
> I have done some tests, and while I confirm that libc6-i386:amd64 is

The problem is with libc6-amd64:i386 or libc6-amd64:x32.
Not libc6-i386:amd64.

I.e. use amd64 Debian Sid base installation, add foreign architectures 
i386 and x32 and use this /etc/apt/sources.list:

deb [ arch=i386,amd64 ] http://ftp.cz.debian.org/debian/ sid main contrib 
non-free
deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unreleased main
deb [ arch=x32 ] http://ftp.de.debian.org/debian-ports/ unstable main

> unpacked much before libc6:amd64, it doesn't cause any issue here.
> Indeed the search path in ld.so is to give higher priority to
> /lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
> libc6:amd64 in version 2.24 (using force-all), while keeping
> libc6-amd64:i386 in version 2.25.
> 
> The only way to change the priority of the two path is using a
> non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf or
> /etc/ld.so.conf.d/*? Maybe you can share the content of this file and
> this directory.
> 
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net

On my system, there's a file /etc/ld.so.conf.d/zz_amd64-biarch-compat.conf 
containing:

# Legacy biarch compatibility support
/lib64
/usr/lib64

and /etc/ld.so.conf.d/zz_i386-biarch-compat.conf containing:

# Legacy biarch compatibility support
/lib32
/usr/lib32

These files are created by the packages libc6-i386:x32 and 
libc6-amd64:x32. They cause that /lib64 is preferred to 
/lib/x86_64-linux-gnu/. If I delete these files and run ldconfig, the 
linker will prefer /lib/x86_64-linux-gnu/.

Mikulas

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-20 19:13, Mikulas Patocka wrote:
> Package: libc6-amd64
> Version: 2.25-1
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> I have a x86-64 system with i386 and x32 foreign architectures (because I
> need to develop software for i386 and x32 architectures).
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.
> 
>* What was the outcome of this action?
> 
> Halfway through apt upgrade it failed and I ended up with unusable system 
> where
> large number of binaries were segfauting on startup without doign anything.
> 
>* What outcome did you expect instead?
> 
> The upgrade to libc-2.25 should work.
> 
> 
> The reason for the catastrophic failure is this:
> 
> There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide

I guess you mean you have installed one of the two, not both.

> x86-64 libc in /lib64/). This package is not technically needed (because
> x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> installed nonetheless because of some dependencies.

Just to be clear, as said in my other email, this *is* technically
needed as gcc-multilib is not able to make use of the libc in
/lib/x86_64-linux-gnu.

> apt makes sure that all libc packages are upgraded at once to the same
> version. However, during the upgrade process, the package
> libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
> temporarily have two libcs with different versions on the system, and this
> mismatch makes most of the x86-64 binaries crash. Due to the crashes, the
> upgrade doesn't proceed and it doesn't install the correct libc version in
> /lib/x86_64-linux-gnu/.
> 
> The result is unusable system.

I have done some tests, and while I confirm that libc6-i386:amd64 is
unpacked much before libc6:amd64, it doesn't cause any issue here.
Indeed the search path in ld.so is to give higher priority to
/lib/x86_64-linux-gnu/ over /lib64. I have even been able to install
libc6:amd64 in version 2.24 (using force-all), while keeping
libc6-amd64:i386 in version 2.25.

The only way to change the priority of the two path is using a
non-standard ld.so.conf. Have you made any change to /etc/ld.so.conf or
/etc/ld.so.conf.d/*? Maybe you can share the content of this file and
this directory.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-20 21:58, Mikulas Patocka wrote:
> 
> 
> On Mon, 20 Nov 2017, Samuel Thibault wrote:
> 
> > Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > > x86-64 libc in /lib64/). This package is not technically needed (because
> > > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > > installed nonetheless because of some dependencies.
> > 
> > The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
> > tried to do it in the past, just to see, with the same kind of effect as
> > you had.
> > 
> > The question is rather how that got pulled at all. What package thinks
> > it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> > (which should normally not get pulled either), I can see uc-echo which
> > should rather use foreign dependencies, and :i386 multilib packages
> > which don't really make sense to install either.
> > 
> > I don't remember whether it was tried to make libc6-amd64:i386 conflict
> > with libc6:amd64 (and vice-versa for i386) to make sure that this
> > doesn't happen by misfortune?
> > 
> > Samuel
> 
> libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, 
> lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, lib64itm1, 
> lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64.
> 
> If you install gcc-7-multilib for non-default architecture (i386 or x32), 
> it will inevitably pull libc6-amd64.

What's the point of doing that, as opposed for example building with
-m32 or mx32?

> If we removed libc6-amd64 at all, it would cause problems building amd64 
> packages on i386 system. We could make those lib64* packages dependent on 
> libc6:amd64 instead, but that would break if the user has i386 
> installation and he doesn't have amd64 foreign architecture set up.
> 
> It would be best to set it up so that libc6-amd64 doesn't install any 
> files only if libc6:amd64 is present. Could it be done with the deb 
> format?

It's not something possible, and it's even more complicated than that.
The current ugly way the multiarch + multilib is done, uses a different
libc for linking and executing. So you definitely need to install both
if you want to be able to build and execute code.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#882272: libc6:amd64: upgrade of libc6:amd64 + libc6:i386 + libc6-i686 breaks system

[Stepan Golosunov]

Package: libc6
Version: 2.24-11+deb9u1
Severity: critical
Justification: breaks the whole system


Upgrade of glibc packages from jessie to stretch versions failed
resulting in most programs (presumably all non-static 32-bit ones) to
segfault on start. I believe the following happend:
1. libc6:i386 and libc6:amd64 2.24-11+deb9u1 were unpacked,
/etc/ld.so.nohwcap was created by preinst scripts.
2. postinst of libc6:amd64 started running and removed
/etc/ld.so.nohwcap (as $hwcappkgs is empty for amd64).
3. As libc6-i686 2.19-18+deb8u10 was still installed most applications
started segfaulting (including most essential ones).

Unfortunately, I did not have any root shell open, and while
export LD_HWCAP_MASK=0
workaround worked on many applications, it had no effect on setuid
programs (like su and sudo). I had to resolve the problem by rebooting
system with break=init argument and running
touch /root/etc/ld.so.nohwcap
from initramfs shell (and later calling
dpkg --purge libc6-i686
before finishing upgrade of libc6:amd64).

This probably should be fixed by replacing

case ${DPKG_MAINTSCRIPT_ARCH} in
alpha)
hwcappkgs="libc6-alphaev67"
;;
i386)
hwcappkgs="libc6-i686 libc6-xen"
;;
kfreebsd-i386)
hwcappkgs="libc0.1-i686"
;;
esac

with something like

hwcappkgs="libc6-alphaev67 libc6-i686 libc6-xen libc0.1-i686"

or

hwcappkgs="libc6.1-alphaev67:alpha libc6-i686:i386 libc6-xen:i386 
libc0.1-i686:kfreebsd-i386"

in debian/script.in/nohwcap.sh.


sghpc% sudo apt upgrade
Чтение списков пакетов… Готово
Построение дерева зависимостей   
Чтение информации о состоянии… Готово
Расчёт обновлений…Следующие пакеты устанавливались автоматически и больше не 
требуются:
  aumix aumix-common bzip2-doc gdb-doc libc6-i686 
linux-image-3.16.0-4-amd64:amd64 linux-image-4.9.0-3-amd64-dbg:amd64
  python-networkx python-pygraphviz python-skimage python-skimage-lib
Для их удаления используйте «apt-get autoremove».
Готово
НОВЫЕ пакеты, которые будут установлены:
  libc-l10n
Пакеты, которые будут оставлены в неизменном виде:
  geeqie geeqie-common geeqie-dbg
Пакеты, которые будут обновлены:
  glibc-doc libc-bin libc-dev-bin libc6 libc6:amd64 libc6-dbg libc6-dbg:amd64 
libc6-dev libc6-i686 locales locales-all
  multiarch-support
обновлено 12, установлено 1 новых пакетов, для удаления отмечено 0 пакетов, и 3 
пакетов не обновлено.
Необходимо скачать 0 B/44,6 MB архивов.
После данной операции, объём занятого дискового пространства уменьшится на 9 
642 kB.
Хотите продолжить? [Д/н] 
Чтение журнала изменений... Выполнено 
apt-listchanges: Хотите продолжить? [Y/n] 
apt-listchanges: Отправка почты root: apt-listchanges: журнал изменений sghpc
apt-listchanges: Отправка почты root: apt-listchanges: новости о sghpc
Предварительная настройка пакетов ...
(Чтение базы данных … на данный момент установлено 803482 файла и каталога.)
Подготовка к распаковке …/locales_2.24-11+deb9u1_all.deb …
Распаковывается locales (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Выбор ранее не выбранного пакета libc-l10n.
Подготовка к распаковке …/libc-l10n_2.24-11+deb9u1_all.deb …
Распаковывается libc-l10n (2.24-11+deb9u1) …
Подготовка к распаковке …/locales-all_2.24-11+deb9u1_i386.deb …
Распаковывается locales-all (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Подготовка к распаковке …/libc6_2.24-11+deb9u1_i386.deb …
Деконфигурируется libc6:amd64 (2.19-18+deb8u10) …
Checking for services that may need to be restarted...
Checking init 
scripts...##.]
 
Распаковывается libc6:i386 (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Подготовка к распаковке …/libc6_2.24-11+deb9u1_amd64.deb 
….] 
Checking for services that may need to be 
restarted]
 
Checking init scripts...
Распаковывается libc6:amd64 (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Настраивается пакет libc6:amd64 (2.24-11+deb9u1) 
….] 
dpkg: ошибка при обработке пакета libc6:amd64 
(--configure):...] 
 подпроцесс установлен сценарий post-installation уничтожен по сигналу (Ошибка 
сегментирования)
Настраивается пакет libc6:i386 (2.24-11+deb9u1) …
Устанавливается новая версия файла настройки 
/etc/ld.so.conf.d/i386-linux-gnu.conf …
dpkg: ошибка при обработке пакета libc6:i386 
(--configure):] 
 подпроцесс установлен сценарий post-installation уничтожен по сигналу (Ошибка 
сегментирования)
При обработке следующих пакетов произошли ошибки:
 libc6:amd64
 libc6:i386
E: Sub-process /usr/bin/dpkg returned an error code (1)
E: Problem executing scripts DPkg::Post-Invoke 

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

On Mon, 20 Nov 2017, Samuel Thibault wrote:

> Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > x86-64 libc in /lib64/). This package is not technically needed (because
> > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > installed nonetheless because of some dependencies.
> 
> The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
> tried to do it in the past, just to see, with the same kind of effect as
> you had.
> 
> The question is rather how that got pulled at all. What package thinks
> it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> (which should normally not get pulled either), I can see uc-echo which
> should rather use foreign dependencies, and :i386 multilib packages
> which don't really make sense to install either.
> 
> I don't remember whether it was tried to make libc6-amd64:i386 conflict
> with libc6:amd64 (and vice-versa for i386) to make sure that this
> doesn't happen by misfortune?
> 
> Samuel

libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3, 
lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, lib64itm1, 
lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64.

If you install gcc-7-multilib for non-default architecture (i386 or x32), 
it will inevitably pull libc6-amd64.

If we removed libc6-amd64 at all, it would cause problems building amd64 
packages on i386 system. We could make those lib64* packages dependent on 
libc6:amd64 instead, but that would break if the user has i386 
installation and he doesn't have amd64 foreign architecture set up.

It would be best to set it up so that libc6-amd64 doesn't install any 
files only if libc6:amd64 is present. Could it be done with the deb 
format?

Mikulas

Processed: reassign 882223 to glibc-doc

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # match possible intention of reporter
> reassign 882223 glibc-doc
Bug #882223 [manpages-dev] Document security problems with system.3 and popen.3 
(argument injection)
Bug reassigned from package 'manpages-dev' to 'glibc-doc'.
No longer marked as found in versions manpages/4.13-3.
Ignoring request to alter fixed versions of bug #882223 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
882223: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882223
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#882263: libc6-dev-mips64el-cross breaks linking executables

[Helmut Grohne]

Package: libc6-dev-mips64el-cross
Version: 20
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

I was trying to use gcc-mips64el-linux-gnuabi64 to link a trivial
executable:

$ echo 'int main(){return 0;}' | mips64el-linux-gnuabi64-gcc -x c - -o /dev/null

With libc6-dev:mips64el installed, this just works. As soon as I install
libc6-dev-mips64el-cross, it fails though:

/usr/lib/gcc-cross/mips64el-linux-gnuabi64/7/../../../../mips64el-linux-gnuabi64/bin/ld:
 cannot find /usr/mips64el-linux-gnuabi64/lib/ld.so.1
collect2: error: ld returned 1 exit status

This renders libc6-dev-mips64el-cross pretty much useless.

Helmut

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Aurelien Jarno]

On 2017-11-20 20:47, Samuel Thibault wrote:
> Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > x86-64 libc in /lib64/). This package is not technically needed (because
> > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > installed nonetheless because of some dependencies.
> 
> The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
> tried to do it in the past, just to see, with the same kind of effect as
> you had.
> 
> The question is rather how that got pulled at all. What package thinks
> it's a good idea to pull libc6-amd64?  Apart from libc64* packages
> (which should normally not get pulled either), I can see uc-echo which
> should rather use foreign dependencies, and :i386 multilib packages
> which don't really make sense to install either.
> 
> I don't remember whether it was tried to make libc6-amd64:i386 conflict
> with libc6:amd64 (and vice-versa for i386) to make sure that this
> doesn't happen by misfortune?

Arch-qualified conflicts are not supported. What you can do is make
libc6-amd64 and libc6:amd64 not coinstallable (by changing the Replaces
into a Conflicts). Maybe it's time to do it and let GCC enjoy multiarch
+ multilib pain.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Processed: found 882255 in 2.24-1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 882255 2.24-1
Bug #882255 [libc6-amd64] libc6-amd64: Multilib causes catastrophic system 
failure during upgrade to libc 2.25
Marked as found in versions glibc/2.24-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
882255: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882255
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Samuel Thibault]

Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> x86-64 libc in /lib64/). This package is not technically needed (because
> x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> installed nonetheless because of some dependencies.

The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
tried to do it in the past, just to see, with the same kind of effect as
you had.

The question is rather how that got pulled at all. What package thinks
it's a good idea to pull libc6-amd64?  Apart from libc64* packages
(which should normally not get pulled either), I can see uc-echo which
should rather use foreign dependencies, and :i386 multilib packages
which don't really make sense to install either.

I don't remember whether it was tried to make libc6-amd64:i386 conflict
with libc6:amd64 (and vice-versa for i386) to make sure that this
doesn't happen by misfortune?

Samuel

Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25

[Mikulas Patocka]

Package: libc6-amd64
Version: 2.25-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I have a x86-64 system with i386 and x32 foreign architectures (because I
need to develop software for i386 and x32 architectures).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I ran apt update and apt upgrade. Apt tried to upgrade to libc-2.25.

   * What was the outcome of this action?

Halfway through apt upgrade it failed and I ended up with unusable system where
large number of binaries were segfauting on startup without doign anything.

   * What outcome did you expect instead?

The upgrade to libc-2.25 should work.


The reason for the catastrophic failure is this:

There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
x86-64 libc in /lib64/). This package is not technically needed (because
x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
installed nonetheless because of some dependencies.

apt makes sure that all libc packages are upgraded at once to the same
version. However, during the upgrade process, the package
libc6-amd64 is upgraded before libc6:amd64. So, during the upgrade, we
temporarily have two libcs with different versions on the system, and this
mismatch makes most of the x86-64 binaries crash. Due to the crashes, the
upgrade doesn't proceed and it doesn't install the correct libc version in
/lib/x86_64-linux-gnu/.

The result is unusable system.

The system can be fixed if we mount it from another machine and remove the
libc files from /lib64 directory - the upgrade can then proceed and
install correct libc in /lib/x86_64-linux-gnu/.

The libc package should be fixed, so that if we have mismatching libc
version in /lib64 and in /lib/x86_64-linux-gnu/, it shouldn't crash,
because such mismatch happens temporarily during upgrade.


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 4.14.0 (SMP w/12 CPU cores; PREEMPT)
Locale: LANG=cs_CZ.utf8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8), 
LANGUAGE=cs_CZ.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc6-amd64 depends on:
ii  libc6  2.25-1

libc6-amd64 recommends no packages.

libc6-amd64 suggests no packages.

-- no debconf information

[glibc] branch glibc-2.26 updated (76460d3 -> 315855e)

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a change to branch glibc-2.26
in repository glibc.

  from  76460d3   debian/testsuite-xfail-debian.mk: Update hurd-i386 xfail 
with new test
   new  15ca994   Bump build-dependency on binutils to >= 2.25, as required 
by glibc 2.26.
   new  315855e   debian/testsuite-xfail-debian.mk: re-add double-lround 
XFAILs for mips64el.

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 debian/changelog | 5 +
 debian/control   | 2 +-
 debian/control.in/main   | 2 +-
 debian/testsuite-xfail-debian.mk | 5 +
 4 files changed, 12 insertions(+), 2 deletions(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

[glibc] branch sid updated (2aae445 -> fc93354)

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a change to branch sid
in repository glibc.

  from  2aae445   debian/control.in/main: add a Conflicts: again openrc (<< 
0.27-2~). Closes: #882129.
   new  783c16c   Fix a thinko
   new  e510ada   debian/control.in/libc: add Breaks: and Replaces against 
kfreebsd-kernel-headers (<< 10.3~4) to avoid  conflict.
   new  9ee20b8   Add symbol files for mipsn32 and mips64.
   new  fc93354   Add mipsr6, mipsr6el, mipsn32r6, mipsn32r6el, mips64r6, 
mips64r6el architectures.  Closes: #824985, #881457.

The 4 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 debian/changelog   | 11 +++-
 debian/control | 16 ++--
 debian/control.in/libc |  4 +--
 debian/control.in/mips32   |  8 +++---
 debian/control.in/mips64   |  4 +--
 debian/control.in/mipsn32  |  6 ++---
 ...ymbols.mips64el => libc6-mips32.symbols.mips64} |  0
 ...bols.mips64el => libc6-mips32.symbols.mips64r6} |  0
 ...ls.mips64el => libc6-mips32.symbols.mips64r6el} |  0
 ...mbols.mips64el => libc6-mips32.symbols.mipsn32} |  0
 ...ols.mips64el => libc6-mips32.symbols.mipsn32el} |  0
 ...ols.mips64el => libc6-mips32.symbols.mipsn32r6} |  0
 ...s.mips64el => libc6-mips32.symbols.mipsn32r6el} |  0
 ...mbols.mips64el => libc6-mips64.symbols.mipsn32} |  0
 ...ols.mips64el => libc6-mips64.symbols.mipsn32el} |  0
 ...ols.mips64el => libc6-mips64.symbols.mipsn32r6} |  0
 ...s.mips64el => libc6-mips64.symbols.mipsn32r6el} |  0
 ...ymbols.mips64el => libc6-mips64.symbols.mipsr6} |  0
 ...bols.mips64el => libc6-mips64.symbols.mipsr6el} |  0
 ...mbols.mips64el => libc6-mipsn32.symbols.mips64} |  0
 ...ols.mips64el => libc6-mipsn32.symbols.mips64r6} |  0
 ...s.mips64el => libc6-mipsn32.symbols.mips64r6el} |  0
 ...mbols.mips64el => libc6-mipsn32.symbols.mipsr6} |  0
 ...ols.mips64el => libc6-mipsn32.symbols.mipsr6el} |  0
 ...ips32.symbols.mips64el => libc6.symbols.mips64} |  0
 ...s32.symbols.mips64el => libc6.symbols.mips64r6} |  0
 ...2.symbols.mips64el => libc6.symbols.mips64r6el} |  0
 ...ps32.symbols.mips64el => libc6.symbols.mipsn32} |  0
 ...32.symbols.mips64el => libc6.symbols.mipsn32el} |  0
 ...32.symbols.mips64el => libc6.symbols.mipsn32r6} |  0
 symbols.mips64el => libc6.symbols.mipsn32r6el} |  0
 ...ips32.symbols.mips64el => libc6.symbols.mipsr6} |  0
 ...s32.symbols.mips64el => libc6.symbols.mipsr6el} |  0
 debian/rules.d/control.mk  |  3 ++-
 debian/sysdeps/{mips64el.mk => mips64r6.mk}| 26 +--
 debian/sysdeps/{mips64el.mk => mips64r6el.mk}  | 26 +--
 debian/sysdeps/{mipsn32.mk => mipsn32r6.mk}| 26 +--
 debian/sysdeps/{mipsn32.mk => mipsn32r6el.mk}  | 28 ++--
 debian/sysdeps/{mips.mk => mipsr6.mk}  | 26 +--
 debian/sysdeps/{mips.mk => mipsr6el.mk}| 30 +++---
 40 files changed, 111 insertions(+), 103 deletions(-)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mips32.symbols.mips64} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mips32.symbols.mips64r6} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mips32.symbols.mips64r6el} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mips32.symbols.mipsn32} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mips32.symbols.mipsn32el} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mips32.symbols.mipsn32r6} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => 
libc6-mips32.symbols.mipsn32r6el} (100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mips64.symbols.mipsn32} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mips64.symbols.mipsn32el} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mips64.symbols.mipsn32r6} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => 
libc6-mips64.symbols.mipsn32r6el} (100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mips64.symbols.mipsr6} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mips64.symbols.mipsr6el} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mipsn32.symbols.mips64} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mipsn32.symbols.mips64r6} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => 
libc6-mipsn32.symbols.mips64r6el} (100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mipsn32.symbols.mipsr6} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6-mipsn32.symbols.mipsr6el} 
(100%)
 copy debian/{libc6-mips32.symbols.mips64el => libc6.symbols.mips64} (100%)
 

Bug#882152: glibc: FTBFS on hppa - nptl/tst-create-detached fails due to timeout

[Aurelien Jarno]

On 2017-11-19 12:03, John David Anglin wrote:
> Source: glibc
> Version: 2.25-1
> Severity: normal
> 
> Dear Maintainer,
> 
> The nptl/tst-create-detached test fails on hppa with a TIMEOUTFACTOR of
> 25.  Either the timeout value for the test needs to be increased from 100
> to about 500, or the test needs to be xfailed.  I think we need about a
> factor 4 or 5 increase for the slower buildd machines.
> 
> Full log is here:
> https://buildd.debian.org/status/fetch.php?pkg=glibc=hppa=2.25-1=1511033278=0

I am not really in favor of increasing TIMEOUTFACTOR, as it
significantly increase the build time on some architectures. On the
other hand, the following patch has been merged in the 2.26 release,
which increases the timeout before TIMEOUTFACTOR from 20 to 100:

https://sourceware.org/git/?p=glibc.git;a=commit;h=3cefdd7310a5d1fad45648d9346e47df9c185fdc

I will to apply it to the 2.25 release.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Processed: Bug#824985 marked as pending

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tag 824985 pending
Bug #824985 [src:glibc] glibc 2.22: add MIPS r6 support
Bug #824996 [src:glibc] glibc 2.23: add MIPS r6 support
Added tag(s) pending.
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
824985: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824985
824996: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824996
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Bug#881457 marked as pending

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tag 881457 pending
Bug #881457 [src:glibc] glibc: please add mips r6 support
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
881457: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881457
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

[glibc] 01/02: Bump build-dependency on binutils to >= 2.25, as required by glibc 2.26.

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a commit to branch glibc-2.26
in repository glibc.

commit 15ca994a3273a385982c3dbfcf9f8374beffdb8a
Author: Aurelien Jarno 
Date:   Mon Nov 20 18:13:08 2017 +0100

Bump build-dependency on binutils to >= 2.25, as required by glibc 2.26.
---
 debian/changelog   | 3 +++
 debian/control | 2 +-
 debian/control.in/main | 2 +-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index d4e3241..208c4a4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,9 @@ glibc (2.26-0experimental1) UNRELEASED; urgency=medium
   [ Samuel Thibault ]
   * debian/testsuite-xfail-debian.mk: Update hurd-i386 xfail with new test.
 
+  [ Aurelien Jarno ]
+  * Bump build-dependency on binutils to >= 2.25, as required by glibc 2.26.
+
  -- Aurelien Jarno   Sun, 19 Nov 2017 13:44:52 +0100
 
 glibc (2.26-0experimental0) experimental; urgency=medium
diff --git a/debian/control b/debian/control
index 6cb9fc0..e138fc8 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>= 
1.17.14), xz-utils, file,
  hurd-dev (>= 1:0.5.git20140320~) [hurd-i386] | hurd-headers-dev [hurd-i386],
  hurd-dev (>= 1:0.5.git20140320~) [hurd-i386]  | libihash-dev 
[hurd-i386] ,
  kfreebsd-kernel-headers [kfreebsd-any],
- binutils (>= 2.21),
+ binutils (>= 2.25),
  g++-7, g++-7-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 
mipsn32el mips64 mips64el powerpc ppc64 s390x sparc sparc64 x32],
  python3:native ,
  libc-bin (>= 2.26) 
diff --git a/debian/control.in/main b/debian/control.in/main
index de85ad9..b906330 100644
--- a/debian/control.in/main
+++ b/debian/control.in/main
@@ -9,7 +9,7 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>= 
1.17.14), xz-utils, file,
  hurd-dev (>= 1:0.5.git20140320~) [hurd-i386] | hurd-headers-dev [hurd-i386],
  hurd-dev (>= 1:0.5.git20140320~) [hurd-i386]  | libihash-dev 
[hurd-i386] ,
  kfreebsd-kernel-headers [kfreebsd-any],
- binutils (>= 2.21),
+ binutils (>= 2.25),
  g++-7, g++-7-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 
mipsn32el mips64 mips64el powerpc ppc64 s390x sparc sparc64 x32],
  python3:native ,
  libc-bin (>= @GLIBC_VERSION@) 

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

[glibc] 02/02: debian/testsuite-xfail-debian.mk: re-add double-lround XFAILs for mips64el.

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a commit to branch glibc-2.26
in repository glibc.

commit 315855e3cf37b743c07a8b89583b98b334842d89
Author: Aurelien Jarno 
Date:   Mon Nov 20 18:13:08 2017 +0100

debian/testsuite-xfail-debian.mk: re-add double-lround XFAILs for mips64el.
---
 debian/changelog | 2 ++
 debian/testsuite-xfail-debian.mk | 5 +
 2 files changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 208c4a4..b8b8faf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,8 @@ glibc (2.26-0experimental1) UNRELEASED; urgency=medium
 
   [ Aurelien Jarno ]
   * Bump build-dependency on binutils to >= 2.25, as required by glibc 2.26.
+  * debian/testsuite-xfail-debian.mk: re-add double-lround XFAILs for
+mips64el.
 
  -- Aurelien Jarno   Sun, 19 Nov 2017 13:44:52 +0100
 
diff --git a/debian/testsuite-xfail-debian.mk b/debian/testsuite-xfail-debian.mk
index 9d2742e..001ddd2 100644
--- a/debian/testsuite-xfail-debian.mk
+++ b/debian/testsuite-xfail-debian.mk
@@ -809,6 +809,11 @@ test-xfail-tst-cond16 = yes
 test-xfail-tst-mqueue5 = yes
 test-xfail-tst-stack4 = yes
 test-xfail-tst-waitid = yes
+
+# These failures are due to a bug in the Loongson 3A FPU
+test-xfail-test-double-lround = yes
+test-xfail-test-double-finite-lround = yes
+test-xfail-test-idouble-lround = yes
 endif
 
 

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

[glibc] 03/04: Add symbol files for mipsn32 and mips64.

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a commit to branch sid
in repository glibc.

commit 9ee20b88619ca204ed534730d483968e5814a9fd
Author: Aurelien Jarno 
Date:   Mon Nov 20 18:10:03 2017 +0100

Add symbol files for mipsn32 and mips64.
---
 debian/changelog| 3 +++
 debian/libc6-mips32.symbols.mips64  | 5 +
 debian/libc6-mips32.symbols.mipsn32 | 5 +
 debian/libc6-mips64.symbols.mipsn32 | 5 +
 debian/libc6-mipsn32.symbols.mips64 | 5 +
 debian/libc6.symbols.mips64 | 5 +
 debian/libc6.symbols.mipsn32| 5 +
 7 files changed, 33 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 18ca835..3bdb6e6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -8,6 +8,9 @@ glibc (2.25-2) UNRELEASED; urgency=medium
   * debian/control.in/libc: add Breaks: and Replaces against
 kfreebsd-kernel-headers (<< 10.3~4) to avoid  conflict.
 
+  [ YunQiang Su ]
+  * Add symbol files for mipsn32 and mips64.
+
  -- Aurelien Jarno   Sat, 18 Nov 2017 11:58:21 +0100
 
 glibc (2.25-1) unstable; urgency=medium
diff --git a/debian/libc6-mips32.symbols.mips64 
b/debian/libc6-mips32.symbols.mips64
new file mode 100644
index 000..5933230
--- /dev/null
+++ b/debian/libc6-mips32.symbols.mips64
@@ -0,0 +1,5 @@
+#include "libc6.symbols.common"
+ld.so.1 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
+libc.so.6 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
diff --git a/debian/libc6-mips32.symbols.mipsn32 
b/debian/libc6-mips32.symbols.mipsn32
new file mode 100644
index 000..5933230
--- /dev/null
+++ b/debian/libc6-mips32.symbols.mipsn32
@@ -0,0 +1,5 @@
+#include "libc6.symbols.common"
+ld.so.1 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
+libc.so.6 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
diff --git a/debian/libc6-mips64.symbols.mipsn32 
b/debian/libc6-mips64.symbols.mipsn32
new file mode 100644
index 000..5933230
--- /dev/null
+++ b/debian/libc6-mips64.symbols.mipsn32
@@ -0,0 +1,5 @@
+#include "libc6.symbols.common"
+ld.so.1 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
+libc.so.6 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
diff --git a/debian/libc6-mipsn32.symbols.mips64 
b/debian/libc6-mipsn32.symbols.mips64
new file mode 100644
index 000..5933230
--- /dev/null
+++ b/debian/libc6-mipsn32.symbols.mips64
@@ -0,0 +1,5 @@
+#include "libc6.symbols.common"
+ld.so.1 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
+libc.so.6 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
diff --git a/debian/libc6.symbols.mips64 b/debian/libc6.symbols.mips64
new file mode 100644
index 000..5933230
--- /dev/null
+++ b/debian/libc6.symbols.mips64
@@ -0,0 +1,5 @@
+#include "libc6.symbols.common"
+ld.so.1 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
+libc.so.6 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
diff --git a/debian/libc6.symbols.mipsn32 b/debian/libc6.symbols.mipsn32
new file mode 100644
index 000..5933230
--- /dev/null
+++ b/debian/libc6.symbols.mipsn32
@@ -0,0 +1,5 @@
+#include "libc6.symbols.common"
+ld.so.1 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
+libc.so.6 #PACKAGE# #MINVER#
+#include "symbols.wildcards"

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

[glibc] 04/04: Add mipsr6, mipsr6el, mipsn32r6, mipsn32r6el, mips64r6, mips64r6el architectures. Closes: #824985, #881457.

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a commit to branch sid
in repository glibc.

commit fc9335421a5fb7295c667ee4c029dd29ac745ddb
Author: Aurelien Jarno 
Date:   Mon Nov 20 18:10:03 2017 +0100

Add mipsr6, mipsr6el, mipsn32r6, mipsn32r6el, mips64r6, mips64r6el 
architectures.  Closes: #824985, #881457.
---
 debian/changelog|  4 ++
 debian/control.in/mips32|  8 ++--
 debian/control.in/mips64|  4 +-
 debian/control.in/mipsn32   |  6 +--
 debian/libc6-mips32.symbols.mips64r6|  5 +++
 debian/libc6-mips32.symbols.mips64r6el  |  5 +++
 debian/libc6-mips32.symbols.mipsn32el   |  5 +++
 debian/libc6-mips32.symbols.mipsn32r6   |  5 +++
 debian/libc6-mips32.symbols.mipsn32r6el |  5 +++
 debian/libc6-mips64.symbols.mipsn32el   |  5 +++
 debian/libc6-mips64.symbols.mipsn32r6   |  5 +++
 debian/libc6-mips64.symbols.mipsn32r6el |  5 +++
 debian/libc6-mips64.symbols.mipsr6  |  5 +++
 debian/libc6-mips64.symbols.mipsr6el|  5 +++
 debian/libc6-mipsn32.symbols.mips64r6   |  5 +++
 debian/libc6-mipsn32.symbols.mips64r6el |  5 +++
 debian/libc6-mipsn32.symbols.mipsr6 |  5 +++
 debian/libc6-mipsn32.symbols.mipsr6el   |  5 +++
 debian/libc6.symbols.mips64r6   |  5 +++
 debian/libc6.symbols.mips64r6el |  5 +++
 debian/libc6.symbols.mipsn32el  |  5 +++
 debian/libc6.symbols.mipsn32r6  |  5 +++
 debian/libc6.symbols.mipsn32r6el|  5 +++
 debian/libc6.symbols.mipsr6 |  5 +++
 debian/libc6.symbols.mipsr6el   |  5 +++
 debian/rules.d/control.mk   |  3 +-
 debian/sysdeps/mips64r6.mk  | 64 
 debian/sysdeps/mips64r6el.mk| 64 
 debian/sysdeps/mipsn32r6.mk | 66 +
 debian/sysdeps/mipsn32r6el.mk   | 64 
 debian/sysdeps/mipsr6.mk| 60 ++
 debian/sysdeps/mipsr6el.mk  | 60 ++
 32 files changed, 498 insertions(+), 10 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 3bdb6e6..11e766a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -11,6 +11,10 @@ glibc (2.25-2) UNRELEASED; urgency=medium
   [ YunQiang Su ]
   * Add symbol files for mipsn32 and mips64.
 
+  [ YunQiang Su / Aurelien Jarno ]
+  * Add mipsr6, mipsr6el, mipsn32r6, mipsn32r6el, mips64r6, mips64r6el
+architectures.  Closes: #824985, #881457.
+
  -- Aurelien Jarno   Sat, 18 Nov 2017 11:58:21 +0100
 
 glibc (2.25-1) unstable; urgency=medium
diff --git a/debian/control.in/mips32 b/debian/control.in/mips32
index 1d5008a..7831000 100644
--- a/debian/control.in/mips32
+++ b/debian/control.in/mips32
@@ -1,5 +1,5 @@
 Package: libc6-mips32
-Architecture: mipsn32 mipsn32el mips64 mips64el
+Architecture: mipsn32 mipsn32el mips64 mips64el mipsn32r6 mipsn32r6el mips64r6 
mips64r6el
 Section: libs
 Priority: optional
 Depends: libc6 (= ${binary:Version}), ${misc:Depends}
@@ -10,13 +10,13 @@ Description: GNU C Library: o32 Shared libraries for MIPS
  of the library, meant for MIPS systems.
 
 Package: libc6-dev-mips32
-Architecture: mipsn32 mipsn32el mips64 mips64el
+Architecture: mipsn32 mipsn32el mips64 mips64el mipsn32r6 mipsn32r6el mips64r6 
mips64r6el
 Section: libdevel
 Priority: optional
 Provides: lib32c-dev
 Depends: libc6-dev (= ${binary:Version}), libc6-mips32 (= ${binary:Version}),
-   libc6-dev-mipsn32 (= ${binary:Version}) [mips64 mips64el],
-   libc6-dev-mips64 (= ${binary:Version}) [mipsn32 mipsn32el],
+   libc6-dev-mipsn32 (= ${binary:Version}) [mips64 mips64el mips64r6 
mips64r6el],
+   libc6-dev-mips64 (= ${binary:Version}) [mipsn32 mipsn32el mipsn32r6 
mipsn32r6el],
${misc:Depends}
 Recommends: gcc-multilib
 Build-Profiles: 
diff --git a/debian/control.in/mips64 b/debian/control.in/mips64
index ec7b70c..32aa1f3 100644
--- a/debian/control.in/mips64
+++ b/debian/control.in/mips64
@@ -1,5 +1,5 @@
 Package: libc6-mips64
-Architecture: mips mipsel mipsn32 mipsn32el
+Architecture: mips mipsel mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 
mipsn32r6el
 Section: libs
 Priority: optional
 Depends: libc6 (= ${binary:Version}), ${misc:Depends}
@@ -10,7 +10,7 @@ Description: GNU C Library: 64bit Shared libraries for MIPS64
  of the library, meant for MIPS64 systems.
 
 Package: libc6-dev-mips64
-Architecture: mips mipsel mipsn32 mipsn32el
+Architecture: mips mipsel mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 
mipsn32r6el
 Section: libdevel
 Priority: optional
 Provides: lib64c-dev
diff --git a/debian/control.in/mipsn32 b/debian/control.in/mipsn32
index 019fce2..9ad5c0a 100644
--- a/debian/control.in/mipsn32
+++ b/debian/control.in/mipsn32
@@ -1,5 +1,5 @@
 Package: libc6-mipsn32
-Architecture: mips mipsel mips64 mips64el
+Architecture: mips mipsel mips64 mips64el 

[glibc] 02/04: debian/control.in/libc: add Breaks: and Replaces against kfreebsd-kernel-headers (<< 10.3~4) to avoid conflict.

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a commit to branch sid
in repository glibc.

commit e510ada65aa32b874526c6b80d7499638d666972
Author: Aurelien Jarno 
Date:   Mon Nov 20 18:10:03 2017 +0100

debian/control.in/libc: add Breaks: and Replaces against 
kfreebsd-kernel-headers (<< 10.3~4) to avoid  conflict.
---
 debian/changelog   |  2 ++
 debian/control | 16 
 debian/control.in/libc |  4 ++--
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 40ca837..18ca835 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,8 @@ glibc (2.25-2) UNRELEASED; urgency=medium
 mips/mipsel section to mips* section.
   * debian/control.in/libc: add a Conflicts: again openrc (<< 0.27-2~).
 Closes: #882129.
+  * debian/control.in/libc: add Breaks: and Replaces against
+kfreebsd-kernel-headers (<< 10.3~4) to avoid  conflict.
 
  -- Aurelien Jarno   Sat, 18 Nov 2017 11:58:21 +0100
 
diff --git a/debian/control b/debian/control
index e0e12db..d0f207d 100644
--- a/debian/control
+++ b/debian/control
@@ -194,10 +194,10 @@ Section: libdevel
 Priority: optional
 Multi-Arch: same
 Depends: libc6 (= ${binary:Version}), libc-dev-bin (= ${binary:Version}), 
${misc:Depends}, ${libc-dev:Depends}, kfreebsd-kernel-headers (>= 0.11) 
[kfreebsd-any], gnumach-dev [hurd-i386], hurd-dev (>= 20080607-3) [hurd-i386] | 
hurd-headers-dev [hurd-i386]
-Replaces: hurd-dev (<< 20120408-3) [hurd-i386]
+Replaces: hurd-dev (<< 20120408-3) [hurd-i386], kfreebsd-kernel-headers (<< 
10.3~4) [kfreebsd-amd64 kfreebsd-i386]
 Suggests: glibc-doc, manpages-dev
 Provides: libc-dev, libc6-dev [alpha hurd-i386 kfreebsd-i386 kfreebsd-amd64]
-Breaks: binutils (<< 2.26), binutils-gold (<< 2.20.1-11), cmake (<< 
2.8.4+dfsg.1-5), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2), gcc-4.6 (<< 
4.6.0-12), make (<< 3.81-8.1), pkg-config (<< 0.26-1), libjna-java (<< 
3.2.7-4), liblouis-dev (<< 2.3.0-2), liblouisxml-dev (<< 2.4.0-2), libhwloc-dev 
(<< 1.2-3), check (<< 0.9.10-6.1+b1) [s390x]
+Breaks: binutils (<< 2.26), binutils-gold (<< 2.20.1-11), cmake (<< 
2.8.4+dfsg.1-5), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2), gcc-4.6 (<< 
4.6.0-12), make (<< 3.81-8.1), pkg-config (<< 0.26-1), libjna-java (<< 
3.2.7-4), liblouis-dev (<< 2.3.0-2), liblouisxml-dev (<< 2.4.0-2), libhwloc-dev 
(<< 1.2-3), check (<< 0.9.10-6.1+b1) [s390x], kfreebsd-kernel-headers (<< 
10.3~4) [kfreebsd-amd64 kfreebsd-i386]
 Conflicts: libc6.1-dev, libc0.1-dev, libc0.3-dev,
 Description: GNU C Library: Development Libraries and Header Files
  Contains the symlinks, headers, and object files needed to compile
@@ -282,10 +282,10 @@ Section: libdevel
 Priority: optional
 Multi-Arch: same
 Depends: libc6.1 (= ${binary:Version}), libc-dev-bin (= ${binary:Version}), 
${misc:Depends}, ${libc-dev:Depends}, kfreebsd-kernel-headers (>= 0.11) 
[kfreebsd-any], gnumach-dev [hurd-i386], hurd-dev (>= 20080607-3) [hurd-i386] | 
hurd-headers-dev [hurd-i386]
-Replaces: hurd-dev (<< 20120408-3) [hurd-i386]
+Replaces: hurd-dev (<< 20120408-3) [hurd-i386], kfreebsd-kernel-headers (<< 
10.3~4) [kfreebsd-amd64 kfreebsd-i386]
 Suggests: glibc-doc, manpages-dev
 Provides: libc-dev, libc6-dev [alpha hurd-i386 kfreebsd-i386 kfreebsd-amd64]
-Breaks: binutils (<< 2.26), binutils-gold (<< 2.20.1-11), cmake (<< 
2.8.4+dfsg.1-5), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2), gcc-4.6 (<< 
4.6.0-12), make (<< 3.81-8.1), pkg-config (<< 0.26-1), libjna-java (<< 
3.2.7-4), liblouis-dev (<< 2.3.0-2), liblouisxml-dev (<< 2.4.0-2), libhwloc-dev 
(<< 1.2-3), check (<< 0.9.10-6.1+b1) [s390x]
+Breaks: binutils (<< 2.26), binutils-gold (<< 2.20.1-11), cmake (<< 
2.8.4+dfsg.1-5), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2), gcc-4.6 (<< 
4.6.0-12), make (<< 3.81-8.1), pkg-config (<< 0.26-1), libjna-java (<< 
3.2.7-4), liblouis-dev (<< 2.3.0-2), liblouisxml-dev (<< 2.4.0-2), libhwloc-dev 
(<< 1.2-3), check (<< 0.9.10-6.1+b1) [s390x], kfreebsd-kernel-headers (<< 
10.3~4) [kfreebsd-amd64 kfreebsd-i386]
 Conflicts: libc6-dev, libc0.1-dev, libc0.3-dev,
 Description: GNU C Library: Development Libraries and Header Files
  Contains the symlinks, headers, and object files needed to compile
@@ -370,10 +370,10 @@ Section: libdevel
 Priority: optional
 Multi-Arch: same
 Depends: libc0.3 (= ${binary:Version}), libc-dev-bin (= ${binary:Version}), 
${misc:Depends}, ${libc-dev:Depends}, kfreebsd-kernel-headers (>= 0.11) 
[kfreebsd-any], gnumach-dev [hurd-i386], hurd-dev (>= 20080607-3) [hurd-i386] | 
hurd-headers-dev [hurd-i386]
-Replaces: hurd-dev (<< 20120408-3) [hurd-i386]
+Replaces: hurd-dev (<< 20120408-3) [hurd-i386], kfreebsd-kernel-headers (<< 
10.3~4) [kfreebsd-amd64 kfreebsd-i386]
 Suggests: glibc-doc, manpages-dev
 Provides: libc-dev, libc6-dev [alpha hurd-i386 kfreebsd-i386 kfreebsd-amd64]
-Breaks: binutils (<< 2.26), binutils-gold (<< 2.20.1-11), cmake (<< 

[glibc] 01/04: Fix a thinko

[Aurelien Jarno]

This is an automated email from the git hooks/post-receive script.

aurel32 pushed a commit to branch sid
in repository glibc.

commit 783c16c704d38f37815d4e417657b47e9bce2e43
Author: Aurelien Jarno 
Date:   Mon Nov 20 18:10:03 2017 +0100

Fix a thinko
---
 debian/changelog | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 1902b1b..40ca837 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,7 +3,7 @@ glibc (2.25-2) UNRELEASED; urgency=medium
   [ Aurelien Jarno ]
   * debian/testsuite-xfail-debian.mk: move corner cases FPU XFAIL from
 mips/mipsel section to mips* section.
-  * debian/control.in/main: add a Conflicts: again openrc (<< 0.27-2~).
+  * debian/control.in/libc: add a Conflicts: again openrc (<< 0.27-2~).
 Closes: #882129.
 
  -- Aurelien Jarno   Sat, 18 Nov 2017 11:58:21 +0100

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git