Bug#1030749: Bug#1031587: [request-tracker-maintainers] Bug#1031587: Handling of the request-tracker4 -> request-tracker5 transition in bookworm

[Dominic Hargreaves]

On Mon, Mar 20, 2023 at 11:06:49PM +0100, Sebastian Ramacher wrote:
> Hi Dominic
> 
> On 2023-02-27 15:50:05 +, Dominic Hargreaves wrote:
> > On Thu, Feb 23, 2023 at 04:54:33PM +0100, Paul Gevers wrote:
> > > Control: tags -1 moreinfo
> > > 
> > > Hi,
> > > 
> > > On 20-02-2023 13:09, Dominic Hargreaves wrote:
> > > > If the release team would be willing to grant an exception to the policy
> > > > to get this done, we can get this wrapped up inside a week I expect.
> > > 
> > > Can you please confirm that everything is ready to do this? I.e. there is 
> > > no
> > > "this should work but we haven't tested it" cases. If yes, then please
> > > upload the packages that involve new binaries to experimental and when 
> > > those
> > > are passed NEW, ping this bug. If no surprises pop up, we'll grant an
> > > exception, but we want everything fully ready before doing so.
> > 
> > Thanks, yep. We had planned out this transition and I feel confident
> > the rest of it will work out (worst case we need to drop a barely
> > used extension package somewhere).
> > 
> > Andrew and I are working on this at the moment and will ping this bug
> > when it's fully staged.
> 
> What's the status of this transition?

Hi Sebastian

Sorry for the long delay. Myself and, I think, Andrew have been short on time.

The transition is basically ready to go, but I've been rethinking the need
to drop request-tracker4, given it will all be quite tight. It turns out that
request-tracker4 is still supported upstream 
(https://bestpractical.com/release-policy)
and there's no specific EoL set. When we first started the plan to
deprecate request-tracker4 in Debian, I think we were assuming otherwise.
The package is in good shape and I believe otherwise ready to be released.

If Andrew is in agreement, I therefore think we should let request-tracker4
be released with the next release. We can reconsider whether to drop it from
the release + 1 at a more leisurely pace. The work we've done to date will not
be wasted effort.

I've tentatively downgraded #1030749 to signal this intent.

Cheers
Dominic

Bug#1030749: request-tracker4: Don't release with bookworm

[Dominic Hargreaves]

Package: request-tracker4
Version: 4.4.6+dfsg-1
Severity: serious
Justification: maintainer

request-tracker5 is the current release; we don't want to release
request-tracker4 any more.

Bug#912682: e: Bug#912682: usefulness of this package?g

[Dominic Hargreaves]

On Sat, Jan 08, 2022 at 03:04:17AM +0100, gregor herrmann wrote:
> On Thu, 06 Jun 2019 10:56:07 +0100, Dominic Hargreaves wrote:
> 
> > Per our new policy[1], we'll remove this after July if no new
> > upstream update appears.
> > [1] <https://perl-team.pages.debian.net/policy.html#Dual-lived_Modules>
> 
> Looks like this hasn't happened :)
> 
> I came to this bug as ExtUtils::ParseXS 3.44 was released yesterday.
> 
> So the current situation is:
> 
> We have libextutils-parsexs-perl 3.35-1 in unstable.
> 
> For ExtUtils::ParseXS in perl core we have
> 
>   v5.32.13.40  
> …
>   v5.34.03.43  
>   v5.35.03.43  
>   v5.35.13.43  
>   v5.35.23.43  
>   v5.35.33.43  
>   v5.35.43.44  
>   v5.35.53.44  
>   v5.35.63.44  
>   v5.35.73.44  
> 
> This means we could upload 3.44() to unstable, and after the
> transition to 5.34 this would still be ok, and after the migration to
> 5.36 in a couple of months we'd be in the same situation as now.
> 
> If I understand it correctly, ExtUtils::ParseXS is one of those
> dual-lifed modules which are primarily maintained in perl core, and
> then also released to the CPAN (ideally when a new perl is releaesed,
> right now a couple of months later), which means that there probably
> won't by any release where CPAN precedes perl core.
> 
> If this understanding is correct, than keeping libextutils-parsexs-perl
> as a separate package doesn't make a lot of sense (it will only be
> newer in the window between new upstream perl releases and our
> migrations in Debian), and I propose to remove it.

Good plan. I've just filed the removal request: https://bugs.debian.org/1009785

Bug#988905: [request-tracker-maintainers] Bug#988905:

[Dominic Hargreaves]

On Mon, Jul 12, 2021 at 01:27:42PM +1200, Michael Hudson-Doyle wrote:
> I see there is a fix in the git repo now. Are you planning an upload any
> time soon, or only after the buster release?

Hi Andrew

Is there anything blocking the upload of 5.0.2 now? Do you need any
help with this?

Cheers
Dominic

Bug#981079: request-tracker4: RT4 does not ship with real ckeditor source

[Dominic Hargreaves]

Package: request-tracker4
Version: 4.4.4-2
Severity: serious
Justification: DFSG

During packaging of RT5 it was noticed that the ckeditor source
shipped in third-party does not correspond to the preferred form
of modification - it is still minified (like that shipped in the main
tarball). This is due to a change of upstream practice since the
third-party tarball setup was originally introduced.

This is fixed in RT5 by repacking the third-party-source to add
additional sources - see[1]. We should do something similar for RT4,
at least if we will keep RT4 around in bullseye.

[1] 

Bug#942135: Сannot install Perl 5.30.0-6 without deleting the libgtk2-perl package

[Dominic Hargreaves]

On Sat, Jan 02, 2021 at 08:22:48AM +0100, intrigeri wrote:
> Hi,
> 
> Dominic Hargreaves (2020-11-10):
> > On Tue, Nov 10, 2020 at 09:03:42AM +0100, intrigeri wrote:
> >> Dominic Hargreaves (2020-11-09):
> >> > A year on, it seems there's almost no realistic prospect of this
> >> > package coming back. Shall we remove it from sid?
> >> 
> >> Thank you for caring!
> >> 
> >> Quoting the plan I proposed #912860: "I intend to remove libgtk2-perl
> >> from testing soon after the Buster release, and then from sid later
> >> during the Bullseye development cycle".
> 
> > We're quite a way through the bullseye development cycle already but
> > I guess you mean once we're into the deep freeze when there is no longer
> > any chance of reviving those packages for bullseye, which makes sense
> > to me.
> 
> Actually, when writing my previous message here, I misread my own
> initial proposal. You're indeed correct that under this proposal,
> we could remove libgtk2-perl from sid right away. Thank you for
> your patience! :)
> 
> Given the upcoming freeze, I'd like to give the maintainers of the
> reverse-dependencies a last chance to get their package in Bullseye
> before migration of new source packages to testing is disabled
> (2021-02-12), which would be required if we removed libgtk2-perl and
> all its reverse-dependencies right away.
> 
> In particular:
> 
>  - tinyca: a few months ago the maintainer was actively working on
>a solution
> 
>  - gprename: upstream ported to GTK 3, now waiting for the new release
>to be packaged & uploaded
> 
> So, I'm now leaning towards removing libgtk2-perl and its remaining
> reverse-dependencies from sid at any time after 2021-02-12 (I don't
> care much when exactly). At that point, indeed it'll be too late for
> these packages to go into Bullseye, and their maintainers will have
> 2 years to find a solution.
> 
> Does this make sense to you?

Sure, sounds good!

Bug#961283: libhttp-tiny-perl: Don't release with bullseye

[Dominic Hargreaves]

On Thu, Dec 17, 2020 at 10:17:24PM +0100, Paul Gevers wrote:
> Hi Dominic,
> 
> On Fri, 22 May 2020 16:15:31 +0100 Dominic Hargreaves
>  wrote:
> > Package: libhttp-tiny-perl
> > Version: 0.076-1
> > Severity: serious
> > Justification: maintainer
> > 
> > libhttp-tiny-perl at this version should not be released with
> > bullseye, since perl contains the same version.
> 
> This package is considered a key package by our tooling and will not be
> automatically removed from bullseye. Why don't you request it to be
> removed from unstable with a RM bug filed against ftp.debian.org? Than
> it will automatically be removed from bullseye too.

pkg-perl standard practice is to keep dual-lived packages in unstable
for a release cycle to make it easier to bring back when they
become newer than the version in perl again, which happens from time
to time.

It sounds like we should file a bug with the release team for
manual removal from testing instead in this case? What makes the package
"key" OOI? The package is provided by perl so removal from testing
should be safe.

Best
Dominic

Bug#974033: marked as pending in libapache2-mod-perl2

[Dominic Hargreaves]

On Mon, Nov 09, 2020 at 07:23:53PM +, gregor herrmann wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #974033 in libapache2-mod-perl2 reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/perl-team/modules/packages/libapache2-mod-perl2/-/commit/b6c0cb9545a10bdd97ac545e1330d32b2530f42a
> 
> 
> Run tests with "-servername 127.0.0.1" instead of the default 'localhost'
> 
> to avoid DNS lookup failures on IPv6-only machines.
> 
> Closes: #974033
> 

For anyone who is reading this having been notified of a dependency's
status in testing, I belive we can fix this once the perl 5.32
migration (currently ongoing) has completed, which should be in a couple
of days.

Bug#974704: [pcp] Bug#974704: pcp: FTBFS on some archs: Cannot find (any matches for) "usr/lib/pcp/pmdas/infiniband[...]

[Dominic Hargreaves]

On Mon, Nov 16, 2020 at 04:49:07PM +1100, Nathan Scott wrote:
> Hi Dom,
> 
> On Sun, Nov 15, 2020 at 7:01 AM Dominic Hargreaves  wrote:
> >
> > On Sat, Nov 14, 2020 at 12:35:04AM +0000, Dominic Hargreaves wrote:
> > > This package FTBFS on the architectures which don't have bpftrace as a
> > > dependency since:
> >
> > ...
> >
> > Also, if you do do another upload, please can you do a source-only
> > upload or make sure that you build on an up-to-date sid (the upload
> > on Wednesday was built against perl 5.30 on amd64).
> 
> We always do source-only uploads, except in this case where we
> were explicitly requested by ftp-masters to do a binary upload as
> it introduced a new sub-package.

