Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

[Steve McIntyre]

Hey Aurelien,

On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote:
>
>One solution for this would be to ship the optimized library in the same
>package as the default library. Now this is not acceptable for embedded
>systems as they might not need that library and can't remove it. This is
>even more problematic if we need to add more optimized libraries. I guess
>this might be the case for arm64 as there are many new extensions in the
>pipe.

ACK. It's a problem to ship the different things in separate
packages. If it's really a problem for smaller systems to have all the
variants because of size, is there maybe another way to do things? How
about keeping the existing libc and have an extra package
("libc-optimised") with all the optimised versions *and* the basic
version, and have it provide/replace/conflict libc6?

(/me prepares to be ambarrassed as you point out the obvious flaw I'm
missing...)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect."
  -- Bruce Schneier

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

[Steve McIntyre]

On Wed, Apr 22, 2020 at 01:08:46PM -0400, Noah Meyerhans wrote:
>On Wed, Apr 22, 2020 at 05:48:27PM +0100, Steve McIntyre wrote:
>> I think the -moutline-atomics is probably good to enable by default
>> once we've got it (gcc 10). that's the suggestion I've heard from gcc
>> folks in Arm.
>
>JFTR, it's been backported to gcc 9 and is available in Debian's gcc-9
>as of 9.3.0-9. See
>https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-9-debian/debian/patches/git-updates.diff

Ah, cool. I knew it *was* being backported, but I wasn't aware it was
already with us. Woot!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

[Steve McIntyre]

Hi folks!

I'm adding a CC to Steve Capper, a colleague in Arm who's our expert
here for this kind of question. He's also a DM in Debian... :-)

On Tue, Apr 21, 2020 at 06:37:07PM -0400, Noah Meyerhans wrote:
>On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote:
>
>> It would also be nice to have numbers to see the impact on non-ARMv8.1
>> CPU on real workloads. As pointed out by Florian, and if the impact is
>> negligible, it might be a good idea to enable -moutline-atomics
>> globally at the GCC level so that all software can benefit from it, and
>> instead of only glibc. That could be either upstream or only in Debian,
>> that's probably a separate discussion. Otherwise we will likely end up
>> using this non-default GCC option on all packages that runs faster with
>> it.
>
>Agreed.

I think the -moutline-atomics is probably good to enable by default
once we've got it (gcc 10). that's the suggestion I've heard from gcc
folks in Arm.

>> Also note that the mechanism allowing a safe upgrade *does* incur a 
>> runtime overhead as every binary now has to test for the presence of
>> /etc/ld.so.nohwcap to detect a possible upgrade of the glibc in
>> progress. That's why we have disabled it on architecture not providing
>> an optimized library [1].

Oh, ick. :-/

>Thanks for the pointer, it's interesting to see data on that.  This also
>suggests that it might be worthwhile to investigate a better mechanism
>for identifying the availability of hardware features.
>
>> > I've tested both options and found them to be acceptable on v8.1a (Neoverse
>> > N1) and v8a (Cortex A72) CPUs.  I can provide bulk test run data of the
>> > various different configuration permutations if you'd like to see 
>> > additional
>> > data.
>> 
>> As said above I think we would need more numbers on real workload to
>> take a decision. Don't get me wrong I do not oppose on improving atomics
>> on ARMv8.1, but I would like that we chose the best option. Also if we
>> go with the -moutline-atomics option, I believe it rather has to be a
>> ARM porters decision than a glibc maintainers decision (hence the Cc:).
>
>I'll see what I can come up with.
>
>Do the arm porters have any opinions on this matter?

It's a good question, and thanks for asking! I definitely think it's
worth doing -moutline-atomics, and I'm hoping Steve can share some
performance numbers to help convince. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?

Bug#943798: ld.so: old Arm ABI detection patch causing problems, time to remove?

[Steve McIntyre]

