On 2023-08-28 21:56, Aurelien Jarno wrote: > Hi Niko, > > On 2023-08-27 14:43, Niko Tyni wrote: > > (full quote for the benefit of the Aurelien and other glibc maintainers) > > > > On Sat, Aug 26, 2023 at 09:07:38PM +0300, Niko Tyni wrote: > > > Package: perl > > > Version: 5.36.0-8 > > > Severity: serious > > > X-Debbugs-Cc: debian-powe...@lists.debian.org > > > Control: affects -1 libfile-fcntllock-perl > > > > > > Hi, > > > > > > debugging an unexpected autopkgtest failure of > > > libfile-fcntllock-perl_0.22-4+b1 with perl_5.36.0-8 on ppc64el [1] I found > > > it's because the old perl binary (5.36.0-7) was built with the fcntl(2) > > > constant F_GETLK == 12, but the new one with F_GETLK == 5 [2]. > > > > > > There are no source or build system changes in perl that would have caused > > > this change. The failure is currently blocking perl testing migration, > > > so filing at 'serious'. > > > > > > Perl is built with -D_FILE_OFFSET_BITS=64, and I see that on bullseye > > > this causes F_GETLK == F_GETLK64 == 12, but on bookworm and later > > > F_GETLK == 5 while F_GETLK64 == 12 [3]. I didn't find the exact > > > change that caused this yet. > > > > > > As can be expected from the above, building libfile-fcntllock-perl on > > > bookworm against perl_5.36.0-7 makes it fail its test suite in a similar > > > way. And rebuilding it on sid against perl_5.36.0-8 makes it pass. > > > > > > On amd64 the constants have stayed equal (== 5) from bullseye to sid, > > > and _FILE_OFFSET_BITS=64 doesn't affect them. What's the deal on ppc64el? > > > > > > Copying the powerpc porters list. Could you please look into this? > > > > > > [1] > > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/libf/libfile-fcntllock-perl/34669085/log.gz > > > [2] perl -MPOSIX -E 'say F_GETLK' > > > [3] printf '#include <fcntl.h>\nF_GETLK\nF_GETLK64\n' | cpp > > > -D_FILE_OFFSET_BITS=64 | tail -2 > > Thanks for the details and the investigation. > > > I think the relevant change here is this in libc6-dev_2.36-9+deb12u1 for > > bookworm: > > > > --- libc6-dev_2.36-9/usr/include/powerpc64le-linux-gnu/bits/fcntl.h > > 2023-04-10 09:35:16.000000000 +0100 > > +++ libc6-dev_2.36-9+deb12u1/usr/include/powerpc64le-linux-gnu/bits/fcntl.h > > 2023-07-13 19:07:47.000000000 +0100 > > @@ -33,6 +33,12 @@ > > # define __O_LARGEFILE 0200000 > > #endif > > > > +#if __WORDSIZE == 64 > > +# define F_GETLK 5 > > +# define F_SETLK 6 > > +# define F_SETLKW 7 > > +#endif > > + > > Indeed you are correct that the issue has been introduced by this patch. > It fixes the case *without* -D_FILE_OFFSET_BITS=64, but OTOH breaks the > case *with* it. > > > and a similar one in 2.37-2 for trixie/sid. > > > > The applicable changelog entry is presumably > > > > [ Aurelien Jarno ] > > * debian/patches/git-updates.diff: update from upstream stable branch: > > [...] > > - Not affecting bookworm release architectures: > > - Fix LFS POSIX lock constants for powerpc64. > > > > Aurelien, it seems that there's an oversight as ppc64el is a release > > architecture? > > Yes, sorry about that. When reading the changelog and the diff, I > thought it was only for powerpc64, as ppc64el has a different ABI, but I > was wrong. > > > I can see that this changed for the better, but what should I do with the > > above > > breakage? Rebuild perl and libfcntl-fcntllock-perl and declare some Breaks? > > Do we want to do that for stable too? > > I think it's an ABI breakage that should be fixed, but just reverting > the patch will break the case without -D_FILE_OFFSET_BITS=64. I'll check > with upstream and try to get the issue fixed in both testing/sid and > stable. I'll keep you updated. In the meantime feel free to reassign the > bug to the glibc.
I have opened a bug upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=30804 And submitted a possible patch: https://sourceware.org/pipermail/libc-alpha/2023-August/151199.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
