Bug#871731: libfile-nfslock-perl: FTBFS when debhelper does not export PERL_USE_UNSAFE_INC

[Dominic Hargreaves]

Source: libfile-nfslock-perl
Version: 1.27-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: debhelper-use-unsafe-inc-removal

This package FTBFS when debhelper is changed to not export
PERL_USE_UNSAFE_INC to the build environment. This export was added in
2016 at the same time that '.' was removed from INC by default, to
avoid breakage, but was a temporary change.

As well as allowing us to (eventually) remove this export from debhelper,
fixing this bug in your package will also help upstream, since this
change has been made in perl 5.26 upstream.

Additionally, it's possible that the problem may also exist at runtime
for your package (though from experience this is less likely).

Note that the rebuild testing was against a locally-modified version
of debhelper, but you can get the same effect by setting debhelper
compat level 11 in your package, which also removes the same
export.

For information about how to fix this class of issues, please refer
to the upstream release notes (in particular, 'Script authors' and
'Module Authors'):

http://perldoc.perl.org/perldelta.html#Removal-of-the-current-directory-(%22.%22)-from-%40INC

The relevant build failure logs are below:

Manifying 1 pod document
"/usr/bin/perl" "-Iblib/arch" "-Iblib/lib" File-NFSLock.spec.PL 
File-NFSLock.spec
do "Makefile.PL" failed, '.' is no longer in @INC; did you mean do 
"./Makefile.PL"? at File-NFSLock.spec.PL line 32.
Makefile.PL: Missing WriteMakefile at File-NFSLock.spec.PL line 36.

Please feel feel free to get in touch with the Debian Perl team at  
debian-p...@lists.debian.org if you need any more information or
assistance to fix this issue.  

Cheers,
Dominic.

Bug#871728: libdata-objectdriver-perl: FTBFS when debhelper does not export PERL_USE_UNSAFE_INC

[Dominic Hargreaves]

Source: libdata-objectdriver-perl
Version: 0.14-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: debhelper-use-unsafe-inc-removal

This package FTBFS when debhelper is changed to not export
PERL_USE_UNSAFE_INC to the build environment. This export was added in
2016 at the same time that '.' was removed from INC by default, to
avoid breakage, but was a temporary change.

As well as allowing us to (eventually) remove this export from debhelper,
fixing this bug in your package will also help upstream, since this
change has been made in perl 5.26 upstream.

Additionally, it's possible that the problem may also exist at runtime
for your package (though from experience this is less likely).

Note that the rebuild testing was against a locally-modified version
of debhelper, but you can get the same effect by setting debhelper
compat level 11 in your package, which also removes the same
export.

For information about how to fix this class of issues, please refer
to the upstream release notes (in particular, 'Script authors' and
'Module Authors'):

http://perldoc.perl.org/perldelta.html#Removal-of-the-current-directory-(%22.%22)-from-%40INC

The relevant build failure logs are below:

dh_auto_test
perl Build test --verbose 1
t/00-compile.t . 
1..2
ok 1 - use Data::ObjectDriver;
ok 2 - use Data::ObjectDriver::SQL;
ok
Can't locate t/lib/db-common.pl in @INC (@INC contains: t/lib 
/<>/blib/arch /<>/blib/lib /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at 
t/01-col-inheritance.t line 7.
t/01-col-inheritance.t . 
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
Can't locate t/lib/db-common.pl in @INC (@INC contains: t/lib/cached t/lib 
/<>/blib/arch /<>/blib/lib /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at t/02-basic.t 
line 8.
t/02-basic.t ... 
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
Can't locate t/lib/db-common.pl in @INC (@INC contains: t/lib/cached t/lib 
/<>/blib/arch /<>/blib/lib /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at 
t/03-primary-keys.t line 8.
t/03-primary-keys.t  
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
Can't locate t/lib/db-common.pl in @INC (@INC contains: t/lib/cached t/lib 
/<>/blib/arch /<>/blib/lib /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at t/04-clone.t 
line 8.
t/04-clone.t ... 
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
Can't locate t/lib/db-common.pl in @INC (@INC contains: t/lib/cached t/lib 
/<>/blib/arch /<>/blib/lib /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at t/05-deflate.t 
line 8.
t/05-deflate.t . 
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
Can't locate t/lib/db-common.pl in @INC (@INC contains: t/lib 
/<>/blib/arch /<>/blib/lib /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at t/06-errors.t 
line 6.
t/06-errors.t .. 
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
Can't locate t/lib/db-common.pl in @INC (@INC contains: t/lib/cached t/lib 
/<>/blib/arch /<>/blib/lib /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at 
t/07-has-a-cached.t line 8.
t/07-has-a-cached.t  
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
Can't locate t/lib/db-common.pl in @INC (@INC contains: t/lib/cached t/lib 
/<>/blib/arch /<>/blib/lib /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 

Bug#871729: libembperl-perl: FTBFS when debhelper does not export PERL_USE_UNSAFE_INC

[Dominic Hargreaves]

Source: libembperl-perl
Version: 2.5.0-11
Severity: normal
User: debian-p...@lists.debian.org
Usertags: debhelper-use-unsafe-inc-removal

This package FTBFS when debhelper is changed to not export
PERL_USE_UNSAFE_INC to the build environment. This export was added in
2016 at the same time that '.' was removed from INC by default, to
avoid breakage, but was a temporary change.

As well as allowing us to (eventually) remove this export from debhelper,
fixing this bug in your package will also help upstream, since this
change has been made in perl 5.26 upstream.

Additionally, it's possible that the problem may also exist at runtime
for your package (though from experience this is less likely).

Note that the rebuild testing was against a locally-modified version
of debhelper, but you can get the same effect by setting debhelper
compat level 11 in your package, which also removes the same
export.

For information about how to fix this class of issues, please refer
to the upstream release notes (in particular, 'Script authors' and
'Module Authors'):

http://perldoc.perl.org/perldelta.html#Removal-of-the-current-directory-(%22.%22)-from-%40INC

The relevant build failure logs are below:

PERL_DL_NONLAZY=0 "/usr/bin/perl" "-Iblib/lib" "-Iblib/arch" test.pl 

loading...do "test/conf/config.pl" failed, '.' is no longer 
in @INC; did you mean do "./test/conf/config.pl"? at test.pl line 1326.
Use of uninitialized value $EPSESSIONVERSION in pattern match (m//) at test.pl 
line 1332.
Use of uninitialized value $EPSESSIONVERSION in numeric ge (>=) at test.pl line 
1332.
Can't locate test/testapp.pl in @INC (@INC contains: /<>/blib/lib 
/<>/blib/arch /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0 
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at test.pl line 
1426.

Test terminated with fatal error

Please feel feel free to get in touch with the Debian Perl team at  
debian-p...@lists.debian.org if you need any more information or
assistance to fix this issue.  

Cheers,
Dominic.

Bug#826438: libtm-perl: Calling POSIX::tmpnam() is deprecated

[Dominic Hargreaves]

Control: severity -1 serious
Control: retitle -1 libtm-perl: FTBFS: Unimplemented: POSIX::tmpnam():

On Sun, Jun 05, 2016 at 06:07:45PM +0300, Niko Tyni wrote:
> Building this package triggers a deprecation warning with Perl 5.24
> (currently in experimental):
> 
>   Calling POSIX::tmpnam() is deprecated at t/095tau.t line 88.
>   t/095tau.t . ok
>   Calling POSIX::tmpnam() is deprecated at t/096taumapsphere.t line 76.
>   Calling POSIX::tmpnam() is deprecated at t/096taumapsphere.t line 77.
>   t/096taumapsphere.t  ok
>   t/100mapsphere.t ... ok
>   Calling POSIX::tmpnam() is deprecated at t/101mapsphere.t line 27.
>   t/101mapsphere.t ... ok

This is now causing the package to FTBFS with perl 5.26: see

http://perl.debian.net/rebuild-logs/experimental/libtm-perl_1.56-7/libtm-perl_1.56-7_amd64-2017-08-07T11:28:12Z.build

Cheers,
Dominic.

Bug#868945: Pending fixes for bugs in the libtest-redisserver-perl package

[Dominic Hargreaves]

On Wed, Jul 19, 2017 at 09:43:43PM +, 
pkg-perl-maintain...@lists.alioth.debian.org wrote:
> tag 868945 + pending
> thanks
> 
> Some bugs in the libtest-redisserver-perl package are closed in
> revision 4adcf585e374ed43e8dfe1e5a59885a809d99f85 in branch 'master'
> by Jonas Smedegaard
> 
> The full diff can be seen at
> https://anonscm.debian.org/cgit/pkg-perl/packages/libtest-redisserver-perl.git/commit/?id=4adcf58
> 
> Commit message:
> 
> Modernize cdbs: Do copyright-check in maintainer script (not during 
> build). Closes: Bug#868945. Thanks to Lucas Nussbaum.

Hi,

I don't believe this is the fix to this FTBFS bug; after all, the
package continues to build after licensecheck is not found.

Based on the log output in the bug report, this seems more relevant:

> cd  . && ./Build test  --verbose 1
> *** failed to launch redis-server ***
> 40903:C 19 Jul 12:00:56.265 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
> 40903:C 19 Jul 12:00:56.265 # Redis version=4.0.0, bits=64, commit=, 
> modified=0, pid=40903, just started
> 40903:C 19 Jul 12:00:56.265 # Configuration loaded
> 40903:M 19 Jul 12:00:56.266 * Increased maximum number of open files to 10032 
> (it was originally set to 1024).
> 40903:M 19 Jul 12:00:56.266 * Running mode=standalone, port=38665.
> 40903:M 19 Jul 12:00:56.266 # WARNING: The TCP backlog setting of 511 cannot 
> be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 
> 128.
> 40903:M 19 Jul 12:00:56.266 # Server initialized
> 40903:M 19 Jul 12:00:56.266 # WARNING overcommit_memory is set to 0! 
> Background save may fail under low memory condition. To fix this issue add 
> 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the 
> command 'sysctl vm.overcommit_memory=1' for this to take effect.
> 40903:M 19 Jul 12:00:56.266 # WARNING you have Transparent Huge Pages (THP) 
> support enabled in your kernel. This will create latency and memory usage 
> issues with Redis. To fix this issue run the command 'echo never > 
> /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your 
> /etc/rc.local in order to retain the setting after a reboot. Redis must be 
> restarted after THP is disabled.
> 40903:M 19 Jul 12:00:56.266 * Ready to accept connections
> 40903:signal-handler (1500465702) Received SIGTERM scheduling shutdown...
> 40903:M 19 Jul 12:01:42.859 # User requested shutdown...
> 40903:M 19 Jul 12:01:42.859 # Redis is now ready to exit, bye bye...
>  at t/basic.t line 28.
> # Tests were run but no plan was declared and done_testing() was not seen.
> # Looks like your test exited with -1 just after 6.
> t/basic.t . 

Cheers,
Dominic.

Bug#836110: Remove export of PERL_USE_UNSAFE_INC in the future

[Dominic Hargreaves]

On Fri, Jul 07, 2017 at 12:00:36AM +0100, Dominic Hargreaves wrote:
> On Thu, Jun 29, 2017 at 12:06:21PM +0100, Dominic Hargreaves wrote:

> > Sorry about this. At this stage I think it might be better to wait
> > until perl 5.26 has transitioned, so we can reassess all the various
> > breakages without the local modifications that we introduced for 5.24.
> > 
> > I think a transition bug will be opened soon, so this shouldn't delay
> > by more than another couple of months, which should be acceptable for 
> > the buster release?
> 
> (For the bug record).
> 
> Niels removed this from debhelper compat 11:
> 
> https://anonscm.debian.org/git/debhelper/debhelper.git/tree/debhelper.pod#n683
> 
> but I don't this changes my plan above to push on this after the
> perl 5.26 transition is underway. It means that module maintainers
> can move to debhelper 11 as a way to verify whether their packages
> need properly fixing.

Hi,

I've now started this rebuild, and the results are appearing on gobby:


<https://gobby.debian.org/export/Teams/Perl/Perl-debhelper-unsafe-inc-QA>

I propose to file bugs on affected packages: do you think that the
wording below is okay? I'm guessing severity: normal is appropriate
for now, since there is no great hurry to remove the export?

"This package FTBFS when built with a locally-patched version of
debhelper without USE_UNSAFE_INC exported to the build environment.
This export was added in 2016 in order to accommodate the perl security
release to remove '.' in @INC by default.

As well as allowing us to (eventually) remove this temporary
fix from debhelper, fixing this bug will also help upstreams, since
their users using perl 5.26 will also experience this breakage.
Additionally, it's possible that the problem may also exist at runtime
for your package (though from experience this is less likely).

Note that the testing was against a locally-modified version
of debhelper, but you can get the same effect by setting debhelper
compat level 11 in your package, which also removes the same
export.

The relevant build failure logs are below."

Cheers,
Dominic.

Bug#870964: [request-tracker-maintainers] Bug#870964: rt-extension-assettracker: should rt-extension-assettracker be removed from unstable?

[Dominic Hargreaves]

reassign 870964 ftp.debian.org
retitle 870964 RM: rt-extension-assettracker -- RoM; obsolete since 
request-tracker4.2
thanks

On Sun, Aug 06, 2017 at 09:50:12AM -0400, Lucas Nussbaum wrote:
> Following a discussion[1] on the debian-qa@ mailing list on packages that
> missed both jessie and stretch, I am proposing the removal of this package 
> from
> unstable, because:
> 
>   it was in unstable at the time of the stretch freeze
> but wasn't part of stretch
> AND
>   it was in unstable at the time of the jessie freeze
> but it wasn't part of jessie
> AND
>   it is still not in testing
> AND
>   it was not uploaded since the beginning of 2017.
> 
> If you disagree and think that this package should remain in unstable, feel
> free to just close this bug.
> 
> If this bug is still open one month from now (on 2017-09-06), it will be 
> turned
> into a removal request, using:
> 
>   reassign -1 ftp.debian.org
>   retitle -1 RM: rt-extension-assettracker -- RoQA; missed both jessie and 
> stretch
>   thanks

This was certainly the intention; this package is obsolete, so I'm
requesting its removal now.

Thank you for your work on this and QA in general!

Cheers,
Dominic.

Bug#869994: perl5.26 update: postgresql databases cannot be viewed using browser

[Dominic Hargreaves]

Control: retitle -1 sql-ledger: Can't locate bin/mozilla/login.pl in @INC

On Fri, Jul 28, 2017 at 10:37:38AM -0400, gregor herrmann wrote:
> On Fri, 28 Jul 2017 14:45:11 +0100, Neil Redgate wrote:
> 
> Thanks for your detailed bug report!
> 
> > I can no longer access my postgressql database using any web browser for the
> > sql-ledger 3.2.4 package.
> 
> > [Fri Jul 28 13:45:40.995556 2017] [cgi:error] [pid 6345] [client ::1:40496] 
> > End
> > of script output before headers: admin.pl
> > [Fri Jul 28 13:46:12.133989 2017] [cgi:error] [pid 6231] [client ::1:40500]
> > AH01215: Can't locate bin/mozilla/login.pl in @INC (@INC contains: /etc/perl
> > /usr/local/lib/x86_64-linux-gnu/perl/5.26.0 /usr/local/share/perl/5.26.0
> > /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-
> > gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl
> > /usr/lib/x86_64-linux-gnu/perl-base) at /usr/local/sql-ledger/login.pl line
> > 119.: /usr/local/sql-ledger/login.pl
> > [Fri Jul 28 13:46:12.134085 2017] [cgi:error] [pid 6231] [client ::1:40500] 
> > End
> > of script output before headers: login.pl
> 
> I'm afraid there's not much we can do here. /etc/perl/sitecustomize.pl
> was a temporary workaround which is gone for good now.
> 
> It seems that you are using sql-ledger 3.2.4 which is not packaged in
> Debian and installed in /usr/local/sql-ledger, and that this version
> is not updated to work with Perl 5.26. (I had a brief look at 3.2.5
> and it looks like it still does the same "do $file").
> 
> https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/perldelta.pod#Removal-of-the-current-directory-%28%22.%22%29-from-@INC
> has background information and a couple of suggestions to remedy the
> situation which you can try yourself and/or suggest to the sql-ledger
> upstream authors.
> 
> (Not closing the bug report yet in case the perl maintainers have
> something to add.)

Thanks gregoa for your investigation/response. I can confirm that I don't
think we can do anything here, unfortunately, as (after around a year)
we have indeed removed the workaround to enable potentially unsafe
operation.

I noticed that we do have an sql-ledger package in Debian, but that
hasn't been updated since before the @INC fix was made, so it's quite
likely to also be completely broken there.

The next steps for this bug report are to check whether the sql-ledger
package has the same problem, and if so reassign it. If the answer is
no, then that might at least point the way towards a resolution for the
reporter.

Cheers,
Dominic.

Bug#869653: Local path for modules not included any more

[Dominic Hargreaves]

Control: tags -1 + moreinfo

On Tue, Jul 25, 2017 at 01:10:16PM +0200, Karsten wrote:
> Package: perl
> Version: 5.24.1-3+deb9u1
> Severity: normal
> 
> Hello,
> 
> suddenly my perl scripts will not find modules in the local path anymore.
> Is this a bug or a new feature?
> 
> 
> Error message:
> 
> Can't locate mymodule.pm in @INC (you may need to install the haarpconfig 
> module) (@INC contains: /etc/perl
> /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 
> /usr/lib/x86_64-linux-gnu/perl5/5.24
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 
> /usr/local/lib/site_perl
> /usr/lib/x86_64-linux-gnu/perl-base) at ./myscript.pl line 61.
> BEGIN failed--compilation aborted at ./myscript.pl line 61.
> 
> 
> Now for every script that uses modules in the local path the path have to be 
> defined like:
> use lib "/path/to/local/modules"; # 
> http://perldoc.perl.org/perlrun.html#ENVIRONMENT

