Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 14/07/14 23:17, Niko Tyni wrote: I've just uploaded perl_5.18.2-7 providing only perlapi-5.18.2d on s390x and closing this bug (#753444). FWIW, this had some trouble migrating because there were a few packages that were still depending on perlapi-5.18.2 on testing, and the rebuilds were not migrating for one reason or another. These are the packages I had to remove: remove libsereal-encoder-perl/2.04-1 libsereal-decoder-perl/2.12-3 libsession-storage-secure-perl/0.010-1 libdancer-session-cookie-perl/0.22-1 libimager-perl/0.98+dfsg-2 libimager-qrcode-perl/0.033-1.2 libmojomojo-perl/1.10+dfsg1-3 libxml-saxon-xslt2-perl/0.007-3 libinline-java-perl/0.53-1 remove inn/1:1.7.2q-41 uucpsend/1.1-4 remove pilot-manager/1.107.0pre108-5 syncbbdb/2.6-2 As you can see, most of those are perl modules that had no (non-perl-modules) rdeps in the archive. They can get back when they are fixed. inn has been fixed already, so it and uucpsend should get back in very soon. pilot-manager and syncbbdb are RC-buggy, as they depend on libpda-pilot-perl which is gone. Thanks to gregor who fixed libio-interface-perl, preventing me from removing a few more packages. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 14/07/14 23:17, Niko Tyni wrote:
On Mon, Jul 14, 2014 at 09:34:35AM +0200, Emilio Pozuelo Monfort wrote:
On 14/07/14 09:05, Niko Tyni wrote:
So can I go ahead with dropping perlapi-5.18.2 or do we need to dig in
the libimager-perl/libpng problem first?
If you're ok with removing libimager-perl, libimager-qrcode-perl and
libmojomojo-perl from testing if those don't get fixed in time, then yes.
As for sereal, we'd need to remove libsereal-{en,de}coder-perl,
libsession-storage-secure-perl and libdancer-session-cookie-perl.
The libimager-perl/libpng thing looks thorny enough that I don't
think we should wait for that. The libsereal-encoder-perl package
has been failing on s390x for a long time, if it has to be removed
then so be it.
I've just uploaded perl_5.18.2-7 providing only perlapi-5.18.2d on s390x
and closing this bug (#753444).
Sounds good, thanks for your work!
Emilio
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sun, Jul 13, 2014 at 01:27:37PM +0200, Emilio Pozuelo Monfort wrote: On 13/07/14 13:04, Julien Cristau wrote: On Sat, Jul 5, 2014 at 11:45:16 +0200, Emilio Pozuelo Monfort wrote: I have thought a bit more about this. I was hesitant as there are lots of packages involved, but thinking more about it, this should be pretty smooth. You add perlapi-5.18.2d to perl-base's Provides, but you won't remove perlapi-5.18.1 or perlapi-5.18.2. Then perl-base can migrate immediately, and all the rebuilds can migrate as well. Then after the rebuilds are done, you can remove perlapi-5.18.1 and perlapi-5.18.2 from Provides. perl 5.18.2-6 is now in jessie, so AFAICT it should be fine to drop the old Provides on s390x at this point. Yes, but the seven packages that haven't been rebuilt will be a problem, unless we can drop them from testing. So fixing those or checking if they can be dropped will be good. libapache2-mod-perl2 is OK in sid now, and we have a fix for xacobeo. So can I go ahead with dropping perlapi-5.18.2 or do we need to dig in the libimager-perl/libpng problem first? -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 14/07/14 09:05, Niko Tyni wrote:
On Sun, Jul 13, 2014 at 01:27:37PM +0200, Emilio Pozuelo Monfort wrote:
On 13/07/14 13:04, Julien Cristau wrote:
On Sat, Jul 5, 2014 at 11:45:16 +0200, Emilio Pozuelo Monfort wrote:
I have thought a bit more about this. I was hesitant as there are lots of
packages involved, but thinking more about it, this should be pretty
smooth. You
add perlapi-5.18.2d to perl-base's Provides, but you won't remove
perlapi-5.18.1
or perlapi-5.18.2. Then perl-base can migrate immediately, and all the
rebuilds
can migrate as well. Then after the rebuilds are done, you can remove
perlapi-5.18.1 and perlapi-5.18.2 from Provides.
perl 5.18.2-6 is now in jessie, so AFAICT it should be fine to drop the
old Provides on s390x at this point.
Yes, but the seven packages that haven't been rebuilt will be a problem,
unless
we can drop them from testing. So fixing those or checking if they can be
dropped will be good.
libapache2-mod-perl2 is OK in sid now, and we have a fix for xacobeo.
So can I go ahead with dropping perlapi-5.18.2 or do we need to dig in
the libimager-perl/libpng problem first?
If you're ok with removing libimager-perl, libimager-qrcode-perl and
libmojomojo-perl from testing if those don't get fixed in time, then yes.
As for sereal, we'd need to remove libsereal-{en,de}coder-perl,
libsession-storage-secure-perl and libdancer-session-cookie-perl.
Emilio
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 13/07/14 20:12, Aurelien Jarno wrote: On Sun, Jul 13, 2014 at 03:19:51PM +0200, gregor herrmann wrote: - libsereal-* FTBFS on various architectures and are perfect removal candidates from testing (#742409 and #750770). hm, except that libsession-storage-secure-perl depends on them, which is depended upon by libdancer-session-cookie-perl. hm. This one is missing support for big-endian architectures. These got uploaded with fixes. libsereal-decoder-perl built fine, but libsereal-encoder-perl (built against the new libsereal-decoder-perl) failed. Emilio -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Mon, 14 Jul 2014 21:40:42 +0200, Emilio Pozuelo Monfort wrote: On 13/07/14 20:12, Aurelien Jarno wrote: On Sun, Jul 13, 2014 at 03:19:51PM +0200, gregor herrmann wrote: - libsereal-* FTBFS on various architectures and are perfect removal candidates from testing (#742409 and #750770). hm, except that libsession-storage-secure-perl depends on them, which is depended upon by libdancer-session-cookie-perl. hm. This one is missing support for big-endian architectures. These got uploaded with fixes. libsereal-decoder-perl built fine, but libsereal-encoder-perl (built against the new libsereal-decoder-perl) failed. Right, too bad ... It almost builds everywhere, only sparc and s390x fail. I'm going to update https://github.com/Sereal/Sereal/issues/47 with these new results once all build logs are in (or before I go to bed, whatever happens first). Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Rolling Stones signature.asc Description: Digital Signature
Bug#753444: Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Mon, Jul 14, 2014 at 09:34:35AM +0200, Emilio Pozuelo Monfort wrote:
On 14/07/14 09:05, Niko Tyni wrote:
So can I go ahead with dropping perlapi-5.18.2 or do we need to dig in
the libimager-perl/libpng problem first?
If you're ok with removing libimager-perl, libimager-qrcode-perl and
libmojomojo-perl from testing if those don't get fixed in time, then yes.
As for sereal, we'd need to remove libsereal-{en,de}coder-perl,
libsession-storage-secure-perl and libdancer-session-cookie-perl.
The libimager-perl/libpng thing looks thorny enough that I don't
think we should wait for that. The libsereal-encoder-perl package
has been failing on s390x for a long time, if it has to be removed
then so be it.
I've just uploaded perl_5.18.2-7 providing only perlapi-5.18.2d on s390x
and closing this bug (#753444).
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sat, Jul 5, 2014 at 11:45:16 +0200, Emilio Pozuelo Monfort wrote: I have thought a bit more about this. I was hesitant as there are lots of packages involved, but thinking more about it, this should be pretty smooth. You add perlapi-5.18.2d to perl-base's Provides, but you won't remove perlapi-5.18.1 or perlapi-5.18.2. Then perl-base can migrate immediately, and all the rebuilds can migrate as well. Then after the rebuilds are done, you can remove perlapi-5.18.1 and perlapi-5.18.2 from Provides. perl 5.18.2-6 is now in jessie, so AFAICT it should be fine to drop the old Provides on s390x at this point. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 13/07/14 13:04, Julien Cristau wrote: On Sat, Jul 5, 2014 at 11:45:16 +0200, Emilio Pozuelo Monfort wrote: I have thought a bit more about this. I was hesitant as there are lots of packages involved, but thinking more about it, this should be pretty smooth. You add perlapi-5.18.2d to perl-base's Provides, but you won't remove perlapi-5.18.1 or perlapi-5.18.2. Then perl-base can migrate immediately, and all the rebuilds can migrate as well. Then after the rebuilds are done, you can remove perlapi-5.18.1 and perlapi-5.18.2 from Provides. perl 5.18.2-6 is now in jessie, so AFAICT it should be fine to drop the old Provides on s390x at this point. Yes, but the seven packages that haven't been rebuilt will be a problem, unless we can drop them from testing. So fixing those or checking if they can be dropped will be good. Emilio -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sun, 13 Jul 2014 13:27:37 +0200, Emilio Pozuelo Monfort wrote: perl 5.18.2-6 is now in jessie, so AFAICT it should be fine to drop the old Provides on s390x at this point. Yes, but the seven packages that haven't been rebuilt will be a problem, unless we can drop them from testing. So fixing those or checking if they can be dropped will be good. Quick overview: - libapache2-mod-perl2 FTBFS everywhere (#754308), the workaround is to build with gcc-4.8. Already prepared in git. - libapache-authenhook-perl looks similar ... builds fine locally, so this is probably mod_perl failing which should be rebuilt _before_ (not sure why this is in stage 1 and mod_perl in stage 2 on the transition page) - libsereal-* FTBFS on various architectures and are perfect removal candidates from testing (#742409 and #750770). hm, except that libsession-storage-secure-perl depends on them, which is depended upon by libdancer-session-cookie-perl. hm. - libimager-perl: no idea but not new: #754125 upstream is involved - libimager-qrcode-perl: probably fallout from libimager-perl - pcp: fails everywhere: https://buildd.debian.org/status/package.php?p=pcp and #752171, fix apparently trivial I'm going to upload libapache2-mod-perl2 and the pcp NMU now. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Pink Floyd: Speak To Me / Breathe signature.asc Description: Digital Signature
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sun, Jul 13, 2014 at 03:19:51PM +0200, gregor herrmann wrote: On Sun, 13 Jul 2014 13:27:37 +0200, Emilio Pozuelo Monfort wrote: perl 5.18.2-6 is now in jessie, so AFAICT it should be fine to drop the old Provides on s390x at this point. Yes, but the seven packages that haven't been rebuilt will be a problem, unless we can drop them from testing. So fixing those or checking if they can be dropped will be good. Quick overview: - libapache2-mod-perl2 FTBFS everywhere (#754308), the workaround is to build with gcc-4.8. Already prepared in git. Thanks, it built successfully. - libapache-authenhook-perl looks similar ... builds fine locally, so this is probably mod_perl failing which should be rebuilt _before_ (not sure why this is in stage 1 and mod_perl in stage 2 on the transition page) Rebuilding against the new libapache2-mod-perl2 worked. - libsereal-* FTBFS on various architectures and are perfect removal candidates from testing (#742409 and #750770). hm, except that libsession-storage-secure-perl depends on them, which is depended upon by libdancer-session-cookie-perl. hm. This one is missing support for big-endian architectures. - libimager-perl: no idea but not new: #754125 upstream is involved A quick debugging seems to show the problem is on the libpng side. Rebuilding it makes the problem disappear. It looks like it is due to the same issue we are doing this transition, ie the libpng structure expose a jmp_buf structure. I don't really now what to do... - libimager-qrcode-perl: probably fallout from libimager-perl Indeed, I wouldn't be surprised they are related. - pcp: fails everywhere: https://buildd.debian.org/status/package.php?p=pcp and #752171, fix apparently trivial It build successfully, thanks. Cheers, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 07/07/14 10:49, Emilio Pozuelo Monfort wrote: On 07/07/14 09:31, Aurelien Jarno wrote: On Sat, Jul 05, 2014 at 07:15:56PM +0200, Emilio Pozuelo Monfort wrote: That said, feel free to upload perl now. It has been uploaded, and is now installed on all s390x buildds. Thanks. I have scheduled a bunch of binNMUs. I scheduled all of them, and there are a few failures: https://release.debian.org/transitions/html/perlapi-5.18.2d-s390x.html However the main blocker right now is the perl/mips FTBFS. Emilio -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Tue, Jul 08, 2014 at 09:43:14AM +0200, Emilio Pozuelo Monfort wrote: https://release.debian.org/transitions/html/perlapi-5.18.2d-s390x.html However the main blocker right now is the perl/mips FTBFS. For the record, I'm aware of this but it's currently difficult to find the time. The quick fix is probably to build with gcc-4.8 on mips or something like that. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sat, Jul 05, 2014 at 07:15:56PM +0200, Emilio Pozuelo Monfort wrote: That said, feel free to upload perl now. It has been uploaded, and is now installed on all s390x buildds. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 07/07/14 09:31, Aurelien Jarno wrote: On Sat, Jul 05, 2014 at 07:15:56PM +0200, Emilio Pozuelo Monfort wrote: That said, feel free to upload perl now. It has been uploaded, and is now installed on all s390x buildds. Thanks. I have scheduled a bunch of binNMUs. Emilio -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sat, Jul 05, 2014 at 02:27:02AM +0200, Emilio Pozuelo Monfort wrote: On 03/07/14 19:50, Aurelien Jarno wrote: On Thu, Jul 03, 2014 at 07:43:57PM +0300, Niko Tyni wrote: I could make a sourceful perl upload incrementing perlapi-5.18.2 to for instance perlapi-5.18.2d (and removing perlapi-5.18.1) on s390x only. This would make ~500 reverse dependencies of perlapi-5.18.* uninstallable and require a new binNMU round for them. As libperl5.18 has a tight dependency on perl-base, I don't think we'd need to do anything on the libperl side. I think this would work fine. From the buildds point of view, the 500 binNMUs should not pose any problem, we have enough build power there. I think this would be the right way fix this, but I suppose it would affect ongoing transitions and the like. I'm cc'ing the release team for advice. I have come up with: https://release.debian.org/transitions/html/perlapi-5.18.2d-s390x.html Although I would prefer to wait a bit and do 5.20 directly, I'm not affected by this breakage as I don't have any s390x machines. So if you think this is important enough, we could go ahead and do it now. The only conflict I see right now is gdal with the poppler transition, but that one should be finished in two or three days if everything goes well. Thanks. I don't use s390x either, but clearly there are people who do, and broken upgrades for a few weeks don't seem acceptable to me. So do I wait until poppler is done? Please ping me when it's OK to upload. What do we do with packages that fail to build? Remove the old s390x binaries from testing? The source packages are going to cause trouble for the 5.20 transition too, of course... -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 05/07/14 08:48, Niko Tyni wrote: On Sat, Jul 05, 2014 at 02:27:02AM +0200, Emilio Pozuelo Monfort wrote: Although I would prefer to wait a bit and do 5.20 directly, I'm not affected by this breakage as I don't have any s390x machines. So if you think this is important enough, we could go ahead and do it now. The only conflict I see right now is gdal with the poppler transition, but that one should be finished in two or three days if everything goes well. Thanks. I don't use s390x either, but clearly there are people who do, and broken upgrades for a few weeks don't seem acceptable to me. So do I wait until poppler is done? Please ping me when it's OK to upload. I have thought a bit more about this. I was hesitant as there are lots of packages involved, but thinking more about it, this should be pretty smooth. You add perlapi-5.18.2d to perl-base's Provides, but you won't remove perlapi-5.18.1 or perlapi-5.18.2. Then perl-base can migrate immediately, and all the rebuilds can migrate as well. Then after the rebuilds are done, you can remove perlapi-5.18.1 and perlapi-5.18.2 from Provides. What do we do with packages that fail to build? Remove the old s390x binaries from testing? The source packages are going to cause trouble for the 5.20 transition too, of course... For leaf packages, we could possibly remove them. But why not just fix them wherever possible? Do you expect many FTBFS? Emilio -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sat, Jul 05, 2014 at 11:45:16AM +0200, Emilio Pozuelo Monfort wrote: On 05/07/14 08:48, Niko Tyni wrote: I have thought a bit more about this. I was hesitant as there are lots of packages involved, but thinking more about it, this should be pretty smooth. You add perlapi-5.18.2d to perl-base's Provides, but you won't remove perlapi-5.18.1 or perlapi-5.18.2. Then perl-base can migrate immediately, and all the rebuilds can migrate as well. Then after the rebuilds are done, you can remove perlapi-5.18.1 and perlapi-5.18.2 from Provides. I'm not very enthusiastic about this. It's basically lying: we don't offer the old ABI anymore so we should be straight about it. An uninstallable package seems better than a broken one. But I can see it would help the transition, and it wouldn't cause a regression, it would just make the fix take longer. So yes, I can do that if you want. What do we do with packages that fail to build? Remove the old s390x binaries from testing? The source packages are going to cause trouble for the 5.20 transition too, of course... For leaf packages, we could possibly remove them. But why not just fix them wherever possible? Do you expect many FTBFS? Sure, fixing them is certainly preferrable :) It's just that I've recently rebuilt the same set of packages for the 5.20 transition and ISTR encountering quite a few known long-standing FTBFS bugs. I suppose those packages aren't in testing anymore, though; I didn't look at that part much in my tests. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed (with 2 errors): Re: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
Processing control commands: reassign -1 perl-base,release.debian.org Bug #753444 [perl-base] perl-base - Segfaults in libperl.so.5.18 Bug #753592 [perl-base] interruption code 0x4003B in libperl.so.5.18.2[3fffcfff000+1d] Bug reassigned from package 'perl-base' to 'perl-base,release.debian.org'. Bug reassigned from package 'perl-base' to 'perl-base,release.debian.org'. No longer marked as found in versions perl/5.18.2-4. No longer marked as found in versions perl/5.18.2-4. Ignoring request to alter fixed versions of bug #753444 to the same values previously set Ignoring request to alter fixed versions of bug #753592 to the same values previously set user release.debian@packages.debian.org Unknown command or malformed arguments to command. usertags -1 transition Unknown command or malformed arguments to command. -- 753444: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753444 753592: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753592 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
Control: reassign -1 perl-base,release.debian.org Control: user release.debian@packages.debian.org Control: usertags -1 transition On 05/07/14 18:31, Niko Tyni wrote: On Sat, Jul 05, 2014 at 11:45:16AM +0200, Emilio Pozuelo Monfort wrote: On 05/07/14 08:48, Niko Tyni wrote: I have thought a bit more about this. I was hesitant as there are lots of packages involved, but thinking more about it, this should be pretty smooth. You add perlapi-5.18.2d to perl-base's Provides, but you won't remove perlapi-5.18.1 or perlapi-5.18.2. Then perl-base can migrate immediately, and all the rebuilds can migrate as well. Then after the rebuilds are done, you can remove perlapi-5.18.1 and perlapi-5.18.2 from Provides. I'm not very enthusiastic about this. It's basically lying: we don't offer the old ABI anymore so we should be straight about it. An uninstallable package seems better than a broken one. But I can see it would help the transition, and it wouldn't cause a regression, it would just make the fix take longer. It would make the fix only take longer for people who do partial uploads, right? The users who do a dist-upgrade and get all the updated perl modules that we have binNMUed should be fine, right? And then after things have been rebuilt and any potential FTBFS have been fixed, we drop the old perlapi Provides, and then partial upgrades won't be possible (thus fixing that case as well). The alternative is delaying the migration until everything has been rebuilt and all the FTBFS bugs have been fixed. I think keeping the provides for now is a better option, but I don't know Perl so I may be missing something. If you want to drop them now, that's fine with me. So yes, I can do that if you want. What do we do with packages that fail to build? Remove the old s390x binaries from testing? The source packages are going to cause trouble for the 5.20 transition too, of course... For leaf packages, we could possibly remove them. But why not just fix them wherever possible? Do you expect many FTBFS? Sure, fixing them is certainly preferrable :) It's just that I've recently rebuilt the same set of packages for the 5.20 transition and ISTR encountering quite a few known long-standing FTBFS bugs. I suppose those packages aren't in testing anymore, though; I didn't look at that part much in my tests. I suppose you don't have a list? #735623 could be a problem. #742409 as well. That's not an exhaustive list and I haven't checked if those could be removed from testing (if they are leaf packages). That's why I think a smooth transition (i.e. keeping the provides for now) would be preferable. That said, feel free to upload perl now. Regards, Emilio -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
Processing commands for cont...@bugs.debian.org: forwarded 753444 https://release.debian.org/transitions/html/perlapi-5.18.2d-s390x.html Bug #753444 [perl-base,release.debian.org] perl-base - Segfaults in libperl.so.5.18 Bug #753592 [perl-base,release.debian.org] interruption code 0x4003B in libperl.so.5.18.2[3fffcfff000+1d] Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/perlapi-5.18.2d-s390x.html'. Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/perlapi-5.18.2d-s390x.html'. thanks Stopping processing here. Please contact me if you need assistance. -- 753444: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753444 753592: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753592 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed (with 2 errors): Re: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
Processing control commands: reassign -1 perl-base,release.debian.org Bug #753542 [libc6] perl-base - Segfaults in libperl.so.5.18 Bug reassigned from package 'libc6' to 'perl-base,release.debian.org'. No longer marked as found in versions eglibc/2.19-1 and glibc/2.19-4. Ignoring request to alter fixed versions of bug #753542 to the same values previously set user release.debian@packages.debian.org Unknown command or malformed arguments to command. usertags -1 transition Unknown command or malformed arguments to command. -- 753542: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753542 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sat, Jul 05, 2014 at 07:15:56PM +0200, Emilio Pozuelo Monfort wrote:
On 05/07/14 18:31, Niko Tyni wrote:
On Sat, Jul 05, 2014 at 11:45:16AM +0200, Emilio Pozuelo Monfort wrote:
I have thought a bit more about this. I was hesitant as there are lots of
packages involved, but thinking more about it, this should be pretty
smooth. You
add perlapi-5.18.2d to perl-base's Provides, but you won't remove
perlapi-5.18.1
or perlapi-5.18.2. Then perl-base can migrate immediately, and all the
rebuilds
can migrate as well. Then after the rebuilds are done, you can remove
perlapi-5.18.1 and perlapi-5.18.2 from Provides.
I'm not very enthusiastic about this. It's basically lying: we don't offer
the old ABI anymore so we should be straight about it. An uninstallable
package seems better than a broken one.
But I can see it would help the transition, and it wouldn't cause a
regression, it would just make the fix take longer.
It would make the fix only take longer for people who do partial uploads,
right?
The users who do a dist-upgrade and get all the updated perl modules that we
have binNMUed should be fine, right? And then after things have been rebuilt
and
any potential FTBFS have been fixed, we drop the old perlapi Provides, and
then
partial upgrades won't be possible (thus fixing that case as well). The
alternative is delaying the migration until everything has been rebuilt and
all
the FTBFS bugs have been fixed. I think keeping the provides for now is a
better
option, but I don't know Perl so I may be missing something. If you want to
drop
them now, that's fine with me.
Yes, this is mostly about partial upgrades. I assume there are a few
packages in sid that FTBFS and therefore failed the earlier binNMU round,
so they are currently silently broken even for full upgrades. But they
probably aren't in testing.
Also, at least some upgrade paths are currently totally broken because
of debconf failing. But keeping the Provides for a while more shouldn't
make that worse.
I think we're on the same page, let's do it your way.
Sure, fixing them is certainly preferrable :) It's just that I've
recently rebuilt the same set of packages for the 5.20 transition and
ISTR encountering quite a few known long-standing FTBFS bugs. I suppose
those packages aren't in testing anymore, though; I didn't look at that
part much in my tests.
I suppose you don't have a list?
Sorry, no. The only ones I could find in my notes are not in testing
(#733367 in postgres-xc and #750283 in xacobeo). It's possible that
I'm just confusing things with arch-indep packages.
#735623 could be a problem. #742409 as well. That's not an exhaustive list
and I
haven't checked if those could be removed from testing (if they are leaf
packages). That's why I think a smooth transition (i.e. keeping the provides
for
now) would be preferable.
pdl is not in testing. #742409 and #750770 (libsereal-{en,de}coder-perl)
are related and will probably cause problems.
That said, feel free to upload perl now.
Thanks, will do.
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 03/07/14 19:50, Aurelien Jarno wrote: On Thu, Jul 03, 2014 at 07:43:57PM +0300, Niko Tyni wrote: On Thu, Jul 03, 2014 at 08:48:37AM +0200, Aurelien Jarno wrote: On Wed, Jul 02, 2014 at 11:29:58PM +0200, Bastian Blank wrote: The problem is a missmatch between the jmp_buf size in perl vs. modules. Aka the build against glibc 2.19 changed the public ABI of perl. Yes, jmp_buf had to be increased to support new CPUs. This has been done using symbol versioning, but unfortunately it doesn't work when jmp_buf is embedded in a struct like in perl. Upstream consider this as a non-issue and recommend to do the upgrade of all the perl packages in a lockstep. I see. A bit of googling turns up the related https://bugzilla.redhat.com/show_bug.cgi?id=1064271 I note that Carlos O'Donell says there I expect Ruby is going to fail also since it embeds jmp_buf similarly. Has anybody noticed similar issues with Ruby? So far I haven't, but as symbol versioning is used, until we start mixing versions, the problem won't appear. How do we want to fix this so upgrades won't barf in the users face? The problem only concerns the jessie to jessie partial upgrades, dist-upgrades should be fine. wheezy to jessie upgrades are also fine, due to the perl 5.14 to 5.18 transition. If we want to fix that for jessie to jessie, one way is to start the perl 5.20 transition. So all libc6 reverse dependencies have been binNMU'd on s390x for this in early June? It looks like some have a confusing changelog entry. I checked libterm-readline-gnu-perl and libreadonly-xs-perl, which state Rebuild against perl 5.18. I could make a sourceful perl upload incrementing perlapi-5.18.2 to for instance perlapi-5.18.2d (and removing perlapi-5.18.1) on s390x only. This would make ~500 reverse dependencies of perlapi-5.18.* uninstallable and require a new binNMU round for them. As libperl5.18 has a tight dependency on perl-base, I don't think we'd need to do anything on the libperl side. I think this would work fine. From the buildds point of view, the 500 binNMUs should not pose any problem, we have enough build power there. I think this would be the right way fix this, but I suppose it would affect ongoing transitions and the like. I'm cc'ing the release team for advice. I have come up with: https://release.debian.org/transitions/html/perlapi-5.18.2d-s390x.html Although I would prefer to wait a bit and do 5.20 directly, I'm not affected by this breakage as I don't have any s390x machines. So if you think this is important enough, we could go ahead and do it now. The only conflict I see right now is gdal with the poppler transition, but that one should be finished in two or three days if everything goes well. Emilio It'll still take at least a few weeks before we can do a clean perl 5.20 transition. See #753529. -- Niko -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Thu, Jul 03, 2014 at 08:48:37AM +0200, Aurelien Jarno wrote: On Wed, Jul 02, 2014 at 11:29:58PM +0200, Bastian Blank wrote: The problem is a missmatch between the jmp_buf size in perl vs. modules. Aka the build against glibc 2.19 changed the public ABI of perl. Yes, jmp_buf had to be increased to support new CPUs. This has been done using symbol versioning, but unfortunately it doesn't work when jmp_buf is embedded in a struct like in perl. Upstream consider this as a non-issue and recommend to do the upgrade of all the perl packages in a lockstep. I see. A bit of googling turns up the related https://bugzilla.redhat.com/show_bug.cgi?id=1064271 I note that Carlos O'Donell says there I expect Ruby is going to fail also since it embeds jmp_buf similarly. Has anybody noticed similar issues with Ruby? How do we want to fix this so upgrades won't barf in the users face? The problem only concerns the jessie to jessie partial upgrades, dist-upgrades should be fine. wheezy to jessie upgrades are also fine, due to the perl 5.14 to 5.18 transition. If we want to fix that for jessie to jessie, one way is to start the perl 5.20 transition. So all libc6 reverse dependencies have been binNMU'd on s390x for this in early June? It looks like some have a confusing changelog entry. I checked libterm-readline-gnu-perl and libreadonly-xs-perl, which state Rebuild against perl 5.18. I could make a sourceful perl upload incrementing perlapi-5.18.2 to for instance perlapi-5.18.2d (and removing perlapi-5.18.1) on s390x only. This would make ~500 reverse dependencies of perlapi-5.18.* uninstallable and require a new binNMU round for them. As libperl5.18 has a tight dependency on perl-base, I don't think we'd need to do anything on the libperl side. I think this would be the right way fix this, but I suppose it would affect ongoing transitions and the like. I'm cc'ing the release team for advice. It'll still take at least a few weeks before we can do a clean perl 5.20 transition. See #753529. -- Niko -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Thu, Jul 03, 2014 at 07:43:57PM +0300, Niko Tyni wrote: On Thu, Jul 03, 2014 at 08:48:37AM +0200, Aurelien Jarno wrote: On Wed, Jul 02, 2014 at 11:29:58PM +0200, Bastian Blank wrote: The problem is a missmatch between the jmp_buf size in perl vs. modules. Aka the build against glibc 2.19 changed the public ABI of perl. Yes, jmp_buf had to be increased to support new CPUs. This has been done using symbol versioning, but unfortunately it doesn't work when jmp_buf is embedded in a struct like in perl. Upstream consider this as a non-issue and recommend to do the upgrade of all the perl packages in a lockstep. I see. A bit of googling turns up the related https://bugzilla.redhat.com/show_bug.cgi?id=1064271 I note that Carlos O'Donell says there I expect Ruby is going to fail also since it embeds jmp_buf similarly. Has anybody noticed similar issues with Ruby? So far I haven't, but as symbol versioning is used, until we start mixing versions, the problem won't appear. How do we want to fix this so upgrades won't barf in the users face? The problem only concerns the jessie to jessie partial upgrades, dist-upgrades should be fine. wheezy to jessie upgrades are also fine, due to the perl 5.14 to 5.18 transition. If we want to fix that for jessie to jessie, one way is to start the perl 5.20 transition. So all libc6 reverse dependencies have been binNMU'd on s390x for this in early June? It looks like some have a confusing changelog entry. I checked libterm-readline-gnu-perl and libreadonly-xs-perl, which state Rebuild against perl 5.18. I could make a sourceful perl upload incrementing perlapi-5.18.2 to for instance perlapi-5.18.2d (and removing perlapi-5.18.1) on s390x only. This would make ~500 reverse dependencies of perlapi-5.18.* uninstallable and require a new binNMU round for them. As libperl5.18 has a tight dependency on perl-base, I don't think we'd need to do anything on the libperl side. I think this would work fine. From the buildds point of view, the 500 binNMUs should not pose any problem, we have enough build power there. I think this would be the right way fix this, but I suppose it would affect ongoing transitions and the like. I'm cc'ing the release team for advice. It'll still take at least a few weeks before we can do a clean perl 5.20 transition. See #753529. -- Niko -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
