Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?
On Sat, Mar 16, 2019 at 12:29:07PM +0200, Niko Tyni wrote: > > > This will cause temporary uninstallability of libmarc-charset-perl in > > > sid so the uploads should be coordinated a bit. I guess I can do both > > > if needed. > > > > Thanks. > > (If it helps I can also upload libmarc-charset-perl but maybe the > > coordination effort is higher than if you just go ahead :)) > > Yeah, thanks. I'll try to handle this myself. Just uploaded perl_5.28.1-5 and pushed the planned libmarc-charset-perl changes to salsa. Will upload libmarc-charset-perl later when the new perl is built and available on the mirrors. Fine by me if someone else beats me to it. -- Niko
Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?
Control: clone -1 -2 Control: retitle -2 perl: Break libmarc-charset-perl (<< 1.35-3) Control: reassign -2 perl 5.28.1-4 On Wed, Mar 13, 2019 at 10:49:29PM +0100, gregor herrmann wrote: > On Wed, 13 Mar 2019 20:24:59 +0200, Niko Tyni wrote: > > > - have perl_5.28.1-5 Build-Depend on libgdbm-dev (>= 1.18-3) > > [any gdbm version built with LFS support would do, but 1.18-3 > >fixed other binary compat issues so pick that for safety] > > - have perl_5.28.1-5 Break libmarc-charset-perl (<< 1.35-3) > > - have libmarc-charset-perl_1.35-3 Build-Depend and Depend on > > perl (>= perl_5.28.1-5) > > Sounds right. Thanks. Cloning and reassigning. > > This will cause temporary uninstallability of libmarc-charset-perl in > > sid so the uploads should be coordinated a bit. I guess I can do both > > if needed. > > Thanks. > (If it helps I can also upload libmarc-charset-perl but maybe the > coordination effort is higher than if you just go ahead :)) Yeah, thanks. I'll try to handle this myself. -- Niko
Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?
On Wed, 13 Mar 2019 20:24:59 +0200, Niko Tyni wrote: > - have perl_5.28.1-5 Build-Depend on libgdbm-dev (>= 1.18-3) > [any gdbm version built with LFS support would do, but 1.18-3 >fixed other binary compat issues so pick that for safety] > - have perl_5.28.1-5 Break libmarc-charset-perl (<< 1.35-3) > - have libmarc-charset-perl_1.35-3 Build-Depend and Depend on > perl (>= perl_5.28.1-5) Sounds right. > We could limit the above to just 32-bit architectures, but IIRC those > would need to be listed one by one and it's probably not worth the > trouble. *nod* > This will cause temporary uninstallability of libmarc-charset-perl in > sid so the uploads should be coordinated a bit. I guess I can do both > if needed. Thanks. (If it helps I can also upload libmarc-charset-perl but maybe the coordination effort is higher than if you just go ahead :)) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Kings of Convenience: Know How signature.asc Description: Digital Signature
Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?
On Wed, Feb 27, 2019 at 09:20:25PM +0200, Niko Tyni wrote: > On Mon, Feb 25, 2019 at 11:31:14AM +0100, Gianfranco Costamagna wrote: > > Package: libmarc-charset-perl > > Version: 1.35-2 > > Severity: serious > > > > Hello, for some reasons the package testsuite started to fail in Ubuntu for > > this package and xml-perl reverse-dependency, > > only on armhf and i386. > > This happened when the new gdbm has been uploaded and rebuilds issued. > > > > I traced down the problem to some differences in the march8/utf8 Table > > generation, I don't know how serious it is, but the > > testsuite seems completely broken on armhf and i386 at least, and utf8 cjk > > conversion seems to return wrong values. > > This is the reason for me opening this bug as "serious". > > Thanks for noticing this. I've confirmed that this happens on at least > Debian sid/i386 too. It's a bit unfortunate that we only have autopkgtest > checks on amd64, so this wasn't spotted earlier. > > > after a no-change rebuild of the package, and installing it, the test goes > > passing ok: This was discussed in #923609, and src:gdbm will not restore backward binary compatibility. The incompatibility is due to building with LFS support in the newer versions. The gdbmtool package now includes separate -nolfs binaries compatible with old databases, so that they can be converted to a compatible binary format. This means that libmarc-charset-perl indeed needs to be rebuilt. However, a simple binNMU does not do anything to prevent broken combinations of libmarc-charset-perl and perl in partial upgrades. I suggest the following steps to fix this: - have perl_5.28.1-5 Build-Depend on libgdbm-dev (>= 1.18-3) [any gdbm version built with LFS support would do, but 1.18-3 fixed other binary compat issues so pick that for safety] - have perl_5.28.1-5 Break libmarc-charset-perl (<< 1.35-3) - have libmarc-charset-perl_1.35-3 Build-Depend and Depend on perl (>= perl_5.28.1-5) We could limit the above to just 32-bit architectures, but IIRC those would need to be listed one by one and it's probably not worth the trouble. This will cause temporary uninstallability of libmarc-charset-perl in sid so the uploads should be coordinated a bit. I guess I can do both if needed. Will clone a separate bug against perl soon but would appreciate some eyeballs first. -- Niko
Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?
` [2019-02-28 18:01] Niko Tyni > > > But ideally gdbm would restore compatibility and libmarc-charset-perl > > > would > > > not need any changes. > > > > I believe upstream release 1.8.1 introduced change, that > > made it possible to read old /usr/lib/libmarc-charset-perl/Table. Am I > > missing something in current situation? > > I thought so too, but this new bug highlights the fact that the fix > does not work on all architectures. This was missed earlier because > Debian does not have autopkgtest checks on !amd64, so we're relying > on user bug reports and haven't got any so far. > > I've now verified that creating GDBM files with Perl, Python 2 or Python 3 > on stretch i386 and then upgrading to buster renders the old databases > unusable with the corresponding software in buster. > > I can file a separate bug against src:gdbm if that makes things clearer. Yes, it would help. Please include as much details, as possible, including database created on stretch-i386. It would speed-up communication with upstream. > > By the way, I disagree about compability. If all we need to make > > everything good is just a binNMU, I'd rather not introduce any > > patches/hacks/compatibility layers/etc. > > binNMU'ing libmarc-charset-perl will only fix libmarc-charset-perl, > not unpackaged local user databases. If those become unusable on > stretch -> buster upgrades with no way to recover them, that seems > like a major problem. > > binNMU'ing libmarc-charset-perl does not fix partial upgrades where > perl that uses a newer libgdbm is upgraded before libmarc-charset-perl. > Hence the need for Breaks and versioned build dependencies that I listed. Ah, I see. Yes, breaking user databases would not be nice. > > By the way, it is sad that libmarc-charset-perl uses gdbm, not cdb. > Are you referring to https://cr.yp.to/cdb.html ? I see there's a CDB_File > Perl module in libcdb-file-perl but I'm not familiar with it. Seems worth > a wishlist bug. Among advantages of cdb is that it has well-specified format on disk. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?
On Thu, Feb 28, 2019 at 12:06:18PM +, Dmitry Bogatov wrote: > > [2019-02-27 21:20] Niko Tyni > > > - update perl to build-depend on libgdbm-dev (>= 1.18-2) and Break > > > older versions of libmarc-charset-perl (and any other perl packages > > > bundling GDBM or NDBM databases) > > > > > > - update libmarc-charset-perl (and any other perl packages bundling > > > GDBM or NDBM databases) to build-depend and depend on the newer perl > > > > > > I assume other language bindings like python-gdbm will need something > > > similar. > > > > But ideally gdbm would restore compatibility and libmarc-charset-perl would > > not need any changes. > > I believe upstream release 1.8.1 introduced change, that > made it possible to read old /usr/lib/libmarc-charset-perl/Table. Am I > missing something in current situation? I thought so too, but this new bug highlights the fact that the fix does not work on all architectures. This was missed earlier because Debian does not have autopkgtest checks on !amd64, so we're relying on user bug reports and haven't got any so far. I've now verified that creating GDBM files with Perl, Python 2 or Python 3 on stretch i386 and then upgrading to buster renders the old databases unusable with the corresponding software in buster. I can file a separate bug against src:gdbm if that makes things clearer. > By the way, I disagree about compability. If all we need to make > everything good is just a binNMU, I'd rather not introduce any > patches/hacks/compatibility layers/etc. binNMU'ing libmarc-charset-perl will only fix libmarc-charset-perl, not unpackaged local user databases. If those become unusable on stretch -> buster upgrades with no way to recover them, that seems like a major problem. binNMU'ing libmarc-charset-perl does not fix partial upgrades where perl that uses a newer libgdbm is upgraded before libmarc-charset-perl. Hence the need for Breaks and versioned build dependencies that I listed. > By the way, it is sad that libmarc-charset-perl uses gdbm, not cdb. Are you referring to https://cr.yp.to/cdb.html ? I see there's a CDB_File Perl module in libcdb-file-perl but I'm not familiar with it. Seems worth a wishlist bug. -- Niko Tyni nt...@debian.org
Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?
[2019-02-27 21:20] Niko Tyni > > - update perl to build-depend on libgdbm-dev (>= 1.18-2) and Break > > older versions of libmarc-charset-perl (and any other perl packages > > bundling GDBM or NDBM databases) > > > > - update libmarc-charset-perl (and any other perl packages bundling > > GDBM or NDBM databases) to build-depend and depend on the newer perl > > > > I assume other language bindings like python-gdbm will need something > > similar. > > But ideally gdbm would restore compatibility and libmarc-charset-perl would > not need any changes. I believe upstream release 1.8.1 introduced change, that made it possible to read old /usr/lib/libmarc-charset-perl/Table. Am I missing something in current situation? By the way, I disagree about compability. If all we need to make everything good is just a binNMU, I'd rather not introduce any patches/hacks/compatibility layers/etc. By the way, it is sad that libmarc-charset-perl uses gdbm, not cdb. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?
On Mon, Feb 25, 2019 at 11:31:14AM +0100, Gianfranco Costamagna wrote: > Package: libmarc-charset-perl > Version: 1.35-2 > Severity: serious > > Hello, for some reasons the package testsuite started to fail in Ubuntu for > this package and xml-perl reverse-dependency, > only on armhf and i386. > This happened when the new gdbm has been uploaded and rebuilds issued. > > I traced down the problem to some differences in the march8/utf8 Table > generation, I don't know how serious it is, but the > testsuite seems completely broken on armhf and i386 at least, and utf8 cjk > conversion seems to return wrong values. > This is the reason for me opening this bug as "serious". Thanks for noticing this. I've confirmed that this happens on at least Debian sid/i386 too. It's a bit unfortunate that we only have autopkgtest checks on amd64, so this wasn't spotted earlier. > after a no-change rebuild of the package, and installing it, the test goes > passing ok: Looks like src:gdbm has broken compatibility with old databases, much like #910911. I haven't extracted the details so not reassigning yet, but copying Dmitry as a heads-up. As I argued in #910911, the big issue with such a backcompat break is that user databases become unusable, and libmarc-charset-perl breakage is just a small detail that could be properly solved with the recipe in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910911#63 : > - update perl to build-depend on libgdbm-dev (>= 1.18-2) and Break > older versions of libmarc-charset-perl (and any other perl packages > bundling GDBM or NDBM databases) > > - update libmarc-charset-perl (and any other perl packages bundling > GDBM or NDBM databases) to build-depend and depend on the newer perl > > I assume other language bindings like python-gdbm will need something > similar. But ideally gdbm would restore compatibility and libmarc-charset-perl would not need any changes. -- Niko Tyni nt...@debian.org
Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?
Package: libmarc-charset-perl Version: 1.35-2 Severity: serious Hello, for some reasons the package testsuite started to fail in Ubuntu for this package and xml-perl reverse-dependency, only on armhf and i386. This happened when the new gdbm has been uploaded and rebuilds issued. I traced down the problem to some differences in the march8/utf8 Table generation, I don't know how serious it is, but the testsuite seems completely broken on armhf and i386 at least, and utf8 cjk conversion seems to return wrong values. This is the reason for me opening this bug as "serious". you can see the reports here https://autopkgtest.ubuntu.com/packages/libmarc-xml-perl and https://autopkgtest.ubuntu.com/packages/libmarc-charset-perl perl t/cjk.t 1..1 no mapping found for [0x61] at position 0 in a $1!u`!** z g0=ASCII_DEFAULT g1=EXTENDED_LATIN at /usr/share/perl5/MARC/Charset.pm line 308. not ok 1 - cjk # Failed test 'cjk' # at t/cjk.t line 17. Wide character in print at /usr/share/perl/5.28/Test2/Formatter/TAP.pm line 113. # got: 'a 埇 z' # expected: undef # Looks like you failed 1 test of 1. after a no-change rebuild of the package, and installing it, the test goes passing ok: perl t/cjk.t 1..1 ok 1 - cjk I'm not sure if a no-change rebuild fixes also libmarc-xml-perl and fixes all the test failures, this is something I'm checking right now (but I suppose it will) G.
