Bug#919349: pyvo: Please remove python-astropy-helpers build dependency

[Ole Streicher]

Source: pyvo
Version: 0.9.2-1
Severity: serious

Dear maintainer,

python-astropy-helpers (the Python 2 package) is going away soon.
Therefore, please remove it as build dependency from pyvo. I is probably
anyway unused and just forgotten to remove, right?

Cheers

Ole

Bug#919348: xfce4-screensaver: Accidental upload to unstable while fixing bug #919151

[Jonathan Carter]

Package: xfce4-screensaver
Version: 0.1.3-1
Severity: important

While fixing #919151, I uploaded this package to unstable when
it was meant to go to experimental.

This package is still beta and security-wise, we don't consider
it quite ready yet to support in a stable release.

So we're filing an RC bug to prevent it from migrating to testing,
this can be closed once buster is frozen.

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Bug#919332: casparcg-server: FTBFS in sid (cannot find -lpthreads)

[Petter Reinholdtsen]

[Santiago Vila]
> I tried to build this package in sid but it failed:

Thank you for the heads up.

> but the error message suggests a missing build-dependency.

I agree, but libpthread is part of glibc, so it can not be that one.
Perhaps libc6-dev is the missing one?  Seem unlikely, given it is
Build-Essential: yes.  Any idea which one can be missing?

It build for me, but I fail to understand why now. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#919347: matrix-synapse: Logs everything to /var/log/messages by default

[Kurt Roeckx]

Package: matrix-synpase

Hi,

It seems that at least version 0.34.0-3~bpo9+2 logs everything to
/var/log/messages, and also to
/var/log/matrix-synapse/homeserver.log

/var/log/messages is currently a 1.3 GB file, containing data for
about 1 day. /var/log/matrix-synapse/homeserver.log on the other
hand gets rotated more often, and contains the same messages.

I have logcheck check the logs for me, which now takes over 1
hours to run.

Please stop logging everything to both files. It only used to
contain the errors in /var/log/messages.


Kurt

Bug#919346: ruby-data-migrate: Missing tasks/databases.rake file

[李健秋]

Package: ruby-data-migrate
Version: 3.2.2-1
Severity: important

Dear Ruby team,

Just noticed that the `tasks/databases.rake` are exist in the source
package, but doesn't get installed in the binary package.

So that I got following errors:
```
root@obs-api:/# /usr/share/obs/api/script/rake-tasks.sh setup
rake aborted!
LoadError: cannot load such file --
/usr/lib/ruby/vendor_ruby/data_migrate/../../tasks/databases.rake
/usr/share/obs/api/Rakefile:7:in `'
(See full trace by running task with --trace)
```

The problem is the tasks/ doesn't get installed. I did a hack on the
package to copy over tasks/ into lib/ at the build time to solved this.

However I am not sure if this is the proper way to handle the missing
installed file for ruby package. Please help to review my merge
request:
 https://salsa.debian.org/ruby-team/ruby-data-migrate/merge_requests/1

Best regards,
-Andrew

Bug#784479: [kde4libs] Qt4's WebKit removal

[Pino Toscano]

In data lunedì 14 gennaio 2019 22:28:46 CET, Adrian Bunk ha scritto:
> What is actually the overall plan for KDE4 in buster now?

kdelibs 4.x will stay in buster. Period.

Dropping stuff just for the sake of removal is a no-go, especially
when done from people who have NO IDEA about Qt/KDE
libraries/applications.

As I already asked you: Adrian Bunk, please stay away from Qt/KDE
stuff.

Thanks,
-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Bug#919345: RM: alpine [kfreebsd-amd64 kfreebsd-i386] -- ROM; Old cruft package existing on non-released architectures only

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

according to

$ rmadison alpine | grep "unstable "
alpine | 2.20+dfsg1-2| unstable   | source, kfreebsd-amd64, 
kfreebsd-i386
alpine | 2.21+dfsg1-1.1  | unstable   | source, amd64, arm64, 
armel, armhf, hurd-i386, i386, mips, mips64el, mipsel, ppc64el, s390x


version 2.20+dfsg1-2 should be deleted from the archive.

Kind regards

Andreas.

Bug#784479: [kde4libs] Qt4's WebKit removal

[Pino Toscano]

In data lunedì 14 gennaio 2019 12:22:52 CET, Scott Kitterman ha scritto:
> On Thu, 01 Nov 2018 14:04:12 -0300 Lisandro 
> =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer  wrote:
> > On Wed, 17 Oct 2018 15:57:25 +0200 Ivo De Decker  wrote:
> > > Hi,
> > > 
> > > On Fri, Nov 24, 2017 at 04:59:58PM -0300, Lisandro Damián Nicanor Pérez 
> > Meyer wrote:
> > > > Control: tag -1 patch
> > > > 
> > > > There is patch available for this at 
>  > > > packages.git/tree/trunk/kdelibs-no-kdewebkit.patch?h=packages/kdelibs>
> > > > 
> > > > We might want to wait for the last tandem of KF5 apps though.
> > > 
> > > Is there anything still blocking this?
> > 
> > Yes, at least one co maintainer believes the kde-runtime patch is not 
> > appropriate.
> 
> That patch no longer seems to be available, so I made my own.  Patches for 
> kde4libs and kde-runtime attached.  I looked at the KDE4 packages still in 
> Buster and I don't believe this interferes with anything.  This also fixes 
> the 
> FTBFS with Samba 4.9 by dropping the KDE4 kio_smb.

The samba compatibility issue is a different story, and it can be fixed
by just disabling kio_smb (in case it requires non-trivial work to make
it work again).

> I think we should move forward on these (or some improved version if someone 
> has suggestions).
> 
> Even though there are separate bugs for kde-runtime, since the patch for it 
> was already discussed in this bug, I thought we might as well keep them 
> together.

Did you check that all the packages using kde4libs still build fine?

The removal of kio_thumbnail from kde-runtime is definitely not
appropriate, since it will break the thunbnail support for any
kdelibs 4.x application.

Again: something worth to mention, since apparently it is not clear:
removing bits from either kde4libs or kde-runtime has consequences,
either build time or runtime ones. Randomly chopping pieces without
checking what changes, and potentially what breaks, is generally a
big no-no from me. I do not see how "remove qtwebkit" is an excuse to
start messing up with packages, just for the sake of package removal.

-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Bug#919344: adequate reports obsolete-conffile in openssh-client

[shirish शिरीष]

Package: openssh-client
Version: 1:7.9p1-5
Severity: normal

Usertags: obsolete-conffile adequate

Dear Maintainer,

Thank you for maintaining openssh. So much of our modern world depends on it.

While updating today, adequate informs me about this -

$ adequate openssh-client
openssh-client: obsolete-conffile /etc/ssh/moduli

Please look into this and fix the offending file.

-- 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: amd64 (x86_64)

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

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.19.2
ii  libc6 2.28-5
ii  libedit2  3.1-20181209-1
ii  libgssapi-krb5-2  1.16.2-1
ii  libselinux1   2.8-1+b1
ii  libssl1.1 1.1.1a-1
ii  passwd1:4.5-1.1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain
pn  libpam-ssh  
ii  lxqt-openssh-askpass [ssh-askpass]  0.13.0-1
pn  monkeysphere

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#919162: lintian.d.o apears to report many failures twice

[Niels Thykier]

Chris Lamb:
> [Adding ni...@thykier.net to CC]
> 
> Hi Ian,
> 
>> It seems that lintian.d.o lists some (all?) failures in a binary
>> package twice.
> […]
>>  * usr/bin/grub-editenv
>>  * usr/bin/grub-editenv
> […]
> 
>> I failed to find the raw reports anywhere so I can't see if these are
>> duplicated there
> 
> So I dug them out from 
> /srv/lintian.debian.org/reports-directory/www/lintian.log.gz
> on lindsay.debian.org:
> 
> [...]
> 
> … so I think that this is something depper in the reporting system
> itself (and they are not emitted twice locally).
> 
> Unfortunately this is an area that I don't know very well at all so
> I'm not even sure where to start. Niels (CC'd), can you help point
> me at least in the right direction, perhaps?
> 
> 
> Regards,
> 

What you see is that grub-editenv have the tag twice because the tag
appears on different architectures (i386 vs. amd64).  The reporting
framework was never updated to include this information more smoothly
than simply adding the tag twice.

Thanks,
~Niels

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

[Diane Trout]

On Tue, 2019-01-15 at 00:08 +0100, Florian Schlichting wrote:
> 
> Before thinking about cleanup, I'd start by making sure that fresh
> installs don't re-create problems. At the moment, purging dnssec-
> trigger
> leaves two keypairs in /etc; and when I rm them manually, and again
> install dnssec-trigger, they're back (in addition to the identically
> named pair in /etc/dnssec-trigger, which does get cleaned up on
> purge).
> Does that not happen for you?

No dnssec-trigger has  been leaving configuration files all over the
place.

I think I've found more of the configuration file installation
locations and fixed them to point to /etc/dnssec-trigger/, but now I'm
encountering the segfault while installing, that caused Axel Beckert to
open this bug so I'm having trouble testing all the fixes.

I did a bit of test driven development, wrote tests for config files in
/etc/, made sure it failed, then fixed the paths, and made sure the
tests pass -- at least when running in autopkgtest.

But I'd like to find the segfault before making another release.

Diane

Bug#919258: Tried purge and reinstall

[BOGENPARADIES Richard]

To make shure the problem is not caused by my installation, I purged 
gnome-games, than restarted the computer and reinstalled gnome-games.


The behaviour of mahjongg did not change at all! Even the best lists are 
there, which I expected to loose through the purge.


Richard

Bug#919343: tdom FTCBFS: hard codes the wrong pkg-config

[Helmut Grohne]

Source: tdom
Version: 0.9.1-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

tdom fails to cross build from source, because and autoconf macro hard
codes the build architecture pkg-config. In principle, one should be
using PKG_PROG_PKG_CONFIG or even PKG_CHECK_MODULES here, however that's
not possible, because tdom confuses the meaning of aclocal.m4 and
acinclude.m4 and therefore we cannot run aclocal. It would be a good
idea to fix that as well. Therefore, the attached patch resorts to a
more bare bones fixes. Please consider applying it.

Helmut
--- tdom-0.9.1.orig/tdom.m4
+++ tdom-0.9.1/tdom.m4
@@ -225,6 +225,7 @@
 #
 
 AC_DEFUN(TDOM_ENABLE_HTML5, [
+AC_PATH_TOOL([PKG_CONFIG],[pkg-config])
 AC_MSG_CHECKING([whether to enable support for HTML5 parsing (using gumbo)])
 AC_ARG_ENABLE(html5,
 AC_HELP_STRING([--enable-html5],
@@ -241,24 +242,22 @@
 HTML5_INCLUDES=""
 if test "$tcl_ok" = "yes" ; then
 # Check if pkg-config is available
-PKGCONFIG=no
-pkg-config --version > /dev/null 2>&1 && PKGCONFIG=yes
-if test "$PKGCONFIG" = no; then
+if test "x$PKG_CONFIG" = x; then
 tcl_ok=no
 	AC_MSG_ERROR([cannot find pkg-config needed for --enable-html5.])
 fi
 fi
 if test "$tcl_ok" = "yes" ; then
-HAVEGUMBO=`pkg-config --exists gumbo && echo "1"`
+HAVEGUMBO=`$PKG_CONFIG --exists gumbo && echo "1"`
 if test "$HAVEGUMBO" = "1" ; then
 AC_MSG_RESULT([yes])
 AC_DEFINE(TDOM_HAVE_GUMBO)
 if test "${TEA_PLATFORM}" = "windows" ; then
-HTML5_LIBS="-Wl,-Bstatic `pkg-config --static --libs gumbo` -Wl,-Bdynamic"
+HTML5_LIBS="-Wl,-Bstatic `$PKG_CONFIG --static --libs gumbo` -Wl,-Bdynamic"
 else
-HTML5_LIBS="`pkg-config --libs gumbo`"
+HTML5_LIBS="`$PKG_CONFIG --libs gumbo`"
 fi
-HTML5_INCLUDES="`pkg-config --cflags gumbo`"
+HTML5_INCLUDES="`$PKG_CONFIG --cflags gumbo`"
 else
 AC_MSG_ERROR([The required lib gumbo not found])
 fi

Bug#919316: bugs.debian.org: DoS with libravatar.cgi and version.cgi

[Don Armstrong]

On Mon, 14 Jan 2019, Julien Cristau wrote:
> the last few days our two bugs web hosts have been struggling. We've
> got apache set up with RLimitNPROC 256, which means once www-data has
> that many processes fork() dies with EAGAIN.
> 
> In the case of version.cgi that means perl forking to run dot, for
> libravatar.cgi it looks like it's either cp or convert.  Either way, the
> failure mode of fork returning EAGAIN is that perl does sleep(5) and
> tries again.  Over and over.  Which means by the time something happens
> the client has long gone, but we're still holding up one of the 256
> nproc slots not doing anything useful for quite a bunch of time.

Is there any reason why we're using RLimitNPROC instead of setting
MaxClients?

There's not much on bugs.debian.org which isn't served by a cgi script,
so there's limited difference between the two for it, and as you can
see, returning EAGAIN isn't particularly useful. [Those two CGI scripts
actually just die() when system() returns non-zero, so it's probably
perl internal system() bits which are sleep() and retrying.]

-- 
Don Armstrong  https://www.donarmstrong.com

Those who begin coercive elimination of dissent soon find themselves
exterminating dissenters. Compulsory unification of opinion achieves
only the unanimity of the graveyard.
 -- Justice Roberts in 319 U.S. 624 (1943)

Bug#919341: libtool-bin: amd64 /usr/bin/libtool is a zero byte file

[Cyril Brulebois]

Cyril Brulebois  (2019-01-15):
> I'm attaching individual patches addressing these, along with a ready to
> use (except for “dch -r”) source debdiff. A quick upload and further
> assessment would likely be a good idea.

Oops, forgot to mention → MR available if that's easier:
  https://salsa.debian.org/mckinstry/libtool/merge_requests/1


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#907072: lintian: verify AppStream metainfo metadata_license matches debian/copyright

[Daniel Kahn Gillmor]

On Mon 2019-01-14 23:50:47 +, Chris Lamb wrote:
> Chris Lamb wrote:
>
>> > The gnupg2 source package version 2.2.9-1 has this mismatch because i
>> > was sloppy.
>> 
>> So, debian/copyright contains:
>> 
>>Files: debian/org.gnupg.scdaemon.metainfo.xml
>>Copyright: 2017 Daniel Kahn Gillmor 
>>Comment: This file is licensed permissively for the sake of AppStream
>>License: CC0-1.0
>> 
>> ... and debian/org.gnupg.scdaemon.metainfo.xml contains:
>> 
>>
>>
>>  org.gnupg.scdaemon
>>  GPL

In unstable, it's  
CC0-1.0, which matches the
declaration in d/copyright.

>>  scdaemon
>>  USB SmartCard Readers
>>  
>>
>>  GnuPG's scdaemon provides access to USB tokens and smartcard
>>  readers that provide cryptographic functionality (e.g. use of
>>  protected secret keys).
>>
>>  
>>[...]
>> 
>> ... which is installed to /usr/share/metainfo via debian/
>> scdaemon.install.
>> 
>> Thus, whilst we can rely on such metadata files existing in /usr/share/
>> metainfo/*.xml (or similar) we don't know which file in the source tree
>> this originated from (and thus it's license).
>> 
>> Ideas?
>
> Gentle ping on this? :)

Sorry, i'm confused by this question.  The source file
debian/org.gnupg.scdaemon.metainfo.xml itself is what shows up in
/usr/share/metainfo/.  this file states that its own license is CC0-1.0,
as does debian/copyright.  What information is missing?

sorry to be dense,

   --dkg

Bug#919341: libtool-bin: amd64 /usr/bin/libtool is a zero byte file

[Cyril Brulebois]

Control: severity -1 grave
Control: tag -1 patch

Cyril Brulebois  (2019-01-15):
> For some reasons, libtool and its manpage (from the libtool-bin binary)
> are “sanitized” in binary-indep, which might explain why it's only
> showing up on the maintainer build which was likely using “-b”.
> 
> > $ dpkg-deb -c libtool-bin_2.4.6-7_amd64.deb
> > -rwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/bin/libtool
> > -rw-r--r-- root/root20 2019-01-12 09:10 
> > ./usr/share/man/man1/libtool.1.gz
> 
> The manpage is a gzipped empty file.

I'm afraid the situation is pretty bad, as an empty executable doesn't
do anything but also produces no errors; so I fear any packages having
been built using this version of libtool-bin on amd64 has likely missed
a step or two without that getting noticed…

Cc-ing debian-release@ & debian-wb-team@ for information.

> At least those points need addressing:
>  1. some sed lines have an extra slash before the repetition specifier.
>  2. the for loop isn't set up to bail out on errors
>  3. libtoolize from bin:libtool which is arch:all is “sanitized”
> in binary-arch; looks like a mixup between both targets given
> the already mentioned libtool (binary and manpage)…
>  4. hardcoding the upstream version in debian/rules looks like a recipe
> for a later regression

I'm attaching individual patches addressing these, along with a ready to
use (except for “dch -r”) source debdiff. A quick upload and further
assessment would likely be a good idea.

Setting up something with autopkgtest might be worth it, if only just to
check a few trivial commands (--help comes to mind).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
From e3c73f4532de8f8f83b242011f536729f4db7b05 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Tue, 15 Jan 2019 03:41:39 +
Subject: [PATCH 1/7] Fix Vcs-* URLs.

---
 debian/changelog | 6 ++
 debian/control   | 4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index ace7740..4266654 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libtool (2.4.6-8) UNRELEASED; urgency=medium
+
+  * Fix Vcs-* URLs.
+
+ -- Cyril Brulebois   Tue, 15 Jan 2019 03:41:15 +
+
 libtool (2.4.6-7) unstable; urgency=medium
 
   * Standards-Version: 4.3.0
diff --git a/debian/control b/debian/control
index c2cfefc..0d92424 100644
--- a/debian/control
+++ b/debian/control
@@ -17,8 +17,8 @@ Maintainer: Alastair McKinstry 
 Standards-Version: 4.3.0
 Rules-Requires-Root: no
 Homepage: https://www.gnu.org/software/libtool/
-Vcs-Browser: https://salsa.debian.org:/mckinstry/libtool.git
-Vcs-Git: https://salsa.debian.org:/mckinstry/libtool.git
+Vcs-Browser: https://salsa.debian.org/mckinstry/libtool.git
+Vcs-Git: https://salsa.debian.org/mckinstry/libtool.git
 
 Package: libtool
 Architecture: all
-- 
2.11.0

From 3849d58d6013a1ae557647335b215a6cfe62d725 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Tue, 15 Jan 2019 03:42:58 +
Subject: [PATCH 2/7] Fix sed syntax errors. Closes: #919341

These errors lead to empty libtool executable and manpage. With thanks
to James McCoy for reporting.
---
 debian/changelog | 2 ++
 debian/rules | 8 
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 4266654..da983ae 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,8 @@
 libtool (2.4.6-8) UNRELEASED; urgency=medium
 
   * Fix Vcs-* URLs.
+  * Fix sed syntax errors leading to empty libtool executable and
+manpage, with thanks to James McCoy for reporting. Closes: #919341
 
  -- Cyril Brulebois   Tue, 15 Jan 2019 03:41:15 +
 
diff --git a/debian/rules b/debian/rules
index 004285f..e502a2b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -163,8 +163,8 @@ binary-indep: build-indep install
 	for f in \
 		debian/libtool-bin/usr/share/man/man1/libtool.1 \
 		debian/libtool-bin/usr/bin/libtool ; do cat $$f | \
-			sed -e 's%/usr/bin/grep%/bin/grep%/g' | \
-			sed -e 's%/usr/bin/sed%/bin/sed%/g' | \
+			sed -e 's%/usr/bin/grep%/bin/grep%g' | \
+			sed -e 's%/usr/bin/sed%/bin/sed%g' | \
 			sed -e 's%/usr/bin/dd%/bin/dd%g' | \
 			sed -e 's%${CURDIR}%/build/libtool-2.4.6%g' | \
 			> debian/tmpff ; \
@@ -193,8 +193,8 @@ binary-arch: build-arch install
 	for f in \
 		debian/libtool/usr/bin/libtoolize ; do \
 		cat $$f | \
-			sed -e 's%/usr/bin/grep%/bin/grep%/g' | \
-			sed -e 's%/usr/bin/sed%/bin/sed%/g' | \
+			sed -e 's%/usr/bin/grep%/bin/grep%g' | \
+			sed -e 's%/usr/bin/sed%/bin/sed%g' | \
 			sed -e 's%/usr/bin/dd%/bin/dd%g' | \
 			sed -e 's%${CURDIR}%/build/libtool-2.4.6%g' | \
 			> debian/tmpff ; \
-- 
2.11.0

From 669ed2faf2510b3931cf4a37ca53ba15a8c0598f Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Tue, 15 Jan 2019 03:46:37 +
Subject: [PATCH 3/7] Fix sanitation of libtool vs. libtoolize.

The former 

Bug#919342: darktable: Segfault when moving drawn mask

[Charlie Hagedorn]

Package: darktable
Version: 2.6.0-1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Upgraded via apt-get dist-upgrade this morning. Darktable worked great prior to 
the upgrade, and has for years.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Opened up an image, did some edits to an image, and then created my first drawn 
mask with the upgraded version. It wasn't quite in the right place, so I 
clicked-and-dragged in the middle of the image. The mask outline disappeared, I 
may have clicked in a few spots/faffed a little bit, and darktable crashed.

The image was missing from the lighttable when I restarted darktable, so I 
reapplied the same edits, switched back to the lighttable in order to save my 
progress, drew/moved a mask and got approximately the same behavior, again with 
a segfault. 

In investigating, I have noted the following:

1. That mask is now saved, and if I call it up from the list of masks, 
darktable crashes. I don't know enough about library.db to call it up and 
submit it. If a developer with enough darktable-fu can tell me how, I'll add it 
to this bug.

2. Moving any drawn mask on any image I have tried so far yields an 
instantaneous jump of the mask down and right by ~500-1000 pixels. Dragging is 
then successful, and darktable does not crash.  In ~5 tries, I have not been 
able to generate another segfaulting mask.

3. When segfaulting, Darktable consistently stores

"
this is darktable 2.6.0 reporting a segfault:

warning: Currently logging to /tmp/darktable_bt_5AAEVZ.txt.  Turn the logging 
off and on to make the new setting effective.
/usr/share/darktable/gdb_commands:2: Error in sourced command file:
No stack.
"
to a logfile in /tmp. Internet search suggests that I'd get more debug output 
with darktable-dbg, but as it is not in Debian testing, I don't want to install 
it.


   * What was the outcome of this action?

Consistent segfaults with one drawn mask, unexpected behavior with other masks.

   * What outcome did you expect instead?

The ability to move a mask at will. This is a key feature, which may affect 
every module.


Thank you for maintaining Darktable!


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (200, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-3-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)
LSM: AppArmor: enabled

Versions of packages darktable depends on:
ii  libc62.28-5
ii  libcairo21.16.0-2
ii  libcolord-gtk1   0.1.26-2
ii  libcolord2   1.4.3-3+b1
ii  libcups2 2.2.10-3
ii  libcurl3-gnutls  7.62.0-1
ii  libexiv2-14  0.25-4
ii  libflickcurl01.26-4
ii  libgcc1  1:8.2.0-14
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.2-3
ii  libgomp1 8.2.0-14
ii  libgphoto2-6 2.5.22-1
ii  libgphoto2-port122.5.22-1
ii  libgraphicsmagick-q16-3  1.4~hg15873-1+b1
ii  libgtk-3-0   3.24.2-3
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjs-prototype  1.7.1-3
ii  libjs-scriptaculous  1.9.0-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  liblcms2-2   2.9-3
ii  liblensfun1  0.3.2-4
ii  liblua5.3-0  5.3.3-1.1
ii  libopenexr23 2.2.1-4
ii  libopenjp2-7 2.3.0-1.1
ii  libosmgpsmap-1.0-1   1.1.0-5
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpng16-16  1.6.36-2
ii  libpugixml1v51.9-2
ii  librsvg2-2   2.44.10-1
ii  libsecret-1-00.18.7-1
ii  libsoup2.4-1 2.64.2-2
ii  libsqlite3-0 3.26.0+fossilbc891ac6b-1
ii  libstdc++6   8.2.0-14
ii  libtiff5 4.0.10-3
ii  libwebp6 0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  zlib1g   1:1.2.11.dfsg-1

darktable recommends no packages.

darktable suggests no packages.

-- no debconf information

Bug#825383: /usr/share/hplip/doctor.py: hp-doctor will not accept sudo password and there is no root account

[Brendon Higgins]

On Saturday, 5 January 2019 1:49:47 PM EST Brian Potkin wrote:
> On Fri 04 Jan 2019 at 11:58:53 -0500, Brendon Higgins wrote:
> > hp-plugin, too. Do you have your upstream bug number handy? I'd like to
> > follow progress (if any).
> 
> It is referenced as a duplicate in the forwarded bug report.

Ah, yes. Apologies, apparently I was blind that day. XD

> Brendon - it is always useful to know which device make and model is
> being used.

In my case it's an HP Color LaserJet Pro MFP M277dw.

Best,
Brendon

Bug#919341: libtool-bin: amd64 /usr/bin/libtool is a zero byte file

[Cyril Brulebois]

Hi James,

James McCoy  (2019-01-14):
> The amd64 package, the only one not built on a buildd, contains a
> zero-byte /usr/bin/libtool.  This makes it completely non-functional.

For some reasons, libtool and its manpage (from the libtool-bin binary)
are “sanitized” in binary-indep, which might explain why it's only
showing up on the maintainer build which was likely using “-b”.

> $ dpkg-deb -c libtool-bin_2.4.6-7_amd64.deb
> -rwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/bin/libtool
> -rw-r--r-- root/root20 2019-01-12 09:10 
> ./usr/share/man/man1/libtool.1.gz

The manpage is a gzipped empty file.

Looking at debian/rules, this cannot possibly work… which is confirmed
by an amd64 build inside a (non-minimal) sid devel schroot, with
“dpkg-buildpackage -b”:
| # Sanitize /usr-merge path builds
| for f in \
|   debian/libtool-bin/usr/share/man/man1/libtool.1 \
|   debian/libtool-bin/usr/bin/libtool ; do cat $f | \
|   sed -e 's%/usr/bin/grep%/bin/grep%/g' | \
|   sed -e 's%/usr/bin/sed%/bin/sed%/g' | \
|   sed -e 's%/usr/bin/dd%/bin/dd%g' | \
|   sed -e 's%/tmp/libtool-2.4.6%/build/libtool-2.4.6%g' | \
|   > debian/tmpff ; \
|   mv debian/tmpff $f ; \
|   done
| sed: -e expression #1, char 25: unknown option to `s'
| sed: -e expression #1, char 27: unknown option to `s'
| sed: -e expression #1, char 27: unknown option to `s'
| sed: -e expression #1, char 25: unknown option to `s'
[…]
| # Sanitize /usr-merge path builds
| for f in \
|   debian/libtool/usr/bin/libtoolize ; do \
|   cat $f | \
|   sed -e 's%/usr/bin/grep%/bin/grep%/g' | \
|   sed -e 's%/usr/bin/sed%/bin/sed%/g' | \
|   sed -e 's%/usr/bin/dd%/bin/dd%g' | \
|   sed -e 's%/tmp/libtool-2.4.6%/build/libtool-2.4.6%g' | \
|   > debian/tmpff ; \
|   mv debian/tmpff $f ; \
|   done
| sed: -e expression #1, char 25: unknown option to `s'
| sed: -e expression #1, char 27: unknown option to `s'

