Bug#960167: yaml-cpp FTCBFS: builds embedded gtest for the build architecture
Source: yaml-cpp Version: 0.6.3-5 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs yaml-cpp fails to cross build from source again, because it ships an embedded gtest library and builds it using the build architecture via a cmake ExternalProject_Add. It turns out, that we don't actually need it unless running tests, which we don't do during cross compilation. Therefore please skip building tests when DEB_BUILD_OPTIONS=nocheck is set. I'm attaching a patch for your convenience. It also cleans up debian/rules a little and fixes a little build/host confusion. I hope that's ok for you. Helmut diff --minimal -Nru yaml-cpp-0.6.3/debian/changelog yaml-cpp-0.6.3/debian/changelog --- yaml-cpp-0.6.3/debian/changelog 2020-05-09 17:34:48.0 +0200 +++ yaml-cpp-0.6.3/debian/changelog 2020-05-10 07:37:31.0 +0200 @@ -1,3 +1,10 @@ +yaml-cpp (0.6.3-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Don't build tests for DEB_BUILD_OPTIONS=nocheck. (Closes: #-1) + + -- Helmut Grohne Sun, 10 May 2020 07:37:31 +0200 + yaml-cpp (0.6.3-5) unstable; urgency=medium * Team upload. diff --minimal -Nru yaml-cpp-0.6.3/debian/rules yaml-cpp-0.6.3/debian/rules --- yaml-cpp-0.6.3/debian/rules 2020-05-09 17:34:13.0 +0200 +++ yaml-cpp-0.6.3/debian/rules 2020-05-10 07:37:31.0 +0200 @@ -6,7 +6,7 @@ # This has to be exported to make some magic below work. export DH_OPTIONS -DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) +include /usr/share/dpkg/architecture.mk CPPFLAGS :=$(shell dpkg-buildflags --get CPPFLAGS) ifneq (,$(filter $(DEB_BUILD_ARCH),mipsel)) @@ -20,23 +20,18 @@ export DEB_HOST_MULTIARCH CPPFLAGS CFLAGS CXXFLAGS LDFLAGS -ifeq (,$(filter $(DEB_BUILD_ARCH),kfreebsd-amd64 kfreebsd-i386 hurd-i386)) -DISABLE_PTHREADS=OFF -else -DISABLE_PTHREADS=ON -endif +COMMON_CMAKE_FLAGS = \ + -DCMAKE_INSTALL_PREFIX=/usr \ + -DLIB_INSTALL_DIR=/usr/lib/$(DEB_HOST_MULTIARCH) \ + -DYAML_CPP_BUILD_TOOLS=ON \ + -DYAML_CPP_BUILD_TESTS=$(if $(filter nocheck,$(DEB_BUILD_OPTIONS)),OFF,ON) \ + -Dgtest_disable_pthreads=$(if $(filter $(DEB_HOST_ARCH_OS),kfreebsd hurd),ON,OFF) override_dh_auto_configure: dh_testdir - dh_auto_configure --builddirectory=build-static -- -DCMAKE_INSTALL_PREFIX=/usr \ - -DLIB_INSTALL_DIR=/usr/lib/$(DEB_HOST_MULTIARCH) \ --DYAML_CPP_BUILD_TOOLS=ON \ --Dgtest_disable_pthreads=$(DISABLE_PTHREADS) - dh_auto_configure --builddirectory=build-shared -- -DCMAKE_INSTALL_PREFIX=/usr \ - -DLIB_INSTALL_DIR=/usr/lib/$(DEB_HOST_MULTIARCH) \ --DYAML_BUILD_SHARED_LIBS=ON \ --DYAML_CPP_BUILD_TOOLS=ON \ --Dgtest_disable_pthreads=$(DISABLE_PTHREADS) + dh_auto_configure --builddirectory=build-static -- $(COMMON_CMAKE_FLAGS) + dh_auto_configure --builddirectory=build-shared -- $(COMMON_CMAKE_FLAGS) \ +-DYAML_BUILD_SHARED_LIBS=ON override_dh_auto_build: dh_testdir
Bug#960168: libgpg-error FTCBFS for mips64: missing lock-obj-pub.h
Source: libgpg-error
Version: 1.37-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
libgpg-error fails to cross build from source when building for mips64
(big endian), because there is no lock-obj-pub.h for mips64 in the
syscfg folder. I asked YunQiang Su to create one natively. He kindly did
and reported that it is identical to the mips64el one (which is
reasonable as all sizeofs match mips64 and the initializer is all
zeros). I've attached a patch for your convenience, but the credit goes
to YunQiang Su.
Helmut
Index: libgpg-error-1.37/src/syscfg/lock-obj-pub.mips64-unknown-linux-gnuabi64.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ libgpg-error-1.37/src/syscfg/lock-obj-pub.mips64-unknown-linux-gnuabi64.h 2020-05-10 07:06:22.249081290 +0200
@@ -0,0 +1,25 @@
+## lock-obj-pub.mips64-unknown-linux-gnuabi64.h
+## File created by gen-posix-lock-obj - DO NOT EDIT
+## To be included by mkheader into gpg-error.h
+
+typedef struct
+{
+ long _vers;
+ union {
+volatile char _priv[40];
+long _x_align;
+long *_xp_align;
+ } u;
+} gpgrt_lock_t;
+
+#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \
+0,0,0,0,0,0,0,0, \
+0,0,0,0,0,0,0,0, \
+0,0,0,0,0,0,0,0, \
+0,0,0,0,0,0,0,0}}}
+##
+## Local Variables:
+## mode: c
+## buffer-read-only: t
+## End:
+##
Index: libgpg-error-1.37/src/Makefile.am
===
--- libgpg-error-1.37.orig/src/Makefile.am 2020-02-06 18:39:06.0 +0100
+++ libgpg-error-1.37/src/Makefile.am 2020-05-10 07:07:13.932190364 +0200
@@ -59,6 +59,7 @@
syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h\
syscfg/lock-obj-pub.mips-unknown-linux-gnu.h\
syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h \
+syscfg/lock-obj-pub.mips64-unknown-linux-gnuabi64.h \
syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h \
syscfg/lock-obj-pub.nios2-unknown-linux-gnu.h \
syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h\
Index: libgpg-error-1.37/src/Makefile.in
===
--- libgpg-error-1.37.orig/src/Makefile.in 2020-02-07 13:17:38.0 +0100
+++ libgpg-error-1.37/src/Makefile.in 2020-05-10 07:07:20.160081571 +0200
@@ -537,6 +537,7 @@
syscfg/lock-obj-pub.m68k-unknown-linux-gnu.h\
syscfg/lock-obj-pub.mips-unknown-linux-gnu.h\
syscfg/lock-obj-pub.mips64el-unknown-linux-gnuabi64.h \
+syscfg/lock-obj-pub.mips64-unknown-linux-gnuabi64.h \
syscfg/lock-obj-pub.mipsel-unknown-linux-gnu.h \
syscfg/lock-obj-pub.nios2-unknown-linux-gnu.h \
syscfg/lock-obj-pub.or1k-unknown-linux-gnu.h\
Bug#957259: gdbm: ftbfs with GCC-10
Control: tags -1 + patch upstream On Fri, Apr 17, 2020 at 11:01:05AM +, Matthias Klose wrote: > /usr/bin/ld: ./libgdbmapp.a(parseopt.o):(.bss+0x8): multiple definition of > `parseopt_program_args'; gdbm_dump.o:(.data.rel.local+0x50): first defined > here > /usr/bin/ld: ./libgdbmapp.a(parseopt.o):(.bss+0x10): multiple definition of > `parseopt_program_doc'; gdbm_dump.o:(.data.rel.local+0x58): first defined here > /usr/bin/ld: ./libgdbmapp.a(parseopt.o):(.bss+0x8): multiple definition of > `parseopt_program_args'; gdbm_load.o:(.data.rel.local+0x140): first defined > here > /usr/bin/ld: ./libgdbmapp.a(parseopt.o):(.bss+0x10): multiple definition of > `parseopt_program_doc'; gdbm_load.o:(.data.rel.local+0x148): first defined > here Gentoo created a patch for us already: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1265f8991883546f19b9d3a58e6cedf1c0ce4465 Helmut
Bug#960166: mark gcc-arm-none-eabi Multi-Arch: foreign
Package: gcc-arm-none-eabi
Version: 15:8-2019-q3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:arm-trusted-firmware
arm-trusted-firmware fails to cross build from source, because it fails
running arm-none-eabi-gcc with an Exec format error. Packages containing
triplet-prefixed tools already tellwhich architecture they are operating
on, so their interface is considered architecture independent.
Accordingly, gcc-arm-none-eabi should be marked Multi-Arch: foreign.
While at it, we can also thus mark the -source package as it is a pure
data package. Please consider applying the attached patch.
Helmut
diff --minimal -Nru gcc-arm-none-eabi-8-2019-q3/debian/changelog
gcc-arm-none-eabi-8-2019-q3/debian/changelog
--- gcc-arm-none-eabi-8-2019-q3/debian/changelog2019-07-21
05:55:22.0 +0200
+++ gcc-arm-none-eabi-8-2019-q3/debian/changelog2020-05-10
06:39:00.0 +0200
@@ -1,3 +1,10 @@
+gcc-arm-none-eabi (15:8-2019-q3-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark all packages Multi-arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne Sun, 10 May 2020 06:39:00 +0200
+
gcc-arm-none-eabi (15:8-2019-q3-1) unstable; urgency=medium
[ Joaquin de Andres ]
diff --minimal -Nru gcc-arm-none-eabi-8-2019-q3/debian/control
gcc-arm-none-eabi-8-2019-q3/debian/control
--- gcc-arm-none-eabi-8-2019-q3/debian/control 2019-07-21 05:55:22.0
+0200
+++ gcc-arm-none-eabi-8-2019-q3/debian/control 2020-05-10 06:38:59.0
+0200
@@ -40,6 +40,7 @@
Package: gcc-arm-none-eabi
Architecture: any
+Multi-Arch: foreign
Depends: ${misc:Depends}, ${shlibs:Depends}, binutils-arm-none-eabi
Recommends: libnewlib-arm-none-eabi
Breaks: libnewlib-dev (<= 2.4.0.20160527-4), libstdc++-arm-none-eabi-newlib
(<= 15:6.3.1+svn253039-1+10)
@@ -50,6 +51,7 @@
Package: gcc-arm-none-eabi-source
Architecture: all
+Multi-Arch: foreign
Depends: ${misc:Depends}
Description: GCC cross compiler for ARM Cortex-R/M processors (source)
Bare metal C and C++ compiler for embedded ARM chips using Cortex-M, and
Bug#960165: nmrpflash FTCBFS: uses the build architecture pkg-config
Source: nmrpflash Version: 0.9.14-16-ge95526d-2 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs nmrpflash fails to cross build from source, because the upstream Makefile hard codes the build architecture pkg-config. Please consider applying the attached patch to make it substitutable thus making nmrpflash cross buildable. Helmut --- nmrpflash-0.9.14-16-ge95526d.orig/Makefile +++ nmrpflash-0.9.14-16-ge95526d/Makefile @@ -1,4 +1,5 @@ CC ?= gcc +PKG_CONFIG ?= pkg-config PREFIX ?= /usr/local VERSION := $(shell if [ -d .git ] && which git 2>&1 > /dev/null; then git describe --always | tail -c +2; else echo $$STANDALONE_VERSION; fi) LIBS = -lpcap @@ -6,8 +7,8 @@ LDFLAGS += $(LIBS) ifeq ($(shell uname -s),Linux) - CFLAGS += $(shell pkg-config libnl-route-3.0 --cflags) - LIBS += $(shell pkg-config libnl-route-3.0 --libs) + CFLAGS += $(shell $(PKG_CONFIG) libnl-route-3.0 --cflags) + LIBS += $(shell $(PKG_CONFIG) libnl-route-3.0 --libs) endif nmrpflash_OBJ = nmrp.o tftp.o ethsock.o main.o util.o
Bug#960131: swi-prolog: flaky autopkgtest: test set "file" ... aborted
Hi, Сб 09 мая 2020 @ 20:59 Paul Gevers : > Source: swi-prolog > Version: 8.1.29+dfsg-2 > Severity: serious > Tags: sid bullseye > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > You package has an autopkgtest, great. However, it seems to regularly > fail [1] on both amd64 and arm64. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. Please either fix the test to be more robust, or use the "flaky" > restriction for the offending test until a solution has been found. > > I copied the output at the bottom of this report. All the failing tests > that I inspected look like it. > > I'll have the migration software ignore the results of your autopkgtest > until this bug is fixed. > > Paul > > [1] https://ci.debian.net/user/britney/jobs?package=swi-prolog > > https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/5373683/log.gz > > Running test set "file" > (2329).(2332).(2335).(2338).(2341).(2343).(2346).(2348).(2350).(2353).(2357)[Thread > 1 (main) at Fri May 8 15:26:09 2020] > /build/swi-prolog-Chg12z/swi-prolog-8.1.29+dfsg/src/os/pl-os.c:1093: > deleteCanonicalDir: Assertion failed: 0 > C-stack trace labeled "assert_fail": > [0] PL_strtod() at ??:? [0x7f51fc9d36f1] > [1] __assert_fail() at ??:? [0x7f51fc991e16] > [2] PL_get_file_nameW() at ??:? [0x7f51fc9bd6a0] > [3] PL_get_file_nameW() at ??:? [0x7f51fc9bdba9] > [4] PL_get_file_nameW() at ??:? [0x7f51fc9bde80] > [5] FreeMemory() at ??:? [0x7f51fc9bee4b] > [6] PopTty() at ??:? [0x7f51fc9c0307] > [7] PL_get_file_name() at ??:? [0x7f51fc9bb48f] > [8] PL_next_solution() at ??:? [0x7f51fc907836] > [9] pl_skip_list3_va() at ??:? [0x7f51fc9465cf] > [10] pl_skip_list3_va() at ??:? [0x7f51fc946e3b] > [11] PL_initialise() at ??:? [0x7f51fc989a9c] > [12] /usr/bin/swipl(+0x10a7) [0x55ca1e9350a7] > [13] __libc_start_main() at ??:? [0x7f51fc71be0b] > [14] /usr/bin/swipl(+0x10fa) [0x55ca1e9350fa] > Aborted this should be fixed in 8.1.30+dfsg-1 currently in NEW queue. It was uploaded to experimental due to introduction of some changes to packaging, but upload to unstable will follow shortly after it gets accepted. Cheers! Lev
Bug#960164: xterm: forceBoxChars mode + cjkWidth mode renders oddly
Package: xterm
Version: 356-1
Severity: minor
Steps to reproduce:
- Launch xterm in "CJK width" mode, forcing xterm to render
box-drawing characters itself:
xterm -cjk_width +fbx
- Run the following command to print some box-drawing characters:
python3 -c 'print("a\u2500\u2500\u2500b\na\u2550\u2550\u2550b\n")'
Expected results:
In non-CJK-width mode, all the printed characters are one character-cell
wide, so the output looks like this (assuming the browser/email client
you're using also uses non-CJK-width mode):
a───b
a═══b
However, the box-drawing characters are "East-Asian Width: Ambiguous"
in Unicode, so in CJK-width mode they should occupy 2 character cells,
looking something like this:
a──b
a══b
Actual results:
a─── b
a═ ═ ═ b
For the second line, I guess xterm doesn't actually treat those box-drawing
characters specially, so it just pads them out, which is fair enough.
For the first line, though, xterm understands the box-drawing characters
should be wide, and it leaves room for them to be wide, but it draws them
narrow. At the very least, if it's going to draw them narrow it should pad
them out like the second line, but if it's going to draw them it might as
well draw them the correct width to begin with.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xterm depends on:
ii libc6 2.30-4
ii libfontconfig1 2.13.1-4
ii libfreetype62.10.1-2
ii libice6 2:1.0.9-2
ii libtinfo6 6.2-1
ii libutempter01.1.6-6
ii libx11-62:1.6.9-2+b1
ii libxaw7 2:1.0.13-1+b2
ii libxext62:1.3.3-1+b2
ii libxft2 2.3.2-2
ii libxinerama12:1.1.4-2
ii libxmu6 2:1.1.2-2+b3
ii libxpm4 1:3.5.12-1
ii libxt6 1:1.1.5-1+b3
ii xbitmaps1.1.1-2
Versions of packages xterm recommends:
ii x11-utils 7.7+5
Versions of packages xterm suggests:
pn xfonts-cyrillic
-- no debconf information
Bug#960163: nvidia-driver: x86/modules: Skipping invalid relocation
Package: nvidia-driver Version: 418.113-1 Severity: critical Justification: breaks unrelated software Dear Maintainer, I upgraded to 10.4 and on the subsequent reboot lightdm and X failed to start, and in syslog I found the following error message: 2020-05-10T03:28:57.914+00:00 vent kernel: module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1, loc 08f75532, val c1819a08 If I try to install the kernel module with `modprobe nvidia-current`, I get a similar error message. Tried dpgk-reconfigure nvidia-driver and nvidia-kernel-dkms which rebuilds the module but it makes no difference after reboot. I ran `apt purge nvidia-* libnvidia*` and found that after a reboot that I got X & lightdm running using the nouveau driver. Reinstalled nvidia-driver and back to where I started. apt/history.log tells me that the 10.4 upgrade was this nvidia-driver change: nvidia-driver:amd64 (418.74-1, 418.113-1) allan@vent:~$ cat /proc/version Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) Happy to help. /Allan -- Package-specific info: uname -a: Linux vent 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64 GNU/Linux /proc/version: Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM206GLM [Quadro M2200 Mobile] [10de:1436] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Lenovo GM206GLM [Quadro M2200 Mobile] [17aa:2251] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel modules: nvidia dmesg: Device node permissions: video:x:44:allan,mona OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 May 10 03:29 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 51 May 10 03:29 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1 lrwxrwxrwx 1 root root 50 May 10 03:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 50 May 10 03:29 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 57 May 10 03:29 /etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1 lrwxrwxrwx 1 root root 57 May 10 03:29 /etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1 lrwxrwxrwx 1 root root 54 May 10 03:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 54 May 10 03:29 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 44 May 10 03:29 /etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 lrwxrwxrwx 1 root root 44 May 10 03:29 /etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 lrwxrwxrwx 1 root root 38 May 10 03:29 /etc/alternatives/glx--libglxserver_nvidia.so -> /usr/lib/nvidia/libglxserver_nvidia.so lrwxrwxrwx 1 root root 51 May 10 03:29 /etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 42 May 10 03:29 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 May 10 03:29 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 39 May 10 03:29 /etc/alternatives/glx--nvidia-drm-outputclass.conf -> /etc/nvidia/nvidia-drm-outputclass.conf lrwxrwxrwx 1 root root 28 May 10 03:29 /etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf lrwxrwxrwx 1 root root 32 May 10 03:29 /etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf lrwxrwxrwx 1 root root 29 May 10 03:29 /etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 23 May 10 03:28 /etc/alternatives/nvidia -> /usr/lib/nvidia/current lrwxrwxrwx 1 root root 59 May 10 03:28 /etc/alternatives/nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL_nvidia.so.0 lrwxrwxrwx 1 root root 65 May 10 03:28
Bug#960162: RFS: mgba/0.8.1+dfsg-1 -- Game Boy Advance emulator
Package: sponsorship-requests
Severity: normal
Dear mentors and games team,
I have packaged the new upstream version of mgba and am looking for a
sponsor to upload it.
This is a package hijack as I have not been able to contact Sérgio (also
including him in X-D-CC here). I am interested in (co-)maintaining mgba
going forward. I'm not a member of the Games Team but I'm willing to
join if needed. I took the liberty of adding myself to Uploaders here.
There are a couple of lintian warnings about libmgba. The warnings are
not new; I think it has always been packaged this way. It's a private
library used only by mgba-{sdl,qt} and I don't think versioning the
package name is useful. I can look into patching the build system to
install it somewhere more private (i.e. /usr/lib/${D_H_M}/mgba) but it
would be great if that didn't have to block this upload.
The package is on mentors.d.n:
https://mentors.debian.net/package/mgba
https://mentors.debian.net/debian/pool/main/m/mgba/mgba_0.8.1+dfsg-1.dsc
I don't have access to the games-team git repo, therefore I forked the
repo under my own namespace. The changes are here:
https://salsa.debian.org/rtandy/mgba (master, upstream, pristine-tar)
The package builds successfully in Salsa-CI and I tested all three
frontends (sdl, qt, and retroarch).
Changes since the last upload:
* New upstream release. (Closes: #950820)
* Exclude vendored rapidjson; add Build-Depends: rapidjson-dev.
- CMakeLists.txt: don't install excluded res/licenses/rapidjson.txt.
* Exclude vendored inih; add Build-Depends: libinih-dev. (Closes: #958247)
- CMakeLists.txt: don't install excluded res/licenses/inih.txt.
* Update debian/copyright with newly added third-party licenses.
* Update Build-Depends: cmake >= 3.1 (since 0.7.0).
* Add Build-Depends: libavfilter-dev to re-enable GIF/Video recording
feature.
* Update Standards-Version to 4.5.0. No changes needed.
* Drop -Wl,--as-needed as this is now the default.
* Update to debhelper compat level 13.
- libretro-mgba.install: Use built-in substitution instead of dh-exec.
- Update *.install and *.manpages to install from debian/tmp.
- Add debian/not-installed.
* Drop patch 01_fix-about-strings. The patch was out of date and the git
revision info is not required since we build from a release tarball.
* Add debian/gitlab-ci.yaml for CI build.
* Add myself to Uploaders.
Thank you,
Ryan
Bug#960160: Acknowledgement (mutt: stack overflow DoS fixed in 1.14)
Relevant upstream commit is 758d406ede97ad627ab804ab049e77396d18746c https://gitlab.com/muttmua/mutt.git
Bug#960161: libgpg-error: add mips64(eb) lock-obj-pub.h file
Package: src:libgpg-error
The lock-obj-pub.mips64-unknown-linux-gnuabi64.h has the same content with
mips64el one, beside the header comments
## lock-obj-pub.mips64-unknown-linux-gnuabi64.h
## File created by gen-posix-lock-obj - DO NOT EDIT
## To be included by mkheader into gpg-error.h
typedef struct
{
long _vers;
union {
volatile char _priv[40];
long _x_align;
long *_xp_align;
} u;
} gpgrt_lock_t;
#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0, \
0,0,0,0,0,0,0,0}}}
##
## Local Variables:
## mode: c
## buffer-read-only: t
## End:
##
Bug#960160: mutt: stack overflow DoS fixed in 1.14
Package: mutt Version: 1.10.1-2.1 Severity: important Tags: upstream, security mutt 1.14 fixes a stack overflow when parsing a specially-crafted message.
Bug#960158: libemail-mime-contenttype-perl: denial-of-service via OOM
Package: libemail-mime-contenttype-perl Version: 1.022-1 Severity: important Tags: upstream, security It's possible to easily craft a message which triggers out-of-memory error. Upstream has been notified and working on the issue.
Bug#960159: libgmime-3.0-0: DoS fixes available upstream
Package: libgmime-3.0-0 Version: 3.2.1-1 Severity: important Tags: upstream, security gmime 3.2.5+ is needed to fix deep recursion and stack overflows Excessive parts and CPU cycles needs commit 53449a25fa46e6a0333d1919ee4f3778c1789d53 in https://github.com/jstedfast/gmime.git No release as of 3.2.7 has that, yet. I expect there's also old gmime-2.x packages affected, but don't have time/energy to check myself.
Bug#929157: Upstream fix
Hi everyone, sorry for the double post, but the potential cause for a similar error and a simple patch for that has been found upstream, see [1]. In the case I have here (multiple robots with different domains and a mostly empty global config), that patch only helped with fixing the help page without the hotfix from my previous message and not the random occurences elsewhere, but when I also added a "wwsympa_url https://DOMAIN.TLD/sympa; of one of the domains to the _global_ config as was recommended somewhere else in [1], the problem went away completely and has not appeared again since. Before, wwsympa_url was set to "sympa" for some inexplicable reason. Kind regards Aldo [1] https://github.com/sympa-community/sympa/issues/876#issuecomment-589950136
Bug#960157: ldc -flto doesn't find LLVMgold.so automatically
Package: ldc Version: 1:1.20.1-1 Severity: normal Dear Maintainer, $ dpkg -L llvm-10-dev | grep gold /usr/lib/llvm-10/lib/LLVMgold.so $ time ldc2 -mcpu=native --flto=full -d-version=benchmark -of=bench_ldc2 bench.d Error: The LLVMgold.so plugin (needed for LTO) was not found. You can specify its path with -flto-binary=. $ Passing -flto-binary=/usr/lib/llvm-10/lib/LLVMgold.so to the ldc2 solves the issue, but I find it weird it is not done automatically. Regards, Witold -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ldc depends on: ii libc6 2.30-7 ii libgcc-s1 10.1.0-1 ii libllvm9 1:9.0.1-12 ii libphobos2-ldc-shared-dev 1:1.20.1-1 ii libstdc++6 10.1.0-1 ii zlib1g 1:1.2.11.dfsg-2 ldc recommends no packages. ldc suggests no packages. -- no debconf information
Bug#959913: autopkgtest: please clarify breaks-testbed
On Wed, May 06, 2020 at 11:30:50PM +0200, Andreas Beckmann wrote: > Source: autopkgtest > Version: 5.13.1 > Severity: normal > > Hi, > > I have some problems understanding the breaks-testbed restriction: > > breaks-testbed > The test, when run, is liable to break the testbed system. This > includes causing data loss, causing services that the machine is > running to malfunction, or permanently disabling services; it does > not include causing services on the machine to temporarily fail. > > AIUI the testbed system is a throwaway chroot/container/virtual machine/... > So how can breakage (e.g. rm /bin/ls) be persistent? Or is it possible > to run subsequent tests in the same testbed instance? as an optimization autopkgtest reuses testbeds across tests if the dependencies of the later test are a superset of the dependencies of the earlier ones, unless breaks-testbed is specified, in which case the testbed is discarded after the test. > Or does that mean the test can affect the host system? (E.g. from a > chroot with root access killing all processes with even PIDs, including > processes on the host.) that depends on specifics of the tests and of the virtualisation backend you are using. note that the very next paragraph says: When this restriction is present the test will usually be skipped unless the testbed's virtualisation arrangements are sufficiently powerful, or alternatively if the user explicitly requests. > BTW, what does "machine" denote in the quoted paragraph? the host machine. Do you have a wording suggestion to make it more clear? signature.asc Description: PGP signature
Bug#960154: UDD table no longer populated
clone 960154 -1 retitle 960154 lintian: please provide a stable, parsable output reassign -1 qa.debian.org user qa.debian@packages.debian.org usertags -1 udd block -1 by 960154 retitle -1 udd.debian.org: change the lintian importer to use the new export file thanks On Sat, May 09, 2020 at 11:37:52PM +, Jelmer Vernooij wrote: > Not sure whether to file this against UDD or lintian or detagtive; filing it > against lintian since it changed more recently and I suspect that's related. It was caused by a change in lintian, but it will have to be fixed in both lintian and udd. > For a while now, the UDD tables for lintian have been empty. They were > previously populated with lintian data. This was discussed recently in #-qa. The frontend rewrite lechner did, completely removed the logs.gz that was used by udd (and not only udd, I fear…) I believe the first step is going to have lintian decide on a nice machine-parsable (text!) format and publish that; then udd will adopt its importer. (PS, lechner: I went looking in lindsay to see if there was already a replacement for the logs.gz file, and I noticed that the files under /srv/lintian.debian.org/ are all with mixed ownership lintian:lintian and lechner:lintian that might not be a issue right now since you are the only one working on that part of lintian, but it's not quite nice to any other team member in the future, even if the umask seems to allow all team members to edit those files; I recommend you take on the habit to deploy that stuff entirely under the role account.) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#960155: ITP: liburl-encode-xs-perl -- XS implementation of URL::Encode
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: liburl-encode-xs-perl Version : 0.03 Upstream Author : Christian Hansen * URL : https://metacpan.org/release/URL-Encode-XS * License : Artistic or GPL-1+ Programming Lang: Perl Description : XS implementation of URL::Encode URL::Encode::XS is an XS implementation of the URL::Encode module. The main URL::Encode package will use this package automatically if it can find it. Do not use this package directly, use URL::Encode instead. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#960154: UDD table no longer populated
Package: lintian.debian.org Severity: normal Not sure whether to file this against UDD or lintian or detagtive; filing it against lintian since it changed more recently and I suspect that's related. For a while now, the UDD tables for lintian have been empty. They were previously populated with lintian data. (Independently of that, I'm curious if there are other avenues of getting this information that don't involve UDD)
Bug#960153: ca-certificates-java: Failed to install ca-certificates-java on Beagle Bone Black
Package: ca-certificates-java Version: 20190405 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * I tried to install ca-certificates-java * apt get install -y ca-certificates-java * I got this error: Could not load hsdis-arm.so; library not loadable; PrintAssembly is disabled installed ca-certificates-java package post-installation script subprocess returned error exit status 134 full apt log can be found here: https://ipfs.io/ipfs/QmYyixmCD9VAugY1zLf88UibjXPnyq9mRmDok1sFkSNEjC The referenced log hs_err_pid1975.log can be found here: https://ipfs.io/ipfs/QmURBmFwFVF3Jo9iqCjCdAgHvoBaUdRD4QfptXjBeprcgW * I expected the package ca-certificates-java to be installed *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 4.19.0-9-armmp (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ca-certificates-java depends on: ii ca-certificates 20190110 ii default-jre-headless [java8-runtime-headless] 2:1.11-71 ii libnss3 2:3.42.1-1+deb10u2 ii openjdk-11-jre-headless [java8-runtime-headless] 11.0.7+10-3~deb10u1 ca-certificates-java recommends no packages. ca-certificates-java suggests no packages. -- no debconf information
Bug#960152: linux-image-5.6.0-1-arm64: Enable compressed modules
Package: src:linux Version: 5.6.7-1 Severity: wishlist The on-disk kernel modules take up a significant amount of the package installation size, and most modules aren't actively used on any given system. In debian-installer, the "on-disk" modules take up space in ram during the installation. From the linux Makefile: # CONFIG_MODULE_COMPRESS, if defined, will cause module to be compressed # after they are installed in agreement with CONFIG_MODULE_COMPRESS_GZIP # or CONFIG_MODULE_COMPRESS_XZ. I'm not sure how to enable it; I don't see it mentioned in any Kconfig files. It does appear possible to manually compress the individual .ko files as an alternative method, if that is somehow more flexible. The kmod utility supports xz compressed modules since version 25-1 (26-1 is present in buster, the current debian stable release). Unfortunately, gzip isn't supported in kmod yet (patch submitted in #960149). What other software needs support enabled in order to support on-disk compressed modules in the linux kernel packages? live well, vagrant signature.asc Description: PGP signature
Bug#960151: petsc: FTBFS during arch:all build: petscrules: No such file or directory
Package: petsc Version: 3.13.0+dfsg2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, petsc/experimental FTBFS during the arch:all build (on amd64): Completed test examples make[2]: Leaving directory '/build/petsc-3.13.0+dfsg2' make[2]: Entering directory '/build/petsc-3.13.0+dfsg2' /build/petsc-3.13.0+dfsg2/lib/petsc/conf/rules:788: /build/petsc-3.13.0+dfsg2/x86_64-linux-gnu-real/lib/petsc/conf/petscrules: No such file or directory make[3]: *** No rule to make target '/build/petsc-3.13.0+dfsg2/x86_64-linux-gnu-real/lib/petsc/conf/petscrules'. Stop. gmakefile:5: x86_64-linux-gnu-real/lib/petsc/conf/petscvariables: No such file or directory make[2]: *** [GNUmakefile:17: /build/petsc-3.13.0+dfsg2/x86_64-linux-gnu-real/include/petscconf.h] Error 2 make[2]: *** Waiting for unfinished jobs /build/petsc-3.13.0+dfsg2/lib/petsc/conf/rules:788: /build/petsc-3.13.0+dfsg2/x86_64-linux-gnu-real/lib/petsc/conf/petscrules: No such file or directory make[3]: *** No rule to make target '/build/petsc-3.13.0+dfsg2/x86_64-linux-gnu-real/lib/petsc/conf/petscrules'. Stop. make[2]: *** [GNUmakefile:17: /build/petsc-3.13.0+dfsg2/x86_64-linux-gnu-real/lib/petsc/conf/petscvariables] Error 2 /build/petsc-3.13.0+dfsg2/lib/petsc/conf/rules:788: /build/petsc-3.13.0+dfsg2/x86_64-linux-gnu-real/lib/petsc/conf/petscrules: No such file or directory make[3]: *** No rule to make target '/build/petsc-3.13.0+dfsg2/x86_64-linux-gnu-real/lib/petsc/conf/petscrules'. Stop. make[2]: *** [GNUmakefile:17: x86_64-linux-gnu-real/lib/petsc/conf/petscvariables] Error 2 make[2]: Leaving directory '/build/petsc-3.13.0+dfsg2' make[1]: *** [debian/rules:265: override_dh_auto_test] Error 2 make[1]: Leaving directory '/build/petsc-3.13.0+dfsg2' make: *** [debian/rules:136: build-indep] Error 2 Andreas petsc_3.13.0+dfsg2-1_indep.log.gz Description: application/gzip
Bug#932779: lirc: Fails to install due to missing /etc/lirc/lirc_options.conf
Control: tag -1 patch
Hi Sebastien,
thanks for the analysis!
On Fri, 8 May 2020 11:16:09 +0200 Sebastien Bacher
wrote:
> There are a few possible options there now that I can see
> - restore the .postinst 'test -e /etc/lirc/$f || cp /etc/lirc/${f}.dist
> /etc/lirc/$f || :' calls
But we want to get rid of that mess!
> - reverse the logic, and ship the conffile with the normal name but move
Yep, we want that
> old existing pre 0.10 ones to .old or something in the preinst
let's just delete them if
* dpkg does not know about them, and
* they match a known shipped version
> - restore the 'prompt for conffile change even when no change' bug, it's
> not ideal but better than just segfaulting and failing installation
and fall back to prompting only if the file has likely been modified
That is best explained in more detail as patches ;-)
Since I'm the one most likely to file more prompting bugs, I've
implemented that and quickly tested it in a chroot for the most
interesting upgrade paths.
I'm offering to NMU that.
If someone else is going to upload the fix, please don't bunde it with
stuff not appropriate for buster.
Note that we need this fix in buster, too, and to avoid doing fany
things with the version numbers for the upgrade paths, we should rebuild
0.10.1-6.2 as 0.10.1-6.2~deb10u1 (with the python3.8 patch disabled, the
linux 4.18 patch should be OK for buster).
Andreas
>From 3a77ccb1a928329f2a3540a300fcf55cb1d7e32e Mon Sep 17 00:00:00 2001
From: Andreas Beckmann
Date: Sat, 9 May 2020 23:06:55 +0200
Subject: [PATCH 1/3] Revert "Revert "Do not install conffiles in a dummy
location""
---
debian/changelog| 8
debian/lirc.maintscript | 4
debian/rules| 4
3 files changed, 12 insertions(+), 4 deletions(-)
create mode 100644 debian/lirc.maintscript
diff --git a/debian/changelog b/debian/changelog
index f30a620..9d47679 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+lirc (0.10.1-6.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Revert "Revert "Do not install conffiles in a dummy location""
+(0.10.1-5.2).
+
+ -- Andreas Beckmann Sat, 09 May 2020 23:05:43 +0200
+
lirc (0.10.1-6.1) unstable; urgency=medium
* Non-maintainer upload.
diff --git a/debian/lirc.maintscript b/debian/lirc.maintscript
new file mode 100644
index 000..f26aaa2
--- /dev/null
+++ b/debian/lirc.maintscript
@@ -0,0 +1,4 @@
+mv_conffile /etc/lirc/lircd.conf.dist /etc/lirc/lircd.conf 0.10.1-5.1~
+mv_conffile /etc/lirc/lircmd.conf.dist /etc/lirc/lircmd.conf 0.10.1-5.1~
+mv_conffile /etc/lirc/irexec.lircrc.dist /etc/lirc/irexec.lircrc 0.10.1-5.1~
+mv_conffile /etc/lirc/lirc_options.conf.dist /etc/lirc/lirc_options.conf 0.10.1-5.1~
diff --git a/debian/rules b/debian/rules
index fc2b39d..84787ef 100755
--- a/debian/rules
+++ b/debian/rules
@@ -42,10 +42,6 @@ ifeq ($(DEB_BUILD_ARCH_OS), linux)
endif
# Temporary postinstall 0.9.4 script.
cp debian/lirc-old2new debian/tmp/usr/share/lirc
- # Don't overwrite existing config files.
- for f in lircd.conf lircmd.conf irexec.lircrc lirc_options.conf; do \
- mv debian/tmp/etc/lirc/$$f debian/tmp/etc/lirc/$$f.dist; \
- done
override_dh_auto_test:
ifneq "nocheck" "$(findstring nocheck,$(DEB_BUILD_OPTIONS))"
--
2.20.1
>From 0da18e85905411d0c6b2b6fda93a6689809aa493 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann
Date: Sat, 9 May 2020 23:16:03 +0200
Subject: [PATCH 2/3] rm_conffile /etc/lirc/*.dist, don't mv_conffile
---
debian/changelog| 3 +++
debian/lirc.maintscript | 8
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 9d47679..b4af7b6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,9 @@ lirc (0.10.1-6.2) UNRELEASED; urgency=medium
* Non-maintainer upload.
* Revert "Revert "Do not install conffiles in a dummy location""
(0.10.1-5.2).
+ * d/lirc.maintscript: rm_conffile /etc/lirc/*.dist because they are most
+likely unmodified, don't mv_conffile them to =~ s/\.dist// to avoid
+clashes with possibly modified files.
-- Andreas Beckmann Sat, 09 May 2020 23:05:43 +0200
diff --git a/debian/lirc.maintscript b/debian/lirc.maintscript
index f26aaa2..d00d265 100644
--- a/debian/lirc.maintscript
+++ b/debian/lirc.maintscript
@@ -1,4 +1,4 @@
-mv_conffile /etc/lirc/lircd.conf.dist /etc/lirc/lircd.conf 0.10.1-5.1~
-mv_conffile /etc/lirc/lircmd.conf.dist /etc/lirc/lircmd.conf 0.10.1-5.1~
-mv_conffile /etc/lirc/irexec.lircrc.dist /etc/lirc/irexec.lircrc 0.10.1-5.1~
-mv_conffile /etc/lirc/lirc_options.conf.dist /etc/lirc/lirc_options.conf 0.10.1-5.1~
+rm_conffile /etc/lirc/lircd.conf.dist 0.10.1-6.2~
+rm_conffile /etc/lirc/lircmd.conf.dist 0.10.1-6.2~
+rm_conffile /etc/lirc/irexec.lircrc.dist 0.10.1-6.2~
+rm_conffile /etc/lirc/lirc_options.conf.dist 0.10.1-6.2~
--
2.20.1
>From f4ba5e27e9c9a79832b6413afa0822263126c51e Mon Sep 17 00:00:00 2001
From: Andreas Beckmann
Date: Sat, 9 May
Bug#954020: buster-pu: package zipios++/0.1.5.9+cvs.2007.04.28-10+deb10u1
Hi, On 20-05-09 14:02:21, François Mazen wrote: > Adam or you, could you please upload it? I'm happy to upload this, but I'm unable to do a review on my own. Dear SRMs, if that's acceptable in this case, please let me know. Cheers, Georg
Bug#960150: gdc-10 / libphobos 2.76 core.cpuid.{cores,threads}PerCPU() returns wrong value
Package: gdc-10
Version: 10.1.0-1
Severity: normal
Dear Maintainer,
import std.stdio;
import core.cpuid;
void main() {
writefln("CPU: threads_per_cpu=%d; cores_per_cpu=%d; ht=%s; processor=%s",
threadsPerCPU(), coresPerCPU(), hyperThreading(), processor());
}
# Using gdc-10 (10.1.0-1) and ligphobos1 (10.1.0-1)
CPU: threads_per_cpu=1; cores_per_cpu=32; ht=false; processor=AMD Ryzen
Threadripper 2950X 16-Core Processor
# Using ldc (1:1.20.1-1) and libphobos2-ldc-shared-dev (= 1:1.20.1-1):
CPU: threads_per_cpu=32; cores_per_cpu=16; ht=true; processor=AMD Ryzen
Threadripper 2950X 16-Core Processor
As can be seen gdc-10 (and gdc-9 too) returns wrong values.
I tried various optimization options, different -mcpu, static phobos
linking, etc. and they don't change it.
I am running on a bare hardware (no kvm, Xen or qemu involved) with
kernel Linux 5.2.17.
For reference:
$ lscpu
Architecture:x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 43 bits physical, 48 bits virtual
CPU(s): 32
On-line CPU(s) list: 0-31
Thread(s) per core: 2
Core(s) per socket: 16
Socket(s): 1
NUMA node(s):2
Vendor ID: AuthenticAMD
CPU family: 23
Model: 8
Model name: AMD Ryzen Threadripper 2950X 16-Core Processor
Stepping:2
Frequency boost: enabled
CPU MHz: 2431.075
CPU max MHz: 3500.
CPU min MHz: 2200.
BogoMIPS:6999.26
Virtualization: AMD-V
L1d cache: 512 KiB
L1i cache: 1 MiB
L2 cache:8 MiB
L3 cache:32 MiB
NUMA node0 CPU(s): 0-7,16-23
NUMA node1 CPU(s): 8-15,24-31
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled
via prctl and s
eccomp
Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and
__user pointer sanit
ization
Vulnerability Spectre v2:Mitigation; Full AMD retpoline, IBPB
conditional, STIBP disab
led, RSB filling
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht
syscall nx mmxext fxs
r_opt pdpe1gb rdtscp lm constant_tsc rep_good
nopl nonstop_ts
c cpuid extd_apicid amd_dcm aperfmperf pni
pclmulqdq monitor
ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes
xsave avx f16c
rdrand lahf_lm cmp_legacy svm extapic
cr8_legacy abm sse4a mi
salignsse 3dnowprefetch osvw skinit wdt tce
topoext perfctr_c
ore perfctr_nb bpext perfctr_llc mwaitx cpb
hw_pstate sme ssb
d sev ibpb vmmcall fsgsbase bmi1 avx2 smep
bmi2 rdseed adx sm
ap clflushopt sha_ni xsaveopt xsavec xgetbv1
xsaves clzero ir
perf xsaveerptr arat npt lbrv svm_lock
nrip_save tsc_scale vm
cb_clean flushbyasid decodeassists pausefilter
pfthreshold av
ic v_vmsave_vmload vgif overflow_recov succor
smca
$
$ numactl -s
policy: default
preferred node: current
physcpubind: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
25 26 27 28 29 30 31
cpubind: 0 1
nodebind: 0 1
membind: 0 1
$
$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 0 size: 64371 MB
node 0 free: 15527 MB
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31
node 1 size: 64497 MB
node 1 free: 678 MB
node distances:
node 0 1
0: 10 16
1: 16 10
$
$ nproc
32
$
$ getconf -a | grep PROCESSORS
_NPROCESSORS_CONF 32
_NPROCESSORS_ONLN 32
$
$ cpuid
CPU 0:
vendor_id = "AuthenticAMD"
version information (1/eax):
processor type = primary processor (0)
family = 0xf (15)
model = 0x8 (8)
stepping id = 0x2 (2)
extended family = 0x8 (8)
extended model = 0x0 (0)
(family synth) = 0x17 (23)
(model synth) = 0x8 (8)
(simple synth) = AMD Ryzen (Pinnacle Ridge PiR-B2) [Zen+], 12nm
miscellaneous (1/ebx):
process local APIC physical ID = 0x0 (0)
cpu
Bug#959481: alpine: does not connect with TLS to smtp/imap server
On Sun, 3 May 2020, Unit 193 wrote: Thank you for including logs! The important line from the latter is as follows: sslfailure: host=imap.otenet.gr reason=SSL negotiation failed Unfortunately that's not a lot of detail, so it's useful to use testssl or `openssl s_client` to check what's going on here. From that, I got routines:ssl_choose_client_version:unsupported protocol:../ssl/statem/statem_lib.c:1929: as well as testssl noting a few things that weren't favorable, such as a SHA1 cert, offering SSLv3 and TLSv1, etc. Alpine had a bunch of changes with regards to TLS in the last release, namely for me it added SNI support, and I wonder if it's now more strict. I do not know what changes Debian makes to the compilation of Alpine, or to Openssl, and both are relevant here. The server at imap.otenet.gr supports as the highest protocol for encryption TLSv1. Today the minimum that most servers support is TLSv1_1, and so you find commonly that TLSv1_2 is also used. Rarely you find TLSv1_3, but that is the direction in which we are going. On the other hand Alpine will support encryptions protocol as the library that was used to compile supports. That is the exculpatory part in Alpine. So you have to look at the encryption protocols in the underlying openssl library. If that library was compiled without support for TLSv1, then no application that needs support for TLSv1 will fail. again, this is because of the library, not the program. Many linux distributors already distribute libraries that do not support SSLv3, even though the source code that they use to build those libraries supports such version of SSL. This is a choice distributors make, not the person compiling Alpine. Maybe Debian builds their openssl only supporting TLSv1_1 and above. I do not know, but that is something to investigate. Finally, there is a way to protect alpine users directly. Any Alpine user can disable encryption protocols that they do not wish to use. So, for example, if Debian distributed a version of openssl that supported SSLv3, a user that feels that this is insecure could disable completely the negotiation of said protocol, and make the connection fail (in the way that this connection is failing) after the TLSv1 negotiation fail. In other words, one could make the negotiation fail even when both Alpine (through openssl) and the server support SSLv3. This is configured in the variable Encryption Protocol Range = which is an interval of encryption protocols that Alpine will try. The default is "no_min,no_max", meaning that openssl should try to use any protocol that is compiled into openssl, starting with the highest and continuing down, until it finds one that works for the server and openssl. All Alpine does in this case is to tell openssl what not to try. This could also be a source of conflict, because the default value of this option can be modified at compilation time (e.g.: Debian can disable some protocols from the beginning, and I would advise Debian not to do that, but let the user choose). You can learn more about this variable by pressing M S C and once you find it, read its help text. So, unless the person who built alpine played with the default for this variable, or the person reporting this bug also played with this variable, the answer here is that both openssl and the server were compiled with disjoint versions of encryption protocols, and none of them support the one the other supports. Hence Alpine fails to connect. -- Eduardo
Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4
On 2020.05.09 22:20, Ben Hutchings wrote: On Thu, 2020-05-07 at 14:23 +0100, Pete Batard wrote: [...] I specifically designed the patch I submitted for easy review and integration, because there are missing elements from 4.x that are present in 5.x, that we have to compensate for. I would rather not have to split it, especially as I believe it should be included as a matter of priority and we're simply adding delays. I personally find it much easier to review backports in this form, and it is the usual practice in Debian to backport changes in this form where possible. Then you should have asked for that 3 months ago. Sorry but that mistakes of not following up on the patch I submitted in a reasonable timeframe, or understanding its context and priority level is entirely on you. I have tried all the means I knew to bring attention to this patch for weeks that followed its submission (including posting about it in various Debian mailing lists, including arm64 and debian-release), and nothing happened, and especially nobody provided any inkling about the submission needing to be split, so you genuinely have exhausted all of the good will I had on that topic. Moreover, if you are taking my refusal to split the patch as an excuse not to produce your own effort to include it in the next release, then you are simply corroborating the idea I have established that Debian appears to have no clue about the level of importance it should actually allocate to the underlying problem this is attempting to solve, and, furthermore, that it may simply be looking for a way out of a situation it mishandled. In other words, I am waiting to see a real concerted effort on your side before I decide whether I am willing to contribute any further, and insistance on asking me to perform work that, if you understood the actual severity of the situation, you should be more than willing to perform yourself as a matter of urgency, simply indicates that you still haven't understood the nature of the underlying situation. As a direct result of that, I have good reasons to estimate that further involvement from my side is simply not worth the trouble, because it appears that you are still going to be bouncing, delaying or mishandling the ability for RPi4 users to install Debian from vanilla Debian ISOs. Therefore either you understand the importance of the problem, and are willing to perform the work required to reorganize the submission according to your *preferences*. Or you continue to hint that you don't, and instead try to place the blame on someone from whom you have long exhausted any willingness to contribute to something they have good reasons to believe, from the continued unwillingness to take the necessary actions on your side, is most likely going to amount to *another* completely wasted effort. In other words, I will need to see some real good will from Debian in the matter of trying to salvage the current RPi4 situation before I decide to get involved in trying to contribute again. Thus, in case this was not clear, let me be explicit in saying that you are not going to see any further contribution from me until you have made some visible effort to remedy that. Regards, /Pete
Bug#960149: kmod: Enable support for gzip compressed kernel modules
Package: kmod Version: 26-1 Severity: wishlist Tags: patch Please consider enabling support for gzip compressed modules. I see xz-compressed modules are supported, which is definitely useful, but gzip compressed modules are also widely used, and have different CPU vs. storage space tradeoffs. Patch attached. live well, vagrant From 45f30b6510e1275b4261cdb08ec0644e8defb31c Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sat, 9 May 2020 14:43:20 -0700 Subject: [PATCH] Enable support for gzip-compressed modules. Add Build-Depends on zlib1g-dev. --- debian/control | 2 +- debian/rules | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 0abc91d..9c8a015 100644 --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Section: admin Priority: important Maintainer: Marco d'Itri Build-Depends: debhelper-compat (= 12), liblzma-dev, libssl-dev, xsltproc, - autoconf, automake, libtool, gtk-doc-tools + autoconf, automake, libtool, gtk-doc-tools, zlib1g-dev Standards-Version: 4.4.0.1 Rules-Requires-Root: no Vcs-Git: https://salsa.debian.org/md/kmod.git diff --git a/debian/rules b/debian/rules index b40ac59..4345679 100755 --- a/debian/rules +++ b/debian/rules @@ -21,6 +21,7 @@ CONFFLAGS_deb = $(CONFFLAGS) \ --enable-gtk-doc \ --with-openssl \ --with-xz \ + --with-zlib \ --enable-debug CONFFLAGS_udeb = $(CONFFLAGS) \ $(subst -O2,-Os -fomit-frame-pointer,$(shell DEB_BUILD_MAINT_OPTIONS="hardening=-all" \ -- 2.20.1 signature.asc Description: PGP signature
Bug#959399: libreoffice-common: Using libreoffice results in many AppArmor "ALLOWED" log messages in kernel syslog
On Sat, May 09, 2020 at 05:16:04PM -0500, Evan Harris wrote:
> > No, $HOME isn't. $HOME in your case is "/raid/home/user/.
>
> Actually it's not. In the particular example I gave logs for, $HOME is
> /home/user. It just happens that /home is a symlink to /raid/home.
Aha...
> > > How should the configuration be changed for multiple home directories
> > > being
> > > stored and mounted in multiple locations?
> >
> > Erm, what?
> >
> > I mentioned
> >
> > @{libo_user_dirs} = @{HOME} /mnt /media
>
> I don't know where that is configured. Where would I find that?
This is cut'n'paste the libreoffice (well
/usr/lib/libreoffice/program/soffice.bin) apparmor profile.
> > Wouldn't be surprised if @{HOME} (documented as "all homedirs") actually
> > means /home/** and thus wouldn't allow /raid/home/**.
> >
> > I'd first try adding /raid/home there, obviously?
>
> Where is "there"?
Of course in the apparmor profile.
(/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin)
BTW: This is not a apparmor or configuration support, this is for
tracking bugs ;-)
Regards,
Rene
Bug#959399: libreoffice-common: Using libreoffice results in many AppArmor "ALLOWED" log messages in kernel syslog
No, $HOME isn't. $HOME in your case is "/raid/home/user/.
Actually it's not. In the particular example I gave logs for, $HOME is
/home/user. It just happens that /home is a symlink to /raid/home.
How should the configuration be changed for multiple home directories being
stored and mounted in multiple locations?
Erm, what?
I mentioned
@{libo_user_dirs} = @{HOME} /mnt /media
I don't know where that is configured. Where would I find that?
Wouldn't be surprised if @{HOME} (documented as "all homedirs") actually
means /home/** and thus wouldn't allow /raid/home/**.
I'd first try adding /raid/home there, obviously?
Where is "there"?
Bug#959940: hdmf FTBFS with h5py 2.10.0
Package: python3-h5py
Version: 2.10.0-7
Followup-For: Bug #959940
Please see https://github.com/hdmf-dev/hdmf/issues/343#issuecomment-625972582
for possibly more info:
@tillea @yarikoptic the debian port contains this code in
h5py_2.10.0-7.debian/debian/wrapper_module/h5py/__init__.py
from sys import modules as sys_modules
# [snip]
# make generic h5py module behaviour the same as specific builds
# by importing public and weak internal symbols (single _underscore)
api = [ k for k in _h5py.__dict__.keys() if not k.startswith('__') and
not k.endswith('__') ]
this_module=sys_modules[__name__]
for key in api:
# "imports" symbols (makes them accessible)
setattr(this_module,key,getattr(_h5py,key))
# rename symbols as properties of toplevel h5py module
sys_modules['h5py.{}'.format(key)] = getattr(_h5py,key)
Since remove_deprecated_highlevel_module_2f41c78.patch is not
applied, the api list includes 'highlevel' so then
sys.modules['h5py.highlevel'] is set to h5py.highlevel. This is
problematic
because sys.modules is traversed in the context manager for
unittest.TestCase.assertWarns and getattr is called on it, but
h5py.highlevel
is intentionally lazily imported by h5py, I think, because it is
deprecated. So
one solution might be to apply the patch. Another might be to add and
not k ==
'highlevel' to the line that sets api above.
In the above "patch" is the remove_deprecated_highlevel_module_2f41c78.patch
patch
which was disabled in
commit ed17e72dc2fa47f590b78632401512546d3d3e1e
Author: Drew Parsons
Date: Sun Apr 5 18:31:33 2020 +0800
disable upstream patches and update drop_deprecation_tests.patch
aid HDF5 transition by giving bitshuffle more time to update
(see Bug#955456)
changes to drop_deprecation_tests.patch needed to pass h5py
tests
diff --git a/debian/patches/series b/debian/patches/series
index 6753f8e..9f3468d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -7,8 +7,8 @@ fix_2.10_docs.patch
hdf5_pkgconfig.patch
build_flavour.patch
stop_circular_dep.patch
-drop_deprecated_dtype_6a77b91.patch
-remove_deprecated_highlevel_module_2f41c78.patch
-file_default_read_5e71c49.patch
+#drop_deprecated_dtype_6a77b91.patch
+#remove_deprecated_highlevel_module_2f41c78.patch
+#file_default_read_5e71c49.patch
drop_deprecation_tests.patch
tests_as_local_build.patch
Cheers,
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100,
'unstable-debug'), (100, 'stable-updates'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.0-1-amd64 (SMP w/12 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 python3-h5py depends on:
ii python3-h5py-serial 2.10.0-7
python3-h5py recommends no packages.
Versions of packages python3-h5py suggests:
pn python-h5py-doc
-- no debconf information
Bug#959399: libreoffice-common: Using libreoffice results in many AppArmor "ALLOWED" log messages in kernel syslog
Hi,
On Sat, May 09, 2020 at 03:32:48PM -0500, Evan Harris wrote:
> I guess I don't understand what needs to be changed. $HOME is /home, which
> is where the local users homes are. There are additional mount points
No, $HOME isn't. $HOME in your case is "/raid/home/user/.
> (/raid, and one other) that hold additional network mounts of remotely store
> users' home directories.
But you run as a remote user?
name="/raid/home/user/.config/libreoffice/4/user/GpDXp7
suggests so.
> How should the configuration be changed for multiple home directories being
> stored and mounted in multiple locations?
Erm, what?
I mentioned
@{libo_user_dirs} = @{HOME} /mnt /media
Wouldn't be surprised if @{HOME} (documented as "all homedirs") actually
means /home/** and thus wouldn't allow /raid/home/**.
I'd first try adding /raid/home there, obviously?
Regards,
Rene
Bug#960148: RFP: hstspreload -- Chromium HSTS Preload list as a Python package
Package: wnpp Severity: wishlist * Package name: hstspreload Version : 2020.5.5 Upstream Author : Seth Michael Larson * URL : https://github.com/sethmlarson/hstspreload * License : BSD-3 Programming Lang: Python Description : Chromium HSTS Preload list as a Python package It is used by httpx (althought it's not a hard requirement, but nice-to-have) Please consider package this under DPMT
Bug#951551: ITP: httpx -- fully featured HTTP client, with sync and async APIs, and support for both HTTP/1.1 and HTTP/2
> > please hold, i'll have it uploaded to NEW withing 15 days from today. httpx requires a newer version of python3-rfc3986 than we have in the archived; so until that's upgraded i cant continue with this work. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#960147: python-rfc3986: please upgrade to a later release (ideally 1.4.0 released on April 9th)
Source: python-rfc3986 Severity: important Hello, httpx requires a version of python-rfc3986 that contains https://github.com/python-hyper/rfc3986/pull/50 , which appears to be first released with 1.3.0. There's also 1.4.0 released recently, so ideally update to that version? Without with this update, i cannot continue packaging httpx, hence the severity. Regards, Sandro -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#959113: guava-libraries: Please update to recent upstream (v25.1 or later)
Le 09/05/2020 à 22:33, Olek Wojnar a écrit : > Ok, update. I can confirm that Bazel does not build with Guava v19. [1] > It looks like `com.google.common.graph.GraphBuilder` is missing, along > with other classes. Indeed, GraphBuilder was added to Guava 20, and Streams to Guava 21. Thank you for checking. > Great, thanks! I'll try those! Are you planning to migrate either to > unstable in the near future? Yes, I was waiting for your confirmation before uploading to unstable. > Also, is it possible to concurrently install multiple versions of guava > like we do with some C++ libraries? Sorry if that's a naive question but > I'm not exactly an expert with Java and how we package it in Debian. I > know I've had similar issues in the past with C++ libraries and solved > them by packaging both versions so that I was breaking neither old nor > new packages that depended on them. Then again, I'm not sure if it's > practical to do that with Java. Yes it's possible for Java libraries and we do it sometimes. Uploading a libguava19-java package is an option, but that might not be necessary since I've patched Guava 29 to preserve the backward compatibility. I think I've fixed most (and hopefully all) of the regressions reported by ratt. Emmanuel Bourg
Bug#931863: debirf: buster build fails to create initrd
Hello,
I'm facing the same problem from a clean Debian 10 install using
debirf-0.38
debirf> modules complete
debirf> creating debirf initrd ('nested')...
cp: cannot stat
'/media/sdb1/workspace/ai_bench/debird/rescue/root/lib/klibc-*': No such
file or directory
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 10 (buster)
Release:10
Codename: buster
$ cat /etc/debian_version
10.4
To reproduce:
- Install debirf: `apt-get install debirf`
- Take rescue template: `tar zxf
/usr/share/doc/debirf/example-profiles/rescue.tgz`
- Disable partimage package: `sed -i '/partimage$/d' rescue/packages`
- Build the image: `sudo debirf make rescue`
--
Pierre Gronlier
Bug#960146: dahdi-dkms: Installs files under /usr/src/dahdi-DEB_VERSION (unsubstituted)
Package: dahdi-dkms Version: 1:2.11.1.0.20170917~dfsg-7 Severity: normal Hi, I noticed that dahdi-dkms in Debian is installing files under the /usr/src/dahdi-DEB_VERSION directory [1], which doesn't seem to be the intended behavior (in Ubuntu, it substitutes DEB_VERSION with the current version of the package). Thanks, Logan [1] https://packages.debian.org/sid/all/dahdi-dkms/filelist
Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4
On Thu, 2020-05-07 at 14:23 +0100, Pete Batard wrote: [...] > I specifically designed the patch I submitted for easy review and > integration, because there are missing elements from 4.x that are > present in 5.x, that we have to compensate for. I would rather not have > to split it, especially as I believe it should be included as a matter > of priority and we're simply adding delays. I personally find it much easier to review backports in this form, and it is the usual practice in Debian to backport changes in this form where possible. > If Debian 11 was planning to continue to use a 4.x kernel, I could see > some point in splitting the patch and ensuring, so that it *might* be > easier to maintain for many years to come. But, from what I gather, > Debian 11 will bump kernel major, so any work being done making the 4.x > backport (which is not that complex, sorry, especially as I made sure to > already group the code changes in a manner that makes it easier to > handle) easier to maintain in the long run seems like a waste of time, > even if 10.x may see long time support for a few more years... [...] Debian 10 will be supported for 4 more years, in fact. During that time this driver may well see other changes backported through the stable process. Based on past experience, I think it will be easier to resolve any conflicts if our patches make smaller changes. So please don't assume what's "easier to handle" for us. Ben. -- Ben Hutchings - Debian developer, member of kernel, installer and LTS teams signature.asc Description: This is a digitally signed message part
Bug#960144: srt: please package new upstream bugfix release 1.4.1
Source: srt Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Upstream released a new bugfix release in December 2019. It includes some improvements and also fixes for several crashing issues. Please upgrade the package in Debian. Raising severity due to the nature of the changes to that release. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl63HE8ACgkQLHwxRsGg ASGABQ//eNSAzImCrSYiJKRhj3683LtOGWTPHB07c6Q2/4ZGCCbD0PKCTxxU9NNS Qi8NwghnoMG3sxe8NI2R/jIqbOGhUHBghRQ27Pji3L6tXTN6Yb/XAJs9f3Uj9zd2 M/60iyCNv+R7e4gNX2jLLMNnWdAE5J+VTgdKsrDvQvm10qac0IV509xaWSLe9RLT CBEvpiXOd0x49EiwVh96BcFCNkGevitLhTFcsS75gAdqaZU2yUdSt9A3B+QnbhJ9 Z8PUS00x13+vzOZPoRL8Nhz0pZ+UWS65HsgPhth8KeQ6+2j1VjuF1h3LZyD99+md rJbEaeX1JMqTfhM/k7XT+2DMmutlIxlFhByF5qHQeP5OQ/grgXL6c8+9F/T97+VB /hInS6PUhEvqerYTjHvvLTQIQAnBJsOQXhGM43f7Gc3hhUCuMGcMOlHyqx6nz1Dj /q83xRLAuG6Oy9TUsJgVEZXt/imd51EkPlOCUNKIBD9NZ5HPr96gwhHXjVODIsm+ b1VnqBVPq8Ayi2txREO/T8u4iBL1ordbO60Cp8WDov91CrjVr+ESUylNZpW5qyXZ gMcPahu2883FZPVIfCNdHmhxYy8SAZjZhAGQZy78QZ6SX/gGpQvm2jcwVlTjWU6G n4EDwE0Yvc7ZemEkBSIzC7YhiSDonaiMPAaKmsRKn19ljkcp54A= =HWAg -END PGP SIGNATURE-
Bug#960145: Description: is misleading with regards to jwm having few dependencies
Package: jwm Version: 2.3.6-1 Severity: wishlist The package Description: currently (2.3.7-3) reads: JWM is a window manager for the X11 Window System. JWM is written in C and uses only Xlib and (optionally) the shape extension and libXpm. […] However, as of 2.3.6-1 (stretch), the jwm Debian package is built with SVG support, which adds considerably to its footprint. I actually have two requests regarding this situation: a. could the description of the package please be fixed to mention that This JWM package is built with support for the full suite of supported image formats, including JPEG, PNG, SVG and XPM; as well as Xinerama and Xrender extensions, and FreeType-based font rendering. b. an alternative jwm-tiny package is provided with the minimal set of dependencies (in the spirit of vim-tiny.) TIA. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#959399: libreoffice-common: Using libreoffice results in many AppArmor "ALLOWED" log messages in kernel syslog
I guess I don't understand what needs to be changed. $HOME is /home, which is where the local users homes are. There are additional mount points (/raid, and one other) that hold additional network mounts of remotely store users' home directories. How should the configuration be changed for multiple home directories being stored and mounted in multiple locations? Evan On Sat, 2 May 2020, Rene Engelhard wrote: retitle 959399 libreoffice-common: many AppArmor "ALLOWED" log messages if using "non-standard" $HOME severity 959399 minor tag 959399 + wontfix thanks On Fri, May 01, 2020 at 06:00:46PM -0500, E Harris wrote: Using LibreOffice results in many AppArmor audit log messages marked as "ALLOWED". These messages repeat many times during normal use of the app, resulting in quite a bit of log spam. Perhaps this is the result of the user's home directory being mounted in an alternate location? Yes, and to be honest, if you change that dir you need to change all profiles referencing $HOME to allow it. Here you can be just glad it works because the profile is in complain mode, if it wasn't this wouldn't work at all... One simply cannot allow any path as this would simply defeat the purpose. A small sampling of messages (obfuscated): May 1 17:19:49 host kernel: [ 9201.656675] audit: type=1400 audit(1588371589.713:822): apparmor="ALLOWED" operation="mknod" profile="libreoffice-soffice" name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 comm="configmgrWriter" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 why /raid as extra mountpoint and not /home directly or / directly or if that's not intended some bind mounts to have /home on a "known" location? So that stuff like this doesn't knowingly break? Or is that the case? I am honestly not sure whether there's something to do there at all - except for the admin of the system to adapt the profile to the setuo of the system. Regards, Rene
Bug#933180: srt: consider adding non-openssl build
Source: srt Version: 1.4.0-1 Followup-For: Bug #933180 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Another option seems to be to link against mbedtls instead. That would be beneficial to the use with GStreamer as well - I guess licensing is the reason for it currently being in the "ugly" set. - Jonas - -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_DIE Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8), LANGUAGE=da_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl63G4QACgkQLHwxRsGg ASHecA//e/c0rXYYqAZJauBHOspyLIBmjnQOBJArqfQYzog1CGGQ6qs7YGQ2J1Aa RuMNbJkCeXbd/2sr0H42rJqCXv2R5h5PxgVvlRkrwORBvx1wTY1k1Xzk36TnBfNg iL4Fke/soi8rZ4blvohPSPSe9L9GFJ1k2qkREc59TY6uGx85hWanBHfDhfrU0UPe LhlfGDHKnAFvnh5RBPyUZEuNbq/opge47I6oW3Yw+KKs0PW8Zm9N4b/OonFe47nO jYXiid92ImNvCmlP71aNjfb7HfVY4muwQHXSC+hcTxhQZjdDi4wswIsaGZ0zwCS5 f9gImLHBnn+HmwolxvZPA5vrq5XKSRbgyIS4TFBSSCXB6pfA/zHvXsH+rzjj55pL VRcv8VpQKKGNYA5UpkcJRlyPVxCHDpg8vx7HPHe1gJSryMH9lkbVsc/kLgq5UQTh nziGJ11iwdX2d4igN6uI6lq31PPC4x9IrmBTBfbsn8NEqXEJ2TumKALHWQlOO2Ed ViNEQYeBwQVhEGrvOvUf6OmJh2FApNzHvHfoOlC8RAX/F/7U4Kc471k4micpgjYZ c9b2vVxTQxx+fgLlu6W+RmRQw1Ke4/QxA9L9gd7ql+U8499AL68DvwCH+LbL+UZ2 5+5QQSVlSEyDbQQC+NiyOgL3AbkJ7TZ2eblAoHLGmRH7OAKYkfQ= =Zprs -END PGP SIGNATURE-
Bug#960143: sagetex: FTBFS in unstable
Source: sagetex Version: 3.4+ds-1 Severity: serious Tags: ftbfs Hi Maintainer Sagetex currently FTBFS in unstable [1]. I've copied what I hope is the relevant part of the log below. Regards Graham [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sagetex.html kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 tcrm1000 mkdir: cannot create directory '././nonexistent': Permission denied mktexpk: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1+0/600; nonstopmode; input tcrm1000 This is METAFONT, Version 2.7182818 (TeX Live 2020/Debian) (preloaded base=mf) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/tcrm1000.mf (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/exbase.mf) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/tcrm.mf (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txsymb.mf Ok (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/exaccess.mf Ok) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txpseudo.mf Ok) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txaccent.mf Ok [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [27] [29]) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txgen.mf Ok [100] [109] [98] [99] [108]) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txsymbol.mf Ok [13] [18] [21] [22] [23] [24] [25] [26] [28] [31] [32] [36] [39] [44] [45] [46] [42] [47] [60] [61] [62] [77] [79] [87] [110] [91] [93] [94] [95] [96] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159] [160] [161] [162] [163] [164] [165] [166] [167] [168] [169] [171] [172] [173] [174] [175] [177] [176] [180] [181] [182] [183] [184] [187] [191] [214] [246]) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txromod.mf Ok [48] [49] [50] [51] [52] [53] [54] [55] [56] [57]) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txrsuper.mf Ok [185] [178] [179] [170] [186]) (/usr/share/texlive/texmf-dist/fonts/source/jknappen/ec/txrfract.mf Ok [188] [189] [190]) ) ) ) (some charht values had to be adjusted by as much as 0.06943pt) Font metrics written on tcrm1000.tfm. Output written on tcrm1000.600gf (128 characters, 23548 bytes). Transcript written on tcrm1000.log. mktexpk: /tmp/texfonts/pk/ljfour/jknappen/ec/tcrm1000.600pk: successfully generated. make[2]: Leaving directory '/build/1st/sagetex-3.4+ds' /usr/bin/make example.pdf TEXOPTS="-interaction batchmode" TEXINPUTS=".:_build/DEBIAN/usr/share/texmf/tex/latex/sagetex:_build/:" PYTHONPATH=_build/DEBIAN/usr/lib/python3.8/dist-packages VPATH=_build/DEBIAN/usr/share/texmf/tex/latex/sagetex:_build/DEBIAN/usr/lib/python3.8/dist-packages DOT_SAGE=/build/1st/sagetex-3.4+ds/_test/DOT_SAGE MPLCONFIGDIR=/build/1st/sagetex-3.4+ds/_test/MPLCONFIGDIR MAXIMA_USERDIR=/build/1st/sagetex-3.4+ds/_test/MAXIMA_USERDIR make[2]: Entering directory '/build/1st/sagetex-3.4+ds' pdflatex -interaction batchmode example.tex This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) (preloaded format=pdflatex) restricted \write18 enabled. entering extended mode make[2]: *** [Makefile:21: example.pdf] Error 1 make[2]: Leaving directory '/build/1st/sagetex-3.4+ds' make[1]: *** [debian/rules:59: override_dh_auto_test] Error 2 make[1]: Leaving directory '/build/1st/sagetex-3.4+ds' make: *** [debian/rules:28: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
Bug#953081: lambda-align2: empty package on !amd64
Followup-For: Bug #953081 Control: severity -1 normal The useless empty packages have been removed from stable, too. Therefore downgrading the severity to allow for bug archival. Andreas
Bug#960142: ITP: pyerfa -- Python bindings for ERFA routines
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-pyt...@lists.debian.org, debian-de...@lists.debian.org, debian-as...@lists.debian.org * Package name: pyerfa Version : TBD Upstream Author : Astropy Developers * URL : https://github.com/liberfa/pyerfa * License : BSD-3-Clause Programming Lang: Python Description : Python bindings for ERFA routines PyERFA is the Python wrapper for the ERFA library (Essential Routines for Fundamental Astronomy), a C library containing key algorithms for astronomy, which is based on the SOFA library published by the International Astronomical Union (IAU). All C routines are wrapped as Numpy universal functions, so that they can be called with scalar or array inputs. The project is a split of astropy._erfa module, developed in the context of Astropy project, into a standalone package, and therefore will be a dependency of upcoming Astropy releases. The packages will be maintained under Debian Astro team maintainance, with the repository at https://salsa.debian.org/debian-astro-team/pyerfa Best regards Ole
Bug#959113: guava-libraries: Please update to recent upstream (v25.1 or later)
Hi Emmanuel, On Tue, May 5, 2020 at 7:22 PM Emmanuel Bourg wrote: > Le 05/05/2020 à 05:59, Olek Wojnar a écrit : > > > However, I will attempt to build with v19 once we get to that point. > > That will hopefully be within the next week or two. If I obtain any > > useful information, I will let you know on this bug report. > Ok, update. I can confirm that Bazel does not build with Guava v19. [1] It looks like `com.google.common.graph.GraphBuilder` is missing, along with other classes. > Thank you. Guava is a troublesome library to upgrade, it's a core > library used by many projects, but upstream doesn't take binary > compatibility seriously and frequently removes classes/methods. This is > a recurrent source of regression on upgrades. So if the upgrade isn't > absolutely required it's preferable to stick to the current version. > Ugh, that *does* sound like quite the pain. I can definitely understand your preference to stick with something that you know works. That said, I've uploaded the version 23.6.1 to experimental, and the > version 29.0 should follow soon. So if it doesn't work with Guava 19 you > can try with the recent releases. > Great, thanks! I'll try those! Are you planning to migrate either to unstable in the near future? Also, is it possible to concurrently install multiple versions of guava like we do with some C++ libraries? Sorry if that's a naive question but I'm not exactly an expert with Java and how we package it in Debian. I know I've had similar issues in the past with C++ libraries and solved them by packaging both versions so that I was breaking neither old nor new packages that depended on them. Then again, I'm not sure if it's practical to do that with Java. Please let me know if there's anything else that I can do to help with this! -Olek [1] http://paste.debian.net/1145912/
Bug#960141: ffmpeg: Please enable SRT support
Package: ffmpeg Version: 7:4.2.2-1+b1 Severity: wishlist Dear Maintainer, Since version 0.4, FFmpeg supports SRT (Secure Reliable Transport) streaming. Please consider enabling it in the Debian packaging. https://trac.ffmpeg.org/ticket/6348 Thanks -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8), LANGUAGE=en_ZA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ffmpeg depends on: ii libavcodec587:4.2.2-1+b1 ii libavdevice58 7:4.2.2-1+b1 ii libavfilter77:4.2.2-1+b1 ii libavformat58 7:4.2.2-1+b1 ii libavresample4 7:4.2.2-1+b1 ii libavutil56 7:4.2.2-1+b1 ii libc6 2.30-7 ii libpostproc55 7:4.2.2-1+b1 ii libsdl2-2.0-0 2.0.10+dfsg1-3 ii libswresample3 7:4.2.2-1+b1 ii libswscale5 7:4.2.2-1+b1 ffmpeg recommends no packages. Versions of packages ffmpeg suggests: pn ffmpeg-doc -- no debconf information
Bug#960140: ffmpeg: please link with libsrt
Package: ffmpeg Version: 7:4.2.2-1+b1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 According to https://ffmpeg.org/index.html#news, ffmpeg supports linking with libsrt since version 4.0. Please link with libsrt. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl63EgcACgkQLHwxRsGg ASF1gA/9EBCfjuNWlVNiW3zPoA6KNPl6Pm8hhwUOPFRzAbRNg3Dl6UZ/PJ0U9aH7 1o9NlkF+GtsDHrqIir0BJZNHREUuhiDY2I+Wqw28qI6KmLGkP1CuPpC2j+QHwMA/ Kv9PeTo7vLvuwxS5ANTQX3gNycMEpKBJwwiG0tUq26xavXhszwpeLp+ypILrVbLa R/eup+5ILVIe8/fM3qUMfKXiSlKXes60pMZ53K5HMVHe8C5trCv2YLqfWjIf6JKX kr1GNpjwL5TzebM9T8MLXgebdEzmqUaSoeWOorvoyKVqiluejlHKm5LIPjERAW0I 4RJDRr3TZKGuvtHYki1/J9mCRw7cCN9IWb20TS88IbUz7zOu8DPL0/uxGGPaxDbH sEi7tWu1426yAwqYdj5W2gclsczFAxMNLdJ/C4p2zXh6s2NGpUjm0Dtvh/f063eK olx+lQMFlFsIaUpPFGxsqs6EdGr7bLisofBcBaeLx+2TNl8aFstDh2w3zcgFbdC+ iyHtuGuTT8B3VEJKkstq323myYGF72ibKlYMsXppNVn9PljdPrR+5jLVEZQ6p1dW TvzpRvepYrHfAQXPai6/xojyShAd+VSJ774BGHWIIhTMWTaUsrcHeADW6ss2k4nR Fyw7sTi6cUgnh5KtedsKaKt/RXdy+pE+3x0CFPgpMZ/5oOLrk2k= =5w4w -END PGP SIGNATURE-
Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
Control: severity -1 important Hi Adrian, On 07-05-2020 12:16, Adrian Bunk wrote: > On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote: >> On 07-05-2020 10:07, Adrian Bunk wrote: >>> This is a toolchain problem affecting many packages: >>> https://sourceware.org/bugzilla/show_bug.cgi?id=25051 [...] >>> Is there a non-manual way to express that the autopkgtest must not run >>> on arm64 and powerpc64el? >> >> There is currently not even a manual way except for marking the test as >> skippable and exitting with error code 77 on unsupported architectures. >> Mind you, I don't think toolchain issues should be marked at the package >> level (but maybe you didn't mean that). > > vtkplotter: flagged for removal in 6.3 days So, let's get that issue out of the way for now. I've lowered the severity of this bug and hinted the acceptance of the failing test for now. Paul signature.asc Description: OpenPGP digital signature
Bug#960137: O: duck -- checks URLs in debian/control and debian/upstream files
Package: wnpp Severity: normal I intend to orphan the duck package. I am retiring from the Debian Project. The package description is: duck, the Debian Url ChecKer, processes several fields in the debian/control, debian/upstream, debian/copyright,
Bug#960139: O: snowdrop -- plain text watermarking and watermark recovery
Package: wnpp Severity: normal I intend to orphan the snowdrop package. I am retiring from the Debian Project. The package description is: Snowdrop provides reliable, difficult to remove stenographic watermarking of text documents (internal memos, draft research papers, advisories and other writing) and C sources (limited distribution software, licensed software, or freely available code) so that: (1) leaks can be identified if the data goes public (2) original source can be determined and demonstrated if part of the document is claimed by somebody else, copied without permission, etc Snowdrop uses redundant steganography using four different logical channels, and should be proof to many modifications, including reformatting, spell checking and so on. .
Bug#960138: O: rtax -- Classification of sequence reads of 16S ribosomal RNA gene
Package: wnpp Severity: normal I intend to orphan the rtax package. I am retiring from the Debian Project. The package description is: Short-read technologies for microbial community profiling are increasingly popular, yet previous techniques for assigning taxonomy to paired-end reads
Bug#960085: [INTL:es] Spanish translation of the debian-installer template
Control: tags -1 + pending Camaleón wrote: > Package: installation-guide > Severity: wishlist > Tags: patch l10n > > Hello, > > You can find enclosed the Spanish translation template to be uploaded > with the latest package build. > > Greetings, > > -- > Camaleón Hi, first, I wonder why this bug did not end up on the debian-boot mailinglist? (I did not received it in my mailbox, and it does not appear in the list archive, too.) Luckily I got aware of this bug, due to other mails... second, despite the subject, this is a translation update for the installation- guide for Spanish. At the end, I have committed this to git. Tagging this bug as pending. Regards Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#958445: ruby-attr-encrypted and ruby-acts-as-taggable incompatible with Rails 6
I found these ruby gems are still using set_attribute_was, which appears
to have been removed in rails 6:
vendor_ruby/attr_encrypted/adapters/active_record.rb:
set_attribute_was(attr, __send__(attr)) if value != __send__(attr)
vendor_ruby/acts_as_taggable_on/taggable/core.rb:
set_attribute_was("#{tag_type}_list", #{tag_type}_list)
ii ruby-acts-as-taggable-on 6.5.0-2~bpo10+1 all provides
advanced tagging for Rails
ii ruby-attr-encrypted 3.1.0-2~bpo10+1 all Encrypt and
decrypt attributes
https://github.com/mbleigh/acts-as-taggable-on/issues/955
https://github.com/rolandoalvarado/acts-as-taggable-on/commit/391650aa48c571687844393e16b5d03c88f93be1
https://github.com/attr-encrypted/attr_encrypted/pull/337
attr_encrypted seems pretty much a dead project...
--
Frederik Himpe
Vrije Universiteit Brussel
Bug#960136: RM: pybitcointools -- RoQA; Depends on Python 2, dead upstream, unmaintained
Package: ftp.debian.org Severity: normal Please remove pybitcointools. It's abandoned upstream (#937391), depends on Python 2 and there was just a single upload back in 2017. Cheers, Moritz
Bug#943287: tcpwatch-httpproxy: Python2 removal in sid/bullseye
On Fri, Apr 24, 2020 at 08:13:42PM +0200, Moritz Mühlenhoff wrote: > On Wed, Oct 23, 2019 at 02:33:34AM +, mo...@debian.org wrote: > > Source: tcpwatch-httpproxy > > Version: 1.3.1-3 > > Severity: normal > > Tags: sid bullseye > > User: debian-pyt...@lists.debian.org > > Usertags: py2removal > > > > Python2 becomes end-of-live upstream, and Debian aims to remove > > Python2 from the distribution, as discussed in > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > > > Your package either build-depends, depends on Python2, or uses Python2 > > in the autopkg tests (the specific reason can be found searching this > > source package in > > https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ). > > Please stop using Python2, and fix this issue by one of the following > > actions. > > tcpwatch seems dead upstream, are you planning to port it to Python 3 > yourself or should it be removed? Filed an RM bug now. Cheers, Moritz
Bug#960135: RM: tcpwatch-httpproxy -- RoQA; Depends on Python 2, dead upstream
Package: ftp.debian.org Severity: normal Please remove tcpwatch-httpproxy. It depends on Python 2 and is dead upstream. Cheers, Moritz
Bug#937806: python-halberd: Python2 removal in sid/bullseye
On Thu, Apr 16, 2020 at 10:03:14PM +0200, Moritz Mühlenhoff wrote: > On Wed, Sep 04, 2019 at 11:16:28AM +, Gianfranco Costamagna wrote: > > control: forwared -1 https://github.com/jmbr/halberd/issues/2 > > Upstream seems dead, let's remove? Filed an RM bug now. Cheers, Moritz
Bug#960134: RM: python-halberd -- RoQA; Depends on Python 2, dead upstream
Package: ftp.debian.org Severity: normal Please remove python-halberd. It depends on Python 2 and is dead upstream. Cheers, Moritz
Bug#960036: inkscape takes 100% CPU when opening font combobox
I have adopted this workaround: copy gtk-3.0 specific setting to inkscape config subdir: cp -a ~/.config/gtk-3.0 ~/.config/inkscape/ editing file ~/.config/inkscape/gtk-3.0/settings.ini comment line: ; gtk-font-name=Noto Sans 10 modify command start application in: XDG_CONFIG_HOME=/home/root/.config/inkscape inkscape Now inkscape works, without making changes to the system. However, I disabled the preview of the fonts because it takes too long. Antonio
Bug#947776: [Pkg-owncloud-maintainers] Bug#947776: Same problem also with nautilus-nextcloud 2.6.4-1
Control: reassign -1 python3-nautilus 1.2.3-1 Control: affects -1 nautilus-nextcloud Hey, Thanks for digging into this deeper. > When I start nautilus from the command line I get this warning: > > ** (org.gnome.Nautilus:36227): WARNING **: 21:34:08.527: > /usr/lib/x86_64-linux-gnu/nautilus/extensions-3.0/libnautilus- > python.so: undefined symbol: _PyNautilusInfoProvider_Type > > Maybe this indicates the root of the problem? If python3-natuilus has undefined symbols this properly the root cause for this, because the nautilus integration is only a python script. I reassigned the bug to python3-nautilus, so they can have a look. hefee signature.asc Description: This is a digitally signed message part.
Bug#960133: downgrade dependencies on libgl1-mesa-dri to Recommends:
Package: libglx-mesa0 Version: 18.3.6-2+deb10u1 Control: found -1 19.3.3-1 Severity: wishlist So far as I can tell, the usage of the DRI modules provided by libgl1-mesa-dri by libglx-mesa0 is either optional or dependent on the context. At the very least, circumventing these dependencies produces no apparent ill effects with the packages transitionally dependent on libglx-mesa0, such as x11-utils, xvfb (via libgl1), and so on. Given that the libgl1-mesa-dri package brings in some 60‒70 MB of Installed-Size: due to libllvm alone – and also on headless systems which cannot possibly benefit from having DRI modules available – could the dependency on libgl1-mesa-dri please be downgraded to Recommends:? Background I’m concerned with, specifically, the amount of runnable code in the (base) system – and its implications on security. I assume that /not/ having some package installed is ought to be the ultimate guarantee that no security flaw in said package is going to affect a given system. Hence is my interest in minimalistic Debian installs. As a workaround, I’ve installed an otherwise empty Provides: libgl1-mesa-dri package [1], produced with nope.sh [2], like: $ fakeroot -- nope libgl1-mesa-dri [1] http://am-1.org/~ivan/dist/no-libgl1-mesa-dri_0.1_all.deb [2] http://am-1.org/~ivan/src/nope.sh -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#960132: mdadm: mdcheck_start.service trying to start unexisting file
X-Debbugs-Cc: none Package: mdadm Version: 4.1-5 Severity: normal mdcheck_start.service trying to start unexisting file root@debian:/# cat /lib/systemd/system/mdcheck_start.service | grep Exec ExecStartPre=-/usr/lib/mdadm/mdadm_env.sh ExecStart=/usr/share/mdadm/mdcheck --duration $MDADM_CHECK_DURATION root@debian:/# ls -la /usr/share/mdadm/mdcheck ls: cannot access '/usr/share/mdadm/mdcheck': No such file or directory root@debian:/# dpkg -L mdadm | grep mdcheck /lib/systemd/system/mdcheck_continue.service /lib/systemd/system/mdcheck_continue.timer /lib/systemd/system/mdcheck_start.service /lib/systemd/system/mdcheck_start.timer -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mdadm depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii lsb-base 10.2019051400 ii udev 241-7~deb10u4 Versions of packages mdadm recommends: ii exim4-daemon-light [mail-transport-agent] 4.92-8+deb10u3 ii kmod 26-1 Versions of packages mdadm suggests: pn dracut-core -- debconf information: mdadm/autoscan: true mdadm/mail_to: root mdadm/start_daemon: true mdadm/autocheck: true There is a patch in attachment, that adds missed scripts into the package during build process. This bug also affects Ubuntu mdadm package - https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1852747 --- a/debian/rules 2020-05-10 01:51:20.69600 +0700 +++ b/debian/rules 2020-05-10 01:52:56.4 +0700 @@ -28,6 +28,7 @@ rm -rf udeb mkdir udeb ln *.[ch] Makefile udeb/ + ln misc/mdcheck misc/syslog-events udeb/ touch $@ build-arch: udeb/build-stamp @@ -63,6 +64,8 @@ install -Dm0755 debian/mkconf $(DESTDIR)/usr/share/mdadm/mkconf install -Dm0755 debian/checkarray $(DESTDIR)/usr/share/mdadm/checkarray + install -Dm0755 udeb/mdcheck $(DESTDIR)/usr/share/mdadm/mdcheck + install -Dm0755 udeb/syslog-events $(DESTDIR)/usr/share/mdadm/syslog-events install -Dm0755 debian/bugscript $(DESTDIR)/usr/share/bug/mdadm/script install -Dm0755 udeb/mdadm $(DESTDIR_UDEB)/sbin/mdadm install -Dm0755 udeb/mdmon $(DESTDIR_UDEB)/sbin/mdmon
Bug#960131: swi-prolog: flaky autopkgtest: test set "file" ... aborted
Source: swi-prolog Version: 8.1.29+dfsg-2 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), You package has an autopkgtest, great. However, it seems to regularly fail [1] on both amd64 and arm64. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Please either fix the test to be more robust, or use the "flaky" restriction for the offending test until a solution has been found. I copied the output at the bottom of this report. All the failing tests that I inspected look like it. I'll have the migration software ignore the results of your autopkgtest until this bug is fixed. Paul [1] https://ci.debian.net/user/britney/jobs?package=swi-prolog https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/5373683/log.gz Running test set "file" (2329).(2332).(2335).(2338).(2341).(2343).(2346).(2348).(2350).(2353).(2357)[Thread 1 (main) at Fri May 8 15:26:09 2020] /build/swi-prolog-Chg12z/swi-prolog-8.1.29+dfsg/src/os/pl-os.c:1093: deleteCanonicalDir: Assertion failed: 0 C-stack trace labeled "assert_fail": [0] PL_strtod() at ??:? [0x7f51fc9d36f1] [1] __assert_fail() at ??:? [0x7f51fc991e16] [2] PL_get_file_nameW() at ??:? [0x7f51fc9bd6a0] [3] PL_get_file_nameW() at ??:? [0x7f51fc9bdba9] [4] PL_get_file_nameW() at ??:? [0x7f51fc9bde80] [5] FreeMemory() at ??:? [0x7f51fc9bee4b] [6] PopTty() at ??:? [0x7f51fc9c0307] [7] PL_get_file_name() at ??:? [0x7f51fc9bb48f] [8] PL_next_solution() at ??:? [0x7f51fc907836] [9] pl_skip_list3_va() at ??:? [0x7f51fc9465cf] [10] pl_skip_list3_va() at ??:? [0x7f51fc946e3b] [11] PL_initialise() at ??:? [0x7f51fc989a9c] [12] /usr/bin/swipl(+0x10a7) [0x55ca1e9350a7] [13] __libc_start_main() at ??:? [0x7f51fc71be0b] [14] /usr/bin/swipl(+0x10fa) [0x55ca1e9350fa] Aborted signature.asc Description: OpenPGP digital signature
Bug#933180: Patch for #933180
tags 933180 + patch
thanks
The attached patch adds an extra build of srt linked to GnuTLS
(on a different soname), complete with separate -dev packages.
I intend to NMU with this (and a version bump to 1.4.1) in 14 days
time; please let me know if you have any comments.
/* Steinar */
--
Homepage: https://www.sesse.net/
diff -Nru srt-1.4.0/debian/changelog srt-1.4.0/debian/changelog
--- srt-1.4.0/debian/changelog 2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/changelog 2020-05-09 20:28:05.0 +0200
@@ -1,3 +1,11 @@
+srt (1.4.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add a build against GnuTLS, for packages with licenses that are not
+compatible with OpenSSL. (Closes: #933180)
+
+ -- Steinar H. Gunderson Sat, 09 May 2020 20:28:05 +0200
+
srt (1.4.0-1) unstable; urgency=medium
* New upstream release (Closes: #939040)
diff -Nru srt-1.4.0/debian/control srt-1.4.0/debian/control
--- srt-1.4.0/debian/control 2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/control 2020-05-09 20:09:38.0 +0200
@@ -21,6 +21,7 @@
Multi-Arch: same
Depends: libsrt1 (= ${binary:Version}), ${misc:Depends}
Suggests: libsrt-doc (= ${binary:Version})
+Conflicts: libsrt-gnutls-dev
Description: Secure Reliable Transport UDP streaming library
SRT is a latency-aware UDP transport mechanism optimized for video streams.
It detects and compensates for jitter and bandwidth fluctuations due to
@@ -28,6 +29,20 @@
.
This package contains development files for libsrt1
+Package: libsrt-gnutls-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: libsrt1 (= ${binary:Version}), ${misc:Depends}
+Suggests: libsrt-doc (= ${binary:Version})
+Conflicts: libsrt-dev
+Description: Secure Reliable Transport UDP streaming library
+ SRT is a latency-aware UDP transport mechanism optimized for video streams.
+ It detects and compensates for jitter and bandwidth fluctuations due to
+ network congestion. It mitigates packet loss and supports AES encryption.
+ .
+ This package contains development files for libsrt1-gnutls
+
Package: libsrt-doc
Section: doc
Architecture: all
@@ -48,6 +63,19 @@
It detects and compensates for jitter and bandwidth fluctuations due to
network congestion. It mitigates packet loss and supports AES encryption.
+Package: libsrt1-gnutls
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Secure Reliable Transport UDP streaming library
+ SRT is a latency-aware UDP transport mechanism optimized for video streams.
+ It detects and compensates for jitter and bandwidth fluctuations due to
+ network congestion. It mitigates packet loss and supports AES encryption.
+ .
+ The package contains a version of the shared library that is linked to
+ GnuTLS instead of OpenSSL. This is useful if you intend to use SRT in
+ software that is GPL-compatible but not compatible with the OpenSSL license.
+
Package: srt-tools
Architecture: any
Section: utils
diff -Nru srt-1.4.0/debian/libsrt1-gnutls.install srt-1.4.0/debian/libsrt1-gnutls.install
--- srt-1.4.0/debian/libsrt1-gnutls.install 1970-01-01 01:00:00.0 +0100
+++ srt-1.4.0/debian/libsrt1-gnutls.install 2020-05-09 20:06:43.0 +0200
@@ -0,0 +1,2 @@
+usr/lib/*/libsrt-gnutls.so.*
+
diff -Nru srt-1.4.0/debian/libsrt1.install srt-1.4.0/debian/libsrt1.install
--- srt-1.4.0/debian/libsrt1.install 2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/libsrt1.install 2020-05-09 20:06:32.0 +0200
@@ -1 +1 @@
-usr/lib/*/lib*.so.*
+usr/lib/*/libsrt.so.*
diff -Nru srt-1.4.0/debian/libsrt-dev.install srt-1.4.0/debian/libsrt-dev.install
--- srt-1.4.0/debian/libsrt-dev.install 2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/libsrt-dev.install 2020-05-09 20:26:24.0 +0200
@@ -1,3 +1,2 @@
usr/include/*
-usr/lib/*/lib*.so
-usr/lib/*/pkgconfig/*
+usr/lib/*/libsrt.so
diff -Nru srt-1.4.0/debian/libsrt-gnutls-dev.install srt-1.4.0/debian/libsrt-gnutls-dev.install
--- srt-1.4.0/debian/libsrt-gnutls-dev.install 1970-01-01 01:00:00.0 +0100
+++ srt-1.4.0/debian/libsrt-gnutls-dev.install 2020-05-09 20:15:20.0 +0200
@@ -0,0 +1,2 @@
+usr/include/*
+usr/lib/*/libsrt-gnutls.so
diff -Nru srt-1.4.0/debian/rules srt-1.4.0/debian/rules
--- srt-1.4.0/debian/rules 2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/rules 2020-05-09 20:26:11.0 +0200
@@ -4,6 +4,14 @@
export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
+# Standardized flags from /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm.
+CMAKE_OPTS := -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON
+
+ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+ NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+ MAKEFLAGS += -j$(NUMJOBS)
Bug#960129: linux-image-5.6.0-1-arm64: please enable CONFIG_PCIE_BRCMSTB in the arm64 kernel for Raspberry Pi 4
Package: src:linux Version: 5.6.7-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Maintainer, Please enable CONFIG_PCIE_BRCMSTB on arm64. The Raspberry Pi 4 has a VL805 xhci controller connected to the PCIe bus on the SoC. All USB ports are connected to this controller. CONFIG_PCIE_BRCMSTB is therefore necessary for USB support. I tested rebuilding the current Debian 5.6 kernel in sid with just this change, and it is enough to enable the USB port on the RPi4: root@buster-rpi4:~# lspci -nn 00:00.0 PCI bridge [0604]: Broadcom Limited Device [14e4:2711] (rev 10) 01:00.0 USB controller [0c03]: VIA Technologies, Inc. VL805 USB 3.0 Host Controller [1106:3483] (rev 01) root@buster-rpi4:~# lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@buster-rpi4:~# dmesg |egrep -i 'pci|usb|xhci' [0.877939] PCI: CLS 0 bytes, default 64 [1.359321] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [1.359879] brcm-pcie fd50.pcie: host bridge /scb/pcie@7d50 ranges: [1.359905] brcm-pcie fd50.pcie: No bus range found for /scb/pcie@7d50, using [bus 00-ff] [1.359943] brcm-pcie fd50.pcie: MEM 0x06..0x0603ff -> 0x00f800 [1.359978] brcm-pcie fd50.pcie: IB MEM 0x00..0x00bfff -> 0x00 [1.409038] brcm-pcie fd50.pcie: link up, 5 GT/s x1 (SSC) [1.409257] brcm-pcie fd50.pcie: PCI host bridge to bus :00 [1.409277] pci_bus :00: root bus resource [bus 00-ff] [1.409296] pci_bus :00: root bus resource [mem 0x6-0x603ff] (bus address [0xf800-0xfbff]) [1.409340] pci :00:00.0: [14e4:2711] type 01 class 0x060400 [1.409442] pci :00:00.0: PME# supported from D0 D3hot [1.411585] pci :00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [1.411761] pci :01:00.0: [1106:3483] type 00 class 0x0c0330 [1.411849] pci :01:00.0: reg 0x10: [mem 0x-0x0fff 64bit] [1.412028] pci :01:00.0: PME# supported from D0 D3cold [1.424884] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 [1.424924] pci :00:00.0: BAR 14: assigned [mem 0x6-0x6000f] [1.424947] pci :01:00.0: BAR 0: assigned [mem 0x6-0x60fff 64bit] [1.424975] pci :00:00.0: PCI bridge to [bus 01] [1.424991] pci :00:00.0: bridge window [mem 0x6-0x6000f] [1.425165] pcieport :00:00.0: enabling device ( -> 0002) [1.425312] pcieport :00:00.0: PME: Signaling with IRQ 40 [1.425631] pcieport :00:00.0: AER: enabled with IRQ 40 [1.425806] pci :01:00.0: enabling device ( -> 0002) [3.189692] usb_phy_generic phy: phy supply vcc not found, using dummy regulator [3.278169] usbcore: registered new interface driver usbfs [3.284814] usbcore: registered new interface driver hub [3.291153] usbcore: registered new device driver usb [3.336101] dwc2 fe98.usb: fe98.usb supply vusb_d not found, using dummy regulator [3.344668] dwc2 fe98.usb: fe98.usb supply vusb_a not found, using dummy regulator [3.459118] dwc2 fe98.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM [ 15.946055] xhci_hcd :01:00.0: xHCI Host Controller [ 15.954077] xhci_hcd :01:00.0: new USB bus registered, assigned bus number 1 [ 15.967736] xhci_hcd :01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0090 [ 15.989621] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.06 [ 15.998076] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 16.005520] usb usb1: Product: xHCI Host Controller [ 16.010535] usb usb1: Manufacturer: Linux 5.6.0-2-arm64 xhci-hcd [ 16.016722] usb usb1: SerialNumber: :01:00.0 [ 16.023171] hub 1-0:1.0: USB hub found [ 16.033311] xhci_hcd :01:00.0: xHCI Host Controller [ 16.039381] xhci_hcd :01:00.0: new USB bus registered, assigned bus number 2 [ 16.039400] xhci_hcd :01:00.0: Host supports USB 3.0 SuperSpeed [ 16.039510] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [ 16.039578] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.06 [ 16.039581] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 16.039584] usb usb2: Product: xHCI Host Controller [ 16.039587] usb usb2: Manufacturer: Linux 5.6.0-2-arm64 xhci-hcd [ 16.039589] usb usb2: SerialNumber: :01:00.0 [ 16.039938] hub 2-0:1.0: USB hub found [ 16.197384] usbcore: registered new interface driver brcmfmac [ 16.443015] usb 1-1: new high-speed USB device number 2 using xhci_hcd [ 16.601666] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.21 [ 16.613530] usb 1-1: New USB device strings:
Bug#960130: downgrade dependencies on libnl to Recommends:
Package: quota Version: 4.04-2+deb10u1 Severity: wishlist [I’ve checked that this bug affects 4.05-1 as well. Due to a separate problem, already AFAICT fixed upstream, the workaround suggested below does /not/ work for the version in testing.] The (versioned) dependencies on libnl-3-200, libnl-genl-3-200 currently specified by the quota package are only relevant to the single quota_nld binary. As circumventing these dependencies produces no apparent ill effects when using the rest of the package, could they please be downgraded to Recommends:? (Note that per the CTTE decision recorded in Debian Bug#119517, slight breakage due to missing Recommends: is considered acceptable.) Alternatively, could the binary in question please be moved off to a separate binary package? TIA. Background I’m concerned with, specifically, the amount of runnable code in the (base) system – and its implications on security. I assume that /not/ having some package installed is ought to be the ultimate guarantee that no security flaw in said package is going to affect a given system. Hence is my interest in minimalistic Debian installs. As a workaround, I’ve installed two otherwise empty packages that specify versioned Provides: on libnl-3-200 and libnl-genl-3-200, both (= 3.2.7), respectively [1‒2]. The packages were produced with nope.sh [3], like: $ fakeroot -- nope libnl-3-200=3.2.7 ; \ fakeroot -- nope libnl-genl-3-200=3.2.7 [1] http://am-1.org/~ivan/dist/no-libnl-3-200_0.1_all.deb [2] http://am-1.org/~ivan/dist/no-libnl-genl-3-200_0.1_all.deb [3] http://am-1.org/~ivan/src/nope.sh Note that in 4.05-1, /all/ the binaries are made to link with /all/ the libraries, thus making the workaround above unsuitable. This upstream bug has since been fixed: commit 00d61f21bfa3ccf40826ce22de12cfeeab8a40a5 Author: Dmitry V. Levin AuthorDate: 2019-04-01 02:23:59 +0300 Commit: Jan Kara CommitDate: 2019-04-01 17:11:11 +0200 Revert "configure.ac: fix pkg_check_modules calls" CFLAGS and LIBS are variables that users are entitled to modify in order to compile the package, so do not tamper with CFLAGS and LIBS. COM_ERR_CFLAGS, EXT2FS_CFLAGS, DBUS_CFLAGS, LIBNL3_CFLAGS, TIRPC_CFLAGS, COMM_ERR_LIBS, EXT2FS_LIBS, DBUS_LIBS, LIBNL3_LIBS, and TIRPC_LIBS should be used directly where appropriate and apparently they already are. This reverts commit b54d97d677481287faa5d6b98c92f41c1af3. Signed-off-by: Dmitry V. Levin Signed-off-by: Jan Kara -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#960128: csound: autopkgtest regression: libcsound64.so: cannot open shared object file
Source: csound
Version: 1:6.14.0~dfsg-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of csound the autopkgtest of csound fails in
testing when that autopkgtest is run with the binary packages of csound
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
csound from testing1:6.14.0~dfsg-2
versioned deps [0 from testingfrom unstable
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=csound
https://ci.debian.net/data/autopkgtest/testing/amd64/c/csound/5391643/log.gz
autopkgtest [07:07:45]: test python3-csound: [---
Testing ctcsound with python3.8:
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/ctcsound.py", line 39, in
libcsound = ct.CDLL("libcsound64.so")
File "/usr/lib/python3.8/ctypes/__init__.py", line 373, in __init__
self._handle = _dlopen(self._name, mode)
OSError: libcsound64.so: cannot open shared object file: No such file or
directory
autopkgtest [07:07:46]: test python3-csound: ---]
signature.asc
Description: OpenPGP digital signature
Bug#933439: (no subject)
did you try with this change? https://github.com/amule-project/amule/commit/cf63429667953088c7cf93846c892eed7bdde617 It seems to work fine here with this change in a quick test.
Bug#960119: dh-vim-addon: missing substvar for non-basic Vim flavours?
On Sat, May 09, 2020 at 07:31:51PM +0300, Nicholas Guriev wrote: > It sounds good but does not seem to work. :( At least, apt wants to install > the > vim package despite vim-gtk3 already provides vim. Something strange is > happening, and I need a bit more investigation. Ok, I have an idea of what might be happening. I think the "Provides: vim" needs to be versioned. I'll test it out later to confirm. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#960127: Tk::Error: Can't locate object method "resolve_names" via package "App::ClusterSSH::Window"
Package: clusterssh Version: 4.14-1 Severity: grave Justification: renders package unusable It looks like cssh doesn't work anymore on my Debian unstable machine. When I add a host, I see the following on the console: Tk::Error: Can't locate object method "resolve_names" via package "App::ClusterSSH::Window" at /usr/share/perl5/App/ClusterSSH/Window/Tk.pm line 349. App::ClusterSSH::Window::Tk::add_host_by_name at /usr/share/perl5/App/ClusterSSH/Window/Tk.pm line 349 App::ClusterSSH::Window::Tk::key_event at /usr/share/perl5/App/ClusterSSH/Window/Tk.pm line 1613 (command bound to event) and nothing happens. Francois -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=UTF-8), LANGUAGE=fr_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clusterssh depends on: ii libexception-class-perl 1.44-1 ii libtry-tiny-perl0.30-1 ii libx11-protocol-other-perl 31-1 ii libx11-protocol-perl0.56-7 ii openssh-client 1:8.2p1-4 ii perl5.30.0-10 ii perl-tk 1:804.033-2+b4 ii xterm 356-1 clusterssh recommends no packages. clusterssh suggests no packages. -- no debconf information
Bug#960126: FTBFS: No cached version of :osmosis-core-0.47.2: available for offline mode.
Source: mapsforge Version: 0.13.0+dfsg.1-2 Severity: serious Tags: ftbfs Dear Maintainer, mapsforge 0.13.0+dfsg.1-2 currently fails to build: All input files are considered out-of-date for incremental task ':mapsforge-map:compileJava'. Compiling with JDK Java compiler API. :mapsforge-poi:compileJava (Thread[Task worker for ':' Thread 10,5,main]) completed. Took 0.717 secs. :mapsforge-map:compileJava (Thread[Task worker for ':' Thread 3,5,main]) completed. Took 2.081 secs. FAILURE: Build failed with an exception. * What went wrong: Could not resolve all files for configuration ':mapsforge-map-writer:compileClasspath'. Could not resolve :osmosis-core-0.47.2:. Required by: project :mapsforge-map-writer > No cached version of :osmosis-core-0.47.2: available for offline mode. > No cached version of :osmosis-core-0.47.2: available for offline mode. > No cached version of :osmosis-core-0.47.2: available for offline mode. For more details see https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mapsforge.html I suppose it fails to find the osmosis jars now that it has been updated to 0.48.0-1. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-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 -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#960125: Subject: FTBFS: collect2: error: ld returned 1 exit status
Source: ignition-transport Version: 8.0.0+dfsg-3 Severity: serious Tags: ftbfs Dear Maintainer, ignition-transport 8.0.0+dfsg-3 currently fails to build: Run Build Command(s):/usr/bin/make cmTC_64ca3/fast && make[2]: Entering directory '/build/1st/ignition-transport-8.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' /usr/bin/make -f CMakeFiles/cmTC_64ca3.dir/build.make CMakeFiles/cmTC_64ca3.dir/build make[3]: Entering directory '/build/1st/ignition-transport-8.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_64ca3.dir/src.c.o /usr/bin/cc -g -O2 -ffile-prefix-map=/build/1st/ignition-transport-8.0.0+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DCMAKE_HAVE_LIBC_PTHREAD -o CMakeFiles/cmTC_64ca3.dir/src.c.o -c /build/1st/ignition-transport-8.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c Linking C executable cmTC_64ca3 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_64ca3.dir/link.txt --verbose=1 /usr/bin/cc -g -O2 -ffile-prefix-map=/build/1st/ignition-transport-8.0.0+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DCMAKE_HAVE_LIBC_PTHREAD -Wl,-z,relro -Wl,-z,now CMakeFiles/cmTC_64ca3.dir/src.c.o -o cmTC_64ca3 /usr/bin/ld: CMakeFiles/cmTC_64ca3.dir/src.c.o: in function `main': ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:11: undefined reference to `pthread_create' /usr/bin/ld: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:12: undefined reference to `pthread_detach' /usr/bin/ld: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:13: undefined reference to `pthread_join' collect2: error: ld returned 1 exit status make[3]: *** [CMakeFiles/cmTC_64ca3.dir/build.make:87: cmTC_64ca3] Error 1 make[3]: Leaving directory '/build/1st/ignition-transport-8.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' make[2]: *** [Makefile:121: cmTC_64ca3/fast] Error 2 make[2]: Leaving directory '/build/1st/ignition-transport-8.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' See also https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ignition-transport.html -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-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 -- mvh / best regards Hans Joachim Desserud http://desserud.org
Bug#960124: all VMs refuse to start, 0x80004005 / MachineWrap / {85632c68-b5bb-4316-a900-5eb28d3413df}
Package: virtualbox
Version: 6.1.6-dfsg-2
Severity: important
Hi,
none of my VMs is usable anymore. It was ok in last summer with the
latest vanilla kernel back then, but now I am getting:
The virtual machine 'liveos' has terminated unexpectedly during startup with
exit code 1 (0x1).
Fehlercode:
NS_ERROR_FAILURE (0x80004005)
Komponente:
MachineWrap
Interface:
IMachine {85632c68-b5bb-4316-a900-5eb28d3413df}
And this for all existing VMs in my configuration. The configuration
itself looks ok, the modules are there, the modules are loaded.
$ find /lib/modules/5.6.0-1-amd64 | grep vbox
/lib/modules/5.6.0-1-amd64/misc/vboxnetadp.ko
/lib/modules/5.6.0-1-amd64/misc/vboxdrv.ko
/lib/modules/5.6.0-1-amd64/misc/vboxnetflt.ko
/lib/modules/5.6.0-1-amd64/kernel/drivers/gpu/drm/vboxvideo
/lib/modules/5.6.0-1-amd64/kernel/drivers/gpu/drm/vboxvideo/vboxvideo.ko
/lib/modules/5.6.0-1-amd64/kernel/drivers/virt/vboxguest
/lib/modules/5.6.0-1-amd64/kernel/drivers/virt/vboxguest/vboxguest.ko
/lib/modules/5.6.0-1-amd64/updates/dkms/vboxnetadp.ko
/lib/modules/5.6.0-1-amd64/updates/dkms/vboxdrv.ko
/lib/modules/5.6.0-1-amd64/updates/dkms/vboxnetflt.ko
$ lsmod | grep vbox
vboxnetadp 28672 0
vboxnetflt 32768 0
vboxdrv 528384 2 vboxnetadp,vboxnetflt
Ryzen virtualization is enabled:
$ grep svm /proc/cpuinfo | sort -u
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf
pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx
f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext
perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2
smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves
clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean
flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif
overflow_recov succor smca
Looking for that error, reveals:
$ grep -i error VBoxSVC.log | grep -v vbox.*File.not.found
00:00:00.576586 nspr-4 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
object functionality is limited}, preserve=false aResultDetail=0
00:00:00.576622 nspr-4 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
object functionality is limited}, preserve=false aResultDetail=0
00:00:00.576640 nspr-4 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
object functionality is limited}, preserve=false aResultDetail=0
00:00:00.576649 nspr-4 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
object functionality is limited}, preserve=false aResultDetail=0
00:00:00.576658 nspr-4 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
object functionality is limited}, preserve=false aResultDetail=0
00:00:04.383412 Watcher ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
virtual machine 'liveos' has terminated unexpectedly during startup with exit
code 1 (0x1)}, preserve=false aResultDetail=0
Now idea how to continue from here. Any ideas?
Maybe this is a variant of https://www.virtualbox.org/ticket/19224 or
https://bbs.archlinux.org/viewtopic.php?pid=1887935#p1887935 ?
What "access" is required there? I am running VirtualBox as plain user
and this has been working for years.
Also, assuming that I need to reconfigure something, I tried this:
$ dpkg-reconfigure -plow virtualbox
insserv: script portmap: service portmap already provided!
Job for vboxweb.service failed because the service did not take the steps
required by its unit configuration.
See "systemctl status vboxweb.service" and "journalctl -xe" for details.
$ systemctl status vboxweb.service
● vboxweb.service - VirtualBox Web Service
Loaded: loaded (/lib/systemd/system/vboxweb.service; enabled; vendor
preset: enabled)
Active: failed (Result: protocol) since Sat 2020-05-09 19:29:55 CEST; 1min
3s ago
Process: 8721 ExecStart=/usr/lib/virtualbox/vboxweb-service.sh start
(code=exited, status=0/SUCCESS)
Mai 09 19:29:55 zombie systemd[1]: Starting VirtualBox Web Service...
Mai 09 19:29:55 zombie systemd[1]: vboxweb.service: Can't open PID file
/run/vboxweb.pid (yet?) after start: Operation not permitted
Mai 09 19:29:55 zombie systemd[1]: vboxweb.service: Failed with result
'protocol'.
Mai 09 19:29:55 zombie systemd[1]: Failed to start VirtualBox Web Service.
Again,
Bug#958883: unattended-upgrades: consumes 100% cpu over a long period (more then half an hour) doing nothing
Control: tags -1 +pending - moreinfo Control: forwarded -1 https://github.com/mvo5/unattended-upgrades/pull/272 Hi Maurizio, Bálint Réczey ezt írta (időpont: 2020. ápr. 26., V, 12:41): > > Control: block -1 by 711128 > Control: tags -1 confirmed moreinfo > > Hi Maurizio, > > Maurizio Di Pietro ezt írta (időpont: 2020. ápr. > 26., V, 10:57): > > > > Package: unattended-upgrades > > Version: 2.3 > > Severity: important > > > > Dear Maintainer, > > > > after latest system upgrade , i noticed this behavior. > > In the bugtracker i noticed there was a similar behavior described in > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899366 > > > > but it had been fixed. Maybe a regression. > > Unattended-upgrades 1.18 attempted to fully rely on APT's resolver for > upgrades, but unfortunately APT's resolver can't always find the > solution. > Unattended-upgrades thus tries to work around APT's resolver's failure > and falls back to adjusting package dependencies which can take long > if there are many upgradable/broken packages and this situation can > occur frequently in unstable. > > Please attach the output of unattended-upgrades -d -v to see if u-u > spends its time in adjusting packages to help APT's resolver. It were the adjustments that took very long indeed, but was a bug in the fallback code that triggered way more adjustments than needed, adding a slow O(n^2) component. The bug will be fixed, making unattended-upgrades finishing in minutes rather than tens of minutes or hours sometimes in unstable. Cheers, Balint
Bug#960123: fastboot -w fails with "mke2fs failed: 1"
Package: fastboot Version: 1:8.1.0+r23-5 Severity: normal Dear Maintainer, I connected my Fairphone 3 to my computer using USB and tried using "fastboot -w". The command failed with the following error message: Invalid erase-block-size 512: must be a power of 2 and at least 4096. Invalid logical-block-size 512: must be a power of 2 and at least 4096. mke2fs 1.45.6 (20-Mar-2020) /tmp/TemporaryFile-GmJtWH: Unimplemented ext2 library function while setting up superblock /usr/lib/android-sdk/platform-tools/mke2fs failed with status 1 mke2fs failed: 1 error: Cannot generate image for userdata I then retried with the version of fastboot that I downloaded from developer.android.com and it worked fine. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/16 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fastboot depends on: ii android-libadb 1:8.1.0+r23-5 ii android-libbase1:8.1.0+r23-5 ii android-libcutils 1:8.1.0+r23-5 ii android-libf2fs-utils 8.1.0+r23-2 ii android-libsparse 1:8.1.0+r23-5 ii android-libutils 1:8.1.0+r23-5 ii android-libziparchive 1:8.1.0+r23-5 ii libc6 2.30-7 ii libgcc-s1 [libgcc1]10.1.0-1 ii libgcc11:10.1.0-1 ii libstdc++6 10.1.0-1 Versions of packages fastboot recommends: ii android-sdk-platform-tools 27.0.0+12 fastboot suggests no packages. -- no debconf information
Bug#960012: probably the same bug
This is probably the same bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959971
Bug#959731: debhelper: Please export $HOME as absolute path, not relative
On Mon, May 04, 2020 at 08:06:45PM +0300, Dmitry Shachnev wrote: > debhelper currently exports HOME='debian/.debhelper/generated/_source/home'. > > However, with some build systems, the tests are run in a different directory, > e.g. with meson the command is: > > cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test > > Then the tests are looking for files in > obj-x86_64-linux-gnu/debian/.debhelper/generated/_source/home, which is wrong. This also results in systems with ccache installed dropping debian/.debhelper/generated/_source/home/.ccache directories all over the tree. Regards, Stephen signature.asc Description: PGP signature
Bug#960122: Errors in X DEFAULTS section of man page: bell, utc, width, height, date
Package: dclock Version: 2.2.2-11 Severity: normal The "bell" resource is documented twice in the X DEFAULTS section of the man page. bell (class Boolean) Specifies whether or not a bell should be rung on the hour and half hour. bell (class Boolean) Specifies whether the bell should sound on the half hour and on the hour. The documented "utc" resource is actually called "utcTime". utc (class Boolean) Specifies whether UTC (GMT) time should be used, rather than local time. Dclock.h: #define XtNutcTime "utcTime" You can verify with these commands: dclock -xrm 'dclock*utc: true' dclock -xrm 'dclock*utcTime: true' The documented "width" and "height" resources did not work for me. I had to use "geometry". dclock -xrm 'dclock*width: 500' -xrm 'dclock*height: 500' dclock -xrm 'dclock*geometry: 500x500' The "date" resource (corresponding to the -date option) is undocumented. dclock -xrm 'dclock*date: %Y-%m-%d' Dclock.h: #define XtNdate "date" -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dclock depends on: ii libc6 2.28-10 ii libice6 2:1.0.9-2 ii libsm62:1.2.3-1 ii libx11-6 2:1.6.7-1 ii libxext6 2:1.3.3-1+b2 ii libxft2 2.3.2-2 ii libxt61:1.1.5-1+b3 Versions of packages dclock recommends: ii sox 14.4.2+git20190427-1 dclock suggests no packages. -- no debconf information
Bug#960121: ITP: pyerfa -- https://github.com/liberfa/pyerfa
Package: wnpp Severity: wishlist Owner: Antonio Valentino * Package name: pyerfa Version : 1.7.0 Upstream Author : The Astropy Developers * URL : https://github.com/liberfa/pyerfa * License : Programming Lang: Python Description : Python bindings for ERFA Binary package names: python3-pyerfa PyERFA is the Python_ wrapper for the ERFA_ library (Essential Routines for Fundamental Astronomy), a C library containing key algorithms for astronomy, which is based on the SOFA library published by the International Astronomical Union (IAU). All C routines are wrapped as Numpy_ `universal functions, so that they can be called with scalar or array inputs.
Bug#960119: dh-vim-addon: missing substvar for non-basic Vim flavours?
It sounds good but does not seem to work. :( At least, apt wants to install the vim package despite vim-gtk3 already provides vim. Something strange is happening, and I need a bit more investigation. mymedia@barberry:~$ LANG=C apt-cache policy vim-gtk3 vim-gtk3: Installed: 2:8.1.0875-5ubuntu2.1 Candidate: 2:8.1.0875-5ubuntu2.1 Version table: *** 2:8.1.0875-5ubuntu2.1 500 500 http://ru.archive.ubuntu.com/ubuntu eoan-updates/universe amd64 Packages 500 http://security.ubuntu.com/ubuntu eoan-security/universe amd64 Packages 100 /var/lib/dpkg/status 2:8.1.0875-5ubuntu2 500 500 http://ru.archive.ubuntu.com/ubuntu eoan/universe amd64 Packages mymedia@barberry:~$ LANG=C apt-cache show ~/окр/vim-ale_archive20200509_amd64/build/vim-ale_2.6.0-1~rc1_all.deb | grep Depends Depends: vim (>= 2:8.1.0693-2~) | neovim (>= 0.2.2-1~) mymedia@barberry:~$ LANG=C apt-get -s install ~/окр/vim-ale_archive20200509_amd64/build/vim-ale_2.6.0-1~rc1_all.deb NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'vim-ale' instead of '/home/mymedia/окр/vim-ale_archive20200509_amd64/build/vim-ale_2.6.0-1~rc1_all.deb' The following additional packages will be installed: vim Suggested packages: ctags vim-doc vim-scripts The following NEW packages will be installed: vim vim-ale 0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded. Inst vim (2:8.1.0875-5ubuntu2.1 Ubuntu:19.10/eoan-updates, Ubuntu:19.10/eoan-security [amd64]) Inst vim-ale (2.6.0-1~rc1 local-deb [all]) Conf vim (2:8.1.0875-5ubuntu2.1 Ubuntu:19.10/eoan-updates, Ubuntu:19.10/eoan-security [amd64]) Conf vim-ale (2.6.0-1~rc1 local-deb [all])
Bug#960119: dh-vim-addon: missing substvar for non-basic Vim flavours?
On Sat, May 09, 2020 at 06:40:35PM +0300, Nicholas Guriev wrote:
> Is basic vim package required for addons? It looks I can use an addon with
> vim-gtk, vim-gtk3, or vim-nox, not having the vim package installed. I suggest
> to add these (and possibly vim-athena) to the ${vim-addon:Depends} substvar.
All the packages which provide /usr/bin/vim also declare "Provides:
vim". Similarly, all those that provide /usr/bin/gvim declare
"Provides: gvim". There shouldn't be a need to specify every provider
here.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#960120: [Pkg-javascript-devel] Bug#960120: node-yarnpkg: build with node-babel-loader 8.x (babel 7) fails
On Sat, May 9, 2020 at 9:30 pm, Pirate Praveen wrote: With node-babel-loader >= 8.0 in experimental, build fails with node ./scripts/build-webpack.js Unhandled rejection TypeError: fileDependencies.map is not a function It seems this failure is already present in the current version, so I'm wondering if we can ignore this error for now.
Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2
أحمد المحمودي writes: > On Mon, Apr 27, 2020 at 08:48:59PM -0600, Bdale Garbee wrote: >> As far as I'm concerned, you can feel free to remove geda-gaf from Debian. >> >> I'm personally quite happily living on the fork that I've packaged of >> lepton-eda. Lepton-eda is very actively maintained and improved, and >> while there's a recent new release of geda-gaf, I'm not likely to spend >> any more time working on the geda-gaf packaging. > ---end quoted text--- > > Aren't there any features in gEDA 1.10 that aren't present in Lepton > EDA? That's a reasonable question. I haven't looked much at gEDA since moving to lepton-eda, so I'm probably not the right person to answer this question. However... The lepton-eda fork came into existence at least in part due to the messy integration of xorn (python extension language support) into gEDA. So, almost by definition, anything related to python as an extension language exists in gEDA but not in lepton-eda. By contrast, the lepton-eda code started with a fork of gEDA just before the xorn merge, and has doubled-down since on using guile for as much as possible. I'm personally happy coding in guile and contributed a tEDAx export module to lepton-eda so that I can easily use it with pcb-rnd. From a practical standpoint, 1.10 is the first new gEDA release in a very long time, and it still build depends on guile-2.0 (caring for guile clearly isn't a priority). On the lepton-eda side, the core team is quite active (new commits in the git repo almost every day), has made multiple stable releases since I started packaging it in August of 2018 (1.9.4 to 1.9.10), and they cheerfully did the work to move from guile-2.0 to 2.2 when I pointed out this was going to become an issue for Debian. As a *user*, I'm happily using lepton-eda almost daily, for all of my circuit board design work. That includes ongoing maintenance and support of designs that I started with geda-gaf. So... while I'm sure gEDA could be "saved" in Debian with enough effort, I just don't see the point, and won't put any time or attention on it myself. Bdale signature.asc Description: PGP signature
Bug#960120: node-yarnpkg: build with node-babel-loader 8.x (babel 7) fails
Package: node-yarnpkg Version: 1.22.4-3 Severity: important Similar to #958780, With node-babel-loader >= 8.0 in experimental, build fails with node ./scripts/build-webpack.js Unhandled rejection TypeError: fileDependencies.map is not a function at compiler.run (/<>/scripts/build-webpack.js:118:38) at finalCallback (/usr/share/nodejs/webpack/lib/Compiler.js:257:39) at hooks.done.callAsync.err (/usr/share/nodejs/webpack/lib/Compiler.js:273:13) at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :6:1) at AsyncSeriesHook.lazyCompileHook [as _callAsync] (/usr/share/nodejs/tapable/lib/Hook.js:35:21) at onCompiled (/usr/share/nodejs/webpack/lib/Compiler.js:271:21) at hooks.afterCompile.callAsync.err (/usr/share/nodejs/webpack/lib/Compiler.js:681:15) at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :6:1) at AsyncSeriesHook.lazyCompileHook [as _callAsync] (/usr/share/nodejs/tapable/lib/Hook.js:35:21) at compilation.seal.err (/usr/share/nodejs/webpack/lib/Compiler.js:678:31) at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :6:1) at AsyncSeriesHook.lazyCompileHook [as _callAsync] (/usr/share/nodejs/tapable/lib/Hook.js:35:21) at hooks.optimizeAssets.callAsync.err (/usr/share/nodejs/webpack/lib/Compilation.js:1423:35) at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :6:1) at AsyncSeriesHook.lazyCompileHook [as _callAsync] (/usr/share/nodejs/tapable/lib/Hook.js:35:21) at hooks.optimizeChunkAssets.callAsync.err (/usr/share/nodejs/webpack/lib/Compilation.js:1414:32) as explained in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958780#39 this will need more adjustments to get it to build with babel 7. This is a blocker for uploading node-babel-loader 8.x in unstable.
Bug#960119: dh-vim-addon: missing substvar for non-basic Vim flavours?
Package: dh-vim-addon
Version: 0.2
Severity: wishlist
Dear maintainer,
Is basic vim package required for addons? It looks I can use an addon with
vim-gtk, vim-gtk3, or vim-nox, not having the vim package installed. I suggest
to add these (and possibly vim-athena) to the ${vim-addon:Depends} substvar.
https://salsa.debian.org/vim-team/dh-vim-addon/-/blob/7eae5a5039724dd4e7ea30b1bc597336febcd283/dh_vim-addon#L214
-- System Information:
Debian Release: buster/sid
APT prefers eoan-updates
APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-51-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dh-vim-addon depends on:
pn debhelper
ii perl5.28.1-6build1
ii vim-common 2:8.1.0875-5ubuntu2.1
dh-vim-addon recommends no packages.
dh-vim-addon suggests no packages.
Bug#960118: ifupdown: ifup doesn't check if /etc/network/if-%s.d exists before running run-parts
Package: ifupdown
Version: 0.8.35
Severity: important
I've just hardly bit by a system in which for some reason yet to
discover the otherwise empty directory /etc/network/if-pre-up.d/ was
removed.
At the next boot, the network didn't come up because of
May 9 14:15:55 ifup[310]: run-parts: failed to open directory
/etc/network/if-pre-up.d: No such file or directory
Looking at the code,
https://sources.debian.org/src/ifupdown/0.8.35/execute.c/?hl=181#L181
|static int execute_scripts(interface_defn *ifd, execfn *exec, char *opt) {
|...
|char *command;
|if(asprintf(, "/bin/run-parts %s%s/etc/network/if-%s.d",
ignore_failures ? "" : "--exit-on-error ", verbose ? "--verbose " : "", opt) ==
-1)
|err(1, "asprintf");
|int result = (*exec) (command);
|...
|return ignore_failures ? 1 : result;
|}
Now, `run-parts` just fails if you pass a non-existing directory.
I believe you should check for the directory existence before trying to
run run-parts on it.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#960117: linux-image-5.6.0-1-686: linux-image-5.6.0-1-686-pae starts weird sound at boot on battery
Package: src:linux Version: 5.6.7-1 Severity: important File: linux-image-5.6.0-1-686 Dear Maintainer, I am running in an issue when booting the latest kernel 5.6.0-1-pae. This appears only on 32-bit-version, every computer with 64-bit is running fine. Environment: I am running am EEEPC with a SSD harddrive, which is seperated in several partitions (/boot, /home (luks enc.), /var (luks enc.) , /usr (luks enc.). The batteries are fully charged and in best shape. Issue: When booting on battery, first /usr wants to be decrypted, what is running well. Then, as soon it wants to be /var decrypted, ththere is a loud noise from the speakers (hardly to describe, such a "taktaktaktaktaktak..." with about 5Hz. Ignoring this, the syetem is booting, but the sound stays. I tested with the prior kernel-version 5.5.0-2-686-pae, which works without any isues. I also had to say, that I had an issue with this kernel to the partition of /var, which killed my filesystem (glad, could restore it by using the superblock) and I believe this crash was due to the same bug in kernel-version 5.6.0-1-686 so I set this report to "important" as it might kill something. As a workaround, I am running now kernel 5.5.0-2-686-pae, but it would be nice, if you could fix this issue in kernel 5.6.0-1-686-pae (or higher). Thank you very much for the grrat work! Best regards and stay healthy! Hans *** End of the template - remove these template lines *** -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GSE Express Memory Controller Hub [8086:27ac] (rev 03) Subsystem: ASUSTeK Computer Inc. Mobile 945GSE Express Memory Controller Hub [1043:8340] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Mobile 945GSE Express Integrated Graphics Controller [1043:8340] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03) Subsystem: ASUSTeK Computer Inc. Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [1043:8340] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition Audio Controller [8086:27d8] (rev 02) Subsystem: ASUSTeK Computer Inc. NM10/ICH7 Family High Definition Audio Controller [1043:8398] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 1 [8086:27d0] (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 2 [8086:27d2] (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:1c.3 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 4 [8086:27d6] (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR+ TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 [8086:27c8] (rev
Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2
On Mon, Apr 27, 2020 at 08:48:59PM -0600, Bdale Garbee wrote: > As far as I'm concerned, you can feel free to remove geda-gaf from Debian. > > I'm personally quite happily living on the fork that I've packaged of > lepton-eda. Lepton-eda is very actively maintained and improved, and > while there's a recent new release of geda-gaf, I'm not likely to spend > any more time working on the geda-gaf packaging. ---end quoted text--- Aren't there any features in gEDA 1.10 that aren't present in Lepton EDA ? -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7 GPG Fingerprints: 6E2E E4BB 72E2 F417 D066 6ABF 7B30 B496 A7EF 5761 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: PGP signature
Bug#960101: [Pkg-javascript-devel] Bug#960101: marked as done (node-jsonld, node-rdf-canonize: Build with babel version 7)
Control: reopen -1 On Sat, May 9, 2020 at 2:39 pm, Debian Bug Tracking System wrote: Your message dated Sat, 09 May 2020 14:37:31 + with message-id and subject line Bug#960101: fixed in node-jsonld 1.6.2-4 has caused the Debian Bug report #960101, regarding node-jsonld, node-rdf-canonize: Build with babel version 7 to be marked as done. Please remove build dependency on these two babel 6 binary packages too, node-babel-plugin-transform-object-rest-spread, node-babel-plugin-transform-runtime These are now included in node-babel7 as @babel/plugin-proposal-object-rest-spread and @babel/plugin-transform-runtime
Bug#960108: proftpd-basic: proftpd write pidfile with incorrect mode
I think i've found the problem. The umask configuration is taken into account when the pidfile is created. That's a little bit strange because i think this setting should only taken into account when files are uploaded at runtime. Nevertheless, it seems to be a configuration problem, thus you can close this issue. Volker Am 09.05.20 um 16:33 schrieb Volker Theile: > Hi Hilmar, > > the issue exits for a long time. I have many reports about this issue in > the openmediavault forum. To workaround this issue i added a systemd > drop-in to change the file mode before the 'stop' action is executed. > See > https://github.com/openmediavault/openmediavault/commit/439d11d9ad375101f8f65820013e5d472ff590ca > > I can not say if it always appears and if there must be special > conditions to make it happen. > > Regards > Volker > > Am 09.05.20 um 16:13 schrieb Hilmar Preuße: >> Am 09.05.2020 um 15:29 teilte votdev mit: >> >> Hi Volker, >> >>> The proftpd daemon writes the pidfile with mode 0666 instead of 0644. >>> Because of that it is >>> not possible to stop or restart the daemon with "systemctl stop proftpd" or >>> "systemctl restart proftpd". The reason is the new security check of >>> start-stop-deamon >>> in conjunction with --pidfile. >>> >> I'm failing to reproduce all this. >> >> root@nas1:~# ls -ld /run/proftpd* >> drwxr-xr-x 2 root root 40 May 9 16:07 /run/proftpd >> -rw-r--r-- 1 root root 5 May 9 16:08 /run/proftpd.pid >> -rw-r--r-- 1 root root 32 May 9 16:08 /run/proftpd.scoreboard >> -rw-r--r-- 1 root root 0 May 9 16:08 /run/proftpd.scoreboard.lck >> >> And stopping / restarting works fine. Is this new w/ deb10u5? I'm not >> aware of any changes regarding this between deb10u5 & deb10u4. >> >>> The following error will be logged to syslog. >>> >>> Mai 09 14:42:30 titan proftpd[1296]: Stopping ftp server: >>> proftpdstart-stop-daemon: matching on world-writable pidfile >>> /run/proftpd.pid is insecure >>> Mai 09 14:42:30 titan proftpd[1296]: start-stop-daemon: matching on >>> world-writable pidfile /run/proftpd.pid is insecure >>>
Bug#960116: bad interaction with parameter substitution
Package: dh-python
Version: 4.20200315
Severity: normal
Hello, I try to use parameter substitution in one of my package.
something with this line
# install all the non .py files of the sources
# modules
dh_auto_install -- -s custom --install-args='find modules -path
"modules/cctbx_project" -prune -o -name "__init__.py" -print0 |\
while read -d $$"\0" file; do fdir=`dirname "$$file"`\
; find "$fdir" -maxdepth 1 \\\
-name "*.py" -prune \\\
-o -name "*.c" \\\
-o -name "*.cc" \\\
-o -name "*.cpp" \\\
-o -name "*.h" \\\
-o -name "*.hpp" \\\
-o -name "*.f" \\\
-o -name "SConscript" \\\
-o -name "\.*" \\\
-o -name "*.rst" \\\
-o -name "*.md" \\\
-o -name "*.toml" \\\
-o -name "LICENSE*" \\\
-o -name "AUTHORS*" \\\
-o -type d \\\
-o -print0 |\
while read -d $$"\0" ffile; do \
dh_install -p python3-dials --sourcedir=modules
"$${ffile#modules/}" {install_dir};\
done \
done'
But it failes with this error
E: pybuild pybuild:352: install: plugin custom failed with: 'ffile#modules/'
Traceback (most recent call last):
File "/usr/bin/pybuild", line 350, in main
run(func, i, version, c)
File "/usr/bin/pybuild", line 301, in run
result = func(context, args)
File
Bug#960108: proftpd-basic: proftpd write pidfile with incorrect mode
Hi Hilmar, the issue exits for a long time. I have many reports about this issue in the openmediavault forum. To workaround this issue i added a systemd drop-in to change the file mode before the 'stop' action is executed. See https://github.com/openmediavault/openmediavault/commit/439d11d9ad375101f8f65820013e5d472ff590ca I can not say if it always appears and if there must be special conditions to make it happen. Regards Volker Am 09.05.20 um 16:13 schrieb Hilmar Preuße: > Am 09.05.2020 um 15:29 teilte votdev mit: > > Hi Volker, > >> The proftpd daemon writes the pidfile with mode 0666 instead of 0644. >> Because of that it is >> not possible to stop or restart the daemon with "systemctl stop proftpd" or >> "systemctl restart proftpd". The reason is the new security check of >> start-stop-deamon >> in conjunction with --pidfile. >> > I'm failing to reproduce all this. > > root@nas1:~# ls -ld /run/proftpd* > drwxr-xr-x 2 root root 40 May 9 16:07 /run/proftpd > -rw-r--r-- 1 root root 5 May 9 16:08 /run/proftpd.pid > -rw-r--r-- 1 root root 32 May 9 16:08 /run/proftpd.scoreboard > -rw-r--r-- 1 root root 0 May 9 16:08 /run/proftpd.scoreboard.lck > > And stopping / restarting works fine. Is this new w/ deb10u5? I'm not > aware of any changes regarding this between deb10u5 & deb10u4. > >> The following error will be logged to syslog. >> >> Mai 09 14:42:30 titan proftpd[1296]: Stopping ftp server: >> proftpdstart-stop-daemon: matching on world-writable pidfile >> /run/proftpd.pid is insecure >> Mai 09 14:42:30 titan proftpd[1296]: start-stop-daemon: matching on >> world-writable pidfile /run/proftpd.pid is insecure >> >
Bug#959971: meet.google.com broken with debian build (ff76)
This is the corresponding upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1636632 Either building without --with-system-nss or adding a patch should resolve the problem.
Bug#954020: buster-pu: package zipios++/0.1.5.9+cvs.2007.04.28-10+deb10u1
Hi Salvatore, > The problem is just, the upload is not there. Did an error happen on > uploading? > I'm not DM, so someone has to sponsor the upload. Adam or you, could you please upload it? Thanks, François
Bug#953745: stretch-pu: package proftpd-dfsg/1.3.5b-4+deb9u5
On Sat, 2020-05-09 at 15:57 +0200, Hilmar Preuße wrote: > Am 12.04.2020 um 23:45 teilte Adam D. Barratt mit: > > Hi Adam, > > Ho about that one: will deb9u5 accepted for next oldstable release? > As Julien mentioned in a mail that you should have received on April 26th, if you want to remove the debconf calls in stretch then they need to be removed in unstable first. Per your own previous response: > Seems, we did not remove all references to debconf back in 2017 and we > still read the confmodule file. However we don't use that code any more > since 2017: Whether the package in unstable actually uses debconf to manage its configuration, it *does* still source the debconf confmodule in proftpd-basic.postinst, which is the call that you're proposing to remove in the stretch update. Regards, Adam
Bug#960115: ITP: libtest-metrics-any-perl -- module to assert that code produces metrics via Metrics::Any
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libtest-metrics-any-perl Version : 0.01 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Test-Metrics-Any * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to assert that code produces metrics via Metrics::Any Test::Metrics::Any helps write unit tests which assert that the code under test reports metrics via Metrics::Any. Loading this module automatically sets the Metrics::Any::Adapter type to Test. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#960108: proftpd-basic: proftpd write pidfile with incorrect mode
Am 09.05.2020 um 15:29 teilte votdev mit: Hi Volker, > The proftpd daemon writes the pidfile with mode 0666 instead of 0644. > Because of that it is > not possible to stop or restart the daemon with "systemctl stop proftpd" or > "systemctl restart proftpd". The reason is the new security check of > start-stop-deamon > in conjunction with --pidfile. > I'm failing to reproduce all this. root@nas1:~# ls -ld /run/proftpd* drwxr-xr-x 2 root root 40 May 9 16:07 /run/proftpd -rw-r--r-- 1 root root 5 May 9 16:08 /run/proftpd.pid -rw-r--r-- 1 root root 32 May 9 16:08 /run/proftpd.scoreboard -rw-r--r-- 1 root root 0 May 9 16:08 /run/proftpd.scoreboard.lck And stopping / restarting works fine. Is this new w/ deb10u5? I'm not aware of any changes regarding this between deb10u5 & deb10u4. > The following error will be logged to syslog. > > Mai 09 14:42:30 titan proftpd[1296]: Stopping ftp server: > proftpdstart-stop-daemon: matching on world-writable pidfile > /run/proftpd.pid is insecure > Mai 09 14:42:30 titan proftpd[1296]: start-stop-daemon: matching on > world-writable pidfile /run/proftpd.pid is insecure > -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
