Bug#1037091: podman run fails because of missing ~/.config/docker/config.json
For others having the same issue, just creating an empty file with "touch ~/.config/docker/config.json" does fix the issue. Podman does not seem to require any configuration in there (at least in my case). However, as someone might assume that Podman wants any content there, they still might be virtually hindered to use podman, so I think severity important is still correct. But feel free to reduce that if you think otherwise.
Bug#1037091: podman run fails because of missing ~/.config/docker/config.json
Package: podman Version: 4.3.1+ds1-8+b1 Severity: important Dear maintainer, the current version of podman does not allow me to run any container due to the following error message: Error: stat /home/$USER/.config/docker/config.json: no such file or directory I can trigger this issue with a simple: podman run debian However, what container I try to run seems not to matter. The current version in experimental (4.4.0+ds1-1) is also not working on my machine. I cannot say which version introduced this issue as I do not use podman very often. To the best of my knowledge, the last time I used it, it worked fine and I do not know of any changes I introduced (beside updates) which could explain this issue. However, it still seems at least weird to me, that podman requires (not just reads optionally) a config file which is in Docker's config dir. I can append further debugging information if requested. Thanks Felix Stupp -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (550, 'testing'), (500, 'testing-security'), (500, 'stable-security'), (400, 'stable-updates'), (400, 'stable'), (350, 'oldstable-updates'), (350, 'oldstable'), (110, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages podman depends on: ii conmon 2.1.6+ds1-1 ii crun 1.8.1-1+b1 ii golang-github-containers-common 0.50.1+ds1-4 ii libc62.36-9 ii libdevmapper1.02.1 2:1.02.185-2 ii libgpgme11 1.18.0-3+b1 ii libseccomp2 2.5.4-1+b3 ii libsubid41:4.13+dfsg1-1+b1 ii runc 1.1.5+ds1-1+b1 Versions of packages podman recommends: ii buildah1.28.2+ds1-3+b1 ii dbus-user-session 1.14.6-1 ii fuse-overlayfs 1.10-1 ii slirp4netns1.2.0-1 ii tini 0.19.0-1 ii uidmap 1:4.13+dfsg1-1+b1 Versions of packages podman suggests: ii containers-storage 1.43.0+ds1-8 ii docker-compose 1.29.2-3 ii iptables1.8.9-2 -- Configuration Files: /etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied: '/etc/cni/net.d/87-podman-bridge.conflist' -- no debconf information
Bug#1036190: kmail: Crash on startup when GHNS is disabled in kde5rc
I have the same issue that kmail on version 4:22.12.3-1 does eventually but always crash after a certain time or action. Makes the program unusable. I haven't set the "ghns" key to false in /etc/kde5rc, but I also might not have the full KDE suite installed, I selected the packages I need. And because reverting to 4:22.12.2-1 does solve my issue (aka. 4:22.12.3-1 was the first I had this issue), I assume that I might have the same bug. So I assume it could be from the same reason, I'm sorry if that assumption of mine is wrong. -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (550, 'testing'), (500, 'testing-security'), (500, 'stable-security'), (400, 'stable-updates'), (400, 'stable'), (350, 'oldstable-updates'), (350, 'oldstable'), (110, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kmail depends on: ii akonadi-server 4:22.12.3-1 ii kdepim-runtime 4:22.12.3-1 ii kio 5.103.0-1 ii libc62.36-9 ii libgcc-s112.2.0-14 ii libgpgmepp6 1.18.0-3+b1 ii libkf5akonadiagentbase5 [libkf5akonadiagentbase5-22 4:22.12.3-1 .12] ii libkf5akonadicontact5 [libkf5akonadicontact5-22.12] 4:22.12.3-1 ii libkf5akonadicore5abi2 [libkf5akonadicore5-22.12]4:22.12.3-1 ii libkf5akonadimime5 [libkf5akonadimime5-22.12]4:22.12.3-1 ii libkf5akonadisearch-bin 4:22.12.3-1 ii libkf5akonadisearch-plugins 4:22.12.3-1 ii libkf5akonadisearchdebug5 [libkf5akonadisearchdebug 4:22.12.3-1 5-22.12] ii libkf5akonadisearchpim5 [libkf5akonadisearchpim5-22 4:22.12.3-1 .12] ii libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22 4:22.12.3-1 .12] ii libkf5bookmarks5 5.103.0-1 ii libkf5calendarcore5abi2 5:5.103.0-1 ii libkf5calendarutils5 [libkf5calendarutils5-22.12]4:22.12.3-1 ii libkf5codecs55.103.0-1 ii libkf5completion55.103.0-1 ii libkf5configcore55.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5configwidgets5 5.103.0-1 ii libkf5contacts5 5:5.103.0-1 ii libkf5coreaddons55.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5dbusaddons55.103.0-1 ii libkf5grantleetheme-plugins 22.12.3-1 ii libkf5gravatar5abi2 [libkf5gravatar5-22.12] 4:22.12.3-1 ii libkf5guiaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5iconthemes55.103.0-1 ii libkf5identitymanagement5 [libkf5identitymanagement 22.12.3-1 5-22.12] ii libkf5identitymanagementwidgets5 [libkf5identityman 22.12.3-1 agementwidgets5-22.12] ii libkf5itemmodels55.103.0-1 ii libkf5itemviews5 5.103.0-1 ii libkf5jobwidgets55.103.0-1 ii libkf5kcmutils5 5.103.0-3 ii libkf5kiocore5 5.103.0-1 ii libkf5kiofilewidgets55.103.0-1 ii libkf5kiogui55.103.0-1 ii libkf5kiowidgets55.103.0-1 ii libkf5kontactinterface5 [libkf5kontactinterface5-22 22.12.3-1 .12] ii libkf5ksieveui5 [libkf5ksieveui5-22.12] 4:22.12.3-1 ii libkf5ldap5abi1 [libkf5ldap5-22.12] 22.12.3-1 ii libkf5libkdepim5 [libkf5libkdepim5-22.12]4:22.12.3-1 ii libkf5libkleo5 [libkf5libkleo5-22.12]4:22.12.3-1 ii libkf5mailcommon5abi2 [libkf5mailcommon5-22.12] 4:22.12.3-1 ii libkf5mailtransport5 [libkf5mailtransport5-22.12]22.12.3-1 ii libkf5mailtransportakonadi5 [libkf5mailtransportako 22.12.3-1 nadi5-22.12] ii libkf5messagecomposer5abi1 [libkf5messagecomposer5- 4:22.12.3-1 22.12] ii libkf5messagecore5abi1 [libkf5messagecore5-22.12]4:22.12.3-1 ii libkf5messagelist5abi1 [libkf5messagelist5-22.12]4:22.12.3-1 ii libkf5messageviewer5abi1 [libkf5m
Bug#1036642: [Pkg-zfsonlinux-devel] Bug#1036642: zfsutils-linux: Fix description in man page for periodic scrubs (Debian's own implementation not explained & OpenZFS unit files missing)
Dear Yurii, sorry, I messed up my check & the verification I did. I checked for it by auto completing "systemctl status" command and then trying to manually type it in, which both of course does not work for "systemctl status" but for "systemctl enable" (because there is no instance known yet). An dI verified it by searching for the files on packages.debian.org, but most probably searched only for bullseye / stable and not for bookworm, I'm sorry for that. I would then change the title myself, but I don't know how to do that on this tracker. Am Dienstag, 23. Mai 2023, 20:38:03 CEST schrieben Sie: > Dear Felix, I’m unsure how you checked for it, but it’s been shipped [0] in > the Debian for over a year since 04c0728c [1]. > > [0] > https://packages.debian.org/search?searchon=contents&keywords=zfs-scrub&mode=filename&suite=testing&arch=any > [1] > https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/04c0728cdb8c2f58aa7958ef72ab41f3d20df26f > > signature.asc Description: This is a digitally signed message part.
Bug#1036642: zfsutils-linux: Fix description in man page for periodic scrubs (Debian's own implementation not explained & OpenZFS unit files missing)
Package: zfsutils-linux
Version: 2.1.11-1
Severity: normal
Dear maintainer,
in the man page zpool-scrub(8), the OpenZFS maintainers explain how an
admin can setup automatic periodic scrubs on machines using systemd.
The explanation refers to the unit files which they want to be included
in each OpenZFS Installation. See the files
`zfs-scrub-{weekly,monthly}@.{service,timer}.in in:
https://github.com/openzfs/zfs/tree/master/etc/systemd/system
1. The Debian installation of OpenZFS do not include those both files,
making the explanation in the man page not helpful. Either should those
be included in future ZFS installations (which I would prefer, as it
gives the people the most options) or this section of the man page
should be changed.
2. In the Debian Wiki, there is an explanation about a Debian specific
implementation of auto scrub, which automatically scrubs all pools (with
an opt-out), see https://wiki.debian.org/ZFS#Auto_Scrub_of_all_pools .
I think the existance of this mechanism should also be explained in this
man page, otherwise admins, especially ones, which might know ZFS
already from other plattforms might run into the problem of multiple
auto scrub timers running.
(I'm not personally a fan of the opt-out as, on my PC, most pools are on
external drives, which I currently work with & scrub manually, so I have
it permanently disabled on my system by changing the cron file, and opt
in for internal pools by using a systemd timer with Persistent=True. I
can understand why its implemented in the first place, so at least a
hint in that man page would be nice. I found out about this by accident
as I don't really use the Debian Wiki as long as man pages & general
documentation on the Internet are good enough.)
If you have any further questions, just ask.
Thanks for reading & fixing this & in general thanks for packaging ZFS
for Debian.
Felix Stupp
-- System Information:
Debian Release: 12.0
APT prefers testing
APT policy: (550, 'testing'), (500, 'testing-security'), (500,
'stable-security'), (400, 'stable-updates'), (400, 'stable'), (350,
'oldstable-updates'), (350, 'oldstable'), (110, 'unstable'), (102,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages zfsutils-linux depends on:
ii init-system-helpers 1.65.2
ii libblkid12.38.1-5+b1
ii libc62.36-9
ii libnvpair3linux 2.1.11-1
ii libuuid1 2.38.1-5+b1
ii libuutil3linux 2.1.11-1
ii libzfs4linux 2.1.11-1
ii libzpool5linux 2.1.11-1
ii python3 3.11.2-1+b1
Versions of packages zfsutils-linux recommends:
ii zfs-dkms [zfs-modules] 2.1.11-1
ii zfs-zed 2.1.11-1
Versions of packages zfsutils-linux suggests:
ii nfs-kernel-server 1:2.6.2-4
pn samba-common-bin
pn zfs-initramfs | zfs-dracut
-- Configuration Files:
/etc/cron.d/zfsutils-linux changed [not included]
/etc/sudoers.d/zfs [Errno 13] Permission denied: '/etc/sudoers.d/zfs'
-- no debconf information
signature.asc
Description: This is a digitally signed message part.
Bug#1010385: task-spooler: Please update to newer upstream
Hi, the dev of that GitHub project explained that it's a fork because the original one "is unmaintained". However, he started the fork before the last version of the original upstream, 1.0.2, was released. I think it most probably deserves its own package at first. On Sun, 29 May 2022 11:52:32 +0300 Alexander Inyukhin wrote: > Hi! > > Is it really a new upstream? > Original one is often inaccessible but still valid, I guess. > Latest version there is 1.0.2 with minor changes. > > > On Sat, Apr 30, 2022 at 02:49:56AM -0500, John Goerzen wrote: > > Package: task-spooler > > Version: 1.0.1+dfsg1-1 > > Severity: wishlist > > > > https://github.com/justanhduc/task-spooler seems to be the new home, and it > > up to 1.3.x. > > > > Thanks! > >
Bug#1033617: libopenexr-dev: Cannot just upgrade libopenexr-dev to 3.1.5-4 because of file conflict with older version of libilmbase-dev
Hello, that's true, somehow I messed up the version number, sorry. I had libilmbase-dev version 2.5.7-2+b1 installed when I ran into this issue according to my aptitude log. I also tried out to reproduce the issue again in Docker & succeeded, see the attached Dockerfile. However, after seeing how old both package versions are and that these exact versions were not available at the same time, I do not know how I ended up with exactly these versions and using them until just a few days ago. Maybe another package which wasn't updated for quite a while had a hardlocked dependency. To know for sure, I would need to restore the full list of packages & versions I had installed before upgrading by reading the dpkg logs. Best Regards, Felix Stupp Am Mittwoch, 29. März 2023, 19:06:29 CEST schrieben Sie: > On 2023-03-28 Felix Stupp wrote: > > Package: libopenexr-dev > > Version: 3.1.5-4 > > Severity: serious > > Justification: Policy 7.4 > > X-Debbugs-Cc: me+debian-b...@banananet.work > > > Dear Maintainer, > > > I cannot upgrade this package from version 2.5.7-1 to version 3.1.5-4 > > due to a file conflict with the package libilmbase-dev on version > > 2.5.4-1. I tried with apt & aptitude as well. Both want to replace > > libilmbase-dev with libopenexr-dev in a single execution of them, but > > fail to do that in a way that dpkg allows that (tries first to install > > the new package and then uninstall the old one). > > Currently I see no other solution than removing the old one first aside > > with all packages depending it on it, and then installing the new one > > with all packages which were removed before. > [...] > > Hello, > > I cannot reporoduce this from your description because the original > setup you started with > > libopenexr-dev + libopenexr25 2.5.7-1 > libilmbase-dev + libilmbase25 2.5.4-1 > > is not installable, libopenexr25 2.5.7-1 depends on libilmbase25 (>= 2.5.7). > > cu Andreas > FROM docker.io/library/debian:bookworm-20230320 # Install tools required further RUN apt-get update && apt-get install -y aptitude # Disable current and enable snapshot repository RUN sed -i -r 's~# ~URIs: ~;s~URIs:( http://deb.debian.org)~#\1~' /etc/apt/sources.list.d/debian.sources # Enable old enough snapshot repository RUN sed -i -r 's~# ~URIs: ~;s~/20[0-9]*(T[0-9]*Z)$~/20210929\1~;s~URIs:( http://deb.debian.org)~#\1~' /etc/apt/sources.list.d/debian.sources RUN aptitude -o Acquire::Check-Valid-Until=false update # Install packages to break RUN aptitude install -y libopenexr-dev=2.5.7-1 # Jump to specific date RUN sed -i -r 's~/20[0-9]*(T[0-9]*Z)$~/20221010\1~' /etc/apt/sources.list.d/debian.sources RUN cat /etc/apt/sources.list.d/debian.sources RUN aptitude -o Acquire::Check-Valid-Until=false update # Install packages to break RUN aptitude install -y libilmbase-dev=2.5.7-2+b1 # Reset to newer repository RUN sed -i -r 's~# ~URIs: ~;s~URIs:( http://snapshot.debian.org)~#\1~' /etc/apt/sources.list.d/debian.sources RUN aptitude update # Try to upgrade package with following command: # apt install -y libopenexr-dev>=3.1.5-4
Bug#1033617: libopenexr-dev: Cannot just upgrade libopenexr-dev to 3.1.5-4 because of file conflict with older version of libilmbase-dev
for documentation purposes, I now fixed the issue for my systems by
force-removing the old package first with dpkg and then installing its
replacements with markauto:
sudo dpkg --remove --force-depends libilmbase-dev
sudo aptitude install lib{imath,openexr}-dev+M # or apt install --mark-auto
lib{imath,openexr}-dev
Bug#1033617: libopenexr-dev: Cannot just upgrade libopenexr-dev to 3.1.5-4 because of file conflict with older version of libilmbase-dev
Package: libopenexr-dev Version: 3.1.5-4 Severity: serious Justification: Policy 7.4 X-Debbugs-Cc: me+debian-b...@banananet.work Dear Maintainer, I cannot upgrade this package from version 2.5.7-1 to version 3.1.5-4 due to a file conflict with the package libilmbase-dev on version 2.5.4-1. I tried with apt & aptitude as well. Both want to replace libilmbase-dev with libopenexr-dev in a single execution of them, but fail to do that in a way that dpkg allows that (tries first to install the new package and then uninstall the old one). Currently I see no other solution than removing the old one first aside with all packages depending it on it, and then installing the new one with all packages which were removed before. They already have a "Breaks" & a "Replace" relationship, which seems to be right, but I assume adding a "Conflicts" relation will fix that, for "Breaks" "dpkg will refuse to allow the package […] to be unpacked unless the broken package is deconfigured first", while for "Conflicts" it says that "dpkg will refuse to allow them to be unpacked on the system at the same time". I marked this bug as serious as I think, even if another solution may be found, that still a Conflicts field on this package referring to the older one may be required unless that is not possible. However, I'm not 100% sure, so feel free to change the severity. Maybe I just ran into this problem due to other circumstances a stable user will not run into. Also I assume that if this configuration will be released into bookworm, others will having problems as well. Best Regards, Felix Stupp -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (550, 'testing'), (500, 'testing-security'), (400, 'stable-updates'), (400, 'stable-security'), (400, 'stable'), (110, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.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 libopenexr-dev depends on: pn libilmbase-dev ii libopenexr252.5.7-1 libopenexr-dev recommends no packages. libopenexr-dev suggests no packages. -- no debconf information
Bug#1013089: ddccontrol-db: Version number not matching with upstream
Package: ddccontrol-db Version: 20220626-1 Severity: minor Dear Maintainer, just wanted to inform you that the version number of the current package (20220626-1) does not match the current upstream version (20220526-1), the month is one too big. Just so you know that if a new version is released until 2022-06-26, you might need to continue using another version number so its recognized as a updated package. Otherwise I don't think needs to be fixed ASAP. Sincerely, Felix Stupp -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (550, 'testing'), (500, 'stable-security'), (400, 'stable-updates'), (400, 'stable'), (350, 'oldstable-updates'), (350, 'oldstable'), (110, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled ddccontrol-db depends on no packages. Versions of packages ddccontrol-db recommends: ii ddccontrol 0.6.0-8 ddccontrol-db suggests no packages. -- no debconf information
Bug#1008658: virtualbox: Rebuild against python3 >= 3.10
Dear Maintainers, couldn't this be resolved in a better way? Because the VirtualBox package is now requires python3 >= 3.10, << 3.11, I cannot upgrade it to its newer version without upgrading python3 to its unstable version as well. I'm primarily using Debian testing packages but install some packages from unstable, like VirtualBox. I have installed python3.10 as well, but currently python3 (the dependency package) from testing. Does VirtualBox really need python3.10 as default and cannot work, if package python3 is installed in version 3.9 while python3.10 is available as well? If not, I think it would be better to remove the dependency on python3 and only depend on the currently required / targeted python package (like python3.9 / python3.10 / …). Or another way could be to lift the restriction on the python3 package versions and only introduce them if really required. With either solution, it should be possible to use the virtualbox package on multiple versions without any more hassle than necessary about these dependencies. I propose these solutions because if multiple packages would pin python3 to their required versions and a user wants to install two packages, where these versions differ, it would not be possible. Regards, Felix
Bug#993768: exa: "git" feature was disabled in this build of exa
Package: exa Version: 0.10.1-1 Severity: normal I'm using exa especially because of its git support. After upgrading to version 0.10.1-1, the git features stop working. Calling `exa --git` now issues following error: ``` $ exa --git exa: Options --git and --git-ignore can't be used because `git` feature was disabled in this build of exa ``` Is there a reason (like a software bug) which explains why the git features are disabled in the newer builds? If not, I would this a bug, especially because exa in Debian is also promoted with the git features. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (550, 'testing'), (400, 'stable'), (350, 'oldstable-updates'), (350, 'oldstable'), (110, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0-trunk-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages exa depends on: ii libc6 2.31-17 ii libgcc-s1 11.2.0-4 exa recommends no packages. exa suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part.
Bug#980243: arcanist: man page misses "arc diff --draft" option
Package: arcanist Version: 0~git20200925-1 Severity: minor The manpage of arc seems to miss some updates, e.g. for the subcommand "arc diff" the manpage lists "--plan-changes" as a valid option, but arcanist fails when calling with this option due to not knowing it. But "arc diff --help" lists "--draft", which seems like the successor of the first option, which works just fine and is not listed in the manpage. This may should be fixed if someone finds time to look through the manpage. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (550, 'testing'), (400, 'stable-updates'), (400, 'stable'), (350, 'oldstable-updates'), (350, 'oldstable'), (110, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-5-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:de Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages arcanist depends on: ii libphutil 0~git20200925-1 ii php7.4-cli [php-cli]7.4.11-1 ii php7.4-curl [php-curl] 7.4.11-1 ii php7.4-xml [php-xml]7.4.11-1 arcanist recommends no packages. Versions of packages arcanist suggests: pn python -- no debconf information signature.asc Description: This is a digitally signed message part.
Bug#958404: Tried to confirm on clean VM
I TRIED to confirm the issue in a clean VirtualBox VM, but failed. On Debian Buster after enabling Backports, installing wireguard and confirming that it was built by dkms, I got the same issue. Rebooting the system did not help. I collected more information about the dkms module, and found the issue: "wireguard-dkms" was built for the newest kernel available in buster (not backports), in my case "4.19.0-11-amd64" (see output of "dkms status") due to first installing "linux-headers-amd64" (wasn't required before). Testing with "modprobe wireguard" showed, that the kernel module could not be loaded. And that was because I was running the older kernel version "4.19.0-10-amd64". Upgrading and restarting the system solved the issue in my case. It must be that a new kernel version was released while I was working today with the VM, maybe a similar issue happened to you, too? Best Regards, Felix Stupp signature.asc Description: This is a digitally signed message part.
Bug#949518: iptables: ufw fails with iptables 1.8.4-2
This report (#949739) refers to the same bug as the report #949518 (https://bugs.debian.org/949518), These reports should be merged or at least be linked together.
