Bug#923432: gnome-shell: WLAN status icon gets unresponsive after some suspend and resume cycles

[Paul Menzel]

Package: gnome-shell
Version: 3.30.2-3
Severity: normal
Forwarded: https://gitlab.gnome.org/GNOME/gnome-shell/issues/903


Dear Debian folks,


After some suspend/resume cycles, sometimes the WLAN status icon is not 
updated anymore. For example, currently, it is the icon for the Wifi to

be connected, but the Wifi is actually not connected, and `nmcli`
confirms that. Even disabling the Wifi, the airplone mode icon appears, 
but the Wifi connected icon still remains.


The journal contains the messages below.

```
Feb 27 21:50:41.139683 ersatz gnome-shell[841]: Object 
NM.ActiveConnection (0x5559db1794a0), has been already deallocated — 
impossible to get any prop
erty from it. This might be caused by the object having been destroyed 
from C code using something such as destroy(), dispose(), or remove() 
vfuncs.
Feb 27 21:50:41.140060 ersatz gnome-shell[841]: JS ERROR: TypeError: 
connection.get_setting_ip4_config is not a function


_isHotSpotMaster@resource:///org/gnome/shell/ui/status/network.js:1339:25

wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22

getIndicatorIcon@resource:///org/gnome/shell/ui/status/network.js:1352:13

wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22

_updateIcon@resource:///org/gnome/shell/ui/status/network.js:2051:52

wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22

_syncNMState@resource:///org/gnome/shell/ui/status/network.js:1946:9

wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
Feb 27 21:50:41.140420 ersatz org.gnome.Shell.desktop[841]: == Stack 
trace for context 0x5559db4881d0 ==
Feb 27 21:50:41.140420 ersatz org.gnome.Shell.desktop[841]: #0 
5559dd41dd68 i   resource:///org/gnome/shell/ui/status/network.js:1335 
(7fbb33ce58b0 @ 56)
Feb 27 21:50:41.140420 ersatz org.gnome.Shell.desktop[841]: #1 
7ffcd5348350 b   resource:///org/gnome/gjs/modules/_legacy.js:82 
(7fbb643b0b80 @ 71)
Feb 27 21:50:41.140420 ersatz org.gnome.Shell.desktop[841]: #2 
5559dd41dcd0 i   resource:///org/gnome/shell/ui/status/network.js:1352 
(7fbb33ce5940 @ 113)
Feb 27 21:50:41.140420 ersatz org.gnome.Shell.desktop[841]: #3 
7ffcd53492c0 b   resource:///org/gnome/gjs/modules/_legacy.js:82 
(7fbb643b0b80 @ 71)
Feb 27 21:50:41.140420 ersatz org.gnome.Shell.desktop[841]: #4 
5559dd41dc30 i   resource:///org/gnome/shell/ui/status/network.js:2051 
(7fbb33ce8af0 @ 216)
Feb 27 21:50:41.140420 ersatz org.gnome.Shell.desktop[841]: #5 
7ffcd534a230 b   resource:///org/gnome/gjs/modules/_legacy.js:82 
(7fbb643b0b80 @ 71)
Feb 27 21:50:41.140420 ersatz org.gnome.Shell.desktop[841]: #6 
5559dd41dbb0 i   resource:///org/gnome/shell/ui/status/network.js:1946 
(7fbb33ce8700 @ 80)
Feb 27 21:50:41.140420 ersatz org.gnome.Shell.desktop[841]: #7 
7ffcd534b1b0 b   resource:///org/gnome/gjs/modules/_legacy.js:82 
(7fbb643b0b80 @ 71)
Feb 27 21:50:41.140420 ersatz org.gnome.Shell.desktop[841]: #8 
5559dd41daf0 i   self-hosted:979 (7fbb643f01f0 @ 440)
Feb 27 21:50:41.217273 ersatz wpa_supplicant[500]: nl80211: deinit 
ifname=wlp2s0 disabled_11b_rates=0


```

I reported this issue upstream as [1].


Kind regards,

Paul


[1]: https://gitlab.gnome.org/GNOME/gnome-shell/issues/903
 "Object NM.ActiveConnection (0x560dd5e44d80), has been already 
deallocated"


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

Kernel: Linux 4.20.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1
ii  gir1.2-accountsservice-1.0   0.6.45-1
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-3
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-1
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-ibus-1.0  1.5.19-4
ii  gir1.2-mutter-3  3.30.2-6
ii  gir1.2-nm-1.01.14.6-2
ii  gir1.2-nma-1.0   1.8.20-1
ii  gir1.2-pango-1.0 1.42.4-6
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-1
ii  gir1.2-soup-2.4  2.64.2-2
ii  

Bug#923431: containerd: unsatisfiable build dependencies

[Ralf Treinen]

Source: containerd
Version: 0.2.3+git20170126.85.aa8187d~ds1-2
Severity: serious
Tags: ftbfs
User: trei...@debian.org
Usertags: edos-uninstallable

Hi,

containerd cannot satisfy its build-dependencies in sid due to a 
conflict between golang-github-rcrowley-go-metrics-dev and golang-metrics-dev.

In fact:
- containers build-depends on golang-github-cyberdelia-go-metrics-graphite-dev
- golang-github-cyberdelia-go-metrics-graphite-dev (0.0~git20151204.0.7e54b5c-3)
  depends on golang-github-rcrowley-go-metrics-dev

- containerd also build-depends on golang-metrics-dev

- golang-github-rcrowley-go-metrics-dev (0.0~git20180125.8732c61-2)
  declares a Conflict with golang-metrics-dev.

-Ralf.

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

[Johannes Schauer]

Hi Daniel,

after staring at the log output for a while longer, I now have a theory:

Quoting Johannes Schauer (2019-02-28 00:11:42)
> > Get:1 http://deb.debian.org/debian sid InRelease [242 kB]
> > Get:2 http://deb.debian.org/debian sid/main amd64 Packages [8366 kB]
> > Fetched 8608 kB in 2s (4984 kB/s)
> > Reading package lists...
> > W: Download is performed unsandboxed as root as file
> > '/root/sid/var/lib/apt/lists/partial/deb.debian.org_debian_dists_sid_InRelease'
> > couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission
> > denied)
> > apt-get update failed at /usr/bin/mmdebstrap line 569.

You probably have the permissions of /root set up such that it's non-readable
by any non-root user?

This would explain the error message because it would not allow the _apt user
to perform any operation in any subdirectory of /root including your chroot
directory.

Can you confirm that mmdebstrap root mode works if you are putting your chroot
directory somewhere where also non-root users have read permissions?

That would also mean that this is not a new problem but one that always has
existed. You probably not attempted to put the chroot into /root before you
upgraded to version 0.4.0?

You could also test if disabling the apt sandboxing feature fixes the problem
for you by adding the following option to mmdebstrap:

--aptopt='APT::Sandbox::User "root"'

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#915559: bug#34681: mv fails when renaming on external drive in coreutils 8.30-2

[Pádraig Brady]

On 27/02/19 14:20, Derek Dongray wrote:
> When trying to use mv to rename a file on an external drive using coreutils
> 8.30-2 on a debian system (Linux version 4.19.0-3-amd64), the rename fails
> with the error message:
> 
> mv: cannot move 'file1' to a subdirectory of itself 'file2'
> 
> Downgrading to coreutils 8.30-1, the rename executes as expected.
> 
> The following is the result of running a test script. The folder '/backup'
> is an external drive using the ZFS fileystems (zfs-zed 0.7.12-3), but I
> have seen a report on superuser.com (
> https://superuser.com/questions/1409618/renaming-a-file-with-mv-cannot-move-to-a-subdirectory-of-itself)
> that this also happens with NTFS external drives.
> 
> root@capella:~# ./mv-bug
> + apt install -y --allow-downgrades coreutils=8.30-1
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> coreutils is already the newest version (8.30-1).
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> + cd /backup
> + touch t
> + ls s t
> ls: cannot access 's': No such file or directory
> t
> + mv t s
> + ls s t
> ls: cannot access 't': No such file or directory
> s
> + rm s t
> rm: cannot remove 't': No such file or directory
> + cd /root
> + apt install -y coreutils=8.30-2
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages will be upgraded:
>   coreutils
> 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 2,707 kB of archives.
> After this operation, 4,096 B disk space will be freed.
> Get:1 http://ftp.uk.debian.org/debian sid/main amd64 coreutils amd64 8.30-2
> [2,707 kB]
> Fetched 2,707 kB in 1s (2,729 kB/s)
> apt-listchanges: Reading changelogs...
> (Reading database ... 226704 files and directories currently installed.)
> Preparing to unpack .../coreutils_8.30-2_amd64.deb ...
> Unpacking coreutils (8.30-2) over (8.30-1) ...
> Setting up coreutils (8.30-2) ...
> Processing triggers for install-info (6.5.0.dfsg.1-4+b1) ...
> Processing triggers for man-db (2.8.5-2) ...
> + cd /backup
> + touch t
> + ls s t
> ls: cannot access 's': No such file or directory
> t
> + mv t s
> mv: cannot move 't' to a subdirectory of itself, 's'
> + ls s t
> ls: cannot access 's': No such file or directory
> t
> + rm s t
> rm: cannot remove 's': No such file or directory
> root@capella:~#

That sounds like unsupported renameat2()
is not falling back to rename()

The only change in debian is:
  coreutils (8.30-2) unstable; urgency=medium
* Use renameat glibc function that can be intercepted by fakechroot
  (Closes: https://bugs.debian.org/915559 )
* Above requires autoreconf turned on again

A quick scan of the patches shows that the name was changed
to renameatu() in gnulib, but copy.c still calls renameat2()
and thus now doesn't have the fallback.

To be clear this seems to only be an issue in the debian patch.

cheers,
Pádraig

Bug#923429: texlive-lang-french: Upgrading the package uninstalls it.

[Nicolas Patrois]

Package: texlive-lang-french
Severity: important

Dear Maintainer,

For some reason, upgrading this package (and some others from texlive)
uninstalls it.



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

Kernel: Linux 4.17.0-3-686-pae (SMP w/3 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages texlive-lang-french depends on:
it  tex-common6.10
ii  texlive-base  2018.20190207-1

texlive-lang-french recommends no packages.

texlive-lang-french suggests no packages.

Bug#923428: fastqc fails it's autopkg tests

[Matthias Klose]

Package: src:fastqc
Version: 0.11.8+dfsg-1
Severity: important
Tags: sid buster

fastqc fails it's autopkg tests according to
https://ci.debian.net/data/packages/unstable/amd64/f/fastqc/latest-autopkgtest/log.gz

ailed to process toy.sam
htsjdk.samtools.util.RuntimeIOException: java.io.IOException: Stream closed
at
htsjdk.samtools.SamReaderFactory$SamReaderFactoryImpl.open(SamReaderFactory.java:448)
at uk.ac.babraham.FastQC.Sequence.BAMFile.(BAMFile.java:64)
at
uk.ac.babraham.FastQC.Sequence.SequenceFactory.getSequenceFile(SequenceFactory.java:100)
at
uk.ac.babraham.FastQC.Sequence.SequenceFactory.getSequenceFile(SequenceFactory.java:62)
at 
uk.ac.babraham.FastQC.Analysis.OfflineRunner.processFile(OfflineRunner.java:152)
at 
uk.ac.babraham.FastQC.Analysis.OfflineRunner.(OfflineRunner.java:121)
at 
uk.ac.babraham.FastQC.FastQCApplication.main(FastQCApplication.java:316)
Caused by: java.io.IOException: Stream closed
at 
java.base/java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:165)
at 
java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
at 
java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:292)
at 
java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:351)
at
htsjdk.samtools.util.BlockCompressedInputStream.readBytes(BlockCompressedInputStream.java:583)
at
htsjdk.samtools.util.BlockCompressedInputStream.isValidFile(BlockCompressedInputStream.java:443)
at htsjdk.samtools.SamStreams.isBAMFile(SamStreams.java:51)
at
htsjdk.samtools.SamReaderFactory$SamReaderFactoryImpl.open(SamReaderFactory.java:374)
... 6 more
autopkgtest [08:36:51]: test run-unit-test: ---]
autopkgtest [08:36:51]: test run-unit-test:  - - - - - - - - - - results - - - -
- - - - - -
run-unit-testFAIL non-zero exit status 1
autopkgtest [08:36:51]:  summary

Bug#923249: [Pkg-libvirt-maintainers] Bug#923249: libvirt0: libvirt sets disable_ipv6 on bridge, entirely breaking internal IPv6 networking

[Guido Günther]

Hi,
On Wed, Feb 27, 2019 at 10:08:24PM +0100, Ralf Jung wrote:
> Btw, I reported this upstream at
> , and made some headway
> debugging things there.

Cool, thanks!
 -- Guido

Bug#923427: mergechanges: Regression: --indep/source mangles/breaks (valid?) Binary fields

[Salvatore Bonaccorso]

Package: devscripts
Version: 2.19.3
Severity: serious
Justification: regression

Hi

Not sure on the severity, but better safe than sorry, please downgrade
as needed or see it fitting better.

I had prepared an upload where I issued mergechanges --indep on the
_amd64.changes to produce a changes to include only source packages
and architecture-independent packages.

$ mergechanges --indep -f linux_4.9.161-1_amd64.changes 
linux_4.9.161-1_amd64.changes 
Error: acpi-modules-4.9.0-9-amd64-di not found in Binary field  
 
b4ae0b22174cb1c7bf009bfcf0deaee8 10304 debian-installer extra 
acpi-modules-4.9.0-9-amd64-di_4.9.161-1_amd64.udeb

This seems related to the change included in the 2.19.3 version, as
the version in stretch creates the _multi.changes correctly.

I'm attaching the original amd64.changes, plus the multi.changes
produced with 2.17.6+deb9u2 and the multi.changes.broken produced with
(2.19.3).

Regards,
Salvatore


linux_4.9.161-1_amd64.changes.xz
Description: application/xz


linux_4.9.161-1_multi.changes.xz
Description: application/xz


linux_4.9.161-1_multi.changes.broken.xz
Description: application/xz

Bug#923210: bash-completion: postinst and postrm generate find warnings

[Daniel Lewart]

Gabriel,

> > Both "apt install bash-completion" and "apt purge bash-completion"
> > generate the following warning:
> >   find: '/etc/bash_completion.d/': No such file or directory

> > The cause is that postinst and postrm assume that
> > /etc/bash_completion.d exists.

> Is it safe to upload such a change so close to the freeze?  I'm always
> worried about unforeseen side-effects.

The patch might be easier to understand by ignoring indentation:

diff -br a/debian/postinst b/debian/postinst
6a7
> if [ -d /etc/bash_completion.d ]; then
19a21
> fi
diff -br a/debian/postrm b/debian/postrm
7a8
> if [ -d /etc/bash_completion.d ]; then
11a13
> fi

I think it is safe, but I defer to you.

> ...
> Is this hunk needed?  The test (-d /etc/bash_completion.d/helpers) is
> not likely to produce the warnings you mentioned.

Absolutely.  The warnings come from the following line in both
post{inst,rm}:
for f in $(find /etc/bash_completion.d/ -type f -name "*.dpkg-*");
do

Thank you!
Dam

Bug#923426: pal FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: pal
Version: 0.4.3-8.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

pal fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that - using dh_auto_build -
does not fix that entirely, because the upstream Makefile hard codes the
build architecture pkg-config. The attached patch makes pal cross
buildable. Please consider applying it.