At least those points need addressing:
 1. some sed lines have an extra slash before the repetition specifier.
 2. the for loop isn't set up to bail out on errors
 3. libtoolize from bin:libtool which is arch:all is “sanitized”
in binary-arch; looks like a mixup between both targets given
the already mentioned libtool (binary and manpage)…
 4. hardcoding the upstream version in debian/rules looks like a recipe
for a later regression


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#903201: cinnamon: CVE-2018-13054: privilege escalation in cinnamon-settings-users.py GUI

[Andres Salomon]

On Mon, Jan 14, 2019 at 5:39 PM, Andres Salomon  
wrote


It's not a critical bug (cinnamon-settings-users continues running), 
it just can't update
the file.  That needs to be fixed upstream if it's not already, by 
changing ownership or
deleting the old file before dropping privileges.  I've attached a 
patch that deletes the

old file.


I realized that os.remove throws an exception if the file isn't there, 
which isn't what we
want. Here's an updated patch.  It works with .face owned by root, 
owned by the proper

user, or when it doesn't exist at all.
--- /usr/share/cinnamon/cinnamon-settings-users/cinnamon-settings-users.py.orig	2019-01-14 17:24:37.799003654 -0800
+++ /usr/share/cinnamon/cinnamon-settings-users/cinnamon-settings-users.py	2019-01-14 18:41:39.855137769 -0800
@@ -675,6 +675,10 @@
 image.thumbnail((96, 96), Image.ANTIALIAS)
 face_path = os.path.join(user.get_home_dir(), ".face")
 try:
+try:
+os.remove(face_path)
+except:
+pass
 priv_helper.drop_privs(user)
 image.save(face_path, "png")
 finally:
@@ -704,9 +708,14 @@
 user = model[treeiter][INDEX_USER_OBJECT]
 user.set_icon_file(path)
 self.face_image.set_from_file(path)
+face_path = os.path.join(user.get_home_dir(), ".face")
 try:
+try:
+os.remove(face_path)
+except:
+pass
 priv_helper.drop_privs(user)
-shutil.copy(path, os.path.join(user.get_home_dir(), ".face"))
+shutil.copy(path, face_path)
 finally:
 priv_helper.restore_privs()
 model.set_value(treeiter, INDEX_USER_PICTURE, GdkPixbuf.Pixbuf.new_from_file_at_size(path, 48, 48))

Bug#919341: libtool-bin: amd64 /usr/bin/libtool is a zero byte file

[James McCoy]

Package: libtool-bin
Version: 2.4.6-7
Severity: serious
File: /usr/bin/libtool

The amd64 package, the only one not built on a buildd, contains a
zero-byte /usr/bin/libtool.  This makes it completely non-functional.

$ dpkg-deb -c libtool-bin_2.4.6-7_amd64.deb
drwxr-xr-x root/root 0 2019-01-12 09:10 ./
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/bin/
-rwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/bin/libtool
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/share/
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/share/doc/
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/share/doc/libtool-bin/
-rw-r--r-- root/root  9329 2019-01-12 09:10 
./usr/share/doc/libtool-bin/changelog.Debian.gz
-rw-r--r-- root/root342562 2015-02-15 12:15 
./usr/share/doc/libtool-bin/changelog.gz
-rw-r--r-- root/root  1976 2019-01-12 09:10 
./usr/share/doc/libtool-bin/copyright
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/share/man/
drwxr-xr-x root/root 0 2019-01-12 09:10 ./usr/share/man/man1/
-rw-r--r-- root/root20 2019-01-12 09:10 
./usr/share/man/man1/libtool.1.gz

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

Kernel: Linux 4.19.0-1-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)
LSM: AppArmor: enabled

Versions of packages libtool-bin depends on:
ii  libtool  2.4.6-7

libtool-bin recommends no packages.

libtool-bin suggests no packages.

-- no debconf information

Bug#919340: fenix-plugins: FTBFS: configure.ac:36: error: possibly undefined macro: AC_CHECK_FT2

[Andreas Beckmann]

Source: fenix-plugins
Version: 0.0.20070803-7
Severity: serious
Tags: sid buster
Justification: fails to build from source (but built successfully in the past)

Hi,

fenix-plugins cannot be rebuilt any longer in a current pbuilder sid
environment:

 debian/rules build
dh build --with autoreconf
   dh_update_autotools_config
   dh_autoreconf
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:14: installing './compile'
configure.ac:11: installing './missing'
Makefile.am: installing './depcomp'
libtoolize: putting auxiliary files in '.'.
[...]
configure.ac:11: installing './missing'
Makefile.am: installing './depcomp'
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:36: error: possibly undefined macro: AC_CHECK_FT2
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
dh_autoreconf: autoreconf -f -i agua-1.0 exec-0.4a fgfx-1.0 fire-1.0 fsock-1.0 
image-1.0 mixer-1.0 mpeg-1.0 net-1.0 tcpsock-2.0 ttf-1.0 returned exit code 1
make: *** [debian/rules:31: build] Error 2


Cheers,

Andreas


fenix-plugins_0.0.20070803-7.build.gz
Description: application/gzip

Bug#907337: WIP packaging VCS

[Antoine Beaupré]

Control: tags -1 +pending +patch