On Fri, Nov 01, 2019 at 10:22:14AM +0100, Aurelien Jarno wrote:
>On 2019-10-30 00:17, Steve McIntyre wrote:
>> Source: glibc
>> Version: 2.28-10
>> Severity: important
>> 
>> Hi folks,
>> 
>> It looks like my old Arm ABI detection patch for ld.so is causing
>> problems for people using LLVM. I've been contacted by a developer,
>> referring to a mailing list thread:
>> 
>>   https://lists.llvm.org/pipermail/llvm-dev/2019-October/135993.html
>> 
>> It looks like the LLVM version of strip is more aggressive than the
>> GNU binutils version, and this is causing problems - it's stripping
>> the .ARM.attributes data and that's causing problems with our extra
>> checks for the Tag_ABI_VFP_args setting. Whether that's a valid thing
>> to do or not is an argument for another day, I think... However,
>> checking with the bzip2 binaries that the reporter provided I can see
>> that they have the right ABI flag in the ELF header but we're still
>> running the extra ABI check:
>> 
>> (sid-armhf)steve@mjolnir:~/abi$ LD_PRELOAD=./libbz2.so.all ./bzip2 
>> ERROR: ld.so: object './libbz2.so.all' from LD_PRELOAD cannot be preloaded 
>> (cannot open shared object file): ignored.
>> bzip2: I won't write compressed data to a terminal.
>> bzip2: For help, type: `bzip2 --help'.
>> 
>> (sid-armhf)steve@mjolnir:~/abi$ readelf -a libbz2.so.all | grep "^  Flags"
>>   Flags: 0x5000400, Version5 EABI, hard-float ABI
>> 
>> I think this is wrong, and I can't think of why I didn't find this
>> earlier when I was working in this area. :-/
>> 
>> So: I think we have two sensible options:
>> 
>> 1. I find time now to fix up ld.so to only do the extra check here if
>>we think it's needed
>> 
>> OR
>> 
>> 2. Just remove the patch for extra check here - it was always the plan
>>that this would go away after a while once people were unlikely to
>>still be running binaries from the pre ELF-header toolchains.
>> 
>> Checking history, I can see that the binutils changes for those ELF
>> header changes landed in Debian back in Nov 2012. (Wow, time
>> flies!). Given that, I'd now be strongly in favour of just dropping the
>> patch in
>> 
>> debian/patches/arm/unsubmitted-ldso-abi-check.diff
>> 
>> as it's now safely obsolete. What do others think?
>
>Given this patch is not needed anymore, I also thing it's the way to do.
>It caused us issue in the past, so i'll be very happy to see it going
>away.

ACK. I did want to keep it around for a while for safety, and that
period is clearly done. Thanks for your help with this! 

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Bug#943798: ld.so: old Arm ABI detection patch causing problems, time to remove?

[Steve McIntyre]

On Wed, Oct 30, 2019 at 12:17:20AM +, Steve McIntyre wrote:
>Source: glibc
>Version: 2.28-10
>Severity: important
>
>Hi folks,
>
>It looks like my old Arm ABI detection patch for ld.so is causing
>problems for people using LLVM. I've been contacted by a developer,
>referring to a mailing list thread:
>
>  https://lists.llvm.org/pipermail/llvm-dev/2019-October/135993.html

Forgot to add: there's an llvm-objcopy patch under discussion here:

  https://reviews.llvm.org/D69188

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Is there anybody out there?

Bug#943798: ld.so: old Arm ABI detection patch causing problems, time to remove?

[Steve McIntyre]

Source: glibc
Version: 2.28-10
Severity: important

Hi folks,

It looks like my old Arm ABI detection patch for ld.so is causing
problems for people using LLVM. I've been contacted by a developer,
referring to a mailing list thread:

  https://lists.llvm.org/pipermail/llvm-dev/2019-October/135993.html

It looks like the LLVM version of strip is more aggressive than the
GNU binutils version, and this is causing problems - it's stripping
the .ARM.attributes data and that's causing problems with our extra
checks for the Tag_ABI_VFP_args setting. Whether that's a valid thing
to do or not is an argument for another day, I think... However,
checking with the bzip2 binaries that the reporter provided I can see
that they have the right ABI flag in the ELF header but we're still
running the extra ABI check:

(sid-armhf)steve@mjolnir:~/abi$ LD_PRELOAD=./libbz2.so.all ./bzip2 
ERROR: ld.so: object './libbz2.so.all' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
bzip2: I won't write compressed data to a terminal.
bzip2: For help, type: `bzip2 --help'.

(sid-armhf)steve@mjolnir:~/abi$ readelf -a libbz2.so.all | grep "^  Flags"
  Flags: 0x5000400, Version5 EABI, hard-float ABI

I think this is wrong, and I can't think of why I didn't find this
earlier when I was working in this area. :-/

So: I think we have two sensible options:

1. I find time now to fix up ld.so to only do the extra check here if
   we think it's needed

OR

2. Just remove the patch for extra check here - it was always the plan
   that this would go away after a while once people were unlikely to
   still be running binaries from the pre ELF-header toolchains.

Checking history, I can see that the binutils changes for those ELF
header changes landed in Debian back in Nov 2012. (Wow, time
flies!). Given that, I'd now be strongly in favour of just dropping the
patch in

debian/patches/arm/unsubmitted-ldso-abi-check.diff

as it's now safely obsolete. What do others think?

-- System Information:
Debian Release: 10.1
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#685706: libc-bin: order of /etc/ld.so.conf.d/*.conf

[Steve McIntyre]

On Mon, Sep 17, 2018 at 12:33:08AM +0200, Aurelien Jarno wrote:
>On 2018-09-16 02:38, Alexander Huynh wrote:
>> Hello all,
>> 
>> I have a branch on Salsa [0] that would provide ordering for the two files I
>> currently see placed in /etc/ld.so.conf.d/:
>> 
>>   * libc.conf
>>   * $(uname -m)-linux-gnu.conf
>> 
>> I've also done a sweep of the rest of the repo, adding ordering to other 
>> files
>> that could appear in /etc/ld.so.conf.d/.
>
>This only changes the name of the files, which is the trivial part. As
>those are conf files, the problem is to handle them during the package
>upgrade, probably using dpkg-maintscript-helper. During the whole
>upgrade process, the biarch compat files (old or new version) should never
>have bigger priority than the corresponding native one, as it might
>render the libc unusable for some weird multiarch + multilib
>configurations.

Ugh, yes. Especially considering that there might be all kinds of
user-supplied config in here in arbitrarily-named files. :-/

On my Stretch amd64/i386 system I currently have:

c30-smcintyre:/etc/ld.so.conf.d$ ls -l
total 24
-rw-r--r-- 1 root root  38 Oct  5  2014 fakeroot-x86_64-linux-gnu.conf
-rw-r--r-- 1 root root 108 Jun 15  2017 i386-linux-gnu.conf
-rw-r--r-- 1 root root  44 Nov 29  2013 libc.conf
-rw-r--r-- 1 root root  68 Dec 22  2013 x86_64-linux-gnu.conf
-rw-r--r-- 1 root root  56 Jul  8  2014 zz_i386-biarch-compat.conf
-rw-r--r-- 1 root root  58 Apr 15  2015 zz_x32-biarch-compat.conf