Hi,

I suspect you are talking about a change in behaviour in perl from
jessie to stretch (Debian 8 to Debian 9) which was documented here.

https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#perl

(the second point in that list). In other words, this probably isn't a
bug.

However, if you believe that this happened between 5.24.1-3 and
5.24.1-3+deb9u1, please let us know together with an example script
which used to work and now doesn't.

Thanks,
Dominic.

Bug#869641: [request-tracker-maintainers] Bug#869641: "encountered object '1', but neither allow_blessed[..]" upon login

[Dominic Hargreaves]

Control: severity -1 important
Control: forcemerge 848041 -1

On Tue, Jul 25, 2017 at 08:44:49AM +, Peter Palfrader wrote:
> Package: request-tracker4
> Version: 4.4.1-3+deb9u2
> Severity: grave
> 
> Hi,
> 
> I just upgraded an RT instance from jessie to stretch.
> 
> Immediately upon login I get
> 
> | An internal RT error has occurred. Your administrator can find more details 
> in RT's log files.
> 
> and this in my logs:
> 
> |[11788] [Tue Jul 25 08:40:12 2017] [error]: encountered object '1', but 
> neither allow_blessed, convert_blessed nor allow_tags settings are enabled 
> (or TO_JSON/FREEZE method missing) at /usr/share/perl5/JSON.pm line 154.
> |
> |Stack:
> |  [/usr/share/perl5/JSON.pm:154]
> |  [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:193]
> |  [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:4396]
> |  [/usr/share/request-tracker4/html/Elements/JavascriptConfig:87]
> |  [/usr/share/request-tracker4/html/Elements/Header:64]
> |  [/usr/share/request-tracker4/html/index.html:4]
> |  [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:696]
> |  [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:375]
> |  [/usr/share/request-tracker4/html/autohandler:53] 
> (/usr/share/request-tracker4/lib/RT/Interface/Web/Handler.pm:209)

Hi,

This is #848041, merging.

I believe this is a combination of mod_perl + libjson-xs-perl and that
removing libjson-xs-perl from your system should fix the issue.

Does this work for you as a workaround/solution?

Thanks,
Dominic.

Bug#867490: stretch-pu: package perl/5.24.1-3+deb9u1

[Dominic Hargreaves]

On Mon, Jul 10, 2017 at 09:41:00PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2017-07-06 at 20:52 +0100, Dominic Hargreaves wrote:
> > We would like to apply the following fixes to perl in stretch for the
> > next point release:
> > 
> >   * Backport various Getopt-Long fixes from upstream 2.49..2.51.
> > (Closes: #855532, #864544)
> >   * Backport upstream patch fixing regexp "Malformed UTF-8 character"
> > crashes. (Closes: #864782)
> >   * Apply upstream base.pm no-dot-in-inc fix (from 5.24.2-RC1)
> > (Closes: #867170)
> 
> Please go ahead.

Thanks, done.

Dominic.

Bug#864745: jessie-pu: package perl/5.20.2-3+deb8u6

[Dominic Hargreaves]

On Mon, Jul 10, 2017 at 09:24:11PM +0100, Adam D. Barratt wrote:
> Control; tags -1 + confirmed
> 
> On Wed, 2017-06-14 at 00:14 +0100, Dominic Hargreaves wrote:
> > In July 2016 we released a security update for perl to fix an optional
> > module loading related vulnerability:
> > 
> > https://www.debian.org/security/2016/dsa-3628
> > 
> > This update included a change that has been since improved by upstream
> > for better compatibility with existing code. The original update caused
> > a few packages to FTBFS:
> > 
> > #864302
> > #864299
> > #832862
> > #832866
> > #832845
> > 
> > As such we believe that it makes sense to update perl in jessie to
> > include the improved fix, which is scheduled for inclusion in upstream
> > maintenance releases soon.
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Thanks, done.

Dominic.

Bug#864745: Update on base.pm jessie point release

[Dominic Hargreaves]

On Thu, Jul 06, 2017 at 09:01:21PM +0200, Cyril Brulebois wrote:
> Dominic Hargreaves <d...@earth.li> (2017-07-06):
> > + debian-perl as it possible affects how we deal with FTBFS module
> > packages.
> > 
> > On Wed, Jul 05, 2017 at 07:46:39AM +0200, Cyril Brulebois wrote:
> > > Hi Dominic,
> > > 
> > > Dominic Hargreaves <d...@earth.li> (2017-07-04):
> > > > 1) this commit is identical to those now in upstream release
> > > >candidates.
> > > > 2) This has now been filed as #867164 (sorry that this was missing
> > > >before)
> > > 
> > > Thanks for the update, much appreciated.
> > > 
> > > I have to say that giving you a green light to update perl in stable
> > > with this kind of fix makes me a little nervous, sorry. :(
> > 
> > Okay, it would be useful to know in a bit more detail why you think
> > this, as it doesn't seem any different from other similar fixes to
> > perl we have requested in the past (and we've learnt our lesson from
> > lack of mass rebuild testing where that was an issue previously)
> 
> Well, I'm not the one having accepted past proposed-updates, and since
> I've been active on quite a number of {jessie,stretch}-pu requests over
> the past few weeks, that was mainly a hint for other release team
> members that I wasn't going to green or red light this request myself.
> 
> > But anyway, there are two options:
> > 
> > 1) proceed with the update as proposed. This should be fairly low risk
> > since we have test-rebuilt all packages build-depending on perl and found
> > no regressions, and the problem it is fixing only affected a handful
> > of unusual cases. Given the lack of bug reports, I assume the imperfect
> > base.pm change hasn't actually affected anyone in the real world, but of
> > course that might be a rash assumption.
> > 
> > 2) work around the problem by patching away the issue like we have
> > for stretch in the half dozen or so affected packages. This would leave
> > jessie's perl in a slightly awkward state in carrying around for the
> > rest of its days a patch that was rejected by upstream in favour
> > of another one. But in practice it may not make all that difference.
> > And probably the risk in doing this is slightly less in not touching a
> > core package, though it is a bit more work.
> > 
> > Overall I'm in favour of 1) but happy to defer to you. Does anyone
> > else in pkg-perl have an opinion on this?
> 
> I see a third one:
> 
> 0) Wait from someone else from the release team to comment on this.
> 
> 
> Hope this clarifies.

That makes perfect sense, sorry for the misunderstanding!

Dominic.

Bug#836110: Remove export of PERL_USE_UNSAFE_INC in the future

[Dominic Hargreaves]

On Thu, Jun 29, 2017 at 12:06:21PM +0100, Dominic Hargreaves wrote:
> On Tue, Jun 27, 2017 at 08:55:00AM +, Niels Thykier wrote:
> > On Sat, 3 Dec 2016 14:12:53 +0000 Dominic Hargreaves <d...@earth.li> wrote:
> > > [...]
> > > 
> > > Hi Niels,
> > > 
> > > (and sorry about the silence).
> > > 
> > > No, not yet. That will need a full rebuild with the debhelper change
> > > reverted, and I'm unlikely to have time to do that until the new year.
> > > 
> > > Cheers,
> > > Dominic.
> > > 
> > > 
> > 
> > Ping. :)
> > 
> > I was reminded of this due to a related chat on #d-perl today. :)
> 
> Hi Niels,
> 
> Sorry about this. At this stage I think it might be better to wait
> until perl 5.26 has transitioned, so we can reassess all the various
> breakages without the local modifications that we introduced for 5.24.
> 
> I think a transition bug will be opened soon, so this shouldn't delay
> by more than another couple of months, which should be acceptable for 
> the buster release?

(For the bug record).

Niels removed this from debhelper compat 11:

https://anonscm.debian.org/git/debhelper/debhelper.git/tree/debhelper.pod#n683

but I don't this changes my plan above to push on this after the
perl 5.26 transition is underway. It means that module maintainers
can move to debhelper 11 as a way to verify whether their packages
need properly fixing.

Thanks Niels!

Dominic.

Bug#867490: stretch-pu: package perl/5.24.1-3+deb9u1

[Dominic Hargreaves]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

We would like to apply the following fixes to perl in stretch for the
next point release:

  * Backport various Getopt-Long fixes from upstream 2.49..2.51.
