Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev

[shirish शिरीष]

at bottom :-

On 27/02/2019, Dmitry Bogatov  wrote:
>



>
> Seems there is no /etc/init.d/mountkernfs.sh on your system.
>
> Since your init system is systemd, I question, why do you need insserv
> in first place. Do you have bin:initscripts installed?
>
> My guess is that update-initramfs invokes insserv /if/ it is available,
> and since you have insserv installed, but no initscripts, we get this
> bug.
>
> Adding initramfs-tools maintainer into loop. If my guess is correct,
> this issue should be resolved on initramfs side, since making insserv
> depending on initscripts is not nice to user.
> --
> Note, that I send and fetch email in batch, once every 24 hours.
>  If matter is urgent, try https://t.me/kaction
>
> --
>

Dear Dimity,

You are right on both counts. Indeed systemd is pid 0 on my system.

In answer to your query, I attempted -

$ aptitude why insserv
i   rcconf  Depends sysv-rc
i A sysv-rc Depends insserv (> 1.12.0-10)

Does this answer the question ?

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

Bug#923168: initscripts: Old cruft in initscripts postinst

[Pierre Ynard]

> Thank you very much for your research and patches. Can you please
> re-submit your patches in format, generated by `git format-patch'?
>
> What you included is `git show` output, which is not possible to apply
> directly. Thank you again.

Here you go.

-- 
Pierre Ynard
From 289d898ca707be223d4220951cdc3753d21e2df6 Mon Sep 17 00:00:00 2001
From: Pierre Ynard 
Date: Sun, 24 Feb 2019 17:29:36 +0100
Subject: [PATCH 1/2] Remove write-only variable left over from legacy
 migration postinst code

The code using that workaround is long gone.
---
 debian/initscripts.postinst | 6 --
 1 file changed, 6 deletions(-)

diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst
index c6ac94d..4ed27ec 100755
--- a/debian/initscripts.postinst
+++ b/debian/initscripts.postinst
@@ -9,12 +9,6 @@ set -e
 . /lib/init/tmpfs.sh
 . /lib/init/mount-functions.sh
 
-# Set this as a variable to hide from lintian the fact that we're removing
-# it; otherwise, a wrong lintian check + ftp fatal autoreject prevents us
-# from uploading this legitimate code, even though the previous upload was
-# accepted without incident.
-devshm=/dev/shm
-
 case "$1" in
   configure)
 	PREV_VER=$2
-- 
2.1.4

From 2f1e2ebf9e6154acabb419789ee193678e221300 Mon Sep 17 00:00:00 2001
From: Pierre Ynard 
Date: Sun, 24 Feb 2019 17:39:16 +0100
Subject: [PATCH 2/2] Clean up unused leftover legacy migration code from
 postinst

The postinst code using this was long cleaned up itself.
---
 debian/initscripts.postinst | 34 --
 1 file changed, 34 deletions(-)

diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst
index 4ed27ec..ad0eb4d 100755
--- a/debian/initscripts.postinst
+++ b/debian/initscripts.postinst
@@ -20,40 +20,6 @@ esac
 
 umask 022
 
-compat_link () {
-	SRC=$1
-	DEST=$2
-
-	ssrc="$(stat -L --format="%d %i" "$SRC" 2>/dev/null || :)"
-	sdest="$(stat -L --format="%d %i" "$DEST" 2>/dev/null || :)"
-
-	if [ -n "$ssrc" ] && [ "$ssrc" != "$sdest" ]; then
-		echo "guest environment detected: Linking $DEST to $SRC"
-		(
-			if [ -e $DEST ]; then
-if [ -L $DEST ]; then
-	echo "$DEST is already a symlink; not replacing with link to $SRC"
-	exit 0
-elif [ -d $DEST ]; then
-	rmdir $DEST || exit 1
-else
-	echo "$DEST isn't a directory or a symlink"
-	exit 1
-fi
-			fi
-			ln -fs $SRC $DEST
-		) || {
-			echo "Can't symlink $DEST to $SRC; please fix manually."
-			return 1
-		}
-		if which restorecon >/dev/null 2>&1; then
-			restorecon "$DEST"
-		fi
-	fi
-
-	return 0
-}
-
 # In 2.88dsf-23 the "mountoverflowtmp" script was dropped entirely.
 if dpkg --compare-versions "$PREV_VER" lt-nl "2.88dsf-23" ; then
 update-rc.d -f mountoverflowtmp remove >/dev/null
-- 
2.1.4

Bug#923378: unblock: spampd/2.53-1

[Michael Meskes]

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

Please unblock package spampd

Yes, I know it is a new upstream version, but all versions of spampd starting
with 2.40 had a breaking bug in LMTP processing for multiple recipients
(re-introducing the bug originally reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395355). When upstream
learned this, he released a new and fixed version. 

The only other change in the new upstream version is a fix for a warning
message that we had a very similar patch for. The only change is that upstream
put the initialization in question at a different line of the source file.

Finally I fixed an oversight by myself that upstream pointed out. The standard
way of calling spampd lacked the option "--setsid". I seem to have forgotten
the option when the prior patched-in solution was removed.

debdiff is attached.

Thanks

Michael

unblock spampd/2.53-1

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

Kernel: Linux 4.20.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru spampd-2.52/changelog.txt spampd-2.53/changelog.txt
--- spampd-2.52/changelog.txt   2018-11-10 10:24:14.0 +0100
+++ spampd-2.53/changelog.txt   2019-02-25 12:49:09.0 +0100
@@ -1,6 +1,11 @@
 SpamPD Change Log
 -
 
+2.53 (25-Feb-19)
+
+- Fix LMTP delivery with multiple recipients 
(https://github.com/mpaperno/spampd/issues/23 & 
https://github.com/mail-in-a-box/mailinabox/issues/1523)
+- Fix Warning for "Use of uninitialized value in string" 
(https://github.com/mpaperno/spampd/issues/22)
+
 2.52 (10-Nov-18)
 
 - Override Net::Server's HUP handling, just restart children 
(https://github.com/mpaperno/spampd/pull/20).
@@ -10,17 +15,11 @@
 
 2.51 (01-May-18)
 
-- Fix listening to IP address, broken in 2.50 "Unix ports" feature.  (#18)
-- Add --setsid option to start server with setsid if running in background 
(#18)
 - Fix listening to IP address, broken in 2.50 "Unix ports" feature.  
(https://github.com/mpaperno/spampd/pull/18)
 - Add --setsid option to start server with setsid if running in background 
(https://github.com/mpaperno/spampd/pull/18)
 
 2.50 (30-Apr-18)
 
-- Replace IO::Socket::INET with IO::Socket::IP for IPv6 support (#9).
-- Unix ports (ability to listen on UNIX sockets) (#13).
-- Add X-Envelope-* headers before Received (#14).
-- Add /usr/local/bin and /usr/local/sbin to PATH (#17).
 - Replace IO::Socket::INET with IO::Socket::IP for IPv6 support 
(https://github.com/mpaperno/spampd/pull/9).
 - Unix ports (ability to listen on UNIX sockets) 
(https://github.com/mpaperno/spampd/pull/13).
 - Add X-Envelope-* headers before Received 
(https://github.com/mpaperno/spampd/pull/14).
diff -Nru spampd-2.52/debian/changelog spampd-2.53/debian/changelog
--- spampd-2.52/debian/changelog2018-11-21 12:24:59.0 +0100
+++ spampd-2.53/debian/changelog2019-02-26 12:16:46.0 +0100
@@ -1,3 +1,11 @@
+spampd (2.53-1) unstable; urgency=medium
+
+  * New upstream version 2.53
+  * Use the --setsid argument to make sure the process is correctly detached.
+  * Bumped Standards-Version, no changes needed.
+
+ -- Michael Meskes   Tue, 26 Feb 2019 12:16:46 +0100
+
 spampd (2.52-1) unstable; urgency=medium
 
   * New upstream version 2.52 (Closes: #849543)
diff -Nru spampd-2.52/debian/control spampd-2.53/debian/control
--- spampd-2.52/debian/control  2018-11-21 12:21:27.0 +0100
+++ spampd-2.53/debian/control  2019-02-26 12:16:46.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Michael Meskes 
 Build-Depends: debhelper (>= 11), quilt, dh-exec
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Homepage: https://github.com/mpaperno/spampd
 
 Package: spampd
diff -Nru spampd-2.52/debian/patches/20-proto-warning.patch 
spampd-2.53/debian/patches/20-proto-warning.patch
--- spampd-2.52/debian/patches/20-proto-warning.patch   2018-11-21 
12:22:45.0 +0100
+++ spampd-2.53/debian/patches/20-proto-warning.patch   1970-01-01 
01:00:00.0 +0100
@@ -1,10 +0,0 @@
 spampd-2.52/spampd.pl.orig 2018-11-10 10:24:14.0 +0100
-+++ spampd-2.52/spampd.pl  2018-11-12 08:32:59.0 +0100
-@@ -145,6 +145,7 @@
- return 0 unless defined($_ = $self->_getline);
- s/[\r\n]*$//;
- $self->{state} = $_;
-+$self->{proto} = "(unknown)";
- if (s/^(l|h)?he?lo\s+//i) {  # mp: find helo|ehlo|lhlo
-   # mp: determine protocol
-   if (s/^helo\s+//i) {
diff -Nru spampd-2.52/debian/patches/series spampd-2.53/debian/patches/series
--- spampd-2.52/debian/patches/series   2018-11-21 12:24:02.0 +0100
+++ spampd-2.53/debian/patches/seri

Bug#923209: RFS: heaptrack/1.1.0+20180922.gitf752536-3.1 [NMU]

[Chris Lamb]

Hi Nicholas,

> Maybe it's obvious, but perhaps the developer's reference and
> wiki/PackageSalvaging would benefit from the addition of "Things to do
> before NMUing…for a team maintained package, […]  It's a
> trivial bit of work I'd be happy to do...

Go for it :)


Regards,

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

Bug#923380: progress-linux: [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: progress-linux
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege



fr.po.gz
Description: application/gzip

Bug#923379: u-boot: Dreamplug fails to detect SPI and USB

[Leigh Brown]

Package: u-boot
Version: 2019.01+dfsg-1
Severity: important
Tags: upstream

Dear Maintainer,

I flashed u-boot 2019.01+dfsg-1 on my Dreamplug. I found that u-boot was
unable to detect the SPI flash on the device (and thus could not read
the u-boot environment). It could also not detect the usb storage.

On booting, the following output is observed:

8<
U-Boot 2019.01+dfsg-1 (Jan 15 2019 - 00:36:19 +)
Marvell-DreamPlug

oC:   Kirkwood 88F6281_A1
DRAM:  512 MiB
Loading Environment from SPI Flash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

In:serial
Out:   serial
Err:   serial
Net:   egiga0
Error: egiga0 address not set.
, egiga1
Error: egiga1 address not set.

88E1116 Initialized on egiga0
88E1116 Initialized on egiga1
IDE:   ide_preinit failed
Hit any key to stop autoboot:  0
=> usb start
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
 ERROR: NOT USB_CONFIG_DESC a3
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
2 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
8<

I then compiled u-boot from the upstream git tree and tried various
versions.  The results are as follows:

v2018.01 all works
v2018.07 all works
v2018.09 all works
v2018.11 USB fails
v2019.01 SPI flash fails, USB fails

I then bisected both issues.  The USB issue was caused by the following
commit:

commit 93b283d49f933f95f3a6f40762936f454ac655a8
Author: Adam Ford 
Date:   Thu Aug 16 13:23:11 2018 -0500

ARM: CPU: arm926ejs: Consolidate cache routines to common file

Four different boards had different options for enabling cache
that were virtually all the same.  This consolidates these
common functions into arch/arm/cpu/arm926ejs/cache.c

This also has the positive side-effect of enabling cache on
the Davinci (da850) boards.

Signed-off-by: Adam Ford 
[trini: Add mach-at91 to the list of consolidations]
Signed-off-by: Tom Rini 

I used the following patch to temporarily fix up the issue (I am no
expert on ARM so cannot say whether this is in any way correct):

iff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c
index d54de53f31..8a065d73ae 100644
--- a/arch/arm/mach-kirkwood/cpu.c
+++ b/arch/arm/mach-kirkwood/cpu.c
@@ -291,7 +291,6 @@ int arch_misc_init(void)
temp |= (1 << 22);
writefr_extra_feature_reg(temp);
 
-   icache_enable();
/* Change reset vector to address 0x0 */
temp = get_cr();
set_cr(temp & ~CR_V);
diff --git a/include/configs/dreamplug.h b/include/configs/dreamplug.h
index f4d717213c..6348935c68 100644
--- a/include/configs/dreamplug.h
+++ b/include/configs/dreamplug.h
@@ -79,4 +79,6 @@
 #define CONFIG_SYS_ATA_IDE0_OFFSET MV_SATA_PORT0_OFFSET
 #endif /*CONFIG_MVSATA_IDE*/
 
+#define CONFIG_SYS_DCACHE_OFF
+
 #endif /* _CONFIG_DREAMPLUG_H */

I then bisected the SPI flash issue, and found it was caused by the
following commit:

commit 6aaf76beb131c2ff2b7184c2d63c2c63e5ab339c
Author: Chris Packham 
Date:   Wed Nov 21 22:22:23 2018 +1300


arm: kirkwood: configs: dreamplug: Convert to DM_SPI

Enable CONFIG_DM_SPI=y and CONFIG_DM_SPI_FLASH=y in the defconfig.

Signed-off-by: Chris Packham 
Reviewed-by: Stefan Roese 
Signed-off-by: Stefan Roese 

I don't know enough about u-boot to easily diagnose this issue.

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

Kernel: Linux 4.19.7+
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#918206: Pandas

[Andreas Tille]

Dear Rebecca,

On Wed, Feb 27, 2019 at 07:25:26AM +, Rebecca N. Palmer wrote:
> On 27/02/2019 07:00, Andreas Tille wrote:
> > Dear Rebecca,
> > I do not think that there is any
> > need for a separate branch.  Just stick to the debian branch.
> 
> It's needed because the debian branch contains the attempt at packaging 0.24
> described earlier in this thread, which it's now too late for.

You are right.  Considering the branching jungle (Yaroslav, could you possibly
cleanup branches that are not used any more?) I'd prefer if you would move the
0.24 packaging to some separate branch (debian-experimental is covered but may
be debian-0.24 or something like this?) and keep branch debian for what we are
really releasing.

Thanks again for your work on this

Andreas.

-- 
http://fam-tille.de

Bug#923381: x2broker: [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: x2broker
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege



fr.po.gz
Description: application/gzip

Bug#873086: ifupdown script disables IPv6 on parent of VLAN interface

[Roman Mamedov]

Hello,

I just hit this bug as well. From what I see this has been fixed in 1.5-16,
but Stretch currently contains 1.5-13+deb9u1. And 1.5-16 is not available in
any archive. The Buster version is 1.6-2. Is it possible to push the fixed
version to Stretch?

Thanks

-- 
With respect,
Roman

Bug#873086: ifupdown script disables IPv6 on parent of VLAN interface

[Roman Mamedov]

Hello,

Actually, both 1.6-2 and 1.5-16 still disable IPv6 on the parent interface for
me, in a config like this:

iface br-test inet static
  address 192.168.9.101
  netmask 255.255.255.0
  bridge-ports eth1.1008

After "ifup br-test", /proc/sys/net/ipv6/conf/eth1/disable_ipv6 is set to 1.

-- 
With respect,
Roman

Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)

[Domenico Andreoli]

On Tue, Feb 26, 2019 at 08:15:59PM +0100, Adam Borowski wrote:
> On Tue, Feb 26, 2019 at 06:06:18PM +0100, Domenico Andreoli wrote:
> > * Package name: dwarves-dfsg
> >   Version : 1.12-2
> 
> > Changes since the last upload:
> > 
> > dwarves-dfsg (1.12-2) unstable; urgency=medium
> > 
> >   * Convert to dh.
> >   * Fix Homepage and Vcs-Git.
> >   * Fix depends on debhelper >= 10.
> >   * Remove trailing spaces from the Debian changelog.
> >   * Update copyright to copyright-format/1.0. Closes: #919356.
> 
> Hi!

Hi,

> The new copyright file contains references to GPL-2.0-only and
> GPL-2.0-or-later without defining them.

According to https://spdx.org/licenses/ they are defined and supersede
GPL-2 and GPL-2+ now deprecated (maybe I should file a bug). OTOH I'm
reading that as long as copyright-format is not updated, new ones should
not be used.

Anyway, this is what I get if I switch to GPL-2 and GPL-2+ everywhere:

W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2+ 
(paragraph at line 102)
N: 
N:The files paragraph in the machine readable copyright file references a
N:license, for which no standalone license paragraph exists.
N:
N:Refer to
N:https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for
N:details.
N:
N:Severity: normal, Certainty: possible
N:
N:Check: source-copyright, Type: source
N: 
W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2 
(paragraph at line 94)

I spent quite some time in trying to understand what lintian tries
to tell me here. I verified that reshuffling the file does not help
either, these errors stay in a similar location, as if lintian had some
bug somewhere.

I also expected they to be repeated as many times as in the files (yes,
I'm using --no-tag-display-limit -i) but they are not and so at certain
point I gave up.

I'm uploaded a new version with GPL-2/GPL-2+, should be available shortly.

Thanks for reviewing.

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Bug#923330: jajuk: Fails to start with Java Runtime Environment 1.7 minimum required. You use a JVM ext.JVM@23fc625e

[Werner Mahr]

Am Mittwoch, 27. Februar 2019, 00:56:12 CET schrieben Sie:
> Am 26.02.19 um 21:34 schrieb Markus Koschany:
> > Thanks for reporting and the hint how to fix this problem. I'll take a
> > closer look soon.
> 
> Unfortunately there is another issue that prevents jajuk from starting.
> This appears to be the same one which affects triplea as well.
> 
> https://bugs.debian.org/911078

That's correct. I've seen your message exactly 1 minute after trying the fix 
from git.

-- 
MfG usw.

Werner Mahr

Bug#923374: root mode doesn't work anymore?

[Jonas Smedegaard]

Quoting Daniel Baumann (2019-02-27 05:18:53)
> with previous version of mmdebstrap, I used to do:
> 
>   sudo mmdebstrap sid sid http://deb.debian.org/debian
> 
> which then automatically uses 'root mode'.
> 
> Now I get this instead:
> 
> ---snip---
> I: automatically chosen mode: root
> I: chroot architecture amd64 is equal to the host's architecture
> I: running apt-get update...
> done
> Get:1 http://deb.debian.org/debian sid InRelease [242 kB]
> Get:2 http://deb.debian.org/debian sid/main amd64 Packages [8366 kB]
> Fetched 8608 kB in 2s (4984 kB/s)
> Reading package lists...
> W: Download is performed unsandboxed as root as file
> '/root/sid/var/lib/apt/lists/partial/deb.debian.org_debian_dists_sid_InRelease'
> couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission
> denied)
> apt-get update failed at /usr/bin/mmdebstrap line 569.
> ---snap---
> 
> Looking at the manpage I coudn't find anything obvious that I'm doing
> wrong. If there is, maybe the default behaviour could be made more
> user-friendly to 'just work'[tm]? Or is there a bug in 'root mode'?

I noticed such error message yesterday when running apt update inside a 
chroot - so perhaps this is not specific to mmdebstrap but is tied to 
apt or dpkg, especially the latter seeing major changes recently.


 - Jonas

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

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


signature.asc
Description: signature

Bug#922731: llvm-toolchain-7: Unjustified API breakage introduced by Debian patch

[Sylvestre Ledru]

I was waiting for 7.1.0 but as it isn't coming, I will upload it now

S


Le 26/02/2019 à 23:58, Svante Signell a écrit :

ping!

On Wed, 2019-02-20 at 12:51 +0100, Svante Signell wrote:

On Wed, 2019-02-20 at 09:21 +0100, Sylvestre Ledru wrote:

Bug#923382: libseqlib: FTBFS (dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file)

[Santiago Vila]

Package: src:libseqlib
Version: 1.1.2+dfsg-2
Severity: serious
Tags: ftbfs

Hello Andreas et al.

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


[...]
 debian/rules build-arch
dh build-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
libtoolize: 'AC_PROG_RANLIB' is rendered obsolete by 'LT_INIT'
configure.ac:17: installing './compile'
configure.ac:19: installing './config.guess'
configure.ac:19: installing './config.sub'
configure.ac:4: installing './missing'
src/Makefile.am: installing './depcomp'
   dh_auto_configure -a
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of g++... none
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking for ranlib... ranlib
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... (cached) ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared 
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is p

Bug#921294: No need to block buster

[Santiago Vila]

On Sun, 24 Feb 2019, Dominik George wrote:

> Control: severity 921297 normal
> Control: severity 921298 normal
> Control: severity 921294 normal
> Control: severity 921300 normal
> 
> As the new doxygen will not make it into buster (as apparently, it
> causes major breakage), there is no need to block reverse dependencies
> as long as they build with the doxygen currently in buster.
> 
> (Mind that they actually do *not* currently build, but for anotehr
> reason - see #921779).

Hi. I don't fully understand this.

For example: How is fltk1.3_1.3.4-8 supposed to propagate to testing
when it FTBFS in the arch:all autobuilder?

https://buildd.debian.org/status/package.php?p=fltk1%2e3

Thanks.

Bug#743138: [Pkg-utopia-maintainers] Bug#743138: Bug#743138: Bug#743138: [Needs upstream 0.9.10 release] Please only enable ifupdown plugin when ifupdown installed

[Michael Biebl]

Am 27.02.19 um 08:09 schrieb Guus Sliepen:
> On Tue, Feb 26, 2019 at 10:37:28PM +0100, Michael Biebl wrote:
> 
 Andrej, I'm fine with dropping ifupdown from the default NM
 configuration if the ifupdown package is going to ship such a config
 snippet for NM.
>>>
>>> Are we talking about /etc/NetworkManager/dispatcher.d/01-ifupdown here?
>>> It seems like a hack to avoid having to update some packages to directly
>>> support NetworkManager. For the long run, it's probably better if we
>>> don't have this dependence on scripts written for ifupdown.
>>
>> No, we are talking about the ifupdown plugin in NM, i.e.
>> /usr/lib/*/NetworkManager/1.14.6/libnm-settings-plugin-ifupdown.so
>>
>> which is responsible for parsing /etc/network/interfaces (and depending
>> on whether managed=true or false, simply ignores interfaces configured
>> in /e/n/i or tries to apply the configuration set there)
> 
> Ah, OK.
> 
>> ifupdown could ship the file as /etc/NetworkManager/conf.d/ifupdown.conf
>> This would have the downside, that the ifupdown plugin would still be
>> active if the ifupdown package is removed, but not purged.
> 
> But it could just check for /sbin/ifup being executable before
> continuing, just like init scripts do. Even better, the plugin could
> just call system("/sbin/ifquery ") to check whether an
> interface is managed by ifupdown or not. If the return value is 0, it
> means it's managed. If it's anything else, either ifupdown is not
> installed or it is but that interface is not known to ifupdown.

If the idea is to load and run less code in NM, this would mean we have
to add more. So at a first glance this doesn't look very compelling.


Also, if we wanted to find devices which should not be touched by NM
because they are defined in /e/n/i, is ifquery really sufficient to do that?
Say I have a br0 and eth0 in bridge_ports.
What will ifquery eth0 return in such a case?

Personally, I've never been a fan of the ifupdown plugin in NM. Parsing
the /e/n/i file is hairy and incomplete.
Especially the managed=true mode is something I would like to get rid off.
If we removed managed=true mode, all that would remain from the ifupdown
plugin is to mark devices as unmanaged by NM if they are defined in
/e/n/i. In such a case we might consider replacing the handwritten
parser and just exec ifquery.
Maybe this could even be replaced by a udev rule which runs ifquery and
sets ENV{NM_UNMANAGED}='1'

-- 
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#920984: nextcloud-desktop: Client forgets credentials

[kaliko]

Thanks Sandro (and everyone involved) for your work on this :)

Cheers
k



signature.asc
Description: OpenPGP digital signature

Bug#895115: Package does not seem to migrate to testing due to missing build on arm64

[Rhonda D'Vine]

   Hi!

On 2/27/19 8:52 AM, Andreas Tille wrote:
> I'm just pinging both RC bugs to reset the autoremoval from testing
> counter.  I just realised that the package might not migrate to testing
> due to a missing arm64 build.  I leave it to you to decide about the
> action to take but just wanted to prevent that you will be hit by an
> autoremoval which might have escaped your attention.

 Thanks.  The discussions about whether (and how) to add support to
automatically make beep available to non-root users did hold it back a
bit.  The patch for making it build on arm64 is prepared, I just wasn't
too sure what to do about the discussions on whether it's fine to leave
local adaption to the admin (and potentially improve the documentation
about it), or to offer support through the packaging for it.  Given that
an additional dependency on acl doesn't sound too encouraging, and
whether a TAG+="uaccess" might be more useful instead (which I haven't
tried yet), this sort of blocked my thoughts from just uploading the fix
so far.

 So .. thanks for the ping, will get around to it later today. :)
Rhonda

Bug#923219: ITP: eclipse-package -- Utility for creating Eclipse Debian packages

[Philipp Meisberger]

Hi Emmanuel,

this would be great!

Thanks,
Philipp

Am 26.02.19 um 23:15 schrieb Emmanuel Bourg:
> Hi Philipp,
> 
> On Mon, 25 Feb 2019 09:10:40 +0100 Philipp Meisberger
>  wrote:
> 
>> This package provides the capability to build a Debian package from an 
>> Eclipse binary distribution by running make-eclipsepkg > file>. Download the archive file from 
>> https://www.eclipse.org/downloads/eclipse-packages/
>>
>> This package is a good addition to Debian since there seems no such 
>> application. I often use it. The package is no dependency for other 
>> packages. I am looking for a sponsor.
> 
> This would be a good fit for the Java Team. I'll be happy to sponsor it.
> 
> Emmanuel Bourg
> 



signature.asc
Description: OpenPGP digital signature

Bug#923246: binutils: ld segfaults building pacemaker in unstable

[Matthias Klose]

Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=24276

ld and gold agree on the warning, and gold emits an error.  ld should not
segfault, but the errors seems to be in the construction of libqb.so.

Bug#923384: please add mod_net_dovecotauth

[W. Martin Borgert]

Package: prosody-modules
Version: 0.0~hg20190203.b54e98d5c4a1+dfsg-1
Severity: wishlist

mod_net_dovecotauth is a server implementation of the Dovecot
authentication protocol. It allows you to authenticate e.g.
Postfix against your Prosody installation.

Due to missing support for virtal hosts in this protocol, only
one host can be supported.

I need this module to authenticate users of one prosody instance
against another one. The former needs mod_auth_dovecot enabled,
which is already in the package.

Bug#922699: caja: Caja crash when copying paste

[Vlad Orlov]

Hi,

I'm not able to reproduce it in my Debian Testing VM. Don't have it installed 
on baremetal,
maybe it's relevant. Anyway, the full backtrace might give some hints... can 
you obtain it?
You'll need to do the following:

1. Run the debugger with the latest dump from Caja:

$ coredumpctl debug caja

It should show some info and gdb's prompt, (gdb).

2. Run the command to get the full backtrace in gdb's prompt:

(gdb) bt full

And post the result of it.

To quit gdb, use 'q' command:

(gdb) q

Bug#857130: os-prober: add support for veracrypt system encryption on UEFI

[Nat Harward]

Also hoping for an update on this, I've been hacking my grub.cfg file manually 
to work around this.
Saw this bug and used the provided file (thank you!) on Arch with os-prober 
1.76 - works like a charm.

Bug#921294: No need to block buster

[Dominik George]

Hi,

> > As the new doxygen will not make it into buster (as apparently, it
> > causes major breakage), there is no need to block reverse dependencies
> > as long as they build with the doxygen currently in buster.
> > 
> > (Mind that they actually do *not* currently build, but for anotehr
> > reason - see #921779).
> 
> Hi. I don't fully understand this.
> 
> For example: How is fltk1.3_1.3.4-8 supposed to propagate to testing
> when it FTBFS in the arch:all autobuilder?

It failed, but due to another bug.

Or maybe your bug reports are not clear enough - you are saying that the
build will fail with doxygen 1.8.15, but doxygen 1.8.15 is not in Debian
testing (and neither in sid). So *this* bug does not break the build for
Debian buster.

-nik


signature.asc
Description: PGP signature

Bug#922699: caja: Caja crash when copying paste

[Frédéric MASSOT]

Le 27/02/2019 à 11:40, Vlad Orlov a écrit :
> Hi,
> 
> I'm not able to reproduce it in my Debian Testing VM. Don't have it installed 
> on baremetal,
> maybe it's relevant. Anyway, the full backtrace might give some hints... can 
> you obtain it?
> You'll need to do the following:
> 
> 1. Run the debugger with the latest dump from Caja:
> 
> $ coredumpctl debug caja
> 
> It should show some info and gdb's prompt, (gdb).
> 
> 2. Run the command to get the full backtrace in gdb's prompt:
> 
> (gdb) bt full
> 
> And post the result of it.

Hi,

The result of the full backtrace:


#0  0xf70165f3 in g_file_query_info (file=0x5668c828
, attributes=0x5671de65
"standard::display-name", flags=G_FILE_QUERY_INFO_NONE,
cancellable=0x59063c30 [GCancellable], error=0x0) at
../../../gio/gfile.c:1303
__inst = 0x5668c828
__r = 
_g_boolean_var_ = 
iface = 
__FUNCTION__ = "g_file_query_info"
#1  0x566863f2 in custom_basename_to_string (format=0xee224090 "%B",
va=0xeed87f50 "\001") at caja-file-operations.c:827
file = 0x5668c828 
info = 
name = 
basename = 
tmp = 
#2  0x566f5996 in eel_strdup_vprintf_with_custom (custom=0x567e5700
, format=0xf38217ac , va_orig=0xeed87f44 "\002") at eel-string.c:714
va = 0xeed87f4c "(\310hV\001"
p = 0xf38217da 
num_args = 
i = 
j = 3
args = 0xee220bb0
type = 
conversions = 0xee22c810
f = 
str = 0xf2d5acc0
flags = 
width = 
mod = 
pos = 
s = 
__func__ = "eel_strdup_vprintf_with_custom"
#3  0x566861a7 in f (format=0xf38217ac ) at caja-file-operations.c:940
va = 0xeed87f44 "\002"
res = 
#4  0x5668c933 in report_copy_progress
(copy_job=copy_job@entry=0x58b04570,
source_info=source_info@entry=0xeed87ffc,
transfer_info=transfer_info@entry=0xeed88010) at caja-file-operations.c:3005
files_left = 
total_size = 
elapsed = 
transfer_rate = 
remaining_time = 
now = 
job = 0x58b04570
is_move = 0
#5  0x5668e67a in copy_files (transfer_info=0xeed88010,
source_info=0xeed87ffc, dest_fs_id=0xee260280 "l2049", job=0x58b04570)
at caja-file-operations.c:4516
common = 0x58b04570
dest_fs_type = 0x0
inf = 
src = 
unique_names = 
readonly_source_fs = 0
l = 
same_fs = 
i = 
point = 
skipped_file = -151639012
dest = 
source_dir = 
job = 
common = 
source_info = {num_files = 2, num_bytes = 4137,
num_files_since_progress = 2, op = OP_KIND_COPY}
transfer_info = {num_files = 0, num_bytes = 0, op =
OP_KIND_COPY, last_report_time = 181390712176, last_reported_files_left = 2}
dest_fs_id = 0xee260280 "l2049"
dest = 
#6  0x5668e67a in copy_job (io_job=0xecb0c580, cancellable=, user_data=) at caja-file-operations.c:4650
job = 
common = 
source_info = {num_files = 2, num_bytes = 4137,
num_files_since_progress = 2, op = OP_KIND_COPY}
transfer_info = {num_files = 0, num_bytes = 0, op =
OP_KIND_COPY, last_report_time = 181390712176, last_reported_files_left = 2}
dest_fs_id = 0xee260280 "l2049"
dest = 
#7  0xf703400b in io_job_thread (task=0x59065db0 [GTask],
source_object=0x0, task_data=0xecb0c580, cancellable=0x59063c30
[GCancellable]) at ../../../gio/gioscheduler.c:85
job = 0xecb0c580
result = 
#8  0xf706110f in g_task_thread_pool_thread (thread_data=0x59065db0,
pool_data=0x0) at ../../../gio/gtask.c:1331
task = 0x59065db0 [GTask]
#9  0xf6e9f87d in g_thread_pool_thread_proxy (data=0x582cede0) at
../../../glib/gthreadpool.c:307
task = 0x59065db0
pool = 0x582cede0
#10 0xf6e9ee2a in g_thread_proxy (data=0x586e94f0) at
../../../glib/gthread.c:784
thread = 0x586e94f0
__FUNCTION__ = "g_thread_proxy"
#11 0xf6994fd2 in start_thread (arg=) at pthread_create.c:486
ret = 
pd = 
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-157630464,
-287798464, -157630464, -287800856, 2006751563, -201207429},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev =
0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
#12 0xf68aa276 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108



Regards.
-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Bug#914606: apache2 setup-instance (apache-multi) logrotation (#914606)

[Horst Platz]

Hi Moritz,

after some days surveilance logrotation works now as expected.

Thx again Horst

Am 20. Februar 2019 11:02:54 MEZ schrieb Moritz Schlarb :
>Control: tags -1 + patch
>
>Hi Horst,
>
>I've prepared a patch for this issue:
>https://salsa.debian.org/apache-team/apache2/merge_requests/7
>
>Regards,

Bug#923385: ecryptfs-utils: Can no longer move files between ecryptfs-mounted directories

[Matijs van Zuijlen]

Package: ecryptfs-utils
Version: 111-4
Severity: important

Dear maintainer,

I have had an encrypted directory ~/.Private mounted as ~/Private for
quite some time. Since about two hours, I can no longer move files
within that directory:

$ cd ~/Private
$ mkdir foo
$ cd foo
$ touch bar
$ mv bar baz
mv: cannot move 'bar' to a subdirectory of itself, 'baz'

Copying, overwriting and deleting files works fine.

Please let me know if I can provide any further information to debug
this.

Kind regards,
Matijs van Zuijlen

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

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

Versions of packages ecryptfs-utils depends on:
ii  gettext-base0.19.8.1-9
ii  keyutils1.6-4
ii  libassuan0  2.5.2-1
ii  libc6   2.28-7
ii  libecryptfs1111-4
ii  libgpg-error0   1.35-1
ii  libgpgme11  1.12.0-6
ii  libkeyutils11.6-4
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5
ii  libtspi10.3.14+fixed1-1

ecryptfs-utils recommends no packages.

Versions of packages ecryptfs-utils suggests:
pn  cryptsetup  

-- no debconf information

Bug#923247: Request: Qt 5.12 before the full freeze

[Dmitry Shachnev]

Hi all,

On Mon, Feb 25, 2019 at 01:07:10PM +0100, Salvi Loris wrote:
> libqt has a bug with okular Duplex printer option fixed in 5.12, but in
> SID there is still libQt 5.11.x . It's possibile to have libQt 5.12
> before the full-freeze?
> This is a known bug from wheezy and would be great to have finally fixed.
>
> This is the link of a bug opened on Qt bugreports:
> https://bugreports.qt.io/browse/QTBUG-71824 .

On Mon, Feb 25, 2019 at 09:42:16AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> It does not seems to be a particular patch but a full rewrite of the code, so
> not, I'm afraid it will not be possible.

However the issue with duplex printing should be fixed in qtbase 5.11.3+dfsg-4
where I backported commit [1] from upstream.

[1]: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=fa854f214a3c812e

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#921294: No need to block buster

[Dominik George]

> At least in the case of fltk1.3's originally reported failure, the
> culprit turned out to be texlive-latex-extra -- Doxygen's
> (preexisting) usage of (long)tabu wound up running afoul of #920459. I
> haven't had time to investigate the latest failure, but see a new
> tl-l-e showed up, and suspect an accidental regression on that front.

Correct, will be fixed today.

-nik


signature.asc
Description: PGP signature

Bug#918578: maybe something to try

[Holger Levsen]

hi,

from irc:

 | sunweaver: but if you have some spare cycles, maybe you could look 
into #918578 ;)
-  zwiebelbot- | (#debian-release) Debian#918578: gosa: GOsa web interface 
missing password field - https://bugs.debian.org/918578
 I have the gosa bug on my radar, but no idea, yet.
 I have seen it once, when I test-installed unstable's smarty3 on a 
stretch Debian Edu TJENER.
 so, it might be unrelated to gosa, in fact.

maybe someone could try to reproduce this: on stretch, install smarty3
from sid and see if this bug pops up.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#921294: No need to block buster

[Aaron M. Ucko]

At least in the case of fltk1.3's originally reported failure, the culprit 
turned out to be texlive-latex-extra -- Doxygen's (preexisting) usage of 
(long)tabu wound up running afoul of #920459. I haven't had time to investigate 
the latest failure, but see a new tl-l-e showed up, and suspect an accidental 
regression on that front. 

On February 27, 2019 5:53:43 AM EST, Dominik George  
wrote:
>Hi,
>
>> > As the new doxygen will not make it into buster (as apparently, it
>> > causes major breakage), there is no need to block reverse
>dependencies
>> > as long as they build with the doxygen currently in buster.
>> > 
>> > (Mind that they actually do *not* currently build, but for anotehr
>> > reason - see #921779).
>> 
>> Hi. I don't fully understand this.
>> 
>> For example: How is fltk1.3_1.3.4-8 supposed to propagate to testing
>> when it FTBFS in the arch:all autobuilder?
>
>It failed, but due to another bug.
>
>Or maybe your bug reports are not clear enough - you are saying that
>the
>build will fail with doxygen 1.8.15, but doxygen 1.8.15 is not in
>Debian
>testing (and neither in sid). So *this* bug does not break the build
>for
>Debian buster.
>
>-nik

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#923387: udisks2: Please support new logind virtual packages

[Mark Hindley]

Package: udisks2
Version: 2.1.3-4
Severity: normal
Tags: patch

Dear Maintainer,

Please change udisks2 to use the new default-logind and logind virtual packages.
This will enable udisks2 to also be used on systems using elogind and
non-systemd inits.

The logind and default-logind virtual packages have been seconded for inclusion
in Debian Policy (see #917431) and libpam-elogind and libpam-systemd providing
these have been uploaded.   
 

Patch below.

Thanks

Mark

commit 7de85e517d65985463a9e609749c88e21f6df06a
Author: Mark Hindley 
Date:   Wed Feb 27 10:17:50 2019 +

Depend on new default-logind | logind virtual packages.

diff --git a/debian/control b/debian/control
index 45401909..808559e9 100644
--- a/debian/control
+++ b/debian/control
@@ -48,7 +48,7 @@ Depends: dbus,
  libblockdev-swap2,
  libblockdev-loop2,
  libblockdev-fs2,
- libpam-systemd,
+ default-logind | logind,
  parted,
  udev,
  ${misc:Depends},

Bug#908216: btrfs blocked for more than 120 seconds

[Russell Mosemann]

Two servers hung last night. Both events happened while a file was being copied 
into the btrfs file system. No references or vm's were involved. It was a 
simple file copy.
 
I had the opportunity to observe the system while it happened. It turns out 
that the CPU time goes to 50% or more I/O wait. The servers have 6 cores/12 
threads running at 3.5GHz. It is like the operating system goes into an 
infinite loop, banging away at the disk. Letting it sit for hours does not 
resolve the problem. The only solution I'm aware of at this time is to reboot 
the server. Restarting the copy process after a reboot sometimes triggers the 
same bug, and sometimes it works fine.
 
--
Russell Mosemann

Bug#922081: pyparted: Please enable build-time tests in pyparted

[Herbert Fortes]

Hi,

> The last try is here:
> 
> mips,  mips64el and  mipsel are important
> for release and they fail.
> 

The test I skip for these archs has this first
assert:

self.assertGreater(len(parted.getLabels()), 0)

The __init__.py file inside parted has:

def getLabels(arch=None):
[...]
for label, regex in __archLabels:
if re.match(regex, arch):
labels.add(label)

return labels


__archLabels is a tuple without mips*. I think this is
why test fails.

https://sources.debian.org/src/pyparted/3.11.2-9/src/parted/__init__.py/#L362

Can you give me your opinion on that?



Regards,
Herbert

Bug#923386: RM: python-schema-salad & python-typing-extensions -- ROM; binary packages for Python 2 no longer needed

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

Hello,

Please remove the binary package python-schema-salad version
2.6.20171201034858-3 and the binary package python-typing-extensions version
3.7.2-1 from the archive. We now only need and build for Python 3
and these packages are holding up the migration of python3-typing-extensions:
https://qa.debian.org/excuses.php?package=python-typing-extensions

Thanks!

Bug#751632: DPMI mode in DOSEMU does not work on 4.9.0-8-amd64

[Roger Korby]

Hi there,

The DPMI mode in DOSEMU does not appear to work on kernel 4.9.0-8-amd64 either. 
This bug seems to be re-occurring.

Roger.


Roger Korby, CEO

PIANOS.CA Inc. | www.pianos.ca

911 Golf Links Road | Ancaster, ON L9K 1H9 | Canada



This communication is intended only for the named recipient(s) and is private, 
confidential and privileged. Any unauthorized use or disclosure of this 
communication is prohibited.

Bug#921840: metar: Parsing metar record fails due to changes in NOAA API

[Peter Palfrader]

Kees, ping!

On Sat, 09 Feb 2019, Sven Paulus wrote:

> * What led up to the situation?
> 
> On February 4th the "metar" tool stopped working.
> At this point NOAA switched responding on their HTTP URL with metar data
> to returning a redirect to the HTTPS variante of the URL.


weasel@orinoco:~$ metar lows
METAR pattern not found in NOAA data.
weasel@orinoco:~$ 
METARURL=https://tgftp.nws.noaa.gov/data/observations/metar/stations/ metar lows
LOWS 271220Z VRB03KT CAVOK 15/M00 Q1027 NOSIG

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#923388: germinate: Homepage missing from package metadata

[Jonas Smedegaard]

Package: germinate
Version: 2.30
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The germinate package does not provide a Homepage URL
as part of its metadata.

I suggest to list this as its Homepage: https://wiki.ubuntu.com/Germinate

Thanks for considering,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlx2h4UACgkQLHwxRsGg
ASEbVBAAq2UyG/AlmQHfIX949wm+vj7fODPC8GNTrp5Hyrt7oTWysauq6LpvtD9x
R0XCxkrNYRhNKGocuRgSNCBcLl8y6ZT5l/BCGA2Ttkr9M7QWS0VbciqM3NFqz/WI
xI2KkxD74oJarxYNgu9bFDN2zbrCtjkKiepntzVHH3h0zi6PFZCtFeFxjRhMaU/a
4wxLHvEq3AkMivfS/mgV2bSGH2IB31nYLug9Tprn1b8mWyyezI+C6v6kgU2SytX+
WowJ49/P1G7B0pKZVCszdfMvs6aUVfeOAem3wSGxUhZf4Jk+9XrRvA5sMKI4OEY9
FPCWmUb2g3RknhnZkA0wmUsNzq9a6XDu2l6YEeHa4e1CNuJPKZf+elSCVqVPEj8z
bF9ySj32Ycr2A7s/bgXAw0lI0NlxOhNRgMa8+VAcDjz/3eSLK6gYnHfNSrLfBsx8
UMjvfaR6dDZVgcxNDulJrPlQat/idAAwb8CLq31qZInmWDBqkozj0+XYc06grDKq
wvSdxveErOiEehsswLuz+2bOvYt2+ktTN8yLbUbOoUbmH7iwRwEmeQr8Y7lBueGB
d2wjZPhDXqO1RFOopd7IktMJN55wifuZQ1qWkwz7AGStyKvRkpCmgu0eRVUxDGP5
UD7sMIwnF4eL33TZckfPVfulbYT8oTLhpOaFQWxl4FqAbtrZh2w=
=jq8c
-END PGP SIGNATURE-

Bug#921363: [Pkg-javascript-devel] Bug#921363: Package does not migrate to testing

[Xavier]

Le 27/02/2019 à 13:40, Xavier a écrit :
> Le 27/02/2019 à 08:47, Andreas Tille a écrit :
>> Hi Utkarsh,
>>
>> I realised that you intend to take over this package but for a reason I
>> do not understand myself it does not migrate to testing (see testing
>> excuses at the tracker page:
>>
>>https://tracker.debian.org/pkg/ejs.js
>>
>> ).
>>
>> I admit I have no idea why but if you really want to save this package
>> for Buster some action seems to be needed.  Please do not ask me
>> personally about it since I do not have the slightest interest in this
>> package at all but simply realised that it has the autoremoval from
>> testing flag set despite your upload.
>>
>> Thank you for your contribution
>>
>> Andreas.
> 
> Hello,
> 
> I filled a BTS to ftp.debian.org to remove this source package: a
> node-ejs package exists with a up-to-date GitHub repo (that's why
> migration is blocked). There is no reverse dependency to ejs.js (the
> only one requires node-ejs >= 2.5.2 while ejs.js is 1.0.0 due to old
> GitHub repo, so points to src:node-ejs). libjs-ejs isn't used by any
> package.
> 
> Cheers,
> Xavier

Ref: https://bugs.debian.org/923294

Bug#923389: [systemd] CVE-2018-15686 not fixed in stretch stable

[Jean-Pierre Stierlin]

Package: systemd
Version: 232-25+deb9u9
Severity: grave
Tags: security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org

--- Please enter the report below this line. ---

Hi,

According to https://security-tracker.debian.org/tracker/CVE-2018-15686, 
the systemd package is still vulnerable.


Are there any plans to backport this fix to the stable version, as it 
was done for jessie ?


Best regards,

Jean-Pierre.

--- System information. ---
Architecture:
Kernel: Linux 4.9.0-8-amd64

Debian Release: 9.8
500 stable-updates ftp.fr.debian.org
500 stable security.debian.org
500 stable ftp.fr.debian.org

--- Package information. ---
Depends (Version) | Installed
==-+- 


libacl1 (>= 2.2.51-8) | 2.2.52-3+b1
libapparmor1 (>= 2.9.0-3+exp2) | 2.11.0-3+deb9u2
libaudit1 (>= 1:2.2.1) | 1:2.6.7-2
libblkid1 (>= 2.19.1) | 2.29.2-1+deb9u1
libc6 (>= 2.17) | 2.24-11+deb9u4
libcap2 (>= 1:2.10) | 1:2.25-1
libcryptsetup4 (>= 2:1.4.3) | 2:1.7.3-4
libgcrypt20 (>= 1.7.0) | 1.7.6-2+deb9u3
libgpg-error0 (>= 1.14) | 1.26-2
libidn11 (>= 1.13) | 1.33-1
libip4tc0 (>= 1.6.0+snapshot20161117) | 1.6.0+snapshot20161117-6
libkmod2 (>= 5~) | 23-2
liblz4-1 (>= 0.0~r127) | 0.0~r131-2+b1
liblzma5 (>= 5.1.1alpha+20120614) | 5.2.2-1.2+b1
libmount1 (>= 2.26.2) | 2.29.2-1+deb9u1
libpam0g (>= 0.99.7.1) | 1.1.8-3.6
libseccomp2 (>= 2.3.1) | 2.3.1-2.1+deb9u1
libselinux1 (>= 2.1.9) | 2.6-3+b3
libsystemd0 (= 232-25+deb9u9) | 232-25+deb9u9
util-linux (>= 2.27.1) | 2.29.2-1+deb9u1
mount (>= 2.26) | 2.29.2-1+deb9u1
adduser | 3.115
procps | 2:3.3.12-3+deb9u1


Package Status (Version) | Installed
==-+-===
udev | 232-25+deb9u9
dracut |
initramfs-tools | 0.130


Recommends (Version) | Installed
=-+-===
libpam-systemd | 232-25+deb9u9
dbus | 1.10.26-0+deb9u1


Suggests (Version) | Installed
-+-===
systemd-ui |
systemd-container |
policykit-1 | 0.105-18+deb9u1



--- Output from package bug script ---

Bug#803342: I switched to dwww

[sixerjman]

No problems experieced with dwww's cron daily or weekly jobs.

Bug#918578: maybe something to try

[Wolfgang Schweer]

On Wed, Feb 27, 2019 at 11:45:23AM +, Holger Levsen wrote:
>  | sunweaver: but if you have some spare cycles, maybe you could look 
> into #918578 ;)
> -  zwiebelbot- | (#debian-release) Debian#918578: gosa: GOsa web interface 
> missing password field - https://bugs.debian.org/918578
>  I have the gosa bug on my radar, but no idea, yet.
>  I have seen it once, when I test-installed unstable's smarty3 on 
> a stretch Debian Edu TJENER.
>  so, it might be unrelated to gosa, in fact.

It is unrelated to gosa (and to smarty3, too).
Actually, it's the changed PHP 7.3 cgi configuration. This bug's log 
should contain enough information about it, see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918578#51

Also, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918578#56

contains a link to the buster manual's upgrade chapter with more 
information what needs to be fixed if upgrading from stretch.

> maybe someone could try to reproduce this: on stretch, install smarty3
> from sid and see if this bug pops up.

smarty3 Depends: php | php-cgi | php-cli, php-common

So PHP7.3 is pulled in, triggering the bug, I figure.

Maybe gosa's postinst could contain code to fix the cgi configuration.
Also, gosa supports lighttpd. Upgrading in this case should be tested as 
well.

Wolfgang


signature.asc
Description: PGP signature

Bug#923387: [Pkg-utopia-maintainers] Bug#923387: udisks2: Please support new logind virtual packages

[Michael Biebl]

Control: tags -1 + moreinfo

Am 27.02.19 um 13:26 schrieb Mark Hindley:
> Package: udisks2
> Version: 2.1.3-4
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> Please change udisks2 to use the new default-logind and logind virtual 
> packages.
> This will enable udisks2 to also be used on systems using elogind and
> non-systemd inits.
> 
> The logind and default-logind virtual packages have been seconded for 
> inclusion
> in Debian Policy (see #917431) and libpam-elogind and libpam-systemd providing
> these have been uploaded. 
>
> 

udisks e.g. uses sd_uid_is_on_seat() and links against libsystemd0 for that.
It is my understanding though reading through #923244 that the
combination libsystemd0 + elogind is not functional as elogind does not
guarantee ABI compatibility with logind.


-- 
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#923244: [Pkg-utopia-maintainers] Bug#923244: policykit-1: Please support elogind backend

[Michael Biebl]

Hi

Am 25.02.19 um 12:49 schrieb Mark Hindley:
> Package: policykit-1
> Version: 0.105-25
> Severity: normal
> 
> Dear Maintainers,
> 
> policykit-1 needs specific support for elogind, an alternative implementation 
> of
> the DBus login1 API for systems not running systemd as pid 1.  Without this
> pkexec and items such as restart, suspend and shut down from the desktop are
> either unavailable or do not function correctly.
> 
> Choice of policykit-1 backend is currently made at compilation time. 
> 
> There appear to be 3 possible choices for adding elogind support:
> 
>  1) Change policykit-1 source to be configured and built twice against both
> libsystemd-dev and libelogind-dev, generating different flavour binary
> packages for users to install.
> 
>  2) Implement some sort of runtime dlopen switching.
>  
>  3) Commit libelogind to always be ABI compatible with libsystemd and arrange
> for libelogind to ship its own version of libsystemd.so.
> 
> Of these, 2) has been suggested by Adam Borowski, but I have not seen a 
> working
> implementation. 3) seems to have the potential for numerous incompatibility 
> and
> maintenance issues. I have proof of concept patches for 1) both against 
> 0.105-25
> and 0.115.
> 
> I am happy to work with you to provide tested patches. Perhaps you could
> indicate which route you would lkie to follow or suggest alternatives we have
> not considered.

I think, only 3) has a chance to work in Debian (or a slight
modification of it).
A complete rebuild against libelogind-dev is only reasonable for source
based distros, where you either rebuild the whole world against systemd
or elogind.
Keep in mind, that we have dozens of packages using logind via
libsystemd0 and not only via the D-Bus API. Recompiling and providing
different flavours for all of them is not going to work, as it will
basically be impossible to get a consistent set of working packages
installed.
elogind should not only have a compatible D-Bus API with logind, clients
using the sd_ API via libsystemd should also not be broken.
Ideally, libelogind0 should not be used at all in Debian.

Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log

[Vincent Blut]

Hi Francesco,

On Mon, Feb 25, 2019 at 10:07:28PM +0100, Francesco Poli wrote:

On Mon, 25 Feb 2019 01:22:40 +0100 Vincent Blut wrote:


On Sun, Feb 24, 2019 at 08:19:02PM +0100, Francesco Poli wrote:
>On Sun, 24 Feb 2019 17:52:46 +0100 Vincent Blut wrote:
>
>> Please use `ps ax | grep chrony' (or ps -ef). `ps a' only lists
>> processes with a tty.
>
>You are right, sorry: I wanted to simplify the command output, but I
>overplayed...   ;-)
>Anyway, chronyd really fails to start:
>
>  # ps ax | grep chrony
>  12035 pts/0S+ 0:00 grep chrony