Ah, okay, that makes sense. I hadn't realised we had two conflicting
policies here... :(

> Thanks for the NMU, please feel free to reduce it from 4 days to
> less if that helps - I'll ensure a version of your patch gets included
> in the next upstream release.

Thanks! I'll reschedule that now.

(Please CC me in replies).

Best
Dominic

Bug#974574: nbdkit: diff for NMU version 1.22.3-1.1

[Dominic Hargreaves]

On Sat, Nov 14, 2020 at 09:47:23PM +0100, Hilko Bengen wrote:
> Hi Dominic,
> 
> thanks for your NMU. Please push your changes since 1.22.3-1 to git and
> reschedule for immediate acceptance into unstable.

Done!

Bug#974574: nbdkit: diff for NMU version 1.22.3-1.1

[Dominic Hargreaves]

Control: tags 974574 + patch
Control: tags 974574 + pending

Dear maintainer,

I've prepared an NMU for nbdkit (versioned as 1.22.3-1.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Changelog:

nbdkit (1.22.3-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Temporarily stop building the torrent plugin since
libtorrent-rasterbar-dev is RC-buggy (see #956285), to allow nbdkit to
migrate to testing. The torrent plugin has never been available in
testing, so this does not represent a regression there (Closes: #974574) 

 -- Dominic Hargreaves   Sat, 14 Nov 2020 19:13:45 +

Regards.

diff -Nru nbdkit-1.22.3/debian/changelog nbdkit-1.22.3/debian/changelog
--- nbdkit-1.22.3/debian/changelog	2020-09-23 10:35:11.0 +0100
+++ nbdkit-1.22.3/debian/changelog	2020-11-14 19:13:45.0 +
@@ -1,3 +1,13 @@
+nbdkit (1.22.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Temporarily stop building the torrent plugin since
+libtorrent-rasterbar-dev is RC-buggy (see #956285), to allow nbdkit to
+migrate to testing. The torrent plugin has never been available in
+testing, so this does not represent a regression there (Closes: #974574) 
+
+ -- Dominic Hargreaves   Sat, 14 Nov 2020 19:13:45 +
+
 nbdkit (1.22.3-1) unstable; urgency=medium
 
   * New upstream version 1.22.3
diff -Nru nbdkit-1.22.3/debian/control nbdkit-1.22.3/debian/control
--- nbdkit-1.22.3/debian/control	2020-09-17 15:12:47.0 +0100
+++ nbdkit-1.22.3/debian/control	2020-11-14 16:54:20.0 +
@@ -20,7 +20,6 @@
  tcl-dev,
  libselinux1-dev,
  libssh-dev,
- libtorrent-rasterbar-dev,
  libvirt-dev,
  zlib1g-dev,
  linux-image-arm64 [arm64] ,
diff -Nru nbdkit-1.22.3/debian/nbdkit.install nbdkit-1.22.3/debian/nbdkit.install
--- nbdkit-1.22.3/debian/nbdkit.install	2020-09-10 00:38:52.0 +0100
+++ nbdkit-1.22.3/debian/nbdkit.install	2020-11-14 17:20:08.0 +
@@ -34,7 +34,6 @@
 /usr/lib/*-*/nbdkit/plugins/nbdkit-streaming-plugin.so
 /usr/lib/*-*/nbdkit/plugins/nbdkit-tar-plugin.so
 /usr/lib/*-*/nbdkit/plugins/nbdkit-tmpdisk-plugin.so
-/usr/lib/*-*/nbdkit/plugins/nbdkit-torrent-plugin.so
 /usr/lib/*-*/nbdkit/plugins/nbdkit-zero-plugin.so
 /usr/lib/*-*/nbdkit/filters
 /usr/share/man/man1/nbdkit-cdi-plugin.1
@@ -60,7 +59,6 @@
 /usr/share/man/man1/nbdkit-streaming-plugin.1
 /usr/share/man/man1/nbdkit-tar-plugin.1
 /usr/share/man/man1/nbdkit-tmpdisk-plugin.1
-/usr/share/man/man1/nbdkit-torrent-plugin.1
 /usr/share/man/man1/nbdkit-zero-plugin.1
 /usr/share/man/man3/nbdkit-cc-plugin.3
 /usr/share/man/man3/nbdkit-sh-plugin.3

Bug#974704: pcp: diff for NMU version 5.2.2-1.1

[Dominic Hargreaves]

Control: tags 974704 + patch
Control: tags 974704 + pending

Dear maintainer,

I've prepared an NMU for pcp (versioned as 5.2.2-1.1) and
uploaded it to DELAYED/4. Please feel free to tell me if I
should delay it longer.

I have tested this fix on i386 and the contents of the
pcp-pmda-infiniband package look plausible.

However, note that I have partially reverted a change in the last
upload to add architecture constraints to the libibumad-dev and
libibmad-dev build-deps. They were causing the build-failure and
I couldn't see why they were needed. But please let me know if this
wasn't the right fix.

Note also that this is one of the last blockers for the perl
5.32 transition which is ongoing, so any early confirmation (so that
I can reschedule the NMU) or a source-only maintainer upload would be
welcome. (In the latter case, please note that I did not touch the
d/control regeneration script in my NMU, and also note that the upload
must be source-only in order to comply with the bullseye release policy[1]

Regards,
Dominic

[1] <https://lists.debian.org/debian-devel-announce/2019/07/msg2.html>
diff -Nru pcp-5.2.2/debian/changelog pcp-5.2.2/debian/changelog
--- pcp-5.2.2/debian/changelog	2020-11-10 21:31:00.0 +
+++ pcp-5.2.2/debian/changelog	2020-11-14 15:02:58.0 +
@@ -1,3 +1,11 @@
+pcp (5.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove architecture constraints to libibumad-dev and libibmad-dev
+(closes: #974704)
+
+ -- Dominic Hargreaves   Sat, 14 Nov 2020 15:02:58 +
+
 pcp (5.2.2-1) unstable; urgency=low
 
   * Remove python3-all-dev dependency (closes: #972330)
diff -Nru pcp-5.2.2/debian/control pcp-5.2.2/debian/control
--- pcp-5.2.2/debian/control	2020-11-10 21:31:00.0 +
+++ pcp-5.2.2/debian/control	2020-11-14 15:02:53.0 +
@@ -4,7 +4,7 @@
 Homepage: https://pcp.io
 Maintainer: PCP Development Team 
 Uploaders: Nathan Scott , Ken McDonell 
-Build-Depends: bison, flex, gawk, procps, pkg-config, debhelper (>= 5), perl (>= 5.6), libreadline-dev | libreadline5-dev | libreadline-gplv2-dev, chrpath, libbsd-dev [kfreebsd-any], libkvm-dev [kfreebsd-any], python3-dev, libnspr4-dev, libnss3-dev, libsasl2-dev, libuv1-dev, libssl-dev, libavahi-common-dev, qtbase5-dev, qtbase5-dev-tools, libqt5svg5-dev, qtchooser, autotools-dev, zlib1g-dev, autoconf, libclass-dbi-perl, libdbd-mysql-perl, python3-psycopg2, dh-python, libpfm4-dev, libncurses5-dev, python3-six, python3-json-pointer, python3-requests, libextutils-autoinstall-perl, libxml-tokeparser-perl, librrds-perl, libjson-perl, libwww-perl, libnet-snmp-perl, libnss3-tools, liblzma-dev, libsystemd-dev, bpftrace (>= 0.9.2) [amd64 arm64 ppc64el], libibumad-dev [amd64 arm64 mips64el ppc64el s390x], libibmad-dev [amd64 arm64 mips64el ppc64el s390x], manpages
+Build-Depends: bison, flex, gawk, procps, pkg-config, debhelper (>= 5), perl (>= 5.6), libreadline-dev | libreadline5-dev | libreadline-gplv2-dev, chrpath, libbsd-dev [kfreebsd-any], libkvm-dev [kfreebsd-any], python3-dev, libnspr4-dev, libnss3-dev, libsasl2-dev, libuv1-dev, libssl-dev, libavahi-common-dev, qtbase5-dev, qtbase5-dev-tools, libqt5svg5-dev, qtchooser, autotools-dev, zlib1g-dev, autoconf, libclass-dbi-perl, libdbd-mysql-perl, python3-psycopg2, dh-python, libpfm4-dev, libncurses5-dev, python3-six, python3-json-pointer, python3-requests, libextutils-autoinstall-perl, libxml-tokeparser-perl, librrds-perl, libjson-perl, libwww-perl, libnet-snmp-perl, libnss3-tools, liblzma-dev, libsystemd-dev, bpftrace (>= 0.9.2) [amd64 arm64 ppc64el], libibumad-dev, libibmad-dev, manpages
 Standards-Version: 3.9.3
 X-Python3-Version: >= 3.3
 

Bug#974073: Help with an arm64 specific gcc internal error with polymake

[Dominic Hargreaves]

On Wed, Nov 11, 2020 at 10:12:19PM +, Dominic Hargreaves wrote:
> During the perl 5.32 transition we observed a build failure on arm64 which
> is reproducible on the porterbox and at lease three different buidds::
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974073
> 
> However Matthias Klose (and I) tried to isolate the problem using the
> expanded source and that doesn't fail:
> 
> g++ -c -std=c++14 -g -O2 -fPIC -fstack-protector-strong -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 SparseMatrix-2.ii
> 
> (source file attached).
> 
> Can anyone help try and pin this down?

Matthias theorized that this could be the OOM killer, which is why
it doesn't happen when built sequentially.

Does anyone have access to a higher RAM machine than the buildds
and amdahl (11GiB) that could help test this theory (and maybe do a
porter upload to unblock the issue for the perl transition?

Cheers
Dominic

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Dominic Hargreaves]

On Sat, Nov 14, 2020 at 03:01:10PM +0100, Marco d'Itri wrote:
> On Nov 14, Dominic Hargreaves  wrote:
> 
> > This seems to be same as #953562 which was reported in March.
> Why do you think that this is the same?

The symptoms seem identical, at least. Maybe there is more than one
root cause that I'm not aware of - feel free to unmerge if you don't
think the new problem is caused by Replaces not working.

Thanks
Dominic

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Dominic Hargreaves]

Control: reassign -1 libcrypt1
Control: forcemerge -1 953562

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 have a good idea how to fix that, though. :-(

Right - perl-base 5.32.0-5 has the following:

Pre-Depends: libc6 (>= 2.29), libcrypt1 (>= 1:4.1.0)

I don't think we can do anything about this on the perl side, so
reassigning to libcrypt.

This seems to be same as #953562 which was reported in March.

Bug#974704: pcp: FTBFS on some archs: Cannot find (any matches for) "usr/lib/pcp/pmdas/infiniband[...]

[Dominic Hargreaves]

On Sat, Nov 14, 2020 at 12:35:04AM +, Dominic Hargreaves wrote:
> This package FTBFS on the architectures which don't have bpftrace as a
> dependency since:

...

Also, if you do do another upload, please can you do a source-only
upload or make sure that you build on an up-to-date sid (the upload
on Wednesday was built against perl 5.30 on amd64).

Thanks
Dominic

Bug#974704: pcp: FTBFS on some archs: Cannot find (any matches for) "usr/lib/pcp/pmdas/infiniband[...]

[Dominic Hargreaves]

Source: pcp
Version: 5.2.2-1
Severity: serious
Justification: FTBFS on archs that previously worked
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition
Control: block 968912 with -1

This package FTBFS on the architectures which don't have bpftrace as a
dependency since:

dh_install: warning: Cannot find (any matches for) 
"usr/lib/pcp/pmdas/infiniband/Install" (tried in debian/pcp, debian/tmp)

dh_install: warning: pcp-pmda-infiniband missing files: 
usr/lib/pcp/pmdas/infiniband/Install
...
dh_install: error: missing files, aborting

See 
https://buildd.debian.org/status/fetch.php?pkg=pcp=armel=5.2.2-1=1605310204=0
and https://buildd.debian.org/status/package.php?p=pcp

for full details.

Thanks
Dominic

Bug#961154: debarchiver: diff for NMU version 0.11.5+nmu1

[Dominic Hargreaves]

Control: tags 961154 + patch
Control: tags 961154 + pending

Dear maintainer,

I've prepared an NMU for debarchiver (versioned as 0.11.5+nmu1) and
uploaded it to DELAYED/0. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru debarchiver-0.11.5/debian/changelog debarchiver-0.11.5+nmu1/debian/changelog
--- debarchiver-0.11.5/debian/changelog	2020-05-03 20:10:21.0 +0100
+++ debarchiver-0.11.5+nmu1/debian/changelog	2020-11-10 22:47:54.0 +
@@ -1,3 +1,10 @@
+debarchiver (0.11.5+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Build-Depends on libpod-parser-perl. Closes: #961154.
+
+ -- Dominic Hargreaves   Tue, 10 Nov 2020 22:47:54 +
+
 debarchiver (0.11.5) unstable; urgency=medium
 
   * Added source format "3.0 (native)".
diff -Nru debarchiver-0.11.5/debian/control debarchiver-0.11.5+nmu1/debian/control
--- debarchiver-0.11.5/debian/control	2020-05-03 20:10:21.0 +0100
+++ debarchiver-0.11.5+nmu1/debian/control	2020-11-10 22:46:16.0 +
@@ -2,7 +2,7 @@
 Section: devel
 Priority: optional
 Maintainer: Ola Lundqvist 
-Build-Depends-Indep: perl (>= 5.6.0-16), po4a
+Build-Depends-Indep: perl (>= 5.6.0-16), po4a, libpod-parser-perl
 Build-Depends: debhelper-compat (= 12)
 Standards-Version: 4.3.0
 

Bug#961154: debarchiver: needs a build dependency on libpod-parser-perl

[Dominic Hargreaves]

Having just discussed this a bit more with the release team, I'll do
an NMU now since it's a trivial change.

Best
Dominci

On Sun, Nov 08, 2020 at 06:13:44PM +, Dominic Hargreaves wrote:
> Hi,
> 
> Could you please upload this soon? We've just kicked off the transition
> so this will prevent your package from being buildable in unstable soon.
> 
> Cheers
> Dominic
> 
> On Thu, May 21, 2020 at 08:56:35AM +0200, Ola Lundqvist wrote:
> > Thank you. Will add on next ipload.
> > 
> > Den ons 20 maj 2020 22:06Niko Tyni  skrev:
> > 
> > > Package: debarchiver
> > > Version: 0.11.5
> > > Severity: normal
> > > User: debian-p...@lists.debian.org
> > > Usertags: perl-5.32-transition
> > >
> > > This package uses /usr/bin/podselect, part of the Pod-Parser distribution
> > > which will be removed from the Perl core in upcoming version 5.32.
> > > It is being packaged separately for Debian as libpod-parser-perl
> > > (#960790), and affected packages need to declare appropriate dependencies
> > > on that.
> > >
> > > As the perl core packages already Provide libpod-parser-perl, these
> > > dependencies can be added at any time and do not need to wait for the
> > > separate package to enter sid.
> > >
> > > Please consider adding a build dependency sooner rather than later,
> > > to help our testing efforts.
> > >
> > >  make[3]: Entering directory '/<>/po4a'
> > >  podselect ../src/debarchiver.pl > debarchiver.pod
> > >
> > > --
> > > Niko Tyni   nt...@debian.org
> > >

Bug#942135: Сannot install Perl 5.30.0-6 without deleting the libgtk2-perl package

[Dominic Hargreaves]

On Tue, Nov 10, 2020 at 09:03:42AM +0100, intrigeri wrote:
> Hi,
> 
> Dominic Hargreaves (2020-11-09):
> > A year on, it seems there's almost no realistic prospect of this
> > package coming back. Shall we remove it from sid?
> 
> Thank you for caring!
> 
> Quoting the plan I proposed #912860: "I intend to remove libgtk2-perl
> from testing soon after the Buster release, and then from sid later
> during the Bullseye development cycle".
> 
> In principle, I see value in sticking to the announced timeline, in
> order to lower the risk of bad feelings in case any of the
> reverse-dependencies' maintainers somehow relied on it.
> 
> In practice, if we removed libgtk2-perl now, I would not expect any
> trouble about:
> 
>  - asciio (#912870): I filed a RFH, the maintainer won't have time to
>do the work themselves
> 
>  - gprename (#912880): no reply from maintainer since 2 years
>despite 2 pings
> 
>  - tinyca (#912889): the maintainer is actively working on a solution
> 
>  - libdata-treedumper-renderer-gtk-perl (#912874): maintained by
>pkg-perl, only reason why I did not remove it from sid yet is asciio
> 
> However, wrt. libcircle-fe-gtk-perl (#932220), the brief discussion
> I had with Andrej at DebConf19 suggests it's a touchy topic.
> If someone else, who wants to speed up the removal, takes the lead
> here: great (and please check with Andrej). Otherwise, personally I'd
> rather avoid the extra effort, and simply stick with the originally
> announced timeline.

Thanks for the summary. I got the wrong impression from this
bug and didn't spot the merged bugs at all :(

We're quite a way through the bullseye development cycle already but
I guess you mean once we're into the deep freeze when there is no longer
any chance of reviving those packages for bullseye, which makes sense
to me.

Cheers
Dominic

Bug#974143: marked as pending in libencode-arabic-perl

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

Bug #974143 in libencode-arabic-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libencode-arabic-perl/-/commit/c1bbdb128dd90782a302a1ed62a20d87d621fc3e


Suppress 'Useless use of /d modifier' warnings

The transliteration lists are dynamically created. Fixes autopkgtest
failures with perl 5.32 (Closes: #974143)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/974143

Bug#974134: marked as pending in libdbd-csv-perl

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

Bug #974134 in libdbd-csv-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libdbd-csv-perl/-/commit/d271e3f705c7167facf66a90beec8e107aaa85a4


Fix test failure with libdbi-perl 1.643-3 (Closes: #974134)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/974134

Bug#948706: closed by Debian FTP Masters (reply to Julian Gilbey ) (Bug#948706: fixed in greylistd 0.9.0)

[Dominic Hargreaves]

On Mon, Nov 09, 2020 at 11:43:27PM +0100, Chris Hofstaedtler wrote:
> Hello Julian,
> 
> * Debian Bug Tracking System  [201109 22:41]:
> > This is an automatic notification regarding your Bug report
> > which was filed against the greylistd package:
> > 
> > #948706: greylistd: python3 version fails to start - conversion from 
> > python2 very broken
> ...
> > Changed-By: Julian Gilbey 
> 
> Could I kindly ask you to upload a new .1 version, source-only, to
> allow migration to testing?
> 
> Right now, the migration tracker says:
>   Not built on buildd: arch all binaries uploaded by jdg, a new source-only 
> upload is needed to allow migration

Adding Julian to CC and +1 to this request.

Julian - thanks for your work on this package! Do you have any plans to
adopt it?

Cheers
Dominic

Bug#942135: Сannot install Perl 5.30.0-6 without deleting the libgtk2-perl package

[Dominic Hargreaves]

On Fri, Oct 11, 2019 at 08:02:29AM +0200, intrigeri wrote:
> Control: forwarded -1 https://gitlab.gnome.org/GNOME/perl-gtk2/issues/3
> Control: tag -1 + upstream
> Control: retitle -1 libgtk2-perl: FTBFS with gdk-pixbuf 2.39+ and not built 
> against perl 5.30
> Control: severity -1 serious
> 
> Hi,
> 
> Dominic Hargreaves:
> > It seems uncertain at the moment - the package has been removed from
> > testing (see #912860) and is clearly not coming back. It's also now FTBFS,
> > possibly related to the Gnome 3 transition?:
> 
> Confirmed: when I noticed that this package was blocking the
> GNOME 3.34 transition, I told the release team that this package would
> be removed from testing later during the Bullseye development cycle
> anyway, so they could as well remove it already.
> 
> At this point, now that my objective of removing the package from
> testing has been met, I have little motivation for fixing it in sid.

A year on, it seems there's almost no realistic prospect of this
package coming back. Shall we remove it from sid?

Dominic

Bug#974061: postgresql-12: FTBFS during perl 5.32 transition

[Dominic Hargreaves]

On Mon, Nov 09, 2020 at 02:43:18PM +, Niko Tyni wrote:
> On Mon, Nov 09, 2020 at 02:16:57PM +0000, 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=amd64=12.4-3%2Bb1=1604914304=0
> 
> This looks relevant, hope it helps:
> 
>  https://www.postgresql.org/message-id/16689-57701daa23b37...@postgresql.org

In which case there seems to be a patch here:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4a071afbd056282746a5bc9362e87f579a56402d

But the build logs reveal quite a few other errors, so I'm not sure whether
this is the only problem?

Dominic.

Bug#974058: polymake: FTBFS on arm64: ninja: build stopped: subcommand failed.

[Dominic Hargreaves]

Control: retitle -1 polymake: FTBFS on arm64: internal compiler error: 
canonical types differ for identical types

On Mon, Nov 09, 2020 at 02:03:39PM +, Dominic Hargreaves wrote:
> This package FTBFS on arm64:
> <https://buildd.debian.org/status/fetch.php?pkg=polymake=arm64=4.1-4%2Bb2=1604910083=0>
> 
> I've just given it back in case it's a transient issue.

Retrying didn't help.

The actual error seems to be:

/<>/include/core/polymake/GenericVector.h:304:11: internal 
compiler error: canonical types differ for identical types 
‘std::enable_if<! std::is_same >::value) && 
polymake::is_derived_from_instance_of::type>::type, pm::GenericVector>::value) && 
pm::GenericVector, pm::Integer>::temp_ignore >::value)>::value) && 
pm::isomorphic_types::type>::type::element_type>::value), void>’ and 
‘std::enable_if<! std::is_same >::value) && 
polymake::is_derived_from_instance_of::type>::type, pm::GenericVector>::value) && 
pm::GenericVector, false, pm::sparse2d::full> >&, pm::NonSymmetric>, 
pm::Integer>::temp_ignore >::value)>::value) && 
pm::isomorphic_types::type>::type::element_type>::value), void>’
  304 |struct lazy_op>::value &&
  |   
~
  306 |is_generic_vector::value &&
  |~
  307 |temp_ignore::value>::value &&
  |
~
  308 |isomorphic_types::element_type>::value>> {
  |
~~
0x91afa3 comptypes(tree_node*, tree_node*, int)
../../src/gcc/cp/typeck.c:1561
0x91a467 structural_comptypes
../../src/gcc/cp/typeck.c:1410
0x846ba7 template_args_equal(tree_node*, tree_node*, bool)
../../src/gcc/cp/pt.c:9124
0x84656f template_args_equal(tree_node*, tree_node*, bool)
../../src/gcc/cp/pt.c:9085
0x84656f comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**, 
bool)
../../src/gcc/cp/pt.c:9172
0x84656f comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**, 
bool)
../../src/gcc/cp/pt.c:9152
0x8468a3 template_args_equal(tree_node*, tree_node*, bool)
../../src/gcc/cp/pt.c:9095
0x84656f template_args_equal(tree_node*, tree_node*, bool)
../../src/gcc/cp/pt.c:9085
0x84656f comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**, 
bool)
../../src/gcc/cp/pt.c:9172
0x84656f comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**, 
bool)
../../src/gcc/cp/pt.c:9152
0x855a7b spec_hasher::equal(spec_entry*, spec_entry*)
../../src/gcc/cp/pt.c:1714
0x8b73cb hash_table::find_with_hash(spec_entry* const&, unsigned int)
../../src/gcc/hash-table.h:917
0x891e77 lookup_template_class_1
../../src/gcc/cp/pt.c:9780
0x8958cf lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, 
int, int)
../../src/gcc/cp/pt.c:10120
0x8958cf tsubst_aggr_type
../../src/gcc/cp/pt.c:13413
0x8a2307 tsubst_template_decl
../../src/gcc/cp/pt.c:14085
0x87dc33 tsubst_decl
../../src/gcc/cp/pt.c:14226
0x8698cb most_specialized_partial_spec(tree_node*, int)
../../src/gcc/cp/pt.c:24684
0x8b14f7 instantiate_class_template_1
../../src/gcc/cp/pt.c:11583
0x8b457b instantiate_class_template(tree_node*)
../../src/gcc/cp/pt.c:12122
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccuRLJIg.out file, please attach this to 
your bugreport.

I'll file a blocking bug on gcc.

Bug#974063: postgresql-13: FTBFS during perl 5.32 transition

[Dominic Hargreaves]

Source: postgresql-13
Version: 13.0-6
Severity: serious
Justification: ftbfs
Tags: ftbfs
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition
Control: block 968912 with -1

Similar to postgresql-12 (#974061) postgresql-13 FTBFS on multiple archs, eg:

https://buildd.debian.org/status/fetch.php?pkg=postgresql-13=amd64=13.0-6%2Bb1=1604915618=0

Unfortunately, postgresql-13 wasn't in sid at the point we did our
last full rebuild test. plperl does seem to be implicated in the error
output:

2020-11-09 09:53:28.680 UTC client backend[31345] pg_regress/event_trigger 
ERROR:  object audit_tbls.schema_two_table_three of type table cannot be dropped
2020-11-09 09:53:28.680 UTC client backend[31345] pg_regress/event_trigger 
CONTEXT:  PL/pgSQL function undroppable() line 14 at RAISE
SQL statement "DROP TABLE IF EXISTS audit_tbls.schema_two_table_three"
PL/pgSQL function test_evtrig_dropped_objects() line 8 at EXECUTE
2020-11-09 09:53:28.680 UTC client backend[31345] pg_regress/event_trigger 
STATEMENT:  DROP SCHEMA schema_one, schema_two CASCADE;
2020-11-09 09:53:28.818 UTC client backend[31345] pg_regress/event_trigger 
ERROR:  object schema_one.table_three of type table cannot be dropped
2020-11-09 09:53:28.818 UTC client backend[31345] pg_regress/event_trigger 
CONTEXT:  PL/pgSQL function undroppable() line 14 at RAISE
2020-11-09 09:53:28.818 UTC client backend[31345] pg_regress/event_trigger 
STATEMENT:  DROP SCHEMA schema_one, schema_two CASCADE;
2020-11-09 09:53:28.985 UTC client backend[31345] pg_regress/event_trigger 
ERROR:  pg_event_trigger_table_rewrite_oid() can only be called in a 
table_rewrite event trigger function
2020-11-09 09:53:28.985 UTC client backend[31345] pg_regress/event_trigger 
STATEMENT:  select pg_event_trigger_table_rewrite_oid();
2020-11-09 09:53:28.998 UTC client backend[31345] pg_regress/event_trigger 
ERROR:  rewrites not allowed
2020-11-09 09:53:28.998 UTC client backend[31345] pg_regress/event_trigger 
CONTEXT:  PL/pgSQL function test_evtrig_no_rewrite() line 3 at RAISE
2020-11-09 09:53:28.998 UTC client backend[31345] pg_regress/event_trigger 
STATEMENT:  alter table rewriteme alter column foo type numeric;
2020-11-09 09:53:29.024 UTC client backend[31345] pg_regress/event_trigger 
ERROR:  cannot alter type "rewritetype" because column "rewritemetoo3.a" uses it
2020-11-09 09:53:29.024 UTC client backend[31345] pg_regress/event_trigger 
STATEMENT:  alter type rewritetype alter attribute a type varchar cascade;
2020-11-09 09:53:30.668 UTC client backend[31354] pg_regress/stats LOG:  
wait_for_stats delayed 0.543818 seconds
2020-11-09 09:53:30.668 UTC client backend[31354] pg_regress/stats CONTEXT:  
PL/pgSQL function wait_for_stats() line 48 at RAISE
2020-11-09 09:53:30.668 UTC client backend[31354] pg_regress/stats STATEMENT:  
SELECT wait_for_stats();
2020-11-09 09:53:30.836 UTC postmaster[29982] LOG:  received fast shutdown 
request
2020-11-09 09:53:30.836 UTC postmaster[29982] LOG:  aborting any active 
transactions
2020-11-09 09:53:30.839 UTC postmaster[29982] LOG:  background worker "logical 
replication launcher" (PID 29991) exited with exit code 1
2020-11-09 09:53:30.840 UTC checkpointer[29986] LOG:  shutting down
2020-11-09 09:53:30.840 UTC checkpointer[29986] LOG:  checkpoint starting: 
shutdown immediate
2020-11-09 09:53:31.100 UTC checkpointer[29986] LOG:  checkpoint complete: 
wrote 10551 buffers (64.4%); 0 WAL file(s) added, 0 removed, 13 recycled; 
write=0.227 s, sync=0.000 s, total=0.259 s; sync files=0, longest=0.000 s, 
average=0.000 s; distance=220237 kB, estimate=220237 kB
2020-11-09 09:53:31.131 UTC postmaster[29982] LOG:  database system is shut down

Please could you take a look?

Cheers
Dominic

Bug#974061: postgresql-12: FTBFS during perl 5.32 transition

[Dominic Hargreaves]

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=amd64=12.4-3%2Bb1=1604914304=0

2020-11-09 09:31:39.067 UTC [386] LOG:  received fast shutdown request
2020-11-09 09:31:39.067 UTC [386] LOG:  aborting any active transactions
2020-11-09 09:31:39.070 UTC [386] LOG:  background worker "logical replication 
launcher" (PID 395) exited with exit code 1
2020-11-09 09:31:39.073 UTC [390] LOG:  shutting down
2020-11-09 09:31:39.073 UTC [390] LOG:  checkpoint starting: shutdown immediate
2020-11-09 09:31:39.185 UTC [390] LOG:  checkpoint complete: wrote 10234 
buffers (62.5%); 0 WAL file(s) added, 0 removed, 13 recycled; write=0.092 s, 
sync=0.000 s, total=0.111 s; sync files=0, longest=0.000 s, average=0.000 s; 
distance=206300 kB, estimate=206300 kB
2020-11-09 09:31:39.206 UTC [386] LOG:  database system is shut down
make[1]: *** [debian/rules:196: override_dh_auto_test-arch] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:95: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

FWIW, 12.4-1 did not fail on our test rebuilds in September:

http://perl.debian.net/rebuild-logs/perl-5.32-throwaway/postgresql-12_12.4-1/postgresql-12_12.4-1_amd64.build

Please could you take a look?

Cheers
Dominic

Bug#974058: polymake: FTBFS on arm64: ninja: build stopped: subcommand failed.

[Dominic Hargreaves]

Source: polymake
Version: 4.1-4
Severity: serious
Justification: ftbfs
Tags: ftbfs
User: debian-p...@lists.debian.org 
Usertags: perl-5.32-transition 
Control: block 968912 with -1

This package FTBFS on arm64:


I've just given it back in case it's a transient issue.

Dominic

Bug#974033: libapache2-mod-perl2 FTBFS on IPV6-only buildds

[Dominic Hargreaves]

Control: severity -1 important

On Mon, Nov 09, 2020 at 12:17:55PM +0200, Adrian Bunk wrote:
> Source: libapache2-mod-perl2
> Version: 2.0.11-2
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=libapache2-mod-perl2=amd64=2.0.11-2%2Bb1=1604895223=0
> 
> ...
> # Failed test 1 in t/filter/both_str_req_proxy.t at line 18
> t/filter/both_str_req_proxy.t ... 
> 1..1
> # Running under perl version 5.032000 for linux
> # Current time local: Mon Nov  9 04:11:13 2020
> # Current time GMT:   Mon Nov  9 04:11:13 2020
> # Using Test.pm version 1.31
> # Using Apache/Test.pm version 1.42
> # testing : lc input and reverse output filters
> # expected: 'abcdefghijklmnopqrstuvwxyz0123456789'
> # received: '
> # 
> # 403 Forbidden
> # 
> # Forbidden
> # You don\'t have permission to access this resource.
> # 
> # Apache/2.4.46 (Debian) world domination series/2.0 mod_perl/2.0.11 
> Perl/v5.32.0 Server at localhost Port 8529
> # 
> # '
> not ok 1
> Failed 1/1 subtests 
> ...
> request has failed (the response code was: 503)
> see t/logs/error_log for more details
> t/modules/proxy.t ... 
> # connecting to http://localhost:8536/TestModules__proxy
> 1..1
> # Running under perl version 5.032000 for linux
> # Current time local: Mon Nov  9 04:13:18 2020
> # Current time GMT:   Mon Nov  9 04:13:18 2020
> # Using Test.pm version 1.31
> # Using Apache/Test.pm version 1.42
> Dubious, test returned 2 (wstat 512, 0x200)
> Failed 1/1 subtests
> ...
> Test Summary Report
> ---
> t/filter/both_str_req_proxy.t (Wstat: 0 Tests: 1 Failed: 1)
>   Failed test:  1
> t/modules/proxy.t (Wstat: 512 Tests: 0 Failed: 0)
>   Non-zero exit status: 2
>   Parse errors: Bad plan.  You planned 1 tests but ran 0.
> Files=245, Tests=2589, 279 wallclock secs ( 1.18 usr  0.92 sys + 199.06 cusr 
> 66.41 csys = 267.57 CPU)
> Result: FAIL
> Failed 2/245 test programs. 1/2589 subtests failed.

Downgrading as it's been built on a retry:

https://buildd.debian.org/status/logs.php?pkg=libapache2-mod-perl2=amd64

Bug#961208: bucardo: diff for NMU version 5.5.0-1.1

[Dominic Hargreaves]

Control: tags 961208 + patch
Control: tags 961208 + pending

Dear maintainer,

I've prepared an NMU for bucardo (versioned as 5.5.0-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u bucardo-5.5.0/debian/changelog bucardo-5.5.0/debian/changelog
--- bucardo-5.5.0/debian/changelog
+++ bucardo-5.5.0/debian/changelog
@@ -1,3 +1,10 @@
+bucardo (5.5.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add dependency on libpod-parser-perl (Closes: #961208)
+
+ -- Dominic Hargreaves   Sun, 08 Nov 2020 18:26:12 +
+
 bucardo (5.5.0-1) unstable; urgency=medium
 
   [ Christoph Berg ]
diff -u bucardo-5.5.0/debian/control bucardo-5.5.0/debian/control
--- bucardo-5.5.0/debian/control
+++ bucardo-5.5.0/debian/control
@@ -11,7 +11,7 @@
 
 Package: bucardo
 Architecture: all
-Depends: ${misc:Depends}, adduser, perl (>= 5.10.0), libdbix-safe-perl, libdbd-pg-perl, libboolean-perl, lsb-base (>= 3.0-3)
+Depends: ${misc:Depends}, adduser, perl (>= 5.10.0), libdbix-safe-perl, libdbd-pg-perl, libboolean-perl, lsb-base (>= 3.0-3), libpod-parser-perl
 Recommends: postgresql-plperl
 Description: asynchronous replication system for PostgreSQL
  Bucardo is an asynchronous PostgreSQL replication system, allowing for both

Bug#971969: libdata-alias-perl: FTBFS with Perl 5.32: t/03_copy.t failure

[Dominic Hargreaves]

Control: unblock 968912 by -1

On Sat, Oct 10, 2020 at 09:54:54PM +0300, Niko Tyni wrote:
> Source: libdata-alias-perl
> Version: 1.21-1
> Severity: important
> Tags: ftbfs sid bullseye
> Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=130156
> 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 (currently in experimental).
> 
> From the build log:
> 
>Useless use of a variable in void context at t/03_copy.t line 12.
># Looks like your test exited with 2 before it could output anything.
>t/03_copy.t .. 
>1..14
>Dubious, test returned 2 (wstat 512, 0x200)
>Failed 14/14 subtests 
>
>[...]
>
>Test Summary Report
>---
>t/03_copy.t(Wstat: 512 Tests: 0 Failed: 0)
>  Non-zero exit status: 2
>  Parse errors: Bad plan.  You planned 14 tests but ran 0.
>Files=32, Tests=608,  2 wallclock secs ( 0.07 usr  0.04 sys +  1.41 cusr  
> 0.29 csys =  1.81 CPU)
>Result: FAIL

There's no sign of this being fixed upstream, and popcon is very low.
We shouldn't block the transition with this package.

Dominic

Bug#961155: pod2pdf: diff for NMU version 0.42-5.1

[Dominic Hargreaves]

Control: tags 961155 + patch
Control: tags 961155 + pending

Dear maintainer,

I've prepared an NMU for pod2pdf (versioned as 0.42-5.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru pod2pdf-0.42/debian/changelog pod2pdf-0.42/debian/changelog
--- pod2pdf-0.42/debian/changelog	2014-08-02 20:15:16.0 +0100
+++ pod2pdf-0.42/debian/changelog	2020-11-08 18:22:34.0 +
@@ -1,3 +1,10 @@
+pod2pdf (0.42-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove obsolete alternate depends on perl-modules (Closes: #961155)
+
+ -- Dominic Hargreaves   Sun, 08 Nov 2020 18:22:34 +
+
 pod2pdf (0.42-5) unstable; urgency=medium
 
   * Added libpaper-sizes-perl to suggests.
diff -Nru pod2pdf-0.42/debian/control pod2pdf-0.42/debian/control
--- pod2pdf-0.42/debian/control	2014-08-02 20:12:09.0 +0100
+++ pod2pdf-0.42/debian/control	2020-11-08 18:17:40.0 +
@@ -2,9 +2,9 @@
 Section: perl
 Priority: optional
 Build-Depends: debhelper (>= 9)
-Build-Depends-Indep: perl (>= 5.6.0-12), perl-modules,
-  perl-modules | libfile-spec-perl,
-  perl-modules | libpod-parser-perl, perl-modules | libpod-escapes-perl,
+Build-Depends-Indep: perl (>= 5.6.0-12),
+  libfile-spec-perl,
+  libpod-parser-perl, libpod-escapes-perl,
   libpdf-api2-perl (>= 0.6), libgetopt-argvfile-perl
 Maintainer: Guo Yixuan (郭溢譞) 
 Standards-Version: 3.9.5
@@ -14,9 +14,9 @@
 
 Package: pod2pdf
 Architecture: all
-Depends: ${perl:Depends}, ${misc:Depends}, perl-modules,
-  perl-modules | libfile-spec-perl,
-  perl-modules | libpod-parser-perl, perl-modules | libpod-escapes-perl,
+Depends: ${perl:Depends}, ${misc:Depends},
+  libfile-spec-perl,
+  libpod-parser-perl, libpod-escapes-perl,
   libpdf-api2-perl (>= 0.6), libgetopt-argvfile-perl
 Recommends: libimage-size-perl, libfile-type-perl
 Suggests: libpaper-specs-perl

Bug#961154: debarchiver: needs a build dependency on libpod-parser-perl

[Dominic Hargreaves]

Hi,

Could you please upload this soon? We've just kicked off the transition
so this will prevent your package from being buildable in unstable soon.

Cheers
Dominic

On Thu, May 21, 2020 at 08:56:35AM +0200, Ola Lundqvist wrote:
> Thank you. Will add on next ipload.
> 
> Den ons 20 maj 2020 22:06Niko Tyni  skrev:
> 
> > Package: debarchiver
> > Version: 0.11.5
> > Severity: normal
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.32-transition
> >
> > This package uses /usr/bin/podselect, part of the Pod-Parser distribution
> > which will be removed from the Perl core in upcoming version 5.32.
> > It is being packaged separately for Debian as libpod-parser-perl
> > (#960790), and affected packages need to declare appropriate dependencies
> > on that.
> >
> > As the perl core packages already Provide libpod-parser-perl, these
> > dependencies can be added at any time and do not need to wait for the
> > separate package to enter sid.
> >
> > Please consider adding a build dependency sooner rather than later,
> > to help our testing efforts.
> >
> >  make[3]: Entering directory '/<>/po4a'
> >  podselect ../src/debarchiver.pl > debarchiver.pod
> >
> > --
> > Niko Tyni   nt...@debian.org
> >

Bug#961152: apt-show-versions: diff for NMU version 0.22.11+nmu1

[Dominic Hargreaves]

Control: tags 961152 + patch
Control: tags 961152 + pending

Dear maintainer,

I've prepared an NMU for apt-show-versions (versioned as 0.22.11+nmu1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru apt-show-versions-0.22.11/debian/changelog apt-show-versions-0.22.11+nmu1/debian/changelog
--- apt-show-versions-0.22.11/debian/changelog	2019-02-16 11:10:23.0 +
+++ apt-show-versions-0.22.11+nmu1/debian/changelog	2020-11-08 17:23:26.0 +
@@ -1,3 +1,11 @@
+apt-show-versions (0.22.11+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build-dep on libpod-parser-perl, which is no longer shipped in
+the core perl package (closes: #961152)
+
+ -- Dominic Hargreaves   Sun, 08 Nov 2020 17:23:26 +
+
 apt-show-versions (0.22.11) unstable; urgency=medium
 
   * fix long standing bug handling incomplete entries in
diff -Nru apt-show-versions-0.22.11/debian/control apt-show-versions-0.22.11+nmu1/debian/control
--- apt-show-versions-0.22.11/debian/control	2019-02-16 11:10:23.0 +
+++ apt-show-versions-0.22.11+nmu1/debian/control	2020-11-08 17:23:26.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Christoph Martin 
 Uploaders: Andreas Hoenen 
-Build-Depends: debhelper (>= 9)
+Build-Depends: debhelper (>= 9), libpod-parser-perl
 Build-Depends-Indep: po4a
 Standards-Version: 3.9.8
 Vcs-Browser: https://salsa.debian.org/debian/apt-show-versions

Bug#969768: lib-io-socket-ip-perl: do not release with bullseye

[Dominic Hargreaves]

On Sat, Sep 26, 2020 at 05:07:13PM +0200, gregor herrmann wrote:
> Control: tag -1 + pending
> 
> On Mon, 07 Sep 2020 23:50:03 +0100, Dominic Hargreaves wrote:
> 
> > IO-Socket-IP is bundled with perl 5.30, so there is no need to ship
> > this separately.
> 
> IO-Socket-IP 0.41 has been released, without the patch for #964902
> but with some other changes:
> https://metacpan.org/pod/IO::Socket::IP
> 
> IO::Socket::IP 0.41 is bundled with perl ony starting with v5.33.2,
> which won't be in Debian any time soon.
> 
> I guess we should update libio-socket-ip-perl to 0.41 and close this
> bug with the upload (and close #969967 in libtest-tcp-perl as well).
> 
> I've pushed libio-socket-ip-perl_0.41-1 to git but wanted to give
> others a chance to comment before the actual upload.

Fine by me!

Bug#964902: marked as pending in libio-socket-ip-perl

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

Bug #964902 in libio-socket-ip-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libio-socket-ip-perl/-/commit/b3f756662f844c4862033f90732cea284b856652


Replace nov4 test patch with one from Niko Tyni which works around the 
underlying issue (Closes: #964902)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/964902

Bug#969768: lib-io-socket-ip-perl: do not release with bullseye

[Dominic Hargreaves]

Source: libio-socket-io-perl
Version: 0.39-2
Severity: serious
Justification: maintainer

IO-Socket-IP is bundled with perl 5.30, so there is no need to ship
this separately.

Bug#964902: libio-socket-ip-perl: AI_ADDRCONFIG breaks many test suites on IPv6-only hosts

[Dominic Hargreaves]

On Sat, Jul 11, 2020 at 11:14:23PM +0300, Niko Tyni wrote:
> Package: libio-socket-ip-perl
> Version: 0.39-2
> Severity: serious
> Tags: patch ipv6
> 
> This is a follow-up for #962047 "fails to build on IPv6-only buildds".
> 
> The background here is that a while ago new official build daemons were
> added that only have IPv6 connectivity, and this exposed a new class
> of build failures, mainly due to getaddrinfo(3) behaviour with the
> AI_ADDRCONFIG flag.
> 
> Quoting Julien Cristau there:
> 
> > FWIW, it seems IO::Socket::IP passes AI_ADDRCONFIG to getaddrinfo, which
> > then doesn't return ipv4 addresses because the host doesn't have
> > non-local ones, even though the address we're trying to resolve is
> > "127.0.0.1".
> > 
> > Passing either GetAddrInfoFlags => AI_NUMERICHOST or GetAddrInfoFlags =>
> > 0 to both IO::Socket::IP->new calls in the test file lets it pass, by
> > turning off the smarts in getaddrinfo.
> 
> We fixed the test suite of libio-socket-ip-perl itself in 0.39-2 by
> making it pass AI_NUMERICHOST in all the tests. However, it turns out
> that the problem is much more widespread than this.
> 
> I've been testing systematically for these issues by test rebuilding
> the whole archive, and found
> 
> 1) 138 packages that failed to build on a host with an IPv6 address
>on a "real" interface, and IPv4 + IPv6 on lo, but no internet
>connection
> 
> 2) 8 of those 138 also failed to build on a host with both an IPv6 address
>and an IPv4 address on a "real interface", still without a real internet
>connection (these are regular "needs internet" bugs, not IPv6 specific)
> 
> 3) only 42 of the remaining 130 packages fail to build with the same setup
>as 1), after applying the patch discussed below to IO::Socket::IP.
> 
> So it looks like the AI_ADDRCONFIG default of IO-Socket-IP is causing
> 88 potential build failures on the new IPv6-only buildds. Examples of
> those can be seen on for instance
> 
>  https://buildd.debian.org/status/logs.php?pkg=libmojolicious-perl
> 
>  https://buildd.debian.org/status/logs.php?pkg=libtest-redisserver-perl
> 
>  https://buildd.debian.org/status/logs.php?pkg=libwww-mechanize-perl
> 
> The attached patch changes IO-Socket-IP to pass AI_NUMERICHOST to
> getaddrinfo(3) when the address looks like an IPv4 numeric address (rather
> than a hostname), and special cases a PeerHost value of "localhost"
> not to use AI_ADDRCONFIG.
> 
> I have tried quite a few variants, and this was the best I could do
> without removing AI_ADDRCONFIG (which is a documented feature) altogether.
> (TODO: The patch does not currently update the documentation about the
> new behaviour.)
> 
> It would be good to get something like this upstream of course, and it
> will also need to go in src:perl which has a copy of IO::Socket::IP.
> 
> I've tested that this makes libio-socket-perl pass its own test suite
> without the modifications in 0.39-2, so this supersedes the current test
> suite patch.
> 
> Build logs can currently (but not guaranteed indefinitely) be found at
> 
>  http://perl.debian.net/rebuild-logs/sid-v6only/
> 
>  http://perl.debian.net/rebuild-logs/experimental-v6only/
> 
> where the latter had a patched libio-socket-ip-perl package pre-installed
> in the chroot.

[snip list of affected packages]

As a heads up, there was some discussion on debian-devel about how this
is something which should be fixed in libc. This is the bug about the
issue from this perspective:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952740

There doesn't seem any prospect of this being fixed in the near future,
so I'm planning to apply Niko's patch to libio-socket-ip-perl (and perl,
probably starting with experimental) to solve the immediate issues of
failing tests.

Dominic.

Bug#967017: [request-tracker-maintainers] Bug#967017: request-tracker4: FTBFS: can't exec /usr/bin/gpg

[Dominic Hargreaves]

Control: retitle -1 request-tracker4: FTBFS: GPG test failures

On Mon, Aug 03, 2020 at 02:05:16PM +0200, Lucas Nussbaum wrote:
> Source: request-tracker4
> Version: 4.4.4-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200802 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Relevant log extract is

[18290] [Sun Aug  2 17:07:59 2020] [warning]: Can't exec "/usr/bin/gpg": No 
such file or directory at /usr/share/perl5/GnuPG/Interface.pm line 349. 
(/<>/lib/RT/Test.pm:716)
exec() error: No such file or directory at /usr/share/perl5/GnuPG/Interface.pm 
line 349.
BEGIN failed--compilation aborted at t/crypt/gnupg/attachments-in-db.t line 10.
[18287] [Sun Aug  2 17:07:59 2020] [warning]: Use of uninitialized value $line 
in pattern match (m//) at /usr/share/perl5/GnuPG/Interface.pm line 822. 
(/<>/lib/RT/Test.pm:716)
[18287] [Sun Aug  2 17:07:59 2020] [warning]: Use of uninitialized value $a in 
split at /usr/share/perl5/GnuPG/Interface.pm line 836. 
(/<>/lib/RT/Test.pm:716)
[18287] [Sun Aug  2 17:07:59 2020] [warning]: Use of uninitialized value $a in 
split at /usr/share/perl5/GnuPG/Interface.pm line 836. 
(/<>/lib/RT/Test.pm:716)
GnuPG Version 1.4 or 2.2+ required at /<>/lib/RT/Crypt/GnuPG.pm 
line 1851.
BEGIN failed--compilation aborted at t/crypt/gnupg/attachments-in-db.t line 10.

...

This seems related to changes in libgnupg-interface-perl, which on the
face of it is ignoring the instruction to use 'gpg1' (configured via
the test_gnupg_interface_gpg1.diff patch). I can't immediately see why
that's happening but it seems related to the recent changes
libgnupg-interface-perl.

Andrew, any clues?

Dominic.

Bug#963387: [request-tracker-maintainers] Bug#963387: Bug#963387: Bug#963387: request-tracker4: FTBFS: CORE missing dependencies: Plack::Handler::Starlet ...MISSING

[Dominic Hargreaves]

Control: reassign -1 libmojolicious-perl
Control: retitle -1 libmojolicious-perl: Invalid selectors (breaks RT)
Control: found -1 8.54+dfsg-1
Control: fixed -1 8.55+dfsg-1
Control: affects -1 request-tracker4

On Tue, Jun 23, 2020 at 12:19:03AM +0100, Dominic Hargreaves wrote:
> > Almost certainly triggered by the recent uploads of libmojolicious-perl.
> > It happens with both 8.55+dfsg-1 (sid) and 8.54+dfsg-1 (bullseye).
> 
> Confirmed it doesn't happen with 8.53. Forwarded upstream.

I got this wrong, 8.55 is fine - it's only 8.54 that's broken. See
changelog entry:

8.55  2020-06-18
  - Fixed a regression in Mojo::DOM::CSS that caused some selectors to not be 
valid anymore.

Bug#963853: [Pkg-clamav-devel] Bug#963853: clamav: FTBFS on IPv6-only environments

[Dominic Hargreaves]

On Tue, Jun 30, 2020 at 08:28:15AM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-06-28 12:48:20 [+0100], Dominic Hargreaves wrote:
> > Source: clamav
> > Version: 0.102.3+dfsg-1
> > Severity: serious
> > Justification: FTBFS (when it built before)
> > 
> > During archive-wide test rebuilding of an IPv6-only environment (which
> 
> Is this decision blessed by the release team? If so where is it
> documented?

If you're asking about the decision to introduce IPv-only buildds,
then I don't really know the answer. I was unable to find any
announcement/discussion about an introduction of ipv6 only buildds,
unfortunately. But the buildds are there - the perl team has had this
happen on several occasions during normal uploads.

We (perl team) did a full archive rebuild to assess the impact, which
seems to be around 25 non-perl-related packages. We should probably add
a usertag and maybe post more generally about this to centralise the
discussion.

Best
Dominic

Bug#963857: gammaray: FTBFS on IPv6-only environments

[Dominic Hargreaves]

Source: gammaray
Version: 2.11.1-1
Severity: serious
Justification: FTBFS (when it built before)

During archive-wide test rebuilding of an IPv6-only environment (which
appears on some normal buildds)[1] we noticed that this package fails:

: No symbol table info available.
4: #57 0x5646a45dc6d3 in main (argc=, argv=0x7ffdb7aca8c8) 
at ./tests/test_connections.cpp:293
4: app = 
4: tc = { = {}, static staticMetaObject = {d = 
{superdata = 0x7f414b1f1980 , stringdata = 
0x5646a45e0240 , data = 0x5646a45e01a0 
, static_metacall = 0x5646a45dc920 
, 
relatedMetaObjects = 0x0, extradata = 0x0}}, m_argc = 1, m_argv = 
0x7ffdb7aca8c8}
4: Detaching from program: 
/<>/obj-x86_64-linux-gnu/bin/connectiontest, process 2710977
4: [Inferior 1 (process 2710977) detached]
4: QFATAL : TestMain::threading() Received signal 11
4:  Function time: 93ms Total time: 5226ms
4: FAIL!  : TestMain::threading() Received a fatal error.
4:Loc: [Unknown file(0)]
4: Totals: 32577 passed, 1260715025 failed, 1260719888 skipped, 32577 
blacklisted, 8882ms
4: * Finished testing of TestMain *
4: === End of stack trace ===
4: QFatal in connectiontest 
(/<>/obj-x86_64-linux-gnu/bin/connectiontest)
4: START BACKTRACE:
4: 1QMessageLogger::fatal(char const*, ...) const ()
4: 2/usr/lib/x86_64-linux-gnu/libQt5Test.so.5 ()
4: 3/lib/x86_64-linux-gnu/libc.so.6 ()
4: 4/usr/lib/x86_64-linux-gnu/libQt5Core.so.5 ()
4: 5/usr/lib/x86_64-linux-gnu/libQt5Core.so.5 ()
4: 6/usr/lib/x86_64-linux-gnu/libQt5Core.so.5 ()
4: 7/usr/lib/x86_64-linux-gnu/libQt5Core.so.5 ()
4: 8QMetaMethod::invoke(QObject*, Qt::ConnectionType, 
QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument) const ()
4: 9
/<>/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/gammaray/2.11/qt5_12-x86_64/../../../libgammaray_kitemmodels-qt5_12-x86_64.so.2.11.1
 ()
4: 10   
/<>/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/gammaray/2.11/qt5_12-x86_64/../../../libgammaray_kitemmodels-qt5_12-x86_64.so.2.11.1
 ()
4: 11   QMetaObject::activate(QObject*, int, int, void**) ()
4: 12   QAbstractItemModel::rowsInserted(QModelIndex const&, int, int, 
QAbstractItemModel::QPrivateSignal) ()
4: 13   QAbstractItemModel::endInsertRows() ()
4: 14   
/<>/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/gammaray/2.11/qt5_12-x86_64/../../../libgammaray_core-qt5_12-x86_64.so.2.11.1
 ()
4: 15   QMetaObject::activate(QObject*, int, int, void**) ()
4: 16   GammaRay::Probe::objectCreated(QObject*) ()
4: 17   GammaRay::Probe::objectFullyConstructed(QObject*) ()
4: 18   GammaRay::Probe::processQueuedObjectChanges() ()
4: 19   QMetaObject::activate(QObject*, int, int, void**) ()
4: 20   QTimer::timeout(QTimer::QPrivateSignal) ()
4: 21   QObject::event(QEvent*) ()
4: 22   QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
4: 23   QApplication::notify(QObject*, QEvent*) ()
4: 24   QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
4: 25   QTimerInfoList::activateTimers() ()
4: 26   /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 ()
4: 27   g_main_context_dispatch ()
4: 28   /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 ()
4: 29   g_main_context_iteration ()
4: 30   
QEventDispatcherGlib::processEvents(QFlags) ()
4: 31   QEventLoop::exec(QFlags) ()
4: 32   /<>/obj-x86_64-linux-gnu/bin/connectiontest ()
4: 33   /<>/obj-x86_64-linux-gnu/bin/connectiontest ()
4: 34   QMetaMethod::invoke(QObject*, Qt::ConnectionType, 
QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument) const ()
4: 35   /usr/lib/x86_64-linux-gnu/libQt5Test.so.5 ()
4: 36   /usr/lib/x86_64-linux-gnu/libQt5Test.so.5 ()
4: 37   /usr/lib/x86_64-linux-gnu/libQt5Test.so.5 ()
4: 38   QTest::qRun() ()
4: 39   QTest::qExec(QObject*, int, char**) ()
4: 40   /<>/obj-x86_64-linux-gnu/bin/connectiontest ()
4: 41   QObject::event(QEvent*) ()
4: 42   QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
4: 43   QApplication::notify(QObject*, QEvent*) ()
4: 44   QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
4: 45   QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) 
()
4: 46   /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 ()
4: END BACKTRACE
4: Injector error: Process crashed
 4/53 Test  #4: connectiontest-style-filter ...***Failed8.95 sec

The full log is available at 
http://perl.debian.net/rebuild-logs/sid-v6only/gammaray_2.11.1-1/gammaray_2.11.1-1_amd64-2020-06-14T14:09:54Z.build

One way to replicate this environment is like so:

  # unshare -n
  # ip li set lo up
  # ip li add dummy0 type dummy
  # ip li set dummy0 up

Cheers
Dominic

[1] this test showed approximately 100 packages in the archive failing,
but nearly all of them were due to the behaviour of 

Bug#963856: datalad: FTBFS on IPv6-only environments

[Dominic Hargreaves]

Source: datalad
Version: 0.12.6-1
Severity: serious
Justification: FTBFS (when it built before)

During archive-wide test rebuilding of an IPv6-only environment (which
appears on some normal buildds)[1] we noticed that this package fails:

ERROR: datalad.interface.tests.test_add_archive_content.test_add_archive_content
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/<>/.pybuild/cpython3_3.8_datalad/build/datalad/tests/utils.py", 
line 1200, in newfunc
raise exc_info[1]
  File 
"/<>/.pybuild/cpython3_3.8_datalad/build/datalad/tests/utils.py", 
line 1172, in newfunc
ret = func(*args, **kwargs)
  File 
"/<>/.pybuild/cpython3_3.8_datalad/build/datalad/tests/utils.py", 
line 559, in newfunc
return t(*(arg + (d,)), **kw)
  File 
"/<>/.pybuild/cpython3_3.8_datalad/build/datalad/tests/utils.py", 
line 671, in newfunc
return tfunc(*(args + (path, url)), **kwargs)
  File 
"/<>/.pybuild/cpython3_3.8_datalad/build/datalad/tests/utils.py", 
line 732, in newfunc
return t(*(arg + (filename,)), **kw)
  File 
"/<>/.pybuild/cpython3_3.8_datalad/build/datalad/interface/tests/test_add_archive_content.py",
 line 186, in test_add_archive_content
repo.add_urls([opj(url, '1.tar.gz')], options=["--pathdepth", "-1"])
  File 
"/<>/.pybuild/cpython3_3.8_datalad/build/datalad/support/annexrepo.py",
 line 1967, in add_urls
self._run_annex_command('addurl', annex_options=options + urls,
  File 
"/<>/.pybuild/cpython3_3.8_datalad/build/datalad/support/annexrepo.py",
 line 1003, in _run_annex_command
return self._run_command_files_split(
  File 
"/<>/.pybuild/cpython3_3.8_datalad/build/datalad/support/gitrepo.py",
 line 1930, in _run_command_files_split
out_, err_ = func(
  File "/<>/.pybuild/cpython3_3.8_datalad/build/datalad/cmd.py", 
line 718, in run
out, err = super(GitRunner, self).run(
  File "/<>/.pybuild/cpython3_3.8_datalad/build/datalad/cmd.py", 
line 544, in run
raise CommandError(str(cmd), msg, status, out[0], out[1])
datalad.support.exceptions.CommandError: CommandError: command '['git-annex', 
'addurl', '-c', 'annex.dotfiles=true', '--pathdepth', '-1', 
'http://127.0.0.1:36559/1.tar.gz']' failed with exitcode 1
Failed to run ['git-annex', 'addurl', '-c', 'annex.dotfiles=true', 
'--pathdepth', '-1', 'http://127.0.0.1:36559/1.tar.gz'] under 
'/tmp/datalad_temp_test_add_archive_content59pn23bs'. Exit code=1.

The full log is available at 
http://perl.debian.net/rebuild-logs/sid-v6only/datalad_0.12.6-1/datalad_0.12.6-1_amd64-2020-06-28T06:56:47Z.build

One way to replicate this environment is like so:

  # unshare -n
  # ip li set lo up
  # ip li add dummy0 type dummy
  # ip li set dummy0 up

Cheers
Dominic

[1] this test showed approximately 100 packages in the archive failing,
but nearly all of them were due to the behaviour of libio-socket-ip-perl,
so will be fixed centrally. I'm filing bugs about the small number of
unrelated cases.

Bug#963855: capnproto: FTBFS on IPv6-only environments

[Dominic Hargreaves]

Source: capnproto
Version: 0.7.0-6
Severity: serious
Justification: FTBFS (when it built before)

During archive-wide test rebuilding of an IPv6-only environment (which
appears on some normal buildds)[1] we noticed that this package fails:

  kj/async-io-test.c++:126: failed: expected ("1.2.3.4:80") == (tryParse(w, 
network, "1.2.3.4:http", 5678)); 1.2.3.4:80; tryParse(w, network, 
"1.2.3.4:http", 5678) = [:::1.2.3.4]:80
  stack: 55872da0b7fc 55872d9e5546 7f1351d2c60f 7f1351ccef9a 7f1351d2d7f5 
7f1351d2ea31 7f1351d035ba 7f1351ccef9a 7f1351d03c11 7f1351d2b59c 7f13518f5e0a 
55872d8438d9
  [ FAIL ] kj/async-io-test.c++:107: legacy test: AsyncIo/AddressParsing (71960 
μs)

The full log is available at 
http://perl.debian.net/rebuild-logs/sid-v6only/capnproto_0.7.0-6/capnproto_0.7.0-6_amd64-2020-06-28T02:01:53Z.build

One way to replicate this environment is like so:

  # unshare -n
  # ip li set lo up
  # ip li add dummy0 type dummy
  # ip li set dummy0 up

Cheers
Dominic

[1] this test showed approximately 100 packages in the archive failing,
but nearly all of them were due to the behaviour of libio-socket-ip-perl,
so will be fixed centrally. I'm filing bugs about the small number of
unrelated cases.

Bug#963853: clamav: FTBFS on IPv6-only environments

[Dominic Hargreaves]

Source: clamav
Version: 0.102.3+dfsg-1
Severity: serious
Justification: FTBFS (when it built before)

During archive-wide test rebuilding of an IPv6-only environment (which
appears on some normal buildds)[1] we noticed that this package fails:

  Sun Jun 28 05:38:28 2020 -> !TCP: getaddrinfo failed: Address family for 
hostname not supported
  Sun Jun 28 05:38:28 2020 -> *Closing the main socket.
  
  ***
  *** Failed to run /<>/unit_tests/../clamd/clamd -c 
test-clamd.conf, expected 0 exitcode, but was 1
  ***
  
  ***
  *** Failed to run clamd
  ***
  FAIL check4_clamd.sh (exit status: 42)

The full log is available at 
http://perl.debian.net/rebuild-logs/sid-v6only/clamav_0.102.3+dfsg-1/clamav_0.102.3+dfsg-1_amd64-2020-06-28T05:34:48Z.build

One way to replicate this environment is like so:

  # unshare -n
  # ip li set lo up
  # ip li add dummy0 type dummy
  # ip li set dummy0 up

Cheers
Dominic

[1] this test showed approximately 100 packages in the archive failing,
but nearly all of them were due to the behaviour of libio-socket-ip-perl,
so will be fixed centrally. I'm filing bugs about the small number of
unrelated cases.

Bug#963387: [request-tracker-maintainers] Bug#963387: Bug#963387: request-tracker4: FTBFS: CORE missing dependencies: Plack::Handler::Starlet ...MISSING

[Dominic Hargreaves]

On Mon, Jun 22, 2020 at 11:44:13PM +0100, Dominic Hargreaves wrote:
> Control: retitle -1 request-tracker4: FTBFS with newer libmojolicious-perl: 
> t/web/ticket_owner.t
> Control: tags -1 + confirmed
> 
> On Sun, Jun 21, 2020 at 10:34:37PM +0200, Lucas Nussbaum wrote:
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> > 
> > Relevant part (hopefully):
> 
> ...
> > > SOME DEPENDENCIES WERE MISSING.
> > > MAILGATE missing dependencies:
> > >   Mozilla::CA ...MISSING
> > > CORE missing dependencies:
> > >   Plack::Handler::Starlet ...MISSING
> > > 
> > > Perl library path for /usr/bin/perl:
> > > /etc/perl
> > > /usr/local/lib/x86_64-linux-gnu/perl/5.30.3
> > > /usr/local/share/perl/5.30.3
> > > /usr/lib/x86_64-linux-gnu/perl5/5.30
> > > /usr/share/perl5
> > > /usr/lib/x86_64-linux-gnu/perl-base
> > > /usr/lib/x86_64-linux-gnu/perl/5.30
> > > /usr/share/perl/5.30
> > > /usr/local/lib/site_perl
> > > make[1]: *** [Makefile:272: testdeps] Error 1
> 
> This was not the problem (the immediately following lines are):
> 
> make[1]: Leaving directory '/<>'
> make: [debian/rules:38: build-stamp] Error 2 (ignored)
> 
> > The full build log is available from:
> >
> > http://qa-logs.debian.net/2020/06/20/request-tracker4_4.4.4-1_unstable.log
> 
> The actual error is:
> 
> Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.
> Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.
> 
> #   Failed test 'no warnings'
> #   at /usr/share/perl/5.30/Test/Builder.pm line 152.
> # There were 1 warning(s)
> #   Previous test 95 'Ticket -> Reply'
> #   Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.
> #  at /usr/share/perl5/Log/Dispatch/Perl.pm line 86.
> #   Log::Dispatch::Perl::__ANON__("Not an ARRAY reference at 
> /usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at 
> /usr/share/perl5/Log/Dispatch/Output.pm line 64
> #   
> Log::Dispatch::Output::_log_with_num(Log::Dispatch::Perl=HASH(0x55e04f914d00),
>  5, "message", "Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm 
> li"..., "level", "critical") called at /usr/share/perl5/Log/Dispatch.pm line 
> 170
> #   Log::Dispatch::_log_with_num(Log::Dispatch=HASH(0x55e04f8d43b8), 5, 
> "level", "critical", "message", "Not an ARRAY reference at 
> /usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at 
> /usr/share/perl5/Log/Dispatch.pm line 25
> #   Log::Dispatch::__ANON__(Log::Dispatch=HASH(0x55e04f8d43b8), "Not an ARRAY 
> reference at /usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at 
> /<>/lib/RT.pm line 408
> #   RT::__ANON__("Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm 
> li"...) called at /usr/share/perl5/Mojo/DOM/CSS.pm line 237
> #   Mojo::DOM::CSS::_pc(qr((?:^|:)class$)u, 
> qr((?:^|\s+)transaction(?:\s+|$))u, ARRAY(0x55e050a066e0), 
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at 
> /usr/share/perl5/Mojo/DOM/CSS.pm line 291
> #   Mojo::DOM::CSS::_selector(ARRAY(0x55e0510b0c78), ARRAY(0x55e050a066e0), 
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at 
> /usr/share/perl5/Mojo/DOM/CSS.pm line 61
> #   Mojo::DOM::CSS::_combinator(ARRAY(0x55e0510b2a70), ARRAY(0x55e050a066e0), 
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 2) called at 
> /usr/share/perl5/Mojo/DOM/CSS.pm line 34
> #   Mojo::DOM::CSS::_ancestor(ARRAY(0x55e0510b2a70), ARRAY(0x55e0510a9cc0), 
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 0, 2) called at 
> /usr/share/perl5/Mojo/DOM/CSS.pm line 75
> #   Mojo::DOM::CSS::_combinator(ARRAY(0x55e0510b2a70), ARRAY(0x55e0510a9cc0), 
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 0) called at 
> /usr/share/perl5/Mojo/DOM/CSS.pm line 172
> #   Mojo::DOM::CSS::_match(ARRAY(0x55e0510b2038), ARRAY(0x55e0510a9cc0), 
> ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at 
> /usr/share/perl5/Mojo/DOM/CSS.pm line 266
> #   Mojo::DOM::CSS::_select(1, ARRAY(0x55e050a066e0), ARRAY(0x55e0510b2038)) 
> called at /usr/share/perl5/Mojo/DOM/CSS.pm line 26
> #   Mojo::DOM::CSS::select_one(Mojo::DOM::CSS=HASH(0x55e0510b0c00), 
> ".transaction.people .description") called at /usr/share/perl5/Mojo/DOM.pm 
> line 27
> #   Mojo::DOM::at(Mojo::DOM=REF(0x55e050aab360), ".transaction.people 
> .description") called at t/web/ticket_owner.t line 393
> # 
> # Some tests failed or we bailed out, tmp directory 
> '/<>/t/tmp/web-ticket_owner.t-pLaG9Zs3' is not cleaned
> # Tests were run but no plan was declared and done_testing() was not seen.
> # Looks like your test exited with 255 just after 98.
> t/web/ticket_owner.t ... 
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 1/98 subtests 
> 
> Almost certainly triggered by the recent uploads of libmojolicious-perl.
> It happens with both 8.55+dfsg-1 (sid) and 8.54+dfsg-1 (bullseye).

Confirmed it doesn't happen with 8.53. Forwarded upstream.

Bug#963387: [request-tracker-maintainers] Bug#963387: request-tracker4: FTBFS: CORE missing dependencies: Plack::Handler::Starlet ...MISSING

[Dominic Hargreaves]

Control: retitle -1 request-tracker4: FTBFS with newer libmojolicious-perl: 
t/web/ticket_owner.t
Control: tags -1 + confirmed

On Sun, Jun 21, 2020 at 10:34:37PM +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):

...
> > SOME DEPENDENCIES WERE MISSING.
> > MAILGATE missing dependencies:
> > Mozilla::CA ...MISSING
> > CORE missing dependencies:
> > Plack::Handler::Starlet ...MISSING
> > 
> > Perl library path for /usr/bin/perl:
> > /etc/perl
> > /usr/local/lib/x86_64-linux-gnu/perl/5.30.3
> > /usr/local/share/perl/5.30.3
> > /usr/lib/x86_64-linux-gnu/perl5/5.30
> > /usr/share/perl5
> > /usr/lib/x86_64-linux-gnu/perl-base
> > /usr/lib/x86_64-linux-gnu/perl/5.30
> > /usr/share/perl/5.30
> > /usr/local/lib/site_perl
> > make[1]: *** [Makefile:272: testdeps] Error 1

This was not the problem (the immediately following lines are):

make[1]: Leaving directory '/<>'
make: [debian/rules:38: build-stamp] Error 2 (ignored)

> The full build log is available from:
>http://qa-logs.debian.net/2020/06/20/request-tracker4_4.4.4-1_unstable.log

The actual error is:

Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.
Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.

#   Failed test 'no warnings'
#   at /usr/share/perl/5.30/Test/Builder.pm line 152.
# There were 1 warning(s)
#   Previous test 95 'Ticket -> Reply'
#   Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm line 237.
#  at /usr/share/perl5/Log/Dispatch/Perl.pm line 86.
#   Log::Dispatch::Perl::__ANON__("Not an ARRAY reference at 
/usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at 
/usr/share/perl5/Log/Dispatch/Output.pm line 64
#   
Log::Dispatch::Output::_log_with_num(Log::Dispatch::Perl=HASH(0x55e04f914d00), 
5, "message", "Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm 
li"..., "level", "critical") called at /usr/share/perl5/Log/Dispatch.pm line 170
#   Log::Dispatch::_log_with_num(Log::Dispatch=HASH(0x55e04f8d43b8), 5, 
"level", "critical", "message", "Not an ARRAY reference at 
/usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at 
/usr/share/perl5/Log/Dispatch.pm line 25
#   Log::Dispatch::__ANON__(Log::Dispatch=HASH(0x55e04f8d43b8), "Not an ARRAY 
reference at /usr/share/perl5/Mojo/DOM/CSS.pm li"...) called at 
/<>/lib/RT.pm line 408
#   RT::__ANON__("Not an ARRAY reference at /usr/share/perl5/Mojo/DOM/CSS.pm 
li"...) called at /usr/share/perl5/Mojo/DOM/CSS.pm line 237
#   Mojo::DOM::CSS::_pc(qr((?:^|:)class$)u, qr((?:^|\s+)transaction(?:\s+|$))u, 
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at 
/usr/share/perl5/Mojo/DOM/CSS.pm line 291
#   Mojo::DOM::CSS::_selector(ARRAY(0x55e0510b0c78), ARRAY(0x55e050a066e0), 
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at 
/usr/share/perl5/Mojo/DOM/CSS.pm line 61
#   Mojo::DOM::CSS::_combinator(ARRAY(0x55e0510b2a70), ARRAY(0x55e050a066e0), 
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 2) called at 
/usr/share/perl5/Mojo/DOM/CSS.pm line 34
#   Mojo::DOM::CSS::_ancestor(ARRAY(0x55e0510b2a70), ARRAY(0x55e0510a9cc0), 
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 0, 2) called at 
/usr/share/perl5/Mojo/DOM/CSS.pm line 75
#   Mojo::DOM::CSS::_combinator(ARRAY(0x55e0510b2a70), ARRAY(0x55e0510a9cc0), 
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0), 0) called at 
/usr/share/perl5/Mojo/DOM/CSS.pm line 172
#   Mojo::DOM::CSS::_match(ARRAY(0x55e0510b2038), ARRAY(0x55e0510a9cc0), 
ARRAY(0x55e050a066e0), ARRAY(0x55e050a066e0)) called at 
/usr/share/perl5/Mojo/DOM/CSS.pm line 266
#   Mojo::DOM::CSS::_select(1, ARRAY(0x55e050a066e0), ARRAY(0x55e0510b2038)) 
called at /usr/share/perl5/Mojo/DOM/CSS.pm line 26
#   Mojo::DOM::CSS::select_one(Mojo::DOM::CSS=HASH(0x55e0510b0c00), 
".transaction.people .description") called at /usr/share/perl5/Mojo/DOM.pm line 
27
#   Mojo::DOM::at(Mojo::DOM=REF(0x55e050aab360), ".transaction.people 
.description") called at t/web/ticket_owner.t line 393
# 
# Some tests failed or we bailed out, tmp directory 
'/<>/t/tmp/web-ticket_owner.t-pLaG9Zs3' is not cleaned
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 98.
t/web/ticket_owner.t ... 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/98 subtests 

Almost certainly triggered by the recent uploads of libmojolicious-perl.
It happens with both 8.55+dfsg-1 (sid) and 8.54+dfsg-1 (bullseye).

Bug#962138: perl-base: libperl5.30 version skew can break essential functionality

[Dominic Hargreaves]

On Wed, Jun 03, 2020 at 07:39:38PM +0300, Niko Tyni wrote:
> Package: perl-base
> Version: 5.30.2-1
> Severity: serious
> 
> Our Perl package dependencies and search path arrangements allow
> for a suitably versioned libperl5.30 package to break perl-base
> functionality. This is bad as perl-base is Essential:yes and is therefore
> required to stay functional at all times.
> 
> The specific version skew that triggers this is between minor upstream
> versions, so for instance 5.30.2-1 -> 5.30.3-1, which are the current
> version in testing and unstable.

> Minor upstream version upgrades in testing/unstable have been relatively
> rare in the past, and oldstable -> stable upgrades have always
> incorporated a major version bump since the 5.10 times (squeeze), when
> the dependencies and the package set were very different.

> I'm afraid this also means that a minor upstream version upgrade
> in stable has a higher risk of breaking things, so maybe we should
> reconsider #961443.

Agreed.
 
> I see two ways of fixing this (but happy to entertain other suggestions too).
> 
> A) Move /usr/lib//perl-base up on the @INC search path. This is
>shipped in perl-base and includes the parts of the standard library
>we consider part of Essential:yes functionality. It's currently last
>on @INC. The libperl5.30 and perl-modules-5.30 packages include copies
>of these files, shipped in /usr/{lib,share}//perl/5.30,
>so that they can be used "standalone" for different architectures or
>major versions. The position of these copies higher on @INC makes this
>bug possible.
> 
>IIRC I put /usr/lib//perl-base last because it's a nonstandard
>divergence from the upstream way of doing things, and I wanted it not
>to have an effect in the "normal" case when all the related packages
>are installed and configured. So it was only supposed to be a safeguard
>during upgrades and such. Clearly the safeguard is incomplete.
> 
> B) Do away with the /usr/{share,lib/x86_64-linux-gnu}/perl/5.30 -> 5.30.x
>symlinks currently shipped in libperl5.30 and perl-modules-5.30,
>and have the perl search path include the full upstream version. We
>tried this with the multiarch changes in 5.22 but reverted it with
>#787158 .  As I noted in that bug, this would mean that long running
>Perl programs could have @INC changed underneath them during version
>upgrades. This is not a showstopper by any means; we already have the
>'perl-major-upgrade' trigger for similar situations during major
>version upgrades, with at least some buy-in from packages like
>spamassassin IIRC.
> 
> I think A) is currently my preferred way of fixing this, and I think
> the upstream "divergence" issue it creates is not very important. I
> can envision some corner case regressions where standard library
> modules expect other modules to be in the same directory, but those
> seem improbable.
> 
> The main reason why I prefer option A is that it seems conceptually more
> correct (improving the standalone properties of perl-base). Also, option
> B may be harder to implement while keeping upgrade paths robust. But I
> haven't really thought this through yet.

Agreed, the upstream divergence seems like a very minor thing compared
to the advantage of a simpler, more predictable fix.

> On a brighter note, either of these options would close #798626 :)
> 
> Apologies for my verbosity and thanks for reading through; ideas and
> comments are naturally welcome. Despite the severity I don't think this
> is particularly urgent, except with the possibly implications for stable
> updates / #961443.

One reason to make this urgent is so that this issue doesn't occur when
5.30.3-1 transitions to testing in a couple of days. It doesn't sound
like the fix is especially hard, so it might be worth pushing through
if we can?

Cheers
Dominic

Bug#962047: marked as pending in libio-socket-ip-perl

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

Bug #962047 in libio-socket-ip-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libio-socket-ip-perl/-/commit/88f35f656944a4a6fa1afb231fbd36b2fa839170


Fix FTBFS with IPv6-only host (Closes: #962047)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/962047

Bug#961283: libhttp-tiny-perl: Don't release with bullseye

[Dominic Hargreaves]

Package: libhttp-tiny-perl
Version: 0.076-1
Severity: serious
Justification: maintainer

libhttp-tiny-perl at this version should not be released with
bullseye, since perl contains the same version.

Bug#944154: dehydrated: broken in oldstable: "JWS has no anti-replay nonce"

[Dominic Hargreaves]

On Tue, Nov 05, 2019 at 01:49:29PM +0100, Mattia Rizzolo wrote:
> On Tue, Nov 05, 2019 at 09:35:48AM +0000, Dominic Hargreaves wrote:
> > I understand that you probably won't fix this, but hopefully by filing
> > this we can raise awareness. Perhaps the package should be removed
> > altogether from oldstable?
> 
> I actually intend to fix this, but most likely the permanent fix will be
> a whole upgrade of dehydrated to the version that is currently in
> buster.

Brilliant, thanks! Not sure where I got the idea that you wouldn't
want to fix it then...

Cheers
Dominic

Bug#944154: dehydrated: broken in oldstable: "JWS has no anti-replay nonce"

[Dominic Hargreaves]

Package: dehydrated
Version: 0.3.1-3+deb9u2
Severity: grave
Justification: non-functional
Forwarded: https://github.com/lukas2511/dehydrated/issues/559

dehydrated in stretch suffers from the following issue due to upstream
API changes::

  + ERROR: An error occurred while sending post-request to 
https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 400)

Details:
{
  "type": "urn:acme:error:badNonce",
  "detail": "JWS has no anti-replay nonce",
  "status": 400
} 

I understand that you probably won't fix this, but hopefully by filing
this we can raise awareness. Perhaps the package should be removed
altogether from oldstable?

As a workaround, I was able to temporarily add the buster repo to my
system and install dehydrated from there without any additional
depenendencies being pulled in.

Thanks for your work in maintaining this important package!

Cheers
Dominic

Bug#940230: Downgrading

[Dominic Hargreaves]

Control: severity -1 important

Since this only happens under specific circumstances, I'm downgrading
this. I have now received example configuration from Julien, so 
will look at this soon to try and pin down the problem.

Bug#941917: Ping? nginx and the perl transition

[Dominic Hargreaves]

Hello nginx maintainers.

Please would you be able to look at this bug soon? I believe It's
currently the main thing preventing the perl transition from completing.

If not, I can try and look at it, but it might not be before the weekend
and it would be good if the transition was completed by then.

Thanks!
Dominic

Bug#940230: ircd-hybrid: use after free and crash

[Dominic Hargreaves]

Control: tags -1 + moreinfo

On Sat, Sep 14, 2019 at 11:54:53AM +0200, Julien Cristau wrote:
> Package: ircd-hybrid
> Version: 1:8.2.24+dfsg.1-1
> Severity: grave
> 
> Hi,
> 
> I just upgraded to buster and ircd keeps crashing.
> One case with a segfault in strcmp, other times with glibc aborts.

Does this happen with a default config file? If not, could you share your
configuration? (feel free to email it to me privately if you don't want
it to be public).

And although I suspect it's not the same problem, could you check whether
you have a dhparam.pem file created where your config file refers to it?
See 

Cheers,
Dominic.

Bug#919059: ensymble: Time to retire

[Dominic Hargreaves]

On Thu, Jul 25, 2019 at 11:39:43PM +0200, Moritz Mühlenhoff wrote:
> On Sat, Jan 12, 2019 at 12:12:46PM +0000, Dominic Hargreaves wrote:
> > Source: ensymble
> > Version: 0.29-1
> > Severity: serious
> > Justification: maintainer
> > 
> > I'm going to hazard a guess and say that there is absolutely nobody
> > using this in Debian. Certainly popcon indicates that way. As far as
> > I can see there is no active development upstream since 2010 and now
> > active VCS (it's on Google Code archive).
> > 
> > Whilst the package might still work, I have no easy way to test this.
> > 
> > So let's not release it any more. If anyone reading this disagrees,
> > let me know! 
> 
> Noone stepped forward for half a year, seems safe to remove it, it appears.

Good point, RM filed.

Bug#907974: Please add the "perl-doc-html" package to Debian 10.

[Dominic Hargreaves]

On Thu, Jul 25, 2019 at 10:58:15PM -0600, MyMail5 wrote:
> Dear Maintainer,
> Please add the "perl-doc-html" package to Debian 10.

Hello,

Unfortunately the perl-doc-html maintainer orphaned the package last year
so it was removed so that it didn't reflect the wrong version of perl
shipped in that release.

It won't be possible (even if there was the will from someone)
to add it back to Debian 10 after the fact due to Debian's release
policies. There are some ideas about how to get it back into Debian in
 and
 so if someone
wanted to work on that it could be restored for Debian 11.

Since I last looked at this it appears there has been some work in
revitalising perldoc.perl.org which had itself fallen into unmaintained
mode if I recall.

If anyone would be interested in working on this please ping me so we
can discuss if/how it should be integrated into the perl packages.

Cheers,
Dominic.

Bug#903124: marked as pending in libevent-rpc-perl

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

Bug #903124 in libevent-rpc-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libevent-rpc-perl/commit/dc71f12bcbb059e274583a9b2dcb389a78e28adb


Fix FTBFS due to expired test SSL certificates (Closes: #903124)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/903124

Bug#912682: e: Bug#912682: usefulness of this package?

[Dominic Hargreaves]

On Fri, Dec 14, 2018 at 03:00:10AM +0100, gregor herrmann wrote:
> On Thu, 13 Dec 2018 21:25:58 +0000, Dominic Hargreaves wrote:
> 
> > > Ok but I don't see how this bug differs from #915550 and #915876 for both
> > > of which the intent seems to remove the corresponding packages.
> > > 
> > > Shouldn't this package also be considered for removal?
> > 
> > Perhaps. We usually leave it a while in case it is upgraded, as the cost
> > of having around for "a while" in unstable only is judged cheaper than
> > the extra work needed to remove it and then reintroduce it. I think this
> > is mostly a matter of personal opinion and we don't have a firm policy
> > on this, but I'm sure other list members will correct me if I'm wrong.
> 
> This matches my impression of our habits as well.
> 
> I'd just like to add that the "maintenance cost" can be zero (no
> releases, no bugs, no nothing) or can be high (e.g. breakage with
> each new perl release) or anything in between. And our habit seems to
> be that if there's no or hardly any work needed there's also no
> particular need to trigger the removal steps.

Per our new policy[1], we'll remove this after July if no new
upstream update appears.

[1] <https://perl-team.pages.debian.net/policy.html#Dual-lived_Modules>

Bug#920744: Bug #920744 in request-tracker4 marked as pending

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

Bug #920744 in request-tracker4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/request-tracker-team/request-tracker4/commit/6ce499183eeff24d753a12e7ea57d2b4cb5c552d


Add missing dependencies on libcpanel-json-xs-perl (Closes: #920744)

I think missing this out from the previous commit was probably deliberate,
but based on flawed logic. It is safe and necessary to declare this
dependency to reflect the fact we are invoking it by name.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/920744

Bug#920744: Bug #920744 in request-tracker4 marked as pending

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

Bug #920744 in request-tracker4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/request-tracker-team/request-tracker4/commit/97ed2abbbdaf8d4da26616690cd554b109556ec6


Add missing dependencies on libcpanel-json-xs-perl (Closes: #920744)

I think missing this out from the previous commit was probably deliberate,
but based on flawed logic. It is safe and necessary to declare this
dependency to reflect the fact we are invoking it by name.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/920744

Bug#919059: ensymble: Time to retire

[Dominic Hargreaves]

Source: ensymble
Version: 0.29-1
Severity: serious
Justification: maintainer

I'm going to hazard a guess and say that there is absolutely nobody
using this in Debian. Certainly popcon indicates that way. As far as
I can see there is no active development upstream since 2010 and now
active VCS (it's on Google Code archive).

Whilst the package might still work, I have no easy way to test this.

So let's not release it any more. If anyone reading this disagrees,
let me know! 

Cheers,
Dominic.

Bug#907974: perl-doc-html: Should be updated to 5.28 at the point of the transition

[Dominic Hargreaves]

On Mon, Nov 05, 2018 at 08:54:13PM +0200, Niko Tyni wrote:
> Control: severity -1 serious
> 
> On Tue, Sep 04, 2018 at 05:40:41PM +0100, Dominic Hargreaves wrote:
> > Source: perl-doc-html
> > Version: 5.26.0-4
> > Severity: wishlist
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.28-transition
> > X-Debbugs-Cc: p...@packages.debian.org
> > 
> > We should make this bug serious at the point of the 5.28 transition
> > so that we don't end up releasing with documentation for the wrong 
> > version of perl.
> > 
> > See #907273 and #154963 for additional context.
> 
> Perl 5.28 transition is done now, so raising the severity of this bug.

I'm not sure where the original tooling for perldoc.perl.org has gone,
but it seems like it might not be the best option these days.

Possible alternative source:

https://perldoc.pl/
https://github.com/Grinnz/perldoc-browser
https://metacpan.org/pod/Mojolicious::Command::export

Bug#912682: e: Bug#912682: usefulness of this package?

[Dominic Hargreaves]

On Wed, Dec 12, 2018 at 10:43:17AM +0100, Cyrille Bollu wrote:
> On Tue, 11 Dec 2018 15:13:11 +0000 Dominic Hargreaves  wrote:
> > On Tue, Dec 11, 2018 at 10:06:45AM +0100, Cyrille Bollu wrote:
> > > From its debian/control file:
> > >
> > > >This module is already included as part of Perl's core distribution, so
> > > this
> > > > package is only beneficial when newer features or bug fixes are
> required.
> > >
> > > I don't understand how
> >
> > The perl package provides the same package via a Provides entry:
> > libextutils-parsexs-perl (= 3.39). This is newer than the version
> > in the separate package (against which this bug is filed) so this
> > package will never be selected for installation.
> >
> > This could change if a newer version is uploaded, but until then,
> > the separate package should not be released.
> >
> > Dominic.
> >
> 
> Ok but I don't see how this bug differs from #915550 and #915876 for both
> of which the intent seems to remove the corresponding packages.
> 
> Shouldn't this package also be considered for removal?

Perhaps. We usually leave it a while in case it is upgraded, as the cost
of having around for "a while" in unstable only is judged cheaper than
the extra work needed to remove it and then reintroduce it. I think this
is mostly a matter of personal opinion and we don't have a firm policy
on this, but I'm sure other list members will correct me if I'm wrong.

Dominic.

Bug#912682: usefulness of this package?

[Dominic Hargreaves]

On Tue, Dec 11, 2018 at 10:06:45AM +0100, Cyrille Bollu wrote:
> From its debian/control file:
> 
> >This module is already included as part of Perl's core distribution, so
> this
> > package is only beneficial when newer features or bug fixes are required.
> 
> I don't understand how

The perl package provides the same package via a Provides entry:
libextutils-parsexs-perl (= 3.39). This is newer than the version
in the separate package (against which this bug is filed) so this 
package will never be selected for installation.

This could change if a newer version is uploaded, but until then,
the separate package should not be released.

Dominic.

Bug#915550: libautodie-perl: superseded by perl

[Dominic Hargreaves]

On Tue, Dec 04, 2018 at 07:52:19PM +0200, Niko Tyni wrote:
> Package: libautodie-perl
> Version: 2.29-2
> Severity: serious
> 
> This is a separately packaged version of a module that
> is also bundled with Perl core.
> 
> The last upstream release of autodie was over three years ago, despite
> the rather serious bug in it (#798096). I don't think there's any value
> in releasing buster with this as a separate package.

Okay, so any reason not to just request an RM now?

Cheers,
Dominic.

Bug#915096: libperl-apireference-perl: Missing support for perl 5.28.1

[Dominic Hargreaves]

Source: libperl-apireference-perl
Version: 0.22-9
Severity: grave
Justification: ftbfs

This package needs an update for perl 5.28.1, which was uploaded to
unstable yesterday.

Bug#915086: libcommon-sense-perl: not installable with perl 5.28.1-1

[Dominic Hargreaves]

affects 915052 libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl 
libcommon-sense-perl
thanks

On Fri, Nov 30, 2018 at 10:53:18AM +0100, Vincent Lefevre wrote:
> On 2018-11-30 09:45:52 +0000, Dominic Hargreaves wrote:
> > On Fri, Nov 30, 2018 at 10:01:25AM +0100, Vincent Lefevre wrote:
> > > libcommon-sense-perl 3.74-2+b6 has
> > > 
> > >   Depends: perl (>= 5.28.0~), perlapi-5.28.0, perl (<< 5.28.1~)
> > > 
> > > thus is not installable with perl 5.28.1-1.
> > 
> > A binNMU has already been requested:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915052
> 
> Thanks. I'm wondering whether an "affects" should have been added on
> the concerned packages to make this bug visible on their bug pages
> and with reportbug.

Fair point, done.

Bug#915086: libcommon-sense-perl: not installable with perl 5.28.1-1

[Dominic Hargreaves]

On Fri, Nov 30, 2018 at 10:01:25AM +0100, Vincent Lefevre wrote:
> Package: libcommon-sense-perl
> Version: 3.74-2+b6
> Severity: grave
> Justification: renders package unusable
> 
> libcommon-sense-perl 3.74-2+b6 has
> 
>   Depends: perl (>= 5.28.0~), perlapi-5.28.0, perl (<< 5.28.1~)
> 
> thus is not installable with perl 5.28.1-1.

A binNMU has already been requested:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915052

Bug#912682: libextutils-parsexs-perl: version is older than Replaces+Breaks in perl-modules-5.28

[Dominic Hargreaves]

On Fri, Nov 02, 2018 at 09:57:57PM +0200, Adrian Bunk wrote:
> Package: libextutils-parsexs-perl
> Version: 3.35-1
> Severity: serious
> 
> The following packages have unmet dependencies:
>  perl-modules-5.28 : Breaks: libextutils-parsexs-perl (< 3.39)

For the avoidance of doubt: this does not require any action beyond
monitoring the situation, and eventually removing libextutils-parsexs-perl
from Debian if there are no newer versions that would be useful to package.

Bug#900853: [request-tracker-maintainers] Bug#900853: [request-tracker4] FTBFS: missing fonts in ckeditor

[Dominic Hargreaves]

Control: severity -1 normal
Control: tags -1 + moreinfo

On Wed, Jun 06, 2018 at 12:01:59AM +0200, Bastien ROUCARIÈS wrote:
> Package: request-tracker4
> Severity: serious
> 
> Hi,
> 
> third-party-source/devel/third-party/ckeditor-4.5.3/samples/toolbarconfigurator/font/fontello*
> 
> Does not build from source
> 
> Time to use ckeditor package ?
> 
> Will upload this font ASAP

I don't understand this bug report, please could you
clarify what you think the problem is? The file you referred to is not
used in the package build.

We don't use the ckeditor package because of compatibility concerns.

Dominic.

Bug#899021: libembperl-perl: FTBFS with Perl 5.27, unmaintained upstream

[Dominic Hargreaves]

On Sun, May 20, 2018 at 10:17:43AM +0200, Dominique Dumont wrote:
> On Friday, 18 May 2018 17:08:38 CEST Dominic Hargreaves wrote:
> > Currently the package has a popcon of inst: 37 / vote: 22 / recent: 1
> > suggesting that it is barely used anywhere. 
> 
> Reading its features, I think this module may have been a good idea when it 
> was created back in 1997, but I'm afraid it's now completely obsoleted by 
> modern JavaScript frameworks.  
> 
> > So I suggest that rather than
> > spending any more time maintaining it, we remove it from Debian.
> 
> Agreed.

I asked the Embperl mailing list about this, and although noone
who actually uses the Embperl Debian packages spoke up, there was
definitely some interest in keeping it alive. I have hopefully reflected
the views of pkg-perl here:

http://mail-archives.apache.org/mod_mbox/perl-embperl/201805.mbox/browser

Cheers,
Dominic.

Bug#899129: prime-phylo: FTBFS: cd obj-x86_64-linux-gnu && make -j8 -Oline returned exit code 2

[Dominic Hargreaves]

On Sun, May 20, 2018 at 10:11:58AM +0300, Juhani Numminen wrote:
> Control: tags -1 moreinfo
> 
> On Sat, 19 May 2018 18:01:53 +0200 Dominic Hargreaves <d...@earth.li> wrote:
> 
> > When testing packages against the upcoming release of perl, we found
> > an unrelated FTBFS on a clean sid chroot:
> > 
> > cd /<>/obj-x86_64-linux-gnu/src/cxx/libraries/prime && 
> > /usr/bin/c++  -DONLY_ONE_TIMESAMPLE -DPERTURBED_NODE -Dprime_phylo_EXPORTS 
> > -I/<>/obj-x86_64-linux-gnu/src/cxx/libraries/prime 
> > -I/<>/src/cxx/libraries/prime 
> > -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
> > -I/usr/lib/x86_64-linux-gnu/openmpi/include 
> > -I/usr/lib/x86_64-linux-gnu/openmpi/include/ompi/mpi/cxx 
> > -I/usr/include/libxml2 -I/<>/src/cxx/libraries 
> > -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/ompi/mpi/cxx 
> > -I/usr/lib/openmpi/include/openmpi/ompi/mpi/cxx  -g -O2 
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wreorder -Wall 
> > -fexceptions -g -fPIC   -std=gnu++98 -o 
> > CMakeFiles/prime-phylo.dir/TreeIO.cc.o -c 
> > /<>/src/cxx/libraries/prime/TreeIO.cc
> > make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> > make[2]: *** [CMakeFiles/Makefile2:137: 
> > src/cxx/libraries/prime/CMakeFiles/prime-phylo.dir/all] Error 2
> > make[1]: *** [Makefile:155: all] Error 2
> > dh_auto_build: cd obj-x86_64-linux-gnu && make -j8 -Oline returned exit 
> > code 2
> > make: *** [debian/rules:10: build] Error 25
> 
> Hi,
> 
> do you have the whole build log? Any lines containing "error:" might be 
> relevant,
> even if they were in the middle of the log :-) 
> 
> If there's something like
> > /PrimeOptionMap.hh:162:33: error:  should have been declared inside 
> > 'beep'
> the issue might be the same as #897837.

Apologies, here's the full build log.

Cheers,
Dominic.


prime-phylo_1.0.11-4_amd64-2018-05-19T15:09:31Z.build.gz
Description: application/gzip

Bug#899130: stunnel4: FTBFS: tests failing returned exit code 2

[Dominic Hargreaves]

Source: stunnel4
Version: 3:5.44-1
Severity: serious
Justification: FTBFS
User: debian-p...@lists.debian.org
Usertags: hh2018

When testing packages against the upcoming release of perl, we found
an unrelated FTBFS on a clean sid chroot:

./make_test
Sat May 19 16:06:30 UTC 2018
stunnel 5.44 on x86_64-pc-linux-gnu platform
Compiled/running with OpenSSL 1.1.0h  27 Mar 2018
Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI 
Auth:LIBWRAP
 
test 010_require_cert   configuration failed
error logs  logs/010_require_cert.log
test 011_verify_peerconfiguration failed
error logs  logs/011_verify_peer.log
test 012_verify_chain   configuration failed
error logs  logs/012_verify_chain.log
test 013_CRL_file   configuration failed
error logs  logs/013_CRL_file.log
test 014_PSK_secretsconfiguration failed
error logs  logs/014_PSK_secrets.log
test 015_p12_cert   configuration failed
error logs  logs/015_p12_cert.log
/<>/tests/recipes/020_IPv6: 24: 
/<>/tests/recipes/020_IPv6: ifconfig: not found
test 020_IPv6   skipped
test 021_FIPS   skipped
test 030_simple_execute configuration failed
error logs  logs/030_simple_execute.log
test 031_redirect   configuration failed
error logs  logs/031_redirect.log
test 032_no_redirectconfiguration failed
error logs  logs/032_no_redirect.log
test 033_redirect_exec  configuration failed
error logs  logs/033_redirect_exec.log
test 034_no_redirect_exec   configuration failed
error logs  logs/034_no_redirect_exec.log
test 035_SNIconfiguration failed
error logs  logs/035_SNI.log
test 036_no_SNI configuration failed
error logs  logs/036_no_SNI.log
test 037_failover_prio1 configuration failed
error logs  logs/037_failover_prio1.log
test 038_failover_prio2 configuration failed
error logs  logs/038_failover_prio2.log
test 039_failover_rrconfiguration failed
error logs  logs/039_failover_rr.log
HTTP/1.1 400 Unknown Version

Content-Type: text/html;charset=iso-8859-1

Content-Length: 58

Connection: close

Server: Jetty(9.4.z-SNAPSHOT)



Bad Message 400reason: Unknown Versiontest 040_reload   
failed
error logs  logs/040_reload.log
test 110_failure_require_cert   ok
test 111_failure_verify_peerok
test 112_failure_verify_chain   ok
test 113_failure_CRL_file   ok
test 114_failure_PSK_secretsok
test 120_failure_no_certok
test 121_failure_wrong_config   ok
summary: success 7, skip 2, fail 17
./make_test finished
make[3]: *** [Makefile:447: check-local] Error 1

Bug#899129: prime-phylo: FTBFS: cd obj-x86_64-linux-gnu && make -j8 -Oline returned exit code 2

[Dominic Hargreaves]

Source: prime-phylo
Version: 1.0.11-4
Severity: serious
Justification: FTBFS
User: debian-p...@lists.debian.org
Usertags: hh2018

When testing packages against the upcoming release of perl, we found
an unrelated FTBFS on a clean sid chroot:

cd /<>/obj-x86_64-linux-gnu/src/cxx/libraries/prime && 
/usr/bin/c++  -DONLY_ONE_TIMESAMPLE -DPERTURBED_NODE -Dprime_phylo_EXPORTS 
-I/<>/obj-x86_64-linux-gnu/src/cxx/libraries/prime 
-I/<>/src/cxx/libraries/prime 
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
-I/usr/lib/x86_64-linux-gnu/openmpi/include 
-I/usr/lib/x86_64-linux-gnu/openmpi/include/ompi/mpi/cxx -I/usr/include/libxml2 
-I/<>/src/cxx/libraries 
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/ompi/mpi/cxx 
-I/usr/lib/openmpi/include/openmpi/ompi/mpi/cxx  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wreorder -Wall 
-fexceptions -g -fPIC   -std=gnu++98 -o CMakeFiles/prime-phylo.dir/TreeIO.cc.o 
-c /<>/src/cxx/libraries/prime/TreeIO.cc
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:137: 
src/cxx/libraries/prime/CMakeFiles/prime-phylo.dir/all] Error 2
make[1]: *** [Makefile:155: all] Error 2
dh_auto_build: cd obj-x86_64-linux-gnu && make -j8 -Oline returned exit code 2
make: *** [debian/rules:10: build] Error 25

Bug#899126: openjpeg2: FTBFS: cd obj-x86_64-linux-gnu && make -j8 -Oline returned exit code 2

[Dominic Hargreaves]

Source: openjpeg2
Version: 2.3.0-1
Severity: serious
Justification: FTBFS
User: debian-p...@lists.debian.org
Usertags: hh2018

When testing packages against the upcoming release of perl, we found
an unrelated FTBFS on a clean sid chroot:

/usr/bin/ar qc ../../../bin/libopenjp2.a  
CMakeFiles/openjp2_static.dir/thread.c.o CMakeFiles/openjp2_static.dir/bio.c.o 
CMakeFiles/openjp2_static.dir/cio.c.o CMakeFiles/openjp2_static.dir/dwt.c.o 
CMakeFiles/openjp2_static.dir/event.c.o CMakeFiles/openjp2_static.dir/image.c.o 
CMakeFiles/openjp2_static.dir/invert.c.o CMakeFiles/openjp2_static.dir/j2k.c.o 
CMakeFiles/openjp2_static.dir/jp2.c.o CMakeFiles/openjp2_static.dir/mct.c.o 
CMakeFiles/openjp2_static.dir/mqc.c.o 
CMakeFiles/openjp2_static.dir/openjpeg.c.o 
CMakeFiles/openjp2_static.dir/opj_clock.c.o 
CMakeFiles/openjp2_static.dir/pi.c.o CMakeFiles/openjp2_static.dir/t1.c.o 
CMakeFiles/openjp2_static.dir/t2.c.o CMakeFiles/openjp2_static.dir/tcd.c.o 
CMakeFiles/openjp2_static.dir/tgt.c.o 
CMakeFiles/openjp2_static.dir/function_list.c.o 
CMakeFiles/openjp2_static.dir/opj_malloc.c.o 
CMakeFiles/openjp2_static.dir/sparse_array.c.o 
CMakeFiles/openjp2_static.dir/cidx_manager.c.o 
CMakeFiles/openjp2_static.dir/phix_manager.c.o 
CMakeFiles/openjp2_static.dir/ppix_manager.c.o 
CMakeFiles/openjp2_static.dir/thix_manager.c.o 
CMakeFiles/openjp2_static.dir/tpix_manager.c.o
/usr/bin/ranlib ../../../bin/libopenjp2.a
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: Entering directory '/<>/obj-x86_64-linux-gnu'
[ 57%] Built target openjp2_static
make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[1]: *** [Makefile:155: all] Error 2
dh_auto_build: cd obj-x86_64-linux-gnu && make -j8 -Oline returned exit code 2
make: *** [debian/rules:10: build] Error 25

The full log is here:



This seems to be a separate problem to #873997 which is related to
Java.

Bug#899123: nuxwdog: FTBFS: javah missing with openjdk-10

[Dominic Hargreaves]

Source: nuxwdog
Version: 1.0.3-4
Severity: serious
Justification: FTBFS
User: debian-p...@lists.debian.org
Usertags: hh2018

When testing packages against the upcoming release of perl, we found
an unrelated FTBFS on a clean sid chroot:

BUILD FAILED
/<>/build.xml:85: Execute failed: java.io.IOException: Cannot run 
program "javah" (in directory "/<>"): error=2, No such file or 
directory
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1128)
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
at java.base/java.lang.Runtime.exec(Runtime.java:635)
[...]

This seems to be due to switching to openjdk-10, which does not include
javah.

Bug#899021: libembperl-perl: FTBFS with Perl 5.27, unmaintained upstream

[Dominic Hargreaves]

Source: libembperl-perl
Version: 2.5.0-11
Severity: serious
Justification: unmaintained upstream, and will shortly break in Debian
X-Debbugs-Cc: debian-p...@lists.debian.org
User: debian-p...@lists.debian.org
Usertags: perl-5.28-transition hh2018

The upstream version of this package has not worked since 5.18, and we
have had to apply several fixes in Debian since. The build has now
broken again with Perl 5.27:

http://perl.debian.net/rebuild-logs/perl-5.27-throwaway/libembperl-perl_2.5.0-11/libembperl-perl_2.5.0-11_amd64-2018-05-18T08:09:28Z.build

The problem in this case might not be that hard to fix, but I have
been consisdering deprecating/removing this for some time, as there is
a limit to how long we can be de facto upstream for this type of
package.

Currently the package has a popcon of inst: 37 / vote: 22 / recent: 1
suggesting that it is barely used anywhere. So I suggest that rather than
spending any more time maintaining it, we remove it from Debian.

CC to debian-perl to get wider exposure of the proposal.

Cheers,
Dominic.

Bug#899019: getfem++ FTBFS: FAIL demo_laplacian.py

[Dominic Hargreaves]

Source: getfem++
Version: 5.2+dfsg1-6
Severity: serious
Justification: FTBFS

When testing packages against the upcoming release of perl, we found
an unrelated FTBFS on a clean sid chroot:

===
   getfem 5.2: interface/tests/python/test-suite.log
===

# TOTAL: 5
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: demo_laplacian.py
===

Traceback (most recent call last):
  File "./demo_laplacian.py", line 60, in 
fneum = np.compress(True - ttop - tleft, flst, axis=1)
TypeError: numpy boolean subtract, the `-` operator, is deprecated, use the 
bitwise_xor, the `^` operator, or the logical_xor function instead.
FAIL demo_laplacian.py (exit status: 1)

Bug#899008: breezy-debian: FTBFS: Unable to import library "dulwich"

[Dominic Hargreaves]

Source: breezy-debian
Version: 2.8.12
Severity: serious
Justification: FTBFS

When testing packages against the upcoming release of perl, we found
an unrelated FTBFS on a clean sid chroot:

10.863  opening working tree 
'/tmp/testbzr-Mq8mdV.tmp/breezy.plugins.debian.tests.test_upstream.UpstreamBranchSourceTests.test_version_as_revision_invalid_revspec/work'
}}}

Traceback (most recent call last):
  File "/<>/tests/test_upstream.py", line 465, in 
test_version_as_revision_invalid_revspec
source.version_as_revision, "foo", "2.1+bzr4242")
  File "/usr/lib/python2.7/dist-packages/breezy/tests/__init__.py", line 1468, 
in assertRaises
callableObj(*args, **kwargs)
  File "/<>/upstream/branch.py", line 245, in version_as_revision
revspec).as_revision_id(self.upstream_branch)
  File "/usr/lib/python2.7/dist-packages/breezy/revisionspec.py", line 226, in 
as_revision_id
return self._as_revision_id(context_branch)
  File "/usr/lib/python2.7/dist-packages/breezy/revisionspec.py", line 234, in 
_as_revision_id
return self.in_history(context_branch).rev_id
  File "/usr/lib/python2.7/dist-packages/breezy/revisionspec.py", line 208, in 
in_history
return self._match_on_and_check(branch, revs=None)
  File "/usr/lib/python2.7/dist-packages/breezy/revisionspec.py", line 196, in 
_match_on_and_check
info = self._match_on(branch, revs)
  File "/usr/lib/python2.7/dist-packages/breezy/revisionspec.py", line 313, in 
_match_on
return self._try_spectype(rs_class, branch)
  File "/usr/lib/python2.7/dist-packages/breezy/revisionspec.py", line 297, in 
_try_spectype
return rs.in_history(branch)
  File "/usr/lib/python2.7/dist-packages/breezy/revisionspec.py", line 208, in 
in_history
return self._match_on_and_check(branch, revs=None)
  File "/usr/lib/python2.7/dist-packages/breezy/revisionspec.py", line 196, in 
_match_on_and_check
info = self._match_on(branch, revs)
  File "/usr/lib/python2.7/dist-packages/breezy/plugins/git/revspec.py", line 
117, in _match_on
lazy_check_versions()
  File "/usr/lib/python2.7/dist-packages/breezy/plugins/git/__init__.py", line 
82, in lazy_check_versions
import_dulwich()
  File "/usr/lib/python2.7/dist-packages/breezy/plugins/git/__init__.py", line 
69, in import_dulwich
"bzr-git: Please install dulwich, https://www.dulwich.io/;)
breezy.errors.DependencyNotPresent: Unable to import library "dulwich": 
bzr-git: Please install dulwich, https://www.dulwich.io/

--
Ran 532 tests in 11.355s

FAILED (errors=1)
4 tests skipped

Bug#898964: mrs: FTBFS: you don't seem to have log4cpp installed

[Dominic Hargreaves]

Source: mrs
Version: 6.0.5+dfsg-5
Severity: serious

Whilst test-rebuilding packages for the next perl release we found
an unrelated build failure:

Checking for liblog4cpp...

Cannot continue since you don't seem to have log4cpp installed
Please install the log4cpp-dev package and run configure again.
make[1]: *** [debian/rules:11: override_dh_auto_configure] Error 2

The full log is here:



This seems likely to be caused by the new release of log4cpp 1.1.3-1
last week.

Cheers,
Dominic.

Bug#886494: polymake: Can't locate loadable object for module Polymake::Ext in @INC

[Dominic Hargreaves]

On Mon, Jan 08, 2018 at 10:40:19PM +0200, Niko Tyni wrote:
> On Sun, Jan 07, 2018 at 05:04:17PM +0200, Niko Tyni wrote:
> 
> > The wasted stats could certainly be fixed by modifying our relevant
> > changes to perl.c
> >  
> > https://sources.debian.org/src/perl/5.26.1-3/debian/patches/debian/mod_paths.diff/
> > but I haven't looked into that properly yet.
> 
> I did this now and pushed to the 'ntyni/inc-version-list'
> branch of the Debian perl git repository.
> 
> The relevant changes are
> 
>  
> https://anonscm.debian.org/cgit/perl/perl.git/diff/debian/patches/debian/mod_paths.diff?h=ntyni/inc-version-list=3885251398d6e2897fa57cafe61134e4e14593ac
> 
>  
> https://anonscm.debian.org/cgit/perl/perl.git/commit/?h=ntyni/inc-version-list=f8e4ea6058a58019e78a5c3225a6ab4a3d0c6700
> 
> A test build fixes the polymake issue and doesn't seem to break anything
> major.
> 
> I'm inclined to reassign this bug to perl and close it with the above
> change unless I hear arguments to the contrary.

This all looks well reasoned and sensible, thanks for digging into
that!

Cheers,
Dominic.

Bug#883673: fix build with libcdio 1.0

[Dominic Hargreaves]

On Wed, Dec 06, 2017 at 11:46:31AM +0100, Matthias Klose wrote:
> Package: src:libdevice-cdio-perl
> Version: 0.4.0-2
> Severity: serious
> Tags: sid buster patch
> 
> One driver is gone upstream.
> 
> patch at
> http://launchpadlibrarian.net/348274120/libdevice-cdio-perl_0.4.0-2build1_0.4.0-2ubuntu1.diff.gz

Hi Matthew,

I tried applying this patch (both to the Debian package and to upstream
git ready for forwarding) but I get the following build failures on sid:

./perlcdio_wrap.c: In function 'get_cdtext':
./perlcdio_wrap.c:2439:14: error: too many arguments to function 'cdio_get_cdtex
t'
 cdtext = cdio_get_cdtext (p_cdio, (track_t) track);
  ^~~
In file included from /usr/include/cdio/cdio.h:62:0,
 from ./perlcdio_wrap.c:1562:
/usr/include/cdio/disc.h:77:13: note: declared here
   cdtext_t *cdio_get_cdtext (CdIo_t *p_cdio);
 ^~~
./perlcdio_wrap.c:2448:29: warning: passing argument 1 of 'cdtext_get_const' 
makes pointer from integer without a cast [-Wint-conversion]
 if(cdtext_get_const(num,cdtext)) {
 ^~~
In file included from /usr/include/cdio/cdio.h:59:0,
 from ./perlcdio_wrap.c:1562:
/usr/include/cdio/cdtext.h:262:13: note: expected 'const cdtext_t * {aka const 
struct cdtext_s *}' but argument is of type 'int'
 const char *cdtext_get_const (const cdtext_t *p_cdtext, cdtext_field_t field,
 ^~~~
./perlcdio_wrap.c:2448:33: error: incompatible type for argument 2 of 
'cdtext_get_const'
 if(cdtext_get_const(num,cdtext)) {
 ^~

[...]

(full log attached).

Do you have any suggestions about how to resolve this?

Cheers,
Dominic.
sbuild (Debian sbuild) 0.73.0 (23 Dec 2016) on himalia.internal.semmle.com

+==+
| libdevice-cdio-perl 0.4.0-3 (amd64)  Wed, 06 Dec 2017 12:53:07 + |
+==+

Package: libdevice-cdio-perl
Version: 0.4.0-3
Source Version: 0.4.0-3
Distribution: sid
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/sid-amd64-sbuild-da6941f7-b7da-4f42-9d95-94af0fb241a3' 
with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://localhost:3142/debian sid InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/dom/working/debian/pkg-perl/libdevice-cdio-perl_0.4.0-3.dsc exists in 
/home/dom/working/debian/pkg-perl; copying to chroot
I: NOTICE: Log filtering will replace 
'build/libdevice-cdio-perl-3ngYLQ/libdevice-cdio-perl-0.4.0' with 
'<>'
I: NOTICE: Log filtering will replace 'build/libdevice-cdio-perl-3ngYLQ' with 
'<>'

+--+
| Install build-essential  |
+--+


Setup apt archive
-

Merged Build-Depends: build-essential, fakeroot
Filtered Build-Depends: build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-core-dummy' in 
'/<>/resolver-5QCaU6/apt_archive/sbuild-build-depends-core-dummy.deb'.
dpkg-scanpackages: warning: Packages in archive but missing from override file:
dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy
dpkg-scanpackages: info: Wrote 1 entries to output Packages file.
Ign:1 copy:/<>/resolver-5QCaU6/apt_archive ./ InRelease
Get:2 copy:/<>/resolver-5QCaU6/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/resolver-5QCaU6/apt_archive ./ Release.gpg
Get:4 copy:/<>/resolver-5QCaU6/apt_archive ./ Sources [349 B]
Get:5 copy:/<>/resolver-5QCaU6/apt_archive ./ Packages [432 B]
Fetched 1738 B in 0s (140 kB/s)
Reading package lists...
Reading package lists...

Install core build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  sbuild-build-depends-core-dummy
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 852 B of archives.
After this operation, 0 B of 

Bug#880528: wordpress: Unsafe queries with wpdb->prepare

[Dominic Hargreaves]

On Thu, Nov 02, 2017 at 06:40:04AM +1100, Craig Small wrote:
> Source: wordpress
> Version: 4.8.2+dfsg-2
> Severity: grave
> Tags: upstream security
> Justification: user security hole
> 
> WordPress versions 4.8.2 and earlier are affected by an issue where
> $wpdb->prepare() can create unexpected and unsafe queries leading to
> potential SQL injection (SQLi). WordPress core is not directly vulnerable
> to this issue, but we’ve added hardening to prevent plugins and themes from
> accidentally causing a vulnerability.

Hi Craig,

I noticed that this is still affected on stable; do you have an update
on that? (Then again, perhaps it is not a serious as all that as it's
"only" hardenening against already-vulnerable plugins.)

Cheers,
Dominic.

Bug#882648: exim4: remote code execution in chunking

[Dominic Hargreaves]

Package: exim4
Version: 4.89-9
Severity: grave
Tags: security
Justification: remote code execution

Source: https://lists.exim.org/lurker/message/20171125.034842.d1d75cac.en.html

- Forwarded message from Phil Pennock  -

Date: Fri, 24 Nov 2017 22:48:42 -0500
From: Phil Pennock 
To: exim-annou...@exim.org
Subject: [exim-announce] Critical Exim Security Vulnerability: disable chunking
Reply-To: exim-announce-ow...@exim.org

Folks,

A remote code execution vulnerability has been reported in Exim, with
immediate public disclosure (we were given no private notice).
A tentative patch exists but has not yet been confirmed.

With immediate effect, please apply this workaround: if you are running
Exim 4.88 or newer (4.89 is current, 4.90 is upcoming) then in the main
section of your Exim configuration, set:

  chunking_advertise_hosts =

That's an empty value, nothing on the right of the equals.  This
disables advertising the ESMTP CHUNKING extension, making the BDAT verb
unavailable and avoids letting an attacker apply the logic.

This should be a complete workaround.  Impact of applying the workaround
is that mail senders have to stick to the traditional DATA verb instead
of using BDAT.

We've requested CVEs.  More news will be forthcoming as we get this
worked out.

-Phil



-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-announce Exim 
details at http://www.exim.org/ ##


- End forwarded message -

Bug#762638: Update on DFSG-freeness of perl/Configure

[Dominic Hargreaves]

Hi Helmut et al,

At the Perl 5 hackathon in Amsterdam[1], Niko and I have been working
on Configure maintenance with several other core developers (including
H.Merijn Brand, who has been the lead/only maintainer of Configure for
some years). The conclusions of these discussions are threefold:

1) the previous assertion on this ticket that Configure was, de facto,
*a* preferred form of modification was a misunderstanding on our side.
I have updated the header for Configure, and the information in
Porting/pumpkin.pod, upstream. Hence this bug being reopened.

2) an understanding of the the current mechanism for updating Configure
upstream has been shared amongst several people, and the documentation
has been improved both in the perl source and in the separate metaconfig
repository, which is now on github[2]. It is now much easier for a new
contributor to start working on this process upstream (and PRs are
welcome there).

2a) There is renewed interest in looking at the dist tools itself,
with a view to modernizing them. I'm not sure if the type of cross-building
work you might be interested in would be better done there or not. 

2b) One issue is that we are still using many older version of units
from the upstream dist package, as well as the perl-specific units, but
over time this divergence is being reduced.