which means that (for example) i386 system-provided libraries will be
searched ahead of anything in /usr/local/lib, listed in
libc.conf. It's even worse on Arm systems where "aarch64-*" or "arm-*"
will all sort before "libc".

Should we at least simply rename libc.conf to 00libc.conf to make this
bit work? Adding a simple rename for that would seem to be the right
answer as a start?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?

Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

[Steve McIntyre]

s are not seeing any value in A32 support so they're
leaving it out of their CPUs. We'll need to be careful about that.

Options I can see today for new publically available machines are
here. I'm sure I'll have missed something obvious - please feel free
to improve on this list!

 * Macchiatobin [1] - based on the Marvell 8040 SoC (4-core Cortex
   A72), supports both A32 and A64. Standard format (mini-itx) board
   mountable in a rack case. DIMM slot supports up to 16GiB, 3 SATA
   ports, multiple onboard NICs. Supported in mainline upstream
   kernel. Console on USB :-/. Readily available to buy.

 * Synquacer [2] - based on the Socionext SC2A11 SoC (24-core Cortex
   A53), supports both A32 and A64. Standard format (ATX) board
   mountable in a rack case. DIMM slots supports up to 4x16GiB, 2 SATA
   ports, onboard NIC. Supported in mainline upstream kernel. I'm
   hoping to get some of these machines donated to us from Linaro.

 * Qualcomm Centriq [3] - based on Qualcomm's Falkor CPU. Only
   supports A64 - no A32 support. All the big features you'd want in a
   big expensive server (management, RAM, I/O). Development machines
   available, but difficult to get hold of for the general
   public. Supported in mainline upstream kernel, some of it
   backported for Stretch (9.5) in #896775.

 * ThunderX 2 [4] - Cavium's second generation of AArch64 server
   CPU. Only supports A64 - no A32 support. All the big features you'd
   want in a big expensive server (management, RAM, I/O). Development machines
   available, but difficult to get hold of for the general
   public. Supported in mainline upstream kernel.

 * HiSilicon D05 [5] - HiSilicon's latest AArch64 server CPU and
   board. AFAIK only supports A64 - no A32 support. All the big
   features you'd want in a big expensive server (management, RAM,
   I/O). Development machines available, but difficult to get hold of
   for the general public - I've been trying for a while with
   HiSilicon. Not sure about upstream kernel support.

While they're on the lower end of this list, I think the Macchiatobin
and Synquacer are probably our best bets *at the moment*, particularly
when considering A32 support. In suitable rack cases with PDU and
serial console, would those work for DSA's needs?

[1] http://macchiatobin.net/
[2] 
https://www.cnx-software.com/2017/09/24/gigabyte-synquacer-96boards-enterprise-platform-is-powered-by-socionext-sc2a11-24-core-armv8-soc/)
[3] https://www.qualcomm.com/products/qualcomm-centriq-2400-processor
[4] https://www.cavium.com/product-thunderx2-arm-processors.html
[5] http://open-estuary.org/d05/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Re: Bug#851790: installation-reports: DNS not working

[Steve McIntyre]

On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote:
>On 2017-01-19 01:53, Cyril Brulebois wrote:
>
>> It's been a while since I last looked at/understood mklibs stuff though,
>> feel free to fix my suspicions/conclusions.
>
>The long term solution is to package all the libraries into udeb
>packages. That way we can simply get rid of the mklibs pass.
>
>The workaround are to make sure the chroots are up-to-date (which should
>be the case now on the build daemons). An other alternative would be to
>avoid copying a library in mklibs if it is already present in the image.
>That might break if some very strict dependencies are used, though
>I guess the way the udebs are downloaded, they should always have the
>same or a newer version than in the chroot.

Thanks for the explanation - it's appreciated!

Is there anything we could do to fail the build if versions are out of
sync, rather than let a broken build through?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.

Bug#822489: armhf ABI detection crashing ldconfig on arm64

[Steve McIntyre]

On Tue, Apr 26, 2016 at 12:33:38AM +0100, Steve McIntyre wrote:
>On Mon, Apr 25, 2016 at 09:57:00AM +0200, Aurelien Jarno wrote:
>
>>Could you please ensure that all the binaries in the archive that still
>>needs these patches are rebuilt?
>
>I'll look again for broken/old stuff. I thought you'd already pushed
>binNMUs for everything outstanding, though??

And checking my archive, that was just for the linker path in
fact. I'm re-scanning all armel and armhf binary packages in unstable
right now for all the following:

 linker path (armhf)
 fp ABI flags (both)

I'll report the results in the morning when it's done.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/

Bug#822489: armhf ABI detection crashing ldconfig on arm64

[Steve McIntyre]

On Mon, Apr 25, 2016 at 09:57:00AM +0200, Aurelien Jarno wrote:
>On 2016-04-25 00:30, Steve McIntyre wrote:
>> Package: libc6-bin
>> Severity: serious
>> Version: 2.22-7
>> Tags: patch
>> 
>> Hi folks,
>> 
>> Steev has reported some crashing using ldconfig on arm64 systems with
>> armhf added as a secondary architecture - he's using this config in
>> Kali, for example.
>> 
>> Working through the problem with him on #debian-arm, I can see that
>> it's a problem with our/my patch for ARM ABI detection. On older
>> binaries that predate the new ABI flags in the ELF header, we're still
>> parsing the ARM attributes. That works fine on armel/armhf, but on
>> arm64 this code is being built wrongly using native (ELF64)
>> types. This patch is the obvious fix - enforce using ELF32 types for
>> all arches.
>
>You have the same code in unsubmitted-ldconfig-cache-abi.diff, so I
>guess it also have to be patched?