Interesting. Does `grep -i chrony /var/log/messages' report something
suspect?


Nothing is added to /var/log/messages when chrony fails to start.


Ok so I think I can reproduce this issue on a Debian Buster i386 virtual 
machine. However, to double check that I’m facing the same issue as 
yours, I’d like you to:


- stop the chronyd daemon
# service chrony stop

- install strace
# apt install strace

- use the log directive in chrony.conf (“log measurements” alone 
 suffices to trigger the issue)


- execute strace on chronyd
# strace -o chronyd_debug.txt chronyd -d -F -1

- don’t forget to attach the chronyd_debug.txt file when you answer ;-)

Hmm, that’s fairly strange. I failed to reproduce this issue on some 
of my systems. Would you please share your chrony.conf file 
(privately if you prefer)?


I think there's nothing really special in it.
I've attached it.


Indeed, nothing unusual here.


There's another important thing that I should mention.
Today I have upgraded chrony on another box and the system call filter
works fine there (with mailonchange disabled, but with log *enabled*).

So I tried to think about the differences between the box where it
fails, and the box where it works.

The first difference is the architecture:
• the box where it fails is i386


Indeed, this is due to a missing syscall needed for this architecture 
(and probably some other 32-bit plateforms) in the seccomp filter.



• the box where it works is amd64
However, I suspect that chrony level of abstraction is high enough to
make this difference immaterial... Or am I wrong?


See Above.


The second difference is the init system and might be more relevant:
• the box where it fails runs with sysvinit as PID 1
• the box where it works runs with systemd as PID 1


I think it is safe to exclude PID 1 as the cause of this issue.

Thanks for yout time,
Vincent


signature.asc
Description: PGP signature

Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)

[Adam Borowski]

On Wed, Feb 27, 2019 at 09:33:43AM +0100, Domenico Andreoli wrote:
> On Tue, Feb 26, 2019 at 08:15:59PM +0100, Adam Borowski wrote:
> > On Tue, Feb 26, 2019 at 06:06:18PM +0100, Domenico Andreoli wrote:
> > > * Package name: dwarves-dfsg
> > >   Version : 1.12-2

> > >   * Update copyright to copyright-format/1.0. Closes: #919356.

> > The new copyright file contains references to GPL-2.0-only and
> > GPL-2.0-or-later without defining them.
> 
> According to https://spdx.org/licenses/ they are defined and supersede
> GPL-2 and GPL-2+ now deprecated (maybe I should file a bug). OTOH I'm
> reading that as long as copyright-format is not updated, new ones should
> not be used.

SPDX has nothing to the copyright-format.  The latter doesn't care about
short names at all, merely that 1. every file has a license, and 2. every
license is defined.

Thus, "GPL-2", "GPL-2+", "GPL-2.0-only", "GPL-2.0-or-later", "Meow-meow"
and "Cthulhu-fhtagn" have exactly the same meaning: they're merely
identifiers that need to be defined elsewhere in the file.  Obviously,
for human readers we still want GPL to mean GPL -- but it's a syntax vs
content distinction.

> Anyway, this is what I get if I switch to GPL-2 and GPL-2+ everywhere:
> 
> W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2+ 
> (paragraph at line 102)
> N: 
> N:The files paragraph in the machine readable copyright file references a
> N:license, for which no standalone license paragraph exists.
> N:
> N:Refer to
> N:https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for
> N:details.
> N:
> N:Severity: normal, Certainty: possible
> N:
> N:Check: source-copyright, Type: source
> N: 
> W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2 
> (paragraph at line 94)

So it does if you say "GPL-2.0-only" or "GPL-2.0-or-later"...

> I spent quite some time in trying to understand what lintian tries
> to tell me here. I verified that reshuffling the file does not help
> either, these errors stay in a similar location, as if lintian had some
> bug somewhere.

"references a license, for which no standalone license paragraph exists"

> I'm uploaded a new version with GPL-2/GPL-2+, should be available shortly.

I don't see it on mentors yet...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄

Bug#923390: Umlet package missing from the desktop menu

[Rui Maciel]

Package: hello
Version: 13.3-1.1

The umlet installer does not register umlet by not installing a desktop entry.

I've attached a desktop entry which, when installed in the
applications' directory (i.e., /usr/share/applications), enables Umlet
to be featured among the system's applications.


umlet.desktop
Description: application/desktop

Bug#831835: [Friendly Reminder] Survey regarding your Extension bcma for Mozilla Firefox

[Benedict Bender]

 
Dear Sir or Madam,

Recently we invited you to participate concerning your extension BCMA
for MOZILLA FIREFOX. We note that you have not yet completed the
survey, and wish to remind you that the survey is still available
should you wish to take part:
https://survey.wi.uni-potsdam.de/index.php/738581?token=PoHTPajH&lang=en
[https://survey.wi.uni-potsdam.de/index.php/738581?token=PoHTPajH&lang=en]

The University of Potsdam is currently conducting research regarding
coring of extension functionality on digital platforms in the browser
context.

Specifically, we are interested in which _effects result to you as a
developer_ from platform coring. Furthermore, which measures and
options you have to influence coring activities. The results are of
utmost importance for any developer that contributes extensions to
digital platforms such as Mozilla Firefox or Google Chrome.

PLATFORM CORING is defined as the integration of functionalities
provided by third-party extensions in the platform core, whereby the
core is the browser (platform).
For example, if a new version of a Browser (e.g. Chrome or Firefox) is
released with additional functionality (e.g. security features,
bookmarking features) which were formerly provided by extensions, this
is considered to be platform coring. In a nutshell, functionality
formerly (only) provided through extensions is now available in the
browser itself.

We recognized that you provide an extension called BCMA on the
Marketplace for MOZILLA FIREFOX. Therefore _your thoughts are highly
valuable_ to our study!

Please take FIVE MINUTES TO PARTICIPATE in our survey
at: HTTPS://SURVEY.WI.UNI-POTSDAM.DE/INDEX.PHP/738581?TOKEN=POHTPAJH&LANG=EN
[https://survey.wi.uni-potsdam.de/index.php/738581?token=PoHTPajH&lang=en].

Why should you participate in our survey?

* As the ANALYSIS RESULTS PROVIDE VALUABLE INPUT FOR YOUR BUSINESS
we would be happy to provide you those. If you are interested, just
leave your email address during the survey.
* Your valuable input is of great interest for our research. If
there is anything we can do for you please let us know.

If you are interested in our research regarding coring on digital
platforms please feel free to have a look at our recent research paper
[https://aisel.aisnet.org/icis2017/DigitalPlatforms/Presentations/6/]
or contact me.

Thank you very much for effort with regard to this survey!
Sincerely,
Benedict Bender (benedict.ben...@wi.uni-potsdam.de)

--
Click here to do the survey:
https://survey.wi.uni-potsdam.de/index.php/738581?token=PoHTPajH&lang=en
[https://survey.wi.uni-potsdam.de/index.php/738581?token=PoHTPajH&lang=en]

If you do not want to participate in this survey and don't want to
receive any more invitations please click the following link:
https://survey.wi.uni-potsdam.de/index.php/optout/tokens/738581?langcode=en&token=PoHTPajH
[https://survey.wi.uni-potsdam.de/index.php/optout/tokens/738581?langcode=en&token=PoHTPajH]
 

Bug#921363: [Pkg-javascript-devel] Bug#921363: Package does not migrate to testing

[Xavier]

Le 27/02/2019 à 08:47, Andreas Tille a écrit :
> Hi Utkarsh,
> 
> I realised that you intend to take over this package but for a reason I
> do not understand myself it does not migrate to testing (see testing
> excuses at the tracker page:
> 
>https://tracker.debian.org/pkg/ejs.js
> 
> ).
> 
> I admit I have no idea why but if you really want to save this package
> for Buster some action seems to be needed.  Please do not ask me
> personally about it since I do not have the slightest interest in this
> package at all but simply realised that it has the autoremoval from
> testing flag set despite your upload.
> 
> Thank you for your contribution
> 
> Andreas.

Hello,

I filled a BTS to ftp.debian.org to remove this source package: a
node-ejs package exists with a up-to-date GitHub repo (that's why
migration is blocked). There is no reverse dependency to ejs.js (the
only one requires node-ejs >= 2.5.2 while ejs.js is 1.0.0 due to old
GitHub repo, so points to src:node-ejs). libjs-ejs isn't used by any
package.

Cheers,
Xavier

Bug#629902: dh_installinit: should support LSB compliant scripts

[Michael Biebl]

I might be missing something obvious here, but why is the service
started after installation if it's not configured?

And if the package insist on this behaviour, why does it not use the
existing dh_installinit --error-handler mechanism to explicitly define
the behaviour it wants?

I'm not convinced that such a --lsb flag is a good idea.

-- 
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#921363: [Pkg-javascript-devel] Bug#921363: Package does not migrate to testing

[Andreas Tille]

On Wed, Feb 27, 2019 at 01:40:44PM +0100, Xavier wrote:
> 
> I filled a BTS to ftp.debian.org to remove this source package: a
> node-ejs package exists with a up-to-date GitHub repo (that's why
> migration is blocked). There is no reverse dependency to ejs.js (the
> only one requires node-ejs >= 2.5.2 while ejs.js is 1.0.0 due to old
> GitHub repo, so points to src:node-ejs). libjs-ejs isn't used by any
> package.

Perfectly fine for me.

Kind regards

Andreas. 

-- 
http://fam-tille.de

Bug#919231: Salt-master unable to access directories

[Felipe Sateler]

Control: found -1 241-5
Control: tags -1 confirmed upstream
Control: forwarded -1 https://github.com/systemd/systemd/issues/11842

I was able to reproduce the issue, and forwarded this upstream.

-- 

Saludos,
Felipe Sateler

Bug#921840: Upload necessary before March 2nd (Buster hard freeze), Bug #921840 NOAA URL -> https

[Daniel Lange]

Hoi Kees,

could you please upload a new version of Metar before March 2nd as the 
Buster hard freeze is coming up March 12 and the current delay is 10 
days for packages to transition to testing.


Bug #921840 is the related Debian bug.

If you currently don't have the time, I can NMU but you have everything 
ready in your Github repo already.


Vriendelijke groet,
Daniel

Bug#742182: samba-tool gpo aclcheck always fails with uncaught exception error

[L. van Belle]

Please reopen, not fixed in 4.8.9 and 4.9.4. 


























Best regards, 














Louis

Bug#923391: Uses another classifier if build with jdk >= 9

[Sjoerd Simons]

Source: hikaricp
Version: 2.7.1
Severity: important
Tags: patch

When rebuilding hikaricp with a jdk newer then 9 it adds a java9 classifier,
which will unfortually cause it's build dependencies (e.g. libquartz2-java) to
then fail.

Attaching a debdiff which adds a patch to drop using the classifier so the
result is consistend independent of the java version used for build

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru hikaricp-2.7.1/debian/changelog hikaricp-2.7.1/debian/changelog
--- hikaricp-2.7.1/debian/changelog 2017-09-12 23:57:47.0 +0200
+++ hikaricp-2.7.1/debian/changelog 2019-02-27 14:19:28.0 +0100
@@ -1,3 +1,11 @@
+hikaricp (2.7.1-1co1) apertis; urgency=medium
+
+  * d/p/drop-java9-classifier.patch: Added, drop the java9 classifier if build
+with jdk >= 9. Prevents packages from hitting FTBS when building against
+hikaricp build with jdk 9 which built fine with older hikaricp builds.
+
+ -- Sjoerd Simons   Wed, 27 Feb 2019 14:19:28 
+0100
+
 hikaricp (2.7.1-1) unstable; urgency=medium
 
   * New upstream version 2.7.1 (Closes: #875368)
diff -Nru hikaricp-2.7.1/debian/patches/drop-java9-classifier.patch 
hikaricp-2.7.1/debian/patches/drop-java9-classifier.patch
--- hikaricp-2.7.1/debian/patches/drop-java9-classifier.patch   1970-01-01 
01:00:00.0 +0100
+++ hikaricp-2.7.1/debian/patches/drop-java9-classifier.patch   2019-02-27 
14:17:19.0 +0100
@@ -0,0 +1,29 @@
+--- a/pom.xml
 b/pom.xml
+@@ -442,22 +442,26 @@
+
+ 
+
++   
+ 
++   
+ 
+   
+  coverage
diff -Nru hikaricp-2.7.1/debian/patches/series 
hikaricp-2.7.1/debian/patches/series
--- hikaricp-2.7.1/debian/patches/series2017-09-12 23:57:42.0 
+0200
+++ hikaricp-2.7.1/debian/patches/series2019-02-27 14:12:11.0 
+0100
@@ -1 +1,2 @@
 skip-hibernate-prometheus-micrometer
+drop-java9-classifier.patch

Bug#922729: bug is in arch-test

[Adam Borowski]

> Other than uninstalling arch-test, there appears to be no way to tell
> debootstrap to ignore, or at least downgrade arch-test results to a
> warning. I'm not sure if a commandlinne option and/or environment
> variable would be the preferred workaround.

It's a bug in arch-test -- one I don't quite understand: even if newer
compilers could have dropped the use of SWP, I can't seem to reproduce this
failure even on jessie.  A Pine64 with CONFIG_ARMV8_DEPRECATED=n on kernel
5.0-rc6, yet any jessie programs other than ghc work -- I remember anything
with thread support crashing immediately.  No idea what could have changed.

I've dropped the check (both for SIGILL and for whether SWP gets silently
ignored) -- worst case, there'll be false positives where debootstrap
installs something that doesn't work.

In general, I don't think debootstrap should work around bugs elsewhere;
the design principle for arch-test is to err on the false positive rather
than false negative side, thus setups that fail the test should be nearly
useless.

For the record, here's the list of checks above basic syscall test:
* armhf: dmb (ARMv7)
* i386: cmovz (686)
* powerpc: fsel (!SPE)
* powerpcspe: efscfsi (SPE)
* ppc64el: mtvsrd (POWER8)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄

Bug#923287: firefox: Open with/Save as dialog slow to respond

[Dmitry Shachnev]

On Mon, Feb 25, 2019 at 06:31:14PM -0300, Alexandre Lymberopoulos wrote:
> Dear Maintainer,
>
> Once Firefox opens the Save As or Open With window to take action on a
> given file it hangs with almost all the window rendered (not the
> buttons). After a few seconds the buttons are drawn but not
> responsible.

I can confirm this behavior.

I have opened Firefox in GDB and got a stacktrace when the dialog is opened.

Looks like there is a very deep recursion (or stack corruption, which
is not better):

[same as below, repeated many times]
#78324 nsXULElement::QueryInterface(nsID const&, void**) 
(aInstancePtr=0x7fffb8f0, aIID=..., this=0x7fffd4098040)
at 
/build/firefox-AFMdyg/firefox-65.0.1/build-browser/dist/include/nsCOMPtr.h:1104
#78325 nsXULElement::QueryInterface(nsID const&, void**) (this=0x7fffd4098040, 
aIID=..., aInstancePtr=0x7fffb8f0)
at /build/firefox-AFMdyg/firefox-65.0.1/dom/xul/nsXULElement.cpp:297

Bottom of the stack trace is attached.

--
Dmitry Shachnev
#78320 0x704bdb8d in nsXULElement::QueryInterface(nsID const&, void**) 
(aInstancePtr=0x7fffb8f0, aIID=..., this=0x7fffd4098040) at 
/build/firefox-AFMdyg/firefox-65.0.1/build-browser/dist/include/nsCOMPtr.h:1104
#78321 0x704bdb8d in nsXULElement::QueryInterface(nsID const&, void**) 
(this=0x7fffd4098040, aIID=..., aInstancePtr=0x7fffb8f0) at 
/build/firefox-AFMdyg/firefox-65.0.1/dom/xul/nsXULElement.cpp:297
#78322 0x704bdb8d in nsXULElement::QueryInterface(nsID const&, void**) 
(aInstancePtr=0x7fffb8f0, aIID=..., this=0x7fffd4098040) at 
/build/firefox-AFMdyg/firefox-65.0.1/build-browser/dist/include/nsCOMPtr.h:1104
#78323 0x704bdb8d in nsXULElement::QueryInterface(nsID const&, void**) 
(this=0x7fffd4098040, aIID=..., aInstancePtr=0x7fffb8f0) at 
/build/firefox-AFMdyg/firefox-65.0.1/dom/xul/nsXULElement.cpp:297
#78324 0x704bdb8d in nsXULElement::QueryInterface(nsID const&, void**) 
(aInstancePtr=0x7fffb8f0, aIID=..., this=0x7fffd4098040) at 
/build/firefox-AFMdyg/firefox-65.0.1/build-browser/dist/include/nsCOMPtr.h:1104
#78325 0x704bdb8d in nsXULElement::QueryInterface(nsID const&, void**) 
(this=0x7fffd4098040, aIID=..., aInstancePtr=0x7fffb8f0) at 
/build/firefox-AFMdyg/firefox-65.0.1/dom/xul/nsXULElement.cpp:297
#78326 0x7fffee4ff0f6 in nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper 
const&, nsID const&) (this=this@entry=0x7fffb918, aHelper=..., aIID=...) at 
/build/firefox-AFMdyg/firefox-65.0.1/xpcom/base/nsCOMPtr.cpp:109
#78327 0x704a8e83 in 
nsCOMPtr::nsCOMPtr(nsCOMPtr_helper const&) 
(aHelper=..., this=0x7fffb918) at 
/build/firefox-AFMdyg/firefox-65.0.1/build-browser/dist/include/nsCOMPtr.h:420
#78328 0x704a8e83 in nsXULElement::IsFocusableInternal(int*, bool) 
(this=0x7fffd4098040, aTabIndex=0x7fffb99c, aWithMouse=) at 
/build/firefox-AFMdyg/firefox-65.0.1/dom/xul/nsXULElement.cpp:440
#78329 0x7fffef3201b6 in nsIContent::IsFocusable(int*, bool) 
(this=0x7fffd4098040, aTabIndex=aTabIndex@entry=0x7fffb99c, 
aWithMouse=aWithMouse@entry=false) at 
/build/firefox-AFMdyg/firefox-65.0.1/dom/base/FragmentOrElement.cpp:1124
#78330 0x7084b830 in nsIFrame::IsFocusable(int*, bool) 
(this=0x7fffb73e1a68, aTabIndex=0x0, aWithMouse=) at 
/build/firefox-AFMdyg/firefox-65.0.1/build-browser/dist/include/nsCOMPtr.h:836
#78331 0x7fffef3baf7b in 
nsFocusManager::CheckIfFocusable(mozilla::dom::Element*, unsigned int) 
(this=this@entry=0x7fffebb65e40, aElement=aElement@entry=0x7fffd4098040, 
aFlags=aFlags@entry=0) at 
/build/firefox-AFMdyg/firefox-65.0.1/dom/base/nsFocusManager.cpp:1530
#78332 0x7fffef3f5d9f in nsFocusManager::Focus(nsPIDOMWindowOuter*, 
mozilla::dom::Element*, unsigned int, bool, bool, bool, bool, nsIContent*) 
(this=this@entry=0x7fffebb65e40, aWindow=0x7fffd3fd2420, 
aElement=aElement@entry=0x7fffd4098040, aFlags=aFlags@entry=0, 
aIsNewDocument=aIsNewDocument@entry=true, 
aFocusChanged=aFocusChanged@entry=false, aWindowRaised=true, 
aAdjustWidgets=true, aContentLostFocus=0x0) at 
/build/firefox-AFMdyg/firefox-65.0.1/dom/base/nsFocusManager.cpp:1818
#78333 0x7fffef3f76d2 in nsFocusManager::WindowRaised(mozIDOMWindowProxy*) 
(this=0x7fffebb65e40, aWindow=aWindow@entry=0x7fffd3fd2420) at 
/build/firefox-AFMdyg/firefox-65.0.1/build-browser/dist/include/nsCOMPtr.h:1408
#78334 0x713bd05f in nsWebShellWindow::WindowActivated() 
(this=0x7fffd47cf7a0) at 
/build/firefox-AFMdyg/firefox-65.0.1/xpfe/appshell/nsWebShellWindow.cpp:452
#78335 0x713bd0f8 in 
nsWebShellWindow::WidgetListenerDelegate::WindowActivated() (this=) at 
/build/firefox-AFMdyg/firefox-65.0.1/xpfe/appshell/nsWebShellWindow.cpp:793
#78336 0x7061d032 in nsWindow::OnContainerFocusInEvent(_GdkEventFocus*) 
(this=this@entry=0x7fffd470e400, aEvent=aEvent@entry=0x7fffd30cd8e0) at 
/build/firefox-AFMdyg/firefox-65.0.1/widget/gtk/nsWindow.cpp:2622
#78337 0x7061d14a in focus_in_event_cb(GtkWidget*, GdkEventFocus*)

Bug#922081: pyparted: Please enable build-time tests in pyparted

[Steve Langasek]

On Wed, Feb 27, 2019 at 08:55:13AM -0300, Herbert Fortes wrote:
> > The last try is here:

> > mips,  mips64el and  mipsel are important
> > for release and they fail.

> The test I skip for these archs has this first
> assert:

> self.assertGreater(len(parted.getLabels()), 0)

> The __init__.py file inside parted has:

> def getLabels(arch=None):
> [...]
> for label, regex in __archLabels:
> if re.match(regex, arch):
> labels.add(label)
> 
> return labels

> __archLabels is a tuple without mips*. I think this is
> why test fails.

> https://sources.debian.org/src/pyparted/3.11.2-9/src/parted/__init__.py/#L362

> Can you give me your opinion on that?

I have no opinion on the internals of pyparted.  There should certainly be
some partition table types recognized as valid on mips, but I'm also not a
mips porter so can't say which.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#923392: bluez: Bluetooth daemon is blocked by rfkill

[Corcodel Marian]

Package: bluez
Version: 5.43-2+deb9u1
Severity: normal

Try to connect on bluetooth device but fail to connect.
Inspect with journalctl -r and find :
 Feb 27 14:48:48 debian bluetoothd[1586]: Failed to set mode: Blocked through
rfkill (0x12)






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

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

Versions of packages bluez depends on:
ii  dbus 1.10.26-0+deb9u1
ii  init-system-helpers  1.48
ii  kmod 23-2
ii  libc62.24-11+deb9u4
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libreadline7 7.0-3
ii  libudev1 232-25+deb9u8
ii  lsb-base 9.20161125
ii  udev 232-25+deb9u8

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  10.0-1+deb9u1

-- no debconf information

Bug#923393: CONFIG_DRM_I915_GVT_KVMGT is not enabled

[Michael Fritscher]

Package: linux-image-4.19.0-2-amd64
Version: 4.19.16-1

I would like to try GVT like described in
https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide to get native
3D accelaration in a KVM guest. Unfortunately, the kernel compile
options CONFIG_DRM_I915_GVT and CONFIG_DRM_I915_GVT_KVMGT are not set.
So I can't use it with the provided kernels.

Can it be enabled in the official builds?

Best regards,
Michael Fritscher

Bug#922916: network-manager: I think it's the same as #922554. No wifi connection is possible.

[Steve Newcomb]

> Do you have network-manager-config-connectivity-debian installed or
enabled connectivity checking via other means?

> Can you provide a debug log of network-manager please.
See https://wiki.gnome.org/Projects/NetworkManager/Debugging

The good news is that this problem disappeared after the next aptitude update.
But it remains a mystery.

This morning I found the information I think you're looking for in
/var/log/syslog.6.gz.  During the time of this log, I did an aptitute
update and rebooted, after which the wifi didn't work.  I'm attaching the
result of

gunzip -c syslog.6.gz | egrep '(NetworkManager|Starting Flush Journal to
Persistent Storage|wifi)' | xz -c9 /tmp/basil-syslog-selections.xz

to this email.  The file begins with wifi in working condition.  Lines
containing "Starting Flush Journal..." show when the machine is booting
up.


basil-syslog-selections.xz
Description: application/xz

Bug#923394: Unblock: webext-tbsync/1.7-1, webext-dav4tbsync/0.15, webext-eas4tbsync/0,12

[Mechtilde Stehmann]

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

Please unblock
webext-tbsync/1.7-1
webext-dav4tbsync/0.15
webext-eas4tbsync/0,12

They contain some important fixes to use thunderbird/lightning version
60.x to connect to an Exchange-Server.
-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#923392: Acknowledgement (bluez: Bluetooth daemon is blocked by rfkill)

[Corcodel Marian]

On 2/27/19 3:03 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 923392: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923392.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
   corcodel.mar...@gmail.com
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
  Debian Bluetooth Maintainers 

If you wish to submit further information on this problem, please
send it to 923...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

run from terminal as root root@debian:/home/as# systemctl stop 
systemd-rfkill.socket

and can connect to bluetooth audio device.

Bug#923356: unblock: prelude-lml/4.1.0-1+b2

[Mattia Rizzolo]

On Tue, Feb 26, 2019 at 04:24:00PM -0500, Thomas Andrejak wrote:
> unblock prelude-lml/4.1.0-1+b2

make this

unblock prelude-lml/4.1.0-2

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#920823: phpmyadmin: CVE-2019-6799: PMASA-2019-1

[Sylvain Beucler]

Uploaded to jessie-security.

Bug#923395: lxc: LXC container creation fails due to config file parse error

[Christoph Döpmann]

Package: lxc
Version: 1:3.1.0+really3.0.3-4
Severity: important

Dear Maintainer,

I just freshly installed the abovementioned LXC version (none was 
installed before).
When trying to create a simple container, I am experiencing the 
following issue:


  $ sudo lxc-create -t debian -n testcon -- -r buster
  lxc-create: testcon: parse.c: lxc_file_for_each_line_mmap: 142 Failed 
to parse config file "/etc/lxc/default.conf" at line "lxc.net.type = 
empty"
  lxc-create: testcon: parse.c: lxc_file_for_each_line_mmap: 142 Failed 
to parse config file "/var/lib/lxc/testcon/config" at line "lxc.net.type 
= empty"
  lxc-create: testcon: tools/lxc_create.c: main: 327 Failed to create 
container testcon


If I replace "lxc.net.type = empty" by "lxc.net.0.type = empty" in
/etc/lxc/default.conf, everything works out fine.


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  libc6  2.28-6
ii  libcap21:2.25-2
ii  libgnutls303.6.6-2
ii  liblxc11:3.1.0+really3.0.3-4
ii  libseccomp22.3.3-3
ii  libselinux12.8-1+b1
ii  lsb-base   10.2018112800

Versions of packages lxc recommends:
ii  bridge-utils 1.6-2
ii  debootstrap  1.0.114
ii  dirmngr  2.2.12-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  gnupg2.2.12-1
ii  iproute2 4.20.0-2
ii  iptables 1.8.2-3
ii  libpam-cgfs  1:3.1.0+really3.0.3-4
ii  lxc-templates3.0.3-1
ii  lxcfs3.0.3-2
ii  nftables 0.9.0-2
ii  openssl  1.1.1a-1
ii  rsync3.1.3-5
ii  uidmap   1:4.5-1.1

Versions of packages lxc suggests:
ii  apparmor 2.13.2-7
ii  btrfs-progs  4.20.1-1
ii  lvm2 2.03.02-2
pn  python3-lxc  

-- debconf information:
  lxc/auto_update_config:

Bug#782644: Re : Bug#782644: Re : Bug#782644: xscreensaver always rejects my password

[nicolas . patrois]

Le 26/02/2019 23:44:46, Tormod Volden a écrit :

> Is there any information in e.g. /var/log/auth.log ?

> Regards,
> Tormod

I have this for example:
Feb  2 17:57:22 nicolas unix_chkpwd[10736]: check pass; user unknown
Feb  2 17:57:31 nicolas unix_chkpwd[10743]: check pass; user unknown
Feb  2 17:57:31 nicolas unix_chkpwd[10743]: password check failed for user 
(nicolas)
Feb  2 17:57:31 nicolas xscreensaver: pam_unix(xscreensaver:auth): 
authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost=  
user=nicolas
Feb  2 17:57:31 nicolas xscreensaver: pam_winbind(xscreensaver:auth): getting 
password (0x0388)
Feb  2 17:57:31 nicolas xscreensaver: pam_winbind(xscreensaver:auth): 
pam_get_item returned a password
Feb  2 17:57:31 nicolas xscreensaver: pam_winbind(xscreensaver:auth): internal 
module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'nicolas')
Feb  2 17:57:32 nicolas xscreensaver[3516]: FAILED LOGIN 1 ON DISPLAY ":0.0", 
FOR "nicolas"
Feb  2 17:57:34 nicolas unix_chkpwd[10744]: check pass; user unknown
Feb  2 17:57:47 nicolas xscreensaver[3516]: pam_unix(xscreensaver:auth): 
conversation failed
Feb  2 17:57:47 nicolas xscreensaver[3516]: pam_unix(xscreensaver:auth): auth 
could not identify password for [nicolas]
Feb  2 17:57:47 nicolas xscreensaver[3516]: pam_winbind(xscreensaver:auth): 
getting password (0x0388)
Feb  2 17:57:47 nicolas xscreensaver[3516]: pam_winbind(xscreensaver:auth): 
Could not retrieve user's password
Feb  2 17:57:48 nicolas unix_chkpwd[10756]: check pass; user unknown

Regards,
nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#923223: XML::Parser::parsefile() uses 2-argument open

[Gianfranco Costamagna]

reopen 923223
affects 923223 src:xmltv
severity 923223 serious
thanks

Hello, the latest update of libxml-parser-perl seems to have broken xmltv 
testsuite, and now it is failing to build from source.

I suspect the testsuite of xmltv might just need updates, but I don't know if 
the package is really broken, and how much in the archive is now not building 
anymore due to this change.

Can you please clarify if this is something we should deal with in xmltv or not?
https://ci.debian.net/packages/x/xmltv/unstable/amd64/
I see there are some "open" calls in the testsuite, this is why I'm blaming 
this fix...

snip of the failing testsuite

/usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
--with-plot < t/data-tv_imdb/Movie1-case-insensitive.xml > 
'/tmp/Tl8eCfv0EW/Movie1-case-insensitive.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 2
/usr/bin/tv_imdb --movies-only --quiet --imdbdir '/tmp/Tl8eCfv0EW' 
--with-keywords --with-plot < t/data-tv_imdb/Movie1-movies-only.xml > 
'/tmp/Tl8eCfv0EW/Movie1-movies-only.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 3
/usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
--with-plot < t/data-tv_imdb/Movie1.xml > 
'/tmp/Tl8eCfv0EW/Movie1.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 4
/usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
--with-plot < t/data-tv_imdb/Movie100-years.xml > 
'/tmp/Tl8eCfv0EW/Movie100-years.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 5
/usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
--with-plot < t/data-tv_imdb/Movie101-movie-and-tv.xml > 
'/tmp/Tl8eCfv0EW/Movie101-movie-and-tv.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 6
/usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
--with-plot < t/data-tv_imdb/Movie21-accents.xml > 
'/tmp/Tl8eCfv0EW/Movie21-accents.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 7
/usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
--with-plot < t/data-tv_imdb/Movie22-dots.xml > 
'/tmp/Tl8eCfv0EW/Movie22-dots.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 8
/usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
--with-plot < t/data-tv_imdb/Movie3-and-amp.xml > 
'/tmp/Tl8eCfv0EW/Movie3-and-amp.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 9
/usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
--with-plot < t/data-tv_imdb/Movie5-ignore-punc.xml > 
'/tmp/Tl8eCfv0EW/Movie5-ignore-punc.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 10
/usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
--with-plot < t/data-tv_imdb/Movie5-with-punc.xml > 
'/tmp/Tl8eCfv0EW/Movie5-with-punc.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 11
/usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
--with-plot < t/data-tv_imdb/Movie6-articles.xml > 
'/tmp/Tl8eCfv0EW/Movie6-articles.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 12
/usr/bin/tv_imdb --movies-only --quiet --imdbdir '/tmp/Tl8eCfv0EW' 
--with-keywords --with-plot < t/data-tv_imdb/Show1-movies-only.xml > 
'/tmp/Tl8eCfv0EW/Show1-movies-only.xml-output.xml' 2>&1 failed: 2, 0, 0
not ok 13
/usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
--with-plot < t/data-tv_imdb/Show1.xml > '/tmp/Tl8eCfv0EW/Show1.xml-output.xml' 
2>&1 failed: 2, 0, 0
not ok 14
Failed 13/14 subtests 
t/test_tv_split.t  

thanks for having a look

Gianfranco

Bug#919385: postgresql-common: alter system set port ignored by pg-commands

[Christoph Berg]

I was looking into several ideas that all have some problems.

0. Look into pg_settings

Doesn't work because we can only query the database if we already know
the port

1. Put the port on the postgres command line (postgres -p )

Works, but then restarting the server is hard once the port got
changed. `pg_ctl restart` will even preserve the last command line.

2. Put the port into a file next to /var/run/postgresql/11-main.pid

Has several consistency issues. If the port is changed, the file is
not updated immediately. If the cluster is shut down, should the file
be removed?

3. Write a suid wrapper that read postgresql.auto.conf

suid programs are a security nightmare.

4. Patch PostgreSQL such that it puts the port into external_pid_file,
i.e. into /var/run/postgresql/11-main.pid

Patching the server is evil, and it breaks applications reading the
external file that are not prepared to ignore extra information


The bottom line is that #4 looks most attractive, but I'm not fixing
this in postgresql-common now. I will try sending a patch for #4 to
upstream and see if it gets accepted for PG 12+. If so, we can still
patch the older versions on our side.

Christoph

Bug#918206: Pandas

[Yaroslav Halchenko]

On Wed, 27 Feb 2019, Andreas Tille wrote:

> Dear Rebecca,

> On Wed, Feb 27, 2019 at 07:25:26AM +, Rebecca N. Palmer wrote:
> > On 27/02/2019 07:00, Andreas Tille wrote:
> > > Dear Rebecca,
> > > I do not think that there is any
> > > need for a separate branch.  Just stick to the debian branch.

> > It's needed because the debian branch contains the attempt at packaging 0.24
> > described earlier in this thread, which it's now too late for.

> You are right.  Considering the branching jungle (Yaroslav, could you possibly

for someone jungle is a sweet sweet home! ;)

$> git br -a | grep salsa | grep -e bf- -e enh- -e cythoned | while 
read b; do git push salsa :${b//*salsa\//}; done
To salsa.debian.org:science-team/pandas.git
 - [deleted] __tent/debian-cythoned-quilt
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-cython
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-i386
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-native-endianness
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-skips
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-unser
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-versions-etc
To salsa.debian.org:science-team/pandas.git
 - [deleted] enh-tests-compat-pytables-2.1

and will try to not forget to not push them again ;)

$> git br -a | grep salsa # -- with my annotations
  remotes/salsa/master -- some upstream's point of master -- could 
also be removed if you like
  remotes/salsa/releases   -- linear progression of upstream releases
  remotes/salsa/debian -- sits on top of releases and carries 
packaging
  remotes/salsa/debian-experimental -- the one for uploads to 
experimental

better now?

> cleanup branches that are not used any more?) I'd prefer if you would move the
> 0.24 packaging to some separate branch (debian-experimental is covered but may
> be debian-0.24 or something like this?) and keep branch debian for what we are
> really releasing.

well "releasing" is a loaded term. I guess you are talking about uploading to
unstable so it manages to get into buster.  Since "debian" branch already got
its 0.24, what about starting debian-buster branch off debian/0.23.3-1 ?

otherwise -- I am ok to hard-reset and force push debian to the debian/0.23.3-1
state -- everyone should just beware of it, and then progress
debian-experimental to current state of debian (v0.24.1-972-g1cfbd07c7)

your call

> Thanks again for your work on this

yeap, Thank you Rebecca!

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#923396: file -e should silently ignore nonexistent testnames

[Vincent Lefevre]

Package: file
Version: 1:5.35-2
Severity: wishlist

I get the following error:

$ file -e foo /dev/null
Usage: file [-bcCdEhikLlNnprsvzZ0] [--apple] [--extension] [--mime-encoding]
[--mime-type] [-e ] [-F ]  [-f ]
[-m ] [-P ]  ...
   file -C [-m ]
   file [--help]

because testname foo does not exist. This should silently be ignored,
so that if the testname is added in a later version, one can
unconditionally use "file -e foo" on all machines.

As an example, "file -e json" works in Debian/unstable, but not
in stretch.

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

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

Versions of packages file depends on:
ii  libc6  2.28-7
ii  libmagic1  1:5.35-2
ii  zlib1g 1:1.2.11.dfsg-1

file recommends no packages.

file suggests no packages.

-- no debconf information

Bug#922996: Bug#923176: stretch-pu: package ca-certificates-java/20170929~deb9u1

[Andreas Beckmann]

Hi Tony,

On 2019-02-25 00:53, tony mancill wrote:
> Andreas, since you handled the prior update, feel free to take care of
> this one as well.  The only difference between our debdiffs is that mine
> addresses the "echo -e" bashism, but that would only be triggered for
> Ubuntu updates for versions older than trusty (14.04 LTS), and so I
> imagine that it is actually needed.

I'm fine if you go ahead with your variant. I'm a bit short of time
currently.

Andreas

Bug#904018: gcc-8: FTBFS on x32: hangs in the testsuite

[Thorsten Glaser]

found 904018 8.3.0-2
thanks

https://buildd.debian.org/status/fetch.php?pkg=gcc-8&arch=x32&ver=8.3.0-2&stamp=1551277939&raw=0

I’ve again uploaded a “nocheck” build, to let the game continue,
but this ought to be eventually fixed.

Thanks,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Bug#922974: unblock: nvidia-graphics-drivers/410.93-2

[Andreas Beckmann]

On Fri, 22 Feb 2019 15:12:17 +0100 Andreas Beckmann  wrote:
> nvidia-graphics-drivers seems to need a force-hint since it drops the
> driver parts for i386 and armhf (and the libraries for armhf as well).
> This makes the arch:all meta-package hashcat-nvidia uninstallable on
> i386 (since nvidia-smi is gone).

Hi,

I'd like to see this sorted out before I upload a new upstream release
to unstable. Or are there more blockers for the migration that I'm
currently not aware of? (Cruft packages should not be an issue.)

There is also #922976 which suggests hashcat to restrict to amd64 and/or
add alternative dependencies to the respective packages from the 390xx
legacy driver.

Thanks,

Andreas

Bug#923397: lirc-setup don't start

[paul romanchenko]

Package: lirc
Version: 0.10.1-5
Severity: important

lirc-setup don't start with following messages:
$ lirc-setup 
/usr/lib/x86_64-linux-gnu/python3.7/site-packages/lirc-setup/mvc_control.py:13: 
PyGIWarning: Gtk was imported without specifying a version first. Use 
gi.require_version('Gtk', '3.0') before import to ensure that the right version 
gets loaded.
  from gi.repository import Gtk # pylint: disable=no-name-in-module
Traceback (most recent call last):
  File "/usr/bin/lirc-setup", line 16, in 
import mvc_control
  File 
"/usr/lib/x86_64-linux-gnu/python3.7/site-packages/lirc-setup/mvc_control.py", 
line 16, in 
import choosers
  File 
"/usr/lib/x86_64-linux-gnu/python3.7/site-packages/lirc-setup/choosers.py", 
line 11, in 
import mvc_model
  File 
"/usr/lib/x86_64-linux-gnu/python3.7/site-packages/lirc-setup/mvc_model.py", 
line 14, in 
from lirc.database import Database
  File "/usr/lib/python3/dist-packages/lirc/__init__.py", line 7, in 
from .client import get_default_lircrc_path
  File "/usr/lib/python3/dist-packages/lirc/client.py", line 38, in 
import _client
ModuleNotFoundError: No module named '_client'


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

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

Versions of packages lirc depends on:
ii  libasound2   1.1.7-2
ii  libc62.28-6
ii  libftdi1-2   1.4-1+b2
ii  libgcc1  1:8.2.0-16
ii  liblirc-client0  0.10.1-5
ii  liblirc0 0.10.1-5
ii  libportaudio219.6.0-1
ii  libpython3.7 3.7.2-2
ii  libstdc++6   8.2.0-16
ii  libsystemd0  238-4
ii  libudev1 240-5
ii  libusb-0.1-4 2:0.1.12-32
ii  libusb-1.0-0 2:1.0.22-2
ii  lsb-base 10.2018112800
ii  python3  3.7.2-1

Versions of packages lirc recommends:
pn  gir1.2-vte
ii  python3-gi3.30.4-1
ii  python3-yaml  3.12-1+b2
ii  systemd   238-4

Versions of packages lirc suggests:
ii  ir-keytable  1.16.3-1
pn  lirc-compat-remotes  
pn  lirc-doc 
pn  lirc-drv-irman   
ii  lirc-x   0.10.1-5
pn  setserial

-- Configuration Files:
/etc/lirc/hardware.conf changed:
LIRCD_ARGS=""
LOAD_MODULES=true
DEVICE="/dev/lirc0"
MODULES=""
LIRCD_CONF=""
LIRCMD_CONF=""

/etc/lirc/lirc_options.conf changed:
[lircd]
nodaemon= False
driver  = devinput
device  = auto
output  = /var/run/lirc/lircd
pidfile = /var/run/lirc/lircd.pid
plugindir   = /usr/lib/x86_64-linux-gnu/lirc/plugins
permission  = 666
allow-simulate  = No
repeat-max  = 600
[lircmd]
uinput  = False
nodaemon= False

/etc/lirc/lircd.conf changed:
include "lircd.conf.d/*.conf"

/etc/lirc/lircd.conf.d/devinput.lircd.conf changed:
begin remote
  name  devinput
  driver devinput
  bits   16
  eps30
  aeps  100
  one 0 0
  zero0 0
  pre_data_bits   16
  pre_data   0x1
  post_data_bits  32
  post_data  0x1
  gap  132799
  toggle_bit_mask 0x0
  begin codes
  KEY_00x000B
  KEY_102ND0x0056
  KEY_10x0002
  KEY_20x0003
  KEY_30x0004
  KEY_40x0005
  KEY_50x0006
  KEY_60x0007
  KEY_70x0008
  KEY_80x0009
  KEY_90x000A
  KEY_A0x001E
  KEY_AB   0x0196
  KEY_AGAIN0x0081
  KEY_ALTERASE 0x00DE
  KEY_ANGLE0x0173
  KEY_APOSTROPHE   0x0028
  KEY_ARCHIVE  0x0169
  KEY_AUDIO0x0188
  KEY_AUX  0x0186
  KEY_B0x0030
  KEY_BACK 0x009E
  KEY_BACKSLASH0x002B
  KEY_BACKSPACE0x000E
  KEY_BASSBOOST0x00D1
  KEY_BATTERY  0x00EC
  KEY_BLUE 0x0191
  KEY_BOOKMARKS0x009C
  KEY_BREAK0x019B
  KEY_BRIGHTNESSDOWN   0x00E0
  KEY_BRIGHTNESSUP 0x00E1
  KEY_BRL_DOT1 0x01F1
  KEY_BRL_DOT2 0x01F2
  KEY_BRL_DOT3 0x01F3
  KEY_BRL_DOT4 0x01F4
  KEY_BRL_DOT5 0x01F5
  KEY_BRL_DOT6 0x01F6
  KEY_BRL_DOT7 0x01F7
  KEY_BR

Bug#922869: libtool: file date issue

[Alastair McKinstry]

Hi,


Where did you see this error ? I cannot repeat it. Builds work fine 
locally / pdebuild, and it appears the buildds ?


regards

Alastair


--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Bug#923381: Warning: #923381 filled against x2broker (source: ) but x2gobroker is in the database

[Baptiste Jammet]

Control: reassign -1 x2gobroker
Thanks

Hello, 

Dixit Laura Arjona Reina, le 27/02/2019 :
>The l10n scripts have produced the warning below.
>Maybe you want to forward the bug/translation to a different package.

Thanks Laura for the notice. I'm reassigning the bug to the correct
package.
Maintainers, this was the french debconf translation, still available
in the BTS (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923381)

Baptiste


pgpXE9O1CPYGc.pgp
Description: Signature digitale OpenPGP

Bug#923398: In debian stretch: bind(2) port collision checking is wrong for IPv4 if IPv6 is checked first

[Katerina Koukiou]

Package: linux-headers-4.9.0-8-amd64

I hit into the following bug when creating two VMs with virt-manager
configured with spice server. I started them sequentially, first
starts but the second fails to spawn with error:

Error starting domain: internal error: qemu unexpectedly closed the monitor:
(process:7985): Spice-WARNING **: reds.c:2577:reds_init_socket:
listen: Address already in use
2017-03-15T23:57:46.288270Z qemu-system-x86_64: failed to initialize
spice server

While searching for open bugs about it I found out that it was a
kernel bug, which was fixed in kernel-4-13, later than what debian
stretch has.

The main upstream kernel fix seems to be:

commit cbb2fb5c72f48d3029c144be0f0e61da1c7bccf7
Author: Josef Bacik 
Date:   Fri Sep 22 20:20:06 2017 -0400

net: set tb->fast_sk_family

This is not included in 4.9 kernel of debian stretch ,
# uname -ra
Linux unassigned-hostname 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1
(2019-02-19) x86_64 GNU/Linux

Maybe it is worth to backport it.

Thanks,
Katerina

Bug#923399: texlive-base: uninstallable due to versioned conflicts

[Vincent Lefevre]

Package: texlive-base
Version: 2018.20190227-1
Severity: serious

texlive-base 2018.20190227-1 has versioned conflicts:

Conflicts: luasseq (<< 2018.20190227), prosper (<< 2018.20190227), tex4ht (<< 
20160814), texlive (<< 2018.20190227), texlive-base (<< 2018.20190227), 
texlive-bibtex-extra (<< 2018.20190227), texlive-binaries (<< 2018.20180416), 
texlive-extra-utils (<< 2018.20190227), texlive-font-utils (<< 2018.20190227), 
texlive-fonts-extra (<< 2018.20190227), texlive-fonts-extra-doc (<< 
2018.20190227), texlive-fonts-extra-links (<< 2018.20190227), 
texlive-fonts-recommended (<< 2018.20190227), texlive-fonts-recommended-doc (<< 
2018.20190227), texlive-formats-extra (<< 2018.20190227), texlive-full (<< 
2018.20190227), texlive-games (<< 2018.20190227), texlive-generic-extra (<< 
2018.20190227), texlive-generic-recommended (<< 2018.20190227), texlive-htmlxml 
(<< 2018.20190227), texlive-humanities (<< 2018.20190227), 
texlive-humanities-doc (<< 2018.20190227), texlive-lang-african (<< 
2018.20190227), texlive-lang-all (<< 2018.20190227), texlive-lang-arabic (<< 
2018.20190227), texlive-lang-chinese (<< 2018.20190227), texlive-lang-cjk (<< 
2018.20190227), texlive-lang-cyrillic (<< 2018.20190227), 
texlive-lang-czechslovak (<< 2018.20190227), texlive-lang-english (<< 
2018.20190227), texlive-lang-european (<< 2018.20190227), texlive-lang-french 
(<< 2018.20190227), texlive-lang-german (<< 2018.20190227), texlive-lang-greek 
(<< 2018.20190227), texlive-lang-indic (<< 2018.20190227), texlive-lang-italian 
(<< 2018.20190227), texlive-lang-japanese (<< 2018.20190227), 
texlive-lang-korean (<< 2018.20190227), texlive-lang-other (<< 2018.20190227), 
texlive-lang-polish (<< 2018.20190227), texlive-lang-portuguese (<< 
2018.20190227), texlive-lang-spanish (<< 2018.20190227), texlive-latex-base (<< 
2018.20190227), texlive-latex-base-doc (<< 2018.20190227), texlive-latex-extra 
(<< 2018.20190227), texlive-latex-extra-doc (<< 2018.20190227), 
texlive-latex-recommended (<< 2018.20190227), texlive-latex-recommended-doc (<< 
2018.20190227), texlive-luatex (<< 2018.20190227), texlive-metapost (<< 
2018.20190227), texlive-metapost-doc (<< 2018.20190227), texlive-music (<< 
2018.20190227), texlive-omega (<< 2018.20190227), texlive-pictures (<< 
2018.20190227), texlive-pictures-doc (<< 2018.20190227), texlive-plain-extra 
(<< 2018.20190227), texlive-plain-generic (<< 2018.20190227), texlive-pstricks 
(<< 2018.20190227), texlive-pstricks-doc (<< 2018.20190227), texlive-publishers 
(<< 2018.20190227), texlive-publishers-doc (<< 2018.20190227), texlive-science 
(<< 2018.20190227), texlive-science-doc (<< 2018.20190227), texlive-xetex (<< 
2018.20190227)

making it uninstallable, e.g. with texlive-extra-utils,
whose latest version is 2018.20190207-1 according to

  https://tracker.debian.org/pkg/texlive-extra

These conflicts should be relaxed, or new versions of the packages
should be produced.

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2880 2019-02-26 12:25:23 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2018-09-02 14:32:33 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2019-02-25 02:59:25 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrw

Bug#923346: networking

[Tino Mettler]

On Tue, Feb 26, 2019 at 18:35:58 -0500, Paul Thomas wrote:
> OK, I think something more with the networking is going on. It still
> works, but something is off. I'll investigate more tomorrow.

Hi,

this issue sounds rather strange. Regarding IP, ptp4l only uses UDP
multicast and unicast, so TCP traffic for SSH should never be
disturbed.

One wild guess from my side is that ptp4l triggers some bug in your
setup.  Maybe the network driver for your hardware or the hardware
itself behaves strange once timestamping is enabled by ptp4l.

Regards,
Tino

Bug#923346: networking

[Paul Thomas]

Yeah, I think a bug in the driver is possible, Xilinx reports proper
ptp operation:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver#MacbDriver-PTP

I'm using a RT patched 4.18 kernel, so now I'm in the process of
testing some other kernels.

One other piece of information, I did pull the latest git version of
linuxptp, with the same results:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver#MacbDriver-PTP

thanks,
Paul

On Wed, Feb 27, 2019 at 10:25 AM Tino Mettler  wrote:
>
> On Tue, Feb 26, 2019 at 18:35:58 -0500, Paul Thomas wrote:
> > OK, I think something more with the networking is going on. It still
> > works, but something is off. I'll investigate more tomorrow.
>
> Hi,
>
> this issue sounds rather strange. Regarding IP, ptp4l only uses UDP
> multicast and unicast, so TCP traffic for SSH should never be
> disturbed.
>
> One wild guess from my side is that ptp4l triggers some bug in your
> setup.  Maybe the network driver for your hardware or the hardware
> itself behaves strange once timestamping is enabled by ptp4l.
>
> Regards,
> Tino

Bug#922869: libtool: file date issue

[Vincent Lefevre]

On 2019-02-27 15:12:24 +, Alastair McKinstry wrote:
> Where did you see this error ? I cannot repeat it. Builds work fine locally
> / pdebuild, and it appears the buildds ?

When attempting to rebuild libtool on a machine. A second build
(after a reboot due to an issue with the nouveau driver that
made the machine very slow) was fine, though. Still, it appears
that the test is wrong and can yield failures like there.

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

Bug#923081: privacy invasion due to automatic fallback to Cloudflare

[Michael Biebl]

On Mon, 25 Feb 2019 14:29:42 + Toni Mueller  wrote:
> 
> 
> reopen 923081
> thanks
> 
> 
> Hi Andreas,
> 
> On Mon, Feb 25, 2019 at 09:25:48AM +0100, Andreas Henriksson wrote:
> > (Not sure why you think Cloudflare is a problem but Google is not, but
> > oh well.)
> 
> well, I think you are misreading my bug report.
> 
> I definitely think that *both* are a problem, but until I took a closer
> look, I was just unaware of this entire thing. And, btw, I would prefer
> to use something that has sane defaults and can be used without
> attending a special "systemd university" first - I just have different
> priorities than that.
> 
> > If *you* enable systemd-resolved (which is shipped completely disabled)
> > then *you* are expected to know how to configure it.
> 
> I don't know how you can conclude that *I* enabled it. In fact, it is
> enabled by default as far as I can see, because there is only one way to
> disable it, which is setting "DNSStubListener" to "no", while the
> default is "yes", as also indicated by this snippet from the config file
> as shipped in this file: systemd_240-6_amd64.deb:
> 
> #DNSStubListener=yes
> 
> Please see also the appropriate section about this option on this web
> page:
> 
> https://www.freedesktop.org/software/systemd/man/resolved.conf.html
> 
> 
> Please don't claim that this service is disabled as shipped in Debian
> when it is not.

Andreas is correct.
systemd-resolved is *not* enabled by default in Debian.

$ systemctl is-enabled systemd-resolved
disabled

If that reports a different state for you, then you have enabled the
service manually.


-- 
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#923399: texlive-base: uninstallable due to versioned conflicts

[Norbert Preining]

tag 923399 + pending
thanks

On Wed, 27 Feb 2019, Vincent Lefevre wrote:
> texlive-base 2018.20190227-1 has versioned conflicts:

Already in the upload queue ... first upload was messed up by DAK
(again), I just cleaned up and re-upload later today.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#920296: Installs /etc/systemd/system/dbus-org.freedesktop.timesync1.service identical to /lib/systemd/system/systemd-timesyncd.service

[Michael Biebl]

On Wed, 23 Jan 2019 14:54:48 -0800 Josh Triplett 
wrote:
> On Wed, Jan 23, 2019 at 07:52:24PM -0300, Felipe Sateler wrote:
> > On Wed, Jan 23, 2019 at 4:15 PM Josh Triplett  wrote:
> > > Package: systemd
> > > Severity: normal
> > >
> > > I installed using the Buster Alpha 4 installer, and for some reason I
> > > ended up with a file
> > > /etc/systemd/system/dbus-org.freedesktop.timesync1.service, identical to
> > > /lib/systemd/system/systemd-timesyncd.service. dpkg -S shows it not
> > > owned by any package, and searching through maintainer scripts pointed
> > > to systemd's postinst. systemd shouldn't install a service in /etc
> > > identical to the one already installed in /lib.
> > >
> > 
> > All systemd does is enable the service. On my system that leaves a symlink,
> > not a regular file.
> > Is  /etc/systemd/system/dbus-org.freedesktop.timesync1.service a regular
> > file or a symlink?
> 
> It was a regular file.

I don't think it's systemctl/systemd which is responsible for creating
/etc/systemd/system/dbus-org.freedesktop.timesync1.service as regular file.
Maybe a file system issue or the result of the file being copied around.

Josh, can you reproduce the issue?

What happens if you remove
/etc/systemd/system/dbus-org.freedesktop.timesync1.service and run
systemctl enable systemd-timesyncd.service (as we do in postinst)

-- 
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#922096: sddm-theme-debian-maui: background image doesn't load, shows white screen

[Steven De Herdt]

Control: block -1 by 921678

Hi Dan

I noticed this bug too, but the error is actually in desktop-base.  Two
other reports of this bug were already moved from sddm-theme-debian-maui
to desktop-base.  That makes it non-obvious from the side of sddm that
the bug is known, so I will not move your report to the other package.

@Aurélien: Excuse my nagging, but can this be fixed in time for the
buster release?  If I understand the freeze process correctly there's
only little time left, right?

Thank you
-Steven

Bug#915584: fix required on the dico side

[Matthias Klose]

This has to be fixed on the dico side.  One possible solution is to guard the
import and fall back to some defaults, either provided inline, or using a
defaults config file shipped in /usr/lib/...  This way the package can be
installed with the dangling symlink.

Bug#53434: Hello

[contacts info]

Dear Entrepreneur,

This brief introductory letter may come to you as a big surprise,
but I believe it is only a day that people meet and become great
friends and business partners.

On behalf of my son, I am searching for business with good
return to invest a reasonable amount.

If you have profitable project hesitate not to draw my attention
for more discussions.

Thanking you in advance

Yours Sincerely,
Mr.Gray Wayne
+15622030899

Bug#922874: file: mistakes Xorg.0.log file as JSON data

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://bugs.astron.com/view.php?id=69

On 2019-02-21 17:02:15 +0100, Vincent Lefevre wrote:
> file mistakes Xorg.0.log file as JSON data (which breaks viewing
> with "less" + LESSOPEN).
[...]

I've reported the bug upstream.

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

Bug#923223: XML::Parser::parsefile() uses 2-argument open

[gregor herrmann]

On Wed, 27 Feb 2019 15:35:23 +0100, Gianfranco Costamagna wrote:

> Hello, the latest update of libxml-parser-perl seems to have broken
> xmltv testsuite, and now it is failing to build from source.

Ack.
 
> I suspect the testsuite of xmltv might just need updates, but I
> don't know if the package is really broken, and how much in the
> archive is now not building anymore due to this change.

Right, that's a good question :)
 
> Can you please clarify if this is something we should deal with in xmltv or 
> not?

Not sure yet … Xavier is looking into libxml-parser-perl, I took a
look at xmltv:

> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Movie1-case-insensitive.xml > 
> '/tmp/Tl8eCfv0EW/Movie1-case-insensitive.xml-output.xml' 2>&1 failed: 2, 0, 0

1) A fix for the xmltv testsuite is trivial:

#v+
--- a/t/test_tv_imdb.t
+++ b/t/test_tv_imdb.t
@@ -86,9 +86,9 @@
 my $output="$tmpDir/".File::Basename::basename($input)."-output.xml";
 
 # Make temporary directory and split into it.
-my $cmd="$cmds_dir/tv_imdb --quiet --imdbdir '$tmpDir' --with-keywords 
--with-plot < $input > '$output' 2>&1";
+my $cmd="$cmds_dir/tv_imdb --quiet --imdbdir '$tmpDir' --with-keywords 
--with-plot $input > '$output' 2>&1";
 if ( $input=~m/movies-only/ ) {
-   $cmd="$cmds_dir/tv_imdb --movies-only --quiet --imdbdir '$tmpDir' 
--with-keywords --with-plot < $input > '$output' 2>&1";
+   $cmd="$cmds_dir/tv_imdb --movies-only --quiet --imdbdir '$tmpDir' 
--with-keywords --with-plot $input > '$output' 2>&1";
 }
 #print STDERR "\nRUN:$cmd\n";
 my $r = system($cmd);
#v-

2) This fix would also suite the documentation of tv_imdb which says:

tv_imdb --imdbdir  [--help] [--quiet]
   [--with-keywords] [--with-plot]
   [--movies-only] [--actors NUMBER]
   [--stats] [--debug]
   [--output FILE] [FILE...]

(so: pass FILE as an argument, not: read from STDIN, as the testsuite
does)

3) What the code in tv_imdb does is:

@ARGV = ('-') if not @ARGV;

XMLTV::parsefiles_callback(\&encoding_cb, \&credits_cb,
   \&channel_cb, \&programme_cb,
   @ARGV);
(which ends with '$t->parsefile($f);' in XMLTV)


So it seems that XML::Parser's parsefile was able to handle '-' with
the 2-args-open() and fails to do so with the 3-args-open(). This is
a regression at first glance; although the documentation for open()
only mentions "<-" or "-" for STDIN in the (one-args- and)
two-args-form. But yeah, this has the potential to break more code
out there …



Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Tom Waits: Top Of The Hill


signature.asc
Description: Digital Signature

Bug#908216: btrfs blocked for more than 120 seconds

[Russell Mosemann]

I ran a "btrfs check" on one of the partitions that had issues last night to 
confirm that the file system was not damaged. No errors were found.
 
# btrfs check -p /dev/sdc1
Checking filesystem on /dev/sdc1
UUID: d6640b4b-bd59-47d5-bfd7-37b4c40fb3c6
checking extents [.]
checking free space cache [o]
checking fs roots [O]
checking only csum items (without verifying data)
checking root refs
found 1453455912960 bytes used, no error found
total csum bytes: 1411701148
total tree bytes: 7534133248
total fs tree bytes: 3358851072
total extent tree bytes: 2426896384
btree space waste bytes: 695281951
file data blocks allocated: 3067911655424
 referenced 6563527507968
 

--
Russell Mosemann

Bug#922996: Bug#923176: stretch-pu: package ca-certificates-java/20170929~deb9u1

[tony mancill]

On Wed, Feb 27, 2019 at 04:01:08PM +0100, Andreas Beckmann wrote:
> Hi Tony,
> 
> On 2019-02-25 00:53, tony mancill wrote:
> > Andreas, since you handled the prior update, feel free to take care of
> > this one as well.  The only difference between our debdiffs is that mine
> > addresses the "echo -e" bashism, but that would only be triggered for
> > Ubuntu updates for versions older than trusty (14.04 LTS), and so I
> > imagine that it is actually needed.
> 
> I'm fine if you go ahead with your variant. I'm a bit short of time
> currently.

Hi Andreas,

I know the feeling... :)  I have performed the dput.  I don't upload to
s-p-u often, so I'll keep an eye and handle clean up if I've made a
mistake in the process.  (It seems that the Release Managers have done a
lot of good work over the years to make the process simpler than it
was.)

Cheers,
tony


signature.asc
Description: PGP signature

Bug#920692: [PATCH] Packages must not install files or directories into /var/cache

[Josh Triplett]

On Wed, Feb 27, 2019 at 08:13:52AM +0100, Ansgar wrote:
> Josh Triplett writes:
> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> > index 48410be..1cdcb18 100644
> > --- a/policy/ch-files.rst
> > +++ b/policy/ch-files.rst
> > @@ -722,6 +722,15 @@ The name of the files and directories installed by 
> > binary packages
> >  outside the system PATH must be encoded in UTF-8 and should be
> >  restricted to ASCII when it is possible to do so.
> >
> > +.. _s-cache:
> > +
> > +Cache
> > +-
> > +
> > +Packages must not install files or directories into ``/var/cache``. The
> > +system administrator may delete any or all files from this directory at
> > +any time, or may choose to put it on an ephemeral filesystem.
> > +
>
> If you allow directories to be removed at any time, it breaks non-root
> programs using /var/cache: they cannot recreate them.  The FHS only
> allows removing files.
>
> Creating the directories in maintainer scripts instead of shipping them
> in the package makes no difference: if you care about ephemeral
> filesystems for /var/cache, you have to require something like tmpfiles
> or CacheDirectory= in .service files to be used (depending on the
> requirements of the package).
>
> So I think we should require such solutions to be used over just
> forbidding to ship the directory as part of the package.

I don't think we should require any *specific* solution to be used, but
if you'd like, I could certainly say something like "if the package
expects to have a specific directory writable by non-root, it will need
to arrange to create that directory as root before running; the package
should not fail to run if that directory does not exist".

Bug#920296: Installs /etc/systemd/system/dbus-org.freedesktop.timesync1.service identical to /lib/systemd/system/systemd-timesyncd.service

[Felipe Sateler]

On Wed, Feb 27, 2019 at 12:48 PM Michael Biebl  wrote:

> On Wed, 23 Jan 2019 14:54:48 -0800 Josh Triplett 
> wrote:
> > On Wed, Jan 23, 2019 at 07:52:24PM -0300, Felipe Sateler wrote:
> > > On Wed, Jan 23, 2019 at 4:15 PM Josh Triplett 
> wrote:
> > > > Package: systemd
> > > > Severity: normal
> > > >
> > > > I installed using the Buster Alpha 4 installer, and for some reason I
> > > > ended up with a file
> > > > /etc/systemd/system/dbus-org.freedesktop.timesync1.service,
> identical to
> > > > /lib/systemd/system/systemd-timesyncd.service. dpkg -S shows it not
> > > > owned by any package, and searching through maintainer scripts
> pointed
> > > > to systemd's postinst. systemd shouldn't install a service in /etc
> > > > identical to the one already installed in /lib.
> > > >
> > >
> > > All systemd does is enable the service. On my system that leaves a
> symlink,
> > > not a regular file.
> > > Is  /etc/systemd/system/dbus-org.freedesktop.timesync1.service a
> regular
> > > file or a symlink?
> >
> > It was a regular file.
>
> I don't think it's systemctl/systemd which is responsible for creating
> /etc/systemd/system/dbus-org.freedesktop.timesync1.service as regular file.
> Maybe a file system issue or the result of the file being copied around.


> Josh, can you reproduce the issue?
>
> What happens if you remove
> /etc/systemd/system/dbus-org.freedesktop.timesync1.service and run
> systemctl enable systemd-timesyncd.service (as we do in postinst)
>

This is definitely not systemctl's doing:

% sudo systemctl disable systemd-timesyncd.service
Removed /etc/systemd/system/dbus-org.freedesktop.timesync1.service.
Removed /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service.
% sudo systemctl enable systemd-timesyncd.service
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service
→ /lib/systemd/system/systemd-timesyncd.service.
Created symlink
/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service →
/lib/systemd/system/systemd-timesyncd.service.

Unfortunately I don't think we have enough information to act on this issue.

-- 

Saludos,
Felipe Sateler

Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev

[Ben Hutchings]

On Wed, 2019-02-27 at 03:01 +, Dmitry Bogatov wrote:
> [2019-02-25 05:45] shirish शिरीष 
> > On 24/02/2019, Dmitry Bogatov  wrote:
> > 
> > 
> > 
> > > Interesting, you seems somehow got mountkernfs.sh script removed from
> > > runlevel S.
> > > 
> > > Can you please invoke as root
> > > 
> > >   # update-rc.d mountkernfs.sh enable S
> > > 
> > > and then retry your upgrade.
> > 
> > When I try the command you shared, it says -
> > 
> > root@debian:~# update-rc.d mountkernfs.sh enable S
> > update-rc.d: error: cannot find a LSB script for mountkernfs.sh
> 
> Seems there is no /etc/init.d/mountkernfs.sh on your system.
> 
> Since your init system is systemd, I question, why do you need insserv
> in first place. Do you have bin:initscripts installed?
> 
> My guess is that update-initramfs invokes insserv /if/ it is available,
> and since you have insserv installed, but no initscripts, we get this
> bug.

It does not.

Ben.

> Adding initramfs-tools maintainer into loop. If my guess is correct,
> this issue should be resolved on initramfs side, since making insserv
> depending on initscripts is not nice to user.
-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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

Bug#911408: dnsmasq breaks systemd autopkgtest

[Martin Pitt]

Hello all,

Paul Gevers [2018-10-19 21:07 +0200]:
> With a recent upload of dnsmasq the autopkgtest of systemd fails in
> testing when that autopkgtest is run with the binary packages of dnsmasq
> from unstable.

I fixed (or rather, worked around) this recently in
https://github.com/systemd/systemd/pull/11784

I spent several hours trying to configure dnsmasq 2.80 to be an authoritative
zone server with various combinations of --address, --auth-server, --auth-zone,
--local-service, and others, and then gave up. It's not that important, we can
live with the little hack in the networkd test. That worked [1].
(Note, now they fail again, but on a different reason, I'm investigating that in
[2]).

Not sure if this is an actual regression in dnsmasq, I leave it for the package
maintainer to decide whether to close this.

Thanks,

Martin

[1] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/systemd/1978562/log.gz
[2] https://github.com/systemd/systemd/pull/11814


signature.asc
Description: PGP signature

Bug#923223: XML::Parser::parsefile() uses 2-argument open

[Xavier]

Le 27/02/2019 à 15:35, Gianfranco Costamagna a écrit :
> reopen 923223
> affects 923223 src:xmltv
> severity 923223 serious
> thanks
> 
> Hello, the latest update of libxml-parser-perl seems to have broken xmltv 
> testsuite, and now it is failing to build from source.
> 
> I suspect the testsuite of xmltv might just need updates, but I don't know if 
> the package is really broken, and how much in the archive is now not building 
> anymore due to this change.
> 
> Can you please clarify if this is something we should deal with in xmltv or 
> not?
> https://ci.debian.net/packages/x/xmltv/unstable/amd64/
> I see there are some "open" calls in the testsuite, this is why I'm blaming 
> this fix...
> 
> snip of the failing testsuite
> 
> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Movie1-case-insensitive.xml > 
> '/tmp/Tl8eCfv0EW/Movie1-case-insensitive.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 2
> /usr/bin/tv_imdb --movies-only --quiet --imdbdir '/tmp/Tl8eCfv0EW' 
> --with-keywords --with-plot < t/data-tv_imdb/Movie1-movies-only.xml > 
> '/tmp/Tl8eCfv0EW/Movie1-movies-only.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 3
> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Movie1.xml > 
> '/tmp/Tl8eCfv0EW/Movie1.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 4
> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Movie100-years.xml > 
> '/tmp/Tl8eCfv0EW/Movie100-years.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 5
> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Movie101-movie-and-tv.xml > 
> '/tmp/Tl8eCfv0EW/Movie101-movie-and-tv.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 6
> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Movie21-accents.xml > 
> '/tmp/Tl8eCfv0EW/Movie21-accents.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 7
> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Movie22-dots.xml > 
> '/tmp/Tl8eCfv0EW/Movie22-dots.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 8
> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Movie3-and-amp.xml > 
> '/tmp/Tl8eCfv0EW/Movie3-and-amp.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 9
> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Movie5-ignore-punc.xml > 
> '/tmp/Tl8eCfv0EW/Movie5-ignore-punc.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 10
> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Movie5-with-punc.xml > 
> '/tmp/Tl8eCfv0EW/Movie5-with-punc.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 11
> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Movie6-articles.xml > 
> '/tmp/Tl8eCfv0EW/Movie6-articles.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 12
> /usr/bin/tv_imdb --movies-only --quiet --imdbdir '/tmp/Tl8eCfv0EW' 
> --with-keywords --with-plot < t/data-tv_imdb/Show1-movies-only.xml > 
> '/tmp/Tl8eCfv0EW/Show1-movies-only.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 13
> /usr/bin/tv_imdb --quiet --imdbdir '/tmp/Tl8eCfv0EW' --with-keywords 
> --with-plot < t/data-tv_imdb/Show1.xml > 
> '/tmp/Tl8eCfv0EW/Show1.xml-output.xml' 2>&1 failed: 2, 0, 0
> not ok 14
> Failed 13/14 subtests 
> t/test_tv_split.t  
> 
> thanks for having a look
> 
> Gianfranco

Hi all,

after some tries, I didn't succeed to find a way to patch
libxml-parser-perl without breaking xmltv. Can someone else take a look ?

Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook

[Jonas Smedegaard]

Package: initramfs-tools
Version: 0.133
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Building a system image using multistrap,
including generating an initial ramdisk,
worked fine recently.

Now it fails with this error message:

  W: Couldn't identify type of root file system for fsck hook

It seems to me that git commit a8ed874 intended to extend the code
operating on "auto" mounted filesystems to cover all _except_ root disk,
but that the logic is flipped around so that now it _only_ extends that
to include root disk:

- -   case "$MNT_TYPE" in
- -   auto)
[...]
+   # Ignore filesystem type for /, as it is not available and
+   # therefore never used at boot time
+   if [ "${MNT_DIR}" = "/" ] || [ "${MNT_TYPE}" = "auto" ]; then


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlx2vqoACgkQLHwxRsGg
ASF8ohAAjuJLFgguQyXi0Xp+v2YhFWxqiZxnSBav7/f85S3UjaqUNU3DjXdFv/FJ
7SkzZShmdqGIkpjxGyajRBGbFZzDJkR2Xn7p1T+CcYHvOcUNPfcWzHumc120l9mW
f74frkEC6J/IZX3tFRRXsEZaZ9ZasA16mvoQyL6lXR6ys22gQa3fEVRpGS95jxm2
hH4OorJSLeaGNYiXUMDmav29Aom1We7sojs/fdkQXiSE7Q0nc9jeuOOsSXLkFgKI
EvK88J3YpjuzXGNtwYbVn1QyVAYSAqrDyLyTtjtFwUjQbQc3jy/rYW/DeoTQ8lD2
syKc7e2N0xz02Y3JOQWxMdA+SdlQqeiGkQI7AHL23D0MXLcVkCp9WfWfOAlulpKd
tNrf7+Bc+tSBz4uNy04xP5UzhLcOKOPy1Rxz2ItSd6vZF0BL/4fptMZBMlvqxWsX
f3soeauNDC9F0584K0Fkuhta8jI3KYAJkNOw1omBzjunf8TpnAEKIvr7IfEk9RJp
FnE7TF9fUurxxnZx8crBCzNqFRkwj0oCjno/0HMvNKYbucPaXCD/Oco7aU4/KnbP
YVj5i9V/sfS7f68N3q6tZF09Tcd0IKPkItm7i796GtQRcVwvLpa7CPPMz4WK33bE
P6lP1/ldcx2+THYbL1i4xGhA3S24g4Nn1DSqNZRaZA90cLtZGKU=
=0zMd
-END PGP SIGNATURE-

Bug#916587: AppArmor breaks virtio-gpu + virgl

[Francois Gouget]

I got the virto-gpu + Virgl configuration to work with the configuration 
file I posted.

When I edited the file I fumbled a bit so I suspect what happened is 
that at some point I broke the AppArmor state in some subtle way. Then 
it all got fixed a bit later when I rebooted.

So the important thing is: the file I posted works!

-- 
Francois Gouget   http://fgouget.free.fr/
question = ( to ) ? be : ! be;
  -- Wm. Shakespeare