Bug#972079: cyrus-imapd: Seen/Unseen Flag not working correctly if sharedseen of a shared mailbox is not set to true
Hi, to help us to resolve this issue, could you take a look at this comment? https://github.com/cyrusimap/cyrus-imapd/issues/3240#issuecomment-877913241 Cheers, Yadd
Bug#989553: imapd: bullsey regression: unable to get certificate CRL
Hi Juergen, could you take a look at https://github.com/cyrusimap/cyrus-imapd/issues/3545 ? Cheers, Yadd
Bug#989229: grub-install: warning: Cannot read EFI Boot* variables.
id_sensor_hub i915 hid_generic mmc_block crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel i2c_algo_bit drm_kms_helper cec drm ahci xhci_pci sdhci_pci xhci_hcd libahci [Sun Jul 11 20:36:36 2021] aesni_intel cqhci sdhci usbcore libaes crypto_simd libata cryptd glue_helper mmc_core scsi_mod i2c_i801 i2c_smbus lpc_ich intel_lpss_pci intel_lpss idma64 usb_common i2c_hid hid fan button battery wmi video [Sun Jul 11 20:36:36 2021] CPU: 0 PID: 66728 Comm: kworker/u8:10 Not tainted 5.10.0-6-amd64 #1 Debian 5.10.28-1 [Sun Jul 11 20:36:36 2021] Hardware name: Acer Spin SP111-31N/Ironhide_AP, BIOS V1.02 01/04/2017 [Sun Jul 11 20:36:36 2021] Workqueue: efi_rts_wq efi_call_rts [Sun Jul 11 20:36:36 2021] RIP: 0010:efi_recover_from_page_fault+0x2a/0xc0 [Sun Jul 11 20:36:36 2021] Code: 0f 1f 44 00 00 8b 15 65 77 f7 01 85 d2 74 09 48 81 ff ff 0f 00 00 77 01 c3 53 48 89 fe 48 c7 c7 60 ca 8c b0 50 e8 e9 b0 7f 00 <0f> 0b 83 3d 3d 77 f7 01 0a 0f 84 13 ac 7f 00 48 8b 3d 18 bb e5 01 [Sun Jul 11 20:36:36 2021] RSP: 0018:abf1c1703b50 EFLAGS: 00010082 [Sun Jul 11 20:36:36 2021] RAX: RBX: 93b4eb6b8000 RCX: 93b53bc18a08 [Sun Jul 11 20:36:36 2021] RDX: ffd8 RSI: 0027 RDI: 93b53bc18a00 [Sun Jul 11 20:36:36 2021] RBP: abf1c1703bf8 R08: R09: abf1c1703970 [Sun Jul 11 20:36:36 2021] R10: abf1c1703968 R11: b0ecb368 R12: 66cd61d0 [Sun Jul 11 20:36:36 2021] R13: R14: 000b R15: 0001 [Sun Jul 11 20:36:36 2021] FS: () GS:93b53bc0() knlGS: [Sun Jul 11 20:36:36 2021] CS: 0010 DS: ES: CR0: 80050033 [Sun Jul 11 20:36:36 2021] CR2: 66cd61d0 CR3: 0001001a4000 CR4: 003506f0 [Sun Jul 11 20:36:36 2021] Call Trace: [Sun Jul 11 20:36:36 2021] no_context+0x16a/0x3a0 [Sun Jul 11 20:36:36 2021] exc_page_fault+0x7b/0x160 [Sun Jul 11 20:36:36 2021] asm_exc_page_fault+0x1e/0x30 [Sun Jul 11 20:36:36 2021] RIP: 0010:0xfffefb04fd44 [Sun Jul 11 20:36:36 2021] Code: d1 b9 04 00 00 00 e9 b7 ff ff ff cc cc cc 48 8b 05 f9 4a 00 00 48 ff 60 30 cc 48 83 ec 28 48 8b 05 e9 4a 00 00 4c 8d 44 24 40 50 40 48 8b 4c 24 40 33 d2 48 85 c0 48 0f 48 ca 48 8b c1 48 83 [Sun Jul 11 20:36:36 2021] RSP: 0018:abf1c1703ca0 EFLAGS: 00010086 [Sun Jul 11 20:36:36 2021] RAX: 66cd6190 RBX: 0002 RCX: 0004 [Sun Jul 11 20:36:36 2021] RDX: 0002 RSI: RDI: 0002 [Sun Jul 11 20:36:36 2021] RBP: abf1c1703d70 R08: abf1c1703ce0 R09: abf1c1703dd0 [Sun Jul 11 20:36:36 2021] R10: R11: 0018 R12: [Sun Jul 11 20:36:36 2021] R13: 00083fb0 R14: abf1c1703dd0 R15: abf1c1703dd8 [Sun Jul 11 20:36:36 2021] ? __clear_extent_bit+0x232/0x4a0 [btrfs] [Sun Jul 11 20:36:36 2021] ? endio_readpage_release_extent+0x52/0xb0 [btrfs] [Sun Jul 11 20:36:36 2021] ? psi_group_change+0x41/0x210 [Sun Jul 11 20:36:36 2021] ? __efi_call+0x28/0x30 [Sun Jul 11 20:36:36 2021] ? __schedule+0x28a/0x870 [Sun Jul 11 20:36:36 2021] ? efi_call_rts+0x424/0x760 [Sun Jul 11 20:36:36 2021] ? __schedule+0x28a/0x870 [Sun Jul 11 20:36:36 2021] ? process_one_work+0x1b6/0x350 [Sun Jul 11 20:36:36 2021] ? worker_thread+0x53/0x3e0 [Sun Jul 11 20:36:36 2021] ? process_one_work+0x350/0x350 [Sun Jul 11 20:36:36 2021] ? kthread+0x11b/0x140 [Sun Jul 11 20:36:36 2021] ? __kthread_bind_mask+0x60/0x60 [Sun Jul 11 20:36:36 2021] ? ret_from_fork+0x22/0x30 [Sun Jul 11 20:36:36 2021] ---[ end trace b7e2b9ad057169a2 ]--- [Sun Jul 11 20:36:36 2021] efi: Froze efi_rts_wq and disabled EFI Runtime Services [Sun Jul 11 20:36:36 2021] efi: EFI Runtime Services are disabled! [Sun Jul 11 20:36:42 2021] efi: EFI Runtime Services are disabled! The output from the other commands is fairly long, so I've left copies at the links below, but I assume they couldn't possibly run correctly as the kernel has disabled efi: # strace -f -s 1024 grub-install --target=x86_64-efi https://www.maher.org.uk/~joseph/20210711-strace-grub-install.log # strace -f -s 1024 efibootmgr https://www.maher.org.uk/~joseph/20210711-strace-efibootmgr.log Thanks! Joseph
Bug#990976: unblock: raspi-firmware/1.20210303+ds-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please allow version 1.20210303+ds-2 of raspi-firmware into
testing. This is a minor version, adding a config option that avoids
setting the GPU_FREQ for a fixed GPU speed, which works around a bug
in the RPi4 family that changes the baud rate for the serial interface
rendering it useless. Some other much minor changes are included as
well.
As you will see when reviewing this bug, I should have filed this
request about two months ago. I completely forgot about it... shame on
me! Thanks to Adrian Bunk for reminding me.
The impact of not having this change accepted in Bullseye is not being
able to use a serial console on the current top of the line Raspberry
lineup.
I don't have automated tests in place for this package; as it's
basically a firmware blob needed to boot the system, the main test is
whether it boots and *seems* to work correctly (it does!) or not.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock raspi-firmware/1.20210303+ds-2
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index c3c54ff..a2dee16 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+raspi-firmware (1.20210303+ds-2) unstable; urgency=medium
+
+ * Add a header to config.txt warning users it's an autogenerated file
+(Closes: #983896)
+ * Added config option GPU_FREQ to allow specifying a fixed GPU speed,
+needed for using the serial console in the RPi4 family
+ * ignore *.old-dkms when configuring a new kernel/initrd (Closes:
+#983409)
+ * Applied some shellcheck fixes to improve clarity. Thanks Diederik!
+
+ -- Gunnar Wolf Wed, 21 Apr 2021 00:52:21 -0500
+
raspi-firmware (1.20210303+ds-1) unstable; urgency=medium
* New upstream release
diff --git a/debian/default/raspi-firmware b/debian/default/raspi-firmware
index e8e83bc..3e9d9cd 100644
--- a/debian/default/raspi-firmware
+++ b/debian/default/raspi-firmware
@@ -67,6 +67,25 @@
#
#CONSOLES="auto"
+# In the RPi4 and p400 families, the video processor (GPU) has several
+# possible operating frequencies, but is known to corrupt the serial
+# console (switch to an invalid baud rate), as the UART (the component
+# which drives the serial ports) gets its clock from the GPU, as
+# explained here:
+#
+# https://www.raspberrypi.org/documentation/configuration/uart.md
+#
+# The clock speeds the RPi4 GPU uses are 360/500/550 MHz. If you
+# intend to use the serial console, you need to set GPU_FREQ to
+# 360. If you intend to use this computer as a desktop system, set it
+# to "auto". Both 500 and 550 MHz also corrupt the serial console.
+#
+# Do note that earlier models have fixed frequencies, and this setting
+# will be ignored if your board does not identify as a RPi 4 (any
+# model) or p400.
+#
+#GPU_FREQ="auto"
+
# Force the architecture to install the kernel as. You will most
# likely want to leave this setting alone; the only use case I have
# found for this is when you want to run a 32-bit userland on a
diff --git a/debian/kernel/postinst.d/z50-raspi-firmware
b/debian/kernel/postinst.d/z50-raspi-firmware
index 09b882f..1cb1334 100755
--- a/debian/kernel/postinst.d/z50-raspi-firmware
+++ b/debian/kernel/postinst.d/z50-raspi-firmware
@@ -1,7 +1,7 @@
#!/bin/sh
# vim:ts=2:sw=2:et
# see also:
-# https://kernel-handbook.alioth.debian.org/ch-update-hooks.html#s-kernel-hooks
+#
https://kernel-team.pages.debian.net/kernel-handbook/ch-update-hooks.html#s-kernel-hooks
set -e
@@ -31,13 +31,15 @@ fi
# Ensure the target directory exists. See https://bugs.debian.org/887062
mkdir -p /boot/firmware
-latest_kernel=$(ls -1 /boot/vmlinuz-* | grep -v '\.dpkg-bak$' | sort -V -r |
head -1)
+# shellcheck disable=SC2010
+latest_kernel=$(ls -1 /boot/vmlinuz-* | grep -E -v '\.(dpkg-bak|old-dkms)$' |
sort -V -r | head -1)
if [ -z "$latest_kernel" ]; then
echo "raspi-firmware: no kernel found in /boot/vmlinuz-*, cannot populate
/boot/firmware"
exit 0
fi
-latest_initrd=$(ls -1 /boot/initrd.img-* | grep -v '\.dpkg-bak$' | sort -V -r
| head -1)
+# shellcheck disable=SC2010
+latest_initrd=$(ls -1 /boot/initrd.img-* | grep -E -v '\.(dpkg-bak|old-dkms)$'
| sort -V -r | head -1)
if [ -z "$latest_initrd" ]; then
echo "raspi-firmware: no initrd found in /boot/initrd.img-*, cannot populate
/boot/firmware"
exit 0
@@ -76,7 +78,7 @@ else
fi
if [ "$KERNEL" = "auto" ]; then
- for dtb in ${dtb_path}/bcm*.dtb; do
+ for dtb in
Bug#990853: Problem with Directory directive
Hi, but it's curious, that 2 weeks earlier it run's like I expected; I could enable Auth through a Directory directive on special folders and all of it's content. The problem with is, that I can not except single files with Satisfy any Aktuelles finden Sie auch auf https://www.olb.de und https://www.facebook.com/olb.bank Oldenburgische Landesbank AG Vorsitzender des Aufsichtsrates: Axel Bartsch Vorstand: Dr. Wolfgang Klein, Vorsitzender; Stefan Barth, stellv. Vorsitzender; Marc Ampaw; Peter Karst; Karin Katerbau; Dr. Rainer Polster Sitz der Gesellschaft und Registergericht: Oldenburg (Oldb), HR-Nummer: HRB 3003 >> Other problems I had after that update: I had to enable some modules via >> a2enmod. 3 weeks earlier the modules were automatically enabled and the >> AuthType works for the whole directory >Could you give more details ? 2 weeks earlier, I just build my image with From: ... debian:buster Run apt-get install -y \ apache2 \ apache2-utils \ libapache2-mod-auth-gssapi \ libapache2-mod-authnz-external \ libapache2-mod-fcgid Now I had to add run a2enmod session_cookie \ && a2enmod rewrite \ && a2enmod include to get it to work I just mentioned the problem with a2enmod as I thought there was a bigger change in apache2. My only real problem is to enable Auth only on some Directories. thanks smime.p7s Description: S/MIME cryptographic signature
Bug#990872: puppetdb.jar crashes out of the box with clojure classpath error
On Sat, 10 Jul 2021 14:08:00 -0400 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?= wrote: > On Fri, 09 Jul 2021 23:14:22 -0700 "Gabriel G. Rosa" > wrote: > > Package: puppetdb > > Version: 6.2.0-5 > > Severity: grave > > Justification: renders package unusable > > > > Dear Maintainer, > > > > When installing puppetdb and configuring it to listen on http port, the > > puppetdb.jar crashes with the following lines in syslog: > > > > Jul 9 23:01:46 puppet java[25194]: Syntax error (FileNotFoundException) > > compiling at (clojure/core/async/impl/ioc_macros.clj:1:1). > > Jul 9 23:01:46 puppet java[25194]: Could not locate > > clojure/tools/analyzer__init.class, clojure/tools/analyzer.clj or > > clojure/tools/analyzer.cljc on classpath. > > Jul 9 23:01:46 puppet java[25194]: Full report at: > > Jul 9 23:01:46 puppet java[25194]: /tmp/clojure-1064777479875377538.edn > > I've seen that error elsewhere while running clojure testsuites for > packages depending on libcore-async-clojure [1] and never got to debug it... > > I've just re-built libcore-async-clojure and libtools-analyzer-clojure > locally and their full testsuites passes though. > > I've also checked, and libtools-analyzer-clojure does ship the right jar > files: > > usr/ > └── share > ├── doc > │ └── libtools-analyzer-clojure > │ ├── changelog.Debian.gz > │ ├── changelog.gz > │ ├── CONTRIBUTING.md > │ ├── copyright > │ └── README.md.gz > ├── java > │ ├── tools.analyzer-1.0.0.jar > │ └── tools.analyzer.jar -> tools.analyzer-1.0.0.jar > └── maven-repo > └── org > └── clojure > └── tools.analyzer > ├── 1.0.0 > │ ├── tools.analyzer-1.0.0.jar > │ └── tools.analyzer-1.0.0.pom > └── debian > ├── tools.analyzer-debian.jar -> > ../1.0.0/tools.analyzer-1.0.0.jar > └── tools.analyzer-debian.pom > > Those jars do contain the right clojure files too... > > clojure/ > └── tools > ├── analyzer > │ ├── ast > │ │ └── query.clj > │ ├── ast.clj > │ ├── env.clj > │ ├── passes So if I include a few extra jars in the command line, it gets me a little further: grosa@puppet:~$ sudo /usr/bin/java -Xmx192m -Djava.security.egd=/dev/urandom -XX:OnOutOfMemoryError="kill -9 %p" -cp /usr/share/puppetdb/puppetdb.jar:/usr/share/java/tools.analyzer.jar:/usr/share/java/tools.analyzer.jvm.jar clojure.main -m puppetlabs.puppetdb.core services --config /etc/puppetdb/conf.d --bootstrap-config /etc/puppetdb/bootstrap.cfg --restart-file /run/puppetdb/restart Syntax error (ClassNotFoundException) compiling . at (puppetlabs/http/client/async.clj:60:5). org.apache.http.nio.protocol.HttpAsyncResponseConsumer Full report at: /tmp/clojure-11985391683440035019.edn clojure-11985391683440035019.edn Description: Binary data But still not at a working puppetdb http listener… Sorry I am fumbling in the dark a bit — I am not at all familiar with java and clojure. Should I be filing a bug report against a different package? Thanks, -G
Bug#990975: wtype: Fails with, "Compositor does not support the virtual keyboard protocol"
Package: wtype Version: 0.3-1 Severity: important X-Debbugs-Cc: chandru...@gmail.com Dear Maintainer, Running `wtype foo` fails with the error, "Compositor does not support the virtual keyboard protocol". I have verified that I am on Wayland. $ echo $XDG_SESSION_TYPE wayland -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wtype depends on: ii libc6 2.31-13 ii libwayland-client0 1.19.0-2 ii libxkbcommon0 1.0.3-2 wtype recommends no packages. wtype suggests no packages. -- no debconf information
Bug#990974: ds2490: Driver seems broken (worked in 4.19.0)
Package: src:linux Version: 5.10.40-1 Severity: normal Driver ds2490 For Dallas 1-wire bus driver DS9490R seems broken. No devices on 1-wire bus are detected and reading most files from /sys/bus/w1/drivers/w1_master_driver/w1_bus_master1 causes process to hang in uninterruptible wait. The same hardware and driver works without any problems in Buster with Linux kernel version 4.19.67. -- Package-specific info: ** Version: Linux version 5.10.0-7-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.40-1 (2021-05-28) ** Command line: BOOT_IMAGE=/vmlinuz-5.10.0-7-amd64 root=/dev/dm-0 rootfstype=btrfs rootflags=subvol=root,noatime,ssd cryptopts=source=/dev/sda2,target=sda2,cipher=aes-xts-plain64,size=256,hash=sha256,discard ** Tainted: E (8192) * unsigned module was loaded ** Kernel log: [0.00] Linux version 5.10.0-7-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.40-1 (2021-05-28) [0.00] Command line: BOOT_IMAGE=/vmlinuz-5.10.0-7-amd64 root=/dev/dm-0 rootfstype=btrfs rootflags=subvol=root,noatime,ssd cryptopts=source=/dev/sda2,target=sda2,cipher=aes-xts-plain64,size=256,hash=sha256,discard [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xc5cc] usable [0.00] BIOS-e820: [mem 0xc5cd-0xc5cd6fff] ACPI NVS [0.00] BIOS-e820: [mem 0xc5cd7000-0xd9a80fff] usable [0.00] BIOS-e820: [mem 0xd9a81000-0xd9b19fff] reserved [0.00] BIOS-e820: [mem 0xd9b1a000-0xd9b33fff] ACPI data [0.00] BIOS-e820: [mem 0xd9b34000-0xd9c8efff] ACPI NVS [0.00] BIOS-e820: [mem 0xd9c8f000-0xd9ffefff] reserved [0.00] BIOS-e820: [mem 0xd9fff000-0xd9ff] usable [0.00] BIOS-e820: [mem 0xdb00-0xdf1f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00021fdf] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.8 present. [0.00] DMI: /D34010WYK, BIOS WYLPT10H.86A.0040.2015.0612.1400 06/12/2015 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 1696.038 MHz processor [0.001001] e820: update [mem 0x-0x0fff] usable ==> reserved [0.001006] e820: remove [mem 0x000a-0x000f] usable [0.001015] last_pfn = 0x21fe00 max_arch_pfn = 0x4 [0.001021] MTRR default type: uncachable [0.001022] MTRR fixed ranges enabled: [0.001024] 0-9 write-back [0.001025] A-B uncachable [0.001027] C-C write-protect [0.001028] D-E7FFF uncachable [0.001029] E8000-F write-protect [0.001030] MTRR variable ranges enabled: [0.001032] 0 base 00 mask 7E write-back [0.001034] 1 base 02 mask 7FE000 write-back [0.001036] 2 base 00E000 mask 7FE000 uncachable [0.001037] 3 base 00DC00 mask 7FFC00 uncachable [0.001038] 4 base 00DB00 mask 7FFF00 uncachable [0.001040] 5 base 021FE0 mask 7FFFE0 uncachable [0.001041] 6 disabled [0.001042] 7 disabled [0.001042] 8 disabled [0.001043] 9 disabled [0.001450] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.002111] e820: update [mem 0xdb00-0x] usable ==> reserved [0.002117] last_pfn = 0xda000 max_arch_pfn = 0x4 [0.013927] found SMP MP-table at [mem 0x000fd770-0x000fd77f] [0.020447] Using GB pages for direct mapping [0.021173] RAMDISK: [mem 0x34698000-0x36343fff] [0.021177] ACPI: Early table checksum verification
Bug#924581: lintian: license-problem-gfdl-invariants false positive
Hi guys, This bug also affects png-definitive-guide. The license text says (from copyright.html): Permission is granted to copy, distribute, and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Lintian says: E: png-definitive-guide source: license-problem-gfdl-invariants copyright.html invariant part is: with no invariant sections, e-mail from laurie petrycki, 20030726: no front-cover texts, and no back-cover texts. end (yes, the litian message has an e-mail and ends with "end"). Regards, Eriberto
Bug#990867: shim-helpers-arm64-signed: post-install script fails with 'error exit status 1'
On Sun, 11 Jul 2021 01:31:19 +0100 Steve McIntyre
wrote:
> On Sat, Jul 10, 2021 at 01:48:53AM +0200, Diederik de Haas wrote:
[...]
> 1. To stop your machine failing here, do a "dpkg-reconfigure
> grub-efi-arm64" and say "yes" to the removable media path question
> and "no" to the "update boot variables" question. That should
> solve the immediate problem for you - please shout if it doesn't!
>
> Fixing this in the *general* case is hard. We could add code to
> fall back to *not* updating UEFI boot variables if that fails, but
> that's likely going to be error-prone and cause trouble on
> machines where that *should* work but it fails on a temporary
> basis. Instead, I suspect we may need to replicate similar
> functionality to flash-kernel and have a list of "quirky" machines
> where we *don't* expect UEFI boot variables to work. That's messy
> as all hell, but I'm not sure of a better option. :-/
Should this just do a quick test in the postinst to test that efivarfs
is mounted r/w? Something quick like:
db_get grub2/update_nvram || RET=true
if [ "$RET" = false ]; then
OPTIONS="$OPTIONS --no-nvram"
elif [ ! -w /sys/firmware/efi/efivars/ ]; then
echo "WARNING: can't write to /sys/firmware/efi/efivars/, your
system may not be bootable" >&2
OPTIONS="$OPTIONS --no-nvram"
fi
Perhaps a more informative error message, though...
Also, grub-efi-arm64's postinst runs grub-install the following way, and
I feel like the shim stuff could do the same?
run_grub_install()
{
if ! grub-install $@ ; then
echo "Failed: grub-install $@" >&2
echo "WARNING: Bootloader is not properly installed, system may not be
bootable" >&2
fi
}
>
> 2. To the best of my knowledge, none of the current U-Boot releases
> support Secure Boot so you may as well remove the shim-signed
> package anyway. It's normally harmless to include it (so we pull
> it in via recommends), but on your system it's not going to do
> anything for you so you may as well remove it.
Worth pointing out that it can't be removed unless one does the
dpkg-reconfigure trick above! :)
The following packages will be REMOVED:
mokutil* shim-helpers-arm64-signed* shim-signed* shim-signed-common*
shim-unsigned*
0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 3,674 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 23499 files and directories currently installed.)
Removing shim-signed:arm64 (1.37+15.4-6) ...
Installing for arm64-efi platform.
grub-install: warning: Cannot set EFI variable Boot.
grub-install: warning: efivarfs_set_variable: failed to create
/sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c
for writing: Read-only file system.
grub-install: warning: _efi_set_variable_mode: ops->set_variable()
failed: Read-only file system.
grub-install: error: failed to register the EFI boot entry: Read-only
file system.
dpkg: error processing package shim-signed:arm64 (--remove):
installed shim-signed:arm64 package post-removal script subprocess
returned error exit status 1
Bug#801951: debian/copyright should mention BSD3 license, not PSF
Am 11.07.21 um 01:28 schrieb Colin Watson: Thanks for committing a fix for this to git. Do you need sponsorship help to upload this (if so, I'd be happy to do it), or is an upload already in progress? The change needs sponsorship. It is in the Python Team's RFS queue, so please go ahead.
Bug#988905:
I see there is a fix in the git repo now. Are you planning an upload any time soon, or only after the buster release?
Bug#990966: grub-efi-arm64: breaks upgrades when the efivarfs is mounted read-only
Note: I misspoke in my original report; both boards are rock64 boards, there's no pi4 board involved here (it doesn't use EFI). On Sun, 11 Jul 2021 23:21:56 +0100 Steve McIntyre wrote: > > >Here's the relevant field in /proc/mounts: > >efivarfs /sys/firmware/efi/efivars efivarfs > >ro,nosuid,nodev,noexec,relatime 0 0 > > > >I expect that the reason /sys/firmware/efi/efivars is mounted > >read-only is due to bug reports such as the following: > >https://github.com/systemd/systemd/issues/2402 > > But that was never agreed. I'm genuinely curious why you have efivarfs > mounted read-only, and I don't think it's a supported/supportable > option here. > I did not manually set it this way; the boards were installed via debootstrap/vmdb2 methods with stock bullseye. I had assumed that this was the default in debian, but it would appear that the kernel itself doesn't allow mounting it rw: dilinger@wifi2:/usr/lib/systemd$ sudo umount /sys/firmware/efi/efivars dilinger@wifi2:/usr/lib/systemd$ sudo mount -t efivarfs none /sys/firmware/efi/efivars -o rw dilinger@wifi2:/usr/lib/systemd$ grep efivar /proc/mounts none /sys/firmware/efi/efivars efivarfs ro,relatime 0 0 > >It would be preferable for grub to either > >a) continue the package postinstall despite efivars being read-only, > >or b) remount efivars read-write, update efivars, and then remount > >ro. > > > >grub-install is being called from shim-helpers-arm64-signed's > >postinst. You could argue that shim-helpers-arm64-signed could > >remount efivars read-write, but since I can actually trigger the > >same error in grub-efi-arm64's postinst, it seems like this should be > >fixed in grub: > > The "issue" is definitely coming from grub-efi-$ARCH, but it's > behaving as designed here. Continuing despite failing to update the > EFI boot vars here will potentially leave you with an unbootable > system. > So yeah, basically given the above info; remounting is unnecessary. Instead, there needs to be a graceful way for grub-install or the shim packages to deal with an unwriteable efivarfs. I don't recall grub packages actually failing (just error messages to console), so we might just need the shim packages to gracefully fail.
Bug#990973: unblock: mksh/59c-9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: t...@mirbsd.de, Vincent Lefèvre Please unblock package mksh [ Reason ] This update is comprised of: • documentation update from upstream CVS HEAD, mostly related to the death of a certain IRC network (one FAQ entry related to changes that are already in 59c-8 also got in) • some more reliability checks (although I’m afraid the full C1 control character escaping changes won’t make bullseye, they’re still under development and rather invasive, so I only picked the small independent fixes): – check lower bounds of input line array when backspacing – protect against hi-bit7 (stty) EOF character – ensure macro calls don’t have side effects in arguments • properly flush stderr and unwind for direct builtin calls (“ln -s /bin/mksh echo; ./echo …”) so they behave the same as if called from within the shell (“/bin/mksh -c 'echo …'”) • fix truncation behaviour for internal snprintf equivalent (a sequence of putc+puts+putc could, before, drop the puts but allow the putc to succeed); this becomes important with the next change • show error message and exit nōn-zero on stdout write failure for builtin calls (Closes: #990265) ‣ there was quite a discussion around what parts are actually buggy-as-in-not-POSIX on the Austin Group (POSIX) mailing list, as there was no consensus between shell implementors, packagers and users; this implements (for all known cases) what the official response requires • display correct errno when doing so (before, one codepath could lose errno as it did another libc call in between) • show error message in echo/print builtin on output write failure (basically the same as the generic one except echo/print don’t write buffered to stdout, they write to any fd, and already exited 1 on write error but didn’t issue a diagnostic message in that case which the POSIX people seem to prefer) [ Impact ] The references to the dead IRC network stay in. Scenarios in which output is redirected to files on a full filesystem can’t be handled by shell scripts. Direct builtin calls can lose stderr messages. (The other fixes are for bugs I’ve not seen in production but aren’t untrue either.) [ Tests ] The stdout/error change has new tests in the regression test suite and has also been tested by the requestor and the concept was ACK’d on the Austin Group mailing list. All changes have been tested in MirBSD for a while (including rebuilding the full OS with them in play) and not triggered any problems. The changes (except documentation where I cp’d for some files) are all individual cherry-picks of the relevant commits, individually reviewed. I also tested the truncation one by temporarily adding debugging code during development, and all error handling-related ones also on Debian with /dev/full (which doesn’t exist on MirBSD). [ Risks ] As mentioned in the last unblock, mksh is effectively not key. These changes only affect specific things (the ones under “some more reliability checks” only the interactive line editor, for example) and thus are rather localised, mistakes easily spotted. Therefore I believe these are low risk (I specifically didn’t cherry-pick a few fixes that are of higher risk because of their interwovenness and intrusivity level; users will have to wait for the next release for these). I expect this to be the last upload before the release. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach diff against the package in testing [ Other info ] I’ve again attached a diff of the unpacked package instead of a debdiff because I use single-debian-patch and develop in VCS. I’ve commented the diff, so it’s easier to map the hunks to the changes listed. unblock mksh/59c-9
Bug#990972: coolmail 1.3-12 - sound plays distorted
Package: coolmail Version: 1.3-12 Severity: normal Using the available option to play a sound file istead of using the system beep as indicated in the /etc/X11/app-defaults/Coolmail file results in the application playing a highly distorted sound and not the intended *.au file. ie: --- coolmail.soundFile: /usr/local/bin/sounds/youvegotmail.au --- When run from a terminal with coolmail -v, the application wants to write to /dev/audio but complains about not being able to do it. --- ~$ coolmail -v Coolmail 1.3 watching file: /var/spool/mail/groucho Coolmail: Error writing to /dev/audio. ~$ --- The same file can be properly played by the aplay, VLC and Audacious applications so I think it is safe to conclude that there's not problem with the *.au file being used. My system has ALSA and the alsa-aoss package installed. Starting the application with aoss coolmail -v gets me the same (distorted audio/printout) results. Other texts I have seen online have only make reference to the *.au format, so it would seem that it is what the application expects. All the same, I tried with a *.wav file but got output saying that it is the wrong file format. Thanks in advance, JHM
Bug#990956: uploading lintian-brush to testing-proposed-updates
On Sun, Jul 11, 2021 at 09:58:30PM +0200, Paul Gevers wrote: > Hi Jelmer, > > On 11-07-2021 21:47, Jelmer Vernooij wrote: > > It's going to be tricky to get this resolved in time before the removal of > > lintian-brush from testing. > > Can you elaborate why it's tricky (not promising anything, but there > could be reasons for t-p-u)? The current autoremoval is scheduled for > August 8, which is *after* the tentative release date. There have been updates to the other packages that relate to lintian-brush - both dependencies (python-tr, debmutate, upstream-ontologist, buildlog-consultant) and reverse dependencies ((silver-platter); we'd have to either roll those back in unstable as well or instead patch lintian-brush with a set of changes to lintian-brush that isn't really a roll back. (I appreciate that some of those changes probably should have gone to experimental) > > Of the reverse dependencies, routine-update can > > hopefully be updated easily (I've already pinged Andreas) to skip > > lintian-brush > > and silver-platter should probably not make it into bullseye (I've just > > filed a > > removal request for it). > > I'll handle the removals. Thanks! Cheers, Jelmer signature.asc Description: PGP signature
Bug#990966: grub-efi-arm64: breaks upgrades when the efivarfs is mounted read-only
Control: severity -1 important Hey Andres, On Sun, Jul 11, 2021 at 04:19:19PM -0400, Andres Salomon wrote: >Package: grub-efi-arm64 >Version: 2.04-19 >Severity: serious > >I experienced the follow on multiple ARM64 systems (both a Rock64 >board and a Raspberry Pi 4b board) during an unattended-upgrades run: > >Unattended upgrade result: All upgrades installed > >Packages that attempted to upgrade: > shim-helpers-arm64-signed shim-signed shim-signed-common > shim-unsigned ... >Here's the relevant field in /proc/mounts: >efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec,relatime 0 0 > >I expect that the reason /sys/firmware/efi/efivars is mounted read-only is >due to bug reports such as the following: >https://github.com/systemd/systemd/issues/2402 But that was never agreed. I'm genuinely curious why you have efivarfs mounted read-only, and I don't think it's a supported/supportable option here. >It would be preferable for grub to either >a) continue the package postinstall despite efivars being read-only, or >b) remount efivars read-write, update efivars, and then remount ro. > >grub-install is being called from shim-helpers-arm64-signed's >postinst. You could argue that shim-helpers-arm64-signed could >remount efivars read-write, but since I can actually trigger the >same error in grub-efi-arm64's postinst, it seems like this should be >fixed in grub: The "issue" is definitely coming from grub-efi-$ARCH, but it's behaving as designed here. Continuing despite failing to update the EFI boot vars here will potentially leave you with an unbootable system. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Bug#990971: atitvout should drop ia64 from the architecture list
Source: atitvout Version: 0.4-13 Severity: minor atitvout never built on ia64, and ia64 laptops are not something that ever existed.
Bug#990970: unblock: debconf/1.5.77
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package debconf
* Check that whiptail or dialog is actually usable (closes: #985572).
(and translation updates, as documented in d/changelog)
(changes by Colin Watson)
This is a rare but nasty bug during upgrades, where the chosen
debconf frontend is temporarily not usable breaking the upgrade.
The rest of the changes are translation updates.
I discussed with Colin Watson, who doesn't object to me filing
this unblock request.
diff -Nru debconf-1.5.75/Debconf/FrontEnd/Dialog.pm
debconf-1.5.77/Debconf/FrontEnd/Dialog.pm
--- debconf-1.5.75/Debconf/FrontEnd/Dialog.pm 2021-02-28 19:51:28.0
+0200
+++ debconf-1.5.77/Debconf/FrontEnd/Dialog.pm 2021-06-10 20:17:49.0
+0300
@@ -65,7 +65,8 @@
# Autodetect if whiptail or dialog is available and set magic numbers.
if (Debconf::Path::find("whiptail") &&
(! defined $ENV{DEBCONF_FORCE_DIALOG} || !
Debconf::Path::find("dialog")) &&
- (! defined $ENV{DEBCONF_FORCE_XDIALOG} || !
Debconf::Path::find("Xdialog"))) {
+ (! defined $ENV{DEBCONF_FORCE_XDIALOG} || !
Debconf::Path::find("Xdialog")) &&
+ system('whiptail --version >/dev/null 2>&1') == 0) {
$this->program('whiptail');
$this->dashsep('--');
$this->borderwidth(5);
@@ -77,7 +78,8 @@
$this->hasoutputfd(1);
}
elsif (Debconf::Path::find("dialog") &&
- (! defined $ENV{DEBCONF_FORCE_XDIALOG} || !
Debconf::Path::find("Xdialog"))) {
+ (! defined $ENV{DEBCONF_FORCE_XDIALOG} || !
Debconf::Path::find("Xdialog")) &&
+ system('dialog --version >/dev/null 2>&1') == 0) {
$this->program('dialog');
$this->dashsep(''); # dialog does not need (or support)
# double-dash separation
diff -Nru debconf-1.5.75/debian/changelog debconf-1.5.77/debian/changelog
--- debconf-1.5.75/debian/changelog 2021-02-28 19:51:28.0 +0200
+++ debconf-1.5.77/debian/changelog 2021-06-10 20:17:49.0 +0300
@@ -1,3 +1,24 @@
+debconf (1.5.77) unstable; urgency=medium
+
+ [ Programs translations ]
+ * Dutch (Frans Spiesschaert; closes: #986167).
+ * Polish (Mmobilea; closes: #976044).
+
+ [ Debconf translations ]
+ * Fix double UTF-8 encoding in Finnish translation (closes: #989692).
+
+ -- Colin Watson Thu, 10 Jun 2021 18:17:49 +0100
+
+debconf (1.5.76) unstable; urgency=medium
+
+ [ Colin Watson ]
+ * Check that whiptail or dialog is actually usable (closes: #985572).
+
+ [ Programs translations ]
+ * Dutch (Frans Spiesschaert; closes: #906948).
+
+ -- Colin Watson Sat, 20 Mar 2021 13:14:50 +
+
debconf (1.5.75) unstable; urgency=medium
[ Philip Hands ]
diff -Nru debconf-1.5.75/debian/po/fi.po debconf-1.5.77/debian/po/fi.po
--- debconf-1.5.75/debian/po/fi.po 2021-02-28 19:51:28.0 +0200
+++ debconf-1.5.77/debian/po/fi.po 2021-06-10 20:17:49.0 +0300
@@ -52,8 +52,8 @@
"Packages that use debconf for configuration share a common look and feel. "
"You can select the type of user interface they use."
msgstr ""
-"Debconf yhdenmukaistaa sitÀ kÀyttÀvien pakettien asetuskÀyttöliittymÃ"
-"€n. Voit itse valita mieluisesi liittymÀn muutamasta vaihtoehdosta."
+"Debconf yhdenmukaistaa sitä käyttävien pakettien asetuskäyttöliittymän. Voit "
+"itse valita mieluisesi liittymän muutamasta vaihtoehdosta."
#. Type: select
#. Description
@@ -66,11 +66,10 @@
"you configure things using your favorite text editor. The noninteractive "
"frontend never asks you any questions."
msgstr ""
-"Valintaikkuna on ruudun tÀyttÀvÀ merkkipohjainen liittymÀ, kun taas "
-"readline on perinteisempi pelkkÀÀ tekstiÀ kÀyttÀvÀ liittymÀ. SekÀ "
-"Gnome ettÀ KDE ovat nykyaikaisia X-pohjaisia liittymiÀ. Teksturi kÀyttÀÃ"
-"€ asetusten sÀÀtöön lempiteksturiasi. Ei-vuorovaikutteinen liittymÀ ei "
-"koskaan kysy kysymyksiÀ."
+"Valintaikkuna on ruudun täyttävä merkkipohjainen liittymä, kun taas readline "
+"on perinteisempi pelkkää tekstiä käyttävä liittymä. Sekä Gnome että KDE ovat "
+"nykyaikaisia X-pohjaisia liittymiä. Teksturi käyttää asetusten säätöön "
+"lempiteksturiasi. Ei-vuorovaikutteinen liittymä ei koskaan kysy kysymyksiä."
#. Type: select
#. Choices
@@ -114,13 +113,13 @@
" - 'medium' is for normal questions\n"
" - 'low' is for control freaks who want to see everything"
msgstr ""
-"Debconf priorisoi esittÀmÀnsÀ kysymykset. Valitse alin prioriteetti, "
-"jonka kysymykset haluat nÀhdÀ:\n"
-" - \"kriittinen\" kysyy vain jos jÀrjestelmÀ voi hajota.\n"
-"Valitse tÀmÀ jos olet uusi tai sinulla on kiire.\n"
-" - \"tÀrkeÀ\" on kohtuullisen tÀrkeille kysymyksille\n"
+"Debconf priorisoi esittämänsä kysymykset. Valitse alin prioriteetti, jonka "
+"kysymykset haluat nähdä:\n"
+" -
Bug#990940: release-notes: wpewebkit to be covered by security support in bullseye
On Sun, Jul 11, 2021 at 06:10:09PM +0100, Justin B Rye wrote:
> If we can refer to "webkit" and "khtml" (in the previous line) and
> "Firefox" and "Chromium" (below) without special markup, it's not
> clear why we need make such a big deal about "*webkit2gtk*" and
> "*wpewebkit*" being source package names. I would suggest just:
>
> mentioned here, with the exception of webkit2gtk and
> the new wpewebkit. are included in
> , but not covered by security support. These
> browsers should not be used against untrusted websites.
> The webkit2gtk and wpewebkit engines
> are covered by security support.
Ok, here's a new patch.
Berto
diff --git a/en/issues.dbk b/en/issues.dbk
index d0940906..827ee75f 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -506,12 +506,11 @@ data = ${lookup{$local_part}lsearch{/some/path/$domain_data/aliases}}
enginesThese engines are shipped in a number of different
source packages and the concern applies to all packages shipping
them. The concern also extends to web rendering engines not explicitly
- mentioned here, with the exception of webkit2gtk. are included in
- , but not
+ mentioned here, with the exception of webkit2gtk and the new
+ wpewebkit. are included in , but not
covered by security support. These browsers should not be used against
untrusted websites.
- The webkit2gtk source package is
+ The webkit2gtk and wpewebkit engines are
covered by security support.
Bug#990969: lxml: reproducible-builds: Build path embedded in documentation
Source: lxml Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The version is derived from the build directory name, which gets embedded into the changes-VERSION.html file: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/lxml.html usr/share/doc/python-lxml/html/changes-4.6.3+dfsg.html vs. usr/share/doc/python-lxml/html/changes-2nd.html The attached patch changes debian/rules to use DEB_UPSTREAM_VERSION from dpkg's pkg-info.mk instead of deriving the upstream version from the build directory. Unfortunately, there are other build path related issues in binaries, but this significantly reduces the diff between builds. Thanks for maintaining lxml! live well, vagrant From 95c022663849bc83ad5f76ef7be17809494b8bfb Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sun, 11 Jul 2021 20:15:53 + Subject: [PATCH 3/3] Use DEB_VERSION_UPSTREAM from dpkg/pkg-info.mk to pass the upstream version to doc/mkhtml.py. Assuming that the build directory contains the package name and version will result in different builds dependent on the build path. --- debian/rules | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/rules b/debian/rules index 466e936..9c1e0d0 100755 --- a/debian/rules +++ b/debian/rules @@ -7,7 +7,7 @@ PY3VERS := $(shell py3versions -vs) PY3VER := $(shell py3versions -vd) -UPSTREAMVER := $(subst lxml-,,$(notdir $(CURDIR))) +include /usr/share/dpkg/pkg-info.mk # Some locales trigger reproducibility issues in html documentation export LC_ALL=C.UTF-8 @@ -29,7 +29,7 @@ build3-stamp: $(PY3VERS:%=build3-python%) $(PY3VERS:%=dbg-build3-python%) build3-python%: prebuild python$* setup.py build ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS))) - python$* doc/mkhtml.py doc/html . $(UPSTREAMVER) + python$* doc/mkhtml.py doc/html . $(DEB_VERSION_UPSTREAM) endif touch $@ dbg-build3-python%: prebuild -- 2.32.0 signature.asc Description: PGP signature
Bug#990963: gajim: Recommends non-existent python3-crypto package
Thanks for your bug report, Matt! On 2021-07-11 19:22, Matt Marjanovic wrote: > so > maybe the Recommends for python3-crypto is vestigial and can simply be > dropped. Yes. I believe, that this is the case! I removed the Recommends in git.
Bug#990968: unblock: apache2/2.4.48-3.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: t...@mirbsd.de Please unblock package apache2 [ Reason ] Fixes #990580 which is a regression caused by the changes from #979813. [ Impact ] Sysadmins will get hundreds of eMails each night, become angry and storm Debian HQ with torches and putforks and… erm well insert your favourite upraising scenatio. [ Tests ] The updated package fixes the issue for me, and the cause was identified by kilobyte, so it’s seen two eyepairs at least. [ Risks ] Trivial fix to a logrotate script. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] unblock apache2/2.4.48-3.1 diff -Nru apache2-2.4.48/debian/apache2.logrotate apache2-2.4.48/debian/apache2.logrotate --- apache2-2.4.48/debian/apache2.logrotate 2021-06-20 13:55:24.0 +0200 +++ apache2-2.4.48/debian/apache2.logrotate 2021-07-10 23:31:24.0 +0200 @@ -14,7 +14,7 @@ endscript postrotate if pgrep -f ^/usr/sbin/apache2 > /dev/null; then - invoke-rc.d apache2 reload + invoke-rc.d apache2 reload 2>&1 | logger -t apache2.logrotate fi endscript } diff -Nru apache2-2.4.48/debian/changelog apache2-2.4.48/debian/changelog --- apache2-2.4.48/debian/changelog 2021-06-20 16:39:33.0 +0200 +++ apache2-2.4.48/debian/changelog 2021-07-10 23:31:28.0 +0200 @@ -1,3 +1,11 @@ +apache2 (2.4.48-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Direct init script reload output from logrotate to syslog, to +avoid mail-spamming the local admin (Closes: #990580) + + -- Thorsten Glaser Sat, 10 Jul 2021 23:31:28 +0200 + apache2 (2.4.48-3) unstable; urgency=medium * Fix debian/changelog
Bug#990967: unblock: debmirror/1:2.35
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock debmirror 1:2.35. I hadn't been going to request this
because #961197 was only filed at normal severity, but Adrian Bunk
pointed out that "fills up root filesystem" is rather less than ideal
and they probably have a point.
diff -Nru debmirror-2.34/debian/changelog debmirror-2.35/debian/changelog
--- debmirror-2.34/debian/changelog 2021-02-06 17:33:50.0 +
+++ debmirror-2.35/debian/changelog 2021-06-03 11:23:33.0 +0100
@@ -1,3 +1,11 @@
+debmirror (1:2.35) unstable; urgency=medium
+
+ [ Kees Cook ]
+ * Remove temporary files created while verifying InRelease (closes:
+#961197).
+
+ -- Colin Watson Thu, 03 Jun 2021 11:23:33 +0100
+
debmirror (1:2.34) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru debmirror-2.34/debmirror debmirror-2.35/debmirror
--- debmirror-2.34/debmirror2021-02-06 17:33:50.0 +
+++ debmirror-2.35/debmirror2021-06-03 11:23:33.0 +0100
@@ -2328,6 +2328,8 @@
push (@errlog,$@);
$num_errors++;
}
+ unlink($content_filename);
+ unlink($signature_filename);
}
if (! $got_gpg) {
say("Release gpg signature does not verify, file missing.");
unblock debmirror/1:2.35
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
signature.asc
Description: PGP signature
Bug#990897: unblock: linux/5.10.46-1
Control: tags -1 d-i Hi, On 10-07-2021 22:15, Salvatore Bonaccorso wrote: > Hi release team, hi Cyril (specifically for d-i) So, let's add him (via d-boot) in. > Please unblock package linux > > It contained a rebase of the 5.10.y series to 5.10.46 upstream and > included the following changes relevant to add additional HW support > and bugfxes. The upstream import to 5.10.46 contained fixes for > various CVEs. Ack. > I guess at this point we want to delay any further 5.10.y imports to > the first bullseye point release, but let me know your toughts on > this. If the tentative release date becomes solid, I think that's a good plan. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990954: kodi: crashes on older hardware
Please find attached the output of "glxinfo -v -t". Cheers On Sun, 2021-07-11 at 20:04 +, Vasyl Gello wrote: > Sven, > > It is not only VDPAU missing for you but opengl is totally broken > (see Failed to create EGL context, and GL major/minor versions set to > NULL). > Can you run glxinfo? I guess since there is no i915 driver it'll be > broken anyway but… > -- > Vasyl Gello > == > Certified SolidWorks Expert > > Mob.:+380 (98) 465 66 77 > > E-Mail: vasek.ge...@gmail.com > > Skype: vasek.gello > == > 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 -- GPG Fingerprint 3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585 name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_no_config_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync GLX version: 1.4 GLX extensions: GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_swap_control, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) 945GM x86/MMX/SSE2 (0x27a2) Version: 20.3.4 Accelerated: yes Video memory: 192MB Unified memory: yes Preferred profile: compat (0x2) Max core profile version: 0.0 Max compat profile version: 1.4 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 2.0 OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) 945GM x86/MMX/SSE2 OpenGL version string: 1.4 Mesa 20.3.4 OpenGL extensions: GL_3DFX_texture_compression_FXT1, GL_AMD_shader_trinary_minmax, GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, GL_APPLE_object_purgeable, GL_APPLE_packed_pixels, GL_ARB_ES2_compatibility, GL_ARB_clear_buffer_object, GL_ARB_compressed_texture_pixel_storage, GL_ARB_copy_buffer, GL_ARB_debug_output, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, GL_ARB_explicit_uniform_location, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_framebuffer_object, GL_ARB_get_program_binary, GL_ARB_get_texture_sub_image, GL_ARB_half_float_pixel, GL_ARB_internalformat_query, GL_ARB_invalidate_subdata, GL_ARB_map_buffer_alignment, GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_parallel_shader_compile, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters,
Bug#990932: unblock: udpkg/1.20
Control: tags -1 confirmed d-i Hi Steve, On 11-07-2021 12:21, Steve McIntyre wrote: > Please unblock package udpkg unblocked > I've added locking for the status file, so parallel udpkg invocations > will not break the world. This fixes #987368. We definitely want this > fix for Bullseye. I've CC:ed KiBi too. ...but waiting for ack from kibi. (Didn't see the CC, so adding d-boot). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990966: grub-efi-arm64: breaks upgrades when the efivarfs is mounted read-only
Package: grub-efi-arm64 Version: 2.04-19 Severity: serious I experienced the follow on multiple ARM64 systems (both a Rock64 board and a Raspberry Pi 4b board) during an unattended-upgrades run: Unattended upgrade result: All upgrades installed Packages that attempted to upgrade: shim-helpers-arm64-signed shim-signed shim-signed-common shim-unsigned Packages with upgradable origin but kept back: Debian testing: shim-signed shim-helpers-arm64-signed shim-signed-common Package installation log: Log started: 2021-07-10 06:16:45 Preparing to unpack .../shim-unsigned_15.4-6_arm64.deb ... Unpacking shim-unsigned (15.4-6) over (15.4-5) ... Setting up shim-unsigned (15.4-6) ... Log ended: 2021-07-10 06:16:50 Log started: 2021-07-10 06:16:51 Preconfiguring packages ... Preconfiguring packages ... Preparing to unpack .../shim-signed-common_1.37+15.4-6_all.deb ... Unpacking shim-signed-common (1.37+15.4-6) over (1.36+15.4-5) ... Preparing to unpack .../shim-signed_1.37+15.4-6_arm64.deb ... Unpacking shim-signed:arm64 (1.37+15.4-6) over (1.36+15.4-5) ... Setting up shim-signed-common (1.37+15.4-6) ... No DKMS packages installed: not changing Secure Boot validation state. Setting up shim-signed:arm64 (1.37+15.4-6) ... Installing for arm64-efi platform. grub-install: warning: Cannot set EFI variable Boot. grub-install: warning: efivarfs_set_variable: failed to create /sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c for writing: Read-only file system. grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Read-only file system. grub-install: error: failed to register the EFI boot entry: Read-only file system. dpkg: error processing package shim-signed:arm64 (--configure): installed shim-signed:arm64 package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: shim-signed:arm64 E:Sub-process /usr/bin/dpkg returned an error code (1) Log ended: 2021-07-10 06:17:29 Unattended-upgrades log: Checking if system is running on battery is skipped. Please install powermgmt-base package to check power status and skip installing updates when the system is running on battery. Starting unattended upgrades script Allowed origins are: origin=Debian,codename=bullseye,label=Debian, origin=Debian,codename=bullseye,label=Debian-Security, origin=Debian,codename=bullseye-security,label=Debian-Security Initial blacklist: Initial whitelist (not strict): Packages that will be upgraded: shim-helpers-arm64-signed shim-signed shim-signed-common shim-unsigned Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log Installing the upgrades failed! error message: installArchives() failed dpkg returned a error! See /var/log/unattended-upgrades/unattended-upgrades-dpkg.log for details Package shim-helpers-arm64-signed is kept back because a related package is kept back or due to local apt_preferences(5). Package shim-signed is kept back because a related package is kept back or due to local apt_preferences(5). Package shim-signed-common is kept back because a related package is kept back or due to local apt_preferences(5). Here's the relevant field in /proc/mounts: efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec,relatime 0 0 I expect that the reason /sys/firmware/efi/efivars is mounted read-only is due to bug reports such as the following: https://github.com/systemd/systemd/issues/2402 It would be preferable for grub to either a) continue the package postinstall despite efivars being read-only, or b) remount efivars read-write, update efivars, and then remount ro. grub-install is being called from shim-helpers-arm64-signed's postinst. You could argue that shim-helpers-arm64-signed could remount efivars read-write, but since I can actually trigger the same error in grub-efi-arm64's postinst, it seems like this should be fixed in grub: dilinger@wifi2:~$ sudo dpkg-reconfigure grub-efi-arm64 [sudo] password for dilinger: Installing for arm64-efi platform. grub-install: warning: Cannot set EFI variable Boot. grub-install: warning: efivarfs_set_variable: failed to create /sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c for writing: Read-only file system. grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: Read-only file system. grub-install: error: failed to register the EFI boot entry: Read-only file system. Failed: grub-install --target=arm64-efi WARNING: Bootloader is not properly installed, system may not be bootable Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.10.0-7-arm64 Found initrd image: /boot/initrd.img-5.10.0-7-arm64 done
Bug#990954: kodi: crashes on older hardware
On 2021-07-11 20:04:57 +, Vasyl Gello wrote: > Sven, > > It is not only VDPAU missing for you but opengl is totally broken (see Failed > to create EGL context, and GL major/minor versions set to NULL). > Can you run glxinfo? I guess since there is no i915 driver it'll be broken > anyway but… VA-API drivers and OpenGL drivers are two different things. Cheers > -- > Vasyl Gello > == > Certified SolidWorks Expert > > Mob.:+380 (98) 465 66 77 > > E-Mail: vasek.ge...@gmail.com > > Skype: vasek.gello > == > 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#990882: openssh-server: With ipv6 ssh-client fail as well as scp getting expecting SSH2_MSG_KEX_ECDH_REPLY
Hallo Daniel, 10.07.21 14:14 Daniel: > ssh and scp connecting smoothly. With the above MACs trick, scp connect > but then hangs on copy like > > Authenticated to myserver ([2001:db8:dead:beef::1]:22). > debug1: channel 0: new [client-session] > debug1: Requesting no-more-sessi...@openssh.com > debug1: Entering interactive session. > debug1: pledge: network > debug1: client_input_global_request: rtype hostkeys...@openssh.com > want_reply 0 > debug1: Remote: /root/.ssh/authorized_keys:2: key options: > agent-forwarding port-forwarding pty user-rc x11-forwarding > debug1: Remote: /root/.ssh/authorized_keys:2: key options: > agent-forwarding port-forwarding pty user-rc x11-forwarding > debug1: Sending environment. > debug1: Sending env LANG = fr_FR.UTF-8 > debug1: Sending command: scp -v -t /etc/bind/VarCacheBind/ > Sending file modes: C0644 3079 file.txt > Sink: C0644 3079 file.txt > file.txt 0% 0 0.0KB/s --:-- ETA So actually the connection setup (small packets) works and the connection starts hanging when packets get big. > * What exactly did you do (or not do) that was effective (or > ineffective)? > > Adding MACs=hmacs-sha2-256 to .ssh/config solved the problem for ssh > client (Debian 9/10 & Ubuntu 18/20) but not for scp (Debian 9/10 & > Ubuntu 18/20) A quick test with wireshark shows: ssh client with default/no config sends a "Client: Key Exchange Init" with over 1500 Bytes. With that config change you likely dropped that below your PMTU. What is the network between client and server like? Does PMTUD work? Maybe there are non-conforming IPv6-implementations and/or misconfigured firewalls on the way? > If we do the copy in ipv4 -by adding -4 in front of command- it copy > smoothly. Well, in IPv4 routers usually do fragmentation (lowering throughput/ efficiency) instead of relying on PMTUD. Grüße Timo signature.asc Description: This is a digitally signed message part.
Bug#990906: Xarchiver Debian bug 990906
Hi Ingo, I have received a bug report from David Harte (Debian bug #990906) and I can reproduce the behavior. https://bugs.debian.org/990906 It makes no difference if the linked directory is on a ntfs or ext4 file system though. If you follow all steps and open the archive with xarchiver and double click on the symlink, then xarchiver will move the files from the linked directory to the tmp directory. They are not lost yet but this is a surprising behavior. After a reboot they would be permanently lost though. If I right click on the symlink and try to extract it then the extraction works as intended. However the "Open with" feature (or a double click) produces an error message and moves the files inside the symlinked directory to the tmp directory. Could you comment on this issue please? Is there a quick fix which I could apply to address this problem because we are in a full freeze right now. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#990954: kodi: crashes on older hardware
Sven, It is not only VDPAU missing for you but opengl is totally broken (see Failed to create EGL context, and GL major/minor versions set to NULL). Can you run glxinfo? I guess since there is no i915 driver it'll be broken anyway but… -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#990956: uploading lintian-brush to testing-proposed-updates
Hi Jelmer, On 11-07-2021 21:47, Jelmer Vernooij wrote: > It's going to be tricky to get this resolved in time before the removal of > lintian-brush from testing. Can you elaborate why it's tricky (not promising anything, but there could be reasons for t-p-u)? The current autoremoval is scheduled for August 8, which is *after* the tentative release date. > Of the reverse dependencies, routine-update can > hopefully be updated easily (I've already pinged Andreas) to skip > lintian-brush > and silver-platter should probably not make it into bullseye (I've just filed > a > removal request for it). I'll handle the removals. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990965: unblock: liferea/1.13.5-3
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package liferea
[ Reason ]
The version of liferea in bullseye is susceptible to bug 990911 where
the application can crash if the user select a specific element (news
bin) in the GUI. What's worse, if a news bin was the last selected item
before upgrading, it will then automatically crash on startup with no
way for the user to recover, except by downgrading.
[ Impact ]
Program crashes, or fails to start after upgrade.
[ Tests ]
I verified manually that I can trigger the crash with the version in
bullseye and that the crash doesn't happen with the patch from upstream
applied.
[ Risks ]
The patch is small and is a move of three lines of existing code to
inside an if(). I'd say the risk is small. The patch comes from upstream
(and is nearly a year ago).
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock liferea/1.13.5-3
Paul
diff -Nru liferea-1.13.5/debian/changelog liferea-1.13.5/debian/changelog
--- liferea-1.13.5/debian/changelog 2021-04-27 20:27:39.0 +0200
+++ liferea-1.13.5/debian/changelog 2021-07-11 21:37:39.0 +0200
@@ -1,3 +1,10 @@
+liferea (1.13.5-3) unstable; urgency=medium
+
+ [ Frédéric Brière ]
+ * Add 0001-Fix-crash-on-selecting-news-bins.patch (Closes: #990911)
+
+ -- Paul Gevers Sun, 11 Jul 2021 21:37:39 +0200
+
liferea (1.13.5-2) unstable; urgency=medium
* Add patch to work with latest webgit2gkt:
diff -Nru
liferea-1.13.5/debian/patches/0001-Fix-crash-on-selecting-news-bins.patch
liferea-1.13.5/debian/patches/0001-Fix-crash-on-selecting-news-bins.patch
--- liferea-1.13.5/debian/patches/0001-Fix-crash-on-selecting-news-bins.patch
1970-01-01 01:00:00.0 +0100
+++ liferea-1.13.5/debian/patches/0001-Fix-crash-on-selecting-news-bins.patch
2021-07-11 21:37:39.0 +0200
@@ -0,0 +1,43 @@
+From dd9ede21cd822989e9fafecadefb4fc410a7c0e7 Mon Sep 17 00:00:00 2001
+From: Lars Windolf
+Date: Fri, 2 Apr 2021 01:22:24 +0200
+Subject: [PATCH] Fix crash on selecting news bins
+
+---
+ src/feed.c | 11 ++-
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/src/feed.c b/src/feed.c
+index 585ed82a..97848f9f 100644
+--- a/src/feed.c
b/src/feed.c
+@@ -165,9 +165,14 @@ feed_add_xml_attributes (nodePtr node, xmlNodePtr
feedNode)
+ xmlNewTextChild (feedNode, NULL, "feedId", node_get_id (node));
+ xmlNewTextChild (feedNode, NULL, "feedTitle", node_get_title (node));
+
+- if (node->subscription)
++ if (node->subscription) {
+ subscription_to_xml (node->subscription, feedNode);
+
++ tmp = g_strdup_printf("%d", node->subscription->error);
++ xmlNewTextChild(feedNode, NULL, "error", tmp);
++ g_free(tmp);
++ }
++
+ tmp = g_strdup_printf("%d", node->available?1:0);
+ xmlNewTextChild(feedNode, NULL, "feedStatus", tmp);
+ g_free(tmp);
+@@ -178,10 +183,6 @@ feed_add_xml_attributes (nodePtr node, xmlNodePtr
feedNode)
+
+ if(feed->parseErrors && (strlen(feed->parseErrors->str) > 0))
+ xmlNewTextChild(feedNode, NULL, "parseError",
feed->parseErrors->str);
+-
+- tmp = g_strdup_printf("%d", node->subscription->error);
+- xmlNewTextChild(feedNode, NULL, "error", tmp);
+- g_free(tmp);
+ }
+
+ xmlDocPtr
+--
+2.30.2
+
diff -Nru liferea-1.13.5/debian/patches/series
liferea-1.13.5/debian/patches/series
--- liferea-1.13.5/debian/patches/series2021-04-27 20:27:39.0
+0200
+++ liferea-1.13.5/debian/patches/series2021-07-11 21:37:39.0
+0200
@@ -1,3 +1,4 @@
debian-example-feeds.patch
www-browser.patch
34d26be00328a68d2f1625c78b54dc168da0648e.patch
+0001-Fix-crash-on-selecting-news-bins.patch
OpenPGP_signature
Description: OpenPGP digital signature
Bug#966549: autopkgtest fails with rails 6 in experimental
Control: severity -1 important On Thu, 30 Jul 2020 19:18:09 +0530 Kartik Kulkarni wrote: > Hi, > > This package's autopkgtest and rebuilds failed with rails 6 currently in > experimental. rails 6 will be uploaded to unstable in a weeks time, so > please make sure this package is ready for rails 6. The severity of > this bug will be raised to serious after rails 6 is uploaded to > unstable. Its only reverse dependency diaspora now embeds rails 5 and the test failures during build is ignored and autopkgtest is disabled in 1.1.0-4. I will keep the bug open in case someone is interested to fix the rails 6 support. Alternatively, if diaspora switches to another gem like premailer-rails we could remove this package.
Bug#990954: kodi: crashes on older hardware
Hi Sven! Looks like https://github.com/xbmc/xbmc/blob/9c2c8913a80a32aee0dc582bc737744c2989a32c/xbmc/utils/GLUtils.cpp#L148 gets nullptr from libgl somewhere. I will build i386 with DWO CUs and upload to fex.net so that we can get finer-grained picture of what fails. -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#990961: RM: ognibuild/0.0.1~git20201031.4cbc8df-1.1
Control: tags -1 moreinfo On 2021-07-11 19:02:20 +, Jelmer Vernooij wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > > Please remove ognibuild from bullseye/testing; the current version > (0.0.1~git20201031.4cbc8df-1.1) there is a very early prerelease that is > unlikely to provide a good experience to users. % dak rm -Rn -s testing ognibuild Will remove the following packages from testing: ognibuild | 0.0.1~git20201031.4cbc8df-1.1 | source, all Maintainer: Jelmer Vernooij --- Reason --- -- Checking reverse dependencies... # Broken Depends: lintian-brush: lintian-brush # Broken Build-Depends: lintian-brush: ognibuild Dependency problem found. So that won't be possible without also removing lintian-brush. So is that really what you want? Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#990956: uploading lintian-brush to testing-proposed-updates
Hi Paul, On Sun, Jul 11, 2021 at 08:35:07PM +0200, Paul Gevers wrote: > On 11-07-2021 19:44, Jelmer Vernooij wrote: > > Can I upload a small fix for lintian-brush to testing-proposed-updates to > > allow > > it to remain in testing? I just found out an old FTBFS bug is still > > affecting > > it in testing, and there's a much newer version in unstable. > > That's not why we have t-p-u. We really prefer you to revert the new > upstream release in unstable (using e.g. +really version number). See > also our FAQ [1]. Thanks for the reply. Unfortunately this is something that I get caught up in my workflow around every release - having to switch to uploading to experimental for some packages rather than unstable. I really should have paid more attention to that, rather than creating this mess. :-/ It's going to be tricky to get this resolved in time before the removal of lintian-brush from testing. Of the reverse dependencies, routine-update can hopefully be updated easily (I've already pinged Andreas) to skip lintian-brush and silver-platter should probably not make it into bullseye (I've just filed a removal request for it). Jelmer
Bug#990911: liferea: Segfaults when selecting a news bin
Control: tags -1 confirmed Control: severity -1 serious Hi Frédéric, On 11-07-2021 01:33, Frédéric Brière wrote: > liferea 1.13.5 will immediately segfault when selecting a news bin in > the left pane. (And if a news bin was the last selected item before > upgrading, it will then automatically crash on startup. I'd argue this > would justify a bump to serious; you be the judge.) Don't be shy ;), done so now. > The bug is in feed_add_xml_attributes(), where node->subscription gets > dereferenced at the end, even if it was found to be NULL beforehand. > > This was fixed upstream in 49cf235, by moving the last three lines > inside the if(), where they belong. That patch does not apply cleanly > to 1.13.5 (due to 9db267f), so I'm attaching a revised version. Thanks for the report, and the patch, will upload soon. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990954: kodi: crashes on older hardware
Hi Vasyl! Hi Sebastian! On Sun, 2021-07-11 at 21:18 +0200, Sebastian Ramacher wrote: > On 2021-07-11 19:03:23 +, Vasyl Gello wrote: > > Hi Sven! > > > > I am not using Intel HD graphics but maybe Sebastian knows someone > > who uses it. > > The issue of missing i915 driver was reported in 2014. > > Processors from Cantiga and newer come with integrated graphics chips > and VA-API support. The processor is simply too old and is never > going to get VA-API support. [...] Here are the details of the graphics chip set (from lspci): 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) I would expect Kodi would not request acceleration for such a graphics controller. @Vasyl: Please find attached a Kodi crash log including stack trace. Cheers, Sven -- GPG Fingerprint 3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585 ## Kodi CRASH LOG ### SYSTEM INFO Date: Sun Jul 11 21:17:45 CEST 2021 Kodi Options: Arch: i686 Kernel: Linux 5.10.0-7-686-pae #1 SMP Debian 5.10.40-1 (2021-05-28) Release: Debian GNU/Linux 11 (bullseye) ## END SYSTEM INFO ## ### STACK TRACE # => Core file: /home/kodi/core (2021-07-11 21:17:41.612602823 +0200) = [New LWP 1054] [New LWP 1057] [New LWP 1059] [New LWP 1063] [New LWP 1060] [New LWP 1066] [New LWP 1064] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". Core was generated by `/usr/lib/i386-linux-gnu/kodi/kodi.bin'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:50 [Current thread is 1 (Thread 0xa9fd15c0 (LWP 1054))] Thread 7 (Thread 0x979feb40 (LWP 1064)): #0 0xb7f12559 in __kernel_vsyscall () #1 0xb7ee6ecc in futex_wait_cancelable (private=0, expected=0, futex_word=0x98200dc8) at ../sysdeps/nptl/futex-internal.h:186 #2 __pthread_cond_wait_common (abstime=, clockid=, mutex=, cond=) at pthread_cond_wait.c:508 #3 __pthread_cond_wait (cond=0x98200da0, mutex=0x98200de0) at pthread_cond_wait.c:638 #4 0xb3f7ee19 in pa_cond_wait () from /usr/lib/i386-linux-gnu/pulseaudio/libpulsecommon-14.2.so warning: Could not find DWO CU CMakeFiles/audioengine.dir/Sinks/AESinkPULSE.cpp.dwo(0x69e947b35e7ea6db) referenced by CU at offset 0xf7f0 [in module /usr/lib/debug/.build-id/ab/17203b9bc3fc28554ef4db23c5d41d1e1f1152.debug] #5 0xb7a6864a in pa_threaded_mainloop_wait () from /usr/lib/i386-linux-gnu/libpulse.so.0 warning: (Internal error: pc 0x1b1d828 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b1d829 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b1d829 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b1d6c0 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b1d828 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b1d828 in read in CU, but not in symtab.) warning: Could not find DWO CU CMakeFiles/audioengine.dir/Engines/ActiveAE/ActiveAESink.cpp.dwo(0x1848dad7951f7491) referenced by CU at offset 0xf550 [in module /usr/lib/debug/.build-id/ab/17203b9bc3fc28554ef4db23c5d41d1e1f1152.debug] warning: (Internal error: pc 0x1b1d828 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b1d828 in read in CU, but not in symtab.) #6 0x01b1d829 in CAESinkPULSE::AddPackets(unsigned char**, unsigned int, unsigned int) (warning: (Internal error: pc 0x1b1d828 in read in CU, but not in symtab.) ) at ./xbmc/cores/AudioEngine/Sinks/AESinkPULSE.cpp:1086 warning: (Internal error: pc 0x1b01077 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b01078 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b01078 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b00fc0 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b01077 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b01077 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b02581 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b01077 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b01077 in read in CU, but not in symtab.) #7 0x01b01078 in ActiveAE::CActiveAESink::OutputSamples(ActiveAE::CSampleBuffer*) (warning: (Internal error: pc 0x1b01077 in read in CU, but not in symtab.) ) at ./xbmc/cores/AudioEngine/Engines/ActiveAE/ActiveAESink.cpp:1028 warning: (Internal error: pc 0x1b02581 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b02582 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b02582 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b022a0 in read in CU, but not in symtab.) warning: (Internal error: pc 0x1b02581 in read in CU, but not in symtab.)
Bug#990964: installation-reports: Successfully installed on hp notebook with latest rc of debian 11
Package: installation-reports Severity: normal X-Debbugs-Cc: ilovecountrymusic...@gmail.com (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: usb Image version: debian bulzye rc2 nonfree encluding firmware Date: July 10th 10:00 P.m EST. Machine: Hp notebook Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot:O [ ] Detect network card:O[ ] Configure network: [O ] Detect media: [O ] Load installer modules: [O ] Clock/timezone setup: [O ] User/password setup:[O ] Detect hard drives: [O ] Partition hard drives: [O ] Install base system:[O ] Install tasks: [O ] Install boot loader:[O ] Overall install:[O ] Comments/Problems: This is a 2 year old machine that runs debian well. I use mate desktop and all works well here on this machine. I even got speech working both in gui and concle. Please make sure that any installation logs that you think would be useful are attached to this report. Please compress large files using gzip. -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210606" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux debian-hp-laptop 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 (2021-05-28) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SoC Transaction Register [8086:2280] (rev 35) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:81f1] lspci -knn: Kernel driver in use: iosf_mbi_pci lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller [8086:22b1] (rev 35) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:81f1] lspci -knn: 00:0b.0 Signal processing controller [1180]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power Management Controller [8086:22dc] (rev 35) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:81f1] lspci -knn: 00:13.0 SATA controller [0106]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SATA Controller [8086:22a3] (rev 35) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:81f1] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller [8086:22b5] (rev 35) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:81f1] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:1a.0 Encryption controller [1080]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine [8086:2298] (rev 35) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:81f1] lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series High Definition Audio Controller [8086:2284] (rev 35) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:81f1] lspci -knn: Kernel driver in use: snd_hda_intel lspci -knn: Kernel modules: snd_hda_intel lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Express Port #1 [8086:22c8] (rev 35) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Express Port #3 [8086:22cc] (rev 35) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Express Port #4 [8086:22ce] (rev 35) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCU [8086:229c] (rev 35) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:81f1] lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx SMBus Controller [8086:2292] (rev 35) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:81f1] lspci -knn: 02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter [10ec:b723] lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:81c1] lspci -knn: Kernel
Bug#990963: gajim: Recommends non-existent python3-crypto package
Package: gajim Version: 1.3.1-1 Severity: normal X-Debbugs-Cc: mad...@mir.com Dear Maintainer, The gajim package has a Recommends for the python3-crypto package, but that package no longer exists after buster. (It has been removed from unstable/testing and will not exist in bullseye.) It is not clear what functionality is lost if python3-crypto is not present or if it is removed, so it is not clear (to me) how serious this is. E.g., will OMEMO encryption/decryption abruptly stop working? changelog.Debian.gz suggests that this was the case at some (early) point, as it mentions that the Recommends was added to enable end-to-end encryption. On the other hand, the gajim-omemo package itself has a hard Depends on the python3-cryptography package --- so maybe the Recommends for python3-crypto is vestigial and can simply be dropped. (If the python3-crypto Recommends does still serve a purpose: the removed-from-unstable message for python3-crypto mentions that it has been replaced by python3-pycryptodome. Maybe this is enough of a drop-in replacement that the Recommends could simply be changed to the new package? I have no idea if this is actually the case; I am just trying to give this bug a chance of being fixed for bullseye.) -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gajim depends on: ii desktop-file-utils 0.26-1 ii gir1.2-gtk-3.0 3.24.24-4 ii python3 3.9.2-3 ii python3-cairo1.16.2-4+b2 ii python3-css-parser 1.0.6-1 ii python3-cssutils 1.0.2-3 ii python3-gi 3.38.0-2 ii python3-gi-cairo 3.38.0-2 ii python3-idna 2.10-1 ii python3-keyring 22.0.1-1 ii python3-nbxmpp 2.0.2-1 ii python3-openssl 20.0.1-1 ii python3-packaging20.9-2 ii python3-precis-i18n 1.0.2-3 Versions of packages gajim recommends: ii alsa-utils 1.2.4-1 ii aspell-en [aspell-dictionary]2018.04.16-0-1 ii ca-certificates 20210119 ii dbus 1.12.20-2 ii fonts-noto-color-emoji 0~20200916-1 ii gajim-omemo 2.7.13-1 ii gajim-pgp1.3.5-2 ii gir1.2-farstream-0.2 0.2.9-1 ii gir1.2-geoclue-2.0 2.5.7-3 ii gir1.2-gsound-1.01.0.2-5 ii gir1.2-gspell-1 1.8.4-1 ii gir1.2-gst-plugins-base-1.0 1.18.4-dmo1 ii gir1.2-gstreamer-1.0 1.18.4-2 ii gir1.2-gupnpigd-1.0 1.2.0-1 ii gir1.2-secret-1 0.20.4-2 ii gstreamer1.0-plugins-ugly1:1.18.4-dmo3 ii notification-daemon 3.20.0-4 ii pulseaudio-utils 14.2-2 ii python3-crypto 2.6.1-13.1+b3 ii python3-dbus 1.2.16-5 ii python3-gnupg0.4.6-1 ii python3-pil 8.1.2+dfsg-0.2 ii sox 14.4.2+git20190427-2 ii xfce4-notifyd [notification-daemon] 0.6.2-1 Versions of packages gajim suggests: ii avahi-daemon 0.8-5 ii libxss1 1:1.2.3-1 pn nautilus-sendto ii python3-kerberos 1.1.14-3.1+b3 ii python3-pycurl7.43.0.6-5 -- no debconf information
Bug#990395: depends on deprecated qhull library
Thanks for reporting this. Upstream (ie, me) has support for this, which is now merged into the main branch (default, 8f9d2fe3d9dd). This was previously blocked by 925540. Some build targets still use the old qhull library, so I will modify it to support both old and new versions at configure time. Thanks.
Bug#990954: kodi: crashes on older hardware
On 2021-07-11 19:03:23 +, Vasyl Gello wrote: > Hi Sven! > > I am not using Intel HD graphics but maybe Sebastian knows someone who uses > it. > The issue of missing i915 driver was reported in 2014. Processors from Cantiga and newer come with integrated graphics chips and VA-API support. The processor is simply too old and is never going to get VA-API support. Cheers > -- > Vasyl Gello > == > Certified SolidWorks Expert > > Mob.:+380 (98) 465 66 77 > > E-Mail: vasek.ge...@gmail.com > > Skype: vasek.gello > == > 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#990954: kodi: crashes on older hardware
Hi Sven! I am not using Intel HD graphics but maybe Sebastian knows someone who uses it. The issue of missing i915 driver was reported in 2014. -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#990961: RM: ognibuild/0.0.1~git20201031.4cbc8df-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove ognibuild from bullseye/testing; the current version (0.0.1~git20201031.4cbc8df-1.1) there is a very early prerelease that is unlikely to provide a good experience to users.
Bug#990960: RM: silver-platter/0.4.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove silver-platter from bullseye; the current version has a low popcon count (9) and upgrading to future versions will require a major change for users - a new CLI has been introduced in 0.4.3. It's probably best not to encourage adoption of the old CLI.
Bug#988909: Please make sure lintian-brush will migrate to testing (Was: routine-update is marked for autoremoval from testing)
Hi Andreas, Thanks for the pointer - I hadn't realized that this bug was still affecting testing. How hard would it be to drop support for lintian-brush in routine-update in testing? It looks like properly fixing this bug is going to be tricky if it involves going via unstable - it would mean rolling back several packages in unstable. Dropping lintian-brush is probably the safest option to avoid impact on routine-update, as I am not sure I'll be able to get all of that done properly in time. Sorry :-/ Cheers, Jelmer On Fri, Jul 09, 2021 at 08:53:27AM +0200, Andreas Tille wrote: > Hi Jelmer, > > its only four days left to get lintian-brush migrating. You definitely > need to do some action. > > Kind regards > Andreas. > > On Fri, Jul 09, 2021 at 04:39:03AM +, Debian testing autoremoval watch > wrote: > > routine-update 0.0.6 is marked for autoremoval from testing on 2021-07-13 > > > > It (build-)depends on packages with these RC bugs: > > 988909: lintian-brush: autopkgtest failure and FTBFS > > https://bugs.debian.org/988909 > > > > > > > > This mail is generated by: > > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > > > > Autoremoval data is generated by: > > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl > > > > ___ > > Debian-med-packaging mailing list > > debian-med-packag...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > > > > -- > http://fam-tille.de > signature.asc Description: PGP signature
Bug#990418: SSL handshake failed when loading openweathermap data
On 11.07.2021 03:36, Adrian Bunk wrote: On Mon, Jun 28, 2021 at 10:10:23PM +0500, Alexei Ustyuzhaninov wrote: Package: gnome-shell-extension-weather Version: 0.0~git20201103.d8be50f-1 Severity: important The extensiond doesn't show the weather information for me. A quick debuging shows that it can't access the openweathermap api with error "SSL handshake failed". The sasame url (https://api.openweathermap.org/data/2.5/weather?lon=60.6082502=56.8391034=metric=) is opened in a browser without a problem. ... Thanks for your report, does it work after installing the ca-certificates package? Hi Adrian! Yes, updating ca-certificates to version 20210119 (I had version 20200601 installed previously) fixed the issue. Probably dependencies of the gnome-shell-extension-weather package should be corrected. Thank you very much for the help, -- Alexei
Bug#990888: libnss-gw-name FTCBFS: builds for the build architecture
Hi, thanks for the patch. Feel free to NMU the package to be unblocked, I am not sure when I’ll get around to do an upload (recently re-set up my laptop and not fully working yet). Cheers, Joachim Am Samstag, dem 10.07.2021 um 17:41 +0200 schrieb Helmut Grohne: > Source: libnss-gw-name > Version: 0.3-2 > Tags: patch > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > > libnss-gw-name fails to cross build from source, because debian/rules > does not pass cross tools to make. The easiest way of doing so - using > dh_auto_build - is not sufficient as the upstream Makefile hard codes > pkg-config. It has to be made substitutable as well. Please consider > applying the attached patch. > > Helmut -- Joachim “nomeata” Breitner • nome...@debian.org • https://j.oach.im/ signature.asc Description: This is a digitally signed message part
Bug#990956: uploading lintian-brush to testing-proposed-updates
Hi Jelmer, On 11-07-2021 19:44, Jelmer Vernooij wrote: > Can I upload a small fix for lintian-brush to testing-proposed-updates to > allow > it to remain in testing? I just found out an old FTBFS bug is still affecting > it in testing, and there's a much newer version in unstable. That's not why we have t-p-u. We really prefer you to revert the new upstream release in unstable (using e.g. +really version number). See also our FAQ [1]. Paul [1] https://release.debian.org/bullseye/FAQ.html OpenPGP_signature Description: OpenPGP digital signature
Bug#990939: unblock: newlisp/10.7.5-2
On Sunday, July 11 2021, Adrian Bunk wrote: > Please unblock package newlisp > > * d/p/0009-Fix-shared-library-loading-for-modules.patch: > Adjust patch so that the modules don't try to load a versioned shared > library. > * d/control: Don't recommend hardcoded ABI versions in library packages. > We should recommend the '-dev' packages instead, which will install > the proper .so files that will get loaded by the modules. (Closes: > #984686) > * d/p/0009-Set-NEWLISPDIR-to-usr-share-newlisp.patch: > Inform newlisp that the common files are installed under > /usr/share/newlisp, not /usr/local/share. > (changes by Sergio Durigan Junior) Thanks for request the unblock on this one. > Depending on the -dev packages instead is not nice, > but it is actually the fix with the smallest change. I'm open to suggestions here. A small correction: the package doesn't depend on the -dev packages; it recommends them. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Bug#990954: kodi: crashes on older hardware
Hi Vasyl! There does not seem to exist a package containing i915_drv_video.so according to https://packages.debian.org/search?mode=path=bullseye=all=any=contents=i915_drv_video.so Only i965_drv_video.so is available from the package i965-va-driver. From what I found on the net it's about video acceleration which is not available for the i915 driver. I will install gdb & kodi-bin-dbgsym to come back to you with more logs soon. Sven On Sun, 2021-07-11 at 17:49 +, Vasyl Gello wrote: > Hi Sven! > > Does the problem go away if you put missing /usr/lib/i386-linux- > gnu/dri/i915_drv_video.so file in place by installing package or > copying manually? > Also, please install gdb & kodi-bin-dbgsym from debian-debug repo and > reproduce issue again to get a proper stacktrace. > > I can rebuild the deb package with debuginfo (DWO CU files) to get > more insights like internal variables etc. > -- > Vasyl Gello > == > Certified SolidWorks Expert > > Mob.:+380 (98) 465 66 77 > > E-Mail: vasek.ge...@gmail.com > > Skype: vasek.gello > == > 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 -- GPG Fingerprint 3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585 signature.asc Description: This is a digitally signed message part
Bug#990959: ITP: scep -- SCEP server and client written in go
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: scep Version : 2.0.0-1 Upstream Author : MicroMDM * URL : https://github.com/micromdm/scep * License : Expat Programming Lang: Go Description : SCEP server and client written in go Binaries and library files for Simple Certificate Enrollment Protocol client and server Source package of this project is needed for step-ca (#990946)
Bug#990958: ITP: npinv -- finds inversions in long DNA segments post alignment
Package: wnpp Severity: wishlist Subject: ITP: npinv -- finds inversions in long DNA segments post alignment Package: wnpp Owner: Steffen Moeller Severity: wishlist * Package name: npinv Version : 1.24+ds Upstream Author : haojingshao * URL : https://github.com/haojingshao/npInv/ * License : MIT Programming Lang: Java Description : finds inversions in long DNA segments post alignment npInv accurately detects and genotypes inversions using multiple alignment long reads. Remark: This package is maintained by Steffen Moeller at https://salsa.debian.org/med-team/npinv
Bug#990957: unblock: pam/1.4.0-9
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: vor...@debian.org, henr...@debian.org
Please unblock package pam
(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)
[ Reason ]
As part of refreshing patches for PAM 1.4.0, we accidentally disabled support
for the non-multiarch path for /lib/security. This patch brings back support
for loading pam modules in /lib/security.
[ Impact ]
At a minimum, the following pam-modules will be completely ineffective
and will do nothing if installed:
libpam-apparmor: /lib/security/pam_apparmor.so
libpam-barada: /lib/security/pam_barada.so
libpam-biometric: /lib/security/pam_biometric.so
libpam-blue: /lib/security/pam_blue.so
libpam-freerdp2: /lib/security/pam_freerdp2.so
libpam-otpw: /lib/security/pam_otpw.so
libpam-pgsql: /lib/security/pam_pgsql.so
libpam-shield: /lib/security/pam_shield.so
libpam-slurm: /lib/security/pam_slurm.so
libpam-slurm-adopt: /lib/security/pam_slurm_adopt.so
libpam-tacplus: /lib/security/pam_tacplus.so
libpam-x2go: /lib/security/pam_x2go.so
libpam-yubico: /lib/security/pam_yubico.so
virtualbox-guest-utils: /lib/security/pam_vbox.so
[ Tests ]
PAM has no automated tests at the packaging level.
I confirmed without the patch that libpam-yubico failed to load and that with
the patch libpam-yubico didn't give a module load error.
I did not properly configure and test libpam-yubico.
I confirmed that even with the patch, /lib/security/pam_unix.so does not mask
/lib/x86_64-linux-gnu/security/pam_unix.so
[ Risks ] The patch looks relatively simple, it's been reviewed by
myself and by the person who submitted it. Even so, PAM is an
essential package, and if you take a look at the changelog for -9,
it's possible to get even a patch this simple wrong.
However, that's a lot of pam modules to have a grave your module doesn't work
at all bug.
If you do grant the unblock, please add aging hints so the new PAM makes it in.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[] attach debdiff against the package in testing
[ Other info ]
(Anything else the release team should know.)
unblock pam/1.4.0-9
diff --git a/debian/changelog b/debian/changelog
index 03358422..dee3f32b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,36 @@
+pam (1.4.0-9) unstable; urgency=medium
+
+ * Revert prefer the multiarch path from 1.4.0-8: It turns out that
+Debian uses DEFAULT_MODULE_PATH and _PAM_ISA in the opposite meaning
+of upstream. If I had read the patch header of
+patches-applied/lib_security_multiarch_compat more closely I would
+have noticed this. The effect of 1.4.0-9 is what is stated in the
+1.4.0-8 changelog: we prefer multiarch paths, but the original patch
+did that.
+ * I did test this in 1.4.0-8, but my test design was flawed. I placed a
+invalid shared object in /lib/security and confirmed it did not shadow
+an object in /lib/x86_64-linux-gnu/security. However I realized
+shortly after releasing 1.4.0-8 that a valid shared object in
+/lib/security will shadow one in the multiarch path.
+
+ -- Sam Hartman Fri, 09 Jul 2021 10:55:02 -0600
+
+pam (1.4.0-8) unstable; urgency=high
+
+ [ Hideki Yamane ]
+ * debian/patches-applied/lib_security_multiarch_compat
+- Fix regression introduced in 1.4.0-1: search both /lib/security and
+/lib/[multiarch_tripple]/security/, Closes: #990790
+
+ [ Sam Hartman ]
+ * Reword changelog
+ * Prefer the multiarch path (_PAM_ISA) to the non-multiarch path.
+That's different than buster, but guarantees everything already
+working in bullseye will continue to work and also guarantees that
+when multiarch modules are available we use them.
+
+ -- Hideki Yamane Tue, 06 Jul 2021 22:09:15 +0900
+
pam (1.4.0-7) unstable; urgency=medium
* Updated portuguese debconf translation, thanks Pedro Ribeiro, Closes:
diff --git a/debian/patches-applied/lib_security_multiarch_compat
b/debian/patches-applied/lib_security_multiarch_compat
index c43a733e..e386ff39 100644
--- a/debian/patches-applied/lib_security_multiarch_compat
+++ b/debian/patches-applied/lib_security_multiarch_compat
@@ -11,11 +11,11 @@ currently abusing the existing variables and inverting
their meaning in
order to get everything installed where we want it and get absolute paths
the way we want them.
-Index: pam/libpam/pam_handlers.c
+Index: pam-1.4.0/libpam/pam_handlers.c
===
pam.orig/libpam/pam_handlers.c
-+++ pam/libpam/pam_handlers.c
-@@ -735,7 +735,18 @@
+--- pam-1.4.0.orig/libpam/pam_handlers.c
pam-1.4.0/libpam/pam_handlers.c
+@@ -735,7 +735,27 @@ _pam_load_module(pam_handle_t *pamh, con
success = PAM_ABORT;
D(("_pam_load_module:
Bug#990954: kodi: crashes on older hardware
Hi Sven! Does the problem go away if you put missing /usr/lib/i386-linux-gnu/dri/i915_drv_video.so file in place by installing package or copying manually? Also, please install gdb & kodi-bin-dbgsym from debian-debug repo and reproduce issue again to get a proper stacktrace. I can rebuild the deb package with debuginfo (DWO CU files) to get more insights like internal variables etc. -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#990956: uploading lintian-brush to testing-proposed-updates
Package: release.debian.org Severity: important Hi release team, Can I upload a small fix for lintian-brush to testing-proposed-updates to allow it to remain in testing? I just found out an old FTBFS bug is still affecting it in testing, and there's a much newer version in unstable. The bug in question is https://bugs.debian.org/988909 Thanks, Jelmer
Bug#990955: unblock: mstch/1.0.2-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mstch
[ Reason ]
Fixes release-critical bug 951647.
[ Impact ]
No packages in Debian depend on this library, but it would cause libmstch-dev
to be removed from Buster, preventing people from installing it.
[ Tests ]
Manual test has been done to confirm that the bugs have been fixed.
[ Risks ]
The change is trivial, and consists of moving a CMake configuration file
into an arch-specific directory where it belongs.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock mstch/1.0.2-3
diff -Nru mstch-1.0.2/debian/changelog mstch-1.0.2/debian/changelog
--- mstch-1.0.2/debian/changelog2018-01-03 00:35:05.0 +0100
+++ mstch-1.0.2/debian/changelog2021-07-11 14:18:54.0 +0200
@@ -1,3 +1,12 @@
+mstch (1.0.2-3) unstable; urgency=medium
+
+ * Bump Standards-Version.
+ * Add Rules-Requires-Root: no.
+ * Fix installation directory for the CMake configuration file.
+Closes: #951647, #897342
+
+ -- Guus Sliepen Sun, 11 Jul 2021 14:18:54 +0200
+
mstch (1.0.2-2) unstable; urgency=medium
* Fix grammar in debian/control.
diff -Nru mstch-1.0.2/debian/control mstch-1.0.2/debian/control
--- mstch-1.0.2/debian/control 2018-01-03 00:33:44.0 +0100
+++ mstch-1.0.2/debian/control 2018-01-09 19:32:09.0 +0100
@@ -2,9 +2,10 @@
Priority: optional
Maintainer: Guus Sliepen
Build-Depends: debhelper (>= 10), cmake (>= 3.0), libboost-dev (>= 1.54)
-Standards-Version: 4.1.2
+Standards-Version: 4.1.3
Section: libs
Homepage: https://github.com/no1msd/mstch
+Rules-Requires-Root: no
Package: libmstch-dev
Section: libdevel
diff -Nru mstch-1.0.2/debian/patches/fix-lib-dir
mstch-1.0.2/debian/patches/fix-lib-dir
--- mstch-1.0.2/debian/patches/fix-lib-dir 2018-01-02 16:59:55.0
+0100
+++ mstch-1.0.2/debian/patches/fix-lib-dir 2021-07-11 14:17:41.0
+0200
@@ -11,7 +11,7 @@
install(
FILES "${PROJECT_SOURCE_DIR}/include/mstch/mstch.hpp"
-@@ -55,7 +55,7 @@
+@@ -55,10 +55,10 @@
EXPORT mstchTargets
FILE mstch-targets.cmake
NAMESPACE mstch::
@@ -20,3 +20,7 @@
install(FILES
"${PROJECT_SOURCE_DIR}/cmake/mstch-config.cmake"
+ "${CMAKE_CURRENT_BINARY_DIR}/mstch/mstch-config-version.cmake"
+-DESTINATION lib/cmake/mstch
++DESTINATION lib/${CMAKE_LIBRARY_PATH}/cmake/mstch
+ COMPONENT Devel)
Bug#990954: kodi: crashes on older hardware
Package: kodi Version: 2:19.1+dfsg2-2 Severity: normal Dear Maintainer, Kodi crashes on my 1st generation intel-based Mac mini with trying to access the non-existent file /usr/lib/i386-linux-gnu/dri/i915_drv_video.so. This happened after having upgraded the system from Buster to Bullseye. Pinning Kodi and its dependencies to the version in Buster circumvents the issue for me. .xsession-errors log shows: Xsession: X session started for kodi at So 11. Jul 18:48:29 CEST 2021 WARNING: tempfile is deprecated; consider using mktemp instead. dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus dbus-update-activation-environment: setting DISPLAY=:0 dbus-update-activation-environment: setting XAUTHORITY=/home/kodi/.Xauthority localuser:kodi being added to access control list libva info: VA-API version 1.10.0 libva info: Trying to open /usr/lib/i386-linux-gnu/dri/i915_drv_video.so libva info: va_openDriver() returns -1 Segmentation fault Crash report available at /home/kodi/kodi_crashlog-20210711_184843.log Kodi crash log shows: ## Kodi CRASH LOG ### SYSTEM INFO Date: Sun Jul 11 18:48:43 CEST 2021 Kodi Options: Arch: i686 Kernel: Linux 5.10.0-7-686-pae #1 SMP Debian 5.10.40-1 (2021-05-28) Release: Debian GNU/Linux 11 (bullseye) ## END SYSTEM INFO ## ### STACK TRACE # gdb not installed, can't get stack trace. # END STACK TRACE ### # LOG FILE ## 2021-07-11 18:48:39.139 T:916 INFO : --- 2021-07-11 18:48:39.139 T:916 INFO : Starting Kodi from Debian (19.1 Debian package version: 2:19.1+dfsg2-2). Platform: Linux x86 32-bit 2021-07-11 18:48:39.139 T:916 INFO : Using Release Kodi from Debian x32 2021-07-11 18:48:39.139 T:916 INFO : Kodi from Debian compiled 2021-06-24 by GCC 10.2.1 for Linux x86 32-bit version 5.10.46 (330286) 2021-07-11 18:48:39.139 T:916 INFO : Running on Debian GNU/Linux 11 (bullseye), kernel: Linux x86 32-bit version 5.10.0-7-686-pae 2021-07-11 18:48:39.139 T:916 INFO : FFmpeg version/source: 4.3.2-0+deb11u2 2021-07-11 18:48:39.139 T:916 INFO : Host CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz, 2 cores available 2021-07-11 18:48:39.139 T:916 INFO : special://xbmc/ is mapped to: /usr/share/kodi 2021-07-11 18:48:39.139 T:916 INFO : special://xbmcbin/ is mapped to: /usr/lib/i386-linux-gnu/kodi 2021-07-11 18:48:39.139 T:916 INFO : special://xbmcbinaddons/ is mapped to: /usr/lib/i386-linux-gnu/kodi/addons 2021-07-11 18:48:39.140 T:916 INFO : special://masterprofile/ is mapped to: /home/kodi/.kodi/userdata 2021-07-11 18:48:39.140 T:916 INFO : special://envhome/ is mapped to: /home/kodi 2021-07-11 18:48:39.140 T:916 INFO : special://home/ is mapped to: /home/kodi/.kodi 2021-07-11 18:48:39.140 T:916 INFO : special://temp/ is mapped to: /home/kodi/.kodi/temp 2021-07-11 18:48:39.140 T:916 INFO : special://logpath/ is mapped to: /home/kodi/.kodi/temp 2021-07-11 18:48:39.140 T:916 INFO : The executable running is: /usr/lib/i386-linux-gnu/kodi/kodi.bin 2021-07-11 18:48:39.140 T:916 INFO : Local hostname: macmini 2021-07-11 18:48:39.140 T:916 INFO : Log File is located: /home/kodi/.kodi/temp/kodi.log 2021-07-11 18:48:39.140 T:916 INFO : --- 2021-07-11 18:48:39.171 T:916 INFO : loading settings 2021-07-11 18:48:39.186 T:916 INFO : special://profile/ is mapped to: special://masterprofile/ 2021-07-11 18:48:39.191 T:916 WARNING : missing version attribute 2021-07-11 18:48:39.213 T:916 WARNING : unable to read value of setting "videolibrary.showunwatchedplots" 2021-07-11 18:48:39.213 T:916 WARNING : unable to read value of setting "videoplayer.autoplaynextitem" 2021-07-11 18:48:39.213 T:916 INFO : No settings file to load (special://xbmc/system/advancedsettings.xml) 2021-07-11 18:48:39.214 T:916 INFO : No settings file to load (special://masterprofile/advancedsettings.xml) 2021-07-11 18:48:39.214 T:916 INFO : Default Video Player: VideoPlayer 2021-07-11 18:48:39.214 T:916 INFO : Default Audio Player: paplayer 2021-07-11 18:48:39.214 T:916 INFO : Disabled debug logging due to GUI setting. Level 0. 2021-07-11 18:48:39.214 T:916 INFO : Log
Bug#990950: Question about packaging a Lisp image
Hello! I would like to package bergman [1], a Common Lisp program for computations in noncommutative algebra. Upstream's build script creates an executable by generating an image with SAVEINITMEM. However, in order for some of the features of bergman to work properly, the source files must be present, and in the same location as they were during build time, at runtime. So generating the image while building the binary package won't work, as then at runtime we'd be looking for some non-existent directory from the buildd machines. (Not to mention the reproducibility issues from having these paths hardcoded in the image!) One solution that I've come up with is to just have the Debian package install the necessary source files, and then have the postinst script run the upstream build script and generate the image right there on the user's system as part of the installation process. I'm very new to Common Lisp, so I'm not sure if this is the best strategy. Is there another method that would be recommended instead? Thanks! Doug [1] https://bugs.debian.org/990950 signature.asc Description: PGP signature
Bug#990940: release-notes: wpewebkit to be covered by security support in bullseye
Alberto Garcia wrote:
> Debian provides security support for the WebKitGTK browser engine
> (source package: webkit2gtk). For bullseye we also want to support
> wpewebkit, which is developed by the same team, follows a very similar
> release schedule and numbering system, shares most of the code and
> almost all CVEs fixes apply to both ports.
>
> See #990754 for more details.
Buster users reading this ought to be able to work out that "uses
webkit2gtk" means "Depends: libwebkit2gtk-X.Y-Z", but wpewebkit is
more obscure: nobody preparing a dist-upgrade is going to learn
anything about it with APT searches on buster. Can we add some hint
that it's new in bullseye?
> I'm attaching a patch for the release notes.
> diff --git a/en/issues.dbk b/en/issues.dbk
> index 5f177f54..9fb6861d 100644
> --- a/en/issues.dbk
> +++ b/en/issues.dbk
> @@ -483,12 +483,13 @@ data =
> ${lookup{$local_part}lsearch{/some/path/$domain_data/aliases}}
> source packages and the concern applies to all packages shipping
> them. The concern also extends to web rendering engines not explicitly
> mentioned here, with the exception of - role="source">webkit2gtk. are included
> in
> - , but not
> - covered by security support. These browsers should not be used against
> - untrusted websites.
> - The webkit2gtk source package
> is
> - covered by security support.
> + role="source">webkit2gtk and + role="source">wpewebkit. are included
> in
> + , but not covered by security support. These
> + browsers should not be used against untrusted websites.
> + The webkit2gtk and
> + wpewebkit source
> + packages are covered by security support.
>
>
> For general web browser use we recommend Firefox or Chromium.
If we can refer to "webkit" and "khtml" (in the previous line) and
"Firefox" and "Chromium" (below) without special markup, it's not
clear why we need make such a big deal about "*webkit2gtk*" and
"*wpewebkit*" being source package names. I would suggest just:
mentioned here, with the exception of webkit2gtk and
the new wpewebkit. are included in
, but not covered by security support. These
browsers should not be used against untrusted websites.
The webkit2gtk and wpewebkit engines
are covered by security support.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Bug#990953: lxml: reproducible-builds: Set locale to ensure html documentation is reproducible
Source: lxml Severity: minor Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: locale X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Various .html files generated in the documentation have different results depending on the (potentially obscure) locale used in reprotest. ./usr/share/doc/python-lxml/html/index.html https://mailman-mail5.webfaction.com/pipermail/lxml/200\ 80131/019119.html"> lxml takes all the pain out of XML. vs. https://mailman-mail5.webfaction.com/pipermail/lxml/200\ 80131/019119.html"> lxml takes all the pain out of XML. The attached patch sets the LC_ALL and LANG environment variables from debian/rules to ensure the C.UTF-8 locale is used. Thanks for maintaining lxml! live well, vagrant From b3bf97844053add891129e119cc66b5af3eb5016 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sun, 11 Jul 2021 17:00:21 + Subject: [PATCH 2/2] debian/rules: Set LC_ALL and LANG to C.UTF-8 to avoid reproducibility issues when generating html documentation. --- debian/rules | 4 1 file changed, 4 insertions(+) diff --git a/debian/rules b/debian/rules index db5abad..466e936 100755 --- a/debian/rules +++ b/debian/rules @@ -9,6 +9,10 @@ PY3VER := $(shell py3versions -vd) UPSTREAMVER := $(subst lxml-,,$(notdir $(CURDIR))) +# Some locales trigger reproducibility issues in html documentation +export LC_ALL=C.UTF-8 +export LANG=C.UTF-8 + include /usr/share/python3/python.mk prebuild: prebuild-stamp -- 2.32.0 signature.asc Description: PGP signature
Bug#990867: shim-helpers-arm64-signed: post-install script fails with 'error exit status 1'
On zondag 11 juli 2021 17:42:27 CEST Steve McIntyre wrote: > >If an error is detected, a message like "Look at this wiki page for > >possible solutions", with the solution you just provided me (among others), > >would be really helpful. > >I've made/attached screenshots which could be used for that. > > I'm adding an extra section to https://wiki.debian.org/UEFI right now, > at least. Great :-) But IMO it's also important to point to that when it fails. "shim-helpers-arm64-signed package post-installation script subprocess returned error exit status 1" is not a helpful error message for most people. I was wondering whether the 'real' problem was in that package or in an efi package or in grub(-*?) or in the kernel (evivars) or yet something else. Or a combination of those. > >> 2. To the best of my knowledge, none of the current U-Boot releases > >> support Secure Boot so you may as well remove the shim-signed > >> package anyway. It's normally harmless to include it (so we pull > >> it in via recommends), but on your system it's not going to do > >> anything for you so you may as well remove it. > > > >It may have prevented me seeing this issue, but others would likely have > >encountered it anyway. One of the reasons I run Sid is encountering issues > >and finding a fix, so others won't have to. So I'm keeping it for now. > Fair enough. You *should* be getting the same error message without > shim being involved, though. Any update to the various grub-efi > packages will end up calling grub-install, with the same results. ACK > Have you not been seeing that? Maybe I have, but I didn't realize it. I didn't know what caused the previous time I got this error and it was a 'random' command (or a lucky sequence of commands) that made the error go away. Assuming/Hoping it was a one time thing, I didn't investigate further. But when I encountered it a second time, I felt I needed to report it. Not knowing what caused it and not (really) knowing what fixed it, makes it hard to make connections. Now that I know it is/was caused by grub-install I can/will look out for that and that'll make me recognize patterns. Thanks, Diederik signature.asc Description: This is a digitally signed message part.
Bug#990952: lxml: reproducible builds: Embedded timestamps in html documentation
Source: lxml Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The build timestamp is embedded in various html documentation: https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/lxml.html ./usr/share/doc/python-lxml/html/FAQ.html Generated·on:·2022-08-12. vs. Generated·on:·2021-07-10. The attached patch fixes this by adjusting the rst2html arguments to use --no-datestamp instead of --date in doc/mkhtml.py. This patch does not fix all reproducibility issues in lxml (e.g. build paths), but with this patch applied, lxml should become reproducible again on the tests.reproducible-builds.org in the testing suite. Thanks for maintaining lxml! live well, vagrant From ce24e7825f1da92b91704ef13ba337de917165b3 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sun, 11 Jul 2021 16:39:05 + Subject: [PATCH] doc/mkhtml.py: Do not embed timestamps in html documentation. --- doc/mkhtml.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/mkhtml.py b/doc/mkhtml.py index c652335..3542ba7 100644 --- a/doc/mkhtml.py +++ b/doc/mkhtml.py @@ -19,7 +19,7 @@ RST2HTML_OPTIONS = " ".join([ '--no-toc-backlinks', '--strip-comments', '--language en', -'--date', +'--no-datestamp', ]) XHTML_NS = 'http://www.w3.org/1999/xhtml' -- 2.20.1 signature.asc Description: PGP signature
Bug#990580: debdiff for NMU apache2 (= 2.4.48-3.1) (was Re: Bug#990580: apache2: [regression] daily cron mails from logrotate: Reloading Apache httpd web server: apache2., caused by #979813)
On Sun, 11 Jul 2021, Adam Borowski wrote: > I for one believe the old behaviour was superior for the common case of > "success" -- no news is good news No disagreement from here. We could do things like… output=$(command 2>&1; echo $? >tempfile) case $(cat tempfile 2>&1) in (0) ;; (*) printf >&2 '%s\n' "$output" ;; esac … but… > • three weeks before the release is no time for such meddling … precisely this. > • it should be coded in sysv-rc/runit/etc instead of every daemon Nope. This is out of the scope of init systems. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Bug#990678: budgie-desktop: Software windows don't display correctly, move badly or stay on the screen after being shut
Package: budgie-desktop Version: 10.5.2-3 Followup-For: Bug #990678 X-Debbugs-Cc: pascal.mart...@gmx.fr Dear Maintainer, I tried MPV in several other (simple) desktop/window managers : i3, Jwm and Openbox. As I said before, our bug about the MPV window (just) seems quite linked/related to this brief defect/blinking you can see in the upper part of the MPV window just after going fullscreen. So first I tried MPV in Gnome (plain or Xorg), and this MPV screen defect appears everytime, like in Budgie. But it doesn't appear in Gnome Wayland. The window connects to fullscreen quite cleanly and remains so. The aspect of the window is different (no GUI title bar) by the way. And interestingly, neither does it appear in the simple WMs (i3, Jwm, Openbox). The MPV window is quite clean, no defect, good fullscreen connection. Of course in i3 (tiled WM), you can't move the MPV window with the mouse. About MPV in Gnome, I remarked too that the video image is rather long to launch (at least since Debian 10, not a new problem). This you can notice only with a rather slow PC like mine I think. When launching a video, you can always hear the sound 1 or 2 seconds before seeing the image. You even have to go back when the very beginning is important. In other WMs, MPV is launched instantly. On the contrary, in all WMs this time, since Debian 11, Gedit has become very long to close. Hoping all this rings a bell and brings some light. Cordially, Pascal. -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads) 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages budgie-desktop depends on: ii budgie-core 10.5.2-3 ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii gir1.2-budgie-1.010.5.2-3 ii gnome-control-center 1:3.38.4-1 ii gnome-menus 3.36.0-1 ii network-manager-gnome1.20.0-3 Versions of packages budgie-desktop recommends: ii budgie-desktop-view 1.1.1-1 Versions of packages budgie-desktop suggests: ii gnome-terminal 3.38.3-1 ii nautilus3.38.2-1 pn slick-greeter
Bug#990585: frr: diff for NMU version 7.5.1-1.1
Control: tags 990585 + patch
Control: tags 990585 + pending
Dear maintainer,
I've prepared an NMU for frr (versioned as 7.5.1-1.1) and uploaded
it to DELAYED/2. Please feel free to tell me if I should cancel it.
cu
Adrian
diff -Nru frr-7.5.1/debian/changelog frr-7.5.1/debian/changelog
--- frr-7.5.1/debian/changelog 2021-03-08 10:40:19.0 +0200
+++ frr-7.5.1/debian/changelog 2021-07-11 19:15:04.0 +0300
@@ -1,3 +1,11 @@
+frr (7.5.1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport upstream fix for compatibility with the bullseye
+libyang1. (Closes: #990585)
+
+ -- Adrian Bunk Sun, 11 Jul 2021 19:15:04 +0300
+
frr (7.5.1-1) unstable; urgency=medium
* Update the d/gbp.conf for 7.5.1 release
diff -Nru frr-7.5.1/debian/patches/0001-yang-fix-zebra-module.patch frr-7.5.1/debian/patches/0001-yang-fix-zebra-module.patch
--- frr-7.5.1/debian/patches/0001-yang-fix-zebra-module.patch 1970-01-01 02:00:00.0 +0200
+++ frr-7.5.1/debian/patches/0001-yang-fix-zebra-module.patch 2021-07-11 18:41:30.0 +0300
@@ -0,0 +1,71 @@
+From 7573cb86a259d3c9ef6eae9dd5d529f8080922cd Mon Sep 17 00:00:00 2001
+From: Igor Ryzhov
+Date: Thu, 22 Apr 2021 12:48:19 +0300
+Subject: yang: fix zebra module
+
+Fixes: #8521
+Signed-off-by: Igor Ryzhov
+---
+ yang/frr-zebra.yang | 14 +++---
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/yang/frr-zebra.yang b/yang/frr-zebra.yang
+index 2efc45c14..6b4be6591 100644
+--- a/yang/frr-zebra.yang
b/yang/frr-zebra.yang
+@@ -2184,8 +2184,8 @@ module frr-zebra {
+ + "/frr-route-map:match-condition"
+ + "/frr-route-map:condition-value" {
+ case ipv4-prefix-length {
+- when "./condition = 'ipv4-prefix-length' or
+-./condition = 'ipv4-next-hop-prefix-length'";
++ when "./frr-route-map:condition = 'ipv4-prefix-length' or
++./frr-route-map:condition = 'ipv4-next-hop-prefix-length'";
+ leaf ipv4-prefix-length {
+ type uint8 {
+ range "0..32";
+@@ -2193,7 +2193,7 @@ module frr-zebra {
+ }
+ }
+ case ipv6-prefix-length {
+- when "./condition = 'ipv6-prefix-length'";
++ when "./frr-route-map:condition = 'ipv6-prefix-length'";
+ leaf ipv6-prefix-length {
+ type uint8 {
+ range "0..128";
+@@ -2201,13 +2201,13 @@ module frr-zebra {
+ }
+ }
+ case source-protocol {
+- when "./condition = 'source-protocol'";
++ when "./frr-route-map:condition = 'source-protocol'";
+ leaf source-protocol {
+ type frr-route-types:frr-route-types;
+ }
+ }
+ case source-instance {
+- when "./condition = 'source-instance'";
++ when "./frr-route-map:condition = 'source-instance'";
+ leaf source-instance {
+ type uint8 {
+ range "0..255";
+@@ -,14 +,14 @@ module frr-zebra {
+ + "/frr-route-map:set-action"
+ + "/frr-route-map:action-value" {
+ case source-v4 {
+- when "./action = 'source'";
++ when "./frr-route-map:action = 'source'";
+ leaf source-v4 {
+ description "IPv4 address";
+ type inet:ipv4-address;
+ }
+ }
+ case source-v6 {
+- when "./action = 'source'";
++ when "./frr-route-map:action = 'source'";
+ leaf source-v6 {
+ description "IPv6 address";
+ type inet:ipv6-address;
+--
+2.20.1
+
diff -Nru frr-7.5.1/debian/patches/series frr-7.5.1/debian/patches/series
--- frr-7.5.1/debian/patches/series 1970-01-01 02:00:00.0 +0200
+++ frr-7.5.1/debian/patches/series 2021-07-11 19:15:01.0 +0300
@@ -0,0 +1 @@
+0001-yang-fix-zebra-module.patch
Bug#990951: RFS: sane-backends/1.0.32-3 -- API library for scanners
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "sane-backends": Package name: sane-backends Version : 1.0.32-3 Upstream Author : [fill in name and email of upstream] URL : http://www.sane-project.org License : Artistic, GPL-3+, GPL-2, GPL-2+, GPL-2+ with sane exception, GFDL-1.1, LGPL-2.1+ Vcs : https://jff.email/cgit/sane-backends.git Section : graphics It builds those binary packages: libsane - API library for scanners [transitional package] libsane-dev - API development library for scanners [development files] libsane1 - API library for scanners libsane-common - API library for scanners -- documentation and support files sane-utils - API library for scanners -- utilities To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sane-backends/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.32-3.dsc or from git https://jff.email/cgit/sane-backends.git?h=release%2Fdebian%2F1.0.32-3 Changes since the last upload: sane-backends (1.0.32-3) experimental; urgency=medium . * Fix use-after-free and two mem leaks: - New debian/patches/0180-gt68xx_fix_use-after-free_two_memleaks.patch. Cherry-picked from upstream (Closes: #980311). * Add some Debian files / directories into .gitignore. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype: joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#990950: ITP: bergman -- Groebner bases in commutative and non-commutative algebras
Package: wnpp Severity: wishlist Owner: Doug Torrance X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu * Package name: bergman Version : 1.001 Upstream Author : Joergen Backelin * URL : http://servus.math.su.se/bergman/ * License : Bergman General Public License Programming Lang: Common Lisp Description : Groebner bases in commutative and noncommutative algebras Bergman is a powerful tool to calculate Gröbner bases in commutative and non-commutative algebras, and in modules over them. It may also be used to calculate some invariants of algebras and modules: the Hilbert series, and (in the non-commutative case) the Poincaré-Betti series, the Anick resolution, and the Betti numbers. The most important feature of bergman are computations both in non-commutative and commutative cases. It also permits degree-wise output of results; thus it may save partial results from calculations close to or beyond the limit for calculations of entire Gröbner bases with present-day computer strength. This saves for the user partial results even the problem overheads the strength of the computer. Bergman offers the user a high level of flexibiliy. Among the alternatives for ring set-ups are: commutativity or non-commutativity; various strategies of Gröbner basis computation; a few different monomial orderings; and various coefficient fields. The set-up may be changed interactively during the session. Most calculations can be done both for ideals and modules. In the Reduce version it is possible to include indeterminates (with or without declared reduction rules) as coefficients for the commutative computations; otherwise the coefficient field should be a prime field. Bergman is written in Standard Lisp, the Lisp dialect underlying Reduce implementations. There is also available an experimentative Common Lisp version.Therefore, bergman works under Reduce, PSL or Common Lisp (at least one of them should be pre-installed), and commands are written in respect to Reduce or Lisp syntax. Bergman is a dependency of the Macaulay2 package "NCAlgebra" for working with noncommutative algebras. I intend to maintain it under the umbrella of the Debian Science Team.
Bug#990867: shim-helpers-arm64-signed: post-install script fails with 'error exit status 1'
On Sun, Jul 11, 2021 at 04:39:20PM +0200, Diederik de Haas wrote: >On zondag 11 juli 2021 02:31:19 CEST Steve McIntyre wrote: >> >> AFAICS grub-install is failing to update due to the *real* underlying >> problem, which is that your platform is running firmware which >> implements UEFI but that UEFI support isn't working for writing UEFI >> boot variables. You're using U-Boot, I assume? > >Yes, u-boot-rockchip to be exact. The base image for my rock64 is made using >the .yaml file from https://salsa.debian.org/diederik/rock64 > >> So, here's a few thoughts: >> >> 1. To stop your machine failing here, do a "dpkg-reconfigure >> grub-efi-arm64" and say "yes" to the removable media path question >> and "no" to the "update boot variables" question. That should >> solve the immediate problem for you - please shout if it doesn't! > >Yeah! That fixed it, thanks :-) \o/ >> Fixing this in the *general* case is hard. We could add code to >> fall back to *not* updating UEFI boot variables if that fails, but >> that's likely going to be error-prone and cause trouble on >> machines where that *should* work but it fails on a temporary >> basis. Instead, I suspect we may need to replicate similar >> functionality to flash-kernel and have a list of "quirky" machines >> where we *don't* expect UEFI boot variables to work. That's messy as >> all hell, but I'm not sure of a better option. :-/ > >There was recently a thread on debian-arm ML about questions to ask to ARM and >the general trend was "can we please get some (more) uniformity?". >So I can understand that fixing it in code could be (extremely) hard. Yes, I saw and chipped in on the thread. :-) >What can be improved is the error message. >If I may say so myself, in running Sid for 10+ years I've gotten pretty decent >at finding the cause of an issue and then finding a fix. But at this problem I >was at a loss. Twice. (not knowing much about EFI probably doesn't >help). ACK. >If an error is detected, a message like "Look at this wiki page for >possible solutions", with the solution you just provided me (among others), >would be really helpful. >I've made/attached screenshots which could be used for that. I'm adding an extra section to https://wiki.debian.org/UEFI right now, at least. >> 2. To the best of my knowledge, none of the current U-Boot releases >> support Secure Boot so you may as well remove the shim-signed >> package anyway. It's normally harmless to include it (so we pull >> it in via recommends), but on your system it's not going to do >> anything for you so you may as well remove it. > >It may have prevented me seeing this issue, but others would likely have >encountered it anyway. One of the reasons I run Sid is encountering issues and >finding a fix, so others won't have to. So I'm keeping it for now. Fair enough. You *should* be getting the same error message without shim being involved, though. Any update to the various grub-efi packages will end up calling grub-install, with the same results. Have you not been seeing that? -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183
Bug#990949: libapache2-mod-php7.3 package post-installation script subprocess returned error exit status 1
Package: libapache2-mod-php7.3
Version: 7.3.29-1~deb10u1
Severity: normal
Dear Maintainer,
the postinst script for libapache2-mod-php7.3 errors out with:
Setting up libapache2-mod-php7.3 (7.3.29-1~deb10u1) ...
dpkg: error processing package libapache2-mod-php7.3 (--configure):
installed libapache2-mod-php7.3 package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
libapache2-mod-php7.3
Adding "set -x" to /var/lib/dpkg/info/libapache2-mod-php7.3.postinst reveals:
[...]
+ a2query -m php7.3
+ a2query_ret=1
+ [ 1 -eq 0 ]
+ [ 1 -eq 32 ]
+ APACHE2_NEED_ACTION=1
+ a2enmod -m -q php7.3
+ return 1
+ exit 1
dpkg: error processing package libapache2-mod-php7.3 (--configure):
installed libapache2-mod-php7.3 package post-installation script subprocess
returned error exit status 1
So, it tries to enable a module called "php7.3" while no such module exists.
The module "php7" does exist and is already active, and is in fact PHP,
version 7.3. Replacing "7.3" with "7" in the postinst script does the trick
and libapache2-mod-php7.3 can be configured correctly.
--- /var/lib/dpkg/info/libapache2-mod-php7.3.postinst.orig 2021-07-11
17:07:22.070644622 +0200
+++ /var/lib/dpkg/info/libapache2-mod-php7.3.postinst 2021-07-11
17:07:43.908380789 +0200
@@ -7,7 +7,7 @@
php_enable() {
local a2query_ret=0
- a2query -m "php7.3" > /dev/null 2>&1 || a2query_ret=$?
+ a2query -m "php7" > /dev/null 2>&1 || a2query_ret=$?
if [ "$a2query_ret" -eq 0 ] ; then
apache2_msg "info" "$DPKG_MAINTSCRIPT_PACKAGE: not switching MPM -
already enabled"
return 1
@@ -17,8 +17,8 @@
fi
PHP_MODULE=$(a2query -m | sed -n 's/^\(php[\.0-9]*\) (enabled.*)/\1/p')
-if [ -n "$PHP_MODULE" -a "$PHP_MODULE" != "php7.3" ]; then
- apache2_msg "err" "$DPKG_MAINTSCRIPT_PACKAGE: $PHP_MODULE module
already enabled, not enabling PHP 7.3"
+if [ -n "$PHP_MODULE" -a "$PHP_MODULE" != "php7" ]; then
+ apache2_msg "err" "$DPKG_MAINTSCRIPT_PACKAGE: $PHP_MODULE module
already enabled, not enabling PHP 7"
return 1
fi
@@ -27,7 +27,7 @@
prefork|itk) return 0;;
*) if apache2_switch_mpm prefork; then return 0; fi;;
esac
-apache2_msg "err" "$DPKG_MAINTSCRIPT_PACKAGE: Could not switch to
prefork MPM, not enabling PHP 7.3"
+apache2_msg "err" "$DPKG_MAINTSCRIPT_PACKAGE: Could not switch to
prefork MPM, not enabling PHP 7"
return 1
}
*** End of the template - remove these template lines ***
-- Package-specific info:
Additional PHP 7.3 information
PHP 7.3 SAPI (php7.3query -S):
PHP 7.3 Extensions (php7.3query -M -v):
Configuration files:
[PHP]
engine = On
short_open_tag = Off
precision = 14
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = -1
disable_functions =
pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,
disable_classes =
zend.enable_gc = On
expose_php = Off
max_execution_time = 30
max_input_time = 60
memory_limit = 128M
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
html_errors = On
variables_order = "GPCS"
request_order = "GP"
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 8M
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
default_charset = "UTF-8"
doc_root =
user_dir =
enable_dl = Off
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 20
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60
[CLI Server]
cli_server.color = On
[Date]
[filter]
[iconv]
[imap]
[intl]
[sqlite3]
[Pcre]
[Pdo]
[Pdo_mysql]
pdo_mysql.default_socket=
[Phar]
[mail function]
SMTP = localhost
smtp_port = 25
mail.add_x_header = Off
[ODBC]
odbc.allow_persistent = On
odbc.check_persistent = On
odbc.max_persistent = -1
odbc.max_links = -1
odbc.defaultlrl = 4096
odbc.defaultbinmode = 1
[Interbase]
ibase.allow_persistent = 1
ibase.max_persistent = -1
ibase.max_links = -1
ibase.timestampformat = "%Y-%m-%d %H:%M:%S"
ibase.dateformat = "%Y-%m-%d"
ibase.timeformat = "%H:%M:%S"
[MySQLi]
mysqli.max_persistent = -1
mysqli.allow_persistent = On
mysqli.max_links = -1
Bug#990948: ITP: golang-github-thales-e-security-pool -- Collection of packages from Vitess
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-github-thales-e-security-pool Version : 0.0.2-1 Upstream Author : Thales eSecurity * URL : https://github.com/thales-e-security/pool * License : Apache-2.0 Programming Lang: Go Description : Collection of packages from Vitess This package exposes the resource pool implementation and some of the atomic types. from https://github.com/vitessio/vitess. Vitess has some useful Go packages, however they are not versioned with Go modules, which causes issues (e.g. https://github.com/ThalesIgnite/crypto11/issues/56). They are also buried inside a large project, which forms a heavyweight dependency. This package is needed for #990947
Bug#990947: ITP: golang-github-thalesignite-crypto11 -- implementation of Golang crypto interfaces using PKCS#11 as a backend
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-github-thalesignite-crypto11 Version : 1.2.4-1 Upstream Author : Thales Ignite * URL : https://github.com/ThalesIgnite/crypto11 * License : Expat Programming Lang: Go Description : implementation of Golang crypto interfaces using PKCS#11 as a backend Dependency of step-ca (#990946)
Bug#990946: ITP: step-ca -- private certificate authority
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: step-ca Version : 0.16.0 Upstream Author : Smallstep * URL : https://github.com/smallstep/certificates * License : Apache-2.0 Programming Lang: Go Description : private certificate authority Source files are needed for Caddy (#810890)
Bug#990923: minetest-data: Crash in falling.lua
On Sun, Jul 11, 2021 at 03:31:03PM +1000, Craig Small wrote: > Package: minetest-data > Version: 5.3.0+repack-2 > Severity: normal > > Hi, > falling.lua has a bug where if param2 is not defined it crashes. > > > 2021-07-11 15:01:10: ERROR[Main]: ServerError: AsyncErr: ServerThread::run > Lua: Runtime error from mod '*builtin*' in callback luaentity_Activate(): > /usr/share/games/minetest/builtin/game/falling.lua:154: attempt to perform > arithmetic on field 'param2' (a nil value) > > I'm not sure why param2 is not defined but its a simple fix, see patch. The upstream fix is then likely https://github.com/minetest/minetest/commit/aba8c3753162320c7cc8a66913ad82f4f1fd0d8b I am neither maintainer nor user of this package, but it sounds like something that might be worth fixing for bullseye. > - Craig >... cu Adrian
Bug#990945: unblock: cog/0.10.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package cog
I filed a separate bug report (#990754) requesting to unblock
wpewebkit so it is up-to-date in order to provide security releases
for bullseye.
To that end and for the same reasons I would also like to request
the unblocking of cog, a simple, single-window web browser that
uses wpewebkit. Cog is the main user of WPE WebKit in Debian and is
developed by the same upstream team.
The reason why I think that it is interesting to have the latest
version in bullseye is its low risk (it has no reverse dependencies)
and the fact that it provides two additional platform plugins: DRM
(for the Linux Direct Rendering Manager) and headless (a plugin
that does not produce output and can be used without any graphics
hardware). The version currently in testing only supports Wayland
output.
See #990754 for more details.
unblock cog/0.10.0-2
diff --git a/debian/changelog b/debian/changelog
index beecb16..c8eaa3d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,28 @@
+cog (0.10.0-2) unstable; urgency=medium
+
+ * debian/control:
+- Build with libwpebackend-fdo-1.0-dev 1.10.0. This enables SHM buffer
+ exports.
+
+ -- Alberto Garcia Wed, 16 Jun 2021 15:31:16 +0200
+
+cog (0.10.0-1) experimental; urgency=medium
+
+ * New upstream release.
+ * debian/control:
+- Add build dependencies on libdrm-dev, libgbm-dev and libinput-dev.
+ * debian/install:
+- Install all platform plugins (this version builds two new ones: drm
+ and headless).
+ * debian/cog.lintian-overrides:
+- Override sharedobject-in-library-directory-missing-soname in all
+ plugins
+- Override library-not-linked-against-libc in the headless plugin
+ (this is a false positive, this plugin does not use libc symbols)
+ * Drop use-fdo-backend.patch.
+
+ -- Alberto Garcia Tue, 18 May 2021 23:25:25 +0200
+
cog (0.8.1-1) unstable; urgency=medium
* New upstream release.
diff --git a/debian/cog.lintian-overrides b/debian/cog.lintian-overrides
index 0023111..b7be197 100644
--- a/debian/cog.lintian-overrides
+++ b/debian/cog.lintian-overrides
@@ -1,2 +1,3 @@
-cog: sharedobject-in-library-directory-missing-soname
usr/lib/*/libcogplatform-fdo.so
+cog: library-not-linked-against-libc usr/lib/*/libcogplatform-headless.so
+cog: sharedobject-in-library-directory-missing-soname
usr/lib/*/libcogplatform-*.so
cog: package-name-doesnt-match-sonames libcogcore1
diff --git a/debian/control b/debian/control
index c29a56f..91b5b38 100644
--- a/debian/control
+++ b/debian/control
@@ -5,8 +5,11 @@ Maintainer: Alberto Garcia
Build-Depends: debhelper-compat (= 12),
cmake,
libcairo-dev,
+ libdrm-dev,
+ libgbm-dev,
+ libinput-dev,
libwayland-dev,
- libwpebackend-fdo-1.0-dev,
+ libwpebackend-fdo-1.0-dev (>= 1.10.0),
libwpewebkit-1.0-dev,
wayland-protocols
Standards-Version: 4.5.1
diff --git a/debian/install b/debian/install
index dec1194..bd32724 100644
--- a/debian/install
+++ b/debian/install
@@ -1,4 +1,4 @@
usr/bin/*
usr/lib/*/*.so.*
-usr/lib/*/libcogplatform-fdo.so
+usr/lib/*/libcogplatform-*.so
usr/share/man
diff --git a/debian/patches/series b/debian/patches/series
deleted file mode 100644
index 2368f97..000
--- a/debian/patches/series
+++ /dev/null
@@ -1 +0,0 @@
-use-fdo-backend.patch
diff --git a/debian/patches/use-fdo-backend.patch
b/debian/patches/use-fdo-backend.patch
deleted file mode 100644
index 5e138fb..000
--- a/debian/patches/use-fdo-backend.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-From: Alberto Garcia
-Subject: Default to the fdo backend if none is specified
-diff --git a/cog.c b/cog.c
-index 6f30bb7..f9d164d 100644
a/cog.c
-+++ b/cog.c
-@@ -309,11 +309,12 @@ platform_setup (CogShell *shell)
- * a given platform.
- */
-
-+if (!s_options.platform_name) {
-+s_options.platform_name = g_strdup("fdo");
-+}
-+
- g_debug ("%s: Platform name: %s", __func__, s_options.platform_name);
-
--if (!s_options.platform_name)
--return FALSE;
--
- g_autofree char *platform_soname =
- g_strdup_printf ("libcogplatform-%s.so", s_options.platform_name);
- g_clear_pointer (_options.platform_name, g_free);
Bug#990867: shim-helpers-arm64-signed: post-install script fails with 'error exit status 1'
On zondag 11 juli 2021 02:31:19 CEST Steve McIntyre wrote: > Hi Diederik, Hi Steve, > On Sat, Jul 10, 2021 at 01:48:53AM +0200, Diederik de Haas wrote: > >dpkg: error processing package shim-helpers-arm64-signed (--configure): > > installed shim-helpers-arm64-signed package post-installation script > > subprocess returned error exit status 1> > >dpkg: dependency problems prevent configuration of shim-signed:arm64: > > shim-signed:arm64 depends on shim-helpers-arm64-signed (>= 1+15.4+2); > > however: > > Package shim-helpers-arm64-signed is not configured yet. > > The maintainer scripts for the shim-signed packages now explicitly > calls grub-install to make sure that shim is added/removed from the > boot chain as appropriate. The errors you're seeing are from > grub-install, and that's where the problem is showing up. > > AFAICS grub-install is failing to update due to the *real* underlying > problem, which is that your platform is running firmware which > implements UEFI but that UEFI support isn't working for writing UEFI > boot variables. You're using U-Boot, I assume? Yes, u-boot-rockchip to be exact. The base image for my rock64 is made using the .yaml file from https://salsa.debian.org/diederik/rock64 > So, here's a few thoughts: > > 1. To stop your machine failing here, do a "dpkg-reconfigure > grub-efi-arm64" and say "yes" to the removable media path question > and "no" to the "update boot variables" question. That should > solve the immediate problem for you - please shout if it doesn't! Yeah! That fixed it, thanks :-) > Fixing this in the *general* case is hard. We could add code to > fall back to *not* updating UEFI boot variables if that fails, but > that's likely going to be error-prone and cause trouble on > machines where that *should* work but it fails on a temporary > basis. Instead, I suspect we may need to replicate similar > functionality to flash-kernel and have a list of "quirky" machines > where we *don't* expect UEFI boot variables to work. That's messy as > all hell, but I'm not sure of a better option. :-/ There was recently a thread on debian-arm ML about questions to ask to ARM and the general trend was "can we please get some (more) uniformity?". So I can understand that fixing it in code could be (extremely) hard. What can be improved is the error message. If I may say so myself, in running Sid for 10+ years I've gotten pretty decent at finding the cause of an issue and then finding a fix. But at this problem I was at a loss. Twice. (not knowing much about EFI probably doesn't help). If an error is detected, a message like "Look at this wiki page for possible solutions", with the solution you just provided me (among others), would be really helpful. I've made/attached screenshots which could be used for that. > 2. To the best of my knowledge, none of the current U-Boot releases > support Secure Boot so you may as well remove the shim-signed > package anyway. It's normally harmless to include it (so we pull > it in via recommends), but on your system it's not going to do > anything for you so you may as well remove it. It may have prevented me seeing this issue, but others would likely have encountered it anyway. One of the reasons I run Sid is encountering issues and finding a fix, so others won't have to. So I'm keeping it for now. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#990944: RM: atlas-ecmwf [armel armhf i386 mipsel] -- NBS; no longer built for 32bit
Package: ftp.debian.org Severity: normal Control: block -1 by 990943 atlas-ecmwf (0.25.0-2) unstable; urgency=medium * Drop 32-bit support. Closes: #987482 ... -- Alastair McKinstry Thu, 03 Jun 2021 08:33:27 +0100
Bug#990943: RM: metview [armel armhf i386 mipsel] -- RoQA; build dependency atlas-ecmwf no longer built for 32bit
Package: ftp.debian.org Severity: normal The build dependency atlas-ecmwf is no longer built for 32bit.
Bug#990927: ensmallen FTBFS: test not run
Control: tag -1 patch Hi Adrian, Thank you for your testings, and having caught this: > Unable to find executable: > /<>/obj-x86_64-linux-gnu/ensmallen_tests It looks like the binary ensmallen_tests driving the test suite does not get built by the default targets. The patch in attachment solves the problem on my end, and the build from source goes through. In hope this helps… Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/tty1, please excuse my verbosity. --- a/debian/rules +++ b/debian/rules @@ -7,6 +7,9 @@ %: dh $@ +execute_after_dh_auto_build: + dh_auto_build -- ensmallen_tests + # Number of times to run test suite. # (There was a heisenbug, and this was used to help track it down.) n_test = 1 signature.asc Description: PGP signature
Bug#989805: collectd-core: nut plugin missing
Please enable the nut plugin in Debian Bullseye, otherwise this will break systems that migrate from Debian 10 to Debian 11.
Bug#990807: thunderbird incapable to run only with ~/.thunderbird that was migrated from icedove
Hello Tomas, Am 07.07.21 um 22:58 schrieb Tomas Pospisek: > I'd like to describe my problem, which is related to #950941. > > I have copyied over ~/thunderbird from my old laptop. Now when > I start thunderbird, it start's normally. However at next start it > will fail and complain and tell me that I should resolve the > situation. > > Why? > > Because on first start, the second layer of wrappers will > apparently make a **copy** of ~/.thunderbird to ~/.icedove. the wrapper will never start a copy of any folder. We were thinking in 2017 if simply copying the old profile to the new folder is a good idea. But we concluded rather quickly this is a bad idea for several reasons. So no, you making here a wrong assumption, the wrapper isn't copying anything. > And on the second start the first layer wrapper will see: > > $ ls -l .thunderbird/ .icedove/ -d > drwx-- 3 me mi 4096 7. Jul 22:24 .icedove/ > drwx-- 5 me mi 4096 2. Jul 21:57 .thunderbird/ > > and ... fail. I can't say why you have two folders here, but I can think of you copied the symlinked folder into a real folder, this was happen to my back in 2017 while testing the stuff. And then the wrapper refuses to start anything because we don't know what to use for (from a PoV of the wrapper). If you don't need the old .icedove folder anymore then remove it. The wrapper script will start Thunderbird without further modifications. It's the Thunderbird binary that is requiring the folder $(HOME)/.thunderbird. > So I've tried to find out. Took me now over 1.5 hours and > I still haven't found out because... well it's complex. > And even with the whole complexity the wrapper is still > not able to handle (in the sense of behaving like > thunderbird itself would in the same situation) the > situation. > > So I'd suggest something in the vein of: > > $ cat /usr/bin/thunderbird > #!/bin/bash > if [ "$SKIP_THUNDERBIRD_WRAPPER" != "" ]; then > /usr/lib/thunderbird/thunderbird "$@"; fi > > But then again one could simply do: > > alias thunderbird=/usr/lib/thunderbird/thunderbird > > (the path /usr/lib/thunderbird/thunderbird not being > trivial to find...). Or maybe [also] document that... > > Yet another alternative is to use upstream? I don't want to add any more complexity to the wrapper, it's not worth in my eyes. You reported for a very very long time the first new issue regarding the Icedove -> Thunderbird transition, that let me assume there is no real issue in the wrapper today. The wrapper script has a commented out line 'set -x' in line 21. I suggest to activate this setting and look into the output while calling 'thunderbird' from the command line. This will give more ozutput that is helpful for a diagnose. -- Regards Carsten
Bug#990754: unblock: wpewebkit/2.32.1-1
On Wed, Jul 07, 2021 at 11:53:16AM +0200, Moritz Muehlenhoff wrote: > > The concern also extends to web rendering engines not explicitly > > mentioned here, with the exception of > role="source">webkit2gtk. > > Good point wrt the releases notes part. I guess we should simply > make this "with the exception of webkit2gtk/wpewebkit". Alberto, > could you file a bug against the release notes? Done, #990940 Berto
Bug#990371: munin-node: Unit fails on startup - Runtime directory n/a
I've sent MR to fix this issue. https://salsa.debian.org/debian/munin/-/merge_requests/5 Regards,
Bug#990942: unblock: debian-design/3.0.22
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package debian-design
* rebuild using newer boxer-data
(change by Jonas Smedegaard)
This is a manual binNMU for binary-all.
According to debdiff, the only change is in the
dependencies of design-desktop-web:
Depends: design-desktop, compass-blueprint-plugin,
compass-color-schemer-plugin, compass-fancy-buttons-plugin,
compass-h5bp-plugin, compass-layoutgala-plugin, compass-normalize-plugin,
[-compass-singularitygs-plugin, compass-slickmap-plugin, compass-susy-plugin,-]
compass-toolkit-plugin, [-compass-yui-plugin, midori-] {+midori,
sass-stylesheets-gutenberg, sass-stylesheets-sass-extras,
sass-stylesheets-typey, sassc+}
diff -Nru debian-design-3.0.21/debian/changelog
debian-design-3.0.22/debian/changelog
--- debian-design-3.0.21/debian/changelog 2020-12-29 20:11:34.0
+0200
+++ debian-design-3.0.22/debian/changelog 2021-03-02 17:30:17.0
+0200
@@ -1,9 +1,15 @@
+debian-design (3.0.22) unstable; urgency=medium
+
+ * rebuild using newer boxer-data
+
+ -- Jonas Smedegaard Tue, 02 Mar 2021 16:30:17 +0100
+
debian-design (3.0.21) unstable; urgency=medium
* declare compliance with Debian Policy 4.5.1
* rebuild using newer boxer-data:
+ stop include chromium;
- closes: bug#972134, thanks to Paul Gevers
+ closes: bug#976292, thanks to Paul Gevers
-- Jonas Smedegaard Tue, 29 Dec 2020 19:11:34 +0100
Bug#990940: release-notes: wpewebkit to be covered by security support in bullseye
Package: release-notes
Severity: important
Tags: patch
Debian provides security support for the WebKitGTK browser engine
(source package: webkit2gtk). For bullseye we also want to support
wpewebkit, which is developed by the same team, follows a very similar
release schedule and numbering system, shares most of the code and
almost all CVEs fixes apply to both ports.
See #990754 for more details.
I'm attaching a patch for the release notes.
diff --git a/en/issues.dbk b/en/issues.dbk
index 5f177f54..9fb6861d 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -483,12 +483,13 @@ data =
${lookup{$local_part}lsearch{/some/path/$domain_data/aliases}}
source packages and the concern applies to all packages shipping
them. The concern also extends to web rendering engines not explicitly
mentioned here, with the exception of webkit2gtk. are included
in
- , but not
- covered by security support. These browsers should not be used against
- untrusted websites.
- The webkit2gtk source package
is
- covered by security support.
+ role="source">webkit2gtk and wpewebkit. are included
in
+ , but not covered by security support. These
+ browsers should not be used against untrusted websites.
+ The webkit2gtk and
+ wpewebkit source
+ packages are covered by security support.
For general web browser use we recommend Firefox or Chromium.
Bug#990941: ITP: zipkin -- Distributed tracing system
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: zipkin Version : 2.22.1 Upstream Author : Zipkin Team * URL : http://www.zipkin.org/ * License : Apache Programming Lang: Java Description : Distributed tracing system Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in service architectures. Features include both the collection and lookup of this data. If you have a trace ID in a log file, you can jump directly to it. Otherwise, you can query based on attributes such as service, operation name, tags and duration. Some interesting data will be summarized for you, such as the percentage of time spent in a service, and whether or not operations failed.
Bug#990939: unblock: newlisp/10.7.5-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package newlisp
* d/p/0009-Fix-shared-library-loading-for-modules.patch:
Adjust patch so that the modules don't try to load a versioned shared
library.
* d/control: Don't recommend hardcoded ABI versions in library packages.
We should recommend the '-dev' packages instead, which will install
the proper .so files that will get loaded by the modules. (Closes: #984686)
* d/p/0009-Set-NEWLISPDIR-to-usr-share-newlisp.patch:
Inform newlisp that the common files are installed under
/usr/share/newlisp, not /usr/local/share.
(changes by Sergio Durigan Junior)
Recommending no longer existing shared libraries is bad,
even worse is trying to open them at runtime.
Depending on the -dev packages instead is not nice,
but it is actually the fix with the smallest change.
The NEWLISPDIR change looks correct to me.
diff -Nru newlisp-10.7.5/debian/changelog newlisp-10.7.5/debian/changelog
--- newlisp-10.7.5/debian/changelog 2019-07-21 02:47:33.0 +0300
+++ newlisp-10.7.5/debian/changelog 2021-03-07 22:17:34.0 +0200
@@ -1,3 +1,17 @@
+newlisp (10.7.5-2) unstable; urgency=medium
+
+ * d/p/0009-Fix-shared-library-loading-for-modules.patch:
+Adjust patch so that the modules don't try to load a versioned shared
+library.
+ * d/control: Don't recommend hardcoded ABI versions in library packages.
+We should recommend the '-dev' packages instead, which will install
+the proper .so files that will get loaded by the modules. (Closes: #984686)
+ * d/p/0009-Set-NEWLISPDIR-to-usr-share-newlisp.patch:
+Inform newlisp that the common files are installed under
+/usr/share/newlisp, not /usr/local/share.
+
+ -- Sergio Durigan Junior Sun, 07 Mar 2021 15:17:34
-0500
+
newlisp (10.7.5-1) unstable; urgency=medium
* New upstream version 10.7.5.
diff -Nru newlisp-10.7.5/debian/control newlisp-10.7.5/debian/control
--- newlisp-10.7.5/debian/control 2019-07-21 02:46:32.0 +0300
+++ newlisp-10.7.5/debian/control 2021-03-07 22:08:21.0 +0200
@@ -17,11 +17,11 @@
Depends: ${shlibs:Depends}, ${misc:Depends}
# For newLISP modules.
Recommends:
- libcrypto++6,
- libmysqlclient18,
- libpq5,
- libsqlite3-0,
- zlib1g,
+ libssl-dev,
+ default-libmysqlclient-dev,
+ libpq-dev,
+ libsqlite3-dev,
+ zlib1g-dev,
sensible-utils,
Description: LISP like, general purpose scripting language
newLISP is a scripting language for developing web applications and
diff -Nru
newlisp-10.7.5/debian/patches/0009-Fix-shared-library-loading-for-modules.patch
newlisp-10.7.5/debian/patches/0009-Fix-shared-library-loading-for-modules.patch
---
newlisp-10.7.5/debian/patches/0009-Fix-shared-library-loading-for-modules.patch
2019-07-21 02:46:32.0 +0300
+++
newlisp-10.7.5/debian/patches/0009-Fix-shared-library-loading-for-modules.patch
2021-03-07 22:16:26.0 +0200
@@ -22,7 +22,7 @@
8 files changed, 9 insertions(+), 126 deletions(-)
diff --git a/modules/crypto.lsp b/modules/crypto.lsp
-index 26d7bda..e52af3a 100644
+index 26d7bda..289a027 100644
--- a/modules/crypto.lsp
+++ b/modules/crypto.lsp
@@ -41,28 +41,7 @@
@@ -51,7 +51,7 @@
- (throw-error "cannot find crypto library"
-
-(set 'option (if (= ostype "Windows") "cdecl"))
-+(set 'library "libcrypto.so.1")
++(set 'library "libcrypto.so")
(import library "MD5" option)
(import library "RIPEMD160" option)
@@ -85,7 +85,7 @@
; structs are defined but only needed for debugging, instead use "void*"
(struct 'complex "double" "double") ; complex numbers
diff --git a/modules/mysql.lsp b/modules/mysql.lsp
-index 05faded..bd93a21 100644
+index 05faded..20a6093 100644
--- a/modules/mysql.lsp
+++ b/modules/mysql.lsp
@@ -118,20 +118,7 @@
@@ -106,7 +106,7 @@
-(set 'library (files (or
- (find true (map file? files))
- (throw-error "cannot find libmysqlclient library"
-+(set 'library "libmysqlclient.so.18")
++(set 'library "libmysqlclient.so")
(import library "mysql_init")
(import library "mysql_real_connect")
@@ -125,7 +125,7 @@
; Constants used, make sure these constants are Ok on your Operating System
or Platform.
; Note, that (define var value) is the same as as saying (set 'var value), it
is here more
diff --git a/modules/postgres.lsp b/modules/postgres.lsp
-index 0fe5ec5..c620f92 100644
+index 0fe5ec5..5af0c6c 100644
--- a/modules/postgres.lsp
+++ b/modules/postgres.lsp
@@ -128,34 +128,7 @@
@@ -160,7 +160,7 @@
-(delete 'pg_config)
-(delete 'pg_lib_dir)
-(delete 'files)
-+(set 'library "libpq.so.5")
++(set 'library "libpq.so")
; import functions and throw error if not found
(define (pg_import fun_name)
@@ -198,7 +198,7 @@
(import library "sqlite3_open" "cdecl")
(import library "sqlite3_close" "cdecl")
diff --git a/modules/unix.lsp b/modules/unix.lsp
Bug#990938: unblock: dh-virtualenv/1.2.2-1.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package dh-virtualenv
* Rebuild to update python3.X-venv dependency. Closes: #984766.
(Change by Vincent Bernat)
This was basically a binNMU for a binary-all package to update
a non-default dependency alternative.
$ debdiff dh-virtualenv_1.2.2-1_all.deb dh-virtualenv_1.2.2-1.1_all.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in first .deb but not in second
-
lrwxrwxrwx root/root
/usr/share/doc/dh-virtualenv/html/_static/js/html5shiv-printshiv.min.js ->
../../../../../sphinx_rtd_theme/static/js/html5shiv-printshiv.min.js
lrwxrwxrwx root/root
/usr/share/doc/dh-virtualenv/html/_static/js/html5shiv.min.js ->
../../../../../sphinx_rtd_theme/static/js/html5shiv.min.js
Control files: lines which differ (wdiff format)
Built-Using: sphinx (= [-3.2.1-2)-] {+3.4.3-1)+}
Depends: python3:any, perl:any, libjs-sphinxdoc (>= 2.4.3-5~),
sphinx-rtd-theme-common (>= [-0.5.0+dfsg),-] {+0.5.1+dfsg),+} virtualenv |
python3-virtualenv (>= 1.7) | [-python3.8-venv-] {+python3.9-venv+}
Installed-Size: [-524-] {+521+}
Version: [-1.2.2-1-] {+1.2.2-1.1+}
$
The change in Sphinx output is "normal" when rebuilding
with a different version of Sphinx.
diff -Nru dh-virtualenv-1.2.2/debian/changelog
dh-virtualenv-1.2.2/debian/changelog
--- dh-virtualenv-1.2.2/debian/changelog2020-10-22 13:39:46.0
+0300
+++ dh-virtualenv-1.2.2/debian/changelog2021-03-08 10:02:45.0
+0200
@@ -1,3 +1,10 @@
+dh-virtualenv (1.2.2-1.1) unstable; urgency=medium
+
+ * NMU.
+ * Rebuild to update python3.X-venv dependency. Closes: #984766.
+
+ -- Vincent Bernat Mon, 08 Mar 2021 09:02:45 +0100
+
dh-virtualenv (1.2.2-1) unstable; urgency=medium
* New upstream release (Closes: #970810)
Bug#990937: unblock: l2tpns/2.3.3-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package l2tpns * Backport patch to systemd unit from upstream (and trivial metadata changes that are documented in d/changelog) (changes by Julien Rabier and Sebastien Badia) Reading [1] this two-line change sounds like something that is wanted for bullseye. https://code.ffdn.org/l2tpns/l2tpns/-/merge_requests/11 diff -Nru l2tpns-2.3.3/debian/changelog l2tpns-2.3.3/debian/changelog --- l2tpns-2.3.3/debian/changelog 2021-02-06 02:11:00.0 +0200 +++ l2tpns-2.3.3/debian/changelog 2021-03-09 00:32:16.0 +0200 @@ -1,3 +1,15 @@ +l2tpns (2.3.3-2) unstable; urgency=medium + + [ Sebastien Badia ] + * d/gbp: Added configuration + * d/patches: Update DEP-3 headers + + [ Julien Rabier ] + * Update Uploader's e-mail address + * Backport patch to systemd unit from upstream + + -- Sebastien Badia Mon, 08 Mar 2021 23:32:16 +0100 + l2tpns (2.3.3-1) unstable; urgency=medium [ Julien Rabier ] diff -Nru l2tpns-2.3.3/debian/control l2tpns-2.3.3/debian/control --- l2tpns-2.3.3/debian/control 2021-02-06 02:09:30.0 +0200 +++ l2tpns-2.3.3/debian/control 2021-03-08 00:26:28.0 +0200 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian l2tpns Packaging Team Uploaders: Sebastien Badia , - Julien Rabier , + Julien Rabier , Fernando Alves Build-Depends: debhelper-compat (= 13), libcli-dev (>> 1.8.5) Standards-Version: 4.5.1 diff -Nru l2tpns-2.3.3/debian/gbp.conf l2tpns-2.3.3/debian/gbp.conf --- l2tpns-2.3.3/debian/gbp.conf1970-01-01 02:00:00.0 +0200 +++ l2tpns-2.3.3/debian/gbp.conf2021-03-08 00:26:19.0 +0200 @@ -0,0 +1,4 @@ +[DEFAULT] +upstream-branch=upstream +debian-branch=master +pristine-tar = True diff -Nru l2tpns-2.3.3/debian/patches/02-systemd-restart.patch l2tpns-2.3.3/debian/patches/02-systemd-restart.patch --- l2tpns-2.3.3/debian/patches/02-systemd-restart.patch1970-01-01 02:00:00.0 +0200 +++ l2tpns-2.3.3/debian/patches/02-systemd-restart.patch2021-03-09 00:31:31.0 +0200 @@ -0,0 +1,17 @@ +Description: Restart l2tpns service on failure +Author: Baptiste Jonglez +Reviewed-by: Julien Rabier +Bug: https://code.ffdn.org/l2tpns/l2tpns/-/merge_requests/11 +Applied-Upstream: https://code.ffdn.org/l2tpns/l2tpns/-/commit/a5ddc0f64a1099449c2f81b251cee6960f68ea18 + +--- a/scripts/l2tpns.service b/scripts/l2tpns.service +@@ -7,6 +7,8 @@ Documentation=man:l2tpns(8) man:startup- + EnvironmentFile=-/etc/default/l2tpns + ExecStart=/usr/sbin/l2tpns $L2TPNS_OPTS + ExecReload=/bin/kill -HUP $MAINPID ++Restart=on-failure ++RestartSec=5s + + [Install] + WantedBy=multi-user.target diff -Nru l2tpns-2.3.3/debian/patches/series l2tpns-2.3.3/debian/patches/series --- l2tpns-2.3.3/debian/patches/series 2021-02-06 02:09:30.0 +0200 +++ l2tpns-2.3.3/debian/patches/series 2021-03-08 00:26:28.0 +0200 @@ -1 +1,2 @@ 01-harden-compile.patch +02-systemd-restart.patch
Bug#990936: unblock: debian-keyring/2021.06.25
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: keyring-ma...@debian.org Please unblock package debian-keyring (Please provide enough (but not too much) information to help the release team to judge the request efficiently. E.g. by filling in the sections below.) [ Reason ] This is the usual request to unblock debian-keyring so that the most up to date version of it can be included with the release. There will probably be another update just before the actual release, but not with enough time to migrate cleanly (~ 24th July). [ Impact ] If not unblocked then bullseye will ship with the December 2020 keyring update. [ Tests ] N/A [ Risks ] This is a leaf package and there shouldn't be any risks associated with including it in the release. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing [ Other info ] I have not included a debdiff as I do not believe it is useful in any fashion for this request. unblock debian-keyring/2021.06.25
Bug#990935: unblock: zsh-antigen/2.2.3-4
On Sun, Jul 11, 2021 at 03:06:35PM +0300, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
>
> Please unblock package zsh-antigen
>
> * Add patch to replace PWD in Makefile (Closes: #906757).
> (change by Michael Fladischer)
>
>
> The effect of this bug was that /usr/share/zsh-antigen/antigen.zsh
> was being misbuilt.
>
>
> Quoting from a comment in #906757:
> It looks like the make command from antigen builds the antigen script by
> copying files from it's source directory into bin/antigen.zsh.
>
> When it does that, it uses a GLOB variable, that accumulatees the files
> to copy. This in turn is filled by the COMMANDS, HELPERS and LIB
> variables (Makefile.in lines 48-50).
>
>
> diffoscope between 2.2.3-3 and 2.2.3-4 confirms this.
>
>
> "source /usr/share/zsh-antigen/antigen.zsh" fails with the package
> in bullseye but appears to work with the package in unstable.
And now with a non-empty debdiff...
cu
Adrian
diff -Nru zsh-antigen-2.2.3/debian/changelog zsh-antigen-2.2.3/debian/changelog
--- zsh-antigen-2.2.3/debian/changelog 2020-12-04 22:21:35.0 +0200
+++ zsh-antigen-2.2.3/debian/changelog 2021-03-09 17:37:29.0 +0200
@@ -1,3 +1,9 @@
+zsh-antigen (2.2.3-4) unstable; urgency=medium
+
+ * Add patch to replace PWD in Makefile (Closes: #906757).
+
+ -- Michael Fladischer Tue, 09 Mar 2021 16:37:29 +0100
+
zsh-antigen (2.2.3-3) unstable; urgency=medium
* Update patch to use UTC timestamp and Debian revision to support
diff -Nru
zsh-antigen-2.2.3/debian/patches/0002-Replace-PWD-environment-with-PROJECT-variable-Closes.patch
zsh-antigen-2.2.3/debian/patches/0002-Replace-PWD-environment-with-PROJECT-variable-Closes.patch
---
zsh-antigen-2.2.3/debian/patches/0002-Replace-PWD-environment-with-PROJECT-variable-Closes.patch
1970-01-01 02:00:00.0 +0200
+++
zsh-antigen-2.2.3/debian/patches/0002-Replace-PWD-environment-with-PROJECT-variable-Closes.patch
2021-03-09 17:37:29.0 +0200
@@ -0,0 +1,25 @@
+From: Michael Fladischer
+Date: Tue, 9 Mar 2021 16:25:31 +0100
+Subject: Replace PWD environment with PROJECT variable (Closes: #906757).
+
+---
+ Makefile.in | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index ad1ac59..de32824 100644
+--- a/Makefile.in
b/Makefile.in
+@@ -45,9 +45,9 @@ GLOB += ${SRC}/boot.zsh
+ EXTENSIONS += ${SRC}/ext/cache.zsh
+ endif
+
+-LIB = $(filter-out ${SRC}/lib/log.zsh,$(sort $(wildcard
${PWD}/src/lib/*.zsh)))
+-HELPERS = $(sort $(wildcard ${PWD}/src/helpers/*.zsh))
+-COMMANDS= $(sort $(wildcard ${PWD}/src/commands/*.zsh))
++LIB = $(filter-out ${SRC}/lib/log.zsh,$(sort $(wildcard
${PROJECT}/src/lib/*.zsh)))
++HELPERS = $(sort $(wildcard ${PROJECT}/src/helpers/*.zsh))
++COMMANDS= $(sort $(wildcard ${PROJECT}/src/commands/*.zsh))
+ GLOB += ${SRC}/antigen.zsh ${HELPERS} ${LIB} ${COMMANDS} ${EXTENSIONS}
+
+ ifeq (${WITH_COMPLETION}, yes)
diff -Nru zsh-antigen-2.2.3/debian/patches/series
zsh-antigen-2.2.3/debian/patches/series
--- zsh-antigen-2.2.3/debian/patches/series 2020-12-04 22:21:35.0
+0200
+++ zsh-antigen-2.2.3/debian/patches/series 2021-03-09 17:37:29.0
+0200
@@ -1 +1,2 @@
0001-Use-package-specific-revision-and-date-for-build.patch
+0002-Replace-PWD-environment-with-PROJECT-variable-Closes.patch
Bug#990935: unblock: zsh-antigen/2.2.3-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package zsh-antigen * Add patch to replace PWD in Makefile (Closes: #906757). (change by Michael Fladischer) The effect of this bug was that /usr/share/zsh-antigen/antigen.zsh was being misbuilt. Quoting from a comment in #906757: It looks like the make command from antigen builds the antigen script by copying files from it's source directory into bin/antigen.zsh. When it does that, it uses a GLOB variable, that accumulatees the files to copy. This in turn is filled by the COMMANDS, HELPERS and LIB variables (Makefile.in lines 48-50). diffoscope between 2.2.3-3 and 2.2.3-4 confirms this. "source /usr/share/zsh-antigen/antigen.zsh" fails with the package in bullseye but appears to work with the package in unstable. debdiff-zsh-antigen_2.2.3-4 Description: inode/empty
Bug#989037: Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1
Hi Paul, [CC'ed team@s.d.o] On Sat, Jul 10, 2021 at 1:34 AM Paul Gevers wrote: > Unblocked the latest version in unstable. Awesome, thank you so much! Just as a heads up, I'll be also filing unblock requests for ruby2.7 (already uploaded) and libjdom1-java & libjdom2-java (yet to upload). All three are CVE fixes and hopefully should be trivial for the release team to evaluate. Let me know if you've any questions, thank you! - u
Bug#990934: unblock: python-reportlab/3.5.59-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package python-reportlab
* Fix building the reference documentation.
(change by Matthias Klose)
This is a documentation change.
$ debdiff python-reportlab-doc_3.5.59-*
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root
/usr/share/doc/python-reportlab-doc/html/py-modindex.html
Control files: lines which differ (wdiff format)
Installed-Size: [-1067-] {+1622+}
Version: [-3.5.59-1-] {+3.5.59-2+}
$
diffoscope output is very noisy (package is not reproducible),
but when glancing over it there was nothing that looked bad.
diff -Nru python-reportlab-3.5.59/debian/changelog
python-reportlab-3.5.59/debian/changelog
--- python-reportlab-3.5.59/debian/changelog2021-01-08 11:15:25.0
+0200
+++ python-reportlab-3.5.59/debian/changelog2021-03-13 14:39:39.0
+0200
@@ -1,3 +1,9 @@
+python-reportlab (3.5.59-2) unstable; urgency=medium
+
+ * Fix building the reference documentation.
+
+ -- Matthias Klose Sat, 13 Mar 2021 13:39:39 +0100
+
python-reportlab (3.5.59-1) unstable; urgency=medium
* New upstream version.
diff -Nru python-reportlab-3.5.59/debian/patches/reportlab-version.diff
python-reportlab-3.5.59/debian/patches/reportlab-version.diff
--- python-reportlab-3.5.59/debian/patches/reportlab-version.diff
1970-01-01 02:00:00.0 +0200
+++ python-reportlab-3.5.59/debian/patches/reportlab-version.diff
2021-03-13 14:32:55.0 +0200
@@ -0,0 +1,15 @@
+--- a/docs/source/conf.py
b/docs/source/conf.py
+@@ -45,9 +45,10 @@ copyright = '2010, Robinson, Becker, Wat
+ # built documents.
+ #
+ # The short X.Y version.
+-version = '2.4'
++from reportlab import Version
++version = '.'.join(Version.split('.')[:2])
+ # The full version, including alpha/beta/rc tags.
+-release = '2.4'
++release = Version
+
+ # The language for content autogenerated by Sphinx. Refer to documentation
+ # for a list of supported languages.
diff -Nru python-reportlab-3.5.59/debian/patches/series
python-reportlab-3.5.59/debian/patches/series
--- python-reportlab-3.5.59/debian/patches/series 2020-01-28
17:56:28.0 +0200
+++ python-reportlab-3.5.59/debian/patches/series 2021-03-13
14:39:07.0 +0200
@@ -1,3 +1,4 @@
gsfonts.diff
reproducible-build.patch
toColor.patch
+reportlab-version.diff
diff -Nru python-reportlab-3.5.59/debian/rules
python-reportlab-3.5.59/debian/rules
--- python-reportlab-3.5.59/debian/rules2020-01-28 17:56:28.0
+0200
+++ python-reportlab-3.5.59/debian/rules2021-03-13 14:39:28.0
+0200
@@ -28,7 +28,7 @@
set -x; \
cd docs \
&& PYTHONPATH=$(wildcard $(CURDIR)/build/lib.*-*-$(VER3)) python3
genAll.py
- $(MAKE) -C docs html PAPER=a4
+ PYTHONPATH=$(wildcard $(CURDIR)/build/lib.*-*-$(VER3)) $(MAKE) -C docs
html PAPER=a4
touch $@
clean:
Bug#990933: unblock: katarakt/0.2-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package katarakt * Fix: katarakt has mailcap entries with quoted %-escapes Thanks to Marriott NZ for the patch and report (Closes: #985600) * Update standards version, no changes needed (changes by Christoph Egger) Quoted %-escapes in mailcap entries feel more serious to me than the many unfixed packages [1] imply, but in any case migrating this package already fixed to bullseye would feel sound the right thing to do to me. [1] https://lintian.debian.org/tags/quoted-placeholder-in-mailcap-entry diff -Nru katarakt-0.2/debian/changelog katarakt-0.2/debian/changelog --- katarakt-0.2/debian/changelog 2020-11-20 19:13:55.0 +0200 +++ katarakt-0.2/debian/changelog 2021-03-20 18:40:23.0 +0200 @@ -1,3 +1,11 @@ +katarakt (0.2-4) unstable; urgency=medium + + * Fix: katarakt has mailcap entries with quoted %-escapes +Thanks to Marriott NZ for the patch and report (Closes: #985600) + * Update standards version, no changes needed + + -- Christoph Egger Sat, 20 Mar 2021 17:40:23 +0100 + katarakt (0.2-3) unstable; urgency=medium * Import bugfix patches from VCS diff -Nru katarakt-0.2/debian/control katarakt-0.2/debian/control --- katarakt-0.2/debian/control 2020-11-20 19:13:55.0 +0200 +++ katarakt-0.2/debian/control 2021-03-20 18:40:23.0 +0200 @@ -14,7 +14,7 @@ pkg-config, qtbase5-dev, xsltproc -Standards-Version: 4.1.0 +Standards-Version: 4.5.1 Homepage: https://gitlab.cs.fau.de/Qui_Sum/katarakt Vcs-Git: https://salsa.debian.org/debian/katarakt.git Vcs-Browser: https://salsa.debian.org/debian/katarakt diff -Nru katarakt-0.2/debian/katarakt.mime katarakt-0.2/debian/katarakt.mime --- katarakt-0.2/debian/katarakt.mime 2020-11-20 19:13:55.0 +0200 +++ katarakt-0.2/debian/katarakt.mime 2021-03-20 18:40:23.0 +0200 @@ -1,3 +1,3 @@ # default priority=5 -application/pdf; /usr/bin/katarakt '%s'; test=test -n "$DISPLAY"; description=Portable Document Format -application/x-pdf; /usr/bin/katarakt '%s'; test=test -n "$DISPLAY"; description=Portable Document Format +application/pdf; /usr/bin/katarakt %s; test=test -n "$DISPLAY"; description=Portable Document Format +application/x-pdf; /usr/bin/katarakt %s; test=test -n "$DISPLAY"; description=Portable Document Format
Bug#990909: ITP: elpa-treemacs -- a tree layout file explorer for Emacs
Control: retitle -1 ITP: elpa-treemacs -- a tree layout file explorer for Emacs Packaging repository is here: https://salsa.debian.org/emacsen-team/elpa-treemacs
Bug#990893: unblock: libserialport/0.1.1-4
Control: tags -1 - moreinfo On Sun, Jul 11, 2021 at 10:18:03AM +0200, Graham Inggs wrote: > On Sat, 10 Jul 2021 at 19:03, Jonathan McDowell wrote: > > unblock libserialport/0.1.1-3 > > I'm assuming this bug was meant as a pre-approval request for 0.1.1-4. > Please go ahead and upload to unstable, then remove the moreinfo tag > once it has built. It was, thanks. Now uploaded and built for all release archs. J. -- No program done by a hacker will work unless he is on the system.
Bug#820848: RFS: phcpack 2.4.84 (NEW)
On Sun, 11 Jul 2021 at 05:35, Torrance, Douglas wrote: > On Thu 08 Jul 2021 12:24:47 AM EDT, Torrance, Douglas < > dtorra...@piedmont.edu> wrote: > > On Wed 07 Jul 2021 08:37:08 AM EDT, Doug Torrance < > dtorra...@piedmont.edu> wrote: > >> On Wed 07 Jul 2021 01:16:03 AM EDT, Nilesh Patra > wrote: > >>> ./src/Ada/Math_Lib/QD/READ_ME states this: > >>> > >>> The main reference for the QD-2.3.9 library is > >>> Y. Hida, X.S. Li, and D.H. Bailey: > >>> "Algorithms for quad-double precision floating point arithmetic." > >>> In 15th IEEE Symposium on Computer Arithmetic (Arith-15 2001), > >>> 11-17 June 2001, Vail, CO, USA, pages 155-162. IEEE Computer Society, > 2001. > >>> Shortened version of Technical Report LBNL-46996, > >>> software at http://crd.lbl.gov/~dhbailey/mpdist/qd-2.3.9.tar.gz. > >>> > >>> Note that the "BSD-LBNL-License" is GPL compatible, although > >>> "If you wish to use the software for commercial purposes > >>> please contact the Technology Transfer Department at t...@lbl.gov or > >>> call 510-286-6457." > >>> > >>> I admit, I'm not very sure if I understand the terms there correctly, > but > >>> should it be mentioned in d/copyright? > >>> I also see similar stuff in a lot of READ_ME files, > >>> ./src/Ada/Root_Counts/MixedVol/READ_ME for instance. > >>> > >>> Do they need to be mentioned in d/copyright? If not, IMO adding a > >>> "Comment:" and the reasoning for not adding these in copyright would be > >>> good. > >> > >> Good catch! I've sent upstream a note asking for clarification on the > license > >> of the files in this directory. > > > > Upstream confirmed that this particular feature would cause limitations > for > > commercial use due to the license. It's just one feature, though, and I > think > > that PHCpack would still be a valuable addition to Debian without it. > (For > > example, the PHCpack package in Macaulay2 doesn't use it.) > > > > I'll spend some time working on stripping this feature out to create a > > DFSG-compliant version of PHCpack and ping the list when it's ready for > another > > look. > > I've repacked the PHCpack package so that it doesn't use the non-free QD > library. I believe it's ready for another review: > https://salsa.debian.org/science-team/phcpack > Uploaded, thanks a lot for your work! Nilesh