Helmut
diff -u pal-0.4.3/debian/changelog pal-0.4.3/debian/changelog
--- pal-0.4.3/debian/changelog
+++ pal-0.4.3/debian/changelog
@@ -1,3 +1,12 @@
+pal (0.4.3-8.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make pkg-config substitutable.
++ Let dh_auto_build pass cross tools to make.
+
+ -- Helmut Grohne   Wed, 27 Feb 2019 18:57:54 +0100
+
 pal (0.4.3-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u pal-0.4.3/debian/patches/series pal-0.4.3/debian/patches/series
--- pal-0.4.3/debian/patches/series
+++ pal-0.4.3/debian/patches/series
@@ -11,0 +12 @@
+cross.patch
diff -u pal-0.4.3/debian/rules pal-0.4.3/debian/rules
--- pal-0.4.3/debian/rules
+++ pal-0.4.3/debian/rules
@@ -24,7 +24,7 @@
 build-arch: build-stamp
 build-stamp: $(QUILT_STAMPFN)
dh_testdir
-   $(MAKE) "CFLAGS=$(CFLAGS)"
+   dh_auto_build -- "CFLAGS=$(CFLAGS)"
touch $@
 
 .PHONY: clean
--- pal-0.4.3.orig/debian/patches/cross.patch
+++ pal-0.4.3/debian/patches/cross.patch
@@ -0,0 +1,24 @@
+--- pal-0.4.3.orig/src/Makefile
 pal-0.4.3/src/Makefile
+@@ -2,9 +2,9 @@
+ 
+ include Makefile.defs
+ 
+-INCLDIR = -I${prefix}/include `pkg-config --cflags glib-2.0`
++INCLDIR = -I${prefix}/include `$(PKG_CONFIG) --cflags glib-2.0`
+ LIBDIR  =
+-LIBS= `pkg-config --libs glib-2.0` -lreadline -lncursesw
++LIBS= `$(PKG_CONFIG) --libs glib-2.0` -lreadline -lncursesw
+ 
+ SRC = main.c colorize.c output.c input.c event.c rl.c html.c latex.c \
+   add.c edit.c del.c remind.c search.c manage.c
+--- pal-0.4.3.orig/src/Makefile.defs
 pal-0.4.3/src/Makefile.defs
+@@ -5,6 +5,7 @@
+ # want to change this to /usr/local
+ prefix = /usr
+ CC  = gcc
++PKG_CONFIG ?= pkg-config
+ 
+ PAL_VERSION = 0.4.3
+ 

Bug#923417: pspp: CVE-2019-9211

[Ben Pfaff]

On Wed, Feb 27, 2019 at 10:31:58PM +0100, Salvatore Bonaccorso wrote:
> Source: pspp
> Version: 1.2.0-2
> Severity: normal
> Tags: security upstream
> 
> Hi,
> 
> The following vulnerability was published for pspp.
> 
> CVE-2019-9211[0]:
> | There is a reachable assertion abort in the function
> | write_long_string_missing_values() in data/sys-file-writer.c in
> | libdata.a in GNU PSPP 1.2.0 that will lead to denial of service.

I fixed this on PSPP master with commit 0b842a843537 ("sys-file-writer:
Remove assertions based on file position.").

As has become usual, this bug was reported to Debian and Red Hat and
MITRE and never to me, the upstream author.  If you know any way to
de-anonymize whoever is actually finding these bugs, I'd appreciate it.
Whoever it is deserves education.

Bug#923425: Chase gives incorrect file path

[Nick Taylor]

Package: chase
Version: 0.5.2


When the link is in a different folder than the target file, the
resultant path to the target file given by chase turns out to be incorrect.
Here is a transcript:

In this example, the files are located in the folder 
/media/MyBook/Hostshare/GIFS
The links are located in the folder  /media/MyBook/Hostshare/GIFS

cd /media/MyBook/Hostshare/GIFS/GIFLINKS
/media/MyBook/Hostshare/GIFS/GIFLINKS$ chase achtagDu6Blo
chase: /media/MyBook/Hostshare/GIFS/GIFLINKS/IJa7b9jy.gif: No such file or 
directory

The filename IJa7b9jy.gif does exist in the folder 
/media/MyBook/Hostshare/GIFS, but
not in  /media/MyBook/Hostshare/GIFS/GIFLINKS

I am using Debian GNU/Linux 9.7 (stretch) kernel 4.9.0-8-amd64 and (Debian 
GLIBC 2.24-11+deb9u3) 2.24




 

Bug#923423: texlive-fonts-extra installation hangs

[Norbert Preining]

reassign 923423 dpkg
thanks

On Thu, 28 Feb 2019, Vincent Lefevre wrote:
> It eventually resumed. In the /var/log/dpkg.log file:
> 
> [...]
> 2019-02-28 00:49:41 install texlive-bibtex-extra:all 2018.20190207-1 
> 2018.20190227-1
> 2019-02-28 00:49:41 status half-installed texlive-bibtex-extra:all 
> 2018.20190207-1
> 2019-02-28 00:50:27 status unpacked texlive-bibtex-extra:all 2018.20190227-1

Nothing I can do about it, please ask dpkg maintainers what is going on.

Norbert

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

Bug#923424: Build yafaray with qt5

[Alexey Loginov]

Package: yafaray
Version: yafaray_0.1.2+really0.1.2~beta5-2

There is qt5: https://github.com/YafaRay/Core

Bug#904111: Susan picked You!!

[Lina Nageb Mohammed Fewella]

From: Lina Nageb Mohammed Fewella
Sent: Thursday, February 28, 2019 4:02 AM
To: i...@mail.com
Subject: Susan picked You!!

Mrs Susan picked you Reply To 
mrssusan...@gmail.com  for more details

Bug#919628: Apply Julia's LLVM patches

[Mo Zhou]

Hi Sylvestre,

Should I file freeze exception requests against llvm-6.0 and julia,
so that we will have some more time to work on this?

On Fri, Feb 22, 2019 at 08:41:14AM +0100, Sylvestre Ledru wrote:
> Hello,
> 
> I started the work ( 
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/408f329cd84ad41cef7fc41ee4ac2b4b4573945f
> ) on that but:
> 
> * some patches didn't apply
> 
> * some are breaking the builds
> 
> I will try to finish this week end
> 
> Anyway, this should not prevent you to move back to llvm packages as
> 
> I took this fix  "Fix a baseline violation on armhf (Closes: #914268)"
> 
> Cheers,
> 
> S
> 
> 
> Le 22/02/2019 à 00:55, Mo Zhou a écrit :
> > Hi Sylvestre,
> > 
> > Any chance for getting this into Buster? If there is any, I'd like
> > to apply for freeze exception early, especially for the next Julia
> > LTS release 1.0.4 (likely to come out before 1st March)
> > 
> > On Fri, Feb 08, 2019 at 08:46:06AM +0100, Sylvestre Ledru wrote:
> > > Wahou, better than I was expecting! Many thanks!
> > > 
> > > I will take as much as possible! Thanks
> > > 
> > > S
> > > 
> > > 
> > > Le 08/02/2019 à 07:47, Mo Zhou a écrit :
> > > > Hi Sylvestre,
> > > > 
> > > > Please cherry-pick at least: (8) (12) (13) (14) (15)
> > > > 
> > > > Recommended to include: (1) (2) (4) (5) (11)
> > > > 
> > > > Feel free to ignore: (6) (9) (16) (17)
> > > > 
> > > > I have no idea about: (3) (7) (10)
> > > > 
> > > > https://github.com/JuliaLang/julia/tree/master/deps/patches
> > > > I've listed patches for llvm 6.0.1
> > > > 
> > > > 
> > > > 
> > > > 
> > > > (1) [unwind] llvm-D27629-AArch64-large_model_6.0.1
> > > > 
> > > >   Fix unwind info relocation with large code model on AArch64
> > > >   https://reviews.llvm.org/D27629
> > > > 
> > > > (2) [performance] llvm-D34078-vectorize-fdiv
> > > > 
> > > >   Enable support for floating-point division reductions
> > > >   https://reviews.llvm.org/D34078
> > > > 
> > > > (3) [nvptx] llvm-6.0-NVPTX-addrspaces
> > > > 
> > > >   No idea about this patch.
> > > > 
> > > > (4) [performance regression] llvm-D42262-jumpthreading-not-i1
> > > > 
> > > >   For details see Julia commit: 
> > > > e94a1f8b08e0bc3b8093d8f1dc2bf3c8f5d59519
> > > >   merged upstream: https://reviews.llvm.org/D42262
> > > > 
> > > > (5) [???] llvm-PPC-addrspaces
> > > > 
> > > >   merged upstream: https://reviews.llvm.org/D43781
> > > > 
> > > > (6) [ignore: mingw] llvm-6.0.0_D27296-libssp
> > > >   [ignore: mingw] llvm-6.0-D44650
> > > > 
> > > > (7) [???] llvm-D46460
> > > > 
> > > >   still under review: https://reviews.llvm.org/D46460
> > > > 
> > > > (8) [???] llvm-rL327898
> > > > 
> > > >   
> > > > https://github.com/JuliaLang/julia/blob/master/deps/patches/llvm-rL327898.patch
> > > >   Fixes Julia issues: #27055 #27080 #27032 #27603
> > > > 
> > > > (9) [ignore: compiler complain] llvm-6.0-DISABLE_ABI_CHECKS
> > > > 
> > > > (10) [profiling] llvm-OProfile-line-num
> > > > 
> > > > (11) [profiling] llvm-D44892-Perf-integration
> > > > 
> > > >merged upstream: https://reviews.llvm.org/D44892
> > > > 
> > > > (12) [bug fix] llvm-D49832-SCEVPred
> > > >[bug fix] llvm-rL323946-LSRTy
> > > > 
> > > >   Add LLVM patches for bugs introducing illegal ptrtoint
> > > >   rL323946 [LSR] Don't force bases of foldable formulae to the 
> > > > final type.
> > > >   D49832   [SCEV] Don't expand Wrap predicate using inttoptr in ni 
> > > > addrspaces
> > > > 
> > > > (13) llvm-D50010-VNCoercion-ni
> > > > 
> > > >   Fixes julia issue: #28360 (#28362)
> > > >   https://reviews.llvm.org/D50010
> > > > 
> > > > (14) llvm-D50167-scev-umin
> > > > 
> > > >   Add LLVM patch to explicitly represent umin in SCEV (#28403)
> > > >   Fix mix-type arithmetic detection in umin/max expansion (#28465)
> > > >   Fixes #28464
> > > >   Fixes #28379
> > > >   Fixes #28388
> > > > 
> > > > (15) llvm-rL326967-aligned-load
> > > > 
> > > >   Fixes incorrect codegen: #28726
> > > > 
> > > > (16) [ignore: win64] llvm-D51842-win64-byval-cc
> > > > 
> > > > (17) [...] llvm-D57118-powerpc
> > > > 
> > > >   https://reviews.llvm.org/D57118
> > > > 

Bug#921600: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Arnaud Rebillout]

On Thu, 7 Feb 2019 23:42:32 + "brian m. carlson"
 wrote:
>
> Moreover, this package probably needs to conflict with the new iptables
> package, since it cannot usefully work in conjunction with it.

>From what I see, the iptables package provides both iptables-legacy and
iptables-nft. The docker.io packages depends on iptables for
iptables-legacy (but can't work with iptables-nft). So we can't add a
conflict in this case, unless I miss something?

However there's also the nftables packages, and if I understand you
correctly we should add a conflict with nftables?

And then again, that wouldn't help in your situation, as the package ufw
you mention depends on iptables, not on nftables.

  Arnaud

Bug#919590: RFS: openliberty/18.0.0.4 [ITP]

[Michael Zhang]

Hi,

>From the last email, changes such as:
"Long description is missing. Short description far exceeds 80 chars.
source/format being "3.0 (native)" is also questionable."

were requested and have been corrected. As for the unacceptable lines in d/rules, we are currently in the midst of changing the build process to include the creation of the binaries (ex. *.jar).

I've also modified my package openliberty:

 * Package name: openliberty
   Version : 19.0.0.1-1ubuntu1
   Upstream Author : https://groups.io/g/openliberty
 * URL : https://openliberty.io/
 * License : EPL-1.0
   Section : java

  It builds those binary packages:

openliberty - Server runtime for Java developers

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/o/openliberty/openliberty_19.0.0.1-1ubuntu1.dsc
  More information about openliberty can be obtained from https://www.example.com.

  Changes since the last upload:

  openliberty (19.0.0.1-1ubuntu1) unstable; urgency=medium

  * Fixed many lintian errors and warnings
  * Added template argument in 'create' script
  * Added java weak dependency
  * Added SystemD service files for instance servers

 -- Michael Zhang   Mon, 25 Feb 2019 22:38:40 +
We are currently looking into the debian policy manuals and lintian errors for more improvements on our package. We also appreciate any more constructive criticism to help us get this package up-to-standard for the Debian repository.Yours Sincerely,

 
  Michael Zhang
   Software Developer Test (WAS Install Team)
 Phone: 1-9054133415
 E-mail: michael.zh...@ibm.com
 

 

Bug#923423: texlive-fonts-extra installation hangs

[Vincent Lefevre]

Control: severity -1 important
Control: retitle -1 texlive-fonts-extra installation hangs for 19 minutes

On 2019-02-28 01:06:28 +0100, Vincent Lefevre wrote:
> Package: texlive-fonts-extra
> Version: 2018.20190227-1
> Severity: serious
> 
> Installation of texlive-fonts-extra 2018.20190227-1 hangs.
[...]

It eventually resumed. In the /var/log/dpkg.log file:

[...]
2019-02-28 00:49:41 install texlive-bibtex-extra:all 2018.20190207-1 
2018.20190227-1
2019-02-28 00:49:41 status half-installed texlive-bibtex-extra:all 
2018.20190207-1
2019-02-28 00:50:27 status unpacked texlive-bibtex-extra:all 2018.20190227-1
2019-02-28 00:50:27 install texlive-extra-utils:all 2018.20190207-1 
2018.20190227-1
2019-02-28 00:50:27 status half-installed texlive-extra-utils:all 
2018.20190207-1
2019-02-28 00:50:55 status unpacked texlive-extra-utils:all 2018.20190227-1
2019-02-28 00:50:55 install texlive-font-utils:all 2018.20190207-1 
2018.20190227-1
2019-02-28 00:50:55 status half-installed texlive-font-utils:all 2018.20190207-1
2019-02-28 00:51:00 status unpacked texlive-font-utils:all 2018.20190227-1
2019-02-28 00:51:01 install texlive-fonts-extra:all 2018.20190207-1 
2018.20190227-1
2019-02-28 00:51:01 status half-installed texlive-fonts-extra:all 
2018.20190207-1
2019-02-28 01:10:50 status unpacked texlive-fonts-extra:all 2018.20190227-1
2019-02-28 01:10:50 install texlive-fonts-recommended:all 2018.20190207-1 
2018.20190227-1
2019-02-28 01:10:50 status half-installed texlive-fonts-recommended:all 
2018.20190207-1
2019-02-28 01:11:49 status unpacked texlive-fonts-recommended:all 
2018.20190227-1
[...]

So that's about 19 minutes with almost no CPU/disk/network activity.

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

Bug#921889: debian-policy: recommends an old version of libjs-sphinxdoc

[Sean Whitton]

Hello Gabriele,

On Wed 27 Feb 2019 at 10:56PM +01, Gabriele Stilli wrote:

> unfortunately the bug showed again when the latest libjs-sphinxdoc
> 1.8.4-1 entered buster.
>
> (debian-policy now Recommends: libjs-sphinxdoc (< 1.8.3.0~))
>
> Not sure we want to undergo all this at every sphinx version bump :-)

Once #658238 is resolved, it won't be necessary.  See comments in
debian-policy's d/rules.

I've made another upload.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#923423: texlive-fonts-extra installation hangs

[Vincent Lefevre]

Package: texlive-fonts-extra
Version: 2018.20190227-1
Severity: serious

Installation of texlive-fonts-extra 2018.20190227-1 hangs.

Here's px information:

# px 5553
/usr/bin/dpkg
  --status-fd
  80
  --no-triggers
  --unpack
  --auto-deconfigure
  --recursive
  /tmp/apt-dpkg-install-mos7uq

kernel(0) root
  init(1) root
lightdm(915)  root
  lightdm(1525)   root
zsh(1547) vinc17
  fvwm2(1629) vinc17
sh(1745)  vinc17
  xterm(1746) vinc17
zsh(1750) vinc17
  su(1839)root
bash(1841)root
  aptitude(2012)  root
--> dpkg(5553)root

17m01s ago dpkg was started, at 2019-02-28T00:48:45+01:00.
1.5% has been its average CPU usage since then, or 15s/17m01s

Other processes started close to dpkg(5553):
  [kworker/0:1-events](5351) was started 2m57s before dpkg(5553)
  [kworker/u17:0-kcryptd](5540) was started 1.0s before dpkg(5553)
  [kworker/4:2](5771) was started 2m19s after dpkg(5553)
  [kworker/u16:1-events_unbound](5928) was started 4m21s after dpkg(5553)
  [kworker/5:2-mm_percpu_wq](6068) was started 5m06s after dpkg(5553)

Users logged in when dpkg(5553) started:
  vinc17 from 155.133.131.76
  vinc17 from :0

2019-02-28T01:05:46.585799: Now invoking lsof, this can take over a minute on a 
big system...
2019-02-28T01:05:47.098503: lsof done, proceeding.

File descriptors:
  stdin : [CHR] /dev/pts/16
  stdout: [CHR] /dev/pts/16
  stderr: [CHR] /dev/pts/16

Network connections:

Inter Process Communication:
  aptitude(2012): [FIFO] pipe

For a list of all open files, do "sudo lsof -p 5553", or "sudo watch lsof -p 
5553" for a live view.

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

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

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

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

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

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

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

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

or 

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

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2880 2019-02-27 03:14:07 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2018-09-02 14:32:33 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2019-02-27 01:08:59 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2019-02-27 01:08:59 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2018-09-02 20:20:53 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2019-02-27 01:08:59 
/usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2019-02-27 01:08:59 /usr/share/texmf/web2c/updmap.cfg 
-> /var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5089 2019-02-27 03:13:40 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2014-10-21 02:46:09 mktex.cnf
-rw-r--r-- 1 root root 475 2018-09-02 20:20:53 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Bug#923422: psmisc: pstree segfault with threads (patch included)

[Charles Samuels]

Package: psmisc 
Version: 22.21-2.1+b2 
Severity: normal

Dear Maintainer,

When I run pstree on my busy servers, it usually SIGSEGVs before outputting
anything.

This is because pstree is calling `fclose(f)` on an `f` that may 
be null, which is not permitted:

   The behaviour of fclose() is undefined if the stream parameter is
   an illegal pointer, or is  a  descriptor  already
   passed to a previous invocation of fclose().

(quoting man fclose)

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/64 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 psmisc depends on:
ii  libc62.24-11+deb9u3
ii  libselinux1  2.6-3+b3
ii  libtinfo56.0+20161126-1+deb9u2

psmisc recommends no packages.

psmisc suggests no packages.

-- no debconf informationdiff -ur psmisc-22.21/src/pstree.c psmisc-22.21-fixed/src/pstree.c
--- psmisc-22.21/src/pstree.c	2014-02-02 05:59:07.0 +
+++ psmisc-22.21-fixed/src/pstree.c	2019-02-27 23:19:40.611866628 +
@@ -819,7 +819,9 @@
 }
 /* Fall back to old method */
 sprintf(threadname, "{%.*s}", COMM_LEN, comm);
-fclose(file);
+if (file) { 
+fclose(file);
+}
 return threadname;
 }

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

[Johannes Schauer]

Hi Daniel,

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

hrm... this is odd.

The commandline you quote works fine for me and a very similar one runs fine in
the qemu testsuite and CI. The former executes mmdebstrap as root in a qemu
virtual machine and the latter directly on the host. Both evidently work fine:

https://ci.debian.net/packages/m/mmdebstrap/

Could you try to reproduce the error inside a minimal chroot? Currently, I'm
not able to reproduce it.

What you tried should indeed 'just work'[tm]. Something is broken.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#910902: Please test again: my_print_defaults and Akonadi for a freash installation

[Otto Kekäläinen]

Looks like this has never been in the core package:

https://packages.debian.org/search?searchon=contents=resolveip=path=unstable=any
/usr/bin/resolveipmariadb-server-10.0 [arm64], mariadb-server-10.1
[powerpc], mariadb-server-10.3 [ei ia64, powerpc, s390, sparc],
mariadb-server-5.5 [sparc, arm64], mysql-server-5.5 [sparc, ia64,
s390, arm64], mysql-server-5.7 [ei hurd-i386, ia64, kfreebsd-i386,
s390, sparc, sparc64], percona-xtradb-cluster-server-5.5 [sparc,
arm64]

Moving the file requires some consideration for backwards
compatibility etc. Would you like to take a look at this and try to
come up with a solution?

See https://wiki.debian.org/Teams/MySQL/patches on how to use Salsa-CI
to test and submit patches.

Bug#923210: bash-completion: postinst and postrm generate find warnings

[Gabriel F. T. Gomes]

On Sun, Feb 24 2019, Daniel Lewart wrote:
> Package: bash-completion
> Version: 1:2.8-5
> Severity: minor
> Tags: patch
> 
> Both "apt install bash-completion" and "apt purge bash-completion"
> generate the following warning:
>   find: '/etc/bash_completion.d/': No such file or directory
> 
> The cause is that postinst and postrm assume that
> /etc/bash_completion.d exists.
> 
> Patch is attached.

Thanks.

I have a comment about a hunk in the patch and a question, here:

Is it safe to upload such a change so close to the freeze?  I'm always
worried about unforeseen side-effects.

> diff -ru a/debian/postinst b/debian/postinst
> --- a/debian/postinst 2018-12-21 19:23:09.0 -0600
> +++ b/debian/postinst 2019-02-24 00:00:00.0 -0600
> @@ -4,19 +4,21 @@
>  
>  case "$1" in
>  configure)
> -# let's remove old bash-completion conffiles
> -for f in $(find /etc/bash_completion.d/ -type f -name "*.dpkg-*"); do
> -dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- "$@"
> -done
> +if [ -d /etc/bash_completion.d ]; then
> +# let's remove old bash-completion conffiles
> +for f in $(find /etc/bash_completion.d/ -type f -name 
> "*.dpkg-*"); do
> +dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- 
> "$@"
> +done

OK.

> -if dpkg --compare-versions "$2" le "1:2.1-3"; then
> -if [ -d /etc/bash_completion.d/helpers ]; then
> -rmdir --ignore-fail-on-non-empty 
> /etc/bash_completion.d/helpers 2>/dev/null
> +if dpkg --compare-versions "$2" le "1:2.1-3"; then
> +if [ -d /etc/bash_completion.d/helpers ]; then
> +rmdir --ignore-fail-on-non-empty 
> /etc/bash_completion.d/helpers 2>/dev/null
> +fi
> +# disabled from Ubuntu, third party packages might have 
> installed things here
> +#if [ -d /etc/bash_completion.d ]; then
> +#rmdir --ignore-fail-on-non-empty /etc/bash_completion.d 
> 2>/dev/null
> +#fi
>  fi
> -# disabled from Ubuntu, third party packages might have 
> installed things here
> -#if [ -d /etc/bash_completion.d ]; then
> -#rmdir --ignore-fail-on-non-empty /etc/bash_completion.d 
> 2>/dev/null
> -#fi
>  fi
>   ;;
>  abort-upgrade|abort-remove|abort-deconfigure)

Is this hunk needed?  The test (-d /etc/bash_completion.d/helpers) is
not likely to produce the warnings you mentioned.

> diff -ru a/debian/postrm b/debian/postrm
> --- a/debian/postrm   2018-12-21 19:23:09.0 -0600
> +++ b/debian/postrm   2019-02-24 00:00:00.0 -0600
> @@ -5,10 +5,12 @@
>  case "$1" in
>  purge)
>   rm -f /etc/bash_completion
> -# let's remove old bash-completion conffiles
> -for f in $(find /etc/bash_completion.d/ -type f -name "*.dpkg-*"); do
> -dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- "$@"
> -done
> + if [ -d /etc/bash_completion.d ]; then
> +# let's remove old bash-completion conffiles
> +for f in $(find /etc/bash_completion.d/ -type f -name 
> "*.dpkg-*"); do
> +dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- 
> "$@"
> +done
> + fi
>   ;;
>  remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
>   ;;