3) the Debian perl package is in the process of being updated to
regenerate Configure in the build process by adding (parts of) the
repository to the perl source package as a separate component. Although
the upstream metaconfig.git contains a generated version of the tools
from dist, we are using the already-packaged version of dist in Debian
for this and this doesn't (substantially) change Configure at the moment.

I'm therefore hopeful that this bug will be resolved in more satisfactory
way very soon, and that this might prove a useful basis for your porting
work.

Best wishes,
Dominic.

[1] thanks to the sponsors for this event, listed at http://p5h.org/
[2] 

Bug#875982: RM: obsolete with current Perl?

[Dominic Hargreaves]

On Sat, Sep 16, 2017 at 10:22:11PM +0200, Florian Schlichting wrote:
> Package: libsub-current-perl
> Version: 0.03-2
> Severity: serious
> Justification: obsolete with perl >= 5.16.0
> 
> libsub-current-perl 0.03 added a note to its POD explaining that from
> perl 5.16.0, the built-in __SUB__ can be used instead via the pragma
> 
> use feature 'current_sub';
> 
> libsub-current-perl has no reverse dependencies and an extremely low
> popcon (7 installs, 0 votes currently). It would appear that it is
> obsolete and can be removed from Debian.

Thanks, I'd suggest using this bug to keep it out of testing, and
if noone yells in a few months, requesting an RM.

