Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
Hi Luca, On Sun, May 19, 2024 at 06:04:38PM +0100, Luca Boccassi wrote: > On Sun, 19 May 2024 18:42:17 +0200 Helmut Grohne > wrote: > > the init process should handle SIGTERM more like an init system would > handle that > > This seems the obvious answer to me. sbuild is setting up a system such > that its component runs as pid1, so it needs to behave like a pid1. We > know this is special and requires supporting a number of interfaces. If > a program doesn't, then it shouldn't be running as pid1 in a namespace. Die you mean "... so it needs to behave like a systemd"? sysvinit does not document SIGTERM as a supported signal. https://manpages.debian.org/bookworm/sysvinit-core/init.8.en.html Neither does runit. https://manpages.debian.org/bookworm/runit/runit.8.en.html#SIGNALS Nor did upstart. https://sources.debian.org/src/upstart/0.6.6-1/init/main.c/#L249 Or dumb-init (forwards all signals to its children). Or tini (forwards all signals to its children). https://github.com/krallin/tini/blob/master/src/tini.c#L525 Or busybox (see busybox init --help). But openrc-init and it then performs a shutdown. https://sources.debian.org/src/openrc/0.54-2/src/openrc-init/openrc-init.c/#L210 As far as my research goes, this handling of SIGTERM is specific to systemd and not a generic assumption of pid1. Helmut
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
Package: sbuild,debianutils,libc6,systemd-sysv
Severity: important
Hello lots of maintainers,
I am faced with a very crazy interaction bug. Roughly speaking, when you
use sbuild to build a package and your build-depends happen to include
systemd-sysv and you happen to install (cross building) or upgrade
libc6, installing build-depends reliably fails. Since upgrading libc6 is
a thing, I guess that this now affects buildds and is why I file this at
important severity. Regenerating buildd chroots, will "heal" buildds, so
it is self-recovering there.
Without further ado, let's dive into the details. The issue is
reproducible using mmdebstrap:
mmdebstrap unstable --verbose --architectures amd64,arm64 --variant=apt
/dev/null --include=systemd-sysv,libc6:arm64 --essential-hook='ln -sf
/bin/false $1/usr/bin/ischroot'
This is using a cross build setting, because libc6 is installed early
during bootstrap and reproducing the bug takes configuring libc6 after
systemd-sysv has been unpacked. So I simply install a foreign libc6 and
apt happens to configure it late enough in my tests. So we now look into
libc6.postinst. We take the "$1" = "configure" branch. We eventually run
into:
| # Restart init. Currently handles chroots, systemd and upstart, and
| # assumes anything else is going to not fail at behaving like
| # sysvinit:
| TELINIT=yes
| if ischroot 2>/dev/null; then
| # Don't bother trying to re-exec init from a chroot:
| TELINIT=no
I note that mmdebstrap creates a number of namespaces and then
externally runs apt. If I understand things correctly, it also runs an
external dpkg --root ... without --force-scripts-chrootless. Hence dpkg
performs a chroot for every maintainer script and ischroot correctly
detects this, so we would be setting TELINIT=no if I were not replacing
it in the --essential-hook.
In sbuild, the namespace setup is different. apt is entirely run inside
the namespace. ischroot compares /proc/1/mountinfo to
/proc/self/mountinfo. If both are readable and equal, it concludes that
we're not in a chroot. If they differ, it concludes that we are in a
chroot. For mmdebstrap, pid 1 happens to be a mmdebstrap process in the
initial namespace and the ischroot process sees fewer mounts. Hence it
concludes success there. For sbuild, pid 1 is a runuser process already
running chrooted. Hence the mountinfo files equal and ischroot concludes
that we are not running in a chroot.
| elif [ -n "${DPKG_ROOT:-}" ]; then
| # Do not re-exec init if we are operating on a chroot from outside:
| TELINIT=no
In neither case DPKG_ROOT is non-empty.
| elif [ -d /run/systemd/system ]; then
| # Restart systemd on upgrade, but carefully.
| # The restart is wanted because of LP: #1942276 and Bug: #993821
| # The care is needed because of https://bugs.debian.org/753725
| # (if systemd --help fails the system might still be quite broken but
| # that seems better than the kernel panic that results if systemd
| # cannot reexec itself).
| TELINIT=no
In neither case /run/systemd/system exists.
| if systemd --help >/dev/null 2>/dev/null; then
| systemctl daemon-reexec
| else
| echo "Error: Could not restart systemd, systemd binary not
working" >&2
| fi
| fi
| if [ "$TELINIT" = "yes" ]; then
| telinit u 2>/dev/null || true ; sleep 1
| fi
And finally we run telinit u when running inside sbuild or faking
ischroot in mmdebstrap. Running telinit u doesn't go well. This actually
has been a known problem with different symptoms recently. Earlier,
cross build nodes would get stuck in libc6.postinst hanging in telinit
forever. The reason was that telinit was re-executing itself over and
over again attempting to forward to another init system but always
returning back to itself. This has been fixed by Luca Boccassi:
https://github.com/systemd/systemd/pull/31251 and #1063147
telinit no longer reexecs itself and rather does what it is supposed to
do: kill(1, SIGTERM). Sadly this doesn't go well. In case of sbuild, we
kill the runuser process. It exits non-zero and sbuild considers this a
failure to install Build-Depends. This is bad.
So I'm not exactly sure which part is broken here. We might argue that
sbuild is setting up a container that looks too much like a container
and should have pid 1 outside the chroot area or that the init process
should handle SIGTERM more like an init system would handle that. We
might argue that ischroot should detect init-less application container
environments. We might argue that libc6 should ischroot is not meant for
detecting application containers and libc6.postinst asks the wrong
question and should be skipping telinit for such environments as well.
We might argute that telinit should not kill a pid 1 that isn't systemd.
At this time, I am really unsure which of these four packages we
consider at fault.
Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Hi Aurelien,
On Mon, Apr 08, 2024 at 11:24:40PM +0200, Aurelien Jarno wrote:
> Thanks for you analysis and your patch. In short your proposal is to
> extend the initial patch from Steve to fully hide the fact that the
> compiler default to -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64.
>
> This indeed works and fixes the FTBFS. However it seems that, at least
> for some of the issues, it just hides them. For instance the wrong type
> for timeval.tv_usec, reported by Simon upstream [1], was detected by the
> conformance tests. Quoting utmpx.h/conform.out:
I think this needs a more nuanced look. From the comments in the
conformance test suite, it is evident that it expects to be run without
_FILE_OFFSET_BITS and _TIME_BITS. Many of the symbols it requires to
exist only exist when these macros are unset. The conformance test suite
has a comment saying that it should be testing the case where
_FILE_OFFSET_BITS is defined, but it currently does not provide
expectations for that case.
Before we can reasonably run the conformance test suite with these
macros set (and really, the test suite should be in control of these
macros), we cannot reasonably use it with them set. Let us now imagine a
future where the conformance test suite has been extended to provide
expectations (which in lots of cases means that *64 symbols disappear
when -D_FILE_OFFSET_BITS=64). Then what still remains is Simon's issue:
> | /tmp/tmp98wzaavx/test.c:4:35: error: conflicting types for ‘b2_10’; have
> ‘__suseconds64_t’ {aka ‘long long int’}
> | 4 | extern __typeof__ (a2_10.tv_usec) b2_10;
> | | ^
> | /tmp/tmp98wzaavx/test.c:3:20: note: previous declaration of ‘b2_10’ with
> type ‘suseconds_t’ {aka ‘long int’}
> | 3 | extern suseconds_t b2_10;
> | |^
> | FAIL: Type of member tv_usec
Indeed, this is not something that can easily be fixed and where
upstream is still debating on what the correct solution should be. It
also is an issue that existed for a long time. If you head over to a
bookworm glibc and enable -D_TIME_BITS=64 there, you'll also notice that
tv_usec and suseconds_t have different sizes. So yes, this is a bug, but
it is not one that is directly related to Debian changing the default.
We merely increased the visibility of this problem that existed earlier
already.
Given that
* the issue is already present in bookworm,
* there are two mutually exclusive solutions and
* upstream is still discussing the best solution
I recommend deferring this aspect.
> And we know it is the reason for the FTBFS of libflorist [2], so should
> we just ignore that issue anyway?
The libflorist issue likely is a consequence. It arises from
gnat_to_gnu_field where GNAT verifies that the value (of type
suseconds_t) to be assigned to a field (tv_usec) has the matching size.
This is directly based on the POSIX expectation and will be fixed with
the glibc issue.
How about filing a separate bug with glibc that tracks this POSIX
divergence and mark the libflorist bug as being blocked by this other
glibc bug? It can be RC or not, but since it affects bookworm, it won't
block testing migration.
Helmut
Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Control: tags -1 + patch
Hi Aurelien and Canonical folks,
On Tue, Apr 02, 2024 at 08:53:31PM +0200, Aurelien Jarno wrote:
> Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with
> -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures
> except i386.
>
> This has been partially fixed in the 2.37-15.1 NMU by adding
> -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite:
There are two subtleties about -U_TIME_BITS in a moment.
> | +-+
> | | Encountered regressions that don't match expected failures. |
> | +-+
> | FAIL: conform/ISO/stdio.h/linknamespace
The detail for this failure is:
| [initial] fgetpos64
| [initial] fopen64
| [initial] freopen64
| [initial] fsetpos64
| [initial] tmpfile64
What linknamespace.py wants to tell us here is that it expected
fgetpos64, but no fgetpos64 was declared. It was not declared, because
there is no difference between fgetpos and fgetpos64 after defining
-D_FILE_OFFSET_BITS=64 (which is also in the default compiler flags).
The other failures are of very similar kind, but there also is another
kind.
> | FAIL: conform/POSIX/sys/stat.h/conform
The detail for this failure contains:
| /tmp/tmpnzda_r9j/test.c:90:35: error: conflicting types for 'b2_8'; have
'__time64_t' {aka 'long long int'}
|90 | extern __typeof__ (a2_8.st_atime) b2_8;
| | ^~~~
| /tmp/tmpnzda_r9j/test.c:89:17: note: previous declaration of 'b2_8' with type
'__time_t' {aka 'long int'}
|89 | extern __time_t b2_8;
| | ^~~~
Here, it tells us that it expected the st_atime field of struct stat to
have type __time_t (the 32 bit one), but it really has __time64_t.
Looking at the invocation of linknamespace.py you can see:
| python3 -B linknamespace.py --cc='arm-linux-gnueabihf-gcc-12'
--flags='-I../include
-I/build/reproducible-path/glibc-2.37/build-tree/armhf-libc
-I../sysdeps/unix/sysv/linux/arm/le -I../sysdeps/unix/sysv/linux/arm
-I../sysdeps/arm/nptl -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread
-I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix/arm -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/arm/le/armv7/multiarch -I../sysdeps/arm/armv7/multiarch
-I../sysdeps/arm/le/armv7 -I../sysdeps/arm/armv7 -I../sysdeps/arm/armv6t2
-I../sysdeps/arm/armv6 -I../sysdeps/arm/le -I../sysdeps/arm/include
-I../sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic
-nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/12/include -isystem
/build/reproducible-path/glibc-2.37/debian/include -I..' ...
In particular, what you do not see is -U_TIME_BITS inside --flags.
> Ubuntu has just ignored those failures for now, but I am just afraid
> that if we do the same, nobody will fix them.
Armed with this knowledge, I think we need two changes. For one thing
debian/sysdeps/linux.mk needs to add -U_FILE_OFFSET_BITS to extra_cflags
to revert any possible ABI changing effects. For another, the
conformance tests use independent compiler flags defined in
conform/Makefile. There, a naive patch seems to be:
-conformtest-cc-flags = -I../include $(+sysdep-includes) $(sysincludes) -I..
+conformtest-cc-flags = -U_FILE_OFFSET_BITS -U_TIME_BITS -I../include
$(+sysdep-includes) $(sysincludes) -I..
With these two changes, I am able to successfully build glibc on armhf
with the conformance test suite passing.
> In addition it means that upstream glibc does not build anymore by
> default on a 32-bit Debian. Not really a Debian issue, but that is not
> nice either and should probably be fixed.
I think that latter change may be applicable upstream. Running the
conformance test suite with either _FILE_OFFSET_BITS or _TIME_BITS set
is not expected nor supported. This is partially evident from
conform/linknamespace.py in a comment:
| # * Header inclusions should be compiled several times with
| # different options such as -O2, -D_FORTIFY_SOURCE and
| # -D_FILE_OFFSET_BITS=64 to find out what symbols are undefined
| # from such a compilation; this is not yet implemented.
The conformance test suite clearly wants to manage these macros (and its
effects on symbols) explicitly and does not expect them to be
pre-defined.
Hope this helps
Helmut
Re: Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi, On Sat, Mar 09, 2024 at 09:50:11PM +0100, Sebastian Ramacher wrote: > > I'd now like to coordinate a time of upload. Given that chroots are > > rebuilt in Wednesday and Sunday, I suggest we pick a Thursday morning > > for the actual upload. If I unexpectedly break stuff, I still have a few > > days to fix. How about March 21st? > > If and only if time64_t is done by then. Adding more changes where > transition has to be coordinated to the ongoing mega transition does not > help. Aurelien also said that glibc doesn't really build at this time. Furthermore, cryptsetup needs to migrate to testing before the upload and cryptsetup -> openssl -> dpkg is also entangled in time64. I propose April 11th on the condition that all relevant packages (including cryptsetup and e2fsprogs) have migrated. I'll also check with Aurelien on feasibility after Easter. Helmut
Re: transition: move files from / to /usr to finalize /usr-merge
Hi release team and essential maintainers, On Mon, Sep 04, 2023 at 10:33:54PM +0200, Helmut Grohne wrote: > Once these issues have been resolved, we can move most files except for > a small set of essential packages. For those, a coordinated upload > moving their files will be needed as will be an upload of base-files > adding the aliasing symlinks there. We're well into this now. Most of the essential set is moved and I've most of the remaining pieces. I hope that within one week, we're left with only: - base-files - bash - dash - glibc - util-linux Patches for these have been prepared. The current patches are available from https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo. These changes have been uploaded to Ubuntu noble already and feedback has been incorporated. In particular, base-files will now divert to dot files to avoid cluttering the / view during the transition and base-files will remove unnecessary diversions (those where it ships symlinks). I'd now like to coordinate a time of upload. Given that chroots are rebuilt in Wednesday and Sunday, I suggest we pick a Thursday morning for the actual upload. If I unexpectedly break stuff, I still have a few days to fix. How about March 21st? Once this has uploaded, we need to ensure that these packages migrate together. Also note that dash's autopkgtest will fail unless it uses the updated base-files, but it cannot depend on base-files. If you prefer, I can mark the relevant test case as flaky and unmark it in a second upload. Having a temporary migration block on these packages would also be a good idea. Once agreed, I shall announce this change to d-d-a as I cannot fully rule out it being disruptive despite the extensive testing performed. > We probably have to use NMUs to convert remaining packages at this > point. Once everything is moved, we may think we're done, but we're not. Speaking of the rest of packages. At the time of this writing, the numbers are: * 224 source packages can be moved via dh-sequence-movetousr. * 191 source packages have a dep17 usertagged bug report (most with patches). * 141 source packages can be moved with a no-change sourceful upload. This is about Arch:all packages as we already binNMUed the others. * 35 source packages cannot be analyzed, because they FTBFS (reported). * A 1-digit number of packages (e.g. the bootstrap ones above) needs special handling, but this is communicated and monitored. I hope that these numbers go down moving forward (especially the patches one). At some point, I want to mass-NMU the remaining packages. > As packages are restructured throughout the release cycle, they may > introduce file loss scenarios. Continued monitoring for problems until > trixie is released is crucial. The biggest chunk of findings was due to time64. I think the reports are timely and actionable. Generally, I hope that we'll run into less fallout moving forward as the "big" stuff is being handled. One exception here is that time64 has introduced a pile of "risky replaces". These are not accounted as buggy in the above numbers but need to be addressed before we can mass-NMU. That'll happen once the dust settles on time64. Any objections so far? Helmut
Bug#1061248: refining DEP17 patches for glibc and base-files
Hi Aurelien and Santiago, my DEP17 work on moving essential files has been uploaded to Ubuntu noble by Julian Andres Klode and we gain some insights there. As a result, I've been refining the patches and published my testing infrastructure. You can find it all (though maybe not in an easily consumable way) at https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo. One thing we noticed on the Ubuntu side is that as long as there are packages installing into aliased locations, the protective diversions (DEP17 M4) that I propose for base-files cause surprises for users. We divert e.g. /bin to /bin.usr-is-merged and this becomes a real directory. I've reconsidered this and concluded that there is no benefit in diverting /bin, /lib and /sbin. All that we have to do to avoid their accidental deletion is to ensure that they are installed by some package at all times. In bookworm and older, these are directories installed by base-files. In trixie, these will be symlinks provided by base-files. dpkg will resolve symlink vs directory conflicts in our favour. For /lib64 (on amd64 and some others), the story is more nuanced. This is not installed by base-files in bookworm. Therefore upgrading libc6:amd64 (whose bookworm version contains /lib64) before upgrading base-files is prone to loosing this symlink. Therefore, we need the protective diversion from libc6.preinst until base-files.postinst. On the final installation, /lib64 will not be diverted on amd64. For other multilib links, I discussed the matter with some members of #debian-devel and there were some conclusions. In general, we want to avoid the presence of unnecessary multilib symlinks (which is what the trigger approach in base-files is supposed to ensure). However, that means that there can be no package containing them and hence we really need to divert them for longer (in a finished trixie installation). This is what the previous patches already did, but I'm reconfirming that we really need this. The trigger-interest I previously added for base-files was broken and not actually activating. This is also fixed. As a further measure to reduce annoyed user reports, I'm changing the diversion targets for aliasing links from /$orig.usr-is-merged to /.$orig.usr-is-merged hoping that the leading dot will prevent the empty directories from being listed to users. Note that we cannot delete them, because that would cause dpkg --verify to report them as missing. They'll automatically disappear once no installed package installs any files into an aliased location. Niels Thykier made me aware of dh_installdeb -D. Using it avoids the need for a pile of .in files in base-files. I hope you like this refactoring. Let me know if not. I hope the coding style now fully meets base-files. Regarding the repository mentioned above, most of the changes are on the main branch, but the avoidance of diversions for /bin, /lib and /sbin as well as the change in diversion target are currently on a separate branch fewer-m4-diversions to ease comparing the approaches. This is mostly a report of what I've been doing and not something actionable to you except that I appreciate reviews of this work (e.g. commenting on the choices and rationale given above or actually looking into the changes). I still don't have a proposed upload date as the time64 transition unfolds and also breaks debootstrap currently. I hope we get this done by the end of March. Helmut
Bug#1061248: glibc: DEP17: move most files but rtld to /usr
Hi Aurelien, On Sun, Feb 04, 2024 at 09:43:53PM +0100, Aurelien Jarno wrote: > No, it is actually needed. For instance using the arm64 cross-compiler > on amd64: > > $ rm /usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 > $ arch64-linux-gnu-gcc -o test test.c > /usr/lib/gcc-cross/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/bin/ld: > cannot find /usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1: No such file or > directory > collect2: error: ld returned 1 exit status Right. For one thing this is not exactly the case where we're after. This is the plain architecture case where the rtld link will just be there by virtue of being there in the multiarch libc package. The case where we're after is running a cross compiler with multilib. Say I install i686-linux-gnu-gcc and pass -mx32: $ i686-linux-gnu-gcc -mx32 test.c -o test $ rm /usr/i686-linux-gnu/libx32/ld-linux-x32.so.2 $ i686-linux-gnu-gcc -mx32 test.c -o test /usr/lib/gcc-cross/i686-linux-gnu/13/../../../../i686-linux-gnu/bin/ld: cannot find /usr/i686-linux-gnu/libx32/ld-linux-x32.so.2: No such file or directory collect2: error: ld returned 1 exit status $ So this confirms your initial suspicion on the actually affected case. Thank you. c-t-b has repacking code with arch-specific mangling (of slibdir) already. https://sources.debian.org/src/cross-toolchain-base/68/debian/rules/#L563 Adding to that wouldn't be the worst. A relatively easy measure would be running the libc-alt.postinst manually with DPKG_ROOT set to have it create the symlink that way. Do you think this is too much of a hack? Helmut
Bug#1061248: glibc: DEP17: move most files but rtld to /usr
Hi Aurelien and Sven, On Wed, Jan 24, 2024 at 09:19:12PM +0100, Aurelien Jarno wrote: > On 2024-01-23 17:40, Helmut Grohne wrote: > > Conflicting runtime dynamic linkers between multiarch packages > > == > > > > Some architecture combinations such as s390, powerpc, hppa, m68k, > > mipsn32, and hurd-i386 or alpha, i386, sh4, and sparc have conflicting > > runtime dynamic loaders. In theory this violates Multi-Arch: same, but > > there is basically nothing we can do about this and dropping Multi-Arch: > > same from the packages would completely break any kind of multiarch > > setup. There is little we can do here and this is also unrelated to > > DEP17. > > We tried to add conflicts for those, like it's done for the multilib > packages, but at the time the infrastructure exploded (see #745552). I > don't remember the details, but I guess it was either dak or > dose-builddebcheck. Yeah, I also remember something like that. It's not the first time I trip into this. "There is little we can do here" still counts. > I guess the symlink in the maintainer script could indeed work. I am not > sure why it has been done like that, it was part of the multiarch > patchset from Steve Langasek more than 10 years ago. Practically speaking, it appears to work rather well. On the flip side, I also thought that way of my first patch. ;) > Note however that the those packages are used by cross-toolchain-base > (which builds them from glibc-source) and mangled to install them in the > cross path. See for instance libc6-amd64-x32-cross. For such cases, we > probably do want to keep the dynamic linker symlink, as those packages > do not have maintainer scripts. I don't think those -$arch-cross packages need the runtime dynamic linker at all. Unlike the libc6-$multilib packages, we don't use -$arch-cross packages to actaully run any binary. Simply not installing it might just work in practice. So here is an updated patch with a few notes: * This patch moves all the files including the runtime dynamic linker in the main multiarch library. Therefore, this patch needs to be synced with the corresponding base-files change to add the aliasing symlinks or debootstrap breaks. In other words: Don't upload this yet. * As mentioned earlier, only the multiarch packages install the runtime dynamic linker via data.tar. All the multilib packages install it via maintainer scripts now. * When installing libc6-x32, /libx32 will be created because partial upgrades might otherwise be broken. Removing libc6-x32 will not remove /libx32 though. I suggest fixing this in base-files by installing a trigger interest in /usr/libx32 and having base-files.postinst create/remove /libx32 as needed. This way, we centralize the management of aliasing links into base-files. libx32 only serves as an example here and it works the same way for any other non-essential multilib directory. Do you agree with the approach? * The multilib packages install a trigger interest on the runtime dynamic linker such that they notice when a multiarch package deletes it and can then recreate it as needed. Thus the multiarch packages do not have to pay attention to a possibly installed multilib package when they are removed. * I've tried quite a few multiarch upgrades involving amd64 and i386 using dpkg --auto-deconfigure --unpack with various packages and even cross grading libc6-x32 from :i386 to :amd64 during the upgrade. While dpkg --verify was occasionally unhappy during a partial upgrade (where half-unpacked packages were around), once no package was half-installed, dpkg --verify was also happy again in all attempts. I did not come up with a systematic enumeration of possible upgrade scenarios though. * The patch works will deboostrap/cdebootstrap/mmdebstrap (in combination with more patches including base-files, bash, dash and util-linux). * The change to install ldconfig to /usr/sbin can be uploaded right away. It's limited to debian/debhelper.in/libc-bin.install and debian/debhelper.in/libc-bin.lintian-overrides and doesn't contribute much diff, so doing it later is fine as well. I hope you don't manage to punch holes into my theory this time around. Helmut diff --minimal -Nru glibc-2.37/debian/changelog glibc-2.37/debian/changelog --- glibc-2.37/debian/changelog 2024-01-23 07:13:18.0 +0100 +++ glibc-2.37/debian/changelog 2024-01-19 15:56:06.0 +0100 @@ -1,3 +1,10 @@ +glibc (2.37-14.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * DEP17: Move files to /usr. (Closes: #-1) + + -- Helmut Grohne Fri, 19 Jan 2024 15:56:06 +0100 + glibc (2.37-14) unstable; urgency=medium [ Aurelien Jarno ] diff --minimal -Nru glibc-2.37/debian/debhelper.in/libc-alt.install glibc-2.3
Bug#1061248: glibc: DEP17: move most files but rtld to /usr
Hi, TL;DR: I brainstorm solutions and appreciated feedback, but no action is required at this time. On Sun, Jan 21, 2024 at 10:32:29PM +0100, Helmut Grohne wrote: > This seems pretty much unfxiable to me now. Unfixable was a bit too strong. With much help from Aurelien and ideas from Enrico I looked at this more systematically. I first tried to understand what kind of file sharing we between glibc packages. To that end I wrote a collect.sh (attached) that downlods all the glibc packages and a diagnose.py (attached) that tries to scrape relevant detail from them. This results in an output.txt (attached). This is all quite hacky, but it gets the job done. For the purpose of this analysis, I am assuming that files that differ in content also differ in size (which of course is not generally correct, but simplifies matters). That output.txt lists files (normalized to lack any /usr prefix) and the packages shipping them (as a 3-tuple package name, architecture, size or symlink target). Assuming that all the packages were Multi-Arch: same, files with identical content (i.e. size) are discarded. We're left with three kinds of file sharing: debhelper version on sh4 Apparently sh4 has a different debhelper that emits different files in /usr/share/doc. This breaks M-A:same, but is otherwise boring in the DEP17 context. Conflicting multilibs = Around 300 files in /lib64 conflict between libc6-ppc64:powerpc, libc6-amd64:i386 and libc6-amd64:x32. Likewise, around 300 files in /lib32 conflict between libc6-s390:s390x, libc6-sparc:sparc64, libc6-i386:amd64 libc6-powerpc:ppc64, libc6-i386:x32 and libc6-mipsn32:mips64el. These are declared file conflicts. Unfortunately, we learned that Conflicts do not reliably prevent concurrent unpacks in the presence of aliasing, so when moving these libraries, we can construct a file loss, for example: * apt install libc6:mips64el libc6-i386:amd64 * Add hypothetical apt sources with a moved glibc. * echo libc6-i386:amd64 deinstall | dpkg --set-selections * dpkg --auto-deconfigure --install libc6-mipsn32_usrmoved_mips64el.deb In essence, this will be upgrading from bookworm to trixe while simultaneously replacing libc6-i386 with libc6-mipsn32 for some reason. On top of that, I guess that apt would prefer removing libc6-i386 before unpacking libc6-mipsn32 such that the loss scenario likely requires working with dpkg directly. There is a relatively simple mitigation. For every file in SLIBDIR in the trixie, libc-alt.preinst can set up a diversion for the corresponding aliased location diverting to some non-existent filename. libc-alt.postinst then removes these diversions. The Conflicts require the conflicting libc-alt to actually be removed before libc-alt.postinst is run. (Breaks is not sufficient as I learned the hard way.) These are very temporary diversions, but they're also quite many (300). At the time of this writing, I have not prototyped this approach. Let me already pose the question of how you assess the involved risks here. Actually triggering this failure is a rather strange corner case and it is not clear to me whether this corner case is worth risking possible implementation bugs in the mitigation. Conflicting runtime dynamic linkers between multiarch packages == Some architecture combinations such as s390, powerpc, hppa, m68k, mipsn32, and hurd-i386 or alpha, i386, sh4, and sparc have conflicting runtime dynamic loaders. In theory this violates Multi-Arch: same, but there is basically nothing we can do about this and dropping Multi-Arch: same from the packages would completely break any kind of multiarch setup. There is little we can do here and this is also unrelated to DEP17. Conflicting runtime dynamic linkers between multiarch and multilib == Runtime dynamic linkers need to be installed both into libc:ARCH and libc-ARCH:SIBLINGARCH. An example is libc6:i386 and libc6-i386:amd64 both containing /lib/ld-linux.so.2. Both packages really need to ensure presence of the runtime dynamic linker on installation in the exact location so there is little we can do about this. The current situation is that the multiarch package Replaces the multilib one such that ownership is automatically transferred to the multiarch one when both are installed. The multiarch postrm also checks whether a multilib package is remaining and restores the symlink if it was stolen. This way of doing things works badly with the /usr-move. In the DEP17 document, this amounts to a P1 problem where a file is both moved from one package to another and from / to /usr. Since we actually want to permit concurrent unpack, we cannot use Conflicts (M7). We will have to employ protective diversions one way or another. Unfortunately, the /usr-move makes it difficult to safely transition the ownership of the runtime dyna
Bug#1061248: glibc: DEP17: move most files but rtld to /usr
On Sun, Jan 21, 2024 at 07:39:04PM +0100, Helmut Grohne wrote: > I shall rework the patch and also exempt multilib rtlds from moving. I'm > sorry for not having realized this. I suspect that dumat would have > reported this problem. This seems pretty much unfxiable to me now. Essentially, keeping all (including multilib) rtlds aliased works badly with the matching in debian/debhelper.in/libc-alt.install. Trying to refine those patterns in a way that retains the rtlds aliased while moving everything else is quite difficult, because sometimes SLIBDIR and RTLDDIR overlap. Even if managing this, it breaks my simplistic approach to fixing symlinks. When base-files gains the aliasing links, we can move both files from SLIBDIR and RTLDDIR restoring this simplicity. The value we gain from moving files in SLIBDIR now already seems to diminish given the complexity it would incur. If we disregard SLIBDIR moves, not much is left in my patch. Essentially all we can move is ldconfig and moving that now or later doesn't pose a significant difference. So it seems, that the proposed change is not very useful in the end. I've learned a few things about how to do the coordinated NMU move and that's about it, it seems. Sorry for the noise. Is it ok, to repurpose and leave open this bug open for the later upload moving all of the files or do you prefer a new bug then? Helmut
Bug#1061248: glibc: DEP17: move most files but rtld to /usr
Control: tags -1 - patch + moreinfo On Sun, Jan 21, 2024 at 06:37:35PM +0100, Sven Joachim wrote: > I have not studied the details, but this looks rather dangerous to me. > If you install the runtime dynamic linker in multilib packages below > /usr, but keep the native one at its current place, you risk losing it > when the multilib packages are removed. Thank you for reviewing my patch. > For instance, I have both libc6:i386 and libc6-i386:amd64 installed. If > the latter starts shipping /usr/lib/ld-linux.so.2 rather than > /lib/ld-linux.so.2, the "Replaces" in libc6:i386 becomes ineffective, > and we have basically a case of Dep17 P1. I shall rework the patch and also exempt multilib rtlds from moving. I'm sorry for not having realized this. I suspect that dumat would have reported this problem. Helmut
Bug#1061248: glibc: DEP17: move most files but rtld to /usr
Source: glibc Version: 2.37-13 Tags: patch User: helm...@debian.org Usertags: dep17m2 Hi Aurelien, thanks for your answers on IRC to my design question. As promised here comes a patch that moves most files in binary packages built from glibc from aliased locations to /usr. This excludes the runtime dynamic linker for native libc packages (i.e. not multilib), because moving it would break filesystem bootstrap unless base-files installs the aliasing symlinks at the same time. That move is a later step and is what I asked for in https://lists.debian.org/20230912181509.ga2588...@subdivi.de. What I'm asking for here is staging the changes to glibc in two phases where the majority of the move happens before that coordinated upload. This patch is that majority move. Regarding the implementation, I asked whether you'd prefer to change slibdir or not and you answered that you'd rather not change it as e.g. Fedora is not changing it either. My first implementation changed slibdir and this second iteration that does not change slibdir is quite a bit simpler. I also asked about how to deal with symbolic links that point at aliased locations. Your answer felt a little inconclusive to me, but fixing them practically is a requirement: During filesystem bootstrap, libc6 needs to briefly operate in an unmerged state (temporarily until that coordinated move) and therefore those symlinks in libc6 cannot rely on the aliasing symlinks having been set up. Hence, I added code for fixing those links before letting dh_link perform their canonicalization according to Debian policy. In practice, this turns most of the links (but runtime dynamic linker links) into relative ones. We may be able to drop this after the coordinated move if you disagree about the approach taken here, but I think it is best to accept this temporarily at least. Are you also comfortable with keeping this link fixing permanently? The change at hand requires significant testing, because there is a significant risk of breaking stuff and doing so is very annoying to many developers. I've performed the following steps: * Reviewed the file lists of created .debs to see that all files but runtime dynamic linkers have moved out of aliased locations. * Reviewed all symbolic links in created .debs. * Ran piuparts. It complained about /lib32 and /libx32 not being cleaned up after removal of multilib packages. I think this is vaguely fine. Do you agree? If not, I can add postrm code that checks whether /usr/lib32 and /usr/libx32 vanished and removes the aliasing links in those cases. * I set up a custom reprepro repository with these packages and ran a number of filesystem bootstraps: * debootstrap * debootstrap --variant=minbase * cdebootstrap --flavour=standard * cdebootstrap --flavour=minimal * mmdebstrap --variant=debootstrap * mmdebstrap --variant=minbase * mmdebstrap --variant=apt All of these bootstraps do not contain any glibc-owned files in aliased locations with the exception of the runtime dynamic linker. * I compiled a minimal C program in chroot both with -m32 and without and verified that the embedded location of the runtime dynamic linker still is aliased and that the resulting program still runs. * In addition to testing on amd64, I performed a i386 build. I note that my builds are nocheck builds, due to failing tests unrelated to my changes. I did not bother figuring out what local configuration causes those the test failures. Do you miss any testing here? Helmut diff --minimal -Nru glibc-2.37/debian/changelog glibc-2.37/debian/changelog --- glibc-2.37/debian/changelog 2023-12-03 14:23:52.0 +0100 +++ glibc-2.37/debian/changelog 2024-01-19 15:56:06.0 +0100 @@ -1,3 +1,10 @@ +glibc (2.37-13.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * DEP17: Move most files but rtld to /usr. (Closes: #-1) + + -- Helmut Grohne Fri, 19 Jan 2024 15:56:06 +0100 + glibc (2.37-13) unstable; urgency=medium [ Aurelien Jarno ] diff --minimal -Nru glibc-2.37/debian/debhelper.in/libc-alt.install glibc-2.37/debian/debhelper.in/libc-alt.install --- glibc-2.37/debian/debhelper.in/libc-alt.install 2022-09-22 22:06:02.0 +0200 +++ glibc-2.37/debian/debhelper.in/libc-alt.install 2024-01-19 15:56:06.0 +0100 @@ -1,6 +1,6 @@ # This file is used for biarch libraries. -TMPDIR/RTLDDIR/*.so* RTLDDIR -TMPDIR/SLIBDIR/*.so* SLIBDIR +TMPDIR/RTLDDIR/*.so* usr/RTLDDIR +TMPDIR/SLIBDIR/*.so* usr/SLIBDIR TMPDIR/LIBDIR/gconv/* LIBDIR/gconv/ TMPDIR/etc/ld.so.conf.d /etc diff --minimal -Nru glibc-2.37/debian/debhelper.in/libc-alt.postrm glibc-2.37/debian/debhelper.in/libc-alt.postrm --- glibc-2.37/debian/debhelper.in/libc-alt.postrm 2023-10-03 21:07:14.0 +0200 +++ glibc-2.37/debian/debhelper.in/libc-alt.postrm 2024-01-19 15:56:06.0 +0100 @@ -7,8 +7,8 @@ # multiarch package are installed, then the multiarch package
Re: /usr-merge and filesystem bootstrap
Hi Aurelien, On Fri, Sep 15, 2023 at 12:02:35AM +0200, Aurelien Jarno wrote: > Answering for the glibc package. Thanks. > On 2023-09-12 20:15, Helmut Grohne wrote: > > Once the Priority:required set only has that exception set left > > unconverted, I will prepare patches for the entire exception set and > > upload it coherently in one dinstall window. > > > > That exception set is: > > * base-files > > * bash > > * coreutils maybe > > * dash > > * libc6 > > * util-linux > > Do you mean you plan to upload source+binaries for all the above > packages and for all architectures? How do you plan to handle ports > architectures? My initial idea was doing source-only uploads and letting buildds perform all of the builds. Of course that leaves the possibility of buildds producing their packages "late" for the next dinstall. If that happens, the relevant architecture will fail debootstrap unstable. That is unfortunate, but it does happen occasionally and I think it is a reasonable risk to accept here. Once all relevant builds are done, debootstrap will work again. There are a number of things I can do to minimize the risk. For one thing, I can ask DSA when the cronjob for updating buildd chroots happens and align the uploads closely after such a cronjob. For another, I can coordinate with the buildd people and ask for help (e.g. prioritizing builds) on their side. Then I can mail d-devel and announce a concrete point in time asking developers to not upload packages on that particular day (e.g. using the delayed queue) to temporarily reduce the buildd load. Quite probably, debootstrap will temporarily break on some architectures. I hope that this is acceptable and that minimizing the downsides is good enough. Does that answer your question? > > * Are you fine in principle with me NMUing your package after having > >reviewed the promised patch? > > Yes, with the condition that help is provided to fix the bugs resulting > from moving files from / to /usr in the glibc packages. It is sad to see that this no longer goes without saying. Yes, I will actively look for possible fallout and allocate time for dealing with it. > > * Do you readily see any flaw in the proposed transition already? > > I haven't looked at the details besides the changes you described above. Thank you. We'll get into details once there are patches. Unfortunately, testing patches right now is difficult, because this work depends on all other (required) packages having been converted, which in turn is blocked in buildds being merged. Hoping that this is less work if done later, I've prioritized other matters for now and reach out to you now as a means of informing and gathering consent. There will certainly be a few more mails about this and there will be time after me having sent patches and provided details on how I tested them. Helmut
/usr-merge and filesystem bootstrap
Dear maintainers of relevant essential packages, this /usr-merge transition covering multiple release has reached a point where consensus has been reached about completing it by moving files from / to /usr. The chosen approach also affects filesystem bootstrap and an earlier discussion of this matter has resulted in consensus for not changing the bootstrap protocol from the pre-/usr-merge state and rather returning to that state. To this end, debootstrap has been updated in trixie and unstable such that it performs the initial unpack before performing the merge (mirroring how usrmerge does it on existing systems). This change is being backported to bookworm and bullseye by Simon McVittie. In order to remove the usrmerge package eventually, we want base-files to install the aliasing symlinks via its data.tar. Unfortunately, we cannot just do that, because doing so would break debootstrap or cdebootstrap/mmdebstrap or both. The way we get there is to first convert all packages from the Priority:required set but some exceptions to install no files into aliased locations such as /bin, /sbin or /lib*. Getting there will consume months. I hope we can reach this state in early 2024. Once the Priority:required set only has that exception set left unconverted, I will prepare patches for the entire exception set and upload it coherently in one dinstall window. That exception set is: * base-files * bash * coreutils maybe * dash * libc6 * util-linux base-files will install /bin, /sbin and /lib as symbolic links in its data.tar. libc6 will install multilib /lib* where needed as symbolic links in its data.tar: * /lib64: amd64, loong64, mips64el, ppc64, ppc64el * /libx32: x32 Since the relevant architectures share their libc soname, these packages will remain multiarch co-installable. Multilib symlinks that are not essential to a Debian architecture are not installed in a data.tar and managed using maintainer scripts instead. For instance, /lib64 will not be a symlink in libc6-amd64:i386, because /lib64 is not essential to i386 nor is libc6-amd64:i386 essential to i386. If we were to upload base-files before other packages, then a bootstrapping tool could first unpack that other package thereby creating e.g. /bin as a directory and then extracting the symbolic link from base-files' data.tar would fail. If we were to upload any other package from that set before base-files, the aliasing links would be absent and merging via usrmerge.postinst would not work due to missing the dynamic linker, /bin/sh, /bin/bash, or /bin/cp. Running util-linux.postinst before usrmerge.postinst could fail for the absence of /bin/more. Therefore changes need to be uploaded concurrently. I intend to perform these uploads in coordination with you. I request permission to NMU your package for the purpose of completing the transition in this way. Before actually performing such a NMU, I will prepare and send the to-be-NMUed patches to all affected maintainers for review. The purpose of having these NMUed is meeting the concurrency requirement. If you insist on performing the upload yourself, you could arrange handing me a signed .dsc. These packages also need to migrate to testing together or we will temporarily break bootstrappability of testing. We can either ensure that by temporarily adding suitable Breaks or using special release team powers. I will coordinate a suitable time avoiding e.g. a glibc transition or a time64 transition. I will try to remove coreutils from the exception set by changing usrmerge to no longer require a particular location of cp. I request that affected maintainers reply to this mail: * Are you ok with the proposed changes in principle? + Moving all files from / to /usr leaving no files in aliased locations + Installing aliasing symbolic links in base-files and libc6 * Are you fine in principle with me NMUing your package after having reviewed the promised patch? * Do you readily see any flaw in the proposed transition already? Thanks for your cooperation Helmut
[Git][glibc-team/glibc] Pushed new tag debian/2.19-18+deb8u12
Helmut Grohne pushed new tag debian/2.19-18+deb8u12 at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/debian/2.19-18+deb8u12 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc] Pushed new tag debian/2.19-18+deb8u11
Helmut Grohne pushed new tag debian/2.19-18+deb8u11 at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/debian/2.19-18+deb8u11 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc] Pushed new tag debian/2.24-11+deb9u5
Helmut Grohne pushed new tag debian/2.24-11+deb9u5 at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/debian/2.24-11+deb9u5 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc][jessie-security] import ELA-872-1 aka glibc 2.19-18+deb8u12
Helmut Grohne pushed to branch jessie-security at GNU Libc Maintainers / glibc Commits: fb5edb6e by Helmut Grohne at 2023-06-20T14:08:08+02:00 import ELA-872-1 aka glibc 2.19-18+deb8u12 - - - - - 3 changed files: - debian/changelog - + debian/patches/bz18036.patch - debian/patches/series View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/fb5edb6e2fbcc59b0a9c038f8842aaefa22e6022 -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/fb5edb6e2fbcc59b0a9c038f8842aaefa22e6022 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc] Deleted branch disarm-werror
Helmut Grohne deleted branch disarm-werror at GNU Libc Maintainers / glibc -- You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc][disarm-werror] disable -Werror when dpkg-builflags contains -Wno-error
Helmut Grohne pushed to branch disarm-werror at GNU Libc Maintainers / glibc Commits: 80722788 by Helmut Grohne at 2023-03-03T17:54:41+01:00 disable -Werror when dpkg-builflags contains -Wno-error Building glibc with a different toolchain tends to produce new warnings that are turned into build failures via -Werror. Instead, we typically want such builds to succeed. Thus we allow disabling -Werror by adding -Wno-error to dpkg-buildflags (which usually emits neither -Werror nor -Wno-error). Suggested-by: Steve Langasek vor...@debian.org Link: https://lists.debian.org/debian-devel/2023/02/msg00355.html - - - - - 2 changed files: - debian/rules - debian/rules.d/build.mk View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/80722788e42862d602ad1497bc9cca9104dec98f -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/80722788e42862d602ad1497bc9cca9104dec98f You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc] Pushed new branch disarm-werror
Helmut Grohne pushed new branch disarm-werror at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/disarm-werror You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc][sid] Annotate B-D libcap-dev with stage2 profile.
Helmut Grohne pushed to branch sid at GNU Libc Maintainers / glibc Commits: 50e5ea41 by Helmut Grohne at 2022-12-06T08:31:33+01:00 Annotate B-D libcap-dev with stage2 profile. libcap-dev is a library that is also needed when enabling selinux support. We already disable selinux in stage2, so we can disable this dependency as well without further loss of functionality. - - - - - 2 changed files: - debian/changelog - debian/control View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/50e5ea414c3267398768e9c31645b1738286ef3e -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/50e5ea414c3267398768e9c31645b1738286ef3e You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc][sid] Use conjunction for libgd-dev profiles.
Helmut Grohne pushed to branch sid at GNU Libc Maintainers / glibc Commits: 9309e3cc by Helmut Grohne at 2022-12-05T22:52:32+01:00 Use conjunction for libgd-dev profiles. The previous form !stage1 !stage2 would activate the dependency unless both profiles are given at the same time. We want either profile to disable the dependency though. - - - - - 3 changed files: - debian/changelog - debian/control - debian/control.in/main View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/9309e3cc9a80230b03b72c6c234e888ca8d5531b -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/9309e3cc9a80230b03b72c6c234e888ca8d5531b You're receiving this email because of your account on salsa.debian.org.
Bug#1025148: rpcsvc-proto FTCBFS: runs the built rpcgen
Source: rpcsvc-proto
Version: 1.4.2-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
rpcsvc-proto fails to cross build from source, because it runs the just
built rpcgen during build. There are basically two ways to fix this. One
is modifying the upstream build system to build rpcgen twice (for build
and for host). The other is adding a self-dependency and running the
installed rpcgen. Since the latter is far simpler, I'm attaching a patch
for that variant. Do you find that acceptable?
Helmut
diff --minimal -Nru rpcsvc-proto-1.4.2/debian/changelog
rpcsvc-proto-1.4.2/debian/changelog
--- rpcsvc-proto-1.4.2/debian/changelog 2021-08-18 22:04:55.0 +0200
+++ rpcsvc-proto-1.4.2/debian/changelog 2022-11-30 08:22:32.0 +0100
@@ -1,3 +1,10 @@
+rpcsvc-proto (1.4.2-4.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: Run the installed rpcgen during cross builds. (Closes: #-1)
+
+ -- Helmut Grohne Wed, 30 Nov 2022 08:22:32 +0100
+
rpcsvc-proto (1.4.2-4) unstable; urgency=medium
* Bump the breaks + replace version to 2.31-14. Thanks to Simon McVittie for
diff --minimal -Nru rpcsvc-proto-1.4.2/debian/control
rpcsvc-proto-1.4.2/debian/control
--- rpcsvc-proto-1.4.2/debian/control 2021-08-18 22:04:42.0 +0200
+++ rpcsvc-proto-1.4.2/debian/control 2022-11-30 08:20:02.0 +0100
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: GNU Libc Maintainers
Uploaders: Aurelien Jarno , Josue Ortega
-Build-Depends: debhelper-compat (= 13)
+Build-Depends: debhelper-compat (= 13), rpcsvc-proto
Rules-Requires-Root: no
Standards-Version: 4.6.0
Vcs-Browser: https://salsa.debian.org/glibc-team/rpcsvc-proto
diff --minimal -Nru rpcsvc-proto-1.4.2/debian/rules
rpcsvc-proto-1.4.2/debian/rules
--- rpcsvc-proto-1.4.2/debian/rules 2020-08-19 23:45:51.0 +0200
+++ rpcsvc-proto-1.4.2/debian/rules 2022-11-30 08:22:32.0 +0100
@@ -1,4 +1,13 @@
#!/usr/bin/make -f
+include /usr/share/dpkg/architecture.mk
+
%:
dh $@
+
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+execute_before_dh_auto_build:
+ set -e; for f in rpcsvc/*.x; do \
+ rpcgen -h -o $${f%.x}.h $$f; \
+ done
+endif
Bug#1024940: glibc: declare packages skipped by noudeb build profile
Source: glibc Version: 2.36-5 Severity: minor Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Aurelien et al, I noticed that while glibc does implement the noudeb build profile somewhat, it does not declare the profile in debian/control. I'm attaching a patch to fix that latter part for your convenience. Helmut diff --minimal -Nru glibc-2.36/debian/changelog glibc-2.36/debian/changelog --- glibc-2.36/debian/changelog 2022-11-12 14:23:05.0 +0100 +++ glibc-2.36/debian/changelog 2022-11-27 14:47:44.0 +0100 @@ -1,3 +1,10 @@ +glibc (2.36-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Declare packages skipped by noudeb build profile. (Closes: #-1) + + -- Helmut Grohne Sun, 27 Nov 2022 14:47:44 +0100 + glibc (2.36-5) unstable; urgency=medium [ Samuel Thibault ] diff --minimal -Nru glibc-2.36/debian/control glibc-2.36/debian/control --- glibc-2.36/debian/control 2022-11-09 23:31:15.0 +0100 +++ glibc-2.36/debian/control 2022-11-27 14:45:51.0 +0100 @@ -222,7 +222,7 @@ Section: debian-installer Priority: optional Provides: libc6, libc-udeb, libnss-dns-udeb, libnss-files-udeb -Build-Profiles: +Build-Profiles: Description: GNU C Library: Shared libraries - udeb Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library @@ -296,7 +296,7 @@ Section: debian-installer Priority: optional Provides: libc6.1, libc-udeb, libnss-dns-udeb, libnss-files-udeb -Build-Profiles: +Build-Profiles: Description: GNU C Library: Shared libraries - udeb Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library @@ -370,7 +370,7 @@ Section: debian-installer Priority: optional Provides: libc0.3, libc-udeb, libnss-dns-udeb, libnss-files-udeb -Build-Profiles: +Build-Profiles: Description: GNU C Library: Shared libraries - udeb Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library @@ -444,7 +444,7 @@ Section: debian-installer Priority: optional Provides: libc0.1, libc-udeb, libnss-dns-udeb, libnss-files-udeb -Build-Profiles: +Build-Profiles: Description: GNU C Library: Shared libraries - udeb Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library diff --minimal -Nru glibc-2.36/debian/control.in/libc glibc-2.36/debian/control.in/libc --- glibc-2.36/debian/control.in/libc 2022-11-09 23:31:03.0 +0100 +++ glibc-2.36/debian/control.in/libc 2022-11-27 14:46:08.0 +0100 @@ -63,7 +63,7 @@ Section: debian-installer Priority: optional Provides: @libc@, libc-udeb, libnss-dns-udeb, libnss-files-udeb -Build-Profiles: +Build-Profiles: Description: GNU C Library: Shared libraries - udeb Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library
[Git][glibc-team/glibc] Pushed new branch jessie-security
Helmut Grohne pushed new branch jessie-security at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/jessie-security You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc] Pushed new branch stretch-security
Helmut Grohne pushed new branch stretch-security at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/stretch-security You're receiving this email because of your account on salsa.debian.org.
Bug#1023437: lxc FTBFS with glibc 2.36
Source: lxc Version: 1:5.0.1-1 Severity: serious Tags: ftbfs X-Debbugs-Cc: debian-glibc@lists.debian.org lxc fails to build from source in unstable. It seems very likely that this is due to glibc 2.36. A non-parallel build log fails as follows: | [24/4015] cc -Isrc/lxc/liblxc_static.a.p -Isrc/lxc -I../src/lxc -I. -I.. -Isrc -I../src -Isrc/include -I../src/include -I../src/lxc/cgroups -I../src/lxc/storage -flto=auto -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=gnu11 -O0 -Wno-format-signedness -Wno-missing-field-initializers -Wno-unused-parameter -Wvla -Wimplicit-fallthrough=5 -Wcast-align -Wstrict-prototypes -fno-strict-aliasing -fstack-clash-protection --param=ssp-buffer-size=4 -Werror=implicit-function-declaration -Wlogical-op -Wmissing-include-dirs -Wold-style-definition -Winit-self -Wunused-but-set-variable -Wno-unused-parameter -Wfloat-equal -Wsuggest-attribute=noreturn -Werror=return-type -Werror=incompatible-pointer-types -Wformat=2 -Wshadow -Wendif-labels -Werror=overflow -fdiagnostics-show-option -Werror=shift-count-overflow -Werror=shift-overflow=2 -Wdate-time -Wnested-externs -fasynchronous-unwind-tables -fexceptions -Warray-bounds -Wrestrict -Wreturn-local-addr -Wstringop-overflow -include config.h -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -fvisibility=default -MD -MQ src/lxc/liblxc_static.a.p/conf.c.o -MF src/lxc/liblxc_static.a.p/conf.c.o.d -o src/lxc/liblxc_static.a.p/conf.c.o -c ../src/lxc/conf.c | FAILED: src/lxc/liblxc_static.a.p/conf.c.o | cc -Isrc/lxc/liblxc_static.a.p -Isrc/lxc -I../src/lxc -I. -I.. -Isrc -I../src -Isrc/include -I../src/include -I../src/lxc/cgroups -I../src/lxc/storage -flto=auto -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=gnu11 -O0 -Wno-format-signedness -Wno-missing-field-initializers -Wno-unused-parameter -Wvla -Wimplicit-fallthrough=5 -Wcast-align -Wstrict-prototypes -fno-strict-aliasing -fstack-clash-protection --param=ssp-buffer-size=4 -Werror=implicit-function-declaration -Wlogical-op -Wmissing-include-dirs -Wold-style-definition -Winit-self -Wunused-but-set-variable -Wno-unused-parameter -Wfloat-equal -Wsuggest-attribute=noreturn -Werror=return-type -Werror=incompatible-pointer-types -Wformat=2 -Wshadow -Wendif-labels -Werror=overflow -fdiagnostics-show-option -Werror=shift-count-overflow -Werror=shift-overflow=2 -Wdate-time -Wnested-externs -fasynchronous-unwind-tables -fexceptions -Warray-bounds -Wrestrict -Wreturn-local-addr -Wstringop-overflow -include config.h -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -fvisibility=default -MD -MQ src/lxc/liblxc_static.a.p/conf.c.o -MF src/lxc/liblxc_static.a.p/conf.c.o.d -o src/lxc/liblxc_static.a.p/conf.c.o -c ../src/lxc/conf.c | ../src/lxc/conf.c: In function ‘__lxc_idmapped_mounts_child’: | ../src/lxc/conf.c:2993:37: error: passing argument 4 of ‘mount_setattr’ from incompatible pointer type [-Werror=incompatible-pointer-types] | 2993 | , | | ^ | | | | | struct lxc_mount_attr * | In file included from ../src/lxc/conf.c:22: | /usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’ | 317 | struct mount_attr *__uattr, size_t __usize) | | ~~~^~~ | ../src/lxc/conf.c:3016:41: error: passing argument 4 of ‘mount_setattr’ from incompatible pointer type [-Werror=incompatible-pointer-types] | 3016 | , | | ^ | | | | | struct lxc_mount_attr * | /usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’ | 317 | struct mount_attr *__uattr, size_t __usize) | | ~~~^~~ | ../src/lxc/conf.c: In function ‘lxc_idmapped_mounts_parent’: | ../src/lxc/conf.c:4130:37: error: passing argument 4 of ‘mount_setattr’ from incompatible pointer type [-Werror=incompatible-pointer-types] | 4130 | , sizeof(attr)); | | ^ | | | | | struct lxc_mount_attr * | /usr/include/x86_64-linux-gnu/sys/mount.h:317:46: note: expected ‘struct mount_attr *’ but argument is of type ‘struct lxc_mount_attr *’ | 317 |
[Git][glibc-team/glibc] Pushed new tag debian/2.28-10+deb10u2
Helmut Grohne pushed new tag debian/2.28-10+deb10u2 at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/debian/2.28-10+deb10u2 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc] Pushed new branch buster-security
Helmut Grohne pushed new branch buster-security at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/buster-security You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc] Deleted branch fix-dpkg-root-merged-usr
Helmut Grohne deleted branch fix-dpkg-root-merged-usr at GNU Libc Maintainers / glibc -- You're receiving this email because of your account on salsa.debian.org.
Bug#1021973: iconv: undefined symbol after upgrade
Control: tags -1 + confirmed On Tue, Oct 18, 2022 at 09:13:05AM +0200, Guillaume Lefranc wrote: > after upgrading libc-bin from 2.28-10+deb10u1 to 2.28-10+deb10u2, the > following error appeared after running iconv the following way: > > iconv -cs -f 'UTF-8' -t 'UTF-8' /tmp/510754/import/import.1 > > iconv: relocation error: iconv: symbol __gconv_create_spec version > GLIBC_PRIVATE not defined in file libc.so.6 with link time reference I'm sorry for having missed this. The fix for this issue is quite obvious. libc-bin needs a tighter version constraint on libc6. Also libc6 needs to break old libc-bin. I don't think this is worth an update on its own though, because partial upgrades are an unusual thing to do. Indeed apt in unstable will make this even more difficult to perform. If there happens to be a regression update for other reasons, this should be fixed as well. Helmut
[Git][glibc-team/glibc] Pushed new branch fix-dpkg-root-merged-usr
Helmut Grohne pushed new branch fix-dpkg-root-merged-usr at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/fix-dpkg-root-merged-usr You're receiving this email because of your account on salsa.debian.org.
Bug#1010477: tzdata: reduce Installed-Size using deduplication
Source: tzdata Version: 2022a-1 Severity: wishlist Tags: patch tzdata is not a huge package, but when considering it for use in an embedded system, the size is noticeable. Depending on the file system in use, the size consumption may even be bigger due to the many small files. It turns out that a number of those files are duplicated. You can see a report at https://dedup.debian.net/compare/tzdata/tzdata. If replacing them with hardlinks, we can easily save 20% of reported Installed-Size. I expect that the practical savings are bigger. Please consider applying the attached patch. If you dislike hard links for some reason, the same effect can be achieved using symlinks in a similarly mechanical way. Helmut diff --minimal -Nru tzdata-2022a/debian/changelog tzdata-2022a/debian/changelog --- tzdata-2022a/debian/changelog 2022-03-22 20:49:04.0 +0100 +++ tzdata-2022a/debian/changelog 2022-05-02 12:00:33.0 +0200 @@ -1,3 +1,10 @@ +tzdata (2022a-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Deduplicate files in timezone database using hard links. Closes: #-1. + + -- Helmut Grohne Mon, 02 May 2022 12:00:33 +0200 + tzdata (2022a-1) unstable; urgency=high [ Aurelien Jarno ] diff --minimal -Nru tzdata-2022a/debian/control tzdata-2022a/debian/control --- tzdata-2022a/debian/control 2022-03-22 20:47:25.0 +0100 +++ tzdata-2022a/debian/control 2022-05-02 12:00:33.0 +0200 @@ -2,7 +2,7 @@ Section: localization Priority: required Build-Depends: debhelper-compat (= 13) -Build-Depends-Indep: gawk, po-debconf, symlinks +Build-Depends-Indep: gawk, po-debconf, symlinks, rdfind Rules-Requires-Root: no Maintainer: GNU Libc Maintainers Uploaders: Clint Adams , Aurelien Jarno diff --minimal -Nru tzdata-2022a/debian/rules tzdata-2022a/debian/rules --- tzdata-2022a/debian/rules 2022-03-22 20:47:25.0 +0100 +++ tzdata-2022a/debian/rules 2022-05-02 12:00:32.0 +0200 @@ -76,6 +76,7 @@ echo ; \ done ) > $(TEMPLATES_FILE) debconf-updatepo + rdfind -outputname /dev/null -makehardlinks true $(TZGEN) override_dh_auto_test: # The upstream tests are related to the sources. Just skip it. diff --minimal -Nru tzdata-2022a/debian/tzdata.lintian-overrides tzdata-2022a/debian/tzdata.lintian-overrides --- tzdata-2022a/debian/tzdata.lintian-overrides1970-01-01 01:00:00.0 +0100 +++ tzdata-2022a/debian/tzdata.lintian-overrides2022-05-02 12:00:33.0 +0200 @@ -0,0 +1,2 @@ +# lintian bug #1010476 +tzdata: package-contains-hardlink *
Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
Hi Florian, On Sat, Dec 04, 2021 at 01:59:14PM +0100, Florian Weimer wrote: > It is as architecture-independent as ldconfig or getconf. Perhaps a bit > more so than getconf. Both of those are bad examples as both are lies. An amd64 ldconfig really does not handle arm64 libraries at all. I'd rather not see us adding more issues. > Even if /bin/true is an i386 program, assuming that libeatmydata1:i386 > is installed. Whether ld.so is built for i386 or amd64 will not matter. That's great. > With the patch I've posted, you'll get the ELFCLASS64 error. But I have > some ideas how to fix that eventually. Is this sufficient for now? I'd prefer making it work upfront. People will use it and run into issues blaming Multi-Arch otherwise. If you also have ideas on how to make ldconfig work, that would be cool as well, but it's a different topic and should be moved to d-cross@l.d.o rather than discussed in this thread. Helmut
Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
Hi Florian, On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote: > We can add a generic ELF parser to that ld.so and use PT_INTERP, as I > mentioned below. I think this is the way to go. Some care will be > needed to avoid endless loops, but that should be it. Can I ask you to go into a bit more technical detail as to how this is supposed to work? >From what was said, I expect that /usr/bin/ld.so is an ELF executable. It will likely be part of libc-bin. Do you confirm? Since libc-bin is Multi-Arch: foreign. The new ld.so really must have an architecture-independent API. If it does not, it must not go there. As far as I understand things, the typical use will be "ld.so --preload somelib someprogram". Now consider an i386 ld.so, an amd64 somelib and an amd64 someprogram. Will that work with the generic ELF parser? At present, it does not seem to work: $ /lib/ld-linux.so.2 --preload /usr/lib/x86_64-linux-gnu/libeatmydata.so /bin/true /bin/true: error while loading shared libraries: /bin/true: wrong ELF class: ELFCLASS64 $ If that is what you will get from /usr/bin/ld.so, then it must not be part of libc-bin or Multi-Arch: foreign must be dropped. The latter likely is a non-option due to the amount of resulting breakage. Helmut
Bug#993973: nss FTBFS with glibc 2.32: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull]
Source: nss Version: 2:3.70-1 Severity: serious Tags: ftbfs X-Debbugs-Cc: debian-glibc@lists.debian.org A native build of nss now fails as follows: | x86_64-linux-gnu-gcc -o OBJS/nsinstall.o -c -std=c99 -g -g -fPIC -pipe -ffunction-sections -fdata-sections -DHAVE_STRERROR -DLINUX -Dlinux -Wall -Wshadow -Werror -DXP_UNIX -DXP_UNIX -DDEBUG -UNDEBUG -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_SOURCE -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT -DDEBUG -UNDEBUG -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_SOURCE -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT -DNSS_NO_INIT_SUPPORT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -I/<>/dist/include -I/<>/dist/public/coreconf -I/<>/dist/private/coreconf nsinstall.c | nsinstall.c: In function ‘main’: | nsinstall.c:70:16: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull] |70 | #define GETCWD getcwd | |^ | nsinstall.c:239:8: note: in expansion of macro ‘GETCWD’ | 239 | cwd = GETCWD(0, PATH_MAX); | |^~ | In file included from nsinstall.c:20: | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ declared with attribute ‘write_only (1, 2)’ | 520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur | | ^~ | nsinstall.c:70:16: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull] |70 | #define GETCWD getcwd | |^ | nsinstall.c:246:13: note: in expansion of macro ‘GETCWD’ | 246 | todir = GETCWD(0, PATH_MAX); | | ^~ | In file included from nsinstall.c:20: | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ declared with attribute ‘write_only (1, 2)’ | 520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur | | ^~ | cc1: all warnings being treated as errors | make[2]: *** [../../coreconf/rules.mk:292: OBJS/nsinstall.o] Error 1 | make[2]: Leaving directory '/<>/nss/coreconf/nsinstall' | make[1]: *** [debian/rules:100: override_dh_auto_build] Error 2 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:195: build] Error 2 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 It looks very much like this is due to the glibc 2.32 upload. My reading of man getcwd is that the call of nss is legit (as a glibc extension). Maybe this is a glibc bug? Helmut
Bug#993874: flurm FTBFS with glibc 2.32: fatal error: sys/sysctl.h: No such file or directory
Source: slurm Version: 0.4.3-2 Severity: serious Tags: ftbfs X-Debbugs-Cc: debian-glibc@lists.debian.org slurm fails to build from source with glibc 2.32, because sys/sysctl.h was removed. A build ends with: | [ 50%] Building C object CMakeFiles/slurm.dir/slurm.c.o | /usr/bin/cc -D_HAVE_NCURSES -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -o CMakeFiles/slurm.dir/slurm.c.o -c /<>/slurm.c | In file included from /<>/slurm.c:37: | /<>/os.h:180:10: fatal error: sys/sysctl.h: No such file or directory | 180 | #include | | ^~ | compilation terminated. | make[3]: *** [CMakeFiles/slurm.dir/build.make:85: CMakeFiles/slurm.dir/slurm.c.o] Error 1 | make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' | make[2]: *** [CMakeFiles/Makefile2:98: CMakeFiles/slurm.dir/all] Error 2 | make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu' | make[1]: *** [Makefile:152: all] Error 2 | make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu' | dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j1 VERBOSE=1 returned exit code 2 | make: *** [debian/rules:3: build] Error 25 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Helmut
Bug#990031: glibc FTCBFS: multiple reasons
Source: glibc Version: 2.31-12 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs Hi Aurelien et al, while we do cross build glibc stage2 during architecture bootstrap with some hacks, I've never really attempted cross building it in a pristine build environment. Now the need has arisen and I've figured that it doesn't work. There are three distinct problems. The binutils dependency is interpreted as a host architecture dependency. Unfortunately, host binutils are neither runnable nor coinstallable with build-essential. What you really want here is binutils for the host architecture. This problem is known as "toolchain dependency translation". We devised a number of possible solution and ultimately settled on my crazy one back then in 2014 in Paris. The rough idea is to suffix build tools with -for-build or -for-host and let those packages magically do the right thing. Fortunately, this actually works for binutils already. Nextup is g++-10. The problem is equal to binutils. Unfortunately, we've not fully implemented the devised solution here yet. We've got patches for gcc-N and for gcc-defaults, but more review and testing is needed before those can be uploaded to unstable. In the mean time, the linux maintainers figured a clever workaround. Instead of $tool, they write something slightly longer: $tool , $tool-$gnutriplet1 [arch1] , $tool-$gnutriplet2 [arch2] , $tool-gnutriplet3 [arch3] , ... Yes, this is slightly longish and a little bit ugly. The upshot is that it works today. Can you bear this temporarily? Nextup, malloc/Makefile says that the check for libgd does not work for cross compilation and skips building memusageat. debhelper then complains when it is missing. In fact, the libgd check does work just fine during cross builds and the hack can be removed. So here you have a patch that makes glibc cross buildable to arm64 without any fuss. Do note that I did not touch the multilib dependency. Cross building for e.g. amd64 requires adding the nobiarch profile. I think this is a fair compromise for now. Helmut diff --minimal -Nru glibc-2.31/debian/changelog glibc-2.31/debian/changelog --- glibc-2.31/debian/changelog 2021-05-01 22:56:06.0 +0200 +++ glibc-2.31/debian/changelog 2021-06-18 14:40:52.0 +0200 @@ -1,3 +1,13 @@ +glibc (2.31-12.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Annotate binutils dependency with -for-host. ++ Use suffixed cross compilers until there is -for-host. ++ cross.patch: LIBGD detection actually works. + + -- Helmut Grohne Fri, 18 Jun 2021 14:40:52 +0200 + glibc (2.31-12) unstable; urgency=medium * debian/po/de.po: fix encoding declaration. Closes: #986450. diff --minimal -Nru glibc-2.31/debian/control glibc-2.31/debian/control --- glibc-2.31/debian/control 2021-01-05 06:41:20.0 +0100 +++ glibc-2.31/debian/control 2021-06-18 14:30:58.0 +0200 @@ -8,10 +8,11 @@ mig-for-host (>= 1.5-3) [hurd-i386], gnumach-dev (>= 2:1.8+git20200710-2~) [hurd-i386], hurd-dev (>= 1:0.9.git20201127-4~) [hurd-i386] | hurd-headers-dev [hurd-i386], kfreebsd-kernel-headers [kfreebsd-any], - binutils (>= 2.29), - g++-10, g++-10-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el powerpc ppc64 s390x sparc sparc64 x32] , - gcc-10 (>= 10-20200431) [arm64], - gcc-10 (>= 10.1.0-3) [hurd-i386], + binutils-for-host (>= 2.29), + g++-10 , g++-10-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el powerpc ppc64 s390x sparc sparc64 x32] , + g++-10-x86-64-kfreebsd-gnu [kfreebsd-amd64] , g++-10-i686-kfreebsd-gnu [kfreebsd-i386] , g++-10-x86-64-kfreebsd-gnu [kfreebsd-amd64] , g++-10-i686-kfreebsd-gnu [kfreebsd-i386] , g++-10-x86-64-linux-gnu [amd64] , g++-10-aarch64-linux-gnu [arm64] , g++-10-arm-linux-gnueabi [armel] , g++-10-arm-linux-gnueabihf [armhf] , g++-10-hppa-linux-gnu [hppa] , g++-10-i686-linux-gnu [i386] , g++-10-m68k-linux-gnu [m68k] , g++-10-mips-linux-gnu [mips] , g++-10-mipsel-linux-gnu [mipsel] , g++-10-mips64-linux-gnuabin32 [mipsn32] , g++-10-mips64el-linux-gnuabin32 [mipsn32el] , g++-10-mips64-linux-gnuabi64 [mips64] , g++-10-mips64el-linux-gnuabi64 [mips64el] , g++-10-mipsisa32r6-linux-gnu [mipsr6] , g++-10-mipsisa32r6el-linux-gnu [mipsr6el] , g++-10-mipsisa64r6-linux-gnuabin32 [mipsn32r6] , g++-10-mipsisa64r6el-linux-gnuabin32 [mipsn32r6el] , g++-10-mipsisa64r6-linux-gnuabi64 [mips64r6] , g++-10-mipsisa64r6el-linux-gnuabi64 [mips64r6el] , g++-10-nios2-linux-gnu [nios2] , g++-10-powerpc-linux-gnu [powerpc] , g++-10-powerpc64-linux-gnu [ppc64] , g++-10-powerpc64le-linux-gnu [ppc64el] , g++-10-riscv64-linux-gnu [riscv64] , g++-10-sparc-linux-gnu [sparc] , g++-10-sparc64-linux-gnu [sparc64] , g++-10-s390x-linux-gnu
Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Vineet, On Wed, Feb 24, 2021 at 08:17:53PM +, Vineet Gupta wrote: > Checking in to see if things have change since my last posting on this > topic. Appreciated. I would have forgotten about arc. > Is glibc 2.32 now packaged for debian so we can attempt ARC rebootstrap ? Unfortunately, no. Debian has started freezing in preparating of the bullseye release. Only up to version 2.31 is packaged and Aurelien seems a little busy these days. If I recall correctly, 2.32 drops some backwards compatibility stuff that Debian still relies on $somewhere, but is transitioning away already. So it's not just dumping 2.32 together with the 2.31 packaging in experimental. Before that happens, there is little I can do to help. With 2.31, we still get: | checking sysdep dirs... configure: error: The arc is not supported. I'm still interested in supporting the arc bootstrap. Please get back with me when we can move on. You can check Debian's glibc version at https://tracker.debian.org/pkg/glibc at any time in the version column. Helmut
Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Vineet, On Wed, Aug 26, 2020 at 02:39:53PM +, Vineet Gupta wrote: > Following up as ARC glibc port was merged upstream in 2.32. Can we now give > rebootstrap a spin for ARC Debian enablement. That's great news. Unfortunately, it's not that easy yet. rebootstrap requires the relevant software to be packaged for Debian and the glibc packaging has only reached 2.31 yet. 2.32 is not even in experimental yet. Trying rebootstrap with an experimental glibc is not entirely trivial, but possible. Aurelien (Cced via d-glibc@l.d.o), are there plans to upload 2.32 to experimental anytime soon? Alternatively, can we segregate the relevant diff between 2.31 and 2.32 and apply it to the unstable package without bumping the version? Helmut
Bug#91815: Patch to add memusage and memusagestat
Hi Stephen,
On Wed, Jul 08, 2020 at 05:38:46PM +0200, Stephen Kitt wrote:
> I don’t mind, it’s not as if this is an urgent bug ;-).
Thank you for your patience and work on this.
> I went for libc-devtools to avoid making it too closely-tied to libc-dev-bin,
> on purpose; it’s not only useful for people needing libc-dev.
Sounds good to me.
> I’ve implemented this, see the attached patch. I’m not sure the upgrade
> scenario is ideal though: recommends are ignored on upgrades. This means
> that, if libc-dev-bin recommends libc-devtools, upgrades won’t install the
> latter, but new installations of libc-dev-bin will.
There is little to add here.
> Pushing memusage* to a separate package would result in that being installed
> on upgrade: libc-dev-bin would depend on libc-devtools (following the
> transition rules strictly), so that would get pulled in automatically on
> upgrade, and since it’s a new package, it would count as installation, and
> thus pull in its recommendations.
I don't have an opinion on this and leave it to the glibc maintainers.
> diff --git a/debian/control.in/main b/debian/control.in/main
> index 659267bd..c513a01a 100644
> --- a/debian/control.in/main
> +++ b/debian/control.in/main
> @@ -12,7 +12,8 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>=
> 1.17.14), xz-utils, file,
> g++-9, g++-9-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32
> mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6
> mips64r6el powerpc ppc64 s390x sparc sparc64 x32] ,
> python3:native,
> libidn2-0 (>= 2.0.5~) ,
> - libc-bin (>= @GLIBC_VERSION@)
> + libc-bin (>= @GLIBC_VERSION@) ,
> + libgd-dev
I suggest adding a trailing comma to make the diff for the next change
smaller.
> Build-Depends-Indep: perl, po-debconf (>= 1.0)
> Maintainer: GNU Libc Maintainers
> Uploaders: Clint Adams , Aurelien Jarno
> , Adam Conrad , Samuel Thibault
>
> @@ -47,11 +48,31 @@ Section: libdevel
> Priority: optional
> Multi-Arch: foreign
> Depends: ${shlibs:Depends}, ${misc:Depends}
> -Recommends: manpages, manpages-dev
> +Recommends: libc-devtools (>> @GLIBC_VERSION@)
> Build-Profiles:
> Description: GNU C Library: Development binaries
> This package contains utility programs related to the GNU C Library
> development package.
> + .
> + * gencat: generate message catalogs
> + * rpcgen: compile RPC protocols to C
> +
> +Package: libc-devtools
> +Architecture: any
> +Section: devel
> +Priority: optional
> +Multi-Arch: foreign
I doubt that memusage is eligible for Multi-Arch: foreign.
> +Depends: ${shlibs:Depends}, ${misc:Depends}
> +Recommends: manpages, manpages-dev
> +Build-Profiles:
You need Breaks + Replaces here. With the current patch, piuparts should
be unhappy.
> +Description: GNU C Library: Development tools
> + This package contains development tools shipped by the GNU C
> + Library.
> + .
> + * memusage, memusagestat: profile a program's memory usage
> + * mtrace: interpret the malloc trace log
> + * sotruss: trace shared library calls
> + * sprof: display shared object profiling data
>
> Package: libc-l10n
> Architecture: all
> diff --git a/debian/debhelper.in/libc-dev-bin.install
> b/debian/debhelper.in/libc-dev-bin.install
> index 0d760a7e..902029b5 100644
> --- a/debian/debhelper.in/libc-dev-bin.install
> +++ b/debian/debhelper.in/libc-dev-bin.install
> @@ -1,5 +1,2 @@
> debian/tmp-libc/usr/bin/gencat usr/bin
> -debian/tmp-libc/usr/bin/mtrace usr/bin
> debian/tmp-libc/usr/bin/rpcgen usr/bin
> -debian/tmp-libc/usr/bin/sotruss usr/bin
> -debian/tmp-libc/usr/bin/sprof usr/bin
> diff --git a/debian/debhelper.in/libc-dev-bin.manpages
> b/debian/debhelper.in/libc-dev-bin.manpages
> index c33123a0..576ec52c 100644
> --- a/debian/debhelper.in/libc-dev-bin.manpages
> +++ b/debian/debhelper.in/libc-dev-bin.manpages
> @@ -1,3 +1,2 @@
> debian/local/manpages/gencat.1
> debian/local/manpages/rpcgen.1
> -debian/local/manpages/sotruss.1
> diff --git a/debian/debhelper.in/libc-devtools.install
> b/debian/debhelper.in/libc-devtools.install
> new file mode 100644
> index ..7a0024da
> --- /dev/null
> +++ b/debian/debhelper.in/libc-devtools.install
> @@ -0,0 +1,5 @@
> +debian/tmp-libc/usr/bin/memusage usr/bin
> +debian/tmp-libc/usr/bin/memusagestat usr/bin
> +debian/tmp-libc/usr/bin/mtrace usr/bin
> +debian/tmp-libc/usr/bin/sotruss usr/bin
> +debian/tmp-libc/usr/bin/sprof usr/bin
> diff --git a/debian/debhelper.in/libc-dev-bin.lintian-overrides
> b/debian/debhelper.in/libc-devtools.lintian-overrides
> similarity index 58%
> rename from debian/debhelper.in/libc-dev-bin.lintian-overrides
> rename to debian/debhelper.in/libc-devtools.lintian-overrides
> index eedd7cbd..1031449a 100644
> --- a/debian/debhelper.in/libc-dev-bin.lintian-overrides
> +++ b/debian/debhelper.in/libc-devtools.lintian-overrides
> @@ -1,3 +1,5 @@
> # these manpages are provided by the manpages package
> +libc-dev-bin: binary-without-manpage usr/bin/memusage
>
Bug#91815: Patch to add memusage and memusagestat
Hi Stephen, Thank you for not dropping the ball after my initial "it's not that easy" reply. On Sat, May 09, 2020 at 10:53:10AM +0200, Stephen Kitt wrote: > There’s another part of the transition which bothers me: if we add memusage > to a package which is depended upon (albeit temporarily) by libc-dev-bin, it > becomes part of build-essential, and adding memusage means adding libgd3, > libfontconfig1, libfreetype6, etc. to all builds... > > It occurred to me that there is however a way to add memusage while > transitioning cleanly, over a few years. It seems to me that the binaries in > libc-dev-bin can be split into two categories: binaries that are expected as > build tools (gencat and rpcgen), and binaries that are useful as tools for > understanding programs but not building them (memusage, memusagestat, mtrace, > sotruss, sprof). How about the following? > > * We add a new package, say libc-devtools, containing the second type of > tools (mtrace, sotruss, sprof). For transition purposes, libc-dev-bin > depends on that in Bullseye. > * We add another package, memusage, containing memusage and memusagestat. > That’s the package which ends up with all the annoying extra dependencies, > but nothing depends on it. > * In Bookworm, libc-dev-bin can drop the dependency on libc-devtools, and we > can merge memusage into libc-devtools. > > Does that make sense? All of what you write here makes very much sense to me and the trade-offs seem good to me. What you propose will result in making the bootstrapping/profile stuff simpler/better. That said, I am not a glibc maintainer. I don't see the full picture. I have two minor remarks: * Should libc-devtools maybe recommend memusage already? * We cannot simply have libc-devtools absorb memusage in bookworm. Doing so would break upgrades when someone has memusage, but not libc-devtools installed. Therefore memusage likely needs to be a transitional dummy package in bookworm and can only be removed one release later. I'm wondering whether this could be avoided if we had memusage depend on libc-devtools. Neither of these touch the core of your thoughts. I'm happy to review patches to make this happen. Please continue to Cc me if you want my review. Helmut
Bug#91815: Patch to add memusage and memusagestat
Hi Aurelien and Stephen, On Mon, May 04, 2020 at 12:00:28AM +0200, Aurelien Jarno wrote: > It's something we can fix. I found strange nobody notice so far. Does it > mean the bootstrap is done ignoring the build-dependencies? Yes, I still ignore build-depends entirely. glibc depends on a specific version of the compiler and such dependencies are not compatible with cross compilation until we fix #666743 aka gcc-for-host. That bug has a patch, but nobody wants to review it and communication isn't working best on the issue either. If you really want to make a dent now, you need to do like src:linux does: Build-Depends: g++-9 , g++-9-aarch64-linux-gnu [arm64] , g++-9-arm-linux-gnueabi [armel] , ... Do you want that? Doing so still means me hacking up the package during bootstrap, because I always force the compiler version regardless of whether glibc supports that. > Thanks for the detailed explanations. It looks to me that it's better to > add a different package. And while mtrace looks a good candidate to join > this package, I am not sure we can handle the transition easily. It > would mean that libc6-dev-bin need to depends on that new package at > least for one release cycle. And we actually don't want that for stage > 2, which means producing different packages for stage2... Let me point out that a transitional dependency is not a huge cost to reproducibility. Making the dependency optional to stage2 is reasonable. libc packages are not yet reproducible across stages. That's more of a vision. In diffoscope, such a dependency difference is very light. I agree with everything else you said around moving mtrace though. So judge it on its own knowing that it won't negatively impact bootstrap. When thinking about bootstrap, it helps to always think of any kind of transition as atomic (i.e. completed once started). It might be temporarily broken, but since you always rebuild everything from source, you can simply fix up anyth broken rdeps immediately. Helmut
Bug#958674: glibc: refactor generation of multilib include symlinks
Hi Aurelien, On Sun, May 03, 2020 at 11:32:41PM +0200, Aurelien Jarno wrote: > On the principle I am fine with it, it's a nice cleanup. Now I still > have one comment about it, see below. Thank you for taking the time to review the patch. > > --- glibc-2.30/debian/rules.d/build.mk 2020-03-25 13:36:06.0 > > +0100 > > +++ glibc-2.30/debian/rules.d/build.mk 2020-04-24 08:02:08.0 > > +0200 > > @@ -2,6 +2,16 @@ > > # PASS_VAR, we need to call all variables as $(call xx,VAR) > > # This little bit of magic makes it possible: > > xx=$(if $($(curpass)_$(1)),$($(curpass)_$(1)),$($(1))) > > +define generic_multilib_extra_pkg_install > > +set -e; \ > > +mkdir -p debian/$(1)/usr/include/sys; \ > > +ln -sf $(DEB_HOST_GNU_TYPE)/bits debian/$(1)/usr/include/; \ > > +ln -sf $(DEB_HOST_GNU_TYPE)/gnu debian/$(1)/usr/include/; \ > > +ln -sf $(DEB_HOST_GNU_TYPE)/fpu_control.h debian/$(1)/usr/include/; \ > > +for i in `ls debian/tmp-libc/usr/include/$(DEB_HOST_GNU_TYPE)/sys`; do \ > > + ln -sf ../$(DEB_HOST_GNU_TYPE)/sys/$$i debian/$(1)/usr/include/sys/$$i; > > \ > > DEB_HOST_GNU_TYPE doesn't look correct here. What we want here is the > multiarch path, not the gnu triplet. They are similar on most > architectures, but differ at least on i386. You're right. This should be DEB_HOST_MULTIARCH of course. It's a little embarrassing as I should know better. I've attached a revised version. Is there anything else you object to? Helmut diff --minimal -Nru glibc-2.30/debian/changelog glibc-2.30/debian/changelog --- glibc-2.30/debian/changelog 2020-03-25 13:56:56.0 +0100 +++ glibc-2.30/debian/changelog 2020-04-24 08:02:13.0 +0200 @@ -1,3 +1,10 @@ +glibc (2.30-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Refactor generation of multilib include symlinks. (Closes: #-1) + + -- Helmut Grohne Fri, 24 Apr 2020 08:02:13 +0200 + glibc (2.30-4) unstable; urgency=medium [ Aurelien Jarno ] diff --minimal -Nru glibc-2.30/debian/rules.d/build.mk glibc-2.30/debian/rules.d/build.mk --- glibc-2.30/debian/rules.d/build.mk 2020-03-25 13:36:06.0 +0100 +++ glibc-2.30/debian/rules.d/build.mk 2020-04-24 08:02:08.0 +0200 @@ -2,6 +2,16 @@ # PASS_VAR, we need to call all variables as $(call xx,VAR) # This little bit of magic makes it possible: xx=$(if $($(curpass)_$(1)),$($(curpass)_$(1)),$($(1))) +define generic_multilib_extra_pkg_install +set -e; \ +mkdir -p debian/$(1)/usr/include/sys; \ +ln -sf $(DEB_HOST_MULTIARCH)/bits debian/$(1)/usr/include/; \ +ln -sf $(DEB_HOST_MULTIARCH)/gnu debian/$(1)/usr/include/; \ +ln -sf $(DEB_HOST_MULTIARCH)/fpu_control.h debian/$(1)/usr/include/; \ +for i in `ls debian/tmp-libc/usr/include/$(DEB_HOST_MULTIARCH)/sys`; do \ + ln -sf ../$(DEB_HOST_MULTIARCH)/sys/$$i debian/$(1)/usr/include/sys/$$i; \ +done +endef ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),) libc_extra_config_options = $(extra_config_options) --disable-sanity-checks \ diff --minimal -Nru glibc-2.30/debian/sysdeps/amd64.mk glibc-2.30/debian/sysdeps/amd64.mk --- glibc-2.30/debian/sysdeps/amd64.mk 2020-03-25 13:36:06.0 +0100 +++ glibc-2.30/debian/sysdeps/amd64.mk 2020-04-24 08:02:08.0 +0200 @@ -20,21 +20,13 @@ define libc6-dev-i386_extra_pkg_install -mkdir -p debian/libc6-dev-i386/usr/include -ln -sf x86_64-linux-gnu/bits debian/libc6-dev-i386/usr/include/ -ln -sf x86_64-linux-gnu/gnu debian/libc6-dev-i386/usr/include/ -ln -sf x86_64-linux-gnu/fpu_control.h debian/libc6-dev-i386/usr/include/ +$(call generic_multilib_extra_pkg_install,libc6-dev-i386) mkdir -p debian/libc6-dev-i386/usr/include/x86_64-linux-gnu/gnu cp -a debian/tmp-i386/usr/include/gnu/lib-names-32.h \ debian/tmp-i386/usr/include/gnu/stubs-32.h \ debian/libc6-dev-i386/usr/include/x86_64-linux-gnu/gnu -mkdir -p debian/libc6-dev-i386/usr/include/sys -for i in `ls debian/tmp-libc/usr/include/x86_64-linux-gnu/sys` ; do \ -ln -sf ../x86_64-linux-gnu/sys/$$i debian/libc6-dev-i386/usr/include/sys/$$i ; \ -done - endef define libc6-i386_extra_pkg_install diff --minimal -Nru glibc-2.30/debian/sysdeps/armel.mk glibc-2.30/debian/sysdeps/armel.mk --- glibc-2.30/debian/sysdeps/armel.mk 2020-03-11 22:13:40.0 +0100 +++ glibc-2.30/debian/sysdeps/armel.mk 2020-04-24 08:02:08.0 +0200 @@ -15,21 +15,13 @@ # #define libc6-dev-armhf_extra_pkg_install # -#mkdir -p debian/libc6-dev-armhf/usr/include -#ln -sf arm-linux-gnueabi/bits debian/libc6-dev-armhf/usr/include/ -#ln -sf arm-linux-gnueabi/gnu debian/libc6-dev-armhf/usr/include/ -#ln -sf arm-linux-gnueabi/fpu_control.h debian/libc6-dev-armhf/usr/include/ +#$(call generic_multilib_extra_pkg_install,libc6-dev-armhf) # #mkdir -p debian/libc6-dev-armhf/usr/include/arm-linux-gnueabi/gnu #cp -a debian/tmp-armhf/usr/include/gnu/lib-names-hard.h \
Bug#958674: glibc: refactor generation of multilib include symlinks
Source: glibc Version: 2.30-4 Severity: wishlist Tags: patch Control: block 798955 by -1 Hi Aurelien, as you might have noticed, I resumed work on the long-standing multiarch glibc headers issue. It seems that we're mostly done with prerequisites now. Most patches with the exception of a qmake one have been filed a while ago, so it seems like time to move forward a little. The resulting patch to glibc is not entirely trivial, so I've tried to split it into more manageable pieces: * This bug: Refactor generation of multilib include symlinks. It is essentially pulling a pile of duplicated code into a make define. As such it can be considered a cleanup patch (net -160 lines) and does not affect resulting packages in an observable way. It is readily applicable. * #798955 will receive an updated patch after applying this one. The updated patch is much smaller, which makes it easier to review. Please don't let this patch sit in the bts for long. Either you like my approach of splitting the diff and can apply it. Fine. Or you disagree with it on some level. In that case, I'd like to learn your reason and have this bug closed and tagged wontfix. Helmut diff --minimal -Nru glibc-2.30/debian/changelog glibc-2.30/debian/changelog --- glibc-2.30/debian/changelog 2020-03-25 13:56:56.0 +0100 +++ glibc-2.30/debian/changelog 2020-04-24 08:02:13.0 +0200 @@ -1,3 +1,10 @@ +glibc (2.30-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Refactor generation of multilib include symlinks. (Closes: #-1) + + -- Helmut Grohne Fri, 24 Apr 2020 08:02:13 +0200 + glibc (2.30-4) unstable; urgency=medium [ Aurelien Jarno ] diff --minimal -Nru glibc-2.30/debian/rules.d/build.mk glibc-2.30/debian/rules.d/build.mk --- glibc-2.30/debian/rules.d/build.mk 2020-03-25 13:36:06.0 +0100 +++ glibc-2.30/debian/rules.d/build.mk 2020-04-24 08:02:08.0 +0200 @@ -2,6 +2,16 @@ # PASS_VAR, we need to call all variables as $(call xx,VAR) # This little bit of magic makes it possible: xx=$(if $($(curpass)_$(1)),$($(curpass)_$(1)),$($(1))) +define generic_multilib_extra_pkg_install +set -e; \ +mkdir -p debian/$(1)/usr/include/sys; \ +ln -sf $(DEB_HOST_GNU_TYPE)/bits debian/$(1)/usr/include/; \ +ln -sf $(DEB_HOST_GNU_TYPE)/gnu debian/$(1)/usr/include/; \ +ln -sf $(DEB_HOST_GNU_TYPE)/fpu_control.h debian/$(1)/usr/include/; \ +for i in `ls debian/tmp-libc/usr/include/$(DEB_HOST_GNU_TYPE)/sys`; do \ + ln -sf ../$(DEB_HOST_GNU_TYPE)/sys/$$i debian/$(1)/usr/include/sys/$$i; \ +done +endef ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),) libc_extra_config_options = $(extra_config_options) --disable-sanity-checks \ diff --minimal -Nru glibc-2.30/debian/sysdeps/amd64.mk glibc-2.30/debian/sysdeps/amd64.mk --- glibc-2.30/debian/sysdeps/amd64.mk 2020-03-25 13:36:06.0 +0100 +++ glibc-2.30/debian/sysdeps/amd64.mk 2020-04-24 08:02:08.0 +0200 @@ -20,21 +20,13 @@ define libc6-dev-i386_extra_pkg_install -mkdir -p debian/libc6-dev-i386/usr/include -ln -sf x86_64-linux-gnu/bits debian/libc6-dev-i386/usr/include/ -ln -sf x86_64-linux-gnu/gnu debian/libc6-dev-i386/usr/include/ -ln -sf x86_64-linux-gnu/fpu_control.h debian/libc6-dev-i386/usr/include/ +$(call generic_multilib_extra_pkg_install,libc6-dev-i386) mkdir -p debian/libc6-dev-i386/usr/include/x86_64-linux-gnu/gnu cp -a debian/tmp-i386/usr/include/gnu/lib-names-32.h \ debian/tmp-i386/usr/include/gnu/stubs-32.h \ debian/libc6-dev-i386/usr/include/x86_64-linux-gnu/gnu -mkdir -p debian/libc6-dev-i386/usr/include/sys -for i in `ls debian/tmp-libc/usr/include/x86_64-linux-gnu/sys` ; do \ -ln -sf ../x86_64-linux-gnu/sys/$$i debian/libc6-dev-i386/usr/include/sys/$$i ; \ -done - endef define libc6-i386_extra_pkg_install diff --minimal -Nru glibc-2.30/debian/sysdeps/armel.mk glibc-2.30/debian/sysdeps/armel.mk --- glibc-2.30/debian/sysdeps/armel.mk 2020-03-11 22:13:40.0 +0100 +++ glibc-2.30/debian/sysdeps/armel.mk 2020-04-24 08:02:08.0 +0200 @@ -15,21 +15,13 @@ # #define libc6-dev-armhf_extra_pkg_install # -#mkdir -p debian/libc6-dev-armhf/usr/include -#ln -sf arm-linux-gnueabi/bits debian/libc6-dev-armhf/usr/include/ -#ln -sf arm-linux-gnueabi/gnu debian/libc6-dev-armhf/usr/include/ -#ln -sf arm-linux-gnueabi/fpu_control.h debian/libc6-dev-armhf/usr/include/ +#$(call generic_multilib_extra_pkg_install,libc6-dev-armhf) # #mkdir -p debian/libc6-dev-armhf/usr/include/arm-linux-gnueabi/gnu #cp -a debian/tmp-armhf/usr/include/gnu/lib-names-hard.h \ # debian/tmp-armhf/usr/include/gnu/stubs-hard.h \ # debian/libc6-dev-armhf/usr/include/arm-linux-gnueabi/gnu # -#mkdir -p debian/libc6-dev-armhf/usr/include/sys -#for i in `ls debian/tmp-libc/usr/include/arm-linux-gnueabi/sys` ; do \ -# ln -sf ../arm-linux-gnueabi/sys/$$i debian/libc6-dev-armhf/usr/include/sys/$$i ; \ -#done -# #endef # #define libc6-armhf_extra_pkg_install diff --minimal
Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers
Hi, On Mon, Apr 20, 2020 at 10:12:37AM +0100, Jonathan Wakely wrote: > > Now you are probably going to say that "-isystem /usr/include" is a bad > > idea and that you shouldn't do that. > > Right. > > > I'm inclined to agree. This isn't a > > problem just yet. Debian wants to move /usr/include/stdlib.h to > > /usr/include//stdlib.h. After that move, the problematic flag > > becomes "-isystem /usr/include/". Unfortunately, around 30 > > Debian packages[1] do pass exactly that flag. Regardless whether doing > > so is a bad idea, I guess we will have to support that. > > Or Debian should fix what they're going to break. This is not quite precise. The offending -isystem /usr/include/ flag is already being passed. According to what you write later, doing so is broken today. It just happens to work by accident. So all we do is making the present breakage visible. > > I am proposing to replace those two #include_next with plain #include. > > That'll solve the problem described above, but it is not entirely > > obvious that doing so doesn't break something else. > > > > After switching those #include_next to #include, > > libstdc++-v3/include/c_global/cstdlib will continue to temporarily > > will #include . Now, it'll search all include directories. It > > may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's > > version. We cannot tell which. If it finds the one from libstdc++-v3, > > the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and > > immediately #include_next skipping the rest of the header. > > That in turn will find the libc version. So in both cases, it ends up > > using the right one. Precisely what we wanted. > > As Marc said, this doesn't work. That is not very precise either. Marc said that it won't fix all cases. In practice, it would make those work that don't #include but use #include instead. Marc also indicated that using include_next for a header of a different name is wrong. So this is a bug in libstdc++ regardless of whether it breaks or unbreaks other pieces of software. > If a program tries to include it needs to get the libstdc++ > version, otherwise only the libc versions of certain functions are > defined. That means the additional C++ overloads such as ::abs(long) > and ::abs(long long) won't be defined. That is the reason why > libstdc++ provides its own . > > And if you do -isystem /usr/include (or any other option that causes > libstdc++'s to be skipped) that doesn't work. Only > ::abs(int) gets defined. > > So -isystem /usr/include breaks code, with or without your patch. It is very difficult to disagree with -isystem /usr/include or -isystem /usr/include/ being broken and unsupported. Having you state it that clearly does help with communicating to other upstreams. For this reason, I've looked into the remaining cases. It turns out that there aren't that many left. In particular chromium, opencv and vtk got fixed in the mean time. Basically all remaining failures could be attributed to qmake, which passes all directories below /usr/include (including /usr/include and /usr/include/ if a .pc file mentions them) using -isystem. I've sent a patch https://bugs.debian.org/958479 to make qmake stop doing that. I therefore agree with you that the patch I sent for libstdc++ is not necessary to make packages build on Debian. Removing the offending -isystem flags from the respective builds is a manageable option and has already happened to a large extend. We can conclude that the motivation for my patch is not a good one, because it embraces broken behaviour. However, the use of include_next remains a bug, because the name of the including and the name of the included header differ, and it should be fixed on that ground. Helmut
Bug#91815: Patch to add memusage and memusagestat
Hi Aurelien and Stephen, On Wed, Apr 22, 2020 at 12:04:32AM +0200, Aurelien Jarno wrote: > > The attached patch adds memusage and memusagestat to the libc-bin package. > > This does mean that the latter becomes dependent on libgd3, so it might be > > better to add a new memusage package; I can take care of that if the > > maintainers think it’s better. > > I am not sure we want to add a new dependency for libc-bin, I am sure > people running embedded systems won't appreciate. Any reason for not > shipping it in libc-dev-bin instead? For me that looks more like a tool > to be used for "development". At least the memusagestat is similar to > the mtrace one that is in libc-dev-bin. > > We also have to make sure that this new build-dependency doesn't break > bootstrapping. I have added Helmut in Cc so that he can have a look. Thank you for notifying me. Indeed, the patch doesn't work for bootstrapping as is. A stage2 build of glibc would start requiring libgd-dev -> libgd3 -> libc6, but the stage1 libc6 will not be sufficient to build src:libgd2. It must be possible to build stage2 without that dependency. (Note that this is going to become more confusing as there is ongoing work on removing stage1 and maybe renaming stage2, but let's stick to the current names for now.) >From a bootstrapping pov, the libgd-dev dependency is similar to the libselinux-dev dependency, but I notice just now that it is not correctly annotated with in Build-Depends! >From a build profile pov, it is very undesirable to have package contents change with profiles. Doing so makes it impossible to validate them using reproducible builds. However, since we need libc6-dev from stage2 and it depends on libc-dev-bin we cannot skip generating libc-dev-bin in stage2. I wonder whether it would make sense to add another binary package for development tools that are not normally needed for building software. Then we could skip generating that package. mtrace would be a good candidate to join that package indeed. Failing that, we'll have to cope with changing package contents for stage2 and disable the new dependency for stage2 (or some other profile). Helmut
Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers
The and headers need their counter parts and from the libc respectively, but libstdc++ wraps these headers. Now and include these headers using $ echo '#include ' | g++ -x c++ -E - -isystem /usr/include >/dev/null In file included from :1: /usr/include/c++/9/cstdlib:75:15: fatal error: stdlib.h: No such file or directory 75 | #include_next | ^~ compilation terminated. $ What happens here is that g++ includes libstdc++-v3/include/c_global/cstdlib. That header temporarily #defines _GLIBCXX_INCLUDE_NEXT_C_HEADERS and then does #include_next . libstdc++-v3's replacement libstdc++-v3/include/c_comaptibility/stdlib.h happens to come earlier and is not considered. Unfortunately, the -isystem above inserted glibc's header before the location containing , so the #include_next continues searching and fails to find . Now you are probably going to say that "-isystem /usr/include" is a bad idea and that you shouldn't do that. I'm inclined to agree. This isn't a problem just yet. Debian wants to move /usr/include/stdlib.h to /usr/include//stdlib.h. After that move, the problematic flag becomes "-isystem /usr/include/". Unfortunately, around 30 Debian packages[1] do pass exactly that flag. Regardless whether doing so is a bad idea, I guess we will have to support that. I am proposing to replace those two #include_next with plain #include. That'll solve the problem described above, but it is not entirely obvious that doing so doesn't break something else. After switching those #include_next to #include, libstdc++-v3/include/c_global/cstdlib will continue to temporarily will #include . Now, it'll search all include directories. It may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's version. We cannot tell which. If it finds the one from libstdc++-v3, the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and immediately #include_next skipping the rest of the header. That in turn will find the libc version. So in both cases, it ends up using the right one. Precisely what we wanted. #include_next is simply not useful here. The #include_next was originally added via PRs libstdc++/14608 and libstdc++/60401. At that time, the _GLIBCXX_INCLUDE_NEXT_C_HEADERS guard macro was also added. It seems like the #include_next was a meant as an extra safe-guard, but actually breaks a practical use case. For these reasons, I think that using #include_next here is harmful and that replacing it with plain #include solves the problem without introducing regressions. [1] Including but not limited chromium-browser, inkscape, various kde packages, opencv, and vtk. libstdc++-v3/ChangeLog: * include/c_global/cmath: Don't use #include_next. * include/c_global/cstdlib: Likewise. --- libstdc++-v3/include/c_global/cmath | 2 +- libstdc++-v3/include/c_global/cstdlib | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Given the patch's size, I think that the copyright dance is not necessary. The issue affects at least gcc-8 to gcc-10. Please Cc me in replies. Helmut diff --git a/libstdc++-v3/include/c_global/cmath b/libstdc++-v3/include/c_global/cmath index b99aaf8df40..8b2bb7c0785 100644 --- a/libstdc++-v3/include/c_global/cmath +++ b/libstdc++-v3/include/c_global/cmath @@ -42,7 +42,7 @@ #include #include #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS -#include_next +#include #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS #include diff --git a/libstdc++-v3/include/c_global/cstdlib b/libstdc++-v3/include/c_global/cstdlib index f42db41fc51..80b39f6144f 100644 --- a/libstdc++-v3/include/c_global/cstdlib +++ b/libstdc++-v3/include/c_global/cstdlib @@ -72,7 +72,7 @@ namespace std // Need to ensure this finds the C library's not a libstdc++ // wrapper that might already be installed later in the include search path. #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS -#include_next +#include #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS #include -- 2.26.0
Bug#910685: glibc: please support DPKG_ROOT
Hi Aurelien, On Tue, Apr 14, 2020 at 05:49:38PM +0200, Helmut Grohne wrote: > Yes, please. Is there anything blocking this? Without support in glibc, > moving forward is a little difficult. Can you include it soonish? I pinged Aurelien on IRC about this. Let me summarize your answer here: * The relevant maintainer scripts are fragile. Experience has shown that every time one touches them they break. They should be well-tested. * Does the patch actually make libc6 work the way it advertises? * What about libc-bin? * Why not move forward with more testing of more packages before applying this patch? Yes, that makes sense. Let me give a partial answer already. I've performed a number of upgrades from unstable to patched libc packages in buildd-like environments now. The coverage is limited. I've set up a little testing lab to build patched versions of base-files, bash, coreutils, debhelper, debianutils, dpkg, glibc, shadow and util-linux. When installing subsets of essential using these patched packages, few packages fail to install. The failures are base-files, base-passwd, bash, dash, debconf, libc-bin, libpam-modules-bin, libpam-modules, libpam0g, login, mawk, sysvinit-utils, and util-linux. The majority of failures is due to missing patches for debconf. libc-bin is notable here as it will need changes to ldconfig to support this use case. However, very few packages depend on libc-bin. Therefore, I think solving libc-bin at a later time is reasonable. Small steps have been made in various packages: https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/4 https://salsa.debian.org/debian/shadow/-/merge_requests/10 https://salsa.debian.org/debian/shadow/-/merge_requests/11 https://salsa.debian.org/debian/debianutils/-/merge_requests/5 Guillem Jover resumed up work on dpkg-maintscript-helper and update-alternatives. In any case, I think that this patch does indeed make the library (not libc-bin) work for DPKG_ROOT and I'd prefer libc-bin to be handled in a separate issue. So yeah, we can move forward without this being merged if we really want. Questioning whether this patch blocks progress was a useful thing to do. There will be more fixes. Helmut
Bug#956855: consider reducing toolchain bootstrap stages
Source: cross-toolchain-base
Version: 45
Severity: wishlist
Tags: patch moreinfo
I'm not sure anymore who told me, but glibc has a build_many_glibcs.py
script and it does the toolchain bootstrap dance with fewer stages than
Debian (i.e. cross-toolchain-base and rebootstrap) does. The current
Debian toolchain bootstrap looks like this:
* binutils
* linux-libc-dev
* gcc stage1 (bare metal)
* glibc stage1 (headers + stub libc.so)
* gcc stage2
* glibc stage2 (libc without systemtap and other optional features)
* gcc stage3 (libc-integrated cross compiler)
* gcc rtlibs (runtime libraries for the cross compiler)
The assertion is that we can skip glibc stage1 and gcc stage2 and go
directly from gcc stage1 to glibc stage2.
I've implemented this in rebootstrap and it seems to work reasonably
well for a number of architectures. I've not run it on the full test
matrix yet. Some observations on rebootstrap:
* musl-linux-any already works like this since a while.
* hurd-any formerly needed libihash-dev for libpthread, but no longer
does. This sequence also works on hurd-i386.
* I've had success with arm64, armel, armhf, m68k, mips (nobiarch),
mipsel (nobiarch) and ppc64el thus far. Notably, these all lack
multilibs and I'm still sorting out multilib issues.
* I cannot tell about kfreebsd-any, since they didn't manage to get the
relevant kernel header source package back into unstable yet.
I've implemented this for cross-toolchain-base (patch attached) and a
performed a successful testbuild. Using diffoscope to compare the
resulting packages with the ones from the archive was not a useful thing
to do as the build-ids changed.
So what do you think about going to fewer stages? I'd like to solicit
explicit feedback from the involved parties:
gcc maintainers / Matthias:
* Do you have any objections to reducing stages?
* Should we delete gcc stage2?
* Should we rename gcc stage3 to gcc stage2?
glibc maintainers / Aurelien:
* Do you have any objections to reducing stages?
* Should we delete glibc stage1?
* Should we rename glibc stage2 to glibc stage1?
* Should we maybe split stage2 into a number of profiles
pkg.glibc.noselinux, pkg.glibc.noxen, pkg.glibc.noalphaev,
pkg.glibc.noxcryptdep?
Due to these open questions, I've tagged the bug moreinfo.
Helmut
diff --minimal -Nru cross-toolchain-base-45/debian/changelog
cross-toolchain-base-45+nmu1/debian/changelog
--- cross-toolchain-base-45/debian/changelog2020-03-22 14:02:54.0
+0100
+++ cross-toolchain-base-45+nmu1/debian/changelog 2020-04-15
11:35:18.0 +0200
@@ -1,3 +1,10 @@
+cross-toolchain-base (45+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Bootstrap with fewer stages. (Closes: #-1)
+
+ -- Helmut Grohne Wed, 15 Apr 2020 11:35:18 +0200
+
cross-toolchain-base (45) unstable; urgency=medium
* Build using glibc 2.30-2.
diff --minimal -Nru cross-toolchain-base-45/debian/rules
cross-toolchain-base-45+nmu1/debian/rules
--- cross-toolchain-base-45/debian/rules2020-03-22 14:02:01.0
+0100
+++ cross-toolchain-base-45+nmu1/debian/rules 2020-04-15 11:35:18.0
+0200
@@ -343,96 +344,6 @@
ln -sf ${CROSS_GNU_TYPE}-gcov-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcov
endef
-$(stamp)build-gcc2.%: $(stamp)init-gcc $(stamp)install-glibc1.%
- @echo START $@
- cd debian/tmp.${CROSS_ARCH}/$(PF)/bin/ && \
- rm -f ${CROSS_GNU_TYPE}-gcc-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcc && \
- rm -f ${CROSS_GNU_TYPE}-cpp-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-cpp && \
- rm -f ${CROSS_GNU_TYPE}-gcov-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcov
- cd gcc && \
- PATH=${CURDIR}/debian/tmp.${CROSS_ARCH}/$(PF)/bin:${PATH} \
- LD_LIBRARY_PATH=$(call
binutils_ldpath,$*):${CURDIR}/debian/tmp.${CROSS_ARCH}/usr/lib:${CURDIR}/debian/tmp.${CROSS_ARCH}/lib
\
- DH_VERBOSE=1 \
- WITH_SYSROOT=/ \
- WITH_BUILD_SYSROOT=${CURDIR}/debian/tmp.${CROSS_ARCH} \
- DEB_STAGE=stage2 \
- PKG_IGNORE_CURRENTLY_BUILDING=1 \
- BACKPORT=false \
- DEB_BUILD_OPTIONS="$(DEB_BUILD_OPTIONS) nocheck nopgo nolto nohppa64
nojit nonvptx" \
- WITHOUT_LANG="hppa64 jit nvptx" \
- $(if $(filter $(HOST_ARCH),$(CROSS_ARCH)),FORCE_CROSS_LAYOUT=yes
WITH_BOOTSTRAP=off) \
- dpkg-buildpackage -b -uc -us -d
- touch $@
-
-$(stamp)install-gcc2.%: $(stamp)build-gcc2.%
- @echo START $@
- $(call install_gcc)
- dpkg-deb -x libgcc[124]-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
- debian/tmp.${CROSS_ARCH}
-ifneq (,$(ARM32_MULTILIBS))
- $(if $(filter $(CROSS_ARCH),armhf), \
- dpkg-deb -x libsfgcc1-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
- debian/tmp.${CROSS_ARCH}; \
- dpkg-deb -x
libsfgcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
- debian
Bug#910685: glibc: please support DPKG_ROOT
On Tue, Oct 09, 2018 at 10:09:57PM +0200, Johannes 'josch' Schauer wrote: > Currently in Debian sid, there are 57 packages that need to be installed > for the whole Essential:yes set. Most of them Depend (directly or > indirectly) on libc6. Attached patch adds $DPKG_ROOT to a couple of > places of the preinst and postinst of libc6 and that will make 37 of > these 57 install without problems. The patch adds $DPKG_ROOT in more > places than strictly necessary for just installing packages. For example > I didn't test the upgrade scenario. If you like, I can prepare a smaller > patch with only the code paths that I tested. I think that your approach is not ideal. Much of the code in the libc scripts is for ensuring that a system is not bricked and that services continue to work after a libc upgrade. When working with the chrootless mode, we cannot assume that the running kernel version or other aspects are relevant to the chroot at hand. In this case, it is much better to skip the relevant code entirely. Doing so has the additional benefit of not using debconf at all. When running in chrootless mode, there cannot be any services running, because they'd have to be chrooted. So we can simply skip all those checks. The patch becomes quite a bit simpler. > It would be nice if you could consider applying attached patch because > it is required for the majority of packages in the Essential:yes set to > be successfully installed with the --force-script-chrootless mode. > > To test you can run: > > dpkg --root "$target" --log "$target/var/log/dpkg.log" > --force-script-chrootless -i libc6_2.27-6.1_amd64.deb Yes, please. Is there anything blocking this? Without support in glibc, moving forward is a little difficult. Can you include it soonish? Helmut diff --minimal -Nru glibc-2.30/debian/changelog glibc-2.30/debian/changelog --- glibc-2.30/debian/changelog 2020-03-25 13:56:56.0 +0100 +++ glibc-2.30/debian/changelog 2020-04-14 17:39:34.0 +0200 @@ -1,3 +1,10 @@ +glibc (2.30-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Initial, minimal support for DPKG_ROOT. (Closes: #910685) + + -- Helmut Grohne Tue, 14 Apr 2020 17:39:34 +0200 + glibc (2.30-4) unstable; urgency=medium [ Aurelien Jarno ] diff --minimal -Nru glibc-2.30/debian/debhelper.in/libc.postinst glibc-2.30/debian/debhelper.in/libc.postinst --- glibc-2.30/debian/debhelper.in/libc.postinst2020-03-25 13:36:06.0 +0100 +++ glibc-2.30/debian/debhelper.in/libc.postinst2020-04-14 17:36:49.0 +0200 @@ -17,11 +17,14 @@ if [ "$type" = "configure" ] then # We don't use a registry anymore, remove the old file -rm -f /etc/ld.so.hwcappkgs +rm -f "$DPKG_ROOT/etc/ld.so.hwcappkgs" # /etc/ld.so.nohwcap code: __NOHWCAP__ +fi +if [ "$type" = configure -a -z "$DPKG_ROOT" ] +then # Load debconf module if available if [ -f /usr/share/debconf/confmodule ] ; then . /usr/share/debconf/confmodule diff --minimal -Nru glibc-2.30/debian/debhelper.in/libc.preinst glibc-2.30/debian/debhelper.in/libc.preinst --- glibc-2.30/debian/debhelper.in/libc.preinst 2020-03-25 13:38:38.0 +0100 +++ glibc-2.30/debian/debhelper.in/libc.preinst 2020-04-14 17:38:54.0 +0200 @@ -19,7 +19,7 @@ test $verA -$2 $verB } -if [ "$type" != abort-upgrade ] +if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ] then # Load debconf module if available and usable if [ -f /usr/share/debconf/confmodule ] && \ @@ -148,7 +148,7 @@ fi fi -if [ "$type" = upgrade ] +if [ "$type" = upgrade -a -z "$DPKG_ROOT" ] then if [ -n "$preversion" ] && [ -x "$(which ischroot)" ] && ! ischroot; then # NSS authentication trouble guard @@ -246,8 +246,8 @@ # unconditionally wipe ld.so.cache on major version upgrades; this # makes those upgrades a bit slower, but is less error-prone than # hoping we notice every time the cache format is changed upstream - rm -f /etc/ld.so.cache - rm -f /var/cache/ldconfig/aux-cache + rm -f "$DPKG_ROOT/etc/ld.so.cache" + rm -f "$DPKG_ROOT/var/cache/ldconfig/aux-cache" fi fi diff --minimal -Nru glibc-2.30/debian/script.in/nohwcap.sh glibc-2.30/debian/script.in/nohwcap.sh --- glibc-2.30/debian/script.in/nohwcap.sh 2019-08-16 12:57:33.0 +0200 +++ glibc-2.30/debian/script.in/nohwcap.sh 2020-04-14 17:39:30.0 +0200 @@ -18,5 +18,5 @@ # one, we could remove /etc/ld.so.nohwcap. Otherwise, it will be removed # when all optimized packages are upgraded or removed. if [ "$all_upgraded" = yes ] ; then -rm -f /etc/ld.so.nohwcap +rm -f "$DPKG_ROOT/etc/ld.so.nohwcap" fi
Bug#954393: please Breaks: libc6-dev-${DEB_HOST_ARCH}-cross (<< ${CURRENT_UPSTREAM_VERSION})
Package: libc6-dev
Version: 2.30-2
Severity: wishlist
Every time a new glibc upstream release gets uploaded,
cross-toolchain-base breaks in difficult to diagnose ways. This seems to
happen, because gcc uses the libc6-dev:somearch headers together with
libc6-dev-somearch-cross libraries.
Would you agree to have libc6-dev declare
Breaks: libc6-dev-${DEB_HOST_ARCH}-cross (<< ${CURRENT_UPSTREAM_VERSION}~)
where CURRENT_UPSTREAM_VERSION would presently be 2.30? I think that'd
spare us from diagnosing these issues in general.
Helmut
Bug#954392: libc6-dev-armhf-cross is incompatible with current libc6-dev:armhf
Package: libc6-dev-armhf-cross Version: 2.29-9cross1 Severity: serious The current libc6-dev-armhf-cross is incompatible with libc6-dev:armhf versioned >= 2.30. Typical symptoms include (mips64el this time, but also reproducible for armhf): /usr/lib/gcc-cross/mips64el-linux-gnuabi64/9/../../../../mips64el-linux-gnuabi64/bin/ld: /lib/mips64el-linux-gnuabi64/libpthread.so.0: undefined reference to `__twalk_r@GLIBC_PRIVATE' /usr/lib/gcc-cross/mips64el-linux-gnuabi64/9/../../../../mips64el-linux-gnuabi64/bin/ld: /lib/mips64el-linux-gnuabi64/libsystemd.so: undefined reference to `gettid@GLIBC_2.30' This seems to happen, because gcc uses the glibc 2.30 headers from libc6-dev:armhf and then links the shared library from libc6-dev-armhf-cross. Deferring the sysroot library path after the multiarch library path might solve this. In the mean time, please rebuild cross-toolchain-base with glibc >= 2.30. Helmut
Bug#946396: glibc+libxcrypt breaks cross-toolchain-base
Source: glibc Version: 2.29-5 Severity: serious Justification: installation failure Control: affects -1 + src:cross-toolchain-base Since glibc added dependencies on libxcrypt, building cross-toolchain-base produces packages that are not installable: | $ dpkg-deb -I libc6-dev-arm64-cross_2.29-5cross1_all.deb | new Debian package, version 2.0. | size 2261068 bytes: control archive=12892 bytes. | 833 bytes,17 lines control |40350 bytes, 515 lines md5sums | Package: libc6-dev-arm64-cross | Version: 2.29-5cross1 | Section: libdevel | Priority: optional | Architecture: all | Maintainer: GNU Libc Maintainers | Source: cross-toolchain-base (42) | Provides: libc-dev-arm64-cross, libc6-dev-arm64-dcv1 | Depends: libc6-arm64-cross (= 2.29-5cross1), linux-libc-dev-arm64-cross, libcrypt1-dev-arm64-cross | Conflicts: libc0.1-dev-arm64-cross, libc0.3-dev-arm64-cross, libc6.1-dev-arm64-cross | Description: GNU C Library: Development Libraries and Header Files (for cross-compiling) | This package was generated by dpkg-cross for cross compiling. | . | Contains the symlinks, headers, and object files needed to compile | and link programs which use the standard C library. | Built-Using: binutils (= 2.33.1-5), linux (= 5.3.15-1), gcc-9 (= 9.2.1-21), glibc (= 2.29-5) | Multi-Arch: foreign | $ However, there is no libcrypt1-dev-arm64-cross package produced by anything in the archive. For this reason glibc/2.29-5 should not migrate to testing until there is a solution to this problem. Helmut
Bug#916588: libc6: uses non-essential runlevel in preinst and postinst
Package: libc6 Version: 2.28-2 Severity: minor While upgrading libc6 from 2.27-8 to 2.28-2, I saw this: | Checking for services that may need to be restarted... | Checking init scripts... | /var/lib/dpkg/tmp.ci/preinst: 320: /var/lib/dpkg/tmp.ci/preinst: runlevel: not found That's libc6's preinst using runlevel. I also saw this: | Checking for services that may need to be restarted... | Checking init scripts... | /var/lib/dpkg/info/libc6:amd64.postinst: 81: /var/lib/dpkg/info/libc6:amd64.postinst: runlevel: not found | Nothing to restart. That's the same thing for postinst. The message is completely harmless. It's from debian/script.in/nsscheck.sh and tells. When runlevel is not available, we're not running any of sysvinit, systemd or runit and very likely no services are running. In that case, the result is irrelevant and the only negative effect is the message. The upgrade proceeds successfully. Helmut
Re: Propose requiring Python 3.4 or later for building glibc.
On Mon, Oct 22, 2018 at 11:38:15AM -0400, Carlos O'Donell wrote: > It is possible that the build *and* host require python 3.4. > > The reason being that when cross-testing glibc with the test-wrapper-env > script the build system may execute a command on the host system to > run python (which is usually implemented as a ssh to a target system > with a shared mounted filesystem). > > There are at least several pretty-printing tests which use python, and > require PExpect, and those run on the host during testing via the > test-wrapper-env abstraction. > > I've started a new thread of discussion here, but in general my expectation > has always been that host and build environments need the same set of tools. > > https://www.sourceware.org/ml/libc-alpha/2018-10/msg00395.html I should have thought of testing indeed. In Debian, we tend to turn testing off completely for a bootstrap and then rebuild the world (using the bootstraped packages) with testing enabled. This is done, because it removes a pile of dependencies and makes the problem a bit more manageable. So as long as tests can be disabled (preferably without changing the build result in terms of reproducible builds[1]), the cross bootstrap won't be impacted. In any case, requiring Python 3 for testing does not seem to be a new thing. The dependency is already there and it is not causing problems now. So from a cross bootstrap pov, I'm fine here. Helmut [1] We also use reproducible builds to validate cross buildt packages against natively built (with tests enabled) ones.
Re: Propose requiring Python 3.4 or later for building glibc.
On Mon, Oct 22, 2018 at 11:51:25AM +0200, Aurelien Jarno wrote: > On 2018-10-19 09:47, Carlos O'Donell wrote: > > This proposal is to being circulated to all the distribution > > maintainers to gain their acceptance surrounding the use of > > python 3.4 or greater for building glibc. > > > > There has been concern expressed that requiring python 3.4 > > or greater for the bootstrap process will add an additional > > tool the the bootstrap, and specifically a tool that may not > > be available on older distributions. > > > > Python is already mostly available for distributions because > > of the integration into key OS components. Python can be > > built on older distributions, and on older distributions you > > already have to build a lot of things to compile glibc (like > > a newer gcc, and binutils). > > > > The question today is: > > > > * Is it OK to require python 3.4 or later to build glibc? > > [...] > > > Aurelian, > > > > Any input from Debian? > > From the Debian side, the version 3.4 is not an issue at all. The > default Python 3 version in unstable (which is relevant for future > versions of glibc) is already 3.6. > > We also need to consider the process of bootstrapping Debian. In that > case I believe it should also be fine as Python 3 from the host system > can be used. I have added Helmut Grohne in Cc: who is much more aware > of the bootstrapping process than me, and can confirm or infirm that. I fear we need more precision here. There are multiple ways to bootstrap Debian. There is "cross bootstrap" for jumping from one Debian architecture to another, which is what I work on. As long as glibc only needs to run the build architecture Python, I see no problems here. I assume that you are not trying to integrate with the host architecture Python as that would pose interesting problems. Given that Debian's cross bootstraps are version locked, I don't see problems with requiring recent versions either. In contrast, I'd love to be able to use Python 3 in Debian's glibc packaging. Also note that Debian's linux packaging already requires Python 3 (for the build architecture) for quite a while already. >From a Debian cross bootstrap pov, no problems are to be expected. Daniel Schepler is working on a native bootstrap approach. As far as I understand, he natively bootstraps Debian from non-Debian (same processor architecure and kernel). I expect that his work will be impacted by the proposed change. I've added him to Cc to let him speak up. Requiring Python modules or extensions is another question. Some modules (e.g. six) are easy, but ones with dependencies of their own tend to not be. That's rooted in the way Debian handles cross architecture dependencies unfortunately. Thank you for reaching out in advance of the change and for relaying the message to non-subscribers. Helmut
Bug#798955: How to deal with gcc's with multiarch glibc headers?
Hi, I was offered some CPU cycles to research the impact of #798955 (moving glibc's headers to /usr/include/). I'll post another mail with a summary, but there is already one quite obvious issue affecting multiple packages. The implications are not quite clear to me, so maybe someone else can chime in? /usr/include/c++/8/cstdlib contains the following code: | // Need to ensure this finds the C library's not a libstdc++ | // wrapper that might already be installed later in the include search path. | #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS | #include_next | #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS After fixing #798955, glibc's stdlib.h will live in /usr/include/. One can figure out the default include search path with "gcc -E -Wp,-v - comes before /usr/include. Adding -x c++ gives the search path for C++. Notably /usr/include/c++/8 comes before both others. Now most of the time, that works, but some packages (such as chromium-browser, fcitx-qt5, fw4spl, or gemma) insist on adding some -isystem /usr/include/. That changes order and one can get: | /usr/include/c++/8/cstdlib:75:15: fatal error: stdlib.h: No such file or directory | #include_next |^~ | compilation terminated. You can trigger the very same error on a standard sid system using -isystem /usr/include: | echo '#include ' | g++ -isystem /usr/include -x c++ -E - >/dev/null After messing with system include order, that's a little expected, but I wonder whether it should work anyway. Now gcc also ships /usr/include/c++/8/stdlib.h which starts with: | #if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS | # include_next | #else So it seems that if we replaced the #include_next in cstdlib with a plain #include, it should always work, regardless of the search order: If glibc's header comes first, all is fine. Otherwise, the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro will instruct gcc's stdlib.h to #include_next glibc's stdlib.h, so it should also be fine. What I don't understand is: why does cstdlib use #include_next at all? What problem is solved by not using plain #include? Then the question arises whether adding /usr/include/ via -isystem is something that should work. Should we fix chromium-browser et al here? Thanks in advance Helmut
Bug#902800: glibc FTBFS: dh_installdocs: Cannot find (any matches for) "BUGS" (tried in .)
Source: glibc Version: 2.27-3 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: ftbfs User: helm...@debian.org Usertags: rebootstrap glibc fails to cross build from source. An arch-only build log (using DEB_BUILD_OPTIONS=nocheck to speed things up) on amd64 ends with: | dh_installdocs -plibc6 | dh_installdocs: Cannot find (any matches for) "BUGS" (tried in .) | | make: *** [debian/rules.d/debhelper.mk:27: /<>/stamp-dir/binaryinst_libc6] Error 2 | dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned exit status 2 A certain coincidence with the debhelper/11.3.5 upload cannot be ruled out. debhelper maintainers Cced. A timely fix is appreciated as this breaks bootstrap QA. Helmut
Bug#898743: breaks when #included after
Package: linux-libc-dev,libc6-dev Severity: serious Justification: makes systemd ftbfs User: helm...@debian.org Usertags: rebootstrap Control: affects -1 + src:systemd libmount-dev systemd FTBFS here, because compiling load-fragment.c fails. I spent a while minimizing that file and it boils down to: $ cat test.c #include #include $ gcc -c test.c In file included from test.c:1:0: /usr/include/x86_64-linux-gnu/sys/mount.h:35:3: error: expected identifier before numeric constant MS_RDONLY = 1, /* Mount read-only. */ ^ $ linux/fs.h #defines MS_RDONLY and then sys/mount.h tries to create an enum containing MS_RDONLY. That's a problem. This is also known in fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1497501 That bug hints that sometimes headers need to #included in a certain order. If that is the case, this bug should be reassigned to src:systemd asking that or must be #included before . It also means that should #include before defining its own copies of these macros. Helmut PS: Let me briefly curse systemd for their use of cyclic #includes (unit.h <-> cgroup.h) and #pragma once as that works pretty badly with creduce. Thank you.
Bug#892126: glibc: stage1 build failure due to missing multilib lib-names-*.h
Source: glibc Version: 2.27-1 User: helm...@debian.org Usertags: rebootstrap Hi Aurelien, I need a bug number for tracking this issue, so I am filing this bug summarizing the problem and recording my knowledge. Building glibc with DEB_BUILD_OPTIONS=nocheck DEB_BUILD_PROFILES=stage1 presently fails (even natively) on architectures with multilib packages. The symptom always is that some variant of a multilib lib-names-*.h goes missing in the packaging part of the installation procedure recently added. The headers in question are not generated during a (stage1) build and a gcc stage2 (the only relevant user) does not use them. I verified that simply not installing them makes a bootstrap of e.g. mips work again: sed -i -e 's#debian/tmp-.*/usr/include/gnu/lib-names.*\.h#$(if $(filter stage1,$(DEB_BUILD_PROFILES)),,&)#' debian/sysdeps/*.mk Now I am not asking you to include this fix (thus not adding a patch tag), because we both know it is ugly, but I am recording the workaround to improve our understanding. It confirms our intuition that the same workaround as for gnu/stubs.h should be applicable here. My attempts at implementing that properly weren't fruitful thus far. So all I can do now is document the problem. Helmut
Bug#886315: libc6-dev-$arch-cross incompatible with libc6-dev:$arch: glibc major version skew
Package: libc6-dev-arm64-cross,libc6-dev-armel-cross,libc6-dev-armhf-cross,libc6-dev-mips-cross,libc6-dev-mips64el-cross,libc6-dev-mipsel-cross,libc6-dev-ppc64el-cross,libc6-dev-s390x-cross Version: 2.25-3cross1 Severity: important User: helm...@debian.org Usertags: rebootstrap Control: block -1 by 886301 The cross-toolchain-base package in unstable is still built from glibc 2.25 while unstable has glibc 2.26. When both are installed, gcc seems to pick e.g. -lpthread from libc6-dev:$arch and -lc from libc6-dev-$arch-cross. That can result in: //lib/powerpc64le-linux-gnu/libpthread.so.0: undefined reference to `__mmap@GLIBC_PRIVATE' Try configuring src:nvi to reproduce. Please reupload cross-toolchain-base. You probably want to wait for the fix of #886301 though. This is not super exciting, but I need a bug number. Helmut
Bug#886301: glibc: logme removal accidentally breaks stage1
Source: glibc
Version: 2.26-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Hi Aurelien,
pkg-glibc commit 74784d0d9e06adb57047548685e79ea0223a05ac
("debian/rules, debian/rules.d/build.mk: stop logging build/check
messages to files, both sbuild and debuild are able to do that.")
accidentally breaks stage1. It fails to remove a closing brace
corresponding to a prior logme call for install-headers, which is stage1
only code. It's a simple typo.
Helmut
--- a/debian/rules.d/build.mk
+++ b/debian/rules.d/build.mk
@@ -166,7 +166,7 @@
ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
$(MAKE) -C $(DEB_BUILDDIR) $(NJOBS) \
cross-compiling=yes install_root=$(CURDIR)/debian/tmp-$(curpass)
\
- install-bootstrap-headers=yes install-headers )
+ install-bootstrap-headers=yes install-headers
install -d $(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)
install -m 644 $(DEB_BUILDDIR)/csu/crt[01in].o
$(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)/.
Bug#883186: e2fsprogs FTBFS on mips64el: undefined reference to `posix_fadvise64'
Source: e2fsprogs Version: 1.43.7-1 Severity: serious Justification: FTBFS User: helm...@debian.org Usertags: rebootstrap I was investigating a bootstrap failure for mips64el (https://jenkins.debian.net/job/rebootstrap_mips64el_gcc7_nobiarch/51) and wondered whether this was a native issue. Indeed a native build of e2fsprogs fails on mips64el and the build log ends as follows: | /usr/bin/make -C /home/helmutg/e2fsprogs-1.43.7/debian/BUILD-STD/e2fsck V=1 e2fsck.static | make[1]: Entering directory '/home/helmutg/e2fsprogs-1.43.7/debian/BUILD-STD/e2fsck' | gcc -Wl,-z,relro -Wl,-z,now -static -o e2fsck.static unix.o e2fsck.o super.o pass1.o pass1b.o pass2.o pass3.o pass4.o pass5.o journal.o badblocks.o util.o dirinfo.o dx_dirinfo.o ehandler.o problem.o message.o quota.o recovery.o region.o revoke.o ea_refcount.o rehash.o logfile.o sigcatcher.o readahead.o extents.o ../lib/libsupport.a ../lib/libext2fs.a ../lib/libcom_err.a -lpthread -lblkid -luuid -luuid -luuid ../lib/libe2p.a -ldl -lblkid | logfile.o: In function `expand_percent_expression': | ./debian/BUILD-STD/e2fsck/../../../e2fsck/logfile.c:141: warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking | ../lib/libext2fs.a(unix_io.o): In function `unix_cache_readahead': | ./debian/BUILD-STD/lib/ext2fs/../../../../lib/ext2fs/unix_io.c:969: undefined reference to `posix_fadvise64' | ./debian/BUILD-STD/lib/ext2fs/../../../../lib/ext2fs/unix_io.c:969: undefined reference to `posix_fadvise64' | collect2: error: ld returned 1 exit status | Makefile:428: recipe for target 'e2fsck.static' failed | make[1]: *** [e2fsck.static] Error 1 | make[1]: Leaving directory '/home/helmutg/e2fsprogs-1.43.7/debian/BUILD-STD/e2fsck' | debian/rules:262: recipe for target 'debian/stampdir/build-std-stamp' failed | make: *** [debian/stampdir/build-std-stamp] Error 2 | dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 Since this could either be a mips issue or a glibc issue, I put both lists into X-Debbugs-Cc and hope that someone will sort this out. Helmut
Bug#882263: libc6-dev-mips64el-cross breaks linking executables
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#869717: glibc FTBFS: Error: `loc1@GLIBC_2.2.5' can't be versioned to common symbol 'loc1'
Source: glibc Version: 2.24-12 Severity: serious Tags: patch upstream fixed-upstream Forwarded: https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=388b4f1a02f3a801965028bbfcd48d905638b797 User: helm...@debian.org Usertags: rebootstrap glibc fails to build from source in unstable amd64: | x86_64-linux-gnu-gcc-6 -no-pie -fno-PIE regexp.c -c -std=gnu11 -fgnu89-inline -O2 -Wall -Werror -Wundef -Wwrite-strings -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes -Wold-style-definition -fPIC -ftls-model=initial-exec-isystem /<>/debian/include -I../include -I/<>/build-tree/amd64-libc/misc -I/<>/build-tree/amd64-libc -I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/x86_64/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu -I../sysdeps/x86_64/multiarch -I../sysdeps/x86_64 -I../sysdeps/x86 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/6/include -isystem /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed -isystem /<>/debian/include -D_LIBC_REENTRANT -include /<>/build-tree/amd64-libc/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h -DPIC -DSHARED -o /<>/build-tree/amd64-libc/misc/regexp.os -MD -MP -MF /<>/build-tree/amd64-libc/misc/regexp.os.dt -MT /<>/build-tree/amd64-libc/misc/regexp.os | x86_64-linux-gnu-gcc-6 -no-pie -fno-PIE ../sysdeps/unix/sysv/linux/getloadavg.c -c -std=gnu11 -fgnu89-inline -O2 -Wall -Werror -Wundef -Wwrite-strings -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes -Wold-style-definition -fPIC -ftls-model=initial-exec -isystem /<>/debian/include -I../include -I/<>/build-tree/amd64-libc/misc -I/<>/build-tree/amd64-libc -I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/x86_64/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu -I../sysdeps/x86_64/multiarch -I../sysdeps/x86_64 -I../sysdeps/x86 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/6/include -isystem /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed -isystem /<>/debian/include -D_LIBC_REENTRANT -include /<>/build-tree/amd64-libc/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h -DPIC -DSHARED -o /<>/build-tree/amd64-libc/misc/getloadavg.os -MD -MP -MF /<>/build-tree/amd64-libc/misc/getloadavg.os.dt -MT /<>/build-tree/amd64-libc/misc/getloadavg.os | x86_64-linux-gnu-gcc-6 -no-pie -fno-PIE ../sysdeps/unix/sysv/linux/getclktck.c -c -std=gnu11 -fgnu89-inline -O2 -Wall -Werror -Wundef -Wwrite-strings -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes -Wold-style-definition -fPIC -ftls-model=initial-exec -isystem /<>/debian/include -I../include -I/<>/build-tree/amd64-libc/misc -I/<>/build-tree/amd64-libc -I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/x86_64/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu -I../sysdeps/x86_64/multiarch -I../sysdeps/x86_64 -I../sysdeps/x86 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/6/include -isystem
Bug#840260: glibc: please support the tilegx architecture
Hi Aurelien, On Sat, Oct 15, 2016 at 09:15:36PM +0200, Aurelien Jarno wrote: > Unfortunately this is not enough. Recent dak versions check that the > architecture is known by dpkg, and ftp-master.debian.org is using > jessie. If we add tilegx to the Architecture: list, the source package > will then get rejected. I agree. > Please see #835851. Until this is solved or until ftp-master.debian.org > is fixed, you will have to maintain the patch on your side. I think this works rather well for me. You took the include change, which is more relevant for me. rebootstrap automatically adds any architectures that are missing from all libc*_archs to libc6_archs, so there is nothing for me to maintain here. I probably won't even notice when you apply it. I hope it is ok for you to simply wait until dak has a sufficiently recent dpkg and then add it. Bringing up full tilegx will take a while anyway. Next up will be sending a patch for libatomic-ops. Thanks for your support here. Helmut
Bug#840260: glibc: please support the tilegx architecture
Source: glibc Version: 2.24-3 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Aurelien, Can you add support for the tilegx architecture to glibc? dpkg knows about the architecture since 1.18.8 and gcc-6 has some preliminary support already. The patch is quite small. Beyond adding it to libc6_archs, care needs to be taken to use arch-specific linux headers from /usr/include//arch. After applying the patch, debian/control must be regeneratd (not included in the patch). Can you maintain the diff? Helmut diff --minimal -Nru glibc-2.24/debian/changelog glibc-2.24/debian/changelog --- glibc-2.24/debian/changelog 2016-09-17 20:00:44.0 +0200 +++ glibc-2.24/debian/changelog 2016-10-10 06:36:11.0 +0200 @@ -1,3 +1,10 @@ +glibc (2.24-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Support tilegx. (Closes: #-1) + + -- Helmut Grohne <hel...@subdivi.de> Mon, 10 Oct 2016 06:36:01 +0200 + glibc (2.24-3) unstable; urgency=medium [ Aurelien Jarno ] diff --minimal -Nru glibc-2.24/debian/rules.d/control.mk glibc-2.24/debian/rules.d/control.mk --- glibc-2.24/debian/rules.d/control.mk2016-09-04 01:26:39.0 +0200 +++ glibc-2.24/debian/rules.d/control.mk2016-10-10 06:35:57.0 +0200 @@ -1,7 +1,7 @@ libc_packages := libc6 libc6.1 libc0.1 libc0.3 libc0_1_archs := kfreebsd-amd64 kfreebsd-i386 libc0_3_archs := hurd-i386 -libc6_archs := amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh4 x32 +libc6_archs := amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh4 tilegx x32 libc6_1_archs := alpha control_deps := $(wildcard debian/control.in/*) $(addprefix debian/control.in/, $(libc_packages)) diff --minimal -Nru glibc-2.24/debian/sysdeps/linux.mk glibc-2.24/debian/sysdeps/linux.mk --- glibc-2.24/debian/sysdeps/linux.mk 2016-09-04 01:26:39.0 +0200 +++ glibc-2.24/debian/sysdeps/linux.mk 2016-10-10 06:35:21.0 +0200 @@ -39,6 +39,11 @@ else \ ln -s $(LINUX_HEADERS)/asm debian/include ; \ fi + if [ -d "$(LINUX_ARCH_HEADERS)/arch" ]; then \ + ln -s $(LINUX_ARCH_HEADERS)/arch debian/include ; \ + else \ + ln -s $(LINUX_HEADERS)/arch debian/include ; \ + fi ln -s $(LINUX_HEADERS)/asm-generic debian/include ln -s $(LINUX_HEADERS)/linux debian/include
Bug#817944: nios2 support
Source: glibc Version: 2.22-2 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap Dear glibc maintainers, >From a Debian pov, nios2 is a pretty new architecture. It has been added to dpkg in version 1.18.4. Marek Vasut has been working on actually bootstrapping the port and things seem to be going well. At this time, we need one binutils patch[1] and one gcc patch[2], both of which are upstream already. The matter for glibc is rather simple as well with sed -i -e 's/^libc6_archs *:=.*/& nios2/' debian/rules.d/control.mk and then regenerating debian/control. No further nios2 patches on top of Debian unstable are necessary to bootstrap the toolchain. Can you apply this patch? Helmut [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=patch;h=a7be2893a6449e64fe6cfcdd8700b0a367a69f19 [2] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=1d67120d95c2c6e0ed4f7357d1cc62887eaba463
Bug#806912: Don't build optimized variants in stage1 or stage2 builds
On Wed, Dec 02, 2015 at 09:20:58PM +0100, Matthias Klose wrote: > Package: src:glibc > Version: 2.21-1 > Tags: patch > > Don't build optimized variants in stage1 or stage2 builds; saves a pass on > alpha and i386. I think that the functionality requested here is useful, but I have a few remarks on the implementation. 1) stage1 shouldn't be doing any non *-dev passes at all, so limiting these here is less than ideal. 2) The ability to build without optimized packages is useful beyond bootstrapping and it also is not required for bootstrapping, so I'd rather see an orthogonal profile be used here. We already have a number of "no*" profile names (e.g. noudeb, nodoc, nobiarch, ...) and we could certainly expand that. 3) When limiting packages to certain profiles, debian/control should be updated to reflect that. Helmut
Bug#773300: Improve glibc bootstrap
In the mean time, the other patch #766877 was merged into experimental.
Time to review this bug. Unfortunately, the original submission lacks
details on what problems are being solved, so assessing the solutions is
difficult and I do not understand all the aspects.
| diff -urN debian/rules /usr/src/glibc/debian/rules
| --- debian/rules 2015-03-18 11:08:54.0 +
| +++ /usr/src/glibc/debian/rules 2015-05-10 07:31:39.0 +
| @@ -140,8 +140,12 @@
| endif
| endif
|
| +ifeq ($(DEB_STAGE),stage2)
| + DEB_BUILD_PROFILES+=stage2
| +endif
| +
Do we still want to support DEB_STAGE or DEB_BUILD_PROFILE? Maybe we can
just remove support for these variables in 2.21 entirely?
| ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
| - DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev
| + DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev $(libc)
I still disagree with this approach. The underlying problem is that
currently the resulting libc-dev packages from stage1 cannot be
installed, because they depend on libc packages that are not built in
stage1. I think that generating empty libc packages is wrong and that
the dependencies should be dropped in stage1 instead.
|DEB_INDEP_REGULAR_PACKAGES =
|DEB_UDEB_PACKAGES =
| else
| diff -urN debian/rules.d/build.mk /usr/src/glibc/debian/rules.d/build.mk
| --- debian/rules.d/build.mk 2015-03-19 20:28:42.0 +
| +++ /usr/src/glibc/debian/rules.d/build.mk2015-05-10 07:31:39.0
+
| @@ -160,10 +160,19 @@
| cross-compiling=yes install_root=$(CURDIR)/debian/tmp-$(curpass)
\
| install-bootstrap-headers=yes install-headers )
|
| - install -d $(CURDIR)/debian/tmp-$(curpass)/lib
| - install -m 644 $(DEB_BUILDDIR)/csu/crt[1in].o
$(CURDIR)/debian/tmp-$(curpass)/lib
| - ${CC} -nostdlib -nostartfiles -shared -x c /dev/null \
| - -o $(CURDIR)/debian/tmp-$(curpass)/lib/libc.so
| + install -d $(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)
| + install -m 644 $(DEB_BUILDDIR)/csu/crt[1in].o
$(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)
| + $(call xx,CC) -nostdlib -nostartfiles -shared -x c /dev/null \
| + -o $(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)/libc.so
Fixed in experimental.
| + if [ $(curpass) = libc ]; then \
| + mkdir -p debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/bits
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/gnu
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/sys
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/fpu_control.h
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/a.out.h
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/ieee754.h
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + fi
I would appreciate an explanation on what problem this hunk solves.
| else
| : # FIXME: why just needed for ARM multilib?
| case "$(curpass)" in \
| diff -urN debian/rules.d/debhelper.mk
/usr/src/glibc/debian/rules.d/debhelper.mk
| --- debian/rules.d/debhelper.mk 2015-03-19 22:15:39.0 +
| +++ /usr/src/glibc/debian/rules.d/debhelper.mk2015-05-10
12:12:25.937141495 +
| @@ -109,7 +109,8 @@
| ./debian/shlibs-add-udebs $(curpass)
|
| dh_installdeb -p$(curpass)
| - dh_shlibdeps -p$(curpass)
| + [ -n "$$(echo $(curpass) | grep 'mips32')" ] &&
o32_libs="-l$(CURDIR)/debian/$(curpass)/libo32/"; \
| +dh_shlibdeps $$o32_libs -p$(curpass)
Why does this special case mips32? Would it be possible to solve this
issue for more architectures by relying on slibdir instead?
| dh_gencontrol -p$(curpass)
| if [ $(curpass) = nscd ] ; then \
| sed -i -e "s/\(Depends:.*libc[0-9.]\+\)-[a-z0-9]\+/\1/"
debian/nscd/DEBIAN/control ; \
| @@ -179,7 +180,7 @@
|
| # Generate common substvars files.
| : > tmp.substvars
| -ifeq ($(filter stage2,$(DEB_BUILD_PROFILES)),)
| +ifeq ($(filter stage1 stage2,$(DEB_BUILD_PROFILES)),)
| echo 'libgcc:Depends=libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4
[hppa]' >> tmp.substvars
| endif
The gcc stage2 (which can be built with glibc stage1 packages) includes
libgccN packages. Thus the dependency is satisfiable in stage2. Dropping
it here should not be necessary and I think it also is wrong.
|
| @@ -197,9 +198,20 @@
| slibdir=$(call xx,slibdir) ; \
| rtlddir=$(call xx,rtlddir) ; \
| curpass=$(curpass) ; \
| - templates="libc-dev" ;\
| - pass="" ; \
| - suffix="" ;\
| + templates="libc-dev" ; \
| + case "$$curpass:$$slibdir" in \
| + libc:*) \
| + suffix="" \
| + pass="" \
| +
Bug#797831: glibc: further problems with stage1
Hi Aurelien, On Tue, Sep 08, 2015 at 07:58:13PM +0200, Aurelien Jarno wrote: > Thanks for the patch and the detailed explanation. The changes make sense, > so I have applied the patch. Thank you. > That said looking as this part of the code as a whole, it ends up being a > bit complicated. Basically we define defaults value before the case, but > then we basically handle all cases. Then we use a for loop as a if, as > $templates contains either zero or one value. I concur with that observation. > The complexity comes from the fact this piece of code has been forked from > the non-staged one. I therefore wonder if we should try to either: > 1) Simplify it. > 2) make it as common as possible with the non-stage code. I believe it's > not a problem if we generate debhelper files that we don't use in > practice, as long as the stage ones are correct. Maybe we should try 3) merge it into the non-stage code? Having these two cases separate has the disadvantage that they will go out of sync as the non-staged variant is adapted to the current needs. We should strive for minimal differences in stage1 to minimize its maintenance cost. So what actually is the difference between these two implementations of the debhelper-common target? If I am not mistaken it is: * Generate fewer debhelper templates. As you observed there is no harm in just generating them anyway. * Interpolate more variables, in particular RTLD_SO. They are not used in the libc-dev templates. The computation of the shell variable rtld_so would probably result in garbage as debian/tmp-*/usr/bin/iconv will be missing, but maybe it still succeeds (from an exit code pov). * Remove lines containing LIBDIR in stage1. Unless I am missing something, this is the only relevant difference. So maybe one could have something along the lines. ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),) STAGE1_TEMPLATE_FILTER= else STAGE1_TEMPLATE_FILTER=sed -e "/LIBDIR.*\.a /d" $$t fi and then add "$(STAGE1_TEMPLATE_FILTER);" to the pile of sed invocations in the non-stage1 code path while eliminating the stage1 block altogether. Do you think this idea would be worth trying and preparing a proper patch? Do you have a better name for that strange make variable? Helmut
Bug#798064: glibc: please find kfreebsd-kernel-headers in multiarch path
Hi Steven, On Sat, Sep 05, 2015 at 01:50:02AM +0100, Steven Chamberlain wrote: > We're hoping to move kfreebsd-kernel-headers' files to multiarch > path /usr/include/$(DEB_TARGET_MULTIARCH), so that headers of other > kernels are co-installable on a build machine (for cross-building and > bootstrapping). Thanks for doing that work! > Please could glibc be patched as attached, to always look in that > directory for system includes, even for native builds (HOST==BUILD). I'm not quite sure how much backwards compatibility we need here and your patch probably breaks that. In former times (before multiarch based cross building) cross libraries were installed in a sysroot, typically /usr/$(DEB_HOST_GNU_TYPE). The package dpkg-cross was used to convert regular :$(DEB_HOST_ARCH) packages to -$(DEB_HOST_ARCH)-cross:all packages and convert the paths in the same way. (In jenkins.d.n/view/rebootstrap this method is called "supported", because it is the only way supported by the gcc maintainers.) So maybe we could find a way that works for both the "dpkg-cross" way (at least in theory) and the multiarch way. For linux this is not sorted out either yet. The relevant code here is in debian/sysdeps/linux.mk: | ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) | LINUX_HEADERS := /usr/include | else | LINUX_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include | endif | LINUX_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH) The patch in bug #773300 (which is mostly obsolete due to merging #766877), suggests to change this ifeq to the following line. | ifeq ($(shell dpkg-query --status linux-libc-dev-$(DEB_HOST_ARCH)-cross 2>/dev/null),) It might make sense to do something similar for kfreebsd, but I was still wondering whether this particular test method works in all relevant cases. Aurelien, I shall follow up to #773300 again and explain what parts of that bug are still applicable. > - ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) > -KFREEBSD_HEADERS := /usr/include > - else > -KFREEBSD_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include > - endif > + KFREEBSD_HEADERS := /usr/include/$(DEB_TARGET_MULTIARCH) Using target variables is wrong here. It might work (because target defaults to host), but it doesn't make sense semantically. This must be DEB_HOST_MULTIARCH here. Target variables are only relevant for compilers, but glibc isn't a compiler. Helmut
Bug#797831: glibc: further problems with stage1
Source: glibc Version: 2.21-0experimental1 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Aurelien, thank you very much for applying #766877 and uploading to experimental. This has moved us a big step closer to a working stage1. We are not quite there yet. At this point I estimate a remaining patch stack for the following problems: * stage1 fails to build for various reasons * stage1 libc6-dev not installable due to dependency on libc6 * wrong set of packages being built for stage1 * dh_shlibdeps fails * linux headers cannot be found * various hurd things Even though I still carry patches for these, it is not clear that all of these problems are still reproducible. The above list is meant as an outlook, not a cumulative bug report. This particular bug shall address only the first of those problems above, because I have a good understanding and can answer your questions. I am attaching a patch and also explain the individual hunks in what follows. All of them apply to stage1-specific code. - *:/lib32 | *:/lib64 | *:/libx32 | *:/lib/arm-linux-gnueabi*) \ + *:/lib32 | *:/lib64 | *:/libo32 | *:/libx32 | *:/lib/arm-linux-gnueabi*) \ The code fails to identify a certain mips architecture multilib build and thus places the multilib build into the main package. + *:* ) \ + templates="" \ + ;; \ This extra case ensures that no templates are interpolated for optimized builds (e.g. libc6-i686). These do not generate development packages anyway, so dropping them (for stage1) is the right thing to do. Failing to do so again overwrites the main package. - -e "/$$libdir.*.a /d" \ + -e "/LIBDIR.*\.a /d" \ The immediate error resulting from this sed invocation is that the command "u" is not understood by sed. $libdir becomes "/usr/lib/triplet". Thus the resulting sed command starts with "//u" which sed does not like. Fixing the escaping is not enough however, since LIBDIR is not yet interpolated. That only happens a few lines later. So instead, the match needs to target non-interpolated filenames and thus match LIBDIR. I hope that the level of detail given is sufficient. If not, please ask. Otherwise, please consider applying the patch. I would appreciate another experimental upload that also includes the hurd changes staged to SVN by Samuel Thibault already within a month from now. Thank you for your support. Helmut diff -Nru glibc-2.19/debian/rules.d/debhelper.mk glibc-2.19/debian/rules.d/debhelper.mk --- glibc-2.19/debian/rules.d/debhelper.mk +++ glibc-2.19/debian/rules.d/debhelper.mk @@ -197,10 +197,13 @@ case "$$curpass:$$slibdir" in \ libc:*) \ ;; \ - *:/lib32 | *:/lib64 | *:/libx32 | *:/lib/arm-linux-gnueabi*) \ + *:/lib32 | *:/lib64 | *:/libo32 | *:/libx32 | *:/lib/arm-linux-gnueabi*) \ pass="-alt" \ suffix="-$(curpass)" \ ;; \ + *:* ) \ + templates="" \ + ;; \ esac ; \ for t in $$templates ; do \ for s in debian/$$t$$pass.* ; do \ @@ -219,7 +219,7 @@ cp $$s $$t ; \ fi ; \ sed -i \ - -e "/$$libdir.*.a /d" \ + -e "/LIBDIR.*\.a /d" \ -e "s#TMPDIR#debian/tmp-$$curpass#g" \ -e "s#RTLDDIR#$$rtlddir#g" \ -e "s#SLIBDIR#$$slibdir#g" \
Re: Bug#787227: broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No such file or d
Control: severity -1 wishlist Control: reassign -1 libc6 Control: retitle -1 ld-linux.so loads libraries from . when /proc is not mounted Control: affects -1 + ghc Control: summary -1 0 When /proc is not mounted, a relative RPATH causes ld-linux.so to fall back to using the working directory as the base directory for RPATH resolution instead of using the (unknown) location of the executed binary. This issue is hard to diagnose, because the error message does not make it clear that fallback code is in use due to readlink /proc/self/exe failing. Furthermore, it may pose a security risk by loading libraries from unintended locations. On Sat, May 30, 2015 at 11:54:26AM -0400, Joey Hess wrote: Sorry, I meant the linker should be fixed, not ghc. Let's codify that in the bts. Steps to reproduce (for glibc maintainers): Create an unstable chroot. Install ghc. Do not mount /proc in that chroot. Execute /usr/bin/ghc. You shall see that it fails loading libraries. I assume that any binary with a relative RPATH is affected. Helmut -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150530165603.ga7...@alf.mars
Bug#784015: undeclared file conflict between libc6-i386 and libc6-mipsn32
Package: libc6-i386,libc6-mipsn32 Version: 2.19-18 User: helm...@debian.org Usertags: rebootstrap | dpkg: error processing archive /tmp/repo/pool/main/g/glibc/libc6-mipsn32_2.19-18_mips.deb (--unpack): | trying to overwrite '/usr/lib32/gconv/ANSI_X3.110.so', which is also in package libc6-i386 2.19-18 I am filing this as a new bug report instead of merging it into #745552, because I believe that this instance is easily fixable. It should be possible to have the multilib packages with matching multilib directories declare conflicts against each other as no M-A:same is involved here. The loader conflict issue shall remain with #745552. Helmut -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150502063742.ga17...@alf.mars
Bug#766877: Fix multilib enabled stage1 cross builds
On Tue, Dec 16, 2014 at 08:51:44PM +0100, Helmut Grohne wrote: Matthias patch does not work for architectures with optimized libcs (called otherarch in glibc packaging, i.e. i386, mipsel, alpha). Matthias asked to clarify my stance on this patch. The above says that the patch does not work for architectures with optimized libcs. What it doesn't say there is that the patch goes a long way to fix architectures without optimized libcs. It thus presents a good basis for further work on the bootstrap problem. I would like to see that patch merged. To be serious, the reason for me having stopped sending glibc patches is that this essential patch still has not been merged. Helmut -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150430150247.ga25...@alf.mars
Bug#780431: 2.19-16 breaks stage2 build
Package: src:glibc Version: 2.19-16 Tags: patch User: helm...@debian.org Usertags: rebootstrap The glibc 2.19-16 upload regresses the stage2 build. The regression is introudced in svn revision 6371 in debian/rules.d/debhelper.mk where tmp.substvars is no longer generated for stage2. The build fails a few lines later trying to copy tmp.substvars: | cp: cannot stat 'tmp.substvars': No such file or directory I verified that the attached patch solves the issue. Adam Conrad committed a similar fix as svn revision 6376. Helmut -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150313203600.ga31...@alf.mars
Bug#780431: 2.19-16 breaks stage2 build
On Fri, Mar 13, 2015 at 09:36:01PM +0100, Helmut Grohne wrote: I verified that the attached patch solves the issue. As Adam pointed out, my patch was missing. Sorry. But it really is equivalent to what is already in SVN. So this mostly is a confirmation. Helmut diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog --- glibc-2.19/debian/changelog 2015-03-12 22:00:48.0 +0100 +++ glibc-2.19/debian/changelog 2015-03-13 20:16:44.0 +0100 @@ -1,3 +1,10 @@ +glibc (2.19-16.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Unbreak stage2 build. (Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Fri, 13 Mar 2015 20:16:06 +0100 + glibc (2.19-16) unstable; urgency=medium [ Samuel Thibault ] diff -Nru glibc-2.19/debian/rules.d/debhelper.mk glibc-2.19/debian/rules.d/debhelper.mk --- glibc-2.19/debian/rules.d/debhelper.mk 2015-03-08 22:29:32.0 +0100 +++ glibc-2.19/debian/rules.d/debhelper.mk 2015-03-13 20:16:03.0 +0100 @@ -180,6 +180,8 @@ # Generate common substvars files. ifeq ($(filter stage2,$(DEB_BUILD_PROFILES)),) echo 'libgcc:Depends=libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4 [hppa]' tmp.substvars +else + touch tmp.substvars endif for pkg in $(DEB_ARCH_REGULAR_PACKAGES) $(DEB_INDEP_REGULAR_PACKAGES) $(DEB_UDEB_PACKAGES); do \
Bug#759530: CPU info?
On Thu, Jan 01, 2015 at 10:09:58PM +0100, Yves-Alexis Perez wrote: I'm not experiencing that bug, but maybe it'd help if the submitters would provide their /proc/cpuinfo and maybe try to get a clue about where the segfault happens (maybe with coredumps)? /proc/cpuinfo from Bernd Zeimetz (he was reporting segfaults as well): processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz stepping: 7 microcode : 0x29 cpu MHz : 813.769 cache size : 3072 KB physical id : 0 siblings: 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips: 4983.78 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Helmut -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150110201323.ga2...@alf.mars
Bug#773300: Improve glibc bootstrap
On Tue, Dec 16, 2014 at 11:39:40PM +0800, YunQiang Su wrote: Hi, the attached patch can improve bootstrapping of glibc. Partially, this seems to be a duplicate of #766877. Maybe these should be merged? It produces the similiar stage1 glibc (libc6/libc6-dev and multilib version of them), at the same time, the dependencies of them are also correct. The documentation and rationale of this patch are scarce. I have a few comments on individual hunks though. diff -Nru glibc-2.19/debian/rules glibc-2.19/debian/rules --- glibc-2.19/debian/rules 2014-10-17 07:43:19.0 + +++ glibc-2.19/debian/rules 2014-12-10 23:16:28.0 + @@ -143,8 +143,12 @@ endif endif +ifeq ($(DEB_STAGE),stage2) + DEB_BUILD_PROFILES+=stage2 +endif + ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),) - DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev + DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev $(libc) DEB_INDEP_REGULAR_PACKAGES = DEB_UDEB_PACKAGES = else I have no clue how one would build the libc in stage1. The gcc stage1 does not provide the means for doing so. If anything those packages would be empty. I.e. this seems rather wrong to me. diff -Nru glibc-2.19/debian/sysdeps/linux.mk glibc-2.19/debian/sysdeps/linux.mk --- glibc-2.19/debian/sysdeps/linux.mk 2014-07-16 18:43:31.0 + +++ glibc-2.19/debian/sysdeps/linux.mk 2014-12-10 23:11:05.0 + @@ -16,11 +16,7 @@ endif ifndef LINUX_SOURCE - ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) -LINUX_HEADERS := /usr/include - else -LINUX_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include - endif + LINUX_HEADERS := /usr/include LINUX_ARCH_HEADERS := /usr/include/$(DEB_HOST_MULTIARCH) else LINUX_HEADERS := $(LINUX_SOURCE)/include This breaks the supported cross build method. diff -Nru glibc-2.19/debian/sysdeps/mips64.mk glibc-2.19/debian/sysdeps/mips64.mk --- glibc-2.19/debian/sysdeps/mips64.mk 2014-10-17 07:43:19.0 + +++ glibc-2.19/debian/sysdeps/mips64.mk 2014-12-11 03:50:09.0 + @@ -59,5 +59,5 @@ # create a symlink for the 32 bit dynamic linker in /lib define libc6-mips32_extra_pkg_install mkdir -p debian/libc6-mips32/lib -ln -sf /libo32/ld.so.1 debian/libc6-mips32/lib +ln -sf ../libo32/ld.so.1 debian/libc6-mips32/lib endef This violates a should in Debian policy section 10.5. Helmut -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216191023.ga13...@alf.mars
Bug#766877: Fix multilib enabled stage1 cross builds
Control: user helm...@debian.org Control: usertags -1 + rebootstrap On Sun, Oct 26, 2014 at 02:23:07PM +0100, Matthias Klose wrote: The patch fixes building multilib enabled stage1 cross, by doing the call xx dance for stage1 as well, as well as generating the debhelper files for multilib stage1 packages. Matthias patch does not work for architectures with optimized libcs (called otherarch in glibc packaging, i.e. i386, mipsel, alpha). Quoting the commit message of http://anonscm.debian.org/cgit/users/helmutg/rebootstrap.git/commit/?id=b462ceb for details: | attempt at fixing glibc multilib stage1 builds | | Currently for mipsel libc6-dev and libc6-dev-mips64 (stage1) are not | coinstallable, because they have an undeclared file conflict in | /usr/include/sys. Since libc6-dev is multiarch, it shouldn't contain | that directory but use something below /usr/include/triplet. | | The cause is the debhelper tooling affected by the patch below. It is | run for each $curpass, where in case of mipsel passes include libc, | mips64 and loongson2f. The last one is interesting, because it is not | covered by either existing cases. In the non-stage1 variant of this | code, it is classified as a pass=-otherbuild. Since we don't change | templates or pass for loongson2f, the snippet overwrites the debhelper | .install files for libc causing the libc6-dev package to contain the | headers for loongson2f (in non-multiarch locations). So the non-stage1 | restricts templates to just libc for otherbuild. Since stage1 restricts | templates to libc-dev, the intersection for stage1 and otherbuild is | empty. | | Arguably, the loongson2f pass should be skipped in stage1 entirely. | | This bug should break any architecture with optimized libc packages: | * mipsel - loongon2f | * i386 - 686 (breaks in gcc earlier atm) | * alpha - alphaev67 (libc6.1-dev and libc6-dev conflict already) Helmut -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216195143.ga15...@alf.mars
Bug#756473: src:glibc: install multilib stubs-$abi.h when bootstrapping
Package: src:glibc Version: 2.19-7 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap While attempting to do multilib glibc stage1 cross builds, i noticed that certain libc*-dev-*_extra_pkg_install defines from debian/sysdeps/*.mk would fail to install absent debian/tmp-*/usr/include/gnu/stubs-*.h files. I dug into the reasons and discovered that Ubuntu's eglibc patch (in its *-cross-toolchain-base packages) would just touch the missing files. While this appears to work, I believe that it is the wrong solution, because it adds cruft. Rather, I suggest to update the place that handles them: debian/patches/any/local-bootstrap-headers.diff Looking at that patch one can see that it predates multilib as it only handles the main stubs.h, but doesn't handle the stubs-$abi.h headers. To that end, I am proposing to update said patch rather than papering over its deficiencies. This should keep the packaging simpler. Please consider the attached patch. Helmut diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog --- glibc-2.19/debian/changelog 2014-07-13 01:31:22.0 +0200 +++ glibc-2.19/debian/changelog 2014-07-30 09:29:34.0 +0200 @@ -1,3 +1,11 @@ +glibc (2.19-7.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * debian/patches/any/local-bootstrap-headers.diff: Update to handle +stubs-$abi.h which is required for multilib bootstraps. (Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Wed, 30 Jul 2014 09:28:26 +0200 + glibc (2.19-7) unstable; urgency=high * debian/patches/localedata/unsubmitted-tst-setlocale3-ENV.diff: Apply diff -Nru glibc-2.19/debian/patches/any/local-bootstrap-headers.diff glibc-2.19/debian/patches/any/local-bootstrap-headers.diff --- glibc-2.19/debian/patches/any/local-bootstrap-headers.diff 2014-07-06 10:13:13.0 +0200 +++ glibc-2.19/debian/patches/any/local-bootstrap-headers.diff 2014-07-30 09:28:22.0 +0200 @@ -1,5 +1,11 @@ Taken from EGLIBC, r1484 + r1525 +2014-07-30 Helmut Grohne hel...@subdivi.de + + * With the advent of multilib gnu/stubs.h became a meta-header that + includes the correct stubs-$abi.h. So install gnu/stubs.h as usual + and install stubs-bootstrap.h as gnu/stubs-$abi.h + 2007-02-20 Jim Blandy j...@codesourcery.com * Makefile (install-headers): Preserve old behavior: depend on @@ -33,48 +39,40 @@ + an empty stubs.h like this will do fine for GCC. */ --- a/Makefile +++ b/Makefile -@@ -68,9 +68,18 @@ - vpath %.h $(subdir-dirs) - - # What to install. --install-others = $(inst_includedir)/gnu/stubs.h - install-bin-script = +@@ -177,6 +177,13 @@ + install-others-nosubdir: $(installed-stubs) + endif +# If we're bootstrapping, install a dummy gnu/stubs.h along with the +# other headers, so 'make install-headers' produces a useable include +# tree. Otherwise, install gnu/stubs.h later, after the rest of the +# build is done. +ifeq ($(install-bootstrap-headers),yes) -+install-headers: $(inst_includedir)/gnu/stubs.h -+else -+install-others = $(inst_includedir)/gnu/stubs.h ++install-headers: $(inst_includedir)/gnu/stubs.h $(installed-stubs) +endif -+ - ifeq (yes,$(build-shared)) - headers += gnu/lib-names.h - endif -@@ -150,6 +159,16 @@ - - subdir-stubs := $(foreach dir,$(subdirs),$(common-objpfx)$(dir)/stubs) + # Since stubs.h is never needed when building the library, we simplify the + # hairy installation process by producing it in place only as the last part +@@ -184,6 +191,14 @@ + # iterates over all the subdirs; subdir_install in each subdir depends on + # the subdir's stubs file. Having more direct dependencies would result in + # extra iterations over the list for subdirs and many recursive makes. ++ifeq ($(install-bootstrap-headers),yes) +# gnu/stubs.h depends (via the subdir 'stubs' targets) on all the .o +# files in GLIBC. For bootstrapping a GCC/GLIBC pair, an empty +# gnu/stubs.h is good enough. -+ifeq ($(install-bootstrap-headers),yes) -+$(inst_includedir)/gnu/stubs.h: include/stubs-bootstrap.h $(+force) ++$(installed-stubs): include/stubs-bootstrap.h $(+force) + $(make-target-directory) + $(INSTALL_DATA) $ $@ -+ -+installed-stubs = +else - ifndef abi-variants - installed-stubs = $(inst_includedir)/gnu/stubs.h - else -@@ -176,6 +195,7 @@ - - install-others-nosubdir: $(installed-stubs) - endif + $(installed-stubs): include/stubs-prologue.h subdir_install + $(make-target-directory) + @rm -f $(objpfx)stubs.h +@@ -192,6 +207,7 @@ + then echo 'stubs.h unchanged'; \ + else $(INSTALL_DATA) $(objpfx)stubs.h $@; fi + rm -f $(objpfx)stubs.h +endif - - - # Since stubs.h is never needed when building the library, we simplify the + + # This makes the Info or DVI file of the documentation from the Texinfo source. + .PHONY: info dvi pdf html
Bug#756095: src:glibc: application of debian/patches/ia64/local-rtld-compile-options.diff fails
Package: src:glibc Version: 2.19-7 Severity: normal Tags: patch User: helm...@debian.org Usertags: rebootstrap Building of glibc for ia64 fails in application of patch debian/patches/ia64/local-rtld-compile-options.diff. I am attaching a patch that fixes the above patch. Note that my patch will not make ia64 build, because it then fails in conifgure: | checking for forced unwind support... no | configure: error: forced unwind support is required This bug is only about the patch application part though. Helmut diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog --- glibc-2.19/debian/changelog 2014-07-13 01:31:22.0 +0200 +++ glibc-2.19/debian/changelog 2014-07-26 07:41:47.0 +0200 @@ -1,3 +1,11 @@ +glibc (2.19-7.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Fix application of debian/patches/ia64/local-rtld-compile-options.diff. +(Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Sat, 26 Jul 2014 07:41:10 +0200 + glibc (2.19-7) unstable; urgency=high * debian/patches/localedata/unsubmitted-tst-setlocale3-ENV.diff: Apply diff -Nru glibc-2.19/debian/patches/ia64/local-rtld-compile-options.diff glibc-2.19/debian/patches/ia64/local-rtld-compile-options.diff --- glibc-2.19/debian/patches/ia64/local-rtld-compile-options.diff 2013-12-08 11:40:29.0 +0100 +++ glibc-2.19/debian/patches/ia64/local-rtld-compile-options.diff 2014-07-26 07:41:03.0 +0200 @@ -6,8 +6,8 @@ -D'SLIBDIR=$(slibdir)' -DIS_IN_ldconfig=1 CFLAGS-dl-cache.c = $(SYSCONF-FLAGS) CFLAGS-cache.c = $(SYSCONF-FLAGS) --CFLAGS-rtld.c = $(SYSCONF-FLAGS) -+CFLAGS-rtld.c = $(SYSCONF-FLAGS) -O1 -fno-tree-copy-prop -fno-tree-dominator-opts -fno-tree-ccp +-CFLAGS-rtld.c += $(SYSCONF-FLAGS) ++CFLAGS-rtld.c += $(SYSCONF-FLAGS) -O1 -fno-tree-copy-prop -fno-tree-dominator-opts -fno-tree-ccp CPPFLAGS-.os += $(if $(filter $(@F),$(patsubst %,%.os,$(all-rtld-routines))),\ -DNOT_IN_libc=1 -DIS_IN_rtld=1 -DIN_LIB=rtld)
Bug#755580: src:glibc: drop libgcc dependency from stage2 builds
Package: src:glibc
Version: 2.19-7
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Even if one manages to build glibc with profiles stage1 or stage2, the
results are not installable due to unmet dependencies. The following
issues occur:
* stage1 libc6-dev Depends on libc6 which is not built in stage1
* stage2 libc6 Depends on libgcc1 which is not built by gcc stage2
This bug shall only cover the second (easier) part and I shall report a
different bug for the first issue at a later time.
When we briefly discussed this issue, there was consensus that substvars
would be the tool to address it. So the attached patch turns those
libgcc dependencies into ${libgcc:Depends} and suppresses them for
stage2. It's a bit unfortunate that dependency information keeps
scattering over control and rules.d/debhelper.mk, but I didn't find a
better way.
Helmut
diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog
--- glibc-2.19/debian/changelog 2014-07-13 01:31:22.0 +0200
+++ glibc-2.19/debian/changelog 2014-07-20 22:07:19.0 +0200
@@ -1,3 +1,10 @@
+glibc (2.19-7.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Don't emit dependencies on libgcc when building stage2. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Sun, 20 Jul 2014 22:06:57 +0200
+
glibc (2.19-7) unstable; urgency=high
* debian/patches/localedata/unsubmitted-tst-setlocale3-ENV.diff: Apply
diff -Nru glibc-2.19/debian/control.in/libc glibc-2.19/debian/control.in/libc
--- glibc-2.19/debian/control.in/libc 2014-06-27 04:28:51.0 +0200
+++ glibc-2.19/debian/control.in/libc 2014-07-20 22:09:20.0 +0200
@@ -3,7 +3,7 @@
Section: libs
Priority: required
Multi-Arch: same
-Depends: ${shlibs:Depends}, libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4
[hppa]
+Depends: ${shlibs:Depends}, ${libgcc:Depends}
Recommends: libc6-i686 [i386], libc0.1-i686 [kfreebsd-i386], libc0.3-i686
[hurd-i386]
Suggests: glibc-doc, debconf | debconf-2.0, locales [!hurd-i386]
Provides: ${locale-compat:Depends}, libc6-sparcv9b [sparc sparc64]
diff -Nru glibc-2.19/debian/rules.d/debhelper.mk
glibc-2.19/debian/rules.d/debhelper.mk
--- glibc-2.19/debian/rules.d/debhelper.mk 2014-07-10 21:49:24.0
+0200
+++ glibc-2.19/debian/rules.d/debhelper.mk 2014-07-20 22:08:45.0
+0200
@@ -180,6 +180,9 @@
# Generate common substvars files.
echo locale:Depends=$(shell perl debian/debver2localesdep.pl
$(LOCALES_DEP_VER)) tmp.substvars
echo locale-compat:Depends=$(shell perl debian/debver2localesdep.pl
$(LOCALES_COMPAT_VER)) tmp.substvars
+ifeq ($(filter stage2,$(DEB_BUILD_PROFILES)),)
+ echo 'libgcc:Depends=libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4
[hppa]' tmp.substvars
+endif
for pkg in $(DEB_ARCH_REGULAR_PACKAGES) $(DEB_INDEP_REGULAR_PACKAGES)
$(DEB_UDEB_PACKAGES); do \
cp tmp.substvars debian/$$pkg.substvars; \
Bug#745380: src:eglibc: support non-multilib builds
On Mon, Apr 21, 2014 at 07:58:51AM +0200, Helmut Grohne wrote:
Please consider the attached patch to achieve this goal.
Please find an updated patch attached. Changes since last version:
* Add Build-Profiles headers to binary packages.
* Don't treat optimized packages (e.g. i686) as multilib (thanks to
Aurelien Jarno).
* Introduce GLIBC_MULTILIB_PASSES to work the same way as
DEB_ARCH_MULTILIB_PACKAGES (thanks to Aurelien Jarno).
* Support new architectures (mips*).
Helmut
diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog
--- glibc-2.19/debian/changelog 2014-07-13 01:31:22.0 +0200
+++ glibc-2.19/debian/changelog 2014-07-19 07:38:01.0 +0200
@@ -1,3 +1,11 @@
+glibc (2.19-7.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Add a nobiarch build profile that inhibits all multilib packages from
+being built. (Closes: #745380)
+
+ -- Helmut Grohne hel...@subdivi.de Sat, 19 Jul 2014 07:37:22 +0200
+
glibc (2.19-7) unstable; urgency=high
* debian/patches/localedata/unsubmitted-tst-setlocale3-ENV.diff: Apply
diff -Nru glibc-2.19/debian/control.in/amd64 glibc-2.19/debian/control.in/amd64
--- glibc-2.19/debian/control.in/amd64 2014-06-27 04:28:51.0 +0200
+++ glibc-2.19/debian/control.in/amd64 2014-07-19 07:53:34.0 +0200
@@ -4,7 +4,7 @@
Priority: optional
Depends: libc6 (= ${binary:Version}), ${misc:Depends}
Conflicts: amd64-libs (= 1.2)
-Build-Profiles: !stage1
+Build-Profiles: !stage1 !nobiarch
Description: GNU C Library: 64bit Shared libraries for AMD64
This package includes shared versions of the standard C library and the
standard math library, as well as many others. This is the 64bit version
@@ -19,6 +19,7 @@
Conflicts: libc6-dev ( 2.13-14)
Replaces: amd64-libs-dev (= 1.2), libc6-dev ( 2.13-11)
Provides: lib64c-dev
+Build-Profiles: !nobiarch
Description: GNU C Library: 64bit Development Libraries for AMD64
Contains the symlinks and object files needed to compile and link programs
which use the standard C library. This is the 64bit version of the
diff -Nru glibc-2.19/debian/control.in/armel glibc-2.19/debian/control.in/armel
--- glibc-2.19/debian/control.in/armel 2014-06-27 04:28:51.0 +0200
+++ glibc-2.19/debian/control.in/armel 2014-07-19 07:53:48.0 +0200
@@ -3,7 +3,7 @@
Section: libs
Priority: optional
Depends: libc6 (= ${binary:Version}), ${misc:Depends}
-Build-Profiles: !stage1
+Build-Profiles: !stage1 !nobiarch
Description: GNU C Library: ARM softfp shared libraries for armhf
This package includes shared versions of the standard C
library and the standard math library, as well as many others.
@@ -15,6 +15,7 @@
Priority: optional
Depends: libc6-armel (= ${binary:Version}), libc6-dev (= ${binary:Version}),
${misc:Depends}
Recommends: gcc-multilib
+Build-Profiles: !nobiarch
Description: GNU C Library: ARM softfp development libraries for armhf
Contains the symlinks and object files needed to compile and link programs
which use the standard C library. This is the ARM softfp version of the
diff -Nru glibc-2.19/debian/control.in/armhf glibc-2.19/debian/control.in/armhf
--- glibc-2.19/debian/control.in/armhf 2014-06-27 04:28:51.0 +0200
+++ glibc-2.19/debian/control.in/armhf 2014-07-19 07:54:00.0 +0200
@@ -3,7 +3,7 @@
Section: libs
Priority: optional
Depends: libc6 (= ${binary:Version}), ${misc:Depends}
-Build-Profiles: !stage1
+Build-Profiles: !stage1 !nobiarch
Description: GNU C Library: ARM hard float shared libraries for armel
This package includes shared versions of the standard C
library and the standard math library, as well as many others.
@@ -15,6 +15,7 @@
Priority: optional
Depends: libc6-armhf (= ${binary:Version}), libc6-dev (= ${binary:Version}),
${misc:Depends}
Recommends: gcc-multilib
+Build-Profiles: !nobiarch
Description: GNU C Library: ARM hard float development libraries for armel
Contains the symlinks and object files needed to compile and link programs
which use the standard C library. This is the ARM hard float version of the
diff -Nru glibc-2.19/debian/control.in/i386 glibc-2.19/debian/control.in/i386
--- glibc-2.19/debian/control.in/i386 2014-06-27 04:28:51.0 +0200
+++ glibc-2.19/debian/control.in/i386 2014-07-19 07:54:14.0 +0200
@@ -5,7 +5,7 @@
Depends: libc6 (= ${binary:Version}), ${misc:Depends}
Replaces: libc6-dev-i386
Breaks: fakeroot ( 1.12.3), gnu-efi ( 3.0e-3), fakechroot ( 2.9-1.1),
fglrx-glx-ia32 ( 1:9-6-1), ia32-libs ( 20090804), ia32-libs-gtk (
20090804), lib32asound2 ( 1.0.20-3), lib32asound2-dev ( 1.0.20-3),
lib32bz2-1.0 ( 1.0.5-3), lib32bz2-dev ( 1.0.5-3), lib32ffi-dev (
3.0.9~rc9-1), lib32ffi5 ( 3.0.9~rc9-1), lib32g2c0 ( 1:3.4.6-10), lib32gcc1
( 1:4.4.0-7), lib32gfortran3 ( 4.4.0-7), lib32gmp3 ( 2:4.3.1+dfsg-3),
lib32gmp3-dev ( 2:4.3.1+dfsg-3), lib32gmpxx4 ( 2:4.3.1+dfsg-3), lib32gomp1
( 4.4.0-7), lib32icu-dev ( 4.0.1-3), lib32icu40 ( 4.0.1-3), lib32mudflap0
( 4.4.0-7
Bug#742640: src:eglibc: build stage2 without selinux
On Thu, Jul 10, 2014 at 09:46:05PM +0200, Aurelien Jarno wrote: Hmm, the above has actually been removed in favor of a test on $(DEB_BUILD_PROFILES). Instead of duplicating the code, please test for both stage1 and stage2 in the same test. Updating patch addressing both concerns. Successfully tested on jenkins.d.n. Helmut diff -Nru eglibc-2.19/debian/sysdeps/linux.mk eglibc-2.19/debian/sysdeps/linux.mk --- eglibc-2.19/debian/sysdeps/linux.mk +++ eglibc-2.19/debian/sysdeps/linux.mk @@ -11,5 +11,5 @@ -ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),) +ifneq ($(filter stage1 stage2,$(DEB_BUILD_PROFILES)),) libc_extra_config_options = $(extra_config_options) else libc_extra_config_options = --with-selinux --enable-systemtap $(extra_config_options)
Bug#742640: src:eglibc: build stage2 without selinux
Version: 2.19-5 On Tue, Mar 25, 2014 at 09:51:33PM +0100, Helmut Grohne wrote: The eglibc package currently lacks a stage2 build profile entirely. A stage2 is needed though, because libselinux cannot be built without an actual libc among other things and eglibc explicitly enabled selinux via a configure flag. The attached patch removes that flag when the package is built with dpkg-buildpackage -Pstage2. Updated patch to apply against glibc 2.19. It also disables systemptap now. Helmut diff -Nru eglibc-2.19/debian/sysdeps/linux.mk eglibc-2.19/debian/sysdeps/linux.mk --- eglibc-2.19/debian/sysdeps/linux.mk +++ eglibc-2.19/debian/sysdeps/linux.mk @@ -12,7 +12,11 @@ ifeq ($(DEB_BUILD_PROFILE),bootstrap) libc_extra_config_options = $(extra_config_options) else - libc_extra_config_options = --with-selinux --enable-systemtap $(extra_config_options) + ifneq ($(filter stage2,$(DEB_BUILD_PROFILES)),) +libc_extra_config_options = $(extra_config_options) + else +libc_extra_config_options = --with-selinux --enable-systemtap $(extra_config_options) + endif endif ifndef LINUX_SOURCE
Bug#754350: src:glibc: fix dh_strip call in stage1
Package: src:glibc
Version: 2.19-5
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
I introduced a regression in my patch for #752480. All non-dev packages
were (correctly) marked with Build-Profiles: !stage1. For debhelper this
means, that those packages no longer exist. In particular passing a
non-existing package to dh_strip --dbg-package fails. Please apply the
attached patch or something equivalent.
Helmut
diff -Nru glibc-2.19/debian/rules.d/debhelper.mk glibc-2.19/debian/rules.d/debhelper.mk
--- glibc-2.19/debian/rules.d/debhelper.mk
+++ glibc-2.19/debian/rules.d/debhelper.mk
@@ -8,6 +8,10 @@
non-debug-packages = $(filter-out %-dbg,$(DEB_ARCH_REGULAR_PACKAGES))
$(patsubst %,$(stamp)binaryinst_%,$(debug-packages)):: $(patsubst %,$(stamp)binaryinst_%,$(non-debug-packages))
+ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
+DH_STRIP_DEBUG_PACKAGE=--dbg-package=$(libc)-dbg
+endif
+
$(patsubst %,$(stamp)binaryinst_%,$(DEB_ARCH_REGULAR_PACKAGES) $(DEB_INDEP_REGULAR_PACKAGES)):: $(patsubst %,$(stamp)install_%,$(GLIBC_PASSES)) debhelper
@echo Running debhelper for $(curpass)
dh_testroot
@@ -49,7 +53,7 @@
# strip *.o files as dh_strip does not (yet?) do it.
if test $(NOSTRIP_$(curpass)) != 1; then\
if test $(NODEBUG_$(curpass)) != 1; then\
- dh_strip -p$(curpass) -Xlibpthread --dbg-package=$(libc)-dbg; \
+ dh_strip -p$(curpass) -Xlibpthread $(DH_STRIP_DEBUG_PACKAGE); \
(cd debian/$(curpass); \
find . -name libpthread-\*.so -exec objcopy \
--only-keep-debug '{}' ../$(libc)-dbg/usr/lib/debug/'{}' \
Bug#752480: src:eglibc: use the build profile spec
Package: src:eglibc
Version: 2.19-3
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Dear eglibc maintainers,
You asked me to prepare a patch that maps the old ways of selecting
bootstrap stages to the current build profile specification
(https://wiki.debian.org/BuildProfileSpec). I therefore prepared the
attached patch. It keeps supporting the following environment variables:
* DEB_STAGE=stage1
* DEB_BUILD_PROFILE=bootstrap
It selects the original behaviour of DEB_BUILD_PROFILE=bootstrap and
implements it as DEB_BUILD_PROFILES=stage1 (in accordance with the above
specification). The code for the original DEB_STAGE=stage1 is dropped.
This patch does not yet annotate Build-Depends with build profiles,
because that would prevent the package from being uploaded due to
#744246.
Helmut
diff -Nru eglibc-2.19/debian/changelog eglibc-2.19/debian/changelog
--- eglibc-2.19/debian/changelog2014-06-17 18:58:21.0 +0200
+++ eglibc-2.19/debian/changelog2014-06-18 17:06:15.0 +0200
@@ -1,3 +1,11 @@
+eglibc (2.19-3.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Rename the bootstrap stage to DEB_BUILD_PROFILES=stage1 to conform with
+https://wiki.debian.org/BuildProfileSpec. Closes: #-1
+
+ -- Helmut Grohne hel...@subdivi.de Wed, 18 Jun 2014 17:05:21 +0200
+
eglibc (2.19-3) unstable; urgency=medium
[ Aurelien Jarno ]
diff -Nru eglibc-2.19/debian/control.in/amd64
eglibc-2.19/debian/control.in/amd64
--- eglibc-2.19/debian/control.in/amd64 2014-06-17 18:58:21.0 +0200
+++ eglibc-2.19/debian/control.in/amd64 2014-06-24 00:01:51.0 +0200
@@ -4,6 +4,7 @@
Priority: optional
Depends: libc6 (= ${binary:Version}), ${misc:Depends}
Conflicts: amd64-libs (= 1.2)
+Build-Profiles: !stage1
Description: Embedded GNU C Library: 64bit Shared libraries for AMD64
This package includes shared versions of the standard C library and the
standard math library, as well as many others. This is the 64bit version
diff -Nru eglibc-2.19/debian/control.in/armel
eglibc-2.19/debian/control.in/armel
--- eglibc-2.19/debian/control.in/armel 2014-06-17 18:58:21.0 +0200
+++ eglibc-2.19/debian/control.in/armel 2014-06-24 00:02:05.0 +0200
@@ -3,6 +3,7 @@
Section: libs
Priority: optional
Depends: libc6 (= ${binary:Version}), ${misc:Depends}
+Build-Profiles: !stage1
Description: Embedded GNU C Library: ARM softfp shared libraries for armhf
This package includes shared versions of the standard C
library and the standard math library, as well as many others.
diff -Nru eglibc-2.19/debian/control.in/armhf
eglibc-2.19/debian/control.in/armhf
--- eglibc-2.19/debian/control.in/armhf 2014-06-17 18:58:21.0 +0200
+++ eglibc-2.19/debian/control.in/armhf 2014-06-24 00:02:18.0 +0200
@@ -3,6 +3,7 @@
Section: libs
Priority: optional
Depends: libc6 (= ${binary:Version}), ${misc:Depends}
+Build-Profiles: !stage1
Description: Embedded GNU C Library: ARM hard float shared libraries for armel
This package includes shared versions of the standard C
library and the standard math library, as well as many others.
diff -Nru eglibc-2.19/debian/control.in/i386 eglibc-2.19/debian/control.in/i386
--- eglibc-2.19/debian/control.in/i386 2014-06-17 18:58:21.0 +0200
+++ eglibc-2.19/debian/control.in/i386 2014-06-24 00:02:24.0 +0200
@@ -5,6 +5,7 @@
Depends: libc6 (= ${binary:Version}), ${misc:Depends}
Replaces: libc6-dev-i386
Breaks: fakeroot ( 1.12.3), gnu-efi ( 3.0e-3), fakechroot ( 2.9-1.1),
fglrx-glx-ia32 ( 1:9-6-1), ia32-libs ( 20090804), ia32-libs-gtk (
20090804), lib32asound2 ( 1.0.20-3), lib32asound2-dev ( 1.0.20-3),
lib32bz2-1.0 ( 1.0.5-3), lib32bz2-dev ( 1.0.5-3), lib32ffi-dev (
3.0.9~rc9-1), lib32ffi5 ( 3.0.9~rc9-1), lib32g2c0 ( 1:3.4.6-10), lib32gcc1
( 1:4.4.0-7), lib32gfortran3 ( 4.4.0-7), lib32gmp3 ( 2:4.3.1+dfsg-3),
lib32gmp3-dev ( 2:4.3.1+dfsg-3), lib32gmpxx4 ( 2:4.3.1+dfsg-3), lib32gomp1
( 4.4.0-7), lib32icu-dev ( 4.0.1-3), lib32icu40 ( 4.0.1-3), lib32mudflap0
( 4.4.0-7), lib32ncurses5 ( 5.7+20090523-1), lib32ncurses5-dev (
5.7+20090530-1), lib32ncursesw5 ( 5.7+20090530-1), lib32ncursesw5-dev (
5.7+20090530-1), lib32nss-mdns ( 0.10-3.1), lib32objc2 ( 4.4.0-7),
lib32readline5 ( 5.2-5), lib32readline5-dev ( 5.2-5), lib32stdc++6 (
4.4.0-7), lib32stdc++6-4.4-dbg ( 4.4.0-7), lib32z1 ( 1:1.2.3.3.dfsg-14),
lib32z1-dev ( 1:1.2.3.3.dfsg-14), libc6-dev-i386 ( 2.9-15), nvidia-glx-ia32
( 185.18.14-2), nvidia-libvdpau1-ia32 ( 185.18.14-2)
+Build-Profiles: !stage1
Description: Embedded GNU C Library: 32-bit shared libraries for AMD64
This package includes shared versions of the standard C
library and the standard math library, as well as many others.
diff -Nru eglibc-2.19/debian/control.in/kfreebsd-i386
eglibc-2.19/debian/control.in/kfreebsd-i386
--- eglibc-2.19/debian/control.in/kfreebsd-i386 2014-06-17 18:58:21.0
+0200
+++ eglibc-2.19/debian/control.in/kfreebsd-i386 2014-06-24 00
Bug#745380: src:eglibc: support non-multilib builds
Package: src:eglibc Version: 2.18-4 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap It would be awesome, if eglibc had a variant to drop all the multilib packages. In particular this helps for cross-building into an architecture where a sibling architectures is momentarily broken. The gcc-X.Y source packages have this feature for quite a while now and it goes by the name DEB_CROSS_NO_BIARCH=yes. When I talked to Adam Conrad, he indicated that he'd prefer using build profiles instead. So I am suggesting to use nobiarch as the name for that profile, because it is close to gcc's way of calling things. Please consider the attached patch to achieve this goal. Helmut diff -Nru eglibc-2.18/debian/changelog eglibc-2.18/debian/changelog --- eglibc-2.18/debian/changelog +++ eglibc-2.18/debian/changelog @@ -1,3 +1,11 @@ +eglibc (2.18-4.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Add a nobiarch stage that inhibits all multilib packages from being +built. (Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Mon, 21 Apr 2014 07:44:15 +0200 + eglibc (2.18-4) unstable; urgency=high [ Aurelien Jarno ] diff -Nru eglibc-2.18/debian/rules eglibc-2.18/debian/rules --- eglibc-2.18/debian/rules +++ eglibc-2.18/debian/rules @@ -173,6 +173,10 @@ -include debian/sysdeps/$(DEB_HOST_ARCH_OS).mk -include debian/sysdeps/$(DEB_HOST_ARCH).mk +ifeq ($(filter nobiarch,$(DEB_BUILD_PROFILES)),) +DEB_ARCH_REGULAR_PACKAGES += $(DEB_ARCH_MULTILIB_PACKAGES) +endif + # Don't run dh_strip on this package NOSTRIP_$(libc)-dbg = 1 @@ -196,6 +200,10 @@ endif endif +ifneq ($(filter nobiarch,$(DEB_BUILD_PROFILES)),) +override EGLIBC_PASSES = libc +endif + # And now the rules... include debian/rules.d/*.mk diff -Nru eglibc-2.18/debian/sysdeps/alpha.mk eglibc-2.18/debian/sysdeps/alpha.mk --- eglibc-2.18/debian/sysdeps/alpha.mk +++ eglibc-2.18/debian/sysdeps/alpha.mk @@ -4,7 +4,7 @@ # build an ev67 optimized library EGLIBC_PASSES += alphaev67 -DEB_ARCH_REGULAR_PACKAGES += libc6.1-alphaev67 +DEB_ARCH_MULTILIB_PACKAGES += libc6.1-alphaev67 alphaev67_add-ons = ports nptl $(add-ons) alphaev67_configure_target = alphaev67-linux-gnu alphaev67_extra_cflags = -mcpu=ev67 -mtune=ev67 -O2 diff -Nru eglibc-2.18/debian/sysdeps/amd64.mk eglibc-2.18/debian/sysdeps/amd64.mk --- eglibc-2.18/debian/sysdeps/amd64.mk +++ eglibc-2.18/debian/sysdeps/amd64.mk @@ -3,7 +3,7 @@ # build 32-bit (i386) alternative library EGLIBC_PASSES += i386 -DEB_ARCH_REGULAR_PACKAGES += libc6-i386 libc6-dev-i386 +DEB_ARCH_MULTILIB_PACKAGES += libc6-i386 libc6-dev-i386 libc6-i386_shlib_dep = libc6-i386 (= $(shlib_dep_ver)) i386_add-ons = nptl $(add-ons) i386_configure_target = i686-linux-gnu @@ -39,7 +39,7 @@ # build x32 ABI alternative library EGLIBC_PASSES += x32 -DEB_ARCH_REGULAR_PACKAGES += libc6-x32 libc6-dev-x32 +DEB_ARCH_MULTILIB_PACKAGES += libc6-x32 libc6-dev-x32 libc6-x32_shlib_dep = libc6-x32 (= $(shlib_dep_ver)) x32_add-ons = nptl $(add-ons) x32_configure_target = x86_64-linux-gnux32 diff -Nru eglibc-2.18/debian/sysdeps/armel.mk eglibc-2.18/debian/sysdeps/armel.mk --- eglibc-2.18/debian/sysdeps/armel.mk +++ eglibc-2.18/debian/sysdeps/armel.mk @@ -2,7 +2,7 @@ extra_config_options = --enable-multi-arch #EGLIBC_PASSES += armhf -#DEB_ARCH_REGULAR_PACKAGES += libc6-armhf libc6-dev-armhf +#DEB_ARCH_MULTILIB_PACKAGES += libc6-armhf libc6-dev-armhf #armhf_add-ons = ports nptl $(add-ons) #armhf_configure_target = arm-linux-gnueabihf #armhf_CC = $(CC) -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard diff -Nru eglibc-2.18/debian/sysdeps/armhf.mk eglibc-2.18/debian/sysdeps/armhf.mk --- eglibc-2.18/debian/sysdeps/armhf.mk +++ eglibc-2.18/debian/sysdeps/armhf.mk @@ -13,7 +13,7 @@ endef #EGLIBC_PASSES += armel -#DEB_ARCH_REGULAR_PACKAGES += libc6-armel libc6-dev-armel +#DEB_ARCH_MULTILIB_PACKAGES += libc6-armel libc6-dev-armel #armel_add-ons = ports nptl $(add-ons) #armel_configure_target = arm-linux-gnueabi #armel_CC = $(CC) -mfloat-abi=soft diff -Nru eglibc-2.18/debian/sysdeps/hurd-i386.mk eglibc-2.18/debian/sysdeps/hurd-i386.mk --- eglibc-2.18/debian/sysdeps/hurd-i386.mk +++ eglibc-2.18/debian/sysdeps/hurd-i386.mk @@ -1,7 +1,7 @@ # We use -march=i686 and glibc's i686 routines use cmov, so require it. # A Debian-local glibc patch adds cmov to the search path. EGLIBC_PASSES += i686 -DEB_ARCH_REGULAR_PACKAGES += libc0.3-i686 +DEB_ARCH_MULTILIB_PACKAGES += libc0.3-i686 i686_add-ons = $(libc_add-ons) i686_configure_target=i686-gnu i686_extra_cflags = -march=i686 -mtune=generic diff -Nru eglibc-2.18/debian/sysdeps/i386.mk eglibc-2.18/debian/sysdeps/i386.mk --- eglibc-2.18/debian/sysdeps/i386.mk +++ eglibc-2.18/debian/sysdeps/i386.mk @@ -4,7 +4,7 @@ # A Debian-local glibc patch adds cmov to the search path. # The optimized libraries also use NPTL! EGLIBC_PASSES += i686 -DEB_ARCH_REGULAR_PACKAGES += libc6-i686 +DEB_ARCH_MULTILIB_PACKAGES += libc6-i686 i686_add-ons = nptl $(add
Bug#743676: FTCBFS: i386 stage1 tries to install xen stuff which is not built
Package: src:eglibc Version: 2.18-4 Severity: normal Tags: patch Hi Adam, When trying to cross-build an eglibc stage1 for i386 on amd64 it fails installing xen stuff: # extra_debhelper_pkg_install is used for debhelper.mk only. # when you want to install extra packages, use extra_pkg_install. mkdir -p debian/libc6-dev//usr/lib/i386-linux-gnu/xen cp -af debian/tmp-xen//usr/lib/i386-linux-gnu/*.a debian/libc6-dev//usr/lib/i386-linux-gnu/xen cp: cannot stat 'debian/tmp-xen//usr/lib/i386-linux-gnu/*.a': No such file or directory make: *** [/tmp/buildd/eglibc/eglibc-2.18/stamp-dir/binaryinst_libc6-dev] Error 1 dpkg-buildpackage: error: debian/rules binary-arch gave error exit status 2 I propose not to install the xen stuff which is not built in stage1 anyway by making that part conditional. Helmut diff -Nru eglibc-2.18/debian/changelog eglibc-2.18/debian/changelog --- eglibc-2.18/debian/changelog 2014-03-02 16:01:30.0 +0100 +++ eglibc-2.18/debian/changelog 2014-04-05 08:08:23.0 +0200 @@ -1,3 +1,11 @@ +eglibc (2.18-4.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Don't try to install xen headers in i386 bootstrap build, because they are +not built. Closes: #-1. + + -- Helmut Grohne hel...@dedup1.subdivi.de Sat, 05 Apr 2014 08:07:22 +0200 + eglibc (2.18-4) unstable; urgency=high [ Aurelien Jarno ] diff -Nru eglibc-2.18/debian/sysdeps/i386.mk eglibc-2.18/debian/sysdeps/i386.mk --- eglibc-2.18/debian/sysdeps/i386.mk 2014-03-02 16:01:31.0 +0100 +++ eglibc-2.18/debian/sysdeps/i386.mk 2014-04-05 08:09:22.0 +0200 @@ -51,11 +51,13 @@ debian/tmp-libc/usr/bin endef +ifneq ($(DEB_BUILD_PROFILE),bootstrap) define libc6-dev_extra_pkg_install mkdir -p debian/libc6-dev/$(libdir)/xen cp -af debian/tmp-xen/$(libdir)/*.a \ debian/libc6-dev/$(libdir)/xen endef +endif define libc6-dev-amd64_extra_pkg_install
Bug#742640: src:eglibc: build stage2 without selinux
Package: src:eglibc Version: 2.18-4 Severity: wishlist Tags: patch The eglibc package currently lacks a stage2 build profile entirely. A stage2 is needed though, because libselinux cannot be built without an actual libc among other things and eglibc explicitly enabled selinux via a configure flag. The attached patch removes that flag when the package is built with dpkg-buildpackage -Pstage2. Note that I did not convert the stage1 code to comply with the build profile spec. Thus eglibc now evaluates DEB_STAGE or DEB_BUILD_PROFILE (singular) for stage1 and DEB_BUILD_PROFILES (plural, in accordance with build profile spec) for stage2. Not all architectures successfully build a stage2 with this patch, but arm64, armel, armhf and m68k do. Helmut diff -Nru eglibc-2.18/debian/sysdeps/linux.mk eglibc-2.18/debian/sysdeps/linux.mk --- eglibc-2.18/debian/sysdeps/linux.mk +++ eglibc-2.18/debian/sysdeps/linux.mk @@ -12,7 +12,11 @@ ifeq ($(DEB_BUILD_PROFILE),bootstrap) libc_extra_config_options = $(extra_config_options) else - libc_extra_config_options = --with-selinux $(extra_config_options) + ifneq ($(filter stage2,$(DEB_BUILD_PROFILES)),) +libc_extra_config_options = $(extra_config_options) + else +libc_extra_config_options = --with-selinux $(extra_config_options) + endif endif ifndef LINUX_SOURCE
Bug#708504: src:eglibc: drop always satisfied build-dependency sed
Control: retitle -1 drop always satisfied build-dependencies sed and make Sorry for the noise. On Thu, May 16, 2013 at 07:45:59AM +0200, Helmut Grohne wrote: Could you drop sed from Build-Depends? Rationale: * Currently it is sed (= 4.0.5-4). The version required is satisfied in old old stable and the package itself is essential. * sed lacks Multi-Arch foreign (#693872), so this makes cross building eglibc a little harder. This equally applies to make, since make is build-essential and its bug is #693926. Helmut -- 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/20130516060125.ga27...@alf.mars
Bug#708504: src:eglibc: drop always satisfied build-dependency sed
Package: src:eglibc Version: 2.17-2 Severity: wishlist Could you drop sed from Build-Depends? Rationale: * Currently it is sed (= 4.0.5-4). The version required is satisfied in old old stable and the package itself is essential. * sed lacks Multi-Arch foreign (#693872), so this makes cross building eglibc a little harder. Helmut -- 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/20130516054558.ga21...@alf.mars
Bug#667023: 2.15 brings x32 support
block 667023 by 672934 thanks x32 support has been merged into the 2.15 version of glibc. Since carrying x32 patches ourselves seems like a useless waste of time, I mark the x32 bug as being blocked by the new upstream version. Helmut -- 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/20120527093302.ga11...@alf.mars
Bug#667023: src:eglibc: please provide a binary package for the x32 sub architecture on amd64
Package: src:eglibc Version: 2.13-27 Severity: normal Tags: upstream Blocks: 667005 gcc-4.7 and binutils (2.22) already provide support for the x32 abi. The missing piece to producing x32 binaries is a c library. Patches are available at git://github.com/hjl-tools/glibc.git. An aspect that makes supporting x32 more difficult is that glibc is currently compiled using gcc-4.4 whereas the x32 abi requires at least gcc-4.7. Switching compiler version is not a lightly taken decision and especially not this late in the freeze process. I estimate the diff between 2.13 and 2.13+x32 to be around 202 files changed, 3967 insertions, 218 deletions, and 568 modifications. Due to the ongoing multiarch transition another question should be asked: Should the new package be libc6-x32:amd64 or libc6:x32? Helmut -- 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/20120403130210.GA17099@localhost
Bug#286825: fixed in experimental
tags 286825 = fixed-in-experimental thanks This bug seems to be fixed in experimental. Helmut Grohne signature.asc Description: Digital signature
