Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
Hi, Quoting Aurelien Jarno (2024-05-20 11:49:32) > > > > That's all legacy stuff and I really don't want to touch it anymore. > > > > Going from the other side, maybe libc6.postinst could use something > > > > more reliable than ischroot()? Is systemd-detect-virt able to figure > > > > out the situation a bit better? > > > Nope. > > What's the output? With SYSTEMD_LOG_LEVEL=debug exported > In sbuild using unshare chroot running in a VM: > > | SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-detect-virt > | Failed to read $container of PID 1, ignoring: Permission denied > | Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy > | Found container virtualization none. > | Virtualization QEMU found in DMI (/sys/class/dmi/id/sys_vendor) > | UML virtualization not found in /proc/cpuinfo. > | Virtualization XEN not found, /proc/xen does not exist > | Virtualization found, CPUID=KVMKVMKVM > | Found VM virtualization kvm > | kvm would it help (and be correct) if PID 1 in sbuild unshare mode would have the "container" environment variable set to something? And/or if sbuild unshare mode would create the file /run/systemd/container with some content? I'd need input from somebody who knows how containers (if this is one) are supposed to work. :) Thanks! cheers, josch signature.asc Description: signature
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
Hi, Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > [..] But maybe it [glibc's postinst] should be doing some > > more involved checks about what PID 1 is? It could then make sure to only > > call > > systemd telinit if systemd is pid 1. [..] > > Well, that would probably suck. Putting the knowledge when to call > telinit, and a specific telinit, into a ton of different things > makes all those things hard to get right, hard to update, the usual. > > I've checked the sysvinit and the systemd implementations now, and > they are not that different. Both try to talk to their respective > pid1 daemons first using their respective communication socket. > > But then, if that doesn't work, they diverge: > - sysvinit's telinit just gives up > - systemd's telinit, *as an explicit fallback*, sends signals. > > systemd's telinit (aka systemctl) helpfully exits if it detects > being in a chroot, before doing any of that. > > IWSTM systemd's telinit could, if called as telinit, not do the > fallback to stick with sysvinit's behaviour? > > As a bonus, sysvinit's telinit could also gain the chroot check, and glibc's > postinst (and other places) can become simpler again. via irc, jochen also pointed out: telinit could be the component which checks what PID 1 actually is and only do its thing after it confirmed that it is indeed an init system like systemd that is providing PID 1? Thanks! cheers, josch signature.asc Description: signature
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
Quoting Helmut Grohne (2024-05-20 07:17:54) > Hi Chris, > > On Mon, May 20, 2024 at 01:02:32AM +0200, Chris Hofstaedtler wrote: > > "..., when using telinit from systemd-sysv" > > > > It would seem like a reasonable assumption that systemd-sysv's > > telinit uses systemd-specific stuff, like SIGTERM. > > That also is an interesting angle to it. sbuild didn't ask for systemd-sysv > to be installed. this might shift the bug back to glibc postinst, no? Currently, it just checks the exit of ischroot before calling telinit. But maybe it should be doing some more involved checks about what PID 1 is? It could then make sure to only call systemd telinit if systemd is pid 1. And sysvinit telinit if sysvinit is pid 1 and not call telinit at all in unknown cases. Is it too much to ask for glibc postinst to know about the PID 1 providers? Thanks! cheers, josch signature.asc Description: signature
Bug#1063624: libc.preinst: please skip kernel check via uname when DPKG_ROOT is not empty for gnu hurd support
Source: glibc Version: 2.37-15 Severity: normal Tags: patch User: debian-h...@lists.debian.org Usertags: hurd X-Debbugs-Cc: debian-h...@lists.debian.org, debian-cr...@lists.debian.org Hi, one of the reasons for DPKG_ROOT support in packages close to the essential and build-essential set is to build chroots for architectures that do not have qemu-user support. Building chroots for hurd from linux is one such scenario where qemu-user emulation will never allow running hurd binaries from the chroot on the linux system creating that chroot and thus the only way to create it (short of running the whole thing inside a full virtual machine) is to use chrootless mode. In our last round of DPKG_ROOT related patches we built chroots for other linux architectures on linux. Now we try building chroots for foreign kernels. In this case: hurd on linux. In the process we discovered another problem class: maintainer scripts running uname. This is a problem because "uname -s" will print "Linux" and thus the linux-specific parts of the maintainer script get executed but we want to build a hurd chroot and need the hurd-specific bits instead. In case of libc.preinst, its use of "uname -s" and "uname -r" can be avoided by adding another condition on $DPKG_ROOT being empty, i.e to only check the kernel version for normal installations but not when glibc is installed with dpkg --force-script-chrootless as in that case, there exists no way for the script to know what kernel version will be running on the final system where the chroot will be deployed. So if "$DPKG_ROOT" is not empty, the kernel version checks just get skipped. I submitted a patch as a merge request here: https://salsa.debian.org/glibc-team/glibc/-/merge_requests/20 Please consider applying it to close this bug. What do you think? Thanks! cheers, josch
Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT
Quoting Aurelien Jarno (2022-10-11 22:14:31) > From what I have understood from your explanation, if the directory exists > chroot_canon() will work, so `ldconfig -r` will be able to create the > aux-cache file in it. I can confirm this conclusion. The following patch makes our CI pass without any other changes to glibc. --- glibc-2.35/debian/debhelper.in/libc-bin.dirs2022-09-22 22:06:02.0 +0200 +++ glibc-2.35/debian/debhelper.in/libc-bin.dirs2022-10-12 10:15:46.0 +0200 @@ -1,2 +1,3 @@ usr/lib/locale usr/share/libc-bin +var/cache/ldconfig > I still think that the bug should be fixed on the glibc upstream side, > but that would allow to easy fix it on the package side, and it's > probably better to have a closer match of the dpkg database and the file > system. Though I have heard from some people that they want packages to ship only files under /usr and have everything else be created upon instantiation of the machine. This change would go the opposite direction. Thanks! cheers, josch signature.asc Description: signature
Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT
Hi, Quoting Aurelien Jarno (2022-10-11 21:55:47) > Ok, thanks for the details, I'll look at the patch. thank you! > Anyway that makes me wonder if we should ship that directory in the libc6 > package, just like apt ships /var/cache/apt and debconf ships > /var/cache/debconf. In our DPKG_ROOT CI we compare a chroot tarball created the normal way with a tarball created with dpkg run with --force-script-chrootless. We added an additional mode that tries out if this whole thing also works when run without being the root user but run as the normal user under fakeroot and then we found the missing /var/cache/ldconfig directory. So if libc6 would ship that directory, I think my patch would still be needed. Because if `ldconfig -r` doesn't use the directory, then the last modification timestamps will differ between a chroot created the normal way and a chroot created without actually ever running chroot() (the DPKG_ROOT way). Thanks! cheers, josch signature.asc Description: signature
Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT
Hi, Quoting Aurelien Jarno (2022-10-11 21:41:05) > On 2022-10-11 07:57, Johannes Schauer Marin Rodrigues wrote: > > Package: glibc > > Version: 2.35-3 > > Severity: normal > > Tags: patch > > > > Hi, > > > > when running libc-bin.postinst with DPKG_ROOT non-empty, ldconfig from > > the outside is used to operate on the chroot and thus ldconfig will > > never create the empty /var/cache/ldconfig directory inside the chroot. > > I don't get why this is needed. The point of calling ldconfig -r is to > create that directory and create the aux-cache file in it. In my tests > ldconfig does create that directory properly when ran with -r. > > > Please consider creating that directory if DPKG_ROOT is non-empty. > > Even if it ends up that in some conditions yet to be found, the > directory is not created, this doesn't seems correct. This means that > aux-cache file is also not created, which is more problematic. I now have a much better understanding about what is happening and filed this patch: https://sourceware.org/pipermail/libc-alpha/2022-October/142592.html The problem occurs only if the opt_chroot variable is not NULL. This happens when you pass -r but the chroot() call fails, for example because you are running as an unprivileged user with fakeroot. In that case, chroot_canon() will return NULL because /var/cache/ldconfig doesn't exist in the chroot yet. This leads to aux_cache_file being set to NULL and that means that in the end save_aux_cache() doesn't get called. Thanks! cheers, josch signature.asc Description: signature
Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT
Package: glibc Version: 2.35-3 Severity: normal Tags: patch Hi, when running libc-bin.postinst with DPKG_ROOT non-empty, ldconfig from the outside is used to operate on the chroot and thus ldconfig will never create the empty /var/cache/ldconfig directory inside the chroot. Please consider creating that directory if DPKG_ROOT is non-empty. For your convenience, I submitted a merge request on salsa fixing this issue: https://salsa.debian.org/glibc-team/glibc/-/merge_requests/13 These changes are tested on our CI and allow us to drop the manual creation of /var/cache/ldconfig to become bit-by-bit reproducible: https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs Thanks! cheers, josch
Bug#1017590: glibc 2.34 broke getpwnam calls under fakechroot
Source: glibc
Version: 2.34-1
Severity: normal
X-Debbugs-Cc: jo...@debian.org
Control: affects -1 + fakechroot mmdebstrap
Hi,
ultimately this probably needs to be fixed in fakechroot but I need some
help solving this problem from somebody who understands glibc.
Since the upload of glibc 2.34, getpwnam (and friends) under fakechroot
are not wrapped anymore. This means that instead of accessing
/etc/passwd from the chroot, the version from the host will be accessed,
leading to incorrect behaviour.
Since mmdebstrap uses fakechroot, this problem affects mmdebstrap as
well and breaks its autopkgtest.
There was a similar problem in the past. See
https://bugs.debian.org/993946 which in the end was fixed by letting
fakechroot wrap __nss_files_fopen.
I bisected glibc from git between 2.33 and 2.34 and found out, that this
fix broke again in this commit:
https://sourceware.org/git/?p=glibc.git;a=commit;h=6212bb67f4695962748a5981e1b9fea105af74f6
Do you have any idea why this commit is responsible and what fakechroot
could do to fix it? Attached the script I used to setup a minimal chroot
to bisect glibc git (this is for future-me in case I need to do this
ever again in the future).
Thanks!
cheers, josch
#!/bin/sh
set -e
rm -rf /install ./*
/glibc/configure --prefix=/usr && make -j
wget -c
http://snapshot.debian.org/archive/debian/20211216T150239Z/pool/main/f/fakechroot/fakechroot_2.20.1%2Bds-2_all.deb
wget -c
http://snapshot.debian.org/archive/debian/20211216T150239Z/pool/main/f/fakechroot/libfakechroot_2.20.1%2Bds-2_amd64.deb
mkdir -p /install/bin /install/lib /install/lib64 /install/dev /install/usr/lib
ln -s ../lib/ld.so /install/lib64/ld-linux-x86-64.so.2
ln -s ../../lib64 /install/usr/lib/x86_64-linux-gnu
ln -s ../bin /install/usr/bin
cp /bin/dash /install/bin/sh
cp ./elf/ldconfig /install/bin/
cp /usr/bin/seq /usr/bin/env /bin/bash /usr/bin/tr /usr/bin/basename
/usr/bin/getopt /usr/sbin/chroot /bin/echo /install/bin/
cp -a /lib/x86_64-linux-gnu/libtinfo.so.6.2 /install/lib64
ln -s libtinfo.so.6.2 /install/lib64/libtinfo.so.6
cp ./elf/ld.so /install/lib
find -name '*.so' -or -name '*.so.*' | xargs -I'{}' cp '{}' /install/lib64
dpkg-deb --fsys-tarfile fakechroot_2.20.1+ds-2_all.deb | tar -C /install
--keep-directory-symlink -x
dpkg-deb --fsys-tarfile libfakechroot_2.20.1+ds-2_amd64.deb | tar -C /install
--keep-directory-symlink -x
cp /fakechroot/test/src/test-nss_files_fopen /install/bin/
cp -a /install /chroot
mv /chroot /install/chroot
echo "user:x:1337:1337:user:/home/user:/bin/bash" > /install/chroot/etc/passwd
chroot /install fakechroot --lib
/usr/lib/x86_64-linux-gnu/fakechroot/libfakechroot.so /bin/chroot /chroot
/bin/test-nss_files_fopen user
Bug#1007756: tzdata: please support DPKG_ROOT
Source: tzdata
Version: 2021e-1
Severity: normal
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support
X-Debbugs-Cc: jo...@debian.org
Hi,
when creating chroots for new architectures that are in the process of
being bootstrapped without yet having emulation support from qemu, it is
not possible to run maintainer scripts inside the foreign architecture
chroot because foreign architecture ELF binaries cannot be executed. The
solution to that problem is to run maintainer scripts from outside the
chroot and use the DPKG_ROOT environment variable to instruct the
maintainer script on which chroot to operate. By default, for normal
installations, that environment variable is set, but empty.
Apart from init-system-helpers and pam, all packages in the
Essential:yes set have support for DPKG_ROOT already. To start building
packages we also need to install build-essential. In debootstrap, the
buildd variant includes the Essential:yes packages, Priority:required
packages and build-essential. Strictly speaking, tzdata is not necessary
to start building packages as it only gets installed in the buildd
variant of debootstrap because it is Priority:required. Still, it would
be helpful to have tzdata support DPKG_ROOT because it would avoid
having to add an exception to the buildd set chosen by debootstrap.
Please consider applying the patch at the end of this mail. We tested it
in our CI environment and it produces a bit-by-bit identical chroot with
DPKG_ROOT compared to a normal installation.
https://salsa.debian.org/helmutg/dpkg-root-demo/
Since the DPKG_ROOT variable is empty on normal installations, the patch
should have no effect in the normal case.
Thanks!
cheers, josch
diff -Nru tzdata-2021e/debian/tzdata.config tzdata-2021e/debian/tzdata.config
--- tzdata-2021e/debian/tzdata.config 2021-09-29 00:38:51.0 +0200
+++ tzdata-2021e/debian/tzdata.config 2022-03-14 14:49:42.0 +0100
@@ -372,38 +372,38 @@
}
# If /etc/localtime is a link, update /etc/timezone
-if [ -L /etc/localtime ] ; then
-TIMEZONE="$(readlink /etc/localtime)"
+if [ -L "$DPKG_ROOT/etc/localtime" ] ; then
+TIMEZONE="$(readlink "$DPKG_ROOT/etc/localtime")"
TIMEZONE="${TIMEZONE#/usr/share/zoneinfo/}"
-if [ -f "/usr/share/zoneinfo/$TIMEZONE" ] ; then
-echo ${TIMEZONE} > /etc/timezone
+if [ -f "$DPKG_ROOT/usr/share/zoneinfo/$TIMEZONE" ] ; then
+echo ${TIMEZONE} > "$DPKG_ROOT/etc/timezone"
fi
fi
# Read /etc/timezone
-if [ -e /etc/timezone ]; then
-TIMEZONE="$(head -n 1 /etc/timezone)"
+if [ -e "$DPKG_ROOT/etc/timezone" ]; then
+TIMEZONE="$(head -n 1 "$DPKG_ROOT/etc/timezone")"
TIMEZONE="${TIMEZONE%% *}"
TIMEZONE="${TIMEZONE##/}"
TIMEZONE="${TIMEZONE%%/}"
TIMEZONE="$(convert_timezone $TIMEZONE)"
-if [ -f "/usr/share/zoneinfo/$TIMEZONE" ] ; then
+if [ -f "$DPKG_ROOT/usr/share/zoneinfo/$TIMEZONE" ] ; then
AREA="${TIMEZONE%%/*}"
ZONE="${TIMEZONE#*/}"
else
-rm -f /etc/timezone
+rm -f "$DPKG_ROOT/etc/timezone"
fi
fi
# The timezone is already configured
-if [ -e /etc/timezone ] && [ -e /etc/localtime ] ; then
+if [ -e "$DPKG_ROOT/etc/timezone" ] && [ -e "$DPKG_ROOT/etc/localtime" ] ; then
# Don't ask the user, except if he/she explicitely asked that
if [ -z "$DEBCONF_RECONFIGURE" ] ; then
db_fset tzdata/Areas seen true
db_fset tzdata/Zones/$AREA seen true
fi
# The timezone has never been configured or is falsely configured
-elif ! [ -e /etc/localtime ] || [ -n "$DEBCONF_RECONFIGURE" ] ; then
+elif ! [ -e "$DPKG_ROOT/etc/localtime" ] || [ -n "$DEBCONF_RECONFIGURE" ] ;
then
if [ -z "$AREA" ] || [ -z "$ZONE" ] ; then
RET=""
db_get tzdata/Areas || true
@@ -421,7 +421,7 @@
ZONE="UTC"
fi
-echo "$AREA/$ZONE" > /etc/timezone
+echo "$AREA/$ZONE" > "$DPKG_ROOT/etc/timezone"
fi
db_fset tzdata/Areas seen false
db_fset tzdata/Zones/$AREA seen false
diff -Nru tzdata-2021e/debian/tzdata.postinst
tzdata-2021e/debian/tzdata.postinst
--- tzdata-2021e/debian/tzdata.postinst 2018-07-10 00:46:15.0 +0200
+++ tzdata-2021e/debian/tzdata.postinst 2022-03-14 14:49:40.0 +0100
@@ -12,7 +12,7 @@
if [ "$1" = configure ]; then
# If the user prefers to manage the time zone by itself, let him doing
that.
-if ! [ -e /etc/timezone ] && [ -z "$DEBCONF_RECONFIGURE" ] ; then
+if ! [ -e "$DPKG_ROOT/etc/timezone" ] && [ -z "$DEBCONF_RECONFIGURE" ] ;
then
db_stop
echo
echo "User defined time zone, leaving /etc/localtime unchanged."
@@ -26,10 +26,10 @@
db_stop
# Update the time zone
-echo $AREA/$ZONE > /etc/timezone
- ln -nsf /usr/share/zoneinfo/$AREA/$ZONE /etc/localtime.dpkg-new && \
- mv -f /etc/localtime.dpkg-new /etc/localtime
- which restorecon >/dev/null 2>&1 && restorecon /etc/localtime
+
Bug#1006692: glibc: libc6 postinst: do not re-exec init if DPKG_ROOT is set
Source: glibc
Version: 2.33-7
Severity: normal
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support
X-Debbugs-Cc: jo...@debian.org
Hi,
when glibc is installed with $DPKG_ROOT set to a non-empty string, then
"systemctl daemon-reexec" or "telinit" should not be executed, similarly
to when the postinst is run inside a chroot. I filed a MR [1] and put
the patch at the end of this mail.
Thanks!
cheers, josch
[1] https://salsa.debian.org/glibc-team/glibc/-/merge_requests/5
--- a/debian/debhelper.in/libc.postinst
+++ b/debian/debhelper.in/libc.postinst
@@ -157,6 +157,9 @@ then
if ischroot 2>/dev/null; then
# Don't bother trying to re-exec init from a chroot:
TELINIT=no
+elif [ -n "${DPKG_ROOT:-}" ]; then
+# Do not re-exec init if we are operating on a chroot from outside:
+TELINIT=no
elif [ -d /run/systemd/system ]; then
# Restart systemd on upgrade, but carefully.
# The restart is wanted because of LP: #1942276 and Bug: #993821
Bug#983412: libc-bin: please add support for DPKG_ROOT to the postinst
Hi,
Quoting Johannes 'josch' Schauer (2021-02-23 20:30:41)
> this is a followup on
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910685
we can now verify that with this patch it is possible to create a Debian chroot
that is bit-by-bit identical to one created the normal way:
https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs
Currently, half the time in our CI job is spent building glibc. It would be
great if this patch can be applied, so that we do not have to build a patched
glibc anymore.
I opened a merge request here:
https://salsa.debian.org/glibc-team/glibc/-/merge_requests/4
And attached the git-format-patch.
Thanks!
cheers, josch>From 64e9212385a7cf75a206481e539ca1779a075b5e Mon Sep 17 00:00:00 2001
From: Johannes Schauer Marin Rodrigues
Date: Fri, 20 Aug 2021 11:37:16 +0200
Subject: [PATCH] More support for DPKG_ROOT (closes: #983412)
- this partially reverts 9e77b114 because debconf is patched to support
DPKG_ROOT
---
debian/changelog | 4
debian/debhelper.in/libc-bin.postinst | 6 +++---
debian/debhelper.in/libc.postinst | 2 +-
debian/debhelper.in/libc.preinst | 6 +++---
4 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index f9175ced..e6b256d9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,11 @@
glibc (2.31-17) UNRELEASED; urgency=medium
+ [ Samuel Thibault ]
* debian/testsuite-xfail-debian.mk: Update tests.
+ [ Johannes Schauer Marin Rodrigues ]
+ * additional bits to support DPKG_ROOT (closes: #983412)
+
-- Samuel Thibault Wed, 18 Aug 2021 23:04:08 +0200
glibc (2.31-16) unstable; urgency=medium
diff --git a/debian/debhelper.in/libc-bin.postinst b/debian/debhelper.in/libc-bin.postinst
index 802a3ad0..7fc320c5 100644
--- a/debian/debhelper.in/libc-bin.postinst
+++ b/debian/debhelper.in/libc-bin.postinst
@@ -40,15 +40,15 @@ update_to_current_default() {
}
if [ "$1" = "configure" ] && [ "$2" = "" ] ; then
- install_from_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf
+ install_from_default "$DPKG_ROOT/usr/share/libc-bin/nsswitch.conf" "$DPKG_ROOT/etc/nsswitch.conf"
fi
if [ "$1" = "configure" ] && [ "$2" != "" ]; then
- update_to_current_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf
+ update_to_current_default "$DPKG_ROOT/usr/share/libc-bin/nsswitch.conf" "$DPKG_ROOT/etc/nsswitch.conf"
fi
if [ "$1" = "triggered" ] || [ "$1" = "configure" ]; then
- ldconfig || ldconfig --verbose
+ ldconfig -r "$DPKG_ROOT/" || ldconfig --verbose -r "$DPKG_ROOT/"
exit 0
fi
diff --git a/debian/debhelper.in/libc.postinst b/debian/debhelper.in/libc.postinst
index 687ebc4c..d58771ed 100644
--- a/debian/debhelper.in/libc.postinst
+++ b/debian/debhelper.in/libc.postinst
@@ -20,7 +20,7 @@ then
__NOHWCAP__
fi
-if [ "$type" = configure -a -z "$DPKG_ROOT" ]
+if [ "$type" = configure ]
then
# Load debconf module if available
if [ -f /usr/share/debconf/confmodule ] ; then
diff --git a/debian/debhelper.in/libc.preinst b/debian/debhelper.in/libc.preinst
index 9a857c9c..75519bca 100644
--- a/debian/debhelper.in/libc.preinst
+++ b/debian/debhelper.in/libc.preinst
@@ -12,7 +12,7 @@ kernel_compare_versions () {
test $verA -$2 $verB
}
-if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
+if [ "$type" != abort-upgrade ]
then
# Load debconf module if available and usable
if [ -f /usr/share/debconf/confmodule ]; then
@@ -159,7 +159,7 @@ then
fi
fi
-if [ "$type" = upgrade -a -z "$DPKG_ROOT" ]
+if [ "$type" = upgrade ]
then
if [ -n "$preversion" ] && [ -x "$(command -v ischroot)" ] && ! ischroot; then
# NSS authentication trouble guard
@@ -247,7 +247,7 @@ then
# This will keep us from using hwcap libs (optimized) during an
# upgrade.
-touch /etc/ld.so.nohwcap
+touch "$DPKG_ROOT/etc/ld.so.nohwcap"
fi
#DEBHELPER#
--
2.30.2
signature.asc
Description: signature
Bug#954374: marked as pending in glibc
Okay, wow, this is a 100 times better solution than the one I proposed. :D Thank you!! Quoting Aurelien Jarno (2020-03-24 19:02:59) > Bug #954374 in glibc reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/glibc-team/glibc/-/commit/7d682fdc92f2a3bf2a16c534204c89a69ca08040 > > > debian/debhelper.in/libc.preinst, debian/rules.d/debhelper.mk: determine > ld.so ELF magic at build time instead of at run time to avoid using "readlink > -m". Closes: #954374. > > > (this message was generated automatically) signature.asc Description: signature
Bug#954374: libc6: please make maintainerscript compatible with busybox
Control: tag -1 + patch Hi again, Quoting Johannes Schauer (2020-03-21 22:50:46) > Quoting Aurelien Jarno (2020-03-21 00:00:18) > > On 2020-03-20 22:57, Johannes 'josch' Schauer wrote: > > > would it be possible to make the libc6 preinst maintainer script > > > compatible with busybox? Currently the preinst script calls "readlink > > > -m" which is not supported by busybox. Hence the following error will be > > > thrown: > > > > > > BusyBox v1.30.1 (Debian 1:1.30.1-4) multi-call binary. > > > > > > Usage: readlink [-fnv] FILE > > > > > > Display the value of a symlink > > > > > > -f Canonicalize by following all symlinks > > > -n Don't add newline > > > -v Verbose > > > > > > I tried to prepare a patch for the preinst script but ran into a FTBFS: > > > > > > x86_64-linux-gnu-gcc-9 -shared -static-libgcc -Wl,-O1 -Wl,-z,defs > > > -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 > > > -B/<>/build-tree/amd64-libc/csu/ > > > -Wl,--version-script=/<>/build-tree/amd64-libc/libnss_files.map > > > -Wl,-soname=libnss_files.so.2 -Wl,-z,combreloc -Wl,-z,relro > > > -Wl,--hash-style=both -L/<>/build-tree/amd64-libc > > > -L/<>/build-tree/amd64-libc/math > > > -L/<>/build-tree/amd64-libc/elf > > > -L/<>/build-tree/amd64-libc/dlfcn > > > -L/<>/build-tree/amd64-libc/nss > > > -L/<>/build-tree/amd64-libc/nis > > > -L/<>/build-tree/amd64-libc/rt > > > -L/<>/build-tree/amd64-libc/resolv > > > -L/<>/build-tree/amd64-libc/mathvec > > > -L/<>/build-tree/amd64-libc/support > > > -L/<>/build-tree/amd64-libc/nptl > > > -Wl,-rpath-link=/<>/build-tree/amd64-libc:/<>/build-tree/amd64-libc/math:/<>/build-tree/amd64-libc/elf:/<>/build-tree/amd64-libc/dlfcn:/<>/build-tree/amd64-libc/nss:/<>/build-tree/amd64-libc/nis:/<>/build-tree/amd64-libc/rt:/<>/build-tree/amd64-libc/resolv:/<>/build-tree/amd64-libc/mathvec:/<>/build-tree/amd64-libc/support:/<>/build-tree/amd64-libc/nptl > > > -o /<>/build-tree/amd64-libc/nss/libnss_files.so > > > /<>/build-tree/amd64-libc/csu/abi-note.o -Wl,--whole-archive > > > /<>/build-tree/amd64-libc/nss/libnss_files_pic.a > > > -Wl,--no-whole-archive -Wl,--start-group > > > /<>/build-tree/amd64-libc/linkobj/libc.so > > > /<>/build-tree/amd64-libc/libc_nonshared.a -Wl,--as-needed > > > /<>/build-tree/amd64-libc/elf/ld.so -Wl,--no-as-needed > > > -Wl,--end-group > > > /usr/bin/ld: > > > /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libselinux.so: > > > undefined reference to `gettid@GLIBC_2.30' > > > collect2: error: ld returned 1 exit status > > > > Strange. How did you try to build it? > > It turned out to be a problem on my side. Sorry for the false alarm. > > > > Thus, I'm now reporting this wishlist bug here before further working on > > > a fix. > > > > > > Would you be willing to accept a change that makes the preinst script of > > > libc6 compatible with readlink from busybox? > > > > On the principle yes, but it means we need to have an equivalent to > > readlink -m. Do you have a way for doing that in busybox? > > Indeed I have. There exists a version for bash with an extensive test suite: > https://github.com/bashup/realpaths I ported that one to POSIX shell while > keeping the test suite and comparing it with "realpath -m": > https://gitlab.mister-muffin.de/josch/realpath > > The preinst script should probably continue using coreutils readlink when it > exists and only fall back to the re-implementation in POSIX shell if the > version of readlink on the system does not provide the -m option (as it is the > case with busybox). > > Since I now was able to successfully rebuild glibc, I can confirm that this is > the last puzzlepiece needed to allow to create and configure a system > containing only the following packages (and their Depends) without errors: > base-files, base-passwd, busybox, debianutils, dpkg, libc-bin, mawk, tar > > So it would be great if this could be solved somehow. What do you think? :) In case you find it useful, attached is a debdiff that worked for me. Thanks! cheers, joschdiff -Nru glibc-2.30/debian/changelog glibc-2.30/debian/changelog --- glibc-2.30/debian/changelog 2020-03-12 23:47:03.0
Bug#954374: libc6: please make maintainerscript compatible with busybox
Hi, Quoting Aurelien Jarno (2020-03-21 00:00:18) > On 2020-03-20 22:57, Johannes 'josch' Schauer wrote: > > would it be possible to make the libc6 preinst maintainer script > > compatible with busybox? Currently the preinst script calls "readlink > > -m" which is not supported by busybox. Hence the following error will be > > thrown: > > > > BusyBox v1.30.1 (Debian 1:1.30.1-4) multi-call binary. > > > > Usage: readlink [-fnv] FILE > > > > Display the value of a symlink > > > > -f Canonicalize by following all symlinks > > -n Don't add newline > > -v Verbose > > > > I tried to prepare a patch for the preinst script but ran into a FTBFS: > > > > x86_64-linux-gnu-gcc-9 -shared -static-libgcc -Wl,-O1 -Wl,-z,defs > > -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 > > -B/<>/build-tree/amd64-libc/csu/ > > -Wl,--version-script=/<>/build-tree/amd64-libc/libnss_files.map > > -Wl,-soname=libnss_files.so.2 -Wl,-z,combreloc -Wl,-z,relro > > -Wl,--hash-style=both -L/<>/build-tree/amd64-libc > > -L/<>/build-tree/amd64-libc/math > > -L/<>/build-tree/amd64-libc/elf > > -L/<>/build-tree/amd64-libc/dlfcn > > -L/<>/build-tree/amd64-libc/nss > > -L/<>/build-tree/amd64-libc/nis > > -L/<>/build-tree/amd64-libc/rt > > -L/<>/build-tree/amd64-libc/resolv > > -L/<>/build-tree/amd64-libc/mathvec > > -L/<>/build-tree/amd64-libc/support > > -L/<>/build-tree/amd64-libc/nptl > > -Wl,-rpath-link=/<>/build-tree/amd64-libc:/<>/build-tree/amd64-libc/math:/<>/build-tree/amd64-libc/elf:/<>/build-tree/amd64-libc/dlfcn:/<>/build-tree/amd64-libc/nss:/<>/build-tree/amd64-libc/nis:/<>/build-tree/amd64-libc/rt:/<>/build-tree/amd64-libc/resolv:/<>/build-tree/amd64-libc/mathvec:/<>/build-tree/amd64-libc/support:/<>/build-tree/amd64-libc/nptl > > -o /<>/build-tree/amd64-libc/nss/libnss_files.so > > /<>/build-tree/amd64-libc/csu/abi-note.o -Wl,--whole-archive > > /<>/build-tree/amd64-libc/nss/libnss_files_pic.a > > -Wl,--no-whole-archive -Wl,--start-group > > /<>/build-tree/amd64-libc/linkobj/libc.so > > /<>/build-tree/amd64-libc/libc_nonshared.a -Wl,--as-needed > > /<>/build-tree/amd64-libc/elf/ld.so -Wl,--no-as-needed > > -Wl,--end-group > > /usr/bin/ld: > > /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libselinux.so: > > undefined reference to `gettid@GLIBC_2.30' > > collect2: error: ld returned 1 exit status > > Strange. How did you try to build it? It turned out to be a problem on my side. Sorry for the false alarm. > > Thus, I'm now reporting this wishlist bug here before further working on > > a fix. > > > > Would you be willing to accept a change that makes the preinst script of > > libc6 compatible with readlink from busybox? > > On the principle yes, but it means we need to have an equivalent to > readlink -m. Do you have a way for doing that in busybox? Indeed I have. There exists a version for bash with an extensive test suite: https://github.com/bashup/realpaths I ported that one to POSIX shell while keeping the test suite and comparing it with "realpath -m": https://gitlab.mister-muffin.de/josch/realpath The preinst script should probably continue using coreutils readlink when it exists and only fall back to the re-implementation in POSIX shell if the version of readlink on the system does not provide the -m option (as it is the case with busybox). Since I now was able to successfully rebuild glibc, I can confirm that this is the last puzzlepiece needed to allow to create and configure a system containing only the following packages (and their Depends) without errors: base-files, base-passwd, busybox, debianutils, dpkg, libc-bin, mawk, tar So it would be great if this could be solved somehow. What do you think? :) Thanks! cheers, josch signature.asc Description: signature
Bug#764274: glibc: update the syntax of the Build-Profiles field
Source: glibc
Version: 2.19-11
Severity: normal
Tags: patch
Dear glibc maintainers,
the syntax for the Build-Profiles field was changed during the bootstrap
sprint in paris [1,2]. Please see attached patch for a fix of the issue.
I omitted patching debian/control which has to be regenerated.
glibc is one of three source packages which are affected. They do not
FTBFS because dpkg contains a backward compatibility hack but we'd like
to remove it after all three source packages have been adapted.
cheers, josch
diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog
--- glibc-2.19/debian/changelog 2014-09-12 23:50:53.0 +0200
+++ glibc-2.19/debian/changelog 2014-10-06 15:33:31.0 +0200
@@ -1,3 +1,10 @@
+glibc (2.19-11.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Make Build-Profiles field comply with the spec
+
+ -- Johannes Schauer j.scha...@email.de Mon, 06 Oct 2014 15:32:19 +0200
+
glibc (2.19-11) unstable; urgency=medium
[ Samuel Thibault ]
diff -Nru glibc-2.19/debian/control.in/amd64 glibc-2.19/debian/control.in/amd64
--- glibc-2.19/debian/control.in/amd64 2014-09-12 23:50:54.0 +0200
+++ glibc-2.19/debian/control.in/amd64 2014-10-06 15:46:13.0 +0200
@@ -4,7 +4,7 @@
Priority: optional
Depends: libc6 (= ${binary:Version}), ${misc:Depends}
Conflicts: amd64-libs (= 1.2)
-Build-Profiles: !stage1 !nobiarch
+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,7 +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
+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-09-12 23:50:53.0 +0200
+++ glibc-2.19/debian/control.in/armel 2014-10-06 15:50:13.0 +0200
@@ -3,7 +3,7 @@
Section: libs
Priority: optional
Depends: libc6 (= ${binary:Version}), ${misc:Depends}
-Build-Profiles: !stage1 !nobiarch
+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,7 +15,7 @@
Priority: optional
Depends: libc6-armel (= ${binary:Version}), libc6-dev (= ${binary:Version}), ${misc:Depends}
Recommends: gcc-multilib
-Build-Profiles: !nobiarch
+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-09-12 23:50:53.0 +0200
+++ glibc-2.19/debian/control.in/armhf 2014-10-06 15:50:36.0 +0200
@@ -3,7 +3,7 @@
Section: libs
Priority: optional
Depends: libc6 (= ${binary:Version}), ${misc:Depends}
-Build-Profiles: !stage1 !nobiarch
+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,7 +15,7 @@
Priority: optional
Depends: libc6-armhf (= ${binary:Version}), libc6-dev (= ${binary:Version}), ${misc:Depends}
Recommends: gcc-multilib
-Build-Profiles: !nobiarch
+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-09-12 23:50:54.0 +0200
+++ glibc-2.19/debian/control.in/i386 2014-10-06 15:49:41.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
Bug#632720: tzdata: fails to install when setting debconf values beforehand
Package: tzdata Version: 2011h-3 Severity: normal Hi, this problem was present since 2011h-1 and while I can install tzdata again since bug #631878 is fixed, I still get the exact same error as described in that bug report when using debconf-set-selections before package installation: Setting up tzdata (2011h-3) ... dpkg: error processing tzdata (--configure): subprocess installed post-installation script returned error exit status 10 Errors were encountered while processing: tzdata This is how to reproduce the problem: $ sudo multistrap -f multistrap.conf multistrap.conf: -%-- [General] arch= directory=debian-sid-multistrap cleanup=true debootstrap=Debian aptsources=Debian debconfseed=tzdata.debconf [Debian] packages=apt source=http://cdn.debian.net/debian keyring=debian-archive-keyring suite=sid -%-- tzdata.debconf: -%-- tzdata tzdata/Zones/Europe select Berlin tzdata tzdata/Areasselect Europe -%-- To not encounter the problem, either comment the debconfseed line in multistrap.conf or the lines in tzdata.debconf. Multistrap will run fine then. cheers, josch -- 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/20110705103931.17414.2957.reportbug@hoothoot
Bug#631878: fixed in tzdata 2011h-2
Hi, I can confirm that the same happens with a multistrap installation. tzdata cannot be configured: $ fakeroot fakechroot chroot debian-sid-armel-2011-06-30 dpkg --configure tzdata Setting up tzdata (2011h-2) ... dpkg: error processing tzdata (--configure): subprocess installed post-installation script returned error exit status 10 Errors were encountered while processing: tzdata $ The configuration breaks at line 87 in /usr/share/debconf/frontend where $confmodule-communicate returns a non-zero exit status and fails. cheers, josch -- 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/20110630193516.GA16569@hoothoot
