Hi Helmut

On 2024-06-05 14:21, Helmut Grohne wrote:
> Hi Aurelien,
> 
> On Tue, Jun 04, 2024 at 06:58:00PM +0200, Aurelien Jarno wrote:
> > It would be really great if glibc can migrate before as it fixes an RC
> > bug. That said there are suspicions that it introduced bug #1072521, so
> > it might be worth investigating before it gets pushed into testing.
> > Unfortunately, on my side, I am unable to reproduce the issue.
> 
> I looked and couldn't spot the RC bug you are referring to. The highest
> severity one I could spot is the systemd/debianutils/sbuild where
> telinit kills the build, but that isn't RC. Am I missing something?

Oops, I was convinced that #1071462 was filled with severity serious.
Nevermind.

> I also looked at #1072521 and am fairly certain that it is not a glibc
i> regression. For sure, #1072521 is not trivially reproducible. In fact, I
> am not aware of anyone other than the submitter reproducing it. Beyond
> that, it is very likely that the submitter uses a non-default file
> descriptor soft limit (even though raising it does not reproduce the
> problem).
> 
> In general, I agree with glibc migrating before doing the synced upload
> and that's also what Paul asked for. From my side the urgency here is
> risk management. Doing it later makes it harder for me to provide
> resources to fix fallout and I'm trying to find a good balance.
> Given that both util-linux and glibc need to migrate, deferring to
> Thursday (still leaves time until the Sunday cron) or even Monday looks
> most reasonable to me.

Ok, thanks.

> > Please go ahead with a NMU. I wonder about experimental, do we want to
> > do the changes at the same time, or a bit after? Said otherwise is
> > moving files from /usr to /lib supported?
> 
> I don't want to support such moves in any way. Hence, I think the best
> option would be to simultaneously NMU experimental. dash is affected in
> the same way.

Ok, a simultaneous experimental NMU sounds good.

Note however that people often downgrade glibc when they have suspicions
(like in the fakeroot case above), or even the hard way with dpkg once
their system is broken. Therefore we should at least test that case to
see how much breakage to expect, and also to easily spot patterns where
a system went through a glibc downgrade possibly followed by an upgrade.

But that's not a reason to block the upload.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurel...@aurel32.net                     http://aurel32.net

Reply via email to