Re: Bug#1017777: bullseye-pu: package glibc/2.31-13+deb11u4

[Cyril Brulebois]

Aurelien Jarno  (2022-08-20):
> [ Reason ]
> There are multiple fixes in this upload, mostly coming from the upstream
> stable branch:
> - One security issue with CVE entry
> - Multiple overflow fixes to wide string functions
> - Failure to enforce libio vtable protection
> - A performance issue with string functions affecting Skylake-X CPUs (up
>   to 40% slower)
> - A new NEW.Debian.gz entry for libc6-dev explaining users how to switch
>   from to the TI-RPC implementation following the Sun RPC implementation
>   removal in glibc 2.31
> - Make grantpt usable after multi-threaded fork to prevent Ansible
>   deadlocks.

No objections in principle on the d-i side.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1016868: libc6-udeb: dangling ld-linux symlink

[Cyril Brulebois]

Package: libc6-udeb
Version: 2.34-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debian-b...@lists.debian.org

Hi,

Checking fil's report regarding runtime issues related to libc6-udeb,
which I thought to be a major version mismatch (d-i built against
unstable from a few hours ago = 2.33, but running against current
unstable = 2.34), I ended up with a fresh build that doesn't boot:
failure to execute /init.

Smallest bisection ever:
 - Building d-i against testing's udebs fixes it.
 - There are only a handful of differences… picking one “at random”.
 - Building d-i against testing's udebs except libc6-udeb from unstable
   generates the problem.

To get the booting issue out of the way, I've verified that I was able
to start busybox from the build tree after a netboot build against
testing's udebs, using this:

cd build/tmp/netboot/tree
sudo chroot . /bin/busybox sh

That's not the case after a build against unstable's udebs. Of course,
strace cannot report much:

chroot(".") = 0
chdir("/")  = 0
execve("bin/busybox", […])  = -1 ENOENT (No such file or 
directory)

Looking at the contents of the udebs before/after, a number of files and
symlinks are different, and there's one missing piece:

 - before:

./lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 -> ld-2.33.so
./lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.33.so

 - after:

./lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

Thanks to Aurélien for investigating at the same time as I did, and for
the upcoming fix!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

[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)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

[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)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#941853: crypt(3) should be provided by libxcrypt

[Cyril Brulebois]

Aurelien Jarno  (2019-12-06):
> There should be no changes needed on the d-i side. libc6-udeb has a
> new dependency on libcrypt1-udeb. When packages get rebuilt against
> libxcrypt, they'll have a direct dependency on libcrypt1-udeb.
> 
> There is a small impact on size (~100kB) as libxcrypt provides a bit
> more functionality.

Perfect, thanks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#941853: crypt(3) should be provided by libxcrypt

[Cyril Brulebois]

Hi,

Marco d'Itri  (2019-10-07):
> Dear debian-boot: for the benefit of the ftpmasters, please confirm that 
> you have no objections to src:libxcrypt generating a libcrypt1-udeb 
> package (initially in experimental) which will provide crypt(3) 
> currently in the libc udeb.
> 
> > I guess we should keep building libcrypt1 for the bi/tri-arch packages.
> What do I need to do about this?
> 
> > > (Also, do not forget about the man pages in the -dev packages.)
> > The man page was not provided by the -dev package but by manpages-dev.
> Actually I see that it automatically stopped shipping crypt(3) and 
> crypt_r(3) in 5.01-1, so I will add Breaks+Replaces.
> 
> > We must build the libcrypt1 udeb, and add a depends from libc6-deb to
> > libcrypt1-udeb, otherwise we might break d-i. At some point we might
> OK, I will start again building the udeb with the next upload.

Aurelien, Marco, do we need to anticipate any changes on the d-i side?

Or will that udeb addition just result in a new dependency from crypt-using
udebs to libcrypt1-udeb?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#924657: release-notes? Was: Re: kbdnames are generated with incorrect translations

[Cyril Brulebois]

Hi,

Paul Gevers  (2019-07-04):
> This apparently wasn't uploaded, so it's to late for the initial buster
> release. Does it make any sense to mention this in the release notes? I
> tend to say it doesn't, but will do it nevertheless when others think it
> does.

