Bug#922811: RFP: transporter -- GUI magic-wormhole client that makes file transfer between computers a breeze

[Nicholas D Steeves]

Hi Antoine!

On Thu, Feb 21, 2019 at 12:48:14PM -0500, Antoine Beaupré wrote:
> On 2019-02-20 20:13:33, Nicholas D Steeves wrote:
> 
> > This package is a useful inclusion to Debian because it makes Magic
> > Wormhole accessible to users who are not comfortable using the command
> > line; this lowers the barrier to entry to file-transfers that avoid
> > corporate data-mining such as Dropbox, Google Drive, unencrypted
> > email, etc.  I learned of its existence in the following article:
> >   
> > https://medium.com/elementaryos/appcenter-spotlight-transporter-7c9db2472f37
> 
> Wow, that's great!
>

I think so too, especially since we probably both agree that Syncthing
is still too difficult to set up for the users noted below ;-)

> It would be great if this would also be available for other platforms
> (iOS, OSX, Windows) as file sharing between geeks only goes so far - it
> is, after all, the current state of affaires with wormhole
> itself... Getting a GUI is sure nice but won't help our peers in the
> walled gardens out there...
> 
> Not sure how portable Vala is anyways?
>

I don't have any experience with the language, but read that "Vala is a cross 
platform development tool with third party distributions providing binaries for 
Windows, macOS, Linux, *BSDs and other platforms"
  https://wiki.gnome.org/Projects/Vala

And it looks like something like this one liner will produce either a
statically linked binary or win32 binary + associated DLLs (similarly
to how I've seen some python apps for Windows)
  # valac --pkg gtk+-3.0 -X -mwindows gtk.vala
  http://valainstaller.sourceforge.net/

Hm, I wonder if Wormhole could someday become a standard for sending
confidential files?  Interfax is overkill for non-businesses, after
all.

> > Given that ElementaryOS has a pay-what-you-want Appstore model, and
> > the upstream developer primarily targeted this platform, I believe
> > they would appreciate it if their software was packaged with
> > upstream/metadata containing a "Donation: $URL" field.
> 
> I didn't know about this field, but sure why not...
>

Thanks :-) My rose-tinted glasses call it a small kindness.

> > CCing the magic-wormhole maintainer and GNOME team, who seem like the
> > people who would be most interested in packaging this.
> 
> As one of the wormhole maintainers, I'm interested in seeing this exist
> as well!

Yay! :-D

> > 'wish I had learned of it months ago so that it could have been part
> > of Buster!
> 
> We can always backport, that shouldn't be too hard...
> 

Good point, and of course popular downstreams of Debian will import it
for their next release--thinking about less technical users' access to
the software, you know? ;-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#923025: powertop: New version 2.10 is available

[陳侃如]

Package: powertop
Version: 2.8-1+b2
Severity: wishlist

Dear Maintainer,

The latest version 2.8-1 in Debian is very old. Upstream has released
2.10 recently, please consider package it.

Cheers,
Kanru

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

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

Versions of packages powertop depends on:
ii  libc6 2.28-7
ii  libgcc1   1:8.2.0-21
ii  libncurses6   6.1+20181013-2
ii  libncursesw6  6.1+20181013-2
ii  libnl-3-200   3.4.0-1
ii  libnl-genl-3-200  3.4.0-1
ii  libpci3   1:3.5.2-1
ii  libstdc++68.2.0-21
ii  libtinfo6 6.1+20181013-2

powertop recommends no packages.

Versions of packages powertop suggests:
pn  cpufrequtils   
pn  laptop-mode-tools  

-- no debconf information

Bug#923024: libteam-utils: teamd can not be run as root

[Arthur Gautier]

Package: libteam-utils
Version: 1.26-1
Severity: important

Dear Maintainer,

Teamd reports a message like:
  This program is not intended to be run as root.
When trying to run. Teamd cannot be run as a simple user either because
it needs permissions you don't get as user.

Instead, I believe it must be compiled with `configure 
--with-user=randomuser` so that it may downgrade its permissions.

The commit that introduced it is:
  
https://github.com/jpirko/libteam/commit/a6e7faccf949c1650c4f3da765459a113c454b19

I believe the patch attached fixes the issue. A fix for stretch would
be very much appreciated if possible.

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

Kernel: Linux 4.18.5+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages libteam-utils depends on:
ii  libc6 2.28-7
ii  libdaemon00.14-7
ii  libdbus-1-3   1.12.12-1
ii  libjansson4   2.12-1
pn  libteam5  
ii  libteamdctl0  1.28-1

libteam-utils recommends no packages.

libteam-utils suggests no packages.
diff -Nur a/debian/control b/debian/control
--- a/debian/control2016-08-27 12:18:08.0 +
+++ b/debian/control2019-02-23 04:36:47.336504690 +
@@ -11,6 +11,7 @@
   ,libnl-genl-3-dev
   ,libnl-route-3-dev (>= 3.2.19)
   ,pkg-config
+  ,libcap-dev
 Standards-Version: 3.9.8
 Homepage: http://libteam.org
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/libteam.git
@@ -90,7 +91,7 @@
 
 Package: libteam-utils
 Architecture: linux-any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: adduser, ${shlibs:Depends}, ${misc:Depends}
 # if-pre-up, if-post-down:
 #,jq
 Recommends:
diff -Nur a/debian/libteam-utils.postinst b/debian/libteam-utils.postinst
--- a/debian/libteam-utils.postinst 1970-01-01 00:00:00.0 +
+++ b/debian/libteam-utils.postinst 2019-02-23 04:31:34.820251196 +
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+case "$1" in
+configure|reconfigure)
+adduser --system --disabled-password --disabled-login --home 
/var/run/teamd \
+   --no-create-home --quiet --force-badname --group _teamd
+;;
+esac
+
+#DEBHELPER#
+
+exit 0
diff -Nur a/debian/libteam-utils.postrm b/debian/libteam-utils.postrm
--- a/debian/libteam-utils.postrm   1970-01-01 00:00:00.0 +
+++ b/debian/libteam-utils.postrm   2019-02-23 06:35:52.419126722 +
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+set -e
+
+#DEBHELPER#
+
+case "$1" in
+purge)
+rm -rf /var/run/teamd
+;;
+*)
+;;
+esac
+
+exit 0
diff -Nur a/debian/rules b/debian/rules
--- a/debian/rules  2013-12-04 17:21:55.0 +
+++ b/debian/rules  2019-02-23 04:29:37.496156030 +
@@ -11,7 +11,9 @@
#./autogen.sh
dh_auto_configure -- \
   --disable-silent-rules \
-  --enable-static=no
+  --enable-static=no \
+  --with-user=_teamd \
+  --with-group=_teamd \
 
 override_dh_auto_install:
dh_auto_install --destdir=$(CURDIR)/debian/tmp

Bug#922929: doc-debian: please convert to git and migrate to salsa

[Joost van Baal-Ilić]

Hi,

On Thu, Feb 21, 2019 at 11:05:59PM +0100, Joost van Baal-Ilić wrote:
> 
> https://tracker.debian.org/pkg/doc-debian still lists
> svn://anonscm.debian.org/ddp/packages/trunk/doc-debian/ as vcs.
> 
> The repo should get converted from SVN to git and should get moved to e.g.
> https://salsa.debian.org/ddp-team .

