Bug#863859: apt: runs unattended-upgrades in debug mode

[Raphaël Halimi]

Package: apt
Version: 1.4.2

Since a few days, my Stretch machine sends an additional daily e-mail
with cron output from unattended-upgrades.

It seems related to a change introduced in 1.4.2:

* Run unattended-upgrade -d in download part

...which dates from May 04 according to the changelog, but hit Stretch
only recently (on this machine apt was upgraded on May 27 according to
apt logs).

This is really annoying. Cron jobs are not supposed to output anything
unless there was an error. Now i receive three daily e-mails regarding
unattended upgrades: one from apt-listchanges (ok), one from
unattended-upgrades itself (ok, I enabled this in the config myself),
and one from anacron (not ok, if the upgrade ran without error, cron
shouldn't report anything).

It would be nice to revert this change before Stretch is released.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#863858: draft fix

[dann frazier]

Here's an initial proposal for a fix:
  https://git.launchpad.net/~dannf/+git/makedumpfile/commit/?h=grubcfg

If we decide to go this direction, we'll probably need to implement an
upgrade path from symlink-to-non-symlink mode. But, I'll wait for
feedback on the overall approach before spending time on that.

  -dann

Bug#863858: issues with grub config symlinks

[dann frazier]

Package: kdump-tools
Version: 1:1.6.1-1
Severity: normal

In 1.5.9-6, a facility was added to make /etc/default/grub.d/kdump-tools.cfg a
symlink, pointing to an appropriate architecture-specific config, with
ppc64el as the initial user. There are a couple of issues with this:

  - It doesn't work on ppc64el today. Reason being that the postinst
uses the "arch" command to ID the architecture. That returns the
kernel arch name (ppc64*le*), not the Debian port name
(ppc64*el*), so the intended symlink is not created.
  - This method requires that we install all of the arch-specific
configs on every arch, even though they aren't needed.

I wonder if we could simplify this by doing the default config file
selection at build time instead of installtime. That should still solve
preserve the behavior of dpkg only considering the file to be modified
if the user manually edited it.

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

Kernel: Linux 4.11.0-trunk-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)

Versions of packages kdump-tools depends on:
ii  bsdmainutils   9.0.12+nmu1
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  kexec-tools1:2.0.14-1
ii  lsb-base   9.20161125
ii  makedumpfile   1:1.6.1-1

kdump-tools recommends no packages.

kdump-tools suggests no packages.

-- Configuration Files:
/etc/default/kdump-tools changed [not included]

-- debconf information:
* kdump-tools/use_kdump: false

Bug#863857: $PIDFILE unset, so writes to a file called /-g

[積丹尼 Dan Jacobson]

Package: ntp
Version: 1:4.2.8p10+dfsg-3+exp2
Severity: important
File: /usr/lib/ntp/ntp-systemd-wrapper

Because $PIDFILE is never set, you end up writing the PIDFILE to a file
called "/-g" in the root file system.

By the way stopping the deamon does not remove the PIDFILE either,
thus your next version should clean the stray /-g file off the users'
systems lest it be left there forever.

Bug#863260: kstart: k5start does not recognize network changes

[Benjamin Kaduk]

On Wed, May 24, 2017 at 11:44:12AM -0700, Russ Allbery wrote:
> 
> Kai Wohlfahrt  writes:
> 
> > Package: kstart
> > Version: 4.2-1
> > Severity: important
> > Tags: upstream
> 
> > Dear Maintainer,
> 
> > The k5start program repeats attempts to contact the KDC server if it is
> > unavailable. However, it continues to fail if a new network is
> > available.
> 
> > Steps to reproduce:
> > - Disable network interface
> > - Run k5start (e.g. k5start -f /etc/krb5.keytab -K 10 -u host/jason -k 
> > test.tkt)
> > - Enable network interface
> 
> > I expect to see the error below repeated until the network comes back
> > up, and then it should stop:
> 
> > k5start: error getting credentials: Cannot contact any KDC for realm 
> > 'MY.REALM.NAME'
> 
> > Instead, I continue to get errors until I stop the k5start
> > process. Starting it again after the network is available shows no
> > errors and gets the ticket correctly.
> 
> k5start just calls krb5_get_init_creds_*, so if something is being
> inappropriately cached, this would be a bug in the underlying Kerberos
> library (rather than in kstart).  Reassigning accordingly.

I could not reproduce this behavior using any of 'ifconfig 
down', adding loopback routes to all configured KDCs, or modifying
the profile (KRB5_CONFIG pointing to a custom path) to use
inaccessible KDC addresses as a way of making the KDC inaccessible.
The 'ifconfig  down' method requires manual intervention to
restore a default route after bringing the interface back up,
though.

(Code inspection also did not find a place where such caching would
occur, though of course there are probably some places I didn't
look.)

Kai, can you confirm that you can reproduce and that have proper
network connectivity (DNS resolution, ping, etc.) during the case
where k5start continues to be unable to contact any KDCs?

Also, is krb5.conf or DNS being used to locate KDCs (not that this
appears to matter).

-Ben

Bug#863856: getmail4: please use run-parts --list or similar to enumerate the config files in ~/.getmail/config/

[Scott Barker]

Package: getmail4
Version: 4.53.0-1
Severity: wishlist

The getmails script considers every file in ~/.getmail/config/ to be a valid
config file, including any backup files from editors like vim, emacs, etc.

To avoid this, please consider using "run-parts --list $HOME/.getmail/config/"
to enumerate the config files, instead of "for file in $HOME/.getmail/config/*"

Thank you.

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#863855: nautilus: Nautilus doesn't extract files with .xz extension

[Klebson Porfirio]

Package: nautilus
Version: 3.22.3-1
Severity: normal
Tags: upstream

Dear Maintainer,

I was trying to extract a compressed ISO image from FreeBSD with
Nautilus right
click "extract here" menu and it's not possible. The message is
displayed:
There was an error extracting "FreeBSD-11.0-RELEASE-amd64-
disc1.iso.xz". And
box:

'FreeBSD-11.0-RELEASE-amd64-disc1.iso.xz': Ignoring out-of-order file
@5fcbc
(usr/sbin/chown) 141887488 < 567750656

But when I open the terminal and type the command

$ xz -d FreeBSD-11.0-RELEASE-amd64-disc1.iso.xz

Everything works perfectly and the extracted image is consistent with
hash.



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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.23-1
ii  gsettings-desktop-schemas  3.22.0-1
ii  gvfs   1.30.4-1
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-10
ii  libcairo-gobject2  1.14.8-1
ii  libcairo2  1.14.8-1
ii  libexempi3 2.4.1-1
ii  libexif12  0.6.21-2+b2
ii  libgail-3-03.22.11-1
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libglib2.0-0   2.50.3-2
ii  libglib2.0-data2.50.3-2
ii  libgnome-autoar-0-00.1.1-4+b1
ii  libgnome-desktop-3-12  3.22.2-1
ii  libgtk-3-0 3.22.11-1
ii  libnautilus-extension1a3.22.3-1
ii  libpango-1.0-0 1.40.5-1
ii  libselinux12.6-3+b1
ii  libtracker-sparql-1.0-01.10.5-1
ii  libx11-6   2:1.6.4-3
ii  nautilus-data  3.22.3-1
ii  shared-mime-info   1.8-1

Versions of packages nautilus recommends:
ii  gnome-sushi  3.21.91-2
ii  gvfs-backends1.30.4-1
ii  librsvg2-common  2.40.16-1+b1

Versions of packages nautilus suggests:
ii  brasero  3.12.1-4
ii  eog  3.20.5-1+b1
ii  evince [pdf-viewer]  3.22.1-3
ii  nautilus-sendto  3.8.4-2+b1
ii  totem3.22.1-1
ii  tracker  1.10.5-1
ii  vlc [mp3-decoder]1:2.2.6-dmo2
ii  xdg-user-dirs0.15-2+b1

Bug#751993: upload?

[Vincent McIntyre]

Hi

there have been a couple of stable point releases (8.7,8.8) since
this and #799781 were tagged as pending, but they haven't made it in.
Could you check what's up please?

Vince

Bug#821806: ksh does not export symbols to loaded "built-in" modules

[tetsujin]

I think I've somewhat misunderstood the issue. --export-dynamic
appears to not truly be necessary, and when building from upstream
sources the build now includes a few sample loadable modules.

When building the upstream source (the "master" branch of
https://github.com/att/ast, which is still identified as 93u+
2012-08-01) using its own build script ("bin/package make"), ksh is
not linked with --export-dynamic (I don't quite understand how its
loadable modules work without ksh being linked --export-dynamic), but
it does build the sample loadable modules that are included with the
distribution (including "open.c" which I used as an example in the bug
report) - and that build of Korn Shell will be able to load and run
those modules:

$ ./bin/package make   # And then wait a while for it to build...
$ ./arch/linux.i386-64/bin/ksh --version    # Copy I built from Git
  version sh (AT Research) 93u+ 2012-08-01
$ ./arch/linux.i386-64/bin/ksh
$ builtin -f arch/linux.i386-64/lib/ksh/libopen.so open
$ open   # Runs the builtin from libopen.so
Usage: open [-abcirwx] [-m mode] var file

But loading this module from the version from Debian
(93u+20120801-2+b1) fails:

$ ksh --version   # Installed copy
  version sh (AT Research) 93u+ 2012-08-01
$ ksh
$ builtin -f arch/linux.i386-64/lib/ksh/libopen.so open    #
Loading the libopen.so built from git
builtin: arch/linux.i386-64/lib/ksh/libopen.so: libshell.so: cannot
open shared object file: No such file or directory

If I download the Debian ksh source package and build it, and try
that, I get a similar failure. I'm not entirely sure why it works on
the one from upstream (with no --export-dynamic) or why it doesn't
work on the packaged one (which describes itself as the same version
from the package...)

So it's hard for me to gauge exactly what's going on here:
- The installed copy of "ksh" is stripped, and stripping "ksh"
apparently makes it incompatible with modules built from a
non-stripped build. (I don't know if stripping ksh makes it
incompatible with modules entirely...)
- I also rebuilt ksh in the Debian package source tree without using
the Debian build rules, yielding an unstripped 93u+ with Debian
patches. This was also incompatible with the loadable module built
from git.
- I attempted to manually build libopen.so in the Debian build tree,
using compile and link commands from another successful build, and
that also didn't work, so I can't determine if the feature really was
broken on that version, and has since been fixed, or if it's just a
build issue.

The upshot is that it's pretty easy to get a working demonstration of
this feature from the upstream copy in git now. I'll see if I can
figure out why it's still not working with the packaged version.

Bug#863491: Spams the journal with debug messages

[Jason Crain]

Control: forwarded -1 https://github.com/gnunn1/tilix/pull/951

On Mon, May 29, 2017 at 06:54:56PM -0500, Jason Crain wrote:
> I think changing this line to ": ${DCFLAGS='-O'}" would work better.  It
> will set DCFLAGS only if it is not already set.

Pull request submitted upstream.

Bug#863642: [Pkg-xfce-devel] Bug#863642: Thunar shows all fstab entries in devices in the Shortcuts Side Pane

[bakhelit]

Looked at it again, and I also cannot reproduce showing devices on 
desktop - probably because only root Thunar shows the fstab entries in 
DEVICES in the Shortcuts Side Pane. On my current testing system 
(installed from Stretch RC3 installer but fully updated) root Thunar 
shows in DEVICES (when no USB, network or other devices are connected):


File System (this is ok -> non-root Thunar shows only this entry)
Filesystem root (this is LVM for "/" with BTRFS)
boot (this is BTRFS partition for boot which I can even unmount:)

When I had a separate LVM for "/home" it was shown also as "home" in 
root Thunar DEVICES (at that time EXT4 was used instead of BTRFS). 
Current partitions on my test system are: sda1 (BTRFS boot), sda2_crypt 
(ENCRYPTED LVM for SWAP and "/" with BTRFS). If libglib2.0-0 is 
installed from stable (version 2.42.1-1) both root and non-root Thunar 
show just the "File System" entry in DEVICES in the Shortcuts Side Pane.

Bug#851933: udev: /lib/udev/hwdb.bin gets wrong SE Linux label

[Michael Biebl]

Control: clone -1 -2
Control: reassign -2 libselinux1
Control: found -2 2.6-3
Control: retitle -2 selabel_lookup_raw() doesn't find correct context for  
"//lib/udev/hwdb.bin"

Am 01.06.2017 um 00:34 schrieb Michael Biebl:

> This path is passed to mac_selinux_fix() in
> https://github.com/systemd/systemd/blob/master/src/basic/selinux-util.c#L122
> 
> I supposed either selabel_lookup_raw() or lsetfilecon_raw() doesn't
> properly deal with the double //.

Apparently it's selabel_lookup_raw() which doesn't handle the double slash 
gracefully

Using selabel_lookup_raw(label_hnd, , path, st.st_mode);

and path being set to "//lib/udev/hwdb.bin", fcon contains 
"system_u:object_r:default_t:s0".

I'm cloning this bug report for libselinux1.

We can work around this in systemd, but I'm convinced selabel_lookup_raw() 
should deal with such paths more robustly.

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#863838: unblock: debian-edu-install/1.926

[Cyril Brulebois]

Holger Levsen  (2017-05-31):
> Please unblock package debian-edu-install, it only contains a trivial
> update in preparation of the Debian Edu Stretch release.
> 
> Please note that it also contains an (unmodified) udeb, thus cc:ing KiBi
> for the famous KiBi-ack! :)

I'm not sure why we're still having this hardcoded list of versions.


KiBi.


signature.asc
Description: Digital signature

Bug#863853: libdpkg-perl: Cannot install the package. getting this error: cannot copy extracted data for './usr/share/doc/libdpkg-perl/changelog.gz' to '/usr/share/doc/libdpkg-perl/changelog.gz.dpkg-n

[Dmitrii]

Package: libdpkg-perl
Version: 1.18.24
Severity: important

Dear Maintainer,

Current package cannot be installed due to some problem with
an unexpected end of file or a stream.

Thank you.


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

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

Bug#800072: Asks to phone home - Consider patching this out?

[pipatron]

On Sat, 26 Sep 2015 13:56:00 +0200 Didier 'OdyX' Raboud  wrote:
> Package: vym
> Version: 2.4.8-1
> Severity: wishlist
> 
> Hi,
> 
> I've just re-launched vym today after some months, and was surprised
to be met
> with a request to enable a "phone home" functionality. Although I can
> sympathize with the reasons leading to this functionality, I think
it'd be
> better to have it opt-in, from a menu option, not really as an
upfront pop-up.
> 
> What do you think?

I would very much like to see this. Such a request does *not* play well
with free software, IMO. Imagine if every program you installed in
debian had one.

Bug#863852: rename: manpage of rename does not document bare double dash ("--")

[Max-Julian Pogner]

Package: rename
Version: 0.20-4
Severity: minor

Dear Maintainer,

   * What led up to the situation?

writing a shell script which possibly deals with filenames starting with "-"


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

I looked at `man rename`.
Then i experimented and think, that rename indeed does support double-dash.


   * What was the outcome of this action?

undocumented use of bare double dash.


   * What outcome did you expect instead?

i hope that one day bare double dash will be considered standard
implementation for command line programs.



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

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

Versions of packages rename depends on:
ii  perl  5.20.2-3+deb8u6

rename recommends no packages.

rename suggests no packages.

-- no debconf information

Bug#863851: xfce4-terminal: command and execute options do not work

[Ben Caradoc-Davies]

Package: xfce4-terminal
Version: 0.8.4-1
Severity: normal

Dear Maintainer,

the command and execute options have no effect. Invoking either:

xfce4-terminal -H -c ls
xfce4-terminal -H -e ls

results in a blank held terminal window. Without -H the terminal does not even 
appear, but this is expected as a short-running command may exit before the 
window can be created.

The corresponding xterm command works just fine:

xterm -hold -e ls

Kind regards,
Ben.

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

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

Versions of packages xfce4-terminal depends on:
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-11
ii  libcairo2   1.14.8-1
ii  libgdk-pixbuf2.0-0  2.36.5-2
ii  libglib2.0-02.50.3-2
ii  libgtk-3-0  3.22.12-1
ii  libpango-1.0-0  1.40.5-1
ii  libvte-2.91-0   0.46.1-1
ii  libx11-62:1.6.4-3
ii  libxfce4ui-2-0  4.12.1-2
ii  libxfce4util7   4.12.1-3

Versions of packages xfce4-terminal recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.10.18-1
ii  dbus-x11 [dbus-session-bus]   1.10.18-1

xfce4-terminal suggests no packages.

-- no debconf information

Bug#863850: systemd service file does not stop systemd-based containers

[JD Friedrikson]

Package: lxc
Version: 1:2.0.7-2

Hello,

Debian's packaged version of LXC currently is not able to stop systemd-based 
containers as they have not responded to SIGPWR as of 
https://github.com/lxc/lxc/commit/8eb62c245e9b67b451ba0766f3ecd7c6f2081d73 .

The appropriate way to stop systemd via a signal is to use SIGRTMIN+3 (or, I 
think, SIGRTMIN+4). The lxc-stop binary automatically determines whether the 
container will respond to this signal and handles it appropriately. Therefore, 
we should use that binary with ExecStop instead of using a signal (in the 
service file).

This has already been fixed upstream:

https://github.com/lxc/lxc/commit/c08d29b6d134fbb94d2cff0454ce27eb66930c4d

It would be cool if we could package this fix before the release. Here's a 
patch:

"""

diff --git a/config/init/systemd/l...@.service.in 
b/config/init/systemd/l...@.service.in
index 44d11e8e..a2aa2211 100644
--- a/config/init/systemd/l...@.service.in
+++ b/config/init/systemd/l...@.service.in
@@ -8,9 +8,9 @@ Documentation=man:lxc-start man:lxc
[Service]
Type=simple
KillMode=mixed
-KillSignal=SIGPWR
TimeoutStopSec=120s
ExecStart=@BINDIR@/lxc-start -F -n %i
+ExecStop=@BINDIR@/lxc-stop -n %i
# Environment=BOOTUP=serial
# Environment=CONSOLETYPE=serial
Delegate=yes
--
2.13.0

"""