I see release notes as something that should be meaningful during the
the release's lifetime? I would rather see that issue documented in
installer's errata instead, as that's something we expect to be fixed
“soon”?

  
https://salsa.debian.org/webmaster-team/webwml/blob/master/english/devel/debian-installer/errata.wml

I've just double checked the effects of the patch and I'll send a
separate update, as a follow-up to the initial patch proposal.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: busybox sh broken on i386 with glibc 2.26, leads to kernel panic

[Cyril Brulebois]

Raphael Hertzog <hert...@debian.org> (2018-01-17):
> On Wed, 17 Jan 2018, Aurelien Jarno wrote:
> > busybox is compiled with -mpreferred-stack-boundary=2 on i386 which has
> > the same effect of reducing the default stack alignment from 16 bytes to
> > 2 bytes. This comes from arch/i386/Makefile:
> > 
> > |  # -mpreferred-stack-boundary=2 is essential in preventing gcc 4.2.x
> > |  # from aligning stack to 16 bytes. (Which is gcc's way of supporting 
> > SSE).
> > |  CFLAGS += $(call cc-option,-march=i386 -mpreferred-stack-boundary=2,)
> > 
> > I don't really get why it is essential to prevent gcc from aligning
> > stack to 16 bytes, anyway this is a bad idea. Removing this option just
> > fixes the issue.

Oh wow, that's an old commit:
| commit 65b8cfb2a0b6854271dbd8baf5203896223cd4ce
| Author: Denis Vlasenko <vda.li...@googlemail.com>
| Date:   Mon Jul 23 21:05:06 2007 +
| 
| add comment why preferred stack boundary is 4 on i386

> I confirm that rebuilding busybox with this option dropped fixed the issue
> for me. I uploaded a fixed busybox to Kali. I'm happy to do the same for
> Debian if it can help the current maintainers.

Fixing it ASAP would look good to me (unless you here differently from
Chris or Christoph); it would be great to ping upstream to propagate
Aurélien's comments too.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#882158: stretch-pu: package glibc/2.24-11+deb9u2

[Cyril Brulebois]

Adam D. Barratt  (2017-11-24):
> This looks OK to me, but will need a KiBi-ack; CCing.

lgtm; apologies for the delay.


KiBi.


signature.asc
Description: PGP signature

Re: Bug#837004: installation-locale: FTBFS: no output file produced because warnings were issued

[Cyril Brulebois]

Aurelien Jarno <aurel...@aurel32.net> (2017-02-06):
> On 2017-02-06 00:50, Cyril Brulebois wrote:
> > Hi,
> > 
> > Aurelien Jarno <aurel...@aurel32.net> (2017-02-06):
> > > Well this kind of patch is not mergeable upstream, so we will have to
> > > keep it forever.
> > 
> > Or just for stretch given the following points?
> 
> No, I don't think the freeze is an excuse for fixing bugs the wrong way.
> 
> > > What would be wrong in using a supported value for the debian-installer
> > > locale? It should only be a dozen of lines to change.
> > 
> > A couple of things:
> >  1. I don't know anything about locales.
> 
> Understandable.
> 
> >  2. Nobody moved a finger on this RC bug for months, so I'm not sure we
> > have anyone else able/willing to fix this.
> 
> Or maybe people able/willing to fix this were not aware of the bug?
> 
> >  3. The freeze is here and I'm not too thrilled about changing code/data
> > I don't have a clue about.
> 
> These strings only changes LC_IDENTIFICATION, so there is no risk to
> replace them by "i18n:2012". We have done that for a few additional
> locales we have in the glibc, including for the C.UTF-8 locale [1].
> 
> If you don't want to fix that yourself, I can just do the upload.

If you're certain this can't generate any regressions in d-i, sure,
please go ahead.


KiBi.


signature.asc
Description: Digital signature

Re: Bug#837004: installation-locale: FTBFS: no output file produced because warnings were issued

[Cyril Brulebois]

Hi,

Aurelien Jarno  (2017-02-06):
> Well this kind of patch is not mergeable upstream, so we will have to
> keep it forever.

Or just for stretch given the following points?

> What would be wrong in using a supported value for the debian-installer
> locale? It should only be a dozen of lines to change.