(Closes: #855532, #864544)
  * Backport upstream patch fixing regexp "Malformed UTF-8 character"
crashes. (Closes: #864782)
  * Apply upstream base.pm no-dot-in-inc fix (from 5.24.2-RC1)
(Closes: #867170)

Hopefully the bug reports provide all the relevant context. The
jessie-pu bug #864745 is somewhat related as the third change above
is also being proposed there; the others are regressions from jessie
which appeared in stretch.

Thanks,
Dominic.
diff --git a/MANIFEST b/MANIFEST
index e4331f1..e6a3dd9 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -3007,6 +3007,7 @@ dist/base/t/fields-5_6_0.tSee if fields work
 dist/base/t/fields-5_8_0.t See if fields work
 dist/base/t/fields-base.t  See if fields work
 dist/base/t/fields.t   See if fields work
+dist/base/t/incdot.t   Test how base.pm handles '.' in @INC
 dist/base/t/isa.t  See if base's behaviour doesn't change
 dist/base/t/lib/Broken.pm  Test module for base.pm
 dist/base/t/lib/Dummy.pm   Test module for base.pm
diff --git a/cpan/Getopt-Long/lib/Getopt/Long.pm 
b/cpan/Getopt-Long/lib/Getopt/Long.pm
index fdc96bd..e71fee8 100644
--- a/cpan/Getopt-Long/lib/Getopt/Long.pm
+++ b/cpan/Getopt-Long/lib/Getopt/Long.pm
@@ -1110,10 +1110,29 @@ sub FindOption ($) {
 
 # Check if there is an option argument available.
 if ( $gnu_compat ) {
-   my $optargtype = 0; # 0 = none, 1 = empty, 2 = nonempty
-   $optargtype = ( !defined($optarg) ? 0 : ( (length($optarg) == 0) ? 1 : 
2 ) );
-   return (1, $opt, $ctl, undef)
- if (($optargtype == 0) && !$mand);
+   my $optargtype = 0; # none, 1 = empty, 2 = nonempty, 3 = aux
+   if ( defined($optarg) ) {
+   $optargtype = (length($optarg) == 0) ? 1 : 2;
+   }
+   elsif ( defined $rest || @$argv > 0 ) {
+   # GNU getopt_long() does not accept the (optional)
+   # argument to be passed to the option without = sign.
+   # We do, since not doing so breaks existing scripts.
+   $optargtype = 3;
+   }
+   if(($optargtype == 0) && !$mand) {
+   if ( $type eq 'I' ) {
+   # Fake incremental type.
+   my @c = @$ctl;
+   $c[CTL_TYPE] = '+';
+   return (1, $opt, \@c, 1);
+   }
+   my $val
+ = defined($ctl->[CTL_DEFAULT]) ? $ctl->[CTL_DEFAULT]
+ : $type eq 's' ? ''
+ :0;
+   return (1, $opt, $ctl, $val);
+   }
return (1, $opt, $ctl, $type eq 's' ? '' : 0)
  if $optargtype == 1;  # --foo=  -> return nothing
 }
@@ -2322,11 +2341,14 @@ do. Without C, C<--opt=> gives an error. 
With C,
 C<--opt=> will give option C and empty value.
 This is the way GNU getopt_long() does it.
 
+Note that C<--opt value> is still accepted, even though GNU
+getopt_long() doesn't.
+
 =item gnu_getopt
 
 This is a short way of setting C C C
 C. With C, command line handling should be
-fully compatible with GNU getopt_long().
+reasonably compatible with GNU getopt_long().
 
 =item require_order
 
diff --git a/debian/.git-dpm b/debian/.git-dpm
index e62f968..28b4395 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-641936971e243d39e8eee510824e076c75965fc6
-641936971e243d39e8eee510824e076c75965fc6
+ceaa6f3d1fd7942ad1de321197030bb2306bd7ec
+ceaa6f3d1fd7942ad1de321197030bb2306bd7ec
 13beb365bfa6ab6c49c061bd55769bf272a5e1bf
 13beb365bfa6ab6c49c061bd55769bf272a5e1bf
 perl_5.24.1.orig.tar.xz
diff --git a/debian/changelog b/debian/changelog
index c48cff7..d05b73a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+perl (5.24.1-3+deb9u1) UNRELEASED; urgency=medium
+
+  * Backport various Getopt-Long fixes from upstream 2.49..2.51.
+(Closes: #855532, #864544)
+  * Backport upstream patch fixing regexp "Malformed UTF-8 character"
+crashes. (Closes: #864782)
+  * Apply upstream base.pm no-dot-in-inc fix (from 5.24.2-RC1)
+(Closes: #867170)
+
+ -- Dominic Hargreaves <d...@earth.li>  Fri, 23 Jun 2017 21:31:26 +0100
+
 perl (5.24.1-3) unstable; urgency=high
 
   * [CVE-2017-6512] Fix file permissions race condition in File-Path;
diff --git a/debian/patches/debian/CVE-2016-1238/base-pm-amends-pt2.diff 
b/debian/patches/debian/CVE-2016-1238/base-pm-amends-pt2.diff
new file mode 100644
index 000..fd44d21
--- /dev/null
+++ b/debian/patches/debian/CVE-2016-1238/base-pm-amends-pt2.diff
@@ -0,0 +1,206 @@
+From ceaa6f3d1fd7942ad1de321197030bb2306bd7ec Mon Sep 17 00:00:00 2001
+From: Aristotle Pagaltzis <pagalt...@gmx.

Bug#864745: Update on base.pm jessie point release

[Dominic Hargreaves]

+ debian-perl as it possible affects how we deal with FTBFS module
packages.

On Wed, Jul 05, 2017 at 07:46:39AM +0200, Cyril Brulebois wrote:
> Hi Dominic,
> 
> Dominic Hargreaves <d...@earth.li> (2017-07-04):
> > 1) this commit is identical to those now in upstream release candidates.
> > 2) This has now been filed as #867164 (sorry that this was missing before)
> 
> Thanks for the update, much appreciated.
> 
> I have to say that giving you a green light to update perl in stable with this
> kind of fix makes me a little nervous, sorry. :(

Okay, it would be useful to know in a bit more detail why you think this,
as it doesn't seem any different from other similar fixes to perl we
have requested in the past (and we've learnt our lesson from lack of
mass rebuild testing where that was an issue previously)

But anyway, there are two options:

1) proceed with the update as proposed. This should be fairly low risk
since we have test-rebuilt all packages build-depending on perl and found
no regressions, and the problem it is fixing only affected a handful
of unusual cases. Given the lack of bug reports, I assume the imperfect
base.pm change hasn't actually affected anyone in the real world, but of
course that might be a rash assumption.

2) work around the problem by patching away the issue like we have
for stretch in the half dozen or so affected packages. This would leave
jessie's perl in a slightly awkward state in carrying around for the
rest of its days a patch that was rejected by upstream in favour
of another one. But in practice it may not make all that difference.
And probably the risk in doing this is slightly less in not touching a
core package, though it is a bit more work.

Overall I'm in favour of 1) but happy to defer to you. Does anyone
else in pkg-perl have an opinion on this?

> > 3) this particular bug doesn't strictly apply to stretch/sid, but we plan
> >to fix it in sid at least for consistency and to fix the minor remaining
> >security bug (see #867170)
> 
> I'm not sure how we feel about similar-yet-kind-of-different bugs in
> other suites (as in: not sure whether fixing those would be considered
> a hard requirement before an update in (old)stable).

Even if you reject the patch for jessie, I hope you will consider it
in stretch, as there is actually fixes a minor security issue (in due
course it will end up in a new upstream point release, and it's quite
likely we'll want a wholesale upgrade to that anyway).

Indeed, if that would also make you uncomfortable we should discuss
that in more detail...

I will aim to get the s-p-u bug for that filed soon.

Thanks,
Dominic.

Bug#865225: stretch-pu: package request-tracker4/4.4.1-3+deb9u2

[Dominic Hargreaves]

On Sun, Jul 02, 2017 at 11:18:43PM +0200, Cyril Brulebois wrote:
> Hi,
> 
> Dominic Hargreaves <d...@earth.li> (2017-06-27):
> > Sorry, this is not yet uploaded. I somehow got this and the anope
> > bug mixed up.
> 
> Alright, no worries; for the avoidance of doubt, I can't spot any
> uploads of the request-tracker4 package to stretch at the moment.

Should be there now :)

Bug#867164: perl: base.pm change causes other packages to FTBFS

[Dominic Hargreaves]

On Tue, Jul 04, 2017 at 12:53:01PM +0100, Dominic Hargreaves wrote:
> It was discovered that the security fix from last summer caused various
> packages to FTBFS during unrelated QA work:
> 
> request-tracker4_4.2.8-3+deb8u1
> libgraph-writer-dsm-perl_0.006-1
> libclass-c3-xs-perl_0.13-2
> libclass-c3-perl_0.26-1
> libbio-das-lite-perl_2.04-1.1
> 
> This was caused by an early version of a security fix in base.pm
> which was not released by upstream because of these compatibility problems.
> 
> In stretch/sid these packages have been patched to work around the problem;
> it was an oversight that similar workarounds didn't get made in jessie.
> 
> Now that there is an improved patch available from upstream which fixes
> this regression (currently in the 5.24.2-RC1 and 5.22.4-RC1 releases) we
> should apply this in jessie and (for completeness) stretch point releases,
> as well as sid.

This is being tracked for jessie as release team bug #864745.

Dominic.

Bug#864745: Update on base.pm jessie point release

[Dominic Hargreaves]

Just to confirm that

1) this commit is identical to those now in upstream release candidates.
2) This has now been filed as #867164 (sorry that this was missing before)
3) this particular bug doesn't strictly apply to stretch/sid, but we plan
   to fix it in sid at least for consistency and to fix the minor remaining
   security bug (see #867170)

Thanks,
Dominic.

Bug#867170: perl: lingering base.pm vulnerability in stretch+sid

[Dominic Hargreaves]

Source: perl
Version: 5.24.1~rc5-1
Severity: important

In 5.24.1~rc5-1 the previous base.pm change was reverted because it
broke compatibility. This leaves a lingering potential security issue
(not very exposed because '.' is removed from @INC by default, but
still theoretically there).

Both to fix the lingering security issue, and for consistency with
other releases (see #867164) we should apply the new version of
the base.pm fix descibed there sid (and probably stretch too).

Bug#867164: perl: base.pm change causes other packages to FTBFS

[Dominic Hargreaves]

Source: perl
Version: 5.20.2-3+deb8u6
Severity: serious
Justification: causes other packages to FTBFS
Tags: jessie upstream fixed-upstream

It was discovered that the security fix from last summer caused various
packages to FTBFS during unrelated QA work:

request-tracker4_4.2.8-3+deb8u1
libgraph-writer-dsm-perl_0.006-1
libclass-c3-xs-perl_0.13-2
libclass-c3-perl_0.26-1
libbio-das-lite-perl_2.04-1.1

This was caused by an early version of a security fix in base.pm
which was not released by upstream because of these compatibility problems.

In stretch/sid these packages have been patched to work around the problem;
it was an oversight that similar workarounds didn't get made in jessie.

Now that there is an improved patch available from upstream which fixes
this regression (currently in the 5.24.2-RC1 and 5.22.4-RC1 releases) we
should apply this in jessie and (for completeness) stretch point releases,
as well as sid.

Upstream commit:

https://perl5.git.perl.org/perl.git/commit/1afa2890005f3acdb5794bc9ec34dfd0a7e54c28

with additional documentation in later commits:

https://perl5.git.perl.org/perl.git/shortlog/refs/heads/maint-5.24

Bug#866389: transition: perl 5.26

[Dominic Hargreaves]

On Sun, Jul 02, 2017 at 05:01:20PM +0200, gregor herrmann wrote:
> On Fri, 30 Jun 2017 12:39:09 +0200, Emilio Pozuelo Monfort wrote:
> 
> > We need to distinguish among blockers and non-blockers in that list. E.g.,
> > "fails to run with perl 5.26" is a blocker, but "uses a deprecated feature" 
> > is
> > not. 
> 
> Just for clarification, most of the bugs which have "deprecated" in
> the title will fail to run with 5.26; IOW: the warnings are from
> 5.24, and in 5.26 the issues become fatal.

I've retitled those bugs would could be confusing in this regard. I
believe that all the bugs which severity: important are the ones which
would become RC when we decide we want to start soon.

Noting for completeness that Niko has added the other lockers on
architecture: all related FTBFS bugs as requested by Emilio.

Cheers,
Dominic.

Bug#866389: transition: perl 5.26

[Dominic Hargreaves]

On Thu, Jun 29, 2017 at 03:07:39PM +0300, Niko Tyni wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-p...@lists.debian.org
> 
> We'd like to get Perl 5.26 in sid/buster soonish.
> 
> As usual, we've done test rebuilds of packages build dependending on perl.
> Things are looking pretty good. Known issues are at
> 
>  
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.26-transition;users=debian-p...@lists.debian.org
> 
> and should be marked as blockers of this bug next.

Previously we only used blockers to track FTBFS in packages needing
binNMUing - so far I have just added those. I think it probably makes
sense to keep with that, as the above link give you the full picture
when needed.

> We'll ping this bug when things are ready, but please let us know if
> you have any preference about the timing.

Indeed, it might be worth having debconf as a target?

> It might be prudent to decouple the move to versioned Provides (see
> #758100 and the thread at [1]) from the rest of the transition and do
> it with 5.24 in sid first. I hope to have time for that next week.
> 
>  [1] https://lists.debian.org/debian-devel/2017/06/msg00236.html

+1 to that!

Cheers,
Dominic.

Bug#836110: Remove export of PERL_USE_UNSAFE_INC in the future

[Dominic Hargreaves]

On Tue, Jun 27, 2017 at 08:55:00AM +, Niels Thykier wrote:
> On Sat, 3 Dec 2016 14:12:53 +0000 Dominic Hargreaves <d...@earth.li> wrote:
> > [...]
> > 
> > Hi Niels,
> > 
> > (and sorry about the silence).
> > 
> > No, not yet. That will need a full rebuild with the debhelper change
> > reverted, and I'm unlikely to have time to do that until the new year.
> > 
> > Cheers,
> > Dominic.
> > 
> > 
> 
> Ping. :)
> 
> I was reminded of this due to a related chat on #d-perl today. :)

Hi Niels,

Sorry about this. At this stage I think it might be better to wait
until perl 5.26 has transitioned, so we can reassess all the various
breakages without the local modifications that we introduced for 5.24.

I think a transition bug will be opened soon, so this shouldn't delay
by more than another couple of months, which should be acceptable for 
the buster release?

Cheers,
Dominic.

Bug#865225: stretch-pu: package request-tracker4/4.4.1-3+deb9u2

[Dominic Hargreaves]

On Tue, Jun 27, 2017 at 05:25:45AM +0200, Cyril Brulebois wrote:
> Hi Dominic,
> 
> Dominic Hargreaves <d...@earth.li> (2017-06-26):
> > Thanks, uploaded.
> 
> I only see the security update (4.4.1-3+deb9u1), but not the package for
> this pu request (4.4.1-3+deb9u2). Did the upload go through properly, to
> the regular archive rather than the security one?

Sorry, this is not yet uploaded. I somehow got this and the anope
bug mixed up.

Bug#865898: perl: EU::MM regression in 5.26 breaks erlsvc build

[Dominic Hargreaves]

Control: reassign -1 erlsvc
Control: retitle -1 erlsvc: FTBFS with perl 5.26 (Extutils::MakeMaker 
compatibility)

On Mon, Jun 26, 2017 at 11:17:20PM +0100, Dominic Hargreaves wrote:
> On Sun, Jun 25, 2017 at 08:37:10PM +0300, Niko Tyni wrote:
> > Package: perl
> > Version: 5.26.0-1
> > Severity: important
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.26-transition
> > Forwarded: 
> > https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/305
> > Affects: erlsvc
> > X-Debbugs-Cc: erl...@packages.debian.org
> > 
> > It looks like a regression in recent versions of ExtUtils-MakeMaker,
> > including the one bundled with Perl 5.26.0 currently in experimental,
> > broke the erlsvc build. I'm copying the erlsvc maintainer FYI, but it's
> > not yet clear where this needs to be fixed.
> > 
> > A full build log is at
> > 
> >  
> > http://perl.debian.net/rebuild-logs/perl-5.26-throwaway/erlsvc_1.02-2/erlsvc_1.02-2_amd64-2017-05-22T00:32:44Z.build
> > 
> > and the failure mode is
> > 
> >   dh_auto_test
> >make -j1 test TEST_VERBOSE=1
> >make[1]: Entering directory '/<>'
> >make[2]: Entering directory '/<>/share'
> >make[2]: Nothing to be done for 'all'.
> >make[2]: Leaving directory '/<>/share'
> >make[2]: Entering directory '/<>/share'
> >make[2]: *** No rule to make target 'test_dynamic'.  Stop.
> >make[2]: Leaving directory '/<>/share'
> >Makefile:918: recipe for target 'subdirs-test_dynamic' failed
> >make[1]: *** [subdirs-test_dynamic] Error 2
> >make[1]: Leaving directory '/<>'
> >dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2
> >debian/rules:4: recipe for target 'build' failed
> >
> > As noted in the upstream bug, I've bisected that this started with 
> >  
> > https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/0c38f3739cb7476fc1b843484584fee30c9ea69e
> > and still happens with current HEAD.
> 
> Upstream seems to think that this is a problem with erlsvc, which I
> tend to agree with, so probably this just be reassigned?

Doing so now. Maintainers, the upstream issue at

https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/305

has some useful suggestion about how to modernise Makefile.PL et al
to resolve this.

Cheers,
Dominic.

Bug#865563: libcatmandu-sru-perl FTBFS: test failures

[Dominic Hargreaves]

Control: clone -1 -2
Control: reassign -2 cdbs
Control: retitle -2 cdbs: perl Build.PL -I. doesn't have the intended effect

On Tue, Jun 27, 2017 at 01:31:15AM +0200, Jonas Smedegaard wrote:
> Hmm - I guess the special code in Module::Build checks for . only at the 
> _end_ (or beginning?) of the INC list, and the difference of how 
> debhelper and cdbs applies the option affects the order.
> 
> I will adjust the code in CDBS, but I believe that to be only a 
> workaround and it should be fixed in Module::Build (as a patch in 
> Debian, if upstream chooses to dismiss it).

This aspect has nothing to do with Module::Build; it's just that 
you're passing options to perl in an order which causes them to be ignored.

perl foo.pl -I.

does nothing diferent to

perl foo.pl

This was just never seen before in sid because we necessarily fixed this
all in a belt-and-braces fashion to minimise breakage at the point of security
disclosure.

So I agree that the fix is to swap the ordering in cdbs so that it
is consistent with cdbs in jessie. That in itself is a long-term
workaround, until the whole perl ecosystem has got away from the
assumption that '.' will be in @INC.

Given that there are only 12 packages it is plausible to just remove
the (not working) workaround and fix those packages instead (the same
issue in debhelper will take a bit more work; see #836110 which I
really ought to get back to).

Note that I make no remark on Module::Build being buggy or not after
the removal of the Debian-specific stuff; I think the consensus upstream
was that the workarounds should be done in the higher level tolls like
the cpan client and packaging helpers rather than in the modules, but
it still seems like they're attempting to keep '.' on @INC and failing...
we'll see what they say in the github issue there.

Cheers,
Dominic.

Bug#865898: perl: EU::MM regression in 5.26 breaks erlsvc build

[Dominic Hargreaves]

On Sun, Jun 25, 2017 at 08:37:10PM +0300, Niko Tyni wrote:
> Package: perl
> Version: 5.26.0-1
> Severity: important
> User: debian-p...@lists.debian.org
> Usertags: perl-5.26-transition
> Forwarded: 
> https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/305
> Affects: erlsvc
> X-Debbugs-Cc: erl...@packages.debian.org
> 
> It looks like a regression in recent versions of ExtUtils-MakeMaker,
> including the one bundled with Perl 5.26.0 currently in experimental,
> broke the erlsvc build. I'm copying the erlsvc maintainer FYI, but it's
> not yet clear where this needs to be fixed.
> 
> A full build log is at
> 
>  
> http://perl.debian.net/rebuild-logs/perl-5.26-throwaway/erlsvc_1.02-2/erlsvc_1.02-2_amd64-2017-05-22T00:32:44Z.build
> 
> and the failure mode is
> 
>   dh_auto_test
>make -j1 test TEST_VERBOSE=1
>make[1]: Entering directory '/<>'
>make[2]: Entering directory '/<>/share'
>make[2]: Nothing to be done for 'all'.
>make[2]: Leaving directory '/<>/share'
>make[2]: Entering directory '/<>/share'
>make[2]: *** No rule to make target 'test_dynamic'.  Stop.
>make[2]: Leaving directory '/<>/share'
>Makefile:918: recipe for target 'subdirs-test_dynamic' failed
>make[1]: *** [subdirs-test_dynamic] Error 2
>make[1]: Leaving directory '/<>'
>dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2
>debian/rules:4: recipe for target 'build' failed
>
> As noted in the upstream bug, I've bisected that this started with 
>  
> https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/0c38f3739cb7476fc1b843484584fee30c9ea69e
> and still happens with current HEAD.

Upstream seems to think that this is a problem with erlsvc, which I
tend to agree with, so probably this just be reassigned?

Dominic.

Bug#865225: stretch-pu: package request-tracker4/4.4.1-3+deb9u2

[Dominic Hargreaves]

On Sun, Jun 25, 2017 at 11:19:29PM +0200, Cyril Brulebois wrote:
> Dominic Hargreaves <d...@earth.li> (2017-06-20):
> > I didn't manage to get the fix for #862426 sorted out for stretch
> > in time and this will cause annoying breakage for new installs.
> > 
> > It's possible that I will follow up with a fix for #848041 too, but
> > it's not clear what that is yet.
> 
> This looks good to me, but please remember to target stretch in your
> changelog entry.

Thanks, uploaded.

Bug#864276: [request-tracker-maintainers] Bug#864276: Bug#864276: rt4-extension-sla: not installable in sid

[Dominic Hargreaves]

On Tue, Jun 06, 2017 at 02:58:36PM +0100, Dominic Hargreaves wrote:
> On Tue, Jun 06, 2017 at 08:41:39AM +0200, Ralf Treinen wrote:
> > Package: rt4-extension-sla
> > Version: 1.04-2
> > Severity: serious
> > User: trei...@debian.org
> > Usertags: edos-uninstallable
> > 
> > Hi,
> > 
> > rt4-extension-sla is not installable in sid on any architecture. This is
> > the case since at least 2017-01-21. The reason is that it depends on
> > request-tracker4 (< 4.4.0), however the version of that package in sid
> > is 4.4.1-3.
> 
> Thanks. As per #851986 this was left in to aid backporting(?) but the
> reasoning in that bug is not too clear. Joost, any objections to just
> removing this?

I've now filed an RM bug (#865767) for this.

Dominic.

Bug#865767: RM: rt-extension-sla -- ROM; obsoleted by RT 4.4

[Dominic Hargreaves]

Package: ftp.debian.org
Severity: normal

As per #851986 and #864276 this package is not useful any more.
Whilst unofficial backports may still be useful for jessie, this
doesn't benefit from the package being in sid.

Thanks,
Dominic.

Bug#865563: libcatmandu-sru-perl FTBFS: test failures

[Dominic Hargreaves]

On Fri, Jun 23, 2017 at 07:43:52PM +0200, gregor herrmann wrote:
> On Fri, 23 Jun 2017 17:22:52 +0200, gregor herrmann wrote:
> 
> > > So what is not there anymore is PERL_USE_UNSAFE_INC=1.
> > 
> > Dom, I think you're our expert on dot-in-inc; do you think my hunch
> > is correct that we need to add PERL_USE_UNSAFE_INC back?
> > (And if yes, where would be the best place - in the $dot_in_inc_code,
> > and if yes within the if(); or after $dot_in_inc_code is output in
> > the second hunk of the above diff?
> 
> So this seems to work (as in: libcatmandu-sru-perl builds again, if I
> change /usr/share/perl5/Module/Build/Base.pm in the chroot):
> 
> --- a/lib/Module/Build/Base.pm
> +++ b/lib/Module/Build/Base.pm
> @@ -1866,6 +1866,7 @@ BEGIN {
>  $quoted_INC
>  );
>  $dot_in_inc_code
> +\$ENV{"PERL_USE_UNSAFE_INC"} = 1;
>  }
> 
>  close(*DATA) unless eof(*DATA); # ensure no open handles to this script
> 
> 
> I didn't have any success when playing with the new $dot_in_inc_code
> string, seems like the condition is never met. (And to be honest, I
> don't understand the logic ...) [0]
> 
> So it looks like we really need PERL_USE_UNSAFE_INC, and we might
> want to insert it unconditionally manually where we did prior to the
> accidental removal in the last upload.
> 
> 
> Cheers,
> gregor
> 
> [0]
> my $dot_in_inc_code = $INC[-1] eq '.' ? <<'END' : '';
> if ($INC[-1] ne '.') {
> push @INC, '.';
> }
> END
> 
> What also works is reverting the logic:
> 
> --- /usr/share/perl5/Module/Build/Base.pm~2017-06-19 17:25:18.0 
> +
> +++ /usr/share/perl5/Module/Build/Base.pm 2017-06-23 17:42:01.820466942 
> +
> @@ -1824,7 +1824,7 @@
>my $shebang = $self->_startperl;
>my $magic_number = $self->magic_number;
>  
> -my $dot_in_inc_code = $INC[-1] eq '.' ? <<'END' : '';
> +my $dot_in_inc_code = $INC[-1] ne '.' ? <<'END' : '';
>  if ($INC[-1] ne '.') {
>  push @INC, '.';
>  }
> 
> 
> Then PERL_USE_UNSAFE_INC is not needed. But testing $INC[-1] ne '.'
> two times make as little sense to me as first testing eq '.' and then ne '.'
> ...

It does rather look like a mistaken attempt to solve this problem, and
I agree that the logic is a bit odd, but this seems like the patch
likely to get accepted upstream; can you send this patch to the module
author?

I feel like we should try and not diverge further from upstream; that
seems almost guaranteed to end up with similar issues later.

Cheers,
Dominic.

Bug#865506: Upgrade buggy librdf-trine-perl with new release in Debian Jessie

[Dominic Hargreaves]

Control: tags -1 + moreinfo

On Thu, Jun 22, 2017 at 03:47:15PM +1000, David Cook wrote:
> Versions of RDF::Trine prior to 1.017 have buggy implementations of bulk_ops
> methods in RDF::Trine::Store::SPARQL, which causes only 1 RDF triple to be
> inserted into a triplestore when you are trying to insert more than 1 triple
> in bulk. 
> 
>  
> 
> This was fixed in version 1.017 with the commit
> https://github.com/kasei/perlrdf/commit/fbe2d3f8679cc134a38bd848d60b43ba9e17
> 20e2. 
> 
>  
> 
> Jonas Smedegaard has already uploaded the most recent version of RDF::Trine
> to Debian Sid (https://packages.debian.org/sid/librdf-trine-perl), and I'm
> hoping that this package can be backported to Debian Jessie.

Hi,

There's no need to file duplicate bug reports for different releases -
the information on affected releases is stored within the bug, so I've
merged the two together.

In https://github.com/kasei/perlrdf/issues/146 I note that the reporter
only mentions RDF::Trine 1.016 and nothing earlier. Do you have a test
case that we can use to verify whether this is broken on earlier
releases?

Best,
Dominic.

Bug#865411: perl: please backport zlib > 1.2.9 patches

[Dominic Hargreaves]

On Thu, Jun 22, 2017 at 12:25:16AM +0200, gregor herrmann wrote:
> On Wed, 21 Jun 2017 20:17:48 +0100, Dominic Hargreaves wrote:
> 
> > > > Just to be clear, this is in Compress-Raw-Zlib that has already 
> > > > (according to https://rt.cpan.org/Public/Bug/Display.html?id=119762)
> > > > been fixed in 2.74, which is already in blead and perl 5.26 (which is
> > > > in experimental).
> > > The Ubuntu patches and the second bug also reference IO-Compress, not
> > > sure if that's upstream yet.
> > My reading is that no change in IO-Compress was needed once
> > Compress-Raw-Zlib was fixed. And the CPAN bug was resolved with
> > no code change in IO-Compress.
> 
> In any case, both are updated to the latest version in unstable (and
> they are released in lockstep), so I assume no problems there.

This is about the version bundled with perl itself which is not yet fixed
in unstable. But good to point out that the separate packaged versions
don't need a separate bug report :)

https://anonscm.debian.org/cgit/perl/perl.git/tree/cpan/Compress-Raw-Zlib/lib/Compress/Raw/Zlib.pm#n12

Bug#865411: perl: please backport zlib > 1.2.9 patches

[Dominic Hargreaves]

On Wed, Jun 21, 2017 at 10:02:37PM +0300, Niko Tyni wrote:
> On Wed, Jun 21, 2017 at 07:42:32PM +0100, Dominic Hargreaves wrote:
> > On Wed, Jun 21, 2017 at 08:10:04AM +, Gianfranco Costamagna wrote:
> > > Source: perl
> > > Version: 5.24.1-4
> > > Severity: important
> > > 
> > > Hello, with the new zlib > 1.2.9 the testsuite fails,
> > > (e.g. you can look at Ubuntu build failures).
> > > https://launchpad.net/ubuntu/+source/perl/5.24.1-2
> > > 
> > > I found the test failures on rt.cpan.org and I applied to Ubuntu the 
> > > proposed
> > > patches:
> > > https://rt.cpan.org/Public/Bug/Display.html?id=120134
> > > https://rt.cpan.org/Public/Bug/Display.html?id=119762
> 
> > Just to be clear, this is in Compress-Raw-Zlib that has already 
> > (according to https://rt.cpan.org/Public/Bug/Display.html?id=119762)
> > been fixed in 2.74, which is already in blead and perl 5.26 (which is
> > in experimental).
> 
> The Ubuntu patches and the second bug also reference IO-Compress, not
> sure if that's upstream yet.

My reading is that no change in IO-Compress was needed once
Compress-Raw-Zlib was fixed. And the CPAN bug was resolved with
no code change in IO-Compress.

> > I'm not convinced that we need to spend time on fixing this for 5.24
> > given where we are in the release cycle, but this will depend on
> > when the zlib maintainer (Cced) plans to update to a newer zlib.
> 
> Agreed.

Bug#865411: perl: please backport zlib > 1.2.9 patches

[Dominic Hargreaves]

Control: fixed -1 5.26.0~rc1-1

On Wed, Jun 21, 2017 at 08:10:04AM +, Gianfranco Costamagna wrote:
> Source: perl
> Version: 5.24.1-4
> Severity: important
> 
> Hello, with the new zlib > 1.2.9 the testsuite fails,
> (e.g. you can look at Ubuntu build failures).
> https://launchpad.net/ubuntu/+source/perl/5.24.1-2
> 
> I found the test failures on rt.cpan.org and I applied to Ubuntu the proposed
> patches:
> https://rt.cpan.org/Public/Bug/Display.html?id=120134
> https://rt.cpan.org/Public/Bug/Display.html?id=119762
> 
> 
> I don't know why they are not applied upstream, nor if they are really 
> backward
> compatible with the older zlib
> 
> 
> please consider applying them or upstreaming them (in case cpan is not the 
> upstream
> place).

Just to be clear, this is in Compress-Raw-Zlib that has already 
(according to https://rt.cpan.org/Public/Bug/Display.html?id=119762)
been fixed in 2.74, which is already in blead and perl 5.26 (which is
in experimental).

I'm not convinced that we need to spend time on fixing this for 5.24
given where we are in the release cycle, but this will depend on
when the zlib maintainer (Cced) plans to update to a newer zlib.

Thanks,
Dominic.

Bug#862426: stretch update plan

[Dominic Hargreaves]

an s-p-u bug has been opened at

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

for this.

Bug#865225: stretch-pu: package request-tracker4/4.4.1-3+deb9u2

[Dominic Hargreaves]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

I didn't manage to get the fix for #862426 sorted out for stretch
in time and this will cause annoying breakage for new installs.

It's possible that I will follow up with a fix for #848041 too, but
it's not clear what that is yet.

Debdiff attached.

Thanks,
Dominic.
diff --git a/debian/changelog b/debian/changelog
index a984a89..431eb9c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+request-tracker4 (4.4.1-3+deb9u2) UNRELEASED; urgency=medium
+
+  * Handle configuration permissions correctly following
+RT_SiteConfig.d changes (Closes: #862426)
+
+ -- Dominic Hargreaves <d...@earth.li>  Tue, 20 Jun 2017 00:22:12 +0100
+
 request-tracker4 (4.4.1-3+deb9u1) stretch-security; urgency=high
 
   * Fix multiple security issues:
diff --git a/debian/postinst b/debian/postinst
index ab05f40..a6f9a56 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -100,8 +100,10 @@ run_dbconfig () {
 maybe_handle_permissions () {
 if [ "$HANDLE_PERMISSIONS" = "true" ]
 then
-chown root:www-data /etc/request-tracker4/RT_SiteConfig.pm
-chmod 640   /etc/request-tracker4/RT_SiteConfig.pm
+for f in /etc/request-tracker4/RT_SiteConfig.d/50-debconf.pm \
+ /etc/request-tracker4/RT_SiteConfig.d/51-dbconfig-common.pm; 
do
+[ -f "$f" ] && chown root:www-data $f && chmod 640 $f
+done
 fi
 }
 

Bug#865196: request-tracker4: syntax error in config script

[Dominic Hargreaves]

Package: request-tracker4
Version: 4.4.1-4
Severity: important

Somehow this doesn't break installation (as I didn't spot it during testing)
but the config script was broken by the change in 4.4.1-4:

# /var/lib/dpkg/info/request-tracker4.config
/var/lib/dpkg/info/request-tracker4.config: 255: [: missing ]

Bug#864875: [request-tracker-maintainers] Bug#864875: request-tracker4: frontend exists with status 10 after last upgrade

[Dominic Hargreaves]

On Fri, Jun 16, 2017 at 12:33:55PM +0200, Franz Georg Koehler wrote:
> After the latest upgrade to 4.2.8-3+deb8u2, frontend fails to run the postinst
> script sucessfully and exists with code 10 instead. This prevents the
> completion of the upgrade.
> 
> Might be related to the configuration. Hoever, I do not see what exactly is
> the problem? Actually, there is nothing that frontend would need to do?
> 
> root@orion:/etc/request-tracker4# /usr/share/debconf/frontend 
> /var/lib/dpkg/info/request-tracker4.postinst configure 4.2.8-3+deb8u1
> debconf (db): making DbDriver of type File

[snip many lines of debconf debug output]

> debconf (db configdb): passing to config ..
> debconf (developer): --> 0 ok
> debconf (developer): <-- CAPB backup
> debconf (developer): --> 0 multiselect escape backup
> debconf (developer): <-- REGISTER dbconfig-common/database-type 
> request-tracker4/database-type
> debconf (developer): --> 10 No such template, "dbconfig-common/database-type"
> debconf (developer): <-- GET request-tracker4/dbconfig-install
> debconf (developer): --> 10 request-tracker4/dbconfig-install doesn't exist
> debconf (db configdb): trying to 
> setflag(request-tracker4/handle-siteconfig-permissions seen true) ..
> debconf (db configdb): passing to config ..
> root@orion:/etc/request-tracker4# echo $?
> 10
> 
> oot@orion:/etc/request-tracker4# apt-get -f install
> Paketlisten werden gelesen... Fertig
> Abh??ngigkeitsbaum wird aufgebaut.   
> Statusinformationen werden eingelesen Fertig
> 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
> 1 nicht vollst??ndig installiert oder entfernt.
> Nach dieser Operation werden 0 B Plattenplatz zus??tzlich benutzt.
> request-tracker4 (4.2.8-3+deb8u2) wird eingerichtet ...
> + branch_version=4
> + branch_priority=250
> + warn
> + fmt -60
> + sed s/^/**WARNING**  /
> **WARNING**  
> **WARNING**  If you are using mod_perl or any form of persistent perl
> **WARNING**  process such as FastCGI, you will need to restart your
> **WARNING**  web server and any persistent processes now.
> **WARNING**  
> **WARNING**  For mod_perl this means
> **WARNING**  
> **WARNING**  invoke-rc.d apache2 stop && invoke-rc.d apache2 start
> **WARNING**  
> + find /var/cache/request-tracker4/mason_data -type f -print0
> + xargs -r0 rm -f
> + . /usr/share/debconf/confmodule
> + [ !  ]
> + PERL_DL_NONLAZY=1
> + export PERL_DL_NONLAZY
> + [  ]
> + exec /usr/share/debconf/frontend 
> /var/lib/dpkg/info/request-tracker4.postinst configure 4.2.8-3+deb8u1
> dpkg: Fehler beim Bearbeiten des Paketes request-tracker4 (--configure):
>  Unterprozess installiertes post-installation-Skript gab den Fehlerwert 10 
> zur??ck
> Fehler traten auf beim Bearbeiten von:
>  request-tracker4
> needrestart is being skipped since dpkg has failed
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Hi,

Thanks for this detailed bug report and I'm sorry that you have run into
problems particularly during a security update. As far as I can tell this
was a latent problem rather than one caused by the update directly, as the
Debian post-config code wasn't touched in the update. It must be quite an
edge case for it to not have been noticed before.

The problem seems to be that some dbconfig-common debconf questions are
not set by the time they are used in the postinst. This should happen
in the package preconfiguration script but apparently isn't.

Please could you take a copy of the debconf database
(/var/cache/debconf/config.dat) and then run
/var/lib/dpkg/info/request-tracker4.config by hand, having first
edited the first line to read

#!/bin/sh -x

This might shed some light on why this is happening. Please compare the
saved copy of the config database, eg:

diff -u /path/to/backup/config.dat /var/lib/debconf/config.dat

to see if anything changes.

Thanks,
Dominic

Bug#864747: stretch-pu: package anope/2.0.4-1+deb9u1

[Dominic Hargreaves]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

As per #864668 a typo in the control file means that installing
anope removes MTAs other than Exim. Please consider the attached
for a stretch point release.

Thanks,
Dominic.
diff --git a/debian/changelog b/debian/changelog
index c9265df..1ffa8d4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+anope (2.0.4-1+deb9u1) UNRELEASED; urgency=medium
+
+  * Correct Recommends typo tranport -> transport to stop Exim taking
+over from already-installed MTAs (Closes: #864668)
+
+ -- Dominic Hargreaves <d...@earth.li>  Tue, 13 Jun 2017 23:04:12 +0100
+
 anope (2.0.4-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/control b/debian/control
index c3152c5..862ce0e 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@ Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  lsb-base (>= 3.2-14),
-Recommends: default-mta | mail-tranport-agent
+Recommends: default-mta | mail-transport-agent
 Description: IRC Services designed for flexibility and ease of use
  Anope offers various services to maintain your IRC network.
  .

Bug#864668: anope installs automatically exim4 mta and removes other mta's

[Dominic Hargreaves]

Control: tags -1 + confirmed

On Mon, Jun 12, 2017 at 06:23:06PM +0200, Andreas Beck wrote:
> anope installs automatically exim4 mta and removes other mta's.
> Thats it...

Ah, yes, this appears to be caused by a typo in:

Recommends: default-mta | mail-tranport-agent

(tranport != transport).

I'll fix this in unstable shortly. As a workaround, you could use the
'equivs' tool to make a fake 'defaults-mta' package which depends on
your preferred MTA.

Apologies for the inconvenience.

Dominic.

Bug#864544: libgetopt-long-descriptive-perl: option value : and :+ processing are very broken

[Dominic Hargreaves]

On Sun, Jun 11, 2017 at 12:06:49PM +0100, Graham Cobb wrote:
> On 10/06/17 22:21, Dominic Hargreaves wrote:
> > Unfortunately we won't be able to fix either of these issues before
> > stretch releases because we're past the last upload date, even if 
> > fixes were available.
> > 
> > Given the last few releases of Getopt::Long have contained various
> > regressions and regression fixes I'd also be a bit wary of trying to
> > fix this in a stable point release, and indeed of diving in to try 
> > and fix the issue.
> > 
> > This is all a bit unfortunate but I'm not sure there is a solution
> > at this point.
> 
> I wonder if a solution for the immediate future might be to re-package
> the same version of Getopt::Long as available in (the latest update to)
> Jessie (which seems to be 2.42)? Obviously this would be missing some
> number of other bug fixes but it would, at least, not be a regression
> from Jessie.
> 
> As you say, it is too late to change the stretch release content, but
> that version could be made available in sid and in testing when it is
> opened up again (so fairly easily accessible to anyone who hits the
> bug), and could be made available as a stretch backport and in a stretch
> update release. After that is available, we could go back to repackaging
> the upstream version (which would hopefully include both fixes by then)
> and get that into testing to shake it down.
> 
> Or are there too many important changes to Getopt::Long since 2.42 to
> consider reverting?

I did briefly ponder that, but downgrading Getopt::Long in a point
release seems at least as invasive as the bug at hand. It's going
to be quite hard to tell whether that would break more than it would
fix due to people relying on the newer Getopt::Long.

And backports is not the right place for such things either (see
extensive discussions in recent Debian backports threads).

Dominic.

Bug#864607: noisy mariadb-server-10.1 installation

[Dominic Hargreaves]

Control: reassign -1 debconf
Control: forcemerge 863479 -1

On Sun, Jun 11, 2017 at 07:21:20PM +0200, Andreas Beckmann wrote:
> Control: reassign -1 perl 5.24.1-3
> Control: tag -1 stretch
> Control: retitle -1 perl: noisy about "Unescaped left brace in regex" on 
> upgrades to stretch
> 
> On Sun, 11 Jun 2017 16:59:38 +0300 Juha Heinanen  wrote:
> > During 'apt-get dist-upgrade' from jessie to stretch, this got printed
> > to console:
> > 
> > Setting up mariadb-common (10.1.23-9+deb9u1) ...
> > Selecting previously unselected package mariadb-server-10.1.
> > (Reading database ... 72727 files and directories currently installed.)
> > Preparing to unpack .../mariadb-server-10.1_10.1.23-9+deb9u1_amd64.deb ...
> > Unescaped left brace in regex is deprecated, passed through in regex; 
> > marked by <-- HERE in m/^(.*?)(\\)?\${ <-- HERE ([^{}]+)}(.*)$/ at 
> > /usr/share/perl5/Debconf/Question.pm line 72.
> > Unescaped left brace in regex is deprecated, passed through in regex; 
> > marked by <-- HERE in m/\${ <-- HERE ([^}]+)}/ at 
> > /usr/share/perl5/Debconf/Config.pm line 30.
> > 
> > Please fix so that the deprecated info does not get printed.  If every
> > package would be as noisy, user couldn't comprehend anything about what
> > is going on.
> 
> perl probably should silence this warning for stretch. Especially
> if it triggers on perl packages from jessie during the upgrade
> (because perl was upgraded first, and the package in question will
> be upgraded soon. Or should debconf in jessie be "fixed"?

This has already been discussed in #863479 where it was suggested
that this should be fixed in debconfi in a jessie point-release.

Regards,
Dominic.

Bug#864544: libgetopt-long-descriptive-perl: option value : and :+ processing are very broken

[Dominic Hargreaves]

On Sat, Jun 10, 2017 at 08:35:31PM +0200, gregor herrmann wrote:
> On Sat, 10 Jun 2017 19:12:16 +0100, Graham Cobb wrote:
> 
> > Apologies, Gregor, for my misunderstanding. I had thought that
> > libgetopt-long-descriptive-perl provided both. I have now removed
> > libgetopt-long-descriptive-perl from my system and the problem remains
> > so, of course, you are right.
> 
> No worries.
>  
> > By the way, I have confirmed that the problem does NOT occur on my
> > jessie system (perlbase 5.20.2-3+deb8u7). On that system the option
> > parsing works according to the documentation.
> 
> This seems indeed to be a known regression, cf.
> https://bugs.debian.org/855532 
> https://rt.cpan.org/Ticket/Display.html?id=114999

The defaulting issue (:n) seems to be fixed in the latest upstream
release, but the incremental processing (:+) is still broken in upstream's
master. I've reported this as

https://rt.cpan.org/Ticket/Display.html?id=122068

Unfortunately we won't be able to fix either of these issues before
stretch releases because we're past the last upload date, even if 
fixes were available.

Given the last few releases of Getopt::Long have contained various
regressions and regression fixes I'd also be a bit wary of trying to
fix this in a stable point release, and indeed of diving in to try 
and fix the issue.

This is all a bit unfortunate but I'm not sure there is a solution
at this point.

Help welcome, of course...

Dominic.

Bug#863479: perl-base should add Breaks: debconf (<< 1.5.57~)

[Dominic Hargreaves]

Control: reassign -1 debconf

On Wed, May 31, 2017 at 12:39:57PM +0100, Dominic Hargreaves wrote:
> On Mon, May 29, 2017 at 10:16:08PM +0300, Niko Tyni wrote:
> > On Sat, May 27, 2017 at 03:42:14PM +0200, Julien Cristau wrote:
> > > On Sat, May 27, 2017 at 16:36:50 +0300, Adrian Bunk wrote:
> >  
> > > > Package: perl-base
> > > > Version: 5.24.1-2
> > 
> > > > Technically #786705 is just a harmless warning, but when
> > > > during a jessie -> stretch upgrade perl-base is upgraded
> > > > before debconf is upgraded the user might see a lot scary
> > > > warnings as if something was seriously broken.
> > > > 
> > > [...]
> > > > 
> > > > perl-base should add a Breaks: debconf (<< 1.5.57~).
> > > 
> > > Adding Breaks in a core package a couple of weeks before the release
> > > sounds like a very, very, very bad idea.
> > 
> > Indeed it seems too late in the cycle for this.
> > 
> > Other possible solutions that come to mind:
> > 
> > - silence the warnings during maintainer scripts, much like
> >
> > https://sources.debian.net/src/perl/5.24.1-2/debian/patches/debian/squelch-locale-warnings.diff/
> >   (but it's late for even this IMO)
> > 
> > - update debconf in a jessie point release to minimize the impact
> >   (this feels right to me, but won't help the immediate stretch upgraders)
> > 
> > Cc'ing Colin. What do you think about the latter option?
> 
> Agree, the third option looks correct to me, we don't have time for
> anything else.

I'm reassigning this bug to debconf now as this seems to be the obvious
way forward. Colin, let us know if you would like a hand with preparing an
update for jessie for this.

Cheers,
Dominic.

Bug#832845: Update on base.pm breakage in jessie

[Dominic Hargreaves]

Hi all,

We are currently investiging a more general fix to these problems
with an update to the perl package. If this is successful, it will
probably be preferable to changing all of these packages (with potential
remaining unknown runtime issues and/or issues in user-supplied code,
even if this is very unlikely given how long the issue has been in Debian).
I'll send an update once we know whether this approach will work.

Cheers,
Dominic.

Bug#864302: request-tracker4: FTBFS due to base.pm changes in July 2016

[Dominic Hargreaves]

Source: request-tracker4
Version: 4.2.8-3+deb8u1
Severity: serious
Justification: ftbfs
Tags: jessie patch

As per

http://perl.debian.net/rebuild-logs/jessie/request-tracker4_4.2.8-3+deb8u1/request-tracker4_4.2.8-3+deb8u1_amd64-2017-06-05T20:11:50Z.build

building this package was broken by the changes in perl to fix the '.'
in @INC vulnerability.

The breakage doesn't appear in the version in unstable, though it's
not immediately obvious why. There is a proposed fix in

https://anonscm.debian.org/cgit/pkg-request-tracker/request-tracker4.git/log/?h=ntyni/jessie-base-pm

Dominic.

Bug#864299: libclass-c3-perl: FTBFS due to base.pm changes in July 2016

[Dominic Hargreaves]

Source: libclass-c3-perl
Version: 0.26-1
Severity: serious
Justification: ftbfs
Tags: jessie patch

As per

http://perl.debian.net/rebuild-logs/jessie/libclass-c3-perl_0.26-1/libclass-c3-perl_0.26-1_amd64-2017-06-05T20:11:30Z.build

building this package was broken by the changes in perl to fix the '.'
in @INC vulnerability.

The package was fixed in unstable by the upstream version 0.31 by 
commit

https://anonscm.debian.org/cgit/pkg-perl/packages/libclass-c3-perl.git/commit/?id=47a367d0930224e392be71678bddff77e4ddee82

Dominic.

Bug#864276: [request-tracker-maintainers] Bug#864276: rt4-extension-sla: not installable in sid

[Dominic Hargreaves]

On Tue, Jun 06, 2017 at 08:41:39AM +0200, Ralf Treinen wrote:
> Package: rt4-extension-sla
> Version: 1.04-2
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-uninstallable
> 
> Hi,
> 
> rt4-extension-sla is not installable in sid on any architecture. This is
> the case since at least 2017-01-21. The reason is that it depends on
> request-tracker4 (< 4.4.0), however the version of that package in sid
> is 4.4.1-3.

Thanks. As per #851986 this was left in to aid backporting(?) but the
reasoning in that bug is not too clear. Joost, any objections to just
removing this?

Dominic.

Bug#863870: perl: File-Path rmtree/remove_tree race condition [CVE-2017-6512]

[Dominic Hargreaves]

On Thu, Jun 01, 2017 at 10:41:56AM +0100, Dominic Hargreaves wrote:
> Similar to #286905, a new race condition has been reported in File-Path:
> 
> https://rt.cpan.org/Public/Bug/Display.html?id=121951
> 
> In the rmtree() and remove_tree() functions, the chmod()logic to make
> directories traversable can be abused to set the mode on an
> attacker-chosen file to an attacker-chosen value.  This is due to the
> time-of-check-to-time-of-use (TOCTTOU) race condition
> (https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use) between the
> stat() that decides the inode is a directory and the chmod() that tries
> to make it user-rwx.
> 
> Fixed on CPAN with 2.13.

I've uploaded a fix to sid. As evidenced by the additional patch I
included, and upstream's testing, one package out of the CPAN top 2000
was broken by the change: a test in ExtUtils::MakeMaker; see

https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/294

Given the potential for other code to be affected, we are running a
rebuild of all perl rdeps with the new package. The results are available here:

http://perl.debian.net/rebuild-logs/experimental/report.html

(ignore everything with a date older than today).

Assuming that no breakage that we can't live with is found, I'll file
an unblock request.

Work on jessie is still ongoing.

Dominic.

Bug#862901: Stable link

[Dominic Hargreaves]

Control: tags -1 + patch

Hi,

Please use 

https://metacpan.org/changes/release/XSAWYERX/perl-5.26.0#Removal-of-the-current-directory-(%22.%22)-from-@INC

instead of the gitweb link in the previous patch.

Thanks,
Dominic.

Bug#863870: perl: File-Path rmtree/remove_tree race condition [CVE-2017-6512]

[Dominic Hargreaves]

Package: perl
Version: 5.26.0~rc1-1
Severity: critical
Justification: privilege escalation in library code

Similar to #286905, a new race condition has been reported in File-Path:

https://rt.cpan.org/Public/Bug/Display.html?id=121951

In the rmtree() and remove_tree() functions, the chmod()logic to make
directories traversable can be abused to set the mode on an
attacker-chosen file to an attacker-chosen value.  This is due to the
time-of-check-to-time-of-use (TOCTTOU) race condition
(https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use) between the
stat() that decides the inode is a directory and the chmod() that tries
to make it user-rwx.

Fixed on CPAN with 2.13.

Bug#863479: perl-base should add Breaks: debconf (<< 1.5.57~)

[Dominic Hargreaves]

On Mon, May 29, 2017 at 10:16:08PM +0300, Niko Tyni wrote:
> On Sat, May 27, 2017 at 03:42:14PM +0200, Julien Cristau wrote:
> > On Sat, May 27, 2017 at 16:36:50 +0300, Adrian Bunk wrote:
>  
> > > Package: perl-base
> > > Version: 5.24.1-2
> 
> > > Technically #786705 is just a harmless warning, but when
> > > during a jessie -> stretch upgrade perl-base is upgraded
> > > before debconf is upgraded the user might see a lot scary
> > > warnings as if something was seriously broken.
> > > 
> > [...]
> > > 
> > > perl-base should add a Breaks: debconf (<< 1.5.57~).
> > 
> > Adding Breaks in a core package a couple of weeks before the release
> > sounds like a very, very, very bad idea.
> 
> Indeed it seems too late in the cycle for this.
> 
> Other possible solutions that come to mind:
> 
> - silence the warnings during maintainer scripts, much like
>
> https://sources.debian.net/src/perl/5.24.1-2/debian/patches/debian/squelch-locale-warnings.diff/
>   (but it's late for even this IMO)
> 
> - update debconf in a jessie point release to minimize the impact
>   (this feels right to me, but won't help the immediate stretch upgraders)
> 
> Cc'ing Colin. What do you think about the latter option?

Agree, the third option looks correct to me, we don't have time for
anything else.

Cheers,
Dominic.

Bug#862901: release-notes: further update to perl @INC change

[Dominic Hargreaves]

Package: release-notes
Severity: normal

Hi,

Further to #859129, please consider this additional patch which refers
to a possible workaround for local issues, and freshly-minted upstream
documentation for developers on the topic.

Index: en/issues.dbk
===
--- en/issues.dbk   (revision 11492)
+++ en/issues.dbk   (working copy)
@@ -710,6 +710,25 @@
   require(), do() etc., where the
   arguments are files in the current directory.
 
+
+
+  All perl programs and module shipped by Debian should have been
+  fixed to address any incompatibilities caused by the above; please
+  file bugs if this is not the case. As the change has now been made
+  in perl 5.26.0, third-party software should also start to be fixed.
+  Information about how to fix this issue for developers is provided
+  in the https://perl5.git.perl.org/perl.git/blob_plain/HEAD:/pod/perldelta.pod;>perl
 5.26 release notes (see the SECURITY section).
+
+
+  If needed you can temporarily reinstate . in
+  @INC globally by commenting out the line in
+  /etc/perl/sitecustomize.pl but you should
+  only do this with a understanding of the potential risks. This
+  workaround will be removed in  . You can
+  also set the PERL_USE_UNSAFE_INC environment
+  variable in a specific context which will have the same effect.  
 
   
   

Bug#862426: request-tracker4: No longer handles configuration permissions correctly

[Dominic Hargreaves]

Package: request-tracker4
Severity: important
Version: 4.4.1-3

Following the changes to use /etc/request-tracker4/RT_SiteConfig.d,
file permissions were not handled automatically when requested, breaking
out of the box installs.

A patch is forthcoming.

Bug#862405: libjson-xs-perl: dropped support for to_json

[Dominic Hargreaves]

Package: libjson-xs-perl
Version: 3.030-1
Severity: important

3.0 (released 2013) removed to_json/from_json with no further
information given
(https://sources.debian.net/src/libjson-xs-perl/3.030-1/Changes/#L40)

This seems to break a documented interface of libjson-perl's if installed.
I don't know the full history but it seems that there are other known
issues with JSON::XS not working nicely with JSON, and the recommendation
is to not use it at all.

https://rt.cpan.org/Public/Bug/Display.html?id=94784

This was observed with #848041 in request-tracker4. I'm honestly not sure
about the best route forward on that ticket; looking at the rdeps of
libjson-xs-perl, Conflicting on it may be too invasive...

Thoughts welcomed!

Dominic.

Bug#861591: Bug#862071: password-store: FTBFS when built in a path with >= 74 characters

[Dominic Hargreaves]

On Mon, May 08, 2017 at 10:43:21PM +0100, Chris Lamb wrote:
> gregor herrmann wrote:
> 
> > > This is due to GNUPGHOME needing to fit within sockaddr_un.sun_path.
> > 
> > Also #861591, where the same happens.
> > 
> > I'm not sure how RC-ish this should be, as build paths by our usual
> > tools (sbuild, pbuilder) are, IIRC, shorter (/build//…), so
> > this shouldn't be a problem in most cases.
> 
> As it happens, it appears to also fail when HOME is non-existent:
> 
>   https://gist.github.com/lamby/72f051e7c4dd75cfbdd23e48a2151f5e/raw
> 
> … which is even more dubious as RC severity, but I'll leave that to
> the Release Team.

Hi Release Team,

Please could you rule on whether the above class of bugs should be RC
for stretch? It doesn't seem productive at this late stage.

Thanks,
Dominic.

Bug#730621: Still an issue

[Dominic Hargreaves]

This is still happening with Debian testing, when trying to install
Mathematica. Creating /usr/share/desktop-directories by hand fixed the
problem.

Thanks,
Dominic.

Bug#861671: spamassassin: bb.barracudacentral.org not suitable for being automatically enabled

[Dominic Hargreaves]

Package: spamassassin
Version: 3.4.1-6
Severity: normal

Dear Maintainer,

I happened to spot, whilst looking at the reason for a mail rejection,
the rule:

ifplugin Mail::SpamAssassin::Plugin::DNSEval
header RCVD_IN_BRBL_LASTEXT   
eval:check_rbl('brbl-lastexternal','bb.barracudacentral.org')
tflags RCVD_IN_BRBL_LASTEXT   net
endif

I'd not heard of this blocklist before so I went to have a look. From
their website, it seems that this list is not supposed to be used
without registering:

http://barracudacentral.org/account/register

(quote: " IP addresses not listed may be blocked, rate controlled or
otherwise denied access without warning")

Therefore, I suggest that this rule not be enabled by default.

Cheers,
Dominic.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages spamassassin depends on:
ii  adduser  3.115
ii  curl 7.52.1-5
ii  init-system-helpers  1.47
ii  libhtml-parser-perl  3.72-3
ii  libhttp-date-perl6.02-1
ii  libmail-dkim-perl0.40-1
ii  libnet-dns-perl  1.07-1
ii  libnetaddr-ip-perl   4.079+dfsg-1+b1
ii  libsocket6-perl  0.27-1+b1
ii  libsys-hostname-long-perl1.5-1
ii  libwww-perl  6.15-1
ii  lsb-base 9.20161125
ii  perl 5.24.1-2
ii  perl-modules-5.24 [libarchive-tar-perl]  5.24.1-2
ii  w3m  0.5.3-34

Versions of packages spamassassin recommends:
ii  gnupg 2.1.18-6
ii  libio-socket-inet6-perl   2.72-2
ii  libmail-spf-perl  2.9.0-4
ii  libperl5.24 [libsys-syslog-perl]  5.24.1-2
ii  sa-compile3.4.1-6
ii  spamc 3.4.1-6+b1

Versions of packages spamassassin suggests:
ii  libdbi-perl  1.636-1+b1
pn  libencode-detect-perl
pn  libgeo-ip-perl   
ii  libio-socket-ssl-perl2.044-1
pn  libnet-patricia-perl 
ii  libperl5.24 [libcompress-zlib-perl]  5.24.1-2
pn  pyzor
pn  razor

-- Configuration Files:
/etc/default/spamassassin changed:
ENABLED=0
OPTIONS="--create-prefs --max-children 5 --helper-home-dir"
PIDFILE="/var/run/spamd.pid"
CRON=1


-- debconf-show failed

Bug#783228: Still broken

[Dominic Hargreaves]

As reported in https://lists.debian.org/debian-user/2016/03/msg01091.html,
the default configuration now sends out cronspam once every four hours.

It can be disabled with

si_dbs=""

in /etc/clamav-unofficial-sigs.conf.d/local.conf

Dominic.

Bug#857748: [request-tracker-maintainers] Bug#857748: Please package current version - 1.02

[Dominic Hargreaves]

On Wed, Apr 12, 2017 at 12:13:30PM +0300, Adrian Bunk wrote:
> On Thu, Mar 23, 2017 at 03:09:56PM +0900, Satoru KURASHIKI wrote:
> >...
> > In the later stage of freeze, are there any chance to upload newer
> > upstream version (into testing) to fix RC bugs?
> > If it can, I will finish staged git chages as soon as I can.
> >...
> 
> This was already ACK'ed for stretch by the release team in #858779,
> but there is a second open issue:
> 
> The upstream changelog says 4.2 compatibility was added in 0.02
> 
> Does rt4-extension-customfieldsonupdate 0.01-1 in jessie work with 
> request-tracker4 4.2.8 in jessie?

I don't use it myself, but the git history suggests that it mostly
worked:

https://github.com/bestpractical/rt-extension-customfieldsonupdate/commit/60ab227c44296f6f92c3084bc811171d9aa0b665

(silence deprecation warnings)

https://github.com/bestpractical/rt-extension-customfieldsonupdate/commit/ae351ae9cdee8b37c4eb397402d80f7ba6ecd54d

(fixing a non-fatal bug)

Cheers,
Dominic.

Bug#858779: [request-tracker-maintainers] RFS: rt-extension-customfieldsonupdate-1.02-1

[Dominic Hargreaves]

On Thu, Apr 06, 2017 at 08:20:04PM +0900, Satoru KURASHIKI wrote:
> hi,
> 
> To fix RC bug #857748, I've upload updated package to mentors,
> which include changes only:
>  - new upstream version
>  - use libmodule-install-rtx-perl
> https://mentors.debian.net/debian/pool/main/r/rt-extension-customfieldsonupdate/rt-extension-customfieldsonupdate_1.02-1.dsc
> 
> Please upload it into archive, thanks.
> # Also, acked by release team at #858779
> cf.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857748
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858779
> 
> After fixing RC, I will drop my local git repo, and import this change
> into alioth's repo to switch.

Now uploaded.

Dominic.

Bug#582925: Bug#839218: nama: FTBFS: Failed 1/7 test programs. 0/91 subtests failed.Bad plan. You planned 126 tests but ran 57.

[Dominic Hargreaves]

Control: reassign 839218 nama
Control: retitle 839218 nama: FTBFS because of perl's lack of stack reference 
counting

On Mon, Mar 27, 2017 at 09:33:29AM +0200, Balint Reczey wrote:
> Control: tags -1 patch
> 
> Hi Niko,
> 
> On Sun, Mar 26, 2017 at 8:23 PM, Niko Tyni  wrote:
> > On Fri, Mar 24, 2017 at 11:30:11AM +0200, Niko Tyni wrote:
> >
> >> I'll also work a bit on reducing the test further when I find the time.
> >
> > I got it down to this:
> >
> >   my $a = [ 0, 1 ];
> >   sub f {
> > my $arg = shift;
> > my @a1 = @$a;
> > @$a = @a1;
> > return();
> >   }
> >   map{ f($_) } @$a;
> >
> >
> > This looks to me like an instance of the general stack-not-refcounted
> > issue, see https://rt.perl.org/Public/Bug/Display.html?id=77706 et al.
> >
> > But let's see what upstream says, I'll follow up there as well.
> 
> Thanks!
> 
> Seeing that they confirmed that and the refcounting issue is rather old
> I think it would be reasonable to apply a workaround in nama.
> The attached patch made nama build in current unstable.

Thanks, reassigning back to Nama so the workaround can be considered.
The underlying problem in perl is tracked in #582925.

Dominic.

Bug#857748: [request-tracker-maintainers] Bug#857748: Please package current version - 1.02

[Dominic Hargreaves]

Control: severity -1 serious

On Tue, Mar 14, 2017 at 07:25:32PM +0300, Max Kosmach wrote:
> X-Debbugs-CC: pkg-request-tracker-maintain...@lists.alioth.debian.org
> Package: rt4-extension-customfieldsonupdate
> Version: 0.01-1.1
> 
> Please package current version (1.02) which is compatible with RT 4.2 and RT 
> 4.4

Hi Max,

Thanks for raising this issue. From the changelog I take it that 0.0.1
doesn't support 4.2 or 4.4 at all. Is that your understanding too? 

As such this is RC for both jessie and stretch, so raising the
severity appropriately.

Dominic.

Bug#793660: Is still an issue

[Dominic Hargreaves]

On Sun, Dec 18, 2016 at 05:12:40PM -0700, Bdale Garbee wrote:
> Borden Rhodes  writes:
> 
> > I'm on Debian Stretch, so I use libsss-sudo version 1.14.2-1 and
> > version 1.8.17p1-2 of sudo. I've since uninstalled libsss-sudo but can
> > reinstall it for debugging purposes.
> 
> I'd be curious to know if sudo 1.8.18p1-2 still exhibits the problem.
> Is that something you can test without great angst?

I can confirm that the problem happens with sudo 1.8.19p1-1 and
sssd 1.15.0-3.

The workaround I used was as per [1] in sssd's configuration:

[sssd]
services = nss, pam, sudo

[mydomain/LDAP]
sudo_provider = none

It seems quite debatable whether this is a sudo problem rather than
an sssd problem. The summary at [2] from Oliver Brakmann seems
most informative:

"It affects both local and LDAP users. I don't have any sudo config in LDAP, 
which is probably the problem.

What I believe happens is that either or both of sudo and sssd do not correctly 
cope with the situation of the sudo configuration not being available in the 
sssd backing store. Sudo asks sssd for the "cn=defaults" entry from LDAP, sssd 
looks for it, doesn't find anything and returns an error. Sudo sees the error 
and complains.

I can come up with three possible solutions:

1) patch sudo to not log a message when sssd returns an error.
=> probably not the best solution, since we may miss real errors, too.

2) patch sssd to not return an error when the configuration isn't found.
=> probably slightly better than (1), but we still might miss real errors (I 
think). BTW, the offending code starts here: 
https://git.fedorahosted.org/cgit/sssd.git/tree/src/sss_client/sudo/sss_sudo.c#n109

3) patch the sssd package to not alter the nsswitch.conf.
=> this is probably the best solution. I think the people that store the sudo 
config in LDAP are quite the minority. I also think that those people know that 
they need to modify their nsswitch.conf for their configuration to work. Goes a 
bit against the spirit of Ubuntu, though."

Cheers,
Dominic.

[1] https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1249777/comments/11
[2] https://bugs.launchpad.net/debian/+source/sudo/+bug/1249777/comments/2

Bug#834190: perl: please make the output of ExtUtils::Command::MM reproducible

[Dominic Hargreaves]

On Wed, Feb 08, 2017 at 03:48:56PM +1300, Chris Lamb wrote:
> Hi Dominic,
> 
> > Could you clarify how this showed up as an issue as part of the
> > reproducible builds work?
> 
> Not sure how I can add beyond the original bug report alas :) However,
> what I was seeing was that ExtUtils::Command::MM was generating
> "perllocal.pod" files that contained the current time of day,
> hence the patch.

I suppose my question was whether you saw this in the context of
a package build (which would be odd, but I'm sure there are cases
where it happens) or at some other time (in which case, is there
still a justification for working towards reproducibility)? I appreciate
this was a long time ago so you may not have the information, and I
should have asked this at the time.

perllocal.pod generation is already disabled for vendor installs so either
there is a bug in that or you saw the generation happening elsewhere.

https://sources.debian.net/src/perl/5.24.1-1/debian/patches/debian/no_packlist_perllocal.diff/

> > A reproducible build should just disable perllocal generation
> >
> >   — https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/279
> 
> I'm afraid I just don't know -- am not deep enough into Perl packaging
> to know the impact of this.
> 
> Let me comment on there actually...

Thanks!
Dominic.

Bug#834190: perl: please make the output of ExtUtils::Command::MM reproducible

[Dominic Hargreaves]

On Fri, Aug 12, 2016 at 10:39:13PM +0100, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], I noticed
> that ExtUtils::Command::MM generates perllocal.pod files that are
> not reproducible.
> 
> For example:
> 
>   -=head2 Sun Jul  3 14:56:53 2016: C   +=head2 Sun Aug  6 23:18:50 2017: C 
> Patch attached.
> 
>  [0] https://reproducible-builds.org/

Hi Chris,

Could you clarify how this showed up as an issue as part of the
reproducible builds work? There seems to be some resistance to the
change in https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/279
that I don't quite understand, and it'd be nice to demonstrate more
clearly that it's relevant outside Debian...

Cheers,
Dominic.

Bug#854198: [request-tracker-maintainers] Bug#854198: Packages that are now part of request-tracker4 must be removed from testing

[Dominic Hargreaves]

On Sun, Feb 05, 2017 at 01:10:14AM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> 
> #852258   rt-authen-externalauth: FTBFS: Your installed version of RT 
> (4.4.1-2) is too new
> #851987   rt-extension-spawnlinkedticketinqueue: Obsolete with RT 4.4
> #851986   rt-extension-sla: Obsolete with RT 4.4
> 
> These are now part of request-tracker4 and request-tracker4
> has proper Conflicts, so they must be removed to allow
> testing migration of request-tracker4.

Thanks for pointing this out, Adrian. Indeed these packages should be
removed from testing. RT, please could you do this so that RT 4.4
can migrate in time? Thanks very much.

Cheers,
Dominic.

Bug#852332: dh-make-perl: DEBFULLNAME and DEBEMAIL should be used with git

[Dominic Hargreaves]

On Tue, Jan 24, 2017 at 12:32:58PM +, Carnë Draug wrote:

> diff --git a/lib/DhMakePerl/Command/make.pm b/lib/DhMakePerl/Command/make.pm
> index 31db889..4cde1da 100644
> --- a/lib/DhMakePerl/Command/make.pm
> +++ b/lib/DhMakePerl/Command/make.pm
> @@ -748,7 +748,7 @@ sub git_import_upstream__init_debian {
>  my $git = Git->repository( $self->main_dir );
>  $git->command( qw(symbolic-ref HEAD refs/heads/upstream) );
>  $git->command( 'add', '.' );
> -$git->command( 'commit', '-m',
> +$git->command( 'commit', '--author', $self->get_developer, '-m',
>"Import original source of "
>  . $self->perlname . ' '
>  . $self->version );
> @@ -762,7 +762,7 @@ sub git_import_upstream__init_debian {
># debian/ directory from the working tree; git has the history, so I 
> don't
># need the debian.bak
>$git->command( 'rm', '-r', $self->debian_dir );
> -  $git->command( 'commit', '-m',
> +  $git->command( 'commit', '--author', $self->get_developer, '-m',
>   'Removed debian directory embedded in upstream source' 
> );
>  }
>  }
> @@ -777,7 +777,7 @@ sub git_add_debian {
>  
>  my $git = Git->repository( $self->main_dir );
>  $git->command( 'add', 'debian' );
> -$git->command( 'commit', '-m',
> +$git->command( 'commit', '--author', $self->get_developer, '-m',
>  "Initial packaging by dh-make-perl $VERSION" );
>  $git->command(
>  qw( remote add origin ),

This will indeed create commits with the email and name specified, but
the committer address will not be overridden which is probably confusing.
Also, any future commits to the repo it created will use the global default,
which may be confusing. (There's no option to override the committer
in the git commit command)

Setting the per-repo config would fix both these issues at the expense
of sprinkling potentially unwanted hard-coded data in the repos. Changing
the git global default would obviously be unwanted and rude.

I think I'm leaning towards adding the repo config being the least
worst option, but I'm not completely sure.

Dominic.

Bug#851986: [request-tracker-maintainers] Bug#851986: Bug#851986: rt-extension-sla: Obsolete with RT 4.4

[Dominic Hargreaves]

On Sun, Jan 22, 2017 at 01:44:05AM +0100, Joost van Baal-Ilić wrote:
> On Fri, Jan 20, 2017 at 03:38:31PM +0000, Dominic Hargreaves wrote:
> > Source: rt-extension-sla
> > Version: 1.04-2
> > Severity: serious
> > Justification: obsolete, uninstallable
> > 
> > With the upload of RT 4.4 to unstable, this separate package is
> > obsoleted - RT 4.4 includes the SLA functionality out of the box. As
> > such, rt-extension-sla should not be released with stretch.
> 
> Thanks for reporting this; you are right.
> 
> FWIW; rt-extension-sla has been packaged to be useful for people running
> jessie/stable.  I am running it on jessie production systems.
> 
> I am wondering if it would be usefull to have rt-extension-sla in unstable for
> the next couple of months...  Unfortunately, as long as it is not in testing,
> it can't be in backports either; due to the backports policy :( .

Yes, that is rather unfortunate :( I have no objections to keeping
it unstable for a while to support backporting, even if it only appears
in an unofficial backports repository (roll on, PPAs!)

Cheers,
Dominic.

Bug#851986: rt-extension-sla: Obsolete with RT 4.4

[Dominic Hargreaves]

Source: rt-extension-sla
Version: 1.04-2
Severity: serious
Justification: obsolete, uninstallable

With the upload of RT 4.4 to unstable, this separate package is
obsoleted - RT 4.4 includes the SLA functionality out of the box. As
such, rt-extension-sla should not be released with stretch.

Dominic.

Bug#851987: rt-extension-spawnlinkedticketinqueue: Obsolete with RT 4.4

[Dominic Hargreaves]

Source: rt-extension-spawnlinkedticketinqueue
Version: 0.06-1.1
Severity: serious
Justification: obsolete, uninstallable

With the upload of RT 4.4 to unstable, this separate package is
obsoleted - RT 4.4 includes the SLA functionality out of the box. As
such, rt-extension-spawnlinkedticketinqueue should not be released with
stretch.

Dominic.

Bug#825987: /usr/sbin/update-java-alternatives: Re: /usr/sbin/update-java-alternatives: doesn't detect openjdk-8 xjc

[Dominic Hargreaves]

On Thu, Jun 23, 2016 at 03:07:50PM +0100, Dominic Hargreaves wrote:
> Control: retitle -1 update-java-alternatives: doesn't recognise new jdkhl 
> label in jinfo files
> Control: tags -1 + patch confirmed
> Control: severity -1 normal
> 
> On Fri, Jun 03, 2016 at 11:42:27AM +1000, Jayen Ashar wrote:
> > Package: java-common
> > Version: 0.57
> > Followup-For: Bug #825987
> > 
> > Dear Maintainer,
> > 
> > javac seems to have the same issue:
> > 
> > $ sudo update-java-alternatives -v -l | grep javac
> > listing java alternatives:
> > jdk javac /usr/lib/jvm/java-6-openjdk-i386/bin/javac
> > jdk javac /usr/lib/jvm/java-7-openjdk-i386/bin/javac
> > jdk javac /usr/lib/jvm/java-6-sun/bin/javac
> > jdk javac /usr/lib/jvm/jdk-7-oracle-i586/bin/javac
> 
> This is because, as of openjdk-8 8u72-b15-3[1] a new 'jdkhl' label
> was added to the jinfo files, but update-java-alternatives was not
> updated to take account of this.
> 
> This affects the following commands:
> 
> extcheck, idlj, jar, jarsigner, javac, javadoc, javah, javap, jcmd, jdb,
> jdeps, jhat, jinfo, jmap, jps, jrunscript, jsadebugd, jstack, jstat,
> jstatd, native2ascii, rmic, schemagen, serialver, wsgen, wsimport, xjc
> 
> I've attached a patch which restores the expected behaviour.

Ping? Is there any chance of getting this included into stretch?
It would be nice to to have to manually patch this ourselves through
its life.

Best,
Dominic.

Bug#834420: Bug#834423: Can't reproduce

[Dominic Hargreaves]

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

On Mon, Dec 19, 2016 at 03:04:50AM +0100, Christian Hofstaedtler wrote:
> * Dominic Hargreaves <d...@earth.li> [161219 02:04]:
> > Control: severity -1 important
> > Control tags -1 + unreproducible
> > 
> > This package builds for me on a current sid chroot, so downgrading.
> 
> I was going to merge this bug with #834420 as it looks like
> basically the same thing, but then saw this downgrade. Can you sort
> out the severity of the other bug and/or the merging?

It was not supposed to be quite the same; #834420 was supposed to be about
the way latex2html was designed, rather than the FTBFS, but for whatever
reason I think I've screwed up my analysis since it's clearly still working
after the @INC change (eg condor is not FTBFS).

Anyway, downgrading until I can figure out what happened to avoid it
getting unfairly removed from the stretch release.

Thanks for the heads up.

Dominic

Bug#849812: ITP: requests-ntlm -- HTTP NTLM authentication using the requests library

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves <d...@earth.li>

* Package name: requests-ntlm
  Version : 1.0.0
  Upstream Author : Ben Toews <https://github.com/mastahyeti> et al
* URL : https://github.com/requests/requests-ntlm
* License : ISC
  Programming Lang: Python
  Description : HTTP NTLM authentication using the requests library

HttpNtlmAuth can be used in conjunction with a Session in order to make
use of connection pooling. Since NTLM authenticates connections, this
is more efficient. Otherwise, each request will go through a new NTLM
challenge-response.

This is a new dependency of pywinrm, and will be maintained as part of
the Python Modules Team.

Bug#834423: Can't reproduce

[Dominic Hargreaves]

Control: severity -1 important
Control tags -1 + unreproducible

This package builds for me on a current sid chroot, so downgrading.

Bug#689490: piuparts blocking testing migration

[Dominic Hargreaves]

On Sat, Dec 17, 2016 at 10:03:40AM +0100, Julien Cristau wrote:
> On Fri, Dec 16, 2016 at 22:38:16 +0000, Dominic Hargreaves wrote:
> 
> > Hi,
> > 
> > I must have missed the memo, but according to
> > 
> > https://qa.debian.org/excuses.php?package=ircd-hybrid
> > 
> > this package is not migrating because of a piuparts failure.
> > In fact, the failure is not caused by irc-hybrid directly, but because
> > of this bug in openssl:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689490
> > 
> I've told britney to ignore that failure for the next run.

Great, thanks!

Dominic.

Bug#689490: piuparts blocking testing migration

[Dominic Hargreaves]

Hi,

I must have missed the memo, but according to

https://qa.debian.org/excuses.php?package=ircd-hybrid

this package is not migrating because of a piuparts failure.
In fact, the failure is not caused by irc-hybrid directly, but because
of this bug in openssl:

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

It doesn't seem appropriate for this issue to block migration of
a package which uses openssl (I'm not even sure why this behaviour
is in violation of the FHS, although, although I can see why it is 
a problem in the context of maintainer scripts). And there doesn't seem
to be any plan to do anything with that bug before stretch is released.

What to do? It seems that the testing blocker needs to be smarter
about issues which are actually related to the package, or at least
for there to be a way to request an exception. Even better, reverting
to the idea of having manual review of piuparts output and then filing
RC bugs if appropriate seemed better, although maybe it was too much
work for people, which I do understand.

However at the moment people's packages risk being outdated in testing
for completely spurious reasons and maintainers not being told about
them. I only noticed this by chance.

Cheers,
Dominic.

Bug#847751: lurker: FHS violation: default configuration writes to files in /usr

[Dominic Hargreaves]

On Wed, Dec 14, 2016 at 06:05:42PM +0100, Jonas Meurer wrote:
> Hi Dominic,
> 
> Am 11.12.2016 um 13:10 schrieb Dominic Hargreaves:
> > Package: lurker
> > Version: 2.3-5+b1
> > Severity: serious
> > Justification: Policy 9.1.1
> > 
> > As of 2.3-1 the Debian package of lurker unfortunately started
> > violating the FHS, because it moved its HTML generation output to
> > /usr/share/lurker/www. According to the FHS[1] /usr must not be
> > written to in normal operations.
> 
> Thanks a lot for the bugreport. You're indeed right, that current lurker
> package violated the FHS.
> 
> > I discovered this whilst migrating a lurker installation to a new host.
> > As far as I can tell, this is a genuine cache, and so I rsynced
> > /usr/share/lurker/www/ to /var/cache/lurker/www/ and updated the
> > config file reference, and everything still worked.
> > 
> > Fixing this in the package would also involve cleaning up any
> > left-over cache in /usr/share/lurker/www. It's probably not safe
> > to do this in an automated way, so a similar news item as the one
> > used in 2.3-1 would be needed.
> 
> In your patch you suggest to move the htdocs dir to
> /var/cache/lurker/www. The Problem with this directory is that it's not
> guaranteed to be kept. /var/cache is allowed to be a volatile
> filesystem. See Section 5.5.1 of the FHS:
> 
> "The application must be able to regenerate or restore the data. Unlike
> /var/spool, the cached files can be deleted without data loss. The data
> must remain valid between invocations of the application and rebooting
> the system."
> 
> (http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varcacheApplicationCacheData)
> 
> Thus I suggest to move the htdocs to /var/lib/lurker/www instead. I'll
> modify your patch accordingly.

Well, it is definitely a cache, so it would be nice to put it in
/var/cache to avoid being backed up. The only problem is that the
initial hierachy is not created on the fly by lurker, right?

If the permissions are tweaked so that the web server user can write
out the hierachy including image symlink, maybe that can be done.

Cheers,
Dominic.

Bug#848041: [request-tracker-maintainers] Bug#848041: request-tracker4 requires allow-blessed in Web.pm

[Dominic Hargreaves]

On Tue, Dec 13, 2016 at 04:55:37AM -0900, James Zuelow wrote:
> I run request-tracker4, apache2, and postfix.  I've been tracking testing in 
> order to get a newer version of request-tracker4 than is available in Jessie.
> 
> After upgrading request-tracker4 when I run the unmodified package, Apache 
> generates a 500 internal
> server error as such:
> 
> x
> 
> [31143] [Tue Dec 13 13:29:06 2016] [error]: encountered object '1', but 
> neither allow_blessed, convert_blessed nor allow_tags settings are enabled 
> (or TO_JSON/FREEZE method missing) at /usr/share/perl5/JSON.pm line 154.
> 
> Stack:
>   [/usr/share/perl5/JSON.pm:154]
>   [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:197]
>   [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:4065]
>   [/usr/share/request-tracker4/html/Elements/JavascriptConfig:79]
>   [/usr/share/request-tracker4/html/Elements/Header:64]
>   [/usr/share/request-tracker4/html/index.html:4]
>   [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:681]
>   [/usr/share/request-tracker4/lib/RT/Interface/Web.pm:369]
>   [/usr/share/request-tracker4/html/autohandler:53] 
> (/usr/share/request-tracker4/lib/RT/Interface/Web/Handler.pm:209)
> 
> xx
> 
> I've tried updating JSON via CPAN, etc. without success.  However a simple 
> addition to Web.pm resolves the issue.  I've been running this modification 
> in production without any issues.  There has been at least one other person 
> on rt-users that has needed this in conjunction with a Debian install, so I'm 
> fairly sure that this isn't being caused by a local modification.  (Unless 
> we've both made the same modification without realizing it.)  However Best 
> Practical hasn't responded on: rt-users, so this may be Debian specific.
> 
> Patch for /usr/share/request-tracker4/lib/RT/Interface/Web.pm:
> 
> xx
> 
> --- Web.pm  2016-12-13 04:40:12.199936566 -0900
> +++ Web-jfz.pm  2016-12-13 04:39:53.643473002 -0900
> @@ -194,7 +194,7 @@
>  =cut
>  
>  sub EncodeJSON {
> -my $s = JSON::to_json(shift, { allow_nonref => 1 });
> +my $s = JSON::to_json(shift, { allow_blessed => 1, allow_nonref => 1 });
>  $s =~ s{/}{\\/}g;
>  return $s;
>  }
> 
> xx

> -- Package-specific info:
> Changed files:
>   usr/share/request-tracker4/lib/RT/Interface/Web.pm
> 
> There are locally modified files in /usr/local/share/request-tracker4/,
>  these may (or may not) be the source of the problem.

Hi James,

Sorry to hear that you are having problems. Just a quick question
before I dive into the code; can you clarify what web server interface
you are using (mod_perl or something else), and whether you can
reproduce the problem without your other local modifications. It 
would help if you could share the changes in
/usr/local/share/request-tracker4/ if they look relevant.

I note that this problem looks similar to one seen quite a while ago:

http://requesttracker.8502.n7.nabble.com/Update-to-RT-4-2-1-gt-JSON-error-after-login-td55890.html

and a similar problem is here:

http://www.perlmonks.org/?node_id=1159078

In both of those mod_perl is implicated, and maybe JSON::XS too.
You mention that JSON::XS is installed, but it's not a direct dependency
of RT - can you try uninstalling it (from the package and CPAN install)
and see if that makes a difference?

Cheers,
Dominic.

Bug#847514: Amazon::S3 vs. Net::Amazon::S3

[Dominic Hargreaves]

On Tue, Dec 13, 2016 at 09:03:07PM +, Christopher Hoskin wrote:
> I'd already done most of this at the weekend, so thought I might as
> well upload it. Hope you don't mind!
> 
> https://anonscm.debian.org/cgit/pkg-perl/packages/libamazon-s3-perl.git

Awesome. Thank you both!

Bug#847981: linux-image-4.8.0-2-amd64: kernel panic during bootup running under qemu/kvm

[Dominic Hargreaves]

On Mon, Dec 12, 2016 at 08:11:12PM +, Dominic Hargreaves wrote:
> The kernel panics immediately after bootup with the following console
> output:

I forgot to mention that problem isn't seen with either 4.6.4-1
or 3.16.7-ckt25-2+deb8u3 which are also installed.

Thanks for any assistance.

Dominic.

Bug#847981: linux-image-4.8.0-2-amd64: kernel panic during bootup running under qemu/kvm

[Dominic Hargreaves]

Package: src:linux
Version: 4.8.11-1
Severity: important

The kernel panics immediately after bootup with the following console
output:

Loading Linux 4.8.0-2-amd64 ...
Loading initial ramdisk ...
/dev/vda1: clean, 832314/3932160 files, 10062334/15728128 blocks
[  147.464089] general protection fault:  [#1] SMP
[  147.464556] Modules linked in: ip_tables x_tables autofs4 ext4 crc16
jbd2 crc32c_generic fscrypto ecb mbcache ata_generic virtio_net
virtio_blk crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul
ablk_helper cryptd ata_piix psmouse ehci_pci uhci_hcd ehci_hcd libata
usbcore scsi_mod usb_common virtio_pci virtio_ring virtio floppy
[  147.465002] CPU: 1 PID: 16 Comm: ksoftirqd/1 Tainted: GW
4.8.0-2-amd64 #1 Debian 4.8.11-1
[  147.465002] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[  147.465003] task: 9805f6274dc0 task.stack: 9805f6278000
[  147.465003] RIP: 0010:[]  []
put_cred_rcu+0x67/0xb0
[  147.465007] RSP: 0018:9805f627bde0  EFLAGS: 00010286
[  147.465007] RAX:  RBX: 9805f20c4158 RCX:
0252
[  147.465007] RDX: 0252 RSI: 826a9960 RDI:
8000
[  147.465008] RBP: 9805f20c40c0 R08: 9805f7099788 R09:
0100
[  147.465008] R10:  R11: 0009 R12:
9805f21c6758
[  147.465008] R13: 000a R14: 0004 R15:
9805ffc98f00
[  147.465009] FS:  () GS:9805ffc8()
knlGS:
[  147.465010] CS:  0010 DS:  ES:  CR0: 80050033
[  147.465010] CR2: 7f64f0209c68 CR3: 0002321f6000 CR4:
003406e0
[  147.465012] DR0:  DR1:  DR2:

[  147.465012] DR3:  DR6: fffe0ff0 DR7:
0400
[  147.465012] Stack:
[  147.465013]  82452040 9805ffc98f38 81ae0dfb

[  147.465014]  9805f627c000 9805f6274dc0 9805f1c87a58
0009
[  147.465016]  82405108  0009
0200
[  147.465017] Call Trace:
[  147.465020]  [] ? rcu_process_callbacks+0x1fb/0x5b0
[  147.465022]  [] ? __do_softirq+0xf8/0x290
[  147.465024]  [] ? run_ksoftirqd+0x25/0x40
[  147.465024]  [] ? smpboot_thread_fn+0xf9/0x150
[  147.465025]  [] ? sort_range+0x20/0x20
[  147.465026]  [] ? kthread+0xcd/0xf0
[  147.465027]  [] ? ret_from_fork+0x1f/0x40
[  147.465028]  [] ?
kthread_create_on_node+0x190/0x190
[  147.465028] Code: 1f 00 48 8b 7b d8 e8 b9 9f 1f 00 48 8b 43 f8 48 85
c0 74 05 f0 ff 08 74 33 48 8b 7b e8 e8 52 b2 fe ff 48 8b 7b f0 48 85 ff
74 09  ff 8f c0 00 00 00 74 11 48 89 ee 48 8b 3d 06 d6 c0 00 5b 5d
[  147.465041] RIP  [] put_cred_rcu+0x67/0xb0
[  147.465042]  RSP 
[  147.465044] ---[ end trace 45d38fba86842009 ]---
[  147.465044] Kernel panic - not syncing: Fatal exception in interrupt
[  147.466034] Kernel Offset: 0xa0 from 0x8100
(relocation range: 0x8000-0xbfff)
[  147.482959] ---[ end Kernel panic - not syncing: Fatal exception in
interrupt


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: QEMU
product_name: Standard PC (i440FX + PIIX, 1996)
product_version: pc-i440fx-2.1
chassis_vendor: QEMU
chassis_version: pc-i440fx-2.1
bios_vendor: SeaBIOS
bios_version: 1.7.5-20140531_083030-gandalf


** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] 
[8086:1237] (rev 02)
Subsystem: Red Hat, Inc Qemu virtual machine [1af4:1100]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:03.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #1 [8086:2934] (rev 03) (prog-if 00 [UHCI])
Subsystem: Red Hat, Inc QEMU Virtual Machine [1af4:1100]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:05.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon 
[1af4:1002]
Subsystem: Red Hat, Inc Virtio memory balloon [1af4:0005]
Physical Slot: 5
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
ii  grub-pc 2.02~beta3-3
pn  linux-doc-4.8   

Versions of packages linux-image-4.8.0-2-amd64 is related to:
pn  

Bug#847514: RFP: libamazon-s3-perl -- a portable client library for working with and managing Amazon S3 buckets and keys.

[Dominic Hargreaves]

[CCing rt-de...@lists.bestpractical.com]

On Sun, Dec 11, 2016 at 11:11:56AM +, Christopher Hoskin wrote:
> Amazon::S3 is a fork of  Net::Amazon::S3.
> 
> "This need for this module arose from some work that needed to work
> with S3 and would be distributed, installed and used on many various
> environments where compiled dependencies may not be an option.
> Net::Amazon::S3 used XML::LibXML tying it to that specific and often
> difficult to install option. In order to remove this potential barrier
> to entry, this module is forked and then modified to use XML::SAX via
> XML::Simple."
> 
> Since Net::Amazon::S3 is already packaged for Debian as
> libnet-amazon-s3-perl, the motivation for the fork does not apply to
> us. Also, Net::Amazon::S3 seems more actively maintained upstream
> (most recent release 2014 as opposed to 2009 for Amazon::S3).
> 
> I'm therefore wondering if patching RT to use Net::Amazon::S3 might be
> a better option? (I don't know how much work this would involve?)

I did think of this, but I assume that it wouldn't be in RT upstream's
interest to accept such a patch (for the reason stated in the above
justification for the fork), nor in Debian's interest to permanently
deviate from upstream in this way.

As for the concern about the Amazon::S3 being unmaintained - I
haven't done a detailed investigation but I would guess that the fact
that RT adopted it in their new release means that it is at least good
enough for them.

Upstream: can anyone comment on the decision to go with Amazon::S3
rather than Net::Amazon::S3?

Cheers,
Dominic.

Bug#847751: lurker: FHS violation: default configuration writes to files in /usr

[Dominic Hargreaves]

Control: tags -1 + patch

On Sun, Dec 11, 2016 at 12:10:04PM +, Dominic Hargreaves wrote:
> As of 2.3-1 the Debian package of lurker unfortunately started
> violating the FHS, because it moved its HTML generation output to
> /usr/share/lurker/www. According to the FHS[1] /usr must not be
> written to in normal operations.
> 
> I discovered this whilst migrating a lurker installation to a new host.
> As far as I can tell, this is a genuine cache, and so I rsynced
> /usr/share/lurker/www/ to /var/cache/lurker/www/ and updated the
> config file reference, and everything still worked.
> 
> Fixing this in the package would also involve cleaning up any
> left-over cache in /usr/share/lurker/www. It's probably not safe
> to do this in an automated way, so a similar news item as the one
> used in 2.3-1 would be needed.

Please find attached an initial patch. It's been lightly tested but
could do with some sanity checking.

Note that it's note quite a straight swap, because we've kept the
shipped images in /usr and symlinked them.

Cheers,
Dominic.
diff -Nru lurker-2.3/debian/changelog lurker-2.3/debian/changelog
--- lurker-2.3/debian/changelog	2014-07-24 11:31:10.0 +0100
+++ lurker-2.3/debian/changelog	2016-12-11 12:29:12.0 +
@@ -1,3 +1,11 @@
+lurker (2.3-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move default htdocs from /usr/share/lurker/www to /var/cache/lurker/www
+for FHS compliance (Closes: #847751)
+
+ -- Dominic Hargreaves <d...@earth.li>  Sun, 11 Dec 2016 12:25:55 +
+
 lurker (2.3-5) unstable; urgency=high
 
   * Acknowledge NMU. Thanks to Colin Watson. (closes: #734731)
diff -Nru lurker-2.3/debian/NEWS lurker-2.3/debian/NEWS
--- lurker-2.3/debian/NEWS	2011-09-19 11:51:07.0 +0100
+++ lurker-2.3/debian/NEWS	2016-12-11 12:54:50.0 +
@@ -1,3 +1,29 @@
+lurker (2.3-5.1) UNRELEASED; urgency=high
+
+  The lurker htdocs directory has been moved from /usr/share/lurker/www to
+  /var/cache/lurker/www in order to comply with the File Hierarchy Standard.
+  You will have to migrate custom files manually from /usr/share/lurker/www to
+  /var/cache/lurker/www, and update the configuration files in /etc/lurker
+  accordingly.
+  Mail archives are stored in the lurker database at /var/lib/lurker. The html
+  files are generated from this database, thus no archives will be lost.
+  Please remove the following files/directories after everything has been
+  migrated and tested:
+
+  /usr/share/lurker/www/attach
+  /usr/share/lurker/www/index.html
+  /usr/share/lurker/www/list
+  /usr/share/lurker/www/lurker.docroot
+  /usr/share/lurker/www/mbox
+  /usr/share/lurker/www/message
+  /usr/share/lurker/www/mindex
+  /usr/share/lurker/www/search
+  /usr/share/lurker/www/splash
+  /usr/share/lurker/www/thread
+  /usr/share/lurker/www/zap
+
+ -- Dominic Hargreaves <d...@earth.li>  Sun, 11 Dec 2016 12:21:15 +
+
 lurker (2.3-1) unstable; urgency=low
 
   The lurker htdocs directory has been moved from /var/www/lurker to
diff -Nru lurker-2.3/debian/postinst lurker-2.3/debian/postinst
--- lurker-2.3/debian/postinst	2014-07-24 11:20:51.0 +0100
+++ lurker-2.3/debian/postinst	2016-12-11 12:48:29.0 +
@@ -26,10 +26,9 @@
   chmod u=rwx,g=rwxs,o=rx /var/lib/lurker
 fi
 
-chown root:root /usr/share/lurker/www
 www_data_files="attach list lurker.docroot mbox message mindex search splash thread zap"
 for f in $www_data_files; do
-  chown -R www-data:www-data /usr/share/lurker/www/$f
+  chown -R www-data:www-data /var/cache/lurker/www/$f
 done
 
 # apache2 configuration section
diff -Nru lurker-2.3/debian/rules lurker-2.3/debian/rules
--- lurker-2.3/debian/rules	2013-12-13 00:51:52.0 +
+++ lurker-2.3/debian/rules	2016-12-11 12:41:21.0 +
@@ -35,7 +35,8 @@
 		--prefix=/usr \
 		--sysconfdir=/etc \
 		--localstatedir=/var \
-		--with-cgi-bin-dir=/usr/lib/cgi-bin/lurker
+		--with-cgi-bin-dir=/usr/lib/cgi-bin/lurker \
+		--with-default-www-dir=/var/cache/lurker/www
 	touch $@
 
 build-stamp: configure-stamp
@@ -74,6 +75,7 @@
 	echo "#" > lurker.conf.local
 	echo "# Mailing list configuration." >> lurker.conf.local
 	awk 'BEGIN { X=0 } { if ( X ) { print $$0'\n' } } /'"^# Mailing list configuration.$$"'/ { X=1 }' < lurker.conf >> lurker.conf.local
+	install -d $(CURDIR)/debian/lurker/usr/share/lurker/www
 	touch $@
 
 # Build architecture-independent files here.
@@ -93,8 +95,10 @@
 	dh_installexamples lurker.conf
 	dh_lintian
 	mv debian/lurker/etc/apache2/conf-available/apache.conf debian/lurker/etc/apache2/conf-available/lurker.conf
-	mv debian/lurker/usr/share/lurker/www/ui debian/lurker/etc/lurker
-	dh_link etc/lurker/ui usr/share/lurker/www/ui
+	mv debian/lurker/var/cache/lurker/www/ui debian/lurker/etc/l

Bug#847751: lurker: FHS violation: default configuration writes to files in /usr

[Dominic Hargreaves]

Package: lurker
Version: 2.3-5+b1
Severity: serious
Justification: Policy 9.1.1

As of 2.3-1 the Debian package of lurker unfortunately started
violating the FHS, because it moved its HTML generation output to
/usr/share/lurker/www. According to the FHS[1] /usr must not be
written to in normal operations.

I discovered this whilst migrating a lurker installation to a new host.
As far as I can tell, this is a genuine cache, and so I rsynced
/usr/share/lurker/www/ to /var/cache/lurker/www/ and updated the
config file reference, and everything still worked.

Fixing this in the package would also involve cleaning up any
left-over cache in /usr/share/lurker/www. It's probably not safe
to do this in an automated way, so a similar news item as the one
used in 2.3-1 would be needed.

[1] 


-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages lurker depends on:
ii  adduser  3.113+nmu3
ii  apache2 [httpd-cgi]  2.4.10-10+deb8u7
ii  apache2-mpm-prefork [httpd-cgi]  2.4.10-10+deb8u7
ii  debconf [debconf-2.0]1.5.56
ii  libc62.19-18+deb8u6
ii  libgcc1  1:4.9.2-10
ii  libmimelib1c2a   5:1.1.4-2
ii  libstdc++6   4.9.2-10
ii  lighttpd [httpd-cgi] 1.4.35-4+deb8u1
ii  passwd   1:4.2-3+deb8u1
ii  ucf  3.0030
ii  xsltproc 1.1.28-2+deb8u2
ii  zlib1g   1:1.2.8.dfsg-2+b1

lurker recommends no packages.

Versions of packages lurker suggests:
ii  gnupg1.4.18-7+deb8u3
ii  mailman  1:2.1.18-2+deb8u1

-- Configuration Files:
/etc/lurker/apache.conf 4c1675809ae49b7e0fe08dcca45f00f0 [Errno 2] No such file 
or directory: u'/etc/lurker/apache.conf 4c1675809ae49b7e0fe08dcca45f00f0'
/etc/lurker/lurker.conf.local changed [not included]

-- debconf information excluded

Bug#847377: closed by Adrian Bunk <b...@stusta.de> (You already maintain this package in Debian)

[Dominic Hargreaves]

On Fri, Dec 09, 2016 at 10:03:05PM +, Debian Bug Tracking System wrote:

> Dominic, you sent an RFP for a package you already maintain in Debian:
>   https://tracker.debian.org/pkg/libnet-ldap-server-test-perl
> 
> :-)

Oh, how embarrassing :) I could have sworn I'd double checked that list;
apparently not.

Thanks,
Dominic.

Bug#847516: RFP: libnet-dns-lite-perl -- libnet-dns-lite-perl

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist

* Package name: libnet-dns-lite-perl
  Version : 0.12
  Upstream Author : Kazuho Oku 
* URL : https://metacpan.org/pod/Net::DNS::Lite
* License : Perl
  Programming Lang: Perl
  Description :  a pure-perl DNS resolver with support for timeout

This module provides a replacement function for Socket::inet_aton, with
support for timeouts.

This is a requirement of File::Dropbox which is a requirement for
RT 4.4 which I hope to have packaged in time for stretch. I will look
at packaging this in the next couple of weeks, but if someone else in
the Perl team is able to look at this sooner, that'd be ideal.

Bug#847515: RFP: libfile-dropbox-perl -- convenient and fast Dropbox API abstraction

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist

* Package name: libfile-dropbox-perl
  Version : 0.7
  Upstream Author : Alexander Nazarov 
* URL : https://metacpan.org/pod/File::Dropbox
* License : Perl
  Programming Lang: Perl
  Description : convenient and fast Dropbox API abstraction

File::Dropbox provides high-level Dropbox API abstraction based on
Tie::Handle. Code required to get access_token and access_secret for
signed OAuth 1.0 requests or access_token for OAuth 2.0 requests is
not included in this module. To get app_key and app_secret you need
to register your application with Dropbox.

At this moment Dropbox API is not fully supported, File::Dropbox
covers file read/write and directory listing methods. If you need full
API support take look at WebService::Dropbox. File::Dropbox main
purpose is not 100% API coverage, but simple and high-performance
file operations.

This is a requirement of RT 4.4 which I hope to have packaged in time
for stretch. I will look at packaging this in the next couple of weeks,
but if someone else in the Perl team is able to look at this sooner,
that'd be ideal.

Bug#847514: RFP: libamazon-s3-pelr -- a portable client library for working with and managing Amazon S3 buckets and keys.

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist

* Package name: libamazon-s3-perl
  Version : 0.45
  Upstream Author : Timothy Appnel 
* URL : https://metacpan.org/pod/Amazon::S3
* License : Artistic
  Programming Lang: Perl
  Description : a portable client library for working with and managing 
Amazon S3 buckets and keys.

Amazon::S3 provides a portable client interface to Amazon Simple Storage
System (S3).

This need for this module arose from some work that needed to work with S3
and would be distributed, installed and used on many various environments
where compiled dependencies may not be an option. Net::Amazon::S3 used
XML::LibXML tying it to that specific and often difficult to install
option. In order to remove this potential barrier to entry, this module
is forked and then modified to use XML::SAX via XML::Simple.

Amazon::S3 is intended to be a drop-in replacement for Net:Amazon::S3
that trades some performance in return for portability.

This is a requirement of RT 4.4 which I hope to have packaged in time
for stretch. I will look at packaging this in the next couple of weeks,
but if someone else in the Perl team is able to look at this sooner,
that'd be ideal.

Bug#847378: RFP: libnet-ldap-sid-perl -- Active Directory Security Identifier manipulation

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist

* Package name: libnet-ldap-sid-perl
  Version : 0.001
  Upstream Author : Peter Karman 
* URL : https://metacpan.org/pod/Net::LDAP::SID
* License : Perl
  Programming Lang: Perl
  Description : Active Directory Security Identifier manipulation

This perl module provides conversion routines between string and binary
forms of SIDs.

This is a dependency of libnet-ldap-server-test-perl, proposed in #847377.

This is a requirement of RT 4.4 which I hope to have packaged in time
for stretch. I will look at packaging this in the next couple of weeks,
but if someone else in the Perl team is able to look at this sooner,
that'd be ideal.

Bug#847377: RFP: libnet-ldap-server-test-perl -- a lightweight LDAP server for use in Net::LDAP testing

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist

X-Debbugs-Cc: debian-p...@lists.debian.org

* Package name: libnet-ldap-server-test-perl
  Version : 0.21
  Upstream Author : Peter Karman 
* URL : 
https://metacpan.org/release/KARMAN/Net-LDAP-Server-Test-0.21
* License : Perl
  Programming Lang: Perl
  Description : a lightweight LDAP server for use in Net::LDAP testing

Now you can test your Net::LDAP code without having a real LDAP server
available. This module offers a simple perl interface to starting up
a test LDAP server and populating it with Net::LDAP::Entry objects
(in-memory). Add, delete and modify operations are supported.

This is a requirement of RT 4.4 which I hope to have packaged in time
for stretch. I will look at packaging this in the next couple of weeks,
but if someone else in the Perl team is able to look at this sooner,
that'd be ideal.

Bug#836110: Remove export of PERL_USE_UNSAFE_INC in the future

[Dominic Hargreaves]

On Wed, Oct 05, 2016 at 05:58:00AM +, Niels Thykier wrote:
> On Tue, 30 Aug 2016 17:35:41 +0100 Dominic Hargreaves <d...@earth.li> wrote:
> > Package: debhelper
> > Version: 9.20160814
> > Severity: wishlist
> > X-Debbugs-Cc: p...@packages.debian.org
> > User: debian-p...@lists.debian.org
> > Usertags: perl-cwd-inc-removal
> > 
> > On Tue, Aug 30, 2016 at 03:59:00PM +, Niels Thykier wrote:
> > > Dominic Hargreaves:
> > > > Hi maintainers,
> > > > 
> > > > Thanks very much for applying the patches in #832436 for the
> > > > remove-cwd-in-inc issue in perl. One of these changes, to export
> > > > PERL_USE_UNSAFE_INC, is not a good long-term solution, and I will file
> > > > bugs against packages which would otherwise be broken in due course
> > > > with a view to requesting removal of that export in debhelper at some
> > > > point after stretch's release.
> > > > 
> > > > Would you be happy for me to file a wishlist bug against this to act
> > > > as a reminder, and to block with the bugs I will file against affected
> > > > packages?
> > > > 
> > > > No hurry on this, but I wanted to make sure it didn't get forgotten.
> > > > 
> > > > Cheers,
> > > > Dominic.
> > > > 
> > > > [...]
> > > 
> > [...]
> > 
> 
> Hi Dominic,
> 
> Did you file some of the blockers already?  If so, they don't seem to be
> tagged as blockers of this bug. :)

Hi Niels,

(and sorry about the silence).

No, not yet. That will need a full rebuild with the debhelper change
reverted, and I'm unlikely to have time to do that until the new year.

Cheers,
Dominic.

Bug#846029: request-tracker4: uses deprecated gpg1

[Dominic Hargreaves]

Source: request-tracker4
Version: 4.2.13-4
Severity: normal

Since #845534 was fixed RT now uses gpg1, which is deprecated, or at
least its uses discouraged, in Debian.

Fixing this is blocked by #845781.

Dominic.

Bug#839580: [request-tracker-maintainers] Bug#839580: Bug#839580: request-tracker4: FTBFS in testing (failed tests)

[Dominic Hargreaves]

On Thu, Nov 24, 2016 at 12:01:20PM +, Dominic Hargreaves wrote:
> Firstly, I'm sorry that you didn't get any response on this, and thank
> you for pushing this issue. I must confess to being rather frustrated
> by the situation as well as not having any spare cycles for Debian
> work for a while.
> 
> It seems like at least for RT, any update to a version of
> libgnupg-interface-perl which drops support for gpg1 is going to be
> quite invasive, because the RT test suite depends on a particular
> version of gpg. I note you didn't get any response on the gnupg upstream
> portability issue - was there any other progress on that front? It
> would certainly be much easier for upstream to take the patchset if
> it didn't break compatibility with GPG1 (even if we might be able to
> do so in Debian).
> 
> I will try and do some testing with RT and the version of this pacakge
> in experimental. Do you have any idea whether the other rdeps are
> similarly sensitive?
> 
> FTR, I've just filed #845534 about another related issue which I failed
> to spot; RT is currently configured to use gpg1 for tests, but the default
> (which is now gpg2) at runtime, and that probably doesn't work.
> 
> (GPG isn't that commonly used in RT, so I wouldn't be surprised if this
> hasn't been road tested in sid :( )

FTR: I've filed #845781 against libgnupg-interface-perl, which is
probably the right place to continue this discussion.

Best,
Dominic.

Bug#845781: libgnupg-interface-perl: in-band passphrases do not work with gpg2

[Dominic Hargreaves]

Package: libgnupg-interface-perl
Version: 0.52-5
Severity: important
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=102651
X-Debbugs-Cc: d...@fifthhorseman.net

As documented in the discussions at #839580 this package doesn't
support in-band passphrases with gpg2. This was worked around in 
RT to use gpg1 again.

This is fixed in 0.52-6 which is currently in experimental, but
this isn't backwards-compatible to earlier versions of gpg due to [1].

That said, it's probably preferable to upload this to unstable once it's
been tested a bit more than to rely on gpg1 for the stretch cycle.

dkg's suggestion on the upstream mailing list looks plausible:

"One way to resolve this would be to add --pinentry-mode=loopback as a
dummy no-op parameter to classic and modern.  This doesn't help for old
installations, of course, but if someone can upgrade within a given
series, it would at least let the bindings work."

dkg - should we just go ahead and do this in gnupg1 in Debian?
This would AFAICT be preferable to a coordinated upgrade between
libgnupg-interface-perl and RT (and I would guess this problem would
arise in other places too).

Thanks for all your work on this so far!

Dominic.

[1] 

Bug#839580: [request-tracker-maintainers] Bug#839580: request-tracker4: FTBFS in testing (failed tests)

[Dominic Hargreaves]

On Wed, Nov 23, 2016 at 06:26:45PM -0500, Daniel Kahn Gillmor wrote:
> On Tue 2016-10-11 23:48:15 -0400, Daniel Kahn Gillmor wrote:
> > Those patches are posted here:
> >
> >  https://github.com/bestpractical/gnupg-interface/pull/1
> >
> > I'd like to upload them to debian as well, though they are *not*
> > interoperable with versions of GnuPG prior to 2.1.x, due to GnuPG's
> > non-portable interface :/ I've pushed a proposed upload to experimental
> > to the move-to-modern-gnupg branch on
> > https://anonscm.debian.org/git/pkg-perl/packages/libgnupg-interface-perl.git
> >
> > (see also discussion around this portability issue here:
> > https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031800.html)
> >
> > sigh...
> >
> > Any thoughts on the right thing to do with libgnupg-interface-perl?
> 
> I haven't heard anything about this -- either from upstream, or from
> other debian perl or gnupg folks.  I've gone ahead with the experimental
> upload, so please let me know if you see this causing trouble.

Hi Daniel,

Firstly, I'm sorry that you didn't get any response on this, and thank
you for pushing this issue. I must confess to being rather frustrated
by the situation as well as not having any spare cycles for Debian
work for a while.

It seems like at least for RT, any update to a version of
libgnupg-interface-perl which drops support for gpg1 is going to be
quite invasive, because the RT test suite depends on a particular
version of gpg. I note you didn't get any response on the gnupg upstream
portability issue - was there any other progress on that front? It
would certainly be much easier for upstream to take the patchset if
it didn't break compatibility with GPG1 (even if we might be able to
do so in Debian).

I will try and do some testing with RT and the version of this pacakge
in experimental. Do you have any idea whether the other rdeps are
similarly sensitive?

FTR, I've just filed #845534 about another related issue which I failed
to spot; RT is currently configured to use gpg1 for tests, but the default
(which is now gpg2) at runtime, and that probably doesn't work.

(GPG isn't that commonly used in RT, so I wouldn't be surprised if this
hasn't been road tested in sid :( )

Cheers,
Dominic.

Bug#845534: request-tracker4: Tests against gpg1 but runs with gpg2

[Dominic Hargreaves]

Source: request-tracker4
Version: 4.2.13-3
Severity: important

After the changes in libgnupg-interface-perl and the fixes to the test
suite in 4.2.13-3 (see #839580), we are no longer testing this
functionality effectively. We should probably revert no_gpg_hardcoding.diff
and make sure we hardcode gpg1 at runtime so that the test suite and
runtime behaviour matches again.

Dominic.

Bug#845252: debget: README.Debian more than a decade out of date

[Dominic Hargreaves]

Package: debget
Version: 1.6+nmu3
Severity: minor
Tags: patch pending

Dear maintainer,

README.Debian containts advice about libnet config which has been wrong
for more than a decade, when the libnet config was moved to /etc/perl.

I've prepared an NMU for debget (versioned as 1.6+nmu4) and
uploaded it to DELAYED/XX. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru debget-1.6+nmu3/debian/changelog debget-1.6+nmu4/debian/changelog
--- debget-1.6+nmu3/debian/changelog	2016-02-15 01:19:13.0 +
+++ debget-1.6+nmu4/debian/changelog	2016-11-21 19:10:44.0 +
@@ -1,3 +1,11 @@
+debget (1.6+nmu4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove advice about libnet config which has been out of date for
+more than a decade
+
+ -- Dominic Hargreaves <d...@earth.li>  Mon, 21 Nov 2016 19:10:03 +
+
 debget (1.6+nmu3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru debget-1.6+nmu3/debian/README.debian debget-1.6+nmu4/debian/README.debian
--- debget-1.6+nmu3/debian/README.debian	1999-04-05 15:59:54.0 +0100
+++ debget-1.6+nmu4/debian/README.debian	2016-11-21 19:13:25.0 +
@@ -1,25 +1,9 @@
 This program uses Perl's Net::FTP library to do its FTP transfers.  The
-library has global configuration information stored (with our current
-Perl layout) in /usr/lib/perl5/Net/Config.pm.  If you need to, eg, have
-all external transfers use passive FTP, you'd want the ftp_ext_passive
-config variable to be set to a true value.  The library can also be
-configured to use a proxy, and probably other things.
-
-The Debian package which contains Net::FTP doesn't give you a good way
-to customize this file right now, though.  If you know what changes you
-need to make to it you can either make them by hand every time you update
-libnet-perl, or divert the package's copy of this file.
-
-If you don't know what changes you need to make, download the source
-package and use its interactive configuration program:
-
-debget --unpack libnet-perl &&
-	cd libnet-perl-* &&
-	perl Configure
-
-This will create a file called "libnet.cfg" in the source directory,
-it can be used as /usr/lib/perl5/Net/Config.pm.
+library has global configuration information stored in
+/etc/perl/Net/libnet.cfg. If you need to, eg, have all external transfers
+use passive FTP, you'd want the ftp_ext_passive config variable to be set
+to a true value.  The library can also be configured to use a proxy, and
+probably other things.
 
 Roderick Schertler <roder...@argon.org>
-
-$Id: README.debian,v 1.1 1999-04-05 14:59:54 roderick Exp $
+Dominic Hargreaves <d...@earth.li>