Ah, yes - good point. I'd not considered that yet. Hmmm, pondering
some more...

No, we're safe here. In *that* case, we're running inside the armhf
(or armel) version of ld.so, *not* in the arm64 version. There's no
problem there. Does that make sense to you?

>> It seems that we still have some older packages without the ABI flags
>> attached - libshout3 is one such. :-(
>
>Frankly we are keeping "temporary" hacks for quite too long on armhf. I
>would like to drop the following patches after the Stretch release:
>
>- local-soname-hack.diff

Can go away easily I think, yes. The old soname should already be
history now.

>- unsubmitted-ldconfig-cache-abi.diff

Should go away after stretch, agreed.

>- unsubmitted-ldso-abi-check.diff
>- unsubmitted-ldso-multilib.diff

U. I don't think these two can go away *at all* without breaking
multi-arch on ARM.

The first one could do with updating to use the new ARM ABI float
flags in preference to the old, slow ARM attributes scan (as an
optimisation), but the concept isn't going to change.

The second one is also necessary to deal with finding two different
float ABIs in the ld.so cache.

>Could you please ensure that all the binaries in the archive that still
>needs these patches are rebuilt?

I'll look again for broken/old stuff. I thought you'd already pushed
binNMUs for everything outstanding, though??

Also: the 

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Is there anybody out there?

Re: Fixing the armhf linker path

[Steve McIntyre]

On Thu, Dec 17, 2015 at 11:04:47AM +, Steve McIntyre wrote:
>On Wed, Dec 16, 2015 at 11:30:53PM +0100, Aurelien Jarno wrote:
>>At the beginning of the armhf port the hard-float dynamic linker has
>>been chosen to be '/lib/arm-linux-gnueabihf/ld-linux.so.3'. However it
>>has been standardized later as '/lib/ld-linux-armhf.so.3' [1]. We have
>>changed it in Debian, and added a patch to the glibc [2] to temporarily
>>support both paths, until all the packages have been rebuilt with the
>>new path.
>>  
>>However we failed to do it for Wheezy. We also failed to do it for
>>Jessie. So let's do it for Stretch, so that we can drop the glibc
>>patches in Buster, and ensure binary compatibility with other
>>distributions.
>>
>>For that we first need to binNMU the packages which have not been
>>rebuilt since the dynamic linker change in unstable (see the list at
>>the end of the mail). Then we can have a look at getting all of them 
>>migrated to testing.
>>
>>Any comments or objections?
>
>ACK, this makes sense. I spoke with Adam a while back about doing
>this. I promised I'd scan the archive for any packages still relying
>on the old linker path, but I've not got to it yet - sorry. :-/

And I did today. Scanning all the armhf debs in stretch and sid for
linker path suggests the following binary packages needing
updating/rebuilding:

  stretch   sid

main       741  771
contrib  34
non-free 34

Logs of the found wrong linker paths (by binary package and binary)
are attached.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/


stretch-out-main.gz
Description: application/gzip


stretch-out-contrib.gz
Description: application/gzip


stretch-out-non-free.gz
Description: application/gzip


sid-out-main.gz
Description: application/gzip


sid-out-contrib.gz
Description: application/gzip


sid-out-non-free.gz
Description: application/gzip

Re: Fixing the armhf linker path

[Steve McIntyre]

On Wed, Dec 16, 2015 at 11:30:53PM +0100, Aurelien Jarno wrote:
>At the beginning of the armhf port the hard-float dynamic linker has
>been chosen to be '/lib/arm-linux-gnueabihf/ld-linux.so.3'. However it
>has been standardized later as '/lib/ld-linux-armhf.so.3' [1]. We have
>changed it in Debian, and added a patch to the glibc [2] to temporarily
>support both paths, until all the packages have been rebuilt with the
>new path.
>  
>However we failed to do it for Wheezy. We also failed to do it for
>Jessie. So let's do it for Stretch, so that we can drop the glibc
>patches in Buster, and ensure binary compatibility with other
>distributions.
>
>For that we first need to binNMU the packages which have not been
>rebuilt since the dynamic linker change in unstable (see the list at
>the end of the mail). Then we can have a look at getting all of them 
>migrated to testing.
>
>Any comments or objections?

ACK, this makes sense. I spoke with Adam a while back about doing
this. I promised I'd scan the archive for any packages still relying
on the old linker path, but I've not got to it yet - sorry. :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

Bug#691173: build bug can lead to locking problems on some arches

[Steve McIntyre]

Package: libc6
Version: 2.13-35
Severity: serious
Tags: upstream patch

Hi folks,

Just been directed to the bug discussion at

  http://sourceware.org/bugzilla/show_bug.cgi?id=13844

In some cases, the (e)glibc build will pick up an incorrect version of
lowlevellock.c and this can cause futex deadlocks. Although the
subject specifically mentions sparc, this is expected to impact ARM
too. AFAICS our current eglibc in unstable will include this
problem. Simple patch from glibc upstream:

diff --git a/nptl/ChangeLog b/nptl/ChangeLog
index 700fb72..7c6005b 100644
--- a/nptl/ChangeLog
+++ b/nptl/ChangeLog
@@ -1,3 +1,11 @@
+2012-03-16  David S. Miller  
+
+   [BZ #13844]
+   * sysdeps/unix/sysv/linux/libc-lowlevellock.c: Include using
<..>
+   instead of "...".
+   * sysdeps/unix/sysv/linux/sparc/sparc32/libc-lowlevellock.c:
+   Delete, not needed.
+
 2012-03-15  David S. Miller  
 
[BZ #13844]
diff --git a/nptl/sysdeps/unix/sysv/linux/libc-lowlevellock.c
b/nptl/sysdeps/unix/sysv/linux/libc-lowlevellock.c
index 28672a6..4883765 100644
--- a/nptl/sysdeps/unix/sysv/linux/libc-lowlevellock.c
+++ b/nptl/sysdeps/unix/sysv/linux/libc-lowlevellock.c
@@ -17,4 +17,4 @@
.  */
 
 /* No difference to lowlevellock.c, except we lose a couple of
 functions.  */
-#include "lowlevellock.c"
+#include 
diff --git
 a/nptl/sysdeps/unix/sysv/linux/sparc/sparc32/libc-lowlevellock.c
 b/nptl/sysdeps/unix/sysv/linux/sparc/sparc32/libc-lowlevellock.c
deleted file mode 100644
index 61296a4..000
--- a/nptl/sysdeps/unix/sysv/linux/sparc/sparc32/libc-lowlevellock.c
+++ /dev/null
@@ -1 +0,0 @@
-#include "lowlevellock.c"


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin  2.13-35
ii  libgcc1   1:4.7.2-4

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.46
pn  glibc-doc  
ii  locales2.13-35

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121022150729.ga23...@einval.com

Re: glibc: disabling armhf ldconfig support

[Steve McIntyre]

On Thu, Jul 05, 2012 at 12:08:06AM +0200, Aurelien Jarno wrote:
>Hi,
>
>At the end of last year the patch unsubmitted-ldconfig-cache-abi.diff
>has been added, but has not been submitted upstream despite asking a few
>times. This patch provides correct ldconfig support for systems with
>both armel and armhf libraries.
>
>The situation is now that this patch breaks MIPS N64 support due
>to a missing break in a case (easily fixable), but also that upstream
>has reused the same tag value for x32 support:
>
>  Debian 2.13:
>#define FLAG_ARM_HFABI  0x0800
>
>  Upstream HEAD:
>#define FLAG_X8664_LIBX32   0x0800

Sigh.

>As a consequence the armhf value will have to be changed in the future,
>which might have some side effects.

We'd have to make sure that the ldconfig cache is re-generated after
the change, to make sure things don't break.

>For now I guess the best change is simply to disable this patch for
>wheezy, which is already done in the SVN, and will land to send in the
>next upload. I'll ask debian-release to allow migration of the package
>to wheezy. I am also ready to re-enable this patch for wheezy once it
>has been merged upstream, or even when at least the tag value is merged
>upstream.

I'm in the middle of re-working the patch for upstream, but it's slow
going at the moment. I'm trying to get reviews for definitions of the
PT_ARM_ARCH_EXT segment, and that's been held up. :-(

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120705173641.gb19...@einval.com

Bug#670597: libc6: /lib/ld-linux.so.3 symlink not set

[Steve McIntyre]

On Sun, Apr 29, 2012 at 04:57:03PM +0200, Philipp Kern wrote:
>On Fri, Apr 27, 2012 at 12:04:29PM +, Adam Conrad wrote:
>> Closing this bug, as it was discovered that the failing binaries
>> in question were from debian-ports, not from debian.org.  Maintaining
>> backward compat with non-official archives is a non-starter, and
>> hopefully most people know how to work around this with violent
>> apt-pinning sidegrades, or reinstalling from the official archive.
>
>However it would be nice if you could avoid breaking all our official
>buildds in the process next time.  I.e. a notice *before* breaking the
>ports' users would've been helpful, especially as that change wasn't
>particularly time critical *for Debian*.

For now I've put in an extra /lib/ld-linux.so.3 symlink on the buildds
so they can start working again immediately. Next, I'm scanning all
the machines to verify exactly which packages need
fixing/rebuilding/reinstalling. Shouldn't take too long.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich




-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120429151317.gu21...@einval.com

Bug#387498: Unable to reproduce - mips/mipsel? 2.4/2.6 kernel difference?

[Steve McIntyre]

I've tried to look into this on my mips machine, but all seems to work
as expected:

[EMAIL PROTECTED]:~$ zless /usr/share/doc/libc6/changelog.Debian.gz 
[EMAIL PROTECTED]:~$ cat >t.c
int
main(int argc,char * argv[]) {return system(argv[1]);}
[EMAIL PROTECTED]:~$ cc -g t.c -o t
[EMAIL PROTECTED]:~$ ./t "echo g"
g
[EMAIL PROTECTED]:~$ cc -g -pg t.c -o t
[EMAIL PROTECTED]:~$ ./t "echo g"
g
[EMAIL PROTECTED]:~$ dpkg -s libc6 | grep Version:
Version: 2.3.6.ds1-4

One difference to point out is that I'm using a 2.6 kernel on this
machine:
[EMAIL PROTECTED]:~$ uname -a
Linux mallet 2.6.16-1-r5k-ip32 #1 Mon Apr 3 18:39:05 UTC 2006 mips64
GNU/Linux

which might explain it. I don't have any mipsen running 2.4 atm. Camm,
can you still reproduce this?

Ah, hang on - you reported this on vaughan, which is mips*el*. It
seems to be locked down atm, so I can't take a look myself atm on
there...

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"Because heaters aren't purple!" -- Catherine Pitt


signature.asc
Description: Digital signature

Bug#233392: Inefficient packaging of arch independent data in package libc6

[Steve McIntyre]

On Tue, Feb 24, 2004 at 11:46:39AM -0500, Joey Hess wrote:
>Steve McIntyre wrote:
>> No problem here. The zone info is actually quite small (compressed)
>> within the .deb, not really big enough to warrant the split I was
>> (mistakenly) asking for. Sorry for bothering you and thanks for
>> looking into this.
>
>It is, however, 5 mb unpacked, which is quite large compared to the
>overall size of the debian base system.

True. On a really small system that will hurt.

>> Joey, where is the existing bug asking for the split? I can't find it
>> in a quick check through the BTS...
>
>I can't find it, it may have been only a post to the debian-glibc
>mailing list.

OK, that explains it.

Is it worth some discussion on debian-devel here to see what other
people think?

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead


pgpLuS1BFdFbl.pgp
Description: PGP signature

Bug#233392: Inefficient packaging of arch independent data in package libc6

[Steve McIntyre]

On Wed, Feb 25, 2004 at 12:25:52AM +0900, GOTO Masanori wrote:
>At Wed, 18 Feb 2004 20:34:07 -0500,
>Joey Hess wrote:
>> Steve McIntyre wrote:
>> >   * Some packages need to have a -common or -doc package split out to
>> > contain this common data, and the existing packages that need this
>> > data should then be altered to depend on the new -common or -doc
>> > package.
>> 
>> If you give in to this bug report, please excersise sanity and do not
>> name the resulting package libc6-common. One genuinely useful split
>> would be to move the zoneinfo data (5.4 mb) to its own package, as that
>> is not needed on many small dedicated servers. There is an existing bug
>> asking for that.
>
>I don't think spliting zoneinfo is useful.
>
>(1) If zoneinfo is set as "required", then at last we need to install
>libc6 and zoneinfo on general machine.
>
>(2) I think even on many small dedicated servers, they need to handle
>"time".  And if such servers has no need to care for "time", the
>package system is even meaningless on them.
>
>So I would like to reject it.  Any comments?

No problem here. The zone info is actually quite small (compressed)
within the .deb, not really big enough to warrant the split I was
(mistakenly) asking for. Sorry for bothering you and thanks for
looking into this.

Joey, where is the existing bug asking for the split? I can't find it
in a quick check through the BTS...

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Is there anybody out there?


pgpHBqj06YYJd.pgp
Description: PGP signature

Bug#233392: Inefficient packaging of arch independent data in package libc6

[Steve McIntyre]

On Tue, Feb 24, 2004 at 11:46:39AM -0500, Joey Hess wrote:
>Steve McIntyre wrote:
>> No problem here. The zone info is actually quite small (compressed)
>> within the .deb, not really big enough to warrant the split I was
>> (mistakenly) asking for. Sorry for bothering you and thanks for
>> looking into this.
>
>It is, however, 5 mb unpacked, which is quite large compared to the
>overall size of the debian base system.

True. On a really small system that will hurt.

>> Joey, where is the existing bug asking for the split? I can't find it
>> in a quick check through the BTS...
>
>I can't find it, it may have been only a post to the debian-glibc
>mailing list.

OK, that explains it.

Is it worth some discussion on debian-devel here to see what other
people think?

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead


pgp0.pgp
Description: PGP signature

Bug#233392: Inefficient packaging of arch independent data in package libc6

[Steve McIntyre]

On Wed, Feb 25, 2004 at 12:25:52AM +0900, GOTO Masanori wrote:
>At Wed, 18 Feb 2004 20:34:07 -0500,
>Joey Hess wrote:
>> Steve McIntyre wrote:
>> >   * Some packages need to have a -common or -doc package split out to
>> > contain this common data, and the existing packages that need this
>> > data should then be altered to depend on the new -common or -doc
>> > package.
>> 
>> If you give in to this bug report, please excersise sanity and do not
>> name the resulting package libc6-common. One genuinely useful split
>> would be to move the zoneinfo data (5.4 mb) to its own package, as that
>> is not needed on many small dedicated servers. There is an existing bug
>> asking for that.
>
>I don't think spliting zoneinfo is useful.
>
>(1) If zoneinfo is set as "required", then at last we need to install
>libc6 and zoneinfo on general machine.
>
>(2) I think even on many small dedicated servers, they need to handle
>"time".  And if such servers has no need to care for "time", the
>package system is even meaningless on them.
>
>So I would like to reject it.  Any comments?

No problem here. The zone info is actually quite small (compressed)
within the .deb, not really big enough to warrant the split I was
(mistakenly) asking for. Sorry for bothering you and thanks for
looking into this.

Joey, where is the existing bug asking for the split? I can't find it
in a quick check through the BTS...

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Is there anybody out there?


pgp0.pgp
Description: PGP signature

Bug#233390: Inefficient packaging of arch independent data in package libc0.3

[Steve McIntyre]

Package: libc0.3
Version: 2.3.1-5
Severity: normal

This is a semi-automated bug report based on scanning the contents of
binary .deb files in the unstable Debian archive.

The libc0.3 packages seem to contain a very large amount of
architecture-independent data in architecture-dependent packages,
specifically data installed under /usr/share. This is wasteful of
mirror space and bandwidth, as we then end up with multiple copies of
this data, one for each architecture. Initial estimates suggest that
several gigabytes of Debian archive space may currently be wasted
because of packages like this.

The way to fix this depends on the layout of your package:

  * Some packages need to have a -common or -doc package split out to
contain this common data, and the existing packages that need this
data should then be altered to depend on the new -common or -doc
package.

  * This package may already be such a -common or -doc package, in
which case it probably should already be marked as Architecture:
all in your debian/control file rather than Architecture: any .

  * Maybe the files under /usr/share do not belong there - several
packages seem to contain data in /usr/share that is definitely
architecture-dependent. In this case, please move the files into
the right place.

Policy is quite clear on this point:

http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-archindepdata

The usage of these packages is currently:
 debsize pkgsize /usr/share %  filename
 3071500  117965184 43 pool/main/g/glibc/libc0.3_2.3.1-5_hurd-i386.deb

Please split this package appropriately. If you believe your package
is already split reasonably, then sorry for bothering you. If you wish
to discuss this further, please feel free to reply to this bug. If you
agree that there's a problem here but need help to fix it: again, feel
free to ask...

Thanks,
--
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]

Bug#233391: Inefficient packaging of arch independent data in package libc6.1

[Steve McIntyre]

Package: libc6.1
Version: 2.3.2.ds1-11
Severity: normal

This is a semi-automated bug report based on scanning the contents of
binary .deb files in the unstable Debian archive.

The libc6.1 packages seem to contain a very large amount of
architecture-independent data in architecture-dependent packages,
specifically data installed under /usr/share. This is wasteful of
mirror space and bandwidth, as we then end up with multiple copies of
this data, one for each architecture. Initial estimates suggest that
several gigabytes of Debian archive space may currently be wasted
because of packages like this.

The way to fix this depends on the layout of your package:

  * Some packages need to have a -common or -doc package split out to
contain this common data, and the existing packages that need this
data should then be altered to depend on the new -common or -doc
package.

  * This package may already be such a -common or -doc package, in
which case it probably should already be marked as Architecture:
all in your debian/control file rather than Architecture: any .

  * Maybe the files under /usr/share do not belong there - several
packages seem to contain data in /usr/share that is definitely
architecture-dependent. In this case, please move the files into
the right place.

Policy is quite clear on this point:

http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-archindepdata

The usage of these packages is currently:
 debsize pkgsize /usr/share %  filename
 4374822  149445808 38 pool/main/g/glibc/libc6.1_2.3.2.ds1-11_alpha.deb
 6205082  214845848 27 pool/main/g/glibc/libc6.1_2.3.2.ds1-11_ia64.deb

Please split this package appropriately. If you believe your package
is already split reasonably, then sorry for bothering you. If you wish
to discuss this further, please feel free to reply to this bug. If you
agree that there's a problem here but need help to fix it: again, feel
free to ask...

Thanks,
--
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]

Bug#233392: Inefficient packaging of arch independent data in package libc6

[Steve McIntyre]

Package: libc6
Version: 2.3.2.ds1-11
Severity: normal

This is a semi-automated bug report based on scanning the contents of
binary .deb files in the unstable Debian archive.

The libc6 packages seem to contain a very large amount of
architecture-independent data in architecture-dependent packages,
specifically data installed under /usr/share. This is wasteful of
mirror space and bandwidth, as we then end up with multiple copies of
this data, one for each architecture. Initial estimates suggest that
several gigabytes of Debian archive space may currently be wasted
because of packages like this.

The way to fix this depends on the layout of your package:

  * Some packages need to have a -common or -doc package split out to
contain this common data, and the existing packages that need this
data should then be altered to depend on the new -common or -doc
package.

  * This package may already be such a -common or -doc package, in
which case it probably should already be marked as Architecture:
all in your debian/control file rather than Architecture: any .

  * Maybe the files under /usr/share do not belong there - several
packages seem to contain data in /usr/share that is definitely
architecture-dependent. In this case, please move the files into
the right place.

Policy is quite clear on this point:

http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-archindepdata

The usage of these packages is currently:
 debsize pkgsize /usr/share %  filename
 4041994  131405800 44 pool/main/g/glibc/libc6_2.3.2.ds1-11_arm.deb
 4345510  142205800 40 pool/main/g/glibc/libc6_2.3.2.ds1-11_hppa.deb
 4877886  151205956 39 pool/main/g/glibc/libc6_2.3.2.ds1-11_i386.deb
 3681378  123605800 46 pool/main/g/glibc/libc6_2.3.2.ds1-11_m68k.deb
 4165148  150485800 38 pool/main/g/glibc/libc6_2.3.2.ds1-11_mips.deb
 4096278  150485800 38 pool/main/g/glibc/libc6_2.3.2.ds1-11_mipsel.deb
 4211148  140365808 41 pool/main/g/glibc/libc6_2.3.2.ds1-11_powerpc.deb
 5417456  160765848 36 pool/main/g/glibc/libc6_2.3.2.ds1-11_s390.deb
 4128276  138685800 41 pool/main/g/glibc/libc6_2.3.2.ds1-11_sparc.deb

Please split this package appropriately. If you believe your package
is already split reasonably, then sorry for bothering you. If you wish
to discuss this further, please feel free to reply to this bug. If you
agree that there's a problem here but need help to fix it: again, feel
free to ask...

Thanks,
--
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]