Please let me know if you need anything more from me.

Cheers,
JD

Bug#851933: udev: /lib/udev/hwdb.bin gets wrong SE Linux label

[Michael Biebl]

Am 01.06.2017 um 00:53 schrieb Michael Biebl:

> Am 01.06.2017 um 00:34 schrieb Michael Biebl:

>> The result is //lib/udev/hwdb.bin, note the double //
> 
> Fwiw, we could stick a
> path_kill_slashes(hwdb_bin);
> after the strjoin like in the attached patch.

Hm, using path_join() might be even nicer (assuming arg_hwdb_bin_dir
itself doesn't contain any double slashes, which is probably a safe
assumption).

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/src/hwdb/hwdb.c b/src/hwdb/hwdb.c
index a9539c812..793398ca6 100644
--- a/src/hwdb/hwdb.c
+++ b/src/hwdb/hwdb.c
@@ -31,6 +31,7 @@
 #include "hwdb-util.h"
 #include "label.h"
 #include "mkdir.h"
+#include "path-util.h"
 #include "selinux-util.h"
 #include "strbuf.h"
 #include "string-util.h"
@@ -670,7 +671,7 @@ static int hwdb_update(int argc, char *argv[], void *userdata) {
 log_debug("strings dedup'ed: %8zu bytes (%8zu)",
   trie->strings->dedup_len, trie->strings->dedup_count);
 
-hwdb_bin = strjoin(arg_root, "/", arg_hwdb_bin_dir, "/hwdb.bin");
+hwdb_bin = path_join(arg_root, arg_hwdb_bin_dir, "hwdb.bin");
 if (!hwdb_bin)
 return -ENOMEM;
 


signature.asc
Description: OpenPGP digital signature

Bug#811162: [Dms-maintainers] Bug#811162: Upgrade to PostgreSQL 9.5

[Matt Grant]

Finally a Pong!

Rewrote the scripts and DB configuration in DMS to get rid of some old bad
postgresql.conf hacks.  Repackaging now.  Should be able to easily upgrade.

Regards,

Matt

On Sat, Mar 19, 2016 at 12:55 AM, Christoph Berg  wrote:

> Re: To Debian Bug Tracking System 2016-01-16 <20160116093745.GA20861@msg.
> df7cb.de>
> > Package: dms-core
> > Version: 1.0.3-2
> > Severity: serious
> >
> > Hi,
> >
> > PostgreSQL in unstable has been upgraded to 9.5, please upgrade the
> > dependency of dms-core to postgresql-9.5.
> >
> > (This is #756352 reloaded. I'd still suggest to look into if just
> > "Depends: postgresql" wouldn't do what you want. The old 9.4 dms
> > cluster won't disappear on the version upgrade, and "pg_upgradecluster
> > 9.4 dms" (or whatever it is called) will upgrade all user data
> > transparently, i.e. the upgraded cluster will use the same port,
> > pg_hba.conf etc as the old one.)
>
> Ping?
>
> Christoph
> --
> c...@df7cb.de | http://www.df7cb.de/
>
> ___
> Dms-maintainers mailing list
> dms-maintain...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/dms-maintainers
>

Bug#863846: xen-tools: Fails to reload dnsmasq under systemd

[Axel Beckert]

Hi Daniel,

Daniel Gnoutcheff wrote:
> /usr/share/xen-tools/common/50-setup-hostname-deb is supposed to reload
> dnsmasq (if installed and running) after adding a line to /etc/hosts.
> However, this does not happen on my stretch system, and dnsmasq doesn't
> pick up these entries until I reload it manually.
> 
> I suspect this is because setup-hostname-deb hardcodes the wrong pidfile
> path:
> 
> > if [ -e /var/run/dnsmasq.pid ]; then
> > 
> > logMessage Allowing DNSMasq to restart.
> > kill -s HUP `cat /var/run/dnsmasq.pid`
> > fi
> 
> The correct path seems to be /run/dnsmasq/dnsmasq.pid.

Thanks for the bug report.

Since these snippets should be rather generic I wonder if should be
replaced with something like this:

for pidfile in {,/var}/run/{,dnsmasq/}dnsmasq.pid; do
if [ -e $pidfile ]; then
logMessage Trying to restart DNSMasq via $pidfile.
kill -s HUP `cat $pidfile`
fi
done

(bash-syntax, the final script should be POSIX compatible, hence no
curly brace expansion possible.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#851933: udev: /lib/udev/hwdb.bin gets wrong SE Linux label

[Michael Biebl]

Am 01.06.2017 um 00:34 schrieb Michael Biebl:

> https://github.com/systemd/systemd/blob/master/src/hwdb/hwdb.c#L673
> This computes the path to the cache file:
> hwdb_bin = strjoin(arg_root, "/", arg_hwdb_bin_dir, "/hwdb.bin");
> 
> The result is //lib/udev/hwdb.bin, note the double //

Fwiw, we could stick a
path_kill_slashes(hwdb_bin);
after the strjoin like in the attached patch.

But...

> Afaics, this looks like a libselinux bug to me. It should properly deal
> with paths that have double //.

I think this still applies. libselinux/the selinux policy should deal
with that fact that a path with double slashes is passed on.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/src/hwdb/hwdb.c b/src/hwdb/hwdb.c
index a9539c812..e52e13b06 100644
--- a/src/hwdb/hwdb.c
+++ b/src/hwdb/hwdb.c
@@ -31,6 +31,7 @@
 #include "hwdb-util.h"
 #include "label.h"
 #include "mkdir.h"
+#include "path-util.h"
 #include "selinux-util.h"
 #include "strbuf.h"
 #include "string-util.h"
@@ -673,6 +674,7 @@ static int hwdb_update(int argc, char *argv[], void *userdata) {
 hwdb_bin = strjoin(arg_root, "/", arg_hwdb_bin_dir, "/hwdb.bin");
 if (!hwdb_bin)
 return -ENOMEM;
+path_kill_slashes(hwdb_bin);
 
 mkdir_parents_label(hwdb_bin, 0755);
 r = trie_store(trie, hwdb_bin);


signature.asc
Description: OpenPGP digital signature

Bug#851933: udev: /lib/udev/hwdb.bin gets wrong SE Linux label

[Michael Biebl]

Am 31.05.2017 um 19:32 schrieb Michael Biebl:
> The selinux context should be set by label_fix:
> https://github.com/systemd/systemd/blob/master/src/hwdb/hwdb.c#L682
> 
> I haven't debugged yet, why that doesn't work for --usr.

I have a better picture now what's going on/wrong:

https://github.com/systemd/systemd/blob/master/src/hwdb/hwdb.c#L673
This computes the path to the cache file:
hwdb_bin = strjoin(arg_root, "/", arg_hwdb_bin_dir, "/hwdb.bin");

The result is //lib/udev/hwdb.bin, note the double //

This path is passed to mac_selinux_fix() in
https://github.com/systemd/systemd/blob/master/src/basic/selinux-util.c#L122

I supposed either selabel_lookup_raw() or lsetfilecon_raw() doesn't
properly deal with the double //.

If I change the strjoin to omit the "/", the context is applied correctly.

Afaics, this looks like a libselinux bug to me. It should properly deal
with paths that have double //.

Laurent, Russel, should we reassign this to libselinux?

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#852962: ycmd FTBFS on mipsel: test failures

[Christoph Biedl]

Julien Cristau wrote...

> On Wed, Feb  1, 2017 at 10:49:34 +0100, Emilio Pozuelo Monfort wrote:
>
> > Somehow this has built now:
> >
> > https://buildd.debian.org/status/logs.php?pkg=ycmd=0%2B20161219%2Bgit486b809-1=mipsel
> >
> > Let's downgrade for now.
> >
> Next upload failed again, somebody needs to look at this.

Did so, but failed to reproduce the issue on the mipsel porter box.
However, the bug seems to manifest when building in a qemu-static
chroot. In that scenario however, diagnostic tools like strace
fail.

Updates will follow as I get them.

Christop


signature.asc
Description: Digital signature

Bug#863843: bugs.debian.org: Encrypted partition not accessible after resume

[Ben Hutchings]

Control: tag -1 moreinfo

On Wed, 31 May 2017 21:34:59 +0200 Garjola Dindi 
wrote:
[...]
> For several weeks now I have been having issues after resume (both
from RAM or from disk): my /home seems not to be accessible (at least
for writing). This does not happen every time, but more something like
once every 10 or 20 resume cycles.
[...]

Please send the messages that appear in the kernel log when you resume.
(Run 'dmesg' as root to show the kernel log.)

Ben.

-- 
Ben Hutchings
Lowery's Law:
    If it jams, force it. If it breaks, it needed replacing anyway.



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

Bug#863849: davmail: Please include headless jre packages as dependencies

[Scott Barker]

Package: davmail
Version: 4.7.3.2438-2
Severity: wishlist

It is possible to run davmail completely headless, for example on a
standalone server. Please consider including the headless java runtime
packages in the Depends header. For example:

  default-jre | java6-runtime | java7-runtime | java8-runtime | 
default-jre-headless | java6-runtime-headless | java7-runtime-headless | 
java8-runtime-headless

Thank you.

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages davmail depends on:
pn  libswt-cairo-gtk-3-jni | libswt-cairo-gtk-3.5-jni
pn  libswt-gtk-3-java | libswt-gtk-3.6-java | libswt-gtk-3.5-java | lib  
pn  openjdk-7-jre | openjdk-6-jre | oracle-java7-jre | sun-java6-jre 

davmail recommends no packages.

davmail suggests no packages.

Bug#626217: Re: Bug

[tm hck]

Bug#863847: gnumeric: CPU hog

[Kingsley G. Morse Jr.]

Package: gnumeric
Version: 1.12.32-1+b1
Severity: normal

Hi Dmitry,

Thank you very much for maintaining Debian's
gnumeric package.

I like it!

Disclaimer: This is a long and inconclusive bug
report.

So,
Kingsley

   * What led up to the situation?

 Maybe 
 
copying sheets between workbooks,

sorting,

using mismatched versions of packages from
Debian's unstable distribution, or

my cursed good looks.


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

 I dunno.


   * What was the outcome of this action?


 The "top" command said gnumeric was using
 100% of CPU.

 (Plus, sorting started failing for me a few
 weeks ago.)


 The "sar" command said over half was for
 "%user".


strace didn't help.

$ strace -c -p 11579

% time seconds  usecs/call callserrors syscall
-- --- --- - - 
  0.000.00   043   writev
  0.000.00   0   128   poll
  0.000.00   08987 recvmsg
-- --- --- - - 
100.000.00   26087 total


gdb reported 

kingsley$ gdb --q --n --ex bt --batch --pid 11579

[New LWP 11583]
[New LWP 11581]
[New LWP 11580]
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/i386-linux-gnu/libthread_db.so.1".
0xb616521c in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#0  0xb616521c in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#1  0xb6160559 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#2  0xb61656dc in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#3  0xb61a2266 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#4  0xb613fe57 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#5  0xb61bf013 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#6  0xb618e0ab in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#7  0xb6149082 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#8  0xb61418e6 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#9  0xb6139fdc in cairo_stroke_preserve () from 
/usr/lib/i386-linux-gnu/libcairo.so.2
#10 0xb741343c in ?? () from /usr/lib/libspreadsheet-1.12.32.so
#11 0xb71d6aa8 in ?? () from /usr/lib/libgoffice-0.10.so.10
#12 0xb71d6a93 in ?? () from /usr/lib/libgoffice-0.10.so.10
#13 0xb71d290c in ?? () from /usr/lib/libgoffice-0.10.so.10
#14 0xb6d066d4 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#15 0xb6ad1cdb in gtk_container_propagate_draw () from 
/usr/lib/i386-linux-gnu/libgtk-3.so.0
#16 0xb6ad1dae in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#17 0xb6b5b87e in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#18 0xb6ad73e5 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#19 0xb6adcc62 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#20 0xb6b5c802 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#21 0xb6d066d4 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#22 0xb6ad1cdb in gtk_container_propagate_draw () from 
/usr/lib/i386-linux-gnu/libgtk-3.so.0
#23 0xb6bce63c in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#24 0xb6ad73e5 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#25 0xb6adcc62 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#26 0xb6a852d7 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#27 0xb6adcc62 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#28 0xb6bd0eec in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#29 0xb6d066d4 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#30 0xb6ad1cdb in gtk_container_propagate_draw () from 
/usr/lib/i386-linux-gnu/libgtk-3.so.0
#31 0xb6ad1dae in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#32 0xb6a80d0e in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#33 0xb6ad73e5 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#34 0xb6adcc62 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#35 0xb6a83832 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#36 0xb6d066d4 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#37 0xb6ad1cdb in gtk_container_propagate_draw () from 
/usr/lib/i386-linux-gnu/libgtk-3.so.0
#38 0xb6ad1dae in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#39 0xb6a80d0e in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0

Bug#863848: swig: New upstream release

[Sylvestre Ledru]

Package: swig
Severity: wishlist

Hello,

Could you please package 3.0.11, or, better 3.0.12 ?
This is now mandatory for some packages like lldb.

Thanks,
Sylvestre


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages swig depends on:
ii  swig3.0  3.0.10-1.1

swig recommends no packages.

Versions of packages swig suggests:
pn  swig-doc   
pn  swig-examples  

-- no debconf information

Bug#602591: Re: Bug

[tm hck]

Bug#863846: xen-tools: Fails to reload dnsmasq under systemd

[Daniel Gnoutcheff]

Package: xen-tools
Version: 4.7-1
Severity: minor

Dear Maintainer,

/usr/share/xen-tools/common/50-setup-hostname-deb is supposed to reload
dnsmasq (if installed and running) after adding a line to /etc/hosts.
However, this does not happen on my stretch system, and dnsmasq doesn't
pick up these entries until I reload it manually.

I suspect this is because setup-hostname-deb hardcodes the wrong pidfile
path:

> if [ -e /var/run/dnsmasq.pid ]; then
> 
> logMessage Allowing DNSMasq to restart.
> kill -s HUP `cat /var/run/dnsmasq.pid`
> fi

The correct path seems to be /run/dnsmasq/dnsmasq.pid.

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

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

Versions of packages xen-tools depends on:
ii  debootstrap   1.0.89
ii  libconfig-inifiles-perl   2.94-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdata-validate-ip-perl  0.27-1
ii  libdata-validate-uri-perl 0.06-1
ii  libfile-slurp-perl.19-6
ii  libfile-which-perl1.21-1
ii  libsort-versions-perl 1.62-1
ii  libterm-ui-perl   0.46-1
ii  libtext-template-perl 1.46-1
ii  openssh-client1:7.4p1-10
ii  perl  5.24.1-2

Versions of packages xen-tools recommends:
ii  debian-archive-keyring 2014.3
ii  libexpect-perl 1.21-1
ii  lvm2   2.02.168-2
ii  rinse  3.2
ii  ubuntu-archive-keyring 2016.05.13-1
ii  xen-hypervisor-4.8-amd64 [xen-hypervisor]  4.8.1-1+deb9u1
ii  xen-utils-4.8 [xen-utils]  4.8.1-1+deb9u1

Versions of packages xen-tools suggests:
pn  btrfs-tools
pn  cfengine2  
pn  reiserfsprogs  
pn  xfsprogs   

-- Configuration Files:
/etc/xen-tools/xen-tools.conf changed:
memory = 256M
swap = 512M
size = 4G
dist = stretch
mirror = http://debian.sflc.info/debian/
lvm = wilson_vg
bridge = vm-br
gateway = 10.66.0.1
netmask = 255.255.255.0
nameserver = 10.66.0.2
role = pvgrub
kernel = /usr/lib/grub-xen/grub-x86_64-xen.bin
initrd =
install-method = debootstrap
fs = ext4
ext4_options = noatime,nodiratime,errors=remount-ro
ext3_options = noatime,nodiratime,errors=remount-ro
ext2_options = noatime,nodiratime,errors=remount-ro
xfs_options  = defaults
reiserfs_options = defaults
btrfs_options= defaults


-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#863843: bugs.debian.org: Encrypted partition not accessible after resume

[Don Armstrong]

Control: reassign -1 src:linux
Control: severity -1 normal
Control: tag -1 moreinfo

On Wed, 31 May 2017, Garjola Dindi wrote:
> I am using Debian Stretch on a laptop with a HDD (/dev/sda) and an SSD
> (/dev/sdd). My swap and home partitions are encrypted with lvm. The
> ouput of lsblk is:
> 
> NAME  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
> sda 8:00 931.5G  0 disk  
> ├─sda1  8:10   243M  0 part  /boot
> ├─sda2  8:20 1K  0 part  
> └─sda5  8:50 931.3G  0 part  
>   └─sda5_crypt254:00 931.3G  0 crypt 
> ├─pc--117--162--vg-root   254:10 893.6G  0 lvm   /home
> └─pc--117--162--vg-swap_1 254:20  37.7G  0 lvm   [SWAP]
> sdb 8:16   0   477G  0 disk  
> └─sdb1  8:17   0   477G  0 part  /
> 
> For several weeks now I have been having issues after resume (both
> from RAM or from disk): my /home seems not to be accessible (at least
> for writing). This does not happen every time, but more something like
> once every 10 or 20 resume cycles.
> 
> At first, I thought this was related to an initramfs-tools (0.129)
> update where it was mentioned that the RESUME variable had to be set
> in the configuration, but this should only affect resuming from disk.
> I however tried to set this to different values (the /dev/XXX, auto,
> none) but nothing changes with my issue.
> 
> Since I also have a warning at boot time saying "Failing to connect to
> lvmetad" I set use_lvmetad = 0 in /etc/lvm/lvm.conf. Again, nothing
> changes.

You've filed this bug against bugs.debian.org which is the pseudopackage
for reporting bugs which affect the bug tracking system itself, not for
bugs which the underlying package is unclear.

I've reassigned it to the linux source package, but you'll need to
provide more information before the maintainers of that package will be
able to help.

In this particular case, I'm suspecting that /home or possibly swap is
getting mounted read only, but the output of dmesg; when you have a
failure will provide more information. [Along with the precise kernel
version and whether this happens on newer kernels (4.11.0-trunk is in
experimental) too.]



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

"In my many years I have come to a conclusion that one useless man is
a shame, two is a law firm, and three or more is a congress."
 -- John Adams

Bug#863797: Bug#863797: monitoring-plugins-basic: unable to use check_disk inside /var/tmp

[Emmanuel DECAEN]

Le 31/05/2017 à 18:50, Sebastiaan Couwenberg a écrit :
> On 05/31/2017 06:11 PM, Emmanuel DECAEN wrote:
>> Le 31/05/2017 à 17:04, Bas Couwenberg a écrit :
>>> On 2017-05-31 16:52, Jan Wagner wrote:
 Am 31.05.17 um 12:06 schrieb Emmanuel DECAEN:
> In nrpe, system wide /var/tmp is no more reachable
> $ grep "/var/tmp" /proc/11489/mountinfo
> 115 113 254:2 / /var/tmp/mysql rw,noatime,nodiratime shared:65
> master:32- xfs /dev/mapper/v1-tmp rw,attr2,inode64,noquota
> 121 113 8:5
> /tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-7xjqpw/tmp
>
> /var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5
> rw,data=ordered
 As you traced the problem yourself to nrpe, you might want to reassign
 the bug to nagios-nrpe-plugin with appropriate version?
>>> If NRPE cannot execute the checkcommand that implies that the nagios
>>> user doesn't have the required permissions.
>> Command run as nagios user:
>> nagios@server:~$ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p
>> /var/tmp/mysql
>> DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);|
>> /var/tmp/mysql=42MB;8184;9207;0;10230
> This is what NRPE executes, so this is not a problem in NRPE.
>
>>> The given checkcommand is not part of the default configuration:
>>>
>>>  /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql
>>>
>>> Which suggests that this is a configuration issue to be resolved by
>>> the administrator of the system. (e.g use sudo to execute the plugin
>>> as a users with the required permissions).
>> (It was working before upgrade)
>>
>> Using sudo :
>> $ sudo -u nagios /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p
>> /var/tmp/mysql
>> DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);|
>> /var/tmp/mysql=42MB;8184;9207;0;10230
> What is the output of the check_nrpe command when you execute it (as the
> nagios user) from the monitoring host?

nagios@mon:~$  /usr/lib/nagios/plugins/check_nrpe -n -H server -c
check_tmpsqldisk
DISK CRITICAL - /var/tmp/mysql is not accessible: No such file or directory

> And what does nagios-nrpe-server log on the system where the check_disk
> command you claim fails?

May 31 22:46:45 server nrpe[31037]: Running command:
/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql
May 31 22:46:45 server nrpe[31037]: Command completed with return code 2
and output: DISK CRITICAL - /var/tmp/mysql is not accessible: No such
file or directory
May 31 22:46:45 server nrpe[31037]: Return Code: 2, Output: DISK
CRITICAL - /var/tmp/mysql is not accessible: No such file or directory

I think the problem is related to this "private" mount in
nagios-nrpe-server (extract from /proc/xx/mountinfo):
121 113 8:5
/tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-MbLbk1/tmp
/var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5 rw,data=ordered

Best Regards,
-- 
*Emmanuel DECAEN*

Bug#863584: CVE-2017-2824

[Moritz Mühlenhoff]

On Mon, May 29, 2017 at 12:05:59PM +0300, Alexei Vladishev wrote:
> Hey all,
> 
> Upstream here. Both issues has already been fixed under 
> https://support.zabbix.com/browse/ZBX-12075 
> .

Dmitry, can you please upload a fix in time for the stretch release?

Cheers,
   Moritz

Bug#854727: Removal from stretch?

[Moritz Muehlenhoff]

On Fri, Mar 24, 2017 at 07:41:03AM -0400, Scott Howard wrote:
> I was contacted by someone at SUSE that is working on fixing the security
> bugs - but even if successful, I don't know how good the quality will be or
> how much testing will be able to get done before stretch is released.
> Removal might be safest option

Unfortunately removal didn't work our for stretch and will have to wait
for buster.

I'm attaching the patches used by SuSE to address these vulnerabilities
(extracted from their srpm).

Cheers,
Moritz
Index: zziplib-0.13.62/zzip/memdisk.c
===
--- zziplib-0.13.62.orig/zzip/memdisk.c
+++ zziplib-0.13.62/zzip/memdisk.c
@@ -216,12 +216,12 @@ zzip_mem_entry_new(ZZIP_DISK * disk, ZZI
 /* override sizes/offsets with zip64 values for largefile support */
 zzip_extra_zip64 *block = (zzip_extra_zip64 *)
 zzip_mem_entry_extra_block(item, ZZIP_EXTRA_zip64);
-if (block)
+if (block && ZZIP_GET16(block->z_datasize) >= (8 + 8 + 8 + 4))
 {
-item->zz_usize = __zzip_get64(block->z_usize);
-item->zz_csize = __zzip_get64(block->z_csize);
-item->zz_offset = __zzip_get64(block->z_offset);
-item->zz_diskstart = __zzip_get32(block->z_diskstart);
+item->zz_usize = ZZIP_GET64(block->z_usize);
+item->zz_csize = ZZIP_GET64(block->z_csize);
+item->zz_offset = ZZIP_GET64(block->z_offset);
+item->zz_diskstart = ZZIP_GET32(block->z_diskstart);
 }
 }
 /* NOTE:
Index: zziplib-0.13.62/zzip/memdisk.c
===
--- zziplib-0.13.62.orig/zzip/memdisk.c
+++ zziplib-0.13.62/zzip/memdisk.c
@@ -173,6 +173,8 @@ zzip_mem_entry_new(ZZIP_DISK * disk, ZZI
 return 0;   /* errno=ENOMEM; */
 ___ struct zzip_file_header *header =
 zzip_disk_entry_to_file_header(disk, entry);
+if (!header)
+	{ free(item); return 0; }
 /*  there is a number of duplicated information in the file header
  *  or the disk entry block. Theoretically some part may be missing
  *  that exists in the other, ... but we will prefer the disk entry.
Index: zziplib-0.13.62/zzip/mmapped.c
===
--- zziplib-0.13.62.orig/zzip/mmapped.c
+++ zziplib-0.13.62/zzip/mmapped.c
@@ -289,6 +289,8 @@ zzip_disk_entry_to_file_header(ZZIP_DISK
 (disk->buffer + zzip_disk_entry_fileoffset(entry));
 if (disk->buffer > file_header || file_header >= disk->endbuf)
 return 0;
+if (ZZIP_GET32(file_header) != ZZIP_FILE_HEADER_MAGIC)
+return 0;
 return (struct zzip_file_header *) file_header;
 }
 
Index: zziplib-0.13.62/zzip/memdisk.c
===
--- zziplib-0.13.62.orig/zzip/memdisk.c
+++ zziplib-0.13.62/zzip/memdisk.c
@@ -201,6 +201,7 @@ zzip_mem_entry_new(ZZIP_DISK * disk, ZZI
 {
 void *mem = malloc(ext1 + 2);
 item->zz_ext[1] = mem;
+	item->zz_extlen[1] = ext1 + 2;
 memcpy(mem, ptr1, ext1);
 ((char *) (mem))[ext1 + 0] = 0;
 ((char *) (mem))[ext1 + 1] = 0;
@@ -209,6 +210,7 @@ zzip_mem_entry_new(ZZIP_DISK * disk, ZZI
 {
 void *mem = malloc(ext2 + 2);
 item->zz_ext[2] = mem;
+	item->zz_extlen[2] = ext2 + 2;
 memcpy(mem, ptr2, ext2);
 ((char *) (mem))[ext2 + 0] = 0;
 ((char *) (mem))[ext2 + 1] = 0;
@@ -245,8 +247,10 @@ zzip_mem_entry_extra_block(ZZIP_MEM_ENTR
 while (1)
 {
 ZZIP_EXTRA_BLOCK *ext = entry->zz_ext[i];
-if (ext)
+if (ext && (entry->zz_extlen[i] >= zzip_extra_block_headerlength))
 {
+	char *endblock = (char *)ext + entry->zz_extlen[i];
+
 while (*(short *) (ext->z_datatype))
 {
 if (datatype == zzip_extra_block_get_datatype(ext))
@@ -257,6 +261,10 @@ zzip_mem_entry_extra_block(ZZIP_MEM_ENTR
 e += zzip_extra_block_headerlength;
 e += zzip_extra_block_get_datasize(ext);
 ext = (void *) e;
+		if (e >= endblock)
+		{
+		break;
+		}
 ;
 }
 }
Index: zziplib-0.13.62/zzip/memdisk.h
===
--- zziplib-0.13.62.orig/zzip/memdisk.h
+++ zziplib-0.13.62/zzip/memdisk.h
@@ -66,6 +66,7 @@ struct _zzip_mem_entry {
 int  zz_filetype;  /* (from "z_filetype") */
 char*zz_comment;   /* zero-terminated (from "comment") */
 ZZIP_EXTRA_BLOCK* zz_ext[3];   /* terminated by null in z_datatype */
+int  zz_extlen[3]; /* length of zz_ext[i] in bytes */
 }; /* the extra blocks are NOT converted */
 
 #define _zzip_mem_disk_findfirst(_d_) ((_d_)->list)
