Bug#1067571: applicability to stable and oldstable

[Dominic Hargreaves]

We had intended to update this via a DSA in stable and oldstable, but
I believe 
renders this unexploitable, so it'll probably go in as a point release
instead.

Dominic

Bug#1067571: anope: suspended users can reset their passwords

[Dominic Hargreaves]

Package: anope
Version:  2.0.12-1
Severity: important
Tags security pending

A security issue was fixed in the most recent 2.0.15 release:
IRC users can evade account suspensions by resetting their password.

Bug#1063653: Acknowledgement (anope: Please ship new upstream version)

[Dominic Hargreaves]

On Mon, Feb 26, 2024 at 07:56:42PM -0500, Victor Coss wrote:
> Now the latest version is 2.0.15 which includes even more bug fixes
> including a more concerning race condition.
> https://www.anope.org/news/2024/anope-2015-release.html
> 
> Would greatly appreciate it if you can package the updated version.

Thanks for letting me know. I have been short on time in recent weeks
due to other commitments. I will try and look at this this week, all
being well. If any Debian contributor would like to upload a new version,
that's also fine with me!

Cheers
Dominic

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#1031587: [request-tracker-maintainers] Bug#1031587: Handling of the request-tracker4 -> request-tracker5 transition in bookworm

[Dominic Hargreaves]

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.

Dominic

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

[Dominic Hargreaves]

On Sun, Feb 19, 2023 at 12:12:15AM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: Dominic Hargreaves , Debian Request Tracker 
> Group 
> Control: block 1030749 by -1
> 
> https://release.debian.org/testing/freeze_policy.html#soft
> 
> ...
> Dropping or adding binary packages to a source package, moving binaries 
> between source packages or renaming source or binary packages is no longer 
> allowed. Packages with these changes will not be allowed to migrate to 
> testing. These changes are also no longer appropriate in unstable.
> ...
> 
> 
> The problem is that opening of #1030749 is de facto
> a request-tracker4 -> request-tracker5 transition that
> happened 4 weeks after the deadline for transitions.
> 
> 
> There are two options for resolving this:
> 1. Treat #1030749 as a forbidden transition and ship both versions
>of request-tracker in bookworm, or
> 2. grant reverse dependencies an exception from the soft freeze
>rules for the request-tracker4 -> request-tracker5 transition.

Hi, 

Thanks very much for flagging this. I must admit I had lost sight of
the fact that this still required so much work and that it would count
as a transition. We had originally planned this for a long while ago
but never quite completed it.

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.

Please let us know.

Best
Dominic

> For option 2 I looked at the 9 reverse dependencies of request-tracker4
> in the autoremoval list:
> 
> RT extension installer that has to stop depending on
> both versions:
> - libmodule-install-rtx-perl
> 
> No package remame required, has to upgrade to the upstream version
> that supports request-tracker5:
> - librt-extension-commandbymail-perl
> 
> Ships packages for both versions and has to drop the
> request-tracker4 package:
> - rt-extension-assets-import-csv
> 
> request-tracker4 -> request-tracker5 transition prepared
> in experimental:
> - rt-extension-customfieldsonupdate
> - rt-extension-calendar
> - rt-extension-jsgantt
> - rt-extension-nagios
> - rt-extension-smsnotify
> 
> Update to latest upstream version and package rename required:
> - rt-extension-repeatticket

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#221790: perl: please kick out that annoying locale warning

[Dominic Hargreaves]

On Sat, Nov 26, 2022 at 09:44:06AM -0800, Russ Allbery wrote:
> Rene Engelhard  writes:
> 
> > dpkg-buildpackage: source package is dmake
> > perl: warning: Setting locale failed.
> > perl: warning: Please check that your locale settings:
> > LANGUAGE = (unset),
> > LC_ALL = (unset),
> > LANG = "de_DE@euro"
> > are supported and installed on your system.
> 
> > is _extremely_ annoying. Everytime I build something in a chroot via
> > sbuild (which is a clean chroot; so no locales are installed there)
> > and I forget to set LANG="C" this message obfuscates everything...
> 
> I used to see this warning all the time, but I haven't seen it in years.
> I think something may have changed about how locales works or about how
> upgrades are sequenced that resolved it?  However that happened, I'm
> wondering if this 19-year-old bug should be closed.

This is resolved for upgrades in 

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