Bug#233390: Inefficient packaging of arch independent data in package libc0.3

[Steve McIntyre]

Package: libc0.3
Version: 2.3.1-5
Severity: normal

This is a semi-automated bug report based on scanning the contents of
binary .deb files in the unstable Debian archive.

The libc0.3 packages seem to contain a very large amount of
architecture-independent data in architecture-dependent packages,
specifically data installed under /usr/share. This is wasteful of
mirror space and bandwidth, as we then end up with multiple copies of
this data, one for each architecture. Initial estimates suggest that
several gigabytes of Debian archive space may currently be wasted
because of packages like this.

The way to fix this depends on the layout of your package:

  * Some packages need to have a -common or -doc package split out to
contain this common data, and the existing packages that need this
data should then be altered to depend on the new -common or -doc
package.

  * This package may already be such a -common or -doc package, in
which case it probably should already be marked as Architecture:
all in your debian/control file rather than Architecture: any .

  * Maybe the files under /usr/share do not belong there - several
packages seem to contain data in /usr/share that is definitely
architecture-dependent. In this case, please move the files into
the right place.

Policy is quite clear on this point:

http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-archindepdata

The usage of these packages is currently:
 debsize pkgsize /usr/share %  filename
 3071500  117965184 43 pool/main/g/glibc/libc0.3_2.3.1-5_hurd-i386.deb

