Re: Bug#988740: unblock: glibc/2.31-12

2021-05-23 Thread Paul Gevers
Hi kibi,

On 24-05-2021 06:30, Cyril Brulebois wrote:
> Nothing dramatic, we'll be more explicit next time and pick an option
> for real instead of considering both options and letting one pick a
> favorite. :)

Let's agree on that indeed. It's a shame that we get into these
annoyances, while all we try to do is help each other.

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Re: Bug#988740: unblock: glibc/2.31-12

2021-05-23 Thread Cyril Brulebois
Hi Paul,

Paul Gevers  (2021-05-20):
> On 20-05-2021 08:23, Cyril Brulebois wrote:
> > Having udeb-producing packages change under our feet when we're in
> > the middle of unentangling the rendering mess isn't exactly nice…
> 
> I'm terribly sorry, but I thought we discussed migrating udeb generating
> packages recently on IRC #d-release. I now realize that's a bit longer
> ago than I though. To quote you:
> 
> [00:00:00] - {Day changed to Monday, 26 April 2021}
> [22:06:17]  looks to me we have enough to fix and/or to debug on
> our plate that we won't be issuing another RC in a week or so, so
> freezing everyone (keeping everyone frozen) will only generate more
> requests for acks; at this stage, it's likely easier to let stuff
> migrate and deal with consequences afterward
> 
> I interpreted that as you are sort of fine at this moment if we
> migrated the packages if they are otherwise fine. We should have
> agreed on a schedule and it was on my TODO list to ask you today.

I'm a little too lazy to dig into IRC logs, but I'm pretty sure we had
two possibilities: either keep all udeb-producing frozen and deal with
individual requests; or lift the general block-udeb. Given nothing
changed in britney1.git since Apr 14, I seemed to me we went for d-i
acks (which I've tried to handle swiftly) and that's what got me
surprised for the glibc thing.

Nothing dramatic, we'll be more explicit next time and pick an option
for real instead of considering both options and letting one pick a
favorite. :)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: Bug#988740: unblock: glibc/2.31-12

2021-05-20 Thread Paul Gevers
Hi Cyril

On 20-05-2021 08:23, Cyril Brulebois wrote:
> Having udeb-producing packages change under our feet when we're in
> the middle of unentangling the rendering mess isn't exactly nice…

I'm terribly sorry, but I thought we discussed migrating udeb generating
packages recently on IRC #d-release. I now realize that's a bit longer
ago than I though. To quote you:

[00:00:00] - {Day changed to Monday, 26 April 2021}
[22:06:17]  looks to me we have enough to fix and/or to debug on
our plate that we won't be issuing another RC in a week or so, so
freezing everyone (keeping everyone frozen) will only generate more
requests for acks; at this stage, it's likely easier to let stuff
migrate and deal with consequences afterward

I interpreted that as you are sort of fine at this moment if we migrated
the packages if they are otherwise fine. We should have agreed on a
schedule and it was on my TODO list to ask you today.

Additional note: glibc is on the list of build-essentials [1], so,
according to our freeze policy [2] it would have needed a pre-approval
already.

Paul

[1] https://release.debian.org/bullseye/essential-and-build-essential.txt
[2] https://release.debian.org/bullseye/freeze_policy.html#transition



OpenPGP_signature
Description: OpenPGP digital signature


Re: Bug#988740: unblock: glibc/2.31-12

2021-05-20 Thread Cyril Brulebois
Hi,

Aurelien Jarno  (2021-05-18):
> [ Risks ]
> The fixes related to the testsuite involves many changes to our build
> system, by letting the upstream makefiles to install the ld.so symlink
> instead of doing it in the Debian makefiles, in an architecture specific
> way for bi/tri-arch packages. While the changes might look risky at a
> first glance, they do not change the code in the binaries, but only the
> ld.so symlinks and the libc.so linker scripts. Those have been verified
> manually on the packages built by glibc and cross-toolchain-base.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing

No objection, thanks.

Just to be on the safe side, I've built a netboot-gtk image against
unstable's udebs and run a few installation and rescue tests, using
various languages and I haven't noticed anything worrisome.


And since I was wondering what the change was for the German debconf
template, running `d` told me the package has migrated already, and
it was indeed already unblock(-udeb)'ed…

Having udeb-producing packages change under our feet when we're in
the middle of unentangling the rendering mess isn't exactly nice…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#988740: unblock: glibc/2.31-12

2021-05-18 Thread Aurelien Jarno
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-glibc@lists.debian.org, debian-b...@lists.debian.org

Please unblock package glibc

