Bug#946450: New upstream version 2.5.1

[Christian Kastner]

Source: keepassxc
Version: 2.4.3+dfsg.1-1
Severity: wishlist

I'm being bitten by a bug that was supposedly fixed in 2.5.1 [1], but
while I have a workaround for 2.4.3, I'd greatly appreciate an update to
the new upstream version :-)

[1] https://github.com/keepassxreboot/keepassxc/issues/3985

Bug#946087: Please move the VCS to the DPMT Salsa group

[Angel Abad]

Hi, repo move has been requested, you can track here:

https://salsa.debian.org/salsa/support/issues/182

Cheers

On Tue, Dec 03, 2019 at 03:26:37PM -0500, Louis-Philippe Véronneau wrote:
> Package: src:polib
> Severity: wishlist
> 
> Dear maintainers,
> 
> The current VCS for this package is under the /debian group in Salsa,
> although this package is maintained by the DPMT.
> 
> DPMT policy state that:
> 
> Git repositories live on Salsa under the url
> g...@salsa.debian.org:python-team/modules/.git
> 
> Would it be possible to move it over there? I'd have done it myself
> since I technically have the permissions to do so, but I thought I'd ask
> first :)
> 
> If you don't have time, I'll be happy to do this for you.
> 
> Cheers,
> 
> -- 
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
>   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
>   ⠈⠳⣄
> 





signature.asc
Description: PGP signature

Bug#946137: nvidia-legacy-340xx-driver: Fails to build with kernel 5.4

[jim_p]

Package: nvidia-legacy-340xx-driver
Followup-For: Bug #946137

Thank you for patching the package as I requested. However, I think it would be
nice to report the real contributor in the changelog, i.e. the user that posted
the patch on github, and give thim the credit instead of copying the lines for
ubuntu from 340.107-7 and just changing the kernel version.



-- Package-specific info:
uname -a:
Linux mitsos 5.3.0-3-amd64 #1 SMP Debian 5.3.15-1 (2019-12-07) x86_64 GNU/Linux

/proc/version:
Linux version 5.3.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20191130 (Debian 9.2.1-21)) #1 SMP Debian 5.3.15-1 (2019-12-07)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.107  Thu May 24 21:54:01 
PDT 2018
GCC version:  gcc version 9.2.1 20191130 (Debian 9.2.1-21) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.312906] Console: colour VGA+ 80x25
[0.741570] pci :01:00.0: vgaarb: setting as boot VGA device
[0.741570] pci :01:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.741570] pci :01:00.0: vgaarb: bridge control possible
[0.741570] vgaarb: loaded
[0.927276] Linux agpgart interface v0.103
[3.290697] nvidia: loading out-of-tree module taints kernel.
[3.290708] nvidia: module license 'NVIDIA' taints kernel.
[3.313863] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[3.338446] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[3.339579] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[3.339591] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.107  Thu May 
24 21:54:01 PDT 2018
[3.830777] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[5.091401] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input17
[5.091481] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input22
[5.091553] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input24
[5.091622] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input25
[8.200648] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

Device node permissions:
crw-rw+ 1 root video 226,   0 Dec  9 08:54 /dev/dri/card0
crw-rw-rw-  1 root root  195,   0 Dec  9 08:54 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Dec  9 08:54 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Dec  9 08:54 pci-:01:00.0-card -> ../card0
video:*:44:jim

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Nov 21  2017 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Nov 21  2017 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   43 Nov 21  2017 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Nov 21  2017 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   54 Nov 21  2017 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 Nov 21  2017 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   25 Nov 21  2017 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Nov 21  2017 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Nov 21  2017 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 Nov 21  2017 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 Nov 21  2017 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 Nov 21  2017 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 Nov 21  2017 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   28 Oct 26 13:06 

Bug#944242: Autopkgtest error for arm64

[Andreas Tille]

Control: forwarded -1 https://github.com/biopython/biopython/issues/2388

There is an autopkgtest regression on arm64 that prevents migration:

   
https://ci.debian.net/data/autopkgtest/testing/arm64/p/python-biopython/3607200/log.gz

It is reported upstream as issue 2388


-- 
http://fam-tille.de

Bug#946263: 946263: breaks xdrawchem

[merkys]

Hello,

xdrawchem too seems incompatible with openbabel 3:

xdrawchem/ioiface.cpp: In member function ‘void
IOIface::convertToChemData()’:
xdrawchem/ioiface.cpp:122:21: error: invalid use of incomplete type
‘class OpenBabel::OBBond’
  122 | atom1 = bond->GetBeginAtom();
  | ^~

...

xdrawchem/ioiface.cpp: In member function ‘bool IOIface::convertToOBMol()’:
xdrawchem/ioiface.cpp:275:13: error: aggregate ‘OpenBabel::vector3 v’
has incomplete type and cannot be defined
  275 | vector3 v;
  | ^
xdrawchem/ioiface.cpp:276:12: error: aggregate ‘OpenBabel::OBAtom atom’
has incomplete type and cannot be defined
  276 | OBAtom atom;
  |    ^~~~

Best,
Andrius

Bug#946435: texlive-latex-recommended: Missing Breaks+Replaces texlive-latex-extra 2019.20191112-1

[Hilmar Preuße]

Control: forcemerge -1 946430

Am 08.12.2019 um 23:49 teilte Stuart Prescott mit:

> Package: texlive-latex-recommended
> Version: 2019.20191208-1
> Severity: serious
> Justification: Policy 7.6 overwriting files in other packages
> 
> Dear Maintainer,
> 
> Upgrading texlive packages in sid generates the following.
> 
> Preparing to unpack .../3-texlive-latex-recommended_2019.20191208-1_all.deb 
> ...
> Unpacking texlive-latex-recommended (2019.20191208-1) over (2019.20191112-1) 
> ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-qFj4g6/3-texlive-latex-recommended_2019.20191208-1_all.deb
>  (--unpack):
>  trying to overwrite 
> '/usr/share/texlive/texmf-dist/tex/latex/grffile/grffile-2017-06-30.sty', 
> which is also in package texlive-latex-extra 2019.20191112-1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> 
Has been solved already in 2019.20191208-2. Forcemerge.

> An appropriate Breaks+Replaces will need to be added to the package.
> 
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
> 
> regards
> Stuart
> 


-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#946449: qbittorrent: New upstream release (4.2)

[jim_p]

Package: qbittorrent
Version: 4.1.7-1+b2
Severity: normal
Tags: upstream

So, v4.2 was released a few days ago and, since it is a major release that
makes qbittorrent now use libtorrent 1.2.x, I would like to see it in the
repos.



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

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

Versions of packages qbittorrent depends on:
ii  geoip-database 20191108-1
ii  libboost-system1.67.0  1.67.0-13+b1
ii  libc6  2.29-3
ii  libgcc11:9.2.1-21
ii  libqt5core5a   5.12.5+dfsg-2
ii  libqt5dbus55.12.5+dfsg-2
ii  libqt5gui5 5.12.5+dfsg-2
ii  libqt5network5 5.12.5+dfsg-2
ii  libqt5widgets5 5.12.5+dfsg-2
ii  libqt5xml5 5.12.5+dfsg-2
ii  libstdc++6 9.2.1-21
ii  libtorrent-rasterbar9  1.1.13-1.1
ii  python 2.7.17-2
ii  zlib1g 1:1.2.11.dfsg-1+b1

qbittorrent recommends no packages.

Versions of packages qbittorrent suggests:
pn  qbittorrent-dbg  

-- no debconf information

Bug#946448: z3: FTBFS: ../src/util/mpz.cpp:57:30: error: definition of ‘uint32_t __builtin_ctz(uint32_t)’ ambiguates built-in declaration ‘int __builtin_ctz(unsigned int)’

[Sebastian Ramacher]

Source: z3
Version: 4.8.7-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

z3 fails to build on all 32 bit architectures with:
| ../src/util/mpz.cpp:57:30: error: definition of ‘uint32_t 
__builtin_ctz(uint32_t)’ ambiguates built-in declaration ‘int 
__builtin_ctz(unsigned int)’
|57 | #define _trailing_zeros32(X) __builtin_ctz(X)
|   |  ^
| ../src/util/mpz.cpp:76:17: note: in expansion of macro ‘_trailing_zeros32’
|76 | inline uint32_t _trailing_zeros32(uint32_t x) {
|   | ^
| make[2]: *** [Makefile:188: util/mpz.o] Error 1

See
https://buildd.debian.org/status/fetch.php?pkg=z3=i386=4.8.7-1=1575849231=0
for a full log

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#946447: thefuck: does not start without python3-distutils installed

[sandro]

Package: thefuck
Version: 3.29-0.1
Severity: important

Dear Maintainer,

   * What led up to the situation?
   I installed thefuck on a fresh system with the bullseye installer.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   I tried to load my dotfiles wich include eval "$(thefuck --alias c)".

   * What was the outcome of this action?
   It failed with this error

   Traceback (most recent call last):
 File "/usr/bin/thefuck", line 9, in 
   from thefuck.entrypoints.main import main
 File "/usr/share/thefuck/thefuck/entrypoints/main.py", line 2, in 
   from ..system import init_output
 File "/usr/share/thefuck/thefuck/system/__init__.py", line 7, in 
   from .unix import *  # noqa: F401,F403
 File "/usr/share/thefuck/thefuck/system/unix.py", line 6, in 
   from distutils.spawn import find_executable
 ModuleNotFoundError: No module named 'distutils.spawn'

   * What outcome did you expect instead?
   To load normally without an error.


   I searched the internet about this issue and found a solution in
   installing python3-distutils. I believe thefuck just missing a
   depency on it.

   PS: First bug report on Debian :)

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thefuck depends on:
ii  python33.7.5-1
ii  python3-colorama   0.4.1-1
ii  python3-decorator  4.3.0-1.1
ii  python3-pkg-resources  41.2.0-1
ii  python3-psutil 5.6.7-1
ii  python3-pyte   0.4.8-1
ii  python3-six1.13.0-1

thefuck recommends no packages.

thefuck suggests no packages.

-- no debconf information

Bug#946446: harfbuzz: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: harfbuzz
Version: 2.6.4-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The harfbuzz tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru harfbuzz-2.6.4/debian/tests/build harfbuzz-2.6.4/debian/tests/build
--- harfbuzz-2.6.4/debian/tests/build   2019-11-02 19:37:28.0 -0700
+++ harfbuzz-2.6.4/debian/tests/build   2019-12-08 21:37:00.0 -0800
@@ -7,6 +7,13 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < hbtest.c
 #include 
 #include 
@@ -18,7 +25,7 @@
 }
 EOF
 
-gcc -o hbtest hbtest.c `pkg-config --cflags --libs harfbuzz`
+${CROSS_COMPILE}gcc -o hbtest hbtest.c `${CROSS_COMPILE}pkg-config --cflags 
--libs harfbuzz`
 echo "build: OK"
 [ -x hbtest ]
 ./hbtest

Bug#946445: kafkacat FTCBFS: mklove does not understand --host

[Helmut Grohne]

Source: kafkacat
Version: 1.5.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

kafkacat fails to cross build from source, because the mklove system
providing system driving the configure script does not understand the
--host flag passed by dh_auto_configure. Instead, one is supposed to
export the relevant build tool substitutions via the environment. We can
use dpkg's buildtools.mk to make kafkacat cross buildable. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru kafkacat-1.5.0/debian/changelog 
kafkacat-1.5.0/debian/changelog
--- kafkacat-1.5.0/debian/changelog 2019-10-04 17:07:58.0 +0200
+++ kafkacat-1.5.0/debian/changelog 2019-12-08 20:00:33.0 +0100
@@ -1,3 +1,10 @@
+kafkacat (1.5.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Export build tools via environment for mklove. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 08 Dec 2019 20:00:33 +0100
+
 kafkacat (1.5.0-1) unstable; urgency=medium
 
   * New upstream version.
diff --minimal -Nru kafkacat-1.5.0/debian/rules kafkacat-1.5.0/debian/rules
--- kafkacat-1.5.0/debian/rules 2019-10-04 17:07:58.0 +0200
+++ kafkacat-1.5.0/debian/rules 2019-12-08 20:00:27.0 +0100
@@ -1,5 +1,8 @@
 #!/usr/bin/make -f
 
+DPKG_EXPORT_BUILDTOOLS=1
+include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@
 

Bug#946375: pulseaudio: Please make autopkgtests cross-test-friendly

[Steve Langasek]

On Sun, Dec 08, 2019 at 09:04:06AM -0300, Felipe Sateler wrote:

> Thanks for the patch, I have applied it.  However, wouldn't it be better
> if autopkgtest provided CC and friends directly to the test?  Or provide a
> tool that does?  I have commented on the autopkgtest merge request.

This parallels the existing interface used for cross-compilation in dpkg. 
We don't try to set CC directly for a couple of reasons:

 - it's very difficult to be comprehensive about all the tools that will
   need to be invoked differently for cross vs native builds. CC is one, but
   LD, AS, CXX, FF, ... and there is no such standard variable for
   pkg-config that's widely recognized by build systems.
 - there are cases when cross-compiling that you need to build code for both
   the host and build architectures, and in that case there is no universal
   agreement which of these two targets "CC" points to.

So I've been relying on the tried and true dpkg interface here instead.

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


signature.asc
Description: PGP signature

Bug#946444: librsvg: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: librsvg
Version: 2.46.4-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The librsvg tests currently fail in this environment, because they are build
tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru librsvg-2.46.4/debian/tests/build librsvg-2.46.4/debian/tests/build
--- librsvg-2.46.4/debian/tests/build   2019-11-27 10:21:55.0 -0800
+++ librsvg-2.46.4/debian/tests/build   2019-12-08 20:36:43.0 -0800
@@ -8,6 +8,12 @@
 
 cd "$AUTOPKGTEST_TMP"
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 echo "1..1"
 
 cat > simple.c <<'EOF'
@@ -26,7 +32,7 @@
 }
 EOF
 
-gcc -o simple simple.c $(pkg-config --cflags --libs librsvg-2.0 gobject-2.0)
+${CROSS_COMPILE}gcc -o simple simple.c $(${CROSS_COMPILE}pkg-config --cflags 
--libs librsvg-2.0 gobject-2.0)
 test -x simple
 ./simple
 echo "# everything seems OK"

Bug#946443: libnotify: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: libnotify
Version: 0.7.8-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The libnotify tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner, and
also because they declare a test dependency on a virtual package
'notification-daemon' which may or may not be cross-installable.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libnotify-0.7.8/debian/tests/build libnotify-0.7.8/debian/tests/build
--- libnotify-0.7.8/debian/tests/build  2019-08-14 03:48:50.0 -0700
+++ libnotify-0.7.8/debian/tests/build  2019-12-08 13:39:28.0 -0800
@@ -9,6 +9,13 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < libnotify_test.c
 #include 
 #include 
@@ -33,8 +40,8 @@
 }
 EOF
 