On 2018-08-26 15:27:49, David Bremner wrote:
> In case someone is interested, there is some beginnings of packaging at
>
>https://salsa.debian.org/bremner/dateparser.git
>
> it is not currently in a state suitable for the archive, but it might be
> a place to start.
>
> Or you could run debmake yourself.

I needed this package as a new dependency for undertime, so I started
from your package and fixed up some stuff. I published the source
package here:

https://salsa.debian.org/python-team/modules/dateparser

... and uploaded the result to NEW.

My main problem was dealing with the test suite, which was failing
at build time. I disabled the build-time test suite and moved it to
autopkgtest, where it *also* was failing. Unfortunately, the test suite
actually fails with the dependency versions that are shipped in Debian
(they are too new!). I reported this a bug upstream and fixed the test
suite to download the dependencies on the fly...

https://github.com/scrapinghub/dateparser/issues/489

It's clearly sub-par: autopkgtest should normally be ran against the
*installed* package, not the source code. But that's the best I could do
while still running the test suite at all. Eventually, the unit tests
could be ran against the dependencies shipped by Debian, once upstream
gets their stuff together, and some smoke tests could be added to
autopkgtest.

I haven't audited or reviewed the source code. At 57k SLOC, it seems
unreasonable to expect that so I just trust that the git repository is
not hostile, unfortunately.

A.

-- 
You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write operating
systems or applications without security holes, can then turn around
and suddenly write virtualization layers without security holes.
- Theo de Raadt

Bug#919339: radicale: uwsgi config tries chdir to non-existing directory

[Jonas Smedegaard]

Quoting James Valleroy (2019-01-15 02:18:37)
> Package: radicale
> Version: 2.1.11-2
> Severity: normal
> 
> I enabled the radicale config for uwsgi, and then restarted uwsgi,
> which failed to start.
> 
> # cat /var/log/uwsgi/app/radicale.log 
> Mon Jan 14 20:03:06 2019 - *** Starting uWSGI 2.0.17.1-debian (64bit) on [Mon 
> Jan 14 20:03:06 2019] ***
> Mon Jan 14 20:03:06 2019 - compiled with version: 8.2.0 on 27 December 2018 
> 16:37:18
> Mon Jan 14 20:03:06 2019 - os: Linux-4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 
> (2018-12-22)
> Mon Jan 14 20:03:06 2019 - nodename: compbook
> Mon Jan 14 20:03:06 2019 - machine: x86_64
> Mon Jan 14 20:03:06 2019 - clock source: unix
> Mon Jan 14 20:03:06 2019 - pcre jit disabled
> Mon Jan 14 20:03:06 2019 - detected number of CPU cores: 4
> Mon Jan 14 20:03:06 2019 - current working directory: /
> Mon Jan 14 20:03:06 2019 - writing pidfile to /run/uwsgi/app/radicale/pid
> Mon Jan 14 20:03:06 2019 - detected binary path: /usr/bin/uwsgi-core
> Mon Jan 14 20:03:06 2019 - chdir() to /var/lib/radicale/collections
> Mon Jan 14 20:03:06 2019 - chdir(): No such file or directory [core/uwsgi.c 
> line 2631]
> 
> 
> The uwsgi config shipped in radicale 2.x package tries to chdir to
> /var/lib/radicale/collections.
> 
> There is a step to create /var/lib/radicale, but I think it needs to
> be moved before the chdir, and to also create the collections
> directory.

Ohh, good catch!

I remember adjusting that chdir was one of the last adjustments I did - 
but clearly was too focused on handling migrations carefully and forgot 
to take new installations into account.

New fixed release should be on its way now...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#704089: tzdata config script prevents non-interactive (re)configuration

[Adam Bolte]

Package: tzdata
Version: 2018i-0+deb9u1
Followup-For: Bug #704089

Dear Maintainer,

This is still a problem 4 years later, and I unexpectedly found myself
spending time to track it down when doing configuration
management. Can we please get the above patch applied *before* the
Buster soft-freeze on 2019-02-12 (just over a month away)?

It seems the only work-around for now (aside from patching
tzdata.config before executing dpkg-reconfigure in non-interactive
mode) is to delete /etc/timezone first. As discussed in #516755, that
has the effect of causing a race condition that can lead to things
like log files showing wrong timestamps. Not great.

Thanks,
Adam

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (400, 
'proposed-updates'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en:ja 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0]  1.5.61

tzdata recommends no packages.

tzdata suggests no packages.

-- debconf-show failed


signature.asc
Description: PGP signature

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

On 14 January 2019 at 20:45, Evan Miller wrote:
| Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared from 
GitHub. I don’t know if the original reporter intended to close them, or what.

That is ... weird.
 
| I have an email copy of #34 but do not have access to the PoC files. So 
without the cooperation of the reporter (Zhao Liang, Huawei Weiran Labs) my 
ability to research will be limited.

Understood.

Moritz: Any idea?  Will the CVE end of things have copies?

Dirk
 
| Evan
| 
| > On Jan 14, 2019, at 19:22, Dirk Eddelbuettel  wrote:
| > 
| > 
| > Hi Evan,
| > 
| > On 14 January 2019 at 19:03, Evan Miller wrote:
| > | Hi Dirk,
| > | 
| > | You are correct - these are issues with the underlying C library, the 
GitHub issues you referenced. I have not researched them specifically, but I 
recently fixed two issues (#36 and #37) that are possibly related:
| > | 
| > | https://github.com/evanmiller/libxls/issues/36 

| > | https://github.com/evanmiller/libxls/issues/37 

| > | 
| > | I will look into #34 and #35 when I get a chance.
| > 
| > Thanks for the prompt follow-up.  Please keep us posted and abreast of any 
progress.
| > 
| > Dirk
| > 
| > | Evan
| > | 
| > | > On Jan 14, 2019, at 17:56, Dirk Eddelbuettel  wrote:
| > | > 
| > | > 
| > | > Hi Evan,
| > | > 
| > | > On 14 January 2019 at 23:32, Moritz Muehlenhoff wrote:
| > | > | Package: r-cran-readxl
| > | > | Severity: important
| > | > | Tags: security
| > | > | 
| > | > | These two libxls issues should affect r-cran-readxl:
| > | > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20450
| > | > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20452
| > | > 
| > | > These are both file as #34 and #35 at your GitHub repo, but I did not 
see any
| > 
| > s/file/filed/  -- sorry
| > 
| > | > follow-up.  I presume this is similar to the last time that the issue 
really
| > | > stems from the underlying C parser library?  Any idea how long it may 
take
| > | > until we have a fix?
| > | > 
| > | > Courtesy to Jenny who via readxl 'upstream' is the real maintainer for
| > | > the
| > 
| > s/Courtesy/Courtesy CC/ -- sorry
| > 
| > | > CRAN package I mostly just wrap up for Debian.
| > | > 
| > | > Best,  Dirk
| > | > 
| > | > | Cheers,
| > | > | Moritz
| > | > 
| > | > -- 
| > | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| > | 
| > 
| > -- 
| > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#903201: cinnamon: CVE-2018-13054: privilege escalation in cinnamon-settings-users.py GUI

[Andres Salomon]

Hi,

Is there a reason why this hasn't been fixed in stretch yet?  The 
upstream commit is here:


https://github.com/linuxmint/Cinnamon/commit/66e54f43f179fdf041a3e5232178a9910963cfb5

https://github.com/linuxmint/Cinnamon/commit/66e54f43f179fdf041a3e5232178a9910963cfb5.patch

It applies to the version in stretch, and I've tested it.  Here's the 
before:

dilinger@e7470:~$ ls -l .face
-rw-r--r-- 1 root root 9379 Jan 14 17:14 .face

After:
dilinger@e7470:~$ ls -lh .face
-rw-r--r-- 1 dilinger dilinger 2.6K Jan 14 17:19 .face

There is, however, a problem where the root-owned .face cannot be 
overwritten once the

new code drops privileges:

Traceback (most recent call last):
 File 
"/usr/share/cinnamon/cinnamon-settings-users/cinnamon-settings-users.py", 
line 709, in _on_face_menuitem_activated

   shutil.copy(path, os.path.join(user.get_home_dir(), ".face"))
 File "/usr/lib/python2.7/shutil.py", line 119, in copy
   copyfile(src, dst)
 File "/usr/lib/python2.7/shutil.py", line 83, in copyfile
   with open(dst, 'wb') as fdst:
IOError: [Errno 13] Permission denied: '/home/dilinger/.face'

It's not a critical bug (cinnamon-settings-users continues running), it 
just can't update
the file.  That needs to be fixed upstream if it's not already, by 
changing ownership or
deleting the old file before dropping privileges.  I've attached a 
patch that deletes the

old file.

Thanks,
Andres
--- /usr/share/cinnamon/cinnamon-settings-users/cinnamon-settings-users.py.orig	2019-01-14 17:24:37.799003654 -0800
+++ /usr/share/cinnamon/cinnamon-settings-users/cinnamon-settings-users.py	2019-01-14 17:38:06.248595816 -0800
@@ -675,6 +675,7 @@
 image.thumbnail((96, 96), Image.ANTIALIAS)
 face_path = os.path.join(user.get_home_dir(), ".face")
 try:
+os.remove(face_path)
 priv_helper.drop_privs(user)
 image.save(face_path, "png")
 finally:
@@ -704,9 +705,11 @@
 user = model[treeiter][INDEX_USER_OBJECT]
 user.set_icon_file(path)
 self.face_image.set_from_file(path)
+face_path = os.path.join(user.get_home_dir(), ".face")
 try:
+os.remove(face_path)
 priv_helper.drop_privs(user)
-shutil.copy(path, os.path.join(user.get_home_dir(), ".face"))
+shutil.copy(path, face_path)
 finally:
 priv_helper.restore_privs()
 model.set_value(treeiter, INDEX_USER_PICTURE, GdkPixbuf.Pixbuf.new_from_file_at_size(path, 48, 48))

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared from 
GitHub. I don’t know if the original reporter intended to close them, or what.

I have an email copy of #34 but do not have access to the PoC files. So without 
the cooperation of the reporter (Zhao Liang, Huawei Weiran Labs) my ability to 
research will be limited.

Evan

> On Jan 14, 2019, at 19:22, Dirk Eddelbuettel  wrote:
> 
> 
> Hi Evan,
> 
> On 14 January 2019 at 19:03, Evan Miller wrote:
> | Hi Dirk,
> | 
> | You are correct - these are issues with the underlying C library, the 
> GitHub issues you referenced. I have not researched them specifically, but I 
> recently fixed two issues (#36 and #37) that are possibly related:
> | 
> | https://github.com/evanmiller/libxls/issues/36 
> 
> | https://github.com/evanmiller/libxls/issues/37 
> 
> | 
> | I will look into #34 and #35 when I get a chance.
> 
> Thanks for the prompt follow-up.  Please keep us posted and abreast of any 
> progress.
> 
> Dirk
> 
> | Evan
> | 
> | > On Jan 14, 2019, at 17:56, Dirk Eddelbuettel  wrote:
> | > 
> | > 
> | > Hi Evan,
> | > 
> | > On 14 January 2019 at 23:32, Moritz Muehlenhoff wrote:
> | > | Package: r-cran-readxl
> | > | Severity: important
> | > | Tags: security
> | > | 
> | > | These two libxls issues should affect r-cran-readxl:
> | > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20450
> | > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20452
> | > 
> | > These are both file as #34 and #35 at your GitHub repo, but I did not see 
> any
> 
> s/file/filed/  -- sorry
> 
> | > follow-up.  I presume this is similar to the last time that the issue 
> really
> | > stems from the underlying C parser library?  Any idea how long it may take
> | > until we have a fix?
> | > 
> | > Courtesy to Jenny who via readxl 'upstream' is the real maintainer for
> | > the
> 
> s/Courtesy/Courtesy CC/ -- sorry
> 
> | > CRAN package I mostly just wrap up for Debian.
> | > 
> | > Best,  Dirk
> | > 
> | > | Cheers,
> | > | Moritz
> | > 
> | > -- 
> | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> | 
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919339: radicale: uwsgi config tries chdir to non-existing directory

[James Valleroy]

Package: radicale
Version: 2.1.11-2
Severity: normal

I enabled the radicale config for uwsgi, and then restarted uwsgi,
which failed to start.

# cat /var/log/uwsgi/app/radicale.log 
Mon Jan 14 20:03:06 2019 - *** Starting uWSGI 2.0.17.1-debian (64bit) on [Mon 
Jan 14 20:03:06 2019] ***
Mon Jan 14 20:03:06 2019 - compiled with version: 8.2.0 on 27 December 2018 
16:37:18
Mon Jan 14 20:03:06 2019 - os: Linux-4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 
(2018-12-22)
Mon Jan 14 20:03:06 2019 - nodename: compbook
Mon Jan 14 20:03:06 2019 - machine: x86_64
Mon Jan 14 20:03:06 2019 - clock source: unix
Mon Jan 14 20:03:06 2019 - pcre jit disabled
Mon Jan 14 20:03:06 2019 - detected number of CPU cores: 4
Mon Jan 14 20:03:06 2019 - current working directory: /
Mon Jan 14 20:03:06 2019 - writing pidfile to /run/uwsgi/app/radicale/pid
Mon Jan 14 20:03:06 2019 - detected binary path: /usr/bin/uwsgi-core
Mon Jan 14 20:03:06 2019 - chdir() to /var/lib/radicale/collections
Mon Jan 14 20:03:06 2019 - chdir(): No such file or directory [core/uwsgi.c 
line 2631]


The uwsgi config shipped in radicale 2.x package tries to chdir to
/var/lib/radicale/collections.

There is a step to create /var/lib/radicale, but I think it needs to
be moved before the chdir, and to also create the collections
directory.


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

Kernel: Linux 4.19.0-1-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)
LSM: AppArmor: enabled

Versions of packages radicale depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  lsb-base 10.2018112800
ii  python3  3.7.1-3
ii  python3-radicale 2.1.11-2

Versions of packages radicale recommends:
ii  ssl-cert  1.0.39

Versions of packages radicale suggests:
pn  apache2 
pn  apache2-utils   
pn  libapache2-mod-proxy-uwsgi  
pn  python3-bcrypt  
pn  python3-passlib 
ii  uwsgi   2.0.17.1-11

-- no debconf information

Bug#879084: 879084: more info, and three possible fixes

[Raphaël Halimi]

Hi,

I stumbled upon this bug with another plugin (check_rpc). I don't think
it's related to #863399 at all.

After enabling debug in icinga.cfg, the error message states:

Can't locate utils.pm in @INC (you may need to install the utils module)
(@INC contains: /usr/lib/icinga [...]).

The problem is that the plugin looks for a library (utils.pm) which is
specific to Nagios plugins. Icinga in Debian defaults to use an embedded
Perl interpreter (ePN - Embedded Perl Nagios), and the required library
file is indeed present in the package monitoring-plugins-common;
unfortunately, it seems that during the Nagios -> Icinga fork, the @INC
path used by ePN has been changed from /usr/lib/nagios to
/usr/lib/icinga, whereas the monitoring-plugins-common still provides
utils.pm in the original /usr/lib/nagios directory.

Interestingly, when check_rpc (which does use FindBin) is run from the
command-line, it works fine, though. I'm not a PerlMonk, but by
comparing ePN's @INC and the system's default @INC (perl -e "print
\"@INC\""), I guess in that case, the plugin is happy to find one of
/usr/share/perl/5.24.1/Module/CoreList/Utils.pm or
/usr/share/perl/5.24.1/ExtUtils/Constant/Utils.pm (those are the only
ones on my system that are located in a directory not included in ePN's
@INC)n and don't actually require any function from monitoring-plugins'
utils.pm.

It seems that quite a bunch of plugins should suffer from this problem;
a quick grep on "use utils" in /usr/lib/nagios/plugins/ gives:

/usr/lib/nagios/plugins/check_breeze
/usr/lib/nagios/plugins/check_disk_smb
/usr/lib/nagios/plugins/check_file_age
/usr/lib/nagios/plugins/check_flexlm
/usr/lib/nagios/plugins/check_ifoperstatus
/usr/lib/nagios/plugins/check_ifstatus
/usr/lib/nagios/plugins/check_ircd
/usr/lib/nagios/plugins/check_mailq
/usr/lib/nagios/plugins/check_rpc
/usr/lib/nagios/plugins/check_wave

To fix this bug without modifying every plugin, there are several solutions:

The one which seems the cleanest would be to modify Icinga's ePN source
code to add /usr/lib/nagios in @INC (since that's where utils.pm is
actually provided by monitoring-plugins-common) or even replace
/usr/lib/icinga, since this directory contains only a single file
"p1.pl", whose path is (correctly) set in /etc/icinga/icinga.cfg. I
don't know what /usr/lib/icinga is used for, since on my system it only
contains p1.pl.

Another solution would be to disable ePN completely, which would make
Icinga use the native Perl installation from the system. It's disabled
by default in upstream, but enabled by default in the Debian package by
the patch "debian/patches/52_icinga.cfg-debianize.patch"; the change was
introduced in 1.5.0-2 (according to the changelog), but the git log for
dab43df doesn't say anything more about the reason of that choice.

This would mean that the bug was present since at least Wheezy (which
has Icinga 1.7.1-7). I'm not sure how it went unnoticed for so long,
maybe people just enable debug, see what's wrong, quickly fix it (like
OP, or globally, see below) and go on without reporting it; or maybe
they just deem the impacted plugins as bugged and give up on them
completely (it's true that, if one doesn't enable debug, the web
interface doesn't say much apart of something like "the plugin died with
an error").

Anyway, note that the comment about ePN in /etc/icinga/icinga.cfg is
quite scary:

# This option is intentionally disabled by default, because embedded
# perl can cause memory leaks and make Icinga unstable if not properly
# used.
# Only enable this setting when you really know what you are doing!

On the other hand, this scary comment in not present in the equivalent
configuration file in Nagios 3 (in fact, I'm new to Icinga, because I
migrated an old Nagios installation on Jessie to a new Stretch box; I
don't have the required time right now to learn Icinga 2, so I went the
lazy way with Icinga 1).

I guess this comment dates from the times when Icinga was freshly
forked, and that ePN's stability has hugely since then; or maybe the
performance loss would be *really* huge without it; moreover, for the
years I used Nagios, this host never suffered any noticeable memory
leak, so I decided to trust the package maintainers' choice and let ePN
enabled, which brings us to the third solution: the quick and dirty
workaround I used on my system to make the plugin(s) work, which is to
simply symlink utils.pm in /usr/lib/icinga, so that ePN would find it in
its @INC.

Solution 1 may have unforeseen consequences, especially if you decide to
replace /usr/lib/icinga in @INC by /usr/lib/nagios; solution 2 may
result in a performance loss (maybe a huge one on big installations), so
the third one, which may look like a quick and dirty workaround, is in
fact the less intrusive; and since icinga-core depends on icinga-common,
which in turn depends on monitoring-plugins-basic, it would be safe for
one of those two packages to provide such a symlink.

In any case, apart of a fix in 

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Celejar]