Dominic.

Bug#874425: soapdenovo2: please Build-Depend on rename

[Dominic Hargreaves]

Source: soapdenovo2
Version: 240+dfsg1-2
Severity: serious
Justification: FTBFS with impending change
User: debian-p...@lists.debian.org
Usertags: rename-deprecation

As announced last year[1] and as advised by deprecation messages,
rename(1) will be removed from the perl package after the stretch
release, and this is now imminent.

Your package FTBFS with perl 5.26.0-7 (just uploaded to unstable) as
a result. Please add a Build-Depends: rename to your package, and all
will be well again:

cd debian/soapdenovo2/usr/bin/;rename 's/SOAPdenovo/soapdenovo2/' SOAP*
/bin/sh: 1: rename: not found
debian/rules:24: recipe for target 'override_dh_install' failed

Let me know if you would prefer an NMU to get this trivial change made. 

Cheers,
Dominic.

[1] 

Bug#874424: soapdenovo: please Build-Depend on rename

[Dominic Hargreaves]

Source: soapdenovo
Version: 1.05-3
Severity: serious
Justification: FTBFS with impending change
User: debian-p...@lists.debian.org
Usertags: rename-deprecation

As announced last year[1] and as advised by deprecation messages,
rename(1) will be removed from the perl package after the stretch
release, and this is now imminent.