Index: 

Bug#863844: kwalletmanager: Migration does not work and restarts at every login

[Rainer Dorsch]

Package: kwalletmanager
Version: 4:16.08.3-1
Severity: important

Dear Maintainer,

since upgrading from Jessie to Stretch, the migration assistant starts at every 
login, but kwalletmanager does never see the old passwords. I assume the 
migration
assistant crashes silently.

I am happy to provide additional debug information, please specify what would 
help to better understand the failure.

I classify the Severity as important since I do not know how many users will be 
affected by this bug, once Stretch is released.

Thanks
Rainer


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Versions of packages kwalletmanager depends on:
ii  kio 5.28.0-2
ii  libc6   2.24-10
ii  libkf5archive5  5.28.0-2
ii  libkf5auth5 5.28.0-2
ii  libkf5codecs5   5.28.0-1+b2
ii  libkf5configcore5   5.28.0-2
ii  libkf5configwidgets55.28.0-2
ii  libkf5coreaddons5   5.28.0-2
ii  libkf5dbusaddons5   5.28.0-1
ii  libkf5i18n5 5.28.0-2
ii  libkf5iconthemes5   5.28.0-2
ii  libkf5itemviews55.28.0-1
ii  libkf5jobwidgets5   5.28.0-2
ii  libkf5kdelibs4support5  5.28.0-1
ii  libkf5kiocore5  5.28.0-2
ii  libkf5notifications55.28.0-1
ii  libkf5service-bin   5.28.0-1
ii  libkf5service5  5.28.0-1
ii  libkf5textwidgets5  5.28.0-1
ii  libkf5wallet-bin5.28.0-3
ii  libkf5wallet5   5.28.0-3
ii  libkf5widgetsaddons55.28.0-3
ii  libkf5xmlgui5   5.28.0-1
ii  libqt5core5a5.7.1+dfsg-3+b1
ii  libqt5dbus5 5.7.1+dfsg-3+b1
ii  libqt5gui5  5.7.1+dfsg-3+b1
ii  libqt5widgets5  5.7.1+dfsg-3+b1
ii  libqt5xml5  5.7.1+dfsg-3+b1
ii  libstdc++6  6.3.0-18

Versions of packages kwalletmanager recommends:
ii  kde-runtime  4:16.08.3-2

kwalletmanager suggests no packages.

-- no debconf information

Bug#863845: libstdc++6: adding more Breaks to smoothen upgrades from jessie to stretch

[Andreas Beckmann]

Package: libstdc++6
Version: 6.3.0-18
Severity: important

Hi,

during my piuparts upgrade tests I identified a few upgrade paths that
could likely be smoothened by adding a few Breaks to libstdc++6:

  libktoblzcheck1c2a(replaced by libktoblzcheck1v5)
  libterralib   (replaced by libterralib3)
  libmagickcore-6.q16-2 (replaced by 
libmagickcore-6.q16-3)
  liblhapdf0(replaced by liblhapdf0v5)
  libspice-client-glib-2.0-8 (<< 0.33)

In these upgrade paths the problematic packages are not removed
or upgraded, but the jessie versions of these (and some other) packages
are kept installed.

I'm now going to try whether that works as expected ...


Andreas

Bug#863843: bugs.debian.org: Encrypted partition not accessible after resume

[Garjola Dindi]

Package: bugs.debian.org
Severity: serious
Justification: 4

Dear Maintainer,

Hi,

I am using Debian Stretch on a laptop with a HDD (/dev/sda) and an SSD 
(/dev/sdd). My swap and home partitions are encrypted with lvm. The ouput of 
lsblk is:

NAME  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda 8:00 931.5G  0 disk  
├─sda1  8:10   243M  0 part  /boot
├─sda2  8:20 1K  0 part  
└─sda5  8:50 931.3G  0 part  
  └─sda5_crypt254:00 931.3G  0 crypt 
├─pc--117--162--vg-root   254:10 893.6G  0 lvm   /home
└─pc--117--162--vg-swap_1 254:20  37.7G  0 lvm   [SWAP]
sdb 8:16   0   477G  0 disk  
└─sdb1  8:17   0   477G  0 part  /

For several weeks now I have been having issues after resume (both from RAM or 
from disk): my /home seems not to be accessible (at least for writing). This 
does not happen every time, but more something like once every 10 or 20 resume 
cycles.

At first, I thought this was related to an initramfs-tools (0.129) update where 
it was mentioned that the RESUME variable had to be set in the configuration, 
but this should only affect resuming from disk. I however tried to set this to 
different values (the /dev/XXX, auto, none) but nothing changes with my issue.

Since I also have a warning at boot time saying "Failing to connect to lvmetad" 
I set use_lvmetad = 0 in /etc/lvm/lvm.conf. Again, nothing changes.

My /etc/crypttab reads as follows:
sda5_crypt UUID=11a52b25-26f4-41ae-b52e-2aa5d0a4d35d none luks

which seems OK since
ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 May 31 10:45 11a52b25-26f4-41ae-b52e-2aa5d0a4d35d -> 
../../sda5
lrwxrwxrwx 1 root root 10 May 31 10:45 136599d4-9b3b-4a74-a0dc-6bc48fb227f3 -> 
../../sda1
lrwxrwxrwx 1 root root 10 May 31 10:45 2b70ec10-751f-4670-8000-1c59d7307f29 -> 
../../dm-2
lrwxrwxrwx 1 root root 10 May 31 10:45 98ae6177-1de0-4af2-b905-687df457f1ca -> 
../../sdb1
lrwxrwxrwx 1 root root 10 May 31 10:45 d3415b5d-e1fe-4ce6-98c8-a8645f358524 -> 
../../dm-1

Thanks

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

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

Bug#863799: ITP: redtick -- tiny pomodoro timer for Emacs

[Sean Whitton]

On Wed, May 31, 2017 at 04:40:56PM +0200, Carsten Leonhardt wrote:
> I'm curious to see the long description, as I don't see the
> relationship between tomatoes and timers.

Sure!

Description: tiny pomodoro timer for Emacs
 This package provides a little pomodoro timer in the mode-line.
 .
 After importing into your Emacs configuration, redtick shows a little
 red tick (✓) in the mode-line.  When you click on this tick, redtick
 starts a pomodoro timer.
 .
 The Pomodoro Technique involves working in 25 minute intervals,
 separated by 5 minute breaks, with a longer break after every four
 intervals.

https://en.wikipedia.org/wiki/Pomodoro_Technique

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#863447: dh_install -X is ignored for --list/fail-missing

[Michael Biebl]

Am 31.05.2017 um 22:23 schrieb Iain Lane:
> On Sat, May 27, 2017 at 12:51:38AM +0200, Michael Biebl wrote:
>> I also note, that usr/share/doc/NetworkManager/examples/server.conf is
>> actually installed via debian/network-manager.examples, which contains:
>> debian/tmp/usr/share/doc/NetworkManager/examples/server.conf
>>
>> I assume dh_installexamples is simply not updated yet to support the new
>> dh_missing functionality?
> 
> This also happens with dh_install --list-missing currently[0]. I *guess*
> that this is because dh_install is run first, before all the other
> dh_installfoo commands. So dh_install itself has no way of knowing what
> is about to be installed by other commands. This to me seems unfixable
> without either changing the order (at a compat bump?) or removing
> --{list,fail}-missing and running dh_missing after all the dh_installfoo
> commands. AFAICS they will all need to call log_installed_files for this
> to work properly.

Right, I don't think this is fixable with the current dh_install and I
was actually thinking of the new dh_missing helper here which indeed
should run "last" i.e. after all other dh_installfoo helpers.

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#863469: Wheezy update of pngquant?

[Emilio Pozuelo Monfort]

Control: tags -1 patch

Hi Andreas,

On 31/05/17 22:13, Andreas Tille wrote:
> Hi Emilio,
> 
> On Wed, May 31, 2017 at 09:42:37AM +0200, Emilio Pozuelo Monfort wrote:
>>
>> No worries. I already updated pngquant in wheezy.
> 
> Cool.  Thanks a lot.
> 
>> I also found another possible
>> buffer overflow and reported it upstream, but it's not confirmed yet (and I
>> don't have a test case to confirm it).
>>
>> BTW if you can fix this in sid that'd be nice. Or if you're too busy I can 
>> fix
>> it for you there. The fix is pretty simple:
>>
>> https://github.com/pornel/pngquant/commit/b7c217680cda02dddced245d237ebe8c383be285
> 
> Hmmm, are you sure that this patch applies to version 2.5.0 from sid?
> The code looks pretty different.  I do not mind at all if you do a NMU -
> if you provide a patch that applies cleanly I can promise quick upload.

That's because in 2.5.0 the (wrong) overflow check hadn't been added. That
upstream patch removes the wrong check and adds the correct one. Since 2.5.0
doesn't have the wrong one, we just need to add it. See the attached patch,
which builds and works fine in a quick test (didn't test against a crafted 
image).

Cheers,
Emilio
--- rwpng.c.old 2017-05-31 22:36:13.329067904 +0200
+++ rwpng.c 2017-05-31 22:37:37.697664350 +0200
@@ -278,6 +278,12 @@ pngquant_error rwpng_read_image24_libpng
 
 rowbytes = png_get_rowbytes(png_ptr, info_ptr);
 