A couple of things:
 1. I don't know anything about locales.
 2. Nobody moved a finger on this RC bug for months, so I'm not sure we
have anyone else able/willing to fix this.
 3. The freeze is here and I'm not too thrilled about changing code/data
I don't have a clue about.

> Alternatively would it make sense to install the C.UTF-8 locale from
> libc-bin in libc6-udeb?

Maybe…


KiBi.


signature.asc
Description: Digital signature

Re: Bug#837004: installation-locale: FTBFS: no output file produced because warnings were issued

[Cyril Brulebois]

Hi,

Lucas Nussbaum <lu...@debian.org> (2016-09-07):
> Source: installation-locale
> Version: 1.6
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160906 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > localedef -i C.UTF-8.in -f "UTF-8" ./C.UTF-8
> > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_CTYPE'
> > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_NUMERIC'
> > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_TIME'
> > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_COLLATE'
> > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> > `LC_MONETARY'
> > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> > `LC_MESSAGES'
> > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_PAPER'
> > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_NAME'
> > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_ADDRESS'
> > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> > `LC_TELEPHONE'
> > LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> > `LC_IDENTIFICATION'
> > no output file produced because warnings were issued
> > Makefile:4: recipe for target 'C.UTF-8' failed
> > make[1]: *** [C.UTF-8] Error 4

I think this is due to the following commit, first released with 2.24:
| commit 900f59f084bfe35cb389bbe0dc464413a1a38e90
| Author: Mike Frysinger <vap...@gentoo.org>
| Date:   Wed Apr 13 18:38:56 2016 -0400
| 
| localedef: check LC_IDENTIFICATION.category values
| 
| Currently localedef accepts any value for the category keyword.  This has
| allowed bad values to propagate to the vast majority of locales (~90%).
| Add some logic to only accept a few standards.

I suppose it makes sense to add a Debian-specific patch to the glibc
package to accept “our extra standard”. I've successfully tested the
attached patch on top of glibc master, even if I had to disable the
testsuite because of this:
| FAIL: rt/tst-shm
| original exit status 1
| --
| +-+
| | Encountered regressions that don't match expected failures. |
| +-+
| FAIL: rt/tst-shm
| debian/rules.d/build.mk:115: recipe for target 
'/home/kibi/hack/glibc/glibc-debian.git/stamp-dir/check_libc' failed

With upgraded libc packages, installation-locale builds fine again.

glibc maintainer: if you agree with this proposed path and patch, please
steal this bug report awawy from src:installation-locale.


KiBi.
From e9a91a6d4c17fa07fe8199c6abc026c7f65cee88 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois <k...@debian.org>
Date: Sat, 4 Feb 2017 21:44:52 +0100
Subject: [PATCH] Accept D-I specific locale: C@utf-8:2000 (Closes: #837004).

This fixes the installation-locale FTBFS with glibc >= 2.24
---
 .../locale/local-accept-debian-installer-locale.diff  | 19 +++
 debian/patches/series |  1 +
 2 files changed, 20 insertions(+)
 create mode 100644 debian/patches/locale/local-accept-debian-installer-locale.diff

diff --git a/debian/patches/locale/local-accept-debian-installer-locale.diff b/debian/patches/locale/local-accept-debian-installer-locale.diff
new file mode 100644
index 000..8ce8e18
--- /dev/null
+++ b/debian/patches/locale/local-accept-debian-installer-locale.diff
@@ -0,0 +1,19 @@
+The installation-locale component of the Debian Installer uses the
+“C@utf-8:2000” category, while glibc only accepts a small number of
+categories (starting with 2.24). Add the D-I specific category to
+this list accordingly.
+
+ locale/programs/ld-identification.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/locale/programs/ld-identification.c
 b/locale/programs/ld-identification.c
+@@ -187,6 +187,8 @@ No definition for %s category found"), "LC_IDENTIFICATION"));
+ 	  "posix:1993",
+ 	  "i18n:2004",
+ 	  "i18n:2012",
++	  /* Debian Installer -- installation-locale, #837004 */
++	  "C@utf-8:2000",
+ 	};
+ 	  size_t i;
+ 	  bool matched = false;
diff --git a/debian/patches/series b/debian/patches/series
index 2f9d247..087f331 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,6 +4,7 @@ locale/check-unknown-symbols.diff
 locale/fix-LC_COLLATE-rules.diff
 locale/preprocessor-collate-uli-sucks.diff
 locale/preprocessor-collate.diff  # should not be needed anymore, but keep it anyways.
