Bug#1068476: RM: rlog -- leaf package
reassign 1068476 ftp.debian.org retitle 1068476 RM: rlog -- ROM; obsolete dependency of encfs thanks Hallo FTP masters, please remove the source package rlog and all binary packages originating from it (librlog-dev, librlog5v5). This library has been a custom logging framework from the encfs author(s) but it seems like has never been widely accepted and even encfs has transitioned to a more popular solution (elpp) over a decade ago. Therefore, no loss of functionality to expect here, IMHO. Thank you. Best regards, Eduard. * Bastian Germann [Fri, Apr 05 2024, 11:46:56PM]: > Source: rlog > Version: 1.4-4.2 > Severity: wishlist > > clamfs has just lost its dependency on rlog and therefore, rlog is now a leaf > package. > The last upstream release was 15 years ago, so now would be the perfect time > to remove it. > Please consider filing a RM bug on ftp.debian.org.
Bug#1068642: No intuitive way to debug/edit/fix defaults for file types
Package: xdg-utils Version: 1.1.3-4.1 Severity: normal File: /usr/bin/xdg-open Hi, sorry for making this lengthy, but this is first-hand user experience. If TL;DR is wanted, please scroll down to the summary section. This issue has bothered me for a while and I had to report it eventually. I have a mixed system here, not just one single DE. And xdg-open is apparently used in many applications. And the behavior on folders puzzled me: - xdg-open . --> opens VS Code - xdg-open /tmp --> opens QDirStat And the manual of xdg-open does not give me any clue on how to investigate or modify it. Which UI tool can I use? Which CLI tool may I use? The first idea was to use xdg-settings. That tool does NOT HELP ME AT ALL. I can get and check and set something, but WHAT? There is no "list" sub-command in that utility. Okay, so I had to check the internet. Found out about MimeType and found code.desktop and qdirstat.desktop, and found the mime types inode/directory and inode/mountpoint . So I had to read further to create $HOME/.local/share/applications/thunar.desktop which is based on the packaged version, and I added this into it: $ grep Mime $HOME/.local/share/applications/thunar.desktop MimeType=inode/directory;inode/mountpoint; Expected result: - the change should be picked up - the preferred version in user's home should be used Actual result: $ xdg-open /var/tmp [main 2024-04-04T10:41:10.001Z] update#setState idle [main 2024-04-04T10:41:11.720Z] Extension host with pid 1431582 exited with code: 0, signal: unknown. [main 2024-04-04T10:41:11.728Z] [UtilityProcess id: 1, type: fileWatcher, pid: 1431552]: crashed with code 15 and reason 'killed' And it still opens it with code, not thunar. And what is this fileWatcher being killed? So, assuming that it might use a user service for all operations, I have applied "systemctl --user restart xdg..." on all services. Result: no luck, nothing has changed. So eventually I hat do dig further, after finding out that those are just shell scripts, which brings us to "xdg-mime query default inode/directory" returning code.desktop. And only after bash-x-ing this I have learned about the existence of defaults.list file. And I still had no idea how to create or modify it. So I had to use SO again and found https://unix.stackexchange.com/questions/36380/how-to-properly-and-easily-configure-xdg-open-without-any-environment#59088 And only after creating the file with the following I get to my actual target. [Default Applications] inode/directory=thunar.desktop inode/mountpoint=thunar.desktop So, my summary, what would I expect: - the manpages shall document the related configuration files, at least briefly - default.list should have a manpage (no user should be forced to use web sources for such basic knowledge) - the MimeType of the user's desktop files probably should be considered first, and the system versions later - there should be some kind of verbosity switch, which would print relevant information along the decision making, without having to dig through all the shell debug log. Best regards, Eduard. -- Package-specific info: Desktop environment: XDG_CURRENT_DESKTOP= -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.2 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled xdg-utils depends on no packages. Versions of packages xdg-utils recommends: ii libfile-mimeinfo-perl 0.34-1 ii libnet-dbus-perl 1.2.0-2+b2 ii libx11-protocol-perl 0.56-9 ii x11-utils 7.7+6+b1 ii x11-xserver-utils 7.7+10+b1 xdg-utils suggests no packages. -- no debconf information -- Noch freiwillige Tester für svn-inject und svn-uupdate hier? Wenn du mir erklärst, was das is ;) Greek0: Dope für Maintainer, echt guter Stoff.
Bug#1068126: firefox: No video, no codecs found
Package: firefox
Version: 124.0.1-1
Severity: important
Dear Maintainer,
* What led up to the situation?
Last week's dist-upgrade, including ffmpeg and libavcodec and related
libs.
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
Observed that ALL video playback (with HTML5 tech) ceased to work,
either no video starting at all or some error report, depending on the
page. YT can generate a debug report, I could add it but there is not
much to see, the main info is:
"debug_error": "{\"errorCode\":\"html5.missingapi\",\"errorMessage\":\"This
video format is not
supported.\",\"SN\":\"HTML5_NO_AVAILABLE_FORMATS_FALLBACK\",\"yn\":\"\",\"wK\":\"nocodecs.1;a6s.0\"
- next experiment: try firefox-esr. Result: no problem there, videos do work
as usual
- next experiment: download the upstream build and unpack it. Result: works as
supposed. Also tried the 125-beta, also works there
- next experiments: reinstall ffmpeg, reinstall libavcodec60, also
tried libavcode-extra60, restarting firefox inbetween. Does not cure
the problem, remains broken.
- next experiment: did a strace on firefox, checking for libav... and
yes, it loads the latest versions of that libs. And remains broken.
- next experiment: double-checking the ArchLinux guide,
https://wiki.archlinux.org/title/Firefox section 4.2.3. Tried setting
and unsetting (to defaults) of those variables, and restarting. Did
not change a thing, remains broken. Also tried removing the profile
and starting with fresh settings, and even that remains broken (unlike
with upstream build or ESR version in the same situation).
- more digging: tried to observe error output. It prints something to
STDERR but that isn't helpful. vainfo... lines are the same as from
players like vlc, the other errors: no idea, maybe this is the
culprit?
- more digging: tried to generate debug output, like:
MOZ_LOG_FILE=/tmp/upstream_log MOZ_LOG="FFmpegVideo:5" ./firefox
That works just fine, those files (with ...child-number... extension)
are created and in the one for the playback window, I can find lots
of sensible codec log printing.
BUT: when I do the same with our version, that also creates log files
but they have zero size, nothing is even printed into them.
So, is this maybe some internal failure in our build, which aborts
the video engine loading early on without telling the user?
* What outcome did you expect instead?
A non-broken Debian package, at least SOME useful MOZ_LOG information in
case when someone tries to debug issues.
strace:
112061 openat(AT_FDCWD, "/usr/lib/firefox/libavcodec.so.60", O_RDONLY|O_CLOEXEC
112061 sendmsg(22, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16},
{iov_base="/usr/lib/firefox/libavcodec.so.6"..., iov_len=34}, {iov_base=NULL,
iov_len=0}], msg_iovlen=3, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_RIGHTS, cmsg_data=[21]}], msg_controllen=24, msg_flags=0},
MSG_NOSIGNAL
112064 <... recvmsg resumed>{msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16},
{iov_base="/usr/lib/firefox/libavcodec.so.6"..., iov_len=8194}], msg_iovlen=2,
msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS,
cmsg_data=[112]}], msg_controllen=24, msg_flags=MSG_CMSG_CLOEXEC},
MSG_CMSG_CLOEXEC) = 50
112064 openat(AT_FDCWD, "/usr/lib/firefox/libavcodec.so.60",
O_RDONLY|O_NOCTTY|O_CLOEXEC
112061 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libavcodec.so.60",
O_RDONLY|O_CLOEXEC
112061 sendmsg(22, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16},
{iov_base="/lib/x86_64-linux-gnu/libavcodec"..., iov_len=39}, {iov_base=NULL,
iov_len=0}], msg_iovlen=3, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_RIGHTS, cmsg_data=[21]}], msg_controllen=24, msg_flags=0},
MSG_NOSIGNAL
112064 <... recvmsg resumed>{msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16},
{iov_base="/lib/x86_64-linux-gnu/libavcodec"..., iov_len=8194}], msg_iovlen=2,
msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS,
cmsg_data=[112]}], msg_controllen=24, msg_flags=MSG_CMSG_CLOEXEC},
MSG_CMSG_CLOEXEC) = 55
112064 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libavcodec.so.60",
O_RDONLY|O_NOCTTY|O_CLOEXEC
112061 openat(AT_FDCWD, "/usr/lib/firefox/libavutil.so.58", O_RDONLY|O_CLOEXEC
112061 sendmsg(22, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16},
{iov_base="/usr/lib/firefox/libavutil.so.58"..., iov_len=33}, {iov_base=NULL,
iov_len=0}], msg_iovlen=3, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_RIGHTS, cmsg_data=[21]}], msg_controllen=24, msg_flags=0},
MSG_NOSIGNAL
112064 <... recvmsg resumed>{msg_name=NULL,
Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed
reopen 1067486 reassign 1067486 apt severity 1067486 normal thanks Am Fri, Mar 22, 2024 at 11:46:02PM +0100 schrieb Julian Andres Klode: > > Please upload a new version so grub-efi-amd64-signed can be installable. > > Thanks! > > I'm getting a bit tired of this. This is normal, the packages are > automatically generated but need to be approved by ftpteam. This might be a normal condition but a) this is not transparent to user, and b) it really does break apt's operation, at least partly. For a) maybe we should make this somehow auto-checked remotely and shown in reportbug? Or would you have a better idea? And for b) all "dist-upgrade" or "full-upgrade" failed suddenly. Yes, failing, user getting completely locked out. And "upgrade" operation installed just a fraction of the potential candidates (there were more reasons for that but the lack of dist-upgrade feature is still PITA). And the reason has not been obvious, and even debugging with -oDebug::pkgProblemResolver=true is NO FUN on bigger upgrades. And the eventual solution was close examination, and some guessing/observing that apt is confused and jumps between amd64 and i386, and then some FORCE magic, i.e. dpkg --remove --force-depends grub-common:i386 (don't ask me how this package got installed before, that system installation has been migrated a lot). Another candidate was an old iproute:i386 package which I also had to remove. Best regards, Eduard.
Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed
On Fri, 22 Mar 2024 23:46:02 +0100 Julian Andres Klode wrote: > Version: 1+2.12+1+b1 > > (this should be the right version when it gets accepted) > > On Fri, Mar 22, 2024 at 06:23:06PM +0800, Tianyu Chen wrote: > > Package: grub-efi-amd64-signed > > Version: 1+2.12+1 > > Severity: serious > > X-Debbugs-Cc: sweetyf...@deepin.org > > > > Hi, > > > > grub-efi-amd64-signed seems uninstallable now in sid. This might caused > > by a binNMU in src:grub2. > > > > The following packages have unmet dependencies: > > grub-efi-amd64-signed : Depends: grub-common (= 2.12-1) but it is not > > going to be installed > > > > $ apt policy grub-common > > grub-common: > > Installed: (none) > > Candidate: 2.12-1+b1 > > Version table: > > 2.12-1+b1 500 > > 500 http://mirrors.cernet.edu.cn/debian sid/main amd64 Packages > > > > Please upload a new version so grub-efi-amd64-signed can be installable. > > Thanks! > > I'm getting a bit tired of this. This is normal, the packages are > automatically generated but need to be approved by ftpteam. > > And people are probably understandably hesitant to accept them because future > binNMUs are expected. > > So Please do not file bugs for them, it is out of our hands. > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en > >
Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed
On Fri, 22 Mar 2024 23:46:02 +0100 Julian Andres Klode wrote: > Version: 1+2.12+1+b1 > > (this should be the right version when it gets accepted) > > On Fri, Mar 22, 2024 at 06:23:06PM +0800, Tianyu Chen wrote: > > Package: grub-efi-amd64-signed > > Version: 1+2.12+1 > > Severity: serious > > X-Debbugs-Cc: sweetyf...@deepin.org > > > > Hi, > > > > grub-efi-amd64-signed seems uninstallable now in sid. This might caused > > by a binNMU in src:grub2. > > > > The following packages have unmet dependencies: > > grub-efi-amd64-signed : Depends: grub-common (= 2.12-1) but it is not > > going to be installed > > > > $ apt policy grub-common > > grub-common: > > Installed: (none) > > Candidate: 2.12-1+b1 > > Version table: > > 2.12-1+b1 500 > > 500 http://mirrors.cernet.edu.cn/debian sid/main amd64 Packages > > > > Please upload a new version so grub-efi-amd64-signed can be installable. > > Thanks! > > I'm getting a bit tired of this. This is normal, the packages are > automatically generated but need to be approved by ftpteam. > > And people are probably understandably hesitant to accept them because future > binNMUs are expected. > > So Please do not file bugs for them, it is out of our hands. > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en > >
Bug#1057447: broadcom-sta-dkms: module build fails for Linux 6.6: wl_linux.c:486:12: error: 'struct net_device' has no member named 'wireless_handlers'
Hallo, * Andreas Beckmann [Fri, Feb 23 2024, 06:27:26PM]: > Followup-For: Bug #1057447 > Control: found -1 6.30.223.271-24~exp1 > Control: tag -1 + patch > > This issue is caused by > a) version parsing that expects three numeric components (6.6.1-foo) and >fails if there are only two (6.7-rc1) > b) broken version comparison logic > which turn on APICHOICE=FORCE_WEXT on kernels without > CONFIG_WIRELESS_EXT > > Attached patch fixes that. Thanks, and sorry, I overlooked the last message. I guess we should take it as is. Any opinion from Roger or Cyril? BR, Eduard. -- * weasel hatte letztens eine nette idee fuer ein namensschema hab's aber leider wieder vergessen :(
Bug#1057447: broadcom-sta-dkms: module build fails for Linux 6.6: wl_linux.c:486:12: error: 'struct net_device' has no member named 'wireless_handlers'
tags 1057447 +moreinfo thanks Hi, which exact kernel version is that? Which exact compiler version is that? At the first glance, that looks like some DKMS bug to me (see the strange shell warning). I just tested the module-assistant based build with a locally built 6.6.18 on Stable, works like a charm. "/usr/share/modass/packages/default.sh" build KVERS=6.6.18 KSRC=/lib/modules/6.6.18/build KDREV=6.6.18-5 kdist_image Done with /usr/src/broadcom-sta-modules-6.6.18_6.30.223.271-23+6.6.18-5_all.deb . dpkg -Ei /usr/src/broadcom-sta-modules-6.6.18_6.30.223.271-23+6.6.18-5_all.deb (Reading database ... 464471 files and directories currently installed.) Preparing to unpack .../broadcom-sta-modules-6.6.18_6.30.223.271-23+6.6.18-5_all.deb ... Unpacking broadcom-sta-modules-6.6.18 (6.30.223.271-23+6.6.18-5) ... Setting up broadcom-sta-modules-6.6.18 (6.30.223.271-23+6.6.18-5) ... apt-mark auto broadcom-sta-modules-6.6.18 broadcom-sta-modules-6.6.18 set to automatically installed. Please elaborate! Eduard. * Andreas Beckmann [Tue, Dec 05 2023, 10:33:27AM]: > Package: broadcom-sta-dkms > Version: 6.30.223.271-23 > Severity: important > Tags: sid trixie > > Hi, > > broadcom-sta-dkms fails to build a module for Linux 6.6 that was just uploaded > to experimental: > > DKMS make.log for broadcom-sta-6.30.223.271 for kernel 6.6-cloud-amd64 > (x86_64) > Tue Dec 5 08:33:20 UTC 2023 > /bin/sh: 1: [: Illegal number: 6.6-cloud-amd64 > /bin/sh: 1: [: Illegal number: 6.6-cloud-amd64 > Wireless Extension is the only possible API for this kernel version > Using Wireless Extension API > KBUILD_NOPEDANTIC=1 make -C /lib/modules/6.6-cloud-amd64/build M=`pwd` > make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make > rule. > make[1]: Entering directory '/usr/src/linux-headers-6.6-cloud-amd64' > /bin/sh: 1: [: Illegal number: 6.6-cloud-amd64 > /bin/sh: 1: [: Illegal number: 6.6-cloud-amd64 > Wireless Extension is the only possible API for this kernel version > Using Wireless Extension API > Kernel architecture is X86_64 > CC [M] /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.o > CC [M] /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.o > In file included from > /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:81: > /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_iw.h:73: warning: > "isprint" redefined >73 | #define isprint(c) bcm_isprint(c) > | > In file included from > /usr/src/linux-headers-6.6-common/include/linux/string_helpers.h:6, > from > /usr/src/linux-headers-6.6-common/include/linux/seq_file.h:7, > from > /usr/src/linux-headers-6.6-common/include/linux/seq_file_net.h:5, > from > /usr/src/linux-headers-6.6-common/include/net/net_namespace.h:195, > from > /usr/src/linux-headers-6.6-common/include/linux/netdevice.h:38, > from > /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/linuxver.h:69, > from > /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:27: > /usr/src/linux-headers-6.6-common/include/linux/ctype.h:30: note: this is the > location of the previous definition >30 | #define isprint(c) ((__ismask(c)&(_P|_U|_L|_D|_SP)) != 0) > | > /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c: In > function 'wl_if_setup': > /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:486:12: > error: 'struct net_device' has no member named 'wireless_handlers' > 486 | dev->wireless_handlers = (struct iw_handler_def *) > _iw_handler_def; > |^~ > make[3]: *** [/usr/src/linux-headers-6.6-common/scripts/Makefile.build:248: > /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.o] Error 1 > make[2]: *** [/usr/src/linux-headers-6.6-common/Makefile:1938: > /var/lib/dkms/broadcom-sta/6.30.223.271/build] Error 2 > make[1]: *** [/usr/src/linux-headers-6.6-common/Makefile:246: __sub-make] > Error 2 > make[1]: Leaving directory '/usr/src/linux-headers-6.6-cloud-amd64' > make: *** [Makefile:181: all] Error 2 > > > Andreas -- error compiling committee.c: too many arguments to function
Bug#926807: Missed a couple dependencies
On Tue, 16 Apr 2019 10:44:28 -0400 Jacob Adams wrote: > libsignal-metadata-java requires > > https://github.com/signalapp/libsignal-protocol-java > > And that requires > > https://github.com/signalapp/curve25519-java Any progress on this? Do you need help? Do you need a sponsor/uploader? Best regards, Eduard. -- error compiling committee.c: too many arguments to function
Bug#1065301: Please stop hijacking mailto: by default
Package: emacs-common Version: 1:29.2+1-2 Severity: minor Hi, I have recently experienced a little discomfort, when my regular click on some mailto: link in a browser started opening Emacs (which I have not configured for this purpose and never wanted to use it for Mail). Instead of my regular mutt-in-terminal. So I looked around and found: /usr/share/applications/emacs-mail.desktop:Exec=emacs -f message-mailto %u /usr/share/applications/emacsclient-mail.desktop:# u=$(echo "$1" | sed 's/[\"]/\\&/g'); exec emacsclient --alternate-editor= --reuse-frame --eval "(message-mailto \"$u\")" /usr/share/applications/emacsclient-mail.desktop:Exec=sh -c "u=\\$(echo \\"\\$1\\" | sed 's/[\\"]/&/g'); exec /usr/bin/emacsclient --alternate-editor= --reuse-frame --eval \\"(message-mailto \\"\\$u\\")\\"" sh %u /usr/share/applications/emacsclient-mail.desktop:Exec=sh -c "u=\\$(echo \\"\\$1\\" | sed 's/[\\"]/&/g'); exec /usr/bin/emacsclient --alternate-editor= --create-frame --eval \\"(message-mailto \\"\\$u\\")\\"" sh %u /usr/share/applications/emacsclient-mail.desktop:Exec=emacs -f message-mailto %u In my opinion, this is quite crude. Why are you pushing this "emacslient" as default application as part of a BASE package? Please stop doing that. Or move it to some optional package like "emacslient-integration" which installs those application configs. And I, for one, will uninstall emacs completely now. I kept it as backup, but this brings me over the edge, sorry. Best regards, Eduard. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.0-rc6+ (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs-common depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b1 ii emacs-el 1:29.2+1-2 ii emacsen-common 3.0.5 ii init-system-helpers 1.66 ii install-info 7.1-3 emacs-common recommends no packages. Versions of packages emacs-common suggests: pn emacs-common-non-dfsg ii ncurses-term 6.4+20240113-1 -- no debconf information -- <_crash> ... irgendwie ist IRC toll ... man muss nur da fragen und dann findet man bei google 5 minuten später selbst die antwort ... auch wenn man vorher schon 'ne halbe Stunde gesucht hat
Bug#1059041: Xorg segfault when unlocking from Xscreensaver while video playback
Package: xserver-xorg-video-amdgpu Version: 23.0.0-1 Severity: important Prerequisites: - icewm - xscreensaver - vlc Repro: a) let a fullscreen video run in VLC b) wait until xscreensaver blackens the screen c) push any key in the very same second Result: Whole Xorg going down, see below. Following the trace dump smells like the error would originate in the video driver. $ coredumpctl dump > /tmp/xorg-video-playback-crash.log PID: 1011552 (Xorg) UID: 0 (root) GID: 0 (root) Signal: 6 (ABRT) Timestamp: Tue 2023-12-19 20:09:34 CET (5min ago) Command Line: /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch Executable: /usr/lib/xorg/Xorg Control Group: /system.slice/lightdm.service Unit: lightdm.service Slice: system.slice Boot ID: 67cdd05639504fd48e987b5f02106871 Machine ID: ae90e3d096ca29949df8c700456b394f Hostname: zombie Storage: /var/lib/systemd/coredump/core.Xorg.0.67cdd05639504fd48e987b5f02106871.1011552.170301297400.zst (present) Size on Disk: 7.1M Message: Process 1011552 (Xorg) of user 0 dumped core. Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64 Module libsystemd.so.0 from deb systemd-255-1.amd64 Module libudev.so.1 from deb systemd-255-1.amd64 Stack trace of thread 1011552: #0 0x7fb1494a80fc __pthread_kill_implementation (libc.so.6 + 0x8a0fc) #1 0x7fb14945a472 __GI_raise (libc.so.6 + 0x3c472) #2 0x7fb149b2 __GI_abort (libc.so.6 + 0x264b2) #3 0x5577d8f7ae30 OsAbort (Xorg + 0x1d8e30) #4 0x5577d8f80649 n/a (Xorg + 0x1de649) #5 0x5577d8f81619 FatalError (Xorg + 0x1df619) #6 0x5577d8f78019 n/a (Xorg + 0x1d6019) #7 0x7fb14945a510 __restore_rt (libc.so.6 + 0x3c510) #8 0x7fb149186702 n/a (amdgpu_drv.so + 0x16702) #9 0x7fb149186c96 n/a (amdgpu_drv.so + 0x16c96) #10 0x5577d8e75a6b xf86DPMSSet (Xorg + 0xd3a6b) #11 0x5577d8e41485 n/a (Xorg + 0x9f485) #12 0x5577d8eb5c56 n/a (Xorg + 0x113c56) #13 0x5577d8f57335 mieqProcessInputEvents (Xorg + 0x1b5335) #14 0x5577d8e4177d ProcessInputEvents (Xorg + 0x9f77d) #15 0x5577d8e01f93 n/a (Xorg + 0x5ff93) #16 0x5577d8e062cc n/a (Xorg + 0x642cc) #17 0x7fb1494456ca __libc_start_call_main (libc.so.6 + 0x276ca) #18 0x7fb149445785 __libc_start_main_impl (libc.so.6 + 0x27785) #19 0x5577d8def281 _start (Xorg + 0x4d281) Stack trace of thread 1011555: #0 0x7fb1494a3156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7fb1494a5818 __pthread_cond_wait_common (libc.so.6 + 0x87818) #2 0x7fb146d198ed n/a (radeonsi_dri.so + 0x1198ed) #3 0x7fb146cf96cb n/a (radeonsi_dri.so + 0xf96cb) #4 0x7fb146d1981b n/a (radeonsi_dri.so + 0x11981b) #5 0x7fb1494a63ec start_thread (libc.so.6 + 0x883ec) #6 0x7fb149526a5c __clone3 (libc.so.6 + 0x108a5c) Stack trace of thread 1011556: #0 0x7fb1494a3156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7fb1494a5818 __pthread_cond_wait_common (libc.so.6 + 0x87818) #2 0x7fb146d198ed n/a (radeonsi_dri.so + 0x1198ed) #3 0x7fb146cf96cb n/a (radeonsi_dri.so + 0xf96cb) #4 0x7fb146d1981b n/a (radeonsi_dri.so + 0x11981b) #5 0x7fb1494a63ec start_thread (libc.so.6 + 0x883ec) #6 0x7fb149526a5c __clone3 (libc.so.6 + 0x108a5c) Stack trace of thread 1011557: #0 0x7fb1494a3156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7fb1494a5818 __pthread_cond_wait_common (libc.so.6 + 0x87818) #2 0x7fb146d198ed n/a (radeonsi_dri.so + 0x1198ed) #3 0x7fb146cf96cb n/a (radeonsi_dri.so + 0xf96cb) #4 0x7fb146d1981b n/a (radeonsi_dri.so + 0x11981b) #5 0x7fb1494a63ec start_thread (libc.so.6 + 0x883ec) #6 0x7fb149526a5c __clone3 (libc.so.6 + 0x108a5c) Stack trace of thread 1011562: #0 0x7fb1494a3156 __futex_abstimed_wait_common64 (libc.so.6 + 0x85156) #1 0x7fb1494a5818 __pthread_cond_wait_common (libc.so.6 + 0x87818) #2 0x7fb146d198ed n/a (radeonsi_dri.so + 0x1198ed) #3 0x7fb146cf96cb n/a (radeonsi_dri.so + 0xf96cb)
Bug#1042859: [Pkg-rust-maintainers] Bug#1042859: cargo: Please upgrade to at least 0.67.0
Hallo, * Fabian Grünbichler [Fri, Nov 03 2023, 01:57:08PM]: > > Eduard Bloch hat am 03.11.2023 13:46 CET geschrieben: > > > > > > Hallo, > > * Fabian Grünbichler [Fri, Nov 03 2023, 12:32:50PM]: > > > > > > the version of Cargo seriously needs an update. Because the word is > > > > moving and the old version performs increasingly bad. > > > > > > the upgrade (to 0.70.1, since later versions require a lot of NEW > > > processing first) is being prepared, but it takes a long time because it > > > is very involved. > > > > > > https://salsa.debian.org/rust-team/debcargo-conf/-/issues/48 > > > https://salsa.debian.org/rust-team/cargo/-/merge_requests/21 > > > > > > also related, and hopefully improving this in the future: > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054658 > > > https://salsa.debian.org/rust-team/rust/-/merge_requests/27 > > > > Okay, I get the idea. That said, I find it quite strange that you want > > to include a Python dependency in order to run a central Rust tool. > > > > Would you like me to rewrite the proposed cargo wrapper script into a > > native Rust app? That's a serious offer, I have IMHO sufficient Python > > and Rust experience, recently working on something partly similar > > (https://gitlab.com/setecastronomy/wec ). > > > I am not sure what you are referring to, but the fact that some > helper/wrapper scripts are written in python is in no way related to what is > making updates cumbersome at the moment. I was refering to the last link from the post above: https://salsa.debian.org/rust-team/rust/-/merge_requests/27/diffs#98066737513db2808acb090ffe631b89bd788499 > and we most definitely don't want to rewrite the cargo wrapper in rust, that > would serve no purpose at all. Depends on the whole picture. From that statement I understand that reducing dependencies on further interpreters (like Python) is not a goal here. > > (Not sure about bootstrapping, though. Is rustc available while our > > source package is being built?) > > of course rustc is required to build both rustc and cargo, since both are > written in rust. note that rustc itself also has a build-dependency on python > anyway, since it's (internal) bootstrapping/build tool is written in python > (and rust). Okay. But I did not have only build-deps of the Debian source package in mind, more the dependencies of the binary package, i.e. what the regular user (application developer) gets. Why should cargo have a dependency on Python? Looks quite strange to me. MfG, Eduard. -- Das Wichtigste bleibt jedoch das Gleichzeitige, weil es sich in uns am reinsten abspiegelt, wir uns in ihm. -- Goethe, Maximen und Reflexionen, Nr. 8
Bug#1042859: [Pkg-rust-maintainers] Bug#1042859: cargo: Please upgrade to at least 0.67.0
Hallo, * Fabian Grünbichler [Fri, Nov 03 2023, 12:32:50PM]: > > the version of Cargo seriously needs an update. Because the word is > > moving and the old version performs increasingly bad. > > the upgrade (to 0.70.1, since later versions require a lot of NEW processing > first) is being prepared, but it takes a long time because it is very > involved. > > https://salsa.debian.org/rust-team/debcargo-conf/-/issues/48 > https://salsa.debian.org/rust-team/cargo/-/merge_requests/21 > > also related, and hopefully improving this in the future: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054658 > https://salsa.debian.org/rust-team/rust/-/merge_requests/27 Okay, I get the idea. That said, I find it quite strange that you want to include a Python dependency in order to run a central Rust tool. Would you like me to rewrite the proposed cargo wrapper script into a native Rust app? That's a serious offer, I have IMHO sufficient Python and Rust experience, recently working on something partly similar (https://gitlab.com/setecastronomy/wec ). (Not sure about bootstrapping, though. Is rustc available while our source package is being built?) Best Regards, Eduard. -- wie führt man noch mal ein shellscript aus? ausdrucken, einstecken, zum italiener gehen, auf nen stuhl legen ... und sag ihm ein paar nette Sachen, das mögen sie
Bug#1055266: pipewire: Changing monitor settings makes HDMI output silent forever
Package: pipewire Version: 0.3.84-1 Severity: important Dear Maintainer, * What led up to the situation? My speakers are connected via 3.5mm jack to monitor, which is connected via docking station to laptop. When connecting the laptop for the first time, the HDMI output works. BUT: I need to change the monitor settings with xrandr, i.e. fix the RGB range or refresh rate (it's a 144Hz monitor after all). And when I do change the refresh rate, the picture of the monitor is lost for a couple of seconds. Afterwards, almost everything works and I have my smooth 144Hz. BUT: audio output is BROKEN. * What was the outcome of this action? There is NO SOUND comming out of the speaker anymore!! I still see the devices there in pavucontrol, it seems to be in the same state as before and "... HDMI output" is selected as before. I can still control it, but it remains SILENT. * What outcome did you expect instead? TO NOT BREAK! Restore the settings and continue with sound output after the display connection was reestablished. Best regards, Eduard. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=de_DE.UTF-8, LC_CTYPE=ru_RU.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 pipewire depends on: ii adduser 3.137 ii init-system-helpers 1.65.2 ii libpipewire-0.3-modules 0.3.84-1 ii pipewire-bin 0.3.84-1 pipewire recommends no packages. pipewire suggests no packages. -- no debconf information
Bug#1042859: cargo: Please upgrade to at least 0.67.0
severity 1042859 important
thanks
Hallo,
* Mike Hommey [Wed, Aug 02 2023, 06:37:08AM]:
> 0.66 is the version of cargo that goes alongside rustc 1.65.
> 0.67 is the version of cargo that goes alongside rustc 1.66.
> Unstable and testing have rustc 1.66, so cargo should be updated to at
> least version 0.67.
Dear Rust Maintainers,
the version of Cargo seriously needs an update. Because the word is
moving and the old version performs increasingly bad.
I.e. we got Rust 1.70 in the meantime, and there were more fixes in Cargo.
Also sparse mode is now enabled by default, see
https://releases.rs/docs/1.70.0/#cargo while in the version 0.66 the
sparse mode seems not to work if configured manually. And the index
update is also NOT smart in the old version, meaning that it rebuilds
quite often, and then it takes OVER SIX MINUTES on my laptop (older Core i5).
I tried manual update of cargo ("cargo install cargo") and the new
version shows "lightspeed" performance compared to the old one. Also the
required space for metadata in ~/.cargo/registry/index went down
from >> 700MiB to a matter of a few hundred KILOBYTES.
Best regards,
Eduard.
Bug#1052547: unable to boot, no luks passwort prompt shown
Package: cryptsetup-initramfs Version: 2:2.6.1-5 Severity: grave Hello Maintainer, we have a problem here. After latest upgrades, I am no longer able to boot into a system with LUKS-encrypted rootfs. This worked just fine a few weeks ago. I jumped in circles in the search for the cause, and only after downgrading cryptsetup-initramfs to 2:2.6.1-4 it suddenly started working again. The symptom: initramfs starts more or less okay, after a second KVM switches the screen mode. And then I see a blinking cursor. And that's all. Normally (like before, or after after downgrading the package) I get a LUKS passwort prompt instead, where I enter the rootfs password. Best regards, Eduard. -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-6.5.5 root=UUID=6e83a5a5-0c68-41e9-8bcb-ea0b50c06197 ro acpi=force -- /etc/crypttab # #xroot /dev/sdb2 none luks,discard #xroot UUID=4047a384-74d1-465d-9e1b-536f40ed73d2 none luks,discard yroot UUID=0a03cfce-d1a8-4a93-a403-d411f8ead12e none luks,discard -- /etc/fstab # /etc/fstab: static file system information. # # proc /proc proc defaults 0 0 /dev/mapper/yroot / ext4 defaults,errors=remount-ro,noatime,commit=1200 1 UUID="e69c6bbe-f493-4dc5-aed3-419654c4bf41" /boot ext4 defaults,errors=remount-ro 01 UUID="B63D-00A4" /boot/efi vfat defaults,errors=remount-ro 01 /dev/cdrom /media/cdrom0 udf,iso9660 ro,user,noauto0 0 UUID="0a03cfce-d1a8-4a93-a403-d411f8ead12e" /mnt/bigdata auto noauto,user UUID="2610550D1054E579"/mnt/d ntfs-3g utf8,user,auto,umask=000,nofail 0 0 UUID="78496414545E7C56" /mnt/cfs2 ntfs-3g defaults,noauto,nofail 0 1 UUID=CE2E78A02E78836F /mnt/c ntfs-3g utf8,user,auto,umask=000,nofail 0 0 none /var/cache/pbuilder/bd tmpfs defaults 0 0 -- lsmod Module Size Used by snd_seq_dummy 12288 0 snd_hrtimer12288 1 snd_seq 110592 7 snd_seq_dummy cpufreq_userspace 16384 0 cpufreq_conservative16384 0 cpufreq_powersave 16384 0 nvme_fabrics 36864 0 overlay 188416 0 bnep 28672 2 uinput 20480 1 binfmt_misc28672 1 nls_ascii 12288 1 nls_cp437 16384 1 vfat 20480 1 fat94208 1 vfat pktcdvd53248 0 uvcvideo 143360 0 videobuf2_vmalloc 20480 1 uvcvideo uvc12288 1 uvcvideo videobuf2_memops 16384 1 videobuf2_vmalloc videobuf2_v4l2 36864 1 uvcvideo snd_usb_audio 401408 1 videodev 356352 2 videobuf2_v4l2,uvcvideo snd_usbmidi_lib49152 1 snd_usb_audio snd_rawmidi53248 1 snd_usbmidi_lib videobuf2_common 77824 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops joydev 24576 0 snd_seq_device 16384 2 snd_seq,snd_rawmidi mc 94208 5 videodev,snd_usb_audio,videobuf2_v4l2,uvcvideo,videobuf2_common btusb 81920 0 btmtk 12288 1 btusb btrtl 28672 1 btusb btbcm 24576 1 btusb btintel57344 1 btusb bluetooth1110016 15 btrtl,btmtk,btintel,btbcm,bnep,btusb intel_rapl_msr 20480 0 intel_rapl_common 36864 1 intel_rapl_msr kvm_amd 180224 0 sha3_generic 16384 1 jitterentropy_rng 20480 1 drbg 28672 1 snd_hda_codec_realtek 192512 1 ccp 135168 1 kvm_amd snd_hda_codec_generic 110592 1 snd_hda_codec_realtek ansi_cprng 12288 0 ledtrig_audio 12288 1 snd_hda_codec_generic ecdh_generic 16384 1 bluetooth snd_hda_codec_hdmi 90112 2 rfkill 40960 4 bluetooth snd_hda_intel 61440 3 ecc45056 1 ecdh_generic snd_intel_dspcfg 24576 1 snd_hda_intel kvm 1335296 1 kvm_amd snd_hda_codec 221184 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek irqbypass 12288 1 kvm snd_hda_core 143360 5
Bug#1052545: os-prober in initramfs gets repeatedly disabled
Package: os-prober Version: 1.81 Severity: normal Something happened in the last months. Whenever I upgrade, it seems like the os-prober part is disabled. This is just PITA. I can use the usual: dpkg-reconfigure -plow grub-efi-amd64 ... to turn it back on, and after an upgrade it's lost again. WHY? Now I started seeing messages after installing a new kernel package: Warning: os-prober will not be executed to detect other bootable partitions. Systems on them will not be added to the GRUB boot configuration. Check GRUB_DISABLE_OS_PROBER documentation entry. Adding boot menu entry for UEFI Firmware Settings ... Sorry, dear maintainer, WHAT DOES THAT MEAN? Which documentation? From which package? Why does this reset my settings? Best regards, Eduard. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages os-prober depends on: ii grub-common 2.12~rc1-10 ii libc62.37-10 ii mount2.39.2-1 os-prober recommends no packages. os-prober suggests no packages. -- no debconf information -- * falky kann die Frauen einfach nicht verstehen Die Frau, das unbekannte Wesen. To boldy come where no man has come before?
Bug#632243: [encfs] /bin/umount: unrecognized option '--fake'
On Thu, 30 Jun 2011 21:20:53 +0200 Markus Grunwald wrote: > Package: encfs > Version: 1.7.4-2.2 > Severity: minor > > --- Please enter the report below this line. --- > This happens when I umount an encfs directory: > > markus@haktar % fusermount -u private.dec > /bin/umount: unrecognized option '--fake' > Usage: umount -h | -V >umount -a [-d] [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts] >umount [-d] [-f] [-r] [-n] [-v] special | node... > 1 markus@haktar % ls ~/private.dec > markus@haktar % > > Since ~/private.dec is unmounted, it's no big problem, but disturbing. Hi, this has been a while. Is this still a problem with the current version of mount? Gruß, Eduard.
Bug#1026848: apt-cacher-ng: Two fixes for erroneous tagging
Hallo,
* Antonio Russo [Thu, Dec 22 2022, 07:15:12AM]:
> Package: apt-cacher-ng
> X-Debbugs-Cc: aeru...@aerusso.net
> Severity: important
> Tags: patch upstream
>
> Dear maintainer,
>
> In bug 1026395, I identified behavior where apt-cacher-ng was tagging many
> valid, referenced files for deletion. One cause is mentioned there. However,
> I failed to notice another source of erroneous tagging: SHA256 sums in
> the Packages/Sources/etc. files are not being detected.
>
> For examples, debrep/dists/bullseye-backports/main/binary-amd64/Packages,
> contains "^SHA256: " lines that are not being used.
>
> The first of the two patches fixes that behavior for Packages.
>
> During this process, a third source showed up: the lists of files in Sources
> was getting clobbered because of the behavior of
> cacheman.cc:ParseGenericRfc822File
> ("we don't merge").
>
> The second patch implements streaming handling of Sources a la Packages. That
> patch parses possibly untrusted data, so please give it a close read (also I
> haven't done a lot of C++ coding recently, so I apologize in advance).
Thanks. Regarding the second patch, I am not sure. Looks like my C++
also has become rusty in the last months. It would be good to have an
explicit description of the problem cases, since I don't know exactly
what you mean with "streaming". I.e. it seems like you want the generic
parser implementation to be changed to a specialized local one but how
am I supposed to write a unit test for this?
To be checked in the next days, stay tuned.
Best regards,
Eduard.
Bug#1025389: libgl1-mesa-dri: AIGLX error: dlopen of /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
severity 1025389 normal thanks Hallo, * Fabio Pedretti [Mon, Jan 02 2023, 10:10:24AM]: > Hi, i965 driver was removed, and replaced by iris, crocus and (gallium > version of) i915. > > Did you have any reference to i965 in your configuration? > > cd /etc/ && grep -ri i965 > > If so try to remove them, the system should be able to pick up the > proper driver. Okay, the devil is in the details. Multiple issues were involved. First, I had a custom config snippet in xorg.conf.d which has activated the intel drivers. I had to add this in earlier times in order to get rid of tearing. Another part in the puzzle was an environment setting which I have added some time ago to work around crashes (first VLC crashes, then all applications crashes in the major driver loader fu*up a few weeks ago). So it seems like it was the MESA_LOADER_DRIVER_OVERRIDE=i965 which actually triggered the Xorg.0.log messages which I have mistakenly attributed to the incorrect X configuration itself. So after changing all that, it's now apparently loading the proper driver (iris in the log), with no errors, and most GL using applications also work properly. VLC is still crashing on certain video formats but that is probably due to some internal bug of VLC's vaapi usage (there is another bugreport for that). But mplayer works mostly fine, except for some gamma problems. So in the end, it would be good if there was at least some notice about the driver configuration change, something in NEWS.Debian, for example. Maybe with a longer explanation in README.Debian. I can imagine that more users with customized configurations are affected like I was. Best regards, Eduard.
Bug#1025389: libgl1-mesa-dri: AIGLX error: dlopen of /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
Am Sun, Jan 01, 2023 at 11:02:08PM +0100 schrieb Eduard Bloch: > reopen 1025389 > severity 1025389 serious > thanks > > Am Sun, Jan 01, 2023 at 02:29:01PM +0100 schrieb Fabio Pedretti: > > Version: 22.3.0-3 > > > > 22.3.0-3 reenabled two intel drivers missing in previou release. > > Why the heck are you closing this when the very specific issue in the > subject is not resolved? And the fun goes on. After some websearch, I found: https://www.phoronix.com/review/ivy-bridge-crocus So was THAT supposed to replace i965 support in mesa-22? Well, then it simply DOES NOT WORK. Yes, I found that crocus lib. But: MESA_LOADER_DRIVER_OVERRIDE=crocus strace -f -o wtf.log vlc ... $ grep crocus wtf.log 21999 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/tls/crocus_dri.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden) 21999 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/crocus_dri.so", O_RDONLY|O_CLOEXEC) = 23 21999 write(2, "failed to load driver: crocus\n", 30) = 30 22019 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/tls/crocus_dri.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden) 22019 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/crocus_dri.so", O_RDONLY|O_CLOEXEC) = 28 22019 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/tls/crocus_dri.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden) 22011 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/tls/crocus_dri.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden) 22011 write(2, "failed to load driver: crocus\n", 30) = 30 So, and now? Is that internal implementation change something which was supposed to be communicated to users? If yes, where are the docs? If not, why is this not at least sufficiently transparent to developers, and made easy to debug? In any case, it seems to be broken as of now.
Bug#1025389: libgl1-mesa-dri: AIGLX error: dlopen of /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
reopen 1025389
severity 1025389 serious
thanks
Am Sun, Jan 01, 2023 at 02:29:01PM +0100 schrieb Fabio Pedretti:
> Version: 22.3.0-3
>
> 22.3.0-3 reenabled two intel drivers missing in previou release.
Why the heck are you closing this when the very specific issue in the
subject is not resolved?
$ dpkg -L libgl1-mesa-dri | grep 965
$ dpkg -L libgl1-mesa-dri | grep 915
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so
So, apparently the i915 driver is there, fine; i965 IS NOT!
And while the other issue with the loader crash is apparently fixed, I
still cannot see a solution for i965. Any program requesting GLX support
reports:
libGL error: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: cannot
open shared object file: No such file or directory (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
and that's basically it.
NOTE: you can override my judgement WRT severity but IMHO breaking
support for ~7 year old hardware is not acceptable, should be RC.
And the hardware here is:
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
Also:
$ grep i9 /var/log/Xorg.0.log
[93.347] Kernel command line: BOOT_IMAGE=/vmlinuz-6.1.0-0-amd64
root=/dev/mapper/default-root ro init=/bin/systemd i915.enable_rc6=0
iwlwifi.power_save=Y iwlwifi.power_level=3 quiet
915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
[93.463] (II) intel(0): Using Kernel Mode Setting driver: i915, version
1.6.0 20201103
[93.493] (II) intel(0): [DRI2] DRI driver: i965
[93.500] (EE) AIGLX error: dlopen of
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so failed
(/usr/lib/x86_64-linux-gnu/dri/i965_dri.so: cannot open shared object file: No
such file or directory)
[93.500] (EE) AIGLX error: unable to load driver i965
Bug#1016505: patch: Fix `Incorrect netdev->dev_addr` errors in linux-5.17+ patch
Am Thu, Nov 10, 2022 at 12:08:31PM -0500 schrieb Diego Escalante Urrelo: > Package: broadcom-sta-dkms > Version: 6.30.223.271-22 > Followup-For: Bug #1016505 > X-Debbugs-Cc: die...@gnome.org > > Bump. > > I have pushed this and other fixes as a branch in salsa: > https://salsa.debian.org/diegoe/broadcom-sta/-/commits/2022-various-fixes Thank you. I am on it. Brief test on Linux 6.1 staging branch shows no warnings. Best regars, Eduard.
Bug#1023200: va-driver-all: buggy or unstable behavior on older i965 GPU
Package: va-driver-all
Version: 2.16.0-1
Severity: important
Dear Maintainer,
Please dispatch this ticket as you see fit. I report this against va-driver-all
since it seems to have indirectly lead to the trouble, and there is no README
in va-driver-all which would explain the rules of the game.
My system has been working fine with Sid until a couple of months ago. IIRC,
last year I checked the vainfo config and eventually enabled it even in Firefox
(Chrome was fine out of the box).
However, now the CPU consumption in Chrome is back to high in Video playback,
feels like the GPU acceleration started failing silently. Investigation on the
issue has caused trobule, see below. And setting popular env. vars like
MESA_LOADER_DRIVER_OVERRIDE=i965 did not help.
Hardware:
Lenovo X250 (older revision)
00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller
(rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI
Controller #1 (rev 03)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) I218-LM
(rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio
Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #6
(rev e3)
00:1c.1 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3
(rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller
(rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller
[AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation Wildcat Point-LP
Thermal Management Controller (rev 03)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI
Express Card Reader (rev 01)
03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 99)
Situation 1:
va-driver-all is installed (that installs intel-media-va-driver; see below for
intel-media-va-driver-nonfree effects).
Result:
on some H264 videos, VLC is not accelerated, framerate is terrible, like 2-5
fps.
On bigger ones, VLC simply crashes. Where? Here:
Module libudev.so.1 from deb systemd-252~rc3-2.amd64
Module libsystemd.so.0 from deb systemd-252~rc3-2.amd64
Stack trace of thread 3269:
#0 0x7f4eca507730 _Z21mos_bo_wait_renderingP12mos_linux_bo
(iHD_drv_video.so + 0x107730)
#1 0x7f4eca718db9
_ZN14DdiMediaDecode12CreateBufferE12VABufferTypejjPvPj (iHD_drv_video.so +
0x318db9)
#2 0x7f4eca6fe0ac
_Z21DdiMedia_CreateBufferP15VADriverContextj12VABufferTypejjPvPj
(iHD_drv_video.so + 0x2fe0ac)
#3 0x7f4f38c9e870 vaCreateBuffer (libva.so.2 + 0x6870)
#4 0x7f4f0060ab85 n/a (libvdpau_va_gl.so.1 + 0xab85)
#5 0x7f4f0060b2ac n/a (libvdpau_va_gl.so.1 + 0xb2ac)
#6 0x7f4f0060b879 n/a (libvdpau_va_gl.so.1 + 0xb879)
#7 0x7f4f1f200f78 n/a (libavcodec.so.59 + 0x800f78)
#8 0x7f4f1f2028b4 n/a (libavcodec.so.59 + 0x8028b4)
#9 0x7f4f1ed8a28c n/a (libavcodec.so.59 + 0x38a28c)
#10 0x7f4f1ed9ff3e n/a (libavcodec.so.59 + 0x39ff3e)
#11 0x7f4f1f06756b n/a (libavcodec.so.59 + 0x66756b)
#12 0x7f4f7628784a start_thread (libc.so.6 + 0x8784a)
#13 0x7f4f7630b2cc __clone3 (libc.so.6 + 0x10b2cc)
Before it brings:
VLC media player 3.0.18-rc2 Vetinari (revision 3.0.13-8-g41878ff4f2)
[55f30ff19610] main libvlc: VLC wird mit dem Standard-Interface ausgeführt.
Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
libGL error: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: Kann
die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
(search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri,
suffix _dri)
libGL error: failed to load driver: i965
[55f30fff2db0] main audio output error: too low audio sample frequency (0)
[7ff9e4c96810] main decoder error: failed to create audio output
[55f30fff2db0] vlcpulse audio output error: digital pass-through stream
connection failure: Eingabe/Ausgabe-Fehler
[55f30fff2db0] main audio output error: module not functional
[7ff9e4c96810] main decoder error: failed to create audio output
libEGL warning: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so:
Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht
gefunden (search paths
Bug#1020909: Enable lfs (large file support) in apt-cacher-ng
Hallo, * Helge Deller [Wed, Sep 28 2022, 10:12:52PM]: > On 9/28/22 21:52, Eduard Bloch wrote: > If you call readdir() a few lines below, this readdir will not be able > to store the file info in the dirent struct (if the file is located in > high area of discs), instead returns NULL with errno set (e.g. E2BIG or like > that). > Finally the readdir() will not work as expected as it doesn't find some files. > > [*] _LARGEFILE_SOURCE or _FILE_OFFSET_BITS=64 Both of them? I don't think so. _LARGEFILE_SOURCE will export some XYZo functions of the C API, but I don't use them. And _FILE_OFFSET_BITS IS set, I have no idea what you are talking about. Check the logs, like https://buildd.debian.org/status/fetch.php?pkg=apt-cacher-ng=i386=3.7.4-1%2Bb1=1652551064=0 > I found a similiar issue with glibc right recently: > https://sourceware.org/bugzilla/show_bug.cgi?id=29583 > > > So do you have your cache on NFS with thousands of files in a single > > directory? > > No, but a disc of TB size on a 32-bit platform. Exactly, no. So where is the problem you are observing actually coming from? So far I saw a weak theory, observation of some error status, and pointing at "missing LFS". And the last part is not even true as far as I could see. > > > Sometimes I see a cron job warning: > > > /etc/cron.daily/apt-cacher-ng: > > > Aborted > > > run-parts: /etc/cron.daily/apt-cacher-ng exited with return code 134 > > > > > > Change is trivial, just add "future=+lfs" to DEB_BUILD_MAINT_OPTIONS: > > > > This does not make sense. That would only inject a couple of runtime > > influencing defines. > > Well, not just runtime influencing. More importantly: Build-time. Obviously. > They enlarge the dirent struct for 64-bit wide inode numbers and > thus allow readdir() [which actually calls the readdir64 syscall then] > to function properly. You don't need to teach me the basics. I have added LFS support over a decade ago. Please do at least some basic research to find things like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588048 . > > apt-cacher-ng has been adding those defines since > > the early days of its creation. > > Really? > I don't find the CFLAGS _LARGEFILE_SOURCE or _FILE_OFFSET_BITS=64 in the > sources. Strange, my grep command has no problems doing right that. $ grep FILE_OFFSET src/* CMakeLists.txt src/config.h:// added in Makefile... #define _FILE_OFFSET_BITS 64 src/meta.h:// _FILE_OFFSET_BITS mostly irrelevant. But if it's set, watch out for user's "experiments". src/meta.h:#if _FILE_OFFSET_BITS == 32 src/meta.h:#error Unsupported: _FILE_OFFSET_BITS == 32 with large long size src/meta.h:#if 64 == _FILE_OFFSET_BITS src/meta.h:#if 32 == _FILE_OFFSET_BITS CMakeLists.txt:SET(ACNG_COMPFLAGS "-D_FILE_OFFSET_BITS=64") MfG, Eduard.
Bug#1020909: Enable lfs (large file support) in apt-cacher-ng
Hallo, * Helge Deller [Wed, Sep 28 2022, 12:46:53PM]: > Package: apt-cacher-ng > Severity: 3.7.4-1 > Tags: lfs, hppa, patch > > Please enable large file support. > apt-cacher-ng uses readdir() which can fail on 32-bit arches > running on large discs. This does not make sense. readdir() does not care about large discs. It might care about the file number in a directory. And while there are some limitations with readdir for virtual filesystems (like NFS) there should be no issue with local filesystem where kernel is maintaining the internal handle with proper means. So do you have your cache on NFS with thousands of files in a single directory? > Sometimes I see a cron job warning: > /etc/cron.daily/apt-cacher-ng: > Aborted > run-parts: /etc/cron.daily/apt-cacher-ng exited with return code 134 > > Change is trivial, just add "future=+lfs" to DEB_BUILD_MAINT_OPTIONS: This does not make sense. That would only inject a couple of runtime influencing defines. apt-cacher-ng has been adding those defines since the early days of its creation. And how would that affect readdir related syscalls? Best regards, Eduard. -- Wenn wir bedenken, daß wir alle verrückt sind, ist das Leben erklärt. -- Mark Twain (eigl. Samuel Langhorne Clemens)
Bug#992995: mail-expire: Add support to skip new or unread marked mails
Hallo, * Eduard Bloch [Tue, Sep 06 2022, 10:03:24AM]: > Dev branch: > https://salsa.debian.org/blade/mail-expire/-/commits/feat-992995-status-filter Well okay, once I started implementing the actual code, it became obvious that this way of filtering does not make much sense. I.e. separating including/excluding/date filter into different categories gets overcomplicated and at the same time it limits user's options to combine them properly. Instead, I would use something like following, i.e. attaching the additionial filtering wishes directly to the age specification. Details as following or see the latest git changes, link above. This obviously does not cover all corner cases but IMHO it's good enough for all usecases I came up with. So you could specify something like: mail-expire 1,Recent maildir-foo --filter 100,NonRecent --filter 50,Seen --filter 7,Deleted # "never" expire New/Recent mails, after 100 days the spotted ones, after 50 # days the already read mails, and the deleted ones after a week Opinions? SYNOPSIS mail-expire AGE-IN-DAYS[,FILTERFLAG,...] FILES... ... The filter parameter can be extended with additional filter specifications (see --filter in options), also multiple alternative filters can be specified using options. --filter=DAYS,FILTERFLAG,FILTERFLAG,... Specifies additional filter(s), with the minimum age in days, and optional status flags which turn on or off the consideration of the message for expiration. Multiple filters are possible. Possible filter flags are: Seen, Recent, Answered, Flagged, Draft, Deleted. The meaning can also be inverted by prepending "Not" (like: NotSeen). The meaning of Seen and Recent may vary depending on the mail storage format and the client editing message metadata. For Maildir, Recent means "still in NEW space" or marked with IMAP "R" flag, and Seen is "MUA marked the message as actually read". Best regards, Eduard.
Bug#992995: mail-expire: Add support to skip new or unread marked mails
Hallo, * Joey Hess [Mon, Sep 05 2022, 03:13:41PM]: > I agree, I would also need this in order to replace my useage of > archivemail with mail-expire. I'm probably not unusual in having certian > mailboxes full of messages that need to remain in there despite being > old or unread. Hmm, okay. What do you think about the following extension? Just drafting for now. Seems like mbox and Maildir deviate on the status flag naming, therefore I would probably add a readable set of filters. Message selection Messages can be filtered by their status flags, including or excluding them from being considered for expiration. In case of conflicting choice, the message will be kept. --flags-in, -I Consider only messages which flags are matched by the flags listed in this option (comma-separated list). Possible flags are: Seen, Recent, Answered, Flagged, Draft, Deleted. The meaning of Seen and Recent may vary depending on the mail storage format and the client editing message metadata. For Maildir, Recent typically means "still in New area" and Seen is "MUA marked the message as actually read". EXAMPLE: -I Deleted,Seen --flags-not-in, -E Exclude the matched messages from expiration. See -I option for format description. SEE ALSO https://www.rfc-editor.org/rfc/rfc3501#section-2.3.2, https://doc.dovecot.org/admin_manual/mailbox_formats/mbox/ Dev branch: https://salsa.debian.org/blade/mail-expire/-/commits/feat-992995-status-filter Best regards, Eduard. signature.asc Description: PGP signature
Bug#1010420: Acknowledgement (firefox: 100% CPU load on one core with some pipe activity)
Hallo, and it gets worse. Playing a YT video (720p) consumes about 300% CPU power and laptop running hot. Doing the same with Chromium causes about 30% load, that's an order of magnitude! NOTE: this cannot be attributed to Video HW accelleration, I have enabled that in FF long time ago, following https://askubuntu.com/questions/1291279/ubuntu-20-10-firefox-82-intel-hd-500-vaapi-hardware-acceleration and https://ubuntuhandbook.org/index.php/2021/08/enable-hardware-video-acceleration-va-api-for-firefox-in-ubuntu-20-04-18-04-higher/ . And it has been working well for months. The obvious reason would be the FF update. Basically, this version is garbage. Best regards, Eduard. -- formorer: Ein Editor, der das Tastenkürzel ctrl-alt-del als mögliche Befehlskombination für wahrscheinlich erscheinen lässt, ist einfach nur krank.
Bug#1010420: firefox: 100% CPU load on one core with some pipe activity
Package: firefox
Version: 99.0-1
Severity: important
Dear Maintainer,
* What led up to the situation?
Upgraded to latest FF version.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Restarted FF.
* What was the outcome of this action?
All the time there is load of 100% on one core. "about:performance" does not
show anything suspicious. Restarting does not help, CPU load is back
immediately. Even if the only focused tab is an empty one.
Observing with strace -f shows permanent activity around two file handles (see
below for example) and intermediate
lsof output shows that this is some pipe (fds 28 and 29) and FD 4 involved
which is some Unix socket, created very early.
4u unix 0x779602fd 0t0 63406 type=STREAM (CONNECTED)
5u a_inode 0,14 0 8155 [eventfd:34]
WHAT IS IT DOING THERE? Waiting for something unreachable?
No special plugins installed, just Noscript and Ublock Origin.
* What outcome did you expect instead?
No permanent CPU load!
9282 futex(0x7f9b481296e8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0,
NULL, FUTEX_BITSET_MATCH_ANY
9272 futex(0x7f9b3833e9d8, FUTEX_WAIT_BITSET_PRIVATE, 0, {tv_sec=2776,
tv_nsec=584387042}, FUTEX_BITSET_MATCH_ANY
9222 read(28, "\372", 1) = 1
9222 write(29, "\372", 1) = 1
9222 recvmsg(4, {msg_namelen=0}, 0)= -1 EAGAIN (Die Ressource ist zur Zeit
nicht verfügbar)
9222 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=24, events=POLLIN}, {fd=28, events=POLLIN}], 5, 0) = 1
([{fd=28, revents=POLLIN}])
9222 read(28, "\372", 1) = 1
9222 recvmsg(4, {msg_namelen=0}, 0)= -1 EAGAIN (Die Ressource ist zur Zeit
nicht verfügbar)
9222 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=24, events=POLLIN}, {fd=28, events=POLLIN}], 5, 0) = 0
(Timeout)
9222 recvmsg(4, {msg_namelen=0}, 0)= -1 EAGAIN (Die Ressource ist zur Zeit
nicht verfügbar)
9222 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=24, events=POLLIN}, {fd=28, events=POLLIN}], 5, 0) = 0
(Timeout)
9222 recvmsg(4, {msg_namelen=0}, 0)= -1 EAGAIN (Die Ressource ist zur Zeit
nicht verfügbar)
9222 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=24, events=POLLIN}, {fd=28, events=POLLIN}], 5, 0) = 0
(Timeout)
9222 recvmsg(4, {msg_namelen=0}, 0)= -1 EAGAIN (Die Ressource ist zur Zeit
nicht verfügbar)
9222 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=24, events=POLLIN}, {fd=28, events=POLLIN}], 5, -1
9272 <... futex resumed>) = -1 ETIMEDOUT (Die Wartezeit für die
Verbindung ist abgelaufen)
9272 futex(0x7f9b3833e980, FUTEX_WAKE_PRIVATE, 1) = 0
9272 futex(0x7f9b481296e8, FUTEX_WAKE_PRIVATE, 1) = 1
9282 <... futex resumed>) = 0
9282 futex(0x7f9b48129690, FUTEX_WAKE_PRIVATE, 1
9272 write(29, "\372", 1
9282 <... futex resumed>) = 0
9282 futex(0x7f9b481296ec, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0,
NULL, FUTEX_BITSET_MATCH_ANY
9272 <... write resumed>) = 1
9222 <... poll resumed>) = 1 ([{fd=28, revents=POLLIN}])
9272 futex(0x7f9b3833e9d8, FUTEX_WAIT_BITSET_PRIVATE, 0, {tv_sec=2776,
tv_nsec=600861196}, FUTEX_BITSET_MATCH_ANY
9222 read(28, "\372", 1) = 1
9222 write(29, "\372", 1) = 1
9222 recvmsg(4, {msg_namelen=0}, 0)= -1 EAGAIN (Die Ressource ist zur Zeit
nicht verfügbar)
9222 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=24, events=POLLIN}, {fd=28, events=POLLIN}], 5, 0) = 1
([{fd=28, revents=POLLIN}])
9222 read(28, "\372", 1) = 1
9222 recvmsg(4, {msg_namelen=0}, 0)= -1 EAGAIN (Die Ressource ist zur Zeit
nicht verfügbar)
9222 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=24, events=POLLIN}, {fd=28, events=POLLIN}], 5, 0) = 0
(Timeout)
9222 futex(0x7f9b481296ec, FUTEX_WAKE_PRIVATE, 1
9282 <... futex resumed>) = 0
9222 <... futex resumed>) = 1
9282 futex(0x7f9b48129690, FUTEX_WAIT_PRIVATE, 2, NULL
9222 futex(0x7f9b48129690, FUTEX_WAKE_PRIVATE, 1
9282 <... futex resumed>) = -1 EAGAIN (Die Ressource ist zur Zeit
nicht verfügbar)
9222 <... futex resumed>) = 0
9282 futex(0x7f9b48129690, FUTEX_WAKE_PRIVATE, 1) = 0
9222 write(29, "\372", 1) = 1
9282 futex(0x7f9b22b521b8, FUTEX_WAKE_PRIVATE, 1
9222 recvmsg(4,
9353 <... futex resumed>) = 0
9282 <... futex resumed>) = 1
9222 <... recvmsg resumed>{msg_namelen=0}, 0) = -1 EAGAIN (Die Ressource ist
zur Zeit nicht verfügbar)
9353 futex(0x7f9b22b52458, FUTEX_WAKE_PRIVATE, 1
9282 futex(0x7f9b481296e8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0,
NULL, FUTEX_BITSET_MATCH_ANY
9222 poll([{fd=4,
Bug#1009689: playlist recursive expansion not working
Package: vlc Version: 3.0.17.3-1 Severity: normal For details, see: https://forum.videolan.org/viewtopic.php?p=480711 I have the same or similar issue again. Setting the "Expand" behavior in the settings of Playlist does not fix it. Command line like: vlc --recursive expand audio does not solve it either. It always opens the playlist in non-expanded mode, which heavily influences the likelyhood of the song selection in Shuffle mode (i.e. if you have many files in the top folder and then another couple of folders with even more files inside, then it will keep selecting songs in the main folder only, until it once hits a folder, only then it is expanded and the content there gets a chance to be played). Best regards, Eduard. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.2+ (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_CRAP Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vlc depends on: ii vlc-bin 3.0.17.3-1 ii vlc-plugin-base 3.0.17.3-1 ii vlc-plugin-qt3.0.17.3-1 ii vlc-plugin-video-output 3.0.17.3-1 Versions of packages vlc recommends: ii vlc-l10n 3.0.17.3-1 pn vlc-plugin-access-extra ii vlc-plugin-notify 3.0.17.3-1 pn vlc-plugin-samba ii vlc-plugin-skins2 3.0.17.3-1 ii vlc-plugin-video-splitter 3.0.17.3-1 ii vlc-plugin-visualization 3.0.17.3-1 Versions of packages vlc suggests: pn vlc-plugin-fluidsynth pn vlc-plugin-jack pn vlc-plugin-svg Versions of packages libvlc-bin depends on: ii libc62.33-7 ii libvlc5 3.0.17.3-1 Versions of packages libvlc5 depends on: ii libc62.33-7 ii libvlccore9 3.0.17.3-1 Versions of packages libvlc5 recommends: ii libvlc-bin 3.0.17.3-1 Versions of packages vlc-bin depends on: ii libc6 2.33-7 ii libvlc-bin 3.0.17.3-1 ii libvlc5 3.0.17.3-1 Versions of packages vlc-plugin-base depends on: ii liba52-0.7.4 0.7.4-20 ii libarchive13 3.6.0-1 ii libaribb24-0 1.0.3-dmo2 ii libasound2 1.2.6.1-2+b1 ii libass9 1:0.15.2-1 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libavc1394-0 0.5.4-5 ii libavcodec58 7:4.4.1-3+b2 ii libavformat587:4.4.1-3+b2 ii libavutil56 7:4.4.1-3+b2 ii libbluray2 1:1.3.1-1 ii libc62.33-7 ii libcairo21.16.0-5 ii libcddb2 1.3.2-7 ii libchromaprint1 1.5.1-2 ii libdav1d50.9.2-1+b1 ii libdbus-1-3 1.14.0-1 ii libdc1394-25 2.2.6-4 ii libdca0 0.0.7-2 ii libdvbpsi10 1.3.3-1 ii libdvdnav4 6.1.1-1 ii libdvdread8 6.1.2-1 ii libebml5 1.4.2-2 ii libfaad2 2.10.0-2 ii libflac8 1.3.4-1 ii libfontconfig1 2.13.1-4.4 ii libfreetype6 2.11.1+dfsg-1 ii libfribidi0 1.0.8-2.1 ii libgcc-s112-20220319-1 ii libgcrypt20 1.10.1-2 ii libglib2.0-0 2.72.0-1+b1 ii libgnutls30 3.7.3-4+b1 ii libgpg-error01.43-3 ii libharfbuzz0b2.7.4-1 ii libixml101:1.8.4-2 ii libjpeg62-turbo 1:2.1.2-1 ii libkate1 0.4.1-11 ii liblirc-client0 0.10.1-6.3 ii liblua5.2-0 5.2.4-2 ii libmad0 0.15.1b-10 ii libmatroska7 1.6.3-2 ii libmpcdec6 2:0.1~r495-2 ii libmpeg2-4 0.5.1-9 ii libmpg123-0 1.29.3-1 ii libmtp9 1.1.19-1 ii libncursesw6 6.3-2 ii libnfs13 4.0.0-1 ii libogg0 1.3.4-0.1 ii libopenmpt-modplug1 0.8.9.0-openmpt1-2 ii libopus0 1.3.1-0.1 ii libpng16-16 1.6.37-3 ii
Bug#1006774: freeze on the first keypress
Package: grub-pc
Version: 2.04-20
Severity: important
Hi,
strange things here. My workstation is using EFI CSM (legacy) mode,
rootfs is on a SATA SSD (MBR parttable), there is also an unrelated NVME
SSD involved.
This has been working for years. Had to replace the CPU recently, which
caused a few hickups, resetting mainboard CMOS, etc.. Now suddenly I
cannot use the GRUB menu anymore. First keystroke freezes GRUB, the
timeout stops ticking.
This happened with grub 2.06, so I downgraded to 2.04 after seeing your
blocker ticket. Didn't make any difference, same freezing.
I googled already, tried different values of GRUB_TERMINAL_INPUT
(usb_keyboard, at_keyboard) and running update-grub afterwards. And no
help, the issue remains.
I tried booting our netinst which apparently comes up in EFI mode and
keyboard navigation works there very well.
That sounds similar to #538381 but it's from another age, and might be
unrelated.
Chipset: AMD AM4, B450, Gigabyte board
Best Regards,
Eduard.
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/mapper/xroot / ext4 rw,noatime,errors=remount-ro,commit=120 0 0
/dev/sda1 /boot ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda3 /mnt/c fuseblk
rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096
0 0
/dev/nvme0n1p4 /mnt/d fuseblk
rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096
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="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
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_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd1,msdos1'
f7939fcb-3ac8-4cea-9fda-6867d31dd41d
else
search --no-floppy --fs-uuid --set=root f7939fcb-3ac8-4cea-9fda-6867d31dd41d
fi
font="/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=de_DE
insmod gettext
fi
terminal_input at_keyboard
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=10
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=10
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd1,msdos1'
f7939fcb-3ac8-4cea-9fda-6867d31dd41d
else
search --no-floppy --fs-uuid --set=root f7939fcb-3ac8-4cea-9fda-6867d31dd41d
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=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-5df203d7-fe19-44e6-87e9-3228b863f54a' {
savedefault
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd1,msdos1'
f7939fcb-3ac8-4cea-9fda-6867d31dd41d
Bug#1003204: set the sticky bit on some InRelease files
Hallo, * Marc Haber [Thu, Jan 06 2022, 09:49:56AM]: > Package: apt-cacher-ng > Version: 3.6.4-1 > Severity: minor > > Hi, > > the sticky bit is set on some InRelease files in my apt-cacher-ng data > directories, but not on all of them: > > [5/3002]mh@pivot:~ $ ls -al /var/cache/apt-cacher-ng/zg20150/dists/*/InRelease > -rw-r--r-T 1 apt-cacher-ng apt-cacher-ng 18K Jan 6 08:50 > /var/cache/apt-cacher-ng/zg20150/dists/bookworm-zg-stable/InRelease > -rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 18K Jan 5 21:06 > /var/cache/apt-cacher-ng/zg20150/dists/bookworm-zg-unstable/InRelease > -rw-r--r-T 1 apt-cacher-ng apt-cacher-ng 18K Jan 6 08:50 > /var/cache/apt-cacher-ng/zg20150/dists/bullseye-zg-stable/InRelease > -rw-r--r-T 1 apt-cacher-ng apt-cacher-ng 18K Jan 6 08:50 > /var/cache/apt-cacher-ng/zg20150/dists/bullseye-zg-unstable/InRelease > -rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 18K Jan 6 08:50 > /var/cache/apt-cacher-ng/zg20150/dists/buster-zg-stable/InRelease > -rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 18K Jan 5 20:44 > /var/cache/apt-cacher-ng/zg20150/dists/buster-zg-unstable/InRelease > -rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 18K Sep 10 17:46 > /var/cache/apt-cacher-ng/zg20150/dists/jessie-zg-stable/InRelease > -rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 18K Sep 10 17:46 > /var/cache/apt-cacher-ng/zg20150/dists/jessie-zg-unstable/InRelease > -rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 23K Sep 4 13:04 > /var/cache/apt-cacher-ng/zg20150/dists/sid-zg-experimental/InRelease > -rw-r--r-T 1 apt-cacher-ng apt-cacher-ng 23K Jan 6 08:50 > /var/cache/apt-cacher-ng/zg20150/dists/sid-zg-stable/InRelease > -rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 23K Jan 4 21:08 > /var/cache/apt-cacher-ng/zg20150/dists/sid-zg-testing/InRelease > -rw-r--r-T 1 apt-cacher-ng apt-cacher-ng 23K Jan 6 08:50 > /var/cache/apt-cacher-ng/zg20150/dists/sid-zg-unstable/InRelease > -rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 18K Jan 6 09:25 > /var/cache/apt-cacher-ng/zg20150/dists/stretch-zg-stable/InRelease > -rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 18K Jan 5 21:05 > /var/cache/apt-cacher-ng/zg20150/dists/stretch-zg-unstable/InRelease > [6/3003]mh@pivot:~ $ > > If this is the intended behavior, the reason should be documented > because the sticky bit on files is at least unusual. Please check your setting of "FilePerms" in the configuration. That picture can only be explained if some files were created earlier and some files were created later, and there was a change of FilePerms value inbetween. That setting only gets applied to newly created files (see open(2)). The mode argument specifies the file mode bits to be applied when a new file is created. If neither O_CREAT nor Best regards, Eduard. -- Verbindet man Religion nicht mit Moralität, so wird Religion nur zur Gunstbewerbung. -- Immanuel Kant
Bug#1001645: pulseaudio: My system has no sound at all, after upgrading
On Mon, 13 Dec 2021 21:29:34 +0330 alireza wrote: > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? upgrade >* What exactly did you do (or not do) that was effective (or > ineffective)? upgrade >* What was the outcome of this action? no sound at all! >* What outcome did you expect instead? sound ! Dear reporter, you were supposed to enter a detailed description here. Maybe I can provide mine, does this match your experiences? since the last update, PA is almost completely BROKEN. a) ALSA devices which were detected prior to PA start do not work AT ALL. The only Sink in the mixer is "Dummy-Output". Log output is something like this: Failed to load module "module-alsa-card" (argument: "device_id="1" name="pci-_09_00.3" card_name="alsa_card.pci-_09_00.3" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1""): initialization failed. b) When I reconnect the device then it works briefly, for exactly one stream. Once the stream stops, the device becomes mute. It's still there but no sound comes out of it. c) If you restart PA in the condition above, then even the new device is not detected any longer. Best regards, Eduard. -- morgen! was ist morgen? aehm, mittwoch!
Bug#1001544: please UNMUTE a tab when user changes sound volume
Package: firefox
Version: 95.0-1
Severity: important
Hello,
recently I was was hit by the issue demonstrated in
https://askubuntu.com/questions/967061/firefox-keeps-resetting-pulse-volume-to-0
and this is a UX issue which FF should solve.
What is happening here? I am not sure (exatly). Maybe the Tab was muted
by me, or maybe it was muted by opening multiple YT tabs. Not sure.
The point is: I start playing some YT video. And there is basically NO
SOUND. I still CAN click on the audio settings of the audio player and
change the volume. And I still don't hear anything. The YT audio icon is
"apparently" not showing my audio status as muted, so I expect something
to be audible.
Next act: I open pavucontrol and see that there is an active stream from
FF but the volume is 0. Why 0%? Dunno, I can change it to something and
then I can her the sound. But only for a short while, after the track
changes, the sound volume returns to 0% again. WAT?
The mentioned askubuntu posting explains the reason for the strange
behavior. But it's really surprising. And it's really hard to spot, the
only indication of the mute-forcing behavior is a thin gray line in an
icon of the tab.
Please CHANGE THIS. Make the user aware of the brute-force-muting
behaviour of FF by showing a flashy "soundblock" icon on that tab.
AND:
when $USER tried to change volume, it should be unmuted, not ignored.
Best regards,
Eduard.
-- Package-specific info:
-- Extensions information
Name: Abstract — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Abstract — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Abstract — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Add-ons Search Detection
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Amazon.co.uk
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Bing
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Binnen-I be gone
Location: ${PROFILE_EXTENSIONS}/{b65d7d9a-4ec0-4974-b07f-83e30f6e973f}.xpi
Status: enabled
Name: Cheers — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Cheers — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Cheers — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: ClearURLs
Location: ${PROFILE_EXTENSIONS}/{74145f27-f039-47ce-a470-a662b129930a}.xpi
Status: user-disabled
Name: Copy ShortURL
Location: ${PROFILE_EXTENSIONS}/jid0-odikjs9b4it3h1nylpkr0ndt...@jetpack.xpi
Status: user-disabled
Name: Dark theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Deutsch (DE) Language Pack locale
Location:
/usr/lib/firefox/browser/extensions/langpack...@firefox.mozilla.org.xpi
Package: firefox-l10n-de
Status: enabled
Name: DoH Roll-Out
Location: /usr/lib/firefox/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: DuckDuckGo
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: eBay
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Ecosia
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Elemental — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Elemental — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Elemental — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Firefox Alpenglow theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled
Name: Foto — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Foto — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Foto — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Google
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled
Name: Graffiti — Balanced theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Graffiti — Bold theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: Graffiti — Soft theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled
Name: HTTP Header Live
Location: ${PROFILE_EXTENSIONS}/{ed102056-8b4f-43a9-99cd-6d1b25abe87e}.xpi
Bug#996730: Certain menus don't work right when chrome is in the Normal Layer
Control: severity 996730 important Control: tags 996730 +notreproducible +upstream Hallo, * 積丹尼 Dan Jacobson [Mon, Oct 18 2021, 03:42:00AM]: > Package: icewm > Version: 2.8.0-1 > Severity: grave > > Are there any other users who can confirm > https://github.com/ice-wm/icewm/issues/62 ? I have no idea what you mean and this is definitively not "grave". Tried to reproduce with different settings and chromium 93.0.4577.82-1 and it just works. Maybe some issue with other software on your system which is manipulating properties? Maybe gijsbers finds something. Does it work if you downgrade icewm (and icewm-common) to the Testing version? Best regards, Eduard.
Bug#996539: ITP: sqlitecpp -- a smart and easy to use C++ SQLite3 wrapper
Control: merge 996539 948701 Hallo, * YaNing Lu [Fri, Oct 15 2021, 05:18:13AM]: >Package: wnpp >Severity: wishlist >X-Debbugs-Cc: [1]debian-de...@lists.debian.org Did my response to the private mail get lost? Since you apparently prefered not to take over #948701, I will merge them in BTS so they get closed together automatically. Best regards, Eduard.
Bug#948701: Acknowledgement (ITP: libsqlitecpp -- smart and easy to use C++ SQLite3 wrapper)
Control: retitle 948701 RFP: libsqlitecpp -- smart and easy to use C++ SQLite3 wrapper I lost the requirement for that package as of now, but it's still a potentially good addition to Debian, IMHO. Whoever cares, feel free to take over. The pre-packaged version at https://github.com/Code7R/SQLiteCpp/tree/debian/sid might need an update.
Bug#995975: UDP socket from DNS keeps listening on 0.0.0.0
Control: retitle 995975 UDP socket from DNS keeps listening on 0.0.0.0
Control: reassign 995975 libevent-extra-2.1-7
Hallo,
* Richard Lewis [Sat, Oct 09 2021, 03:45:03PM]:
> Sorry, im not sure how to make gmail sensibly so i may have mangled
> the quoting. Thanks for replying - and I'm sure there is indeed a
> significant change ive done something wrong, or misunderstood
> something.
>
> On Sat, 9 Oct 2021 at 14:59, Eduard Bloch wrote:
> >
> > > I set "BindAddress: localhost" in /etc/apt-cacher-ng/acng.conf
> >
> > So, please do a "grep -i bindaddr /etc/apt-cacher-ng/*.conf" and report
> > what's there.
>
> grep -i bindaddr /etc/apt-cacher-ng/*.conf
> /etc/apt-cacher-ng/acng.conf:56:# BindAddress: localhost 192.168.7.254
> publicNameOnMainInterface
> /etc/apt-cacher-ng/acng.conf:58:BindAddress: localhost
> /etc/apt-cacher-ng/acng.conf:379:# BindAddress value.
>
> ie, nothing other than comments and the setting in acng.conf
Okay so far.
> > That does not make sense. First, apt-cacher is not apt-cacher-ng (its a
> > different package). Second: no listening ports are bound after the
> > startup in apt-cacher-ng.
> >
> > > ss -tunlp|grep apt
> > > udp UNCONN 0 0 0.0.0.0:41044 0.0.0.0:*
> > > users:(("apt-cacher-ng",pid=2584993,fd=11))
> > > tcp LISTEN 0 250 127.0.0.1:3142 0.0.0.0:*
> > > users:(("apt-cacher-ng",pid=2584993,fd=10))
> >
> > I cannot see 0.0.0.0:3142 here, and especially not in TCP context. What do
> > you mean?
>
> the issue is the udp line not the tcp line. the tcp line is exactly
> what i expected. the udp should either not be there at all or should
> say 127.0.0.1:41044. at least, that is what i think the output means.
It's most likely a dangling UDP socket from the evdns resolver library.
I have seen them before and they were one of the reasons why I switched
DNS resolution to libc-ares now (another reason is the SRV record
support).
I am not sure whether this is a security risk, though. The resolver
expects a response from the peer somehow. If you expect it to be extra
paranoid and listen only on a specific interface for its client
activities, that would be probably huge implementational effort for very
little security gain.
> > The UDP socket is probably the DNS resolver.
>
> it's certainly nothing to do with the usual dns resolvers running on my
> system.
> (unless you are saying that apt-cacher-ng includes a DNS resolver?)
Yes, I was refering to DNS resolver CODE in the application.
So, reassigning this to libevent now. The issue is reproducible in a
quick test in a container, and it disappears in the Sid version (which
using c-ares resolver instead of evdns).
Best regards,
Eduard.
Bug#994778: closed by Debian FTP Masters (reply to Eduard Bloch ) (Bug#994778: fixed in apt-cacher-ng 3.7.3-1)
Control: reopen 994778 Control: severity 994778 minor Control: tags 994778 +upstream Hallo, * corubba [Mon, Oct 11 2021, 08:40:33PM]: > Dear Maintainer, > > unfortunately the bug is not yet fully fixed. Well, I used your test vectors for the unit tests and considered it done. :-) > These do work now as expected: > BindAddress=:: -> binds to [::]:3142 > BindAddress=:::1 -> throws an "invalid address" error > BindAddress=[::]:1 -> binds to [::]:1 > BindAddress=1:: -> binds to [1::]:3142 > BindAddress=::1 -> binds to [::1]:3142 > BindAddress=[1::1] -> binds to [1::1]:3142 > BindAddress=[1:2:3:4:5:6:7:8]-> binds to [1:2:3:4:5:6:7:8]:3142 > BindAddress=[1:2::7:8] -> binds to [1:2::7:8]:3142 > BindAddress=[1:2:3:4:5:6:7:::8] -> throws an "invalid address" error > BindAddress=[1:2:3:4:5:6:7:8:9] -> throws an "invalid address" error We will see where it fits. This might be fixed in the next major version, or in the next generation where I considered switching the whole parser code to a 3rd party lib. > These still don't work as expected: > BindAddress=1::1 -> binds to nothing, should be > [1::1]:3142 > BindAddress=1:2:3:4:5:6:7:8 -> binds to nothing, should be > [1:2:3:4:5:6:7:8]:3142 > BindAddress=1:2::7:8 -> binds to [1:2::7]:8 but should be > [1:2::7:8]:3142 > BindAddress=1:2:3:4:5:6:7:::8-> binds to [1:2:3:4:5:6:7::]:8 but > should throw an "invalid address" error > BindAddress=1:2:3:4:5:6:7:8:9-> binds to [1:2:3:4:5:6:7:8]:9 but > should throw an "invalid address" error Best regards, Eduard.
Bug#995975: apt-cacher-ng: Listens on 0.0.0.0 despite "BindAddress" being set
Control: severity 995975 important
Control: 995975 notreproducible
> I set "BindAddress: localhost" in /etc/apt-cacher-ng/acng.conf
I smell a source of confusion here. Please read that file from the start.
# IMPORTANT NOTE:
#
# THIS FILE IS MAYBE JUST ONE OF MANY CONFIGURATION FILES IN THIS DIRECTORY.
# SETTINGS MADE IN OTHER FILES CAN OVERRIDE VALUES THAT YOU CHANGE HERE. GO
# LOOK FOR OTHER CONFIGURATION FILES! CHECK THE MANUAL AND INSTALLATION NOTES
# (like README.Debian) FOR MORE DETAILS!
So, please do a "grep -i bindaddr /etc/apt-cacher-ng/*.conf" and report
what's there.
> -- Configuration Files:
> /etc/apt-cacher-ng/acng.conf changed [not included]
> /etc/apt-cacher-ng/security.conf [Errno 13] Permission denied:
> '/etc/apt-cacher-ng/security.conf'
>
> -- debconf information:
> * apt-cacher-ng/tunnelenable: false
> apt-cacher-ng/cachedir: keep
> apt-cacher-ng/proxy: keep
> * apt-cacher-ng/gentargetmode: Set up now and update later
Maybe there is some debconf issue, since this value would keep updating
/etc/apt-cacher-ng/zz_debconf.conf on every update. OTOH, this:
> apt-cacher-ng/bindaddress: keep
... should also disable the assignment of BindAddress directory.
Please post zz_debconf.conf of whatever was identified by grep.
> when i restart the service it is indeed listening on 127.0.0.1:3142 (for tcp)
> But when apt-cacher starts doing something (I use it via sbuild) it also
> starts
> listening on 0.0.0.0 + a random port for udp. I would expect 127.0.0.1:41044
> only in:
That does not make sense. First, apt-cacher is not apt-cacher-ng (its a
different package). Second: no listening ports are bound after the
startup in apt-cacher-ng.
> ss -tunlp|grep apt
> udp UNCONN 0 0 0.0.0.0:41044 0.0.0.0:*
> users:(("apt-cacher-ng",pid=2584993,fd=11))
> tcp LISTEN 0 250 127.0.0.1:3142 0.0.0.0:*
> users:(("apt-cacher-ng",pid=2584993,fd=10))
I cannot see 0.0.0.0:3142 here, and especially not in TCP context. What do you
mean?
The UDP socket is probably the DNS resolver.
> isnt this a security risk? (It gets flagged by the tiger package as such -
> now I do know that
> in fact it may be a low risk and that it is easily mitigated via firewall
> rules, but i dont want
> apt-cacher-ng listening on any external ip, especially when the config
> explicitly tells it not to.)
> this did not happen in the 'buster' version, so is a regression in the new
> stable release
>
> I also wonder why the default setting is so permissive - surely the biggest
> use-case is for building on
What exactly is the security risk? The default setting? Well, you
install a network daemon, wouldn't a normal user expect it to listen on
the network??
> a localhost via sbuild or similar, and people who want to provide a cache to
> other machines would be able
> to change the default. (but any default is fine as long as it can be changed
> - but the above shows the
> change isnt working)
But they can change the default on installation or via debconf.
dpkg-reconfigure -plow apt-cacher-ng
> Thanks for considering to fix this
Not sure what to fix yet.
Best regards,
Eduard.
Bug#795284: troubles with range requests
Control: severity 795284 important On Tue, 25 Aug 2015 15:04:29 +0100 Mark Hindley wrote: > package apt-cacher > reassign 795284 apt > thanks > > I have looked at this some more and I think apt-cacher is following the spec > correctly. It seems as if apt-get doesn't realise that the 416 response with > the > Content-Range denominator equal to the size it already has indicates the file > is > complete. > > So I am going to reassign to apt. > > Apt team, if I have got this analysis wrong, sorry, do point out my error and > assign > back. Dear apt team, I came recently to erratical behavior of apt with apt-cacher-ng (not apt-cacher but similar). Checking the wireshark trace, I see strange things, see below. For me, what apt's http client is doing there DOES NOT MAKE MUCH SENSE. The ancient version, like 10 years ago, used a very simple and effective trick. It specified If-Range but also a Range which started one byte _before_ the previous body length. So the server could either return just a byte or start returning a completely new resource body with a 200 response, no extra rounds needed. What does the current version do? It requests the file but the with If-Range (which is okay) and Range which starts AFTER the body. This obviously causes a code 416 even if the response body hasn't changed. In response, apt makes another request, with "If-Modified-Since" from a day ago - so I guess it has another version in cache, which it takes as replacement now. It also does not specify the Range. So I guess the issue 795284 is mostly solved but not fully, we got another pointless behavior now. So, the current version behaves better than in 2015, but still worse than ~10 years ago. Please restore the original algorithm, which refetched the last byte. This causes less bandwith waste than doing a second request which will almost always become necessary. (local trace, input/output interleaved but you see the point). GET http://ftp.de.debian.org/debian/dists/testing/InRelease HTTP/1.1 Host: ftp.de.debian.org Cache-Control: max-age=0 Accept: text/* Range: bytes=128490- If-Range: Fri, 08 Oct 2021 14:16:00 GMT User-Agent: Debian APT-HTTP/1.3 (2.3.9) HTTP/1.1 416 Requested Range Not Satisfiable Content-Length: 512 Content-Type: text/html Date: Fri, 08 Oct 2021 18:26:45 GMT Server: Debian Apt-Cacher NG/3.7.3 ... href="http://www.unix-ag.uni-kl.de/~bloch/acng/;>Apt-Cacher NG homepage GET http://ftp.de.debian.org/debian/dists/testing/InRelease HTTP/1.1 Host: ftp.de.debian.org Cache-Control: max-age=0 Accept: text/* If-Modified-Since: Thu, 07 Oct 2021 14:15:24 GMT User-Agent: Debian APT-HTTP/1.3 (2.3.9) HTTP/1.1 200 OK Content-Type: octet/stream Last-Modified: Fri, 08 Oct 2021 14:16:00 GMT Content-Length: 128490 X-Original-Source: http://deb.debian.org/debian/dists/testing/InRelease Date: Fri, 08 Oct 2021 18:26:45 GMT Server: Debian Apt-Cacher NG/3.7.3 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Origin: Debian Label: Debian ... Best regards, Eduard.
Bug#994032: switch from https to http transport for certain proxies
Package: apt Version: 2.3.9 Severity: wishlist Hi, as of now, there are certain HTTPS protocol schemes used in apt in conjunction with proxies. a) for http, the requests are used with GET and plain URL over http transport b) for https, CONNECT establishes a tunnel and then plain http over TLS stream is used What we don't have is option c) the user might trust his proxy and want requests to be made in plain text (GET) but with https:// schema, and the proxy gets the responsibility for HTTPS communication and delivery of the content as plain HTTP response. This should be configurable through some options. Some idea from mstone and me in the recent debian-devel thread about #992692: > If we're imagining apt options, something like > Acquire::https::Force-Proxy-HTTP true; > would probably be more useful for this specific case (not that I think it's > a great idea--too much potential for surprise). I would make it a list of trusted hosts and a special value ALL. Best regards, Eduard. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.1+ (SMP w/12 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser 3.118 ii debian-archive-keyring 2021.1.1 ii gpgv2.2.27-2 ii gpgv2 2.2.27-2 ii libapt-pkg6.0 2.3.9 ii libc6 2.31-17 ii libgcc-s1 11.2.0-4 ii libgnutls30 3.7.2-2 ii libseccomp2 2.5.1-1 ii libstdc++6 11.2.0-4 ii libsystemd0 247.9-1 Versions of packages apt recommends: ii ca-certificates 20210119 Versions of packages apt suggests: ii apt-doc 2.3.8 pn aptitude | synaptic | wajig ii dpkg-dev 1.20.9 ii gnupg2.2.27-2 ii gnupg2 2.2.27-2 ii powermgmt-base 1.36 -- no debconf information
Bug#990308: FTBFS on non-vanilla system, pthread detection
Hallo, * Lisandro Damián Nicanor Pérez Meyer [Thu, Jul 08 2021, 09:13:43AM]: > > CMake Error at /usr/lib/llvm-12/lib/cmake/clang/ClangTargets.cmake:699 > > (message): > > The imported target "clangBasic" references the file > > > > "/usr/lib/llvm-12/lib/libclangBasic.a" > > > > but this file does not exist. Possible reasons include: > > > > * The file was deleted, renamed, or moved to another location. > > > > * An install or uninstall procedure did not complete successfully. > > > > * The installation package was faulty and contained > > > > "/usr/lib/llvm-12/lib/cmake/clang/ClangTargets.cmake" > > > > but not all the files it references. > > > I don't know if creator is ready for llvm 12, but I'm pretty sure we > will find out as soon as bullseye is released. > > Thanks for the bug report, Lisandro. Ok, thanks. By the way, I came to build it locally in order to compile https://github.com/CJCombrink/SpellChecker-Plugin . Do you know a better (maybe already existing) plug-in for regular spellchecking, or could the mentioned project get added to qtcreator? Or to some auxiliary package, like qtcreator-extras? Best regards, Eduard. -- Aber ich bin bekannt für meine ausgesprochene Liebe zu PHP...
Bug#991273: acng: for testing dist fails to download by-hash translations
Hallo, * Václav Ovsík [Mon, Jul 19 2021, 03:05:39PM]: > Package: apt-cacher-ng > Version: 3.3.1-2~bpo10+1 > Severity: normal That's an ancient version in backports. Sorry for not having updated this for a long time. > Dear Maintainer, > I tried to install bullseye machine and it fails to download some > translations and installation fails: > > Jul 19 10:29:53 in-target: E: Failed to fetch > http://debian.i.cz:/debian/dists/bullseye/non-free/i18n/by-hash/SHA256/1719a3a7f5c969d9780aec600763314a8b55aaaed3016a76fa9a7a020c1e584c > File has unexpected size (50436 != 91475). Mirror sync in progress? [IP: > 10.0.156.66 ] > Jul 19 10:29:53 in-target:Hashes of expected file: > Jul 19 10:29:53 in-target: - Filesize:91475 [weak] > Jul 19 10:29:53 in-target: - > SHA256:1719a3a7f5c969d9780aec600763314a8b55aaaed3016a76fa9a7a020c1e584c > Jul 19 10:29:53 in-target: - MD5Sum:c3ad4b048f3df02478a64b33ef776008 > [weak] That kind of corruption is supposed to be fixed in the Testing version. I started the backport process but I am waiting for additionial dependency to be accepted as backport in the archive (https://buildd.debian.org/status/package.php?p=c-ares=buster-backports). > Its obvious from the curl output: > > zito@ser1:~/admin$ curl --head > http://debian.i.cz:/debian/dists/bullseye/non-free/i18n/by-hash/SHA256/1719a3a7f5c969d9780aec600763314a8b55aaaed3016a76fa9a7a020c1e584c > HTTP/1.1 200 OK > Content-Length: 50436 > Last-Modified: Tue, 15 Jun 2021 01:57:32 GMT This looks very wrong and indicates a file truncation in the cache. I suggest to go to the admin webpage and run a cleanup operation (Expiration task, with "check sizes and checksums" and "consider incomplete files as damaged" checkboxes checked). Best regards, Eduard.
Bug#990308: FTBFS on non-vanilla system, pthread detection
Package: qtcreator Version: 4.14.1-1 Severity: important Tags: ftbfs Hi, see below, smells like missing -lpthread in the minimum linker flags of subsequent tests. What was performed: $ apt source qtcreator $ cd ... $ apt build-dep qtcreator $ debuild dpkg-buildpackage -us -uc -ui dpkg-buildpackage: Information: Quellpaket qtcreator dpkg-buildpackage: Information: Quellversion 4.14.1-1 dpkg-buildpackage: Information: Quelldistribution unstable dpkg-buildpackage: Information: Quelle geändert durch Pino Toscano dpkg-buildpackage: Warnung: von langen OpenPGP-Schlüsselkennungen wird klar abgeraten; bitte verwenden Sie stattdessen Fingerabdrücke in -k oder DEB_SIGN_KEYID dpkg-source --before-build . dpkg-buildpackage: Information: Host-Architektur amd64 debian/rules clean dh clean --builddirectory=builddir dh_auto_clean -O--builddirectory=builddir dh_autoreconf_clean -O--builddirectory=builddir dh_clean -O--builddirectory=builddir dpkg-source -b . dpkg-source: Information: Quellformat »3.0 (quilt)« wird verwendet dpkg-source: Information: qtcreator wird unter Benutzung des existierenden ./qtcreator_4.14.1.orig.tar.xz gebaut dpkg-source: Information: Patchliste aus debian/patches/series wird verwendet dpkg-source: Information: qtcreator wird in qtcreator_4.14.1-1.debian.tar.xz gebaut dpkg-source: Information: qtcreator wird in qtcreator_4.14.1-1.dsc gebaut debian/rules binary dh binary --builddirectory=builddir dh_update_autotools_config -O--builddirectory=builddir dh_autoreconf -O--builddirectory=builddir debian/rules override_dh_auto_configure make[1]: Verzeichnis „/tmp/qtcreator-4.14.1“ wird betreten dh_auto_configure --buildsystem=cmake -- \ -DBUILD_DEVELOPER_DOCS=ON \ -DBUILD_QBS=OFF \ -DWITH_DOCS=ON cd builddir && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DBUILD_DEVELOPER_DOCS=ON -DBUILD_QBS=OFF -DWITH_DOCS=ON .. -- The C compiler identification is GNU 10.2.1 -- The CXX compiler identification is GNU 10.2.1 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/lib/ccache/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/lib/ccache/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Looking for pthread.h -- Looking for pthread.h - found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11") CMake Error at /usr/lib/llvm-12/lib/cmake/clang/ClangTargets.cmake:699 (message): The imported target "clangBasic" references the file "/usr/lib/llvm-12/lib/libclangBasic.a" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/llvm-12/lib/cmake/clang/ClangTargets.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/cmake/clang-12/ClangConfig.cmake:20 (include) cmake/FindClang.cmake:1 (find_package) CMakeLists.txt:55 (find_package) -- Configuring incomplete, errors occurred! See also "/tmp/qtcreator-4.14.1/builddir/CMakeFiles/CMakeOutput.log". See also "/tmp/qtcreator-4.14.1/builddir/CMakeFiles/CMakeError.log". cd builddir && tail -v -n \+0 CMakeCache.txt ==> CMakeCache.txt <== # This is the CMakeCache file. # For build in directory: /tmp/qtcreator-4.14.1/builddir # It was generated by CMake: /usr/bin/cmake # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. # EXTERNAL cache entries //No help, variable specified on the command line. BUILD_DEVELOPER_DOCS:UNINITIALIZED=ON //Build executables by default. This can be used to build all executables // by default, or none.
Bug#989193: [pkg-apparmor] Bug#989193: breaks apt-cacher-ng by blocking link operation
Hallo, * intrigeri [Wed, Jun 02 2021, 10:13:12AM]: > Control: tag -1 + upstream > Control: forwarded -1 > https://gitlab.com/apparmor/apparmor-profiles/-/merge_requests/51 > Control: tag -1 + moreinfo > > Hi, > > Eduard Bloch (2021-05-28): > > see attachment, your config which doesn't allow link calls, which > > sporadically breaks operation of apt-cacher-ng in unexpected ways. > > Thanks! I've turned this patch into an upstream merge request. > > I see you've made this bug RC. I'd like to better understand the I set it RC because it deliberately breaks other package's (legal) operations, and installing such booby traps was not properly announced. And because you take away the control over the package's behavior from the maintainers and push them to "collaboration", if I understood https://wiki.debian.org/AppArmor/Contribute/MergeProfileFromUpstream correctly. In a way I don't like (shoot first, ask later). > severity, so I can figure out what I should do for Bullseye. > I'm wondering because I'm using this AppArmor policy on sid with There were issues with rare file truncation, one of the potential improvements was applies after soft-freeze. Line 847 at https://salsa.debian.org/blade/apt-cacher-ng/-/blob/upstream/sid/source/fileitem.cc which is a more careful rotation of files with volatile contents. > apt-cacher-ng myself, and I can't find traces of such denials in > my logs. Please. Just because you don't see issues does not mean that issues don't exist. > Could you please help me understand what kind of apt-cacher-ng > operations (or configuration) trigger these denials and are broken by > the current AppArmor policy? When the mentioned mechanism was put in place, regular operation started breaking. This also affects the expiration jobs, therefore your cache will keep growing when users use non-stable distros. Or what exactly did make you think that "rw" is okay and everything else can be dumped? Where are we? "I see all cars on my road are driving straight, means that we can remove all steering wheels"? *facepalm* Eduard.
Bug#989118: please try https first
Hallo, * Harald Dunkel [Wed, May 26 2021, 10:10:16AM]: > Package: apt-cacher-ng > Version: 3.6.3-1 > Severity: wishlist > > Sorry to say, but configuring https for apt-cacher-ng is APITA. Would it be > possible for ACNG to silently try https first, if the client asked for http? > That would be similar to an explicit http://HTTPS///get.docker.com/ubuntu, > except for the client doesn't have to know. Here you can play with it: https://salsa.debian.org/blade/apt-cacher-ng/-/tree/feature/debian/bts-989118_Optimistic-TLS-probing But I am not convinced, it has issues: a) additional network traffic b) most mirrors have some kind of broken or missing TLS configuration like snake-oil cets or generic host cert not matching the mirror hostname and apparently no SNI active. This can be "mitigated" by partly disabling the host validation but it makes it insecure. c) some mirrors actually offering different folder configuration on TLS port, therefore delivering 404 or maybe even wrong contents. The last problem is hard to detect and to work around in reliable fashion. So basically I'd prefer not to include this feature for now. Best regards, Eduard.
Bug#986749: Bad file descriptor / failed to move stale items / storage error / hash mismatch and other
notfound 986749 3.6.4-1 notfound 986749 3.7-1 severity 986749 serious thanks On Thu, 15 Apr 2021 13:49:22 + FUSTE Emmanuel wrote: > Hello, > > I have similar problems exacerbated by tree level of "forcemanaged=1" of > apt cacher servers behind a blucoat proxy. > Somes are VM, somes are physical. All machines / OS are ok. > My conf use VfileUseRangeOps:-1 and ResuseConnections:0 > Trashing all the caches on all the servers even does not completely cure > the problem which reappear shortly. > Client concurrency activity worsen/trigguer the problem very very fast. > Smell like treading problems. > Will activate Debug: 7 and report here if I see something interesting. After excessive testing, I am pretty sure that the root cause of this problem was solved in the commit https://salsa.debian.org/blade/apt-cacher-ng/-/commit/c333cf3829e6373bcad07c831436317a7c34fac1 or for Sid (hopefully unblocked...): https://salsa.debian.org/blade/apt-cacher-ng/-/commit/2afc3d384b2c051f2754730ed392ea5381f854f1 The other aspects with stale storage items (file recreation) were already tackled in versions 3.6.2 und 3.6.3. Your guess was not bad, the Bad-File-Descriptor problem was related to concurrency issues but the error path was not trivial. First, there was buggy usage of a RAII helper (unique_fd) which was added as an afterthought in the commit: 0c02c1a0 (Eduard Bloch 2019-11-23 11:46:20 +0100 This was never used correctly though, the extra member in the class was only for "design beauty" (uniformity) and is basically not used, but it was interfering with the existing method for graceful connection shutdown (see destructor). So actually after that change the socket was closed ASAP and NOT graceful (risking loss of the final bytes of the active TCP stream) which is an issue of its own, and then the delayed closer code (see sockio.cc) came along and tried to close this socket again, which killed random streams depending on the timing. This was not obvious with a fast server and a few clients but with some load, this becomes a real problem. Then, another problem was the graceful-closing code itself. It was not thread-safe but it was called from multi-threaded context via the FinishConnection method in conserver.cc. This is now fixed by posting the scheduling task into the IO thread. I'd also consider the code inefficient and error-prone because it was using a hashmap for a purpose where simply allocating the metadata nodes and releasing them is totally sufficient and probably cheaper. So I rewrote this mess in sockio.cc some weeks ago and current code seems to behave stable. I.e. no socket or memory leaks spotted since then. Another minor issue which caught my eye was the forceclose() helper method, which was written in a sloppy way many years ago, and which might call close(-1) once in a while. Which is not a drama but pointless. The method is now dropped in the Unstable commit (see above), it was hardly used anyway. Best regards, Eduard. -- Erst wenn der letzte Programmierer eingesperrt und die letzte Idee patentiert ist, werdet ihr merken, daß Anwälte nicht programmieren können
Bug#989193: breaks apt-cacher-ng by blocking link operation
Package: apparmor-profiles-extra
Version: 1.33
Severity: serious
Tags: patch
Hi,
see attachment, your config which doesn't allow link calls, which
sporadically breaks operation of apt-cacher-ng in unexpected ways.
The suggested change should probably be improved, I am no apparmor
expert.
[ 1451.927739] audit: type=1400 audit(1622048089.493:85): apparmor="ALLOWED"
operation="link" profile="apt-cacher-ng"
name="/var/cache/apt-cacher-ng/debrep/dists/unstable/InRelease.1622048089"
pid=36785 comm="apt-cacher-ng" requested_mask="l" denied_mask="l" fsuid=121
ouid=121 target="/var/cache/apt-cacher-ng/debrep/dists/unstable/InRelease"
Eduard.
-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.12.0+ (SMP w/12 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apparmor-profiles-extra depends on:
ii apparmor 2.13.6-10
apparmor-profiles-extra recommends no packages.
apparmor-profiles-extra suggests no packages.
-- Configuration Files:
/etc/apparmor.d/usr.sbin.apt-cacher-ng changed:
@{APT_CACHER_NG_CACHE_DIR}=/var/cache/apt-cacher-ng
profile apt-cacher-ng /usr/sbin/apt-cacher-ng {
#include
#include
#include
#include
/etc/apt-cacher-ng/ r,
/etc/apt-cacher-ng/** r,
/etc/hosts.{deny,allow} r,
/usr/sbin/apt-cacher-ng mr,
/var/lib/apt-cacher-ng/** r,
/{,var/}run/apt-cacher-ng/* rw,
@{APT_CACHER_NG_CACHE_DIR}/ r,
@{APT_CACHER_NG_CACHE_DIR}/** rwl,
/var/log/apt-cacher-ng/ r,
/var/log/apt-cacher-ng/* rw,
/{,var/}run/systemd/notify w,
/{usr/,}bin/dash ixr,
/{usr/,}bin/ed ixr,
/{usr/,}bin/red ixr,
/{usr/,}bin/sed ixr,
/usr/lib/apt-cacher-ng/acngtool ixr,
# Allow serving local documentation
/etc/mime.types r,
/usr/share/doc/apt-cacher-ng/html/** r,
# used by libevent
@{PROC}/sys/kernel/random/uuid r,
# Site-specific additions and overrides. See local/README for details.
#include
}
-- no debconf information
From 5eeca40ec3c93dc0d91ce3db0d9f652310087a12 Mon Sep 17 00:00:00 2001
From: Eduard Bloch
Date: Fri, 28 May 2021 07:11:52 +0200
Subject: [PATCH] Stop breaking latest apt-cacher-ng by blocking link
operations
---
profiles/usr.sbin.apt-cacher-ng | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/profiles/usr.sbin.apt-cacher-ng b/profiles/usr.sbin.apt-cacher-ng
index 6d2f5ff..c24c2c5 100644
--- a/profiles/usr.sbin.apt-cacher-ng
+++ b/profiles/usr.sbin.apt-cacher-ng
@@ -18,7 +18,7 @@ profile apt-cacher-ng /usr/sbin/apt-cacher-ng {
/var/lib/apt-cacher-ng/** r,
/{,var/}run/apt-cacher-ng/* rw,
@{APT_CACHER_NG_CACHE_DIR}/ r,
- @{APT_CACHER_NG_CACHE_DIR}/** rw,
+ @{APT_CACHER_NG_CACHE_DIR}/** rwl,
/var/log/apt-cacher-ng/ r,
/var/log/apt-cacher-ng/* rw,
/{,var/}run/systemd/notify w,
--
2.32.0.rc0
Bug#932177: Please include apparmor profile directly in the package
Hallo, * Laurent Bigonville [Tue, Jul 16 2019, 11:55:52AM]: > Package: apt-cacher-ng > Version: 3.2-2 > Severity: wishlist > > Hi, > > Currectly, the apparmor-profiles-extra package includes a profile for > apt-cacher-ng (/etc/apparmor.d/usr.sbin.apt-cacher-ng) > > IMVHO, it would be better if it was included (and maintained) directly > inside the apt-cacher-ng. > > Could you please see at moving the profile in this package? Yes. In case you have instructions on the proper process to get this fixed, please let me know. Just creating a replacement for their conffile feels like the wrong way to go. Some apparmor weirdness has hit me on one of my systems recently and I would like to have it solved properly. I worked around that with /etc/apparmor.d/local/usr.sbin.apt-cacher-ng for now but it's messy. I actually don't like apparmor people secretly creating a profile for apt-cacher-ng instead of telling the maintainer to fix it properly. On the other hand, apparmor maintenance seems to be a case for the MIA team, their contact address is still an Alioth mailing list. Best regards, Eduard.
Bug#989034: wifi-qr: Pointless package description
Package: wifi-qr Version: 0.2-1 Severity: normal Dear Maintainer, * What led up to the situation? I was looking for a tool which shares files from PC to Android phone, maybe sending the link via QR. * What was the outcome of this action? apt search has found your package. But reading the description adds more questions that it answers. Let's see what it says: >> Description: WiFi Share and Connect with QR What does that mean? Share WHAT? Share the WiFi connection? Is this about tethering or something similar? How shall the reader know? >> Xiaomi Android phones has started using QR to use WiFi for sharing. Nice bit of information but how does that help me to understand what your package does? >> The idea was to get started with Bash, from Android to PC or PC to WHOSE idea, and what was the intention behind that idea?? >> Mobile, and use Interface for zenity What is "the Interface"? Do you mean a "user interface using zenity dialogs" or similar? >> , QR for zbar and qrencode, What does "QR for zbar" mean? Who is zbar and why do I need QR for him I just want to share data? Ant what is "qrencode" about?? >> and nmcli from Network-Manager for Network. For security, >> you can use WPA, WPA2, WEP, Open and share with the Hidden Network. I don't even know yet what this package is good for, and now you ask user to think about security already?? >> QR code does not support LDAP Network and VPN. >> Android can easily generate WiFi QR, but iOS isn't quite so sure. Who is not sure? Android? Mr. Data? This package is no sure? What does that mean? If certain versions support a feature subset, please describe that version range or refer to helpful documentation, but not this "thing XY is not sure". * What outcome did you expect instead? Reading a useful description which describes the actual functionality of the package. Summary: Please improve it and ask actual users to proofread it! Best regards, Eduard. -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=de_DE.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#986356: Support SRV record and add cdn-fastly.deb.debian.org and avoid truncated InRelease
Control: reopen 914852 Hallo, * Osamu Aoki [Fri, Apr 23 2021, 02:35:08PM]: > control: unmerge 986356 > control: merge 986356 954904 > control: retitle 954904 Support SRV record > control: retitle 986356 Support SRV record > control: clone 986356 -1 -2 > control: retitle -1 Add cdn-fastly.deb.debian.org to debvol_mirrors.gz > control: tags -1 patch > control: retitle -2 Truncated InRElease file > control: severity -2 normal > thanks I am loosing track of this mess and I think I have closed on of this issue with the latest experimental release by mistake. > Although > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914852 > is likely caused by the same root cause, let me not get too agressive. > So I am unmerging it. But merging keep 2 bugs together. Okay. Still, wrong issue was hit, sorry. > As I grep the source for "SRV", I do not see it in apt-cacher-ng > source. So I am faily sure apt-cacher-ng doesn't support SRV record. > > https://en.wikipedia.org/wiki/SRV_record > > APT is also written in C++ and it has: > apt/apt-pkg/contrib/srvrec.cc > apt/apt-pkg/contrib/srvrec.h > to support SRV record from 2015. > > It explains as: >DNS SRV record support in apt >= > >Apt supports a subset of the DNS SRV server records protocol as >described in [RFC 2782](https://tools.ietf.org/html/rfc2782) for >service discovery. > >Before connecting to the requested server APT will send a SRV >record request of the form `_$protocol._tcp._$host`, e.g. >`_http._tcp.ftp.debian.org` or `_http._tcp.security.debian.org`. This is ongoing implementation. I switched the code to libc-ares which has SRV support too. However it's not happening automatically (I need to implement a bit of code which does similar considerations as APT) so it is currently not utilized, also because I don't have a good test base to implement it. For deb.debian.org it seems to be pointless because CNAME does the job ATM, or am seing things wrong here? $ host -t SRV deb.debian.org deb.debian.org is an alias for debian.map.fastlydns.net. $ host -t CNAME deb.debian.org deb.debian.org is an alias for debian.map.fastlydns.net. >If the server sends SRV records >as a reply APT will use those to connect to the server(s) in >this reply. It will honor the `priority` field in the reply. > >However it does not implement the `weight` algorithm as described >in RFC 2782. It will use an equal weight for each server of the >same priority. > >If connecting to a server fails APT will retry with the next one >and remove the server from the list of valid servers for this >session. > > Merging this part of code from apt to apt-cacher-ng should fix issues > from the root cause. I am afraid some repos such as one from Ubuntu > may be using the similar configuration. So other bugs may be solved > too. > > Fixing this may fix truncated file problem too. (I don't know) File truncation is likely to be a bug somewhere deep in the downloading code. I tried to find a workaround for the low hanging fruits in 3.6.3 but I am not sure whether it was doing it right. Another issue I have found is with the connection closing code which was not done right and could potentially kill open filehandles or even causing unrelated activities to reuse the ID, therefore maybe even damaging data. This should explains all that "bad file descriptor" issues. I am going to prepare a backport of the changes from the experimental release into stable-proposed-updates but the timing is very unfortunate. > I also cloned this bug to make different issues separate. > > Since without adding cdn-fastly.deb.debian.org as attached file, it > waste cache space if the user uses it in chroot etc.. Since it is > small gz file I atach fixed file itselg here and mark this bug as > patch. This goes to -1 cloned bug. First, the file you sent is generated, so patching it is not okay. Second, I am not sure whether I can reproduce the original issue. Means: for me, using deb.debian.org as source simply works and the last time I checked it was transparently going to fastly service, no extra hops there. Best regards, Eduard.
Bug#986749: apt-cacher-ng: acng still stops working with APOLL ADD failing and Bad file descriptor
Hallo, * Christian Meyer [Sun, Apr 11 2021, 01:26:01PM]: > Package: apt-cacher-ng > Version: 3.6.3-1 > Severity: important > X-Debbugs-Cc: c2h...@web.de > > Dear Maintainer, > > even after the recent acng updates I still see apt-cacher-ng (3.6.3-1 amd64) > stop working. What you describe here does, all in one, not make much sense. Too many symptoms coming together which are not adding up. Are you sure that there is no bad memory or system instability involved? > Apt throws a bunch of errors like: > > E: Fehlschlag beim Holen von > http://deb.debian.org/debian/dists/bullseye/main/Contents-all Fehler beim > Lesen vom Server: Verbindung wurde durch den Se > rver auf der anderen Seite geschlossen. [IP: 127.0.0.1 3142] Closing connection is a potential outcome in worst situations but the connection wouldn't stay down permanently as seen in the rest of your log. Actually, that might be caused by periodic crashes so systemd keeps the server down for a while. Which brings me to the suspicion of system instability. Please send the output of journalctl -b0 -u apt-cacher-ng and also please set debug=7 in acng.conf or similar conf file. If that's a crash, please install systemd-coredump service and we can debug the corefiles later. > E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden > ignoriert oder alte an ihrer Stelle benutzt. > ... > > W: Das Depot »http://127.0.0.1:3142/deb.debian.org/debian bullseye Release« > enthält keine Release-Datei. > E: Fehlschlag beim Holen von > http://127.0.0.1:3142/deb.debian.org/debian/dists/bullseye/main/binary-i386/Packages > 503 Service Unavailable [IP: 127.0. > 0.1 3142] Oh, that's probably our "nice" apt hiding the actual error string and showing this dummy instead. It should match some error in the error log, though. This doesn't make sense. ACNG does not render this message string explicitly. Is there some proxy server involved? > Get:99 http://deb.debian.org/debian bullseye/main amd64 krb5-user amd64 > 1.18.3-4 [151 kB] > Get:100 http://deb.debian.org/debian bullseye/main amd64 ldap-utils amd64 > 2.4.57+dfsg-2 [206 kB] > Get:101 http://deb.debian.org/debian bullseye/main amd64 > linux-image-5.10.0-5-amd64 amd64 5.10.26-1 [53.4 MB] > Err:101 http://deb.debian.org/debian bullseye/main amd64 > linux-image-5.10.0-5-amd64 amd64 5.10.26-1 > Undetermined Error [IP: 127.0.0.1 3142] That's apt's insufficient error message which probably indicates a short read. Would fit to the connection refusal series. > Err:102 http://deb.debian.org/debian bullseye/main amd64 linux-image-amd64 > amd64 5.10.26-1 > Could not connect to 127.0.0.1:3142 (127.0.0.1). - connect (111: Connection > refused) [IP: 127.0.0.1 3142] > Err:103 http://deb.debian.org/debian bullseye/main amd64 whois amd64 5.5.8 > Unable to connect to 127.0.0.1:3142: [IP: 127.0.0.1 3142] > Since systemctl often tells me something about "Epoll ADD" failing: > # systemctl status apt-cacher-ng.service > apt-cacher-ng[646]: [warn] Epoll ADD(1) on fd 14 failed. Old events were 0; > read change was 1 (add); write change was 0 (none); close change was 0 > (none): Bad file descriptor > > my workaround is to automatically restart the service by a cronjob (and after > that /usr/lib/apt-cacher-ng/expire-caller.pl) when this line is seen. And now that is getting really odd. Do you have some kind of application firewall installed, like apparmor? > More information: > > Yes, my internet connection is very slow (around 8000 kbit/s) and that's my > reason to run acng). 8mbit/s isn't awful slow and it shouldn't make a difference anyway. > # less /var/log/apt-cacher-ng/apt-cacher.err.1 > Beside of tons of "Bad file descriptor" messages: > Fri Apr 9 11:13:05 > 2021|debrep/pool/main/f/ffmpeg/libavutil56_4.3.2-0+deb11u1_amd64.deb storage > error [HTTP/1.1 503 Bad file descriptor], last errno: Bad file descriptor > Fri Apr 9 11:13:06 > 2021|debrep/pool/main/c/codec2/libcodec2-0.9_0.9.2-4_amd64.deb storage error > [HTTP/1.1 503 Bad file descriptor], last errno: Bad file descriptor > Fri Apr 9 11:13:17 > 2021|debrep/pool/main/p/pulseaudio/libpulsedsp_14.2-2_amd64.deb storage error > [HTTP/1.1 503 Bad file descriptor], last errno: Bad file descriptor So I checked the code and it doesn't make sense. fileitem.cc:755 is the only location reporting that and it wouldn't get there when the filedescriptor is okay, and you cannot get that FD closed by any regular code path. We can have an interactive Jitsi session if you prefer to get this solved in realtime and it can be made reproducible somehow. Best regards, Eduard.
Bug#986356: Info received (Bug#986356: Attachments (cached package is truncated))
Hallo, * Osamu Aoki [Mon, Apr 05 2021, 08:32:30PM]: > Hi, > I created a script to check all broken repo contents across all debian > and security downloads. > > After fiddling with this problem, I realized few things on this apt- > cacher-ng problem. > > Broken downloads is not just deb file but I also saw truncated > InRelease file. But such problem is much fewer than simple missed > downloads. I see them in log. Hm, thank you for the verbose report. All the things you reported make me worry a lot. Yes, it sounds very much like 954904 all over again. For a while it did happen to me too, but it's a Heisenbug, I never managed to reliably catch it and after some refactoring it disappeared. I never trusted that outcome, thus 954904 is still open. If you don't mind, I would like to merge them. > So after fixing apt-cacher-ng data with attached script, running apt > again goes smoothly. Yes, but the question is for how long. I am preparing a bigger upstream release right now, where the logics of file storage are overhauled to a large extent. This might solve your issue along the way. Especially, there won't be truncation of payload anymore, therefore no risk of getting into such trouble by design. If you have a good environment to reproduce that issue, would you volunteer to test it in a couple of weeks? (or maybe even sooner, cannot tell yet) > As I read over BTS, I saw interesting one on approx BTS. Debian Bug > report logs - #884713 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884713 Under > systemd, socket activation is rate limited. > > This socket activation limit may be the root cause. What do you think? See /lib/systemd/system/apt-cacher-ng.service , socket activation is not used by default. Also it wouldn't explain sudden trancation in the cache. Best regards, Eduard. -- gibts fürs debian pakete erstellen nicht auch ne GUI lösung?
Bug#980923: acngtools eats all the CPU and doesn’t finish daily cron with merged pdiffs
Hallo, * Marcos Carot [Fri, Mar 26 2021, 12:48:11PM]: > Package: apt-cacher-ng > Version: 3.6.3-1 > Followup-For: Bug #980923 > X-Debbugs-Cc: marcos.ca...@gmail.com > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? The last two versions of apt-cacher-ng in > testing have shown this issue. No idea what triggers it The version you mentioned above is not in Testing. So what do you mean? You see this with the Testing version? Have you tried the actual version 3.6.3 then? And what issue? What exactly are you observing? Mind to share your log files from /var/log/apt-cacher-ng/ and the maint*.html files with me? (compress them all into a tarball or ZIP) >* What exactly did you do (or not do) that was effective (or > ineffective)? restart service temporarily fixes it So how does it behave? Before restarting, can you do a: strace -f -o /tmp/acngtool.log -p $(pidof acngtool) and then send that acngtool.log file to me? >* What was the outcome of this action? apt-cacher-ng not using 100% CPU This ticket is about acngtool eating CPU, not apt-cacher-ng. So what do you mean? If this is about apt-cacher-ng, please create another ticket. And also trace the actual program. Like: strace -f -o /tmp/apt-cacher-ng.log -p $(pidof apt-cacher-ng) Best regards, Eduard. -- Ruft sie aus der Küche: "Komm Nörgeln, das Essen ist fertig."
Bug#977611: Bug#982984: Mirror blocked due to repeated errors
reopen 982984 severity 982984 serious thanks Hallo, * Sven Geuer [Sun, Feb 28 2021, 10:20:03PM]: > Restarting apt-cacher-ng per > >systemctl restart apt-cacher-ng > > temporarily fixes the issue which shows up again after the next boot cycle. > > I also believe apt-cacher-ng should not rely on a nameserver > configuration detected during start-up as /etc/resolv.conf may change > any time, be it for manual re-configuration or for NetworkManager > updating resolv.conf dynamically. Yes. This can be solved by checking for updated resolv.conf at certain moments, for example when a new client connects. However getting the replacement resolver in place is non-trivial because of the shutdown situation. You can grab a copy from https://www.unix-ag.uni-kl.de/~bloch/acng/snap3.6.1/ if you wish, or build from git, or wait a couple of days because I just found an occurrence of #977611 which needs further investigation. Best regards, Eduard. -- jaja, irc lerne ich, wenn ich gross bin signature.asc Description: PGP signature
Bug#983394: apt-cacher-ng suddently stopped working
Hallo, * nicoo [Tue, Feb 23 2021, 02:16:25PM]: > Fetched 53,0 kB in 1s (67,0 kB/s) > Reading package lists... Done > Building dependency tree... Done > 1 package can be upgraded. Run 'apt list --upgradable' to see it. > W: Failed to fetch > http://localhost:3142/debian/dists/bullseye/InRelease 502 Mirror blocked > due to repeated errors [IP: 127.0.0.1 3142] > W: Failed to fetch > http://localhost:3142/debian/dists/experimental/InRelease 502 Mirror > blocked due to repeated errors [IP: 127.0.0.1 3142] > W: Failed to fetch http://localhost:3142/debian/dists/sid/InRelease > 502 Mirror blocked due to repeated errors [IP: 127.0.0.1 3142] > W: Some index files failed to download. They have been ignored, or old > ones used instead. > > This is what happens in syslog at the same time: > > systemd[1]: Started Apt-Cacher NG software download proxy. > apt-cacher-ng[1540]: [warn] Call to getaddrinfo_async with no > evdns_base configured. > apt-cacher-ng[1540]: [warn] Call to getaddrinfo_async with no > evdns_base configured. > apt-cacher-ng[1540]: [warn] Call to getaddrinfo_async with no > evdns_base configured. See #982984 and the fixed version suggested there. Or just test https://www.unix-ag.uni-kl.de/~bloch/acng/snap3.6.1/ and please report whether it solves your issue. Thanks, Eduard.
Bug#982984: Mirror blocked due to repeated errors
Hallo,
* Eduard Bloch [Sun, Feb 21 2021, 10:59:14AM]:
> > same issue here since upgrade to apt-cacher-ng 3.6-1. Packages apparmor-
> > profiles or apparmor-profiles-extra are not installed.
>
> Ok, so I think we have some kind of strange libevent bug here. Could
> someone please run:
>
> strace -s 4000 -o log.strace -f /usr/lib/apt-cacher-ng/acngtool curl
> http://www.debian.org
Okay guys, thank you very much for the contributed traces and other
remarks, this helped to track down about two and half real or potential
bugs.
I hope I have identified all root causes for the problems in Russel's
original report, some were specific to evdns (best reproduced in
Michael's setup) which are IMHO bugs in libevent (worth another
bug report there when I have more evidence) and some could be attributed
to a file descriptor introduced in version 3.6 and some are caused by
incorrect (and actually obsolete) algorithms on cache item handling.
I might also have found a reason for hanging acngtool cronjobs along the
way (another bug report). Check
https://salsa.debian.org/blade/apt-cacher-ng/-/commits/upstream/sid if
you want to see the longer story.
If you don't mind, I would kindly ask you to test a snapshot of that,
built locally from debian/sid branch ("fakeroot debian/rules binary") or
check the snapshot builds for amd64 at
https://www.unix-ag.uni-kl.de/~bloch/acng/snap3.6.1/ . If this is still
failing, it would be good to have a similar strace log but attaching to
the daemon process, like:
strace -s 4000 -o log.strace -f -p $(pidof apt-cacher-ng)
and then rerunning the failing operation. It might also make sense to
make another run after taking a break on client activity for 30s or more
in order to trigger the specific behavior leading to this bug.
It would be good to receive some feedback by Wednesday, then I am
planing to approach the release team (expecting the "usual" messy
discussion).
Best regards,
Eduard.
Bug#982984: Mirror blocked due to repeated errors
Hallo, * Sven Geuer [Sat, Feb 20 2021, 11:43:19PM]: > Package: apt-cacher-ng > Version: 3.6-1 > Followup-For: Bug #982984 > > same issue here since upgrade to apt-cacher-ng 3.6-1. Packages apparmor- > profiles or apparmor-profiles-extra are not installed. Ok, so I think we have some kind of strange libevent bug here. Could someone please run: strace -s 4000 -o log.strace -f /usr/lib/apt-cacher-ng/acngtool curl http://www.debian.org And send me that log.strace file in private. Maybe also your resolv.conf file, thanks. Best regards, Eduard.
Bug#982984: Mirror blocked due to repeated errors
Hallo, * Michael Tokarev [Sun, Feb 21 2021, 12:16:06AM]: > Getting these errors here too, restart of apt-cacher-ng > does NOT help in my case (so I'm basically unable to use apt > anymore, will have to drop usage of the cacher). > > The log contains this message for every access to the cache: > > apt-cacher-ng[xxx]: [warn] Call to getaddrinfo_async with no evdns_base > configured. I tried to reproduce it but couldn't so far. I admit that there is no error handling for the failing creation of evdns_base, though. And I have a strange feeling that it might be connected to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983006 . Do you all have apparmor-profiles-extra installed? Best regards, Eduard.
Bug#884881: Bug#944114: Missing directory spec in Remap secdeb rule
Hallo,
* john doe [Mon, Nov 04 2019, 03:47:00PM]:
> Package: apt-cacher-ng
> Version: 3.2-2
>
> Upon installation of AC-NG, the remap rule ('secdeb') for debian
> security is missing the directory spec ('/debian-security'):
>
> Rong remap rule without directory spec:
>
> Remap-secdeb: security.debian.org ; security.debian.org
> deb.debian.org/debian-security
>
> Working remap rule with directory spec:
>
> Remap-secdeb: security.debian.org /debian-security ; security.debian.org
> deb.debian.org/debian-security
Ok, so I think the default configuration has been PITA for some people
for the last couple of years and I am sorry. I intend to modify the
default mapping as shown below, or see:
https://salsa.debian.org/blade/apt-cacher-ng/-/commit/3090d97ed9794a64f509917c77f0bb7ebccf1fbf
Is this something we can agree on? I am not so sure about using
deb.debian.org as default backend.
index 9dbf87c..940feab 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -4,6 +4,9 @@ apt-cacher-ng (3.6.1) HAPPENS-TO-THE-BEAST-OF-US; urgency=low
* Avoid potential file descriptor leak in download item collision handling
* Extended mirror scan to guess {ftp2, ftp3}.XY.debian.org address aliases
(Debian bug #951005)
+ * Extended security.debian.org rewriting to also include deb.debian.org
+requests and change default mirror for them all to deb.debian.org (Debian
+bugs #932093, previously #884881)
--
diff --git a/conf/acng.conf.in b/conf/acng.conf.in
index 2f269ae..4147809 100644
--- a/conf/acng.conf.in
+++ b/conf/acng.conf.in
@@ -77,7 +77,7 @@ Remap-fedora: file:fedora_mirrors # Fedora Linux
Remap-epel: file:epel_mirrors # Fedora EPEL
Remap-slrep: file:sl_mirrors # Scientific Linux
Remap-gentoo: file:gentoo_mirrors.gz /gentoo ; file:backends_gentoo # Gentoo
Archives
-Remap-secdeb: security.debian.org ; security.debian.org
deb.debian.org/debian-security
+Remap-secdeb: security.debian.org security.debian.org/debian-security
deb.debian.org/debian-security /debian-security ;
deb.debian.org/debian-security security.debian.org
# Virtual page accessible in a web browser to see statistics and status
# information, i.e. under http://localhost:3142/acng-report.html
Best Regards,
Eduard.
--
Atheismus ist keine Philosophie, er ist noch nicht ein mal eine
Weltsicht. Er ist schlichtweg die Weigerung, ohne Grund das Gegenteil
des Offensichtlichen zu glauben.
Bug#978768: apt-cacher-ng: ftbfs with autoconf 2.70
Control: reassign 978768 binutils-x86-64-linux-gnu Control: retitle 978768 gold linker crashing with -Wl,--threads On Thu, 31 Dec 2020 14:26:39 + Matthias Klose wrote: > [ 94%] Linking CXX executable ../apt-cacher-ng > cd /<>/obj-x86_64-linux-gnu/source && /usr/bin/cmake -E > cmake_link_script CMakeFiles/apt-cacher-ng.dir/link.txt --verbose=1 > /usr/bin/c++ -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now > -Wl,-fuse-ld=gold -Wl,--threads -Wl,--as-needed -Wl,-O1 -Wl,--discard-all > -Wl,--no-undefined -Wl,--build-id=sha1 -Wl,--gc-sections > CMakeFiles/apt-cacher-ng.dir/apt-cacher.cc.o -o ../apt-cacher-ng > -Wl,-rpath,/<>/obj-x86_64-linux-gnu: ../libsupacng.so -latomic > -levent -levent_pthreads -levent -lwrap -lz -lbz2 -llzma -lssl -lcrypto > -lsystemd -lpthread -levent_pthreads -lwrap -lz -lbz2 -llzma -lssl -lcrypto > -lsystemd -lpthread > double free or corruption (out) > collect2: fatal error: ld terminated with signal 6 [Aborted] No, it's not about autoconf. It's gold linker crashing when -Wl,--threads is used. The latest version work around this by not adding it but you can easily reproduce the crash by putting it into CXXFLAGS and LDFLAGS. Interestingly it has never happened to me on PCs, maybe the number of cores is the way to trigger it. Best regards, Eduard.
Bug#973883: [apt-cacher-ng] bad exit code (=0) instead (<>0) if Check permissions of /var/log/apt-cacher-ng
Control: severity 973883 normal Hallo, * Jean-Marc LACROIX [Fri, Nov 06 2020, 03:46:53PM]: > Package: apt-cacher-ng > Version: 3.2.1-1 > Severity: grave > > Dear maintainers, > > It seems there is one bad exit code issue (=0) when trying to start démon if > internal check is bad. (/etc/init.d/apt-cacher-ng start) Yes. > ansible@srv-apt-cache-400:~$ sudo /etc/init.d/apt-cacher-ng start > [] Starting apt-cacher-ng: apt-cacher-ngProblem creating log files. > Check permissions of the log directory, //var/log/apt-cacher-ng > failed! > ansible@srv-apt-cache-400:~$ echo $? > 0 > ansible@srv-apt-cache-400:~$ > > And, of course, this is true, because ... Yes. > ansible@srv-apt-cache-400:~$ sudo ls -altr /var/log/apt-cacher-ng > total 2 > drwx-- 2 root root 1024 Nov 6 14:34 . > drwxr-xr-x 8 root root 1024 Nov 6 14:52 .. So you have not installed it properly. Because you have some custom way of adding the filesystem components. This does not justify the grave severity. > Thanks in advance to correct this issue. In my use case, because i am using > Ansible to make deployment, it is then not possible to detect this bug > (because exit code = 0) in one automatic way So am I not sure what exactly you want to see fixed. Shall it start and go to degraded mode in this situation, rejecting all operations? Shall it start but run all downloads in pass-through mode (therefore hiding the problem, actually). Best regards, Eduard.
Bug#980923: acngtools eats all the CPU and doesn’t finish daily cron with merged pdiffs
notfound 980923 3.6-1 thanks Hallo, * Eduard Bloch [Sun, Jan 31 2021, 11:30:07PM]: > > > Interesting. Please throw gcore at it and send me a copy of that dump > > > > Uploaded at <https://people.debian.org/~taffit/acng/core.669583>, thanks > > for looking into it. > > Ok, thank you. I think I can reproduce the issue with a local sample > now. This also might be the cause of another bugreport I got recently. > > Stay tuned, I will send you a test binary for fix verification soon. At least that issue should be solved in 3.6 now. Best regards, Eduard.
Bug#948346: [PATCH] Ensure graceful signal handling when the pid file exists
Control: tags 948346 +patch Hallo, * Chris Hofstaedtler [Mon, Feb 08 2021, 01:43:52AM]: > * Eduard Bloch [210208 00:43]: > > > Could you make an upload to DELAYED instead of further waiting? > > > > I am no longer waiting, today is timeout day. Will use 7-DAY DELAYED > > queue, should be appropriate. > > That upload somehow did not make it into the archive? Not yet. If you need a patch, please grab the repo from https://salsa.debian.org/xorg-team/app/xdm/-/merge_requests/2 and/or contribute to the MR review. @Julien: okay to add myself as Uploader and upload? And/or do you actually insist on the changes mentioned in the MR? Best regards, Eduard. -- error compiling committee.c: too many arguments to function
Bug#980923: acngtools eats all the CPU and doesn’t finish daily cron with merged pdiffs
Control: severity 980923 serious Hallo, * David Prévot [Tue, Jan 26 2021, 06:12:58AM]: > Hi Eduard, > > Le Mon, Jan 25, 2021 at 07:46:45PM +0100, Eduard Bloch a écrit : > > Hallo, > > * David Prévot [Sun, Jan 24 2021, 08:31:34AM]: > > > Package: apt-cacher-ng > > > Version: 3.5-3 > […] > > > Since (a few days after) merged pdiff were enabled on Sid and Bullseye, > > > apt-cacher-ng seems unable to finish its daily cron job (I have to > > > restart it to be able to use my machine again). acngtools seems to use > > > all the CPU according to top(1). > > > > Interesting. Please throw gcore at it and send me a copy of that dump > > Uploaded at <https://people.debian.org/~taffit/acng/core.669583>, thanks > for looking into it. Ok, thank you. I think I can reproduce the issue with a local sample now. This also might be the cause of another bugreport I got recently. Stay tuned, I will send you a test binary for fix verification soon. Best regards, Eduard. -- Atheismus ist keine Philosophie, er ist noch nicht ein mal eine Weltsicht. Er ist schlichtweg die Weigerung, ohne Grund das Gegenteil des Offensichtlichen zu glauben. signature.asc Description: PGP signature
Bug#980923: acngtools eats all the CPU and doesn’t finish daily cron with merged pdiffs
Hallo, * David Prévot [Sun, Jan 24 2021, 08:31:34AM]: > Package: apt-cacher-ng > Version: 3.5-3 > Severity: important > X-Debbugs-Cc: stu...@debian.org, nthyk...@debian.org > > Hi, > > Since (a few days after) merged pdiff were enabled on Sid and Bullseye, > apt-cacher-ng seems unable to finish its daily cron job (I have to > restart it to be able to use my machine again). acngtools seems to use > all the CPU according to top(1). Interesting. Please throw gcore at it and send me a copy of that dump, or maybe a decoded stacktrace for the beginning. Best regards, Eduard.
Bug#948346: [PATCH] Ensure graceful signal handling when the pid file exists
Hallo, * Adrian Bunk [Mon, Jan 25 2021, 07:15:35AM]: > On Sun, Jan 10, 2021 at 12:10:16PM +0100, Eduard Bloch wrote: > >... > > I am setting this to RC severity because it's just NOT ok and obvious to > > fix. Going to change mentioned things and NMU this in a couple of weeks > > if there is no further reaction from maintainers. > > Could you make an upload to DELAYED instead of further waiting? I am no longer waiting, today is timeout day. Will use 7-DAY DELAYED queue, should be appropriate. Best regards, Eduard.
Bug#980837: icewm-common: Icewm crashes and/or doesn't start when Infadel2 theme is selected as default.
Control: 980837 tags +upstream Hallo, * Bartek [Fri, Jan 22 2021, 11:27:03PM]: > IceWM does not start neither through any used display manager, ie.: LightDM, > SDDM nor using startx command. > A default theme was set to Infadel2 in $HOME/.icewm/theme. I tested it with > each of it available options: default, Ergonomic and Overloaded. After > changing the theme in the mentioned file to any other in menu IceWM runs. > > Question: can the bug be related to: > icewm (2.0.0-2) unstable; urgency=low > * Disable direct loaders except for Imlib2 and librsvg > * Dropped libgdx-pixbuf-2.0 dependency (its xlib support is deprecated) > > I rather use this theme as I find the best of available in the package. Yes, it looks that way, thanks for reporting! To be continued at https://github.com/bbidulock/icewm/issues/541 . Best regards, Eduard.
Bug#979562: lightdm session termination does not stop xscreensaver
Hallo, * Jamie Zawinski [Mon, Jan 11 2021, 01:13:10PM]: > > my .icewm/startup file at the moment contains: > > > > xscreensaver -nosplash -log wtf-xscreensaver.txt & > > > > When icewm starts, I see the splash screen for a brief moment (not joking, > > looks -nosplash has no effect there), but it does not happen every time. > > This kinda sounds like *something else* is launching xscreensaver at the same > time, and whatever that is is doing it without -nosplash. The two of them > racing would explain the "already running" error. I think they are both originating from xscreensaver.service ExecStart's command line. > > Or, if run ps quick enough before it's killed, I see: > > > > user 3904 0.0 0.0 5712 1128 ?SN 21:13 0:00 > > xscreensaver-systemd -verbose > > lightdm11997 0.1 0.0 18948 5952 ?Ss 21:55 0:00 > > xscreensaver > > lightdm12068 0.0 0.0 5712 1128 ?SN 21:55 0:00 > > xscreensaver-systemd > > user 12416 0.0 0.0 3748 664 pts/0S+ 21:56 0:00 grep > > saver > > Note that pid 11997 does not have -nosplash on its command line. That also matches the command in the service file, including the ownership of the process. Best regards, Eduard.
Bug#979562: lightdm session termination does not stop xscreensaver
Hallo, * Michael Biebl [Sun, Jan 10 2021, 08:24:12PM]: > Am 10.01.21 um 20:02 schrieb Jamie Zawinski: > > > Why would a xscreensaver instance running for user A have any influence > > > on a xscreensaver instance running for user B? That seems absolutely > > > weird to me and something I don't understand. > > > > Yeah, that sounds impossible, assuming that the X server has restarted > > between user A and user B. > > > > If things have gone wrong in a weird way, the "xscreensaver-systemd" > > process of user A might linger, but it won't be able to communicate with > > user B's xscreensaver. > > Since Eduard has been claiming this originally: > > > - having this xscreensaver hanging around disturbs the startup of > >another xscreensaver process in the new user session > > I guess he needs to back this up somehow. > Unfortunately I haven't seen any log files or anything, which would give us > the opportunity to retrace what's happening. Not sure which kind of backup you expect. How can I generate more useful logfiles? IMHO I asked before for some kind of tracing functionality to become able to get that information, i.e. to see how systemd is ticking, to see what is happening or how the the delayed SIGTERM is triggered. Those are basically the symptoms I see: my .icewm/startup file at the moment contains: xscreensaver -nosplash -log wtf-xscreensaver.txt & When icewm starts, I see the splash screen for a brief moment (not joking, looks -nosplash has no effect there), but it does not happen every time. And in wtf-xscreensaver.txt I find: xscreensaver: 21:50:06: already running on display :0 (window 0x45) from process 9797 (lightdm@whitestar). Second attempt (and a different PID): When I run "xscreensaver-command -lock" (through ctrl-alt-del dialog of icewm) then the screen gets locked, and pushing a key shows me the credentials prompt for the user called "lightdm". Or, if run ps quick enough before it's killed, I see: user 3904 0.0 0.0 5712 1128 ?SN 21:13 0:00 xscreensaver-systemd -verbose lightdm11997 0.1 0.0 18948 5952 ?Ss 21:55 0:00 xscreensaver lightdm12068 0.0 0.0 5712 1128 ?SN 21:55 0:00 xscreensaver-systemd user 12416 0.0 0.0 3748 664 pts/0S+ 21:56 0:00 grep saver (one of those "xscreensaver-systemd" belongs to an earlier session, this is another complaint of mine in #978589 but it's claimed not to cause the main issue). Best regards, Eduard.
Bug#948346: [PATCH] Ensure graceful signal handling when the pid file exists
Control: severity 948346 serious On Tue, 04 Aug 2020 11:49:17 +0300 =?UTF-8?B?QWxleGFuZGVyIEtsaW1vdg==?= wrote: > > The attached seems to work on buster. Thanks for the patch, also thanks to Bernhard for investigation. The patch could be used but it just working around symptoms. I see multiple bugs involved here. a) logrotate job using a plain kill. This is racy, even with SysV init. We can do it better (systemctl kill function). b) service file not cleaning up the pid file. That file should be gone even when service terminates. c) xdm refusing to start when the pid file exists, although the process is no longer running. It could check whether it's still active, and/or maybe just kill it and evaluate the errno. I am setting this to RC severity because it's just NOT ok and obvious to fix. Going to change mentioned things and NMU this in a couple of weeks if there is no further reaction from maintainers. Best regards, Eduard. -- Atheismus ist keine Philosophie, er ist noch nicht ein mal eine Weltsicht. Er ist schlichtweg die Weigerung, ohne Grund das Gegenteil des Offensichtlichen zu glauben.
Bug#809877: xdg-utils: fix for #801048 breaks xdg-open if whitespaces in the filename on Debian/Cinnamon
On Mon, 04 Jan 2016 13:15:49 -0600 tyler wrote:
> Package: xdg-utils
> Version: 1.1.1-1
> Severity: grave
> Justification: renders package unusable
>
> To reproduce, install Cinnamon on Debian 8.2, then pull 1.1.1-1 from Stretch.
> You should find that xdg-open will no longer correctly parse file paths with
> spaces in them. This is probably due to the fix for #801048 which dealt with
> some whitespace stuff, since whitespaces worked just fine in 1.1.0.
I also ran into trouble with the whitespace stuff. This time in the
application entry (vendor).
The code is just buggy, sometimes doublequotes are used, sometimes not.
I think the attached patch should fix at least my problem. Could you
give it a try and see how it works for you?
The other file is prepatched xdg-mime from version 1.1.3 (don't use it
with older package version like above!).
Best regards,
Eduard.
diff --git a/scripts/xdg-utils-common.in b/scripts/xdg-utils-common.in
index d8277e7..e84a3c4 100644
--- a/scripts/xdg-utils-common.in
+++ b/scripts/xdg-utils-common.in
@@ -62,17 +62,17 @@ desktop_file_to_binary()
if [ "${desktop#*-}" != "$desktop" ]; then
vendor=${desktop%-*}
app=${desktop#*-}
-if [ -r $dir/applications/$vendor/$app ]; then
-file_path=$dir/applications/$vendor/$app
-elif [ -r $dir/applnk/$vendor/$app ]; then
-file_path=$dir/applnk/$vendor/$app
+if [ -r "$dir/applications/$vendor/$app" ]; then
+file_path="$dir/applications/$vendor/$app"
+elif [ -r "$dir/applnk/$vendor/$app" ]; then
+file_path="$dir/applnk/$vendor/$app"
fi
fi
if test -z "$file_path" ; then
for indir in "$dir"/applications/ "$dir"/applications/*/ "$dir"/applnk/ "$dir"/applnk/*/; do
file="$indir/$desktop"
if [ -r "$file" ]; then
-file_path=$file
+file_path="$file"
break
fi
done
#!/bin/sh
#-
# xdg-mime
#
# Utility script to manipulate MIME related information
# on XDG compliant systems.
#
# Refer to the usage() function below for usage.
#
# Copyright 2009-2010, Fathi Boudra
# Copyright 2009-2010, Rex Dieter
# Copyright 2006, Kevin Krammer
# Copyright 2006, Jeremy White
#
# LICENSE:
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included
# in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
# OTHER DEALINGS IN THE SOFTWARE.
#
#-
manualpage()
{
cat << _MANUALPAGE
Name
xdg-mime - command line tool for querying information about file type handling
and adding descriptions for new file types
Synopsis
xdg-mime query { filetype | default } ...
xdg-mime default application mimetype(s)
xdg-mime install [--mode mode] [--novendor] mimetypes-file
xdg-mime uninstall [--mode mode] mimetypes-file
xdg-mime { --help | --manual | --version }
Description
The xdg-mime program can be used to query information about file types and to
add descriptions for new file types.
Commands
query
Returns information related to file types.
The query option is for use inside a desktop session only. It is not
recommended to use xdg-mime query as root.
The following queries are supported:
query filetype FILE: Returns the file type of FILE in the form of a MIME
type.
query default mimetype: Returns the default application that the desktop
environment uses for opening files of type mimetype. The default
application is identified by its *.desktop file.
default
Ask the desktop environment to make application the default application for
opening files of type mimetype. An application can be made the default for
several file types by specifying multiple mimetypes.
application is the desktop file id of the application and has the form
vendor-name.desktop. application must already be installed
Bug#979562: lightdm session termination does not stop xscreensaver
Hallo, I don't fully agree. If you don't see a problem here, WHERE do you see it? Under my naive assumptions, it looks like SIGTERM is not sent when lightdm stops the service. So apparently a systemd issue. I would like to investigate more but a there seems to be no "debug" or "trace" mode for such kind of issues in systemd. Mind to share your knowledge? * Michael Biebl [Fri, Jan 08 2021, 01:34:43PM]: > Control: reassign -1 xscreensaver > > I don't see a systemd problem here, so re-assigning to xscreensaver. > > Am 08.01.21 um 13:04 schrieb Eduard Bloch: > > Package: systemd > > Version: 247.2-4 > > Severity: serious > > > > Hi, > > > > I am reporting this with high severity because it might affect system > > security. > > > > For details of this issue, see 978589. There are different symptoms to > > see but the originating cause is apparently the same: > > > > - xscreensaver user service is enabled as documented in its README > > - lightdm starts the service in its internal user session (owned by > > "lightdm" user) > > - lightdm stops its session when the login happens. However, > > xscreensaver process is NOT terminated for unknown reason. > > - having this xscreensaver hanging around disturbs the startup of > > another xscreensaver process in the new user session > > - after ~15s the old xscreensaver process (from lightdm) is finally > > dead, apparently a SIGTERM is emited only then! > > > > Visible symptoms: > > > > In the meantime, someone might lock the system (by xscreensaver-command) > > and go away, assuming that xscreensaver is locked. And then it suddenly > > dies. > > > > Same things happens if xscreensaver is invoked from .xsession or similar > > contents instead of user service. > > > > Best regards, > > Eduard. > > > > -- Package-specific info: > > > > -- System Information: > > Debian Release: bullseye/sid > >APT prefers unstable-debug > >APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), > > (1, 'experimental-debug'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 5.10.5+ (SMP w/12 CPU threads) > > Kernel taint flags: TAINT_OOT_MODULE > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE > > not set > > Shell: /bin/sh linked to /bin/bash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages systemd depends on: > > ii adduser 3.118 > > ii libacl1 2.2.53-9 > > ii libapparmor1 2.13.6-3 > > ii libaudit11:3.0-2 > > ii libblkid12.36.1-4 > > ii libc62.31-9 > > ii libcap2 1:2.44-1 > > ii libcrypt11:4.4.17-1 > > ii libcryptsetup12 2:2.3.4-1 > > ii libgcrypt20 1.8.7-2 > > ii libgnutls30 3.7.0-5 > > ii libgpg-error01.38-2 > > ii libip4tc21.8.6-1 > > ii libkmod2 28-1 > > ii liblz4-1 1.9.3-1 > > ii liblzma5 5.2.5-1.0 > > ii libmount12.36.1-4 > > ii libpam0g 1.4.0-2 > > ii libseccomp2 2.5.1-1 > > ii libselinux1 3.1-2+b2 > > ii libsystemd0 247.2-4 > > ii libzstd1 1.4.8+dfsg-1 > > ii mount2.36.1-4 > > ii systemd-timesyncd [time-daemon] 247.2-4 > > ii util-linux 2.36.1-4 > > > > Versions of packages systemd recommends: > > ii dbus 1.12.20-1 > > > > Versions of packages systemd suggests: > > ii policykit-10.105-29 > > pn systemd-container > > > > Versions of packages systemd is related to: > > pn dracut > > ih initramfs-tools 0.139 > > ii libnss-systemd 247.2-4 > > ii libpam-systemd 247.2-4 > > ii udev 247.2-4 > > > > -- no debconf information > > > > -- > > Chirurgen sind die einzigen Menschen, die ohne fremden Blinddarm und > > ohne fremde Mandeln nicht leben können. > > -- Peter Sellers > > > > Best regards, Eduard. signature.asc Description: PGP signature
Bug#978589: systemd based startup not working
Hallo, I have created a new bug report for the issue of xscreensaver not being properly terminated: http://bugs.debian.org/979562 The issue with xscreensaver-systemd persists. It seems like either when xscreensaver is killed by SIGTERM or it's aborted because another one is active, there is a process like this remaining in the background forever: xscreensaver-systemd -verbose Best regards, Eduard.
Bug#979463: crash when run for remote DISPLAY
Package: geeqie Version: 1:1.6-3 Severity: important Just what the description says. You start geeqie and the only parameter is a picture file (regular JPG). Result: application crashes (SIGSEGV). gdb (with symbols loaded) does not reveal much: (gdb) bt #0 0x7fc0596bec60 in () #1 0x7fc0680c72a2 in XGetErrorText () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #2 0x7fc068e89abf in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #3 0x7fc068e96f43 in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #4 0x7fc0680e936b in _XError () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #5 0x7fc0680e6197 in () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #6 0x7fc0680e6235 in () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #7 0x7fc0680e6b7a in _XEventsQueued () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #8 0x7fc0680e9a85 in _XGetRequest () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #9 0x7fc0680c4a8a in XCreateColormap () at /usr/lib/x86_64-linux-gnu/libX11.so.6 #10 0x7fc068268cef in () at /usr/lib/x86_64-linux-gnu/libcogl.so.20 #11 0x7fc06826a3b8 in () at /usr/lib/x86_64-linux-gnu/libcogl.so.20 #12 0x7fc06821c85b in cogl_display_setup () at /usr/lib/x86_64-linux-gnu/libcogl.so.20 #13 0x7fc06821bb29 in cogl_renderer_check_onscreen_template () at /usr/lib/x86_64-linux-gnu/libcogl.so.20 #14 0x7fc0682ec65a in () at /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0 #15 0x7fc068316fb2 in () at /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0 #16 0x7fc0683307c3 in () at /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0 #17 0x7fc06834158a in () at /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0 #18 0x7fc0683417f8 in () at /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0 #19 0x7fc068970177 in g_option_context_parse () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #20 0x7fc06834274b in clutter_init () at /usr/lib/x86_64-linux-gnu/libclutter-1.0.so.0 #21 0x56283bed0229 in main (argc=, argv=) at main.c:961 The only special thing about this setup is that the shell is connected via ssh and DISPLAY forwarding via -X parameter set. But various other applications, even GTK based like vim-gtk, work just fine. Best regards, Eduard. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.4+ (SMP w/12 CPU threads) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages geeqie depends on: ii geeqie-common1:1.6-3 ii libc62.31-6 ii libcairo21.16.0-4 ii libchamplain-0.12-0 0.12.20-1 ii libchamplain-gtk-0.12-0 0.12.20-1 ii libclutter-1.0-0 1.26.4+dfsg-2 ii libclutter-gtk-1.0-0 1.8.4-4 ii libcogl201.22.8-2 ii libdjvulibre21 3.5.28-1 ii libexiv2-27 0.27.3-3 ii libffmpegthumbnailer4v5 1:2.2.2-dmo1 ii libgcc-s110.2.1-3 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.4-1 ii libgtk-3-0 3.24.24-1 ii libheif1 1.10.0-1 ii libjpeg62-turbo 1:2.0.5-1.1 ii liblcms2-2 2.9-4+b1 ii liblirc-client0 0.10.1-6.2+b1 ii liblua5.1-0 5.1.5-8.1+b3 ii libopenjp2-7 2.3.1-1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpoppler-glib8 20.09.0-3 ii libstdc++6 10.2.1-3 ii libtiff5 4.2.0-1 ii libwebp6 0.6.1-2+b1 ii libx11-6 2:1.6.12-1 ii sensible-utils 0.0.12+nmu1 Versions of packages geeqie recommends: ii cups-bsd [lpr] 2.3.3op1-4 ii exiftran 2.10-4 ii exiv20.27.3-3 ii imagemagick 8:6.9.11.24+dfsg-1+b2 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.24+dfsg-1+b2 ii librsvg2-common 2.50.2+dfsg-1 ii ufraw-batch 0.22-4 ii zenity 3.32.0-6 Versions of packages geeqie suggests: pn geeqie-dbg ii gimp 2.10.22-2 ii libjpeg-progs 1:9d-1 ii ufraw 0.22-4 pn xpaint -- no debconf information -- Es ist auch so viel besser, daß man freundlich abrechnet, als daß man sich immer einander anähnlichen will, und wenn das nicht reüssiert, einander aus dem Wege geht. -- Johann Wolfgang von Goethe (an Charlotte v. Stein, Febr. 1789)
Bug#978589: systemd based startup not working
Hallo, * Eduard Bloch [Sat, Jan 02 2021, 11:52:50AM]: > Hallo, > * Jamie Zawinski [Wed, Dec 30 2020, 07:05:29PM]: > > > created. With absolute path, it is created but then it's created by > > > lightdm user first and then maybe the user session cannot replace it. > > > > Ok, that definitely means you're running as the wrong user, which explains > > why .Xauthority is not readable. Though why the earlier xscreensaver log > > said you were running as the correct user is confusing. Unless that log was > > from before this problem began. > > I don't have enough information to judge here. What I see is that the > xscreensvaer logo appears twice, i.e. when the lightdm screen comes and > when the xsession starts. When I check on the process list briefly in > those first seconds, there is: > > lightdm 4881 0.2 0.0 18924 5936 ?Ss 11:44 0:00 \_ > xscreensaver > lightdm 4959 0.0 0.0 5716 1064 ?SN 11:44 0:00 | \_ > xscreensaver-systemd > > So not running as user. And that process is terminated soon. And what > happened with the second appearence of the logo? This looks like an > aborted start of xscreensaver. > > Is this maybe lightdm failing to stop its instance in time so > xscreensaver cannot attach the the session and silently dies? > > Maybe should be a question to Debian maintainers of resp. stakeholders. > > > > Ok. Is this supposed to be gone when user logs out? Does this interfere > > > with my trying different parameters (-log, --log, etc.) above, are those > > > cached and therefore ignored after subsequent changes? So I switched to another DM, gdm3 instead of lightdm. And rebootet. gdm3 does not use xscreensaver, IIRC. Result: xscreensaver still not starting, nor is there a xscreensaver-systemd process. But there is: Debian-+7672 0.0 0.0 232856 6072 tty1 Sl+ 11:54 0:00 | \_ /usr/libexec/gsd-screensaver-proxy Which also terminates within the first minute. And like before, systemctl --user status xscreensaver.service only shows the logs which failed due to inaccessible DISPLAY and cookie problems. But that status also never changes. I can logout, and login again, there is no additonal attempt to start the user service. I can run systemctl --user restart xscreensaver.service manually and then it starts, and on logout it is reported as failed Active: failed (Result: exit-code) since Sat 2021-01-02 12:10:58 CET; 14s > Process: 6435 ExecStart=xscreensaver (code=exited, status=1/FAILURE) (obviously: xscreensaver[6435]: X connection to :0 broken) But it is NEVER RESTARTED. I think it should be answered by Debian maintainers and I don't know whom to ask: - how is the DISPLAY environment for systemd user session supposed to get there? - why are failed services not restarted when user logs out / logs in? For now, I will run in from .xsession again. systemd integration is just buggy. Best regards, Eduard.
Bug#978589: systemd based startup not working
Hallo, * Jamie Zawinski [Wed, Dec 30 2020, 07:05:29PM]: > > created. With absolute path, it is created but then it's created by > > lightdm user first and then maybe the user session cannot replace it. > > Ok, that definitely means you're running as the wrong user, which explains > why .Xauthority is not readable. Though why the earlier xscreensaver log said > you were running as the correct user is confusing. Unless that log was from > before this problem began. I don't have enough information to judge here. What I see is that the xscreensvaer logo appears twice, i.e. when the lightdm screen comes and when the xsession starts. When I check on the process list briefly in those first seconds, there is: lightdm 4881 0.2 0.0 18924 5936 ?Ss 11:44 0:00 \_ xscreensaver lightdm 4959 0.0 0.0 5716 1064 ?SN 11:44 0:00 | \_ xscreensaver-systemd So not running as user. And that process is terminated soon. And what happened with the second appearence of the logo? This looks like an aborted start of xscreensaver. Is this maybe lightdm failing to stop its instance in time so xscreensaver cannot attach the the session and silently dies? Maybe should be a question to Debian maintainers of resp. stakeholders. > > Ok. Is this supposed to be gone when user logs out? Does this interfere > > with my trying different parameters (-log, --log, etc.) above, are those > > cached and therefore ignored after subsequent changes? > > xscreensaver-systemd should be killed by xscreensaver when it exits, but it's > definitely not a part of the problem that you're experiencing right now. Right now I cannot reproduce it, but I am almost sure that I have seen it once. xscreensaver-systemd was haning around without associated xscreensaver process. > > ## > > xscreensaver: 19:08:25: logging to "/tmp/xscreensaver-log.txt" at Wed Dec > > 30 19:08:25 2020 > > ## > > No "running as" line in this log? I've pasted the whole file. Best regards, Eduard. -- alphascorpii: channel.d.d/fortunes.html Rhonda: Die Seite mag ich nicht, da bin ich so häufig drauf.
Bug#978589: systemd based startup not working
Hallo, * Jamie Zawinski [Tue, Dec 29 2020, 04:48:10PM]: > > Once logged in, I can see some active process of xscreensaver (this is what > > "pidof xscreensaver" tells me). > > > > But after some seconds, this process is gone. Why? Don't know. > > Dunno. Maybe it's trying to connect and timing out. Run xscreensaver with > --log log.txt I tried, but no such file gets created, even with absolute path. After RTFM and some time wasted I guess that it should be -log AND NOT --log. And then, when I use it with relative path, no such file is created. With absolute path, it is created but then it's created by lightdm user first and then maybe the user session cannot replace it. I could trick my way around it by removing the file manually, though. After some daemon-reload runs, I cannot even start it now whatsoever. Means: journalctl or "systemctl --user status xscreensaver.service" show me the last log lines from an hour ago (with the failed-to-open-DISPLAY issue). systemctl --user status | grep saver -> nothing However without --user: CGroup: / ├─user.slice │ └─user-500.slice │ ├─user@500.service │ │ ├─app.slice │ │ │ ├─pulseaudio.service │ │ │ │ └─12150 /usr/bin/pulseaudio --daemonize=no ... │ │ └─init.scope │ │ ├─2483 /lib/systemd/systemd --user │ │ └─2484 (sd-pam) │ ├─session-2.scope │ │ └─2748 xscreensaver-systemd ... The PID of xscreensaver-systemd does not fit, it's an old process, started an hour ago. /proc/2748 confirms it, this belong to the old lines in "systemctl --user status". But I did close and restart the X session severtal times now, why is that process not dead? > Or if you have an old version, -verbose -no-capture -log log.txt That said, I saw something odd, sometimes xscreensaver was started. That made me remember something, I think I had a similar problem on this same system some months ago and it did not work with systemd but I took a shortcut due to lag of time and so I have put it into the startup file of the window manager. And it seems like it had worked this way since then. So my previous statement was not fully correct. Nevertheless, the systemd way does not work even after I removed the custom startup call. > > 2884 0.0 0.0 5716 1064 ?SN 01:13 0:00 xscreensaver-systemd > > > > The manpage of this binary is slightly confusing. That is some kind of > > helper, fine, but who is supposed to run it? Xsession? Or systemd user > > session? It mentions "When run from ~/.xsession or equivalent" but there > > is no information on what is considered "equivalent" here. > > It is launched by xscreenasver itself. Ok. Is this supposed to be gone when user logs out? Does this interfere with my trying different parameters (-log, --log, etc.) above, are those cached and therefore ignored after subsequent changes? Anyway, I killed it now, logged out, logged in, the process is not coming back, and the picture looks like above (old status log in the "systemctl --user status" output). Also, xscreensaver process was running for some seconds and then disappeared. However, this time it created a log file. ## xscreensaver: 19:08:25: logging to "/tmp/xscreensaver-log.txt" at Wed Dec 30 19:08:25 2020 ## xscreensaver: 19:08:26: running on display ":0.0" xscreensaver: 19:08:26: vendor is The X.Org Foundation, 1201. xscreensaver: 19:08:26: useful extensions: xscreensaver: 19:08:26: MIT Screen-Saver (disabled at compile time) xscreensaver: 19:08:26: Shared Memory (1.2) xscreensaver: 19:08:26: Double-Buffering (1.0) xscreensaver: 19:08:26: Power Management (1.2) xscreensaver: 19:08:26: GLX xscreensaver: 19:08:26: XF86 Video-Mode (2.2) xscreensaver: 19:08:26: XC Misc (disabled at compile time) xscreensaver: 19:08:26: Xinerama (1.1) xscreensaver: 19:08:26: Resize-and-Rotate (1.5) xscreensaver: 19:08:26: XInput xscreensaver: 19:08:26: libsystemd xscreensaver: 19:08:26: screen 0 non-colormapped depths: 24. xscreensaver: 19:08:26: WARNING: RANDR and Xinerama report different xscreensaver: 19:08:26: screen layouts! Believing RANDR. xscreensaver: 19:08:26: screens in use: 1 xscreensaver: 19:08:26:3/0: 1920x1080+0+0 (HDMI-1) xscreensaver: 19:08:26: rejected screens: 4 xscreensaver: 19:08:26:0/0: 1920x1080+0+0 (DVI-D-1) -- output disabled xscreensaver: 19:08:26:1/0: 1920x1080+0+0 (DP-1) -- output disabled xscreensaver: 19:08:26:2/0: 1920x1080+0+0 (DP-2) -- output disabled xscreensaver: 19:08:26:4/0: 1920x1080+0+0 (HDMI-2) -- output disabled xscreensaver: 19:08:26: selecting RANDR events xscreensaver: 19:08:26: not using XInputExtension. xscreensaver: 19:08:26: consulting /proc/interrupts for keyboard activity. xscreensaver: 19:08:26: 0: visual 0x21
Bug#978589: systemd based startup not working
Hallo, * Jamie Zawinski [Mon, Dec 28 2020, 06:07:55PM]: > The fact that $DISPLAY is not set at the time xscreensaver is launched is not > a good sign. The cookie error suggests that ~/.Xauthority does not exist or > is not readable. However you do appear to be running as yourself, not as > "nobody". Perhaps $HOME is set to something weird? Maybe try setting your > command to "printenv ; pwd ; xdpyinfo ; xscreensaver" and see if that > provides some clues. > No, nothing special I am aware of. Symptoms are very strange. Once logged in, I can see some active process of xscreensaver (this is what "pidof xscreensaver" tells me). But after some seconds, this process is gone. Why? Don't know. And I see another process, what is this? 2884 0.0 0.0 5716 1064 ?SN 01:13 0:00 xscreensaver-systemd The manpage of this binary is slightly confusing. That is some kind of helper, fine, but who is supposed to run it? Xsession? Or systemd user session? It mentions "When run from ~/.xsession or equivalent" but there is no information on what is considered "equivalent" here. Anyway, I patched /usr/lib/systemd/user/xscreensaver.service to add your instructions: $ cat /usr/lib/systemd/user/xscreensaver.service [Unit] Description=XScreenSaver [Service] #ExecStart=xscreensaver ExecStart=/bin/sh -c "printenv ; pwd ; xdpyinfo ; xscreensaver" [Install] WantedBy=default.target I did daemon-reload (for --user). Net result: no visible change but the state is this now: $ systemctl --user status xscreensaver.service ● xscreensaver.service - XScreenSaver Loaded: loaded (/usr/lib/systemd/user/xscreensaver.service; enabled; vendor preset: enabled) Active: inactive (dead) Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing. Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Cannot add dependency job, ignoring: Unit xscreensaver.service has a bad unit file setting. Now this does not make any sense anymore. Best regards, Eduard.
Bug#978589: systemd based startup not working
Package: xscreensaver Version: 5.45+dfsg1-1 Severity: important Hi, just what the title says. I have configured xscreensaver start via systemd user session as suggested in README.Debian. Not working now but it has been a few weeks ago. I am wondering about the MAGIC COOKIE problem. My startup sequence is old school, lightdm -> Xsession and ~/.xsession contains a few commands and eventually "exec icewm-session". One noteworthy thing is also that for a few seconds after login I can see an active xscreensaver process in the process list and then it suddenly terminates. $ systemctl --user status xscreensaver.service â—? xscreensaver.service - XScreenSaver Loaded: loaded (/usr/lib/systemd/user/xscreensaver.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2020-12-29 00:30:47 CET; 7min ago Process: 2652 ExecStart=xscreensaver (code=exited, status=1/FAILURE) Main PID: 2652 (code=exited, status=1/FAILURE) CPU: 6ms Dez 29 00:30:47 whitestar xscreensaver[2652]: xscreensaver: 00:30:47: warning: $DISPLAY is not set: defaulting to ":0.0". Dez 29 00:30:47 whitestar xscreensaver[2652]: Invalid MIT-MAGIC-COOKIE-1 keyxscreensaver: 00:30:47: Can't open display: :0.0 Dez 29 00:30:47 whitestar xscreensaver[2652]: xscreensaver: 00:30:47: running as bloch/bloch (500/500) Dez 29 00:30:47 whitestar xscreensaver[2652]: xscreensaver: 00:30:47: Errors at startup are usually authorization problems. Dez 29 00:30:47 whitestar xscreensaver[2652]: But you're not logging in as root (good!) so something Dez 29 00:30:47 whitestar xscreensaver[2652]: else must be wrong. Did you read the manual and the FAQ? Dez 29 00:30:47 whitestar xscreensaver[2652]: https://www.jwz.org/xscreensaver/faq.html Dez 29 00:30:47 whitestar xscreensaver[2652]: https://www.jwz.org/xscreensaver/man.html Dez 29 00:30:47 whitestar systemd[2626]: xscreensaver.service: Main process exited, code=exited, status=1/FAILURE Dez 29 00:30:47 whitestar systemd[2626]: xscreensaver.service: Failed with result 'exit-code'. Best regards, Eduard. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.1+ (SMP w/12 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xscreensaver depends on: ii init-system-helpers 1.60 ii libatk1.0-0 2.36.0-2 ii libc62.31-6 ii libcrypt11:4.4.17-1 ii libglib2.0-0 2.66.4-1 ii libgtk2.0-0 2.24.32-5 ii libpam0g 1.4.0-1 ii libpango-1.0-0 1.46.2-3 ii libsystemd0 247.2-3 ii libx11-6 2:1.6.12-1 ii libxext6 2:1.3.3-1.1 ii libxi6 2:1.7.10-1 ii libxinerama1 2:1.1.4-2 ii libxml2 2.9.10+dfsg-6.3+b1 ii libxmu6 2:1.1.2-2+b3 ii libxrandr2 2:1.5.1-1 ii libxt6 1:1.2.0-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data5.45+dfsg1-1 Versions of packages xscreensaver recommends: pn libjpeg-turbo-progs ii perl 5.32.0-6 ii wamerican [wordlist] 2019.10.06-1 ii wngerman [wordlist] 20161207-8 ii xfonts-100dpi 1:1.0.4+nmu1 Versions of packages xscreensaver suggests: ii chromium [www-browser] 87.0.4280.88-0.3 ii elinks [www-browser] 0.13.2-1+b1 ii falkon [www-browser] 3.1.0+dfsg1-9 ii firefox [www-browser]84.0-3 ii fortune-mod [fortune]1:1.99.1-7.1 ii gdm3 3.38.2.1-1 ii lynx [www-browser] 2.9.0dev.6-1 pn qcam | streamer ii w3m [www-browser]0.5.3-38+b1 pn xdaliclock pn xfishtank pn xscreensaver-data-extra pn xscreensaver-gl pn xscreensaver-gl-extra -- no debconf information -- hm... kann man eigentlich auch von vorne poppen oder nur von hinten? -- Wo kann man eigentlich Verbesserungen für die Fortunes anbringen? cpt_nemo: Geschichtsfälscher!
Bug#976797: icewm: The "Terminal" menu does not work with terminal other than xterm
Control: severity 976797 important > I removed xterm because it is difficult to configure and now I cannot > start terminal with the top menu item in the icewm menu. > > The menuitem is hardcoded to "x-terminal-emulator -ls". While -l support > is common -s is specific to xterm. When x-terminal-emulator points to > something else the menu fails to start a terminal. > > Please consider dropping the -s. I agree. Those switches are basically Wild West across different terminal emulators, they all should be removed where possible in the caller's command line. Unfortunatelly I forgot to apply this change in the last upload, this should be changed in a couple of days, I want to get 2.0.x version into Testing first. Best regards, Eduard.
Bug#977611: apt-cacher-ng: Daily cron job frequently hangs
Hallo, * Daniel Schepler [Thu, Dec 17 2020, 11:31:15AM]: > Package: apt-cacher-ng > Version: 3.5-3 > Severity: important > > Running apt-cacher-ng to serve an sbuild container which gets used > heavily, I frequently get a hang in the daily cron job. The process > tree involved is: > > anacron -d -q -s > └─sh -c run-parts --report /etc/cron.daily > └─run-parts --report /etc/cron.daily > └─apt-cacher-ng /etc/cron.daily/apt-cacher-ng > └─acngtool maint -c /etc/apt-cacher-ng > SocketPath=/var/run/apt-cacher-ng/socket > > This then prevents the system from reaching other /etc/cron.daily entries. Oh crap. If it's still hanging at the time when you reach the console, please make some analysis, like: lsof > openfiles.txt gcore -o acng.dmp $(pidof apt-cacher-ng) and then compress them and send them directly to me. Latest contents of /var/log/apt-cacher-ng/... would also be interesting. Thanks, Eduard.
Bug#977363: assertion crash when adding a new alias
Package: neomutt
Version: 20201120+dfsg.1-1
Severity: important
Repro:
$ grep alias .muttrc
set alias_file=~/.mail_aliases # where I keep my aliases
source ~/.mail_aliases
set reverse_alias # attempt to look up my names for people
Open neomutt, navigate to some gmail address.
Press a, confirm the parts of the alias.
Confirm with Y.
Result:
neomutt crashes on some assertion, before asking for the target path
confirmation. See below.
Vanilla mutt does not crash.
Related stack:
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht
gefunden.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7faa195d5537 in __GI_abort () at abort.c:79
#2 0x7faa195d540f in __assert_fail_base
(fmt=0x7faa183753ad "%s%s%s:%u: %s%sZusicherung »%s« nicht erfüllt.\n%n",
assertion=0x5650afbecbeb "DTYPE(he->type) == DT_STRING", file=0x5650afbecac0
"../config/helpers.c", line=248, function=) at assert.c:92
#3 0x7faa195e4602 in __GI___assert_fail
(assertion=assertion@entry=0x5650afbecbeb "DTYPE(he->type) == DT_STRING",
file=file@entry=0x5650afbecac0 "../config/helpers.c", line=line@entry=248,
function=function@entry=0x5650afbecc10 <__PRETTY_FUNCTION__.0>
"cs_subset_string")
at assert.c:101
#4 0x5650afba7536 in cs_subset_string (sub=sub@entry=0x5650b0b10420,
name=name@entry=0x5650afbcbfb9 "alias_file") at ../config/helpers.c:248
#5 0x5650afb8c00f in alias_create (al=, sub=0x5650b0b10420)
at ../alias/alias.c:485
#6 0x5650afb10570 in mutt_pager (banner=banner@entry=0x0, fname=, flags=flags@entry=66, extra=extra@entry=0x7ffd72dfbf00) at ../pager.c:3020
#7 0x5650afad0def in mutt_display_message
(win_index=win_index@entry=0x5650b1c18bb0,
win_ibar=win_ibar@entry=0x5650b1c18c50,
win_pager=win_pager@entry=0x5650b25a38b0,
win_pbar=win_pbar@entry=0x5650b25a3950, m=, e=0x5650b1058f00) at
../commands.c:377
#8 0x5650afaeb7f8 in mutt_index_menu (dlg=0x5650b1c18a70) at
../index.c:2579
#9 0x5650afacb14a in main (argc=1, argv=0x7ffd72dff1c8, envp=) at ../main.c:1236
Best regards,
Eduard.
-- Package-specific info:
NeoMutt 20201120
Copyright (C) 1996-2020 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.
System: Linux 5.9.0-4-amd64 (x86_64)
ncurses: ncurses 6.2.20201114 (compiled with 6.2.20201114)
libidn: 1.33 (compiled with 1.33)
GPGME: 1.14.0-unknown
GnuTLS: 3.6.15
libnotmuch: 5.3.0
storage: tokyocabinet
Configure options: --build=x86_64-linux-gnu --prefix=/usr
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man}
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
{--libdir=${prefix}/lib/x86_64-linux-gnu}
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss
--idn --mixmaster --sasl --tokyocabinet --sqlite --autocrypt
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/neomutt-Ulxxh7/neomutt-20201120+dfsg.1=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include
-I/usr/include/lua5.4 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
+autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens
+getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify
-locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +regex +sasl
+smime +sqlite +start_color +sun_attachment +typeahead
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"
To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to:
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE,
Bug#974724: no useful documentation of pdfjam commands
Hallo, * Norbert Preining [Thu, Nov 26 2020, 01:41:15PM]: > On Sat, 14 Nov 2020, Eduard Bloch wrote: > > First, in former times it was easy to find pdfjam because the package > > Yes, but now it is part of the TeX Live group and we cannot include the > long description of every single included TeX package in the long > description of the Debian package, it would fill a book. And who decided to put dozens of separate tools into monster packages? And adding a few more keywords to descriptions makes it suddenly "a book" now? > > Second, the documentation is useless. The manpage refers to ONLINE > > documentation. IMHO this should be part of a package and NOT require a > > user to establish internet connection. There is no offline version of > > that README.md as far as I can see. > > Using > texdoc pdfjam Interesting. Let's take a tour, demonstrating the ways of documentation retrieval from users perspective. Pre-Condition: As a regular user, I want to use a simple tool to merge (join, concatenate, append...) a couple of existing PDF files. I don't want to learn Latex language, my PDFs dont have much to do with Latex. > gives you the README file of pdfjam with additional documentation, and First, what is texdoc anyway? $ man pdfjam | grep texdoc -> nothing A regular user has no idea about this command. Why should we even care? We install a tool for basic documentation postprocessing, not creating new stuff with Tex. Even if the user knows learned this somehow by accident, your command opens a browser, which wants me to open the MD file in a special editor which is totally inappropriate. I guess you call sensible-browser there? If so, why do you that for non-HTML contents? This does not make sense. Why not use sensible-pager? Or "see"? Let's assume that $USER figured out that RTFM of "pdfpages" is needed, where to get it? Maintainer says: > texdoc pdfpages > gives you the documentation of the additional key/value pairs accepted. No, it doesn't. $ texdoc pdfpages Sorry, no documentation found for "pdfpages". If you are unsure about the name, try full-text searching on CTAN. Search form: <https://www.ctan.org/search/> $ apt search pdfpages Sortierung... Fertig Volltextsuche... Fertig texlive-extra-utils/unstable,unstable,unstable,unstable,unstable,unstable,now 2020.20200925-1 all [installiert] TeX Live: TeX auxiliary programs texlive-latex-recommended/unstable,unstable,unstable,unstable,unstable,unstable,now 2020.20200925-1 all [Installiert,automatisch] TeX Live: LaTeX recommended packages And now, where is supposed to come from? (Remember, user perspective!) Search it online? Like https://duckduckgo.com/?t=ffsb=man+pdfpages ? Nice try, I remember "Passierschein A38" resp. "Catch 22". Okay, with some luck (and knowledge how to use apt-file) one can find: texlive-latex-recommended-doc: /usr/share/doc/texlive-doc/latex/pdfpages/pdfpages.pdf So even after all that guessing one has to install FIFTY megabytes of docs to learn about a couple of command line options of a simple tool which does not even have obvious relationship to Latex in the first place? SERIOUSLY? And then even when going the hard way with pdfpages docs, it's not perfectly clear how exactly to convert those documentation into pdfnup command line options. And by the way, if this is the way to go (which I doubt) then that way should be documented in /usr/share/doc/texlive-extra-utils/README.Debian somehow. Is it? Hardly, IMHO. And what do find there instead? -- snip -- please see the document TeX-on-Debian in the tex-common package, which can be found in /usr/share/doc/tex-common/ in the pdf, txt, and html format. -- snap -- $ ls /usr/share/doc/tex-common/ NEWS.Debian.gz changelog.gz copyright Great, another wrong instruction. > Do you expect that pdfjam duplicates the complete documentation of > pdfpages? Why should I expect that? I didn't ever care about what it uses underneath. I expect it, like any other tool, to document ITS OWN BASIC operations properly. If that's is too complicated to be stored in a manpage then please in a easily identifiable README somewhere aside AND linked from the manpage. > > Even the --help output is not helping. It tells a few things about > > options but it does NOT mention what the actual operations are. > > It says that it is any of the many keys of pdfpages, so you need to read > the documentation of pdfpages, which incidentally can be found with the > above command. Why? $USER installs a basic tool and wants to - use it for basic operations (like, merging two PDFs) and - have a simple doc about - those basic commands - which is avaible offline and - is easy to find. Or do you expect a car buyer to read the complete maintenance manual before starting the engine? > So I real
Bug#975137: marked as done (apt-cacher-ng: FTBFS: collect2: fatal error: ld terminated with signal 11 [Segmentation fault])
reopen 975137 reassign 975137 binutils thanks Hi, first I assumed that it's a GOLD issue but looking at https://buildd.debian.org/status/package.php?p=apt%2dcacher%2dng shows the real drama. Half of architecture builds fail due to some obscure segfault of ld linker. Please investigate. Best regards, Eduard.
Bug#974870: libgdk-pixbuf2.0-dev: Plans for Xlib API deprecation
Hallo, * Simon McVittie [Sun, Nov 15 2020, 11:51:25PM]: Thanks for the insights! > However, it might be good to get the framework for this in place before > the Debian 11 freeze, which would look like this: > > * source: gdk-pixbuf > - binary: libgdk-pixbuf-2.0-0 > - binary: libgdk-pixbuf-2.0-dev > - binary: libgdk-pixbuf-xlib-2.0-0 > - binary: libgdk-pixbuf-xlib-2.0-dev > - transitional binary: libgdk-pixbuf2.0-0 > + Depends: libgdk-pixbuf-2.0-0, libgdk-pixbuf-xlib-2.0-0 > - transitional binary: libgdk-pixbuf2.0-dev > + Depends: libgdk-pixbuf-2.0-dev, libgdk-pixbuf-xlib-2.0-dev > > (That'll require a trip through NEW, of course.) Okay, sounds like a plan. I guess you will take the lead from here? Feel free to use this bug report as anchor. I cannot promise to have enough resources to support on that, though, I only came along because an upstream project where I collaborate was stormed by Gentoo users where deprecation process is apparently harsher. > Then we can do a mass-bug-filing for packages that actively use the -xlib > sub-library, and (perhaps later) a lower-severity mass-bug-filing for > packages that build-depend on libgdk-pixbuf2.0-dev but should ideally > only B-D on libgdk-pixbuf-2.0-dev. XMAS time becoming a good candidate for a such rollout then? > > maybe there should be even a warning of some kind printed > > through pkg-config or GCC warnings (although this is bad, of course, > > would break -Werror using packages). > > I don't *think* we can issue warnings from pkg-config, although there > might be a mechanism available that I'm not aware of. Do you know of such > a mechanism? Not really, sorry. Looked around and couldn't find much useful. We could invent some new hack here, like extension of FindPkgConfig.cmake (for cmake users) but all that feels like an evil kludge. > We can't issue compiler warnings and simultaneously not issue compiler > warnings, we have to choose whichever is the lesser evil. Yes. Too much warning is bad, not enough is equally bad. > If packages in Debian are using -Werror for release builds, I personally > think that's a packaging bug, because any new gcc release with better > (or just different!) optimizations or diagnostics can start issuing new > warnings that would break those packages; so I don't think it would be > terrible to break them. It would probably be better to break them after > the Debian 11 release so that people get an entire release cycle to fix > them, though. Agreed. Warnings from headers could be used as ultima ratio but only THEN. Best regards, Eduard.
Bug#974870: libgdk-pixbuf2.0-dev: Plans for Xlib API deprecation
Package: libgdk-pixbuf2.0-dev Version: 2.40.0+dfsg-5 Severity: minor Dear Maintainer, it looks like upstream support for Xlib API adapters is officially declared deprecated now. For details, see https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib . Since this affects some application packages in Debian, please prepare documentation of this issue, maybe there should be even a warning of some kind printed through pkg-config or GCC warnings (although this is bad, of course, would break -Werror using packages). Best regards, Eduard. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=de_DE.UTF-8, LC_CTYPE=ru_RU.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 libgdk-pixbuf2.0-dev depends on: ii gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-5 ii libgdk-pixbuf2.0-02.40.0+dfsg-5 ii libgdk-pixbuf2.0-bin 2.40.0+dfsg-5 ii libglib2.0-dev2.66.2-1 ii libpng-dev1.6.37-3 ii libx11-dev2:1.6.12-1 ii shared-mime-info 2.0-1 libgdk-pixbuf2.0-dev recommends no packages. libgdk-pixbuf2.0-dev suggests no packages. -- no debconf information
Bug#974724: no useful documentation of pdfjam commands
Package: texlive-extra-utils Version: 2020.20200925-1 Severity: minor File: /usr/share/texlive/texmf-dist/scripts/pdfjam/pdfjam Hi, reporting this as minor here because the usability is severely impacted. First, in former times it was easy to find pdfjam because the package description mentioned its uses more explicitly. You searched for "pdf join" or "pdf flip" and found the pdfjam. That is no longer possible, long package description does not provide enough clues, basic search does not find pdfjam. Second, the documentation is useless. The manpage refers to ONLINE documentation. IMHO this should be part of a package and NOT require a user to establish internet connection. There is no offline version of that README.md as far as I can see. Even the --help output is not helping. It tells a few things about options but it does NOT mention what the actual operations are. Tried to explain this to upstream before but earned only nothing but harsh treatment. https://github.com/DavidFirth/pdfjam/issues/30 Unfortunately they also removed the shortcut scripts (see online manual), so looking for pdfjoin executable does not bring you far. Best regards, Eduard. -- Package-specific info: IMPORTANT INFORMATION: We will only consider bug reports concerning the packaging of TeX Live as relevant. If you have problems with combination of packages in a LaTeX document, please consult your local TeX User Group, the comp.text.tex user group, the author of the original .sty file, or any other help resource. In particular, bugs that are related to up-upstream, i.e., neither Debian nor TeX Live (upstream), but the original package authors, will be closed immediately. *** The Debian TeX Team is *not* a LaTeX Help Desk *** If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.minimalbeispiel.de/mini-en.html (english) or http://www.minimalbeispiel.de/mini.html (german) ## minimal input file ## other files ## List of ls-R files -rw-rw-r-- 1 root staff 80 Mar 13 2018 /usr/local/share/texmf/ls-R -rw-r--r-- 1 root root 1436 Sep 22 2013 /etc/texmf/ls-R -rw-r--r-- 1 root root 3656 Nov 13 22:28 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Jun 8 10:31 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Sep 26 22:41 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Sep 26 22:41 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 1464 Jun 18 22:36 /etc/texmf/web2c/texmf.cnf lrwxrwxrwx 1 root root 33 Sep 26 22:41 /usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN lrwxrwxrwx 1 root root 32 Sep 26 22:41 /usr/share/texmf/web2c/updmap.cfg -> /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 2763 Oct 5 23:29 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Aug 24 2006 mktex.cnf -rw-r--r-- 1 root root 1464 Jun 18 22:36 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf 055e06548bac99958d8ab2dd1248f2b4 /etc/texmf/texmf.d/80tex4ht.cnf 1df66bc319cec731e202eaf39f5d85e1 /etc/texmf/texmf.d/96JadeTeX.cnf -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.6+ (SMP w/12 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages texlive-extra-utils depends on: ii libunicode-linebreak-perl 0.0.20190101-1+b2 ii python33.8.6-1 ii tex-common 6.15 ii texlive-base
Bug#972498: icewm: xnec2c not managed by icewm
Control: severity 972498 normal Control: tags 972498 + upstream Hallo, * g.l. gragnani [Mon, Oct 19 2020, 01:26:26PM]: > Package: icewm > Version: 1.8.3-2 > Severity: important > > Dear Maintainer, > Since some months I switched (back) to icewm. > Unfortunaly, a program that I often use, xnec2c, is not correctly managed by > icewm. > When I start xnec2c, windows are not decorated, do not appear in the taskbar, > are always in foreground and are not, in any way, managed by icewm. > xnec2c is a gtk3 multiwindow program: depending on the initial conf, the > program is started with one o more windows opened, suffering the symptoms > described before. Other windows, successively opened by xnec2c itself, are > instead correcly managed. > I tried other versions of icewm, in particular 1.6.6-1 and > 1.4.3.0~pre-20181030-2 but results are the same. > I tried LXDE (with Openbox) and Fluxbox and in these cases, xnec2c is duly > opened and managed by the wm. > I also noticed that if I start xnec2c in fluxbox and after I switch to icewm, > all the windows work as it should be. Interesting. Opened upstream issue, https://github.com/bbidulock/icewm/issues/503 Unfortunatelly I don't have any viable workaround for you, brief experimenting with winoptions (trying to enfoce decorations adding) was not effective. Best regards, Eduard.
Bug#969587: sensible-utils: document select-editor and .selected_editor file
Package: sensible-utils Version: 0.0.13 Severity: normal Dear Maintainer, * What led up to the situation? vim.gtk was removed and I have run something which was relying on sensible-editor * What exactly did you do (or not do) that was effective (or ineffective)? I wondered why something reported that vim.gtk is missing and couldn't figure out quickly where it comes from. * What was the outcome of this action? Reading sensible-editor manpage did not help. Checking environment did not help, $EDITOR or $VISUAL were not set. Eventually I had to dig in the shell script manually. * What outcome did you expect instead? The error message from sensible-editor shall tell the user where the program name came from, where was it set? The manual page shall cross-link to select-editor manpage and mention the ~/.selected_editor file along the lines. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#966390: no transparency in xzgv.png
Package: xzgv Version: 0.9.2-2 Severity: minor gimp /usr/share/icons/hicolor/32x32/apps/xzgv.png The background is just black. gimp /usr/share/pixmaps/xzgv.xpm Background appears transparent. Other scaled PNG versions of that icon also seem to have the same issue. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xzgv depends on: ii libc6 2.31-2 ii libexif12 0.6.22-2 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-02.64.4-1 ii libgtk2.0-0 2.24.32-4 ii libx11-62:1.6.9-2+b1 xzgv recommends no packages. xzgv suggests no packages. -- no debconf information
Bug#962382: kcollectd: no information printing
Package: kcollectd Version: 0.11.0-1+b1 Severity: important Dear Maintainer, I am trying to display any value from collectd. The perl script from the package works, there is apparently no problem with the data. kcollectd starts, shows the inputs tree correctly but clicking any source shows only: "Drop sensors from list here" and the rest of the main area is grey. Also there are three buttons in the bottom right corners which don't have any description and are not doing anything. BR, Eduard. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.3+ (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kcollectd depends on: ii collectd 5.11.0-3 ii libboost-filesystem1.71.0 1.71.0-6+b2 ii libc6 2.30-8 ii libgcc-s1 10.1.0-2 ii libkf5configcore5 5.62.0-1+b1 ii libkf5coreaddons5 5.62.0-1 ii libkf5i18n55.62.0-1 ii libkf5widgetsaddons5 5.62.0-1+b1 ii libkf5xmlgui5 5.62.0-1+b1 ii libqt5core5a 5.12.5+dfsg-10 ii libqt5gui5 5.12.5+dfsg-10 ii libqt5widgets5 5.12.5+dfsg-10 ii libqt5xml5 5.12.5+dfsg-10 ii librrd81.7.2-3+b4 ii libstdc++6 10.1.0-2 kcollectd recommends no packages. Versions of packages kcollectd suggests: pn khelpcenter -- no debconf information
Bug#948087: Please report state
Hello, I was notified by a prominent user who is seriouly worried about the state of this package. Please let us know whether it will be in releasable shape in the next weeks, or whether you need any support or a sponsored upload. Thank you. And in case that you no longer wish to maintain it, plesae follow the regular procedures (see policy) of orphaning, or at least consider raising a Request-For-Help, if appropriate. Best regards, Eduard. -- man the AMD64 camp is not helped by the list of people supporting it when nerode is on your side, you know you're doing something wrong
Bug#961641: Icewm needs too the X11 en_US locales, removed by localepurge v. 0.7.3.9
Hallo, * Martintxo [Sun, May 31 2020, 06:00:56PM]: > For you to know, my locale set in /etc/default/locale is: > LANG=eu_ES.UTF-8 > > So, yes, localepurge need to keep en_US.UTF-8 in /usr/share/X11/locale/. As of now, I have no motivation in "fixing" it. Purging en_US* locales is just a bad idea. This should be prevented by localepurge by adding big warning signs. Also pulling in libxft2 maintainers. I have no idea how to solve it, since icewm uses regular libxft2 methods to calculate string lengths and render the strings. Also, icewm does not set the en_US.UTF8 locale anywhere. If the presence of those locale files somehow works around your problems, then it would mean that some library code (probably in libxft2) uses that fallback to do some magic. I'd expect this magic to be documented properly then. Best regards, Eduard. -- *lesen* CrashOverride: lies mal "man undocumented", da sind einige gute Tips drin
Bug#960124: all VMs refuse to start, 0x80004005 / MachineWrap / {85632c68-b5bb-4316-a900-5eb28d3413df}
Package: virtualbox
Version: 6.1.6-dfsg-2
Severity: important
Hi,
none of my VMs is usable anymore. It was ok in last summer with the
latest vanilla kernel back then, but now I am getting:
The virtual machine 'liveos' has terminated unexpectedly during startup with
exit code 1 (0x1).
Fehlercode:
NS_ERROR_FAILURE (0x80004005)
Komponente:
MachineWrap
Interface:
IMachine {85632c68-b5bb-4316-a900-5eb28d3413df}
And this for all existing VMs in my configuration. The configuration
itself looks ok, the modules are there, the modules are loaded.
$ find /lib/modules/5.6.0-1-amd64 | grep vbox
/lib/modules/5.6.0-1-amd64/misc/vboxnetadp.ko
/lib/modules/5.6.0-1-amd64/misc/vboxdrv.ko
/lib/modules/5.6.0-1-amd64/misc/vboxnetflt.ko
/lib/modules/5.6.0-1-amd64/kernel/drivers/gpu/drm/vboxvideo
/lib/modules/5.6.0-1-amd64/kernel/drivers/gpu/drm/vboxvideo/vboxvideo.ko
/lib/modules/5.6.0-1-amd64/kernel/drivers/virt/vboxguest
/lib/modules/5.6.0-1-amd64/kernel/drivers/virt/vboxguest/vboxguest.ko
/lib/modules/5.6.0-1-amd64/updates/dkms/vboxnetadp.ko
/lib/modules/5.6.0-1-amd64/updates/dkms/vboxdrv.ko
/lib/modules/5.6.0-1-amd64/updates/dkms/vboxnetflt.ko
$ lsmod | grep vbox
vboxnetadp 28672 0
vboxnetflt 32768 0
vboxdrv 528384 2 vboxnetadp,vboxnetflt
Ryzen virtualization is enabled:
$ grep svm /proc/cpuinfo | sort -u
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf
pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx
f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext
perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2
smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves
clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean
flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif
overflow_recov succor smca
Looking for that error, reveals:
$ grep -i error VBoxSVC.log | grep -v vbox.*File.not.found
00:00:00.576586 nspr-4 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
object functionality is limited}, preserve=false aResultDetail=0
00:00:00.576622 nspr-4 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
object functionality is limited}, preserve=false aResultDetail=0
00:00:00.576640 nspr-4 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
object functionality is limited}, preserve=false aResultDetail=0
00:00:00.576649 nspr-4 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
object functionality is limited}, preserve=false aResultDetail=0
00:00:00.576658 nspr-4 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
object functionality is limited}, preserve=false aResultDetail=0
00:00:04.383412 Watcher ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005)
aIID={85632c68-b5bb-4316-a900-5eb28d3413df} aComponent={MachineWrap} aText={The
virtual machine 'liveos' has terminated unexpectedly during startup with exit
code 1 (0x1)}, preserve=false aResultDetail=0
Now idea how to continue from here. Any ideas?
Maybe this is a variant of https://www.virtualbox.org/ticket/19224 or
https://bbs.archlinux.org/viewtopic.php?pid=1887935#p1887935 ?
What "access" is required there? I am running VirtualBox as plain user
and this has been working for years.
Also, assuming that I need to reconfigure something, I tried this:
$ dpkg-reconfigure -plow virtualbox
insserv: script portmap: service portmap already provided!
Job for vboxweb.service failed because the service did not take the steps
required by its unit configuration.
See "systemctl status vboxweb.service" and "journalctl -xe" for details.
$ systemctl status vboxweb.service
● vboxweb.service - VirtualBox Web Service
Loaded: loaded (/lib/systemd/system/vboxweb.service; enabled; vendor
preset: enabled)
Active: failed (Result: protocol) since Sat 2020-05-09 19:29:55 CEST; 1min
3s ago
Process: 8721 ExecStart=/usr/lib/virtualbox/vboxweb-service.sh start
(code=exited, status=0/SUCCESS)
Mai 09 19:29:55 zombie systemd[1]: Starting VirtualBox Web Service...
Mai 09 19:29:55 zombie systemd[1]: vboxweb.service: Can't open PID file
/run/vboxweb.pid (yet?) after start: Operation not permitted
Mai 09 19:29:55 zombie systemd[1]: vboxweb.service: Failed with result
'protocol'.
Mai 09 19:29:55 zombie systemd[1]: Failed to start VirtualBox Web Service.
Again,
Bug#959675: libgrpc++1: endless looping with default settings
Package: libgrpc++1 Version: 1.26.0-3 Severity: serious Dear Maintainer, * What led up to the situation? Tried to setup a basic POC using gRPC. Used the example source code for Cpp from this source package, and dev package and protoc from regular Debian Sid. * What exactly did you do (or not do) that was effective (or ineffective)? Compiled the cpp/hellworld examples and tried to run them. * What was the outcome of this action? Nothing works. All sample programs get stuck in the beginning before opening or connecting TCP ports and inf-loop on a CPU core. Backtrace check indicates that this is a variant of https://github.com/grpc/grpc/issues/21280 . (gdb) bt #0 0x77c198e0 in grpc_core::TraceFlagList::Set(char const*, bool) () from /usr/lib/x86_64-linux-gnu/libgrpc++.so.1 #1 0x77c19a0e in grpc_tracer_init() () from /usr/lib/x86_64-linux-gnu/libgrpc++.so.1 #2 0x77535401 in grpc_init () from /usr/lib/x86_64-linux-gnu/libgrpc.so.9 #3 0x55564988 in grpc::GrpcLibraryCodegen::GrpcLibraryCodegen(bool) () #4 0x77b97aee in grpc_impl::ServerBuilder::BuildAndStart() () from /usr/lib/x86_64-linux-gnu/libgrpc++.so.1 #5 0x55575c13 in RunServer() () #6 0x55575d3f in main () * What outcome did you expect instead? Bugs like this never to arrive in Debian and not remain there for months. The Sid version is 3 months behind upstream. *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgrpc++1 depends on: ii libc6 2.30-4 ii libgcc-s1 10-20200418-1 ii libgrpc9 1.26.0-3 ii libprotobuf22 3.11.4-4 ii libstdc++6 10-20200418-1 ii zlib1g 1:1.2.11.dfsg-2 libgrpc++1 recommends no packages. libgrpc++1 suggests no packages. -- no debconf information
Bug#959208: add working instructions to disable nouveau
Hallo, * Andreas Beckmann [Fri, May 01 2020, 12:23:39AM]: > On 30/04/2020 22.08, Eduard Bloch wrote: > > lrwxrwxrwx 1 root root 22 Apr 30 21:51 /etc/alternatives/glx -> > > /usr/lib/mesa-diverted > > In this configuration, the nvidia driver is disabled. > But that has changed in your next bug report. This probably comes from the fact that I tried to configure it bottom-up. Like in the old times, first figure out how to build the module and how to load it, then install the Xorg driver. But to be honest, is this the origin of the issue? If yes, then the description of nvidia-kernel-source and nvidia-kernel-dkms (and its README.Debian) probably should clearly state: "This kernel modules shall only be installed after installing nvidia-driver package" or something similar. Best regards, Eduard. 2020-04-30 21:50:29 startup archives unpack 2020-04-30 21:50:29 install linux-headers-5.6.0-trunk-common:all 5.6.4-1~exp1 2020-04-30 21:50:29 status half-installed linux-headers-5.6.0-trunk-common:all 5.6.4-1~exp1 2020-04-30 21:50:33 status unpacked linux-headers-5.6.0-trunk-common:all 5.6.4-1~exp1 2020-04-30 21:50:33 install linux-kbuild-5.6:amd64 5.6.4-1~exp1 2020-04-30 21:50:33 status half-installed linux-kbuild-5.6:amd64 5.6.4-1~exp1 2020-04-30 21:50:33 status unpacked linux-kbuild-5.6:amd64 5.6.4-1~exp1 2020-04-30 21:50:33 install linux-headers-5.6.0-trunk-amd64:amd64 5.6.4-1~exp1 2020-04-30 21:50:33 status half-installed linux-headers-5.6.0-trunk-amd64:amd64 5.6.4-1~exp1 2020-04-30 21:50:35 status unpacked linux-headers-5.6.0-trunk-amd64:amd64 5.6.4-1~exp1 2020-04-30 21:50:35 startup packages configure 2020-04-30 21:50:35 configure linux-headers-5.6.0-trunk-common:all 5.6.4-1~exp1 2020-04-30 21:50:35 status unpacked linux-headers-5.6.0-trunk-common:all 5.6.4-1~exp1 2020-04-30 21:50:35 status half-configured linux-headers-5.6.0-trunk-common:all 5.6.4-1~exp1 2020-04-30 21:50:35 status installed linux-headers-5.6.0-trunk-common:all 5.6.4-1~exp1 2020-04-30 21:50:35 configure linux-kbuild-5.6:amd64 5.6.4-1~exp1 2020-04-30 21:50:35 status unpacked linux-kbuild-5.6:amd64 5.6.4-1~exp1 2020-04-30 21:50:35 status half-configured linux-kbuild-5.6:amd64 5.6.4-1~exp1 2020-04-30 21:50:35 status installed linux-kbuild-5.6:amd64 5.6.4-1~exp1 2020-04-30 21:50:35 configure linux-headers-5.6.0-trunk-amd64:amd64 5.6.4-1~exp1 2020-04-30 21:50:35 status unpacked linux-headers-5.6.0-trunk-amd64:amd64 5.6.4-1~exp1 2020-04-30 21:50:35 status half-configured linux-headers-5.6.0-trunk-amd64:amd64 5.6.4-1~exp1 2020-04-30 21:51:11 status installed linux-headers-5.6.0-trunk-amd64:amd64 5.6.4-1~exp1 2020-04-30 21:51:23 startup archives unpack 2020-04-30 21:51:24 install update-glx:amd64 0.8.3 1.1.0 2020-04-30 21:51:24 status half-installed update-glx:amd64 0.8.3 2020-04-30 21:51:24 status triggers-pending man-db:amd64 2.9.1-1 2020-04-30 21:51:24 status unpacked update-glx:amd64 1.1.0 2020-04-30 21:51:24 install glx-alternative-mesa:amd64 0.8.3 1.1.0 2020-04-30 21:51:24 status half-installed glx-alternative-mesa:amd64 0.8.3 2020-04-30 21:51:24 status unpacked glx-alternative-mesa:amd64 1.1.0 2020-04-30 21:51:25 install nvidia-installer-cleanup:amd64 20151021+7 20151021+11 2020-04-30 21:51:25 status half-installed nvidia-installer-cleanup:amd64 20151021+7 2020-04-30 21:51:25 status unpacked nvidia-installer-cleanup:amd64 20151021+11 2020-04-30 21:51:25 startup packages configure 2020-04-30 21:51:25 configure nvidia-installer-cleanup:amd64 20151021+11 2020-04-30 21:51:25 status unpacked nvidia-installer-cleanup:amd64 20151021+11 2020-04-30 21:51:25 status half-configured nvidia-installer-cleanup:amd64 20151021+11 2020-04-30 21:51:25 status installed nvidia-installer-cleanup:amd64 20151021+11 2020-04-30 21:51:26 startup archives unpack 2020-04-30 21:51:26 install glx-diversions:amd64 0.8.3 1.1.0 2020-04-30 21:51:26 status half-installed glx-diversions:amd64 0.8.3 2020-04-30 21:51:26 status unpacked glx-diversions:amd64 1.1.0 2020-04-30 21:51:26 install glx-alternative-nvidia:amd64 0.8.0 1.1.0 2020-04-30 21:51:26 status half-installed glx-alternative-nvidia:amd64 0.8.0 2020-04-30 21:51:26 status unpacked glx-alternative-nvidia:amd64 1.1.0 2020-04-30 21:51:26 install nvidia-legacy-check:amd64 384.111-4 440.82-1 2020-04-30 21:51:26 status half-installed nvidia-legacy-check:amd64 384.111-4 2020-04-30 21:51:27 status unpacked nvidia-legacy-check:amd64 440.82-1 2020-04-30 21:51:27 startup packages configure 2020-04-30 21:51:27 configure nvidia-legacy-check:amd64 440.82-1 2020-04-30 21:51:27 status unpacked nvidia-legacy-check:amd64 440.82-1 2020-04-30 21:51:27 status half-configured nvidia-legacy-check:amd64 440.82-1 2020-04-30 21:51:27 status installed nvidia-legacy-check:amd64 440.82-1 2020-04-30 21:51:27 startup archives unpack 2020-04-30 21:51:28 install nvidia-alternative:amd64 375.82-4 440.82-1 2020-04-30 21:51:28 status half-installed nvidia-alternative:amd64 375.82-4 2020-0
Bug#959210: no automatic Xorg configuration for NVidia
Hallo, * Andreas Beckmann [Fri, May 01 2020, 12:49:11AM]: > On 30/04/2020 22.18, Eduard Bloch wrote: > > I don't know what the problem is. Looking at Xorg log, it seems that it > > The problem happens earlier, before xorg gets started: > The nvidia module does not get loaded at boot. > > > still insist on loading NOUVEAU. So I think something is broken in your > > package, the bit which was supposed to turn nouveau off. > > I think something is "special" in your long grown system, some local > tweak long forgotten that now gets in the way of nvidia ... > > /etc/modules-load.d/nvidia.conf should be responsible for loading the > nvidia-drm kernel module, while > /etc/modprobe.d/nvidia-blacklists-nouveau.conf prevents nouveau from > being loaded automatically. > Does manual 'modprobe -v nvidia-drm' work? If not, dmesg may contain > interesting error messages. $ cat /etc/modules-load.d/nvidia.conf nvidia-drm $ cat /etc/modprobe.d/nvidia-blacklists-nouveau.conf # You need to run "update-initramfs -u" after editing this file. # see #580894 blacklist nouveau $ modprobe -v nvidia-drm $ modinfo nvidia-drm modinfo: ERROR: Module nvidia-drm not found. Now what? $ grep nvidia-kernel /var/log/dpkg.log 2020-04-30 21:51:28 install nvidia-kernel-common:amd64 20151021+4 20151021+11 2020-04-30 21:51:28 status half-installed nvidia-kernel-common:amd64 20151021+4 2020-04-30 21:51:28 status unpacked nvidia-kernel-common:amd64 20151021+11 2020-04-30 21:51:28 install nvidia-kernel-source:amd64 440.82-1 2020-04-30 21:51:28 status half-installed nvidia-kernel-source:amd64 440.82-1 2020-04-30 21:51:29 status unpacked nvidia-kernel-source:amd64 440.82-1 2020-04-30 21:51:29 install nvidia-kernel-support:amd64 375.82-1 440.82-1 2020-04-30 21:51:29 status half-installed nvidia-kernel-support:amd64 375.82-1 2020-04-30 21:51:29 status unpacked nvidia-kernel-support:amd64 440.82-1 2020-04-30 21:51:29 configure nvidia-kernel-common:amd64 20151021+11 2020-04-30 21:51:29 status unpacked nvidia-kernel-common:amd64 20151021+11 2020-04-30 21:51:29 status half-configured nvidia-kernel-common:amd64 20151021+11 2020-04-30 21:51:30 status installed nvidia-kernel-common:amd64 20151021+11 2020-04-30 21:51:30 configure nvidia-kernel-source:amd64 440.82-1 2020-04-30 21:51:30 status unpacked nvidia-kernel-source:amd64 440.82-1 2020-04-30 21:51:30 status half-configured nvidia-kernel-source:amd64 440.82-1 2020-04-30 21:51:30 status installed nvidia-kernel-source:amd64 440.82-1 2020-04-30 21:51:43 configure nvidia-kernel-support:amd64 440.82-1 2020-04-30 21:51:43 status unpacked nvidia-kernel-support:amd64 440.82-1 2020-04-30 21:51:43 status half-configured nvidia-kernel-support:amd64 440.82-1 2020-04-30 21:51:43 status triggers-awaited nvidia-kernel-support:amd64 440.82-1 2020-04-30 21:51:52 status installed nvidia-kernel-support:amd64 440.82-1 2020-04-30 22:11:07 install nvidia-kernel-dkms:amd64 440.82-1 2020-04-30 22:11:07 status half-installed nvidia-kernel-dkms:amd64 440.82-1 2020-04-30 22:11:08 status unpacked nvidia-kernel-dkms:amd64 440.82-1 2020-04-30 22:11:19 configure nvidia-kernel-dkms:amd64 440.82-1 2020-04-30 22:11:19 status unpacked nvidia-kernel-dkms:amd64 440.82-1 2020-04-30 22:11:19 status half-configured nvidia-kernel-dkms:amd64 440.82-1 2020-04-30 22:11:58 status installed nvidia-kernel-dkms:amd64 440.82-1 Now that confuses me. I have run "m-a a-i nvidia -vt" yesterday and as far as I remember, it has finished successfully, it has installed a few packages. But I don't see a log in /var/cache/modass/ , only nvidia-kernel-source.cur_version and nvidia-kernel-source.avail_version files. That's totally confusing. Why was the package Ok, so what I did not? Run "m-a a-i nvidia -vt" again. OTOH I don't know. The driver worked yesterday after chaning xorg.conf so it should be there, and I cannot check afterwards what happened. I rerun m-a again, and it did build and install nvidia-kernel-5.6.0-trunk-amd64 this time. But the module it contains is called nvidia-current-drm, not nvidia-drm. EDIT: continuing to write this a after a couple of reboots. I tried to recreate the situation from yesterday. I see that installing the m-a packages was not needed, the module was already built and injected by dkms and yes, it was loadable. But it was not loaded yesterday, according to the log it was only loaded after I edited xorg.conf (so it was triggerd forcibly by the driver). Also, this looks confusing if you don't know what to look for: # modprobe -v nvidia-drm # modprobe -v nvidia-current-drm insmod /lib/modules/5.6.0-trunk-amd64/updates/dkms/nvidia-current.ko insmod /lib/modules/5.6.0-trunk-amd64/updates/dkms/nvidia-current-modeset.ko insmod /lib/modules/5.6.0-trunk-amd64/updates/dkms/nvidia-current-drm.ko So, your hint from above was only partly helpful. Maybe this should be brought to modutils maintainers, this difference shou