Please split this package appropriately. If you believe your package
is already split reasonably, then sorry for bothering you. If you wish
to discuss this further, please feel free to reply to this bug. If you
agree that there's a problem here but need help to fix it: again, feel
free to ask...

Thanks,
--
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#233391: Inefficient packaging of arch independent data in package libc6.1

[Steve McIntyre]

Package: libc6.1
Version: 2.3.2.ds1-11
Severity: normal

This is a semi-automated bug report based on scanning the contents of
binary .deb files in the unstable Debian archive.

The libc6.1 packages seem to contain a very large amount of
architecture-independent data in architecture-dependent packages,
specifically data installed under /usr/share. This is wasteful of
mirror space and bandwidth, as we then end up with multiple copies of
this data, one for each architecture. Initial estimates suggest that
several gigabytes of Debian archive space may currently be wasted
because of packages like this.

The way to fix this depends on the layout of your package:

  * Some packages need to have a -common or -doc package split out to
contain this common data, and the existing packages that need this
data should then be altered to depend on the new -common or -doc
package.

  * This package may already be such a -common or -doc package, in
which case it probably should already be marked as Architecture:
all in your debian/control file rather than Architecture: any .

  * Maybe the files under /usr/share do not belong there - several
packages seem to contain data in /usr/share that is definitely
architecture-dependent. In this case, please move the files into
the right place.