On Mon, 14 Jan 2019 16:27:18 -0800
Jonathan Nieder  wrote:

> # missing Depends
> severity 919296 serious
> quit
> 
> Celejar wrote:
> >> Celejar wrote:
> 
> >>> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per
> >>> README.debian) fails with:
> >>>
> >>> warning: git-daemon: unable to open supervise/ok: file does not exist
> [...]
> > ii  runit  2.1.2-22 amd64system-wide service supervision
> > ii  runit-helper   2.7.3all  dh-sysuser implementation 
> > detail
> > un  runit-init   (no description available)
> > un  runit-systemd(no description available)
> > un  runit-sysv   (no description available)
> >
> > I don't install recommends by default, and I do run into trouble
> > sometimes because of that ;). Should I try installing one of them to see
> > if that solves the problem?
> 
> Yes, please.  Please install runit-systemd and then run
> "dpkg-reconfigure git-daemon-run".

Okay, I've installed runit-systemd:

~# dpkg-reconfigure git-daemon-run
Service git-daemon already added.
warning: git-daemon: unable to open supervise/ok: file does not exist

> If I'm lucky then that will get it working.  I'll try to reproduce it
> here and set the right dependencies.

Sorry :/

Again, thanks for the help. I'm likely doing something basic wrong, so
thanks for bearing with me.

> It appears that runit-sysv depends on sysvinit-core, which conflicts
> with systemd-sysv, so adding a Depends by git-daemon-run on
> 'runit-init | runit-systemd | runit-sysv' should do the trick.  I'll
> experiment.
> 
> Thanks,
> Jonathan


Celejar

Bug#919337: RM: jd -- ROM; dead upstream, not work (crash) and fork is coming

[Hideki Yamane]

package: ftp.debian.org
severity: wishlist

Hi,

 Please remove jd package that I maintain.
 
 - It doesn't work now and upstream is no longer maintained
 - Fork project is coming [1], I'll package it (They intend to change the name
   but not decide yet).

 [1] https://github.com/yama-natuki/JD/issues/15 (in Japanese)


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp
 http://wiki.debian.org/HidekiYamane

Bug#919338: postgresql-11: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: postgresql-11
Version: 11.1-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for postgresql-11's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


postgresql-11_11.1-2_pt.po.gz
Description: application/gzip

Bug#919138: wpasupplicant: Fails to connect to some Wifi networks on version 2:2.7-3

[Different55]

On Monday, January 14, 2019 10:37 AM, Ben Greear  
wrote:

> What is the model number of your home AP?
>
> Thanks,
> Ben

It is a Comtrend VR-3033

Bug#919336: dump1090-mutability: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: dump1090-mutability
Version: 1.15_20180310.4a16df3+dfsg-5
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for dump1090-mutability's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


dump1090-mutability_1.15_20180310.4a16df3+dfsg-5_pt.po.gz
Description: application/gzip

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Jonathan Nieder]

# missing Depends
severity 919296 serious
quit

Celejar wrote:
>> Celejar wrote:

>>> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per
>>> README.debian) fails with:
>>>
>>> warning: git-daemon: unable to open supervise/ok: file does not exist
[...]
> ii  runit  2.1.2-22 amd64system-wide service supervision
> ii  runit-helper   2.7.3all  dh-sysuser implementation detail
> un  runit-init   (no description available)
> un  runit-systemd(no description available)
> un  runit-sysv   (no description available)
>
> I don't install recommends by default, and I do run into trouble
> sometimes because of that ;). Should I try installing one of them to see
> if that solves the problem?

Yes, please.  Please install runit-systemd and then run
"dpkg-reconfigure git-daemon-run".

If I'm lucky then that will get it working.  I'll try to reproduce it
here and set the right dependencies.

It appears that runit-sysv depends on sysvinit-core, which conflicts
with systemd-sysv, so adding a Depends by git-daemon-run on
'runit-init | runit-systemd | runit-sysv' should do the trick.  I'll
experiment.

Thanks,
Jonathan

Bug#904152: Request: Rename "ubuntu-archive-keyring" package to "ubuntu-keyring" for consistency with Ubuntu

[Jeremy Bicha]

Hideki,

I believe you need a transitional package so that people with the old
package install will get upgraded to the new version.

Thanks,
Jeremy Bicha

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Dirk Eddelbuettel]

Hi Evan,

On 14 January 2019 at 19:03, Evan Miller wrote:
| Hi Dirk,
| 
| You are correct - these are issues with the underlying C library, the GitHub 
issues you referenced. I have not researched them specifically, but I recently 
fixed two issues (#36 and #37) that are possibly related:
| 
| https://github.com/evanmiller/libxls/issues/36 

| https://github.com/evanmiller/libxls/issues/37 

| 
| I will look into #34 and #35 when I get a chance.

Thanks for the prompt follow-up.  Please keep us posted and abreast of any 
progress.

Dirk

| Evan
| 
| > On Jan 14, 2019, at 17:56, Dirk Eddelbuettel  wrote:
| > 
| > 
| > Hi Evan,
| > 
| > On 14 January 2019 at 23:32, Moritz Muehlenhoff wrote:
| > | Package: r-cran-readxl
| > | Severity: important
| > | Tags: security
| > | 
| > | These two libxls issues should affect r-cran-readxl:
| > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20450
| > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20452
| > 
| > These are both file as #34 and #35 at your GitHub repo, but I did not see 
any

s/file/filed/  -- sorry

| > follow-up.  I presume this is similar to the last time that the issue really
| > stems from the underlying C parser library?  Any idea how long it may take
| > until we have a fix?
| > 
| > Courtesy to Jenny who via readxl 'upstream' is the real maintainer for
| > the

s/Courtesy/Courtesy CC/ -- sorry

| > CRAN package I mostly just wrap up for Debian.
| > 
| > Best,  Dirk
| > 
| > | Cheers,
| > | Moritz
| > 
| > -- 
| > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Celejar]

On Mon, 14 Jan 2019 13:26:37 -0800
Jonathan Nieder  wrote:

> Hi again,
> 
> Celejar wrote:
> > Severity: grave
> >
> > Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per
> > README.debian) fails with:
> >
> > warning: git-daemon: unable to open supervise/ok: file does not exist
> [...]
> > Versions of packages git-daemon-run depends on:
> > ii  adduser  3.118
> > ii  git  1:2.20.1-1
> > ii  runit2.1.2-22
> 
> What is the output of "dpkg -l runit*"?  In particular, do you have
> runit-sysv or runit-systemd installed?

~# dpkg -l runit*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  runit  2.1.2-22 amd64system-wide service supervision
ii  runit-helper   2.7.3all  dh-sysuser implementation detail
un  runit-init   (no description available)
un  runit-systemd(no description available)
un  runit-sysv   (no description available)

I don't install recommends by default, and I do run into trouble
sometimes because of that ;). Should I try installing one of them to see
if that solves the problem?

Celejar

Bug#919335: mpifort (3.1.3-9) infinite loop on hurd reading from stdin

[Boud Roukema]

hi again

I forgot to state evidence that this is a GNU/Hurd bug:

On an amd64 machine running Debian/stretch GNU/Linux, mpifort runs this test 
program as expected.


$ cat hurd_fortran_minimal.f90
program openmpi_hurd_bug
 i_myid = 178
 print*,'i_myid = ',i_myid,' Please type in an integer and hit return.'
 read(*,*) icase
 print*,'Your integer is ', icase, ' Bye.'
end program openmpi_hurd_bug


$ cat infile
414



$ mpifort src/hurd_fortran_minimal.f90 && mpirun -n 1 --mca plm_rsh_agent  
/bin/false ./a.out < infile


$ uname -srvmoip
Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 unknown 
unknown GNU/Linux

$ mpifort fortran_minimal.f90 && mpirun -n 1 --mca plm_rsh_agent /bin/false 
./a.out < infile
 i_myid =  178  Please type in an integer and hit return.
  Your integer is  414  Bye.

This runs almost instantly - it does not run for 900 seconds.


$ dpkg -l |egrep "openmpi|pmix|gfortran|gcc|mpifort|libc[-0]"
ii  gcc4:6.3.0-4 
amd64GNU C compiler
ii  gcc-6  6.3.0-18+deb9u1   
amd64GNU C compiler
ii  gcc-6-base:amd64   6.3.0-18+deb9u1   
amd64GCC, the GNU Compiler Collection (base package)
ii  gfortran   4:6.3.0-4 
amd64GNU Fortran 95 compiler
ii  gfortran-6 6.3.0-18+deb9u1   
amd64GNU Fortran compiler
ii  klibc-utils2.0.4-9   
amd64small utilities built with klibc for early boot
ii  libc-bin   2.24-11+deb9u3
amd64GNU C Library: Binaries
ii  libc-dev-bin   2.24-11+deb9u3
amd64GNU C Library: Development binaries
ii  libc-l10n  2.24-11+deb9u3
all  GNU C Library: localization files
ii  libgcc-6-dev:amd64 6.3.0-18+deb9u1   
amd64GCC support library (development files)
ii  libgcc1:amd64  1:6.3.0-18+deb9u1 
amd64GCC support library
ii  libgfortran-6-dev:amd646.3.0-18+deb9u1   
amd64Runtime library for GNU Fortran applications (development files)
ii  libgfortran3:amd64 6.3.0-18+deb9u1   
amd64Runtime library for GNU Fortran applications
ii  libopenmpi-dev 2.0.2-2   
amd64high performance message passing library -- header files
ii  libopenmpi2:amd64  2.0.2-2   
amd64high performance message passing library -- shared library
ii  linux-libc-dev:amd64   4.9.130-2 
amd64Linux support headers for userspace development
ii  openmpi-bin2.0.2-2   
amd64high performance message passing library -- binaries
ii  openmpi-common 2.0.2-2   
all  high performance message passing library -- common files


Cheers
Boud

Bug#914565: libcap-ng 0.7.9-2

[Dino Hüllmann]

Hi,

I can confirm that the patched package has solved the problem and the bug no 
longer occurs.

Thanks to all involved,
Dino

Bug#919332: casparcg-server: FTBFS in sid (cannot find -lpthreads)

[Santiago Vila]

Sorry, I don't really know if it's a missing build-depends or not,
so I might better put the full build log here:

https://people.debian.org/~sanvila/build-logs/casparcg-server/

Thanks.

Bug#900354: lintian: warn against guarding adduser/addgroup calls

[Chris Lamb]

Chris Lamb wrote:

> > >> <@weasel> "guarding adduser calls considered harmful"
> > > 
> > > … regardless of --system or? oh, some concrete examples of "good" and
> > > "bad" would be really helpful here in ensuring we implement exactly
> > > what you after if you could spend a couple of seconds on that?
> > > 
> > I would think adduser/addgroup without --system in maintainer scripts
> > should be verboten altogether.  I'll try to poke through codesearch to
> > find other examples later.
> 
> Great stuff — looking forward to receiving these. :)

Gentle ping on this, Julien?


Regards,

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

Bug#909510: please add a lintian note to inform/warn about python in the shebang (instead of python2/python2.7)

[Chris Lamb]

Adrian Bunk wrote:

> > There is discussion upstream about updating PEP 394 to recommend 
> > soft-linking
> > python to python3 on newer distributions.  Not a good idea from my point of
> > view, but it would be better if we remove the usage of python as a shebang 
> > in
> > our packages.  Replacing that with python2 or python2.7 should be easy and 
> > safe.
> >  It would be nice if lintian could help with this task. Maybe first as a 
> > note so
> > we can get an overview.
> 
> Isn't it too late for such a lintian warning to make sense?
> 
> We are only 5.5 months away from the buster freeze, and there
> is no realistic chance of fixing this archive-wide until then.
> 
> Unless plans have changed python2 will not be part of bullseye,
> and for that to happen removal of any python2 usage has to start
> aggressively directly after the release of buster.
> The lintian warning would be moot then.
> 
> If such an upstream change will be in bullseye or later,
> the realistic solution would be to add a
>   Breaks: python-minimal
>   Replaces: python-minimal
> to python3-minimal.

Any followup to this, Matthias?


Regards,

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

Bug#907072: lintian: verify AppStream metainfo metadata_license matches debian/copyright

[Chris Lamb]

Chris Lamb wrote:

> > The gnupg2 source package version 2.2.9-1 has this mismatch because i
> > was sloppy.
> 
> So, debian/copyright contains:
> 
>Files: debian/org.gnupg.scdaemon.metainfo.xml
>Copyright: 2017 Daniel Kahn Gillmor 
>Comment: This file is licensed permissively for the sake of AppStream
>License: CC0-1.0
> 
> ... and debian/org.gnupg.scdaemon.metainfo.xml contains:
> 
>
>
>  org.gnupg.scdaemon
>  GPL
>  scdaemon
>  USB SmartCard Readers
>  
>
>  GnuPG's scdaemon provides access to USB tokens and smartcard
>  readers that provide cryptographic functionality (e.g. use of
>  protected secret keys).
>
>  
>[...]
> 
> ... which is installed to /usr/share/metainfo via debian/
> scdaemon.install.
> 
> Thus, whilst we can rely on such metadata files existing in /usr/share/
> metainfo/*.xml (or similar) we don't know which file in the source tree
> this originated from (and thus it's license).
> 
> Ideas?

Gentle ping on this? :)


Regards,

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

Bug#909267: library-not-linked-against-libc: downgrade from error

[Chris Lamb]

Chris Lamb wrote:

> > > I wonder if we would get all of the utility out of the tag if instead it
> > > looked for shared libraries with no NEEDED metadata.  I think it's only
> > > catching libraries that aren't linked with anything else, so maybe just
> > > check for that explicitly?
> > 
> > Yeah probably better than the status-quo. Any kind of plugin would need
> > to be excluded though, because it might simply be using symbols from the
> > loading binary (via -rdynamic). It would still emit false-positives for
> > any library that implements language run-times or does syscall wrapping.
> […]
> > So, I'd say the trade-off is worth it, as there's definitely going to
> > be way less false-positives on language run-time libraries, than the
> > current false-positives.
> 
> Sounds reasonable. Can someone retitle this bug to match?  (I doubt I
> personally have enough shared library foo to implement this myself,
> alas.)

Gentle ping on this, folks? :)


Regards,

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

Bug#919335: mpifort (3.1.3-9) infinite loop on hurd reading from stdin

[Boud Roukema]

Source: openmpi
Version: 3.1.3-9
Severity: important

SUMMARY: mpifort (openmpi 3.1.3-9) infinite loop on hurd while reading from 
stdin

DESCRIPTION:
On GNU/Hurd, a few-line fortran program that reads an integer from
stdin and outputs it to stdout, and has no calls to mpi, runs
as expected when compiled with gfortran-8.2.0-2, but when compiled
with mpifort (openmpi 3.1.3-9), runs at about 10-30% of cpu 
in an apparently infinite loop (at least 900 seconds).



CONTEXT:

$ uname -a
GNU exodar 0.9 GNU-Mach 1.8+git20181103-486-dbg/Hurd-0.9 i686-AT386 GNU

$ cat /proc/hostinfo
Basic info:
max_cpus=  1/* max number of cpus possible */
avail_cpus  =  1/* number of cpus now available */
memory_size = 3221151744/* size of memory in bytes */
cpu_type= 19/* cpu type */
cpu_subtype =  1/* cpu subtype */