-gcc -o libnotify_test libnotify_test.c \
-`pkg-config --cflags --libs libnotify` -Wall -Werror
+${CROSS_COMPILE}gcc -o libnotify_test libnotify_test.c \
+`${CROSS_COMPILE}pkg-config --cflags --libs libnotify` -Wall -Werror
 echo "build: OK"
 [ -x libnotify_test ]
 dbus-run-session -- xvfb-run ./libnotify_test
diff -Nru libnotify-0.7.8/debian/tests/control 
libnotify-0.7.8/debian/tests/control
--- libnotify-0.7.8/debian/tests/control2019-08-14 03:48:50.0 
-0700
+++ libnotify-0.7.8/debian/tests/control2019-12-08 20:21:11.0 
-0800
@@ -1,2 +1,2 @@
 Tests: build
-Depends: build-essential, dbus (>= 1.8), notification-daemon, xauth, xvfb, 
libnotify-dev, pkg-config
+Depends: build-essential, dbus (>= 1.8), notification-daemon:native, xauth, 
xvfb, libnotify-dev, pkg-config

Bug#946442: mirror submission for mirror.biznetgio.com

[Agik]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.biznetgio.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Agik 
Country: ID Indonesia
Location: Jakarta
Sponsor: Biznet Gio Nusantara https://www.biznetgio.com
Comment: Hi Debian Support
 Please add my mirror in your list
 
 Thanks
 
 Agik




Trace Url: http://mirror.biznetgio.com/debian/project/trace/
Trace Url: 
http://mirror.biznetgio.com/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.biznetgio.com/debian/project/trace/mirror.biznetgio.com

Bug#946441: mirror submission for mirror.biznetgio.com

[Agik Agustono]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.biznetgio.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Agik Agustono 
Country: ID Indonesia
Location: Jakarta
Sponsor: Biznet Gio Nusantara https://www.biznetgio.com
Comment: Hi Debian Support
 Please add my mirror in your list
 
 Thanks
 
 Agik




Trace Url: http://mirror.biznetgio.com/debian/project/trace/
Trace Url: 
http://mirror.biznetgio.com/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.biznetgio.com/debian/project/trace/mirror.biznetgio.com

Bug#930128: tint: Error creating /var/games/tint.scores

[Asher Gordon]

Package: tint
Version: 0.05+b1
Followup-For: Bug #930128

Hi Mark,

Mark Van den Borre  writes:

> May I suggest updating the default high scores file to the user's home
> directory?

A better solution would be to have /usr/games/tint binary be owned by
the group "games" and set the set-group-ID bit. This would allow it to
write /var/games/tint.scores since that file is writable by the "games"
group.

This solution is better than having the high scores file in the user's
home directory, because this way if multiple users are playing, they can
each see each others high scores.

In fact, many games in Debian do this already (take moon-buggy for
example).

You can work around this bug by changing the group and set-group-ID bit
yourself:

$ su
Password:
# chown root:games /usr/games/tint 
# chmod g+s /usr/games/tint
# exit
$ ls -l /usr/games/tint
-rwxr-sr-x 1 root games 27032 Aug  7 04:48 /usr/games/tint*
$ tint
Choose a level to start [1-9]: 1

   PLAYER STATISTICS

Score   186
Efficiency   -1
Score ratio   8
Congratulations! You have a new high score.
Enter your name [asher]: Asher

   TINT HIGH SCORES

Rank   ScoreName

  1* 186Asher

Hopefully you get a better score than I did, but as you can see, it did
save the score.

By the way: I played TINT a while ago, and I'm pretty sure this bug
wasn't present then (most likely someone accidentally removed the
set-group-ID bit from the package since then).

Also, in my opinion, the severity of this bug should be important or
even serious since saving high scores are a big part of the game. But
I'll leave that up to the Maintainers to decide.


Asher


-- 
It's better to be quotable than to be honest.
-- Tom Stoppard

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


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

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

Versions of packages tint depends on:
ii  libc62.29-3
ii  libncurses6  6.1+20191019-1
ii  libtinfo66.1+20191019-1

tint recommends no packages.

tint suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#946400: plplot: please build the Ada binding with gnat-9

[Rafael Laboissière]

Control: tags -1 moreinfo

* Nicolas Boulenguez  [2019-12-08 16:24]:


The attached archive contains various suggestions related to the Ada 
binding.  The last commit switches the Ada compiler from GCC-8 to -9.


Thanks for the patches.

I ignore if this compiler change breaks the plplot-ada ABI. If so, 
libplplotada4.deb should be renamed to libplplotada5.deb, and CMake 
should be told that plplotada_SOVERSION=5.


Could you please suggest a way to test for the ABI breakage ?

At any rate, I think that bumping the SOVERSION like this must be done 
upstream, don't you think?  I am not sure it is a good idea to have the 
Debian packaging messing with this.


I have also another question regarding the package naming.  I see that 
you introduced, in commit 95d5fc9 [1], the change in naming of 
libplplot-ada-dev to libplplotada1-dev.  Is there any specific reason you 
have chosen the number "1"?  Would it not be better to have both packages 
in sync, like libplplotadaN and libplplotadaN-dev?


Please upload to experimental so that the new package(s) pass the NEW 
queue. Once all Ada packages are ready, we will reupload them to 
unstable.


Okay.

Best,

Rafael Laboissière

[1] 
https://salsa.debian.org/science-team/plplot/commit/95d5fc9f79576c9475c4f9c0bea464a86f8c191c

Bug#937727: RM python-enable

[Scott Talbert]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: python-enable -- RoQA; unmaintained; low popcon; 
blocking py2 removal; no rdeps

Bug#946213: RFS: git-delta/0.0.15 -- Syntax-highlighting pager for git and diff output

[Paul Wise]

On Sat, Dec 7, 2019 at 9:36 PM Dan Davison wrote:

> Currently (FreeBSD, Rust Cargo, Arch Linux, Homebrew) the package name is 
> "git-delta", which installs an executable named "delta". Can it do the same 
> for Debian?

There is one package already using that executable name:

$ apt-file search bin/delta
...
swap-cwm: /usr/bin/delta

In general, it is a bad idea to use generic names because of the
potential for namespace conflicts (in $PATH, package names etc).

A rebrand to something like diff-syntax-highlight or git-delta might
be a good idea.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#946170: libpam-cgfs: does nothing under cgroupv2 / unified hierarchy

[Ryutaroh Matsumoto]

Control: severity -1 minor
Control: unblock 943981 by -1

The discussion at the upstream
https://github.com/lxc/lxc/issues/3198
shows that libpam-cgfs cannot do anything useful on Linux
booted with systemd.unified_cgroup_hierarchy.

So I would like to lower the severity and blocking status.
This cannot be fixed, but the man page should be updated, and
a proper instruction should be given so that a non-root user can
start an LXC container with full functionality.

Best regards, Ryutaroh

Bug#943611: cegui-mk2 fails to package extensions for python 3.8

[Olek Wojnar]

Hi Matthias,


Quick update on this bug report.


On 11/13/19 8:32 PM, Olek Wojnar wrote:
> Hi Matthias,
>
>
> Thanks for filing this bug report, I'll try to fix it as soon as I can.
>
>
> On 10/27/19 6:33 AM, Matthias Klose wrote:
>> Package: src:cegui-mk2
>> Version: 0.8.7-3
>> Severity: important
>> Tags: sid bullseye patch
>> User: debian-pyt...@lists.debian.org
>> Usertags: python3.8
>
> I noticed the "patch" tag but I don't see a patch in the BTS. Did you
> intend to upload a patch?


I haven't heard back from you and in the meantime I see that you have
increased the severity of this bug. In the interests of fixing what is
now an RC bug, I am opting for the easy fix and building only for the
default python, as you suggested. I am removing the "patch" tag but if
you had intended to send a patch, please send it to me directly and I
will implement it in my next upload.


Thanks!


-Olek




signature.asc
Description: OpenPGP digital signature

Bug#946440: Add example of browsing local file with odd characters in filename

[積丹尼 Dan Jacobson]

X-Debbugs-Cc: yama...@jpl.org
Package: w3m
Version: 0.5.3-37+b1
Severity: wishlist
File: /usr/share/man/man1/w3m.1.gz

In EXAMPLES add:
Browse local file with "?" in filename:
$ w3m -T text/html /tmp/zzz%3Fx=n #("?" URI-encoded)

Bug#941198: In support of mandatory unit files

[Guillem Jover]

On Sun, 2019-12-08 at 15:55:45 -0800, Russ Allbery wrote:
> Guillem Jover  writes:
> > But here you do have another option, but I'm not sure it might be
> > described as nicer TBH, :) something like this, or variations on this
> > theme:
> 
> >   [Service]
> >   Type=simple
> >   EnvironmentFile=/etc/default/service-static-vars
> >   EnvironmentFile=-/run/service-dynamic-vars
> >   ExecStartPre=-/bin/sh -c 'echo NAME=$(hostname) 
> > >/run/service-dynamic-vars'
> >   ExecStart=/usr/bin/daemon --option ${NAME}
> 
> This is a nice approach, but I don't think it quite preserves the original
> behavior.  As you wrote it above, if someone changed the setting in the
> /etc/default file, that would have no effect and the default would still
> be used.  If you reverse the order of EnvironmentFile, it avoids that
> problem, but now the legacy setting with $(hostname) will be used if it
> hasn't been changed, and that will result in a literal $(hostname) in the
> value.

Right, it was more about showing the concept than a proper
implementation, but it's true that as is, it's not helpful. :)

I guess the following which starts to get a bit into ugly territory
would do instead:

   [Service]
   Type=simple
   EnvironmentFile=-/run/service-dynamic-vars
   ExecStartPre=-/usr/bin/env -i /bin/sh -a -c '. 
/etc/default/service-static-vars && env -uPWD >/run/service-dynamic-vars'
   ExecStart=/usr/bin/daemon --option ${NAME}

Thanks,
Guillem

Bug#946438: udev: /lib/udev/rules.d/56-lvm.rules:40 Invalid value for OPTIONS key, ignoring: 'event_timeout=180'

[Michael Biebl]

control: reassign -1 lvm2

Am 09.12.19 um 00:43 schrieb Vincent Lefevre:
> Package: udev
> Version: 244-3
> Severity: minor
> 
> I get the following message in the journalctl output:
> 
> Dec 09 00:10:17 zira systemd-udevd[477]: /lib/udev/rules.d/56-lvm.rules:40 
> Invalid value for OPTIONS key, ignoring: 'event_timeout=180'
> Dec 09 00:10:17 zira systemd-udevd[477]: /lib/udev/rules.d/56-lvm.rules:40 
> The line takes no effect, ignoring.
> 
> This was mentioned in bug 944917 (fixed in systemd/243-8), but I still
> get this message. The upstream bug
> 
>   https://github.com/systemd/systemd/issues/14062
> 
> has been closed as fixed too. Not sure what was done... It is said:
> 
>   systemd-udevd has never supported event_timeout=. The supported
>   options are listed in udev(7).
> 

This is a bug in lvm2 afaics. This issue was simply not logged before.
So reassigning.


-- 
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#941198: In support of mandatory unit files

[Russ Allbery]

Guillem Jover  writes:

> But here you do have another option, but I'm not sure it might be
> described as nicer TBH, :) something like this, or variations on this
> theme:

>   [Service]
>   Type=simple
>   EnvironmentFile=/etc/default/service-static-vars
>   EnvironmentFile=-/run/service-dynamic-vars
>   ExecStartPre=-/bin/sh -c 'echo NAME=$(hostname) >/run/service-dynamic-vars'
>   ExecStart=/usr/bin/daemon --option ${NAME}

This is a nice approach, but I don't think it quite preserves the original
behavior.  As you wrote it above, if someone changed the setting in the
/etc/default file, that would have no effect and the default would still
be used.  If you reverse the order of EnvironmentFile, it avoids that
problem, but now the legacy setting with $(hostname) will be used if it
hasn't been changed, and that will result in a literal $(hostname) in the
value.

-- 
Russ Allbery (r...@debian.org)  

Bug#946439: youtube-dl needs python3.8 for dailymotion.com

[shirish शिरीष]

Package: youtube-dl
Version: 2019.09.28-1
Severity: normal

Dear Maintainer,
 Please see https://github.com/ytdl-org/youtube-dl/issues/23256 . This
seems to be an issue with python2. Maybe you can get an updated build
as well as solve the issue so it picks or uses python3.8 instead of
python2.7 as it currently does.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages youtube-dl depends on:
ii  python33.7.5-1
ii  python3-pkg-resources  41.2.0-1

Versions of packages youtube-dl recommends:
ii  ca-certificates  20190110
ii  curl 7.67.0-2
ii  ffmpeg   7:4.2.1-2
ii  mpv  0.30.0-1
ii  phantomjs2.1.1+dfsg-2+b2
ii  python3-pyxattr  0.6.1-1+b1
ii  rtmpdump 2.4+20151223.gitfa8646d.1-2+b1
ii  wget 1.20.3-1+b2

youtube-dl suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#946438: udev: /lib/udev/rules.d/56-lvm.rules:40 Invalid value for OPTIONS key, ignoring: 'event_timeout=180'

[Vincent Lefevre]

Package: udev
Version: 244-3
Severity: minor

I get the following message in the journalctl output:

Dec 09 00:10:17 zira systemd-udevd[477]: /lib/udev/rules.d/56-lvm.rules:40 
Invalid value for OPTIONS key, ignoring: 'event_timeout=180'
Dec 09 00:10:17 zira systemd-udevd[477]: /lib/udev/rules.d/56-lvm.rules:40 The 
line takes no effect, ignoring.

This was mentioned in bug 944917 (fixed in systemd/243-8), but I still
get this message. The upstream bug

  https://github.com/systemd/systemd/issues/14062

has been closed as fixed too. Not sure what was done... It is said:

  systemd-udevd has never supported event_timeout=. The supported
  options are listed in udev(7).

-- Package-specific info:

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

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

Versions of packages udev depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libacl1   2.2.53-5
ii  libblkid1 2.34-0.1
ii  libc6 2.29-5
ii  libkmod2  26-3
ii  libselinux1   2.9-3+b1
ii  libudev1  244-3
ii  systemd-sysv  244-3
ii  util-linux2.34-0.1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  244-3

-- debconf information:
  udev/title/upgrade:
  udev/new_kernel_needed: false
  udev/sysfs_deprecated_incompatibility:
  udev/reboot_needed:

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

Bug#946415: rust-cargo Build-Depends on librust-crates-io-0.25+default-dev which doesn't exist

[Ximin Luo]

Hi,

This type of bug is a natural artifact of the way rust crates are structured 
and updated, and the Rust team is continually aware of these types of bugs. 
There is no need to file these types of bugs for packages in unstable as the 
testing migration script will prevent migrations anyway, rendering a RC bug 
report unbeneficial and contributing to more paperwork for the packaging team.

Best,
Ximin