Now working on it.  (Found back our old svn repo @
https://alioth-archive.debian.org/svn/ddp.tar.xz, svndumpfilter-ing now.)

Bye,

Joost

PS/Notes to self:

> (it seems https://salsa.debian.org/debian/ddp is not used; maybe
> that should get removed?)

And, at svn://anonscm.debian.org/ddp/ we also used to have:

 webpages: 1998 - 2000
 articles: 2002 (just one commit, xml/sgml source for
  counting-potatoes debian-international debian-presentation package-interfaces
 man-cgi: 2007 - 2017 (and obsolete)
 manpages: 2002 - 2006 (manpage translations in 9 languages, likely/hopely now
  merged and maintained in upstream projects)
 utils: 2002 - 2003

This did not end up @ https://salsa.debian.org/ddp-team .  Perhaps that should
just stay archived there?

Bug#923023: original-awk FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: original-awk
Version: 2012-12-20-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

original-awk fails to cross build from source, because the packaging
forces the build architecture compiler "gcc". Using a triplet-prefixed
compiler fixes that, but makes executing maketab fail. For building
maketabe the build architecture compiler was the right thing. So we also
need to extend the build system to differentiate between these
compilers. The attached patch implements that and makes original-awk
cross buildable. Please consider applying it.

Helmut
diff --minimal -Nru original-awk-2012-12-20/debian/changelog 
original-awk-2012-12-20/debian/changelog
--- original-awk-2012-12-20/debian/changelog2017-01-08 18:47:44.0 
+0100
+++ original-awk-2012-12-20/debian/changelog2017-08-05 22:00:10.0 
+0200
@@ -1,3 +1,12 @@
+original-awk (2012-12-20-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Closes: #-1.
++ Let dpkg's buildtools.mk supply CC and CC_FOR_BUILD.
++ cross.patch: Use CC_FOR_BUILD for maketab.
+
+ -- Helmut Grohne   Sat, 05 Aug 2017 22:00:10 +0200
+
 original-awk (2012-12-20-6) unstable; urgency=medium
 
   * Rename all patches to end with .patch.
diff --minimal -Nru original-awk-2012-12-20/debian/patches/cross.patch 
original-awk-2012-12-20/debian/patches/cross.patch
--- original-awk-2012-12-20/debian/patches/cross.patch  1970-01-01 
01:00:00.0 +0100
+++ original-awk-2012-12-20/debian/patches/cross.patch  2017-08-05 
22:00:10.0 +0200
@@ -0,0 +1,19 @@
+--- original-awk-2012-12-20.orig/makefile
 original-awk-2012-12-20/makefile
+@@ -30,6 +30,7 @@
+ CC = gcc -fprofile-arcs -ftest-coverage # then gcov f1.c; cat f1.c.gcov
+ CC = gcc -g -Wall -pedantic 
+ CC = gcc -O4 -Wall -pedantic -fno-strict-aliasing
++CC_FOR_BUILD ?= $(CC)
+ 
+ YACC = bison -d -y
+ YACC = yacc -d -S
+@@ -62,7 +63,7 @@
+   ./maketab >proctab.c
+ 
+ maketab:  ytab.h maketab.c
+-  $(CC) $(CFLAGS) maketab.c -o maketab
++  $(CC_FOR_BUILD) $(CFLAGS) maketab.c -o maketab
+ 
+ bundle:
+   @cp ytab.h ytabh.bak
diff --minimal -Nru original-awk-2012-12-20/debian/patches/series 
original-awk-2012-12-20/debian/patches/series
--- original-awk-2012-12-20/debian/patches/series   2017-01-08 
17:00:00.0 +0100
+++ original-awk-2012-12-20/debian/patches/series   2017-08-05 
22:00:10.0 +0200
@@ -1,3 +1,4 @@
 01-awk-is-called-original-awk-here.patch
 02-remove-generated-files-in-clean-target.patch
 03-cflags-and-cppflags-together.patch
+cross.patch
diff --minimal -Nru original-awk-2012-12-20/debian/rules 
original-awk-2012-12-20/debian/rules
--- original-awk-2012-12-20/debian/rules2017-01-08 17:00:00.0 
+0100
+++ original-awk-2012-12-20/debian/rules2017-08-05 22:00:10.0 
+0200
@@ -1,4 +1,8 @@
 #!/usr/bin/make -f
+
+-include /usr/share/dpkg/buildtools.mk
+CC_FOR_BUILD ?= cc
+
 %:
dh $@
 
@@ -6,13 +10,12 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
-CC = gcc
 CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall
 LDFLAGS := `dpkg-buildflags --get LDFLAGS`
 CPPFLAGS := `dpkg-buildflags --get CPPFLAGS`
 
 override_dh_auto_build:
-   dh_auto_build -- CC="$(CC)" CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" 
ALLOC="$(LDFLAGS)" YACC="bison -d -y"
+   dh_auto_build -- CC="$(CC)" CC_FOR_BUILD="$(CC_FOR_BUILD)" 
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" ALLOC="$(LDFLAGS)" YACC="bison -d -y"
 
 override_dh_auto_install:
install -m 755 a.out debian/$(package)/usr/bin/$(package)

Bug#923013: [Pkg-xen-devel] Bug#923013: xen: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

Correction. I said:
> "dpkg-buildpackage -B" (to generate arch-indep packages).

but really meant this:

"dpkg-buildpackage -B" (to generate arch-dep packages).

Sorry for the confusion.

Bug#923013: [Pkg-xen-devel] Bug#923013: xen: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

On Sat, Feb 23, 2019 at 01:15:49AM +0100, Hans van Kranenburg wrote:

> Can you please help me by formulating a clear problem / question and if
> possible some expected things that you would like to have as a result?

Sure. This is a packaging bug in debian/rules. Packages must build for the
end user with plain "dpkg-buildpackage" but also in the official
autobuilders by doing "dpkg-buildpackage -A" (to generate arch-all
packages) or "dpkg-buildpackage -B" (to generate arch-indep packages).

Either of those failing is a FTBFS bug, hence the serious severity.

To reproduce the problem, please try building the package with 
"dpkg-buildpackage -A", which is exactly what the arch:all
autobuilder would do if the package was uploaded in source-only form.

The hint of splitting dh_foo into dh_foo-arch and dh_foo-indep usually
works for packages that use dh and have this bug, i.e. for packages
which build ok when built with plain "dpkg-buildpackage" but not with
"dpkg-buildpackage -A" or "dpkg-buildpackage -B".

Thanks.

Bug#759487: smokeping: reporting a bug tries to include private data into the bug report

[Gabriel Filion]

Hello,

I've taken a look at this issue and I believe that in theory the file
"smokeping_secrets" should not be managed by the package as a config
file at all.

...however while trying to patch the package for this, I relized the
following:

 * smokeing absolutely *wants* to have "secrets=" defined
 * the file pointed to by "secrets=" *must* exist
 * setting "secrets=/dev/null" (this would arguably be a very ugly hack)
does not work: smokeping wants a plain file

so we're stuck here. if we want the default configuration to work and
have a functional service right after install, we need to deploy the
file and point configuration to it.


... maybe something that could work would be to touch the file from
postinst, but I'm not yet convinced this is so great.



signature.asc
Description: OpenPGP digital signature

Bug#921809: [Pkg-rust-maintainers] Bug#921809: rustc: LLVM ERROR: Undefined temporary symbol (rust-wasm-bindgen-macro-support/ppc64el)

[Seo Sanghyeon]

This is upstream https://github.com/rust-lang/rust/issues/58516.

-- 
Seo Sanghyeon

Bug#923022: console-setup ships minified shell scripts

[Wookey]

Package: console-setup
Version: 1.189
Severity: normal
Tags: patch

/bin/setupcon and /usr/bin/ckbcomp-mini are both shell scripts that
are minified (preprocessed to remove comments, whitespace and
indenting) before being shipped in the udeb.

/usr/lib/base-installer.d/20console-setup and 
usr/share/console-setup/keyboard-configuration.config

setupcon is a 38K script before minifying and 22K afterwards. It's
extremely difficult to read to work out what on earth it is doing when
in that state, and this is sometimes necessary (e.g. when debugging
debian-installer). ckbcomp-mini goes from 5.4K to 3.3K keyboardconfiguration 
from 47K to 44K

The debian config and postinst scripts get the same treatment (in the
conventional and udeb packages

Why are we minifying these scripts? Perhaps it made sense once to
squeeze the size of console-setup by a few K (maybe 24?), but it seems
very unlikely to be useful any more, given the cost of making
comprehension of the code almost impossible.

Attached is a patch to stop doing this. (It makes the udeb 6K bigger)
commit dac59c59d9a71612e8a1fbca744ba3b53f57663e
Author: Wookey 
Date:   Sat Feb 23 04:10:42 2019 +

Stop minifying shell scripts

diff --git a/debian/changelog b/debian/changelog
index ea8a91d..c43b1db 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+console-setup (1.190) unstable; urgency=medium
+
+  * Stop minifying shell scripts
+
+ -- Wookey   Sat, 23 Feb 2019 03:23:03 +
+
 console-setup (1.189) unstable; urgency=medium
   * Team upload
 
diff --git a/debian/preprocessor b/debian/preprocessor
index a9c3aa5..9571309 100755
--- a/debian/preprocessor
+++ b/debian/preprocessor
@@ -94,11 +94,6 @@ else
 }' "$file" >$tmp && cat $tmp >"$file"
 fi
 
-if [ "$mini" ]; then
-sed -e 's/^[ \t]*//' -e 's/^#[^!].*//' -e 's/^#$//' <"$file" >$tmp \
-   && grep . $tmp >"$file"
-fi
-
 rm $tmp
 
 exit 0

Bug#916594: [Pkg-mozext-maintainers] Bug#916594: Bug#916594: webext-umatrix: Can not load configuration from backup

[Antoine Beaupré]

Control: reopen -1
Control: found -1 1.3.16+dfsg-1

On 2019-02-23 02:55:00, Ximin Luo wrote:
> Version: -1 1.3.16+dfsg-1
>
> Antoine Beaupré:
>> On 2019-02-22 07:41:00, Ximin Luo wrote:
>>> Control: severity -1 important
>>> Control: forwarded -1 
>>> https://github.com/uBlockOrigin/uBlock-issues/issues/144
>>> Control: tags -1 + upstream
>>>
>>> Bumping down the severity, there is no data loss. The "backup" function 
>>> works fine, it's just the "restore" functionality that doesn't work.
>> 
>> Okay, but from my perspective, installing this software means I lose all
>> my settings from the non-Debian package version. That's why I said "data
>> loss".
>> 
>> After all, a backup is worth nothing if you can't restore it. ;)
>
> Sure, I get that, but from other users' perspective that don't need to 
> restore a previous backup, the extension works fine.

Hm. Well it works, but I'm not sure it works "fine". ;)

Anyways - I'm not sure I want to argue this to the death, I see where
you're coming from.

> Actually I just tried the latest version and restore seems to be working 
> correctly. I must have been confused when dealing with all these multiple bug 
> reports or something. Please re-open if it doesn't work for you. Note that 
> you might need to work around bug 919557 first - either by using firefox-esr, 
> or doing `sudo rm /usr/share/webext/umatrix/lib/punycode.js && sudo cp 
> /usr/share/javascript/punycode/punycode.js 
> /usr/share/webext/umatrix/lib/punycode.js`.

Are you sure this is the same bug?

Here if I follow those instructions in buster with 1.3.16, the bug still
occurs, so I don't believe this is strictly related to #919557.

A.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker

Bug#923021: Kernel oops using Buster Alpha 5 armhf installer onto ClearFog Base

[Joel Johnson]

Package: installation-reports

Boot method: microSD card
Image version: 
http://ftp.debian.org/debian/dists/testing/main/installer-armhf/current/images/hd-media/hd-media.tar.gz

Date: 2019-02-22T20:57:53-07:00

Machine: ClearFog Base
Processor: Marvell ARMADA A388 ARM A9
Memory: 1GB
Partitions: single ext4 partition, primary part 1

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [ ]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

I encounter a consistent kernel oops when trying to install Debian onto 
a SolidRun ClearFog Base device. I previously attempted installation 
using the Buster Alpha 4 version of the installer, and have just 
retested using Alpha 5 version and get the same result. This particular 
device is using a self-compiled U-Boot version based on upstream sources 
at v2018.11.


To prepare the installation media, I downloaded the armhf hd-media 
archive [1], and then unpacked the contents into a single ext4 partition 
on a micro SD card. I then copied the armhf netinst ISO image to the 
root of the filesystem.


The installer boots successfully, goes through the language selection 
and location prompts, then proceeds to mount the mmcblk0 device, find 
the ISO image, and cycles through "Loading additional components". When 
it completes component loading, it proceed to detecting network devices, 
at which point I get a kernel oops dump like the one below. The 
installation happens via serial (USB FTDI) connection, so I apologize 
for the corruption in the capture of the message.


[   68.717677] Unable to handle kernel paging request at virtual address 
2680

[   68.725981] pgd = (ptrval)
[   68.730086] [2680] *pgd=
[   68.735082] Internal error: Oops: 5 [#1] SMP ARM
[   68.741086] Modules linked in: marvell mvmdio(+) mvneta(+) mvneta_bm 
phylink sfp mdio_i2c nls_utf8 dm_mod loop isofs vfat fat ext4 crc16 
mbcache jbd2 crc32c_generic fscrypto usb_storage sd_mod gpio_pca953x 
ehci_orion ahci_mve bu ehci_hcd libahci_platform libahci sdhci_pxav3 
xhci_plat_hcd xhci_hcd sdhci_pltfm libata sdhci scsi_mod usbcore 
i2c_mv64xxx
[   68.772053] CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted 
4.19.0-1-armmp #1 Debian 4.19.12-1

[   68.780422] Hardware name: Marvell Armada 380/385 (Device Tree)
[   68.786370] Workqueue: events_power_efficient phylink_resolve 
[phylink]

[   68.793033] PC is at mvneta_port_down+0x20/0x1a0 [mvneta]
[   68.798454] LR is at mvneta_mac_link_down+0x24/0x90 [mvneta]
[   68.804125] pc : []lr : []psr: 600b0013
[   68.810406] sp : ee96be60  ip : ee96be88  fp : ee96be84
[   68.815641] r10:   r9 : eef1c99c  r8 : eef1c900
[   68.820876] r7 : eef1c960  r6 : ede82000  r5 : 0002  r4 : 
ede82580
[   68.827417] r3 : 2680  r2 : 0004  r1 : 0002  r0 : 
ede82580
[   68.833959] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  
Segment none

[   68.841109] Control: 10c5387d  Table: 0fe9804a  DAC: 0051
[   68.846867] Process kworker/0:1 (pid: 13, stack limit = 0x(ptrval))
[   68.853147] Stack: (0xee96be60 to 0xee96c000)
[   68.857514] be60: ede82000 0002 ede82000 eef1c960 eef1c900 
eef1c99c ee96bea4 ee96be88
[   68.865711] be80: bf51b490 bf51b2d8 eef1c998 c1105dcc ede82000 
eef1c960 ee96befc ee96bea8
[   68.873908] bea0: bf507000 bf51b478 c0aeb1e8 c037bc10 0001 
 ee96bee4 ee96bec8
[   68.882104] bec0: c04f637c c050ebdc  2e6b8000 c1018c40 
4bd6f77b ee8d6180 eef1c998
[   68.890301] bee0: ee8d6180 ef6d0840 ef6d3f00  ee96bf34 
ee96bf00 c036c090 bf506eac
[   68.898497] bf00: 0008 ef6d0858 c1104d00 ee8d6180 ee8d6194 
ef6d0840 0008 ef6d0858
[   68.906695] bf20: c1104d00 ef6d0840 ee96bf74 ee96bf38 c036d0a4 
c036bed4 ee8f6e40 c0c7436c
[   68.914891] bf40: c11f1428 e000 c0372638 ee8f6600 ee8f6e40 
 ee96a000 ee8d6180
[   68.923088] bf60: c036d044 ee957e74 ee96bfac ee96bf78 c0372b58 
c036d050 ee8f661c ee8f661c
[   68.931285] bf80: ee96bfac ee8f6e40 c03729ec   
  
[   68.939482] bfa0:  ee96bfb0 c03010e8 c03729f8  
  
[   68.947678] bfc0:      
  
[   68.955875] bfe0:     0013 
  
[   68.964102] [] (mvneta_port_down [mvneta]) from 
[] (mvneta_mac_link_down+0x24/0x90 [mvneta]
) ┌─┤ Detecting network hardware 
├──┐
[ │  
   │ (phylink_resolve+0x160/0x2dc [phylin
k]│0%  

Bug#922402: Bug #922402 in lintian marked as pending

[Roberto C . Sánchez]

On Fri, Feb 15, 2019 at 09:46:52PM +, Chris Lamb wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #922402 in lintian reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/lintian/lintian/commit/603d9f2c5f54af162dbbfccf370d1881bbc9430f
> 
> 
> Prevent false positives in pkg-config-references-unknown-shared-library (eg. 
> "-lm") by creating an exception list and populating with shared objects 
> shipped by libc6-dev. (Closes: #922402)
> 
> 
Hi Chris,

As I was working on packaging the new mongo-c-driver upstream, I
encountered the same problem, though with different libraries.

Here is the line from the pkg-config file:

Libs: -L${libdir} -lbson-static-1.0  -lpthread -lgcc -lgcc_s -lc -lgcc
-lgcc_s /usr/lib/x86_64-linux-gnu/librt.so
/usr/lib/x86_64-linux-gnu/libm.so

The complaints from lintian:

W: libbson-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lpthread (line 9)
W: libbson-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lgcc (line 9)
W: libbson-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lgcc_s (line 9)
W: libbson-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lc (line 9)
W: libbson-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lgcc (line 9)
W: libbson-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libbson-static-1.0.pc -lgcc_s (line 9)

It looks like perhaps libraries files shipped in libgcc1 also need to be
added to the whitelist.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#768555: bootlogd apparantly runs but /var/log/bootlog* files are from 2013

[Pierre Ynard]

> /etc/init.d/bootlogd [Errno 2] No such file or directory: 
> u'/etc/init.d/bootlogd'
> /etc/init.d/stop-bootlogd [Errno 2] No such file or directory: 
> u'/etc/init.d/stop-bootlogd'
> /etc/init.d/stop-bootlogd-single [Errno 2] No such file or directory: 
> u'/etc/init.d/stop-bootlogd-single'

Other reports featuring missing init scripts can be found in #663587 and
#689992, both originally about different issues. Reports in #689992 only
miss /etc/init.d/stop-bootlogd and /etc/init.d/stop-bootlogd-single, not
/etc/init.d/bootlogd

-- 
Pierre Ynard

Bug#689992: bootlogd doesn't log anything ni /var/log/boot

[Pierre Ynard]

retitle 689992 bootlogd doesn't log anything in /var/log/boot
merge 564149 689992
thanks

The original report here doesn't seem to miss any bootlogd init script,
so I'm merging with similar reports of unexplained failure.

The second and third reports miss /etc/init.d/stop-bootlogd and
/etc/init.d/stop-bootlogd-single, so they would be similar to #768555.

-- 
Pierre Ynard

Bug#663587: bootlogd: Missing /etc/default/bootlogd file

[Pierre Ynard]

retitle 663587 bootlogd: missing former /etc/default/bootlogd file confuses 
people
thanks

> bootlogd: Missing /etc/default/bootlogd file

We have a similar report found in #689992:

> I want to read the boot messages but, according to the wiki, there is
> no config file anymore. It seems that bootlogd runs as a service now.
> OK

bootlogd was split to its own package a while ago, which made
/etc/default/bootlogd obsolete:

> sysvinit-utils (2.88dsf-14) unstable; urgency=low
>
>   bootlogd has moved from sysvinit-utils to a separate bootlogd
>   package. If you wish to continue using bootlogd, please
>   install the bootlogd package. Note that the configuration file
>   /etc/default/bootlogd and its option BOOTLOGD_ENABLE no longer
>   exist; if you do not wish to run bootlogd, remove the bootlogd
>   package.
>
>  -- Josh Triplett   Sun, 09 Oct 2011 01:50:15 -0700

So I think that the meaning of the original report here is that
they read in some documentation somewhere or expected to edit
/etc/default/bootlogd to enable bootlogd, and figured something was
wrong because that file didn't exist on their system.

So this would be a case of outdated documentation somewhere or
"according to the wiki", or maybe just old habits. As for the sysvinit
package, I don't see that the change was documented elsewhere than in
the changelog, but anyway it's a bit late for that. This can probably be
closed.

The second report in this thread seems unrelated and would be a case
similar to #768555.

-- 
Pierre Ynard

Bug#923018: geeqie: Segfault on create new archive filters

[Andreas Ronnquist]

Control: tags moreinfo

On Sat, 23 Feb 2019 01:36:27 +0100 jEsuSdA  wrote:
> Package: geeqie
> Version: 1:1.4+git20190121-1
> Severity: important
> 
> Dear Maintainer,
> 
> Geeqie crashes when trying to editing archive preferences.
> 
> Once you try to ADD new archive filter, geeqie crashes.
> 
> Here, the configuration settings where the bug exists:
> https://i.imgur.com/nXGXQBR.png
> 

I cannot reproduce this - Does the program crash immediately as you
press the "Añadir" button?

A backtrace from the crash with debug symbols activated for geeqie would
be really helpful.

/Andreas Rönnquist
gus...@debian.org

Bug#766654: bootlogd: fails to log into /var/log/boot on Jessie, dependency libc0.1 missing

[Pierre Ynard]

retitle 766654 bootlogd: fails to log into /var/log/boot on Jessie
severity 564149 important
merge 564149 766654
thanks

> After checking with packages.debian.org missing dependency libc0.1

> Tried to install libc0.1 manually but no installation candidate
> available - proposed alternative packages tzdata, initscripts,
> libc-bin are installed.

I think there was some confusion from the reporter about the kfreebsd
dependency on libc0.1, which he doesn't seem to be using. Hence this is
just another unexplained case of bootlogd not logging to /var/log/boot.

-- 
Pierre Ynard

Bug#923020: Get LeakSanitizer has encountered a fatal error message when using tome --help

[shirish शिरीष]

Package: tome
Version: 2.4~0.git.2015.12.29-1.2+b2
Severity: normal

Dear Maintainer,

I get the following message whenever I use

$tome --help

==24605==LeakSanitizer has encountered a fatal error.
==24605==HINT: For debugging, try setting environment variable
LSAN_OPTIONS=verbosity=1:log_threads=1
==24605==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)

This comes after the options are listed.

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

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

Versions of packages tome depends on:
ii  libasan5   8.2.0-20
ii  libboost-filesystem1.67.0  1.67.0-13
ii  libboost-system1.67.0  1.67.0-13
ii  libc6  2.28-7
ii  libgcc11:8.2.0-20
ii  libjansson42.12-1
ii  libncurses66.1+20181013-2
ii  libsdl-image1.21.2.12-10
ii  libsdl-ttf2.0-02.0.11-6
ii  libsdl1.2debian1.2.15+dfsg2-4
ii  libstdc++6 8.2.0-20
ii  libtinfo6  6.1+20181013-2
ii  libubsan1  8.2.0-20
ii  libx11-6   2:1.6.7-1
ii  libxext6   2:1.3.3-1+b2

tome recommends no packages.

tome suggests no packages.

-- no debconf information


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

Bug#852927: dstat: FTBFS: Test failures

[Emanuele Rocca]

tag 852927 patch
thanks

On 28/01 09:25, Lucas Nussbaum wrote:
> > Traceback (most recent call last):
> >   File "./dstat", line 2842, in 
> > main()
> >   File "./dstat", line 2703, in main
> > scheduler.run()
> >   File "/usr/lib/python2.7/sched.py", line 117, in run
> > action(*argument)
> >   File "./dstat", line 2797, in perform
> > o.extract()
> >   File "/<>/plugins/dstat_top_int.py", line 40, in extract
> > total = (self.intset2[i] - self.intset1[i]) * 1.0 / elapsed
> > IndexError: list index out of range
> > Makefile:36: recipe for target 'test' failed

Fixed in 0.7.3-1.1. NUM diff attached.
diff -Nru dstat-0.7.3/debian/changelog dstat-0.7.3/debian/changelog
--- dstat-0.7.3/debian/changelog	2017-01-18 11:12:16.0 +0100
+++ dstat-0.7.3/debian/changelog	2019-02-23 02:10:18.0 +0100
@@ -1,3 +1,11 @@
+dstat (0.7.3-1.1) unstable; urgency=high
+
+  * Non-maintainer upload
+  * Fix crash in top-int plugin (closes: #852927)
+  * Exclude ntp plugin from --all-plugins, used by make test (closes: #857973)
+
+ -- Emanuele Rocca   Sat, 23 Feb 2019 02:10:18 +0100
+
 dstat (0.7.3-1) unstable; urgency=medium
 
   * New upstream release (closes: #851494)
diff -Nru dstat-0.7.3/debian/patches/all_plugins_exclude_ntp_857973 dstat-0.7.3/debian/patches/all_plugins_exclude_ntp_857973
--- dstat-0.7.3/debian/patches/all_plugins_exclude_ntp_857973	1970-01-01 01:00:00.0 +0100
+++ dstat-0.7.3/debian/patches/all_plugins_exclude_ntp_857973	2019-02-23 02:10:18.0 +0100
@@ -0,0 +1,20 @@
+Description: exclude ntp from --all-plugins
+ dstat allows to specify --all-plugins, a CLI option used by `make test` for
+ testing purposes. Exclude the ntp plugin from the list as it performs network
+ access.
+Author: Emanuele Rocca 
+Bug-Debian: https://bugs.debian.org/857973
+Last-Update: 2019-02-23
+
+--- dstat-0.7.3.orig/dstat
 dstat-0.7.3/dstat
+@@ -177,6 +177,9 @@ class Options:
+ ### Make list unique in a fancy fast way
+ plugins = {}.fromkeys(allplugins).keys()
+ plugins.sort()
++# Do not include ntp plugin as it performs network access. See
++# https://bugs.debian.org/857973
++plugins.remove('ntp')
+ self.plugins += plugins
+ elif opt in ['--bits']:
+ self.bits = True
diff -Nru dstat-0.7.3/debian/patches/series dstat-0.7.3/debian/patches/series
--- dstat-0.7.3/debian/patches/series	2014-03-24 03:02:19.0 +0100
+++ dstat-0.7.3/debian/patches/series	2019-02-23 02:10:18.0 +0100
@@ -1 +1,3 @@
 fix_629680
+top_int_plugin_852927
+all_plugins_exclude_ntp_857973
diff -Nru dstat-0.7.3/debian/patches/top_int_plugin_852927 dstat-0.7.3/debian/patches/top_int_plugin_852927
--- dstat-0.7.3/debian/patches/top_int_plugin_852927	1970-01-01 01:00:00.0 +0100
+++ dstat-0.7.3/debian/patches/top_int_plugin_852927	2019-02-23 02:08:28.0 +0100
@@ -0,0 +1,21 @@
+Description: avoid crashing in top-int plugin
+ The first intset can have less elements than the second one. Catch IndexError
+ to avoid crashing if that is the case.
+Author: Emanuele Rocca 
+Bug-Debian: https://bugs.debian.org/852927
+Last-Update: 2019-02-23
+
+--- dstat-0.7.3.orig/plugins/dstat_top_int.py
 dstat-0.7.3/plugins/dstat_top_int.py
+@@ -37,7 +37,10 @@ class dstat_plugin(dstat):
+ self.intset2 = [ long(int) for int in line[3:] ]
+ 
+ for i in range(len(self.intset2)):
+-total = (self.intset2[i] - self.intset1[i]) * 1.0 / elapsed
++try:
++total = (self.intset2[i] - self.intset1[i]) * 1.0 / elapsed
++except IndexError:
++continue
+ 
+ ### Put the highest value in self.val
+ if total > self.val['total']:

Bug#857973: dstat: uses network during build

[Emanuele Rocca]

tag 857973 patch
thanks

On 16/03 07:48, James Cowgill wrote:
> When running the testsuite, the ntp dstat plugin tries to get the time
> using NTP from 0.fedora.pool.ntp.org. As policy says, accessing the
> network in this way is not permitted for packages in the main archive.

Fixed by excluding ntp from --all-plugins. NMU diff attached.
diff -Nru dstat-0.7.3/debian/changelog dstat-0.7.3/debian/changelog
--- dstat-0.7.3/debian/changelog	2017-01-18 11:12:16.0 +0100
+++ dstat-0.7.3/debian/changelog	2019-02-23 02:10:18.0 +0100
@@ -1,3 +1,11 @@
+dstat (0.7.3-1.1) unstable; urgency=high
+
+  * Non-maintainer upload
+  * Fix crash in top-int plugin (closes: #852927)
+  * Exclude ntp plugin from --all-plugins, used by make test (closes: #857973)
+
+ -- Emanuele Rocca   Sat, 23 Feb 2019 02:10:18 +0100
+
 dstat (0.7.3-1) unstable; urgency=medium
 
   * New upstream release (closes: #851494)
diff -Nru dstat-0.7.3/debian/patches/all_plugins_exclude_ntp_857973 dstat-0.7.3/debian/patches/all_plugins_exclude_ntp_857973
--- dstat-0.7.3/debian/patches/all_plugins_exclude_ntp_857973	1970-01-01 01:00:00.0 +0100
+++ dstat-0.7.3/debian/patches/all_plugins_exclude_ntp_857973	2019-02-23 02:10:18.0 +0100
@@ -0,0 +1,20 @@
+Description: exclude ntp from --all-plugins
+ dstat allows to specify --all-plugins, a CLI option used by `make test` for
+ testing purposes. Exclude the ntp plugin from the list as it performs network
+ access.
+Author: Emanuele Rocca 
+Bug-Debian: https://bugs.debian.org/857973
+Last-Update: 2019-02-23
+
+--- dstat-0.7.3.orig/dstat
 dstat-0.7.3/dstat
+@@ -177,6 +177,9 @@ class Options:
+ ### Make list unique in a fancy fast way
+ plugins = {}.fromkeys(allplugins).keys()
+ plugins.sort()
++# Do not include ntp plugin as it performs network access. See
++# https://bugs.debian.org/857973
++plugins.remove('ntp')
+ self.plugins += plugins
+ elif opt in ['--bits']:
+ self.bits = True
diff -Nru dstat-0.7.3/debian/patches/series dstat-0.7.3/debian/patches/series
--- dstat-0.7.3/debian/patches/series	2014-03-24 03:02:19.0 +0100
+++ dstat-0.7.3/debian/patches/series	2019-02-23 02:10:18.0 +0100
@@ -1 +1,3 @@
 fix_629680
+top_int_plugin_852927
+all_plugins_exclude_ntp_857973
diff -Nru dstat-0.7.3/debian/patches/top_int_plugin_852927 dstat-0.7.3/debian/patches/top_int_plugin_852927
--- dstat-0.7.3/debian/patches/top_int_plugin_852927	1970-01-01 01:00:00.0 +0100
+++ dstat-0.7.3/debian/patches/top_int_plugin_852927	2019-02-23 02:08:28.0 +0100
@@ -0,0 +1,21 @@
+Description: avoid crashing in top-int plugin
+ The first intset can have less elements than the second one. Catch IndexError
+ to avoid crashing if that is the case.
+Author: Emanuele Rocca 
+Bug-Debian: https://bugs.debian.org/852927
+Last-Update: 2019-02-23
+
+--- dstat-0.7.3.orig/plugins/dstat_top_int.py
 dstat-0.7.3/plugins/dstat_top_int.py
+@@ -37,7 +37,10 @@ class dstat_plugin(dstat):
+ self.intset2 = [ long(int) for int in line[3:] ]
+ 
+ for i in range(len(self.intset2)):
+-total = (self.intset2[i] - self.intset1[i]) * 1.0 / elapsed
++try:
++total = (self.intset2[i] - self.intset1[i]) * 1.0 / elapsed
++except IndexError:
++continue
+ 
+ ### Put the highest value in self.val
+ if total > self.val['total']:

Bug#922952: ITP: simdjson -- Parsing gigabytes of JSON per second

[Sam Hartman]

I don't know about official policy, but I think you could make your bug
not RC by detecting whether the current system can support the package
in some reasonable wail and failing more gracefully than with SIGILL.

It's not a requirement that all packages work on all systems.
Open-vm-tools doesn't do squat if you aren't running on top of vmware;
pcscd is remarkably useless without a smartcard reader; etc.
I think it ought to be fine to have a package that is only useful with
some given hardware provided that  you're reasonable about detecting
requirements, and that  you don't place stronger requirements than are
actulaly needed by your package.

--Sam

Bug#908216: btrfs blocked for more than 120 seconds

[Russell Mosemann]

 
Package: src:linux
Version: 4.19.16-1~bpo9+1
Severity: important
 
 
 
Feb 22 19:09:23 vhost182 kernel: INFO: task btrfs-transacti:612 blocked for 
more than 120 seconds.
Feb 22 19:09:23 vhost182 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 22 19:09:23 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 22 19:09:23 vhost182 kernel: btrfs-transacti D0   612  2 0x8000
Feb 22 19:09:23 vhost182 kernel: Call Trace:
Feb 22 19:09:23 vhost182 kernel:  ? __schedule+0x3f5/0x880
Feb 22 19:09:23 vhost182 kernel:  schedule+0x32/0x80
Feb 22 19:09:23 vhost182 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 22 19:09:23 vhost182 kernel:  ? remove_wait_queue+0x60/0x60
Feb 22 19:09:23 vhost182 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Feb 22 19:09:23 vhost182 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Feb 22 19:09:23 vhost182 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Feb 22 19:09:23 vhost182 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Feb 22 19:09:23 vhost182 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Feb 22 19:09:23 vhost182 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Feb 22 19:09:23 vhost182 kernel:  kthread+0xf8/0x130
Feb 22 19:09:23 vhost182 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Feb 22 19:09:23 vhost182 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 22 19:09:23 vhost182 kernel:  ret_from_fork+0x35/0x40

Feb 22 19:11:24 vhost182 kernel: INFO: task btrfs-transacti:612 blocked for 
more than 120 seconds.
Feb 22 19:11:24 vhost182 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 22 19:11:24 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 22 19:11:24 vhost182 kernel: btrfs-transacti D0   612  2 0x8000
Feb 22 19:11:24 vhost182 kernel: Call Trace:
Feb 22 19:11:24 vhost182 kernel:  ? __schedule+0x3f5/0x880
Feb 22 19:11:24 vhost182 kernel:  schedule+0x32/0x80
Feb 22 19:11:24 vhost182 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 22 19:11:24 vhost182 kernel:  ? remove_wait_queue+0x60/0x60
Feb 22 19:11:24 vhost182 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Feb 22 19:11:24 vhost182 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Feb 22 19:11:24 vhost182 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Feb 22 19:11:24 vhost182 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Feb 22 19:11:24 vhost182 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Feb 22 19:11:24 vhost182 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Feb 22 19:11:24 vhost182 kernel:  kthread+0xf8/0x130
Feb 22 19:11:24 vhost182 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Feb 22 19:11:24 vhost182 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 22 19:11:24 vhost182 kernel:  ret_from_fork+0x35/0x40
Feb 22 19:13:25 vhost182 kernel: INFO: task btrfs-transacti:612 blocked for 
more than 120 seconds.
Feb 22 19:13:25 vhost182 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 22 19:13:25 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 22 19:13:25 vhost182 kernel: btrfs-transacti D0   612  2 0x8000
Feb 22 19:13:25 vhost182 kernel: Call Trace:
Feb 22 19:13:25 vhost182 kernel:  ? __schedule+0x3f5/0x880
Feb 22 19:13:25 vhost182 kernel:  schedule+0x32/0x80
Feb 22 19:13:25 vhost182 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 22 19:13:25 vhost182 kernel:  ? remove_wait_queue+0x60/0x60
Feb 22 19:13:25 vhost182 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Feb 22 19:13:25 vhost182 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Feb 22 19:13:25 vhost182 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Feb 22 19:13:25 vhost182 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Feb 22 19:13:25 vhost182 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Feb 22 19:13:25 vhost182 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Feb 22 19:13:25 vhost182 kernel:  kthread+0xf8/0x130
Feb 22 19:13:25 vhost182 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Feb 22 19:13:25 vhost182 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Feb 22 19:13:25 vhost182 kernel:  ret_from_fork+0x35/0x40

Feb 22 19:15:26 vhost182 kernel: INFO: task btrfs-transacti:612 blocked for 
more than 120 seconds.
Feb 22 19:15:26 vhost182 kernel:   Not tainted 4.19.0-0.bpo.2-amd64 #1 
Debian 4.19.16-1~bpo9+1
Feb 22 19:15:26 vhost182 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 22 19:15:26 vhost182 kernel: btrfs-transacti D0   612  2 0x8000
Feb 22 19:15:26 vhost182 kernel: Call Trace:
Feb 22 19:15:26 vhost182 kernel:  ? __schedule+0x3f5/0x880
Feb 22 19:15:26 vhost182 kernel:  schedule+0x32/0x80
Feb 22 19:15:26 vhost182 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Feb 22 19:15:26 vhost182 

Bug#531207: initscripts: modes of execution for services

[Sean Whitton]

Hello,

On Thu 21 Feb 2019 at 05:55PM +00, Dmitry Bogatov wrote:

> I support your proposal, but would not definitely volonteer to drive
> this initiative to get included into Policy. Either way, reassigning to
> debian-policy.

We would want to see this implemented in the archive before
standardising it in Policy.  Please consider reassigning the bug back to
the package in which it might be implemented, unless you have some
reason why the Policy change absolutely has to happen first.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#923019: RFS: pymacs/0.25-2 [ITA]

[eamanu15]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: ba...@debian.org

Dear mentors,

I am looking for a sponsor for my package "pymacs"

* Package name: pymacs
 Version : 0.25-2
 Upstream Author : François Pinard 
* URL : http://pymacs.progiciels-bpi.ca/
* License : GPL-2+
 Section : python

It builds those binary packages:

  pymacs - interface between Emacs Lisp and Python

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/pymacs


Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/p/pymacs/pymacs_0.25-2.dsc

More information about pymacs can be obtained from
http://pymacs.progiciels-bpi.ca/

Changes since the last upload:

[Ondřej Nový]
* Fixed VCS URL (https)
* d/control: Set Vcs-* to salsa.debian.org
* d/copyright: Use https protocol in Format field
* d/control: Remove ancient X-Python-Version field
* Convert git repository from git-dpm to gbp layout

[Emmanuel Arias]
* New Maintainer. Closes (#920406).
  - Update d/control. Add me to Uploaders field.
  - Update d/contorl. Add DPMT to Maintainer field.
* Update d/control.
  - Bump debhelper compatibility to debhelper-compat 11
(from 8).
* Delete d/compat file. This is becauase on d/control
  is set debhelper-compat on version 12.
* Update d/copyright file. Add me on debian/* files copyright.
* Update d/rules. Modify delete --list-missing
  from dh_install from override_dh_install. And add a
  override_dh_missing target where add dh_missing --list-missing
* Bump Standards-Version to 4.3.0 (from 3.9.5)


Regards,
Emmanuel Arias

-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#923013: [Pkg-xen-devel] Bug#923013: xen: FTBFS when built with dpkg-buildpackage -A

[Hans van Kranenburg]

On 2/23/19 1:15 AM, Hans van Kranenburg wrote:
> Hi,
> 
> On 2/23/19 12:59 AM, Santiago Vila wrote:
>>
>>> Hint: Try splitting override_dh_compress into override_dh_compress-arch
>>> and override_dh_compress-indep.
>>
>> Not really sure that this is a good hint in this case. The first rule 
>> showing an
>> error is certainly this one:
>>
>> find: 'debian/xen-hypervisor-*/usr/lib/debug': No such file or directory
>>
>> but maybe it's override_dh_missing the one that would benefit from an 
>> -arch/-indep split.
> 
> Can you please help me by formulating a clear problem / question and if
> possible some expected things that you would like to have as a result?
> 
> What I see flying by is: A B C and also X Y Z and you might R S T, and
> also, by the way: F G H.

Also, your new bts results in an...

"Serious (policy violations or makes package unfit for release)"

...listed for our packages, which is not nice, in this phase of the
release freeze cycle, because...

The whole thing builds just fine in sid and also in stretch here.

Can you explain why you want to do this?

Hans

Bug#922654: debian-policy: Section 9.1.2 points to a wrong FHS section?

[Sean Whitton]

Hello,

On Mon 18 Feb 2019 at 11:54PM +00, Linda Lapinlampi wrote:

> The policy says in section § 9.1.2. "Site-specific programs":
>
>> Packages must not create sub-directories in the directory /usr/local
>> itself, except those listed in FHS, section 4.5. However, you may
>> create directories below them as you wish. You must not remove any of
>> the directories listed in 4.5, even if you created them.
>
> FHS 3.0's section 4.5 is about a completely irrelevant /usr/include
> directory, not about /usr/local. I think this should point to section
> 4.9 in the FHS?
>
> In FHS 2.3, this "section 4.5" might have been right. But as said in
> policy 9.1.1:
>
>> The location of all files and directories must comply with the Filesystem
>> Hierarchy Standard (FHS), version 3.0, [...].
>
> No other exception is noted below that.

Thanks.  A patch would be welcome.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#923018: geeqie: Segfault on create new archive filters

[jEsuSdA]

Package: geeqie
Version: 1:1.4+git20190121-1
Severity: important

Dear Maintainer,

Geeqie crashes when trying to editing archive preferences.

Once you try to ADD new archive filter, geeqie crashes.

Here, the configuration settings where the bug exists:
https://i.imgur.com/nXGXQBR.png

Thanks!



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

Kernel: Linux 4.18.0-20.2-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages geeqie depends on:
ii  geeqie-common1:1.4+git20190121-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-2
ii  libcairo21.16.0-2
ii  libexiv2-14  0.25-4
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.2.0-13
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.2-3
ii  libgtk2.0-0  2.24.32-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblirc-client0  0.10.0-2+b1
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libpangoft2-1.0-01.42.4-3
ii  libstdc++6   8.2.0-13
ii  libtiff5 4.0.9-2
ii  sensible-utils   0.0.12

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.2.10-3
ii  exiftran 2.10-2+b3
ii  exiv20.25-4
ii  imagemagick  8:6.9.10.23+dfsg-2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2
ii  librsvg2-common  2.44.10-1
ii  ufraw-batch  0.22-4
ii  zenity   3.30.0-2

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.10.8-2
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1
ii  ufraw0.22-4
pn  xpaint   

-- no debconf information

Bug#923017: vlc-plugin-video-output: crash when pressing space while playing menu of VIDEO_TS folder copied to hard disk

[Bernhard Übelacker]

Package: vlc-plugin-video-output
Version: 3.0.6-1
Severity: normal
Tags: upstream upstream-fixed patch 


Dear Maintainer,
I received a "SIGFPE, Arithmetic exception." while the menu of a to
hard disk copied VIDEO_TS folder was playing and then pressing space.
For some reason I did not get that exception when pressing the pause
button in the gui.

This seems to be fixed upstream in commits [1] [2].

Kind regards,
Bernhard


[1] 
https://git.videolan.org/?p=vlc.git;a=commitdiff;h=90989df9e3aab300c2d09a8eb9c0570e4cba4efa
[2] 
https://git.videolan.org/?p=vlc.git;a=commitdiff;h=8a2db618c882d869d3dfe849a57b1eb1a268ac8b



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

Kernel: Linux 4.19.0-2-amd64 (SMP w/16 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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vlc-plugin-video-output depends on:
ii  libaa1   1.4p5-45
ii  libavcodec58 7:4.1-1
ii  libavutil56  7:4.1-1
ii  libc62.28-7
ii  libcaca0 0.99.beta19-2+b3
ii  libegl1  1.1.0-1
ii  libgl1   1.1.0-1
ii  libgles2 1.1.0-1
ii  libplacebo7  1.7.0-2
ii  libva-drm2   2.4.0-1
ii  libva-wayland2   2.4.0-1
ii  libva-x11-2  2.4.0-1
ii  libva2   2.4.0-1
ii  libvlccore9 [vlc-plugin-abi-3-0-0f]  3.0.6-1
ii  libwayland-client0   1.16.0-1
ii  libwayland-egl1  1.16.0-1
ii  libx11-6 2:1.6.7-1
ii  libxcb-keysyms1  0.4.0-1+b2
ii  libxcb-shm0  1.13.1-2
ii  libxcb-xv0   1.13.1-2
ii  libxcb1  1.13.1-2

vlc-plugin-video-output recommends no packages.

vlc-plugin-video-output suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.28-7
ii  libvlc5  3.0.6-1

Versions of packages libvlc5 depends on:
ii  libc62.28-7
ii  libvlccore9  3.0.6-1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.6-1

Versions of packages vlc depends on:
ii  vlc-bin  3.0.6-1
ii  vlc-plugin-base  3.0.6-1
ii  vlc-plugin-qt3.0.6-1

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.6-1
pn  vlc-plugin-notify  
pn  vlc-plugin-samba   
pn  vlc-plugin-skins2  
pn  vlc-plugin-video-splitter  
pn  vlc-plugin-visualization   

Versions of packages vlc-bin depends on:
ii  libc6   2.28-7
ii  libvlc-bin  3.0.6-1
ii  libvlc5 3.0.6-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-19
ii  libaom0  1.0.0-3
ii  libarchive13 3.3.3-4
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.1.8-1
ii  libass9  1:0.14.0-2
ii  libavahi-client3 0.7-4+b1
ii  libavahi-common3 0.7-4+b1
ii  libavc1394-0 0.5.4-5
ii  libavcodec58 7:4.1-1
ii  libavformat587:4.1-1
ii  libavutil56  7:4.1-1
ii  libbasicusageenvironment12018.11.26-1
ii  libbluray2   1:1.0.2-3
ii  libc62.28-7
ii  libcairo21.16.0-2
ii  libcddb2 1.3.2-6
ii  libchromaprint1  1.4.3-3
ii  libcrystalhd31:0.0~git20110715.fdd2f19-13
ii  libdbus-1-3  1.12.12-1
ii  libdc1394-22 2.2.5-1
ii  libdca0  0.0.6-1
ii  libdvbpsi10  1.3.2-1
ii  libdvdnav4   6.0.0-1
ii  libdvdread4  6.0.1-1
ii  libebml4v5   1.3.6-2
ii  libfaad2 2.8.8-1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libfribidi0  1.0.5-3.1
ii  libgcc1  1:8.2.0-20
ii  libgcrypt20  1.8.4-5
ii  libglib2.0-0 2.58.3-1
ii  libgnutls30  3.6.6-2
ii  libgpg-error01.35-1
ii  libgroupsock82018.11.26-1
ii  libharfbuzz0b2.3.1-1
ii  libixml10   

Bug#921586: RFS: pymacs/0.25-1.2 [ITA]

[eamanu15]

Hi,

> Any specific reason for using an non-maintainer upload version number
here?
No, I was wrong. I had a problem with package pymacs.
You can see: https://lists.debian.org/debian-mentors/2019/02/msg00153.html

But, I've ready upload to -2 version. I will send the RFS.

Thanks!
Regards!

El vie., 22 de feb. de 2019 a la(s) 15:30, Bart Martens (ba...@debian.org)
escribió:

> Hi Emmanuel,
>
> Good to see you want to adopt this package. However, the version ending
> with -1.2 seems meant for a non-maintainer upload. Any specific reason
> for using an non-maintainer upload version number here?
>
> Cheers,
>
> Bart
>
>

-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#923013: [Pkg-xen-devel] Bug#923013: xen: FTBFS when built with dpkg-buildpackage -A

[Hans van Kranenburg]

Hi,

On 2/23/19 12:59 AM, Santiago Vila wrote:
> 
>> Hint: Try splitting override_dh_compress into override_dh_compress-arch
>> and override_dh_compress-indep.
> 
> Not really sure that this is a good hint in this case. The first rule showing 
> an
> error is certainly this one:
> 
> find: 'debian/xen-hypervisor-*/usr/lib/debug': No such file or directory
> 
> but maybe it's override_dh_missing the one that would benefit from an 
> -arch/-indep split.

Can you please help me by formulating a clear problem / question and if
possible some expected things that you would like to have as a result?

What I see flying by is: A B C and also X Y Z and you might R S T, and
also, by the way: F G H.

Hans

Bug#923016: systemtap: scripts fail to compile with recent kernels

[Emanuele Rocca]

Package: systemtap
Version: 3.3-1
Severity: grave
Justification: renders package unusable

SystemTap 3.3-1 does not work with the kernel currently in sid, 
linux-image-4.19.0-3-amd64 4.19.20-1.

  $ sudo stap -e 'probe oneshot { println("hello world") }'
  In file included from 
/tmp/stapBznfoX/stap_7c11b6c20586a98b7853a74fee0e49f4_979_src.c:298:
  /usr/share/systemtap/runtime/linux/stp_tracepoint.c: In function 
‘stp_tracepoint_coming’:
  /usr/share/systemtap/runtime/linux/stp_tracepoint.c:281:6: error: assignment 
to ‘struct tracepoint *’ from ‘tracepoint_ptr_t’ {aka ‘const int’} makes 
pointer from integer without a cast [-Werror=int-conversion]
 tp = tp_mod->mod->tracepoints_ptrs[i];
^
  /usr/share/systemtap/runtime/linux/stp_tracepoint.c: In function 
‘stp_tracepoint_going’:
  /usr/share/systemtap/runtime/linux/stp_tracepoint.c:323:6: error: assignment 
to ‘struct tracepoint *’ from ‘tracepoint_ptr_t’ {aka ‘const int’} makes 
pointer from integer without a cast [-Werror=int-conversion]
 tp = tp_mod->mod->tracepoints_ptrs[i];
^
  cc1: all warnings being treated as errors
  make[3]: *** 
[/usr/src/linux-headers-4.19.0-3-common/scripts/Makefile.build:308: 
/tmp/stapBznfoX/stap_7c11b6c20586a98b7853a74fee0e49f4_979_src.o] Error 1
  make[2]: *** [/usr/src/linux-headers-4.19.0-3-common/Makefile:1535: 
_module_/tmp/stapBznfoX] Error 2
  make[1]: *** [Makefile:146: sub-make] Error 2
  make: *** [Makefile:8: all] Error 2
  WARNING: kbuild exited with status: 2
  Pass 4: compilation failed.  [man error::pass4]
  Tip: /usr/share/doc/systemtap/README.Debian should help you get started.

The latest upstream version (4.0) does however work fine. I'm gonna package it
right away to get a working SystemTap in Buster.

Bug#923015: udisks2: segfault in udisksd when unmounting usb stick

[Bernhard Übelacker]

Package: udisks2
Version: 2.8.1-3
Severity: normal


Dear Maintainer,
I received a crash of udevd by doing an unmount of a ntfs partition
of an usb stick via the plasma systray icon.

As far as I see in this case in function udisks_linux_drive_object_get_block
is a call to udisks_linux_block_object_get_device which that returned
a null pointer that get unconditionally dereferenced.

This was just a one time crash and I could not reproduce
it with the same usb stick.

I have systemd-coredump installed but unfortunately
no crash dump was collected.
More details in attached file.

Kind regards,
Bernhard


Feb 21 10:08:52 rechner udisksd[886]: g_object_ref: assertion 
'object->ref_count > 0' failed
Feb 21 10:08:52 rechner kernel: pool[15388]: segfault at 18 ip 55822b5966e2 
sp 7f458d8aa590 error 4 in udisksd[55822b579000+3c000]
Feb 21 10:08:52 rechner kernel: Code: c0 74 05 4c 39 20 74 0f 4c 89 e6 48 89 df 
e8 a5 49 fe ff 85 c0 74 c7 4c 89 e6 48 89 df e8 a6 4d fe ff 48 89 c7 e8 ce c7 
fe ff <48> 8b 78 18 49 89 c7 e8 82 3b fe ff 4c 89 f6 48 89 c7 e8 47 31 fe





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

Kernel: Linux 4.19.0-2-amd64 (SMP w/16 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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages udisks2 depends on:
ii  dbus   1.12.12-1
ii  libacl12.2.52-3+b1
ii  libatasmart4   0.19-5
ii  libblockdev-fs22.20-6
ii  libblockdev-loop2  2.20-6
ii  libblockdev-part2  2.20-6
ii  libblockdev-swap2  2.20-6
ii  libblockdev-utils2 2.20-6
ii  libblockdev2   2.20-6
ii  libc6  2.28-7
ii  libglib2.0-0   2.58.3-1
ii  libgudev-1.0-0 232-2
ii  libmount1  2.33.1-0.1
ii  libpam-systemd 240-5
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libsystemd0240-5
ii  libudisks2-0   2.8.1-3
ii  parted 3.2-24
ii  udev   240-5

Versions of packages udisks2 recommends:
ii  dosfstools   4.1-2
ii  e2fsprogs1.44.5-1
ii  eject2.1.5+deb1+cvs20081104-13.2
ii  exfat-utils  1.3.0-1
pn  libblockdev-crypto2  
ii  ntfs-3g  1:2017.3.23AR.3-2
ii  policykit-1  0.105-25

Versions of packages udisks2 suggests:
ii  btrfs-progs  4.20.1-2
ii  f2fs-tools   1.11.0-1.1
pn  libblockdev-mdraid2  
ii  mdadm4.1-1
pn  nilfs-tools  
ii  reiserfsprogs1:3.6.27-3
pn  udftools 
pn  udisks2-bcache   
pn  udisks2-btrfs
pn  udisks2-lvm2 
pn  udisks2-vdo  
pn  udisks2-zram 
ii  xfsprogs 4.15.1-1

-- no debconf information

Feb 21 10:08:52 rechner udisksd[886]: Cleaning up mount point 
/media/bernhard/CCCOMA_X64FRE_DE-DE_DV9 (device 8:33 is not mounted)
Feb 21 10:08:52 rechner systemd[1138]: 
media-bernhard-CCCOMA_X64FRE_DE\x2dDE_DV9.mount: Succeeded.
Feb 21 10:08:52 rechner systemd[1]: 
media-bernhard-CCCOMA_X64FRE_DE\x2dDE_DV9.mount: Succeeded.
Feb 21 10:08:52 rechner systemd[1]: Stopping Clean the 
/media/bernhard/CCCOMA_X64FRE_DE-DE_DV9 mount point...
Feb 21 10:08:52 rechner systemd[1]: 
clean-mount-point@media-bernhard-CCCOMA_X64FRE_DE\x2dDE_DV9.service: Succeeded.
Feb 21 10:08:52 rechner systemd[1]: Stopped Clean the 
/media/bernhard/CCCOMA_X64FRE_DE-DE_DV9 mount point.
Feb 21 10:08:52 rechner ntfs-3g[15088]: Unmounting /dev/sdc1 
(CCCOMA_X64FRE_DE-DE_DV9)
Feb 21 10:08:52 rechner udisksd[886]: Unmounted /dev/sdc1 on behalf of uid 1000
Feb 21 10:08:52 rechner udisksd[886]: g_object_ref: assertion 
'object->ref_count > 0' failed
Feb 21 10:08:52 rechner kernel: pool[15388]: segfault at 18 ip 55822b5966e2 
sp 7f458d8aa590 error 4 in udisksd[55822b579000+3c000]
Feb 21 10:08:52 rechner kernel: Code: c0 74 05 4c 39 20 74 0f 4c 89 e6 48 89 df 
e8 a5 49 fe ff 85 c0 74 c7 4c 89 e6 48 89 df e8 a6 4d fe ff 48 89 c7 e8 ce c7 
fe ff <48> 8b 78 18 49 89 c7 e8 82 3b fe ff 4c 89 f6 48 89 c7 e8 47 31 fe
Feb 21 10:08:52 rechner systemd[1]: udisks2.service: Main process exited, 
code=killed, status=11/SEGV
Feb 21 10:08:52 rechner systemd[1]: udisks2.service: Failed with result 
'signal'.
Feb 21 10:08:52 rechner dbus-daemon[852]: [system] Activating via systemd: 
service name='org.freedesktop.UDisks2' unit='udisks2.service' requested by 
':1.79' (uid=1000 pid=1296 comm="/usr/bin/plasmashell ")
Feb 21 10:08:52 rechner systemd[1]: Starting Disk Manager...
Feb 21 10:08:52 rechner udisksd[15395]: udisks daemon version 2.8.1 starting
Feb 21 10:08:52 rechner udisksd[15395]: failed to load module crypto: 
libbd_crypto.so.2: cannot open shared object file: No such file 

Bug#923013: xen: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

Hmm, I said:

> Hint: Try splitting override_dh_compress into override_dh_compress-arch
> and override_dh_compress-indep.

Not really sure that this is a good hint in this case. The first rule showing an
error is certainly this one:

find: 'debian/xen-hypervisor-*/usr/lib/debug': No such file or directory

but maybe it's override_dh_missing the one that would benefit from an 
-arch/-indep split.

Thanks.

Bug#923014: Add systemd unit - allow usage without cron installed

[Bryan Quigley]

Package: popularity-contest
Version: 1.67

This is regards to the popularity-contest cron job.  I'm looking into
running systems without anacron/cron installed - instead using systemd
timers.

My suggestion would be to remove the what to do functionality from the
cron job/timing bits to another script - say popcon-runner.

The cron job could then be something like:
# skip in favour of systemd timer (from logrotate)
if [ -d /run/systemd/system ]; then
exit 0
fi



popcon-runner

And creating a systemd timer/service for those that have systemd installed:

Timer File
/etc/systemd/system/timers.target.wants/popularity-contest.timer
[Unit]
Description=Sends popularity contest data

[Timer]
OnCalendar=daily
AccuracySec=24h  [ Can change this to be less accurate to spread
server load, etc)
Persistent=true

[Install]
WantedBy=timers.target

Service File
/usr/lib/systemd/system/popularity-contest.service
[Unit]
Description=Sends popularity contest data

[Service]
ExecStart=/path/to/popcon-runner
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7

(can easily set nice levels, IO limits)

PrivateTmp=true
PrivateDevices=true

There are a bunch of other restrictions that can be placed on it via
systemd Private directives.

Thanks!

Bug#923013: xen: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

Package: src:xen
Version: 4.11.1+26-g87f51bf366-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid with "dpkg-buildpackage -A" but it failed:


[...]
 debian/rules build-indep
dh build-indep --with=python2
   debian/rules override_dh_update_autotools_config
make[1]: Entering directory '/<>/xen-4.11.1+26-g87f51bf366'
cp /usr/share/misc/{config.sub,config.guess} .
make[1]: Leaving directory '/<>/xen-4.11.1+26-g87f51bf366'
   dh_autoreconf -i
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/xen-4.11.1+26-g87f51bf366'
cp debian/xen-kconfig xen/.config
make -C xen olddefconfig  XEN_COMPILE_ARCH=x86_64 XEN_TARGET_ARCH=x86_64 
make[2]: Entering directory '/<>/xen-4.11.1+26-g87f51bf366/xen'
make -f 
/<>/xen-4.11.1+26-g87f51bf366/xen/tools/kconfig/Makefile.kconfig 
ARCH=x86_64 SRCARCH=x86 HOSTCC="gcc" HOSTCXX="g++" olddefconfig
make[3]: Entering directory '/<>/xen-4.11.1+26-g87f51bf366/xen'

[... snipped ...]

   dh_perl -i
   dh_link -i
   dh_strip_nondeterminism -i
   debian/rules override_dh_compress
make[1]: Entering directory '/<>/xen-4.11.1+26-g87f51bf366'
rdfind -makehardlinks true -makeresultsfile false \
debian/xenstore-utils/usr/bin
Now scanning "debian/xenstore-utils/usr/bin", found 0 files.
Now have 0 files in total.
Removed 0 files due to nonunique device and inode.
Total size is 0 bytes or 0 B
Removed 0 files due to unique sizes from list.0 files left.
Now eliminating candidates based on first bytes:removed 0 files from list.0 
files left.
Now eliminating candidates based on last bytes:removed 0 files from list.0 
files left.
Now eliminating candidates based on sha1 checksum:removed 0 files from list.0 
files left.
It seems like you have 0 files that are not unique
Totally, 0 B can be reduced.
Now making hard links.
Making 0 links.
:
dh_compress
find debian/xen-hypervisor-*/usr/lib/debug -type f -print0 \
| xargs -0r gzip -9vn
find: 'debian/xen-hypervisor-*/usr/lib/debug': No such file or directory
make[1]: Leaving directory '/<>/xen-4.11.1+26-g87f51bf366'
   dh_fixperms -i
   debian/rules override_dh_missing
make[1]: Entering directory '/<>/xen-4.11.1+26-g87f51bf366'
dh_missing --fail-missing
dh_missing: etc/bash_completion.d/xl.sh exists in debian/tmp but is not 
installed to anywhere
dh_missing: missing files, aborting
The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: libxen-dev (30), libxencall1 (2), libxendevicemodel1 
(2), libxenevtchn1 (2), libxenforeignmemory1 (2), libxengnttab1 (2), 
libxenmisc4.11 (14), libxenstore3.0 (2), libxentoolcore1 (2), libxentoollog1 
(2), xen-doc (1), xen-hypervisor-4.11-amd64 (3), xen-hypervisor-4.11-arm64 (0), 
xen-hypervisor-4.11-armhf (0), xen-hypervisor-common (1), xen-system-amd64 (0), 
xen-system-arm64 (0), xen-system-armhf (0), xen-utils-4.11 (4), 
xen-utils-common (18), xenstore-utils (13)
 * dh_installdocs: libxen-dev (0), libxencall1 (0), libxendevicemodel1 
(0), libxenevtchn1 (0), libxenforeignmemory1 (0), libxengnttab1 (0), 
libxenmisc4.11 (0), libxenstore3.0 (0), libxentoolcore1 (0), libxentoollog1 
(0), xen-doc (0), xen-hypervisor-4.11-amd64 (0), xen-hypervisor-4.11-arm64 (0), 
xen-hypervisor-4.11-armhf (0), xen-hypervisor-common (0), xen-system-amd64 (0), 
xen-system-arm64 (0), xen-system-armhf (0), xen-utils-4.11 (0), 
xen-utils-common (0), xenstore-utils (0)
 * dh_installexamples: libxen-dev (0), libxencall1 (0), 
libxendevicemodel1 (0), libxenevtchn1 (0), libxenforeignmemory1 (0), 
libxengnttab1 (0), libxenmisc4.11 (0), libxenstore3.0 (0), libxentoolcore1 (0), 
libxentoollog1 (0), xen-doc (0), xen-hypervisor-4.11-amd64 (0), 
xen-hypervisor-4.11-arm64 (0), xen-hypervisor-4.11-armhf (0), 
xen-hypervisor-common (0), xen-system-amd64 (0), xen-system-arm64 (0), 
xen-system-armhf (0), xen-utils-4.11 (0), xen-utils-common (1), xenstore-utils 
(0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
For a short-term work-around: Add the files to debian/not-installed
make[1]: *** [debian/rules:316: override_dh_missing] Error 2
make[1]: Leaving directory '/<>/xen-4.11.1+26-g87f51bf366'
make: *** [debian/rules:147: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


Hint: Try splitting override_dh_compress into override_dh_compress-arch
and 

Bug#922533: please document location of accounting file

[Marcos Fouces]

On 22/2/19 16:55, Marc Haber wrote:
> I am not sure whether this was a brilliant idea, many local mechanisms
> on existing installations might be looking for the file in the old
> place. Also, migration probably needs a gazillion of tests to make sure
> that nothing breaks. For how long has the data been in /var/log/?

Hello Marc

The /var/log/account/ path was introduced by a previous maintainer in
6.3.99+6.4pre1-3 release (2006).

I can't figure out any reason for that. In fact, there were several bugs
reporting troubles caused by this change (#377835
, #380744
, #385626
, #392045
, #396444
).

Instead of reverting this change to the standard path (/var/account), he
decided to fix them setting this new path properly in all pertinent
files and it was in use it since then. AFAIK, you could define any path
you want for store log files.

Greetings,

Marcos.

Bug#897882: validns: diff for NMU version 0.8+git20160720-3.1

[Sebastian Andrzej Siewior]

Dear maintainer,

I've prepared an NMU for validns (versioned as 0.8+git20160720-3.1) and
uploaded it to DELAYED/1. Please feel free to tell me if I
should delay it longer.

Regards.
Sebastian
diff -Nru validns-0.8+git20160720/debian/changelog validns-0.8+git20160720/debian/changelog
--- validns-0.8+git20160720/debian/changelog	2016-12-14 16:01:55.0 +0100
+++ validns-0.8+git20160720/debian/changelog	2019-02-22 23:52:58.0 +0100
@@ -1,3 +1,12 @@
+validns (0.8+git20160720-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Avoid a warning regarding string truncation (Closes: #897882).
+  * Get it compiled against OpenSSL 1.1+ (Closes: #859784).
+  * Use priority optional instead of extra.
+
+ -- Sebastian Andrzej Siewior   Fri, 22 Feb 2019 23:52:58 +0100
+
 validns (0.8+git20160720-3) unstable; urgency=medium
 
   * debian/copyright Add License: statement.
diff -Nru validns-0.8+git20160720/debian/control validns-0.8+git20160720/debian/control
--- validns-0.8+git20160720/debian/control	2016-12-14 16:01:55.0 +0100
+++ validns-0.8+git20160720/debian/control	2019-02-22 23:52:58.0 +0100
@@ -1,9 +1,9 @@
 Source: validns
 Section: net
-Priority: extra
+Priority: optional
 Maintainer: Casper Gielen 
 Uploaders: Joost van Baal-Ilić 
-Build-Depends: debhelper (>= 9), libssl1.0-dev, libjudy-dev, libtest-command-simple-perl, dpkg-dev (>= 1.16.1~)
+Build-Depends: debhelper (>= 9), libssl-dev, libjudy-dev, libtest-command-simple-perl, dpkg-dev (>= 1.16.1~)
 Standards-Version: 3.9.8
 Homepage: http://www.validns.net/
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/validns.git
diff -Nru validns-0.8+git20160720/debian/patches/fix-compilation-on-openssl-1.1.patch validns-0.8+git20160720/debian/patches/fix-compilation-on-openssl-1.1.patch
--- validns-0.8+git20160720/debian/patches/fix-compilation-on-openssl-1.1.patch	1970-01-01 01:00:00.0 +0100
+++ validns-0.8+git20160720/debian/patches/fix-compilation-on-openssl-1.1.patch	2019-02-22 23:50:11.0 +0100
@@ -0,0 +1,248 @@
+From: Author: "Chris West (Faux)" 
+Date: Fri, 22 Feb 2019 23:39:34 +0100
+Subject: [PATCH] fix compilation on openssl 1.1
+
+BTS: https://bugs.debian.org/859784
+bigeasy: drop locking, check for OOM during allocation.
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ dnskey.c  |  9 +--
+ nsec3checks.c | 29 +-
+ rrsig.c   | 69 ++-
+ 3 files changed, 42 insertions(+), 65 deletions(-)
+
+diff --git a/dnskey.c b/dnskey.c
+index fecc62abfd21..fda220c14d08 100644
+--- a/dnskey.c
 b/dnskey.c
+@@ -154,6 +154,7 @@ int dnskey_build_pkey(struct rr_dnskey *rr)
+ 		unsigned int e_bytes;
+ 		unsigned char *pk;
+ 		int l;
++		BIGNUM *n, *e;
+ 
+ 		rsa = RSA_new();
+ 		if (!rsa)
+@@ -174,11 +175,15 @@ int dnskey_build_pkey(struct rr_dnskey *rr)
+ 		if (l < e_bytes) /* public key is too short */
+ 			goto done;
+ 
+-		rsa->e = BN_bin2bn(pk, e_bytes, NULL);
++		e = BN_bin2bn(pk, e_bytes, NULL);
+ 		pk += e_bytes;
+ 		l -= e_bytes;
+ 
+-		rsa->n = BN_bin2bn(pk, l, NULL);
++		n = BN_bin2bn(pk, l, NULL);
++		if (!e || !n)
++			goto done;
++
++		RSA_set0_key(rsa, n, e, NULL);
+ 
+ 		pkey = EVP_PKEY_new();
+ 		if (!pkey)
+diff --git a/nsec3checks.c b/nsec3checks.c
+index 69c655345bad..2abac9efa1bf 100644
+--- a/nsec3checks.c
 b/nsec3checks.c
+@@ -28,7 +28,7 @@
+ static struct binary_data name2hash(char *name, struct rr *param)
+ {
+ struct rr_nsec3param *p = (struct rr_nsec3param *)param;
+-	EVP_MD_CTX ctx;
++	EVP_MD_CTX *ctx;
+ 	unsigned char md0[EVP_MAX_MD_SIZE];
+ 	unsigned char md1[EVP_MAX_MD_SIZE];
+ 	unsigned char *md[2];
+@@ -45,26 +45,31 @@ static struct binary_data name2hash(char *name, struct rr *param)
+ 
+ 	/* XXX Maybe use Init_ex and Final_ex for speed? */
+ 
+-	EVP_MD_CTX_init();
+-	if (EVP_DigestInit(, EVP_sha1()) != 1)
++	ctx = EVP_MD_CTX_new();
++	if (ctx == NULL)
+ 		return r;
+-	digest_size = EVP_MD_CTX_size();
+-	EVP_DigestUpdate(, wire_name.data, wire_name.length);
+-	EVP_DigestUpdate(, p->salt.data, p->salt.length);
+-	EVP_DigestFinal(, md[mdi], NULL);
++	if (EVP_DigestInit(ctx, EVP_sha1()) != 1)
++		goto out;
++	digest_size = EVP_MD_CTX_size(ctx);
++	EVP_DigestUpdate(ctx, wire_name.data, wire_name.length);
++	EVP_DigestUpdate(ctx, p->salt.data, p->salt.length);
++	EVP_DigestFinal(ctx, md[mdi], NULL);
+ 
+ 	for (i = 0; i < p->iterations; i++) {
+-		if (EVP_DigestInit(, EVP_sha1()) != 1)
+-			return r;
+-		EVP_DigestUpdate(, md[mdi], digest_size);
++		if (EVP_DigestInit(ctx, EVP_sha1()) != 1)
++			goto out;
++
++		EVP_DigestUpdate(ctx, md[mdi], digest_size);
+ 		mdi = (mdi + 1) % 2;
+-		EVP_DigestUpdate(, p->salt.data, p->salt.length);
+-		EVP_DigestFinal(, md[mdi], NULL);
++		EVP_DigestUpdate(ctx, p->salt.data, p->salt.length);
++		EVP_DigestFinal(ctx, md[mdi], NULL);
+ 	}
+ 
+ 	r.length = digest_size;
+ 	r.data = getmem(digest_size);
+ 	memcpy(r.data, md[mdi], digest_size);
++out:
++	

Bug#882993: Fedora also has one, not upstream from what I can see.

[Bryan Quigley]

Fedora also has one, not upstream from what I can see.  This also doe more
restrictions on what it can see.

/usr/lib/systemd/system/mlocate-updatedb.service
[Unit]
Description=Update a database for mlocate

[Service]
ExecStart=/usr/libexec/mlocate-run-updatedb
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7

PrivateTmp=true
PrivateDevices=true
PrivateNetwork=true
ProtectSystem=true


/etc/systemd/system/timers.target.wants/mlocate-updatedb.timer
[Unit]
Description=Updates mlocate database every day

[Timer]
OnCalendar=daily
AccuracySec=24h
Persistent=true

[Install]


The last bit would be to take the cronjob line from logrotate (if you want
compatibility from systems without system):
# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
exit 0
fi

Bug#819490: debmirror: SHA256 validating of debian-installer files

[Bastian Germann]

Package: debmirror

Please have a look at
https://salsa.debian.org/debian/debmirror/merge_requests/4
for a fix of this issue.

Bug#923011: nuxwdog: FTBFS (/usr/include/keyutils.h:204:48: error: expected ',' or '...' before 'private')

[Santiago Vila]

Package: src:nuxwdog
Version: 1.0.5-2
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-arch
dh build-arch  --no-parallel --with javahelper
   dh_update_autotools_config -a
   dh_autoreconf -a
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
configure.ac:59: installing './compile'
configure.ac:52: installing './missing'
Makefile.am: installing './depcomp'
   jh_linkjars -a
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
mkdir stash
cp lib/perl/Nuxwdogclient/*.inc stash
dh_auto_build -- -Dproduct.ui.flavor.prefix="" -Dproduct.prefix="" 
-Dproduct="nuxwdog" -Dversion="1.0.5"
ant -Duser.name debian -Dproduct.ui.flavor.prefix= -Dproduct.prefix= 
-Dproduct=nuxwdog -Dversion=1.0.5
Buildfile: /<>/build.xml

clean:
 [echo] Removing 'nuxwdog' component directories ...
 [echo] Completed removing 'nuxwdog' component directories.

clean_javadocs:
 [echo] Removing 'nuxwdog' javadocs directory ...
 [echo] Nothing to do!
 [echo] Completed removing 'nuxwdog' javadocs directory.

compile_java:
 [echo] Compiling 'nuxwdog' java code from 'src' into 'build/classes' ...
[mkdir] Created dir: /<>/build/classes
[javac] /<>/build.xml:59: warning: 'includeantruntime' was not 
set, defaulting to build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 1 source file to /<>/build/classes
 [echo] Completed compiling 'nuxwdog' java code from 'src' into 
'build/classes'.

build_jars:
 [echo] Generating 'nuxwdog' jar files ...
[mkdir] Created dir: /<>/build/jars
  [jar] Building jar: /<>/build/jars/nuxwdog.jar
 [echo] Completed generating 'nuxwdog' jar files.

build_jni_headers:
 [echo] Generating 'nuxwdog' java header files ...
[mkdir] Created dir: /<>/build/include
 [echo] Completed generating 'nuxwdog' java header files.

build_header_files:
 [echo] ${begin.build.headers.log.message}
[mkdir] Created dir: /<>/build/usr/include
 [copy] Copying 2 files to /<>/build/usr/include

build:
 [echo] Built classes, jars, and jni headers for the 'nuxwdog' component.

compose_javadocs:
 [echo] Composing 'nuxwdog' javadocs ...
 [echo] Nothing to do!
 [echo] Completed composing 'nuxwdog' javadocs.

document:
 [echo] Documented 'nuxwdog' javadocs.

distribute_binaries:
 [echo] Creating 'nuxwdog' binary distributions ...
[mkdir] Created dir: /<>/dist/binary
 [echo] Creating 'nuxwdog' binary wrappers ...
 [echo] Nothing to do!
 [echo] Completed creating 'nuxwdog' binary wrappers.
 [echo] Creating 'nuxwdog' binary zip files ...
  [zip] Building zip: /<>/dist/binary/nuxwdog-1.0.5.zip
 [echo] Completed creating 'nuxwdog' binary zip files.
 [echo] Creating 'nuxwdog' binary tar files ...
  [tar] Building tar: /<>/dist/binary/nuxwdog-1.0.5.tar
 [echo] Completed creating 'nuxwdog' binary tar files.
 [echo] Creating 'nuxwdog' binary gzip files ...
 [gzip] Building: /<>/dist/binary/nuxwdog-1.0.5.tar.gz
   [delete] Deleting: /<>/dist/binary/nuxwdog-1.0.5.tar
 [echo] Completed creating 'nuxwdog' binary gzip files.
 [echo] Completed creating 'nuxwdog' binary distributions.

distribute_source:
 [echo] Creating 'nuxwdog' source distributions ...
[mkdir] Created dir: /<>/dist/source
 [echo] Creating 'nuxwdog' source zip files ...
  [zip] Building zip: /<>/dist/source/nuxwdog-1.0.5.zip
 [echo] Completed creating 'nuxwdog' source zip files.
 [echo] Creating 'nuxwdog' source tar files ...
  [tar] Building tar: /<>/dist/source/nuxwdog-1.0.5.tar
 [echo] Completed creating 'nuxwdog' source tar files.
 [echo] Creating 'nuxwdog' source gzip files ...
 [gzip] Building: /<>/dist/source/nuxwdog-1.0.5.tar.gz
   [delete] Deleting: /<>/dist/source/nuxwdog-1.0.5.tar
 [echo] Completed creating 'nuxwdog' source gzip files.
 [echo] Completed creating 'nuxwdog' source distributions.

distribute:
 [echo] Distributed 'nuxwdog' distribution packages.

main:
 [echo] Built, verified, documented, and distributed a fresh 'nuxwdog' 
component.

BUILD SUCCESSFUL
Total time: 9 seconds
# run this here 
dh_auto_configure -- \
 --enable-64bit
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info 

Bug#923010: fauhdlc: FTBFS (FAUhdlParser.yy:13.9-27: error: syntax error, unexpected string, expecting identifier)

[Santiago Vila]

Package: src:fauhdlc
Version: 20180504-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-arch
./autogen.sh
configure.ac:8: installing 'scripts/compile'
configure.ac:6: installing 'scripts/install-sh'
configure.ac:6: installing 'scripts/missing'
Makefile.am: installing './INSTALL'
Makefile.am:17: warning: source file 'frontend/ast/NodeFactory.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding 
output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same 
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
Makefile.am:17: warning: source file 'frontend/ast/Location.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/AstNode.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/AttributableDeclaration.cpp' 
is in a subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/AttributeDeclaration.cpp' is 
in a subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/AttributeSpecification.cpp' 
is in a subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/Name.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/PhysicalType.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/SubtypeIndication.cpp' is in 
a subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/RecordType.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/Types.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/ConstInteger.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/DiscreteRange.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/Expression.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/SimpleName.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/SymbolDeclaration.cpp' is in 
a subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/ast/ValDeclaration.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/misc/Driver.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/misc/DeclarativeRegion.cpp' is 
in a subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/misc/Symbol.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/misc/SymbolTable.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/misc/BuiltinSymbolTable.cpp' is 
in a subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/misc/NameLookup.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/misc/RegisterBuiltins.cpp' is in 
a subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/misc/RangeSet.cpp' is in a 
subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 'frontend/reporting/AmbiguousTypes.cpp' is 
in a subdirectory,
Makefile.am:17: but option 'subdir-objects' is disabled
Makefile.am:17: warning: source file 

Bug#923012: squirrel3: FTBFS (Could not import extension sphinx.ext.pngmath)

[Santiago Vila]

Package: src:squirrel3
Version: 3.1-5
Severity: serious
Tags: ftbfs

Dear maintainer:

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
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure --buildsystem=cmake -- \
-DINSTALL_LIB_DIR=lib/x86_64-linux-gnu \
-DINSTALL_INC_DIR=include/squirrel3 \
-DDISABLE_STATIC="" -DLONG_OUTPUT_NAMES=""
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DINSTALL_LIB_DIR=lib/x86_64-linux-gnu -DINSTALL_INC_DIR=include/squirrel3 
-DDISABLE_STATIC= -DLONG_OUTPUT_NAMES= ..
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

CMAKE_EXPORT_NO_PACKAGE_REGISTRY
CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY
CMAKE_INSTALL_LIBDIR
CMAKE_INSTALL_LOCALSTATEDIR
CMAKE_INSTALL_SYSCONFDIR
DISABLE_STATIC
LONG_OUTPUT_NAMES


-- Build files have been written to: /<>/obj-x86_64-linux-gnu
make[1]: Leaving directory '/<>'
   dh_auto_build -a
cd obj-x86_64-linux-gnu && make -j1
make[1]: Entering directory '/<>/obj-x86_64-linux-gnu'
/usr/bin/cmake -S/<> -B/<>/obj-x86_64-linux-gnu 
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start 
/<>/obj-x86_64-linux-gnu/CMakeFiles 
/<>/obj-x86_64-linux-gnu/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[2]: Entering directory '/<>/obj-x86_64-linux-gnu'
make -f squirrel/CMakeFiles/squirrel.dir/build.make 
squirrel/CMakeFiles/squirrel.dir/depend
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends 
"Unix Makefiles" /<> /<>/squirrel 
/<>/obj-x86_64-linux-gnu 
/<>/obj-x86_64-linux-gnu/squirrel 
/<>/obj-x86_64-linux-gnu/squirrel/CMakeFiles/squirrel.dir/DependInfo.cmake
 --color=
Scanning dependencies of target squirrel
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make -f squirrel/CMakeFiles/squirrel.dir/build.make 
squirrel/CMakeFiles/squirrel.dir/build
make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
[  4%] Building CXX object squirrel/CMakeFiles/squirrel.dir/sqapi.cpp.o
cd /<>/obj-x86_64-linux-gnu/squirrel && /usr/bin/c++  -D_SQ64 
-Dsquirrel_EXPORTS -I/<>/include  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -pedantic -fno-exceptions -fno-strict-aliasing 
-fno-rtti -std=c++11 -Wdate-time -D_FORTIFY_SOURCE=2 -fno-rtti -std=c++0x -fPIC 
  -fno-exceptions -fno-strict-aliasing -Wall -Wextra -pedantic -Wcast-qual -o 
CMakeFiles/squirrel.dir/sqapi.cpp.o -c /<>/squirrel/sqapi.cpp
/<>/squirrel/sqapi.cpp: In function 'SQRESULT 
sq_setdelegate(HSQUIRRELVM, SQInteger)':
/<>/squirrel/sqapi.cpp:961:13: warning: this 'if' clause does not 
guard... [-Wmisleading-indentation]
 if(!_table(self)->SetDelegate(_table(mt))) return sq_throwerror(v, 
_SC("delagate cycle")); v->Pop();}
 ^~
/<>/squirrel/sqapi.cpp:961:104: note: ...this statement, but the 
latter is misleadingly indented as if it were guarded by the 'if'
 if(!_table(self)->SetDelegate(_table(mt))) return sq_throwerror(v, 
_SC("delagate cycle")); v->Pop();}

^
In file included from /<>/squirrel/sqobject.h:5,
 from /<>/squirrel/sqpcheader.h:17,
 from /<>/squirrel/sqapi.cpp:4:
/<>/squirrel/squtils.h: In instantiation of 'void 
sqvector::remove(SQUnsignedInteger) [with T = SQObjectPtr; SQUnsignedInteger 
= long long unsigned int]':
/<>/squirrel/sqarray.h:83:27:   required from here
/<>/squirrel/squtils.h:97:20: warning: 'void* memmove(void*, const 
void*, size_t)' writing to an object of type 'struct SQObjectPtr' with no 
trivial copy-assignment; use copy-assignment or copy-initialization instead 
[-Wclass-memaccess]
 memmove(&_vals[idx], &_vals[idx+1], sizeof(T) * 

Bug#911133: Multiple console support in d-i

[Wookey]

OK. Steve stayed up very late last night checking that this worked OK
on x86 and adding some useful logging (allowing for the fact that it
needs to work before syslog is actually started).

We've checked some more stuff today, including testing the matching
finish-install functionality on full installs, and reverting my fancy
inittab seddery to go back to simply appending which is more reliable
and easier to understand. We are now confident that the 'use init'
version is the superior (cleaner and more reliable) approach. 

That's all merged in the attached patches which we reckon are now
ready for general use.

I will do some more testing (to check I've not broken hurd - bsd
doesn't seem to be built at the moment so there is nothing to break),
and of course we are ready to prod it some more if we find this does
actually cause unhelpful behaviour for anyone. I also need to check
the docs which no doubt need a few updates.

I've found a couple of other things whilst poking about in the D-I
entrails. There is plenty of cruft from older ways of doing things,
which of course tends to get ignored if it's not actually breaking
things, largely due to chronic undermanning in D-I land. I'll file
some bugs and patches. None of it is urgent, but worth noting before I
forget.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
diff --git b/debian/changelog a/debian/changelog
index a7c80c3..e23b91e 100644
--- b/debian/changelog
+++ a/debian/changelog
@@ -7,7 +7,11 @@ rootskel (1.127) UNRELEASED; urgency=medium
   [ Holger Wansing ]
   * Remove trailing whitespaces from changelog file, to fix lintian tag.
 
- -- Samuel Thibault   Fri, 08 Feb 2019 01:50:37 +0200
+  [ Wookey ]
+  * Support multiple consoles - Run D-I on all enabled consoles
+  * Rename reopen-console to choose-consoles
+
+ -- Wookey   Fri, 22 Feb 2019 15:57:39 +
 
 rootskel (1.126) unstable; urgency=medium
 
diff --git b/src/etc/inittab-hurd a/src/etc/inittab-hurd
index a7b8a23..eeff7e2 100644
--- b/src/etc/inittab-hurd
+++ a/src/etc/inittab-hurd
@@ -2,10 +2,9 @@
 # busybox init configuration for debian-installer
 
 # main rc script
-::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
+::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup
 
 # main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
 
 # convenience shells
 tty2::askfirst:-/bin/sh
diff --git b/src/etc/inittab-kfreebsd a/src/etc/inittab-kfreebsd
index 748f19b..c328548 100644
--- b/src/etc/inittab-kfreebsd
+++ a/src/etc/inittab-kfreebsd
@@ -2,10 +2,9 @@
 # busybox init configuration for debian-installer
 
 # main rc script
-::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
+::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup
 
 # main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
 
 # convenience shells
 ttyv1::askfirst:-/bin/sh
diff --git b/src/etc/inittab-linux a/src/etc/inittab-linux
index a7b8a23..d7136e2 100644
--- b/src/etc/inittab-linux
+++ a/src/etc/inittab-linux
@@ -2,10 +2,7 @@
 # busybox init configuration for debian-installer
 
 # main rc script
-::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
-
-# main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
+::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup
 
 # convenience shells
 tty2::askfirst:-/bin/sh
@@ -19,3 +16,6 @@ tty4::respawn:/usr/bin/tail -f /var/log/syslog
 
 # re-exec init on receipt of SIGHUP/SIGUSR1
 ::restart:/sbin/init
+
+# main setup program
+# Entries will be added here as the system starts up
diff --git b/src/sbin/Makefile a/src/sbin/Makefile
index dec554e..f1a4f5f 100644
--- b/src/sbin/Makefile
+++ a/src/sbin/Makefile
@@ -8,7 +8,7 @@ files_exec = \
 	debian-installer-startup \
 	shutdown \
 	init:init-$(DEB_HOST_ARCH_OS) \
-	reopen-console:reopen-console-$(DEB_HOST_ARCH_OS) \
+	choose-consoles:choose-consoles-$(DEB_HOST_ARCH_OS) \
 	steal-ctty
 
 ifeq ($(DEB_HOST_ARCH_OS),linux)
diff --git b/src/sbin/reopen-console-hurd a/src/sbin/choose-consoles-hurd
similarity index 61%
rename from src/sbin/reopen-console-hurd
rename to src/sbin/choose-consoles-hurd
index 7f9b54e..bef2b73 100755
--- b/src/sbin/reopen-console-hurd
+++ a/src/sbin/choose-consoles-hurd
@@ -4,9 +4,9 @@
 # corresponding to the console we are actually using.
 
 console=
-if ! [ -f /var/run/console-device ]; then
-	tty > /var/run/console-device
+if ! [ -f /var/run/console-devices ]; then
+	tty > /var/run/console-devices
 fi
 
 # Some other session may have it as ctty. Steal it from them
-exec /sbin/steal-ctty $(cat /var/run/console-device) "$@"
+exec /sbin/steal-ctty $(cat /var/run/console-devices) "$@"
diff --git b/src/sbin/reopen-console-kfreebsd a/src/sbin/choose-consoles-kfreebsd
similarity index 87%
rename from src/sbin/reopen-console-kfreebsd
rename to src/sbin/choose-consoles-kfreebsd
index 6dec149..2dd292a 100755
--- b/src/sbin/reopen-console-kfreebsd
+++ 

Bug#923009: seafile: CVE-2013-7469

[Salvatore Bonaccorso]

Source: seafile
Version: 6.2.11-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/haiwen/seafile/issues/350

Hi,

The following vulnerability was published for seafile.

CVE-2013-7469[0]:
| Seafile through 6.2.11 always uses the same Initialization Vector (IV)
| with Cipher Block Chaining (CBC) Mode to encrypt private data, making
| it easier to conduct chosen-plaintext attacks or dictionary attacks.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2013-7469
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7469
[1] https://github.com/haiwen/seafile/issues/350

Regards,
Salvatore

Bug#921598: fixed in simgear 1:2018.3.2+dfsg-5

[Gabriel F. T. Gomes]

On Wed, 20 Feb 2019 00:53:18 -0300 "Gabriel F. T. Gomes" 
 wrote:
>
> I tested that rebuilding flightgear with this dependency updated solves
> the METAR problem.  Do you plan to upload a new binary version of
> flightgear, too?  (I'm asking because the flightgear package currently
> on the archives still has the problem (probably because it needs to be
> rebuilt - should a rebuild happen automatically?)).

I learned about binNMUs (thanks tarpman@OFTC) and I learned that such
rebuilds are not automatically triggered, but must be manually request
via a bug report against the release.debian.org package.

I have created such request as https://bugs.debian.org/923005

I think I got it right, but I'll check once the build is done and if
you could also check that it fixes the problem for yourselves, that
would be good.

Thanks,
Gabriel

Bug#923008: CVE-2018-16886

[Moritz Muehlenhoff]

Source: etcd
Severity: grave
Tags: security

Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16886  and
https://security-tracker.debian.org/tracker/CVE-2018-16886

Cheers,
Moritz

Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Handle transition from MAT to MAT2

[Jonas Meurer]

jvoisin:
>> On 19-02-12 14:39:32, Georg Faerber wrote:
>>> That is: option one of the second proposal ("quickly patch together a
>>> Python 2 Nautilus extension that wraps mat2's CLI").
>>
>> Unfortunately, and sorry again for my delay working on this, there was
>> no feedback. I've poked Jonas today on IRC privately, asking if he had a
>> comment, he said "sounds good, go ahead", and so I did.
> Ouch, this is unexpected and sounds like a hack, but I guess this is the
> only way to get a useable Mat2 into Buster before the hard freeze.
> 
> I took a look at your patch, and improved it a bit. Improved as in tried
> to reduce the number of modifications, and made it more Pythonic.
> 
> I'm not super-duper-confident that this approach won't result in some
> weird issues, but again, I guess it's better than nothing.
> 
> Thank you for taking the time to write this patch and taking care of
> mat2 in Debian ♥

Thanks a ton for working on this, Georg and Julien! Thanks to you,
there's still hope to have a working mat2 nautilus extension in Buster.

I skimmed through the patch and it looks good to me. I also did some
rough testing and at least with my test files it worked as expected.

I merged jvoisin's changes into the d/0.7.0-2 branch.

So from my side, 0.7.0-2 is ready to be uploaded.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#921156: etcd: CVE-2018-1098 CVE-2018-1099

[Moritz Mühlenhoff]

severity 921156 important
thanks

On Tue, Feb 19, 2019 at 11:24:47PM -0600, Stephen Gelman wrote:
> On Tue, 12 Feb 2019 09:32:48 +0700 Arnaud Rebillout
>  wrote:
> > I looked into this a bit yesterday.
> >
> > As mentioned in the issue upstream at
> > https://github.com/etcd-io/etcd/issues/9353, the fix has been merged in
> > the master branch of etcd in March 2018, almost a year ago. The
> > conversation also mentions that this will be part of the next release
> > v3.4. However v3.4 has not been released yet.
> >
> > And I don't think we want to package a random commit from the master
> > branch of etcd. So if we want to solve this bug simply by updating the
> > package, we'll have to wait for v3.4 to be released.
> >
> > The other alternative is to cherry-pick the patch.
> >
> > If I'm not mistaken, the fix can be found in this MR:
> > https://github.com/etcd-io/etcd/pull/9372/files. It's not a trivial
> > patch. It's unlikely that we can apply it without modification on the
> > etcd currently packaged in debian.
> >
> > I personally can't do that, as I know nothing about etcd anyway. I don't
> > know if someone feels up to the task, or have a better idea about how to
> > solve that.
> >
> > Cheers,
> >
> >   Arnaud
> 
> Since upstream still hasn't released a version that fixes the CVE is
> this still considered a RC bug?  Obviously it's better to fix it asap
> but if upstream doesn't consider it critical I'm not sure this should
> be RC.

Let's downgrade and revisit when a fix has been backported to a 3.2.x
release.

Cheers,
Moritz

Bug#923007: fusiondirectory: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: fusiondirectory
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#923005: nmu: flightgear 1:2018.3.2+dfsg-2

[Gabriel F. T. Gomes]

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

nmu: flightgear_1:2018.3.2+dfsg-2 . ANY . unstable . -m "rebuild against 
libsimgear-dev 1:2018.3.2+dfsg-5"

Fetching of 'live weather' data was broken on flightgear, as reported in
https://bugs.debian.org/921598#5.  The fix is not in flightgear itself,
but in libsimgear-dev, which flightgear build-depends upon.  Recently,
libsimgear-dev was updated (with the fix) on the archive, and now
flightgear needs to be rebuilt for the fix to be effective to users.

I have manually built flightgear with the updated libsimgear-dev, on
x86_64, and I confirm that it actually fixes the problem.

Thanks,
Gabriel

Bug#923006: prometheus: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: prometheus
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#923004: minissdpd: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: minissdpd
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#923003: CVE-2018-19873 CVE-2018-19871 CVE-2018-19870

[Moritz Muehlenhoff]

Source: qt4-x11
Severity: grave
Tags: security

Three security issues fixed in QT5 also affect qt4-x11:
https://blog.qt.io/blog/2018/12/04/qt-5-11-3-released-important-security-updates/

CVE-2018-19873:
https://github.com/qt/qtbase/commit/621ab8ab59901cc3f9bd98be709929c9eac997a8

CVE-2018-19871:
https://github.com/qt/qtimageformats/commit/7cfe47a8fe2f987fb2a066a696fb3d9d0afe4d65
(qt4-x11 affected in src/plugins/imageformats/tga/qtgafile.cpp)

CVE-2018-19870:
https://github.com/qt/qtbase/commit/2841e2b61e32f26900bde987d469c8b97ea31999
(qt4-x11 affected in src/gui/image/qgifhandler.cpp)

Cheers,
Moritz

Bug#916902: pspp: CVE-2018-20230

[Ben Pfaff]

On Fri, Feb 22, 2019 at 10:57:20PM +0100, Moritz Mühlenhoff wrote:
> On Wed, Dec 19, 2018 at 10:07:59PM -0800, Ben Pfaff wrote:
> > On Thu, Dec 20, 2018 at 06:22:14AM +0100, Salvatore Bonaccorso wrote:
> > > Source: pspp
> > > Version: 1.2.0-2
> > > Severity: important
> > > Tags: security upstream
> > > 
> > > Hi,
> > > 
> > > The following vulnerability was published for pspp.
> > > 
> > > CVE-2018-20230[0]:
> > > | An issue was discovered in PSPP 1.2.0. There is a heap-based buffer
> > > | overflow at the function read_bytes_internal in
> > > | utilities/pspp-dump-sav.c, which allows attackers to cause a denial of
> > > | service (application crash) or possibly have unspecified other impact.
> > 
> > This is another instance of a recurring problem with PSPP, in which some
> > anonymous person reports a vulnerability to MITRE, but not to the
> > upstream authors or the pspp-security list, and so the authors only hear
> > about it when Red Hat and Debian file bugs based on it.  It makes me
> > really mad.
> 
> Regardless of the questionable reporting done here, do you know if this
> bug has been addressed/reported upstream?

Yes, I fixed it upstream with commit abd1f816ca3b ("pspp-dump-sav: Issue
error message for too-large extension records.") on January 1.

Bug#916902: pspp: CVE-2018-20230

[Moritz Mühlenhoff]

On Wed, Dec 19, 2018 at 10:07:59PM -0800, Ben Pfaff wrote:
> On Thu, Dec 20, 2018 at 06:22:14AM +0100, Salvatore Bonaccorso wrote:
> > Source: pspp
> > Version: 1.2.0-2
> > Severity: important
> > Tags: security upstream
> > 
> > Hi,
> > 
> > The following vulnerability was published for pspp.
> > 
> > CVE-2018-20230[0]:
> > | An issue was discovered in PSPP 1.2.0. There is a heap-based buffer
> > | overflow at the function read_bytes_internal in
> > | utilities/pspp-dump-sav.c, which allows attackers to cause a denial of
> > | service (application crash) or possibly have unspecified other impact.
> 
> This is another instance of a recurring problem with PSPP, in which some
> anonymous person reports a vulnerability to MITRE, but not to the
> upstream authors or the pspp-security list, and so the authors only hear
> about it when Red Hat and Debian file bugs based on it.  It makes me
> really mad.

Regardless of the questionable reporting done here, do you know if this
bug has been addressed/reported upstream?

Cheers,
Moritz

Bug#923002: CVE-2018-20532 CVE-2018-20533 CVE-2018-20534

[Moritz Muehlenhoff]

Source: libsolv
Severity: important
Tags: security

See Security tracker.

All three fixed by 
https://github.com/openSUSE/libsolv/commit/4830af9d979d3685de538b80fbeba51ad590525e

It would be great if that were fixed in time for buster.

Cheers,
Moritz

Bug#917812: gnome-software: update broke gnome software

[Andrew Hayzen]

Any information which helps the packagekitd developers resolve the bug
( https://github.com/hughsie/PackageKit/issues/314 ) is useful :-)

Unfortunately when I run packagekitd under gdb and then start gnome-
software it results in a different crash, so the trace I attached
wasn't useful. I've also been unsuccessful in using things such as
systemd-coredump to try and capture the crash.

On Tue, 2019-02-19 at 21:36 +0800, Nathaniel Roach wrote:
> Hi Andrew,
> 
> I'm able to reproduce the issue fairly easily, my steps above don't
> seem
> to work too well. I'm more than happy to attach strace or do any
> other
> steps you'd like me to try while reproducing the issue, just let me
> know.
> 
> Cheers.
> 
> On 19/2/19 5:30 am, Andrew Hayzen wrote:
> > FYI, I've been discussing this issue with upstream gnome-software 
> > https://gitlab.gnome.org/GNOME/gnome-software/issues/589 and
> > packagekit https://github.com/hughsie/PackageKit/issues/314 .
> > 
> > I've not been able to capture a trace of packagekit crashing yet,
> > so
> > any additional info would be appreciated.
> > 

Bug#859135: CVE-2016-10127: XXE attack via crafted SAML XML request or response

[Salvatore Bonaccorso]

The CVE and fix association here was wrong way around. CVE-2016-10127
is yet still unresolved and as explained in the references that would
require a prerequisite fix in libxml2 first before fixable in
python-pysaml2.

Bug#919975: [Pkg-mailman-hackers] Bug#919975: mailman3-web: whoosh python2 and python3 databases are not compatible

[Jonas Meurer]

Pierre-Elliott Bécue:
> Le lundi 21 janvier 2019 à 08:08:16+, Sampo Sorsa a écrit :
>> Package: mailman3-web
>> Version: 0+20180916-2~bpo9+1
>>
>> Dear Maintainer,
>>
>> After upgrading from earlier python2-based packages, I ran into this problem 
>> of Whoosh databases between python2 and python3 being incompatible:
>>
>> $ sudo -u www-data /usr/share/mailman3-web/manage.py update_index_one_list 
>> exam...@example.com
>>
>> Indexing XXX emails
>> Exception in thread Thread-1:
>> Traceback (most recent call last):
>>  [traceback]
>>
>> The solution is to remove /var/lib/mailman3/web/fulltext_index/ and run:
>>
>> $ sudo -u www-data /usr/share/mailman3-web/manage.py rebuild_index
>>
>> This is mostly FYI for other stretch-backports users. As mailman3-web is not 
>> in stretch, it's probably not worth it to bother handling this when 
>> upgrading packages.
> 
> Dear Sampo,
> 
> Thanks for the report.
> 
> I agree it's not worth a big trouble, but still, this would be a nice thing
> to advertise our end users even in backports. When I met the issue myself, I
> found out the workaround, and I thought about a way to advertise end users.
> 
> I'll release something this evening.

I don't think it's worth the trouble anymore. The python3 django
packages have been in buster and stretch-backports for a while now, and
probably nobody will ever run into this again.

Would you agree with closing this bugreport, Sampo and PEB?

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#922999: aptitude: Aptitude doesn't display package descriptions on arm64

[Daniel Haude]

Additional information: /usr/share/aptitude/aptitude-defaults are the
same on both systems.

Bug#923001: error message on start

[W. Martin Borgert]

Package: chromium
Version: 72.0.3626.109-1

When I start chromium as a newly added user (no chromium config
is present in $HOME) I get a warning dialog:

> Failed to load extension from: . Manifest file
> is missing or unreadable
> OK

The warning disappears after around 1 s. I'm not aware of any
further problems related to the warning, but it is confusing
and annoying, esp. to less "technical" users, who fear their
whole system is broken.

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

Locale: LANG=en_DK.utf8, LC_CTYPE=en_DK.utf8 (charmap=UTF-8), 
LANGUAGE=en_DK.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common  72.0.3626.109-1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.30.0-4
ii  libatk1.0-0  2.30.0-2
ii  libatomic1   8.2.0-20
ii  libatspi2.0-02.30.0-7
ii  libavcodec58 7:4.1-1
ii  libavformat587:4.1-1
ii  libavutil56  7:4.1-1
ii  libc62.28-7
ii  libcairo-gobject21.16.0-2
ii  libcairo21.16.0-2
ii  libcups2 2.2.10-3
ii  libdbus-1-3  1.12.12-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.2.0-20
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.3-1
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.1-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.42-1
ii  libopenjp2-7 2.3.0-1.1
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpci3  1:3.5.2-1
ii  libpng16-16  1.6.36-5
ii  libpulse012.2-3
ii  libre2-5 20190101+dfsg-2
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.2.0-20
ii  libva2   2.4.0-1
ii  libvpx5  1.7.0-3
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  72.0.3626.53-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox 72.0.3626.53-1
ii  fonts-liberation 1:1.07.4-9
ii  gnome-shell [notification-daemon]3.30.1-2
ii  libgl1-mesa-dri  18.3.2-1
ii  libu2f-udev  1.1.7-1
ii  notification-daemon  3.20.0-4
ii  upower   0.99.9-3
ii  xfce4-notifyd [notification-daemon]  0.4.3-1

Versions of packages chromium-sandbox depends on:
ii  libatomic1  8.2.0-20
ii  libc6   2.28-7
ii  libgcc1 1:8.2.0-20
ii  libstdc++6  8.2.0-20

-- no debconf information

Bug#922998: python-sqlalchemy: (armhf) Can't load plugin: sqlalchemy.dialects:mysql

[Daniel Haude]

Hello dear maintainer,

sorry to bother you. It was my fault. Due to some trouble with a
misconfigured mysql installation that wouldn't purge and reinstall I
ended up deleting everything in my system that had the name "mysql" in
it. After successfully re-installing all mysql-related packages I
hadn't noticed that sqlalchemy had a file mysql-soundso as well. After
reinstallation of sqlalchemy all is fine.

Please close the bug.

Best regards, boblatest

On Fri, 22 Feb 2019 21:41:04 +0100
Robert Latest  wrote:

> Package: python-sqlalchemy
> Version: 1.0.15+ds1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I'm using several installations of sqlalchemy on Intel 32 and 64 bit
> platforms (both Debian and RedHat). But I found it impossible to
> transfer my application from i386 to arm64 because of this error.
> 
> This line:
> 
> engine = create_engine('mysql://localhost/sql13503')
> 
> raises this exception:
> 
> NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:mysql
> 
> 
> -- System Information:
> Debian Release: 9.8
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: arm64 (aarch64)
> Foreign Architectures: armhf
> 
> Kernel: Linux 4.4.174-rockchip64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked
> to /bin/dash Init: systemd (via /run/systemd/system)
> 
> Versions of packages python-sqlalchemy depends on:
> ii  python  2.7.13-2
> 
> Versions of packages python-sqlalchemy recommends:
> ii  python-sqlalchemy-ext  1.0.15+ds1-1
> 
> Versions of packages python-sqlalchemy suggests:
> ii  python 2.7.13-2
> pn  python-fdb 
> ii  python-mysqldb 1.3.7-1.1
> pn  python-psycopg2
> pn  python-pymssql 
> pn  python-sqlalchemy-doc  
> 
> -- no debconf information

Bug#880554: [Pkg-xen-devel] Bug#880554: #880554: max grant frames problem

[Hans van Kranenburg]

Hi,

Our Buster TODO [1] has a TODO item for me about adding a paragraph in
the "Known Issues" section of the Debian README / NEWS / or wherever it
will go about the grant frames issue.

It would be very nice to have some WARN_ONCE code in the linux kernel
exactly at the place where this issue happens, but nobody has been
adding that yet, so for now, if this happens, domUs will just still hang
without meaningful stuff in dmesg.

I also have a suspicion that this issue will be showing up less when
using Xen 4.11+ and Linux 4.19+ in dom0 and domU (so, yay, upgrade all
the things!). Newer Linux kernel versions have patches that also
actually release frame stuff when it's no longer actually in use, which
might end the 'only-going-up' behaviour of the number we see.

Anyway, I'm planning to add some "known issue" documentation about this
to the Xen 4.11 packaging, together with a clear short description of
what to change where in what configuration (because in Xen 4.11+ it's
different than in 4.4 or 4.8 again), and then mark this bts as closed
while that upload happens.

Digging around in kernel code to find out where this happens and adding
this WARN_ONCE is still a nice kernel coding exercise, but I don't want
this bts to track if that ends up on top of my TODO list or not.

Hans

[1] https://salsa.debian.org/xen-team/debian-xen/issues/24

Bug#920631: [rb-general] debian-installer: Ensure build is reproducible regardless of the user's umask(2)

[Vagrant Cascadian]

On 2019-02-22, Cyril Brulebois wrote:
> Cyril Brulebois  (2019-02-22):
>> Vagrant Cascadian  (2019-02-21):
>> > I went ahead and merged them into git.
>> 
>> This seems to have broken all daily builds.

Ouch, very sorry...


> FWIW daily builds are run from a buildscript that basically does:
>   cd build && ./daily-build
>
> but the failures were also obtained by running dpkg-buildpackage.
>
> Please make sure you can build d-i with the patches you're merging?

They seemed innocuous, but obvisouly this is another important lesson to
always test.


> Anyway, this seems to have been fixed this morning by Samuel (please let
> us know when such things happen, so that we know and can also trigger
> daily builds again):
>   
> https://salsa.debian.org/installer-team/debian-installer/commit/d0868ed0bfd3d31a7fc5c3eaf6509d58e74cc2b1

Thanks for cleaning up the mess, Samuel!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#923000: iptables-apply does not restart fail2ban when reverting

[Richard Lewis]

Package: iptables
Version: 1.6.0+snapshot20161117-6
Severity: normal
File: /sbin/iptables-apply
Tags: patch

Dear Maintainer,

iptables-apply stops fail2ban (line 48) but only
restarts it if it gets to line 291. If rules were
reverted line 291 is not executed and the system
is not in the same state as before.

I suggest restarting fail2ban in revertrules as well

--- /usr/sbin/iptables-apply2017-04-12 10:41:06.0 +0100
+++ /tmp/iptabls-appply.new 2019-02-22 13:24:30.361996547 +
@@ -122,6 +122,7 @@
echo -n "Reverting to old iptables rules... "
"$RESTORE" <"$TMPFILE"
echo "done."
+   [ -x /etc/init.d/fail2ban ] && /etc/init.d/fail2ban start
 }



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

Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iptables depends on:
ii  libc62.24-11+deb9u4
ii  libip4tc01.6.0+snapshot20161117-6
ii  libip6tc01.6.0+snapshot20161117-6
ii  libiptc0 1.6.0+snapshot20161117-6
ii  libnetfilter-conntrack3  1.0.6-2
ii  libnfnetlink01.0.1-3
ii  libxtables12 1.6.0+snapshot20161117-6

iptables recommends no packages.

Versions of packages iptables suggests:
ii  kmod  23-2

-- no debconf information

Bug#912975: xen-hypervisor-4.8-amd64: Dom0 crashes randomly without logs on Debian Stretch with Xen 4.8.4

[Hans van Kranenburg]

Hi Alexander,

On 2/22/19 9:41 PM, Alexander Dahl wrote:
> 
> On Fri, Feb 22, 2019 at 07:24:11PM +0100, Hans van Kranenburg wrote:
>> The current state of this bug does not really allow anyone other than
>> yourself to cause it to progress.
> 
> FWIW, I also have problems with Xen and stretch on amd64. Since
> upgrading from jessie I get random crashes, which means the system
> hangs and I only can do a hard powercycle.

Ok. I'm gonna sound a bit strict/rigorous/stern here (I don't know which
of those is the right one, not a native speaker).

Please don't use an existing bug for an "I'm also having similar
problems" report. It might seem helpful to group similar symptoms
together, but often there seem to be different causes in the end, and
people from the package maintainer team will get confused about what the
real issue was and if it's fixed now or not, and you might end up with a
closed bug report while your issue was not dealt with, or the original
reporter might end up with a closed bug because your me-too problem was
fixed.

>From your problem description, it seems you're experiencing dom0 or even
xen hypervisor problems, not domU (virtual machine) problems. Is that right?

> I'm currently reorganizing
> the partitions to get enough space for a debug kernel on the rootfs,
> otherwise the stacktraces are probably not of big help?

As long as you don't share any stack trace at all, they won't be of any
help no. :) You might be experiencing a known problem, or a problem that
we know already has been fixed upstream in later Xen or Linux, or a new
problem.

> (I would have upgraded to buster already, but pygrub is broken there,
> so maybe we get stretch fixed until then.)

The pygrub fixes are in the upload to unstable that was done today.

https://tracker.debian.org/news/1031793/accepted-xen-411126-g87f51bf366-2-all-amd64-source-into-unstable/

Hans

Off-the-record: 2018 was not a good year for the Linux kernel in
general, also thanks to all the spectre/meltdown things happening. My
own experience is that the Linux 4.9 LTS kernel is quite unusable (as
dom0 and domU) with Xen, and I jumped over it, towards Xen 4.11 and
Linux 4.19, which is a great success so far.

So, with my personal (and $dayjob) hat on, I can recommend leaving the
current situation behind and at least please run the Linux 4.19 kernel
from stretch-backports instead.

With my Debian Xen package mainainer hat on... Yes, I'd like to help
you, but please create an additional bug after you have been able to
collect more logs and stacktraces and explosions happening etc.

Thanks.

Bug#922923: qemu: CVE-2019-8934: ppc64: sPAPR emulator leaks the host hardware identity

[Salvatore Bonaccorso]

Hi Michael,

On Fri, Feb 22, 2019 at 01:43:39AM +0300, Michael Tokarev wrote:
> 22.02.2019 0:22, Salvatore Bonaccorso wrote:
> > Source: qemu
> > Version: 1:3.1+dfsg-4
> > Severity: normal
> > Tags: security upstream
> > Forwarded: 
> > https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg04821.html
> > 
> > Hi,
> > 
> > The following vulnerability was published for qemu.
> > 
> > CVE-2019-8934[0]:
> > ppc64: sPAPR emulator leaks the host hardware identity
> 
> This one's interesting. The vuln itself and the fix too.
> First is described elsewhere.
> 
> For the second, we can't "just" fix it, -- the fix is to provide
> a way to avoid the "leakage" by a means of a command-line option,
> and ofcourse a management tool. if any, to run qemu, needs to know
> and use this option.
> 
> But it is not all really, since this "fix" breaks migration stream
> format, so it can't just be backported to 3.1 (the fix applies to
> the ongoing next version of qemu). I dunno how much do we care about
> the online migration of a ppc guest, probably not _very_ mich, so
> this might be an easy path to take. If it is, we can just use a
> stright backport of this patch to current debian 3.1 version and
> be done with it (modulo the first part -- something needs to actually
> use the fix anyway).

Thanks for the explanations. So I guess it's safest to just wait for
the respective upstream version which will integrate the fixes and
furthermore not try to backport fixes to older versions.

Regards,
Salvatore

Bug#898119: cron: Removal of sharp character at the end of line in the header

[Christian Kastner]

Tags: + confirmed pending

On Mon, 7 May 2018 15:58:57 +0200 =?UTF-8?Q?St=C3=A9phane_Blondon?=
 wrote:
> --- cron_3.0pl1-130.diff.orig 2018-05-07 15:50:16.539054242 +0200
> +++ cron_3.0pl1-130.diff  2018-05-07 15:53:13.851529214 +0200
> @@ -2326,7 +2326,7 @@
>  +"# \n"
>  +"# To define the time you can provide concrete values for\n"
>  +"# minute (m), hour (h), day of month (dom), month (mon),\n"
> -+"# and day of week (dow) or use '*' in these fields (for 'any')."
> ++"# and day of week (dow) or use '*' in these fields (for 'any').\n"
>  +"# \n"
>  +"# Notice that tasks will be started based on the cron's system\n"
>  +"# daemon's notion of time and timezones.\n"

Thanks, patch committed.

Regards,
Christian

Bug#922999: aptitude: Aptitude doesn't display package descriptions on arm64

[Robert Latest]

Package: aptitude
Version: 0.8.7-1
Severity: normal

Dear Maintainer,

when using aptitude to browse packages on the arm64 platform, the
"description" area in the lower half of the screen doesn't display any
descriptions, just the homepage and tags. On my i386 machines it
displays the descriptions but neither tags nor homepage (which I don't
need). I've copied my /etc/apt directory 1:1 from the i386 to the arm
machine, but aptitude keeps behaving differently.

$HOME/.aptitude/config are identical on both machines

-- Package-specific info:
Terminal: rxvt-unicode
$DISPLAY not set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.7
Compiler: g++ 6.3.0 20170415
Compiled against:
  apt version 5.0.1
  NCurses version 6.0
  libsigc++ version: 2.10.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20161126
  cwidget version: 0.5.17
  Apt version: 5.0.1

aptitude linkage:
linux-vdso.so.1 (0x007f9e957000)
libapt-pkg.so.5.0 => /usr/lib/aarch64-linux-gnu/libapt-pkg.so.5.0 
(0x007f9e39b000)
libncursesw.so.5 => /lib/aarch64-linux-gnu/libncursesw.so.5 
(0x007f9e361000)
libtinfo.so.5 => /lib/aarch64-linux-gnu/libtinfo.so.5 
(0x007f9e328000)
libsigc-2.0.so.0 => /usr/lib/aarch64-linux-gnu/libsigc-2.0.so.0 
(0x007f9e311000)
libcwidget.so.3 => /usr/lib/aarch64-linux-gnu/libcwidget.so.3 
(0x007f9e20a000)
libsqlite3.so.0 => /usr/lib/aarch64-linux-gnu/libsqlite3.so.0 
(0x007f9e113000)
libboost_iostreams.so.1.62.0 => 
/usr/lib/aarch64-linux-gnu/libboost_iostreams.so.1.62.0 (0x007f9e0ea000)
libboost_filesystem.so.1.62.0 => 
/usr/lib/aarch64-linux-gnu/libboost_filesystem.so.1.62.0 (0x007f9e0c1000)
libboost_system.so.1.62.0 => 
/usr/lib/aarch64-linux-gnu/libboost_system.so.1.62.0 (0x007f9e0ad000)
libxapian.so.30 => /usr/lib/aarch64-linux-gnu/libxapian.so.30 
(0x007f9de99000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 
(0x007f9de6d000)
libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 
(0x007f9dcdc000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x007f9dc2f000)
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 
(0x007f9dc0d000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x007f9dac3000)
/lib/ld-linux-aarch64.so.1 (0x007f9e92d000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x007f9dab)
libresolv.so.2 => /lib/aarch64-linux-gnu/libresolv.so.2 
(0x007f9da8b000)
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x007f9da63000)
libbz2.so.1.0 => /lib/aarch64-linux-gnu/libbz2.so.1.0 
(0x007f9da41000)
liblzma.so.5 => /lib/aarch64-linux-gnu/liblzma.so.5 (0x007f9da1)
liblz4.so.1 => /usr/lib/aarch64-linux-gnu/liblz4.so.1 
(0x007f9d9f1000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x007f9d9da000)
libuuid.so.1 => /lib/aarch64-linux-gnu/libuuid.so.1 (0x007f9d9c5000)

-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

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

Versions of packages aptitude depends on:
ii  aptitude-common0.8.7-1
ii  libapt-pkg5.0  1.4.9
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4
ii  libboost-iostreams1.62.0   1.62.0+dfsg-4
ii  libboost-system1.62.0  1.62.0+dfsg-4
ii  libc6  2.24-11+deb9u4
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:6.3.0-18+deb9u1
ii  libncursesw5   6.0+20161126-1+deb9u2
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libsqlite3-0   3.16.2-5+deb9u1
ii  libstdc++6 6.3.0-18+deb9u1
ii  libtinfo5  6.0+20161126-1+deb9u2
ii  libxapian301.4.3-2+deb9u3

Versions of packages aptitude recommends:
pn  libparse-debianchangelog-perl  
ii  sensible-utils 0.0.9+deb9u1

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
ii  tasksel 3.39

-- Configuration Files:
/etc/logrotate.d/aptitude changed:
/var/log.hdd/aptitude {
  rotate 6
  monthly
  compress
  missingok
  notifempty
}


-- no debconf information

Bug#912975: xen-hypervisor-4.8-amd64: Dom0 crashes randomly without logs on Debian Stretch with Xen 4.8.4

[Alexander Dahl]

Hei hei,

On Fri, Feb 22, 2019 at 07:24:11PM +0100, Hans van Kranenburg wrote:
> The current state of this bug does not really allow anyone other than
> yourself to cause it to progress.

FWIW, I also have problems with Xen and stretch on amd64. Since
upgrading from jessie I get random crashes, which means the system
hangs and I only can do a hard powercycle. I'm currently reorganizing
the partitions to get enough space for a debug kernel on the rootfs,
otherwise the stacktraces are probably not of big help?

(I would have upgraded to buster already, but pygrub is broken there,
so maybe we get stretch fixed until then.)

Greets
Alex

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
 X  AGAINST  | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)


signature.asc
Description: PGP signature

Bug#922995: pycsw: FTBFS: dh_installman: Cannot find (any matches for) "debian/man/pycsw-admin.1"

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 2/22/19 8:27 PM, Andreas Beckmann wrote:
> dh_installman: Cannot find (any matches for) "debian/man/pycsw-admin.1" 
> (tried in .)

ronn apparently changed behaviour:

 ronn debian/man/pycsw-admin.md
  roff: debian/man/pycsw-admin.md.1
  html: debian/man/pycsw-admin.md.1.html  +man

Fixed by renaming the file.

Kind Regards,

Bas

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

Bug#922998: python-sqlalchemy: (armhf) Can't load plugin: sqlalchemy.dialects:mysql

[Robert Latest]

Package: python-sqlalchemy
Version: 1.0.15+ds1-1
Severity: normal

Dear Maintainer,

I'm using several installations of sqlalchemy on Intel 32 and 64 bit
platforms (both Debian and RedHat). But I found it impossible to
transfer my application from i386 to arm64 because of this error.

This line:

engine = create_engine('mysql://localhost/sql13503')

raises this exception:

NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:mysql


-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

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

Versions of packages python-sqlalchemy depends on:
ii  python  2.7.13-2

Versions of packages python-sqlalchemy recommends:
ii  python-sqlalchemy-ext  1.0.15+ds1-1

Versions of packages python-sqlalchemy suggests:
ii  python 2.7.13-2
pn  python-fdb 
ii  python-mysqldb 1.3.7-1.1
pn  python-psycopg2
pn  python-pymssql 
pn  python-sqlalchemy-doc  

-- no debconf information

Bug#922925: libreoffice: Please add a crash tracker

[Rene Engelhard]

On Fri, Feb 22, 2019 at 09:58:52AM +0100, Jean-Philippe MENGUAL wrote:
> > And send where? Upstrem? Where we have a different build config than
> > them? (Let alone think about external libraries). Do we really want our
> > LO to "phone home" on a crash? Do we want to set up a web service for
> > those reports? (The latter one definitely is no)
> 
> Well I am not a familiar with QA, but according to what I understand, in TDF
> releases (I tried nightly before going back to Debian as it was useless),
> when LO crashes, a crash report is somewhere on the TDF infra. It also is

I know. That needs infrastructure, though, as you say.

> stored on the locl computer. From this file, a user can check wether a bug
> is opened or not and if not, fill one with reproducible steps and this file
> to help upstream devs.

Yes, you can still do so manually...

> > For a meaningful backtrace you just need the *-dbgsym's, not necessarily
> > the "crash reporter".
> 
> Yes but it also requirs skills related to gdb then, doesn't it? I mean,

Yes.

> -dbgsym are a base to get relevant crash reports, but how to generate them?
> The only way I know is running gdb, but il Libreoffice the problem is
> knowing on which binary.

There's basically just soffice.bin as a binary.

> My question is then: is reporting bug upstream from a Debian build relevant?
> If yes, should not we write something to assist users doing it (a short wiki
> page about how to help debugging LO from a Debian release)?

https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace
 ?

Regards,

Rene

Bug#859553: pidentd: Please migrate to openssl1.1 in buster

[Moritz Mühlenhoff]

On Thu, Feb 21, 2019 at 11:37:02PM +0100, Sebastian Andrzej Siewior wrote:
> The debian maintainer of this package looks MIA. Nobody spoke up for
> keeping it so far. I'm happy to NMU it so it builds against libssl-dev
> but I see little to no reason for it. I think we have alternatives which
> *are* in Buster.
> Would you mind filling a RM request?

I've just filed a RM bug.

Cheers,
Moritz

Bug#922997: RM: pidentd -- RoQA; unmaintained, RC-buggy, alternatives exist

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pidentd from the archive. It's dead upstream hasn't seen
a maintainer upload since 2016 and is dropped from testing since 2017
(and thus missed buster). It's one of the few remaining packages still
depending OpenSSL and thus blocking it's removal. Alternatives exist
(oidentd).

Cheers,
Moritz

Bug#894013: [Pkg-xen-devel] Bug#894013: xen-utils-common: issue with iptables antispoofing rules in xen4.8 generated by vif-bridge and vif-common.sh

[Hans van Kranenburg]

tags 894013 + upstream
severity 894013 wishlist
thanks

On 1/4/19 12:01 AM, Hans van Kranenburg wrote:
> On 1/3/19 11:46 PM, Hans van Kranenburg wrote:
>> Hi,
>>
>> [...]

I'm moving this one to the wishlist department of the bug list, and
tagging upstream, because this needs to happen upstream. This doesn't
mean I'm trying to sweep it under the carpet. This is one of the more
interesting issues, but it is not in a state where we can just "do
something" and fix it in the next package upload.

Hans

Bug#922484: nmu: paw_1:2.14.04.dfsg.2-9.1, mclibs_20061220+dfsg3-3.1, geant321_1:3.21.14.dfsg-11

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 22/02/2019 à 10:08 :
> Control: tags -1 stretch
> 
> On 21/02/2019 23:55, Andreas Beckmann wrote:
>> On Sat, 16 Feb 2019 22:09:11 +0100 Gilles Filippini  wrote:
>>> Now that #922453 is fixed, paw, mclibs and geant321 have to be rebuilt
>>> against this fixed cernlib release.
>>
>> Please binNMU the packages with a "gap" in the binNMU version s.t. this 
>> bug can be fixed by binNMUing in stable, too. The stretch binNMUs need a 
>> fixed cernlib in stretch-pu first of course (no pu request filed, yet).

I've just filed #922987.

>> given that we have these binary versions currently in stretch and sid:
>>
>> paw | 1:2.14.04.dfsg.2-9.1| stable | source, 
>> amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
>> paw | 1:2.14.04.dfsg.2-9.1+b2 | unstable   | amd64, 
>> arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
>>
>> libherwig59-2-dev   | 20061220+dfsg3-3.1  | stable | amd64, 
>> armel, armhf, i386, mips, mipsel, s390x
>> libherwig59-2-dev   | 20061220+dfsg3-3.1+b2   | unstable   | amd64, 
>> armel, armhf, i386, mips, mipsel, s390x
>>
>> libgeant321-2-dev   | 1:3.21.14.dfsg-11+b2| stable | amd64, 
>> arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
>> libgeant321-2-dev   | 1:3.21.14.dfsg-11+b4| unstable   | amd64, 
>> arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
>>
>> the following binNMUs should leave the required gap:
>>
>> nmu 4 paw_1:2.14.04.dfsg.2-9.1 . ANY . unstable . -m "rebuild against fixed 
>> cernlib regarding #922453"
>> nmu 4 mclibs_20061220+dfsg3-3.1 . ANY . unstable . -m "rebuild against fixed 
>> cernlib regarding #922453"
>> nmu 6 geant321_1:3.21.14.dfsg-11 . ANY . unstable . -m "rebuild against 
>> fixed cernlib regarding #922453"
> 
> Scheduled.
> 
>> For future reference, the corresponding binNMUs for stretch would be:
>>
>> nmu 3 paw_1:2.14.04.dfsg.2-9.1 . ANY . stretch . -m "rebuild against fixed 
>> cernlib regarding #922453"
>> dw paw_1:2.14.04.dfsg.2-9.1 . ANY . stretch . -m "cernlib-base-dev (>= 
>> 20061220+dfsg3-4.4~deb9u1)
>> nmu 3 mclibs_20061220+dfsg3-3.1 . ANY . stretch . -m "rebuild against fixed 
>> cernlib regarding #922453"
>> dw mclibs_20061220+dfsg3-3.1 . ANY . stretch . -m "cernlib-base-dev (>= 
>> 20061220+dfsg3-4.4~deb9u1)
>> nmu 5 geant321_1:3.21.14.dfsg-11 . ANY . stretch . -m "rebuild against fixed 
>> cernlib regarding #922453"
>> dw geant321_1:3.21.14.dfsg-11 . ANY . stretch . -m "cernlib-base-dev (>= 
>> 20061220+dfsg3-4.4~deb9u1)
> 
> I'll leave those to a SRM. I'm keeping this bug open and tagging it as stretch
> so the bug appears on their radar.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#920631: [rb-general] debian-installer: Ensure build is reproducible regardless of the user's umask(2)

[Cyril Brulebois]

Cyril Brulebois  (2019-02-22):
> Vagrant Cascadian  (2019-02-21):
> > I went ahead and merged them into git.
> 
> This seems to have broken all daily builds.

FWIW daily builds are run from a buildscript that basically does:
  cd build && ./daily-build

but the failures were also obtained by running dpkg-buildpackage.

Please make sure you can build d-i with the patches you're merging?


Anyway, this seems to have been fixed this morning by Samuel (please let
us know when such things happen, so that we know and can also trigger
daily builds again):
  
https://salsa.debian.org/installer-team/debian-installer/commit/d0868ed0bfd3d31a7fc5c3eaf6509d58e74cc2b1


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


signature.asc
Description: PGP signature

Bug#922787: Please fix!

[Matthias Urlichs]

This bug prevents use with a significant portion of available ESP32
devices and development boards out there. Please update this package –
the current version should not be in the next release. I can prepare an
NMU if necessary.

-- 
-- Matthias Urlichs




signature.asc
Description: OpenPGP digital signature

Bug#920631: [rb-general] debian-installer: Ensure build is reproducible regardless of the user's umask(2)

[Cyril Brulebois]

Hi,

Vagrant Cascadian  (2019-02-21):
> On 2019-02-21, Chris Lamb wrote:
> > Chris Lamb wrote:
> >> > #920631 debian-installer: Ensure build is reproducible regardless
> >> > of the user's umask(2)
> >> [..]
> >> > #920676: debian-installer: Ensure build is reproducible
> >> > regardless of the underlying filesystem ordering
> >> 
> >> Thank you for developing and maintainer the Debian Installer. I
> >> was wondering what might be needed on my end to ensure that these
> >> patches end up in the next alpha/beta release?
> >
> > Sorry to bug you again folks but I haven't done any d-i development
> > for almost 10 years now so I may not be aware of the most
> > productive, helpful and — above everything else! — friendly way of
> > getting things merged, particularly in time for buster. Can you
> > help? :-)
> 
> I went ahead and merged them into git.

This seems to have broken all daily builds.

Example on amdahl for arm64, even if that doesn't appear to be
arch-specific at all.

[ last lines of /home/d-i/di/logs/di-autobuild_daily-arm64-20190222-0200 ]

# Ensure build results have reproducible mtimes
chmod: changing permissions of './tmp/netboot/tree/sbin/modprobe': 
Operation not permitted
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/vconfig'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/syslogd'
chmod: changing permissions of './tmp/netboot/tree/sbin/modinfo': Operation 
not permitted
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/mkswap'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/swapon'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/blockdev'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/fstrim'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/swapoff'
chmod: changing permissions of './tmp/netboot/tree/sbin/insmod': Operation 
not permitted
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/udhcpc'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/poweroff'
chmod: changing permissions of './tmp/netboot/tree/sbin/rmmod': Operation 
not permitted
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/sbin/freeramdisk'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/klogd'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/sbin/switch_root'
chmod: changing permissions of './tmp/netboot/tree/sbin/depmod': Operation 
not permitted
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/reboot'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/ip'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/route'
chmod: changing permissions of './tmp/netboot/tree/sbin/lsmod': Operation 
not permitted
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/halt'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/sbin/hwclock'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/sbin/pivot_root'
chmod: changing permissions of './tmp/netboot/tree/usr/lib/ssl/certs': 
Operation not permitted
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/usr/sbin/chroot'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/usr/sbin/arping'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/['
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/test'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/usr/bin/printf'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/wc'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/bzcat'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/usr/bin/dirname'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/sort'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/[['
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/nc'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/env'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/tftp'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/tail'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/xzcat'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/usr/bin/realpath'
chmod: cannot operate on dangling symlink 
'./tmp/netboot/tree/usr/bin/groups'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/tr'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/head'
chmod: cannot operate on dangling symlink './tmp/netboot/tree/usr/bin/free'
chmod: can

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

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

rebuilding 20170929 for stretch also imported some bashisms, breaking
the hook script.
That code is no longer present in sid.


Andreas


ca-certificates-java_20170929~deb9u2.dsc.diff.gz
Description: application/gzip

Bug#922994: muscle FTCBFS: uses the wrong compiler

[Helmut Grohne]

Source: muscle
Version: 1:3.8.1551-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

muscle fails to cross build from source, because its upstream Makefile
uses the non-standard name GPP for the C++ compiler and thus uses the
build architecture compiler. After renaming the compiler, it cross
builds successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru muscle-3.8.1551/debian/changelog 
muscle-3.8.1551/debian/changelog
--- muscle-3.8.1551/debian/changelog2018-10-29 09:42:54.0 +0100
+++ muscle-3.8.1551/debian/changelog2019-02-22 20:23:33.0 +0100
@@ -1,3 +1,10 @@
+muscle (1:3.8.1551-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass C++ compilers as GPP. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 22 Feb 2019 20:23:33 +0100
+
 muscle (1:3.8.1551-1) unstable; urgency=medium
 
   * New upstream version
diff --minimal -Nru muscle-3.8.1551/debian/rules muscle-3.8.1551/debian/rules
--- muscle-3.8.1551/debian/rules2018-10-29 09:42:54.0 +0100
+++ muscle-3.8.1551/debian/rules2019-02-22 20:23:31.0 +0100
@@ -4,3 +4,6 @@
 
 %:
dh $@
+
+override_dh_auto_build:
+   dh_auto_build -- 'GPP=$$(CXX)'

Bug#922995: pycsw: FTBFS: dh_installman: Cannot find (any matches for) "debian/man/pycsw-admin.1"

[Andreas Beckmann]

Source: pycsw
Version: 2.2.0+dfsg-5
Severity: serious
Justification: fails to build from source

Hi,

pycsw recently started to FTBFS in a minimal up-to-date sid pbuilder
environment:

[...]
   debian/rules override_dh_install
make[1]: Entering directory '/build/pycsw-2.2.0+dfsg'
dh_install --list-missing
dh_install: Please use dh_missing --list-missing/--fail-missing instead
dh_install: This feature will be removed in compat 12.
# Remove empty directories
rmdir debian/*/usr/share/pycsw/tests/functionaltests/suites/harvesting/data/
rmdir debian/*/usr/share/pycsw/tests/functionaltests/suites/manager/data/
# Remove documentation outside usr/share/doc
rm -f debian/*/usr/share/pycsw/tests/README.txt
rm -f 
debian/*/usr/share/pycsw/tests/functionaltests/suites/apiso/data/README.txt
rm -f debian/*/usr/share/pycsw/tests/functionaltests/suites/cite/data/README.txt
make[1]: Leaving directory '/build/pycsw-2.2.0+dfsg'
   dh_apache2 -O--buildsystem=pybuild -O--parallel
   dh_installdocs -O--buildsystem=pybuild -O--parallel
   dh_sphinxdoc -O--buildsystem=pybuild -O--parallel
   dh_installchangelogs -O--buildsystem=pybuild -O--parallel
   dh_installexamples -O--buildsystem=pybuild -O--parallel
   dh_installman -O--buildsystem=pybuild -O--parallel
dh_installman: Cannot find (any matches for) "debian/man/pycsw-admin.1" (tried 
in .)

dh_installman: Aborting due to earlier error
make: *** [debian/rules:7: binary] Error 25


Andreas


pycsw_2.2.0+dfsg-5.log.gz
Description: application/gzip

Bug#922644: [debian-mysql] Bug#922644: mariadb-server-10.3: Unable to reinstall

[Janusz S. Bień]

On Fri, Feb 22 2019 at 20:39 +02, Otto Kekäläinen wrote:
> pe 22. helmik. 2019 klo 18.40 Janusz S. Bień (jsb...@mimuw.edu.pl) kirjoitti:
>>
>> On Fri, Feb 22 2019 at 17:09 +02, Otto Kekäläinen wrote:
>> > The problem is:
>> > " Installation of system tables failed!"
>> >
>> > What if you uninstall/purge, clear /etc/mysql and /var/lib/mysql and try 
>> > again?
>>
>> I was already thinking about purging the package, but I would like to be sure
>> what is the risk. Is there a chance I will loose the database needed for
>> playing MythTV recording?
>
> Yes, purging the package will delete /var/lib/mysql and all of your data.
>
> Your configs look OK. Unfortunately I am not able to figure out what
> might the problem with this data.

Fortunately I can live without MythTV by using a MS Windows program for
TV. Nevertheless I would like to solve my problem in some reasonable
future. I will come bacǩ to it probably in April, after some planned
hardware change.

Best regards

Janusz

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#922644: [debian-mysql] Bug#922644: mariadb-server-10.3: Unable to reinstall

[Otto Kekäläinen]

pe 22. helmik. 2019 klo 18.40 Janusz S. Bień (jsb...@mimuw.edu.pl) kirjoitti:
>
> On Fri, Feb 22 2019 at 17:09 +02, Otto Kekäläinen wrote:
> > The problem is:
> > " Installation of system tables failed!"
> >
> > What if you uninstall/purge, clear /etc/mysql and /var/lib/mysql and try 
> > again?
>
> I was already thinking about purging the package, but I would like to be sure
> what is the risk. Is there a chance I will loose the database needed for
> playing MythTV recording?

Yes, purging the package will delete /var/lib/mysql and all of your data.

Your configs look OK. Unfortunately I am not able to figure out what
might the problem with this data.

Bug#922993: RFS: Popout3D/1.5.0

[Popout3D]

Package: sponsorship-requests

Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "Popout3D":

Package name: Popout3D
Version : 1.5.0
Upstream Author : Chris Rogers
URL : popout3d/popout3d
License : GNU GENERAL PUBLIC LICENSE GPLv3
Section : Graphics

It enables the creation of a 3D image from two photos taken with an ordinary 
camera, without any technical knowledge. Without Popout3D that process is 
extremely laborious, as it requires expert use of software such as Hugin to 
accurately align the images, then Gimp to filter and merge them. A set of 
images or a whole directory can be processed and the results reviewed.

It builds these binary packages:

    popout3d -  Creates 3D images from photographs taken with an ordinary 
camera.

To access further information about this package, please visit the following 
URL:

popout3d/popout3d

Changes since the last upload:

This has only previously been released on GetDebChris

Sample 3D image created with the software:

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
popout3d/popout3d

Popout3D creates 3D images from photographs taken with an ordinary camera. - 
popout3d/popout3d
 |

 |

 |

Bug#812327: xen: initrd booting with xen don't find any harddisks

[Hans van Kranenburg]

Hi Markus,

This is about the bug report (#812327) that you filed
before in the Debian bug tracker, against the Xen packages.

Your bug report was targeted at a Xen package in a Debian distribution
older than the current stable (Stretch).

Can you please help us by confirming that any of the following scenarios
does apply to your situation?

* I had this problem a long time ago. It was never solved, but I found a
workaround, which is ...
* I had this problem a long time ago, and I solved it by not using Xen
any more, but by doing ...
* I still experience this problem, and I'm still using Xen
3.2/4.1/4.4/etc. I cannot upgrade to Debian Stretch or Buster because ...
* I had this problem, and since upgrading to Stretch / Buster / ? it
seems it was solved, and I forgot to report it again. Please close it,
thanks.
* Other: ...

Note that even if you found a solution, it's still very useful to report
it back to our bug tracker. There might be someone else running into the
same problem, who can be helped with your information.

Please note that unless there's a response within a while from now, we
will close the bug report. If you discover this message later, and this
case is important to you, then you can try unarchiving the bug and
replying to it, or reach out to the maintainers email list at
pkg-xen-devel at lists.alioth.debian.org (no subscription required) and
post a message.

Thanks,
Hans van Kranenburg

Bug#915547: Use iso639-3.xml file

[Osamu Aoki]

Hi,

On Sun, Feb 17, 2019 at 11:38:18PM +0900, Osamu Aoki wrote:
...
> Looks like pull request https://github.com/ibus/ibus/pull/2061 is
> already applied to fujiwara's https://github.com/fujiwarat/ibus  repo
> for 1.5.20.
> 
> 1cd52548 ("src: use iso 639-3 to have names for more languages", 2018-12-17)
> 
> He didn't apply it to https://github.com/ibus/ibus repo

This is incorrect.  fujiwatat and ibus has the same commit history.

> Let's close this when ibus 1.5.20 is packaged for post-buster.
> 
> If Daniel think upstream patch needs to be backported, can you create
> pull request on salsa?
> 
>   https://salsa.debian.org/debian/ibus
> 
> With rationale to patch it for Debian.

I am waiting :-)

Osamu

Bug#921586: RFS: pymacs/0.25-1.2 [ITA]

[Bart Martens]

Hi Emmanuel,

Good to see you want to adopt this package. However, the version ending
with -1.2 seems meant for a non-maintainer upload. Any specific reason
for using an non-maintainer upload version number here?

Cheers,

Bart

Bug#922615: nvidia-driver: Windows not visible on third screen after stable upgrade

[Andreas Ronnquist]

Alright, I thought I would have my problem fixed now, putting

xrandr --output HDMI-0 --mode 1920x1200 --rotate left --pos 5120x0
--output DP-0 --mode 2560x1440 --pos 2560x0 --output DP-2 --mode
2560x1440 --pos 0x0

into /usr/local/bin/setup_lightdm_xrandr.sh, (with a proper shebang) and
adding it to 

/etc/lightdm/lightdm.conf under

[Seat:*]

display_setup_script=/usr/local/bin/setup_lightdm_xrandr.sh
session_setup_script=/usr/local/bin/setup_lightdm_xrandr.sh

makes lightdm work correctly again, but then I run into the original
problem when logging into Xfce. Mouse shows correctly on my pivot
screen, but dragging any window there shows only the mouse cursor, and
no window. (I can see that the screen is like I want it regarding to
position and pivot rotation though).

Question is if it is a lighdm, Xfce or Nvidia problem though...

-- Andreas Rönnquist
gus...@debian.org

Bug#912975: xen-hypervisor-4.8-amd64: Dom0 crashes randomly without logs on Debian Stretch with Xen 4.8.4

[Hans van Kranenburg]

tags 912975 + moreinfo
thanks

Hi,

On 11/7/18 3:43 PM, Roalt Zijlstra | webpower wrote:
> 
> Op wo 7 nov. 2018 om 14:30 schreef Hans van Kranenburg  >:
> >
> > Well hopefully the 'noreboot' provided server crashes soon for some
> > logs. I will check if we can do any serial console tricks.
> 
> Oh and before I forget.. Thanks for all the feedback/help!

Do you have any update here? Any debug logging?

The current state of this bug does not really allow anyone other than
yourself to cause it to progress.

Hans

Bug#922992: hardlink FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

Source: hardlink
Version: 0.3.2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

hardlink fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config. After making it
substitutable, hardlink cross builds successfully. Please consider
applying the attached patch.

Helmut
--- hardlink-0.3.2.orig/Makefile
+++ hardlink-0.3.2/Makefile
@@ -13,9 +13,11 @@
 EXTRA_LIBS  = $(shell $(EXTRA_LIBS!))
 EXTRA_FLAGS = $(shell $(EXTRA_FLAGS!))
 
+PKG_CONFIG ?= pkg-config
+
 # pmake executes the commands, GNU make creates variables with a ! suffix
-EXTRA_LIBS!= pkg-config --libs $(ENABLE) 2>/dev/null || echo
-EXTRA_FLAGS!= pkg-config --cflags $(ENABLE) 2>/dev/null || echo
+EXTRA_LIBS!= $(PKG_CONFIG) --libs $(ENABLE) 2>/dev/null || echo
+EXTRA_FLAGS!= $(PKG_CONFIG) --cflags $(ENABLE) 2>/dev/null || echo
 
 #Default flags
 CFLAGS ?= -Wall -O2 -g

Bug#922160: lightdm: Add elogind support

[Ansgar]

On Fri, 2019-02-22 at 17:46 +, Mark Hindley wrote:
> On Fri, Feb 22, 2019 at 06:34:09PM +0100, Ansgar wrote:
> > On Fri, 2019-02-22 at 13:59 +, Mark Hindley wrote:
> > > A further suggestion, now systemd 241-1 has been uploaded to
> > > unstable
> > > with
> > > libpam-systemd which provides logind (closing #915407), the
> > > dependencies could
> > > be simplified to
> > > 
> > >  logind [linux-any] | consolekit,
> > 
> > So the PAM configuration is no longer relevant?
> 
> Yes, I think the PAM configuration change is still required.

So the logind dependency is still wrong as a different logind provider
than those listed in the PAM configuration won't work?

> > Also, please list a real package first to ensure the same package
> > gets
> > picked by default, i.e.
> > 
> >   libpam-systemd [linux-any] | logind [linux-any] | consolekit
> 
> OK, so consolekit | logind [linux-any]

No.  consolekit is not a real package; nor the preferred provider.

Ansgar

Bug#837962: Xen 4.6 fails to build due to incorrect patch applied to tools/blktap2/drivers/tapdisk-vbd.c

[Hans van Kranenburg]

On 1/22/19 6:55 PM, Hans van Kranenburg wrote:
> [...]
> 
> Please note that unless there's a response within a month from now, we
> will close the bug report. 

Closing now.

Hans

Bug#820862: Xen VM on Jessie freezes often with INFO: task jbd2/xvda2-8:111 blocked for more than 120 seconds

[Hans van Kranenburg]

Hi Christoph,

This is about the bug report (#820862) that you filed
before in the Debian bug tracker, against the Xen packages.

Your bug report was targeted at a Xen package in a Debian distribution
older than the current stable (Stretch).

Can you please help us by confirming that any of the following scenarios
does apply to your situation?

* I had this problem a long time ago. It was never solved, but I found a
workaround, which is ...
* I had this problem a long time ago, and I solved it by not using Xen
any more, but by doing ...
* I still experience this problem, and I'm still using Xen
3.2/4.1/4.4/etc. I cannot upgrade to Debian Stretch or Buster because ...
* I had this problem, and since upgrading to Stretch / Buster / ? it
seems it was solved, and I forgot to report it again. Please close it,
thanks.
* Other: ...

Note that even if you found a solution, it's still very useful to report
it back to our bug tracker. There might be someone else running into the
same problem, who can be helped with your information.

Please note that unless there's a response within a while from now, we
will close the bug report. If you discover this message later, and this
case is important to you, then you can try unarchiving the bug and
replying to it, or reach out to the maintainers email list at
pkg-xen-devel at lists.alioth.debian.org (no subscription required) and
post a message.

Thanks,
Hans van Kranenburg

Bug#804884: xen-hypervisor-4.4-amd64: Starting with hypervisor get nouveau CACHE_ERROR in dmesg without hypervisor -> OK

[Hans van Kranenburg]

Hi ced,

This is about the bug report (#804884) about nouveau that you filed
before in the Debian bug tracker, against the Xen packages.

Your bug report was targeted at a Xen package in a Debian distribution
older than the current stable (Stretch).

Can you please help us by confirming that any of the following scenarios
does apply to your situation?

* I had this problem a long time ago. It was never solved, but I found a
workaround, which is ...
* I had this problem a long time ago, and I solved it by not using Xen
any more, but by doing ...
* I still experience this problem, and I'm still using Xen
3.2/4.1/4.4/etc. I cannot upgrade to Debian Stretch or Buster because ...
* I had this problem, and since upgrading to Stretch / Buster / ? it
seems it was solved, and I forgot to report it again. Please close it,
thanks.
* Other: ...

Note that even if you found a solution, it's still very useful to report
it back to our bug tracker. There might be someone else running into the
same problem, who can be helped with your information.

Please note that unless there's a response within a while from now, we
will close the bug report. If you discover this message later, and this
case is important to you, then you can try unarchiving the bug and
replying to it, or reach out to the maintainers email list at
pkg-xen-devel at lists.alioth.debian.org (no subscription required) and
post a message.

Thanks,
Hans van Kranenburg

Bug#922798: nvidia-driver: Xorg uses wrong copy of libglx.so with nvidia-driver version 415.27

[Andreas Beckmann]

On 2019-02-22 16:44, Михаил Воронов wrote:
> Update:
> I reinstalled xserver-xorg-core. Now it loads without any problems and loads 
> correct libglx.so.
> [...]
> [ 22.087] (II) LoadModule: "glx"
> [ 22.103] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
> [ 22.154] (II) Module glx: vendor="X.Org Foundation"
> [ 22.154]     compiled for 1.20.3, module version = 1.0.0
> [ 22.154]     ABI class: X.Org Server Extension, version 10.0
> [...]
> It seems that during one of the xserver-xorg-core upgrades the library was 
> not upgraded.

More likely, the .run installer moved aside the libglx.so to replace it
with its own variant. Then you upgraded xorg, replacing it again with
the current xorg variant. Upon removal of the .run installer version the
old backup was restored.

There is not much that we can do on the nvidia-installer-cleanup side,
since there was no "unclean" removal.


Andreas

Bug#922160: lightdm: Add elogind support

[Mark Hindley]

On Fri, Feb 22, 2019 at 06:34:09PM +0100, Ansgar wrote:
> On Fri, 2019-02-22 at 13:59 +, Mark Hindley wrote:
> > A further suggestion, now systemd 241-1 has been uploaded to unstable
> > with
> > libpam-systemd which provides logind (closing #915407), the
> > dependencies could
> > be simplified to
> > 
> >  logind [linux-any] | consolekit,
> 
> So the PAM configuration is no longer relevant?

Yes, I think the PAM configuration change is still required.

> Also, please list a real package first to ensure the same package gets
> picked by default, i.e.
> 
>   libpam-systemd [linux-any] | logind [linux-any] | consolekit

OK, so consolekit | logind [linux-any]

Thanks

Mark

Bug#922160: lightdm: Add elogind support

[Ansgar]

On Fri, 2019-02-22 at 13:59 +, Mark Hindley wrote:
> A further suggestion, now systemd 241-1 has been uploaded to unstable
> with
> libpam-systemd which provides logind (closing #915407), the
> dependencies could
> be simplified to
> 
>  logind [linux-any] | consolekit,

So the PAM configuration is no longer relevant?

Also, please list a real package first to ensure the same package gets
picked by default, i.e.

  libpam-systemd [linux-any] | logind [linux-any] | consolekit

or something like that.

See reverse depends of mail-transport-agent as a different example for
this.

Ansgar