but (per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221790#39)
this bug was left over for the general case.

Cheers
Dominic

Bug#1009174: [request-tracker-maintainers] Bug#1009174: request-tracker4: disordering of email headers in forwarded messages

[Dominic Hargreaves]

On Fri, Apr 08, 2022 at 08:59:06AM +0200, Joost van Baal-Ilić via 
pkg-request-tracker-maintainers wrote:
> Package: request-tracker4
> Version: 4.4.1-3+deb9u3
> Severity: normal
> 
> Dear Maintainer,
> 
> RT changes the original order of email headers when forwarding attached 
> emails.
> This is seen in case the original message was offered to RT with a leading 
> unix
> style From_ header.  This behaviour causes havoc in case the full mime message
> later gets analysed by strict spam scanners who interpret mime-included 
> message
> headers.

Thanks for the detailed report!

4.4.1 is now very old from an upstream point of view (and indeed even
in Debian that's from an LTS only release now).

Have you been able to reproduce this with a newer release such as
4.4.5 (which is in sid/testing)? I don't have a suitable test system
for this at the moment, unfortunately (I'm not using RT at all any more).

If it can be reproduced with 4.4.5 I think this report would be in a
good state to forwards upstream.

Cheers
Dominic

Bug#1009786: request-tracker4: CVE-2021-38562 username enumeration via timing side-channel attack

[Dominic Hargreaves]

Source: request-tracker
Version: 4.4.4+dfsg-3
Severity: important

Per https://docs.bestpractical.com/release-notes/rt/4.4.5:

Security

* In previous versions, RT's native login system is vulnerable to user 
enumeration
through a timing side-channel attack. This means an external entity could try to
find valid usernames by attempting logins and comparing the time to evaluate 
each
login attempt for valid and invalid usernames. This vulnerability does not 
allow any
access to the RT system. This vulnerability is assigned CVE-2021-38562 and is 
fixed
in this release.

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#1009785: RM: libextutils-parsexs-perl -- ROM; Maintained primarily in src:perl

[Dominic Hargreaves]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-p...@lists.debian.org

Per #912682, this package doesn't have any real use.

Bug#997994: Incompatibility between Net::FTP and IO::Socket::SSL

[Dominic Hargreaves]

Control: forwarded -1 https://github.com/steve-m-hay/perl-libnet/pull/40

On Thu, Oct 28, 2021 at 01:42:15PM +0200, Nathan MALO wrote:
> Package: perl-modules-5.32
> Version: 5.32.1-4+deb11u2
> 
> Hello,
> 
> I use backup-manager (conf attached) to upload tarballs to a FTPS
> destination.
> backup-manager use the perl package Net::FTP to handle ftp connections.
> It seems that the Net::FTP v3.11 perl package is incompatible with the
> IO::Socket:SSL perl package provided by the libio-socket-ssl-perl v2.069-1
> debian package.
> This version of Net::FTP uses a custom SSL_session_cache which lacks a
> 'del_session' routine invoked by IO::Socket:SSL.

...

> Net::FTP=GLOB(0x5646f37d5218)<<< 227 Entering Passive Mode
> (xx,xxx,xxx,xxx,xxx,xxx)
> Net::FTP=GLOB(0x5646f37d5218)>>> NLST
> Can't locate object method "del_session" via package
> "Net::FTP::_SSL_SingleSessionCache" at /usr/share/perl5/IO/Socket/SSL.pm
> line 3042.
> 
> 
> It seems to have been fixed in Net::FTP v3.13 by this commit :
> https://github.com/steve-m-hay/perl-libnet/commit/67281c8f29f081962cb7702a87c16a4473b936e8#diff-506ff1e09133b22009f33a185017deec1c04bce8e645f818c7c4fb2665c57ec3
> 
> This commit is present in perl 5.34, but I have not tested it.
> 
> Do you think that perl 5.34 could arrive in bullseye-backports ?
> 
> I am available for testing.
> I am using Debian GNU/Linux 11.1, kernel 5.10.0-9, and libc6
> 2.31-13+deb11u2.

Sorry for the delay in replying. Yes, I think this could be added to
a stable release. It looks like we should also include
https://github.com/steve-m-hay/perl-libnet/pull/41 too. I've enquired
about whether that can be released to CPAN.

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#1003653: Revision of removal of rename.ul from package util-linux

[Dominic Hargreaves]

On Sun, Apr 10, 2022 at 07:37:05PM +0200, Helmut Grohne wrote:
> Hi Dom and gregor,
> 
> On Sun, Apr 10, 2022 at 03:06:56PM +0100, Dominic Hargreaves wrote:
> > +1 to all of this.
> 
> Thank you for your replies. They're not unexpected, but we (or at least
> I) weren't entirely sure.
> 
> > Furthermore I'm troubled that this discussion rolled on for two months
> > having dropped the perl folk, in a circular fashion. That doesn't seem
> > to be in the spirit of cooperation alluded to in
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003653#122
> 
> At that time, we (ctte) didn't really consider changing the
> /usr/bin/rename API to be a viable option, but apparently Chris did and
> that only became fully clear much later. Thus the question popped up
> now.
> 
> In any case, we now have three relevant opinions that form a
> contradiction when combined:
> 
>  * Submitter: The util-linux rename implementation should be included in
>Debian
>  * Chris: The util-linux rename should be either /usr/bin/rename or
>absent.
>  * Dom/gregor: /usr/bin/rename should be perl rename.
> 
> In all of this discussion, I think we didn't have such a clear
> understanding of the disagreement. It always looked solvable in a
> consensual way to me. That has somewhat changed now.
> 
> The next step is checking back with Chris on whether his position could
> be adjusted. I would still prefer resolving this without using special
> ctte powers.

Thanks for the clarification.

By the way, it's possible that this discussion has taken place without
reference to the original bug where these issues were discussed at length:

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

I should have provided this link back in February when we were first
asked about it; mea culpa. I hope this is helpful.

Dominic

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Dominic Hargreaves]

On Sun, Apr 10, 2022 at 03:17:22AM +0200, gregor herrmann wrote:
> On Sat, 09 Apr 2022 19:00:37 +0200, Helmut Grohne wrote:
> 
> > Chris proposes to transition /usr/bin/rename from the perl API to the
> > util-linux API.
> [..]
> > Dom (or whoever maintains perl's rename now), would you agree to release
> > the /usr/bin/rename name to use it for util-linux' implementation
> > retaining prename for the perl implementation?
> 
> (The "whoever" was and is the Debian Perl Group :))
> 
> 
> I'd like to quote Chris and Dom from #114 in this bug:
> 
>   On Tue, Jan 25, 2022 at 09:16:25AM +0100, Chris Hofstaedtler wrote:
>   > A very valid way of closing this discussion is saying "our
>   > (Perl) /usr/bin/rename is great, people should use that".
> 
>   That's the conclusion I came to when I looked at this at the point of
>   packaging rename separately. There doesn't seem to be any benefit to
>   changing this command line interface in Debian at this stage even though
>   I don't think it should have been there in the first place.
> 
>   Dominic
> 
> I think this conclusion still holds.
> 
> 
> Some additional thoughts:
> * Shipping u-l's rename as /usr/bin/rename.ul might be nice for users
>   who want to use it and are already used to this name.
> * Switching /usr/bin/rename from perl's rename to u-l's rename will
>   break interactive and scripted user experience.
> * A Conflicts of a new util-linux-$something against file-rename will
>   be painful for users.
> * Personally I very much prefer compatibility with Debian's history
>   over compatibility with Fedora.
> * Side note: "releasing the /usr/bin/rename name" is an interesting
>   framing.

+1 to all of this.

Furthermore I'm troubled that this discussion rolled on for two months
having dropped the perl folk, in a circular fashion. That doesn't seem
to be in the spirit of cooperation alluded to in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003653#122

Bug#793660: Is still an issue

[Dominic Hargreaves]

On Wed, Feb 02, 2022 at 12:48:17PM +0100, Marc Haber wrote:
> Control: outlook -1 close 2022-04-30
> thanks
> 
> On Sat, Dec 11, 2021 at 09:22:15AM +0100, Marc Haber wrote:
> > is this still an issue? If so, can I get more instructions about how do
> > reproduce this please?
> 
> Please check with sudo 1.9.9 whether this still happens. If the sudo
> maintainers cannot reproduce this behavior by the End of April 2022,
> this bug will be closed.

I don't have access to the systems I was using at the time (and I suspect
they don't exist). So I'm not able to provide any more information about
this bug.

Dominic

Bug#985934: chromium: Built in update feature appears to be enabled

[Dominic Hargreaves]

On Tue, Feb 08, 2022 at 06:12:20PM -0500, Andres Salomon wrote:
> On Sun, 28 Mar 2021 18:44:48 +0200 Michel Le Bihan wrote:
> > Hello,
> >
> > Are you sure that you were using Chromium from the Debian package?
> >
> > Michel Le Bihan
> >
> >
> 
> >
> 
> 
> Hi, I don't know if you saw Michel's response. Can you please let us know if
> it was the debian package chromium (the About Chromium page should
> specifically say this), and if it is still a problem in the latest chromium
> package?

I didn't see that, no (the BTS doesn't send messages to bug addresses
to the submitter).

I'm 100% sure that it was a Debian build - I've not ever used anything
else in the machine in question. I haven't seen the behaviour since,
however.

Dominic

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Dominic Hargreaves]

On Tue, Jan 25, 2022 at 09:16:25AM +0100, Chris Hofstaedtler wrote:
> Hi,
> 
> * Sean Whitton  [220125 00:06]:
> > On Mon 24 Jan 2022 at 11:33AM +01, Chris Hofstaedtler wrote:
> > 
> > > For context, the idea is that /usr/bin/rename should become
> > > src:util-linux' rename implementation.
> > 
> > That seems likely to break a great many scripts, though?
> > 
> > Perhaps we should ship them both under a name other than
> > /usr/bin/rename, such that people are prompted to update their scripts
> > to choose one, or create their own symlink?
> 
> Then all of this is a completely pointless exercise. Either we break
> them, or it is favorable to keeping the way things are:
> 
> A very valid way of closing this discussion is saying "our
> (Perl) /usr/bin/rename is great, people should use that".

That's the conclusion I came to when I looked at this at the point of
packaging rename separately. There doesn't seem to be any benefit to
changing this command line interface in Debian at this stage even though
I don't think it should have been there in the first place.

Dominic

Bug#987977: Silly shebang "#!./perl -w"

[Dominic Hargreaves]

Control: tags -1 + wontfix

