Bug#1067228: linux-image-6.6.13+bpo-amd64-unsigned: _major_ cpu performance degradation from 6.1
Package: linux-image-6.6.13+bpo-amd64-unsigned Severity: important Dear Maintainer, Upgrading from bookroms 6.1 to 6.6 causes a major performance degradation. * What led up to the situation? I semi-regularly stress-test systems with linpack-xtreme-1.1.5-amd64 to see if there are thermal or stability problems. Typical output looks like this. The GFlops performance varies somewhat due to thermal issues, but is generally above 500 GFlops on this system: Size LDAAlign. Time(s)GFlops Residual Residual(norm) Check 22611 22611 4 15.171 508.0650 4.907015e-10 3.410840e-02 pass 22611 22611 4 14.935 516.0887 4.907015e-10 3.410840e-02 pass 22611 22611 4 14.978 514.6037 4.907015e-10 3.410840e-02 pass 22611 22611 4 15.260 505.0881 4.907015e-10 3.410840e-02 pass 22611 22611 4 14.669 525.4384 4.907015e-10 3.410840e-02 pass After upgrading from 6.1 to 6.6, I noticed some programs being surprisingly slow, so I run the stress test,a nd got output like this: Size LDAAlign. Time(s)GFlops Residual Residual(norm) Check 22611 22611 4 48.447 159.0972 5.357863e-10 3.724222e-02 pass As you can see, the performance is seriously degraded. Moreso, it is all over the place, sometimes it as 212 GFlops, sometimes only 44. This is on an i7-14700k, but it happens with another system using a 13700k in exactly the same way. * What exactly did you do (or not do) that was effective (or ineffective)? After some investigation, I noticed that rapl shows a power usage of about 50W instead of the more expected 200+. Turned out thermald set a power limit of 65W. Thinking this to be some bug in thermald, I disabled it and restored the power limit(s) too 300W. Unfortunately, while this increased the power usage to almost 200W, it did not improve performance at all (normal cpu power suage for linpack is up to 275W). I then tried various other things, and found that booting the old 6.1 linux kernel fixed this problem completely. Not quite believing it, I built a special initrd with linpack inside, and found it happens in there too, that is, linux-6.6 is slow, erratic, and linux-6.1 performs as expected, and this is independent of any configuration or installed software. I tried booting with no kernel arguments as well to exclude any command line arguments being the culprit, and found the same performance degradation, leaving essentially only the kernel. (my default arguments include mitigations=off, so it's not caused by any mitigation either). I also tried this on another system with a 13700K cpu, and got exactly the same results - 6.1 works fine, 6.6 only reaches 10-50% of the performance, very erratically. I do notice that processes seem to jump around widely between cpus when this happens, but that might or might not be related. * What was the outcome of this action? I did downgrade to 6.1 on all affected systems. * What outcome did you expect instead? Obviously, 6.6 should perform more or less the same as 6.1. This might not be an issue with debians kernel, as I can find a few other, similar reports affecting manjaro and arch linux, e.g. https://forum.manjaro.org/t/linux-kernel-6-6-lts-cpu-regression-on-i7-alderlake/157474/30 *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.0-18-amd64 (SMP w/28 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 linux-image-6.6.13+bpo-amd64-unsigned depends on: ii initramfs-tools [linux-initramfs-tool] 0.142 ii kmod30+20221128-1 ii linux-base 4.9 Versions of packages linux-image-6.6.13+bpo-amd64-unsigned recommends: ii apparmor 3.0.8-3 ii firmware-linux-free 20200122-1 Versions of packages linux-image-6.6.13+bpo-amd64-unsigned suggests: pn debian-kernel-handbook ii extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1 ii grub-efi-amd64 2.06-13+deb12u1 pn linux-doc-6.6
Bug#1065411: dash: 'jobs' utility does not generate output in a pipe
Package: dash Version: 0.5.12-6 Severity: normal Dear Maintainer, I found that 'jobs' in dash is silent when stdout is a pipe: # dash -c 'sleep 1 1|wc -l' 0 afaics, this is not documented behaviour, and other utilities (kill, alias) seem to work fine. bash does allow the output of jobs to be parsed: # bash -c 'sleep 1 1|wc -l' 2 I think the bash behaviour is more useful for shell programming, and probably correct, as the sus does not seem to indicate that jobs should have no output in this case. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.6.15-amd64 (SMP w/28 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 dash depends on: ii debianutils 5.7-0.5~deb12u1 ii dpkg 1.21.22 ii libc62.36-9+deb12u4 dash recommends no packages. dash suggests no packages. -- debconf information excluded
Bug#1042411: closed by Thomas Lange (found problem)
On Sat, Feb 17, 2024 at 08:54:03PM +, Debian Bug Tracking System wrote: > the problem is that on your computer you have a directory /usr/etc. Interesting bug. > Then rinse uses this wrong path because it thinks a local rinse > installation is available. Please remove this /usr/etc, which is not a > usual directory. I am not sure what you mean or why you closed this bug - asking me to delete any "unusual" directories does not fix the bug in rinse. It's completely legal in debian to have this directorxy, and some software requires it - I cannot delete it without breaking other software. The bug here is clearly in rinse - /usr/etc is not a debian-mandated directory, so rinse must not rely on it being preesent or absent (see the debian filesysytem heirarchy standard for example). Asking users to delete random directories to work around a bug in your package without fixing it is not acceptable.
Bug#1057480: e2fsprogs: -E mount_opts contradicting documentation
Package: e2fsprogs
Version: 1.47.0-2
Severity: normal
Dear Maintainer,
tune2fs documents the -E switch as:
Extended options are comma separated, and may take an argu‐ ment using the
equals ('=') sign.
and the mount_opts sub-option:
mount_opts=mount_option_string
mount_option_string is an arbitrary string with a maximum length of 63
bytes...
The problem is that mount options are also comma-separated and tune2fs
does not seem to support this (instead assuming the comma separates
-E options), therefore, the string is not arbitrary, or at least, its
impossible to specify arbitrary contents, or, if it is possible, its
undocumented how to do so.
I don't know if this is a documentation problem or not, but it would be
nice if one could actually specify an arbitrary mount_option_string with
tune2fs.
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990,
'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32
Kernel: Linux 6.1.0-13-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 e2fsprogs depends on:
ii libblkid12.38.1-5+b1
ii libc62.36-9+deb12u3
ii libcom-err2 1.47.0-2
ii libext2fs2 1.47.0-2
ii libss2 1.47.0-2
ii libuuid1 2.38.1-5+b1
ii logsave 1.47.0-2
Versions of packages e2fsprogs recommends:
pn e2fsprogs-l10n
Versions of packages e2fsprogs suggests:
pn e2fsck-static
pn fuse2fs
ii gpart 1:0.3-10
ii parted 3.5-3
-- Configuration Files:
/etc/cron.d/e2scrub_all changed [not included]
-- no debconf information
Bug#1054558: iotop: crashes on non-utf8 characters
Package: iotop Version: 0.6-42-ga14256a-0.1+b2 Severity: normal Dear Maintainer, independent of locale (or the fatc that locales are per-process), if iotop finds a command line argument that is not utf-8 encoded, it simply crashes. regardless of how it handles encodings it does not understand, it should not simply crash: File "/usr/lib/python3/dist-packages/iotop/data.py", line 311, in get_cmdline cmdline = proc_cmdline.read(4096) ^^^ File "", line 322, in decode UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 2259: invalid continuation byte -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.55-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 iotop depends on: ii python3 3.11.2-1+b1 iotop recommends no packages. iotop suggests no packages. -- no debconf information
Bug#1042798: rinse: wrong default for --cache
Package: rinse Version: 4.1 Severity: minor Dear Maintainer, the manpage of rinse claims the default for --cache is 1, but rinse does not seem to cache any packages unless "--cache 1" is explicitly given so it sems the default is actually 0. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.42-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 rinse depends on: ii cpio 2.13+dfsg-7.1 ii libterm-size-perl 0.211-1+b2 ii libwww-perl6.68-1 ii perl 5.36.0-7 ii rpm4.18.0+dfsg-1+b1 ii rpm2cpio 4.18.0+dfsg-1+b1 ii wget 1.21.3-1+b2 rinse recommends no packages. rinse suggests no packages. -- no debconf information
Bug#1042411: rinse: wrong path to /etc directory
Package: rinse Version: 4.1 Severity: normal Dear Maintainer, when trying essntially an examp,e, rinse fials wioth a message like this: The package list for the distribution rocky-8 was not found. We expected to find: /usr/sbin/../etc/rocky-8.packages Aborting. I think the default path should be /etc/rinse, not /usr/sbin/../etc/, for two reasons: the files are obviously stored in /etc/rinse, and debian policy does not allow config files in /usr/etc (not would it allow assuming /usr/../etc is trhe same as /etc(. Ther problem is also not just limited to --distribution, as speciyfing something like ../../../../etc/rinse/rocky-8 to work aorund the first issue causes another, simiar problem when reeading rinse.conf: The configuration file /usr/sbin/../etc/rinse.conf was not found. Aborting. Note also that the manpage wrongly says the default confgig file is /etc/rinse/rinse.conf, but it is not, as specfying that path directly via --config makes rinse find it, apparently. I haven't foiund away to invoke rinse so far, though, even with tricks, so it seems to be seriouslöy hosed atm.- -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.41-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 rinse depends on: ii cpio 2.13+dfsg-7.1 ii libterm-size-perl 0.211-1+b2 ii libwww-perl6.68-1 ii perl 5.36.0-7 ii rpm4.18.0+dfsg-1+b1 ii rpm2cpio 4.18.0+dfsg-1+b1 ii wget 1.21.3-1+b2 rinse recommends no packages. rinse suggests no packages. -- no debconf information
Bug#1041360: partitionmanager calls btrfsck --repair causing data corruption
Package: partitionmanager Version: 22.12.3-1 Severity: normal Dear Maintainer, * What led up to the situation? I was trying to resize a btrfs partition. * What exactly did you do (or not do) that was effective (or ineffective)? I saw partitionmanager invoke "btrfsck --repair" on the partition without asking. * What was the outcome of this action? I immediately killed partitionmanager, and still suffer from shock! :) * What outcome did you expect instead? btrfsck --repair is well known to corrupt data, and under no circumstances must a program run it without explicitly asking the user. Note the warning message that the program outputs: WARNING: Do not use --repair unless you are advised to do so by a developer or an experienced user, This is not an idle warning to be ignored. MAybe one day in the future, btrfsck --repair will be as useful as other fsck programs, but at this point in time, running btrfsck --repair almost invariably results in making things worse rather than better. -- System Information: Debian Release: 12.0 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.37-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 partitionmanager depends on: ii kio 5.103.0-1 ii libc6 2.36-9 ii libkf5configcore5 5.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5configwidgets5 5.103.0-1 ii libkf5coreaddons5 5.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5dbusaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5jobwidgets5 5.103.0-1 ii libkf5kiocore55.103.0-1 ii libkf5kiogui5 5.103.0-1 ii libkf5widgetsaddons5 5.103.0-1 ii libkf5windowsystem5 5.103.0-1 ii libkf5xmlgui5 5.103.0-1 ii libkpmcore12 22.12.3-1 ii libpolkit-qt5-1-1 0.114.0-2 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5gui55.15.8+dfsg-11 ii libqt5widgets55.15.8+dfsg-11 ii libstdc++612.2.0-14 partitionmanager recommends no packages. Versions of packages partitionmanager suggests: ii btrfs-progs6.2-1 ii dosfstools 4.2-1 ii hfsplus1.0.4-17 ii hfsutils 3.2.6-15 pn jfsutils ii ntfs-3g1:2022.10.3-1+b1 ii reiser4progs 1.2.2-1+b1 ii reiserfsprogs 1:3.6.27-4 ii xfsprogs 6.1.0-1 -- no debconf information
Bug#1041209: kakasi: endless loop with certain input
Package: kakasi Version: 2.3.6-4.1 Severity: normal Dear Maintainer, when running kakasi -i utf8 -w, this input: ～ｳﾞｨｰﾊﾞﾃﾞヲﾝｻﾞﾋﾞｰ～ results in an endless loop and infinite output. reproducer: perl -e 'print pack "H*", "efbd9eefbdb3efbe9eefbda8efbdb0efbe8aefbe9eefbe83efbe9ee383b2efbe9defbdbbefbe9eefbe8befbe9eefbdb0efbd9e"'|kakasi -i utf8 -w -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.37-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 kakasi depends on: ii kakasi-dic 2.3.6-4.1 ii libc6 2.36-9 kakasi recommends no packages. kakasi suggests no packages. -- no debconf information
Bug#1040186: ipmitool: IANA PEN registry open failed: No such file or directory
Package: ipmitool Version: 1.8.19-4 Severity: normal Dear Maintainer, after upgrade to bookworm, ipmitool outputs this on every invocation: IANA PEN registry open failed: No such file or directory * What led up to the situation? upgrading to bookworm, before it was fine. * What exactly did you do (or not do) that was effective (or ineffective)? using ipmitool * What was the outcome of this action? the message: IANA PEN registry open failed: No such file or directory * What outcome did you expect instead? no such message. *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.35-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 ipmitool depends on: ii init-system-helpers1.65.2 ii libc6 2.36-9 ii libfreeipmi17 1.6.10-1+b1 ii libreadline8 8.2-1.3 ii libssl33.0.9-1 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages ipmitool recommends: ii openipmi 2.0.33-1+b1 ipmitool suggests no packages. -- no debconf information
Bug#1039866: openssh-server: bookworm config enforces outdated extern sftp-server, unable to override
Package: openssh-server Version: 1:9.2p1-2 Severity: normal Dear Maintainer, after upgrading to bookworm, sshd did not come up again. The reason is that the config file now enforces the usage of the outdated sftp-server subsystem, and this is not overridable. Please consider NOT enforcing a specific sftp implementation (going with the defaults and letting users override it in separate4 conf files), or, if it has to be done, make it easier to override it, or possibly default to the modern "internal-sftp" implementation which allows chroot (and thus provides better defense-in-dpeth in most cases). Thanks for your work! -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.35-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 openssh-server depends on: ii adduser3.134 ii debconf [debconf-2.0] 1.5.82 ii init-system-helpers1.65.2 ii libaudit1 1:3.0.9-1 ii libc6 2.36-9 ii libcom-err21.47.0-2 ii libcrypt1 1:4.4.33-2 ii libgssapi-krb5-2 1.20.1-2 ii libkrb5-3 1.20.1-2 ii libpam-modules 1.5.2-6 ii libpam-runtime 1.5.2-6 ii libpam0g 1.5.2-6 ii libselinux13.4-1+b6 ii libssl33.0.9-1 ii libsystemd0252.6-1 ii libwrap0 7.6.q-32 ii lsb-base 11.6 ii openssh-client 1:9.2p1-2 ii openssh-sftp-server1:9.2p1-2 ii procps 2:4.0.2-3 ii runit-helper 2.15.2 ii sysvinit-utils [lsb-base] 3.06-4 ii ucf3.0043+nmu1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 252.6-1 ii ncurses-term 6.4-4 ii xauth1:1.1.2-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere ii ssh-askpass 1:1.2.4.1-16 pn ufw -- debconf information excluded
Bug#1039707: /usr/bin/mysqld_safe: missing from package
Package: mariadb-server-core Version: 1:10.11.3-1 Severity: normal Dear Maintainer, after upgrading to bookworm, the4 init script for mariadb fails to strat the server as it looks for mysqld_safe, which is not installed by mariadb-server-core. It appears that the init script comes from mariadb-server-10.5, which is probably a leftover from bullseye. I think if mariadb-server-10.5 is incompatible with bookworms mariadb server, it should be uninstalled on upgrades. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.35-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 mariadb-server-core depends on: ii libc6 2.36-9 ii libcrypt1 1:4.4.33-2 ii libnuma12.0.16-1 ii libpcre2-8-010.42-1 ii libpmem11.12.1-2 ii libssl3 3.0.9-1 ii libstdc++6 12.2.0-14 ii libsystemd0 252.6-1 ii liburing2 2.3-3 ii mariadb-common 1:10.11.3-1 ii zlib1g 1:1.2.13.dfsg-1 mariadb-server-core recommends no packages. mariadb-server-core suggests no packages. -- no debconf information
Bug#1039705: mariadb-server-core: fails to start via systemd due to lacking permissions on /run
Package: mariadb-server-core Version: 1:10.11.3-1 Severity: normal Dear Maintainer, after upgrade to bookworm, mariadb no longer starts, because the socket directory /run/myysqld does not exist. this only happens when started via systemd. immediate reason is: install: cannot change owner and permissions of ‘/run/mysqld’: No such file or directory when started via sysv, the command line or some invoke tool, this works, because the start script runs as root. when started via system, the service is started as user mysql, which does npt have permissions. This seems to come form a file created during the upgrade called /etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf. The system had a "user=mysql" in mariadb.conf before the upgrade, so maybe this is where it is from. I don't think moving user= form mariadb to the systemd unit makes sense, as the user given to mariadb is the user the server changes to after initialisation, so moving it to the systemd unit breaks things (as is the case here). -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.35-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 mariadb-server-core depends on: ii libc6 2.36-9 ii libcrypt1 1:4.4.33-2 ii libnuma12.0.16-1 ii libpcre2-8-010.42-1 ii libpmem11.12.1-2 ii libssl3 3.0.9-1 ii libstdc++6 12.2.0-14 ii libsystemd0 252.6-1 ii liburing2 2.3-3 ii mariadb-common 1:10.11.3-1 ii zlib1g 1:1.2.13.dfsg-1 mariadb-server-core recommends no packages. mariadb-server-core suggests no packages. -- no debconf information
Bug#1039702: mariadb-server: mariadb-plugin-provider-bzip2 dependency on mariadb-server required?
Package: mariadb-server Version: 1:10.11.3-1 Severity: wishlist Dear Maintainer, I found that the various compression plugins (e.g. mariadb-plugin-provider-bzip2) all depend on mariadb-server. If there is no technical reason for this (apologies if there are, it looks to me that there aren't), wouldn't it make more sense to depend on mariadb-server-core? Thanks! -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.35-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 mariadb-server depends on: ii adduser3.134 ii debconf [debconf-2.0] 1.5.82 ii galera-4 26.4.13-1 ii gawk 1:5.2.1-2 ii iproute2 6.1.0-3 ii libc6 2.36-9 ii libdbi-perl1.643-4 ii libpam0g 1.5.2-6 ii libssl33.0.9-1 ii libstdc++6 12.2.0-14 ii lsof 4.95.0-1 ii mariadb-client 1:10.11.3-1 ii mariadb-common 1:10.11.3-1 ii mariadb-server-core1:10.11.3-1 ii passwd 1:4.13+dfsg1-1+b1 ii perl 5.36.0-7 ii procps 2:4.0.2-3 ii psmisc 23.6-1 ii rsync 3.2.7-1 ii socat 1.7.4.4-2 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages mariadb-server recommends: ii libhtml-template-perl 2.97-2 ii mariadb-plugin-provider-bzip2 1:10.11.3-1 ii mariadb-plugin-provider-lz4 1:10.11.3-1 ii mariadb-plugin-provider-lzma1:10.11.3-1 ii mariadb-plugin-provider-lzo 1:10.11.3-1 ii mariadb-plugin-provider-snappy 1:10.11.3-1 ii pv 1.6.20-1 Versions of packages mariadb-server suggests: ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1 ii mailutils [mailx] 1:3.15-4 pn mariadb-test ii netcat-openbsd 1.219-1 -- debconf information excluded
Bug#1037275: dd: regression - posix expression syntax no longer supported
Package: coreutils Version: 9.1-1 Severity: normal Dear Maintainer, I have a script that was used for some decades on multiple unices. Beginning with bookworm, it stopped working because dd no longer understands POSIX expression syntax for bs=: $ dd if=... bs=1024x1024x32 dd: invalid number: ‘1024x1024x32’ This should be valid syntax according to POSIX, and was understood on older versions of Debian GNU/Linux: Two or more positive decimal numbers (with or without k or b) separated by x, specifying the product of the indicated values -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (990, 'testing-security'), (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.32-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 coreutils depends on: ii libacl1 2.3.1-3 ii libattr1 1:2.5.1-4 ii libc62.36-9 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libselinux1 3.4-1+b6 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information
Bug#1037273: dupeguru: immediately crashes: ModuleNotFoundError: No module named 'core.pe.photo'
Package: dupeguru Version: 4.3.1-3+b1 Severity: grave Justification: renders package unusable Dear Maintainer, while the package installs fine, it immediately crashes on startup: $ dupeguru qt.qpa.xkeyboard: failed to compile a keymap Traceback (most recent call last): File "/bin/dupeguru", line 88, in sys.exit(main()) ^^ File "/bin/dupeguru", line 71, in main from qt.app import DupeGuru File "/usr/share/dupeguru/qt/app.py", line 22, in from core.app import AppMode, DupeGuru as DupeGuruModel File "/usr/share/dupeguru/core/app.py", line 27, in from core.pe.photo import get_delta_dimensions ModuleNotFoundError: No module named 'core.pe.photo' -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (990, 'testing-security'), (990, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.33-schmorp (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 dupeguru depends on: ii libc6 2.36-9 ii python3 3.11.2-1+b1 ii python3-distro1.8.0-1 ii python3-mutagen 1.46.0-1 ii python3-pyqt5 5.15.9+dfsg-1 ii python3-semantic-version 2.9.0-2 ii python3-send2trash1.8.1~b0-2 ii python3-xxhash3.2.0-1+b1 dupeguru recommends no packages. dupeguru suggests no packages. -- no debconf information
Bug#1037023: blueman: missing dependency (Failed to load module "xapp-gtk3-module")
On Fri, Jun 02, 2023 at 09:30:13AM +0200, Christopher Schramm wrote: > blueman-manager works fine for me without that package and blueman does not > have anything to do with xapp. Interesting - probably some action at a distance thing then. Weird that only blueman did output this message, though. > Could it be that you're referring to the module in > ~/.config/gtk-3.0/settings.ini or similar? Do other GTK 3 apps work fine? Can't see anything (see below), and other gtk-3 programs (such as xfce4-panel) did not complain when started similarly (i.e. same terminal instance). Here are the contents of ~/.config/gtk-3.0/settings.ini [Settings] gtk-cursor-theme-name=breeze_cursors gtk-font-name=Noto Sans 10 gtk-theme-name=Breeze gtk-icon-theme-name=breeze gtk-fallback-icon-theme=gnome gtk-toolbar-style=GTK_TOOLBAR_ICONS gtk-menu-images=1 gtk-button-images=1 gtk-primary-button-warps-slider=0 gtk-application-prefer-dark-theme=0
Bug#1037023: blueman: missing dependency (Failed to load module "xapp-gtk3-module")
Package: blueman Version: 2.3.5-2+b1 Severity: normal Dear Maintainer, when gir1.2-xapp-1.0 is not installed, bluerman-manager displays the following message and immediately exits: Gtk-Message: 22:49:13.732: Failed to load module "xapp-gtk3-module" | -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (990, 'testing-security'), (990, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.30-schmorp (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 blueman depends on: ii adwaita-icon-theme 43-1 ii bluez 5.66-1 ii bluez-obexd 5.66-1 ii dbus1.14.6-1 ii dbus-user-session [default-dbus-session-bus]1.14.6-1 ii dbus-x11 [dbus-session-bus] 1.14.6-1 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gir1.2-gdkpixbuf-2.02.42.10+dfsg-1+b1 ii gir1.2-glib-2.0 1.74.0-3 ii gir1.2-gtk-3.0 3.24.37-2 ii gir1.2-nm-1.0 1.42.4-1 ii gir1.2-pango-1.01.50.12+ds-1 ii gnome-icon-theme3.12.0-5 ii libbluetooth3 5.66-1 ii libc6 2.36-9 ii libpulse-mainloop-glib0 16.1+dfsg1-2+b1 ii librsvg2-common 2.54.5+dfsg-1 ii lxqt-notificationd [notification-daemon]1.2.0-1 ii mate-icon-theme 1.26.0-1 ii mate-notification-daemon [notification-daemon] 1.26.0-1 ii notification-daemon 3.20.0-4+b1 ii plasma-workspace [notification-daemon] 4:5.27.5-2 ii polkitd 122-3 ii python3 3.11.2-1+b1 ii python3-cairo 1.20.1-5+b1 ii python3-gi 3.42.2-3+b1 ii python3-gi-cairo3.42.2-3+b1 ii xfce4-notifyd [notification-daemon] 0.7.3-1 Versions of packages blueman recommends: ii pulseaudio-module-bluetooth 16.1+dfsg1-2+b1 blueman suggests no packages. -- no debconf information
Bug#1035601: lprint: uninstallable together with altos
Package: lprint Version: 1.1.0-2 Severity: normal Dear Maintainer, I don't know if this is a problem with this package or altos, but lrpint cannot be installed even though apt thinks they should not conflict: Preparing to unpack lprint_1.1.0-2_amd64.deb ... Unpacking lprint (1.1.0-2) ... dpkg: error processing archive lprint_1.1.0-2_amd64.deb (--install): trying to overwrite directory '/usr/lib/x86_64-linux-gnu/systemd/system' in package altos 1.9.15-1+b1 with nondirectory I am not sure either package should contain /usr/lib/x86_64-linux-gnu/systemd/system, and I am also not sure that this is the rght place for service files :) -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-rt-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lprint depends on: ii libc6 2.36-9 ii libcups2 2.4.2-3 ii libpappl1 1.3.1-2 lprint recommends no packages. lprint suggests no packages.
Bug#1035486: dpkg: consider making FS_IOC_FIEMAP an option that cna be turned off
Package: dpkg Version: 1.20.12 Severity: wishlist Dear Maintainer, on many of my systems using nvme drives or even sata ssds, the FS_IOC_FIEMAP scan that dpkg does is not only superfluous, but with a large number of packages installed, absolutely dominates the installation time (based on profiling) - essentially, dpkg does nothing else during the preparing/unpacxking/selecting steps. and while being a very useful optimisation for spinning rust drives, when installing many small packages, the scan is apparently done for every package unpack, when, again, on modern systems, everything is in the cache aftzer the first pass. could you consider making this scan optional (i.e. off-switchable via an option)? this way, users can disable it in dpkg.cfg on those systems where it matters, while still retaining it by default (I do not think trying to autodetect ssds is a good idea here, and a switch should be trivial to implement). thanks a lot for your consideration! PS: it might also be a good idea to reconsider the whole scan - fiemap often creates just as many seeks as a stat or an open, especially on more complicated filesystems. In fact, sorting by inode numbers (which are essentially free info) is often a good approximation for locality on many filesystems and might be a good replacement strategy. -- Package-specific info: System tainted due to merged-usr-via-aliased-dirs. -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.1.27-schmorp (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 dpkg depends on: ii libbz2-1.0 1.0.8-4 ii libc62.31-13+deb11u6 ii liblzma5 5.2.5-2.1~deb11u1 ii libselinux1 3.1-3 ii tar 1.34+dfsg-1 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.2.4 pn debsig-verify -- Configuration Files: /etc/dpkg/dpkg.cfg changed [not included] -- no debconf information
Bug#1035314: cron:i386 : PreDepends: cron-daemon-common:i386 but it is not installable
Package: cron Version: 3.0pl1-137 Severity: normal Dear Maintainer, * What led up to the situation? Updating a multiarch (amd64 & i386) system from bullseye to bookworm. * What exactly did you do (or not do) that was effective (or ineffective)? cron was the only package that dist-upgrade didn't upgrade, so I tried: apt upgrade cron:i386 * What was the outcome of this action? The following packages have unmet dependencies: cron:i386 : PreDepends: cron-daemon-common:i386 but it is not installable * What outcome did you expect instead? cron gets upgraded, along with any dependent packages. -- Package-specific info: --- EDITOR: not set --- /usr/bin/editor: /usr/bin/vim.nox --- /usr/bin/crontab: -rwxr-sr-x 1 root crontab 43568 Feb 22 2021 /usr/bin/crontab --- /var/spool/cron: drwxr-xr-x 1 root root 42 Dec 23 2019 /var/spool/cron --- /var/spool/cron/crontabs: drwx-wx--T 1 root crontab 24 Aug 5 2021 /var/spool/cron/crontabs --- /etc/cron.d: drwxr-xr-x 1 root root 264 Feb 15 06:16 /etc/cron.d --- /etc/cron.daily: drwxr-xr-x 1 root root 508 Feb 23 06:27 /etc/cron.daily --- /etc/cron.hourly: drwxr-xr-x 1 root root 24 Aug 15 2021 /etc/cron.hourly --- /etc/cron.monthly: drwxr-xr-x 1 root root 46 Aug 20 2021 /etc/cron.monthly --- /etc/cron.weekly: drwxr-xr-x 1 root root 152 Aug 15 2021 /etc/cron.weekly
Bug#1032615: please consider pcp over dool as replacement
Please do NOT consider dool as replacement for dstat, but pcp instead. The reasons are not only that pcp seems to be much more actively maintained, it is also vastly more compatible to dstat than dool. For example, dool uses an unreadable color palette (e.g. black text on black background) by default, and uses a very different default output format. pcp both works with the same terminals as dstat, and has a practically identical default output format, i.e. it is indistinguishable top dstat for most users out of the box. It would certainly be great to package dool, but since it does not seem to try to maintain bakcwards compatibility to dstat at all, it should not be the default replacement, instead it should be pcp, which, for existing dstat users, provides essentially the same experience. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#924307: xfsprogs: xfs_fsr needlessly defragments fully defragmented files
Seems that current versions of e2fsprogs have improved filefrag, which now reports one "extent" for these files, even though it has two extents: File size of 014798 is 87556096 (21376 blocks of 4096 bytes) ext: logical_offset:physical_offset: length: expected: flags: 0:0.. 21373: 352550127.. 352571500: 21374: 1:21374.. 21375: 352571501.. 352571502: 2: last,unwritten,eof 014798: 1 extent found not quite correct, but arguably more useful (2 _extents_ vs. 1 _fragment_, just a wording issue). xfs_fsr still considers these files fragmented, though: 014798 extents before:2 after:1 DONE 014798 --
Bug#1022858: perl-base: lots of duplicate files between perl-modules-5.32 and perl-base
Package: perl-base Version: 5.32.1-4+deb11u2 Severity: minor X-Debbugs-Cc: report...@plan9.de Dear Maintainer, I recently installed a fresh bullseye and ran jdupes to deduplicate files. To my surprise, this reduced the installed size (on a zstd-compressed btrfs filesystem) from 2GB to 1.3GB. This was rather unexpected and I investigated. One of the larger reasons for this size reduction is a large number of relatively large files that are identical in perl-modules-5.32 and perl-base, random example: -rw-r--r-- 1 root root 1466 Sep 24 2021 /usr/lib/x86_64-linux-gnu/perl-base/unicore/lib/Lb/CL.pl -rw-r--r-- 1 root root 1466 Sep 24 2021 /usr/share/perl/5.32.1/unicore/lib/Lb/CL.pl I wonder if thid duplication is intended, and if yes, maybe hardlinks should be used to save space. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 perl-base depends on: ii dpkg 1.20.12 ii libc6 2.31-13+deb11u5 ii libcrypt1 1:4.4.18-4 perl-base recommends no packages. Versions of packages perl-base suggests: ii perl5.32.1-4+deb11u2 ii sensible-utils 0.0.14 -- no debconf information
Bug#1021438: libsndfile1: undefined symbol: vorbis_version_string
Package: libsndfile1 Version: 1.0.31-2 Severity: normal Dear Maintainer, older propgrams using alsa at some point stopped working due to "undefined symbol: vorbis_version_string", e.g.: ALSA lib conf.c:3725:(snd_config_hooks_call) Cannot open shared library libasound_module_conf_pulse.so (/lib/x86_64-linux-gnu/libsndfile.so.1: undefined symbol: vorbis_version_string) They happened to work with older versions, so it seems somehow a symbol or dependency went missing. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.0.0-schmorp (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 libsndfile1 depends on: ii libc6 2.31-13+deb11u4 ii libflac8 1.3.3-2+deb11u1 ii libogg01.3.4-0.1 ii libopus0 1.3.1-0.1 ii libvorbis0a1.3.7-1 ii libvorbisenc2 1.3.7-1 libsndfile1 recommends no packages. libsndfile1 suggests no packages. -- no debconf information
Bug#1021365: wishlist: support same syntax for ipv6 addresse4s as other tools (RFC2291)
Package: nftables
Version: 0.9.8-3.1
Severity: wishlist
Dear Maintainer,
virtually all tools accepting ipv6 addresses use the format defined in RFC
4291 (IP Version 6 Addressing Architecture) section 2.2 (specifically form
3 is what I am talking about).
In fact, the only exception known to me is nftables, which defines its
own format ("Addresses are specified as a host name or as hexadecimal
halfwords separated by colons.").
This makes interoperability between other network tools and nftables
a hassle, as converting from standard IPv6 addressses toi the format
required by nft is quite hard to do e.g. in shell scripts.
I think it would be a very useful improvement if nft used the same IPv6
address format as other tools (in addition to hostnames, of course).
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990,
'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'stable-debug'), (500, 'unstable'), (500, 'testing'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32
Kernel: Linux 6.0.0-schmorp (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 nftables depends on:
ii dpkg 1.20.12
ii libc6 2.31-13+deb11u4
ii libedit2 3.1-20191231-2+b1
ii libnftables1 0.9.8-3.1
nftables recommends no packages.
Versions of packages nftables suggests:
pn firewalld
-- no debconf information
Bug#1019655: remmina: should support WM_DELETE_WINDOW like other programs
Package: remmina Version: 1.4.11+dfsg-3 Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? A host connection ended and remmina displayed its "lost connection [close]" or something similar banner inside its window. * What exactly did you do (or not do) that was effective (or ineffective)? I pressed the alt-f4 keyboard shortcut and also clicked the window close icon of my window manager, both of which send a WM_DELETE_WINDOW message. * What was the outcome of this action? Apparently, nothing, both were simply ignored by remmina. I *had* to click the close button inside the window, or use the equivalent of xkill. * What outcome did you expect instead? The window should close when the user requests it to via her window manager. The reason why I expect this is that I used a lot of x11 prorgams in my life and none of them simply ignore WM_DELETE_WINDOW in similar situaitons (or, actually, ever afaicr), so this is a serious user interface deficiency. *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.19.5-schmorp (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 remmina depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-2 ii dbus-x11 [dbus-session-bus] 1.12.20-2 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libavahi-ui-gtk3-00.8-5 ii libayatana-appindicator3-10.5.5-2 ii libc6 2.31-13+deb11u3 ii libcairo2 1.16.0-5 ii libgcrypt20 1.8.7-6 ii libglib2.0-0 2.66.8-1 ii libgtk-3-03.24.24-4+deb11u2 ii libjson-glib-1.0-01.6.2-1 ii libpango-1.0-01.46.2-3 ii libsodium23 1.0.18-1 ii libsoup2.4-1 2.72.0-2 ii libssh-4 0.9.5-1+deb11u1 ii libssl1.1 1.1.1n-0+deb11u3 ii libvte-2.91-0 0.62.3-1 ii remmina-common1.4.11+dfsg-3 Versions of packages remmina recommends: ii remmina-plugin-rdp 1.4.11+dfsg-3 ii remmina-plugin-secret 1.4.11+dfsg-3 ii remmina-plugin-vnc 1.4.11+dfsg-3 Versions of packages remmina suggests: pn remmina-plugin-exec pn remmina-plugin-kwallet pn remmina-plugin-nx ii remmina-plugin-spice1.4.11+dfsg-3 pn remmina-plugin-www ii remmina-plugin-xdmcp1.4.11+dfsg-3 -- no debconf information
Bug#1018900: mini-httpd: maxage option documented but not implemented
Package: mini-httpd Version: 1.30-2+b1 Severity: normal Dear Maintainer, the manpage documents the "maxage" option, but if you add: maxage=0 to the config file, mini_httpd no longer starts: Sep 01 20:17:25 acer mini-httpd[6312]: /usr/sbin/mini_httpd: unknown config option 'maxage' Sep 01 20:17:25 acer systemd[1]: mini-httpd.service: Control process exited, code=exited, status=1/FAILURE -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.19.5-schmorp (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 mini-httpd depends on: ii init-system-helpers 1.60 ii libc62.31-13+deb11u3 ii libcrypt11:4.4.18-4 ii libssl1.11.1.1n-0+deb11u3 ii lsb-base 11.1.0 Versions of packages mini-httpd recommends: ii apache2-utils 2.4.54-1~deb11u1 mini-httpd suggests no packages. -- no debconf information
Bug#948108: closed by yokota (Re: unrar corrupts filenames given as arguments)
> Tags: wontfix Shocking. > This file name bug comes from conversion between wide char strings and > multi byte strings. Why would unrar even try to do such a thing for an archive filename on the command line? It would make sense if this had anything to do with the filenames stored in the archive, but that's not the case. > These encoding conversion has so many wired pitfalls, and there is no > trivial fix. This is simply false: since there is no need for any conversion, the fix is trivial, namely don't do any conversion. Your decision to close this bugreport is wrong, please reconsider. If you really don't know why the fix is trivial, here is how to do it: unrar gets a filename to open as archive on the command line. This filename is a C string in argv. All it has to do is to use this string in e.g. the open(2) syscall. No conversion is necessary, and any attempted conversion is simply a bug with a trivial fix. The proof for this is that basically every other command has no trouble with this. If unsure, try to look at how programs such as "cat", "zip" or "unzip" work, none of which have trouble with this. Seriously, I have no clue how you can make such extremely wrong claims as this being a conversion problem. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#998627: Please enable ntfs3 module, it does not conflict wiht anything
Hi! I was just stumblinmg over this bugreport, and must say I am surprised at the logic here - the ntfs3 module does not conflict with existing filesystem drivers (such as ntfs-3g), so existing systems shouldn't be negatively affected as they would continue to either fail to mount or use ntfs-3g, if installed. also, the logic of keeping it out is very flawed, namely that the feature is new. but the code in question existed for a long time outside the kernel, so arguing there might possibly, potentially, maybe be some problems in the code (that haven't surfaced in the half a year since the release) is very strange. while I appreciate that the kernel package maintainers try to keep dangerous or broken modules disabled, I think doing so based on zero actual evidence is going to far, especially given that other broken modules are enabled (e.g. ufs, which does get used by default and can eat ufs filesystems for breakfast). the only actual evidence so far is that there is no working fsck - well, the same argument could be used to keep btrfs out of debian. I would have understood this decision if the ntfs3 module conflicted with the existing ntfs or ntfs-3g drivers, but it doesn't. please reconsider your decision - thanks!
Bug#1002718: Password: prompt during noninteractive install with no epxlanation
Package: gavodachs2-serv Version: 2.3+dfsg-3 Severity: normal Dear Maintainer, * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? while installing this package (and others) noninteractively, the installation paused with a "Password:" prompt. No explanation was given as to which password is required, or what for. Running ps from another shell showed thta it was running "su", which probably was responsible for the password prompt. * What was the outcome of this action? Instalklation was unexpectedely hanging. * What outcome did you expect instead? The package should not pause installation, and, if a password is required, should explain what password is reequired and what it is for. *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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
Bug#1002486: matlab-support: endless loop during interactive install
Package: matlab-support Version: 0.0.22 Severity: normal Dear Maintainer, when trying to install this package, I get a full-screen prompt saying: ┌─┤ MATLAB interface configuration ├──┐ │ │ │ No MATLAB installation found│ │ │ │ No MATLAB executables were found in the directories you specified. │ │ │ │ This package requires at least one local installation of MATLAB.│ │ │ │ │ │ │ └─┘ there is only one choice, and using it results... in the same prompt. I held down enter for about half a minute, worth about one thousand "OK"'s, but the dialog still repappeared, so thisa seems to be an endless loop. You can't ^Z out of it, either, so you need to log in form another terminal and kill the process tree. -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 matlab-support depends on: ii debconf [debconf-2.0] 1.5.77 ii sudo 1.9.5p2-3 Versions of packages matlab-support recommends: ii libgfortran-10-dev10.2.1-6 pn libgfortran-11-dev ii libstdc++-10-dev [libstdc++-dev] 10.2.1-6 ii libstdc++-6-dev [libstdc++-dev] 6.3.0-18+deb9u1 ii libstdc++-9-dev [libstdc++-dev] 9.3.0-22 Versions of packages matlab-support suggests: pn lsb-core
Bug#986591: attack of the hyphens
Package: fbreader
Version: 0.12.10dfsg2-4
Followup-For: Bug #986591
Dear Maintainer,
in my case, the bug is caused by pango's auto-hyphenation feature (which
was adeed and enabled by default, causing a lot of similar breakage in
other software), but the underlying cause is using uninitialised memory,
which is why it is happening randomly.
I fixed this by initialising the PangoAnalysis struct in
zlibrary/ui/src/gtk/view/ZLGtkPaintContext.cpp, in the constrcutor
(ZLGtkPaintContext::ZLGtkPaintContext), by adding:
myAnalysis = PangoAnalysis ({0});
This might be a problem elsewhere in the code, which I haven't
investigated, as with this fix, fbreader becomes usable again.
-- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990,
'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32
Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 fbreader depends on:
ii libc62.31-13+deb11u2
ii libgcc-s1 [libgcc1] 10.2.1-6
ii libgcc1 1:8.3.0-6
ii libsqlite3-0 3.34.1-3
ii libstdc++6 10.2.1-6
ii libzlcore0.130.12.10dfsg2-4
ii libzltext0.130.12.10dfsg2-4
ii libzlui-gtk 0.12.10dfsg2-4
Versions of packages fbreader recommends:
ii sensible-utils 0.0.14
fbreader suggests no packages.
Bug#996177: cryptsetup: please report fatal errors without having to use -v
On Tue, Oct 12, 2021 at 02:25:31AM +0200, Guilhem Moulin
wrote:
> > Also did you run luksFormat on that same machine (and didn't remove
> > memory sticks afterwards)?
>
> I was actually able to reproduce this with buster's 2.1.0, but doing the
> same thing after upgrading to bullseye or sid yields
> which sounds alright. Did you run reportbug(1) from the affected system
> or from an older one?
I reported this from another system, but both were recently upgraded to
bullseye.
I know because I use kvm to see if the machine will actually boot (Cthus
the different memory setup) and the kvm in bullseye has a bug that makes
this very hard (remote display makes it freeze randomly), and I had to
work around this bug, so I know it was not buster.
> Looking at the upstream git log, I found
> 206b70c837f29c8b34cb0d80ae496870550ec50c
> which fixes https://gitlab.com/cryptsetup/cryptsetup/-/issues/488 which looks
> really familiar :-)
It looks very similar. It is not the message I got with -v, which
specifically had the error number (3) in it somewhere, but maybe thats
because it ran out of memory in a different place.
I tried to recreate the conditions again (which was basically runnign kvm
without -m option), but I can't get the kernel to boot with the default
memory, and the minimum amount I got it to boot with was 256MB, at which
cryptsetup was able to open the volume.
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=/_/_//_/\_,_/ /_/\_\
Bug#996177: cryptsetup: please report fatal errors without having to use -v
On Tue, Oct 12, 2021 at 12:33:32AM +0200, Guilhem Moulin wrote: > Could you please share the memory cost of the PBKDF, I wouldn't know how to do that. > of `free` just before running cryptsetup? That would help us trying to > reproduce this and forward the issue upstream. I tried to reproduce > this but only managed to trigger the OOM killer. Not sure what this extra information has to do with the problem I reported - the problem is that the oom error is not reported unless -v is used, which has nothing to do with the oom killer or how much memory was needed - cryptsetup surely had reasons to use a lot of memory, but it should report an error if it can, as opposed to silently fail to do its job. > Also did you run luksFormat on that same machine (and didn't remove > memory sticks afterwards)? There was _significantly_ less memory in the machine at the time of the problem. I think you are likely confused about the nature of the problem I reported - the problem is not that cryptsetup used too much memory. The problem is that it only reported it when using an extra option, as opposed to reporting it when it hit the issue. cryptsetup was not killed by the oom killer, so it should have had no problems reporting the result of some failed allocation. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#996434: qemu-system-gui: gui randomly freezes even before booting under remote X
Package: qemu-system-gui Version: 1:5.2+dfsg-11+deb11u1 Severity: normal Dear Maintainer, when running with ssh -X forwarding, qemu now randomly hangs within the first few seconds. Sometimes the screen is empty with blinking cursor, sometimes there is a partial or full SEABIOS message, sometimes it gets to the grub welcome message, but without fail, it hangs within the first few seconds of startup. the buster version works absolutely reliably with x forwarding. I have seen this both with my own hosts, as well as with the hetzner buster/bullseye rescue systems, so its unlikely to be my system configuration. Aimple way to reproduce this for me is: kvm -snapshot -hda /dev/sda -m 4096 Which normally is a simple way to see if my system is gonna boot. -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 qemu-system-gui depends on: ii libc6 2.31-13+deb11u2 ii libcairo2 1.16.0-5 ii libepoxy0 1.5.5-1 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-03.24.24-4 ii libpixman-1-0 0.40.0-1 ii libpulse0 14.2-2 ii libvte-2.91-0 0.62.3-1 ii libx11-6 2:1.7.2-1 ii qemu-system-arm 1:5.2+dfsg-11+deb11u1 ii qemu-system-mips 1:5.2+dfsg-11+deb11u1 ii qemu-system-misc [qemu-system-s390x] 1:5.2+dfsg-11+deb11u1 ii qemu-system-ppc 1:5.2+dfsg-11+deb11u1 ii qemu-system-sparc 1:5.2+dfsg-11+deb11u1 ii qemu-system-x86 1:5.2+dfsg-11+deb11u1 qemu-system-gui recommends no packages. qemu-system-gui suggests no packages. -- no debconf information
Bug#996177: cryptsetup: please report fatal errors without having to use -v
Package: cryptsetup Version: 2:2.3.5-1 Severity: wishlist Dear Maintainer, I just had a somewhat lengthy initramfs debug issue caused by some suboptimal cryptsetup behaviour. Specifically, the machine didn't have enough ram, probably because the default algorithm (argon) requires more ram than the machine had. Unfortunately, cryptsetup silently fails - you get a password prompt, youc an enter any password, your shell prompt appears without any message but nothing happened. Only when running cryptsetup with -v did it output an error message akin to (repeated from memory): error -3 not enough memory I think requiring users to use --verbose to see fatal error messages is highly suboptimal behaviour. It would be nice if future versions of cryptsetup would output error messages by default, at least when they are fatal, i.e. the action could not be executed. Thanks! -- Package-specific info: -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 cryptsetup depends on: ii cryptsetup-bin 2:2.3.5-1 ii debconf [debconf-2.0] 1.5.77 ii dmsetup2:1.02.175-2.1 ii libc6 2.31-13+deb11u2 Versions of packages cryptsetup recommends: ii cryptsetup-initramfs 2:2.3.5-1 ii cryptsetup-run2:2.3.5-1 Versions of packages cryptsetup suggests: ii dosfstools 4.2-1 ii keyutils1.6.1-2 ii liblocale-gettext-perl 1.07-4+b1 -- debconf information excluded
Bug#991472: mariadb-client-10.3: mytop has wrong shebang line
Package: mariadb-client-10.3 Version: 1:10.3.29-0+deb10u1 Severity: normal Dear Maintainer, mytop has a broken shebang line: #!/usr/bin/env perl this will cause it to pick up a ranodm perl from PATH which, in my case, doesn't have the modules it needs. the correct shebang would be: #!/usr/bin/perl -- System Information: Debian Release: 10.10 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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 mariadb-client-10.3 depends on: ii debianutils 4.8.6.1 ii libc6 2.30-4 ii libconfig-inifiles-perl 3.01-1 ii libgnutls30 3.7.0-7 ii libstdc++610.2.1-6 ii mariadb-client-core-10.3 1:10.3.29-0+deb10u1 ii perl 5.32.1-4 ii zlib1g1:1.2.11.dfsg-1 Versions of packages mariadb-client-10.3 recommends: ii libdbd-mysql-perl 4.050-3+b1 ii libdbi-perl 1.643-3+b1 ii libterm-readkey-perl 2.38-1+b2 mariadb-client-10.3 suggests no packages. -- no debconf information
Bug#985786: systemd: should be restartable even with mounted network filesystems
On Thu, May 06, 2021 at 11:11:04PM +0200, Michael Biebl wrote: > > This sounds a bit like https://github.com/systemd/systemd/issues/16156 > > Unfortunately your strace log was clipped off. Pretty much similar, yes, except in my case it's not a race condiiton. > > Can you try https://github.com/systemd/systemd/pull/19101 ? > > > > As I haven't heard back from you, I'm tentatively marking this issue as > fixed upstream Sorry, I must have overlooked it, and apologies if my strace was clipped - marking as fixed upstream sounds like an excellent idea to me - if it it turns out to be still a problem, and I run into it, I can either re-open or report again once it happens. Thanks again for your work! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#985786: systemd: should be restartable even with mounted network filesystems
Package: systemd Version: 247.3-1 Severity: normal Dear Maintainer, we were just debugging an issue where systemd-networkd did not restart on some systems, with the following error: Mar 23 13:29:50 cert systemd[1]: Starting Network Service... Mar 23 13:29:50 cert systemd[564743]: systemd-networkd.service: Failed to set up mount namespacing: /run/systemd/unit-r... Mar 23 13:29:50 cert systemd[564743]: systemd-networkd.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-... Mar 23 13:29:50 cert systemd[1]: systemd-networkd.service: Main process exited, code=exited, status=226/NAMESPACE Mar 23 13:29:50 cert systemd[1]: systemd-networkd.service: Failed with result 'exit-code'. Mar 23 13:29:50 cert systemd[1]: Failed to start Network Service. As it turns out, this is due to an extremely fragile setup of networkd - essentially, it requires working network connectivity to be restartable. In our case, the issue above (which, btw., we could only diagnose by strace'ing systemd as systemd gives absolutely no useful error message for this) was a shared network filesystem mounted as /shared. And since we had a network problem (that restarting networkd with a better config was supposed to fix), at some point accesses to /shared caused it to fail with ENOTCONN. This in turn caused sysstemd to not be able to set up the private fs namespace, eventually causing the failure: [pid 564996] statx(4, "shared", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, 0, 0x7ffdadcf3d30) = -1 ENOTCONN (Transport endpoint is not connected) So while systemd and the systemd-networkd.service work as correctly designed here, I think networkd should not have to rely on a working network to be restartable. I don't know what is at fault or how to solve this problem, but I think this expectation (to be able to restart networkd to fix the nwtrok config) is a reasonable one, so I consider it a bug that this currently can't be done. Also, systemd should diagnose that it cannot access /shared (or whatever path is the problem), rather than just giving a generic error message that something failed without telling what. Thanks for considering my concerns! -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.8.18-050818-generic (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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 systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-4 ii libapparmor1 2.13.2-10 ii libaudit11:2.8.4-3 ii libblkid12.33.1-0.1 ii libc62.30-4 ii libcap2 1:2.25-2 ii libcrypt11:4.4.17-1 ii libcryptsetup12 2:2.3.4-2 ii libgcrypt20 1.8.4-5 ii libgnutls30 3.7.0-7 ii libgpg-error01.35-1 ii libip4tc21.8.7-1 ii libkmod2 26-1 ii liblz4-1 1.8.3-1 ii liblzma5 5.2.4-1 ii libmount12.36.1-7 ii libpam0g 1.3.1-5 ii libseccomp2 2.5.1-1 ii libselinux1 3.1-3 ii libsystemd0 247.3-1 ii libzstd1 1.4.8+dfsg-1 ii mount2.33.1-0.1 ii systemd-timesyncd [time-daemon] 247.3-1 ii util-linux 2.36.1-7 Versions of packages systemd recommends: ii dbus 1.12.20-1 Versions of packages systemd suggests: ii policykit-10.105-25 ii systemd-container 247.3-1 Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.139 pn libnss-systemd ii libpam-systemd 247.3-1 ii udev 247.3-1 -- no debconf information
Bug#984996: [debian-mysql] Bug#984996: mariadb-server-core-10.5: modifies globalö environment, causing race conditions
On Fri, Mar 19, 2021 at 03:41:06PM +1100, Daniel Black
wrote:
> > > This has the effect of polluting the environment of other sservices with
> > > these variables, which is usually pretty harmless.
>
> The intent was for minimal effects.
That has clearly failed, as it pollutes the environment blocvks for all
services on the system-
> > However, if there are multiple server instances then this creates a race
> > > condition
>
> Multiinstance services use _WSREP_START_POSITION%I as the environment name
>
> ref:
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/blob/master/support-files/mari...@.service.in#L88
That might indeed work around the problem, but of course increases the
pollution for unrelated services and user sessions.
> I'm not convinced about it easily. There are aria and innodb locks on
> filesystem preventing a second process
> modifying an already running process.
>
> Also the state only exists within the startup process of the
> mariadb.service. There are systemd blocks that prevent
> two copies of the same service starting at the same time.
>
> Maybe you mean something I haven't thought of. Can you explain the scenario?
The environment variables are _global_, not per-service. They will leak
into every other service started concurrently, including other mariadb
services.
> I know it's unclean.
>
> Suggestions welcome as to how to communicate state between two separate
> ExecStart* states in systemd welcome.
Files would be an obvious better solution, either using instanced
filenames or maybe a private fs namespace (e.g. in /tmp). I am not a
systemd expert, so can't comment on what the best working solution would
be, but files are obviously already better without any systemd features,
as they don't interfere with the suer environment or other services.
> * Codership are quite unaccepting of contributions (e.g:
> https://github.com/codership/galera/pull/109).
Can't force them to fix bugs or have a high-quality product, of
course. They do their thing, and hopefully get happy. But debian could,
and probably should, if at all possible.
> And there's been no bugs that I've found reported against the operation of
> the functionality.
Luck is not a good argument :) It is, after all, a race condition.
> > >* What was the outcome of this action?
> > >
> > > Environment polluted,
>
> One environment variable of a constrained name. Pollution? That appears for
> the microscopic time between a couple service script starts and is gone by
> the time the service start? Pollution, really?
Slippery slope much? :)
The "microscopic" time can be many minutes or longer under normal
operating conditions, and I don't think I need to seriously defend leaving
the global environment alone.
> critical environment variables of other services
> > > erased/modified.
> >
>
> Nothing else is modified or erased as you've already seen
Other than variables of other services, no, I agree.
> > > A systemd service should _never_ _ever_ modify the global environment.
>
> I agree. But an exaggerated purist argument to fix a problem that doesn't
> have a concrete real or theoretical failure isn't going to get a high
> priority.
That's why I explaiend concrete and theoretical failures in my report.
In any case, I think the problem is well understood, and I don't think more
explanations will be needed. If nobody cares about fixing this, thats fine
with me.
Good luck, and thanks for your efforts!
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=/_/_//_/\_,_/ /_/\_\
Bug#984997: [debian-mysql] Bug#984997: mariadb-server-10.5: database password passed in cleartext both on commandline and in environment
On Thu, Mar 11, 2021 at 09:49:03PM +0200, Otto Kekäläinen wrote: > Thanks for looking into this and reporting it. Could you be a bit more > specific what the context is, who can view the command? This is a rather old and wlel-known type of security issue. Typically any local user can view the password. This data is also often exposed in monitoring output, http status pages, smtp and so on. The comandline and environment are simply the wrong places to expose secret data - passwords should never be shown on screen in cleartext. (That includes the environment, btw. storing secrets in environment variables is similarly insecure). > How do you suggest the password would be passed? The typical method that is employed in practise is passing it via a file descriptor. A bit less secure is using a (non-world-readable) file, e.g. using --defaults-extra-file. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#984997: mariadb-server-10.5: database password passed in cleartext both on commandline and in environment
Package: mariadb-server-10.5 Version: 1:10.5.9-1 Severity: normal Dear Maintainer, I had a look at /usr/bin/wsrep_sst_mariabackup, after being a bit suspicious on how mariadb executes mariabackup for wsrep replication. I found that the database password is passed in *cleartext* both on the command line and via the environment. Neither of these are suitable places for a secret, as both can usually easily be queried by nonprivileged users. * What outcome did you expect instead? Secrets should never be passwd on the commandline or in the environment. -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.8.18-050818-generic (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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 mariadb-server-10.5 depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.71 pn galera-4 ii gawk 1:4.2.1+dfsg-1 ii iproute2 5.10.0-4 ii libc6 2.30-4 ii libdbi-perl 1.642-1+deb10u2 ii libpam0g 1.3.1-5 ii libssl1.1 1.1.1d-0+deb10u2 ii libstdc++610.2.1-6 ii lsb-base 11.1.0 ii lsof 4.91+dfsg-1 pn mariadb-client-10.5 ii mariadb-common1:10.3.27-0+deb10u1 pn mariadb-server-core-10.5 ii passwd1:4.5-1.1 ii perl 5.28.1-6+deb10u1 ii procps2:3.3.15-2 ii psmisc23.2-1 ii rsync 3.2.3-4 ii socat 1.7.3.2-2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages mariadb-server-10.5 recommends: ii libhtml-template-perl 2.97-1 Versions of packages mariadb-server-10.5 suggests: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-1 ii mailutils [mailx] 1:3.5-4 pn mariadb-test ii netcat-openbsd 1.195-2
Bug#984996: mariadb-server-core-10.5: modifies globalö environment, causing race conditions
Package: mariadb-server-core-10.5 Version: 1:10.5.9-1 Severity: normal Dear Maintainer, * What led up to the situation? various scripts (e.g. galera_new_cluster) and the systemd.unit modify the global/systemwide environment, e.g. with variables _WSREP_START_POSITION. This has the effect of polluting the environment of other sservices with these variables, which is usually pretty harmless. However, if there are multiple server instances then this creates a race condition where starting/stopping one server or bootstrapping one cluster will interfere with the other instance,s which could easily lead to database corruption. * What exactly did you do (or not do) that was effective (or ineffective)? I didn't try to solve the problem, it seems to be too fundamental to easily work around. The mechanism (systemd environment block) is wholly unsuitable to solve this problem. * What was the outcome of this action? Environment polluted, critical environment variables of other services erased/modified. * What outcome did you expect instead? A systemd service should _never_ _ever_ modify the global environment. -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.8.18-050818-generic (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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
Bug#975435: fdisk: feature request: partition alignment for sfdisk
Package: fdisk Version: 2.33.1-0.1 Severity: wishlist Dear Maintainer, sfdisk by default aligns partition sizes to one sector (at least on some disks) when sizes are not exactly specified. Larger alignments can be very useful nowadays, for example, disk encryption can be more efficient when the sector size for encryption is 4096 octets, requiring a partition size that is an exact multiple of 8 sectors. Unfortunately, when sfidsk auto-sizes a partition and the device has an "odd" size and the size is not specified, sfdisk will simply (and correctly) use the full remaining disk, causing e.g. cryptsetup with --sector-size 4096 to fail. It would be nice if it were possible to specify an alignment factor in bytes or sectors that would be used when creating partitions. Thanks! -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.8.18-050818-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fdisk depends on: ii libc6 2.30-4 ii libfdisk1 2.33.1-0.1 ii libmount1 2.36-3+b2 ii libncursesw6 6.1+20181013-2+deb10u2 ii libsmartcols1 2.36-3+b2 ii libtinfo6 6.1+20181013-2+deb10u2 fdisk recommends no packages. fdisk suggests no packages. -- no debconf information
Bug#975121: fuse-posixovl: this package does _not_ extend mount
Package: fuse-posixovl Version: 1.2.20120215+gitf5bfe35-3 Severity: minor Dear Maintainer, the description for this package says: This package extends mount and provides option '-t posixovl'. However, neither does it extend mount nor does it provide that option (nor does it work with fstab), as the mount.posixovl helper is not acxtually a valid mount.posixovl helper, as it doesn'tg rok the required options, most notably -o, e.g. # mount -t posixovl test test /sbin/mount.posixovl: invalid option -- 'o' Usage: /sbin/mount.posixovl [-F] [-S source] mountpoint [-- fuseoptions] -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.8.18-050818-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fuse-posixovl depends on: ii libc6 2.30-4 ii libfuse2 2.9.9-3 fuse-posixovl recommends no packages. fuse-posixovl suggests no packages. -- no debconf information
Bug#974139: libpango1.0-dev: PangoFcFont, PangoFcFontMap no longer subclassable
s more > crashes in the short term than the affected ABIs do: while the transition > is incomplete, apps will end up loading both the "old" and "new" Pango > into the same address space, which seems likely to be bad news. Right, but this is the case even when upstream bumps the soname as normal part of their work, so debian surely must be able to deal with this. Existing binaries will continue to work as opposed to having unknown bugs. Anyway, the TL;DR is (yeah, I put it at the end :) that the changes seem to be extensive, and not limited to a single pango release. Just restoring the members/size doesn't seem to be as feasible as I originally thought, as there have been *actual* semantic changes behind the scenes. And I only looked at two of the classes. PS: Thanks for caring - I am relying on the overhelmingly good work of Debian maintainers ever since I switched to debian some 20 years ago. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#974139: libpango1.0-dev: PangoFcFont, PangoFcFontMap no longer subclassable
On Wed, Nov 11, 2020 at 05:07:44PM +, Simon McVittie
wrote:
> Distribution-specific SONAME bumps, without coordination with upstreams,
> cause incompatibilities for years to come (see: libcurl) and I would
> strongly prefer to avoid them.
I agree it is an unfortunate situation that upstream does this, but
a) it's a debian policy violation and b) it introduces unchecked out
of bounds accesses, which are always potential security bugs. This is
especially troublesome as the mere display of text from untrusted sources
can trigger this.
If you think that this bug report is a bit muddled I can open a new bug
only about the policy vioaltion and memory corruption issue, so there is
no confusion about header files or other incompatiiblities, which are a
separate issue.
> It is also the upstream developer who decides which parts of a library are
> or aren't considered to be part of the public API/ABI.
True, but in this case, the developer has decided that the relevant parts
ARE part of the public ABI. A developer cannot undo this, just as a
developer cannot make 1=2, no matter how much she or he insist on it.
(which the pango developers don't do btw., it's not disputed that the
relevant parts are part of the public ABI, all that the pango developers
have said is that they don't have the manpower to bump the soname when on
breaking changes).
> Yes, reclassifying public API/ABI as private breaks derived projects
> that were relying on it,
Not only that, they also introduce random memory corruption and potential
security bugs.
Please note that the problem is not reclassifying the public ABI as
private, the problem is breaking the ABI without bumping the soname
introducing serious actual bugs.
Reclassifying thew ABI as private would not have caused this, neither
would breaking the ABI and bumping the soname cause this kind of issue.
> and it's unfortunate that the Pango maintainers were unaware
> that derived projects were relying on this part of the API
The pango maintainers obviously were aware of that, because it's
documented in the pango documentation multiple timesa and in the nissue I
reported they admitted they were aware of it, but don't care (apparently
because it is just too much work, a fair point).
> *could* make a Debian-specific fork of Pango, and link our GTK/etc.
Bumping the soname is not forking pango, but required by debian policy.
Note that bumping thew soname is all that's required to fix this issue, even
if the fix is not to my liking, but keep in mind this escalated from "some
ABI/API is no longer accessible" to "
> I'm sorry that this has broken your use-case, but I don't think taking
> an adversarial tone is going to help you to achieve the result you are
> aiming for.
Can you point out where I have taken "adversial tone"? What I reported is
a policy violation and apart from that a serious issue (unchecked memory
accesses that can be triggered simply by displaying text).
> People who perceive that they are being attacked will tend to
> become increasingly defensive and unwilling to change their position,
> which is presumably the opposite of what you want.
I suppose the bets way to proceed for you is to not feel attacked - I am
not aware of attacking you, and if you wrongly got the impression I did,
rest assured that this was not the intent of my words, I respect you as a
fellow human and so on.
Since this is cleared up, I hope we can go back to the actual etchnical
issues here?
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=/_/_//_/\_,_/ /_/\_\
Bug#974140: Bug#974139: libpango1.0-dev: PangoFcFont, PangoFcFontMap no longer subclassable
On Tue, Nov 10, 2020 at 04:30:07PM +, Simon McVittie wrote: > Control: tags 974139 = upstream wontfix I think this can't be a wontfix, as it directly breaks debian policy (8.1), as the ABI has changed incompatibly. upstream has confirmed that pango is essentially unmaintained and they do not keep ABI compatibility, or more exactly, they change the ABI without bumping the soname. Since these ABI changes can easily cause security issues as it creates out-of-bound writes, I think debian at the very least has to bump the soname version to avoid this. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#974139: libpango1.0-dev: PangoFcFont, PangoFcFontMap no longer subclassable
On Tue, Nov 10, 2020 at 04:30:07PM +, Simon McVittie wrote: > On Tue, 10 Nov 2020 at 15:52:26 +0100, Marc Lehmann wrote: > > If this breakage is indeed intended, maybe debian could simply ship the > > missing header files (pango/*-private.h)? > > Sorry, I don't think it's appropriate for Debian to be unilaterally > changing Pango's API. If upstream makes these APIs public again, we can Actually, looking at 1.47 in experimental, it seems the ABI has been changed without bumping the soname (the size of the PangoFcFontClass struct has changed, which is part of the publicv ABI), which means existing binaries will suffer memory corruption. So debian would at least have to bump the soname to soemthing like 1.1. This has happened before - pango upstream does not seem to care much about ABI compatibility, but it's trivial to avoid in debian by bumping the soname, so old binaries don't cause bad things to happen to users. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#974139: libpango1.0-dev: PangoFcFont, PangoFcFontMap no longer subclassable
On Tue, Nov 10, 2020 at 04:30:07PM +, Simon McVittie wrote: > On Tue, 10 Nov 2020 at 15:52:26 +0100, Marc Lehmann wrote: > > If this breakage is indeed intended, maybe debian could simply ship the > > missing header files (pango/*-private.h)? > > Sorry, I don't think it's appropriate for Debian to be unilaterally > changing Pango's API. If upstream makes these APIs public again, we can Actually, upstream has changed both API and ABI unilaterally - the removed definitions are part of the public ABI, so at some point, debian would have to bump the .soname. > pick that up; but if upstream confirms that they're intentionally private, > making them public again in Debian is just going to cause us more trouble > in future. Upstream has now confirmed that it was intentional - apparently, they don't want people to be able to extend pango themselves anymore, so in the long term I have to switch to something else anyway. Now, since these definitions are part of the public ABI, I guess it is safe to ship these header files myself until actual breakage occurs, but that's really a bit insane. The rationale behind debian shipping these headers would be that the deifntions inside are ABI parameters, so cannot change without a .soname change, at which point ABI compatibility doesn't matter anymore. (Pango has broken their ABI in the past without bumping the .soname, so this is definitely something you should watch out for). Anyway, thanks for your feedback! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#974139: Acknowledgement (libpango1.0-dev: silent api breakage, subclassing no longer possible)
I've dug a bit deeper. Unfortunately, pango no longer has a ChangeLog, so it's not clear to me when this was changed or why, but this seems to be an intentional change, i.e. between pango 1.42 and pango 1.46 a bunch of public members and structs required to subclass pango have been moved into private header files. I've opened an issue at https://gitlab.gnome.org/GNOME/pango/-/issues/513, as massively removing parts of the documented api and disallowing extensibility can't be good. If this breakage is indeed intended, maybe debian could simply ship the missing header files (pango/*-private.h)? According to the docs, they are required to implement new backends). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#974140: Acknowledgement (libpango1.0-dev: silent api breakage, subclassing no longer possible)
On Tue, Nov 10, 2020 at 03:15:03PM +, Debian Bug Tracking System wrote: > You can follow progress on this Bug here: 974140: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974140. I'm sorry, I replied too quickly on the bugreport without realising that it doesn't yet have an id assigned, so #974140 and #974139 belong together, but I don't know how to merge them. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#974140: libpango1.0-dev: silent api breakage, subclassing no longer possible
Package: libpango1.0-dev Version: 1.46.2-2 Severity: normal Dear Maintainer, I checked, and it seems I had packages form tetsinginstalled - the stable 1.42.4-8~deb10u1 version has the required types. I find nothing in the NEWS or debian changelog about this, so this is likely an oversight by upstream, it's not the first time that they broke subclassing. -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.8.16-050816-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpango1.0-dev depends on: ii gir1.2-pango-1.0 1.46.2-2 ii libcairo2-dev1.16.0-4 ii libfontconfig1-dev 2.13.1-2 ii libfreetype6-dev 2.10.2+dfsg-4 ii libfribidi-dev 1.0.5-3.1+deb10u1 ii libglib2.0-dev 2.66.2-1 ii libharfbuzz-dev 2.6.7-1 ii libpango-1.0-0 1.46.2-2 ii libpangocairo-1.0-0 1.46.2-2 ii libpangoft2-1.0-01.46.2-2 ii libpangoxft-1.0-01.46.2-2 ii libthai-dev 0.1.28-3 ii libx11-dev 2:1.6.7-1+deb10u1 ii libxft-dev 2.3.2-2 ii libxrender-dev 1:0.9.10-1 ii pango1.0-tools 1.46.2-2 ii pkg-config 0.29-6 libpango1.0-dev recommends no packages. Versions of packages libpango1.0-dev suggests: ii imagemagick 8:6.9.10.23+dfsg-2.1+deb10u1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+deb10u1 ii libpango1.0-doc 1.42.4-8~deb10u1 -- no debconf information
Bug#974139: libpango1.0-dev: silent api breakage, subclassing no longer possible
Package: libpango1.0-dev Version: 1.46.2-2 Severity: normal Dear Maintainer, I don't know in which version it happened, but the header files no longer define the PangoFcFontClass type (and PangoFcFontMapClass), which makes accessing the documented public members inside and subclassing impossible. According to the docs (e.g. https://developer.gnome.org/pango/stable/PangoFcFont.html), to implement a new fc-backend requires subclassing both PangoFcFontMap and PangoFcFont, which is no longer possible in 1.46, breaking all third-party renderers (e.g. ours, which uses pango to implement opengl rendering in games). -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.8.16-050816-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpango1.0-dev depends on: ii gir1.2-pango-1.0 1.46.2-2 ii libcairo2-dev1.16.0-4 ii libfontconfig1-dev 2.13.1-2 ii libfreetype6-dev 2.10.2+dfsg-4 ii libfribidi-dev 1.0.5-3.1+deb10u1 ii libglib2.0-dev 2.66.2-1 ii libharfbuzz-dev 2.6.7-1 ii libpango-1.0-0 1.46.2-2 ii libpangocairo-1.0-0 1.46.2-2 ii libpangoft2-1.0-01.46.2-2 ii libpangoxft-1.0-01.46.2-2 ii libthai-dev 0.1.28-3 ii libx11-dev 2:1.6.7-1+deb10u1 ii libxft-dev 2.3.2-2 ii libxrender-dev 1:0.9.10-1 ii pango1.0-tools 1.46.2-2 ii pkg-config 0.29-6 libpango1.0-dev recommends no packages. Versions of packages libpango1.0-dev suggests: ii imagemagick 8:6.9.10.23+dfsg-2.1+deb10u1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+deb10u1 ii libpango1.0-doc 1.42.4-8~deb10u1 -- no debconf information
Bug#970514: p7zip-full: interprets file names with '*' in it in archives
Package: p7zip-full Version: 16.02+dfsg-6 Severity: normal Dear Maintainer, when unpacking (zip) archives with filenames containing '*', 7za seems to interpret at least '*' in filenames in a weird (and worrying) way. For example, when unpacking the solaris 10u11 recommended patchset zip, I get this message (neither file existed on the filesystem when running 7za, both are inside the archive): Would you like to replace the existing file: Path: ./10_Recommended/patches/145006-09/SUNWwebminu/reloc/usr/sfw/lib/webmin/ldap-useradmin/config-sol-linux Size: 385 bytes (1 KiB) Modified: 2014-12-31 20:06:54 with the file from archive: Path: 10_Recommended/patches/145006-09/SUNWwebminu/reloc/usr/sfw/lib/webmin/ldap-useradmin/config-*-linux Size: 416 bytes (1 KiB) Modified: 2014-12-31 20:06:54 ? (Y)es / (N)o / (A)lways / (S)kip all / A(u)to rename all / (Q)uit? (Y)es / (N)o / (A)lways / (S)kip all / A(u)to rename all / (Q)uit? This happens whenever the archive contains filenames with '*' in them. Obviously, 7za should handle '*' and related characters like any other valid character in filenames. -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.6.19-050619-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages p7zip-full depends on: ii libc62.30-4 ii libgcc-s1 [libgcc1] 10.2.0-6 ii libgcc1 1:9.2.1-22 ii libstdc++6 10.2.0-6 ii p7zip16.02+dfsg-6 p7zip-full recommends no packages. Versions of packages p7zip-full suggests: pn p7zip-rar -- no debconf information
Bug#970090: lvm2: Cache mode "writeback" is not compatible with cache policy "cleaner".
Package: lvm2 Version: 2.03.02-3 Severity: wishlist Dear Maintainer, when trying to use the cleaner cachepolicy in writeback mode, lvm2 fails like this: Cache mode "writeback" is not compatible with cache policy "cleaner". However, the kernel suports this combination, which is very useful to avoid cache migrations but sitll have a hotspot writeback cache. It would be nice if lvm2 also supported this combination (can't see why it dosn't, in fact). -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.6.19-050619-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lvm2 depends on: ii dmeventd 2:1.02.155-3 ii dmsetup 2:1.02.171-3 ii libaio1 0.3.112-3 ii libblkid1 2.33.1-0.1 ii libc6 2.30-4 ii libdevmapper-event1.02.1 2:1.02.171-3 ii libdevmapper1.02.12:1.02.171-3 ii libreadline5 5.2+dfsg-3+b13 ii libselinux1 3.1-2 ii libsystemd0 246.4-1 ii libudev1 241-7~deb10u4 ii lsb-base 10.2019051400 Versions of packages lvm2 recommends: ii thin-provisioning-tools 0.7.6-2.1 lvm2 suggests no packages. -- Configuration Files: /etc/lvm/lvmlocal.conf changed [not included] -- debconf information excluded
Bug#969466: btrfs-progs: strace'ing btrfs instantly and silently breaks operation
Package: btrfs-progs Version: 5.6-1 Severity: normal Dear Maintainer, on at least some operations, e.g. "btrfs fi def somefile", attaching strace to the btrfs process instantly cancels the current operation without any error message or other indication that it has not done its job. obviously, I would expect that strace'ing btrfs would not affect the correctness of its operation. -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.6.19-050619-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages btrfs-progs depends on: ii libblkid12.33.1-0.1 ii libc62.30-4 ii libcom-err2 1.45.6-1 ii libext2fs2 1.45.6-1 ii liblzo2-22.10-0.1 ii libuuid1 2.33.1-0.1 ii libzstd1 1.4.5+dfsg-4 ii zlib1g 1:1.2.11.dfsg-1 btrfs-progs recommends no packages. Versions of packages btrfs-progs suggests: pn duperemove -- no debconf information
Bug#968258: caja-dropbox: obnoxious advertising
Package: caja-dropbox Version: 1.20.0-4 Severity: minor Dear Maintainer, when installing the package, it currently displays the following advertising: Dropbox is the easiest way to share and store your files online. Want to learn more? Head to https://www.dropbox.com/ I find this very questionable - why does debian make (likely false) claims like this? On what base is dropbox advertised as the "easiest way to share and store your files online"? I think this should simply be removed, especially as it is likely not even true. -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.6.19-050619-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages caja-dropbox depends on: ii dbus-x11 1.12.20-0+deb10u1 ii gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1 ii gir1.2-glib-2.0 1.58.3-2 ii gir1.2-gtk-3.03.24.5-1 ii gir1.2-pango-1.0 1.42.4-8~deb10u1 ii libatk1.0-0 2.30.0-2 ii libc6 2.30-4 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 pn libcaja-extension1 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk-3-03.24.5-1 ii libpango-1.0-01.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii policykit-1 0.105-25 ii procps2:3.3.15-2 ii python2.7.16-1 ii python-gpg1.12.0-6 ii python-gtk2 2.24.0-5.1+b1 ii python3 3.7.3-1 ii python3-gi3.30.4-1 ii python3-gpg 1.12.0-6 caja-dropbox recommends no packages. Versions of packages caja-dropbox suggests: pn caja
Bug#965062: systemd: Cannot resolve user name systemd-network: No such process
On Sun, Jul 19, 2020 at 03:40:41PM +0200, Michael Biebl wrote: > Maybe you start with a minimal debian system and turn that bit by bit > into a system like the one where you encounter the problem to see which > change is causing it. Unfortunately, I was away for a bit and when I returned some helpful person had it set up from scratch, deleting the old installation. I was told that /var/tmp had wrong permissions (1700 instead of 1777), so maybe that was the reason for the problem, although when I manually chmod 1700 /var/tmp, I can't reproduce the problem with the fresh setup, either. > I do also notice, that you run a 5.7.0 kernel. So this appears to be a > jessie->buster upgraded system with a mix of unstable/testing. > Maybe there is some configuration mixed/messed up. Certainly, although the kernel was added afterwards (the whole upgrade was to get a more recent kernel for newer hardware, and more specifically, a debian kernel, as we used mainlinme-ppa kernels before). On Sun, Jul 19, 2020 at 05:03:21PM +0200, Michael Biebl wrote: > getent passwd systemd-network Already sent this one - I don't think resolving the passwd/group entries were the problem, something else went wrong, and the problem here is just very bad error reporting. Anyway, I'm sorry to not be able to provide closure here, I did reserve the pxe environment for further debugging, but due to circumstances out of my control, it has been deleted. A fresh buster setup, not surprisingly, works fine. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#965062: systemd: Cannot resolve user name systemd-network: No such process
On Wed, Jul 15, 2020 at 03:30:30PM +0200, Michael Biebl wrote: > systemctl status systemd-networkd ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2020-07-16 04:15:32 UTC; 23s ago Docs: man:systemd-networkd.service(8) Process: 854 ExecStart=/lib/systemd/systemd-networkd (code=exited, status=1/FAILURE) Main PID: 854 (code=exited, status=1/FAILURE) Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Main process exited, code=exited, status=1/FAILURE Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Failed with result 'exit-code'. Jul 16 04:15:32 pxe systemd[1]: Failed to start Network Service. Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Service has no hold-off time (RestartSec=0), scheduling restart. Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Scheduled restart job, restart counter is at 5. Jul 16 04:15:32 pxe systemd[1]: Stopped Network Service. Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Start request repeated too quickly. Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Failed with result 'exit-code'. Jul 16 04:15:32 pxe systemd[1]: Failed to start Network Service. > getent passwd systemd-network systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false > systemctl cat systemd-networkd > And your /etc/nsswitch.conf Attached. Additionally, when I run /lib/systemd/systemd-networkd manually, it works (as root), so maybe it's a permissions problem: # /lib/systemd/systemd-networkd eth0: Gained IPv6LL Enumeration completed eth0: DHCPv4 address 10.0.0.73/25 via 10.0.0.5 lo: Configured eth0: Configured However, even non-root users can resolve the passwd entry just fine it seems: # su -c "getent passwd systemd-network" -s /bin/sh nobody systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false Lastly, "No such process" seems to be a peculiar error, but it seems to be generated by logic in the systemd code (which, btw., seems to errornously assume that errno is 0 when a library call succeeds, in a lot of places - fortunately only for error reporting it seems). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ # /lib/systemd/system/systemd-networkd.service # SPDX-License-Identifier: LGPL-2.1+ # # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Network Service Documentation=man:systemd-networkd.service(8) ConditionCapability=CAP_NET_ADMIN DefaultDependencies=no # systemd-udevd.service can be dropped once tuntap is moved to netlink After=systemd-udevd.service network-pre.target systemd-sysusers.service systemd-sysctl.service Before=network.target multi-user.target shutdown.target Conflicts=shutdown.target Wants=network.target [Service] AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW ExecStart=!!/lib/systemd/systemd-networkd LockPersonality=yes MemoryDenyWriteExecute=yes NoNewPrivileges=yes ProtectControlGroups=yes ProtectHome=yes ProtectKernelModules=yes ProtectSystem=strict Restart=on-failure RestartSec=0 RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 AF_PACKET RestrictNamespaces=yes RestrictRealtime=yes RuntimeDirectory=systemd/netif RuntimeDirectoryPreserve=yes SystemCallArchitectures=native SystemCallErrorNumber=EPERM SystemCallFilter=@system-service Type=notify User=systemd-network WatchdogSec=3min [Install] WantedBy=multi-user.target Also=systemd-networkd.socket Alias=dbus-org.freedesktop.network1.service # We want to enable systemd-networkd-wait-online.service whenever this service # is enabled. systemd-networkd-wait-online.service has # WantedBy=network-online.target, so enabling it only has an effect if # network-online.target itself is enabled or pulled in by some other unit. Also=systemd-networkd-wait-online.service # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: files systemd group: files systemd shadow: files gshadow:files hosts: files dns networks:
Bug#965062: systemd: Cannot resolve user name systemd-network: No such process
Package: systemd Version: 241-7~deb10u4 Severity: normal Dear Maintainer, after upgrading multiple systems from jessie to buster, systemd-networkd and systemd-resolved no longer start on any of them, both with similar error messages: Jul 15 11:42:17 pxe systemd-networkd[327]: Cannot resolve user name systemd-network: No such process Jul 15 11:42:18 pxe systemd-resolved[472]: Cannot resolve user name systemd-resolve: No such process Both daemons worked fine before the upgrade. googling shows me a number of reports related to DynamicUsers, but this doesn't seem to apply to this case, as both users exist in /etc/passwd: systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin I cannot run reportbug on the affected system, so I removed the automatically-added info as it would refer to the wrong system.
Bug#962946: mdadm: --name not valid in grow mode
Package: mdadm Version: 4.1-1 Severity: normal Dear Maintainer, The mdadm manpage lists --name under "For create, build, or grow". But mdadm disagrees: # mdadm --grow /dev/md127 --name raid1 mdadm: :option --name not valid in grow mode -- Package-specific info: --- mdadm.conf CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST MAILADDR root --- /etc/default/mdadm AUTOCHECK=true START_DAEMON=true DAEMON_OPTIONS="--syslog" VERBOSE=false --- /proc/mdstat: Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] unused devices: --- /proc/partitions: major minor #blocks name 80 1953514584 sda 81 262144 sda1 82 1782579200 sda2 83 170672199 sda3 8 16 117220824 sdb 8 17 102400 sdb1 8 18 117117383 sdb2 8 32 488386584 sdc 8 48 2930266582 sdd 8 49 1007 sdd1 8 50 262143 sdd2 8 51 2930002944 sdd3 8 64 58595475456 sde 8 65 58595474415 sde1 2530 838860800 dm-0 2531 536870912 dm-1 2532 262144 dm-2 2533 57756610560 dm-3 2534 57756610560 dm-4 2535 536870912 dm-5 2536 536854528 dm-6 2537 838844416 dm-7 2538 25165824 dm-8 25391048576 dm-9 253 10 209715200 dm-10 253 11 25165824 dm-11 253 12 57756610560 dm-12 253 13 209715200 dm-13 --- LVM physical volumes: PV VG Fmt Attr PSize PFree /dev/sda2 vg_cerebro lvm2 a-- 1.66t <450.50g /dev/sde1 vg_cerebro lvm2 a-- 54.57t 0 --- mount output sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=8143448k,nr_inodes=2035862,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1633596k,mode=755) /dev/mapper/cryptroot on / type btrfs (rw,noatime,nossd,space_cache,subvolid=257,subvol=/rootfs) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,relatime) none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) debugfs on /sys/kernel/debug type debugfs (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=44,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21807) mqueue on /dev/mqueue type mqueue (rw,relatime) nfsd on /proc/fs/nfsd type nfsd (rw,relatime) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime) /dev/mapper/cryptroot on /cryptroot type btrfs (rw,noatime,nossd,space_cache,subvolid=5,subvol=/) /dev/mapper/vg_cerebro-boot on /boot type ext4 (rw,noatime) /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) configfs on /sys/kernel/config type configfs (rw,relatime) /dev/mapper/cryptlocalvol on /cryptlocalvol type btrfs (rw,relatime,nossd,discard,space_cache,subvolid=5,subvol=/) /dev/mapper/cryptlocalvol on /localvol type btrfs (rw,relatime,nossd,discard,space_cache,subvolid=257,subvol=/rootfs) tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime)
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
offset=512) 3900: libblkid: LOWPROBE: parts: add partition (start=2048, size=524288) 3900: libblkid: LOWPROBE: parts: add partition (start=526336, size=3565158400) 3900: libblkid: LOWPROBE: parts: add partition (start=3565684736, size=341344399) 3900: libblkid: LOWPROBE: gpt: <--- (rc = 0) 3900: libblkid: LOWPROBE: <-- leaving probing loop (type=gpt) [PARTS idx=4] 3900: libblkid: LOWPROBE: partitions probe done [rc=0] 3900: libblkid: LOWPROBE: returning partitions binary data 3900: libblkid: LOWPROBE: trying to convert devno 0x803 to partition 3900: libblkid: LOWPROBE: searching by offset/size 3900: libblkid: LOWPROBE: assigning PART_ENTRY_SCHEME [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_NAME [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_UUID [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_TYPE [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_NUMBER [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_OFFSET [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_SIZE [partitions] 3900: libblkid: LOWPROBE: assigning PART_ENTRY_DISK [partitions] 3900: libblkid: LOWPROBE: parts: end probing for partition entry [success] 3900: libblkid: LOWPROBE: partitions probe done [rc=0] 3900: libblkid: LOWPROBE: end probe 3900: libblkid: LOWPROBE: zeroize wiper 3900: libblkid: LOWPROBE: returning LABEL value 3900: libblkid: TAG: [0x5557ab40]: alloc 3900: libblkid: TAG: [0x5557ab40]: setting (LABEL) 'SSDCER' 3900: libblkid: TAG: [0x5557aba0]: alloc 3900: libblkid: TAG: [0x5557aba0]: creating new cache tag head LABEL 3900: libblkid: LOWPROBE: returning UUID value 3900: libblkid: TAG: [0x5557ac20]: alloc 3900: libblkid: TAG: [0x5557ac20]: setting (UUID) '25E09C2A0B0B294A' 3900: libblkid: TAG: [0x5557ac80]: alloc 3900: libblkid: TAG: [0x5557ac80]: creating new cache tag head UUID 3900: libblkid: LOWPROBE: returning TYPE value 3900: libblkid: TAG: [0x5557ad00]: alloc 3900: libblkid: TAG: [0x5557ad00]: setting (TYPE) 'ntfs' 3900: libblkid: TAG: [0x5557ad60]: alloc 3900: libblkid: TAG: [0x5557ad60]: creating new cache tag head TYPE 3900: libblkid: LOWPROBE: returning PTTYPE value 3900: libblkid: TAG: [0x5557ade0]: alloc 3900: libblkid: TAG: [0x5557ade0]: setting (PTTYPE) 'dos' 3900: libblkid: TAG: [0x5557ae40]: alloc 3900: libblkid: TAG: [0x5557ae40]: creating new cache tag head PTTYPE This is all I can provide for the moment. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
On Mon, May 04, 2020 at 12:19:43PM +0200, Chris Hofstaedtler wrote: > > partitions on the same disk it is unlikely to be caused by something weird > > in the partition tables. That, or the algorithm is completely hosed, as it > > shouldn't depend on the partition at all, only on the disk. > > Well, I tried recreating your setup on a loop blockdev, and it works > for me: As an intermediate result, I did sgdisk -R /dev/sde /dev/sda, and the problem does not travel: # lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE /dev/sda /dev/sde PATH KNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE /dev/sda sda 8:0 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd /dev/sda1 sda18:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat /dev/sda2 sda28:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member /dev/sda3 sda38:3 part dos 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d SSDCERntfs /dev/sde sde 8:64 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd /dev/sde1 sde18:65 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d /dev/sde2 sde28:66 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 /dev/sde3 sde38:67 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d So I guess replicating this is not trivial. I think it would be more fruitful for somebody who knows the code to look at this, as obviously lsblk takes information from some place that is not the disk partition info, which should be more obvious (i.e. PTTYPE should simply not differ between partitions on the same disk). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
On Mon, May 04, 2020 at 12:19:43PM +0200, Chris Hofstaedtler wrote: > > On Sun, May 03, 2020 at 09:01:49PM +0200, Chris Hofstaedtler > > wrote: > > > I wouldn't assume this is necessary, though, as this is almost certainly > > a relatively simple bug to fix - since the partition type differs for > > partitions on the same disk it is unlikely to be caused by something weird > > in the partition tables. That, or the algorithm is completely hosed, as it > > shouldn't depend on the partition at all, only on the disk. > > Well, I tried recreating your setup on a loop blockdev, and it works > for me: Hi, and thanks for your efforts. I jumped the gun and upgraded to testing, and the bug still exists - at this point, I assume lsblk somehow looks at the partition data to detect PTTYPE (which makes no sense to me), or maybe it looks at some gpt data not visible in gdisk output: # lsblk --version lsblk from util-linux 2.35.1 # lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE PATH KNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE /dev/sda sda 8:0 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd /dev/sda1 sda18:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat /dev/sda2 sda28:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member /dev/sda3 sda38:3 part dos 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d SSDCER ntfs I might be able to creat some test image, or maybe I'll look at the util-linux sources to see what issue is going on here, but either will take some time for me. > Which fdisk is this, because it omits important info (partition > table type) and also doesn't show the GPT partitions? Oh right, sorry - that is actually fdisk v1.17.3, which I use because it doesn't support gpt and also lacks many of tghe safeguards of newer versions that kept getting into my way. I use it for so long I forgot it's not the debian one :(). OTOH, the current fdisk version doesn't show the mbr data on -l, so maybe that was a good thing after all. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#372110: closed by Chris Hofstaedtler (Documentation and message updates)
On Sun, May 03, 2020 at 09:00:15PM +, Debian Bug Tracking System wrote: > thank you for your reports. Please send documentation and message > improvements upstream, as tracking this in Debian is a good way of > them never arriving :-) Hi! While it might be fair to ask reporting bugs to upstream and close bugs (this is only a wishlist item after all), I don't think it is a good idea to force users to run non-free software (and give companies private data) to report a bug in Debian GNU/Linux - that's what the debian bugtracker is for, which manages bugs without these issues. Reiserfs is practically dead by now, so this bug report doesn't matter, but you really should re-think what you ask users to do. > Karel and team tend to react well to properly formatted patches that > are useful to all distributions. Well, I don't have a patch anyway. Greetings, Marc
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
On Sun, May 03, 2020 at 09:01:49PM +0200, Chris Hofstaedtler wrote: > >/dev/sda sda 8:0 disk gpt81c62d1c-b086-4f48-b1e9-b8ae2d457f91 > >/dev/sda1 sda18:1 part gpt > > 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 cf573ead-cdeb-42d5-9d75-aee9ceec3370 > >/dev/sda2 sda28:2 part gpt > > 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 89a285e0-09ca-44eb-b7ca-e1261a5e2f07 > > USBEFI vfat > >/dev/sda3 sda38:3 part dos > > 81c62d1c-b086-4f48-b1e9-b8ae2d457f91 d7f7dfdf-a2a6-4097-9975-c09fa73b19b3 > > DATAntfs > > I agree this is weird. Can you check if this still happens with the > current util-linux, and if so, file a report with upstream? I'm a bit reluctant to upgrade util-linux soon on the machine where it happens, but I still have the disk where it happens (but obviously, util-linux is still the version from buster), so I don't think I can do this anytime soon for the upstream version, which is presumably newer. For what it's worth, here is gdisk -l ands fdisk -l for the disk above. Current lsblk output (similar to the above, but the disk was blkdiscard'ed since then and re-done from scratch, so is a bit different): PATHKNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE /dev/sdasda 8:0 disk gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd /dev/sda1 sda18:1 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd c845ed61-afd2-4437-8db8-cd22b74daf1d EFI vfat /dev/sda2 sda28:2 part gpt 81be6e1d-066c-45eb-a13d-53fc8e4730bd e6a8207b-c4da-44ac-8a04-8f68cf15c119 LVM2_member /dev/sda3 sda38:3 part dos 81be6e1d-066c-45eb-a13d-53fc8e4730bd e744ce6f-6ba9-43a2-b36e-ebd019e0b20d SSDCERntfs gdisk -l: Number Start (sector)End (sector) Size Code Name 12048 526335 256.0 MiB EF00 EFI System 2 526336 3565684735 1.7 TiB 8E00 Linux LVM 3 3565684736 3907029134 162.8 GiB 0700 Microsoft basic data fdisk -l: Disk /dev/sda: 2000.3 GB, 2000398934016 bytes 256 heads, 63 sectors/track, 242251 cylinders Units = cylinders of 16128 * 512 = 8257536 bytes Device Boot Start End Blocks Id System /dev/sda1 1 242252 1953514583+ ee EFI GPT I wouldn't assume this is necessary, though, as this is almost certainly a relatively simple bug to fix - since the partition type differs for partitions on the same disk it is unlikely to be caused by something weird in the partition tables. That, or the algorithm is completely hosed, as it shouldn't depend on the partition at all, only on the disk. Hope this helps, -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#948108: unrar corrupts filenames given as arguments
Hi! For some reason I didn't see or receive the reply to this bug report. Anyway, thanks for the explanation, but I am not sure what to make of it - on the one hand, it confirms the bug (unrar incorrectly mangles filenames by trying to recode them), but on the other hand, it's still clearly a bug. And while not as bad as, say, a buffer overflow, this could still have security implications, as unrar will try to process a different file than what the user specified, which could result in unwanted information disclosure. I would agree that this is not a terribly likely scenario, but I don't see a reason why this bug shouldn't get fixed eventually, and I certainly wouldn't call it harmless - I lost some data due to this bug, as some perfectly fine archives were flagged as undecodable due to this spurious error and were deleted before I understood that this is just unrar being broken and not actually a problem in the archives themselves. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#953829: regression/crash: mtr: Probes exhausted
On Sun, Mar 15, 2020 at 03:43:09PM -0700, Robert Woodcock
wrote:
> If you *do* need to differentiate, I would adjust the limit for the
> number of outstanding probes in packet/probe.h, and then recompile:
>
> #define MAX_PROBES 1024
>
> However, that's not enough - I believe the intent of this limit is to
> match the default Linux limit of 1024 open files per process, which you
> will need to override in /etc/security/limits.conf to make effective use
> of the new limit in your copy of mtr.
>
> Probably the best long-term fix would be to automatically free the
> oldest probe when the newest one is requested, but I don't know how
> practical that would be.
Thanks a lot for this detailed analysis and tips. The strange thing,
though, is that this is clearly a regression, i.e. these limits (other
than the kernel limit) seem to either be new, or mtr silently handled this
in the past.
Anyway, if that's going to be it, I'll simply have to adapt, and this
apparently works as designed and is not a bug.
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=/_/_//_/\_,_/ /_/\_\
Bug#953865: lvm2: please improve vgmerge manpage
Package: lvm2 Version: 2.03.02-3 Severity: wishlist Dear Maintainer, vgmerge currently says: vgmerge position_args [...] The inactive source VG is merged into the destination VG [...] vgmerge VG VG Thats all nice, but the most crucial information is missing - how to specify the source and destination VG - is source first or destination first? I suggest changing the USAGE to something like: vgmerge destinationVG sourceVG -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.4.24-050424-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lvm2 depends on: ii dmeventd 2:1.02.155-3 ii dmsetup 2:1.02.155-3 ii libaio1 0.3.112-3 ii libblkid1 2.33.1-0.1 ii libc6 2.28-10 ii libdevmapper-event1.02.1 2:1.02.155-3 ii libdevmapper1.02.12:1.02.155-3 ii libreadline5 5.2+dfsg-3+b13 ii libselinux1 2.8-1+b1 ii libsystemd0 241-7~deb10u3 ii libudev1 241-7~deb10u3 ii lsb-base 10.2019051400 Versions of packages lvm2 recommends: ii thin-provisioning-tools 0.7.6-2.1 lvm2 suggests no packages. -- Configuration Files: /etc/lvm/lvmlocal.conf changed [not included] -- debconf information excluded
Bug#953829: regression/crash: mtr: Probes exhausted
Package: mtr-tiny Version: 0.92-2 Severity: normal Dear Maintainer, recent versions of mtr started to crash seemingly randomly with the following message: mtr: Probes exhausted and an exit status of 1. It's not consistently reproducible, but I found that when specifying a low interval, e.g. mtr -i 0.01 target it happens much more often than with the default interval. This might not be new. However, I use mtr daily for many years, and also with low intervals, and have never seen this message until recently, so I assume this is new behaviour. -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.4.24-050424-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mtr-tiny depends on: ii libc62.28-10 ii libncurses6 6.1+20181013-2+deb10u2 ii libtinfo66.1+20181013-2+deb10u2 mtr-tiny recommends no packages. mtr-tiny suggests no packages. -- no debconf information
Bug#953076: unace: goes into endless loop when stdin is /dev/null
Package: unace Version: 1.2b-17 Severity: normal Dear Maintainer, unace goes into an endless loop when stdin is /dev/null, for example, when using xargs:; unace t x.ace
Bug#916260: gparted mounts partition without protection
On Fri, Feb 14, 2020 at 02:52:59PM -0500, Phillip Susi wrote: > > You keep making this false claim, but that doesn't lend it more > > credence. POSIX permissions work the way they work, and if you think some > > combination of permissions are wrong, what are the rules to determine > > right and wrong and what is your source for this repeated statement? > > Simple... right doesn't allow access to the people you don't want to > have it. Wrong permissions do allow access to those you don't intend to > have it. Working around that by other means ( to deny access to the > entire filesystem ) does not change the fact that the permissions on the > file are not configured correctly to carry out your intent. No, it just means gparted has a security bug, because the permissions did work as the user intended before gparted changed them without the users knowledge, and they would have worked if gparted wasn't insecurely exposing the files. gparted *changed* the effective permissions of files by mounting the fs in an insecure location. The reason why your logic doesn't work is that you claim *every* debian root fs has the wrong permissions, because some directories might be world-writable (such as /tmp) which might not be what the user intended by not having the fs mounted in an insecure location (and thus allowing a DoS attack). It would also mean filesystems such as fat, without intrinsic permissions, would somehow have "wrong" permissions. I really don't understand why it is so difficult to simply accept that gparted has a security bug. It happens. It should be fixed. It's not the most dangerous security bug, after all... Fact is, gparted exposes files because it changes effective permissions. Whether you all these permissions right or wrong, green or blue, ethical or satanistic doesn't have any influence on this fact - all these classifications are your own personal opinions and don't have any merit in objectively analying this bug. > > Ah, maybe I see where you are copming from - gparted changes effective > > permissions, so they are wrong. > > No, I didn't say anything about gparted. Well, then you missed the topic - this bug report is about discussing a specific gparted security bug, if you want to discuss something else, you can try to engange me somewhere else or privately. > When gparted mounts it somewhere that isn't traverse proof, yes, that > does allow access where it was not previously, but that's really only > exposing the underlying bug that was always there: that the permissions > on the files are too loose. Well, I have asked you for the source of this claim, but you haven't given one - and I claim you just made it up, because I can't believe you have a source. If you could point out where, in the SuS, it says which permissions are wrong and which are right, then you might have something to discuss. But SuS only documents how permissions work, how they effectively apply, and according to the cold hard facts, gparted exposes files that weren't exposed before. It's that simple. Anyways, I am out of here, have a good one! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#916260: gparted mounts partition without protection
On Fri, Feb 14, 2020 at 10:11:13AM -0500, Phillip Susi wrote: > > doesn't matter how exactly I change a file, as long as I can change it > > when I shouldn't be, it is a security bug. > > True, you can delete the file and replace it, but then it is now owned > by you instead of the original owner. It's a fair argument that it > amounts mostly to the same thing. Maybe it helps when you realise thta chown can also modify a file... > > No, there are other possibilities, but that is one way, yes. > > Other possibilities like what? You yourself mentioned some - in any case, does this lead somewhere? > >> looser permissions, and that amounts to the same thing as just not > >> keeping it mounted most of the time. > > > > No, these are very different things. > > How so? If you can't see how not mounting a filesystem and having ti accessible by various means are very different, I am afraid I don't see how I can explain it to you. > In both cases the permissions on the file itself are wrong, You keep making this false claim, but that doesn't lend it more credence. POSIX permissions work the way they work, and if you think some combination of permissions are wrong, what are the rules to determine right and wrong and what is your source for this repeated statement? It seems to me your claim of "wrongess" is a value statement only - do you have any objective arguments, too? > > Your question is loaded, because it presumes that the correct permissions > > are somehow incorrect (a contradiction that any answer would have to > > accept, which makes it impossible to answer your question). That is > > The permissions allow access that you do not wish it to. Ipso facto, > the permissions are incorrect. Ah, maybe I see where you are copming from - gparted changes effective permissions, so they are wrong. Well, congratulations, that's exactly why this is a security bug in gparted - the user doesn't wish file access and configures the permissions accordingly, but gparted circumvents this user configuration, and this is unexpected, and incorrect behaviour. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#916260: gparted mounts partition without protection
On Tue, Feb 11, 2020 at 09:18:30AM -0500, Phillip Susi wrote: > > The effective permissions for a path depend on more than just the > > permissions of the file it refers to. For example, a root-only readable > > file can still be changed by normal users if the directory is writable for > > them. > > No, it can't. Yes it can. > If the directory is writable, then the user can modify the directory, > i.e. to rm the file, but they can't modify the file itself. When you recreate a file with different contents you have modified it. Anything else is weird word twisting, and not useful in this context - it doesn't matter how exactly I change a file, as long as I can change it when I shouldn't be, it is a security bug. > > effective permissions in ways not expected by the user, by mounting it in > > an insecure location. > > The only way it can change the effective permissions are if you normally > have it mounted in a directory that uses the traverse/execute permission > to restrict who can traverse it with the files inside otherwise having No, there are other possibilities, but that is one way, yes. > looser permissions, and that amounts to the same thing as just not > keeping it mounted most of the time. No, these are very different things. > filesystem namespace so that it is only mounted to the one user and not > visable to the rest of the system. Either way, it begs the question: > why not just set the permissions correctly instead? Your question is loaded, because it presumes that the correct permissions are somehow incorrect (a contradiction that any answer would have to accept, which makes it impossible to answer your question). That is not so, of course, which I have already pointed out (wehich begs the question why you repeat this falsehood :). > Come to think of it, maybe using filesystem namespaces would be a better > idea than chmod()ing the /tmp mount point ( and then creating another > subdirectory in which to actually mount the fs ). A less portable, more complicated, but altogether valid solution, yes. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#950985: rsync: hlink.c:132: match_gnums: Assertion `gnum >= hlink_flist->ndx_start' failed.
Package: rsync Version: 3.1.3-6 Severity: minor Dear Maintainer, while running rsyc -avH, I got this assertion failure (non-repeatable): rsync: hlink.c:132: match_gnums: Assertion `gnum >= hlink_flist->ndx_start' failed. Aborted I suspect (but don't know) that this is due to me concurrently running a program on the source file tree that hardlinks files with identical contents, such replacing files with other files with identical content and name, but possibly different mtime etc. I suspect that a failed assertion is not the expected handling of this condition and a better response or error message is intended. -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.4.18-050418-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rsync depends on: ii base-files 10.3+deb10u3 ii init-system-helpers 1.56+nmu1 ii libacl1 2.2.53-4 ii libattr1 1:2.4.48-4 ii libc62.28-10 ii libpopt0 1.16-12 ii lsb-base 10.2019051400 rsync recommends no packages. Versions of packages rsync suggests: ii openssh-client 1:7.9p1-10+deb10u2 ii openssh-server 1:7.9p1-10+deb10u2 -- no debconf information
Bug#916260: gparted mounts partition without protection
On Mon, Feb 03, 2020 at 01:07:55PM -0500, Phillip Susi wrote: > > 3. Now *another user* on the same machine can access that file system, > >which I unwittingly mounted and exposed. > > I get it, I just don't understand why you would have a filesystem around > whose internal permissions were not already set up correctly but instead > you relied on not mounting it to protect it. It happens also for filesystems with correct permissions - maybe this is the point you have problems with? The effective permissions for a path depend on more than just the permissions of the file it refers to. For example, a root-only readable file can still be changed by normal users if the directory is writable for them. That means the whole access path needs to be taken into account, and this is why the security issue is in gparted, because gparted changes effective permissions in ways not expected by the user, by mounting it in an insecure location. Or in other wors, gparted can make files accessible that weren't accessible before, without the user reasonably expecting this (as the user expectation is that gparted doesn't widen effective permissions). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#950287: autofs: automount expriing unmounts target filesystem
On Sat, Feb 01, 2020 at 07:41:03AM +0800, Ian Kent wrote: > > decided that nobody should use symlinks as bind mounts are the > > future(tm). > > >From an upstream POV it was more neglect (on my part) of the > symlink code in favour of bind mounts. Not sure why you write this, but it's clearly not true: Date: Tue, 29 May 2001 14:00:42 -0700 [...] I don't want to perpetuate the symlink thing because it is a terrible hack in the kernel part of the code, and thus will be removed in autofs v5. -hpa (I hope he forgives me to quote a private mail, but the fact is documented in debian bug #128171). That was probably a bit before your time, but the last time I reported problems with symlinks to upstream I was told (in a long thread) that it is a hack and will not be supported. And the result was that the debian maintainer locally applied a patch (in 2006) to make symlinks configurable, for which I was super-thankful. (Note that there are two sides to this: symlinks for local nfs mounts, and symlinks for bind mounts, which are not the same, and which confused me for quite a while). > But the autofs amd format map support needs them to work properly > so quite a bit of effort went into making them work as best as I > could. Yes, I am very fond of this change in policy, thanks a lot - the effect is that I can consider autofs again for new deployments, rather than having had to give up on it :) I also am very fond of amd map support, although documentation, of course, is sorely lacking. In any case, since we all seems to agree on the bug part, I think this part of the disucssion (who stated what policy when) should stay off the debian bts :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#928086: closed by Emfox Zhou (close the bug)
On Sat, Feb 01, 2020 at 07:33:11AM +, Debian Bug Tracking System wrote: > Subject: close the bug > > you can now custom your temp dir via preference. Thats cool, but that doesn't affect the bug in any way (which is about a wrong default) - unpacking big archives into /tmp (which is a tmpfs on standard debian) is wrong even if this can somehow be changed - kepe in mind that this can easily crash machines. In any case, I cannot force you to fix this bug, so if you want to keep mcomix buggy, I will not press this issue further. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#950287: autofs: automount expriing unmounts target filesystem
As added info, I installed 5.1.6 form tetsing on some of the affected machines, and the problem is indeed gone, local filesystems don't randomly get unmounted on autofs restarts or expires. Thanks! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#950287: autofs: automount expriing unmounts target filesystem
On Fri, Jan 31, 2020 at 02:24:11PM +, Mike Gabriel wrote: > Marc, as I get it, it would be welcome to get the discussed issue fixed in > Debian stable (aka buster). Right? It would be convenient yes, but since I had to roll back the timeout change (in my configs) anyway, I can live with the current version for a few more years, and it probably only affects a small subset of hosts anyway, as most only have a symlink to / which won't be unmounted aciidentally... The fact that upstream apparently changed policy on symlinks (to "supported", probably years ago, but I haven't known) is the most welcome news for me! Maybe some day I finally have a replacement for amd that can actually be restarted cleanly without rebooting the machine :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#950287: autofs: automount expriing unmounts target filesystem
On Fri, Jan 31, 2020 at 07:16:14PM +0800, Ian Kent wrote:
> It looks like this package has the change that adds handling of
> symlinks to umount_multi() so this should not be calling umount()
> at all.
Ah, I tried to see if there was a custom symlink patch in debians version,
but it seems to e integrated intot he source tree. I feel a bit guilty as I
think I am the likely reason why debian kept some symlink changes.
> >5463 execve("/bin/umount", ["/bin/umount", "/fs/bp"],
> > 0x555b23a0 /* 20 vars */) = 0
>
> Yeah, it may have done that before the symlink handling change
> I mentioned. For a long time there wasn't sufficient attention
> given to symlinks in favour of bind mounting.
That's because the previous autofs maintainer, in true systemd fashioon,
decided that nobody should use symlinks as bind mounts are the future(tm).
This seesm to be no longer the case, and I greatly appreciate the apparent
change in policy to make symlinks viable - autofs would be completely
useless to me without symlink support.
> I definitely don't see the the target get umounted in the Fedora
> package or the current development source and I've verified the
I downlaoded autofs-5.1.5-10.fc30.src.rpm and indeed, this block is only in
the debian version (didn't check any .patch files in the rpm though):
/* If path is a mount it can't be a symlink */
if (is_mounted(_PATH_MOUNTED, path, MNTS_ALL))
goto real_mount;
And this is exactly the code that causes this problem. is_mounted has
different semantics depending on whether /dev/autofs exists.
> I could stop the path walk following symlinks but I'd rather not
> since the current code, including that of the Debian package (I'll
> look a bit closer at the Debian package source), has that early
> symlink handing I spoke about.
Right. Even if this problem is fixed though, maybe some thought should
be given to the fact that is_mounted is not useful for symlinks in the
current version as the result is essentially random (practically, lstat
vs. stat).
MY hunch is that the kernel shouldn't follow symlinks when testing for
mountpoints, but that probably can't be changed anymore.
> > It happens with the debian package I am using, yes.
>
> That's 5.1.2-4 right?
Yup!
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=/_/_//_/\_,_/ /_/\_\
Bug#950287: autofs: automount expriing unmounts target filesystem
> > Sounds like I have enough information to duplicate the problem so
> > I'll have a look see.
>
> Oh, as usual, what's the autofs source version of your package please,
> since I'll be using the current development source to work on it.
It's the one mentioned in my original report (that you probably didn't
get): 5.1.2-4
On Fri, Jan 31, 2020 at 02:07:54PM +0800, Ian Kent wrote:
> A quick test with the current Fedora autofs package, autofs-5.1.5-
> 10.fc30.x86_64, I see that at expire the symlink is removed but the
> mount point directory used for browsing isn't recreated.
>
> I'll need to fix that.
That's the minor aspect (But of course appreciqated :).
> IIUC, the other aspect of this problem is that the target of the
> symlink, the NFSv4 mount, is also umounted at expire. That doesn't
> happen with the above Fedora package.
The target (in my example) is not an NFS mount at all, it's just normal
mountpoint, the target of the symlink (which in general might not be a but
mountpoint, in my case, is one).
The problem is that autofs calls umount on the symlink (in my example,
/fs/bp), but umount follows symlinks, so the target filesystem is unnmounted,
if it is a mountpoint.
I tried with debug logging, and it looks like this on kill -USR1:
expiring path /fs/bp
umount_multi: path /fs/bp incl 1
umount_multi: removing symlink /fs/bp
expired /fs/bp
When stracing, it literally execs umount /fs/bp:
5463 execve("/bin/umount", ["/bin/umount", "/fs/bp"], 0x555b23a0 /* 20
vars */) = 0
As explained earlier this only happens with misc-device support because
autofs thinks /fs/bp is a mountpoint as the kernel seems to follow
symlinks as well - without /dev/autofs it uses another method which
correctly finds that /fs/bp is not a mountpoint, so umount is never
called.
> This could get a bit complicated since there have been kernel
> changes as well as user space changes to the symlink handling
> with later version of autofs, we will need to work that out as
> we go.
I don't think it's a new bug (or change) in the kernel, as I remember
having had exactly this problem years ago (so long ago that I forgot about
it when confronted with the workaround, but it came back to me quickly).
But for the record, I am using linux 5.4.15.
The reason I didn't report it at the time was that I binary-patched the
debian package (with a regex-replace on mount_bind.so), and obviously all
bets are off with that method, and I didn't have time to reproduce it with
the pristine debian package, which I did now, however.
> Can you confirm this second part of the problem occurs with the
> Debian package your using please, then we can hunt for patches
> from later autofs releases.
It happens with the debian package I am using, yes.
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=/_/_//_/\_,_/ /_/\_\
Bug#950287: autofs: automount expriing unmounts target filesystem
On Thu, Jan 30, 2020 at 11:50:32PM +, Mike Gabriel wrote: > This seems like something to be discussed upstream. I Cc:ed Ian Kent, maybe > he has some 2? to add. Cool! In the meantime, I digged a bit more, and it seems that it is because with misc-device support, autofs uses the AUTOFS_DEV_IOCTL_ISMOUNTPOINT ioctl to check whether something is a mountpoint, which returns 1, which causes the code in umount_multi to decude it cannot be symlink and unmounting it. Indeed, rm /dev/autofs before starting autofs makes it partially work (the target dir is not unmounted, but the entry is still gone without ghosting). Upstream probably already knows this, of course. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#950287: autofs: automount expriing unmounts target filesystem
Package: autofs Version: 5.1.2-4 Severity: normal Dear Maintainer, for many years, I started automount with -t 8640, and by now had forgotten what this was for (or whether I reported the problem). Today, I removed it and got reminded what it was supposed to work around. Effectively, when automount expires mountpoints, specifically symlink bind mounts, it will unmount the target directory. Example, with browse mode being on: auto.master: /fs /etc/auto.fs symlink -vers=4,intr,rsize=1048576,wsize=1048576,tcp,port=2049,fsc auto.fs: bp -fstype=bind:/bp With this setup, doing ls /fs show a bp directory. ls /fs/bp will replace it by a symlink to /bp, then killall -USR1 automount will remove /fs/bp (which I think it shouldn't when in browse mode, bug #1) and ALSO unmount /bp (bug #2, the real problem). I guess automount simply calls umount on the symlink and then unlinks it. killall -HUP automount will bring back the ghosted /fs/bp entry. alternatively, ls /fs/bp will bring bakc the symolink, butg of course the target directory stays unmounted. I think I never reported it because this behaviour was with my own patched copy, but it is reproducible with the pristine version. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.4.15-050415-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autofs depends on: ii libc62.28-10 ii libxml2 2.9.4+dfsg1-7+b3 ii ucf 3.0038+nmu1 Versions of packages autofs recommends: ii e2fsprogs 1.45.5-2 ii kmod26-1 ii nfs-common 1:1.3.4-2.5 autofs suggests no packages. -- debconf information excluded
Bug#949777: pngnq: should not log to syslog
Package: pngnq Version: 1.0-2.3+b1 Severity: normal Dear Maintainer, pngnq unconditionally logs most errors and warnings tgo syslog. This makes little sense in most circumstances. It would nice if pngnq wouldn't log to syslog by default. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.4.12-050412-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pngnq depends on: ii libc62.28-10 ii libpng16-16 1.6.36-6 ii zlib1g 1:1.2.11.dfsg-1 pngnq recommends no packages. pngnq suggests no packages. -- no debconf information
Bug#948210: ftpmirror: does not handle filenames beginning or ending with whitespace
Package: ftpmirror Version: 1.96+dfsg-16+b1 Severity: normal Dear Maintainer, I found that ftpmirror does not handle filenames with leading or trailing spaces in unix directory listings. To make matters worse, the error message one gets is not very helpful: get_misc: can't get array at blib/lib/Fan.pm (autosplit into blib/lib/auto/Fan/run_full_mirror.al) line 1269. and then ftpmirror crashes. An example file listing where this happens looks like this: drwxr-xr-x 2 ftp ftp 4 Mar 15 2007 the dir to look at drwxr-xr-x 2 ftp ftp 4 Mar 15 2007 trailing spaces I found it works pretty reliable again after editing /usr/lib/ftpmirror/auto/Fan/Attrib/from_list.al and changing these lines: # kill leading/trailing spaces, and trailing slash s/^\s+//; s/\s+$//; s/\/$//; to: # kill leading space and trailing slash s/^\s//; s/\/$//; i.e. instead of removing all whitespace, it only removes the single whitespace after the file time, and never removes trailing whitespace. I'm not sure trailing whitespace actually exists in reality, but I can imagine extra whitespace after the date, although I haven't seen this yet. Given the age of ftpmirror, I'm not really expecting much action here, maybe a patch or note might be useful though. (I use ftpmirror because, although lftp is quite reliable, it also lacks a lot of the options of ftpmirror, e.g. it can't exclude paths, so it's still useful :) -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.4.7-050407-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ftpmirror depends on: ii libc6 2.28-10 ii perl5.28.1-6 ii perl-base [perlapi-5.28.0] 5.28.1-6 pn perlapi-5.24.1 pn perlapi-5.30.0 Versions of packages ftpmirror recommends: ii cron 3.0pl1-134+deb10u1 ftpmirror suggests no packages.
Bug#948108: unrar corrupts filenames given as arguments
Package: unrar
Version: 1:5.6.6-2
Severity: normal
Dear Maintainer,
when passing certain (archive) filenames to unrar, unrar will corrupt them
and not be able to open them. The peculiar way this corruption occurs
hints at possible security issues.
Example:
strace -feexecve,stat perl -e 'system "unrar", "x", "x\x92.rar"'
Outputs, among other things:
[pid 9326] execve("/bin/unrar", ["unrar", "x", "x\222.rar"], 0x557679f0
/* 112 vars */) = 0
[pid 9326] stat("x\222.ra", 0x7ffef1d0) = -1 ENOENT (No such file or
directory)
Cannot open x�.ra
(the later filename is written like this):
[pid 9390] write(2, "x", 1x)= 1
[pid 9390] write(2, "\357\277\276", 3�) = 3
[pid 9390] write(2, "\356\202\222", 3) = 3
[pid 9390] write(2, ".", 1.)= 1
[pid 9390] write(2, "r", 1r)= 1
[pid 9390] write(2, "a", 1a)= 1
[pid 9390] write(2, "\nN", 2
So somehow the \x92 character gets replaced, but also the trailing "r" (from
rar) is removed.
This happened in a utf-8 based locale (en_DK.UTF-8), which is probably
related.
Obviously, unrar should not mangle filenames, as filenames are
octet-strings, not locale-encoded.
-- System Information:
Debian Release: 10.2
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'),
(500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'),
(500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500,
'oldstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32
Kernel: Linux 5.4.7-050407-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages unrar depends on:
ii libc6 2.28-10
ii libgcc1 1:9.2.1-15
ii libstdc++6 8.3.0-6
unrar recommends no packages.
unrar suggests no packages.
-- no debconf information
Bug#947091: manpages-dev: timerfd_settime can fail with ECANCELED
Package: manpages-dev
Version: 5.04-1
Severity: wishlist
Dear Maintainer,
the timerfd_create/settime/... manpage documents that reads from a timerfd
configured with TFD_TIMER_CANCEL_ON_SET fail with ECANCELED, however, I
found that timerfd_settime (and probably timerfd_gettime and others) have
the same behaviour, and of course youc an poll for this event as well, and
all this is not documented.
Background: I was implementing time jump detection in libev using the
relatively new TFD_TIMER_CANCEL_ON_SET feature. For this, I arm the timer
with some future value and only use it for the side effect of getting
canceled (although it might occasionally expire).
The timerfd_create/settime calls look like this (future it_value.tv_sec
value, zero interval):
timerfd_create(CLOCK_REALTIME, TFD_CLOEXEC|TFD_NONBLOCK) = 5
timerfd_settime(5, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET,
{it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=1579464284, tv_nsec=0}},
NULL) = 0
all normal so far: On every time jump, I rearm the timer with
timerfd_settime, without having any other interaction with the timerfd
(other than polling it for read events). The following is the effect of
"date -s somevalue" three times:
timerfd_settime(5, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET,
{it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=949273200, tv_nsec=0}},
NULL) = -1 ECANCELED (Operation canceled)
timerfd_settime(5, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET,
{it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=949273200, tv_nsec=0}},
NULL) = -1 ECANCELED (Operation canceled)
timerfd_settime(5, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET,
{it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=949273200, tv_nsec=0}},
NULL) = -1 ECANCELED (Operation canceled)
>From this, I learn that timerfd_settime fails the same way as a read would
do (probably some error slippage happening) and despite timerfd_settime
failing with ECANCELED, it actually succeeds in rearming the timer.
Don't know if this is a kernel bug, but I assume this works more or less
as designed, but has escaped the documentation as TFD_TIMER_CANCEL_ON_SET
is a relatively new feature.
As a minor nitpick, the "Operating on a timer file descriptor" is a tiny
bit misleading, as it doesn't mention timerfd_gettime etc. as supported
"operations on a timerfd fd". And while it probably isn't a major thing in
the context, I do expect the utmost exactness from manpages-dev because
that is my past experiencw with it, so I suggest adding "additional" here:
The file descriptor returned by timerfd_create() supports the
following additional operations:
Thanks,
Marc
-- System Information:
Debian Release: 10.2
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'),
(500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'),
(500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500,
'oldstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32
Kernel: Linux 5.2.21-050221-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages manpages-dev depends on:
ii manpages 4.16-2
manpages-dev recommends no packages.
Versions of packages manpages-dev suggests:
ii konqueror [man-browser] 4:18.12.0-1
ii man-db [man-browser] 2.8.5-2
-- no debconf information
Bug#946962: gparted: fails resize on encrypted volumes
Package: gparted Version: 0.32.0-2 Severity: normal Dear Maintainer, gparted fails at resizing encrypted volumes when the volume was opened without --disable-keyring, as cryptsetup resize then requires the passphrase but gparted does not provide it. background: current cryptsetup versions use the kernel keyring to store encryption keys, which means resizes cannot be done without entering the passphrase again, as the key cannot be recovered (at leats by normal means) from the kernel anymore. unfortunately, gparted opens encrypted volumes without --disable-keyring, and then fails at the resize step as no password is provided. as a workaround, one can manually luksOpen the encrypted volume with --disable-keyring before running gparted. Either gparted should open encrypted volumes in a way that is comaptible with itself, or, better yet, it should support giving a passphrase to cryptsetup resize - it should properly cache the passphrase entered when opening the encrypted volume. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.2.21-050221-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gparted depends on: ii libatkmm-1.6-1v5 2.28.0-2 ii libc6 2.28-10 ii libgcc1 1:9.2.1-15 ii libglib2.0-0 2.58.3-2+deb10u2 ii libglibmm-2.4-1v5 2.58.0-2 ii libgtk2.0-0 2.24.32-3 ii libgtkmm-2.4-1v5 1:2.24.5-4 ii libpangomm-1.4-1v52.42.0-2 ii libparted-fs-resize0 3.2-25 ii libparted23.2-25 ii libsigc++-2.0-0v5 2.10.1-2 ii libstdc++68.3.0-6 ii libuuid1 2.33.1-0.1 gparted recommends no packages. Versions of packages gparted suggests: pn dmraid ii dmsetup2:1.02.155-3 ii dosfstools 4.1-2 ii e2fsprogs 1.45.4-1 ii gpart 1:0.3-6 pn jfsutils ii kpartx 0.7.9-3 ii mtools 4.0.23-1 ii ntfs-3g1:2017.3.23AR.3-3 ii reiser4progs 1.2.0-2 ii reiserfsprogs 1:3.6.27-3 ii udftools 2.1-1 ii xfsprogs 4.20.0-1 ii yelp 3.31.90-1 -- no debconf information
Bug#945977: displaycal: apparent missing dependency on dbuslaunch
Package: displaycal Version: 3.7.1.4-1 Severity: normal Dear Maintainer, After installing displaycal, starting it gave me the following backtrace and a crash. Installing dbus-x11 fixed this, so I guess displaycal (or a component it uses that requires it) should depend on this. XDG: [Errno 2] No translation file found for domain: xdg-user-dirs displaycal 3.8.8.1 2019-11-07T21:22:40.565184Z debian 10.2 x86_64 Python 2.7.16 (default, Oct 10 2019, 22:02:15) [GCC 8.3.0] ImportError: No module named faulthandler wxPython 3.0.2.0 gtk3 (classic) Encoding: UTF-8 File system encoding: UTF-8 ┌──┐ │ Traceback (most recent call last): │ │ File "/usr/lib/python2.7/dist-packages/DisplayCAL/main.py", line 353, in │ │ main │ │ _main(module, name, applockfilename) │ │ File "/usr/lib/python2.7/dist-packages/DisplayCAL/main.py", line 283, in │ │ _main│ │ from wxwindows import BaseApp│ │ File "/usr/lib/python2.7/dist-packages/DisplayCAL/wxwindows.py", line 26, │ │ in │ │ import ICCProfile as ICCP│ │ File "/usr/lib/python2.7/dist-packages/DisplayCAL/ICCProfile.py", line 37, │ │ in │ │ import colord│ │ File "/usr/lib/python2.7/dist-packages/DisplayCAL/colord.py", line 27, in │ │ │ │ from util_dbus import DBusObject, DBusException, BUSTYPE_SYSTEM │ │ File "/usr/lib/python2.7/dist-packages/DisplayCAL/util_dbus.py", line 21, │ │ in │ │ dbus_session = Gio.bus_get_sync(Gio.BusType.SESSION, None) │ │ Error: g-exec-error-quark: Failed to execute child process “dbus-launch” (No │ │ such file or directory) (8) │ └──┘ Exiting displaycal Ran application exit handlers -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.2.21-050221-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages displaycal depends on: ii argyll 2.0.1+repack-1 ii libc62.28-10 ii libjs-jquery 3.3.1~dfsg-3 ii libx11-6 2:1.6.7-1 ii libxinerama1 2:1.1.4-2 ii libxrandr2 2:1.5.1-1 ii libxxf86vm1 1:1.1.4-1+b2 ii python 2.7.16-1 ii python-numpy 1:1.16.2-1 ii python-wxgtk3.0 3.0.2.0+dfsg-8 Versions of packages displaycal recommends: ii colord1.4.3-4 ii gir1.2-colordgtk-1.0 0.1.26-2 displaycal suggests no packages. -- no debconf information
Bug#935471: systemd: bogus "Process .. as been marked to be excluded from killing" warning from systemd-shutdown
On Sat, Nov 30, 2019 at 06:02:17PM +0100, Michael Biebl wrote: > > That's silly and dishonest. > > I guess you just proved the point, thank you. Your point is that when _you_ start throwing around ad-hominems that this is a sign that the _other_ side has stopped being constructive? Is this designed to leave me speechless? Anyway, wwhatever pleases you, I guess - I have explained why you have all the necessary information, and you have not explained why you would need the contents of my script, which are clearly not needed. It is clearly you who stopped being "collaborative". Being an arrogant prick and needlessly starting to insult bug reporters who act in good faith doesn't help things. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#935471: systemd: bogus "Process .. as been marked to be excluded from killing" warning from systemd-shutdown
On Sat, Nov 30, 2019 at 04:14:55PM +0100, Michael Biebl wrote: > I assume there is no further interest to work collaboratively on this > from the bug reporters side, so closing the issue. Your assumption is wrong, lacks good faith and is unnecessarily insulting - I provided all information requested and necessary to fix this issue and just don't have enough time to chase extra info that is clearly unnecessary and just adds a lot of extra work for me or requires me to disclose information that is neither public nor needed to fix this issue, _as I already have explained_. What else do you want, a full filesysstem dump? Sorry, but the ball is in your court - either fix the bug or don't fix it, but don't make me responsible for it: I did my part. Seriously, just admit that you just don't want to fix this bug (because that iws clearly the issue here) and don't try to bury it under an unreasonable list of extra requirements so you can spread FUD about me not wanting to work on this collaboratively, as is already disproven by the effort I made documenting this issue and reporting it. That's silly and dishonest. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#935471: systemd: bogus "Process .. as been marked to be excluded from killing" warning from systemd-shutdown
Hi!
All information asked for was either already provided (you even quote the
text where it was provided!) or is entirely unnecessary to investigate
this problem. I have tried to duplicate the information in a different
form below, in case there was a comprehension issue. If you still think
some information is missing you would need to more clearly explain what
you think is missing, and I'd be happy to provide it.
On Tue, Nov 12, 2019 at 12:55:42AM +0100, Michael Biebl
wrote:
> > To accomplish this I have an initramfs-tools script that runs it something
> >
> > exec -a @ntfs-3g-root ntfs-3g ...
>
> Would be great if you can share this script so we can see what exactly
> it is doing.
Uhm, what other information could potentially be of use? Nothing else
in the script is of any relevance, other than starting a daemon with
@ as first character of its name. The arguments do not do anything to
change the name, and that's essentially the only other thing that the
script does. The only relevant information is that systemd has special
(but buggy) code for processes whose names start with '@' - nothing else
matters, as systemd clearly doesn't check for anything else, as you can
see in the code - just grep for the log_notice I provided (I don't have
easy access to it righ now, otherwise I woudl do it for you).
> > The @ prevents systemd-shutdown from killing it, which works. However, it
> > outputs the following warning (lifted from the code, can't copy from
> > the real system):
> >
> > log_notice("Process " PID_FMT " (%s) has been marked to be
> > excluded from killing. It is "
> >"running from the root file system, and thus
> > likely to block re-mounting of the "
> >"root file system to read-only. Please consider
> > moving it into an initrd file "
> >"system instead.", pid, strna(comm));
> >
> > Since it is running from the initramfs, this warning is bogus (and indeed,
> > the root fs can be mounted ro with no problem), suggesting that the check
> > systemd-shutdown uses to detect this case is broken.
> >
> > For additional reference, /proc//root has a target of "/",
> > which probably causes this. /proc//exe has a target of
> > '/usr/bin/ntfs-3g (deleted)', which makes sense as it was deleted when
> > cleaning up the initramfs before handing over to the actual root fs.
>
> Please supply the information that was requested by upstream:
The information is right in the paragraph you just quoted - root points to
"/" and exe points to "/usr/bin/ntfs-3g (deleted)".
> have a magic effect, and point to something potentially different than
> their literal value. Hence, can you do stat on those two magic symlinks
> to see what they actually point to?
stat can't show you what they "actually" point to, but since the command
was started using initramfs (as also already mentioned), / obviously
points to the root of the initramfs, and the ntfs-3g dxecutable in there
has been deleted when it was cleaned up during boot, unless you want to
assume a kernel bug.
What _stat_ can tell you is that "root" points to a different filesystem
(the tmpfs used by the kernel) than the current root filesystem that is
supposedly blocked.
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=/_/_//_/\_,_/ /_/\_\
Bug#943544: "read out of range" on ntfs-files with streams
Mystery is solved, when an ntfs file has a data stream, then grub fails with an "out of range" error while reading. Should be relatively easy to fix by ignoring extended attributes, or at the very least giving a sensible error message :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#939856: unattended-upgrades: claims to upgrade packages, but then only upgrades some
Package: unattended-upgrades Version: 0.93.1+nmu1 Severity: normal Dear Maintainer, I'm sure I am doing something wrong, but if I do, then I think unattended-upgrades should explain itself better. I maintain a small pool of stretch machines which were all cloned from the same master image, with some local package changes - some use exim4-daemon-light, some use exim4-daemon-heavy. After CVE-2019-15846, I had a look at whether unattended-upgrades has properly installed security fixes, but what I found I cannot explain: On machines using exim4-daemon-light, everything was upgraded: ii exim4-base 4.89-2+deb9u6 ii exim4-config 4.89-2+deb9u6 ii exim4-daemon-light 4.89-2+deb9u6 On machines using exim4-daemon-heavy, everything but that package was upgraded: ii exim4-base 4.89-2+deb9u6 ii exim4-config 4.89-2+deb9u6 ii exim4-daemon-heavy 4.89-2+deb9u3 If I run unattended-upgrades -v manually, it clearly claims to have installed it successfully: 2019-09-08 13:22:07,884 INFO Packages that will be upgraded: exim4-daemon-heavy 2019-09-08 13:22:07,884 INFO Writing dpkg log to '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log' 2019-09-08 13:22:07,926 INFO All upgrades installed But it didn't. And in fact, looking at the log, it keeps saying this for a while already: 2019-06-07 06:36:19,385 INFO Starting unattended upgrades script 2019-06-07 06:36:19,385 INFO Allowed origins are: ['origin=Debian,codename=stretch,label=Debian-Security'] 2019-06-07 06:36:23,617 INFO Packages that will be upgraded: exim4-base exim4-config exim4-daemon-heavy 2019-06-07 06:36:23,618 INFO Writing dpkg log to '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log' 2019-06-07 06:37:08,647 INFO All upgrades installed 2019-06-08 06:18:09,946 INFO Starting unattended upgrades script 2019-06-08 06:18:09,947 INFO Allowed origins are: ['origin=Debian,codename=stretch,label=Debian-Security'] 2019-06-08 06:18:15,564 INFO Packages that will be upgraded: exim4-daemon-heavy qemu-kvm qemu-system-common qemu-system-x86 qemu-utils 2019-06-08 06:18:15,564 INFO Writing dpkg log to '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log' 2019-06-08 06:18:50,208 INFO All upgrades installed 2019-06-09 06:00:07,184 INFO Allowed origins are: ['origin=Debian,codename=stretch,label=Debian-Security'] 2019-06-09 06:00:10,673 INFO Packages that will be upgraded: exim4-daemon-heavy 2019-06-09 06:00:10,673 INFO Writing dpkg log to '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log' 2019-06-09 06:00:10,721 INFO All upgrades installed ... from here on the last lines keep repeating. Nothing in the log indicates that it installs some packages, but not others. There is no mention of even trying to install exim4-daemon-heavy in unattended-upgrades-dpkg.log. So, unattended-upgrades on this machine clearly installed most security updates, but not exim4-daemon-heavy. It claims to install it, and that everything went ok, but in fact, it doesn't even try. When I run apt install exim4-daemon-heavy manually, it installs it without issues. Even if this is some kind of misconfiguration on my part, I think that unattended-upgrades should not claim it has installed security updates when in fact it didn't do anything at all. Version of unattended upgrades is: ii unattended-upgrades 0.93.1+nmu1
Bug#939358: budgie-core: missing dependency on gnome-session
Package: budgie-core Version: 10.2.9-2 Severity: normal Dear Maintainer, installing budgie-core leaves it unstartable, as running budgie-session requires gnome-session, which isn't in any of the dependencies. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.1.21-050121-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages budgie-core depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 pn gnome-settings-daemon pn libaccountsservice0 ii libasound2 1.1.8-1 ii libatk1.0-0 2.30.0-2 pn libbudgie-plugin0 pn libbudgie-private0 pn libbudgietheme0 ii libc62.28-10 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libdrm2 2.4.97-1 ii libegl1-mesa 18.3.6-2 ii libgbm1 18.3.6-2 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgirepository-1.0-11.58.3-2 ii libglib2.0-0 2.58.3-2 pn libgnome-bluetooth13 pn libgnome-desktop-3-12 ii libgnome-desktop-3-173.30.2.1-2 pn libgnome-menu-3-0 ii libgtk-3-0 3.24.5-1 ii libibus-1.0-51.5.19-4 ii libjson-glib-1.0-0 1.4.4-2 pn libmutter-3-0 pn libmutter0i ii libnotify4 0.7.7-4 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libpangocairo-1.0-0 1.42.4-7~deb10u1 ii libpeas-1.0-01.22.0-4 ii libpolkit-agent-1-0 0.105-25 ii libpolkit-gobject-1-00.105-25 ii libpulse-mainloop-glib0 12.2-4 ii libpulse012.2-4 pn libraven0 ii libupower-glib3 0.99.10-1 ii libuuid1 2.33.1-0.1 ii libwayland-client0 1.16.0-1 ii libwayland-egl1 [libwayland-egl1-mesa] 1.16.0-1 ii libwayland-server0 1.16.0-1 pn libwnck-3-0 ii libx11-6 2:1.6.7-1 ii libxcomposite1 1:0.4.4-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxrandr2 2:1.5.1-1 budgie-core recommends no packages. budgie-core suggests no packages.
Bug#939053: firejail: dolphin profile only allows single window
Package: firejail Version: 0.9.58.2-2 Severity: normal Dear Maintainer, when running dolphin in firejail with the default profile, it can only open a single window/can only be started once. opening a second instance fails like this (including quotes): "Couldn't register name 'org.kde.dolphin-3' with DBUS - another process owns it already!" org.kde.dolphin-3 also is seen with other numbers at the end. I would have expected that basic usage of dolphin is undisturbed by firejail, but maybe my expectation is wrong and this is the expected outcome. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.1.21-050121-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firejail depends on: ii libapparmor1 2.13.2-10 ii libc6 2.28-10 Versions of packages firejail recommends: ii firejail-profiles 0.9.58.2-2 ii iproute2 4.20.0-2 ii iptables 1.8.2-4 ii xauth 1:1.0.10-1 ii xserver-xephyr 2:1.20.4-1 ii xvfb 2:1.20.4-1 firejail suggests no packages. -- no debconf information
Bug#935725: util-linux: lsblk sometimes gives wrong pttype "dos" for gpt partitions
Package: util-linux Version: 2.33.1-0.1 Severity: normal Dear Maintainer, I have a script that gathers information using lsblk., It specifically needs the partition table type, uuid and partition uuid. It uses something like this: lsblk -o PATH,KNAME,MAJ:MIN,TYPE,PTTYPE,PTUUID,PARTUUID,LABEL,FSTYPE This works mostly fine, except on some disks, it gives a bogus PTTYPE of "dos" when it should be "gpt" for example: PATH KNAME MAJ:MIN TYPE PTTYPE PTUUID PARTUUID LABEL FSTYPE /dev/loop4 loop4 7:4 loop USBROOT btrfs /dev/sda sda 8:0 disk gpt81c62d1c-b086-4f48-b1e9-b8ae2d457f91 /dev/sda1 sda18:1 part gpt81c62d1c-b086-4f48-b1e9-b8ae2d457f91 cf573ead-cdeb-42d5-9d75-aee9ceec3370 /dev/sda2 sda28:2 part gpt81c62d1c-b086-4f48-b1e9-b8ae2d457f91 89a285e0-09ca-44eb-b7ca-e1261a5e2f07 USBEFI vfat /dev/sda3 sda38:3 part dos81c62d1c-b086-4f48-b1e9-b8ae2d457f91 d7f7dfdf-a2a6-4097-9975-c09fa73b19b3 DATAntfs /dev/sr0 sr011:0 rom Here, /dev/sda3 has a bogus pttype of "dos", but correct PTUUID and PARTUUID values (mbr entries don't have uuids). -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.1.21-050121-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii fdisk 2.33.1-0.1 ii libaudit1 1:2.8.4-3 ii libblkid1 2.33.1-0.1 ii libc6 2.28-10 ii libcap-ng0 0.7.9-2 ii libmount1 2.33.1-0.1 ii libpam0g 1.3.1-5 ii libselinux12.8-1+b1 ii libsmartcols1 2.33.1-0.1 ii libsystemd0241-5 ii libtinfo6 6.1+20181013-2 ii libudev1 241-5 ii libuuid1 2.33.1-0.1 ii login 1:4.5-1.1 ii zlib1g 1:1.2.11.dfsg-1 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.1-2 ii kbd 2.0.4-4 pn util-linux-locales -- debconf information excluded