+locale/local-accept-debian-installer-locale.diff
 locale/locale-print-LANGUAGE.diff
 locale/LC_IDENTIFICATION-optional-fields.diff
 locale/LC_COLLATE-keywords-ordering.diff
-- 
2.1.4



signature.asc
Description: Digital signature

Re: Bug#851790: installation-reports: DNS not working

[Cyril Brulebois]

Steve McIntyre <st...@einval.com> (2017-01-19):
> On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote:
> >On 2017-01-19 01:53, Cyril Brulebois wrote:
> >
> >> It's been a while since I last looked at/understood mklibs stuff though,
> >> feel free to fix my suspicions/conclusions.
> >
> >The long term solution is to package all the libraries into udeb
> >packages. That way we can simply get rid of the mklibs pass.
> >
> >The workaround are to make sure the chroots are up-to-date (which should
> >be the case now on the build daemons). An other alternative would be to
> >avoid copying a library in mklibs if it is already present in the image.
> >That might break if some very strict dependencies are used, though
> >I guess the way the udebs are downloaded, they should always have the
> >same or a newer version than in the chroot.
> 
> Thanks for the explanation - it's appreciated!

Yeah, thanks for the confirmation.

> Is there anything we could do to fail the build if versions are out of
> sync, rather than let a broken build through?

Well, I think Aurélien mentioned it: ensure chroots are up-to-date.
Tweaking the buildscript might do the trick, I suppose. AFAIUI, the
build isn't broken every time there's a divergence in versions anyway;
you're sometimes (un)lucky.

Can't really devote time right now to investigating the “let's not copy
stuff over if it's already present” suggestion…


KiBi.


signature.asc
Description: Digital signature

Re: Bug#851790: installation-reports: DNS not working

[Cyril Brulebois]