[ Reason ]
This new version fixes testsuite failures when run on a kernel which has
kernel.unprivileged_userns_clone set to 1. This is the case of the
Bullseye kernel. This problem manifests itself as an FTBFS when building
the package or a failed autopkgtests.

In addition this version also fixes the display of non-ascii characters
in German debconf template. It also includes fixes from the upstream
stable branch fixing:
- a wrong assumption of available instructions on s390x in the memmove
  code which might be triggered by a kernel parameter or some older
  versions of zVM
- a fix in the way of AT_SECURE binaries are handled, which might be
  used to facilitate the exploitation of security issues in those
  binaries

[ Impact ]
If the unblock is not granted, users won't be able to build the package
from sources on a Bullseye system without using the nocheck build option
or disabling kernel.unprivileged_userns_clone. In addition users with
a German locale will have to understand the displayed text without the
non-ASCII letters.

[ Tests ]
The changes related to the testsuite actually improves the testsuite
coverage. This allowed to find an issue in the debian/rules makefile
causing the value of the --build= parameter to be wrongly empty.

The debconf changes have been tested manually on a system set to German
locale.

The upstream changes related to the AT_SECURE binaries come with
additional tests. Note that those tests actually represent the bigger
part of the debdiff.

[ Risks ]
The fixes related to the testsuite involves many changes to our build
system, by letting the upstream makefiles to install the ld.so symlink
instead of doing it in the Debian makefiles, in an architecture specific
way for bi/tri-arch packages. While the changes might look risky at a
first glance, they do not change the code in the binaries, but only the
ld.so symlinks and the libc.so linker scripts. Those have been verified
manually on the packages built by glibc and cross-toolchain-base.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
The decision to install the ld.so symlink using the Debian specific
makefiles instead of the upstream ones seems to have been taken many
years ago to avoid changing dpkg-cross. dpkg-cross has been fixed
recently in version 2.6.18+nmu1 (already in Bullseye), so this is not
an issue anymore. No conflicts or breaks against dpkg-cross have been
added as dpkg-cross is basically a .deb mangler which takes any .deb
file from the command line.

unblock glibc/2.31-12
diff -Nru glibc-2.31/debian/changelog glibc-2.31/debian/changelog
--- glibc-2.31/debian/changelog 2021-03-31 22:09:32.0 +0200
+++ glibc-2.31/debian/changelog 2021-05-01 22:56:06.0 +0200
@@ -1,3 +1,29 @@
+glibc (2.31-12) unstable; urgency=medium
+
+  * debian/po/de.po: fix encoding declaration.  Closes: #986450.
+  * debian/patches/git-updates.diff: update from upstream stable branch:
+- On s390x, check for vector support in memmove ifunc-selector in
+  addition to Miscellaneous-Instruction-Extensions.
+  * debian/patches/any/local-rtlddir-cross.diff: drop patch, letting upstream
+makefiles to install the dynamic linker symlink directly in the right
+location. This fixes the temporary installation done by upstream makefiles
+to run some tests in a container.  Closes: #973278, #985617.
+  * debian/rules.d/build.mk: do not create the dynamic linker manually.
+  * debian/sysdeps/*.mk: do not create the dynamic linker manually for
+bi/tri-arch packages.
+  * debian/rules.d/build.mk: create the soname symlink for ld-2.xx.so, to
+avoid its creation later by ldconfig.
+  * debian/debhelper.in/libc.install, debhelper.in/libc-alt.install,
+debhelper.in/libc-udeb.install, debhelper.in/libc-udeb.install.hurd-i386:
+adjust given that the dynamic linker symlink is now already at the correct
+location.
+  * debian/patches/git-updates.diff: update from upstream stable branch:
+- Fix GLIBC_TUNABLES parsing for AT_SECURE binaries.
+  * debian/rules.d/build.mk: escape EOL so that $configure_build is correctly
+passed to the configure script.
+
+ -- Aurelien Jarno   Sat, 01 May 2021 22:56:06 +0200
+
 glibc (2.31-11) unstable; urgency=medium
 
   * debian/debhelper.in/libc.preinst: handle the case where debconf
diff -Nru glibc-2.31/debian/debhelper.in/libc-alt.install 
glibc-2.31/debian/debhelper.in/libc-alt.install
--- glibc-2.31/debian/debhelper.in/libc-alt.install 2019-07-29 
11:56:57.0 +0200
+++ glibc-2.31/debian/debhelper.in/libc-alt.install 2021-04-25 
18:11:42.0 +0200
@@ -1,4 +1,5 @@
 # This file is used for biarch libraries.