Policy is quite clear on this point:

http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-archindepdata

The usage of these packages is currently:
 debsize pkgsize /usr/share %  filename
 4374822  149445808 38 pool/main/g/glibc/libc6.1_2.3.2.ds1-11_alpha.deb
 6205082  214845848 27 pool/main/g/glibc/libc6.1_2.3.2.ds1-11_ia64.deb

Please split this package appropriately. If you believe your package
is already split reasonably, then sorry for bothering you. If you wish
to discuss this further, please feel free to reply to this bug. If you
agree that there's a problem here but need help to fix it: again, feel
free to ask...

Thanks,
--
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#233392: Inefficient packaging of arch independent data in package libc6

[Steve McIntyre]

Package: libc6
Version: 2.3.2.ds1-11
Severity: normal

This is a semi-automated bug report based on scanning the contents of
binary .deb files in the unstable Debian archive.

The libc6 packages seem to contain a very large amount of
architecture-independent data in architecture-dependent packages,
specifically data installed under /usr/share. This is wasteful of
mirror space and bandwidth, as we then end up with multiple copies of
this data, one for each architecture. Initial estimates suggest that
several gigabytes of Debian archive space may currently be wasted
because of packages like this.

The way to fix this depends on the layout of your package:

  * Some packages need to have a -common or -doc package split out to