OK.

Bug#923418: Introduces spurious whitespace after parentheses

[Martin Michlmayr]

* John MacFarlane  [2019-02-27 14:15]:
> This looks like
> 
> https://github.com/jgm/pandoc/issues/4635
> 
> which is fixed in recent versions nof pandoc.
> 2.2.2+

Yeah, sounds like it.

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#923420: coreutils: mv broken when file system doesn't support RENAME_NOREPLACE

[Johannes Schauer]

Hi Felix,

Quoting Felix Geyer (2019-02-27 23:16:15)
> With those distro patches from version 8.30-2 mv fails on filesystems that 
> don't
> support the renameat2 RENAME_NOREPLACE flag.
> I noticed this because coreutils 8.30-2 breaks autopkgtest with the qemu 
> runner
> which calls mv on a 9p filesystem.
> 
> renameatu.patch is the offender as it only changes renameat2() calls to 
> renameatu()
> in lib/ but not in src/.
> As a result some tools call the glibc renameat2() instead of the gnulib one 
> which
> has appropriate fallbacks.
> I haven't checked what other tools are exactly affected (calls are in mv.c, 
> shred.c
> and copy.c).
> 
> After an extended debugging session,

wow, that must've been a "fun" session until you figured out what was wrong!

Unfortunately, I'm still on holidays until March 3, so I cannot look into the
situation before then due to very limited internet access in the Swedish
mountains.

I'm sorry I missed this issue my patch created on filesystems that don't
support the RENAME_NOREPLACE flag. :(

cheers, josch


signature.asc
Description: signature

Bug#920519: ITA: mtx -- controls tape autochangers

[Carsten Leonhardt]

Control: retitle -1 ITA: mtx -- controls tape autochangers

I'm going to adopt mtx, probably as part of the Bacula packaging team.

Bug#923420: coreutils: mv broken when file system doesn't support RENAME_NOREPLACE

[Felix Geyer]

Package: coreutils
Version: 8.30-2
Severity: serious

Hi,

With those distro patches from version 8.30-2 mv fails on filesystems that don't
support the renameat2 RENAME_NOREPLACE flag.
I noticed this because coreutils 8.30-2 breaks autopkgtest with the qemu runner
which calls mv on a 9p filesystem.

renameatu.patch is the offender as it only changes renameat2() calls to 
renameatu()
in lib/ but not in src/.
As a result some tools call the glibc renameat2() instead of the gnulib one 
which
has appropriate fallbacks.
I haven't checked what other tools are exactly affected (calls are in mv.c, 
shred.c
and copy.c).

After an extended debugging session,
Felix

Bug#923421: start-stop-daemon: matching only on non-root pidfile /run/sogo/sogo.pid is insecure

[Niels Nowatzki]

Package: sogo
Version: 4.0.5-3
Severity: important

Dear Maintainer,

i just ran in a problem which was already reported on other packages (#921557 
and #921016).
When i try to restart or stop sogod the initscript throws an error message as 
seen in the subject
and ceases to operate.

The attached patch resembles the solution of #921016 and works for me.

In other notes: The severity should probably really be "serious", but i could 
not easily find out 
how to feed it to the BTS.

Thanks for your good work,
niels
 

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages sogo depends on:
ii  adduser   3.118
ii  gnustep-base-runtime  1.26.0-4
ii  libc6 2.28-7
ii  libcurl3-gnutls   7.64.0-1
ii  libgcc1   1:8.2.0-21
ii  libglib2.0-0  2.58.3-1
ii  libgnustep-base1.26   1.26.0-4
ii  libgnutls30   3.6.6-2
ii  liblasso3 2.6.0-2+b2
ii  libmemcached111.0.18-4.2
ii  libobjc4  8.2.0-21
ii  libsbjson2.3  2.3.2-4+b1
ii  libsope1  4.0.5-2
ii  lsb-base  10.2018112800
ii  memcached 1.5.6-1
ii  sogo-common   4.0.5-3
ii  tmpreaper 1.6.14
ii  zip   3.0-11+b1

sogo recommends no packages.

Versions of packages sogo suggests:
pn  postgresql | default-mysql-server | virtual-mysql-server  

-- Configuration Files:
/etc/init.d/sogo changed [not included]
/etc/sogo/sogo.conf [not included] 

-- no debconf information
diff -u orig/debian/sogo.init patch/debian/sogo.init
--- orig/debian/sogo.init   2019-02-27 22:13:00.809760064 +0100
+++ patch/debian/sogo.init  2019-02-27 22:17:41.581975621 +0100
@@ -74,12 +74,12 @@
;;
   stop)
log_daemon_msg "Stopping $DESC" "$NAME"
-   start-stop-daemon --stop --oknodo --pidfile $PIDFILE 
--retry=TERM/20/KILL/5
+   start-stop-daemon --stop --oknodo --pidfile $PIDFILE 
--retry=TERM/20/KILL/5 --user $USER
log_end_msg 0
;;
   restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME"
-   start-stop-daemon --stop --oknodo --pidfile $PIDFILE 
--retry=TERM/20/KILL/5
+   start-stop-daemon --stop --oknodo --pidfile $PIDFILE 
--retry=TERM/20/KILL/5 --user $USER
 # Ensure run directory's existence and permissions
if [ ! -d /run/sogo ]; then
 install -o $USER -g $GROUP -d /run/sogo

Bug#910902: Please test again: my_print_defaults and Akonadi for a freash installation

[Sandro Knauß]

Control: tags -1 -moreinfo
Control: retitle -1 resolveip is missing for a fresh installation of Akonadi

Hey,

Okay I made the initial test late December and checked against 10.1. I now 
checked again and you are right my_print_defaults is now found in the -core 
package.

Bit this the command is not successfully:
 "/usr/bin/mysql_install_db" "--defaults-file= --force --basedir=/usr --
datadir=/home/siducer/.local/share/akonadi/db_data/"

it fails because /usr/bin/resolveip is missing in core package.

hefee

> If you look at
> https://packages.debian.org/stretch/amd64/mariadb-server-core-10.1/filelist
> there is no my_print_defaults
> 
> However since 10.3 there is:
> https://packages.debian.org/sid/amd64/mariadb-server-core-10.3/filelist
>   /usr/bin/my_print_defaults
>   ..
>   /usr/share/man/man1/my_print_defaults.1.gz
> 
> Your question is the other way around. Can you please test again if
> this is actually a issue with MariaDB 10.3 or something else? Are you
> using the MariaDB from official Debian repositories?



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

Bug#923419: openssh-client: ssh-agent returns incorrect signature type for RSA CERTs

[Eldon Koyle]

Package: openssh-client
Version: 1:7.9p1-7
Severity: normal
Tags: fixed-upstream

Dear Maintainer,

There is an issue with the ssh client/ssh-agent that causes RSA CERT
based authentication to fail on the initial attempt when using
ssh-agent.  The problem has been fixed upstream[1] and will be part of
the openssh 8.0 release.  There is also a patch[2] for openssh 7.9
mentioned in the ticket.  I'm hoping this fix can make it into buster.

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2944
[2] 
https://anongit.mindrot.org/openssh.git/commit/authfd.c?id=007a88b48c97d092ed2f501bbdcb70d9925277be

-- 
Eldon Koyle

Bug#923418: Introduces spurious whitespace after parentheses

[John MacFarlane]

This looks like

https://github.com/jgm/pandoc/issues/4635

which is fixed in recent versions nof pandoc.
2.2.2+

Martin Michlmayr  writes:

> Package: pandoc
> Version: 2.2.1-3+b2
>
> pandoc introduces a space after parentheses under certain
> circumstances:
>
> 65576:tbm@jirafa: ~] cat pandoc
>
> this is a test (e.g.
> why is there a space after the parenthesis?).
>
> 65577:tbm@jirafa: ~] cat pandoc | pandoc
> this is a test ( e.g. why is there a space after the parenthesis?).
>
> -- 
> Martin Michlmayr
> https://www.cyrius.com/