Scheduling info:
min_timeout = 10/* minimum timeout in milliseconds */
min_quantum =100/* minimum quantum in milliseconds */

Load info:
avenrun[3]  = { 1.57, 1.57, 1.43 }
mach_factor[3]  = { 0.15, 0.14, 0.09 }


$ dpkg -l |egrep "openmpi|pmix|gfortran|gcc|mpifort|libc[-0]"

ii  gcc4:8.2.0-2   hurd-i386
GNU C compiler
ii  gcc-8  8.2.0-14hurd-i386
GNU C compiler
ii  gcc-8-base:hurd-i386   8.2.0-14hurd-i386
GCC, the GNU Compiler Collection (base package)
ii  gfortran   4:8.2.0-2   hurd-i386
GNU Fortran 95 compiler
ii  gfortran-8 8.2.0-14hurd-i386
GNU Fortran compiler
ii  libc-bin   2.28-5  hurd-i386
GNU C Library: Binaries
ii  libc-dev-bin   2.28-5  hurd-i386
GNU C Library: Development binaries
ii  libc-l10n  2.28-5  all  
GNU C Library: localization files
ii  libc0.3:hurd-i386  2.28-5  hurd-i386
GNU C Library: Shared libraries
ii  libc0.3-dev:hurd-i386  2.28-5  hurd-i386
GNU C Library: Development Libraries and Header Files
ii  libgcc-8-dev:hurd-i386 8.2.0-14hurd-i386
GCC support library (development files)
ii  libgcc1:hurd-i386  1:8.2.0-14  hurd-i386
GCC support library
ii  libgfortran-8-dev:hurd-i3868.2.0-14hurd-i386
Runtime library for GNU Fortran applications (development files)
ii  libgfortran5:hurd-i386 8.2.0-14hurd-i386
Runtime library for GNU Fortran applications
ii  libopenmpi-dev:hurd-i386   3.1.3-9 hurd-i386
high performance message passing library -- header files
ii  libopenmpi3:hurd-i386  3.1.3-9 hurd-i386
high performance message passing library -- shared library
ii  libpmix2:hurd-i386 3.1.0~rc4-1 hurd-i386
Process Management Interface (Exascale) library
ii  openmpi-bin3.1.3-9 hurd-i386
high performance message passing library -- binaries
ii  openmpi-common 3.1.3-9 all  
high performance message passing library -- common files

$ mpifort --showme
gfortran -I/usr/lib/i386-gnu/openmpi/include -pthread 
-I/usr/lib/i386-gnu/openmpi/lib -Wl,--enable-new-dtags 
-L/usr/lib/i386-gnu/openmpi/lib -lmpi_usempif08 -lmpi_usempi_ignore_tkr 
-lmpi_mpifh -lmpi

$ mpifort --version
GNU Fortran (Debian 8.2.0-14) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gfortran --version
GNU Fortran (Debian 8.2.0-14) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.





REPRODUCE THE BUG:

$ cat hurd_fortran_minimal.f90
program openmpi_hurd_bug
  i_myid = 178
  print*,'i_myid = ',i_myid,' Please type in an integer and hit return.'
  read(*,*) icase
  print*,'Your integer is ', icase, ' Bye.'
end program openmpi_hurd_bug


$ cat infile
414

(1) gfortran

$  gfortran src/hurd_fortran_minimal.f90 && ./a.out < infile
 i_myid =  178  Please type in an integer and hit return.
 Your integer is  414  Bye.

Compiled without errors or warnings; printed out the integer 414 as expected.

(2) mpifort

Since exodar has only one cpu, and since a test script for openmpi
should be able to run on a single-processor machine, and since it's a bad
idea to ssh to any external machines when doing automated tests,
the '--mca 

Bug#919334: kde-standard: Please add kleopatra to Depends

[Scott Kitterman]

Package: kde-standard
Version: 5:102
Severity: normal

Debian ought to be making barriers to using encryption as low as we reasonably
can.  If you attempt to set a preferred gpg key in kmail without kleopatra
installed, it fails with a very unhelpful error message.

Rather than improve the error message in kmail, let's just make it work by
adding kleopatra to kde-standard.

Scott K

Bug#919332: casparcg-server: FTBFS in sid (cannot find -lpthreads)

[Santiago Vila]

Package: src:casparcg-server
Version: 2.2.0+dfsg-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-arch
dh build-arch --sourcedirectory=src --buildsystem=cmake
   dh_update_autotools_config -a -O--sourcedirectory=src -O--buildsystem=cmake
   dh_autoreconf -a -O--sourcedirectory=src -O--buildsystem=cmake
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/casparcg-server-2.2.0+dfsg'
dh_auto_configure -- -DENABLE_HTML=OFF
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DENABLE_HTML=OFF ../src
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done

[... snipped ...]

./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:
 undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/cmTC_43642.dir/build.make:87: cmTC_43642] Error 1
make[3]: Leaving directory 
'/<>/casparcg-server-2.2.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
make[2]: *** [Makefile:121: cmTC_43642/fast] Error 2
make[2]: Leaving directory 
'/<>/casparcg-server-2.2.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'

File 
/<>/casparcg-server-2.2.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include 

int main(int argc, char** argv)
{
  (void)argv;
#ifndef pthread_create
  return ((int*)(_create))[argc];
#else
  (void)argc;
  return 0;
#endif
}

Determining if the function pthread_create exists in the pthreads failed with 
the following output:
Change Dir: 
/<>/casparcg-server-2.2.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_24c32/fast"
make[2]: Entering directory 
'/<>/casparcg-server-2.2.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_24c32.dir/build.make 
CMakeFiles/cmTC_24c32.dir/build
make[3]: Entering directory 
'/<>/casparcg-server-2.2.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_24c32.dir/CheckFunctionExists.c.o
/usr/bin/cc   -g -O2 
-fdebug-prefix-map=/<>/casparcg-server-2.2.0+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -DCHECK_FUNCTION_EXISTS=pthread_create   -o 
CMakeFiles/cmTC_24c32.dir/CheckFunctionExists.c.o   -c 
/usr/share/cmake-3.13/Modules/CheckFunctionExists.c
Linking C executable cmTC_24c32
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_24c32.dir/link.txt 
--verbose=1
/usr/bin/cc -g -O2 
-fdebug-prefix-map=/<>/casparcg-server-2.2.0+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -DCHECK_FUNCTION_EXISTS=pthread_create  -Wl,-z,relro  
-rdynamic CMakeFiles/cmTC_24c32.dir/CheckFunctionExists.c.o  -o cmTC_24c32 
-lpthreads 
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/cmTC_24c32.dir/build.make:87: cmTC_24c32] Error 1
make[3]: Leaving directory 
'/<>/casparcg-server-2.2.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
make[2]: *** [Makefile:121: cmTC_24c32/fast] Error 2
make[2]: Leaving directory 
'/<>/casparcg-server-2.2.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'


dh_auto_configure: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DENABLE_HTML=OFF ../src returned exit code 1
make[1]: *** [debian/rules:6: override_dh_auto_configure] Error 2
make[1]: Leaving directory '/<>/casparcg-server-2.2.0+dfsg'
make: *** [debian/rules:3: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -B".
At the time of writing this, it has not been tested here yet:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/casparcg-server.html

but the error message suggests a missing build-dependency.

Thanks.

Bug#919333: schroedinger-coordgenlibs: FTBFS in sid (Can't exec "cmake": No such file or directory)

[Santiago Vila]

Package: src:schroedinger-coordgenlibs
Version: 1.1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-arch
dh build-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
   dh_auto_configure -a
install -d obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu ..
Can't exec "cmake": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 475.
dh_auto_configure: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu .. failed to execute: No child 
processes
dh_auto_configure: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu .. returned exit code 2
make: *** [debian/rules:8: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


The above build was made in my autobuilder with "dpkg-buildpackage -B"
but it does also fail here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/schroedinger-coordgenlibs.html

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#919266: msmtp: AppArmor profile makes .msmtprc symlink unusable

[semente]

Package: msmtp
Version: 1.8.1-2
Followup-For: Bug #919266

I have the same issue. I set up my dotfiles as symlinks and would be
great if AppArmor allow it.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 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)
LSM: AppArmor: enabled

Versions of packages msmtp depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.28-4
ii  libgnutls303.6.5-2
ii  libgsasl7  1.8.0-8+b2
ii  ucf3.0038+nmu1

Versions of packages msmtp recommends:
ii  ca-certificates  20170717

Versions of packages msmtp suggests:
pn  msmtp-mta  

-- debconf information excluded

Bug#919320: nginx-extras: Would you please consider replacing Gzip module with Brotli for compression?

[Abigaile Johannesburg]

Thanks for sharing your thought. But I just checked Google's home page, it is 
using 'content-encoding: br'. I wonder how they curb the security concern. 

Then how about keeping Gzip and include length_hiding module in nginx-extra 
instead? 

https://github.com/nulab/nginx-length-hiding-filter-module 


Or we should not use any compression at all?

Thanks,
Abi

Jan 14, 2019, 11:05 PM by tew...@dark-net.net:

> FYI if I remember right BREACH is a risk in Brotli as well.
>
> Also Brotli has a few code level concerns that the Ubuntu Security Team saw 
> in a cursory review that could lead to crashes which made it judged 'not 
> suitable for inclusion'.
>
> Just wanted to share this info.
>
> On Mon, Jan 14, 2019, 17:46 Abigaile Johannesburg <> a...@tuta.io 
> >  wrote:
>
>> Package: nginx-extras
>> Version: 1.14.2-2
>> Severity: wishlist
>>
>>
>> Hello nginx maintainers,
>>
>> At the moment, nginx-extra package includes gzip module as one of the 
>> optional http modules. However it seems Gzip compression is vulnerable to 
>> BREACH [1] attack and the vulnerability researchers' recommendation is to 
>> disable Gzip compression. There are also discussions on stackexchange [2].
>>
>> Instead of disabling compression over TLS/SSL completely, Google seems to be 
>> using a different compression scheme Brotli [3]. Would you consider 
>> replacing nginx Gzip module with Brotli?
>>
>> Thanks,
>> Abi,
>>
>> ---
>> [1] >> http://breachattack.com/#mitigations 
>> 
>> [2] >> 
>> https://security.stackexchange.com/questions/65625/current-state-of-breach-gzip-ssl-attack
>>  
>> 
>> [3] >> https://github.com/google/ngx_brotli 
>> 
>>

Bug#919331: wine: /run/user exists, but not /run/user/$uuid

[Jon Daley]

Package: wine
Version: 4.0~rc4-2
Severity: normal

I checked the patch (in bug 904041, not what was actually checked in to the 
source code)
and I see that it only checks for /run/user, which does exist on my system.

I do have pam-systemd, but not XDG_RUNTIME_DIR, as was requested in the other 
bug.

I manually created /run/user/1000 and everything works.

For me, this is a highly customized situation (PHP via a web page runs wine and 
uses stdout
from the windows executable to return results to PHP) so I don't mind a hacky 
solution at all.

Am I right in thinking I could set XDG_RUNTIME_DIR to a safe temporary 
directory somewhere
and that would be fine?

It seems the real fix would be to check for the actual $UUID directory, rather 
than just /run/user.


-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

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

Kernel: Linux 4.13.0-1-686-pae (SMP w/2 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)

Versions of packages wine depends on:
ii  wine32  4.0~rc4-2

wine recommends no packages.

Versions of packages wine suggests:
pn  dosbox   
pn  playonlinux  
pn  q4wine   
pn  winbind  
pn  wine-binfmt  
pn  winetricks   

Versions of packages wine is related to:
pn  fonts-wine  
ii  wine4.0~rc4-2
ii  wine32  4.0~rc4-2
pn  wine64  

-- no debconf information

Bug#919330: ITP: libapache2-mod-authn-yolo

[Hans van Kranenburg]

Package: wnpp
Severity: wishlist
Owner: Hans van Kranenburg 

* Package name: libapache2-mod-authn-yolo
  Version : 1.1
  Upstream Author : Hans van Kranenburg 
* URL : https://github.com/knorrie/mod-authn-yolo/
* License : Apache-2.0
  Programming Lang: C
  Description : Yolo style authentication for Apache 2

The authn_yolo module is an authentication provider for Basic
Authentication in the Apache2 web server. It accepts any combination of
user and password.

Sometimes this is useful when testing or building a proof of concept,
since there's no need to generate a htpasswd file etc. It can also be
used to pass a user name to Apache in a scenario where verification of
the credentials is delegated to a reverse proxy in front of Apache.

--- >8 

So, this apache2 authentication module doesn't do more than just...

return AUTH_GRANTED;

It can be used like this:


AuthType Basic
AuthName "Yolo"
AuthBasicProvider yolo
Require valid-user


There seems to be no other way in apache2 to end up with the same
result, allowing everything, but still ending up with the provided
username in r->user.

The actual use case for this (at $dayjob, at Mendix) is to be able to do
all authentication and authorization work in nginx with custom code
using lua etc etc... and still have apache2 running libapache2-mod-svn
behind it, using the user name from the basic auth header as svn commit
author.

Thanks,
Knorrie

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Michael Biebl]

On Sat, 12 Jan 2019 14:54:09 +0100 Axel Beckert  wrote:

> I don't have local access to the affected machine for the weekend and
> hence won't be able to test reboots before Monday again, though.
> 
> I'm though also keen to know if a downgrade to udev 239 will make it
> more stable again, so I'll definitely test that.

Please make sure to also test 240-4

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

[Florian Schlichting]

On Mon, Jan 14, 2019 at 01:31:28PM -0800, Diane Trout wrote:
> I'm a little worried about just rm-ing previously invalid locations for
> configuration files. Might you have suggestions about how to safely
> clean up dnssec-triggers configuration file mess? (At the very least it
> seems like it should check that a configuration file was actually
> created by it before just deleting it)

Before thinking about cleanup, I'd start by making sure that fresh
installs don't re-create problems. At the moment, purging dnssec-trigger
leaves two keypairs in /etc; and when I rm them manually, and again
install dnssec-trigger, they're back (in addition to the identically
named pair in /etc/dnssec-trigger, which does get cleaned up on purge).
Does that not happen for you?

I think you can assume that files named /etc/dnssec_trigger_* belong to
your package. However I don't understand dnssec-trigger enough to judge
if these will always be autogenerated keys that are rendered obsolete by
the keys in /etc/dnssec-trigger, or if some sysadmin might have replaced
them with his own keys, for some reason. That is, if these are
"configuration files" or just "data" that could equally have been put
into /var/lib/dnssec-trigger for example...

Florian

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

[Michael Biebl]

Am 14.01.19 um 19:45 schrieb Isaac Gelado:
> When I got the initramfs shell I also typed
> 
> udevadm trigger --type=subsystems --action=add
> udevadm trigger --type=devices --action=add
> 
> and tried to continue the boot process, but it failed. Then I typed
> 
> udevadm trigger --type=devices --action=add -v
> 
> and it booted nicely. Somehow, the `-v` flag is trigger some
> additional logic (maybe required to get what to print?) that makes the
> difference.

This issue is fixed in 240-4.
Please update to that version.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#919320: nginx-extras: Would you please consider replacing Gzip module with Brotli for compression?

[Thomas Ward]

FYI if I remember right BREACH is a risk in Brotli as well.

Also Brotli has a few code level concerns that the Ubuntu Security Team saw
in a cursory review that could lead to crashes which made it judged 'not
suitable for inclusion'.