Cyril Brulebois <k...@debian.org> (2017-01-19):
> Summing up things from IRC:
>  - in an uptodate sid chroot (both development version and minimal one
>with daily-build script): no DNS issues with the generated mini.iso
>(amd64, tested within stable's kvm on amd64). My image was also
>tested successfully by Steve, so not a setup issue.
> 
>  - I can reproduce the issue with dailies from 2017-01-18, and from
>2017-01-19 (I picked it in advance during its build on barriere).
> 
>  - I can reproduce the issue in the above mentioned sid chroot if
>I downgrade these packages to testing's version (-9 → -8):
>  sudo apt-get install libc6:amd64=2.24-8 libc6-dev:amd64=2.24-8 
> libc-dev-bin=2.24-8
> 
>  - The older set of libc* packages is installed in barriere's current
>amd64 sid chroot, too.
> 
>  - Steve could only produce broken images when building locally, until
>he upgraded his libc* packages as well.

And since Steve was wondering how we could release something for Stretch
RC 1 with that… I've just confirmed that using -8 .deb with a -8 .udeb
(reversioned as -9+hack so that its being dropped under localudebs makes
it take precedence over sid's .udeb) leads to an image that's working
fine. And AFAICT that's the combination we had at the time.

I suspect the implementation change through the following patch in -9:
glibc-2.24/debian/patches/any/cvs-resolv-internal-qtype.diff

plus 283e7a294275a7da53258600deaaafbbec6b96c1 in debian-installer.git is
what is triggering the issue? (Explaining why host's libc .deb have an
impact on the built images.)

It's been a while since I last looked at/understood mklibs stuff though,
feel free to fix my suspicions/conclusions.


KiBi.


signature.asc
Description: Digital signature

Re: Bug#851790: installation-reports: DNS not working

[Cyril Brulebois]

Cyril Brulebois <k...@debian.org> (2017-01-19):
> You can try downgrading the kernel, but I'd usually look at glibc first
> for DNS related issues.

Summing up things from IRC:
 - in an uptodate sid chroot (both development version and minimal one
   with daily-build script): no DNS issues with the generated mini.iso
   (amd64, tested within stable's kvm on amd64). My image was also
   tested successfully by Steve, so not a setup issue.

 - I can reproduce the issue with dailies from 2017-01-18, and from
   2017-01-19 (I picked it in advance during its build on barriere).

 - I can reproduce the issue in the above mentioned sid chroot if
   I downgrade these packages to testing's version (-9 → -8):
 sudo apt-get install libc6:amd64=2.24-8 libc6-dev:amd64=2.24-8 
libc-dev-bin=2.24-8

 - The older set of libc* packages is installed in barriere's current
   amd64 sid chroot, too.

 - Steve could only produce broken images when building locally, until
   he upgraded his libc* packages as well.


→ Copying glibc@packages for the time being, even I suspect this will
  likely disappear entirely once -9 propagates…


KiBi.


signature.asc
Description: Digital signature

Bug#836446: libc6-dev: depends on linux-libc-dev:$arch, breaking debootstrap

[Cyril Brulebois]

Aurelien Jarno  (2016-09-03):
> clone 836446 -1
> reassign -1 debootstrap
> retitle -1 debootstrap: doesn't support arch-qualified dependencies
> affects -1 libc6-dev
> thanks

Thanks for this.

> On 2016-09-03 11:28, Sven Joachim wrote:
> > Package: libc6-dev
> > Version: 2.24-1
> > Severity: important
> > 
> > The fix for bug #834706 has the side effect that libc6-dev now depends
> > on linux-libc-dev:$arch :
> > 
> > ,
> > | $ apt-cache show libc6-dev | grep ^Depends
> > | Depends: libc6 (= 2.24-1), libc-dev-bin (= 2.24-1), linux-libc-dev:i386 
> > (>= 4.6.4-1)
> > `
> > 
> > While dpkg and apt obviously don't have a problem with that, debootstrap
> > cannot cope with it, and "debootstrap --variant=buildd" fails to even
> > download linux-libc-dev.  See the attached log.
> 
> That's definitely a bug in debootstrap. In the future it's more and more
> likely that we'll have arch-qualified dependencies in the bases packages,
> so this has to be fixed. I am therefore cloning and reassigning the bug.

Do you plan to implement a workaround in glibc for now, or should this bug
report (on the debootstrap side) be raised to RC and fixed before we can
think of a new d-i release? (I have no such plan right now, but it might
be nice not to wait too much once linux has migrated).


KiBi.


signature.asc
Description: Digital signature

Re: Bug#740068: debian-installer: segfaults when built against testing

[Cyril Brulebois]

Hi,

Cyril Brulebois <k...@debian.org> (2014-02-25):
> Aurelien Jarno <aurel...@aurel32.net> (2014-02-25):
> > Yes, we get this bug happening regularly because the binaries on the
> > image went through the library reduction process with a given libc (here
> > 2.18), and later a different version of the libc is unpacked over it
> > (here 2.17). Therefore some symbols are missings, causing the segfault.
> > In addition I think there are also some version mismatches between libnss-*
> > and libc6 when the old one is getting unpacked.
> 
> alright, thanks.

Fastforward a few years, we now have libnss-dns-udeb and libnss-files-udeb
merged into libc6-udeb; additionally, we're no longer reducing libraries,
since we switched to mklibs-copy. Relevant commits in debian-installer.git:
| commit 83a73f6400ea8dd6fdedafe64e32e16c7c0e213a
| Author: Aurelien Jarno <aurel...@aurel32.net>
| Date:   Wed May 13 16:13:27 2015 +0200
| 
| Use mklibs-copy instead of mklibs, as discussed on the mailing list.

and:
| commit 283e7a294275a7da53258600deaaafbbec6b96c1
| Author: Aurelien Jarno <aurel...@aurel32.net>
| Date:   Wed Mar 30 08:01:26 2016 +
| 
| Stop excluding libc{0.1,0.3,6,6.1} as we now use mklibs-copy for the 
reduction pass. This avoids dropping libnss libraries and also avoids a useless 
download of this udeb during the installation.


But trying to install stretch as of today, using Stretch Alpha 7 through
PXE results in an error while trying to install libc6-udeb at the partman
step.

Logs say:
| anna-install: Installing partman-auto-lvm
| anna[PID]: DEBUG: retrieving libc6-udeb 2.23-4

and d-i/debconf says that libc6-udeb couldn't be installed for unknown
reasons.

initrd has a 2.22-11 libc6-udeb installed (/var/lib/dpkg/status), and it
seems there are no udebs depending on a >= 2.23 libc6-udeb; so libc6-udeb
getting (re)installed at this stage is rather strange in the first place;
I'm not sure whether glibc is supposed to support this upgrade anyway,
Aurélien mentioned it might possibly be due to udpkg's not unpacking
atomically. End result: everything segfaults past this point.

I've reproduced this using:
  
http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20160630/images/netboot/gtk/netboot.tar.gz

Some comments:
 - this will likely disappear when we release a new d-i;
 - but it would be nice to figure out why libc6-udeb is pulled while it's
   already installed; this might affect other components, so it'd be
   better to figure out why and fix that now.
 - maybe glibc/udpkg/… could use some improvements to be more reliable
   when that happens anyway.


KiBi.


signature.asc
Description: Digital signature

Re: Next d-i alpha release: late June

[Cyril Brulebois]

Hi,

Nicholas D Steeves  (2016-06-28):
> Could someone please tell me what the deadline is for adding expanded
> partman-btrfs functionality?  My proposal is in a thread on
> debian-b...@lists.debian.org, subject: "Re: btrfs subvolume naming
> scheme".  A résumé of the read is: add the volume-manager-like
> subvolume setup, and hopefully also add btrfs-style raid1 profile
> support, and also the question of whether Debian should follow Ubuntu
> and openSUSE subvolume naming conventions or Fedora/CentOS/RHEL ones.
> The upstream wiki advocates Fedora/CentOS/RHEL-style.

The upcoming release will use whatever is in testing at this point, so
it'll be for a later release.


KiBi.


signature.asc
Description: Digital signature

Next d-i alpha release: late June

[Cyril Brulebois]

Hi,

I've just checked with Ben, it seems we could be getting a 4.6 kernel
suitable for testing (no regressions reported from previous version +
mips* FTBFS fix) shortly. We could think about urgenting it into testing
and releasing a new d-i early in the week, which seems OK on the -cd
side too.

Glibc maintainers (esp. Aurélien): you should then have a clear path for
the new glibc in unstable. I'm not sure how much time it'll need to be
ready, that's why I'd slightly prefer if we could go for a d-i release
first (as outlined above). In case major blockers pop up, we would
probably let you go ahead with the new glibc upload and postpone d-i
until glibc reaches testing.

Having checked with -release already, I'm freezing udebs right away.

(Please cc me on replies.)


KiBi.


signature.asc
Description: Digital signature

Re: Bug#819685: [Pkg-iscsi-maintainers] Bug#819685: open-iscsi-udeb: please drop libnss-files-udeb dependency

[Cyril Brulebois]

Hi,

Christian Seiler  (2016-04-02):
> Control: tags -1 + confirmed pending
> 
> Thanks for the notification about the glibc change!
> 
> On 03/31/2016 09:23 PM, Aurelien Jarno wrote:
> > As of glibc 2.22-5, libnss-files-udeb has been merged into libc-udeb. 
> > Therefore the dependency in open-iscsi-udeb could now be dropped.
> 
> Fixed in git:
> https://anonscm.debian.org/cgit/pkg-iscsi/open-iscsi.git/commit/?id=2f35aeb0b6ab8da185450ddaad285051cc081176
> 
> Ritesh and I don't have any immediate plans for a next upload, so I
> don't know when this will hit the archive, but there will definitely
> be more updates before Stretch is released. If there are unforeseen
> problems with the glibc change that would require an earlier upload
> of the package with just the dropped dependency, please increase the
> severity of this bug report to at least important and I'll upload
> sooner.

Steve approached me to see if I could lift the block-udeb on the glibc
since he was interested in getting its arm64 fix migrate to testing.

Given src:glibc drops libnss-files-udeb, and given your package hasn't
been updated yet, src:glibc will not be able to migrate to testing for a
while.

I suppose it would be nice if you could update your package right away.

(The current block-udeb should be lifted in a few hours; the other
reverse-depends was espeakup-udeb, fixed last night, migrated minutes
ago.)


KiBi.


signature.asc
Description: Digital signature

Re: Bug#740068: debian-installer: segfaults when built against testing

[Cyril Brulebois]

Cyril Brulebois k...@debian.org (2014-02-25):
 Cyril Brulebois k...@debian.org (2014-02-25):
  It doesn't seem to happen when building against unstable, but it
  would be nice to make sure we spot the reason/bugfix and possibly
  speed up its propagation to testing.
 
 I forgot to mention it's netboot/gtk/mini.iso on amd64, in case it
 matters.

So here are the results of some cross tests, using this:
  git clean -xdf  make rebuild_netboot-gtk USE_UDEBS_FROM=...


  chroot \ USE_UDEBS_FROM |  jessie  |   sid
  -
  jessie  |OK| segfault
  -
  sid | segfault |OK

(FTR my chroots are up-to-date and sid's has 2.18-3.)

This might be due to some libc mismatch (2.17 vs. 2.18) I guess?

This rings some bells:
| eglibc (2.18-2) unstable; urgency=medium
|
|   [ Aurelien Jarno ]
|   * any/local-ldconfig-ignore-ld.so.diff: new patch to ignore the dynamic
| linker in ldconfig.  Closes: #699206, #707185, #727786, #736097,
| #739734, #739758.

eglibc maintainers, can you please suggest further directions for me to
look into? Initial d-i bug report with busybox sh segfaults:
  http://bugs.debian.org/740068

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#740068: debian-installer: segfaults when built against testing

[Cyril Brulebois]

Hi,

Aurelien Jarno aurel...@aurel32.net (2014-02-25):
 Yes, we get this bug happening regularly because the binaries on the
 image went through the library reduction process with a given libc (here
 2.18), and later a different version of the libc is unpacked over it
 (here 2.17). Therefore some symbols are missings, causing the segfault.
 In addition I think there are also some version mismatches between libnss-*
 and libc6 when the old one is getting unpacked.

alright, thanks.

  This rings some bells:
  | eglibc (2.18-2) unstable; urgency=medium
  |
  |   [ Aurelien Jarno ]
  |   * any/local-ldconfig-ignore-ld.so.diff: new patch to ignore the dynamic
  | linker in ldconfig.  Closes: #699206, #707185, #727786, #736097,
  | #739734, #739758.
 
 No it's not related to that. This bug is when you have multiple libc of
 the same architecture on a system (e.g. libc6:amd64 and
 libc6-amd64:i386, or libc6:i386 and libc-i386:amd64)

OK, thanks.

  eglibc maintainers, can you please suggest further directions for me to
  look into? Initial d-i bug report with busybox sh segfaults:
http://bugs.debian.org/740068
  
 
 You just have to ensure that the libc used for building the image is the
 same as the one used later in d-i.

Said slightly otherwise, this issue should go away as soon as eglibc
hits testing. I guess we can live with a few days of breakages, if that
only happens when a new major eglibc release appears in unstable, and
lasts until it's ready to migrate to testing. If that's correct, it
would be nice to announce new major releases to -boot@ a few days before
it gets uploaded. Or I could monitor that along with linux kernel
versions… Will think about it.

Thanks again for the explanations; I'll keep this bug report open as a
placeholder for the time being.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#699818: pre-approval for unblock: eglibc change restricted for GNU/kFreeBSD

[Cyril Brulebois]

Control: tag -1 moreinfo

Hi Petr,

Petr Salinger petr.salin...@seznam.cz (05/02/2013):
 Please pre-approve following change for eglibc.
 
 The rationale is that setgroups(size, groups) changes egid on kfreebsd,
 precisely groups[0] is the new egid.
 
 initgroups(user, gid) prepares the groups list via
 internal_getgrouplist(). It puts supplied gid as the first entry in
 all but NSCD cases.
 The patch fixes the remaining NSCD case.
 
 The change will be restricted for GNU/kFreeBSD build, it is not yet
 uploaded. The original submitter of bug (#698102, #699593) confirms,
 that it fixes his situation. In his setup, one supplementary group
 got lost.

FWIW that means only applying the below patch in kfreebsd-* cases (I
was looking for some #ifdef initially), using arch-specific series:
  debian/changelog
  debian/patches/kfreebsd/local-initgroups-order.diff
  debian/patches/series.kfreebsd-amd64
  debian/patches/series.kfreebsd-i386

This seems to have been merged since eglibc 2.17-1. Were there any
related regressions? Or happy users popping up because that fixed all
their issues?

Eglibc maintainers: is that the only thing you'd want to fix in
wheezy? On its own, I'm not sure it warrants an upload. Any other
opinions?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#625521: glibc: causes segfault in Xorg

[Cyril Brulebois]

Michel Dänzer daen...@debian.org (04/05/2011):
 More importantly xserver-xorg-core-dbg, to get debugging symbols
 for /usr/lib/xorg/modules/libshadow.so .

If fbdev is indeed used (see Michel's other mail about that),
rebuilding it with debugging symbols would be nice.

AFAICT from a quick grep, the entry point to shadowUpdate*Packed would
be through:
| src/fbdev.c:   shadowUpdateRotatePackedWeak() : 
shadowUpdatePackedWeak(),

in the driver, leading to that in the server:
| miext/shadow/shpacked.c:shadowUpdatePacked [Weak or not]
or
| miext/shadow/shrotate.c:shadowUpdateRotatePacked [Weak or not]

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#625521: glibc: causes segfault in Xorg

[Cyril Brulebois]

Michel Dänzer daen...@debian.org (04/05/2011):
 Those are just callback pointers passed to shadowAdd(). The driver
 doesn't call shadowUpdatePacked() directly (in fact you'll note the
 backtrace doesn't have any frames belonging to the driver), but the
 shadow layer is only used as set up by the driver.

Alright. Wasn't sure whether that was a somewhat broken backtrace with
missing stuff, or something else. Thanks for the clarification.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#564008: FTBFS: Applying patch kfreebsd/local-no-SOCK_NONBLOCK.diff fails

[Cyril Brulebois]

Package: eglibc
Version: 2.10.2-4
Severity: serious
Justification: FTBFS

Hi Aurélien et al.,

eglibc unfortunately FTBFS on all non-Linux ports (at least):
| Applying patch kfreebsd/local-no-SOCK_NONBLOCK.diff
| patching file resolv/res_send.c
| Hunk #1 FAILED at 933.
| Hunk #2 succeeded at 927 (offset -18 lines).
| Hunk #3 FAILED at 956.
| Hunk #4 succeeded at 945 (offset -23 lines).
| Hunk #5 succeeded at 973 (offset -23 lines).
| 2 out of 5 hunks FAILED -- rejects in file resolv/res_send.c
| patching file nscd/connections.c
| Restoring resolv/res_send.c
| Restoring nscd/connections.c
| Patch kfreebsd/local-no-SOCK_NONBLOCK.diff does not apply (enforce with -f)
| Restoring resolv/res_send.c
| Restoring nscd/connections.c
| make: *** 
[/build/buildd-eglibc_2.10.2-4-kfreebsd-amd64-o4wcHm/eglibc-2.10.2/stamp-dir/patch]
 Error 1

Build logs at the usual place:
  https://buildd.debian.org/status/package.php?p=eglibcsuite=unstable

Mraw,
KiBi.



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Please test eglibc 2.9-23+multiarch.2

[Cyril Brulebois]

Goswin von Brederlow goswin-...@web.de (03/08/2009):
 Does it break aptitude too?

I think that people involved in serious things like multiarch and glibc
might appreciate your staying quiet at some point given the quite huge
mess you initially created. But maybe that's just me.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#449423: glibc2.7 followup

[Cyril Brulebois]

Stuart Prescott [EMAIL PROTECTED] (06/11/2007):
 I know that you know that -- that comment wasn't for you but for the
 original reporter and […]

Next time, trying putting the submitter in the loop, so that he has a
chance to even get your message.

Cheers,

-- 
Cyril Brulebois


pgpTHdzzwkoWT.pgp
Description: PGP signature