Processed: unarchiving 969284
Processing commands for cont...@bugs.debian.org:
> unarchive 969284
Bug #969284 {Done: Julien Cristau } [libwayland-dev]
xorg-server: FTBFS: configure: error: Xwayland build explicitly requested, but
required modules not found
Unarchived Bug 969284
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
969284: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969284
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#984439: netgen: FTBFS on armhf (unaligned access on arm64 kernel)
On 2021-03-03, Gianfranco Costamagna wrote: > Hello, looks like the package FTBFS on armhf with an arm64 kernel. > See e.g. builds from reproducible-builds.org > https://tests.reproducible-builds.org/debian/logs/unstable/armhf/netgen_6.2.2006+really6.2.1905+dfsg-2.build2.log.gz If this can be built in a similar environment with the personality set with linux32, the severity should be downgraded. The tests.reproducible-builds.org infrastructure does not use linux32 (which finds corner-case bugs like this one), but I believe buildd.debian.org does use linux32 to set the personality where appropriate. live well, vagrant signature.asc Description: PGP signature
Bug#969896: marked as done (rust-http: Integer Overflow in HeaderMap::reserve() can cause Denial of Service)
Your message dated Mon, 08 Mar 2021 06:48:23 + with message-id and subject line Bug#969896: fixed in rust-http 0.1.19-2 has caused the Debian Bug report #969896, regarding rust-http: Integer Overflow in HeaderMap::reserve() can cause Denial of Service to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 969896: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969896 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: rust-http Version: 0.1.19-1 Severity: normal Dear Maintainer, Versions below 0.1.20 of rust-http have a denial of service vulnerability. Description of the vulnerability: HeaderMap::reserve() used usize::next_power_of_two() to calculate the increased capacity. However, next_power_of_two() silently overflows to 0 if given a sufficently large number in release mode. If the map was not empty when the overflow happens, the library will invoke self.grow(0) and start infinite probing. This allows an attacker who controls the argument to reserve() to cause a potential denial of service (DoS). The flaw was corrected in 0.1.20 release of http crate. Link to advisory: https://rustsec.org/advisories/RUSTSEC-2019-0033.html -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- End Message --- --- Begin Message --- Source: rust-http Source-Version: 0.1.19-2 Done: Wolfgang Silbermayr We believe that the bug you reported is fixed in the latest version of rust-http, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 969...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Wolfgang Silbermayr (supplier of updated rust-http package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 08 Mar 2021 07:19:34 +0100 Source: rust-http Architecture: source Version: 0.1.19-2 Distribution: unstable Urgency: medium Maintainer: Debian Rust Maintainers Changed-By: Wolfgang Silbermayr Closes: 969896 Changes: rust-http (0.1.19-2) unstable; urgency=medium . * Package http 0.1.19 from crates.io using debcargo 2.4.3 * Resolve RUSTSEC-2019-0033 (Closes: #969896) Checksums-Sha1: 5e0da87c5c0228848c98d3a05c5afc0661bbde78 2501 rust-http_0.1.19-2.dsc 4e020df9f360c3a06c576e05c274435cbf217761 3668 rust-http_0.1.19-2.debian.tar.xz 116b73a946b8db7fb1ca79858e1ea57164ecde0f 7541 rust-http_0.1.19-2_source.buildinfo Checksums-Sha256: 6f8403329bd5ce4d6d954702c18148706af5b08b06a72aadcbe38439ac6ab07d 2501 rust-http_0.1.19-2.dsc 2780a5a18855e9cad4d401de73140600024f4a50c1ea705d8ceb3e241f25fe3c 3668 rust-http_0.1.19-2.debian.tar.xz ff11605c07adb41dcb0c26f650c51ecf6277427421b6281d94c3cd166bf6b732 7541 rust-http_0.1.19-2_source.buildinfo Files: 38f5d384fb029a4160f6ed26cff1dc6e 2501 rust optional rust-http_0.1.19-2.dsc 63c69392bba843988813e4079e7b7f72 3668 rust optional rust-http_0.1.19-2.debian.tar.xz 1de7841cf317e12d187051d7742c87bc 7541 rust optional rust-http_0.1.19-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJLBAEBCgA1FiEEz66yQIxXO1E0pjrO1bHTe2DcM9MFAmBFwhAXHHdvbGZnYW5n QHNpbGJlcm1heXIuYXQACgkQ1bHTe2DcM9Pl6A//eXFKpzIGK7XmxU6vmWA331QY /tsf0tUGwvXLAFoQtseJAjbDIPO7xZd4vLR7KRw27Awcy/yG9BXhRLzVRhxdCfBl hZlzdxmTGBT0Vtc453oJmA18rTer0FkV7G/AkXlW9ZynQBD0w8X/+kVjd74mP/1k GQ5MqGvYfV6E3g2s/PJIuQfSm2I7XSuP1qBaEcuqiQ1cYI3ishvh21W0kLiHPNvF PWHzwInq5qByOSEwH8+tXtlpJUePO/bJ3xRBOra69N896LDGsDmNfIJYtpWpdDQH AyCruTntU08FMV+y0o5btmC1X8bO75TwLjL1fO0u/y4PMuJP71TiJiJEguAqv7Ui +u8YwItQeMpa/dDYGieaOqXBf5FAiSty5CqdmradbrX7hH0cE41R2VprM2kb6U2J 8o5sr7njH18LqEeRhgC4fuYNFNW36Eont4WG99HRxFnb2hFmHHAchvCIEn+65jeb pEl5RepH8z9OkNJTooUUHssEnFneUA3ldKOh2/CyDC4OTzgTqnzf6XHw33eRMZSZ PfmfY6bdUXF/KZeUKQVPVedA/Wmoa1mmfi3wKb6heD7L8NAceUEYmA2JU0q53jRy fuJh5lbZnlFnNvt14ddU4KTyd2d5zkkQr8ZQihWn9O1Z48ZjpXNvDDadqy4931gk TQPuuBKr+hKOD+5y
Bug#966479: marked as done (sysdig: broken support on 32 bit kernels?)
Your message dated Mon, 08 Mar 2021 05:18:25 + with message-id and subject line Bug#966479: fixed in sysdig 0.27.1-0.2 has caused the Debian Bug report #966479, regarding sysdig: broken support on 32 bit kernels? to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 966479: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966479 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: sysdig Version: 0.26.7-2 Severity: serious Forwarded: https://github.com/draios/sysdig/issues/1669 Hello, I don't know if this happens also in Debian, but there is no reason for it not happening there. I asked upstream for help, this is what happens: CC [M] /var/lib/dkms/sysdig/0.26.7/build/ppm_cputime.o LD [M] /var/lib/dkms/sysdig/0.26.7/build/sysdig-probe.o Building modules, stage 2. MODPOST 1 modules ERROR: "__aeabi_uldivmod" [/var/lib/dkms/sysdig/0.26.7/build/sysdig-probe.ko] undefined! make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1 thanks for having a look Gianfranco --- End Message --- --- Begin Message --- Source: sysdig Source-Version: 0.27.1-0.2 Done: Dima Kogan We believe that the bug you reported is fixed in the latest version of sysdig, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 966...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Dima Kogan (supplier of updated sysdig package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 07 Mar 2021 20:55:11 -0800 Source: sysdig Architecture: source Version: 0.27.1-0.2 Distribution: unstable Urgency: medium Maintainer: Evgeni Golov Changed-By: Dima Kogan Closes: 966479 Changes: sysdig (0.27.1-0.2) unstable; urgency=medium . * Non-maintainer upload * Fix FTBFS on armhf. Thanks to Paolo Pisati for the patch. (Closes: #966479) Checksums-Sha1: 13fa1ed750b01fd5f43f7e2154f7a2634918d288 2322 sysdig_0.27.1-0.2.dsc 48afd8c89f1a0ca346ac26bf0dd5daccc7a56626 11152 sysdig_0.27.1-0.2.debian.tar.xz b6572828ff0c797f923b0f6552c996df1c1ab99a 9138 sysdig_0.27.1-0.2_amd64.buildinfo Checksums-Sha256: 40f844f786e4d405d91c52be78120d462b2d30a783bec3576ec421c580261564 2322 sysdig_0.27.1-0.2.dsc 4a4ee22f0e44a0023fa5cd1367c912f7382040bc03ecc506695d1bddb22a5411 11152 sysdig_0.27.1-0.2.debian.tar.xz de358f207ef8291ef69199c88faefce4bb0c2d8dc73dcbd34810c5808dd64bb7 9138 sysdig_0.27.1-0.2_amd64.buildinfo Files: ce158676a5e025f146c31e2faef8d133 2322 admin optional sysdig_0.27.1-0.2.dsc 3f9a6ea5eb9ae6fe1a9a61b0737bb5a6 11152 admin optional sysdig_0.27.1-0.2.debian.tar.xz f30c67b37f32d53137afb4d77bb3a425 9138 admin optional sysdig_0.27.1-0.2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdRwTXcLOAUM4CFTz7WO2ElodFWEFAmBFsBoACgkQ7WO2Elod FWHwQg/9G1DX9g2vXcj44TIPPZBhiEN8u05AsLJ+vKx/mz6iY9FSMAAm3aW7vXPJ s/Mys32yCz/27XvEnejN/5v6WZ/ySlbKgbpasgJVfSMnVBUh1J7SsYdvToTWizGe CdR+NbeU5M3hf51KsTPBwu7Gq44P+U/iaFVA6SA7VskLcp8oJggQPjYig3ifq0Jd /fPrhOW/P4ANqbYKDWuI5SgaFaSv7o7PRyyxYTWU9pHuHDptbgONWmWmkyfopgtF V7aIr8/PZyUXfH7/JcTiw70qy32kOPcZHhtlj4N4RjR7PT350+ZV/pwjhGHM+IiR fjjC3oYAMMq9wuGthbXXBA+CL64ibowUZvfzx+ynMWCrvJt73doi6D4ooj5UMdUt VoVFdP9rFnVMSTrKp0oeik3d+fp1D2qAMaY6QdfNdZ8MgV4jfvQAPvDqEQHR04lQ E17fA8AiLbOdZgHVo6wbL3yqu3B06c8/0v6ojA6K1tkgGPYf9a9ROJ6Hw5OrB23C YsSu4sG24Min8dvSQww9ruKoMxxQtQ6llv10FltLtR+JxeSPQUEvDJInRv5i77U3 XWHu0yNCs1RBPDLxC5mjAWybqTKJWH1bErYhWAfnO1BrrODQkqpErZrzDKQpV7TK 9dFDHUUDxounGxF2hBBAS38NxQThXbqoPtGcbXmfnOB8yn25r2Q= =kMvP -END PGP SIGNATURE End Message ---
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
Package: grub-efi-amd64
Version: 2.04-16
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: akum...@gmail.com
Dear Maintainer,
* What led up to the situation?
A Toshiba laptop with a single disk, with GPT partitions, a few days ago
performed a normal upgrade:
...
2021-03-03 16:21:30 status installed man-db:amd64 2.9.4-2
2021-03-04 06:44:34 startup archives unpack
2021-03-04 06:44:34 upgrade grub2-common:amd64 2.04-15 2.04-16
2021-03-04 06:44:34 status half-configured grub2-common:amd64 2.04-15
2021-03-04 06:44:34 status unpacked grub2-common:amd64 2.04-15
2021-03-04 06:44:34 status half-installed grub2-common:amd64 2.04-15
2021-03-04 06:44:34 status triggers-pending man-db:amd64 2.9.4-2
2021-03-04 06:44:34 status unpacked grub2-common:amd64 2.04-16
2021-03-04 06:44:35 upgrade grub-efi-amd64:amd64 2.04-15 2.04-16
2021-03-04 06:44:35 status half-configured grub-efi-amd64:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64:amd64 2.04-15
2021-03-04 06:44:35 status half-installed grub-efi-amd64:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:35 upgrade grub-efi-amd64-bin:amd64 2.04-15 2.04-16
2021-03-04 06:44:35 status half-configured grub-efi-amd64-bin:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64-bin:amd64 2.04-15
2021-03-04 06:44:35 status half-installed grub-efi-amd64-bin:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:35 upgrade grub-common:amd64 2.04-15 2.04-16
2021-03-04 06:44:35 status half-configured grub-common:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-common:amd64 2.04-15
2021-03-04 06:44:35 status half-installed grub-common:amd64 2.04-15
2021-03-04 06:44:36 status unpacked grub-common:amd64 2.04-16
2021-03-04 06:44:36 startup packages configure
2021-03-04 06:44:36 configure grub-common:amd64 2.04-16
2021-03-04 06:44:36 status unpacked grub-common:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub-common:amd64 2.04-16
2021-03-04 06:44:36 status installed grub-common:amd64 2.04-16
2021-03-04 06:44:36 configure grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:36 status unpacked grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:36 status installed grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:36 configure grub2-common:amd64 2.04-16
2021-03-04 06:44:36 status unpacked grub2-common:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub2-common:amd64 2.04-16
2021-03-04 06:44:36 status installed grub2-common:amd64 2.04-16
2021-03-04 06:44:36 configure grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:36 status unpacked grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:49 status installed grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:49 trigproc man-db:amd64 2.9.4-2
2021-03-04 06:44:49 status half-configured man-db:amd64 2.9.4-2
2021-03-04 06:44:50 status installed man-db:amd64 2.9.4-2
...
During the course of this upgrade, I was prompted to run:
$ /usr/share/debconf/fix_db.pl
Do to some debconf database corrupt (I believe the package which prompted this
was either mysql-common or mariadb-common)
I recall some questions / answers related to linux (and potentially grub) being
removed due to there being no corresponding question (or similiar)
* What exactly did you do (or not do) that was effective (or
ineffective)?
Rebooted on 7 Mar
* What was the outcome of this action?
grub went into grub rescue mode and displayed:
error: symbol `grub_is_lockdown` not found
* What outcome did you expect instead?
A reboot into a functioning system.
Currently, I am booting using a rescue CD and then entering commands to
manually start the laptop
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda6 /home ext4 rw,relatime 0 0
/dev/sda2 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/disk/by-id/ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
se
Processed: severity of 958787 is important
Processing commands for cont...@bugs.debian.org:
> severity 958787 important
Bug #958787 {Done: Adrian Bunk } [maven-cache-cleanup]
maven-cache-cleanup needs java-wrappers
Severity set to 'important' from 'serious'
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
958787: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958787
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: Bug#984703 marked as pending in libreoffice
Processing control commands: > tag -1 pending Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Added tag(s) pending. -- 984703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984703: marked as pending in libreoffice
Control: tag -1 pending Hello, Bug #984703 in libreoffice reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/869fece0f2170b3b276d3de149deee12ea41a02d backport upstream fix to not leave a bare trailing : in PYTHONPATH as it causes unconditional loading of encodings.py from . (closes: #984703) (this message was generated automatically) -- Greetings https://bugs.debian.org/984703
Processed: notfixed 984703 in 1:6.4.5-1
Processing commands for cont...@bugs.debian.org: > notfixed 984703 1:6.4.5-1 Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv No longer marked as fixed in versions libreoffice/1:6.4.5-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 984703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: fixed 984703 in 1:6.4.5-1
Processing commands for cont...@bugs.debian.org: > fixed 984703 1:6.4.5-1 Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Marked as fixed in versions libreoffice/1:6.4.5-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 984703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: fixed 984703 in 1:6.4.5-1
Processing commands for cont...@bugs.debian.org: > fixed 984703 1:6.4.5-1 Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Marked as fixed in versions libreoffice/1:6.4.5-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 984703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984696: marked as done (courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/dpkg configurable.)
Your message dated Sun, 07 Mar 2021 22:48:27 + with message-id and subject line Bug#984696: fixed in courier 1.0.16-3 has caused the Debian Bug report #984696, regarding courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/dpkg configurable. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 984696: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984696 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: courier-mta Version: 1.0.16-2 Severity: grave Justification: renders package unusable On current debian bullseye, courier-mta is not startable, looks like some kind of problem in init scripts (but could be executables/environment), as per system info and console log below. Even with all courier packages purged, /etc/courier /???/lib/courier directories completely removed, and start from scratch, installation of courier-base is OK but installing courier-mta consistently fails. This is reproducible on a buster system upgraded to bullseye (i386 and sysvinit-core and no usrmerge) e.g.:- Preconfiguring packages ... Selecting previously unselected package courier-mta. (Reading database ... 42620 files and directories currently installed.) Preparing to unpack .../courier-mta_1.0.14-2_i386.deb ... Adding 'diversion of /usr/bin/addcr to /usr/bin/addcr.ucspi-tcp by courier-mta' Adding 'diversion of /usr/share/man/man1/addcr.1.gz to /usr/share/man/man1/addcr.ucspi-tcp.1.gz by courier-mta' Unpacking courier-mta (1.0.14-2) ... Setting up courier-mta (1.0.14-2) ... update-alternatives: using /usr/bin/lockmail.courier to provide /usr/bin/lockmail (lockmail) in auto mode update-alternatives: using /usr/bin/preline.courier to provide /usr/bin/preline (preline) in auto mode /etc/courier/esmtpd.pem.pem already exists. dpkg: error processing package courier-mta (--configure): installed courier-mta package post-installation script subprocess returned error exit status 1 Processing triggers for man-db (2.9.4-2) ... Errors were encountered while processing: courier-mta E: Sub-process /usr/bin/dpkg returned an error code (1) ALSO (though not quite the same) on a current debian amd64 bullseye chroot (not upgraded) systemd-based host system as well. In that circumstance you get various "Running in chroot, ignoring request." messages for start (which otherwise passes even if mta may not be started), but similar error shows up upon trying to remove/purge courier-mta instead, with error:- Removing courier-mta (1.0.14-2) ... Running in chroot, ignoring request. Stopping Courier MSA server: esmtpd-msa. invoke-rc.d: initscript courier-msa, action "stop" failed. dpkg: error processing package courier-mta (--remove): installed courier-mta package pre-removal script subprocess returned error exit status 1 dpkg: too many errors, stopping locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Errors were encountered while processing: courier-mta Processing was halted because there were too many errors. System info below is from trying the sid/second version (just the courier packages) but exactly the same failure happens either way. This clearly needs looking at for bullseye release. **NB** Have discovered that, at least for the case of new-installing courier-mta 1.0.16-2, adding "exit 0" on the end of /etc/init.d/courier-msa *seems* to be sufficient to allow dpkg configure to work, and courier-mta then seems to start okay. I have considered the non-systemd and non-usrmerge (mkdir path) bugs I could find for courier-mta but these don't seem to apply to this circumstance. This clearly makes the package unusable on bullseye and needs looking at for release. Lots of courier-mta users will be "upgrade" case, I strongly suspect, so working for upgrade cases in older configs is especially important! --Simon -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (50
Bug#984694: marked as done (courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/configurable.)
Your message dated Sun, 07 Mar 2021 22:48:27 + with message-id and subject line Bug#984696: fixed in courier 1.0.16-3 has caused the Debian Bug report #984696, regarding courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/configurable. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 984696: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984696 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: courier-mta Version: 1.0.16-2 Severity: grave Justification: renders package unusable On current debian bullseye, courier-mta is not startable, looks like some kind of problem in init scripts (but could be executables/environment), as per system info and console log below. Even with all courier packages purged, /etc/courier /???/lib/courier directories completely removed, and start from scratch, installation of courier-base is OK but installing courier-mta consistently fails. This is reproducible on a buster system upgraded to bullseye (i386 and sysvinit-core and no usrmerge) e.g.:- Preconfiguring packages ... Selecting previously unselected package courier-mta. (Reading database ... 42620 files and directories currently installed.) Preparing to unpack .../courier-mta_1.0.14-2_i386.deb ... Adding 'diversion of /usr/bin/addcr to /usr/bin/addcr.ucspi-tcp by courier-mta' Adding 'diversion of /usr/share/man/man1/addcr.1.gz to /usr/share/man/man1/addcr.ucspi-tcp.1.gz by courier-mta' Unpacking courier-mta (1.0.14-2) ... Setting up courier-mta (1.0.14-2) ... update-alternatives: using /usr/bin/lockmail.courier to provide /usr/bin/lockmail (lockmail) in auto mode update-alternatives: using /usr/bin/preline.courier to provide /usr/bin/preline (preline) in auto mode /etc/courier/esmtpd.pem.pem already exists. dpkg: error processing package courier-mta (--configure): installed courier-mta package post-installation script subprocess returned error exit status 1 Processing triggers for man-db (2.9.4-2) ... Errors were encountered while processing: courier-mta E: Sub-process /usr/bin/dpkg returned an error code (1) ALSO (though not quite the same) on a current debian amd64 bullseye chroot (not upgraded) systemd-based host system as well. In that circumstance you get various "Running in chroot, ignoring request." messages for start (which otherwise passes even if mta may not be started), but similar error shows up upon trying to remove/purge courier-mta instead, with error:- Removing courier-mta (1.0.14-2) ... Running in chroot, ignoring request. Stopping Courier MSA server: esmtpd-msa. invoke-rc.d: initscript courier-msa, action "stop" failed. dpkg: error processing package courier-mta (--remove): installed courier-mta package pre-removal script subprocess returned error exit status 1 dpkg: too many errors, stopping locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Errors were encountered while processing: courier-mta Processing was halted because there were too many errors. System info below is from trying the sid/second version (just the courier packages) but exactly the same failure happens either way. This clearly needs looking at for bullseye release. --Simon -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.19.0-14-686-pae (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages courier-mta depends on: ii courier-authlib0.71.1-1 ii courier-base 1.0.16-2 ii debconf [debconf-2.0] 1.5.74 ii libc6 2.31-9 ii libcourier-unicode42.1.2-2 ii libgcc-s1 10.2.1-6 ii libgdbm6 1.19-2 ii libidn11 1.33-3 ii libnet-cidr-perl 0.2
Processed: tagging 984703
Processing commands for cont...@bugs.debian.org: > tags 984703 + patch Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 984703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: tagging 984703, tagging 984703
Processing commands for cont...@bugs.debian.org: > tags 984703 + upstream Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Added tag(s) upstream. > tags 984703 + fixed-upstream Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Added tag(s) fixed-upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 984703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: found 984703 in 1:6.1.3~rc1-1, fixed 984703 in 1:7.0.0~rc1-1
Processing commands for cont...@bugs.debian.org: > found 984703 1:6.1.3~rc1-1 Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Marked as found in versions libreoffice/1:6.1.3~rc1-1. > fixed 984703 1:7.0.0~rc1-1 Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Marked as fixed in versions libreoffice/1:7.0.0~rc1-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 984703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system
On 2021-03-07 22:56, Sven Joachim wrote: > On 2021-03-05 14:41 +0100, Aurelien Jarno wrote: > > > control: notfound -1 libc6/2.28-10 > > control: found -1 libc6/2.31-9 > > control: severity -1 grave > > > > On 2021-03-04 19:26, Thomas Hahn wrote: > >> Package: libc6 > >> Version: 2.28-10 > >> Severity: normal > >> X-Debbugs-Cc: thah...@t-online.de > >> > >> Dear Maintainer, > >> > >> installed buster, then apt upgrade was also fine, > >> but the following dist-upgrade put the system in a broken state. > >> > >> Preparing to unpack .../62-locales_2.31-9_all.deb ... > >> Unpacking locales (2.31-9) over (2.28-10) ... > >> Preparing to unpack .../63-openssh-server_1%3a8.4p1-4_amd64.deb ... > >> Unpacking openssh-server (1:8.4p1-4) over (1:7.9p1-10+deb10u2) ... > >> Preparing to unpack .../64-libc6_2.31-9_amd64.deb ... > >> whiptail: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not > >> found (required by /lib/x86_64-linux-gnu/libslang.so.2) > > > > This seems to show that libslang2 has been wrongly unpacked before > > libc6. Do you happen to have the beginning of the log? You can find it > > in /var/log/apt/term.log.* > > > >> debconf: whiptail output the above errors, giving up! > >> Checking for services that may need to be restarted...dpkg: error > >> processing archive > >> /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb (--unpack): > >> new libc6:amd64 package pre-installation script subprocess returned error > >> exit status 255 > >> Selecting previously unselected package libcrypt1:amd64. > >> dpkg: considering deconfiguration of libc6:amd64, which would be broken by > >> installation of libcrypt1:amd64 ... > >> dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64) > >> Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ... > >> De-configuring libc6:amd64 (2.28-10) ... > >> Unpacking libcrypt1:amd64 (1:4.4.17-1) ... > >> Errors were encountered while processing: > >> /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb > >> Error: Timeout was reached > >> E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > To unbreak your system the best would be to unpack libc6 manually using > > the following command: > > dpkg -x /var/cache/apt/libc6_2.31-9_amd64.deb / > > No, never do that! This command actually runs "dpkg-deb -x" which, > unlike "dpkg -i", will silently overwrite symlinks to directories on the > filesystem with directories contained in the package. This is very bad > if /lib is a symlink to /usr/lib (the "usrmerge" layout). Oh I wasn't aware of that, I have fixed broken systems that way, I wasn't aware that it doesn't work for usrmerge systems. Yet another design issue of usrmerge... I guess running the usrmerge script again should fix the system. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0
> "Martin" == Martin Schurz writes: Martin> I have added pam_tally to common-auth and the upgrade did Martin> not stop when installing the new libpam-modules. I believe Martin> the regex is missing these files, since it does not contain Martin> a "-" in the permitted characters. Will fix. Martin> While testing I also noticed, that pam-auth-update gives Martin> some errors on my system. These come from line 710-714 of Martin> the script. Upon further checking I found, that the script Martin> does not handle commented lines. We use "# ..." comments at Martin> the start of our pam-configs. Is that an intented use-case Martin> or should we add an exception to pam-auth-update to filter Martin> comment lines? Not part of this bug; too late for bullseye. Martin> And some final nitpick: It seems I mistyped a capital T Martin> (line 21) into the text templates and this got copied over. Nod, a translator caught this; will fix. Thanks for all your help.
Processed: tagging 984703
Processing commands for cont...@bugs.debian.org: > tags 984703 - moreinfo Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 984703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: tagging 984703
Processing commands for cont...@bugs.debian.org: > tags 984703 - unreproducible Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Removed tag(s) unreproducible. > thanks Stopping processing here. Please contact me if you need assistance. -- 984703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0
Hi Sam, that looks mostly good. Now I had some time to test your changes, and I have some things, that may need another check. I have added pam_tally to common-auth and the upgrade did not stop when installing the new libpam-modules. I believe the regex is missing these files, since it does not contain a "-" in the permitted characters. Currently it chatches these files: # ls -1d /etc/pam.d/* | grep -e '^/etc/pam.d/[0-9a-zA-Z/]*$' /etc/pam.d/chfn /etc/pam.d/chpasswd /etc/pam.d/chsh /etc/pam.d/login /etc/pam.d/newusers /etc/pam.d/other /etc/pam.d/passwd /etc/pam.d/runuser /etc/pam.d/su With a modified search it will also find the common-* files: # ls -1d /etc/pam.d/* | grep -e '^/etc/pam.d/[0-9a-zA-Z/-]*$' /etc/pam.d/chfn /etc/pam.d/chpasswd /etc/pam.d/chsh /etc/pam.d/common-account /etc/pam.d/common-auth /etc/pam.d/common-password /etc/pam.d/common-session /etc/pam.d/common-session-noninteractive /etc/pam.d/login /etc/pam.d/newusers /etc/pam.d/other /etc/pam.d/passwd /etc/pam.d/runuser /etc/pam.d/runuser-l /etc/pam.d/su /etc/pam.d/su-l While testing I also noticed, that pam-auth-update gives some errors on my system. These come from line 710-714 of the script. Upon further checking I found, that the script does not handle commented lines. We use "# ..." comments at the start of our pam-configs. Is that an intented use-case or should we add an exception to pam-auth-update to filter comment lines? And some final nitpick: It seems I mistyped a capital T (line 21) into the text templates and this got copied over.
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
Hi again, Am 07.03.21 um 23:08 schrieb Rene Engelhard: > Am 07.03.21 um 22:45 schrieb Milko Krachounov: >> After some additional testing, checking my environment and inspecting pyuno/ >> source/loader/pyuno_loader.cxx, I want to amend the report, particularly >> about >> 7.0.4 which is not affected (kind of). > > Interestingly, in discussion on #debian-devel it is said that it does :/ > > See below. [...] OK, some more discussion sheds some more light on it and would explain it. From #debian-devel again: 23:10 < _jwilk> OK, I kinda reproduced in buster without setting PYTHONPATH myself. It doesn't crash for me, but it can't open the CSV file. 23:11 < _jwilk> I had to install libreoffice-lightproof-pt-br to trigger the bug. 23:13 < _jwilk> So, yay, mystery solved? 23:14 < _rene_> on sid? 23:14 < _rene_> ah, on buster. yes, probably. 23:15 < _rene_> but according to the submitter and the upstream bug it does not happen on 7.0.x 23:15 < _rene_> guess I need to fire up a buster vm 23:15 < _rene_> (and probably backport the upstream fix to buster. *sigh*) 23:16 < _rene_> yeah, libreoffice-lightproof-* is python. but I have libreoffice-lightproof-en installed, too 23:16 < bunk> libreoffice-lightproof-en makes it reproducible for me on buster 23:17 < _rene_> gah. even on my testing, indeed 23:17 < _rene_> no idea what I tested before, probably I didn't do PYTHONPATH=. 23:17 < _rene_> ok, so it boils down to 23:18 < _rene_> a) buster is affected without interaction (-> bad) 23:18 < _rene_> b) testing/sid is when setting PYTHONPATH=. (-> not ideal, but one shouldn't do so(tm)) 23:21 < _rene_> thus this is something one needs to fix for buster, for testing/sid it's "user error" 23:21 * _jwilk nods. 23:22 < bunk> I see some similarities between a) and https://security-tracker.debian.org/tracker/CVE-2016-1238 23:22 < _rene_> indeed @Salvatore: Want it done via DSA? Regards, Rene
Processed: user debian...@lists.debian.org, usertagging 947277, usertagging 975659, affects 975659 ...
Processing commands for cont...@bugs.debian.org:
> user debian...@lists.debian.org
Setting user to debian...@lists.debian.org (was a...@debian.org).
> usertags 947277 piuparts
There were no usertags set.
Usertags are now: piuparts.
> usertags 975659 piuparts
There were no usertags set.
Usertags are now: piuparts.
> affects 975659 + libaio-ocaml-dev
Bug #975659 [src:libaio-ocaml] libaio-ocaml: FTBFS with ocaml 4.11
Added indication that 975659 affects libaio-ocaml-dev
> usertags 968022 piuparts
There were no usertags set.
Usertags are now: piuparts.
> usertags 936854 piuparts
There were no usertags set.
Usertags are now: piuparts.
> affects 936854 + python3-libewf
Bug #936854 [src:libewf] libewf: Python2 removal in sid/bullseye
Added indication that 936854 affects python3-libewf
> usertags 973778 piuparts
There were no usertags set.
Usertags are now: piuparts.
> affects 973778 + librust-nitrokey-sys-dev
Bug #973778 [src:rust-nitrokey-sys] rust-nitrokey-sys: unsatifiable B-D:
librust-bindgen-0.51+default-dev
Added indication that 973778 affects librust-nitrokey-sys-dev
> usertags 937214 piuparts
There were no usertags set.
Usertags are now: piuparts.
> found 937214 1.11-2
Bug #937214 {Done: Matthias Klose } [src:openturns] openturns:
Python2 removal in sid/bullseye
Bug #966768 {Done: Matthias Klose } [src:openturns] openturns:
Unversioned Python removal in sid/bullseye
Marked as found in versions openturns/1.11-2.
Marked as found in versions openturns/1.11-2.
> affects 937214 + python3-openturns
Bug #937214 {Done: Matthias Klose } [src:openturns] openturns:
Python2 removal in sid/bullseye
Bug #966768 {Done: Matthias Klose } [src:openturns] openturns:
Unversioned Python removal in sid/bullseye
Added indication that 937214 affects python3-openturns
Added indication that 966768 affects python3-openturns
> affects 970454 + libaac-tactics-coq
Bug #970454 [src:aac-tactics] aac-tactics: FTBFS in sid
Added indication that 970454 affects libaac-tactics-coq
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
936854: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936854
937214: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937214
966768: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966768
970454: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970454
973778: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973778
975659: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975659
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: rust-sha-1: several B-D are no longer available
Processing control commands: > affects -1 + librust-sha-1-dev librust-sha-1+std-dev Bug #984742 [src:rust-sha-1] rust-sha-1: several B-D are no longer available Added indication that 984742 affects librust-sha-1-dev and librust-sha-1+std-dev -- 984742: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984742 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984742: rust-sha-1: several B-D are no longer available
Source: rust-sha-1 Version: 0.8.1-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian...@lists.debian.org Usertags: piuparts Control: affects -1 + librust-sha-1-dev librust-sha-1+std-dev The following packages have unmet dependencies: builddeps:rust-sha-1 : Depends: librust-block-buffer-0.7+default-dev but it is not installable Depends: librust-digest-0.8+default-dev but it is not installable Depends: librust-digest-0.8+std-dev but it is not installable Depends: librust-opaque-debug-0.2+default-dev but it is not installable Andreas
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
forwarded 984703 https://bugs.documentfoundation.org/show_bug.cgi?id=121384
thanks
Hi,
Am 07.03.21 um 22:45 schrieb Milko Krachounov:
> After some additional testing, checking my environment and inspecting pyuno/
> source/loader/pyuno_loader.cxx, I want to amend the report, particularly
> about
> 7.0.4 which is not affected (kind of).
Interestingly, in discussion on #debian-devel it is said that it does :/
See below.
> First, I wonder if someone reproduces this on 1:6.1.5-3+deb10u6 (if nobody
> does, I may whip up a VM to exclude other factors next Sunday).
Can try, too. My normal system is normally a stable but was already
upgraded to bullseye, though ("eat your own dogfood") due to the freeze.
> Indeed, however, on 1:7.0.4~rc2-1~bpo10+2 the issue is *NOT* reproducible (at
> least with the given steps, see below), and was only happening entirely due
> to
> a local misconfiguration, as I had a trailing colon inside PYTHONPATH. That
> causes Python 3 to crash with that error. My deepest apologies for polluting
> the report with the wrong information about 7.0.4.
> However, I can still reproduce this on 6.1.5, and changing absolutely nothing
> in the environment, including deletion of ~/.config/libreoffice does not seem
> to stop it, and there is no PYTHONPATH set in any form. I also noticed that
Yeah, LO does itself.
$ grep -r PYTHONPATH /usr/lib/libreoffice/*
/usr/lib/libreoffice/program/unopkg:export
PYTHONPATH="/usr/lib/libreoffice/program"
grep: /usr/lib/libreoffice/program/libpythonloaderlo.so:
Übereinstimmungen in Binärdatei
/usr/lib/libreoffice/program/pythonloader.unorc:PYUNO_LOADER_PYTHONPATH=$ORIGIN
/usr/lib/libreoffice/program/pythonloader.unorc:PYTHONPATH=$PYTHONHOME
$PYTHONHOME/site-packages $PYTHONHOME/lib-dynload $PYTHONHOME/lib-tk $ORIGIN
$
The latter is for scripts via python3-uno though.
> pyuno/source/loader/pyuno_loader.cxx from the buster source does add exactly
> such trailing colon (an issue that has been explicitly fixed in 7.0.4, so
> only
> Buster is affected):
>
> bufPYTHONPATH.append( systemPath );
> bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) );
>
> I see the code for buster-backports (and presumably bullseye) has been
> modified to not leave either trailing colons or colons surrounding an empty
> string by adding three explicit checks (except for one case, which threw off
> my testing):
>
> if (!systemPath.isEmpty())
> {
> if (bAppendSep)
>
> bufPYTHONPATH.append(static_cast(SAL_PATHSEPARATOR));
> bufPYTHONPATH.append(systemPath);
> bAppendSep = true;
> }
>
> const char * oldEnv = getenv( "PYTHONPATH");
> if( oldEnv )
> {
> if (bAppendSep)
> bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR)
> );
> bufPYTHONPATH.append( OUString(oldEnv, strlen(oldEnv),
> osl_getThreadTextEncoding()) );
> }
Yes, this looks like
https://cgit.freedesktop.org/libreoffice/core/commit/?id=327153471ae38abe90463f6272e00aaa996c5ba3
and thus https://bugs.documentfoundation.org/show_bug.cgi?id=121384
(which is filed for writer and not calc, but...)
> P.S. Yeah, LibreOffice doesn't touch encodings.py. The error is produced by
> Python during initialisation as it tries to determine the locale encoding, so
> it happens before any external Python code is executed, and only happens if
> something injects the local directory or an empty string in PYTHONPATH.
Yeah, that was told to me on #debian-devel, too:
22:14 < olly[m]1> seems potentially problematic if PYTHONPATH is
honoured here (since it could find an entirely unrelated encodings.py on
PYTHONPATH),
though not really RC or a security bug AFAICS
22:16 < _rene_> the question also is what calls encodings.py at all
22:17 < _rene_> since LO itself definitely does not
22:22 < _jwilk> Python itself loads it: https://paste.debian.net/1188328
[ content:
$ echo boom > encodings.py
$ export PYTHONPATH=/opt/moo:$PYTHONPATH # oops, if PYTHONPATH is
empty, this adds cwd
$ python3
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/jwilk/encodings.py", line 1, in
NameError: name 'boom' is not defined
Aborted ]
which would support your report. Though I still don't see it.
22:33 < _rene_> and when?
22:34 < _rene_> since PYTHONPATH=. localc test.csv still doesn't load it
22:34 < _rene_> Fatal Python error: initfsencoding: Unable to get the
locale encoding
22:34 < _rene_> only then?
22:34 < _rene_> whatever that means
22:36 < _rene_> Hmm, OK, I do get an error with LANG=en_US PYTHONPATH=.
localc test.csv
22:36 < _rene_> but nothing on the console, though
22:37 < _rene_> ah, LANG=en_US in ~/äöü is not a good idea
22:37 < _rene_> still nothing pythonish, though
22:39 < _jwilk> It does crash here: https://paste.debian.net/1188332
[ content:
$echoboom > encodings.py $echo> foo.csv $PYTHONPATH
Processed: Re: Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
Processing commands for cont...@bugs.debian.org: > forwarded 984703 https://bugs.documentfoundation.org/show_bug.cgi?id=121384 Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Set Bug forwarded-to-address to 'https://bugs.documentfoundation.org/show_bug.cgi?id=121384'. > thanks Stopping processing here. Please contact me if you need assistance. -- 984703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system
On 2021-03-05 14:41 +0100, Aurelien Jarno wrote: > control: notfound -1 libc6/2.28-10 > control: found -1 libc6/2.31-9 > control: severity -1 grave > > On 2021-03-04 19:26, Thomas Hahn wrote: >> Package: libc6 >> Version: 2.28-10 >> Severity: normal >> X-Debbugs-Cc: thah...@t-online.de >> >> Dear Maintainer, >> >> installed buster, then apt upgrade was also fine, >> but the following dist-upgrade put the system in a broken state. >> >> Preparing to unpack .../62-locales_2.31-9_all.deb ... >> Unpacking locales (2.31-9) over (2.28-10) ... >> Preparing to unpack .../63-openssh-server_1%3a8.4p1-4_amd64.deb ... >> Unpacking openssh-server (1:8.4p1-4) over (1:7.9p1-10+deb10u2) ... >> Preparing to unpack .../64-libc6_2.31-9_amd64.deb ... >> whiptail: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not >> found (required by /lib/x86_64-linux-gnu/libslang.so.2) > > This seems to show that libslang2 has been wrongly unpacked before > libc6. Do you happen to have the beginning of the log? You can find it > in /var/log/apt/term.log.* > >> debconf: whiptail output the above errors, giving up! >> Checking for services that may need to be restarted...dpkg: error >> processing archive >> /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb (--unpack): >> new libc6:amd64 package pre-installation script subprocess returned error >> exit status 255 >> Selecting previously unselected package libcrypt1:amd64. >> dpkg: considering deconfiguration of libc6:amd64, which would be broken by >> installation of libcrypt1:amd64 ... >> dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64) >> Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ... >> De-configuring libc6:amd64 (2.28-10) ... >> Unpacking libcrypt1:amd64 (1:4.4.17-1) ... >> Errors were encountered while processing: >> /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb >> Error: Timeout was reached >> E: Sub-process /usr/bin/dpkg returned an error code (1) > > To unbreak your system the best would be to unpack libc6 manually using > the following command: > dpkg -x /var/cache/apt/libc6_2.31-9_amd64.deb / No, never do that! This command actually runs "dpkg-deb -x" which, unlike "dpkg -i", will silently overwrite symlinks to directories on the filesystem with directories contained in the package. This is very bad if /lib is a symlink to /usr/lib (the "usrmerge" layout). Cheers, Sven
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
Hello,
After some additional testing, checking my environment and inspecting pyuno/
source/loader/pyuno_loader.cxx, I want to amend the report, particularly about
7.0.4 which is not affected (kind of).
First, I wonder if someone reproduces this on 1:6.1.5-3+deb10u6 (if nobody
does, I may whip up a VM to exclude other factors next Sunday).
Indeed, however, on 1:7.0.4~rc2-1~bpo10+2 the issue is *NOT* reproducible (at
least with the given steps, see below), and was only happening entirely due to
a local misconfiguration, as I had a trailing colon inside PYTHONPATH. That
causes Python 3 to crash with that error. My deepest apologies for polluting
the report with the wrong information about 7.0.4.
However, I can still reproduce this on 6.1.5, and changing absolutely nothing
in the environment, including deletion of ~/.config/libreoffice does not seem
to stop it, and there is no PYTHONPATH set in any form. I also noticed that
pyuno/source/loader/pyuno_loader.cxx from the buster source does add exactly
such trailing colon (an issue that has been explicitly fixed in 7.0.4, so only
Buster is affected):
bufPYTHONPATH.append( systemPath );
bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) );
I see the code for buster-backports (and presumably bullseye) has been
modified to not leave either trailing colons or colons surrounding an empty
string by adding three explicit checks (except for one case, which threw off
my testing):
if (!systemPath.isEmpty())
{
if (bAppendSep)
bufPYTHONPATH.append(static_cast(SAL_PATHSEPARATOR));
bufPYTHONPATH.append(systemPath);
bAppendSep = true;
}
const char * oldEnv = getenv( "PYTHONPATH");
if( oldEnv )
{
if (bAppendSep)
bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR)
);
bufPYTHONPATH.append( OUString(oldEnv, strlen(oldEnv),
osl_getThreadTextEncoding()) );
}
However, in spite of this fix, I was still able to reproduce a *similar*
(though significantly less impactful) issue on 7.0.4. Since the code checks if
PYTHONPATH is set (as opposed to empty), passing an empty PYTHONPATH causes
LibreOffice to crash in the same manner (while Python 3 itself does not).
With unset PYTHONPATH:
* 1:6.1.5-3+deb10u6 from Buster crashes
* 7.0.4 from Buster Backports and Bullseye DOES NOT crash
With *empty* PYTHONPATH both crash.
$ PYTHONPATH= localc ./test.csv # this triggers it on 7.0.4
$ localc ./test.csv # this triggers it on 6.1.5
Best wishes, and I again apologize for the missing report, and for reporting
an issue that is fixed (-ish) in bullseye and sid.
P.S. Yeah, LibreOffice doesn't touch encodings.py. The error is produced by
Python during initialisation as it tries to determine the locale encoding, so
it happens before any external Python code is executed, and only happens if
something injects the local directory or an empty string in PYTHONPATH.
On неделя, 7 март 2021 г. 22:14:02 EET Rene Engelhard wrote:
> tag 984703 + moreinfo
>
> tag 984703 + unreproducible
>
> thanks
>
>
> Hi,
>
> Am 07.03.21 um 13:34 schrieb Milko Krachounov:
> > When opening any CSV file with LibreOffice Calc, Calc opens and executes
> > encodings.py from the current working directory.
>
> Demonstrably wrong, see below.
>
> > That presumably happens because
> >
> > Some file managers, including Krusader and mc, would launch localc in the
> > current directory, as would running it from the command line (such as
> > `localc file.csv'), thereby running encodings.py from the directory
> > containing the file.
> >
> > The issue is not present when LibreOffice is launched through the
> > application launcher, and the file is opened later through whatever
> > means (neither Open file, nor through a file manager or the command
> > line, since localc already operates in one's $HOME in that instance)
> > To reproduce the issue, one needs to:
> > 1. Close LibreOffice *completely*
> > 2. In an empty directory, create "encodings.py" which raises an exception
>
> Created a encodings.py which contains "foo", which surely is not valid
> python.
>
> > 3. In the same directory (for simplicity), create "file.csv" with some
> >
> >rows.
>
> Did.
>
> 1,2
>
> ö,ä
>
>
> (last line to be sure there is some encoding in there)
>
> > 4. Open "file.csv" with `localc ./file.csv' using the directory containing
> >
> >"encodings.py" (double clicking in krusader and mc leads to the same
> >result)
>
> Done that.
>
> > The result is that LibreOffice crashes with the Python exception raised
> > by the rogue encodings.py, and then exits with an error that reads:
> > Fatal Python error: initfsencoding: Unable to get the locale encoding
>
> Just works here. Opens the .csv as is.
>
> > The problem is present in both Debian Stable (1:6.1.5-3+deb10u6), and
> > Buster Backports (1:7.0.4~rc2-1~bpo10+2).
>
> Tried with 7.0.4-3 on bullseye (which s
Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system
On 2021-03-07 18:26, Thomas Hahn wrote: > On Fri, 5 Mar 2021 14:41:23 +0100 Aurelien Jarno wrote: > > control: notfound -1 libc6/2.28-10 > > control: found -1 libc6/2.31-9 > > control: severity -1 grave > > > > On 2021-03-04 19:26, Thomas Hahn wrote: > > > Package: libc6 > > > Version: 2.28-10 > > > Severity: normal > > > X-Debbugs-Cc: thah...@t-online.de > > > > > > Dear Maintainer, > > > > > > installed buster, then apt upgrade was also fine, > > > but the following dist-upgrade put the system in a broken state. > > > > > > Preparing to unpack .../62-locales_2.31-9_all.deb ... > > > Unpacking locales (2.31-9) over (2.28-10) ... > > > Preparing to unpack .../63-openssh-server_1%3a8.4p1-4_amd64.deb ... > > > Unpacking openssh-server (1:8.4p1-4) over (1:7.9p1-10+deb10u2) ... > > > Preparing to unpack .../64-libc6_2.31-9_amd64.deb ... > > > whiptail: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found > > > (required by /lib/x86_64-linux-gnu/libslang.so.2) > > > > This seems to show that libslang2 has been wrongly unpacked before > > libc6. Do you happen to have the beginning of the log? You can find it > > in /var/log/apt/term.log.* > > > > Attached the section starting with the ill-fated dist-upgrade. Thanks, that confirms the fact that libslang2 is unpacked before. We have to find a solution for this. > > > debconf: whiptail output the above errors, giving up! > > > Checking for services that may need to be restarted...dpkg: error > > > processing archive /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb > > > (--unpack): > > > new libc6:amd64 package pre-installation script subprocess returned > > > error exit status 255 > > > Selecting previously unselected package libcrypt1:amd64. > > > dpkg: considering deconfiguration of libc6:amd64, which would be broken > > > by installation of libcrypt1:amd64 ... > > > dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64) > > > Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ... > > > De-configuring libc6:amd64 (2.28-10) ... > > > Unpacking libcrypt1:amd64 (1:4.4.17-1) ... > > > Errors were encountered while processing: > > > /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb > > > Error: Timeout was reached > > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > To unbreak your system the best would be to unpack libc6 manually using > > the following command: > > dpkg -x /var/cache/apt/libc6_2.31-9_amd64.deb / > > > > Then you should be able to run apt again to fix you system. > > It looked like that did the trick. But then update-initramfs failed. > /lib/modules was EMPTY! Hmm, I fail to see how that's linked to manually unpacking the libc6 package. Do you have a log of the failure? > The same story for 2 machines. > So, for me it looks like the scripts in the control file do some magic > which make it bad right now. > > Thought I would get an automatic reply on all messages, but maybe I > need to subscribe. Your email address was in the To:, but your mail server refused my email. I tried from two non-dialup IPs multiple time, but all my tentative fails: thah...@t-online.de host mx02.t-online.de [194.25.134.9] SMTP error from remote mail server after initial connection: 554 IP=193.70.89.123 - A problem occurred. (Ask your postmaster for help or to contact t...@rx.t-online.de to clarify.) Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system
On 2021-03-07 22:14, Paul Gevers wrote: > Hi, > > On Fri, 5 Mar 2021 14:41:23 +0100 Aurelien Jarno > wrote: > > > Selecting previously unselected package libcrypt1:amd64. > > > dpkg: considering deconfiguration of libc6:amd64, which would be broken > > > by installation of libcrypt1:amd64 ... > > > dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64) > > > Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ... > > > De-configuring libc6:amd64 (2.28-10) ... > > > Unpacking libcrypt1:amd64 (1:4.4.17-1) ... > > > Errors were encountered while processing: > > > /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb > > > Error: Timeout was reached > > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > Could this be the same problem as in bug #974552? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974552 Nope, that's a different issue. libcrypt appears there as a consequence of a the first failure. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#976053: marked as done (sysdig-dkms in unstable fails to build with current kernel)
Your message dated Sun, 07 Mar 2021 21:18:50 + with message-id and subject line Bug#976053: fixed in sysdig 0.27.1-0.1 has caused the Debian Bug report #976053, regarding sysdig-dkms in unstable fails to build with current kernel to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 976053: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976053 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sysdig-dkms Version: 0.26.7-2 Severity: important Dear Maintainer, While trying to install sysdig-dkms in unstable, the building of the kernel module(s) fails with the following messages: DKMS make.log for sysdig-0.26.7 for kernel 5.9.0-3-amd64 (x86_64) Sat 28 Nov 2020 02:28:56 PM GMT make: Entering directory '/usr/src/linux-headers-5.9.0-3-amd64' AR /var/lib/dkms/sysdig/0.26.7/build/built-in.a CC [M] /var/lib/dkms/sysdig/0.26.7/build/main.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/dynamic_params_table.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/fillers_table.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/flags_table.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/ppm_events.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/ppm_fillers.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/event_table.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/syscall_table.o CC [M] /var/lib/dkms/sysdig/0.26.7/build/ppm_cputime.o In file included from /usr/src/linux-headers-5.9.0-3-common/include/linux/export.h:43, from /usr/src/linux-headers-5.9.0-3-common/include/linux/linkage.h:7, from /usr/src/linux-headers-5.9.0-3-common/arch/x86/include/asm/cache.h:5, from /usr/src/linux-headers-5.9.0-3-common/include/linux/cache.h:6, from /usr/src/linux-headers-5.9.0-3-common/include/linux/time.h:5, from /usr/src/linux-headers-5.9.0-3-common/include/linux/compat.h:10, from /var/lib/dkms/sysdig/0.26.7/build/ppm_fillers.c:12: /var/lib/dkms/sysdig/0.26.7/build/ppm_fillers.c: In function ‘ppm_get_tty’: /var/lib/dkms/sysdig/0.26.7/build/ppm_fillers.c:691:15: error: implicit declaration of function ‘probe_kernel_read’; did you mean ‘kernel_read’? [-Werror=implicit-function-declaration] 691 | if (unlikely(probe_kernel_read(&tty, &sig->tty, sizeof(tty | ^ /usr/src/linux-headers-5.9.0-3-common/include/linux/compiler.h:78:42: note: in definition of macro ‘unlikely’ 78 | # define unlikely(x) __builtin_expect(!!(x), 0) | ^ cc1: some warnings being treated as errors make[2]: *** [/usr/src/linux-headers-5.9.0-3-common/scripts/Makefile.build:288: /var/lib/dkms/sysdig/0.26.7/build/ppm_fillers.o] Error 1 make[1]: *** [/usr/src/linux-headers-5.9.0-3-common/Makefile:1796: /var/lib/dkms/sysdig/0.26.7/build] Error 2 make: *** [/usr/src/linux-headers-5.9.0-3-common/Makefile:185: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-headers-5.9.0-3-amd64' Judging by the comments found online, this issue appears to be fixed in version 0.27.1. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_BAD_PAGE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 sysdig-dkms depends on: ii dkms 2.8.3-4 sysdig-dkms recommends no packages. sysdig-dkms suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Source: sysdig Source-Version: 0.27.1-0.1 Done: Dima Kogan We believe that the bug you reported is fixed in the latest version of sysdig, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 976...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Dima Kogan (supplier of updated sysdig package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8
Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system
Hi, On Fri, 5 Mar 2021 14:41:23 +0100 Aurelien Jarno wrote: > > Selecting previously unselected package libcrypt1:amd64. > > dpkg: considering deconfiguration of libc6:amd64, which would be broken by > > installation of libcrypt1:amd64 ... > > dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64) > > Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ... > > De-configuring libc6:amd64 (2.28-10) ... > > Unpacking libcrypt1:amd64 (1:4.4.17-1) ... > > Errors were encountered while processing: > > /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb > > Error: Timeout was reached > > E: Sub-process /usr/bin/dpkg returned an error code (1) Could this be the same problem as in bug #974552? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974552 Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
Hi, On Fri, 20 Nov 2020 13:44:50 +0100 Alois Wohlschlager wrote: > > > > Another option might be to have the new libc6 Conflict with old > > > > versions > > > > of Essential:yes packages that need libcrypt1, forcing those > > > > Essential:yes > > > > packages to get upgraded first. A quick check based on libcrypt1 > > > > reverse > > > > dependencies in sid shows perl-base, login and util-linux. I'm > > > > not sure > > > > if this list is exhaustive, though. > > Having libc6 Conflict with one of those packages should be enough, > right? Shouldn't this bug be reassigned to libc6? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#984479: is this a proper fix?
Do you think that this is a proper fix? diff --git a/debian/fai-nfsroot.preinst b/debian/fai-nfsroot.preinst index a2b5d45e..47402800 100755 --- a/debian/fai-nfsroot.preinst +++ b/debian/fai-nfsroot.preinst @@ -5,7 +5,11 @@ if [ ! -f /.THIS_IS_THE_FAI_NFSROOT ]; then exit 1 fi -dpkg-divert --package fai-nfsroot --add --divert /etc/init.d/rcS.orig --rename /etc/init.d/rcS +case $1 in +install) + dpkg-divert --package fai-nfsroot --add --divert /etc/init.d/rcS.orig --rename /etc/init.d/rcS + ;; +esac
Processed: fixed 984615 in 366-1
Processing commands for cont...@bugs.debian.org: > fixed 984615 366-1 Bug #984615 [src:xterm] xterm: bug in CVE-2021-27135 patch in at least stretch Marked as fixed in versions xterm/366-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 984615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984615 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Merge duplicates
Processing commands for cont...@bugs.debian.org:
> unarchive 777882
Bug #777882 {Done: gregor herrmann } [src:gnokii] gnokii:
ftbfs with GCC-5
Unarchived Bug 777882
> tags 777882 experimental ftbfs
Bug #777882 {Done: gregor herrmann } [src:gnokii] gnokii:
ftbfs with GCC-5
Added tag(s) experimental and ftbfs.
> affects 777882 gnokii-cli libgnokii7
Bug #777882 {Done: gregor herrmann } [src:gnokii] gnokii:
ftbfs with GCC-5
Added indication that 777882 affects gnokii-cli and libgnokii7
> forcemerge 777882 832330
Bug #777882 {Done: gregor herrmann } [src:gnokii] gnokii:
ftbfs with GCC-5
Bug #832330 [src:gnokii] gnokii: FTBFS in experimental: undefined references to
GUI_HideAbout, CloseLogosWindow
Marked Bug as done
Marked as fixed in versions gnokii/0.6.30+dfsg-1.1.
Marked as found in versions gnokii/0.6.30+dfsg-1.
Added tag(s) sid, patch, experimental, and stretch.
Bug #777882 {Done: gregor herrmann } [src:gnokii] gnokii:
ftbfs with GCC-5
Marked as found in versions gnokii/0.6.31+dfsg-2.
Merged 777882 832330
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
777882: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777882
832330: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832330
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
tag 984703 + moreinfo
tag 984703 + unreproducible
thanks
Hi,
Am 07.03.21 um 13:34 schrieb Milko Krachounov:
> When opening any CSV file with LibreOffice Calc, Calc opens and executes
> encodings.py from the current working directory.
Demonstrably wrong, see below.
> That presumably happens because
>
> Some file managers, including Krusader and mc, would launch localc in the
> current directory, as would running it from the command line (such as
> `localc file.csv'), thereby running encodings.py from the directory
> containing the file.
>
> The issue is not present when LibreOffice is launched through the
> application launcher, and the file is opened later through whatever
> means (neither Open file, nor through a file manager or the command
> line, since localc already operates in one's $HOME in that instance)
> To reproduce the issue, one needs to:
> 1. Close LibreOffice *completely*
> 2. In an empty directory, create "encodings.py" which raises an exception
Created a encodings.py which contains "foo", which surely is not valid
python.
> 3. In the same directory (for simplicity), create "file.csv" with some
>rows.
Did.
1,2
ö,ä
(last line to be sure there is some encoding in there)
> 4. Open "file.csv" with `localc ./file.csv' using the directory containing
>"encodings.py" (double clicking in krusader and mc leads to the same
>result)
Done that.
> The result is that LibreOffice crashes with the Python exception raised
> by the rogue encodings.py, and then exits with an error that reads:
> Fatal Python error: initfsencoding: Unable to get the locale encoding
Just works here. Opens the .csv as is.
> The problem is present in both Debian Stable (1:6.1.5-3+deb10u6), and
> Buster Backports (1:7.0.4~rc2-1~bpo10+2).
Tried with 7.0.4-3 on bullseye (which should be identical to the
backport you use in this regard)
> No extensions not installed
> by apt are present on either machine (on the one with 6.1.5 I never
> installed any, and on the 7.0.4 I'm trusting what the LO extension
> manager is telling me, since I cannot recall for sure)
Something else you did?
> Here's the console chatter:
>
> # Test on the host with 1:7.0.4~rc2-1~bpo10+2 - hostname is censored
> milko@host2 ~/Временна/LOSecurity $ cat > encodings.py
Maybe it is because of the *dir* this is in? I am so sure not creating a
cyrillic directory to check.
But even in a ~/öäü I just created, no crash and just an open of the .csv
> raise NotImplementedError("Darth Vader, Obi-Wan and Ahsoka walk into a bar")
> milko@host2 ~/Временна/LOSecurity $ cat > test.csv
> Column 1;Column 2;Column 3
> текст;ຂໍ້ຄວາມ;text
> milko@host2 ~/Временна/LOSecurity $ localc test.csv
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
> File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
> File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> milko@host2 ~/Временна/LOSecurity $ cat > test2.csv
> Column 1;Column 2;Column 3
> text1;text2;text3
> milko@host2 ~/Временна/LOSecurity $ localc test2.csv
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
> File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> Application Error
> milko@host2 ~/Временна/LOSecurity $
Even this doesn't produce any error. (in my ~/aöü)
>> Can yu pleas make this directly a public report in the Debian BTS?
Are you serious? For something unreproducible? Or were you able to
reproduce it?
Regards,
Rene
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
Hi again, Am 07.03.21 um 13:34 schrieb Milko Krachounov: > When opening any CSV file with LibreOffice Calc, Calc opens and executes > encodings.py from the current working directory. That presumably happens > because There also is no mention of any "encodings.py" in anything in LibreOffice itself: rene@frodo:~/LibreOffice/git/libreoffice-7-0-4$ git grep encodings config_host/config_locales.h.in: * support all the locales and character encodings that it has code configure.ac: tables for encodings mainly targeted for a cui/source/tabpages/tpline.cxx:// Convert URL encodings to UI characters (e.g. %20 for spaces) [ internal python3 (which we don't use) encoding stuff stripped ] filter/qa/complex/filter/detection/typeDetection/TypeDetection.java: * is used as source for several encodings. filter/source/graphicfilter/idxf/dxfreprd.cxx:// Its Windows variant, and later releases used ANSI encodings for filter/source/graphicfilter/idxf/dxfreprd.cxx:// encodings for storing to corresponding formats, but there's filter/source/graphicfilter/idxf/dxfreprd.cxx:// $DWGCODEPAGE to encodings mappings filter/source/msfilter/util.cxx:// in last-ditch broken-file-format cases to guess the right 8bit encodings framework/qa/complex/loadAllDocuments/CheckXComponentLoader.java: * is used as source for several encodings. include/filter/msfilter/util.hxx:/// i.e. useful when dealing with legacy formats which use legacy text encodings without recording include/rtl/string.h:for double-byte encodings, UTF-7, UTF-8). include/rtl/tencinfo.h:Can be rather meaningless for encodings that encode global state along include/rtl/tencinfo.h:with the characters (e.g., ISO-2022 encodings). include/rtl/tencinfo.h:Can be rather meaningless for encodings that encode global state along include/rtl/tencinfo.h:with the characters (e.g., ISO-2022 encodings). include/rtl/tencinfo.h:characters (SS2 and SS3) used by some of the EUC encodings (to denote include/rtl/tencinfo.h:repertoire) do not imply that encodings making use of these characters include/rtl/tencinfo.h:have the CONTEXT property. Examples of encodings that do have the include/rtl/tencinfo.h:CONTEXT property are the ISO-2022 encodings and UTF-7. include/rtl/tencinfo.h:special purposes in some encodings. include/rtl/textenc.h:/** The various supported text encodings. include/rtl/textenc.h:Possible values include a wide range of single- and multi-byte encodings include/rtl/textenc.h:the ISO 10646 (Unicode) specific encodings RTL_TEXTENCODING_UCS4 and include/rtl/textenc.h:These encodings are not used for text encodings, only used for include/rtl/textenc.h:font-/textoutput encodings. include/rtl/uri.h:converted to eCharset because it contains (encodings of) unmappable include/rtl/ustring.h:for double-byte encodings, UTF-7, UTF-8). include/rtl/ustring.hxx:encodings, UTF-7, UTF-8). include/rtl/ustring.hxx:encodings, UTF-7, UTF-8). include/svx/txencbox.hxx:/** Fill with all known encodings but exclude those matching one or more include/svx/txencbox.hxx: If nButIncludeInfoFlags is given, encodings are included even if they include/svx/txencbox.hxx:If , some specific encodings are not listed, as they are a include/svx/txencbox.hxx:/** Fill with all encodings known to the dbtools::OCharsetMap but exclude include/svx/txencbox.hxx: If nButIncludeInfoFlags is given, encodings are included even if they include/svx/txencbox.hxx:If , some specific encodings are not listed, as they are a include/svx/txencbox.hxx:/** Fill with all known MIME encodings and select the best according to include/svx/txencbox.hxx:/** Fill with all known encodings but exclude those matching one or more include/svx/txencbox.hxx:If , some specific encodings are not listed, as they are a include/svx/txencbox.hxx:/** Fill with all encodings known to the dbtools::OCharsetMap but exclude include/svx/txencbox.hxx:If , some specific encodings are not listed, as they are a include/tools/tenccvt.hxx:/// encoding. The encodings could be different. sal/osl/unx/nlsupport.cxx: * _nl_language_list[] is an array list of supported encodings. Because sal/osl/unx/nlsupport.cxx: * We are comparing the encodings case insensitive, so the list has sal/qa/rtl/uri/rtl_testuri.cxx:// Check encode with unusual text encodings: sal/rtl/ustring.cxx: code here. Could be the case for apple encodings */ sal/textenc/tcvtbyte.hxx:/** For those encodings only with unicode range of 0x80 to 0xFF. */ sal/textenc/tcvtmb.cxx:/* then share many tables for different charset encodings. */ sal/textenc/tcvtmb.cxx:/* so that extensions that don't consider encodings */ sal/textenc/tcvtmb.cxx:/* so that extensions that don't consider encodin
Processed: tagging 984615
Processing commands for cont...@bugs.debian.org: > tags 984615 + stretch Bug #984615 [src:xterm] xterm: bug in CVE-2021-27135 patch in at least stretch Added tag(s) stretch. > thanks Stopping processing here. Please contact me if you need assistance. -- 984615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984615 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
Processing commands for cont...@bugs.debian.org: > tag 984703 + moreinfo Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Added tag(s) moreinfo. > tag 984703 + unreproducible Bug #984703 [libreoffice-calc] libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv Added tag(s) unreproducible. > thanks Stopping processing here. Please contact me if you need assistance. -- 984703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984689: ruby-vcr: DFSG violation (Hippocratic license)
On Sun, Mar 07, 2021 at 11:01:16PM +0530, Pirate Praveen wrote: > [adding release team] > > On Sun, Mar 7, 2021 at 10:49 pm, Utkarsh Gupta wrote: > > Hi Praveen, > > > > On Sun, Mar 7, 2021 at 10:15 PM Pirate Praveen > > wrote: > > > It looks like we will have to remove ruby-vcr and we will have to > > > disable tests for the following packages. I don't think there is > > > another way, thoughts? > > > > Maybe worth opening an issue upstream and discuss the cons of this > > change or something? Or if that doesn't work out > > and we need this > > I doubt discussing with upstream will yield any possitive outcome as this is > a specific philosophical movement. > > See https://github.com/vcr/vcr/pull/792 > and > https://github.com/vcr/vcr/issues/804 > > > package or something, would forking be an option? > > https://github.com/vcr/vcr/blob/master/CHANGELOG.md#510-feb-5-2020 > > We will have to go back to 5.0 and someone will have to maintain it > independently. > > Hi Release team, > > Do you think this needs to be fixed before bullseye? If yes, do you agree to > change the reverse dependencies listed in my previous message to this bug? I don't think that will be needed. I reverted to 5.0.0 locally, added a few patches, and at least all of our reverse dependencies seem to pass their tests with it: = Testing reverse (build) dependencies rebuild nanoc ... PASS rebuild ruby-coveralls ... PASS autopkgtest ruby-faraday... PASS rebuild ruby-graphlient ... PASS rebuild ruby-mixlib-install ... PASS rebuild ruby-octokit... PASS So in principle we could fix this issue without touching anything else. signature.asc Description: PGP signature
Bug#984547: marked as done (isenkramd failure with with "TypeError: argument should be integer or bytes-like object, not 'str'")
Your message dated Sun, 07 Mar 2021 19:48:24 +
with message-id
and subject line Bug#984547: fixed in isenkram 0.46
has caused the Debian Bug report #984547,
regarding isenkramd failure with with "TypeError: argument should be integer or
bytes-like object, not 'str'"
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
984547: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984547
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: isenkram
Version: 0.45
Severity: serious
X-Debbugs-Cc: hert...@debian.org
I saw this in my logs:
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: Traceback (most recent call
last):
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: File "/usr/bin/isenkramd",
line 400, in uevent_callback
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: if not
is_pkg_installed(pkg):
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: File "/usr/bin/isenkramd",
line 340, in is_pkg_installed
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: if 0 == line.find("ii "):
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: TypeError: argument should
be integer or bytes-like object, not 'str'
It looks like that the package was not fully tested in a Python 3 context
as this is a common failure when you mix binary content and text content.
Cheers,
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
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 isenkram depends on:
ii gir1.2-gtk-3.0 3.24.24-3
ii gir1.2-gudev-1.0 234-1
ii gir1.2-notify-0.7 0.7.9-3
ii gir1.2-packagekitglib-1.0 1.2.2-2
ii isenkram-cli 0.45
ii packagekit 1.2.2-2
ii python33.9.1-1
ii python3-gi 3.38.0-2
isenkram recommends no packages.
isenkram suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Source: isenkram
Source-Version: 0.46
Done: Petter Reinholdtsen
We believe that the bug you reported is fixed in the latest version of
isenkram, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 984...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Petter Reinholdtsen (supplier of updated isenkram package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 07 Mar 2021 20:16:31 +0100
Source: isenkram
Architecture: source
Version: 0.46
Distribution: unstable
Urgency: medium
Maintainer: Petter Reinholdtsen
Changed-By: Petter Reinholdtsen
Closes: 982781 984547
Changes:
isenkram (0.46) unstable; urgency=medium
.
* Updated library metadata.
* Updated generated firmware lists.
* Fix a few fatal leftovers from python 3 migration (Closes: 984547).
* Remove /etc/apt/sources.list.d/isenkram-autoinstall-firmware.list on purge
(Closes: #982781).
Checksums-Sha1:
70443985f730c7bf7b0222669eb03e10653b4469 1825 isenkram_0.46.dsc
62a6e074151e889d14393d0f6a1c80ef13eceb58 196193 isenkram_0.46.tar.gz
9d14796b755f5c41efd21aa4438f4fd621ca3d7d 6389 isenkram_0.46_source.buildinfo
Checksums-Sha256:
7bc4f59a25236f106c75cc1ea90c99131d59f76a8d5e4659df0210aa793bff37 1825
isenkram_0.46.dsc
6979664c5b628d1c4b8b62f31f50cf6646aa391c869d792cd98588d775c858f0 196193
isenkram_0.46.tar.gz
023f96d04e459b8ed26f9565a9f0e181a42d09e6aea7859bee8e36c302ae61e5 6389
isenkram_0.46_source.buildinfo
Files:
fdfe1c4cd8d1cd2c4c70cb63193477b9 1825 misc optional isenkram_0.46.dsc
ff018c6b26d79d20ff4856d8f38d361c 196193 misc optional isenkram_0.46.tar.gz
06d5a4d7020a64e38489cec83f45 6389 misc optional
isenkram_0.46_source.buildinfo
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEERqLf4owIeylOb9kkgSgKoIe6+w4FAmBFJ1IACgkQgSgKoIe6
+w6SbBAAlB2K1xa72NmN1aqsqOAyh3/2eZbcjWYI3UAOI70hPCTkQrrYDmCIOVc8
EH2TW
Processed: rust-sequoia-autocrypt: autopkgtest needs update for new version of rust-sequoia-openpgp: output changed
Processing control commands: > affects -1 src:rust-sequoia-openpgp Bug #984730 [src:rust-sequoia-autocrypt] rust-sequoia-autocrypt: autopkgtest needs update for new version of rust-sequoia-openpgp: output changed Added indication that 984730 affects src:rust-sequoia-openpgp -- 984730: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984730 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984730: rust-sequoia-autocrypt: autopkgtest needs update for new version of rust-sequoia-openpgp: output changed
Source: rust-sequoia-autocrypt
Version: 0.23.0-2
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:rust-sequoia-openpgp
[X-Debbugs-CC: debian...@lists.debian.org,
rust-sequoia-open...@packages.debian.org]
Dear maintainer(s),
With a recent upload of rust-sequoia-openpgp the autopkgtest of
rust-sequoia-autocrypt fails in testing when that autopkgtest is run
with the binary packages of rust-sequoia-openpgp from unstable. It
passes when run with only packages from testing. In tabular form:
passfail
rust-sequoia-openpgp from testing1.1.0-1
rust-sequoia-autocrypt from testing0.23.0-2
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of
rust-sequoia-openpgp to testing [1]. Of course, rust-sequoia-openpgp
shouldn't just break your autopkgtest (or even worse, your package), but
it seems to me that the change in rust-sequoia-openpgp was intended and
your package needs to update to the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from rust-sequoia-openpgp
should really add a versioned Breaks on the unfixed version of (one of
your) package(s). Note: the Breaks is nice even if the issue is only in
the autopkgtest as it helps the migration software to figure out the
right versions to combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=rust-sequoia-openpgp
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-sequoia-autocrypt/10911145/log.gz
failures:
test::autocrypt_header_new stdout
thread 'test::autocrypt_header_new' panicked at 'assertion failed:
`(left == right)`
left: `"3E8877C877274692975189F5D03F6F865226FE8B"`,
right: `"3E88 77C8 7727 4692 9751 89F5 D03F 6F86 5226 FE8B"`',
src/lib.rs:1058:9
stack backtrace:
0: rust_begin_unwind
at /usr/src/rustc-1.48.0/library/std/src/panicking.rs:483
1: std::panicking::begin_panic_fmt
at /usr/src/rustc-1.48.0/library/std/src/panicking.rs:437
2: sequoia_autocrypt::test::autocrypt_header_new
at ./src/lib.rs:1058
3: sequoia_autocrypt::test::autocrypt_header_new::{{closure}}
at ./src/lib.rs:1034
4: core::ops::function::FnOnce::call_once
at /usr/src/rustc-1.48.0/library/core/src/ops/function.rs:227
5: core::ops::function::FnOnce::call_once
at /usr/src/rustc-1.48.0/library/core/src/ops/function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
verbose backtrace.
failures:
test::autocrypt_header_new
test result: FAILED. 6 passed; 1 failed; 0 ignored; 0 measured; 0
filtered out
OpenPGP_signature
Description: OpenPGP digital signature
Bug#982866: marked as done (FTBFS: tests require network access)
Your message dated Sun, 07 Mar 2021 19:18:38 + with message-id and subject line Bug#982866: fixed in ruby-asciidoctor-kroki 0.2.2-3 has caused the Debian Bug report #982866, regarding FTBFS: tests require network access to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 982866: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982866 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: ruby-asciidoctor-kroki Version: 0.2.2-2 Severity: important X-Debbugs-Cc: a...@exmaple.com Dear Maintainer, ruby-asciidoctor-kroki currently fails to build. It looks like some of the tests attempt to access the Internet and download files from kroki.io For an example see Failures: 1) AsciidoctorExtensions::KrokiDiagram should fetch a diagram from Kroki and save it to disk Failure/Error: ::OpenURI.open_uri(uri, 'r', &:read) SocketError: Failed to open TCP connection to kroki.io:443 (getaddrinfo: Temporary failure in name resolution) # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:314:in `get' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:297:in `get_image' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:230:in `save' # ./spec/asciidoctor_kroki_diagram_spec.rb:33:in `block (2 levels) in ' # -- # --- Caused by: --- # SocketError: # getaddrinfo: Temporary failure in name resolution # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:314:in `get' 2) AsciidoctorExtensions::KrokiBlockProcessor convert to html5 should create SVG diagram in imagesdir if kroki-fetch-diagram is set Failure/Error: ::OpenURI.open_uri(uri, 'r', &:read) SocketError: asciidoctor: FAILED: : Failed to load AsciiDoc document - Failed to open TCP connection to kroki.io:443 (getaddrinfo: Temporary failure in name resolution) # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:314:in `get' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:297:in `get_image' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:230:in `save' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:160:in `create_image_src' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:104:in `process' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:36:in `process' # ./spec/asciidoctor_kroki_spec.rb:57:in `block (3 levels) in (required)>' # -- # --- Caused by: --- # SocketError: # getaddrinfo: Temporary failure in name resolution # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:314:in `get' 3) AsciidoctorExtensions::KrokiBlockProcessor convert to html5 should create PNG diagram in imagesdir if kroki-fetch-diagram is set Failure/Error: ::OpenURI.open_uri(uri, 'r', &:read) SocketError: asciidoctor: FAILED: : Failed to load AsciiDoc document - Failed to open TCP connection to kroki.io:443 (getaddrinfo: Temporary failure in name resolution) # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:314:in `get' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:297:in `get_image' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:230:in `save' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:160:in `create_image_src' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:104:in `process' # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:36:in `process' # ./spec/asciidoctor_kroki_spec.rb:70:in `block (3 levels) in (required)>' # -- # --- Caused by: --- # SocketError: # getaddrinfo: Temporary failure in name resolution # ./lib/asciidoctor/extensions/asciidoctor_kroki/extension.rb:314:in `get' Finished in 0.09851 seconds (files took 0.38877 seconds to load) 17 examples, 3 failures More details on https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-asciidoctor-kroki.html -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/3 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 Versions of packages ruby-asciidoctor-kroki depends on: pn ruby-asciidoctor ruby-asciidoctor-kroki r
Bug#982171: libint breaks psi4 autopkgtest: 'str' object is not callable; perhaps you missed a comma?
psi4 1:1.3.2+dfsg-2 and libint 1.2.1-5 uploaded which should be able to migrate together.
Bug#984492: marked as done (autopkg test failures)
Your message dated Sun, 07 Mar 2021 18:21:21 +
with message-id
and subject line Bug#984492: fixed in python-w3lib 1.22.0-3
has caused the Debian Bug report #984492,
regarding autopkg test failures
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
984492: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984492
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:python-w3lib
Version: 1.22.0-2
Severity: serious
Tags: sid bullseye
seen on all architectures, triggered by the python3-defaults upload.
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-w3lib/10824843/log.gz
=== python3.9 ===
= test session starts ==
platform linux -- Python 3.9.2, pytest-6.0.2, py-1.10.0, pluggy-0.13.0
rootdir: /tmp/autopkgtest-lxc.or2rkj_p/downtmp/autopkgtest_tmp
collected 146 items
tests/test_encoding.py ... [ 13%]
tests/test_form.py ... [ 15%]
tests/test_html.py . [ 51%]
[ 51%]
tests/test_http.py ... [ 56%]
tests/test_url.py F. [ 93%]
.. [100%]
=== FAILURES ===
UrlTests.test_add_or_replace_parameter
self =
def test_add_or_replace_parameter(self):
url = 'http://domain/test'
self.assertEqual(add_or_replace_parameter(url, 'arg', 'v'),
'http://domain/test?arg=v')
url = 'http://domain/test?arg1=v1&arg2=v2&arg3=v3'
self.assertEqual(add_or_replace_parameter(url, 'arg4', 'v4'),
'http://domain/test?arg1=v1&arg2=v2&arg3=v3&arg4=v4')
self.assertEqual(add_or_replace_parameter(url, 'arg3', 'nv3'),
'http://domain/test?arg1=v1&arg2=v2&arg3=nv3')
url = 'http://domain/test?arg1=v1;arg2=v2'
> self.assertEqual(add_or_replace_parameter(url, 'arg1', 'v3'),
'http://domain/test?arg1=v3&arg2=v2')
E AssertionError: 'http://domain/test?arg1=v3' !=
'http://domain/test?arg1=v3&arg2=v2'
E - http://domain/test?arg1=v3
E + http://domain/test?arg1=v3&arg2=v2
E ?
tests/test_url.py:303: AssertionError
=== warnings summary ===
tests/test_url.py::UrlTests::test_urljoin_rfc_deprecated
/usr/lib/python3/dist-packages/w3lib/url.py:618: DeprecationWarning:
w3lib.url.urljoin_rfc is deprecated, use urlparse.urljoin instead
warnings.warn("w3lib.url.urljoin_rfc is deprecated, use urlparse.urljoin
instead",
-- Docs: https://docs.pytest.org/en/stable/warnings.html
=== short test summary info
FAILED tests/test_url.py::UrlTests::test_add_or_replace_parameter - Assertion...
=== 1 failed, 145 passed, 1 warning in 0.61s ===
--- End Message ---
--- Begin Message ---
Source: python-w3lib
Source-Version: 1.22.0-3
Done: Andrey Rahmatullin
We believe that the bug you reported is fixed in the latest version of
python-w3lib, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 984...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Andrey Rahmatullin (supplier of updated python-w3lib package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 07 Mar 2021 22:51:14 +0500
Source: python-w3lib
Architecture: source
Version: 1.22.0-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Team
Changed-By: Andrey Rahmatullin
Closes: 984492
Changes:
python-w3lib (1.22.0-3) unstable; urgency=medium
.
[ Ondřej Nový ]
* d/control: Update Maintainer field with new Debian Python Team
contact address.
* d/control: Update Vcs-* fields
Bug#984725: openjdk-11-jre-dcevm: incompatible with newest openjdk-11-jre 11.0.11+4-1
Package: openjdk-11-jre-dcevm Version: 11.0.10+1-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: schissdra...@rmm.li After the last update of openjdk-11-jre from 11.0.10+9-1 to 11.0.11+4-1 dcevm can't be used anymore. The error is: java -dcevm :( [0.040s][error][class] Name nativeParkEventPointer should be in the SymbolTable since its class is loaded Error occurred during initialization of VM Invalid layout of well-known class: java.lang.Thread -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (600, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openjdk-11-jre-dcevm depends on: ii libc62.31-9 ii openjdk-11-jre-headless 11.0.11+4-1 openjdk-11-jre-dcevm recommends no packages. openjdk-11-jre-dcevm suggests no packages.
Processed: Re: Bug#846950: Merge request for nfs-utils to fix bugs #846950, #849942, #849608
Processing control commands: > unmerge 846950 Bug #846950 [nfs-common] nfs-common: RPCGSSDOPTS not replicated to /run/sysconfig/nfs-utils Ignoring request to unmerge a bug which is not merged with any others. > severity 846950 grave Bug #846950 [nfs-common] nfs-common: RPCGSSDOPTS not replicated to /run/sysconfig/nfs-utils Ignoring request to change severity of Bug 846950 to the same value. -- 846950: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846950 849608: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849608 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#846950: Merge request for nfs-utils to fix bugs #846950, #849942, #849608
Processing control commands: > unmerge 846950 Bug #846950 [nfs-common] nfs-common: RPCGSSDOPTS not replicated to /run/sysconfig/nfs-utils Bug #849608 [nfs-common] nfs-common: For rpc.gssd, keytab location is hardcoded to /etc/krb5.keytab Disconnected #846950 from all other report(s). > severity 846950 grave Bug #846950 [nfs-common] nfs-common: RPCGSSDOPTS not replicated to /run/sysconfig/nfs-utils Severity set to 'grave' from 'normal' -- 846950: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846950 849608: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849608 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 981374 is not forwarded, tagging 981374
Processing commands for cont...@bugs.debian.org: > notforwarded 981374 Bug #981374 [electrum] electrum: Ledger wallet not found: Library version for 'ledger' is incompatible. Unset Bug forwarded-to-address > tags 981374 - fixed-upstream Bug #981374 [electrum] electrum: Ledger wallet not found: Library version for 'ledger' is incompatible. Removed tag(s) fixed-upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 981374: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981374 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984689: ruby-vcr: DFSG violation (Hippocratic license)
[adding release team] On Sun, Mar 7, 2021 at 10:49 pm, Utkarsh Gupta wrote: Hi Praveen, On Sun, Mar 7, 2021 at 10:15 PM Pirate Praveen wrote: It looks like we will have to remove ruby-vcr and we will have to disable tests for the following packages. I don't think there is another way, thoughts? Maybe worth opening an issue upstream and discuss the cons of this change or something? Or if that doesn't work out and we need this I doubt discussing with upstream will yield any possitive outcome as this is a specific philosophical movement. See https://github.com/vcr/vcr/pull/792 and https://github.com/vcr/vcr/issues/804 package or something, would forking be an option? https://github.com/vcr/vcr/blob/master/CHANGELOG.md#510-feb-5-2020 We will have to go back to 5.0 and someone will have to maintain it independently. Hi Release team, Do you think this needs to be fixed before bullseye? If yes, do you agree to change the reverse dependencies listed in my previous message to this bug? Thanks Praveen
Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system
On Fri, 5 Mar 2021 14:41:23 +0100 Aurelien Jarno wrote: > control: notfound -1 libc6/2.28-10 > control: found -1 libc6/2.31-9 > control: severity -1 grave > > On 2021-03-04 19:26, Thomas Hahn wrote: > > Package: libc6 > > Version: 2.28-10 > > Severity: normal > > X-Debbugs-Cc: thah...@t-online.de > > > > Dear Maintainer, > > > > installed buster, then apt upgrade was also fine, > > but the following dist-upgrade put the system in a broken state. > > > > Preparing to unpack .../62-locales_2.31-9_all.deb ... > > Unpacking locales (2.31-9) over (2.28-10) ... > > Preparing to unpack .../63-openssh-server_1%3a8.4p1-4_amd64.deb ... > > Unpacking openssh-server (1:8.4p1-4) over (1:7.9p1-10+deb10u2) ... > > Preparing to unpack .../64-libc6_2.31-9_amd64.deb ... > > whiptail: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found > > (required by /lib/x86_64-linux-gnu/libslang.so.2) > > This seems to show that libslang2 has been wrongly unpacked before > libc6. Do you happen to have the beginning of the log? You can find it > in /var/log/apt/term.log.* > Attached the section starting with the ill-fated dist-upgrade. > > debconf: whiptail output the above errors, giving up! > > Checking for services that may need to be restarted...dpkg: error > > processing archive /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb > > (--unpack): > > new libc6:amd64 package pre-installation script subprocess returned error > > exit status 255 > > Selecting previously unselected package libcrypt1:amd64. > > dpkg: considering deconfiguration of libc6:amd64, which would be broken by > > installation of libcrypt1:amd64 ... > > dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64) > > Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ... > > De-configuring libc6:amd64 (2.28-10) ... > > Unpacking libcrypt1:amd64 (1:4.4.17-1) ... > > Errors were encountered while processing: > > /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb > > Error: Timeout was reached > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > To unbreak your system the best would be to unpack libc6 manually using > the following command: > dpkg -x /var/cache/apt/libc6_2.31-9_amd64.deb / > > Then you should be able to run apt again to fix you system. It looked like that did the trick. But then update-initramfs failed. /lib/modules was EMPTY! The same story for 2 machines. So, for me it looks like the scripts in the control file do some magic which make it bad right now. Thought I would get an automatic reply on all messages, but maybe I need to subscribe. > > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net > Thomas Log started: 2021-03-04 15:57:34 Selecting previously unselected package libmfx1:amd64. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 318464 files and directories currently installed.) Preparing to unpack .../00-libmfx1_21.1.0-1_amd64.deb ... Unpacking libmfx1:amd64 (21.1.0-1) ... Selecting previously unselected package libmysofa1:amd64. Preparing to unpack .../01-libmysofa1_1.2~dfsg0-1_amd64.deb ... Unpacking libmysofa1:amd64 (1.2~dfsg0-1) ... Preparing to unpack .../02-libgfortran5_10.2.1-6_amd64.deb ... Unpacking libgfortran5:amd64 (10.2.1-6) over (8.3.0-6) ... Preparing to unpack .../03-liblapack3_3.9.0-3_amd64.deb ... Unpacking liblapack3:amd64 (3.9.0-3) over (3.8.0-2) ... Preparing to unpack .../04-libgdk-pixbuf2.0-0_2.40.2-2_amd64.deb ... Unpacking libgdk-pixbuf2.0-0:amd64 (2.40.2-2) over (2.38.1+dfsg-1) ... Selecting previously unselected package libgdk-pixbuf-xlib-2.0-0:amd64. Preparing to unpack .../05-libgdk-pixbuf-xlib-2.0-0_2.40.2-2_amd64.deb ... Unpacking libgdk-pixbuf-xlib-2.0-0:amd64 (2.40.2-2) ... Preparing to unpack .../06-libgdk-pixbuf2.0-common_2.42.2+dfsg-1_all.deb ... Unpacking libgdk-pixbuf2.0-common (2.42.2+dfsg-1) over (2.38.1+dfsg-1) ... Preparing to unpack .../07-libpng16-16_1.6.37-3_amd64.deb ... Unpacking libpng16-16:amd64 (1.6.37-3) over (1.6.36-6) ... Selecting previously unselected package libdeflate0:amd64. Preparing to unpack .../08-libdeflate0_1.7-1_amd64.deb ... Unpacking libdeflate0:amd64 (1.7-1) ... Preparing to unpack .../09-libtiff5_4.2.0-1_amd64.deb ... Unpacking libtiff5:amd64 (4.2.0-1) over (4.1.0+git191117-2~deb10u1) ... Selecting previously unselected package libgdk-pixbuf-2.0-0:amd64. Preparing to unpack .../10-libgdk-pixbuf-2.0-0_2.42
Bug#984689: ruby-vcr: DFSG violation (Hippocratic license)
On Sun, Mar 7, 2021 at 10:49 PM Utkarsh Gupta wrote: > On Sun, Mar 7, 2021 at 10:15 PM Pirate Praveen > wrote: > > It looks like we will have to remove ruby-vcr and we will have to > > disable tests for the following packages. I don't think there is > > another way, thoughts? > > Maybe worth opening an issue upstream and discuss the cons of this > change or something? Or if that doesn't work out and we need this > package or something, would forking be an option? It looks like they just upgraded to the latest version of the license they were previously using; cf: https://github.com/vcr/vcr/pull/813. I didn't read the license but is it realy a problem? If it is, I know Olle (the upstream dev), maybe we can talk this out and they can revert to the previous version of the license. - u
Bug#984689: ruby-vcr: DFSG violation (Hippocratic license)
Hi Praveen, On Sun, Mar 7, 2021 at 10:15 PM Pirate Praveen wrote: > It looks like we will have to remove ruby-vcr and we will have to > disable tests for the following packages. I don't think there is > another way, thoughts? Maybe worth opening an issue upstream and discuss the cons of this change or something? Or if that doesn't work out and we need this package or something, would forking be an option? - u
Processed: merge 984694 984696
Processing commands for cont...@bugs.debian.org: > merge 984694 984696 Bug #984694 [courier-mta] courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/configurable. Bug #984696 [courier-mta] courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/dpkg configurable. Added tag(s) confirmed. Merged 984694 984696 > #(984696 is good bug, 984694 is duplicate...) > End of message, stopping processing here. Please contact me if you need assistance. -- 984694: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984694 984696: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984696 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: retitle 984716 to gocryptfs: data lost when root file system is full
Processing commands for cont...@bugs.debian.org: > retitle 984716 gocryptfs: data lost when root file system is full Bug #984716 [gocryptfs] gocryptfs: data loos upon full root file system Changed Bug title to 'gocryptfs: data lost when root file system is full' from 'gocryptfs: data loos upon full root file system'. > thanks Stopping processing here. Please contact me if you need assistance. -- 984716: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984716 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984689: ruby-vcr: DFSG violation (Hippocratic license)
It looks like we will have to remove ruby-vcr and we will have to disable tests for the following packages. I don't think there is another way, thoughts? No reverse dependencies. reverse-depends -b ruby-vcr Reverse-Build-Depends * nanoc * ruby-coveralls * ruby-graphlient * ruby-mixlib-install * ruby-octokit
Bug#984716: gocryptfs: data loos upon full root file system
Package: gocryptfs Version: 1.6.1-1+b20 Severity: critical Justification: causes serious data loss Dear Maintainer, I'm using a gocryptfs container. Both the save location and mount point are on partitions other then "/" that where not full. Whilst installing packages with apt the root file system got overfilled. After fixing that situation by deleting log files and rebooting (reboot was necessary as for unknown reasons the root file system still reported to be full) I noticed that the content of some of the directories in the mounted gocryptfs were empty. Running gocryptfs -fsck (...) gave: Using config file at custom location (...) Password: Decrypting master key OpenDir "": invalid entry "._sync_7629b36e80e0.db-wal": illegal base64 data at input byte 0 OpenDir "": invalid entry "._sync_7629b36e80e0.db-shm": illegal base64 data at input byte 0 fsck: corrupt entry in dir "": "._sync_7629b36e80e0.db-wal" fsck: corrupt entry in dir "": "._sync_7629b36e80e0.db-shm" OpenDir "": invalid entry "._sync_7629b36e80e0.db": illegal base64 data at input byte 0 fsck: corrupt entry in dir "": "._sync_7629b36e80e0.db" fsck: error opening dir "(...)": 2=no such file or directory fsck: error opening dir "(...)": 2=no such file or directory fsck: error opening dir "(...)": 2=no such file or directory fsck: error opening dir "(...)": 2=no such file or directory fsck: error opening dir "(...)": 2=no such file or directory fsck: error opening dir "(...)": 2=no such file or directory fsck: error opening dir "(...)": 2=no such file or directory fsck summary: 10 corrupt files Looking into the encrypted directory after that showed that the encrypted data was missing. This wasn't verified before running "gocryptfs -fsck". Interestingly the directories that lost their content are alphabetically last if sorted by encrypted directory name. Both filesystems, the root filesystem and the filesystem that hosts the gocryptfs ecrypted directory are ext4. I can not be sure that this is caused by gocryptfs and not by some underlying filesystem problem, but I think it warents checking if gocryptfs can be dammaged by a filled root file system. For example by not being able to use /tmp? Best Matthias -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gocryptfs depends on: ii libc6 2.28-10 ii libfuse2 2.9.9-1+deb10u1 ii libssl1.1 1.1.1d-0+deb10u5 gocryptfs recommends no packages. gocryptfs suggests no packages. -- no debconf information
Bug#984709: yubikey-luks: Stop exposing challenge in process list
Package: yubikey-luks Version: 0.5.1+29.g5df2b95-5 Severity: grave Justification: confidential information leak Tags: security Hi, Looking at the upstream yubikey-luks repository, I noticed what seems to be an important recent fix, namely for the password (used as the yubikey challenge) being exposed in the process list: https://github.com/cornelinux/yubikey-luks/pull/63 This affects stable, too. The fix from the PR seems simple enough, it just changes four LOC. I looked at the (non-whitespace, non-documentation) diff between our current version and HEAD, and it's not that big. Perhaps the RT would be even be willing to ACK an update to HEAD. Best, Christian
Processed: closing 901780
Processing commands for cont...@bugs.debian.org: > close 901780 Bug #901780 [linkchecker] linkchecker: Should depend on python-xdg Bug #909165 [linkchecker] linkchecker-gui: linkcheker-gui does not start Marked Bug as done Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 901780: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901780 909165: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909165 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984694: courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/configurable.
Control: tags -1 + confirmed Hello Simon, On 07.03.21 11:47, Simon Iremonger wrote: On current debian bullseye, courier-mta is not startable, looks like some kind of problem in init scripts (but could be executables/environment), as per system info and console log below. thanks for filing a bug against Courier. I can reproduce at least the postinst error on a SysV-init syntem. Can I ask you to please file a separate report for the postrm failure? Thank you. Best Regards Markus
Processed: Re: Bug#984694: courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/configurable.
Processing control commands: > tags -1 + confirmed Bug #984694 [courier-mta] courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/configurable. Added tag(s) confirmed. -- 984694: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984694 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#983888: marked as done (python3-adios: leaves alternatives after purge: /etc/alternatives/python-3.9-adios-@MULTIARCH@)
Your message dated Sun, 07 Mar 2021 13:33:26 + with message-id and subject line Bug#983888: fixed in adios 1.13.1-28 has caused the Debian Bug report #983888, regarding python3-adios: leaves alternatives after purge: /etc/alternatives/python-3.9-adios-@MULTIARCH@ to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 983888: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983888 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: python3-adios Version: 1.13.1-27 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-removal-and-or-configuration-purging The leftover files are actually alternatives that were installed by the package but have not been properly removed. While there is ongoing discussion how to remove alternatives correctly (see https://bugs.debian.org/71621 for details) the following strategy should work for regular cases: * 'postinst configure' always installs the alternative * 'prerm remove' removes the alternative * 'postrm remove' and 'postrm disappear' remove the alternative In all other cases a maintainer script is invoked (e.g. upgrade, deconfigure) the alternatives are not modified to preserve user configuration. Removing the alternative in 'prerm remove' avoids having a dangling link once the actual file gets removed, but 'prerm remove' is not called in all cases (e.g. unpacked but not configured packages or disappearing packages) so the postrm must remove the alternative again (update-alternatives gracefully handles removal of non-existing alternatives). Note that the arguments for adding and removing alternatives differ, for removal it's 'update-alternatives --remove '. >From the attached log (scroll to the bottom...): 0m33.2s INFO: Warning: Package purging left files on system: /etc/alternatives/python-3.9-adios-@MULTIARCH@ -> /usr/lib/python3/dist-packages/adios_openmpi/adios_mpi.cpython-39-x86_64-linux-gnu.so not owned /usr/lib/python3/ owned by: python3-adios, python3.9 /usr/lib/python3/dist-packages/owned by: python3-adios, python3.9 /usr/lib/python3/dist-packages/adios_mpi/ owned by: python3-adios /usr/lib/python3/dist-packages/adios_mpi/adios_mpi.cpython-39-x86_64-linux-gnu.so -> /etc/alternatives/python-3.9-adios-@MULTIARCH@not owned The package creates an alternative with an unsubstituted '@MULTIARCH@' in its name, I don't that that was intended. This broken alternative needs to be removed by 'postinst configure'. cheers, Andreas python3-adios_1.13.1-27.log.gz Description: application/gzip --- End Message --- --- Begin Message --- Source: adios Source-Version: 1.13.1-28 Done: Alastair McKinstry We believe that the bug you reported is fixed in the latest version of adios, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 983...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Alastair McKinstry (supplier of updated adios package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 06 Mar 2021 16:35:45 + Source: adios Architecture: source Version: 1.13.1-28 Distribution: unstable Urgency: medium Maintainer: Alastair McKinstry Changed-By: Alastair McKinstry Closes: 983888 983962 Changes: adios (1.13.1-28) unstable; urgency=medium . * postinst/prerm: Ensure generated tags correct. Also cope with situation where supported python changes between install/removal. Closes: #983888 * Change condition to support gfortran >=9, not just <=10. Closes: #983962 Checksums-Sha1: bc5bf9eb9433fc80c750f2915ab9e5bc58f6675c 3066 adios_1.13.1-28.dsc 7a182aedd2d5c42d0dad23b03fa12d7c132eb69f 23936 adios_1.13.1-28.debian.tar.xz Checksums-Sha256: b2085c3899ecc44f86ae0e79ac1e1138399677c131e02fcbbf0fe69c1c04773a 3066 adios_1.13.1-28.dsc 7c00e797b74c8fa6fdc220594276c811e8bfa1561c0e7d600d6641c15d7f3b95 23936 adios_1.13.1-28.debian.tar.xz Files: c349a9fb0a3f1c7a09d550c7c8168618 306
Bug#984672: marked as done (oneisenough: AttributeError: module 'time' has no attribute 'clock')
Your message dated Sun, 07 Mar 2021 13:18:25 + with message-id and subject line Bug#984672: fixed in oneisenough 0.40-6 has caused the Debian Bug report #984672, regarding oneisenough: AttributeError: module 'time' has no attribute 'clock' to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 984672: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984672 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: oneisenough Version: 0.40-5 Severity: grave X-Debbugs-Cc: a...@debian.org oneisenough fails to start because the function time.clock() has been removed in Python 3.8. I believe time.process_time() is the new equivalent but I have not tested the patch yet. Markus -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages oneisenough depends on: ii fonts-dejavu-core 2.37-2 ii python33.9.1-1 pn python3-pygame oneisenough recommends no packages. oneisenough suggests no packages. --- End Message --- --- Begin Message --- Source: oneisenough Source-Version: 0.40-6 Done: Markus Koschany We believe that the bug you reported is fixed in the latest version of oneisenough, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 984...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Markus Koschany (supplier of updated oneisenough package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 07 Mar 2021 13:51:14 +0100 Source: oneisenough Architecture: source Version: 0.40-6 Distribution: unstable Urgency: medium Maintainer: Debian Games Team Changed-By: Markus Koschany Closes: 984672 Changes: oneisenough (0.40-6) unstable; urgency=medium . * Team upload. . [ Markus Koschany ] * Fix AttributeError module 'time' has no attribute 'clock'. (Closes: #984672) * Update standards version to 4.5.1, no changes needed. . [ Debian Janitor ] * Fix day-of-week for changelog entry 0.40-1. Checksums-Sha1: 17fcdde7f3a9af97b8229257908039667faa5a8d 2139 oneisenough_0.40-6.dsc dc758d1bfaa26ff1d3ff928a897438e7a76c54b5 8552 oneisenough_0.40-6.debian.tar.xz 09c8c1f218f8dc63a1e077c286f22d0b8afc6651 5728 oneisenough_0.40-6_amd64.buildinfo Checksums-Sha256: 61d6e949b9842e25e135d997ceb0db373ef26bdeb21645fc526b778609494663 2139 oneisenough_0.40-6.dsc 5b431955bce2d08d4ef61a2e4e5fec48a6f5d9e9442bc54234e92be3754ac946 8552 oneisenough_0.40-6.debian.tar.xz 1152c2c3965562829c63225afee4a92477e45267d3159ead6de0e5bd351c7ad8 5728 oneisenough_0.40-6_amd64.buildinfo Files: 565ee87f189f02032fba4017f2d3c52e 2139 games optional oneisenough_0.40-6.dsc 84411137d82509e4ea69ca7c1859cc04 8552 games optional oneisenough_0.40-6.debian.tar.xz d16a1f5a00c36c05a383f95bff68e0c5 5728 games optional oneisenough_0.40-6_amd64.buildinfo -BEGIN PGP SIGNATURE- iQKjBAEBCgCNFiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmBEz1JfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQPHGFwb0BkZWJp YW4ub3JnAAoJENmtFLlRO1HkzGwP/3OQvLbLg1x3AO7mePMpPSFkLfVJEllugjY7 2OtMoGrwOFkyH/wsZ6qJt+x1tza2GIh24W1NKocUDnzJajHQEr6u/yB5ljJHCl5b TgBnA++IdH+6tOK/7IqDd26TQYWOobrNqPb5Gh2oDninbrUdkRranV322daNS6Cm 3fnOgzGuxlwFYtIiLbPsyOMNU7G+nYaoGxnV+uNej84WZmlnYQcvNbnRoKIJMq9w /i6uIfbr5t0KrP0T2Gu9H9H3CBoxEiqT5xEoJjPbk59++oQpw6TJ5rPSQJ166vKN eieTLdojYsBTRsxDIrIg0IA4juMxIN8M2Ql/mExacTzNmJh1BobdecQl4Ca29lIb ulwII2HhI5kaSgE+ajzQtgxWciknzKGRKnImhSz5kZzAdyyYOgVD8m92I5LyKnCU QIAQgrAfkA1gZx9F3kGgaVXjivN7Lm4Scft90Q/pjj4KSA+81owbNyF1esGN3RpO y7DrgWhDjeHXiA0iBENvM1uIm+7XIpeH2qH7TeDYdSBBwcS69tYk0h2vSIlNsxU1 rZddHvoNkifNms4+dYWE3QXXRTZ9ZlpUyhVRsOim2+MN3YJYPYL3TXqCwfnJoGZ1 vUIkjTBnzcWiJLRvyPm9jBlR4ixIG0jzBTYvQ96IFQdg7V0Re6mn25v5ZydKRTiO JnduUkWv =pp3c -END PGP SIGNATURE End Message ---
Bug#984672: marked as pending in oneisenough
Control: tag -1 pending Hello, Bug #984672 in oneisenough reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/oneisenough/-/commit/385561748feb8e2736f69192cbbd2ae5da4dbdb8 Fix AttributeError module 'time' has no attribute 'clock'. Closes: #984672 (this message was generated automatically) -- Greetings https://bugs.debian.org/984672
Processed: Bug#984672 marked as pending in oneisenough
Processing control commands: > tag -1 pending Bug #984672 [oneisenough] oneisenough: AttributeError: module 'time' has no attribute 'clock' Added tag(s) pending. -- 984672: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984672 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#983379: linux uml segfault
On Sun, 2021-03-07 at 21:22 +0900, Hajime Tazaki wrote: > Sorry that this email is going to be long. In summary, what Johannes > said is right: what objcopy does is not sufficient, and with ld it > transforms as we expected. > > More goes to below. [snip] Interesting, thanks for looking into that! johannes
Processed: Re: Bug#984547: isenkramd failure with with "TypeError: argument should be integer or bytes-like object, not 'str'"
Processing control commands: > tags -1 +patch Bug #984547 [isenkram] isenkramd failure with with "TypeError: argument should be integer or bytes-like object, not 'str'" Added tag(s) patch. -- 984547: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984547 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#984547: isenkramd failure with with "TypeError: argument should be integer or bytes-like object, not 'str'"
Control: tags -1 +patch
[Raphaël Hertzog]
> It looks like that the package was not fully tested in a Python 3 context
> as this is a common failure when you mix binary content and text
> content.
Thank you for bringing this to my attention. Definitely insufficient
testing. I had a look at the code and tried various approaches (use
decode(), decode('utf-8') to convert line, add encoding='utf-8' to
open), but in the end decided that no charset conversion magic is really
needed to find three ascii characters in a byte stream and went with
this approach below. Further testing also exposed other issues, also
fixed below.
diff --git a/isenkramd b/isenkramd
index ab09c9e..aea1fa9 100755
--- a/isenkramd
+++ b/isenkramd
@@ -286,7 +286,7 @@ npkgs = None
def notify_pleaseinstall(notification=None, action=None, data=None):
pkgs = data
-pkgsstr = string.join(pkgs, " ")
+pkgsstr = " ".join(pkgs)
#print pkgs
print("info: button clicked, installing %s" % pkgsstr)
if use_apt_daemon:
@@ -295,7 +295,7 @@ def notify_pleaseinstall(notification=None, action=None,
data=None):
installer = PackageKitInstaller(pkgs)
installer.request_installation()
def notify(bus, vendor, device, pkgs):
-pkgstr = string.join(pkgs, " ")
+pkgstr = " ".join(pkgs)
if 'usb' == bus:
usbdb = isenkram.usb.usbdb()
usbinfo = usbdb.product(vendor, device)
@@ -337,7 +337,7 @@ def is_pkg_installed(packagename):
while True:
retcode = p.poll()
line = p.stdout.readline()
-if 0 == line.find("ii "):
+if 0 == line.find(b"ii "):
retval = True
if(retcode is not None):
break
@@ -402,7 +402,7 @@ def uevent_callback(client, action, device, user_data):
else:
alreadyinstalled.append(pkg)
print("info: not proposing already installed package(s) %s" % \
-string.join(alreadyinstalled, ', '))
+ ', '.join(alreadyinstalled))
if 0 < len(newpkg):
vendorid, deviceid, bcdevice = \
device.get_property("PRODUCT").split("/")
Please test it and let me know if it solve your problem too.
--
Happy hacking
Petter Reinholdtsen
Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv
Package: libreoffice-calc
Version: 1:6.1.5-3+deb10u6
Severity: grave
Tags: security
Justification: user security hole
Dear Maintainer,
When opening any CSV file with LibreOffice Calc, Calc opens and executes
encodings.py from the current working directory. That presumably happens
because
Some file managers, including Krusader and mc, would launch localc in the
current directory, as would running it from the command line (such as
`localc file.csv'), thereby running encodings.py from the directory
containing the file.
The issue is not present when LibreOffice is launched through the
application launcher, and the file is opened later through whatever
means (neither Open file, nor through a file manager or the command
line, since localc already operates in one's $HOME in that instance)
To reproduce the issue, one needs to:
1. Close LibreOffice *completely*
2. In an empty directory, create "encodings.py" which raises an exception
3. In the same directory (for simplicity), create "file.csv" with some
rows.
4. Open "file.csv" with `localc ./file.csv' using the directory containing
"encodings.py" (double clicking in krusader and mc leads to the same
result)
The result is that LibreOffice crashes with the Python exception raised
by the rogue encodings.py, and then exits with an error that reads:
Fatal Python error: initfsencoding: Unable to get the locale encoding
An offer is made to recover the unsaved file (but the list is empty),
relaunching LO sometimes leads to new crashes.
This is NOT the only way the issue happens, I was able to get the
same crash while clicking through the menus or editing an .ods
which initially didn't cause a crash, but those aren't deterministically
reproduced, whereas the .csv route seems to guarantee a crash for me
even when the .csv is ASCII.
The problem is present in both Debian Stable (1:6.1.5-3+deb10u6), and
Buster Backports (1:7.0.4~rc2-1~bpo10+2). No extensions not installed
by apt are present on either machine (on the one with 6.1.5 I never
installed any, and on the 7.0.4 I'm trusting what the LO extension
manager is telling me, since I cannot recall for sure)
Here's the console chatter:
# Test on the host with 1:7.0.4~rc2-1~bpo10+2 - hostname is censored
milko@host2 ~/Временна/LOSecurity $ cat > encodings.py
raise NotImplementedError("Darth Vader, Obi-Wan and Ahsoka walk into a bar")
milko@host2 ~/Временна/LOSecurity $ cat > test.csv
Column 1;Column 2;Column 3
текст;ຂໍ້ຄວາມ;text
milko@host2 ~/Временна/LOSecurity $ localc test.csv
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
milko@host2 ~/Временна/LOSecurity $ cat > test2.csv
Column 1;Column 2;Column 3
text1;text2;text3
milko@host2 ~/Временна/LOSecurity $ localc test2.csv
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in
NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
Application Error
milko@host2 ~/Временна/LOSecurity $
# Test on the host with 1:6.1.5-3+deb10u6 - hostname is censored
# The encodings.py and test.csv were copied from host2
milko@host1 ~/Временни/LOSecurity $ localc test2.csv
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/milko/Временни/LOSecurity/encodings.py", line 1, in
NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
milko@host1 ~/Временни/LOSecurity $ lowriter
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
File "/home/milko/Временни/LOSecurity/encodings.py", line 1, in
NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
^C
milko@host1 ~/Временни/LOSecurity $
LO packages installed on host1 and host2. I do apologize for the untidy
mess with transitional and unpurged packages and leftover from the dawn of
time (especially on host2) -- I didn't expect someone to be looking through
my messy house -- but I have to leave them here in case one of them comes
responsible.
milko@host2 ~ $ dpkg -l | grep -i -e libreoffice -e 1:7.0.4~rc2-1~bpo10+2
ii hyphen-ru 20030310-1
all Russian hyphenation patterns for
LibreOffice/OpenOffice.org
ii jabref-plugin-oo2.10+ds-3
all LibreOffice plugin for JabRef
(transitional dummy package)
ii libjuh-java
Bug#984520: error : symbol 'grub_register_command_lockdown' not found
Hi Dieter, the same error message for the update of grub-pc instead of grub-efi-amd64 has already been reported before this as bug #984426 . -- Marco signature.asc Description: This is a digitally signed message part.
Bug#984702: r-cran-effectsize: autopkgtest regression
Source: r-cran-effectsize Version: 0.4.3-1 Severity: serious Tags: bullseye sid X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Hi Maintainer Since r-cran-rstanarm has migrated to testing, the autopkgtests of r-cran-effectsize are succeeding again on amd64 and armhf. Unfortunately they have regressed on arm64, i386, ppc64el and s390x [1], where they succeeded in the past. I've copied the output below, which is the same on all affected architectures. Regards Graham [1] https://ci.debian.net/packages/r/r-cran-effectsize/ ══ Failed tests ── Failure (test-standardize_parameters.R:94:5): standardize_parameters (lm with ci) ── standardize_parameters(m0, method = "refit")[[2]][-1] (`actual`) not equal to standardize_parameters(m0, method = "smart")[[2]][-1] (`expected`). `actual`: -0.74 0.43 `expected`: -0.74 0.42 ── Failure (test-standardize_parameters.R:98:5): standardize_parameters (lm with ci) ── standardize_parameters(m0, method = "refit", two_sd = TRUE)[[2]][-1] (`actual`) not equal to standardize_parameters(m0, method = "smart", two_sd = TRUE)[[2]][-1] (`expected`). `actual`: -1.48 0.43 `expected`: -1.48 0.42 [ FAIL 2 | WARN 7 | SKIP 5 | PASS 427 ] Error: Test failures Execution halted autopkgtest [15:53:57]: test run-unit-test: ---] autopkgtest [15:53:57]: test run-unit-test: - - - - - - - - - - results - - - - - - - - - - run-unit-testFAIL non-zero exit status 1
Bug#983379: linux uml segfault
Sorry that this email is going to be long. In summary, what Johannes said is right: what objcopy does is not sufficient, and with ld it transforms as we expected. More goes to below. On Sat, 06 Mar 2021 05:22:19 +0900, Johannes Berg wrote: > > On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote: > > > > objcopy (from binutils) can localize symbols (i.e., objcopy -L > > sem_init $orig_file $new_file). > > This doesn't seem to be sufficient. > > > It also does renaming symbols. But > > not sure this is the ideal solution. > > Even that doesn't seem to actually work/help? I still get libcom_err > trying to call UML's sem_init, even after doing > objcopy --redefine-sym sem_init=uml_sem_init > > > > How does UML handle symbol conflicts between userspace code and Linux > > kernel (like this case sem_init) ? AFAIK, libnl has a same symbol as > > Linux kernel (genlmsg_put) and others can possibly do as well. > > I think like I said it just doesn't but since you don't have much > userspace code linked with UML it never really mattered? > > We only link a 'linux' binary, after all. How does LKL handle this > though? It should be far more affected? > > > Despite the objcopy *not* fixing it, this does seem to: with slightly old version: - objcopy/ld version 2.29.1-23.fc28 I confirmed that objcopy (both --redefine-sym and --localize-symbol) only changes symbols of .symtab table. But there is another table, .dynsym table, which is used to resolve. So, the original file looks like this: 1) before objcopy (vmlinux) % readelf -s obj-x86-um/vmlinux |grep -E "sem_init|Symbol table|Num:" Symbol table '.dynsym' contains 179 entries: Num:Value Size TypeBind Vis Ndx Name 129: 60011d3872 FUNCGLOBAL DEFAULT2 sem_init Symbol table '.symtab' contains 38474 entries: Num:Value Size TypeBind Vis Ndx Name 28515: 60011d3872 FUNCGLOBAL DEFAULT2 sem_init 37798: 601e30d562 FUNCGLOBAL DEFAULT 13 sem_init_ns the result object looks like 2) after objcopy (linux) % readelf -s obj-x86-um/linux |grep -E "sem_init|Symbol table|Num:" Symbol table '.dynsym' contains 179 entries: Num:Value Size TypeBind Vis Ndx Name 129: 60011d3872 FUNCGLOBAL DEFAULT2 sem_init Symbol table '.symtab' contains 38474 entries: Num:Value Size TypeBind Vis Ndx Name 28455: 60011d3872 FUNCLOCAL DEFAULT2 sem_init 37798: 601e30d562 FUNCGLOBAL DEFAULT 13 sem_init_ns Only .symtab symbol table is changed to local while .dynsym table is not changed. So, sem_init call from libcom_err.so still can resolve the Linux symbol. On the other hand, ld --version script solution does as we wish. 3) localized with ld % readelf -s obj-x86-um/linux G -E "sem_init|Symbol table|Num:" Symbol table '.dynsym' contains 142 entries: Num:Value Size TypeBind Vis Ndx Name Symbol table '.symtab' contains 38474 entries: Num:Value Size TypeBind Vis Ndx Name 28512: 60011d3872 FUNCLOCAL DEFAULT2 sem_init 37669: 601e2b4562 FUNCLOCAL DEFAULT 13 sem_init_ns Only .symtab table is generated for the sem_init symbol and it's localized. Because the way to build is different from what UML currently does, LKL (and UML binaries) do not have this issue, with a quick check. LKL applies objcopy before generating intermediate file (linux.o), and the symbols of the final binary (linux) are localized and have no .dynsym entries, thus no issue in this case. refs: https://stackoverflow.com/questions/54332797/binding-failure-with-objcopy-redefine-syms https://sourceware.org/legacy-ml/binutils/2019-01/msg00254.html -- Hajime
Bug#984469: guitarix: debian/copyright is inaccurate
On Sat, 6 Mar 2021 18:39:37 +0100 Hermann Meyer wrote: [...] > If it helps, I could mark the files in question as CC-BY-1.0 so that the > copyright file is correct. [...] No! Please do _not_ do that! It would make the situation worse: the two images would become non-free and the Debian package maintainers would need to drop them from the Debian source package, in order to keep it in Debian main. For the avoidance of doubt: the upstream Guitarix project is perfectly fine and does not need any change (as far as this bug is concerned). The only thing to be fixed here is the debian/copyright file in the Debian package. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpR3zz3BoeQz.pgp Description: PGP signature
Bug#984696: courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/dpkg configurable.
Package: courier-mta Version: 1.0.16-2 Severity: grave Justification: renders package unusable On current debian bullseye, courier-mta is not startable, looks like some kind of problem in init scripts (but could be executables/environment), as per system info and console log below. Even with all courier packages purged, /etc/courier /???/lib/courier directories completely removed, and start from scratch, installation of courier-base is OK but installing courier-mta consistently fails. This is reproducible on a buster system upgraded to bullseye (i386 and sysvinit-core and no usrmerge) e.g.:- Preconfiguring packages ... Selecting previously unselected package courier-mta. (Reading database ... 42620 files and directories currently installed.) Preparing to unpack .../courier-mta_1.0.14-2_i386.deb ... Adding 'diversion of /usr/bin/addcr to /usr/bin/addcr.ucspi-tcp by courier-mta' Adding 'diversion of /usr/share/man/man1/addcr.1.gz to /usr/share/man/man1/addcr.ucspi-tcp.1.gz by courier-mta' Unpacking courier-mta (1.0.14-2) ... Setting up courier-mta (1.0.14-2) ... update-alternatives: using /usr/bin/lockmail.courier to provide /usr/bin/lockmail (lockmail) in auto mode update-alternatives: using /usr/bin/preline.courier to provide /usr/bin/preline (preline) in auto mode /etc/courier/esmtpd.pem.pem already exists. dpkg: error processing package courier-mta (--configure): installed courier-mta package post-installation script subprocess returned error exit status 1 Processing triggers for man-db (2.9.4-2) ... Errors were encountered while processing: courier-mta E: Sub-process /usr/bin/dpkg returned an error code (1) ALSO (though not quite the same) on a current debian amd64 bullseye chroot (not upgraded) systemd-based host system as well. In that circumstance you get various "Running in chroot, ignoring request." messages for start (which otherwise passes even if mta may not be started), but similar error shows up upon trying to remove/purge courier-mta instead, with error:- Removing courier-mta (1.0.14-2) ... Running in chroot, ignoring request. Stopping Courier MSA server: esmtpd-msa. invoke-rc.d: initscript courier-msa, action "stop" failed. dpkg: error processing package courier-mta (--remove): installed courier-mta package pre-removal script subprocess returned error exit status 1 dpkg: too many errors, stopping locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Errors were encountered while processing: courier-mta Processing was halted because there were too many errors. System info below is from trying the sid/second version (just the courier packages) but exactly the same failure happens either way. This clearly needs looking at for bullseye release. **NB** Have discovered that, at least for the case of new-installing courier-mta 1.0.16-2, adding "exit 0" on the end of /etc/init.d/courier-msa *seems* to be sufficient to allow dpkg configure to work, and courier-mta then seems to start okay. I have considered the non-systemd and non-usrmerge (mkdir path) bugs I could find for courier-mta but these don't seem to apply to this circumstance. This clearly makes the package unusable on bullseye and needs looking at for release. Lots of courier-mta users will be "upgrade" case, I strongly suspect, so working for upgrade cases in older configs is especially important! --Simon -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.19.0-14-686-pae (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages courier-mta depends on: ii courier-authlib0.71.1-1 ii courier-base 1.0.16-2 ii debconf [debconf-2.0] 1.5.74 ii libc6 2.31-9 ii libcourier-unicode42.1.2-2 ii libgcc-s1 10.2.1-6 ii libgdbm6 1.19-2 ii libidn11 1.33-3 ii libnet-cidr-perl 0.20-1 ii libperl5.325.32.1-2 ii libstdc++6 10.2.1-6 ii perl 5.32.1-2 ii sysvinit-utils 2.96-6 ii wget 1.21-1 courier-mta recommends no packages. Versions of p
Bug#984694: courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/configurable.
Package: courier-mta Version: 1.0.16-2 Severity: grave Justification: renders package unusable On current debian bullseye, courier-mta is not startable, looks like some kind of problem in init scripts (but could be executables/environment), as per system info and console log below. Even with all courier packages purged, /etc/courier /???/lib/courier directories completely removed, and start from scratch, installation of courier-base is OK but installing courier-mta consistently fails. This is reproducible on a buster system upgraded to bullseye (i386 and sysvinit-core and no usrmerge) e.g.:- Preconfiguring packages ... Selecting previously unselected package courier-mta. (Reading database ... 42620 files and directories currently installed.) Preparing to unpack .../courier-mta_1.0.14-2_i386.deb ... Adding 'diversion of /usr/bin/addcr to /usr/bin/addcr.ucspi-tcp by courier-mta' Adding 'diversion of /usr/share/man/man1/addcr.1.gz to /usr/share/man/man1/addcr.ucspi-tcp.1.gz by courier-mta' Unpacking courier-mta (1.0.14-2) ... Setting up courier-mta (1.0.14-2) ... update-alternatives: using /usr/bin/lockmail.courier to provide /usr/bin/lockmail (lockmail) in auto mode update-alternatives: using /usr/bin/preline.courier to provide /usr/bin/preline (preline) in auto mode /etc/courier/esmtpd.pem.pem already exists. dpkg: error processing package courier-mta (--configure): installed courier-mta package post-installation script subprocess returned error exit status 1 Processing triggers for man-db (2.9.4-2) ... Errors were encountered while processing: courier-mta E: Sub-process /usr/bin/dpkg returned an error code (1) ALSO (though not quite the same) on a current debian amd64 bullseye chroot (not upgraded) systemd-based host system as well. In that circumstance you get various "Running in chroot, ignoring request." messages for start (which otherwise passes even if mta may not be started), but similar error shows up upon trying to remove/purge courier-mta instead, with error:- Removing courier-mta (1.0.14-2) ... Running in chroot, ignoring request. Stopping Courier MSA server: esmtpd-msa. invoke-rc.d: initscript courier-msa, action "stop" failed. dpkg: error processing package courier-mta (--remove): installed courier-mta package pre-removal script subprocess returned error exit status 1 dpkg: too many errors, stopping locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Errors were encountered while processing: courier-mta Processing was halted because there were too many errors. System info below is from trying the sid/second version (just the courier packages) but exactly the same failure happens either way. This clearly needs looking at for bullseye release. --Simon -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.19.0-14-686-pae (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages courier-mta depends on: ii courier-authlib0.71.1-1 ii courier-base 1.0.16-2 ii debconf [debconf-2.0] 1.5.74 ii libc6 2.31-9 ii libcourier-unicode42.1.2-2 ii libgcc-s1 10.2.1-6 ii libgdbm6 1.19-2 ii libidn11 1.33-3 ii libnet-cidr-perl 0.20-1 ii libperl5.325.32.1-2 ii libstdc++6 10.2.1-6 ii perl 5.32.1-2 ii sysvinit-utils 2.96-6 ii wget 1.21-1 courier-mta recommends no packages. Versions of packages courier-mta suggests: pn courier-doc pn courier-filter-perl pn couriergrey pn mail-reader -- Configuration Files: /etc/courier/aliases/system [Errno 13] Permission denied: '/etc/courier/aliases/system' /etc/courier/esmtpauthclient [Errno 13] Permission denied: '/etc/courier/esmtpauthclient' /etc/courier/esmtpd.cnf [Errno 13] Permission denied: '/etc/courier/esmtpd.cnf' -- debconf information: courier-mta/dsnfrom: mailer-dae...@muddle.enyc.org.uk courier-mta/defaultdomain: muddle.enyc.org.uk
Bug#978625: marked as done (src:prads: invalid maintainer address)
Your message dated Sun, 07 Mar 2021 09:33:28 + with message-id and subject line Bug#978625: fixed in prads 0.3.3-6 has caused the Debian Bug report #978625, regarding src:prads: invalid maintainer address to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 978625: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978625 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: prads Version: 0.3.3-5 Severity: serious X-Debbugs-Cc: Stig Sandbeck Mathisen The maintainer address is invalid, see below. Ansgar Forwarded Message Subject: Mail delivery failed: returning message to sender Date: Sat, 26 Dec 2020 18:04:58 + > This message was created automatically by mail delivery software. > > A message that you sent could not be delivered to one or more of its > recipients. This is a permanent error. The following address(es) > failed: > > prads-de...@projects.linpro.no > retry timeout exceeded --- End Message --- --- Begin Message --- Source: prads Source-Version: 0.3.3-6 Done: Stig Sandbeck Mathisen We believe that the bug you reported is fixed in the latest version of prads, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 978...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Stig Sandbeck Mathisen (supplier of updated prads package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 07 Mar 2021 10:06:15 +0100 Source: prads Architecture: source Version: 0.3.3-6 Distribution: unstable Urgency: medium Maintainer: Stig Sandbeck Mathisen Changed-By: Stig Sandbeck Mathisen Closes: 978625 Changes: prads (0.3.3-6) unstable; urgency=medium . * debian/control: Update packaging contact information (Closes: #978625) Checksums-Sha1: b942a1a6a063abe6ca21843b62dd02263b0e3b2e 2034 prads_0.3.3-6.dsc 9238a4b779cd6eb21e28e0c4a32c5e75df0b3bf8 7684 prads_0.3.3-6.debian.tar.xz Checksums-Sha256: d2c5e0a456152faa0f526ed884e0a9f400f7be6eb100dcd307fe5d94b1aaf8bb 2034 prads_0.3.3-6.dsc b265453832c9b2621cadfc1eb085a69704f94fb91ae511dfc42ac90d9751866a 7684 prads_0.3.3-6.debian.tar.xz Files: efe8133595881e79501b82fd3c6ddd53 2034 utils optional prads_0.3.3-6.dsc 2e0899979fd12a26d7f43613242ad213 7684 utils optional prads_0.3.3-6.debian.tar.xz -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEeZ5n7uInSAMeBaLcfbqVjBwFVTgFAmBEmZ4PHHNzbUBkZWJp YW4ub3JnAAoJEH26lYwcBVU4onUP/0aU4yrn0XB6E1e22a60ZHc8r8gaDnbjth6C paEIlBKnH/brNn2MUZmPvwyiki3SP0GlXZZPWB0N94q7kaudrR8Z43Ni6/0eMuRA 3Wch1S/AakRYpzpp67D12VP20etXuKD/kr6X11xc3NkToo4jo7XPMX9HhPIB+Uig 0yZvU9UdUhfd8xR6JGpS7NReJ+BgWoslcltXdIEqqfusMKYWpfTx23Q6EZ9gcaLn FBPLY//ApHBa3Vc9iBQ2bwJL9uQXjv0qP4LrltkB3y8/bAFLM1TfXPNJbmLp9M2d UpZdH+zsRH94MqvUngU+UrV8N7XPJD7bHUISGwb6lDVy378gZEzbq1lxz9Ia8yO5 hSEAS+AsCIfkb/jn4UFxCFP/yrIHqmRjkG12qb7seCYnHOXuFVRnGq7N3Iwb5Ikm g3Scu3p2lsiVdyoX+OCBTbOaMUtIUTEW13tn4u+5j+0CeTEfUMqugk7DmARxpaLl eHe+Uioy7ChlwTr0rdoI8YLhJHspqI9zXClBiC1A7mcy2w/qy6bio+84aSGvr/nB G0ndUCURa3FHvWpK5AjLVuwhhkr4D5WEAFafdWMaVMxmli75G/slE7BvTjEUWexZ HaEd/zyNBjbUqSKT8R3OPJgC1eJ066pvMxhM0WNdKfGhJrjBxsX7tXZs19kOIXmX 5j9jISWZ =m+lK -END PGP SIGNATURE End Message ---