Just wanted to share this info.

On Mon, Jan 14, 2019, 17:46 Abigaile Johannesburg  Package: nginx-extras
> Version: 1.14.2-2
> Severity: wishlist
>
>
> Hello nginx maintainers,
>
> At the moment, nginx-extra package includes gzip module as one of the
> optional http modules. However it seems Gzip compression is vulnerable to
> BREACH [1] attack and the vulnerability researchers' recommendation is to
> disable Gzip compression. There are also discussions on stackexchange [2].
>
> Instead of disabling compression over TLS/SSL completely, Google seems to
> be using a different compression scheme Brotli [3]. Would you consider
> replacing nginx Gzip module with Brotli?
>
> Thanks,
> Abi,
>
> ---
> [1] http://breachattack.com/#mitigations
> [2]
> https://security.stackexchange.com/questions/65625/current-state-of-breach-gzip-ssl-attack
> [3] https://github.com/google/ngx_brotli
>

Bug#919326: msmtp: account default not found: no configuration file available

[Simon Deziel]

Hi Sergio,

On 2019-01-14 5:40 p.m., Sergio Mendoza wrote:
>   A few days ago, msmtp fails to work.  It all seems to be related to the
> inability to read ~/.msmtprc file.  In other words it seems that
> ~/.msmtprc needs to have mode 644.  This is not at all desired since
> sensible (private) information can be included in that file. The package
> msmtp should run  with no trouble when the user configuration file
> ~/.msmtprc has mode 600.

Indeed, it should work with ~/.msmtprc with mode 0600. Is it working
when you have it set to 0644?

>   I am sending you some useful output so that you can check the relevance of 
> the
> situation (please note that I tried playing with stable, testing and sid
> versions of msmtp and I get the same output -this lead me to think whether
> the problem is with msmtp or with some other related package):
> 
> 
>>
> 
> sergio@quetzalli:~$ echo "Hello World" | msmtp -d ser...@mendozza.org
> ignoring system configuration file /etc/msmtprc: No such file or directory
> ignoring user configuration file /home/sergio/.msmtprc: Permission denied
> falling back to default account
> msmtp: account default not found: no configuration file available
> 
>
> 
>   As such, the bug leaves the package fully unusable.

That's unexpected but could be related to the Apparmor profile changes
that went in recently. Is /home/sergio/.msmtprc a symlink by any chance?
If yes, could you share the output of "ls -l /home/sergio/.msmtprc"?

Could you please also share the output of "dmesg | grep apparmor"

Thanks in advance,
Simon

Bug#919326: msmtp: account default not found: no configuration file available

[Sergio Mendoza]

Dear Simon,

  Yes.  I have now checked and I have .msmtprc as a symlink.  If it is not
a symlink then I have no problems and everything runs smooth.  In any case
this is the output you asked for:

root@quetzalli:~# dmesg | grep apparmor | tail -n 20
[1064093.935900] audit: type=1400 audit(1547506649.916:130): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="torbrowser_tor" 
pid=14345 comm="apparmor_parser"
[1064094.438967] audit: type=1400 audit(1547506650.420:131): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="/usr/lib/cups/backend/cups-pdf" pid=14346 comm="apparmor_parser"
[1064094.440476] audit: type=1400 audit(1547506650.420:132): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="/usr/sbin/cupsd" 
pid=14346 comm="apparmor_parser"
[1064094.461620] audit: type=1400 audit(1547506650.444:133): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="/usr/sbin/cupsd//third_party" pid=14346 comm="apparmor_parser"
[1064094.520228] audit: type=1400 audit(1547506650.500:134): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="torbrowser_firefox" 
pid=14343 comm="apparmor_parser"
[1064094.736714] audit: type=1400 audit(1547506650.716:135): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="system_tor" pid=14348 
comm="apparmor_parser"
[1064094.854220] audit: type=1400 audit(1547506650.836:136): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="libreoffice-oopslash" 
pid=14350 comm="apparmor_parser"
[1064094.936866] audit: type=1400 audit(1547506650.916:137): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="torbrowser_plugin_container" pid=14347 comm="apparmor_parser"
[1064095.090757] audit: type=1400 audit(1547506651.072:138): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="/usr/bin/man" pid=14351 
comm="apparmor_parser"
[1064095.091543] audit: type=1400 audit(1547506651.072:139): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="man_filter" pid=14351 
comm="apparmor_parser"
[1064102.892009] audit: type=1400 audit(1547506658.872:150): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="/usr/bin/evince" 
pid=14349 comm="apparmor_parser"
[1064102.910914] audit: type=1400 audit(1547506658.892:151): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="/usr/bin/evince//sanitized_helper" pid=14349 comm="apparmor_parser"
[1064102.914186] audit: type=1400 audit(1547506658.896:152): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="/usr/bin/evince-previewer" pid=14349 comm="apparmor_parser"
[1064102.930416] audit: type=1400 audit(1547506658.912:153): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="/usr/bin/evince-previewer//sanitized_helper" pid=14349 
comm="apparmor_parser"
[1064102.932260] audit: type=1400 audit(1547506658.912:154): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="/usr/bin/evince-thumbnailer" pid=14349 comm="apparmor_parser"
[1064111.250930] audit: type=1400 audit(1547506667.232:155): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="libreoffice-soffice" pid=14344 comm="apparmor_parser"
[1064111.253633] audit: type=1400 audit(1547506667.236:156): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="libreoffice-soffice//gpg" pid=14344 
comm="apparmor_parser"
[1064151.025521] audit: type=1400 audit(1547506707.004:157): apparmor="DENIED" 
operation="open" profile="/usr/bin/msmtp" name="/home/sergio/Private/.msmtprc" 
pid=14560 comm="msmtp" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[1064177.994021] audit: type=1400 audit(1547506733.971:158): apparmor="DENIED" 
operation="open" profile="/usr/bin/msmtp" 
name="/home/sergio/mail/msmtp/log.txt" pid=14580 comm="msmtp" 
requested_mask="ac" denied_mask="ac" fsuid=1000 ouid=1000
[1064281.325901] audit: type=1400 audit(1547506837.302:159): apparmor="DENIED" 
operation="open" profile="/usr/bin/msmtp" 
name="/home/sergio/mail/msmtp/log.txt" pid=14656 comm="msmtp" 
requested_mask="ac" denied_mask="ac" fsuid=1000 ouid=1000


Cheers,

Sergio.





On Mon, Jan 14, 2019 at 05:59:31PM -0500, Simon Deziel wrote:
> Hi Sergio,
> 
> On 2019-01-14 5:40 p.m., Sergio Mendoza wrote:
> >   A few days ago, msmtp fails to work.  It all seems to be related to the
> > inability to read ~/.msmtprc file.  In other words it seems that
> > ~/.msmtprc needs to have mode 644.  This is not at all desired since
> > sensible (private) information can be included in that file. The package
> > msmtp should run  with no trouble when the user configuration file
> > ~/.msmtprc has mode 600.
> 
> Indeed, it should work with ~/.msmtprc with mode 0600. Is it working
> when you have it set to 0644?
> 
> 

Bug#919162: lintian.d.o apears to report many failures twice

[Chris Lamb]

[Adding ni...@thykier.net to CC]

Hi Ian,

> It seems that lintian.d.o lists some (all?) failures in a binary
> package twice.
[…]
>  * usr/bin/grub-editenv
>  * usr/bin/grub-editenv
[…]

> I failed to find the raw reports anywhere so I can't see if these are
> duplicated there

So I dug them out from 
/srv/lintian.debian.org/reports-directory/www/lintian.log.gz
on lindsay.debian.org:

N: Processing binary package grub-common (version 2.02+dfsg1-10, arch 
amd64) ...
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-editenv
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-file
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-fstest
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-glue-efi
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-menulst2cfg
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-mkfont
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-mkimage
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-mklayout
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-mknetdir
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-mkpasswd-pbkdf2
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-mkrelpath
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-mkrescue
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-mkstandalone
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-mount
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-render-label
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-script-check
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/bin/grub-syslinux2cfg
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/sbin/grub-macbless
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/sbin/grub-mkdevicemap
I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow 
usr/sbin/grub-probe
C: grub-common binary (2.02+dfsg1-10) [amd64]: ctrl-script postinst
C: grub-common binary (2.02+dfsg1-10) [amd64]: ctrl-script postrm
C: grub-common binary (2.02+dfsg1-10) [amd64]: ctrl-script preinst
C: grub-common binary (2.02+dfsg1-10) [amd64]: ctrl-script prerm
C: grub-common binary (2.02+dfsg1-10) [amd64]: 
control-tarball-compression-format xz
C: grub-common binary (2.02+dfsg1-10) [amd64]: 
data-tarball-compression-format xz
C: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-interpreter control/postinst /bin/sh
C: grub-common binary (2.02+dfsg1-10) [amd64]: 
debhelper-autoscript-in-maintainer-scripts dh_installdeb/12
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper postinst:4
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper postinst:7
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper postinst:10
C: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-interpreter control/postrm /bin/sh
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper postrm:4
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper postrm:7
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper postrm:10
C: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-interpreter control/preinst /bin/sh
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper preinst:4
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper preinst:7
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper preinst:10
C: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-interpreter control/prerm /bin/sh
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper prerm:4
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper prerm:7
W: grub-common binary (2.02+dfsg1-10) [amd64]: 
maintainer-script-should-not-use-dpkg-maintscript-helper prerm:10
N: 

… so I think that this is something depper in the reporting system
itself (and they are not emitted twice locally).

Unfortunately this is an area that I don't know very well 

Bug#919328: ITP: exadrums -- Software drum module (graphical user interface)

[Jeremy Oden]

Package: wnpp
Severity: wishlist
Owner: Jeremy Oden 

* Package name: exadrums
  Version : 0.3.0
  Upstream Author : Jeremy Oden 
* URL : https://github.com/SpintroniK/eXaDrums
* License : MIT
  Programming Lang: C++
  Description : Software drum module (graphical user interface)

ExaDrums is a virtual drum module that allows to play drums with custom-made
drum kits.
It is user-friendly and combines high quality stereo sound with low latency.
Each drum kit provides individual sliders in order to control the volume of its
drum pads.
A built-in metronome can be combined with a rhythm coach to make practice
sessions easier and efficient.
The drum triggers can be adjusted so that their response feels as natural as
possible, and different sensor interfaces include a virtual (on-screen) multi
pad and external sensors.


Exadrums provides a graphical user interface that offers the functionalities of
a standard
drum module. I depends on libexadrums.
I have played drums using exadrums as a drum module, and it is working well.
To my knowledge there are no packages in the current Debian distributions that
offer similar functionality.

Bug#919325: iptables -nvL consumes 100% of CPU and hogs memory with kernel 5.0-rc2

[Martin Steigerwald]

I asked on LKML using similar subject about it.  Not yet visible on

https://lore.kernel.org/lkml/

Thanks,
-- 
Martin

Bug#919329: ITP: r-cran-venndiagram -- Generate High-Resolution Venn and Euler Plots

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: r-cran-venndiagram
* URL : https://cran.r-project.org/web/packages/VennDiagram/
* License : GPL-2
  Programming Lang: R
  Description : Generate High-Resolution Venn and Euler Plots

To be team maintained at https://salsa.debian.org/r-pkg-team/r-cran-venndiagram

Bug#919117: meson ignores all compiler flags when a --cross-file is given

[Jussi Pakkanen]

On Sun, Jan 13, 2019 at 5:35 PM Jussi Pakkanen  wrote:

> I updated the packaging to have the new debcrossgen script.
> Unfortunately the repository is currently broken and pbuilder can not
> install all the dependency packages needed to run the test suite so
> binary packages can not be built. I have uploaded the packaging to
> mentors, feel free to upload it to unstable as you see fit:
>
> https://mentors.debian.net/package/meson

I tested again today and sid is now in working order. The test suite
passes for that packaging version. Those of you who have upload
rights, please upload it so these issues will be fixed. Thanks.

Bug#919327: ITP: libexadrums -- Software drum module (library)

[Jeremy Oden]

Package: wnpp
Severity: wishlist
Owner: Jeremy Oden 

* Package name: libexadrums
  Version : 0.3.0
  Upstream Author : Jeremy Oden 
* URL : https://github.com/SpintroniK/libeXaDrums
* License : MIT
  Programming Lang: C++
  Description : Software drum module (library)

ExaDrums is a virtual drum module that allows to play drums with custom-made
drum kits.
It is user-friendly and combines high quality stereo sound with low latency.
Each drum kit provides individual sliders in order to control the volume of its
drum pads.
A built-in metronome can be combined with a rhythm coach to make practice
sessions easier and efficient.
The drum triggers can be adjusted so that their response feels as natural as
possible, and different sensor interfaces include a virtual (on-screen) multi
pad and external sensors.


Libexadrums provides a C++ API that offers the functionalities of a standard
drum module.
I have played drums using libexadrums, and it is working well.
To my knowledge there are no packages in the current Debian distributions that
offer similar functionality.

Bug#919325: iptables -nvL consumes 100% of CPU and hogs memory with kernel 5.0-rc2

[Martin Steigerwald]

Martin Steigerwald - 14.01.19, 23:38:
> Package: iptables
> Version: 1.8.2-3
> Severity: important
[…]
> I upgraded to self-compiled 5.0-rc2 today and found the machine to be
> slow after startup. I saw iptables consuming 100% CPU, it only
> responded to SIGKILL. It got restarted several times, probably by
> some systemd service.
> 
> Then I started 'iptables -nvL' manually. And I got this:

[… strace output with what appears to be a loop on recvmsg …]

[… atop output showing iptables using 5 GiB + of resident memory …]

> I will attach kernel configuration.
> 
> That is all I am willing to spend time on for now before going to
> sleep. I will however reboot with older 4.20 kernel to see whether it
> is kernel related.

It appears to be kernel related. I do not see this behavior with self-
compiled 4.20 kernel.

Attaching both configuration for both kernels.

[…]
-- 
Martin

config-4.20.0-tp520.xz
Description: application/xz


config-5.0.0-rc2-tp520.xz
Description: application/xz

Bug#919326: msmtp: account default not found: no configuration file available

[Sergio Mendoza]

Package: msmtp
Version: 1.8.1-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

  A few days ago, msmtp fails to work.  It all seems to be related to the
inability to read ~/.msmtprc file.  In other words it seems that
~/.msmtprc needs to have mode 644.  This is not at all desired since
sensible (private) information can be included in that file. The package
msmtp should run  with no trouble when the user configuration file
~/.msmtprc has mode 600.
  
  I am sending you some useful output so that you can check the relevance of the
situation (please note that I tried playing with stable, testing and sid
versions of msmtp and I get the same output -this lead me to think whether
the problem is with msmtp or with some other related package):


>

sergio@quetzalli:~$ echo "Hello World" | msmtp -d ser...@mendozza.org
ignoring system configuration file /etc/msmtprc: No such file or directory
ignoring user configuration file /home/sergio/.msmtprc: Permission denied
falling back to default account
msmtp: account default not found: no configuration file available



  As such, the bug leaves the package fully unusable.

Cheers,

Sergio.




-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages msmtp depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.28-5
ii  libgnutls303.6.5-2
ii  libgsasl7  1.8.0-8+b2
ii  ucf3.0038+nmu1

Versions of packages msmtp recommends:
ii  ca-certificates  20180409

Versions of packages msmtp suggests:
pn  msmtp-mta  

-- debconf information:
  msmtp/sysconfig: false
  msmtp/port: 25
  msmtp/maildomain:
  msmtp/tls: false
  msmtp/auto_from: true
  msmtp/host:

Bug#919325: iptables -nvL consumes 100% of CPU and hogs memory with kernel 5.0-rc2

[Martin Steigerwald]

Package: iptables
Version: 1.8.2-3
Severity: important

Dear Maintainer,

for now I am rating this important. If it happens for many users it may
have a higher severity. It may however also be a kernel issue, as it
happened after upgrading to self-compiled 5.0-rc2.

I upgraded to self-compiled 5.0-rc2 today and found the machine to be slow
after startup. I saw iptables consuming 100% CPU, it only responded to
SIGKILL. It got restarted several times, probably by some systemd service.

Then I started 'iptables -nvL' manually. And I got this:

% strace -p 5748
[… tons more, in what appeared an endless loop …]
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 
msg_namelen=12, msg_iov=[{iov_base={{len=372, type=0xa06 /* NLMSG_??? */, 
flags=NLM_F_MULTI|0x800, seq=0, pid=5748}, 
"\x02\x00\x00\x11\x0b\x00\x01\x00\x66\x69\x6c\x74\x65\x72\x00\x00\x0b\x00\x02\x00\x4f\x55\x54\x50\x55\x54\x00\x00\x0c\x00\x03\x00"...},
 iov_len=16536}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 372
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 
msg_namelen=12, msg_iov=[{iov_base={{len=372, type=0xa06 /* NLMSG_??? */, 
flags=NLM_F_MULTI|0x800, seq=0, pid=5748}, 
"\x02\x00\x00\x11\x0b\x00\x01\x00\x66\x69\x6c\x74\x65\x72\x00\x00\x0b\x00\x02\x00\x4f\x55\x54\x50\x55\x54\x00\x00\x0c\x00\x03\x00"...},
 iov_len=16536}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 372
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 
msg_namelen=12, msg_iov=[{iov_base={{len=372, type=0xa06 /* NLMSG_??? */, 
flags=NLM_F_MULTI|0x800, seq=0, pid=5748}, 
"\x02\x00\x00\x11\x0b\x00\x01\x00\x66\x69\x6c\x74\x65\x72\x00\x00\x0b\x00\x02\x00\x4f\x55\x54\x50\x55\x54\x00\x00\x0c\x00\x03\x00"...},
 iov_len=16536}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 372
recvmsg(3, ^C{msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 
msg_namelen=12, msg_iov=[{iov_base={{len=372, type=0xa06 /* NLMSG_??? */, 
flags=NLM_F_MULTI|0x800, seq=0, pid=5748}, 
"\x02\x00\x00\x11\x0b\x00\x01\x00\x66\x69\x6c\x74\x65\x72\x00\x00\x0b\x00\x02\x00\x4f\x55\x54\x50\x55\x54\x00\x00\x0c\x00\x03\x00"...},
 iov_len=16536}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 372
strace: Process 5748 detached

and this (output from atop):

  PID TID   MINFLT   MAJFLTVSTEXT   VSLIBSVDATAVSTACKVSIZE  
  RSIZEPSIZE VGROWRGROW   SWAPSZRUID   EUIDMEM   
CMD1/16
11575   -615520  152K2324K 5.0G  132K 5.1G  
   5.1G   0K240.4M   240.5M   0Kroot   root33%   
iptables

I had it growing till 10 GiB before I stopped it by SIGKILL to prevent
excessive swapping.

I will attach kernel configuration.

That is all I am willing to spend time on for now before going to sleep.
I will however reboot with older 4.20 kernel to see whether it is kernel
related.

Thanks,
Martin

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

Kernel: Linux 5.0.0-rc2-tp520 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iptables depends on:
ii  libc62.28-5
ii  libip4tc01.8.2-3
ii  libip6tc01.8.2-3
ii  libiptc0 1.8.2-3
ii  libmnl0  1.0.4-2
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnfnetlink01.0.1-3+b1
ii  libnftnl11   1.1.2-2
ii  libxtables12 1.8.2-3

Versions of packages iptables recommends:
ii  nftables  0.9.0-2

Versions of packages iptables suggests:
ii  kmod  25-2

-- no debconf information

Bug#918820:

[Simon Deziel]

On 2019-01-14 1:42 p.m., demuredemeanor wrote:
> After testing this new configuration (and retesting after removing my
> temporary apparmor force-complain symlink) msmtp seems to working for
> both `pass` and the GNU stow symlink.

Thanks for the testing and feedback!

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Moritz Muehlenhoff]

Package: r-cran-readxl
Severity: important
Tags: security

These two libxls issues should affect r-cran-readxl:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20450
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20452

Cheers,
Moritz

Bug#919323: msmtp: apparmor blocks reading configuration file ~/.msmtprc

[Simon Deziel]

Hi Robbie,

On 2019-01-14 5:28 p.m., Robbie Harwood wrote:
> Package: msmtp
> Version: 1.8.1-2
> Severity: important
> 
> Dear Maintainer,
> 
> Trying to send mail with msmtp after upgrading, it fails with "no
> configuration file available".  The audit line is:
> 
> audit: type=1400 audit(1547504604.078:263): apparmor="DENIED" 
> operation="open" profile="/usr/bin/msmtp" name="/home/bos/rharwood/.msmtprc" 
> pid=15946 comm="msmtp" requested_mask="r" denied_mask="r" fsuid=21259 
> ouid=21259
> 
> I wish I could tell you more, but I know nothing about apparmor.

That's exactly what we need for such bugs so thanks! A bunch of fixes to
the Apparmor profile are being worked on [1] and it should make it work
for you.

Regards,
Simon


1:
https://salsa.debian.org/sdeziel-guest/msmtp/blob/misc-fixes/debian/apparmor/usr.bin.msmtp

Bug#918623: dizzy: Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT

[Florian Schlichting]

Hi Niko,

> >   $ dizzy
> >   GPU features: [x] GLSL [x] FBOs
> >   Your vendor has not defined OpenGL macro GL_FRAMEBUFFER_EXT, used at 
> > /usr/share/perl5/Dizzy/TextureGenerator.pm line 101.
> > 
> > I tested the same qemu VM with stretch and there it was working.
> > After some tests I found it stopped working when
> > libopengl-perl in version 0.7000+dfsg-1
> > entered testing in 2017-08-12.
> > But I am uncertain if the fault is
> > in package dizzy or libopengl-perl.
> 
> I looked at this a bit, and I assume it regressed with
> 
>   
> https://sourceforge.net/p/pogl/code/ci/ad3508bed030b856a8c36c4900727bbd838212dd/
> 
> If I read this correctly, the constants used to be provided
> unconditionally, but are now excluded if things like
> NO_GL_EXT_framebuffer_object are defined.
> 
> Now, our Debian packaging has
> 
>   
> https://sources.debian.org/src/libopengl-perl/0.7000+dfsg-1/debian/patches/add-gl_exclude.h/
> 
> which "adds back" these exclusions, apparently for xvfb compatibility and 
> making
> the build result independent of the build machine hardware.
> 
> My tentative conclusion is that the exclusions we patch in now affect things
> that they didn't earlier, and that we need to fix this on the libopengl-perl
> side somehow. So reassigning.
> 
> Copying Florian, who added the patch back in 2012. Any interest in looking
> at this? :)

well thanks for prodding me, I wouldn't have thought I ever touched
anything OpenGL and probably hadn't read your email otherwise.

When I started working on libopengl-perl in 2012, the update to upstream
version 0.66 was unfinished and the build would fail with an error about
a lacking gl_exclude.h; my idea was to just patch in the gl_exclude.h
that used to be part of the upstream tarball, without really
investigating its content, on the assumption that it would keep the
feature set unchanged.

Upstream's idea about gl_exclude.h is to determine the available GPU
features through probing, for which a 'glversion' binary is compiled and
run from Makefile.PL, preferably "under an X11 shell". My understanding
is that this proved impossible to reconcile with the way we build
packages on buildds, as they don't have GPUs and xvfb doesn't emulate
the relevant features either. Hence debian/patches/disable-glversion
disabled the probing, so when upstream stopped shipping gl_exclude.h,
there was nothing that created it.

I notice that the unpatched Makefile.PL has an option

dist=NO_EXCLUSIONS  Build with no OpenGL Extension exclusions

which will write a gl_exclude.h containing nothing but comments. This
seems aimed at Windows builds, but if I modify
debian/patches/add-gl_exclude.h so that it results in the same basically
empty header file, I can build a package that will run test.pl and
display the 3D graphics apparently without issues.

Do we need to exclude any OpenGL Extensions, at all?

I'd tend to think that there are so many different machines out there
that we would have heard from our users if gl_exclude.h really needed to
be tailored to the individual machine. Then again why would upstream
bother to exclude anything in the first place?

It's probably a bit late in the release cycle to "just find out" by
uploading a -2 with that modified patch.

Hmmm...

Florian

Bug#919322: CVE-2019-6245 CVE-2019-6247

[Moritz Muehlenhoff]

Source: agg
Severity: grave

Please see
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6245
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6247

Given that the package isn't exactly fast-moving, how about
revisiting #377270 for buster? Right now we need to coordinate
rebuilds against the fixed agg...

Cheers,
Moritz

Bug#919323: msmtp: apparmor blocks reading configuration file ~/.msmtprc

[Robbie Harwood]

Package: msmtp
Version: 1.8.1-2
Severity: important

Dear Maintainer,

Trying to send mail with msmtp after upgrading, it fails with "no
configuration file available".  The audit line is:

audit: type=1400 audit(1547504604.078:263): apparmor="DENIED" 
operation="open" profile="/usr/bin/msmtp" name="/home/bos/rharwood/.msmtprc" 
pid=15946 comm="msmtp" requested_mask="r" denied_mask="r" fsuid=21259 ouid=21259

I wish I could tell you more, but I know nothing about apparmor.

Thanks,
--Robbie

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

Kernel: Linux 4.19.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages msmtp depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.28-4
ii  libgnutls303.6.5-2
ii  libgsasl7  1.8.0-8+b2
ii  ucf3.0038+nmu1

Versions of packages msmtp recommends:
ii  ca-certificates  20170717

Versions of packages msmtp suggests:
pn  msmtp-mta  

-- debconf information excluded

Bug#919321: CVE-2019-6246

[Moritz Muehlenhoff]

Source: svgpp
Severity: grave
Tags: security

Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6246

It will also be affected by CVE-2019-6247 and CVE-2019-6245, as agg
doesn't provide a shared library...

So make sure to add a versioned build-deps on the fixed agg when
that's done.

Cheers,
Moritz

Bug#919320: nginx-extras: Would you please consider replacing Gzip module with Brotli for compression?

[Abigaile Johannesburg]

Package: nginx-extras
Version: 1.14.2-2
Severity: wishlist


Hello nginx maintainers,

At the moment, nginx-extra package includes gzip module as one of the optional 
http modules. However it seems Gzip compression is vulnerable to BREACH [1] 
attack and the vulnerability researchers' recommendation is to disable Gzip 
compression. There are also discussions on stackexchange [2].

Instead of disabling compression over TLS/SSL completely, Google seems to be 
using a different compression scheme Brotli [3]. Would you consider replacing 
nginx Gzip module with Brotli?

Thanks,
Abi,

---
[1] http://breachattack.com/#mitigations 
[2] 
https://security.stackexchange.com/questions/65625/current-state-of-breach-gzip-ssl-attack
 

[3] https://github.com/google/ngx_brotli 

Bug#919319: RM: pion -- RoQA; orphaned, low popcon, no rdeps

[Sebastian Andrzej Siewior]

Package: ftp.debian.org
Severity: normal

Please remove pion from unstable. Its popcon is low, it has been
recently orphaned (#919210) it is not fit for a release due to a RC bug
and has no reverse dependencies. The old maintainer gave me his
blessing [0] to file this removal. 

[0] 
https://alioth-lists.debian.net/pipermail/pkg-clamav-devel/2019-January/007102.html

Sebastian

Bug#919289: [Pkg-kde-extras] Bug#919289: kile: After upgrade, kile will not open until okular installed

[D Haley]

Hi,

Thanks for the quick reply.

> Which kind of system is this?
>
> You have a mixup of stable and testing/unstable.  This situation is not
> supported.

Its a stable system that I was upgrading to testing.  It normally runs
stable.

The upgrade is incomplete because  I was upgrading from inside a DE, and
it wanted to pull the X server, so I was upgrading piecewise whilst
trying to work.

So yes, its incomplete. If this is an is an issue, please feel free to
close the bug.

> What is the exact error you saw?

It looks like the message is from main.cpp:175-176,

175:KMessageBox::sorry(Q_NULLPTR, i18n("Kile cannot start as
a recent version the Okular library could not be found.\n\n"
176:   "Please install the
Okular library before running Kile."),

Thanks!

Bug#672369: "FIXME: MISSING XINCLUDE CONTENT" in reference manual

[arielaw]

Confirming that this bug is still around, 6 years later, on testing, with the 
exact same description.

Version: 3.24.2-3
Debian Release: testing
Architecture: i686 (x86_32)

Any ideas on how to fix this? I can help, but I'm gonna need a pointer or two 
in the right direction.

-- 
arielaw 

Bug#919318: nginx-extras: Would you please consider replacing Gzip module with Brotli for compression?

[Abigaile Johannesburg]

Package: nginx-extrasVersion: 1.14.2-2Severity: wishlistHello nginx maintainers,
At the moment, nginx-extra package includes gzip module as one of the optional 
http modules. However it seems Gzip compression is vulnerable to BREACH [1] 
attack and the vulnerability researchers' recommendation is to disable Gzip 
compression. There are also discussions on stackexchange [2]. 

Instead of disabling compression over TLS/SSL completely, Google seems to be 
using a different compression scheme Brotli [3]. Would you consider replacing 
nginx Gzip module with Brotli?

Thanks,
Abi,

---
[1] http://breachattack.com/#mitigations 
[2] 
https://security.stackexchange.com/questions/65625/current-state-of-breach-gzip-ssl-attack
 

[3] https://github.com/google/ngx_brotli 

Bug#784479: [kde4libs] Qt4's WebKit removal

[Adrian Bunk]

On Mon, Jan 14, 2019 at 06:22:52AM -0500, Scott Kitterman wrote:
> 
> That patch no longer seems to be available, so I made my own.  Patches for 
> kde4libs and kde-runtime attached.  I looked at the KDE4 packages still in 
> Buster and I don't believe this interferes with anything.  This also fixes 
> the 
> FTBFS with Samba 4.9 by dropping the KDE4 kio_smb.
> 
> I think we should move forward on these (or some improved version if someone 
> has suggestions).
> 
> Even though there are separate bugs for kde-runtime, since the patch for it 
> was already discussed in this bug, I thought we might as well keep them 
> together.

What is actually the overall plan for KDE4 in buster now?

A year ago I was told that only qtwebkit should be removed at that 
point, and the rest of KDE4 later for buster.

Someone else told me they were planning to do it after updating
all KDE packages to the latest release.

No matter what advice I followed someone was yelling at me,
so I gave up working on that.

Looking at kde-runtime in buster:

# Broken Depends:
basket: basket
kaccessible: kaccessible
kamerka: kamerka
kcollectd: kcollectd
kdbg: kdbg
kdiff3: kdiff3
keurocalc: keurocalc
kmetronome: kmetronome
kmidimon: kmidimon
kmldonkey: kmldonkey
knutclient: knutclient
kopete: kopete
kover: kover
kppp: kppp
kprinter4: kprinter4
kradio4: kradio4
kredentials: kredentials
kremotecontrol: kremotecontrol
kscd: kscd
kvpnc: kvpnc
syncevolution: syncevolution-libs-kde

Making the bugs in these packages RC (some packages like kdbg or 
kmetronome already have Qt5 versions that someone might upload to
unstable) plus an upload of kopete from experimental to unstable,
that's what would be needed for complete removal of kde-runtime.

Complete removal of kde4libs would add another list of comparable size,
with no obvious blocker.

> Scott K

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#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

[Diane Trout]

On Mon, 2019-01-14 at 21:25 +0100, Florian Schlichting wrote:
> Hi,
> 
> in the course of looking into the upgrade failure, I ended up purging
> dnssec-trigger and then installed it again. I notice this creates
> keys
> and config files in both /etc/ and /etc/dnssec-trigger?! Different to
> Alex, I get traceback in the middle of the log (also for subsequent
> attempts to 'apt-get install -f' etc):

... I thought I had fixed that... But apparently I had just found a few
other places that had hardcoded paths that weren't being updated.

Apparently there are still more hardcoded paths.

I'm a little worried about just rm-ing previously invalid locations for
configuration files. Might you have suggestions about how to safely
clean up dnssec-triggers configuration file mess? (At the very least it
seems like it should check that a configuration file was actually
created by it before just deleting it)

Diane

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Jonathan Nieder]

Hi again,

Celejar wrote:
> Severity: grave
>
> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per
> README.debian) fails with:
>
> warning: git-daemon: unable to open supervise/ok: file does not exist
[...]
> Versions of packages git-daemon-run depends on:
> ii  adduser  3.118
> ii  git  1:2.20.1-1
> ii  runit2.1.2-22

What is the output of "dpkg -l runit*"?  In particular, do you have
runit-sysv or runit-systemd installed?

Thanks,
Jonathan

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Jonathan Nieder]

Hi,

Celejar wrote:

> Severity: grave
>
> Any attempt to manage the daemon (e.g., 'sv stat git-daemon', as per
> README.debian) fails with:
>
> warning: git-daemon: unable to open supervise/ok: file does not exist
>
> I see that there's an old, archived bug about this:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570094
>
> But I'm getting the same thing on my uptodate Sid system (and even on
> another Sid system with the version of the package from experimental
> installed).
>
> I know nothing about runit, so perhaps I'm doing something obvious
> wrong, but I'm just trying to follow the directions from the README, and
> getting this.

Thanks for reporting.  I'm cc-ing Debian's runit maintainers, who may
be able to help us track this down.

I haven't tried reproducing this yet, but I will try soon (some time
this week).

Sincerely,
Jonathan

Bug#919316: bugs.debian.org: DoS with libravatar.cgi and version.cgi

[Julien Cristau]

Package: bugs.debian.org
Severity: important
X-Debbugs-Cc: debian-ad...@lists.debian.org

Hi,

the last few days our two bugs web hosts have been struggling.  We've
got apache set up with RLimitNPROC 256, which means once www-data has
that many processes fork() dies with EAGAIN.

In the case of version.cgi that means perl forking to run dot, for
libravatar.cgi it looks like it's either cp or convert.  Either way, the
failure mode of fork returning EAGAIN is that perl does sleep(5) and
tries again.  Over and over.  Which means by the time something happens
the client has long gone, but we're still holding up one of the 256
nproc slots not doing anything useful for quite a bunch of time.

So for now, I've chmodded -x libravatar.cgi on beach and buxtehude, but
we should figure out a better solution.

Cheers,
Julien

Bug#919315: geeqie: Orientation keys ('[' and ']') don't work in latest geeqie release

[Dima Kogan]

Package: geeqie
Version: 1:1.3-1+b1
Severity: normal

Hi. These appear to not work anymore.

With the geeqie in stable (1:1.3-1+b1) I can load any image, press [ and
see the image rotate in response.

With the latest (1:1.4+git20190106-1) when I press '[', the text in the
Exif pane gets a different text label 'Orientation: xxx', but the
displayed image does not change.

Thanks

Bug#919217: Acknowledgement (Missing dependency on devscripts)

[Jeroen Dekkers]

Control: tag -1 +patch

https://salsa.debian.org/jelmer/lintian-brush/merge_requests/1

Bug#919314: nmu: node-leveldown_1.5.0+dfsg-1, node-sqlite3_4.0.2+ds1-1

[Andreas Beckmann]

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

nmu node-leveldown_1.5.0+dfsg-1 . ANY . unstable . -m "Rebuild against 
nodejs-abi-64"
nmu node-sqlite3_4.0.2+ds1-1 . ANY . experimental . -m "Rebuild against 
nodejs-abi-64"

Looks like a small transition is here ongoing ...


Andreas

Bug#919313: ITP: r-cran-ffield -- Force field simulation for a set of points

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: r-cran-ffield
  Version : 0.1.0
* URL : https://cran.r-project.org/web/packages/FField/index.html
* License : GPL-3
  Programming Lang: R
  Description : Force field simulation for a set of points

To be team-maintained at https://salsa.debian.org/r-pkg-team/r-cran-ffield

Bug#919312: ITP: git-secrets -- Prevents you from committing passwords and other sensitive information to a git repository.

[Francois Marier]

Package: wnpp
Severity: wishlist
Owner: Francois Marier 

* Package name: git-secrets
  Version : 1.2.1
  Upstream Author : Michael Dowling 
* URL : https://github.com/awslabs/git-secrets
* License : Apache 2.0
  Programming Lang: Bash
  Description : Prevents you from committing passwords and other sensitive 
information to a git repository.

git-secrets scans commits, commit messages, and --no-ff merges to prevent
adding secrets into your git repositories. If a commit, commit message, or
any commit in a --no-ff merge history matches one of your configured
prohibited regular expression patterns, then the commit is rejected.

Bug#919197: Acknowledgement (qtwayland-opensource-src: FTBFS on hppa - Segmentation faults in testsuite)

[Dmitry Shachnev]

Hi John!

On Sun, Jan 13, 2019 at 05:55:22PM -0500, John David Anglin wrote:
> Actually, it has only been partially optimized away.  It appears the
> check is still there (movb instruction)
> but register r3 contains an undefined value (it is not an argument
> register).  So, this seems a wrong
> code bug.
>
> Why are we building with gcc-7?

The latest hppa build log [1] has gcc 8.2.0.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=qtwayland-opensource-src=hppa=5.11.3-2=1547325647

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#912237: /etc/init.d/rpcbind: stat: not found

[Allan Jensen]

On Mon, 29 Oct 2018 16:20:06 +0100 Laurent Bigonville  wrote:
> Package: rpcbind
> Version: 1.2.5-0.1
> Severity: important
> 
> Hi,
> 
> So according to [0], the LSB initscript fails to start rpcbind because
> it looks for "stat" command that is not in the path, PATH is
> explicitly set to PATH='/sbin:/bin' because it's possible that /usr is
> on a NFS share and rpcbind is needed to mount NFS shares...
> 
> An idea what to do here? The initrd is supposed to mount /usr now I
> believe, so is it now OK to change the PATH to
> "/sbin:/bin:/usr/sbin:/usr/bin"?

How about using ls and grep, which are both in /bin?

Something like

   if [ `ls -dl "$STATEDIR" | grep -cE '^drwxr-xr-x [0-9]+ _rpc root '` -lt 1 ] 
; then

--
Regards
Allan

Bug#892403: starpu-contrib: build-depends on GCC 6

[Samuel Thibault]

Control: tags -1 + pending

Andreas Beckmann, le lun. 14 janv. 2019 17:44:01 +0100, a ecrit:
> On 2019-01-10 01:10, Samuel Thibault wrote:
> > Andreas Beckmann, le jeu. 10 janv. 2019 01:02:19 +0100, a ecrit:
> >> I successfully built the package with the attached patch that switched
> >> to GCC 7, but since the build system is a bit special, I'm not going to
> >> upload this myself.
> > 
> > I'll handle it once CUDA 9.2 is uploaded, yes. Thanks for checking that
> > it'll build.
> 
> CUDA 9.2 is now in a good shape in sid.

Good, uploaded, thanks!

Samuel

Bug#917909: NMU for fribidi 1.0.5-3.1

[Samuel Thibault]

Hugh McMaster, le mer. 09 janv. 2019 22:18:52 +1100, a ecrit:
> I have prepared an NMU for fribidi, fixing bugs 907792 and 917909.

Thanks!

I can confirm that today's daily build has RtL fixed in textmode.

Samuel

Bug#916468: dune: /usr/bin/dune is already provided by the whitedune package

[Paul Gevers]

Hi whitedune maintainers,

On Mon, 7 Jan 2019 14:00:45 +0100 =?UTF-8?Q?St=c3=a9phane_Glondu?=
 wrote:
> reassign 916468 whitedune 0.30.10-2.1
> thanks
> 
> Le 14/12/2018 à 20:24, Andreas Beckmann a écrit :
> > automatic installation tests of packages that share a file and at the
> > same time do not conflict by their package dependency relationships has
> > detected the following problem:
> > 
> >   Selecting previously unselected package dune.
> >   Preparing to unpack .../dune_1.6.2-1_amd64.deb ...
> >   Unpacking dune (1.6.2-1) ...
> >   dpkg: error processing archive 
> > /var/cache/apt/archives/dune_1.6.2-1_amd64.deb (--unpack):
> >trying to overwrite '/usr/bin/dune', which is also in package whitedune 
> > 0.30.10-2.1+b2
> >   Errors were encountered while processing:
> >/var/cache/apt/archives/dune_1.6.2-1_amd64.deb
> > 
> > 
> > This is a serious bug as it makes installation fail, and violates
> > sections 7.6.1 and 10.1 of the policy. An optimal solution would
> > consist in only one of the packages installing that file, and renaming
> > or removing the file in the other package. Depending on the
> > circumstances you might also consider Replace relations or file
> > diversions. If the conflicting situation cannot be resolved then, as a
> > last resort, the two packages have to declare a mutual
> > Conflict. Please take into account that Replaces, Conflicts and
> > diversions should only be used when packages provide different
> > implementations for the same functionality.
> > 
> > Here is a list of files that are known to be shared by both packages
> > (according to the Contents file for sid/amd64, which may be
> > slightly out of sync):
> > 
> >   usr/bin/dune
> >   usr/share/man/man1/dune.1.gz
> 
> As discussed on debian-devel, I propose that the whitedune package drops
>  /usr/bin/dune, which is a symlink to whitedune.

Is anybody against dropping the symlink? If not, I can prepare an upload
to fix this RC bug. This bug affecting my package view3dscene, because I
use whitedunes files in its tests. I could drop the dependency but I'd
rather not.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#919250: RM: qtscriptgenerator -- RoQA; Obsolete, unmaintained, RC buggy

[Scott Kitterman]

On Mon, 14 Jan 2019 00:17:55 -0500 Scott Kitterman  
wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Last maintainer upload was in 2012.  Package has been out of Testing for 15
> months and will not return.  This is an obsolete, unmaintained Qt4 package
> that should be removed.

Sigh.  Amarok needs to go first:

Checking reverse dependencies...
# Broken Depends:
amarok: amarok [amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el 
s390x]

Dependency problem found.

Scott K

Bug#919289: [Pkg-kde-extras] Bug#919289: kile: After upgrade, kile will not open until okular installed

[Pino Toscano]

Hi,

In data lunedì 14 gennaio 2019 16:21:33 CET, D Haley ha scritto:
> Package: kile
> Version: 4:2.9.92-1
> Severity: normal
> 
> Dear Maintainer,
> 
> After upgrading kile from 4:2.1.3-4+b1 to 4:2.9.92-1, kile would not
> open, giving an error along the lines of missing libokular. Okular was
> installed on my system, but was an older version. I suspect there is a
> missing depends on libokular5core8, or something along these lines

What is the exact error you saw?

> -- System Information:
> Debian Release: 9.6
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'testing')

Which kind of system is this?

> Versions of packages kile depends on:
> ii  kinit  5.51.0-2
> ii  kio5.51.0-1
> ii  konsole-kpart  4:18.04.0-1
> ii  libc6  2.28-2
> ii  libgcc11:6.3.0-18+deb9u1
> ii  libkf5codecs5  5.28.0-1+b2
> ii  libkf5completion5  5.28.0-1
> ii  libkf5configcore5  5.28.0-2
> ii  libkf5configgui5   5.28.0-2
> ii  libkf5configwidgets5   5.28.0-2
> ii  libkf5coreaddons5  5.28.0-2
> ii  libkf5dbusaddons5  5.28.0-1
> ii  libkf5guiaddons5   5.28.0-1
> ii  libkf5i18n55.28.0-2
> ii  libkf5iconthemes5  5.51.0-1
> ii  libkf5jobwidgets5  5.28.0-2
> ii  libkf5khtml5   5.51.0-1
> ii  libkf5kiocore5 5.51.0-1
> ii  libkf5kiofilewidgets5  5.51.0-1
> ii  libkf5kiowidgets5  5.51.0-1
> ii  libkf5parts5   5.51.0-1
> ii  libkf5service-bin  5.51.0-1
> ii  libkf5service5 5.51.0-1
> ii  libkf5texteditor5  5.51.0-3
> ii  libkf5textwidgets5 5.51.0-1
> ii  libkf5widgetsaddons5   5.28.0-3
> ii  libkf5windowsystem55.28.0-2
> ii  libkf5xmlgui5  5.51.0-1+b1
> ii  libpoppler-qt5-1   0.71.0-2
> ii  libqt5core5a   5.11.3+dfsg-2
> ii  libqt5dbus55.11.3+dfsg-2
> ii  libqt5gui5 5.11.3+dfsg-2
> ii  libqt5script5  5.11.3+dfsg-2
> ii  libqt5widgets5 5.11.3+dfsg-2
> ii  libqt5xml5 5.11.3+dfsg-2
> ii  libstdc++6 8.2.0-14
> ii  perl   5.24.1-3+deb9u4
> ii  texlive-latex-base 2016.20170123-5

You have a mixup of stable and testing/unstable.  This situation is not
supported.

-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1

[Axel Beckert]

Hi Diane,

Diane Trout wrote:
> Was dnssec-triggerd running before the upgrade?

I think so.

> Was there then an
> upgrade to openssl 1.1.1? and then finally it wouldn't start?

That one was much earlier IIRC, like weeks ago.

Anyway, I've now got a second machine with the same symptoms, just now
with sysvinit instead of systemd:

Setting up dnssec-trigger (0.17+repack-1) ...
Installing new version of config file 
/etc/NetworkManager/dispatcher.d/01-dnssec-trigger ...

Configuration file '/etc/dnssec-trigger/dnssec-trigger.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** dnssec-trigger.conf (Y/I/N/O/D/Z) [default=N] ? d
--- /etc/dnssec-trigger/dnssec-trigger.conf 2017-01-15 19:10:09.588308480 
+0100
+++ /etc/dnssec-trigger/dnssec-trigger.conf.dpkg-new2019-01-13 
22:10:28.0 +0100
@@ -22,12 +22,10 @@

 # the domain example.com line (if any) to add to resolv.conf(5). default none.
 # domain: ""
-domain: deuxchevaux.org

 # domain name search path to add to resolv.conf(5). default none.
 # the search path from DHCP is not picked up, it could be used to misdirect.
 # search: ""
-search: kub.deuxchevaux.org deuxchevaux.org noone.org debian.org ethz.ch 
lugs.ch

 # the command to run to open login pages on hot spots, a web browser.
 # empty string runs no command.
@@ -50,7 +48,7 @@
 # control-cert-file: "/etc/dnssec-trigger/dnssec_trigger_control.pem"

 # check for updates, download and ask to install them (for Windows, OSX).
-# check-updates:
+# check-updates: no

 # webservers that are probed to see if internet access is possible.
 # They serve a simple static page over HTTP port 80.  It probes a random url:
@@ -65,6 +63,7 @@
 url: "http://fedoraproject.org/static/hotspot.txt OK"

 # fallback open DNSSEC resolvers that run on TCP port 80 and TCP port 443.
+# These relay incoming DNS traffic on the other port numbers to the usual DNS
 # the ssl443 adds an ssl server IP, you may also specify one or more hashes
 # the following on one line: ssl443:{}
 # hash is output of openssl x509 -sha256 -fingerprint -in server.pem
@@ -77,3 +76,12 @@
 ssl443: 185.49.140.67 
7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF
 ssl443: 2a04:b900::10:0:0:67 
7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF

+# Use VPN servers for all traffic
+# use-vpn-forwarders: no
+
+# Forward RFC 1918 private addresses to global forwarders
+# use-private-addresses: yes
+
+# Add domains provided by VPN connections into Unbound forward zones
+# add-wifi-provided-zones: no
+

Configuration file '/etc/dnssec-trigger/dnssec-trigger.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** dnssec-trigger.conf (Y/I/N/O/D/Z) [default=N] ? n
[] Restarting : dnssec-triggerdJan 14 21:10:59 dnssec-triggerd[12444] 
error: Error for server-cert-file: /etc/dnssec-trigger/dnssec_trigger_server.pem
Jan 14 21:10:59 dnssec-triggerd[12444] error: Error in SSL_CTX 
use_certificate_file crypto error:140AB18F:SSL 
routines:SSL_CTX_use_certificate:ee key too small
Jan 14 21:10:59 dnssec-triggerd[12444] error: cannot setup SSL context
Jan 14 21:10:59 dnssec-triggerd[12444] fatal error: could not init server
 failed!

On this machine, OpenSSL 1.1.1 was installed in August 2018, i.e.
about half a year ago.
 
> The error message looks like your openssl keys are too small and all
> attempts to control dnssec-triggerd will fail. I modified dnssec-
> trigger-control-setup to check the key size and delete it if it was too
> small. Did the certificates in /etc/dnssec-trigger get regenerated?

Clearly not. They're from 2016 (on the second machine, the other one
is currently sleeping in my backpack):

/etc/dnssec-trigger # ls -l
total 36
-rw-r--r-- 1 root root 3115 Jan 15  2017 dnssec-trigger.conf
-rw-r--r-- 1 root root 3338 Jan 13 22:10 dnssec-trigger.conf.dpkg-dist
-rw-r--r-- 1 root root 3095 Oct  4  2016 dnssec-trigger.conf~
-rw-r--r-- 1 root root 4640 Dec 20  2016 dnssec.conf
-rw-r--r-- 1 root root 1277 May 28  2016 dnssec_trigger_control.key
-rw-r--r-- 1 root root  822 May 28  2016 dnssec_trigger_control.pem
-rw-r- 1 root root 1277 May 28  2016 dnssec_trigger_server.key