Upcoming stable point release (10.4)

2020-04-14 Thread Adam D. Barratt
Hi,

The next point release for "buster" (10.4) is scheduled for Saturday,
May 9th. Processing of new uploads into buster-proposed-updates will be
frozen during the preceding weekend.

Regards,

Adam



Bug#910685: glibc: please support DPKG_ROOT

2020-04-14 Thread Helmut Grohne
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