Your package FTBFS with perl 5.26.0-7 (just uploaded to unstable) as
a result. Please add a Build-Depends: rename to your package, and all
will be well again:

cd debian/soapdenovo/usr/bin/;rename 's/SOAP/soap/' SOAP*
/bin/sh: 1: rename: not found
debian/rules:13: recipe for target 'override_dh_install' failed

Let me know if you would prefer an NMU to get this trivial change made. 

Cheers,
Dominic.

[1] 

Bug#874368: python-whisper: please Build-Depend on rename

[Dominic Hargreaves]

Source: python-whisper
Version: 0.9.15-1
Severity: serious
Justification: FTBFS with impending change
User: debian-p...@lists.debian.org
Usertags: rename-deprecation

As announced last year[1] and as advised by deprecation messages,
rename(1) will be removed from the perl package after the stretch
release, and this is now imminent.

Your package FTBFS with perl from experimental as a result. Please
add a Build-Depends: rename to your package, and all will be well
again:

   debian/rules override_dh_install
make[1]: Entering directory '/<>'
rename 's/\.py//' debian/python-whisper/usr/bin/*.py
/bin/sh: 1: rename: not found

Let me know if you would prefer an NMU to get this trivial change made. 

Cheers,
Dominic.

[1] 

Bug#874212: mediainfo: please Build-Depend on rename

[Dominic Hargreaves]

Source: mediainfo
Version: 0.7.98-1
Severity: serious
Justification: FTBFS with impending change
User: debian-p...@lists.debian.org
Usertags: rename-deprecation

As announced last year[1] and as advised by deprecation messages,
rename(1) will be removed from the perl package after the stretch
release, and this is now imminent.

Your package FTBFS with perl from experimental as a result. Please
add a Build-Depends: rename to your package, and all will be well
again:

find debian/mediainfo-gui   \
-name \*.desktop\
-exec prename 's/\.kde[34]\.desktop$/.desktop/' '{}' '+'
find: 'prename': No such file or directory
debian/rules:30: recipe for target 'override_dh_install' failed

Let me know if you would prefer an NMU to get this trivial change made. 

Cheers,
Dominic.

[1] 

Bug#874213: mercurial: please Build-Depend on rename

[Dominic Hargreaves]

Source: mercurial
Version: 4.3.1-3
Severity: serious
Justification: FTBFS with impending change
User: debian-p...@lists.debian.org
Usertags: rename-deprecation

As announced last year[1] and as advised by deprecation messages,
rename(1) will be removed from the perl package after the stretch
release, and this is now imminent.

Your package FTBFS with perl from experimental as a result. Please
add a Build-Depends: rename to your package, and all will be well
again:

Skipped test-debian-packages.t: missing feature: debian packaging tools
# Ran 564 tests, 57 skipped, 0 failed.
# Cleaning up HGTMP /tmp/hgtests.1d5pdA 
make[2]: Leaving directory '/<>'
rename 's/\.deb-backup$//' /<>/tests/*
/bin/sh: 1: rename: not found
debian/rules:46: recipe for target 'override_dh_auto_test' failed

Let me know if you would prefer an NMU to get this trivial change made. 

Cheers,
Dominic.

[1] 

Bug#874211: libxml2: please Build-Depend on rename

[Dominic Hargreaves]

Source: libxml2
Version: 2.9.4+dfsg1-3.1
Severity: serious
Justification: FTBFS with impending change
User: debian-p...@lists.debian.org
Usertags: rename-deprecation

As announced last year[1] and as advised by deprecation messages,
rename(1) will be removed from the perl package after the stretch
release, and this is now imminent.

Your package FTBFS with perl from experimental as a result. Please
add a Build-Depends: rename to your package, and all will be well
again:

make[2]: Leaving directory 
'/<>/libxml2-2.9.4+dfsg1/builddir/main/python2.7-dbg'
prename -vf 's/(?https://lists.debian.org/debian-devel/2016/05/msg00138.html>

Bug#825608: Remove libnet-jifty-perl?

[Dominic Hargreaves]

On Thu, Aug 31, 2017 at 02:00:23PM +0200, gregor herrmann wrote:
> On Thu, 31 Aug 2017 12:43:14 +0100, Dominic Hargreaves wrote:
> 
> > On Thu, Aug 31, 2017 at 12:40:40PM +0100, Dominic Hargreaves wrote:
> > > I noticed that that this bug has been tagged rm-candidate, and I'd like
> > > to support this. There has been no upstream activity on Jifty since 2011
> > > and Best Practical abandoned their plans to port RT to this framework
> > > (which was, IIRC, the original reason for its creation).
> > > 
> > Just to add: libnet-hiveminder-perl is an rdep (my previous checking
> > was broken). That is also abandoned by Best Practical (and is only
> > useful for talking to a now-closed down web service). So I would remove
> > that too.
> 
> Sounds good to me.

Thanks, I've filed RM bugs now: #874046 #874047.

Dominic.

Bug#874042: hmmer2: please Build-Depend on rename

[Dominic Hargreaves]

Source: hmmer2
Version: 2.3.2+dfsg-4
Severity: serious
Justification: FTBFS with impending change
User: debian-p...@lists.debian.org
Usertags: rename-deprecation

As announced last year[1] and as advised by deprecation messages,
rename(1) will be removed from the perl package after the stretch
release, and this is now imminent.

Your package FTBFS with perl from experimental as a result. Please
add a Build-Depends: rename to your package, and all will be well
again:

# lkajan: rename binaries and man pages like this: s/hmm/hmm2/ - except 
hmmer.1, rename that to hmmer2.1:
rename 's/^hmm/hmm2/;' /<>/hmmer2-2.3.2+dfsg/debian/tmp/bin/*
/bin/sh: 1: rename: not found
debian/rules:31: recipe for target 'override_dh_auto_install' failed

Cheers,
Dominic.

[1] 

Bug#874041: graphite-carbon: please Build-Depend on rename

[Dominic Hargreaves]

Source: graphite-carbon
Version: 0.9.15-1
Severity: serious
Justification: FTBFS with impending change
User: debian-p...@lists.debian.org
Usertags: rename-deprecation

As announced last year[1] and as advised by deprecation messages,
rename(1) will be removed from the perl package after the stretch
release, and this is now imminent.

Your package FTBFS with perl from experimental as a result. Please
add a Build-Depends: rename to your package, and all will be well
again:

make[1]: Entering directory '/<>'
rename 's/\.py//' debian/graphite-carbon/usr/bin/*.py
/bin/sh: 1: rename: not found
debian/rules:7: recipe for target 'override_dh_install' failed
Let me know if you would prefer an NMU to get this trivial change made.

Cheers,
Dominic.

[1] 

Bug#874040: fprintd: please Build-Depend on rename

[Dominic Hargreaves]

Source: fprintd
Version: 0.7.0-1
Severity: serious
Justification: FTBFS with impending change
User: debian-p...@lists.debian.org
Usertags: rename-deprecation

As announced last year[1] and as advised by deprecation messages,
rename(1) will be removed from the perl package after the stretch
release, and this is now imminent.

Your package FTBFS with perl from experimental as a result. Please
add a Build-Depends: rename to your package, and all will be well
again:

# Arch-qualify pam-configs
rename 's|(.*)/(.*)$|$1/$2.amd64|' debian/libpam-fprintd/usr/share/pam-configs/*
/bin/sh: 1: rename: not found
debian/rules:35: recipe for target 'override_dh_install-arch' failed

Let me know if you would prefer an NMU to get this trivial change made.

Cheers,
Dominic.

[1] 

Bug#873928: caveconverter: please Build-Depend on rename

[Dominic Hargreaves]

Source: caveconverter
Version: 0~20170114-1
Severity: serious
Justification: FTBFS with impending change
User: debian-p...@lists.debian.org
Usertags: rename-deprecation

As announced last year[1] and as advised by deprecation messages,
rename(1) will be removed from the perl package after the stretch
release, and this is now imminent.

Your package FTBFS with perl from experimental as a result. Please
add a Build-Depends: rename to your package, and all will be well
again:

#change to unix command name in examples files
sed --in-place -e 's/java -jar CaveConverter.jar/caveconverter/' 
debian//caveconverter/usr/share/doc/caveconverter/examples/*.bat
rename 's/\.bat$//' 
debian//caveconverter/usr/share/doc/caveconverter/examples/*.bat
/bin/sh: 1: rename: not found

Let me know if you would prefer an NMU to get this trivial change made.

Cheers,
Dominic.

[1] 

Bug#825608: Remove libnet-jifty-perl?

[Dominic Hargreaves]

I noticed that that this bug has been tagged rm-candidate, and I'd like
to support this. There has been no upstream activity on Jifty since 2011
and Best Practical abandoned their plans to port RT to this framework
(which was, IIRC, the original reason for its creation).

There are no rdepends and a low/dropping popcon. Any objections to me
requesting this removal?

Cheers,
Dominic.