Bug#1078556: bash: 5.2.21-2.1 to 5.2.21-2.1+b1 breaks printf %.2f .1
Package: bash Version: 5.2.21-2.1+b1 Severity: normal Dear Maintainer, Using bash 5.2.21-2.1, `printf '%.2f\n' .1` (or any other float value) produces the expected result. After upgrade to bash package 5.2.21-2.1+b1, that same statement outputs either: - 0.00 - -0.00 - a random float value, with a large number of digits to the left of the decimal separator. I noticed this on my laptop and was able to reproduce the bug using a Debian Sid-based podman container of mine: --- 8< $ podman run --rm -i kindwolf/unstable-shell:2024080501 < /dev/null 2>&1 && apt install bash > /dev/null 2>&1 dpkg -l bash bash -c "printf '%.2f\n' 0.1" bash -c "printf '%.2f\n' 0.1" bash -c "printf '%.2f\n' 0.1" bash -c "printf '%.2f\n' 0.1" EOF 0.10 0.10 0.10 0.10 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii bash 5.2.21-2.1 amd64GNU Bourne Again SHell Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-=--= ii bash 5.2.21-2.1+b1 amd64GNU Bourne Again SHell 6109438027055380006607751[abridged]65066323432594610641285551911364642996224.00 -584981660093124326370703[abridged]70191893948199565939443678471705365315584.00 5363123171977038804941351[abridged]23734249005160240020871689125814289301504.00 5601186210462057897385212[abridged]67104256981197088027398783407112107065344.00 --- 8< I got these results on: - a 2016 Intel CPU - a 2024 AMD CPU and thus assume this regression is not hardware-specific. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.10.3-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 bash depends on: ii base-files 13.5 ii debianutils 5.20 ii libc62.39-6 ii libtinfo66.5-2 Versions of packages bash recommends: ii bash-completion 1:2.14.0-1 Versions of packages bash suggests: pn bash-doc -- Configuration Files: /etc/bash.bashrc changed [not included] -- no debconf information
Bug#918464: nocache.c:148: init_mutexes: Assertion `fds_lock != NULL' failed.
Package: nocache Version: 1.1-1+b1 Followup-For: Bug #918464 Addendum: this issue was seemingly fixed upstream: https://github.com/Feh/nocache/commit/7451e161997d4282dd6b66fd1514b5b157b41f8a Therefore, this bug could be fixed by packaging nocache v1.2, tagged two years ago.
Bug#918464: nocache.c:148: init_mutexes: Assertion `fds_lock != NULL' failed.
Package: nocache Version: 1.1-1+b1 Followup-For: Bug #918464 Hi, Following a full-upgrade on two Debian Sid hosts of mine on 2024-06-02 around 21:55 UTC, I have just stumbled upon this issue. It matches the explanation provided by Sven and can be worked around by lowering the hard NOFILE rlimit, e.g. ulimit -Hn 1 However, the fact that nocache, a program typically used to leave global memory usage untouched, triggers an OOM is particularly ironic. It would be nice if this could be fixed, either in nocache itself or by adjusting default rlimits. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 nocache depends on: ii libc6 2.38-12 nocache recommends no packages. nocache suggests no packages. -- no debconf information
Bug#1064123: libgl1-mesa-dri: latest version crashes X, can't use mouse/keyboard
Dear Maintainer, I confirm this issue. I experienced it with an AMD R7 240 graphics card[1] on a regular Debian Sid host running kernel 6.6.15. Booting with the previous kernel (6.6.13) did not change the situation but I confirm "Accel" "no", as suggested by Grégory, is a suitable workaround. The machine that experiences this issue idles most of the time, so let me know if I can do/provide anything that would help solving this. Cheers, -- Xavier G. [1] lspci: Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO [Radeon R7 240/340 / Radeon 520]
Bug#1036197: ibus-pinyin setup broken with Python >= 3.10 due to gettext.bind_textdomain_codeset
Package: ibus-pinyin
Version: 1.5.0-8
Severity: important
Dear Maintainer,
How to reproduce?
- ensure you are running a flavour of Debian that features Python >= 3.10
- install ibus and ibus-pinyin
- run ibus-setup in a terminal
- select the "Input Method" tab
- click "Add" > Chinese > Pinyin > Add
- select "Chinese - Pinyin"
- click Preferences
Outcome:
1. no dialog appear on screen
2. the following Python stacktrace appears in the terminal:
Traceback (most recent call last):
File "/usr/share/ibus-pinyin/setup/main.py", line 428, in
main()
File "/usr/share/ibus-pinyin/setup/main.py", line 424, in main
PreferencesDialog(name).run()
^^^
File "/usr/share/ibus-pinyin/setup/main.py", line 44, in __init__
gettext.bind_textdomain_codeset("ibus-pinyin", "UTF-8")
^^^
AttributeError: module 'gettext' has no attribute 'bind_textdomain_codeset'
The python documentation[1] reports that
gettext.bind_textdomain_codeset(domain, codeset=None) is "Deprecated since
version 3.8, removed in version 3.10", hence the stacktrace.
Let me know if you need further information.
[1] https://docs.python.org/3.10/library/gettext.html
-- System Information:
Debian Release: 12.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-8-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages ibus-pinyin depends on:
ii gir1.2-gtk-3.0 3.24.37-2
ii gir1.2-ibus-1.0 1.5.27-5
ii libc62.36-9
ii libgcc-s112.2.0-14
ii libglib2.0-0 2.74.6-2
ii libibus-1.0-51.5.27-5
ii liblua5.4-0 5.4.4-3
ii libpyzy-1.0-0v5 1.0.1-8
ii libsqlite3-0 3.40.1-2
ii libstdc++6 12.2.0-14
ii python3 3.11.2-1+b1
ii python3-gi 3.42.2-3+b1
ii python3-xdg 0.28-2
ibus-pinyin recommends no packages.
ibus-pinyin suggests no packages.
-- no debconf information
Bug#1010000: podman run panics with "assignment to entry in nil map"
Package: podman
Version: 3.4.7+ds1-2
Followup-For: Bug #101
Dear Maintainer,
Unfortunately, it seems upgrading from 3.4.7+ds1-1 to 3.4.7+ds1-2 does not
solve the issue reported by Norbert.
I tested as root user to avoid potential rootless-induced issues:
# dpkg -l podman
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==---==
ii podman 3.4.7+ds1-2 amd64engine to run OCI-based containers
in Pods
# podman run alpine date
panic: assignment to entry in nil map
goroutine 1 [running]:
github.com/opencontainers/runtime-tools/generate.(*Generator).addEnv(...)
github.com/opencontainers/runtime-tools/generate/generate.go:532
github.com/opencontainers/runtime-tools/generate.(*Generator).AddProcessEnv(0xc00053da20,
{0x17edeb7, 0x8}, {0xc0004022c0, 0xc})
github.com/opencontainers/runtime-tools/generate/generate.go:508 +0x2ea
github.com/containers/podman/libpod.(*Container).generateSpec(0xc00031e790,
{0x1ad3150, 0xc000228d20})
github.com/containers/podman/libpod/container_internal_linux.go:648
+0x2965
github.com/containers/podman/libpod.(*Container).init(0xc00031e790, {0x1ad3150,
0xc000228d20}, 0x0)
github.com/containers/podman/libpod/container_internal.go:1098 +0x8e
github.com/containers/podman/libpod.(*Container).prepareToStart(0xc00031e790,
{0x1ad3150, 0xc000228d20}, 0xa8?)
github.com/containers/podman/libpod/container_internal.go:875 +0x345
github.com/containers/podman/libpod.(*Container).StartAndAttach(0xc00031e790,
{0x1ad3150?, 0xc000228d20?}, 0xc0006300c0, {0x17f5ed4, 0xd}, 0xc949c0,
0xb0?)
github.com/containers/podman/libpod/container_api.go:115 +0x145
github.com/containers/podman/pkg/domain/infra/abi/terminal.StartAttachCtr({0x1ad3150,
0xc000228d20}, 0xc00031e790, 0xc10018, 0xc10020, 0x0, {0x17f5ed4,
0xd}, 0x1, 0x1)
github.com/containers/podman/pkg/domain/infra/abi/terminal/terminal_linux.go:91
+0x546
github.com/containers/podman/pkg/domain/infra/abi.(*ContainerEngine).ContainerRun(0xc0001249f8,
{0x1ad3150, 0xc000228d20}, {{0x0, 0x0}, 0x0, {0x17f5ed4, 0xd}, 0xc10020,
0x0, ...})
github.com/containers/podman/pkg/domain/infra/abi/containers.go:957
+0x31e
github.com/containers/podman/cmd/podman/containers.run(0x25046a0?,
{0xc4ae60?, 0x2, 0x2})
github.com/containers/podman/cmd/podman/containers/run.go:194 +0x7e6
github.com/spf13/cobra.(*Command).execute(0x25046a0, {0xc3c0a0, 0x2, 0x2})
github.com/spf13/cobra/command.go:856 +0x67c
github.com/spf13/cobra.(*Command).ExecuteC(0x251b3a0)
github.com/spf13/cobra/command.go:974 +0x3b4
github.com/spf13/cobra.(*Command).Execute(...)
github.com/spf13/cobra/command.go:902
github.com/spf13/cobra.(*Command).ExecuteContext(...)
github.com/spf13/cobra/command.go:895
main.Execute()
github.com/containers/podman/cmd/podman/root.go:91 +0xc5
main.main()
github.com/containers/podman/cmd/podman/main.go:39 +0x74
Let me know if there is anything I can do to help on this matter.
Thanks for your work.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages podman depends on:
ii conmon 2.0.25+ds1-1.1
ii containernetworking-plugins 1.1.0+ds1-1
ii crun 0.17+dfsg-1.1
ii golang-github-containers-common 0.44.5+ds1-1
ii libc62.33-7
ii libdevmapper1.02.1 2:1.02.175-2.1
ii libgpgme11 1.16.0-1.2
ii libseccomp2 2.5.4-1
ii runc 1.1.1+ds1-1
Versions of packages podman recommends:
ii buildah 1.23.1+ds1-2
pn catatonit | tini | dumb-init
ii fuse-overlayfs1.8.2-1
pn golang-github-containernetworking-plugin-dnsname
ii slirp4netns 1.0.1-2
ii uidmap1:4.11.1+dfsg1-2
Versions of packages podman suggests:
ii containers-storage 1.37.2+ds1-1
ii docker-compose 1.29.2-1
ii iptables1.8.7-1
-- no debconf information
Bug#1008896: salt-minion needs python3-importlib-metadata to start
Package: salt-minion Version: 3004+dfsg1-10 Severity: important Dear Maintainer, On Sunday 2022-04-03, I full-upgraded my Debian bookworm/sid hosts (+ apt autoremove --purge), all of them running salt-minion. On some of them, salt-minion failed to restart and exhibited the following Python error; AttributeError: 'PathDistribution' object has no attribute '_normalized_name' ... with the exact same stacktrace as this bugreport: https://github.com/saltstack/salt/issues/61062 A brief look at the associated fix: https://github.com/saltstack/salt/pull/61064 ... made me inspect whether python3-importlib-metadata was installed. Fortunately, the correlation was obvious: all hosts where salt-minion failed to restart lacked python3-importlib-metadata. Installing this package and starting salt-minion.service was enough to work around the issue. However, this is easier said than done on large infrastructures, especially when salt-minion is down, hence the "important" severity. I assume python3-importlib-metadata should be added to salt-minion or salt-common's required dependencies. Thanks for your work. -- Xavier G. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages salt-minion depends on: ii dctrl-tools 2.24-3+b1 ii init-system-helpers 1.62 ii lsb-base 11.1.0 ii python3 3.10.4-1 ii python3-pycryptodome 3.11.0+dfsg1-3 ii python3-systemd 234-4 ii python3-zmq 22.3.0-1+b1 ii salt-common 3004+dfsg1-10 Versions of packages salt-minion recommends: pn debconf-utils ii dmidecode 3.3-3 ii e2fsprogs 1.46.5-2 ii fdisk 2.37.3-1+b1 Versions of packages salt-minion suggests: pn python3-augeas -- no debconf information
Bug#987956: libgcrypt20: ECDH decryption fails with "gpg: public key decryption failed: Invalid object" error message
Package: libgcrypt20 Version: 1.8.7-4 Severity: important Dear Maintainer, After a full-upgrade in Sid on 2021-05-02, `gpg --decrypt somefile.gpg` fails: gpg: encrypted with 256-bit ECDH key, ID [hopefully irrelevant] gpg: public key decryption failed: Invalid object gpg: decryption failed: No secret key Strace provides a little more context: read(6, "S INQUIRE_MAXLEN 4096\nINQUIRE CIPHERT"..., 1002) = 41 write(6, "D (7:enc-val(4:ecdh(1:s49:0V\333\26\231\377\242\231\237b\375"..., 120) = 120 write(6, "END", 3) = 3 write(6, "\n", 1) = 1 read(6, "ERR 16777281 Invalid object \n", 1002) = 37 Considering the list of updated packages this day, libgcrypt20:amd64 (1.8.7-3, 1.8.7-4) is the likely culprit. Its changelog states: libgcrypt20 (1.8.7-4) unstable; urgency=medium * Update from LIBGCRYPT-1.8-BRANCH: + 30_07-Fix-previous-commit.patch + 30_08-ecc-Check-the-input-length-for-the-point.patch -- Andreas Metzler Sun, 02 May 2021 13:58:47 +0200 The second patch is precisely about returning "Invalid object" / GPG_ERR_INV_OBJ in some case related to GnuPG and ECDH decryption. Therefore, could you please double-check this patch? Thanks for your work. Cheers, -- Xavier G. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgcrypt20 depends on: ii libc6 2.31-12 ii libgpg-error0 1.38-2 libgcrypt20 recommends no packages. Versions of packages libgcrypt20 suggests: pn rng-tools -- no debconf information