+// For overflow safety reject images that won't fit in 32-bit
+if (rowbytes > INT_MAX/mainprog_ptr->height) {
+png_destroy_read_struct(_ptr, _ptr, NULL);
+return PNG_OUT_OF_MEMORY_ERROR;  /* not quite true, but whatever */
+}
+
 if ((mainprog_ptr->rgba_data = malloc(rowbytes*mainprog_ptr->height)) == 
NULL) {
 fprintf(stderr, "pngquant readpng:  unable to allocate image data\n");
 png_destroy_read_struct(_ptr, _ptr, NULL);

Bug#863201: libpam-ldap not longer installs the file /usr/share/pam-configs/ldap needed for pam-auth-update

[Julián Moreno Patiño]

Hello Lucas,

I've canceled my NMU upload and I've uploaded yours.

Kind regards,

-- 
Julián Moreno Patiño
Debian Developer
 .''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `'  http://debian.org/
  `-   GPG Fingerprint:
C2C8 904E 314C D8FA 041D 9B00 D5FD FC15 6168 BF60
Registered GNU Linux User ID 488513


signature.asc
Description: PGP signature

Bug#863673: [Pkg-freeradius-maintainers] Bug#863673: CVE-2017-9148: FreeRADIUS TLS resumption authentication bypass

[Moritz Muehlenhoff]

On Tue, May 30, 2017 at 05:50:20PM +0200, Michael Stapelberg wrote:
> security-team, can you take care of applying the patch to stable and
> oldstable please? Thank you.

No, we generally expect maintainers to prepare/test security updates,
particularly for packages which are complex to test like freeradius.

Cheers,
Moritz

Bug#863842: CVE-2017-9304

[Moritz Muehlenhoff]

Source: yara
Severity: important
Tags: security

Please see
https://github.com/VirusTotal/yara/issues/674
https://github.com/VirusTotal/yara/commit/925bcf3c3b0a28b5b78e25d9efda5c0bf27ae699

Cheers,
Moritz

Bug#863447: dh_install -X is ignored for --list/fail-missing

[Iain Lane]

On Sat, May 27, 2017 at 12:51:38AM +0200, Michael Biebl wrote:
> I also note, that usr/share/doc/NetworkManager/examples/server.conf is
> actually installed via debian/network-manager.examples, which contains:
> debian/tmp/usr/share/doc/NetworkManager/examples/server.conf
> 
> I assume dh_installexamples is simply not updated yet to support the new
> dh_missing functionality?

This also happens with dh_install --list-missing currently[0]. I *guess*
that this is because dh_install is run first, before all the other
dh_installfoo commands. So dh_install itself has no way of knowing what
is about to be installed by other commands. This to me seems unfixable
without either changing the order (at a compat bump?) or removing
--{list,fail}-missing and running dh_missing after all the dh_installfoo
commands. AFAICS they will all need to call log_installed_files for this
to work properly.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]

[0] 
https://buildd.debian.org/status/fetch.php?pkg=network-manager=i386=1.8.0-2=1494613902=0


signature.asc
Description: PGP signature

Bug#863841: Enable systemd hardening options for named

[Russ Allbery]

Package: bind9
Version: 1:9.10.3.dfsg.P4-12.3
Severity: wishlist

BIND named is a great candidate for enabling systemd hardening features,
since it has very limited required access to the local file system and
a long history of security issues due to its complexity.

I'm currently using the following settings on jessie without any impact,
although I'm not using dynamic DNS or a few other things that may make
a difference.  jessie had much more limited options; there are other
options now available in newer systemd, and I didn't start looking at
system call filtering.

CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_NET_BIND_SERVICE CAP_SETGID 
CAP_SETUID
NoNewPrivileges=true
PrivateDevices=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=full

CAP_DAC_OVERRIDE is required for rndc to read /etc/bind/rndc.key; a
possible alternative would be to find a way to run it as the bind user
instead.  It's possible that you could drop CAP_SETGID and CAP_SETUID
and instead let systemd switch to the bind user, and put
CAP_NET_BIND_SERVICE into the ambient capability set instead so that it
can still bind to a low-numbered port.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.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)

Versions of packages bind9 depends on:
ii  adduser3.115
ii  bind9utils 1:9.10.3.dfsg.P4-12.3
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  libbind9-140   1:9.10.3.dfsg.P4-12.3
ii  libc6  2.24-11
ii  libcap21:2.25-1
ii  libcomerr2 1.43.4-2
ii  libdns162  1:9.10.3.dfsg.P4-12.3
ii  libgeoip1  1.6.9-4
ii  libgssapi-krb5-2   1.15-1
ii  libirs141  1:9.10.3.dfsg.P4-12.3
ii  libisc160  1:9.10.3.dfsg.P4-12.3
ii  libisccc1401:9.10.3.dfsg.P4-12.3
ii  libisccfg140   1:9.10.3.dfsg.P4-12.3
ii  libk5crypto3   1.15-1
ii  libkrb5-3  1.15-1
ii  liblwres1411:9.10.3.dfsg.P4-12.3
ii  libssl1.0.21.0.2l-1
ii  libxml22.9.4+dfsg1-2.2
ii  lsb-base   9.20161125
ii  net-tools  1.60+git20161116.90da8a0-1
ii  netbase5.4

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind9-doc   
ii  dnsutils1:9.10.3.dfsg.P4-12.3
pn  resolvconf  
pn  ufw 

-- debconf information:
  bind9/start-as-user: bind
  bind9/different-configuration-file:
  bind9/run-resolvconf: false

Bug#863840: qemu: CVE-2017-9310: net: infinite loop in e1000e NIC emulation

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.8+dfsg-6
Severity: important
Tags: patch upstream security fixed-upstream

Hi,

the following vulnerability was published for qemu.

CVE-2017-9310[0]:
net: infinite loop in e1000e NIC emulation

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-9310
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9310
[1] 
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4154c7e03fa55b4cf52509a83d50d6c09d743b7

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#863663: libgstreamer1.0-0: plays MJPEG AVI files (and possibly other formats) at degraded quality

[Francesco Poli]

On Wed, 31 May 2017 10:09:46 +0300 Sebastian Dröge wrote:

[...]
> Thanks for the sample file.

You're welcome.

> I can reproduce this here and it's caused
> by the libjpeg based decoder from GStreamer. The one based on ffmpeg
> works just fine.

How can I force GStreamer to use the ffmpeg based decoder with
gst-launch-1.0?
And from within an application that uses the GStreamer library?

> 
> I've forwarded this upstream here:
>   https://bugzilla.gnome.org/show_bug.cgi?id=783267
> 
> 
> Thanks for reporting

Thanks to you for forwarding my bug report upstream so promptly.
Now let's hope the issue is pinpointed and fixed real soon now!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpzHXjfmlBwg.pgp
Description: PGP signature

Bug#863839: CVE-2017-7502

[Ola Lundqvist]

Package: nss
Severity: important

Hi

An important vulnerability has been found in nss.

For more information see
https://security-tracker.debian.org/tracker/CVE-2017-7502
and
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-7502

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#863447: dh_install -X is ignored for --list/fail-missing

[Iain Lane]

On Sat, May 27, 2017 at 12:51:38AM +0200, Michael Biebl wrote:
> Package: debhelper
> Version: 10.4
> Severity: normal
> 
> Hi,
> 
> I just tried debhelper 10.4 from experimental which implements
> dh_install --list/fail-missing via the new dh_missing tool.
> 
> I don't use dh_missing directly yet, but rely on the backwards compat
> support. My debian/rules contains
> 
> override_dh_install:
>   dh_install -X.la --list-missing
> 
> Apparently the -X.la is ignored though and dh_missing still complains
> about the libtool .la files:

