Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
On 2023-09-03 17:48, Niko Tyni wrote: > Control: reassign -1 libc6-dev 2.37-2 > Control: found -1 2.36-9+deb12u1 > Control: tag -1 bookworm > > On Mon, Aug 28, 2023 at 11:46:14PM +0200, Aurelien Jarno wrote: > > > > 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 > > Many thanks! I'm reassigning this. Hope I got the versions right. > > Looks like the discussion upstream has quieted down now. I have submitted the v3 of the patch and I am waiting for it to be rebuilt: https://sourceware.org/pipermail/libc-alpha/2023-August/151273.html Unfortunately upstream does not consider it as an ABI breakage on the glibc side, just an API breakage. But it causes an ABI breakage on the perl side. > My understanding is that for sid/trixie we'll just need a binNMU of perl > on ppc64el afterwards. I'll request that once glibc has the fix. I believe so (well probably on all architectures for multiarch sync). > For stable I don't think anything needs to be done on the perl side. > Both perl and libfile-fcntllock-perl were build with the old constants > before the regression. So just fixing glibc should be enough. I agree. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Processed: Re: Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
Processing control commands: > reassign -1 libc6-dev 2.37-2 Bug #1050592 [perl] perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl Bug reassigned from package 'perl' to 'libc6-dev'. No longer marked as found in versions perl/5.36.0-8. Ignoring request to alter fixed versions of bug #1050592 to the same values previously set Bug #1050592 [libc6-dev] perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl Marked as found in versions glibc/2.37-2. > found -1 2.36-9+deb12u1 Bug #1050592 [libc6-dev] perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl Marked as found in versions glibc/2.36-9+deb12u1. > tag -1 bookworm Bug #1050592 [libc6-dev] perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl Added tag(s) bookworm. -- 1050592: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050592 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
Control: reassign -1 libc6-dev 2.37-2 Control: found -1 2.36-9+deb12u1 Control: tag -1 bookworm On Mon, Aug 28, 2023 at 11:46:14PM +0200, Aurelien Jarno wrote: > > 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 Many thanks! I'm reassigning this. Hope I got the versions right. Looks like the discussion upstream has quieted down now. My understanding is that for sid/trixie we'll just need a binNMU of perl on ppc64el afterwards. I'll request that once glibc has the fix. For stable I don't think anything needs to be done on the perl side. Both perl and libfile-fcntllock-perl were build with the old constants before the regression. So just fixing glibc should be enough. -- Niko
Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
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 \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.0 +0100 > > +++ libc6-dev_2.36-9+deb12u1/usr/include/powerpc64le-linux-gnu/bits/fcntl.h > > 2023-07-13 19:07:47.0 +0100 > > @@ -33,6 +33,12 @@ > > # define __O_LARGEFILE 020 > > #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
Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
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 \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.0 +0100 > +++ libc6-dev_2.36-9+deb12u1/usr/include/powerpc64le-linux-gnu/bits/fcntl.h > 2023-07-13 19:07:47.0 +0100 > @@ -33,6 +33,12 @@ > # define __O_LARGEFILE 020 > #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. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
(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 \nF_GETLK\nF_GETLK64\n' | cpp > -D_FILE_OFFSET_BITS=64 | tail -2 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.0 +0100 +++ libc6-dev_2.36-9+deb12u1/usr/include/powerpc64le-linux-gnu/bits/fcntl.h 2023-07-13 19:07:47.0 +0100 @@ -33,6 +33,12 @@ # define __O_LARGEFILE 020 #endif +#if __WORDSIZE == 64 +# define F_GETLK 5 +# define F_SETLK 6 +# define F_SETLKW 7 +#endif + 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? 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? -- Niko Tyni nt...@debian.org
Bug#1050592: perl: F_GETLK / F_GETLK64 confusion on ppc64el breaking libfile-fcntllock-perl
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 \nF_GETLK\nF_GETLK64\n' | cpp -D_FILE_OFFSET_BITS=64 | tail -2 -- Niko Tyni nt...@debian.org
