Bug#882648: exim4: remote code execution in chunking

[Dominic Hargreaves]

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

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

- Forwarded message from Phil Pennock  -

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

Folks,

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

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

  chunking_advertise_hosts =

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

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

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

-Phil



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


- End forwarded message -

Bug#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#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#907974: perl-doc-html: Should be updated to 5.28 at the point of the transition

[Dominic Hargreaves]

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

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

Possible alternative source:

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

Bug#919059: ensymble: Time to retire

[Dominic Hargreaves]

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

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

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

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

Cheers,
Dominic.

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

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

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

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


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

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


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/920744

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

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

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

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


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

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


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/920744

Bug#762638: metaconfig source control/distribution and Debian's DFSG

[Dominic Hargreaves]

On Sat, Nov 01, 2014 at 02:41:58PM +, Dominic Hargreaves wrote:
> I will propose within Debian that we package up the modified dist
> package and metaconfig units, and include documentation in the perl
> source package about this.

After discussions with Helmut at Debconf, it seems like all we can
reasonably do in Debian is to make it clear that the current situation
is explicitly supported by Debian, rather than spending effort with
metaconfig. As such, I propose we close this bug with something like the
attached documentation patch.

Cheers,
Dominic.
>From 72c6dc60df6cb46a77986f96ed29643a8ec9b55c Mon Sep 17 00:00:00 2001
From: Dominic Hargreaves 
Date: Mon, 17 Aug 2015 18:45:25 +0200
Subject: [PATCH] Document the special case of modifying Configure in in
 debian/README.Source (Closes: #762638)

---
 debian/README.source | 12 
 debian/changelog |  7 +++
 2 files changed, 19 insertions(+)

diff --git a/debian/README.source b/debian/README.source
index f4b7dbb..7cbbba8 100644
--- a/debian/README.source
+++ b/debian/README.source
@@ -125,6 +125,18 @@ then
 prove debian/t/*.t
 fi
 
+A special note on patching Configure
+
+
+The Configure file is a special case of a file which is autogenerated
+upstream by specialised tools, but which upstream explicitly declares
+it as being (a) preferred form of modification. As far as Debian goes,
+this means that we should generally not try to regenerate it, but patch
+it directly (forwarding patches upstream when needed).
+
+Please see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762638>
+for a discussion about this issue.
+
 Credits
 ---
 
diff --git a/debian/changelog b/debian/changelog
index 14f18df..539206c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+perl (5.22.0-3) UNRELEASED; urgency=medium
+
+  * Document the special case of modifying Configure in
+in debian/README.Source (Closes: #762638)
+
+ -- Dominic Hargreaves   Mon, 17 Aug 2015 18:44:44 +0200
+
 perl (5.22.0-2) experimental; urgency=medium
 
   * Drop the ExtUtils::MakeMaker changes we've been carrying for much too long
-- 
2.1.4

Bug#787450: inn: diff for NMU version 1:1.7.2q-44.1

[Dominic Hargreaves]

Control: tags 787450 + pending

Dear maintainer,

I've prepared an NMU for inn (versioned as 1:1.7.2q-44.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.
Dominic.
diff -u inn-1.7.2q/debian/changelog inn-1.7.2q/debian/changelog
--- inn-1.7.2q/debian/changelog
+++ inn-1.7.2q/debian/changelog
@@ -1,3 +1,11 @@
+inn (1:1.7.2q-44.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply fix from gregor herrmann fixing FTBFS with newer pod2man
+(Closes: #787450)
+
+ -- Dominic Hargreaves   Thu, 20 Aug 2015 15:56:52 +0200
+
 inn (1:1.7.2q-44) unstable; urgency=medium
 
   * inn.service: remove NoNewPrivileges=yes because it prevents innd
diff -u inn-1.7.2q/debian/rules inn-1.7.2q/debian/rules
--- inn-1.7.2q/debian/rules
+++ inn-1.7.2q/debian/rules
@@ -65,7 +65,7 @@
 
 	cp extra/innreport_inn.pm $D/usr/lib/news/
 	install -m 755 extra/send-uucp.pl extra/innreport $D/usr/lib/news/bin/
-	pod2man --section=8 < extra/send-uucp.pl \
+	pod2man --section=8 extra/send-uucp.pl \
 		> $D/usr/share/man/man8/send-uucp.8
 
 	# these scripts contain an unfixable bashism

Bug#797087: debian-design: FTBFS: "reclass" unexpectedly returned exit value 7

[Dominic Hargreaves]

Source: debian-design
Version: 3
Severity: serious
Tags: sid stretch
Justification: FTBFS

This package FTBFS in a clean sid chroot:

cd content/desktop/animation/ \
&& boxer compose \
--nodedir /«PKGBUILDDIR»/nodes \
--skeldir /«PKGBUILDDIR»/skel \
--suite jessie \
desktop-animation
Class 'Admin.apt.aptitude' (in ancestry of node './desktop-animation') not 
found under yaml_fs:///usr/share/boxer/jessie/classes
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/reclass/storage/yaml_fs/__init__.py", 
line 93, in get_class
path = os.path.join(self.classes_uri, self._classes[name])
KeyError: 'Admin.apt.aptitude'

"reclass" unexpectedly returned exit value 74 at (eval 168) line 12.
 at /usr/share/perl5/Boxer/Task/Classify.pm line 69
make[1]: *** [content/desktop/animation/preseed.cfg] Error 74
Makefile:17: recipe for target 'content/desktop/animation/preseed.cfg' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [content/desktop/preseed.cfg] Error 2


Cheers,
Dominic.

Bug#797088: dune-pdelab: FTBFS: undefined reference to `Dune::concatPaths

[Dominic Hargreaves]

Source: dune-pdelab
Version: 2.0.0-1
Severity: serious
Tags: sid stretch
Justification: FTBFS

This package FTBFS in a clean sid chroot:

libtool: link: g++ -std=c++11 -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -fpermissive -Wl,-z -Wl,relro -o .libs/testanalytic 
testanalytic-
testanalytic.o -pthread  ../../../lib/.libs/libdunepdelab.so -ldunetypetree -ldu
negeometry -ldunecommon -L/usr//lib -L/usr/lib/openmpi/lib -lmpi -ldl -lhwloc -l
ugS2 -lugS3 -ldevS -L/usr/lib/x86_64-linux-gnu -ldunealbertagrid_2d -ldunegrid -
L/usr/lib -lalberta_2d -lalberta_utilities -lm -pthread
testanalytic-testanalytic.o: In function `Dune::VTKWriter const, (Dune::PartitionIteratorType)4
> > >::pwrite(std::__cxx11::basic_string, std::allo
cator > const&, std::__cxx11::basic_string, s
td::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, Dune::VTK::OutputType, int, int)':
/usr/include/dune/grid/io/file/vtk/vtkwriter.hh:686: undefined reference to `Dun
e::concatPaths(std::__cxx11::basic_string, std::all
ocator > const&, std::__cxx11::basic_string, 
std::allocator > const&)'
/usr/include/dune/grid/io/file/vtk/vtkwriter.hh:687: undefined reference to `Dun
e::relativePath(std::__cxx11::basic_string, std::al
locator > const&, std::__cxx11::basic_string,
 std::allocator > const&)'
testanalytic-testanalytic.o: In function 
`Dune::VTKWriter
 const, (Dune::PartitionIteratorType)4> > 
>::getSerialPieceName(std::__cxx11::basic_string, 
std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) const':
/usr/include/dune/grid/io/file/vtk/vtkwriter.hh:603: undefined reference to 
`Dune::concatPaths(std::__cxx11::basic_string, 
std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&)'
collect2: error: ld returned 1 exit status
make[7]: *** [testanalytic] Error 1
Makefile:1441: recipe for target 'testanalytic' failed
make[7]: Leaving directory '/«PKGBUILDDIR»/dune/pdelab/test'
make[6]: *** [check-am] Error 2
Makefile:2344: recipe for target 'check-am' failed
make[6]: Leaving directory '/«PKGBUILDDIR»/dune/pdelab/test'
make[5]: *** [check-recursive] Error 1
Makefile:1907: recipe for target 'check-recursive' failed
make[5]: Leaving directory '/«PKGBUILDDIR»/dune/pdelab/test'
make[4]: *** [check-recursive] Error 1
Makefile:645: recipe for target 'check-recursive' failed
make[4]: Leaving directory '/«PKGBUILDDIR»/dune/pdelab'
make[3]: *** [check-recursive] Error 1
Makefile:624: recipe for target 'check-recursive' failed
make[3]: Leaving directory '/«PKGBUILDDIR»/dune'
make[2]: *** [check-recursive] Error 1
Makefile:798: recipe for target 'check-recursive' failed
make[2]: Leaving directory '/«PKGBUILDDIR»'
dh_auto_test: make -j1 check returned exit code 2
make[1]: *** [override_dh_auto_test] Error 2
/usr/share/dune/dune-debian.mk:20: recipe for target 'override_dh_auto_test' 
failed
make[1]: Leaving directory '/«PKGBUILDDIR»'

Cheers,
Dominic.

Bug#797090: konversation: FTBFS: *** No rule to make target '/usr/lib/libsoprano.so'

[Dominic Hargreaves]

Source: konversation
Version: 1.5-2
Severity: serious
Tags: sid stretch
Justification: FTBFS

This package FTBFS in a clean sid chroot:

[ 76%] Building CXX object src/CMakeFiles/konversation.dir/preferences_base.o
cd src && /usr/bin/c++   -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=26 -DKDE_DEPRECATED_WA
RNINGS -DQT_NO_CAST_TO_ASCII -DQT_NO_STL -DQT_USE_FAST_CONCATENATION -DQT_USE_FA
ST_OPERATOR_PLUS -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_REENTRANT -D_XOPEN_SOURCE=50
0 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SO
URCE=2  -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts
 -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -
fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibil
ity=hidden -Werror=return-type -fvisibility-inlines-hidden -DNDEBUG -DQT_NO_DEBU
G -I. -I../../src -I../.. -I.. -I../../src/config -I../../src/dcc -I../../src/ir
c -I../../src/viewer -I../../src/linkaddressbook -I../../src/upnp -I/usr/include
/KDE -I/usr/include/qt4/KDE -I/usr/include/qt4 -I/usr/include/qt4/phonon -I/usr/
include/qt4/QtXmlPatterns -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtUiTools 
-I/usr/include/qt4/QtTest -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtSql -I/u
sr/include/qt4/QtScriptTools -I/usr/include/qt4/QtScript -I/usr/include/qt4/QtNe
twork -I/usr/include/qt4/QtHelp -I/usr/include/qt4/QtDesigner -I/usr/include/qt4
/QtDeclarative -I/usr/include/qt4/QtDBus -I/usr/include/qt4/Qt3Support 
-I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt 
-I/usr/share/qt4/mkspecs/default -I/usr/include/QtCrypto-D_GNU_SOURCE 
-D_LARGEFILE64_SOURCE -o CMakeFiles/konversation.dir/preferences_base.o -c 
preferences_base.cpp
make[3]: *** No rule to make target '/usr/lib/libsoprano.so', needed by 
'src/konversation'.  Stop.
make[3]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu'
make[2]: *** [src/CMakeFiles/konversation.dir/all] Error 2
CMakeFiles/Makefile2:110: recipe for target 
'src/CMakeFiles/konversation.dir/all' failed
make[2]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu'
make[1]: *** [all] Error 2
dh_auto_build: make -j1 returned exit code 2

Cheers,
Dominic.

Bug#797089: ggcov: FTBFS: tests fail

[Dominic Hargreaves]

Source: ggcov
Version: 0.9-7
Severity: serious
Tags: sid stretch
Justification: FTBFS

This package FTBFS in a clean sid chroot:

Running tests
hostname: "kale"
date: "20150827T092647"
uname -s: "Linux"
uname -m: "x86_64"
uname -r: "4.1.0-1-amd64"
head -1 /etc/os-release: "PRETTY_NAME="Debian GNU/Linux stretch/sid""
which gcc: "/usr/bin/gcc"
gcc --version: "gcc (Debian 5.2.1-15) 5.2.1 20150808"
which g++: "/usr/bin/g++"
g++ --version: "g++ (Debian 5.2.1-15) 5.2.1 20150808"
PASS: (test000) unit tests
ERROR: (test001) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test002) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test004) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test005.1) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test006) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test007) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test008.0) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test009) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test010) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test011.1) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test013) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test014) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test015.a001) tggcov failed, see log or re-run with -D all,verbose --no-
log
ERROR: (test016.1) tggcov failed, see log or re-run with -D all,verbose --no-log
PASS: (test021) unit test for libpopt / fakepopt.c
ERROR: (test029) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test030) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test033) tggcov failed, see log or re-run with -D all,verbose --no-log
ERROR: (test034) tggcov failed, see log or re-run with -D all,verbose --no-log
Total: 2/20 tests passed
make[1]: *** [override_dh_auto_test] Error 1

Cheers,
Dominic.

Bug#797289: libxml-easyobj-perl: FTBFS: Can't locate object method "getXMLDecl" via package "XML::DOM::Element"

[Dominic Hargreaves]

Source: libxml-easyobj-perl
Version: 1.12-3
Severity: serious
Justification: FTBFS

This package FTBFS in a clean sid chroot:

Can't locate object method "getXMLDecl" via package "XML::DOM::Element" at /usr/
share/perl5/XML/DOM.pm line 1221.
t/write.t . 
1..11
# Running under perl version 5.020002 for linux
# Current time local: Fri Aug 28 19:12:33 2015
# Current time GMT:   Fri Aug 28 19:12:33 2015
# Using Test.pm version 1.26
ok 1
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 10/11 subtests 
Failed 1/5 test programs. 0/33 subtests failed.

Test Summary Report
---
t/write.t   (Wstat: 65280 Tests: 1 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 11 tests but ran 1.
Files=5, Tests=33,  1 wallclock secs ( 0.07 usr  0.05 sys +  1.16 cusr  0.14 
csys =  1.42 CPU)
Result: FAIL

Cheers,
Dominic.

Bug#797292: regina-normal: FTBFS: undefined reference to `srchilite::Utils::toupper...

[Dominic Hargreaves]

Source: regina-normal
Version: 4.96-2
Severity: serious
Justification: FTBFS

This package FTBFS in a clean sid chroot:

/usr/bin/c++   -O3 -DNDEBUG   CMakeFiles/regina-gui.dir/choosers/boundarycompone
ntchooser.cpp.o CMakeFiles/regina-gui.dir/choosers/cuspchooser.cpp.o CMakeFiles/
regina-gui.dir/choosers/edgechooser.cpp.o CMakeFiles/regina-gui.dir/choosers/edg
eintchooser.cpp.o CMakeFiles/regina-gui.dir/choosers/tetrahedronchooser.cpp.o CM
akeFiles/regina-gui.dir/choosers/trianglechooser.cpp.o CMakeFiles/regina-gui.dir
/choosers/vertexchooser.cpp.o CMakeFiles/regina-gui.dir/foreign/csvsurfacehandle
r.cpp.o CMakeFiles/regina-gui.dir/foreign/dehydrationhandler.cpp.o CMakeFiles/re
gina-gui.dir/foreign/exportdialog.cpp.o CMakeFiles/regina-gui.dir/foreign/import
dialog.cpp.o CMakeFiles/regina-gui.dir/foreign/isosighandler.cpp.o CMakeFiles/re
gina-gui.dir/foreign/orbhandler.cpp.o CMakeFiles/regina-gui.dir/foreign/pdfhandl
er.cpp.o CMakeFiles/regina-gui.dir/foreign/pythonhandler.cpp.o CMakeFiles/regina
-gui.dir/foreign/recogniserhandler.cpp.o CMakeFiles/regina-gui.dir/foreign/regin
ahandler.cpp.o CMakeFiles/regina-gui.dir/foreign/snappeahandler.cpp.o CMakeFiles
/regina-gui.dir/foreign/sourcehandler.cpp.o CMakeFiles/regina-gui.dir/packettype
s/dim2tricreator.cpp.o CMakeFiles/regina-gui.dir/packettypes/dim2trigluings.cpp.
o CMakeFiles/regina-gui.dir/packettypes/dim2triskeleton.cpp.o CMakeFiles/regina-
gui.dir/packettypes/dim2triui.cpp.o CMakeFiles/regina-gui.dir/packettypes/eltmov
edialog.cpp.o CMakeFiles/regina-gui.dir/packettypes/facetgraphtab.cpp.o CMakeFil
es/regina-gui.dir/packettypes/gaprunner.cpp.o CMakeFiles/regina-gui.dir/packetty
pes/groupwidget.cpp.o CMakeFiles/regina-gui.dir/packettypes/nanglestructurecreat
or.cpp.o CMakeFiles/regina-gui.dir/packettypes/nanglestructureui.cpp.o CMakeFile
s/regina-gui.dir/packettypes/ncompatcanvas.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/ncontainerui.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nnormalsurfacecreator.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nnormalsurfaceui.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/npdfui.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nscriptui.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsnappeaalgebra.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsnappeacreator.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsnappeafile.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsnappeagluings.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsnappeashapes.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsnappeaui.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsurfacecompatui.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsurfacecoordinateui.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsurfacefiltercomb.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsurfacefiltercreator.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsurfacefilterprop.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsurfacematchingui.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/nsurfacesummaryui.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/ntextui.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/ntrialgebra.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/ntriangulationcreator.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/ntriangulationui.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/ntricomposition.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/ntrigluings.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/ntriskeleton.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/ntrisurfaces.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/skeletonwindow.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/ntrisnappea.cpp.o 
CMakeFiles/regina-gui.dir/packettypes/snappeacomponents.cpp.o 
CMakeFiles/regina-gui.dir/python/commandedit.cpp.o 
CMakeFiles/regina-gui.dir/python/pythonconsole.cpp.o 
CMakeFiles/regina-gui.dir/python/pythoninterpreter.cpp.o 
CMakeFiles/regina-gui.dir/python/pythonoutputstream.cpp.o 
CMakeFiles/regina-gui.dir/srchiliteqt/GNUSyntaxHighlighter.cpp.o 
CMakeFiles/regina-gui.dir/srchiliteqt/Qt4SyntaxHighlighter.cpp.o 
CMakeFiles/regina-gui.dir/srchiliteqt/Qt4TextFormatter.cpp.o 
CMakeFiles/regina-gui.dir/srchiliteqt/Qt4TextFormatterFactory.cpp.o 
CMakeFiles/regina-gui.dir/srchiliteqt/QtColorMap.cpp.o 
CMakeFiles/regina-gui.dir/srchiliteqt/TextFormatter.cpp.o 
CMakeFiles/regina-gui.dir/srchiliteqt/TextFormatterFactory.cpp.o 
CMakeFiles/regina-gui.dir/bigwidget.cpp.o 
CMakeFiles/regina-gui.dir/codecchooser.cpp.o 
CMakeFiles/regina-gui.dir/columnlayout.cpp.o 
CMakeFiles/regina-gui.dir/examplesaction.cpp.o 
CMakeFiles/regina-gui.dir/iconcache.cpp.o 
CMakeFiles/regina-gui.dir/introdialog.cpp.o 
CMakeFiles/regina-gui.dir/main.cpp.o CMakeFiles/regina-gui.dir/reginamain.cpp.o 
CMakeFiles/regina-gui.dir/reginapref.cpp.o 
CMakeFiles/regina-gui.dir/reginamanager.cpp.o 
CMakeFiles/regina-gui.dir/actionspart.cpp.o 
CMakeFiles/regina-gui.dir/exports.cpp.o CMakeFiles/regina-gui.dir/imports.cpp.o 
CMakeFiles/regina-gui.dir/messagelayer.cpp.o 
CMakeFiles/regina-gui.dir/newpacketdialog.cpp.o 
CMakeFiles/regina-gui.dir/newpackets.cpp.o

Bug#797293: votca-csg: FTBFS: undefined reference to `votca::tools::RangeParser::Parse

[Dominic Hargreaves]

Source: votca-csg
Version: 1.2.4-1
Severity: serious
Justification: FTBFS

This package FTBFS in a clean sid chroot:

CMakeFiles/csg_dump.dir/csg_dump.cc.o:(.data.rel.ro._ZTV10CsgDumpApp[_ZTV10CsgDu
mpApp]+0x28): undefined reference to `votca::tools::Application::VersionString[a
bi:cxx11]()'
../libcsg/libvotca_csg.so.2: undefined reference to `votca::tools::ParseXML::Par
seIgnore(std::__cxx11::basic_string, std::allocator
 > const&, std::map, std::allocator >, std::__cxx11::basic_string, std::allocator >, std::less, std::allocator > >, 
std::allocator, std::allocator > const, 
std::__cxx11::basic_string, std::allocator > 
> > >&)'
../libcsg/libvotca_csg.so.2: undefined reference to 
`votca::tools::Property::get(std::__cxx11::basic_string, std::allocator > const&)'
../libcsg/libvotca_csg.so.2: undefined reference to 
`votca::tools::ParseXML::Open(std::__cxx11::basic_string, std::allocator > const&)'
../libcsg/libvotca_csg.so.2: undefined reference to 
`votca::tools::ToolsVersionStr[abi:cxx11]()'
../libcsg/libvotca_csg.so.2: undefined reference to 
`votca::tools::load_property_from_xml(votca::tools::Property&, 
std::__cxx11::basic_string, std::allocator 
>)'
../libcsg/libvotca_csg.so.2: undefined reference to 
`votca::tools::Application::CheckRequired(std::__cxx11::basic_string, std::allocator > const&, 
std::__cxx11::basic_string, std::allocator > 
const&)'
../libcsg/libvotca_csg.so.2: undefined reference to 
`votca::tools::Table::Load(std::__cxx11::basic_string, std::allocator >)'
../libcsg/libvotca_csg.so.2: undefined reference to 
`votca::tools::Property::Select(std::__cxx11::basic_string, std::allocator > const&)'
../libcsg/libvotca_csg.so.2: undefined reference to 
`votca::tools::RangeParser::Parse(std::__cxx11::basic_string, std::allocator >)'
collect2: error: ld returned 1 exit status
make[3]: *** [src/tools/csg_dump] Error 1
src/tools/CMakeFiles/csg_dump.dir/build.make:92: recipe for target 
'src/tools/csg_dump' failed
make[3]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu'
make[2]: *** [src/tools/CMakeFiles/csg_dump.dir/all] Error 2
CMakeFiles/Makefile2:654: recipe for target 
'src/tools/CMakeFiles/csg_dump.dir/all' failed
make[2]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu'
make[1]: *** [all] Error 2


Cheers,
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  [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#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#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#1030749: request-tracker4: Don't release with bookworm

[Dominic Hargreaves]

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

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

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

[Dominic Hargreaves]

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

Hi Sebastian

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

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

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

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

Cheers
Dominic

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

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

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

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


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


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/903124

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

[Dominic Hargreaves]

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

Hello,

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

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

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

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

Cheers,
Dominic.

Bug#919059: ensymble: Time to retire

[Dominic Hargreaves]

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

Good point, RM filed.

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

[Dominic Hargreaves]

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

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

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

[Dominic Hargreaves]

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

Sure, sounds good!

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

[Dominic Hargreaves]

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

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

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

[1] 

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

[Dominic Hargreaves]

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

Dear maintainer,

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

Regards.

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

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

[Dominic Hargreaves]

Hi,

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

Cheers
Dominic

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

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

[Dominic Hargreaves]

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

Dear maintainer,

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

Regards.

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

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

[Dominic Hargreaves]

Control: unblock 968912 by -1

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

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

Dominic

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

[Dominic Hargreaves]

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

Dear maintainer,

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

Regards.

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

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

[Dominic Hargreaves]

Control: severity -1 important

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

Downgrading as it's been built on a retry:

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

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

[Dominic Hargreaves]

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

This package FTBFS on arm64:


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

Dominic

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

[Dominic Hargreaves]

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

postgresql-12 FTBFS on multiple archs, eg:

https://buildd.debian.org/status/fetch.php?pkg=postgresql-12&arch=amd64&ver=12.4-3%2Bb1&stamp=1604914304&raw=0

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

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

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

Please could you take a look?

Cheers
Dominic

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

[Dominic Hargreaves]

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

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

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

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

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

Please could you take a look?

Cheers
Dominic

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

[Dominic Hargreaves]

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

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

Retrying didn't help.

The actual error seems to be:

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

I'll file a blocking bug on gcc.

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

[Dominic Hargreaves]

On Mon, Nov 09, 2020 at 02:43:18PM +, Niko Tyni wrote:
> On Mon, Nov 09, 2020 at 02:16:57PM +0000, Dominic Hargreaves wrote:
> > Source: postgresql-12
> > Version: 12.4-3
> > Severity: serious
> > Justification: ftbfs
> > Tags: ftbfs
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.32-transition
> > Control: block 968912 with -1
> > 
> > postgresql-12 FTBFS on multiple archs, eg:
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=postgresql-12&arch=amd64&ver=12.4-3%2Bb1&stamp=1604914304&raw=0
> 
> This looks relevant, hope it helps:
> 
>  https://www.postgresql.org/message-id/16689-57701daa23b37...@postgresql.org

In which case there seems to be a patch here:

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

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

Dominic.

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

[Dominic Hargreaves]

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

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

Dominic

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

[Dominic Hargreaves]

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

Adding Julian to CC and +1 to this request.

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

Cheers
Dominic

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

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

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

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


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


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/974134

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

[Dominic Hargreaves]

Control: tag -1 pending

Hello,

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

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


Suppress 'Useless use of /d modifier' warnings

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


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/974143

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

[Dominic Hargreaves]

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

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

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

Cheers
Dominic

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

[Dominic Hargreaves]

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

Best
Dominci

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

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

[Dominic Hargreaves]

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

Dear maintainer,

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

Regards.

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

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

[Dominic Hargreaves]

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

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

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

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

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

for full details.

Thanks
Dominic

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

[Dominic Hargreaves]

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

...

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

Thanks
Dominic

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

[Dominic Hargreaves]

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

On Fri, Nov 13, 2020 at 08:48:19PM +0100, Sven Joachim wrote:
> On 2020-11-13 18:23 +0100, Niels Thykier wrote:
> 
> > Control: reassign -1 perl-base
> > Control: affects -1 upgrade-reports
> > Control: severity -1 grave
> >
> > Hi Perl team,
> >
> > I have reassigned this bug to perl because perl-base being essential
> > must remain functional during an upgrade and AFAICT perl-base fails in
> > this case here.
> >
> > If it is a direct linkage, then you might be needing a Pre-Depends.  If
> > it is an indirect linkage then I am not sure how to fix it. :-/
> 
> I don't think perl-base is doing anything wrong here, it already uses
> Pre-Depends.  AFAICS the problem is that libcrypt.so.1 can temporarily
> go missing if libc6 2.31-4 is unpacked before libcrypt1, breaking the
> assumption that binaries from essential packages are always usable.
> 
> I don't have a good idea how to fix that, though. :-(

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

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

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

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

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

[Dominic Hargreaves]

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

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

Thanks
Dominic

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

[Dominic Hargreaves]

On Wed, Nov 11, 2020 at 10:12:19PM +, Dominic Hargreaves wrote:
> During the perl 5.32 transition we observed a build failure on arm64 which
> is reproducible on the porterbox and at lease three different buidds::
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974073
> 
> However Matthias Klose (and I) tried to isolate the problem using the
> expanded source and that doesn't fail:
> 
> g++ -c -std=c++14 -g -O2 -fPIC -fstack-protector-strong -ftemplate-depth=200 
> -fno-strict-aliasing -fopenmp -Wshadow -Wlogical-op -Wconversion 
> -Wzero-as-null-pointer-constant -Wno-parentheses -Wno-error=unused-function 
> -Wno-stringop-overflow -Wno-array-bounds SparseMatrix-2.ii
> 
> (source file attached).
> 
> Can anyone help try and pin this down?

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

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

Cheers
Dominic

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

[Dominic Hargreaves]

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

Dear maintainer,

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

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

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

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

Regards,
Dominic

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

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

[Dominic Hargreaves]

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

Dear maintainer,

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

Changelog:

nbdkit (1.22.3-1.1) unstable; urgency=medium

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

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

Regards.

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

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

[Dominic Hargreaves]

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

Done!

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

[Dominic Hargreaves]

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

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

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

Thanks! I'll reschedule that now.

(Please CC me in replies).

Best
Dominic

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

[Dominic Hargreaves]

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

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

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

[Dominic Hargreaves]

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

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

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

Best
Dominic

Bug#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#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#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#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#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#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#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#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]

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#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#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#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   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   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/lurke

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#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#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#841163: [debian-mysql] Upload of MySQL 5.7.16 security update to unstable

[Dominic Hargreaves]

On Mon, Nov 07, 2016 at 06:44:57AM -0800, Lars Tangvald wrote:
> Hi all,
> 
> We prepared a security upload for the Oracle October 2016 CPU, but we need 
> someone with access to sponsor the upload to Debian unstable. Is anyone 
> available to do this?
> The source should be ready to go from 
> https://anonscm.debian.org/cgit/pkg-mysql/mysql.git

Hi Lars,

Now uploaded.

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#839580: [request-tracker-maintainers] Bug#839580: request-tracker4: FTBFS in testing (failed tests)

[Dominic Hargreaves]

On Tue, Oct 11, 2016 at 11:48:15PM -0400, Daniel Kahn Gillmor wrote:
> Does any of you RT hackers know how to run specific tests manually
> without needing to re-run the entire ~10 minute suite so i can reduce
> the cycle time as i'm debugging this stuff and trying to propose fixes?

./configure --with-my-user-group  --enable-layout=inplace --with-db-type=SQLite 
--enable-developer
[...]
prove -l t/TESTNAME.t

should be enough to get you running on most tests, I think.

Cheers,
Dominic.

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

[Dominic Hargreaves]

On Tue, Oct 11, 2016 at 10:44:28PM +0200, gregor herrmann wrote:
> On Mon, 10 Oct 2016 23:10:30 +0300, Niko Tyni wrote:
> 
> > Help untangling this mess would be very welcome, as both Dominic and I
> > are rather short on time. Tagging and copying possible candidates :)
> 
> Good news: I got the package to build.
> Bad news: Only by forcing gpg1 even harder in the test suite.
> 
> For gpg2 I guess we'd need a fake pinentry and maybe also changes to
> the secret key layout etc. -- Material for dkg maybe :)
> lib/RT/Test/GnuPG.pm looks interesting for setting the gpg config,
> lib/RT/Test.pm has import_gnupg_key.
> 
> What I don't know is if RT4 in the current state now works with
> gpg2 when the test suite passes with gpg1 ...
> Maybe forcing it to gpg1 (in etc/RT_Config.pm.in and debian/control)
> would buy some time. But in general I guess we want gpg2 both at
> buildtime and runtime.
> 
> 
> Before getting that far, I had to make some other changes to reduce
> the build failures to the gpg related ones.
> 
> After the package built I also fixed some lintian errors :)
> 
> Additionally I noted that the build tried to connect to IP addresses
> beyond localhost (my DNS server and my gateway).
> 
> Attached is a patch series.

Hi gregor et al,

Thanks so much for preparing this patch series and tidying up some
non-related issues with the package while I've been unavailable! I
applied your patch series to master and will upload it shortly.

Thanks also to Daniel for looking at some of the root causes and
possible solutions. It would be great to get this all unravelled with
the gpg1 to gpg2 transition. I wonder if at this stage it's safest
to keep RT using gpg1 for stretch, although of course if it's possible
to get it working in time that'd be even better.

Cheers,
Dominic.

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

[Dominic Hargreaves]

Hi Helmut et al,

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

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

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

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

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

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

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

Best wishes,
Dominic.

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

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

[Dominic Hargreaves]

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

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

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

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

[Dominic Hargreaves]

Control: tags -1 + moreinfo

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

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

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

Cheers,
Dominic.

Bug#941917: Ping? nginx and the perl transition

[Dominic Hargreaves]

Hello nginx maintainers.

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

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

Thanks!
Dominic

Bug#940230: Downgrading

[Dominic Hargreaves]

Control: severity -1 important

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

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

[Dominic Hargreaves]

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

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

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

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

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

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

Thanks for your work in maintaining this important package!

Cheers
Dominic

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

[Dominic Hargreaves]

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

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

Cheers
Dominic

Bug#912682: usefulness of this package?

[Dominic Hargreaves]

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

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

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

Dominic.

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

[Dominic Hargreaves]

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

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

Dominic.

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

[Dominic Hargreaves]

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

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

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

[Dominic Hargreaves]

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

A binNMU has already been requested:

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

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

[Dominic Hargreaves]

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

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

Fair point, done.

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

[Dominic Hargreaves]

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

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

Bug#915550: libautodie-perl: superseded by perl

[Dominic Hargreaves]

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

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

Cheers,
Dominic.

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

[Dominic Hargreaves]

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

Hi Andrew

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

Cheers
Dominic

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

[Dominic Hargreaves]

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

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

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

[Dominic Hargreaves]

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

Hi Craig,

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

Cheers,
Dominic.

Bug#883673: fix build with libcdio 1.0

[Dominic Hargreaves]

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

Hi Matthew,

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

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

[...]

(full log attached).

Do you have any suggestions about how to resolve this?

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

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

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

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

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

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

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


Local sources
-

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

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


Setup apt archive
-

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

Install core build dependencies (apt-based resolver)


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

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

[Dominic Hargreaves]

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

Apologies, here's the full build log.

Cheers,
Dominic.


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

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

[Dominic Hargreaves]

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

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

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

Cheers,
Dominic.

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

[Dominic Hargreaves]

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

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

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

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

Dominic.

Bug#873745: bioperl: please Build-Depend on rename

[Dominic Hargreaves]

Source: bioperl
Version: 1.7.1-2
Severity: serious

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

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

# prename is the rename utility written in perl usually available as 
/usr/bin/rename in Debian.
prename s/.pl$// debian/bioperl/usr/bin/*pl
/bin/sh: 1: prename: not found

[1] 

Bug#825608: Remove libnet-jifty-perl?

[Dominic Hargreaves]

On Thu, Aug 31, 2017 at 12:40:40PM +0100, Dominic Hargreaves wrote:
> I noticed that that this bug has been tagged rm-candidate, and I'd like
> to support this. There has been no upstream activity on Jifty since 2011
> and Best Practical abandoned their plans to port RT to this framework
> (which was, IIRC, the original reason for its creation).
> 
> There are no rdepends and a low/dropping popcon. Any objections to me
> requesting this removal?

Just to add: libnet-hiveminder-perl is an rdep (my previous checking
was broken). That is also abandoned by Best Practical (and is only
useful for talking to a now-closed down web service). So I would remove
that too.

Dominic.

Bug#825608: Remove libnet-jifty-perl?

[Dominic Hargreaves]

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

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

Cheers,
Dominic.