Indeed. How about a patch like this? Comes with a test.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]
From 0ca87c2d2b383e1e6e0c42c4f74e48eeb60cbb35 Mon Sep 17 00:00:00 2001
From: Iain Lane 
Date: Wed, 31 May 2017 20:45:15 +0100
Subject: [PATCH] dh_install: Pass --exclude/-X to dh_missing. (Closes:
 #863447)

---
 debian/changelog  | 6 ++
 dh_install| 3 +++
 t/dh_missing/Makefile | 1 +
 t/dh_missing/dh_missing.t | 9 -
 4 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index db49925f..20628ddd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+debhelper (10.5) UNRELEASED; urgency=medium
+
+  * dh_install: Pass --exclude/-X to dh_missing. (Closes: #863447)
+
+ -- Iain Lane   Wed, 31 May 2017 20:40:24 +0100
+
 debhelper (10.4) experimental; urgency=medium
 
   * Team upload.
diff --git a/dh_install b/dh_install
index 820ac70b..2806af9e 100755
--- a/dh_install
+++ b/dh_install
@@ -271,6 +271,9 @@ if ($missing_files) {
 
 if ($dh{LIST_MISSING} || $dh{FAIL_MISSING}) {
 	my @options;
+	foreach (@{$dh{EXCLUDE}}) {
+		push(@options, '--exclude', $_);
+	}
 	push(@options, '--sourcedir', $dh{SOURCEDIR}) if defined($dh{SOURCEDIR});
 	push @options, "--list-missing" if $dh{LIST_MISSING};
 	push @options, "--fail-missing" if $dh{FAIL_MISSING};
diff --git a/t/dh_missing/Makefile b/t/dh_missing/Makefile
index 679592a7..e33e1dfc 100644
--- a/t/dh_missing/Makefile
+++ b/t/dh_missing/Makefile
@@ -4,3 +4,4 @@ install:
 
 installmore: install
 	install -m 644 file-for-foo debian/tmp/usr/bin/file-for-foo-more
+	install -m 644 file-for-foo debian/tmp/usr/bin/file-for-foo-lots
diff --git a/t/dh_missing/dh_missing.t b/t/dh_missing/dh_missing.t
index 6cd80ea8..851c5ef5 100755
--- a/t/dh_missing/dh_missing.t
+++ b/t/dh_missing/dh_missing.t
@@ -22,7 +22,7 @@ if (not defined($rootcmd)) {
 	plan skip_all => 'fakeroot required';
 }
 else {
-	plan(tests => 4);
+	plan(tests => 5);
 }
 
 # Verify dh_missing does not fail when all files are installed.
@@ -41,6 +41,13 @@ ok(! ($? & 127), 'dh_missing did not die due to a signal');
 my $exitcode = ($? >> 8);
 is($exitcode, 2, 'dh_missing exited with exit code 2');
 
+# Verify that dh_install -X --fail-missing is passed through to dh_missing (#863447)
+# dh_install -Xfile makes file-for-foo not be installed. Then we shouldn't
+# complain about it not being missing.
+system("$rootcmd $TOPDIR/dh_clean");
+system("$rootcmd make install");
+is(system("PATH=$TOPDIR:\$PATH $rootcmd $TOPDIR/dh_install -X more --exclude lots --fail-missing"),0, 'dh_install -X... --fail-missing failed');
+
 system("$rootcmd $TOPDIR/dh_clean");
 
 # Local Variables:
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#863539: depends on runit not runit-init

[Adam Borowski]

Control: tags -1 +moreinfo

Hi!
All these packages depend on runit, while the RC bug is on runit-init.
While they are indeed built from the same source, a recent upload already
dropped the runit-init binary, thus making the issue moot for Stretch.

Unless I'm missing something, these bugs can be closed.


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.

Bug#754393: grml-rescueboot: add script to fetch iso image

[Felipe Sateler]

On Sun, Aug 31, 2014 at 1:34 PM, Michael Prokop  wrote:

> Hi,
>
> sorry for the delay :(
>
> * Felipe Sateler [Thu Jul 10, 2014 at 11:34:45AM -0400]:
>
> > This package is very useful. However, upon install one has to go
> > download a grml iso image, and then keep updating it periodically.
>
> > I have done a small script that queries the grml site for release
> > images, and downloads the latest. It is possible to specify the
> > architecture (32/64/96 with autodetection) and the version (small/full).
>
> > I am not sure this script ready for direct usage, especially as it lacks
> > any kind of documentation. But it could be useful shipped as an example
> > script.
>
> That's a wonderful idea, thanks for the script! I'll work on its
> integration in grml-rescueboot ASAP.
>

Because there is no better time to ping than with a new GRML release, I
attach a new version of the script here. Changes since the last version:

1. Use download.grml.org instead of deb.grml.org to get the iso file list.
The latter seems to lag behind.
2. Do not verify sha1sum, as the signature is now validating the iso image
and not the sha sum.

-- 

Saludos,
Felipe Sateler


fetch-grml-iso
Description: Binary data

Bug#863838: unblock: debian-edu-install/1.926

[Holger Levsen]

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

Please unblock package debian-edu-install, it only contains a trivial update
in preparation of the Debian Edu Stretch release.

Please note that it also contains an (unmodified) udeb, thus cc:ing KiBi for
the famous KiBi-ack! :)


$ debdiff debian-edu-install_1.915.dsc  debian-edu-install_1.916.dsc
diff -Nru debian-edu-install-1.915/debian/changelog 
debian-edu-install-1.916/debian/changelog
--- debian-edu-install-1.915/debian/changelog   2017-03-05 17:21:09.0 
+0100
+++ debian-edu-install-1.916/debian/changelog   2017-05-30 15:53:21.0 
+0200
@@ -1,3 +1,11 @@
+debian-edu-install (1.916) unstable; urgency=medium
+
+  * Set version number to 9+edu0 in preparation of the Debian Stretch release,
+which for the first time could also mark the Debian Edu Stretch release at
+the same time!
+
+ -- Holger Levsen   Tue, 30 May 2017 15:53:21 +0200
+
 debian-edu-install (1.915) unstable; urgency=medium
 
   [ Wolfgang Schweer ]
diff -Nru debian-edu-install-1.915/debian/debian-edu-install.postinst 
debian-edu-install-1.916/debian/debian-edu-install.postinst
--- debian-edu-install-1.915/debian/debian-edu-install.postinst 2017-03-02 
20:20:10.0 +0100
+++ debian-edu-install-1.916/debian/debian-edu-install.postinst 2017-05-29 
17:48:03.0 +0200
@@ -155,7 +155,7 @@
 '7.1+edu0~a3' '7.1+edu0~b0' '7.1+edu0~b1' '7.1+edu0~b2' \
 '7.1+edu0' '8.0.0+edu+alpha0' '8.0+edu+alpha0' \
 '8.0+edu0~alpha0' '8.0+edu0~alpha1' '8.0+edu0~alpha2' \
-'8.0+edu0~beta1' '8+edu0' '9+edu0~alpha0'
+'8.0+edu0~beta1' '8+edu0' '9+edu0~alpha0' '9+edu0~a0'
 
do
if [ "$VERSION" = "$i" ] ; then
diff -Nru debian-edu-install-1.915/version debian-edu-install-1.916/version
--- debian-edu-install-1.915/version2017-03-02 20:20:10.0 +0100
+++ debian-edu-install-1.916/version2017-05-29 17:47:19.0 +0200
@@ -1 +1 @@
-9+edu0~a0
+9+edu0


unblock debian-edu-install/1.926

Thanks for your work on Stretch!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#863837: yara-python FTBFS with yara 3.6.0: error: 'YR_OBJECT_INTEGER' undeclared (first use in this function)

[Adrian Bunk]

Source: yara-python
Version: 3.5.0+dfsg-4
Severity: serious
Tags: sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/yara-python.html

...
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes 
-fno-strict-aliasing -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DHAVE_MEMMEM=1 
-Iyara/libyara/include -Iyara/libyara/ -I. -I/usr/include/python2.7 -c 
yara-python.c -o build/temp.linux-amd64-2.7/yara-python.o
yara-python.c: In function 'convert_object_to_python':
yara-python.c:421:13: error: 'YR_OBJECT_INTEGER' undeclared (first use in this 
function)
   if (((YR_OBJECT_INTEGER*) object)->value != UNDEFINED)
 ^
yara-python.c:421:13: note: each undeclared identifier is reported only once 
for each function it appears in
yara-python.c:421:31: error: expected expression before ')' token
   if (((YR_OBJECT_INTEGER*) object)->value != UNDEFINED)
   ^
yara-python.c:423:38: error: expected expression before ')' token
 "i", ((YR_OBJECT_INTEGER*) object)->value);
  ^
yara-python.c:427:24: error: 'YR_OBJECT_STRING' undeclared (first use in this 
function)
   sized_string = ((YR_OBJECT_STRING*) object)->value;
^~~~
yara-python.c:427:41: error: expected expression before ')' token
   sized_string = ((YR_OBJECT_STRING*) object)->value;
 ^
yara-python.c:445:10: error: 'OBJECT_TYPE_REGEXP' undeclared (first use in this 
function)
 case OBJECT_TYPE_REGEXP:
  ^~
In file included from /usr/include/python2.7/pyport.h:325:0,
 from /usr/include/python2.7/Python.h:58,
 from yara-python.c:18:
yara-python.c:454:20: error: 'YR_OBJECT_DOUBLE' undeclared (first use in this 
function)
   if (!isnan(((YR_OBJECT_DOUBLE*) object)->value))
^
yara-python.c:454:37: error: expected expression before ')' token
   if (!isnan(((YR_OBJECT_DOUBLE*) object)->value))
 ^
yara-python.c:455:56: error: expected expression before ')' token
 result = Py_BuildValue("d", ((YR_OBJECT_DOUBLE*) object)->value);
^
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
E: pybuild pybuild:283: build: plugin distutils failed with: exit code=1: 
/usr/bin/python setup.py build --dynamic-linking
dh_auto_build: pybuild --build -i python{version} -p 2.7 
--build-args=--dynamic-linking returned exit code 13
debian/rules:11: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 25

Bug#863835: [Pkg-fonts-devel] Bug#863835: fontconfig: please do not register WOFF(2) fonts

[Fabian Greffrath]

Control: block 861938 by -1
Control: block 863009 by -1


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

Bug#863836: waagent: [waagent] Re-add "waagent2.0" file to package

[Stephen Zarkos]

Package: waagent
Version: 2.2.0-1~deb8+azure1
Severity: normal

Hi,

The current waagent package (both 2.2.0 and 2.2.12 in unstable) includes the 
patch "entry-points.patch," which patches setup.py to remove the waagent2.0 
file from the package. The absense of the waagent2.0 file is causing some 
popular VM extensions on Azure to fail. Please re-add this file to the package 
to make VM extensions work again.

The waagent2.0 file is loaded as a python library by these extensions. Its 
purpose is to provide distribution detection logic and some distro-specific 
functions. Currently the only workaround is for the VM owner to take manual 
action to resolve.



-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-0.bpo.3-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages waagent depends on:
ii  bind9-host [host]1:9.9.5.dfsg-9+deb8u11
ii  ca-certificates  20141019+deb8u3
ii  eject2.1.5+deb1+cvs20081104-13.1+deb8u1
ii  host 1:9.9.5.dfsg-9+deb8u11
ii  init-system-helpers  1.22
ii  iptables 1.4.21-2+b1
ii  net-tools1.60-26+b1
ii  openssh-server   1:6.7p1-5+deb8u3
ii  openssl  1.0.1t-1+deb8u6
ii  parted   3.2-7
ii  python   2.7.9-1
ii  python-pyasn10.1.7-1
pn  python:any   
ii  sudo 1.8.10p3-1+deb8u4

waagent recommends no packages.

waagent suggests no packages.

-- no debconf information

Bug#863835: fontconfig: please do not register WOFF(2) fonts

[Fabian Greffrath]

Package: fontconfig
Version: 2.11.0-6.7+b1
Severity: important
Tags: patch

Dear maintainer,

currently, fontconfig registers all fonts installed into the
/usr/share/fonts directory hierarchy. This may, however, contain fonts
that are not meant to be exposed to general application and are only
there to adhere to the FHS specs.

One example are fonts in the WOFF(2) file formats. From the official
W3C WOFF specs (https://www.w3.org/TR/WOFF/):

"2. General Requirements

The primary purpose of the WOFF format is to package fonts linked to
Web documents by means of CSS @font-face rules. User agents supporting
the WOFF file format for linked fonts must respect the requirements of
the CSS3 Fonts specification ([CSS3-Fonts] Section 4.1: The @font-face
rule). In particular, such linked fonts are only available to the
documents that reference them; they MUST NOT be made available to
other applications or documents on the user's system.

NOTE: the WOFF format is intended for use with @font-face to provide
fonts linked to specific Web documents. Therefore, WOFF files must not
be treated as an installable font format in desktop operating systems
or similar environments. The WOFF-packaged data will typically be
decoded to sfnt format for use by existing font-rendering APIs that
expect OpenType font data, but such decoded font must not be exposed
to other documents or applications."

So, please refrain from registering fonts in WOFF(2) formats with
fontconfig. This can be achieved by installing the attached fontconfig
snippet, courtesy of Nicolas Spalinger ,
as /etc/fonts/conf.d/70-no-woffs.conf .

Thanks!

Cheers,

 - Fabian

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'experimental'), 
(500, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Versions of packages fontconfig depends on:
ii  dpkg   1.18.24
ii  fontconfig-config  2.11.0-6.7
ii  libc6  2.24-10
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.8-0.1

fontconfig recommends no packages.

fontconfig suggests no packages.

-- no debconf information




 
  
  /usr/share/fonts/woff/*
  
 

Bug#863834: imagemagick: CVE-2017-9262: Memory leak in the ReadJNGImage function

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.8.9.9-5
Severity: normal
Tags: security patch upstream fixed-upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/475

Hi,

the following vulnerability was published for imagemagick.

CVE-2017-9262[0]:
| In ImageMagick 7.0.5-6 Q16, the ReadJNGImage function in coders/png.c
| allows attackers to cause a denial of service (memory leak) via a
| crafted file.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-9262
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9262
[1] https://github.com/ImageMagick/ImageMagick/issues/475

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#863833: imagemagick: CVE-2017-9261: Memory leak in the ReadMNGImage function

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-9
Severity: normal
Tags: security patch upstream fixed-upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/476

Hi,

the following vulnerability was published for imagemagick.

CVE-2017-9261[0]:
| In ImageMagick 7.0.5-6 Q16, the ReadMNGImage function in coders/png.c
| allows attackers to cause a denial of service (memory leak) via a
| crafted file.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-9261
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9261
[1] https://github.com/ImageMagick/ImageMagick/issues/476

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#863820: gcc-6-base: adding Breaks: tzdata-java to smoothen the openjdk 7 -> 8 upgrade path from jessie to stretch

[Andreas Beckmann]

On 2017-05-31 16:01, Andreas Beckmann wrote:
> I'll now build a gcc-6 with that Breaks added ...

... and can confirm that it fixes the upgrade path of
libreoffice-subsequentcheckbase (where I previously observed a kept back
tzdata (and openjdk-7) from jessie).

Andreas

Bug#863671: Commit fix?

[David Steele]

Note that the CVE references 1ebc60b, which removes a "/bin/sh"
call, addressing the vulnerability.

Your patch incorporates the relevant code added by that commit
(though it replaces a system() call, instead).


https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-9059

https://github.com/npat-efault/picocom/commit/1ebc60b

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#789607: git-email: better to install with package "ca-certificates" by Recommends or Suggests

[Uwe Kleine-König]

Package: git
Version: 1:2.11.0-3
Followup-For: Bug #789607

Hello,

without ca-certificates installed I get on a Debian porter box:

(sid_arm64-dchroot)ukleinek@asachi:~$ debcheckout linux
declared git repository at 
https://anonscm.debian.org/git/kernel/linux.git
git clone https://anonscm.debian.org/git/kernel/linux.git linux ...
Cloning into 'linux'...
fatal: unable to access 
'https://anonscm.debian.org/git/kernel/linux.git/': Problem with the SSL CA 
cert (path? access rights?)
checkout failed (the command above returned a non-zero exit code)

So please consider a Recommends: for git, not git-email.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#673515: ETA ?

[Apollon Oikonomopoulos]

Hi,

On 12:40 Wed 31 May , andi+debian-673515@notmuch.email wrote:
> Hi,
> 
> I really appreciate your effort and time investment into this.
> 
> Do you have any idea if this will make it into strech?

Unfortunately PuppetDB will not make it into stretch. The deadline for 
this would be February 5, when the hard freeze started. However, I plan 
to provide backports for stretch as soon as possible. I don't have an 
ETA yet, but I think I'll push for the uploads after stretch has been 
released.

Regards,
Apollon

Bug#863832: subliminal manpage: bogus default cache dir

[Jakub Wilk]

Package: subliminal
Version: 1.1.1-2
Severity: minor

The subliminal manual page reads:

  --cache-dir DIRECTORY
 Path to the cache directory.  [default: 
/sbuild-nonexistent/.config/subliminal]

I don't think the stated default value is correct...

--
Jakub Wilk

Bug#863536: doomsday: Segfaults when attempting to start new game

[Bernhard Übelacker]

Hello,
tried to reproduce the issue.

I think the problem is that in Cl_IsClientMobj the method maybeAs()
is called on a NULL pointer on mo->thinker.d.

With the attached patch the crash does not happen.

And this time I took the opportunity to play in
doom1-share.wad and doom2.wad (just short) and found
no more crashes.

Kind regards,
Bernhard





# gdb -q --args doomsday
(gdb) run
...
Loading map "E1M1"...

Thread 39 "CallbackThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff873a2700 (LWP 17501)]
0x7476492d in __dynamic_cast () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6


(gdb) bt
#0  0x7476492d in __dynamic_cast () at 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x555dc9bd in Thinker::IData::maybeAs() 
(this=) at ../libdoomsday/include/doomsday/world/thinker.h:135
#2  0x555dc9bd in Cl_IsClientMobj(mobj_s const*) 
(mo=mo@entry=0x7fffe2663cc0) at src/client/cl_mobj.cpp:214
#3  0x558828e0 in de::Thinkers::add(thinker_s&, bool) 
(this=0x7fff39c58690, th=..., makePublic=makePublic@entry=true) at 
src/world/thinkers.cpp:230
#4  0x55861020 in P_MobjCreate(void (*)(void*), de::Vector3 
const&, unsigned int, double, double, int) (function=0x7fffe1fc3940 
, origin=..., angle=, radius=16, height=128, 
ddflags=536870912) at src/world/p_mobj.cpp:119
#5  0x5580555b in Mobj_CreateXYZ(thinkfunc_t, coord_t, coord_t, 
coord_t, angle_t, coord_t, coord_t, int) (function=, 
x=, y=, z=, angle=, 
radius=, height=, ddflags=) at 
src/world/api_map.cpp:1788
#6  0x7fffe1fc3458 in P_SpawnMobjXYZ (type=type@entry=MT_MISC48, x=288, 
y=-3104, z=0, angle=1073741824, spawnFlags=536870919) at src/p_mobj.c:709
#7  0x7fffe1fc385a in P_SpawnMobj (type=type@entry=MT_MISC48, 
pos=pos@entry=0x7fffe26625c0, angle=, spawnFlags=) at src/p_mobj.c:796
#8  0x7fffe1f6b972 in spawnMapObjects () at ../common/src/p_mapsetup.cpp:593
#9  0x7fffe1f6b972 in P_FinalizeMapChange(uri_s const*) 
(mapUri_=0x7fff873a1900) at ../common/src/p_mapsetup.cpp:894
#10 0x558871c6 in de::WorldSystem::Instance::makeCurrent(de::Map*) 
(this=this@entry=0x56e16b60, newMap=newMap@entry=0x7fff38423e50) at 
src/world/worldsystem.cpp:521
#11 0x55889022 in de::WorldSystem::Instance::changeMap(MapDef*) 
(this=0x56e16b60, mapDef=0x7fff383a08f0) at src/world/worldsystem.cpp:724
#12 0x5588965d in de::WorldSystem::Instance::changeMapWorker(void*) 
(context=) at src/world/worldsystem.cpp:744
#13 0x77243f83 in CallbackThread::run() (this=0x58ae1330) at 
src/concurrency.cpp:76
#14 0x74d45daa in QThreadPrivate::start(void*) (arg=0x58ae1330) at 
thread/qthread_unix.cpp:352
#15 0x76509494 in start_thread (arg=0x7fff873a2700) at 
pthread_create.c:333
#16 0x73f0693f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97


(gdb) up
#1  0x555dc9bd in Thinker::IData::maybeAs 
(this=) at ../libdoomsday/include/doomsday/world/thinker.h:135
135 DENG2_AS_IS_METHODS()
(gdb) 
#2  Cl_IsClientMobj (mo=mo@entry=0x7fffe2663cc0) at src/client/cl_mobj.cpp:214
214 if(ClientMobjThinkerData *data = THINKER_DATA_MAYBE(mo->thinker, 
ClientMobjThinkerData))


(gdb) print mo
$3 = (const mobj_t *) 0x7fffe2663cc0
(gdb) print mo->thinker
$4 = {prev = 0x0, next = 0x0, function = 0x7fffe1fc3940 , _flags 
= 0, id = 0, d = 0x0}


#define THINKER_DATA_MAYBE(thinker, T)  (reinterpret_cast((thinker).d)->maybeAs())


(gdb) print mo->thinker.d
$5 = (void *) 0x0


dd_bool Cl_IsClientMobj(mobj_t const *mo)
{
if(ClientMobjThinkerData *data = THINKER_DATA_MAYBE(mo->thinker, 
ClientMobjThinkerData))
{
return data->hasRemoteSync();
}
return false;
}
From 8a6fb59e5dd1965638c70ad9a396eb9bf959e84d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Wed, 31 May 2017 19:59:36 +0200
Subject: Avoid crash when mo->thinker.d is a NULL pointer.

https://bugs.debian.org/863536

(gdb) bt
#0  0x7476492d in __dynamic_cast () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x555dc9bd in Thinker::IData::maybeAs() (this=) at ../libdoomsday/include/doomsday/world/thinker.h:135
#2  0x555dc9bd in Cl_IsClientMobj(mobj_s const*) (mo=mo@entry=0x7fffe2663cc0) at src/client/cl_mobj.cpp:214
#3  0x558828e0 in de::Thinkers::add(thinker_s&, bool) (this=0x7fff39c58690, th=..., makePublic=makePublic@entry=true) at src/world/thinkers.cpp:230
#4  0x55861020 in P_MobjCreate(void (*)(void*), de::Vector3 const&, unsigned int, double, double, int) (function=0x7fffe1fc3940 , origin=..., angle=, radius=16, height=128, ddflags=536870912) at src/world/p_mobj.cpp:119
#5  0x5580555b in Mobj_CreateXYZ(thinkfunc_t, coord_t, coord_t, coord_t, angle_t, coord_t, coord_t, int) (function=, x=, y=, z=, angle=, radius=, height=, ddflags=) at src/world/api_map.cpp:1788
#6  0x7fffe1fc3458 in P_SpawnMobjXYZ (type=type@entry=MT_MISC48, x=288, y=-3104, 

Bug#725392: findutils: please add xargs -o parameter (MirBSD compatible) to help interactive applications

[Thorsten Glaser]

Andreas Metzler dixit:

>Control: forwarded -1 https://savannah.gnu.org/bugs/?51151

Thanks!

>Forwarded, however with a pointer to ,
>where an argument against adding this can be found.

Hm, I can’t find it. Where, and/or, which argument?


Funnily enough, joe (or rather its fork jupp) is precisely
what I need -o for:

$ git find pom.xml -print0 | xargs -0o jupp

This works on MirBSD (if jupp and “git-find” are installed)
but not on Debian, where one has to type

$ git find pom.xml -print0 | xargs -0 sh -c 'jupp  emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh").  [aus dasr]

Bug#725392: findutils: please add xargs -o parameter (MirBSD compatible) to help interactive applications

[Thorsten Glaser]

Dixi quod…

>>Forwarded, however with a pointer to ,

>Hm, I can’t find it. Where, and/or, which argument?

Ah, I think I see now what you mean.

   | Consider the following command:
   |
   | echo bar | (echo foo | xargs --interactive grep)
   |
   | What should grep's stdin be, /dev/tty or the stdout of "echo
   | bar"? Is the answer different for other programs? Why? (I

This?

By the time xargs runs, the stdout of 'echo bar' is already
not available *at all* any more in Unix, there is no way any
program can retrieve it with standard Unix tools (Linux procfs
might, but even then, possibly not, depending on the shell
used and how it handles fds).

So that’s not an issue ;-)

I assume --interactive would be -o ?


bye,
//mirabilos (now how do I Cc the Savannah tracker?)
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

Bug#851214: images attached to emails are embedded with task=1 instead of task=mail

[Michael Laß]

Hi,

this is a duplicate of #843795. The workaround shown here would actually revert 
parts of a critical security fix for CVE-2016-4069. Instead, the solution 
mentioned in #843795 should be implemented and pushed via Wheezy LTS.

Cheers,
Michael

Bug#863831: libpam-duo: Security issue reported with versions prior to 1.9.21; need package updated

[Richard Landster]

Package: libpam-duo
Version: 1.9.18-1~sbp80+1
Severity: important

Dear Maintainer,

This is from Duo Security:


Duo Product Security Advisory

=

Advisory ID: DUO-PSA-2017-002
Publication Date: 2017-05-31
Revision Date: 2017-05-31
Status: Confirmed, Fixed
Document Revision: 1

Overview
Duo Security has identified an issue in duo_unix, which, under certain
uncommon configurations, could enable attackers to bypass second-factor
user authentication. Duo has no evidence that this vulnerability has
actively been exploited and we believe this specific configuration is
extraordinarily uncommon.

This issue was resolved in version 1.9.21 of duo_unix. Customers using an
affected configuration should update to the latest version as soon as
possible (see "Solution" section below).

Description
Prior to version 1.9.21, duo_unix (which includes both login_duo and
pam_duo), supported setting an HTTP proxy configuration through the
standard 'http_proxy' environment variable. Under some uncommon
configurations (examples listed below), however, it is possible for an
untrusted user to set a value for the 'http_proxy' variable prior to
initiating a Duo authentication attempt.

If an invalid proxy host (e.g. '0.0.0.0') is selected, then
login_duo/pam_duo will ultimately fail to connect to Duo's API, and as a
result, trigger the configured "failmode" behavior. If "failmode" is set
to "safe" (which is the default), then this could result in a bypass of
second-factor authentication.

Duo has identified two specific configuration scenarios in which an
untrusted user may be able to control the value of the 'http_proxy'
environment variable.

1. login_duo with nonstandard sshd "AcceptEnv" configurations:

OpenSSH can permit clients to forward environment variables to servers. By
default, OpenSSH server distributions generally allow only a whitelisted
set of variables (which does not include 'http_proxy') to be forwarded in
this way. It is possible, however, for an administrator to configure a
less-restrictive policy using the AcceptEnv keyword in sshd_config.

If a server has been configured with a non-default AcceptEnv policy that
permits clients to send an 'http_proxy' environment variable, and is using
login_duo to add Duo 2FA to ssh logins, then this configuration could
result in a bypass of Duo 2FA.

This scenario only applies to login_duo; when used with OpenSSH, pam_duo
is unaffected by this issue.

2. pam_duo with local authentication (e.g. su / sudo):

While pam_duo is not affected by this issue when used with OpenSSH, when
pam_duo is being used to perform 2FA in other contexts - particularly, to
authenticate system-local actions performed by untrusted users - it may be
possible for untrusted users to control the value of the 'http_proxy'
environment variable prior to initiating an authentication attempt.

In particular, Duo has confirmed that configurations which use pam_duo to
add Duo 2FA to the "su" and "sudo" commands are impacted by this issue.

Version 1.9.21 of duo_unix has been released to resolve this issue. It
removes support for configuring an HTTP Proxy via an environment variable.

Impact
Attackers may be able to bypass second-factor authentication on impacted
configurations which accept attacker-controlled environment variables.

Affected Product(s)
All versions of duo_unix prior to 1.9.21 are impacted when used in one of
the following configuration scenarios:

* login_duo is performing 2FA for SSH logins, and sshd has been configured
  with a permissive (non-default) AcceptEnv policy
  * pam_duo is performing 2FA for scenarios other than SSH logins

Workaround
Customers using login_duo in an affected configuration may work around
this issue by ensuring that their AcceptEnv configuration for sshd
(e.g. in /etc/ssh/sshd_config) does not permit clients to send an
'http_proxy' variable.

Customers using pam_duo in an affected configuration must upgrade to the
latest version of duo_unix.

Solution
Customers should upgrade to the latest version of the duo_unix client as
discussed above. Clone the latest version from:

* https://github.com/duosecurity/duo_unix

For more information on upgrading duo_unix, see
https://duo.com/docs/duounix

Vulnerability Metrics
Vulnerability Class: CWE-454: External Initialization of Trusted Variables
or Data Stores
https://cwe.mitre.org/data/definitions/454.html
Remotely Exploitable: [No]
Authentication Required: [Partial]
Severity: [High]
CVSSv2 Overall Score: 5.0
CVSSv2 Group Scores: Base: 6.0, Temporal: 5.0
CVSSv2 Vector: AV:L/AC:M/Au:S/C:P/I:P/A:N/E:F/RL:OF/RC:C

References
* CWE-454: External Initialization of Trusted Variables or Data Stores -
https://cwe.mitre.org/data/definitions/454.html
* Duo Unix Reference - https://duo.com/docs/duounix

Timeline
2017-05-19
* Duo privately receives report of a security vulnerability in Duo Unix
* Duo acknowledges receipt of report and begins investigation

2017-05-22
* Duo confirms vulnerability exists in 

Bug#725392: findutils: please add xargs -o parameter (MirBSD compatible) to help interactive applications

[Andreas Metzler]

Control: forwarded -1 https://savannah.gnu.org/bugs/?51151

On 2017-05-30 Thorsten Glaser  wrote:
[...]
> BSD’s ‘-o’ option is documented thus:

>  -o  Reopen stdin as /dev/tty in the child process before executing
>  the command. This is useful if you want xargs to run an interac-
>  tive application.

> IMHO, the -o option is much less cumbersome to type/remember, and for
> the sake of reverse portability (support applications that _already_
> use the BSD variant), and especially given that the GNU maintainers
> already know of it, the -o option ought to be added to GNU xargs as
> well.

> Side effect: avoids launching another shell, and, more importantly
> to some, avoids quoting hell.

> (That being said, /bin/sh on FreeBSD and derivates thereof has
> slightly broken (for hysterical raisins) behaviour when sh -c cmd
> is followed by “--” so the portability the GNU maintainers assert
> for the sh variant is not exactly true either.)

> So please persuade the upstream developers to add it; if necessary
> I can likely cook up a debdiff.

Hello Thorsten,

thanks for taking the time to write down a concise feature request.

Forwarded, however with a pointer to ,
where an argument against adding this can be found.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#851933: udev: /lib/udev/hwdb.bin gets wrong SE Linux label

[Michael Biebl]

Control: tags -1 + confirmed

On Fri, 20 Jan 2017 15:39:14 +1100 Russell Coker 
wrote:
> Package: udev
> Version: 232-12
> Severity: normal
> 
> The command "systemd-hwdb --usr update" as run from
> /var/lib/dpkg/info/udev.postinst creates the file /lib/udev/hwdb.bin and
> assigns it the SE Linux context "system_u:object_r:default_t:s0" when it
> should have "system_u:object_r:bin_t:s0" with the current policy.


I've setup a test stretch VM enabling SELinux following the instructions
from [1] and can reproduce the issue.

Running "systemd-hwdb --usr update" creates the cache file as
/lib/udev/hwdb.bin with context "system_u:object_r:default_t:s0".

Running "systemd-hwdb update" creates the cache file as
/etc/udev/hwdb.bin with context "system_u:object_r:etc_t:s0", which
seems to be the correct context (as restorecon doesn't change it).

The selinux context should be set by label_fix:
https://github.com/systemd/systemd/blob/master/src/hwdb/hwdb.c#L682

I haven't debugged yet, why that doesn't work for --usr.


[1] https://wiki.debian.org/SELinux/Setup
-- 
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#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Daniel Kahn Gillmor]

Hi all--

On Tue 2017-05-30 13:07:01 -0400, Daniel Kahn Gillmor wrote:
> I've now done this NMU, and filed #863732 to unblock the upload.
>
> I've pushed the changes in a git branch to
> https://anonscm.debian.org/git/collab-maint/runit.git, which is forked
> from of https://anonscm.debian.org/git/users/kaction-guest/runit.git and
> should probably be re-merged at some point.
>
> fwiw, the practice of keeping just the debian/ directory in git seems
> odd to me and makes it more difficult for me to contribute to the
> NMU-maintenance of the package.  if i was going to do more work on the
> package, i'd certainly prefer it to be converted to a standard
> git-buildpackage-style "ladder" repo.

I regret to say that i think i did this upload suboptimally.  by just
dropping the runit-init package, we've left debian users who want runit
as pid 1 with no options other than to rebuild the package, because
nothing is shipping /sbin/runit or /sbin/runit-init.

in jessie, /sbin/runit and /sbin/runit-init are both shipped in the
runit package.

What i should have done is to move /sbin/runit and /sbin/runit-init into
the runit package itself, rather than drop them entirely.

I've made this change and would like to propose a 2.1.2-9.2 upload, with
attached debdiff.  I've tested this with a guest system which now does
load runit as PID 1 when booted with a kernel argument of
"init=/sbin/runit-init".

I apologize for the oversight, and want to know if it'd be ok for me to
upload 2.1.2-9.2 using the attached debdiff.  I've pushed a queue of
these changes into the "unstable" branch at
https://anonscm.debian.org/git/collab-maint/runit.git already if you'd
prefer to review them there.

Regards,

   --dkg

diff -Nru runit-2.1.2/debian/changelog runit-2.1.2/debian/changelog
--- runit-2.1.2/debian/changelog	2017-05-30 11:46:28.0 -0400
+++ runit-2.1.2/debian/changelog	2017-05-31 12:44:38.0 -0400
@@ -1,3 +1,11 @@
+runit (2.1.2-9.2) unstable; urgency=medium
+
+  * non-maintainer upload
+  * re-add /sbin/runit{,-init} to runit package so it remains possible to
+use runit as PID 1
+
+ -- Daniel Kahn Gillmor   Wed, 31 May 2017 12:44:38 -0400
+
 runit (2.1.2-9.1) unstable; urgency=medium
 
   * non-maintainer upload
diff -Nru runit-2.1.2/debian/control runit-2.1.2/debian/control
--- runit-2.1.2/debian/control	2017-05-28 15:07:36.0 -0400
+++ runit-2.1.2/debian/control	2017-05-31 12:44:38.0 -0400
@@ -6,7 +6,6 @@
 Homepage: http://smarden.org/runit/
 Build-Depends: bash-completion,
debhelper (>= 9),
-   dh-exec,
dh-systemd,
dh-runit (>= 1.6),
dh-buildinfo (>= 0.11+nmu1),
diff -Nru runit-2.1.2/debian/rules runit-2.1.2/debian/rules
--- runit-2.1.2/debian/rules	2017-05-28 15:08:57.0 -0400
+++ runit-2.1.2/debian/rules	2017-05-31 12:44:38.0 -0400
@@ -9,9 +9,6 @@
 override_dh_systemd_enable:
 	dh_systemd_enable --name runit
 
-override_dh_installman-arch:
-	dh_installman
-
 override_dh_runit: runscripts/getty
 	dh_runit
 
diff -Nru runit-2.1.2/debian/runit.install runit-2.1.2/debian/runit.install
--- runit-2.1.2/debian/runit.install	2017-05-28 14:51:14.0 -0400
+++ runit-2.1.2/debian/runit.install	2017-05-31 12:44:38.0 -0400
@@ -8,7 +8,9 @@
 runit-*/src/chpst  /usr/bin
 runit-*/src/runsvchdir /usr/sbin
 runit-*/src/utmpset/usr/sbin
+runit-*/src/runit-init /sbin
+runit-*/src/runit  /sbin
 
 runit-*/etc/debian/1   /etc/runit
 runit-*/etc/2  /etc/runit
-runit-*/etc/debian/3   /etc/runit
\ No newline at end of file
+runit-*/etc/debian/3   /etc/runit
diff -Nru runit-2.1.2/debian/runit.manpages runit-2.1.2/debian/runit.manpages
--- runit-2.1.2/debian/runit.manpages	2017-05-28 14:51:14.0 -0400
+++ runit-2.1.2/debian/runit.manpages	2017-05-31 12:40:18.0 -0400
@@ -5,4 +5,6 @@
 runit-*/man/chpst.8
 runit-*/man/runsvchdir.8
 runit-*/man/utmpset.8
+runit-*/man/runit.8
+runit-*/man/runit-init.8
 debian/contrib/update-service.8


signature.asc
Description: PGP signature

Bug#860159: libsamplerate: CVE-2017-7697

[Moritz Muehlenhoff]

On Wed, Apr 12, 2017 at 08:42:59PM +1000, Erik de Castro Lopo wrote:
> Salvatore Bonaccorso wrote:
> 
> > Source: libsamplerate
> > Version: 0.1.8-8
> > Severity: important
> > Tags: security upstream
> > 
> > Hi,
> > 
> > the following vulnerability was published for libsamplerate.
> > 
> > CVE-2017-7697[0]:
> > | In libsamplerate before 0.1.9, a buffer over-read occurs in the
> > | calc_output_single function in src_sinc.c via a crafted audio file.
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> This bug was reported within the last 24 hours, but was fixed over
> 6 months ago and released as part of version 0.1.9.
> 
> Obviously, I cannot go back an retoactively update the changelog.

What's the status, can we fix that in testing/sid?

Cheers,
Moritz

Bug#861769: fixed in systemd 233-8

[Michael Biebl]

Control: found -1 233-8

On Mon, 29 May 2017 13:19:08 + Michael Biebl  wrote:
>  systemd (233-8) experimental; urgency=medium
>  .
>* Bump debhelper compatibility level to 10
>* Drop versioned Build-Depends on dpkg-dev.
>  It's no longer necessary as even Jessie ships a new enough version.
>* timesyncd: don't use compiled-in list if FallbackNTP has been configured
>  explicitly (Closes: #861769)

I mixed up the bug numbers here. I meant to actually close #863038.

Re-opening this one.
-- 
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#863830: debocker: Support for git source format

[Mikael Magnusson]

Package: debocker

Version: 0.2.1

Tags: patch

Hello,

I have implemented support for the git source format "3.0 (git)" in debocker,

which I would like to contribute.


/Mikael

>From 6d4a66c0e7d429d0c7df6cd9370716c077eed8da Mon Sep 17 00:00:00 2001
From: Mikael Magnusson 
Date: Tue, 30 May 2017 17:01:24 +0200
Subject: [PATCH] add support for git source format

---
 bundle-files/steps/build-tar |  5 -
 debocker | 45 
 2 files changed, 37 insertions(+), 13 deletions(-)

diff --git a/bundle-files/steps/build-tar b/bundle-files/steps/build-tar
index 06fb0e0..a8af3e7 100755
--- a/bundle-files/steps/build-tar
+++ b/bundle-files/steps/build-tar
@@ -11,7 +11,10 @@ cd /root/source/
 if [ "${format}" = "native" ]; then
 # native
 exec tar -cf - *.build *.changes *.deb *.dsc *.tar.*
+elif [ "${format}" = "git" ]; then
+# git
+exec tar -cf - *.build *.changes *.deb *.dsc *.git
 else
-# non-native
+# non-native (quilt)
 exec tar -cf - *.build *.changes *.deb *.dsc *.debian.tar.* *.orig.tar.*
 fi
diff --git a/debocker b/debocker
index ae68c8a..7776d67 100755
--- a/debocker
+++ b/debocker
@@ -142,7 +142,7 @@ class Package:
 def is_valid(self):
 '''verifies that the current directory is a debian package'''
 return isdir(self.debian) and isfile(self.control) and \
-isfile(self.source_format) and self.format in ['native', 'quilt']
+isfile(self.source_format) and self.format in ['native', 'quilt', 'git']
 
 def assert_is_valid(self):
 if not self.is_valid():
@@ -152,7 +152,7 @@ class Package:
 def format(self):
 with open(self.source_format) as f:
 line = f.readline().strip()
-m = re.match(r'^3\.0 \((native|quilt)\)', line)
+m = re.match(r'^3\.0 \((native|quilt|git)\)', line)
 if not m:
 fail('unsupported format ({})', line)
 fmt = m.group(1)
@@ -161,7 +161,7 @@ class Package:
 
 @cached_property
 def native(self):
-return self.format == 'native'
+return self.long_version.find('-') == -1
 
 @cached_property
 def name(self):
@@ -216,7 +216,7 @@ class Package:
 fail('could not find original tarball')
 
 def assert_orig_tarball(self):
-if self.native:
+if self.format == 'native':
 # for now, we just tar the current directory
 path = tmppath('{}_{}.tar.xz'.format(
 self.name, self.version))
@@ -225,6 +225,12 @@ class Package:
 '-C', self.path, '.' ]
 log_check_call(tar, stdout = output)
 return path
+elif self.format == 'git':
+path = tmppath('{}_{}.git'.format(
+self.name, self.version))
+git = [ 'git', 'bundle', 'create', path, '--all']
+log_check_call(git)
+return path
 else:
 return self.orig_tarball  # simple alias
 
@@ -255,10 +261,14 @@ class Package:
 self.tar_package_debian(debian, comp = 'xz')
 originalfile = self.assert_orig_tarball()
 originalfile = abspath(originalfile)
-if self.native:
+if self.format == 'native':
 make_native_bundle(self.name, self.version,
controlfile, originalfile,
buildinfo, output)
+elif self.format == 'git':
+make_git_bundle(self.name, self.long_version,
+controlfile, originalfile, debianfile,
+buildinfo, output)
 else:
 make_quilt_bundle(self.name, self.long_version,
   controlfile, originalfile, debianfile,
@@ -284,7 +294,7 @@ def make_native_bundle(name, version, control,
source, buildinfo, output):
 dsc_name = '{}_{}.dsc'.format(name, version)
 bundler = Bundler(name, version, control, dsc_name,
-  buildinfo, native = True)
+  buildinfo, 'native')
 _, ext = splitext(source)
 source_name = '{}_{}.tar{}'.format(name, version, ext)
 bundler.add_source_file(source_name, source, 'source_tarball')
@@ -294,7 +304,7 @@ def make_quilt_bundle(name, version, control,
   original, debian, buildinfo, output):
 dsc_name = '{}_{}.dsc'.format(name, version)
 bundler = Bundler(name, version, control, dsc_name,
-  buildinfo, native = False)
+  buildinfo, 'quilt')
 _, oext = splitext(original)
 _, dext = splitext(debian)
 # TODO: improve
@@ -305,6 +315,17 @@ def make_quilt_bundle(name, version, control,
 bundler.add_source_file(debian_name, debian, 'debian_tarball')
 bundler.write_bundle(output = output)
 
+def make_git_bundle(name, version, control,
+source, debian, buildinfo, output):
+
+

Bug#863797: Bug#863797: monitoring-plugins-basic: unable to use check_disk inside /var/tmp

[Sebastiaan Couwenberg]

On 05/31/2017 06:11 PM, Emmanuel DECAEN wrote:
> Le 31/05/2017 à 17:04, Bas Couwenberg a écrit :
>> On 2017-05-31 16:52, Jan Wagner wrote:
>>> Am 31.05.17 um 12:06 schrieb Emmanuel DECAEN:
 In nrpe, system wide /var/tmp is no more reachable
 $ grep "/var/tmp" /proc/11489/mountinfo
 115 113 254:2 / /var/tmp/mysql rw,noatime,nodiratime shared:65
 master:32- xfs /dev/mapper/v1-tmp rw,attr2,inode64,noquota
 121 113 8:5
 /tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-7xjqpw/tmp

 /var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5
 rw,data=ordered
>>> As you traced the problem yourself to nrpe, you might want to reassign
>>> the bug to nagios-nrpe-plugin with appropriate version?
>>
>> If NRPE cannot execute the checkcommand that implies that the nagios
>> user doesn't have the required permissions.
> 
> Command run as nagios user:
> nagios@server:~$ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p
> /var/tmp/mysql
> DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);|
> /var/tmp/mysql=42MB;8184;9207;0;10230

This is what NRPE executes, so this is not a problem in NRPE.

>> The given checkcommand is not part of the default configuration:
>>
>>  /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql
>>
>> Which suggests that this is a configuration issue to be resolved by
>> the administrator of the system. (e.g use sudo to execute the plugin
>> as a users with the required permissions).
> 
> (It was working before upgrade)
> 
> Using sudo :
> $ sudo -u nagios /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p
> /var/tmp/mysql
> DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);|
> /var/tmp/mysql=42MB;8184;9207;0;10230

What is the output of the check_nrpe command when you execute it (as the
nagios user) from the monitoring host?

And what does nagios-nrpe-server log on the system where the check_disk
command you claim fails?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#863829: python2: dolfin 'module' object has no attribute 'cpp'

[Drew Parsons]

Package: python-dolfin
Version: 2016.2.0-3
Severity: grave
Justification: renders package unusable

Weird, the new python3 module seems to have broken the python2 dolfin
module.  That's not good.

Importing dolfin gives the error:
AttributeError: 'module' object has no attribute 'cpp'

Importing in python3 does not have this error.

$ ipython
Python 2.7.13 (default, Jan 19 2017, 14:48:08) 
In [1]: import dolfin
---
AttributeErrorTraceback (most recent call last)
 in ()
> 1 import dolfin

/usr/lib/python2.7/dist-packages/dolfin/__init__.pyc in ()
 15 
 16 # Import names from the compiled cpp modules
---> 17 from . import cpp
 18 from dolfin.cpp import *
 19 from dolfin.cpp import __version__, __swigversion__, __pythonversion__

/usr/lib/python2.7/dist-packages/dolfin/cpp/__init__.py in ()
 41 
 42 # Import the module
---> 43 exec("from . import %s" % module_name)
 44 module = globals()[module_name]
 45 

 in ()

/usr/lib/python2.7/dist-packages/dolfin/cpp/la.py in ()
233 make_ufc_form = _la.make_ufc_form
234 import dolfin.cpp.common
--> 235 class LinearAlgebraObject(dolfin.cpp.common.Variable):
236 """
237 

AttributeError: 'module' object has no attribute 'cpp'




-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-dolfin depends on:
ii  libc6 2.24-11
ii  libdolfin-dev 2016.2.0-3
ii  libdolfin2016.2   2016.2.0-3
ii  libgcc1   1:6.3.0-18
ii  libgomp1  6.3.0-18
ii  libopenmpi2   2.0.2-2
ii  libpetsc3.7.5 [libpetsc3.7]   3.7.5+dfsg1-4+b1
ii  libpetsc3.7.6 [libpetsc3.7]   3.7.6+dfsg1-1exp1
ii  libpython2.7  2.7.13-2
ii  libslepc3.7.3 [libslepc3.7]   3.7.3+dfsg1-5
ii  libstdc++66.3.0-18
ii  python2.7.13-2
ii  python-dijitso2016.2.0-1
ii  python-ffc2016.2.0-2
ii  python-instant2016.2.0-2
ii  python-numpy [python-numpy-abi9]  1:1.12.1-3
ii  python-petsc4py   3.7.0-3
ii  python-ply3.9-1
ii  python-six1.10.0-4
ii  python-slepc4py   3.7.0-3
ii  python-sympy  1.0-3
ii  python-ufl2016.2.0-2
pn  python:any
ii  swig3.0   3.0.10-1.1

python-dolfin recommends no packages.

Versions of packages python-dolfin suggests:
ii  dolfin-doc  2016.2.0-3

-- no debconf information

Bug#863828: python3-instant: undefined symbol: PyClass_Type during interpolate

[Drew Parsons]

Package: python3-instant
Version: 2016.2.0-2
Severity: normal

Testing the new python3 dolfin.  It works fine on my own scripts. But
seems to fail when instant is invoked by interpolate.

$ instant-clean-3 
$ ipython3
Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
In [1]: from fenics import *  # dolfin module behaves the same
In [2]: mesh = UnitSquareMesh(2, 2)
In [3]: V = FunctionSpace(mesh, 'P', 1)
In [4]: u = interpolate(Expression('x[0] + x[1]', degree=1), V)
...
AssertionError: Failed to import module found in cache. Modulename: 
'dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2';
Path: 
'/home/user/.cache/instant/python3.5/cache/dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2';
ImportError:/home/user/.cache/instant/python3.5/cache/dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2/_dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2.so:
 undefined symbol: PyClass_Type;



The full error report is:

In [4]: u = interpolate(Expression('x[0] + x[1]', degree=1), V)
Calling DOLFIN just-in-time (JIT) compiler, this may take some time.
--- Instant: compiling ---
In instant.import_module_directly: Failed to import module 
'dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2' from 
'/home/user/.cache/instant/python3.5/cache/dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2';
ImportError:/home/user/.cache/instant/python3.5/cache/dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2/_dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2.so:
 undefined symbol: PyClass_Type;
Failed to import module found in cache. Modulename: 
'dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2';
Path: 
'/home/user/.cache/instant/python3.5/cache/dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2';
ImportError:/home/user/.cache/instant/python3.5/cache/dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2/_dolfin_ee8f3791ac0426bc9e123d64557ccde25f2d90f2.so:
 undefined symbol: PyClass_Type;
---
AssertionErrorTraceback (most recent call last)
 in ()
> 1 u = interpolate(Expression('x[0] + x[1]', degree=1), V)

/usr/lib/python3/dist-packages/dolfin/functions/expression.py in __new__(cls, 
cppcode, *args, **kwargs)
652 cpp_base, members = compile_expressions([cppcode],
653 
[generic_function_members],
--> 654 
mpi_comm=kwargs.get("mpi_comm"))
655 cpp_base, members = cpp_base[0], members[0]
656 

/usr/lib/python3/dist-packages/dolfin/compilemodules/expressions.py in 
compile_expressions(cppargs, generic_function_members, mpi_comm)
212 "\n\n".join(code_snippets), classnames,
213 additional_declarations="\n".join(additional_declarations),
--> 214 mpi_comm=mpi_comm)
215 
216 return expression_classes, all_members

/usr/lib/python3/dist-packages/dolfin/compilemodules/expressions.py in 
compile_expression_code(code, classnames, module_name, additional_declarations, 
mpi_comm)
139 compiled_module = compile_extension_module(
140 code, additional_declarations=additional_declarations,
--> 141 mpi_comm=mpi_comm)
142 
143 # Get the compiled class

/usr/lib/python3/dist-packages/dolfin/compilemodules/jit.py in mpi_jit(*args, 
**kwargs)
 66 # Just call JIT compiler when running in serial
 67 if MPI.size(mpi_comm) == 1:
---> 68 return local_jit(*args, **kwargs)
 69 
 70 # Compile first on process 0

/usr/lib/python3/dist-packages/dolfin/compilemodules/compilemodule.py in 
compile_extension_module(code, module_name, additional_declarations, 
additional_system_headers, mpi_comm, **instant_kwargs)
470 code=code,
471 additional_declarations=additional_declarations,
--> 472 **instant_kwargs)
473 
474 sys.stdout.flush()

/usr/lib/python3/dist-packages/instant/build.py in build_module(modulename, 
source_directory, code, init_code, additional_definitions, 
additional_declarations, sources, wrap_headers, local_headers, system_headers, 
include_dirs, library_dirs, libraries, swigargs, swig_include_dirs, cppargs, 
lddargs, object_files, arrays, generate_interface, generate_setup, 
cmake_packages, signature, cache_dir)
585 
586 # Import module and place in memory cache
--> 587 module = import_and_cache_module(module_path, modulename, 
moduleids)
588 
589 if not module:

/usr/lib/python3/dist-packages/instant/cache.py in 
import_and_cache_module(path, modulename, moduleids)
 90 module, e = import_module_directly(path, modulename)
 91 instant_assert(module is not None, "Failed to import module found 
in cache. Modulename: '%s';\nPath: '%s';\n%s:%s;" % (modulename, path, 
type(e).__name__,
---> 92 
   e))
 93 

Bug#863398: [gimp] menu bar not visibile

[Ari Pollak]

That certainly seems relevant to me. If you install the missing
package, gnome-themes-standard, does the problem go away?

Bug#863797: monitoring-plugins-basic: unable to use check_disk inside /var/tmp

[Emmanuel DECAEN]

reassign 863797 nagios-nrpe-server 3.0.1-3

Le 31/05/2017 à 16:52, Jan Wagner a écrit :
> Hi Emmanuel,
>
> thanks for bringing this to our attention.
>
> Am 31.05.17 um 12:06 schrieb Emmanuel DECAEN:
>> Package: monitoring-plugins-basic
>> Version: 2.2-3
> [...]
>> After upgrade, check_disk on /var/tmp/mysql is broken.
>>
>> Status using nrpe (wrong):
>> DISK CRITICAL - /var/tmp/mysql is not accessible: No such file or directory
>>
>> Status using bash (works correctly):
>> $ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql
>> DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);|
>> /var/tmp/mysql=42MB;8184;9207;0;10230
> Which is a strong indication that check_disk itself works as expected.
>
>> In nrpe, system wide /var/tmp is no more reachable
>> $ grep "/var/tmp" /proc/11489/mountinfo
>> 115 113 254:2 / /var/tmp/mysql rw,noatime,nodiratime shared:65
>> master:32- xfs /dev/mapper/v1-tmp rw,attr2,inode64,noquota
>> 121 113 8:5
>> /tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-7xjqpw/tmp
>> /var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5 rw,data=ordered
> As you traced the problem yourself to nrpe, you might want to reassign
> the bug to nagios-nrpe-plugin with appropriate version?

I agree to reassign the bug to the package containing /usr/sbin/nrpe.

Best regards,

-- 
*Emmanuel DECAEN*

Bug#863797: Bug#863797: monitoring-plugins-basic: unable to use check_disk inside /var/tmp

[Emmanuel DECAEN]

Le 31/05/2017 à 17:04, Bas Couwenberg a écrit :
> On 2017-05-31 16:52, Jan Wagner wrote:
>> Am 31.05.17 um 12:06 schrieb Emmanuel DECAEN:
>>> In nrpe, system wide /var/tmp is no more reachable
>>> $ grep "/var/tmp" /proc/11489/mountinfo
>>> 115 113 254:2 / /var/tmp/mysql rw,noatime,nodiratime shared:65
>>> master:32- xfs /dev/mapper/v1-tmp rw,attr2,inode64,noquota
>>> 121 113 8:5
>>> /tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-7xjqpw/tmp
>>>
>>> /var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5
>>> rw,data=ordered
>> As you traced the problem yourself to nrpe, you might want to reassign
>> the bug to nagios-nrpe-plugin with appropriate version?
>
> If NRPE cannot execute the checkcommand that implies that the nagios
> user doesn't have the required permissions.

Command run as nagios user:
nagios@server:~$ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p
/var/tmp/mysql
DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);|
/var/tmp/mysql=42MB;8184;9207;0;10230

>
> The given checkcommand is not part of the default configuration:
>
>  /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql
>
> Which suggests that this is a configuration issue to be resolved by
> the administrator of the system. (e.g use sudo to execute the plugin
> as a users with the required permissions).

(It was working before upgrade)

Using sudo :
$ sudo -u nagios /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p
/var/tmp/mysql
DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);|
/var/tmp/mysql=42MB;8184;9207;0;10230

Best Regards

-- 
*Emmanuel DECAEN*

Bug#863398: [gimp] menu bar not visibile

[Carsten Knoll]

On 27.05.2017 01:20, Ari Pollak wrote:
> Could this be a GTK+ theme issue? Do other GTK+2 programs have the same
> problem (audacity or inkscape for example)?

Audacity and Inkscape look as I would expect them.

I get a bunch of GTK-Warnings the last two of them might be relevant:



(gimp:4435): Gtk-WARNING **: Unable to locate theme engine in
module_path: "adwaita",

** (gimp:4435): WARNING **: Invalid borders specified for theme pixmap:
/usr/share/themes/Breeze/gtk-2.0/../assets/line-h.png,
borders don't fit within the image






signature.asc
Description: OpenPGP digital signature

Bug#863827: neovim: New upstream version: 0.2.0

[Paride Legovini]

Package: neovim
Version: 0.1.7-4
Severity: normal

Dear Maintainers,

Neovim 0.2.0 has been released about on May, 2.
Please consider upgrading the package.

Thank you,

Paride

Bug#863824: Acknowledgement (iputils-tracepath: traceroute6.iputils fails with IPv6 address)

[Valentin Vidic]

Already fixed upstream in:

https://github.com/iputils/iputils/commit/1ef0e4c86d358c8e217b90686394196412e184d2

-- 
Valentin

Bug#863721: python-ncclient-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/python-ncclient/html/_sources/api.txt

[Sebastien Badia]

On Tuedd, May 30, 2017 at 02:43:10PM (+0200), Andreas Beckmann wrote:
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.

tags 863721 + pending
thanks

Hi,

Thanks Andreas!
I should not be awake when uploading the 0.5.3-2 version…

  ❯ apt show python-ncclient-doc
  Package: python-ncclient-doc
  Version: 0.5.3-2
  […]
  Breaks: foo (<< 0.4.7-1)
  Replaces: foo (<< 0.4.7-1)

Just corrected in the 0.5.3-3 version…

Thanks again!

Seb


signature.asc
Description: PGP signature

Bug#863826: glwMDrawingAreaWidgetClass should be extern, otherwise leads to Error: XtCreateWidget "glxarea" requires non-NULL widget class

[Yaroslav Halchenko]

Package: libglw1-mesa-dev
Version: 8.0.0-1.1
Severity: important
Tags: upstream

We started to encounter this issue with afni package (unfortunately not yet in
Debian, but WiP):

$> /usr/lib/afni/bin/suma   

...
Error: XtCreateWidget "glxarea" requires non-NULL widget class


and upstream's analysis lead to discovering

http://marc.info/?l=cygwin-xfree=141268983004514=2

where upstream agreed that it was a bug to not have glwMDrawingAreaWidgetClass
declared extern.

ATM I haven't found any of the two reverse depends in Debian proper for
this package affected (at least on a quick check).

I am attaching the diff with the patch/changelog entry... if someone from the
team blesses me -- I could do NMU .

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libglw1-mesa-dev depends on:
pn  libglw1-mesa 
ii  libmotif-dev 2.3.4-13
ii  libx11-dev   2:1.6.4-3
ii  libxt-dev1:1.1.5-1
ii  mesa-common-dev  13.0.4-1

libglw1-mesa-dev recommends no packages.

libglw1-mesa-dev suggests no packages.

-- debconf-show failed

-- debsums errors found:
debsums: changed file /usr/include/GL/GLwDrawA.h (from libglw1-mesa-dev package)
>From b35a4281c0c47d3eea152f7b24a7246d84480284 Mon Sep 17 00:00:00 2001
From: Yaroslav Halchenko 
Date: Wed, 31 May 2017 11:03:43 -0400
Subject: [PATCH] Added debian/patches/up_extern patch to declare
 glwMDrawingAreaWidgetClass  extern


diff --git a/debian/changelog b/debian/changelog
index 4967168..8c9a98d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+glw (8.0.0-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/up_extern  to mitigate problem of
+ZglwMDrawingAreaWidgetClass not being defined as extern (Closes: #X)
+
+ -- Yaroslav Halchenko   Wed, 31 May 2017 11:01:44 -0400
+
 glw (8.0.0-1.1) unstable; urgency=low
 
   [ Paul Gevers ]
diff --git a/debian/patches/series b/debian/patches/series
index 9ed72bb..bea18a8 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 # empty for now
+up_extern
diff --git a/debian/patches/up_extern b/debian/patches/up_extern
new file mode 100644
index 000..e2214cc
--- /dev/null
+++ b/debian/patches/up_extern
@@ -0,0 +1,32 @@
+From: Yaroslav Halchenko 
+Subject: glwMDrawingAreaWidgetClass
+
+ See Origin for the description/fix upstream
+
+Origin: http://marc.info/?l=cygwin-xfree=141268983004514=2
+Bug-Debian: http://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded: 
+Applied-Upstream: 
+Last-Update: 2017-05-31
+
+--- a/GLwDrawA.h
 b/GLwDrawA.h
+@@ -136,7 +136,7 @@
+ typedef struct _GLwMDrawingAreaClassRec   *GLwMDrawingAreaWidgetClass;
+ typedef struct _GLwMDrawingAreaRec*GLwMDrawingAreaWidget;
+ 
+-GLAPI WidgetClass glwMDrawingAreaWidgetClass;
++extern GLAPI WidgetClass glwMDrawingAreaWidgetClass;
+ 
+ 
+ #else 
+@@ -144,7 +144,7 @@ GLAPI WidgetClass glwMDrawingAreaWidgetC
+ typedef struct _GLwDrawingAreaClassRec*GLwDrawingAreaWidgetClass;
+ typedef struct _GLwDrawingAreaRec *GLwDrawingAreaWidget;
+ 
+-GLAPI WidgetClass glwDrawingAreaWidgetClass;
++extern GLAPI WidgetClass glwDrawingAreaWidgetClass;
+ 
+ 
+ #endif
-- 
2.11.0

Bug#863797: [Pkg-nagios-devel] Bug#863797: Bug#863797: monitoring-plugins-basic: unable to use check_disk inside /var/tmp

[Bas Couwenberg]

On 2017-05-31 16:52, Jan Wagner wrote:

Am 31.05.17 um 12:06 schrieb Emmanuel DECAEN:

In nrpe, system wide /var/tmp is no more reachable
$ grep "/var/tmp" /proc/11489/mountinfo
115 113 254:2 / /var/tmp/mysql rw,noatime,nodiratime shared:65
master:32- xfs /dev/mapper/v1-tmp rw,attr2,inode64,noquota
121 113 8:5
/tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-7xjqpw/tmp
/var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5 
rw,data=ordered

As you traced the problem yourself to nrpe, you might want to reassign
the bug to nagios-nrpe-plugin with appropriate version?


If NRPE cannot execute the checkcommand that implies that the nagios 
user doesn't have the required permissions.


The given checkcommand is not part of the default configuration:

 /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql

Which suggests that this is a configuration issue to be resolved by the 
administrator of the system. (e.g use sudo to execute the plugin as a 
users with the required permissions).


Kind Regards,

Bas

Bug#863637: kea-common: New isc-kea upstream release 1.2.0

[Maxime Lareo]

user product...@infomaniak.com
usertag 863637 + infomaniak.com-network
thank

Hi there,

I was trying to build the package with the new upstream distributed by
ISC for the release 1.2.0 but some issues shows up.

The upstream sources from the isc ftp server, last modified 2017-05-09,
have some trouble compiling with the option '--enable-generate-parser',
option that you are using to compile kea in the rules file.

Regards,

Maxime Lareo
Infomaniak Network SA



signature.asc
Description: OpenPGP digital signature

Bug#863825: ITP: ayatana-indicator-session -- Ayatana Indicator showing session management, status and user switching

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: ayatana-indicator-session
  Version : 0.4.0
  Upstream Author : Mike Gabriel 
Charles Kerr 
* URL : https://github.com/ArcticaProject/ayatana-indicator-session
* License : GPL
  Programming Lang: C++
  Description : Ayatana Indicator showing session management, status and 
user switching

 This Ayatana Indicator is designed to be placed on the right side of a panel 
and
 give the user easy control for changing their instant message status.  
 Switching to another user.  Starting a guest session.  Or controlling the
 status of their own session.
 .
 It requires some way to be hosted into a panel. For the MATE Panel the
 appropriate package is mate-indicator-applet. For the XFCE Panel the
 appropriate package is xfce4-indicator-plugin.

Bug#863797: [Pkg-nagios-devel] Bug#863797: monitoring-plugins-basic: unable to use check_disk inside /var/tmp

[Jan Wagner]

Hi Emmanuel,

thanks for bringing this to our attention.

Am 31.05.17 um 12:06 schrieb Emmanuel DECAEN:
> Package: monitoring-plugins-basic
> Version: 2.2-3
[...]
> After upgrade, check_disk on /var/tmp/mysql is broken.
> 
> Status using nrpe (wrong):
> DISK CRITICAL - /var/tmp/mysql is not accessible: No such file or directory
> 
> Status using bash (works correctly):
> $ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql
> DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);|
> /var/tmp/mysql=42MB;8184;9207;0;10230

Which is a strong indication that check_disk itself works as expected.

> In nrpe, system wide /var/tmp is no more reachable
> $ grep "/var/tmp" /proc/11489/mountinfo
> 115 113 254:2 / /var/tmp/mysql rw,noatime,nodiratime shared:65
> master:32- xfs /dev/mapper/v1-tmp rw,attr2,inode64,noquota
> 121 113 8:5
> /tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-7xjqpw/tmp
> /var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5 rw,data=ordered
As you traced the problem yourself to nrpe, you might want to reassign
the bug to nagios-nrpe-plugin with appropriate version?

Best regards, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--



signature.asc
Description: OpenPGP digital signature

Bug#863824: iputils-tracepath: traceroute6.iputils fails with IPv6 address

[Valentin Vidic]

Package: iputils-tracepath
Version: 3:20161105-1
Severity: important

Dear Maintainer,

It seems that traceroute6.iputils fails to work when given an address
instead of a hostname:

$ traceroute6.iputils localhost
traceroute to  (::1) from ::1, 30 hops max, 24 byte packets
 1  localhost (::1)  0.052 ms  0.021 ms  0.022 ms

$ traceroute6.iputils ::1
traceroute to ::1 (::1) from ::1, 30 hops max, 24 byte packets
sendto: Invalid argument
 1 traceroute: wrote ::1 24 chars, ret=-1
 *sendto: Invalid argument
traceroute: wrote ::1 24 chars, ret=-1
 *sendto: Invalid argument
traceroute: wrote ::1 24 chars, ret=-1
 *
sendto: Invalid argument
 2 traceroute: wrote ::1 24 chars, ret=-1
 *sendto: Invalid argument
traceroute: wrote ::1 24 chars, ret=-1

The differance in sendto seems to be the port number 33434 vs 0:

# strace traceroute6.iputils localhost
sendto(4, "\0\0\1\253\0\0\0\3\334\327.Y\0\0\0\0e\177\2\0\0\0\0\0", 24, 0, 
{sa_family=AF_INET6, sin6_port=htons(33434), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 24

# strace traceroute6.iputils ::1
sendto(4, "\0\0\1\232\0\0\0\3\227\327.Y\0\0\0\0\202\237\7\0\0\0\0\0", 24, 0, 
{sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 EINVAL (Invalid 
argument)


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-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/bash
Init: systemd (via /run/systemd/system)

Versions of packages iputils-tracepath depends on:
ii  libc6 2.24-11
ii  libcap2   1:2.25-1
ii  libidn11  1.33-1

iputils-tracepath recommends no packages.

Versions of packages iputils-tracepath suggests:
ii  traceroute  1:2.1.0-2

-- no debconf information

Bug#863799: ITP: redtick -- tiny pomodoro timer for Emacs

[Carsten Leonhardt]

Sean Whitton  writes:

>   Description : tiny pomodoro timer for Emacs

I'm curious to see the long description, as I don't see the relationship
between tomatoes and timers.

 - Carsten

Bug#862558: plasma-workspace: Freezes during login with fresh installed Stretch Japanese environment

[YOSHINO Yoshihito]

Followup-For: Bug #862558
Control: reassign -1 plasma-workspace
Control: affects -1 uim-qt5 uim-mozc
Control: tags -1 + patch

Dear Maintainer,

This is a bug in ksplashqml. An upstream commit
https://cgit.kde.org/plasma-workspace.git/commit/?id=56d2c15b9acb9c4b57398b281685807c3191f622
has caused this problem.

x-session-manag,133,kdetest /usr/bin/x-session-manager
  ├─(ksplashqml,232)
  ├─ssh-agent,191 /usr/bin/im-launch x-session-manager
  ├─uim-toolbar,220
  │   ├─{llvmpipe-0},235
  │   ├─{llvmpipe-1},236
  │   ├─{llvmpipe-2},237
  │   └─{llvmpipe-3},238
  └─uim-xim,219
ksplashqml,233,kdetest Breeze --pid
  ├─mozc_server,239
  │   ├─{IPCServer},244
  │   ├─{QueueTimer},240
  │   ├─{QueueTimer},243
  │   └─{WatchDog},242
  ├─uim-candwin-qt5,245 -v
  │   ├─{QDBusConnection},249
  │   └─{QXcbEventReader},248
  ├─{QDBusConnection},255
  ├─{QQmlThread},254
  ├─{QXcbEventReader},234
  ├─{llvmpipe-0},250
  ├─{llvmpipe-1},251
  ├─{llvmpipe-2},252
  └─{llvmpipe-3},253

# strace -f -p 133
strace: Process 133 attached
read(3, ^Cstrace: Process 133 detached
 

It looks like the parent process (133), x-session-manager (startkde
script), is waiting for the stdout of the ksplashqml process (232),
but which is now defunct. Its child process(es) may be writing to the
same fd.

# ls -l /proc/133/fd/3
lr-x-- 1 kdetest kdetest 64 May 31 05:13 /proc/133/fd/3 -> pipe:[88694]

The direct child of the ksplashqml process (233), the splash screen daemon,
closes the file descriptor at ksplash/ksplashqml/main.cpp:97.

# ls -l /proc/233/fd/1
ls: cannot access '/proc/233/fd/1': No such file or directory

One of the children of the process (239), mozc_server, is holding the fd:

# ls -l /proc/239/fd/1
l-wx-- 1 kdetest kdetest 64 May 31 05:14 /proc/239/fd/1 -> pipe:[88694]

So the startkde process has finished reading the pid number string from
the now-defunct process, but is still waiting for another write(s) until
the (shared) fd has been closed.

This mozc_server process has been started during uim-qt5
(a QPlatformInputContext) startup in the SplashApp
initialization phase at ksplash/ksplashqml/main.cpp:92.

Due to the upstream commit the splash screen daemon does not close file
descriptors before the SplashApp initialization, thus its subprocess
shares the fds.

The commit log states Wayland initialization of this daemon needs the
channels. While it may require open file descriptors 0, 1 or 2,
no one should expect the process to talk to the parent through the
descriptors, since the splash screen is a daemon.

An attached patch reverts the commit and redirects the file descriptors
to /dev/null.

Regards,
-- 
YOSHINO Yoshihito 
--- plasma-workspace-5.8.6.orig/ksplash/ksplashqml/main.cpp
+++ plasma-workspace-5.8.6/ksplash/ksplashqml/main.cpp
@@ -24,6 +24,9 @@
 #include 
 
 #include 
+#include 
+#include 
+#include 
 #include 
 
 void logMessageHandler(QtMsgType type, const char *msg)
@@ -83,6 +86,16 @@ int main(int argc, char **argv)
 
 return 0;
 }
+
+int devNull = open("/dev/null", O_RDWR);
+if (devNull == -1) {
+return -1;
+}
+// replace stdin,stdout,stderr, otherwise startkde will block
+dup2(devNull, 0);
+dup2(devNull, 1);
+dup2(devNull, 2);
+close(devNull);
 }
 
 //enable to send log output to /tmp/ksplash
@@ -91,13 +104,6 @@ int main(int argc, char **argv)
 QQuickWindow::setDefaultAlphaBuffer(true);
 SplashApp app(argc, argv);
 
-if (!test && !nofork) {
-// close stdin,stdout,stderr, otherwise startkde will block
-close(0);
-close(1);
-close(2);
-}
-
 return app.exec();
 }
 

Bug#863822: Use debhelper's meson support

[Iain Lane]

Package: src:fwupd
Version: 0.9.2-5
Severity: minor
Tags: patch

Hiya,

[ looks like -5 and the tags aren't pushed to git; I did gbp import-dsc
  to generate this patch ]

Since fwupd BDs on experimental's debhelper, we can make use of its
meson build system support. The attached patch does that. I debdiffed
the binaries, and it says this:

  laney@artful> debdiff fwupd_0.9.2-5_amd64.changes 
fwupd_0.9.2-5ubuntu1_amd64.changes  
 ~/temp
  [The following lists of changes regard files as different if they have
  different names, permissions or owners.]

  Files in second .changes but not in first
  -
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/01/3af5051e01f609d88a24c2a98b410b629caa81.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/08/e84eda01a60a0923123122ef866c2bca69c2d5.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/2c/5725d679a4ef2f8cd150ea2bd4d93a443e2069.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/47/b385eca94e521556da88fdc2942cc11c20ea86.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/48/9b60ef7c7eee7230bb06a34bda2ff19c8d2efc.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/5e/f6f628331b4924f82c93c92005f907f336e7e9.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/6b/8d5d642c972ef6297d4b071aa766a670599332.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/85/704afcd78cc7f548f7fa8d1c8eba062ff24822.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/88/1da077ad1eb160f20eab129062004de744fbb8.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/b5/0365171bc84e47f219c2157c1f5465bda60c81.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/bc/4d2c8e8105c10e6c9d10e4d47179ae43aaec8f.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/cb/1fbdc6628066b3c900752afe5a871a163a47b7.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/d9/a33254896af181f436dfba8387e928425e237b.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/ea/c0dbf7e27c954bdf648633783113d4acf9584b.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/ec/78c8d16608691eb205c923a0eaead4a7a57b60.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/f3/d1d3593e951d6d0f095bd699a89bbf8e58f91e.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/ff/6f16ec8c2f28839ac6bedf70e3d538b7afe52d.debug
  -rwxr-xr-x  root/root   /usr/lib/x86_64-linux-gnu/fwupd/fwupd

  Files in first .changes but not in second
  -
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/19/42ec06f23beac06ce3bc8bd88006d56e793f29.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/28/1c986adedadb6e25ca48aaa142b6d0fe8ab3d0.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/34/ddcb7ccf309d16d0903bfa9211be8dc17dcf04.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/43/861873324603e449bca099b1234346ed5502bb.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/48/69c61fc9c276012f66bf89ae17d0e44aa37b4e.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/5b/e12253d8834f87e263de8b55e980002b3a1de5.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/74/de05561d2293576300057d9fa654b3d68abfc3.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/79/fb0dbb9e8a6fb0b379edca7145769cca30bc1f.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/83/8667ba1ebf332f290f62507670d844884fef13.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/87/37cd721633ab03418bf6e66c889ada8f079576.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/89/be5d81f611c7c5799f445210d450da67f86d03.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/91/025839a49b3b3c20f5becbf799da56863a6cd3.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/93/7d81336efacb1619e4ebbbe3b2b0b5031fff37.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/a4/a8d3cbbd15e4306b9e84138d79cde2ee6c954d.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/b3/3f4a2dd1475e6c38124f5d9158c5bb007a076e.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/ba/1c06d2a6a6c363b31f0296c779a7b18ada5d9d.debug
  -rw-r--r--  root/root   
/usr/lib/debug/.build-id/de/aa5bf15cac0d0f7a398a65097f8b9e7867d59f.debug
  -rwxr-xr-x  root/root   /usr/lib/fwupd/fwupd

  Control files of package fwupd: lines which differ (wdiff format)
  -
  Version: [-0.9.2-5-] {+0.9.2-5ubuntu1+}

  Control files of package fwupd-dbgsym: lines which differ (wdiff format)
  
  Build-Ids: [-1942ec06f23beac06ce3bc8bd88006d56e793f29 
281c986adedadb6e25ca48aaa142b6d0fe8ab3d0 
34ddcb7ccf309d16d0903bfa9211be8dc17dcf04 
43861873324603e449bca099b1234346ed5502bb 
4869c61fc9c276012f66bf89ae17d0e44aa37b4e 
5be12253d8834f87e263de8b55e980002b3a1de5 
74de05561d2293576300057d9fa654b3d68abfc3 

Bug#863817: release-notes: Release notes for Stretch by Debian Med team

[Justin B Rye]

Andreas Tille wrote:
> I'd like to propose the following text from the Debian Med team for
> the Stretch release notes:
> 
> 
> News from Debian Med Blend
> 
> Besides several new packages and updates for software targeting

There might be a better alternative to "Besides" here, but if so I'm
not sure what it is.

> life sciences and medicine the Debian Med team has again put a focus on 
^
Maybe a comma after "medicine".

> the quality of the provided packages.  In a GSoC project and an 
> Outreachy project two students worked hard to add Continuous Integration 
   ^
Maybe a comma after "project", and just possibly make it "In one GSoC
and one Outreachy project".

> support to the packages with the highest usage statistics due to

s/due/according/, or just say "the highest popularity-contest usage
statistics".

> popularity contest.  The latest Debian Med sprint in Bukarest was also 
> targeting at testing packages.

s/Bukarest/Bucharest/ (if we aren't using "București").

s/was also targeting/also targeted/, but we've already used this verb,
so switch to "concentrated on".

s/testing packages/package testing/ (assuming it means software QA as
opposed to packages in Debian testing, or indeed medical testing).

> 
> To install packages maintained by the Debian Med team install the
   ^
Probably a comma after "team".

> metapackages named med-* which are at version 3.0.1 for Debian Stretch
^
Definitely needs a comma before "which" (to make it a description
rather than a definition), and definitely a full stop after "Stretch"!

Also, we're standardising on lowercase releasenames: "stretch".

> Feel free to visit the
> http://blends.debian.org/med/tasks;>Debian Med tasks 
> pages
> to see the full range of biological and medical software inside Debian.
> 

s/inside/in/, but this feels like a weak ending... slightly better
would be "available in".

So my revised version:

News from Debian Med Blend

Besides several new packages and updates for software targeting
life sciences and medicine, the Debian Med team has again put a focus on 
the quality of the provided packages.  In a GSoC project and an 
Outreachy project, two students worked hard to add Continuous Integration 
support to the packages with the highest popularity-contest usage
statistics.  The latest Debian Med sprint in Bucharest also
concentrated on package testing.

To install packages maintained by the Debian Med team, install the
metapackages named med-*, which are at version 3.0.1 for Debian stretch.
Feel free to visit the
http://blends.debian.org/med/tasks;>Debian Med tasks 
pages
to see the full range of biological and medical software available in 
Debian.


-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#863707: simple-tpm-pk11: FTBFS: ./m4/test-driver: line 107: 4695 Aborted (core dumped)

[Chris Lamb]

Hi Michael,

> Thanks for the report. Do you have a VM in which upstream (Thomas Habets)
> could reproduce the failure?

I'm inferring from this that you cannot reproduce it yourself? :)

I'm not sure I can provide any more details apart from that it also fails
on the Reproducible Builds testing framework (as well as my personal laptop
from which I submitted my bug report):

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/simple-tpm-pk11.html


Regards,

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

Bug#863201: libpam-ldap not longer installs the file /usr/share/pam-configs/ldap needed for pam-auth-update

[Lucas Castro]

I've uploaded libpam-ldap to mentors,

Sorry for delay.


Em 29-05-2017 12:09, Julián Moreno Patiño escreveu:
> Control: -1 + pending patch
>
> I've uploaded libpam-ldap 186-3.1 to DELAYED/5:
>   
> libpam-ldap (186-3.1) unstable; urgency=medium
>   
>   * Non-maintainer upload.
>   * Install /usr/share/pam-configs/ldap
> needed for pam-auth-update. (Closes: #863201)
>
> The full debdiff is attached.
>
>
> Regards,
>




signature.asc
Description: OpenPGP digital signature

Bug#772874: closed by IOhannes m zmölnig (Debian/GNU) <umlae...@debian.org> (either fixed or wontfix upstream.)

[Frank Heckenbach]

> 3) incompatible VOC files: upstream denies that there is a problem here.
> also i agree with upstream that the error message is pretty clear:
> "Error in VOC file, incompatible VOC sections" doesn't say "your VOC
> file is broken" but instead "it is incompatible with my notion of VOC
> files due to some issue with sections";

No, that's not what it says. It tries to shift the blame, instead of
at least saying something like: "Sorry, we don't support your VOC
files." (And now I reread my original report and see I suggested
this back then already, even with more detailed analysis. So
apparently you/upstream don't care about this, so I think it's best
to remove VOC support completely from the library.)

> in the future, please try report each issue in a separate bug, so they
> can be closed independently.

I guess in the future I won't bother to report bugs at all.

I mean, honestly, after almost 3 years you come and close one bug
(incorrectly IMHO), forward another one (that I did report
separately, #761240) and still ignore two more (#760898 and
#761307).

Of course, I didn't get to wait quite as long, so I've worked around
libsndfile long ago (for Ogg/Vorbis I use libvorbisfile, for WAV I
wrote a simple parser myself, and for VOC I call avconv as a
subprocess, which apparently has a better "notion of VOC files").

So I don't really care about those bugs anymore. For my sake, close
them all as wontfix.

At least I got a new mail signature out of this ...

-- 
"Error in Debian bug database, incompatible notion of bugs!" (#772874)

Bug#863821: alembic: please package 0.9.2

[Sandro Tosi]

Source: alembic
Version: 0.8.8-2
Severity: wishlist

Dear Maintainer,
a new alembic release is available, 0.9.2, please upgrade alembic in debian so
its user can take advantage of the new features and bug fixes!

thanks

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

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

Bug#863820: gcc-6-base: adding Breaks: tzdata-java to smoothen the openjdk 7 -> 8 upgrade path from jessie to stretch

[Andreas Beckmann]

Package: gcc-6-base
Version: 6.3.0-18
Severity: important

Hi Doko,

would it be possible to use gcc-6-base as the bigger hammer to smoothen
the openjdk 7 -> 8 upgrade from jessie to stretch?
The Breaks: tzdata-java added in openjdk-8-jre-headless (#857992)
improved the situation a lot, but I still see some corner cases where
switching to openjdk-8 is not considered by apt, and instead some jessie
packages are kept installed (the openjdk-7 stack, and especially tzdata 
is kept at the jessie version (that still has tzdata-java)).

A versioned Breaks against some openjdk-7 package would not work due to
new upstream releases being uploaded to (old)stable frequently.
An unversioned Breaks against some openjdk-7 package would render the
packages from experimental uninstallable in sid.

gcc-6-base should have a high enough score in apt to stop any attempts
to keep tzdata-java or openjdk-7 (from jessie) installed.

I'll now build a gcc-6 with that Breaks added ...


Andreas