Bug#1003176: transition: perl 5.34
Hi Paul, Sebastian and others,
as discussed on IRC, here's a list of packages that need rescheduling on
ci.debian.net for the Perl 5.34 transition. Their autopkgtest checks are
failing as their Recommendations are not installable without explicitly
pulling their rebuilt dependencies from unstable.
We also have another class of problem where a handful of packages are
failing their tests because of version skew between testing and unstable.
If the testing version of the package itself is uninstallable with perl
from unstable, autopkgtest falls back to downloading everything from
unstable ("package is not installed though it should be"). Most of the
time this works OK, but in some cases it can include other packages that
break tests in testing, or even a newer version of the package itself that
is incompatible with the tests extracted from the older source package.
I've included a couple of arch:all packages that I hope can be made
installable in testing with some help. We can revisit the rest when these
'easier' ones have been sorted out.
Not sure about the format but hope the attached will do. Each line has
the package to be rescheduled, and then a list of packages that need
to be pulled from unstable. I haven't checked whether the lists are
absolutely minimal for this, but a few too much shouldn't hurt as they
are going to migrate at the same time anyway.
If you can reschedule these, I can then sort through the results to see
whether this worked at all.
(BTW: Could I do the rescheduling myself via the ci.d.n API, or do the
requests need to come from britney to be considered grounds for
migration?)
Thanks,
--
Niko
# make package recommendations installable
libapache-session-perl/1.94-1 needs libhtml-parser-perl libdbi-perl
libcpanplus-perl/0.9914-1 needs libdbd-sqlite3-perl libdbi-perl
libdata-stag-perl/0.14-2 needs libgd-perl libhtml-parser-perl
libnet-ssleay-perl libset-object-perl libxml-libxml-perl libxml-libxslt-perl
libxml-parser-perl perl-tk
libhttp-tinyish-perl/0.17-1 needs libhtml-parser-perl libnet-ssleay-perl
libjavascript-beautifier-perl/0.25-2 needs libb-hooks-op-check-perl
libclass-xsaccessor-perl libdevel-callchecker-perl libparams-classify-perl
liblog-agent-perl/1.005-1 needs libnet-ssleay-perl
liblog-log4perl-perl/1.54-1 needs libb-hooks-op-check-perl
libdevel-callchecker-perl libparams-classify-perl libparams-util-perl
libstring-crc32-perl libsub-identify-perl libsub-name-perl
libvariable-magic-perl libxstring-perl
libmojolicious-perl/9.22+dfsg-1 needs libcommon-sense-perl
libcpanel-json-xs-perl libev-perl libfuture-asyncawait-perl libnet-ssleay-perl
libxs-parse-keyword-perl libxs-parse-sublike-perl
libnet-server-mail-perl/0.28-1 needs libnet-ssleay-perl
libpdf-builder-perl/3.023-1 needs libgraphics-tiff-perl libimage-png-libpng-perl
libpoe-test-loops-perl/1.360-1.1 needs libfilter-perl
libspreadsheet-wright-perl/0.107-3 needs libb-hooks-op-check-perl
libdatetime-perl libdevel-callchecker-perl libparams-classify-perl
libparams-util-perl libsub-identify-perl libsub-name-perl
libvariable-magic-perl libxml-libxml-perl libxstring-perl
libsyntax-highlight-engine-kate-perl/0.14+dfsg-1 needs libhtml-parser-perl
libnet-ssleay-perl libxml-parser-perl
libsys-info-base-perl/0.7807-3 needs libunix-processors-perl
# make the package itself installable
libxml-atom-perl/0.42-2.1 needs libb-hooks-op-check-perl libdatetime-perl
libdevel-callchecker-perl libhtml-parser-perl libnet-ssleay-perl
libparams-classify-perl libparams-util-perl libsub-identify-perl
libsub-name-perl libvariable-magic-perl libxml-libxml-perl libxml-libxslt-perl
libxml-parser-perl libxstring-perl
libdigest-bcrypt-perl/1.209-3 needs libb-hooks-op-check-perl
libcrypt-eksblowfish-perl libdevel-callchecker-perl libparams-classify-perl
Bug#1005175: libtest-harness-perl: uninstallable, older than Perl 5.34 bundled version
Package: libtest-harness-perl Version: 3.42-2 Severity: serious User: debian-p...@lists.debian.org Usertags: perl-5.34-transition Control: block 1003176 with -1 This package is currently uninstallable with Perl 5.34, which bundles a newer version and Provides a corresponding versioned virtual package. The following packages have unmet dependencies: perl-modules-5.34 : Breaks: libtest-harness-perl (< 3.43) 3.43 is not currently on CPAN. This separate package should probably just be removed from testing for now. Apologies for not spotting this earlier. -- Niko Tyni nt...@debian.org
Bug#1005174: libio-compress-perl: uninstallable, older than 5.34 bundled version
Package: libio-compress-perl Version: 2.101-1 Severity: serious User: debian-p...@lists.debian.org Usertags: perl-5.34-transition Control: block 1003176 with -1 This package is currently uninstallable with Perl 5.34, which bundles 2.102. The following packages have unmet dependencies: libperl5.34 : Breaks: libio-compress-perl (< 2.102) 2.102 is on CPAN and would be a short term fix, but going forward we should consider if we need the separate package at all. Apologies for not spotting this earlier. -- Niko Tyni nt...@debian.org
Bug#1003176: transition: perl 5.34
On Sat, Feb 05, 2022 at 12:40:53PM +0200, Niko Tyni wrote: > Uploading this afternoon. perl_5.34.0-3 uploaded and accepted. -- Niko
Bug#1003176: transition: perl 5.34
On Sat, Feb 05, 2022 at 11:07:19AM +0100, Sebastian Ramacher wrote: > On 2022-02-04 10:52:11, Niko Tyni wrote: > > On Thu, Feb 03, 2022 at 09:49:28PM +0100, Sebastian Ramacher wrote: > > > > On 2022-01-05 17:00:54 +, Niko Tyni wrote: > > > > > we'd like a transition slot for Perl 5.34. > > > ocaml is done, so please go ahead. > > > > Thanks! > > > > My last rebuilds found that graphviz has regressed and doesn't build > > anymore (#1004956). Do we need to get that fixed first? > > libgv-perl does not have any reverse dependencies. None of the other > binaries built by graphviz are affected by this transition. Ack, thanks. > Unless there are any other packages that build perl and php bindings > using swig that would fail to build, I don't think that this bug is a > blocker. No other regressions turned up in my rebuild tests, so I think we should be fine. Uploading this afternoon. -- Niko
Bug#1004611: Resignation & call for votes to elect the Chair
On Sun, Jan 30, 2022 at 02:10:08PM -0700, Sean Whitton wrote: > Package: tech-ctte > As the membership of the committee has changed, according to convention > I hereby resign as Chair, effective one week from now, and call for > votes to elect the Chair of the Technicall Committee. In accordance > with the Debian Constitution, the vote runs until all members have > voted, or until my resignation takes effect. > ===BEGIN > > A: Christoph Berg > B: Helmut Grohne > C: Elana Hashman > D: Simon McVittie > E: Niko Tyni > F: Matthew Vernon > G: Sean Whitton > H: Gunnar Wolf I vote: G > C > A = D > E > B = F Thanks to Sean for volunteering. -- Niko signature.asc Description: PGP signature
Bug#1003176: transition: perl 5.34
On Thu, Feb 03, 2022 at 09:49:28PM +0100, Sebastian Ramacher wrote: > > On 2022-01-05 17:00:54 +, Niko Tyni wrote: > > > we'd like a transition slot for Perl 5.34. > ocaml is done, so please go ahead. Thanks! My last rebuilds found that graphviz has regressed and doesn't build anymore (#1004956). Do we need to get that fixed first? If not, I can hopefully upload 5.34 some time tomorrow (Saturday). -- Niko
Bug#1004956: graphviz: FTBFS: These bindings need PHP7
Source: graphviz
Version: 2.42.2-5
Severity: serious
Tags: ftbfs sid bookworm
Control: block 1003176 with -1
This package fails to build from source on current sid, and apparently
testing as well.
Build logs can be found at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/graphviz.html
Looking at the build history there, the PHP 8.1 transition seems to fit
the timeline.
Excerpt:
gv_php.cpp:772:3: error: #error These bindings need PHP7 - to generate PHP5
bindings use: SWIG < 4.0.0 and swig -php5
772 | # error These bindings need PHP7 - to generate PHP5 bindings use:
SWIG < 4.0.0 and swig -php5
| ^
gv_php.cpp: In function 'int SWIG_ConvertPtr(zval*, void**, swig_type_info*,
int)':
gv_php.cpp:963:54: error: cannot convert 'zval*' {aka '_zval_struct*'} to
'zend_object*' {aka '_zend_object*'} in argument passing
963 | HashTable * ht = Z_OBJ_HT_P(z)->get_properties(z);
| ^
| |
| zval* {aka
_zval_struct*}
gv_php.cpp: At global scope:
gv_php.cpp:5405:2: error: 'ZEND_ARG_PASS_INFO' was not declared in this
scope; did you mean 'ZEND_ARG_OBJ_INFO'?
--
Niko Tyni nt...@debian.org
Bug#1000896: Bug#997829: libipc-shareable-perl: autopkgtest regression on armhf and i386
On Sat, Jan 15, 2022 at 11:20:51PM +0100, gregor herrmann wrote: > On Mon, 25 Oct 2021 19:59:39 +0200, gregor herrmann wrote: > No reaction so far at https://github.com/stevieb9/ipc-shareable/issues/14 > > Failures are visible at > https://qa.debian.org/excuses.php?package=libipc-shareable-perl > > And can easily be reproduced by building in an i386 chroot. > > After some looking at the the code I have no idea what's broken > there. > Anyone else? It boils down to perl -e 'shmget(0, , 0666) or die' which dies on amd64 but not in i386. Looking further: # strace -e shmget perl -we 'shmget(0, , 0666) or die' shmget(IPC_PRIVATE, 3567587327, 0666) = 5177377 +++ exited with 0 +++ Given % 2^32 == 3567587327 it's pretty clear that the requested size does not fit into 32 bits (shmget(2) takes a size_t) so just its lower bits get passed in. Not sure if perl should protest somehow there. Anyway, seems like the test could just be skipped on 32-bit or something. -- Niko Tyni nt...@debian.org
Bug#1003738: tech-ctte: Call for votes on TC membership of Matthew Vernon
On Fri, Jan 14, 2022 at 11:56:20AM -0700, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Matthew Vernon be > appointed by the Debian Project Leader to the Technical Committee. > > H: Recommend to Appoint Matthew Vernon > F: Further Discussion > ===END I vote: H > F -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#1003737: tech-ctte: Call for votes on TC membership of Helmut Grohne
On Fri, Jan 14, 2022 at 11:55:17AM -0700, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Helmut Grohne be > appointed by the Debian Project Leader to the Technical Committee. > > H: Recommend to Appoint Helmut Grohne > F: Further Discussion > ===END I vote: H > F -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#1003176: transition: perl 5.34
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-p...@lists.debian.org, p...@packages.debian.org Control: block -1 with 1002093 997267 997189 Hi, we'd like a transition slot for Perl 5.34. Should have done this months ago, but real life has interfered. Sorry about that. Perl 5.36 is scheluded for May or so, and I expect that will be our target for bookworm. Nevertheless, it's probably best to do this incrementally and have a 5.34 transition now in case 5.36 turns out to be difficult for some reason. The changes in 5.34 are quite small, as upstream spent most of that release cycle planning Perl 7 (which did not quite work out.) This reflects in the very low number regressions we found in our test rebuilds, visible at https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.34-transition;users=debian-p...@lists.debian.org with just one bug open (openscap, not in testing). I did a full archive test rebuild back in May, and partial test rebuilds in August. Coming back to this now, I've done another round of test rebuilds for those packages that will need binNMUs. I don't think another full round is necessary: it seems unlikely that the other packages might have introduced any Perl 5.34 related regressions in the meantime. There's a few packages that have unrelated build failures in current sid. I'm marking the ones in testing as blockers for this. Not sure if this Ben file is correct but hope it helps a bit: title = "perl"; is_affected = .depends ~ "libperl5.32|perlapi-5.32" | .pre-depends ~ "libperl5.32|perlapi-5.32"; is_good = .depends ~ "libperl5.34|perlapi-5.34" | .pre-depends ~ "libperl5.34|perlapi-5.34"; is_bad = .depends ~ "libperl5.32|perlapi-5.32" | .pre-depends ~ "libperl5.32|perlapi-5.32"; Thanks for your work, -- Niko Tyni nt...@debian.org
Bug#1003127: libdbd-sqlite3-perl: test failures with sqlite3 3.37
Source: libdbd-sqlite3-perl Version: 1.70-2 Severity: serious Tags: ftbfs fixed-upstream patch Forwarded: https://github.com/DBD-SQLite/DBD-SQLite/issues/92 This package fails its test suite in current sid since the upload of sqlite3 3.37-1.1 a couple of days ago. This makes it fail to build and also causes autopkgtest failures. https://ci.debian.net/packages/libd/libdbd-sqlite3-perl/testing/amd64/ # Failed test 'data type is correct' # at t/51_table_column_metadata.t line 22. # got: 'INTEGER' # expected: 'integer' # Failed test 'data type is correct' # at t/51_table_column_metadata.t line 22. # got: 'INTEGER' # expected: 'integer' # Looks like you failed 2 tests of 32. The upstream issue links to a trivial test suite patch in https://github.com/DBD-SQLite/DBD-SQLite/commit/ba4f472e7372dbf453444c7764d1c342e7af12b8 -- Niko Tyni nt...@debian.org
Bug#997961: debhelper: dh_perl generates unversioned perl/perl-base dependencies for XS modules
Package: debhelper
Version: 13.3
Severity: normal
X-Debbugs-Cc: debian-p...@lists.debian.org
Hi,
as noted by josch in
https://lists.debian.org/debian-perl/2021/10/msg00020.html
dh_perl generates incorrect unversioned dependencies for packages
containing binary Perl modules.
I think this regressed with
https://salsa.debian.org/debian/debhelper/-/commit/7da36e893a975680654c1448c7bcba7dc1786551
which looks incorrect: $version is not always empty and when it
isn't it should be used. This got into unstable with 13.3 in
December 2020, shortly before the bullseye freeze started
and after the Perl 5.32 transition.
Quoting the Perl policy at
https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-binary-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.
A quick count [1] indicates that 150 or so packages are currently violating
this,
presumably because of the dh_perl change.
Fortunately I don't think this is as bad as it might seem (and I guess
we'd have noticed sooner if it was.)
Clearly the policy requirement is there to guarantee that partial upgrades
don't result in a binary module getting loaded by a Perl version older
than the one it was compiled with. The perlapi-* dependencies already
ensure this for the upstream Perl version, and we have made only minimal
changes in the Debian packaging during the time, partially because of
the freeze.
I'm not sure how necessary the policy requirement is nowadays. We
certainly take care not to change the XS module ABI, and if we had
to we'd change the perlapi-* virtual package too to force a full Perl
transition. I guess C toolchain changes might cause issues, but even
that seems improbable.
In any case, it would probably be good to fix this before the Perl 5.34
transition when all the binary modules get rebuilt. (There is no timeline
yet for that but that's just because I haven't got around to pushing it.)
[1] grep-aptavail -FDepends perlapi- | grep-dctrl -sPackage -v -FDepends -e
'perl(-base)? \('
--
Niko Tyni nt...@debian.org
Bug#994275: Call for votes on "Reverting breaking changes in debianutils"
On Wed, Oct 20, 2021 at 12:30:54PM -0700, Sean Whitton wrote: > === Resolution A === > > The Technical Committee resolves: > > 1. The debianutils package must continue to provide the which(1) program >until a compatible utility is available in a package that is at least >transitively essential in Debian 12. > >For the Debian 12 release, we expect which(1) to be in either an >Essential package or a transitively Essential package (that is, a >package that is depended on by an Essential package). > > 2. The which(1) program must not print any deprecation warnings. > > 3. We decline to overrule the maintainer of debianutils regarding the >use of alternatives. If another package takes over responsibility >for which(1), then the debianutils maintainers and the other >package's maintainers should coordinate to choose a suitable >mechanism, which might be either versioned Depends/Breaks/Replaces, >dpkg-divert, alternatives or something else. > > 4. The debianutils package must continue to provide the tempfile(1) >program until a compatible utility is available in a package that is >at least transitively essential in Debian 12. > >For the Debian 12 release, we expect tempfile(1) to be in either an >Essential package or a transitively Essential package. > > 5. Programs in debianutils must not be moved to /usr until we have a >project-wide consensus on going ahead with such a move, and any >programs that have already been moved must be moved back. In >particular, this means debianutils must contain /bin/run-parts and >/sbin/installkernel for the time being. > > === Resolution B === > > As Resolution A, except strike point (2) and renumber succeeding items. > > === End Resolutions === > > A: Issue Resolution A > B: Issue Resolution B > F: Further Discussion I vote: A > B > F -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#987615: Bug#985957: usrmerge has 47.3MB of dependencies
On Thu, Oct 07, 2021 at 03:59:11AM +0200, Michael Biebl wrote: > On Mon, 16 Aug 2021 07:46:49 +0100 Niko Tyni wrote: > > On Mon, Aug 16, 2021 at 12:11:26AM +0200, Marco d'Itri wrote: > > > > > I see no reason to move the usrmerge dependencies to perl-base: usrmerge > > > is supposed to be installed, run and then removed again. > > > If something is moved to perl-base then it will use space on every > > > Debian system. > > > > My suggestion in #987615 (which I also copied to usrmerge@pdo, being > > unaware of #985957) is to introduce separate packages of the usrmerge > > dependencies, and limit their dependencies to perl-base only. This does > > not grow perl-base and can be phased out later, so it does not impose > > a permanent cost on everybody. > > Seems to me, that simply vendoring the necessary perl modules in the > usrmerge package would be a better, simpler and more lightweight approach to > packaging those all invidually as separate packages. Yeah, you're probably right, particularly as I haven't got around to doing much about this so far. I'm fine with that approach FWIW. I did try out the separate package plan at home at one point, and got things working with seven modified or introduced packages (well, eight if you count the usrmerge package too.) Here's some notes, maybe they will save somebody some work even if this is not the chosen path. There's two branches to the usrmerge dependencies: libautodie-perl (would need a separate package) libif-perl (would need a separate package) libtie-refhash-perl (would need a separate package) libfile-find-rule-perl (would need dependency modifications) libfile-find-perl (would need a separate package) libnumber-compare-perl (would need dependency modifications) libtext-glob-perl (would need dependency modifications) Happily all these modules are pure Perl, which makes things a bit easier. The libnumber-compare-perl and libtext-glob-perl modifications are trivial (override dh_perl to dh_perl -d). I suggest modifying at least those two packages instead of bundling them. I'm copying the debian-perl list for some visibility. -- Niko
Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636
On Wed, Oct 13, 2021 at 08:13:08PM +0100, Simon McVittie wrote: > I'm calling for votes on the following resolution as formal advice from > the Technical Committee (Constitution §6.1.5). There are no non-accepted > amendments, so the options to vote on are "yes" or "further discussion". I vote: "yes" > "further discussion". > begin text to be voted on > > Summary > === > > There are currently Debian 11 installations with both the merged-/usr and > non-merged-/usr filesystem layouts. All of these installations should > successfully upgrade via normal upgrade paths to a merged-/usr Debian 12. > Only after the release of Debian 12 can packages assume that all > installations will be merged-/usr. > > Main points: > > - We have recommended merged-/usr for Debian 12. > - Moving individual files is not merged-/usr. > - "Symlink farms" are not merged-/usr. > - Upgrading a non-merged-/usr system to Debian 12 needs to work. > - Upgrading a merged-/usr system to Debian 12 needs to work. > - Packages cannot assume all systems are merged-/usr until the Debian 13 > development cycle begins. > - Upgrading via apt in the usual way should work. > - Testing and QA systems should be able to avoid this transition, but if > they do, they cannot be upgraded beyond Debian 12. > - A package building incorrectly on a non-merged-/usr system is a bug. > - A package building incorrectly on a merged-/usr system is a bug. > - Please stop moving individual packages' files from the root filesystem > into /usr, at least for now. > > Definitions and current status > == > > libQUAL refers to the directories described in FHS 3.0 section 3.10 [1], > such as lib64 on the amd64 architecture. > > Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each > /libQUAL that exists are symbolic links to the corresponding directories > below /usr. This results in aliasing between /bin and /usr/bin, and > so on. > > In the merged-/usr layout, files whose canonical logical location is > in one of the affected directories on the root filesystem, such as > /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at > the corresponding path below /usr, such as /usr/bin/bash. Each file in > one of the affected directories is accessible via two paths: its canonical > logical location (such as /bin/bash or /usr/bin/env), and the other path > implied by the aliasing (such as /usr/bin/bash or /bin/env). > > There are two supported categories of Debian 11 installation, which are > currently considered equally-supported: > > - Merged-/usr installations. These were installed with debian-installer > from Debian 10 or later, or installed with debootstrap --merged-usr, > or converted from the non-merged-/usr layout by installing the usrmerge > package, or installed or converted by any similar procedure. They have > the merged-/usr layout. > > - Non-merged-/usr installations. These were installed with debian-installer > from Debian 9 or earlier and subsequently upgraded without converting > to merged-/usr, or installed with debootstrap --no-merged-usr, or > converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess" > utility or any similar procedure. They have the traditional, > non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly > those physical paths, and /usr/bin/bash and /bin/env do not exist. > > Merged-/usr is not the only filesystem layout that has been proposed for > unifying the root filesystem with /usr. For avoidance of doubt, we do not > consider other filesystem layouts to be implementations of merged-/usr. > In particular, we do not consider these to be implementations of merged-/usr: > > - all affected files physically located in /bin, /sbin, /lib and /libQUAL, > with /usr/bin as a symlink to /bin, etc. (this is the reverse of > merged-/usr, and was historically used in the hurd-i386 port) > > - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual > symbolic links such as /bin/bash -> /usr/bin/bash for only those files that > historically had their canonical logical location on the root filesystem > > - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual > symbolic links such as /bin/env -> /usr/bin/env for all files in the > affected directories, regardless of whether they historically had > their canonical logical location on the root filesystem > > [1]: > https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential > > Upgrade path from Debian 11 to Debian 12 > > > The technical committee resolved in #978636 [2] that Debian 12 'bookworm' > should only support the merged-/usr layout. This resolution describes > the implications of that decision in more detail. > > Debian installations have traditionally had a straightforward upgrade > path between consecutive releases, and the
Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636
On Wed, Sep 15, 2021 at 12:35:38PM +0100, Simon McVittie wrote: > https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md Many thanks for your work, and sorry for not participating earlier. I agree with you that it would be good to send advice out sooner rather than later. I also agree with pretty much all you're saying in the text. In particular: > Questions for the committee: > > - §(Definitions and current status): Does everyone agree with my > characterization of where we are now? Ack from me. > - §(Upgrade path from Debian 11 to Debian 12): Does everyone agree > with what I've written here about the implications of #978636? I think I can follow the logic, and I agree with it. > - §(Upgrade path from Debian 11 to Debian 12): Is the last paragraph > "If a suitable transition mechanism is not available by the time the > Debian 12 freeze is reached..." necessary, or is it implicit that > *obviously* we won't demand that the project carries on with merged-/usr > if it turns out not to be possible? I think it should be included. > - §(Testing and QA): Do we want to recommend this? It does feel a bit like micro-managing to me. But the reasoning makes sense. I'm fine with recommending it. > - §(Building packages): Does everyone agree with my interpretation of > what we agreed in #914897 and its implications? Do we need to make a > recommendation for the Debian 12 development cycle, or is it enough > to assume that the "middle" option that we resolved in #914897 > continues to be our opinion? I agree and I don't think we need a new recommendation. > - §(Building packages): I almost wrote an extra paragraph about how > this class of bugs becomes a non-issue when merged-/usr is the only > supported layout - but actually it doesn't! If we consider building > packages while having /usr/local/bin/sed to be a supported thing you > can do, then we need to ensure that /usr/local/bin/sed doesn't get > hard-coded into the resulting package, and the steps you take to > make that happen are the same as the steps you take to fix this class > of bugs. FWIW I think we've traditionally considered such /usr/local -related issues as bugs in the build setup rather than in the packages. > - §(Moratorium on moving files' logical locations into /usr): > I think we should stop moving files into /usr on an individual basis, > at least until the consequences are fully understood, and perhaps for > the whole Debian 12 release cycle (after which, assuming merged-/usr > goes as we have recommended, maintainers can swap their logical location > without needing a transitional mechanism any more). Implementing > merged-/usr as the only supported layout means that moving files into > /usr on an individual basis is mostly unnecessary, because it has no > practical effect any more. Agreed on the moratorium, mainly because of the unnecessity and the error-prone nature of the moves. Sam brought up concerns about the Replaces failure mode mentioned in the text, that part might need changing. On Mon, Sep 27, 2021 at 10:59:37AM +0100, Simon McVittie wrote: > I am a little concerned that usrmerge is doing more intrusive surgery on > a running system than even what's normal for an apt/dpkg-based upgrade, > so I would prefer not to rule out designs that defer this action to a > later time. I share this concern. -- Niko
Bug#995482: buster-pu: package request-tracker4/4.4.3-2+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-request-tracker-maintain...@lists.alioth.debian.org,
Salvatore Bonaccorso
Hi, we'd like to update request-tracker4 in buster to fix #995175 /
CVE-2021-38562, a timing sidechannel issue that allows user enumeration.
The security team (Salvatore) has deemed this a minor no-dsa
issue that would best be fixed via a point release. It's fixed in
unstable with version 4.4.4+dfsg-3, and bullseye is being fixed with
4.4.4+dfsg-2+deb11u1 in stable-NEW.
The upstream fix is small and isolated. I've verified that it fixes the
timing issue (which is clearly visible in the version in buster.)
I'm assuming this is uncontroversial and have already uploaded. Source
debdiff attached. Sorry about the small debian/.git-dpm noise caused
by our tooling, but I figured that getting rid of it would be more
invasive than leaving it in.
Thanks for your work,
--
Niko Tyni nt...@debian.org
diff -Nru request-tracker4-4.4.3/debian/changelog
request-tracker4-4.4.3/debian/changelog
--- request-tracker4-4.4.3/debian/changelog 2019-02-08 19:50:03.0
+0200
+++ request-tracker4-4.4.3/debian/changelog 2021-09-29 14:41:47.0
+0300
@@ -1,3 +1,11 @@
+request-tracker4 (4.4.3-2+deb10u1) buster; urgency=medium
+
+ * Apply upstream patch which fixes a security vulnerability that involves a
+login timing side-channel attack. This resolves CVE-2021-38562
+(Closes: #995175)
+
+ -- Andrew Ruthven Thu, 30 Sep 2021 00:41:47 +1300
+
request-tracker4 (4.4.3-2) unstable; urgency=high
* Add missing dependencies on libcpanel-json-xs-perl (Closes: #920744)
diff -Nru request-tracker4-4.4.3/debian/.git-dpm
request-tracker4-4.4.3/debian/.git-dpm
--- request-tracker4-4.4.3/debian/.git-dpm 2018-09-18 19:13:22.0
+0300
+++ request-tracker4-4.4.3/debian/.git-dpm 2021-09-29 14:41:47.0
+0300
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-20766b8eaa377b556aaaded81576c43058a0586e
-20766b8eaa377b556aaaded81576c43058a0586e
+78711c71d36915750d34634b48fbd9ba5a98f18e
+78711c71d36915750d34634b48fbd9ba5a98f18e
cae4666079f25496de9f49e7c61583bf3b616946
cae4666079f25496de9f49e7c61583bf3b616946
request-tracker4_4.4.3.orig.tar.gz
diff -Nru request-tracker4-4.4.3/debian/patches/series
request-tracker4-4.4.3/debian/patches/series
--- request-tracker4-4.4.3/debian/patches/series2018-09-18
19:13:22.0 +0300
+++ request-tracker4-4.4.3/debian/patches/series2021-09-29
14:41:47.0 +0300
@@ -17,3 +17,4 @@
test_gnupg-interface_gpg1.diff
runtime_gpg1.diff
use_cpanel_json_xs.diff
+upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
diff -Nru
request-tracker4-4.4.3/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
request-tracker4-4.4.3/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
---
request-tracker4-4.4.3/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
1970-01-01 02:00:00.0 +0200
+++
request-tracker4-4.4.3/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
2021-09-29 14:41:47.0 +0300
@@ -0,0 +1,66 @@
+From 78711c71d36915750d34634b48fbd9ba5a98f18e Mon Sep 17 00:00:00 2001
+From: Dianne Skoll
+Date: Fri, 15 Jan 2021 09:15:20 -0500
+Subject: Always check password to avoid timing side channel attacks on
+
+ login page
+
+This addresses CVE-2021-38562.
+
+Bug-Debian: https://bugs.debian.org/995175
+Forwarded: not-needed
+Patch-Name: upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
+---
+ lib/RT/Interface/Web.pm | 8
+ lib/RT/User.pm | 9 ++---
+ 2 files changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/lib/RT/Interface/Web.pm b/lib/RT/Interface/Web.pm
+index c897a7dc..9c1a1474 100644
+--- a/lib/RT/Interface/Web.pm
b/lib/RT/Interface/Web.pm
+@@ -824,10 +824,18 @@ sub AttemptPasswordAuthentication {
+ my $user_obj = RT::CurrentUser->new();
+ $user_obj->Load( $ARGS->{user} );
+
++# Load the RT system user as well to avoid timing side channel
++my $system_user = RT::CurrentUser->new();
++$system_user->Load(1);# User with ID 1 should always exist!
++
+ my $m = $HTML::Mason::Commands::m;
+
+ my $remote_addr = RequestENV('REMOTE_ADDR');
+ unless ( $user_obj->id && $user_obj->IsPassword( $ARGS->{pass} ) ) {
++if (!$user_obj->id) {
++# Avoid timing side channel... always run IsPassword
++$system_user->IsPassword( $ARGS->{pass} );
++}
+ $RT::Logger->error("FAILED LOGIN for @{[$ARGS->{user}]} from
$remote_addr");
+ $m->callback( %$ARGS, CallbackName => 'FailedLogin', CallbackPage =>
'/autohandler' );
+ return (0, HTML::Mason::Commands::loc('Your use
Bug#995481: bullseye-pu: package request-tracker4/4.4.4+dfsg-2+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-request-tracker-maintain...@lists.alioth.debian.org,
Salvatore Bonaccorso
Hi, we'd like to update request-tracker4 in bullseye to fix #995175 /
CVE-2021-38562, a timing sidechannel issue that allows user enumeration.
The security team (Salvatore) has deemed this a minor no-dsa issue that
would best be fixed via a point release. It's fixed in unstable with
version 4.4.4+dfsg-3.
The upstream fix is small and isolated. I've verified that it fixes the
timing issue (which is clearly visible in the version in bullseye.)
I'm assuming this is uncontroversial and have already uploaded. Source
debdiff attached. Sorry about the small debian/.git-dpm noise caused
by our tooling, but I figured that getting rid of it would be more
invasive than leaving it in.
Thanks for your work,
--
Niko Tyni nt...@debian.org
diff -Nru request-tracker4-4.4.4+dfsg/debian/changelog
request-tracker4-4.4.4+dfsg/debian/changelog
--- request-tracker4-4.4.4+dfsg/debian/changelog2021-02-07
17:44:18.0 +0200
+++ request-tracker4-4.4.4+dfsg/debian/changelog2021-09-29
13:28:05.0 +0300
@@ -1,3 +1,11 @@
+request-tracker4 (4.4.4+dfsg-2+deb11u1) bullseye; urgency=medium
+
+ * Apply upstream patch which fixes a security vulnerability that involves a
+login timing side-channel attack. This resolves CVE-2021-38562
+(Closes: #995175)
+
+ -- Andrew Ruthven Wed, 29 Sep 2021 23:28:05 +1300
+
request-tracker4 (4.4.4+dfsg-2) unstable; urgency=medium
* Downgrade Depends on rsyslog | system-log-daemon to Recommends
diff -Nru request-tracker4-4.4.4+dfsg/debian/.git-dpm
request-tracker4-4.4.4+dfsg/debian/.git-dpm
--- request-tracker4-4.4.4+dfsg/debian/.git-dpm 2021-02-02 02:04:05.0
+0200
+++ request-tracker4-4.4.4+dfsg/debian/.git-dpm 2021-09-29 13:28:05.0
+0300
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-11fa965a537750fbbf8b9b8400792e8055c84424
-11fa965a537750fbbf8b9b8400792e8055c84424
+e3de3eccb556f77daf21be8f900c7f9359879472
+e3de3eccb556f77daf21be8f900c7f9359879472
47d4fe68f38e9517210c5c518c2cb0e7e7a13bfb
47d4fe68f38e9517210c5c518c2cb0e7e7a13bfb
request-tracker4_4.4.4+dfsg.orig.tar.gz
diff -Nru request-tracker4-4.4.4+dfsg/debian/patches/series
request-tracker4-4.4.4+dfsg/debian/patches/series
--- request-tracker4-4.4.4+dfsg/debian/patches/series 2021-02-02
02:04:05.0 +0200
+++ request-tracker4-4.4.4+dfsg/debian/patches/series 2021-09-29
13:28:05.0 +0300
@@ -29,3 +29,4 @@
upstream_4.4-trunk_gpg:_always_use_temp_gpg_homedir.diff
upstream_4.4-trunk_gpg:_add_extra_ignored_keywords.diff
upstream_4.4-trunk_gpg:_default_cert-digest_algo_SHA256.diff
+upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
diff -Nru
request-tracker4-4.4.4+dfsg/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
request-tracker4-4.4.4+dfsg/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
---
request-tracker4-4.4.4+dfsg/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
1970-01-01 02:00:00.0 +0200
+++
request-tracker4-4.4.4+dfsg/debian/patches/upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
2021-09-29 13:28:05.0 +0300
@@ -0,0 +1,66 @@
+From e3de3eccb556f77daf21be8f900c7f9359879472 Mon Sep 17 00:00:00 2001
+From: Dianne Skoll
+Date: Fri, 15 Jan 2021 09:15:20 -0500
+Subject: Always check password to avoid timing side channel attacks on
+
+ login page
+
+This addresses CVE-2021-38562.
+
+Bug-Debian: https://bugs.debian.org/995175
+Forwarded: not-needed
+Patch-Name: upstream_4.4-trunk_cve:_avoid_time_side_channel_attack.diff
+---
+ lib/RT/Interface/Web.pm | 8
+ lib/RT/User.pm | 9 ++---
+ 2 files changed, 14 insertions(+), 3 deletions(-)
+
+diff --git a/lib/RT/Interface/Web.pm b/lib/RT/Interface/Web.pm
+index 57988d74..77ff88fd 100644
+--- a/lib/RT/Interface/Web.pm
b/lib/RT/Interface/Web.pm
+@@ -824,10 +824,18 @@ sub AttemptPasswordAuthentication {
+ my $user_obj = RT::CurrentUser->new();
+ $user_obj->Load( $ARGS->{user} );
+
++# Load the RT system user as well to avoid timing side channel
++my $system_user = RT::CurrentUser->new();
++$system_user->Load(1);# User with ID 1 should always exist!
++
+ my $m = $HTML::Mason::Commands::m;
+
+ my $remote_addr = RequestENV('REMOTE_ADDR');
+ unless ( $user_obj->id && $user_obj->IsPassword( $ARGS->{pass} ) ) {
++if (!$user_obj->id) {
++# Avoid timing side channel... always run IsPassword
++$system_user->IsPassword( $ARGS->{pass} );
++}
+ $RT::Logger->error("FAILED LOGIN for @{[$ARGS->{user}]} from
$remote_addr");
+ $m->callback( %$ARGS, CallbackName => 'Fail
Bug#995331: bullseye-pu: package perl/5.32.1-4+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: p...@packages.debian.org
Hi, I'd like to fix #994834 in perl/bullseye. It's a memory leak
regression from buster. The fix is from upstream Perl 5.34 and the patch
applied as-is to 5.32. It's included in unstable as of 5.32.1-6 which
recently migrated to testing as well (so it triggered no autopkgtest
regressions.) The patch includes a build time regression test.
Debdiff against 5.32.1-4+deb11u1 in stable-security attached. I expect
this is uncontroversial so I've just uploaded without waiting for an
explicit ack.
Thanks for your work,
--
Niko Tyni nt...@debian.org
diff -Nru perl-5.32.1/debian/changelog perl-5.32.1/debian/changelog
--- perl-5.32.1/debian/changelog2021-08-05 22:26:55.0 +0300
+++ perl-5.32.1/debian/changelog2021-09-24 19:10:58.0 +0300
@@ -1,3 +1,9 @@
+perl (5.32.1-4+deb11u2) bullseye; urgency=medium
+
+ * Apply upstream patch fixing a regexp memory leak. (Closes: #994834)
+
+ -- Niko Tyni Fri, 24 Sep 2021 19:10:58 +0300
+
perl (5.32.1-4+deb11u1) bullseye-security; urgency=high
* [SECURITY] CVE-2021-36770: Encode loading code from working directory
diff -Nru perl-5.32.1/debian/patches/fixes/regcomp-memleak.diff
perl-5.32.1/debian/patches/fixes/regcomp-memleak.diff
--- perl-5.32.1/debian/patches/fixes/regcomp-memleak.diff 1970-01-01
02:00:00.0 +0200
+++ perl-5.32.1/debian/patches/fixes/regcomp-memleak.diff 2021-09-24
19:10:52.0 +0300
@@ -0,0 +1,69 @@
+From: Karl Williamson
+Date: Sat, 27 Feb 2021 11:43:41 -0700
+Subject: regcomp.c: Remove memory leak
+
+This fixes GH #18604. There was a path through the code where a
+particular SV did not get its reference count decremented.
+
+I did an audit of the function and came up with several other
+possiblities that are included in this commit.
+
+Further, there would be leaks for some instances of finding syntax
+errors in the input pattern, or when warnings are fatalized. Those
+would require mortalizing some SVs, but that is beyond the scope of this
+commit.
+
+Origin: backport,
https://github.com/Perl/perl5/commit/5f41fa466a67b5535aa8bcf4b814f242545ac7bd
+Bug: https://github.com/Perl/perl5/issues/18604
+Bug-Debian: https://bugs.debian.org/994834
+---
+ regcomp.c | 7 +++
+ t/op/svleak.t | 3 ++-
+ 2 files changed, 9 insertions(+), 1 deletion(-)
+
+diff --git a/regcomp.c b/regcomp.c
+index 0da659c..5c72ff7 100644
+--- a/regcomp.c
b/regcomp.c
+@@ -18626,6 +18626,12 @@ S_regclass(pTHX_ RExC_state_t *pRExC_state, I32
*flagp, U32 depth,
+ RExC_end = save_end;
+ RExC_in_multi_char_class = 0;
+ SvREFCNT_dec_NN(multi_char_matches);
++SvREFCNT_dec(properties);
++SvREFCNT_dec(cp_list);
++SvREFCNT_dec(simple_posixes);
++SvREFCNT_dec(posixes);
++SvREFCNT_dec(nposixes);
++SvREFCNT_dec(cp_foldable_list);
+ return ret;
+ }
+
+@@ -19983,6 +19989,7 @@ S_regclass(pTHX_ RExC_state_t *pRExC_state, I32
*flagp, U32 depth,
+RExC_parse - orig_parse);;
+ SvREFCNT_dec(cp_list);;
+ SvREFCNT_dec(only_utf8_locale_list);
++SvREFCNT_dec(upper_latin1_only_utf8_matches);
+ return ret;
+ }
+
+diff --git a/t/op/svleak.t b/t/op/svleak.t
+index 6acc298..3df4838 100644
+--- a/t/op/svleak.t
b/t/op/svleak.t
+@@ -15,7 +15,7 @@ BEGIN {
+
+ use Config;
+
+-plan tests => 150;
++plan tests => 151;
+
+ # run some code N times. If the number of SVs at the end of loop N is
+ # greater than (N-1)*delta at the end of loop 1, we've got a leak
+@@ -278,6 +278,7 @@ eleak(2,0,'/[[:ascii:]]/');
+ eleak(2,0,'/[[.zog.]]/');
+ eleak(2,0,'/[.zog.]/');
+ eleak(2,0,'/|\W/', '/|\W/ [perl #123198]');
++eleak(2,0,'/a\sb/', '/a\sb/ [GH #18604]');
+ eleak(2,0,'no warnings; /(?[])/');
+ eleak(2,0,'no warnings; /(?[[a]+[b]])/');
+ eleak(2,0,'no warnings; /(?[[a]-[b]])/');
diff -Nru perl-5.32.1/debian/patches/series perl-5.32.1/debian/patches/series
--- perl-5.32.1/debian/patches/series 2021-08-05 22:26:55.0 +0300
+++ perl-5.32.1/debian/patches/series 2021-09-24 19:10:52.0 +0300
@@ -44,3 +44,4 @@
fixes/hurd-cachepropagate-test-fix.diff
fixes/io_socket_ip_ipv6.diff
fixes/encode-CVE-2021-36770.diff
+fixes/regcomp-memleak.diff
Bug#994834: perl: Memory leak in Perl version 5.32 not fixed in Debian 11.0
Control: found -1 5.32.1-4
Control: found -1 5.32.1-5
Control: fixed -1 5.34.0-1
Control: tag -1 bullseye patch fixed-upstream
On Tue, Sep 21, 2021 at 04:30:08PM +0200, Yvon Lafaille wrote:
> Subject: perl: Memory leak in Perl version 5.32 not fixed in Debian 11.0
> Package: perl
> Version: 5.32.1-4+deb11u1
> Severity: important
> The current perl version in Debian 11.0 suffer of memory leak in RegEx
> The details of the bug and the script to reproduce can be found here.
> https://github.com/Perl/perl5/issues/18604
Thanks for the report.
This needs to be fixed in unstable/testing first. I'll try to upload
a fix this weekend and look at a stable update after that. There's a
point release for bullseye scheduled for October 9th, we'll see if I
can meet that.
oldstable (buster) with Perl 5.28 is not affected, and it's fixed
in Perl 5.34.0.
The attached upstream patch applies as-is on 5.32.
--
Niko Tyni nt...@debian.org
From: Karl Williamson
Date: Sat, 27 Feb 2021 11:43:41 -0700
Subject: regcomp.c: Remove memory leak
This fixes GH #18604. There was a path through the code where a
particular SV did not get its reference count decremented.
I did an audit of the function and came up with several other
possiblities that are included in this commit.
Further, there would be leaks for some instances of finding syntax
errors in the input pattern, or when warnings are fatalized. Those
would require mortalizing some SVs, but that is beyond the scope of this
commit.
Origin: backport, https://github.com/Perl/perl5/commit/5f41fa466a67b5535aa8bcf4b814f242545ac7bd
Bug: https://github.com/Perl/perl5/issues/18604
Bug-Debian: https://bugs.debian.org/994834
---
regcomp.c | 7 +++
t/op/svleak.t | 3 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/regcomp.c b/regcomp.c
index 0da659c..5c72ff7 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -18626,6 +18626,12 @@ S_regclass(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth,
RExC_end = save_end;
RExC_in_multi_char_class = 0;
SvREFCNT_dec_NN(multi_char_matches);
+SvREFCNT_dec(properties);
+SvREFCNT_dec(cp_list);
+SvREFCNT_dec(simple_posixes);
+SvREFCNT_dec(posixes);
+SvREFCNT_dec(nposixes);
+SvREFCNT_dec(cp_foldable_list);
return ret;
}
@@ -19983,6 +19989,7 @@ S_regclass(pTHX_ RExC_state_t *pRExC_state, I32 *flagp, U32 depth,
RExC_parse - orig_parse);;
SvREFCNT_dec(cp_list);;
SvREFCNT_dec(only_utf8_locale_list);
+SvREFCNT_dec(upper_latin1_only_utf8_matches);
return ret;
}
diff --git a/t/op/svleak.t b/t/op/svleak.t
index 6acc298..3df4838 100644
--- a/t/op/svleak.t
+++ b/t/op/svleak.t
@@ -15,7 +15,7 @@ BEGIN {
use Config;
-plan tests => 150;
+plan tests => 151;
# run some code N times. If the number of SVs at the end of loop N is
# greater than (N-1)*delta at the end of loop 1, we've got a leak
@@ -278,6 +278,7 @@ eleak(2,0,'/[[:ascii:]]/');
eleak(2,0,'/[[.zog.]]/');
eleak(2,0,'/[.zog.]/');
eleak(2,0,'/|\W/', '/|\W/ [perl #123198]');
+eleak(2,0,'/a\sb/', '/a\sb/ [GH #18604]');
eleak(2,0,'no warnings; /(?[])/');
eleak(2,0,'no warnings; /(?[[a]+[b]])/');
eleak(2,0,'no warnings; /(?[[a]-[b]])/');
Bug#994736: libmath-gsl-perl: FTBFS on several architectures: undefined symbol: gsl_matrix_char_norm1
On Mon, Sep 20, 2021 at 10:25:43AM +0100, Niko Tyni wrote: > Source: libmath-gsl-perl > Version: 0.43-1 > Severity: serious > Tags: ftbfs > > This package failed to build on several architectures. > > From > https://buildd.debian.org/status/fetch.php?pkg=libmath-gsl-perl&arch=arm64&ver=0.43-1&stamp=1632072156&raw=0 > > # Failed test 'use Math::GSL::Matrix;' > # at t/00-load.t line 14. > # Tried to use 'Math::GSL::Matrix'. > # Error: Can't load > '/<>/blib/arch/auto/Math/GSL/Matrix/Matrix.so' for module > Math::GSL::Matrix: /<>/blib/arch/auto/Math/GSL/Matrix/Matrix.so: > undefined symbol: gsl_matrix_char_norm1 at > /usr/lib/aarch64-linux-gnu/perl-base/DynaLoader.pm line 187. > # at /<>/blib/lib/Math/GSL/Matrix.pm line 11. > # Compilation failed in require at t/00-load.t line 14. > # BEGIN failed--compilation aborted at t/00-load.t line 14. The failing architectures are the ones where char is unsigned. https://github.com/leto/math--gsl/issues/231 https://lists.gnu.org/archive/html/bug-gsl/2021-06/msg4.html are probably related but "the other way around": aiui they disabled the exposure of the unsigned char versions of the functions, which were missing on the signed char architectures. -- Niko Tyni nt...@debian.org
Bug#994699: libtest-xml-simple-perl: Test failure in t/03valid.t
On Sun, Sep 19, 2021 at 05:42:55PM +0200, gregor herrmann wrote: > Package: libtest-xml-simple-perl > Version: 1.05-2 > Severity: serious > Tags: ftbfs sid bookworm > Justification: fails to build from source (but built successfully in the past) > This is a bit suprising as we have debian/patches/bug-952180.patch > which fixes the same test (#952180), and now the issue has (almost) > reappeared the other way round although I see no obvious changes (no > uploads of neither libtest-xml-simple-perl nor libxml-libxml-perl). FWIW I expect it broke with the recent libxml2 upload. -- Niko
Bug#994736: libmath-gsl-perl: FTBFS on several architectures: undefined symbol: gsl_matrix_char_norm1
Source: libmath-gsl-perl Version: 0.43-1 Severity: serious Tags: ftbfs This package failed to build on several architectures. >From >https://buildd.debian.org/status/fetch.php?pkg=libmath-gsl-perl&arch=arm64&ver=0.43-1&stamp=1632072156&raw=0 # Failed test 'use Math::GSL::Matrix;' # at t/00-load.t line 14. # Tried to use 'Math::GSL::Matrix'. # Error: Can't load '/<>/blib/arch/auto/Math/GSL/Matrix/Matrix.so' for module Math::GSL::Matrix: /<>/blib/arch/auto/Math/GSL/Matrix/Matrix.so: undefined symbol: gsl_matrix_char_norm1 at /usr/lib/aarch64-linux-gnu/perl-base/DynaLoader.pm line 187. # at /<>/blib/lib/Math/GSL/Matrix.pm line 11. # Compilation failed in require at t/00-load.t line 14. # BEGIN failed--compilation aborted at t/00-load.t line 14. [...] Test Summary Report --- t/00-load.t (Wstat: 512 Tests: 56 Failed: 2) Failed tests: 7, 54 Non-zero exit status: 2 t/BLAS.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: Bad plan. You planned 109 tests but ran 0. t/Eigen.t(Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: Bad plan. You planned 59 tests but ran 0. t/GSL.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output t/Linalg.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output t/Matrix.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output t/Multifit.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output t/Multilarge.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output t/SparseMatrix.t (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: No plan found in TAP output Files=58, Tests=3449, 22 wallclock secs ( 1.15 usr 0.22 sys + 19.59 cusr 2.07 csys = 23.03 CPU) Result: FAIL -- Niko
Bug#993403: libobject-remote-perl: missing dependency on libstrictures-perl
Package: libobject-remote-perl Version: 0.004001-1 Severity: serious Tags: ftbfs sid bookworm This package is missing a dependency on libstrictures-perl. % perl -e 'use Object::Remote' Can't locate strictures.pm in @INC (you may need to install the strictures module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/share/perl5/Object/Remote/Proxy.pm line 3. Until recently this was masked by its dependency, libmoo-perl, depending on libstrictures-perl, but that was removed in libmoo-perl_2.005004-1. The missing dependency causes test suite failures, making the package fail to build from source and regress on ci.debian.net. The regressions are blocking libmoo-perl_2.005004-1 from entering testing. When this is fixed, libmoo-perl should declare a Breaks entry on the old versions. -- Niko Tyni nt...@debian.org
Bug#993399: libdatetimex-easy-perl: FTBFS: t/03-parse.t failure
Source: libdatetimex-easy-perl Version: 0.089-2 Severity: serious Tags: ftbfs sid bookworm patch Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=137397 This package fails its test suite on current sid. It broke with libdatetime-format-flexible-perl_0.34-1. Petr Písař says in the upstream ticket that the libdatetimex-easy-perl tests need to adapt and provides a patch there. This is currently blocking the testing migration of the new libdatetime-format-flexible-perl version because of regressions on ci.debian.net. >From >https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libdatetimex-easy-perl.html # Failed test at t/03-parse.t line 32. # got: 'America/New_York' # expected: '-0500' # Looks like you failed 1 test of 18. [...] Test Summary Report --- t/01-basic.t (Wstat: 0 Tests: 76 Failed: 0) TODO passed: 47-53 t/03-parse.t (Wstat: 256 Tests: 18 Failed: 1) Failed test: 6 Non-zero exit status: 1 Files=3, Tests=106, 3 wallclock secs ( 0.05 usr 0.02 sys + 2.17 cusr 0.22 csys = 2.46 CPU) Result: FAIL -- Niko Tyni nt...@debian.org
Bug#993330: polymake: FTBFS with Perl 5.34: error: ‘Perl_pp_keys’ was not declared in this scope
On Tue, Aug 31, 2021 at 10:48:41AM -0700, David Bremner wrote: > Niko Tyni writes: > > > This package fails to build from source with Perl 5.34 (currently > > in experimental). I don't presently understand why; I'm not aware of > > changes to Perl_pp_keys or Perl_pp_rv2hv. So the root issue might also > > be on the Perl side. At least it seems to reliably fail the same way. > > > > At least some of the build-deps [1] seem not to be rebuilt yet in > experimental. Do you have an extra repo I should add? Yes, see http://perl.debian.net/ . > Alternatively you > can try rebuilding against the polymake 4.4 in git [2]. Can do that but best not to block on me. > [1]: libterm-readkey-perl libterm-readline-gnu-perl > [2]: https://salsa.debian.org/bremner/polymake -- Niko
Bug#993397: libhostfile-manager-perl: FTBFS: You planned 65 tests but ran 64.
Source: libhostfile-manager-perl
Version: 0.09-1.1
Severity: serious
Tags: ftbfs sid bookworm
This package fails its test suite on current sid.
It probably broke with libtest-nowarnings-perl_1.06-1 which is already
in testing (not sure why autopkgtest regression checks didn't catch this.)
>From the Test-NoWarnings changelog:
Made had_no_warnings turn off the checking at END time for use with
done_testing based tests with no test count. Also added docs.
>From
>https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libhostfile-manager-perl.html
# Looks like you planned 65 tests but ran 64.
t/run.t ..
1..65
ok 1 - use Hostfile::Manager;
ok 2 - Hostfile::Manager->can('block')
ok 3 - block
ok 4 - Hostfile::Manager->can('new')
ok 5 - ... and the constructor should succeed
ok 6 - '... and the object it returns' isa 'Hostfile::Manager'
ok 7 - Hostfile::Manager->can('disable_fragment')
ok 8 - ... and fragment_enabled returns ok when fragment is indeed enabled
ok 9 - ... and disable_fragment returns ok when fragment is newly disabled
ok 10 - ... and fragment is indeed disabled
ok 11 - Hostfile::Manager->can('enable_fragment')
ok 12 - ... and enable_fragment returns ok when fragment is newly enabled
ok 13 - ... and fragment is indeed enabled
ok 14 - Hostfile::Manager->can('enable_fragment')
ok 15 - ... and enable_fragment returns ok when fragment is newly enabled
ok 16 - ... and fragment is indeed enabled
ok 17 - ... and fragment only appears once
ok 18 - ... and enable_fragment does not complain excessively when enabling
missing fragment
ok 19 - Hostfile::Manager->can('fragment_enabled')
ok 20 - ... and fragment_enabled returns ok when fragment is indeed enabled
ok 21 - ... and fragment_enabled returns not_ok when fragment is not enabled
ok 22 - Hostfile::Manager->can('fragment_list')
ok 23 - ... and fragment list matches expectation
ok 24 - Hostfile::Manager->can('fragment_status_flag')
ok 25 - ... and fragment_status_flag returns '+' when fragment is enabled
and unmodified
ok 26 - ... and fragment_status_flag returns '*' when fragment is enabled
and modified
ok 27 - ... and fragment_status_flag returns ' ' when fragment is disabled
ok 28 - Hostfile::Manager->can('get_fragment')
ok 29 - ... and get_fragment returns fragment content
ok 30 - Hostfile::Manager->can('get_fragment')
ok 31 - ... and get_fragment undef when fragment file missing
ok 32 - Hostfile::Manager->can('hostfile')
ok 33 - ... and hostfile should start out with content of file at
hostfile_path
ok 34 - ... and settings its value should NOT succeed
ok 35 - ... and settings its value did not succeed
ok 36 - hostfile should start out with content of file at hostfile_path
ok 37 - Hostfile::Manager->can('hostfile')
ok 38 - ... and hostfile should start out with content of file at
hostfile_path, even when constructed with a different hostfile_path
ok 39 - Hostfile::Manager->can('hostfile_path')
ok 40 - ... and hostfile_path should start out with default value
ok 41 - ... and setting its value should succeed
ok 42 - Hostfile::Manager->can('load_hostfile')
ok 43 - ... and load_hostfile indicates success
ok 44 - ... and load_hostfile actually loaded the file
ok 45 - Hostfile::Manager->can('load_hostfile')
ok 46 - ... and load_hostfile chokes when hostfile missing
ok 47 - Hostfile::Manager->can('load_hostfile')
ok 48 - ... and load_hostfile indicates success
ok 49 - ... and load_hostfile actually loaded the file
ok 50 - Hostfile::Manager->can('path_prefix')
ok 51 - ... and path_prefix should start out with default value
ok 52 - ... and setting its value should succeed
ok 53 - Hostfile::Manager->can('toggle_fragment')
ok 54 - ... and fragment_enabled returns ok when fragment is enabled
ok 55 - ... and toggle_fragment returns ok when fragment is newly toggled
ok 56 - ... and fragment is disabled
ok 57 - ... and toggle_fragment returns ok when fragment is newly toggled
ok 58 - ... and fragment is enabled
ok 59 - Hostfile::Manager->can('write_hostfile')
ok 60 - ... and write_hostfile returns ok
ok 61 - ... and hostfile written to t/fixtures/hosts/write_test
ok 62 - Hostfile::Manager->can('write_hostfile')
ok 63 - ... and write_hostfile chokes when trying to write to file without
permissions
ok 64 - ... and hostfile NOT written to t/fixtures/hosts/write_test
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/65 subtests
Test Summary Report
---
t/run.t (Wstat: 65280 Tests: 64 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 65 tests but ran 64.
--
Niko Tyni nt...@debian.org
Bug#993395: libconfig-ini-perl: broken by libmixin-linewise-perl
Package: libconfig-ini-perl Version: 1:0.025-1.1 Severity: serious Tags: ftbfs fixed-upstream sid bookworm As seen on ci.debian.net, this package fails its test suite with libmixin-linewise-perl/0.110-1. The regression is currently blocking libmixin-linewise-perl testing migration. The issue is presumably fixed upstream in Config-INI: 0.027 2021-06-22 22:27:53-04:00 America/New_York - require Mixin::Linewise v0.110 to cope with new error message I haven't checked if this is only build time breakage, or if run time is affected too. In the latter case libmixin-linewise-perl probably needs to add a Breaks entry. >From >https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libconfig-ini-perl.html # Failed test 'read_file on non-plain-file' # at t/reader-err.t line 30. # ''lib' is not readable at t/reader-err.t line 29. # ' # doesn't match '(?^i:not a plain file)' # Failed test 'can't read an unreadable file' # at t/reader-err.t line 51. # ''tempt6w8z' is not readable at t/reader-err.t line 50. # ' # doesn't match '(?^:(?:couldn't|can't) read)' # Looks like you failed 2 tests of 9. t/reader-err.t . 1..9 ok 1 - read_file without args ok 2 - read_file with non-existent file not ok 3 - read_file on non-plain-file not ok 4 - can't read an unreadable file ok 5 - read_string without args ok 6 - syntax error ok 7 - syntax error ok 8 - we can't read a UTF-8 file that starts with a BOM ok 9 - the error message mentions a BOM Dubious, test returned 2 (wstat 512, 0x200) Failed 2/9 subtests -- Niko Tyni nt...@debian.org
Bug#993336: libclass-trait-perl: arch:all but depends on perlapi-5.32.0
Package: libclass-trait-perl Version: 0.31-4.1 Severity: serious Tags: sid bookworm User: debian-p...@lists.debian.org Usertags: perl-5.34-transition X-Debbugs-Cc: Holger Levsen It looks like the no-change 0.31-4.1 upload introduced a regression: despite being arch:all it ships /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Class/Trait/.packlist which has made debhelper add a dependency on perlapi-5.32.0. This is broken: the package will become uninstallable when Perl 5.34 (currently in experimental) enters unstable, but it can't be automatically rebuilt as we don't do arch:all binNMUs. The reason is a hardcoded reference to the old /usr/lib/perl5 directory in debian/rules: the packlist file no longer got removed in the rebuild because it gets installed elsewhere nowadays. AFAICS when this is fixed, upgrades (even partial) from the current version should work fine, so we can live with having this in the stable release. Copying Holger who did the NMU, but mainly just FYI. I'm sure the pkg-perl folks can fix this before the Perl 5.34 transition if the maintainer doesn't. -- Niko Tyni nt...@debian.org
Bug#993335: libxml-rss-feed-perl: FTBFS with Perl 5.34: t/010_deprecated_methods.t failure
Source: libxml-rss-feed-perl Version: 2.212-1.2 Severity: normal Tags: sid bookworm ftbfs fixed-upstream User: debian-p...@lists.debian.org Usertags: perl-5.34-transition This package fails to build from source with Perl 5.34 (currently in experimental). It looks like it regressed with https://github.com/Test-More/test-more/issues/870 A test case is perl -MTest::More=no_plan -e 'cmp_ok(undef, q(eq), q(), qq(tested))' which no longer outputs a warning on stderr. The failing test has since been rewritten upstream. >From a build log: # Looks like you planned 8 tests but ran 6. t/010_deprecated_methods.t .. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 2/8 subtests Test Summary Report --- t/010_deprecated_methods.t(Wstat: 65280 Tests: 6 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 8 tests but ran 6. A full log is available at http://perl.debian.net/rebuild-logs/perl-5.34-throwaway/libxml-rss-feed-perl_2.212-1.2/libxml-rss-feed-perl_2.212-1.2_amd64-2021-08-30T11:31:45Z.build -- Niko Tyni nt...@debian.org
Bug#993334: gdal: FTBFS: configure.ac: error: required file 'config.rpath' not found
Source: gdal Version: 3.2.2+dfsg-2 Severity: serious Tags: ftbfs sid bookworm This package fails to build from source on current sid. >From a build log: configure.ac:5590: warning: The macro `AC_CHECKING' is obsolete. configure.ac:5590: You should run autoupdate. ./lib/autoconf/general.m4:2499: AC_CHECKING is expanded from... configure.ac:5590: the top level configure.ac:6030: warning: AC_OUTPUT should be used without arguments. configure.ac:6030: You should run autoupdate. configure.ac: error: required file 'config.rpath' not found dh_autoreconf: error: autoreconf -f -i returned exit code 1 make: *** [debian/rules:100: build] Error 25 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 A full log is available at https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gdal.html -- Niko Tyni nt...@debian.org
Bug#993333: weechat: FTBFS: Target "irc" links to item " use `command -v' in scripts instead
Source: weechat Version: 3.0.1-1 Severity: serious Tags: ftbfs sid bookworm This package fails to build from source on current sid. It looks like this regressed with the recent change in debianutils that made /usr/bin/which output a deprecation warning. >From a build log: -- Found GCRYPT: /usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead. -L/usr/lib/x86_64-linux-gnu -lgcrypt [...] CMake Error at src/plugins/irc/CMakeLists.txt:20 (add_library): Target "irc" links to item " use `command -v' in scripts instead. -L/usr/lib/x86_64-linux-gnu -lgcrypt" which has leading or trailing whitespace. This is now an error according to policy CMP0004. A full log is available at https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/weechat.html -- Niko Tyni nt...@debian.org
Bug#993332: gnumeric: FTBFS: Can't exec "gtkdocize": No such file or directory
Source: gnumeric Version: 1.12.48-1 Severity: serious Tags: ftbfs sid bookworm This package fails to build from source on current sid. >From a build log: dh_autoreconf --as-needed libtoolize: putting auxiliary files in '.'. libtoolize: copying file './ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. libtoolize: copying file 'm4/libtool.m4' libtoolize: copying file 'm4/ltoptions.m4' libtoolize: copying file 'm4/ltsugar.m4' libtoolize: copying file 'm4/ltversion.m4' libtoolize: copying file 'm4/lt~obsolete.m4' libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am. You should update your 'aclocal.m4' by running aclocal. Can't exec "gtkdocize": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 293. autoreconf: error: gtkdocize failed with exit status: 2 dh_autoreconf: error: autoreconf -f -i returned exit code 2 make[1]: *** [debian/rules:33: override_dh_autoreconf] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:29: binary-arch] Error 2 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 A full log is available for instance at https://buildd.debian.org/status/fetch.php?pkg=gnumeric&arch=mips64el&ver=1.12.48-1%2Bb3&stamp=1630062552&raw=0 -- Niko Tyni nt...@debian.org
Bug#993330: polymake: FTBFS with Perl 5.34: error: ‘Perl_pp_keys’ was not declared in this scope
Source: polymake
Version: 4.3-4
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.34-transition
This package fails to build from source with Perl 5.34 (currently
in experimental). I don't presently understand why; I'm not aware of
changes to Perl_pp_keys or Perl_pp_rv2hv. So the root issue might also
be on the Perl side. At least it seems to reliably fail the same way.
From the build log:
FAILED:
/<>/build/Opt/lib/perlx/5.34.0/x86_64-linux-gnu-thread-multi/RefHash.o
g++ -c -o
/<>/build/Opt/lib/perlx/5.34.0/x86_64-linux-gnu-thread-multi/RefHash.o
-MMD -MT
/<>/build/Opt/lib/perlx/5.34.0/x86_64-linux-gnu-thread-multi/RefHash.o
-MF
/<>/build/Opt/lib/perlx/5.34.0/x86_64-linux-gnu-thread-multi/RefHash.o.d
-fPIC -pipe -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=c++14 -ftemplate-depth-200 -fno-strict-aliasing
-fopenmp -Wshadow -Wlogical-op -Wconversion -Wzero-as-null-pointer-constant
-Wno-parentheses -Wno-error=unused-function -Wno-stringop-overflow
-Wno-array-bounds -DPOLYMAKE_WITH_FLINT -DPOLYMAKE_DEBUG=0 -DNDEBUG -O2
-I/usr/lib/x86_64-linux-gnu/perl/5.34/CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DPerlVersion=5340 -Wno-nonnull
-I/<>/include/core-wrappers -I/<>/include/core
/<>/build/perlx/5.34.0/x86_64-linux-gnu-thread-multi/RefHash.cc &&
: 'COMPILER_USED=10.3.0'
/<>/lib/core/src/perl/RefHash.xxs: In function ‘OP*
pm::perl::glue::{anonymous}::intercept_pp_keys(PerlInterpreter*)’:
/<>/lib/core/src/perl/RefHash.xxs:385:17: error: ‘Perl_pp_keys’
was not declared in this scope; did you mean ‘Perl_pp_akeys’?
385 | OP* ret = Perl_pp_keys(aTHX);
| ^~~~
| Perl_pp_akeys
/<>/lib/core/src/perl/RefHash.xxs:393:11: error: ‘Perl_pp_keys’
was not declared in this scope; did you mean ‘Perl_pp_akeys’?
393 |return Perl_pp_keys(aTHX);
| ^~~~
| Perl_pp_akeys
/<>/lib/core/src/perl/RefHash.xxs: In function ‘OP*
pm::perl::glue::{anonymous}::pp_rv2hv_ref_retrieve(PerlInterpreter*)’:
/<>/lib/core/src/perl/RefHash.xxs:524:14: error:
‘Perl_pp_rv2hv’ was not declared in this scope; did you mean ‘Perl_pp_rv2sv’?
524 |OP* ret = Perl_pp_rv2hv(aTHX);
| ^
| Perl_pp_rv2sv
/<>/lib/core/src/perl/RefHash.xxs: In function ‘OP*
pm::perl::glue::{anonymous}::intercept_pp_rv2hv(PerlInterpreter*)’:
/<>/lib/core/src/perl/RefHash.xxs:549:18: error:
‘Perl_pp_rv2hv’ was not declared in this scope; did you mean ‘Perl_pp_rv2sv’?
549 | PL_op = Perl_pp_rv2hv(aTHX);
| ^
| Perl_pp_rv2sv
A full build log is available at
http://perl.debian.net/rebuild-logs/perl-5.34/polymake_4.3-4/polymake_4.3-4+b2_amd64-2021-08-30T08:15:00Z.build
--
Niko Tyni nt...@debian.org
Bug#993328: openscap: FTBFS with Perl 5.34: hardcodes Perl version 5.32
Source: openscap Version: 1.3.4-1 Severity: normal User: debian-p...@lists.debian.org Usertags: perl-5.34-transition This package fails to build from source with Perl 5.34 (currently in experimental). This is because debian/rules hardcodes Perl version 5.32.0. >From the build log: chrpath -d debian/tmp/usr/bin/oscap chrpath -d debian/tmp/usr/lib/x86_64-linux-gnu/libopenscap.so.25.3.0 chrpath -d debian/tmp/usr/lib/x86_64-linux-gnu/libopenscap_sce.so.25.3.0 chrpath -d debian/tmp/usr/lib/x86_64-linux-gnu/perl5/5.32/openscap_pm.so open: No such file or directory elf_open: Invalid argument make[1]: *** [debian/rules:33: override_dh_auto_install] Error 1 A full build log is available at http://perl.debian.net/rebuild-logs/perl-5.34/openscap_1.3.4-1/openscap_1.3.4-1+b1_amd64-2021-08-29T22:29:14Z.build -- Niko Tyni nt...@debian.org
Bug#993326: jellyfish: FTBFS with Perl 5.34: hardcodes Perl version 5.32
Source: jellyfish Version: 2.3.0-11 Severity: normal User: debian-p...@lists.debian.org Usertags: perl-5.34-transition This package fails to build from source with Perl 5.34 (currently in experimental). This is because debian/rules hardcodes Perl version 5.32.0. >From the build log: make[1]: Entering directory '/<>' # Python files are just installed rm -rf debian/tmp/usr/lib/python3/dist-packages # Necessary Perl files are just installed rm -rf debian/tmp/usr/lib/perl/5.32.0 dh_missing dh_missing: warning: usr/lib/perl/5.34.0/jellyfish.a exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/perl/5.34.0/jellyfish.la exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/perl/5.34.0/jellyfish.so exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/perl/5.34.0/jellyfish.so.0 exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/perl/5.34.0/jellyfish.so.0.0.0 exists in debian/tmp but is not installed to anywhere dh_missing: error: missing files, aborting The following debhelper tools have reported what they installed (with files per package) * dh_install: jellyfish (4), jellyfish-examples (0), libjellyfish-2.0-2 (0), libjellyfish-2.0-dev (1), libjellyfish-perl (2), python3-dna-jellyfish (0) * dh_installdocs: jellyfish (3), jellyfish-examples (0), libjellyfish-2.0-2 (0), libjellyfish-2.0-dev (0), libjellyfish-perl (0), python3-dna-jellyfish (0) * dh_installexamples: jellyfish (0), jellyfish-examples (31), libjellyfish-2.0-2 (0), libjellyfish-2.0-dev (0), libjellyfish-perl (0), python3-dna-jellyfish (0) * dh_installman: jellyfish (1), jellyfish-examples (0), libjellyfish-2.0-2 (0), libjellyfish-2.0-dev (0), libjellyfish-perl (0), python3-dna-jellyfish (0) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built If the omission is intentional or no other helper can take care of this consider adding the paths to debian/not-installed. make[1]: *** [debian/rules:106: override_dh_missing] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:22: binary-arch] Error 2 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 A full build log is available at http://perl.debian.net/rebuild-logs/perl-5.34/jellyfish_2.3.0-11/jellyfish_2.3.0-11+b1_amd64-2021-08-30T07:33:15Z.build -- Niko Tyni nt...@debian.org
Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp
Package: libgsl25 Version: 2.7+dfsg-2 Control: affects -1 libmath-gsl-perl Severity: serious gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest regressions: not ok 7 - use Math::GSL::Matrix; # Failed test 'use Math::GSL::Matrix;' # at t/00-load.t line 14. # Tried to use 'Math::GSL::Matrix'. # Error: Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for module Math::GSL::Linalg: /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: undefined symbol: gsl_linalg_QR_TR_decomp at /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187. # � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 11. # Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. # BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210. # Compilation failed in require at t/00-load.t line 14. # BEGIN failed--compilation aborted at t/00-load.t line 14. ok 8 - use Math::GSL::Poly; not ok 9 - use Math::GSL::MatrixComplex; It seems that the 2.7 upload broke the ABI of libgsl25 by removing the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from entering testing because of this regression in libmath-gsl-perl_0.42-1. Looks like upstream Math-GSL-0.43 probably no longer references this symbol, but it's not in Debian yet and I haven't built and verified that. Clearly at least something must be done on the libgsl side. Not sure if it needs to restore the symbol or bump its SONAME, or if just a Breaks on older libmath-gsl-perl versions is enough. (See policy 8.6.2) I've also filed the separate bug #993323 about libmath-gsl-perl failing to build with GSL 2.7. That should be fixed just by upgrading it to 0.43. -- Niko Tyni nt...@debian.org
Bug#993323: libmath-gsl-perl: FTBFS: Unsupported GSL version!!! : 2.7
Source: libmath-gsl-perl Version: 0.42-1 Severity: serious Tags: ftbfs sid bookworm fixed-upstream This package fails to build on current sid. Checking for GSL using gsl-config Found GSL 2.7 (via gsl-config) installed in /usr Checking if x86_64-linux-gnu-gcc supports "-Wall"...yes Checking if x86_64-linux-gnu-gcc supports "-Wno-sometimes-uninitialized"...yes Checking if x86_64-linux-gnu-gcc supports "-Wno-unused-function"...yes Checking if x86_64-linux-gnu-gcc supports "-Wno-unused-value"...yes Checking if x86_64-linux-gnu-gcc supports "-Wno-unused-function"...yes Checking if x86_64-linux-gnu-gcc supports "-Wno-unused-variable"...yes Checking if x86_64-linux-gnu-gcc supports "-Wno-gnu"...yes Checking if x86_64-linux-gnu-gcc supports "-g"...Unsupported GSL version!!! : 2.7 at Build.PL line 80. yes dh_auto_configure: error: /usr/bin/perl Build.PL --installdirs vendor --config "optimize=-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --config "ld=x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now" returned exit code 25 make: *** [debian/rules:9: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 This clearly broke with gsl 2.7+dfsg-2. It's should be fixed upstream in 0.43. A complication is that gsl 2.7 also broke libmath-gsl-perl on run time by removing a symbol. I'll report this separately against libgsl25. -- Niko Tyni nt...@debian.org
Bug#974199: libnet-nis-perl ftbfs with glibc-2.32
Control: retitle -1 libnet-nis-perl: ftbfs with glibc 2.31-14: rpc/rpc.h: No such file or directory Control: tags -1 - bullseye Control: tags -1 + bookworm ftbfs Control: severity -1 serious On Wed, Nov 11, 2020 at 09:35:01AM +0100, Matthias Klose wrote: > Package: libnet-nis-perl > Version: 0.44-1 > Severity: important > Tags: sid bullseye patch > > patch at > http://launchpadlibrarian.net/506401684/libnet-nis-perl_0.44-1build7_0.44-1ubuntu1.diff.gz The package now fails to build on current sid, presumably because of glibc (2.31-14) unstable; urgency=medium [...] * debian/rules.d/build.mk: stop passing --enable-obsolete-rpc. Raising the severity. -- Niko Tyni nt...@debian.org
Bug#957392: juman: ftbfs with GCC-10
On Fri, Apr 17, 2020 at 11:03:26AM +, Matthias Klose wrote: > Package: src:juman > Version: 7.0-3.4 > Severity: normal > Tags: sid bullseye > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-10 > > Please keep this issue open in the bug tracker for the package it > was filed for. If a fix in another package is required, please > file a bug for the other package (or clone), and add a block in this > package. Please keep the issue open until the package can be built in > a follow-up test rebuild. > > The package fails to build in a test rebuild on at least amd64 with > gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The > severity of this report will be raised before the bullseye release, > so nothing has to be done for the buster release. > Making all in dic > make[4]: Entering directory '/<>/dic' > gcc -E -P JUMAN.connect.c | LANG=C sed "s/\(\#pragma\)/\;\1/" > JUMAN.connect > ../makemat/makemat > JUMAN.kankei parsing... done. > > JUMAN.connect parsing... > /<>/makemat/.libs/makemat: U5f62U5bb9U8a5e is > undefined in JUMAN.grammar . > exit(11) > make[4]: *** [Makefile:532: jumandic.tab] Error 11 Somewhat surprisingly, this package now builds successfully on current sid without any changes. It still fails on bullseye. It looks like this is because configure.ac is missing AC_PROG_CPP, which was tolerated by earlier versions of the toolchain but apparently not anymore. This causes an error that gets ignored but the build continues after that. Making all in dic make[4]: Entering directory '/build/1st/juman-7.0/dic' Makefile:524: warning: ignoring prerequisites on suffix rule definition /bin/bash: line 1: CPP@: command not found ../makemat/makemat JUMAN.kankei parsing... done. JUMAN.connect parsing... (table size 1254) done. I've tested that adding AC_PROG_CPP makes the build fail the same way as earlier. No idea if the current build result is broken or not so leaving the severity as-is. -- Niko Tyni nt...@debian.org
Bug#989393: h2ph wrong destination directory
Control: severity -1 minor
On Wed, Jun 02, 2021 at 03:53:49PM +0200, Daniele Primon wrote:
> Package: perl
> Version: 5.28.1-6+deb10u1
>
> h2ph fails with the following message.
>
> $ h2ph
> Destination directory /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 doesn't
> exist or isn't a directory
Yeah. It wants to write in $Config{installsitearch} by default, but
that doesn't exist on Debian if no packages have been installed directly
from CPAN.
The destination directory can be overridden with '-d' so it's still usable.
The whole h2ph is really an abomination that should die. Please don't
rely on it for anything new. See also #510984.
--
Niko Tyni nt...@debian.org
Bug#990305: Introduce ARC support in Perl cross-compiling for Debian
On Fri, Aug 27, 2021 at 11:30:48PM +0200, Helmut Grohne wrote: > TL;DR: This is a kludge, not a solution. Thanks for your reply. I certainly agree. > On Fri, Aug 27, 2021 at 10:38:12PM +0300, Niko Tyni wrote: > > I assume "tested in rebootstrap build" means the package builds, but > > did anybody test the resulting packages? > > I certainly did not. In particular, the main line of rebootstrap does > not cross build perl. I didn't mean to imply you should have tested it, apologies if it came out that way. That part was mostly aimed at Evgeniy as the bug submitter. > > I'm copying Helmut. Do you have any suggestions? Should I just take this > > in and leave it to porters to worry about breakage? > > I don't have an opinion here. Personally, I do not consider the way perl > performs cross builds sustainable. That is the reason why rebootstrap > still does not cross build perl to this date. I don't consider it sustainable either, and I'd be surprised if anybody did. It's a workaround to the lack of cross build support in Configure, which still hasn't been fixed. I'm pessimistic of that ever happening. The current hack of importing probe results from native builds has a couple of upsides: it makes it possible to notice when other bits of cross build support in the packaging rot away, and it gives us a collection of probed values on different architectures with a history of which bits change and which stay constant over releases. But seeing that the hack is now over five years old and nothing has changed does make me wonder if I should drop it altogether so that the real issue would become more visible. BTW I've also come across https://arsv.github.io/perl-cross/ which looks interesting but hard to integrate cleanly in the Debian packaging. > I still believe that the way to cross build perl is to make Configure > (mostly) work for cross builds. The biggest step towards that has > already been performed by generating Configure from source. Thank you. I > believe that we can now rework it (and in part this has already happened > upstream) to need less and less run tests. At some point, we'll reach a > small and maintainable set of test results that does not have to be > regenerated with every perl release. I'm glad if you see progress here. > > BTW, our development is currently targeting 5.34 so somebody needs to > > port this. I'm not sure if there will be another 5.32 upload before > > we get 5.34 in unstable. > > That is why I find it unsustainable. > > If you deem the effort for updating those files for arc ok, so be it. > From my pov, it would be sufficient to start shipping them for arc once > it becomes a ports architecture using the usual machinery. Right. I don't intend to update any of those files manually myself. All I currently do is run a script to extract them for the latest binary builds on Debian buildds (including debian-ports). For now, I'm leaning towards making a policy of only including config.sh files from native package builds rather than possibly broken handcrafted ones. -- Niko
Bug#990305: Introduce ARC support in Perl cross-compiling for Debian
On Fri, Jun 25, 2021 at 08:59:44AM +, Evgeniy Didin wrote: > Package: perl > Version: 5.32.1-4 > > Currently ARC CPU is not supported in Perl cross-compiling for Debian due to > missing files in debian/cross/ directory. > To enable cross-compiling for ARC the patch was prepared and located here: > https://salsa.debian.org/EvgeniyD/perl/-/commit/b7a9cd6499a91b59585394b1cad10cbdbd4512a4 > > I am not attaching the patch to this report because the size is more than > thousand lines. > > I am using Debian GNU/Linux 9.13 release, kernel - 3.10.0-693.11.6.el7.x86_64 > > This patch was tested in rebootstrap build. Hi, thanks for the report. I'm happy if the cross build hack in src:perl is useful but I'm not quite sure what to do about this. Eyeballing the patch, I think that cross building with this config would result in a broken package due to at least missing -DDEBIAN in ccflags. Also, -DAPPLLIB_EXP="/usr/lib/aarch64-linux-gnu/perl-base" looks wrong, and possibly breaks the perl-base package when used without perl et al. I doubt these are the only problems. I assume "tested in rebootstrap build" means the package builds, but did anybody test the resulting packages? I'm copying Helmut. Do you have any suggestions? Should I just take this in and leave it to porters to worry about breakage? BTW, our development is currently targeting 5.34 so somebody needs to port this. I'm not sure if there will be another 5.32 upload before we get 5.34 in unstable. -- Niko Tyni nt...@debian.org
Bug#914128: perl: usrmerge issues
On Tue, Aug 24, 2021 at 09:55:38PM +0300, Niko Tyni wrote: > On Thu, Jul 15, 2021 at 04:36:10PM -0700, Vagrant Cascadian wrote: > > Attached patch also fixes these issues, by adjusting libpth and libspath > > in debian/config.over ... it feels a little hackish ... but ... > > Yeah. The "pristine" probed values of libpth and libspath on a > non-usrmerged system look messy enough (/lib/../lib and the like) that > it might be more robust to just override them to some cleaner hardcoded > values rather than have more logic that tries to imitate the mess on > usrmerged systems. But I'll see how that works out. For the record, I came up with a cleaner fix (calling realpath with --no-symlinks in libpth.U). It's specific to 5.34 which has changes in that unit, so I expect I won't be fixing this in the 5.32 series. Will upload the 5.34 fixes to experimental this weekend or so. Thanks again, -- Niko
Bug#992200: perl: regen-configure orig tarball file exclusions
On Sun, Aug 15, 2021 at 08:00:42PM +0300, Niko Tyni wrote: > Source: perl > Version: 5.32.1-5 > I'm somewhat at loss. While I'd like to drop the repacking, it seems > that keeping it is a safer course to make sure we ship things with their > source. > > If we keep the repacking, we should at least add a sanity check to make > sure we don't accidentally import pristine tarballs anymore. FWIW at least for 5.34.0 I'm currently inclined to keep the repacking and add a sanity check to make sure the recipe was followed. We can revisit this later if necessary. -- Niko
Bug#914128: perl: usrmerge issues
On Thu, Jul 15, 2021 at 04:36:10PM -0700, Vagrant Cascadian wrote: > On 2021-07-15, Vagrant Cascadian wrote: > > On 2018-11-19, Niko Tyni wrote: > >> Diffoscoping a perl built on a usrmerged [1] system with > >> one built on a non-usrmerged system reveals the configure > >> process hardcoding some paths in the build results, > With all three patches applied, perl builds reproducibly! Many thanks! > Attached patch also fixes these issues, by adjusting libpth and libspath > in debian/config.over ... it feels a little hackish ... but ... Yeah. The "pristine" probed values of libpth and libspath on a non-usrmerged system look messy enough (/lib/../lib and the like) that it might be more robust to just override them to some cleaner hardcoded values rather than have more logic that tries to imitate the mess on usrmerged systems. But I'll see how that works out. I'll try to get this fixed in 5.34 / experimental soonish, but it might only enter sid with the 5.34 transition that we should really start driving. 5.32 is not a development priority at this point. (No need to rebase the patches or anything though, happy to handle that.) -- Niko Tyni nt...@debian.org
Bug#992523: cpio breaks perl autopkgtest on armhf and i386: realloc(): invalid next size
Control: reassign -1 cpio 2.13+dfsg-6 On Thu, Aug 19, 2021 at 08:40:19PM +0200, Paul Gevers wrote: > Source: cpio, perl > Control: found -1 cpio/2.13+dfsg-6 > Control: found -1 perl/5.32.1-5 > Severity: serious > Tags: sid bookworm > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of cpio the autopkgtest of perl fails in testing > when that autopkgtest is run with the binary packages of cpio from > unstable. It passes when run with only packages from testing. > autopkgtest [09:23:59]: test verify-configure: [--- > realloc(): invalid next size > Aborted > make: debian/rules: No such file or directory > make: *** No rule to make target 'debian/rules'. Stop. > autopkgtest [09:24:00]: test verify-configure: ---] That test just runs cpio in pass-through mode: #!/bin/sh mkdir $AUTOPKGTEST_TMP/source find . -print0 | cpio -p0d $AUTOPKGTEST_TMP/source cd $AUTOPKGTEST_TMP/source make -f debian/rules verify-configure-stamp Can't see how perl could be at fault for cpio crashing so reassigning. -- Niko
Bug#985957: usrmerge has 47.3MB of dependencies
On Mon, Aug 16, 2021 at 12:11:26AM +0200, Marco d'Itri wrote: > I see no reason to move the usrmerge dependencies to perl-base: usrmerge > is supposed to be installed, run and then removed again. > If something is moved to perl-base then it will use space on every > Debian system. My suggestion in #987615 (which I also copied to usrmerge@pdo, being unaware of #985957) is to introduce separate packages of the usrmerge dependencies, and limit their dependencies to perl-base only. This does not grow perl-base and can be phased out later, so it does not impose a permanent cost on everybody. -- Niko Tyni nt...@debian.org
Bug#987615: Bug#985957: usrmerge has 47.3MB of dependencies
On Tue, Apr 06, 2021 at 02:17:00PM +0100, Dimitri John Ledkov wrote: > On Tue, 6 Apr 2021 at 14:04, Ansgar wrote: > > > > On Fri, 26 Mar 2021 22:12:33 + Dimitri John Ledkov wrote: > > > I don't know what is the correct process to follow here. For example, > > > could the 5.32 things be promoted from modules to perl-base? > > > > What gets included in the (essential) perl-base package is decided by > > Debian. > > > > I think it would be a fair request to ask for usrmerge's dependencies > > to be included there if we install usrmerge by default on upgrades to > > covert existing systems. The dependencies could probably be dropped > > again for bookworm+1 (with perl-base having `Breaks: usrmerge (<< X)` > > where `X` is the version of usrmerge depending on perl instead of perl- > > base again). Just a note that this #985957 is also #987615 (cc'd) on the perl side. Now that bookworm development is open I'll see what we can do there. -- Niko
Bug#992200: perl: regen-configure orig tarball file exclusions
Source: perl Version: 5.32.1-5 We're not including the metaconfig (= regen-configure) original tarball in a consistent way. We have uscan(1) machinery in debian/watch and debian/copyright to filter out bin/ and repack to .xz, but it looks like we're not using that. The filtering was added pretty early in commit a42e63561fdfa1ed091cabcfe2b176d1bcac33ff Author: Niko Tyni Date: Sat Oct 14 16:06:17 2017 +0300 Add machinery for generating the regen-configure component tarball We filter out bin/* from the upstream repo with Files-Excluded because they are generated files from dist sources. The aim is to use the Debian packaged dist binaries (mainly metaconfig) together with the unit probes that were taken from an earlier dist version (possibly 3.5.20). Later I added the .xz repacking with commit 6f5580f38188e6b0c9b12c110058c2db758183c3 Author: Niko Tyni Date: Thu May 17 21:14:30 2018 +0300 Use xz compression for component tarball This makes the tarball reproducible AFAICS the machinery was used for the 5.28 series, but all tarballs after that were imported as .gz without filtering/repacking. We need to decide what to do going forward. Other things being equal, using the pristine .gz tarball from Github would seem preferrable to me, assuming Github serves it in a reproducible way (which it seems to do in my quick tests.) The argument about bin/* being generated files from dist sources is still true. OTOH looking at src:dist the sources seem to be just small shell extraction wrappers around the scripts. FWIW if this is a DFSG violation, it's present in bullseye too (but not buster). Another reason for the filtering was to make sure we use the separately packaged dist binaries rather than the ones in the tarball. Clearly things have worked fine without this safeguard. If it still feels necessary I suppose we could replace it with some mv(1) dance in the update-configure-stamp target. Using .gz tarballs for regen-configure and .xz for Perl itself leads into some trouble around #898026, but we seem to have managed with the workaround documented in README.source. I'm somewhat at loss. While I'd like to drop the repacking, it seems that keeping it is a safer course to make sure we ship things with their source. If we keep the repacking, we should at least add a sanity check to make sure we don't accidentally import pristine tarballs anymore. Thoughts? -- Niko
Bug#992199: perl: bumping Breaks for small patches doesn't work with versioned Provides
Source: perl Version: 5.32.1-5 While fixing https://security-tracker.debian.org/tracker/CVE-2021-36770 in Encode, we noticed that we could not bump the Breaks in libperl5.32 the way we expected to forbid a combination of a patched Perl core package and an unpatched separate libencode-perl package. (The problem about this combination is that the separate package has precedence on @INC, so it hides the fixed version.) Specifically, as perl Provides: libencode-perl (= 3.06) we couldn't make libperl5.32 Break libencode-perl (<< 3.08-1+deb11u1) as that would have made perl uninstallable. Bumping the Provides to 3.06-1+deb11u1 would not help, and bumping them past 3.08 would be lying. The best I came up with would be to add an epoch, and that seemed too intrusive. In the context of security updates, it does not seem surprising that a partial upgrade can leave the system vulnerable. So we decided to live with this. I'm filing this mostly to document the general issue. I'm not sure if there's a solution other than the epoch one, but maybe somebody else finds one. If not, we can probably live with it in the future too. The last time we needed this feature was in 5.26.1-4, before we adopted versioned Provides. -- Niko
Bug#988900: perl/experimental: FTBFS on x32: t/io/msg.t failure
Source: perl Version: 5.34.0~rc2-1 Severity: normal Tags: ftbfs User: debian-...@lists.debian.org Usertags: port-x32 ftbfs-x32 X-Debbugs-Cc: jrt...@debian.org perl 5.34 fails to build on x32: t/io/msg . # Failed test 2 - send a message at io/msg.t line 54 # Failed test 3 - send a message (upgraded) at io/msg.t line 62 # Failed test 4 - send a message (upgraded receiver) at io/msg.t line 69 FAILED at test 2 The test is new with 5.34, so this does not indicate a regression in functionality. Jessica Clarke (cc'd) says this is expected as SysV IPC is broken on x32 and suggests we skip the test for now but leave a bug open in the BTS. https://lkml.org/lkml/2020/10/12/869 seems to be relevant. -- Niko Tyni nt...@debian.org
Bug#988790: also libxml-grddl-perl
clone 988790 -1 reassign -1 libxml-grddl-perl 0.004-2 retitle -1 libxml-grddl-perl: FTBFS: Undefined subroutine &Scalar::Util::set_prototype called thanks On Wed, May 19, 2021 at 05:51:36PM +0100, Niko Tyni wrote: > Source: libhttp-lrdd-perl > Version: 0.106-2 > Severity: serious > Tags: ftbfs > > This package fails to build from source on current sid. > > # Failed test 'use HTTP::LRDD;' > # at t/01basic.t line 19. > # Tried to use 'HTTP::LRDD'. > # Error: Undefined subroutine &Scalar::Util::set_prototype called at > /usr/share/perl5/Types/TypeTiny.pm line 360. > > Full logs available at > https://tests.reproducible-builds.org/debian/libhttp-lrdd-perl > > According to the test history there, this regressed between 2020-10-29 and > 2020-11-03, > probably with libtype-tiny-perl 1.012000-1. > > #975208 looks similar and indicates this is probably an issue with an > outdated Scalar::Util in inc/ . I don't know why libhttp-lrdd-perl wasn't > spotted back then, but better late than never I guess. Similarly for libxml-grddl-perl, see https://tests.reproducible-builds.org/debian/libxml-grddl-perl -- Niko
Bug#988790: also librdf-rdfa-parser-perl
clone 988790 -1 reassign -1 librdf-rdfa-parser-perl 1.097-1 retitle -1 librdf-rdfa-parser-perl: FTBFS: Undefined subroutine &Scalar::Util::set_prototype called thanks On Wed, May 19, 2021 at 05:51:36PM +0100, Niko Tyni wrote: > Source: libhttp-lrdd-perl > Version: 0.106-2 > Severity: serious > Tags: ftbfs > > This package fails to build from source on current sid. > > # Failed test 'use HTTP::LRDD;' > # at t/01basic.t line 19. > # Tried to use 'HTTP::LRDD'. > # Error: Undefined subroutine &Scalar::Util::set_prototype called at > /usr/share/perl5/Types/TypeTiny.pm line 360. > > Full logs available at > https://tests.reproducible-builds.org/debian/libhttp-lrdd-perl > > According to the test history there, this regressed between 2020-10-29 and > 2020-11-03, > probably with libtype-tiny-perl 1.012000-1. > > #975208 looks similar and indicates this is probably an issue with an > outdated Scalar::Util in inc/ . I don't know why libhttp-lrdd-perl wasn't > spotted back then, but better late than never I guess. Similarly for librdf-rdfa-parser-perl, see https://tests.reproducible-builds.org/debian/librdf-rdfa-parser-perl -- Niko
Bug#988790: libhttp-lrdd-perl: FTBFS: Undefined subroutine &Scalar::Util::set_prototype called
Source: libhttp-lrdd-perl Version: 0.106-2 Severity: serious Tags: ftbfs This package fails to build from source on current sid. # Failed test 'use HTTP::LRDD;' # at t/01basic.t line 19. # Tried to use 'HTTP::LRDD'. # Error: Undefined subroutine &Scalar::Util::set_prototype called at /usr/share/perl5/Types/TypeTiny.pm line 360. Full logs available at https://tests.reproducible-builds.org/debian/libhttp-lrdd-perl According to the test history there, this regressed between 2020-10-29 and 2020-11-03, probably with libtype-tiny-perl 1.012000-1. #975208 looks similar and indicates this is probably an issue with an outdated Scalar::Util in inc/ . I don't know why libhttp-lrdd-perl wasn't spotted back then, but better late than never I guess. -- Niko Tyni nt...@debian.org
Bug#988673: centreon-connectors: FTBFS: Could not find libgcrypt's headers
Source: centreon-connectors Version: 19.10.0-1 Severity: serious Tags: ftbfs sid This package fails to build from source on current sid/amd64. See for instance https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/centreon-connectors.html -- The CXX compiler identification is GNU 10.2.1 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/g++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2") CMake Error at CMakeLists.txt:110 (message): Could not find libgcrypt's headers (try WITH_LIBGCRYPT_INCLUDE_DIR). -- Configuring incomplete, errors occurred! See also "/<>/ssh/build/CMakeFiles/CMakeOutput.log". make[1]: *** [debian/rules:26: override_dh_auto_configure] Error 1 This seems to have regressed when libssh2-1-dev 1.9.0-3 dropped its dependency on libgcrypt20-dev. The libssh2 change is currently blocked from entering testing, so this issue only affects sid at least for now. -- Niko Tyni nt...@debian.org
Bug#987013: Release goal proposal: Remove Berkeley DB
On Fri, Apr 16, 2021 at 08:29:52PM +0200, Bastian Blank wrote: > On Fri, Apr 16, 2021 at 05:04:03PM +0200, Marco d'Itri wrote: > > And then all the packages currently depending on libdb5.3 will need to > > implement, or at least document, a transition strategy. > > My first goal would be to drop it from base packages, so not every > system out there needs to have it installed. Hi, please note that there's a number of indirect users of libdb via interpreter packages - at least Perl, presumably Python too. Given perl gets installed on almost all systems, this seems to to be on the path to the first goal. For the perl core, the libdb5.3 bindings are exposed with the DB_File module. I think this is the only place but have not cross-checked that. (The libberkeleydb-perl package is an entirely separate matter AIUI.) I see 110 source packages in Debian matching DB_File. The list will need to be inspected manually to weed out false positives. The remaining packages need to be changed before perl can drop its libdb5.3 dependency. I suppose this will also need a long list of Breaks declarations on the perl side. Then there's user code too. I also think we'll need at least a dumper utility so that users can migrate their data manually when they discover their program no longer works after upgrading. -- Niko Tyni nt...@debian.org
Bug#987615: perl-base: please ship modules used by usrmerge in perl-base
On Mon, Apr 26, 2021 at 03:26:02PM +0100, Dimitri John Ledkov wrote: > Please consider moving things that usrmerge & libfile-find-rule-perl > use from per/perl-modules to perl-base. > > Specifically please move: > > Fatal.pm > File/Find.pm > Tie/RefHash.pm > autodie.pm > autodie/Scope/Guard.pm > autodie/Scope/GuardStack.pm > autodie/Util.pm > if.pm I note that all of these except File::Find are dual life: they are also released separately upstream on CPAN. We have a well working process for introducing separate packages of dual life modules to Debian, mainly used when the CPAN versions are frequently released and gain features that have not made it into the core versions yet. We could use the same process to introduce separate packages of the above modules, and limit their dependencies to just perl-base. The separate packages can later be phased out easily when this one-time need is over. I think this would be a clean way to handle the issue. As for File::Find, moving it to perl-base does not seem a huge burden. It's just 22K after stripping POD documentation (as we customarily do for the modules in perl-base) and seems unlikely to gain new dependencies or functionality in the future. Alternatively, building a separate libfile-find-perl binary package from src:perl should also be doable. -- Niko Tyni nt...@debian.org
Bug#987615: perl-base: please ship modules used by usrmerge in perl-base
On Mon, Apr 26, 2021 at 03:26:02PM +0100, Dimitri John Ledkov wrote: > Package: perl-base > Version: 5.30.3-4 > Severity: normal > > Dear Maintainer, > > usrmerge will be needed to be installed upon upgrades to bookworm to > convert systems to merged /usr. It would be helpful for small installs > to be able to perform that without installing the larger perl package. Thanks for raising this early. I'm copying the usrmerge maintainer. > Please consider moving things that usrmerge & libfile-find-rule-perl > use from per/perl-modules to perl-base. I understand the concern, but I'm hesitant to do this. See below. > In bookworm+1 you may drop these things from perl-base and add breaks > on usrmerge. Quoting the Debian policy: Maintainers should take great care in adding any programs, interfaces, or functionality to essential packages. Packages may assume that functionality provided by essential packages is always available without declaring explicit dependencies, which means that removing functionality from the Essential set is very difficult and is almost never done. Any capability added to an essential package therefore creates an obligation to support that capability as part of the Essential set in perpetuity. Have other avenues been investigated? How critical is the libfile-find-rule-perl dependency - would it be hard to replace it with something that's already in the Essential set, for instance piping from find(1) ? Could autodie usage be replaced with explicit error handling? Is Perl the right language to implement the migration in the first place? A small binary with minimal external dependencies would seem preferable. -- Niko Tyni nt...@debian.org
Bug#976704: po4a: Missing dependency on libpod-parser-perl
On Sun, Apr 25, 2021 at 09:40:02PM +0300, Adrian Bunk wrote: > Control: reassign -1 perl 5.32.0-6 > Control: retitle -1 perl needs Breaks on more perl-modules-* packages > Control: severity -1 serious > Control: affects -1 po4a > > On Mon, Dec 07, 2020 at 09:24:57AM +0100, Helge Kreutzmann wrote: > >... > > Versions of packages po4a depends on: > >... > > ii perl5.32.0-5 > > ii perl-modules-5.22 [libpod-parser-perl] 5.22.2-5 > >... > > 5.32 != 5.22 > > #97 already fixed the same problem for perl-modules-5.24. Indeed. As discussed there, certain versions of perl-modules-* in the past Provided virtual packages such as libpod-parser-perl, without making sure that those bundled modules were usable with the current /usr/bin/perl on the system. This property broke later when perl was upgraded. Versions earlier than 5.22 were not affected, and the issue was fixed in perl-modules-5.26 5.26.2-5 with #899110. 5.24 (which was in stretch) is already handled but I missed the other versions. So this only happens with packages that were never in a stable release. Not sure if that affects the severity. It should be easy to fix by adding Breaks: perl-modules-5.22, perl-modules-5.26 (<< 5.26.2-5) Any regressions seem improbable given these are leftovers from a time before the current stable release. Ubuntu has released with both 5.22 and an affected version of 5.26. Haven't heard of similar issues there but a fix would possibly help their users too (at least eventually.) In general the coinstallability of older libperl5.xx and perl-modules-5.xx packages with current ones is desirable to ease upgrades of packages linking against libperl, such as postgresql. -- Niko Tyni nt...@debian.org
Bug#953562: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
On Wed, Apr 14, 2021 at 08:50:46PM +0200, Paul Gevers wrote: > Hi Ivo, Marco, > > On 06-04-2021 22:10, Ivo De Decker wrote: > > I ran a number of (partial and full) upgrade tests, and they all seem to > > work > > fine. In all cases, libcrypt1 is installed before libc6, and there is no > > intermediate situations where libcrypt.so.1 is missing. > > The patch looks sensible after reading the discussion in these bugs. Can > we have an upload soon to have exposure? Hi, thanks for your work on this and sorry I'm chiming in so late. I'm concerned that AFAICS no change in src:libxcrypt can make sure that the new libc6 is never unpacked before libcrypt1. (buster-amd64)# dpkg --unpack libc6_2.31-11_amd64.deb (Reading database ... 12224 files and directories currently installed.) Preparing to unpack libc6_2.31-11_amd64.deb ... debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline Unpacking libc6:amd64 (2.31-11) over (2.28-10) ... (buster-amd64)# perl perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory It may well be enough to make this improbable enough in practice. Ivo's testing certainly seems to indicate so. It still makes me a bit uneasy. I'm happy to be proved wrong of course. Do the Important or Protected fields in the patch affect apt's behaviour in this, for instance? The solution Aurelien mentioned of copying the old libcrypt in libc6.preinst and cleaning up in libc6.postinst would eliminate this failure mode totally. But I can see it's not very desirable and may be hard to make robust. Just wanted to bring this up explicitly. Not objecting if we deem the risk of remaining corner case issues small enough that it's worth taking. -- Niko
Bug#985270: Resignation + Call for votes for new Chair
On Mon, Mar 15, 2021 at 10:30:59AM +0100, Margarita Manterola wrote: > ===BEGIN=== > > The chair of the Debian Technical Committee will be: > > A : Margarita Manterola > B : David Bremner > C : Niko Tyni > D : Gunnar Wolf > E : Simon McVittie > F : Sean Whitton > G : Elana Hashman > H : Christoph Berg > > ===END=== I vote: F > A = G > E > B = D > C > H Sean: thanks for volunteering. -- Niko signature.asc Description: PGP signature
Bug#983340: unblock/preapproval: perl/5.32.1-3 with cross build fixes
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: p...@packages.debian.org, Helmut Grohne This is a pre-approval request as perl is part of build-essential and currently frozen. I'd like to fix #983099 by refreshing the cross build support files in the perl source package and updating the documentation a bit. The cross build support files are a workaround for the lack of cross configuration support in perl's Configure system. They need to be refreshed for new upstream versions, and this has not been done for 5.32.1 yet. As Helmut argues in #983099, having a cross buildable perl in stable would be desirable. These updates have been done routinely for several years now. The files have no run time effect, they are only used for cross builds, which are currently failing. The debdiff is unfortunately big; I'm only attaching the diffstat. The full proposed diff is available at https://people.debian.org/~ntyni/perl/perl_5.32.1-3.debdiff Thanks for your work on the release, -- Niko Tyni nt...@debian.org debian/README.source | 12 ++ debian/changelog |8 debian/cross/README | 23 +++ debian/cross/alpha/config.sh.debug.patch | 22 +-- debian/cross/alpha/config.sh.shared.patch | 26 ++--- debian/cross/alpha/config.sh.static | 52 +- debian/cross/amd64/config.sh.debug.patch | 22 +-- debian/cross/amd64/config.sh.shared.patch | 26 ++--- debian/cross/amd64/config.sh.static | 52 +- debian/cross/arm64/config.sh.debug.patch | 22 +-- debian/cross/arm64/config.sh.shared.patch | 26 ++--- debian/cross/arm64/config.sh.static | 52 +- debian/cross/armel/config.sh.debug.patch | 22 +-- debian/cross/armel/config.sh.shared.patch | 26 ++--- debian/cross/armel/config.sh.static | 52 +- debian/cross/armhf/config.sh.debug.patch | 22 +-- debian/cross/armhf/config.sh.shared.patch | 26 ++--- debian/cross/armhf/config.sh.static | 52 +- debian/cross/hppa/config.sh.debug.patch | 22 +-- debian/cross/hppa/config.sh.shared.patch | 26 ++--- debian/cross/hppa/config.sh.static| 52 +- debian/cross/hurd-i386/config.sh.debug.patch | 22 +-- debian/cross/hurd-i386/config.sh.shared.patch | 26 ++--- debian/cross/hurd-i386/config.sh.static | 52 +- debian/cross/i386/config.sh.debug.patch | 22 +-- debian/cross/i386/config.sh.shared.patch | 26 ++--- debian/cross/i386/config.sh.static| 52 +- debian/cross/ia64/config.sh.debug.patch | 22 +-- debian/cross/ia64/config.sh.shared.patch | 26 ++--- debian/cross/ia64/config.sh.static| 52 +- debian/cross/m68k/config.sh.debug.patch | 22 +-- debian/cross/m68k/config.sh.shared.patch | 26 ++--- debian/cross/m68k/config.sh.static| 52 +- debian/cross/mips64el/config.sh.debug.patch | 22 +-- debian/cross/mips64el/config.sh.shared.patch | 26 ++--- debian/cross/mips64el/config.sh.static| 52 +- debian/cross/mipsel/config.sh.debug.patch | 22 +-- debian/cross/mipsel/config.sh.shared.patch| 26 ++--- debian/cross/mipsel/config.sh.static | 52 +- debian/cross/powerpc/config.sh.debug.patch| 22 +-- debian/cross/powerpc/config.sh.shared.patch | 26 ++--- debian/cross/powerpc/config.sh.static | 52 +- debian/cross/ppc64/config.sh.debug.patch | 22 +-- debian/cross/ppc64/config.sh.shared.patch | 26 ++--- debian/cross/ppc64/config.sh.static | 52 +- debian/cross/ppc64el/config.sh.debug.patch| 22 +-- debian/cross/ppc64el/config.sh.shared.patch | 26 ++--- debian/cross/ppc64el/config.sh.static | 52 +- debian/cross/riscv64/config.sh.debug.patch| 22 +-- debian/cross/riscv64/config.sh.shared.patch | 26 ++--- debian/cross/riscv64/config.sh.static | 52 +- debian/cross/s390x/config.sh.debug.patch | 22 +-- debian/cross/s390x/config.sh.shared.patch | 26 ++--- debian/cross/s390x/config.sh.static | 52 +- debian/cross/sh4/config.sh.debug.patc
Bug#983099: perl FTCBFS: cross configs outdated
On Fri, Feb 19, 2021 at 09:22:32PM +, Dominic Hargreaves wrote: > On Fri, Feb 19, 2021 at 11:00:20AM +0100, Helmut Grohne wrote: > > Source: perl > > Version: 5.32.1-2 > > Severity: important > > X-Debbugs-Cc: debian-rele...@lists.debian.org > > User: debian-cr...@lists.debian.org > > Usertags: ftcbfs > > > > perl currently fails to cross build from source, due to a minor version > > bump. Whenever the version is updated, the cross compilation configs > > need to be updated and this didn't happen for perl. > Niko, I see there is a debian/cross/extract-config-sh - could you > possibly add a note to debian/README.source explaining the > circumstances under which it needs to be run? I see there were multiple > updates for 5.32.0 so it looks like it's not only with new upstream > versions it needs to be run. Sure. This is what I've just pushed in the ntyni/bug-983099 branch: +Cross build support +--- + +The build system currently support cross builds by storing architecture +specific configuration information under the debian/cross/ directory in +the source package. This works around for the lack of cross configuration +support in the Configure script. + +These cross build support files need to be refreshed for new +upstream versions, and whenever configuration options change. See +debian/cross/README for more information. along with some tooling examples in debian/cross/README. The update in 5.32.0-6 was not strictly necessary. I probably did it because I was looking at this stuff for #972559. It does not hurt to update these files more often. Incidentally, the fix for #972559 should reduce the churn in the support files in the future a bit because build directory variations are now masked. It doesn't help us quite yet, so the diffstat for updating them for 5.32.1 (pushed to the same branch) is still quite daunting: 60 files changed, 1000 insertions(+), 1000 deletions(-) These changes have no run time effect, and they are only used for cross building. I'll ask the release team next if this can still make it to bullseye. -- Niko
Bug#982987: tech-ctte: Call for votes for new CTTE member
On Wed, Feb 17, 2021 at 12:45:05PM -0600, Gunnar Wolf wrote: > ===BEGIN > > The Technical Committee recommends that Christoph Berg be > appointed by the Debian Project Leader to the Technical Committee. > > A: Recommend to appoint Christoph Berg > B: Further Discussion > > ===END I vote: A > B -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#974836: openconnect FTBFS on IPV6-only buildds
On Thu, Nov 26, 2020 at 05:42:35PM +, Luca Boccassi wrote: > Control: tags -1 moreinfo unreproducible > Control: severity -1 important > > On Sun, 15 Nov 2020 13:25:11 +0200 Adrian Bunk wrote: > > Source: openconnect > > Version: 8.10-1 > > Severity: serious > > Tags: ftbfs > > > > https://buildd.debian.org/status/fetch.php?pkg=openconnect&arch=i386&ver=8.10-1~bpo10%2B1&stamp=1589917131&raw=0 > > > https://buildd.debian.org/status/fetch.php?pkg=openconnect&arch=amd64&ver=8.10-1~bpo10%2B1&stamp=1589912458&raw=0 > > > https://buildd.debian.org/status/fetch.php?pkg=openconnect&arch=amd64&ver=8.10-2&stamp=1603997003&raw=0 > Can't reproduce this in a sid chroot + unshare -n + ip link set dev lo up + > ip addr del 127.0.0.1/8 dev lo > Anything specific required to reproduce? It probably needs a non-lo device to show up, see the thread at https://lists.debian.org/debian-devel/2020/07/msg00070.html -- Niko Tyni nt...@debian.org
Bug#982485: libdist-zilla-plugin-requiresexternal-perl: FTBFS: t/externaldeps.t failure
Control: reassign -1 libtest-output-perl 1.032-1 Control: affects -1 src:libdist-zilla-plugin-requiresexternal-perl Control: tag -1 fixed-upstream On Wed, Feb 10, 2021 at 08:46:30PM +0200, Niko Tyni wrote: > Source: libdist-zilla-plugin-requiresexternal-perl > Version: 1.009-1 > Severity: serious > Tags: ftbfs > > This package fails to build from source in current sid, and presumably > on testing too. > > Test Summary Report > --- > t/externaldeps.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > > This is also visible on the autopkgtest check on ci.debian.net: > > > https://ci.debian.net/packages/libd/libdist-zilla-plugin-requiresexternal-perl/testing/amd64/ > > It looks like this broke with libtest-output-perl 1.032-1: reverting to > 1.031-1 locally makes it go away for me. This seems to be an accidental regression in libtest-output-perl, where upstream version 1.032 did not include the changes in 1.031, resulting in https://github.com/mjgardner/Dist-Zilla-Plugin-RequiresExternal/issues/7 resurfacing. I'm reassigning to libtest-output-perl. Upstream has just released 1.033 which I expect fixes this. -- Niko Tyni nt...@debian.org
Bug#982485: libdist-zilla-plugin-requiresexternal-perl: FTBFS: t/externaldeps.t failure
Source: libdist-zilla-plugin-requiresexternal-perl Version: 1.009-1 Severity: serious Tags: ftbfs This package fails to build from source in current sid, and presumably on testing too. Test Summary Report --- t/externaldeps.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 This is also visible on the autopkgtest check on ci.debian.net: https://ci.debian.net/packages/libd/libdist-zilla-plugin-requiresexternal-perl/testing/amd64/ It looks like this broke with libtest-output-perl 1.032-1: reverting to 1.031-1 locally makes it go away for me. >From what I can see the libdist-zilla-plugin-requiresexternal-perl autopkgtest checks didn't get triggered for libtest-output-perl testing migration at all. I don't understand why. -- Niko Tyni nt...@debian.org
Bug#981493: perl: 5.32.1 needs to Break older versions of libdevel-mat-dumper-perl
Package: perl Version: 5.32.1-1 x-debbugs-cc: libdevel-mat-dumper-p...@packages.debian.org As seen in #981408, libdevel-mat-dumper-perl now has a strict dependency on the same Perl version it was built with. However, partial upgrades could still result in a broken combination of an old version of libdevel-mat-dumper-perl and new version of perl. This can be prevented with a Breaks: libdevel-mat-dumper-perl (<< 0.42-3) on the perl side. I think either perl or perl-base should work, but perl-base is probably the right place to put this. -- Niko Tyni nt...@debian.org
Bug#981232: unblock: perl/5.32.1-1
Control: tag -1 - moreinfo On Sun, Jan 31, 2021 at 11:00:16AM +0200, Niko Tyni wrote: > > Thanks. Looks like all those failures went away, except > libtest-valgrind-perl. I cannot reproduce that ppc64el failure on > plummer.debian.org (though it's a bit hard to simulate the exact > autopkgtest conditions without actually running autopkgtest there.) The libtest-valgrind-perl tests ran successfully now, so I suppose we were just unlucky to have it fail twice in a row earlier. In any case the new perl version doesn't seem to be the cause for the failures. I don't think there are any open issues left, so removing the moreinfo tag. Paul (and others): please consider approving 5.32.1. I think it would be better to release bullseye with that than a Debian-specific 5.32.0 with the patches from 5.32.1 (but both options are better than not having the patches at all.) Thanks for your work on the release, -- Niko Tyni nt...@debian.org
Bug#978636: move to merged-usr-only?
On Mon, Jan 25, 2021 at 11:45:55AM -0700, Sean Whitton wrote: > ===BEGIN > The Technical Committee resolves that Debian 'bookworm' should support > only the merged-usr root filesystem layout, dropping support for the > non-merged-usr layout. > > Until after the release of 'bullseye', any implementation of this > resolution must be done in the 'experimental' distribution, or otherwise > kept out of the critical paths for the release of 'bullseye'. > > We do not recommend any particular implementation of the migration. > > Y: Yes, support only merged-usr in the 'bookworm' release. > N: No, continue to support both layouts in 'bookworm'. > F: Further Discussion > ===END I vote: Y > F > N -- Niko Tyni nt...@debian.org signature.asc Description: PGP signature
Bug#981232: unblock: perl/5.32.1-1
On Sat, Jan 30, 2021 at 07:39:36PM +, Dominic Hargreaves wrote: > I pressed retry a bunch of times. Thanks. Looks like all those failures went away, except libtest-valgrind-perl. I cannot reproduce that ppc64el failure on plummer.debian.org (though it's a bit hard to simulate the exact autopkgtest conditions without actually running autopkgtest there.) I've just scheduled one more retry on ci.debian.net. In any case, I suggest we ignore this for now and revisit if it still shows up with the testing migration runs. -- Niko
Bug#981232: unblock: perl/5.32.1-1
On Sat, Jan 30, 2021 at 07:35:04AM +0100, Paul Gevers wrote: > The pseudo excuses [1] report quite some autopkgtest regressions. Can > you please check them, fix them if relevant or explain why they are not > relevant for bullseye (e.g. unstable only)? > [1] https://release.debian.org/britney/pseudo-excuses-experimental.html#perl I spent most of today going through logs of the 300 or so packages showing regressions. The gain was not worth the maintainer time IMHO. I'm not looking forward to doing this again for the actual testing migration. I found about 160 network/proxy failures on arm64 hosts with apt bailing out, and about 120 installability failures relating to the four packages that we already knew will need a rebuild. The remaining 19 failures are categorized below with comments. I'm away from my credentials for the self service, can schedule retries probably tomorrow if necessary. Happy if somebody else beats me to it. Needs fixing for 5.32.1 --- - libdevel-mat-dumper-perl real issue; needs a strict dependency and a rebuild for 5.32.1 also means this is a fifth package that needs a binnmu filed #981408 - perl filed as #981409 minor issue, can be fixed when uploading to sid Retry suggested --- bioperl # flaky; API rate limit exceeded, similar to testing/amd64/1.7.7-2 2020-12-02 04:21:20 UTC backuppc # one-off? unlikely it's perl's fault jellyfish # test suite timeout, not perl specific? ikiwiki-hosting # not perl specific: apache2.service: Failed to set up mount namespacing: Permission denied libbio-db-ncbihelper-perl # network error? MSG: Can't query website: 500 Status read failed: Connection reset by peer trinityrnaseq # probably flaky? libtest-valgrind-perl # no idea, worth a retry. Might be a valgrind issue on ppc64el Issues elsewhere, not triggered by src:perl --- apache2 # fails with just src:openssl from experimental kopanocore # not in testing; fails with e.g. src:e2fsprogs from experimental too libcrypt-smime-perl # probably triggered by src:openssl in experimental, failed the same way on ppc64el earlier with perl/5.32.1~rc1-1 libdata-alias-perl # not in testing, uninstallable libtemplate-plugin-calendar-simple-perl # #964155; not in testing libwebsockets # tested from experimental, fails just by itself mysql-8.0 # not in testing; fails without src:perl too metastudent # not a regression, missing/old reference? #981293 licensecheck # failures in testing too, filed #981410 -- Niko Tyni nt...@debian.org
Bug#981410: licensecheck: autopkgtest failure: t/exception.t
Package: licensecheck
Version: 3.1.1-1
Severity: important
This package has recently started failing its autopkgtest checks in sid
and testing. This is reproducible for me on current sid.
https://ci.debian.net/data/autopkgtest/testing/amd64/l/licensecheck/9966535/log.gz
not ok 40 - detect licensing "(GPL-2+ and/or LGPL-2.1+) with SDC exception"
for sdc.py
# Failed test 'detect licensing "(GPL-2+ and/or LGPL-2.1+) with SDC
exception" for sdc.py'
# at t/exception.t line 179.
# +-++-+
# | GOT | OP | CHECK |
# +-++-+
# | (GPL-2+ and/or LGPL-2.1) with S | eq | (GPL-2+ and/or LGPL-2.1+) with |
# | DC exception|| SDC exception |
# +-++-+
[...]
Test Summary Report
---
t/exception.t (Wstat: 256 Tests: 44 Failed: 1)
Failed test: 40
Non-zero exit status: 1
--
Niko Tyni nt...@debian.org
Bug#981409: perl/experimental: autopkgtest failure: libmodule-corelist-perl version not updated in dependencies
Package: perl Version: 5.32.1-1 Severity: normal The package in experimental fails its autopkgtest check: # Failed test 'Breaks for libmodule-corelist-perl in perl-modules-5.32 matches Module::CoreList for Module::CoreList' # at debian/t/control.t line 211. # got: '5.20200620' # expected: '5.20210123' # s/libmodule-corelist-perl (<< 5.20200620)/libmodule-corelist-perl (<< 5.20210123)/ # s/libmodule-corelist-perl (= 5.20200620)/libmodule-corelist-perl (= 5.20210123)/ # Looks like you failed 1 test of 572. So the Breaks entry for libmodule-corelist-perl needs a version update. The practical effect of this is that older versions of libmodule-corelist-perl could override a newer Module::CoreList in the core package. -- Niko Tyni nt...@debian.org
Bug#981408: libdevel-mat-dumper-perl: encodes Perl version into the binary, needs stricter dependencies
Package: libdevel-mat-dumper-perl Version: 0.42-2 Severity: important This package compiles Perl version information into the binary module at build time, and fails its test suite if run on a different minor version of Perl. >From a failing autopkgtest run with perl_5.32.1-1 in experimental: t/01header.t .. ok 1 - Write dumpfile ok 2 - File magic signature ok 3 - Flags ok 4 - Zero ok 5 - Major ok 6 - Minor not ok 7 - Perlver # Failed test 'Perlver' # at t/01header.t line 42. # got: '85983232' # expected: '85983233' Here the binary was built with 5.32.0, but run on 5.32.1. The dependencies currently allow this, as 5.32.1 is supposed to be binary compatible. This stems from lib/Devel/MAT/Dumper.xs:950 or so: write_u32(fh, PERL_REVISION<<24 | PERL_VERSION<<16 | PERL_SUBVERSION); where the PERL_xxx constants are preprocessor symbols and so expanded at build time. Given this in the module description: The dump file will contain a representation of every SV in Perl's arena, providing information about pointers between them, as well as other information about the state of the process at the time it was created. it sounds possibly fragile to me and should probably declare a strict dependency on the same Perl upstream version it was built with, in the same vein as for instance libclass-xsaccessor-perl. (I fear this might even break between different builds of the same Perl version, but triggering rebuilds on every src:perl upload seems like a major pain on the current Debian infrastructure. I suggest we don't go there unless we really have to.) -- Niko Tyni nt...@debian.org
Bug#981232: unblock: perl/5.32.1-1
On Thu, Jan 28, 2021 at 10:21:21PM +0100, Paul Gevers wrote: > Hi Dominic, > > On 28-01-2021 22:05, Dominic Hargreaves wrote: > >>> 5.32.1 would need a binnmu of a few leaf packages > >>> (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl > >>> libcommon-sense-perl) as usual. > >> > >> Just to be clear, these binNMU's would be needed too if we would go for > >> the cherry-pick option? > > > > No, the binaries relate to a change of upstream version number > > which ends up being encoded in these packages. If we cherry pick > > fixes, the binNMUs wouldn't be needed. > > But then, that relation is strictly speaking too tight? Is that > something that can be improved (without jumping through hoops)? Maybe > not for this time, but for future changes. Normally perl packages look > for the perl-something-api right? Which would make it clear that this is > no transition. There's a reason for each of them of course. libpar-packer-perl (#551356) would definitely involve jumping through hoops. It's the worst one of the four I think and really requires a tight dependency. The version skew warning in libdevel-cover-perl (#562214) could probably be patched away easily, but that seems a bit risky to me. Presumably upstream has a reason for the check. I'm not sure if we've ever asked though, and OTOH autopkgtest runs should notice if the newer Perl version breaks something. For libcommon-sense-perl, I quote #722332: > Not sure if all the internals that common::sense fiddles with are under > the 'no ABI changes in minor Perl version updates' promise. I suspect they > are, but we might still be best off rebuilding it even for minor updates. libclass-xsaccessor-perl only has this changelog entry: * Add dependency on same upstream version of perl to make sure #define PERL_CORE never breaks things. [...] -- Ansgar Burchardt Wed, 18 Aug 2010 13:21:04 +0900 Not sure if that one could be relaxed but keeping it tight seems prudent to me. As Dominic said, the related binNMUs have not been much of an issue in the past. -- Niko Tyni nt...@debian.org
Bug#977594: liblist-moreutils-perl: autopkgtest regressions, breaks lintian
Package: liblist-moreutils-perl Version: 0.430-1 Severity: serious Affects: lintian Some changes in this version seem to have broken other packages, at least libmakefile-dom-perl/0.008-2 and lintian/2.103.0. There are also bug reports against lintian about this, at least #977419 and possibly #977554. AIUI lintian in git has a fix/workaround. -- Niko Tyni nt...@debian.org
Bug#972322: reassigning to perl
reassign 972322 perl reassign 975998 perl forcemerge 97 972322 975998 thanks These bugs need to be fixed in the perl package dependencies, details are in #97 . I'm therefore reassigning and merging and will hopefully fix this shortly. -- Niko Tyni nt...@debian.org
Bug#976666: perl: perl-modules-5.24 from stretch erroneously satisfies dependencies
Package: perl Version: 5.32.0-5 Severity: important Control: affects -1 liblocale-codes-perl libpod-parser-perl As seen in #972322 and #975998, we have a problem with perl-modules-5.24 from stretch satisfying dependencies on current sid/bullseye systems. The perl-modules-5.24 package Provided (among others) liblocale-codes-perl and libpod-parser-perl, which were moved to separate packages in 5.28 and 5.32 respectively. All the provides entries were moved to perl during the 5.26 cycle with #899110. I think we need to make the current perl Break perl-modules-5.24, even if it would have been nice to keep it coinstallable with later versions. The coinstallability of libperl* and perl-modules-* is most useful for oldstable -> stable upgrades, where the old version can be kept around for a while. This helps at least versioned packages linking against libperl like postgresql, so the old versions don't get forcibly removed during the upgrade. I'm wondering if this needs fixing in buster too, as liblocale-codes-perl was moved out to a separate package already during the buster cycle. OTOH the only report we have is about sid/bullseye so it doesn't seem a very common issue. I'm inclined to skip buster until we get more reports. Filing a separate bug for clarity; possibly #972322 and #975998 should be reassigned and merged. I don't think this can be fixed with a source change on the liblocale-codes-perl / libpod-parser-perl side. Reverse dependencies of liblocale-codes-perl and libpod-parser-perl could work around it with a versioned dependency - any version will do as the stretch Provides were unversioned, but a later version would probably make sense. This has already been done for gscan2pdf in bullseye. Not sure if this should be release critical. Filing at 'important' for now. Eyeballs and comments welcome of course in case I've missed something. -- Niko Tyni nt...@debian.org
Bug#975998: licensecheck: Fails with a Perl problem
On Fri, Nov 27, 2020 at 11:25:25PM +0100, Uwe Kleine-König wrote: > Package: licensecheck > Version: 3.0.47-1 > Severity: normal > this might not be licensecheck's fault but maybe is related to the > recent perl transition. But given I don't know much about Perl, I'm > reporting against licensecheck. > > For all invokations of licensecheck I encounter: > > uwe@taurus:~$ licensecheck > Base class package "Pod::Parser" is empty. > (Perhaps you need to 'use' the module which defines that package > first, > or make that module available in @INC (@INC contains: /etc/perl > /usr/local/lib/x86_64-linux-gnu/perl/5.32.0 /usr/local/share/perl/5.32.0 > /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 > /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 > /usr/share/perl/5.32 /usr/local/lib/site_perl). >at /usr/share/perl5/Pod/Constants.pm line 7. > BEGIN failed--compilation aborted at /usr/share/perl5/Pod/Constants.pm > line 7. > Compilation failed in require at /usr/bin/licensecheck line 14. > BEGIN failed--compilation aborted at /usr/bin/licensecheck line 14. > > This is on a machine that runs a mix of testing and unstable, but I can > reproduce this problem on a sid chroot. Hi, thanks for the report. This doesn't seem to occur for me in a clean sid chroot. Is yours an older one that has been upgraded? Do you happen to have an old perl-modules-5.24 package lying around in both? Is libpod-parser-perl installed? I'm guessing this might be similar to #972322 and we need to do something about it on the src:perl side. -- Niko Tyni nt...@debian.org
Bug#968362: Processed: closing 968362
On Fri, Nov 27, 2020 at 12:05:46PM +, Federico Ceratto wrote: > (This is a direct message) > > > Hi, this closure seems to be incorrect? 0.33-3 still failed > > on the buildds on s390x, ppc64 and sparc64. > > Hi Niko and thanks for spotting the issue. > I'm going to upload a new version and set the supported archs > > > The upload should close 968362 and 974418. Hi, I don't think that helps. I expect the old s390x binary would still need to be removed by the FTP team, so closing #974418 would only confuse things. I recommend waiting for the FTP team to act on #974418, then just downgrading #968362 to 'normal' or 'important'. The package should be fine to migrate to testing after that. Setting the supported archs in debian/control seems unnecessary to me as long as the package fails to build on the unsupported ones anyway. See also https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-your-package-is-not-portable Copying #968362 for visibility; please correct if I'm mistaken somewhere. -- Niko
Bug#968362: Processed: closing 968362
Control: reopen -1 Control: found -1 0.33-3 On Thu, Nov 26, 2020 at 12:42:03PM +, Debian Bug Tracking System wrote: > > # fixed in 0.33-3 > > close 968362 > Bug #968362 [src:libmaxmind-db-writer-perl] libmaxmind-db-writer-perl FTBFS > on big endian Hi, this closure seems to be incorrect? 0.33-3 still failed on the buildds on s390x, ppc64 and sparc64. Reopening, but please let me know if I missed something. -- Niko Tyni nt...@debian.org
Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
On Fri, Nov 20, 2020 at 09:30:23AM +0100, Aurelien Jarno wrote: > On 2020-11-16 16:39, Niko Tyni wrote: > > On Fri, Nov 13, 2020 at 08:48:19PM +0100, Sven Joachim wrote: > > > On 2020-11-13 18:23 +0100, Niels Thykier wrote: > > > > > > > Control: reassign -1 perl-base > > > > Control: affects -1 upgrade-reports > > > > Control: severity -1 grave > > > > > > > > Hi Perl team, > > > > > > > > I have reassigned this bug to perl because perl-base being essential > > > > must remain functional during an upgrade and AFAICT perl-base fails in > > > > this case here. > > > > > > > > If it is a direct linkage, then you might be needing a Pre-Depends. If > > > > it is an indirect linkage then I am not sure how to fix it. :-/ > > > > > > I don't think perl-base is doing anything wrong here, it already uses > > > Pre-Depends. AFAICS the problem is that libcrypt.so.1 can temporarily > > > go missing if libc6 2.31-4 is unpacked before libcrypt1, breaking the > > > assumption that binaries from essential packages are always usable. > > I don't understand what happened there. Sure there has been the perl > transition, but the fact that perl depends on libcrypt1, it is the case > for more than 6 months. I don't think this is related to the recent perl 5.30 -> 5.32 transition. The report is about a buster -> bullseye upgrade, and perl in bullseye was still at 5.30 at the time. In any case, the report says perl (presumably perl-base as well) was still at the buster version when the breakage happened, so it didn't have the libcrypt1 dependency. FWIW the breakage can be reproduced just by manually unpacking the new libc6 on a buster system. I don't know why it hasn't been encountered earlier. > > As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1 > > for one release cycle, so that libc6 cannot be unpacked before libcrypt1 > > is fully installed. > > This has been tried, that works for upgrade, but then apt refuses to > allow new installation of libc6+libxcrypt1, which makes it impossible to > install foreign-arch versions on an existing system. Yeah, I missed the libcrypt1 -> libc6 dependency. That prevents this option. (I wonder if the circular dependency is a factor in apt choosing the upgrade order that results in this breakage.) > > Another option might be to have the new libc6 Conflict with old versions > > of Essential:yes packages that need libcrypt1, forcing those Essential:yes > > packages to get upgraded first. A quick check based on libcrypt1 reverse > > dependencies in sid shows perl-base, login and util-linux. I'm not sure > > if this list is exhaustive, though. > > This is something we can try indeed. It looks like perl-base 5.30.0-10 was the first version to acquire the pre-dependency on libcrypt1. -- Niko
Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
On Fri, Nov 13, 2020 at 08:48:19PM +0100, Sven Joachim wrote: > On 2020-11-13 18:23 +0100, Niels Thykier wrote: > > > Control: reassign -1 perl-base > > Control: affects -1 upgrade-reports > > Control: severity -1 grave > > > > Hi Perl team, > > > > I have reassigned this bug to perl because perl-base being essential > > must remain functional during an upgrade and AFAICT perl-base fails in > > this case here. > > > > If it is a direct linkage, then you might be needing a Pre-Depends. If > > it is an indirect linkage then I am not sure how to fix it. :-/ > > I don't think perl-base is doing anything wrong here, it already uses > Pre-Depends. AFAICS the problem is that libcrypt.so.1 can temporarily > go missing if libc6 2.31-4 is unpacked before libcrypt1, breaking the > assumption that binaries from essential packages are always usable. Indeed. As perl-base isn't upgraded yet at that point, there's nothing we can do on that side. Apparently the new libc6 is still considered to satisfy the old perl-base pre-dependency even when it (libc6) is only unpacked and its dependencies are not yet satisfied. This seems similar to this paragraph from Debian policy, section 7.2: When a package declaring a pre-dependency is about to be unpacked the pre-dependency can be satisfied if the depended-on package is either fully configured, or even if the depended-on package(s) are only in the “Unpacked” or the “Half-Configured” state, provided that they have been configured correctly at some point in the past (and not removed or partially removed since). In this case, both the previously-configured and currently “Unpacked” or “Half-Configured” versions must satisfy any version clause in the Pre-Depends field. The libc6 package has been configured correctly in the past, when it still contained libcrypt1. As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1 for one release cycle, so that libc6 cannot be unpacked before libcrypt1 is fully installed. Another option might be to have the new libc6 Conflict with old versions of Essential:yes packages that need libcrypt1, forcing those Essential:yes packages to get upgraded first. A quick check based on libcrypt1 reverse dependencies in sid shows perl-base, login and util-linux. I'm not sure if this list is exhaustive, though. The first option looks less intrusive to me. Disclaimer: I haven't tested any of this :) -- Niko Tyni nt...@debian.org
Bug#791362: perl: build timezone affects LOCALTIME_{MIN,MAX}
Control: submitter -1 !
Control: severity -1 minor
Control: tag -1 upstream
On Sat, Nov 14, 2020 at 05:27:26PM +, Dominic Hargreaves wrote:
> I'm struggling to see the practical problem with having the timezone
> vary LOCALTIME_{MIN,MAX} (other than reproducibility, which AIUI has
> already been addressed).
I'm not aware of any practical problems here. I suspect nothing
uses $Config{sLOCALTIME_max} et al.
Reproducibility has been addressed in a Debian-specific way. Ideally,
it would be fixed upstream so that the build result would be reproducible
regardless of the build timezone (which we are currently overriding.)
> I don't agree with the starting point that
> an environment variable shouldn't be able to influence the contents
> of the binary (this is clearly a very common and necessary pattern).
I think it depends on the environment variable and its main purpose.
Something like BUILD_BZIP2 does and should influence the result, that's
what it's there for. But what's the use for encoding the local timezone
into the binaries? Binaries can be copied between hosts in different time
zones (our buildd results certainly are), users connect to hosts from
different time zones, and even hosts (think laptops) can move between
time zones.
I don't really mind closing this, it's just a minor detail and I obviously
haven't got around to doing anything about it so far. But I do think
the current TZ=UTC solution is more a workaround than a fix.
I'm updating the metadata at least, feel free to close if you're not
convinced :)
--
Niko
Bug#974418: RM: libmaxmind-db-writer-perl [s390x] -- ROM; built without test suite, broken on big-endian
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org Please remove libmaxmind-db-writer-perl/s390x from unstable. It's broken on big-endian architectures (#968362) but the first upload didn't have the test suite enabled so it built successfully anyway. Thanks for your work, -- Niko Tyni nt...@debian.org
Bug#974143: libencode-arabic-perl: autopkgtest regression with Perl 5.32: Useless use of /d modifier in transliteration operator
Package: libencode-arabic-perl
Version: 14.2-1
Severity: serious
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition
Control: block 968912 with -1
Control: affects -1 libelixirfm-perl
It looks like Perl 5.32 caused a regression in the libencode-arabic-perl
(and transitively libelixirfm-perl) autopkgtest checks. The failure
boils down to this:
# perl -we 'use Encode::Arabic'
Useless use of /d modifier in transliteration operator at (eval 5) line 6.
Useless use of /d modifier in transliteration operator at (eval 7) line 6.
Useless use of /d modifier in transliteration operator at (eval 9) line 6.
Running with 'perl -d' shows these come from
Useless use of /d modifier in transliteration operator at (eval
10)[/usr/share/perl5/Encode/Arabic/Habash.pm:163] line 6.
Useless use of /d modifier in transliteration operator at (eval
8)[/usr/share/perl5/Encode/Arabic/Parkinson.pm:157] line 6.
Useless use of /d modifier in transliteration operator at (eval
6)[/usr/share/perl5/Encode/Arabic/Buckwalter.pm:161] line 6.
Quoting
https://perldoc.perl.org/perldiag#Useless-use-of-/d-modifier-in-transliteration-operator
(W misc) You have used the /d modifier where the searchlist has the same
length as the replacelist.
The difference between Perl versions seems to be that 5.32 has become
smarter about non-ASCII character ranges, as seen with
# perl -we '$0 =~ tr/\x{0626}-\x{0628}/abc/d'
which warns with 5.32 but not with 5.30.
I'm guessing this changed somewhere around
https://github.com/Perl/perl5/commits/f34acfecc286f2eff2450db713da005d888a7317
and it looks to me like this is not a regression in Perl and
Encode::Arabic needs to adapt.
Given the transliteration lists are built dynamically in the code, maybe
the thing to do is just to insert some "no warnings 'misc'" declarations
to suppress the warnings.
Alternatively, disabling the autopkgtest check would lower the severity
of this (but note that at least libelixirfm-perl would also need to
be changed.)
The autopkgtest regression makes this a blocker for Perl 5.32 transition.
--
Niko Tyni nt...@debian.org
Bug#974134: libdbd-csv-perl: test suite fails with libdbi-perl 1.643-3
Source: libdbd-csv-perl
Version: 0.5500-1
Severity: serious
Tags: patch fixed-upstream
Forwarded:
https://github.com/perl5-dbi/DBD-CSV/commit/88c3ca044a3881eab62d6d2d38490351fd421386
Control: block 968912 with -1
libdbi-perl 1.643-3 cannot currently migrate to testing, as
it causes a test failure in libdbd-csv-perl.
t/11_dsnlist.t
ok 1 - use DBI;
ok 2 - Driver is CSV
#
ok 3 - Connect
ok 4 - ping
ok 5 - data_sources
ok 6 - more than one
ok 7 - disconnect
ok 8 - use . as f_dir
ok 9 - disconnect
DBI connect('f_dir=example','',...) failed: No such directory 'example at
./t/lib.pl line 162.
# Cannot connect: No such directory 'example
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 9.
Dubious, test returned 255 (wstat 65280, 0xff00)
[...]
Test Summary Report
---
t/11_dsnlist.t (Wstat: 65280 Tests: 9 Failed: 0)
Non-zero exit status: 255
Parse errors: No plan found in TAP output
Files=24, Tests=1558, 9 wallclock secs ( 0.33 usr 0.06 sys + 7.68 cusr
0.77 csys = 8.84 CPU)
Result: FAIL
This is presumably fixed upstream by
https://github.com/perl5-dbi/DBD-CSV/commit/88c3ca044a3881eab62d6d2d38490351fd421386
This seems to be a test-only issue, so a Breaks entry on the libdbi-perl
side is probably not needed (at least if a fixed libdbd-csv-perl is able
to migrate on its own.)
--
Niko Tyni nt...@debian.org
Bug#974016: mrs: FTBFS with libzeep-dev 5.0.0-1: "Checking for libzeep...libzeep is not installed"
On Mon, Nov 09, 2020 at 09:17:25AM +0200, Juhani Numminen wrote: > Source: mrs > Version: 6.0.5+dfsg-8 > Severity: serious > Tags: ftbfs sid > Justification: fails to build from source (but built successfully in the past) > | Checking for libzeep...libzeep is not installed, either install the package > libzeep-dev > | or download libzeep from ftp://ftp.cmbi.ru.nl/pub/software/libzeep > | and run configure again. > | make[1]: *** [debian/rules:15: override_dh_auto_configure] Error 2 Looks to me like libzeep-dev is broken because the build doesn't pass --enable-shared to ./configure. Probably the override_dh_auto_configure-arch and override_dh_auto_configure-indep targets in src:libzeep debian/rules are not effective because of the earlier override_dh_auto_configure target. But I didn't actually test any of this. Hope this helps, -- Niko Tyni nt...@debian.org
Bug#974061: postgresql-12: FTBFS during perl 5.32 transition
On Mon, Nov 09, 2020 at 02:16:57PM +, Dominic Hargreaves wrote: > Source: postgresql-12 > Version: 12.4-3 > Severity: serious > Justification: ftbfs > Tags: ftbfs > User: debian-p...@lists.debian.org > Usertags: perl-5.32-transition > Control: block 968912 with -1 > > postgresql-12 FTBFS on multiple archs, eg: > > https://buildd.debian.org/status/fetch.php?pkg=postgresql-12&arch=amd64&ver=12.4-3%2Bb1&stamp=1604914304&raw=0 This looks relevant, hope it helps: https://www.postgresql.org/message-id/16689-57701daa23b37...@postgresql.org -- Niko Tyni nt...@debian.org
Bug#974055: libvideo-capture-v4l-perl: FTBFS with Perl 5.32 on 32-bit architectures: overrides $Config{ccflags}
Source: libvideo-capture-v4l-perl Version: 0.902-4 Severity: serious Tags: ftbfs bullseye sid User: debian-p...@lists.debian.org Usertags: perl-5.32-transition Control: block 968912 with -1 This package fails to build with Perl 5.32 on 32-bit architectures. PERL_DL_NONLAZY=1 "/usr/bin/perl" "-Iblib/lib" "-Iblib/arch" test.pl 1..1 V4l.c: loadable library and perl binaries are mismatched (got handshake key 0xa300080, needed 0xa400080) make[1]: *** [Makefile:897: test_dynamic] Error 1 This seems to happen because Makefile.PL overrides CCFLAGS, removing (among other things) -D_FILE_OFFSET_BITS=64 from the compiler invocation. As it used to work before, something must have changed. My guess is that was https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/4392efb97c333007a4a9c91a0b7c20610d21041d In any case, reportedly dropping debian/patches/compile_with_-fPIC.patch makes it build again. I suppose something else is introducing -fPIC to the build nowadays but I haven't looked into this. -- Niko Tyni nt...@debian.org
Bug#972559: perl: please make the build mostly reproducible
On Tue, Oct 20, 2020 at 10:55:23AM +0100, Chris Lamb wrote: > Source: perl > Version: 5.30.3-4 > Severity: wishlist > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: buildpath > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > Hi, > > Whilst working on the Reproducible Builds effort [0] we noticed that > perl could not be built reproducibly. > > This is because it ships a number of build-related header files that > include the build path in various guises. Assuming these files are > actually useful in the binary package, a patch is attached that > sanitises these in debian/rules prior to the final creation of the .deb. Thanks! For some reason I thought this was a wider issue than just those files. The config.h and Config_heavy.pl files are definitely useful and necessary. The config.sh.* files are part of our hacky cross build support, and we seem to be stuck with them until somebody implements cross build safe configure probes upstream. Mangling the build directory in all of them should be fine, though I worry a bit about short build paths potentially matching some other data in the files. But I guess that's mostly theoretical. I'm uneasy with using $(CURDIR) as a regexp in sed. Similar usage in the past led to #585678. Given '+' is not special in sed regexps, this is not quite as bad, but still not ideal. An option is to say $(PERL_TO_USE) -pi -e 's/\Q$(CURDIR)\E/.../' like we do elsewhere in the rules already. > To be clear, Perl is not entirely reproducible with this change — I > need to address the variations added between a /usr-merged system and > one that is not. That part should be incoming soon. Cool, thanks again. We're currently waiting for a transition slot for perl 5.32, so this may have to wait until after that. Feel free to poke if nothing happens. -- Niko
Bug#972218: depends on liblocale-codes-perl
On Thu, Oct 15, 2020 at 07:05:04PM +0200, Jeff wrote: > On 15/10/2020 12:52, Niko Tyni wrote: > > So it should only happen for systems upgraded from stretch. A > > workaround for gscan2pdf could be to declare a versioned dependency on > > liblocale-codes-perl (>= 3.60) or something like that so it wouldn't be > > satisfied by the old perl-modules-5.24. > > > > Not sure if we should make perl in sid/bullseye Break perl-modules-5.24. > > I'd prefer to keep them coinstallable but I can't see any other generic > > fix. > > If you don't have a generic fix in time for the next gscan2pdf release > in around ten days, I'll use your workaround. Thanks for the suggestion. > > Would you like me to duplicate the bug so that it doesn't get forgotten? Sure, please do. Thanks for bringing this up. -- Niko
Bug#968912: transition: perl 5.32
On Sun, Aug 23, 2020 at 07:25:19PM +0100, Dominic Hargreaves wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-p...@lists.debian.org > > Hi, perl 5.32 has been in experimental since June and I think it's going > to be ready for sid/bullseye within the next month or so - this is the > version we expect to ship with bullseye (given the freeze in January). > > The main blockers at present are the perl-tk update (I've just > pinged #960863) and, indirectly, the ipv6-only build related problems > described in #964902. These are resolved now, and all known regressions found in our test rebuilds are marked as blocking this bug. The libpod-parser-perl dependencies are trivial to add. There's no fix for libdata-alias-perl, and I expect we'll need to remove it from testing. It's just an optional dependency for other packages AFAICS, so I don't expect much fallout (as long as the build dependencies are relaxed in libio-stream-perl and libmethod-signatures-perl first.) Could we raise the remaining bugs to 'serious' now? Do you have any guesstimate on the timing for a transition slot? Thanks for your work, -- Niko Tyni nt...@debian.org
Bug#972275: libio-stream-perl: build-depends on libdata-alias-perl, incompatible with Perl 5.32
Source: libio-stream-perl Version: 2.0.3-1 Severity: important Tags: bullseye sid User: debian-p...@lists.debian.org Usertags: perl-5.32-transition Control: block 968912 with -1 This package Recommends and Build-Depends-Indep on libdata-alias-perl, which is broken with Perl 5.32 (#971969) and doesn't seem to be getting fixed. The build dependency looks like it's optional, could we please drop it so the relevant tests are just skipped? Given the binary relation is just a recommendation, any packages using the IO::Stream functionality provided by Data::Alias would presumedly be marked as depending on both libio-stream-perl and libdata-alias-perl. I don't see any such packages in sid so no other packages should be affected AFAICS. -- Niko Tyni nt...@debian.org
Bug#972274: libmethod-signatures-perl: build-depends on libdata-alias-perl, incompatible with Perl 5.32
Source: libmethod-signatures-perl Version: 20170211-1 Severity: important Tags: bullseye sid User: debian-p...@lists.debian.org Usertags: perl-5.32-transition Control: block 968912 with -1 This package Recommends and Build-Depends-Indep on libdata-alias-perl, which is broken with Perl 5.32 (#971969) and doesn't seem to be getting fixed. The build dependency looks like it's optional, could we please drop it so the relevant tests are just skipped? Given the binary relation is just a recommendation, any packages using the Method::Signatures functionality provided by Data::Alias would presumedly be marked as depending on both libmethod-signatures-perl and libdata-alias-perl. I don't see any such packages in sid so no other packages should be affected AFAICS. -- Niko Tyni nt...@debian.org
Bug#972218: depends on liblocale-codes-perl
On Thu, Oct 15, 2020 at 10:45:43AM +0200, Jeff wrote: > John still has perl-modules-5.24, which provides liblocale-codes-perl. > But as his perl is probably 5.30, perl-modules-5.24 is probably not in > his @INC. This seems to be an unfortunate oversight in our Provides handling in src:perl. https://bugs.debian.org/899110 is related. This was fixed in the 5.26 cycle, so after stretch. It looks like we missed the Locale-Codes removal between stretch and buster. So it should only happen for systems upgraded from stretch. A workaround for gscan2pdf could be to declare a versioned dependency on liblocale-codes-perl (>= 3.60) or something like that so it wouldn't be satisfied by the old perl-modules-5.24. Not sure if we should make perl in sid/bullseye Break perl-modules-5.24. I'd prefer to keep them coinstallable but I can't see any other generic fix. -- Niko Tyni nt...@debian.org
