Bug#831390: libnss-extrausers is not thread safe, in particular for function getgrouplist()
This bug seems to have been inactive for many years. In the mean time there has been a discussion on https://sourceware.org/bugzilla/show_bug.cgi?id=27731 about getgrouplist(). The conclusion from this is that libnss-extrausers should supply a function _nss_extrausers_initgroups_dyn() that in a thread-safe way should provide the required information. Via https://forge.univention.org/bugzilla/show_bug.cgi?id=39775 it seems that somebody even made a patch which supplies that version, but then still uses the non-thread safe functions to implement it. Is there even still an upstream for this library? The only place I could find was with debian packages such as https://packages.debian.org/sid/libnss-extrausers . From there you can try to find an upstream in the .dsc file. That links to https://anonscm.debian.org/cgit/collab-maint/libnss-extrausers.git/log/?h=debian which no longer seems to exist... (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831390) -- Olaf Seibert Site Reliability Engineer SysEleven GmbH Boxhagener Straße 80 10245 Berlin T +49 30 233 2012 0 F +49 30 616 7555 0 https://www.syseleven.de https://www.linkedin.com/company/syseleven-gmbh/ Current system status always at: https://www.syseleven-status.net/ Company headquarters: Berlin Registered court: AG Berlin Charlottenburg, HRB 108571 Berlin Managing directors: Andreas Hermann, Jens Ihlenfeld, Norbert Müller, Jens Plogsties
Bug#1069831: kaddressbook: KAddressBook is not in the application launcher.
Package: kaddressbook
Version: 4:22.12.3-1+b1
Severity: normal
Dear Maintainer,
the term used in the KDE Help Center (KDE-Hilfezentrum) is
"KAddressBook" ("Das Handbuch zu KAddressBook").
There is no "KAddressBook" in the "KDE application launcher"
("Anwendungsstarter", my translation, what this launcher is called in
the original is unknown to me).
However, there is an "Addressbuch" which becomes "KAddressBook" after
startup.
Maybe it has something to do with the infantilization of program
names, as GNOME has done, maybe it is a translation error into German?
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-security'), (9, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.28 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages kaddressbook depends on:
ii akonadi-server 4:22.12.3-1+b1
ii kaddressbook-data 4:22.12.3-1
ii kdepim-runtime 4:22.12.3-2
ii libc6 2.38-6
ii libgcc-s1 14-20240330-1
ii libkf5akonadicontact5 [libkf5akonadicontact5-22.12] 4:22.12.3-1+b1
ii libkf5akonadicore5abi2 [libkf5akonadicore5-22.12] 4:22.12.3-1+b1
ii libkf5akonadisearch-bin 4:22.12.3-1+b1
ii libkf5akonadisearch-plugins 4:22.12.3-1+b1
ii libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-2 4:22.12.3-1+b1
2.12]
ii libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22.12 4:22.12.3-1+b1
]
ii libkf5configcore5 5.107.0-1+b1
ii libkf5configgui55.107.0-1+b1
ii libkf5configwidgets55.107.0-2+b1
ii libkf5contacts5 5:5.107.0-1
ii libkf5coreaddons5 5.107.0-1+b1
ii libkf5crash55.107.0-1+b1
ii libkf5grantleetheme5 [libkf5grantleetheme5-22.12] 22.12.3-2+b1
ii libkf5i18n5 5.107.0-1+b1
ii libkf5itemmodels5 5.107.0-1+b1
ii libkf5kcmutils5 5.107.0-2+b1
ii libkf5kontactinterface5 [libkf5kontactinterface5-22.12 22.12.3-1+b1
]
ii libkf5libkdepim5 [libkf5libkdepim5-22.12] 4:22.12.3-1
ii libkf5parts55.107.0-1+b1
ii libkf5pimcommon5abi2 [libkf5pimcommon5-22.12] 4:22.12.3-1
ii libkf5pimcommonakonadi5abi1 [libkf5pimcommonakonadi5-2 4:22.12.3-1
2.12]
ii libkf5widgetsaddons55.107.0-1+b1
ii libkf5xmlgui5 5.107.0-1+b1
ii libkpimaddressbookimportexport5 [libkpimaddressbookimp 4:22.12.3-1+b1
ortexport5-22.12]
ii libkuserfeedbackcore1 1.3.0-3+b1
ii libkuserfeedbackwidgets11.3.0-3+b1
ii libqt5core5t64 [libqt5core5a] 5.15.10+dfsg-7.2+b1
ii libqt5dbus5t64 [libqt5dbus5]5.15.10+dfsg-7.2+b1
ii libqt5gui5t64 [libqt5gui5] 5.15.10+dfsg-7.2+b1
ii libqt5printsupport5t64 [libqt5printsupport5]5.15.10+dfsg-7.2+b1
ii libqt5widgets5t64 [libqt5widgets5] 5.15.10+dfsg-7.2+b1
ii libstdc++6 14-20240330-1
Versions of packages kaddressbook recommends:
ii kdepim-addons 22.12.3-1
kaddressbook suggests no packages.
-- no debconf information
Bug#1060121: mdadm: Value "basecamp:0" cannot be set as name. Reason: Not POSIX compatible. Value ignored.
Package: mdadm Version: 4.2+20231121-1devuan1 Severity: normal Dear Maintainer, * What led up to the situation? Upgrading mdadm to the indicated version (or starting from 4.2+20230901-1).q * What exactly did you do (or not do) that was effective (or ineffective)? I did not do anything other than upgrade. * What was the outcome of this action? The mdadm periodic job to check for degraded arrays started issuing the warning message in the subject. Just running `mdadm --detail /dev/md0` produces the same message. * What outcome did you expect instead? No warning message from mdadm command invocations. The /etc/mdadm/mdadm.conf file was created by the installer and never modified afterwards. FYI, it includes the following comment # This configuration was auto-generated on Sat, 06 Aug 2022 12:36:25 +0900 by mkconf which corresponds to the time I installed the system. The installer put mdadm 4.1-11 on the system, in case that matters. I have been tracking "testing" since. On another system running "stable", I have mdadm 4.2-5 which does not produce this warning. That system has a similar mdadm.conf, only the UUID and hostname differ. The warning was introduced upstream on 2023-06-01 in e2eb503b which would indicate it first entered Debian with version 4.2+20230901-1 of the package. The POSIX compatible character set does not include the `:` which is why the warning triggers. After some searching on how to get rid of the warning, I am not sure if I should or even can as the hostname seems to get included automatically. If so, perhaps the POSIX check should skip the hostname and `:`? Or should a postinst somehow rename the (live) array (and rebuild the initramfs) to adjust to the upstream change, seeing that I never made any changes since I installed the system? # Note, my array contains /. BTW, my initrd is compressed by zstd. I've checked that it has no /conf/conf.d/md. It does contain a copy of /etc/mdadm/mdadm.conf. Also, I only have NVMe disks. It looks like /usr/share/bug/mdadm/script needs to catch up with new technology. Hope this helps, -- Package-specific info: --- mdadm.conf HOMEHOST MAILADDR root ARRAY /dev/md/0 metadata=1.2 UUID=7de21d27:72412544:e86f4f1e:b4e1487d name=basecamp:0 --- /etc/default/mdadm AUTOCHECK=true AUTOSCAN=true START_DAEMON=true DAEMON_OPTIONS="--syslog" VERBOSE=false --- /proc/mdstat: Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md0 : active raid1 nvme1n1p2[1] nvme0n1p2[0] 249401664 blocks super 1.2 [2/2] [UU] bitmap: 1/2 pages [4KB], 65536KB chunk unused devices: --- /proc/partitions: major minor #blocks name 2590 250059096 nvme0n1 2591 524288 nvme0n1p1 2592 249533767 nvme0n1p2 2593 250059096 nvme1n1 2594 524288 nvme1n1p1 2595 249533767 nvme1n1p2 90 249401664 md0 2530 29294592 dm-0 2531 97652736 dm-1 --- LVM physical volumes: LVM does not seem to be used. --- 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=32594668k,nr_inodes=8148667,mode=755,inode64) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=6522772k,mode=755,inode64) /dev/mapper/basecamp-root on / type ext4 (rw,relatime,errors=remount-ro) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64) securityfs on /sys/kernel/security type securityfs (rw,relatime) pstore on /sys/fs/pstore type pstore (rw,relatime) none on /sys/firmware/efi/efivars type efivarfs (rw,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=13045540k,inode64) /dev/nvme1n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) /dev/mapper/basecamp-home on /home type ext4 (rw,relatime) rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime) /etc/autofs/nas.conf on /srv/nas type autofs (rw,relatime,fd=6,pgrp=1593,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=12446) /dev/mapper/basecamp-root on /var/lib/docker type ext4 (rw,relatime,errors=remount-ro) cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot) tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=6522768k,nr_inodes=1630692,mode=700,uid=1000,gid=1000,inode64) --- initrd.img-6.5.0-5-amd64: gzip: /boot/initrd.img-6.5.0-5-amd64: not in gzip format cpio: premature end of archive --- initrd's /conf/conf.d/md: no conf/md file. --- /proc/modules: raid10 77824 0 - Live 0xc1582000 raid456 200704 0 - Live 0xc1541000 libcrc32c 12288 3 nf_conntrack,nf_tables,raid456, Live 0xc1537000 async_raid6_recov 20480 1 raid456, Live 0x
Bug#1059462: g++-13: GCC 13 for Bookworm
Package: g++-13 Severity: wishlist X-Debbugs-Cc: olafvds...@gmail.com Dear Maintainer, Would it be possible to provide GCC 13 for Bookworm, perhaps via backports? Olaf -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-16-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1059398: httping: New Upstream Version
Package: httping Version: 2.5-5.2+b1 Severity: wishlist X-Debbugs-Cc: olafvds...@gmail.com Hi, A new version has been released upstream: https://github.com/folkertvanheusden/HTTPing/releases Olaf -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.8-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages httping depends on: ii libc6 2.37-13 ii libfftw3-double3 3.3.10-1 ii libncursesw6 6.4+20231209-1 ii libssl3 3.1.4-2 ii libtinfo6 6.4+20231209-1 ii openssl 3.1.4-2 httping recommends no packages. httping suggests no packages. -- no debconf information
Bug#942100: openssh-server: /etc/ssh/sshd_config unconditionally overwritten by update
> Port 22 That should have been Port Additionally, when I reviewed the `permit-root-login` debconf settings against the postinst I got a bit confused. In `create_sshdconfig` it says if [ "$permit_root_login" != true ]; then sed -i 's/^#*PermitRootLogin .*/PermitRootLogin yes/' \ "$new_config" fi My debconf setting for `$permit_root_login` is `true` so the `$new_config` is left untouched and has a #PermitRootLogin prohibit-password It took me a second think to realize that `prohibit-password` still permits root logins. However, what left me dumb-founded was that if I were to change `permit-root-login` to any value other then `true`, even `false` or `no` (debconf says it's a boolean), that that would change `$new_config` to have PermitRootLogin yes FWIW, PermitRootLogin supports four values. I find the debconf/postinst behavior *very* unintuitive, so I didn't change my debconf answers and put PermitRootLogin no in a `/etc/ssh/ssdh_config.d/*.conf` snippet so it takes precedence, per `man 5 sshd_config`, no matter how the postinst changes the `$new_config`.
Bug#942100: openssh-server: /etc/ssh/sshd_config unconditionally overwritten by update
This hit me this weekend, courtesy of the Debian 12.1 to 12.2 point upgrade.
That upgraded openssh-server from 1:9.2p1-2 to 1:9.2p1-2+deb12u1.
I had made some changes to /etc/ssh/sshd_config in March 2018 (Debian 9.4), one
of which moved the default port to . This was to make port 22 available
for use by a Docker-based GitLab instance.
I have been following point upgrades since then through 9.13, jumped to 10.6,
point upgrades through 10.11, jumped to 11.2, point upgrades through 11.7. All
without making any manual changes to sshd_config.
I integrated upstream sshd_config changes when I manually upgraded the host to
Debian 12.1 (from 11.7) in August 2023. At that time I did not move my
customizations to use the new /etc/ssh/sshd_config.d/* support.
The point upgrade was performed by unattended-upgrades on 2023-10-08 and the
machine was automatically rebooted on 2023-10-09. The SSH daemon was started
first, preventing the GitLab instance from starting. Seeing that, I tried to
login remotely via port and got a connection refused. Yikes!
Fortunately, the logcheck reports in my mailbox pointed out the GitLab could
not bind to port 22, giving me a clue that I could probably SSH in on that
port. Fortunately that worked and I was able to get things back to working
order via that remote login.
I have not been able to find any notice of this in the Debian 12 release notes
or the /usr/share/doc/openssh-server/{NEWS,README}.Debian.gz files and was
therefore very unpleasantly surprised by this behavior.
FWIW, my /var/cache/debconf/config.dat contains
Name: openssh-server/password-authentication
Template: openssh-server/password-authentication
Value: false
Owners: openssh-server
Name: openssh-server/permit-root-login
Template: openssh-server/permit-root-login
Value: true
Owners: openssh-server
but I manually edited sshd_config to use
PermitRootLogin no
as well as
Port 22
Cross-checking with /var/cache/debconf/templates.dat, it appears I used
dpkg-reconfigure to change password-authentication to end up with
PasswordAuthentication no
in my sshd_config.
The openssh-server.postinst appears to be responsible for "clobbering" my
customizations (via ucf) but I don't see any differences to that file between
the old and new versions, making me wonder why this hasn't hit me before.
I'll be syncing the openssh-server debconf answers with what I have in my
sshd_config and move out any other customizations to /etc/ssh/sshd_config.d/*
snippets but thought this might be of use to others.
Bug#1050341: Error #1050341 present in version 1:4.0.4+dfsg-1+deb10u2 too
Hello Dmitry, this error seems to be present in security update 1:4.0.4+dfsg-1+deb10u2 too. After installation of this security fix version the error reappears. Best Regards Olaf Ohlenmacher -- Olaf Ohlenmacher Team B3 - rlpNetz-Dienste LANDESBETRIEB DATEN UND INFORMATION Valenciaplatz 6 55118 Mainz Germany Telefon +49 (6131) 605–282 Telefax +49 (6131) 605–144 http://www.ldi.rlp.de
Bug#1050341: zabbix-frontend-php: Graphs can not be created or updated
Package: zabbix-frontend-php
Version: 1:4.0.4+dfsg-1+deb10u1
Severity: normal
Tags: patch upstream
Hello,
when creating or updating a graph an error is displayed and the configured
items for this graph are vanished (list of items is emty).
I opened an graph "some name for graph" with two items configured and just
clicked the "Update" button without any changes, then the following error
message is displayed and the list of configured item is displayed as empty:
== error message ==
Cannot update graph
- json_decode() expects parameter 1 to be string, array given [graphs.php:94 ->
json_decode() in graphs.php:94]
- array_key_exists() exspects parameter 2 to be array, null given
[graphs.php:96 -> array_key_exists() in graphs.php:96]
- json_decode() expects parameter 1 to be string, array given [graphs.php:94 ->
json_decode() in graphs.php:94]
- array_key_exists() exspects parameter 2 to be array, null given
[graphs.php:96 -> array_key_exists() in graphs.php:96]
- Missing items for graphs "some name for graph".
== error message ==
I worked around this error with patching the file /usr/share/zabbix/graphs.php:
== patch to workaround ==
# diff -u /usr/share/zabbix/graphs.php_1:4.0.4+dfsg-1+deb10u1
/usr/share/zabbix/graphs.php
--- /usr/share/zabbix/graphs.php_1:4.0.4+dfsg-1+deb10u1 2023-04-11
20:50:56.0 +0200
+++ /usr/share/zabbix/graphs.php2023-08-22 10:22:54.162756296 +0200
@@ -91,7 +91,7 @@
$gitems = [];
foreach (getRequest('items', []) as $item) {
- $gitem = json_decode($item, true);
+ $gitem = json_decode(json_encode($item), true);
if ((array_key_exists('itemid', $gitem) &&
ctype_digit($gitem['itemid']))
&& (array_key_exists('type', $gitem) &&
ctype_digit($gitem['type']))
== patch to workaround ==
This may not the correct solution, but worked for this error.
BTW: I tried to create a new graph, but run into the identical error. Above
patch worked too for creating new graphs.
Best Regards,
Olaf Ohlenmacher
-- System Information:
Debian Release: 10.13
APT prefers oldoldstable-updates
APT policy: (500, 'oldoldstable-updates'), (500,
'oldoldstable-proposed-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-25-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages zabbix-frontend-php depends on:
ii fonts-dejavu-core 2.37-1
ii php 2:7.3+69
ii php-bcmath 2:7.3+69
ii php-gd 2:7.3+69
ii php-mbstring2:7.3+69
ii php-pgsql 2:7.3+69
ii php-xml 2:7.3+69
ii php7.0 [php]7.0.33-0+deb9u12
ii php7.0-bcmath [php-bcmath] 7.0.33-0+deb9u12
ii php7.0-gd [php-gd] 7.0.33-0+deb9u12
ii php7.0-mbstring [php-mbstring] 7.0.33-0+deb9u12
ii php7.0-pgsql [php-pgsql]7.0.33-0+deb9u12
ii php7.0-xml [php-xml]7.0.33-0+deb9u12
ii php7.3 [php]7.3.31-1~deb10u4
ii php7.3-bcmath [php-bcmath] 7.3.31-1~deb10u4
ii php7.3-gd [php-gd] 7.3.31-1~deb10u4
ii php7.3-mbstring [php-mbstring] 7.3.31-1~deb10u4
ii php7.3-pgsql [php-pgsql]7.3.31-1~deb10u4
ii php7.3-xml [php-xml]7.3.31-1~deb10u4
ii ucf 3.0038+nmu1
Versions of packages zabbix-frontend-php recommends:
ii apache2 [httpd] 2.4.38-3+deb10u10
ii libapache2-mod-php7.0 [libapache2-mod-php] 7.0.33-0+deb9u12
ii libapache2-mod-php7.3 [libapache2-mod-php] 7.3.31-1~deb10u4
ii php-ldap2:7.3+69
ii php7.0-ldap [php-ldap] 7.0.33-0+deb9u12
ii php7.3-ldap [php-ldap] 7.3.31-1~deb10u4
zabbix-frontend-php suggests no packages.
-- Configuration Files:
/etc/zabbix/apache.conf changed:
Alias /zabbix /usr/share/zabbix
Options FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
php_value max_execution_time 300
php_value memory_limit 128M
php_value post_max_size 16M
php_value upload_max_filesize 2M
php_value max_input_time 300
php_value always_populate_raw_post_data -1
php_value date.timezone Europe/Berlin
# php_value date.timezone Europe/Riga
php_value max_execution_time 300
php_value memory_limit 128M
php_value post_max_size 16M
php_value upload_max_filesize 2M
php_value max_input_time 300
php_value always_populate_raw_post_data -1
php_value date.timezone Europe/Berl
Bug#1050323: Handy-WARNING: Using … prefer-dark-theme together with HdyStyleManager is unsupported.
Package: file-roller Version: 43.0-1 Severity: normal Dear Maintainer, #+begin_quote (file-roller:11878): Handy-WARNING **: 09:22:58.309: Using GtkSettings:gtk-application-prefer-dark-theme together with HdyStyleManager is unsupported. Please use HdyStyleManager:color-scheme instead. #+end_quote #+begin_quote A warning is the prediction of a possible coming harm, but which could still be prevented or mitigated. It draws attention to an imminent danger. (https://de.wikipedia.org/wiki/Warnung) #+end_quote -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-security'), (500, 'stable'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages file-roller depends on: ii 7zip [p7zip-full]23.01+dfsg-6 ii bzip21.0.8-5+b1 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii libarchive13 3.6.2-1 ii libc62.37-7 ii libcairo21.16.0-7 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.77.2-1 ii libgtk-3-0 3.24.38-2 ii libhandy-1-0 1.8.2-2 ii libjson-glib-1.0-0 1.6.6-1 ii libnautilus-extension4 44.2.1-2 ii libpango-1.0-0 1.50.14+ds-1 Versions of packages file-roller recommends: pn gvfs ii yelp 42.2-1 Versions of packages file-roller suggests: pn arj pn lha pn lzip ii lzop 1.04-2 pn ncompress ii rpm2cpio 4.18.0+dfsg-1+b1 pn rzip ii sharutils1:4.15.2-9 pn squashfs-tools pn unace pn unalz ii unar 1.10.7+ds1+really1.10.1-2+b3 ii unzip6.0-28 ii xz-utils [lzma] 5.4.1-0.2 ii zip 3.0-13 pn zoo -- debconf-show failed
Bug#1037925: deprication warnings
Hello,
the reported deprecation warnings are enabled by the application
bootstrap and overrides the php.ini defaults.
The attached patch solves this problem.
cheers
Olaf--- /usr/share/php/Icinga/Application/ApplicationBootstrap.php.orig 2023-01-26 12:54:15.0 +0100
+++ /usr/share/php/Icinga/Application/ApplicationBootstrap.php 2023-08-09 19:03:20.750101741 +0200
@@ -591,7 +591,7 @@
*/
protected function setupErrorHandling()
{
-error_reporting(E_ALL | E_STRICT);
+error_reporting(E_ALL & ~E_DEPRECATED | E_STRICT);
ini_set('display_startup_errors', 1);
ini_set('display_errors', 1);
set_error_handler(function ($errno, $errstr, $errfile, $errline) {
Bug#1042753: nouveau bug in linux/6.1.38-2
On Sat, 5 Aug 2023 at 01:09, Karol Herbst wrote: Mind checking if instead of reverting the entire commit that this is enough to fix it as well? https://gitlab.freedesktop.org/karolherbst/nouveau/-/commit/f99ae069876f7ffeb6368da0381485e8c3adda43.patch This patch does fix the problem as well: Screen works. Cheers, Olaf
Bug#1042753: nouveau bug in linux/6.1.38-2
Dear all, On Fri, 4 Aug 2023 at 14:15, Karol Herbst wrote: 62aecf23f3d1 drm/nouveau: add nv_encoder pointer check for NULL fb725beca62d drm/nouveau/dp: check for NULL nv_connector->native_mode 90748be0f4f3 drm/nouveau: don't detect DSM for non-NVIDIA device 5a144bad3e75 nouveau: fix client work fence deletion race mind retrying with only fb725beca62d and 62aecf23f3d1 reverted? Would be weird if the other two commits are causing it. If that's the case, it's a bit worrying that reverting either of the those causes issues, but maybe there is a good reason for it. Anyway, mind figuring out which of the two you need reverted to fix your issue? Thanks! The result is: Patch with commit fb725beca62d reverted: Graphics works. I attached the respective patch again to this mail. Patch with commit 62aecf23f3d1 reverted: Screen remains black, error message: # dmesg | grep -A 36 "cut here" [2.921358] [ cut here ] [2.921361] WARNING: CPU: 1 PID: 176 at drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c:460 nvkm_dp_acquire+0x26a/0x490 [nouveau] [2.921627] Modules linked in: sd_mod(E) t10_pi(E) crc64_rocksoft(E) sr_mod(E) crc64(E) crc_t10dif(E) crct10dif_generic(E) cdrom(E) nouveau(E+) mxm_wmi(E) i2c_algo_bit(E) drm_display_helper(E) cec(E) ahci(E) rc_core(E) drm_ttm_helper(E) libahci(E) ttm(E) ehci_pci(E) crct10dif_pclmul(E) crct10dif_common(E) ehci_hcd(E) drm_kms_helper(E) crc32_pclmul(E) firewire_ohci(E) sdhci_pci(E) cqhci(E) libata(E) e1000e(E) sdhci(E) psmouse(E) crc32c_intel(E) lpc_ich(E) ptp(E) i2c_i801(E) scsi_mod(E) i2c_smbus(E) firewire_core(E) scsi_common(E) usbcore(E) crc_itu_t(E) mmc_core(E) drm(E) pps_core(E) usb_common(E) battery(E) video(E) wmi(E) button(E) [2.921695] CPU: 1 PID: 176 Comm: kworker/u16:5 Tainted: GE 6.1.0-0.a.test-amd64 #1 Debian 6.1.38-2a~test [2.921701] Hardware name: Dell Inc. Latitude E6510/0N5KHN, BIOS A17 05/12/2017 [2.921705] Workqueue: nvkm-disp nv50_disp_super [nouveau] [2.921948] RIP: 0010:nvkm_dp_acquire+0x26a/0x490 [nouveau] [2.922192] Code: 48 8b 44 24 58 65 48 2b 04 25 28 00 00 00 0f 85 37 02 00 00 48 83 c4 60 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b c1 e8 03 41 88 6d 62 44 89 fe 48 89 df 48 69 c0 cf 0d d6 26 [2.922196] RSP: 0018:c077c04dfd60 EFLAGS: 00010246 [2.922201] RAX: 00041eb0 RBX: 9a8482624c00 RCX: 00041eb0 [2.922204] RDX: c0b47760 RSI: RDI: c077c04dfcf0 [2.922206] RBP: 0001 R08: c077c04dfc64 R09: 5b76 [2.922209] R10: 000d R11: c077c04dfde0 R12: ffea [2.922212] R13: 9a8517541e00 R14: 00044d45 R15: [2.922215] FS: () GS:9a85a3c4() knlGS: [2.922219] CS: 0010 DS: ES: CR0: 80050033 [2.92] CR2: 55f660bcb3a8 CR3: 00019761 CR4: 06e0 [2.96] Call Trace: [2.922231] [2.922235] ? __warn+0x7d/0xc0 [2.922244] ? nvkm_dp_acquire+0x26a/0x490 [nouveau] [2.922487] ? report_bug+0xe6/0x170 [2.922494] ? handle_bug+0x41/0x70 [2.922501] ? exc_invalid_op+0x13/0x60 [2.922505] ? asm_exc_invalid_op+0x16/0x20 [2.922512] ? init_reset_begun+0x20/0x20 [nouveau] [2.922708] ? nvkm_dp_acquire+0x26a/0x490 [nouveau] [2.922954] nv50_disp_super_2_2+0x70/0x430 [nouveau] [2.923200] nv50_disp_super+0x113/0x210 [nouveau] [2.923445] process_one_work+0x1c7/0x380 [2.923456] worker_thread+0x4d/0x380 [2.923463] ? rescuer_thread+0x3a0/0x3a0 [2.923469] kthread+0xe9/0x110 [2.923476] ? kthread_complete_and_exit+0x20/0x20 [2.923482] ret_from_fork+0x22/0x30 [2.923493] [2.923494] ---[ end trace ]--- (Maybe it's worth to mention that the LED back-light is on, while the screen appears black.) Cheers, Olaf P.S.: By the way: as a linux user for more than 20 years, I am very pleased to have the opportunity to contribute at least a little bit to the improvement. I'd like to use the chance to thank you all very much for building and developing this great operating system.From 47c0e938beef7335ffa179f1006754f9664c6c4d Mon Sep 17 00:00:00 2001 From: Diederik de Haas Date: Mon, 31 Jul 2023 19:55:54 +0200 Subject: [PATCH 2/4] Revert "drm/nouveau/dp: check for NULL nv_connector->native_mode" This reverts commit fb725beca62d175c02ca619c27037c14f7ab8e7c. --- drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index fd984733b8e6..1991bbb1d05c 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -966,7 +966,7 @@ nouveau_connector_get_modes(struct drm_conn
Bug#1042753: nouveau bug in linux/6.1.38-2
On Fri, 4 Aug 2023 at 14:51, Karol Herbst wrote: How are you building the kernel? Because normally from git reverting one of those shouldn't take long, because it doesn't recompile the entire kernel. But yeah, you can potentially just revert one of one for now and it should be fine. I am using the `test-patches` script described here: https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4 This worked for my limited knowledge (first kernel I ever compiled). (On the occasion a maybe silly question: am I right assuming that the kernel has to be build on the machine we want to reproduce the bug on? Otherwise it could use much faster hardware (running also bookworm).) Cheers, Olaf
Bug#1042753: nouveau bug in linux/6.1.38-2
On Fri, 4 Aug 2023 at 14:15, Karol Herbst wrote: mind retrying with only fb725beca62d and 62aecf23f3d1 reverted? I will do this later this day (takes some time, it is a slow machine). Would be weird if the other two commits are causing it. If that's the case, it's a bit worrying that reverting either of the those causes issues, but maybe there is a good reason for it. Anyway, mind figuring out which of the two you need reverted to fix your issue? Thanks! I can do this. But if I build two kernels anyway, isn't it faster to build each with only one of the patches applied? Or do you expect the patches to interact (so that the bug would only be present when both are applied)? Cheers, Olaf
Bug#1042753: nouveau bug in linux/6.1.38-2
Dear Maintainers,
Hereby I would like to report an apparent bug in the nouveau driver in
linux/6.1.38-2.
Running a current debian stable on a Dell Latitude E6510 with a
"NVIDIA Corporation GT218M" graphic card, the monitor turns black
after the grub screen. Also switching to a console (Strg-Alt-F2) shows
just a black screen. Access via ssh is possible.
~# uname -r
6.1.0-10-amd64
demesg shows the following error message:
[3.560153] WARNING: CPU: 0 PID: 176 at
drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c:460 nvkm_dp_acquire+0x26a/0x490
[nouveau]
[3.560287] Modules linked in: sd_mod t10_pi sr_mod crc64_rocksoft cdrom
crc64 crc_t10dif crct10dif_generic nouveau(+) ahci libahci mxm_wmi i2c_algo_bit
drm_display_helper libata cec rc_core drm_ttm_helper ttm scsi_mod e1000e
drm_kms_helper ptp firewire_ohci sdhci_pci cqhci ehci_pci sdhci ehci_hcd
firewire_core i2c_i801 crct10dif_pclmul crct10dif_common drm crc32_pclmul
crc32c_intel psmouse usbcore mmc_core crc_itu_t pps_core scsi_common i2c_smbus
lpc_ich usb_common battery video wmi button
[3.560322] CPU: 0 PID: 176 Comm: kworker/u16:5 Not tainted 6.1.0-10-amd64
#1 Debian 6.1.38-2
[3.560325] Hardware name: Dell Inc. Latitude E6510/0N5KHN, BIOS A17
05/12/2017
[3.560327] Workqueue: nvkm-disp nv50_disp_super [nouveau]
[3.560433] RIP: 0010:nvkm_dp_acquire+0x26a/0x490 [nouveau]
[3.560538] Code: 48 8b 44 24 58 65 48 2b 04 25 28 00 00 00 0f 85 37 02 00 00 48
83 c4 60 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b c1 e8 03
41 88 6d 62 44 89 fe 48 89 df 48 69 c0 cf 0d d6 26
[3.560541] RSP: 0018:9899c048bd60 EFLAGS: 00010246
[3.560542] RAX: 00041eb0 RBX: 88e0209d2600 RCX: 00041eb0
[3.560544] RDX: c079f760 RSI: RDI: 9899c048bcf0
[3.560545] RBP: 0001 R08: 9899c048bc64 R09: 5b76
[3.560546] R10: 000d R11: 9899c048bde0 R12: ffea
[3.560548] R13: 88e00b39e480 R14: 00044d45 R15:
[3.560549] FS: () GS:88e123c0()
knlGS:
[3.560551] CS: 0010 DS: ES: CR0: 80050033
[3.560552] CR2: 7f57f4e90451 CR3: 00018141 CR4: 06f0
[3.560554] Call Trace:
[3.560558]
[3.560560] ? __warn+0x7d/0xc0
[3.560566] ? nvkm_dp_acquire+0x26a/0x490 [nouveau]
[3.560671] ? report_bug+0xe6/0x170
[3.560675] ? handle_bug+0x41/0x70
[3.560679] ? exc_invalid_op+0x13/0x60
[3.560681] ? asm_exc_invalid_op+0x16/0x20
[3.560685] ? init_reset_begun+0x20/0x20 [nouveau]
[3.560769] ? nvkm_dp_acquire+0x26a/0x490 [nouveau]
[3.560888] nv50_disp_super_2_2+0x70/0x430 [nouveau]
[3.560997] nv50_disp_super+0x113/0x210 [nouveau]
[3.561103] process_one_work+0x1c7/0x380
[3.561109] worker_thread+0x4d/0x380
[3.561113] ? rescuer_thread+0x3a0/0x3a0
[3.561116] kthread+0xe9/0x110
[3.561120] ? kthread_complete_and_exit+0x20/0x20
[3.561122] ret_from_fork+0x22/0x30
[3.561130]
Further information:
$ lspci -v -s $(lspci | grep -i vga | awk '{ print $1 }')
01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [NVS 3100M] (rev
a2) (prog-if 00 [VGA controller])
Subsystem: Dell Latitude E6510
Flags: bus master, fast devsel, latency 0, IRQ 27
Memory at e200 (32-bit, non-prefetchable) [size=16M]
Memory at d000 (64-bit, prefetchable) [size=256M]
Memory at e000 (64-bit, prefetchable) [size=32M]
I/O ports at 7000 [size=128]
Expansion ROM at 000c [disabled] [size=128K]
Capabilities:
Kernel driver in use: nouveau
Kernel modules: nouveau
I reported this bug to debian already, see
https://bugs.debian.org/1042753 for context.
With support (thanks Diederik!) I managed to figure out that the cause
was a regression between upstream kernel version 6.1.27 and 6.1.38.
I build a new 6.1.38 kernel with these commits reverted:
62aecf23f3d1 drm/nouveau: add nv_encoder pointer check for NULL
fb725beca62d drm/nouveau/dp: check for NULL nv_connector->native_mode
90748be0f4f3 drm/nouveau: don't detect DSM for non-NVIDIA device
5a144bad3e75 nouveau: fix client work fence deletion race
With that kernel the graphic works again.
Please inform me if further tests are required.
Cheers,
Olaf
Bug#1042753: nouveau: Screen remains black.
On Wed, 2 Aug 2023 at 01:09, Diederik de Haas wrote: On Wednesday, 2 August 2023 00:23:16 CEST Olaf Skibbe wrote: But now I am a little clueless: how do I install this kernel? Any hint? It should have produced one or more .deb files and you can install a .deb file like this: `apt install ./.deb` If you share the output of `ls -lh *.deb` (and/or `ls -lh ../*.deb`) then I can probably give you more precise instructions. Sorry, my fault. I searched for .deb files in the subdirectory when I thought I searched the home directory. I am familiar with installing a .deb file. So we have: ~/Patches$ l *.deb -rw-r--r-- 1 olaf olaf 647K 2. Aug 00:02 linux-compiler-gcc-12-x86_6.1.38-2a~test_amd64.deb -rw-r--r-- 1 olaf olaf 1,2M 1. Aug 23:59 linux-headers-6.1.0-0.a.test-amd64_6.1.38-2a~test_amd64.deb -rw-r--r-- 1 olaf olaf 9,4M 1. Aug 21:34 linux-headers-6.1.0-0.a.test-common_6.1.38-2a~test_all.deb -rw-r--r-- 1 olaf olaf 7,8M 1. Aug 21:34 linux-headers-6.1.0-0.a.test-common-rt_6.1.38-2a~test_all.deb -rw-r--r-- 1 olaf olaf 56M 2. Aug 00:01 linux-image-6.1.0-0.a.test-amd64-unsigned_6.1.38-2a~test_amd64.deb -rw-r--r-- 1 olaf olaf 1,2M 2. Aug 00:02 linux-image-amd64-signed-template_6.1.38-2a~test_amd64.deb -rw-r--r-- 1 olaf olaf 898K 2. Aug 00:01 linux-kbuild-6.1_6.1.38-2a~test_amd64.deb -rw-r--r-- 1 olaf olaf 1001K 2. Aug 00:01 linux-kbuild-6.1-dbgsym_6.1.38-2a~test_amd64.deb -rw-r--r-- 1 olaf olaf 1,8M 2. Aug 00:02 linux-libc-dev_6.1.38-2a~test_amd64.deb -rw-r--r-- 1 olaf olaf 694K 1. Aug 21:34 linux-support-6.1.0-0.a.test_6.1.38-2a~test_all.deb I gave it a shot and ran # apt install /home/olaf/Patches/*.deb Result: # aptitude search linux-image | grep ^i i linux-image-6.1.0-0.a.test-amd64-unsigned - Linux 6.1 for 64-bit PCs i A linux-image-6.1.0-10-amd64 - Linux 6.1 for 64-bit PCs (signed) i linux-image-6.1.0-9-amd64 - Linux 6.1 for 64-bit PCs (signed) i linux-image-amd64 - Linux für 64-Bit-PCs (Metapaket) i linux-image-amd64-signed-template - Template for signed linux-image packages for amd64 Booted in the new kernel. # uname -r 6.1.0-0.a.test-amd64 Graphics works now. I guess I am supposed to build some more kernels with subsets of patches? Any hint where to start? Cheers, Olaf
Bug#1042753: nouveau: Screen remains black.
Finally I managed to compile the kernel via debian/bin/test-patches ../0001-Revert-drm-nouveau-add-nv_encoder-pointer-check-for-.patch ../0002-Revert-drm-nouveau-dp-check-for-NULL-nv_connector-na.patch ../0003-Revert-drm-nouveau-don-t-detect-DSM-for-non-NVIDIA-d.patch ../0004-Revert-nouveau-fix-client-work-fence-deletion-race.patch (apparently successfully, but it took several hours). But now I am a little clueless: how do I install this kernel? Any hint? Cheers, Olaf On Mon, 31 Jul 2023 at 22:42, Diederik de Haas wrote: On Monday, 31 July 2023 21:52:44 CEST Olaf Skibbe wrote: Yep, now we know it's a regression between 6.1.27-1 and 6.1.38-2. https://wiki.debian.org/DebianKernel/GitBisect describes the best way as it would identify the exact (upstream) commit which introduced the problem. If you can do that, great. I'd love to contribute here, but I am afraid this would be a bit beyond my capabilities. I now have only remote access to the computer in question (I have to ask somebody to verify whether the display is working) and I am not very experienced. Sorry. That's ok, I (kind of) expected that a `git bisect` would be too difficult. That's why I also described a simpler procedure which is specifically meant for people who aren't experienced. It will result in a new kernel being build, but all the complexity should be hidden for you. It probably sounds daunting/scary, but it shouldn't be. There is a subsequent step, but that is (far) more likely to succeed if we'd have more detailed data which the above procedure would provide. So it would be great if you could try it. If it turns out to be too difficult, don't worry about it :-) Cheers, Diederik
Bug#1042753: nouveau: Screen remains black.
On Mon, 31 Jul 2023 at 20:28, Diederik de Haas wrote: On Monday, 31 July 2023 18:20:12 CEST Olaf Skibbe wrote: I installed 6.1.0-9-amd64 now from the standard repositories and graphics works. Hope this is sufficient to narrow it down Yep, now we know it's a regression between 6.1.27-1 and 6.1.38-2. https://wiki.debian.org/DebianKernel/GitBisect describes the best way as it would identify the exact (upstream) commit which introduced the problem. If you can do that, great. I'd love to contribute here, but I am afraid this would be a bit beyond my capabilities. I now have only remote access to the computer in question (I have to ask somebody to verify whether the display is working) and I am not very experienced. Sorry. Cheers, Olaf
Bug#1042753: nouveau: Screen remains black.
On Mon, 31 Jul 2023 at 13:09, Diederik de Haas wrote: On Monday, 31 July 2023 12:44:07 CEST Olaf Skibbe wrote: After upgrading to bookworm on a Dell Latitude E6510 with a "NVIDIA Corporation GT218M" graphic card, the screen remains black. Also switching to a console (Strg-Alt-F2) shows a black screen. Access via ssh is possible. When booting to the old kernel, the screen works as before. The old kernel is 5.10.X? Yes, the kernel referred to as "old" is 5.10.x. On https://snapshot.debian.org/binary/linux-image-amd64/ you can find a whole bunch of older 6.1 kernels. Can you try to see if one of them does work? If there is a 6.1 kernel that does work, then it helps if you can find the latest 6.1 kernel which works and (thus) the first kernel version where it stopped working. I installed 6.1.0-9-amd64 now from the standard repositories and graphics works. Hope this is sufficient to narrow it down, otherwise I'd test more kernels. (Would there be a simple way to add the snapshots to the repositories?) Thanks for taking care. Cheers, Olaf
Bug#1042753: nouveau: Screen remains black.
Package: src:linux Version: 6.1.38-2 Severity: important File: nouveau X-Debbugs-Cc: n...@kravcenko.com Dear Maintainer, After upgrading to bookworm on a Dell Latitude E6510 with a "NVIDIA Corporation GT218M" graphic card, the screen remains black. Also switching to a console (Strg-Alt-F2) shows a black screen. Access via ssh is possible. When booting to the old kernel, the screen works as before. ~# uname -r 6.1.0-10-amd64 >From dmesg: ~# dmesg | grep -A 36 "cut here" [3.560151] [ cut here ] [3.560153] WARNING: CPU: 0 PID: 176 at drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c:460 nvkm_dp_acquire+0x26a/0x490 [nouveau] [3.560287] Modules linked in: sd_mod t10_pi sr_mod crc64_rocksoft cdrom crc64 crc_t10dif crct10dif_generic nouveau(+) ahci libahci mxm_wmi i2c_algo_bit drm_display_helper libata cec rc_core drm_ttm_helper ttm scsi_mod e1000e drm_kms_helper ptp firewire_ohci sdhci_pci cqhci ehci_pci sdhci ehci_hcd firewire_core i2c_i801 crct10dif_pclmul crct10dif_common drm crc32_pclmul crc32c_intel psmouse usbcore mmc_core crc_itu_t pps_core scsi_common i2c_smbus lpc_ich usb_common battery video wmi button [3.560322] CPU: 0 PID: 176 Comm: kworker/u16:5 Not tainted 6.1.0-10-amd64 #1 Debian 6.1.38-2 [3.560325] Hardware name: Dell Inc. Latitude E6510/0N5KHN, BIOS A17 05/12/2017 [3.560327] Workqueue: nvkm-disp nv50_disp_super [nouveau] [3.560433] RIP: 0010:nvkm_dp_acquire+0x26a/0x490 [nouveau] [3.560538] Code: 48 8b 44 24 58 65 48 2b 04 25 28 00 00 00 0f 85 37 02 00 00 48 83 c4 60 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b c1 e8 03 41 88 6d 62 44 89 fe 48 89 df 48 69 c0 cf 0d d6 26 [3.560541] RSP: 0018:9899c048bd60 EFLAGS: 00010246 [3.560542] RAX: 00041eb0 RBX: 88e0209d2600 RCX: 00041eb0 [3.560544] RDX: c079f760 RSI: RDI: 9899c048bcf0 [3.560545] RBP: 0001 R08: 9899c048bc64 R09: 5b76 [3.560546] R10: 000d R11: 9899c048bde0 R12: ffea [3.560548] R13: 88e00b39e480 R14: 00044d45 R15: [3.560549] FS: () GS:88e123c0() knlGS: [3.560551] CS: 0010 DS: ES: CR0: 80050033 [3.560552] CR2: 7f57f4e90451 CR3: 00018141 CR4: 06f0 [3.560554] Call Trace: [3.560558] [3.560560] ? __warn+0x7d/0xc0 [3.560566] ? nvkm_dp_acquire+0x26a/0x490 [nouveau] [3.560671] ? report_bug+0xe6/0x170 [3.560675] ? handle_bug+0x41/0x70 [3.560679] ? exc_invalid_op+0x13/0x60 [3.560681] ? asm_exc_invalid_op+0x16/0x20 [3.560685] ? init_reset_begun+0x20/0x20 [nouveau] [3.560769] ? nvkm_dp_acquire+0x26a/0x490 [nouveau] [3.560888] nv50_disp_super_2_2+0x70/0x430 [nouveau] [3.560997] nv50_disp_super+0x113/0x210 [nouveau] [3.561103] process_one_work+0x1c7/0x380 [3.561109] worker_thread+0x4d/0x380 [3.561113] ? rescuer_thread+0x3a0/0x3a0 [3.561116] kthread+0xe9/0x110 [3.561120] ? kthread_complete_and_exit+0x20/0x20 [3.561122] ret_from_fork+0x22/0x30 [3.561130] [3.561131] ---[ end trace 0000 ]--- Cheers, Olaf -- Package-specific info: ** Version: Linux version 6.1.0-10-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2 (2023-07-27) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-10-amd64 root=UUID=2024bc00-f8a8-4d97-a79d-f7840ae196e5 ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Dell Inc. product_name: Latitude E6510 product_version: 0001 chassis_vendor: Dell Inc. chassis_version: bios_vendor: Dell Inc. bios_version: A17 board_vendor: Dell Inc. board_name: 0N5KHN board_version: A02 ** Loaded modules: ctr ccm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device bnep btusb btrtl btbcm btintel btmtk bluetooth jitterentropy_rng drbg ansi_cprng ecdh_generic ecc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc qrtr intel_powerclamp coretemp kvm_intel kvm irqbypass ghash_clmulni_intel sha512_ssse3 sha512_generic binfmt_misc iwldvm snd_hda_codec_idt mac80211 snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel libarc4 dell_rbtn aesni_intel crypto_simd snd_intel_dspcfg cryptd snd_intel_sdw_acpi dell_laptop pcmcia ledtrig_audio snd_hda_codec iwlwifi dell_wmi snd_hda_core dell_smm_hwmon snd_hwdep sparse_keymap intel_cstate intel_uncore cfg80211 snd_pcm yenta_socket iTCO_wdt dell_smbios dcdbas intel_pmc_bxt wmi_bmof dell_wmi_descriptor at24 snd_timer pcmcia_rsrc iTCO_vendor_support pcspkr rfkill pcmcia_core watchdog snd soundcore dell_smo8800 ac acpi_cpufreq joydev evdev serio_raw sg firewire_sbp2 parport_pc ppdev lp p
Bug#1041040: [Aspectc-developers] Fwd: Bug#1041040: aspectc++ autopkg tests fail with GCC 13
Hi! Okay, another try: olaf@x1:/store/olaf/workspace2/AspectC++$ svn commit -m "A third try to fix the problems on systems with g++ 13. Now the types _Float are defined as destinct type s so that template specialization should work without conflicts. Furthermore, all types are now defined on all platforms, regardless of the availability of __float12 8." Sende NamespaceAC.cc Übertrage Daten .erledigt Übertrage Transaktion... Revision 1667 übertragen. I hope that this works now. The "fix" is actually just a workaround, because the types that I have created to satisfy the clang parser are not 100% compatible with the real _Float types. So, it is possible that further improvements are needed. Cheers, Olaf On 25.07.23 16:58, Olaf Spinczyk wrote: Right. /usr/include/math.h does not include a template specialization of struct __iseqsig_type for _Float on my Ubuntu 22.04/AMD64 machine. Therefore, my local test had passed. However, my workaround, which tries to satisfy the internal clang parser with typedefs, doesn't work in combination with this template specialization. On Arm it is a different problem. I'll try some other approach and keep you informed. Cheers, Olaf On 25.07.23 12:49, Reinhard Tartler wrote: Unfortunately, it made it worse :-( Here is abuildlog for amd64: https://salsa.debian.org/debian/aspectc/-/jobs/4471659/raw I've also attached my buildlog from an ARM64 machine to this email. thanks for looking into this! On 7/24/23 10:39 AM, Olaf Spinczyk wrote: Hi! It seems that my previous commit was too simple. I hope that today's modification helps: olaf@x1:~/workspace2/AspectC++$ svn commit -m "Improved previous bugfix: Now the typedefs for _Float128 and _Float64x, which should make the clang parser happy, are only generated on platforms where clang support __float128." Sende NamespaceAC.cc Übertrage Daten .erledigt Übertrage Transaktion... Revision 1666 übertragen. Cheers, Olaf On 24.07.23 13:26, Reinhard Tartler wrote: On 7/23/23 9:13 AM, Reinhard Tartler wrote: Turns out, the fix only works on amd64/i386, but not for instance on Arm, Matthias, our GCC maintainer has filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041040 for this. I looked over the patch and couldn't find anything architecture specific. Can you make any rhyme or reason for why it might fail on arm64? Here are some more test logs: https://ci.debian.net/packages/a/aspectc++/unstable/arm64/ This issue also occurs during a regular package build, not only during autopkgtest. I could reproduce it on the amdhal.debian.org in a sid chroot and got this: Weaving aspects into PreFileIncluder.cc... Weaving aspects into PreprocessorParser.cc... Weaving aspects into UnitManager.cc... In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreFileIncluder.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/TokenStream.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h:27: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PrePrintVisitor.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreSemIterator.h:24: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTreeIterator.h:24: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTree.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h:24: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreprocessorParser.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Token.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h:25: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/UnitManager.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Unit.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/List.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src
Bug#1041040: [Aspectc-developers] Fwd: Bug#1041040: aspectc++ autopkg tests fail with GCC 13
Right. /usr/include/math.h does not include a template specialization of struct __iseqsig_type for _Float on my Ubuntu 22.04/AMD64 machine. Therefore, my local test had passed. However, my workaround, which tries to satisfy the internal clang parser with typedefs, doesn't work in combination with this template specialization. On Arm it is a different problem. I'll try some other approach and keep you informed. Cheers, Olaf On 25.07.23 12:49, Reinhard Tartler wrote: Unfortunately, it made it worse :-( Here is abuildlog for amd64: https://salsa.debian.org/debian/aspectc/-/jobs/4471659/raw I've also attached my buildlog from an ARM64 machine to this email. thanks for looking into this! On 7/24/23 10:39 AM, Olaf Spinczyk wrote: Hi! It seems that my previous commit was too simple. I hope that today's modification helps: olaf@x1:~/workspace2/AspectC++$ svn commit -m "Improved previous bugfix: Now the typedefs for _Float128 and _Float64x, which should make the clang parser happy, are only generated on platforms where clang support __float128." Sende NamespaceAC.cc Übertrage Daten .erledigt Übertrage Transaktion... Revision 1666 übertragen. Cheers, Olaf On 24.07.23 13:26, Reinhard Tartler wrote: On 7/23/23 9:13 AM, Reinhard Tartler wrote: Turns out, the fix only works on amd64/i386, but not for instance on Arm, Matthias, our GCC maintainer has filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041040 for this. I looked over the patch and couldn't find anything architecture specific. Can you make any rhyme or reason for why it might fail on arm64? Here are some more test logs: https://ci.debian.net/packages/a/aspectc++/unstable/arm64/ This issue also occurs during a regular package build, not only during autopkgtest. I could reproduce it on the amdhal.debian.org in a sid chroot and got this: Weaving aspects into PreFileIncluder.cc... Weaving aspects into PreprocessorParser.cc... Weaving aspects into UnitManager.cc... In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreFileIncluder.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/TokenStream.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h:27: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PrePrintVisitor.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreSemIterator.h:24: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTreeIterator.h:24: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTree.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h:24: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreprocessorParser.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Token.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h:25: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/UnitManager.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Unit.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/List.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/ListElement.h:27: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/ListElement.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ ___ aspectc-developers mailing list aspectc-develop...@mail.aspectc.org https://www.aspectc.org/cgi-bin/mailman/listinfo/aspectc-developers ___ aspectc-developers mailing list aspectc-develop...@mail.aspectc.org https://www.aspectc.org/cgi-bin/mailman/listinfo/aspectc-developers
Bug#1041651: bc does not speak german (2023-07-21)
Package: bc Version: 1.07.1-3+b1 Severity: normal Dear Maintainer, the translation of the program description into German suggests that bc can handle the German numeric keyboard. This is not the case, bc uses only the dot as decimal separator, no comma. The translation is therefore counterproductive and should be removed. -- System Information: Debian Release: trixie/sid APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bc depends on: ii libc6 2.36-9 ii libreadline8 8.2-1.3 bc recommends no packages. bc suggests no packages. -- debconf-show failed
Bug#1038425: runit-services: missing dependency on net-tools for ifconfig
Package: runit-services Version: 0.5.4 Severity: normal The sv/dhclient/check file uses ifconfig. This is part of the net-tools package. The package is Priority: important, so would normally be installed. However, iproute2 mentions in its package description that `ifconfig` is a legacy tool. That led me to remove net-tools. I have been doing mostly fine without net-tools but this hit me when I pulled in runit-services, unintentionally, during an upgrade. I've since uninstalled runit-services but thought I'd let you know. -- Olaf Meeuwissen
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Hi, Thanks for forwarding this, Mark. Daniel, I'm not particularly charmed by the retitling to show note about missing boot integration for non-systemd I have a few runit-init based systems with mdadm that run testing, which, thankfully, still has 4.2-5. The version in sid is old enough to migrate to testing but is still waiting on autopkgtest results before it migrates. Other than that there is nothing that prevents 4.2+20230508-2 from migrating and hit unsuspecting mdadm users *without* any message at all. These users will not be able to reboot their system after upgrading. Just image the pain of having this happen to a system in a remote location. Please consider bumping this bug to a Severity that keeps it from migrating to testing/trixie until this is resolved. # I'll be putting mdadm on hold on my systems for the time being. Thanks in advance, -- Olaf Meeuwissen
Bug#1038067: dash: fails to upgrade from -2 in debian:sid-slim image due to --path-exclude=/usr/share/man
I can confirm that it breaks one of my CI jobs. When the file you're trying to divert does not exist, there is nothing to be done, so, yes, that should be assumed as being okay. FWIW, I haven't tested the patch. -- Olaf Meeuwissen
Bug#1036773: [EXTERNAL] Bug#1036773: cloud.debian.org: During vagrant up, mounting NFS fails
+1
I my case installation of the NFS client fails (I'm behind a proxy) but the
machine
boots fine.
$ cat Vagrantfile
Vagrant.configure("2") do |config|
config.vm.box = "debian/testing64"
end
Last bit of the output from `vagrant up`
==> default: Machine booted and ready!
==> default: Installing NFS client...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
apt-get -yqq update
apt-get -yqq install nfs-common portmap
exit $?
Stdout from the command:
Stderr from the command:
W: Failed to fetch https://deb.debian.org/debian/dists/testing/InRelease
Cannot initiate the connection to debian.map.fastly.net:443
(2a04:4e42:48::644). - connect (101: Network is unreachable) Could not connect
to debian.map.fastly.net:443 (151.101.230.132), connection timed out Cannot
initiate the connection to deb.debian.org:443 (2a04:4e42:36::644). - connect
(101: Network is unreachable)
W: Some index files failed to download. They have been ignored, or old ones
used instead.
E: Package 'nfs-common' has no installation candidate
E: Unable to locate package portmap
Hope this helps,
From: Joshua Kugler
Sent: 26 May 2023 04:37
To: Debian Bug Tracking System
Subject: [EXTERNAL] Bug#1036773: cloud.debian.org: During vagrant up, mounting
NFS fails
Package: cloud.debian.org
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I tried to use the debian/testing64 vagrant box.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I ran `vagrant up`. It mostly runs, but hangs on ==> default: Mounting
NFS shared folders...
After sitting there
* What was the outcome of this action?
It mostly runs, but hangs on ==> default: Mounting NFS shared folders...
After sitting there for a while, it fails with:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
mount -o vers=4 192.168.121.1:/home/jkugler/vmware/vagrant_debian
/vagrant
Stdout from the command:
Stderr from the command:
mount.nfs: Connection refused
* What outcome did you expect instead?
I expected the machine to come up without issue.
I noticed in the default Vagrantfile that comes with the box, there is
an NFS shared folder.
That should probably be removed and allow the user to configure shared
folders as they see fit.
Bug#1036276: gthumb: gThumb deletes xattr
Package: gthumb Version: 3:3.12.2-3+b1 Severity: normal Dear Maintainer, gThumb removes already during the tagging of images all extended file attributes attached to the image, so called xattr. You can check this by writing tags with "setfattr" and reading them with "getfattr". Or you can use the file manager Dolphin or the image viewer Gwenview, which lives from extended file attributes. For security reasons, this incompatibility should be pointed out as early as possible. For example, in the package description, which describes gThumb as "advanced". -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gthumb depends on: ii gsettings-desktop-schemas 43.0-1 ii gthumb-data 3:3.12.2-3 ii libbrasero-media3-1 3.12.3-2 ii libc6 2.36-9 ii libcairo2 1.16.0-7 ii libchamplain-0.12-0 0.12.20-1+b1 ii libchamplain-gtk-0.12-0 0.12.20-1+b1 ii libclutter-1.0-01.26.4+dfsg-4 ii libclutter-gtk-1.0-01.8.4-4+b1 ii libcolord2 1.4.6-2.2 ii libexiv2-27 0.27.6-1 ii libgcc-s1 12.2.0-14 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgl1-mesa-dri 23.1.0~rc2-1 ii libglib2.0-02.74.6-2 ii libgstreamer-plugins-base1.0-0 1.22.2-dmo1 ii libgstreamer1.0-0 1.22.0-2 ii libgtk-3-0 3.24.37-2 ii libheif11.15.1-1 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-2 2.14-2 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpng16-16 1.6.39-2 ii libraw200.20.2-2+b1 ii librsvg2-2 2.54.5+dfsg-1 ii libsecret-1-0 0.20.5-3 ii libsoup2.4-12.74.3-1 ii libstdc++6 12.2.0-14 ii libtiff64.5.0-5 ii libwebkit2gtk-4.0-372.40.1-1 ii libwebp71.2.4-0.1 ii libx11-62:1.8.4-2 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages gthumb recommends: ii libgphoto2-6 2.5.30-1 ii libgphoto2-port12 2.5.30-1 gthumb suggests no packages. -- debconf-show failed
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Hi, I just upgraded linux-image-amd64 and that pulled in 6.1.0-9 and now intel/ibt-20-1-3.sfi loads without issues and my Bluetooth keyboard works, even when cold booting! Cold booting 6.1.0-7 it fails and my keyboard is unresponsive. For reference, # grep -E '(version 6\.1\.0-|ibt-20-1-3\.sfi)' /var/log/kern.log | sed 's/.* kernel: //' [0.00] Linux version 6.1.0-7-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-2 (2023-04-08) [1.590712] bluetooth hci0: firmware: failed to load intel/ibt-20-1-3.sfi (-2) [1.590724] bluetooth hci0: firmware: failed to load intel/ibt-20-1-3.sfi (-2) [1.590726] Bluetooth: hci0: Failed to load Intel firmware file intel/ibt-20-1-3.sfi (-2) [0.00] Linux version 6.1.0-9-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) [3.635292] bluetooth hci0: firmware: direct-loading firmware intel/ibt-20-1-3.sfi [3.635294] Bluetooth: hci0: Found device firmware: intel/ibt-20-1-3.sfi I don't know if it is related but when I boot 6.1.0-7, I also see a call trace that starts with [1.554110] alg: self-tests for ecdh-nist-p256 using ecdh-nist-p256-generic failed (rc=-14) [1.554111] [ cut here ] This happens before 6.1.0-7 tries to load intel/ibt-20-1-3.sfi. With 6.1.0-9, that call trace is gone too and loading the firmware file appears to have been moved to a later phase based upon the time stamps. I don't know what fixed it but I'm happy to report this fixed. At least in 6.1.0-9, but I'm slightly worried a later version might reintroduce it as that has happened before. Oh, FYI, I have the following firmware packages installed at the moment # apt list --installed 2>/dev/null | grep firmware firmware-amd-graphics/testing,now 20230210-5 all [installed] firmware-iwlwifi/testing,now 20230210-5 all [installed] firmware-linux-free/unstable,unstable,testing,now 20200122-1 all [installed,automatic] firmware-realtek/testing,now 20230210-5 all [installed] Hope this helps, -- Olaf Meeuwissen
Bug#1028104: libboost-dev: Boost with C++20 uses unavailable std functions
Op wo 19 apr 2023 om 06:04 schreef Anton Gladky : > > Hi, > > boost-defaults_1.81.0 is in experimental. But boost1.81 > is also available in the Debian Bookworm [1]. > > [1] https://packages.debian.org/source/testing/boost1.81 Hi Anton, Ah, it's even available in bpo, thanks a lot! -- Olaf
Bug#1032943: runit-init: halt called with unsupported options during poweroff
Hi Lorenzo, Lorenzo Puliti writes: > Package: runit-init > Version: 2.1.2-54 > Severity: minor > X-Debbugs-Cc: Olaf Meeuwissen , Mark > Hindley , plore...@disroot.org > > From Devuan bug #749 [1] > >> Every time I `poweroff` my machine, I see error message flash by that >> complain about `halt` being called with unsupported options. I think >> I have tracked this down to /etc/init.d/halt making blind assumptions >> about the options supported by the `halt` command. > > When runit is init, calling halt or reboot at the end of stage3 is unecessary, > so an easy solution to silent those warnings is to skip halt and reboot > scripts during the shutdown loop, so that reboot or poweroff is carry on > by runit code as stage 3 returns. Apologies if I sound a bit clueless, but if runit is *not* init, it would still have to call halt and reboot scripts, right? > There will be still one warning left for the -w flag but that is already > tracked in #992648 [2]. Ack. > I prefer not to silence the warning in shutdown.c: > > * It nice for the user to be warned that a used flag is noop > * (more important) halt/reboot are called by other scripts or programs in > the system, and I don't have a complete picture of that, so I'm using > the warning to make debug easier in such situations. Ack and let me state, for the record, that I have even less of a picture of how all these bits fit together :-/ > Olaf, let me know if you would be unsatisfyied with the above solution; If it solves my (wishlist) issue and does not unduly inconvenience other use cases, I'm fine with it. > [1] https://bugs.devuan.org/cgi/bugreport.cgi?bug=749 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992648 Hope this helps, -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Hi,
Again, unfortunately :-(
Diederik de Haas writes:
> On Sunday, 12 February 2023 03:29:14 CET Olaf Meeuwissen wrote:
>> Olaf Meeuwissen writes:
>> > Just checked again with 6.1.7-1 and still no joy :-(
>>
>> Glad to report joy cold-booting linux-image-6.1.0-3-amd64.
>> Currrently have the following installed
>
> That's great!
Cold booting with 6.1.0-5, I was left without a working keyboard again.
Warm booting back to 6.1.0-3 did NOT give me a working keyboard either.
Repeated cold booting 6.1.0-3 did NOT give me my keyboard back. I don't
know what happened when I was able to report success.
Plugged in my PS/2 keyboard via USB dongle, added
deb [check-valid-until=no]
https://snapshot.debian.org/archive/debian/20221112T151812Z/ sid main
to my APT sources and reinstalled 6.0.0-4. Cold booting that got my
Bluetooth-only keyboard back. Subsequent warm booting 6.1.0-5 left
that keyboard functional.
FTR, this is all using firmware-iwlwifi 20221214-3.
Earlier, in message #34, I reported that upgrading that package fixed
the issue for 6.0.0-4. Checking on packages.debian.org, I see that a
newer version is available for bookworm but that the section has been
renamed. Added that and upgraded which also bumped my other firmware
packages and pulled in the 6.1.0-6 kernel.
The 6.1.0-6 kernel also fails to load the firmware file, leaves me
without a working Bluetooth-only keyboard but warm booting to it (from a
6.0.0-4 cold boot) I can use said keyboard.
>> I checked the changelog but did not find anything obviously related, but
>> maybe one of these upstream stable updates
>>
>> - wifi: iwlwifi: fw: skip PPAG for JF
>> - Bluetooth: hci_sync: Fix use HCI_OP_LE_READ_BUFFER_SIZE_V2
>>
>> fixed it?
>
> I looked into them, but didn't find a direct link. But hopefully the issue is
> fixed now.
>
> If the issue does come back, then I'd suggest doing a `git bisect` between
> v5.18.14 and v5.18.16 as that's where the initial problem surfaced and it also
> has the benefit of being a reasonably small range.
Please note that 6.0.0-4 (package version 6.0.8-1) fixed it but 6.0.0-5
(package v6.0.10-1) broke it again. FTR,
diff -u /boot/config-6.0.0-{4,5}-amd64
--- /boot/config-6.0.0-4-amd642022-11-11 17:36:29.0 +0900
+++ /boot/config-6.0.0-5-amd642022-11-27 00:06:48.0 +0900
@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
-# Linux/x86 6.0.8 Kernel Configuration
+# Linux/x86 6.0.10 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc-12 (Debian 12.2.0-9) 12.2.0"
CONFIG_CC_IS_GCC=y
so we can rule out a configuration change causing the breakage.
> https://wiki.debian.org/DebianKernel/GitBisect has instructions for it.
Thanks for the pointer but that is a bit more work than I currently care
to chew into.
--
Olaf Meeuwissen
Bug#1026226: emacs: I hereby retract my bug report.
Package: emacs Followup-For: Bug #1026226 Dear Maintainer, I hereby retract my bug report. The behavior I observed is related to a property described in the Emacs manual about how Emacs creates backup files by default. This setting can be changed by the user. That takes care of the issue. I guess I better take care of the coffee ... -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs depends on: ii emacs-gtk 1:28.2+1-10 emacs recommends no packages. emacs suggests no packages. -- debconf-show failed
Bug#1032252: baloo-kf5: baloo displays search results multiple times.
Package: baloo-kf5 Version: 5.103.0-2 Severity: normal Dear Maintainer, The problem should be well known, e.g. it has been reported here over the years: - https://bugs.kde.org/show_bug.cgi?id=419302 It has nothing to do with the underlying file system, here XFS. It doesn't matter how often baloo's database is reset and re-indexed, after a short time the duplicates will multiply miraculously. An example, after re-setting up the database yesterday evening using "balooctl" I am already getting three (3) duplicate results this morning on a directory and all "found" files. In addition, the frontend, the file manager Dolphin, displays results that were excluded using "excludeFolders". I assumed Baloo was an integral part of KDE/Plasma, contrary to the working Recoll, or did I misunderstand? Or is the problem with my computer, because such problems over such a long period of time would be noticed by the developers and administrators who all work with it, right? And while I'm here, krunner, the other GUI for Baloo, truncates the filenames to fit /nicely into the picture/. The user is supposed to guess? I know you guys from the package management are not responsible for the development, but maybe there is a possibility to mark such packages as toy or experimental? -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages baloo-kf5 depends on: ii init-system-helpers 1.65.2 ii kio 5.103.0-1 ii libc62.36-8 ii libkf5baloo5 5.103.0-2 ii libkf5balooengine5 5.103.0-2 ii libkf5configcore55.103.0-1 ii libkf5coreaddons55.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5dbusaddons55.103.0-1 ii libkf5filemetadata3 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5idletime5 5.103.0-1 ii libkf5kiocore5 5.103.0-1 ii libkf5solid5 5.103.0-1 ii libqt5core5a 5.15.8+dfsg-2 ii libqt5dbus5 5.15.8+dfsg-2 ii libqt5gui5 5.15.8+dfsg-2 ii libqt5qml5 5.15.8+dfsg-2 ii libstdc++6 12.2.0-14 baloo-kf5 recommends no packages. baloo-kf5 suggests no packages. -- debconf-show failed
Bug#1031505: redmine: Install (upgrade) 5.x on Bullseye fails on NameError Redmine::Plugin
Package: redmine
Version: 5.0.4-2~bpo11+1
Severity: important
Dear Maintainer,
The system is a Bullseye server which was upgraded in the past. As Redmine for
Bullseye did not exist untill recently some left overs of the 4.x installation
remained.
I am very happy a backport arrived. Installing it failed:
Bundler will use `/tmp/bundler-20230217-1717663-fjvt9g' as your home directory
temporarily.
rake aborted!
NameError: uninitialized constant Redmine::Plugin
I am also a bit surprised that while being root, the installer reports /var/www
is my root directory instead of /root and also the fact it is not writable.
Although I am quite happy a tmp directory is used instead.
Full install log below.
-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-21-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages redmine depends on:
ii dbconfig-common 2.0.19
ii debconf [debconf-2.0] 1.5.77
ii libjs-chart.js 2.9.4+dfsg+~cs2.10.1-3
ii libjs-jquery3.5.1+dfsg+~3.5.5-7
ii libjs-jquery-ui 1.12.1+dfsg-8+deb11u1
ii libjs-raphael 2.3.0-3
ii libruby2.7 [ruby-csv] 2.7.4-1+deb11u1
ii redmine-mysql 4.0.7-1~bpo10+1
ii ruby1:2.7+2
ii ruby-actionpack-action-caching 1.2.2-1~bpo11+1
ii ruby-actionpack-xml-parser 2.0.1-4
ii ruby-addressable2.7.0-2
ii ruby-bundler2.2.5-2
ii ruby-coderay1.1.3-4
ii ruby-commonmarker 0.23.6-1~bpo11+1
ii ruby-csv3.2.2-1~bpo11+1
ii ruby-html-pipeline 2.14.3-1~bpo11+1
ii ruby-i18n 1.10.0-2~bpo11+1
ii ruby-jquery-rails 4.3.5-2
ii ruby-mail 2.7.1+dfsg1-1.1
ii ruby-marcel 1.0.1+dfsg-2~bpo11+1
ii ruby-mini-magick4.11.0-1~bpo11+1
ii ruby-mini-mime 1.1.1-1~bpo11+2
ii ruby-mocha 1.7.0-1
ii ruby-net-ldap 0.17.0-1~bpo11+1
ii ruby-nokogiri 1.13.5+dfsg-2~bpo11+1
ii ruby-rack 2.1.4-3
ii ruby-rack-test 0.7.0-1.1
ii ruby-rails 2:6.1.7+dfsg-3~bpo11+2
ii ruby-rails-dom-testing 2.0.3-3
ii ruby-rails-observers0.1.5-1.1
ii ruby-rbpdf 1.20.1-1
ii ruby-redcarpet 3.5.1-1
ii ruby-request-store 1.5.0-2
ii ruby-rmagick2.16.0-7
ii ruby-roadie 5.1.0-1~bpo11+1
ii ruby-roadie-rails 3.0.0-1~bpo11+2
ii ruby-rotp 6.2.0-2~bpo11+1
ii ruby-rouge 3.28.0-1~bpo11+1
ii ruby-rqrcode1.1.2-3
ii ruby-sanitize 6.0.0-1~bpo11+1
ii ruby-task-list 2.3.2-2~bpo11+1
ii ruby-zip2.3.0-2~bpo11+1
Versions of packages redmine recommends:
ii passenger 5.0.30-1.2
Versions of packages redmine suggests:
pn bzr
pn cvs
pn darcs
ii git 1:2.30.2-1+deb11u1
ii mercurial 5.6.1-4
pn ruby-fcgi
ii subversion 1.14.1-3+deb11u1
-- debconf information excluded
# aptitude install -t bullseye-backports redmine
The following NEW packages will be installed:
racc{a} ruby-chunky-png{a} ruby-commonmarker{a} ruby-enum{a}
ruby-html-pipeline{a} ruby-metaclass{a} ruby-mini-magick{a}
ruby-mini-portile2{a} ruby-mocha{a} ruby-posix-spawn{a} ruby-rotp{a}
ruby-rqrcode{a} ruby-rqrcode-core{a} ruby-sanitize{a} ruby-task-list{a}
ruby-zip{a}
The following packages will be REMOVED:
ruby-mime-types{u} ruby-mime-types-data{u} ruby-mimemagic{u}
The following packages will be upgraded:
redmine ruby-actioncable ruby-actionmailbox ruby-actionmailer
ruby-actionpack ruby-actionpack-action-caching ruby-actiontext
ruby-actionview ruby-activejob ruby-activemodel ruby-activerecord
ruby-activestorage ruby-activesupport ruby-csv ruby-globalid ruby-i18n
ruby-marcel ruby-mini-mime ruby-net-ldap ruby-nokogiri ruby-rails
ruby-railties ruby-roadie ruby-roadie-rails ruby-rouge ruby-tzinfo
26 packages upgraded, 16 newly installed, 3 to remove and 137 not upgraded.
Need to get 4,663 kB of archives. After unpacking 4,185 kB will be used.
Do you want to continue? [Y/n/?]
Get: 1 https://deb.debian.org/debian bullseye-backports/main amd64 ruby-i18n
all 1.10.0-2~bpo11+1 [42.1 kB]
Get: 2 https://deb.debian.org/debian bullseye-backports/main amd64
ruby-globalid all 0.6.0-1~bpo11+1 [12.9 kB]
Get: 3 https://deb.debian.org/debian bullseye-backp
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Olaf Meeuwissen writes: > Just checked again with 6.1.7-1 and still no joy :-( Glad to report joy cold-booting linux-image-6.1.0-3-amd64. Currrently have the following installed $ dpkg-query -W | grep -E '(linux-image|firmware-iwlwifi)' firmware-iwlwifi 20221214-3 linux-image-6.1.0-2-amd64 6.1.7-1 linux-image-6.1.0-3-amd64 6.1.8-1 linux-image-amd64 6.1.8-1 Cold-booting with linux-image-6.1.0-2-amd64 didn't give me a working keyboard. I checked the changelog but did not find anything obviously related, but maybe one of these upstream stable updates - wifi: iwlwifi: fw: skip PPAG for JF - Bluetooth: hci_sync: Fix use HCI_OP_LE_READ_BUFFER_SIZE_V2 fixed it? Hope this helps, -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Olaf Meeuwissen writes: > I am currently on > > firmware-iwlwifi/testing,now 20221214-3 all [installed] > linux-image-6.0.0-4-amd64/now 6.0.8-1 amd64 [installed,local] > linux-image-6.0.0-6-amd64/now 6.0.12-1 amd64 [installed,local] > linux-image-6.1.0-1-amd64/testing,now 6.1.4-1 amd64 [installed,automatic] > linux-image-amd64/testing,now 6.1.4-1 amd64 [installed,automatic] > > and still experience this issue when "cold" booting (i.e. after > `poweroff`) linux-image-6.1.0.1. Just checked again with 6.1.7-1 and still no joy :-( -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Olaf Meeuwissen writes: > FYI, the situation is unchanged after upgrading > > - firmware-iwlwifi from 20221109-2 to 20221109-4 > - linux-image-6.0.0-5-amd64 from 6.0.10-1 to 6.0.10-2 > - linux-image-amd64 from 6.0.10-1 to 6.0.10-2 I am currently on firmware-iwlwifi/testing,now 20221214-3 all [installed] linux-image-6.0.0-4-amd64/now 6.0.8-1 amd64 [installed,local] linux-image-6.0.0-6-amd64/now 6.0.12-1 amd64 [installed,local] linux-image-6.1.0-1-amd64/testing,now 6.1.4-1 amd64 [installed,automatic] linux-image-amd64/testing,now 6.1.4-1 amd64 [installed,automatic] and still experience this issue when "cold" booting (i.e. after `poweroff`) linux-image-6.1.0.1. In order to use my Bluetooth-only keyboard, I cold boot with 6.0.0-4 so that loading the intel/ibt-20-1-3.sfi firmware file succeeds and then "warm" boot (i.e. `reboot`) into 6.1.0-1 to use the latest kernel. That way I can use that Bluetooth-only keyboard. BTW, in order to select a kernel in the GRUB menu I use an old PS/2 keyboard connected via a PS/2 to USB adapter. P.S.: I have no info on cold booting with 6.0.0-6. Hope this helps, -- Olaf Meeuwissen
Bug#1028652: gnumeric: Inadmissibility of a black background color for cells
Package: gnumeric Version: 1.12.53-1.1+b1 Severity: wishlist Dear Maintainer! The inadmissibility of the black background color for cells is explained as follows: The highlighting of the active cell is done by means of a fine double frame with a transparent center. If cells are formatted with a black background color, the highlighting of the active cell is no longer visible, because black on black does not provide the necessary contrast for the human eye. Ergo, the black background color for cells should be illegal already for logical consideration, but also so that the user is protected from himself and his creativity. TIA! -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnumeric depends on: ii debconf [debconf-2.0] 1.5.81 ii gnumeric-common1.12.53-1.1 ii gsfonts2:20200910-6 ii libatk1.0-02.46.0-4 ii libc6 2.36-7 ii libcairo2 1.16.0-7 ii libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.4-1 ii libgoffice-0.10-10 0.10.53-1 ii libgsf-1-114 1.14.50-1 ii libgtk-3-0 3.24.36-1 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-01.50.12+ds-1 ii libxml22.9.14+dfsg-1.1+b2 ii procps 2:4.0.2-3 ii pxlib1 0.6.8-1+b1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages gnumeric recommends: pn evince ii gnumeric-doc 1.12.53-1.1 ii lp-solve 5.5.2.5-2 Versions of packages gnumeric suggests: ii fonts-liberation1:1.07.4-11 pn gnumeric-plugins-extra ii libgsf-1-dev1.14.50-1 -- debconf information: gnumeric/existing-process-title: * gnumeric/existing-process: true
Bug#1028408: gnumeric: Decimal places change by themselves.
Package: gnumeric Version: 1.12.53-1.1+b1 Severity: normal With request to take note. Dear Maintainer, after updating to the current version, I am noticing discrepancies with my entries in several documents. For example, sums like "9.95 €" are now displayed as "9.9493" and "6.4" as "6.44"; simple calculations like "=2.19/350" now say "=2.1899/0.348", etc. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnumeric depends on: ii debconf [debconf-2.0] 1.5.81 ii gnumeric-common1.12.53-1.1 ii gsfonts2:20200910-6 ii libatk1.0-02.46.0-4 ii libc6 2.36-7 ii libcairo2 1.16.0-7 ii libgdk-pixbuf-2.0-02.42.10+dfsg-1 ii libglib2.0-0 2.74.4-1 ii libgoffice-0.10-10 0.10.53-1 ii libgsf-1-114 1.14.50-1 ii libgtk-3-0 3.24.36-1 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-01.50.12+ds-1 ii libxml22.9.14+dfsg-1.1+b2 ii procps 2:4.0.2-3 ii pxlib1 0.6.8-1+b1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages gnumeric recommends: pn evince ii gnumeric-doc 1.12.53-1.1 ii lp-solve 5.5.2.5-2 Versions of packages gnumeric suggests: ii fonts-liberation1:1.07.4-11 pn gnumeric-plugins-extra ii libgsf-1-dev1.14.50-1 -- debconf-show failed
Bug#1027480: monitor: "Using an empty domain, fix the code."
Package: baloo-kf5 Version: 5.101.0-1 Severity: normal Dear Maintainer, the output of "balooctl monitor" is completely useless, as the following excerpt shows: #+BEGIN_QUOTE balooctl monitor Drücken Sie Strg+C um die Überwachung zu beenden Die Dateiindizierung läuft kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Unknown" msgid_plural: "" msgctxt: "" kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Idle" msgid_plural: "" msgctxt: "" Idle kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Unknown" msgid_plural: "" msgctxt: "" kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Indexing new files" msgid_plural: "" msgctxt: "" Indexing new files kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Unknown" msgid_plural: "" msgctxt: "" kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Idle" msgid_plural: "" msgctxt: "" Idle kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Unknown" msgid_plural: "" msgctxt: "" kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Indexing new files" msgid_plural: "" msgctxt: "" Indexing new files kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Unknown" msgid_plural: "" msgctxt: "" kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Idle" msgid_plural: "" msgctxt: "" Idle #+END_QUOTE -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages baloo-kf5 depends on: ii init-system-helpers 1.65.2 ii kio 5.101.0-2 ii libc62.36-7 ii libkf5baloo5 5.101.0-1 ii libkf5balooengine5 5.101.0-1 ii libkf5configcore55.101.0-1 ii libkf5coreaddons55.101.0-1 ii libkf5crash5 5.101.0-1 ii libkf5dbusaddons55.101.0-1 ii libkf5filemetadata3 5.101.0-2 ii libkf5i18n5 5.101.0-1+b1 ii libkf5idletime5 5.101.0-2 ii libkf5kiocore5 5.101.0-2 ii libkf5solid5 5.101.0-1 ii libqt5core5a 5.15.7+dfsg-2 ii libqt5dbus5 5.15.7+dfsg-2 ii libqt5gui5 5.15.7+dfsg-2 ii libqt5qml5 5.15.7+dfsg-2 ii libstdc++6 12.2.0-11 baloo-kf5 recommends no packages. baloo-kf5 suggests no packages. -- debconf-show failed
Bug#1026465: filelight: defective after upgrade to 20.12.0-1
Aurélien COUDERC writes: > Dear olaf, > > Le 20 décembre 2022 17:52:16 GMT+01:00, olaf a écrit : >>Package: filelight >>Version: 4:22.12.0-2 >>Severity: normal >> >>Dear Maintainer, >> >>after upgrading to the current version filelight works only >> rudimentary, that is, mouse clicks with the left mouse button to >> navigate are no longer accepted and the call of the context menu >> with the right mouse button is no longer there. >> >>To be on the safe side, I deleted all filelight files from all >> directories and user directories and reinstalled filelight. >> >>The version filelight_20.12.0-1_amd64.deb still works fine. > > That'd really very peculiar. > Both versions are supposed to be exactly the same besides an error > in the Debian changelog in my 20.12.0-1 upload. > > Would you mind retesting back and forth between 20.12.0-1 and 20.12.0-2 and > report back ? > > > Thank you, First of all I would like to mention, I had mixed up the version number in the mail heading, the defective version has the number 4:22.12.0-2. But you surely noticed that. I suspect the malfunction is related to the pop-up that slides under the mouse pointer and thus intercepts the mouse clicks that are supposed to invoke the context menu. This pop-up "sticks" when switching workspaces, so that parts of other programs are overlaid by it and are no longer accessible at those points. If filelight is closed, the pop-up is also removed. If my translation into English raises any questions please let me know.
Bug#1026717: gwenview: Description is deleted by rating.
Package: gwenview Version: 4:22.12.0-1+b1 Severity: normal Dear Maintainer, if I give an image a meaningful description under information and then click on the star to rate it, the description is deleted. It is not in the clipboard or in the attributes of the file system but simply erased. Even if stars are assigned first and Gwenview is restarted, any newly added description will be deleted if you proceed as described at the beginning. Furthermore I give to consider that a reference is missing, which makes particularly new users attentive to the fact that it concerns with the information extended attributes (xattr), which are to be stored by the file system and not into the picture arrive, as one knows it e.g. from exif. Because if the user makes the mistake of using the "wrong" program for administration, his sometimes time-consuming work is destroyed (even some KDE programs like Ark do not care about xattr). -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gwenview depends on: ii kinit 5.100.0-1 ii kio5.101.0-2 ii libc6 2.36-6 ii libcfitsio10 4.2.0-2 ii libexiv2-270.27.5-4 ii libgcc-s1 12.2.0-10 ii libjpeg62-turbo1:2.1.2-1+b1 ii libkf5activities5 5.101.0-1 ii libkf5baloo5 5.100.0-1 ii libkf5completion5 5.101.0-1 ii libkf5configcore5 5.101.0-1 ii libkf5configgui5 5.101.0-1 ii libkf5configwidgets5 5.101.0-1 ii libkf5coreaddons5 5.101.0-1 ii libkf5filemetadata35.100.0-1 ii libkf5guiaddons5 5.101.0-1 ii libkf5i18n55.101.0-1 ii libkf5iconthemes5 5.101.0-1 ii libkf5itemmodels5 5.100.0-1 ii libkf5itemviews5 5.101.0-1 ii libkf5jobwidgets5 5.101.0-1 ii libkf5kdcraw5 22.12.0-2 ii libkf5kiocore5 5.101.0-2 ii libkf5kiofilewidgets5 5.100.0-2 ii libkf5kiogui5 5.101.0-2 ii libkf5kiowidgets5 5.101.0-2 ii libkf5notifications5 5.101.0-1 ii libkf5parts5 5.100.0-1 ii libkf5purpose-bin 5.100.0-1 ii libkf5purpose5 5.100.0-1 ii libkf5service-bin 5.101.0-1 ii libkf5service5 5.101.0-1 ii libkf5solid5 5.101.0-1 ii libkf5widgetsaddons5 5.101.0-1 ii libkf5xmlgui5 5.101.0-1 ii libkimageannotator00.6.0-1 ii liblcms2-2 2.13.1-1+b1 ii libphonon4qt5-44:4.11.1-4 ii libpng16-161.6.39-2 ii libqt5core5a 5.15.6+dfsg-5 ii libqt5dbus55.15.6+dfsg-5 ii libqt5gui5 5.15.6+dfsg-5 ii libqt5printsupport55.15.6+dfsg-5 ii libqt5svg5 5.15.6-2 ii libqt5widgets5 5.15.6+dfsg-5 ii libqt5x11extras5 5.15.6-2 ii libstdc++6 12.2.0-10 ii libtiff5 4.4.0-6 ii libx11-6 2:1.8.1-2 ii perl 5.36.0-6 ii phonon4qt5 4:4.11.1-4 Versions of packages gwenview recommends: ii kamera 4:22.12.0-2 ii kio-extras 4:22.12.0-2 ii qt5-image-formats-plugins 5.15.6-2 gwenview suggests no packages. -- debconf-show failed
Bug#1026465: filelight: defective after upgrade to 20.12.0-1
Package: filelight Version: 4:22.12.0-2 Severity: normal Dear Maintainer, after upgrading to the current version filelight works only rudimentary, that is, mouse clicks with the left mouse button to navigate are no longer accepted and the call of the context menu with the right mouse button is no longer there. To be on the safe side, I deleted all filelight files from all directories and user directories and reinstalled filelight. The version filelight_20.12.0-1_amd64.deb still works fine. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages filelight depends on: ii kio 5.101.0-2 ii libc6 2.36-6 ii libkf5configcore5 5.101.0-1 ii libkf5configwidgets55.101.0-1 ii libkf5coreaddons5 5.101.0-1 ii libkf5i18n5 5.101.0-1 ii libkf5jobwidgets5 5.101.0-1 ii libkf5kiocore5 5.101.0-2 ii libkf5kiogui5 5.101.0-2 ii libkf5kiowidgets5 5.101.0-2 ii libkf5widgetsaddons55.101.0-1 ii libkf5xmlgui5 5.101.0-1 ii libqt5core5a5.15.6+dfsg-5 ii libqt5gui5 5.15.6+dfsg-5 ii libqt5qml5 5.15.6+dfsg-2 ii libqt5quick55.15.6+dfsg-2 ii libqt5quickcontrols2-5 5.15.6+dfsg-2 ii libqt5svg5 5.15.6-2 ii libqt5widgets5 5.15.6+dfsg-5 ii libstdc++6 12.2.0-10 filelight recommends no packages. filelight suggests no packages. -- debconf-show failed
Bug#1026249: tarlz does not save extended file attributes (xattr)
Package: tarlz Version: 0.23-2 Severity: normal Dear Maintainer, tarlz, unlike GNU tar, does not save extended file attributes (xattr). This shortcoming should be mentioned in the program description, not that users think they have a false sense of security. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tarlz depends on: ii libc6 2.36-6 ii libgcc-s1 12.2.0-10 ii liblz1 1.13-4 ii libstdc++6 12.2.0-10 tarlz recommends no packages. tarlz suggests no packages. -- debconf-show failed
Bug#1026226: emacs: Emacs ignores extended file attributes (xattr)
Package: emacs Version: 1:28.2+1-8 Severity: normal Dear Maintainer, If a file has extended attributes and is edited with Emacs, the extended attributes are lost. The easiest and most common way to do this is to assign keywords, comments or ratings to a file with the file manager Dolphin* and then open this file with Emacs and change it so that it can be "written" under the same name. (* Or alternatively: setfattr -n user.xdg.tags -v "keyword") On the homepage of Emacs I think I read that Emacs can handle extended attributes. This is obviously still not the case here. However, should this behavior be desired in the form, consider this letter as irrelevant. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs depends on: ii emacs-gtk 1:28.2+1-8 emacs recommends no packages. emacs suggests no packages. -- debconf-show failed
Bug#1026225: /bin/cp: "cp update" ignores "extended attributes".
Package: coreutils Version: 9.1-1 Severity: normal File: /bin/cp Dear Maintainer, "cp update" ignores "extended attributes". The underlying "cp" command reads: #+begin_src sh \cp --preserve=all --reflink=always -au #+end_src If an attribute is subsequently changed or newly set in the source file, e.g. the "user.baloo.rating" with KDE's Dophin, this change is not recognized by "cp". -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US 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-2 ii libattr1 1:2.5.1-3 ii libc62.36-6 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libselinux1 3.4-1+b3 coreutils recommends no packages. coreutils suggests no packages. -- debconf-show failed
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Olaf Meeuwissen writes: > Upgrading the firmware-iwlwifi package last week (2022-11-27) from > 20221012-1 to 20221109-2 fixed the issue for linux-image-6.0.0-4-amd64 > 6.0.8-1. The changelog for 20221109-1 mentioned > > * iwlwifi: update firmware files for Intel Bluetooth AX2* > * iwlwifi: Add Intel Wireless AX211 Bluethooth firmware and > configuration (Closes: #1023245) > > which may be related to fixing it for my > > Intel Corporation Wi-Fi 6 AX200 (rev 1a) > > However, upgrading today (2022-12-04) to linux-image-6.0.0-5-amd64 > 6.0.10-1 reintroduced it. > > Cold booting into 6.0.0-4 I have a working Bluetooth-only keyboard. > Rebooting from that into 6.0.0-5 my keyboard remains functional. > Cold booting into 6.0.0-5 my Bluetooth-only keyboard is unresponsive. > > For both 6.0.0-5 boot scenarios, dmesg --level=err includes > > bluetooth hci0: firmware: failed to load intel/ibt-20-1-3.sfi (-2) > > Twice, actually, about 10 microseconds apart. > > For 6.0.0-4 there is no such error message. FYI, the situation is unchanged after upgrading - firmware-iwlwifi from 20221109-2 to 20221109-4 - linux-image-6.0.0-5-amd64 from 6.0.10-1 to 6.0.10-2 - linux-image-amd64 from 6.0.10-1 to 6.0.10-2 Hope this helps, -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Upgrading the firmware-iwlwifi package last week (2022-11-27) from 20221012-1 to 20221109-2 fixed the issue for linux-image-6.0.0-4-amd64 6.0.8-1. The changelog for 20221109-1 mentioned * iwlwifi: update firmware files for Intel Bluetooth AX2* * iwlwifi: Add Intel Wireless AX211 Bluethooth firmware and configuration (Closes: #1023245) which may be related to fixing it for my Intel Corporation Wi-Fi 6 AX200 (rev 1a) However, upgrading today (2022-12-04) to linux-image-6.0.0-5-amd64 6.0.10-1 reintroduced it. Cold booting into 6.0.0-4 I have a working Bluetooth-only keyboard. Rebooting from that into 6.0.0-5 my keyboard remains functional. Cold booting into 6.0.0-5 my Bluetooth-only keyboard is unresponsive. For both 6.0.0-5 boot scenarios, dmesg --level=err includes bluetooth hci0: firmware: failed to load intel/ibt-20-1-3.sfi (-2) Twice, actually, about 10 microseconds apart. For 6.0.0-4 there is no such error message. Hope this helps, -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
I just want to add that there has been no improvement in the situation with 6.0.0-3 as well as 6.0.0-4. After a poweroff, I boot 5.18.0-3 (after I connect my PS2 keyboard via a USB dongle so I can navigate the GRUB menu) and then *reboot* to the latest kernel. This way, the firmware file is loaded by 5.18.0-3 and stays in the hardware's memory during the reboot so I get to use that latest kernel with my Bluetooth-only keyboard. Cumbersome, at best. Hope this helps, -- Olaf Meeuwissen
Bug#1024294: cmake: Why conflict with linux-image-6.0.0-2-amd64?
Package: cmake Followup-For: Bug #1024294 X-Debbugs-Cc: olafvds...@gmail.com Dear Maintainer, Nevermind, it seems to be an unrelated issue: # apt install cmake Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: cmake : Depends: cmake-data (= 3.25.0-1) but 3.24.3-1 is to be installed E: Unable to correct problems, you have held broken packages. Greetings, Olaf -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/3 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages cmake depends on: ii cmake-data3.24.3-1 ii libarchive13 3.6.0-1 ii libc6 2.36-5 ii libcurl4 7.86.0-2 ii libexpat1 2.5.0-1 ii libgcc-s1 12.2.0-9 ii libjsoncpp25 1.9.5-4 ii librhash0 1.4.3-3 ii libstdc++612.2.0-9 ii libuv11.44.2-1 ii procps2:3.3.17-7.1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages cmake recommends: ii gcc 4:12.2.0-1 ii make 4.3-4.1 Versions of packages cmake suggests: pn cmake-doc pn cmake-format ii ninja-build 1.11.1-1 -- no debconf information
Bug#1024294: cmake: Why conflict with linux-image-6.0.0-2-amd64?
Package: cmake Version: 3.24.3-1 Severity: wishlist X-Debbugs-Cc: olafvds...@gmail.com Dear Maintainer, Maybe not a bug, but why does cmake conflict with this kernel image? Greetings, Olaf # apt dist-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages will be REMOVED: linux-image-6.0.0-2-amd64 The following packages have been kept back: cmake 0 upgraded, 0 newly installed, 1 to remove and 1 not upgraded. After this operation, 478 MB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 100203 files and directories currently installed.) Removing linux-image-6.0.0-2-amd64 (6.0.6-2) ... /etc/kernel/postrm.d/initramfs-tools: update-initramfs: Deleting /boot/initrd.img-6.0.0-2-amd64 /etc/kernel/postrm.d/zz-update-grub: Generating grub configuration file ... Found linux image: /boot/vmlinuz-6.0.0-4-amd64 Found initrd image: /boot/initrd.img-6.0.0-4-amd64 Found linux image: /boot/vmlinuz-6.0.0-3-amd64 Found initrd image: /boot/initrd.img-6.0.0-3-amd64 Warning: os-prober will not be executed to detect other bootable partitions. Systems on them will not be added to the GRUB boot configuration. Check GRUB_DISABLE_OS_PROBER documentation entry. done -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/3 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages cmake depends on: ii cmake-data3.24.3-1 ii libarchive13 3.6.0-1 ii libc6 2.36-5 ii libcurl4 7.86.0-2 ii libexpat1 2.5.0-1 ii libgcc-s1 12.2.0-9 ii libjsoncpp25 1.9.5-4 ii librhash0 1.4.3-3 ii libstdc++612.2.0-9 ii libuv11.44.2-1 ii procps2:3.3.17-7.1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages cmake recommends: ii gcc 4:12.2.0-1 ii make 4.3-4.1 Versions of packages cmake suggests: pn cmake-doc pn cmake-format ii ninja-build 1.11.1-1 -- no debconf information
Bug#1023782: [Pkg-mozext-maintainers] Bug#1023782: Add dependency on pinentry-x11
Hi,
Daniel Kahn Gillmor writes:
> over on Bug #1023782 ("Add dependency on pinentry-x11") about
> webext-browserpass,
> Meeuwissen Olaf wrote:
>
>> Please add a dependency on pinentry-x11. This is a pure virtual package that
>> makes the user pick one. I think that is to be preferred over adding a list
>> of
>> alternatives directly because the package managers tend to pick the first one
>> listed.
>
> Arguably, pinentry-x11 is a misnomer, because pinentry-gnome3 works in
> any GNOME graphical environment, including ones that are purely based on
> Wayland, with no X11 whatsoever.
Fully agree on the misnomer part. Point in case, I noticed this using
sway (with xwayland installed) and installed pinentry-gnome3.
> But we don't have a pinentry-gui virtual package at the moment, so
> pinentry-x11 is probably the right choice.
Maybe pinentry-gui should be added as a pure virtual package? And in
due course, pinentry-x11 removed? Anyway, that's not food for the
webext-browserpass package.
> It should definitely be at least a Recommends: given pass's reliance
> on GnuPG, and GnuPG's transitive reliance (through gpg-agent) on a
> graphical password prompter.
I was getting by fine for the most part with pinentry-tty until I tried
to integrate browserpass ;-)
> It's this tangled mess of dependencies that makes it necessary for the
> bits that are designed to run in a graphical environment (like
> browserpass) to explicitly declare their dependencies on graphical
> pinentry specifically.
Guess what! webext-browserpass doesn't even depend on pass! :-o
Oh, just noticed that pass (or gopass) is not actually required[1].
Maybe that should become a Recommends: too, with a note in the package
description why it's not a Depends: ...
[1]: https://github.com/browserpass/browserpass-extension#requirements
--
Olaf Meeuwissen
Bug#1023784: comma separated no_proxy value ignored
Package: curl Version: 7.86.0-1 Severity: important I use a comma separated list of values in my no_proxy environment settings. Something like this no_proxy=localhost,127.0.0.1,::1,.internal.example.com,.example.org,10.0.0.0/8 This has worked fine for me for years. After the upgrade from 7.85.0-1 to 7.86.0-1, this setting is ignored and curl contacts the proxy server: $ curl -sv http://www.internal.example.com/ >/dev/null * Uses proxy env variable no_proxy == 'localhost,127.0.0.1,::1,.internal.example.com,.example.org,10.0.0.0/8' * Uses proxy env variable http_proxy == 'http://proxy.example.com:8080' * Trying 10.0.20.20:8080... * Connected to (nil) (10.0.20.20) port 8080 (#0) Using a single domain for the no_proxy value does not contact the proxy $ no_proxy=.internal.example.com curl -sv http://www.internal.example.com/ >/dev/null * Uses proxy env variable no_proxy == '.internal.example.com' * Trying 10.11.0.165:80... * Connected to www.internal.example.com (10.11.0.165) port 80 (#0) I have been experimenting a bit and found that *appending* to the variable triggers the bug. That is, no_proxy=.internal.example.com,localhost contacts the proxy server. Prepending it, does *not* trigger the bug. That is no_proxy=localhost,.internal.example.com does not contact the proxy. If I move .internal.example.com to the end of the comma separated list, curl behaves as expected but that obviously breaks for URLs in the .example.org domain or covered by the 10.0.0.0/8 CIDR. BTW, I also observe this with git for HTTP(S) URLs. In fact, that's where I first encountered the bug. Setting the no_proxy value to match the URL works around the issue for git too. Seeing that curl depends on libcurl4 and git libcurl3-gnutls, I'm submitting this to curl. I set the severity to important because it breaks a very common (as in oodles of times per day) workflow for me. Hope this helps.
Bug#1023782: Add dependency on pinentry-x11
Package: webext-browserpass Version: 3.7.2-1+b6 Severity: important The upstream documentation[1] clearly mentions that this extension depends on a GUI-based pinentry (unless you know what you're doing). This is not reflected in the package dependencies. I realize most desktops will pull one in but I prefer to piece something myself. And without installing Recommends: to boot ;-) Please add a dependency on pinentry-x11. This is a pure virtual package that makes the user pick one. I think that is to be preferred over adding a list of alternatives directly because the package managers tend to pick the first one listed. Seeing that people who know what they are doing can get away without the GUI-based pinentry, I guess a Recommends: is sufficient (although a Depends: would be okay with me too). [1]: https://github.com/browserpass/browserpass-extension#error-unable-to-fetch-and-parse-login-fields Hope this helps,
Bug#1021918: debian-installer: Kernel module blacklisting inconsistent
Hi again, Olaf Meeuwissen writes: > Sorry for the belated follow-up. > > Pascal Hambourg writes: > >> On 22/10/2022 at 03:39, Olaf Meeuwissen wrote: >>> Pascal Hambourg writes: >>>> On 17/10/2022 at 13:13, Olaf Meeuwissen wrote: >>>>> I recently tried this version with hardware that triggers loading of the >>>>> mt7921e kernel module. Loading the module fails due to a firmware file >>>>> load error but the installer starts okay. However, the installer later >>>>> crashes when probing for network hardware (when it tries to rmmod the >>>>> kernel module). >>>> >>>> How does the installer crash exactly ? Kernel panic ? Freeze ? Error ? >>> Freeze. Even after ten minutes the network hardware probe does not >>> complete. FWIW, I have seen an error log as well but that may have >>> been with Devuan's preview installer for daedalus. >> >> I could not reproduce this after tricking the installer into unloading >> and reloading the mt7921e module. The module unloads and reloads >> cleanly. But I do not have any hardware matching this module. > > The freeze probably only occurs when an attempt to loadh the firmware > file is made. Unlikely that will happen if the hardware is not found. > Anyway, this issue is not with this particular kernel module but with > the installer's inconsistent module blacklisting behaviour. > > FWIW, I've since installed firmware-misc-nonfree and removed all the > blacklisting bits for the module. WiFi works fine. > >>> I've attached the installer's syslog. /dev/sdc is the installer ISO. >>> The other disks, /dev/sda, /dev/sdb and /dev/nmve0n1 are the machine's >>> internal disks. I just ran the installer after the machine was already >>> installed with the workaround I mentioned in the original bug report. >>> The error starts at >>>Oct 19 23:06:13 check-missing-firmware: removing and loading >>> kernel module mt7921e >> >>> Oct 19 23:06:13 kernel: [ 40.024088] BUG: unable to handle page >>> fault for address: 6500 >>> Oct 19 23:06:13 kernel: [ 40.024092] #PF: supervisor write access in >>> kernel mode >>> Oct 19 23:06:13 kernel: [ 40.024094] #PF: error_code(0x0002) - >>> not-present page >> (...) >>> Oct 19 23:06:13 kernel: [ 40.024120] Call Trace: >>> Oct 19 23:06:13 kernel: [ 40.024121] >>> Oct 19 23:06:13 kernel: [ 40.024124] __cancel_work_timer+0x3c/0x190 >>> Oct 19 23:06:13 kernel: [ 40.024128] ? __kernfs_remove.part.0+0x190/0x2b0 >>> Oct 19 23:06:13 kernel: [ 40.024131] mt7921_pci_remove+0x2c/0x110 >>> [mt7921e] >> >> It looks like a kernel bug when unloading this module. Can you trigger >> the bug in an installed system ? If yes it means that it not specific >> to the installer. > > Machine's at the office, will see if I can test tomorrow or the day after. Checked this morning. With the firmware file loaded, rmmod succeeds without problems. With the firmware file not loaded, trying to rmmod it echoes "Killed" on the command-line and created a longish call trace in /var/log/kern.log. Not sure if it was the same, though. >>>>> The first issue I ran into was that the documented[1] way to blacklist >>>>> kernel modules is no longer correct >>>>>[1]: >>>>> https://www.debian.org/releases/testing/amd64/ch05s03.en.html#module-blacklist >>>>> Instead of >>>>> mt7921e.blacklist=yes >>>>> I had to use >>>>> modprobe.blacklist=mt7921e >>>> >>>> /lib/debian-installer-startup.d/S02module-params has the following comment: >>>> >>>> # Before udev is started, parse kernel command word for module params of >>>> # the form module.param=value and register them so they will be used when >>>> # modules are loaded. Also check for modules to be blacklisted. >>>> >>>> But udev is actually started earlier, so the first method does not >>>> work with modules included in initrd.gz (e.g. storage drivers). >>> In that case, shouldn't that be mentioned in the installation >>> manual? >>> Actually, a single method that works for *all* modules, whether in the >>> initrd.gz or installed later is much preferred. >>> >>>> However it should work with network driver modules which are installed >>>> much later. >>> You may want to double check how the kernel command parse r
Bug#1021918: debian-installer: Kernel module blacklisting inconsistent
Sorry for the belated follow-up. Pascal Hambourg writes: > On 22/10/2022 at 03:39, Olaf Meeuwissen wrote: >> Pascal Hambourg writes: >>> On 17/10/2022 at 13:13, Olaf Meeuwissen wrote: >>>> I recently tried this version with hardware that triggers loading of the >>>> mt7921e kernel module. Loading the module fails due to a firmware file >>>> load error but the installer starts okay. However, the installer later >>>> crashes when probing for network hardware (when it tries to rmmod the >>>> kernel module). >>> >>> How does the installer crash exactly ? Kernel panic ? Freeze ? Error ? >> Freeze. Even after ten minutes the network hardware probe does not >> complete. FWIW, I have seen an error log as well but that may have >> been with Devuan's preview installer for daedalus. > > I could not reproduce this after tricking the installer into unloading > and reloading the mt7921e module. The module unloads and reloads > cleanly. But I do not have any hardware matching this module. The freeze probably only occurs when an attempt to loadh the firmware file is made. Unlikely that will happen if the hardware is not found. Anyway, this issue is not with this particular kernel module but with the installer's inconsistent module blacklisting behaviour. FWIW, I've since installed firmware-misc-nonfree and removed all the blacklisting bits for the module. WiFi works fine. >> I've attached the installer's syslog. /dev/sdc is the installer ISO. >> The other disks, /dev/sda, /dev/sdb and /dev/nmve0n1 are the machine's >> internal disks. I just ran the installer after the machine was already >> installed with the workaround I mentioned in the original bug report. >> The error starts at >>Oct 19 23:06:13 check-missing-firmware: removing and loading >> kernel module mt7921e > >> Oct 19 23:06:13 kernel: [ 40.024088] BUG: unable to handle page fault for >> address: 6500 >> Oct 19 23:06:13 kernel: [ 40.024092] #PF: supervisor write access in >> kernel mode >> Oct 19 23:06:13 kernel: [ 40.024094] #PF: error_code(0x0002) - not-present >> page > (...) >> Oct 19 23:06:13 kernel: [ 40.024120] Call Trace: >> Oct 19 23:06:13 kernel: [ 40.024121] >> Oct 19 23:06:13 kernel: [ 40.024124] __cancel_work_timer+0x3c/0x190 >> Oct 19 23:06:13 kernel: [ 40.024128] ? __kernfs_remove.part.0+0x190/0x2b0 >> Oct 19 23:06:13 kernel: [ 40.024131] mt7921_pci_remove+0x2c/0x110 >> [mt7921e] > > It looks like a kernel bug when unloading this module. Can you trigger > the bug in an installed system ? If yes it means that it not specific > to the installer. Machine's at the office, will see if I can test tomorrow or the day after. >>>> The first issue I ran into was that the documented[1] way to blacklist >>>> kernel modules is no longer correct >>>>[1]: >>>> https://www.debian.org/releases/testing/amd64/ch05s03.en.html#module-blacklist >>>> Instead of >>>> mt7921e.blacklist=yes >>>> I had to use >>>> modprobe.blacklist=mt7921e >>> >>> /lib/debian-installer-startup.d/S02module-params has the following comment: >>> >>> # Before udev is started, parse kernel command word for module params of >>> # the form module.param=value and register them so they will be used when >>> # modules are loaded. Also check for modules to be blacklisted. >>> >>> But udev is actually started earlier, so the first method does not >>> work with modules included in initrd.gz (e.g. storage drivers). >> In that case, shouldn't that be mentioned in the installation >> manual? >> Actually, a single method that works for *all* modules, whether in the >> initrd.gz or installed later is much preferred. >> >>> However it should work with network driver modules which are installed >>> much later. >> You may want to double check how the kernel command parse results >> are >> used then. > > I did, and .blacklist works as expected with NIC modules > matching my hardware (iwlwifi and e1000e). I meant double check by reading the source code, not by trying with some rather commonly used modules. >> Or maybe the mt7921e module is in the initrd.gz? >> Just checked, it is not. > > Indeed, it is in the package nic-wireless-modules--di. > >>>> However, upon booting I saw a pile of ATA bus and I/O errors that made >>>> me suspicious. The disk is brand new and a smartmontools extended test >>>> reports no errors. >>>> I f
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
Hi again, Olaf Meeuwissen writes: >> Package: linux-image-5.18.0-4-amd64 >> Severity: important >> >> The intel/ibt-20-1-3.sfi file loads fine on linux-image-5.18.0-3-amd64. >> Used that to report this bug as the failure to load leaves me without a >> working keyboard. It's a bluetooth-only keyboard and it not working at >> all is why I've marked this important. > > I just want to add that this is still an issue with 6.0.0-2. Exact same > symptoms. Keyboard is useless when booting after a poweroff. Booting > into 5.18.0-3 restores keyboard usability. A subsequent *reboot* to the > latest linux-image version, as opposed to a poweroff+boot, leaves the > keyboard in a usable state. Just upgraded 6.0.0-2 from 6.0.3-1 to 6.0.5-1 and firmware-iwlwifi, which provides the intel/ibt-20-1-3.sfi file, from 20210818-1 to 20221012-1. Still no working keyboard after booting following a poweroff. I'm back to booting 5.18.0-3 which loads the file just fine and gives me back my keyboard. -- Olaf Meeuwissen
Bug#1017977: Fails to load intel/ibt-20-1-3.sfi
> Package: linux-image-5.18.0-4-amd64 > Severity: important > > The intel/ibt-20-1-3.sfi file loads fine on linux-image-5.18.0-3-amd64. > Used that to report this bug as the failure to load leaves me without a > working keyboard. It's a bluetooth-only keyboard and it not working at > all is why I've marked this important. I just want to add that this is still an issue with 6.0.0-2. Exact same symptoms. Keyboard is useless when booting after a poweroff. Booting into 5.18.0-3 restores keyboard usability. A subsequent *reboot* to the latest linux-image version, as opposed to a poweroff+boot, leaves the keyboard in a usable state. Hope this helps, -- Olaf Meeuwissen
Bug#1021918: debian-installer: Kernel module blacklisting inconsistent
Pascal Hambourg writes: > On 17/10/2022 at 13:13, Olaf Meeuwissen wrote: >> I recently tried this version with hardware that triggers loading of the >> mt7921e kernel module. Loading the module fails due to a firmware file >> load error but the installer starts okay. However, the installer later >> crashes when probing for network hardware (when it tries to rmmod the >> kernel module). > > How does the installer crash exactly ? Kernel panic ? Freeze ? Error ? Freeze. Even after ten minutes the network hardware probe does not complete. FWIW, I have seen an error log as well but that may have been with Devuan's preview installer for daedalus. You can still switch VTs but trying to `poweroff` or `reboot` after starting a shell on VT2 or VT3 will also freeze. The last bit of the error can be seen on VT4. I've attached the installer's syslog. /dev/sdc is the installer ISO. The other disks, /dev/sda, /dev/sdb and /dev/nmve0n1 are the machine's internal disks. I just ran the installer after the machine was already installed with the workaround I mentioned in the original bug report. The error starts at Oct 19 23:06:13 check-missing-firmware: removing and loading kernel module mt7921e and looks like what I've seen on VT4. >> The first issue I ran into was that the documented[1] way to blacklist >> kernel modules is no longer correct >> [1]: >> https://www.debian.org/releases/testing/amd64/ch05s03.en.html#module-blacklist >> Instead of >>mt7921e.blacklist=yes >> I had to use >>modprobe.blacklist=mt7921e > > /lib/debian-installer-startup.d/S02module-params has the following comment: > > # Before udev is started, parse kernel command word for module params of > # the form module.param=value and register them so they will be used when > # modules are loaded. Also check for modules to be blacklisted. > > But udev is actually started earlier, so the first method does not > work with modules included in initrd.gz (e.g. storage drivers). In that case, shouldn't that be mentioned in the installation manual? Actually, a single method that works for *all* modules, whether in the initrd.gz or installed later is much preferred. > However it should work with network driver modules which are installed > much later. You may want to double check how the kernel command parse results are used then. Or maybe the mt7921e module is in the initrd.gz? Just checked, it is not. >> However, upon booting I saw a pile of ATA bus and I/O errors that made >> me suspicious. The disk is brand new and a smartmontools extended test >> reports no errors. >> I found a /etc/modprobe.d/blacklist.local.conf file with >>blacklist modprobe > > This is a minor bug in > /lib/debian-installer-startup.d/S02module-params which can be easily > fixed. However, it should not have any actual impact as "modprobe" > does not match any kernel module name or alias. Strange, because removing it made those ATA bus and I/O errors go away, reproducibly at that. >> For completeness' sake, the /etc/default/grub file included >>GRUB_CMDLINE_LINUX="modprobe.blacklist=mt7921e" > > As expected. I have since removed that blacklist statement and installed firmware-misc-nonfree. That makes the firmware load without any trouble. >> Seeing that the kernel boot argument is added correctly to the GRUB >> configuration, there is no need to create a file in /etc/modprobe.d/. >> In addition, the installation manual needs to be updated to use the >> correct syntax. > > If I understand correctly, this is how things work: > > The kernel runs /init. > /init runs /lib/debian-installer/start-udev which starts udevd. > udevd gets hotplug events and calls modprobe to load matching modules > included in initrd.gz. > Then /init exec's /bin/busybox init. Since there is no mt7921e module in the initrd.gz, in fact no modules matching mt7, it should not have been loaded at this point according to your understanding. > busybox init reads /etc/inittab and runs /sbin/debian-installer-startup. > debian-installer-startup runs > /lib/debian-installer-startup.d/S02module-params. > /lib/debian-installer-startup.d/S02module-params calls > /bin/register-module for each module parameter or blacklist in the > kernel command line. That appears to work but blacklisting syntax is *not* as documented in the installation manual. > register-module writes module blacklists in > /etc/modprobe.d/blacklist.local.conf and module parameters in > /etc/modprobe.d/local.conf. The blacklist.local.conf file is created as documented but using the alternative syntax I had to use leads to the oxymoronic blacklist modprobe entry, trying to tell modprobe to blac
Bug#1021918: debian-installer: Kernel module blacklisting inconsistent
Package: debian-installer Version: 20220917 Severity: normal Tags: d-i Dear Maintainer, I recently tried this version with hardware that triggers loading of the mt7921e kernel module. Loading the module fails due to a firmware file load error but the installer starts okay. However, the installer later crashes when probing for network hardware (when it tries to rmmod the kernel module). Since the hardware has 2 additional wired NICs that work fine (and I wanted to do an air-gap install anyway!), I decided to blacklist the module. The first issue I ran into was that the documented[1] way to blacklist kernel modules is no longer correct [1]: https://www.debian.org/releases/testing/amd64/ch05s03.en.html#module-blacklist Instead of mt7921e.blacklist=yes I had to use modprobe.blacklist=mt7921e to prevent the kernel from loading the module (between the boot menu and starting the installer proper). With the latter appended to the `linux` line of the boot menu entry, the installation appeared to have completed without problems. However, upon booting I saw a pile of ATA bus and I/O errors that made me suspicious. The disk is brand new and a smartmontools extended test reports no errors. I found a /etc/modprobe.d/blacklist.local.conf file with blacklist modprobe Removing that file made the ATA bus and I/O errors go away. For completeness' sake, the /etc/default/grub file included GRUB_CMDLINE_LINUX="modprobe.blacklist=mt7921e" so the offending module is not loaded upon reboot after installation. Seeing that the kernel boot argument is added correctly to the GRUB configuration, there is no need to create a file in /etc/modprobe.d/. In addition, the installation manual needs to be updated to use the correct syntax. Hope this helps, -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled -- Olaf Meeuwissen
Bug#1021914: docker.io: Purge nukes /var/lib/docker/ without confirmation
Package: docker.io Severity: normal Dear Maintainer, I came across this issue when replacing docker.io with docker-ce. My APT configuration has APT::Get::Purge=true so behaviour was similar to running apt install --purge docker-ce docker.io Since I was replacing one docker with another, I didn't quite expect /var/lib/docker/ to get nuked. I understand nuking /var/lib/docker/ in the general scenario where someone purges docker.io. However, I think it is still a good idea to ask for confirmation explaining the consequences before proceding. Especially in view of Docker managed volumes that may contain data that the user may want to keep. Fortunately, in my case I don't put valuable data in Docker managed volumes but I still ended up having to pull/build a large pile of images. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled -- Olaf Meeuwissen
Bug#1020615: adduser: README.Debian doesn't seem to exist
Op ma 26 sep. 2022 om 15:19 schreef Marc Haber : > > On Mon, Sep 26, 2022 at 03:18:39PM +0200, Marc Haber wrote: > > Thanks for spotting this. Fixed in git. MR 65 created. > > In the mean time, find the information on salsa: > > https://salsa.debian.org/debian/adduser/-/blob/master/debian/README Some feedback / typos: > Sadly, currently (summer 2022, adduser 3.125) locking and unlocking accounts > it not well supported yet. is? not > Debian pacakges. packages? > to add the Desired support desired? > regular user's home directory to 0700 while keeping the mode permissive setting more? > has oscillated back in forth and? > distributions, none of which setting the sgid bit on home directories to 1 (research done in July 2022). set* -- Olaf
Bug#1020615: adduser: README.Debian doesn't seem to exist
Package: adduser Version: 3.129 Severity: normal X-Debbugs-Cc: olafvds...@gmail.com Hi, > See /usr/share/doc/adduser/README.Debian for detailed reasoning. $ cat /usr/share/doc/adduser/README.Debian cat: /usr/share/doc/adduser/README.Debian: No such file or directory $ l /usr/share/doc/adduser total 56 -rw-r--r-- 1 root root 27798 Sep 5 21:57 changelog.gz -rw-r--r-- 1 root root 12317 Sep 5 21:57 copyright drwxr-xr-x 3 root root 4096 Sep 10 13:29 examples -rw-r--r-- 1 root root 988 Sep 5 21:57 NEWS.Debian.gz -rw-r--r-- 1 root root 1044 Sep 5 21:57 TODO Greetings, Olaf -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages adduser depends on: ii passwd 1:4.11.1+dfsg1-2 adduser recommends no packages. Versions of packages adduser suggests: ii cron3.0pl1-149 ii liblocale-gettext-perl 1.07-4+b2 ii perl5.34.0-5 -- debconf information: adduser/homedir-permission: true adduser/title:
Bug#1008673: gnumeric: libspreadsheet-1.12.50.so segfault
Package: gnumeric Followup-For: Bug #1008673 Dear Maintainer, five days ago I installed Gnumeric version 1.12.52-1 with its dependencies. None of the errors described to me above have occurred since then, although I have tried to reproduce them intentionally alongside daily use. Gnumeric in this current version works for me as stable as I knew it from the versions up to 1.12.48. Thanks for the repeated rapid update! -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-rt-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_GB:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnumeric depends on: ii debconf [debconf-2.0] 1.5.79 ii gnumeric-common1.12.52-1 ii gsfonts1:8.11+urwcyr1.0.7~pre44-4.5 ii libatk1.0-02.38.0-1 ii libc6 2.33-7 ii libcairo2 1.16.0-5 ii libgdk-pixbuf-2.0-02.42.8+dfsg-1 ii libglib2.0-0 2.72.1-1 ii libgoffice-0.10-10 0.10.51-1 ii libgsf-1-114 1.14.49-1 ii libgtk-3-0 3.24.33-1 ii libpango-1.0-0 1.50.7+ds-1 ii libpangocairo-1.0-01.50.7+ds-1 ii libxml22.9.13+dfsg-1+b1 ii procps 2:3.3.17-7+b1 ii pxlib1 0.6.8-1+b1 ii zlib1g 1:1.2.11.dfsg-4 Versions of packages gnumeric recommends: ii evince42.2-1 ii gnumeric-doc 1.12.52-1 ii lp-solve 5.5.2.5-2 Versions of packages gnumeric suggests: ii fonts-liberation1:1.07.4-11 pn gnumeric-plugins-extra ii libgsf-1-dev1.14.49-1 -- debconf information: gnumeric/existing-process-title: gnumeric/existing-process: false
Bug#1009106: nfs-common: blkmapd open pipe file /run/rpc_pipefs/nfs/blocklayout failed
Package: nfs-common Version: 1:2.6.1-1+b1 Severity: normal Dear Maintainer, apparently a file expected by "blkmapd" is not found because it does not exist. #+begin_quote # systemctl status nfs-blkmap.service ● nfs-blkmap.service - pNFS block layout mapping daemon Loaded: loaded (/lib/systemd/system/nfs-blkmap.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2022-04-07 11:03:48 CEST; 10min ago Process: 1007 ExecStart=/usr/sbin/blkmapd (code=exited, status=0/SUCCESS) Main PID: 1010 (blkmapd) Tasks: 1 (limit: 37594) Memory: 388.0K CPU: 1ms CGroup: /system.slice/nfs-blkmap.service └─1010 /usr/sbin/blkmapd Apr 07 11:03:48 acht systemd[1]: Starting pNFS block layout mapping daemon... Apr 07 11:03:48 acht blkmapd[1010]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory Apr 07 11:03:48 acht systemd[1]: Started pNFS block layout mapping daemon. # LANG=en ls -la /run/rpc_pipefs/nfs/ total 0 dr-xr-xr-x 2 root root 0 2022-04-07 11:03 . dr-xr-xr-x 11 root root 0 2022-04-07 11:03 .. #+end_quote If it is a trivial message, I think it should no longer be reported. -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 151 udp 48372 mountd 151 tcp 50807 mountd 152 udp 51838 mountd 152 tcp 33005 mountd 153 udp 41222 mountd 153 tcp 47085 mountd 1000241 udp 60298 status 1000241 tcp 57121 status 133 tcp 2049 nfs 134 tcp 2049 nfs 1002273 tcp 2049 1000211 udp 48057 nlockmgr 1000213 udp 48057 nlockmgr 1000214 udp 48057 nlockmgr 1000211 tcp 39169 nlockmgr 1000213 tcp 39169 nlockmgr 1000214 tcp 39169 nlockmgr -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD= NEED_GSSD= -- /etc/idmapd.conf -- [General] Verbosity = 0 [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- 192.168.1.7:/anexemplary/entry nfs rw,soft,retrans=3,timeo=10,user,noauto 0 0 -- /proc/mounts -- nfsd /proc/fs/nfsd nfsd rw,relatime 0 0 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 nfs-common depends on: ii adduser 3.121 ii init-system-helpers 1.62 ii keyutils 1.6.1-3 ii libc62.33-7 ii libcap2 1:2.44-1 ii libcom-err2 1.46.5-2 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libevent-core-2.1-7 2.1.12-stable-1 ii libgssapi-krb5-2 1.19.2-2+b1 ii libkeyutils1 1.6.1-3 ii libkrb5-31.19.2-2+b1 ii libmount12.37.3-1+b1 ii libnfsidmap1 1:2.6.1-1+b1 ii libtirpc31.3.2-2 ii libwrap0 7.6.q-31 ii lsb-base 11.1.0 ii python3 3.9.8-1 ii rpcbind 1.2.6-2 ii ucf 3.0043 nfs-common recommends no packages. Versions of packages nfs-common suggests: pn open-iscsi pn watchdog Versions of packages nfs-kernel-server depends on: ii keyutils 1.6.1-3 ii libblkid12.37.3-1+b1 ii libc62.33-7 ii libcap2 1:2.44-1 ii libevent-core-2.1-7 2.1.12-stable-1 ii libsqlite3-0 3.38.2-1 ii libtirpc31.3.2-2 ii libuuid1 2.37.3-1+b1 ii libwrap0 7.6.q-31 ii lsb-base 11.1.0 ii netbase 6.3 ii ucf 3.0043 Versions of packages nfs-kernel-server recommends: ii python3 3.9.8-1 ii python3-yaml 5.4.1-1+b1 -- no debconf information
Bug#1008673: gnumeric: libspreadsheet-1.12.50.so segfault
Package: gnumeric Version: 1.12.51-1 Followup-For: Bug #1008673 Dear Maintainer, after installing the new version, I made a new working copy of the respective table with the included tool "ssconvert" as usual. At the beginning Gnumeric behaved stable, I could duplicate table sheets and move selected cells with the mouse. I was already on the verge of declaring it a positive kill. Around noon, I selected two adjacent cells and wanted to drag the containing simple formula downwards with the mouse at the handle to complete it in this way. The result was, Gnumeric crashed immediately without comment, all unsaved changes were lost again: #+begin_quote Apr 03 13:16:16 acht kernel: gnumeric[12159]: segfault at 55b2e0b8c54c ip 7fb7c3a84153 sp 7ffd24a77340 error 4 in libspreadsheet-1.12.51.so[7fb7c398c000+1d2000] Apr 03 13:16:16 acht kernel: Code: 49 89 c5 e8 cf ea f0 ff 0f 1f 80 00 00 00 00 31 f6 4c 89 e2 48 89 ef e8 9b 10 f1 ff 85 c0 74 37 48 8b 74 24 08 48 85 db 74 19 <8b> 46 2c 3b 43 0c 7f dd 3b 43 04 7c d8 8b 46 283b 03 7c d1 3b 43 Apr 03 13:16:16 acht systemd[11794]: app-gnumeric-0fd51cc10ef74eb39119d727e1e1401d.scope: Consumed 1.657sCPU time. #+end_quote Dear Maintainer, thank you for your prompt update of the packages (to 1.12.51-1, which is called a "bugfix release" by the developers). I will go back to the last stable running version (1.12.48-1+b2) and use other spreadsheet programs for new tables. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 gnumeric depends on: ii debconf [debconf-2.0] 1.5.79 ii gnumeric-common1.12.51-1 ii gsfonts1:8.11+urwcyr1.0.7~pre44-4.5 ii libatk1.0-02.36.0-3 ii libc6 2.33-7 ii libcairo2 1.16.0-5 ii libgdk-pixbuf-2.0-02.42.8+dfsg-1 ii libglib2.0-0 2.72.0-1+b1 ii libgoffice-0.10-10 0.10.51-1 ii libgsf-1-114 1.14.47-1+b1 ii libgtk-3-0 3.24.33-1 ii libpango-1.0-0 1.50.6+ds-1 ii libpangocairo-1.0-01.50.6+ds-1 ii libxml22.9.13+dfsg-1 ii procps 2:3.3.17-7+b1 ii pxlib1 0.6.8-1+b1 ii zlib1g 1:1.2.11.dfsg-4 Versions of packages gnumeric recommends: ii evince42.1-1 ii gnumeric-doc 1.12.51-1 ii lp-solve 5.5.2.5-2 Versions of packages gnumeric suggests: ii fonts-liberation1:1.07.4-11 pn gnumeric-plugins-extra ii libgsf-1-dev1.14.47-1+b1 -- debconf-show failed
Bug#1008673: gnumeric: libspreadsheet-1.12.50.so segfault
Package: gnumeric Version: 1.12.50-1+b1 Severity: important Dear Maintainer, when duplicating "sheets", the following error occurs: #+begin_quote Mar 30 13:40:46 acht kernel: [159838.077521] gnumeric[2421]: segfault at d ip 7f04f693cce4 sp 7ffcbc947450 error 4 in libspreadsheet-1.12.50.so[7f04f683+1d2000] Mar 30 13:40:46 acht kernel: [159838.077530] Code: 85 c0 74 0c 49 8b 7e 30 e8 71 4f f0 ff 49 89 c6 8b 05 28 1f 38 00 4c 8b 6d 18 85 c0 0f 88 74 05 00 00 85 c0 0f 85 24 05 00 00 <41> 8b 45 08 85 c0 0f 84 ad 01 00 00 31 db 66 0f 1f 44 00 00 49 8b Mar 30 13:40:46 acht systemd[2050]: app-gnumeric-db9d25be35374dd386938b57a52db1fd.scope: Consumed 5.450s CPU time. #+end_quote I observe this already since the follow-up version of 1.12.48-*: #+begin_quote Nov 21 12:09:16 leto kernel: gnumeric[45594]: segfault at 55f5944f7b78 ip 7fba9eb79aa3 sp 7ffdecb203a0 error 4 in libspreadsheet-1.12.50.so[7fba9ea81000+1d3000] Nov 21 12:09:16 leto kernel: Code: 49 89 c5 e8 7f e1 f0 ff 0f 1f 80 00 00 00 00 31 f6 4c 89 e2 48 89 ef e8 3b 07 f1 ff 85 c0 7437 48 8b 74 24 08 48 85 db 74 19 <8b> 46 2c 3b 43 0c 7f dd 3b 43 04 7c d8 8b 46 28 3b 03 7c d1 3b 43 Nov 21 12:09:16 leto systemd[2856]: app-\x2fusr\x2fbin\x2fgnumeric-75f19003e98d42a9b880172bbf9b8ea1.scope: Consumed 10.684s CPUtime. Sep 09 07:40:04 leto kernel: gnumeric[108723]: segfault at 9 ip 7fb6d4cf8b24 sp 7ffc28e9aa60 error 4 in libspreadsheet-1.12.50.so[7fb6d4beb000+1d3000] Sep 09 07:40:04 leto kernel: Code: 85 c0 74 0c 49 8b 7e 30 e8 21 41 f0 ff 49 89 c6 8b 05 e8 20 38 00 4c 8b 6d 18 85 c0 0f 88 9c05 00 00 85 c0 0f 85 4c 05 00 00 <41> 8b 45 08 85 c0 0f 84 8d 01 00 00 31 db 66 0f 1f 44 00 00 49 8b #+end_quote Because Gnumeric now shows the same behavior not only on my older Intel PC but also on my new AMD, it can be assumed that it is a bug in the program. The error also occurred in the past when moving cells. I ask in the first step to update to the new version of Gnumeric. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 gnumeric depends on: ii debconf [debconf-2.0] 1.5.79 ii gnumeric-common1.12.50-1 ii gsfonts1:8.11+urwcyr1.0.7~pre44-4.5 ii libatk1.0-02.36.0-3 ii libc6 2.33-7 ii libcairo2 1.16.0-5 ii libgdk-pixbuf-2.0-02.42.6+dfsg-2 ii libglib2.0-0 2.72.0-1 ii libgoffice-0.10-10 0.10.50-1 ii libgsf-1-114 1.14.47-1+b1 ii libgtk-3-0 3.24.33-1 ii libpango-1.0-0 1.50.6+ds-1 ii libpangocairo-1.0-01.50.6+ds-1 ii libxml22.9.13+dfsg-1 ii procps 2:3.3.17-7+b1 ii pxlib1 0.6.8-1+b1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages gnumeric recommends: ii evince42.1-1 ii gnumeric-doc 1.12.50-1 ii lp-solve 5.5.2.5-2 Versions of packages gnumeric suggests: ii fonts-liberation1:1.07.4-11 pn gnumeric-plugins-extra ii libgsf-1-dev1.14.47-1+b1 -- debconf information: gnumeric/existing-process-title: gnumeric/existing-process: false
Bug#481468: memtest86+: Should not run update-grub unconditionally in postinst
Hi, On Tue, Feb 08, 2022 at 01:39:58PM +0100, Fabio Fantoni wrote: > Hi, /etc/kernel-img.conf seems specific options related to kernel so I don't > think is good do some additional condition based on it, I don't know other > similar option that can be used out of this. Well, first of all, I'm using update-grub nowadays -- so I don't personally care any more... To be honest, I didn't even remember filing this issue back then :-) Fundamentally, memtest behaves largely like a kernel image for most intents and purposes -- so using options from /etc/kernel-img.conf would make sense in principle... However, the options in question for disabling update-grub etc. seem to have been dropped altogether: which I guess is the source of the confusion here -- best I can tell, this bug is simply obsolete at this point... -antrik-
Bug#1005167: docker.io: Should start, not restart daemon on fresh install
Package: docker.io Version: 20.10.11+dfsg1-2+b1 Severity: normal X-Debbugs-Cc: Olaf Meeuwissen Dear Maintainer, When running `apt install docker.io` installation fails with [...] invoke-rc.d: initscript docker, action "restart" failed. dpkg: error processing package docker.io (--configure): installed docker.io package post-installation script subprocess returned error exit status 1 [...] Errors were encountered while processing: docker.io This happens because there is no daemon running yet that can be restarted. I cleaned up with invoke-rc.d docker start dpkg --configure docker.io but the post-install script should check whether it is a fresh install or upgrade to decide what should be done. Actually, I think even in the case of an upgrade it should check whether the daemon is running. If not, perhaps it should not start the daemon as it may have been stopped by the sysadmin for some reason. -- System Information: Distributor ID: Devuan Description:Devuan GNU/Linux 5 (daedalus/ceres) Release:5 Codename: daedalus ceres Architecture: x86_64 Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages docker.io depends on: ii adduser3.118 ii containerd 1.5.9~ds1-1 ii init-system-helpers1.60+devuan1 ii iptables 1.8.7-1 ii libc6 2.33-5 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libelogind0 [libsystemd0] 246.10-3 ii lsb-base 11.1.0 ii runc 1.0.3+ds1-1 ii tini 0.19.0-1 Versions of packages docker.io recommends: ii apparmor 3.0.3-6 ii ca-certificates 20210119 pn cgroupfs-mount ii git 1:2.34.1-1 pn needrestart pn xz-utils Versions of packages docker.io suggests: pn aufs-tools pn btrfs-progs pn debootstrap pn docker-doc ii e2fsprogs 1.46.5-2 pn rinse pn rootlesskit pn xfsprogs pn zfs-fuse | zfsutils-linux -- no debconf information Hope this helps, -- Olaf MeeuwissenFSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join
Bug#1003593: emacs-gtk: Displays Japanese using a Korean font
Package: emacs-gtk Version: 1:27.1+1-3.1+b1 Severity: normal X-Debbugs-Cc: Olaf Meeuwissen Dear Maintainer, While not really a major issue, this is something that's been bugging me for quite a while now and trying to get all applications on my "desktop" to use the same "Noto Sans Mono *" font I finally decided to chase this down. The problem is that certain Japanese characters look "weird". They are close to what they are supposed to look like but not quite. One simple and obvious example is 平. In Japanese it is supposed to look like - \ | / - | and on my x-terminal-emulator (rxvt-unicode) it does but in Emacs it displays as - / | \ - | Note how the slashes are transposed. This is just one example but there are quite a few other characters that don't quite look the way there supposed to. This issue gives Japanese text a somewhat "Chinese" look. Digging into this, and much to my surprise!, I found that Emacs actually selects a *Korean* font to display all Japanese (and Chinese too!). You can use `C-u C-x =` on the character to check the font that is used to display it. Feel free to explore the HELLO text (`C-h h`) if not using Emacs for mail to get some Japanese text in your buffer. The truly odd thing is that the Japanese characters are correctly identified as belonging to the appropriate JIS standard but displayed with a Korean font notwithstanding the fact that Japanese fonts are available (and used by my x-terminal-emulator, even with LANG=C.UTF-8). For reference, this happens when running emacs --no-init-file --no-site-file emacs --no-init-file emacs with my X session's LANG set to ja_JP.UTF-8 as well as C.UTF-8 and no Xresources applied. Using *font: Noto Sans Mono-16 doesn't change that. No matter what, Emacs insists on using -GOOG-Noto Sans CJK KR-normal-normal-normal-*-21-*-*-*-*-0-iso10646-1 apart from the font size (which defaults to 13 without the .Xresources setting; that's too small to be comfortable on my 31.5" monitor ;-). I have the following "font" packages installed: $ LANG=C apt list --installed 2>/dev/null | grep font fontconfig-config/testing,now 2.13.1-4.2 all [installed,automatic] fontconfig/testing,now 2.13.1-4.2 amd64 [installed,automatic] fonts-dejavu-core/testing,now 2.37-2 all [installed,automatic] fonts-noto-cjk/testing,now 1:20201206-cjk+repack1-1 all [installed] fonts-noto-color-emoji/testing,now 2.034-1 all [installed] fonts-noto-core/testing,now 20201225-1 all [installed] fonts-noto-mono/testing,now 20201225-1 all [installed] libfontconfig1/testing,now 2.13.1-4.2 amd64 [installed,automatic] libfontenc1/testing,now 1:1.1.4-1 amd64 [installed,automatic] libxfont2/testing,now 1:2.0.5-1 amd64 [installed,automatic] and the following Noto Sans Mono CJK fonts are available: $ fc-list | grep "Noto Sans Mono CJK" /usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc: Noto Sans Mono CJK TC:style=Bold /usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc: Noto Sans Mono CJK SC:style=Bold /usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc: Noto Sans Mono CJK KR:style=Bold /usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc: Noto Sans Mono CJK HK:style=Bold /usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc: Noto Sans Mono CJK JP:style=Bold /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: Noto Sans Mono CJK SC:style=Regular /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: Noto Sans Mono CJK TC:style=Regular /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: Noto Sans Mono CJK HK:style=Regular /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: Noto Sans Mono CJK KR:style=Regular /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: Noto Sans Mono CJK JP:style=Regular If I tell Emacs to use Noto Sans Mono CJK JP, the issue goes away but then Chinese and Korean text is also displayed using the JP variant instead of the Simplified Chinese (SC), Traditional Chinese (TC), Hong Kong Chinese (HK) or Korean (KR) one as appropriate. Hope this helps, -- System Information: Architecture: x86_64 Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages emacs-gtk depends on: ii emacs-bin-common 1:27.1+1-3.1+b1 ii emacs-common 1:27.1+1-3.1 ii libacl12.3.1-1 ii libasound2 1.2.5.1-1 ii libc6 2.33-1 ii libcairo2 1.16.0-5 ii libdbus-1-31.12.20-3+devuan3 ii libelogind0 [libsystemd0] 246.10-3 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.11.1+dfsg-1 ii libgdk-pixbuf-2.0-02.42.6+dfsg-2 ii libgif75.1
Bug#1003377: getmail6: Ignores netrc_file configuration settings
Package: getmail6 Version: 6.18.4-2 Severity: normal X-Debbugs-Cc: Olaf Meeuwissen Dear Maintainer, I tried moving my credentials to $HOME/.authinfo by setting use_netrc = true netrc_file = $HOME/.authinfo and removing the username and password from a working configuration file. That resulted in $ getmail --dump --rcfile=ucv Exception: please read docs/BUGS and include the following information in any bug report: getmail version 6.18.4 Python version 3.9.9 (main, Dec 16 2021, 23:13:29) [GCC 11.2.0] Unhandled exception follows: File "/usr/bin/getmail", line 799, in main netrc_object = netrc.netrc( File "/usr/lib/python3.9/netrc.py", line 29, in __init__ with open(file) as fp: FileNotFoundError: [Errno 2] No such file or directory: '/home/olaf/.netrc' Please also include configuration information from running getmail with your normal options plus "--dump". Checking upstream, I noticed that this has been fixed there already and the fix has been released as part of v6.18.6 (just a few hours ago ;-). Please upgrade to the latest version, thanks. -- System Information: Architecture: x86_64 Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages getmail6 depends on: ii python3 3.9.7-1 getmail6 recommends no packages. getmail6 suggests no packages. -- no debconf information -- Olaf MeeuwissenFSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join
Bug#1003265: devuan-installer: No support for runit as init on air-gapped installs
Package: devuan-installer Version: 5.0.preview-20211220 Severity: normal X-Debbugs-Cc: Olaf Meeuwissen Dear Maintainer, Playing with devuan_daedalus_5.0.preview-20211220_amd64_netinstall.iso I noticed that even though I select runit as my init system sysvinit-core gets installed. I've reported this behaviour before for chimaera in https://bugs.devuan.org/cgi/bugreport.cgi?bug=584 I realize that the netinstall images assume a network connection but for something as basic as the system's init I expected that to work without one. At the very least I expect to be notified that my selection is not available without a network connection. The runit-init package is a 30.9 kB download according to apt show so I would think that size is not a reason to not include it in the image. I have since replaced sysvinit-core with runit-init, which went without any trouble (unlike the case I experienced with chimaera). Just a apt install runit-init --purge reboot did the trick for my, at that point, still very, very bare bones system without a GUI. Here's hoping all supported init systems will be installable from the netinstall image without a network connection. -- System Information: Architecture: x86_64 Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled
Bug#1002454: python3.9-minimal: Package fails to install after upgrade from buster to bullseye
Package: python3.9-minimal Version: 3.9.2-1 Severity: grave When attempting to install python3.9-minimal on a system that has been upgraded from buster, during postinst a segmentation fault is reported and the scriptlet terminates with exit code 139. After extracting the postinst scriptlet and doing some testing with the half-installed package, I found out that the error is occurring in line 51 when some files are to be byte-compiled. Here the Python interpreter throws a segmentation fault (can easily be reproduced by extracting the postinst script and then manually executing it on the installed but not yet configured package). This, of course, breaks the installation of various components that are relying on Python like reportbug and certbot. Also, uninstalling everything that is part of Python and manually clearing any files and directories related to Python doesn't solve the issue, either, and the same error is still occurring. My system in use: Debian GNU/Linux 11.2 (bullseye) with bullseye-backports, kernel 5.14.9-2~bpo11+1, and libc6 2.31-13+deb11u2.
Bug#776029: udisks2: "Authentication is required to update SMART data" dialog repeated over and over again
Package: udisks2 Version: 2.9.4-1 Followup-For: Bug #776029 Dear Maintainer, Your program repeatedly asks for the root password via dialog under KDE, although I have already denied this. This is especially noticeable when switching between X servers. I can't uninstall this nonsense, because KDE depends on it. So please turn it off. Again, no means no. Thank you in advance! -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE:de:en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages udisks2 depends on: ii dbus 1.12.20-2 ii libacl12.3.1-1 ii libatasmart4 0.19-5 ii libblockdev-fs22.26-1 ii libblockdev-loop2 2.26-1 ii libblockdev-part2 2.26-1 ii libblockdev-swap2 2.26-1 ii libblockdev-utils2 2.26-1 ii libblockdev2 2.26-1 ii libc6 2.32-4 ii libglib2.0-0 2.70.0-1+b1 ii libgudev-1.0-0 237-2 ii libmount1 2.37.2-4 ii libpolkit-agent-1-00.105-31 ii libpolkit-gobject-1-0 0.105-31 ii libsystemd0249.5-1 ii libudisks2-0 2.9.4-1 ii libuuid1 2.37.2-4 ii parted 3.4-1 ii udev 249.5-1 Versions of packages udisks2 recommends: ii dosfstools 4.2-1 ii e2fsprogs1.46.4-1 ii eject2.37.2-4 ii exfatprogs 1.1.2-2 ii libblockdev-crypto2 2.26-1 ii libpam-systemd 249.5-1 ii ntfs-3g 1:2021.8.22-3 ii policykit-1 0.105-31 Versions of packages udisks2 suggests: ii btrfs-progs 5.14.1-1 ii f2fs-tools 1.14.0-2 pn libblockdev-mdraid2 pn mdadm pn nilfs-tools pn reiserfsprogs ii udftools 2.3-1 pn udisks2-bcache pn udisks2-btrfs pn udisks2-lvm2 pn udisks2-zram ii xfsprogs 5.13.0-1 -- debconf-show failed
Bug#996463: dolphin: Line breaks should be highlighted
Package: dolphin Version: 4:21.08.2-1 Severity: wishlist Dear Maintainer, my file system is XFS and as is well known XFS offers not only the hobby archivist extensive possibilities to name his files in a meaningful way. With the file manager Dolphin it happens to me again that line breaks creep in unintentionally when naming files, which comes partly from C&P as well as by further personal carelessness. Dolphin does not show these line breaks clearly and I only notice them in the terminal or when my backup program warns about them. The renaming of files with line breaks with the file manager Dolphin also does not succeed for me, because I cannot recognize the line breaks, here I still use the (zsh) shell, with which every conspicuousness immediately catches the eye. I would appreciate it if the developers could find and implement a way to make line breaks recognizable at least in the properties dialog. (Original: Mein Dateisystem ist XFS und bekanntermaßen bietet XFS nicht nur dem Hobby-Archivar umfangreiche Möglichkeiten seine Dateien aussagekräftig zu benennen. Mit dem Dateimanager Dolphin passiert es mir wieder, dass sich bei der Benennung von Dateien ungewollt Zeilenumbrüche einschleichen, was zum Teil von C&P wie auch durch weitere persönliche Achtlosigkeit kommt. Dolphin zeigt diese Zeilenumbrüche aber nicht deutlich an und mir fallen sie erst im Terminal auf oder wenn mein Backup-Programm diesbezüglich Warnungen ausgiebig. Die Umbenennung von Dateien mit Zeilenumbrüchen mit dem Dateimanager Dolphin gelingt mir ebenfalls nicht, weil ich die Zeilenumbrüche nicht erkennen kann, hier verwende ich nach wie vor die (zsh) Shell, womit jede Auffälligkeit umgehend ins Auge sticht. Ich wurde es begrüßen, wenn die Entwickler eine Möglichkeit finden und einbauen könnten, zumindest im Eigenschafte-Dialog Zeilenumbrüche kenntlich zu machen.) Thanks in advance! -- System Information: Debian Release: bookworm/sid APT prefers testing Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE:de:en_GB:en Shell: /bin/sh linked to /bin/dash Versions of packages dolphin depends on: ii baloo-kf5 5.86.0-1 ii kinit 5.86.0-1 ii kio 5.86.0-1 ii libc6 2.32-4 ii libdolphinvcs54:21.08.2-1 ii libkf5activities5 5.86.0-1 ii libkf5baloo5 5.86.0-1 ii libkf5baloowidgets5 4:21.08.0-1 ii libkf5bookmarks5 5.86.0-1 ii libkf5codecs5 5.86.0-1 ii libkf5completion5 5.86.0-1 ii libkf5configcore5 5.86.0-1 ii libkf5configgui5 5.86.0-1 ii libkf5configwidgets5 5.86.0-1 ii libkf5coreaddons5 5.86.0-1 ii libkf5crash5 5.86.0-1 ii libkf5dbusaddons5 5.86.0-1 ii libkf5filemetadata3 5.86.0-1 ii libkf5i18n5 5.86.0-1 ii libkf5iconthemes5 5.86.0-1 ii libkf5itemviews5 5.86.0-1 ii libkf5jobwidgets5 5.86.0-1 ii libkf5kcmutils5 5.86.0-1 ii libkf5kiocore55.86.0-1 ii libkf5kiofilewidgets5 5.86.0-1 ii libkf5kiogui5 5.86.0-1 ii libkf5kiowidgets5 5.86.0-1 ii libkf5newstuff5 5.86.0-3 ii libkf5notifications5 5.86.0-1 ii libkf5parts5 5.86.0-1 ii libkf5service-bin 5.86.0-1 ii libkf5service55.86.0-1 ii libkf5solid5 5.86.0-1 ii libkf5textwidgets55.86.0-1 ii libkf5widgetsaddons5 5.86.0-1 ii libkf5windowsystem5 5.86.0-1 ii libkf5xmlgui5 5.86.0-1 ii libkuserfeedbackcore1 1.0.0-3 ii libkuserfeedbackwidgets1 1.0.0-3 ii libpackagekitqt5-11.0.2-1 ii libphonon4qt5-4 4:4.11.1-4 ii libqt5core5a 5.15.2+dfsg-12 ii libqt5dbus5 5.15.2+dfsg-12 ii libqt5gui55.15.2+dfsg-12 ii libqt5widgets55.15.2+dfsg-12 ii libqt5xml55.15.2+dfsg-12 ii libstdc++611.2.0-8 ii phonon4qt54:4.11.1-4 Versions of packages dolphin recommends: ii ffmpegthumbs 4:21.08.0-1 ii kdegraphics-thumbnailers 4:21.08.0-1 ii kimageformat-plugins 5.86.0-1 ii kio-extras4:21.08.2-1 Versions of packages dolphin suggests: ii dolphin-plugins 4:21.08.0-1 -- no debconf information
Bug#994616: xfce4-power-manager: On 'suspend' : locking only occurs after resume
Package: xfce4-power-manager Version: 4.16.0-1 Severity: important Tags: none X-Debbugs-Cc: n...@kravcenko.com Dear Maintainer, On a Lenovo X260 runing Debain bulseye, the Power Manager settings are: "When laptop lid is closed: suspend" "Lock screen when system is going to sleep" When I close the lid, the computer suspends as required. When I open the lid again I see the unlocked session. Only after a few seconds, the screen is locked. I would have expected that the screen is locked before the suspend. I consider this bug serious since crucial data might be displayed to unauthorized persons. The bug seems to be known at XFCE, see https://bugzilla.xfce.org/show_bug.cgi?id=15929 A patch is provided there. This behaviour started after the upgrade from Debian buster to bullseye. With buster the problem did not occur. Kind regards and thanks for your nice work, Olaf -- System Information: Debian Release: 11.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-power-manager depends on: ii libc6 2.31-13 ii libcairo2 1.16.0-5 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 libnotify40.7.9-3 ii libpango-1.0-01.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libupower-glib3 0.99.11-2 ii libx11-6 2:1.7.2-1 ii libxext6 2:1.3.3-1.1 ii libxfce4ui-2-04.16.0-1 ii libxfce4util7 4.16.0-1 ii libxfconf-0-3 4.16.0-2 ii libxrandr22:1.5.1-1 ii upower0.99.11-2 ii xfce4-power-manager-data 4.16.0-1 Versions of packages xfce4-power-manager recommends: ii libpam-systemd [logind] 247.3-6 ii xfce4-power-manager-plugins 4.16.0-1 xfce4-power-manager suggests no packages.
Bug#994446: roundcube-core: SMTP error message 'SMTP auth failed (250)'
Am 16.09.2021 14:54, schrieb Guilhem Moulin: On Thu, 16 Sep 2021 at 14:46:34 +0200, Olaf Zaplinski wrote: Roundcube does authenticate to IMAP, but not to SMTP because it is not needed on localhost. The default is to use SMTP AUTH on localhost:587. This is not an RC bug. Does adding $config['smtp_user'] = ''; $config['smtp_pass'] = ''; to the configuration fixes the problem? I added it to my /etc/dovecot/local.conf => no. I mean to the *Roundcube* configuration (/etc/roundcube/config.inc.php)… OK, I definitely need more coffee... ;-) Sorry! Yes, I added $config['smtp_user'] = ''; $config['smtp_pass'] = ''; to config.inc-php, now it is working. Thank you!
Bug#994446: roundcube-core: SMTP error message 'SMTP auth failed (250)'
Package: roundcube Version: 1.4.11+dfsg.1-4 Severity: grave Justification: renders package unusable Dear Maintainer, on Debian 10, Roundcube worked as configured and could send emails to [::1]:25 without authentication as intended. Now on Debian 11, it says that 'SMTP error (250) authentication failed' or so (my system is set to German). The error message makes no sense. SMTP 250 reply code is 'ok'. This is what Postfix logged: Sep 16 08:19:17 binky postfix/smtpd[16110]: connect from ip6-localhost[::1] Sep 16 08:19:17 binky postfix/smtpd[16110]: disconnect from ip6-localhost[::1] ehlo=1 quit=1 commands=2 This is no Postfix problem: # telnet ::1 25 Trying ::1... Connected to ::1. Escape character is '^]'. 220 binky.tuxfriends.net ESMTP ehlo foo 250-binky.tuxfriends.net 250-PIPELINING 250-SIZE 5000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING mail from:<> 250 2.1.0 Ok rcpt to: 250 2.1.5 Ok data 354 End data with . Subject: test test . 250 2.0.0 Ok: queued as 6F2AD1FC57 quit 221 2.0.0 Bye Connection closed by foreign host. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages roundcube-core depends on: ii dbconfig-common 2.0.19 ii debconf [debconf-2.0] 1.5.77 ii dpkg 1.20.9 ii libapache2-mod-php7.4 [libapache2-mo 7.4.21-1+deb11u1 ii libjs-bootstrap4 4.5.2+dfsg1-7 ii libjs-codemirror 5.59.2+~cs0.23.109-1 ii libjs-jquery 3.5.1+dfsg+~3.5.5-7 ii libjs-jquery-minicolors 2.2.6+dfsg-4 ii libjs-jquery-ui 1.12.1+dfsg-8 ii libjs-jstimezonedetect1.0.6-5 ii libmagic1 1:5.39-3 ii php 2:7.4+76 ii php-auth-sasl 1.1.0-1 ii php-common2:76 ii php-intl 2:7.4+76 ii php-mail-mime 1.10.10-1 ii php-masterminds-html5 2.7.4+dfsg-2 ii php-mbstring 2:7.4+76 ii php-net-sieve 1.4.4-2 ii php-net-smtp 1.9.0-1 ii php-net-socket1.2.2-2 ii php-pear 1:1.10.12+submodules+notgz+20210212-1 ii php7.4 [php] 7.4.21-1+deb11u1 ii php7.4-cli [php-cli] 7.4.21-1+deb11u1 ii php7.4-intl [php-intl]7.4.21-1+deb11u1 ii php7.4-json [php-json]7.4.21-1+deb11u1 ii php7.4-mbstring [php-mbstring]7.4.21-1+deb11u1 ii roundcube-mysql 1.4.11+dfsg.1-4 ii ucf 3.0043 Versions of packages roundcube-core recommends: ii nginx-core [httpd-cgi] 1.18.0-6.1 ii nginx-full [httpd-cgi] 1.18.0-6.1 ii php-fpm 2:7.4+76 ii php-gd 2:7.4+76 pn php-pspell ii php7.4-fpm [php-fpm]7.4.21-1+deb11u1 ii php7.4-gd [php-gd] 7.4.21-1+deb11u1 Versions of packages roundcube-core suggests: pn php-crypt-gpg pn php-mkopinsky-zxcvbn-php pn php-net-ldap3 ii roundcube-plugins 1.4.11+dfsg.1-4 -- debconf information: roundcube/password-confirm: (password omitted) roundcube/mysql/admin-pass: (password omitted) roundcube/mysql/app-pass: (password omitted) roundcube/app-password-confirm: (password omitted) roundcube/missing-db-package-error: abort roundcube/upgrade-error: abort roundcube/remote/port: 3306 * roundcube/dbconfig-install: false roundcube/remove-error: abort roundcube/restart-webserver: true roundcube/internal/skip-preseed: false roundcube/passwords-do-not-match: roundcube/mysql/method: Unix socket roundcube/remote/host: localhost roundcube/mysql/authplugin: default roundcube/db/dbname: roundcube roundcube/install-error: abort roundcube/upgrade-backup: true roundcube/reconfigure-webserver: apache2, lighttpd roundcube/dbconfig-remove: true roundcube/internal/reconfiguring: false roundcube/db/app-user: roundcube/dbconfig-upgrade: true roundcube/purge: false roundcube/remote/newhost: roundcube/language: en_US roundcube/hosts: roundcube/database-type: mysql * roundcube/mysql/admin-user: root roundcube/dbconfig-reinstall: false
Bug#994439:
Sorry, I have sent this to the wrong package. Please reject this report.
Bug#994439: Acknowledgement (dovecot-core: SMTP auth failure on localhost [::1])
Sorry, I have sent this to the wrong package name. Please reject this report.
Bug#994439: dovecot-core: SMTP auth failure on localhost [::1]
Package: dovecot-core
Version: 1:2.3.13+dfsg1-2
Severity: grave
Justification: renders package unusable
Dear Maintainer,
on Debian 10, Dovecot worked as configured and could send emails to [::1]:25
without authentication.
Now on Debian 11, it says that 'SMTP error (250) authentication failed' or so
(my system is set to German).
This is what Postfix logged:
Sep 16 08:19:17 binky postfix/smtpd[16110]: connect from ip6-localhost[::1]
Sep 16 08:19:17 binky postfix/smtpd[16110]: disconnect from ip6-localhost[::1]
ehlo=1 quit=1 commands=2
This is no Postfix problem:
# telnet ::1 25
Trying ::1...
Connected to ::1.
Escape character is '^]'.
220 binky.tuxfriends.net ESMTP
ehlo foo
250-binky.tuxfriends.net
250-PIPELINING
250-SIZE 5000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
mail from:<>
250 2.1.0 Ok
rcpt to:
250 2.1.5 Ok
data
354 End data with .
Subject: test
test
.
250 2.0.0 Ok: queued as 6F2AD1FC57
quit
221 2.0.0 Bye
Connection closed by foreign host.
-- Package-specific info:
dovecot configuration
-
# 2.3.13 (89f716dc2): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.13 (cdd19fe3)
# OS: Linux 5.10.0-8-amd64 x86_64 Debian 11.0
# Hostname: binky.tuxfriends.net
auth_mechanisms = digest-md5 cram-md5
auth_username_format = %Ln
doveadm_password = # hidden, use -P to show it
login_greeting = IMAP ready.
mail_attribute_dict = file:%h/maildir/dovecot-attributes
mail_location = maildir:~/maildir
mail_privileged_group = mail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date index ihave duplicate
mime foreverypart extracttext
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
passdb {
args = scheme=CLEARTEXT /etc/dovecot/passwd
driver = passwd-file
}
plugin {
mail_replica = tcps:nanny.tuxfriends.net:8015
sieve = file:~/sieve;active=~/.dovecot.sieve
}
protocols = imap lmtp sieve
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
user = root
}
service doveadm {
inet_listener {
port = 8015
ssl = yes
}
}
service imap-login {
inet_listener imap {
address = 127.0.0.1, [::1]
port = 143
}
inet_listener imaps {
address = *, [::]
port = 993
}
}
service lmtp {
inet_listener lmtp {
address = ip6-localhost
port = 1025
}
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
process_min_avail = 0
service_count = 1
}
ssl_cert =
ii dovecot-imapd 1:2.3.13+dfsg1-2
pn dovecot-ldap
ii dovecot-lmtpd 1:2.3.13+dfsg1-2
pn dovecot-lucene
ii dovecot-managesieved 1:2.3.13+dfsg1-2
pn dovecot-mysql
pn dovecot-pgsql
pn dovecot-pop3d
ii dovecot-sieve 1:2.3.13+dfsg1-2
pn dovecot-solr
pn dovecot-sqlite
pn dovecot-submissiond
pn ntp
Versions of packages dovecot-core is related to:
ii dovecot-core [dovecot-common] 1:2.3.13+dfsg1-2
pn dovecot-dev
pn dovecot-gssapi
ii dovecot-imapd 1:2.3.13+dfsg1-2
pn dovecot-ldap
ii dovecot-lmtpd 1:2.3.13+dfsg1-2
ii dovecot-managesieved 1:2.3.13+dfsg1-2
pn dovecot-mysql
pn dovecot-pgsql
pn dovecot-pop3d
ii dovecot-sieve 1:2.3.13+dfsg1-2
pn dovecot-sqlite
-- no debconf information
Bug#994408: cdimage.debian.org: Buster non-free firmware image fails to detect wifi
Package: cdimage.debian.org Severity: important Tags: d-i Dear Maintainer, 1. in contrast to Linux Mint, the non-free iso does not detect my (popular) Realtek 8822CE wifi 2. non-free ISO is not available on german mirrors, so do not point us in that direction. I had to use the main server for downloading.
Bug#994289: fail2ban: On start and stop, emails go to root@localhost like it was on Debian 10, but also to nonexistant addresses set and escape:
Package: fail2ban
Version: 0.11.2-2
Severity: normal
Dear Maintainer,
please see this email bounce snippet:
Betreff [Fail2Ban] roundcube: started on binky.tuxfriends.net
Von root
An root@localhost, s...@binky.tuxfriends.net, esc...@binky.tuxfriends.net
Datum Heute 10:10
Hi,
The jail roundcube has been started successfully.
Regards,
Fail2Ban
-- System Information:
Debian Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'oldstable-updates'), (500,
'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages fail2ban depends on:
ii lsb-base 11.1.0
ii python3 3.9.2-3
Versions of packages fail2ban recommends:
ii nftables 0.9.8-3.1
ii python3-pyinotify 0.9.6-1.3
ii python3-systemd234-3+b4
ii whois 5.5.10
Versions of packages fail2ban suggests:
ii bsd-mailx [mailx]8.1.2-0.20180807cvs-2
pn monit
ii rsyslog [system-log-daemon] 8.2102.0-2
pn sqlite3
-- Configuration Files:
/etc/fail2ban/action.d/nftables-multiport.conf changed:
[INCLUDES]
before = nftables-common.local
[Definition]
nftables_mode = dport \{ \}
[Init]
/etc/fail2ban/fail2ban.conf changed:
[Definition]
loglevel = INFO
logtarget = /var/log/fail2ban.log
syslogsocket = auto
socket = /run/fail2ban/fail2ban.sock
pidfile = /run/fail2ban/fail2ban.pid
dbfile = /var/lib/fail2ban/fail2ban.sqlite3
dbpurgeage = 1d
-- no debconf information
Bug#992237: general: dpkg broken, so no security updates available
Package: general Severity: important Dear Maintainer, see below: Get:1 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB] Hit:2 http://deb.debian.org/debian bullseye InRelease Hit:3 http://deb.debian.org/debian bullseye-updates InRelease Hit:4 http://deb.debian.org/debian bullseye-backports InRelease Fetched 44.1 kB in 0s (93.7 kB/s) Reading package lists... Done Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@wp:~# dpkg -S /bin dpkg-query: no path found matching pattern /bin root@wp:~# dpkg -l root@wp:~# After upgrading to stable, dpkg does not know anything about installed packages. This means that security patches will not be installed.
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Package: libc6 Version: 2.31-13 Followup-For: Bug #990069 X-Debbugs-Cc: olafvds...@gmail.com Dear Maintainer, The original issue of not being able to open a new SSH connection during the upgrade still seems to be present. Greetings, Olaf -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libc6 depends on: ii libcrypt1 1:4.4.18-4 ii libgcc-s1 10.2.1-6 Versions of packages libc6 recommends: ii libidn2-0 2.3.0-5 ii libnss-nis 3.1-4 ii libnss-nisplus 1.3-4 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.77 pn glibc-doc ii libc-l10n 2.31-13 ii locales2.31-13 -- debconf information: glibc/disable-screensaver: glibc/kernel-not-supported: * libraries/restart-without-asking: true glibc/upgrade: true glibc/kernel-too-old: glibc/restart-services: glibc/restart-failed:
Bug#990069: closed by Debian FTP Masters (reply to Aurelien Jarno ) (Bug#990069: fixed in glibc 2.31-13)
Op di 6 jul. 2021 om 22:21 schreef Debian Bug Tracking System : > Changes: > glibc (2.31-13) unstable; urgency=medium > . >[ Colin Watson ] >* debian/debhelper.in/libc.postinst, script.in/nsscheck.sh: Look for > openssh-server package rather than ssh. Closes: #990069 Hi, I tried a buster -> unstable upgrade. While the upgrade is waiting for a response to "Restart services during package upgrades without asking?" ssh is still down. It seems to stay down until the end of the apt run. Greetings, Olaf Extracting templates from packages: 100% Preconfiguring packages ... (Reading database ... 31902 files and directories currently installed.) Preparing to unpack .../base-files_11.1_amd64.deb ... Unpacking base-files (11.1) over (10.3+deb10u10) ... Setting up base-files (11.1) ... Installing new version of config file /etc/debian_version ... Installing new version of config file /etc/dpkg/origins/debian ... Installing new version of config file /etc/issue ... Installing new version of config file /etc/issue.net ... Updating /etc/profile to current default. Updating /root/.profile to current default. (Reading database ... 31902 files and directories currently installed.) Preparing to unpack .../debianutils_4.11.2_amd64.deb ... Unpacking debianutils (4.11.2) over (4.8.6.1) ... Setting up debianutils (4.11.2) ... (Reading database ... 31902 files and directories currently installed.) Preparing to unpack .../archives/bash_5.1-3_amd64.deb ... Unpacking bash (5.1-3) over (5.0-4) ... Setting up bash (5.1-3) ... update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide /usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode (Reading database ... 31903 files and directories currently installed.) Preparing to unpack .../bsdmainutils_12.1.7+nmu3_all.deb ... renamed '/etc/default/bsdmainutils' -> '/etc/default/bsdmainutils.dpkg-remove' renamed '/etc/cron.daily/bsdmainutils' -> '/etc/cron.daily/bsdmainutils.dpkg-remove' Unpacking bsdmainutils (12.1.7+nmu3) over (11.1.2+b1) ... dpkg: warning: unable to delete old directory '/etc/calendar': Directory not empty Selecting previously unselected package bsdextrautils. Preparing to unpack .../bsdextrautils_2.36.1-7_amd64.deb ... Unpacking bsdextrautils (2.36.1-7) ... Selecting previously unselected package gcc-10-base:amd64. Preparing to unpack .../gcc-10-base_10.2.1-6_amd64.deb ... Unpacking gcc-10-base:amd64 (10.2.1-6) ... Setting up gcc-10-base:amd64 (10.2.1-6) ... Selecting previously unselected package libgcc-s1:amd64. (Reading database ... 31824 files and directories currently installed.) Preparing to unpack .../libgcc-s1_10.2.1-6_amd64.deb ... Unpacking libgcc-s1:amd64 (10.2.1-6) ... Replacing files in old package libgcc1:amd64 (1:8.3.0-6) ... Setting up libgcc-s1:amd64 (10.2.1-6) ... Selecting previously unselected package libcrypt1:amd64. (Reading database ... 31826 files and directories currently installed.) Preparing to unpack .../libcrypt1_1%3a4.4.18-4_amd64.deb ... Unpacking libcrypt1:amd64 (1:4.4.18-4) ... Replacing files in old package libc6:amd64 (2.28-10) ... Setting up libcrypt1:amd64 (1:4.4.18-4) ... (Reading database ... 31831 files and directories currently installed.) Preparing to unpack .../libc-l10n_2.31-13_all.deb ... Unpacking libc-l10n (2.31-13) over (2.28-10) ... Preparing to unpack .../locales_2.31-13_all.deb ... Unpacking locales (2.31-13) over (2.28-10) ... Selecting previously unselected package libcbor0:amd64. Preparing to unpack .../libcbor0_0.5.0+dfsg-2_amd64.deb ... Unpacking libcbor0:amd64 (0.5.0+dfsg-2) ... Selecting previously unselected package libfido2-1:amd64. Preparing to unpack .../libfido2-1_1.6.0-2_amd64.deb ... Unpacking libfido2-1:amd64 (1.6.0-2) ... Preparing to unpack .../libselinux1_3.1-3_amd64.deb ... Unpacking libselinux1:amd64 (3.1-3) over (2.8-1+b1) ... Setting up libselinux1:amd64 (3.1-3) ... (Reading database ... 31844 files and directories currently installed.) Preparing to unpack .../openssh-sftp-server_1%3a8.4p1-5_amd64.deb ... Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... Preparing to unpack .../openssh-client_1%3a8.4p1-5_amd64.deb ... Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... Selecting previously unselected package runit-helper. Preparing to unpack .../runit-helper_2.10.3_all.deb ... Unpacking runit-helper (2.10.3) ... Preparing to unpack .../openssh-server_1%3a8.4p1-5_amd64.deb ... Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... Preparing to unpack .../libc6_2.31-13_amd64.deb ... Checking for services that may need to be restarted... Checking init scripts... Unpacking libc6:amd64 (2.31-13) over (2.28-10) ... Setting up libc6:amd64 (2.31-13) ... Checking for services that may need to be restarted... Checking init scripts... Configuring libc6:amd64 --- There are services installed on your system w
Bug#990786: fonts-alegreya-sans: The "small caps" variant seems to be missing.
Package: fonts-alegreya-sans Version: 2.008-1 Severity: normal Dear Maintainer, please be so kind and check the fonts "Alegreya Sans SC". Thank you in advance! -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) -- no debconf information
Bug#990708: [debian-mysql] Bug#990708: Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
On Tue, Jul 6, 2021 at 1:19 AM Otto Kekäläinen wrote: > > On Mon, Jul 5, 2021 at 1:12 PM Olaf van der Spek wrote: > > > > On Mon, Jul 5, 2021 at 9:24 PM Otto Kekäläinen wrote: > > > I wish somebody could contribute with exact steps on how to reproduce > > > the issue. So far I've gotten some half attempts at that but they > > > haven't been actionable for me. > > > > Hi Otto, > > > > I'd point to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089 > > Not sure why it's not reproducible with those steps. > > I don't see *the* steps, but I see a lot of messages about many > different steps. If you have them, why not copy-paste the steps here > in email so I can copy-paste them into a Debian Buster Docker > container and run the upgrade to isolate the regression? Docker might be the problem, I'd try a real VM. I do have this in a VM so I think we can easily repro this. // Fresh VM install from debian-10.9.0-i386-netinst.iso # history 1 visudo 2 rm /etc/motd 3 poweroff 4 apt install mariadb-server 5 dpkg -l|grep mariadb 6 sed -i 's/buster/bullseye/g' /etc/apt/sources.list 7 apt update 8 apt upgrade 9 apt dist-upgrade // output below 10 dpkg -l|grep mariadb // output below 11 apt dist-upgrade // output below 12 history -- Olaf
Bug#990708: [debian-mysql] Bug#990708: Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch
On Mon, Jul 5, 2021 at 9:24 PM Otto Kekäläinen wrote: > I wish somebody could contribute with exact steps on how to reproduce > the issue. So far I've gotten some half attempts at that but they > haven't been actionable for me. Hi Otto, I'd point to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089 Not sure why it's not reproducible with those steps. Greetings, -- Olaf
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Op zo 4 jul. 2021 om 00:42 schreef Colin Watson : > Sorry for my delay - it took me a while to spot the problem. libc6's > postinst does arrange to restart services where needed, but in this case > it doesn't realize that you have the ssh service installed because you > only have the openssh-server package installed, not the ssh metapackage > (i.e. the package with the same name as the service). > > I've proposed > https://salsa.debian.org/glibc-team/glibc/-/merge_requests/3 to fix > this. glibc maintainers, if there's any way to get this into bullseye, > I'm sure it would help avoid some people upgrading remote systems ending > up being unable to fix them if something goes wrong between configuring > libc6 and configuring openssh-server. Also CCing debian-release for > their information, as I know it's pretty late for glibc changes. Thanks Colin! I assume openssh-server would then be restarted after the "There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded." question. But ssh is already 'down' when that question is being asked, so wouldn't there still be a time window, with required user interaction, where ssh would be 'down'? -- Olaf
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Op zo 20 jun. 2021 om 10:38 schreef Olaf van der Spek : > > So I think it's not accepting new connections from the start of the > upgrade run until the end: > Setting up openssh-sftp-server (1:8.4p1-5) ... > Setting up console-setup (1.203) ... > Setting up mime-support (3.66) ... > Setting up openssh-server (1:8.4p1-5) ... > Installing new version of config file /etc/init.d/ssh ... > Installing new version of config file /etc/ssh/moduli ... > Replacing config file /etc/ssh/sshd_config with new version > rescue-ssh.target is a disabled or a static unit, not starting it. Hi Colin, Any thoughts on this? -- Olaf
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
So I think it's not accepting new connections from the start of the upgrade run until the end: Setting up openssh-sftp-server (1:8.4p1-5) ... Setting up console-setup (1.203) ... Setting up mime-support (3.66) ... Setting up openssh-server (1:8.4p1-5) ... Installing new version of config file /etc/init.d/ssh ... Installing new version of config file /etc/ssh/moduli ... Replacing config file /etc/ssh/sshd_config with new version rescue-ssh.target is a disabled or a static unit, not starting it.
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Op za 19 jun. 2021 om 13:13 schreef Colin Watson : > > On Sat, Jun 19, 2021 at 12:53:48PM +0200, Olaf van der Spek wrote: > > During a Debian 10 -> 11 upgrade, the SSH server doesn't appear to be > > accepting new connections. IMO this is less than optimal, and not sure if > > this was always the case. > > Would it be possible to keep accepting connections, or at least to make the > > time window in which SSH is down as short as possible? FYI, this is when it's waiting for a reply to this question: Configuring libc6:amd64 | There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded. Since these restarts may cause interruptions | | of service for the system, you will normally be prompted on each upgrade for the list of services you wish to restart. You can choose this option to avoid being prompted; instead, all | | necessary restarts will be done for you automatically so you can avoid being asked questions on each library upgrade. | | | | Restart services during package upgrades without asking? $ ssh localhost kex_exchange_identification: read: Connection reset by peer Connection reset by ::1 port 22 /var/log/auth: Jun 20 10:00:43 alpha sshd[10140]: fatal: recv_rexec_state: buffer error: incomplete message > That's odd, because we already take care to do that. Any chance of some > logs? I think the most useful things would be /var/log/dpkg.log, 2021-05-09 10:03:01 status installed systemd:amd64 241-7~deb10u7 2021-06-20 09:40:28 startup archives unpack 2021-06-20 09:40:28 upgrade base-files:amd64 10.3+deb10u9 10.3+deb10u10 2021-06-20 09:40:28 status half-configured base-files:amd64 10.3+deb10u9 2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u9 2021-06-20 09:40:28 status half-installed base-files:amd64 10.3+deb10u9 2021-06-20 09:40:28 status triggers-pending man-db:amd64 2.8.5-2 2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u10 2021-06-20 09:40:28 startup packages configure 2021-06-20 09:40:28 configure base-files:amd64 10.3+deb10u10 2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u10 2021-06-20 09:40:28 status half-configured base-files:amd64 10.3+deb10u10 2021-06-20 09:40:28 status installed base-files:amd64 10.3+deb10u10 2021-06-20 09:40:28 startup archives unpack 2021-06-20 09:40:28 upgrade libgcrypt20:amd64 1.8.4-5 1.8.4-5+deb10u1 2021-06-20 09:40:28 status triggers-pending libc-bin:amd64 2.28-10 2021-06-20 09:40:28 status half-configured libgcrypt20:amd64 1.8.4-5 2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5 2021-06-20 09:40:28 status half-installed libgcrypt20:amd64 1.8.4-5 2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5+deb10u1 2021-06-20 09:40:28 startup packages configure 2021-06-20 09:40:28 configure libgcrypt20:amd64 1.8.4-5+deb10u1 2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5+deb10u1 2021-06-20 09:40:28 status half-configured libgcrypt20:amd64 1.8.4-5+deb10u1 2021-06-20 09:40:28 status installed libgcrypt20:amd64 1.8.4-5+deb10u1 2021-06-20 09:40:28 startup archives unpack 2021-06-20 09:40:28 upgrade libnettle6:amd64 3.4.1-1 3.4.1-1+deb10u1 2021-06-20 09:40:28 status half-configured libnettle6:amd64 3.4.1-1 2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1 2021-06-20 09:40:28 status half-installed libnettle6:amd64 3.4.1-1 2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 startup packages configure 2021-06-20 09:40:28 configure libnettle6:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status half-configured libnettle6:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status installed libnettle6:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 startup archives unpack 2021-06-20 09:40:28 upgrade libhogweed4:amd64 3.4.1-1 3.4.1-1+deb10u1 2021-06-20 09:40:28 status half-configured libhogweed4:amd64 3.4.1-1 2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1 2021-06-20 09:40:28 status half-installed libhogweed4:amd64 3.4.1-1 2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 startup packages configure 2021-06-20 09:40:28 configure libhogweed4:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status half-configured libhogweed4:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 status installed libhogweed4:amd64 3.4.1-1+deb10u1 2021-06-20 09:40:28 startup archives unpack 2021-06-20 09:40:29 upgrade libgnutls30:amd64 3.6.7-4+deb10u6 3.6.7-4+deb10u7 2021-06-20 09:40:29 status half-configured libgnutls30:amd64 3.6.7-4+deb10u6 2021-06-20 09:40:29 status unpacked libgnutls30:amd64 3.6.7-4+deb10u6 2021-06-20 09:40:29 status half-installed
Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Package: openssh-server Version: 1:8.4p1-5 Severity: normal Dear Maintainer, During a Debian 10 -> 11 upgrade, the SSH server doesn't appear to be accepting new connections. IMO this is less than optimal, and not sure if this was always the case. Would it be possible to keep accepting connections, or at least to make the time window in which SSH is down as short as possible? Greetings, Olaf -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) 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.118 ii debconf [debconf-2.0] 1.5.71 ii dpkg 1.19.7 ii libaudit1 1:2.8.4-3 iu libc6 2.31-12 ii libcom-err21.44.5-1+deb10u3 ii libcrypt1 1:4.4.18-4 ii libgssapi-krb5-2 1.17-3+deb10u1 ii libkrb5-3 1.17-3+deb10u1 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpam0g 1.3.1-5 ii libselinux13.1-3 ii libssl1.1 1.1.1d-0+deb10u6 ii libsystemd0241-7~deb10u7 ii libwrap0 7.6.q-28 ii lsb-base 10.2019051400 iu openssh-client 1:8.4p1-5 iu openssh-sftp-server1:8.4p1-5 ii procps 2:3.3.15-2 iu runit-helper 2.10.3 ii ucf3.0038+nmu1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 241-7~deb10u7 ii ncurses-term 6.1+20181013-2+deb10u2 ii xauth1:1.0.10-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn ssh-askpass pn ufw -- debconf information: openssh-server/permit-root-login: true openssh-server/password-authentication: true
Bug#988089: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11
Ib > Considering mariadb-client-core-10.3:amd64 -4 as a solution to mariadb-client-10.5:amd64 -1 Added mariadb-client-core-10.3:amd64 to the remove list Conflicts//Breaks against version 1:10.3.25-0+deb10u1 for mariadb-client-core-10.3 but that is not InstVer, ignoring MarkDelete mariadb-client-10.3:amd64 < 1:10.3.29-0+deb10u1 @ii mK Ib > FU=0 Fixing mariadb-client-10.5:amd64 via remove of mariadb-client-10.3:amd64 Fixing mariadb-client-10.5:amd64 via remove of mariadb-client-10.3:amd64 MarkDelete mariadb-client-core-10.3:amd64 < 1:10.3.29-0+deb10u1 @ii mK Ib > FU=0 Fixing mariadb-client-10.5:amd64 via remove of mariadb-client-core-10.3:amd64 Investigating (0) mariadb-server-10.5:amd64 < none -> 1:10.5.10-2 @un uN Ib > Broken mariadb-server-10.5:amd64 Depends on galera-4:amd64 < none | 26.4.8-1 @un uH > (>= 26.4) Considering galera-4:amd64 0 as a solution to mariadb-server-10.5:amd64 -1 MarkKeep mariadb-server-10.5:amd64 < none -> 1:10.5.10-2 @un uN Ib > FU=0 Holding Back mariadb-server-10.5:amd64 rather than change galera-4:amd64 Investigating (0) mariadb-server-core-10.5:amd64 < none -> 1:10.5.10-2 @un uN Ib > Broken mariadb-server-core-10.5:amd64 Conflicts on virtual-mysql-server-core:amd64 < none @un H > Considering mariadb-server-core-10.3:amd64 -3 as a solution to mariadb-server-core-10.5:amd64 -1 Added mariadb-server-core-10.3:amd64 to the remove list Conflicts//Breaks against version 1:10.3.25-0+deb10u1 for mariadb-server-core-10.3 but that is not InstVer, ignoring Broken mariadb-server-core-10.5:amd64 Breaks on mariadb-server-10.3:amd64 < 1:10.3.29-0+deb10u1 @ii mK Ib > Considering mariadb-server-10.3:amd64 -5 as a solution to mariadb-server-core-10.5:amd64 -1 Added mariadb-server-10.3:amd64 to the remove list Conflicts//Breaks against version 1:10.3.25-0+deb10u1 for mariadb-server-10.3 but that is not InstVer, ignoring Broken mariadb-server-core-10.5:amd64 Breaks on mariadb-server-core-10.3:amd64 < 1:10.3.29-0+deb10u1 @ii mK Ib > Considering mariadb-server-core-10.3:amd64 -3 as a solution to mariadb-server-core-10.5:amd64 -1 Added mariadb-server-core-10.3:amd64 to the remove list Conflicts//Breaks against version 1:10.3.25-0+deb10u1 for mariadb-server-core-10.3 but that is not InstVer, ignoring MarkDelete mariadb-server-core-10.3:amd64 < 1:10.3.29-0+deb10u1 @ii mK Ib > FU=0 Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-core-10.3:amd64 MarkDelete mariadb-server-10.3:amd64 < 1:10.3.29-0+deb10u1 @ii mK Ib > FU=0 Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-10.3:amd64 Fixing mariadb-server-core-10.5:amd64 via remove of mariadb-server-core-10.3:amd64 Investigating (1) mariadb-server:amd64 < 1:10.3.29-0+deb10u1 -> 1:10.5.10-2 @ii umU Ib > Broken mariadb-server:amd64 Depends on mariadb-server-10.5:amd64 < none | 1:10.5.10-2 @un uH > (>= 1:10.5.10-2) Considering mariadb-server-10.5:amd64 -1 as a solution to mariadb-server:amd64 0 MarkKeep mariadb-server:amd64 < 1:10.3.29-0+deb10u1 -> 1:10.5.10-2 @ii umU Ib > FU=0 Removing mariadb-server:amd64 rather than change mariadb-server-10.5:amd64 MarkDelete mariadb-server:amd64 < 1:10.3.29-0+deb10u1 | 1:10.5.10-2 @ii umH Ib > FU=0 Done Calculating upgrade... Done MarkDelete mariadb-client-10.5:amd64 < none -> 1:10.5.10-2 @un ugN > FU=0 MarkDelete mariadb-client-core-10.5:amd64 < none -> 1:10.5.10-2 @un ugN > FU=0 MarkDelete mariadb-server-core-10.5:amd64 < none -> 1:10.5.10-2 @un ugN > FU=0 The following packages were automatically installed and are no longer required: bsdmainutils galera-3 geoip-database libaio1 libbind9-161 libcgi-fast-perl libcgi-pm-perl libclone-perl libconfig-inifiles-perl libdbd-mysql-perl libdbi-perl libdns1104 libdns1110 libencode-locale-perl libfcgi-bin libfcgi-perl libfcgi0ldbl libgeoip1 libhtml-parser-perl libhtml-tagset-perl libhtml-template-perl libhttp-date-perl libhttp-message-perl libicu63 libio-html-perl libisc1100 libisc1105 libisccc161 libisccfg163 liblwp-mediatypes-perl liblwres161 libmariadb3 libmpdec2 libperl5.28 libpython2-stdlib libpython3.7-minimal libpython3.7-stdlib libreadline5 libreadline7 libsnappy1v5 libterm-readkey-perl libtimedate-perl liburi-perl mariadb-common mysql-common python2 python2-minimal python3.7 python3.7-minimal rsync socat Use 'apt autoremove' to remove them. The following packages will be REMOVED: libpython-stdlib mariadb-client-10.3 mariadb-client-core-10.3 mariadb-server mariadb-server-10.3 mariadb-server-core-10.3 python python-minimal The following packages will be upgraded: galera-3 libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib python2 python2-minimal python2.7 python2.7-minimal 8 upgraded, 0 newly installed, 8 to remove and 0 not upgraded. Need to get 4,856 kB of archives. After this operation, 157 MB disk space will be freed. Do you want to continue? [Y/n] n Abort. -- Olaf
Bug#989817: davmail: [PATCH] Configuration ignored when starting via init.d script
Package: davmail Version: 5.5.1.3299-4 Severity: normal X-Debbugs-Cc: none, Olaf Meeuwissen Dear Maintainer, I have been using Davmail on Devuan (Debian sans systemd) without any trouble until this morning when I wanted to check the login procedure in the logs. Making the relevant changes in the configuration file, /etc/davmail/davmail.properties, and restarting the service with sudo /etc/init.d/davmail restart I did not see any debug log messages in either of the logfiles that might be in use, /var/log/davmail.log according to the init.d script and /var/log/davmail/davmail.log in the configuration file. Some digging around revealed that the init.d script hasn't really been kept in sync with some of the changes made to service startup. The attached patch fixed things for me. The only thing to watch out for is keeping the logfile location in sync with the configuration file. # I made the change to DAEMON_USER earlier to get things to work after # the initial installation. BTW, I don't use a keystore file so didn't bother to add /usr/share/davmail/service-prepare to the start action. Perhaps that is needed as well. Or was that handled by ENABLE_DAEMON in the past? This variable no longer expands to anything as far as I could see. Hope this helps, -- System Information: Distributor ID: Devuan Description:Devuan GNU/Linux 4 (chimaera) Release:4 Codename: n/a Architecture: x86_64 Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages davmail depends on: ii adduser 3.118 ii default-jre-headless [java9-runtime-headless] 2:1.11-72 ii init-system-helpers 1.60+devuan1 ii jarwrapper0.78 ii libcommons-codec-java 1.15-1 ii libcommons-httpclient-java3.1-16 ii libcommons-logging-java 1.2-2 ii libhtmlcleaner-java 2.24-1 ii libhttpclient-java4.5.13-2 ii libjackrabbit-java2.18.0+r2.14.6-1 ii libjcifs-java 1.3.19-2 ii libjettison-java 1.4.1-1 ii liblog4j1.2-java 1.2.17-10 ii libmail-java 1.6.5-1 ii libservlet-api-java 4.0.1-2 ii libslf4j-java 1.7.30-1 ii libstax2-api-java 4.1-1 ii libwoodstox-java 1:6.2.1-1 ii logrotate 3.18.0-2 ii lsb-base 11.1.0 ii openjdk-11-jre-headless [java9-runtime-headless] 11.0.11+9-1 davmail recommends no packages. Versions of packages davmail suggests: pn libopenjfx-java pn libswt-cairo-gtk-4-jni pn libswt-gtk2-4-jni -- Configuration Files: /etc/davmail/davmail.properties changed: davmail.server=true davmail.mode=EWS davmail.url=https://outlook.office365.com/EWS/Exchange.asmx davmail.caldavPort=1080 davmail.imapPort=1143 davmail.ldapPort=1389 davmail.popPort=1110 davmail.smtpPort=1025 davmail.enableProxy=false davmail.useSystemProxies=false davmail.proxyHost= davmail.proxyPort= davmail.proxyUser= davmail.proxyPassword= davmail.noProxyFor= davmail.allowRemote=true davmail.bindAddress= davmail.clientSoTimeout= davmail.server.certificate.hash= davmail.ssl.nosecurecaldav=false davmail.ssl.nosecureimap=false davmail.ssl.nosecureldap=false davmail.ssl.nosecurepop=false davmail.ssl.nosecuresmtp=false davmail.disableUpdateCheck=true davmail.enableKeepAlive=true davmail.folderSizeLimit=0 davmail.defaultDomain= davmail.caldavAlarmSound= davmail.caldavPastDelay=90 davmail.caldavAutoSchedule=true davmail.forceActiveSyncUpdate=false davmail.imapAutoExpunge=true davmail.imapIdleDelay= davmail.imapAlwaysApproxMsgSize= davmail.keepDelay=30 davmail.sentKeepDelay=90 davmail.popMarkReadOnRetr=false davmail.smtpSaveInSent=true davmail.logFilePath=/var/log/davmail/davmail.log davmail.logFileSize=1MB log4j.logger.davmail=INFO log4j.logger.httpclient.wire=INFO log4j.logger.org.apache.commons.httpclient=INFO log4j.rootLogger=INFO /etc/init.d/davmail changed: PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="Davmail Exchange gateway" NAME=davmail DAEMON=/usr/bin/$NAME DAEMON_USER=_$NAME HOME=/var/lib/$DAEMON_USER PIDFILE=/var/run/$NAME.pid LOGFILE=/var/log/$NAME/$NAME.log SCRIPTNAME=/etc/init.d/$NAME [ -x "$DAEMON" ] || exit 0 DAEMON_ARGS="-server /etc/davmail/davmail.properties" if [ ! -r &
Bug#989307: DSA-4923-1: upgrading libwebkit2gtk-4.0-37 on buster pulls in xdg-desktop-portal
Hi Alberto, Alberto Garcia writes: > On Mon, Jun 07, 2021 at 08:52:32PM +0900, Olaf Meeuwissen wrote: >> >> Package changes: >> >> + fuse 2.9.9-1+deb10u1 amd64 >> >> + libpipewire-0.2-1 0.2.5-1 amd64 >> >> + xdg-desktop-portal 1.2.0-1 amd64 >> >> + xdg-desktop-portal-gtk 1.2.0-1 amd64 >> > >> > Yes, these are the actual new dependencies. >> >> Plus whatever these depend on that wasn't already installed. > > This is the complete list of extra dependencies pulled > by xdg-desktop-portal-gtk on a clean buster system with > libwebkit2gtk-4.0-37 but no other recommended packages installed. > > The following NEW packages will be installed: > fuse libfuse2 libpipewire-0.2-1 xdg-desktop-portal xdg-desktop-portal-gtk > >> > Future security updates and buster backports will Suggest >> > xdg-desktop-portal-gtk, although in bullseye it will still be a >> > recommendation. >> >> Good. I don't mind packages acquiring Recommends in testing/unstable. >> I do mind when that happens in stable-security. > > I understand, but note that although in this particular case it > shouldn't have been a Recommends, we cannot guarantee that in general. > The WebKit packages in Debian follow the upstream stable branches > and like all other major browser engines they have frequent security > updates. Thanks for the additional info. I understand that Debian's decision to follow upstreams for selected packages (all of them browser related IIRC) because backporting security fixes was not feasible may occasionally trigger installation of a new library package. That's fine. >> Bloat. >> Increased attack surface. > > Using xdg-desktop-portal-gtk is actually a consequence of the webkit > processes now running inside a sandbox for security reasons, so there > is a trade-off between not using the sandbox at all or using the > sandbox but recommending (not depending on) the portals. I chose the > latter. I see. Perhaps that could have been communicated in NEWS.Debian. Then at least I might have seen it explained during the upgrade. Even if I had opted not to include the Recommends:, I would have been able to make up my mind about adding them or not. Just a thought. >> Just let this be a warning for *all* stable-security packages to >> pay some extra attention to changing dependencies. If it's only >> changing versions of packages already depended upon, that _probably_ >> okay. New packages should raise a red flag. > > It was taken into account, and that one of the reasons why it was > downgraded to a recommendation (it was initially a dependency). Again, thanks for the extra info. -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join
Bug#989307: DSA-4923-1: upgrading libwebkit2gtk-4.0-37 on buster pulls in xdg-desktop-portal
Hi Alberto, Alberto Garcia writes: > On Sat, Jun 05, 2021 at 11:45:45AM +0900, Olaf Meeuwissen wrote: > >> In the mean time, I'll just `apt purge` the added packages. In my >> case these were the >> >> Package changes: >> + fuse 2.9.9-1+deb10u1 amd64 >> + libpipewire-0.2-1 0.2.5-1 amd64 >> + xdg-desktop-portal 1.2.0-1 amd64 >> + xdg-desktop-portal-gtk 1.2.0-1 amd64 > > Yes, these are the actual new dependencies. Plus whatever these depend on that wasn't already installed. I haven't really pruned my Recommends: but other folks may have. > Future security updates and buster backports will Suggest > xdg-desktop-portal-gtk, although in bullseye it will still be a > recommendation. Good. I don't mind packages acquiring Recommends in testing/unstable. I do mind when that happens in stable-security. > I don't think there's any better way to have those packages removed > automatically (certainly not a Conflicts, many people had them > installed anyway). Apart from a couple of MBs of extra used disk > space, is there anything particularly worrying you? Bloat. Increased attack surface. As far as libwebkit2gtk-4.0-37 is concerned, it happened and everyone that cares has to clean up manually. That's too bad. Just let this be a warning for *all* stable-security packages to pay some extra attention to changing dependencies. If it's only changing versions of packages already depended upon, that _probably_ okay. New packages should raise a red flag. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join