Paul Gevers:
> Source: rust-cargo
> Version: 0.37.0-1
> Severity: serious
> Tags: ftbfs sid bullseye
> Justification: ftbfs
> 
> Dear maintainers,
> 
> Your package Build-Depends on librust-crates-io-0.25+default-dev but that
> package doesn't exist.
> 
> Paul
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'testing-debug')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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
> 
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#946437: systemd-udevd: event4: Failed to call EVIOCSKEYCODE with scan code 0x70068, and key code 110: Invalid argument

[Vincent Lefevre]

Package: udev
Version: 244-3
Severity: minor

I've noticed the following error (in red) in the journalctl output:

Dec 09 00:10:18 zira systemd-udevd[506]: event4: Failed to call EVIOCSKEYCODE 
with scan code 0x70068, and key code 110: Invalid argument

This is not new.

I have a file /etc/udev/hwdb.d/98-apple-keyboard.hwdb with:

evdev:input:b0003v05ACp0221*
 KEYBOARD_KEY_70068=insert  # F13: Insert

and this corresponds to

Bus 002 Device 005: ID 05ac:0221 Apple, Inc. Aluminum Keyboard (ISO)

I use the F13 key for Insert, as there is no Insert key on this
keyboard (this is a Fn key at the usual place of the Insert key
and the driver honors this specificity).

I have not seen any side effect of this error, though.

-- Package-specific info:

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

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

Versions of packages udev depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libacl1   2.2.53-5
ii  libblkid1 2.34-0.1
ii  libc6 2.29-5
ii  libkmod2  26-3
ii  libselinux1   2.9-3+b1
ii  libudev1  244-3
ii  systemd-sysv  244-3
ii  util-linux2.34-0.1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  244-3

-- debconf information:
  udev/title/upgrade:
  udev/new_kernel_needed: false
  udev/reboot_needed:
  udev/sysfs_deprecated_incompatibility:

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

Bug#944742: assimp: testsuite regression

[Gianfranco Costamagna]

control: notfixed -1 5.0.0~ds2-2
control: reopen -1

Hello, looks like it is still failing, but looks better than before,
please have another look

http://debomatic-amd64.debian.net/distribution#unstable/assimp/5.0.0~ds2-2/autopkgtest

** Loaded 138 models, got controlled errors for 35 files
autopkgtest [23:52:58]: test quicktest.py: ---]
quicktest.py FAIL non-zero exit status 4
autopkgtest [23:52:58]: test quicktest.py:  - - - - - - - - - - results - - - - 
- - - - - -
autopkgtest [23:52:58]:  summary
command1 PASS
quicktest.py FAIL non-zero exit status 4

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/a/assimp/20191208_161048_be877@/log.gz


thanks!

Gianfranco

Bug#942651: Bugreport use a outdated URL

[John Scott]

> bugreport use the outeded URL
> 
> Forwarded-To: https://bugzilla.gnome.org/show_bug.cgi?id=
> 
> instead of
> 
> Forwarded-To: https://gitlab.gnome.org/GNOME/evolution/issues/

Is this about the other bugs on the Evolution Debian package having outdated 
URLs (like [1]), or a reportbug template using them?
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746461

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

Bug#946436: libplplot-data: missing Breaks+Replaces: libplplot17 (<< 5.15.0+dfsg-8)

[Andreas Beckmann]

Package: libplplot-data
Version: 5.15.0+dfsg-8
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libplplot-data_5.15.0+dfsg-8_all.deb ...
  Unpacking libplplot-data (5.15.0+dfsg-8) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libplplot-data_5.15.0+dfsg-8_all.deb (--unpack):
   trying to overwrite '/usr/share/plplot5.15.0/cglobe.shp', which is also in 
package libplplot17:amd64 5.15.0+dfsg-7
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libplplot-data_5.15.0+dfsg-8_all.deb


cheers,

Andreas


libplplot17=5.15.0+dfsg-7_libplplot-data=5.15.0+dfsg-8.log.gz
Description: application/gzip

Bug#946345: proftpd-dfsg: CVE-2019-19269

[Hilmar Preuße]

Am 07.12.2019 um 16:42 teilte Salvatore Bonaccorso mit:

Hi,

> The following vulnerability was published for proftpd-dfsg.
> 
The uploads to unstable are made.

Please find attached the debdiff patches for buster and stretch. I did
not test the code at all (except that build runs OK), but the change
seems to be rather trivial to me.

Hilmar
-- 
sigfault
#206401 http://counter.li.org
diff -Nru proftpd-dfsg-1.3.6/debian/changelog 
proftpd-dfsg-1.3.6/debian/changelog
--- proftpd-dfsg-1.3.6/debian/changelog 2019-10-23 16:22:38.0 +0200
+++ proftpd-dfsg-1.3.6/debian/changelog 2019-12-08 16:19:57.0 +0100
@@ -1,3 +1,12 @@
+proftpd-dfsg (1.3.6-4+deb10u3) buster-security; urgency=medium
+
+  * Cherry pick patch from upstream:
+ - for upstream 861 (CVE-2019-19269) (Closes: #946345)
+ - for upstream 859 (CVE-2019-19270) (Closes: #946346)
+ upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
+
+ -- Hilmar Preusse   Sun, 08 Dec 2019 16:19:57 +0100
+
 proftpd-dfsg (1.3.6-4+deb10u2) buster-security; urgency=medium
 
   * Add patch from upstream to address CVE-2019-18217.
diff -Nru proftpd-dfsg-1.3.6/debian/patches/series 
proftpd-dfsg-1.3.6/debian/patches/series
--- proftpd-dfsg-1.3.6/debian/patches/series2019-10-23 16:22:38.0 
+0200
+++ proftpd-dfsg-1.3.6/debian/patches/series2019-12-08 16:19:14.0 
+0100
@@ -19,3 +19,4 @@
 github_pr_594
 CVE-2019-12815.patch
 bug_846_CVE-2019-18217.patch
+upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
diff -Nru 
proftpd-dfsg-1.3.6/debian/patches/upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
 
proftpd-dfsg-1.3.6/debian/patches/upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
--- 
proftpd-dfsg-1.3.6/debian/patches/upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
   1970-01-01 01:00:00.0 +0100
+++ 
proftpd-dfsg-1.3.6/debian/patches/upstream_pull_859_861_CVE-2019-19270_CVE-2019-19269
   2019-12-08 16:19:26.0 +0100
@@ -0,0 +1,35 @@
+From 81cc5dce4fc0285629a1b08a07a109af10c208dd Mon Sep 17 00:00:00 2001
+From: TJ Saunders 
+Date: Sun, 24 Nov 2019 14:03:54 -0800
+Subject: [PATCH] Issue #859, #861: Fix handling of CRL lookups by properly
+ using issuer for lookups, and guarding against null pointers.
+
+---
+ contrib/mod_tls.c | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- proftpd-dfsg.orig/contrib/mod_tls.c
 proftpd-dfsg/contrib/mod_tls.c
+@@ -8968,10 +8968,10 @@
+ 
+ #if OPENSSL_VERSION_NUMBER >= 0x1010L && \
+ !defined(HAVE_LIBRESSL)
+-  crls = X509_STORE_CTX_get1_crls(store_ctx, subject);
++  crls = X509_STORE_CTX_get1_crls(store_ctx, issuer);
+ #elif OPENSSL_VERSION_NUMBER >= 0x1000L && \
+   !defined(HAVE_LIBRESSL)
+-  crls = X509_STORE_get1_crls(store_ctx, subject);
++  crls = X509_STORE_get1_crls(store_ctx, issuer);
+ #else
+   /* Your OpenSSL is before 1.0.0.  You really need to upgrade. */
+   crls = NULL;
+@@ -8990,6 +8990,9 @@
+ ASN1_INTEGER *sn;
+ 
+ revoked = sk_X509_REVOKED_value(X509_CRL_get_REVOKED(crl), j);
++if (revoked == NULL) {
++  continue;
++}
+ #if OPENSSL_VERSION_NUMBER >= 0x1010L && \
+ !defined(HAVE_LIBRESSL)
+ sn = X509_REVOKED_get0_serialNumber(revoked);
diff -Nru proftpd-dfsg-1.3.5b/debian/changelog 
proftpd-dfsg-1.3.5b/debian/changelog
--- proftpd-dfsg-1.3.5b/debian/changelog2019-10-23 23:34:50.0 
+0200
+++ proftpd-dfsg-1.3.5b/debian/changelog2019-12-08 16:52:34.0 
+0100
@@ -1,3 +1,11 @@
+proftpd-dfsg (1.3.5b-4+deb9u3) stretch-security; urgency=medium
+
+  *  Cherry pick patch from upstream:
+ - for upstream 861 (CVE-2019-19269) (Closes: #946345)
+ upstream_pull_861_CVE-2019-19269
+
+ -- Hilmar Preusse   Sun, 08 Dec 2019 16:52:34 +0100
+
 proftpd-dfsg (1.3.5b-4+deb9u2) stretch-security; urgency=high
 
   * Add patch from upstream to address CVE-2019-18217.
diff -Nru proftpd-dfsg-1.3.5b/debian/patches/series 
proftpd-dfsg-1.3.5b/debian/patches/series
--- proftpd-dfsg-1.3.5b/debian/patches/series   2019-10-23 23:24:27.0 
+0200
+++ proftpd-dfsg-1.3.5b/debian/patches/series   2019-12-08 16:52:34.0 
+0100
@@ -17,3 +17,4 @@
 CVE-2017-7418
 proftpd-1.3.5e-CVE-2019-12815.patch
 bug_846_CVE-2019-18217.patch
+upstream_861_CVE-2019-19269
diff -Nru proftpd-dfsg-1.3.5b/debian/patches/upstream_861_CVE-2019-19269 
proftpd-dfsg-1.3.5b/debian/patches/upstream_861_CVE-2019-19269
--- proftpd-dfsg-1.3.5b/debian/patches/upstream_861_CVE-2019-19269  
1970-01-01 01:00:00.0 +0100
+++ proftpd-dfsg-1.3.5b/debian/patches/upstream_861_CVE-2019-19269  
2019-12-08 16:52:34.0 +0100
@@ -0,0 +1,12 @@
+--- proftpd-dfsg.orig/contrib/mod_tls.c
 proftpd-dfsg/contrib/mod_tls.c
+@@ -5862,6 +5862,9 @@
+   ASN1_INTEGER *sn;
+ 
+   revoked = sk_X509_REVOKED_value(X509_CRL_get_REVOKED(crl), i);
++  if (revoked == NULL) {
++  continue;
++  }
+   sn = revoked->serialNumber;
+ 
+   if (ASN1_INTEGER_cmp(sn, 

Bug#877802: lintian: Please include file name and line number in output

[Chris Lamb]

Felix,

> Please let me pick your brain. My current solution is to instantiate
> tags as they are issued, but they are a bit cumbersome to use. 

I cannot recall I had a more concise approach beyond a bunch of
dirty "tag_with_filename"-like helpers/wrappers. Just to be clear,
this was very much a proof-of-concept.


Regards,

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

Bug#942261: reportbug: When searching for executables in packages, consider full PATH not first match

[Nis Martensen]

control: tags -1 patch

On 13 Oct 2019 Witold Baryluk wrote:
> $ ls -l / | grep bin
> lrwxrwxrwx   1 root root7 Oct 10 14:23 bin -> usr/bin
> lrwxrwxrwx   1 root root8 Oct 10 14:23 sbin -> usr/sbin
> $
> 
> 
> reportbug can probably be smarter here about this.
> 
> There might be multiple ways to solve this problem, but one of the
> simpler ones might be to inspect all elements of PATH, or add special
> cases for {/usr,}/bin and {/usr,}/sbin.

Thank you for your report. This should fix it:
https://salsa.debian.org/reportbug-team/reportbug/merge_requests/42

Bug#946435: texlive-latex-recommended: Missing Breaks+Replaces texlive-latex-extra 2019.20191112-1

[Stuart Prescott]

Package: texlive-latex-recommended
Version: 2019.20191208-1
Severity: serious
Justification: Policy 7.6 overwriting files in other packages

Dear Maintainer,

Upgrading texlive packages in sid generates the following.

Preparing to unpack .../3-texlive-latex-recommended_2019.20191208-1_all.deb ...
Unpacking texlive-latex-recommended (2019.20191208-1) over (2019.20191112-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-qFj4g6/3-texlive-latex-recommended_2019.20191208-1_all.deb
 (--unpack):
 trying to overwrite 
'/usr/share/texlive/texmf-dist/tex/latex/grffile/grffile-2017-06-30.sty', which 
is also in package texlive-latex-extra 2019.20191112-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

An appropriate Breaks+Replaces will need to be added to the package.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

regards
Stuart

Bug#946431: texlive-latex-recommended{,-doc}: missing Breaks+Replaces: texlive-latex-extra{,-doc} (<< 2019.20191208)

[Hilmar Preuße]

Control: merge -1 946429

Am 08.12.2019 um 23:28 teilte Andreas Beckmann mit:

> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> 
Merge.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#940491: src:meep: missing several Breaks+Replaces

[Andreas Beckmann]

Followup-For: Bug #940491
Control: found -1 1.12.0-2

  Preparing to unpack .../libmeep17_1.12.0-2_amd64.deb ...
  Unpacking libmeep17 (1.12.0-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libmeep17_1.12.0-2_amd64.deb (--unpack):
   trying to overwrite '/usr/share/meep/casimir.scm', which is also in package 
libmeep-mpi-default12 1.7.0-3+b1
  Preparing to unpack .../meep_1.12.0-2_amd64.deb ...
  Unpacking meep (1.12.0-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/meep_1.12.0-2_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/meep', which is also in package 
meep-mpi-default 1.7.0-3+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libmeep17_1.12.0-2_amd64.deb
   /var/cache/apt/archives/meep_1.12.0-2_amd64.deb

probably for the mpich, openmpi, lam variants, too.


Andreas

Bug#946434: /usr/games/ace-freecell: feature request: add undo funktion

[treaki]

Package: ace-of-penguins
Version: 1.5~rc2-3
Severity: normal
File: /usr/games/ace-freecell

Dear Maintainer,
dear developer,
(please forward)

the ace of pinguin cardgames work grate, but it would be much better if 
you would provide an undo feature like sgt- suite dose, with u and 
crtl+z to undo and r and ctrl+y or ctrl+shift+z to redo all steps.


thanks in advance and keep up the good work

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=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 ace-of-penguins depends on:
ii  libc62.28-2
ii  libpng16-16  1.6.34-2
ii  libx11-6 2:1.6.7-1

Versions of packages ace-of-penguins recommends:
ii  xfonts-100dpi  1:1.0.4+nmu1

ace-of-penguins suggests no packages.

-- no debconf information

Bug#941961: reportbug: nudge novice bug submitters away from incorrectly using the newcomer tag

[Nis Martensen]

control: tags -1 patch

On 08 Oct 2019 Paul Wise wrote:
> I was thinking that reportbug should hide the display of the newcomer
> tag from the tag list when the reportbug mode is novice.

In novice mode reportbug does not initially show the tag menu at all,
only before submission the user can still choose to enter a dialog to
add tags.

We could still hide the newcomer tag from the tag list in that case:
https://salsa.debian.org/reportbug-team/reportbug/merge_requests/41

Bug#946433: python3-jpylyzer: missing Breaks+Replaces: python-jpylyzer (<< 1.18.0-3.1)

[Andreas Beckmann]

Package: python3-jpylyzer
Version: 1.18.0-3.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-jpylyzer_1.18.0-3.1_all.deb ...
  Unpacking python3-jpylyzer (1.18.0-3.1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-jpylyzer_1.18.0-3.1_all.deb (--unpack):
   trying to overwrite '/usr/bin/jpylyzer', which is also in package 
python-jpylyzer 1.18.0-3
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-jpylyzer_1.18.0-3.1_all.deb


cheers,

Andreas


python-jpylyzer=1.18.0-3_python3-jpylyzer=1.18.0-3.1.log.gz
Description: application/gzip

Bug#941198: In support of mandatory unit files

[Guillem Jover]

On Sun, 2019-12-08 at 11:15:57 -0800, Russ Allbery wrote:
> > Sure, help fir that would be nice. Thanks for the offer.  (Probably
> > should have an own bug for that.) Nethertheless, this is the line that
> > causes my problems and needs to be transferred:
> > https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8
> 
> Ah, I see, the problem is the $(hostname) part, which isn't supported by
> EnvironmentFile in systemd (which is the normal way to solve this
> problem).
> 
> After looking at this for a bit, my inclination if I were you would be to
> write a tiny shell script that loads /etc/default/gmediarender, constructs
> the command line, and then execs the daemon; install that script as
> /usr/share/gmediarender/start; and then invoke that script via
> start-stop-daemon in the init script and via ExecStart in the systemd unit
> file.  It's a little bit overkill because most of what the /etc/default
> file is doing is simple, but it looks like the easiest way to handle
> $(hostname).

I'd avoid using the wrapper for the init script TBH, because even
though that will make this a bit WET, it would otherwise make it more
complex there (having to use --startas and --exec to cope with the
intermediate interpreter usage).

I think shared wrappers make more sense when used to offload some kind of
pre/post "hook" work, which gets called from Exec{Start,Stop}{Pre,Post}
systemd service file directives (and init scripts).

But here you do have another option, but I'm not sure it might be
described as nicer TBH, :) something like this, or variations on this
theme:

  [Service]
  Type=simple
  EnvironmentFile=/etc/default/service-static-vars
  EnvironmentFile=-/run/service-dynamic-vars
  ExecStartPre=-/bin/sh -c 'echo NAME=$(hostname) >/run/service-dynamic-vars'
  ExecStart=/usr/bin/daemon --option ${NAME}

Thanks,
Guillem

Bug#946432: jenkins-debian-glue: lintian.txt is not copied when lintian runs inside the build env

[Antoine Musso]

Source: jenkins-debian-glue
Version: 0.20.0
Severity: normal

Dear Maintainer,

When using LINTIAN=yes, lintian runs inside the build environment.
The output is redirected to lintian.txt which has to be copied out
of the build environment for further processing.

It used to work fine with Jessie but with Buster the lintian.txt
is not copied.

The issue is fixed by:

https://github.com/mika/jenkins-debian-
glue/commit/c79eb1581c52c5ba67123e955c44b61b3bfdb6b4

Which as been released upstream as 0.20.1.

This bug report is asking to cherry-pick the patch for
the Buster package (0.20.0).

--
Workaround is to set ADDITIONAL_BUILDRESULTS in .pbuilderrc or
in job-pbuilderrc.



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

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

Bug#941257: reportbug: If you choose to save the file rather than email it, you are not given the choice were the file to be saved or told where it has been saved on exit

[Nis Martensen]

control: tags -1 patch

On 27 Sep 2019 David Goodenough wrote:
> 
> In the absense of proper integration with kmail (I see there is another bug
> reported about that) I use the save to file option and then load the file into
> kmail to send.  When you press the save to file option that is the last thing
> you see, not even a console message saying where the file has been saved and
> what it is called.

Thank you for the report. The problem exists only in the GTK+ interface.
We can make this UI show the output file name with a small change:
https://salsa.debian.org/reportbug-team/reportbug/merge_requests/40

> Being able to copy to clipboard or choose the destination directory (and
> possibly even file name) would be a great boon.

In the meantime you can also start reportbug from a terminal and use the
-o (or --output) option to specify the output file name, or use the text UI.

Bug#946431: texlive-latex-recommended{,-doc}: missing Breaks+Replaces: texlive-latex-extra{,-doc} (<< 2019.20191208)

[Andreas Beckmann]

Package: texlive-latex-recommended,texlive-latex-recommended-doc
Version: 2019.20191208-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Unpacking texlive-latex-recommended (2019.20191208-1) over (2019.20191112-1) 
...
  dpkg: error processing archive 
/var/cache/apt/archives/texlive-latex-recommended_2019.20191208-1_all.deb 
(--unpack):
   trying to overwrite 
'/usr/share/texlive/texmf-dist/tex/latex/grffile/grffile-2017-06-30.sty', which 
is also in package texlive-latex-extra 2019.20191112-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/texlive-latex-recommended_2019.20191208-1_all.deb

  Preparing to unpack .../texlive-latex-recommended-doc_2019.20191208-1_all.deb 
...
  Unpacking texlive-latex-recommended-doc (2019.20191208-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/texlive-latex-recommended-doc_2019.20191208-1_all.deb 
(--unpack):
   trying to overwrite '/usr/share/doc/texlive-doc/latex/grffile/README.md', 
which is also in package texlive-latex-extra-doc 2019.20191112-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/texlive-latex-recommended-doc_2019.20191208-1_all.deb


cheers,

Andreas


texlive-latex-extra=2019.20191112-1_texlive-latex-recommended=2019.20191208-1.log.gz
Description: application/gzip

Bug#946430: texlive-latex-recommended: missing Breaks+Replaces: texlive-latex-base (<< 2019.20191208)

[Andreas Beckmann]

Package: texlive-latex-recommended
Version: 2019.20191208-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../texlive-latex-recommended_2019.20191208-1_all.deb ...
  Unpacking texlive-latex-recommended (2019.20191208-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/texlive-latex-recommended_2019.20191208-1_all.deb 
(--unpack):
   trying to overwrite '/usr/bin/pdfatfi', which is also in package 
texlive-latex-base 2019.20191112-1
  Errors were encountered while processing:
   /var/cache/apt/archives/texlive-latex-recommended_2019.20191208-1_all.deb


cheers,

Andreas

Bug#946429: texlive-latex-recommended: File conflict with old texlive-latex-extra

[Sven Joachim]

Package: texlive-latex-recommended
Version: 2019.20191208-1
Severity: serious

Once again a file has moved to a different package without proper
Breaks+Replaces:

,
| Vorbereitung zum Entpacken von 
.../01-texlive-latex-recommended_2019.20191208-1_all.deb ...
| Entpacken von texlive-latex-recommended (2019.20191208-1) über 
(2019.20191112-1) ...
| dpkg: Fehler beim Bearbeiten des Archivs 
/tmp/apt-dpkg-install-W9Ippi/01-texlive-latex-recommended_2019.20191208-1_all.deb
 (--unpack):
|  Versuch, 
»/usr/share/texlive/texmf-dist/tex/latex/grffile/grffile-2017-06-30.sty« zu 
überschreiben, welches auch in Paket texlive-latex-extra 2019.20191112-1 ist
| dpkg-deb: Fehler: »einfügen«-Unterprozess wurde durch Signal (Datenübergabe 
unterbrochen (broken pipe)) getötet
`

After upgrading texlive-latex-extra the installation of
texlive-latex-recommended succeeded.


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

Kernel: Linux 5.4.2-nouveau (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
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)

Versions of packages texlive-latex-recommended depends on:
ii  tex-common  6.13
ii  texlive-base2019.20191208-1
ii  texlive-binaries2019.20190605.51237-3
ii  texlive-latex-base  2019.20191208-1

texlive-latex-recommended recommends no packages.

Versions of packages texlive-latex-recommended suggests:
ii  texlive-latex-recommended-doc  2019.20191208-1
pn  texlive-luatex 
pn  texlive-pstricks   

Versions of packages tex-common depends on:
ii  dpkg  1.19.7
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
ii  debhelper  12.7.2

Versions of packages texlive-latex-recommended is related to:
ii  tex-common6.13
ii  texlive-binaries  2019.20190605.51237-3

-- debconf information:
  tex-common/singleuser: false
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:

Bug#946428: texlive-base: missing Breaks+Replaces: texlive-extra-utils (<< 2019.20191208)

[Andreas Beckmann]

Package: texlive-base
Version: 2019.20191208-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../texlive-base_2019.20191208-1_all.deb ...
  Unpacking texlive-base (2019.20191208-1) over (2019.20191112-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/texlive-base_2019.20191208-1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man1/e2pall.1.gz', which is also in 
package texlive-extra-utils 2019.20191112-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/texlive-base_2019.20191208-1_all.deb

The following conflicting files seem to have been moved:

  usr/bin/e2pall
  usr/share/man/man1/e2pall.1.gz
  usr/share/texlive/texmf-dist/scripts/texlive/e2pall.pl


cheers,

Andreas


texlive-extra-utils=2019.20191112-1_texlive-base=2019.20191208-1.log.gz
Description: application/gzip

Bug#945165: Broken localisation

[Kjö Hansi Glaz]

I belive the bug is fixed in upstream master.

Bug#945167: SVG icon isn't found

[Kjö Hansi Glaz]

I belive the bug is fixed in upstream master.

Bug#945168: GTK button looks wrong

[Kjö Hansi Glaz]

I belive the bug is fixed in upstream master.

Louis-Philippe Véronneau:
> Package: bookletimposer
> Version: 0.3~beta1-1
> Severity: minor
> 
> The button for the "Copy the same group of input pages..." in the
> main GUI window looks wrong. I've attached a screenshot.
> 

Bug#583125: Tag name changed to 'manpage-without-executable'

[Felix Lechner]

After a discussion, the tag was renamed to
'manpage-without-executable'. It was determined to be a better name.


https://salsa.debian.org/lintian/lintian/commit/bc72fd36befed69b22cf435e78058a08f9a21935

Kind regards
Felix Lechner

Bug#946268: Please add support for custom entries

[andreimpopescu]

On Du, 08 dec 19, 14:38:49, Jonas Smedegaard wrote:
> Quoting andreimpope...@gmail.com (2019-12-08 11:10:25)
> > 
> > Ok, attached a patch against u-boot-menu on Salsa/debian implementing 
> > this.
> > 
> > Comments welcome :)
> 
> Please share the patch as attachment here instead.

I did, see my other message (forgot to attach it the first time).

Attached again for your convenience.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
From c36cbdd65e3bc9c4c6dc41fceda5463d52dcf5d7 Mon Sep 17 00:00:00 2001
From: Andrei POPESCU 
Date: Sun, 8 Dec 2019 11:53:36 +0200
Subject: [PATCH] Add option to append one or more custom entries from an
 external file

This patch adds a new option U_BOOT_CUSTOM_ENTRIES to specify an
external file to be appended to extlinux.conf.

default:
Add the new option commented out, with a suggested filename.

u-boot-update:
Do some basic checks on the file (exists, regular file, readable,
non-zero length).
Issue a warning in case the file is not owned by root, but don't
error out (the sysadmin may have good reasons for that).

u-boot-update.8:
Document the new option in the manpage, including some safety/security
warnings.
---
 default |  1 +
 u-boot-update   | 35 +++
 u-boot-update.8 |  2 ++
 3 files changed, 38 insertions(+)

diff --git a/default b/default
index 4389a87..7e6804d 100644
--- a/default
+++ b/default
@@ -11,4 +11,5 @@
 #U_BOOT_TIMEOUT="50"
 #U_BOOT_FDT=""
 #U_BOOT_FDT_DIR="/usr/lib/linux-image-"
+#U_BOOT_CUSTOM_ENTRIES="/etc/default/u-boot-custom"
 
diff --git a/u-boot-update b/u-boot-update
index 2bf151b..9302f7a 100755
--- a/u-boot-update
+++ b/u-boot-update
@@ -216,5 +216,40 @@ done
 
 _NUMBER=""
 
+# Append custom entries if any
+if [ -n "${U_BOOT_CUSTOM_ENTRIES}" ]
+then
+if [ ! -f "${U_BOOT_CUSTOM_ENTRIES}" ]
+then
+echo 'E: The file '"${U_BOOT_CUSTOM_ENTRIES}"' does not exist or is not a regular file'
+exit 1
+fi
+
+if [ ! -r "${U_BOOT_CUSTOM_ENTRIES}" ]
+then
+echo 'E: The file '"${U_BOOT_CUSTOM_ENTRIES}"' is unreadable'
+exit 1
+fi
+
+if [ ! -s "${U_BOOT_CUSTOM_ENTRIES}" ]
+then
+echo 'E: The file '"${U_BOOT_CUSTOM_ENTRIES}"' is empty'
+exit 1
+fi
+
+if [ ! -O "${U_BOOT_CUSTOM_ENTRIES}" ]
+then
+echo 'W: The file '"${U_BOOT_CUSTOM_ENTRIES}"' is NOT owned by root'
+fi
+
+echo 'P: Appending custom entries from '"${U_BOOT_CUSTOM_ENTRIES}"'...'
+
+# Writing custom entries
+_CONFIG="${_CONFIG}
+
+$(< "${U_BOOT_CUSTOM_ENTRIES}")
+"
+fi
+
 Update "${_U_BOOT_DIRECTORY}/extlinux.conf" "${_CONFIG}"
 
diff --git a/u-boot-update.8 b/u-boot-update.8
index 3397bc8..7c209b4 100644
--- a/u-boot-update.8
+++ b/u-boot-update.8
@@ -26,6 +26,8 @@ This variable specifies additional boot parameters that are appended to each ker
 This variable specifies the root partition. It is automatically extracted from /etc/fstab. U\-BOOT supports both devices and UUIDs.
 .IP "U_BOOT_TIMEOUT=""\fB50\fR""" 4
 This variable specifies the time that U\-BOOT should wait for user input during boot. Values are in decisecond greater than 0 (e.g. '10' for a 1 second timeout), 0 specifies to wait forever. The default is 50.
+.IP "U_BOOT_CUSTOM_ENTRIES=""/path/to/file""" 4
+This variable specifies the name of a file containing one or more custom entries. The file is appended \fBas is\fR, without any checks for validity or safety. For security reasons the file should not be writable to untrusted users as it can be used to gain root access to the system (e.g. by adding a boot entry with "init=/bin/sh" as kernel parameter). u\-boot\-update will issue a warning if the file is not owned by root.
 
 .SH FILES
 /etc/default/u-boot
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#946427: python3-vcf: missing Breaks+Replaces: python3-pyvcf

[Andreas Beckmann]

Package: python3-vcf
Version: 0.6.8+git20170215.476169c-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-vcf_0.6.8+git20170215.476169c-3_amd64.deb ...
  Unpacking python3-vcf (0.6.8+git20170215.476169c-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-vcf_0.6.8+git20170215.476169c-3_amd64.deb 
(--unpack):
   trying to overwrite 
'/usr/lib/python3/dist-packages/PyVCF-0.6.8.egg-info/PKG-INFO', which is also 
in package python3-pyvcf 0.6.8+git20170215.476169c-2+b1
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-vcf_0.6.8+git20170215.476169c-3_amd64.deb


cheers,

Andreas


python3-pyvcf=0.6.8+git20170215.476169c-2+b1_python3-vcf=0.6.8+git20170215.476169c-3.log.gz
Description: application/gzip

Bug#946425: python3-pubsub: missing Breaks+Replaces: python3-pypubsub

[Andreas Beckmann]

Package: python3-pubsub
Version: 4.0.3-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-pubsub_4.0.3-3_all.deb ...
  Unpacking python3-pubsub (4.0.3-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-pubsub_4.0.3-3_all.deb (--unpack):
   trying to overwrite 
'/usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info/PKG-INFO', which is 
also in package python3-pypubsub 4.0.3-2
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-pubsub_4.0.3-3_all.deb


cheers,

Andreas


python3-pypubsub=4.0.3-2_python3-pubsub=4.0.3-3.log.gz
Description: application/gzip

Bug#946426: python-pbcore: depends on old pylint3

[Gianfranco Costamagna]

Source: python-pbcore
Version: 1..7.1+git20191121.7947eb7+dfsg-2
Severity: serious

Hello, please switch pylint3 version to pylint, because the pylint3 is a cruft 
package, not built anymore

thanks

Gianfranco

Bug#944856: qtbase-opensource-src 5.11.3+dfsg1-1+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 944856 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: qtbase-opensource-src
Version: 5.11.3+dfsg1-1+deb10u2

Explanation: add support for non-PPD printers and avoid silent fallback to a 
printer supporting PPD; fix crash when using QLabels with rich text; fix 
graphics tablet hover events

Bug#946424: libopenvr-dev: missing Breaks+Replaces: libopenvr-api-dev

[Andreas Beckmann]

Package: libopenvr-dev
Version: 1.8.19~ds1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libopenvr-dev.
  Preparing to unpack .../libopenvr-dev_1.8.19~ds1-2_amd64.deb ...
  Unpacking libopenvr-dev (1.8.19~ds1-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libopenvr-dev_1.8.19~ds1-2_amd64.deb (--unpack):
   trying to overwrite '/usr/include/openvr/openvr.h', which is also in package 
libopenvr-api-dev 1.8.19~ds1-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libopenvr-dev_1.8.19~ds1-2_amd64.deb


cheers,

Andreas

Bug#946402: raspi3-firmware 1.20190215-1+deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 946402 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: raspi3-firmware
Version: 1.20190215-1+deb10u2

Explanation: fix detection of serial console with kernel 5.x

Bug#946423: ITP: ruby-optimist -- Commandline option parser for Ruby that just gets out of your way.

[Stig Sandbeck Mathisen]

Package: wnpp
Severity: wishlist
Owner: Stig Sandbeck Mathisen 

* Package name: ruby-optimist
  Version : 3.0.0
  Upstream Author : William Morgan, Keenan Brock, Jason Frey
* URL : https://www.manageiq.org/optimist/
* License : MIT/Expat
  Programming Lang: Ruby
  Description : Commandline option parser for Ruby that just gets out of 
your way.


Upstream description


Optimist is a commandline option parser for Ruby that just gets out of your
way.  One line of code per option is all you need to write. For that, you get a
nice automatically-generated help page, robust option parsing, and sensible
defaults for everything you don't specify.

Features:

- Dirt-simple usage.
- Sensible defaults. No tweaking necessary, much tweaking possible.
- Support for long options, short options, subcommands, and automatic type
  validation and conversion.
- Automatic help message generation, wrapped to current screen width.


Packaging and maintenance
-

The upstream project name has been changed from trollop to optimist.
(https://github.com/ManageIQ/optimist/issues/92)

ruby-optimist is a dependency for hiera-eyaml >= 3.0.0, and needs to be
available before newer versions of hiera-eyaml can be imported.

ruby-optimist will be maintained under the debian-ruby team umbrella.

Bug#941633: synfigstudio crashes on almost every operation

[VA]

retitle 941633 synfigstudio crashes on almost every operation
severity 941633 serious
thanks

In fact, it's much more general than just when importing an image, it 
crashes for almost everything.


Here are a few example scenarios where synfigstudio crashes:

- start synfigstudio
- draw a rectangle
- press ctrl-z (undo)
-> synfigstudio segfaults

or

- start synfigstudio
- draw 2 rectangles
- select both rectangles
- choose "group layer"
-> synfigstudio segfaults

etc.

Sometimes it doesn't segfault but will fail to do something basic:

- start synfigstudio
- draw a rectangle
- delete the rectangle layer
-> synfigstudio doesn't do it and pop an error dialog mentioning 
"std::exception"


Same when trying to move layers, etc.

In this current state, synfigstudio is unusable.

Bug#933820: WIP

[Leo "Costela" Antunes]

Hi Lee,

Unfortunately this stalled a bit since my request to join the DMPT[0]
apparently went under the radar.

I'll ping the lists and see if I can get the ball rolling again.

Cheers,
Leo

[0] https://lists.debian.org/debian-python/2019/08/msg00152.html

On Sun, Dec 8, 2019 at 4:03 PM Lee Garrett  wrote:
>
> Hi Leo!
>
> On Sun, 4 Aug 2019 03:41:05 +0200 "Leo \"Costela\" Antunes"
>  wrote:
> > FYI, some WIP is on: https://salsa.debian.org/costela/hcloud-python
> > This will hopefully be moved to the python-modules group eventually.
> >
> > Cheers
>
> is there any progress on the ITP of python3-hcloud? It sounds like a
> useful package to me. :)
>
> Greetings,
> Lee

Bug#603757: (no subject)

[Aurélien COUDERC]

Version: 5:77
Hi,

marking this fixed 5:77 / Plasma 4.8.4 since upstream said it was fixed in 
4.8.4.

Feel free to open a new bug if you still experience similar issues.


Happy hacking !
--
Aurélien

Bug#946418: lazygal: gst-stream-error-quark converting mp4 video

[alain]

Package: lazygal
Version: 0.9.3-1
Severity: normal

Dear Maintainer,

Converting mp4 videos hangs with errors :
  TRANSCODE P1030181_video.webm
transcoding P1030181.MP4 failed, skipped  
Pipeline is stalled, this is a problem either in gst or in lazygal's
use of gst
...
  VIDEOTHUMB P1030181_thumb.jpg 
creating P1030181.MP4 thumbnail failed, skipped
(gerror=GLib.Error('Internal data stream error.',
'gst-stream-error-quark', 1), debug='qtdemux.c(5850):
gst_qtdemux_loop ():

/GstPipeline:pipeline9/GstDecodeBin:decodebin27/GstQTDemux:qtdemux18:\nstreaming
stopped, reason not-linked (-1)')
  P1030181.MP4 is BROKEN, skipped   

Regard.



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

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

Versions of packages lazygal depends on:
ii  gir1.2-gexiv2-0.10  0.10.4-2
ii  python3 3.5.3-1
ii  python3-genshi  0.7-5
ii  python3-gi  3.22.0-2
ii  python3-pil 4.0.0-4

lazygal recommends no packages.

Versions of packages lazygal suggests:
ii  gir1.2-gst-plugins-base-1.0  1.10.4-1+deb9u1
ii  gir1.2-gstreamer-1.0 1.10.4-1
ii  gstreamer1.0-plugins-base1.10.4-1+deb9u1
ii  gstreamer1.0-plugins-good1.10.4-1
ii  python3-gst-1.0  1.10.4-1

-- no debconf information

Bug#946422: silx: autopkgtest regression: pocl error

[Graham Inggs]

Source: silx
Version: 0.11.0+dfsg-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

The autopkgtests of silx have regressed in testing [1].
I have copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/s/silx/testing/amd64/


opencl.common:Last chance to get an OpenCL device ... probably not the
one requested
pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close
resident module'.
note: missing symbols in the kernel binary might be reported as 'file
not found' errors.
Aborted

Bug#946420: kpat is spamming with error messages

[Hans-J. Ullrich]

Package: kpat
Version: 4:18.04.1-1
Severity: important

Dear Maintainer,

I discovered that kpat is spamming the file ~/.xsession_errors with lots and 
lots of messages. Within a few minutes 
the file is grown up to several megabytes, while playing a longer time the 
.xsession_errors has grown to several gigabytes.

Workaround is: Delete this file, it will not recreated after next start of the 
windowmanager.

It would be nice, if you could take as look at it. The version 19.0.X is 
spamming, whilst the version 18.0.XXX is working well.

Thank you very much for your help.

Best regards

Hans
 


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

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

Versions of packages kpat depends on:
ii  kdegames-card-data-kf5  4:19.08.1-2
ii  kio 5.62.1-2+b1
ii  libc6   2.29-3
ii  libkf5completion5   5.62.0-1+b1
ii  libkf5configcore5   5.62.0-1+b1
ii  libkf5configgui55.62.0-1+b1
ii  libkf5configwidgets55.62.0-1+b1
ii  libkf5coreaddons5   5.62.0-1
ii  libkf5crash55.62.0-1+b1
ii  libkf5dbusaddons5   5.62.0-1
ii  libkf5guiaddons55.62.0-2
ii  libkf5i18n5 5.62.0-1
ii  libkf5kdegames7 4:19.08.1-2+b1
ii  libkf5kiocore5  5.62.1-2+b1
ii  libkf5newstuff5 5.62.0-1+b1
ii  libkf5widgetsaddons55.62.0-1+b1
ii  libkf5xmlgui5   5.62.0-1+b1
ii  libqt5core5a5.12.5+dfsg-2
ii  libqt5gui5  5.12.5+dfsg-2
ii  libqt5svg5  5.12.5-2
ii  libqt5widgets5  5.12.5+dfsg-2
ii  libqt5xml5  5.12.5+dfsg-2
ii  libstdc++6  9.2.1-21

Versions of packages kpat recommends:
ii  khelpcenter  4:18.04.0-1+b1

kpat suggests no packages.

-- debconf-show failed

Bug#946419: samba-vfs-modules: Resource forks are truncated when written to fruit-enabled share

[Keith Kaisershot]

Package: samba-vfs-modules
Version: 2:4.11.1+dfsg-3
Severity: important

I use vfs_fruit with a Samba share serving various older versions of Mac OS X, 
from 10.6 up through 10.11, archiving classic Mac files dating back to the mid 
80s. With the latest Samba 4.11.1 in Debian testing, writing one of these older 
files with a resource fork larger than 64K results in the resource fork portion 
getting truncated to 65454 bytes on the server end. This corrupts old Mac files 
with resource forks larger than 64K-- executables are the most affected by 
this, but graphic files such as PICT are too.

Looks like this is a regression, as this issue does not occur in 4.9.5 from 
Debian stable.

Repro steps:
1) Copy a classic 68K Mac OS application > 65K from a Mac OS X 10.11 client to 
a Samba 4.9.5 host. (I used ircle 1.5.6 as a test case here.)
2) Get Info on the newly-copied file on the 4.9.5 server and observe that the 
application's size matches that of the original file on the client.
 - Screenshot here: 
https://blitter.net/etc/rsrc_bug/Screen%20Shot%202019-12-08%20at%2012.13.23%20PM.png
3) Observe the same in Finder.
 - Screenshot here: 
https://blitter.net/etc/rsrc_bug/Screen%20Shot%202019-12-08%20at%2012.12.15%20PM.png
4) Copy the same application from the same Mac OS X 10.11 client to a Samba 
4.11.1 host.
5) Get Info on the newly-copied file on the 4.11.1 server and observe that the 
application's size has been truncated.
 - Screenshot here: 
https://blitter.net/etc/rsrc_bug/Screen%20Shot%202019-12-08%20at%2012.13.26%20PM.png
6) Observe the same in Finder.
 - Screenshot here: 
https://blitter.net/etc/rsrc_bug/Screen%20Shot%202019-12-08%20at%2012.12.35%20PM.png

My smb.conf from testparm (identical on both test hosts above except for the 
name of the share which should reflect the Samba version)-- /srv/test is 0777 
on both host filesystems (ext4):

# Global parameters
[global]
log file = /var/log/samba/log.%m
logging = file
map to guest = Bad User
max log size = 1000
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n 
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
server role = standalone server
unix password sync = Yes
usershare allow guests = Yes
idmap config * : backend = tdb
vfs objects = catia fruit streams_xattr


[4.11.1]
guest ok = Yes
path = /srv/test
read only = No


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/1 CPU core)
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 samba-vfs-modules depends on:
ii  libbsd0   0.10.0-1
ii  libc6 2.29-2
ii  libgnutls30   3.6.10-4
ii  libtalloc22.3.0-2
ii  libtdb1   1.4.2-2
ii  libtevent00.10.1-3
ii  libwbclient0  2:4.11.1+dfsg-3
ii  samba-libs2:4.11.1+dfsg-3

Versions of packages samba-vfs-modules recommends:
ii  libcephfs2   12.2.11+dfsg1-2.1+b2
ii  libdbus-1-3  1.12.16-2
ii  libgfapi07.0-1

samba-vfs-modules suggests no packages.

-- no debconf information

Bug#946421: unbound: Fails to answer TCP queries due to broken idle-timeout

[Martin Weinelt]

Package: unbound
Version: 1.9.0-2+deb10u1
Severity: important
Tags: upstream patch

Dear Maintainer,

Unbound fails to answer TCP queries when it's per thread limit is
reached. The limit however is being reached too fast because an error
introduced in 1.9.0 in some cases wrongly disables the TCP idle-timeout
on a socket.

There has been an upstream discussion and fix here:
- https://nlnetlabs.nl/pipermail/unbound-users/2019-October/011858.html
- https://github.com/NLnetLabs/unbound/pull/122

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

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

Versions of packages unbound depends on:
ii  adduser 3.118
ii  dns-root-data   2019031302
ii  libc6   2.28-10
ii  libevent-2.1-6  2.1.8-stable-4
ii  libfstrm0   0.4.0-1
ii  libprotobuf-c1  1.3.1-1+b1
ii  libpython3.73.7.3-2
ii  libssl1.1   1.1.1d-0+deb10u2
ii  libsystemd0 241-7~deb10u2
ii  lsb-base10.2019051400
ii  openssl 1.1.1d-0+deb10u2
ii  unbound-anchor  1.9.0-2+deb10u1

unbound recommends no packages.

Versions of packages unbound suggests:
ii  apparmor  2.13.2-10

-- Configuration Files:
/etc/unbound/unbound.conf changed [not included]

-- no debconf information

Bug#946417: RFS: giflib/5.1.9-1 [ITA] -- library for GIF images (utilities) - Fixes CVE's: #904114, #904113

[David Suárez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : giflib
Version : 5.1.9-1
Upstream Author : https://sourceforge.net/p/giflib/discussion/
* URL : http://giflib.sourceforge.net/
* License : MIT
* Vcs : https://salsa.debian.org/deiv-guest/giflib
Section : libs

It builds those binary packages:

giflib-tools - library for GIF images (utilities)
libgif7 - library for GIF images (library)
libgif-dev - library for GIF images (development)

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/giflib/giflib_5.1.9-1.dsc


Changes since the last upload:

  [ Ondřej Nový ]
  * d/watch: Use https protocol.

  [ Andreas Metzler ]
  * AUTHORS file not shipped anymore, update debian/*.docs.
  * Uses straight make instead of autotools, adapt debian/rules 
accordingly.

  * Use dh 12 compat level.
  + Update debian/copyright, add Format specifier.

  [ David Suárez ]
  * New upstream version:
- Add myself as maintainer; Closes: #834410.
- Fixes heap-based buffer overflow in DGifDecompressLine function.
CVE-2018-11490 sf#113; Closes: #904114
- Fixes MemorySanitizer: FPE on unknown address;
CVE-2019-15133 sf#119: Closes: #904113
  * Acknowledges NMU's uploads.
  * d/watch:
- Bump version.
- Don't run uupdate.
- Don't use debian redirector.
  * d/patches:
- Drop '03-spelling_fixes.patch' and 'CVE-2016-3977.patch';
Applied upstream.
- Add 'install-only-distributed-binaries-manuals' patch.
- Add 'revert-GifQuantizeBuffer-remove-from-lib' patch.
  * d/rules
- Don't force the rebuilding of manpages, the clean rule does the job.
- Remove the txt docs from giflib-tools; Not distributed.
- Remove 'dh_strip --dbgsym-migration'; Not needed anymore.
- Set DPKG_GENSYMBOLS_CHECK_LEVEL to 4.
  * giflib-tools.manpages: point to the correct ones.
  * d/control:
- Add 'Rules-Requires-Root' field.
- Update Standars version; no changes needed.
- Change VCS URL's.
  * d/libgif7.symbols:
- Add 'Build-Depends-Package' field.
- Update symbols.
  * d/copyright:
- Remove 'doc/gif87.txt'; Nows not distributed.
- Add myself on debian/* files.
- Add 'upstream-{Name,Contact}'.
  * Wrap and sort.
  * Add upstream metadata.
  * Add lintian overrides for some giflib-tools manpages.
  * Add lintian source override for sourceforge redirector.
  * Drop libgif7.shlibs; not needed.



The package is not in latest upstream because is currently in a process 
of removing a symbol, in the main library, that breaks some dependent 
packages (exactimage, mplayer-gui, mplayer, qutemol and xplanet).


The current version just patch the library to revert the symbol remove, 
to allow the upload without breaking anything (it fixes a pair of CVE's).


The next upload (the last upstream version) will go to experimental, 
trying to ask upstream to install a missing library (libutil.so) that 
contains the moved symbol (I will ask upstream to rename the library to 
something more suitable, like libgifutil or so).


In the meanwhile there are some bugs open on each package to adapt to 
the new upstream changes (currently we have the latest version on 
experimental), so they get informed about the changes of the next 
experimental upload when upstream gets the ABI stable.


Regards,

--

  David

Bug#946416: gtkmm2.4: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: gtkmm2.4
Version: 1:2.24.5-4
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The gtkmm2.4 tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gtkmm2.4-2.24.5/debian/tests/build gtkmm2.4-2.24.5/debian/tests/build
--- gtkmm2.4-2.24.5/debian/tests/build  2019-02-06 00:54:15.0 -0800
+++ gtkmm2.4-2.24.5/debian/tests/build  2019-12-08 11:38:31.0 -0800
@@ -23,6 +23,12 @@
 
 cd "$WORKDIR"
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < gtktest.cc
 #include 
 
@@ -60,9 +66,9 @@
 }
 EOF
 
-g++ -o pixbuf-demo pixbuf-demo.cc `pkg-config --cflags --libs gtkmm-2.4`
-g++ -o gtk-demo/gtk-demo gtk-demo/*.cc -DHAVE_GETC_UNLOCKED 
-DDEMOCODEDIR=\"${WORKDIR}\" `pkg-config --cflags --libs gtkmm-2.4`
-g++ -o gtktest gtktest.cc `pkg-config --cflags --libs gtkmm-2.4`
+${CROSS_COMPILE}g++ -o pixbuf-demo pixbuf-demo.cc `${CROSS_COMPILE}pkg-config 
--cflags --libs gtkmm-2.4`
+${CROSS_COMPILE}g++ -o gtk-demo/gtk-demo gtk-demo/*.cc -DHAVE_GETC_UNLOCKED 
-DDEMOCODEDIR=\"${WORKDIR}\" `${CROSS_COMPILE}pkg-config --cflags --libs 
gtkmm-2.4`
+${CROSS_COMPILE}g++ -o gtktest gtktest.cc `${CROSS_COMPILE}pkg-config --cflags 
--libs gtkmm-2.4`
 echo "build: OK"
 [ -x gtktest ]
 xvfb-run -a -s "-screen 0 1024x768x24" \

Bug#945925: buster-pu: package gnutls28/3.6.7-4+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2019-12-01 at 07:27 +0100, Andreas Metzler wrote:
> I would like to see #933538 fixed in buster, which is a
> interoperability problem with old (2.x, that is wheezy) versions of
> gnutls.

Please go ahead.

Regards,

Adam

Bug#934753: dropbear-initramfs: please add an autopkgtest

[Guilhem Moulin]

Hi josch,

On Wed, 20 Nov 2019 at 11:21:31 +0100, Johannes Schauer wrote:
> Indeed it would not. The autopkgtest does not even test upgrades. But when I
> re-installed the system after the upgrade failed I also was unsure in many
> points of how to do it correctly. The autopkgtest does not only serve as a
> constant assurance that the current state does work but also serves as
> documentation of which knobs have to be turned to successfully set it up. It
> can thus serve as an addition to
> /usr/share/doc/dropbear-initramfs/README.Debian

Fair enough :-)

>> I'd also bind to INADDR_LOOPBACK, change the NIC and drive model from the
>> default (resp. e1000 and ide) to virtio, and pass `-no-user-config
>> -nodefaults`.  Maybe also set the CPU model to host.  Might also help to
>> create a virtio-rng device, given that key material is generated on the
>> guest.
> 
> I'm unsure about -no-user-config -nodefaults. This will require a much larger
> command line for what benefit?

For ‘-nodefaults’ it might be reasonable to assume that the qemu
maintainers make sure to have sane default that don't break on upgrade,
however ‘-no-user-config’ shouldn't require a larger command line and will
be really useful for those who run the pkgtest in unclean environments.
(One could have tons of stuff there, including extra disks, different
boot priorities, etc. and shoot oneself in the foot.)
 
> What benefit would changing the nic and drive to virtio have? Sorry, I'm not 
> an
> expert on this. :)

I guess QEMU defaults to “full virtualization” (incl. hardware
emulation) because not all guest OS are VirtIO-aware.  When the guest OS
can speak VirtIO it makes little sense to emulate a particular hardware.
That said saving the abstraction cost won't give a huge perf gain here
because there is not much I/O.  Another advantage is the reliable block
device paths (/dev/vda for the first drive), while otherwise that
depends on the bus (SATA, IDE) and driver in use.
 
> Yes, adding something like this might be useful:
> 
> -object rng-random,filename=/dev/urandom,id=rng0 -device 
> virtio-rng-pci,rng=rng0
> 
> I'll benchmark this to see whether there is a noticeable difference.

That's a hard requirement when the guest calls getrandom(,,GRND_RANDOM)
or reads from the blocking PRNG.  dropbear(8) doesn't *right now*, but
other components in the software stack do and on headless VMs there is a
real risk of entropy starvation without virtual hardware RNG (cf. last
year's “Handling of entropy during boot” thread on debian-devel.)

>>> printf myinsecurepassphrase | cryptsetup luksFormat /dev/sdb3 -
>> To speep up things I suggest to skip the the PBKDF benchmark by passing
>> `--pbkdf-force-iterations 4 --pbkdf-memory 32` (for Argon2), or
>> `--pbkdf-force-iterations 1000` (for PBKDF2).  cryptsetup <2.0 (up to
>> Stretch) are only able to format and open LUKSv1 volumes, which only
>> supports PBKDF2 as PBKDF algorithm; since cryptsetup 2.0 a new LUKS
>> version format is available (and is the default as for Buster) with
>> support for both Argon2i/d (default) and PBKDF2.
> 
> Is this only for a potential speedup? Is it not better to test the default
> setup?

PBKDF are by design expensive functions; when a new keyslot is added, a
benchmark is run to choose parameters that are 1/ expensive enough to
defeat bruteforce attacks, and 2/ reasonable enough to avoid waiting too
long for the device to unlock.  When `luksFormat` and `luksOpen` are
called from machines with different clock speed and/or RAM size, the
benchmark is just moot; and when the former machine is much more beefy
than the latter, which is likely the case here (though maybe not in the
CI pipeline), unlocking might take a lng time, or even trigger the
OOM killer and cause the test to fail.  With my cryptsetup maintainer
hat on, the general recommendation when `luksFormat` and `luksOpen` are
called from different machines, is to collect parameters on the latter
machine, and use them when creating the keyslot.  For a test though it
makes sense to skip the benchmark altogether and PBKDF parameters that
are as cheap as possible, to avoid wasting RAM and CPU cycles.  FWIW
this is also what I do in the tests for cryptsetup-initramfs (which I
mean to turn into autopkgtests as well). :-)

Thanks!
Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#946083: buster-pu: package opensmtpd/6.0.3p1-5

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2019-12-03 at 14:57 -0500, Ryan Kavanagh wrote:
> 1) opensmtpd's "sendmail" implementation cannot enqueue mail offline
> unless the "smtpctl" binary is installed setgid opensmtpdq. This has
> been fixed in unstable.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945910
> 
> 2) We should warn users of changes to the config file syntax when
> they
> upgrade from stretch to buster. The binary package in unstable
> already
> does this, albeit with different wording.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944268
> 

Why is the dpkg-statoverride call using --force-all? It should only be
executing if no existing override exists, unless I'm missing something.

Regards,

Adam

Bug#944771: GNOME Shell crashes when selecting "About" from top bar menu in Midori

[Andrew Engelbrecht]

On 12/8/19 2:42 PM, Bernhard Übelacker wrote:
> Hello Andrew,
> I tried to reproduce this crash but it did not show up for me.
> 
> Maybe you could install systemd-coredump, then a backtrace
> would be written automatically into the journal:
> 
> journalctl --no-pager

Hello Bernhard,

I was able to reproduce and to get a backtrace, which I attached to this
email.

I tried clearing out the ~/.config/midori/ directory. After doing so, I
no longer get a crash when selecting the "About" menu option.

If needed, I can try to recover the bad config from backups, for the
sake of testing future versions of Midori and GNOME Shell.

Thanks, : )
Andrew
Dec 08 15:07:06 sol systemd-coredump[2306]: Process 1354 (gnome-shell) of user 
1000 dumped core.

Stack trace of thread 1354:
#0  0x7f3a842cc9a7 
gtk_action_observer_action_removed (libgnome-shell-menu.so)
#1  0x7f3a842cb206 n/a 
(libgnome-shell-menu.so)
#2  0x7f3a842cb26f n/a 
(libgnome-shell-menu.so)
#3  0x7f3a842cbce0 
gtk_action_muxer_remove (libgnome-shell-menu.so)
#4  0x7f3a842cbd28 
gtk_action_muxer_insert (libgnome-shell-menu.so)
#5  0x7f3a853ac8a4 
shell_app_update_window_actions (libgnome-shell.so)
#6  0x7f3a853bbaee n/a 
(libgnome-shell.so)
#7  0x7f3a8516ac8d 
g_closure_invoke (libgobject-2.0.so.0)
#8  0x7f3a8517e365 n/a 
(libgobject-2.0.so.0)
#9  0x7f3a851872be 
g_signal_emit_valist (libgobject-2.0.so.0)
#10 0x7f3a8518797f 
g_signal_emit (libgobject-2.0.so.0)
#11 0x7f3a8516f364 n/a 
(libgobject-2.0.so.0)
#12 0x7f3a85171921 
g_object_notify_by_pspec (libgobject-2.0.so.0)
#13 0x7f3a832a38ee 
ffi_call_unix64 (libffi.so.6)
#14 0x7f3a832a32bf ffi_call 
(libffi.so.6)
#15 0x7f3a8184ab2d n/a 
(libwayland-server.so.0)
#16 0x7f3a818475a9 n/a 
(libwayland-server.so.0)
#17 0x7f3a81848b72 
wl_event_loop_dispatch (libwayland-server.so.0)
#18 0x7f3a845a43a7 n/a 
(libmutter-3.so.0)
#19 0x7f3a85088f2e 
g_main_context_dispatch (libglib-2.0.so.0)
#20 0x7f3a850891c8 n/a 
(libglib-2.0.so.0)
#21 0x7f3a850894c2 
g_main_loop_run (libglib-2.0.so.0)
#22 0x7f3a8456b06c meta_run 
(libmutter-3.so.0)
#23 0x5585b23dc782 n/a 
(gnome-shell)
#24 0x7f3a842f809b 
__libc_start_main (libc.so.6)
#25 0x5585b23dc8da n/a 
(gnome-shell)

Stack trace of thread 1356:
#0  0x7f3a843c2819 __poll 
(libc.so.6)
#1  0x7f3a85089136 n/a 
(libglib-2.0.so.0)
#2  0x7f3a8508925c 
g_main_context_iteration (libglib-2.0.so.0)
#3  0x7f3a850892a1 n/a 
(libglib-2.0.so.0)
#4  0x7f3a850b1415 n/a 
(libglib-2.0.so.0)
#5  0x7f3a8449cfa3 start_thread 
(libpthread.so.0)
#6  0x7f3a843cd4cf __clone 
(libc.so.6)

Stack trace of thread 1357:
#0  0x7f3a843c2819 __poll 
(libc.so.6)
#1  0x7f3a85089136 n/a 
(libglib-2.0.so.0)
#2  0x7f3a850894c2 
g_main_loop_run (libglib-2.0.so.0)
#3  0x7f3a852b5266 n/a 
(libgio-2.0.so.0)
#4  0x7f3a850b1415 n/a 
(libglib-2.0.so.0)
#5  0x7f3a8449cfa3 start_thread 
(libpthread.so.0)
 

Bug#946185: stretch-pu: package fig2dev/1:3.2.6a-2+deb9u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-12-04 at 22:52 +0100, Roland Rosenfeld wrote:
> This fixes CVE-2019-19555 in stretch.  Since this is tagged
> "unimportant" by the security team on
> https://security-tracker.debian.org/tracker/CVE-2019-19555 they won't
> publish a DSA, so I tend to send this into the next point release of
> buster.

s/buster/stretch/ ;-)

Please go ahead.

Regards,

Adam

Bug#946415: rust-cargo Build-Depends on librust-crates-io-0.25+default-dev which doesn't exist

[Paul Gevers]

Source: rust-cargo
Version: 0.37.0-1
Severity: serious
Tags: ftbfs sid bullseye
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainers,

Your package Build-Depends on librust-crates-io-0.25+default-dev but that
package doesn't exist.

Paul

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl3tXnsACgkQnFyZ6wW9
dQrJEAgArOfLFxtWX9VX9pCwEY7IANOd7+n2fzBHBSEpydXsryT3WxJGhYihrzrY
+XFKFSoKqNMzuEhR9hyKsjLfiCIn8QiEhrftdGEXHWaHvWHw9VU/f+FCCFfDl3n9
Hho655KiAIoQbOI1tuosN/q9bY0CV+zQOb5z17eAEIt0Aj3V0++uQIV5pJk96yU5
+0FZptGyLVv1waGJ3gaBIK1E2bi0XZyO43LnF93BpH6l1c4FeD4dWetTe/IdvD8N
itjowp1e7KiOCxiZCRk4BSU4d6xkeKOMCMQrUdtBN5ZfBXgJRGQaBG69ck5TG5js
YTtiQEp4fy4/jglgEmkIoazcvLUNnA==
=pbb/
-END PGP SIGNATURE-

Bug#946184: buster-pu: package fig2dev/1:3.2.7a-5+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-12-04 at 23:17 +0100, Roland Rosenfeld wrote:
> Hi Adam!
> 
> On Mi, 04 Dez 2019, Adam D. Barratt wrote:
> 
> > Control: tags -1 + moreinfo
> > 
> > On Wed, 2019-12-04 at 22:50 +0100, Roland Rosenfeld wrote:
> > > This fixes CVE-2019-19555 in buster.  Since this is tagged
> > > "unimportant" by the security team on
> > > https://security-tracker.debian.org/tracker/CVE-2019-19555 they
> > > won't
> > > publish a DSA, so I tend to send this into the next point release
> > > of
> > > buster.
> > The Security Tracker and BTS suggest this issue is not yet resolved
> > in
> > unstable - is that correct?
> 
> Seems, that the systems are slower than me today :-)
> According to 
> https://tracker.debian.org/news/1084412/accepted-fig2dev-1327b-2-source-into-unstable/
> the upload to unstable proceeded.
> 
> But it seems that I have a typo (brace at wrong position) in the
> changelog, so the bug was not closed :-(
> I'll just send out a closing mail by hand and will fix the wrong
> brace in the patches against buster and stretch soon.

Thanks. Please go ahead, with the changelog fixed as above.

Regards,

Adam

Bug#946414: superfluous insertions of "include /usr/share/dpkg/architecture.mk"

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.44
Severity: normal

lintian-brush is unnecessarily adding includes of 
/usr/share/dpkg/architecture.mk in some cases.

See e.g. 
https://salsa.debian.org/a11y-team/emacspeak/merge_requests/2/diffs#8756c63497c8dc39f7773438edf53b220c773f67_7_7

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-3
ii  python3-breezy   3.0.2-1
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.14-1
ii  python3-levenshtein  0.12.0-3+b2
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.2
ii  lintian2.40.0
ii  python3-asyncpg0.20.0-1
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  210

-- no debconf information

Bug#946413: lintian-brush: Some thoughts on fixers for debian/upstream/metadata

[gregor herrmann]

Package: lintian-brush
Version: 0.44
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Going throught the merge requests for perl packages, I noticed some
issues around the handling of debian/upstream/metadata:

- - The perl YAML libraries we use add "---\n" at the top of the file,
  which the used Python libraries in lintian-brush apparently don't
  do. No idea what is more correct or if it matters at all; I just
  noted that the removal of the line adds some noise.
- - Sometimes when Contact and Name are removed, all that's left in our
  files is "Archive: CPAN" which is no so helpful. In those cases I
  just removed debian/upstream/metadata completely. Not sure if lintian-brush
  should do the same or if I should stop removing it or something
  else :)
- - Similarly, if lintian-brush creates debian/upstream/metadata for a
  perl package, it might add "Archive: CPAN" (not that we use it but
  the Archive field exists …).
- - The URLs lintian-brush finds in META.{json,yml} sometimes have room
  for improvement; in our tools [0] we e.g. fix github URLs to use
  https etc. It would be nice if lintian-brush could also learn some
  of these tricks.


Cheers,
gregor


[0]
https://salsa.debian.org/perl-team/modules/packages/dh-make-perl/blob/master/lib/DhMakePerl/Command/Packaging.pm#L1636
https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/blob/master/scripts/debian-upstream#L30

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl3tWFlfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgb7YBAArhND3dDmqw1vIQx5D3DvWMGc4XtZktsxH3CWpbm0oQvO0ijAs2MkuaJz
NH+5uXYcUB6tDmfCzg7stKdvADAMY4tYNeH5BwijwobIW/Ar5sZ6sliA+IDtQhgl
fOSGGEbECSrLLpZXqVBd/xzF4sj1V9pe5fkRIuOp5LWoTyn3iw/sIpKhvo4uk/De
xeXc81NCj4Bk1gx0eBg8PMT/86aoKq5vWU1rkgqJY3xwtzQ7Wb273iXp9MZmejFu
PohUXSJO/qWW5rNnNnH/X5wZzqIz5L5feU6SqbBsbXCvWpziJ0fC41S1RP0cR3wB
fuH/XNGpIQl2y9tqmwPFnoJwiw+tjMx1gHM3Yu/yrrsB58r74kOzk2+lw+psQoU3
YCUAfMIAUYc5kOcHyKlN9YXKh9sGUTkdUKegmf/llVXLBewH1efyX391qNTJ/g7o
fB87kLF457jRGA7aR5rOY7wnj7JiIf6B1Djk1+5UN9QwnJixvbkEbdq+962SCQ1X
a4tNPxXQzi/jLyO6TPGcKcnQK6YngPstou7A0ChG44Q0LGq2vbC03Fa0hnKEeEeo
klPwBnhF522h6ZajkfzXnXvX+bMOvz8iB9fFREPfrGIXMkSmv011hsKSMAw7GCg4
9dlNllbSksvYOzJI85n4ZcyqVMSHIXswvYrJZ9kLO3zjwGdwxiE=
=UBaC
-END PGP SIGNATURE-

Bug#946412: janus-gateway: upstream does not support stable releases

[Jonas Smedegaard]

Package: janus-gateway
Version: 0
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream releases are to be considered draft snapshots,
and this package is therefore unsuitable for inclusion
in long-term distributions like Debian stable.

This bug should be bumped to release-critical state
close to or after entering freeze -
but not before so as to ease use for users tracking testing
including derivatives based on Debian testing.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl3s9fMACgkQLHwxRsGg
ASGvjA/8CRZ0Edug2xfXO0fdY84m9NazG24GXo5KtAsKefgUtKSJkBaIT0eyajDg
fFpMNQ14F1oJIc7ngFtfUQ05R2xBN/+H8cnOq51zoh6WARdXYtM1UE8SojFYM95p
ft9WcEmlcBX3K3tmHQT+aVjxvqRkyyaL22JPzQO/E+0xeQm+NU1w8zr4SX9dxPdl
GDG9w/d1EhP9iEV/kZdcVVphiEt8KqUKdgLLA17/l53nXOXPIU2PXbL3PpLSj/PP
TpfZdPr85Ry6PnS9n5CWx9TvbCG9LjptdfTnL/qVdY3QAMCgw+zLkL1zISkMOo4P
BclXe4iPdthQC8wwE7OYNyCAVHOvbkQqSB6ybMK44uJe10IY2wzwt+nry/1dljhR
hZYXRBmJT85UGL9/e+7EKh7J4vACRwtdOomD25iH8jXc9mg48buzlzSZojxypA14
LPjhiCB5UDdNSGFCS+Hq82UcB7CgJrsL0DNVLfJxs4RCklMmkos8OBQUwWYG3lcA
yTUxEnJ48lpGJ4dxo9/pV520GWutHtYzsLXOr6zV2/9qNp+4OpAOAoPfXQeKsjY4
3oa0i+/ogKy9Kbzvi1Vw/kw2a+JRMyVbvGeN7pA86Or8tcG56qA+E5s8myoHHpNZ
TQ2HbHvU8drVdvu+Et3kJhV1IJmw5VMSjYleJuGPACIp1HTDS88=
=k5KT
-END PGP SIGNATURE-

Bug#926128: u-boot-menu: should stop with error if failing

[Jonas Smedegaard]

Hi Diego,

Thanks a lot for your many suggestions!

I split your reported suggestions into separate issues, and believe most 
are now fixed except this one:

> Also, the script should stop with a error message, if a file or a 
> directory is not found, so it will not create a invalid configuration 
> file.

Do you agree that above is now the only open issue left?

If you want, then it is helpful if you could propose a patch for this 
issue.


You are quite welcome to continue to report issues - with or without 
patches.  Best if you file each issue separately, however: It is easier 
and less confusing to later merge issues than to split them up.

Kind regards,

 - 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#946268: Please add support for custom entries

[Jonas Smedegaard]

Quoting andreimpope...@gmail.com (2019-12-08 11:10:25)
> On Vi, 06 dec 19, 15:17:37, Jonas Smedegaard wrote:
> > Hi Andrei,
> > 
> > Quoting Andrei POPESCU (2019-12-06 14:45:11)
> > > Currently any changes done to /boot/extlinux/extlinux.conf will be 
> > > overwritten on the next kernel update.
> > > 
> > > It would be nice to have some mechanism to include custom entries. 
> > > In my case I need an entry with a different root partition (to 
> > > boot a different install).
> > > 
> > > One idea would be to have a U_BOOT_CUSTOM configuration variable 
> > > to specify a file to be included as is.
> > > 
> > > If you think the idea is good I might be able to come up with a 
> > > patch for it.
> > 
> > I like the idea, and welcome a draft patch!
> 
> Ok, attached a patch against u-boot-menu on Salsa/debian implementing 
> this.
> 
> Comments welcome :)

Please share the patch as attachment here instead.

Thanks,

 - 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#944771: GNOME Shell crashes when selecting "About" from top bar menu in Midori

[Bernhard Übelacker]

Hello Andrew,
I tried to reproduce this crash but it did not show up for me.

Maybe you could install systemd-coredump, then a backtrace
would be written automatically into the journal:

journalctl --no-pager

Kind regards,
Bernhard

Bug#944856: buster-pu: package qtbase-opensource-src/5.11.3+dfsg1-1+deb10u2

[Adam D. Barratt]

On Sun, 2019-12-08 at 10:52 +0300, Dmitry Shachnev wrote:
> On Sat, Dec 07, 2019 at 07:35:27PM +, Adam D. Barratt wrote:
> > Hmmm. Is the BTS metadata for #935627 accurate? The final entry in
> > the
> > log is currently a "pending" tag from August, but no bug closure,
> > and
> > the fix doesn't appear to be mentioned in the current git
> > changelog.
> 
> That bug was filed when Qt 5.12 was already available in
> experimental, and the first line of it says “Qt5 < 5.12 have a rather
> nasty bug […]”.
> 
> The relevant upstream patch [1] was merged in v5.12.0-beta1 already.
> So I'm adjusting the metadata to show that it is fixed in 5.12. Hope
> it's better now.
> 
> I don't want to close it because the fix in testing / 5.12 is not
> what the reporter wanted. So I would prefer to let it be closed by
> buster upload.
> 
> [1]: https://codereview.qt-project.org/c/qt/qtbase/+/239918

I'm not entirely convinced by the distinction, but OK. :-) Thanks for
the update.

Regards,

Adam

Bug#946411: Please put pydantic to salsa

[Ole Streicher]

Source: pydantic
Version: 0.30.1-1
Severity: wishlist

Dear Maintainer,

Specifically for LowNMU it may be useful to have a git repository to
keep the changes of pdantic. Therefore, I would ask you whether you
would agree to create a git repository on Salsa (in the Python group)
and to put it there. I would volunteer to do this if you agree.

Best regards

Ole

Bug#946410: O: libtap-formatter-junit-perl -- Perl module for converting TAP output to JUnit XML output

[Peter Eisentraut]

Package: wnpp
Severity: normal

This was once useful for use with Jenkins, before Jenkins had a plugin 
for TAP results.  Nowadays, I think it's obsolete.  Perhaps it should be 
removed.

Bug#946409: Please update pydantic to a newer version

[Ole Streicher]

Source: pydantic
Version: 0.30.1-1
Severity: wishlist

Dear Maintainer,

Pydantic is currently version 0.3, while 1.2 is already available. Also,
the package does not migrate because it is still the first (source-only)
upload.

python3-pydantic is now a new build dependency of the "gammapy" package,
that I would like to upload soon. Would it be possible to update to the
current version?

As the package is on LowNMU, I would volunteer to upload the latest
version as an NMU myself (also including the patch #940156).

Best regards

Ole

Bug#941198: In support of mandatory unit files

[Russ Allbery]

Tobias Frost  writes:
> Am Samstag, den 07.12.2019, 17:12 -0800 schrieb Russ Allbery:

>> A Policy should means that if there is some stronger reason (such as
>> that adding a unit file would introduce new bugs), there is nothing
>> requiring you to do so.  It indicates that not having a unit file is a
>> bug, but it's just a bug, and Debian packages are not expected to be
>> bug- free.  Other bugs may be more important.

> Well, I was responding to a mail that suggested to make unit files
> mandatory (which I read as then RC-buggy) and suggesting some lines
> later to drop support for the sysv-generator and in this case it is
> quite moot that policy can be ignored because I fear that once unit
> files would become mandatory that would be used as an argument to drop
> support for the generator.

Just to be clear, that's not what this bug proposes.  This bug just
proposes making systemd unit files recommended.

> Sure, help fir that would be nice. Thanks for the offer.  (Probably
> should have an own bug for that.) Nethertheless, this is the line that
> causes my problems and needs to be transferred:
> https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8

Ah, I see, the problem is the $(hostname) part, which isn't supported by
EnvironmentFile in systemd (which is the normal way to solve this
problem).

After looking at this for a bit, my inclination if I were you would be to
write a tiny shell script that loads /etc/default/gmediarender, constructs
the command line, and then execs the daemon; install that script as
/usr/share/gmediarender/start; and then invoke that script via
start-stop-daemon in the init script and via ExecStart in the systemd unit
file.  It's a little bit overkill because most of what the /etc/default
file is doing is simple, but it looks like the easiest way to handle
$(hostname).

-- 
Russ Allbery (r...@debian.org)  

Bug#941198: In support of mandatory unit files

[Simon Richter]

Hi,

On 08.12.19 09:54, Tobias Frost wrote:

> Well, I was responding to a mail that suggested to make unit files
> mandatory (which I read as then RC-buggy) and suggesting some lines
> later to drop support for the sysv-generator and in this case it is
> quite moot that policy can be ignored because I fear that once
> unit files would become mandatory that would be used as an argument to
> drop support for the generator.

The generator that makes the init scripts usable for systemd generates a
unit that calls the init script. It should be possible to just do the
same thing and build a unit file that calls the init script. That would
be fully allowed when unit files are mandatory.

   Simon



signature.asc
Description: OpenPGP digital signature

Bug#946104: autopkgtest fails with "Failed to retrieve max realtime priority: Input/output error"

[Felipe Sateler]

Control: tags -1 moreinfo

Hi Michael,

On Tue, Dec 3, 2019 at 5:45 PM Michael Biebl  wrote:

> Source: rtkit
> Version: 0.12-4
> Severity: normal
>
> Hi Felipe,
>
> today I was investigating why an update of systemd (v244) was blocked by
> a failing autopkgtest in rtkit from testing migration.
>
> When trying to investigate the issue, I could reproduce the failure with
> both systemd v243 and v244 locally. So I assume it's the rtkit
> autopkgtest which is flaky since [1] shows autopkgtest passing.
> I've attached logs for both sid and bullseye.
> The tests are run on Debian sid.
>

I can't reproduce the failures. How are you running the tests?


-- 

Saludos,
Felipe Sateler

Bug#946408: python3-mysqldb: suggests python-egenix-mxdatetime

[Matthias Urlichs]

Package: python3-mysqldb
Version: 1.3.10-2
Severity: minor

The suggestion from $SUBJECT does not make sense.

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable'), (550, 'experimental'), (550, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3-mysqldb depends on:
ii  libc62.29-3
ii  libmariadb3  1:10.3.18-0+deb10u1
ii  libssl1.11.1.1d-0+deb10u2
ii  python3  3.7.3-1
ii  zlib1g   1:1.2.11.dfsg-1

python3-mysqldb recommends no packages.

Versions of packages python3-mysqldb suggests:
pn  default-mysql-server | virtual-mysql-server  
pn  python-egenix-mxdatetime 
pn  python3-mysqldb-dbg  

-- no debconf information

Bug#946407: don't remove expired keys from upstream signing key

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.44
Severity: normal

These could still be used to e.g. verify older upstream releases.

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-3
ii  python3-breezy   3.0.2-1
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.14-1
ii  python3-levenshtein  0.12.0-3+b2
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.2
ii  lintian2.40.0
ii  python3-asyncpg0.20.0-1
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  210

-- no debconf information

Bug#944417: transition: cgal

[Sebastiaan Couwenberg]

On 12/8/19 7:15 PM, Joachim Reichel wrote:
> openemsbinNMU would be sufficient, unrelated FTBFS
>(#946264), but not on autoremoval list (WHY?)

RC bug report is too young.

"
 Packages which have RC bugs that are present in both testing and
 unstable, and which have no recent activity (currently this means no
 activity in the last 14 days) will be checked for removal.
"

https://lists.debian.org/debian-devel-announce/2013/09/msg6.html

Kind Regards,

Bas

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

Bug#946406: lsb-base: Please add back fancy output support

[Guillem Jover]

Package: lsb-base
Version: 11.1.0
Severity: wishlist

Hi!

The fancy output support got completely removed some time ago, and I
guess I had forgotten I had read the changelog, and kept wondering
what had broken on an unstable system compared to a stable one.

In #670144 it is argued that this was a problem due to parallel
execution, but that would affect non-fancy output too, with
"line...(ok|failed)" style of output. So if this needs fixing it
needs to be fixed in a way that is correct for both modes anyway.

The problem with long output I guess is real, but can arguably be
considered a bug in the init script. The problem with intermixed
output on failures/warnings I guess can also be argued to be a bug,
as that should be trapped and output in a controlled way.

I'd appreciate if the code could be reintroduced, even if not enabled
by default (by providing a variable setting or similar).

Thanks,
Guillem

Bug#946405: nextcloud-desktop: Nextcloud desktop client crash when trying to enter login/password

[Ludovic]

Package: nextcloud-desktop
Version: 2.5.1-3+deb10u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When I start nextcloud-desktop, at the second screen, I can fill the
form with my login and password. But, when I want to validate it, the
nextcloud client crashes.

Here is the traceback:

 Received signal 11 SEGV_MAPERR 0008
 #0 0x7fe16d9b6bde 
 #1 0x7fe16d9b6cf0 
 #2 0x7fe16d9b7327 
 #3 0x7fe166ea4840 
 #4 0x7fe152142a8c 
 #5 0x7fe152142c87 
 #6 0x7fe152142f83 
 #7 0x7fe1523cf490 
 #8 0x7fe1523cf4e0 
 #9 0x7fe166a5f156 
 #10 0x7fe166a5f2b6 
 #11 0x7fe1675e509b QObject::event()
 #12 0x7fe167f7496b QWidget::event()
 #13 0x7fe166a62e5d QQuickWidget::event()
 #14 0x7fe17207cb50 
 #15 0x7fe167f364c1 QApplicationPrivate::notify_helper()
 #16 0x7fe167f3d970 QApplication::notify()
 #17 0x7fe1675bb4f9 QCoreApplication::notifyInternal2()
 #18 0x7fe16760bba8 QTimerInfoList::activateTimers()
 #19 0x7fe16760c404 
 #20 0x7fe166ab9f2e g_main_context_dispatch
 #21 0x7fe166aba1c8 
 #22 0x7fe166aba25c g_main_context_iteration
 #23 0x7fe16760c797 QEventDispatcherGlib::processEvents()
 #24 0x7fe15a477401 
 #25 0x7fe1675ba1cb QEventLoop::exec()
 #26 0x7fe1675c21a2 QCoreApplication::exec()
 #27 0x55a62d7e01ac main
 #28 0x7fe166e9109b __libc_start_main
 #29 0x55a62d7e066a _start
   r8: 7fe15415a470  r9: 7fe15415a400 r10: 0007 r11: 
0206
  r12: 55a62ef83cf0 r13: 55a62e9e9800 r14:  r15: 

   di: 7fe15416efc0  si: 7fe15415a500  bp: 55a62ef83cf0  bx: 
55a62ef83cf0
   dx:   ax: 55a62ef83cf0  cx: 7fe15415a500  sp: 
7ffd8d0fc950
   ip: 7fe152142a8c efl: 00010206 cgf: 002b0033 erf: 
0006
  trp: 000e msk:  cr2: 0008
 [end of stack trace]
 Calling _exit(1). Core file will not be generated.

Thanks for your help.

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

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

Versions of packages nextcloud-desktop depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libnextcloudsync0 2.5.1-3+deb10u1
ii  libqt5concurrent5 5.11.3+dfsg1-1+deb10u1
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u1
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u1
ii  libqt5gui55.11.3+dfsg1-1+deb10u1
ii  libqt5keychain1   0.9.1-2
ii  libqt5network55.11.3+dfsg1-1+deb10u1
ii  libqt5positioning55.11.3+dfsg-2
ii  libqt5printsupport5   5.11.3+dfsg1-1+deb10u1
ii  libqt5qml55.11.3-4
ii  libqt5quick5  5.11.3-4
ii  libqt5sql5-sqlite 5.11.3+dfsg1-1+deb10u1
ii  libqt5webchannel5 5.11.3-2
ii  libqt5webenginecore5  5.11.3+dfsg-2+b1
ii  libqt5webenginewidgets5   5.11.3+dfsg-2+b1
ii  libqt5webkit5 5.212.0~alpha2-21
ii  libqt5widgets55.11.3+dfsg1-1+deb10u1
ii  libqt5xml55.11.3+dfsg1-1+deb10u1
ii  libsqlite3-0  3.27.2-3
ii  libssl1.1 1.1.1d-0+deb10u2
ii  libstdc++68.3.0-6
ii  nextcloud-desktop-common  2.5.1-3+deb10u1
ii  nextcloud-desktop-l10n2.5.1-3+deb10u1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  2.5.1-3+deb10u1

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#943397: runit: Add a finish-default

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-35
Followup-For: Bug #943397

Dmitry Bogatov  wrote:

> Can you please elaborate on this case? How could runsv(1) know whether
> "run" file was read or not?

I've probably put in a way that is misleading: I don't know how/if runsv
knows whether run file was read.
You can reproduce the -1 exit code by moving away the meta file in
/usr/share/runit/meta/${service}/installed
for any service that has runit support already merged.
My guess is that this holds true for any case where invoke-run exits,
like in "noreplace", but I've not tested.

[ updated patches attached ]

Lorenzo


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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: 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: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.29-5
ii  sysuser-helper  1.3.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-35

runit suggests no packages.

-- Configuration Files:
/etc/default/runit changed [not included]
/etc/runit/3 changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/runit/invoke-run (from runit package)
debsums: changed file /sbin/update-service (from runit package)
>From d59f3dd0c5d6ff5fe005bc13bd09da1e3df4686f Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Mon, 4 Nov 2019 19:48:37 +0100
Subject: [PATCH 1/2] Add finish-default

Add a finish-default file to be sourced from finish scripts

Closes: #943397
---
 debian/contrib/lib/finish-default | 34 +++
 debian/runit.install  |  1 +
 2 files changed, 35 insertions(+)
 create mode 100755 debian/contrib/lib/finish-default

diff --git a/debian/contrib/lib/finish-default 
b/debian/contrib/lib/finish-default
new file mode 100755
index 000..5cabbe4
--- /dev/null
+++ b/debian/contrib/lib/finish-default
@@ -0,0 +1,34 @@
+#!/bin/echo this script must be sourced, not executed.
+set -e
+
+. /etc/default/runit
+NAME=${PWD##*/}
+
+if [ "${VERBOSE:-0}" != 0 ] ; then
+   trap "echo runsv: $NAME stopped" EXIT
+fi
+
+case $1 in
+(-1)
+   echo "runsv: ERROR $1 in $NAME: runscript didn't exit normally"
+   # no need to sv d service here, runsv will stop trying after the first 
attempt
+   ;;
+
+(161)
+   echo "runsv: WARNING for $NAME: disabled by local settings"
+   sv d $NAME
+   exit 0
+   ;;
+
+(162)
+   echo "runsv: ERROR $1 in $NAME: configtest or early setup failed"
+   sv d $NAME
+   exit 0
+   ;;
+
+(170)
+   echo "runsv: ERROR $1 in $NAME: a runtime hard dependecy is missing"
+   sv d $NAME
+   exit 0
+   ;;
+esac
diff --git a/debian/runit.install b/debian/runit.install
index 40a9466..78b1307 100644
--- a/debian/runit.install
+++ b/debian/runit.install
@@ -22,4 +22,5 @@ debian/contrib/shutdown /lib/runit
 debian/contrib/runlevel /lib/runit
 debian/sulogin/run  /etc/runit/runsvdir/single/sulogin
 debian/contrib/lib/async-timeout/lib/runit
+debian/contrib/lib/finish-default/lib/runit
 debian/contrib/lib/run_sysv_scripts /lib/runit
-- 
2.24.0

>From 3338c1c72043e6062fc637bd99ee4a4fb738da36 Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Tue, 5 Nov 2019 23:49:58 +0100
Subject: [PATCH 2/2] Update invoke-run manpage for finish-default

Update invoke-run manpage to account for finish-default file and
special error codes.
---
 debian/contrib/man/invoke-run.5 | 88 +
 1 file changed, 88 insertions(+)

diff --git a/debian/contrib/man/invoke-run.5 b/debian/contrib/man/invoke-run.5
index 51b06a5..80d38d0 100644
--- a/debian/contrib/man/invoke-run.5
+++ b/debian/contrib/man/invoke-run.5
@@ -77,6 +77,94 @@ If both
 file and
 .BI "/etc/sv/" foo "/conf"
 directory define some variable, value from directory takes precedence.
+.SH SPECIAL ERROR CODE
+Looking in the
+.I foo
+service log it's possible to see messages in the form of
+.IP "" 2
+runsv: ERROR [NNN] in foo: reason for the error
+.PP
+These messages don't come from runsv itself but from
+.B invoke-run,
+the run file or the finish file. The purpose of these message
+is to detail a permanent failure condition that prevents
+.I foo
+service from being up.
+For each
+.I foo
+service, possible errors and messages are:
+.IP "" 2
+.B runsv: foo binary not installed
+.PP
+.IP "" 4
+this happens when the package containing
+.I foo
+binary has been removed, but not purged.
+.PP
+.IP "" 2
+.B runsv: ERROR -1 in foo: runscript didn't exit normally
+.PP
+.IP "" 4
+this message comes from the finish file, but the exit code comes from
+.BR runsv (8)
+and is documented in its manpage.
+.PP
+.IP "" 2
+.B runsv: WARNING for foo: disabled 

Bug#944417: transition: cgal

[Joachim Reichel]

Update on the current state:

cloudcompare   binNMU successful, all green
gudhi  binNMU successful, all green
mshr   binNMU successful, all green
openfoam   binNMU successful, all green
openscad   fixed by maintainer, all green
pygalmesh  fixed by maintainer, all green

sfcgal fixed by maintainer, all green but armhf (#946261)

crrcsimNMU in delayed queue (#946114), 3 days to go

openemsbinNMU would be sufficient, unrelated FTBFS
   (#946264), but not on autoremoval list (WHY?)
k3dpatch in BTS (#946228), unrelated FTBFS (#946225),
   autoremoval in 6 days
rheolefpatch in BTS (#946116), unrelated FTBFS (#944197),
   autoremoval in 10 days
yade   patch in BTS (#946223), unrelated FTBFS (#938859),
   autoremoval in 12 days, maintainer working on it

pprepair   removed from unstable and testing (#944775, #946133)
prepairremoved from unstable and testing (#944776, #946134)


  Joachim

Bug#946261: RM: sfcgal [armhf] -- ROM; Architecture specific issue

[Sebastiaan Couwenberg]

Control: reopen -1

On 12/7/19 8:45 AM, Debian Bug Tracking System wrote:
> We believe that the bug you reported is now fixed; the following
> package(s) have been removed from unstable:
> 
> libsfcgal-dev |1.3.7-2 | armhf
> 
> --- Reason ---
> ROM; Architecture specific issue
> --

libsfcgal1 also needs to be removed from armhf.


$ dak rm -Rn sfcgal -a armhf
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

libsfcgal1 |1.3.7-2 | armhf
sfcgal |1.3.7-2 | source
sfcgal |1.3.7-3 | source

Maintainer: Debian GIS Project 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


Kind Regards,

Bas

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

Bug#946403: cgal: Replace libgmp10-dev with libgmp-dev

[Sebastiaan Couwenberg]

On 12/8/19 7:17 PM, Joachim Reichel wrote:
> On 08.12.19 17:45, Bas Couwenberg wrote:
>> While looking into the postgis FTBFS with the rebuild sfcal, I noticed that 
>> cgal still uses the libgmp10-dev virtual package instead of libgmp-dev.
> 
> looks like I missed some memo ... Am I right that this does not cause any
> immediate problems and can wait until the next upload, or is this somehow 
> urgent?

That is correct, hence normal severity. Just commit the change to have
in the next upload whenever that may be.

It is quite an old change according the the gmp changelog, see:

 
https://tracker.debian.org/news/373449/accepted-gmp-2501dfsg-7-source-all-amd64/

Kind Regards,

Bas

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