On Mon, May 03, 2021 at 01:07:44PM +1000, Trent W. Buck wrote:
> Package: perl-modules-5.32
> Version: 5.32.1-3
> Severity: wishlist
> File: /usr/share/perl/5.32.1/ExtUtils/Miniperl.pm
> 
> While auditing shebangs for something else, I found this silly one:
> 
> $ sed -n 1p /usr/share/perl/*/ExtUtils/Miniperl.pm
> #!./perl -w
> 
> Can you get upstream to either remove it or change it to something sensible?
> 
> It doesn't really *matter*, it just looks so silly I had to say something!

This was introduced relatively recently:


I'm not sure without further investigation whether it has to be exactly
that way (due to the fact it's to be used by miniperl during the build
process) or whether it was added as an editor hint, or some other
reason but either way, I don't think it warrants an upstream bug report.

Bug#987995: perl-base: File::Temp file creation permissions are not documented

[Dominic Hargreaves]

Control: tags -1 + fixed-upstream

On Mon, May 03, 2021 at 02:39:21PM +0200, Vincent Lefevre wrote:
> The File::Temp documentation ("perldoc File::Temp", but also the
> File::Temp(3perl) man page, which is built from the source, AFAIK)
> doesn't say anything about the permissions of the created file.
> 
> This seems to have been fixed upstream together with another change
> related to permissions in
> 
>   
> https://github.com/Perl-Toolchain-Gang/File-Temp/pull/30/commits/7aede1e9034dfdc9ffe785538c11445645283711
> 
> merged in September 2019:
> 
>   https://github.com/Perl-Toolchain-Gang/File-Temp/pull/30
> 
> So I would have expected this to already be in Debian/unstable.

It didn't get released until a year later: 
https://github.com/Perl-Toolchain-Gang/File-Temp/blob/master/Changes#L6

It'll be in perl 5.34.0, expected in experimental in a month or so.

Dominic

Bug#985141: [request-tracker-maintainers] Bug#985141: request-tracker4: Misconfigured DatabaseAdmin when using mysql

[Dominic Hargreaves]

On Sat, Mar 13, 2021 at 04:18:17PM +0100, Peter Nagel wrote:
> Package: request-tracker4
> Version: 4.4.3-2
> Severity: normal
> 
> Dear Maintainer,
> 
> When installing request-tracker4 (mariadb-server and rt4-db-mysql are already 
> installed)
> I see (during installation) the following output:
>...

FTR, a fix is being discussed in a separate mailing list thread:

Bug#986707: rt4-db-mysql: should declare an incompatibility with mysql 8

[Dominic Hargreaves]

Package: rt4-db-mysql
Version: 4.4.4+dfsg-2

request-tracker4 as shipped with Ubuntu 20.04 is broken when used with
the MySQL release also shipped in Ubuntu. Whilst we can't fix that
directly in Debian, we an arrange for the dependencies to correctly 
reflect this, maybe by conflicting with mysql-server-8.0, and/orrequiring
mariadb explicitly.

Ubuntu bug report: 
https://bugs.launchpad.net/ubuntu/+source/request-tracker4/+bug/1923264

Bug#985934: chromium: Built in update feature appears to be enabled

[Dominic Hargreaves]

Package: chromium
Version: 89.0.4389.82-1
Severity: important
Tags: security

I got an orange "Update" prompt near the omnibar today, as usual when
a separately packaged Chrome installation wants to update itself. But
this is not expected behaviour from the Debian packaged Chromium. I tried
clicking on it and it appeared to go through the motions and restarted
itself (very quickly, such that I don't think it can have actually done
any updates).

The browser is still running from /usr/lib/chromium/chromium (and isn't
running as root).

At the very least, this is confusing to the users who be misled into
thinking that their browser has had secuirity fixes applied when it
hasn't. And at worst, it's somehow managing to download code from the
internet and run it.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common  89.0.4389.82-1
ii  libasound2   1.2.4-1.1
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libatomic1   10.2.1-6
ii  libatspi2.0-02.38.0-2
ii  libavcodec58 7:4.3.2-0+deb11u1
ii  libavformat587:4.3.2-0+deb11u1
ii  libavutil56  7:4.3.2-0+deb11u1
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libcups2 2.3.3op2-3
ii  libdbus-1-3  1.12.20-2
ii  libdrm2  2.4.104-1
ii  libevent-2.1-7   2.1.12-stable-1
ii  libexpat12.2.10-2
ii  libflac8 1.3.3-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgbm1  20.3.4-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.7-2
ii  libgtk-3-0   3.24.24-3
ii  libharfbuzz0b2.7.4-1
ii  libicu67 67.1-6
ii  libjpeg62-turbo  1:2.0.6-2
ii  libjsoncpp24 1.9.4-4
ii  liblcms2-2   2.12~rc1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libopenjp2-7 2.4.0-3
ii  libopus0 1.3.1-0.1
ii  libpango-1.0-0   1.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpulse014.2-2
ii  libre2-9 20210201+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.7.0-2
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxrandr2   2:1.5.1-1
ii  libxshmfence11.3-1
ii  libxslt1.1   1.1.34-4
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  89.0.4389.82-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6   2.31-9
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.0-2
ii  libxext62:1.3.3-1.1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox 89.0.4389.82-1
ii  fonts-liberation 1:1.07.4-11
ii  libgl1-mesa-dri  20.3.4-1
pn  libu2f-udev  
ii  notification-daemon  3.20.0-4
ii  system-config-printer1.5.14-1
ii  upower   0.99.11-2
ii  xfce4-notifyd [notification-daemon]  0.6.2-1

Versions of packages chromium-sandbox depends on:
ii  libc6  2.31-9

-- no debconf information

Bug#984466: dput-ng: sends invalid Uploader field if no email set

[Dominic Hargreaves]

Package: dput-ng
Version: 1.32
Severity: important
Tags: patch

Per https://salsa.debian.org/debian/dput-ng/-/merge_requests/15 dput-ng
sends invalid data when the user doesn't specify an email address. The
patch supplied resolves this.

Bug#983634: rt-extension-repeatticket: not compatible with RT5

[Dominic Hargreaves]

Source: rt-extension-repeatticket
Version: 1.11-1
Severity: important
Tags: sid
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=133122

As mentioned in the upstream report, the styling is broken in RT5.
There is an rt5 branch from upstream, so in the worst case, it may be
possible to apply those changes if there's no upstream release by the time
we want to upload RT5 to unstable (and drop RT4).

Bug#983140: ansible: Does not detect correct python interpreter on bullseye target

[Dominic Hargreaves]

Package: ansible
Version: 2.9.16+dfsg-1.1
Severity: important

I set up a fresh bullseye host (upgraded from a base buster
installation) and it has python3.7 and python3.9 installed. I think that
python3.7 is left over from buster and should probably be removed from
the host (apt-get autoremove does so). However, I expect this is a common
scenario after an upgrade.

if I run my base playbook in check mode it tells me to install
python3-apt, but that is already installed on the target. The reason is
that python3-apt in bullseye only provides the module for python3.9,
but ansible tries to run python3.7.

The following patch fixes this:

--- /usr/lib/python3/dist-packages/ansible/config/base.yml.bak  2021-02-19 
22:34:00.363529032 +
+++ /usr/lib/python3/dist-packages/ansible/config/base.yml  2021-02-19 
22:34:08.987398189 +
@@ -1462,6 +1462,7 @@
   name: Ordered list of Python interpreters to check for in discovery
   default:
   - /usr/bin/python
+  - python3.9
   - python3.7
   - python3.6
   - python3.5

Something similar is available upstream:


Please consider applying this fix in the version of ansible shipped
with bullseye so that bullseye hosts can manage bullseye hosts out of the
box.

(I'd also suggest moving /usr/bin/python3 up that list so that this
doesn't recur for future python 3 releases.)

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ansible depends on:
ii  openssh-client1:8.4p1-3
ii  python3   3.9.1-1
ii  python3-cryptography  3.3.1-1
ii  python3-distutils 3.9.1-2
ii  python3-dnspython 2.0.0-1
ii  python3-httplib2  0.18.1-3
ii  python3-jinja22.11.2-1
ii  python3-netaddr   0.7.19-4
ii  python3-paramiko  2.7.2-1
ii  python3-yaml  5.3.1-3+b1

Versions of packages ansible recommends:
pn  python3-argcomplete  
pn  python3-jmespath 
pn  python3-kerberos 
pn  python3-libcloud 
pn  python3-selinux  
pn  python3-winrm
pn  python3-xmltodict

Versions of packages ansible suggests:
pn  cowsay   
ii  sshpass  1.09-1+b1

-- no debconf information

Bug#983099: perl FTCBFS: cross configs outdated

[Dominic Hargreaves]

On Fri, Feb 19, 2021 at 11:00:20AM +0100, Helmut Grohne wrote:
> Source: perl
> Version: 5.32.1-2
> Severity: important
> X-Debbugs-Cc: debian-rele...@lists.debian.org
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> perl currently fails to cross build from source, due to a minor version
> bump. Whenever the version is updated, the cross compilation configs
> need to be updated and this didn't happen for perl.
> 
> Such temporary ftcbfs are usual for perl. What makes this worthy of
> reporting is that this version will end up in bullseye. There are a
> number of embedded distributions now that are based on Debian and due to
> perl's central role to Debian it should be cross buildable in stable.
> 
> The risk of breaking anything by fixing this bug is quite low as these
> cross configs are used for nothing but cross building perl and updating
> them is a routine task to Niko. I've Cced d-release in case they want to
> object now before Niko files an unblock request.

Thanks for the heads up. I had not realised the significance of these
cross files in the context of the stable release.

Niko, I see there is a debian/cross/extract-config-sh - could you
possibly add a note to debian/README.source explaining the
circumstances under which it needs to be run? I see there were multiple
updates for 5.32.0 so it looks like it's not only with new upstream
versions it needs to be run.

Probably it needs to be listed at 

too.

Cheers
Dominic

Bug#981647: libgnupg-interface-perl 1.01 breaks ssh-agent msva-perl ...

[Dominic Hargreaves]

On Sun, Feb 07, 2021 at 11:42:43PM +, Dominic Hargreaves wrote:
> [Adding Andrew as the person who has recently worked on the package]
> 
> On Sun, Feb 07, 2021 at 03:28:48PM -0500, Aaron M. Ucko wrote:
> > Dominic Hargreaves  writes:
> > 
> > > As a hunch, I changed the default from 'gpg' to '/usr/bin/gpg'.
> > > Could you install this on your system and confirm whether it fixes
> > > the problem?
> 
> (the tentative fix was at
> <https://salsa.debian.org/perl-team/modules/packages/libgnupg-interface-perl/-/tree/hardcode-gpg-path>)
> 
> > I must confess that I haven't actually fully deployed MonkeySphere, so I
> > can't test the change quite as thoroughly as it perhaps deserves, but
> > AFAICT this tweak is sufficient: I can log in without incident, and both
> > dh_auto_test calls to succeed (albeit noisily) with
> > 
> >   -- FULLPERL='/usr/bin/perl -t'
> > 
> > appended.  (Full -T appears to break the test harness, but -t suffices
> > to trigger the PATH-clearing logic.)
> 
> In fact, I've just realised that this regression comes from reverting
> a functionality equivalent (part of a) patch in the latest upload.
> This looks like it might have been unintentional?
> 
> https://salsa.debian.org/perl-team/modules/packages/libgnupg-interface-perl/-/commit/a96ae3047570483e96da309008d4110f16824ed5#f37d120361709f5984c8a7d93302241dc341b4b3_1_1
> 
> Andrew, was this intentional? Maybe we should just restore that part
> of the patch?

Ah, I expect the change to /usr/bin/gpg was lost when applying an
altered upstream version of the patch. So my tentative fix
was correct and just the previous behaviour, with the upstream
changes and the Debian-specific changes now in separate files.
Uploaded.

Bug#981647: libgnupg-interface-perl 1.01 breaks ssh-agent msva-perl ...

[Dominic Hargreaves]

[Adding Andrew as the person who has recently worked on the package]

On Sun, Feb 07, 2021 at 03:28:48PM -0500, Aaron M. Ucko wrote:
> Dominic Hargreaves  writes:
> 
> > As a hunch, I changed the default from 'gpg' to '/usr/bin/gpg'.
> > Could you install this on your system and confirm whether it fixes
> > the problem?

(the tentative fix was at
<https://salsa.debian.org/perl-team/modules/packages/libgnupg-interface-perl/-/tree/hardcode-gpg-path>)

> I must confess that I haven't actually fully deployed MonkeySphere, so I
> can't test the change quite as thoroughly as it perhaps deserves, but
> AFAICT this tweak is sufficient: I can log in without incident, and both
> dh_auto_test calls to succeed (albeit noisily) with
> 
>   -- FULLPERL='/usr/bin/perl -t'
> 
> appended.  (Full -T appears to break the test harness, but -t suffices
> to trigger the PATH-clearing logic.)

In fact, I've just realised that this regression comes from reverting
a functionality equivalent (part of a) patch in the latest upload.
This looks like it might have been unintentional?

https://salsa.debian.org/perl-team/modules/packages/libgnupg-interface-perl/-/commit/a96ae3047570483e96da309008d4110f16824ed5#f37d120361709f5984c8a7d93302241dc341b4b3_1_1

Andrew, was this intentional? Maybe we should just restore that part
of the patch?

Dominic

Bug#982258: gpgv1: Consider removing parts of the tools which aren't recommended to be used

[Dominic Hargreaves]

Package: gpgv1
Version: 1.4.23-1.1
Severity: wishlist

In the discussion at [1] it was suggested that perhaps gnupg1 could be
updated to explicitly remove support for operations other than
decrypting old messages.

[1] 

Bug#981647: libgnupg-interface-perl 1.01 breaks ssh-agent msva-perl ...

[Dominic Hargreaves]

On Tue, Feb 02, 2021 at 10:09:45AM -0500, Aaron M. Ucko wrote:
> Package: libgnupg-interface-perl
> Version: 1.01-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: msva-p...@packages.debian.org
> Control: affects -1 msva-perl
> 
> [Copying msva-perl maintainers.]
> 
> My X session normally boils down to
> 
> exec /usr/bin/ssh-agent /usr/bin/monkeysphere-validation-agent 
> /usr/bin/im-launch x-session-manager
> 
> where /usr/bin/monkeysphere-validation-agent resolves (via the
> alternatives system) to /usr/bin/msva-perl.  With this setup,
> libgnupg-interface-perl 1.01 attempts to run gpg with no PATH and
> bails because it couldn't find an acceptable version of gpg, thereby
> immediately crashing msva-perl and my entire X session.
> 
> I'm not entirely sure what triggers the PATH-clearing here, perhaps
> the fact that ssh-agent is setgid ssh.  Regardless, I'd suggest
> setting a sane PATH that includes at minimum /bin and /usr/bin rather
> than clearing PATH entirely.  (Explicitly running /usr/bin/gpg might
> also work.)
> 
> Could you please take a look?

As a hunch, I changed the default from 'gpg' to '/usr/bin/gpg'.
Could you install this on your system and confirm whether it fixes
the problem?

https://salsa.debian.org/perl-team/modules/packages/libgnupg-interface-perl/-/tree/hardcode-gpg-path

Cheers
Dominic

Bug#981942: [request-tracker-maintainers] Bug#981942: Bug#981942: request-tracker4: Dependency on rsyslog | system-log-daemon prevents system with only journald

[Dominic Hargreaves]

On Sun, Feb 07, 2021 at 02:51:59PM +0100, Chris Hofstaedtler wrote:
> Just wanted to chime in here: systemd's journald always takes over
> /dev/log. This usually means any syslog() calls end up in the
> journal.
> If rsyslog is installed, it takes those messages from journald and
> writes them into the usual plaintext log files. I believe the same
> is true for the other syslog daemons.
> 
> Now, I -think- systemd does not provide system-log-daemon as that
> interface probably should have a syslog.service unit, by-default
> persistent log files and so on.

Yep, that seems reasonable.

> If RT uses /dev/log (via syslog() or the equivalent Perl interface),
> its credible to use RT with journald-only logging. I think
> Recommends would be fine here. Most systems will still have a syslog
> daemon installed, because rsyslog is still Priority: important.

Excellent points, thanks. I'll downgrade from Depends to Recommends.

Bug#982202: ITP: libmodule-install-substitute-perl -- Module::Install::Substitute - substitute values into files before install

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libmodule-install-substitute-perl
  Version : 0.03
  Upstream Author : Ruslan Zakirov 
* URL : https://metacpan.org/release/Module-Install-Substitute
* License : Perl
  Programming Lang: Perl
  Description : Module::Install::Substitute - substitute values into files 
before install

This is an extension for Module::Install system that allow you to substitute
values into files before install, for example paths to libs or binary
executables.

It will be maintained as part of the Debian Perl group.

Bug#981942: [request-tracker-maintainers] Bug#981942: request-tracker4: Dependency on rsyslog | system-log-daemon prevents system with only journald

[Dominic Hargreaves]

On Fri, Feb 05, 2021 at 10:35:49AM +0100, Florian Lohoff wrote:
> Hi,
> the dependency on
> 
>   rsyslog | system-log-daemon
> 
> prevents the removal of rsyslog for a pure systemd(-journald) system 
> as systemd does not provide system-log-daemon.
> 
> I am not that confident but wouldnt it be a valid requirement to run
> request-tracker WITHOUT logging? Could this dependency not be
> dropped completely?

I don't recommend running without logging. Is there actually
a problem with having syslog installed? I mean, it's a standard logging
interface I'd expect to see on any Debian server setup and if systemd
doesn't provide it when users expect it, that's a flaw on the systemd
side.

RT can be configured to run with file based logging, but that's not the
default. We could probably downgrade to Recommends if there was a real
reason to.

Bug#981232: unblock: perl/5.32.1-1

[Dominic Hargreaves]

On Tue, Feb 02, 2021 at 09:08:28AM +0100, Paul Gevers wrote:
> Hi,
> 
> On 02-02-2021 08:47, Dominic Hargreaves wrote:
> > Please rebuild these packages as discussed:
> > 
> > $ wb nmu libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl 
> > libcommon-sense-perl libdevel-mat-dumper-perl . ANY . -m "Rebuild against 
> > perlapi-5.32.1." --extra-depends 'perl-base (>= 5.32.1)'

Thanks!

Bug#974004: Still an issue

[Dominic Hargreaves]

Control: block -1 by 970460

This is an ongoing issue that occurred for 5.32.1 too. For future
new upstream releases, we could send a courtesy note along the lines
of 

 (ideally just before we upload).

Bug#981232: unblock: perl/5.32.1-1

[Dominic Hargreaves]

On Mon, Feb 01, 2021 at 08:38:40PM +0100, Paul Gevers wrote:
> Control: tag -1 confirmed
> 
> Hi,
> 
> On 31-01-2021 21:50, Niko Tyni wrote:
> > please consider approving 5.32.1. I think it would be
> > better to release bullseye with that than a Debian-specific 5.32.0 with
> > the patches from 5.32.1 (but both options are better than not having
> > the patches at all.)
> 
> Please go ahead.

Thanks, this is now uploaded and building:

https://buildd.debian.org/status/package.php?p=perl

Please rebuild these packages as discussed:

$ wb nmu libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl 
libcommon-sense-perl libdevel-mat-dumper-perl . ANY . -m "Rebuild against 
perlapi-5.32.1." --extra-depends 'perl-base (>= 5.32.1)'

Thanks!
Dominic

Bug#846029: Raising severity

[Dominic Hargreaves]

Control: severity -1 important

I'm raising the severity of this, because we shouldn't be the one packaging
causing gnupg1 to ship in bullseye.

Bug#981232: unblock: perl/5.32.1-1

[Dominic Hargreaves]

On Sat, Jan 30, 2021 at 09:13:42PM +0200, Niko Tyni wrote:
> On Sat, Jan 30, 2021 at 07:35:04AM +0100, Paul Gevers wrote:
> 
> > The pseudo excuses [1] report quite some autopkgtest regressions. Can
> > you please check them, fix them if relevant or explain why they are not
> > relevant for bullseye (e.g. unstable only)?
> 
> > [1] https://release.debian.org/britney/pseudo-excuses-experimental.html#perl
> 
> I spent most of today going through logs of the 300 or so packages showing
> regressions. The gain was not worth the maintainer time IMHO. I'm not
> looking forward to doing this again for the actual testing migration.

Thanks!

> I found about 160 network/proxy failures on arm64 hosts with apt bailing
> out, and about 120 installability failures relating to the four packages
> that we already knew will need a rebuild.
> 
> The remaining 19 failures are categorized below with comments.
> 
> I'm away from my credentials for the self service, can schedule retries
> probably tomorrow if necessary. Happy if somebody else beats me to it.

I pressed retry a bunch of times.

> Needs fixing for 5.32.1
> ---
> 
> - libdevel-mat-dumper-perl
>  real issue; needs a strict dependency and a rebuild for 5.32.1
>  also means this is a fifth package that needs a binnmu
>  filed #981408
> 
> - perl 
> filed as #981409
> minor issue, can be fixed when uploading to sid

Fixed in git.

> Retry suggested
> ---
> 
> bioperl # flaky; API rate limit exceeded, similar to testing/amd64/1.7.7-2  
> 2020-12-02 04:21:20 UTC
> backuppc # one-off? unlikely it's perl's fault
> jellyfish # test suite timeout, not perl specific?
> ikiwiki-hosting # not perl specific: apache2.service: Failed to set up mount 
> namespacing: Permission denied
> libbio-db-ncbihelper-perl # network error? MSG: Can't query website: 500 
> Status read failed: Connection reset by peer
> trinityrnaseq # probably flaky?
> libtest-valgrind-perl # no idea, worth a retry. Might be a valgrind issue on 
> ppc64el

Bug#981232: unblock: perl/5.32.1-1

[Dominic Hargreaves]

On Thu, Jan 28, 2021 at 10:21:21PM +0100, Paul Gevers wrote:
> Hi Dominic,
> 
> On 28-01-2021 22:05, Dominic Hargreaves wrote:
> >>> 5.32.1 would need a binnmu of a few leaf packages
> >>> (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl
> >>> libcommon-sense-perl) as usual.
> >>
> >> Just to be clear, these binNMU's would be needed too if we would go for
> >> the cherry-pick option?
> > 
> > No, the binaries relate to a change of upstream version number
> > which ends up being encoded in these packages. If we cherry pick
> > fixes, the binNMUs wouldn't be needed.
> 
> But then, that relation is strictly speaking too tight? Is that
> something that can be improved (without jumping through hoops)? Maybe
> not for this time, but for future changes. Normally perl packages look
> for the perl-something-api right? Which would make it clear that this is
> no transition.

The packages in the mini-transition have a full version dependency
built into them - it's not API/ABI related. It's been a while but we've
looked at improving this before and it's not really practical given
the assumptions built into the upstream code. It's also generally
not been an issue to do the binNMUs.

> Would you have also asked us if you wouldn't have needed the binNMU's?

Yes, since https://release.debian.org/bullseye/freeze_policy.html says
changes to build-essential may only be made with pre-approval...

Bug#981232: unblock: perl/5.32.1-1

[Dominic Hargreaves]

On Thu, Jan 28, 2021 at 09:21:54PM +0100, Paul Gevers wrote:
> (Your bug title is wrong, as you can't use that version anymore as it's
> already in experimental ;) )
> 
> On 28-01-2021 00:39, Dominic Hargreaves wrote:

> > My preference is to upload 5.32.1 in whole as it's probably overall
> > less risky, and less maintenance work, but there is the option of
> > cherry-picking the targetted fixes too.
> > 
> > 5.32.1 would need a binnmu of a few leaf packages
> > (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl
> > libcommon-sense-perl) as usual.
> 
> Just to be clear, these binNMU's would be needed too if we would go for
> the cherry-pick option?

No, the binaries relate to a change of upstream version number
which ends up being encoded in these packages. If we cherry pick
fixes, the binNMUs wouldn't be needed.

Dominic

Bug#981232: unblock: perl/5.32.1-1

[Dominic Hargreaves]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

This is a pre-approval request.

As I wrote in 
https://lists.debian.org/debian-release/2021/01/msg00296.html

we'd like to get 5.32.1 into bullseye if possible. I should have probably
written all that in a bug instead so it can be tracked effectively.

As always, perl point releases are pretty conservative and we've
effectively imported them into s-p-u before.

All the reset of the context is in that post so I won't repeat it.
My preference is to upload 5.32.1 in whole as it's probably overall
less risky, and less maintenance work, but there is the option of
cherry-picking the targetted fixes too.

5.32.1 would need a binnmu of a few leaf packages
(libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl
libcommon-sense-perl) as usual.

perl 5.32.1 is currently in experimental - see


Cheers
Dominic

Bug#981077: ITP: request-tracker5 -- extensible trouble-ticket tracking system

[Dominic Hargreaves]

On Tue, Jan 26, 2021 at 11:17:34PM +0100, Geert Stappers wrote:
> On Tue, Jan 26, 2021 at 01:17:46AM +0000, Dominic Hargreaves wrote:
> > * Package name: request-tracker5
> >   Upstream Author : Best Practical Solutions, LLC >
> > * URL : https://bestpractical.com/rt/
> > * License : GPL-2
> >  .
> >  This package supports three database types out of the box: MySQL,
> >  PostgreSQL and SQLite. In order to support a zero-configuration install,
> >  SQLite will be used by default, but is not recommended for production
> >  use. Please see /usr/share/doc/request-tracker5/NOTES.Debian for more
> >  details and consider installing rt5-db-postgresql or rt5-db-mysql at
> >  the same time as this package.
> 
> How I would write those last three lines
> 
> }  use. Please see /usr/share/doc/request-tracker5/NOTES.Debian for more
> }  details. Consider to install rt5-db-postgresql or rt5-db-mysql when
> }  installing this package.
> 
> 
> It is the  'at the same time as this'  that I'm wanting to loose.
> 
> Please feel free to ignore this non-native English speaker.

Hi

Thanks for the feedback.

There's a distinction between when you do the consideration and when
you do the installation. The point here is that things go more smoothly
if you install the relevant support packages *together* with the main
one. That emphasis is lost in your version. (Perhaps "installing [...]
together with this package" would be an improvement). That said, this
wording has been in place since 2009...

On a more technical note, "Consider to install" is incorrect; it should
be "Consider installing".

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#981077: ITP: request-tracker5 -- extensible trouble-ticket tracking system

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: request-tracker5
  Version : 5.0.0
  Upstream Author : Best Practical Solutions, LLC >
* URL : https://bestpractical.com/rt/
* License : GPL-2
  Programming Lang: Perl
  Description : extensible trouble-ticket tracking system

 Request Tracker (RT) is a ticketing system which
 enables a group of people to intelligently and efficiently manage
 tasks, issues, and requests submitted by a community of users. It
 features web, email, and command-line interfaces (see the package
 rt5-clients).
 .
 RT manages key tasks such as the identification, prioritization,
 assignment, resolution, and notification required by
 enterprise-critical applications, including project management, help
 desk, NOC ticketing, CRM, and software development.
 .
 This package provides the 5 series of RT. It can be installed alongside
 the 3.8 and 4 series without any problems.
 .
 This package provides the core of RT.
 .
 This package supports three database types out of the box: MySQL,
 PostgreSQL and SQLite. In order to support a zero-configuration install,
 SQLite will be used by default, but is not recommended for production
 use. Please see /usr/share/doc/request-tracker5/NOTES.Debian for more
 details and consider installing rt5-db-postgresql or rt5-db-mysql at
 the same time as this package.

This package is the next major release of the software currently
packaged as request-tracker4, and the packaging is a branch of that.

It will be mainted by the RT packaging team,
.

Bug#846029: [request-tracker-maintainers] Bug#846029: Bug#846029: Bug#846029: request-tracker4: uses deprecated gpg1

[Dominic Hargreaves]

On Tue, Jan 05, 2021 at 12:58:21PM +1300, Andrew Ruthven wrote:
> Hey,
> 
> On Mon, 2021-01-04 at 11:03 +, Dominic Hargreaves wrote:
> > On Tue, Dec 15, 2020 at 10:47:30PM +0100, Chris Hofstaedtler wrote:
> > 
> > > Maybe its time to switch RT4 to gnupg2?
> > 
> > Andrew: I think that this just means replicating the changes you made
> > in RT5 to drop the gpg1 patches and update the dependency? Do you
> > foresee
> > any issues with this?
> 
> The changes I made for our RT5 packaging are already in the RT4 branch.
> I think we should be safe to switch RT to using gnupg2. This will
> probably require a note in debian/NEWS as people may need to update how
> they handle gpg passphrases.
> 
> The only dependency change we need to make is Build-Depends.

I had a quick look but it looks like there are quite a few gpg1
patches in the RT4 branch still. Do you have unpushed changes?
I did the naive thing and dropped the gpg1 patches and switched
the build-depends to gnupg, but that results in lots of test failures.

Cheers
Dominic

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#846029: [request-tracker-maintainers] Bug#846029: request-tracker4: uses deprecated gpg1

[Dominic Hargreaves]

On Tue, Dec 15, 2020 at 10:47:30PM +0100, Chris Hofstaedtler wrote:
> Hi,
> 
> * Dominic Hargreaves  [201215 21:46]:
> > Since #845534 was fixed RT now uses gpg1, which is deprecated, or at
> > least its uses discouraged, in Debian.
> 
> As of today, RT4 is apparently the last package directly depending
> on gnupg1 in bullseye. The other packages doing so appear to be
> using gpg1 only for tests at build time.

Thanks for raising this. I imagine it's better for everyone if gnupg1
doesn't get shipped in bullseye. Let's try to make this happen.
 
> > Fixing this is blocked by #845781.
> 
> This appears to be fixed.
> 
> Maybe its time to switch RT4 to gnupg2?

Andrew: I think that this just means replicating the changes you made
in RT5 to drop the gpg1 patches and update the dependency? Do you foresee
any issues with this?

Cheers
Dominic

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#791362: perl: build timezone affects LOCALTIME_{MIN,MAX}

[Dominic Hargreaves]

On Wed, Oct 23, 2019 at 10:40:00PM +0300, Niko Tyni wrote:
> Control: found -1 5.30.0-8
> 
> On Fri, Jul 03, 2015 at 11:16:46PM +0300, Niko Tyni wrote:
> > On Mon, May 04, 2015 at 02:28:04PM +0200, Jérémy Bobbio wrote:
> 
> > > Another issue that surfaced now that we are doing timezone variations is
> > > that LOCALTIME_MIN and LOCALTIME_MAX gets different values depending on
> > > the value of the TZ environment variable.
> > 
> > > The minimum I had on my amd64 system is with TZ=UTC-24, -62167305600.
> > > The maximum is with TZ=UTC and is 67768036191590399.
> > > 
> > > It feels like a bug to have something that can be configured through an
> > > environment variable on a running system affect what gets encoded in the
> > > binary.
> > 
> > This feels like a bug to me too, and should be handled separately.
> > I'm cloning this and will export TZ=UTC in debian/rules, at least
> > for now.
> 
> The TZ=UTC part was accidentally dropped in the build system debhelper
> conversion for 5.30 packaging. This resulted in a reproducibility
> regression that Holger pointed out to me on IRC (thanks!).
> 
> I'll re-instate TZ=UTC in 5.30.0-9 or so, but clearly the underlying
> issue remains.

Hi Niko,

I'm struggling to see the practical problem with having the timezone
vary LOCALTIME_{MIN,MAX} (other than reproducibility, which AIUI has
already been addressed). I don't agree with the starting point that
an environment variable shouldn't be able to influence the contents
of the binary (this is clearly a very common and necessary pattern).

Could you elaborate on your reasoning for keeping this bug open?

Thanks
Dominic

Bug#971935: libperl5.30: rfc-ignorant MIME-Header can make decode() crash

[Dominic Hargreaves]

Control: tags -1 + moreinfo

On Fri, Oct 09, 2020 at 11:02:57PM -0300, eingousef wrote:
> Package: libperl5.30
> Version: 5.30.3-4
> Severity: normal
> 
> Dear Maintainer,
> 
> I have tried to follow the recommendations of :
> 
> https://github.com/pbrisbin/mail-query/blob/master/README.md
> 
> by adding
> 
> set query_command= "mail-query '%s' ~/Mail/ | perl -CS -MEncode -ne 'print 
> decode(\"MIME-Header\", $_)'"
> 
> to my muttrc.
> 
> Unfortunately one e-mail of my mailbox contains an iso-8859-1 header
> which is not ASCII-encoded, and it makes the command crash with the
> following output :
> 
> Malformed UTF-8 character: \xe9\x62\x69 (unexpected non-continuation byte 
> 0x62, immediately after start byte 0xe9; need 3 bytes, got 1) in substitution 
> (s///) at /usr/lib/x86_64-linux-gnu/perl/5.30/Encode/MIME/Header.pm line 90, 
> <> line 24. Malformed UTF-8 character (fatal) at 
> /usr/lib/x86_64-linux-gnu/perl/5.30/Encode/MIME/Header.pm line 90, <> line 24.
> 
> messing up the Mutt UI.
> 
> I don't know much about perl libraries so I don't know if my report is
> relevant or not, maybe it is the expected behavior for decode() to
> trust user input.
> 
> If it's not, then it should check if the string is a properly
> formatted MIME-Header bfore trying to decode it.

Based on 
and 
it's debatable whether this is a bug.

I'd like to forward this upstream for their consideration, but please
can you include a simple test case - ie an example of one of
the malformed headers?

Cheers
Dominic.

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#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#974029: perl: add breaks on packages which were missing libpod-parser-perl deps

[Dominic Hargreaves]

Source: perl
Version: 5.32.0-4

perl 5.32 doesn't include Pod::Parser and packages which relied on this
being part of perl before added (or are in the process of adding)
dependencies on libpod-parser-perl. We should break versions earlier
than that once the updates have been made.

They are listed at

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.32-transition;users=debian-p...@lists.debian.org

Bug#974004: perl: FTBFS on m68k and sh4: qemu-user trashes argv[0] breaking multi-call binaries

[Dominic Hargreaves]

Source: perl
Version: 5.32.0-4
Severity: important

We seem to be affected by #970460 in qemu-user which is breaking builds
on m68 and sh4:

https://lists.debian.org/debian-perl/2020/11/msg7.html

Severity set to important since these are non-release architectures.

Bug#968912: transition: perl 5.32

[Dominic Hargreaves]

On Sat, Nov 07, 2020 at 09:13:50AM +0100, Sebastian Ramacher wrote:
> On 2020-10-15 22:29:53 +0200, Sebastian Ramacher wrote:
> > On 2020-10-15 18:27:08 +0100, Niko Tyni wrote:

> > > These are resolved now, and all known regressions found in our test
> > > rebuilds are marked as blocking this bug.
> > > 
> > > The libpod-parser-perl dependencies are trivial to add.
> > > 
> > > There's no fix for libdata-alias-perl, and I expect we'll need to remove
> > > it from testing. It's just an optional dependency for other packages
> > > AFAICS, so I don't expect much fallout (as long as the build dependencies
> > > are relaxed in libio-stream-perl and libmethod-signatures-perl first.)
> > > 
> > > Could we raise the remaining bugs to 'serious' now? Do you have any
> > > guesstimate on the timing for a transition slot?
> > 
> > There is some overlap with the currently ongoing ocaml transition. So
> > let's wait until that one is done.
> 
> The ocaml transition has finished, so please go ahead with the upload to
> unstable.

I've raised the remaining bugs to serious and uploaded 5.32 to unstable.

Cheers
Dominic.

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#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#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#960863: Help needed with perl-tk NMU

[Dominic Hargreaves]

On Sat, Sep 12, 2020 at 10:45:23PM +0300, Damyan Ivanov wrote:
> -=| Damyan Ivanov, 11.09.2020 12:08:04 +0300 |=-
> > I tried the "new upstream release" route because otherwise there 
> > would be several patches to import, one of them adding 10k-lines 
> > ppport.h
> > 
> > The result is at https://salsa.debian.org/dmn/perl-tk and builds with 
> > per 5.32. There are many lintian/hardening warnings, but since this is 
> > a NMU, the changes are bare minimum.
> > 
> > I haven't tested the resulting package yet, will have to find a way 
> > to do so without disturbing the rest of the system. (perhaps 
> > docker+vnc would help).
> 
> I got around to try this and the results seem acceptable to me.
> 
> All the examples seemed OK.
> 
> I tried two packages that depend on perl-tk: nama and mapivi.
> 
> nama seemed OK to me - no crashes, some windows appeared with menus 
> buttons etc.
> 
> mapivi worked OK as long as no unicode was involved. It is a JPEG 
> viewer with a file browser and unicode directory names are shown as 
> latin1 garbage. When trying to open such a directory it complains on 
> the console with 'Cannot cd to /path/to/spëcial: No such file or 
> directory at /usr/lib/x86_64-linux-gnu/perl5/5.32/Tk/DirTree.pm'. This 
> problem is also present in the version in unstable so it is not 
> a regression.

Excellent, thank you!
 
> Please tell me if there is another test I should perform.

That sounds very comprehensive to me.

> Would uploading to delayed-7 in a week or so be in line with the plans 
> for the arrival of 5.32 to unstable?

Ideally we were targeting the end of September for a transition, which
would potentially be delayed by your proposed timescale. But I don't
know how likely we are to hit that in reality (eg we're probably a week
away from having finished our current round of full QA rebuilds).

Meantime we should at least make sure that your version is in our
test repos so our mass rebuild has a chance to run on it. I'll do that
in the next couple of days.

So let's go ahead with your proposal, and if it comes a blocker, we can
consider rescheduling it.

Best
Dominic

[1] 

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#968912: transition: perl 5.32

[Dominic Hargreaves]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-p...@lists.debian.org

Hi, perl 5.32 has been in experimental since June and I think it's going
to be ready for sid/bullseye within the next month or so - this is the
version we expect to ship with bullseye (given the freeze in January).

The main blockers at present are the perl-tk update (I've just
pinged #960863) and, indirectly, the ipv6-only build related problems
described in #964902.

As usual the bugs are at
 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.32-transition;users=debian-p...@lists.debian.org

This is a somewhat early heads up, in case it's helpful to pencil us in,
but either way, we'll ping this bug again when the blockers are resolved.

Ben file:

title = "perl";
is_affected = .depends ~ "libperl5.30|perlapi-5.30" | .depends ~ 
"libperl5.32|perlapi-5.32";
is_good = .depends ~ "libperl5.32|perlapi-5.32";
is_bad = .depends ~ "libperl5.30|perlapi-5.30";

Thanks,
Dominic

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#960863: perl-tk: new upstream release fixes issues with Perl 5.31.x

[Dominic Hargreaves]

On Thu, Jun 25, 2020 at 09:44:56PM +0200, gregor herrmann wrote:
> Control: forwarded -1 https://github.com/eserte/perl-tk/pull/61
> Control: tag -1 + upstream fixed-upstream
> 
> On Sun, 17 May 2020 20:08:42 +0300, Niko Tyni wrote:
> 
> > Hi,
> > 
> > although Perl 5.32 is not released yet, we've just started early
> > testing against the archive during our online Debian Perl Sprint.
> > One of the issues we noticed is that the current perl-tk version in sid
> > is incompatible with newer versions of Perl, causing build failures with
> > perl-tk reverse dependencies.
> > 
> > The problem is fixed upstream in the 804.035 release according to
> > the changelog. Importing that into Debian would help our testing
> > efforts. Please consider doing that, and let us know if you'd like
> > any help.
> 
> Fixed upstream in
> https://github.com/eserte/perl-tk/commit/59dfbd147d894596b93f0a8dba5a5cf5af11ceaf
> which is in the current 804.035 release.
> 
> Perl 5.32 is already released upstream and uploded to
> Debian/experimental, so it would be nice to have perl-tk fixed
> soonish as well.

Hi Colin,

This is one of the few remaining blockers for the Perl 5.32 transition
which we'll need to get in in the next couple of months - will you be
able to take a look at updating perl-tk in the near future?

Thanks,
Dominic

Bug#968878: ITP: liblingua-stem-ru-perl -- Perl Russian Stemming

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 
X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org

* Package name: liblingua-stem-ru-perl
  Version : 0.04
  Upstream Author : Aleksandr Guidrevitch 
* URL : https://metacpan.org/release/Lingua-Stem-Ru
* License : Perl
  Programming Lang: Perl
  Description : Perl Russian stemming library

Lingua::Stemmer::Ru is an implementation of Porter's stemming algorithm
for Russian (KOI8-R only).
 
The algorithm is implemented exactly as described in:
http://snowball.tartarus.org/algorithms/russian/stemmer.html

It was previously packaged as part of liblingua-stem-perl, but bundling
packages is no longer a recommended approach. This package will
Break/Replace liblingua-stem-perl in the versions currently in unstable. 

Bug#968877: ITP: liblingua-stem-it-perl -- Perl Italian Stemming

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 
X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org

* Package name: liblingua-stem-it-perl
  Version : 0.02
  Upstream Author : Aldo Calpini, d...@perl.it
* URL : https://metacpan.org/release/Lingua-Stem-It
* License : Perl
  Programming Lang: Perl
  Description : Perl Italian stemming library

This module applies the Porter Stemming Algorithm to its parameters,
returning the stemmed words.

The algorithm is implemented as described in:
http://snowball.tartarus.org/algorithms/italian/stemmer.html

It was previously packaged as part of liblingua-stem-perl, but bundling
CPAN packages is no longer a recommended approach. This package will
Break/Replace liblingua-stem-perl in the versions currently in unstable. 

It will be maintained as part of the Debian Perl team.

Bug#968876: ITP: liblingua-stem-fr-perl -- Perl French Stemming

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: liblingua-stem-fr-perl
  Version : 0.02
  Upstream Author : Sébastien Darribere-Pleyt 
* URL : https://metacpan.org/release/Lingua-Stem-Fr
* License : Perl
  Programming Lang: Perl
  Description : Perl French stemming library

This module is an implementation of the Porter Stemming Algorithm
http://snowball.tartarus.org/french/stemmer.html,
with some improvements.

It was previously packaged as part of liblingua-stem-perl, but bundling
packages is no longer a recommended approach. This package will
Break/Replace liblingua-stem-perl in the versions currently in unstable. 

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#966396: debhelper: should invoke perl as /usr/bin/perl

[Dominic Hargreaves]

On Thu, Jul 30, 2020 at 03:09:43PM +0200, mat...@debian.org wrote:
> On Mon, Jul 27, 2020 at 11:17:37PM +0100, Dominic Hargreaves wrote:
> > > > This smells like a bug in debhelper to me - perl policy says that perl
> > > > should be /usr/bin/perl in shebangs, and I think the same should apply
> > > > here. I'm amazed this hasn't bit us before, if I'm right (it's been like
> > > > this since at least 2009, and probably forever).
> > > > 
> > > > https://salsa.debian.org/debian/debhelper/-/blob/master/lib/Debian/Debhelper/Buildsystem/perl_build.pm#L44
> > > 
> > > Yes, that was the problem. After "perlbrew off" it works as expected. It 
> > > is an old problem indeed.
> > > 
> > Filing this as a bug, with a proposed patch at
> > https://salsa.debian.org/debian/debhelper/-/merge_requests/40
> 
> may I disagree?
> I'll admit I never had to do it with perl, but every time people insists
> on using full paths overrinding a program by hacking on PATH suddenly
> becomes much harder.

I'm not persuaded by this argument. Debhelper is invoking perl in order
to build Debian packages, whose contents must be compatible with
/usr/bin/perl. Anyone hacking on something needing to change /usr/bin/perl
is already going to need to deal with replacing /usr/bin/perl in order
to test anything properly.

> As usual, one would expect that their build system is sane, having a
> non-working (or whatever was the problem there) `perl` during a build is
> very much the fault of the person controlling that system, not of
> debhelper.

Not at all. Whilst release builds of packages should of course be built
in clean environments, this is not a reason to break developer workflows
when people happen to use a different perl for day to day activities.

Dominic.

Bug#966396: debhelper: should invoke perl as /usr/bin/perl

[Dominic Hargreaves]

Package: debhelper
Version: 13.2
X-Debbugs-Cc: debian-p...@lists.debian.org

On Tue, Jul 21, 2020 at 03:38:05PM +0200, Stefan Hornburg (Racke) wrote:
> On 7/21/20 3:32 PM, Dominic Hargreaves wrote:
> > On Tue, Jul 21, 2020 at 11:54:50AM +0200, Stefan Hornburg (Racke) wrote:
> >> I'm trying to update a really old Debian package (safe-hole-perl) because 
> >> of bug
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965811.
> >>
> >> It uses Module::Build and is a XS module.
> >>
> >> Error message on build:
> >>
> >> dh binary
> >>dh_testroot
> >>dh_prep
> >>dh_auto_install
> >>perl Build install --destdir 
> >> /var/tmp/debaux-racke/safe-hole-perl/safe-hole-perl-0.14/debian/libsafe-hole-perl
> >> --create_packlist 0
> >> Building Safe-Hole
> >> WARNING: Can't figure out install path for types: arch lib
> >> Files will not be installed.
> >> Installing
> >> /var/tmp/debaux-racke/safe-hole-perl/safe-hole-perl-0.14/debian/libsafe-hole-perl/home/racke/perl5/perlbrew/perls/perl-5.30.0/man/man3/Safe::Hole.3
> > 
> > At a guess, the problem is related to the fact your perl is a perlbrew
> > one (see the install path above).
> > 
> > Does it work if you arrange for the perl in your path to be /usr/bin/perl?
> > 
> > This smells like a bug in debhelper to me - perl policy says that perl
> > should be /usr/bin/perl in shebangs, and I think the same should apply
> > here. I'm amazed this hasn't bit us before, if I'm right (it's been like
> > this since at least 2009, and probably forever).
> > 
> > https://salsa.debian.org/debian/debhelper/-/blob/master/lib/Debian/Debhelper/Buildsystem/perl_build.pm#L44
> > 
> > Dominic
> > 
> > 
> 
> Yes, that was the problem. After "perlbrew off" it works as expected. It is 
> an old problem indeed.
> 
> Thanks a lot (to Dominique as well) for the quick answer.

Filing this as a bug, with a proposed patch at
https://salsa.debian.org/debian/debhelper/-/merge_requests/40

Bug#962237: perl_5.28.1-6+deb10u1 uploaded

[Dominic Hargreaves]

Ouch - I just completely missed your previous response on this until
I was reminded by your rescheduling email today. Uploaded now, hope 
it's in time.

Best
Dominic

Bug#900739: crashing in toke.c, keyword plugin pointer is left pointing to an XS module that's been unloaded

[Dominic Hargreaves]

Thanks. The fix hasn't been integrated into the 5.24 maint branch so
any data we can have about it being battle tested is valuable.

Dominic.

On Thu, Jul 02, 2020 at 05:04:10PM -0700, Dean Hamstead wrote:
> We have been running it in prod since before the ticket was raised in
> debian. We were hoping to pull compiling perl out of our pipeline.
> 
> I would add again, that this is a fix from upstream and is included in all
> newer versions of perl.
> 
> 
> Dean
> 
> On 2020-07-02 15:05, Dominic Hargreaves wrote:
> > On Wed, Jul 01, 2020 at 05:07:33PM -0700, Dean Hamstead wrote:
> > > My preference would be to apply the patch as its a genuine bug fix
> > > from
> > > upstream.
> > 
> > Hi Dean
> > 
> > Thanks for the reply. We do just have a chance to get it into the final
> > stretch point release and we do have other changes queued for perl now.
> > You implied in an earlier message that you'd been running a patched
> > Debian package with https://github.com/Perl/perl5/issues/16086 - can
> > I check this is (still) the case? It'd give us a lot more confidence to
> > know that the combination we'd plan to release has been battle tested.
> > 
> > It's up to the stable release managers of course - I will email now.
> > 
> > Cheers
> > Dominic
> 

Bug#962234: stretch-pu: package perl/5.24.1-3+deb9u7

[Dominic Hargreaves]

On Mon, Jun 15, 2020 at 08:46:03PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2020-06-04 at 22:02 +0100, Dominic Hargreaves wrote:
> > Upstream released fixes for three regexp-related security issues
> > on Monday:
> > 
> > https://metacpan.org/pod/release/XSAWYERX/perl-5.28.3/pod/perldelta.pod
> > 
> > The Debian security team would like these as no-dsa, so we would like
> > to provide them in a point release. The patches have been trivially
> > backported from 5.28. See #962005.
> > 
> 
> Please go ahead.

Hi Adam

Sorry to add another perl release complication - we just had a bid made
on #900739 for another patch to be included in the update in stretch:

https://github.com/Perl/perl5/commit/fa2e45943e2b6ce22cf70dba5b47afe73c8c7c80

This was included in perl 5.28 and has been tested (I believe) in
5.24.


Cheers
Dominic

Bug#900739: crashing in toke.c, keyword plugin pointer is left pointing to an XS module that's been unloaded

[Dominic Hargreaves]

On Wed, Jul 01, 2020 at 05:07:33PM -0700, Dean Hamstead wrote:
> My preference would be to apply the patch as its a genuine bug fix from
> upstream.

Hi Dean

Thanks for the reply. We do just have a chance to get it into the final
stretch point release and we do have other changes queued for perl now.
You implied in an earlier message that you'd been running a patched
Debian package with https://github.com/Perl/perl5/issues/16086 - can
I check this is (still) the case? It'd give us a lot more confidence to
know that the combination we'd plan to release has been battle tested.

It's up to the stable release managers of course - I will email now.

Cheers
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