Bug#1061248: glibc: DEP17: move most files but rtld to /usr
On Sun, Feb 04, 2024 at 09:20:09PM +0100, Helmut Grohne wrote: > 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. Ubuntu testing revealed that due to /lib64 going away in the package we also are going to need Depends or PreDepends on base-files, such that base-files trigger can then create the symlink. Or we temporarily handle the trigger ourselves or so. I am not sure if Depends are enough, I guess if you do a release upgrade we could end up with unpack base-files unpack libc6 preinst for something we want to unpack -> poof, no /lib64 here, can't
Bug#979970: libselinux1: dependency to newer libc6 ignored by/missing for aptitude
On Tue, Jan 26, 2021 at 12:52:52PM +0100, Aurelien Jarno wrote: > reassign 979970 src:glibc,src:libselinux,src:apt,src:openssh > thanks > > On 2021-01-25 11:59, Laurent Bigonville wrote: > > reassign 979970 src:glibc 2.30-1 > > affects 979970 + libselinux1 > > thanks > > > > On Tue, 12 Jan 2021 13:31:19 +0100 Charlemagne Lasse > > wrote: > > > > > Right now, an update from buster to bullseye on amd64 completely > > > bricks the system because libselinux1 is requiring a libc6 which is > > > not yet installed on the system: > > > > > > Preparing to unpack .../0-libselinux1_3.1-2+b2_amd64.deb ... > > > De-configuring libselinux1:i386 (2.8-1+b1) ... > > > Unpacking libselinux1:amd64 (3.1-2+b2) over (2.8-1+b1) ... > > > tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not > > > found (required by /lib/x86_64-linux-gnu/libselinux.so.1) > > > dpkg-deb: error: tar subprocess returned error exit status 1 > > > > > > It is then not possible anymore to recover the system because dpkg > > > (mv, ...) is no longer working. > > > > > > There is most likely some kind dependency missing to let aptitude > > > known that it must first update libc6 before it can update > > > libselinux1. At least on this system, the installed version of libc6 > > > for amd64 and i386 was still 2.28-10 when this happened > > > > After some discussion on IRC it looks like the problem is apparently coming > > from the breaks added to the libc6 package. > > The break hasn't been added randomly, but in response to upstream > release notes and bug #965932. In short the openssh seccomp filters in > buster are too narrow, and do not allow the new 64-bit syscalls needed > for 64-bit time_t compatibility to be used. > > So we definitely can't drop this break. For me this is not a libc6 bug. > Or if it is, it is as much the fault of libc6 (for using new syscalls) > than libselinux1 (for starting using symbol versioning). This is not a question of finding the right solution, but more of the least worst one. Currently, the breaks potentially avoids non-working openssh-server during a partial upgrade at the expense of breaking the system in a full upgrade. We can't have that. The reason this happens is the cycle: New libselinux1 needs new libc6, new libc6 needs newer libselinux1. The right solution would be to deconfigure libselinux1, then unpack libc6, then unpack new libselinux1, but it seems that this is not what's happening, and we can't easily change apt to fix it. An alternative solution, for openssh-server would be to avoid using the new syscalls for 64-bit time_t compatibility I assume (forcing it to link with older symbol versions?), but there are other cycles between libselinux1 and libc6 from what I heard. So well, like hack up libc6 to avoid exposing the new symbol versions and recompile everything against it? If you have alternative suggestions to avoid removing the Breaks, please let me know, but as it stands, I believe that this is the option that causes the least amount of breakage. We've reached the point where we have too many dependencies and conflicts too low in the stack, and it becomes too much for apt to handle. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Re: Bug#856152: python-apt: FTBFS: Testsuite failure
Control: tags -1 - moreinfo
(jrtc forgot to untag this...)
On Wed, Mar 01, 2017 at 03:33:55PM +, James Clarke wrote:
> Control: reassign -1 dirmngr 2.1.18-6
> Control: retitle -1 dirmngr: Fails to resolve localhost and loopback
> addresses when only a loopback interface is available
>
> On Wed, Mar 01, 2017 at 01:31:40AM +0100, Julian Andres Klode wrote:
> > Control: severity 856152 important
> >
> > On Wed, Mar 01, 2017 at 06:39:37AM +0800, Chris Lamb wrote:
> > > retitle 856152 python-apt: FTBFS: AptKeyError: recv from
> > > 'hkp://localhost:19191' failed for
> > > '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'
> > > thanks
> > >
> > > Julian Andres Klode wrote:
> > >
> > > > Retry it. Maybe it timed out or something.
> > >
> > > I don't think this is a timeout issue, but if it is, surely the package
> > > build should be a little more reliable? :)
> >
> > Well, it's some GPG issue, we can't figure out every GPG thing.
> >
> > This works fine with an up-to-date sid chroot in sbuild, so I don't
> > really care, or well, can't reproduce it. Seems more like a pbuilder
> > related issue.
>
> So the issue here is that, by default, pbuilder runs the build in a
> separate network namespace with only a loopback interface configured.
> The loopback interface works, you can bind and connect as normal
> (otherwise this would have been found a long time ago), but getaddrinfo
> has a slightly interesting deviation from POSIX. POSIX states[1]:
It also fails on my system now since I switched from dnsmasq to
systemd-resolved. That's really annoying.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Bug#653446: ldconfig: /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16-gdb.py is not an ELF file
Package: libc-bin,kibstdc++6-4.6-dbg Severity: minor Since some weeks, whenever ldconfig is run during an upgrade, I get the following warning: ldconfig: /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16-gdb.py is not an ELF file - it has the wrong magic bytes at the start. This means that either the .py file is in the wrong location, or that ldconfig should not warn about those files. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgpbo8zUUwfh7.pgp Description: PGP signature
Bug#626389: libc6: uninitialised value via gconv_open.c:70
Package: libc6, valgrind Version: libc6/2.13-2 Severity: normal It seems that with the new libc6 package, we get some more uninitialized values. There seems to be a value uninitialized somewhere (something pointed to by _nl_C_locobj_ptr?), causing dgettext() to produce warnings in valgrind, as seen in the example. $ LC_ALL=de_DE.UTF-8 valgrind gettext -d libapt-pkg4.10 Recommends ==21918== Memcheck, a memory error detector ==21918== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==21918== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==21918== Command: gettext -d libapt-pkg4.10 Recommends ==21918== ==21918== Conditional jump or move depends on uninitialised value(s) ==21918==at 0x4EAD23B: __GI___strcasecmp_l (strcmp.S:243) ==21918==by 0x4E4CE6C: __gconv_open (gconv_open.c:70) ==21918==by 0x4E59EC6: _nl_find_msg (dcigettext.c:990) ==21918==by 0x4E5A683: __dcigettext (dcigettext.c:654) ==21918==by 0x401D05: ??? (in /usr/bin/gettext) ==21918==by 0x4E4BEEC: (below main) (libc-start.c:228) ==21918== ==21918== Use of uninitialised value of size 8 ==21918==at 0x4EAF374: __GI___strcasecmp_l (strcmp.S:2257) ==21918==by 0x4E4CE6C: __gconv_open (gconv_open.c:70) ==21918==by 0x4E59EC6: _nl_find_msg (dcigettext.c:990) ==21918==by 0x4E5A683: __dcigettext (dcigettext.c:654) ==21918==by 0x401D05: ??? (in /usr/bin/gettext) ==21918==by 0x4E4BEEC: (below main) (libc-start.c:228) ==21918== ==21918== Use of uninitialised value of size 8 ==21918==at 0x4EAF378: __GI___strcasecmp_l (strcmp.S:2258) ==21918==by 0x4E4CE6C: __gconv_open (gconv_open.c:70) ==21918==by 0x4E59EC6: _nl_find_msg (dcigettext.c:990) ==21918==by 0x4E5A683: __dcigettext (dcigettext.c:654) ==21918==by 0x401D05: ??? (in /usr/bin/gettext) ==21918==by 0x4E4BEEC: (below main) (libc-start.c:228) ==21918== Empfiehlt==21918== ==21918== HEAP SUMMARY: ==21918== in use at exit: 0 bytes in 0 blocks ==21918== total heap usage: 72 allocs, 72 frees, 11,090 bytes allocated ==21918== ==21918== All heap blocks were freed -- no leaks are possible ==21918== ==21918== For counts of detected and suppressed errors, rerun with: -v ==21918== Use --track-origins=yes to see where uninitialised values come from ==21918== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 4 from 4) -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (250, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.13-2 Embedded GNU C Library: Binaries ii libgcc1 1:4.6.0-7 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.39 Debian configuration management sy pn glibc-doc none (no description available) ii locales 2.13-2 Embedded GNU C Library: National L -- debconf information excluded -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgp0XAs5PDLUk.pgp Description: PGP signature
Bug#611629: libc6: fail to upgrade with Can't locate auto/Hash/Util/bootstpap.al in @INC
On Mon, Jan 31, 2011 at 02:46:35PM +0200, Teodor wrote: Package: libc6 Version: 2.11.2-10 Severity: critical Justification: breaks unrelated software Hi, An almost up-to-date system upgraded last week cannot be upgraded today due to libc6 configuration errors: | Calculating upgrade... Done | The following packages will be upgraded: | binutils bsdutils debconf debconf-i18n dmsetup dpkg ghostscript grub-common grub-pc initramfs-tools libblkid1 libc-bin | libc6 libc6-i686 libdevmapper1.02.1 libgs8 libpango1.0-0 libpango1.0-common libuuid1 locales lvm2 mount openoffice.org | openoffice.org-base openoffice.org-base-core openoffice.org-calc openoffice.org-common openoffice.org-core | openoffice.org-draw openoffice.org-emailmerge openoffice.org-filter-binfilter openoffice.org-filter-mobiledev | openoffice.org-gnome openoffice.org-gtk openoffice.org-impress openoffice.org-java-common openoffice.org-math | openoffice.org-officebean openoffice.org-report-builder-bin openoffice.org-style-galaxy openoffice.org-style-tango | openoffice.org-writer python-uno sudo ttf-opensymbol uno-libs3 update-inetd ure util-linux |49 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. |[..] | Fetched 169 MB in 1min 42s (1,647 kB/s) | dpkg-deb (subprocess): data: internal bzip2 read error: 'DATA_ERROR' | dpkg-deb: subprocess decompress returned error exit status 2 | dpkg-deb (subprocess): failed in write on buffer copy for failed to write to pipe in copy: Broken pipe | Reading changelogs... Done | Extracting templates from packages: 100% | Preconfiguring packages ... | (Reading database ... 124785 files and directories currently installed.) | Preparing to replace libc-bin 2.11.2-9 (using .../libc-bin_2.11.2-10_i386.deb) ... | Unpacking replacement libc-bin ... | Processing triggers for man-db ... | Setting up libc-bin (2.11.2-10) ... | (Reading database ... 124785 files and directories currently installed.) | Preparing to replace libc6 2.11.2-9 (using .../libc6_2.11.2-10_i386.deb) ... | Unpacking replacement libc6 ... | Setting up libc6 (2.11.2-10) ... | Can't locate auto/Hash/Util/bootstpap.al in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/lib/perl/5.10/Hash/Util.pm line 34 | Compilation failed in require at /usr/share/perl/5.10/fields.pm line 122. | Compilation failed in require at /usr/share/perl5/Debconf/Log.pm line 10. | Compilation failed in require at /usr/share/perl5/Debconf/Db.pm line 7. | BEGIN failed--compilation aborted at /usr/share/perl5/Debconf/Db.pm line 7. | Compilation failed in require at /usr/share/debconf/frontend line 6. | BEGIN failed--compilation aborted at /usr/share/debconf/frontend line 6. | dpkg: error processing libc6 (--configure): | subprocess installed post-installation script returned error exit status 2 | configured to not write apport reports | Errors were encountered while processing: | libc6 | E: Sub-process /usr/bin/dpkg returned an error code (1) Attached is an apt-get -f install execution. Definitely not a libc6 bug, and probably not a bug at all. It looks like your perl-base installation is corrupt. Does perl -e require Hash::Util; work? -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgpakeVEKpt9C.pgp Description: PGP signature
Bug#611629: libc6: fail to upgrade with Can't locate auto/Hash/Util/bootstpap.al in @INC
On Mon, Jan 31, 2011 at 03:44:03PM +0200, Teodor MICU wrote: Hi, 2011/1/31 Julian Andres Klode j...@debian.org: Definitely not a libc6 bug, and probably not a bug at all. It looks like your perl-base installation is corrupt. Indeed perl-base was corrupted. The question is how since I didn't modified it manually?! Filesystem bug, system crash? -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- 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/20110131144553.ga9...@debian.org