contain this common data, and the existing packages that need this
data should then be altered to depend on the new -common or -doc
package.

  * This package may already be such a -common or -doc package, in
which case it probably should already be marked as Architecture:
all in your debian/control file rather than Architecture: any .

  * Maybe the files under /usr/share do not belong there - several
packages seem to contain data in /usr/share that is definitely
architecture-dependent. In this case, please move the files into
the right place.

Policy is quite clear on this point:

http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-archindepdata

The usage of these packages is currently:
 debsize pkgsize /usr/share %  filename
 4041994  131405800 44 pool/main/g/glibc/libc6_2.3.2.ds1-11_arm.deb
 4345510  142205800 40 pool/main/g/glibc/libc6_2.3.2.ds1-11_hppa.deb
 4877886  151205956 39 pool/main/g/glibc/libc6_2.3.2.ds1-11_i386.deb
 3681378  123605800 46 pool/main/g/glibc/libc6_2.3.2.ds1-11_m68k.deb
 4165148  150485800 38 pool/main/g/glibc/libc6_2.3.2.ds1-11_mips.deb
 4096278  150485800 38 pool/main/g/glibc/libc6_2.3.2.ds1-11_mipsel.deb
 4211148  140365808 41 pool/main/g/glibc/libc6_2.3.2.ds1-11_powerpc.deb
 5417456  160765848 36 pool/main/g/glibc/libc6_2.3.2.ds1-11_s390.deb
 4128276  138685800 41 pool/main/g/glibc/libc6_2.3.2.ds1-11_sparc.deb

Please split this package appropriately. If you believe your package
is already split reasonably, then sorry for bothering you. If you wish
to discuss this further, please feel free to reply to this bug. If you
agree that there's a problem here but need help to fix it: again, feel
free to ask...

Thanks,
--
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]