Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
On Sat, Nov 14, 2020 at 03:01:10PM +0100, Marco d'Itri wrote: > On Nov 14, Dominic Hargreaves wrote: > > > This seems to be same as #953562 which was reported in March. > Why do you think that this is the same? The symptoms seem identical, at least. Maybe there is more than one root cause that I'm not aware of - feel free to unmerge if you don't think the new problem is caused by Replaces not working. Thanks Dominic
Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
Control: reassign -1 libcrypt1 Control: forcemerge -1 953562 On Fri, Nov 13, 2020 at 08:48:19PM +0100, Sven Joachim wrote: > On 2020-11-13 18:23 +0100, Niels Thykier wrote: > > > Control: reassign -1 perl-base > > Control: affects -1 upgrade-reports > > Control: severity -1 grave > > > > Hi Perl team, > > > > I have reassigned this bug to perl because perl-base being essential > > must remain functional during an upgrade and AFAICT perl-base fails in > > this case here. > > > > If it is a direct linkage, then you might be needing a Pre-Depends. If > > it is an indirect linkage then I am not sure how to fix it. :-/ > > I don't think perl-base is doing anything wrong here, it already uses > Pre-Depends. AFAICS the problem is that libcrypt.so.1 can temporarily > go missing if libc6 2.31-4 is unpacked before libcrypt1, breaking the > assumption that binaries from essential packages are always usable. > > I don't have a good idea how to fix that, though. :-( Right - perl-base 5.32.0-5 has the following: Pre-Depends: libc6 (>= 2.29), libcrypt1 (>= 1:4.1.0) I don't think we can do anything about this on the perl side, so reassigning to libcrypt. This seems to be same as #953562 which was reported in March.
Re: Bug#875927: perl: SIGUNUSED removal in glibc 2.26 changes PL_sig_name / SIG_SIZE
On Sun, Nov 19, 2017 at 05:01:27PM +0200, Niko Tyni wrote: > On Sun, Nov 19, 2017 at 02:38:40PM +0100, Aurelien Jarno wrote: > > > Now that we have glibc 2.26 in experimental, can I ask about the status > > of this issue? Do we have to add Breaks: against the affected perl > > packages? > > Thanks for the reminder. > > I looked a bit at "fixing" libasync-interrupt-perl, noted that it uses > SIG_SIZE for other things too and decided I don't want to spend my time > on that. > > My plan is to use the attached workaround, which should keep the ABI > regardless of the glibc version. It should probably go to sid soon. > > I don't think Breaks are needed. The issue only happens if the current > perl gets built with the new glibc. Assuming we upload the workaround > to sid before glibc 2.26, I think it should be fine. Hello, Nothing too much to add, but this sounds like a good idea. Thanks for taking care of this! Cheers, Dominic.
Re: Bug#875927: perl: SIGUNUSED removal in glibc 2.26 changes PL_sig_name / SIG_SIZE
On Sun, Oct 22, 2017 at 08:57:59PM +0300, Niko Tyni wrote:
> On Sat, Sep 16, 2017 at 10:27:26AM +0300, Niko Tyni wrote:
> > Package: perl
> > Version: 5.26.0-8
> > Severity: normal
> > X-Debbugs-Cc: d...@debian.org, vor...@debian.org, gl...@packages.debian.org
> >
> > As seen in
> > https://bugs.launchpad.net/ubuntu/+source/libanyevent-perl/+bug/1717367
> > an upstream change in glibc 2.26, presumably
> > https://patchwork.sourceware.org/patch/20800/ causes perl to change its
> > ABI when rebuilt against the new glibc. I'm copying Steve and Matthias
> > who worked on the issue on the Ubuntu side.
> >
> > The problem is that Perl's global array PL_sig_name[] and the SIG_SIZE
> > constant ($Config{sig_name}, $Config{sig_size} on the perl language side)
> > change due to the removal of the (long?) obsolete SIGUNUSED constant in
> > glibc. The Async::Interrupt (libasync-intterupt-perl) XS module compiles
> > in SIG_SIZE and walks PL_sig_name[] at run time based on that. When the
> > array changes on the Perl side, Async::Interrupt does not know that and
> > accesses it out of bounds.
>
> > Looking at codesearch.debian.net, this also concerns (reverse dependencies
> > of) libio-aio-perl, libcoro-perl and libev-perl.
>
> Perl upstream is not going to do anything about this. Their recommendation
> is to hardcode the list of signals when calling Configure. This
> seems somewhat over the top to me. It might be nicer to temporarily
> patch Configure (or from 5.26.1-1 onward rather its sources, mainly
> regen-configure/dist/U/Signal.U) to add SIGUNUSED to the list of signals
> if it's missing.
>
> Alternatively, postprocessing config.sh should work too and is arguably
> cleaner. Ubuntu is currently postprocessing config.h which I'm not
> quite as comfortable about as I think it leaves the relevant %Config
> entries unchanged.
>
> Regardless of the approach taken, I note that the stashed Configure
> results in debian/cross/*/config.sh.static show that SIGUNUSED does not
> exist on all architectures, so adding it unconditionally would be wrong.
> These ones don't seem to have it:
>
> % for f in debian/cross/*/config.sh.static; do grep -q
> '^sig_name_init.*UNUSED' $f || echo $f; done
> debian/cross/alpha/config.sh.static
> debian/cross/hurd-i386/config.sh.static
> debian/cross/kfreebsd-amd64/config.sh.static
> debian/cross/kfreebsd-i386/config.sh.static
> debian/cross/mips64el/config.sh.static
> debian/cross/mips/config.sh.static
> debian/cross/mipsel/config.sh.static
> debian/cross/sparc64/config.sh.static
>
> AFAICS this means we need a hardcoded white- or blacklist of the affected
> architectures somewhere (and renders the issue even more unactionable
> upstream.)
>
> Upstream also suggests that the modules breaking due to this change
> are unnecessarily fragile. They all seem to be using the same code,
> namely an 's_signum()' function in schmorp.h. Quoting Leon Timmermans:
>
> > The patch to the modules would be little more than removing code;
> > they'd just have to use the whichsig (perl 1.0) /whichsig_sv (perl 5.16)
> > API instead of reimplementing it. Alternatively s_signame could check
> > for the end of PL_sig_name by checking for a null-pointer instead of
> > assuming it has SIG_SIZE elements. Unlike the other solutions that will
> > prevent this kind of situation from happening again.
>
> Tony Cook also notes that these s_signum() implementations are buggy in
> any case, as shown with
>
> perl -MAsync::Interrupt -le 'print Async::Interrupt::sig2num("POLL")'
>
> which should give 29 instead of 67 on amd64. The code should look the
> signal number up in PL_sig_num[] instead of assuming the signal number
> is same as the array index.
>
> I'm tempted to just declare that anything relying on these parts of the
> ABI is buggy and get the known affected modules/packages fixed.
This does seem like the correct approach, given that all the alternatives
are going against upstream, and are varying levels of hackiness (and remain
fragile). Am I correct that implementing Tony's suggestion is in itself
a complete fix for the issue?
I'm adding debian-p...@lists.debian.org for wider visibility of this
issue, which might include patching these four packages:
libasync-interrupt-perl, libio-aio-perl, libcoro-perl and libev-perl.
Cheers,
Dominic.
Bug#628493: perl: FTBFS on kfreebsd-i386: t/op/threads failed
clone 628493 -1 -2 reassign -1 perl reassign -2 perl found -1 5.14.2-11 found -2 5.14.2-11 severity -1 important severity -2 wishlist retitle -1 Re-enable kFreeBSD threads test retitle -2 Perl_atfork_reinit change tags -2 +patch thanks On Mon, Jun 11, 2012 at 07:03:57AM +0200, Petr Salinger wrote: Hi! I just bisected on past eglibc versions and this is reproducible for me (segfault 5% of the time) on kfreebsd-i386, up until this version, with which I can't reproduce the problem any more (10,000+ test runs) : eglibc (2.13-22) unstable; urgency=low -- Aurelien Jarno aure...@debian.org Sat, 10 Dec 2011 21:49:03 +0100 The changelog for that version was quite long, but probably these changes are what fixed this: [ Petr Salinger ] * kfreebsd/local-sysdeps.diff: update to revision 3763 (from glibc-bsd). * add kfreebsd/local-use-thr-primitives.diff to use kernel thr* primitives inside linuxthreads. Closes: #639658. Therefore I'm marking this as fixed in that eglibc upload and I'll try to let upstream know. Thanks! IMO, my suggested change (Perl_atfork_reinit) in Message #54 [1] still should be aplied by perl upstream. While it might not be problem for this testcase, the unlocking in forked child is fragile. Petr [1] http://bugs.debian.org//cgi-bin/bugreport.cgi?bug=628493#54 Thanks both. Cloning bugs as appropriate. Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- 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/20120611091234.gf5...@urchin.earth.li
Re: Bug#672152: perl: FTBFS on kfreebsd-*: dist/threads-shared/t/waithires.t failing
On Mon, Jun 04, 2012 at 11:16:24AM +0100, Steven Chamberlain wrote: On 29/05/12 18:00, Dominic Hargreaves wrote: On Sun, May 27, 2012 at 08:00:48PM +0100, Steven Chamberlain wrote: On 27/05/12 17:55, Steven Chamberlain wrote: I just checked to see if Petr's eglibc getosreldate() fix made any difference to the Perl waithires.t test [...] Actually this is fixed (#673711), I just didn't notice the other commit in pkg-glibc SVN. Thanks Petr! Thanks - I'd appreciate a heads-up when the updated package is available for test in sid. Hi Dominic, The new eglibc is installed in sid now. Hopefully that failing test can be re-enabled. (I'm running it now and it looks fixed to me). Thanks, confirmed here too and re-enabled in git. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- 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/20120608211727.gg5...@urchin.earth.li
Re: Bug#672152: perl: FTBFS on kfreebsd-*: dist/threads-shared/t/waithires.t failing
On Sun, May 27, 2012 at 08:00:48PM +0100, Steven Chamberlain wrote: On 27/05/12 17:55, Steven Chamberlain wrote: I just checked to see if Petr's eglibc getosreldate() fix made any difference to the Perl waithires.t test [...] Actually this is fixed (#673711), I just didn't notice the other commit in pkg-glibc SVN. Thanks Petr! Thanks - I'd appreciate a heads-up when the updated package is available for test in sid. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- 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/20120529170022.gc29...@urchin.earth.li
