Bug#950128:

[Mohammed Naser]

I can confirm the same issue on my side. I have not attempted any
workarounds but reading online this seems to be related to changes
some Kernel symbol changes.

http://rglinuxtech.com/?p=2614

The reading also has a patch in there which might help.

Bug#950128: Raise severity to grave

[Michael Rasmussen]

Hi,

See the same here, I wonder how this version could slip through Q&A.
Since the package is unbuildable and thereby renders useless to
everyone I suggest raising severity to grave.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
https://pgp.key-server.io/pks/lookup?search=0xD3C9A00E
mir  datanom  net
https://pgp.key-server.io/pks/lookup?search=0xE501F51C
mir  miras  org
https://pgp.key-server.io/pks/lookup?search=0xE3E80917
--
/usr/games/fortune -es says:
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plaugher)


pgpA58p5jSP9r.pgp
Description: OpenPGP digital signature

Bug#950005: next steps

[Christian Ehrhardt]

Thanks Björn

While I could merge the MR that would be bad (merging own stuff defies the
purpose of an MR).
Furthermore I can't upload it to Debian myself.

@Björn - if urgent, until then you might grab the slof deb from [1]. While
it is built for Ubuntu 20.04 IIRC it has no dependencies and should get you
going until things get into unstable/testing.

[1]:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3883/+packages


-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#950131: mixxx: Baseline violation on i386

[Adrian Bunk]

Source: mixxx
Version: 2.0.0~dfsg-7
Severity: serious

The package builds with -msse2, but SSE (or MMX) are not part
of the baseline of the i386 port.

Bug#945701: mock: Python2 removal in sid/bullseye

[Sandro Tosi]

Control: tags -1 +fixed-upstream

On Wed, 27 Nov 2019 23:58:50 + Sandro Tosi  wrote:
> Source: mock
> Version: 1.3.2-2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

it looks like the latest upstream release, 1.4.21-1, contains python3
support; but still someone needs to package that version quickly

Bug#914859: sysctl.conf: include (and set?) the upcoming protected_fifos and protected_regular options

[Craig Small]

Hi Chris,
  I have emailled the Debian developer list to check if anyone knows if
this may cause problems.  I would say that for the large majority of people
this change won't harm anything and would in fact be a benefit by closing
down one series of security bugs.  The concern is that it does break
something and nobody understands why some program that used to work fine no
longer does and they didn't touch it.

 - Craig


On Wed, 22 Jan 2020 at 02:03, Christoph Anton Mitterer <
cales...@scientia.net> wrote:

> Hey.
>
> Anything new on this? More than a year of people running with a less
> safe default config doesn't seem so good :-)
>
> Cheers,
> Chris.
>

Bug#950089: [Pkg-javascript-devel] Bug#950089: node-chrome-trace-event FTBFS: error TS2300: Duplicate identifier 'IteratorResult'

[Xavier]

Le 28/01/2020 à 22:31, Adrian Bunk a écrit :
> Source: node-chrome-trace-event
> Version: 1.0.0-1
> Severity: serious
> Tags: ftbfs bullseye sid
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-chrome-trace-event.html
> 
> ...
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/build/1st/node-chrome-trace-event-1.0.0'
> tsc --typeRoots debian/node_modules/@types --baseUrl debian/node_modules
> debian/node_modules/@types/node/index.d.ts(78,11): error TS2300: Duplicate 
> identifier 'IteratorResult'.
> ../../../usr/share/nodejs/typescript/lib/lib.es2015.iterable.d.ts(41,6): 
> error TS2300: Duplicate identifier 'IteratorResult'.
> make[1]: *** [debian/rules:12: override_dh_auto_build] Error 2

It seems that node-chrome-trace-event requires an old typescript. Can
anyone look if the code can be upgraded ? (no upstream release about this)

Bug#950130: ccbuild FTCBFS: debian/rules forces the build architecture compiler

[Helmut Grohne]

Source: ccbuild
Version: 2.0.7+git20160227.c1179286-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ccbuild fails to cross build from source, because debian/rules overrides
CXX with plain g++ and runs cmake without and cross flags. It doesn't do
this for fun, but because apparently the project is ignoring CXXFLAGS. A
look at CMakeLists.txt reveals why: The C++ language is not enabled.
Unfortunately, CMakeLists.txt looks like it is a generated file. We must
modify the bootstrap file and run it to change CMakeLists.txt. So once
you add "LANGUAGES CXX" to the project invocation and run bootstrap, it
all magically just works. That includes cross compilation. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru ccbuild-2.0.7+git20160227.c1179286/debian/changelog 
ccbuild-2.0.7+git20160227.c1179286/debian/changelog
--- ccbuild-2.0.7+git20160227.c1179286/debian/changelog 2016-08-19 
14:27:46.0 +0200
+++ ccbuild-2.0.7+git20160227.c1179286/debian/changelog 2020-01-29 
05:57:03.0 +0100
@@ -1,3 +1,10 @@
+ccbuild (2.0.7+git20160227.c1179286-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use dh_auto_configure. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 29 Jan 2020 05:57:03 +0100
+
 ccbuild (2.0.7+git20160227.c1179286-1) unstable; urgency=medium
 
   * Use an upstream version number that is actually greater than 2.0.7.
diff --minimal -Nru ccbuild-2.0.7+git20160227.c1179286/debian/clean 
ccbuild-2.0.7+git20160227.c1179286/debian/clean
--- ccbuild-2.0.7+git20160227.c1179286/debian/clean 1970-01-01 
01:00:00.0 +0100
+++ ccbuild-2.0.7+git20160227.c1179286/debian/clean 2020-01-29 
05:57:03.0 +0100
@@ -0,0 +1 @@
+CMakeLists.txt
diff --minimal -Nru 
ccbuild-2.0.7+git20160227.c1179286/debian/patches/cross.patch 
ccbuild-2.0.7+git20160227.c1179286/debian/patches/cross.patch
--- ccbuild-2.0.7+git20160227.c1179286/debian/patches/cross.patch   
1970-01-01 01:00:00.0 +0100
+++ ccbuild-2.0.7+git20160227.c1179286/debian/patches/cross.patch   
2020-01-29 05:57:03.0 +0100
@@ -0,0 +1,11 @@
+--- ccbuild-2.0.7+git20160227.c1179286.orig/bootstrap
 ccbuild-2.0.7+git20160227.c1179286/bootstrap
+@@ -34,7 +34,7 @@
+ #Write CMakeLists.txt
+ cat > CMakeLists.txt <

Bug#950128: nvidia-graphics-drivers: Error! Bad return status for module build on kernel: 5.4.0-3-amd64 (x86_64)

[Bas Couwenberg]

Source: nvidia-graphics-drivers
Version: 435.21-3
Severity: serious
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

The upgrade of nvidia-kernel-dkms failed due to building the module for 
5.4.0-3-amd64 failing:

 Building initial module for 5.4.0-3-amd64
 Error! Bad return status for module build on kernel: 5.4.0-3-amd64 (x86_64)
 Consult /var/lib/dkms/nvidia-current/435.21/build/make.log for more 
information.

The make.log shows:

 The Module.symvers file is missing, or does not contain any
 symbols exported from the kernel. This could cause the NVIDIA
 kernel modules to be built against a configuration that does
 not accurately reflect the actual target kernel.
 The Module.symvers file check can be disabled by setting the
 environment variable IGNORE_MISSING_MODULE_SYMVERS to 1.
 make[3]: *** [/var/lib/dkms/nvidia-current/435.21/build/Kbuild:198: 
module_symvers_sanity_check] Error 1

Setting the env var doesn't help.

Kind Regards,

Bas


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

Kernel: Linux 5.3.0-2-amd64 (SMP w/6 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 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
DKMS make.log for nvidia-current-435.21 for kernel 5.4.0-3-amd64 (x86_64)
Wed 29 Jan 2020 06:14:09 AM CET
make KBUILD_OUTPUT=/lib/modules/5.4.0-3-amd64/build V=1 -C 
/lib/modules/5.4.0-3-amd64/source M=/var/lib/dkms/nvidia-current/435.21/build 
ARCH=x86_64 NV_KERNEL_SOURCES=/lib/modules/5.4.0-3-amd64/source 
NV_KERNEL_OUTPUT=/lib/modules/5.4.0-3-amd64/build NV_KERNEL_MODULES="nvidia 
nvidia-uvm nvidia-modeset nvidia-drm" INSTALL_MOD_DIR=kernel/drivers/video 
NV_SPECTRE_V2=0 modules
make[1]: Entering directory '/usr/src/linux-headers-5.4.0-3-common'
make -C /usr/src/linux-headers-5.4.0-3-amd64 -f 
/usr/src/linux-headers-5.4.0-3-common/Makefile modules
make[2]: Entering directory '/usr/src/linux-headers-5.4.0-3-amd64'
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2;   \
echo >&2 "  ERROR: Kernel configuration is invalid.";   \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are 
missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix 
it.";  \
echo >&2 ;  \
/bin/false)
make -f /usr/src/linux-headers-5.4.0-3-common/scripts/Makefile.build 
obj=/var/lib/dkms/nvidia-current/435.21/build single-build= need-builtin=1 
need-modorder=1
  ln -sf 
/var/lib/dkms/nvidia-current/435.21/build/nvidia/nv-kernel-amd64.o_binary 
/var/lib/dkms/nvidia-current/435.21/build/nvidia/nv-kernel.o
NV_CONFTEST_CMD=/bin/sh /var/lib/dkms/nvidia-current/435.21/build/conftest.sh " 
gcc-9" x86_64 /lib/modules/5.4.0-3-amd64/source /lib/modules/5.4.0-3-amd64/build
NV_CONFTEST_CFLAGS=-O2 -D__KERNEL__ -DKBUILD_BASENAME="#conftest3399488" 
-DKBUILD_MODNAME="#conftest3399488" -nostdinc -isystem 
/usr/lib/gcc/x86_64-linux-gnu/9/include 
-I/lib/modules/5.4.0-3-amd64/source/arch/x86/include/asm/mach-default 
-I/lib/modules/5.4.0-3-amd64/source/include/asm-x86/mach-default 
-I/lib/modules/5.4.0-3-amd64/build/include2 
-I/lib/modules/5.4.0-3-amd64/build/include -include 
/lib/modules/5.4.0-3-amd64/build/include/generated/autoconf.h 
-I/lib/modules/5.4.0-3-amd64/source/arch/x86/include 
-I/lib/modules/5.4.0-3-amd64/source/arch/x86/include/uapi 
-I/lib/modules/5.4.0-3-amd64/build/arch/x86/include/generated 
-I/lib/modules/5.4.0-3-amd64/build/arch/x86/include/generated/uapi 
-I/lib/modules/5.4.0-3-amd64/source/include 
-I/lib/modules/5.4.0-3-amd64/source/include/uapi 
-I/lib/modules/5.4.0-3-amd64/source/include/xen 
-I/lib/modules/5.4.0-3-amd64/build/include/generated/uapi -Wall -Wundef 
-Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE 
-Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx 
-m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 
-mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone 
-mcmodel=kernel -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1 
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_SSSE3=1 
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 
-DCONFIG_AS_SHA256_NI=1 -Wno-sign-compare -fno-asynchronous-unwind-tables 
-mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables 
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation 
-Wno-format-overflow -Wno-address-of-packed-member -O2 
--par

Bug#950129: pyside2 ftbfs in unstable

[Matthias Klose]

Package: src:pyside2
Version: 5.13.2-2.2
Severity: serious
Tags: sid bullseye

[...]
Running process in directory /home/packages/tmp/p/pyside2-5.13.2: command
/usr/bin/patchelf --set-rpath $ORIGIN/
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2/libshiboken2.cpython-37m-x86_64-linux-gnu.so.5.13
Patched rpath to '$ORIGIN/' (Linux) or updated rpath (OS/X) in
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2/libshiboken2.cpython-37m-x86_64-linux-gnu.so.5.13.
Running process in directory /home/packages/tmp/p/pyside2-5.13.2: command
/usr/bin/patchelf --set-rpath $ORIGIN/
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2/shiboken2.cpython-37m-x86_64-linux-gnu.so
Patched rpath to '$ORIGIN/' (Linux) or updated rpath (OS/X) in
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2/shiboken2.cpython-37m-x86_64-linux-gnu.so.
running build_py
package init file 'sources/shiboken2/shibokenmodule/__init__.py' not found (or
not a regular file)
running build_ext
*** Build completed (151s)
running build
Python architecture is 64bit
Using /usr/bin/patchelf ...

Preparing setup tools build directory.

Copying tree
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/lib/python3.7/site-packages/shiboken2_generator
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator.
filter=None. ignore=None.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/lib/python3.7/site-packages/shiboken2_generator/_config.py
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/_config.py.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/lib/python3.7/site-packages/shiboken2_generator/__init__.py
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/__init__.py.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/lib/python3.7/site-packages/shiboken2_generator/_git_shiboken_generator_version.py
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/_git_shiboken_generator_version.py.
Copying tree
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/bin/
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator.
filter=['shiboken2']. ignore=None.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/bin/shiboken2
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/shiboken2.
Making file
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/scripts/shiboken_tool.py.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/bin/shiboken_tool.py
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/scripts/shiboken_tool.py.
Copying tree
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/include/shiboken2
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/include.
filter=None. ignore=None.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/include/shiboken2/sbkdbg.h
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/include/sbkdbg.h.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/include/shiboken2/sbkconverter.h
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/include/sbkconverter.h.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/include/shiboken2/sbkenum.h
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/include/sbkenum.h.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/include/shiboken2/sbkstring.h
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/include/sbkstring.h.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/include/shiboken2/sbkpython.h
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/include/sbkpython.h.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwithdebinfo/include/shiboken2/basewrapper.h
to
/home/packages/tmp/p/pyside2-5.13.2/.pybuild/cpython3_3.7_pyside2/build/shiboken2_generator/include/basewrapper.h.
Copying file
/home/packages/tmp/p/pyside2-5.13.2/pyside3_install/py3.7-qt5.12.5-64bit-relwi

Bug#949380: gmp: Please update to 6.2.0

[Steven Robbins]

On Tuesday, January 28, 2020 4:13:17 P.M. CST Hugh McMaster wrote:
> Hi Steve,
> 
> On Sun, 26 Jan 2020 at 14:33, Steven Robbins wrote:
> > I've just uploaded to experimental and pushed the source changes to salsa.
> > Early feedback would be extremely helpful!
> 
> Thanks for the prompt response and upload to experimental.
> 
> I’ll do some testing tonight, but I noticed you’re not packaging the
> pkg-config files (there are two) upstream now supplies.

Good catch, thanks!  I've pushed the change to salsa; will be in the next
upload.

-Steve


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

Bug#950127: pyside2 fails all autopkg tests

[Matthias Klose]

Package: src:pyside2
Version: 5.13.2-2.2
Severity: serious
Tags: sid bullseye

https://ci.debian.net/packages/p/pyside2/

[...]
autopkgtest [09:55:16]:  summary
command1 FAIL non-zero exit status 127
command2 FAIL non-zero exit status 127
command3 FAIL non-zero exit status 127
command4 FAIL non-zero exit status 127
command5 FAIL non-zero exit status 127
command6 FAIL non-zero exit status 127
command7 FAIL non-zero exit status 127
command8 FAIL non-zero exit status 127
command9 FAIL non-zero exit status 127
command10FAIL non-zero exit status 127
command11FAIL non-zero exit status 127
command12FAIL non-zero exit status 127
command13FAIL non-zero exit status 127
command14FAIL non-zero exit status 127
command15FAIL non-zero exit status 127
command16FAIL non-zero exit status 127
command17FAIL non-zero exit status 127
command18FAIL non-zero exit status 127
command19FAIL non-zero exit status 127
command20FAIL non-zero exit status 127
command21FAIL non-zero exit status 127
command22FAIL non-zero exit status 127
command23FAIL non-zero exit status 127
command24FAIL non-zero exit status 127
command25FAIL non-zero exit status 127
command26FAIL non-zero exit status 127
command27FAIL non-zero exit status 127
command28FAIL non-zero exit status 127
command29FAIL non-zero exit status 127
command30FAIL non-zero exit status 127
command31FAIL non-zero exit status 127
command32FAIL non-zero exit status 127
command33FAIL non-zero exit status 127
command34FAIL non-zero exit status 127
command35FAIL non-zero exit status 127
command36FAIL non-zero exit status 127
command37FAIL non-zero exit status 127
command38FAIL non-zero exit status 127
command39FAIL non-zero exit status 127
command40FAIL non-zero exit status 127

Bug#950076: install fails due to changed OpenStreetMap URLs

[Sebastiaan Couwenberg]

On 1/28/20 8:53 PM, Manfred Hampl wrote:
> Another possible solution to solve this problem would be an upgrade to the 
> most recent version from upstream source (4.24.1)

That's not possible because it requires a newer node-carto which has a
problematic dependency chain like many Node.js packages, no one has been
able to update node-carto for a while.

openstreetmap-carto will be removed from Debian if that is not resolved
during the next development cycle.

Kind Regards,

Bas

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

Bug#948745: ksh2020 vs. ksh93

[Anuradha Weeraman]

On Tue, Jan 28, 2020 at 07:49:27PM +0100, Thorsten Glaser wrote:
> Thanks for having a look over it (oneself doesn’t find one’s own errors
> as good as others).

I certainly learnt a thing or two.

> Am I correct in assuming you’ll need DM upload privileges on it, once
> it’s accepted?

Yes, please, if you would be willing to.

-- 
Regards
Anuradha

Bug#950126: pyside2 ftbfs in experimental

[Matthias Klose]

Package: src:pyside2
Version: 5.14.0-1~exp1
Severity: serious
Tags: sid bullseye

[...]
(gui) [3295ms] Writing log files...
[ESC[0;32mOKESC[0m]
(gui) [3327ms] Running Source generator...
qt.shiboken: (gui) There's no user provided way (conversion rule, argument
removal, custom code, etc) to handle the primiti
ve type 'int *' of argument 2 in function
'QAccessibleTextInterface::attributes(int offset, int * startOffset, int *
endOffset) const'.
qt.shiboken: (gui) There's no user provided way (conversion rule, argument
removal, custom code, etc) to handle the primitive type 'int *' of argument 3 in
function 'QAccessibleTextInterface::attrib
utes(int offset, int * startOffset, int * endOffset) const'.
qt.shiboken: (gui) There's no user provided way (conversion rule, argument
removal, custom code, etc) to handle the primitive type 'int *' of argument 2 in
function 'QAccessibleTextInterface::select
ion(int selectionIndex, int * startOffset, int * endOffset) const'.
qt.shiboken: (gui) There's no user provided way (conversion rule, argument
removal, custom code, etc) to handle the primitive type 'int *' of argument 3 in
function 'QAccessibleTextInterface::select
ion(int selectionIndex, int * startOffset, int * endOffset) const'.
qt.shiboken: (gui) There's no user provided way (conversion rule, argument
removal, custom code, etc) to handle the primitive type 'int *' of argument 3 in
function 'QAccessibleTextInterface::textAf
terOffset(int offset, QAccessible::TextBoundaryType boundaryType, int *
startOffset, int * endOffset) const'.
qt.shiboken: (gui) There's no user provided way (conversion rule, argument
removal, custom code, etc) to handle the primitive type 'int *' of argument 4 in
function 'QAccessibleTextInterface::textAf
terOffset(int offset, QAccessible::TextBoundaryType boundaryType, int *
startOffset, int * endOffset) const'.
qt.shiboken: (gui) There's no user provided way (conversion rule, argument
removal, custom code, etc) to handle the primitive type 'int *' of argument 3 in
function 'QAccessibleTextInterface::textAt
Offset(int offset, QAccessible::TextBoundaryType boundaryType, int *
startOffset, int * endOffset) const'.
qt.shiboken: (gui) There's no user provided way (conversion rule, argument
removal, custom code, etc) to handle the primitive type 'int *' of argument 4 in
function 'QAccessibleTextInterface::textAt
Offset(int offset, QAccessible::TextBoundaryType boundaryType, int *
startOffset, int * endOffset) const'.
qt.shiboken: (gui) There's no user provided way (conversion rule, argument
removal, custom code, etc) to handle the primitive type 'int *' of argument 3 in
function 'QAccessibleTextInterface::textBe
foreOffset(int offset, QAccessible::TextBoundaryType boundaryType, int *
startOffset, int * endOffset) const'.
qt.shiboken: (gui) There's no user provided way (conversion rule, argument
removal, custom code, etc) to handle the primitive type 'int *' of argument 4 in
function 'QAccessibleTextInterface::textBe
foreOffset(int offset, QAccessible::TextBoundaryType boundaryType, int *
startOffset, int * endOffset) const'.
/packages/tmp/p/pyside2-5.14.0/sources/pyside2/libpyside/signalmanager.cpp:56:10:
fatal error: sbkstaticstrings.h: No such file or directory
   56 | #include 
  |  ^~~~
compilation terminated.
make[4]: *** [libpyside/CMakeFiles/pyside2.dir/build.make:96:
libpyside/CMakeFiles/pyside2.dir/signalmanager.cpp.o] Error 1
make[4]: Leaving directory
'/packages/tmp/p/pyside2-5.14.0/pyside3_build/py3.8-qt5.12.5-64bit-relwithdebinfo/pyside2'
make[3]: *** [CMakeFiles/Makefile2:129: libpyside/CMakeFiles/pyside2.dir/all]
Error 2
make[3]: *** Waiting for unfinished jobs

Bug#936806: koji: Python2 removal in sid/bullseye

[Sandro Tosi]

Control: tags -1 +fixed-upstream

On Fri, 30 Aug 2019 09:57:23 + Holger Levsen  wrote:
> On Fri, Aug 30, 2019 at 07:22:19AM +, Matthias Klose wrote:
> > Package: src:koji
> > Version: 1.16.2-1
> [...]
> > Your package either build-depends, depends on Python2, or uses Python2
> > in the autopkg tests.  Please stop using Python2, and fix this issue
> > by one of the following actions.
>
> koji 1.18 has been ported to python 3 and needs to be packaged to solve
> this.

ok, whos of the maintainers is working on packaging 1.18? i see
there's even 1.20 released.

koji is keeping createrepo in the archive, which keeps python-lzma in
the archive.

upgrading koji will help getting rid of some old python2 packages.

Thanks,
Sandro

Bug#950125: ITP: go-mmproxy -- Golang implementation of mmproxy

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

   Package name: go-mmproxy
Version: 1.0
Upstream Author: Path Network, Inc.
License: BSD-3-Clause~Google
URL: https://github.com/path-network/go-mmproxy
Vcs-Browser: https://salsa.debian.org/go-team/packages/go-mmproxy
Description: Golang implementation of mmproxy
 'go-mmproxy' is a standalone application that unwraps HAProxy's
 PROXY-protocol so that the TCP connection to the end server comes from
 client's - instead of proxy server's - IP address and port number.
 .
 This is a Golang reimplementation of mmproxy created to improve on
 mmproxy's runtime stability while providing potentially greater
 performance in terms of connection and packet throughput.


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

Bug#950124: RFS: rumur/2020.01.27-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.01.27-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   Section : devel

It builds those binary packages:

  rumur - model checker for the Murphi language

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2020.01.27-1.dsc

Changes since the last upload:

   * New upstream release.
.
   * Add strace as a build dependency.
.
   * Update Standards-Version from 4.4.1 to 4.5.0.
.
   * Some robustness improvements to the autopkgtests.
.
   * RUMUR_VERSION variable in rules is now set automatically from the changelog
 using pkg-info.mk support.

Regards,
Matthew

Bug#598913: Director

[wwwunitedban...@gmail.com]

Bug#950123: virtualenvwrapper: Autocomplete not loaded in default install

[James Tocknell]

Package: virtualenvwrapper
Version: 4.8.4-4
Severity: important

Hi virtualenvwrapper maintainers,

virtualenvwrapper doesn't seem to load from the autocomplete launcher in a clean
chroot (created via debootstrap). I've tried digging to why this is, but I'm not
familiar enough with bash's autocomplete to work out whether this is a
virtualenvwrapper bug or a bash-completion bug. My tests have been to add printf
lines to the autocomplete code, but these never appear to print (whether that's
because I've done something wrong, or something else, I'm not sure). Strangely,
this works fine in on my main system, it's in containers or chroots that seem to
be the problem.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FORCED_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_AU.UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virtualenvwrapper depends on:
ii  python3-virtualenvwrapper  4.8.4-4
ii  virtualenv 15.1.0+ds-2

Versions of packages virtualenvwrapper recommends:
ii  bash-completion  1:2.10-1

Versions of packages virtualenvwrapper suggests:
pn  virtualenvwrapper-doc  

-- no debconf information

Bug#733631: ksh compatibility

[Vincent Lefevre]

On 2015-10-28 09:14:05 +, Nicholas Bamber wrote:
> This has been documented on the interwebs and in print as a Good Thing (TM).
> http://docstore.mik.ua/orelly/unix3/korn/appb_08.htm To quote:
> 
> 
> "Starting with ksh93m, the built-in arithmetic facility understands a large
> percentage of the C language's expressions. This makes the shell more
> attractive as a full-blown programming language. The following features are
> available:
> 
> ..
> 
> Octal and hexadecimal constants
> You can use the C format for octal (base 8) and hexadecimal (base 16)
> constants. Octal constants start with a leading 0, and hexadecimal constants
> start with a leading 0x or 0X. For example:
> $ print $((010 + 1)) Octal 10 is decimal 8
> 9
> "

Perhaps this should be reverted in ksh2020. Several languages have
already moved away from the leading 0 prefix (generally replacing it
with the unambiguous 0o or 0O prefix): D, ECMAScript, Python, TCL
(and Perl 6, though that's a language different from Perl 5).

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

Bug#937455: pygts: Python2 removal in sid/bullseye

[Stuart Prescott]

pygts is dead upstream and the C parts of the code will need a bit of work to 
port them to Python 3. This package does have a reasonable popcon (281) but 
it's hard to see the porting work happening.

The package needs to go through NEW either with an added python3-gts binary 
package or if removed and then re-added later after porting.

Is it time to remove pygts from Debian?

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#950122: Nautilus & JPEG 2000 Stream Code files

[Apollo Clandestino]

Package: nautilus
Version: 3.30.5-2

Hello.

The Nautilus browser crashes within directories containing "jpeg 2000 code
stream" files. The file extension for jpeg 2000 code stream files actually
is ".j2c".
Virtual World Viewer developers actually have deemed jpeg 2000 code stream
files as "important".
In the past, I have used the Konqueror file browser to navigate directories
that have .j2c files, & I use a converter utility to create the files where
necessary.

I am using Debian Wheezy i386 (just because I liked Wheezy: Wheeze the
Juice!!) & Debian Buster amd64.

Somebody suggested that I file a bug report, since I like to use Nautilus,
& am a proponent of Gnome.
:)

Thanks.

Signed,
jsync.

Bug#950121: opensmtpd: Major vulnerabilities in opensmtpd resulting in RCE and DOS

[Ryan Kavanagh]

Control: found -1 6.0.2p1-2
Control: fixed -1 6.6.2p1-1

This has already been fixed in unstable. I am preparing updates for
oldstable and stable.

—RAK

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#950121: opensmtpd: Major vulnerabilities in opensmtpd resulting in RCE and DOS

[martian67]

>From the OpenBSD security advisory

>Errata patches for OpenSMTPD have been released for OpenBSD 6.5 and 6.6.
>
>smtpd can crash on opportunistic TLS downgrade, causing a denial of service.
>
>Binary updates for the amd64, i386, and arm64 platforms are available via
>the syspatch utility. Source code patches can be found on the respective
>errata page
>
>An incorrect check allows an attacker to trick mbox delivery into executing
>arbitrary commands as root and lmtp delivery into executing arbitrary commands
>as an unprivileged user.
>
>Binary updates for the amd64, i386, and arm64 platforms are available via
>the syspatch utility. Source code patches can be found on the respective
>errata page

https://marc.info/?l=openbsd-announce&m=158025067728747&w=2
https://marc.info/?l=openbsd-announce&m=158025060628722&w=2

Bug#950121: opensmtpd: Major vulnerabilities in opensmtpd resulting in RCE and DOS

[m]

Package: opensmtpd
Version: 6.6.1p1-5~bpo10+1
Severity: critical
Tags: security upstream
Justification: root security hole

Dear Maintainer,

Opensmtpd 6.6.1 has 2 critical vulnerabilities, including one that results in a 
remote root arbitray code execution

see https://www.mail-archive.com/misc@opensmtpd.org/msg04850.html

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

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

Versions of packages opensmtpd depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  ed 1.15-1
ii  init-system-helpers1.56+nmu1
ii  libasr01.0.2-2
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libevent-2.1-6 2.1.8-stable-4
ii  libpam0g   1.3.1-5
ii  libssl1.1  1.1.1d-0+deb10u2
ii  lsb-base   10.2019051400
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages opensmtpd recommends:
ii  opensmtpd-extras  6.6.0-1~bpo10+1

Versions of packages opensmtpd suggests:
ii  ca-certificates  20190110

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

-- debconf information excluded

Bug#949921: buster-pu: package uim_1.8.8-4+deb10u3

[Takatsugu Nokubi]

2020年1月29日(水) 7:37 Adam D. Barratt :
> Are all of these changes already applied to the package in unstable?

This fix is not necessary in unstable, because libuim-data is removed
on unstable.
At first, this transition had coded in buster, but it had canceled
because of postinst bug,
so the last buster-pu package recontained libuim-data.
This fix affects only buser, not unstable.

Bug#950116: gplaycli: KeyError: 'docId'

[Thorsten Glaser]

tags 950116 + patch
thanks

Find below a patch extracted from commit 
719793f65a1ae4e91a12fc49d510095f6bf45e0b
which at least fixes the docId issue.

The “Item not found” issue might be because the shitty DB Navigator äpp
requires Android 5 (and thus is unusable anyway)… but with the nonexistent
documentation and bad error messages gplaycli has, who knows…

--- /usr/lib/python3/dist-packages/gplaycli/gplaycli.py.orig
+++ /usr/lib/python3/dist-packages/gplaycli/gplaycli.py
@@ -249,9 +249,9 @@
 
if filename is None:
if self.append_version:
-   filename = detail['docId']+ "-v." + 
detail['versionString'] + ".apk"
+   filename = detail['docid']+ "-v." + 
detail['versionString'] + ".apk"
else:
-   filename = detail['docId']+ ".apk"
+   filename = detail['docid']+ ".apk"
 
logger.info("%s / %s %s", position, 
len(pkg_todownload), packagename)
 
@@ -300,7 +300,7 @@
for obb_file in additional_data:
obb_filename = 
"%s.%s.%s.obb" % (obb_file["type"],

 obb_file["versionCode"],
-   
 data_iter["docId"])
+   
 data_iter["docid"])
obb_filename = 
os.path.join(download_folder, obb_filename)
obb_total_size = 
int(obb_file['file']['total_size'])
obb_chunk_size = 
int(obb_file['file']['chunk_size'])
@@ -371,7 +371,7 @@
  if result['installationSize'] > 0 
else 'N/A',
  result['numDownloads'],
  result['uploadDate'],
- result['docId'],
+ result['docid'],
  result['versionCode'],
  "%.2f" % 
result["aggregateRating"]["starRating"]
  ]

Bug#950096: flatpak: Flatpak fails to open SSL connections with p11-kit 0.23.19

[Lennart Weller]

I did a downgrade on the host system back to the version currently in testing 
0.23.18 and it works again.

There are some on-going discussions on the rolling release distros:
https://forum.manjaro.org/t/update-2020-01-26-has-a-bug/121375/6
https://bbs.archlinux.org/viewtopic.php?id=252390
https://github.com/flathub/com.valvesoftware.Steam/issues/526

>From what I have gathered this requires a change of the runtime to interface 
>with the p11-kit daemon correctly. But I don't know if that is something that 
>can be quickly fixed on your side.

Jan 29, 2020 00:05:14 Simon McVittie :

> On Tue, 28 Jan 2020 at 22:50:31 +0100, Lennart Weller wrote:
> 
> > Currently all SSL connections, probably mostly HTTPS, will fail with
> > flatpak due to a major API change in p11-kit as discussed in the merge
> > request[1] for p11-kit 0.23.19, cause obviously a patch-version changes
> > major API endpoints.
> > 
> 
> Is there something that can be done in the Flatpak executables to make
> this work better, or is it a problem with the freedesktop.org reference
> runtime?
> 
> Is this triggered by the new p11-kit in the host system, or by the new
> p11-kit in the runtime, or by them being on opposite sides of the 0.23.19
> version threshold, or what?
> 
> Thanks,
> smcv
> 

Bug#950120: RFS: udftools/2.2-1 -- tools for UDF filesystems and DVD/CD-R(W) drives

[Pali Rohár]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: udftools
   Version : 2.2-1
   Upstream Author : Pali Rohár 
 * URL : https://github.com/pali/udftools
 * License : GPL-2+
 * Vcs : None
   Section : otherosfs

It builds those binary packages:

  udftools - tools for UDF filesystems and DVD/CD-R(W) drives

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/udftools/udftools_2.2-1.dsc

Changes since the last upload:

   * New upstream release

Regards,

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#950118: linux-image-4.19.0-6-amd64: Misleading/Confusing dmesgs regarding Spectre V2 user space Mitigation

[Leon Gehling]

Package: src:linux
Version: 4.19.67-2+deb10u2
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Kernel yells "Spectre V2 : User space: Vulnerable" at me despite i have newest
microcode , and spectre_v2_user=on bootparameter set, IBPB: always on is also
described in dmesgs.
see here:

sudo dmesg | grep -i spectre
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.19.0-6-amd64
root=/dev/mapper/thanatos--vg-root ro quiet random.trust_cpu=off spectre_v2=on
spectre_v2_user=on
[0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-6-amd64
root=/dev/mapper/thanatos--vg-root ro quiet random.trust_cpu=off spectre_v2=on
spectre_v2_user=on
[0.008350] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user
pointer sanitization
[0.008351] Spectre V2 : Mitigation: Full AMD retpoline
[0.008352] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on
context switch
[0.008357] Spectre V2 : mitigation: Enabling always-on Indirect Branch
Prediction Barrier
[0.008358] Spectre V2 : User space: Vulnerable


CPU is AMD Ryzen 7 2700.
Microcode: CPU0: patch_level=0x0800820d


Output from spectre-meltdown-checker:

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface:  YES  (Mitigation: Full AMD
retpoline, IBPB: always-on, STIBP: disabled, RSB filling)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES
* IBRS enabled and active:  NO
  * Kernel is compiled with IBPB support:  YES
* IBPB enabled and active:  YES
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO
  * Kernel compiled with retpoline option:  YES
* Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports
full retpoline compilation)
> STATUS:  NOT VULNERABLE  (Full retpoline + IBPB are mitigating the
vulnerability)



-- Package-specific info:
** Version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-6-amd64 root=/dev/mapper/thanatos--vg-root ro quiet 
random.trust_cpu=off spectre_v2=on spectre_v2_user=on

** Not tainted

** Kernel log:
[  103.668388] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  103.668436] sd 1:0:0:0: Attached scsi generic sg1 type 0
[  103.668540] sd 4:0:0:0: Attached scsi generic sg2 type 0
[  103.668574] sd 11:0:0:0: Attached scsi generic sg3 type 0
[  103.669725] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver
[  103.669799] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO address
[  103.669808] sp5100-tco sp5100-tco: Watchdog hardware is disabled
[  103.679757] ccp :09:00.2: ccp enabled
[  103.679782] ccp :09:00.2: psp initialization failed
[  103.679783] ccp :09:00.2: enabled
[  103.718440] snd_hda_intel :08:00.1: Handle vga_switcheroo audio client
[  103.733222] systemd-journald[493]: Received request to flush runtime journal 
from PID 1
[  103.736906] input: HD-Audio Generic HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.1/:06:00.0/:07:00.0/:08:00.1/sound/card0/input7
[  103.736944] input: HD-Audio Generic HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.1/:06:00.0/:07:00.0/:08:00.1/sound/card0/input8
[  103.736980] input: HD-Audio Generic HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.1/:06:00.0/:07:00.0/:08:00.1/sound/card0/input9
[  103.737015] input: HD-Audio Generic HDMI/DP,pcm=9 as 
/devices/pci:00/:00:03.1/:06:00.0/:07:00.0/:08:00.1/sound/card0/input10
[  103.737052] input: HD-Audio Generic HDMI/DP,pcm=10 as 
/devices/pci:00/:00:03.1/:06:00.0/:07:00.0/:08:00.1/sound/card0/input11
[  103.737158] input: HD-Audio Generic HDMI/DP,pcm=11 as 
/devices/pci:00/:00:03.1/:06:00.0/:07:00.0/:08:00.1/sound/card0/input12
[  103.743417] kvm: Nested Virtualization enabled
[  103.743428] kvm: Nested Paging enabled
[  103.743429] SVM: Virtual VMLOAD VMSAVE supported
[  103.743429] SVM: Virtual GIF supported
[  103.745943] MCE: In-kernel MCE decoding enabled.
[  103.747745] EDAC amd64: Node 0: DRAM ECC enabled.
[  103.747746] EDAC amd64: F17h detected (node 0).
[  103.747786] EDAC MC: UMC0 chip selects:
[  103.747787] EDAC amd64: MC: 0: 16383MB 1: 16383MB
[  103.747788] EDAC amd64: MC: 2: 0MB 3: 0MB
[  103.747789] EDAC amd64: MC: 4: 0MB 5: 0MB
[  103.747789] EDAC amd64: MC: 6: 0MB 7: 0MB
[  103.747791] EDAC MC: UMC1 chip selects:
[  103.747792] EDAC amd64: MC: 0: 16383MB 1: 16383MB
[  103.747793] EDAC amd64: MC: 2: 0MB 3: 0MB
[  103.747793] EDAC amd64: MC: 4: 0MB 5: 0MB
[  103.7477

Bug#950119: ITP: gajim-syntaxhighlight -- highlights source code blocks in chat window

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 

* Package name: gajim-syntaxhighlight
  Version : 1.2.5
  Upstream Author : Florian Muenchbach
* URL : 
https://dev.gajim.org/gajim/gajim-plugins/-/wikis/syntaxhighlightplugin
* License : GPL3
  Programming Lang: Python
  Description : highlights source code blocks in chat window

 It uses markdown-style syntax, i.e. text in-between `single backticks` is
 rendered as inline code,
 ```language
 selection is possible in multi-line code snippets in between triple-backticks
 Note the newlines in this case…
 ```

Bug#950117: report debian/upstream/metadata without upstream bug tracking information

[Jelmer Vernooij]

Package: lintian
Version: 2.47.0
Severity: wishlist

It would be great if lintian reported when a debian/upstream/metadata file did
not contain any upstream bug tracking information (i.e. the Bug-Database or
Bug-Submit fields are not set).

-- 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 depends on:
ii  binutils 2.33.90.20200122-2
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.19-1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b2
ii  libarchive-zip-perl  1.67-1
ii  libberkeleydb-perl   0.62-1+b1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.45-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3100-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.008001-2
ii  liburi-perl  1.76-1
ii  libxml-libxml-perl   2.0134+dfsg-1+b1
ii  libyaml-libyaml-perl 0.80+repack-2+b1
ii  man-db   2.9.0-2
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b4
ii  libtext-template-perl  1.58-1

-- no debconf information

Bug#950116: gplaycli: KeyError: 'docId' --or-- 'Item not found.'

[Thorsten Glaser]

Package: gplaycli
Version: 3.26+dfsg-1
Severity: grave
Justification: renders package unusable

Similar to #950114, downloading (getting the ID from the gplay
website) does not work:

$ gplaycli -pvd com.musescore.playerlite
[INFO] GPlayCli version 3.26 [Python3.7.6]
[INFO] Configuration file is /etc/gplaycli/gplaycli.conf
[INFO] Device is bacon
[INFO] Using credentials to connect to API
[INFO] Using plaintext password
Traceback (most recent call last):
  File "/usr/bin/gplaycli", line 11, in 
load_entry_point('GPlayCli==3.26', 'console_scripts', 'gplaycli')()
  File "/usr/lib/python3/dist-packages/gplaycli/gplaycli.py", line 724, in main
cli.download(args.packages_to_download)
  File "/usr/lib/python3/dist-packages/gplaycli/hooks.py", line 9, in 
check_connection
return function(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/gplaycli/gplaycli.py", line 254, in 
download
filename = detail['docId']+ ".apk"
KeyError: 'docId'


Another error I see is this:


$ gplaycli -vpd de.hafas.android.db
[INFO] GPlayCli version 3.26 [Python3.7.6]
[INFO] Configuration file is /etc/gplaycli/gplaycli.conf
[INFO] Device is bacon
[INFO] Using credentials to connect to API
[INFO] Using plaintext password
[ERROR] A few packages could not be downloaded :
de.hafas.android.db
'Item not found.'


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

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

Versions of packages gplaycli depends on:
ii  python3   3.7.5-3
ii  python3-crypto2.6.1-13
ii  python3-gpapi 0.4.4-1
ii  python3-pyaxmlparser  0.3.24-1

Versions of packages gplaycli recommends:
pn  dummydroid
pn  fdroidserver  

gplaycli suggests no packages.

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

-- no debconf information

Bug#950096: flatpak: Flatpak fails to open SSL connections with p11-kit 0.23.19

[Simon McVittie]

On Tue, 28 Jan 2020 at 22:50:31 +0100, Lennart Weller wrote:
> Currently all SSL connections, probably mostly HTTPS, will fail with
> flatpak due to a major API change in p11-kit as discussed in the merge
> request[1] for p11-kit 0.23.19, cause obviously a patch-version changes
> major API endpoints.

Is there something that can be done in the Flatpak executables to make
this work better, or is it a problem with the freedesktop.org reference
runtime?

Is this triggered by the new p11-kit in the host system, or by the new
p11-kit in the runtime, or by them being on opposite sides of the 0.23.19
version threshold, or what?

Thanks,
smcv

Bug#950112: gplaycli: 502 Bad Gateway, does not work at all

[Thorsten Glaser]

Dixi quod…

>[ERROR] Unknown error: 
>502 Bad Gateway

It’s apparently possible to work around this error by
getting a Google account, logging in, creating an
application password, then putting that password and
the eMail address used as login, as well as token=False,
into /etc/gplaycli/gplaycli.conf; this process however
is not documented (and don’t forget chown/chmod on the
configuration file to make it not world-readable either!).

Not that it helps making the program usable… (see the two
other bugreports.)

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Bug#949897: buster-pu: package golang-github-prometheus-common/0+git20181119.b36ad28-1+deb10u1

[Adrian Bunk]

Control: tags -1 - moreinfo

On Tue, Jan 28, 2020 at 10:34:00PM +, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Sun, 2020-01-26 at 21:57 +0200, Adrian Bunk wrote:
> >   * Backport upstream patch "config: extend validity of testdata
> > certs":
> > As the previous test certificates were set to expire on 2019-07-
> > 13,
> > causing TestNewClientFromConfig to fail after that date.
> > See https://github.com/prometheus/common/pull/186
> > (Closes: #949189)
> 
> I'm hoping that doesn't imply having to rebuild any of the (several) r-
> deps?

This is testdata for build-time tests of golang-github-prometheus-common,
not certs that are useful for anything (arguably they should be generated
at build time).

These testdata certs are also shipped in the -dev package.
I haven't seen any build failures due to them in other packages.
And at runtime they are not available since they are in a -dev package.

> Regards,
> 
> Adam

cu
Adrian

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer]

Hi,

Quoting Francesco Poli (2020-01-28 23:41:38)
>   + chroot ${HOME}/Downloads/mmdebstrap.pxni4vAjou update-initramfs -u
>   update-initramfs: Generating /boot/initrd.img-5.4.0-3-amd64
>   W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module 
> r8169
>   [...]
>   W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module 
> r8169
>   cp: failed to access './/mkinitramfs_v8SvPb/lib/systemd/network/': No such 
> file or directory
>   E: /usr/share/initramfs-tools/hooks/udev failed with return 1.
>   update-initramfs: failed for /boot/initrd.img-5.4.0-3-amd64 with 1.
>   E: run_chroot failed: E: command failed: sh -x 
> /usr/share/autopkgtest/setup-commands/setup-testbed "$1"
>   I: main() received signal PIPE: waiting for setup...
>   W: listening on child socket failed: E: received eof on socket
>   
>   I: removing tempdir ${HOME}/Downloads/mmdebstrap.pxni4vAjou...
> 
> 
> As you can see, a "cp" fails to access file 
> './/mkinitramfs_v8SvPb/lib/systemd/network/',
> and /usr/share/initramfs-tools/hooks/udev fails with exit status 1.
> But, honestly, I cannot understand why.
> 
> The lines that seem to fail are /usr/share/initramfs-tools/hooks/udev:
> 25 and the following ones... But why?

yes, that's where it seems to fail. To further investigate you can try the
following:

Copy /usr/share/autopkgtest/setup-commands/setup-testbed to a location that you
control so that you can edit it. Remove all the parts that are not necessary to
reproduce the problem. I suspect just keeping the line 'chroot "$root"
update-initramfs -u' is not sufficient and something else has to happen before
so that you can see the error? If that line alone is enough, then you should
also be able to reproduce the problem by running mmdebstrap with:

--customize-hook='chroot "$1" update-initramfs -u'

Once you are that far, you either already have found the problem or the next
thing you can try is to debug /usr/share/initramfs-tools/hooks/udev. To do
that, just insert a "set -x" somewhere at the top. For example by adding the
following before you call the failing hook:

--customize-hook='awk "NR==2{print 'set -x'}1" 
"$1/usr/share/initramfs-tools/hooks/udev"'

I would love to help more but I already tried out the failing command on three
different systems and I'm unable to reproduce it.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#950115: report debian/upstream/metadata without upstream Repository

[Jelmer Vernooij]

Package: lintian
Version: 2.47.0
Severity: wishlist

It would be great if lintian warned about debian/upstream/metadata files that
did not contain any upstream repository information (i.e. the 'Repository'
field is not present in debian/upstream/metadata).

This should probably be informational, since there are at least some upstreams
that do not use a VCS, and there is not much the Debian maintainer can do about 
that.

-- 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 depends on:
ii  binutils 2.33.90.20200122-2
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.19-1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b2
ii  libarchive-zip-perl  1.67-1
ii  libberkeleydb-perl   0.62-1+b1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.45-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3100-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.008001-2
ii  liburi-perl  1.76-1
ii  libxml-libxml-perl   2.0134+dfsg-1+b1
ii  libyaml-libyaml-perl 0.80+repack-2+b1
ii  man-db   2.9.0-2
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b4
ii  libtext-template-perl  1.58-1

-- no debconf information

Bug#950114: gplaycli: TypeError: search() got an unexpected keyword argument 'nb_result'

[Thorsten Glaser]

Package: gplaycli
Version: 3.26+dfsg-1
Severity: grave
Justification: renders package unusable

After generating an application password and putting it into
/etc/gplaycli/gplaycli.conf (see below) to work around #950112
things still don’t work:

$ gplaycli -s musescore
Traceback (most recent call last):
  File "/usr/bin/gplaycli", line 11, in 
load_entry_point('GPlayCli==3.26', 'console_scripts', 'gplaycli')()
  File "/usr/lib/python3/dist-packages/gplaycli/gplaycli.py", line 716, in main
cli.search(args.search_string, nb_results, not args.paid)
  File "/usr/lib/python3/dist-packages/gplaycli/hooks.py", line 9, in 
check_connection
return function(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/gplaycli/gplaycli.py", line 340, in 
search
results = self.api.search(search_string, nb_result=nb_results)
TypeError: search() got an unexpected keyword argument 'nb_result'


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

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

Versions of packages gplaycli depends on:
ii  python3   3.7.5-3
ii  python3-crypto2.6.1-13
ii  python3-gpapi 0.4.4-1
ii  python3-pyaxmlparser  0.3.24-1

Versions of packages gplaycli recommends:
pn  dummydroid
pn  fdroidserver  

gplaycli suggests no packages.

-- Configuration Files:
/etc/gplaycli/gplaycli.conf changed:
[Credentials]
gmail_address=XXX
gmail_password=XXX
token=False
token_url=https://matlink.fr/token/email/gsfid
[Cache]
token=~/.cache/gplaycli/token
[Locale]
locale=en_GB
timezone=CEST


-- no debconf information

Bug#950113: warn about debhelper-compat in Build-Depends-Indep

[Jelmer Vernooij]

Package: lintian
Version: 2.47.0
Severity: wishlist

It would be great if lintian could warn about debhelper-compat usage in
Build-Depends-Indep rather than Build-Depends.

-- 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 depends on:
ii  binutils 2.33.90.20200122-2
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.19-1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b2
ii  libarchive-zip-perl  1.67-1
ii  libberkeleydb-perl   0.62-1+b1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.45-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3100-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.008001-2
ii  liburi-perl  1.76-1
ii  libxml-libxml-perl   2.0134+dfsg-1+b1
ii  libyaml-libyaml-perl 0.80+repack-2+b1
ii  man-db   2.9.0-2
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b4
ii  libtext-template-perl  1.58-1

-- no debconf information

Bug#935970: stretch-pu: package node-fstream/1.0.10-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2019-09-01 at 22:42 +0200, Xavier wrote:
> Control: tags -1 - moreinfo
> 
> Le 01/09/2019 à 12:38, Adam D. Barratt a écrit :
> > node-fstream is vulnerable to Arbitrary File Overwrite (#931408,
> > CVE-2019-13173). This little patch fixes the problem.
> 
> Sorry, I forgot to push it. Done (see #939166)

Thanks. Please go ahead.

Regards,

Adam

Bug#939897: stretch-pu: package node-mixin-deep/1.1.3-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2019-09-09 at 22:22 +0200, Xavier Guimard wrote:
> since stretch and buster have the same node-mixin-deep, I added here
> the same security patches than pushed in buster.
> 

Please go ahead; sorry for the long delay.

Regards,

Adam

Bug#950110: liboctomap-dev,...: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Followup-For: Bug #950110
Control: affects -1 + libdynamicedt3d-dev

0m24.8s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/libdynamicedt3d-dev/changelog.Debian.gz 
(libdynamicedt3d-dev:amd64) != 
/usr/share/doc/libdynamicedt3d1.8/changelog.Debian.gz (libdynamicedt3d1.8)
/usr/share/doc/libdynamicedt3d-dev -> libdynamicedt3d1.8
  /usr/share/doc/libdynamicedt3d-dev/copyright (libdynamicedt3d-dev:amd64) != 
/usr/share/doc/libdynamicedt3d1.8/copyright (libdynamicedt3d1.8)
/usr/share/doc/libdynamicedt3d-dev -> libdynamicedt3d1.8
  /usr/share/doc/libdynamicedt3d-dev/examples (libdynamicedt3d-dev:amd64) != 
/usr/share/doc/libdynamicedt3d1.8/examples (?)
/usr/share/doc/libdynamicedt3d-dev -> libdynamicedt3d1.8
  /usr/share/doc/libdynamicedt3d-dev/examples/CMakeLists.txt 
(libdynamicedt3d-dev:amd64) != 
/usr/share/doc/libdynamicedt3d1.8/examples/CMakeLists.txt (?)
/usr/share/doc/libdynamicedt3d-dev -> libdynamicedt3d1.8
  /usr/share/doc/libdynamicedt3d-dev/examples/exampleEDT3D.cpp 
(libdynamicedt3d-dev:amd64) != 
/usr/share/doc/libdynamicedt3d1.8/examples/exampleEDT3D.cpp (?)
/usr/share/doc/libdynamicedt3d-dev -> libdynamicedt3d1.8
  /usr/share/doc/libdynamicedt3d-dev/examples/exampleEDTOctomap.cpp 
(libdynamicedt3d-dev:amd64) != 
/usr/share/doc/libdynamicedt3d1.8/examples/exampleEDTOctomap.cpp (?)
/usr/share/doc/libdynamicedt3d-dev -> libdynamicedt3d1.8
  /usr/share/doc/libdynamicedt3d-dev/examples/exampleEDTOctomapStamped.cpp 
(libdynamicedt3d-dev:amd64) != 
/usr/share/doc/libdynamicedt3d1.8/examples/exampleEDTOctomapStamped.cpp (?)
/usr/share/doc/libdynamicedt3d-dev -> libdynamicedt3d1.8


Andreas

Bug#945821: stretch-pu: package libofx/1:0.9.10-2+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2019-11-29 at 09:54 +0100, Dylan Aïssi wrote:
> Upstream has fixed CVE-2019-9656, this CVE is non-dsa. The patch is
> already applied in jessie/buster/testing/unstable (#924350) and now I
> would like to fix the Stretch version. Please find attached a
> debdiff.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#950112: gplaycli: 502 Bad Gateway, does not work at all

[Thorsten Glaser]

Package: gplaycli
Version: 3.26+dfsg-1
Severity: grave
Justification: renders package unusable

After installation, gplaycli --help works (but please do add
a manual page), but nothing else:

$ gplaycli -s musescore
cache file does not exists or is corrupted
Unknown error: 
502 Bad Gateway

502 Bad Gateway
nginx/1.14.2


$ gplaycli -pvd com.musescore.playerlite
[INFO] GPlayCli version 3.26 [Python3.7.6] 
[INFO] Configuration file is /etc/gplaycli/gplaycli.conf
[INFO] Device is bacon
[ERROR] cache file does not exists or is corrupted
[INFO] Retrieving token ...
[INFO] Token URL is https://matlink.fr/token/email/gsfid/bacon
[ERROR] Unknown error: 
502 Bad Gateway

502 Bad Gateway
nginx/1.14.2




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

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

Versions of packages gplaycli depends on:
ii  python3   3.7.5-3
ii  python3-crypto2.6.1-13
ii  python3-gpapi 0.4.4-1
ii  python3-pyaxmlparser  0.3.24-1

Versions of packages gplaycli recommends:
pn  dummydroid
pn  fdroidserver  

gplaycli suggests no packages.

-- no debconf information

Bug#943889: buster-pu: package hbci4java/3.0.22+dfsg-1 hibiscus/2.8.18+dfsg-2

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2019-10-31 at 14:00 +0100, Jochen Sprickerhof wrote:
> I would like to integrate new upstream versions of hbci4java and
> hibiscus into Debian 10 (buster). Hibiscus is a electronic banking
> software and hbci4java the underlying library. The update is
> necessary because of the new EU directive on payment services (PSD2)
> [1], leading to changes in the interfaces of most European banks and
> thus breaking Hibiscus for most users.
> 
> Due to the new upstream versions, the diff is quiet big (~1MB) so I
> only include links to the diff [2, 3] here. I can send the full diff
> as well, if you prefer.

They are quite large, particularly the hbci4java diff. :-( I guess it's
unlikely that such a large change would be needed again during buster's
lifetime?

Regards,

Adam

Bug#950111: libvigraimpex-doc: unhandled symlink to directory conversion: /usr/share/doc/libvigraimpex-dev/html

[Andreas Beckmann]

Package: libvigraimpex-doc
Version: 1.11.1+dfsg-6
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  buster -> bullseye

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


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

0m58.6s ERROR: installs objects over existing directory symlinks:
  /usr/share/doc/libvigraimpex-dev/html/AlgebraicConcepts.html 
(libvigraimpex-doc) != 
/usr/share/doc/libvigraimpex-doc/html/AlgebraicConcepts.html (?)
/usr/share/doc/libvigraimpex-dev/html -> ../libvigraimpex-doc/html
  /usr/share/doc/libvigraimpex-dev/html/ArgumentObjectFactories.html 
(libvigraimpex-doc) != 
/usr/share/doc/libvigraimpex-doc/html/ArgumentObjectFactories.html (?)
/usr/share/doc/libvigraimpex-dev/html -> ../libvigraimpex-doc/html
  /usr/share/doc/libvigraimpex-dev/html/BorderTreatmentMode.html 
(libvigraimpex-doc) != 
/usr/share/doc/libvigraimpex-doc/html/BorderTreatmentMode.html (?)
/usr/share/doc/libvigraimpex-dev/html -> ../libvigraimpex-doc/html
  /usr/share/doc/libvigraimpex-dev/html/CrackEdgeImage.html (libvigraimpex-doc) 
!= /usr/share/doc/libvigraimpex-doc/html/CrackEdgeImage.html (?)
/usr/share/doc/libvigraimpex-dev/html -> ../libvigraimpex-doc/html
  /usr/share/doc/libvigraimpex-dev/html/CreditsChangelog.html 
(libvigraimpex-doc) != 
/usr/share/doc/libvigraimpex-doc/html/CreditsChangelog.html (?)
/usr/share/doc/libvigraimpex-dev/html -> ../libvigraimpex-doc/html
...


cheers,

Andreas


libvigraimpex-doc_1.11.1+dfsg-6.log.gz
Description: application/gzip

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Francesco Poli]

On Mon, 27 Jan 2020 23:44:55 +0100 Johannes Schauer wrote:

[...]
> this looks as if the error comes from
> /usr/share/autopkgtest/setup-commands/setup-testbed. To figure out what goes
> wrong, maybe try running setup-testbed with sh -x like so:
> 
> --customize-hook='sh -x /usr/share/autopkgtest/setup-commands/setup-testbed 
> "$1"'
> 
> Your command works fine on my system, so this must be something specific to
> your setup.
> 
> Thanks!

Thanks to you for your super-prompt reply!   :-)

  $ cd Downloads/
  $ TMPDIR='./'
  $ export TMPDIR
  $ mmdebstrap --variant=important --include=linux-image-amd64 \
  >   --customize-hook='chroot "$1" passwd --delete root' \
  >   --customize-hook='chroot "$1" useradd --home-dir /home/user --create-home 
user' \
  >   --customize-hook='chroot "$1" passwd --delete user' \
  >   --customize-hook='echo host > "$1/etc/hostname"' \
  >   --customize-hook='echo "127.0.0.1 localhost host" > "$1/etc/hosts"' \
  >   --customize-hook='sh -x 
/usr/share/autopkgtest/setup-commands/setup-testbed "$1"' \
  > "sid" debian-unstable.tar
  I: automatically chosen mode: fakechroot
  [...]
  I: running --customize-hook in shell: sh -c 'sh -x 
/usr/share/autopkgtest/setup-commands/setup-testbed "$1"' exec 
${HOME}/Downloads/mmdebstrap.pxni4vAjou
  + set -eu
  + umask 0022
  + export DEBIAN_FRONTEND=noninteractive
  + [ ${HOME}/Downloads/mmdebstrap.pxni4vAjou = --help ]
  + root=${HOME}/Downloads/mmdebstrap.pxni4vAjou
  + [ ${HOME}/Downloads/mmdebstrap.pxni4vAjou != / ]
  + cat
  + chmod 755 ${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/init.d/autopkgtest
  + chroot ${HOME}/Downloads/mmdebstrap.pxni4vAjou update-rc.d autopkgtest 
defaults
  + [ -d ${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/systemd/system ]
  + cat
  + mkdir -p 
${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/systemd/system/multi-user.target.wants
  + ln -sf ../autopkgtest.service 
${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/systemd/system/multi-user.target.wants/autopkgtest.service
  + [ -e ${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/init/tty2.conf -a ! -e 
${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/init/ttyS0.conf ]
  + chroot ${HOME}/Downloads/mmdebstrap.pxni4vAjou dpkg --print-architecture
  + ARCH=amd64
  + [ ! -e 
${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/default/grub.d/90-autopkgtest.cfg ]
  + chroot ${HOME}/Downloads/mmdebstrap.pxni4vAjou which update-grub
  + [ -e ${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/os-release ]
  + . ${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/os-release
  + PRETTY_NAME=Debian GNU/Linux bullseye/sid
  + NAME=Debian GNU/Linux
  + ID=debian
  + HOME_URL=https://www.debian.org/
  + SUPPORT_URL=https://www.debian.org/support
  + BUG_REPORT_URL=https://bugs.debian.org/
  + echo debian
  + DISTRO_ID=debian
  + [ -z  ]
  + awk /^deb .*debian/ { sub(/\[.*\]/, "", $0); print $2; exit } 
${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/apt/sources.list
  + MIRROR=http://deb.debian.org/debian
  + [ -z  ]
  + awk /^deb .*debian/ { sub(/\[.*\]/, "", $0); print $3; exit } 
${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/apt/sources.list
  + RELEASE=sid
  + [ -n  ]
  + [ -n  ]
  + [ -n  ]
  + echo /usr/share/autopkgtest/setup-commands/setup-testbed: Attempting to set 
up Debian/Ubuntu apt sources automatically
  /usr/share/autopkgtest/setup-commands/setup-testbed: Attempting to set up 
Debian/Ubuntu apt sources automatically
  + [ -z sid ]
  + [ -z http://deb.debian.org/debian ]
  + [ http://deb.debian.org/debian != http://deb.debian.org/debian ]
  + echo /usr/share/autopkgtest/setup-commands/setup-testbed: Distribution 
assumed to resemble Debian
  /usr/share/autopkgtest/setup-commands/setup-testbed: Distribution assumed to 
resemble Debian
  + cat
  + [ -e ${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/cloud/cloud.cfg ]
  + [ -z  ]
  + ls ${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/systemd/network/*.network
  + ls ${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/netplan/*.yaml
  + grep -q source.*interfaces.d 
${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/network/interfaces
  + IFACE=
  + [ ${HOME}/Downloads/mmdebstrap.pxni4vAjou = / ]
  + IFACE=eth0
  + [ -e 
${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/udev/rules.d/80-net-setup-link.rules
 ]
  + ln -s /dev/null 
${HOME}/Downloads/mmdebstrap.pxni4vAjou/etc/udev/rules.d/80-net-setup-link.rules
  + chroot ${HOME}/Downloads/mmdebstrap.pxni4vAjou update-initramfs -u
  update-initramfs: Generating /boot/initrd.img-5.4.0-3-amd64
  W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module 
r8169
  [...]
  W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module 
r8169
  cp: failed to access './/mkinitramfs_v8SvPb/lib/systemd/network/': No such 
file or directory
  E: /usr/share/initramfs-tools/hooks/udev failed with return 1.
  update-initramfs: failed for /boot/initrd.img-5.4.0-3-amd64 with 1.
  E: run_chroot failed: E: command failed: sh -x 
/usr/share/autopkgtest/setup-commands/setup-testbed "$1"
  I: main() received signal PIPE: waiting fo

Bug#945578: buster-pu: package libapache2-mod-auth-openidc/2.3.10.2-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-11-27 at 11:18 +0100, Moritz Schlarb wrote:
> Fixes CVE-2019-14857 (Open redirect in logout url when using URLs
> with backslashes) by improving validation of the post-logout URL
> parameter (backported from upstream, see 
> https://salsa.debian.org/debian/libapache2-mod-
> auth-openidc/commit/17e31b94a71ef02d1417bee6b0ef7b7379b40375)
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#950110: liboctomap-dev,...: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: liboctomap-dev,liboctovis-dev,octomap-tools,octovis
Version: 1.9.3+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  buster -> bullseye

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


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

0m51.2s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/liboctomap-dev/changelog.Debian.gz (liboctomap-dev:amd64) != 
/usr/share/doc/liboctomap1.8/changelog.Debian.gz (liboctomap1.8)
/usr/share/doc/liboctomap-dev -> liboctomap1.8
  /usr/share/doc/liboctomap-dev/copyright (liboctomap-dev:amd64) != 
/usr/share/doc/liboctomap1.8/copyright (liboctomap1.8)
/usr/share/doc/liboctomap-dev -> liboctomap1.8
  /usr/share/doc/liboctomap-dev/examples (liboctomap-dev:amd64) != 
/usr/share/doc/liboctomap1.8/examples (?)
/usr/share/doc/liboctomap-dev -> liboctomap1.8
  /usr/share/doc/liboctomap-dev/examples/data (liboctomap-dev:amd64) != 
/usr/share/doc/liboctomap1.8/examples/data (?)
/usr/share/doc/liboctomap-dev -> liboctomap1.8
  /usr/share/doc/liboctomap-dev/examples/data/geb079.bt (liboctomap-dev:amd64) 
!= /usr/share/doc/liboctomap1.8/examples/data/geb079.bt (?)
/usr/share/doc/liboctomap-dev -> liboctomap1.8
  /usr/share/doc/liboctomap-dev/examples/data/mapcoll.txt 
(liboctomap-dev:amd64) != 
/usr/share/doc/liboctomap1.8/examples/data/mapcoll.txt (?)
/usr/share/doc/liboctomap-dev -> liboctomap1.8
  /usr/share/doc/liboctomap-dev/examples/data/scan.dat.bz2 
(liboctomap-dev:amd64) != 
/usr/share/doc/liboctomap1.8/examples/data/scan.dat.bz2 (?)
/usr/share/doc/liboctomap-dev -> liboctomap1.8
  /usr/share/doc/liboctomap-dev/examples/data/spherical_scan.graph 
(liboctomap-dev:amd64) != 
/usr/share/doc/liboctomap1.8/examples/data/spherical_scan.graph (?)
/usr/share/doc/liboctomap-dev -> liboctomap1.8
  /usr/share/doc/liboctomap-dev/examples/example-project.tgz 
(liboctomap-dev:amd64) != 
/usr/share/doc/liboctomap1.8/examples/example-project.tgz (?)
/usr/share/doc/liboctomap-dev -> liboctomap1.8

1m12.1s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/liboctovis-dev/changelog.Debian.gz (liboctovis-dev:amd64) != 
/usr/share/doc/liboctomap1.8/changelog.Debian.gz (liboctomap1.8)
/usr/share/doc/liboctovis-dev -> liboctomap1.8
  /usr/share/doc/liboctovis-dev/copyright (liboctovis-dev:amd64) != 
/usr/share/doc/liboctomap1.8/copyright (liboctomap1.8)
/usr/share/doc/liboctovis-dev -> liboctomap1.8

0m25.1s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/octomap-tools/changelog.Debian.gz (octomap-tools) != 
/usr/share/doc/liboctomap1.8/changelog.Debian.gz (liboctomap1.8)
/usr/share/doc/octomap-tools -> liboctomap1.8
  /usr/share/doc/octomap-tools/copyright (octomap-tools) != 
/usr/share/doc/liboctomap1.8/copyright (liboctomap1.8)
/usr/share/doc/octomap-tools -> liboctomap1.8

2m14.0s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/octovis/changelog.Debian.gz (octovis) != 
/usr/share/doc/liboctomap1.8/changelog.Debian.gz (liboctomap1.8)
/usr/share/doc/octovis -> liboctomap1.8
  /usr/share/doc/octovis/copyright (octovis) != 
/usr/share/doc/liboctomap1.8/copyright (liboctomap1.8)
/usr/share/doc/octovis -> liboctomap1.8



cheers,

Andreas


liboctomap-dev_1.9.3+dfsg-1.log.gz
Description: application/gzip

Bug#623131: Message about Adobe Acrobat

[Stephane Ascoet]

Hi, this message is inside the PDF. What's missing in Xpdf is the ability to 
read PDF document with writeable fields. It blocks me for administrative forms 
too. And since the maintened Xpdf version is now the "4" branch, needing QT 
library(ies), I wonder what will happen in the future.


--
Sincerely, Stephane Ascoet

Bug#950109: ITP: chez-srfi -- SRFI libraries for Chez Scheme

[Göran Weinholt]

Package: wnpp
Severity: wishlist
Owner: Göran Weinholt 

* Package name: chez-srfi
  Version : git checkout
  Upstream Author : Aaron W. Hsu
* URL : https://github.com/arcfide/chez-srfi/
* License : mainly MIT/X and BSD
  Programming Lang: Scheme
  Description : SRFI libraries for Chez Scheme

 SRFI stands for Scheme Requests For Implementation. It is a
 standardization process for extensions to the programming language
 Scheme. Since its start in 1998, the project has been working for
 portability between Scheme implementations.
 .
 This package provides SRFI implementations primarily developed for
 Chez Scheme. Most of the libraries are however fully portable to
 other R6RS implementations.

Almost all Scheme compilers come with a few SRFIs, but Chez Scheme
does not come with any. Yet most Scheme code, including my own,
depends on some SRFIs.

I'm working with upstream to resolve some license issues.

I will maintain this package myself, but would like to see some
coordinated maintenance of Scheme in Debian.

Bug#949921: buster-pu: package uim_1.8.8-4+deb10u3

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2020-01-28 at 13:03 +0900, Takatsugu Nokubi wrote:
> +  [ NOKUBI Takatsugu ]
> +  * d/libuim-data.postint: add uim-mozc (See #939588)
> +
> +  [ HIGUCHI Daisuke (VDR dai) ]
> +  * d/libuim-data.postint: add uim-chewing
> +
> +  [ YOSHINO Yoshihito ]
> +  * d/libuim-data.postinst: unregister not-installed modules
> (Closes: #945344).
> +The previous upload to fix #939588 caused regression, which has
> +accidentally registered some not-installed modules.

Are all of these changes already applied to the package in unstable?

Regards,

Adam

Bug#949897: buster-pu: package golang-github-prometheus-common/0+git20181119.b36ad28-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2020-01-26 at 21:57 +0200, Adrian Bunk wrote:
>   * Backport upstream patch "config: extend validity of testdata
> certs":
> As the previous test certificates were set to expire on 2019-07-
> 13,
> causing TestNewClientFromConfig to fail after that date.
> See https://github.com/prometheus/common/pull/186
> (Closes: #949189)

I'm hoping that doesn't imply having to rebuild any of the (several) r-
deps?

Regards,

Adam

Bug#950018: buster-pu: package php-horde-text-filter/2.3.5-3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-01-28 at 12:21 +0100, IOhannes m zmoelnig wrote:
> The 'php-horde-text-filter' contains a few regular expressions that
> are incompatible with the libpcre2 as shipped in Debian/buster.

That's quite a long way of saying "wrong". :-) I wouldn't have expected
them to have ever worked.

I'm not convinced it's worth the orphaning change in stable, as it's
expected that maintainer information will become outdated after
release, but either way please go ahead.

Regards,

Adam

Bug#950108: r-cran-dt: unhandled symlink to directory conversion: /usr/lib/R/site-library/DT/htmlwidgets/lib/datatables{,-extensions}

[Andreas Beckmann]

Package: r-cran-dt
Version: 0.11+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  buster -> bullseye

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


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

2m27.3s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/AutoFill 
(r-cran-dt) != /usr/share/javascript/jquery-datatables-extensions/AutoFill 
(libjs-jquery-datatables-extensions)
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions -> 
../../../../../../share/javascript/jquery-datatables-extensions
  /usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/Buttons 
(r-cran-dt) != /usr/share/javascript/jquery-datatables-extensions/Buttons 
(libjs-jquery-datatables-extensions)
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions -> 
../../../../../../share/javascript/jquery-datatables-extensions
  /usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/Buttons/css 
(r-cran-dt) != /usr/share/javascript/jquery-datatables-extensions/Buttons/css 
(libjs-jquery-datatables-extensions)
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions -> 
../../../../../../share/javascript/jquery-datatables-extensions
  /usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/Buttons/js 
(r-cran-dt) != /usr/share/javascript/jquery-datatables-extensions/Buttons/js 
(libjs-jquery-datatables-extensions)
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions -> 
../../../../../../share/javascript/jquery-datatables-extensions
  
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/Buttons/js/buttons.bootstrap.js
 (r-cran-dt) != 
/usr/share/javascript/jquery-datatables-extensions/Buttons/js/buttons.bootstrap.js
 (libjs-jquery-datatables-extensions)
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions -> 
../../../../../../share/javascript/jquery-datatables-extensions
  
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/Buttons/js/buttons.bootstrap.min.js
 (r-cran-dt) != 
/usr/share/javascript/jquery-datatables-extensions/Buttons/js/buttons.bootstrap.min.js
 (libjs-jquery-datatables-extensions)
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions -> 
../../../../../../share/javascript/jquery-datatables-extensions
  
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/Buttons/js/buttons.colVis.js
 (r-cran-dt) != 
/usr/share/javascript/jquery-datatables-extensions/Buttons/js/buttons.colVis.js 
(libjs-jquery-datatables-extensions)
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions -> 
../../../../../../share/javascript/jquery-datatables-extensions
  
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/Buttons/js/buttons.colVis.min.js
 (r-cran-dt) != 
/usr/share/javascript/jquery-datatables-extensions/Buttons/js/buttons.colVis.min.js
 (libjs-jquery-datatables-extensions)
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions -> 
../../../../../../share/javascript/jquery-datatables-extensions
  
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/Buttons/js/buttons.foundation.js
 (r-cran-dt) != 
/usr/share/javascript/jquery-datatables-extensions/Buttons/js/buttons.foundation.js
 (libjs-jquery-datatables-extensions)
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions -> 
../../../../../../share/javascript/jquery-datatables-extensions
  
/usr/lib/R/site-library/DT/htmlwidgets/lib/datatables-extensions/Buttons/js/buttons.foundation.min

Bug#948786: buster-pu: package apt-cacher-ng/3.2.1-1 pre-approval

[Adam D. Barratt]

On Wed, 2020-01-22 at 22:16 +0100, Eduard Bloch wrote:
> I would like to have some kind of confirmation from the release team
> that this mail does not go straight to /dev/null and that a new
> upstream (minor) version is an acceptable candidate for a Stable
> update.

No mail is ignored, and I don't appreciate the implication.

As you may have noticed, manpower for processing stable updates is
somewhat thin on the ground these days, and there's only so many
requests I can get through in any given time, particularly while trying
to fit in other Debian, dayjob and other activities.

To be entirely honest, it's also not the most fun thing to spend an
evening doing.

> I can, of course, convert all that into debian/patches/XXX but
> honestly, that would really feel like greenwashing.
> 
> The changes reported here can be reviewed at
> https://salsa.debian.org/blade/apt-cacher-ng/commits/temp/debian-merge ,
> starting with the commit from 2019-12-20.

Those look OK as individual commits, thanks. For completeness, could we
please have a finalised source debdiff of the built source package,
compared to current stable?

Regards,

Adam

Bug#950107: ruby-kramdown no longer ships its gemspec file (makes other packages FTBFS)

[Daniel Leidert]

Package: ruby-kramdown
Version: 1.17.0-3
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The package no longer ships the kramdown-1.17.0.gemspec file. Thus packages
using e.g. gem2deb-test-runner --check-dependencies will fail here. For example
jekyll's dependencies cannot longer be fulfilled, because the gem cannot be
found:

https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-jekyll-redirect-from/4086760/log.gz

This is very probably related to the recent split of ruby-kramdown.

Regards, Daniel


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

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

Versions of packages ruby-kramdown depends on:
ii  libjs-jquery  3.3.1~dfsg-3
ii  ruby-coderay  1.1.2-2
ii  ruby-prawn2.2.0+dfsg-1
ii  ruby-prawn-table  0.2.2-1
ii  ruby-rouge3.15.0-1
ii  ruby-stringex 2.8.4-1

ruby-kramdown recommends no packages.

Versions of packages ruby-kramdown suggests:
pn  libjs-mathjax  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl4wtMsACgkQS80FZ8KW
0F3X6g//Y+W4Ivmn076MJDLjVyJBSRAvz9NRjBzzlmb1TOToHX//IO9RGQa32sjG
4o0wVXU9gMppPZsTXy/XedjQLJ5yJ7XSOovQYWF7aGvayywRz5W5HAqGxxUQ1lNL
LM95fzse9qICPjRqQggLIl5puzRvkTaxh5RW8iKz59NF+BnSRMlG32Yvb0VPDvAA
4lP/SD03Jf0MPBduN00urhP5GZRQeIQHdz4hR8JE29WzWJK/9Op3GsDh4K94Z9F8
ULld1NQLBLXmixnH5dQ2C8m5J9ZhesctWIdYTuN1Mgq+UdXRn0oSsSE1YHrNGRmv
Pd6/wCl6ogIE3V4ZowHYXt2qo+tqStLQDu9BjnyHmT+z+0iKyeGSat1pfZZ2Dl/2
68j6giCDq4CcrmBAHHQdiJrnWsdb8W2m8p1wVZWYIvvEaK+oRJHP4xpTEr9vSdyX
9o39KB+fXUUk+yczNxxw64yFXGXY7mBG30VEOLDLhF56Pq6i21OdkxRNvhz0OFXO
k67GF77Qt0F7dtjujVaRtaFf2ZQbY8aUDQKppBGvg4ww6sbAdJYvtfCRDPn9mxHh
Fbuh3aebym4nZ0dTaKgO4V5kh2S8ABc/aIn0/bbtprYPcyWRBSRJHKYw+xwIYwQR
qqQjlDDVEqXHfeylO4xOK1Qatt5ofVEZ9Dj2Q/r7Vh4iPoA5+J8=
=P3st
-END PGP SIGNATURE-

Bug#950106: tdiary-mode: fails to upgrade from 'buster': >>Error occurred processing http.el: File is missing (("Opening input file" "No such file or directory" "/usr/share/emacs/site-lisp/elpa/tdiary

[Andreas Beckmann]

Package: tdiary-mode
Version: 5.1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails.

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

  Setting up tdiary-mode (5.1.0-1) ...
  Install emacsen-common for emacs
  emacsen-common: Handling install of emacsen flavor emacs
  Install tdiary-mode for emacs
  install/tdiary-mode-20170123.2324: Handling install of emacsen flavor emacs
  install/tdiary-mode-20170123.2324: byte-compiling for emacs
  >>Error occurred processing http.el: File is missing (("Opening input file" 
"No such file or directory" 
"/usr/share/emacs/site-lisp/elpa/tdiary-mode-20170123.2324/http.el"))
  
  In tdiary-new-or-replace:
  tdiary-mode.el:614:12:Warning: Use `with-current-buffer' rather than
  save-excursion+set-buffer
  ERROR: install script from tdiary-mode package failed
  dpkg: error processing package tdiary-mode (--configure):
   installed tdiary-mode package post-installation script subprocess returned 
error exit status 1


cheers,

Andreas


tdiary-mode_5.1.0-1.log.gz
Description: application/gzip

Bug#949959: debcargo.toml should make it possible to declare additional dependencies for generated autopkgtests

[Daniel Kahn Gillmor]

On Tue 2020-01-28 16:58:52 -0500, Daniel Kahn Gillmor wrote:
> Control: tag 949959 + patch
>
> On Mon 2020-01-27 11:55:28 -0500, Daniel Kahn Gillmor wrote:
>> So it would be good to be able to indicate in debcargo.toml some
>> additional autopkgtest dependencies.
>>
>> Simplest might be to add a dependency for *all* generated autopkgtests,
>> but i can imagine there are some subtler requirements which will need to
>> be for specific autopkgtests in the future.
>
> Wolfgang created this patch (on the dev/debian_949959 branch in salsa)
> to implement this mechanism.
>
> It looks reasonable to me, and it compiles fine.  I'm in the process of
> testing it now.

I've just uploaded rust-clang-sys 0.28.1-5, built with a version of
debcargo that is 2.4.2 plus Wolfgang's patch in debian/patches/

We'll see how it fares on ci.debian.net.

  --dkg


signature.asc
Description: PGP signature

Bug#851747: sysvinit-utils: drop Essential flag

[Michael Biebl]

Am 28.01.2020 um 17:38 schrieb Andreas Henriksson:
> On Tue, Jan 28, 2020 at 05:02:38PM +0100, Michael Biebl wrote:
> [...]
>> Assuming the .service isn't just a wrapper around the init script.
>> Unfortunately, we do have quite a few packages which use this
>> anti-pattern :-/
>>
>> https://codesearch.debian.net/search?q=ExecStart%3D%2Fetc%2Finit.d%2F&literal=1&perpkg=1
> 
> https://lintian.debian.org/tags/systemd-service-file-wraps-init-script.html

Thanks for that pointer. Totally forgot that we had a lintian check for
that.

> It seems "Debian OpenStack" is the main offender so unless people use
> openstack the problem possibly isn't that widely spread.

Indeed.

> This however serves as a good reminder that it's not enough to just
> check that there's a masking native systemd unit.
> (I'll probably forget about that very soon again, but atleast there's
> now a note/warning about this case in this bugs history! :)
> 
> (It might be time to ask lintian maintainers to consider raising
> severity or turning some warnings into errors for systemd-related
> lintian checks.)

Sounds like a good idea.

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



signature.asc
Description: OpenPGP digital signature

Bug#949890: buster-pu: packages tbsync, dav4tbsync and eas4tbsync

[Adam D. Barratt]

Control: tags -1 + moreinfo
Control: clone -1 -2 -3
Control: retitle -1 buster-pu: tbsync
Control: retitle -2 buster-pu: dav4tbsync
Control: retitle -3 buster-pu: eas4tbsync

On Sun, 2020-01-26 at 19:45 +0100, Mechtilde Stehmann wrote:
> I want to upload tbsync, dav4tbsync and eas4tbsync to be compatible
> with thunderbird 68.x in stable

In that case, there should be three separate p-u bugs. There are a
variety of reasons why we might end up releasing some combination (but
not all) of the packages in a given point release and we need to be
able to track the status of each individually.

> These packages are needed to be able to connect to a Calendar at an
> Exchange Server. The older ersion s - now released in buster - don't
> work proper.

Depending on the size, could we have - to the relevant of the cloned
bug set - source debdiffs, or at least binary debdiffs between the
current stable packages and the proposed uploads?

Regards,

Adam

Bug#948855: buster-pu: package iputils/3:20180629-2

[Adam D. Barratt]

Control: tags -1 +moreinfo

On Mon, 2020-01-27 at 18:15 -0500, Noah Meyerhans wrote:
> Control: tags -1 - moreinfo
> 
> On Fri, Jan 24, 2020 at 10:11:38PM +, Adam D. Barratt wrote:
> > > I'd like to fix 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947921 in
> > > buster.  Ping has some issues coping with explicitly specified
> > > source interfaces when pinging DNS names and DNS returns multiple
> > > addresses via getaddrinfo().  Please see the commit messages and
> > > the bug report for in-depth explanation of what's going on.
> > 
> > The metadata for that bug report suggests that it affects the
> > iputils package in unstable, and is not currently fixed there. Is
> > that correct?
> 
> That's correct.  Upstream has not yet made a release containing the
> fix, nor have I backported it to the version currently in testing
> (there are enough changes to make that nontrivial).  I am making my
> request based on the patch author's report that it does, indeed, fix
> the problem in buster, and the fact that the fix has been accepted
> upstream.
> 
> If you'd prefer, we can wait until the next buster point release, by
> which time we'll presumably have more testing of these patches.

In general our workflow is for patches to be applied to unstable first
where appropriate, so that sounds like the best approach; thanks for
confirming.

In the meantime, I'm going to re-add the "moreinfo" tag, as it's the
best signal we currently have for "not ready to be processed by SRM".
Please feel free to remove it once the issues are resolved in unsable.

Regards,

Adam

Bug#950103: fonts-lemonada FTBFS: KeyError: "glyph 'M' already exists"

[Adrian Bunk]

Source: fonts-lemonada
Version: 4.004+git20190612-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fonts-lemonada.html

...
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/1st/fonts-lemonada-4.004+git20190612'
fontmake -i -o otf -g sources/*.glyphs
INFO:fontmake.font_project:Building master UFOs and designspace from Glyphs 
source
INFO:glyphsLib.classes:Parsing "sources/Lemonada.glyphs" file into 
Traceback (most recent call last):
  File "/usr/bin/fontmake", line 11, in 
load_entry_point('fontmake==2.0.7', 'console_scripts', 'fontmake')()
  File "/usr/lib/python3/dist-packages/fontmake/__main__.py", line 425, in main
project.run_from_glyphs(glyphs_path, **args)
  File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line 670, in 
run_from_glyphs
write_skipexportglyphs=write_skipexportglyphs,
  File "/usr/lib/python3/dist-packages/fontTools/misc/loggingTools.py", line 
367, in wrapper
return func(*args, **kwds)
  File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line 156, in 
build_master_ufos
ufo_module=ufoLib2,
  File "/usr/lib/python3/dist-packages/glyphsLib/builder/__init__.py", line 
111, in to_designspace
return builder.designspace
  File "/usr/lib/python3/dist-packages/glyphsLib/builder/builders.py", line 
260, in designspace
list(self.masters)  # Make sure that the UFOs are built
  File "/usr/lib/python3/dist-packages/glyphsLib/builder/builders.py", line 
222, in masters
ufo_glyph = ufo_layer.newGlyph(glyph.name)
  File "/usr/lib/python3/dist-packages/ufoLib2/objects/layer.py", line 120, in 
newGlyph
raise KeyError("glyph %r already exists" % name)
KeyError: "glyph 'M' already exists"
make[1]: *** [debian/rules:12: override_dh_auto_build] Error 1

Bug#950100: fonts-oldstandard FTBFS with fontforge using Python 3

[Adrian Bunk]

Source: fonts-oldstandard
Version: 2.2really-3
Severity: serious
Tags: ftbfs bullseye sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fonts-oldstandard.html

...
fontforge -script ost-generate.py
Copyright (c) 2000-2019. See AUTHORS for Contributors.
 License GPLv3+: GNU GPL version 3 or later 
 with many parts BSD . Please read LICENSE.
 Version: 20190801
 Based on sources from 12:20 UTC 13-Nov-2019-ML-D-GDK3.
Cannot find your hotkey definition file!
  File "ost-generate.py", line 37
if ttname[1] == 'SubFamily':
   ^
TabError: inconsistent use of tabs and spaces in indentation
make[1]: *** [debian/rules:11: override_dh_install] Error 1

Bug#950101: python-xarray-doc: FTBFS with new ipython

[Rebecca N. Palmer]

Package: python-xarray-doc
Version: 0.14.1-2
Severity: serious
Control: tags -1 patch

ipython_directive examples are executed at build time.  xarray has some 
examples that fail without optional dependencies Debian doesn't have 
(e.g. h5netcdf) and/or downloaded data.  This used to put the error 
message in the documentation (non-ideal but I prefer it to no 
documentation), but in ipython_directive 7, it defaults to failing the 
whole documentation build.


Fix: this can be turned off by adding

ipython_warning_is_error = False

anywhere in the top level of doc/conf.py.

Bug#950102: DDPO: please remove the icons from the Source Package column again (or as QUERY_STRING option)

[Thorsten Glaser]

Package: qa.debian.org

I’ve barely managed to get the DDPO to fit on my 1024x768 laptop screen
by zooming out, and now there are suddenly icons which make it wider again.
Please allow me to get rid of them.

Similarily, dropping the icon from the Bugs column would be a welcome feature.

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

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

Bug#950099: fonts-inter FTBFS: KeyError: "glyph 'asterisk' already exists"

[Adrian Bunk]

Source: fonts-inter
Version: 3.11-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fonts-inter.html

...
  debian/rules override_dh_auto_build
make[1]: Entering directory '/build/1st/fonts-inter-3.11'
fontmake -i -o otf -g src/Inter.glyphs
INFO:fontmake.font_project:Building master UFOs and designspace from Glyphs 
source
INFO:glyphsLib.classes:Parsing "src/Inter.glyphs" file into 
Traceback (most recent call last):
  File "/usr/bin/fontmake", line 11, in 
load_entry_point('fontmake==2.0.7', 'console_scripts', 'fontmake')()
  File "/usr/lib/python3/dist-packages/fontmake/__main__.py", line 425, in main
project.run_from_glyphs(glyphs_path, **args)
  File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line 670, in 
run_from_glyphs
write_skipexportglyphs=write_skipexportglyphs,
  File "/usr/lib/python3/dist-packages/fontTools/misc/loggingTools.py", line 
367, in wrapper
return func(*args, **kwds)
  File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line 156, in 
build_master_ufos
ufo_module=ufoLib2,
  File "/usr/lib/python3/dist-packages/glyphsLib/builder/__init__.py", line 
111, in to_designspace
return builder.designspace
  File "/usr/lib/python3/dist-packages/glyphsLib/builder/builders.py", line 
260, in designspace
list(self.masters)  # Make sure that the UFOs are built
  File "/usr/lib/python3/dist-packages/glyphsLib/builder/builders.py", line 
222, in masters
ufo_glyph = ufo_layer.newGlyph(glyph.name)
  File "/usr/lib/python3/dist-packages/ufoLib2/objects/layer.py", line 120, in 
newGlyph
raise KeyError("glyph %r already exists" % name)
KeyError: "glyph 'asterisk' already exists"
make[1]: *** [debian/rules:14: override_dh_auto_build] Error 1

Bug#950098: patsy: exceptions in documentation, FTBFS with new ipython

[Rebecca N. Palmer]

Package: python-patsy-doc
Version: 0.5.1-0.2
Severity: serious
Control: tags -1 patch

Some examples in patsy's spline-regression.rst raise exceptions when 
executed (at documentation build time).  Such exceptions used to appear 
in the documentation output, but in ipython_directive 7.x they default 
to failing the whole build.


This can be turned off, but in the case of patsy it is possible to 
really fix the exceptions, which is probably better:


--- patsy-0.5.1/debian/control
+++ patsy-0.5.1/debian/control
@@ -8,6 +8,7 @@
python3-all,
python3-setuptools,
python3-numpy,
+   python3-scipy,
python3-pandas,
python3-nose,
python3-six,
--- patsy-0.5.1/debian/patches/print3.patch
+++ patsy-0.5.1/debian/patches/print3.patch
@@ -0,0 +1,17 @@
+Description: Use Python 3 syntax in example
+
+Author: Rebecca N. Palmer 
+Bug-Debian: https://bugs.debian.org/
+Forwarded: no
+
+--- patsy-0.5.1.orig/doc/spline-regression.rst
 patsy-0.5.1/doc/spline-regression.rst
+@@ -179,7 +179,7 @@ marginal spline bases patterns can be ob
+   :{"x1": x1.ravel(), "x2": x2.ravel(), "df": df})
+   :
+
+-   In [80]: print y.shape
++   In [80]: print(y.shape)
+
+In [90]: fig = plt.figure()
+
--- patsy-0.5.1/debian/patches/series
+++ patsy-0.5.1/debian/patches/series
@@ -1 +1,2 @@
 up_six_PY
+print3.patch

Bug#950097: rauc: no hardening when building from git repository

[Uwe Kleine-König]

Source: rauc
Version: 1.2-1
Severity: minor

When building rauc 1.2-1 from the git repository cloned from salsa I
get:

$ dpkg-buildpackage -uc -us
...
$ lintian -EL '>=pedantic' ../rauc_1.2-1_amd64.changes
I: rauc: hardening-no-fortify-functions usr/bin/rauc
I: rauc-service: package-supports-alternative-init-but-no-init.d-script 
lib/systemd/system/rauc.service
I: rauc-service: systemd-service-file-missing-install-key 
lib/systemd/system/rauc.service
I: rauc source: testsuite-autopkgtest-missing
X: rauc source: upstream-metadata-file-is-missing

. When I do

mv .git ../rauc.git

before building I get however:

$ dpkg-buildpackage -uc -us
...
$ lintian -EL '>=pedantic' ../rauc_1.2-1_amd64.changes
I: rauc-service: package-supports-alternative-init-but-no-init.d-script 
lib/systemd/system/rauc.service
I: rauc-service: systemd-service-file-missing-install-key 
lib/systemd/system/rauc.service
I: rauc source: testsuite-autopkgtest-missing
X: rauc source: upstream-metadata-file-is-missing

So the hardening-no-fortify-functions problem only occurs in the presence of
the .git directory.

This is related to ./configure assuming that debugging should be enabled if a
.git directory exists which in turn adds -O0 to the command line (additionally
to the -O2 that is present for both cases).

According to
https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_FORTIFY_.28gcc.2Fg.2B-.2B-_-D_FORTIFY_SOURCE.3D2.29
"for this feature to be fully enabled, the source must also be compiled with
-O1 or higher."

It is only little relevant for Debian as the packages are build from the
source package and there is no .git directory, but it is still ugly.

Maybe we should pass --disable-debugging to configure? Or convince
upstream that this assumption (.git present => --enable-debug) is a bad
idea?

Best regards
Uwe

Bug#949959: debcargo.toml should make it possible to declare additional dependencies for generated autopkgtests

[Daniel Kahn Gillmor]

Control: tag 949959 + patch

On Mon 2020-01-27 11:55:28 -0500, Daniel Kahn Gillmor wrote:
> So it would be good to be able to indicate in debcargo.toml some
> additional autopkgtest dependencies.
>
> Simplest might be to add a dependency for *all* generated autopkgtests,
> but i can imagine there are some subtler requirements which will need to
> be for specific autopkgtests in the future.

Wolfgang created this patch (on the dev/debian_949959 branch in salsa)
to implement this mechanism.

It looks reasonable to me, and it compiles fine.  I'm in the process of
testing it now.

   --dkg

From 9a250f348f31294ccdc11eb629a2b53341ef6814 Mon Sep 17 00:00:00 2001
From: Wolfgang Silbermayr 
Date: Tue, 28 Jan 2020 12:50:59 +0100
Subject: [PATCH] Implement extra_test_deps config option at top level

Add an extra_test_deps to top level of debcargo.toml where autopkgtest
dependencies can be added. A first simple implementation of this feature
for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949959

Might be extended later by adding the same field to the [packages.lib*]
entries if dependencies are required by some tests only, but must not be
present on others.
---
 debcargo.toml.example |  3 +++
 src/config.rs |  2 ++
 src/debian/mod.rs | 10 --
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/debcargo.toml.example b/debcargo.toml.example
index b463f1d..74658ab 100644
--- a/debcargo.toml.example
+++ b/debcargo.toml.example
@@ -45,6 +45,9 @@
 # exceptional cases where the method gives a false-positive, add them here.
 #whitelist = ["libgit2/**"]
 
+# Additional dependencies for the autopkgtests. Gets added to all tests.
+#extra_test_deps = ["llvm", "clang"]
+
 # Whether to allow prerelease deps, by rewriting these to the released version.
 # This should only be enabled for certain crates if really necessary, and first
 # you should check that they can actually build when this is enabled.
diff --git a/src/config.rs b/src/config.rs
index d0d8583..43a9a89 100644
--- a/src/config.rs
+++ b/src/config.rs
@@ -18,6 +18,7 @@ pub struct Config {
 pub overlay: Option,
 pub excludes: Option>,
 pub whitelist: Option>,
+pub extra_test_deps: Option>,
 pub allow_prerelease_deps: bool,
 pub summary: String,
 pub description: String,
@@ -61,6 +62,7 @@ impl Default for Config {
 overlay: None,
 excludes: None,
 whitelist: None,
+extra_test_deps: None,
 allow_prerelease_deps: false,
 summary: "".to_string(),
 description: "".to_string(),
diff --git a/src/debian/mod.rs b/src/debian/mod.rs
index 7969ee8..a06b522 100644
--- a/src/debian/mod.rs
+++ b/src/debian/mod.rs
@@ -503,6 +503,12 @@ pub fn prepare_debian_folder(
 };
 
 if lib {
+let mut test_depends = dev_depends.clone();
+if let Some(ref extra) = config.extra_test_deps {
+test_depends.extend(extra.clone());
+test_depends.sort();
+test_depends.dedup();
+}
 // debian/tests/control
 let mut testctl = io::BufWriter::new(file("tests/control")?);
 write!(
@@ -513,7 +519,7 @@ pub fn prepare_debian_folder(
 &crate_name,
 &crate_version,
 vec!["--all-features"],
-&dev_depends,
+&test_depends,
 if all_features_test_broken {
 vec!["flaky"]
 } else {
@@ -576,7 +582,7 @@ pub fn prepare_debian_folder(
 } else {
 vec!["--features", feature]
 },
-&dev_depends,
+&test_depends,
 if test_is_broken {
 vec!["flaky"]
 } else {
-- 
2.24.1



signature.asc
Description: PGP signature

Bug#950096: flatpak: Flatpak fails to open SSL connections with p11-kit 0.23.19

[Lennart Weller]

Package: flatpak
Version: 1.6.1-1
Severity: important

Dear Maintainer,

Currently all SSL connections, probably mostly HTTPS, will fail with
flatpak due to a major API change in p11-kit as discussed in the merge
request[1] for p11-kit 0.23.19, cause obviously a patch-version changes
major API endpoints.


[1] 
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/2255?commit_id=e3361c2ddf3ecfff19908effb80d3a648e3dd75a


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

Kernel: Linux 5.4.0-3-amd64 (SMP w/24 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) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=en_US:de (charmap=UTF-8) (ignored: LC_ALL set to 
de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flatpak depends on:
ii  adduser3.118
ii  bubblewrap 0.4.0-1
ii  libappstream-glib8 0.7.16-1
ii  libarchive13   3.4.0-1+b1
ii  libc6  2.29-9
ii  libdconf1  0.34.0-2
ii  libfuse2   2.9.9-2
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-2
ii  libglib2.0-0   2.62.4-1+b1
ii  libgpgme11 1.13.1-3
ii  libjson-glib-1.0-0 1.4.4-2
ii  libostree-1-1  2019.6-1
ii  libpolkit-agent-1-00.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libseccomp22.4.2-2
ii  libsoup2.4-1   2.68.2-1
ii  libsystemd0244.1-1
ii  libxau61:1.0.8-1+b2
ii  libxml22.9.4+dfsg1-8
ii  xdg-dbus-proxy 0.1.2-1

Versions of packages flatpak recommends:
ii  desktop-file-utils   0.24-1
ii  gtk-update-icon-cache3.24.13-1
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   244.1-1
ii  p11-kit  0.23.19-2
ii  policykit-1  0.105-26
ii  shared-mime-info 1.10-1
ii  xdg-desktop-portal   1.6.0-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.6.0-1

Versions of packages flatpak suggests:
ii  avahi-daemon  0.7-5

-- no debconf information

Bug#946470: libreoffice-l10n-de: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Followup-For: Bug #946470
Control: found -1 1:6.4.0~rc3-1
Control: affects -1 + libreoffice-l10n-kmr

Hi Rene,

there are still a few left when upgrading from testing (1:6.3.4-2) to
sid (1:6.4.0~rc3-1):

0m37.5s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/libreoffice-l10n-in/changelog.Debian.gz (libreoffice-l10n-in) 
!= /usr/share/doc/libreoffice-common/changelog.Debian.gz (libreoffice-common)
/usr/share/doc/libreoffice-l10n-in -> libreoffice-common
  /usr/share/doc/libreoffice-l10n-in/copyright (libreoffice-l10n-in) != 
/usr/share/doc/libreoffice-common/copyright (libreoffice-common)
/usr/share/doc/libreoffice-l10n-in -> libreoffice-common

0m35.7s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/libreoffice-l10n-za/changelog.Debian.gz (libreoffice-l10n-za) 
!= /usr/share/doc/libreoffice-common/changelog.Debian.gz (libreoffice-common)
/usr/share/doc/libreoffice-l10n-za -> libreoffice-common
  /usr/share/doc/libreoffice-l10n-za/copyright (libreoffice-l10n-za) != 
/usr/share/doc/libreoffice-common/copyright (libreoffice-common)
/usr/share/doc/libreoffice-l10n-za -> libreoffice-common

0m33.7s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/libreoffice-l10n-kmr/changelog.Debian.gz 
(libreoffice-l10n-kmr) != /usr/share/doc/libreoffice-common/changelog.Debian.gz 
(libreoffice-common)
/usr/share/doc/libreoffice-l10n-kmr -> libreoffice-common
  /usr/share/doc/libreoffice-l10n-kmr/copyright (libreoffice-l10n-kmr) != 
/usr/share/doc/libreoffice-common/copyright (libreoffice-common)
/usr/share/doc/libreoffice-l10n-kmr -> libreoffice-common


Andreas

Bug#949992: Does not take subprocess down when killed

[martin f krafft]

tags 949992 +patch
kthxbye

Attached is a patch. Warning, I'm not a Perl-coder. Seems to work 
though.


--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"i never travel without my diary. one should always have something

 sensational to read on the train."
  -- oscar wilde
--- /tmp/run-mailcap	2020-01-29 09:12:51.002973844 +1300
+++ /usr/bin/run-mailcap	2020-01-29 10:37:56.385391104 +1300
@@ -12,6 +12,7 @@
 use Encode qw(decode);
 use I18N::Langinfo qw(langinfo CODESET);
 use File::Spec;
+use POSIX ":sys_wait_h";
 
 $debug=($ENV{RUN_MAILCAP_DEBUG} || 0);
 $norun=0;
@@ -25,8 +26,17 @@
 $quotedsemi=chr(255);
 $quotedprct=chr(254);
 $retcode=0;
+$wait_on_child_pid=0;
 
+sub signal_handler {
+my($sig) = @_;
+print STDERR " - caught signal $sig, cleaning up...\n" if $debug;
+kill $sig, $wait_on_child_pid;
+die "Terminated on signal $sig";
+}
 
+$SIG{INT} = \&signal_handler;
+$SIG{TERM} = \&signal_handler;
 
 sub Usage {
 my($error) = @_;
@@ -542,22 +552,28 @@
 	print $comm,"\n";
 	$res = 0;
 	} else {
-	$res = system $comm;
-	if ($res != 0) {
-		if (!($res & 0xFF)) {
-print STDERR "Warning: program returned non-zero exit code \#$res\n";
-$retcode = $res >> 8;
-		} elsif ($res == -1) {
-		print STDERR "Error: program failed to execute: $!\n";
-		$retcode = -1;
-		} else {
+	my $pid = fork;
+	die "Unable to fork" unless defined $pid;
+	if ($pid == 0) {
+		exec $comm;
+	} else {
+		$wait_on_child_pid=$pid; # so the signal handler knows what to kill.
+		waitpid($pid, 0);
+
+		if ($? & 0xFF) {
 		my $signal = $? & 0x7F;
 		my $core = ($? & 0x80) ? ' (core dumped)' : '';
 		print STDERR "Warning: program died on signal ${signal}${core}\n";
 		$retcode = -1;
+		} elsif ($? == -1) {
+		print STDERR "Error: program failed to execute: $!\n";
+		$retcode = -1;
+		} elsif ($? > 0) {
+		print STDERR "Warning: program returned non-zero exit code \#$?\n";
+		$retcode = $?;
 		}
-}
-}
+	}
+	}
 $done=1;
 unlink $tmpfile if $tmpfile;
 unlink $tmplink if $tmplink;


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#950095: ITP: pyout -- interface for writing structured records as a table in a terminal

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 

* Package name: pyout
  Version : 0.5.0
  Upstream Author : Kyle Meyer 
* URL : https://github.com/pyout/pyout
* License : MIT/X
  Programming Lang: Python
  Description : interface for writing structured records as a table in a 
terminal

pyout is a Python package that defines an interface for writing
structured records as a table in a terminal. It is being developed to replace
custom code for displaying tabular data in in ReproMan and DataLad.
.
A primary goal of the interface is the separation of content from style
and presentation. Current capabilities include
.
 - automatic width adjustment and updating of previous values
 - styling based on a field value or specified interval
 - defining a transform function that maps a raw value to the displayed value
 - defining a summary function that generates a summary of a column (e.g., 
value totals)
 - support for delayed, asynchronous values that are added to the table as they 
come in


This package is needed for other upcoming ITPs, and eventually might
also be used in already existing packages (e.g. datalad)

The plan is to team maintain it within Debian Python Modules Team, since pyout 
is
of general utility.

Bug#950094: ipywidgets FTBFS with node-semver 7.1.1-2

[Adrian Bunk]

Source: ipywidgets
Version: 6.0.0-6
Severity: serious
Tags: ftbfs

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

...
rm -rf "fakewebpack/widgetsnbextension" && mkdir -p 
"fakewebpack/widgetsnbextension" && ./fakewebpack-generate.py 
fakewebpack-meta/widgetsnbextension.files 
fakewebpack-meta/widgetsnbextension.modules 
fakewebpack-unpacked/widgetsnbextension/ True > 
"fakewebpack/widgetsnbextension/extension.js" && touch 
"fakewebpack/widgetsnbextension.stamp"
fs.js:114
throw err;
^

Error: ENOENT: no such file or directory, open './node_modules/semver/semver.js'
at Object.openSync (fs.js:443:3)
at Object.readFileSync (fs.js:343:35)
at Object. 
(/build/1st/ipywidgets-6.0.0/debian/fakewebpack-postprocess.js:233:19)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
at startup (internal/bootstrap/node.js:283:19)
module 00: nodejs ../../fakewebpack-postprocess.js ./src/extension.js 
../../fakewebpack-meta/widgetsnbextension.modules
module 01: nodejs ../../fakewebpack-postprocess.js ./src/manager.js 
../../fakewebpack-meta/widgetsnbextension.modules
module 02: nodejs ../../fakewebpack-postprocess.js 
./node_modules/underscore/underscore.js 
../../fakewebpack-meta/widgetsnbextension.modules
module 03: nodejs ../../fakewebpack-postprocess.js 
./node_modules/backbone/backbone.js 
../../fakewebpack-meta/widgetsnbextension.modules
module 04: nodejs ../../fakewebpack-postprocess.js 
./node_modules/jquery/dist/jquery.js 
../../fakewebpack-meta/widgetsnbextension.modules
module 05: nodejs ../../fakewebpack-postprocess.js 
./node_modules/jupyter-js-widgets/lib/index.js 
../../fakewebpack-meta/widgetsnbextension.modules
module 06: nodejs ../../fakewebpack-postprocess.js 
./node_modules/jupyter-js-widgets/lib/manager-base.js 
../../fakewebpack-meta/widgetsnbextension.modules
module 07: nodejs ../../fakewebpack-postprocess.js 
./node_modules/jupyter-js-widgets/lib/utils.js 
../../fakewebpack-meta/widgetsnbextension.modules
module 08: nodejs ../../fakewebpack-postprocess.js 
./node_modules/semver/semver.js 
../../fakewebpack-meta/widgetsnbextension.modules
Traceback (most recent call last):
  File "./fakewebpack-generate.py", line 97, in 
sys.exit(main(*sys.argv[1:]))
  File "./fakewebpack-generate.py", line 66, in main
cwd=srcdir).decode("utf-8")
  File "/usr/lib/python3.7/subprocess.py", line 411, in check_output
**kwargs).stdout
  File "/usr/lib/python3.7/subprocess.py", line 512, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['nodejs', 
'../../fakewebpack-postprocess.js', './node_modules/semver/semver.js', 
'../../fakewebpack-meta/widgetsnbextension.modules']' returned non-zero exit 
status 1.
make[2]: *** [fakewebpack.mk:77: fakewebpack/widgetsnbextension.stamp] Error 1

Bug#950093: libblasr-dev: missing Breaks+Replaces: libblasr (<< 5.3.3)

[Andreas Beckmann]

Package: libblasr-dev
Version: 5.3.3+dfsg-3
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 .../2-libblasr-dev_5.3.3+dfsg-3_amd64.deb ...
  Unpacking libblasr-dev (5.3.3+dfsg-3) over (5.3.1+dfsg-2.1+b1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-09Rr1t/2-libblasr-dev_5.3.3+dfsg-3_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libblasr.so', which is also 
in package libblasr:amd64 5.3.1+dfsg-2.1+b1


cheers,

Andreas


libblasr-dev_5.3.3+dfsg-3.log.gz
Description: application/gzip

Bug#950092: node-base64url FTBFS: error TS2688: Cannot find type definition file for 'node'

[Adrian Bunk]

Source: node-base64url
Version: 3.0.1-2
Severity: serious
Tags: ftbfs bullseye sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-base64url.html

...
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/1st/node-base64url-3.0.1'
pandoc --from gfm-raw_html --to html --standalone --output readme.html readme.md
[WARNING] This document format requires a nonempty  element.
  Please specify either 'title' or 'pagetitle' in the metadata,
  e.g. by using --metadata pagetitle="..." on the command line.
  Falling back to 'readme'
pandoc --from gfm-raw_html --to plain --output readme.txt readme.md
tsc
error TS2688: Cannot find type definition file for 'node'.
src/base64url.ts(35,22): error TS4067: Parameter 'input' of call signature from 
exported interface has or is using private name 'Buffer'.
src/base64url.ts(36,28): error TS4075: Parameter 'input' of method from 
exported interface has or is using private name 'Buffer'.
src/base64url.ts(38,34): error TS4075: Parameter 'base64url' of method from 
exported interface has or is using private name 'Buffer'.
src/base64url.ts(40,34): error TS4057: Return type of method from exported 
interface has or is using private name 'Buffer'.
make[1]: *** [debian/rules:9: override_dh_auto_build] Error 1

Bug#950091: node-prop-types FTBFS: Error: Can't resolve

[Adrian Bunk]

Source: node-prop-types
Version: 15.6.0+ds-3
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-prop-types.html

...
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/1st/node-prop-types-15.6.0+ds'
webpack --config debian/webpack.config.js --output-library=PropTypes \
--entry index.js --output ./prop-types.js --mode development
Hash: e061ebce6ca8f90025b2
Version: webpack 4.7.0
Time: 1190ms
Built at: 02/27/2021 10:52:30 PM
Asset  Size  Chunks Chunk Names
prop-types.js  28.9 KiBnull  [emitted]  null
Entrypoint null = prop-types.js
[./checkPropTypes.js] 2.81 KiB {null} [built]
[./factoryWithTypeCheckers.js] 19.4 KiB {null} [built]
[./index.js] 956 bytes {null} [built]
[./lib/ReactPropTypesSecret.js] 314 bytes {null} [built]

ERROR in ./factoryWithTypeCheckers.js
Module not found: Error: Can't resolve 'fbjs/lib/emptyFunction' in 
'/build/1st/node-prop-types-15.6.0+ds'
 @ ./factoryWithTypeCheckers.js 10:20-53
 @ ./index.js

ERROR in ./factoryWithTypeCheckers.js
Module not found: Error: Can't resolve 'fbjs/lib/invariant' in 
'/build/1st/node-prop-types-15.6.0+ds'
 @ ./factoryWithTypeCheckers.js 11:16-45
 @ ./index.js

ERROR in ./checkPropTypes.js
Module not found: Error: Can't resolve 'fbjs/lib/invariant' in 
'/build/1st/node-prop-types-15.6.0+ds'
 @ ./checkPropTypes.js 11:18-47
 @ ./factoryWithTypeCheckers.js
 @ ./index.js

ERROR in ./factoryWithTypeCheckers.js
Module not found: Error: Can't resolve 'fbjs/lib/warning' in 
'/build/1st/node-prop-types-15.6.0+ds'
 @ ./factoryWithTypeCheckers.js 12:14-41
 @ ./index.js

ERROR in ./checkPropTypes.js
Module not found: Error: Can't resolve 'fbjs/lib/warning' in 
'/build/1st/node-prop-types-15.6.0+ds'
 @ ./checkPropTypes.js 12:16-43
 @ ./factoryWithTypeCheckers.js
 @ ./index.js

ERROR in ./factoryWithTypeCheckers.js
Module not found: Error: Can't resolve 'object-assign' in 
'/build/1st/node-prop-types-15.6.0+ds'
 @ ./factoryWithTypeCheckers.js 13:13-37
 @ ./index.js
make[1]: *** [debian/rules:8: override_dh_auto_build] Error 2

Bug#950090: gcc-mingw-w64: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Source: gcc-mingw-w64
Version: 22~exp2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + gcc-mingw-w64-x86-64 gfortran-mingw-w64-x86-64 
g++-mingw-w64-x86-64 gobjc-mingw-w64-x86-64 gobjc++-mingw-w64-x86-64 
gnat-mingw-w64-x86-64
Control: affects -1 + gcc-mingw-w64-i686 gfortran-mingw-w64-i686 
g++-mingw-w64-i686 gobjc-mingw-w64-i686 gobjc++-mingw-w64-i686 
gnat-mingw-w64-i686
Control: found -1 gcc-mingw-w64/9.2.1-21+22~exp2

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  sid -> experimental

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


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

0m37.3s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/g++-mingw-w64-i686/changelog.Debian.gz (g++-mingw-w64-i686) != 
/usr/share/doc/gcc-mingw-w64-base/changelog.Debian.gz (gcc-mingw-w64-base)
/usr/share/doc/g++-mingw-w64-i686 -> gcc-mingw-w64-base
  /usr/share/doc/g++-mingw-w64-i686/changelog.gz (g++-mingw-w64-i686) != 
/usr/share/doc/gcc-mingw-w64-base/changelog.gz (gcc-mingw-w64-base)
/usr/share/doc/g++-mingw-w64-i686 -> gcc-mingw-w64-base
  /usr/share/doc/g++-mingw-w64-i686/copyright (g++-mingw-w64-i686) != 
/usr/share/doc/gcc-mingw-w64-base/copyright (gcc-mingw-w64-base)
/usr/share/doc/g++-mingw-w64-i686 -> gcc-mingw-w64-base
  /usr/share/doc/gcc-mingw-w64-i686/changelog.Debian.gz (gcc-mingw-w64-i686) != 
/usr/share/doc/gcc-mingw-w64-base/changelog.Debian.gz (gcc-mingw-w64-base)
/usr/share/doc/gcc-mingw-w64-i686 -> gcc-mingw-w64-base
  /usr/share/doc/gcc-mingw-w64-i686/changelog.gz (gcc-mingw-w64-i686) != 
/usr/share/doc/gcc-mingw-w64-base/changelog.gz (gcc-mingw-w64-base)
/usr/share/doc/gcc-mingw-w64-i686 -> gcc-mingw-w64-base
  /usr/share/doc/gcc-mingw-w64-i686/copyright (gcc-mingw-w64-i686) != 
/usr/share/doc/gcc-mingw-w64-base/copyright (gcc-mingw-w64-base)
/usr/share/doc/gcc-mingw-w64-i686 -> gcc-mingw-w64-base

0m36.2s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/gcc-mingw-w64-x86-64/changelog.Debian.gz 
(gcc-mingw-w64-x86-64) != /usr/share/doc/gcc-mingw-w64-base/changelog.Debian.gz 
(gcc-mingw-w64-base)
/usr/share/doc/gcc-mingw-w64-x86-64 -> gcc-mingw-w64-base
  /usr/share/doc/gcc-mingw-w64-x86-64/changelog.gz (gcc-mingw-w64-x86-64) != 
/usr/share/doc/gcc-mingw-w64-base/changelog.gz (gcc-mingw-w64-base)
/usr/share/doc/gcc-mingw-w64-x86-64 -> gcc-mingw-w64-base
  /usr/share/doc/gcc-mingw-w64-x86-64/copyright (gcc-mingw-w64-x86-64) != 
/usr/share/doc/gcc-mingw-w64-base/copyright (gcc-mingw-w64-base)
/usr/share/doc/gcc-mingw-w64-x86-64 -> gcc-mingw-w64-base
  /usr/share/doc/gfortran-mingw-w64-x86-64/changelog.Debian.gz 
(gfortran-mingw-w64-x86-64) != 
/usr/share/doc/gcc-mingw-w64-base/changelog.Debian.gz (gcc-mingw-w64-base)
/usr/share/doc/gfortran-mingw-w64-x86-64 -> gcc-mingw-w64-base
  /usr/share/doc/gfortran-mingw-w64-x86-64/changelog.gz 
(gfortran-mingw-w64-x86-64) != /usr/share/doc/gcc-mingw-w64-base/changelog.gz 
(gcc-mingw-w64-base)
/usr/share/doc/gfortran-mingw-w64-x86-64 -> gcc-mingw-w64-base
  /usr/share/doc/gfortran-mingw-w64-x86-64/copyright 
(gfortran-mingw-w64-x86-64) != /usr/share/doc/gcc-mingw-w64-base/copyright 
(gcc-mingw-w64-base)
/usr/share/doc/gfortran-mingw-w64-x86-64 -> gcc-mingw-w64-base

This seems to affect the full language x arch matrix.

Note that dpkg-maintscript-helper symlink_to_dir etc. don't work
reliably if the architecture changes between any and all.


cheers,

Andreas


g++-mingw-w64-i686_9.2.1-21+22~exp2.log.gz
Description: application/gzip

Bug#947847: please install systemd-sysusers using update-alternatives

[Philipp Kern]

On 1/28/2020 1:33 PM, Thomas Goirand wrote:
>> It'd need to be a script that the systemd maintainers feel reasonably
>> confident will always run systemd's implementation when systemd is
>> running, to avoid the mixed implementations issue.
> 
> Not at all. Systemd maintainers have no say if someone wishes to
> implement things in another way, the same way there's gawk and mawk,
> implementing the same thing. If we don't allow such things, then really,
> Debian is doomed.

The interface in question here is "awk". So if the interface would be a
hypothetical "update-sysusers", then this could be shared with
alternatives. I completely understand the view of the systemd
maintainers that "systemd-sysusers" as a binary should be provided by
their package rather than an alternative.

>> Strikes me as there is a possible solution, though: have opensysusers
>> dpkg-divert it and put a shell script in its place that checks which
>> init system is running, and exec's the right sysusers based on that.
> 
> This is exactly what should be avoided. It's perfectly fine to try to
> use opensysusers with systemd if one wants. In fact, that's exactly the
> best way we could do to be able to test it. Also, dpkg-divert is really
> ugly, and something you use as the last resort, when all other options
> have been exhausted.

If the problem here is that everything embeds a call to systemd-sysusers
directly and you want to provide a different intermediate interface
eventually then diverting it as a workaround in the meantime seems sound
to me, no?

So far I see you present a single option rather than trying to negotiate
within the option space. Good escalations are not "Moreover, I don't see
why /usr/bin/systemd-sysusers would be any different from let's say
/usr/bin/awk." but trying to present the two opposing viewpoints and
potential solutions to them.

Kind regards
Philipp Kern

Bug#950089: node-chrome-trace-event FTBFS: error TS2300: Duplicate identifier 'IteratorResult'

[Adrian Bunk]

Source: node-chrome-trace-event
Version: 1.0.0-1
Severity: serious
Tags: ftbfs bullseye sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-chrome-trace-event.html

...
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/1st/node-chrome-trace-event-1.0.0'
tsc --typeRoots debian/node_modules/@types --baseUrl debian/node_modules
debian/node_modules/@types/node/index.d.ts(78,11): error TS2300: Duplicate 
identifier 'IteratorResult'.
../../../usr/share/nodejs/typescript/lib/lib.es2015.iterable.d.ts(41,6): error 
TS2300: Duplicate identifier 'IteratorResult'.
make[1]: *** [debian/rules:12: override_dh_auto_build] Error 2

Bug#950088: node-rollup-plugin-string: missing build dependency on node-rollup-plugin-buble

[Adrian Bunk]

Source: node-rollup-plugin-string
Version: 3.0.0-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-rollup-plugin-string.html

...
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/1st/node-rollup-plugin-string-3.0.0'
rollup -c
[!] Error: Cannot find module 'rollup-plugin-buble'
Error: Cannot find module 'rollup-plugin-buble'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. 
(/build/1st/node-rollup-plugin-string-3.0.0/rollup.config.js:5:29)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.require.extensions..js 
(/usr/share/nodejs/rollup/bin/src/run/loadConfigFile.js:39:24)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)

make[1]: *** [debian/rules:7: override_dh_auto_build] Error 1

Bug#950087: statsmodels: FTBFS with new ipython

[Rebecca N. Palmer]

Package: python-statsmodels-doc
Severity: serious
Control: tags -1 patch
(only tested in 0.11, but believed to exist earlier)

Some documentation examples (e.g. contrasts.rst) fail in a Debian build 
because they need to download data.


This has been the case for some time, but only became an FTBFS when 
ipython 7.x was uploaded, as ipython_directive now defaults to failing 
the build when an example fails.


Fix: turn this off with

--- statsmodels-0.11.0.orig/docs/source/conf.py
+++ statsmodels-0.11.0/docs/source/conf.py
@@ -63,6 +63,7 @@ else:

 # nbsphinx options
 nbsphinx_allow_errors = True
+ipython_warning_is_error = False
 # sphinxcontrib-spelling options
 spelling_word_list_filename = ['spelling_wordlist.txt', 
'names_wordlist.txt']

 spelling_ignore_pypi_package_names = True

Bug#949854: RFS: coinor-vol/1.5.4-3 -- Coin-or linear programming solver (libraries)

[Sudip Mukherjee]

Hi Adam,

On Sun, Jan 26, 2020 at 01:39:00AM +0100, Adam Borowski wrote:
> On Sat, Jan 25, 2020 at 11:53:02PM +, Sudip Mukherjee wrote:
> >  * Package name: coinor-vol
> >Version : 1.5.4-3
> 
> > Changes since the last upload:
> > 
> >* QA upload.
> >* Fix relative paths.
> >* Use dh_autoreconf and dh_auto_configure. (Closes: #949299)
> 
> I'm afraid that it throws an enormous number of errors:

> ./config.status: line 764: : command not found

A new package has been uploaded to mentors for your review.

Changes since the last upload:

   * QA upload.
   * Fix relative paths.
   * Use libtool from system.
   * Use dh_autoreconf and dh_auto_configure. (Closes: #949299)

--
Regards
Sudip

Bug#940536: dhex: hangs on keyboard config screen

[Linux-Fan]

Hello,

this bug is also known for the Ubuntu package:
https://bugs.launchpad.net/ubuntu/+source/dhex/+bug/1814478

There, it is mentioned that the `cpu-load` patch is causing this bug. I just
verified this: Compiling the original (unmodified, unpatched) dhex-0.69
source code does not expose this buggy behaviour. However, if the line from
the `cpu-load` patch is applied (even without the other patches), the setup
screen does not react to keyboard input as described in the respective bug
reports.

I would thus suggest that the `cpu-load` patch be removed or fixed?

Thanks in advance
Linux-Fan


pgpvtF1QsxVrj.pgp
Description: PGP signature

Bug#950086: base-installer: please support configuring initramfs compression

[Alper Nebi Yasak]

Source: base-installer
Version: 1.192
Severity: wishlist
Tags: patch

Dear Maintainers,

Debian-installer can already configure initramfs-tools' MODULES setting 
to get a smaller initramfs. I've written a patch for configuring its 
COMPRESS setting as well, please consider applying it. I've tested it 
using an arm64 virtual machine with a custom built netboot image.


I'm doing something like flash-kernel & flash-kernel-installer for 
chromebooks, which have size limits on kernel + initramfs + etc. If the 
installer step fails due to initramfs size I'll be asking these two 
questions to the user with a higher priority, regenerate the initramfs, 
and retry the step. Such a flow could be implemented for flash-kernel as 
well, and I think having at least the question template here would be great.


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

Kernel: Linux 5.4.0-3-arm64 (SMP w/6 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 2864137a59bcfbc957a7e8960b65e3e39977106a Mon Sep 17 00:00:00 2001
From: Alper Nebi Yasak 
Date: Mon, 27 Jan 2020 21:16:10 +0300
Subject: [PATCH] Support configuring initramfs compression

Some machines/bootloaders do not support initramfs images larger than a
certain size. Setting MODULES=dep in initramfs-tools config is usually
enough to satisfy these size limits, and base-installer already asks a
question for this (driver-policy, with priority medium). This patch
implements a similar question for initramfs-tools' COMPRESS setting
which can further reduce the initramfs size for these machines.

Signed-off-by: Alper Nebi Yasak 
---
 debian/bootstrap-base.templates | 11 +++
 debian/templates-arch   |  6 ++
 library.sh  | 22 ++
 3 files changed, 39 insertions(+)

diff --git a/debian/bootstrap-base.templates b/debian/bootstrap-base.templates
index 78a6f29a..7a53cad3 100644
--- a/debian/bootstrap-base.templates
+++ b/debian/bootstrap-base.templates
@@ -88,6 +88,17 @@ _Description: Drivers to include in the initrd:
  smaller targeted initrd there is a very small chance that not all needed
  drivers are included.
 
+Template: base-installer/initramfs-tools/compression
+Type: select
+Choices: lzop, lz4, gzip, bzip2, xz, lzma
+# :sl3:
+_Description: Compression method for the initramfs image:
+ Compressing the initramfs is usually a trade-off between initramfs
+ size, memory use, compression speed, and the time your system takes to
+ boot (decompression speed). Gzip is reasonably balanced, xz and lzma
+ makes the initramfs significantly smaller, but lz4 has the highest
+ decompression speed.
+
 Template: base-installer/kernel/failed-install
 Type: error
 # :sl2:
diff --git a/debian/templates-arch b/debian/templates-arch
index 30e8f7a8..873dc001 100644
--- a/debian/templates-arch
+++ b/debian/templates-arch
@@ -12,6 +12,12 @@ Default[armel]: dep
 Description: for internal use
  Default driver inclusion policy for initramfs-tools
 
+Template: base-installer/kernel/linux/initramfs-tools/compression
+Type: string
+Default: gzip
+Description: for internal use
+ Default compression method for initramfs-tools
+
 Template: base-installer/kernel/linux/extra-packages
 Type: string
 Default:
diff --git a/library.sh b/library.sh
index d7f05024..d2859566 100644
--- a/library.sh
+++ b/library.sh
@@ -575,8 +575,15 @@ EOF
 			db_get base-installer/kernel/linux/initramfs-tools/driver-policy
 			db_set base-installer/initramfs-tools/driver-policy "$RET"
 		fi
+		if db_get base-installer/initramfs-tools/compression && \
+		   [ -z "$RET" ]; then
+			# Get default for architecture
+			db_get base-installer/kernel/linux/initramfs-tools/compression
+			db_set base-installer/initramfs-tools/compression "$RET"
+		fi
 		db_settitle debian-installer/bootstrap-base/title
 		db_input medium base-installer/initramfs-tools/driver-policy || true
+		db_input medium base-installer/initramfs-tools/compression || true
 		if ! db_go; then
 			db_progress stop
 			exit 10
@@ -591,6 +598,21 @@ EOF
 MODULES=$RET
 EOF
 		fi
+
+		db_get base-installer/initramfs-tools/compression
+		if [ "$RET" != gzip ]; then
+			cat > $IT_CONFDIR/compression <

Bug#913446:

[Jason A. Donenfeld]

I'm not sure doing this by default is a good choice. Seems like this sort
of thing -- disrupting everybody's interfaces and particular configurations
-- should be opt-in rather than opt-out. Trying to (ab)use the wireguard
metapackage as a "switch" for this seems suboptimal. People want the
wireguard metapackage for easier installation, but that doesn't mean they
should also get opted in to this behavior. Can we come up with a real
configuration method for this that doesn't involve the metapackage and is
off by default?

Bug#950083: RM: koji/1.10.0-1+deb9u1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
Control: clone -1 -2
Control: retitle -2 RM: koji/1.16.2-1

Hi SRM

Please do remove koji on next stretch and buster point release, see
discussion with Holger in #942146. It is more sensible in the light of
the security issues and the user base to remove the package from stable
and oldstable.

Regards,
Salvatore

Bug#950085: ITP: mbpoll -- command line utility to communicate with ModBus slave (RTU or TCP)

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 

* Package name: mbpoll
  Version : 1.4.11
  Upstream Author : Pascal JEAN 
* URL : https://github.com/epsilonrt/mbpoll
* License : GPL-3+
  Programming Lang: C
  Description : command line utility to communicate with ModBus slave (RTU 
or TCP)

 mbpoll is a command line utility to communicate with ModBus slave (RTU or 
TCP).  
 It uses libmodbus (http://libmodbus.org/).  
 Although the syntax of these options is very close modpoll proconX program,
 it is a completely independent project.
 .
 mbpoll can:
 .
 - read discrete inputs
 - read and write binary outputs (coil)
 - read input registers
 - read and write output registers (holding register)
 .
 The reading and writing registers may be in decimal, hexadecimal or 
 floating single precision.

I'm will maintain this in an appropriate team. Science team seems to fit.

Bug#950082: nmu: finish transitions in experimental

[Andreas Beckmann]

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

Let's finish some transitions in experimental, too.

nmu connman_1.37+repack-1 . ANY . experimental . -m "Rebuild against 
libreadline8."
nmu librep_0.92.7-1 . ANY . experimental . -m "Rebuild against libreadline8."
nmu simtools_0~git20171013+dfsg-1 . ANY . experimental . -m "Rebuild against 
libreadline8."
nmu urjtag_0.10+r2052-1 . ANY . experimental . -m "Rebuild against 
libreadline8."
nmu virtuoso-opensource_7.2.5.1+dfsg-2 . ANY . experimental . -m "Rebuild 
against libreadline8."

nmu singular_1:4.1.2-p1+ds-2 . ANY . experimental . -m "Rebuild against 
libntl43."

nmu sundials_4.1.0+dfsg-1 . ANY . experimental . -m "Rebuild against petsc 
3.12."


Andreas

Bug#950081: vim-tlib: modifies shipped file: /usr/share/vim/addons/doc/tags

[Andreas Beckmann]

Package: vim-tlib
Version: 1.27-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package modifies files it has
shipped.

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

0m24.4s ERROR: FAIL: debsums reports modifications inside the chroot:
  /usr/share/vim/addons/doc/tags
  

cheers,

Andreas


vim-tlib_1.27-1.log.gz
Description: application/gzip

Bug#946996: wireguard-tools: 'wg-quick down' segfaults

[Daniel Kahn Gillmor]

On Mon 2020-01-27 19:45:36 -0500, Celejar wrote:
> I think I'm probably missing something, but lately "ifdown wg0" isn't
> segfaulting (even after downgrading back to 1.0.20200102-1) - but it
> doesn't seem to be calling iptables-restore at all, but only nft:

Ah, that'd be because you installed nft.  If you only had iptables
installed, and you didn't have nft installed, then you'd exercise the
different codepath in wg-quick.

  --dkg


signature.asc
Description: PGP signature

Bug#950080: kwartz-client: modifies conffiles (policy 10.7.3): /etc/kwartz-cloud.conf

[Andreas Beckmann]

Package: kwartz-client
Version: 1.4-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package modifies conffiles.
This is forbidden by the policy, see
https://www.debian.org/doc/debian-policy/ch-files.html#configuration-files

10.7.3: "[...] The easy way to achieve this behavior is to make the
configuration file a conffile. [...] This implies that the default
version will be part of the package distribution, and must not be
modified by the maintainer scripts during installation (or at any
other time)."

Note that once a package ships a modified version of that conffile,
dpkg will prompt the user for an action how to handle the upgrade of
this modified conffile (that was not modified by the user).

Further in 10.7.3: "[...] must not ask unnecessary questions
(particularly during upgrades) [...]"

If a configuration file is customized by a maintainer script after
having asked some debconf questions, it may not be marked as a
conffile. Instead a template could be installed in /usr/share and used
by the postinst script to fill in the custom values and create (or
update) the configuration file (preserving any user modifications!).
This file must be removed during postrm purge.
ucf(1) may help with these tasks.
See also https://wiki.debian.org/DpkgConffileHandling

In https://lists.debian.org/debian-devel/2012/09/msg00412.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

debsums reports modification of the following files,
from the attached log (scroll to the bottom...):

  /etc/kwartz-cloud.conf


cheers,

Andreas


kwartz-client_1.4-5.log.gz
Description: application/gzip

Bug#950079: grub-cloud-amd64: prompting due to modified conffiles which were not modified by the user: /etc/default/grub

[Andreas Beckmann]

Package: grub-cloud-amd64
Version: 0.0.5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + debian-cloud-images-packages

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

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

  Setting up grub-pc (2.04-5) ...
  
  Creating config file /etc/default/grub with new version
  grub-probe: error: cannot find a device for / (is /dev mounted?).
  grub-probe: error: cannot find a device for /boot (is /dev mounted?).
  grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?).
[...]
  Setting up grub-cloud-amd64 (0.0.5) ...
  
  Configuration file '/etc/default/grub'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** grub (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
grub-cloud-amd64 (--configure):
   end of file on stdin at conffile prompt


This was observed during a test of the debian-cloud-images-packages package.


cheers,

Andreas


debian-cloud-images-packages_0.0.3.log.gz
Description: application/gzip

Bug#950078: ovirt-guest-agent: fails to install: useradd: invalid shell '/sbin/nologin'

[Andreas Beckmann]

Package: ovirt-guest-agent
Version: 1.0.15.dfsg-1
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Selecting previously unselected package ovirt-guest-agent.
  Preparing to unpack .../97-ovirt-guest-agent_1.0.15.dfsg-1_all.deb ...
  useradd: invalid shell '/sbin/nologin'
  dpkg: error processing archive 
/tmp/apt-dpkg-install-pGnFan/97-ovirt-guest-agent_1.0.15.dfsg-1_all.deb 
(--unpack):
   new ovirt-guest-agent package pre-installation script subprocess returned 
error exit status 3
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-pGnFan/97-ovirt-guest-agent_1.0.15.dfsg-1_all.deb


cheers,

Andreas


ovirt-guest-agent_1.0.15.dfsg-1.log.gz
Description: application/gzip

Bug#950077: bs1770gain: Typo in manpage (lundness)

[Hans Joachim Desserud]

Package: bs1770gain
Version: 0.6.5-1
Severity: minor
Tags: patch

Dear Maintainer,

The man page contains a typo: lundness instead of loudness, see the 
attached patch.


Also reported in Ubuntu previously 
https://bugs.launchpad.net/ubuntu/+source/bs1770gain/+bug/1850286


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

Kernel: Linux 5.4.0-3-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

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

Versions of packages bs1770gain depends on:
ii  libavcodec587:4.2.2-1
ii  libavfilter77:4.2.2-1
ii  libavformat58   7:4.2.2-1
ii  libavutil56 7:4.2.2-1
ii  libc6   2.29-9
ii  libpostproc55   7:4.2.2-1
ii  libswresample3  7:4.2.2-1
ii  libswscale5 7:4.2.2-1

bs1770gain recommends no packages.

bs1770gain suggests no packages.

-- no debconf information


--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/bs1770gain.txtman b/debian/bs1770gain.txtman
index b5496de..e84979d 100644
--- a/debian/bs1770gain.txtman
+++ b/debian/bs1770gain.txtman
@@ -1,5 +1,5 @@
 NAME
-  bs1770gain - lundness scanner and normalizer based on ITU-R BS.1770
+  bs1770gain - loudness scanner and normalizer based on ITU-R BS.1770
 SYNOPSIS
   bs1770gain [options]  [ ...]
 DESCRIPTION

Bug#949081: wget2: diff for NMU version 1.99.1-2.1,

[Boyuan Yang]

Control: tags 949081 + patch
Control: tags 949081 + pending


Dear maintainer,

I've prepared an NMU for wget2 (versioned as 1.99.1-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru wget2-1.99.1/debian/changelog wget2-1.99.1/debian/changelog
--- wget2-1.99.1/debian/changelog   2018-05-17 16:13:56.0 -0400
+++ wget2-1.99.1/debian/changelog   2020-01-28 14:51:45.0 -0500
@@ -1,3 +1,12 @@
+wget2 (1.99.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild against new gnulib snapshot (20200127).
+  * debian/control: Add explicit build-dependency on texinfo.
+(Closes: #949081)
+
+ -- Boyuan Yang   Tue, 28 Jan 2020 14:51:45 -0500
+
 wget2 (1.99.1-2) unstable; urgency=medium
 
   * added missing manpages to the packages. closes: Bug#898132
diff -Nru wget2-1.99.1/debian/control wget2-1.99.1/debian/control
--- wget2-1.99.1/debian/control 2018-05-17 16:13:56.0 -0400
+++ wget2-1.99.1/debian/control 2020-01-28 14:51:42.0 -0500
@@ -1,7 +1,7 @@
 Source: wget2
 Priority: optional
 Maintainer: Noël Köthe 
-Build-Depends: debhelper (>= 10), pkg-config, doxygen, pandoc, gettext,
zlib1g-dev, liblzma-dev, libbz2-dev, libbrotli-dev, libpcre2-dev, libgnutls28-
dev, libidn11-dev, libidn2-0-dev, flex, libpsl-dev, automake, dh-strip-
nondeterminism, gnulib, libnghttp2-dev, graphviz, libgpgme-dev
+Build-Depends: debhelper (>= 10), pkg-config, doxygen, pandoc, gettext,
zlib1g-dev, liblzma-dev, libbz2-dev, libbrotli-dev, libpcre2-dev, libgnutls28-
dev, libidn11-dev, libidn2-0-dev, flex, libpsl-dev, automake, dh-strip-
nondeterminism, gnulib, libnghttp2-dev, graphviz, libgpgme-dev, texinfo
 Standards-Version: 4.1.4
 Section: web
 Homepage: https://gitlab.com/gnuwget/wget2


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

Bug#950076: install fails due to changed OpenStreetMap URLs

[Manfred Hampl]

Package: openstreetmap-carto-common
Version: 2.45.1-1

Installation of openstreetmap-carto-common fails in the postinst script.
The script get-shapefiles.sh tries to download certain files from 
OpenStreetMap.org.
Apparently OpenStreetMap.org has restructured their repositories, and so the 
script fails.

The four links starting with "http://data.openstreetmapdata.com/... have to be 
changed into "https://osmdata.openstreetmap.de/download/...

Another possible solution to solve this problem would be an upgrade to the most 
recent version from upstream source (4.24.1)

osm.diff
Description: osm.diff