Bug#915694: RFS: clamav-unofficial-sigs/5.6.2

[Paul Wise]

On Thu, Dec 6, 2018 at 2:03 PM Brent Clark wrote:

> I am looking for a sponsor for my package "clamav-unofficial-sigs":
...
> The respective dsc file can be found at:
>   
> https://mentors.debian.net/debian/pool/main/c/clamav-unofficial-sigs/clamav-unofficial-sigs_5.6.2-1.dsc

Sorry for the long delay, here is a review:

These things need to be done before any upload:

The upstream tarball fetched by uscan (using debian/watch) needs to be
identical to the one you upload to mentors, the one on mentors
currently has both missing files and additional files. If any changes
are needed to upstream files, they should be represented as patches in
debian/patches/ (or possibly other files in debian/). I generally
don't use git for packaging but I hear that there are tools that can
generate those patches from git commits.

About the manual page, cron job and logrotate config, there is an
upstream bug that means that `./clamav-unofficial-sigs.sh --config
somedir/ --information` doesn't work as it always checks
/etc/clamav-unofficial-sigs instead. If it worked, then you could have
asked the script to install the files at package build time. A
workaround for this bug would be to extract the snippets at build time
instead using sed. Unfortunately that isn't feasible since the
snippets in the script are only templates and the full output gets
created dynamically. Since the fix for this bug is a one-liner, I
think it would be best to include the change, since it allows creation
of the files at build time and also fixes a bug that users might run
into. Place the following line just before the second time that the
config_files array is set.

config_dir="$custom_config"

The upgrade from the old version needs to be checked (with piuparts)
to check that it works, that conffiles are handled correctly and that
the package still works afterwards.

These things would be nice to fix at some point:

The second and third stansas of debian/copyright should probably be
merged, details in the copyright format guide:

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

The package description probably needs to be updated for the
new/changed features of the new upstream.

The Vcs-* fields in debian/control should point at the packaging VCS
rather than the upstream VCS.

There are some warnings when I run it on the .changes file after
building the package.

The new upstream doesn't appear to very active, you might want to
offer your assistance or create a new upstream project to maintain the
upstream code in, possibly within the ClamAV github organisation:

https://github.com/clamav

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#921403: RFS: pyfltk/1.3.4.1-1 [ITP]

[Bart Martens]

Hi Robert,

This package has been removed from Debian some time ago. Are you sure that
bringing it back has good value?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870935

Also, there should be an ITP (not to be confused with an RFS with [ITA]).

Cheers,

Bart

Bug#898060: RPC request reserved 84 but used 180

[andrew]

Hello I wanted to report my events around this bug hoping it may help
resolve it.

I think its important to note that I noticed this bug first from data
corruption seen in raw on images transferred from the NFS server during period 
when RPC request error reported; I checked syslog on the server and found 
repeated lines:-

> RPC request reserved 84 but used 180

My server is raspberry pi running ubuntu mate:
> Linux RPi2 4.14.29-v7+ #1101 SMP Thu Mar 22 17:27:30 GMT 2018 armv7l
armv7l armv7l GNU/Linux

>  nfs-common 1:1.3.4-2.1ubuntu5 armhf
>  nfs-kernel-server 1:1.3.4-2.1ubuntu5   armhf
> rpcbind 0.2.3-0.6 armhf   

Client, Ubuntu 18.04 is reporting as follows :
> Linux 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,acregmin=10,a
cregmax=10,acdirmin=10,acdirmax=10,soft,proto=tcp,timeo=5,retrans=5,sec
=sys,clientaddr=192.168.1.105,local_lock=none,addr=192.168.1.133

> autofs 5.1.2-1ubuntu3 amd64
>  nfs-common 1:1.3.4-2.1ubu amd64
> rpcbind 0.2.3-0.6 amd64   

Bug#922305: latexindent: please add dependency with liblog-log4perl-perl

[Yukiharu YABUKI]

Hello, maintainer.

It is hard question for me. I had resolved this problem.
I reported this issue for feature user.

Your proposal means texlive* shuld be install with recommend package.

It seems for me that texlive-extra-utils should be separate packages.
Is this too difficult? If it is true, I agree with you.


On Thu, 14 Feb 2019 23:13:07 +0100
Hilmar Preuße  wrote:

> On 14.02.19 13:23, YABUKI Yukiharu wrote:
> 
> Hi Yabuki,
> 
> > When I use latexindent command in texlive-extra-utils, the command said:
> > 
> > I installed liblog-log4perl-perl, latexindent works well.
> > That is why, I'd like to add dpendency with liblog-log4perl-perl.
> > 
> Would be a recommend (instead of depend) Ok for you? Recommended
> packages are installed by default, if not configured else.
> 
> Hilmar
> -- 
> sigfault
> #206401 http://counter.li.org
> 


--
++++++++++++++
Yukiharu Yabuki (矢吹幸治)  I use Debian GNU/Linux
mail: yab...@netfort.gr.jp
クレクレタコラは好き / クレクレタコだはイヤ
++++++++++++++

Bug#922602: O: javacc-maven-plugin

[Ludovico Cavedon]

Package: wnpp
Severity: normal

Hi,

I am planning on orphaning javacc-maven-plugin, a maven plugin which
uses JavaCC to process JavaCC grammar files, as I cannot find the time
to keep it up to date and I do not work with java related tools anymore.

Thanks,
Ludovico

Bug#922601: O: jtb -- syntax tree builder and visitors generator for JavaCC

[Ludovico Cavedon]

Package: wnpp
Severity: normal

I intend to orphan the jtb package.

The package description is:
 JTB (Java Tree Builder) is a syntax tree builder and visitors generator to be
 used in front of JavaCC (Java Compiler Compiler).  It takes a JavaCC grammar
 file as input (usually a ".jtb" file) and automatically generates the
 following:
  * a set of syntax tree classes based on the productions in the grammar,
utilizing the Visitor design pattern;
  * four interfaces: IVoidVisitor, IVoidArguVisitor, IRetVisitor,
IRetArguVisitor;
  * four depth-first visitors: DepthFirstVoidVisitor, DepthFirstVoidArguVisitor,
DepthFirstRetVisitor, DepthFirstREtArguVisitor, whose default methods simply
visit the children of the current node;
  * a JavaCC grammar ".jj" file (jtb.out.jj by default), with the proper
annotations to build the syntax tree during parsing (which then must be
compiled with JavaCC).
 .
 New visitors, which subclass any generated one, can then override the default
 methods and perform various operations on and manipulate the generated syntax
 tree.

Bug#919978: diaspora-installer package fails to install

[Pirate Praveen]

Control: severity -1 important

On Mon, 21 Jan 2019 09:53:39 +0100 Karl Stenerud
 wrote:
> Package: disaspora-installer
> Version: 0.7.6.1
> Severity: grave
> 
> Attempting to install diaspora-installer via apt fails with an error.
> 
> Transcript:
> 
> $ lxc launch images:debian/sid tester && lxc exec tester bash

Can you try with lxc-attach?

> Installing gems with rubygems ...
> sh: 1: bundle: not found

It seems /usr/local/bin is not in your path when you just start bash. It
worked with lxc-attach.



signature.asc
Description: OpenPGP digital signature

Bug#922594: RM: htmlunit-core-js/2.8-1

[Ludovico Cavedon]

On Sun, Feb 17, 2019 at 11:10 PM Mattia Rizzolo  wrote:

