Bug#1080079: apache2: Upgrade from Debian 11 to 12 seems to have enabled serve-cgi-bin.conf (security risk)
On 2024-08-30 17:03, Ondřej Surý wrote: I think that’s the problem - the script doesn’t only delete or create the symlinks, but it records whether admin or maintainer did the change, and honors the choice. Otherwise the package has no way to know whether the link is missing because of the upgrade or by mistake, and recreates the links. Ok, I checked the script again, and I can now indeed confirm it's registering the states in /var/lib/apache2/conf/ I now recreated the links manually, and then used the script to remove them. And indeed there's now new entries in /var/lib/apache2/conf/disabled_by_admin/ So this seems to be a layer 8 problem. Please close this ticket. And thank you for your help. smime.p7s Description: S/MIME Cryptographic Signature
Bug#1080079: apache2: Upgrade from Debian 11 to 12 seems to have enabled serve-cgi-bin.conf (security risk)
On 2024-08-30 12:58, Ondřej Surý wrote: your report is missing the information on **how** did you disabled serve-cgi-bin.conf? Ah, sorry. I manually deleted the link from conf-available/ to conf-enabled/. I later had some doubts whether I had asked for problems by doing so, I checked the a2disconf script, and if I'm not mistaken it basically does the same thing. In any case I didn't find evidence that the script "registered" this action somewhere, which would be the precondition for not "force-enabling" it later... smime.p7s Description: S/MIME Cryptographic Signature
Bug#1080079: apache2: Upgrade from Debian 11 to 12 seems to have enabled serve-cgi-bin.conf (security risk)
Package: apache2 Version: 2.4.61-1~deb12u1 Severity: important Dear Maintainer, I recently upgraded from Bullseye to Bookworm. Afterwards, I noticed that CGI scripts were active on the default host. I investigated it and found that the upgrade seemed to have re-enabled config-available/serve-cgi-bin.conf which I had intentionally disabled previously, because I didn't want to have CGI enabled globally, but rather enable it on a virtual host basis. This created a risk because now CGI scripts could be invoked thru the default host with no access restrictions. I believe there should be a mechanism that allows admins to permanently block certain config fragments, without Debian package config/upgrade mechanism interfering and re-enabling it. (I hope I'm not missing anything, I re-checked all default config files before posting this report. I chose not to include my modified config files, as they contain confidential info.) Thank you. Kind regards, Ralf -- Package-specific info: -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apache2 depends on: ii apache2-bin2.4.61-1~deb12u1 ii apache2-data 2.4.61-1~deb12u1 ii apache2-utils 2.4.61-1~deb12u1 ii init-system-helpers1.65.2 ii lsb-base 11.6 ii media-types10.0.0 ii perl 5.36.0-7+deb12u1 ii procps 2:4.0.2-3 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages apache2 recommends: pn ssl-cert Versions of packages apache2 suggests: ii apache2-doc 2.4.61-1~deb12u1 pn apache2-suexec-pristine | apache2-suexec-custom pn www-browser Versions of packages apache2-bin depends on: ii libapr1 1.7.2-3 ii libaprutil1 1.6.3-1 ii libaprutil1-dbd-sqlite3 1.6.3-1 ii libaprutil1-ldap 1.6.3-1 ii libbrotli1 1.0.9-2+b6 ii libc62.36-9+deb12u7 ii libcrypt11:4.4.33-2 ii libcurl4 7.88.1-10+deb12u6 ii libjansson4 2.14-2 ii libldap-2.5-02.5.13+dfsg-5 ii liblua5.3-0 5.3.6-2 ii libnghttp2-141.52.0-1+deb12u1 ii libpcre2-8-0 10.42-1 ii libssl3 3.0.13-1~deb12u1 ii libxml2 2.9.14+dfsg-1.3~deb12u1 ii perl 5.36.0-7+deb12u1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages apache2-bin suggests: ii apache2-doc 2.4.61-1~deb12u1 pn apache2-suexec-pristine | apache2-suexec-custom pn www-browser Versions of packages apache2 is related to: ii apache2 2.4.61-1~deb12u1 ii apache2-bin 2.4.61-1~deb12u1 -- Configuration Files: /etc/apache2/conf-available/security.conf changed [not included] /etc/apache2/mods-available/ssl.conf changed [not included] /etc/apache2/ports.conf changed [not included] /etc/apache2/sites-available/000-default.conf changed [not included] /etc/logrotate.d/apache2 changed [not included] -- no debconf information
Bug#1080056: systemd-timesyncd: system clock goes out of sync, despite service being enabled and active
Package: systemd-timesyncd Version: 256.4-3 Severity: normal Dear Maintainer, some time ago, syncing my Laptop clock seems to have stopped working. I can tell how it slowly drifts away from other, radio-controlled clocks in my apartment. This is despite systemd-timesync being set up for automatic synchronization: $ timedatectl Local time: Fr 2024-08-30 08:58:25 CEST Universal time: Fr 2024-08-30 06:58:25 UTC RTC time: Fr 2024-08-30 06:58:25 Time zone: Europe/Zurich (CEST, +0200) System clock synchronized: no NTP service: active RTC in local TZ: no $ systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled) Active: active (running) since Sun 2024-08-18 08:34:18 CEST; 1 week 5 days ago Invocation: 7bd1c1b03524445c8d9e2e6fcb5bb1ba Docs: man:systemd-timesyncd.service(8) Main PID: 978 (systemd-timesyn) Status: "Idle." Tasks: 2 (limit: 38086) Memory: 1.1M (peak: 3.4M swap: 824K swap peak: 944K) CPU: 3.364s CGroup: /system.slice/systemd-timesyncd.service └─978 /usr/lib/systemd/systemd-timesyncd Manually restarting systemd-timesyncd.service seems to trigger a sync. $ sudo systemctl restart systemd-timesyncd.service $ timedatectl Local time: Fr 2024-08-30 08:59:19 CEST Universal time: Fr 2024-08-30 06:59:19 UTC RTC time: Fr 2024-08-30 06:59:19 Time zone: Europe/Zurich (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no Note how "System clock synchronized" switched to "yes". Manual comparison with a radio-controlled clock also confirms that they are in sync now. But obviously, I shouldn't have to manually restart this service to get it to synchronize the clock. Unfortunately I have no idea how to even debug this. Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.10.3-amd64 (SMP w/20 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 systemd-timesyncd depends on: ii libc6 2.39-6 ii libsystemd-shared 256.4-3 ii systemd256.4-3 systemd-timesyncd recommends no packages. systemd-timesyncd suggests no packages. -- no debconf information
Bug#1077748: gnome-shell-extensions: Installing version 46.2-2 fails due to conflict on org.gnome.shell.extensions.system-monitor.gschema.xml
Package: gnome-shell-extensions Version: 46.2-2 Severity: important Dear Maintainer, an 'aptitude upgrade' on my system just failed with this error: dpkg: error processing archive /tmp/apt-dpkg-install-DPE8xz/72-gnome-shell-extensions_46.2-2_all.deb (--unpack): trying to overwrite '/usr/share/glib-2.0/schemas/org.gnome.shell.extensions.system-monitor.gschema.xml', which is also in package gnome-shell-extension-system-monitor 40-6 Errors were encountered while processing: /tmp/apt-dpkg-install-DPE8xz/72-gnome-shell-extensions_46.2-2_all.deb I am not entirely sure what this means, but maybe there's a missing conflict between the two packages? gnome-shell-extension-system-monitor was installed on my system but it was marked for removal as part of the same update. Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/20 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 gnome-shell-extensions depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b2 iu gir1.2-adw-1 1.5.2-1 ii gir1.2-atk-1.0 2.52.0-1 ii gir1.2-glib-2.0 2.80.4-1 ii gir1.2-gmenu-3.0 3.36.0-1.1+b2 ii gir1.2-graphene-1.0 1.10.8-3+b1 ii gir1.2-gtk-4.0 4.12.5+ds-6+b1 ii gir1.2-gtop-2.0 2.41.3-1+b1 ii gir1.2-pango-1.0 1.54.0+ds-1 iu gnome-session-bin46.0-5 iu gnome-settings-daemon46.0-5 iu gnome-shell 46.3.1-2 iu gvfs 1.54.2-1+b1 Versions of packages gnome-shell-extensions recommends: iu gnome-shell-extension-prefs 46.3.1-2 gnome-shell-extensions suggests no packages. -- no debconf information
Bug#1069089: ruby-rubygems: Broken platform detection which lead to unability to install sass-embedded
Hi, I think I am hitting a similar issue -- trying to install a bundle that contains the "ffi" gem leads to an error: Bundler::HTTPError: Could not download gem from https://rubygems.org/ due to underlying error (https://rubygems.org/gems/ffi-1.17.0-x86_64-linux.gem)> /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/rubygems_integration.rb:497:in `rescue in download_gem' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/rubygems_integration.rb:469:in `download_gem' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/source/rubygems.rb:481:in `download_gem' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/source/rubygems.rb:443:in `fetch_gem' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/source/rubygems.rb:427:in `fetch_gem_if_possible' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/source/rubygems.rb:161:in `install' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/installer/gem_installer.rb:54:in `install' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/installer/gem_installer.rb:16:in `install_from_spec' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/installer/parallel_installer.rb:156:in `do_install' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/installer/parallel_installer.rb:147:in `block in worker_pool' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/worker.rb:62:in `apply_func' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/worker.rb:57:in `block in process_queue' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/worker.rb:54:in `loop' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/worker.rb:54:in `process_queue' /usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/worker.rb:90:in `block (2 levels) in create_threads' Indeed the file https://rubygems.org/gems/ffi-1.17.0-x86_64-linux.gem does not exist. The correct filename seems to be https://rubygems.org/gems/ffi-1.17.0-x86_64-linux-gnu.gem. I don't know anything about Ruby, gem, or bundler so I am quite stuck here, and unable to execute Jekyll unfortunately. Kind regards, Ralf
Bug#1069089: ruby-rubygems: Broken platform detection which lead to unability to install sass-embedded
Hi again, Turns out I can fix things by manually editing /usr/lib/ruby/vendor_ruby/rubygems/platform.rb, and un-doing the patch mentioned at <https://github.com/jekyll/jekyll/issues/9478#issuecomment-1785797746>. But that's obviously quite the hack; would be nice if the faulty patch could be removed from the Debian package so that one can use bundler again. Kind regards, Ralf
Bug#1071988: radicale: After upgrade, radicale fails to serve calendar: An exception occurred during GET request
Dear Jonas, Thanks for taking a look! Yeah I reported this upstream in the mean time: <https://github.com/Kozea/Radicale/issues/1498> Kind regards, Ralf
Bug#1071988: radicale: After upgrade, radicale fails to serve calendar: An exception occurred during GET request
Package: radicale Version: 3.2.0-1 Severity: grave Justification: causes non-serious data loss Dear Maintainer, after upgrading radicale, my devices are no longer able to access my calendar. The same calendar worked perfectly fine before the upgrade. I am seeing errors like this in the log: Mai 27 08:48:39 r-ethtop radicale[313128]: [313128/Thread-15 (process_request_thread)] [ERROR] An exception occurred during PROPFIND request on '/ralfj/kalender.cal/': Failed to load item '87a651b3-153b-46e5-bd26-d9fa5beb21b8.ics' in 'ralfj/kalender.cal': At line 32: Failed to parse line: \n Mai 27 08:49:29 r-ethtop radicale[313128]: [313128/Thread-18 (process_request_thread)] [ERROR] An exception occurred during PROPFIND request on '/ralfj/kalender.cal/': Failed to load item '87a651b3-153b-46e5-bd26-d9fa5beb21b8.ics' in 'ralfj/kalender.cal': At line 32: Failed to parse line: \n Mai 27 08:49:41 r-ethtop radicale[313128]: [313128/Thread-19 (process_request_thread)] [ERROR] An exception occurred during PROPFIND request on '/ralfj/kalender.cal/': Failed to load item '87a651b3-153b-46e5-bd26-d9fa5beb21b8.ics' in 'ralfj/kalender.cal': At line 32: Failed to parse line: \n Looks like I now have to try to manually repair the internal data storage, or something like that. This calendar was only ever managed by radicale itself, so if past versions of radicale created invalid calendar entries then future versions shouldn't make that the admin's problem. Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/20 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 radicale depends on: ii adduser3.137 ii init-system-helpers1.66 ii python33.11.8-1 ii python3-radicale 3.2.0-1 ii sysvinit-utils [lsb-base] 3.09-1 Versions of packages radicale recommends: ii ssl-cert 1.1.2 Versions of packages radicale suggests: pn apache2 pn apache2-utils pn libapache2-mod-proxy-uwsgi ii python3-bcrypt 3.2.2-1 ii python3-passlib 1.7.4-4 pn uwsgi pn uwsgi-plugin-python3 -- Configuration Files: /etc/radicale/config changed [not included] /etc/radicale/rights changed [not included] -- no debconf information
Bug#1070863: inkscape: "Import Web Image" fails with ModuleNotFoundError: No module named 'appdirs'
Package: inkscape Version: 1.2.2-2+b3 Severity: normal Dear Maintainer, to reproduce, simply click File - Import Web Image. I then get an error dialog showing a Python exception: Traceback (most recent call last): File "/usr/share/inkscape/extensions/other/clipart/import_web_image.py", line 35, in from appdirs import user_cache_dir ModuleNotFoundError: No module named 'appdirs' Looks like maybe a dependency on python3-appdirs is missing? Once I install that, I get another error about importing 'cachecontrol'. After also installing python3-cachecontrol, the import web window finally appears. Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/20 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 inkscape depends on: ii lib2geom1.2.0 1.2.2-3 ii libatkmm-1.6-1v5 2.28.4-1 ii libboost-filesystem1.83.0 1.83.0-2+b2 ii libc6 2.37-15 ii libcairo-gobject2 1.18.0-1+b1 ii libcairo2 1.18.0-1+b1 ii libcairomm-1.0-1v5 1.14.5-1 ii libcdr-0.1-1 0.1.7-1 ii libfontconfig1 2.15.0-1.1 ii libfreetype6 2.13.2+dfsg-1+b1 ii libgc1 1:8.2.6-1 ii libgcc-s1 14-20240201-3 ii libgdk-pixbuf-2.0-02.42.10+dfsg-3+b1 ii libglib2.0-0 2.78.4-1 ii libglibmm-2.4-1v5 2.66.6-2+b1 ii libgomp1 14-20240201-3 ii libgsl27 2.7.1+dfsg-6+b1 ii libgspell-1-2 1.12.2-1+b1 ii libgtk-3-0 3.24.41-1 ii libgtkmm-3.0-1v5 3.24.8-2+b1 ii libharfbuzz0b 8.3.0-2 ii libjpeg62-turbo1:2.1.5-2+b2 ii liblcms2-2 2.14-2+b1 ii libmagick++-6.q16-98:6.9.12.98+dfsg1-5+b1 ii libpango-1.0-0 1.52.0+ds-1 ii libpangocairo-1.0-01.52.0+ds-1 ii libpangoft2-1.0-0 1.52.0+ds-1 ii libpangomm-1.4-1v5 2.46.4-1 ii libpng16-161.6.43-1 ii libpoppler-glib8 22.12.0-2+b1 ii libpoppler126 22.12.0-2+b1 ii libpotrace01.16-2+b1 ii libreadline8 8.2-3+b1 ii librevenge-0.0-0 0.0.5-3 ii librsvg2-common2.54.7+dfsg-2 ii libsigc++-2.0-0v5 2.12.1-1 ii libsoup2.4-1 2.74.3-3 ii libstdc++6 14-20240201-3 ii libvisio-0.1-1 0.1.7-1+b3 ii libwpg-0.3-3 0.3.4-3 ii libx11-6 2:1.8.7-1 ii libxml22.9.14+dfsg-1.3+b2 ii libxslt1.1 1.1.35-1 ii python33.11.6-1 ii zlib1g 1:1.3.dfsg-3+b1 Versions of packages inkscape recommends: ii aspell 0.60.8.1-1+b1 ii fig2dev 1:3.2.9-3 ii imagemagick 8:6.9.12.98+dfsg1-5+b1 ii imagemagick-6.q16 [imagemagick] 8:6.9.12.98+dfsg1-5+b1 ii libimage-magick-perl 8:6.9.12.98+dfsg1-5 ii libwmf-bin 0.2.13-1.1 ii python3-cssselect1.2.0-2 ii python3-lxml 5.1.0-1 ii python3-numpy1:1.24.2-2 ii python3-scour0.38.2-4.1 Versions of packages inkscape suggests: pn dia pn inkscape-tutorials pn libsvg-perl pn pstoedit ii python3-packaging 24.0-1 pn python3-uniconvertor ii ruby 1:3.1 -- no debconf information
Bug#1068738: gfeeds: python failure at startup
Package: gnome-feeds Version: 2.2.0-2 Severity: grave Hello, after a recent dist-upgrade to unstable, gfeeds crashes at startup. This makes the package unusable. -Ralf. % gfeeds Traceback (most recent call last): File "/usr/bin/gfeeds", line 75, in from gfeeds import __main__ File "/usr/lib/python3/dist-packages/gfeeds/__main__.py", line 9, in from gfeeds.app_window import GFeedsAppWindow File "/usr/lib/python3/dist-packages/gfeeds/app_window.py", line 2, in from gfeeds.main_leaflet import MainLeaflet File "/usr/lib/python3/dist-packages/gfeeds/main_leaflet.py", line 11, in from gfeeds.webview import GFeedsWebView File "/usr/lib/python3/dist-packages/gfeeds/webview.py", line 4, in from gfeeds.util.build_reader_html import build_reader_html File "/usr/lib/python3/dist-packages/gfeeds/util/build_reader_html.py", line 4, in from gfeeds.util.readability_wrapper import RDoc File "/usr/lib/python3/dist-packages/gfeeds/util/readability_wrapper.py", line 3, in from readability.readability import * File "/usr/lib/python3/dist-packages/readability/__init__.py", line 3, in from .readability import Document File "/usr/lib/python3/dist-packages/readability/readability.py", line 11, in from .cleaners import clean_attributes File "/usr/lib/python3/dist-packages/readability/cleaners.py", line 3, in from lxml.html.clean import Cleaner File "/usr/lib/python3/dist-packages/lxml/html/clean.py", line 18, in raise ImportError( ImportError: lxml.html.clean module is now a separate project lxml_html_clean. Install lxml[html_clean] or lxml_html_clean directly. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/4 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 gnome-feeds depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b2 ii gir1.2-adw-1 1.5.0-1 ii gir1.2-webkit-6.02.44.1-1 ii python3 3.11.8-1 ii python3-arrow1.3.0-1 ii python3-bs4 4.12.3-1 ii python3-feedparser 6.0.10-1 ii python3-gi 3.48.2-1 ii python3-html5lib 1.1-6 ii python3-humanize 4.9.0-1 ii python3-listparser 0.18-3 ii python3-lxml 5.2.1-1 ii python3-magic2:0.4.27-3 ii python3-pil 10.3.0-2 ii python3-pygments 2.17.2+dfsg-1 ii python3-readability 0.8.1+dfsg1-3 ii python3-requests 2.31.0+dfsg-1 ii python3-syndom 1.0-2 ii python3-tz 2024.1-2 ii xdg-utils1.1.3-4.1 gnome-feeds recommends no packages. gnome-feeds suggests no packages. -- no debconf information
Bug#1067887: x11-utils: xmessage text area becomes smaller and smaller the more buttons are defined
Package: x11-utils Version: 7.7+5 Severity: normal X-Debbugs-Cc: rst...@gmx.net Dear Maintainer, * What led up to the situation? - I need to alert users to certain actions and give them the option to pause or delay those actions for a limited period of time. Due to a wide variety of desktops (KDE, Gnome, Enlightenment, Fluxbox, WindowMaker, ...) I have to resort to the lowest common denominator: xmessage. - It turned out that the more buttons an xmessage box has, the smaller the text field to display the message becomes. Enlarging or reducing the box (to force a redraw) doesn't help. * What exactly did you do (or not do) that was effective (or ineffective)? - I DID cross-check the behaviour on other distributions (opensuse 15.5, opensuse tumbleweed, ubuntu 22.04 LTS, ubuntu 24.04 LTS). - I did NOT install 'x11-utils' from 'unstable' or 'sid' to cross-check behaviour with version 7.7+6. - I tested with: - xmessage -title "Reminder" -buttons Ok:0,"Snooze (+1min)":1,"Snooze (+5min)":3,"Snooze (Custom)":4 -default Ok -nearmouse -geometry 300x100 "Do not forget!" - xmessage -title "Reminder" -buttons Ok:0,"Snooze (+1min)":1,"Snooze (+5min)":3 -default Ok -nearmouse -geometry 300x100 "Do not forget!" - xmessage -title "Reminder" -buttons Ok:0,"Snooze (+1min)":1 -default Ok -nearmouse -geometry 300x100 "Do not forget!" - xmessage -title "Reminder" -buttons Ok:0 -default Ok -nearmouse -geometry 300x100 "Do not forget!" * What was the outcome of this action? - 'xmessage' behaves the same way on suse and ubuntu -- System Information: Debian Release: 11.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-28-amd64 (SMP w/4 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages x11-utils depends on: ii libc6 2.31-13+deb11u8 ii libfontconfig1 2.13.1-4.2 ii libfontenc1 1:1.1.4-1 ii libgl1 1.3.2-1 ii libx11-62:1.7.2-1+deb11u2 ii libx11-xcb1 2:1.7.2-1+deb11u2 ii libxaw7 2:1.0.13-1.1 ii libxcb-shape0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxext62:1.3.3-1.1 ii libxft2 2.3.2-2 ii libxi6 2:1.7.10-1 ii libxinerama12:1.1.4-2 ii libxkbfile1 1:1.1.0-1 ii libxmu6 2:1.1.2-2+b3 ii libxmuu12:1.1.2-2+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxt6 1:1.2.0-1 ii libxtst62:1.2.3-1 ii libxv1 2:1.0.11-1 ii libxxf86dga12:1.1.4-1+b3 ii libxxf86vm1 1:1.1.4-1+b2 x11-utils recommends no packages. Versions of packages x11-utils suggests: pn mesa-utils -- no debconf information
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
Hi all, Fedora and Ubuntu [1] have now enabled frame pointers on amd64 by default, providing a great profiling experience out-of-the-box. I think it may be time for Debian to reconsider its position here; the performance overhead is very small and meanwhile this lack of frame pointers is preventing other, much more significant performance improvements by making it hard or impossible to properly profile applications. [1]: https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame-pointers-by-default Kind regards, Ralf
Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
On Tue, Feb 27, 2024 at 08:50:48AM +, Richard Lewis wrote:
> thanks - agree logcheck should cope with a default rsyslog output. ... i
> just dont know what that default output is: does the below mean the
> subseconds are now always present?
>
> or: what regexp should logcheck use as prefix?
According to RFC 3339 everything from no subseconds to 6 subsecond
digits can be present (which is seven chars including the decimal dot).
So far (in the wild) I've seen only the two variants with no subseconds
or with 6 subsecond digits. But anything between these is possible.
I've already suggested to modify the regex for the timestamp part from
^(\w{3} [ :0-9]{11}|[0-9T:.+-]{32})
to
^(\w{3} [ :0-9]{11}|[0-9T:.+-]{25,32})
That would match the two extremes (with/without sub-seconds) but would
also cope with anything in between (which is legal according to the
RFCs). The first part would continue to match the "traditional" syslog
format. This is also in wide use today.
Thanks
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: www.runtux.com
Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
On Thu, Feb 22, 2024 at 07:01:05PM +, Richard Lewis wrote:
> >
> > So I guess that logcheck should be prepared to receive both kinds of
> > timestamps, the 32-byte version and the 25-byte version (without the
> > subseconds timestamp).
>
> what is the default, and does logcheck cope with that? there's a limit to
> how much to suport out of the box - especially as rsyslog is no longer the
> default.
The current default of Debians rsyslog (after a long time where it was
the 'traditional' format) it is now RFC 3339 timestamps. This comes in
two variants, with or without the sub-seconds part. Logcheck only
supports the variant *with* sub-seconds.
By default, logcheck supports the 'traditional' format and the 32-byte
header, the pattern in most logcheck rules is
^(\w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32})
The first alternative matched by this is something like
Feb 18 00:01:36
while the second is
2024-02-16T20:59:34.218904+01:00
The short form also produced by rsyslog is
2024-02-16T22:06:02+01:00
The third (short) form with no sub-seconds part is currently not matched
by logcheck.
You might want to simply set the match pattern to
^(\w{3} [ :[:digit:]]{11}|[0-9T:.+-]{25,32})
Although rsyslog would probably never produce it, RFC 3339 allows the
sub-seconds part to be short (min 1 digit). There is no maximum in RFC
3339 but RFC 5424 prohibits more than 6 digits:
https://datatracker.ietf.org/doc/html/rfc5424#section-6.2.3.1
For RFC 3339 see p.7 section 5.6 in
https://www.rfc-editor.org/rfc/rfc3339#section-5.6
So it makes sense to match a range of lengths.
> if you configure a logger to produce a certain format it's not unreasonable
> to also have to edit logcheck rules accordingly
I'm talking about the new Debian rsyslog package's default.
And, yes, but that would mean to edit logcheck rules for each installed
package? And the new default of the rsyslog package is the two variants
of RFC 3339. Unfortunately the default for remote logging does *not*
transmit the sub-seconds part. So you end up with two timestamp formats
in the same logfile. Which is fine according to the syslog standard in
RFC 5424.
> But a longer-term solution is perhaps to allow easier customisation of
> rules via "macros"/variables --- a proof-of-concept for this is in
> progress, but not.yet ready for testing
Nice!
Thanks
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: www.runtux.com
Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064385: rsyslog: New default log format is different for local and remote log
On Thu, Feb 22, 2024 at 12:17:58PM +0100, Michael Biebl wrote: > > Reading through the upstream bug report, they basically agree that this is a > logcheck issue which should handle RFC 3339 timestamps more robustly. > Do you plan to raise this issue with the logcheck maintainers? > As I'm not a logcheck user, I don't plan to do that myself. Yes, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064395 Thanks Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
On Wed, Feb 21, 2024 at 02:52:33PM +0100, Ralf Schlatterbeck wrote: > > I forgot to mention: > There is an upstream (rsyslog) bug-report at > https://github.com/rsyslog/rsyslog/issues/5332 Upstream has decided that it is not a bug and that both timestamp formats are valid RFC 3339 (I've checked, the grammar explicitly defines the sub-seconds part of the timestamp as optional). See link above. They also think, logcheck should cope with both formats. So I guess that logcheck should be prepared to receive both kinds of timestamps, the 32-byte version and the 25-byte version (without the subseconds timestamp). In the downstream bug-report of rsylogd (which I suppose will be closed soon) I've mentioned how to configure remote clients to send a timestamp *with* sub-seconds part. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064385 But there may be other clients out there (which may not be rsyslogd) which still send the traditional format and thus will be logged without a subseconds part. So logcheck should be prepared to receive both formats. Thanks Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064385: rsyslog: New default log format is different for local and remote log
Upstream has decided that it is not a bug and that the RFC 3339 timestamps can in fact freely mix timestamps with or without the sub-seconds part (I've checked, the RFC explicitly has the subseconds part defined as optional in the grammar). For people coming here to look: I've successfully modified my remote client rsyslog configuration to send *long* timestamps to the remote syslog. The default configuration seems to use RSYSLOG_TraditionalForwardFormat (I didn't find much info about which template formats are built into rsyslog and what they do, I've used 'strings' and 'grep' to find out). The RSYSLOG_ForwardFormat formats forwarded messages *with* sub-seconds part. So instead of, e.g., *.*;auth,authpriv.none@syslog:514 you specify a format: auth,authpriv.* @syslog:514;RSYSLOG_ForwardFormat which transmits the sub-seconds part to the receiving rsyslog. So I think we can close this. Thanks, Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
On Wed, Feb 21, 2024 at 02:24:03PM +0100, Ralf Schlatterbeck wrote: > > Local log lines include the sub-seconds part like: > 2024-02-16T22:05:52.315463+01:00 tux [...] > > while remote logs (in that case from virtual machines on the same host) do not > include the sub-seconds part: > 2024-02-16T22:06:02+01:00 tux1 [...] > > Logcheck currently deals only with the first format. This results in no > logcheck pattern matching for remote host log entries. I forgot to mention: There is an upstream (rsyslog) bug-report at https://github.com/rsyslog/rsyslog/issues/5332 And a debian bug report for rsyslog at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064385 Thanks Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version
Package: logcheck Version: 1.4.2 Severity: normal Dear Maintainer, rsyslogd currently produces two different timestamp formats at the start of a log line with the default (now also Debian default) rfc3339 format. Local log lines include the sub-seconds part like: 2024-02-16T22:05:52.315463+01:00 tux [...] while remote logs (in that case from virtual machines on the same host) do not include the sub-seconds part: 2024-02-16T22:06:02+01:00 tux1 [...] Logcheck currently deals only with the first format. This results in no logcheck pattern matching for remote host log entries. Fortunately logcheck also still supports the 'traditional' format which I've reverted to. I would expect rsyslog to only use a single format, but failing that I think that logcheck should not drop support for the old 'traditional' timestamp format until the issue in rsyslogd is resolved. Logcheck *may* want to support both rfc3339 formats (the sub-seconds part *is* optional in the RFC). -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.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 logcheck depends on: ii adduser 3.134 ii cron [cron-daemon] 3.0pl1-162 ii lockfile-progs 0.1.19 ii logtail 1.4.2 ii mime-construct 1.12+really1.11-1 ii postfix [mail-transport-agent] 3.7.10-0+deb12u1 Versions of packages logcheck recommends: ii logcheck-database 1.4.2 Versions of packages logcheck suggests: ii rsyslog [system-log-daemon] 8.2302.0-1 -- Configuration Files: /etc/logcheck/logcheck.logfiles changed [not included] -- no debconf information
Bug#1064385: rsyslog: New default log format is different for local and remote log
Hi Michael, Thanks for the quick answers! On Wed, Feb 21, 2024 at 01:30:50PM +0100, Michael Biebl wrote: > The Debian package does not ship any patches in that regard. > It's thus best if you raise this issue directly upstream at > https://github.com/rsyslog/rsyslog/issues I've made an upstream bug-report on the issue at https://github.com/rsyslog/rsyslog/issues/5332 On Wed, Feb 21, 2024 at 01:40:21PM +0100, Michael Biebl wrote: > Am 21.02.24 um 12:09 schrieb Ralf Schlatterbeck: > > Unfortunately this causes logcheck to completely ignore all the remote logs > > because it matches on a 32-byte timestamp (and the timestamp of the remote > > machine only has 25 byte). > > This is a bug in the logcheck rules, I'd say. It should deal with timestamps > having no subseconds resolution. > > https://www.rsyslog.com/doc/configuration/properties.html > I suppose that for remote messages it uses "timereported", which typically > uses a resolution in seconds I still think that rsyslog should not mix two different timestamp formats in the same logfile with the same template configuration. And yes, maybe logcheck should recognize both formats with/without subseconds part. Thanks Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1064385: rsyslog: New default log format is different for local and remote log
Package: rsyslog Version: 8.2302.0-1 Severity: important Dear Maintainer, I'm using rsyslog to log local events and remote events to the same log. For this I've enabled UDP receiving. The main machine is the host, while the other machines logging via UDP are virtual machines running on that host. The network carrying the syslog traffic is not visible outside the host machine. The version of rsyslog in Debian stable now uses the new international timestamp format by default. Unfortunately this format differs for local and remote logs. The local machine by default logs in the following format: 2024-02-16T22:05:52.315463+01:00 tux [...] while a machine logging via UDP appears like this: 2024-02-16T22:06:02+01:00 tux1 [...] Please observe that the sub-seconds part of the timestamp is not included in the remote logs. Unfortunately this causes logcheck to completely ignore all the remote logs because it matches on a 32-byte timestamp (and the timestamp of the remote machine only has 25 byte). I had to revert to the old 'traditional' log format (which was the default in previous versions of syslog shipped by Debian) with the following config line: $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat You will have to remove that line from the appended config file for reproducing the issue. Fortunately the old 'traditional' format is still supported by logcheck. Expected behavior: The timestamp format logcheck produces with the default configuration should be made the same for local and remote logs. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.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 rsyslog depends on: ii libc6 2.36-9+deb12u4 ii libestr0 0.1.11-1 ii libfastjson4 1.2304.0-1 ii liblognorm5 2.0.6-4 ii libsystemd0 252.22-1~deb12u1 ii libuuid1 2.38.1-5+b1 ii libzstd1 1.5.4+dfsg2-5 ii zlib1g1:1.2.13.dfsg-1 Versions of packages rsyslog recommends: ii logrotate 3.21.0-1 Versions of packages rsyslog suggests: pn rsyslog-doc pn rsyslog-gssapi pn rsyslog-mongodb pn rsyslog-mysql | rsyslog-pgsql pn rsyslog-openssl | rsyslog-gnutls pn rsyslog-relp -- Configuration Files: /etc/rsyslog.conf changed: module(load="imuxsock") # provides support for local system logging module(load="imklog") # provides kernel logging support module(load="imudp") input(type="imudp" port="514") $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $WorkDirectory /var/spool/rsyslog $IncludeConfig /etc/rsyslog.d/*.conf *.*;auth,authpriv.none -/var/log/syslog auth,authpriv.* /var/log/auth.log cron.* -/var/log/cron.log kern.* -/var/log/kern.log mail.* -/var/log/mail.log user.* -/var/log/user.log -- no debconf information
Bug#1064103: qt5-gtk-platformtheme: Qt and KDE applications look pretty bad on a Gnome desktop (even with qt5-gtk-platformtheme installed)
Package: qt5-gtk-platformtheme Version: 5.15.10+dfsg-6 Severity: normal Dear Maintainer, the default experience of starting a Qt or KDE application in a Gnome desktop on Debian is not great: the default widget style is very different from what one sees in a KDE desktop (and it's not very pretty either), and the cursor is way too big. I will attach a screenshot demonstrating the problem (if reportbug lets me). This is despite installing qt5-gtk-platformtheme. So far, I have managed to partially work around this: - I have installed qt5ct - I have edited my ~/.profile to set QT_QPA_PLATFORMTHEME=qt5ct - I have selected the "Breeze" theme in qt5ct This helps a lot, but few non-experts are going to be able to find these steps. And even after all these steps, the cursor is still way too big when moving into Qt or KDE windows. (I originally reported this as a KDE bug: https://bugs.kde.org/show_bug.cgi?id=480272, but I was told that I should report this against the distro.) Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/20 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 qt5-gtk-platformtheme depends on: ii libc6 2.37-15 ii libglib2.0-0 2.78.3-2 ii libgtk-3-0 3.24.41-1 ii libpango-1.0-0 1.51.0+ds-4 ii libqt5core5a [qtbase-abi-5-15-10] 5.15.10+dfsg-6 ii libqt5dbus55.15.10+dfsg-6 ii libqt5gui5 5.15.10+dfsg-6 ii libstdc++6 14-20240201-3 ii libx11-6 2:1.8.7-1 qt5-gtk-platformtheme recommends no packages. qt5-gtk-platformtheme suggests no packages. -- no debconf information
Bug#1055757: webext-browserpass: extension shows warning in browser: "Update native host app"
Package: webext-browserpass Version: 3.7.2-1+b13 Severity: normal Dear Maintainer, When activating the extension in Firefox, I now get a warning in the "pass" menu. It says in red text "Update native host app". The package here in Debian has not been updated in over 2 years, so I assume this simply needs the latest upstream version to be packaged. Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-3-amd64 (SMP w/20 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 webext-browserpass depends on: ii fonts-open-sans 1.11-2 ii libc62.37-12 Versions of packages webext-browserpass recommends: pn firefox | firefox-esr | chromium webext-browserpass suggests no packages. -- no debconf information
Bug#1055389: libgccjit-12-dev: gccjit is not added to the usual library search paths
Package: libgccjit-12-dev Version: 12.3.0-9 Severity: normal Dear Maintainer, when installing libgccjit-12-dev, I'd expect to be able to write applications that link against gccjit. (The GCC codegen backend for the Rust compiler is one example for such an application.) However, strangely, that does not work: instead I get a linker error telling me that the library was not found. The reason for this is that libgccjit.so is located in /usr/lib/gcc/x86_64-linux-gnu/12, rather than /usr/lib/x86_64-linux-gnu/. It would be great if a symlink could be added to the usual linker locations, so that people linking against gccjit do not have to resort to ugly work-arounds such as `sudo ln -s /usr/lib/gcc/x86_64-linux-gnu/12/libgccjit.so /usr/lib/x86_64-linux-gnu/libgccjit.so`. Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/20 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 libgccjit-12-dev depends on: ii gcc-12-base 12.3.0-9 ii libgccjit0 13.2.0-4 libgccjit-12-dev recommends no packages. Versions of packages libgccjit-12-dev suggests: pn libgccjit-12-dbg -- no debconf information
Bug#1050413: etckeeper: Verbose cron job leads to daily email: "Auto packing the repository in background for optimum performance"
Package: etckeeper Version: 1.18.20-1 Severity: normal Dear Maintainer, since very recently, etckeeper started to become rather verbose, and I now get a daily email from the cronjob: /etc/cron.daily/etckeeper: Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. Since this does not indicate any kind of error, it would be better not to bother the admin with such emails. Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-2-amd64 (SMP w/20 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 etckeeper depends on: ii debconf [debconf-2.0] 1.5.82 ii git1:2.40.1-1 Versions of packages etckeeper recommends: ii cron [cron-daemon] 3.0pl1-163 Versions of packages etckeeper suggests: ii sudo 1.9.14p2-1 -- debconf information: etckeeper/purge: true
Bug#1050407: tycho: build-depends on obsolete libeclipse-osgi-util-java
Source: tycho Version: 1.6.0-3 Severity: serious Tags: ftbfs Hi, tycho build-depends on libeclipse-osgi-util-java which only exists in oldstable (and older). -Ralf.
Bug#1050402: aws-shell: build-depends on obsolete version of awscli
Source: aws-shell Tags: ftbfs Version: 0.2.1-1 Severity: serious Hi, aws-shell build-depends on awscli (<< 2.0.0). However, the current version of awscli in sid is 2.12.0-1. -Ralf.
Bug#1050400: aws-checksums: build-depends on non-existing libaws-c-common-dev
Source: aws-checksums Severity: serious Tags: ftbfs Version: 0.1.13-1 Hi, aws-checksums build-depends on libaws-c-common-dev which does not exist anywhere in the archive. This is the case since 2022-11-10. -Ralf.
Bug#1041164: dose-distcheck: fails with (W)Dose_common: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe"
For the record : this seems to be related to the option "--latest 1" discarding Essential packages. Here is a minimal Packages file for reproducing the bug: Package: aa Source: aa Version: 1 Essential: yes Architecture: all Package: aa Source: aa Version: 2 Architecture: all -Ralf.
Bug#1040757: dose: (W)CudfAdd: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe
Hi Raphaël, On Thu, Aug 17, 2023 at 02:07:22PM +0200, Raphael Hertzog wrote: > Hello Ralf, > > Le samedi 15 juillet 2023, Ralf Treinen a écrit : > > In fact it is not related to dose-distcheck being outdated on quantz, I > > get the same error with dose-distcheck on sid. > > > > Since I do not have time to dig further into this atm (leaving for vacation) > > I have now desactivated the unstable_main scenario, which is the only > > one where the error is occurring. > It would be nice if it could be revived. :) Do you have an idea when you > will be able to dig further? I will look into this today. Anyway, it seems that the error does no longer occur with Packages files produced after August 10 (at least). Cheers -Ralf.
Bug#1049962: closed by Stefano Rivera (Re: Bug#1049962: python3-pip: Misleading error message on "pip install --user")
I still think the text and definitely the README.venv could be written in a less
confusing way. For instance, README.venv starts out saying
It is recommended to let Debian's package managers manage Python packages in
/usr/lib/ and /usr/share/.
So for my case ("pip install --user"), obviously this document is not relevant,
since indeed I do want to let Debian manage the packages in /usr. Nothing in
that file even mentions ~/.local.
; Ralf
Bug#1049962: python3-pip: Misleading error message on "pip install --user"
Package: python3-pip Version: 23.2+dfsg-1 Severity: normal Dear Maintainer, When I try to install something to my user directory, I get a confusing error message: error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed. If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed. See /usr/share/doc/python3.11/README.venv for more information. note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification. This is confusing because the error, and the README.venv file, all talk about system-wide installation (in /usr). But I am not trying to do a system-wide installation! I just want a user-wide installation. Somehow that leads to the same error message though. Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-2-amd64 (SMP w/20 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 python3-pip depends on: ii ca-certificates 20230311 ii python3 3.11.4-5 ii python3-distutils 3.11.4-1 ii python3-setuptools 68.0.0-1 ii python3-wheel 0.38.4-2 Versions of packages python3-pip recommends: ii build-essential 12.10 ii python3-dev 3.11.4-5 python3-pip suggests no packages. -- no debconf information
Bug#1049349: valgrind: DWARF5 not supported: "Possibly corrupted debuginfo file"
Package: valgrind Version: 1:3.19.0-1 Severity: normal Dear Maintainer, trying to use valgrind on programs that contain DWARF5 debuginfo leads to an error message: ==92495== Valgrind: debuginfo reader: Possibly corrupted debuginfo file. ==92495== Valgrind: I can't recover. Giving up. Sorry. This is a problem, since e.g. for over a year now, more and more Rust programs contain DWARF5 debuginfo (see <https://github.com/rust-lang/rust/issues/98746>). They all cannot be debugged or profiled with valgrind. Reportedly, valgrind 3.20 improves the situation greatly, but unfortunately that only has an experimental package available right now. Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-2-amd64 (SMP w/20 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 valgrind depends on: ii libc6 2.37-7 ii libc6-dbg 2.37-7 Versions of packages valgrind recommends: ii gdb 13.2-1 ii valgrind-dbg 1:3.19.0-1 Versions of packages valgrind suggests: pn alleyoop pn kcachegrind pn valgrind-mpi pn valkyrie -- no debconf information
Bug#1043443: libgtk-3-0: Missing print backend for lpr
Package: libgtk-3-0 Version: 3.24.37-2 Severity: important libgtk-3-0 used to ship the following print backends in debian buster and debian bullseye: libprintbackend-cloudprint.so libprintbackend-cups.so libprintbackend-file.so libprintbackend-lpr.so libprintbackend-test.so By default only cups and file were enabled. Debian bookworm only ships libprintbackend-cups.so libprintbackend-file.so probably due to the bug-report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025271 Please re-enable the other print backends in the next build. If some undesired backends are available by default, this can be configured in the file /etc/gtk-3.0/settings.ini The stanza there should look like (for previous debian defaults): [Settings] gtk-print-backends=file,cups So the correct fix for #1025271 is to leave all print backends enabled and add a debian-provided config-file with the enabled backends unless there is another way to set a default config in recent gtk. The current state of affairs makes debian bookworm unuseable for people with other print backends like lpr. This is needed, e.g., for the debian-provided lprng package. It is also needed for printers that support the lpr protocol natively. Note: I've searched if the other backends are available in another package now, this does not seem to be the case. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.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 libgtk-3-0 depends on: ii adwaita-icon-theme 43-1 ii hicolor-icon-theme 0.17-2 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-0 2.46.0-5 ii libc62.36-9+deb12u1 ii libcairo-gobject21.16.0-7 ii libcairo21.16.0-7 ii libcolord2 1.4.6-2.2 ii libcups2 2.4.2-3+deb12u1 ii libepoxy01.5.10-1 ii libfontconfig1 2.14.1-4 ii libfribidi0 1.0.8-2.1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-common 3.24.37-2 ii libharfbuzz0b6.0.0+dfsg-3 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpangoft2-1.0-01.50.12+ds-1 ii libwayland-client0 1.21.0-1 ii libwayland-cursor0 1.21.0-1 ii libwayland-egl1 1.21.0-1 ii libx11-6 2:1.8.4-2+deb12u1 ii libxcomposite1 1:0.4.5-1 ii libxcursor1 1:1.2.1-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxi6 2:1.8-1+b1 ii libxinerama1 2:1.1.4-3 ii libxkbcommon01.5.0-1 ii libxrandr2 2:1.5.2-2+b1 ii shared-mime-info 2.2-1 Versions of packages libgtk-3-0 recommends: ii libgtk-3-bin 3.24.37-2 ii librsvg2-common 2.54.5+dfsg-1 Versions of packages libgtk-3-0 suggests: ii gvfs 1.50.3-1 Versions of packages libgtk-3-0 is related to: pn appmenu-gtk3-module pn fcitx-frontend-gtk3 pn gcin-gtk3-immodule pn gtk-vector-screenshot pn gtk3-engines-xfce pn gtk3-im-libthai pn hime-gtk3-immodule pn ibus-gtk3 pn imhangul-gtk3 ii libcanberra-gtk3-module 0.30-10 pn libcaribou-gtk3-module pn libgtk3-nocsd0 pn maliit-inputcontext-gtk3 pn packagekit-gtk3-module pn scim-gtk-immodule pn topmenu-gtk3 pn uim-gtk3 pn uim-gtk3-immodule -- no debconf information
Bug#906077: Still present in bookworm
This bug is still present in Debian bookworm. Package python3-plotly version 5.4.1+dfsg-1 Debian *does* ship the un-minimized javascript and I was able to fix it by sudo ln -s /usr/share/python3-plotly/plotly.js /usr/lib/python3/dist-packages/plotly/package_data/plotly.min.js after creating the package_data directory. I don't care currently if the javascript is minimized or not. But Debian should really be shipping the minimized Javascript at the correct location. My use-case is exporting html from plotly and specifying that the javascript is not part of the exported html. Thanks Ralf Schlatterbeck -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1039893: steam-installer: Dangling symlink in package: /usr/share/pixmaps/steam_tray_mono.png, breaks tray icon
Hi, On 26.07.23 13:37, Simon McVittie wrote: On Thu, 29 Jun 2023 at 11:53:53 +0200, Ralf Jung wrote: this package ships a symlink /usr/share/pixmaps/steam_tray_mono.png that points to ../icons/hicolor/48x48/apps/steam_tray_mono.png. However, that target file does not exist: ... As a consequence of this, the systray icon for steam is broken. Broken in what environment? What component are you using to display tray icons? It's working OK in GNOME with gnome-shell-extension-appindicator, but there are several code paths that a tray icon could potentially go through (KDE status notifier, Ubuntu appindicators, legacy Xembed, and probably more). I am using gnome-shell-extension-appindicator and it didn't use to work here when I made the bugreport. However I have since then done a big apt upgrade and that must have changed something, because when I now tried it again it actually did work. :) (But the nextcloud icon is broken now. *sigh* ) The dangling symlink should probably still be removed, though. We are no longer able to ship Valve's proprietary steam_tray_mono.png in /usr, in order to make steam-installer a pure "installer" package that can be in contrib. When a user runs /usr/games/steam, the actual proprietary files get downloaded, and a symbolic link to the icon is created in ~/.local/share/icons/hicolor/48x48/apps/steam_tray_mono.png (but this happens in an unprivileged process with no access to /usr). As a first attempt at fixing this, I'm going to remove the dangling symlink, which will hopefully result in the icon being loaded from ~/.local/share/icons/hicolor/48x48/apps/steam_tray_mono.png. If that isn't successful, please reopen the bug and provide more details of your environment: it's possible that for some desktop environments it will need a symlink in some other location like ~/.icons or ~/.local/share/icons. Sounds good, thanks! Ralf
Bug#1041765: nextcloud-desktop: Tray icon no longer works with gnome + indicator extension
Package: nextcloud-desktop Version: 3.9.0-1 Severity: normal Dear Maintainer, since installing nextcloud-desktop 3.9, the systray icon no longer works as expected in Gnome (with the AppIndicator extension): it shows shows three white dots instead of the nextcloud icon. Nextcloud shows everything as fully synced, so I am fairly sure that these are the three dots Gnome shows when it cannot find the icon. However, I am not sure why the icon can no longer be found -- it used to work fine before I did a big "apt upgrade" yesterday. Here's another report of the same problem, with a screenshot: https://forum.manjaro.org/t/nextcloud-client-icon-is-not-showing-correctly/138545 Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_DIE, TAINT_WARN 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 nextcloud-desktop depends on: ii libc6 2.37-5 ii libcloudproviders0 0.3.1-2 ii libgcc-s1 13.1.0-6 ii libglib2.0-0 2.74.6-2 ii libkf5archive5 5.107.0-1 ii libnextcloudsync0 3.9.0-1 ii libqt5core5a 5.15.8+dfsg-12 ii libqt5dbus55.15.8+dfsg-12 ii libqt5gui5 5.15.8+dfsg-12 ii libqt5keychain10.14.1-1 ii libqt5network5 5.15.8+dfsg-12 ii libqt5qml5 5.15.8+dfsg-3 ii libqt5quick5 5.15.8+dfsg-3 ii libqt5quickcontrols2-5 5.15.8+dfsg-2 ii libqt5sql5-sqlite 5.15.8+dfsg-12 ii libqt5svg5 5.15.8-3 ii libqt5webenginecore5 5.15.13+dfsg-1~deb12u1 ii libqt5webenginewidgets55.15.13+dfsg-1~deb12u1 ii libqt5widgets5 5.15.8+dfsg-12 ii libstdc++6 13.1.0-6 ii nextcloud-desktop-common 3.9.0-1 ii nextcloud-desktop-l10n 3.9.0-1 ii qml-module-qt-labs-platform5.15.8+dfsg-2 ii qml-module-qtgraphicaleffects 5.15.8-2 ii qml-module-qtqml 5.15.8+dfsg-3 ii qml-module-qtqml-models2 5.15.8+dfsg-3 ii qml-module-qtquick-controls2 5.15.8+dfsg-2 ii qml-module-qtquick-dialogs 5.15.8-2 ii qml-module-qtquick-layouts 5.15.8+dfsg-3 ii qml-module-qtquick-window2 5.15.8+dfsg-3 ii qml-module-qtquick25.15.8+dfsg-3 Versions of packages nextcloud-desktop recommends: ii nextcloud-desktop-doc 3.9.0-1 nextcloud-desktop suggests no packages. -- no debconf information
Bug#1041164: dose-distcheck: fails with (W)Dose_common: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe"
Package: dose-distcheck Version: 7.0.0-1+b2 Affects: #1040757 dose-debcheck fails on recent unstable main packages file, independently of the architectures : % dose-debcheck -e -f --latest 1 --deb-native-arch=amd64 --fg=/home/rt/dose.debian.net/mirror/unstable/main/binary-amd64/Packages > sid-main-amd64.out (W)Dose_common: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe The applications raised this exception : Not_found
Bug#1040757: dose: (W)CudfAdd: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe
In fact it is not related to dose-distcheck being outdated on quantz, I get the same error with dose-distcheck on sid. Since I do not have time to dig further into this atm (leaving for vacation) I have now desactivated the unstable_main scenario, which is the only one where the error is occurring. -Ralf.
Bug#1040757: dose: (W)CudfAdd: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe
Hello, On Mon, Jul 10, 2023 at 01:35:44PM +0800, Paul Wise wrote: > Package: qa.debian.org > Severity: important > User: qa.debian@packages.debian.org > Usertags: dose > X-Debbugs-CC: Ralf Treinen > > The dose cron job has been producing these errors since 2023-07-02: [...] The version of dose-distcheck installed on quantz is very old (5.0.1-12, form oldoldstable). The version in bookworm is 7.0.0-1+b2. I can't tell yet whether more recent versions of dose fix the problem, but do you have plans for upgrading quantz ? Cheers -Ralf.
Bug#1040379: Bug in dhclient
Package: isc-dhcp-client <https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=isc-dhcp-client> I am experiencing a strange behaviour, and this might be connected to the bug #595190 (isc-dhcp-client: goes into an infinite loop if server only answers on broadcast). I am trying to debug two DHCP servers (one is on a Windows Server 2012 R2, and the other one is dnsmasq on Ubuntu 22.04). *To check them both, I am using the option '-s ", but this does not work correctly.* * dhclient sends a DHCPDISCOVER, and as the option suggests, it does not send this as a broadcast, but as a unicast to the server given in the option. * Neither DHCP server, however, answers this with a DHCPOFFER, but both of them send a DHCPACK. * So, it seems as if dhclient assumes to have sent a DHCPDISCOVER and thus waits for a DHCPOFFER - whereas the servers seem to interpret the package as a DHCPREQUEST and answer with DHCPACK. * As this behaviour is identical on both DHCP servers, I dare to assume that this is an error in the package sent by dhclient. * (Moreover, although I deleted the file /var/lib/dhcp/dhcp.leases, the dhclient somehow seems to remember its former lease address and inserts it into the DHCPDISCOVER package. Is that correct?) * And worse, if I do not delete the old lease file, dhclient sends a DHCPREQUEST for its former address - which will can be acknowledged if the request is for an address issued from server A, and the request goes to server B... (but this might be by design) I observe the behavior with dhclient * sc-dhclient-4.4.3 on Linux Debian 12 * isc-dhclient-4.4.1 on Linux Mint 20.3 Una * sc-dhclient-4.4.1 on LinuxUbuntu 20.04.5 Best regards, -- Ralf „Pi“ Pichocki. Bahnhofstraße 190 45770 Marl-Sinsen Germany +49 2365 9559945 (Tel) +46 382 650999 (Tel) +49 176 43117687 (Mobil) ralf.picho...@gmx.de <mailto:ralf.picho...@gmx.de>(Mail)
Bug#486226: ocaml-mode: caml-mode bogusly binds C-c combinations
Hello, I have tagged this bug as wontfix. What you ask for is too invasive on users of caml-mode, changing these key bindings would mean that users of the debian package will have completely different key bindings than users of the upstream package. Best -Ralf.
Bug#1039893: steam-installer: Dangling symlink in package: /usr/share/pixmaps/steam_tray_mono.png, breaks tray icon
Package: steam-installer Version: 1:1.0.0.78~ds-2 Severity: normal Dear Maintainer, this package ships a symlink /usr/share/pixmaps/steam_tray_mono.png that points to ../icons/hicolor/48x48/apps/steam_tray_mono.png. However, that target file does not exist: $ dpkg -L steam-installer | grep png /usr/share/icons/hicolor/16x16/apps/steam.png /usr/share/icons/hicolor/24x24/apps/steam.png /usr/share/icons/hicolor/256x256/apps/steam.png /usr/share/icons/hicolor/32x32/apps/steam.png /usr/share/icons/hicolor/48x48/apps/steam.png /usr/share/pixmaps/steam.png /usr/share/pixmaps/steam_tray_mono.png As a consequence of this, the systray icon for steam is broken. Kind regards, Ralf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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 steam-installer depends on: ii debconf [debconf-2.0] 1.5.82 ii steam-libs 1:1.0.0.78~ds-2 ii steam-libs-i3861:1.0.0.78~ds-2 ii zenity 3.44.0-1 steam-installer recommends no packages. steam-installer suggests no packages. Versions of packages steam-libs depends on: ii ca-certificates 20230311 ii curl 7.88.1-10 ii file 1:5.44-3 ii libc62.36-9 ii libcrypt11:4.4.33-2 ii libgcc-s1 [libgcc1] 12.2.0-14 ii libgl1 1.6.0-1 ii libgl1-mesa-dri 22.3.6-1+deb12u1 ii libgpg-error01.46-1 ii libstdc++6 12.2.0-14 ii libudev1 252.6-1 ii libva-x11-2 2.18.0-1 ii libva2 2.18.0-1 ii libxcb-dri3-01.15-1 ii libxcb1 1.15-1 ii libxi6 2:1.8-1+b1 ii libxinerama1 2:1.1.4-3 ii xz-utils 5.4.1-0.2 Versions of packages steam-libs recommends: ii fontconfig 2.14.1-4 ii fonts-liberation 1:1.07.4-11 ii gnome-terminal [x-terminal-emulator] 3.46.8-1 ii i965-va-driver [va-driver] 2.4.1+dfsg1-1 ii intel-media-va-driver [va-driver] 23.1.2+dfsg1-1 ii konsole [x-terminal-emulator] 4:22.12.3-1 ii libasound2-plugins 1.2.7.1-1 ii libegl11.6.0-1 ii libexpat1 2.5.0-1 ii libfontconfig1 2.14.1-4 ii libgbm122.3.6-1+deb12u1 ii libsdl2-2.0-0 2.26.5+dfsg-1 ii libva-drm2 2.18.0-1 ii libva-glx2 2.18.0-1 ii libx11-6 2:1.8.4-2 ii libx11-xcb12:1.8.4-2 ii libxau61:1.0.9-1 ii libxcb-dri2-0 1.15-1 ii libxcb-glx01.15-1 ii libxcb-present01.15-1 ii libxcb-sync1 1.15-1 ii libxdamage11:1.1.6-1 ii libxdmcp6 1:1.1.2-3 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxss11:1.2.3-1 ii libxxf86vm11:1.1.4-1+b2 ii mesa-va-drivers [va-driver]22.3.6-1+deb12u1 ii mesa-vulkan-drivers22.3.6-1+deb12u1 ii steam-devices 1:1.0.0.78~ds-2 ii va-driver-all 2.18.0-1 ii xdg-desktop-portal 1.16.0-2 ii xdg-desktop-portal-gnome [xdg-desktop-portal-backend] 43.1-2 ii xdg-desktop-portal-gtk [xdg-desktop-portal-backend]1.14.1-1 ii xdg-utils 1.1.3-4.1 ii xterm [x-terminal-emulator]379-1 ii zenity 3.44.0-1 Versions of packages steam-libs suggests: pn libudev0 pn nvidia-driver-libs pn nvidia-vulkan-icd ii pipewire0.3.65-3 Versions of packages steam-libs:i386 depends on: ii ca-certificates 20230311 ii curl 7.88.1-10 ii file 1
Bug#1037199: evince: Cannot open links in browser due to Apparmor profile
Package: evince Version: 43.1-2+b1 Severity: normal Dear Maintainer, clicking a link to open things in my browser works in basically all applications, except evince. It took me a long whole to realize that this is due to apparmor: Jun 07 15:53:03 r-ethtop audit[1165140]: AVC apparmor="DENIED" operation="exec" profile="/usr/bin/evince" name="/home/r/bin/firefox" pid=1165140 comm="gio-launch-desk" requested_mask="x" denied_mask="x" fsuid=1000 ouid=1000 Jun 07 15:53:03 r-ethtop kernel: audit: type=1400 audit(1686145983.857:133): apparmor="DENIED" operation="exec" profile="/usr/bin/evince" name="/home/r/bin/firefox" pid=1165140 comm="gio-launch-desk" requested_mask="x" denied_mask="x" fsuid=1000 ouid=1000 Looks like this would happen to anyone who set their default browser to something they installed themselves as a user rather than using a system package. That's quite surprising and most people will probably never figure out why things are broken. I am still trying to figure out how to work around this, Apparmor seems super complicated and I don't have the time to learn it just to fix clicking links in a PDF... I'll probably end up just disabling it as that seems like the only thing that's reasonably easy to do. :/ Kind regards, Ralf -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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 evince depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii evince-common43.1-2 ii gsettings-desktop-schemas43.0-1 ii libatk1.0-0 2.46.0-5 ii libc62.36-9 ii libcairo-gobject21.16.0-7 ii libcairo21.16.0-7 ii libevdocument3-4 43.1-2+b1 ii libevview3-3 43.1-2+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgnome-desktop-3-2043.2-2 ii libgtk-3-0 3.24.37-2 ii libhandy-1-0 1.8.1-1 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libsecret-1-00.20.5-3 ii shared-mime-info 2.2-1 Versions of packages evince recommends: ii dbus-user-session [default-dbus-session-bus] 1.14.6-1 Versions of packages evince suggests: ii gvfs 1.50.3-1 pn nautilus-sendto ii poppler-data 0.4.12-1 pn unrar -- no debconf information
Bug#1036361: Akonadi floods log file .local/share/akonadi/db_data/mysql.err after upgrade to debian 12
package: akonadi-server version: 4:22.12.3-1 severity: minor I upgrade my system from debian 11 to debian 12. After that the log files .local/share/akonadi/db_data/mysql.err .local/share/akonadi/db_data/mysql.err.old swelled incredibly fast with 2 constantly repeating error messages. Searching the in the internet I found the page https://forums.opensuse.org/t/akonadi-floods-its-mysql-err-with-an-error-message/153196 The command mysql_upgrade --defaults-file=/home/username/.local/share/akonadi/mysql.conf --socket=/run/user/1000/akonadi/mysql.socket solved the issue for me. Still I consider it a bug that should be fixed. Thanks for all your efforts! Ralf
Bug#1032517: nginx settings deleted on upgrade
Package: nginx Version: 1.22.1-7 Severity: grave Justification: causes non-serious data loss Dear Maintainer, last weekend I did an "apt upgrade" of my system as usual, asking apt to prune configuration files for packages that are being uninstalled. Now I realize that my nginx stopped working, and it turns out its configuration files are just completely gone. Look like the recent package reorganization went wrong and actually deletes configuration under certain conditions -- that's pretty bad. Package updates shouldn't cause a loss of configuration files, even when pruning packages that are not present any more. Kind regards, Ralf -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER 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 nginx depends on: ii debconf [debconf-2.0] 1.5.82 ii iproute2 6.1.0-1 ii libc6 2.36-8 ii libcrypt1 1:4.4.33-2 ii libpcre2-8-0 10.42-1 ii libssl33.0.8-1 ii zlib1g 1:1.2.13.dfsg-1 nginx recommends no packages. Versions of packages nginx suggests: ii fcgiwrap 1.1.0-14 pn nginx-doc ii ssl-cert 1.1.2 -- Configuration Files: /etc/nginx/fastcgi.conf [Errno 2] No such file or directory: '/etc/nginx/fastcgi.conf' /etc/nginx/fastcgi_params [Errno 2] No such file or directory: '/etc/nginx/fastcgi_params' /etc/nginx/koi-utf [Errno 2] No such file or directory: '/etc/nginx/koi-utf' /etc/nginx/koi-win [Errno 2] No such file or directory: '/etc/nginx/koi-win' /etc/nginx/mime.types [Errno 2] No such file or directory: '/etc/nginx/mime.types' /etc/nginx/nginx.conf [Errno 2] No such file or directory: '/etc/nginx/nginx.conf' /etc/nginx/proxy_params [Errno 2] No such file or directory: '/etc/nginx/proxy_params' /etc/nginx/scgi_params [Errno 2] No such file or directory: '/etc/nginx/scgi_params' /etc/nginx/sites-available/default [Errno 2] No such file or directory: '/etc/nginx/sites-available/default' /etc/nginx/snippets/fastcgi-php.conf [Errno 2] No such file or directory: '/etc/nginx/snippets/fastcgi-php.conf' /etc/nginx/snippets/snakeoil.conf [Errno 2] No such file or directory: '/etc/nginx/snippets/snakeoil.conf' /etc/nginx/uwsgi_params [Errno 2] No such file or directory: '/etc/nginx/uwsgi_params' /etc/nginx/win-utf [Errno 2] No such file or directory: '/etc/nginx/win-utf' -- debconf information: nginx/log-symlinks:
Bug#1030329: Proposing NMU
Hi Sergei, Sure, please go ahead and thanks! Feel free to add this patch in <https://salsa.debian.org/debian/osspd> as well. ; Ralf On 04.02.23 14:17, Sergei Golovan wrote: Hi Ralf, If you don't mind, I'd suggest doing NMU for this bug. I've tested myself, simply adding pipewire-pulse to the dependencies list allows osspd to work with pipewire (in the modern Gnome desktop pipewire is installed by default and cannot be easily replaced with pulseaudio). The diff for the proposed NMU is attached. Cheers!
Bug#1029314: RM: coccinelle [armhf] -- ROM; compilation on armhf crashes "out of memory"
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: coccine...@packages.debian.org Control: affects -1 + src:coccinelle Hi, compilation of coccinelle on armhf keeps on failing with message "out of memory", which blocks migration to testing. -Ralf.
Bug#984229: mccs: diff for NMU version 1:1.1-9.1
Hi Adrien, On Mon, Jan 16, 2023 at 07:34:53PM +0200, Adrian Bunk wrote: > I've prepared an NMU for mccs (versioned as 1:1.1-9.1) and uploaded > it to DELAYED/14. Please feel free to tell me if I should cancel it. thanks a lot, I just uploaded version 1.1-10, which includes your patch, to unstable. Cheers -Ralf.
Bug#1023712: why3 breaks frama-c (autopkgtest): missing versioned Breaks?
Hi Paul, On Wed, Dec 21, 2022 at 09:16:32PM +0100, Paul Gevers wrote: > Control: reassign -1 frama-c > > Dear maintainers, > > On Tue, 8 Nov 2022 21:53:18 +0100 Paul Gevers wrote: > > [kernel] User Error: cannot load plug-in 'frama-c-wp': cannot load module > >Details: implementation mismatch on Why3 > > [kernel] User Error: Deferred error message was emitted during > > execution. See above messages for more information. > > [kernel] Frama-C aborted: invalid user input. > > autopkgtest [20:18:19]: test eva > > I'm now seeing the above error message in the frama-c test in testing, so it > seems that the issue is rather that the autopkgtest of frama-c doesn't > properly declare it's *versioned* test dependency on why3? Should the > Recommends be versioned? (Not sure if that actually works as intended, but > apparently the tested plug-in only works correctly with the right version of > why3). Sorry for not replying earlier, the last weeks have been very busy at work. The problem is that for some reason the package build of frama-c does not pick up the versioned dependency on libwhy3-ocaml-dev (this should be done by dh_ocaml). I'm looking into this now. Cheers -Ralf.
Bug#1025733: libxmlada: unsatisfiable buil-dependency on unicode-data
Source: libxmlada Version: 22.0.0-3 Severity: serious Hi, libxmlada build-depends (in Build-Depends-Arch) on unicode-data (>= 14~), unicode-data (<< 15~) but the version of unicode-data in sid is 15.0.0-1. -Ralf.
Bug#1025731: libghc-pcre-light-doc: depends on non-existing haddock-interface-35
Package: libghc-pcre-light-doc Version: 0.4.1.0-1 Severity: serious libghc-pcre-light-doc cannot be installed since it depends on haddock-interface-35 which does not exist in sid. -Ralf.
Bug#1024001: flatpak should Recommend: xdg-desktop-portal-gtk (without alternative)
Package: flatpak Version: 1.14.0-2 Severity: normal Dear Maintainer, GTK3 and/or GTK4 applications running inside flatpak on a Wayland host need the xdg-desktop-portal-gtk package to be installed or else font rendering will look terrible (see https://github.com/flatpak/flatpak/issues/2861). So the flatpak package should Recommend: xdg-desktop-portal-gtk. Right now it recommends 'xdg-desktop-portal-gtk | xdg-desktop-portal-packend', which in my case is satisfied by xdk-desktop-portal-kde, but that is not enough to get proper font rendering. Kind regards, Ralf -- Package-specific info: Permissions of /usr/bin/bwrap: -rwxr-xr-x 1 root root 72080 Nov 7 18:57 /usr/bin/bwrap /etc/sysctl.d/*-bubblewrap.conf: cat: '/etc/sysctl.d/*-bubblewrap.conf': No such file or directory /usr/lib/sysctl.d/50-bubblewrap.conf: # Enable unprivileged creation of new user namespaces in older Debian # kernels. # # If this is not desired, copy this file to # /etc/sysctl.d/50-bubblewrap.conf and change the value of this parameter # to 0, then use dpkg-statoverride to make /usr/bin/bwrap setuid root. # # For more details see https://deb.li/bubblewrap or # /usr/share/doc/bubblewrap/README.Debian kernel.unprivileged_userns_clone=1 /proc/sys/kernel/unprivileged_userns_clone: 1 /proc/sys/user/max_cgroup_namespaces: 127534 /proc/sys/user/max_ipc_namespaces: 127534 /proc/sys/user/max_mnt_namespaces: 127534 /proc/sys/user/max_net_namespaces: 127534 /proc/sys/user/max_pid_namespaces: 127534 /proc/sys/user/max_time_namespaces: 127534 /proc/sys/user/max_user_namespaces: 127534 /proc/sys/user/max_uts_namespaces: 127534 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER 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 flatpak depends on: ii adduser 3.129 ii bubblewrap 0.7.0-1 ii dbus [default-dbus-system-bus] 1.14.4-1 ii fuse3 3.12.0-1 ii libappstream4 0.15.5-1 ii libarchive133.6.0-1 ii libc6 2.36-4 ii libcurl3-gnutls 7.86.0-1 ii libdconf1 0.40.0-3 ii libfuse3-3 3.12.0-1 ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1 ii libglib2.0-02.74.1-2 ii libgpgme11 1.18.0-1 ii libjson-glib-1.0-0 1.6.6-1 ii libmalcontent-0-0 0.11.0-3 ii libostree-1-1 2022.6-1+b1 ii libpolkit-agent-1-0 122-1 ii libpolkit-gobject-1-0 122-1 ii libseccomp2 2.5.4-1+b2 ii libsystemd0 252.1-1 ii libxau6 1:1.0.9-1 ii libxml2 2.9.14+dfsg-1+b1 ii libzstd11.5.2+dfsg-1 ii xdg-dbus-proxy 0.1.4-1 Versions of packages flatpak recommends: ii ca-certificates 20211016 ii desktop-file-utils 0.26-1 ii gtk-update-icon-cache3.24.34-3 ii hicolor-icon-theme 0.17-2 ii libpam-systemd 252.1-1 ii p11-kit 0.24.1-1 ii policykit-1 122-1 ii polkitd 122-1 ii shared-mime-info 2.2-1 ii xdg-desktop-portal 1.15.0-2+b1 ii xdg-desktop-portal-gtk [xdg-desktop-portal-backend] 1.14.0-1 ii xdg-desktop-portal-kde [xdg-desktop-portal-backend] 5.26.0-1 ii xdg-user-dirs0.18-1 Versions of packages flatpak suggests: ii avahi-daemon0.8-6+b1 pn malcontent-gui Versions of packages bubblewrap depends on: ii libc62.36-4 ii libcap2 1:2.44-1 ii libselinux1 3.4-1+b3 Versions of packages bubblewrap recommends: ii procps 2:3.3.17-7.1 -- no debconf information
Bug#1023928: evince: Incorrect 'desktopFileName' for wayland surface leads to missing icon in KDE Wayland session
Package: evince Version: 43.0-1 Severity: minor Dear Maintainer, evince windows do not have a proper icon in a KDE Wayland session. This is caused by the fact that the 'desktopFileName' of the Wayland surface is set to 'evince', when it should be 'org.gnome.Evince'. There is no `evince.desktop` so KDE cannot find an icon. Other gnome applications have the expected 'desktopFileName' (I checked the calculator), so this seems to be something specific to evince. I also reported this upstream at <https://gitlab.gnome.org/GNOME/evince/-/issues/1873>; it is hard to tell where the issue originates. Kind regards, Ralf -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evince depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii evince-common43.0-1 ii gsettings-desktop-schemas43.0-1 ii libatk1.0-0 2.46.0-3 ii libc62.36-4 ii libcairo-gobject21.16.0-6 ii libcairo21.16.0-6 ii libevdocument3-4 43.0-1 ii libevview3-3 43.0-1 ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1 ii libglib2.0-0 2.74.1-1 ii libgnome-desktop-3-2043-2 ii libgtk-3-0 3.24.34-3 ii libhandy-1-0 1.8.0-1 ii libpango-1.0-0 1.50.10+ds-1 ii libpangocairo-1.0-0 1.50.10+ds-1 ii libsecret-1-00.20.5-3 ii shared-mime-info 2.2-1 Versions of packages evince recommends: ii dbus-user-session [default-dbus-session-bus] 1.14.4-1 Versions of packages evince suggests: ii gvfs 1.50.2-2 pn nautilus-sendto ii poppler-data 0.4.11-1 ii unrar1:6.2.1-2 -- no debconf information
Bug#1023771: mumble: No icon for mumble window under KDE wayland
Package: mumble Version: 1.3.4-1.1 Severity: minor Dear Maintainer, The subject pretty much says it all: when opening Mumble on a KDE wayland session, the window has no icon. This means something is going wrong in associating the wayland surface with the mumble desktop file. Looking at the surface properties, its desktopFileName is set to 'net.sourceforge.mumble.mumble', so probably the desktop file needs to be renamed to match that. Kind regards, Ralf -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER 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 mumble depends on: ii libasound21.2.7.2-1 ii libavahi-compat-libdnssd1 0.8-6+b1 ii libc6 2.36-4 ii libgcc-s1 12.2.0-9 ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-1 ii libprotobuf23 3.12.4-1+b5 ii libpulse0 16.1+dfsg1-2+b1 ii libqt5core5a 5.15.6+dfsg-2 ii libqt5dbus5 5.15.6+dfsg-2 ii libqt5gui55.15.6+dfsg-2 ii libqt5network55.15.6+dfsg-2 ii libqt5sql55.15.6+dfsg-2 ii libqt5sql5-sqlite 5.15.6+dfsg-2 ii libqt5svg55.15.6-2 ii libqt5widgets55.15.6+dfsg-2 ii libqt5xml55.15.6+dfsg-2 ii libsndfile1 1.1.0-3+b1 ii libspeechd2 0.11.4-1 ii libspeex1 1.2.1-1 ii libspeexdsp1 1.2.1-1 ii libssl3 3.0.7-1 ii libstdc++612.2.0-9 ii libx11-6 2:1.8.1-2 ii libxi62:1.8-1+b1 ii lsb-release 12.0-1 mumble recommends no packages. Versions of packages mumble suggests: pn mumble-server pn speech-dispatcher -- no debconf information
Bug#907178: gimp-plugin-registry: resynthesizer not appearing in menu Filters/Enhance
Hi, the version packaged in Debian seems to be the same that is offered for download on the gimp website. This seems to be an upstream problem: Gimp 3 will be required for Python 3 support, and Gimp 3 has been delayed ~forever -- Gimp 3 is the GTK 3 port, which is not even done yet and meanwhile Gnome is already being ported to GTK 4! Kind regards, Ralf On 07.11.22 21:27, Ying-Chun Liu (PaulLiu) wrote: Hi, Yes, we ported that plugin to Python3. However, gimp in Debian is too old. There was a package called gimp-python which is python2 and got removed. Thus right now in Debian we have to disable all python plugins temporarily. We will bring those plugins back when gimp-python3 is available. This is not a bug of this package. This should be a bug of gimp. Yours, Paul
Bug#1023331: pass: Needs wl-copy but there is no "Depends:"
Hi, An "apt install wl-clipboard" fixes that. Looks like a missing dependency? There's already a Recommends on "xclip | wl-clipboard", attempting to express the fact that (a) only some pass functionality uses either utility and pass is otherwise usable without it (I don't use the clipboard functionality myself), and (b) pass uses one or the other depending on whether you're using X or Wayland. I certainly don't think a Depends is necessary here, but you evidently missed the Recommends as well. The recommends is satisfied because I have xclip installed. The "|" doesn't really help when one switches from X11 to wayland (which means one still has all the X11 things installed). In fact I assume most wayland users will have X11 installed, and the xclip alternative comes first here, so it is probably rather rare that this would actually end up installing wl-clipboard. It's not entirely clear how to improve this without annoying some constituencies of pass users with excess dependencies. Maybe if it were "Recommends: xclip, wl-clipboard" instead then it would be less likely that people would miss the wl-clipboard recommendation? Yeah it's not clear what the best solution is here... ideally you'd be able to say "if some wayland compositor is installed, also recommend wl-clipboard", but that is not something dpkg can express. wl-clipboard has very few dependencies though -- libwayland-client0 is already a dependency of libgtk3 and libgtk4 and plasma-desktop. So yeah I think "Recommends: wl-clipboard" would probably make sense. ; Ralf
Bug#1023357: python3-morse-simulator: depends on non-existing python3 (< 3.9)
Package: python3-morse-simulator Version: 1.4-6+b1 Severity: serious Hi, python3-morse-simulator depends on python3 (< 3.9) which is only satisfiable in oldstable or older. -Ralf.
Bug#1023356: libdune-pdelab-dev: unsatisfiable dependency on libdune-common-2.7.0
Package: libdune-pdelab-dev Version: 2.7~20200605-2 Severity: serious Hi, this package depends on libdune-common-2.7.0 which does not exist in sid. -Ralf.
Bug#1023355: limereg: depends on non-existing libboost-program-options1.67.0
Package: limereg Version: 1.4.1-4+b1 Severity: serious Hi, limereg depends on libboost-program-options1.67.0 which only exists in oldstable. -Ralf.
Bug#1023331: pass: Needs wl-copy but there is no "Depends:"
Package: pass Version: 1.7.4-5 Severity: normal Dear Maintainer, when being run under Wayland, pass uses 'wl-copy' to copy things to the clipboard. This leads to the following error on my system: /usr/bin/pass: line 180: wl-copy: command not found An "apt install wl-clipboard" fixes that. Looks like a missing dependency? Kinds regards, Ralf -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER 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 pass depends on: ii gnupg 2.2.40-1 ii tree 2.0.4-1 Versions of packages pass recommends: ii git 1:2.35.1-1 ii qrencode 4.1.1-1 ii wl-clipboard 2.1.0-0.1+b1 ii xclip 0.13-2 Versions of packages pass suggests: ii libxml-simple-perl 2.25-1 ii perl5.36.0-4 pn python ii python3 3.10.6-1 ii ruby1:3.0+3.1 -- no debconf information
Bug#1023296: plasma-workspace: ssh-agent not working in KDE Plasma Wayland session
Package: plasma-workspace Version: 4:5.26.0-2 Severity: normal Dear Maintainer, when I start a KDE Plasma Wayland session, the ssh-agent is not working: attempting to load my SSH key into the agent (in Konsole via ssh-add) fails saying "Could not open a connection to your authentication agent." This is probably caused by the fact that the SSH_AUTH_SOCK env var is not set. (I am now setting it in my .bashrc to work around the issue.) I have no idea how that env var is *supposed* to end up in the plasma session, but whatever mechanism is supposed to achieve that is not working. I can see that ssh-agent comes with a systemd user service, which is setting the required variable in "dbus-update-activation-environment", so maybe KDE is somehow supposed to fetch that and that is not working? Or maybe it's something else entirely. From feedback I got on IRC, it seems other distros have special ssh-agent scripts in /etc/xdg/plasma-workspace/env/, but I don't know if that is something standard. Kind regards, Ralf -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER 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 plasma-workspace depends on: ii dbus-user-session [default-dbus-session-bus]1.14.4-1 ii drkonqi 5.26.0-2 ii frameworkintegration5.98.0-1 ii gdb 12.1-3 ii init-system-helpers 1.65.2 ii iso-codes 4.11.0-1 ii kactivitymanagerd 5.26.0-1 ii kded5 5.98.0-1 ii kinit 5.98.0-1 ii kio 5.98.0-1 ii kpackagetool5 5.98.0-1 ii kwin-common 4:5.26.0-1 ii libappstreamqt2 0.15.5-1 ii libc6 2.35-4 ii libcolorcorrect54:5.26.0-2 ii libcrypt1 1:4.4.28-2 ii libfontconfig1 2.13.1-4.5 ii libfreetype62.12.1+dfsg-3 ii libgcc-s1 12.2.0-3 ii libgps283.22-4.1+b1 ii libice6 2:1.0.10-1 ii libicu7171.1-3 ii libkf5activities5 5.98.0-1 ii libkf5activitiesstats1 5.98.0-1 ii libkf5archive5 5.98.0-1 ii libkf5authcore5 5.98.0-1 ii libkf5baloo55.98.0-1+b1 ii libkf5bookmarks55.98.0-1 ii libkf5calendarevents5 5.98.0-2 ii libkf5completion5 5.98.0-1 ii libkf5config-bin5.98.0-2 ii libkf5configcore5 5.98.0-2 ii libkf5configgui55.98.0-2 ii libkf5configwidgets55.98.0-1 ii libkf5coreaddons5 5.98.0-1 ii libkf5crash55.98.0-1 ii libkf5dbusaddons5 5.98.0-1 ii libkf5declarative5 5.98.0-2 ii libkf5globalaccel-bin 5.98.0-1 ii libkf5globalaccel5 5.98.0-1 ii libkf5guiaddons55.98.0-2 ii libkf5holidays5 1:5.98.0-1 ii libkf5i18n5 5.98.0-1+b1 ii libkf5iconthemes5 5.98.0-2+b1 ii libkf5idletime5 5.98.0-1 ii libkf5jobwidgets5 5.98.0-1 ii libkf5kcmutils5 5.98.0-1 ii libkf5kexiv2-15.0.0 21.12.3-1 ii libkf5kiocore5 5.98.0-1 ii libkf5kiofilewidgets5 5.98.0-1 ii libkf5kiogui5 5.98.0-1 ii libkf5kiowidgets5
Bug#1023174: Acknowledgement (plasma-desktop: Plasma toolbar tooltip window previews not working under wayland: module "org.kde.pipewire" is not installed)
Turns out the missing package is "qml-module-org-kde-pipewire". It should be added as a dependency of plasma-desktop. ; Ralf
Bug#1023174: plasma-desktop: Plasma toolbar tooltip window previews not working under wayland: module "org.kde.pipewire" is not installed
Package: plasma-desktop Version: 4:5.26.0-1 Severity: normal Dear Maintainer, when starting a Plasma Wayland session, window previews are missing in the toolbar tooltips. This is probably related to the fact that the following shows up in the logs: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/PipeWireThumbnail.qml:11:1: module "org.kde.pipewire" is not installed Looks like a missing dependency somewhere? I tried installing libkpipewire by hand but that did not help. Kind regards, Ralf -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER 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 plasma-desktop depends on: ii accountsservice 22.08.8-1+b1 ii breeze 4:5.26.0-1 ii kactivitymanagerd5.26.0-1 ii kde-cli-tools4:5.26.0-1 ii kded55.98.0-1 ii kio 5.98.0-1 ii kpackagetool55.98.0-1 ii layer-shell-qt 5.26.0-1 ii libaccounts-qt5-11.16-2 ii libc62.35-4 ii libglib2.0-0 2.74.0-3 ii libibus-1.0-51.5.27-2+b1 ii libkaccounts24:21.12.3-1 ii libkf5activities55.98.0-1 ii libkf5activitiesstats1 5.98.0-1 ii libkf5authcore5 5.98.0-1 ii libkf5baloo5 5.98.0-1+b1 ii libkf5bookmarks5 5.98.0-1 ii libkf5codecs55.98.0-1 ii libkf5completion55.98.0-1 ii libkf5configcore55.98.0-1 ii libkf5configgui5 5.98.0-1 ii libkf5configwidgets5 5.98.0-1 ii libkf5coreaddons55.98.0-1 ii libkf5crash5 5.98.0-1 ii libkf5dbusaddons55.98.0-1 ii libkf5declarative5 5.98.0-2 ii libkf5globalaccel-bin5.98.0-1 ii libkf5globalaccel5 5.98.0-1 ii libkf5guiaddons5 5.98.0-2 ii libkf5i18n5 5.98.0-1+b1 ii libkf5iconthemes55.98.0-2+b1 ii libkf5itemviews5 5.98.0-1 ii libkf5jobwidgets55.98.0-1 ii libkf5kcmutils5 5.98.0-1 ii libkf5kcmutilscore5 5.98.0-1 ii libkf5kdelibs4support5 5.98.0-1 ii libkf5kiocore5 5.98.0-1 ii libkf5kiofilewidgets55.98.0-1 ii libkf5kiogui55.98.0-1 ii libkf5kiowidgets55.98.0-1 ii libkf5newstuffcore5 5.98.0-1 ii libkf5notifications5 5.98.0-1 ii libkf5notifyconfig5 5.98.0-1 ii libkf5package5 5.98.0-1 ii libkf5plasma55.98.0-1 ii libkf5plasmaquick5 5.98.0-1 ii libkf5quickaddons5 5.98.0-2 ii libkf5runner55.98.0-1 ii libkf5service-bin5.98.0-1 ii libkf5service5 5.98.0-1 ii libkf5solid5 5.98.0-1 ii libkf5sonnetcore55.98.0-1 ii libkf5sonnetui5 5.98.0-1 ii libkf5widgetsaddons5 5.98.0-1 ii libkf5windowsystem5 5.98.0-1 ii libkf5xmlgui55.98.0-1+b1 ii libkuserfeedbackcore11.2.0-2 ii libkworkspace5-5 4:5.26.0-2 ii libnotificationmanager1 4:5.26.0-2 ii libpackagekitqt5-1 1.0.2-1 ii libphonon4qt5-4 4:4.11.1-4 ii libprocesscore9 4:5.26.0-2+b1 ii libqt5concurrent55.15.6+dfsg-2 ii libqt5core5a 5.15.6+dfsg-2 ii libqt5dbus5 5.15.6+dfsg-2 ii libqt5gui5 5.15.6+dfsg-2 ii libqt5network5 5.15.6+dfsg-2 ii libqt5qml5 5.15.6+dfsg-2 ii libqt5quick5 5.15.6+dfsg-2 ii libqt5quickwidgets5
Bug#1023173: freeture: not installable, depends on libaravis-0.6-0
Package: freeture Version: 1.3.0-1+b1 Severity: serious Hi, freeture is not installable in sid as it depends on libaravis-0.6-0, which only exists in oldstable. -Ralf.
Bug#1023172: dropwatch: not installable since dependency on outdated libbinutils
Package: dropwatch Version: 1.5.3-1+b2 Severity: serious Hi, dropwatch is not installable in sid as it depends on libbinutils (< 2.35.1), however the current version of that package in sid is 2.39-8. -Ralf.
Bug#1023171: cernlib: unsatisfiable dependency on geant321-doc
Package: cernlib Version: 20061220+dfsg3-4.4 Severity: serious Hi, cernlib is not installable in sid as it depends on geant321-doc, which is not available in sid. -Ralf.
Bug#1023116: gitlab-ci-multi-runner build-depends on non-existing golang-github-gorilla-context-dev
Source: gitlab-ci-multi-runner Version: 13.3.1+dfsg-4 Severity: serious Hi, gitlab-ci-multi-runner build-depends on golang-github-gorilla-context-dev but that package does not exist in sid any more (it only exists in stable and older). -Ralf.
Bug#1023114: libaws: build-depends on crufty libtemplates-parser14-dev
Source: libaws Version: 20.2-2 Severity: serious Hi, libaws build-depends on libtemplates-parser14-dev which is not installable, and which seems to be cruft since the current version of libtemplates-parser in sid produces libtemplates-parser15-dev . -Ralf.
Bug#664396: vsdump: Helping to update to packaging format 3.0
Raising severity to serious as dpatch is now removed from sid, which makes the package FTBFS. -Ralf.
Bug#1022927: libghc-aeson-dev depends on non-existing libghc-semialign-dev-1.2.0.1-ebc3a
Package: libghc-aeson-dev Version: 2.0.3.0-1+b4 Severity: serious Hi, libghc-aeson-dev on amd64c depends on libghc-semialign-dev-1.2.0.1-ebc3a which does not exist in the archive. The situation is the same on other arches with a different hash of libghc-semialign-dev-1.2.0.1. -Ralf.
Bug#1022867: libghc-persistable-record-doc: depends on non-existing haddock-interface-35
Package: libghc-persistable-record-doc Version: 0.6.0.5-1 Severity: serious Hi, libghc-persistable-record-doc depends on haddock-interface-35 but that package does not exist in the archive. -Ralf.
Bug#1022866: libghc-product-isomorphic-doc: depends on non-existing haddock-interface-35
Package: libghc-product-isomorphic-doc Version: 0.0.3.3-2 Severity: serious Hi, libghc-dice-doc depends on haddock-interface-35 but that package does not exist in the archive. -Ralf.
Bug#1022842: libghc-dice-doc: depends on non-existing haddock-interface-35
Package: libghc-dice-doc Version: 0.1.0.1-1 Severity: serious Hi, libghc-dice-doc depends on haddock-interface-35 but that package does not exist in the archive. -Ralf.
Bug#1022841: libghc-lambdabot-core-doc: unsatisfiable sdependency on haddock-interface-35
Package: libghc-lambdabot-core-doc Version: 5.3.0.1-1 Severity: serious Hi, libghc-lambdabot-core-doc depends on haddock-interface-35 but that package does not exist in the archive. -Ralf
Bug#1022796: haskell-heist unsatisfiable build-dependency libghc-aeson-dev < 1.5
Source: haskell-heist Version: 1.1.0.1-3 Severity: serious Hi, haskell-heist build-depends on libghc-aeson-dev (<< 1.5) but the version of that package in sid is 2.0.3.0-1. -Ralf.
Bug#1022795: libghc-crypto-numbers-doc: depends on non-existing haddock-interface-35
Package: libghc-crypto-numbers-doc Version: 0.2.7-10 Severity: serious Hi, libghc-crypto-numbers-doc depends on haddock-interface-35 but this package does not exist in the archive. -Ralf.
Bug#1022794: libghc-highlighting-kate-doc: depends on non-existing haddock-interface-35
Package: libghc-highlighting-kate-doc Version: 0.6.4-6 Severity: serious Hi, libghc-highlighting-kate-doc depends on haddock-interface-35 which does not exist in the archive. -Ralf.
Bug#1022786: glirc: unsatisfiable build-dependency libghc-attoparsec-dev (<< 0.14)
Source: glirc Version: 2.36-3 Severity: serious Hi, glirc build-depends on libghc-attoparsec-dev (<< 0.14). However, the current version of that package in sid is 0.14.4-2+b1. -Ralf.
Bug#1022785: guacamole-client: build-depends on removed libangular-maven-plugin-java
Source: guacamole-client Version: 0.9.9+dfsg-1 Severity: serious Hi, guacamole-client build-depends on libangular-maven-plugin-java but that package only exists in oldoldstable. -Ralf.
Bug#1019554: Bug#1021496: anacron: cron.daily stopped executing a month ago
Hi all, FWIW, just enabling and starting both the service and the timer did solve the problem. systemctl enable anacron.service anacron.timer systemctl start anacron.service anacron.timer ; Ralf
Bug#1021496: anacron: cron.daily stopped executing a month ago
Dear Lance, This is a problem, since obviously many things rely on these cron jobs running regularly. For example, one of my SSL certificates expired because of this. Kind regards, Ralf I have merged this bug with #1019554. The problem was introduced in -33. I've noticed that it resulted in an incomplete cleanup on upgrade. It has been fixed in -35 but the service still doesn't start due to the cleanup. Ah, indeed the service was 'disabled'. My tested working solution is to backup existing cron files, remove anacron, manually remove the files and install the -35 version. Specifically, I removed: /var/lib/systemd/deb-systemd-helper-*/ ... anacron files /var/lib/dpkg/info/anacron.* files /var/spool/anacron /etc/anacrontab Sorry for the inconvenience. Please let me know if this works as it seems to fix it on my system. Uh, that sounds pretty scary. I already have the -35 installed so the buggy postrm should be gone. Shouldn't it be enough to manually enable and start the service and timer? I have done that now. FWIW I agree with the sentiment in that bug that anacron should not touch any of these systemd files in its postrm or purge logic. That's what the init-system-helpers are for. They are very well-tested and if they leave behind dangling symlinks that should be brought up with them. Fixing it only for anacron wouldn't help other packages. Kind regards, Ralf
Bug#1021496: anacron: cron.daily stopped executing a month ago
Package: anacron Version: 2.3-35 Severity: important Dear Maintainer, I just realized that my cron.daily jobs stopped being executed about a month ago. 'sudo journalctl | grep cron.daily' shows Sep 04 14:28:19 r-thinktop anacron[12633]: Job `cron.daily' started Sep 04 14:28:19 r-thinktop anacron[13691]: Updated timestamp for job `cron.daily' to 2022-09-04 Sep 04 14:28:20 r-thinktop anacron[12633]: Job `cron.daily' terminated Sep 05 09:59:36 r-thinktop anacron[34905]: Will run job `cron.daily' in 5 min. Sep 05 10:04:36 r-thinktop anacron[34905]: Job `cron.daily' started Sep 05 10:04:36 r-thinktop anacron[36056]: Updated timestamp for job `cron.daily' to 2022-09-05 Sep 05 10:04:37 r-thinktop anacron[34905]: Job `cron.daily' terminated Sep 06 09:24:00 r-thinktop anacron[40089]: Will run job `cron.daily' in 5 min. Sep 06 09:29:00 r-thinktop anacron[40089]: Job `cron.daily' started Sep 06 09:29:00 r-thinktop anacron[40715]: Updated timestamp for job `cron.daily' to 2022-09-06 Sep 06 09:29:01 r-thinktop anacron[40089]: Job `cron.daily' terminated Sep 07 09:46:33 r-thinktop anacron[54913]: Will run job `cron.daily' in 5 min. Sep 07 09:51:33 r-thinktop anacron[54913]: Job `cron.daily' started Sep 07 09:51:33 r-thinktop anacron[55857]: Updated timestamp for job `cron.daily' to 2022-09-07 Sep 07 09:51:33 r-thinktop anacron[54913]: Job `cron.daily' terminated Sep 08 11:38:05 r-thinktop anacron[67536]: Will run job `cron.daily' in 5 min. Sep 08 11:43:05 r-thinktop anacron[67536]: Job `cron.daily' started Sep 08 11:43:05 r-thinktop anacron[69218]: Updated timestamp for job `cron.daily' to 2022-09-08 Sep 08 11:43:06 r-thinktop anacron[67536]: Job `cron.daily' terminated and then it ends. This is a problem, since obviously many things rely on these cron jobs running regularly. For example, one of my SSL certificates expired because of this. Kind regards, Ralf -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages anacron depends on: ii libc6 2.35-1 ii lsb-base 11.4 ii sysvinit-utils [lsb-base] 3.05-6 Versions of packages anacron recommends: ii cron [cron-daemon] 3.0pl1-149 Versions of packages anacron suggests: ii postfix [mail-transport-agent] 3.6.4-1+b3 ii powermgmt-base 1.37 ii rsyslog [system-log-daemon] 8.2208.0-1 -- no debconf information
Bug#1014133: asterisk: Asterisk fails to build from source
On Fri, Jul 01, 2022 at 01:14:28PM +0200, Bernhard Schmidt wrote:
> As Jonas already wrote, please use something like sbuild/cowbuilder. The
> packages for Bullseye have been built from source by the buildd, so
> generally they should work just fine.
I can confirm that the package builds with sbuild.
I was bitten by #725434 #576425 #823651 #856434
my solution was to symlink /tmp to /tmp/user/{1,1000} in the chroot (I
don't have pbuilder installed in the chroot, is probably installed
during build and later removed again).
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: www.runtux.com
Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1017613: kwin-x11 session stops working (semi-freeze) every few days
Package: kwin-x11 Version: 4:5.25.4-2 Severity: important Dear Maintainer, The latest update from kwin 4:5.24.5-1+b1 to 4:5.25.4-2 has made KDE very unreliable for me: every other day, the entire session just basically freezes up; I can still move the cursor, but that's about it. Just before that happens, I usually get a black rectangle in the bottom right corner of the screen, where the Plasma notifications usually appear. At that point I can still interact with the foreground application, but if I do alt-tab, then the session is doomed and I need to Ctrl-Alt-Backspace, losing all unsaved data. Also see https://bugs.kde.org/show_bug.cgi?id=457847. Kind regards, Ralf -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kwin-x11 depends on: ii kwin-common4:5.25.4-2 ii libc6 2.34-3 ii libepoxy0 1.5.10-1 ii libgcc-s1 12.1.0-8 ii libkdecorations2-5v5 4:5.25.4-1 ii libkf5configcore5 5.96.0-1 ii libkf5configgui5 5.96.0-1 ii libkf5configwidgets5 5.96.0-1 ii libkf5coreaddons5 5.96.0-1 ii libkf5crash5 5.96.0-1 ii libkf5globalaccel-bin 5.96.0-1 ii libkf5globalaccel5 5.96.0-1 ii libkf5i18n55.96.0-1 ii libkf5notifications5 5.96.0-1 ii libkf5plasma5 5.96.0-1 ii libkf5service-bin 5.96.0-1 ii libkf5service5 5.96.0-1 ii libkf5windowsystem55.96.0-1 ii libkwineffects13 4:5.25.4-2 ii libkwinglutils13 4:5.25.4-2 ii libkwinxrenderutils13 4:5.25.4-2 ii libqaccessibilityclient-qt5-0 0.4.1-1+b1 ii libqt5core5a 5.15.4+dfsg-5 ii libqt5dbus55.15.4+dfsg-5 ii libqt5gui5 5.15.4+dfsg-5 ii libqt5qml5 5.15.4+dfsg-4 ii libqt5widgets5 5.15.4+dfsg-5 ii libqt5x11extras5 5.15.4-2 ii libstdc++6 12.1.0-8 ii libx11-6 2:1.8.1-2 ii libxcb-composite0 1.15-1 ii libxcb-keysyms10.4.0-1+b2 ii libxcb-randr0 1.15-1 ii libxcb-render0 1.15-1 ii libxcb-shape0 1.15-1 ii libxcb-xfixes0 1.15-1 ii libxcb11.15-1 ii libxi6 2:1.8-1 kwin-x11 recommends no packages. kwin-x11 suggests no packages. -- no debconf information
Bug#1014651: firmware-misc-nonfree: Missing latest i915/skl_guc firmware
Package: firmware-misc-nonfree Version: 20210818-1 Severity: normal Dear Maintainer, on boot, my system says it needs this firmware: Jul 09 09:59:17 r-thinktop kernel: i915 :00:02.0: firmware: failed to load i915/skl_guc_69.0.3.bin (-2) Jul 09 09:59:17 r-thinktop kernel: firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware Jul 09 09:59:17 r-thinktop kernel: i915 :00:02.0: Direct firmware load for i915/skl_guc_69.0.3.bin failed with error -2 Jul 09 09:59:17 r-thinktop kernel: i915 :00:02.0: [drm] GuC firmware i915/skl_guc_69.0.3.bin: fetch failed with error -2 Jul 09 09:59:17 r-thinktop kernel: i915 :00:02.0: [drm] GuC firmware(s) can be downloaded from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 Jul 09 09:59:17 r-thinktop kernel: i915 :00:02.0: [drm] GuC firmware i915/skl_guc_69.0.3.bin version 0.0 Jul 09 09:59:17 r-thinktop kernel: i915 :00:02.0: [drm] GuC is uninitialized However, it looks like this package is missing the required version of that firmware: $ dpkg -S i915/skl_guc firmware-misc-nonfree: /lib/firmware/i915/skl_guc_33.0.0.bin firmware-misc-nonfree: /lib/firmware/i915/skl_guc_ver1.bin firmware-misc-nonfree: /lib/firmware/i915/skl_guc_32.0.3.bin firmware-misc-nonfree: /lib/firmware/i915/skl_guc_49.0.1.bin firmware-misc-nonfree: /lib/firmware/i915/skl_guc_ver9_33.bin firmware-misc-nonfree: /lib/firmware/i915/skl_guc_62.0.0.bin firmware-misc-nonfree: /lib/firmware/i915/skl_guc_ver6_1.bin firmware-misc-nonfree: /lib/firmware/i915/skl_guc_ver6.bin firmware-misc-nonfree: /lib/firmware/i915/skl_guc_ver4.bin Would be nice to get an update with the firmware needed for current kernels. :) Kind regards, Ralf -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-misc-nonfree depends on no packages. firmware-misc-nonfree recommends no packages. Versions of packages firmware-misc-nonfree suggests: ii initramfs-tools 0.141 -- no debconf information
Bug#1014649: linux-image-5.18.0-2-amd64: System fails to sspend when bluetooth headset is connected
00)
Jul 09 09:07:59 r-thinktop kernel: ata1: SATA link up 6.0 Gbps (SStatus 133
SControl 300)
Jul 09 09:07:59 r-thinktop kernel: ata4.00: ACPI cmd
f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
Jul 09 09:07:59 r-thinktop kernel: ata4.00: ACPI cmd ef/10:03:00:00:00:a0(SET
FEATURES) filtered out
Jul 09 09:07:59 r-thinktop kernel: ata1.00: ACPI cmd
f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
Jul 09 09:07:59 r-thinktop kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0(SET
FEATURES) filtered out
Jul 09 09:07:59 r-thinktop kernel: ata1.00: ACPI cmd
f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
Jul 09 09:07:59 r-thinktop kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0(SET
FEATURES) filtered out
Jul 09 09:07:59 r-thinktop kernel: ata4.00: ACPI cmd
f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
Jul 09 09:07:59 r-thinktop kernel: ata4.00: ACPI cmd ef/10:03:00:00:00:a0(SET
FEATURES) filtered out
Jul 09 09:07:59 r-thinktop kernel: ata1.00: configured for UDMA/100
Jul 09 09:07:59 r-thinktop kernel: ahci :00:17.0: port does not support
device sleep
Jul 09 09:07:59 r-thinktop kernel: ata4.00: configured for UDMA/133
Jul 09 09:07:59 r-thinktop kernel: e1000e :00:1f.6 enp0s31f6: Failed to
disable ULP
Jul 09 09:07:59 r-thinktop kernel: OOM killer enabled.
Jul 09 09:07:59 r-thinktop kernel: Restarting tasks ... done.
Jul 09 09:07:59 r-thinktop rtkit-daemon[1422]: The canary thread is apparently
starving. Taking action.
Jul 09 09:07:59 r-thinktop systemd-sleep[3045069]: System returned from sleep
state.
Jul 09 09:07:59 r-thinktop rtkit-daemon[1422]: Demoting known real-time threads.
Jul 09 09:07:59 r-thinktop rtkit-daemon[1422]: Successfully demoted thread
3043314 of process 3043138.
Jul 09 09:07:59 r-thinktop systemd[1]: Starting Daily apt download activities...
Jul 09 09:07:59 r-thinktop rtkit-daemon[1422]: Successfully demoted thread
2976804 of process 1841.
Jul 09 09:07:59 r-thinktop systemd[1]: NetworkManager-dispatcher.service:
Deactivated successfully.
Jul 09 09:07:59 r-thinktop rtkit-daemon[1422]: Demoted 2 threads.
Jul 09 09:07:59 r-thinktop bluetoothd[990]: Controller resume with wake event
0x0
Jul 09 09:07:59 r-thinktop kernel: PM: suspend exit
Kind regards,
Ralf
-- Package-specific info:
** Version:
Linux version 5.18.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian
11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.50.20220615) #1 SMP
PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16)
** Command line:
BOOT_IMAGE=/vmlinuz-5.18.0-2-amd64 root=/dev/mapper/vg-root ro quiet splash
** Tainted: PUOE (12353)
* proprietary module was loaded
* taint requested by userspace application
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
Unable to read kernel log; any relevant messages should be attached
** Model information
sys_vendor: LENOVO
product_name: 20ENCTO1WW
product_version: ThinkPad P50
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N1EET83W (1.56 )
board_vendor: LENOVO
board_name: 20ENCTO1WW
board_version: Not Defined
** Loaded modules:
nvidia_uvm(POE)
hid_corsair
appledisplay
apple_mfi_fastcharge
ufs
qnx4
hfsplus
hfs
cdrom
minix
msdos
jfs
xfs
uinput
nf_conntrack_netbios_ns
nf_conntrack_broadcast
ctr
ccm
xt_MASQUERADE
nf_conntrack_netlink
xfrm_user
xfrm_algo
xt_addrtype
br_netfilter
bridge
stp
llc
rfcomm
nf_nat_tftp
ip6t_REJECT
nf_reject_ipv6
ipt_REJECT
nf_reject_ipv4
xt_conntrack
nft_chain_nat
nf_nat
nf_conntrack_tftp
xt_CT
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
xt_tcpudp
overlay
ip6_tables
nft_compat
ip_set
nf_tables
nfnetlink
qrtr
cmac
algif_hash
algif_skcipher
af_alg
bnep
binfmt_misc
nls_ascii
nls_cp437
vfat
fat
intel_rapl_msr
intel_rapl_common
intel_pmc_core_pltdrv
intel_pmc_core
btusb
btrtl
btbcm
btintel
btmtk
x86_pkg_temp_thermal
intel_powerclamp
iwlmvm
bluetooth
snd_ctl_led
coretemp
snd_hda_codec_realtek
mac80211
snd_hda_codec_generic
snd_hda_codec_hdmi
kvm_intel
uvcvideo
snd_hda_intel
libarc4
snd_intel_dspcfg
jitterentropy_rng
videobuf2_vmalloc
snd_intel_sdw_acpi
videobuf2_memops
sha512_ssse3
mei_hdcp
mei_wdt
joydev
kvm
iwlwifi
snd_hda_codec
sha512_generic
videobuf2_v4l2
snd_hda_core
irqbypass
cuse
videobuf2_common
snd_hwdep
rapl
thinkpad_acpi
nvidia_drm(POE)
intel_cstate
drbg
snd_pcm
iTCO_wdt
nvram
cfg80211
intel_uncore
mei_me
videodev
ansi_cprng
platform_profile
intel_pmc_bxt
snd_timer
pcspkr
ledtrig_audio
iTCO_vendor_support
rmi_smbus
snd
nvidia_modeset(POE)
ecdh_generic
mc
efi_pstore
rmi_core
watchdog
wmi_bmof
ee1004
intel_wmi_thunderbolt
ecc
serio_raw
soundcore
mei
ie31200_edac
intel_pch_thermal
ac
rfkill
evdev
sg
nvidia(POE)
nfsd
auth_rpcgss
ipmi_devintf
nfs_acl
ipmi_msghandler
lockd
msr
grace
parport_pc
ppdev
lp
parport
sunrpc
fuse
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
blake2b_generic
zstd_compress
dm_crypt
dm_mod
efivarfs
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xo
Bug#1014410: xnecview: No longer correctly displays antenna geometry
Package: xnecview Version: 1.37-1 Severity: normal xnecview can - Display the antenna geometry if given a .nec file as input - Display the antenna pattern and other graphs if given the output of nec2c The latter still works. The display of the antenna geometry no longer works, I'm including an example .nec file and the corresponding output as well as the expected output. This is a regression from Debian Buster. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.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 xnecview depends on: ii libc6 2.31-13+deb11u3 ii libglib2.0-0 2.66.8-1 ii libgtk2.0-0 2.24.33-2 ii libpng16-16 1.6.37-3 xnecview recommends no packages. xnecview suggests no packages. -- no debconf information CM -r 0.0291 -d 0.0424 -l 0.1712 -4 0.1174 CM FRQ: 430.00 fw: 6.85 bw: -2.58 CM FRQ: 435.00 fw: 6.62 bw: -4.50 CM FRQ: 440.00 fw: 6.35 bw: -5.41 CM SWR: 1.79 1.11 1.81 CE GA 1 17 0.0291 -90 90 0.00075 GM 0 0 0 0 0 0.1174 0 0 1 GA 2 17 0.0291 90 270 0.00075 GM 0 0 0 0 0 -0.1174 0 0 2 GW 3 19 0 0 0.0291 -0.1174 0 0.0291 0.00075 GW 4 19 0 0 -0.0291 -0.1174 0 -0.0291 0.00075 GW 5 19 0 0 0.0291 0.1174 0 0.0291 0.00075 GW 6 19 0 0 -0.0291 0.1174 0 -0.0291 0.00075 GW 7 5 0 0 0.0291 0 0 -0.0291 0.00075 GW 8 5 0 0 -0.0291 0 0 -0.0715 0.00075 GW 9 57 0.1712 0 -0.0715 0 0 -0.0715 0.00075 GW 10 57 -0.1712 0 -0.0715 0 0 -0.0715 0.00075 GM 0 0 0 270 0 0 0 0.1712 0 GE 0 EK 1 LD 5 0 0 0 3.77358e+07 0 0 EX 0 6 1 0 1 0 0 0 0 0 FR 0 21 0 0 430 0.5 RP 0 37 73 0 0 0 5 5 0 0 EN
Bug#1014133: asterisk: Asterisk fails to build from source
On Thu, Jun 30, 2022 at 08:28:19PM +0200, Jonas Smedegaard wrote: > I am not very familiar with asterisk as packaged for Bullseye - only > know that it was pretty unusually done. > > Maybe try build in a pristine build-environment. What do you mean by this? > Maybe try get directly in touch with Bernhard Schmidt who prepared the > work for Bullseye but possibly doesn't follow these bugs nowadays. I'll try! Can you give me a hint how to find his mail address? Thanks for your *very* quick answer! Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting www: www.runtux.com Reichergasse 131, A-3411 Weidling email: off...@runtux.com
Bug#1014133: asterisk: Asterisk fails to build from source
Package: asterisk Version: 1:16.16.1~dfsg-1+deb11u1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, I'm trying to build asterisk from source (bullseye) using: dpkg-buildpackage -rfakeroot Looks like the verification of the needed pjproject sub-project fails. The last relevant lines from configure: configure:9241: checking for embedded pjproject (may have to download) configure:9243: result: configuring configure:9310: result: failed configure:9312: Unable to configure third-party/pjproject configure:9314: error: Re-run the ./configure command with 'NOISY_BUILD=yes' appended to see error details. If I re-run this, it tries to download the pjproject tarball and fails to verify the checksum. If I clean (debian/rules clean) and configure by hand it seems to be able to verify (but fails later with a different error). Let me know if I'm missing some trick here and if you need additional information. My plan (why I'm trying to re-build) is to include a simple patch to res/res_pjsip_messaging.c to allow content-types other than text/plain. But I'm failing on the unmodified Debian sources. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-15-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.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 asterisk depends on: ii adduser 3.118 ii asterisk-config 1:16.16.1~dfsg-1+deb11u1 ii asterisk-core-sounds-en 1.6.1-1 ii asterisk-modules 1:16.16.1~dfsg-1+deb11u1 ii libc62.31-13+deb11u3 ii libcap2 1:2.44-1 ii libcrypt11:4.4.18-4 ii libedit2 3.1-20191231-2+b1 ii libjansson4 2.13.1-1.1 ii libpopt0 1.18-2 ii libsqlite3-0 3.34.1-3 ii libssl1.11.1.1n-0+deb11u3 ii libsystemd0 247.3-7 ii liburiparser10.9.4+dfsg-1+deb11u1 ii libuuid1 2.36.1-8+deb11u1 ii libxml2 2.9.10+dfsg-6.7+deb11u2 ii libxslt1.1 1.1.34-4 ii lsb-base 11.1.0 Versions of packages asterisk recommends: ii asterisk-moh-opsound-gsm 2.03-1.1 ii asterisk-voicemail [asterisk-voicemail-storage] 1:16.16.1~dfsg-1+deb11u1 ii sox 14.4.2+git20190427-2 Versions of packages asterisk suggests: pn asterisk-dahdi ii asterisk-dev 1:16.16.1~dfsg-1+deb11u1 pn asterisk-doc pn asterisk-ooh323 pn asterisk-opus pn asterisk-vpb -- no debconf information
Bug#1013797: grub-efi: grub no longer offers to boot Windows
Ah, turns out I need to add "GRUB_DISABLE_OS_PROBER=false" in /etc/default/grub. I think it is bad to silently change the default in an upgrade here, since it can leave people locked out of an OS they need. GRUB_DISABLE_OS_PROBER is not even listed in /etc/default/grub.ucf-dist. Kind regards, Ralf
Bug#1013797: grub-efi: grub no longer offers to boot Windows
Package: grub-efi
Version: 2.06-3
Severity: important
Dear Maintainer,
After doing a system update, the option to boot Windows has disappeared from
Grub.
I have not changed anything else.
This will be a big problem the next time I actually need to boot Windows.
Kind regards,
Ralf
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/mapper/vg-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda2 /boot ext4 rw,relatime 0 0
/dev/mapper/vg-home /home ext4 rw,relatime 0 0
/dev/sda1 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
/dev/mapper/store /mnt/store ext4 rw,relatime 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="2"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2
--hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2
2af046c2-1c1f-43ca-9692-7ea1d357493b
else
search --no-floppy --fs-uuid --set=root 2af046c2-1c1f-43ca-9692-7ea1d357493b
fi
font="/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=1920x1080,1024x768,auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=3
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=3
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2
--hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2
2af046c2-1c1f-43ca-9692-7ea1d357493b
else
search --no-floppy --fs-uuid --set=root 2af046c2-1c1f-43ca-9692-7ea1d357493b
fi
insmod png
if background_image /grub/.background_cache.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=keep
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-8f0db0a1-2c26-4b6c-a132-e8292709197e' {
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2
--hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2
2af046c2-1c1f-43ca-9692-7ea1d357493b
else
search --no-floppy --fs-uuid --set=root
2af046c2-1c1f-43ca-9692-7ea1d357493b
fi
echo'Loading Linux 5.18.0-2-amd64 ...'
linux /vmlinuz-5.18.0-2-amd64 root=/dev/mapper/vg-root ro quiet
splash
echo'Loading initial ramdisk ...'
initrd /initrd.img-5.18.0-2-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-8f0db0a1-2c26-4b6c-a132-e8292709197e' {
menuentry 'Debian GNU/Linux, with Linux 5.18.0-2-amd64' --class debian
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-5.
Bug#1012464: libvtk6.3: not installable in sid
Package: libvtk6.3 Version: 6.3.0+dfsg2-8.1+b1 Severity: serious Hi, libvtk6.3 is currently not installable in sid as it depends on libjsoncpp24. That package only exists in stable, in sid and testing we have libjsoncpp25. -Ralf.
Bug#1012326: python-jenkinsapi: build-depends on pylint3
Source: python-jenkinsapi Version: 0.3.11-5 Severity: serious Usertags: edos-uninstallable Hi, python-jenkinsapi build-depends on pylint3 but that package only exists in stable and older stable releases. -Ralf.
Bug#1012320: materialize: build-depends on non-existing libjs-anime
Source: materialize Version: 1.1.0~alpha+ds-1 Severity: serious Usertags: edos-uninstallable Hi, materialize build-depends on libjs-anime, which does not exist in sid. -Ralf.
Bug#1009353: Lamobo R1
Package: installation-reports Boot method: SD Card with u-boot Image version: https://deb.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/ Date: 2022-04-12 08:00 Machine: Lamobo R1 Processor: Allwinner A20 @ 1Ghz Memory: 1GiB DDR3 @ 432MHz Partitions: Output of lspci -knn (or lspci -nn): Base System Installation Checklist: Initial boot: [0] Detect network card:[0] Configure network: [E] Detect media: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: The installer runs through to the configuration of the network. An attempt is made to configure the network with DHCP. That fails. Even after manually configuring the network, the network will not work. This prevents the installation from continuing. Previous tests with Debian had the same error during installation. This bug could be corrected manually under Debian 9. To do this, the shell had to be called in the installer. The command "modprobe b53_mdio" had to be executed. After that, "Detect network hardware" was re-run and DHCP worked fine. The Lamobo R1 and DHCP work when using a preconfigured Ubuntu image for testing. Serial port output: U-Boot SPL 2021.01+dfsg-5 (May 23 2021 - 04:32:45 +) DRAM: 1024 MiB CPU: 91200Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2021.01+dfsg-5 (May 23 2021 - 04:32:45 +) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Lamobo R1 I2C: ready DRAM: 1 GiB MMC: mmc@1c0f000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment HDMI connected: Setting up a 1280x1024 dvi console (overscan 0x0) In:serial Out: vga Err: vga Net: eth0: ethernet@1c5 starting USB... Bus usb@1c14000: USB EHCI 1.00 Bus usb@1c14400: USB OHCI 1.0 Bus usb@1c1c000: USB EHCI 1.00 scanning bus usb@1c14000 for devices... 1 USB Device(s) found scanning bus usb@1c14400 for devices... 4 USB Device(s) found scanning bus usb@1c1c000 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 => boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 1575 bytes read in 2 ms (768.6 KiB/s) ## Executing script at 4310 Mainline u-boot / new-style environment detected. 4964864 bytes read in 279 ms (17 MiB/s) 26960 bytes read in 9 ms (2.9 MiB/s) 22646036 bytes read in 1263 ms (17.1 MiB/s) Booting the Debian installer... ## Flatten
Bug#1007822: "ssh -XAf localhost xeyes" uses 100% CPU after losing tty
Hi all, I am also seeing 100% CPU load from SSH when using it with autossh to set up port forwarding in the background (no X11 forwarding involved): /usr/bin/autossh -M 0 -N -o "ServerAliveInterval 30" -R $IP:$PORT1:localhost:443 -R $IP:$PORT2:localhost:80 $USER@$HOST -i $KEY This only recently started with the latest 'apt upgrade'. ; Ralf On Thu, 17 Mar 2022 13:26:09 +0100 Harald Dunkel wrote: Package: openssh-client Version: 1:8.9p1-3 If I use ssh -XAf localhost xterm to run a second xterm, then ssh eats up 100% CPU after closing the first xterm. Same happens for xeyes or other XWindow apps. It doesn't have to be localhost, either. "nohup ssh -XAf ..." seems to work, but for Bullseye it works very well without nohup. SHELL is bash 5.1-6 Regards Harri
Bug#1006626: biber: Lots of "Use of uninitialized value" warnings after biber update
Package: biber
Version: 2.17-2
Severity: normal
Dear Maintainer,
I updated biber to 2.17, and now I am getting many warnings (thousands of them
for large bib files, which significantly slows down biber itself) from files
that were clean before. The warnings all look like this:
```
Use of uninitialized value $opt in hash element at
/usr/share/perl5/Biber/Config.pm line 977.
Use of uninitialized value within %Biber::Config::CONFIG_OPTSCOPE_BIBLATEX in
hash dereference at /usr/share/perl5/Biber/Config.pm line 977.
```
Sometimes the line numbers are different (I have seen 967, 972, 977).
*Any* use of biber causes that warning for me, so here is an arbitrary example:
```
\documentclass[10pt,a4paper]{article}
\usepackage[backend=biber]{biblatex}
\addbibresource{bib.bib}
\begin{document}
\fullcite{iris}
\end{document}
```
With `bib.bib` being
```
@inproceedings{iris,
author= {Ralf Jung and
David Swasey and
Filip Sieczkowski and
Kasper Svendsen and
Aaron Turon and
Lars Birkedal and
Derek Dreyer},
title = {{Iris}: Monoids and Invariants as an Orthogonal Basis for
Concurrent
Reasoning},
booktitle = {{POPL}},
year = {2015},
doi = {10.1145/2676726.2676980},
}
```
I reported this upstream at https://github.com/plk/biber/issues/403, but the
maintainer suggested this might be a packaging issues since they could not
reproduce the problem.
Kind regards,
Ralf
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages biber depends on:
ii libautovivification-perl 0.18-1+b4
ii libbusiness-isbn-perl 3.006-1
ii libbusiness-ismn-perl 1.202-1
ii libbusiness-issn-perl 1.005-1
ii libclass-accessor-perl0.51-1
ii libdata-compare-perl 1.27-1
ii libdata-dump-perl 1.25-1
ii libdata-uniqid-perl 0.12-1.1
ii libdate-simple-perl 3.0300-3+b2
ii libdatetime-calendar-julian-perl 0.107-1
ii libdatetime-format-builder-perl 0.8300-1
ii libdatetime-perl 2:1.55-1+b1
ii libencode-eucjpms-perl0.07-3+b10
ii libencode-hanextra-perl 0.23-5+b4
ii libencode-jis2k-perl 0.03-1+b8
ii libfile-slurper-perl 0.013-1
ii libipc-run3-perl 0.048-2
ii liblingua-translit-perl 0.28-1
ii liblist-allutils-perl 0.19-1
ii liblist-moreutils-perl0.430-2
ii liblog-log4perl-perl 1.54-1
ii liblwp-protocol-https-perl6.10-1
ii libparse-recdescent-perl 1.967015+dfsg-2
ii libreadonly-perl 2.050-3
ii libregexp-common-perl 2017060201-1
ii libsort-key-perl 1.33-2+b4
ii libtext-bibtex-perl 0.88-3+b3
ii libtext-csv-perl 2.01-1
ii libtext-csv-xs-perl 1.47-1+b1
ii libtext-roman-perl3.5-2.1
ii libunicode-collate-perl 1.31-1+b1
ii libunicode-linebreak-perl 0.0.20190101-1+b4
ii liburi-perl 5.10-1
ii libwww-perl 6.61-1
ii libxml-libxml-simple-perl 1.01-1
ii libxml-libxslt-perl 1.99-1+b2
ii libxml-writer-perl0.900-1
ii perl [libunicode-collate-perl]5.34.0-3
ii tex-common6.17
Versions of packages biber recommends:
ii texlive-bibtex-extra 2021.20220204-1
biber suggests no packages.
-- no debconf information
Bug#907178: gimp-plugin-registry: resynthesizer not appearing in menu Filters/Enhance
Hi again, the latest changelog for version 9.20200927 of this package says "resynthesizer: ported to python3" However, the resynthesizer still does not work after installing the package (the menu entries simply do not appear). So one of the best features of Gimp is broken for several years now. :( I think the severity of this bug should be raised, since it makes the package entirely useless -- at least for people that care about resynthesizer but none of the other plugins. Kind regards, Ralf
