Bug#871562: perl-base: Perl binary crashes with SIGSEGV when used for SVN access in "git svn" tests
On Wed, Aug 09, 2017 at 11:16:03AM +0200, Alex Riesen wrote: > Package: perl-base > Version: 5.24.1-3+deb9u1 > Severity: normal > when I run the test suite (Git (the VCS, master branch), the perl binary > sometimes crashes in one of its tests. I used the commands below to reproduce > the problem (just let it run, it'll crash eventually): Thanks for the thorough report. For now, I'll just note that there's been somewhat similar bugs in the past on the libsvn-perl (src:subversion) side that git-svn uses, see at least #780246 and #534763. I don't see the SVN bindings in your backtrace so it may be something else, but in that case a test case without SVN in the mix would be good of course. Anyway, I'll see if I can reproduce this when I find the time. > I had to recompile the perl package locally to get the details backtrace: I > failed to find the debug symbols of the perl package here: > deb http://debug.mirrors.debian.org/debian-debug/ stretch-debug main non-free > contrib They are in the perl-debug package in the main archive, mostly for historical reasons. -- Niko Tyni nt...@debian.org
Bug#852931: logwatch cannot parse postfix logs due to regex errors
On Sat, Jan 28, 2017 at 10:56:09AM +0100, Stefan Nobis wrote:
> Package: logwatch
> Version: 7.4.3+git20161207-1
> Severity: important
>
> Since my upgrade from jessie to stretch (a couple of days ago), logwatch
> stopped being able to parse postfix logs. The old jessie version worked
> fine, but with the current stretch system I get the following output
> from logwatch for postfix logs:
>
> - Postfix Begin
>
> Unescaped left brace in regex is deprecated, passed through in regex; marked
> by <-- HERE in m/^... .. ..:..:..[ ]*[^ ]* postfix{ <-- HERE
> ,-int,-ext}/[-a-zA-Z\d]*(\[[0123456789]*\])?:? / at
> /usr/share/logwatch/scripts/shared/onlyservice line 32, line 1.
> Unescaped left brace in regex is deprecated, passed through in regex; marked
> by <-- HERE in m/^... .. ..:..:.. [^ ]* [^ ]*(\[[0123456789]*\])?: \[ID
> [0-9]+ postfix{ <-- HERE ,-int,-ext}/[-a-zA-Z\d]*/ at
> /usr/share/logwatch/scripts/shared/onlyservice line 35, line 1.
>
> -- Postfix End -
Hi, I'm not the logwatch maintainer, just noticed this bug by chance.
Apparently something like 'postfix{,-int,-ext}' ends up in the
$ServiceName argument to the script, and this is interpolated into the
regular expression as-is. I doubt this ever worked; it looks like shell
syntax for listing three strings, but {N,M} has a totally different meaning
in regexps. So the warning seems appropriate and highlights a real issue.
I suggest logwatch insert \Q...\E quoting (see perlre(1)) to the
$ServiceName interpolation to fix these warnings (which are fatal in
Perl 5.26 btw), but whatever is passing the 'postfix{,-int,-ext}' parts
(probably local configuration?) may well need fixing too.
Hope this helps a bit,
--
Niko Tyni nt...@debian.org
Bug#735134: perl: rename(1) is ancient
Update: here's a related IRC discussion from today prompted by #870472. Apologies for the lack of wrapping. 21:52 < ntyni> Dom: did you see #870472 ? can't recall if dropping prename was intentional or not 21:52 -zwiebelbot:#debian-perl- Debian#870472: rename: Please provide 'prename' as well as 'rename' - https://bugs.debian.org/870472 21:53 < ntyni> seems like a problem if we want to drop the src:perl version for buster 22:43 < Dom> hmm, seems I need to revive my old memories for this one 22:48 < Dom> isn't the problem there that the alternatives have gone wrong? 22:49 < Dom> huh, no 22:49 < Dom> there is no alternative for prename 22:49 < Dom> this is all wrong 22:49 < ntyni> right, I think we forgot about it 22:50 * Dom reads https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735134 22:50 -zwiebelbot:#debian-perl- Debian#735134: perl: rename(1) is ancient - https://bugs.debian.org/735134 22:53 < Dom> prename must have been issuing that warning for ages, right? 22:54 < Dom> "Additionally, if you are currently using 'prename', please 22:54 < Dom> use 'rename' (which is handled by the alternatives mechanism) or 22:54 < Dom> file-rename, which is the new implementation." 22:54 < ntyni> 5.24.1~rc3-1 I guess 22:54 < Dom> that is what was sent to maintainres 22:54 < Dom> so I think the current situation is correct, and the new bugreporter must be misrembering the advice to start using prename 22:54 < Dom> (or that advice was much older advice) 22:55 < ntyni> I suspect the latter 22:56 < Dom> We could turn prename into an alternative too, it's just work 22:56 < Dom> not sure if it's worth it or not 22:56 < Dom> and would delay us another release, Ithink 22:57 < ntyni> yes, that was my main worry 22:58 < ntyni> no strong opinion on whether we should do it or not 22:59 < Dom> I think given it's been like this for around a year before someone notice (or at least filed a bug), I'd prefer to stick to our previously-announced course, and finally close #735134 23:01 < ntyni> do you mean removing /usr/bin/prename altogether, or moving it in the rename package now without an overlapping transition period? 23:02 < Dom> I mean removing prename altogehter 23:03 < Dom> which is after all what the deprecation warning says will happen 23:03 < Dom> oh hang on, the deprecation message also says that the rename package will provide 'the same command' 23:03 < Dom> ugh 23:03 < ntyni> yes, was just about to point that out 23:04 < Dom> is moving it to the rename package without alternatives good enough? 23:05 < ntyni> I suppose yes 23:05 < Dom> I guess it would need a simultaneous upload 23:05 < ntyni> but I think I'd like a test rebuild + bugs 23:06 < ntyni> yes on simultaneousness (if that is a word) 23:06 < Dom> simultaneity 23:06 < ntyni> thanks 23:08 < ntyni> I think rename would need to Replace perl (<< something) for the overwriting, and Depend on perl perl (>= something) so that installing and then removing rename on an older perl will not lose prename prematurely 23:09 < Dom> yeah. 23:09 < Dom> Or we could just repeat the recipe we already played out for the rename command 23:10 < Dom> *headdesk* so frustrating 23:10 < Dom> and so trivial 23:10 < ntyni> indeed 23:12 < ntyni> the alternatives were needed because we wanted the /usr/bin/rename versions to be coinstallable 23:12 < ntyni> if we don't want that for /usr/bin/prename I guess we can do without alternatives 23:12 < ntyni> and we only want it if we want to keep prename for another release 23:13 < Dom> oh, I remember now 23:13 < Dom> we harnessed an already-existing alternative for rename that has been in perl since 2005 23:13 < Dom> I think your plan is better 23:13 < ntyni> right; /usr/bin/rename was historically an alternative with a brief coexistence in util-linux 23:13 < Dom> with Replaces: 23:21 < ntyni> Dom: ok with me copy-pasting this discussion to #735134 so we don't forget? 23:21 -zwiebelbot:#debian-perl- Debian#735134: perl: rename(1) is ancient - https://bugs.debian.org/735134 23:22 < Dom> sure. -- Niko Tyni nt...@debian.org
Bug#871409: libio-socket-ssl-perl: FTBFS: t/protocol_version.t failure
Package: libio-socket-ssl-perl Version: 2.049-1 Severity: serious User: debian-p...@lists.debian.org Usertags: autopkgtest As noticed by ci.debian.net: https://ci.debian.net/packages/libi/libio-socket-ssl-perl/unstable/amd64/ this package fails to build on current sid/amd64. debci.log indicates this is fallout from openssl disabling TLS 1.0 and 1.1 recently: -openssl 1.1.0f-3 +openssl 1.1.0f-4 See https://lists.debian.org/debian-devel-announce/2017/08/msg4.html >From the build log: # looks like OpenSSL was compiled without SSLv3 support # Failed test 'accept TLSv1' # at t/protocol_version.t line 125. # Failed test 'accept SSLv23:!TLSv1_2:!TLSv1_1' # at t/protocol_version.t line 125. # Failed test 'accept TLSv1_1' # at t/protocol_version.t line 125. # Failed test 'accept SSLv23:!TLSv1_2' # at t/protocol_version.t line 125. # Looks like you failed 4 tests of 7. t/protocol_version.t .. ok 1 - accept SSLv23 with any, got TLSv1_2 not ok 2 - accept TLSv1 not ok 3 - accept SSLv23:!TLSv1_2:!TLSv1_1 not ok 4 - accept TLSv1_1 not ok 5 - accept SSLv23:!TLSv1_2 ok 6 - accept TLSv1_2 with TLSv1_2 ok 7 - accept SSLv23 with TLSv1_2 1..7 Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/7 subtests [...] Test Summary Report --- t/protocol_version.t(Wstat: 1024 Tests: 7 Failed: 4) Failed tests: 2-5 Non-zero exit status: 4 t/sessions.t(Wstat: 256 Tests: 11 Failed: 1) Failed test: 10 Non-zero exit status: 1 Parse errors: Bad plan. You planned 35 tests but ran 11. Files=36, Tests=747, 42 wallclock secs ( 0.27 usr 0.04 sys + 7.04 cusr 0.73 csys = 8.08 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#871389: altree: FTBFS: build-dependency not installable: libmath-tamuanova-perl
On Mon, Aug 07, 2017 at 06:46:25PM +0200, Andreas Tille wrote: > I wonder whether something might be wrong with the apt cache, since > I can not find any sign that libmath-tamuanova-perl would be missing. It's not missing but it's uninstallable in sid together with the other build dependencies, specifically libgsl-dev. Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgsl-dev : Depends: libgsl23 (= 2.4+dfsg-4) but it is not going to be installed Depends: libgslcblas0 (= 2.4+dfsg-4) but it is not going to be installed E: Unable to correct problems, you have held broken packages. This is due to gsl breakage/uncoordinated transition, see #869778 . -- Niko Tyni nt...@debain.org
Bug#870252: pkg-perl-autopkgtest: skip t/00-compile/*.t
On Sat, Aug 05, 2017 at 02:37:35PM -0400, gregor herrmann wrote: > On Fri, 04 Aug 2017 17:42:47 -0400, Alex Muntada wrote: > > > gregor herrmann: > > > A quick glance at the commit says: looks good! > > Looks good to me, too. > > So I guess we could upload the package with this change? > Who wants to do it? Thanks for the eyeballs, uploaded :) Have a happy DebConf! -- Niko
Bug#870334: pkg-perl-autopkgtest: revisiting smoke prove --recurse
On Wed, Aug 02, 2017 at 03:50:39PM -0400, gregor herrmann wrote: > On Wed, 02 Aug 2017 11:10:25 +0300, Niko Tyni wrote: > > Sure, we should filter the more common tests of this kind out > > of the runtime check list. > > Ack, and this should bring us a long way. > (I saw quite a few t/author/ and t/00-compile/ today.) This is now fixed in git fwiw (#870252) > Yes, it makes total sense in theory; I just also happen to like the > idea that we are currently running as many tests as possible. I see your point. > But yeah, if a realiable implementation of "find out build tests and > run them during autopkgtest" is possible then it probably makes > sense. And ... > > The 'make -n -p | grep TEST_FILES' thing seems most promising to me so far > > (even if it's for EU::MM only.) I played with this a bit and while it seems to work, I think it feels a bit too intrusive to me. The second package I tried it with, libbest-perl, generates tests when running Makefile.PL and then lists them one by one in TEST_FILES. So we'd need to do this at least before copying the tests to the tempdir, and the skipped tests might then become a problem... Also I'm a bit worried about other side effects that running Makefile.PL might have. For now, I've pushed what I have to the ntyni/autopkgtest-smoke-list branch as a40524732a6967fc64030e51b00f4998b137208a . > > I just noticed that the Build files generated by Module::Build have a > > 'retest' option that looks promising: Didn't get that far but this feels even more intrusive. Any urgency this issue had is gone now that you did all the work of fixing the --recurse regressions. Many thanks for that :) I think I'm leaving this for now. We can see if it becomes a problem later, and if not, just close this. -- Niko
Bug#870249: pkg-perl-autopkgtest: look at 'tests' in Module::Install based Makefile.PL files
Control: severity -1 normal Control: forcemerge -1 870334 On Wed, Aug 02, 2017 at 11:58:43AM +0300, Niko Tyni wrote: > On Mon, Jul 31, 2017 at 01:00:20PM +0300, Niko Tyni wrote: > > Package: pkg-perl-autopkgtest > > Version: 0.37 > > Severity: wishlist > > > > Apparently Module::Install supports a 'tests' line in Makefile.PL > > listing the tests to be run at build time. It would be nice if > > smoke.t looked at that instead of needing duplicated information in > > debian/tests/pkg-perl/smoke-tests . > > > > The package where I encountered this is libmousex-types-perl. > > A more general way to do this would be as discussed in #870334 : > > perl Makefile.PL && make -n -p | sed -n 's/^TEST_FILES = //p' > > Possibly these two bugs should be merged but not doing that > quite yet. Merging now, don't see much use in a more specific fix. -- Niko
Bug#870252: pkg-perl-autopkgtest: skip t/00-compile/*.t
On Wed, Aug 02, 2017 at 10:45:48AM -0400, gregor herrmann wrote: > On Mon, 31 Jul 2017 22:14:17 -0400, gregor herrmann wrote: > > > > These are not going to work with our autopkgtest setup as they look for > > > modules in the build tree. Also, we run 'perl -wc' in the autopkgtest > > > syntax check which should be more or less equivalent. > > > I propose that we add t/00-compile/*.t to the list that the smoke check > > > skips automatically. > > Ack. > > There are also tons of t/*compile*.t tests which are at best useless: > > And there's t/author/*.t in some packages. I've pushed 75b5cc25c71a896a85c4e92b8eceadb95439b065 that expands the skip list significantly. Eyeballs / testing would be welcome. -- Niko
Bug#870249: pkg-perl-autopkgtest: look at 'tests' in Module::Install based Makefile.PL files
On Mon, Jul 31, 2017 at 01:00:20PM +0300, Niko Tyni wrote: > Package: pkg-perl-autopkgtest > Version: 0.37 > Severity: wishlist > > Apparently Module::Install supports a 'tests' line in Makefile.PL > listing the tests to be run at build time. It would be nice if > smoke.t looked at that instead of needing duplicated information in > debian/tests/pkg-perl/smoke-tests . > > The package where I encountered this is libmousex-types-perl. A more general way to do this would be as discussed in #870334 : perl Makefile.PL && make -n -p | sed -n 's/^TEST_FILES = //p' Possibly these two bugs should be merged but not doing that quite yet. -- Niko
Bug#870334: pkg-perl-autopkgtest: revisiting smoke prove --recurse
On Tue, Aug 01, 2017 at 04:53:36PM -0400, gregor herrmann wrote: > On Tue, 01 Aug 2017 19:58:55 +0300, Niko Tyni wrote: > > > Hm. I agree the goal is to get the same list of tests that are run at > > build time. > > I don't agree 100% I think. > From what I've seen so far when looking at a dozen of the failures we > have: > - same tests in autopkgtest as during build, which fail because of > paths or missing files; so just the usual stuff but it appears only > now for t/**/*.t; Yeah, this was expected. > - more tests in autopkgtest than during build but perfectly > reasonable tests where it looks more like an issue that they are > not run during build (and the typical easy-to-fix-failures); If the issue here is that they should be run during build too, the "right" fix here as well seems to be unifying the list of build and runtime tests? > - and then the group where something weird is in t/ which happens to > look like a test but is a data file or a (misplaced and not > environment-variable-protected) author test etc. > Which is somewhat a case for #870252 Sure, we should filter the more common tests of this kind out of the runtime check list. I still maintain that if we can automatically determine the list of tests that get run during build time, we should base the list of runtime tests on that rather than recursing blindly. Of course, if this determination is too hard, it may be that recursing is good enough. Do we agree on that? > Hm, we could also "make" the distribution and rm blib/ before "make > test". Doesn't feel very clean though ... Indeed not :) The 'make -n -p | grep TEST_FILES' thing seems most promising to me so far (even if it's for EU::MM only.) I just noticed that the Build files generated by Module::Build have a 'retest' option that looks promising: retest [version 0.2806] This is just like the "test" action, but doesn't actually build the distribution first, and doesn't add blib/ to the load path, and therefore will test against a previously installed version of the distribution. This can be used to verify that a certain installed distribution still works, or to see whether newer versions of a distribution still pass the old regression tests, and so on. Potentially this could be used instead of all the 'copy the tests but not the source code' things. Not sure if it's worth it though. Unfortunately I don't see a corresponding EU::MM feature, though it seems it wouldn't be too hard to implement... -- Niko
Bug#870334: pkg-perl-autopkgtest: revisiting smoke prove --recurse
On Tue, Aug 01, 2017 at 11:31:05AM -0400, Alex Muntada wrote: > My idea is that we should smoke test the same list of tests that > are actually run by "make test" or "./Build test" without having > to parse those *.PL files to figure out that list. Therefore, > the list should be obtained by running those same commands with > some "--dry-run" and "--verbose" options, so we can get a list of > the files being run as tests and put that list in the smoke setup > files. > > The issue here is how this "--dry-run" and "--verbose" mode can > be run (e.g. "make -n test TEST_VERBOSE=1" comes to mind) and at > which point of package building that should happen, without > requiring human intervention if possible. Hm. I agree the goal is to get the same list of tests that are run at build time. I'm not very keen on parsing 'make -n' output. Seems somewhat doomed to fail. But yeah, I guess normally the output will end with something like PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/*/*.t t/*/*/*.t which could be parsed. The TEST_FILES thing I was referring to earlier is in the generated Makefile, sorry for my confusion. Parsing that one might work as the syntax will supposedly not vary much across packages, but requires running Makefile.PL first. That's probably not a huge problem as the build dependencies are already installed. Maybe the best of both worlds would be something like make -n -p | sed -n 's/^TEST_FILES = //p' with a fallback to 't/*.t' if it ends up empty for some reason. Alternatively, if we're running Makefile.PL anyway (I'm ignoring M::B for the moment), this might all be solved if we could just force run 'make test' without actually building first. The tests would get run with blib/lib etc. in @INC but if those were empty the installed files would presumably get used anyway. Unfortunately make doesn't seem to be too helpful with this... One more wild idea I had is to patch the build machinery (probably EU::MM itself) to record the list of tests it runs in a file. We could then install that file in the binary package during the build, and look there in the autopkgtest phase. This does feel somewhat intrusive, just mentioning it for completeness :) -- Niko
Bug#870340: perl: perldoc outputs visible escape sequences again
Package: perl Version: 5.26.0-4 As noticed by Olly Betts, the fix for #758689, where we injected the less '-R' option in perldoc, has regressed in the 5.26 packages. It looks like Pod::Perldoc is now trying to figure out what the pager is before injecting options, and possibly gets confused by Debian's sensible-pager or something like that. Some related links: https://github.com/mrallen1/Pod-Perldoc/issues/28 https://rt.perl.org/Public/Bug/Display.html?id=130759 https://github.com/mrallen1/Pod-Perldoc/pull/16 https://sources.debian.net/src/perl/5.26.0-4/cpan/Pod-Perldoc/lib/Pod/Perldoc/ToTerm.pm/#L35 -- Niko Tyni nt...@debian.org
Bug#870334: pkg-perl-autopkgtest: revisiting smoke prove --recurse
Package: pkg-perl-autopkgtest Version: 0.37 Since 0.37, we're running 'prove --recurse' by default in the smoke test. This has resulted in ~50 regressions according to ci.d.n: there are packages ship .t files under t/ subdirectories (or starting with a dot) that are not run during builds and are either broken or not intended to be run at all. Fixing these by adding t/*.t in debian/tests/pkg-perl/smoke-tests gets boring quite quickly, though it's certainly doable. All these packages seem to be relying on the ExtUtils::MakeMaker default of TEST_FILES => t/*.t. I'm wondering if we should try to parse that out of Makefile.PL during autopkgtest instead of always recursing, though that does seem somewhat error prone. FWIW, Module::Build seems to have a related 'recursive_test_files' option that is off by default (see Module::Build::API(3pm)). It might help a bit to collect some statistics about the number of packages with *.t files in subdirectories, and whether those have TEST_FILES specified in Makefile.PL. Currently I have no idea if the failing packages are just a small minority of the affected ones, or if almost all of them are failing now. -- Niko Tyni nt...@debian.org
Bug#867081: autopkgtest: @ no longer pulls in packages with versioned Provides
On Mon, Jul 03, 2017 at 10:40:45PM +0300, Niko Tyni wrote: > Package: autopkgtest > Version: 4.4 > User: debian-p...@lists.debian.org > Usertags: versioned-provides > X-Debbugs-Cc: debian-p...@lists.debian.org > > As seen on ci.debian.net with for instance libhttp-tiny-perl and > libcpan-meta-perl, autopkgtest gets confused about versioned Provides > that were introduced in sid recently with perl_5.24.1-5. > > It looks like "Depends: @" will no longer pull in the binary packages > to be tested if the same name is also Provided by installed packages > with a version. > > My reading of the autopkgtest code is that it synthesizes a dependency > on 'package (>= 0~)', where the versioning is assumed to guarantee that > only a real package gets pulled in. This assumption no longer holds with > versioned Provides. Oh, I'd mostly forgotten about #761003 which introduced the '(>= 0~)' thing three years ago and where we predicted that this will break with versioned Provides. The solution we discussed there was to insert an additional explicit apt-get install phase to the autopkgtest-satdep.deb installation (which unpacks a temporary package and then calls 'apt-get --fix-missing' to have apt solve the dependencies.) This explicit call prefers real packages to virtual ones (at least in all my tests though I can't find this documented; possibly this should be checked with the apt maintainers.) Is this approach something you would consider now that the versioned Provides issue has materialized in practice? -- Niko Tyni nt...@debian.org
Bug#870295: perl: broken symlink /usr/share/man/man1/pstruct.1.gz
Control: tag -1 pending On Mon, Jul 31, 2017 at 07:15:39PM +0200, Manolo Díaz wrote: > Package: perl > Version: 5.26.0-4 > Severity: normal > > Dear Maintainer, > > /usr/share/man/man1/pstruct.1.gz is a broken symlink that points to the > c2ph.1.gz file in the same directory which isn't provided by any package > from Debian testing accordantly to apt-file. Thanks! This will be fixed in the next upload. -- Niko Tyni nt...@debian.org
Bug#870252: pkg-perl-autopkgtest: skip t/00-compile/*.t
Package: pkg-perl-autopkgtest
Version: 0.37
Severity: wishlist
Starting with 0.37, we run the smoke test with 'prove --recurse'.
This has caused a few dozen regressions where packages that
used to pass their autopkgtest checks are now failing due to
tests in subdirectories of t/ that were not run earlier.
One somewhat common failure mode is breakage in t/00-compile/, which I've
encountered in at least libpath-finddev-perl and libmoosex-has-sugar-perl
and which contain autogenerated tests like this:
use strict;
use warnings;
# This test was generated for
# using by Dist::Zilla::Plugin::Test::Compile::PerFile (
@Author::KENTNL/Test::Compile::PerFile ) version 0.002001
# with template 01-basic.t.tpl
use Test::More 0.89 tests => 1;
require_ok("lib/MooseX/Has/Sugar/Minimal.pm");
These are not going to work with our autopkgtest setup as they look for
modules in the build tree. Also, we run 'perl -wc' in the autopkgtest
syntax check which should be more or less equivalent.
I propose that we add t/00-compile/*.t to the list that the smoke check
skips automatically.
--
Niko Tyni nt...@debian.org
Bug#870249: pkg-perl-autopkgtest: look at 'tests' in Module::Install based Makefile.PL files
Package: pkg-perl-autopkgtest Version: 0.37 Severity: wishlist Apparently Module::Install supports a 'tests' line in Makefile.PL listing the tests to be run at build time. It would be nice if smoke.t looked at that instead of needing duplicated information in debian/tests/pkg-perl/smoke-tests . The package where I encountered this is libmousex-types-perl. -- Niko Tyni nt...@debian.org
Bug#870236: libnet-dns-perl: autopkgtest broken in 1.10
On Sun, Jul 30, 2017 at 11:28:40PM -0700, Steve Langasek wrote: > Package: libnet-dns-perl > Version: 1.10-1 > Severity: important > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu artful ubuntu-patch autopkgtest > In Ubuntu, the libnet-dns-perl autopkgtests are failing: > > t/00-version.t > 1..1 > ok 1 - file version: 0.01 blib/lib/Debian/pkgperl/Foobar.pm > No such file or directory at t/00-version.t line 40. > END failed--call queue aborted. > # Looks like your test exited with 2 just after 1. > Dubious, test returned 2 (wstat 512, 0x200) > > <http://autopkgtest.ubuntu.com/packages/libn/libnet-dns-perl/artful/amd64> > > This is a regression vs. 1.07, which is the last version that has been > tested so far on ci.debian.net. > > I've tracked down the regression to the fact that the autopkgtest references > 'Makefile' in the current directory, but when run as part of the generic > perl autopkgtests, we won't have done a package build so there is no > Makefile only Makefile.PL. To resolve this, I've created the attached patch > which checks for the existence of Makefile before attempting to open it. Thanks. The test doesn't make much sense for the autopkgtest setup, so skipping it makes sense. An easier way to do that would be just to put it in debian/tests/pkg-perl/smoke-skip, which I've just done with 1.10-2. -- Niko Tyni nt...@debian.org
Bug#870235: libchi-perl incompatible with libcache-fastmmap-perl 1.46
Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=120705
Control: tag -1 upstream patch
On Sun, Jul 30, 2017 at 11:05:58PM -0700, Steve Langasek wrote:
> Package: libchi-perl
> Version: 0.60-3
> Severity: important
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu artful autopkgtest
>
> Dear maintainers,
>
> As shown at
> <https://ci.debian.net/packages/libc/libchi-perl/unstable/amd64/>, the
> autopkgtests of libchi-perl fail since the upload of libcache-fastmmap-perl
> 1.46:
>
> Test Summary Report
> ---
> t/smoke-Driver-FastMmap.t (Wstat: 256 Tests: 920 Failed: 1)
> Failed test: 140
> Non-zero exit status: 1
> Files=24, Tests=6550, 14 wallclock secs ( 0.87 usr 0.10 sys + 7.14 cusr
> 0.90 csys = 9.01 CPU)
> Result: FAIL
Thanks for the report.
The package would also fail to build from source due to this, but the test
is gated on $ENV{AUTOMATED_TESTING} so it gets skipped. (AUTOMATED_TESTING
is set in the autopkgtest-pkg-perl setup, but not for the build. Possibly
it should be set for both.)
There's a proposed patch in the upstream ticket by Petr Písař, sadly
with no comment from upstream yet. Attaching for convenience.
--
Niko Tyni nt...@debian.org
>From 8513c82bca186a9c724fe9c9b44ccbac062793d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?=
Date: Wed, 3 May 2017 16:57:52 +0200
Subject: [PATCH] Adapt to changes in Cache-FastMmap-1.45
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cache-FastMmap-1.45 deprecated raw_values constructor argument in
favor of new serializer argument. This changes caused
t/smoke-Driver-CacheCache.t to fail.
This patch uses serializer with Cache::FastMmap >= 1.45, otherwise the old
raw_values.
CPAN RT#120705
Signed-off-by: Petr Písař
---
lib/CHI/Driver/FastMmap.pm | 10 +++---
lib/CHI/t/Driver/FastMmap.pm | 6 +-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/lib/CHI/Driver/FastMmap.pm b/lib/CHI/Driver/FastMmap.pm
index 1b43344..19edcf8 100644
--- a/lib/CHI/Driver/FastMmap.pm
+++ b/lib/CHI/Driver/FastMmap.pm
@@ -21,7 +21,11 @@ sub BUILD {
mkpath( $self->root_dir, 0, $self->dir_create_mode )
if !-d $self->root_dir;
$self->{fm_params} = {
-raw_values => 1,
+(
+($Cache::FastMmap::VERSION >= 1.45) ?
+(serializer => '') :
+(raw_values => 1)
+),
unlink_on_exit => 0,
share_file => catfile(
$self->root_dir,
@@ -108,8 +112,8 @@ though not between hosts.
To support namespaces, this driver takes a directory parameter rather than a
file, and creates one Cache::FastMMap file for each namespace.
-Because CHI handles serialization automatically, we pass the C flag
-as 1; and to conform to the CHI API, we pass C as 0, so that
+Because CHI handles serialization automatically, we pass the C flag
+as ''; and to conform to the CHI API, we pass C as 0, so that
all cache files are permanent.
=head1 CONSTRUCTOR OPTIONS
diff --git a/lib/CHI/t/Driver/FastMmap.pm b/lib/CHI/t/Driver/FastMmap.pm
index 2339c84..8532804 100644
--- a/lib/CHI/t/Driver/FastMmap.pm
+++ b/lib/CHI/t/Driver/FastMmap.pm
@@ -35,7 +35,11 @@ sub test_fm_cache : Tests {
my %defaults = (
unlink_on_exit => 0,
empty_on_exit => 0,
-raw_values => 1,
+(
+($Cache::FastMmap::VERSION >= 1.45) ?
+(serialize => 0) :
+(raw_values => 1)
+),
);
while ( my ( $key, $value ) = each(%defaults) ) {
is( $fm_cache->{$key} || 0, $value, "$key = $value by default" );
--
2.7.4
Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node
On Sat, Jul 29, 2017 at 10:05:34PM +0200, Tollef Fog Heen wrote: > === Resolution === > > The Technical Committee recognises that circumstances change in ways > that make previous resolutions no longer appropriate. In 2012, it was > resolved that the nodejs package should not provide /usr/bin/node due to > the historical conflict with the ax25-node package. Node.js is still > quite popular and the ax25-node package is no longer in stable, testing > or unstable so the requirement for nodejs to not provide /usr/bin/node > no longer applies. > > The Committee therefore resolves that: > > 1. The CTTE decision from 2012-07-12 in bug #614907 is repealed. > > This means Debian's normal policies and practices take over and the > nodejs package is free to provide /usr/bin/node. The migration should > be managed according to Debian's usual backwards-compatibility > arrangements. > > === End Resolution === > > R: Approve resolution and repeal the CTTE decision from 2012-07-12. > F: Further Discussion I vote: R > F -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#869122: Bug#869373: Bug#869122: perl: 5.26 FTBFS on hppa: broken miniperl?
On Tue, Jul 25, 2017 at 03:55:14PM -0400, John David Anglin wrote: > On 2017-07-24, at 5:31 PM, John David Anglin wrote: > > >> Does it work for you without the Perl_custom_op_get_field() code > >> reorganization if you patch cflags.SH further like this? > >> > >> -op) : work around http://bugs.debian.org/838613 > >> +op|opmini) : work around http://bugs.debian.org/838613 > >> > >> This should make it build both op.c and opmini.c at -O0. > > > > Might work. > > Another option is to use gcc-7. It built 2.26 successfully. Problem seems > to be specific to gcc-6. My preference at this point would be amending the earlier patch as above to also lower the opmini.c optimization. I intend to upload 5.26.0-5 soonish with that workaround activated for hppa and sh4. Let's revisit the other options if that doesn't work out. (I understand the urgency related to the 5.26 transition is over now for you too, so it hopefully shouldn't impact your other work much if -5 doesn't build on hppa/sh4 after all.) Thanks for your work, -- Niko Tyni nt...@debian.org
Bug#870095: liblwp-protocol-https-perl: Make source package bootstrappable
On Sat, Jul 29, 2017 at 11:19:42AM -0700, Daniel Schepler wrote: > Source: liblwp-protocol-https-perl > Version: 6.07-1 > Severity: wishlist > > Currently, liblwp-protocol-https-perl Build-Depends on libwww-perl > which in turn Depends on liblwp-protocol-https-perl. It would be nice > if this build dependency cycle could be broken to aid the goal of a > bootstrappable Debian. Thanks for reporting this issue! I agree this would be nice. > As far as I can tell, if you don't run the testsuite then libwww-perl > isn't required, so the package could update the Build-Depends-Indep to > something like: > > Build-Depends-Indep: perl, libio-socket-ssl-perl , > libnet-http-perl , libwww-perl (>= 6.05-2) , > libtest-requiresinternet-perl > > which would take care of the cycle. This feels right to me fwiw and should work fine. As an aside I'm wondering if we (pkg-perl) should start tagging build dependencies with as a matter of course. While making the metadata richer this way would certainly be an improvement in the quality of the packaging, the utility does seem somewhat limited. For arch:any packages it would aid at least cross building, but for arch:all the only thing I can think of is breaking (rare) build dependency loops like this one. In general, I expect that the vast majority of pkg-perl packages are similar to this one in that they only need debhelper, perl and maybe libmodule-build-perl to actually build, with the rest of the build dependencies being only needed for the test suite. I think I'll bring this up on the debian-perl list when I find some time, just wanted to chime in here. I'll upload the fix soonish unless someone beats me to it. Cheers, -- Niko Tyni nt...@debian.org
Bug#869139: syslog-ng-incubator FTBFS on s390x: FAIL: modules/grok/tests/test_grok
On Mon, Jul 24, 2017 at 11:40:40PM +0300, Niko Tyni wrote: > On Sun, Jul 23, 2017 at 10:36:04PM +0200, gregor herrmann wrote: > > On Thu, 20 Jul 2017 22:50:00 +0300, Adrian Bunk wrote: > > > > > https://buildd.debian.org/status/fetch.php?pkg=syslog-ng-incubator&arch=s390x&ver=0.5.0-5&stamp=1500577713&raw=0 > > > > > > > > ### > > > # > > > # FAIL: ASSERTION FAILED: Named capture didn't stored; actual_length=0 > > > expected_length=5, > > > # actual= '', > > > # expected= 'value' > > > # > > > > > > ### > > > > > > FAIL modules/grok/tests/test_grok (exit status: 1) > > > > Confirmed on zelenka in the s390x-sid chroot. > > Just for the record, this seems to be specific to 64-bit big endian > platforms as it failed on ppc64 and sparc64 too. This seems to be #841668 in src:grok. -- Niko Tyni nt...@debian.org
Bug#869139: syslog-ng-incubator FTBFS on s390x: FAIL: modules/grok/tests/test_grok
On Sun, Jul 23, 2017 at 10:36:04PM +0200, gregor herrmann wrote: > On Thu, 20 Jul 2017 22:50:00 +0300, Adrian Bunk wrote: > > > https://buildd.debian.org/status/fetch.php?pkg=syslog-ng-incubator&arch=s390x&ver=0.5.0-5&stamp=1500577713&raw=0 > > > > > ### > > # > > # FAIL: ASSERTION FAILED: Named capture didn't stored; actual_length=0 > > expected_length=5, > > # actual= '', > > # expected= 'value' > > # > > > > ### > > > > FAIL modules/grok/tests/test_grok (exit status: 1) > > Confirmed on zelenka in the s390x-sid chroot. Just for the record, this seems to be specific to 64-bit big endian platforms as it failed on ppc64 and sparc64 too. Hope this helps a bit, -- Niko Tyni nt...@debian.org
Bug#869122: Bug#869373: Bug#869122: perl: 5.26 FTBFS on hppa: broken miniperl?
On Mon, Jul 24, 2017 at 02:01:16PM -0400, John David Anglin wrote: > On 2017-07-24, at 6:45 AM, John Paul Adrian Glaubitz wrote: > > > On Sun, Jul 23, 2017 at 09:32:04PM -0400, John David Anglin wrote: > >> Maybe the patch will also fix the sh build. > > > > Yes, it does. I just tested the patch and I can confirm with the patch > > applied, I can build src:perl just fine on sh4 without "noopt". > > I created a gcc bug report: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81538 Thanks for your great work on this! I feel somewhat uneasy about applying a workaround patch that affects all the architectures for the sake of non-release architectures. I can see that it's just a code reorganization that presumably avoids the buggy gcc optimization (at least for the time being), but it's a bit hard to feed upstream as-is and I wouldn't like to carry it for the major architectures without upstreaming it. Do you know why the GCC optimization issue only seems to affect hppa+sh4? I wonder if lowering the optimization of the affected code would be an easier workaround. On that note, looking at the build logs makes me think the cflags fiddling in debian/patches/debian/hppa_op_optimize_workaround.diff is still working, but the problem here is that op.c is linked to opmini.c for the miniperl build and that still gets compiled at -O2. Does it work for you without the Perl_custom_op_get_field() code reorganization if you patch cflags.SH further like this? -op) : work around http://bugs.debian.org/838613 +op|opmini) : work around http://bugs.debian.org/838613 This should make it build both op.c and opmini.c at -O0. Or does this hit the hppa "-O0 -fPIC" problem again? (For sh4, the archname check on the next lines obviously needs adjustment too.) Thanks again, especially for filing the gcc upstream bug so we can eventually get rid of these workarounds. -- Niko
Bug#869612: perl: add Breaks on older versions of intltool
Package: perl Version: 5.26.0-4 User: debian-p...@lists.debian.org Usertags: perl-5.26-transition As seen in #826471 the perl 5.26 transition broke /usr/bin/intltool-update. This was fixed in intltool_0.51.0-4, so perl-base should Break older versions to make sure partial upgrades don't end up with the broken combination. -- Niko Tyni nt...@debian.org
Bug#869602: libclang-perl: FTBFS on armel: clang-c/Index.h: No such file or directory
Package: libclang-perl Version: 0.09-4 Severity: serious Control: block 866389 with -1 Control: block -1 with 866354 The Perl 5.26 binNMU for this package failed to build on armel. https://buildd.debian.org/status/fetch.php?pkg=libclang-perl&arch=armel&ver=0.09-4%2Bb3&stamp=1500677901&raw=0 debian/rules build-arch llvm-config: relocation error: /usr/lib/arm-linux-gnueabi/libLLVM-3.8.so.1: symbol _ZTINSt13__future_base12_Result_baseE, version GLIBCXX_3.4.15 not defined in file libstdc++.so.6 with link time reference llvm-config: relocation error: /usr/lib/arm-linux-gnueabi/libLLVM-3.8.so.1: symbol _ZTINSt13__future_base12_Result_baseE, version GLIBCXX_3.4.15 not defined in file libstdc++.so.6 with link time reference [...] arm-linux-gnueabi-gcc -c -I -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DVERSION=\"0.09\" -DXS_VERSION=\"0.09\" -fPIC "-I/usr/lib/arm-linux-gnueabi/perl/5.26/CORE" Clang.c Clang.xs:5:27: fatal error: clang-c/Index.h: No such file or directory #include ^ compilation terminated. Makefile:353: recipe for target 'Clang.o' failed make[2]: *** [Clang.o] Error 1 The reason seems to be #866354 in libstdc++6. -- Niko Tyni nt...@debian.org
Bug#869122: perl: 5.26 FTBFS on hppa: broken miniperl?
On Sun, Jul 23, 2017 at 04:14:17PM -0400, John David Anglin wrote: > Problem is probably in Perl_custom_op_get_field. Need to figure out why it > returns 0xbf600701. Just a note that #838613 sounds related, and we're still carrying the patch from 5.24 that lowers the optimization level of op.c to -O0. Maybe that has become harmful now if there are problems mixing -O0 and -O2 code? -- Niko Tyni nt...@debian.org
Bug#869373: perl: Please add workaround to fix FTBFS on sh4
On Sat, Jul 22, 2017 at 09:19:30PM +0200, John Paul Adrian Glaubitz wrote: > On 07/22/2017 09:08 PM, Niko Tyni wrote: > > Thanks. In that case you should be able to work around the breakage > > (and hopefully catch up with the 5.26 transition) by building with > > DEB_BUILD_OPTIONS=noopt. > > This is for the buildds. I know that I can build the package manually. Sure, I was just thinking of a manual "porter upload" to get the binNMUs going before the next source upload. But it looks like you (or someone else) did that already. > > The failure mode looks very similar to the hppa one (#869122, cc'd) > > so I guess it should get similar treatment. > > I tried the same workaround on hppa, it didn't help unfortunately. Too bad. Dropping that bug then. > > Would you be able to narrow this down to file level? Cf. #838613 and > > debian/patches/debian/hppa_op_optimize_workaround.diff > > This patch seems to fix a failure of the testsuite, no? The build on > hppa crashes much earlier though. My point was just that file-level optimizations can be achieved by modifying cflags.SH as seen in that patch. I think (but haven't verified) that miniperl is built via cflags.SH too. -- Niko
Bug#869122: Bug#869373: perl: Please add workaround to fix FTBFS on sh4
On Sat, Jul 22, 2017 at 08:51:23PM +0200, John Paul Adrian Glaubitz wrote: > Source: perl > Version: 5.26.0-4 > Severity: normal > Tags: patch > User: debian-sup...@lists.debian.org > Usertags: sh4 > > Hi! > > src:perl currently fails to build from source on sh4 with: > > ./miniperl -Ilib make_ext.pl cpan/Archive-Tar/pm_to_blib > MAKE="/usr/bin/make" LIBPERL_A=libperl.a > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > Unsuccessful Makefile.PL(cpan/Archive-Tar): code=11 at make_ext.pl line 518. > Makefile:586: recipe for target 'cpan/Archive-Tar/pm_to_blib' failed > make[1]: *** [cpan/Archive-Tar/pm_to_blib] Error 2 > make[1]: Leaving directory '/<>' > debian/rules:124: recipe for target 'perl.static' failed > make: *** [perl.static] Error 2 > dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 > > I have not tracked down the actual reason for the bug yet, but it can > be worked around by building perl without optimizations enabled on sh4. > > The attached patch disables the optimizations on sh4 and makes the build > succeed. Please consider applying it for the next upload. Thanks. In that case you should be able to work around the breakage (and hopefully catch up with the 5.26 transition) by building with DEB_BUILD_OPTIONS=noopt. The failure mode looks very similar to the hppa one (#869122, cc'd) so I guess it should get similar treatment. Would you be able to narrow this down to file level? Cf. #838613 and debian/patches/debian/hppa_op_optimize_workaround.diff -- Niko Tyni nt...@debian.org
Bug#869360: slic3r: missing dependency on perlapi-*
Package: slic3r
Version: 1.2.9+dfsg-6
Severity: serious
Tags: buster sid
User: debian-p...@lists.debian.org
Usertags: perl-5.26-transition
X-Debbugs-Cc: p...@packages.debian.org
This package contains a binary ("XS") Perl module
/usr/lib/slic3r/auto/Slic3r/XS/XS.so
but does not depend on perlapi-*. This is a violation
of the Debian Perl policy, quoting:
4.4.2. Binary and Other Architecture Dependent Modules
Binary modules must specify a dependency on either perl or
perl-base with a minimum version of the perl package used to build the
module. Additionally, all binary modules (regardless of their installation
directory) and any other modules installed into $Config{vendorarch} must
depend on the expansion of perlapi-$Config{debian_abi} using the Config
module. If $Config{debian_abi} is empty or not set, $Config{version}
must be used.
The perlapi-* dependency guarantees that the binary module is compatible
with the version of perl on the system.
I see the release team tools have spotted this package and scheduled
binNMUs for the ongoing Perl 5.26 transition, probably because
older versions with the perlapi-* dependency are still around on some
architectures. Still, partial upgrades (upgrading perl without upgrading
slic3r or vice versa) will result in breakage.
The fix is probably something like
override_dh_perl:
dh_perl /usr/lib/slic3r
so that dh_perl knows about the private library directory.
Once this is fixed, please file a bug against perl so we can add a
Breaks entry for older versions. This makes sure partial upgrades from
stretch work.
--
Niko Tyni nt...@debian.org
Bug#866389: transition: perl 5.26
On Fri, Jul 21, 2017 at 10:19:11AM +0200, Emilio Pozuelo Monfort wrote: > On 20/07/17 22:51, Niko Tyni wrote: > > Control: block -1 with 869139 > > > > On Thu, Jul 20, 2017 at 09:16:41PM +0200, Emilio Pozuelo Monfort wrote: > >> On 20/07/17 21:01, Niko Tyni wrote: > >>> On Thu, Jun 29, 2017 at 07:51:33PM +0200, Emilio Pozuelo Monfort wrote: > >>>> Control: forwarded -1 > >>>> https://release.debian.org/transitions/html/perl5.26.html > > > >>> Please let us know when it would be OK to upload Perl 5.26 to sid. > >> > >> Awesome. Now is a good time. I have added some hints for the gsoap and > >> libprelude transitions, so they don't get entangled with this one. > > > > Thanks. I have an upload (almost) ready, but a last minute issue popped > > up as the fixed syslog-ng-incubator fails to build on s390x. See #869139. > > > > Do you want me to hold off because of that? > > I think we can go ahead and worst case remove it as we were planning to before > it got fixed. Thanks. Uploaded earlier today, noting here for the sake of completeness. -- Niko
Bug#869231: perl: FTBFS on sparc64: re/fold_grind.t timeout
On Fri, Jul 21, 2017 at 02:30:07PM -0400, Aaron M. Ucko wrote: > Source: perl > Version: 5.26.0-4 > Severity: important > Justification: fails to build from source (but built successfully in the past) > > Recent builds of perl on sparc64 (admittedly not a release > architecture) have been failing: > > t/re/fold_grind # Test > process timed out - terminating > FAILED--no leader found > > Could you please take a look? Thanks. Copying the debian-sparc list in the hope somebody there will debug this. 5.26.0-4 built on the 'landau' buildd fwiw so it seems either nondeterministic or hardware related. It looks like there's a test timeout of 300 seconds, maybe it's just too slow? That would be a bit odd given it doesn't happen on the "small" architectures (arm*, mips*)... See also #869124 for another apparently timing related issue on sparc64. -- Niko Tyni nt...@debian.org
Bug#869229: perl: FTBFS on hurd-i386: Time-HiRes/t/utime.t fails
On Fri, Jul 21, 2017 at 02:27:38PM -0400, Aaron M. Ucko wrote: > Source: perl > Version: 5.26.0-4 > Severity: important > Justification: fails to build from source (but built successfully in the past) > > Recent builds of perl on hurd-i386 (admittedly not a release > architecture) have been failing with multiple errors in the > dist/Time-HiRes/t/utime test, as detailed at > > https://buildd.debian.org/status/fetch.php?pkg=perl&arch=hurd-i386&ver=5.26.0-4&stamp=1500637358&raw=0 Thanks. Copying the debian-hurd list. This looks like https://rt.cpan.org/Public/Bug/Display.html?id=116127 which was about ext2/ext3 on Linux not recording fractional seconds. The "fix" of parsing /proc/mounts seems fragile at best... Patches for fixing this on Hurd would be welcome, and I expect upstream to be receptive as well. -- Niko Tyni nt...@debian.org
Bug#866389: transition: perl 5.26
Control: block -1 with 869139 On Thu, Jul 20, 2017 at 09:16:41PM +0200, Emilio Pozuelo Monfort wrote: > On 20/07/17 21:01, Niko Tyni wrote: > > On Thu, Jun 29, 2017 at 07:51:33PM +0200, Emilio Pozuelo Monfort wrote: > >> Control: forwarded -1 > >> https://release.debian.org/transitions/html/perl5.26.html > > Please let us know when it would be OK to upload Perl 5.26 to sid. > > Awesome. Now is a good time. I have added some hints for the gsoap and > libprelude transitions, so they don't get entangled with this one. Thanks. I have an upload (almost) ready, but a last minute issue popped up as the fixed syslog-ng-incubator fails to build on s390x. See #869139. Do you want me to hold off because of that? -- Niko Tyni nt...@debian.org
Bug#866389: transition: perl 5.26
On Thu, Jun 29, 2017 at 07:51:33PM +0200, Emilio Pozuelo Monfort wrote: > Control: forwarded -1 > https://release.debian.org/transitions/html/perl5.26.html > > On 29/06/17 14:07, Niko Tyni wrote: > > Package: release.debian.org > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: debian-p...@lists.debian.org > > > > We'd like to get Perl 5.26 in sid/buster soonish. > Nice. Let us know when things are better. Currently there's not much going on > and we could do the perl transition without problems if you were ready. But > let's evaluate again when things are improved. Hi, we're now ready to go. The only known blocker left is #826473 in kdesrc-build, which can be removed from testing. We just did a one last rebuild test of the packages that will need a binnmu, and found no new issues. Many kudos to all the maintainers who fixed their packages, and to Gregor who fixed the rest :) Please let us know when it would be OK to upload Perl 5.26 to sid. -- Niko Tyni nt...@debian.org
Bug#866389: transition: perl 5.26
On Thu, Jul 20, 2017 at 10:51:53AM +0200, gregor herrmann wrote: > On Thu, 20 Jul 2017 10:43:30 +1000, Paul Wise wrote: > > > On Thu, Jul 20, 2017 at 5:04 AM, gregor herrmann wrote: > > > #867213: syslog-ng-incubator: one rdep (syslog-ng). No reaction on > > > the bug report, unrelated build failure; I guess syslog-ng* > > > can be removed from testing if noone fixes the problem in > > > time. > > I'd like to point out that DSA relies on syslog-ng on debian.org > > hosts, so it would be appreciated if the issues could be fixed or > > worked around rather than removing syslog-ng from buster. Of course > > buster is not in use on any debian.org hosts yet. > > Good news: Some hours ago the maintainer added a note about a local > fix to the bug log and tagged the bug pending. Indeed. I'd also like to point out that the package failing to build in sid is src:syslog-ng-incubator, not syslog-ng itself. The binary packages that risk testing removal due to this are syslog-ng-mod-trigger syslog-ng-mod-rss syslog-ng-mod-basicfuncs-plus syslog-ng-mod-lua syslog-ng-mod-perl syslog-ng-mod-date syslog-ng-mod-grok syslog-ng-mod-kafka syslog-ng-mod-zmq -- Niko Tyni nt...@debian.org
Bug#869124: perl: waithires.t problems on sparc64
Package: perl Version: 5.24.1-7 Severity: normal Control: found -1 5.26.0-3 X-Debbugs-Cc: debian-sp...@lists.debian.org The perl package has mostly failed to build on sparc64 recently due to waithires.t failures. There's a few successful builds too (including 5.26.0-1) so it's probably nondeterministic. However, it seems limited to sparc64 afaics. I'm copying the debian-sparc list. I don't intend to work on this myself, but patches are welcome of course if it turns out to be a bug in perl and not the sparc64 platform. -- Niko Tyni nt...@debian.org
Bug#869122: perl: 5.26 FTBFS on hppa: broken miniperl?
Package: perl Version: 5.26.0-1 Severity: normal X-Debbugs-Cc: debian-h...@lists.debian.org Perl 5.26 (currently in experimental) has never built on hppa yet. It's failing with ./miniperl -Ilib make_ext.pl cpan/Archive-Tar/pm_to_blib MAKE="/usr/bin/make" LIBPERL_A=libperl.a Unsuccessful Makefile.PL(cpan/Archive-Tar): code=11 at make_ext.pl line 518. Makefile:586: recipe for target 'cpan/Archive-Tar/pm_to_blib' failed make[1]: *** [cpan/Archive-Tar/pm_to_blib] Error 2 make[1]: Leaving directory '/<>' debian/rules:124: recipe for target 'perl.static' failed make: *** [perl.static] Error 2 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 so it looks like something's seriously wrong. I don't intend to work on this myself (at least in the short term) but patches are welcome of course. I'm copying the debian-hppa list. We're very close to a transition to 5.26 in sid, so there's a danger of hppa getting left behind. Apologies for the late notice. -- Niko Tyni nt...@debian.org
Bug#866389: transition: perl 5.26
On Fri, Jul 14, 2017 at 10:50:16AM +0200, Emilio Pozuelo Monfort wrote: > On 02/07/17 19:04, Dominic Hargreaves wrote: > > On Sun, Jul 02, 2017 at 05:01:20PM +0200, gregor herrmann wrote: > >> On Fri, 30 Jun 2017 12:39:09 +0200, Emilio Pozuelo Monfort wrote: > >> > >>> We need to distinguish among blockers and non-blockers in that list. E.g., > >>> "fails to run with perl 5.26" is a blocker, but "uses a deprecated > >>> feature" is > >>> not. > >> > >> Just for clarification, most of the bugs which have "deprecated" in > >> the title will fail to run with 5.26; IOW: the warnings are from > >> 5.24, and in 5.26 the issues become fatal. > > > > I've retitled those bugs would could be confusing in this regard. I > > believe that all the bugs which severity: important are the ones which > > would become RC when we decide we want to start soon. > > > > Noting for completeness that Niko has added the other lockers on > > architecture: all related FTBFS bugs as requested by Emilio. > > Thanks. Please go ahead and bump them to severity:serious as we are close to > doing this. Thanks, done. -- Niko
Bug#868341: postgis: FTBFS: *** [check] Segmentation fault
Package: postgis Version: 2.3.3+dfsg-1 Severity: serious This package fails to build on current sid/amd64. >From the build log: Run Summary:Type TotalRan Passed Failed Inactive suites 12 12n/a 00 tests 64 64 64 00 asserts 45881 45881 45881 0 n/a Elapsed time =0.584 seconds Makefile:78: recipe for target 'check' failed make[5]: *** [check] Segmentation fault (core dumped) make[5]: Leaving directory '/<>/postgis-2.3.3+dfsg/raster/test/cunit' Makefile:15: recipe for target 'core-check' failed make[4]: *** [core-check] Error 2 -- Niko Tyni nt...@debian.org
Bug#865224: uwsgi: ftbfs with multiple supported python3 versions
On Thu, Jul 13, 2017 at 06:56:52PM -0400, Scott Kitterman wrote: > On Friday, July 14, 2017 12:37:12 AM Niko Tyni wrote: > > It looks like a cdbs issue to me, > > A workaround that seems to help is putting > > X-Python3-Version: 3.5 > > in the Source paragraph of debian/control to prevent it from trying 3.6 > > at all. This makes the build work for me (but doesn't help the python3.6 > > transition of course.) > > > > This is the worst blocker for the Perl 5.26 transition too (uwsgi needs > > to be rebuilt because uwsgi-plugin-psgi links against libperl), so even > > a temporary ugly workaround would be appreciated from this side :) > > Changing the python3-all-dev build-depends to python3-dev would accomplish > the > same thing while allowing a binNMU to work when we make python3.6 default. Thanks, that's indeed even better! > Since this is blocking your work, I would recommend you NMU with that change I guess we'll look at an NMU soonish (unless Jonas wants to handle this?) -- Niko Tyni nt...@debian.org
Bug#868275: perl: add debug symbols packages
On Fri, Jul 14, 2017 at 02:25:30AM +0200, gregor herrmann wrote: > On Fri, 14 Jul 2017 09:50:15 +1000, Paul Wise wrote: > > > I have recently been getting some crashes in perl when it is running > > dpkg-architecture. I'd like to report them but there are no debug > > symbols packages for perl, it would be good to enable this. > > There's /usr/bin/debugperl in the perl-debug package, maybe that > helps? Probably not much if the dpkg-architecture crashes are infrequent and not easily reproducible. However, the detached debug symbols for /usr/bin/perl / libperl5.24 etc. are in perl-debug too and should be more useful for that case. (I see we don't mention them in the perl-debug package description but we clearly should.) See also #810327. -- Niko Tyni nt...@debian.org
Bug#865224: uwsgi: ftbfs with multiple supported python3 versions
On Fri, Jun 30, 2017 at 10:28:09PM +0200, Jonas Smedegaard wrote: > Quoting Scott Kitterman (2017-06-30 08:25:19) > > On Tue, 20 Jun 2017 11:26:35 +1200 Michael Hudson-Doyle > > wrote: > > > This may well turn out to be a cdbs bug in the end, but uwsgi does > > > not build when pysupport -r returns more than one version: > > > > > > https://launchpadlibrarian.net/323025281/buildlog_ubuntu-artful-amd64.uwsgi_2.0.15-1ubuntu3_BUILDING.txt.gz > > > > > > Picking out the failing lines: > > > > > > *** asyncio_python27 plugin built and available in > > > ./asyncio_python27_plugin.so *** > > > touch debian/stamp-uwsgi-plugin-asyncio-python > > > debian/rules:452: *** no python implementation resolved from flavor > > > "python3.6" among packages python-uwsgidecorators > > > python3-uwsgidecorators. Stop. > > > > > > In this build python 3.5 is the default and python 3.6 is supported. > > > In a build where python 3.6 is default and python 3.5 is supported, > > > the error complains about python 3.5 instead. And if python 3.6 is > > > the only supported version, the build completes successfully. So I > > > think this is really a problem in uwsgi or cdbs' handling of > > > multiple supported python versions. > > > > We now have this in Debian, so bumping to serious. > > Thanks, both for reporting initially and for bumping! It looks like a cdbs issue to me, $(call cdbs_expand_pythonruntime,,python3.6) breaks while $(call cdbs_expand_pythonruntime,,python3.5) works (and results in "python3" as expected.) A workaround that seems to help is putting X-Python3-Version: 3.5 in the Source paragraph of debian/control to prevent it from trying 3.6 at all. This makes the build work for me (but doesn't help the python3.6 transition of course.) This is the worst blocker for the Perl 5.26 transition too (uwsgi needs to be rebuilt because uwsgi-plugin-psgi links against libperl), so even a temporary ugly workaround would be appreciated from this side :) -- Niko Tyni nt...@debian.org
Bug#868253: libpoe-component-client-mpd-perl: FTBFS: test suite failures
Package: libpoe-component-client-mpd-perl Version: 2.001-1 Severity: serious This package fails to build from source on current sid due to testsuite failures. The build also hangs for me consistently, though tests.reproducible-builds.org seems to get past that every now and then. This probably regressed with the new mpd around 2017-06-19. Log excerpt (ending with a SIGINT after hanging for ten minutes or so): t/21-conn-non_mpd.t .. 1..1 ok 1 - wrong server ok Can't locate object method "duration" via package "Audio::MPD::Common::Item::Song" at /<>/blib/lib/POE/Component/Client/MPD/Connection.pm line 228. # Looks like you planned 34 tests but ran 9. t/23-conn-dialog.t ... 1..34 ok 1 - got a mpd_error event ok 2 - unknown command ok 3 - got a mpd_error event ok 4 - bad password ok 5 - got a mpd_data event ok 6 - no error message ok 7 - got a mpd_data event ok 8 - no error message ok 9 - commands return stuff Dubious, test returned 255 (wstat 65280, 0xff00) Failed 25/34 subtests [...] t/43-cmds-settings.t . 1..30 ok 1 - command 'repeat' returned an ok status ok 2 - command 'status' returned an ok status ok 3 - repeat is on ok 4 - command 'repeat' returned an ok status ok 5 - command 'status' returned an ok status ok 6 - repeat is off ok 7 - command 'repeat' returned an ok status ok 8 - command 'status' returned an ok status ok 9 - repeat is on ok 10 - command 'repeat' returned an ok status ok 11 - command 'status' returned an ok status ok 12 - repeat is off ok 13 - command 'fade' returned an ok status ok 14 - command 'status' returned an ok status ok 15 - enabling fading ok 16 - command 'fade' returned an ok status ok 17 - command 'status' returned an ok status ok 18 - disabling fading by default ok 19 - command 'random' returned an ok status ok 20 - command 'status' returned an ok status ok 21 - random is on ok 22 - command 'random' returned an ok status ok 23 - command 'status' returned an ok status ok 24 - random is off ok 25 - command 'random' returned an ok status ok 26 - command 'status' returned an ok status ok 27 - random is on ok 28 - command 'random' returned an ok status ok 29 - command 'status' returned an ok status ok 30 - random is off ok E: ABORT: Received INT signal (requesting cleanup and shutdown) -- Niko Tyni nt...@debian.org
Bug#868175: wine: FTBFS: unknown matra Bottom_And_Left at ./tools/make_unicode
Package: wine
Version: 1.8.7-2
Severity: serious
Tags: sid buster
This package fails to build on current sid.
>From the timing I'm guessing it regressed with unicode-data_10.0.0-1.
Log excerpt:
debian/rules build
dh build --parallel --with autoreconf
dh_testdir -O--parallel
dh_update_autotools_config -O--parallel
dh_autoreconf -O--parallel
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec
md5sum {} + > debian/autoreconf.before
autoreconf -f -i
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec
md5sum {} + > debian/autoreconf.after
debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
./debian/scripts/generate libs/wine/cptable.generated cpmap
./debian/scripts/generate server/trace.generated make_requests
./debian/scripts/generate server/request.generated make_requests
./tools/make_fir
size: 7907
interpolation noise: -93.68 dB
DCT: 0.50 -> 0.00 dB
DCT: 0.80 -> -0.39 dB
DCT: 1.00 -> -79.51 dB
DCT: 1.08 -> -92.28 dB
DCT: 1.18 -> -85.15 dB
DCT: 1.33 -> -89.66 dB
DCT: 1.38 -> -96.34 dB
./tools/make_unicode
unknown matra Bottom_And_Left at ./tools/make_unicode line 1226, line
684.
Loading tools/unicode-defaults
Building libs/wine/casemap.c
Building libs/wine/compose.c
Building libs/wine/wctype.c
Building dlls/usp10/mirror.c
Building dlls/dwrite/mirror.c
Building dlls/usp10/bracket.c
Building dlls/dwrite/bracket.c
Building dlls/usp10/shaping.c
Building dlls/usp10/linebreak.c
Building dlls/dwrite/linebreak.c
Building dlls/dwrite/scripts.h
Building dlls/dwrite/scripts.c
debian/rules:110: recipe for target 'override_dh_auto_configure' failed
make[1]: *** [override_dh_auto_configure] Error 25
make[1]: Leaving directory '/<>'
debian/rules:107: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
Niko Tyni nt...@debian.org
Bug#868075: libperlx-assert-perl: missing dependency on libkeyword-simple-perl | libdevel-declare-perl
Package: libperlx-assert-perl Version: 0.904-1 Severity: serious This package seems to be missing a runtime dependency on libkeyword-simple-perl | libdevel-declare-perl. % perl -e 'use PerlX::Assert' Can't locate Devel/Declare.pm in @INC (you may need to install the Devel::Declare module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/PerlX/Assert/DD.pm line 6. BEGIN failed--compilation aborted at /usr/share/perl5/PerlX/Assert/DD.pm line 6. Compilation failed in require at /usr/share/perl5/PerlX/Assert.pm line 50. BEGIN failed--compilation aborted at -e line 1 The code looks like PerlX::Assert::Keyword is used if Keyword::Simple is installed, otherwise PerlX::Assert::DD (which needs Devel::Declare.) -- Niko Tyni nt...@debian.org
Bug#868073: bioperl-run: FTBFS: t/Bowtie.t failure
Package: bioperl-run Version: 1.7.1-3 Severity: serious This package falis to build on current sid/amd64. >From the build log: - EXCEPTION - MSG: /usr/bin/bowtie call crashed: There was a problem running /usr/bin/bowtie : Encountered a space parsing the quality string for read r1 If this is a FASTQ file with integer (non-ASCII-encoded) qualities, please re-run Bowtie with the --integer-quals option. TBB Warning: Exact exception propagation is requested by application but the linked library is built without support for it Command: bowtie-align --wrapper basic-0 -l 28 -n 2 -e 70 -S --12 t/data/bowtie/reads/e_coli.cb t/data/bowtie/indexes/e_coli /tmp/Wi1GtfHq3S/B2MCI6vGnb.sam STACK Bio::Tools::Run::WrapperBase::_run /<>/blib/lib/Bio/Tools/Run/WrapperBase/CommandExts.pm:1032 STACK Bio::Tools::Run::Bowtie::run /<>/blib/lib/Bio/Tools/Run/Bowtie.pm:358 STACK toplevel t/Bowtie.t:234 - # Looks like your test exited with 29 just after 57. t/Bowtie.t 1..70 ok 1 - make a factory using command 'assemble' ok 2 - parameters changed on construction ok 3 - access parameter ok 4 - parameters_changed cleared on read ok 5 - set a param not set in constructor ok 6 - parameters_changed set ok 7 - parameter really set ok 8 - original parameter unchanged ok 9 - parameters_changed cleared on read ok 10 - change an original parameter ok 11 - parameter really changed ok 12 - reset parameters with arg ok 13 - original parameters undefined ok 14 - parameter really reset via arg ok 15 - set an exclusive group parameter ok 16 - parameter really set ok 17 - set an incompatible parameter ok 18 - parameter really set ok 19 - original exclusive parameter really unset ok 20 - parameters changed ok 21 - all available options ok 22 - available parameters ok 23 - available switches ok 24 - parameters changed ok 25 - all available options ok 26 - available parameters ok 27 - available switches ok 28 - get_parameters correct ok 29 - command attribute set ok 30 - internal command array set ok 31 - internal prefix hash set ok 32 - commands filtered by prefix ok 33 - translate_params: options correct ok 34 - make unpaired reads bowtie factory ok 35 - read raw sequence ok 36 - bowtie success ok 37 - read fasta sequence ok 38 - bowtie success ok 39 - read fastq sequence ok 40 - bowtie success ok 41 - make paired reads bowtie factory ok 42 - read paired fasta sequence ok 43 - bowtie success ok 44 - read paired fastq sequence ok 45 - bowtie success ok 46 - make a single alignment factory ok 47 - command attribute set ok 48 - seed mismatch param set ok 49 - seed length param set ok 50 - quality mismatch param set ok 51 - return type set ok 52 - make file based alignment ok 53 - make readable output ok 54 - number of alignments ok 55 - change mode ok 56 - make a crossbow alignment factory ok 57 - command attribute set Dubious, test returned 29 (wstat 7424, 0x1d00) Failed 13/70 subtests [...] Test Summary Report --- t/Bowtie.t (Wstat: 7424 Tests: 57 Failed: 0) Non-zero exit status: 29 Parse errors: Bad plan. You planned 70 tests but ran 57. Files=76, Tests=1783, 90 wallclock secs ( 0.20 usr 0.06 sys + 86.61 cusr 2.41 csys = 89.28 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#868071: ggcov: FTBFS: test failures
Package: ggcov Version: 0.9-14 Severity: serious User: reproducible-bui...@lists.alioth.debian.org This package fails to build on current sid/amd64. >From the build log: debian/rules override_dh_auto_test make[1]: Entering directory '/<>' (cd test && ./runtest) Running tests hostname: "carme" date: "20170711T194721" uname -s: "Linux" uname -m: "x86_64" uname -r: "4.9.0-3-amd64" head -1 /etc/os-release: "PRETTY_NAME="Debian GNU/Linux buster/sid"" which gcc: "/usr/bin/gcc" gcc --version: "gcc (Debian 6.4.0-1) 6.4.0 20170704" which g++: "/usr/bin/g++" g++ --version: "g++ (Debian 6.4.0-1) 6.4.0 20170704" PASS: (test000) unit tests ERROR: (test001) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test002) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test004) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test005.1) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test006) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test007) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test008.0) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test009) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test010) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test011.1) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test013) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test014) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test015.a001) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test016.1) tggcov failed, see log or re-run with -D all,verbose --no-log PASS: (test021) unit test for libpopt / fakepopt.c ERROR: (test029) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test030) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test033) tggcov failed, see log or re-run with -D all,verbose --no-log ERROR: (test034) tggcov failed, see log or re-run with -D all,verbose --no-log Total: 2/20 tests passed debian/rules:34: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 1 make[1]: Leaving directory '/<>' debian/rules:12: recipe for target 'build' failed make: *** [build] Error 2 -- Niko Tyni nt...@debian.org
Bug#868069: liburi-namespacemap-perl: unbuildable with sbuild
Package: liburi-namespacemap-perl Version: 1.00-1 Severity: serious Justification: the buildds use sbuild Building this package with sbuild on current sid fails with Installing build dependencies Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: sbuild-build-depends-liburi-namespacemap-perl-dummy : Depends: libmoo-perl (< 2.003000) but 2.003002-1 is to be installed E: Unable to correct problems, you have held broken packages. apt-get failed. E: Package installation failed The problematic build dependency reads libmoo-perl (<< 2.003000) | libsub-quote-perl while sid has libmoo-perl_2.003002-1 since 2017-06-18. I believe the issue is that sbuild only looks at the first dependency, so they need to be shuffled around now. Bother. I'm not quite sure of the severity, but I expect a source-only upload with these build dependencies would fail on the arch:all buildd. Feel free to downgrade if that turns out to be wrong. -- Niko Tyni nt...@debian.org
Bug#832127: libtest-aggregate-perl: Breaks with Test-Simple >= 1.3
On Fri, Jul 22, 2016 at 05:27:34PM +0200, gregor herrmann wrote: > Package: libtest-aggregate-perl > Version: 0.372-2 > Severity: serious > Tags: upstream > Justification: not fit for release > Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=100035 > Test::Aggregate up to 0.373 doesn't work with the new Test-Simple > (>= 1.3), in libtest-simple-perl (still in experimental but will go > into unstable soon), and in perl core since 5.25.1 (not in Debian for > another ~9 months). The new libtest-simple-perl already has a Breaks > on libtest-aggregate-perl. FWIW, this package is currently unbuildable in sid, as it has Build-Depends-Indep: [...], libtest-most-perl Build-Conflicts-Indep: [...], libtest-simple-perl (>= 1.30), perl (>= 5.25.1) while libtest-most-perl has Depends: [...], libtest-simple-perl (>= 1.302047) | perl (>= 5.25.4) -- Niko Tyni nt...@debian.org
Bug#868063: update-inetd: FTBFS: Can't exec "./update-inetd": No such file or directory
Package: update-inetd
Version: 4.44
Severity: serious
Tags: sid buster
This package fails to build on current sid/amd64.
It looks like this was broken by debconf_1.5.62.
Log excerpt:
fakeroot debian/rules binary
dh_testdir
dh_testroot
python tests.py
F
==
FAIL: testAddDisableEnableRemove (__main__.UpdateInetdTest)
--
Traceback (most recent call last):
File "tests.py", line 280, in testAddDisableEnableRemove
output = self.update_inetd("add", "'%s'" % srv_entry)
File "tests.py", line 187, in update_inetd
return run("%s --%s %s %s" % (cmdline, mode, srv, other_opts))
File "tests.py", line 86, in run
+ "\nand printed this output:\n\"%s\"") % (cmd, status, output))
AssertionError: the command "./update-inetd --file /tmp/tmpWceOqv.modified
--verbose --add 'pop-3 stream tcp nowait root
/usr/sbin/tcpd /usr/sbin/in.pop3d' " failed with exit status 65280
and printed this output:
"debconf: DbDriver "passwords" warning: could not open
/var/cache/debconf/passwords.dat: Permission denied
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
Can't exec "./update-inetd": No such file or directory at
/usr/share/perl5/Debconf/ConfModule.pm line 65.
readline() on closed filehandle GEN0 at
/usr/share/perl5/Debconf/ConfModule.pm line 78."
[...]
--
Ran 9 tests in 0.704s
FAILED (failures=9)
debian/rules:23: recipe for target 'check' failed
make: *** [check] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status
2
--
Niko Tyni nt...@debian.org
Bug#867984: libclass-load-xs-perl: FTBFS: t/012-without-implementation.t failure
Package: libclass-load-xs-perl Version: 0.09-2 Severity: serious Tags: sid buster Control: block 866389 with -1 This package fails its test suite on current sid. It looks like it broke with libtest-without-module-perl_0.20-1. # Failed test 'error when loading Class::Load and no implementation is available includes errors from trying to load modules' # at t/012-without-implementation.t line 15. # 'Could not find a suitable Class::Load implementation: Can't locate Class/Load/XS.pm in @INC (you may need to install the Class::Load::XS module) (@INC contains: CODE(0x560520488868) /<>/blib/lib /<>/blib/arch /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /usr/share/perl5/Module/Runtime.pm line 317. # Can't locate Class/Load/PP.pm in @INC (you may need to install the Class::Load::PP module) (@INC contains: CODE(0x560520488868) /<>/blib/lib /<>/blib/arch /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /usr/share/perl5/Module/Runtime.pm line 317. # at /usr/share/perl5/Class/Load.pm line 21. # Compilation failed in require at t/012-without-implementation.t line 14. # ' # doesn't match '(?^:Class.Load.PP\.pm did not return a true value)' # Looks like you failed 1 test of 1. [...] Test Summary Report --- t/012-without-implementation.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=16, Tests=127, 0 wallclock secs ( 0.03 usr 0.01 sys + 0.41 cusr 0.02 csys = 0.47 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#867983: libclass-load-perl: FTBFS: t/012-without-implementation.t failure
Package: libclass-load-perl Version: 0.23-1 Severity: serious Tags: sid buster This package fails its test suite on current sid. It looks like it broke with libtest-without-module-perl_0.20-1. # Failed test 'error when loading Class::Load and no implementation is available includes errors from trying to load modules' # at t/012-without-implementation.t line 15. # 'Could not find a suitable Class::Load implementation: Can't locate Class/Load/XS.pm in @INC (you may need to install the Class::Load::XS module) (@INC contains: CODE(0x5645284258d0) /<>/blib/lib /<>/blib/arch /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /usr/share/perl5/Module/Runtime.pm line 317. # Can't locate Class/Load/PP.pm in @INC (you may need to install the Class::Load::PP module) (@INC contains: CODE(0x5645284258d0) /<>/blib/lib /<>/blib/arch /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /usr/share/perl5/Module/Runtime.pm line 317. # at /<>/blib/lib/Class/Load.pm line 21. # Compilation failed in require at t/012-without-implementation.t line 14. # ' # doesn't match '(?^:Class.Load.PP\.pm did not return a true value)' # Looks like you failed 1 test of 1. [...] Test Summary Report --- t/012-without-implementation.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=16, Tests=127, 0 wallclock secs ( 0.04 usr 0.00 sys + 0.52 cusr 0.04 csys = 0.60 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#758100: versioned Provides reverted in src:perl for now
fixed 758100 5.24.1-5 found 758100 5.24.1-7 block 758100 with 867104 block 758100 with 867081 thanks I have reverted the versioned Provides in src:perl for now because wanna-build is leaving some packages in B-D-Uninstallable (#867104) due to no fault of their own. The versioned Provides were introduced in sid with perl_5.24.1-5 a week ago, and in the meantime a separate issue (that we could probably have lived with for a bit longer at least) was found in autopkgtest and is tracked as #867081. I'm marking both these bugs as blocking the src:perl one (#758100), and reopening that one. I'm also about to revert the corresponding change for perl/experimental so we can do the 5.26 transition without worrying about this. -- Niko Tyni nt...@debian.org
Bug#867313: perl: versioned Provides shouldn't go to testing before wanna-build is fixed
Package: perl Version: 5.24.1-5 Severity: serious As discussed in #867104, some packages are currently stuck in the 'B-D-Uninstallable' state because dose-builddebcheck is not considering a real package and a versioned virtual package coinstallable. Therefore the src:perl versioned Provides currently in sid are not suitable for release before #867104 is fixed and the fix is deployed on the wanna-build host. This bug is intended to make sure the changes don't enter testing prematurely. I'm not marking #867104 as a blocker for this as the other way to close this is to revert the versioned Provides (hopefully temporarily.) I intend do that this weekend or early next week if #867104 needs time. -- Niko Tyni nt...@debian.org
Bug#867104: wanna-build issue with src:perl versioned Provides
(Taking the debian-dpkg list in the loop and hence overquoting.) On Tue, Jul 04, 2017 at 10:18:08PM +0200, Ralf Treinen wrote: > On Tue, Jul 04, 2017 at 10:29:35PM +0300, Niko Tyni wrote: > > On Tue, Jul 04, 2017 at 09:09:37PM +0200, Ralf Treinen wrote: > > > > > thanks for having figured that out. I tend to believe that dose is right > > > in this case. Since it is not possible to install at the same > > > time two different versions of the same real package, the same should > > > IMHO hold when one is real and the other virtual. Why should this be > > > possible? > > > > Well, dpkg and apt allow it for starters. > > > > The idea with the perl packages is that the src:perl binary packages > > offer an older "stable" version of some modules while a newer version is > > packaged separately and gets installed earlier on the Perl search path > > (so it overrides the src:perl version when installed.) > > > > This has been the case for ages with the src:perl packages Providing > > an unversioned virtual package. The change here is that the virtual > > package is now versioned, which would simplify lots of dependencies > > that currently read like (for instance) > > So, that means that something like > > Depends: p (=1), p (=2) > > suddenly becomes satisfiable (when there is one real package p and > one virtual package)? Would you also allow to have the packages p > and q installed at the same time, in the following situation: > > Package: p > Version: 1 > Provides: v (=1) > > Package: q > Version: 1 > Provides: v (=2) > > If yes this seems to me a quite drastic change of the meaning of > package relations. Has this been discussed somewhere? Not that I know of. I've been just going by what works with dpkg and apt. If this is something that has only been made possible accidentally, I'll of course back up the src:perl changes. @debian-dpkg: could you please comment. -- Niko Tyni nt...@debian.org
Bug#867213: syslog-ng-incubator: FTBFS: error: unknown type name 'SBGString'
Package: syslog-ng-incubator Version: 0.5.0-4 Severity: serious Tags: sid buster Control: block 866389 with -1 This package fails to build on current sid/amd64. >From the build log: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/lua5.2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/eventlog -I/usr/include/syslog-ng -I/usr/include/eventlog -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I../../modules/lua -I./modules/lua -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c ../../modules/lua/lua-dest.c -fPIC -DPIC -o modules/lua/.libs/modules_lua_liblua_la-lua-dest.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/lua5.2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/eventlog -I/usr/include/syslog-ng -I/usr/include/eventlog -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I../../modules/lua -I./modules/lua -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c ../../modules/lua/lua-plugin.c -fPIC -DPIC -o modules/lua/.libs/modules_lua_liblua_la-lua-plugin.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/lua5.2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/eventlog -I/usr/include/syslog-ng -I/usr/include/eventlog -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I../../modules/lua -I./modules/lua -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c ../../modules/lua/lua-parser.c -fPIC -DPIC -o modules/lua/.libs/modules_lua_liblua_la-lua-parser.o ../../modules/lua/lua-dest.c: In function 'lua_dd_queue': ../../modules/lua/lua-dest.c:145:3: error: unknown type name 'SBGString' SBGString *str = sb_gstring_acquire(); ^ [...] Makefile:1839: recipe for target 'modules/lua/modules_lua_liblua_la-lua-dest.lo' failed make[2]: *** [modules/lua/modules_lua_liblua_la-lua-dest.lo] Error 1 make[2]: *** Waiting for unfinished jobs libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/lua5.2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/eventlog -I/usr/include/syslog-ng -I/usr/include/eventlog -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I../../modules/lua -I./modules/lua -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c modules/lua/lua-grammar.c -o modules/lua/modules_lua_liblua_la-lua-grammar.o >/dev/null 2>&1 make[2]: Leaving directory '/<>/debian/build-tree' Makefile:1188: recipe for target 'all' failed make[1]: *** [all] Error 2 -- Niko Tyni nt...@debian.org
Bug#867210: libtext-mecab-perl: FTBFS: test failures: Failed to create mecab instance
Package: libtext-mecab-perl Version: 0.20016-1 Severity: serious Tags: sid buster Control: block 866389 with -1 X-Debbugs-Cc: Hideki Yamane This package fails to build on current sid/amd64. This is probably related to #867173 / #866389 (mecab-jumandic-utf8 regression in sid) but I haven't verified that. Copying Hideki-san to let him know. >From the build log: t/node/02_api.t .. 1..2 ok 1 - use Text::MeCab; ok 2 - Text::MeCab::Node->can(...) ok Failed to create mecab instance at /<>/blib/lib/Text/MeCab.pm line 64. # Tests were run but no plan was declared and done_testing() was not seen. # Looks like your test exited with 2 just after 1. [...] Test Summary Report --- t/node/03_clone.t (Wstat: 512 Tests: 1 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output t/node/04_clone_free.t (Wstat: 512 Tests: 1 Failed: 0) Non-zero exit status: 2 t/node/05_format.t (Wstat: 512 Tests: 1 Failed: 0) Non-zero exit status: 2 t/tagger/03_basic.t(Wstat: 512 Tests: 1 Failed: 0) Non-zero exit status: 2 Files=10, Tests=66, 1 wallclock secs ( 0.05 usr 0.01 sys + 0.26 cusr 0.01 csys = 0.33 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#867104: wanna-build issue with src:perl versioned Provides
(dropped some cc's) On Tue, Jul 04, 2017 at 09:09:37PM +0200, Ralf Treinen wrote: > thanks for having figured that out. I tend to believe that dose is right > in this case. Since it is not possible to install at the same > time two different versions of the same real package, the same should > IMHO hold when one is real and the other virtual. Why should this be > possible? Well, dpkg and apt allow it for starters. The idea with the perl packages is that the src:perl binary packages offer an older "stable" version of some modules while a newer version is packaged separately and gets installed earlier on the Perl search path (so it overrides the src:perl version when installed.) This has been the case for ages with the src:perl packages Providing an unversioned virtual package. The change here is that the virtual package is now versioned, which would simplify lots of dependencies that currently read like (for instance) perl (>= 5.16.1) | libscalar-list-utils-perl (>= 1:1.24) -- Niko Tyni nt...@debian.org
Bug#867104: wanna-build issue with src:perl versioned Provides
Control: reassign -1 dose-builddebcheck 5.0.1-8 On Mon, Jul 03, 2017 at 10:39:55PM +0200, Kurt Roeckx wrote: > On Mon, Jul 03, 2017 at 11:21:30PM +0300, Niko Tyni wrote: > > Package: buildd.debian.org > > X-Debbugs-Cc: debian-p...@lists.debian.org > > User: debian-p...@lists.debian.org > > Usertags: versioned-provides > > > > As discussed in the thread at > > > > https://lists.debian.org/debian-devel/2017/06/msg00236.html > > https://lists.debian.org/debian-devel/2017/07/msg00026.html > > > > src:perl recently started to use versioned Provides. > > This seems to have broken wanna-build, despite #786671 being > > fixed during the stretch cycle. See for instance > > > > > > https://buildd.debian.org/status/package.php?p=libpgobject-type-datetime-perl > > https://buildd.debian.org/status/package.php?p=libtime-moment-perl > > > > where the 'dependency installibility problems' look incorrect to me > > and the build dependencies can be downloaded fine with 'apt build-dep' > > and the like. > > We have version 5.0.1-8~bpo8+1 of dose-builddebcheck installed, > while the bug indicates that it's fixed in 4.1-1. Thanks. I suppose that makes this a separate dose3 bug. Reassigning. Running "dose-builddebcheck -f -e --deb-native-arch=amd64 --checkonly libtime-moment-perl Packages Sources" on sid, with the archive files from current sid, I get the output below. The 'conflict' part looks wrong to me. output-version: 1.2 native-architecture: amd64 report: - package: libtime-moment-perl version: 0.41-1 architecture: any type: src status: broken reasons: - conflict: pkg1: package: libscalar-list-utils-perl version: 1:1.48-1 architecture: amd64 unsat-conflict: libscalar-list-utils-perl:amd64 pkg2: package: perl-base version: 5.24.1-5 architecture: amd64 essential: true depchain1: - depchain: - package: libtime-moment-perl version: 0.41-1 architecture: any type: src depends: libdatetime-perl:amd64 - package: libdatetime-perl version: 2:1.42-1 architecture: amd64 depends: libdatetime-locale-perl:amd64 (>= 1:1.06) - package: libdatetime-locale-perl version: 1:1.11-1 architecture: all depends: libscalar-list-utils-perl:amd64 (>= 1:1.45) | libscalar-list-utils-perl:amd64 (>= 1:1.45) | perl:amd64 (>= 5.25) depchain2: - depchain: - package: libtime-moment-perl version: 0.41-1 architecture: any type: src depends: libdatetime-perl:amd64 - package: libdatetime-perl version: 2:1.42-1 architecture: amd64 depends: libdatetime-locale-perl:amd64 (>= 1:1.06) - package: libdatetime-locale-perl version: 1:1.11-1 architecture: all depends: libscalar-list-utils-perl:amd64 (>= 1:1.45) | libscalar-list-utils-perl:amd64 (>= 1:1.45) | perl:amd64 (>= 5.25) - package: libscalar-list-utils-perl version: 1:1.48-1 architecture: amd64 binary-packages: 82204 source-packages: 27732 broken-packages: 1 -- Niko Tyni nt...@debian.org
Bug#867104: wanna-build issue with src:perl versioned Provides
Package: buildd.debian.org X-Debbugs-Cc: debian-p...@lists.debian.org User: debian-p...@lists.debian.org Usertags: versioned-provides As discussed in the thread at https://lists.debian.org/debian-devel/2017/06/msg00236.html https://lists.debian.org/debian-devel/2017/07/msg00026.html src:perl recently started to use versioned Provides. This seems to have broken wanna-build, despite #786671 being fixed during the stretch cycle. See for instance https://buildd.debian.org/status/package.php?p=libpgobject-type-datetime-perl https://buildd.debian.org/status/package.php?p=libtime-moment-perl where the 'dependency installibility problems' look incorrect to me and the build dependencies can be downloaded fine with 'apt build-dep' and the like. Do you think this is fixable? Should I be looking at reverting the versioned Provides change for now? Maybe it's "just" the wanna-build host still running jessie and not stretch? Copying the debian-perl list as multiple perl packages are affected. Example copy-paste below. The perl-base/5.24.1-5 package currently Breaks: libscalar-list-utils-perl (<< 1:1.42.02) Replaces: libscalar-list-utils-perl (<< 1:1.42.02) Provides: libscalar-list-utils-perl (= 1:1.42.02) and the change that triggered this was moving from traditional unversioned Provides. Dependency installability problem for libtime-moment-perl on arm64: libtime-moment-perl build-depends on: - libdatetime-perl:arm64 libdatetime-perl depends on: - libdatetime-locale-perl:arm64 (>= 1:1.06) libdatetime-locale-perl depends on: - libscalar-list-utils-perl:arm64 (>= 1:1.45) | libscalar-list-utils-perl:arm64 (>= 1:1.45) | perl:arm64 (>= 5.25) libtime-moment-perl build-depends on: - libdatetime-perl:arm64 libdatetime-perl depends on: - libdatetime-locale-perl:arm64 (>= 1:1.06) libdatetime-locale-perl depends on: - libscalar-list-utils-perl:arm64 (>= 1:1.45) | libscalar-list-utils-perl:arm64 (>= 1:1.45) | perl:arm64 (>= 5.25) libscalar-list-utils-perl depends on: - libscalar-list-utils-perl conflicts with: - libscalar-list-utils-perl:arm64 -- Niko Tyni nt...@debian.org
Bug#867089: perl: libperl5.22 and libperl5.24 no longer coinstallable
Package: perl Version: 5.24.1-5 The libperl5.24 package is no longer coinstallable with the libperl5.22 package that used to be in sid + stretch. This is because the old libperl5.22 / perl-modules-5.22 packages have Breaks: libautodie-perl (<< 2.29-2) Replaces: libautodie-perl (<< 2.29-2) Provides: libautodie-perl while the 5.24 ones have Breaks: libautodie-perl (<< 2.29-2) Replaces: libautodie-perl (<< 2.29-2) Provides: libautodie-perl (= 2.29) so the 5.24 Provides is lower than the 5.22 (and 5.24!) Breaks. I'm not quite sure how the current situation works even in sid, with the package breaking itself. This weirdish situation happens because we patched autodie in the 5.22 cycle and wanted to make sure unpatched separate packages can't be installed over it, so we bumped the Breaks entry from 2.26 to 2.29-2. The fix is probably to Provide libautodie-perl (= 2.29-2) in the 5.24 packages. (I wonder what kind of testing would have spotted this, given libperl5.22 is no longer in any Debian suite. Going forward, we will want to ensure at least that libperl5.x in sid is always coinstallable with libperl5.y in stable.) -- Niko Tyni nt...@debian.org
Bug#867081: autopkgtest: @ no longer pulls in packages with versioned Provides
Package: autopkgtest Version: 4.4 User: debian-p...@lists.debian.org Usertags: versioned-provides X-Debbugs-Cc: debian-p...@lists.debian.org As seen on ci.debian.net with for instance libhttp-tiny-perl and libcpan-meta-perl, autopkgtest gets confused about versioned Provides that were introduced in sid recently with perl_5.24.1-5. It looks like "Depends: @" will no longer pull in the binary packages to be tested if the same name is also Provided by installed packages with a version. My reading of the autopkgtest code is that it synthesizes a dependency on 'package (>= 0~)', where the versioning is assumed to guarantee that only a real package gets pulled in. This assumption no longer holds with versioned Provides. Maybe it would work to have _debian_packages_from_source dig the actual package version from debian/changelog and set the dependency to 'package (= version)' instead? Copying the debian-perl@ list as multiple perl packages are affected. -- Niko Tyni nt...@debian.org
Bug#866991: libcpan-meta-perl: uninstallable in unstable
On Mon, Jul 03, 2017 at 06:07:28PM +0200, gregor herrmann wrote: > I see two possibilities: > - lower the version in the Replaces/Breaks to <= 1.4414-1, as that's > the last separateky packaged version un Debian; not as > "theoretically clean" as breaking the "real" version but should be > safe within the Debian universe and allows us to fix this now; > - wait a couple of weeks: when perl 5.26 enters unstable this > problems fixes itself; but then the version in Breaks/Replaces and > Provides is still arbitrary/wrong. > > I tend to prefer the first solution but I'm happy to hear about > others. I'd go with lowering the version. The other one is not much of a fix :) > For convenience, here's the diff which I just pushed to the git repo > on Alioth (with a slightly different version to also catch > theoretical 1.4414-1+localsomething versions): Oh there's versioned Provides here too! The diff looks OK to me fwiw. We might want to automatically calculate the Provided version from the main version as it looks like they're synced nowadays. Otherwise the Provided version will probably start lagging when people don't notice it while importing new upstream releases. -- Niko
Bug#866991: libcpan-meta-perl: uninstallable in unstable
On Mon, Jul 03, 2017 at 11:56:57AM +0200, Sven Joachim wrote: > On 2017-07-03 11:41 +0200, Sven Joachim wrote: > > > Package: libcpan-meta-perl > > Version: 2.150010-1 > > Tags: buster sid > > Severity: serious > > > > After the switch to versioned Provides in perl, libcpan-meta-perl has > > become uninstallable. This happens with perl-modules-5.24 5.24.1-5 > > installed on the system: > > Short analysis: > > > > - libcpan-meta-perl depends on perl which depends on perl-modules-5.24 > > - libcpan-meta-perl breaks libparse-cpan-meta-perl (<< 1.4420) > > - perl-modules-5.24 provides libparse-cpan-meta-perl (= 1.4417.001) > > > > => libcpan-meta-perl both depends on and breaks perl-modules-5.24. > > I suspect the solution here is to lower the Breaks on > libparse-cpan-meta-perl to (<< 1.4417) or similar, since there is no > separate libparse-cpan-meta-perl package anymore (the last version in > Debian was 1.4414-1, removed[1] in 2015), and libcpan-meta-perl already > provides libparse-cpan-meta-perl itself. Thanks. Lowering the Breaks seems OK to me though I haven't looked at this very deeply yet. Assuming the Breaks is mainly about file conflicts, even (<= 1.4414-1) would probably be OK. We're somewhat lucky in this case to have that option available; the general case of a merge of separate packages in sid would probably be harder. -- Niko Tyni nt...@debian.org
Bug#866944: libmecab-perl: FTBFS: no such file or directory: /var/lib/mecab/dic/debian/dicrc
Package: libmecab-perl Version: 0.99.6-1 Severity: serious Tags: sid buster Control: block 866389 with -1 X-Debbugs-Cc: mecab-juman...@packages.debian.org, mecab-ut...@packages.debian.org This package fails to build on current sid/amd64. dh_auto_test make -j1 test TEST_VERBOSE=1 make[1]: Entering directory '/<>' Running Mkbootstrap for MeCab () chmod 644 "MeCab.bs" PERL_DL_NONLAZY=1 PERL_USE_UNSAFE_INC=1 "/usr/bin/perl" "-Iblib/lib" "-Iblib/arch" test.pl RuntimeError param.cpp(69) [ifs] no such file or directory: /var/lib/mecab/dic/debian/dicrc 0.996 Makefile:985: recipe for target 'test_dynamic' failed make[1]: *** [test_dynamic] Error 2 make[1]: Leaving directory '/<>' dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2 debian/rules:4: recipe for target 'build' failed make: *** [build] Error 2 This seems to have been broken by the new version of src:mecab-jumandic in unstable. It looks like the mecab-utils programs in /usr/lib/mecab/ need /var/lib/mecab/dic/debian/dicrc : # /usr/lib/mecab/mecab-dict-index dictionary_compiler.cpp(82) [param.load(DCONF(DICRC))] no such file or directory: ./dicrc # /usr/lib/mecab/mecab-dict-gen dictionary_generator.cpp(212) [param.load(DCONF(DICRC))] no such file or directory: ./dicrc Copying the maintainers. -- Niko Tyni nt...@debian.org
Bug#866934: libhttp-oai-perl: /usr/bin/oai_pmh uses the 'encoding' pragma, breaks with Perl 5.26
Package: libhttp-oai-perl Version: 4.03-2 Severity: important User: debian-p...@lists.debian.org Usertags: perl-5.26-transition The /usr/bin/oai_pmh program does "use encoding 'utf8';", which has been deprecated since Perl 5.18 and breaks with Perl 5.26 (currently in experimental.) % oai_pmh The encoding pragma is no longer supported at /usr/bin/oai_pmh line 3. BEGIN failed--compilation aborted at /usr/bin/oai_pmh line 3. -- Niko Tyni nt...@debian.org
Bug#826506: tiarra: Unescaped left brace in regex is deprecated
severity 826506 important
user debian-p...@lists.debian.org
usertags 826506 + perl-5.26-transition
thanks
On Sun, Jun 05, 2016 at 10:43:28PM +0300, Niko Tyni wrote:
> Package: tiarra
> Version: 20100212+r39209-1
> Severity: minor
> User: debian-p...@lists.debian.org
> Usertags: perl-5.24-transition
>
> Building this package triggers deprecation warnings with Perl 5.24
> (currently in experimental), and probably with Perl 5.22 (current sid)
> too.
>
> Unescaped left brace in regex is deprecated, passed through in regex;
> marked by <-- HERE in m/\%PRE{ <-- HERE (.+?)}ERP\%/ at
> main/Configuration/Preprocessor.pm line 168.
> Unescaped left brace in regex is deprecated, passed through in regex;
> marked by <-- HERE in m/\%CODE{ <-- HERE (. *?)}EDOC\%/ at
> main/Configuration/Block.pm line 143.
This is fatal in Perl 5.26 (currently in experimental), making
the debian/handle_version.pl invocation fail. It doesn't make
the build fail, though.
Raising to 'important', but I guess this shouldn't block the Perl 5.26
transition.
A full build log is available at
http://perl.debian.net/rebuild-logs/perl-5.26-throwaway/tiarra_20100212%2Br39209-1/tiarra_20100212%2Br39209-1_amd64-2017-05-21T08%3A05%3A56Z.build
and the server also hosts an unofficial repository of packages binNMU'd for Perl
5.26 that can be used for testing purposes; see <http://perl.debian.net/>.
--
Niko Tyni nt...@debian.org
Bug#826448: libsyntax-highlight-engine-simple-languages-perl: Use of the encoding pragma is deprecated
severity 826448 important user debian-p...@lists.debian.org usertags 826448 + perl-5.26-transition thanks On Sun, Jun 05, 2016 at 07:26:58PM +0300, Niko Tyni wrote: > Package: libsyntax-highlight-engine-simple-languages-perl > Version: 2 > Severity: minor > User: debian-p...@lists.debian.org > Usertags: perl-5.24-transition > > Building this package triggers deprecation warnings with Perl 5.24 > (currently in experimental): > > Use of the encoding pragma is deprecated at t/highlight.t line 5. > > A full build log is available at > > http://perl.debian.net/rebuild-logs/perl-5.24-throwaway/libsyntax-highlight-engine-simple-languages-perl_2/ This is fatal in Perl 5.26 (currently in experimental), making the test suite fail. However, the package still builds, probably because the for loop in debian/rules doesn't abort on errors. Raising to 'important', but I guess this shouldn't block the transition. A full build log is available at http://perl.debian.net/rebuild-logs/perl-5.26-throwaway/libsyntax-highlight-engine-simple-languages-perl_2/libsyntax-highlight-engine-simple-languages-perl_2_amd64-2017-05-21T14%3A41%3A50Z.build and the server also hosts an unofficial repository of packages binNMU'd for Perl 5.26 that can be used for testing purposes; see <http://perl.debian.net/>. -- Niko Tyni nt...@debian.org
Bug#866389: transition: perl 5.26
On Thu, Jun 29, 2017 at 04:39:21PM +0100, Dominic Hargreaves wrote: > On Thu, Jun 29, 2017 at 03:07:39PM +0300, Niko Tyni wrote: > > Package: release.debian.org > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: debian-p...@lists.debian.org > > > > We'd like to get Perl 5.26 in sid/buster soonish. > > > > As usual, we've done test rebuilds of packages build dependending on perl. > > Things are looking pretty good. Known issues are at > > > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.26-transition;users=debian-p...@lists.debian.org > > > > and should be marked as blockers of this bug next. > > Previously we only used blockers to track FTBFS in packages needing > binNMUing - so far I have just added those. I think it probably makes > sense to keep with that, as the above link give you the full picture > when needed. Fine by me of course. Should we also mark possible unrelated sid FTBFS bugs of those packages as blockers? ISTR us doing that in the past. (I'm not aware of any such bugs at the moment, but we should probably do one more full binNMU test rebuild sweep in addition of the incremental ones we're doing currently.) -- Niko
Bug#866389: transition: perl 5.26
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-p...@lists.debian.org We'd like to get Perl 5.26 in sid/buster soonish. As usual, we've done test rebuilds of packages build dependending on perl. Things are looking pretty good. Known issues are at https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.26-transition;users=debian-p...@lists.debian.org and should be marked as blockers of this bug next. We'll ping this bug when things are ready, but please let us know if you have any preference about the timing. It might be prudent to decouple the move to versioned Provides (see #758100 and the thread at [1]) from the rest of the transition and do it with 5.24 in sid first. I hope to have time for that next week. [1] https://lists.debian.org/debian-devel/2017/06/msg00236.html -- Niko Tyni nt...@debian.org
Bug#866321: frozen-bubble: uses deprecated POSIX::tmpnam()
Package: frozen-bubble
Version: 2.212-7
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.26-transition
This package uses POSIX::tmpnam(), deprecated in Perl 5.22
and removed in 5.26 (currently in experimental.)
/usr/games/frozen-bubble:6024:do { $filename = POSIX::tmpnam() }
It looks like this is in the '--replay' code path and not the
game itself, so filing at 'normal' for now.
--
Niko Tyni nt...@debian.org
Bug#866320: libspreadsheet-writeexcel-perl: uses deprecated POSIX::tmpnam()
Package: libspreadsheet-writeexcel-perl Version: 2.40-1 Severity: normal User: debian-p...@lists.debian.org Usertags: perl-5.26-transition This package uses POSIX::tmpnam(), deprecated in Perl 5.22 and removed in 5.26 (currently in experimental.) lib/Spreadsheet/WriteExcel/Workbook.pm:$tmp_dir = "POSIX::tmpnam() directory" if not $fh; lib/Spreadsheet/WriteExcel/Worksheet.pm:$tmp_dir = "POSIX::tmpnam() directory" if not $fh; It looks like this is fallback code that might not be active so filing at 'normal' for now. -- Niko Tyni nt...@debian.org
Bug#866317: html2ps: relies on deprecated Perl syntax/features, breaks with 5.26
Package: html2ps
Version: 1.0b7-1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.26-transition
In addition to the $[ deprecation (#740782), this package also relies
on other deprecated Perl features. These will become fatal in
Perl 5.26, currently in experimental.
% html2ps /dev/null >/dev/null
Use of assignment to $[ is deprecated at /usr/bin/html2ps line 3409.
Unescaped left brace in regex is deprecated, passed through in regex; marked
by <-- HERE in m//DH { <-- HERE / at /usr/bin/html2ps line 3834.
Unescaped left brace in regex is deprecated, passed through in regex; marked
by <-- HERE in m/\\patterns{ <-- HERE .*/ at /usr/bin/html2ps line 4085.
Calling POSIX::tmpnam() is deprecated at /usr/bin/html2ps line 497.
--
Niko Tyni nt...@debian.org
Bug#866315: libgcj-common: dh_nativejava uses deprecated POSIX::tmpnam()
Package: libgcj-common Version: 1:6.3-4 Severity: important User: debian-p...@lists.debian.org Usertags: perl-5.26-transition The dh_nativejava program uses POSIX::tmpnam(), which was deprecated in Perl 5.22.and is removed in Perl 5.26 (currently in experimental.) Please use File::Temp instead. -- Niko Tyni nt...@debian.org
Bug#866312: mutt: mailspell uses deprecated POSIX::tmpnam()
Package: mutt Version: 1.8.3+neomutt20170609-2 Severity: normal User: debian-p...@lists.debian.org Usertags: perl-5.26-transition The mailspell helper uses POSIX::tmpnam(), which was deprecated in Perl 5.22.and is removed in Perl 5.26 (currently in experimental.) % /usr/lib/mutt/mailspell /dev/null Calling POSIX::tmpnam() is deprecated at /usr/lib/mutt/mailspell line 37. Please use File::Temp instead. -- Niko Tyni nt...@debian.org
Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select
On Sun, Jun 25, 2017 at 11:37:13PM +0100, Colin Watson wrote: > I could arrange for the relevant grub2 postinst scripts to remove > /etc/default/grub.d/init-select.cfg entirely when appropriate conditions > apply. In addition to a self-defence argument, this is further > justified by the fact that grub2 now provides a similar facility of its > own as of 2.02~beta2-20: if other init daemons are installed, then > grub-mkconfig generates additional menu items for them (although there > are no arrangements to migrate the default choice from > /etc/default/init). This would still violate policy §10.7.3/10.7.4, > although it seems to be the favoured option of the debian-devel thread, > and it is the least bad option I can see so far. I also think this is acceptable. As init-select is gone from stretch and sid, and particularly given the other circumstances, I think you should feel free to take over management of the offending conffile that used your extension facility. Viewed this way, I'm not sure there's an inherent policy violation here at all (assuming you only remove the file if it's unmodified etc.) All you're doing is adopting a configuration file and removing it on upgrade as obsolete. Obviously moving configuration files should only be done between cooperative packages and hostile takeovers are not OK, but that's not an issue here. If init-select actually had a future in sid/buster, things would be a bit messier I think... As for possible policy changes, this seems such a corner case to me that they'd be a bit overkill. But I'm certainly not opposing such changes. -- Niko Tyni nt...@debian.org
Bug#864770: jessie-pu: package libapache2-mod-perl2/2.0.9~1624218-2+deb8u2
On Tue, Jun 27, 2017 at 06:27:00AM +0200, Cyril Brulebois wrote: > Control: tag -1 confirmed > > Niko Tyni (2017-06-14): > > The changes in apache2_2.4.10-10+deb8u8 related to CVE-2016-8743 > > caused libapache2-mod-perl2 to start failing its test suite, as > > seen in #864316. > > > > The attached debdiff fixes this by amending the test suite. The > > changes are identical to those we made in stretch/sid for #849082. > > > > Please let me know if it's OK to upload to jessie. > > Looks good to me, feel free to upload. Thanks, uploaded. > (I was amused by the http vs. HTTP one. ;)) Yeah, me too :) -- Niko
Bug#865563: libcatmandu-sru-perl FTBFS: test failures
On Mon, Jun 26, 2017 at 10:50:33PM +0300, Niko Tyni wrote: > On Mon, Jun 26, 2017 at 08:36:41PM +0200, gregor herrmann wrote: > > > Hm. Is there a difference between: > > perl -I. Build.PL # debhelper > > perl Build.PL -I. # cdbs > > Yes, there seems to be. I note that Dominic's patch in #833783 proposed the first style, but what got applied in cdbs.git [0] was the second one. [0] https://anonscm.debian.org/cgit/build-common/cdbs.git/commit/?id=30673973dce32433e62f03e7dba7cef59d73 So this seems to be mostly a cdbs bug? -- Niko Tyni nt...@debian.org
Bug#865563: libcatmandu-sru-perl FTBFS: test failures
On Mon, Jun 26, 2017 at 08:36:41PM +0200, gregor herrmann wrote:
> Hm. Is there a difference between:
> perl -I. Build.PL # debhelper
> perl Build.PL -I. # cdbs
Yes, there seems to be.
The essential part of the diff of the generated Build files
from debhelper style to cdbs style is:
@@ -31,7 +31,7 @@ BEGIN {
}
unshift @INC,
(
- '.'
+
);
}
--
Niko Tyni nt...@debian.org
Bug#865563: libcatmandu-sru-perl FTBFS: test failures
On Sun, Jun 25, 2017 at 09:57:14PM +0300, Niko Tyni wrote: > On Fri, Jun 23, 2017 at 09:19:43PM +0100, Dominic Hargreaves wrote: > > I feel like we should try and not diverge further from upstream; that > > seems almost guaranteed to end up with similar issues later. > > FWIW, I've scheduled a test rebuild of all the 679 libmodule-build-perl > reverse build dependencies on perl.debian.net to get a feeling of > how widespread this issue actually is. Not that widespread. We have 12 clearly affected packages, and a couple that I'm not sure of. See below. Logs can be found at http://perl.debian.net/rebuild-logs/experimental/report.html (it's really a sid chroot, don't mind the "experimental" part.) > If it's bad enough, we should probably patch around it temporarily > in any case and drop it later in a more controlled fashion. Given the low number of broken packages, it does look feasible to fix those instead. I have no strong opinion atm. Others? Affected packages: libtest-name-fromline-perl_0.13-1 libregexp-log-perl_0.06-3 libperl-critic-perl_1.126-1 libparser-mgc-perl_0.15-1 libnet-proxy-perl_0.12-6 libmoox-options-perl_4.023-1 libjson-webtoken-perl_0.10-2 libfurl-perl_3.08-2 libdevel-callparser-perl_0.002-3 libdevel-callchecker-perl_0.007-1 libcatmandu-sru-perl_0.039-1 libcatmandu-perl_1.0304-2 Uncertain, could be caused by something else: libconfig-model-itself-perl_2.006-1 bioperl-run_1.7.1-3 -- Niko Tyni nt...@debian.org
Bug#826505: swissknife: Unescaped left brace in regex is deprecated
Control: tag -1 patch
On Sun, Jun 18, 2017 at 11:21:10PM +0300, Niko Tyni wrote:
> On Sun, Jun 05, 2016 at 10:41:41PM +0300, Niko Tyni wrote:
> > Package: swissknife
> > Version: 1.67-1.1
> > Severity: normal
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.24-transition
> >
> > Building this package triggers deprecation warnings with Perl 5.24
> > (currently in experimental), and probably with Perl 5.22 (current sid)
> > too.
> >
> > Unescaped left brace in regex is deprecated, passed through in regex;
> > marked by <-- HERE in m/^(\S{ <-- HERE 0,-1}/|-(?![>\-]))/ at
> > /<>/blib/lib/SWISS/TextFunc.pm line 196, chunk 25.
> > Unescaped left brace in regex is deprecated, passed through in regex;
> > marked by <-- HERE in m/^(\S{ <-- HERE 0,-1}(? > )-(?=[A-Za-z0-9\(\[]))/ at /<>/blib/lib/SWISS/TextFunc.pm line
> > 196, chunk 25.
>
> This is fatal in Perl 5.26 (currently in experimental), making the
> package fail to build from source. Raising the severity accordingly.
The first pattern reads
/^(\S{0,$w1}$separators[$j])/
It looks like the curly brace is not intended as a literal, but rather
to put together a quantifier so it matches 0 to $w1 non-whitespace
characters.
Somewhat interestingly, this is legal as long as $w1 >= 0. However, if it
goes negative the regexp code sees that {0,-1} can not be a quantifier
and decides that it must be a literal instead, causing warnings / fatal
runtime errors.
So this seems to have been a longstanding hidden bug in the code.
I'm attaching two proposed patches, one for this and the other for
a similar, related warning that was only introduced Perl 5.26. I've
tested that the package builds with these on both sid and with Perl
5.26 from experimental, but I'm not sure at all whether it still works
as intended. But at least the test suite passes now.
I see there have been quite a few new upstream releases but the last (and
only) maintainer upload was in 2009. Steffen, are you still maintaining
this package? Is it worth patching or should it rather be removed?
--
Niko Tyni nt...@debian.org
>From 916994ccaa72399f9f2d3fad41f439ec393d23ce Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Sun, 25 Jun 2017 20:40:06 +
Subject: [PATCH 1/2] Fix broken regexp quantifiers
When $w1 is negative, the regexp parser sees that {0,-1} can not
be a quantifier so it parses it as a literal instead. This does
not seem to be the intended behaviour.
Only try the match with nonnegative numbers, and short-circuit
to 'no match' otherwise.
Bug-Debian: https://bugs.debian.org/826505
---
lib/SWISS/TextFunc.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/SWISS/TextFunc.pm b/lib/SWISS/TextFunc.pm
index 5a340cd..47641a1 100644
--- a/lib/SWISS/TextFunc.pm
+++ b/lib/SWISS/TextFunc.pm
@@ -193,7 +193,7 @@ sub wrapOn {
# of length 1 ($sepLength = 1)
my $sepLength = 1;
my $w1 = $cutPos - $sepLength;
- if ($postMatch =~ /^(\S{0,$w1}$separators[$j])/) {
+ if ($w1 >= 0 and $postMatch =~ /^(\S{0,$w1}$separators[$j])/) {
$cutPos = length($1);
last;
}
--
2.13.1
>From 0f6c9ea418bcdf7650ff3ede46a7bd44e8da6783 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Sun, 25 Jun 2017 20:43:55 +
Subject: [PATCH 2/2] Fix regexp quoting
When $tag starts with a left brace, the interpolation will result
in a warning about an unenscaped left brace starting with Perl 5.26.
Presumably any regexp meta characters in $tag are intended to be
used as literals, so guard the interpolation with \Q...\E.
---
lib/SWISS/BaseClass.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/SWISS/BaseClass.pm b/lib/SWISS/BaseClass.pm
index 34ce34d..ae76059 100644
--- a/lib/SWISS/BaseClass.pm
+++ b/lib/SWISS/BaseClass.pm
@@ -168,7 +168,7 @@ sub setEvidenceTags {
sub addEvidenceTag {
my $self = shift;
my $tag = shift;
- unless ($self->{'evidenceTags'} =~ /[\{\,]$tag[\}\,]/) {
+ unless ($self->{'evidenceTags'} =~ /[\{\,]\Q$tag\E[\}\,]/) {
if ($self->{'evidenceTags'} eq '{}') {
$self->{'evidenceTags'} = '{' . $tag . '}';
} else {
--
2.13.1
Bug#865563: libcatmandu-sru-perl FTBFS: test failures
On Fri, Jun 23, 2017 at 09:19:43PM +0100, Dominic Hargreaves wrote: > On Fri, Jun 23, 2017 at 07:43:52PM +0200, gregor herrmann wrote: > > So it looks like we really need PERL_USE_UNSAFE_INC, and we might > > want to insert it unconditionally manually where we did prior to the > > accidental removal in the last upload. > It does rather look like a mistaken attempt to solve this problem, and > I agree that the logic is a bit odd, but this seems like the patch > likely to get accepted upstream; can you send this patch to the module > author? > > I feel like we should try and not diverge further from upstream; that > seems almost guaranteed to end up with similar issues later. FWIW, I've scheduled a test rebuild of all the 679 libmodule-build-perl reverse build dependencies on perl.debian.net to get a feeling of how widespread this issue actually is. If it's bad enough, we should probably patch around it temporarily in any case and drop it later in a more controlled fashion. I'll follow up with an update once we have results. -- Niko
Bug#826502: quilt: Unescaped left brace in regex is deprecated
Control: tag -1 patch
On Sun, Jun 18, 2017 at 11:24:13PM +0300, Niko Tyni wrote:
> On Sun, Jun 05, 2016 at 10:35:06PM +0300, Niko Tyni wrote:
> > Package: quilt
> > Version: 0.63-3
> > Severity: normal
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.24-transition
> >
> > Building this package triggers deprecation warnings with Perl 5.24
> > (currently in experimental), and probably with Perl 5.22 (current sid)
> > too.
> >
> > perl -pe 'if (/\\sh{.*}/) {s:\\sh{(.*)}:$1:}'\
> >< doc/tmp/main.html > doc/quilt.html
> > Unescaped left brace in regex is deprecated, passed through in regex;
> > marked by <-- HERE in m/\\sh{ <-- HERE .*}/ at -e line 1.
> This is fatal in Perl 5.26 (currently in experimental), making the
> package fail to build from source. Raising the severity accordingly.
The bits in test/run were apparently fixed in 0.63-4 without a mention
on this bug, but the one in debian/rules remains. Trivial patch
attached. I've verified that this fixes builds with Perl 5.26 without
breaking them on current sid.
--
Niko Tyni nt...@debian.org
>From e40c76cf84f372440cf2715bbd77e9e0ee764ab5 Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Sun, 25 Jun 2017 18:23:47 +
Subject: [PATCH] debian/rules: fix deprecated Perl usage
Unescaped left braces in regexps were deprecated in Perl 5.22 and
became unsupported in 5.26.
Closes: #826502
---
debian/rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index 19b680f..dbd2a7c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -24,7 +24,7 @@ override_dh_auto_build:
mkdir -p doc/tmp
ifeq (,$(findstring stage1,$(DEB_BUILD_PROFILES)))
cd doc/tmp; LC_ALL=C hevea ../main.tex ; LC_ALL=C hevea ../main.tex; LC_ALL=C hevea ../main.tex
- perl -pe 'if (/\\sh{.*}/) {s:\\sh{(.*)}:$$1:}' \
+ perl -pe 'if (/\\sh\{.*}/) {s:\\sh\{(.*)}:$$1:}' \
< doc/tmp/main.html > doc/quilt.html
LC_ALL=C perl -e '$$/ = undef; $$f=<>; $$f =~ s|]*?HREF="[^"]*#[^"]*">(.*?)|$$1|msg; print $$f;' < doc/tmp/main.html > doc/tmp/tmp.html
LC_ALL=C lynx doc/tmp/tmp.html -dump > doc/quilt.txt
--
2.13.1
Bug#865888: nagios-plugin-check-multi: FTBFS with Perl 5.26: Unescaped left brace in regex is deprecated here
On Sun, Jun 25, 2017 at 06:54:59PM +0300, Niko Tyni wrote:
> Package: nagios-plugin-check-multi
> Version: 0.26-3
> Severity: important
> User: debian-p...@lists.debian.org
> Usertags: perl-5.26-transition
>
> This package fails to build with Perl 5.26 (currently in experimental.)
> # 'Unescaped left brace in regex is deprecated here (and
> will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in
> m/^${ <-- HERE NAGIOS}/ at ../check_multi line 1377.
Just a note that while there was a very similar deprecation phase in Perl
5.22, this one is new with Perl 5.26. The earlier check was slightly
buggy and failed to warn in some cases where it should have.
So the current unescaped-left-brace-in-regex.patch isn't quite
sufficient unfortunately.
See
http://search.cpan.org/dist/perl-5.26.0/pod/perldelta.pod#Unescaped_literal_%22{%22_characters_in_regular_expression_patterns_are_no_longer_permissible
--
Niko Tyni nt...@debian.org
Bug#809352: Unescaped left brace in regex is deprecated
Control: affects -1 src:pacpl
Control: affects -1 src:libaudio-file-perl
Control: tag -1 + fixed-upstream
On Sun, Jun 18, 2017 at 11:28:41PM +0300, Niko Tyni wrote:
> On Tue, Dec 29, 2015 at 07:52:51PM +0100, Harald Dunkel wrote:
> > Package: libmp3-tag-perl
> > Version: 1.13-1
> >
> > perl 5.22.1-3 woes about some code in /usr/share/perl5/MP3/Tag.pm:
> >
> > Unescaped left brace in regex is deprecated, passed through in regex;
> > marked by
> > <-- HERE in m/(\\%(?:\\=)?(\w|\\{ <-- HERE
> > (?:\w|\\[^\w\\{}]|\\[\\{}])*\\}|\\\W))/ at /usr/share/perl5/MP3/Tag.pm
> > line 2611 (#1)
>
> This is fatal in Perl 5.26 (currently in experimental), making the
> package fail to build from source. Raising the severity accordingly.
This also breaks the build of src:papl and src:libaudio-file-perl
with Perl 5.26. It's fixed upstream in 1.14.
Ian, are you still maintaining this package? Would you be OK with
moving this under the pkg-perl umbrella?
--
Niko Tyni nt...@debian.org
Bug#865898: perl: EU::MM regression in 5.26 breaks erlsvc build
Package: perl Version: 5.26.0-1 Severity: important User: debian-p...@lists.debian.org Usertags: perl-5.26-transition Forwarded: https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/305 Affects: erlsvc X-Debbugs-Cc: erl...@packages.debian.org It looks like a regression in recent versions of ExtUtils-MakeMaker, including the one bundled with Perl 5.26.0 currently in experimental, broke the erlsvc build. I'm copying the erlsvc maintainer FYI, but it's not yet clear where this needs to be fixed. A full build log is at http://perl.debian.net/rebuild-logs/perl-5.26-throwaway/erlsvc_1.02-2/erlsvc_1.02-2_amd64-2017-05-22T00:32:44Z.build and the failure mode is dh_auto_test make -j1 test TEST_VERBOSE=1 make[1]: Entering directory '/<>' make[2]: Entering directory '/<>/share' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/<>/share' make[2]: Entering directory '/<>/share' make[2]: *** No rule to make target 'test_dynamic'. Stop. make[2]: Leaving directory '/<>/share' Makefile:918: recipe for target 'subdirs-test_dynamic' failed make[1]: *** [subdirs-test_dynamic] Error 2 make[1]: Leaving directory '/<>' dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2 debian/rules:4: recipe for target 'build' failed As noted in the upstream bug, I've bisected that this started with https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/0c38f3739cb7476fc1b843484584fee30c9ea69e and still happens with current HEAD. -- Niko Tyni nt...@debian.org
Bug#865033: libsolv: FTBFS with Perl 5.26: swig error: lvalue required as left operand of assignment
Control: tag -1 patch fixed-upstream
On Sun, Jun 18, 2017 at 10:34:21PM +0300, Niko Tyni wrote:
> Package: libsolv
> Version: 0.6.24-1
> Severity: important
> User: debian-p...@lists.debian.org
> Usertags: perl-5.26-transition
>
> This package fails to build with Perl 5.26 (currently in experimental.)
This is fixed upstream by
https://github.com/openSUSE/libsolv/commit/75fa844d8c3658c01b286f5c72d87fce373cfe0b
Patch attached for completeness.
I've verified that this fixes 5.26 builds without breaking on sid.
--
Niko Tyni nt...@debian.org
>From 75fa844d8c3658c01b286f5c72d87fce373cfe0b Mon Sep 17 00:00:00 2001
From: Michael Schroeder
Date: Mon, 19 Jun 2017 11:09:43 +0200
Subject: [PATCH] Add conditionals for swig perl bug workaround
It was fixed in swig-2.0.5 and gets in the way with newer perl
versions.
---
bindings/solv.i | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/bindings/solv.i b/bindings/solv.i
index 043c549..354cde7 100644
--- a/bindings/solv.i
+++ b/bindings/solv.i
@@ -330,7 +330,8 @@ typedef struct {
#if defined(SWIGPERL)
-/* work around a swig bug */
+/* work around a swig bug for swig versions < 2.0.5 */
+#if SWIG_VERSION < 0x020005
%{
#undef SWIG_CALLXS
#ifdef PERL_OBJECT
@@ -343,6 +344,7 @@ typedef struct {
# endif
#endif
%}
+#endif
%define perliter(class)
--
2.11.0
Bug#865893: libtest-simple-perl: crashes the libapache2-authcookie-perl test suite
Package: libtest-simple-perl Version: 1.302075-1 Severity: important Tags: fixed-upstream Forwarded: https://github.com/Test-More/test-more/issues/757 User: debian-p...@lists.debian.org Usertags: perl-5.26-transition Control: clone -1 -2 Control: reassign -2 perl 5.26.0-1 The libapache2-authcookie-perl test suite has started to fail with new versions of Test-Simple, including the one in this package and the one shipped with Perl 5.26. Can't call method "ctx" on an undefined value at /usr/share/perl5/Test/Builder.pm line 228. A context appears to have been destroyed without first calling release(). Based on $@ it does not look like an exception was thrown (this is not always a reliable test) [...] Here are the context creation details, just in case a tool forgot to call release(): File: t/real.t Line: 35 Tool: Test::More::subtest [...] Test Summary Report --- t/real.t (Wstat: 65280 Tests: 1 Failed: 0) Non-zero exit status: 255 Full build logs: sid with libtest-simple-perl (>= 1.302075-1) in b-deps: http://perl.debian.net/rebuild-logs/experimental/libapache2-authcookie-perl_3.26-1/libapache2-authcookie-perl_3.26-1_amd64-2017-06-25T16%3A03%3A49Z.build Perl 5.26: http://perl.debian.net/rebuild-logs/perl-5.26-throwaway/libapache2-authcookie-perl_3.26-1/libapache2-authcookie-perl_3.26-1_amd64-2017-06-25T15:40:13Z.build This should be fixed upstream by https://github.com/Test-More/test-more/commit/68775db7eef1a7e30dc03abf8feabcf3e32301d4 with the Changes entry 1.302076 2017-02-01 19:38:42-08:00 America/Los_Angeles (TRIAL RELEASE) - Fix crash when TB->reset used inside subtest I'm cloning a separate bug for src:perl (assuming the control magic works) as I think we'll want to backport this fix to the 5.26.0 package. -- Niko Tyni nt...@debian.org
Bug#865888: nagios-plugin-check-multi: FTBFS with Perl 5.26: Unescaped left brace in regex is deprecated here
Package: nagios-plugin-check-multi
Version: 0.26-3
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.26-transition
This package fails to build with Perl 5.26 (currently in experimental.)
A full build log is available at
http://perl.debian.net/rebuild-logs/perl-5.26-throwaway/nagios-plugin-check-multi_0.26-3/nagios-plugin-check-multi_0.26-3_amd64-2017-05-21T12:04:35Z.build
and the server also hosts an unofficial repository of packages binNMU'd for Perl
5.26 that can be used for testing purposes; see <http://perl.debian.net/>.
Log excerpt:
# Failed test 'output correct'
# at 10_check_multi.t line 68.
# 'Unescaped left brace in regex is deprecated here (and will
be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^${
<-- HERE NAGIOS}/ at ../check_multi line 1377.
[...]
Test Summary Report
---
10_check_multi.t (Wstat: 6400 Tests: 94 Failed: 25)
Failed tests: 4, 6, 8, 12, 14, 16, 18, 20, 22, 24, 26
28, 30, 32, 34, 36, 38, 40, 42, 44, 54
56, 58, 60, 62
Non-zero exit status: 25
20_check_multi_macros.t (Wstat: 1536 Tests: 20 Failed: 6)
Failed tests: 2, 4, 6, 8, 10, 12
Non-zero exit status: 6
30_check_multi_perfdata.t (Wstat: 3840 Tests: 40 Failed: 15)
Failed tests: 2, 10, 12, 14, 16, 18, 20, 22, 24, 30, 32
34, 36, 38, 40
Non-zero exit status: 15
Files=3, Tests=154, 6 wallclock secs ( 0.04 usr 0.00 sys + 2.96 cusr 0.21
csys = 3.21 CPU)
Result: FAIL
--
Niko Tyni nt...@debian.org
Bug#826489: libperlx-assert-perl: Unescaped left brace in regex is deprecated
severity 826489 important
user debian-p...@lists.debian.org
usertag 826489 perl-5.26-transition
thanks
On Sun, Jun 05, 2016 at 10:04:19PM +0300, Niko Tyni wrote:
> Package: libperlx-assert-perl
> Version: 0.904-1
> Severity: normal
> User: debian-p...@lists.debian.org
> Usertags: perl-5.24-transition
>
> Building this package triggers deprecation warnings with Perl 5.24
> (currently in experimental), and probably with Perl 5.22 (current sid)
> too.
>
> Unescaped left brace in regex is deprecated, passed through in regex;
> marked by <-- HERE in m/\A{ <-- HERE / at
> /<>/blib/lib/PerlX/Assert/DD.pm line 102.
>
> The offending file is installed in a binary package, so this probably
> has runtime effects as well.
This is fatal with Perl 5.26, making the package fail to build from source.
I'm raising the severity accordingly.
A full log is at
http://perl.debian.net/rebuild-logs/perl-5.26-throwaway/libperlx-assert-perl_0.904-1/libperlx-assert-perl_0.904-1_amd64-2017-05-21T15:47:43Z.build
and the server also hosts a test repository of packages binNMU'd for Perl
5.26 that can be used for testing purposes; see <http://perl.debian.net/>.
--
Niko Tyni nt...@debian.org
Bug#865034: polymake: FTBFS with Perl 5.26: 'yy_parser {aka struct yy_parser}' has no member named 'lex_expect'
Control: fixed -1 3.1-2 On Sat, Jun 24, 2017 at 12:36:30PM -0300, David Bremner wrote: > Niko Tyni writes: > > > Package: polymake > > Version: 3.0r2-2 > > Severity: important > > User: debian-p...@lists.debian.org > > Usertags: perl-5.26-transition > > > > This package fails to build with Perl 5.26 (currently in experimental.) > I'll have a look at this when I can, but I'm just back from VAC, so it > may take me some time. If you had a chance to confirm / deny the problem > is still present with polymake 3.1-2 (in experimental), that would be > helpful. Hi David, hope you had a nice VAC! The version in experimental builds fine with Perl 5.26; log at http://perl.debian.net/rebuild-logs/perl-5.26-throwaway/polymake_3.1-2/polymake_3.1-2_amd64-2017-06-25T14%3A27%3A07Z.build I'm updating the bug metadata accordingly. -- Niko
Bug#865563: libcatmandu-sru-perl FTBFS: test failures
On Thu, Jun 22, 2017 at 08:49:19PM +0300, Adrian Bunk wrote: > Source: libcatmandu-sru-perl > Version: 0.039-1 > Severity: serious > > Some recent change in unstable makes this package FTBFS: > > https://tests.reproducible-builds.org/debian/history/libcatmandu-sru-perl.html > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libcatmandu-sru-perl.html > > ... > cd . && ./Build test --verbose 1 Probably libmodule-build-perl_0.422400-1 though I don't really know why, given the changelog says - Remove 0003-Make-Module-Build-set-PERL_UNSAFE_INC.patch (fixed upstream) -- Niko Tyni nt...@debian.org
Bug#865485: Voting for TC Chair
On Wed, Jun 21, 2017 at 10:21:57PM +0200, Didier 'OdyX' Raboud wrote: > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A: Keith Packard > B: Didier Raboud > C: Tollef Fog Heen > D: Sam Hartman > E: Phil Hands > F: Margarita Manterola > G: David Bremner > H: Niko Tyni > ===END=== I vote: B > A = C = D = E = F = G = H -- Niko signature.asc Description: PGP signature
Bug#865411: perl: please backport zlib > 1.2.9 patches
On Wed, Jun 21, 2017 at 07:42:32PM +0100, Dominic Hargreaves wrote: > On Wed, Jun 21, 2017 at 08:10:04AM +, Gianfranco Costamagna wrote: > > Source: perl > > Version: 5.24.1-4 > > Severity: important > > > > Hello, with the new zlib > 1.2.9 the testsuite fails, > > (e.g. you can look at Ubuntu build failures). > > https://launchpad.net/ubuntu/+source/perl/5.24.1-2 > > > > I found the test failures on rt.cpan.org and I applied to Ubuntu the > > proposed > > patches: > > https://rt.cpan.org/Public/Bug/Display.html?id=120134 > > https://rt.cpan.org/Public/Bug/Display.html?id=119762 > Just to be clear, this is in Compress-Raw-Zlib that has already > (according to https://rt.cpan.org/Public/Bug/Display.html?id=119762) > been fixed in 2.74, which is already in blead and perl 5.26 (which is > in experimental). The Ubuntu patches and the second bug also reference IO-Compress, not sure if that's upstream yet. > I'm not convinced that we need to spend time on fixing this for 5.24 > given where we are in the release cycle, but this will depend on > when the zlib maintainer (Cced) plans to update to a newer zlib. Agreed. -- Niko
Bug#865380: libtest-unixsock-perl: Build-Conflicts-Indep: libtest-simple-perl (>= 1.3), including Perl 5.26
Package: libtest-unixsock-perl Version: 0.1-1 Severity: important User: debian-p...@lists.debian.org Usertags: perl-5.26-transition This package Build-Conflicts-Indep: libtest-simple-perl (>= 1.3), for reasons that aren't immediately obvious. This was OK-ish for stretch, where src:perl had an old enough Test-Simple so the Build-Conflicts-Indep just kept the newer separate package away. However, Perl 5.26 bundles a newer Test-Simple, and the change to versioned Provides there means the build dependencies/conflicts can't be satisfied at all anymore. There's an example build log at http://perl.debian.net/rebuild-logs/perl-5.26-throwaway/libtest-unixsock-perl_0.1-1/libtest-unixsock-perl_0.1-1_amd64-2017-05-21T14:10:46Z.build and the server also hosts a repository of packages binNMU'd for Perl 5.26 that can be used for testing purposes; see <http://perl.debian.net/>. -- Niko Tyni nt...@debian.org
Bug#865374: libdigest-sha3-perl: sha3sum perl v5.24.1 and v5.20.0 create a different checksum for the same input
Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=110364 On Tue, Jun 20, 2017 at 09:50:20PM +0200, Honovere wrote: > Package: libdigest-sha3-perl > Version: 0.25-1+b1 > Severity: important > > Dear Maintainer, > > checksums created with sha3sum for the exact same input with Debian 8 and 9 > are different. They should be identical. Hi, this seems to expected behaviour. Quoting the upstream author in https://rt.cpan.org/Public/Bug/Display.html?id=110364 Yes, the outputs are different. As of version 0.23 the Digest::SHA3 module reflects the then-recent updates made to FIPS 202 which called for the use of domain separation bits (ref. the Changes file). These updates caused changes to all digest outputs, as expected. To my knowledge the current Digest::SHA3 module passes all official, published test vectors, including those with partial-byte inputs. If you know of any exceptions, let me know So it looks like the standard is/was still evolving. -- Niko Tyni nt...@debian.org
Bug#865020: [Pkg-postgresql-public] Bug#865020: postgresql-9.6: FTBFS with Perl 5.26: hstore_plperlu differences
On Tue, Jun 20, 2017 at 12:50:26AM -0400, Peter Eisentraut wrote: > On 6/18/17 15:15, Niko Tyni wrote: > > Package: postgresql-9.6 > > Version: 9.6.3-3 > > Severity: important > > User: debian-p...@lists.debian.org > > Usertags: perl-5.26-transition > > > > This package fails to build with Perl 5.26 (currently in experimental.) > > This will be fixed in upstream 9.6.4, expected in August. Yeah, I see it's already in: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=12ad38b3b4b5004001a525e0a0eda2ec45329e8e > So it's perhaps not worth patching around in it before then. Your call, though I'd certainly appreciate if you included it if there's to be another 9.6.3 upload in between. We're tracking sid with the unofficial binNMU repo at perl.debian.net, and this shows up on the radar of packages that can't currently be rebuilt. I don't think it's blocking other packages atm though. We don't have a schedule for 5.26 in sid yet, but things are looking quite good this time [at least compared to some previous years :) ] -- Niko Tyni nt...@debian.org