> On Sun, Feb 17, 2019 at 10:31:22PM -0800, Ludovico Cavedon wrote:
> > The currently packaged version is very old, and nobody is using it.
> > Please remove it only from testing, not from stable.
> > I have also filed a request to removal of htmlunit from testing and
> > unstable.
> >
> > htmlunit-core-js 2.8-1 can be kept in stable and oldstable.
>
> You already asked for remove from unstable, there are no extra action to
> be taken by the release team: once it's removed from unstable, the
> removal from testing will follow (assuming it wouldn't break any rdep).
>
> (same for htmlunit)
>
>
Ah, perfect. thank you for the clarification and sorry for the unnecessary
request.

Ludovico

Bug#922447: lighttpd: autopkgtest regression

[Helmut Grohne]

Control: tags -1 + confirmed

Hi Paul,

On Sat, Feb 16, 2019 at 08:42:35AM +0100, Paul Gevers wrote:
> With a recent upload of lighttpd the autopkgtest of lighttpd fails in
> testing when that autopkgtest is run with the binary packages of
> lighttpd from unstable. It passes when run with only packages from
> testing. In tabular form:
>passfail
> lighttpd   from testing1.4.53-2
> all others from testingfrom testing

Thank you for looking through failures thoroughly. In this case, I was
aware of the issue. I confirm that it is a genuine regression of the
upload.

While I have your attention, I'm interested in your input though. :)

> autopkgtest [00:11:07]: test defconfig: [---
> 2019-02-16 00:11:07: (configfile.c.1599) server.upload-dirs doesn't
> exist: /var/cache/lighttpd/uploads
> 2019-02-16 00:11:07: (mod_compress.c.275) can't stat compress.cache-dir
> /var/cache/lighttpd/compress/ Permission denied

What happens here is that /var/cache/lighttpd/compress is not created
during installation. That actually is a problem, but the question is
whether the test environment is "sane".

The very same autopkgtest does not fail on salsa-ci:
https://salsa.debian.org/debian/lighttpd/-/jobs/126948

Upon closer inspection the difference becomes apparent. salsa-ci is
performing a regular package installation. lighttpd's init script
ensures the presence of said directory as does the tmpfile.d config.
However ci.debian.net runs neither (because it seems to come without an
init system).

We can of course create these locations in the package itself. Indeed we
already do that for e.g. /var/log/lighttpd (and that makes us require
root for build).

It turns out that ci.debian.net's environment is a bit artificial in
this regard. Should we weaken the test here or should we ensure presence
of those locations through non-init means?

Thanks for your input

Helmut

Bug#922594: RM: htmlunit-core-js/2.8-1

[Mattia Rizzolo]

Control: reassign -1 ftp.debian.org
Control: forcemerge 922577 -1
Control: reassign 922576 ftp.debian.org
Control: forcemerge 922575 922576

On Sun, Feb 17, 2019 at 10:31:22PM -0800, Ludovico Cavedon wrote:
> The currently packaged version is very old, and nobody is using it.
> Please remove it only from testing, not from stable.
> I have also filed a request to removal of htmlunit from testing and
> unstable.
> 
> htmlunit-core-js 2.8-1 can be kept in stable and oldstable.

You already asked for remove from unstable, there are no extra action to
be taken by the release team: once it's removed from unstable, the
removal from testing will follow (assuming it wouldn't break any rdep).

(same for htmlunit)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#922600: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: visp
Version: 3.1.0-2
Severity: important

maybe opencv4 broke it due to api change


visp_3.1.0-2_ppc64el-2019-02-15T12:00:30Z.build.zst
Description: Binary data

Bug#922598: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: slowmovideo
Version: 0.5+git20190116-1
Severity: important

it was broken by opencv4 due to api change


slowmovideo_0.5+git20190116-1_ppc64el-2019-02-15T11:55:42Z.build.zst
Description: Binary data

Bug#922599: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: uprightdiff
Version: 1.3.0-1
Severity: important

headers have been moved to /usr/include/opencv4/opencv2/* since opencv4


uprightdiff_1.3.0-1_ppc64el-2019-02-15T11:59:29Z.build.zst
Description: Binary data

Bug#922597: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: sitplus
Version: 1.0.3-5.1
Severity: important

sitplus asks for a header file cv.h that has been deprecated since opencv4


sitplus_1.0.3-5.1_ppc64el-2019-02-15T11:53:28Z.build.zst
Description: Binary data

Bug#922596: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: siril
Version: 0.9.10-2
Severity: important

pkg-config file has been marked as deprecated by upstream since opencv4


siril_0.9.10-2_ppc64el-2019-02-15T11:52:06Z.build.zst
Description: Binary data

Bug#922593: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: saga
Version: 2.3.1+dfsg-4
Severity: important

saga uses header file opencv/cv.h that has been deprecated since opencv4


saga_2.3.1+dfsg-4_ppc64el-2019-02-15T11:41:11Z.build.zst
Description: Binary data

Bug#922595: FTBFS due to PDF compilation failure (against Opencv 4.0.1)

[Mo Zhou]

Source: sdaps
Version: 1.2.1-1
Severity: important




sdaps_1.2.1-1_ppc64el-2019-02-15T11:49:16Z.build.zst
Description: Binary data

Bug#922594: RM: htmlunit-core-js/2.8-1

[Ludovico Cavedon]

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

The currently packaged version is very old, and nobody is using it.
Please remove it only from testing, not from stable.
I have also filed a request to removal of htmlunit from testing and
unstable.

htmlunit-core-js 2.8-1 can be kept in stable and oldstable.

Thanks,
Ludovico

-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#922592: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: ros-vision-opencv
Version: 1.13.0+ds-2
Severity: important

the cmake build simply rejected OpenCV 4 because it asks for 3 ...


ros-vision-opencv_1.13.0+ds-2_ppc64el-2019-02-15T11:39:35Z.build.zst
Description: Binary data

Bug#922589: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: opencfu
Version: 3.9.0-3
Severity: important

pkg-config file has been marked deprecated by upstream.


opencfu_3.9.0-3_ppc64el-2019-02-15T11:23:33Z.build.zst
Description: Binary data

Bug#922590: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: php-facedetect
Version: 1.1.0+git20170801-2
Severity: important

pkg-config file has been marked as deprecated by upstream


php-facedetect_1.1.0+git20170801-2_ppc64el-2019-02-15T11:34:02Z.build.zst
Description: Binary data

Bug#922591: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: ros-opencv-apps
Version: 1.12.0-2
Severity: important

Opencv4 broke it due to API change.


ros-opencv-apps_1.12.0-2_ppc64el-2019-02-15T11:35:50Z.build.zst
Description: Binary data

Bug#922588: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: openalpr
Version: 2.3.0-1.1
Severity: important

build failed due to API change.


openalpr_2.3.0-1.1_ppc64el-2019-02-15T11:21:44Z.build.zst
Description: Binary data

Bug#922587: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: node-opencv
Version: 6.0.0+git20180416.cfc96ba0-2
Severity: important

pkg-config file has been deprecated by upstream.


node-opencv_6.0.0+git20180416.cfc96ba0-2_ppc64el-2019-02-15T11:17:20Z.build.zst
Description: Binary data

Bug#922585: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: mldemos
Version: 0.5.1+git.1.ee5d11f-4
Severity: important

opencv/cv.h has been deprected since opencv4.


mldemos_0.5.1+git.1.ee5d11f-4_ppc64el-2019-02-15T11:00:59Z.build.zst
Description: Binary data

Bug#922584: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: limereg
Version: 1.4.1-4
Severity: important


limereg_1.4.1-4_ppc64el-2019-02-15T10:59:23Z.build.zst
Description: Binary data

Bug#922586: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: mrpt
Version: 1.5.6-1
Severity: important

headers have been moved to /usr/include/opencv4/opencv2/* since opencv4


mrpt_1.5.6-1_ppc64el-2019-02-15T11:12:38Z.build.zst
Description: Binary data

Bug#922581: RM: ruby-fog-atmos -- ROM; not required, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency of ruby-fog, which is now 
removed.

No other reverse dependencies.

Bug#922582: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: gmic
Version: 2.4.5-1
Severity: important

gmic's cmake file needs to be updated for Opencv4


gmic_2.4.5-1_ppc64el-2019-02-15T10:51:33Z.build.zst
Description: Binary data

Bug#922580: RM: ruby-fog-voxel -- ROM; not required, no reverse dependencies

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency of ruby-fog, which is now 
removed.

No other reverse dependencies.

Bug#922579: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: freeture
Version: 1.3.0-1
Severity: important

Opencv4 has moved its headers to /usr/include/opencv4/opencv2/*


freeture_1.3.0-1_ppc64el-2019-02-15T10:47:06Z.build.zst
Description: Binary data

Bug#922578: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: eviacam
Version: 2.1.3-4.1
Severity: important

Unfortunately the pkg-config file has been marked as deprecated by
upstream...


eviacam_2.1.3-4.1_ppc64el-2019-02-15T08:25:34Z.build.zst
Description: Binary data

Bug#922577: RM: htmlunit-core-js -- ROM; the currently packaged version is very old, and nobody is using it

[Ludovico Cavedon]

Package: ftp.debian.org
Severity: normal

Thanks,
Ludovico

Bug#922576: RM: htmlunit/2.8-3

[Ludovico Cavedon]

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

the currently packaged version is very old, and nobody is using it

Please remove it from the upcoming release,
Thanks,
Ludovico

-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#922575: RM: htmlunit -- ROM; the currently packaged version is very old, and nobody is using it

[Ludovico Cavedon]

Package: ftp.debian.org
Severity: normal

Thanks,
Ludovico

Bug#922574: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: digikam
Version: 5.9.0-1
Severity: important

digikam uses opencv headers that have been deprecated in opencv4


digikam_5.9.0-1_ppc64el-2019-02-15T08:21:02Z.build.zst
Description: Binary data

Bug#922570: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: caffe-contrib
Version: 1.0.0+git20180821.99bd997-2
Severity: important

Opencv4 breaks caffe-contrib due to API change.


caffe-contrib_1.0.0+git20180821.99bd997-2_ppc64el-2019-02-15T08:09:29Z.build.zst
Description: Binary data

Bug#922571: sigviewer FTCBFS: does not pass cross flags to qmake

[Helmut Grohne]

Source: sigviewer
Version: 0.6.2-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

sigviewer fails to cross build from source, because it neither uses the
cross qmake nor passes cross flags to qmake. The easiest way of doing so
- using dh_auto_configure - makes sigviewer cross buildable. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru sigviewer-0.6.2/debian/changelog 
sigviewer-0.6.2/debian/changelog
--- sigviewer-0.6.2/debian/changelog2019-01-21 11:08:46.0 +0100
+++ sigviewer-0.6.2/debian/changelog2019-02-18 07:13:08.0 +0100
@@ -1,3 +1,10 @@
+sigviewer (0.6.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass cross flags to qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 Feb 2019 07:13:08 +0100
+
 sigviewer (0.6.2-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru sigviewer-0.6.2/debian/rules sigviewer-0.6.2/debian/rules
--- sigviewer-0.6.2/debian/rules2019-01-21 11:08:46.0 +0100
+++ sigviewer-0.6.2/debian/rules2019-02-18 07:13:07.0 +0100
@@ -9,4 +9,4 @@
dh  $@
 
 override_dh_auto_configure:
-   qmake QMAKE_STRIP=: PREFIX=/usr
+   dh_auto_configure -- QMAKE_STRIP=: PREFIX=/usr

Bug#922573: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: darknet
Version: 0.0.0+git20180914.61c9d02e-1
Severity: important

Opencv4 moved its headers to /usr/include/opencv4/opencv2/*


darknet_0.0.0+git20180914.61c9d02e-1_ppc64el-2019-02-15T08:19:26Z.build.zst
Description: Binary data

Bug#922572: debootstrap variant fakeroot fails due to dash diversion.

[Per Sandberg]

Package: dash
Version: 0.5.10.2-5
Severity:|important|||

Hello when doing:
fakechroot fakeroot debootstrap --foreign --merged-usr 
--variant=fakechroot --arch=amd64  sid debian
On plain buster machine newly updated as a normal user.

I a getting:
-
Setting up dash (0.5.10.2-5) ...
No diversion 'diversion of /bin/sh by bash', none removed.
Adding 'diversion of /bin/sh to /bin/sh.distrib by dash'
mv: cannot move '/bin/sh.tmp' to '/bin/sh': No such file or directory
dpkg: error processing package dash (--configure):
 installed dash package post-installation script subprocess returned error exit 
status 1
...
...
---
And the effect of this is that  /bin/sh is temporary removed from the target 
tree, causing all subsequent post install stages
in the chrooted environment to fail.

/Cheers
/P

Bug#922565: RFA: tortoisehg -- Graphical tool for working with Mercurial

[Ludovico Cavedon]

Package: wnpp
Severity: normal

Hi,
I am no longer a user this package and I am not able to keep up with the
updates, especially because they need to be syncronized with mercurial
updates.

I request an adopter for the tortoisehg package, please.

Thank you,
Ludovico



The package description is:
 TortoiseHg provides a graphical tool for interacting with the distributed
 revision control system Mercurial.  GUI support is provided for over a dozen
 operations, including add files, commit changes, manage ignore filter, view
 change log, merge, recover/rollback, edit configuration, synchronize
 repository, and many others.   The highlight is the interactive commit tool
 which allows easy selection of diffs from multiple files and packaging into
 changesets, and which is more powerful and easier to use than available
 alternatives such as qct and hgct (commit-tool).

Bug#922567: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: auto-multiple-choice
Version: 1.4.0-1
Severity: important

opencv4 moved its headers to /usr/include/opencv4/opencv2/*


auto-multiple-choice_1.4.0-1_ppc64el-2019-02-15T08:03:15Z.build.zst
Description: Binary data

Bug#922568: RFA: jcc -- code generator producing a Python extension from Java classes

[Ludovico Cavedon]

Package: wnpp
Severity: normal

Hi,

I request an adopter for the jcc package, please, as I am no longer a
user and I am having issues finding time to keep it up to date.

Thank you,
Ludovico


The package description is:
 JCC is a code generator for producing a Python extension providing
 access to a set of Java classes. For every Java class, JCC generates
 a C++ wrapper class that hides the gory details necessary for
 accessing methods and fields from C++ via Java's Native Invocation
 Interface.  JCC can also generate C++ wrappers that make it possible
 to access these classes from Python.  When generating Python
 wrappers, JCC produces a complete Python extension via the distutils
 package that makes it readily available to the Python interpreter.
 JCC is a project maintained by the Open Source Applications
 Foundation.

Bug#922566: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: actiona
Version: 3.10.0-1
Severity: important


actiona_3.10.0-1_ppc64el-2019-02-15T08:01:36Z.build.zst
Description: Binary data

Bug#922569: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Source: caffe
Version: 1.0.0+git20180821.99bd997-2
Severity: important

Opencv4 breaks caffe due to API change.

Bug#922563: FTBFS on ppc64el

[Mo Zhou]

Source: casparcg-server
Version: 2.2.0+dfsg-2
Severity: important

ppc64el doesn't have any SIMD instruction set named SSE

make -f shell/CMakeFiles/casparcg_copy_dependencies.dir/build.make 
shell/CMakeFiles/casparcg_copy_dependencies.dir/build
make[3]: Entering directory 
'/<>/casparcg-server-2.2.0+dfsg/obj-powerpc64le-linux-gnu'
cd /<>/casparcg-server-2.2.0+dfsg/obj-powerpc64le-linux-gnu/shell && 
/usr/bin/cmake -E make_directory 
"/<>/casparcg-server-2.2.0+dfsg/obj-powerpc64le-linux-gnu/shell/."
make[3]: Leaving directory 
'/<>/casparcg-server-2.2.0+dfsg/obj-powerpc64le-linux-gnu'
[  2%] Precompiling stdafx.h for common (C++)
cd /<>/casparcg-server-2.2.0+dfsg/obj-powerpc64le-linux-gnu/common && 
/usr/bin/c++ 
@/<>/casparcg-server-2.2.0+dfsg/obj-powerpc64le-linux-gnu/common/common_pch/compile_flags.rsp
 -x c++-header -o 
/<>/casparcg-server-2.2.0+dfsg/obj-powerpc64le-linux-gnu/common/common_pch/stdafx.h.gch/.c++
 
/<>/casparcg-server-2.2.0+dfsg/obj-powerpc64le-linux-gnu/common/common_pch/stdafx.h
c++: error: unrecognized command line option '-msse3'; did you mean '-misel'?
c++: error: unrecognized command line option '-mssse3'; did you mean '-misel'?
c++: error: unrecognized command line option '-msse4.1'
[  2%] Built target casparcg_copy_dependencies
make[3]: *** [common/CMakeFiles/common.dir/build.make:70: 
common/common_pch/stdafx.h.gch/.c++] Error 1
make[3]: Leaving directory 
'/<>/casparcg-server-2.2.0+dfsg/obj-powerpc64le-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:150: common/CMakeFiles/common.dir/all] Error 
2
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory 
'/<>/casparcg-server-2.2.0+dfsg/obj-powerpc64le-linux-gnu'
make[1]: *** [Makefile:87: all] Error 2
make[1]: Leaving directory 
'/<>/casparcg-server-2.2.0+dfsg/obj-powerpc64le-linux-gnu'
dh_auto_build: cd obj-powerpc64le-linux-gnu && make -j4 returned exit code 2
make: *** [debian/rules:3: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Build finished at 2019-02-16T11:59:16Z

Bug#825526: smokeping: deletes files in /etc/smokeping

[Gabriel Filion]

Hi there,

On Fri, 27 May 2016 14:07:00 +0200 Francesco =?utf-8?Q?Potort=C3=AC?=
 wrote:
> Package: smokeping
> Version: 2.6.11-3
> Severity: normal
> 
> I keep an "apache2.conf" file in /etc/smokeping, which is my backup of
> my personalised /etc/apache2/smokeping.conf.
> 
> When smokeping got updated, it deleted that file.
> 
> I think it should not.

From what I know, the apache2 config file is considered as a config file
for the smokeping package. as an example, this is how I see this in buster:

# cat /var/lib/dpkg/info/smokeping.conffiles | grep apache2
/etc/apache2/conf-available/smokeping.conf

if I were to venture a guess about what hapened here is that dpkg may
have asked if this file should be overwritten during upgrade. if the
upgrade was run in a non-interactive way, it's possible that this
question was hushed or pre-answered in a way.

what you could try in order to avoid having your config file get
overwritten is you could use dpkg-divert(1) to add a divert rule for the
file. This way the package will not overwrite it.

cheers!



signature.asc
Description: OpenPGP digital signature

Bug#921704: tortoisehg: uninstallable with mercurial 4.9

[Ludovico Cavedon]

package src:tortoisehg
tags 921704 + sid experimental
thanks

Thank you for the bug report. TortoiseHg 4.9 has not been released yet.

Ludovico

On Fri, Feb 8, 2019 at 12:09 AM Julien Cristau  wrote:

> Source: tortoisehg
> Version: 4.8.1-0.1
> Severity: serious
> X-Debbugs-Cc: James Cowgill 
>
> Hi,
>
> mercurial 4.9 is now in sid, so tortoisehg needs an update.
>
> Cheers,
> Julien
>

Bug#225550: Contact Me

[Mr. LUI SHIYU]

My Name is Liu Shiyu

Bug#922562: RM: picviz -- RoQA; Unmaintained, RC buggy, missed two releases

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

The package is unbuildable, uninstallable, and has not been uploaded in very
close to a decade.

Scott K

Bug#922561: nettoe FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: nettoe
Version: 1.5.1-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

nettoe fails to cross build from source, because it does not pass --host
to ./configure. The easiest way of fixing that - using dh_auto_configure
- makes nettoe cross buildable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru nettoe-1.5.1/debian/changelog nettoe-1.5.1/debian/changelog
--- nettoe-1.5.1/debian/changelog   2016-04-05 22:37:39.0 +0200
+++ nettoe-1.5.1/debian/changelog   2019-02-18 06:44:15.0 +0100
@@ -1,3 +1,10 @@
+nettoe (1.5.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 Feb 2019 06:44:15 +0100
+
 nettoe (1.5.1-2) unstable; urgency=low
 
   * Set Standards-Version to 3.9.7, no changes.
diff --minimal -Nru nettoe-1.5.1/debian/rules nettoe-1.5.1/debian/rules
--- nettoe-1.5.1/debian/rules   2016-04-05 19:13:40.0 +0200
+++ nettoe-1.5.1/debian/rules   2019-02-18 06:44:14.0 +0100
@@ -8,8 +8,7 @@
dh $@ --with autoreconf
 
 override_dh_auto_configure:
-   ./configure --prefix=/usr \
+   dh_auto_configure -- \
--bindir=/usr/games \
-   --mandir=/usr/share/man \
--enable-desktop
 

Bug#922560: FTBFS on ppc64el due to test failure

[Mo Zhou]

Source: ceres-solver
Version: 1.14.0-3
Severity: important

-

Build Architecture: ppc64el
Build Type: any
Build-Space: 25989336
Build-Time: 810
Distribution: unstable
Fail-Stage: build
Host Architecture: ppc64el
Install-Time: 30
Job: /home/debian/x/AUTORB/ceres-solver_1.14.0-3.dsc
Machine Architecture: ppc64el
Package: ceres-solver
Package-Time: 882
Source-Version: 1.14.0-3
Space: 25989336
Status: attempted

-

99% tests passed, 1 tests failed out of 127

Total Test time (real) = 111.60 sec

The following tests FAILED:
 30 - evaluation_callback_test (Failed)
Errors while running CTest
make[1]: *** [Makefile:89: test] Error 8
make[1]: Leaving directory '/<>/obj-powerpc64le-linux-gnu'
dh_auto_test: cd obj-powerpc64le-linux-gnu && make -j4 test ARGS\+=-j4 returned 
exit code 2

-

Start  34: gradient_problem_test
 31/127 Test  #30: evaluation_callback_test 
.***Failed0.47 sec
Running main() from gmock_main.cc
[==] Running 8 tests from 1 test case.
[--] Global test environment set-up.
[--] 8 tests from EvaluationCallback
[ RUN  ] EvaluationCallback.WithTrustRegionMinimizer
[   OK ] EvaluationCallback.WithTrustRegionMinimizer (143 ms)
[ RUN  ] EvaluationCallback.WithLineSearchMinimizerWolfeLbfgsCubic
[   OK ] EvaluationCallback.WithLineSearchMinimizerWolfeLbfgsCubic (60 ms)
[ RUN  ] EvaluationCallback.WithLineSearchMinimizerWolfeLbfgsQuadratic
/<>/internal/ceres/evaluation_callback_test.cc:94: Failure
Expected: (evaluate_last_parameter_hash) != (incoming_parameter_hash), actual: 
774166405242757167 vs 774166405242757167
/<>/internal/ceres/evaluation_callback_test.cc:95: Failure
Expected: (prepare_parameter_hash) != (incoming_parameter_hash), actual: 
774166405242757167 vs 774166405242757167
/<>/internal/ceres/evaluation_callback_test.cc:150: Failure
Expected: (evaluate_last_parameter_hash) != (incoming_parameter_hash), actual: 
774166405242757167 vs 774166405242757167
[  FAILED  ] EvaluationCallback.WithLineSearchMinimizerWolfeLbfgsQuadratic (2 
ms)
[ RUN  ] EvaluationCallback.WithLineSearchMinimizerWolfeBfgsCubic
[   OK ] EvaluationCallback.WithLineSearchMinimizerWolfeBfgsCubic (2 ms)
[ RUN  ] EvaluationCallback.WithLineSearchMinimizerWolfeBfgsQuadratic
/<>/internal/ceres/evaluation_callback_test.cc:94: Failure
Expected: (evaluate_last_parameter_hash) != (incoming_parameter_hash), actual: 
9649131218334053403 vs 9649131218334053403
/<>/internal/ceres/evaluation_callback_test.cc:95: Failure
Expected: (prepare_parameter_hash) != (incoming_parameter_hash), actual: 
9649131218334053403 vs 9649131218334053403
/<>/internal/ceres/evaluation_callback_test.cc:150: Failure
Expected: (evaluate_last_parameter_hash) != (incoming_parameter_hash), actual: 
9649131218334053403 vs 9649131218334053403
[  FAILED  ] EvaluationCallback.WithLineSearchMinimizerWolfeBfgsQuadratic (1 ms)
[ RUN  ] EvaluationCallback.WithLineSearchMinimizerArmijoCubic
[   OK ] EvaluationCallback.WithLineSearchMinimizerArmijoCubic (3 ms)
[ RUN  ] EvaluationCallback.WithLineSearchMinimizerArmijoBisection
[   OK ] EvaluationCallback.WithLineSearchMinimizerArmijoBisection (4 ms)
[ RUN  ] EvaluationCallback.WithLineSearchMinimizerArmijoQuadratic
[   OK ] EvaluationCallback.WithLineSearchMinimizerArmijoQuadratic (2 ms)
[--] 8 tests from EvaluationCallback (218 ms total)

[--] Global test environment tear-down
[==] 8 tests from 1 test case ran. (218 ms total)
[  PASSED  ] 6 tests.
[  FAILED  ] 2 tests, listed below:
[  FAILED  ] EvaluationCallback.WithLineSearchMinimizerWolfeLbfgsQuadratic
[  FAILED  ] EvaluationCallback.WithLineSearchMinimizerWolfeBfgsQuadratic

 2 FAILED TESTS

Start  35: gradient_problem_solver_test
 32/127 Test  #34: gradient_problem_test    
Passed0.07 sec

Bug#922559: Firmware locks up on Vega 8

[Brian Holaday]

Package: firmware-amd-graphics
Version: 20180825+dfsg-1~bpo9+1

Laptop Information
- Inspiron 5775
- AMD Ryzen 5 - 2500U CPU
- Radeon Vega 8 GPU (Shared with CPU)

Kernel: 4.19.0-0.bpo.2-amd64, 4.19.16-1~bpo9+1

- Without Package Debian Stretch works fine with one config change:
/etc/default/grub/
* see notes

Steps to Reproduce:

* This assumes stretch-backports is installed *

#1. Install ATI Firmware:
#sudo apt-get install -t stretch-backports firmware-amd-graphics

#2. Reboot Install:
# After reboot - kernel loads just fine but then when it hits the
gnome-shell login screen the system locks up (cursor has no movement) and
only a grey background is shown.

Here is part of my log what I seem to show:
 gnome-session[857]: gnome-session-binary[857]: WARNING: App
'org.gnome.Shell.desktop' exited with code 1

Without the firmware-driver I can get gnome-shell to launch just fine
however for my laptop I have to set the following up for proper screen
booting: /etc/default/grub/ (see below). Even commenting these in/out still
produce a lock when the firmware is installed does not lock when firmware
is not installed.

* Yes: this is close *
> GFXMODE=1920x1080x32
> GFXPAYLOAD=keep


Last Note: Running Fedora live with vga=3d4 or vga=755 seems to boot up: I
have less lockup problems and HDMI is fully supported. Right now even with
the firmware there is no HDMI output using Debian Stretch. I don't know if
this has to do with a newer firmware of Fedora for AMD ATI and/or the
Kernel or if Mesa also is updated such that for the most part things are
working. I expect Buster to be working fully if what is pulled in is
updated.

Bug#922557: lintian: Please check whether there's an expected orig tarball signature

[Mattia Rizzolo]

On Mon, Feb 18, 2019 at 02:30:05AM +0100, Guillem Jover wrote:
> It would be nice to get a warning to avoid this. I imagine a tag
> could be emitted whenever there is no «*.orig.tar.*.asc» (for each
> «*.orig.tar.*») and either of the following holds:
> 
>   - there is a debian/upstream/signing-key.asc file.
>   - there is pgpmode or pgpsigurlmangle in opts in debian/watch.

There is already such a tag, orig-tarball-missing-upstream-signature.
That's a .changes checks, not a .dsc one, so it would be emitted only
for -1.
Indeed it probably makes sense to turn this into a .dsc tag, that would
also have the added benefit of being emitted in lintian.d.o as well
(where there are no .changes files to check).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#921573: lintian: binary-from-other-architecture only works sometimes

[Helmut Grohne]

Hi Matthia and Chris,

On Sun, Feb 17, 2019 at 11:18:00PM +0100, Chris Lamb wrote:
> > For the advantage of everybody, here are links to the cross-builds from
> > amd64 to mips64el and arm64 of procmail.

Thank you.

> Wow, thanks for this! I had spent an hour trying to follow the
> instructions on the Debian Wiki to get a crossbuild environment
> which failed in a very strage way, so had shelved this for the time
> being...

It would help if you could share your frustration in more detail such
that we can fix that. The whole idea that you'd need a "cross build
environment" seems flawed though. What you need is a "build environment"
and that happens to be a "cross build environment" automatically. If you
decide to put that into words, debian-cr...@lists.debian.org is a good
place.

> Anyway, with these:
> 
> $ dget 
> https://volatile.mapreri.org/2019-02-17/130da1c8cbfd405daeb1a7d0a51f536d/ 
> procmail_3.22-26_mips64el.changes
> […]
> 
> $ ar x *.deb
> 
> $ tar xfJ data.tar.xz 
> 
> $ find | grep bin/lockfile
> ./usr/bin/lockfile
> 
> $ file ./usr/bin/lockfile
> ./usr/bin/lockfile: ELF 64-bit LSB pie executable, x86-64, version 1 
> (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
> GNU/Linux 3.2.0, BuildID[sha1]=61490d858790e4dc01926e63843ad0509abd0371, 
> stripped
> 
> $ ./usr/bin/lockfile -v
> lockfile v3.23pre 2001/09/13
>   Copyright (c) 1990-2001, Stephen R. van den Berg
>   Copyright (c) 1997-2001, Philip A. Guenther 
> 
> 
> 
> Perhaps I'm missing something, but this looks like /usr/bin/
> lockfile is ann amd64 binary, not a a mips64el one.

What you are observing exactly matches my report thus far. procmail
successfully cross builds binary packages that contain native binaries
(for all architectures). Doing so is broken of course and we want
lintian to flag such builds. Indeed, lintian has a tag for such
behaviour for a long time: binary-from-other-architecture. The
particular issue in this report is that the tag is not emitted for the
procmail package when built for mips64el even though it should. I
mentioned the arm64 build as a positive example: The package is also
broken and lintian successfully flags it with
binary-from-other-architecture.

Thank you for looking into this

Helmut

Bug#922483: duplicate?

[Jeffrey Cliff]

a pretty close to duplicate RFP was just filed at #922476 .

Bug#648158: Fix applied upstream

[Alan Coopersmith]

https://gitlab.freedesktop.org/xorg/app/xcompmgr/commit/9c86c0f21b9d34c0ae491327482415a946102c4f

Bug#922367: nas FTCBFS: builds for the wrong architecture

[Do Thanh Trung]

ACK. Thanks for the patch, I've applied it in current git.


Nice. Thanks.



If you're contributing to open source projects, you should probably do
something about this daft message, though!


Sorry. I forgot to remove that message in the signature.
Thank you for reminding me.


--
Trung

--
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com

Bug#922558: avrdude: USBtiny programming of ATmega328p broken

[Austin Roach]

Package: avrdude
Version: 6.3-20171130+svn1429-1
Severity: normal

Programming of ATmega328p microcontrollers with a usbtiny-compatible
(Pocket AVR) programmer is broken for me. The breakage was caused by
upstream Patch #9728 [1], and this bug has been reported upstream [2].

[1] https://savannah.nongnu.org/patch/?9728
[2] https://savannah.nongnu.org/bugs/index.php?55734

Bug#922557: lintian: Please check whether there's an expected orig tarball signature

[Guillem Jover]

Package: lintian
Version: 2.7.0
Severity: wishlist

Hi!

I just noticed that I've sometimes been failing to include the orig
tarball signature file for some of the uploads after the first new
upstream release. Let me clarify with an example:

  - Fetch upstream xfstt 1.9.3 orig.tar.xz and orig.tar.xz.asc.
  - Build xfstt 1.9.3-1 source w/ orig.tar.xz.asc. (Good)
  - Build xfstt 1.9.3-2 source w/o orig.tar.xz.asc. (Bad)
  - Build xfstt 1.9.3-3 source w/o orig.tar.xz.asc. (Bad)
  - Fetch upstream xfstt 1.10 orig.tar.xz and orig.tar.xz.asc.
  - Build xfstt 1.10-1 source w/ orig.tar.xz.asc. (Good)

So, when building new revisions it seems I'm prone to forget to place
the orig.tar.xz.asc alongside the orig.tar.xz sometimes. :/

It would be nice to get a warning to avoid this. I imagine a tag
could be emitted whenever there is no «*.orig.tar.*.asc» (for each
«*.orig.tar.*») and either of the following holds:

  - there is a debian/upstream/signing-key.asc file.
  - there is pgpmode or pgpsigurlmangle in opts in debian/watch.

Thanks,
Guillem

Bug#856595:

[Kunal Mehta]

Hi,

On 2/16/19 7:35 PM, Pavel Minaev wrote:
> It looks like all the dependencies are now in Buster, thanks to Kunal.
> It would be a shame to have it all, except for the actual user-facing
> app that uses it...
> 
> Is there any chance that this package might make it into Buster? Is
> there any assistance I could provide to accelerate the process?

Unfortunately, we missed the deadline for buster already. But your help
would be appreciated!

We need to figure out a resolution to
, as you found. I think
that was the main blocker.

I pushed my packaging work to
, there are probably some
lintian warnings, etc. that need to be cleaned up.

Once we have something working and Buster is released, we can definitely
aim to get kiwix-tools into buster-backports.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#922556: gimp-texturize: New upstream homepage

[Joao Eriberto Mota Filho]

Package: gimp-texturize
Version: 2.1-5
Severity: normal

There is a new upstream homepage here[1].

[1] https://lmanul.github.io/gimp-texturize/index.html

Regards,

Eriberto

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders many systems unbootable

[Vagrant Cascadian]

On 2019-02-17, Vagrant Cascadian  wrote:
> On 2019-02-17, Timo Sigurdsson wrote:
>> Cyril Brulebois schrieb am 17.02.2019 19:38:
>>> Jürgen Löb  (2019-02-16):
> FWIW, I also built a local package from 4.9.155-1~ from salsa/stretch
> git, and it worked on a wandboard quad.
>
> $ uname -a
> Linux wbq0 4.9.0-9-armmp #1 SMP Debian 4.9.155-1~20190217~1 (2019-02-17) 
> armv7l GNU/Linux

That seemed to work fine on several tested boards.

I also did a local build commenting out
"debian/arm-avoid-abi-change-in-4.9.139.patch" in debian/patches and
removing "debian/abi/4.9.0-8/armhf_none_armmp" so that the abi conflicts
didn't fail to build...

$ uname -a
Linux cbxi4b 4.9.0-8-armmp #1 SMP Debian 4.9.144-4~20190217~1 (2019-02-17) 
armv7l GNU/Linux

Sounds like there may be a less intrusive patch in the works...


live well,
  vagrant

Bug#824495: Use of the Build-Conflicts field

[Sean Whitton]

Hello,

On Fri 15 Feb 2019 at 08:59PM -0700, Sean Whitton wrote:

> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases.  See #824495 for the discussion.
>
> There are two cases which we think that everyone would agree that there
> is a bug, but we are not sure that the bug would be considered to be RC.
> We are posting to -devel to see if, in fact, we do have a consensus that
> these bugs would be RC, or not.

Thank you all for the feedback.

It seems that that is not a consensus that the two cases are RC.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#922555: android-sdk: should allow openjdk-8-jdk-headless

[Stephen Paul Weber]

Package: android-sdk
Version: 25.0.0+8
Severity: normal

Dear Maintainer,

When trying to install android-sdk on sid I find that it depends on a
jdk, but openjdk-8-jdk-headless (available in sid) is not in the list.
This means that even if I wish to use openjdk 8, openjdk 11 is pulled in
and made default instead.

Bug#922554: network-manager: NetworkManager continuously spinning, probably while checking for connectivity

[Jiri Palecek]

Package: network-manager
Version: 1.14.4-4
Severity: normal

Dear Maintainer,

I've noticed network manager is consuming most of the cpu time on my
system. It seems to be caused by the connectivity checking code. The
symptoms are:

1. ltrace shows this repeating on and on:

exe->epoll_wait(15, 0xbfb0bba0, 1, 0)   

= 0
exe->clock_gettime(0, 0xbfb0bb54, 1, 15)

= 0
exe->clock_gettime(1, 0xbfb0bb54, 1, 15)

= 0
exe->clock_gettime(7, 0xbfb0bb54, 1, 15)

= 0
exe->g_object_ref(0x15c1b58, 0x15adf20, 0x15a84b0, 0xb7a5acc6)  

= 0x15c1b58
exe->g_io_channel_unix_get_fd(0x1629fb0, 0x15adf20, 0x15a84b0, 0xb7a5acc6)  

= 20
exe->curl_multi_socket_action(0x15c4900, 20, 2, 0xbfb0bd88) 

= 0
exe->curl_multi_info_read(0x15c4900, 0xbfb0bd80, 2, 0xbfb0bd88) 

= 0
exe->g_object_ref(0x15c1b58, 0x1612440, 0x1640dc0, 0xb7a5acc6)  

= 0x15c1b58
exe->g_io_channel_unix_get_fd(0x15e32b0, 0x1612440, 0x1640dc0, 0xb7a5acc6)  

= 22
exe->curl_multi_socket_action(0x15c4900, 22, 2, 0xbfb0bd88) 

= 0
exe->curl_multi_info_read(0x15c4900, 0xbfb0bd80, 2, 0xbfb0bd88) 

= 0
exe->g_object_ref(0x15c1b58, 0, 0x1654880, 0xb7a5acc6)  

= 0x15c1b58
exe->g_io_channel_unix_get_fd(0x1627080, 0, 0x1654880, 0xb7a5acc6)  

= 24
exe->curl_multi_socket_action(0x15c4900, 24, 2, 0xbfb0bd88) 

= 0
exe->curl_multi_info_read(0x15c4900, 0xbfb0bd80, 2, 0xbfb0bd88) 

= 0

2. strace only shows incrementing and decrementing an eventfd, no
network activity or something.

poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, 
events=POLLIN|POLLPRI}, {fd=12, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, 
events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN}, {fd=17, 
events=POLLIN}, {fd=20, events=POLLOUT}, {fd=22, events=POLLOUT}, {fd=24, 
events=POLLOUT}], 12, 0) = 4 ([{fd=3, revents=POLLIN}, {fd=20, 
revents=POLLOUT}, {fd=22, revents=POLLOUT}, {fd=24, revents=POLLOUT}])
read(3, "\6\0\0\0\0\0\0\0", 16) = 8
epoll_wait(15, [], 1, 0)= 0
clock_gettime(CLOCK_BOOTTIME, {tv_sec=124345, tv_nsec=994550347}) = 0
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8

Note: fd 22 is

NetworkMa 20906 root   20u IPv42035553  0t0 TCP   
debian:45852->senfter.debian.org:http (ESTABLISHED)

However the event loop doesn't seem to touch the connection in any
way. fds 20 and 24 are similar connections.

Do you have any ideas about this? I'm not very knowledgeable about curl,
but surely it shouldn't hog the glib main loop like that?

Regards
 Jiri Palecek

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-3-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#922553: Make link to the last release point announcement in the index page of each release

[Laura Arjona Reina]

Package: www.debian.org
User: www.debian@packages.debian.org
Usertag: scripts
Severity: normal

Dear all

Currently we have this kind of code in /english/releases/*/index.wml
(and translations):

---
Debian  was
released .
"
  "Debian 9.0 was initially released on <:=spokendate('2017-06-17'):>."
/>
The release included many major
changes, described in
our press release and
the Release Notes.
---

It would be nice if, apart of linking to the announcement of the initial
release, the announcement to the last point release of each release is
also linked.

I'm attaching a patch for stretch, as an example of what I mean.
If we like it, we would add the tags for each release in
release_info.wml template and update each release index.wml file (and
translations, if possible).

Kind regards
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
diff --git a/english/releases/stretch/index.wml b/english/releases/stretch/index.wml
index 887daf77b95..af0f78937f9 100644
--- a/english/releases/stretch/index.wml
+++ b/english/releases/stretch/index.wml
@@ -6,7 +6,9 @@
 
 
 Debian  was
-released .
+released on .
+
+
 "
   "Debian 9.0 was initially released on <:=spokendate('2017-06-17'):>."
 />
diff --git a/english/template/debian/release_info.wml b/english/template/debian/release_info.wml
index 55f6de018f0..fe41e58cf55 100644
--- a/english/template/debian/release_info.wml
+++ b/english/template/debian/release_info.wml
@@ -28,6 +28,7 @@
 <:=spokendate('2018-06-23'):>
 9.8
 <:=spokendate('2019-02-16'):>
+2019/20190216
 10.0
 TBA
 

Bug#922552: diffutils: FTBFS in ppc64el (failing tests)

[Santiago Vila]

Package: src:diffutils
Version: 1:3.7-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=diffutils=ppc64el=1%3A3.7-1=1550448741=0

Have to look at this.

Bug#922551: RM: oclgrind [armel] -- ROP; FTBFS with clang 7

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

/usr/bin/ld: liboclgrind-18.3.so: undefined reference to `__atomic_fetch_add_4'
/usr/bin/ld: liboclgrind-18.3.so: undefined reference to `__atomic_exchange_4'
/usr/bin/ld: liboclgrind-18.3.so: undefined reference to `__atomic_fetch_sub_4'
/usr/bin/ld: liboclgrind-18.3.so: undefined reference to `__atomic_load_1'
/usr/bin/ld: liboclgrind-18.3.so: undefined reference to `__atomic_store_4'
/usr/bin/ld: liboclgrind-18.3.so: undefined reference to `__atomic_load_4'
/usr/bin/ld: liboclgrind-18.3.so: undefined reference to `__atomic_store_1'
/usr/bin/ld: liboclgrind-18.3.so: undefined reference to 
`__atomic_compare_exchange_4'
collect2: error: ld returned 1 exit status

and I don't have time to debug this.


Andreas

Bug#887329: Bug #887329: minor url patch: /devel/website/using_cvs.wml

[Laura Arjona Reina]

Hello 황병희,
Thanks for reporting this bug, and sorry for the late reply.
The Debian Policy manual footnote url changed, I have updated the links
to the current footnote in the two files where the broken link was present:

https://salsa.debian.org/webmaster-team/webwml/commit/775bde4698a5b024eb1e3ba05a53cf38a0eb1fd5

(for the English files), and

https://salsa.debian.org/webmaster-team/webwml/commit/4ca161a0b9863813f8a964519fe1f253933d1005

for the translated files.

It will be online in the next hours.

Thanks again, even when I couldn't apply the patch it was helpful to
figure out where the problem was, and the fix.

Kind regards,
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#922550: ifupdown: network hangs for 5 minutes at startup / Failed to start Wait for network to be configured by ifupdown

[Vincent Lefevre]

On 2019-02-17 23:50:34 +0100, Vincent Lefevre wrote:
> After the ifupdown upgrade from 0.8.33 to 0.8.35, I now need to wait
> for 5 minutes before eth0 is up.

This problem occurs only when an Ethernet cable is already plugged in
before the boot.

Downgrading to 0.8.33 made the problem disappear.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#922532: linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders many systems unbootable

[M.Gergo]

Some additional info for the previous kernel_panic error:

Stop-log:
==


root@cubieboard2:~# powerpoff

 Stopping Session 1 of user root.
[  OK  ] Stopped target Sound Card.
 Stopping User Manager for UID 0...
 Stopping OpenBSD Secure Shell server...
 Stopping D-Bus System Message Bus...
 Stopping Regular background program processing daemon...
[  OK  ] Stopped System Logging Service.
[  OK  ] Stopped Internet superserver.
[  OK  ] Stopped Self Monitoring and Reporting Technology (SMART) Daemon.
[  OK  ] Stopped D-Bus System Message Bus.
[  OK  ] Stopped irqbalance daemon.
[  OK  ] Stopped Regular background program processing daemon.
[  OK  ] Stopped OpenBSD Secure Shell server.
[  OK  ] Stopped Serial Getty on ttyS0.
[  OK  ] Stopped Getty on tty1.
[  OK  ] Stopped Session 1 of user root.
[  OK  ] Stopped User Manager for UID 0.
[  OK  ] Removed slice User Slice of root.
 Stopping Login Service...
[  OK  ] Removed slice system-getty.slice.
[  OK  ] Removed slice system-serial\x2dgetty.slice.
 Stopping Permit User Sessions...
[  OK  ] Stopped /etc/rc.local Compatibility.
[  OK  ] Stopped Login Service.
[  OK  ] Stopped Permit User Sessions.
[  OK  ] Stopped LSB: Start NTP daemon.
[  OK  ] Stopped target Network is Online.
[  OK  ] Deactivated swap /var/swap_file.
[  OK  ] Stopped LSB: Autogenerate and use a swap file.
[  OK  ] Stopped The Apache HTTP Server.
[  OK  ] Stopped target Remote File Systems.
[  OK  ] Stopped target Host and Network Name Lookups.
[  OK  ] Stopped target Network.
 Stopping Raise network interfaces...
[  OK  ] Stopped target Basic System.
[  OK  ] Stopped target Paths.
[  OK  ] Stopped target Slices.
[  OK  ] Removed slice User and Session Slice.
[  OK  ] Stopped target Sockets.
[  OK  ] Closed D-Bus System Message Bus Socket.
[  OK  ] Closed Syslog Socket.
[  OK  ] Stopped target System Initialization.
 Stopping Update UTMP about System Boot/Shutdown...
[  OK  ] Stopped target Encrypted Volumes.
[  OK  ] Stopped Forward Password Requests to Wall Directory Watch.
[  OK  ] Stopped Dispatch Password Requests to Console Directory Watch.
 Stopping Load/Save Random Seed...
[  OK  ] Stopped target Swap.
[  OK  ] Stopped Load/Save Random Seed.
[  OK  ] Stopped Update UTMP about System Boot/Shutdown.
[  OK  ] Stopped Create Volatile Files and Directories.
[  OK  ] Stopped Raise network interfaces.
[  OK  ] Stopped Apply Kernel Variables.
[  OK  ] Stopped target Local File Systems.
 Unmounting /run/user/0...
 Unmounting /boot...
[  OK  ] Stopped Load Kernel Modules.
[  OK  ] Unmounted /run/user/0.
 Unmounting /home...
[  OK  ] Unmounted /boot.
[  OK  ] Stopped File System Check on 
/dev/d56366-7578-4efd-ab3c-dc9fb422579f.

[  OK  ] Unmounted /home.
[  OK  ] Reached target Unmount All Filesystems.
[  OK  ] Stopped File System Check on 
/dev/d1f8a9-2935-4cb6-9305-27cecd3b43c4.

[  OK  ] Stopped target Local File Systems (Pre).
[  OK  ] Stopped Create Static Device Nodes in /dev.
[  OK  ] Stopped Remount Root and Kernel File Systems.
[  OK  ] Removed slice system-systemd\x2dfsck.slice.
[  OK  ] Reached target Shutdown.
[  192.175162] reboot: Power down
[  194.239408] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[  194.763806] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x

[  194.763806]
[  194.772949] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 
4.9.0-7-armmp-lpae #1 Debian 4.9.110-3+deb9u2

[  194.782500] Hardware name: Allwinner sun7i (A20) Family
[  194.787758] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[  194.795506] [] (show_stack) from [] 
(dump_stack+0x90/0xa4)
[  194.802729] [] (dump_stack) from [] 
(panic+0x100/0x28c)
[  194.809692] [] (panic) from [] 
(complete_and_exit+0x0/0x2c)
[  194.817001] [] (complete_and_exit) from [] 
(SyS_reboot+0x1c8/0x238)
[  194.825004] [] (SyS_reboot) from [] 
(ret_fast_syscall+0x0/0x40)
[  194.832670] ---[ end Kernel panic - not syncing: Attempted to kill 
init! exitcode=0x

[  194.832670]

Bug#922549: A pretended hybrid ISO cannot be launched

[Steve McIntyre]

On Sun, Feb 17, 2019 at 11:20:09PM +0100, Ricky Tigg wrote:
>Package: cdimage.debian.org 
>
>Hi. An Image ISO claimed on official Debian page to be an "hybrid" ISO, with
>those properties
>
>$ file -b debian-9.7.0-amd64-DVD-3.iso
>ISO 9660 CD-ROM filesystem data 'Debian 9.7.0 amd64 3'
>
>and which has been written to an external flash drive relying on that command
>
>$ dd if=debian-9.7.0-amd64-DVD-3.iso of=/dev/sdc bs=4M oflag=direct && sync
>
>could not even be launched at boot due to error message:
>
>Reboot and select proper boot device or insert boot media in selected boot
>device and press a key.

Why are you trying to boot DVD#3? DVD#1 is the bootable disk, the rest
of the media set just contain extra packages...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Bug#853915: reportbug: Retrieved base64 messages aren't decoded

[Nis Martensen]

control: reassign 853915 debbugs

> >> When running e.g. `reportbug -N 853037`, a bunch of base64 is 
> >> displayed instead of the actual content of the messages.

> > I'm not sure if this problem comes from the BTS which sends wrong
> > SOAP or on my side for parsing it wrong.

> My suspicion is that the BTS SOAP interface has trouble with certain
> types of MIME messages (which can be quite complex...) and sends wrong
> SOAP. Can we reassign this bug (to check) if that is the case? (Where?)

The package taking BTS bugs is debbugs, reassigning there.

Summary: Reportbug functionality to browse existing bugs fails with
signed messages, where the encoded message is shown instead of decoded
message text. While this is not too critical with quoted-printable, it
is a real problem with base64 encoding. Try: reportbug -N 853037

reportbug internally does

> import debianbts as bts
> print(bts.get_bug_log()[0]['body']

to show the first message in a report. Example bugs where the problem
can be seen are: #853037, #820649, #861168

Could the BTS SOAP interface be changed to return the decoded message
body of signed messages? Being able to deal with all other kinds of
complex MIME messages is not really necessary.

Bug#922525: procps: typo in sysctl.conf

[Craig Small]

That shift key must have just dropped off for one of those 3/# button
presses.

I'll add that in for the next dh-make release.

 - Craig

Bug#921985: munin-node: df plugin fails to get data for /home

[Lars Kruse]

Hello,


Am Sat, 16 Feb 2019 16:33:53 +0100
schrieb Marc Donges :

> I think to make this less awkward two things would be nice:
> 
> - a option to allow monitoring of /home without editing a non-conffile in
> /lib (How is this even done properly? I just edited the service file to
> find the cause of my problem, but I suppose it will be overwritten on every
> update. Is there a nice way to do this?)

By accident I stumbled upon "systemctl edit munin-node".
This will open up an empty editor. Here you can add the following:

 [Service]
 ProtectHome = read-only

This will create a file /etc/systemd/system/munin-node.service.d/override.conf
with the above content and in turn override the settings of the system-wide
service file.


> - a way to alert the admin of the possibly unintended configuration:
> df-plugin activated + ProtectHome + Separate /home
> Can the df* plugin itself detect the situation and then make a log entry?
> That would have severely cut down the time it took me to find this.

I took a quick look at it.
Here the plugin within the environment simply does not notice that /home is
not accessible: it will simply be missing in the output by "df -h". Thus we
cannot emit a warning in this case.
Or does someone have an idea how to identify such an issue?
(and how we should report it)


Given that the "ProtectHome" setting allows the "read-only" value, I propose
that we should pick this one instead of "yes".

I think, we are mainly trying to protect the user from badly written plugins
that mess up something with their cleanup procedure and accidentally erase
relevant files. "read-only" would prevent this problem.
The different problem of munin plugins spying on users on purpose would indeed
justify "yes". But I tend to think, that everything is lost anyway, if a user
runs random malicious code on his host.

What do you think?

Cheers,
Lars

Bug#922531: lintian: Please make package-uses-vendor-specific-patch-series Debian-archive specific

[Guillem Jover]

Hi!

On Sun, 2019-02-17 at 22:41:19 +0100, Chris Lamb wrote:
> > So, I'd appreciate very much to see this tag emitted exclusively when
> > running lintian on lintian.d.o and Debian's ftp-master […] but not when
> > running locally

> Whilst I have not seen Ubuntu folks complain about this tag being
> emitted by Lintian I can understand the request to not run it on
> Ubuntu (etc.).

As I tried to convey in the parts that got elided, I do think the
Ubuntu folks would definitely want to have this tag be kept emitting
for their archive. That's at least what I gathered from their support
in the original policy bug.

> However, I do not follow why a Debian maintainer maintaining Debian
> packages should not see this when running Lintian locally, both in
> principle and in practice; it would be confusing for it to only
> appear on lintian.d.o and, for example, *I* would want to be
> alerted of this prior to an upload.

Right, and sorry, should have expanded on that. This is something I
also pondered, and I realize it would be slighly annoying to discover
that a package gets (eventually, which I think is the intention)
rejected only after the upload. But, this will get you a mail with
the reason, and this should happen only once (in theory :).

Having the packages not emit warnings right now would also be
inconvenient, but the number of users within the Debian archive is
low enough that a bug filing should be fine before the more severe
rejects get deployed after buster is released. At worst the
maintainers would find out once they upload after the rejects are
in place, which does not seem too bad either.

The problem with emitting this tag unconditionally, even within the
Debian-vendor realm, is that people create local packages for their
own, or for $work, etc., and in most cases will not go to the trouble
of creating a new vendor for this. And emitting such tag for a decision
that should only be getting applied within the Debian (and Ubuntu)
archives does not seem right?

> Lintian supports dpkg-vendor - can we not just add an exception to
> the Ubuntu vendor-specific profile?

As mentioned above, this really has nothing to do with Ubuntu, as in
they should be kept having the same treatment as the Debian archive.

Thanks,
Guillem

Bug#922550: ifupdown: network hangs for 5 minutes at startup / Failed to start Wait for network to be configured by ifupdown

[Vincent Lefevre]

Package: ifupdown
Version: 0.8.35
Severity: important

After the ifupdown upgrade from 0.8.33 to 0.8.35, I now need to wait
for 5 minutes before eth0 is up.

I've attached the beginning of "journalctl -b -1" output. At the end
of these 5 minutes, one can see:

Feb 17 23:15:24 zira systemd[1]: ifupdown-wait-online.service: Main process 
exited, code=exited, status=1/FAILURE
Feb 17 23:15:24 zira systemd[1]: ifupdown-wait-online.service: Failed with 
result 'exit-code'.
Feb 17 23:15:24 zira systemd[1]: Failed to start Wait for network to be 
configured by ifupdown.

Then everything can resume, and it is netplug that puts eth0 up.

With ifupdown 0.8.33, it was also netplug that put eth0 up, but it
did that 2 seconds after the start of the boot. Now, ifupdown 0.8.35
seems to block some units (including netplug).

-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
# [VL] No longer use "allow-hotplug eth0" as it makes the boot hang for
#  several dozens of seconds when no Ethernet cable is plugged in:
#  a DHCP client is started and is waiting for a response. The eth0
#  interface will automatically be brought up by netplugd (from the
#  netplug package) when an Ethernet connection is detected.
#allow-hotplug eth0
iface eth0 inet dhcp

# USB tethering with my Samsung Galaxy Note 3.
# Configuration on 2015-12-22:
allow-hotplug enx02060b0e
iface enx02060b0e inet dhcp
# Configuration on 2016-05-01:
allow-hotplug enp0s20u2
iface enp0s20u2 inet dhcp
# Configuration on 2016-12-23:
allow-hotplug enp0s20u9
iface enp0s20u9 inet dhcp
# Configuration on 2018-08-08:
allow-hotplug enp0s20u10
iface enp0s20u10 inet dhcp

# $Id: interfaces 110698 2018-08-08 12:36:44Z vinc17/zira $

--- /etc/network/interfaces.d/*:
cat: '/etc/network/interfaces.d/*': No such file or directory

--- up and down scripts installed:
/etc/network/if-down.d:
total 8
lrwxrwxrwx 1 vinc17 vinc17   12 2016-06-02 03:12:12 0ifupdown -> ../0ifupdown
-rwxr-xr-x 1 root   root   1015 2015-04-13 22:26:48 avahi-autoipd
-rwxr-xr-x 1 root   root800 2017-01-09 15:25:22 postfix
lrwxrwxrwx 1 root   root 32 2019-01-29 18:11:01 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-post-down.d:
total 4
lrwxrwxrwx 1 vinc17 vinc17   12 2016-06-02 03:12:12 0ifupdown -> ../0ifupdown
lrwxrwxrwx 1 root   root 23 2018-10-10 10:17:36 avahi-daemon -> 
../if-up.d/avahi-daemon
-rwxr-xr-x 1 root   root   1409 2016-03-24 18:38:26 wireless-tools
lrwxrwxrwx 1 root   root 32 2019-01-29 18:11:01 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-pre-up.d:
total 12
lrwxrwxrwx 1 vinc17 vinc17   12 2016-06-02 03:12:12 0ifupdown -> ../0ifupdown
-rwxr-xr-x 1 root   root344 2014-09-22 01:13:29 ethtool
-rwxr-xr-x 1 root   root   4191 2018-09-15 16:13:34 wireless-tools
lrwxrwxrwx 1 root   root 32 2019-01-29 18:11:01 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-up.d:
total 32
lrwxrwxrwx 1 vinc17 vinc17   12 2016-06-02 03:12:12 0ifupdown -> ../0ifupdown
-rwxr-xr-x 1 root   root923 2015-04-13 22:26:48 avahi-autoipd
-rwxr-xr-x 1 root   root484 2015-04-13 22:26:48 avahi-daemon
-rwxr-xr-x 1 root   root   1685 2014-09-22 01:22:24 ethtool
-rwxr-xr-x 1 root   root   4948 2019-01-05 12:21:53 mountnfs
-rwxr-xr-x 1 root   root278 2015-03-02 21:32:26 openntpd
-rwxr-xr-x 1 root   root   1117 2017-01-09 15:25:22 postfix
lrwxrwxrwx 1 root   root 32 2019-01-29 18:11:01 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh
-rwxr-xr-x 1 root   root370 2016-06-02 03:25:26 z_home_net


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-7
ii  lsb-base  10.2018112800

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- Configuration Files:
/etc/default/networking changed:
VERBOSE=yes


-- no debconf information
Feb 17 23:10:23 zira kernel: microcode: microcode updated early to revision 
0x25, date = 2018-04-02
Feb 17 23:10:23 zira kernel: Linux version 4.19.0-3-amd64 
(debian-ker...@lists.debian.org) (gcc version 

Bug#922544: lintian: Mass tag rename to unify naming convention

[Chris Lamb]

Hi Guillem,

> I don't think this is a problem anymore after the renamed-tags support
> was added [which] maps the override tag to the new name and does not even
> emit a tag of its own for this.

Oh, I had forgotten this (!) and assumed you were talking about the
rename detection that is part of generating the debian/changelog
summaries. Yes, this would appear to be sufficient.

Do others have thoughts before I apply this patch?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#922544: lintian: Mass tag rename to unify naming convention

[Guillem Jover]

On Sun, 2019-02-17 at 23:07:50 +0100, Chris Lamb wrote:
> > I'd request that no more such tag names be added, and ideally the
> > current ones be renamed, although the longer they stay the more
> > overrides they might accumulate. :/
> 
> That's my only concern at this point. I mean, there's probably
> countless debian-watch-may-check-gpg-signature overrides.
> 
> I wonder… Lintian could have a small list of aliases used only for
> overrides?

I don't think this is a problem anymore after the renamed-tags support
was added. Which maps the override tag to the new name and does not even
emit a tag of its own for this. I think this is the most inobtrusive way
to handle any such mass rename w/o bothering maintainers about it.

Perhaps it might be nice to eventually emit a pedantic tag or similar,
but I don't think this should be a blocker on any mass tag naming
cleanup TBH.

Thanks,
Guillem

Bug#922549: A pretended hybrid ISO cannot be launched

[Ricky Tigg]

Package: cdimage.debian.org 

Hi. An Image ISO claimed on official Debian page
 to be an "*hybrid*" ISO, with those
properties

$ file -b debian-9.7.0-amd64-DVD-3.iso
ISO 9660 CD-ROM filesystem data 'Debian 9.7.0 amd64 3'

and which has been written to an external flash drive relying on that
command

$ dd if=debian-9.7.0-amd64-DVD-3.iso of=/dev/sdc bs=4M oflag=direct && sync

could not even be launched at boot due to error message:

> *Reboot and select proper boot device or insert boot media in selected
> boot device and press a key.*
>

while a Live ISO image debian-live-9.7.0-amd64-gnome.iso  with those
properties could

$ file -b debian-live-9.7.0-amd64-gnome.iso
DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63),
end-CHS (0x3ff,254,63), startsector 1416, 832 sectors

Bug#921573: lintian: binary-from-other-architecture only works sometimes

[Chris Lamb]

Hi Mattia,

> For the advantage of everybody, here are links to the cross-builds from
> amd64 to mips64el and arm64 of procmail.

Wow, thanks for this! I had spent an hour trying to follow the
instructions on the Debian Wiki to get a crossbuild environment
which failed in a very strage way, so had shelved this for the time
being...

Anyway, with these:

$ dget 
https://volatile.mapreri.org/2019-02-17/130da1c8cbfd405daeb1a7d0a51f536d/ 
procmail_3.22-26_mips64el.changes
[…]

$ ar x *.deb

$ tar xfJ data.tar.xz 

$ find | grep bin/lockfile
./usr/bin/lockfile

$ file ./usr/bin/lockfile
./usr/bin/lockfile: ELF 64-bit LSB pie executable, x86-64, version 1 
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 3.2.0, BuildID[sha1]=61490d858790e4dc01926e63843ad0509abd0371, 
stripped

$ ./usr/bin/lockfile -v
lockfile v3.23pre 2001/09/13
Copyright (c) 1990-2001, Stephen R. van den Berg
Copyright (c) 1997-2001, Philip A. Guenther 



Perhaps I'm missing something, but this looks like /usr/bin/
lockfile is ann amd64 binary, not a a mips64el one.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#921598: No METAR available since noaa.gov switched to https

[Florent Rougon]

Hi again Gabriel, hi Tobias,

"Dr. Tobias Quathamer"  wrote:

> Hi Gabriel and Florent,
>
> thanks for reporting this bug and pointing to the commits! I'm currently
> preparing a new upload of simgear which should still be in time for buster.

The partial revert I foresaw has happened. :)

  
https://sourceforge.net/p/flightgear/flightgear/ci/c2fb01ccb7df6fc893ab79850654cb39153cea3d/

Regards

-- 
Florent

Bug#922548: Pointer is not movable

[Ricky Tigg]

Package: cdimage.debian.org 

Hi. While a Live ISO image debian-live-9.7.0-amd64-gnome.iso with those
properties

$ file -b debian-live-9.7.0-amd64-gnome.iso
DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63),
end-CHS (0x3ff,254,63), startsector 1416, 832 sectors

has been written to an external flash drive relying on command *dd,* and
once media was booted from BIOS, Debian installation steps had to rely
exclusively on the use of arrows in order to be operational, since the
pointer did not respond to invocations; it stayed at its default position,
centred onto the screen.

Bug#922544: lintian: Mass tag rename to unify naming convention

[Chris Lamb]

tags 922544 + moreinfo

Hey Guillem,

[Marking as moreinfo as patch/discussion is RFC.]

>   [T] 

Thanks for re-raising this; I was unaware of this previous
discussion.

[…]

> Encoding either the severity/certainty or the possible solution in the
> tag name duplicates the information contained elsewhere and makes them
> awkward to change.

Indeed and hardcoding RFC 2119 language (eg. must/should) can
simply get out of sync with Policy, if it was ever in sync to begin
with.

> I'd request that no more such tag names be added, and ideally the
> current ones be renamed, although the longer they stay the more
> overrides they might accumulate. :/

That's my only concern at this point. I mean, there's probably
countless debian-watch-may-check-gpg-signature overrides.

I wonder… Lintian could have a small list of aliases used only for
overrides?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#922530: lintian: False positive uses-dpkg-database-directly for dpkg and base-files

[Chris Lamb]

tags 922530 + pending
thanks

Whoops. Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/9af00bf5e4dbbcc536548d2765db47a95ccb2702


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#922365: openssh-server: dpkg --configure fails

[Peter.Chubb]

Hi Colin,
> "Colin" == Colin Watson  writes:

On Fri, Feb 15, 2019 at 01:20:53PM +1100, Peter Chubb wrote:
>> During a normal upgrade of ssh, I see: Restarting OpenBSD Secure
>> Shell server: sshdstart-stop-daemon: matching only on non-root
>> pidfile /run/sshd.pid is insecure invoke-rc.d: initscript ssh,
>> action "restart" failed.
>> 
>> and the package remains `unconfigured' in the database.

Colin> I started a container and installed sysvinit-core and
Colin> openssh-server in it, and I can't reproduce this bug there.  In
Colin> particular, /run/sshd.pid is owned by root.


Can't think of any local customisations.  But this machine started
off on Potato and has been upgraded regularly since then, so there may
be some legacy cruft hanging around.

$ ls -l /run/sshd.pid
-rw-r--r-- 1 root staff 6 Feb 15 13:21 /run/sshd.pid

I suspect the `staff' group is the issue.  Got that way because I have
an su shortcut that puts me in uid 0 group 50 for /usr/local update,
and I must have restarted sshd with those credentials one time.
Should /etc/init.d/ssh set the credentials to create /run/ssh.pid with ?

I chgrped the file to root then dpkg --configure  worked successfully.

-- 
Dr Peter Chubb Tel: +61 2 9490 5852  http://ts.data61.csiro.au/
Trustworthy Systems Group Data61, CSIRO (formerly NICTA)

Bug#922478: have yet to find an armhf board that works with 4.9.144-3

[Adrian Bunk]

On Sun, Feb 17, 2019 at 09:52:48AM -0800, Vagrant Cascadian wrote:
> After upgrading to the latest 4.9.x kernel in sid, all of the armhf
> boards running this kernel failed to boot.
> 
> Adding to the list:
> 
> imx6: Cubox-i4pro, Cubox-i4x4, Wandboard Quad
> exynos5: Odroid-XU4
> exynos4: Odroid-U3
> rk3328: firefly-rk3288
> sunxi A20: Cubietruck
> 
> 
> So it clearly impacts a wide variety of systems...

debian/patches/debian/arm-avoid-abi-change-in-4.9.139.patch changes
the order of struct processor but lacks a corresponding change to 
arch/arm/mm/proc-macros.S

> live well,
>   vagrant

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#922547: linux-image-4.9.0-8-armmp: Failed to boot after upgrading to linux-image-4.9.0-8-armmp version 4.9.144-3

[Jean-Marc]

Package: src:linux
Version: 4.9.130-2
Severity: normal

Dear Maintainer,

Today, I upgraded my Debian stable.  This upgrade included a Linux image 
upgrade from 4.9.130-2 to 4.9.144-3.

The ugrade went well but left my cubieboard unbootable.

I tried to create a rescue SD disk using the firmware + partition images I 
found here:
https://get.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/

But I got the same: an unbootable rescue disk.

I finally need to boot on my backup SD disk apt-marking the package 
linux-image-4.9.0-8-armmp as hold.

Jean-Marc



-- Package-specific info:
** Version:
Linux version 4.9.0-8-armmp (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.130-2 (2018-10-27)

** Command line:
console=ttyS0,115200 quiet

** Not tainted

** Kernel log:
[8.973619] Registered IR keymap rc-empty
[8.974088] input: sunxi-ir as 
/devices/platform/soc@01c0/1c21800.ir/rc/rc0/input0
[8.974114] rc rc0: sunxi-ir as 
/devices/platform/soc@01c0/1c21800.ir/rc/rc0
[9.008281] sunxi-ir 1c21800.ir: initialized sunXi IR driver
[9.086910] lirc_dev: IR Remote Control driver registered, major 242
[9.094194] rc rc0: lirc_dev: driver ir-lirc-codec (sunxi-ir) registered at 
minor = 0
[9.094209] IR LIRC bridge handler initialized
[9.197604] input: axp20x-pek as 
/devices/platform/soc@01c0/1c2ac00.i2c/i2c-0/0-0034/axp20x-pek/input/input1
[9.293592] sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok
[9.417609] Adding 1000444k swap on /dev/mmcblk0p2.  Priority:-1 extents:1 
across:1000444k SSFS
[   11.391116] random: crng init done
[   11.391132] random: 7 urandom warning(s) missed due to ratelimiting
[   13.618733] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: 
(null)
[   13.850605] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: 
(null)
[   14.024784] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: 
(null)
[   14.157500] systemd-journald[193]: Received request to flush runtime journal 
from PID 1
[   14.408922] EXT4-fs (mmcblk0p1): mounting ext2 file system using the ext4 
subsystem
[   14.419429] EXT4-fs (mmcblk0p1): mounted filesystem without journal. Opts: 
(null)
[   15.810981] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   16.950694] sun4i-emac 1c0b000.ethernet eth0: Link is Up - 100Mbps/Full - 
flow control rx/tx
[   16.950732] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   31.099975] tun: Universal TUN/TAP device driver, 1.6
[   31.099986] tun: (C) 1999-2004 Max Krasnyansky 
[  121.770373] rc rc0: IR event FIFO is full!
[  121.774487] rc rc0: IR event FIFO is full!
[  121.778581] rc rc0: IR event FIFO is full!
[  121.782674] rc rc0: IR event FIFO is full!
[  121.786771] rc rc0: IR event FIFO is full!
[  121.790864] rc rc0: IR event FIFO is full!
[  121.794956] rc rc0: IR event FIFO is full!
[  121.799049] rc rc0: IR event FIFO is full!
[  121.803141] rc rc0: IR event FIFO is full!
[  121.807233] rc rc0: IR event FIFO is full!
[  121.811325] rc rc0: IR event FIFO is full!
[  121.815418] rc rc0: IR event FIFO is full!
[  121.819540] rc rc0: IR event FIFO is full!
[  121.823633] rc rc0: IR event FIFO is full!
[  121.827726] rc rc0: IR event FIFO is full!
[  121.831818] rc rc0: IR event FIFO is full!
[  121.835910] rc rc0: IR event FIFO is full!
[  121.840002] rc rc0: IR event FIFO is full!
[  121.844095] rc rc0: IR event FIFO is full!
[  121.848187] rc rc0: IR event FIFO is full!
[  121.852279] rc rc0: IR event FIFO is full!
[  121.856375] rc rc0: IR event FIFO is full!
[  121.860468] rc rc0: IR event FIFO is full!
[  121.864562] rc rc0: IR event FIFO is full!
[  307.911134] nf_conntrack: default automatic helper assignment has been 
turned off for security reasons and CT-based  firewall rule not found. Use the 
iptables CT target to attach helpers instead.
[  406.240378] systemd: 42 output lines suppressed due to ratelimiting
[  859.482624] rc rc0: IR event FIFO is full!
[  859.495934] rc rc0: IR event FIFO is full!
[  879.822042] rc rc0: IR event FIFO is full!
[  879.826157] rc rc0: IR event FIFO is full!
[  879.830265] rc rc0: IR event FIFO is full!
[  879.834358] rc rc0: IR event FIFO is full!
[  879.838449] rc rc0: IR event FIFO is full!
[  879.842540] rc rc0: IR event FIFO is full!
[  879.846632] rc rc0: IR event FIFO is full!
[  879.850725] rc rc0: IR event FIFO is full!
[  879.854818] rc rc0: IR event FIFO is full!
[  879.858910] rc rc0: IR event FIFO is full!
[  879.863002] rc rc0: IR event FIFO is full!
[  879.867112] rc rc0: IR event FIFO is full!
[  879.871206] rc rc0: IR event FIFO is full!
[  879.875299] rc rc0: IR event FIFO is full!
[  879.879391] rc rc0: IR event FIFO is full!
[  879.883483] rc rc0: IR event FIFO is full!
[  879.887576] rc rc0: IR event FIFO is full!
[  879.891667] rc rc0: IR event FIFO is full!
[  879.895759] rc rc0: IR event FIFO is full!
[  879.899860] 

Bug#922478: upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 4.9.130-2 to 4.9.144-3 renders many systems unbootable

[Vagrant Cascadian]

Control: retitle 922478 upgrade linux-image-4.9.0-8-armmp-lpae:armhf from 
4.9.130-2 to 4.9.144-3 renders many systems unbootable

On 2019-02-17, Timo Sigurdsson wrote:
> Cyril Brulebois schrieb am 17.02.2019 19:38:
>> Jürgen Löb  (2019-02-16):
>>> Package: linux-image-4.9.0-8-armmp-lpae
>>> Version: 4.9.144-3
>>> Severity: serious

FWIW, I also built a local package from 4.9.155-1~ from salsa/stretch
git, and it worked on a wandboard quad.

$ uname -a
Linux wbq0 4.9.0-9-armmp #1 SMP Debian 4.9.155-1~20190217~1 (2019-02-17) armv7l 
GNU/Linux

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#922531: lintian: Please make package-uses-vendor-specific-patch-series Debian-archive specific

[Chris Lamb]

tags 922531 + moreinfo
thanks

Hi Guillem,

> As the maintainer of dpkg, I [..]

I note your dislike of the decision that was reached by the CTTE in
#904302. I will pass no comment on it either way.
 
> So, I'd appreciate very much to see this tag emitted exclusively when
> running lintian on lintian.d.o and Debian's ftp-master […] but not when
> running locally

Whilst I have not seen Ubuntu folks complain about this tag being
emitted by Lintian I can understand the request to not run it on
Ubuntu (etc.).

However, I do not follow why a Debian maintainer maintaining Debian
packages should not see this when running Lintian locally, both in
principle and in practice; it would be confusing for it to only
appear on lintian.d.o and, for example, *I* would want to be
alerted of this prior to an upload.

Lintian supports dpkg-vendor - can we not just add an exception to
the Ubuntu vendor-specific profile?


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#922546: qa.debian.org: [udd] upload_history table not updating

[Joao Eriberto Mota Filho]

Package: qa.debian.org
Severity: important

Hi all,

When using the following command against official and public UDD servers,
the dates are missing:

SELECT source, upload_date::date FROM bapase ORDER BY upload_date DESC limit 30;

The last registered date is 2019-01-16. It can be confirmed here[1]. Today,
there are 3.442 source packages in Sid shown without a date.

[1] https://people.debian.org/~eriberto/udd/help_a_package.html

I also tested upload_history table and it stopped in 2019-01-16. I used the
following command:

SELECT source, date FROM upload_history ORDER BY date DESC limit 30;

Thanks in advance.

Regards,

Eriberto

Bug#922545: lxc: FTBFS on hppa - symbol mismatch

[John David Anglin]

Source: lxc
Version: 1:3.1.0+really3.0.3-4
Severity: normal

Dear Maintainer,

The symbol definitions for hppa need updating.  See:
https://buildd.debian.org/status/fetch.php?pkg=lxc=hppa=1%3A3.1.0%2Breally3.0.3-4=1550337104=0

Thanks,
Dave Anglin


-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.14.101+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#922367: nas FTCBFS: builds for the wrong architecture

[Steve McIntyre]

COntrol: tag -1 +pending

On Fri, Feb 15, 2019 at 10:50:46AM +0700, Do Thanh Trung wrote:
>Source: nas
>Version: 1.9.4-6
>Severity: normal
>Tags: patch
>User: helm...@debian.org
>Usertags: rebootstrap
>
>Hi,
>
>nas fails to cross build because it does not pass cross build tools to make.
>Using "dh_auto_build" instead of "$(MAKE)" can solve this problem.

ACK. Thanks for the patch, I've applied it in current git.

>
>Do Thanh Trung (Mr.)
>Toshiba Software Development (Vietnam) Co.,Ltd
>13th Floor, VIT Building, 519 Kim Ma street, Ba Dinh District, Hanoi, Vietnam
>Tel: (84-4) 22 20 88 01 (ext: 207)
>
>
>Note: This e-mail message may contain personal information or confidential
>information.
>If you are not the addressee of this message, please delete this message and
>kindly
>notify the sender as soon as possible, do not copy, use, or disclose this
>message.

If you're contributing to open source projects, you should probably do
something about this daft message, though!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Bug#922544: lintian: Mass tag rename to unify naming convention

[Guillem Jover]

Package: lintian
Version: 2.7.0
Severity: wishlist

Hi!

I brought this up for discussion on the mailing list some time ago [T],
and it resulted in the added support for renaming tags, which is great!
But the proposal then kind of died off.

  [T] 

I'm copying below that initial mail, and attaching the subsequent
rename proposals (plus a few more I think) as a patch using the added
mechanism, even though I've not checked for newly introduced tags since,
as a discussion starter. If there's agreement I could sit down and check
the rest of the tags, and actually rename them in the code base.

§§§

I've noticed the recent addition of tags with either very confusing
names like:

- debian-watch-may-check-gpg-signature

  As reported in #735040, where the suggested name seems way better:
  debian-watch-does-not-check-for-gpg-signature

- privacy-breach-may-use-debian-package

  Does the privacy breach use the package? A better name could perhaps be:
  privacy-breach-uses-embedded-file

Or names that instead of stating the detected fact, seem to dictate what
it would like to see.

- file-should-not-be-compressed

- debian-rules-should-not-automatically-update-control
- debian-rules-should-not-use-DEB_BUILD_OPTS
- debian-rules-should-not-use-or-modify-user-only-variable
- debian-rules-should-not-use-pwd
- debian-rules-should-not-use-underscore-variable

- maintainer-script-should-not-hide-init-failure
- maintainer-script-should-not-modify-ld-so-conf
- maintainer-script-should-not-modify-netbase-managed-file
- maintainer-script-should-not-use-adduser-system-without-home
- maintainer-script-should-not-use-ancient-dpkg-epoch-check
- maintainer-script-should-not-use-ancient-dpkg-multi-conrep-check
- maintainer-script-should-not-use-deprecated-chown-usage
- maintainer-script-should-not-use-dpkg-status-directly
- maintainer-script-should-not-use-fc-cache
- maintainer-script-should-not-use-gconftool
- maintainer-script-should-not-use-install-sgmlcatalog
- maintainer-script-should-not-use-service
- maintainer-script-should-not-use-start-stop-daemon
- maintainer-script-should-not-use-update-alternatives-remove
- maintainer-script-should-not-use-update-alternatives-set

I agree with Jakub Wilk's recent comments on the list that these are not
good names either. Lintian detects patterns, some might be problems that
must be fixed in all cases, others might be a matter of policy, others
might perhaps be issues sometimes, and that's why lintian allows
overridding/disabling them either per package or per profile. Encoding
either the severity/certainty or the possible solution in the tag name
duplicates the information contained elsewhere and makes them awkward
to change.

I'd request that no more such tag names be added, and ideally the
current ones be renamed, although the longer they stay the more
overrides they might accumulate. :/

I skimmed over other tag names and I've found also these patterns which
raise red flags for me (might have missed some), and do not conform
with the vast majority of other tags, or even related ones:

# -must-not-

- udeb-postinst-must-not-call-ldconfig

# -should-not-

- web-application-should-not-depend-unconditionally-on-apache2
- orphaned-package-should-not-have-uploaders
- changelog-should-not-mention-nmu
- debian-revision-should-not-be-zero
- library-in-debug-or-profile-should-not-be-stripped

# -might-not-

- description-synopsis-might-not-be-phrased-properly

# -should-

- changelog-should-mention-nmu
- changelog-should-mention-qa
- clean-should-be-satisfied-by-build-depends
- copyright-should-refer-to-common-license-file-for-apache-2
- copyright-should-refer-to-common-license-file-for-gfdl
- copyright-should-refer-to-common-license-file-for-gpl
- copyright-should-refer-to-common-license-file-for-lgpl
- debian-watch-file-should-dversionmangle-not-uversionmangle
- debian-watch-file-should-mangle-version
- debian-watch-file-should-use-sf-redirector
- debian-watch-file-should-uversionmangle-not-dversionmangle
- debug-file-should-use-detached-symbols
- debug-package-should-be-named-dbg
- debug-package-should-be-priority-extra
- games-package-should-be-section-games
- init.d-script-should-depend-on-virtual-facility
- menu-method-should-include-menu-h
- new-package-should-close-itp-bug
- postrm-should-call-ldconfig
- symlink-should-be-absolute
- symlink-should-be-relative
- transitional-package-should-be-oldlibs-extra

Thanks,
Guillem
From b094a6099aaeba702d3d88cca6da88494ce48297 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 17 Feb 2019 20:43:53 +0100
Subject: [PATCH] RFC: Mass tag rename to try to unify naming conventions

---
 data/override/renamed-tags | 65 --
 1 file changed, 63 insertions(+), 2 deletions(-)

diff --git a/data/override/renamed-tags b/data/override/renamed-tags
index aa87b6113..cc51c01c8 100644
--- a/data/override/renamed-tags

Bug#922534: lintian: Typo fixes

[Chris Lamb]

tags 922534 + pending
thanks

Thanks. Aplied in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/862a4b4ec7f0dcab8efd804cda9a1bdef662c37c

  checks/deb-format.pm| 4 ++--
  t/tags/debs/deb-format-wrong-order/tags | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#922543: python-certbot: FTBFS in stretch when built with sbuild (unmet build-depends)

[Santiago Vila]

Package: src:python-certbot
Version: 0.28.0-1~deb9u1
Severity: serious
Tags: ftbfs patch

Dear maintainer:

I tried to build this package in stretch but it failed:


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 778 B of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 copy:/<>/resolver-imjM6a/apt_archive ./ 
sbuild-build-depends-core-dummy 0.invalid.0 [778 B]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 778 B in 0s (0 B/s)
Selecting previously unselected package sbuild-build-depends-core-dummy.
(Reading database ... 13595 files and directories currently installed.)
Preparing to unpack .../sbuild-build-depends-core-dummy_0.invalid.0_amd64.deb 
...
Unpacking sbuild-build-depends-core-dummy (0.invalid.0) ...
Setting up sbuild-build-depends-core-dummy (0.invalid.0) ...

+--+
| Check architectures  |
+--+

Arch check ok (amd64 included in all)

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>= 10~), dh-python, python3, python3-acme (>= 
0.26.0~), python3-configargparse (>= 0.10.0), python3-configobj, 
python3-cryptography (>= 1.2), python3-distutils | python3 (<< 3.6.5~), 
python3-josepy, python3-mock, python3-parsedatetime (>= 1.3), 
python3-repoze.sphinx.autointerface, python3-requests (>= 2.4.3), 
python3-rfc3339, python3-setuptools (>= 1.0), python3-sphinx (>= 1.2), 
python3-sphinx-rtd-theme, python3-tz, python3-zope.component, 
python3-zope.interface
Filtered Build-Depends: debhelper (>= 10~), dh-python, python3, python3-acme 
(>= 0.26.0~), python3-configargparse (>= 0.10.0), python3-configobj, 
python3-cryptography (>= 1.2), python3-distutils, python3-josepy, python3-mock, 
python3-parsedatetime (>= 1.3), python3-repoze.sphinx.autointerface, 
python3-requests (>= 2.4.3), python3-rfc3339, python3-setuptools (>= 1.0), 
python3-sphinx (>= 1.2), python3-sphinx-rtd-theme, python3-tz, 
python3-zope.component, python3-zope.interface
dpkg-deb: building package 'sbuild-build-depends-python-certbot-dummy' in 
'/<>/resolver-imjM6a/apt_archive/sbuild-build-depends-python-certbot-dummy.deb'.
dpkg-scanpackages: warning: Packages in archive but missing from override file:
dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy 
sbuild-build-depends-python-certbot-dummy
dpkg-scanpackages: info: Wrote 2 entries to output Packages file.
Ign:1 copy:/<>/resolver-imjM6a/apt_archive ./ InRelease
Get:2 copy:/<>/resolver-imjM6a/apt_archive ./ Release [963 B]
Ign:3 copy:/<>/resolver-imjM6a/apt_archive ./ Release.gpg
Get:4 copy:/<>/resolver-imjM6a/apt_archive ./ Sources [684 B]
Get:5 copy:/<>/resolver-imjM6a/apt_archive ./ Packages [750 B]
Fetched 2397 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install python-certbot build dependencies (apt-based resolver)
--

Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 sbuild-build-depends-python-certbot-dummy : Depends: python3-distutils but it 
is not installable
E: Unable to correct problems, you have held broken packages.
apt-get failed.
E: Package installation failed
Not removing build depends: cloned chroot in use
/usr/bin/du: cannot access '/<>': No such file or directory
E: read_command failed to execute du
E: Cannot determine space needed for /<> (du failed)

Setup apt archive
-

Merged Build-Depends: dose-distcheck
Filtered Build-Depends: dose-distcheck
dpkg-deb: building package 'sbuild-build-depends-dose3-dummy' in 
'/<>/resolver-imjM6a/apt_archive/sbuild-build-depends-dose3-dummy.deb'.
dpkg-scanpackages: warning: Packages in archive but missing from override file:
dpkg-scanpackages: warning:   sbuild-build-depends-core-dummy 
sbuild-build-depends-dose3-dummy sbuild-build-depends-python-certbot-dummy
dpkg-scanpackages: info: Wrote 3 entries to 

Bug#922542: dietlibc-dev: new version available

[Dmitry Bogatov]

Package: dietlibc-dev
Version: 0.34~cvs20160606-10
Severity: wishlist

Dear Maintainer,

please consider packaging version 0.34, released 2018-09-24.

-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)

dietlibc-dev depends on no packages.

dietlibc-dev recommends no packages.

Versions of packages dietlibc-dev suggests:
pn  dietlibc-doc  

-- no debconf information


pgpLbOzdLX30G.pgp
Description: PGP signature

Bug#922541: lintian-brush: creating commit for already minimal key

[Dmitry Bogatov]

Package: lintian-brush
Version: 0.12
Severity: normal

Dear Maintainer,

minimal-key fixer generated following commit, removing just one line
of meta-info from signing key, that does not match commit description.

From 5f3f04688b4a091240237bbf2fe30149cb5eb3fa Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Sat, 16 Feb 2019 18:39:34 +
Subject: [PATCH] Re-export upstream signing key without extra signatures.

Fixes lintian: public-upstream-key-not-minimal
See https://lintian.debian.org/tags/public-upstream-key-not-minimal.html for 
more details.
---
 debian/changelog| 1 +
 debian/upstream/signing-key.asc | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index dc35a9f..b81e999 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ cdist (4.10.6-1) UNRELEASED; urgency=medium
 
   * New upstream release
   * Use secure URI in Homepage field.
+  * Re-export upstream signing key without extra signatures.
 
  -- Dmitry Bogatov   Sat, 16 Feb 2019 18:34:14 +
 
diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc
index 14eb360..99b7cea 100644
--- a/debian/upstream/signing-key.asc
+++ b/debian/upstream/signing-key.asc
@@ -1,5 +1,4 @@
 -BEGIN PGP PUBLIC KEY BLOCK-
-Version: GnuPG v1
 
 mQINBFeCnRQBEACoybnhBEubglOHJrZQ8PKcdeQaGZRoTc3cDs84lr6a9HiLeoBO
 f8x9fpN4LJbaJOyFJLcvVHHcljvooCLqL5t8/pj7Lyvq1AYuMAeS2Wy19amy3tE5




pgpe6D6OObyo0.pgp
Description: PGP signature

Bug#823892: fail2ban: very slow startup *and* shutdown

[Antoine Beaupré]

Control: tags -1 +confirmed
Control: found -1 0.9.6-2
Control: fixed -1 0.10.2-2~bpo9+1

[hmm... sorry for the duplicate email, not sure how i managed to send
the last one, but here's the complete version.]

TL;DR: this is probably fixed in buster, try the version in
stretch-backports.

I can confirm both bugs here. During the last upgrade, needrestart
noticed fail2ban needed a restart, so it did. Here's what systemd sees
right now:

root@marcos:/home/anarcat# systemctl status fail2ban
● fail2ban.service - Fail2Ban Service
   Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Sun 2019-02-17 15:32:58 EST; 9min ago
 Docs: man:fail2ban(1)
  Process: 5829 ExecStop=/usr/bin/fail2ban-client stop (code=exited, status=255)
  Process: 12738 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, 
status=0/SUCCESS)
 Main PID: 12745 (fail2ban-server)
Tasks: 14 (limit: 4915)
   Memory: 33.3M
  CPU: 3min 14.842s
   CGroup: /system.slice/fail2ban.service
   └─12745 /usr/bin/python3 /usr/bin/fail2ban-server -s 
/var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ba

fév 17 15:42:06 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.80
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.82
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.84
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.85
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.86
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.87
fév 17 15:42:07 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.88
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.90
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.91
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.93
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.94
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.95
fév 17 15:42:08 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.178.97

... and those lines are still being added there:

fév 17 15:43:28 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
60.168.182.250

etc...

In other words, fail2ban has been loading a list of IP addresses in the
firewall for the last 9 minutes. Before that, it was *removing* IP
addresses from the firewall for another three minutes (before systemd
gave up, maybe related to #788805):

root@marcos:/home/anarcat# journalctl -u fail2ban.service | grep systemd
fév 17 15:29:57 marcos systemd[1]: Stopping Fail2Ban Service...
fév 17 15:31:27 marcos systemd[1]: fail2ban.service: Stopping timed out. 
Terminating.
fév 17 15:31:27 marcos systemd[1]: fail2ban.service: Control process exited, 
code=exited status=255
fév 17 15:32:57 marcos systemd[1]: fail2ban.service: State 'stop-sigterm' timed 
out. Killing.
fév 17 15:32:57 marcos systemd[1]: fail2ban.service: Killing process 2176 
(fail2ban-server) with signal SIGKILL.
fév 17 15:32:57 marcos systemd[1]: fail2ban.service: Main process exited, 
code=killed, status=9/KILL
fév 17 15:32:57 marcos systemd[1]: Stopped Fail2Ban Service.
fév 17 15:32:57 marcos systemd[1]: fail2ban.service: Unit entered failed state.
fév 17 15:32:57 marcos systemd[1]: fail2ban.service: Failed with result 
'timeout'.
fév 17 15:32:57 marcos systemd[1]: Starting Fail2Ban Service...
fév 17 15:32:58 marcos systemd[1]: Started Fail2Ban Service.

Now it systemd considers the thing "started" even though it's still
loading the IP list. Because systemd timed out, we also see this in the
logs:

fév 17 15:45:39 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] 
183.160.227.26 already banned 

... obviously, fail2ban didn't have time to remove all addresses from
the firewall. It ended up taking 15 minutes loading the entire IP set
back into memory, between the first IP loaded and the last:

fév 17 15:32:58 marcos systemd[1]: Started Fail2Ban Service.
[...]
fév 17 15:32:58 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] Ban 
103.207.37.40
[...]
fév 17 15:47:13 marcos fail2ban.actions[12745]: NOTICE [postfix-auth] 
60.168.182.26 already banned

There are many things wrong here:

 1. "service fail2ban restart" should try to remove all IP addresses
from the firewall if it's going to re-add them all a second later

 2. even if it *does* decide to do that, it shouldn't fail halfway
through.

 3. if "stop" waits for all IPs to be cleared out, "start" should as
well

 4. loading IP addresses shouldn't be that slow

We could try to fix points 1-3, but I think the problem really lies with
point 4. Why is fail2ban so damn slow at loading those IP sets?

I don't have that many addresses loaded in that jail: