Bug#917613: Regression: Thunderbird dosen't open ("already running" error)
Hello Hansjoerg, Am 25.11.19 um 23:16 schrieb H. Buchberger: > Hi Carsten, > > as my Thunderbird mail profile (not Thunderbird AA profile) was working > well before the upgrade stretch -> buster and did not work any more > after the upgrade, the upgrade must have got something to do with it. no, we don't touch or modify any data within the /home folders without interacting by the user. The only automatic controlled instance that can make changes to the users profile is the Thunderbird application itself. > Unfortunately I don't have a complete back of my system before the > upgrade. But from the history in this bug report I guess that the AA > profile was already defined in stretch - probably disabled. > > So the upgrade might have removed the "disabled" setting. Also here my answer is no, the postinst script for the thunderbird package has some magic to not enable the AA profile within new installations. But it will keep an AA profile as active it it was active before the update. > BTW: During my upgrade stretch -> buster Thunderbird (and Firefox) was > also updated (from version 60.9.0 to now 68.2.2) and after that I had to > "downgrade" my Thunderbird mail profile. Also a bit weird. You can't 'downgrade' your mail profile. The only possible and reasonable action would be to replace the existing profile with an backup. But we are going in circles, the truth can be found in the (sys)log. And the root for issue here will be apparmor. See also https://wiki.debian.org/AppArmor/Debug -- Regards Carsten Schoenert
Bug#945509: libwebkit2gtk-4.0-37: luakit should also force single process
Package: libwebkit2gtk-4.0-37 Version: 2.26.2-1~deb10+1 Severity: normal Dear Maintainer, The transition to 2.26 and the independent web processes als breaks luakit in several ways discussed in https://github.com/luakit/luakit/issues/804. I strongly suspect (though I've not tried it because rebuilding webkit is such a pain) that including luakit in the client list in force-single-process.patch would fix this. Could you do that? -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 5.3.1 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages libwebkit2gtk-4.0-37 depends on: ii bubblewrap 0.3.1-4 ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libegl1 1.1.0-1 ii libenchant1c2a 1.6.0-11.1+b1 ii libfontconfig1 2.13.1-2 ii libfreetype62.9.1-3+deb10u1 ii libgcc1 1:8.3.0-6 ii libgcrypt20 1.8.4-5 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgl1 1.1.0-1 ii libglib2.0-02.58.3-2+deb10u2 ii libgstreamer-gl1.0-01.14.4-2 ii libgstreamer-plugins-base1.0-0 1.14.4-2 ii libgstreamer1.0-0 1.14.4-1 ii libgtk-3-0 3.24.5-1 ii libharfbuzz-icu02.3.1-1 ii libharfbuzz0b 2.3.1-1 ii libhyphen0 2.8.8-7 ii libicu6363.1-6 ii libjavascriptcoregtk-4.0-18 2.26.2-1~deb10+1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libnotify4 0.7.7-4 ii libopenjp2-72.3.0-2 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libpng16-16 1.6.36-6 ii libseccomp2 2.3.3-4 ii libsecret-1-0 0.18.7-1 ii libsoup2.4-12.64.2-2 ii libsqlite3-03.27.2-3 ii libstdc++6 8.3.0-6 ii libtasn1-6 4.13-3 ii libwayland-client0 1.16.0-1 ii libwayland-egl1 1.16.0-1 ii libwayland-server0 1.16.0-1 ii libwebp60.6.1-2 ii libwebpdemux2 0.6.1-2 ii libwoff11.0.2-1 ii libx11-62:1.6.7-1 ii libxcomposite1 1:0.4.4-2 ii libxdamage1 1:1.1.4-3+b3 ii libxml2 2.9.4+dfsg1-7+b3 ii libxslt1.1 1.1.32-2.2~deb10u1 ii xdg-dbus-proxy 0.1.1-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages libwebkit2gtk-4.0-37 recommends: ii gstreamer1.0-alsa 1.14.4-2 pn gstreamer1.0-gl ii gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2 ii gstreamer1.0-plugins-good 1.14.4-1 ii gstreamer1.0-pulseaudio1.14.4-1 ii libgl1-mesa-dri18.3.6-2 libwebkit2gtk-4.0-37 suggests no packages. -- no debconf information
Bug#896460:
Hello, I am packaging jupyter_sphinx whcih is a dependency of the new lmfit-py. But it required at least ipywidgets > 7. Do you plan to upload this new version into Debian ? thanks for considering
Bug#945507: systemd-resolved rejects DNS-over-TLS based on GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER even though gnutls-cli works fine
On Mon 2019-11-25 22:49:06 -0500, Daniel Kahn Gillmor wrote: > I'm attaching an attempt at importing this patch from upstream. It > applies and builds fine, but an unrelated part of the dh_auto_test > failed for me (https://github.com/systemd/systemd/issues/14152) I can confirm that upgrading systemd to a package built with with this patch works fine, and resolves the problem. Please apply it to the debian package! --dkg signature.asc Description: PGP signature
Bug#945507: systemd-resolved rejects DNS-over-TLS based on GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER even though gnutls-cli works fine
Control: tags 945507 + patch
On Mon 2019-11-25 21:18:02 -0500, Daniel Kahn Gillmor wrote:
> Note from the pcaps that the gnutls-cli connection manages to negotiate
> TLS 1.3, while the systemd-resolved connection only manages to elicit a
> TLS 1.2 response from the server for some reason.
>
> I'm seeing this error in systemd-resolved with libgnutls30 3.6.10-5, but
> I also tried this while rolling back to older versions of libgnutls30 --
> version 3.6.7-4 from buster, for example -- and it didn't fix the
> problem.
>
> So i think the issue is something to do with the way that libgnutls is
> being initialized in this version of systemd.
I think this might be related to upstream commit
68805580209cfaa50b2400d1a2e6c6651395, which fixes
https://github.com/systemd/systemd/issues/13528
I'm attaching an attempt at importing this patch from upstream. It
applies and builds fine, but an unrelated part of the dh_auto_test
failed for me (https://github.com/systemd/systemd/issues/14152)
--dkg
From c0f72da3630655cdfdc8a7c2605501b91ad9aa90 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Mon, 25 Nov 2019 21:49:46 -0500
Subject: [PATCH 1/1] try to address #945507
---
...ion-failures-with-TLS-1.3-and-GnuTLS.patch | 31 +++
debian/patches/series | 1 +
2 files changed, 32 insertions(+)
create mode 100644 debian/patches/resolved-fix-connection-failures-with-TLS-1.3-and-GnuTLS.patch
diff --git a/debian/patches/resolved-fix-connection-failures-with-TLS-1.3-and-GnuTLS.patch b/debian/patches/resolved-fix-connection-failures-with-TLS-1.3-and-GnuTLS.patch
new file mode 100644
index 00..0a9e3b4194
--- /dev/null
+++ b/debian/patches/resolved-fix-connection-failures-with-TLS-1.3-and-GnuTLS.patch
@@ -0,0 +1,31 @@
+From: Peter Wu
+Date: Sun, 20 Oct 2019 18:10:31 +0100
+Subject: resolved: fix connection failures with TLS 1.3 and GnuTLS
+
+Prefer TLS 1.3 before TLS 1.2 for DNS-over-TLS support, otherwise
+servers compliant with RFC 8446 might end up agreeing TLS 1.2 plus a
+downgrade signal which is not expected by GnuTLS clients. This manifests
+in the following error:
+
+Failed to invoke gnutls_handshake: An illegal parameter has been received.
+
+Fixes: #13528
+Fixes: v242-962-g9c0624dcdb ("resolved: support TLS 1.3 when using GnuTLS for DNS-over-TLS")
+(cherry picked from commit 68805580209cfaa50b2400d1a2e6c6651395)
+---
+ src/resolve/resolved-dnstls-gnutls.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/resolve/resolved-dnstls-gnutls.c b/src/resolve/resolved-dnstls-gnutls.c
+index 06d635f..7ad9662 100644
+--- a/src/resolve/resolved-dnstls-gnutls.c
b/src/resolve/resolved-dnstls-gnutls.c
+@@ -10,7 +10,7 @@
+ #include "resolved-dnstls.h"
+
+ #if GNUTLS_VERSION_NUMBER >= 0x030600
+-#define PRIORTY_STRING "NORMAL:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.3"
++#define PRIORTY_STRING "NORMAL:-VERS-ALL:+VERS-TLS1.3:+VERS-TLS1.2"
+ #else
+ #define PRIORTY_STRING "NORMAL:-VERS-ALL:+VERS-TLS1.2"
+ #endif
diff --git a/debian/patches/series b/debian/patches/series
index 0735c48a53..fb0ff26618 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -106,3 +106,4 @@ debian/Drop-seccomp-system-call-filter-for-udev.patch
debian/blacklist-upstream-test-25.patch
debian/blacklist-upstream-test-24-ppc64el.patch
udev-drop-SystemCallArchitectures-native-from-systemd-ude.patch
+resolved-fix-connection-failures-with-TLS-1.3-and-GnuTLS.patch
--
2.24.0
signature.asc
Description: PGP signature
Bug#920900: libicu-dev: icu-config is only deprecated
Hello all, I would like to note that pkgdata is now broken because it tries to use [nonexistent] icu-config.
Bug#945387: plinth: [INTL:de] updated German debconf translation
tag 945387 + pending thanks On 23/11/19 1:07 am, Helge Kreutzmann wrote: > Package: plinth > Version: 19.21 > Severity: wishlist > Tags: patch l10n > > Please find the updated German debconf translation for plinth > attached. > > Please place this file in debian/po/ as de.po for your next upload. > > If you update your template, please use > 'msgfmt --statistics ' > to check the po-files for fuzzy or untranslated strings. > > If there are such strings, please contact me so I can update the > German translation. This patch has been merged. Thank you for updating the translation. -- Sunil
Bug#945508: fastboot: hangs indefinitely when trying to flash a recovery
Package: fastboot Version: 1:8.1.0+r23-5 Severity: important I'm trying to flash a TWRP recovery to a Xiaomi Mix 2s phone: ~$ fastboot devices fastboot ~$ fastboot flash recovery twrp-3.3.1-1-polaris.img The command hangs - it does not return, display any message to the terminal, or log anything, until 120 seconds have passed, at which point the following appears in syslog: Nov 25 13:06:22 lila kernel: [ 363.660869] INFO: task fastboot:2753 blocked for more than 120 seconds. Nov 25 13:06:22 lila kernel: [ 363.660877] Tainted: G OE 5.3.0-2-amd64 #1 Debian 5.3.9-3 Nov 25 13:06:22 lila kernel: [ 363.660880] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 25 13:06:22 lila kernel: [ 363.660884] fastbootD0 2753 2497 0x Nov 25 13:06:22 lila kernel: [ 363.660889] Call Trace: Nov 25 13:06:22 lila kernel: [ 363.660902] ? __schedule+0x2b9/0x6c0 Nov 25 13:06:22 lila kernel: [ 363.660908] schedule+0x39/0xa0 Nov 25 13:06:22 lila kernel: [ 363.660914] schedule_timeout+0x20f/0x300 Nov 25 13:06:22 lila kernel: [ 363.660941] ? usb_hcd_submit_urb+0xc0/0xbf0 [usbcore] Nov 25 13:06:22 lila kernel: [ 363.660948] wait_for_completion_timeout+0x126/0x170 Nov 25 13:06:22 lila kernel: [ 363.660954] ? wake_up_q+0x60/0x60 Nov 25 13:06:22 lila kernel: [ 363.660974] usb_start_wait_urb+0x83/0x160 [usbcore] Nov 25 13:06:22 lila kernel: [ 363.660998] proc_bulk+0x175/0x310 [usbcore] Nov 25 13:06:22 lila kernel: [ 363.661018] usbdev_do_ioctl+0x311/0xf50 [usbcore] Nov 25 13:06:22 lila kernel: [ 363.661038] usbdev_ioctl+0xa/0x10 [usbcore] Nov 25 13:06:22 lila kernel: [ 363.661045] do_vfs_ioctl+0x40e/0x670 Nov 25 13:06:22 lila kernel: [ 363.661052] ksys_ioctl+0x5e/0x90 Nov 25 13:06:22 lila kernel: [ 363.661057] __x64_sys_ioctl+0x16/0x20 Nov 25 13:06:22 lila kernel: [ 363.661063] do_syscall_64+0x53/0x140 Nov 25 13:06:22 lila kernel: [ 363.661067] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Nov 25 13:06:22 lila kernel: [ 363.661072] RIP: 0033:0x7ff70cb255b7 Nov 25 13:06:22 lila kernel: [ 363.661082] Code: Bad RIP value. Nov 25 13:06:22 lila kernel: [ 363.661085] RSP: 002b:7fffb4e068a8 EFLAGS: 0246 ORIG_RAX: 0010 Nov 25 13:06:22 lila kernel: [ 363.661089] RAX: ffda RBX: 7fffb4e068c0 RCX: 7ff70cb255b7 Nov 25 13:06:22 lila kernel: [ 363.661091] RDX: 7fffb4e068d0 RSI: c0185502 RDI: 0004 Nov 25 13:06:22 lila kernel: [ 363.661093] RBP: 0006 R08: 557ae441bca0 R09: 7fffb4e06b50 Nov 25 13:06:22 lila kernel: [ 363.661095] R10: R11: 0246 R12: 7fffb4e068d0 Nov 25 13:06:22 lila kernel: [ 363.661097] R13: 557ae441bc80 R14: 0040 R15: 0040 The same thing appears every 120 seconds. When the USB cable is disconnected, fastboot prints this rather incoherent message to the terminal and then terminates: target didn't report max-download-size sending 'recovery' (59720 KB)... FAILED (command write failed (Success)) finished. total time: 0.000s -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (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.29-3 ii libgcc11:9.2.1-19 ii libstdc++6 9.2.1-19 Versions of packages fastboot recommends: ii android-sdk-platform-tools 27.0.0+12 fastboot suggests no packages. -- no debconf information
Bug#945507: systemd-resolved rejects DNS-over-TLS based on GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER even though gnutls-cli works fine
Package: systemd Version: 243-8 On an amd64 system running sid, with the following settings reported by resolvectl: DNSOverTLS setting: opportunistic DNSSEC setting: allow-downgrade DNSSEC supported: no Current DNS Server: 199.58.81.218 DNS Servers: 199.58.81.218 2001:470:1c:76d::53 The TLS connections don't work for some reason (the host above is dns.cmrg.net, which only offers DNS-over-TLS). /etc/resolv.conf is a symlink to /lib/systemd/resolv.conf I attached ltrace to the systemd-resolved process, while trying to elicit a domain name with "ping" and saw this interaction with GnuTLS: 3437 20:49:39 gnutls_init(0x7ffcfe82eae8, 266, 16, 608) = 0 3437 20:49:39 gnutls_priority_set_direct(0x55f47918c140, 0x55f4772712b8, 0, 0) = 0 3437 20:49:39 gnutls_credentials_set(0x55f47918c140, 1, 0x55f478eb0140, 0) = 0 3437 20:49:39 gnutls_handshake_set_timeout(0x55f47918c140, 0x, 0, 0x55f47918a930) = 0x9c40 3437 20:49:39 gnutls_transport_set_ptr2(0x55f47918c140, 19, 0x55f47918a680, 0x55f47918a930) = 0x9c40 3437 20:49:39 gnutls_transport_set_vec_push_function(0x55f47918c140, 0x55f47723cc80, 0x55f47918a680, 0x55f47918a930) = 0x9c40 3437 20:49:39 gnutls_handshake(0x55f47918c140, 0x55f47723cc80, 0x55f47918a680, 0x55f47918a930 3437 20:49:39 sendmsg(19, 0x7ffcfe82e630, 0x2000, 1) = -1 3437 20:49:39 __errno_location() = 0x7fc6d84bbac0 3437 20:49:39 __errno_location() = 0x7fc6d84bbac0 3437 20:49:39 <... gnutls_handshake resumed> ) = 0xffe4 3437 20:49:39 gnutls_error_is_fatal(0xffe4, 0, -128, 0) = 0 0xffe4 is -55, which is GNUTLS_E_RECEIVED_ILLEGAL_PARAMETER, according to: https://gnutls.org/manual/gnutls.html#Error-codes I'm attaching a pcap for all the traffic on port 853 from the above attempt. I don't see any obviously illegal parameters there. In further debugging, i tried using gnutls-cli to connect directly to it, and that worked fine: $ gnutls-cli --sni-hostname=dns.cmrg.net --verify-hostname=dns.cmrg.net 199.58.81.218:853 Processed 128 CA certificate(s). Resolving '199.58.81.218:853'... Connecting to '199.58.81.218:853'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `CN=dns.cmrg.net', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x03a4d7448cc89c9444776bbf992fe74a4252, RSA key 2048 bits, signed using RSA-SHA256, activated `2019-11-01 06:00:16 UTC', expires `2020-01-30 06:00:16 UTC', pin-sha256="3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=" Public Key ID: sha1:44be3735f2f6cf668b6143335d8189250a7c5cd3 sha256:dc8387492e3c28e73fce590a1ad238e9af5363d3cf283546844dd6d994b8259a Public Key PIN: pin-sha256:3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= - Certificate[1] info: - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x0a014142015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=" - Status: The certificate is trusted. - Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) - Options: - Handshake was completed - Simple Client Mode: I'm attaching a pcap from the gnutls-cli connection as well. Note from the pcaps that the gnutls-cli connection manages to negotiate TLS 1.3, while the systemd-resolved connection only manages to elicit a TLS 1.2 response from the server for some reason. I'm seeing this error in systemd-resolved with libgnutls30 3.6.10-5, but I also tried this while rolling back to older versions of libgnutls30 -- version 3.6.7-4 from buster, for example -- and it didn't fix the problem. So i think the issue is something to do with the way that libgnutls is being initialized in this version of systemd. I do not see this misbehavior on a comparable VM running debian buster (with systemd 241-7~deb10u2). on the buster VM, the nameservice works fine with systemd-resolved. let me know if you want me to try some other debugging step. --dkg systemd-resolved.pcapng Description: Binary data gnutls-cli.pcapng Description: Binary data signature.asc Description: PGP signature
Bug#945506: openafs-modules-dkms: module FTBFS for Linux 5.3.0-2-amd64
Package: openafs-modules-dkms Version: 1.8.5-1 Severity: serious Tags: ftbfs Justification: fails to build from source User: debian...@lists.debian.org Usertags: piuparts Hi, openafs-modules-dkms/sid fails to build the kernel module for the current kernel (5.3.0-2-amd64) in a minimal sid chroot with linux-headers-amd64 installed: Setting up openafs-modules-dkms (1.8.5-1) ... Loading new openafs-1.8.5 DKMS files... It is likely that 5.2.14 belongs to a chroot's host Building for 5.3.0-2-amd64 Building initial module for 5.3.0-2-amd64 Error! Bad return status for module build on kernel: 5.3.0-2-amd64 (x86_64) Consult /var/lib/dkms/openafs/1.8.5/build/make.log for more information. dpkg: error processing package openafs-modules-dkms (--configure): installed openafs-modules-dkms package post-installation script subprocess returned error exit status 10 Processing triggers for libc-bin (2.29-3) ... Errors were encountered while processing: openafs-modules-dkms make.log contains: DKMS make.log for openafs-1.8.5 for kernel 5.3.0-2-amd64 (x86_64) Fri Nov 15 21:42:48 UTC 2019 checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/var/lib/dkms/openafs/1.8.5/build': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details So the sources are looking for "gcc" while they should get the correct compiler to use from the kernel headers ... the module must be built with the same compiler version as the kernel itself, which is not neccessarily the system default "gcc", and for Debian it's always a versioned gcc-N. (The linux-headers- packages transitively depend on the correct versioned gcc package.) Andreas openafs-modules-dkms_1.8.5-1.log.gz Description: application/gzip
Bug#945316: polymake: FTBFS with perl 5.30
On 26/11/2019 00.00, Benjamin Lorenz wrote: > tldr: please rebuild normaliz and then try polymake again. Thanks for the analysis. binNMU of normaliz requested: #945504 > This is very weird but after some digging through backtraces, headers > and bugzilla I am quite sure that this is caused by: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267 > that debian already backported the fix for the gcc bug to gcc 9.2.1-16 Since you looked into this: when was this gcc bug introduced in Debian? We should probably make a note to rebuild everything that was built with the buggy libstdc++ before the release of bullseye... Andreas
Bug#945505: ginkgocadx: FTBFS with current insighttoolkit and gdcm
Source: ginkgocadx Version: 3.8.8-2 Severity: serious User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu focal Dear maintainers, The ginkgocadx package is not buildable in unstable with the current insighttoolkit4 and gdcm: [...] arg [/usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o] ==> ignore arg [/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o] ==> ignore collapse library dir [/usr/lib/gcc/x86_64-linux-gnu/9] ==> [/usr/lib/gcc/x86_64-linux-gnu/9] collapse library dir [/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu] ==> [/usr/lib/x86_64-linux-gnu] collapse library dir [/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib] ==> [/usr/lib] collapse library dir [/lib/x86_64-linux-gnu] ==> [/lib/x86_64-linux-gnu] collapse library dir [/lib/../lib] ==> [/lib] collapse library dir [/usr/lib/x86_64-linux-gnu] ==> [/usr/lib/x86_64-linux-gnu] collapse library dir [/usr/lib/../lib] ==> [/usr/lib] collapse library dir [/usr/lib/gcc/x86_64-linux-gnu/9/../../..] ==> [/usr/lib] implicit libs: [stdc++;m;gcc_s;gcc;c;gcc_s;gcc] implicit dirs: [/usr/lib/gcc/x86_64-linux-gnu/9;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib] implicit fwks: [] dh_auto_configure: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu .. returned exit code 1 make: *** [debian/rules:18: build] Error 2 [...] (https://launchpad.net/ubuntu/+source/ginkgocadx/3.8.8-2build1/+build/18156070) I see nothing in the cmake output that looks like an error to me, up until the exit code, so I'm not sure what to make of this failure. Please note that ginkgocadx has been removed from testing at some point, allowing the new insighttoolkit4 + gdcm to transition there, but somehow this never resulted in an RC bug filed against ginkgocadx. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#945504: nmu: normaliz_3.8.1+ds-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu normaliz_3.8.1+ds-1 . ANY . unstable . -m "Rebuild with gcc-9 with PR libstdc++/92267 fix." This fixes an ABI incompatibility in std::deque that causes segfaults while building polymake, see 945316 for analysis. Andreas
Bug#945502: please update pdftk-java to 3.0.8
Package: pdftk-java Version: 3.0.6-1 Severity: wishlist Dear Maintainer, Please update pdftk-java to 3.0.8 as upstream released about a month ago. the 3.0.7 seems to fix a crash involving passwords and file handles (java.lang.NullPointerException) as shared in the changelog [1] . The updated version 3.0.8 might be valuable for also old-stable as it still serves 1.7 [2] . Look forward to the new updates in Debian testing. 1. https://gitlab.com/pdftk-java/pdftk/blob/master/CHANGELOG.md 2. https://tracker.debian.org/pkg/openjdk-7 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-debug'), (100, 'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pdftk-java depends on: ii default-jre-headless [java8-runtime-headless] 2:1.11-72 ii libbcprov-java1.61-1 ii libcommons-lang3-java 3.8-2 ii openjdk-11-jre-headless [java8-runtime-headless] 11.0.5+10-2 pdftk-java recommends no packages. Versions of packages pdftk-java suggests: ii poppler-utils [xpdf-utils] 0.71.0-6 -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
Bug#945503: ITP: fcitx5-qt -- Qt library and IM module for fcitx5
Package: wnpp Severity: wishlist Owner: Boyuan Yang X-Debbugs-CC: debian-de...@lists.debian.org * Package name: fcitx5-qt Version : 0.0~git2019.000427e Upstream Author : Weng Xuetian * URL : https://github.com/fcitx/fcitx5-qt * License : LGPL-2.1+ or BSD-3-Clause Programming Lang: C++/Qt Description : Qt library and IM module for fcitx5 This package (fcitx5-qt) provides the Qt5 support for fcitx5, the next generation of Fcitx Input Method Framework (fcitx). -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#945501: python-statsmodels-doc: unhandled symlink to directory conversion: /usr/share/doc/python-statsmodels-doc/examples
Package: python-statsmodels-doc Version: 0.10.1-5 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: stable -> testing -> sid For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade It is recommended to use the dpkg-maintscript-helper commands 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) to perform the conversion, ideally using d/$PACKAGE.maintscript. See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. >From the attached log (scroll to the bottom...): 0m51.7s ERROR: installs objects over existing directory symlinks: /usr/share/doc/python-statsmodels-doc/examples/executed (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/executed (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples /usr/share/doc/python-statsmodels-doc/examples/executed/categorical_interaction_plot.ipynb (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/executed/categorical_interaction_plot.ipynb (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples /usr/share/doc/python-statsmodels-doc/examples/executed/chi2_fitting.ipynb (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/executed/chi2_fitting.ipynb (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples /usr/share/doc/python-statsmodels-doc/examples/executed/discrete_choice_example.ipynb (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/executed/discrete_choice_example.ipynb (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples /usr/share/doc/python-statsmodels-doc/examples/executed/discrete_choice_overview.ipynb (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/executed/discrete_choice_overview.ipynb (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples /usr/share/doc/python-statsmodels-doc/examples/executed/distributed_estimation.ipynb (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/executed/distributed_estimation.ipynb (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples /usr/share/doc/python-statsmodels-doc/examples/executed/exponential_smoothing.ipynb (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/executed/exponential_smoothing.ipynb (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples /usr/share/doc/python-statsmodels-doc/examples/executed/formulas.ipynb (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/executed/formulas.ipynb (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples /usr/share/doc/python-statsmodels-doc/examples/executed/generic_mle.ipynb (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/executed/generic_mle.ipynb (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples /usr/share/doc/python-statsmodels-doc/examples/executed/glm.ipynb (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/executed/glm.ipynb (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples /usr/share/doc/python-statsmodels-doc/examples/executed/glm_formula.ipynb (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/executed/glm_formula.ipynb (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples [...] /usr/share/doc/python-statsmodels-doc/examples/python/tsa_arma_0.py (python-statsmodels-doc) != /usr/share/doc/python-statsmodels/examples/python/tsa_arma_0.py (?) /usr/share/doc/python-statsmodels-doc/examples -> ../python-statsmodels/examples
Bug#945500: mopidy-doc: unhandled symlink to directory conversion: /usr/share/doc/mopidy/html
Package: mopidy-doc Version: 2.3.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: buster->sid buster->bullseye For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade It is recommended to use the dpkg-maintscript-helper commands 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) to perform the conversion, ideally using d/$PACKAGE.maintscript. See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. >From the attached log (scroll to the bottom...): 0m28.5s ERROR: installs objects over existing directory symlinks: /usr/share/doc/mopidy/html/_images (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/api_explorer.jpg (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/api_explorer.jpg (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/auto.jpg (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/auto.jpg (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/graphviz-447df13b0da1e5b321116097b13e78f159de2dad.png (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/graphviz-447df13b0da1e5b321116097b13e78f159de2dad.png (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/graphviz-447df13b0da1e5b321116097b13e78f159de2dad.png.map (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/graphviz-447df13b0da1e5b321116097b13e78f159de2dad.png.map (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/graphviz-608d5bd384e8795489b24521adabe750e806c0f5.png (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/graphviz-608d5bd384e8795489b24521adabe750e806c0f5.png (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/graphviz-608d5bd384e8795489b24521adabe750e806c0f5.png.map (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/graphviz-608d5bd384e8795489b24521adabe750e806c0f5.png.map (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/graphviz-83721fec34402e69947264b6c560c4315088ccdf.png (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/graphviz-83721fec34402e69947264b6c560c4315088ccdf.png (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/graphviz-83721fec34402e69947264b6c560c4315088ccdf.png.map (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/graphviz-83721fec34402e69947264b6c560c4315088ccdf.png.map (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/graphviz-b5588201ffdf8aaba776d9ceb236875d6720583a.png (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/graphviz-b5588201ffdf8aaba776d9ceb236875d6720583a.png (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/graphviz-b5588201ffdf8aaba776d9ceb236875d6720583a.png.map (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/graphviz-b5588201ffdf8aaba776d9ceb236875d6720583a.png.map (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/graphviz-e4666ca1e57619dbb041f21a20175b49776bd1e6.png (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/graphviz-e4666ca1e57619dbb041f21a20175b49776bd1e6.png (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/graphviz-e4666ca1e57619dbb041f21a20175b49776bd1e6.png.map (mopidy-doc) != /usr/share/doc/mopidy-doc/html/_images/graphviz-e4666ca1e57619dbb041f21a20175b49776bd1e6.png.map (?) /usr/share/doc/mopidy/html -> ../mopidy-doc/html /usr/share/doc/mopidy/html/_images/graphviz-e6d7a515b0f9f0d09aee0c96d6e17e3650501244.png (mopidy-doc) !=
Bug#945499: debcargo copyright hint is confused by 'license = "GPL-2.0-or-later"' in Cargo.toml
Package: debcargo Version: 2.4.0-1 I updated buffered-reader from 0.11.0 to 0.12.0 upstream changed their licensing in Cargo.toml from: license = "GPL-3.0" to license = "GPL-2.0-or-later" The result is that debcargo seems to think that there's a license named "-later" and a license named "GPL-2.0-" I'm translating this by hand to "GPL-2+" in debian/copyright, but it'd be nice if debcargo was clever enough to deal with this correctly. The stanza i'm using for "GPL-2+" is: License: GPL-2+ This program can be redistributed under the GNU General Public License version 2 or (at your option) any later version. . Debian systems provide the GPL v2 in /usr/share/common-licenses/GPL-2 Thanks for maintaining debcargo! --dkg signature.asc Description: PGP signature
Bug#945498: whatweb: unhandled symlink to directory conversion: /usr/share/whatweb/my-plugins
Package: whatweb Version: 0.5.0-1 an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: buster->sid buster->bullseye For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade It is recommended to use the dpkg-maintscript-helper commands 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) to perform the conversion, ideally using d/$PACKAGE.maintscript. See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. >From the attached log (scroll to the bottom...): 0m36.7s ERROR: installs objects over existing directory symlinks: /usr/share/whatweb/my-plugins/plugin-tutorial-1.rb (whatweb) != /var/lib/whatweb/my-plugins/plugin-tutorial-1.rb (?) /usr/share/whatweb/my-plugins -> /var/lib/whatweb/my-plugins /usr/share/whatweb/my-plugins/plugin-tutorial-2.rb (whatweb) != /var/lib/whatweb/my-plugins/plugin-tutorial-2.rb (?) /usr/share/whatweb/my-plugins -> /var/lib/whatweb/my-plugins /usr/share/whatweb/my-plugins/plugin-tutorial-3.rb (whatweb) != /var/lib/whatweb/my-plugins/plugin-tutorial-3.rb (?) /usr/share/whatweb/my-plugins -> /var/lib/whatweb/my-plugins /usr/share/whatweb/my-plugins/plugin-tutorial-4.rb (whatweb) != /var/lib/whatweb/my-plugins/plugin-tutorial-4.rb (?) /usr/share/whatweb/my-plugins -> /var/lib/whatweb/my-plugins /usr/share/whatweb/my-plugins/plugin-tutorial-5.rb (whatweb) != /var/lib/whatweb/my-plugins/plugin-tutorial-5.rb (?) /usr/share/whatweb/my-plugins -> /var/lib/whatweb/my-plugins /usr/share/whatweb/my-plugins/plugin-tutorial-6.rb (whatweb) != /var/lib/whatweb/my-plugins/plugin-tutorial-6.rb (?) /usr/share/whatweb/my-plugins -> /var/lib/whatweb/my-plugins /usr/share/whatweb/my-plugins/plugin-tutorial-7.rb (whatweb) != /var/lib/whatweb/my-plugins/plugin-tutorial-7.rb (?) /usr/share/whatweb/my-plugins -> /var/lib/whatweb/my-plugins cheers, Andreas whatweb_0.5.0-1.log.gz Description: application/gzip
Bug#898395: dh-make-golang: missing dep on golang-golang-x-tools for digraph
Control: fixed -1 0.0~git20180827.d94f0cb-1 On Mon, 2019-11-25 at 08:37 -0700, Anthony Fok wrote: > Both of these changes entered Debian sid via Dr. Tobias Quathamer's > upload of dh-make-golang (0.0~git20180827.d94f0cb-1) on 2018-09-15, > fixing the bug. Excellent, thanks. PS: please use a versioned -done message in future if closing the bug via debian/changelog was forgotten by the uploader. https://www.debian.org/Bugs/Developer#closing -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#945497: initramfs-tools: Resume function does not check for swap file
Package: initramfs-tools
Version: 0.133ubuntu10
Severity: normal
Dear Maintainer,
The resume hook script (/usr/share/initramfs-tools/hooks/resume) does not check
for a swap file. It checks for a swap device referenced by the RESUME variable.
The RESUME_OFFSET variable is additionally used to point to a file in the
RESUME device that acts as the swap device. In this case, since RESUME points
to a standard file system, a warning is generated:
W: initramfs-tools configuration sets RESUME=$RESUME
W: but no matching swap device is available.
The following contains a possible solution to check for a swap file. It relies
on a set RESUME_OFFSET variable indicating a swap file. At least two files
should be modified: 1) the resume hook script and 2) the mkinitramfs script.
The resume script contains the following line numbered items. The unnumbered
lines contain a possible fix to check for the use of a swap file.
20 # First check if a location is set and is a valid swap partition.
21 # If so, the config file will be copied in and there is nothing to do.
22 if [ -n "$RESUME" ] && [ "$RESUME" != auto ]; then
23 if [ "$RESUME" = none ]; then
24 exit 0
25 fi
if resume_dev_node="$(resolve_device "$RESUME")"; then
if [ -z "$RESUME_OFFSET" ] && \
blkid -p -n swap "$resume_dev_node" >/dev/null 2>&1;
then
exit 0
fi
# Assume RESUME_OFFSET is a proper offset pointing to
# the first data block of an inode in RESUME.
# Then, the swap filename should be in /proc/swaps.
# Get largest filename that is NOT a /dev/...
for resume_filename in $( grep -v ^/dev/ /proc/swaps |
grep ^/ | sort -rnk3 | cut -d " " -f 1 ); do
if [ -n "$resume_filename" ] && \
blkid -p -n swap "$resume_filename"
>/dev/null 2>&1; then
exit 0
fi
break
done
echo >&2 "W: initramfs-tools configuration sets
RESUME=$RESUME and
echo >&2 "W:
RESUME_OFFSET=$RESUME_OFFSET"
echo >&2 "W: but no matching swap file is available."
29 fi
30
31 echo >&2 "W: initramfs-tools configuration sets RESUME=$RESUME"
32 echo >&2 "W: but no matching swap device is available."
33 fi
Getting a file name from an inode from a block offset might be done, but is
problematic as tools related to this are dependent on the file system. For
ext*, this could be:
resume_inode=$( debugfs -R "icheck $RESUME_OFFSET" $resume_dev_node
2>/dev/null | tail -1 | cut -f2 )
resume_fn=$( debugfs -R "ncheck ${RESUME_INODE}" ${RESUME_DEV} 2>/dev/null |
tail -1 | cut -f2 )
However, this process is not generic and may not be available for every file
system.
Additionally, the mkinitramfs script (/usr/sbin/mkinitramfs) does not export
the RESUME_OFFSET variable. It should be exported for use by the hook scripts.
242 # Export environment for hook scripts.
243 #
244 export MODULESDIR
245 export version
246 export CONFDIR
247 export DESTDIR
248 export DPKG_ARCH
249 export verbose
250 export MODULES
251 export BUSYBOX
252 export COMPCACHE_SIZE
253 export RESUME
export RESUME_OFFSET
254
-- System Information:
Debian Release: buster/sid
APT prefers eoan-updates
APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan'),
(100, 'eoan-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-23-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages initramfs-tools depends on:
ii initramfs-tools-core 0.133ubuntu10
ii linux-base4.5ubuntu2
initramfs-tools recommends no packages.
Versions of packages initramfs-tools suggests:
ii bash-completion 1:2.9-1ubuntu1
-- no debconf information
Bug#942469: r-cran-rmarkdown: directory to symlink conversion not correctly handled on upgrade
Followup-For: Bug #942469 Hi, this bug is also reproducible in piuparts on upgrades from buster to sid. An upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: buster -> sid For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade It is recommended to use the dpkg-maintscript-helper commands 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) to perform the conversion, ideally using d/$PACKAGE.maintscript. See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. >From the attached log (scroll to the bottom...): 1m6.5s ERROR: FAIL: silently overwrites files via directory symlinks: /usr/lib/R/site-library/rmarkdown/rmd/h/bootstrap/shim/html5shiv.min.js (r-cran-rmarkdown) != /usr/lib/R/site-library/shiny/www/shared/bootstrap/shim/html5shiv.min.js (r-cran-shiny) /usr/lib/R/site-library/rmarkdown/rmd/h/bootstrap/shim -> ../../../../shiny/www/shared/bootstrap/shim /usr/lib/R/site-library/rmarkdown/rmd/h/bootstrap/shim/respond.min.js (r-cran-rmarkdown) != /usr/lib/R/site-library/shiny/www/shared/bootstrap/shim/respond.min.js (r-cran-shiny) /usr/lib/R/site-library/rmarkdown/rmd/h/bootstrap/shim -> ../../../../shiny/www/shared/bootstrap/shim cheers, Andreas r-cran-rmarkdown_1.17+dfsg-1.log.gz Description: application/gzip
Bug#945316: polymake: FTBFS with perl 5.30
On 23/11/2019 20.30, Andreas Beckmann wrote: > Control: affects 941933 + src:polymake > Control: retitle -1 polymake: FTBFS with normaliz 3.8.1: segfaults during > tests > > On 23/11/2019 10.45, Benjamin Lorenz wrote: >> On 22/11/2019 22.06, Andreas Beckmann wrote: >>> polymake FTBFS against perl 5.30: > >> This was already reported and should be fixed with >> https://bugs.debian.org/941933 >> but it seems that the builds need to be triggered again as the logs are >> older than the normaliz 3.8.1+ds-1 upload. > > OK, tried my first self-served give-backs ... > > ... some architectures succeeed (arm64, s390x), some had tests failing > with segmentation faults (amd64, i386, armhf, ppc64el), mips*el is > still building. > > https://buildd.debian.org/status/package.php?p=polymake=unstable > > Andreas > tldr: please rebuild normaliz and then try polymake again. This is very weird but after some digging through backtraces, headers and bugzilla I am quite sure that this is caused by: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267 The effect is that using the same std::deque template instantiation in different libraries built with gcc 8 and gcc 9 can cause segfaults because of an ABI incompatibility. In this case libppl.so.14.0.0 was built with gcc 8 and libnormaliz with gcc 9 (9.2.1-12), both of them are using std::deque. My build for polymake was with gcc 9 (9.2.1-19). So I rebuilt ppl which to my surprise didn't help, but then I noticed that debian already backported the fix for the gcc bug to gcc 9.2.1-16 (see https://tracker.debian.org/news/1075824/accepted-gcc-9-921-16-source-into-unstable/). This means that instead of ppl only normaliz needed to be rebuilt with gcc >= 9.2.1-16. Some logs from my experiments (rebuilding polymake is not necessary for testing this, just switching out the other libraries): ### current normaliz build from unstable (ppl as well): $ file /usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1 /usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=49042b16a0c8fd0e5ecec9aa50e4fcf70842b8d5, stripped $ objdump -s -j .comment /usr/lib/debug/.build-id/49/042b16a0c8fd0e5ecec9aa50e4fcf70842b8d5.debug Contents of section .comment: 4743433a 20284465 6269616e 20392e32 GCC: (Debian 9.2 0010 2e312d31 32292039 2e322e31 20323031 .1-12) 9.2.1 201 0020 39313032 320091022. lorenz@debian-unstable-amd64:~/polymake-3.2r4$ perl perl/polymake --script run_testcases --applications polytope --examples totally_dual_integral *** Testing in application polytope *** testing Examples: [ /functions/Optimization/totally_dual_integral ] 1Segmentation fault ### Installing my new local normaliz build: # dpkg -i libnormaliz-dev_3.8.1+ds-1_amd64.deb libnormaliz-dev-common_3.8.1+ds-1_all.deb libnormaliz3_3.8.1+ds-1_amd64.deb libnormaliz3-dbgsym_3.8.1+ds-1_amd64.deb $ file /usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1 /usr/lib/x86_64-linux-gnu/libnormaliz.so.3.8.1: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=836dd385fe81deb4ca8b25dc9552a677ec24cc48, stripped $ objdump -s -j .comment /usr/lib/debug/.build-id/83/6dd385fe81deb4ca8b25dc9552a677ec24cc48.debug Contents of section .comment: 4743433a 20284465 6269616e 20392e32 GCC: (Debian 9.2 0010 2e312d31 39292039 2e322e31 20323031 .1-19) 9.2.1 201 0020 39313130 390091109. $ perl perl/polymake --script run_testcases --applications polytope --examples "totally_dual_integral" *** Testing in application polytope *** testing Examples: [ /functions/Optimization/totally_dual_integral ] 1 OK *** Summary *** *** All tests successful *** For reference the top of the backtrace for the segfault with some weird values for __n and __pos for the std::deque: [ /functions/Optimization/totally_dual_integral ] 1 Program received signal SIGSEGV, Segmentation fault. 0x7114972c in std::deque >::_M_fill_insert (this=0x7fffab88, __pos=, __n=140737488330560, __x=) at /usr/include/c++/8/bits/deque.tcc:305 305 /usr/include/c++/8/bits/deque.tcc: No such file or directory. (gdb) bt #0 0x7114972c in std::deque >::_M_fill_insert (this=0x7fffab88, __pos=, __n=140737488330560, __x=) at /usr/include/c++/8/bits/deque.tcc:305 #1 0x70f110af in std::deque >::resize (this=0x7fffab88, __new_size=, __x=) at /usr/include/c++/9/bits/stl_deque.h:757 #2 0x70f14a77 in libnormaliz::Full_Cone::Full_Cone (this=0x7fffa0f0, M=..., do_make_prime=) at /usr/include/c++/9/bits/stl_vector.h:915 #3 0x70e579cf in libnormaliz::Cone<__gmp_expr<__mpz_struct [1], __mpz_struct [1]> >::compute_full_cone (this=this@entry=0x7fffc380, ToCompute=...) at ../../source/libnormaliz/cone.cpp:2899 Benjamin signature.asc Description: OpenPGP digital signature
Bug#917613: Regression: Thunderbird dosen't open ("already running" error)
Hi Carsten, as my Thunderbird mail profile (not Thunderbird AA profile) was working well before the upgrade stretch -> buster and did not work any more after the upgrade, the upgrade must have got something to do with it. (The mail profile is symlinked, that should be the reason why Thunderbird was not able to use it with the AA profile active.) Unfortunately I don't have a complete back of my system before the upgrade. But from the history in this bug report I guess that the AA profile was already defined in stretch - probably disabled. So the upgrade might have removed the "disabled" setting. BTW: During my upgrade stretch -> buster Thunderbird (and Firefox) was also updated (from version 60.9.0 to now 68.2.2) and after that I had to "downgrade" my Thunderbird mail profile. Also a bit weird. -- Regards Hansjörg Am 25.11.19 um 09:11 schrieb Carsten Schoenert: Hi, the question is why the AA profile for Thunderbird was active? The default is that Thunderbird hasn't an activated AA profile. In difference to buster it might be that same data within the profile are not compatible with apparmor version in stretch.
Bug#945495: ocaml-nox: missing Breaks+Replaces: ocaml-compiler-libs (<< 4.08)
Package: ocaml-nox Version: 4.08.1-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: affects -1 + libguestfs-ocaml-dev Hi, during a test with piuparts I noticed your package fails to upgrade from 'stable'. It installed fine in 'stable', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): dpkg: considering deconfiguration of ocaml-base-nox, which would be broken by installation of ocaml-nox ... dpkg: yes, will deconfigure ocaml-base-nox (broken by ocaml-nox) Preparing to unpack .../02-ocaml-nox_4.08.1-4_amd64.deb ... De-configuring ocaml-base-nox (4.05.0-11) ... Unpacking ocaml-nox (4.08.1-4) over (4.05.0-11) ... Replacing files in old package ocaml-base-nox (4.05.0-11) ... dpkg: error processing archive /tmp/apt-dpkg-install-6vAkr1/02-ocaml-nox_4.08.1-4_amd64.deb (--unpack): trying to overwrite '/usr/lib/ocaml/topdirs.cmi', which is also in package ocaml-compiler-libs 4.05.0-11 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) dpkg: considering deconfiguration of ocaml-nox, which would be broken by installation of ocaml-base-nox ... dpkg: yes, will deconfigure ocaml-nox (broken by ocaml-base-nox) Preparing to unpack .../03-ocaml-base-nox_4.08.1-4_amd64.deb ... De-configuring ocaml-nox (4.05.0-11) ... Unpacking ocaml-base-nox (4.08.1-4) over (4.05.0-11) ... Replacing files in old package ocaml-nox (4.05.0-11) ... Preparing to unpack .../04-libguestfs-ocaml_1%3a1.40.2-2+b12_amd64.deb ... Unpacking libguestfs-ocaml (1:1.40.2-2+b12) over (1:1.40.2-2) ... Preparing to unpack .../05-ocaml-interp_4.08.1-4_amd64.deb ... Unpacking ocaml-interp (4.08.1-4) over (4.05.0-11) ... Preparing to unpack .../06-ocaml-compiler-libs_4.08.1-4_amd64.deb ... Unpacking ocaml-compiler-libs (4.08.1-4) over (4.05.0-11) ... [...] Errors were encountered while processing: /tmp/apt-dpkg-install-6vAkr1/02-ocaml-nox_4.08.1-4_amd64.deb This seems to happen only on a single upgrade path, otherwise I might have caught it earlier. cheers, Andreas libguestfs-ocaml-dev_1:1.40.2-2+b12.log.gz Description: application/gzip
Bug#945496: gitmagic: diff for NMU version 20160304-1.2
Package: gitmagic
Version: 20160304-1.1
Severity: normal
Tags: patch pending
Dear maintainer,
I've prepared an NMU for gitmagic (versioned as 20160304-1.2) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should drop it or delay it longer.
This NMU is trying provide a debian/watch file to show the current
upstream version. I also sent a MR to Salsa repository[1] about
this change. If this NMU is accepted, I will merge.
[1] https://salsa.debian.org/debian/gitmagic/merge_requests/1
Thanks a lot in advance.
Regards,
Eriberto
diff -Nru gitmagic-20160304/debian/changelog gitmagic-20160304/debian/changelog
--- gitmagic-20160304/debian/changelog 2019-10-08 23:17:08.0 -0300
+++ gitmagic-20160304/debian/changelog 2019-11-25 18:54:58.0 -0300
@@ -1,3 +1,10 @@
+gitmagic (20160304-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/watch: changed to follow the last commit date.
+
+ -- Joao Eriberto Mota Filho Mon, 25 Nov 2019 18:54:58
-0300
+
gitmagic (20160304-1.1) unstable; urgency=medium
[ Joao Eriberto Mota Filho ]
diff -Nru gitmagic-20160304/debian/watch gitmagic-20160304/debian/watch
--- gitmagic-20160304/debian/watch 2019-10-08 23:16:39.0 -0300
+++ gitmagic-20160304/debian/watch 2019-11-25 18:54:58.0 -0300
@@ -7,3 +7,11 @@
# directory of the packaging clone.
#
# -- Francois Marier Mon, 07 Sep 2009 13:09:33 +1200
+
+# by Eriberto, 2019-11-25
+# This implementation will look at last commit date. Note that these lines
+# won't allow uscan to download anything but it will show the last version
+# in upstream git repository.
+version=4
+opts="searchmode=plain, uversionmangle=s/-//g" \
+https://github.com/blynn/gitmagic/commits/master
relative-time.datetime=.(\d{4}-\d{2}-\d{2})T
Bug#945494: ITP: ruby-unicode-utils -- Unicode algorithms for Ruby 1.9 or later
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-unicode-utils Version : 1.4.0 Upstream Author : Stefan Lang * URL : https://github.com/lang/unicode_utils * License : BSD-2-Clause Programming Lang : Ruby Description: Unicode algorithms for Ruby 1.9 or later UnicodeUtils implements Unicode algorithms for case conversion, normalization, text segmentation and more in pure Ruby code. . UnicodeUtils works with Ruby 1.9.1 or later. Best, Utkarsh
Bug#945493: mcomix: Library shows not all Thumbnails
Package: mcomix Version: 1.2.1mcomix3+git20190616-2 Severity: important Tags: a11y Dear Maintainer, I have more than 1000 books in my library. After the last update of mcomix:amd64 from 1.2.1-1.1 to 1.2.1mcomix3+git20190616-2 not all covers are displayed in the library anymore. Instead, most of them display a free white box that can be selected. The thumbnails are generated successfully. I can find it in the directory "~/.local/share/mcomix/library_covers/". The start with the option "-W all" shows no errors. I have already uninstalled the complete package once, deleted all remaining configurations and reinstalled. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages mcomix depends on: ii gir1.2-gtk-3.03.24.12-1 ii python3 3.7.5-1 ii python3-cairo 1.16.2-2 ii python3-gi3.34.0-3 ii python3-gi-cairo 3.34.0-3 ii python3-pil 6.2.0-1 Versions of packages mcomix recommends: ii python3-chardet 3.0.4-4 Versions of packages mcomix suggests: ii mupdf-tools 1.15.0+ds1-1+b1 ii p7zip16.02+dfsg-7 ii unrar1:5.6.6-2 -- no debconf information
Bug#945492: ifup/ifdown --all causes hooks to be called not per interface, but once with IFACE==--all
Package: ifupdown Version: 0.8.35+b1 Severity: important root@lotus:/etc/network/if-pre-up.d# cat <<_eof > 000debug #!/bin/sh echo IFACE==$IFACE exit 1 _eof root@lotus:/etc/network/if-pre-up.d# chmod +x 000debug root@lotus:/etc/network/if-pre-up.d# ifup -a IFACE==--all run-parts: /etc/network/if-pre-up.d/000debug exited with return code 1 ifup: pre-up script failed Arguably, the hooks should be called once for each interface that is brought up/down, with $IFACE set accordingly, not just once for all of them. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 5.3.0-1 ii libc6 2.29-3 ii lsb-base 11.1.0 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.1-2 Versions of packages ifupdown suggests: pn ppp pn rdnssd -- no debconf information -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#852025: xdg-utils: chromium should not be automatically set as XDG default-web-browser default-web-browser
Package: xdg-utils Version: 1.1.3-1 Followup-For: Bug #852025 xdg-utils on Debian really ought to default to x-www-browser. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled xdg-utils depends on no packages. Versions of packages xdg-utils recommends: pn libfile-mimeinfo-perl pn libnet-dbus-perl pn libx11-protocol-perl ii x11-utils 7.7+4 ii x11-xserver-utils 7.7+8 xdg-utils suggests no packages. -- no debconf information -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#935108: fabric: please consider uploading the latest version
On 11/23/19 6:04 PM, Luca Boccassi wrote: > On Tue, 2019-11-19 at 10:28 +, Luca Boccassi wrote: >> On Wed, 11 Sep 2019 12:36:13 +0100 Luca Boccassi < >> bl...@debian.org >> >>> wrote: >>> Control: tags -1 patch >>> >>> On Tue, 10 Sep 2019 20:10:34 +0100 Luca Boccassi < >>> >> >> bl...@debian.org >> >> wrote: Control: blocks 930451 by 935108 On Mon, 19 Aug 2019 16:47:39 +0100 Luca Boccassi < >> >> bl...@debian.org >> >> > wrote: > On Wed, 12 Jun 2019 22:44:28 +0100 Luca Boccassi < > >> >> bl...@debian.org >> >> >> wrote: >> Source: fabric >> Version: 1.14.0-1 >> Severity: wishlist >> Blocks: 930413 >> >> Dear Maintainer, >> >> Please consider uploading the latest version of fabric, >> 2.4.0: >> >> >> >> https://github.com/fabric/fabric/releases/tag/2.4.0 >> >> >> Among other things, it's a requirement for azure-cli which >> I'd >>> >>> like > to >> upload in the next few weeks. >> >> I'd be happy to help and do the work myself if you are short >> on time. >> Thank you for your work on this package! > > Dear Maintainer, > > Since I am currently blocked by this, unless there are > objections I'll > start working on an NMU shortly. I'll post the debdiff here >> >> before any > upload, and use a long DELAYED queue if the nmu is to go ahead. > > Thank you! The new version of fabric requires a new version of python3- invoke. >> >> Dear Maintainers, >> >> Unless there are any objections, I intend to upload an NMU to >> DELAYED/7 >> later today with the changes from the aforementioned MR to fix this >> bug >> and unblock my work on reverse dependencies: >> >> https://salsa.debian.org/openstack-team/python/python-invoke/merge_requests/3 >> >> >> Thanks! > > Dear python-invoke Maintainers, > > I've uploaded 1.3.0+ds-0.1 to DELAYED/7 and with urgency=low for > delayed migration on top of that. The exact same sources are on the MR > mentioned above. Debdiff is attached. > > Please let me know if there are any issues. > > Thank you! Hi Luca, This NMU is the proof that this package should be offered for adoption. Would you like to take it over, for example in the DPMT? I'd happily stay as uploader. Same for python-invoke. Cheers, Thomas Goirand (zigo)
Bug#945491: quiterss: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
Package: quiterss Version: 0.19.1+dfsg-1 Severity: important Tags: a11y Dear Maintainer, Recently this SSL error occurs again and again while loading the pages in the internal browser. "Beim Lesen ist ein Fehler aufgetreten: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init Failed to load URL https://www.spiegel.de/kultur/musik/hip-hop-magazin- gedruckte-juice-wird-eingestellt-a-1298212.html#ref=rss. QtNetwork Error 99" Overly common on the following feeds. - https://www.heise.de/newsticker/heise-atom.xml - http://www.spiegel.de/schlagzeilen/rss/index.xml From current BUG messages I could read that the package libqt5network5 may be responsible. On my system but a newer version is already installed, as reported there as a solution. My remaining Internet searches brought no further solutions why I write this BUG message. --- Seit kurzem tritt immer wieder dieser SSL Fehler beim laden der Seiten im internen Browser auf. "Beim Lesen ist ein Fehler aufgetreten: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init Failed to load URL https://www.spiegel.de/kultur/musik/hip-hop-magazin- gedruckte-juice-wird-eingestellt-a-1298212.html#ref=rss. QtNetwork Error 99" Bei folgenden Feeds übermäßig häufig. - https://www.heise.de/newsticker/heise-atom.xml - http://www.spiegel.de/schlagzeilen/rss/index.xml Aus aktuellen BUG Meldungen konnte ich lesen, dass das Paket libqt5network5 eventuell schuld daran ist. Auf meinem System ist aber bereits eine neuere Version installiert, als dort als Lösung gemeldet. Meine restlichen Internetrecherchen brachten keine weiteren Lösungsmöglichkeiten weswegen ich diese BUG Meldung verfasse. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages quiterss depends on: ii libc62.29-3 ii libgcc1 1:9.2.1-19 ii libqt5core5a 5.12.5+dfsg-2 ii libqt5gui5 5.12.5+dfsg-2 ii libqt5multimedia55.12.5-1 ii libqt5network5 5.12.5+dfsg-2 ii libqt5printsupport5 5.12.5+dfsg-2 ii libqt5sql5 5.12.5+dfsg-2 ii libqt5sql5-sqlite5.12.5+dfsg-2 ii libqt5webkit55.212.0~alpha3-5 ii libqt5widgets5 5.12.5+dfsg-2 ii libqt5xml5 5.12.5+dfsg-2 ii libsqlite3-0 3.30.1-1 ii libstdc++6 9.2.1-19 quiterss recommends no packages. quiterss suggests no packages. -- no debconf information
Bug#945490: gs always fails with "Permission denied"
Package: pstoedit Version: 3.74-1+b1 Severity: important Tried pstoedit for the first time today, but I couldn't get it to work. After a few tests, I noticed it would fail to run even when converting a dummy pdf (saved with inkscape) to a ps. The following command: $ pstoedit lay1.pdf lay1.ps Results in === pstoedit: version 3.74 / DLL interface 108 (built: Aug 24 2019 - release build - g++ 9.2.1 20190821 - 64-bit) : Copyright (C) 1993 - 2019 Wolfgang Glunz No explicit output format specified - using plot-ps as derived from suffix of output file *** WARNING - you have selected SAFER, indicating you want Ghostscript to execute in a safer environment, but at the same time have selected DELAYBIND. Unless you use this option with care (and specifically, remember to call .bindnow) it is possible that malicious code may be able to evade the limited security offered by the SAFER option. *** WARNING - you have selected SAFER, indicating you want Ghostscript to execute in a safer environment, but at the same time have selected WRITESYSTEMDICT. Unless you use this option with care and specifically, remember to execute code like: "systemdict readonly pop" it is possible that malicious code may be able to evade the limited security offered by the SAFER option. Error: /invalidfileaccess in --run-- Operand stack: (lay1.pdf) (r) Execution stack: %interp_exit .runexec2 --nostringval-- run --nostringval-- 2 %stopped_push --nostringval-- run run false 1 %stopped_push 1989 1 3 %oparray_pop 1988 1 3 %oparray_pop 1976 1 3 %oparray_pop 1833 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- run --nostringval-- 2 %stopped_push --nostringval-- 1989 1 3 %oparray_pop run Dictionary stack: --dict:730/1684(ro)(G)-- --dict:0/20(G)-- --dict:303/450(L)-- Current allocation mode is local Last OS error: Permission denied Current file position is 89272 GPL Ghostscript 9.50: Unrecoverable error, exit code 1 PostScript/PDF Interpreter finished. Return status 256 executed command : gs -q -dDELAYBIND -dWRITESYSTEMDICT -dNODISPLAY -dNOEPS "/tmp/psinD1zLI9" The interpreter seems to have failed, cannot proceed ! === "lay1.ps" is created as zero file. It seems that gs doesn't have enough permissions to read the input (?). I cannot it to run even using stdin/out only. But if I explicitly disable gs "SAFER" with $ pstoedit -psarg '-dNOSAFER' in out then I can convert documents as expected. I'm filing this as important, since I don't think explicitly disabling the gs sandbox is the right fix. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-rt-amd64 (SMP w/8 CPU cores; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pstoedit depends on: ii ghostscript 9.50~dfsg-2 ii libc62.29-3 ii libpstoedit0c2a 3.74-1+b1 ii libstdc++6 9.2.1-19 pstoedit recommends no packages. Versions of packages pstoedit suggests: pn xfig | ivtools-bin | tgif | transfig
Bug#945451: email-print-mime-structure: add test suite
Hello, On Mon 25 Nov 2019 at 04:02PM -05, Daniel Kahn Gillmor wrote: > On Mon 2019-11-25 07:59:45 -0700, Sean Whitton wrote: >> I'm a bit apprehensive about firing up a copy of gpg-agent. The dgit >> test suite has had a lot of issues over the past few years with properly >> setting up and tearing down an agent for testing. It seems to work for >> now, though. > > If mailscripts runs into problems with gpg-agent, i want to know. > > I saw all the trouble dgit had, but never managed to replicate it > myself, and dgit itself was too convoluted for me to follow what was > going on with the test suite :/ the reproducers that Ian managed to come > up with were something like 1 independent processes talking to a > single gpg-agent at once, iirc. I don't think that mailscripts will run > into that particular setup (not that it should fail there either, sigh) > > If we can replicate a failure with gpg-agent on the mailscripts test > suite, that should be simple enough that it will be easier to convince > upstream to deal with. Okay, cool. I believe that we are unlikely to see the problem until and unless the mailscripts test suite sets up the temporary GNUPGHOME more than once. > btw, i've been filing other bug reports with some of these dependent > projects about spurious error messages, warnings, failures in obscure > modes, or other noise as i work through building out this test suite. > So having this stuff recorded and automated in the mailscripts test > suite is turning out to be a good thing for the ecosystem generally, > because those bug reports now have a chance of being fixed. Nice :) -- Sean Whitton signature.asc Description: PGP signature
Bug#945195: [PATCH v2 6/7] email-print-mime-structure: Change pipe_decrypt to pipe_transform
I plan to use the same harness to try to transform other leaf subparts that might be extractable into a MIME subtree, not just decryption. So give it a more generic name. Signed-off-by: Daniel Kahn Gillmor --- email-print-mime-structure | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/email-print-mime-structure b/email-print-mime-structure index 4de0789..6d7b0af 100755 --- a/email-print-mime-structure +++ b/email-print-mime-structure @@ -114,16 +114,16 @@ class MimePrinter(object): if self.args.pgpkey: cryptopayload = self.pgpy_decrypt(self.args.pgpkey, ciphertext) if cryptopayload is None and self.args.use_gpg_agent: -cryptopayload = self.pipe_decrypt(ciphertext, ['gpg', '--batch', '--decrypt']) +cryptopayload = self.pipe_transform(ciphertext, ['gpg', '--batch', '--decrypt']) elif flavor == EncType.SMIME: if self.args.cmskey: for keyname in self.args.cmskey: cmd = ['openssl', 'smime', '-decrypt', '-inform', 'DER', '-inkey', keyname] -cryptopayload = self.pipe_decrypt(ciphertext, cmd) +cryptopayload = self.pipe_transform(ciphertext, cmd) if cryptopayload: return cryptopayload if self.args.use_gpg_agent: -cryptopayload = self.pipe_decrypt(ciphertext, ['gpgsm', '--batch', '--decrypt']) +cryptopayload = self.pipe_transform(ciphertext, ['gpgsm', '--batch', '--decrypt']) if cryptopayload is None: logging.warning(f'Unable to decrypt') return cryptopayload @@ -145,7 +145,7 @@ class MimePrinter(object): pass return None -def pipe_decrypt(self, ciphertext:bytes, cmd:List[str]) -> Optional[Message]: +def pipe_transform(self, ciphertext:bytes, cmd:List[str]) -> Optional[Message]: inp:int outp:int inp, outp = os.pipe() -- 2.24.0
Bug#945451: email-print-mime-structure: add test suite
On Mon 2019-11-25 07:59:45 -0700, Sean Whitton wrote: > I'm a bit apprehensive about firing up a copy of gpg-agent. The dgit > test suite has had a lot of issues over the past few years with properly > setting up and tearing down an agent for testing. It seems to work for > now, though. If mailscripts runs into problems with gpg-agent, i want to know. I saw all the trouble dgit had, but never managed to replicate it myself, and dgit itself was too convoluted for me to follow what was going on with the test suite :/ the reproducers that Ian managed to come up with were something like 1 independent processes talking to a single gpg-agent at once, iirc. I don't think that mailscripts will run into that particular setup (not that it should fail there either, sigh) If we can replicate a failure with gpg-agent on the mailscripts test suite, that should be simple enough that it will be easier to convince upstream to deal with. btw, i've been filing other bug reports with some of these dependent projects about spurious error messages, warnings, failures in obscure modes, or other noise as i work through building out this test suite. So having this stuff recorded and automated in the mailscripts test suite is turning out to be a good thing for the ecosystem generally, because those bug reports now have a chance of being fixed. Thanks for the merge! --dkg signature.asc Description: PGP signature
Bug#945195: [PATCH v2 1/7] email-print-mime-structure: decrypt PGP/MIME parts as bytes
Fully decode the encrypted part before passing it to any decryption
mechanism.
Signed-off-by: Daniel Kahn Gillmor
---
email-print-mime-structure | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/email-print-mime-structure b/email-print-mime-structure
index 27fb532..cdbe2ee 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -87,8 +87,8 @@ class MimePrinter(object):
(parent.get_content_type().lower() == 'multipart/encrypted') and \
(str(parent.get_param('protocol')).lower() ==
'application/pgp-encrypted') and \
(num == 2):
-ciphertext = z.get_payload()
-if not isinstance(ciphertext, str):
+ciphertext = z.get_payload(decode=True)
+if not isinstance(ciphertext, bytes):
logging.warning('encrypted part was not a leaf mime part
somehow')
return
if self.args.pgpkey:
@@ -104,7 +104,7 @@ class MimePrinter(object):
print(f'{newprefix}↧ (decrypts to)')
self.print_tree(cryptopayload, newprefix + '└', z, 0)
-def pgpy_decrypt(self, keys:List[str], ciphertext:str) ->
Optional[Message]:
+def pgpy_decrypt(self, keys:List[str], ciphertext:bytes) ->
Optional[Message]:
if pgpy is None:
logging.warning(f'Python module pgpy is not available, not
decrypting (try "apt install python3-pgpy")')
return None
@@ -121,11 +121,11 @@ class MimePrinter(object):
pass
return None
-def gpg_decrypt(self, ciphertext:str) -> Optional[Message]:
+def gpg_decrypt(self, ciphertext:bytes) -> Optional[Message]:
inp:int
outp:int
inp, outp = os.pipe()
-with open(outp, 'w') as outf:
+with open(outp, 'wb') as outf:
outf.write(ciphertext)
out:subprocess.CompletedProcess[bytes] = subprocess.run(['gpg',
'--batch', '--decrypt'],
stdin=inp,
--
2.24.0
Bug#945195: [PATCH v2 4/7] email-print-mime-structure: decrypt S/MIME parts using gpgsm
Decrypt ciphertext using gpgsm if the user has indicated that it's ok.
This includes a new element in the test suite, which uses secret key
material from https://www.ietf.org/id/draft-dkg-lamps-samples-01.html
Signed-off-by: Daniel Kahn Gillmor
---
debian/control| 2 +
email-print-mime-structure| 11 +++
email-print-mime-structure.1.pod | 8 +-
tests/email-print-mime-structure.sh | 9 ++-
tests/email-print-mime-structure/bob.p12 | 75 +++
.../smime-encrypted.eml | 24 ++
.../smime-encrypted.out | 7 ++
.../smime-encrypted.p12 | 1 +
8 files changed, 132 insertions(+), 5 deletions(-)
create mode 100644 tests/email-print-mime-structure/bob.p12
create mode 100644 tests/email-print-mime-structure/smime-encrypted.eml
create mode 100644 tests/email-print-mime-structure/smime-encrypted.out
create mode 12 tests/email-print-mime-structure/smime-encrypted.p12
diff --git a/debian/control b/debian/control
index 2e96d3e..f04ce79 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends:
diffutils ,
gpg ,
gpg-agent ,
+ gpgsm ,
mypy ,
perl,
python3 ,
@@ -52,6 +53,7 @@ Recommends:
Suggests:
gpg,
gpg-agent,
+ gpgsm,
Architecture: all
Description: collection of scripts for manipulating e-mail on Debian
This package provides a collection of scripts for manipulating e-mail
diff --git a/email-print-mime-structure b/email-print-mime-structure
index d152b34..e82d56e 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -83,6 +83,7 @@ class MimePrinter(object):
print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname}
{nbytes:d} bytes')
cryptopayload:Optional[Message] = None
try_pgp_decrypt:bool = self.args.pgpkey or self.args.use_gpg_agent
+try_cms_decrypt:bool = self.args.use_gpg_agent
if try_pgp_decrypt and \
(parent is not None) and \
@@ -91,6 +92,13 @@ class MimePrinter(object):
(num == 2):
cryptopayload = self.decrypt_part(z, EncType.PGPMIME)
+if try_cms_decrypt and \
+ cryptopayload is None and \
+ z.get_content_type().lower() == 'application/pkcs7-mime' and \
+ str(z.get_param('smime-type')).lower() in ['authenveloped-data',
+ 'enveloped-data']:
+cryptopayload = self.decrypt_part(z, EncType.SMIME)
+
if cryptopayload is not None:
newprefix = prefix[:-3] + ' '
print(f'{newprefix}↧ (decrypts to)')
@@ -107,6 +115,9 @@ class MimePrinter(object):
cryptopayload = self.pgpy_decrypt(self.args.pgpkey, ciphertext)
if cryptopayload is None and self.args.use_gpg_agent:
cryptopayload = self.pipe_decrypt(ciphertext, ['gpg',
'--batch', '--decrypt'])
+elif flavor == EncType.SMIME:
+if self.args.use_gpg_agent:
+cryptopayload = self.pipe_decrypt(ciphertext, ['gpgsm',
'--batch', '--decrypt'])
if cryptopayload is None:
logging.warning(f'Unable to decrypt')
return cryptopayload
diff --git a/email-print-mime-structure.1.pod b/email-print-mime-structure.1.pod
index d8545ad..f109997 100644
--- a/email-print-mime-structure.1.pod
+++ b/email-print-mime-structure.1.pod
@@ -35,8 +35,8 @@ do not interact with any local GnuPG keyring.
=item B<--use-gpg-agent>
If this flag is present, and B encounters
-a PGP/MIME-encrypted part, it will try to decrypt the part using the
-secret keys found in the local installation of GnuPG.
+a PGP/MIME- or S/MIME-encrypted part, it will try to decrypt the part
+using the secret keys found in the local installation of GnuPG.
If both B<--pgpkey=>I and B<--use-gpg-agent> are
supplied, I arguments will be tried before falling back to
@@ -49,8 +49,8 @@ stderr.
=item B<--no-use-gpg-agent>
-Don't try to decrypt PGP/MIME-encrypted parts using secret keys found
-in the local installation of GnuPG. This is the default.
+Don't try to decrypt PGP/MIME- or S/MIME-encrypted parts using secret
+keys found in the local installation of GnuPG. This is the default.
=item B<--help>, B<-h>
diff --git a/tests/email-print-mime-structure.sh
b/tests/email-print-mime-structure.sh
index 0b70d73..5cd34b2 100755
--- a/tests/email-print-mime-structure.sh
+++ b/tests/email-print-mime-structure.sh
@@ -11,15 +11,22 @@ test_eml() {
for eml in tests/email-print-mime-structure/*.eml; do
base="${eml%%.eml}"
pgpkey="$base.pgpkey"
+p12key="$base.p12"
if [ -e "$pgpkey" ]; then
printf "Testing %s (PGPy)\n" "${eml##*/}"
test_eml "$base" --pgpkey "$pgpkey"
testgpghome=$(mktemp -d)
-printf "Testing %s (GnuPG)\n" "${eml##*/}"
+printf "Testing %s (GnuPG PGP/MIME)\n" "${eml##*/}"
gpg
Bug#945195: [PATCH v2 7/7] email-print-mime-structure: handle one-part PKCS#7 signature objects
PKCS#7 offers a signed-only mode which is distinct from
multipart/signed. This mode is more robust to breakage by
transforming MTAs, but it is also unreadable *unless* the receiver
knows how to cope with S/MIME.
See https://tools.ietf.org/html/rfc8551#section-3.5 for more details
about the different formats.
email-print-mime-structure should now be able to handle these messages
and display the structure of their content as well.
Signed-off-by: Daniel Kahn Gillmor
---
debian/control| 2 +
email-print-mime-structure| 13 ++
.../smime-signed.eml | 41 +++
.../smime-signed.out | 7
4 files changed, 63 insertions(+)
create mode 100644 tests/email-print-mime-structure/smime-signed.eml
create mode 100644 tests/email-print-mime-structure/smime-signed.out
diff --git a/debian/control b/debian/control
index d2e07da..73c5919 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Build-Depends:
debhelper (>= 10),
dh-elpa,
diffutils ,
+ gnutls-bin ,
gpg ,
gpg-agent ,
gpgsm ,
@@ -52,6 +53,7 @@ Recommends:
python3-argcomplete,
python3-pgpy,
Suggests:
+ gnutls-bin,
gpg,
gpg-agent,
gpgsm,
diff --git a/email-print-mime-structure b/email-print-mime-structure
index 6d7b0af..ba0d61f 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -103,6 +103,19 @@ class MimePrinter(object):
newprefix = prefix[:-3] + ' '
print(f'{newprefix}↧ (decrypts to)')
self.print_tree(cryptopayload, newprefix + '└', z, 0)
+else:
+if z.get_content_type().lower() == 'application/pkcs7-mime' and \
+ str(z.get_param('smime-type')).lower() == 'signed-data':
+bodypart:Union[List[Message],str,bytes,None] =
z.get_payload(decode=True)
+if isinstance(bodypart, bytes):
+unwrapped = self.pipe_transform(bodypart, ['certtool',
'--p7-show-data', '--p7-info', '--inder'])
+if unwrapped:
+newprefix = prefix[:-3] + ' '
+print(f'{newprefix}⇩ (unwraps to)')
+self.print_tree(unwrapped, newprefix + '└', z, 0)
+else:
+logging.warning(f'Unable to unwrap one-part PKCS#7
signed message (maybe try "apt install gnutls-bin")')
+
def decrypt_part(self, msg:Message, flavor:EncType) -> Optional[Message]:
ciphertext:Union[List[Message],str,bytes,None] =
msg.get_payload(decode=True)
diff --git a/tests/email-print-mime-structure/smime-signed.eml
b/tests/email-print-mime-structure/smime-signed.eml
new file mode 100644
index 000..3929d6b
--- /dev/null
+++ b/tests/email-print-mime-structure/smime-signed.eml
@@ -0,0 +1,41 @@
+Date: Sun, 24 Nov 2019 21:13:45 -0500
+Subject: test message
+Message-ID:
+From: Alice
+To: Bob
+Content-Type: application/pkcs7-mime; smime-type="signed-data"
+Content-Transfer-Encoding: base64
+
+MIIHOgYJKoZIhvcNAQcCoIIHKzCCBycCAQExDTALBglghkgBZQMEAgEwggG+BgkqhkiG9w0BBwGg
+ggGvBIIBq0NvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOyBib3VuZGFyeT0ieHl6Ig0KDQot
+LXh5eg0KQ29udGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7IGJvdW5kYXJ5PSJhYmMx
+MjMiDQoNCi0tYWJjMTIzDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4NCg0KVGhpcyBpcyBhIHNp
+bXBsZSBtZXNzYWdlDQoNCi0tYWJjMTIzDQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQo8aHRt
+bD48aGVhZD48L2hlYWQ+PGJvZHk+PHA+VGhpcyBpcyBhIHNpbXBsZSBtZXNzYWdlPC9wPjwvYm9k
+eT48L2h0bWw+DQoNCi0tYWJjMTIzLS0NCi0teHl6DQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4N
+CkNvbnRlbnQtRGlzcG9zaXRpb246IGF0dGFjaG1lbnQ7IGZpbGVuYW1lPSJ0ZXN0LnR4dCINCg0K
+VGhpcyBpcyBhIHNpbXBsZSBhdHRhY2htZW50IGZpbGUuDQqgggNyMIIDbjCCAlagAwIBAgIUZ4K0
+WXNSS8H0cUcZavD9EYqqTAswDQYJKoZIhvcNAQENBQAwLTErMCkGA1UEAxMiU2FtcGxlIExBTVBT
+IENlcnRpZmljYXRlIEF1dGhvcml0eTAgFw0xOTExMjAwNjU0MThaGA8yMDUyMDkyNzA2NTQxOFow
+GTEXMBUGA1UEAxMOQWxpY2UgTG92ZWxhY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
+AQDD7q35ZdG2JAzzJGNZDZ9sV7AKh0hlRfoFjTZN5m4RegQAYSyag43ouWi1xRN0avf0UTYrwjK0
+4qRdV7GzCACoEKq/xiNUOsjfJXzbCublN3fZMOXDshKKBqThlK75SjA9Czxg7ejGoiY/iidk0e91
+neK30SCCaBTJlfR2ZDrPk73IPMeksxoTatfF9hw9dDA+/Hi1yptN/aG0Q/s9icFrxr6y2zQXsjuQ
+PmjMZgj10aD9cazWVgRYCgflhmA0V1uQl1wobYU8DAVxVn+GgabqyjGQMoythIK0Gn5+ofwxXXUM
+/zbU+g6+1ISdoXxRRFtq2GzbIqkAHZZQm+BbnFrhAgMBAAGjgZcwgZQwDAYDVR0TAQH/BAIwADAe
+BgNVHREEFzAVgRNhbGljZUBzbWltZS5leGFtcGxlMBMGA1UdJQQMMAoGCCsGAQUFBwMEMA8GA1Ud
+DwEB/wQFAwMHoAAwHQYDVR0OBBYEFKwuVFqk/VUYry7oZkQ40SXR1wB5MB8GA1UdIwQYMBaAFLdS
+TXPAiD2yw3paDPOU9/eAonfbMA0GCSqGSIb3DQEBDQUAA4IBAQB76o4Yz7yrVSFcpXqLrcGtdI4q
+93aKCXECCCzNQLp4yesh6brqaZHNJtwYcJ5TqbUym9hJ70iJE4jGNN+yAZR1ltte0HFKYIBKM4EJ
+umG++2hqbUaLz4tl06BHaQPCv/9NiNY7q9R9c/B6s1YzHhwqkWht2a+AtgJ4BkpG+g+MmZMQV/Ao
+7RwLFKJ9OlMWLBmEXFcpIJN0HpPasT0nEl/MmotSu+8RnClAi3yFfyTKb+8rD7VxuyXetqDZ6dU/
+9/iqD/SZS7OQIjywtd343mACz3B1RlFxMHSA6dQAf2btGumqR0KiAp3KkYRAePoaJqYkB7Zad06n
Bug#945195: [PATCH v2 5/7] email-print-mime-structure: decrypt S/MIME parts with OpenSSL
If the user supplies a secret key like the ones found in
https://www.ietf.org/id/draft-dkg-lamps-samples-01.html, then
email-print-mime-structure will try to use that for decryption of
CMS-encrypted (S/MIME) message parts.
Signed-off-by: Daniel Kahn Gillmor
---
debian/control | 2 ++
email-print-mime-structure | 12 ++--
email-print-mime-structure.1.pod| 17 ++---
tests/email-print-mime-structure.sh | 6 ++
4 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/debian/control b/debian/control
index f04ce79..d2e07da 100644
--- a/debian/control
+++ b/debian/control
@@ -12,6 +12,7 @@ Build-Depends:
gpg-agent ,
gpgsm ,
mypy ,
+ openssl ,
perl,
python3 ,
python3-argcomplete,
@@ -54,6 +55,7 @@ Suggests:
gpg,
gpg-agent,
gpgsm,
+ openssl,
Architecture: all
Description: collection of scripts for manipulating e-mail on Debian
This package provides a collection of scripts for manipulating e-mail
diff --git a/email-print-mime-structure b/email-print-mime-structure
index e82d56e..4de0789 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -83,7 +83,7 @@ class MimePrinter(object):
print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname}
{nbytes:d} bytes')
cryptopayload:Optional[Message] = None
try_pgp_decrypt:bool = self.args.pgpkey or self.args.use_gpg_agent
-try_cms_decrypt:bool = self.args.use_gpg_agent
+try_cms_decrypt:bool = self.args.cmskey or self.args.use_gpg_agent
if try_pgp_decrypt and \
(parent is not None) and \
@@ -116,6 +116,12 @@ class MimePrinter(object):
if cryptopayload is None and self.args.use_gpg_agent:
cryptopayload = self.pipe_decrypt(ciphertext, ['gpg',
'--batch', '--decrypt'])
elif flavor == EncType.SMIME:
+if self.args.cmskey:
+for keyname in self.args.cmskey:
+cmd = ['openssl', 'smime', '-decrypt', '-inform', 'DER',
'-inkey', keyname]
+cryptopayload = self.pipe_decrypt(ciphertext, cmd)
+if cryptopayload:
+return cryptopayload
if self.args.use_gpg_agent:
cryptopayload = self.pipe_decrypt(ciphertext, ['gpgsm',
'--batch', '--decrypt'])
if cryptopayload is None:
@@ -175,7 +181,9 @@ def main() -> None:
parser:ArgumentParser = ArgumentParser(description='Read RFC2822 MIME
message from stdin and emit a tree diagram to stdout.',
epilog="Example:
email-print-mime-structure are used ephemerally, and
do not interact with any local GnuPG keyring.
+=item B<--cmskey=>I
+
+I should name a PEM- or DER-encoded X.509 private key that is
+not password-protected. If an S/MIME-encrypted message that uses CMS
+is found on standard input, this key will be tried for decryption.
+May be used multiple times if you want to try decrypting with more
+than one such key.
+
+X.509 private keys listed in B<--cmskey=> are used ephemerally, and do
+not interact with any local GnuPG keyring.
+
=item B<--use-gpg-agent>
If this flag is present, and B encounters
a PGP/MIME- or S/MIME-encrypted part, it will try to decrypt the part
using the secret keys found in the local installation of GnuPG.
-If both B<--pgpkey=>I and B<--use-gpg-agent> are
-supplied, I arguments will be tried before falling back to
-GnuPG.
+If B<--use-gpg-agent> is supplied along with either
+B<--pgpkey=>I or B<--cmskey=>I arguments, the
+I arguments will be tried before falling back to GnuPG.
If B has been asked to decrypt parts with
either B<--pgpkey=>I or with B<--use-gpg-agent>, and it
diff --git a/tests/email-print-mime-structure.sh
b/tests/email-print-mime-structure.sh
index 5cd34b2..8c646d0 100755
--- a/tests/email-print-mime-structure.sh
+++ b/tests/email-print-mime-structure.sh
@@ -22,6 +22,12 @@ for eml in tests/email-print-mime-structure/*.eml; do
GNUPGHOME="$testgpghome" test_eml "$base" --use-gpg-agent
rm -rf "$testgpghome"
elif [ -e "$p12key" ]; then
+printf "Testing %s (OpenSSL)\n" "${eml##*/}"
+grep -v ^- < "$p12key" | base64 -d | \
+openssl pkcs12 -nocerts -nodes -passin pass: -passout pass: -out
"$base.pemkey"
+test_eml "$base" --cmskey "$base.pemkey"
+rm -f "$base.pemkey"
+
testgpghome=$(mktemp -d)
printf "Testing %s (GnuPG S/MIME)\n" "${eml##*/}"
gpgsm --pinentry-mode=loopback --passphrase-fd 4 4<<<''
--homedir="$testgpghome" --batch --quiet --import <"$p12key"
--
2.24.0
Bug#945195: [PATCH v2 3/7] email-print-mime-structure: move decrypt_part to its own function
Signed-off-by: Daniel Kahn Gillmor
---
email-print-mime-structure | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/email-print-mime-structure b/email-print-mime-structure
index 6c68eb3..d152b34 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -32,6 +32,7 @@ something like "cat -n"
'''
import os
import sys
+import enum
import email
import logging
import subprocess
@@ -51,6 +52,8 @@ try:
except ImportError:
argcomplete = None
+EncType = enum.Enum('EncType', ['PGPMIME', 'SMIME'])
+
class MimePrinter(object):
def __init__(self, args:Namespace):
self.args = args
@@ -79,7 +82,6 @@ class MimePrinter(object):
print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname}
{nbytes:d} bytes')
cryptopayload:Optional[Message] = None
-ciphertext:Union[List[Message],str,bytes,None] = None
try_pgp_decrypt:bool = self.args.pgpkey or self.args.use_gpg_agent
if try_pgp_decrypt and \
@@ -87,23 +89,28 @@ class MimePrinter(object):
(parent.get_content_type().lower() == 'multipart/encrypted') and \
(str(parent.get_param('protocol')).lower() ==
'application/pgp-encrypted') and \
(num == 2):
-ciphertext = z.get_payload(decode=True)
-if not isinstance(ciphertext, bytes):
-logging.warning('encrypted part was not a leaf mime part
somehow')
-return
-if self.args.pgpkey:
-cryptopayload = self.pgpy_decrypt(self.args.pgpkey, ciphertext)
-if cryptopayload is None and self.args.use_gpg_agent:
-cryptopayload = self.pipe_decrypt(ciphertext, ['gpg',
'--batch', '--decrypt'])
-if cryptopayload is None:
-logging.warning(f'Unable to decrypt')
-return
+cryptopayload = self.decrypt_part(z, EncType.PGPMIME)
if cryptopayload is not None:
newprefix = prefix[:-3] + ' '
print(f'{newprefix}↧ (decrypts to)')
self.print_tree(cryptopayload, newprefix + '└', z, 0)
+def decrypt_part(self, msg:Message, flavor:EncType) -> Optional[Message]:
+ciphertext:Union[List[Message],str,bytes,None] =
msg.get_payload(decode=True)
+cryptopayload:Optional[Message] = None
+if not isinstance(ciphertext, bytes):
+logging.warning('encrypted part was not a leaf mime part somehow')
+return None
+if flavor == EncType.PGPMIME:
+if self.args.pgpkey:
+cryptopayload = self.pgpy_decrypt(self.args.pgpkey, ciphertext)
+if cryptopayload is None and self.args.use_gpg_agent:
+cryptopayload = self.pipe_decrypt(ciphertext, ['gpg',
'--batch', '--decrypt'])
+if cryptopayload is None:
+logging.warning(f'Unable to decrypt')
+return cryptopayload
+
def pgpy_decrypt(self, keys:List[str], ciphertext:bytes) ->
Optional[Message]:
if pgpy is None:
logging.warning(f'Python module pgpy is not available, not
decrypting (try "apt install python3-pgpy")')
--
2.24.0
Bug#945195: [PATCH v2 2/7] email-print-mime-structure: Generic pipe decryption
Signed-off-by: Daniel Kahn Gillmor --- email-print-mime-structure | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/email-print-mime-structure b/email-print-mime-structure index cdbe2ee..6c68eb3 100755 --- a/email-print-mime-structure +++ b/email-print-mime-structure @@ -94,7 +94,7 @@ class MimePrinter(object): if self.args.pgpkey: cryptopayload = self.pgpy_decrypt(self.args.pgpkey, ciphertext) if cryptopayload is None and self.args.use_gpg_agent: -cryptopayload = self.gpg_decrypt(ciphertext) +cryptopayload = self.pipe_decrypt(ciphertext, ['gpg', '--batch', '--decrypt']) if cryptopayload is None: logging.warning(f'Unable to decrypt') return @@ -121,13 +121,13 @@ class MimePrinter(object): pass return None -def gpg_decrypt(self, ciphertext:bytes) -> Optional[Message]: +def pipe_decrypt(self, ciphertext:bytes, cmd:List[str]) -> Optional[Message]: inp:int outp:int inp, outp = os.pipe() with open(outp, 'wb') as outf: outf.write(ciphertext) -out:subprocess.CompletedProcess[bytes] = subprocess.run(['gpg', '--batch', '--decrypt'], +out:subprocess.CompletedProcess[bytes] = subprocess.run(cmd, stdin=inp, capture_output=True) if out.returncode == 0: -- 2.24.0
Bug#932460: vlc: UPNP does not work in VLC
Hello, I'm coming back to you for Bug # 932460: vlc: UPNP does not work in VLC in relation to bug # 935709 pupnp. I still have the symptoms. Christian Marillat has for his deposit put in place a patch (rather a diff) that along with this report. An upstream version also fixes the bug, it is version 1.10 as we can see it with the changelog of Christian. Can you do something official? Thanks, best regards changelog: pupnp-1.8-dmo (1:1.10.1-dmo1) unstable; urgency=medium * New upstream bugfix release. -- Christian Marillat Thu, 21 Nov 2019 08:39:45 +0100 pupnp-1.8-dmo (1:1.10.0-dmo1) unstable; urgency=medium * New upstream release. -- Christian Marillat Sun, 03 Nov 2019 07:43:16 +0100 pupnp-1.8-dmo (1:1.8.4-dmo1) unstable; urgency=medium * Add upstream patch to fix upnp with VLC. -- Christian Marillat Wed, 28 Aug 2019 00:30:59 +0200 Le 27/08/2019 à 23:21, Sebastian Ramacher a écrit : Control: reassign -1 libupnp13 1:1.8.4-2 Control: forcemerge 935709 -1 Control: forwarded 935709 https://github.com/mrjimenez/pupnp/issues/91 Control: tags 935709 upstream fixed-upstream Hi On 2019-07-19 18:52:05, Sebastien CHAVAUX wrote: Package: vlc Version: 3.0.7-1 Severity: normal Dear Maintainer, Since upgrading to Debian 10, Windows does not see my Upnp network. I can no longer play videos and other multimedia files that are made available from my many Dlna servers. On my PC under Debian 10, I have a Minidlna server visible from all over the house on all my devices (TV, dlna player, PC with Debian 9 via Vlc, ...) and I also have a Dlna multimedia server, but I do not see anything on my Debian PC 10 with Vlc. When I run via a terminal it gives me this: $ vlc VLC media player 3.0.7 Vetinari (revision 3.0.7-0-g86cee31099) [55fc26d82570] main libvlc: Launching vlc with the default interface. Use "cvlc" to start VLC without an interface. [55fc26d864a0] main playlist: playlist is empty [7fbf7c4aaf20] upnp discovery services: Initializing libupnp on 'default' interface [7fbf7c4aaf20] upnp services discovery error: Initialization failed: UPNP_E_SOCKET_BIND [7fbf7c4aaf20] main service error discovery: no suitable services discovery module [7fbf7c4aaf20] upnp discovery services: Initializing libupnp on 'default' interface [7fbf7c4aaf20] upnp services discovery error: Initialization failed: UPNP_E_SOCKET_BIND [7fbf7c4aaf20] main service error discovery: no suitable services discovery module QObject :: ~ QObject: Timers can not be stopped from another thread This issue looks like it could be caused by #935709 in pupnp-1.8. Reassigning and merging. Cheers It looks like the bug I sent a few months ago at openSUSE for the same thing: https://bugzilla.opensuse.org/show_bug.cgi?id=1132829 If I use the Vlc flatpack it works and I can see the Dlna servers. If you need more information, I will do my best to give it. Sincerely, seb. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vlc depends on: ii vlc-bin 3.0.7-1 ii vlc-plugin-base 3.0.7-1 ii vlc-plugin-qt3.0.7-1 ii vlc-plugin-video-output 3.0.7-1 Versions of packages vlc recommends: ii vlc-l10n 3.0.7-1 ii vlc-plugin-notify 3.0.7-1 ii vlc-plugin-samba 3.0.7-1 ii vlc-plugin-skins2 3.0.7-1 ii vlc-plugin-video-splitter 3.0.7-1 ii vlc-plugin-visualization 3.0.7-1 vlc suggests no packages. Versions of packages libvlc-bin depends on: ii libc62.28-10 ii libvlc5 3.0.7-1 Versions of packages libvlc5 depends on: ii libc62.28-10 ii libvlccore9 3.0.7-1 Versions of packages libvlc5 recommends: ii libvlc-bin 3.0.7-1 Versions of packages vlc-bin depends on: ii libc6 2.28-10 ii libvlc-bin 3.0.7-1 ii libvlc5 3.0.7-1 Versions of packages vlc-plugin-base depends on: ii liba52-0.7.4 0.7.4-19 ii libaom0 1.0.0-3 ii libarchive13 3.3.3-4 ii libaribb24-0 1.0.3-2 ii libasound2 1.1.8-1 ii libass9 1:0.14.0-2 ii libavahi-client3 0.7-4+b1 ii libavahi-common3 0.7-4+b1 ii libavc1394-0 0.5.4-5 ii libavcodec58 7:4.1.3-1 ii libavformat587:4.1.3-1 ii libavutil56 7:4.1.3-1 ii libbasicusageenvironment12018.11.26-1.1 ii libbluray2 1:1.1.0-1 ii libc62.28-10 ii
Bug#945488: Fixed already
forcemerge 944892 945488 thanks
Bug#945402: [Pkg-phototools-devel] Bug#945402: feh: Please add dcraw to the Suggests (or even Recommends) of the package
On 2019-11-25 at 21:27:04 +0100, László Böszörményi (GCS) wrote: > On Mon, Nov 25, 2019 at 9:03 PM Elena ``of Valhalla'' > wrote: > > On 2019-11-25 at 17:28:32 +0100, László Böszörményi (GCS) wrote: > > done the upgrade, the same thing is happening. > While I can reproduce the problem, for me the displayed messages are these: yes, I didn't mention the warnings that were already present in buster, i.e.: > TIFFReadDirectory: Warning, Photometric tag is missing, assuming data is > YCbCr. > TIFFReadDirectory: Warning, SamplesPerPixel tag is missing, applying > correct SamplesPerPixel value of 3. > OJPEGSubsamplingCorrect: Warning, Subsampling tag is not set, yet > subsampling inside JPEG data [2,1] does not match default values > [2,2]; assuming subsampling inside JPEG data is correct. > OJPEGSetupDecode: Warning, Depreciated and troublesome old-style JPEG > compression mode, please convert to new-style JPEG compression and > notify vendor of writing software. then there is: > OJPEGWriteHeaderInfo: jpeg_start_decompress() returned image_width = > 4272 and image_height = 2848, expected 4272 and -1. which I can confirm is the same message I'm getting since updating (sorry, when I tested earlier I checked that the image wasn't being opened, and didn't notice that the message had changed). > > At first I thought it was a regression in libimlib2 (and was going to > > open a bug on that package), but after reading the manpage of feh I > > started to think that it was never supposed to work the way it did. > For me this seems to be tiff checks that became stricter to prevent > accidental crashes due to images not conforming the standards. > As such the warnings show the sign of badly written OJPEG format that > don't conform the standard. Indeed, that's why I started to think that maybe it was the files' fault and not the tool. -- Elena ``of Valhalla'' signature.asc Description: PGP signature
Bug#927026: Please enable CONFIG_MD_CLUSTER for linux packages in Buster
Control: tags -1 + pending Hi, On Sun, Oct 20, 2019 at 02:35:00PM +0200, Valentin Vidić wrote: > Hi, > > Please enable for kernels in unstable so we can test cluster functionality > for bullseye release. Enabled now in master branch[1]. Regards, Salvatore [1] https://salsa.debian.org/kernel-team/linux/commit/5eed86cb5b5d331499f9971724f7030c5a3f4d8a
Bug#881889: shadow: Please switch from gnome-doc-utils to pure gettext
Control: tags -1 + fixed-upstream On Sun, Nov 24, 2019 at 01:04:51PM +0100, Andreas Henriksson wrote: > Hi again, > > I figured just switching to itstool might be the most straight forward > solution and fortunately for someone as lazy as me I found that > apparently fedora has already done that via a patch! > > https://src.fedoraproject.org/rpms/shadow-utils/blob/master/f/shadow-4.6-use-itstool.patch And apparently this is already merged upstream! https://github.com/shadow-maint/shadow/pull/184 https://github.com/shadow-maint/shadow/commit/6c6c8d3a33bba32277e1ed46f55df1e6dbc914b7 > > I tried building the debian package with this patch included, > Unfortunately the result isn't perfect. [...] I've filed an upstream issue about the regressions including suggested (proof of concept) solutions at: https://github.com/shadow-maint/shadow/issues/193 Regards, Andreas Henriksson
Bug#945489: llvm-toolchain-9: autopkgtest needs update for new version of cmake: fails on warning
Source: llvm-toolchain-9 Version: 1:9.0.0-3 Severity: serious X-Debbugs-CC: debian...@lists.debian.org, cm...@packages.debian.org Tags: sid bullseye User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:cmake Dear maintainers, With a recent upload of cmake the autopkgtest of llvm-toolchain-9 fails in testing when that autopkgtest is run with the binary packages of cmake from unstable. It passes when run with only packages from testing. In tabular form: passfail cmake from testing3.15.4-1 llvm-toolchain-9 from testing1:9.0.0-3 all others from testingfrom testing I copied some of the output at the bottom of this report. If you don't want to fix the warning, you should add the allow-stderr restriction to not fail on this warning. Currently this regression is blocking the migration of cmake to testing [1]. Of course, cmake shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in cmake was intended and your package needs to update to the new situation. 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=cmake https://ci.debian.net/data/autopkgtest/testing/amd64/l/llvm-toolchain-9/3507607/log.gz autopkgtest [05:43:26]: test cmake-test: - - - - - - - - - - results - - - - - - - - - - cmake-test FAIL stderr: CMake Warning (dev) in CMakeLists.txt: autopkgtest [05:43:27]: test cmake-test: - - - - - - - - - - stderr - - - - - - - - - - CMake Warning (dev) in CMakeLists.txt: No project() command is present. The top-level CMakeLists.txt file must contain a literal, direct call to the project() command. Add a line of code such as project(ProjectName) near the top of the file, but after cmake_minimum_required(). CMake is pretending there is a "project(Project)" command on the first line. This warning is for project developers. Use -Wno-dev to suppress it. signature.asc Description: OpenPGP digital signature
Bug#945488: oce: autopkgtest needs update for new version of cmake: fails on warning to stderr
Source: oce Version: 0.18.2-3 Severity: serious X-Debbugs-CC: debian...@lists.debian.org, cm...@packages.debian.org Tags: sid bullseye User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:cmake Dear maintainers, With a recent upload of cmake the autopkgtest of oce fails in testing when that autopkgtest is run with the binary packages of cmake from unstable. It passes when run with only packages from testing. In tabular form: passfail cmake from testing3.15.4-1 ocefrom testing0.18.2-3 all others from testingfrom testing I copied some of the output at the bottom of this report. If you don't want to fix the warning, you should add the allow-stderr restriction to not fail on this warning. Currently this regression is blocking the migration of cmake to testing [1]. Of course, cmake shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in cmake was intended and your package needs to update to the new situation. 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=cmake https://ci.debian.net/data/autopkgtest/testing/amd64/o/oce/3508958/log.gz autopkgtest [11:12:29]: test build1: - - - - - - - - - - results - - - - - - - - - - build1 FAIL stderr: CMake Warning (dev) in CMakeLists.txt: autopkgtest [11:12:30]: test build1: - - - - - - - - - - stderr - - - - - - - - - - CMake Warning (dev) in CMakeLists.txt: No project() command is present. The top-level CMakeLists.txt file must contain a literal, direct call to the project() command. Add a line of code such as project(ProjectName) near the top of the file, but after cmake_minimum_required(). CMake is pretending there is a "project(Project)" command on the first line. This warning is for project developers. Use -Wno-dev to suppress it. signature.asc Description: OpenPGP digital signature
Bug#945487: dkimproxy: defaults to prohibited rsa-sha1 signatures
Package: dkimproxy Version: 1.4.1-3 Severity: important Dear Maintainer, I was instructed to install dkimproxy while evaluating OpenSMTPD. It pretends to work, but creates rsa-sha1 signatures by default, and it is impossible to override without editing the initscript. However, RFC8301 section 3.1 says: """ DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa-sha256. Signers MUST sign using rsa-sha256. Verifiers MUST be able to verify using rsa-sha256. rsa-sha1 MUST NOT be used for signing or verifying. DKIM signatures identified as having been signed with historic algorithms (currently, rsa-sha1) have permanently failed evaluation as discussed in Section 3.9 of [RFC6376]. """ In other words, the default signatures use a prohibited algorithm. I would also become happy if the OpenSMTPD manual page smtpd(8) starts recommending some other way to make DKIM signatures. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.12-arch1-1 (SMP w/8 CPU cores; PREEMPT) # LXC container Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE # wireguard Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dkimproxy depends on: ii adduser 3.118 ii liberror-perl 0.17027-2 ii libmail-dkim-perl 0.54-1 ii libnet-server-perl2.009-1 ii libtext-wrapper-perl 1.05-2 ii lsb-base 10.2019051400 ii openssl 1.1.1d-0+deb10u2 ii perl 5.28.1-6 ii ssl-cert 1.0.39 Versions of packages dkimproxy recommends: pn amavisd-new dkimproxy suggests no packages. -- Configuration Files: /etc/default/dkimproxy changed [not included] /etc/dkimproxy/dkimproxy_out.conf changed [not included] /etc/init.d/dkimproxy changed [not included] -- no debconf information -- Alexander E. Patrakov
Bug#945486: pwman3: fails to upgrade from 'buster': new pwman3 package pre-installation script subprocess returned error exit status 1
Package: pwman3 Version: 0.10.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'buster'. It installed fine in 'buster', then the upgrade to 'bullseye' fails. >From the attached log (scroll to the bottom...): Preparing to unpack .../8-pwman3_0.10.0-1_all.deb ... dpkg: error processing archive /tmp/apt-dpkg-install-BGTtaQ/8-pwman3_0.10.0-1_all.deb (--unpack): new pwman3 package pre-installation script subprocess returned error exit status 1 Preparing to unpack .../9-libaudit-common_1%3a2.8.5-2_all.deb ... Unpacking libaudit-common (1:2.8.5-2) over (1:2.8.4-3) ... Errors were encountered while processing: /tmp/apt-dpkg-install-BGTtaQ/8-pwman3_0.10.0-1_all.deb cheers, Andreas pwman3_0.10.0-1.log.gz Description: application/gzip
Bug#945015: only-branch only takes exact branch names
On Mon, 18 Nov 2019 12:42:55 +, Iain Lane wrote: > I think it'd be cool if this were instead to support globbing. If I were > to propose a merge request which changes this into a glob (Text::Glob?), > would you merge that? I think the idea totally makes sense, and if the change is backwards-compatible and doesn't pose any other issue I don't see why we wouldn't take it. Maybe Dam who wrote the webhook support has some ideas on how to best implement it or can share other thoughts. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Aimee Mann: Could've Been Anyone signature.asc Description: Digital Signature
Bug#943874: pure-ftpd: pure-ftp error on upgrade
Followup-For: Bug #943874 I can also reproduce this in piuparts in upgrades from buster to bullseye/sid. Unpacking pure-ftpd-common (1.0.49-1) over (1.0.47-3) ... dpkg: error processing archive /tmp/apt-dpkg-install-DSFTxC/9-pure-ftpd-common_1.0.49-1_all.deb (--unpack): unable to install new version of '/usr/share/doc/pure-ftpd-common/README.Authentication-Modules.gz': No such file or directory Errors were encountered while processing: /tmp/apt-dpkg-install-DSFTxC/9-pure-ftpd-common_1.0.49-1_all.deb In buster you have lrwxrwxrwx 1 root root 16 Jan 28 2019 /usr/share/doc/pure-ftpd -> pure-ftpd-common drwxr-xr-x 2 root root 420 Nov 25 20:28 /usr/share/doc/pure-ftpd-common in sid you have drwxr-xr-x 2 root root 320 Nov 25 20:30 /usr/share/doc/pure-ftpd drwxr-xr-x 2 root root 400 Nov 25 20:30 /usr/share/doc/pure-ftpd-common So there is something not working with the symlink to directory conversion, although the error is different than in the other cases of unhandled symlink to directory conversion I encountered. Quoting the corresponding piuparts bug template: Subject: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade It is recommended to use the dpkg-maintscript-helper commands 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14) to perform the conversion, ideally using d/$PACKAGE.maintscript. See dpkg-maintscript-helper(1) and dh_installdeb(1) for details. Andreas pure-ftpd_1.0.49-1.log.gz Description: application/gzip
Bug#945482: rocksndiamonds: Please update the new upstream release.
Thank you, sorry for pushing the request, I thought to do it with an NMU but it's true that it's still better when it's someone official. Has my request been poorly polished? Sincerely and thank you for your response. Sebastien Le 25/11/2019 à 21:18, Stephen Kitt a écrit : Hi Sebastien, On Mon, 25 Nov 2019 20:41:43 +0100, Sebastien CHAVAUX wrote: A new version is available, can you update? I am not sure how to proceed but I am trying to update the NMU package. I’m taking care of it, I’ll upload it soon. Regards, Stephen
Bug#945402: [Pkg-phototools-devel] Bug#945402: feh: Please add dcraw to the Suggests (or even Recommends) of the package
Control: tags -1 -moreinfo On Mon, Nov 25, 2019 at 9:03 PM Elena ``of Valhalla'' wrote: > On 2019-11-25 at 17:28:32 +0100, László Böszörményi (GCS) wrote: > > I think it was a regression due to an other package. Can you please > > do a full upgrade of your Bullseye installation and re-test your image > > with feh? Maybe share that file in private somehow? > > done the upgrade, the same thing is happening. While I can reproduce the problem, for me the displayed messages are these: TIFFReadDirectory: Warning, Photometric tag is missing, assuming data is YCbCr. TIFFReadDirectory: Warning, SamplesPerPixel tag is missing, applying correct SamplesPerPixel value of 3. OJPEGSubsamplingCorrect: Warning, Subsampling tag is not set, yet subsampling inside JPEG data [2,1] does not match default values [2,2]; assuming subsampling inside JPEG data is correct. OJPEGSetupDecode: Warning, Depreciated and troublesome old-style JPEG compression mode, please convert to new-style JPEG compression and notify vendor of writing software. OJPEGWriteHeaderInfo: jpeg_start_decompress() returned image_width = 4272 and image_height = 2848, expected 4272 and -1. > At first I thought it was a regression in libimlib2 (and was going to > open a bug on that package), but after reading the manpage of feh I > started to think that it was never supposed to work the way it did. For me this seems to be tiff checks that became stricter to prevent accidental crashes due to images not conforming the standards. As such the warnings show the sign of badly written OJPEG format that don't conform the standard. > As for the file, I have some that can be shared even in public; they are > between 15 and 20 MB so I'm not sure on the best way to do so (I'll try > to send you a private download link). Got it, as you could see above. Thanks, Laszlo/GCS
Bug#945482: rocksndiamonds: Please update the new upstream release.
Hi Sebastien, On Mon, 25 Nov 2019 20:41:43 +0100, Sebastien CHAVAUX wrote: > A new version is available, can you update? I am not sure how to proceed > but I am trying to update the NMU package. I’m taking care of it, I’ll upload it soon. Regards, Stephen pgpVIQGWhvo3L.pgp Description: OpenPGP digital signature
Bug#943614: [Python-modules-team] Bug#943614: cytoolz ftbfs with python3.8
Hi!, I've just push to salsa the new upstream version I'll need sponsorship for upload Thanks On Mon, Nov 25, 2019 at 10:18 AM Matthias Klose wrote: > Control: tags -1 + patch > > apparently fixed by the new upstream 0.10.1, example packaging at > https://launchpad.net/ubuntu/+source/python-cytoolz/0.10.1-0ubuntu1 > > ___ > Python-modules-team mailing list > python-modules-t...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team -- Cheers, Arias Emmaneul @eamanu yaerobi.com
Bug#945485: The test depends need to be updated for the new libnettle soname
Package: chiark-tcl Version: 1.3.2 The nettle soname changed from 6 to 7, the test control needs to be update, the attached patch should fix the issue Thanks, diff -Nru chiark-tcl-1.3.2/debian/tests/control chiark-tcl-1.3.3/debian/tests/control --- chiark-tcl-1.3.2/debian/tests/control 2018-10-14 02:33:49.0 +0200 +++ chiark-tcl-1.3.3/debian/tests/control 2019-11-25 21:10:51.0 +0100 @@ -29,18 +29,18 @@ Restrictions: skip-not-installable Tests: crypto--def -Depends: tcl, libc6 (>= 2.14), libnettle6, libtcl-chiark-1 +Depends: tcl, libc6 (>= 2.14), libnettle7, libtcl-chiark-1 Tests: crypto--8.5 -Depends: tcl8.5, libc6 (>= 2.14), libnettle6, libtcl-chiark-1 +Depends: tcl8.5, libc6 (>= 2.14), libnettle7, libtcl-chiark-1 Restrictions: skip-not-installable Tests: crypto--8.6 -Depends: tcl8.6, libc6 (>= 2.14), libnettle6, libtcl-chiark-1 +Depends: tcl8.6, libc6 (>= 2.14), libnettle7, libtcl-chiark-1 Restrictions: skip-not-installable Tests: crypto--8.7 -Depends: tcl8.7, libc6 (>= 2.14), libnettle6, libtcl-chiark-1 +Depends: tcl8.7, libc6 (>= 2.14), libnettle7, libtcl-chiark-1 Restrictions: skip-not-installable Tests: dgram--def
Bug#945402: [Pkg-phototools-devel] Bug#945402: feh: Please add dcraw to the Suggests (or even Recommends) of the package
On 2019-11-25 at 17:28:32 +0100, László Böszörményi (GCS) wrote: > I think it was a regression due to an other package. Can you please > do a full upgrade of your Bullseye installation and re-test your image > with feh? Maybe share that file in private somehow? done the upgrade, the same thing is happening. At first I thought it was a regression in libimlib2 (and was going to open a bug on that package), but after reading the manpage of feh I started to think that it was never supposed to work the way it did. As for the file, I have some that can be shared even in public; they are between 15 and 20 MB so I'm not sure on the best way to do so (I'll try to send you a private download link). > I think it should go to Suggests. I use Recommends if that extends > the package in some way. fine -- Elena ``of Valhalla'' signature.asc Description: PGP signature
Bug#945466: bridge_hw sometimes appears to be ignored or overridden
Hi! On Nov 25 2019, Boris Kolpackov wrote: > After upgrading to the latest testing version of all the packages, I now > observe what appears to be the bridge_hw address most of the time being > ignored and some random address being used instead (76:95:e6:8c:c3:9e). I have some questions, let's see if you can answer them. I'm reading that this did not happen before, what was the status before, pure buster? Wha packages related to networking do you have installed and got upgraded? Regards... -- Manty/BestiaTester -> http://manty.net
Bug#945484: itksnap: FTBFS with current insighttoolkit4 and gdcm
Source: itksnap Version: 3.6.0-3 Severity: serious User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu focal Dear maintainers, The itksnap package is not buildable in unstable with the current insighttoolkit4 and gdcm: [...] [100%] Building CXX object CMakeFiles/Test_OrientationWidget.dir/GUI/Renderer/OrientationWidget/Test_OrientationWidget/moc_OrientationWidgetGUI.cpp.o /usr/bin/c++ -DITK_IO_FACTORY_REGISTER_MANAGER -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_QML_LIB -DQT_WIDGETS_LIB -DvtkFiltersFlowPaths_AUTOINIT="1(vtkFiltersParallelFlowPaths)" -DvtkIOExodus_AUTOINIT="1(vtkIOParallelExodus)" -DvtkIOGeometry_AUTOINIT="1(vtkIOMPIParallel)" -DvtkIOImage_AUTOINIT="1(vtkIOMPIImage)" -DvtkIOParallel_AUTOINIT="1(vtkIOMPIParallel)" -DvtkIOSQL_AUTOINIT="2(vtkIOMySQL,vtkIOPostgreSQL)" -DvtkRenderingContext2D_AUTOINIT="1(vtkRenderingContextOpenGL)" -DvtkRenderingCore_AUTOINIT="3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL)" -DvtkRenderingFreeType_AUTOINIT="2(vtkRenderingFreeTypeFontConfig,vtkRenderingMatplotlib)" -DvtkRenderingLIC_AUTOINIT="1(vtkRenderingParallelLIC)" -DvtkRenderingVolume_AUTOINIT="1(vtkRenderingVolumeOpenGL)" -I/<>/obj-x86_64-linux-gnu/ITKIOFactoryRegistration -I/usr/include/hdf5/serial -I/usr/include/x86_64-linux-gnu -I/usr/include/nifti -I/usr/include/double-conversion -I/usr/include/vtk-6.3 -I/usr/include/freetype2 -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/include/hdf5/openmpi -I/usr/include/libxml2 -I/usr/include/jsoncpp -I/usr/include/python2.7 -I/usr/lib/cmake/ITK-4.12/Utilities/zlib -I/<>/Common -I/<>/Common/ITKExtras -I/<>/Logic -I/<>/Logic/Common -I/<>/Logic/Framework -I/<>/Logic/ImageWrapper -I/<>/Logic/LevelSet -I/<>/Logic/Mesh -I/<>/Logic/Preprocessing -I/<>/Logic/Preprocessing/GMM -I/<>/Logic/Preprocessing/Texture -I/<>/Logic/RLEImage -I/<>/Logic/Slicing -I/<>/Submodules/c3d/itkextras/RandomForest -I/<>/Submodules/c3d/api -I/<>/Submodules/greedy/src -I/<>/GUI -I/<>/GUI/Model -I/<>/GUI/Renderer -I/<>/GUI/Renderer/OrientationWidget/Reorient -I/<>/GUI/Qt -I/<>/GUI/Qt/Components -I/<>/GUI/Qt/Coupling -I/<>/GUI/Qt/External -I/<>/GUI/Qt/External/ColorWheel -I/<>/GUI/Qt/ModelView -I/<>/GUI/Qt/Testing -I/<>/GUI/Qt/View -I/<>/GUI/Qt/Windows -I/<>/GUI/Qt/Windows/MeshExportWizard -I/<>/GUI/Qt/Windows/Registration -I/<>/Testing/Logic -I/<>/Testing/GUI/Qt -I/<>/obj-x86_64-linux-gnu -isystem /usr/include/gdcm-2.8 -isystem /usr/include/ITK-4.12 -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem /usr/include/x86_64-linux-gnu/qt5/QtOpenGL -isystem /usr/include/x86_64-linux-gnu/qt5/QtConcurrent -isystem /usr/include/x86_64-linux-gnu/qt5/QtQml -isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -funroll-loops -ftree-vectorize -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -std=gnu++11 -o CMakeFiles/Test_OrientationWidget.dir/GUI/Renderer/OrientationWidget/Test_OrientationWidget/moc_OrientationWidgetGUI.cpp.o -c /<>/obj-x86_64-linux-gnu/GUI/Renderer/OrientationWidget/Test_OrientationWidget/moc_OrientationWidgetGUI.cpp In file included from /<>/GUI/Model/ColorLabelPropertyModel.h:6, from /<>/Logic/Framework/GlobalState.h:57, from /<>/GUI/Qt/Windows/MainImageWindow.h:31, from /<>/GUI/Qt/main.cxx:15: /<>/Logic/Common/ColorLabelTable.h:60:39: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated] 60 | void LoadFromFile(const char *file) throw(itk::ExceptionObject); | ^ /<>/Logic/Common/ColorLabelTable.h:61:43: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated] 61 | void SaveToFile(const char *file) const throw(itk::ExceptionObject); | ^ make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:439: CMakeFiles/Test_OrientationWidget.dir/all] Error 2 make[2]: *** Waiting for unfinished jobs make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:869: CMakeFiles/ITK-SNAP.dir/all] Error 2 make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu' make[1]: *** [Makefile:166: all] Error 2 make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu' dh_auto_build: cd obj-x86_64-linux-gnu && make -j4 "INSTALL=install --strip-program=true" returned exit code 2 [...] (https://launchpad.net/ubuntu/+source/itksnap/3.6.0-3build1/+build/18031852) It is unclear to me what is failing, since there are no errors in the build log prior to the errors
Bug#945483: tcp-wrappers FTCBFS: cross build support removed
Source: tcp-wrappers Version: 7.6.q-29 Tags: patch Severity: important User: debian-cr...@lists.debian.org Usertags: ftcbfs tcp-wrappers fails to cross build from source, because the last upload removed support for doing so. Please consider applying the attached patch. Helmut diff --minimal -Nru tcp-wrappers-7.6.q/debian/changelog tcp-wrappers-7.6.q/debian/changelog --- tcp-wrappers-7.6.q/debian/changelog 2019-11-24 23:29:52.0 +0100 +++ tcp-wrappers-7.6.q/debian/changelog 2019-11-25 20:51:29.0 +0100 @@ -1,3 +1,10 @@ +tcp-wrappers (7.6.q-29.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Mon, 25 Nov 2019 20:51:29 +0100 + tcp-wrappers (7.6.q-29) unstable; urgency=medium * Moved the library from /lib/ to /usr/lib/. (Closes: #941047) diff --minimal -Nru tcp-wrappers-7.6.q/debian/rules tcp-wrappers-7.6.q/debian/rules --- tcp-wrappers-7.6.q/debian/rules 2019-11-24 20:46:34.0 +0100 +++ tcp-wrappers-7.6.q/debian/rules 2019-11-25 20:51:28.0 +0100 @@ -24,7 +24,7 @@ dh_clean shared/ override_dh_auto_build: - $(MAKE) $(CROSS) COPTS="$(CFLAGS) $(CPPFLAGS)" LDOPTS="$(LDFLAGS)" $(build_target) + dh_auto_build -- COPTS="$(CFLAGS) $(CPPFLAGS)" LDOPTS="$(LDFLAGS)" $(build_target) override_dh_installdocs: dh_installdocs --link-doc=libwrap0
Bug#945482: rocksndiamonds: Please update the new upstream release.
Package: rocksndiamonds Version: 4.1.3.0+dfsg-1 Severity: wishlist Tags: upstream Dear Maintainer, A new version is available, can you update? I am not sure how to proceed but I am trying to update the NMU package. Cordially. -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rocksndiamonds depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii libsdl2-2.0-0 2.0.9+dfsg1-1 ii libsdl2-image-2.0-02.0.4+dfsg1-1+deb10u1 ii libsdl2-mixer-2.0-02.0.4+dfsg1-1 ii libsdl2-net-2.0-0 2.0.1+dfsg1-4 ii p7zip 16.02+dfsg-6 ii perl 5.28.1-6 ii unzip 6.0-23+deb10u1 ii wget 1.20.1-1.1 ii zip3.0-11+b1 ii zlib1g 1:1.2.11.dfsg-1 rocksndiamonds recommends no packages. rocksndiamonds suggests no packages. -- debconf information: * rocksndiamonds/select_games: Legend Of Zelda, Legend Of Zelda II, Emerald Mine Club, Contributions 1995 - 2006, Snake Bite, BD2K3, BD Dream, Supaplex, DX-Boulderdash, Sokoban, Tutorial Alpha, Earth 3120, Enhanced Emerald Mine, Might of Elementals, Secret Command, Natural, World of Amoeba, Some Levels, Walpurgis World, Walpurgis Gardens, Walpurgis Flashbacks, Earth Shaker, Earth Shaker Explosions, rnd_jue rocksndiamonds/util_notfound: * rocksndiamonds/begin: true rocksndiamonds/error_download:
Bug#900821: Reproduced on Apache container images for Docker/Kubernetes
Hi all, I experienced this problem while working with Apache container images deployed on a Kubernetes cluster on Azure (the containers are based on Debian). root@apache-nodeport-test-6595bf6579-5vsl6:/usr/local/apache2# hostname apache-nodeport-test-6595bf6579-5vsl6 root@apache-nodeport-test-6595bf6579-5vsl6:/usr/local/apache2# uname -a Linux apache-nodeport-test-6595bf6579-5vsl6 4.15.0-1060-azure #65-Ubuntu SMP Wed Sep 18 08:55:51 UTC 2019 x86_64 GNU/Linux root@apache-nodeport-test-6595bf6579-5vsl6:/usr/local/apache2# cat /etc/debian_version 10.2 root@apache-nodeport-test-6595bf6579-5vsl6:/usr/local/apache2# cat /etc/apt/sources.list # deb http://snapshot.debian.org/archive/debian/20191118T00Z buster main deb http://deb.debian.org/debian buster main # deb http://snapshot.debian.org/archive/debian-security/20191118T00Z buster/updates main deb http://security.debian.org/debian-security buster/updates main # deb http://snapshot.debian.org/archive/debian/20191118T00Z buster-updates main deb http://deb.debian.org/debian buster-updates main root@apache-nodeport-test-6595bf6579-5vsl6:/usr/local/apache2# apachectl -v Server version: Apache/2.4.41 (Unix) Server built: Nov 23 2019 00:34:14 I have tested 2 Apache 2.4.X containers, one from Azure, and one from Bitnami, with the same behaviour. Greetings, David.
Bug#945410: defaultroute sets gateway to 0.0.0.0
On 23/11/2019 19:38, Joey Hess wrote: > Using ppp for the first time in a year or so, it seems something has > broken WRT defaultroute, which was working before. Hi Joey, This seems surprising, or I'm sure I'd have heard much more about this by now. Curious. > There was no default route set before starting pppd. > After pon, this is the result: > > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse Iface > 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 ppp0 > 10.0.0.00.0.0.0 255.0.0.0 U 0 00 > wlx9cefd5fcd6f3 > 207.223.72.68 0.0.0.0 255.255.255.255 UH0 00 ppp0 This looks like output from the old 'route' tool. Would you mind also providing output from 'ip route' as well, please? What is your PPP link running on? I don't expect it to be a modem, but is it PPPoE or PPTP or a VPN of some kind? That might also help to nail things down. > So apparently it's set a default route with no gateway, if that's even a > thing. It certianly does not work. PPP interfaces are point-to-point so it's perfectly valid to have a route with no gateway address and just the interface as a destination. There's no ARP on the PPP link, and any packets stuffed down the interface (should) end up on the other end. There's no notion of a router IP address on such links. > Manually adding 207.223.72.68 as the default gateway makes the connection > work. This doesn't make much sense to me, but a before and after of your route table using 'ip route' would be really helpful and might shed some light on the situation. [snip] > I enabled debug and didn't see anything in the log about routing. > Here's the relevant part of the log, after authentication > (log is in reverse order) No, ppp doesn't negotiate a default route, it's up to each end to add one as required. Hence the defaultroute / nodefaultroute options for pppd. Cheers, Chris -- Chris Boot bo...@debian.org
Bug#944627: fixed in chromium 78.0.3904.108-1
Control: found -1 78.0.3904.108-1 On Thu, 21 Nov 2019 13:57:06 + Michael Gilbert wrote: > chromium (78.0.3904.108-1) unstable; urgency=medium > . >* New upstream security release. > - CVE-2019-13723: Use-after-free in Bluetooth. Reported by Yuxiang Li > - CVE-2019-13724: Out-of-bounds in Bluetooth. Reported by Yuxiang Li >* Disable vaapi on armhf (closes: #944627). From https://buildd.debian.org/status/fetch.php?pkg=chromium=armhf=78.0.3904.108-1=1574381228=0: > [20962/20964] AR obj/content/shell/libcontent_shell_lib.a > [20963/20964] LINK ./chrome > FAILED: chrome > g++ -Wl,--version-script=../../build/linux/chrome.map -Wl,--fatal-warnings > -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs > -Wl,--no-as-needed -fuse-ld=gold > -B../../third_party/binutils/Linux_x64/Release/bin -Wl,--icf=all -Wl,-O2 > -Wl,--gc-sections -rdynamic -pie -Wl,--disable-new-dtags -Wl,--stats > -Wl,--stats -o "./chrome" -Wl,--start-group @"./chrome.rsp" -Wl,--end-group > -latomic -ldl -lpthread -lrt -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor > -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst -lgmodule-2.0 -lgobject-2.0 > -lgthread-2.0 -lglib-2.0 -ljsoncpp -licui18n -licuuc -licudata -lnss3 > -lnssutil3 -lsmime3 -lplds4 -lplc4 -lnspr4 -lcups -lxml2 -lfontconfig > -ldbus-1 -levent -lresolv -lgio-2.0 -lz -ljpeg -lpng16 -lwebpdemux -lwebpmux > -lwebp -lfreetype -lexpat -lharfbuzz -lre2 -lsnappy -ldrm -lXrandr -lpci > -lXss -lasound -lpulse -lavcodec -lavformat -lavutil -lvpx -lm -lopus > -latk-1.0 -latk-bridge-2.0 -lva -lpangocairo-1.0 -lpango-1.0 -lcairo > -lminizip -latspi -lFLAC -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 > -lxslt -llcms2 -lopenjp2 > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::H264Encoder(std::unique_ptr std::default_delete >): error: undefined > reference to 'media::H264BitstreamBuffer::H264BitstreamBuffer()' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::H264Encoder(std::unique_ptr std::default_delete >): error: undefined > reference to 'media::H264BitstreamBuffer::H264BitstreamBuffer()' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::Reset()' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::BeginNALU(media::H264NALU::Type, int)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendU64(unsigned int, unsigned long long)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendBool(bool)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendBool(bool)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendBool(bool)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendBool(bool)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendU64(unsigned int, unsigned long long)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendU64(unsigned int, unsigned long long)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendUE(unsigned int)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendUE(unsigned int)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendUE(unsigned int)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendUE(unsigned int)' > obj/media/gpu/vaapi/vaapi/h264_encoder.o:h264_encoder.cc:function > media::H264Encoder::GeneratePackedSPS(): error: undefined reference to > 'media::H264BitstreamBuffer::AppendU64(unsigned int, unsigned long
Bug#945353: Vagrant libvirt and virtualbox providers missing for buster64 10.1.0
Le 25/11/2019 à 11:40, Jonas Meurer a écrit : > Hi Emmanuel, > > Emmanuel Kasper: >> Le 23/11/2019 à 14:17, Jonas Meurer a écrit : >>> Package: cloud.debian.org >>> Severity: important >>> >>> Hello, >>> >>> for some reason, boxes for providers 'libvirt' and 'virtualbox' are missing >>> for >>> buster64 tag 'v10.1.0' from https://app.vagrantup.com/debian/boxes/buster64. >>> >>> Unfortunately, this breaks inital setup of debian/buster64 boxes with those >>> providers, as many packages from the 10.0.0 apt sources list caches don't >>> exist >>> in the archives any longer. >> >> Thanks you for your interest for the Debian Vagrant Boxes. >> Unfortunately we don't have point releases for Vagrant Boxes for Buster, >> see here for the rationale: >> https://lists.debian.org/debian-cloud/2019/09/msg00041.html > > Thanks for the pointer. I understand your rationale, but ... > >> The package cache for Base Boxes is anyway always updated, since we >> don't rebuild the boxes after every security upgrade which has been >> pushed to the archive. >> >> Concerning the package cache, what prevents you from refreshing it >> before installing new packages ? > > The problem seems to be, that Vagrant itsels doesn't update the package > cache before provisioning. For virtualbox, vagrant per default tries to > install the VirtualBox Guest Additions. Does it ? Using the Debian package and for what I remember from Windows from two years ago, I don't remember pristine Vagrant trying to install the guest additions by itself ( could have changed though ...) Are you using the vagrant-vbguest plugin ? If that's the case, you could then use the Contrib Buster 64 boxes which has the guest additions already installed. https://app.vagrantup.com/debian/boxes/contrib-buster64 This fails if the package cache > wasn't updated in the meantime, as the referenced kernel package doesn't > exist any longer. > Also, isn't it that between point releases no packages are removed from > the achives? Therefore it should be less likely that outdated cache > causes errors, right? Less likely to occur, yes, but you still have the base problem -- You know an upstream is nice when they even accept m68k patches. - John Paul Adrian Glaubitz, Debian OpenJDK maintainer
Bug#945481: Bump minimum version of ruby-molinillo dependency in ruby-bundler
Package: bundler Version: 1.17.3-3 Severity: serious While upgrading from stretch to buster I noticed this error with bundler and bundler command failed. NoMethodError: undefined method `message_with_trees' for # This was resolved by updating ruby-molinillo from buster. Currently ruby-bundler declares ruby-molinillo (>= 0.4.5~) it should be updated to >= 0.6~ # Error Report ## Questions Please fill out answers to these questions, it'll help us figure out why things are going wrong. - **What did you do?** I ran the command `/usr/bin/bundle --local --quiet` - **What did you expect to happen?** I expected Bundler to... - **What happened instead?** Instead, what happened was... - **Have you tried any solutions posted on similar issues in our issue tracker, stack overflow, or google?** I tried... - **Have you read our issues document, https://github.com/bundler/bundler/blob/master/doc/contributing/ISSUES.md?** ... ## Backtrace ``` NoMethodError: undefined method `message_with_trees' for # /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/resolver.rb:303:in `version_conflict_message' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/resolver.rb:55:in `rescue in start' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/resolver.rb:45:in `start' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/resolver.rb:22:in `resolve' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/definition.rb:258:in `resolve' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/definition.rb:170:in `specs' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/definition.rb:151:in `resolve_with_cache!' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/installer.rb:310:in `resolve_if_needed' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/installer.rb:84:in `block in run' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/process_lock.rb:12:in `block in lock' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/process_lock.rb:9:in `open' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/process_lock.rb:9:in `lock' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/installer.rb:73:in `run' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/installer.rb:25:in `install' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/cli/install.rb:65:in `run' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/cli.rb:235:in `block in install' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/settings.rb:143:in `temporary' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/cli.rb:234:in `install' /usr/lib/ruby/vendor_ruby/thor/command.rb:27:in `run' /usr/lib/ruby/vendor_ruby/thor/invocation.rb:126:in `invoke_command' /usr/lib/ruby/vendor_ruby/thor.rb:369:in `dispatch' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/cli.rb:27:in `dispatch' /usr/lib/ruby/vendor_ruby/thor/base.rb:444:in `start' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/cli.rb:18:in `start' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/exe/bundle:30:in `block in ' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors' /usr/share/rubygems-integration/all/gems/bundler-1.17.3/exe/bundle:22:in `' /usr/bin/bundle:23:in `load' /usr/bin/bundle:23:in `' ``` ## Environment ``` Bundler 1.17.3 Platforms ruby, x86_64-linux Ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-linux-gnu] Full Path /usr/bin/ruby2.5 Config Dir /etc RubyGems 2.7.6.2 Gem Home /var/lib/gitlab/.gem Gem Path /var/lib/gitlab/.gem/ruby/2.5.0:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all:/var/lib/gitlab/.gem User Path /var/lib/gitlab/.gem/ruby/2.5.0 Bin Dir /var/lib/gitlab/.gem/bin OpenSSL Compiled OpenSSL 1.1.1c 28 May 2019 Loaded OpenSSL 1.1.1d 10 Sep 2019 Cert File /usr/lib/ssl/cert.pem Cert Dir /usr/lib/ssl/certs Tools Git 2.20.1 RVM not installed rbenv not installed chruby not installed Gem.ruby /usr/bin/ruby2.5 bundle #! /usr/bin/ruby ``` ## Bundler Build Metadata ``` Built At 2018-12-27 Git SHA d7089abb6 Released Version true ``` ## Bundler settings ``` without Set for your local app (/usr/share/gitlab/.bundle/config): [:development, :test] Set for the current user (/var/lib/gitlab/.bundle/config): [:development, :test] ```
Bug#664717: Contact Him.
-- Hello Dear. I want to inform you about the success in transferring the funds.I left 3.8 USD compensation for your efforts. Do contact my secretary via his email address for your money .I appreciate your efforts so much. E-mail contact address[george.pow...@hotmail.com] Contact Person; Mr george.powder Regards. Patrick Ozougo Esq.
Bug#944480: transition: libdvdread
On 2019-11-24 21:01:11, Paul Gevers wrote: > Control: tags -1 confirmed > > Hi Sebastian, > > On 10-11-2019 18:08, Sebastian Ramacher wrote: > > libdvdread bumped its SONAME from 4 to 7. All reverse dependencies build > > fine against the new version. > > Please go ahead in unstable. Uploaded and built almost everywhere. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#944263: python-releases: FTBFS in unstable
Control: tags -1 patch Hi, I tried to use the newer upstream version to see if this issue might be fixed here. But no, it's still existing also in version 1.6.1. But there is an MR in the upstream poject that fixes this build issue. https://github.com/bitprophet/releases/pull/86 The origin of this MR can be found here. https://github.com/rbarrois/releases/commit/8787236dffb7383427b3e1448ece9a5b3eaf5257 I can confirm that this patch fixes the FTBFS for 1.4.0 but also with the current most recent upstream version 1.6.1. Regards Carsten
Bug#890534: jigdo-file: Allow to output directly to USB stick
Control: severity -1 wishlist Control: tag -1 wontfix Hi Samuel, Sorry, I think this is something best done with other tools. On Thu, Feb 15, 2018 at 06:55:11PM +0100, Samuel Thibault wrote: >Package: jigdo-file >Version: 0.7.3-5 >Severity: normal > >Hello, > >It would be useful to be able to directly write the image to a USB >stick, something like > >jigdo-lite --image=/dev/sdb --force >http://cdimage.debian.org/cdimage/release/9.3.0/amd64/jigdo-cd/debian-9.3.0-amd64-netinst.jigdo > >which would need to add the --image option to jigdo-lite, and make >jigdo-file be fine with a device output (ATM it complains that the >destionation already exists, even with --force). > >Samuel > >-- System Information: >Debian Release: buster/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, > 'testing-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, > 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), > (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') >Architecture: amd64 (x86_64) >Foreign Architectures: i386 > >Kernel: Linux 4.15.0 (SMP w/4 CPU cores) >Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), >LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) >Shell: /bin/sh linked to /bin/dash >Init: systemd (via /run/systemd/system) > >Versions of packages jigdo-file depends on: >ii libbz2-1.0 1.0.6-8.1 >ii libc6 2.26-4 >ii libdb5.35.3.28-13.1+b1 >ii libgcc1 1:8-20180207-2 >ii libstdc++6 8-20180207-2 >ii wget1.19.4-1 >ii zlib1g 1:1.2.8.dfsg-5 > >jigdo-file recommends no packages. > >jigdo-file suggests no packages. > >-- no debconf information > >-- >Samuel > ça gaze ? > prout > -+- #ens-mim - ouvrez les fenêtres ! -+- -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Bug#941928: RFS: scons-doc/3.1.1+repack-1 -- Documentation for SCons, a replacement for Make
> >* New upstream release. > Otherwise, looks good. I want to take this occasion to ask: any chance for this package to built using python3? I'm looking at dropping the py2 packages from libxml2 and libxslt, and in paticular the latter doesn't have py3 support at all upstream at this time. -- 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#945480: [PATCH 1/1] Remove remaining usage of python2
---
check | 2 +-
setup.py | 2 +-
yarns/900-implements.yarn | 10 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/check b/check
index 2d3d52c..290797e 100755
--- a/check
+++ b/check
@@ -4,7 +4,7 @@ set -eu
python3 -m CoverageTestRunner --ignore-missing-from=without-tests yarns vmdb
yarn \
---shell=python2 \
+--shell=python3 \
--shell-arg '' \
--shell-library yarns/lib.py \
--env "PYTHONPATH=$(pwd)/yarns" \
diff --git a/setup.py b/setup.py
index 3b89429..bd56d2b 100755
--- a/setup.py
+++ b/setup.py
@@ -45,7 +45,7 @@ class Build(build):
def generate_troff(self, program, lang):
with open('%s.1%s' % (program, lang), 'w') as f:
cliapp.runcmd(
-['python', program,
+['python3', program,
'--generate-manpage=%s.1%s.in' % (program, lang),
'--output=%s.1' % program],
stdout=f)
diff --git a/yarns/900-implements.yarn b/yarns/900-implements.yarn
index f8bc328..c0b7af1 100644
--- a/yarns/900-implements.yarn
+++ b/yarns/900-implements.yarn
@@ -13,15 +13,15 @@ This chapter contains the implementations for all scenario
steps.
vmdb2 = os.path.join(srcdir, 'vmdb2')
exit, out, err = cliapp.runcmd_unchecked([vmdb2] + args.split())
vars['exit'] = exit
-vars['stdout'] = out
-vars['stderr'] = err
+vars['stdout'] = out.decode()
+vars['stderr'] = err.decode()
IMPLEMENTS THEN exit code is (\d+)
wanted = int(get_next_match())
exit = vars['exit']
-print 'exit code', exit
-print 'stdout:', vars['stdout']
-print 'stderr:', vars['stderr']
+print('exit code', exit)
+print('stdout:', vars['stdout'])
+print('stderr:', vars['stderr'])
assertEqual(exit, wanted)
IMPLEMENTS THEN stdout contains "(.+)" followed by "(.+)"
--
2.24.0
Bug#945480: [PATCH 0/1] Drop remaining usage of python2
Hello, The following patch drops the remaining usage of python2 in vmdb2, in the build system and test suite. Gunnar: I just uploaded a cmdtest ported to python3, so without this vmdb2 will still fail to build because the test suite uses yarn internals which will not be available for python2 anymore. Antonio Terceiro (1): Remove remaining usage of python2 check | 2 +- setup.py | 2 +- yarns/900-implements.yarn | 10 +- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.24.0
Bug#945478: Fwd: Debian scanlogd package
Forwarded Message Subject: Re: Debian scanlogd package Date: Mon, 25 Nov 2019 18:19:47 +0100 From: Solar Designer To: Andreas Beckmann Hi Andreas, On Mon, Nov 25, 2019 at 06:15:16PM +0100, Andreas Beckmann wrote: > can I turn your (private) messages w.r.t. scanlogd into a bug report in > the Debian BTS (publically accessible), s.t. they are available to > anyone who is going to update the scanlogd package? Sure, feel free. Thanks for asking, and for the prompt response. Alexander
Bug#945478: Fwd: Debian scanlogd package
Forwarded Message Subject: Re: Debian scanlogd package Date: Mon, 25 Nov 2019 17:58:04 +0100 From: Solar Designer To: Michael Vogt , Scott Kitterman , Andreas Beckmann , Joao Eriberto Mota Filho On Mon, Nov 25, 2019 at 04:04:15PM +0100, Solar Designer wrote: > As upstream author, I am getting occasional problem reports about the > Debian package, and I wonder whether issues are introduced by effects of > the above change on some systems (in particular, non-x86, where these > constants in the kernel are more likely to differ). A user has just reported that building 2.2.7 from source made the problem (of not detecting scans) go away. This is on ARM. Alexander
Bug#945478: Fwd: Debian scanlogd package
Forwarded Message Subject: Re: Debian scanlogd package Date: Mon, 25 Nov 2019 16:07:46 +0100 From: Solar Designer To: Michael Vogt , Scott Kitterman , Andreas Beckmann , Joao Eriberto Mota Filho On Mon, Nov 25, 2019 at 04:04:15PM +0100, Solar Designer wrote: > Can one of you please update the scanlogd package in Debian to current > upstream version 2.2.7, and drop the patching of CLK_TCK to > CLOCKS_PER_SEC, which is a subtly wrong workaround previously applied in > the Debian package. The actual correct value can only be reliably > determined at runtime (which version 2.2.7 does), and besides > CLOCKS_PER_SEC is for clock(3) whereas we use times(2). More on this issue: https://www.openwall.com/lists/xvendor/2006/04/17/1 Debian's wrong fix made instead of simply updating to new upstream version at the time (would be 2.2.6): scanlogd (2.2.5-2.1) unstable; urgency=medium * Non-maintainer upload during BSP. * Substitute CLK_TCK with CLOCKS_PER_SEC in scanlogd.c and P53-13 to avoid FTBFS with new glibc. (Closes: #421085). * Use now dh_installman instead of dh_installmanpages -- Mario Iseli Thu, 17 May 2007 20:30:11 +0200 > As upstream author, I am getting occasional problem reports about the > Debian package, and I wonder whether issues are introduced by effects of > the above change on some systems (in particular, non-x86, where these > constants in the kernel are more likely to differ). > > Debian's patching of the historical Phrack article is especially weird, > and is a misattribution of your newer changes to me. Please revert > those edits (e.g. take the original article off the scanlogd homepage). > > While at it, please update "copyright" to reflect scanlogd's current > license (it's changed since someone copied the old one into that file). > > Thanks, > > Alexander
Bug#945480: vmdb2: FTBFS on unstable: pylint failure
Source: vmdb2
Version: 0.13.2+git20190215-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
The build currently fails with:
Traceback (most recent call last):
File "/usr/bin/pylint3", line 11, in
load_entry_point('pylint==2.2.2', 'console_scripts', 'pylint')()
File "/usr/lib/python3/dist-packages/pylint/__init__.py", line 20, in
run_pylint
Run(sys.argv[1:])
File "/usr/lib/python3/dist-packages/pylint/lint.py", line 1608, in __init__
linter.check(args)
File "/usr/lib/python3/dist-packages/pylint/lint.py", line 938, in check
self._do_check(files_or_modules)
File "/usr/lib/python3/dist-packages/pylint/lint.py", line 1071, in _do_check
self.check_astroid_module(ast_node, walker, rawcheckers, tokencheckers)
File "/usr/lib/python3/dist-packages/pylint/lint.py", line 1154, in
check_astroid_module
walker.walk(ast_node)
File "/usr/lib/python3/dist-packages/pylint/utils.py", line 1269, in walk
self.walk(child)
File "/usr/lib/python3/dist-packages/pylint/utils.py", line 1266, in walk
cb(astroid)
File "/usr/lib/python3/dist-packages/pylint/checkers/variables.py", line
1582, in visit_import
module = next(node.infer_name_module(parts[0]))
AttributeError: 'Import' object has no attribute 'infer_name_module'
make[1]: *** [debian/rules:14: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
This is caused by the build dependency on pylint3, which is an obsolete
binary package and is not compatible anymore with the version of one of
its dependencies in unstable. a fix for this would be just change the
dependency to pylint, but TBH running linters like pylint during the
build make the build flaky because new checks added to the linter can
make the package suddenly fail to build.
I see that the call to pylink has been dropped upstream, so a new
upstream release should fix this.
FWIW the full build log is attached.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
vmdb2_amd64.build.gz
Description: application/gzip
signature.asc
Description: PGP signature
Bug#890534: jigdo-file: Allow to output directly to USB stick
Steve McIntyre, le lun. 25 nov. 2019 18:04:52 +, a ecrit: > Sorry, I think this is something best done with other tools. Which other tools? The point here is to avoid having to store the image in a filesystem before putting it on a stick. If jigdo doesn't support it, I don't see how another tool could make it happen. The only alternative I see is to use wget -O /dev/sdb, but then we don't get jigdo support (use of local debian archive or ISO CDs), which is not recommended by Debian since it prevents a lot of optimizations. Really, I don't see how to achieve the same (use of local debian archive etc.) without stuffing the support in jigdo itself. Samuel > On Thu, Feb 15, 2018 at 06:55:11PM +0100, Samuel Thibault wrote: > >Package: jigdo-file > >Version: 0.7.3-5 > >Severity: normal > > > >Hello, > > > >It would be useful to be able to directly write the image to a USB > >stick, something like > > > >jigdo-lite --image=/dev/sdb --force > >http://cdimage.debian.org/cdimage/release/9.3.0/amd64/jigdo-cd/debian-9.3.0-amd64-netinst.jigdo > > > >which would need to add the --image option to jigdo-lite, and make > >jigdo-file be fine with a device output (ATM it complains that the > >destionation already exists, even with --force). > > > >Samuel > > > >-- System Information: > >Debian Release: buster/sid > > APT prefers testing > > APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, > > 'testing-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, > > 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), > > (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') > >Architecture: amd64 (x86_64) > >Foreign Architectures: i386 > > > >Kernel: Linux 4.15.0 (SMP w/4 CPU cores) > >Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), > >LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) > >Shell: /bin/sh linked to /bin/dash > >Init: systemd (via /run/systemd/system) > > > >Versions of packages jigdo-file depends on: > >ii libbz2-1.0 1.0.6-8.1 > >ii libc6 2.26-4 > >ii libdb5.35.3.28-13.1+b1 > >ii libgcc1 1:8-20180207-2 > >ii libstdc++6 8-20180207-2 > >ii wget1.19.4-1 > >ii zlib1g 1:1.2.8.dfsg-5 > > > >jigdo-file recommends no packages. > > > >jigdo-file suggests no packages. > > > >-- no debconf information
Bug#945014: Debian stretch also affected
found 945014 enigmail/2:2.0.8-5~deb9u1 thanks According to https://lists.debian.org/debian-security-announce/2019/msg00223.html, stretch is affected in the same way, but the update landed in buster only. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature
Bug#945479: dh-golang: improve cross compiling: export PKG_CONFIG
Source: dh-golang
Version: 1.43
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:golang-github-docker-docker-credential-helpers
Hi,
After marking dh-golang Multi-Arch: foreign, a number of golang-*
packages have become bd-satisfiable. One of them is
golang-github-docker-docker-credential-helpers.
The immediate failure is failing to run go as the host architecture go
is installed. I'm not yet set on this part. I'd like to gain a bit more
experience with go before raising it with possible solutions on the
list. A temporary workaround is adding :native.
Once you do that, you run into the actual problem:
| # pkg-config --cflags -- libsecret-1
| Package libsecret-1 was not found in the pkg-config search path.
| Perhaps you should add the directory containing `libsecret-1.pc'
| to the PKG_CONFIG_PATH environment variable
| No package 'libsecret-1' found
| pkg-config: exit status 1
| github.com/docker/docker-credential-helpers/pass/cmd
| dh_auto_build: cd obj-powerpc64le-linux-gnu && go install
-gcflags=all=\"-trimpath=/<>/obj-powerpc64le-linux-gnu/src\"
-asmflags=all=\"-trimpath=/<>/obj-powerpc64le-linux-gnu/src\" -v
-p 8 github.com/docker/docker-credential-helpers/client
github.com/docker/docker-credential-helpers/credentials
github.com/docker/docker-credential-helpers/osxkeychain
github.com/docker/docker-credential-helpers/pass
github.com/docker/docker-credential-helpers/pass/cmd
github.com/docker/docker-credential-helpers/secretservice
github.com/docker/docker-credential-helpers/secretservice/cmd returned exit
code 2
| make[1]: *** [debian/rules:9: override_dh_auto_build] Error 255
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:6: build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2
What happens here is that we have a go file with a syntax "#cgo
pkg-config libsecret-1". This is apparently interpreted by go to run
pkg-config and it uses the build architecture one ... unless one exports
PKG_CONFIG.
So, the golang build system should also pass PKG_CONFIG. My previous
patch already made it pass CC.
Doing so does not fix golang-github-docker-docker-credential-helpers. It
does advance the build a little. More issues reside there, but this one
is well understood now. Please consider applying the attached patch.
Helmut
diff --minimal -Nru dh-golang-1.43/debian/changelog
dh-golang-1.43+nmu1/debian/changelog
--- dh-golang-1.43/debian/changelog 2019-11-22 23:14:21.0 +0100
+++ dh-golang-1.43+nmu1/debian/changelog2019-11-25 18:48:53.0
+0100
@@ -1,3 +1,10 @@
+dh-golang (1.43+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Also export PKG_CONFIG for cross compiling. (Closes: #-1)
+
+ -- Helmut Grohne Mon, 25 Nov 2019 18:48:53 +0100
+
dh-golang (1.43) unstable; urgency=medium
[ Helmut Grohne ]
diff --minimal -Nru dh-golang-1.43/lib/Debian/Debhelper/Buildsystem/golang.pm
dh-golang-1.43+nmu1/lib/Debian/Debhelper/Buildsystem/golang.pm
--- dh-golang-1.43/lib/Debian/Debhelper/Buildsystem/golang.pm 2019-11-22
19:50:36.0 +0100
+++ dh-golang-1.43+nmu1/lib/Debian/Debhelper/Buildsystem/golang.pm
2019-11-25 18:48:49.0 +0100
@@ -344,6 +344,9 @@
unless ($ENV{CC}) {
$ENV{CC} = dpkg_architecture_value("DEB_HOST_GNU_TYPE") . "-gcc";
}
+unless ($ENV{PKG_CONFIG}) {
+$ENV{PKG_CONFIG} = dpkg_architecture_value("DEB_HOST_GNU_TYPE") .
"-pkg-config";
+}
$ENV{CGO_ENABLED} = "1";
Bug#945478: scanlogd: wrong patch, wrong copyright, new upstream release 2.2.7
Source: scanlogd Version: 2.2.5-3.3 Severity: serious Control: submitter -1 [ Turning the private messages into a public bug report with submitters consent. ] [ RC severity for DFSG violations (wrong copyright file) ] Forwarded Message Subject: Debian scanlogd package Date: Mon, 25 Nov 2019 16:04:15 +0100 From: Solar Designer To: Michael Vogt , Scott Kitterman , Andreas Beckmann , Joao Eriberto Mota Filho Hi, Can one of you please update the scanlogd package in Debian to current upstream version 2.2.7, and drop the patching of CLK_TCK to CLOCKS_PER_SEC, which is a subtly wrong workaround previously applied in the Debian package. The actual correct value can only be reliably determined at runtime (which version 2.2.7 does), and besides CLOCKS_PER_SEC is for clock(3) whereas we use times(2). As upstream author, I am getting occasional problem reports about the Debian package, and I wonder whether issues are introduced by effects of the above change on some systems (in particular, non-x86, where these constants in the kernel are more likely to differ). Debian's patching of the historical Phrack article is especially weird, and is a misattribution of your newer changes to me. Please revert those edits (e.g. take the original article off the scanlogd homepage). While at it, please update "copyright" to reflect scanlogd's current license (it's changed since someone copied the old one into that file). Thanks, Alexander
Bug#943504: firefox-esr: Firefox Wayland crashes at startup
Seems to be possible to fix that with the configuration option --enable-default-toolkit=cairo-gtk3-wayland like it is done on the newer official builds. I don't know how this changes the build requirements. Don't know if you want to do such a change in stable. Maybe you just want to add a check for GDK_BACKEND. Then you can add --no-remote in /usr/bin/firefox That changes behaviour. But only in the case when it would crash. So I think no one would complain about that. Maybe besides displaying a proper warning. smime.p7s Description: S/MIME cryptographic signature
Bug#936313: [PATCH 1/3] Port to python3
good stuff, thanks! :) On Mon, Nov 25, 2019 at 12:02 PM Antonio Terceiro wrote: > > On Mon, Nov 25, 2019 at 10:58:42AM -0500, Sandro Tosi wrote: > > Antonio, this package is orphaned - just go ahead and do a QA upload for it > > :) > > Yes, I know. That was me sending the patches upstream - I copied the bug > report to have a publically archived record of them. > > I'm actually adopting it in the python modules team because it's a > dependency for stuff I use. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#936313: [PATCH 1/3] Port to python3
On Mon, Nov 25, 2019 at 10:58:42AM -0500, Sandro Tosi wrote: > Antonio, this package is orphaned - just go ahead and do a QA upload for it :) Yes, I know. That was me sending the patches upstream - I copied the bug report to have a publically archived record of them. I'm actually adopting it in the python modules team because it's a dependency for stuff I use. signature.asc Description: PGP signature
Bug#943504: firefox-esr: Firefox Wayland crashes at startup
Seems to be possible to fix that with the configuration option --enable-default-toolkit=cairo-gtk3-wayland like it is done on the newer official builds. I don't know how this changes the build requirements. Don't know if you want to do such a change in stable. Maybe you just want to add a check for GDK_BACKEND. Then you can add --no-remote in /usr/bin/firefox That changes behaviour. But only in the case when it would crash. So I think no one would complain about that. smime.p7s Description: S/MIME cryptographic signature
Bug#942187: fixed in xdmf 3.0+git20190531-2
Version: 3.0+git20190531-3 On Wed, 30 Oct 2019 16:51:46 + Alastair McKinstry wrote: > xdmf (3.0+git20190531-2) unstable; urgency=medium > . >* Revert libloki changes; xdmf version is not compatible. > Closes: #942187 This changelog entry seems unrelated to #942187 which is about Preparing to unpack .../31-libxdmf-dev_3.0+git20190531-3_amd64.deb ... Unpacking libxdmf-dev (3.0+git20190531-3) over (3.0+git20160803-5+b1) ... dpkg: error processing archive /tmp/apt-dpkg-install-bgCaUu/31-libxdmf-dev_3.0+git20190531-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/xdmf/openmpi/libXdmf.so', which is also in package libxdmf3:amd64 3.0+git20160803-5+b1 Preparing to unpack .../32-libxdmf3_3.0+git20190531-3_amd64.deb ... Unpacking libxdmf3:amd64 (3.0+git20190531-3) over (3.0+git20160803-5+b1) ... Errors were encountered while processing: /tmp/apt-dpkg-install-bgCaUu/31-libxdmf-dev_3.0+git20190531-3_amd64.deb libxdmf-dev is missing a Breaks+Replaces: libxdmf3 (<< 3.0+git20190531) Andreas
Bug#944350: [External] Bug#944350: systemd: screen remains off after waking up from suspend
Hi, I don't know if this is helpful but I recently debugged a similar issue on the Lenovo P1Gen2. There the problem is only with the integrated graphics and an OLED screen - we tracked it down to an issue in the i915 driver where it wasn't giving enough time for eDP link training. It turned out this was due to the driver using the wrong clocks after a suspend and resume . Intel recently up-streamed a fix (commit 2f216a85 - it went into 5.4-rc8) I'm working on doing a patch that I'm hoping to get into Debian to backport - just not done yet :) The patch is pretty small (I've attached it) so you might want to give it a go and see if it helps. Note - we did also test X1 extreme with OLED panel and didn't see a problem therebut it's a really subtle timing issue so some units might be more susceptible than others. Maybe worth a go? If it does make a difference let me know. Mark > -Original Message- > From: Jiri Kanicky > Sent: Sunday, November 24, 2019 9:13 PM > To: 944...@bugs.debian.org > Subject: [External] Bug#944350: systemd: screen remains off after waking up > from suspend > > Further to the issue, when I set BIOS to discrete graphics only, I am > experiencing the same issue when booting the system from shutdown state. > The screen stays off, but the OS is booted and working. 0001-drm-i915-update-rawclk-also-on-resume.patch Description: 0001-drm-i915-update-rawclk-also-on-resume.patch
Bug#827848: snapd: Purging snapd doesn't properly delete snapd from the system
Version: 2.37.4-1+b1 Now trying to purge snapd leads directly to an error: $ sudo apt purge snapd Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: snapd* 0 upgraded, 0 newly installed, 1 to remove and 7 not upgraded. After this operation, 61.0 MB disk space will be freed. Do you want to continue? [Y/n] Y (Reading database ... 394506 files and directories currently installed.) Removing snapd (2.37.4-1+b1) ... Processing triggers for mime-support (3.62) ... Processing triggers for gnome-menus (3.31.4-3) ... Processing triggers for man-db (2.8.5-2) ... Processing triggers for desktop-file-utils (0.23-4) ... (Reading database ... 394456 files and directories currently installed.) Purging configuration files for snapd (2.37.4-1+b1) ... Stopping snap-core-8039.mount Stopping unit snap-core-8039.mount Waiting until unit snap-core-8039.mount is stopped [attempt 1] snap-core-8039.mount is stopped. Removing snap core and revision 8039 Removing snap-core-8039.mount Final directory cleanup Discarding preserved snap namespaces Removing extra snap-confine apparmor rules Removing snapd cache rm: cannot remove '/var/cache/snapd/aux': Is a directory dpkg: error processing package snapd (--purge): installed snapd package post-removal script subprocess returned error exit status 1 Errors were encountered while processing: snapd E: Sub-process /usr/bin/dpkg returned an error code (1)
Bug#877007: orpie FTBFS on armel/armhf/mips/mipsel: #error "Architectures with double-word alignment for doubles are not supported"
On Mon, Nov 25, 2019 at 02:46:25PM +0200, Adrian Bunk wrote: > On Mon, Nov 25, 2019 at 01:26:21PM +0100, Vincent Lefevre wrote: > > On 2019-11-25 14:16:53 +0200, Adrian Bunk wrote: > > > This is fixed now, but testing migration needs a source-only upload. > > > > But this will yield a FTBFS on armel/armhf/mips/mipsel. > > Which is not a problem since there are no old binaries on these > architectures in the archive: > https://tracker.debian.org/pkg/orpie > > 1.6.0 would be nice and fix 3 bugs in the BTS (including this one), > but the problem preventing orpie from reentering testing is unreleated. I'm about to upload 1.6.0. Just packaged it but it has a completely different build system based on dune and opam which I'm not so familiar with. It's building now and piuparts doesn't complain but it still needs some tuning. Uwe -- MMK GmbH, Fleyer Str. 196, 58097 Hagen uwe.steinm...@mmk-hagen.de Tel: 02331 840446Fax: 02331 843920 signature.asc Description: PGP signature
Bug#945477: Just forge my previos post about librecad
Package: librecad I sent a bug report stating that root owned /usr/share/librecad/library is unusable, but I just was not using it right. I apologies! Arto Keiski
Bug#945402: [Pkg-phototools-devel] Bug#945402: feh: Please add dcraw to the Suggests (or even Recommends) of the package
Control: tags -1 +moreinfo Hi Elena, On Sun, Nov 24, 2019 at 12:27 PM Elena ``of Valhalla'' wrote: > Up to buster, feh was able to open (a preview of) the raw files > generated by my camera (Canon EOS 1100D); after upgrading to bullseye it > fails with the following error:: > > OJPEGDecodeRaw: Inconsistent number of MCU in codestream. > feh WARNING: 20171230/141140-img_5195.cr2 - No Imlib2 loader for that > file format I think it was a regression due to an other package. Can you please do a full upgrade of your Bullseye installation and re-test your image with feh? Maybe share that file in private somehow? > However, after a number of attempts, reading the manpage I noticed that > there is a better way to show raw files in feh, by using dcraw. > > I think that having dcraw available in the Suggests of the package would > have helped me find this option much earlier, as that's the first thing > I checked, to see if I was missing some optional dependency. I think it should go to Suggests. I use Recommends if that extends the package in some way. Regards, Laszlo/GCS
Bug#945476: librecad: part library in root owned /usr/share/librecd/library unusable
Package: librecad Version: 2.1.3-1.2 Severity: important -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi_FI.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 librecad depends on: ii libc62.28-10 ii libgcc1 1:8.3.0-6 ii libgl1 1.1.0-1 ii libmuparser2v5 2.2.6.1+dfsg-1 ii libqt5core5a 5.11.3+dfsg1-1+deb10u1 ii libqt5gui5 5.11.3+dfsg1-1+deb10u1 ii libqt5printsupport5 5.11.3+dfsg1-1+deb10u1 ii libqt5svg5 5.11.3-2 ii libqt5widgets5 5.11.3+dfsg1-1+deb10u1 ii librecad-data2.1.3-1.2 ii libstdc++6 8.3.0-6 librecad recommends no packages. librecad suggests no packages. -- no debconf information
Bug#945460: ITP: python-lunardate -- Chinese Calendar Library in Pure Python
Hi Michael, 在 2019-11-25一的 10:22 +0100，Michael Fladischer写道： > Package: wnpp > Severity: wishlist > Owner: Michael Fladischer > > * Package name: python-lunardate > Version : 0.2.0 > Upstream Author : LI Daobing > * URL : https://github.com/lidaobing/python-lunardate/ > * License : GPL-3 > Programming Lang: Python > Description : Chinese Calendar Library in Pure Python > > This library performs date conversion between the Gregorian Solar Calendar > (SC) > and the Chinese Lunar Calendar (LC). Given a date in either calendar, it > also > outputs the corresponding "shengxiao" animal of the year) and "ganzhi" > characters. The date range currently covered is from about 1900 A.D. to > 2049 > A.D. > > I intend to maintain this as part of the DPMT as a prerequisite for a future > workalendar package. Thanks for your interest in packaging a lunar-date-related package. There were several packages in Debian around lunar date, like [1], [2] and [3]; however their upstream are all inactive now. Since the upstream of this python-lunardate was a Debian Developer (in CC list) and that this package is Chinese-related, I am suggesting to add Debian Chinese Team ( https://qa.debian.org/developer.php?email=chinese-developers%40lists.alioth.debian.org ) into the uploaders list so that co-maintenance could be achieved. Please let me know whether that works for you. [1] https://tracker.debian.org/pkg/lunar-date [2] https://tracker.debian.org/pkg/lunar [2] https://tracker.debian.org/pkg/liblunar -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#914967: linux-image-4.18.0-3-amd64: errors "Failed to get unique processor _UID"
Hi Vincent, On Fri, Nov 15, 2019 at 01:43:07PM +0100, Vincent Lefevre wrote: > Control: found -1 4.19.67-2+deb10u2 > > On 2018-11-29 09:21:31 +0100, Vincent Lefevre wrote: > > I get the following errors at boot time: > > > > Nov 29 09:04:20 cventin kernel: acpi LNXCPU:06: Failed to get unique > > processor _UID (0xff) > > Nov 29 09:04:20 cventin kernel: acpi LNXCPU:07: Failed to get unique > > processor _UID (0xff) > > Nov 29 09:04:20 cventin kernel: acpi LNXCPU:08: Failed to get unique > > processor _UID (0xff) > > Nov 29 09:04:20 cventin kernel: acpi LNXCPU:09: Failed to get unique > > processor _UID (0xff) > > Nov 29 09:04:20 cventin kernel: acpi LNXCPU:0a: Failed to get unique > > processor _UID (0xff) > > Nov 29 09:04:20 cventin kernel: acpi LNXCPU:0b: Failed to get unique > > processor _UID (0xff) > > Nov 29 09:04:20 cventin kernel: acpi LNXCPU:0c: Failed to get unique > > processor _UID (0xff) > > [...] > > Nov 29 09:04:21 cventin kernel: acpi LNXCPU:8f: Failed to get unique > > processor _UID (0xff) > > > > There were no such errors before linux-image-4.18.0-3-amd64. > > Still occurs in the Debian/stable kernel. Looking through some of opened bugs for src:linux noticed yours for #914967. This might actually not be a kernel issue, from [1]. [1] https://bugzilla.kernel.org/show_bug.cgi?id=203925 Regards, Salvatore
Bug#936313: [PATCH 1/3] Port to python3
Antonio, this package is orphaned - just go ahead and do a QA upload for it :)
On Mon, Nov 25, 2019 at 10:27 AM Antonio Terceiro wrote:
>
> ---
> cmdtest | 2 +-
> setup.py| 8
> yarn| 20 +---
> yarnlib/mdparser.py | 11 +--
> 4 files changed, 19 insertions(+), 22 deletions(-)
>
> diff --git a/cmdtest b/cmdtest
> index 1d60900..5a3f445 100755
> --- a/cmdtest
> +++ b/cmdtest
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env python
> +#!/usr/bin/env python3
> # Copyright 2011 Lars Wirzenius
> #
> # This program is free software: you can redistribute it and/or modify
> diff --git a/setup.py b/setup.py
> index 9ba00a2..1c11194 100644
> --- a/setup.py
> +++ b/setup.py
> @@ -1,4 +1,4 @@
> -#!/usr/bin/python
> +#!/usr/bin/python3
> # Copyright (C) 2011 Lars Wirzenius
> #
> # This program is free software; you can redistribute it and/or modify
> @@ -43,13 +43,13 @@ class GenerateManpage(build):
>
> def run(self):
> build.run(self)
> -print 'building manpages'
> +print('building manpages')
> cmds = ['cmdtest']
> if markdown_version:
> cmds.append('yarn')
> for x in cmds:
> with open('%s.1' % x, 'w') as f:
> -subprocess.check_call(['python', x,
> +subprocess.check_call(['python3', x,
> '--generate-manpage=%s.1.in' % x,
> '--output=%s.1' % x], stdout=f)
>
> @@ -76,7 +76,7 @@ class Check(Command):
> def run(self):
> if markdown_version:
> subprocess.check_call(
> -['python', '-m', 'CoverageTestRunner',
> +['python3', '-m', 'CoverageTestRunner',
> '--ignore-missing-from', 'without-tests'])
> if os.path.exists('.coverage'):
> os.remove('.coverage')
> diff --git a/yarn b/yarn
> index d67c115..ca2035f 100755
> --- a/yarn
> +++ b/yarn
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env python
> +#!/usr/bin/env python3
> # Copyright 2013 Lars Wirzenius
> #
> # This program is free software: you can redistribute it and/or modify
> @@ -116,8 +116,6 @@ class YarnRunner(cliapp.Application):
> self._write(sys.stderr, msg)
>
> def _write(self, output, msg):
> -if isinstance(msg, unicode):
> -msg = msg.encode(locale.getpreferredencoding())
> output.write(msg)
> output.flush()
>
> @@ -332,7 +330,7 @@ class YarnRunner(cliapp.Application):
> started = time.time()
>
> self.info(0, 'Running scenario %s' % scenario.name)
> -self.ts['scenario_name'] = scenario.name.encode('utf-8')
> +self.ts['scenario_name'] = scenario.name
> self.ts.flush()
> self.scenarios_run += 1
>
> @@ -450,7 +448,7 @@ class YarnRunner(cliapp.Application):
>
> self.info(1, 'Running step "%s %s"' % (step.what, step.text))
> self.ts['current_step'] = step
> -self.ts['step_name'] = '%s %s' % (step.what,
> step.text.encode('utf8'))
> +self.ts['step_name'] = '%s %s' % (step.what, step.text)
> self.ts.flush()
> self.steps_run += 1
>
> @@ -461,7 +459,7 @@ class YarnRunner(cliapp.Application):
> env['SRCDIR'] = os.getcwd()
> env['HOME'] = self.homedir(datadir)
> for i, match in enumerate(m.groups('')):
> -env['MATCH_%d' % (i+1)] = match.encode('utf-8')
> +env['MATCH_%d' % (i+1)] = match
> self.add_srcdir_to_pythonpath(env, env['SRCDIR'])
>
> if self.settings['cd-datadir']:
> @@ -487,11 +485,11 @@ class YarnRunner(cliapp.Application):
>
> logging.debug('Exit code: %d' % exit)
> if stdout:
> -logging.debug('Standard output:\n%s' % self.indent(stdout))
> +logging.debug('Standard output:\n%s' %
> self.indent(stdout.decode()))
> else:
> logging.debug('Standard output: empty')
> if stderr:
> -logging.debug('Standard error:\n%s' % self.indent(stderr))
> +logging.debug('Standard error:\n%s' %
> self.indent(stderr.decode()))
> else:
> logging.debug('Standard error: empty')
>
> @@ -500,9 +498,9 @@ class YarnRunner(cliapp.Application):
> self.error('step "%s %s" failed,' % (step.what, step.text))
> self.error('with exit code %d:' % exit)
> self.error('Standard output from shell command:\n%s' %
> - self.indent(stdout))
> + self.indent(stdout.decode()))
> self.error('Standard error from shell command:\n%s' %
> - self.indent(stderr))
> + self.indent(stderr.decode()))
>
> self.remember_step_timing(
> '%s %s' % (step.what, step.text), time.time() - started)
> @@ -541,7 +539,7 @@ class YarnRunner(cliapp.Application):
>
Bug#945475: the autopkgtests fail due to a deprecation warning on stderr
Le 25/11/2019 à 16:53, Samuel Thibault a écrit : > They happen to be compatible, so there is no strict versioning > dependency needed. > > Samuel Ok, fair enough, it does sounds like an infrastructure limitation to not be smart enough to figure what packages needs to be updated. Sorry for the noise and thanks for the replies!
Bug#945475: the autopkgtests fail due to a deprecation warning on stderr
Sebastien Bacher, le lun. 25 nov. 2019 16:50:57 +0100, a ecrit: > Le 25/11/2019 à 16:46, Samuel Thibault a écrit : > > Get:1 http://ftpmaster.internal/ubuntu focal/main amd64 liblouis-data all > > 3.10.0-1 [1672 kB] > > Get:2 http://ftpmaster.internal/ubuntu focal-proposed/main amd64 liblouis19 > > amd64 3.11.0-2 [70.6 kB] > > > > This CI run is using a recent version of liblouis19 with an old version > > of liblouis-data. Such warnings are then not surprising, it's the CI run > > which needs to use coherent versions. > > > > It does not happen in Debian, thus closing. > > Shouldn't liblouis19 ensure that a matching version of -data is > installed though? They happen to be compatible, so there is no strict versioning dependency needed. Samuel
Bug#939929: terminator: crash when trying to start
Got it: it comes from the accent in my terminator profile name "Présentation". I rewrote it as "Presentation" and it all works… Thanks for the tip! On Thu, 14 Nov 2019 13:06:36 +0100 Egmont Koblinger wrote: > Hi, > > Could you please share your terminator config file > (/home/benoit/.config/terminator/config)? > > If you move that file away, does terminator 1.91-4 start up? > > thanks, > e. > >