Bug#883939: Reproduce " smbclient failing to connect with default protocol SMB3_11"

[m.foul...@blueyonder.co.uk]

Hi Mathieu,

I'm using an up-to-date debian testing/buster installation with 
smbclient 2:4.9.4+dfsg-3.


Matthew


On Wed, Feb 27, 2019 at 10:51:23PM +0100, Mathieu Parent wrote:

  Le mercredi 27 février 2019, Matthew Foulkes 
  a écrit :
  > I now have a Debian laptop again and can confirm that bug 883939 still
  exists. Nothing has changed. As I have already explained, however, the
  problem I am experiencing seems to be specific to the (outdated?) ONTAP 9
  software running on the NetApp file server. It may not be worth attempting
  to fix it in Debian.

  What's your version of smbclient?

  --
  Mathieu


--
**
 email: m.foul...@blueyonder.co.uk
 phone: 07905 505676
**

Bug#922979: qemu-efi-aarch64: arm64 UEFI image is unpadded which may confuse new users

[dann frazier]

reassign 922979 src:qemu
thanks

On Fri, Feb 22, 2019 at 02:55:22PM +, Alex Bennée wrote:
> With an un-patched QEMU running with:
> 
>   -drive 
> if=pflash,file=/usr/share/qemu-efi-aarch64/QEMU_EFI.fd,format=raw,readonly
> 
> will fail cryptically as the image isn't padded to the device size. The
> qemu-efi-arm package is currently padded:
> 
> $ ls -lh /usr/share/qemu-efi-aarch64/QEMU_EFI.fd 
> /usr/share/AAVMF/AAVMF32_CODE.fd
> -rw-r--r-- 1 root root  64M Nov 26 23:34 /usr/share/AAVMF/AAVMF32_CODE.fd
> -rw-r--r-- 1 root root 2.0M Nov 26 23:34 
> /usr/share/qemu-efi-aarch64/QEMU_EFI.fd

qemu-efi-aarch64 also provides a padded image:

$ dpkg -L qemu-efi-aarch64 | grep AAVMF
/usr/share/AAVMF
/usr/share/AAVMF/AAVMF_CODE.fd
/usr/share/AAVMF/AAVMF_VARS.fd

The unpadded QEMU_EFI.fd is just provided for backwards compatibility.

> Whether fixing the packaging or using a patch like currently being
> discussed on qemu-devel:
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg05934.html

Since that's a QEMU patch, and I don't see anything that needs to be
done in edk2 (the source for qemu-efi-aarch64), I'm reassigning to the
qemu package.

  -dann

Bug#921889: debian-policy: recommends an old version of libjs-sphinxdoc

[Gabriele Stilli]

found -1 4.3.0.2

Hi,

unfortunately the bug showed again when the latest libjs-sphinxdoc
1.8.4-1 entered buster.

(debian-policy now Recommends: libjs-sphinxdoc (< 1.8.3.0~))

Not sure we want to undergo all this at every sphinx version bump :-)

Regards
Gabriele Stilli

Bug#805727: lxde: desktop fails to load

[Andriy Grytsenko]

control: tags -1 + moreinfo

Could you, please, clarify if this old issue ever happens again or not?
Thank you very much.

Bug#865141: more info

[Josip Rodin]

Not only does it not work, it errors out with:

% sudo update-grub
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/oldvgname-lvroot'.

Which is to say:

% sudo sh -ex /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg
+ set -e
+ prefix=/usr
+ exec_prefix=/usr
+ datarootdir=/usr/share
+ prefix=/usr
+ exec_prefix=/usr
+ sbindir=/usr/sbin
+ bindir=/usr/bin
+ sysconfdir=/etc
+ PACKAGE_NAME=GRUB
+ PACKAGE_VERSION=2.02~beta3-5+deb9u1
+ host_os=linux-gnu
+ datadir=/usr/share
+ [ x = x ]
+ pkgdatadir=/usr/share/grub
+ export pkgdatadir
+ grub_cfg=
+ grub_mkconfig_dir=/etc/grub.d
+ basename /usr/sbin/grub-mkconfig
+ self=grub-mkconfig
+ grub_probe=/usr/sbin/grub-probe
+ grub_file=/usr/bin/grub-file
+ grub_editenv=/usr/bin/grub-editenv
+ grub_script_check=/usr/bin/grub-script-check
+ export TEXTDOMAIN=grub
+ export TEXTDOMAINDIR=/usr/share/locale
+ . /usr/share/grub/grub-mkconfig_lib
+ prefix=/usr
+ exec_prefix=/usr
+ datarootdir=/usr/share
+ datadir=/usr/share
+ bindir=/usr/bin
+ sbindir=/usr/sbin
+ [ x/usr/share/grub = x ]
+ test x/usr/sbin/grub-probe = x
+ test x/usr/bin/grub-file = x
+ test x = x
+ grub_mkrelpath=/usr/bin/grub-mkrelpath
+ which gettext
+ :
+ grub_tab=
+ test 2 -gt 0
+ option=-o
+ shift
+ argument -o /boot/grub/grub.cfg
+ opt=-o
+ shift
+ test 1 -eq 0
+ echo /boot/grub/grub.cfg
+ grub_cfg=/boot/grub/grub.cfg
+ shift
+ test 0 -gt 0
+ fgrep -qs ${GRUB_PREFIX}/video.lst /etc/grub.d/00_header
+ [ x = x ]
+ id -u
+ EUID=0
+ [ 0 != 0 ]
+ set /usr/sbin/grub-probe dummy
+ test -f /usr/sbin/grub-probe
+ :
+ /usr/sbin/grub-probe --target=device /
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/oldvgname-lvroot'.
+ GRUB_DEVICE=

Which is to say:

% sudo strace grub-probe --target=device / 2>&1 | grep -E 
'(mapper|vg|lv|dev|mount)'
execve("/usr/sbin/grub-probe", ["grub-probe", "--target=device", "/"], [/* 17 
vars */]) = 0
open("/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libudev.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tr"..., 1024) = 311
open("/boot/grub/device.map", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/proc/self/mountinfo", O_RDONLY)  = 3
read(3, "kio rw,nosuid,nodev,noexec,relat"..., 1024) = 717
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3440, ...}) = 0
lstat("/dev/mapper", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
lstat("/dev/mapper/oldvgname-lvroot", 0x7ffc7a97ad80) = -1 ENOENT (No such file 
or directory)
write(2, "failed to get canonical path of "..., 63failed to get canonical path 
of `/dev/mapper/oldvgname-lvroot') = 63

So the problem is the info exposed by the running kernel:

% grep oldvgname "/proc/self/mountinfo"
21 0 253:0 / / rw,relatime shared:1 - ext4 /dev/mapper/oldvgname-lvroot 
rw,errors=remount-ro,data=ordered

Once upon a time, one could mess with /etc/mtab in these cases, but that
file is no longer used, it's a symlink into /proc/mounts.

Not sure if this should be reassigned elsewhere then... maybe lvm2 should
try harder to communicate volume group changes to the running kernel?
The device mapper seems to have done its job in updating /dev/mapper,
but it didn't seem to percolate into mountinfo.

btw xref 
https://askubuntu.com/questions/765058/how-do-you-rename-the-volume-group-that-contains-the-root-volume-in-lvm

-- 
 2. That which causes joy or happiness.

Bug#865141: more info

[Josip Rodin]

And in turn this makes subsequent kernel upgrades croak:

% sudo dpkg --configure -a
Setting up linux-image-4.9.0-8-amd64 (4.9.144-3.1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-8-amd64
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/oldvgname-lvroot'.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
dpkg: error processing package linux-image-4.9.0-8-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 linux-image-4.9.0-8-amd64

-- 
 2. That which causes joy or happiness.

Bug#677262: lxsession: system beeps (still?) not working under LXDE

[Andriy Grytsenko]

Could you, please, provide output of command 'xset q' on your system?

Bug#883939: Reproduce " smbclient failing to connect with default protocol SMB3_11"

[Mathieu Parent]

Le mercredi 27 février 2019, Matthew Foulkes  a
écrit :
> I now have a Debian laptop again and can confirm that bug 883939 still
exists. Nothing has changed. As I have already explained, however, the
problem I am experiencing seems to be specific to the (outdated?) ONTAP 9
software running on the NetApp file server. It may not be worth attempting
to fix it in Debian.


What's your version of smbclient?

-- 
Mathieu

Bug#923418: Introduces spurious whitespace after parentheses

[Martin Michlmayr]

Package: pandoc
Version: 2.2.1-3+b2

pandoc introduces a space after parentheses under certain
circumstances:

65576:tbm@jirafa: ~] cat pandoc

this is a test (e.g.
why is there a space after the parenthesis?).

65577:tbm@jirafa: ~] cat pandoc | pandoc
this is a test ( e.g. why is there a space after the parenthesis?).

-- 
Martin Michlmayr
https://www.cyrius.com/

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

[Francesco Poli]

On Wed, 27 Feb 2019 14:05:03 +0100 Vincent Blut wrote:

[...]
> On Mon, Feb 25, 2019 at 10:07:28PM +0100, Francesco Poli wrote:
[...]
> >Nothing is added to /var/log/messages when chrony fails to start.
> 
> Ok so I think I can reproduce this issue on a Debian Buster i386 virtual 
> machine. However, to double check that I’m facing the same issue as 
> yours, I’d like you to:
> 
> - stop the chronyd daemon
> # service chrony stop
> 
> - install strace
> # apt install strace
> 
> - use the log directive in chrony.conf (“log measurements” alone 
>   suffices to trigger the issue)
> 
> - execute strace on chronyd
> # strace -o chronyd_debug.txt chronyd -d -F -1
> 
> - don’t forget to attach the chronyd_debug.txt file when you answer ;-)

  # strace -o /tmp/chronyd_debug.txt chronyd -d -F -1
  2019-02-27T21:11:34Z chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK 
+RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
  2019-02-27T21:11:34Z Frequency -63.045 +/- 0.023 ppm read from 
/var/lib/chrony/chrony.drift
  2019-02-27T21:11:34Z Loaded seccomp filter
  Bad system call

File chronyd_debug.txt is attached (gzipped).

[...]
> >So I tried to think about the differences between the box where it
> >fails, and the box where it works.
> >
> >The first difference is the architecture:
> > • the box where it fails is i386
> 
> Indeed, this is due to a missing syscall needed for this architecture 
> (and probably some other 32-bit plateforms) in the seccomp filter.

Ah, that's it (maybe).

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

OK, so I was wrong!   ;-)

> 
> >The second difference is the init system and might be more relevant:
> > • the box where it fails runs with sysvinit as PID 1
> > • the box where it works runs with systemd as PID 1
> 
> I think it is safe to exclude PID 1 as the cause of this issue.

Funny that I was completely off-track in the search for the relevant
difference...   :p

> 
> Thanks for yout time,

Thanks to you, for your helpfulness and patience!


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


chronyd_debug.txt.gz
Description: application/gzip


pgpVwiGGV5WSm.pgp
Description: PGP signature

Bug#923412: freecad: After update to 0.18~pre1+dfsg1-4 freecd crashes after start

[Rolf Wuerdemann]

On 27.02.19 21:41, Kurt Kremitzki wrote:
> Hello Rolf,

Hello Kurt,
> 
> On 2/27/19 2:01 PM, Rolf Wuerdemann wrote:
>> Package: freecad
>> Version: 0.18~pre1+dfsg1-4
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> after updating freecad (and subpackages) from 0.17 to 0.18~pre1,
>> freecad stalls after start with the message
>> <-snip->
> 
> This seems similar to an issue reported in the FreeCAD forums [1]. If it
> is the same issue, there seems to be a problem with the
> update-alternatives scripts. As a temporary workaround, can you try
> running `sudo update-alternatives --config freecad` and picking either
> the -python2 or -python3 option? You may need to install freecad-python3
> first before that command works, if you only have freecad-python2 installed.
> 
> [1] https://forum.freecadweb.org/viewtopic.php?f=4=34468
> 

After running update-alternatives freecad works. Thanks for the quick
response!

JFI: Now freecad claims that '/usr/share/freecad/examples' isn't
found.

Best,

   Rolf

-- 
Security is an illusion - Datasecurity twice
Rolf Würdemann   -   ro...@digitalis.org   -   DL9ROW
GnuPG fingerprint:   EEDC BEA9 EFEA 54A9 E1A9  2D54 69CC 9F31 6C64 206A
xmpp: ro...@digitalis.org E1189573 6B4A150C A0C2BF5A 5553F865 0B9CBF7A
  ro...@jabber.ccc.de 64CBBB68 0A3514A4 026FC1E7 5328CE87 AEE2185F



signature.asc
Description: OpenPGP digital signature

Bug#883939: Reproduce " smbclient failing to connect with default protocol SMB3_11"

[Matthew Foulkes]

I now have a Debian laptop again and can confirm that bug 883939 still 
exists. Nothing has changed. As I have already explained, however, the 
problem I am experiencing seems to be specific to the (outdated?) ONTAP 
9 software running on the NetApp file server. It may not be worth 
attempting to fix it in Debian.


Regards, Matthew


On Mon, Feb 18, 2019 at 10:38:32AM -0800, Matthew Foulkes wrote:

Hi Mathieu,

I am visiting the US until the end of March and do not have access to 
a computer running Debian at the moment. Sorry. I will be buying a new 
laptop in a couple of weeks and will install Debian when it arrives, 
but cannot help you until then.


Regards, Matthew

On Mon, Feb 18, 2019 at 01:39:23PM +0100, Mathieu Parent wrote:

Hello all,

Are you able to reproduce this bug on latest stretch (2:4.5.16+dfsg-1)
and/or latest buster (2:4.9.4+dfsg-3, -2 is ok).

Regards
--
Mathieu Parent


--
**
email: m.foul...@blueyonder.co.uk
phone: 07905 505676
**


--
**
 email: m.foul...@blueyonder.co.uk
 phone: 07905 505676
**

Bug#923346: updates

[Paul Thomas]

OK, a couple of updates.

First, I tracked down line ptp4l call that starts this off, it's the
ioctl(fd, SIOCSHWTSTAMP, ); line 88 in sk.c. I can see if a
standalone program that just does that ioctl has the same affect.

Second, I was able to reproduce this using the mainline 5.0-rc8 kernel.

-Paul

Bug#923417: pspp: CVE-2019-9211

[Salvatore Bonaccorso]

Source: pspp
Version: 1.2.0-2
Severity: normal
Tags: security upstream

Hi,

The following vulnerability was published for pspp.

CVE-2019-9211[0]:
| There is a reachable assertion abort in the function
| write_long_string_missing_values() in data/sys-file-writer.c in
| libdata.a in GNU PSPP 1.2.0 that will lead to denial of service.

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-2019-9211
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9211
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1683499

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#788674: lxsession: LXDE not loading at login

[Andriy Grytsenko]

This seems to be similar to bug reported against at-spi2-core package
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918776 but with another
problem produced. I would like to hear if this problem is still present
or reproducible on your system. Let us know, please.

Bug#921294: No need to block buster

[Aaron M. Ucko]

Dominik George  writes:

> Correct, will be fixed today.

Fix confirmed, thanks!  I'll reupload with a tightened build dependency
this evening (US/Eastern).

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#890075: ruby-http ftbfs (test failures with 2.5)

[Emanuele Rocca]

On 10/02 09:47, Matthias Klose wrote:
> ruby-http ftbfs for 2.5, but not for 2.3 in unstable:

Note that the bug is not reproducible with ruby-http 3.3.0-2 as tests
have been disabled:

https://salsa.debian.org/ruby-team/ruby-http/commit/728a3fbcc7c59ebb14cb55aa9f084b910d666971
https://salsa.debian.org/ruby-team/ruby-http/commit/6ba2e142ef6952fc905ac2cac7e2eec536433ac3

Reverting the commits above makes ruby-http ftbfs in unstable.

Bug#923416: advancecomp: CVE-2019-9210

[Salvatore Bonaccorso]

Source: advancecomp
Version: 2.1-1
Severity: important
Tags: security upstream
Forwarded: https://sourceforge.net/p/advancemame/bugs/277/

Hi,

The following vulnerability was published for advancecomp.

CVE-2019-9210[0]:
| In AdvanceCOMP 2.1, png_compress in pngex.cc in advpng has an integer
| overflow upon encountering an invalid PNG size, which results in an
| attempted memcpy to write into a buffer that is too small. (There is
| also a heap-based buffer over-read.)

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-2019-9210
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9210
[1] https://sourceforge.net/p/advancemame/bugs/277/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#923249: [Pkg-libvirt-maintainers] Bug#923249: libvirt0: libvirt sets disable_ipv6 on bridge, entirely breaking internal IPv6 networking

[Ralf Jung]

Btw, I reported this upstream at
, and made some headway
debugging things there.

; Ralf

Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag

[Felix Lechner]

Hi Daniel,

On Wed, Feb 27, 2019 at 12:03 PM Daniel Kahn Gillmor
 wrote:
>
> I guess if we wanted some version of lintian to be able to check on the
> git tag, we need to have some sort of export (git shallow
> something-or-other?) that could be included in debian/ to recreate a git
> repo that would be sufficient to verify the contents of the files and
> confirm the git signature.

I wrote a Debian tool to create a shipping manifest with file-based
hashes. Would it help to include that at the time of packaging? If the
manifest is signed, we could do away with tarball signatures.

Felix

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

[Niels Thykier]

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

Hi,

I have unblocked prelude-lml/4.1.0-2 on the basis that the diff between
-1 and -2 would have been acceptable if it had still been in testing.
Note that this unblock only applies to prelude-lml/4.1.0-2 as it is
currently; if that version cannot migrate to testing then prelude-lml
will not be a part of buster.

Mind you, prelude-lml will not migrate as long as #919869 remains open
AFAICT, it is "just" a question of the bug not being properly closed in
the upload of 4.1.0-2 and that you will have to do that manually.

Thanks,
~Niels

Bug#923309: cacti-spine_1.1.37-2~bpo9+1 fails to run under non-root user

[Sven Hartge]

On 27.02.19 21:35, Paul Gevers wrote:

> @Paul, Thanks for reporting this issue. Please check the existing
> comments in bug 904332
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904332
> 
> @Sven can you please help us and maybe explain how Paul should be using
> the cacti-spine binary with these Linux capabilities enabled that we
> added in that version by your patch. I guess he needs to install
> libcap2-bin and run $(chmod u-s /usr/sbin/spine)

Yes, but one additional step:

You also need to set the capabilities:

   setcap cap_net_raw+ep /usr/sbin/spine

After that, everything should be back in working order.

If not, then the bug is at a different place. Also the missing setuid
bit and the missing capabilities only prevent the use of the
ICMP-Checker for Host Liveliness Checking, but not the failure to run at
all.

Without those two bits in place, SNMP gathering will still work.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#922004: transition: clamav

[Niels Thykier]

Control: tags -1 confirmed pending

Scott Kitterman:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Even though we are after the transition deadline, we would like to have
> permission to go ahead with the clamav transition.  Typically we keep clamav
> updated in stable for effectiveness reasons and we plan to do the same now.
> In order to do that, we need to do sid/buster first.
> 
> Status of preparations:
> 
> clamav 0.101.1+dfsg-2 is in experimental and has built on all release archs
> for which it has been tried (it's been waiting a week for mips64el/mipsel).
> 
> It's ready for unstable/buster.
> 
> rdepends:
> 
> dansguardian (still and issue for stable, but removed from unstable/buster),
> maintianed fork e2guardian uses clamd, not libclamav, so not an issue.
> 
> libclamunrar: Update split from clamav source and uploaded to experimental.
> 
> python-clamav: Source changes needed.  Patched version uploaded to
> experimental.
> 
> havp: Source changes needed.  New upstream release with fixes uploaded to
> experimental (upstream only incorporates Debian patches and this change).
> 
> c-icap-modules: binNMU only - tested rebuild locally.
> 
> pg-snakeoil: binNMU only - tested rebuild locally.
> 
> 
> Ben file (note: this is what reportbug generated, the auto one is fine):
> 
> title = "clamav";
> is_affected = .depends ~ "libclamav7" | .depends ~ "libclamav9";
> is_good = .depends ~ "libclamav9";
> is_bad = .depends ~ "libclamav7";
> 
> Note that for the packages that need sourceful uploads, I am an uploader, so
> no external maintainer coordination is required.
> 
> Scott K
> 

Please go ahead. :)

Thanks,
~Niels

Bug#923412: freecad: After update to 0.18~pre1+dfsg1-4 freecd crashes after start

[Kurt Kremitzki]

Hello Rolf,

On 2/27/19 2:01 PM, Rolf Wuerdemann wrote:
> Package: freecad
> Version: 0.18~pre1+dfsg1-4
> Severity: normal
> 
> Dear Maintainer,
> 
> after updating freecad (and subpackages) from 0.17 to 0.18~pre1,
> freecad stalls after start with the message
> <-snip->

This seems similar to an issue reported in the FreeCAD forums [1]. If it
is the same issue, there seems to be a problem with the
update-alternatives scripts. As a temporary workaround, can you try
running `sudo update-alternatives --config freecad` and picking either
the -python2 or -python3 option? You may need to install freecad-python3
first before that command works, if you only have freecad-python2 installed.

[1] https://forum.freecadweb.org/viewtopic.php?f=4=34468

Bug#923064: [INTL:da] Danish translation of the debconf templates wireshark

[Balint Reczey]

No problem, thanks for updating the translation!

On Wed, Feb 27, 2019 at 6:48 PM Joe Dalton  wrote:
>
> of course sorry about that
>
>
> 
> Den tirs 26/2/19 skrev Balint Reczey :
>
>  Emne: Re: Bug#923064: [INTL:da] Danish translation of the debconf templates 
> wireshark
>  Til: "Joe Dalton" , 923...@bugs.debian.org
>  Dato: tirsdag 26. februar 2019 17.43
>
>  Control: tags -1 moreinfo
>
>  Hi Joe,
>
>  On
>  Sat, Feb 23, 2019 at 8:00 PM Joe Dalton 
>  wrote:
>  >
>  > Package:
>  wireshark
>  > Severity: wishlist
>  > Tags: l10n patch
>  >
>  > Please include the attached Danish
>  wireshark debconf po file.
>  >
>  > joe@debianbuster:~/over/debian/wireshark$
>  msgfmt --statistics -c -v -o /dev/null da.po
>  > da.po: 16 oversatte tekster.
>
>  This looks like the po file
>  for apt-listchanges. Could you please
>  attach
>  the one for wireshark?
>
>  Cheers,
>  Balint
>
>
>  --
>  Balint Reczey
>  Ubuntu &
>  Debian Developer



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#923309: cacti-spine_1.1.37-2~bpo9+1 fails to run under non-root user

[Paul Gevers]

Hi Paul, Allan,

@Paul, Thanks for reporting this issue. Please check the existing
comments in bug 904332

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904332

@Sven can you please help us and maybe explain how Paul should be using
the cacti-spine binary with these Linux capabilities enabled that we
added in that version by your patch. I guess he needs to install
libcap2-bin and run $(chmod u-s /usr/sbin/spine)

Paul

On 26-02-2019 07:39, Paul Allen wrote:
> Package: cacti-spine
> Version: 1.1.37-1~bpo9+1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> Upgrading from cacti-spine_1.1.37-1~bpo9+1 to 
> cacti-spine_1.1.37-2~bpo9+1 caused execution of cacti-spine for non-root 
> users to break, even with setuid bits set for either just user or all.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Attempted to set setuid bits on /usr/sbin/spine to permit execution 
> by non-root users (eg, cacti). Attempted to debug by running 
> "/usr/sbnin/spine -H=180 -R -S -V=5" and "/usr/sbin/spine -h" as both root 
> and cacti users.
>* What was the outcome of this action?
> /usr/sbin/spine would fail silently when executed by cacti user but 
> would run successfully when executed by root user. Example: 
> cacti@mon1:~# /usr/sbin/spine -H=180 -R -S -V=5
> cacti@mon1:~#
> cacti@mon1:~# /usr/sbin/spine -h
> cacti@mon1:~#
> 
>* What outcome did you expect instead?
> Expected spine to execute successfully for non-root cacti user once 
> setuid bit(s) were set.
> 
> Re-installing cacti-spine_1.1.37-2~bpo9+1 had no effect, Removing and 
> re-adding setuid bits had no effect. Once I rolled the package back to 
> cacti-spine_1.1.37-1~bpo9+1 and set the setuid bit for the user it started 
> executing successfully again for the no-root cacti user with no other changes 
> necessary.
> 
> 
> 
> -- 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-6-amd64 (SMP w/16 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 cacti-spine depends on:
> ii  cacti  1.1.38+ds1-1~bpo9+1
> ii  dbconfig-no-thanks 2.0.11~bpo9+1
> ii  debconf [debconf-2.0]  1.5.61
> ii  libc6  2.24-11+deb9u4
> ii  libmariadbclient18 10.1.37-0+deb9u1
> ii  libsnmp30  5.7.3+dfsg-1.7+deb9u1
> ii  ucf3.0036
> 
> cacti-spine recommends no packages.
> 
> Versions of packages cacti-spine suggests:
> ii  snmp-mibs-downloader  1.1+nmu1
> 
> -- no debconf information
> 

Bug#923415: libpodofo: CVE-2018-20797

[Salvatore Bonaccorso]

Source: libpodofo
Version: 0.9.6+dfsg-4
Severity: important
Tags: security upstream
Forwarded: https://sourceforge.net/p/podofo/tickets/34/

Hi,

The following vulnerability was published for libpodofo.

CVE-2018-20797[0]:
| An issue was discovered in PoDoFo 0.9.6. There is an attempted
| excessive memory allocation in PoDoFo::podofo_calloc in
| base/PdfMemoryManagement.cpp when called from
| PoDoFo::PdfPredictorDecoder::PdfPredictorDecoder in
| base/PdfFiltersPrivate.cpp.

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-2018-20797
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20797
[1] https://sourceforge.net/p/podofo/tickets/34/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#923408: lxpanel: weather applet does not update at startup

[Andriy Grytsenko]

>Thanks for fixing the weather applet by using the OpenWeatherMap API.
>Here's another problem though:

>When I start my LXDE session the weather applet does not show the
>temperature etc., but rather says that weather information for my
>location is not available.

Thank you for your report. Actually I am aware of that but unfortunately
time before freeze is so tight that I could not risk to develop reliable
solution as it might take time to develop and test. It will be developed
later so I hope to get it backported to the buster-backports.

Bug#923414: poppler: CVE-2019-9200

[Salvatore Bonaccorso]

Source: poppler
Version: 0.71.0-2
Severity: important
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/poppler/poppler/issues/728

Hi,

The following vulnerability was published for poppler.

CVE-2019-9200[0]:
| A heap-based buffer underwrite exists in ImageStream::getLine() located
| at Stream.cc in Poppler 0.74.0 that can (for example) be triggered by
| sending a crafted PDF file to the pdfimages binary. It allows an
| attacker to cause Denial of Service (Segmentation fault) or possibly
| have unspecified other impact.

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-2019-9200
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9200
[1] https://gitlab.freedesktop.org/poppler/poppler/issues/728
[2] 
https://research.loginsoft.com/bugs/heap-based-buffer-underwrite-in-imagestreamgetline-poppler-0-74-0/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#909401: mailutils: don't know what 2047 is

[Poon, Dara]

The example command in the GNU mailutils documentation 
(http://mailutils.org/manual/html_node/mailutils-2047.html) fails, printing 
"mailutils: don't know what 2047 is" as the error message.  Running it with 
strace shows the root cause:

stat("/usr/lib/mailutils/mailutils/mailutils-2047", 0x7ffd569d7770) = -1 ENOENT 
(No such file or directory)


The build process for mailutils-3.4 actually produces an executable file 
mu/libexec/.libs/mailutils-flt2047, but it is never packaged into any .deb.  If 
you build mailutils-3.4 using dpkg-buildpackage, then manually install that 
binary:

# mkdir -p /usr/lib/mailutils/mailutils
# cp ./mu/libexec/.libs/mailutils-flt2047 /usr/lib/mailutils/mailutils/


… then you would be able to run `mailutils flt2047`.  (Note that the command is 
named "flt2047", in contrast to the documentation, which calls it "2047".  
That's an upstream bug.)

Bug#923413: shim-signed: Receiving error message "Failed to set MokSBStateRT: (2) Invalid Parameter"

[Omer Oz]

Package: shim-signed
Version: 1.28+nmu1+0.9+1474479173.6c180c6-1
Severity: normal

Dear Maintainer,

I started receiving "Failed to set MokSBStateRT: (2) Invalid Parameter" error
message before boot screen after installing shim-signed package while upgrading
grub-efi-amd64-signed package.

This error message is displayed even if secure boot is disabled. I can continue
to grub screen after selecting [OK]. However, boot fails due to kernel
signature validation if secure boot is enabled. The system boots without any
issues if secure boot is disabled.

I have already enrolled Debian's cert and the test cert. They are listed in
the output of `moklist --list`.

A similar bug has been filed against Ubuntu as well [1]. It looks like a patch
addressing this issue has been merged to the upstream [2].

Info about my system:

# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.
Table at 0x000E.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: Dell Inc.
Version: 2.11.2
Release Date: 11/07/2018
Address: 0xF
Runtime Size: 64 kB
ROM Size: 16 MB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 2.11

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Dell Inc.
Product Name: Precision Tower 3620
Version: Not Specified
Serial Number: *redacted*
UUID: *redacted*
Wake-up Type: Power Switch
SKU Number: 06B7
Family: Precision

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Dell Inc.
Product Name: 0MWYPT
Version: A02
Serial Number: *redacted*
Asset Tag: Not Specified
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: Not Specified
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

--
Thanks,
Omer

[1] https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1644806
[2] https://github.com/rhboot/shim/commit/07bda58



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

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages shim-signed depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  grub-efi-amd64-bin 2.02+dfsg1-11
ii  grub2-common   2.02+dfsg1-11
ii  mokutil0.2.0-1+b3
ii  shim   0.9+1474479173.6c180c6-1

Versions of packages shim-signed recommends:
pn  secureboot-db  

shim-signed suggests no packages.

-- debconf information:
  shim/title/secureboot:
  shim/secureboot_explanation:
  shim/error/bad_secureboot_key:
  shim/error/secureboot_key_mismatch:
  shim/enable_secureboot: false
  shim/disable_secureboot: true

Bug#923412: freecad: After update to 0.18~pre1+dfsg1-4 freecd crashes after start

[Rolf Wuerdemann]

Package: freecad
Version: 0.18~pre1+dfsg1-4
Severity: normal

Dear Maintainer,

after updating freecad (and subpackages) from 0.17 to 0.18~pre1,
freecad stalls after start with the message
"
  Wizard shaft module cannot be loaded
  No module named PartDesignGui
  Traceback (most recent call last):
  File "", line 50, in Initialize
"

the screen of freecad stays gray (no help/starter page, etc), one
can change the preferences, but not too much else. Deleting
local file including config does not help.



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

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

Versions of packages freecad depends on:
ii  freecad-python2  0.18~pre1+dfsg1-4

Versions of packages freecad recommends:
ii  calculix-ccx  2.11-1+b3
ii  graphviz  2.40.1-5+b2

Versions of packages freecad suggests:
pn  freecad-doc 
ii  povray  1:3.7.0.8-1
pn  python-collada  

-- no debconf information

Bug#923411: RFS: scdoc/1.9.0-1

[Birger Schacht]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : scdoc
  Version  : 1.9.0-1
  Upstream Author  : Drew DeVault 
* Url  : https://git.sr.ht/~sircmpwn/scdoc
* Licenses : MIT
  Programming Lang : C
  Section  : text

 scdoc is a tool designed to make the process of writing man pages more
 friendly. It reads scdoc syntax from stdin and writes roff to stdout,
suitable
 for reading with man(1).

It builds those binary packages:

  * scdoc

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

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

Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/s/scdoc/scdoc_1.9.0-1.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://salsa.debian.org/bisco-guest/scdoc.git

More information about scdoc can be obtained from
https://git.sr.ht/~sircmpwn/scdoc


Changes since last upload:

  * New upstream release
  * Refreshed patch
  * d/rules: Pass PCDIR to the install target
  * d/control: Drop Multiarch hint

Regards,
  Birger Schacht

Bug#923410: qemu: qemu-debootstrap missed to handle hppa arch

[Helge Deller]

Package: qemu
Version: 3.1+dfsg-4
Severity: normal
Tags: patch

While setting up a hppa debian buildd server, I noticed that the hppa
architecture is not handled in the qemu-debootstrap program. Since hppa
is missing in the list, I noticed another bug in qemu-debootstrap that
the error message is referring to a wrong variable and thus the arch is
not printed.

Can you please apply the trivial patch which is included below in the next 
upload?

Thanks,
Helge


diff -up ./debian/qemu-debootstrap.org ./debian/qemu-debootstrap
--- ./debian/qemu-debootstrap.org   2019-02-27 20:55:49.366838616 +0100
+++ ./debian/qemu-debootstrap   2019-02-27 20:56:44.318469290 +0100
@@ -134,7 +134,7 @@ fi
 
 qemu_arch=""
 case "$deb_arch" in
-  
alpha|arm|armeb|i386|m68k|mips|mipsel|mips64el|ppc64|riscv32|riscv64|sh4|sh4eb|sparc|sparc64|s390x)
+  
alpha|arm|armeb|hppa|i386|m68k|mips|mipsel|mips64el|ppc64|riscv32|riscv64|sh4|sh4eb|sparc|sparc64|s390x)
 qemu_arch="$deb_arch"
   ;;
   amd64)
@@ -156,7 +156,7 @@ case "$deb_arch" in
 qemu_arch="ppc64le"
   ;;
   *)
-die "Sorry, I don't know how to support arch %s" "$arch"
+die "Sorry, I don't know how to support arch %s" "$deb_arch"
   ;;
 esac
 

Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag

[Daniel Kahn Gillmor]

On Tue 2019-02-26 16:36:05 -0500, Chris Lamb wrote:
> I'm afraid it would, and would not be visible on lintian.d.o, and
> would also give different results in different environments. Whilst
> there is no strict written policy about this anywhere, this just
> feels "kinda" wrong, alas.

gotcha, thanks for the explanation and scope of what is in-bounds for
lintian.

I guess if we wanted some version of lintian to be able to check on the
git tag, we need to have some sort of export (git shallow
something-or-other?) that could be included in debian/ to recreate a git
repo that would be sufficient to verify the contents of the files and
confirm the git signature.  I don't know how to do that yet though :/

--dkg

Bug#742182: [Pkg-samba-maint] Bug#742182: samba-tool gpo aclcheck always fails with uncaught exception error

[Mathieu Parent]

Control: reopen -1
Control: found -1 2:4.8.2+dfsg-1
Control: found -1 2:4.9.4+dfsg-1

Le mer. 27 févr. 2019 à 14:45, L. van Belle  a écrit :
>
> Please reopen, not fixed in 4.8.9 and 4.9.4.

Done, but but you can do this yourself.

See https://www.debian.org/Bugs/server-control

Regards
-- 
Mathieu Parent

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

[Daniel Baumann]

On 2/27/19 9:44 AM, Jonas Smedegaard wrote:
> perhaps this is not specific to mmdebstrap but is tied to 
> apt or dpkg, especially the latter seeing major changes recently.

Interestingly, using --mode=fakechroot works for sid whereas --mode=root
fails (buster fails with fakechroot because of #915559).

Regards,
Daniel

Bug#922300: unblock: chef/13.8.7-3, ohai/13.8.0-1

[Stefano Rivera]

Hi Release Team:
> unblock chef/13.8.7-3
> unstable ohai/13.8.0-1
> OR
> remove ruby-cheffish/13.1.0-2

I have a couple of packages that are part of the part of the chef stack
and some were pulled out with it, through no fault of their own.


So, I'd add to that, a

unblock foodcritic/13.1.1-2
unblock ruby-knife-acl/1.0.3-2

Neither of those are critical to the maintenance of ci.debian.org, but
they are of use to people managing Cheffed infrastructure, and don't
have particularly high popcon or bug numbers.

OR

If we don't unblock the chef stack, can we also:

remove chef-zero/13.1.0-2

It seems silly to keep it in the release, without chef.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#923409: perl: autopkgtest failure on i386: arch-specific GDBM files

[Niko Tyni]

Source: perl
Version: 5.28.1-4
User: debian-p...@lists.debian.org
Usertags: autopkgtest

The autopkgtest checks of this package fail on at least i386 because the
GDBM backward compatibility check bundles databases built on amd64 that
are not compatible across different architectures.

 helloPASS
 perl-base-self-contained PASS
 compression  PASS
 db   PASS
 gdbm FAIL non-zero exit status 1
 ndbm FAIL non-zero exit status 1
 storable PASS
 embedPASS
 command1 PASS
 command2 PASS
 command3 PASS

This was not spotted earlier as ci.debian.net only runs checks on amd64.
-- 
Niko Tyni   nt...@debian.org

Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?

[Niko Tyni]

On Mon, Feb 25, 2019 at 11:31:14AM +0100, Gianfranco Costamagna wrote:
> Package: libmarc-charset-perl
> Version: 1.35-2
> Severity: serious
> 
> Hello, for some reasons the package testsuite started to fail in Ubuntu for 
> this package and xml-perl reverse-dependency,
> only on armhf and i386.
> This happened when the new gdbm has been uploaded and rebuilds issued.
> 
> I traced down the problem to some differences in the march8/utf8 Table 
> generation, I don't know how serious it is, but the
> testsuite seems completely broken on armhf and i386 at least, and utf8 cjk 
> conversion seems to return wrong values.
> This is the reason for me opening this bug as "serious".

Thanks for noticing this. I've confirmed that this happens on at least
Debian sid/i386 too. It's a bit unfortunate that we only have autopkgtest
checks on amd64, so this wasn't spotted earlier.

> after a no-change rebuild of the package, and installing it, the test goes 
> passing ok:

Looks like src:gdbm has broken compatibility with old databases, much
like #910911. I haven't extracted the details so not reassigning yet,
but copying Dmitry as a heads-up.

As I argued in #910911, the big issue with such a backcompat break is
that user databases become unusable, and libmarc-charset-perl breakage is
just a small detail that could be properly solved with the recipe in
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910911#63 :

> - update perl to build-depend on libgdbm-dev (>= 1.18-2) and Break
>   older versions of libmarc-charset-perl (and any other perl packages
>   bundling GDBM or NDBM databases)
> 
> - update libmarc-charset-perl (and any other perl packages bundling
>   GDBM or NDBM databases) to build-depend and depend on the newer perl
> 
> I assume other language bindings like python-gdbm will need something
> similar.

But ideally gdbm would restore compatibility and libmarc-charset-perl would
not need any changes.
-- 
Niko Tyni   nt...@debian.org

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

[Niko Tyni]

On Wed, Feb 27, 2019 at 05:16:03PM +0100, gregor herrmann wrote:

> 2) This fix would also suite the documentation of tv_imdb which says:
> 
> tv_imdb --imdbdir  [--help] [--quiet]
>[--with-keywords] [--with-plot]
>[--movies-only] [--actors NUMBER]
>[--stats] [--debug]
>[--output FILE] [FILE...]
> 
> (so: pass FILE as an argument, not: read from STDIN, as the testsuite
> does)

The convention in manual pages is that optional arguments are denoted with
brackets. My expections from just the above synopsis would be precisely
the old behaviour (which the test suite apparently relies on): FILE is
optional and STDIN is used if FILE is not supplied.

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

Not sure I follow but I agree with the last sentence at least :)
Clearly '-' needs special handling in XML::Parser if 2-arg open is
converted to 3-arg open.

(Sorry, no tuits for providing a better patch for XML::Parser.)
-- 
Niko Tyni   nt...@debian.org

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

[Jonas Smedegaard]

Quoting Ben Hutchings (2019-02-27 19:37:41)
> Control: severity -1 wishlist
> Control: retitle -1 Add option to override filesystem type detection
> 
> On Wed, 2019-02-27 at 18:38 +0100, Jonas Smedegaard wrote:
> > Quoting Jonas Smedegaard (2019-02-27 17:45:33)
> > > Building a system image using multistrap,
> > > including generating an initial ramdisk,
> > > worked fine recently.
> > >
> > > Now it fails with this error message:
> > > 
> > >   W: Couldn't identify type of root file system for fsck hook
> > > 
> > > It seems to me that git commit a8ed874 intended to extend the code 
> > > operating on "auto" mounted filesystems to cover all _except_ root 
> > > disk, but that the logic is flipped around so that now it _only_ 
> > > extends that to include root disk:
> 
> This commit went into version 0.123, before stretch, so if your use
> case "worked fine recently" then this is not the change that broke it.

Heh.  I even looked briefly at the date thinking "hmm, committed in 
January, not February when released was made, but oh well...", and 
noticed that corresponding bug#767471 had a quite low number... :-)


> > Please ignore my guess above: I think I understand now that it was 
> > intentional to check root disk (I got confused by the comment 
> > talking about ignoring root and then processing root not skipping 
> > it).
> > 
> > Let me clarify my use case: I generate a system image on a fast 
> > amd64 system targeted a slower real device (that's the reason having 
> > initramfs generated is important).
> > 
> > fstab now unconditionally being distrusted for root disk makes it 
> > more difficult to build on a different host than intended for target 
> > boot.
> >
> > Would it perhaps make sense to support passing pre-resolved root 
> > filesystem fstype as an environment variable, taking precedence over 
> > probing?
> 
> I don't think this should be an environment variable but it does seem 
> like a useful option.

Thanks for considering.


 - Jonas

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

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


signature.asc
Description: signature

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

[Guus Sliepen]

On Wed, Feb 27, 2019 at 10:51:35AM +0100, Michael Biebl wrote:

> > Even better, the plugin could
> > just call system("/sbin/ifquery ") to check whether an
> > interface is managed by ifupdown or not.
> 
> If the idea is to load and run less code in NM, this would mean we have
> to add more. So at a first glance this doesn't look very compelling.
> 
> Also, if we wanted to find devices which should not be touched by NM
> because they are defined in /e/n/i, is ifquery really sufficient to do that?

Yes.

> Say I have a br0 and eth0 in bridge_ports.
> What will ifquery eth0 return in such a case?

If will return an error, because as far as ifupdown itself is concerned,
no interface named eth0 has been defined. Ifupdown doesn't parse
bridge_ports, this is instead handled by /etc/network/if-pre-up.d/bridge
that's in the bridge-utils package. This is unfortunate, it is possible
to make it more visible to ifupdown: for example, when bonding
interfaces (which is similar to briding in the sense that you have a
bond interface and some other interfaces connected to it), the ifenslave
package provides an if-pre-up.d script that allows you to define a bond
interface, and instead of using bond_slaves (the equivalent of
bridge_ports), you can instead give slave interfaces their own iface
definition in /e/n/i and add something like "bond_master bond0" to it.

> Personally, I've never been a fan of the ifupdown plugin in NM. Parsing
> the /e/n/i file is hairy and incomplete.

It basically comes down to the fact that part of the parsing is done by
the plugins, and that there's no way just by looking at /e/n/i to
perfectly know which interfaces are controlled by ifupdown and which are
not.

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

Or maybe set ENV{MANAGER}='ifupdown', to support other ways of managing
networks as well (ifupdown2, wicd, and probably more)? I like this
approach of signalling through udev though, it completely decouples
ifupdown from NetworkManager.

I just did some testing, and just using ifquery as it is now will not be
enough. The reason is that ifquery expects the name of a logical
interface (ie, the name of an iface stanza), and not that of a physical
interface. You can write something like:

allow-hotplug /eth*=eth
iface eth inet dhcp

This will bring up any interface whose name starts with eth (so eth0,
eth1, etc), and use the configuration of the iface eth stanza to
configure them. In this case, "ifquery eth0" would always return an
error, only "ifquery eth" would return zero. OTOH, if eth0 is up, then
"ifquery --state eth0" would return 0, but "ifquery --state eth" would
return an error.

Not confusing enough? The above can still be solved by adding an option
to ifquery to make it query a physical interface. But: you can also
define VLAN interfaces but omit the VLAN trunk interface. Is the
physical (trunk) interface then managed by ifupdown or not?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

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

[Ben Hutchings]

Control: severity -1 wishlist
Control: retitle -1 Add option to override filesystem type detection

On Wed, 2019-02-27 at 18:38 +0100, Jonas Smedegaard wrote:
> Quoting Jonas Smedegaard (2019-02-27 17:45:33)
> > Building a system image using multistrap,
> > including generating an initial ramdisk,
> > worked fine recently.
> >
> > Now it fails with this error message:
> > 
> >   W: Couldn't identify type of root file system for fsck hook
> > 
> > It seems to me that git commit a8ed874 intended to extend the code
> > operating on "auto" mounted filesystems to cover all _except_ root disk,
> > but that the logic is flipped around so that now it _only_ extends that
> > to include root disk:

This commit went into version 0.123, before stretch, so if your use
case "worked fine recently" then this is not the change that broke it.

> Please ignore my guess above: I think I understand now that it was 
> intentional to check root disk (I got confused by the comment talking 
> about ignoring root and then processing root not skipping it).
> 
> Let me clarify my use case: I generate a system image on a fast amd64 
> system targeted a slower real device (that's the reason having initramfs 
> generated is important).
> 
> fstab now unconditionally being distrusted for root disk makes it more 
> difficult to build on a different host than intended for target boot.
>
> Would it perhaps make sense to support passing pre-resolved root 
> filesystem fstype as an environment variable, taking precedence over 
> probing?

I don't think this should be an environment variable but it does seem
like a useful option.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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

Bug#667738: libhttp-daemon-perl: HTTP::Daemon::ClientConn is IPv4 only

[Fabian Grünbichler]

Hello perl maintainers :)

I opened up a MR on salsa[1] to include the patches from upstream's bug
tracker that enable IPv6 support by switching to IO::Socket::IP - it
would be great if somebody can take a look at them and upload the -2
package ;)

Kind Regards,
Fabian

1: 
https://salsa.debian.org/perl-team/modules/packages/libhttp-daemon-perl/merge_requests/1

Bug#923265: libconfig-model-dpkg-perl: cme is unable to parse build dependencies built by npm2deb

[Xavier]

Le 27/02/2019 à 18:54, Dominique Dumont a écrit :
> On Mon, 25 Feb 2019 17:08:53 +0100 Xavier Guimard  wrote:
>> npm2deb build dependencies using this format:
>>
>>   Build-Depends:
>>debhelper (>= 11)
>>, nodejs (>= 6)
> 
> Right 
> 
> Could you send me a link to the whole control file ? (so that I can create a 
> complete test case).
> 
> All the best
> 
> Dod

Thanks for looking at this. An example can be found here:
https://salsa.debian.org/js-team/node-millstone,
https://salsa.debian.org/js-team/node-millstone/blob/master/debian/control

Cheers,
Xavier

Bug#923408: lxpanel: weather applet does not update at startup

[Teemu Ikonen]

Package: lxpanel
Version: 0.10.0-1
Severity: normal
Tags: upstream

Thanks for fixing the weather applet by using the OpenWeatherMap API.
Here's another problem though:

When I start my LXDE session the weather applet does not show the
temperature etc., but rather says that weather information for my
location is not available.

I use network manager / nm-applet to set up my networking, so the likely
reason for this is that the weather plugin tries to make a connection to
the servers before the network setup is finished. If I toggle the manual
/ automatic update in the plugin settings after the network is up, the
weather info appears.

The weather plugin should either wait for the network to come up
(network manager has the 'nm-online' util for this, but I'm not sure if
you can assume that network manager is running), or make a few retries
during startup, with a reasonable wait time in between.

Best,
Teemu

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

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

Versions of packages lxpanel depends on:
ii  libasound2   1.1.8-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-7
ii  libcairo21.16.0-2
ii  libcurl3-gnutls  7.64.0-1
ii  libfm-gtk4   1.3.1-1
ii  libfm-modules1.3.1-1
ii  libfm4   1.3.1-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.3-1
ii  libgtk2.0-0  2.24.32-3
ii  libiw30  30~pre9-13
ii  libkeybinder00.3.1-1
ii  libmenu-cache3   1.1.0-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libwnck222.30.7-6
ii  libx11-6 2:1.6.7-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  lxmenu-data  0.1.5-2
ii  lxpanel-data 0.10.0-1

Versions of packages lxpanel recommends:
ii  libnotify-bin0.7.7-4
ii  lxterminal [x-terminal-emulator] 0.3.2-1
ii  notification-daemon  3.20.0-4
ii  pavucontrol  3.0-4
ii  rxvt-unicode [x-terminal-emulator]   9.23~pre.ti-1
ii  stterm [x-terminal-emulator] 0.8.2-1
ii  xfce4-notifyd [notification-daemon]  0.4.3-1
ii  xkb-data 2.26-2
ii  xterm [x-terminal-emulator]  344-1

Versions of packages lxpanel suggests:
ii  chromium [www-browser] 72.0.3626.109-1
ii  firefox-esr [www-browser]  60.5.1esr-1
ii  lynx [www-browser] 2.8.9rel.1-3
ii  menu   2.1.47+b1
ii  w3m [www-browser]  0.5.3-37

-- no debconf information

Bug#923406: RFS: hoteldruid/2.3.2-1

[Marco M. F. De Santis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: hoteldruid
  Version : 2.3.2-1
  Upstream Author : Marco M. F. De Santis
* URL : http://www.hoteldruid.com
* License : AGPLv3
  Section : web

It builds those binary packages:

  hoteldruid - web-based property management system for hotels or B

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


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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hoteldruid/hoteldruid_2.3.2-1.dsc


More information about hoteldruid can be obtained from 
http://www.hoteldruid.com.


Changes since the last upload:

  * New upstream release
- Fixes multiple sql injection and XSS vulnerabilities.
  (Ref: CVE-2019-9084, CVE-2019-9085, CVE-2019-9086, CVE-2019-9087)
  * Removed patch fix-gestione-utenti (integrated in upstream).

Regards,
Marco M. F. De Santis

Bug#923404: Patch

[Francois Marier]

The attached patch seems to fix the problem for me.

Francois

-- 
https://fmarier.org/
diff -u /usr/bin/ssl-cert-check ssl-cert-check 
--- /usr/bin/ssl-cert-check	2019-02-26 21:24:00.0 -0800
+++ ssl-cert-check	2019-02-27 10:04:34.331729364 -0800
@@ -658,9 +658,9 @@
 fi
 
 if [ "${TLSSERVERNAME}" = "FALSE" ]; then
-	TLSFLAG=(s_client -crlf -connect "${1}":"${2}" "${VERSION}")
+	TLSFLAG=(s_client -crlf -connect "${1}":"${2}")
 else
-TLSFLAG=(s_client -crlf -connect "${1}":"${2}" -servername "${1}" "${VERSION}")
+TLSFLAG=(s_client -crlf -connect "${1}":"${2}" -servername "${1}")
 fi
 
 echo "" | "${OPENSSL}" "${TLSFLAG[@]}" 2> "${ERROR_TMP}" 1> "${CERT_TMP}"

Bug#899337: closed by Dominique Dumont (Bug#899337: fixed in libconfig-model-dpkg-perl 2.114)

[Dominique Dumont]

On Sun, 17 Feb 2019 03:32:47 +0100 Guillem Jover  wrote:
> Unfortunately, only part of the bug was fixed. :)

Oops... I'll fix the 2nd part.

Sorry about that :-)

All the best

Dod

Bug#768005: xl / xen bash completion

[Hans van Kranenburg]

Hi,

On 2/12/19 2:27 AM, Hans van Kranenburg wrote:
> Hi,
> 
> On 2/11/19 2:01 PM, Adi Kriegisch wrote:
>>
>>> Reassigning to Debian Xen team, since I that makes more sense. We
>>> totally missed this on our (release) radar.
>>>
>>> And indeed, we're shipping the upstream completion file now. Adi, I see
>>> how you're improving it, and I like it.
>> I'm happy you like it...
>>  
>>> So, we should probably ship this instead, but at the same time, the
>>> right (tm) place to move this is upstream. We're activetly trying to get
>>> rid of "adjusted copies of upstream stuff" in the packaging.
>> I think it would be great if you could ship that for Buster because I don't
>> think upstream will merge it within the next month... ;-)
>>
>>> Would you mind making an upstream patch out of this? I can help with
>>> that if needed. Then it gets proper review, and upstream can maintain it
>>> when commands are added/changed etc.
>> Find the patch attached; it is based on upstream's repository[1]. Feel free
>> to submit it upstream (no need to credit me; this is just copied together
>> from xm and upstream's command list).
> 
> Well, there's the "two sides of the coin"... There's getting credits for
> doing work, but you'll also get blame because the work is never good enough.
> 
> It's nice that this improved completion script is adding things on top
> of simple first-level commands, but when reviewing this, the first
> command I looked at is xl create. My first question would be: did you
> compare the actual current result to the xl man page?
> 
> For example, I see that xl create has options like -q, --quiet, -f=FILE,
> --defconfig=FILE, -p, -F, -V, --vncviewer, -A, --vncviewer-autopass, -c,
> and (whoa!!) even key=value "It is possible to pass key=value pairs on
> the command line to provide options as if they were written in the
> configuration file"... Ok, that last one is probably a bit too much to
> ask completion to have an opinion about, but...
> 
> You get the picture. Your completion file just has options='-c'.
> 
> What do you think would be the best to do with this? Have a thorough
> review and comparison and add all possible options and test them? Or,
> take a step back and pretend it can do less, like the upstream one?
> 
> I can't just submit a patch upstream with myself as "credit" in this
> state, because I know these are the questions that upstream developers
> will be throwing at me immediately.

Initially, I thought that this file was already converted to xl, but
that seems not to be the case. I do not think it's a good idea to
include this, since it's simply doing an incorrect thing in many places,
e.g. suggesting phy: obsolete syntax, but also the options just don't
match xl.

So, this needs someone who actually uses bash completion a lot, and
wants to take ownership of this task, converting and testing everything
and taking it upstream first.

I'm not going to do that now, sorry.

Hans

Bug#923405: RFS: pandoc-plantuml-filter/0.1.1-1 [ITP]

[Hanno Stock]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "pandoc-plantuml-filter"

 * Package name: pandoc-plantuml-filter
   Version : 0.1.1-1
   Upstream Author : Timo Furrer
 * URL : https://github.com/timofurrer/pandoc-plantuml-filter
 * License : MIT
   Section : misc

  It builds those binary packages:

pandoc-plantuml-filter - Pandoc filter: converts PlantUML code blocks to 
PlantUML images

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

  https://mentors.debian.net/package/pandoc-plantuml-filter

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/pandoc-plantuml-filter/pandoc-plantuml-filter_0.1.1-1.dsc

  The package is maintained in git under 
https://salsa.debian.org/python-team/applications/pandoc-plantuml-filter
  and will be maintained in the Python Application Packagin Team (also set as 
maintainer).

  More information about pandoc-plantuml-filter can be obtained from 
https://github.com/timofurrer/pandoc-plantuml-filter.

  Regards,
   Hanno Stock

Bug#923404: ssl-cert-check cannot monitor TLS1.2-only servers

[Francois Marier]

Package: ssl-cert-check
Version: 4.10-1
Severity: important
Tags: upstream

It appears that version 4.10 no longer supports checking the certificates of
servers that only support TLS 1.2, as recommended by Mozilla:

  https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

Here's an example of a server that can no longer be monitored using this
package:

$ ssl-cert-check -s fmarier.org -p 443

HostStatus   Expires  Days
---   
unable to load certificate
140117264852032:error:0909006C:PEM routines:get_name:no start 
line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
unable to load certificate
140042749473856:error:0909006C:PEM routines:get_name:no start 
line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
unable to load certificate
140668490343488:error:0909006C:PEM routines:get_name:no start 
line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
unable to load certificate
140431452333120:error:0909006C:PEM routines:get_name:no start 
line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
fmarier.org:443 Expired   
-2458542   

Francois

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

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

Versions of packages ssl-cert-check depends on:
ii  openssl  1.1.1b-1

Versions of packages ssl-cert-check recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
ii  mailutils [mailx]  1:3.5-2

ssl-cert-check suggests no packages.

-- no debconf information

Bug#579828: MOC doesn't play 24bit/96kHz flac

[Elimar Riesebieter]

Control: tags -1 unreproducible

* Elimar Riesebieter  [2010-07-02 19:44 +0200]:

> tags 579828 moreinfo
> thanks
> 
> * Elimar Riesebieter [100501 13:06 +0200]
> > forwarded 579828 da...@daper.net
> > thanks
> > 
> > 
> > * James Stuckey [100501 12:16 +0200]
> > > Package: MOC
> > > Version: moc 2.5.0-alpha4 Build: Jan 31 2010 15:00:33
> > > Compiled with: OSS ALSA JACK DEBUG internet streams resample
> > 
> > This isn't a bugreport we can support. Please use 'reportbug moc' so
> > that we get all infos about your moc package and elese..
> > 
> > >   When I try to play a certain flac file on my system MOC says "(0)
> > > Can't set audio parameters: Invalid argument"
> > 
> > Is it possible to play other codecs like ogg or mp3?
> > 
> > > 
> > >   in the console.
> > > 
> > >   The file is: TEST.flac: FLAC audio bitstream data, 24 bit, 6
> > > channels, 96 kHz, 5472 samples
> > 
> > Hmm, could you please make this file avilable online or send it vi
> > PM to me?
> 
> Is this bug still valid for you? I need some more infos as requested
> before.

I've tested last testing (buster) build:

Sample_BeeMoved_96kHz24bit.flac: FLAC audio bitstream data, 24 bit, stereo, 96 
kHz, 3828096 samples

plays just fine. There is no response from the reporter so closing this bug 
hereby.


Elimar
-- 
  Do you smell something burning or is it me?


signature.asc
Description: PGP signature

Bug#923403: anbox launch fails

[Joachim Zobel]

Package: anbox
Version: 0.0~git20181210-1
Severity: important

Dear Maintainer,

Anbox does not strat any more:

jo@pause:~$ /usr/bin/anbox launch --package=org.anbox.appmgr
--component=org.anbox.appmgr.AppViewActivity
[ 2019-02-27 17:18:37] [launch.cpp:71@launch_session_manager] Can't find
correct anbox executable to run. Found /memfd:liblxc (deleted) but does not
exist

jo@pause:~$ dpkg -S liblxc
lxcfs: /usr/lib/x86_64-linux-gnu/lxcfs/liblxcfs.so
liblxc1: /usr/share/doc/liblxc1/copyright
liblxc1: /usr/share/doc/liblxc1/NEWS.Debian.gz
liblxc1: /usr/share/doc/liblxc1
liblxc1: /usr/lib/x86_64-linux-gnu/liblxc.so.1
liblxc1: /usr/share/doc/liblxc1/changelog.Debian.gz
liblxc1: /usr/lib/x86_64-linux-gnu/liblxc.so.1.4.0
(failed reverse-i-search)`reportbu': sudo yum-config-manager add-repo
http://download.opensuse.org/distribution/leap/42.2/^Cpo/oss/




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

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

Versions of packages anbox depends on:
ii  iptables1.8.2-3
ii  libboost-atomic1.67.0   1.67.0-13
ii  libboost-chrono1.67.0   1.67.0-13
ii  libboost-date-time1.67.01.67.0-13
ii  libboost-filesystem1.67.0   1.67.0-13
ii  libboost-iostreams1.67.01.67.0-13
ii  libboost-log1.67.0  1.67.0-13
ii  libboost-program-options1.67.0  1.67.0-13
ii  libboost-regex1.67.01.67.0-13
ii  libboost-serialization1.67.01.67.0-13
ii  libboost-system1.67.0   1.67.0-13
ii  libboost-thread1.67.0   1.67.0-13
ii  libc6   2.28-7
ii  libegl1 1.1.0-1
ii  libgcc1 1:8.2.0-21
ii  libgles21.1.0-1
ii  liblxc1 1:3.1.0+really3.0.3-4
ii  libprotobuf-lite17  3.6.1.3-1
ii  libsdl2-2.0-0   2.0.9+dfsg1-1
ii  libsdl2-image-2.0-0 2.0.4+dfsg1-1
ii  libstdc++6  8.2.0-21
ii  libsystemd0 240-6
ii  lxc 1:3.1.0+really3.0.3-4

Versions of packages anbox recommends:
ii  dbus-user-session  1.12.12-1

anbox suggests no packages.

-- no debconf information

Bug#923265: libconfig-model-dpkg-perl: cme is unable to parse build dependencies built by npm2deb

[Dominique Dumont]

On Mon, 25 Feb 2019 17:08:53 +0100 Xavier Guimard  wrote:
> npm2deb build dependencies using this format:
> 
>   Build-Depends:
>debhelper (>= 11)
>, nodejs (>= 6)

Right 

Could you send me a link to the whole control file ? (so that I can create a 
complete test case).

All the best

Dod

Bug#844229: ITP: node-chroma-js -- JavaScript library for color conversions

[Cah Cilik]

On Sun, 13 Nov 2016 16:32:42 +0100 Ross Gammon  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ross Gammon 
>
> * Package name: node-chroma-js
>   Version : 1.2.1
>   Upstream Author : Gregor Aisch
> * URL : https://github.com/gka/chroma.js
> * License : BSD-3
>   Programming Lang: JavaScript
>   Description : JavaScript library for color conversions
>
>  Chroma.js is a tiny JavaScript library (12kB) for all kinds of color
> conversions and color scales.
>  .
>  Node.js is an event-based server-side JavaScript engine.
>
> Chroma-js is a new dependency of node-carto which is maintained within the
> Debian Javascript Team, where this one will also be maintained.
>
>

Dapatkan Outlook untuk Android

Bug#923401: [Pkg-xen-devel] Bug#923401: /etc/default/xen conffile vs. ucf

[Hans van Kranenburg]

On 2/27/19 6:08 PM, Ian Jackson wrote:
> Package: xen-utils-common
> Version: 4.11.1+26-g87f51bf366-2
> 
> In stretch, /etc/default/xen was a ucf config file.  In buster until
> recently it was absent, with some special casing in rules etc. to
> handle its removal.  in recent buster it is back, as a dpk-ghandld
> file.  I think we should not switch from ucf to dpkg-handled for
> buster.  We should rtain ucf.
> 
> How about this patch ?  salsa#diziet/default-xen-ucf
> 
> I have done a test build and the result seemed to work.  I'm pretty
> sure it's right for upgrades from stretch since for that it is
> completely standard use of ucf.  I think it is right for upgrades from
> testing too.
> 
> I did an install test of a machine with sid's package and it installed
> and the result is /etc/default/xen as an `obsolete' conffile in dpkg,
> and ucf seems happy and there is ucf metadata for the file now.

Pasting parts of the diffs because it was an attachment:

diff --git a/debian/not-installed b/debian/not-installed
index 5ffa447587..7888222c55 100644
--- a/debian/not-installed
+++ b/debian/not-installed
@@ -7,7 +7,6 @@ etc/init.d/xendriverdomain
 etc/init.d/xencommons
 etc/init.d/xen-watchdog
 etc/init.d/xendomains
-etc/default/xencommons

^^
etc/default/xencommons in debian/not-installed has to stay, because of
the dh-exec bug:

https://salsa.debian.org/xen-team/debian-xen/commit/2501ae058a50920e0c5dec9828ae62597df10a7b

--- a/debian/rules
+++ b/debian/rules
@@ -320,4 +320,3 @@ override_dh_missing:
 # earlier versions.  See ./ucf-remove-fixup for more details.
 override_dh_ucf:
dh_ucf
-   debian/ucf-remove-fixup xen-utils-common /etc/default/xen

^^
What about removing all of this, and the now obsolete comment?
Overriding dh_ucf to only do dh_ucf doesn't seem useful?

Ah, I now see that we already still had a xen-utils-common.ucf which was
still in place. I was wondering how ucf could do the right thing here,
but now it makes sense. I still don't fully understand all of it, but I
can help testing scenarios.

So, what about other files? Should also e.g. add /etc/default/xendomains
to ucf? /etc/xen/oxenstored.conf?

Hans

Bug#923064: [INTL:da] Danish translation of the debconf templates wireshark

[Joe Dalton]

of course sorry about that



Den tirs 26/2/19 skrev Balint Reczey :

 Emne: Re: Bug#923064: [INTL:da] Danish translation of the debconf templates 
wireshark
 Til: "Joe Dalton" , 923...@bugs.debian.org
 Dato: tirsdag 26. februar 2019 17.43
 
 Control: tags -1 moreinfo
 
 Hi Joe,
 
 On
 Sat, Feb 23, 2019 at 8:00 PM Joe Dalton 
 wrote:
 >
 > Package:
 wireshark
 > Severity: wishlist
 > Tags: l10n patch
 >
 > Please include the attached Danish
 wireshark debconf po file.
 >
 > joe@debianbuster:~/over/debian/wireshark$
 msgfmt --statistics -c -v -o /dev/null da.po
 > da.po: 16 oversatte tekster.
 
 This looks like the po file
 for apt-listchanges. Could you please
 attach
 the one for wireshark?
 
 Cheers,
 Balint
 
 
 -- 
 Balint Reczey
 Ubuntu &
 Debian Developer

da.po.tar.gz
Description: application/gzip

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

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2019-02-27 17:45:33)
> Building a system image using multistrap,
> including generating an initial ramdisk,
> worked fine recently.
> 
> Now it fails with this error message:
> 
>   W: Couldn't identify type of root file system for fsck hook
> 
> It seems to me that git commit a8ed874 intended to extend the code
> operating on "auto" mounted filesystems to cover all _except_ root disk,
> but that the logic is flipped around so that now it _only_ extends that
> to include root disk:

Please ignore my guess above: I think I understand now that it was 
intentional to check root disk (I got confused by the comment talking 
about ignoring root and then processing root not skipping it).

Let me clarify my use case: I generate a system image on a fast amd64 
system targeted a slower real device (that's the reason having initramfs 
generated is important).

fstab now unconditionally being distrusted for root disk makes it more 
difficult to build on a different host than intended for target boot.

Would it perhaps make sense to support passing pre-resolved root 
filesystem fstype as an environment variable, taking precedence over 
probing?


 - Jonas

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

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


signature.asc
Description: signature

Bug#923244: [Pkg-utopia-maintainers] Bug#923244: Bug#923244: policykit-1: Please support elogind backend

[Michael Biebl]

Hi

Am 27.02.19 um 18:12 schrieb Mark Hindley:
> Micael,
> 
> Thanks. This is very helpful.
> 
> On Wed, Feb 27, 2019 at 02:00:16PM +0100, Michael Biebl wrote:
>> I think, only 3) has a chance to work in Debian (or a slight
>> modification of it).
> 
> Would you specify your slight modification?

What I tried to say is, that I think we should drop libelogind0
completely in Debian. Clients that use libsystemd0 to call sd-login
related functionality should continue to work when elogind is active
without needing recompilation.

Making libelogind0 provide libsystemd0 (e.g. via diversions) is not
going to work (at least not without huge headaches).

So I think the only way forward is to make sure the combination
libsystemd0 + elogind as backend works when it comes to sd-login related
functionality.


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



signature.asc
Description: OpenPGP digital signature

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

[Domenico Andreoli]

On Wed, Feb 27, 2019 at 02:10:06PM +0100, Adam Borowski wrote:
> On Wed, Feb 27, 2019 at 09:33:43AM +0100, Domenico Andreoli wrote:
> > On Tue, Feb 26, 2019 at 08:15:59PM +0100, Adam Borowski wrote:
> > > On Tue, Feb 26, 2019 at 06:06:18PM +0100, Domenico Andreoli wrote:
> > > > * Package name: dwarves-dfsg
> > > >   Version : 1.12-2
> 
> > > >   * Update copyright to copyright-format/1.0. Closes: #919356.
> 
> > > The new copyright file contains references to GPL-2.0-only and
> > > GPL-2.0-or-later without defining them.
> > 
> > According to https://spdx.org/licenses/ they are defined and supersede
> > GPL-2 and GPL-2+ now deprecated (maybe I should file a bug). OTOH I'm
> > reading that as long as copyright-format is not updated, new ones should
> > not be used.
> 
> SPDX has nothing to the copyright-format.  The latter doesn't care about
> short names at all, merely that 1. every file has a license, and 2. every
> license is defined.
> 
> Thus, "GPL-2", "GPL-2+", "GPL-2.0-only", "GPL-2.0-or-later", "Meow-meow"
> and "Cthulhu-fhtagn" have exactly the same meaning: they're merely
> identifiers that need to be defined elsewhere in the file.  Obviously,
> for human readers we still want GPL to mean GPL -- but it's a syntax vs
> content distinction.

Got it, in my mind the two things were related. There is even a paragraph
that says 

 "For SPDX compatibility, versions with trailing dot-zeroes are
  considered to be equivalent to versions without (e.g., “2.0.0”
  is considered equal to “2.0” and “2”)."

but I cannot ignore the one saying:

 "Use of a standard short name does not override the Debian Policy
  requirement to include the full license text in debian/copyright, nor
  any requirements in the license of the work regarding reproduction of
  legal notices. This information must still be included in the License
  field, either in a stand-alone License paragraph or in the relevant
  files paragraph."

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

I evidently read too little and assumed too much.

> > I'm uploaded a new version with GPL-2/GPL-2+, should be available shortly.
> 
> I don't see it on mentors yet...

I rewrote history and pushed a new 1.12-2 release to mentors.

Thanks again for the feedback.

Regards,
Domenico

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


signature.asc
Description: PGP signature

Bug#923402: mu-editor: FTBFS with python3-pkg-resources 40.8.0: TypeError: expected str, bytes or os.PathLike object, not Win

[Dmitry Shachnev]

Source: mu-editor
Version: 1.0.2+dfsg-1
Severity: serious
Justification: fails to build from source
Tags: ftbfs

Dear Maintainer,

As can be seen on [1], mu-editor fails to build with the latest version of
pkg_resources.

The error is:

Traceback (most recent call last):
  File 
"/tmp/mu-editor-1.0.2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/tests/test_app.py",
 line 92, in test_run
run()
  File 
"/tmp/mu-editor-1.0.2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/mu/app.py", 
line 142, in run
app.setWindowIcon(load_icon(editor_window.icon))
  File 
"/tmp/mu-editor-1.0.2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/mu/resources/__init__.py",
 line 37, in load_icon
return QIcon(path(name))
  File 
"/tmp/mu-editor-1.0.2+dfsg/.pybuild/cpython3_3.7_mu-editor/build/mu/resources/__init__.py",
 line 32, in path
return resource_filename(__name__, resource_dir + name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1145, 
in resource_filename
self, resource_name
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1395, 
in get_resource_filename
return self._fn(self.module_path, resource_name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1471, 
in _fn
self._validate_resource_path(resource_name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1518, 
in _validate_resource_path
posixpath.isabs(path) or
  File "/usr/lib/python3.7/posixpath.py", line 66, in isabs
s = os.fspath(s)
TypeError: expected str, bytes or os.PathLike object, not Win

This is caused by addition of _validate_source_path() in pkg_resources 40.8.0,
see [2].

This upstream commit [3] should fix it.

[1]: 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mu-editor.html
[2]: https://github.com/pypa/setuptools/pull/1640
[3]: https://github.com/mu-editor/mu/commit/d38470adc623f887

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#923290: ddpo: Please distinguish reproduible state between sid/testing

[Holger Levsen]

Hi Guillem,

thanks for this bug report and X-Debbugs-Cc:ing us!

On Mon, Feb 25, 2019 at 10:53:36PM +0100, Guillem Jover wrote:
> The reproducible build state is currently only provided for «testing»,
> because «sid» contains additional checks that are deemed would annoy
> maintainers.
 
the problem with the unreproducibility issues in unstable currently is
that they are mostly unactionable as the way forward for build path
issues is not yet clear. thus such warnings can and will be seen as annoying.

> I've been aware of this in the past, but was still caught off guard
> when checking my DDPO page and seeing that inetutils was still marked
> as non-reproducible, even though the tests for sid said it was. And
> thought there was some stale data going on.

basically currently we are only targetting testing/buster with our
efforts.

> I think it would be ideal if the reproducible states was shown
> explicitly for both testing and sid, even though for now the sid
> column would just print a sigil for N/A data (‘-’? with an alt text
> mentioning the suite), this would make the information immediately
> obvious. Also I think that in the future the reproducible people
> might want to expose the state for sid too, at which point the N/A
> marker can just be switched to provide the actual state.

I'm not sure N/A will be less confusing as we do have data for
unstable.. but maybe thats a way forward.


-- 
tschau,
Holger

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


signature.asc
Description: PGP signature

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

[Josh Triplett]

On Wed, Feb 27, 2019 at 01:34:54PM -0300, Felipe Sateler wrote:
> On Wed, Feb 27, 2019 at 12:48 PM Michael Biebl  wrote:
> 
> > On Wed, 23 Jan 2019 14:54:48 -0800 Josh Triplett 
> > wrote:
> > > On Wed, Jan 23, 2019 at 07:52:24PM -0300, Felipe Sateler wrote:
> > > > On Wed, Jan 23, 2019 at 4:15 PM Josh Triplett 
> > wrote:
> > > > > Package: systemd
> > > > > Severity: normal
> > > > >
> > > > > I installed using the Buster Alpha 4 installer, and for some reason I
> > > > > ended up with a file
> > > > > /etc/systemd/system/dbus-org.freedesktop.timesync1.service,
> > identical to
> > > > > /lib/systemd/system/systemd-timesyncd.service. dpkg -S shows it not
> > > > > owned by any package, and searching through maintainer scripts
> > pointed
> > > > > to systemd's postinst. systemd shouldn't install a service in /etc
> > > > > identical to the one already installed in /lib.
> > > > >
> > > >
> > > > All systemd does is enable the service. On my system that leaves a
> > symlink,
> > > > not a regular file.
> > > > Is  /etc/systemd/system/dbus-org.freedesktop.timesync1.service a
> > regular
> > > > file or a symlink?
> > >
> > > It was a regular file.
> >
> > I don't think it's systemctl/systemd which is responsible for creating
> > /etc/systemd/system/dbus-org.freedesktop.timesync1.service as regular file.
> > Maybe a file system issue or the result of the file being copied around.
> 
> 
> > Josh, can you reproduce the issue?
> >
> > What happens if you remove
> > /etc/systemd/system/dbus-org.freedesktop.timesync1.service and run
> > systemctl enable systemd-timesyncd.service (as we do in postinst)
> >
> 
> This is definitely not systemctl's doing:
> 
> % sudo systemctl disable systemd-timesyncd.service
> Removed /etc/systemd/system/dbus-org.freedesktop.timesync1.service.
> Removed /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service.
> % sudo systemctl enable systemd-timesyncd.service
> Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service
> → /lib/systemd/system/systemd-timesyncd.service.
> Created symlink
> /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service →
> /lib/systemd/system/systemd-timesyncd.service.
> 
> Unfortunately I don't think we have enough information to act on this issue.

Feel free to close this. I don't want to do a reinstallation from
scratch in a VM to attempt to reproduce this.

Bug#923244: [Pkg-utopia-maintainers] Bug#923244: policykit-1: Please support elogind backend

[Mark Hindley]

Micael,

Thanks. This is very helpful.

On Wed, Feb 27, 2019 at 02:00:16PM +0100, Michael Biebl wrote:
> I think, only 3) has a chance to work in Debian (or a slight
> modification of it).

Would you specify your slight modification?

We are currently liasing with elogind upstream who are making libelogind ABI
compatible with libsystemd. See https://github.com/elogind/elogind/issues/97

Thanks very much.

Mark

Bug#923401: /etc/default/xen conffile vs. ucf

[Ian Jackson]

Package: xen-utils-common
Version: 4.11.1+26-g87f51bf366-2

In stretch, /etc/default/xen was a ucf config file.  In buster until
recently it was absent, with some special casing in rules etc. to
handle its removal.  in recent buster it is back, as a dpk-ghandld
file.  I think we should not switch from ucf to dpkg-handled for
buster.  We should rtain ucf.

How about this patch ?  salsa#diziet/default-xen-ucf

I have done a test build and the result seemed to work.  I'm pretty
sure it's right for upgrades from stretch since for that it is
completely standard use of ucf.  I think it is right for upgrades from
testing too.

I did an install test of a machine with sid's package and it installed
and the result is /etc/default/xen as an `obsolete' conffile in dpkg,
and ucf seems happy and there is ucf metadata for the file now.

Ian.

>From 49c7a1335efce1c0df766dfac572d37bdada4e59 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Wed, 27 Feb 2019 16:37:32 +
Subject: [PATCH] /etc/default/xen: Handle with ucf

We reintroduced this file in
  "d/xen-utils-common.install: ship /etc/default/xen"
  eg 2f34db35dd27abb4280d38ebc4464c21f64df8c9

But I had forgotten that this file was previously shipped and handled
by ucf; and we have machinery to try to remove it.

This leaves the following possible cases:
(a) stretch: file handled by ucf
(b) older buster: file not shipped, ucf postinst action not done
   | file remains recorded by ucf and ucfr, but that the original
   | version of the file is no longer present on the user's machine
(c) newer buster: file shipped, file recorded by ucf with one
   old version and as dpkg conffile by newer version

(a) and (b) will be handled correctly by just using ucf in the normal
way.

(c) xxx needs testing

So:
 * Drop the special call to ucf-remove-fixup; retain the call to ucf
 * Switch to shipping the file in /usr/share as expected by ucf
 * Remove the file's entry from not-installed
---
 debian/not-installed| 1 -
 debian/rules| 1 -
 debian/xen-utils-common.install | 2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/debian/not-installed b/debian/not-installed
index 5ffa447587..7888222c55 100644
--- a/debian/not-installed
+++ b/debian/not-installed
@@ -7,7 +7,6 @@ etc/init.d/xendriverdomain
 etc/init.d/xencommons
 etc/init.d/xen-watchdog
 etc/init.d/xendomains
-etc/default/xencommons
 
 # This is all handled by debian/shuffle-boot-files,
 # which dh_missing does not know about.
diff --git a/debian/rules b/debian/rules
index 4d3ff89219..23c982eb41 100755
--- a/debian/rules
+++ b/debian/rules
@@ -320,4 +320,3 @@ override_dh_missing:
 # earlier versions.  See ./ucf-remove-fixup for more details.
 override_dh_ucf:
dh_ucf
-   debian/ucf-remove-fixup xen-utils-common /etc/default/xen
diff --git a/debian/xen-utils-common.install b/debian/xen-utils-common.install
index 60642c9a9c..71254213bc 100755
--- a/debian/xen-utils-common.install
+++ b/debian/xen-utils-common.install
@@ -5,7 +5,7 @@ etc/xen/xl*
 etc/bash_completion.d/xl.sh => usr/share/bash-completion/completions/xl
 
 etc/default/xendomains
-etc/default/xencommons => /etc/default/xen
+etc/default/xencommons => usr/share/xen-utils-common/default.xen
 etc/xen/oxenstored.conf
 
 usr/bin
-- 
2.11.0




-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.