Bug#993985: wireguard should not depend on wireguard-dkms or wireguard-modules in Debian 11
Package: wireguard-tools Followup-For: Bug #993985 Dear Maintainer, In Debian 11 (currently 'testing'), there are no packages which provide 'wireguard-dkms', and 'wireguard-modules' is provided by the standard 'linux- image-' packages. As a result there is no apparent value in having 'wireguard-tools' recommend either of those. In fact on a system which intentionally does *not* have the 'linux- image-' package installed, installing 'wireguard-tools' will pull it in unless the user tells it not to, and may pull it in in the future when the 'wireguard-tools' package is upgraded and 'apt upgrade' is run... unless the user once again remember to tell 'apt' to not install recommended packages. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/8 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireguard-tools depends on: ii libc6 2.36-9 Versions of packages wireguard-tools recommends: ii iptables 1.8.9-2 ii linux-image-amd64 [wireguard-modules] 6.1.20-2 ii nftables 1.0.6-2 Versions of packages wireguard-tools suggests: pn openresolv | resolvconf -- no debconf information
Bug#1030930: podman: DNS resolution fails in 'podman build' but works in 'podman run'
On Mon, Apr 10, 2023, at 17:52, Reinhard Tartler wrote: > Control: tag -1 + unreproducible moreinfo > > Hi Kevin, > > great to hear from you in this space! > > On Thu, Feb 9, 2023 at 8:36 AM Kevin P. Fleming wrote: >> Package: podman >> Version: 4.3.1+ds1-5+b1 >> Severity: important >> >> Dear Maintainer, >> >> I am seeing DNS resolution fail when using 'podman build' but succeed when >> using 'podman run', with a Dockerfile which contains the same commands I run >> manually in the 'podman run'-launched shell. >> >> Dockerfile >> -- >> FROM alpine:3.10 >> RUN cat /etc/resolv.conf >> RUN apk add tar > > Unfortunately, I can't reproduce. Please help me to reproduce this issue. > Also, maybe upstream has an idea, can you please report this issue at > https://github.com/containers/podman/issues/new/choose. In any case, here is > the output that I get: > > siretart@x1:/tmp/dnstest$ cat >> Containerfile > FROM alpine:3.10 > RUN cat /etc/resolv.conf > RUN apk add tar > siretart@x1:/tmp/dnstest$ cat Containerfile > FROM alpine:3.10 > RUN cat /etc/resolv.conf > RUN apk add tar > siretart@x1:/tmp/dnstest$ podman build . > STEP 1/3: FROM alpine:3.10 > Resolved "alpine" as an alias > (/etc/containers/registries.conf.d/shortnames.conf) > Trying to pull docker.io/library/alpine:3.10... > Getting image source signatures > Copying blob 396c31837116 done > Copying config e7b300aee9 done > Writing manifest to image destination > Storing signatures > STEP 2/3: RUN cat /etc/resolv.conf > search int.tauware.de > nameserver 10.0.2.3 > nameserver 192.168.88.3 > --> 2ce59772eaf > STEP 3/3: RUN apk add tar > fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz > fetch > http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz > (1/1) Installing tar (1.32-r1) > Executing busybox-1.30.1-r5.trigger > OK: 6 MiB in 15 packages > COMMIT > --> 7c1bfd9e030 > 7c1bfd9e030f07b05cc9427a97c0bc5ff73bca5436bce389ad81da1a64f64a11 Confirmed; I can no longer reproduce the problem. Something somewhere in the stack got fixed :-)
Bug#983600: Is there a workaround for this?
This package is a transitive *unused* dependency of something I'm trying to cross-build (using pbuilder), and the fact that I can't install it stops the entire process. If there's any way I can force this package to be installed despite the broken dependency chain I could likely make progress.
Bug#1030930: podman: DNS resolution fails in 'podman build' but works in 'podman run'
Package: podman Version: 4.3.1+ds1-5+b1 Severity: important Dear Maintainer, I am seeing DNS resolution fail when using 'podman build' but succeed when using 'podman run', with a Dockerfile which contains the same commands I run manually in the 'podman run'-launched shell. Dockerfile -- FROM alpine:3.10 RUN cat /etc/resolv.conf RUN apk add tar 'podman run' -- kpfleming@nvr21:~/ctr-dns$ podman run --rm -it alpine:3.10 /bin/sh / # cat /etc/resolv.conf nameserver 10.0.2.3 nameserver 2001:470:8afe:255::2 options edns0 trust-ad / # apk add tar fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz fetch http://dl- cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz (1/1) Installing tar (1.32-r1) Executing busybox-1.30.1-r5.trigger OK: 6 MiB in 15 packages / # exit `podman build` -- kpfleming@nvr21:~/ctr-dns$ podman build . STEP 1/3: FROM alpine:3.10 STEP 2/3: RUN cat /etc/resolv.conf --> Using cache 6e684b0a8063a3c6ea051cc28b16ea19cc984ba9f154810cc3235d10e2ad4b2b --> 6e684b0a806 STEP 3/3: RUN apk add tar fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.10/main: temporary error (try again later) WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.10/main: No such file or directory fetch http://dl- cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.10/community: temporary error (try again later) WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.10/community: No such file or directory ERROR: unable to select packages: tar (no such package): required by: world[tar] Error: building at STEP "RUN apk add tar": while running runtime: exit status 1 When I add 'strace' to the image and trace the 'apk' invocation, I see that the DNS queries sent to the servers listed in /etc/resolv.conf both time out, when using 'podman build'. I have tested the 4.4 package from 'experimental' with no change in behavior. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/8 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 not set 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.3+ds1-1 ii crun 1.5+dfsg-1+b1 ii golang-github-containers-common 0.50.1+ds1-4 ii libc62.36-8 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 ii runc 1.1.4+ds1-1+b1 Versions of packages podman recommends: ii buildah1.28.2+ds1-1 ii catatonit 0.1.7-1+b1 ii dbus-user-session 1.14.4-1 ii fuse-overlayfs 1.9-1 ii slirp4netns1.2.0-1 ii uidmap 1:4.13+dfsg1-1 Versions of packages podman suggests: ii containers-storage 1.43.0+ds1-7 pn docker-compose ii iptables1.8.9-2 -- no debconf information
Bug#1027476: cron: postrm script fails because expected dpkg-statoverride is not present
Package: cron
Version: 3.0pl1-154
Severity: normal
Dear Maintainer,
The postrm script in the current version of the cron package assumes the
presence of a dpkg-statoverride for /usr/bin/crontab, but no such statoverride
is present on my systems. As a result when I try to 'purge' the cron package
the process fails.
Recipe to reproduce the issue:
1) cd /root
2) mkdir foo
3) debootstrap --variant=minbase --include=logrotate,systemd-cron bookworm
4) chroot /root/foo /bin/bash
5) apt remove --purge cron
This results in the following output:
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
cron*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
(Reading database ... 11054 files and directories currently installed.)
Purging configuration files for cron (3.0pl1-154) ...
dpkg-statoverride: warning: no override present
dpkg: error processing package cron (--purge):
installed cron package post-removal script subprocess returned error exit
status 2
Errors were encountered while processing:
cron
E: Sub-process /usr/bin/dpkg returned an error code (1)
Editing /var/lib/dpkg/info/cron.postrm to remove the first section resolves the
issue.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/8 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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cron depends on:
ii cron-daemon-common 3.0pl1-154
ii init-system-helpers 1.65.2
ii libc62.36-7
ii libpam-runtime 1.5.2-5
ii libpam0g 1.5.2-5
ii libselinux1 3.4-1+b4
ii sensible-utils 0.0.17
Versions of packages cron recommends:
ii msmtp-mta [mail-transport-agent] 1.8.22-1
Versions of packages cron suggests:
pn checksecurity
ii logrotate 3.21.0-1
ii systemd-cron [anacron] 1.15.19-2+b1
Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup
On Sun, Nov 20, 2022, at 12:56, Kevin P. Fleming wrote: > On Sun, Nov 20, 2022, at 08:38, Salvatore Bonaccorso wrote: > >> If that would be helpful, we have some instructions on "simple >> patching and building" the kernel with a additional patches on top >> here: >> >> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > > I found those via another path, and used them :-) Had a few little > issues along the way: failing to set DEBFULLNAME produces a broken > changelog entry so then the build won't run (and leaves the tree in a > broken state as well). Once I solved that problem I was able to make > packages, but the linux-headers-common package didn't get produced, so > I had to use --force-depends-version when installing the packages > (which I knew was safe since the headers had not changed). > > I now have the patched kernel in operation and should know whether the > problem is solved in 24-48 hours. It's been more than 24 hours and connectivity is still in place, and it never lasted this long without the patch. I'm comfortable saying that this patch resolved the problem.
Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup
On Sun, Nov 20, 2022, at 08:38, Salvatore Bonaccorso wrote: > If that would be helpful, we have some instructions on "simple > patching and building" the kernel with a additional patches on top > here: > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 I found those via another path, and used them :-) Had a few little issues along the way: failing to set DEBFULLNAME produces a broken changelog entry so then the build won't run (and leaves the tree in a broken state as well). Once I solved that problem I was able to make packages, but the linux-headers-common package didn't get produced, so I had to use --force-depends-version when installing the packages (which I knew was safe since the headers had not changed). I now have the patched kernel in operation and should know whether the problem is solved in 24-48 hours.
Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup
On Sun, Nov 20, 2022, at 08:15, Salvatore Bonaccorso wrote:
> Hi,
>
> On Sun, Nov 20, 2022 at 02:13:11PM +0100, Salvatore Bonaccorso wrote:
>> Control: tags -1 + moreinfo
>>
>> Hi,
>>
>> On Mon, Nov 14, 2022 at 06:34:43AM -0500, Kevin P. Fleming wrote:
>> > Package: src:linux
>> > Version: 6.0.7-1
>> > Severity: normal
>> > Tags: ipv6
>> >
>> > Dear Maintainer,
>> >
>> > This system has been operating for most of the last 12 months, using
>> > ProxyNDP on its external interface for eight addresses. After
>> > upgrading to the 6.0 kernel series, the kernel stops responding to ND
>> > solicitations for those addresses after startup... it does not happen
>> > immediately, but reliably occurs. When the system is in this state
>> > (not responding to ND solicitations for the proxy addresses), the
>> > proxy addresses are still shown in 'ip neigh show proxy', and the
>> > single non-proxy address on the same interface continues operating
>> > normally.
>> >
>> > Booting the system with the 5.19.0-2 kernel package cures the problem,
>> > with no other changes.
>> >
>> > Example output:
>> >
>> > root@net22:~# ip neigh show proxy
>> > 2607:5300:203:9743::1 dev ve-diw20 proxy
>> > 2607:5300:203:9743::1 dev ve-matrix20 proxy
>> > 2607:5300:203:9743::1 dev ve-ns3 proxy
>> > 2607:5300:203:9743::1 dev ve-ldl20 proxy
>> > 2607:5300:203:9743::1 dev ve-quassel21 proxy
>> > 2607:5300:203:9743::1 dev ve-mastodon22 proxy
>> > 2607:5300:203:9743::1 dev ve-monica21 proxy
>> > 2607:5300:203:9743::1 dev ve-mail20 proxy
>> > 2607:5300:203:9743:4::1 dev enp1s0f0 proxy
>> > 2607:5300:203:9743:1::1 dev enp1s0f0 proxy
>> > 2607:5300:203:9743:8::1 dev enp1s0f0 proxy
>> > 2607:5300:203:9743:5::1 dev enp1s0f0 proxy
>> > 2607:5300:203:9743:3::1 dev enp1s0f0 proxy
>> > 2607:5300:203:9743:2::1 dev enp1s0f0 proxy
>> > 2607:5300:203:9743:6::1 dev enp1s0f0 proxy
>> > 2607:5300:203:9743:7::1 dev enp1s0f0 proxy
>> >
>> > The addresses on enp1s0f0 are the ones which stop responding.
>>
>> Does the following matches your problem?
>>
>> https://lore.kernel.org/netdev/y295+9+jdjqrw...@x1.ze-it.at/
>>
>> Would you be able to test the mentioned patch to verify a fix for your
>> issue? The above changes fixes 0ff4eb3d5ebb ("neighbour: make
>> proxy_queue.qlen limit per-device") introduced in 6.0-rc2.
>
> For reference, the commit would be v2 as applied in netdev as
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=8207f253a097fe15c93d85ac15ebb73c5e39e1e1
While that description does not exactly match my problem, it is so similar as
to almost certainly be the cause. I would be happy to try applying that patch,
but it's been a while since I built a patched Debian kernel so it may take a
couple of days :-)
Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup
Package: src:linux Version: 6.0.7-1 Severity: normal Tags: ipv6 Dear Maintainer, This system has been operating for most of the last 12 months, using ProxyNDP on its external interface for eight addresses. After upgrading to the 6.0 kernel series, the kernel stops responding to ND solicitations for those addresses after startup... it does not happen immediately, but reliably occurs. When the system is in this state (not responding to ND solicitations for the proxy addresses), the proxy addresses are still shown in 'ip neigh show proxy', and the single non-proxy address on the same interface continues operating normally. Booting the system with the 5.19.0-2 kernel package cures the problem, with no other changes. Example output: root@net22:~# ip neigh show proxy 2607:5300:203:9743::1 dev ve-diw20 proxy 2607:5300:203:9743::1 dev ve-matrix20 proxy 2607:5300:203:9743::1 dev ve-ns3 proxy 2607:5300:203:9743::1 dev ve-ldl20 proxy 2607:5300:203:9743::1 dev ve-quassel21 proxy 2607:5300:203:9743::1 dev ve-mastodon22 proxy 2607:5300:203:9743::1 dev ve-monica21 proxy 2607:5300:203:9743::1 dev ve-mail20 proxy 2607:5300:203:9743:4::1 dev enp1s0f0 proxy 2607:5300:203:9743:1::1 dev enp1s0f0 proxy 2607:5300:203:9743:8::1 dev enp1s0f0 proxy 2607:5300:203:9743:5::1 dev enp1s0f0 proxy 2607:5300:203:9743:3::1 dev enp1s0f0 proxy 2607:5300:203:9743:2::1 dev enp1s0f0 proxy 2607:5300:203:9743:6::1 dev enp1s0f0 proxy 2607:5300:203:9743:7::1 dev enp1s0f0 proxy The addresses on enp1s0f0 are the ones which stop responding. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: GIGABYTE product_name: MX33-BS1-V1 product_version: 0100 chassis_vendor: GIGABYTE chassis_version: To be filled by O.E.M. bios_vendor: GIGABYTE bios_version: F04a board_vendor: GIGABYTE board_name: MX33-BS1-V1 board_version: ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4c53] (rev 01) DeviceName: Onboard - Other Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: icl_uncore 00:08.0 System peripheral [0880]: Intel Corporation Device [8086:4c11] (rev 01) DeviceName: Onboard - Other Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:12.0 Serial controller [0700]: Intel Corporation Tiger Lake-H Integrated Sensor Hub [8086:43fc] (rev 11) (prog-if 00 [8250]) DeviceName: Onboard - Other Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Integrated Sensor Hub [1458:1000] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel modules: intel_ish_ipc 00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-H USB 3.2 Gen 2x1 xHCI Host Controller [8086:43ed] (rev 11) (prog-if 30 [XHCI]) DeviceName: Onboard - Other Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H USB 3.2 Gen 2x1 xHCI Host Controller [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-H Shared SRAM [8086:43ef] (rev 11) DeviceName: Onboard - Other Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Shared SRAM [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger Lake-H Serial IO I2C Controller #0 [8086:43e8] (rev 11) DeviceName: Onboard - Other Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Serial IO I2C Controller [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: intel-lpss Kernel modules: intel_lpss_pci 00:16.0 Communication controller [0780]: Intel Corporation Tiger Lake-H Management Engine Interface [8086:43e0] (rev 11) DeviceName: Onboard - Other Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Management Engine Interface [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
Bug#1022810: ddclient: Package installation does not respect systemd preset for disabling service
Package: ddclient Version: 3.9.1-7.1 Severity: normal Dear Maintainer, A systemd preset file is created to ensure that ddclient is not automatically enabled and started, as in: /etc/systemd/system-preset/00-ddclient.service.preset disable ddclient.service The ddclient package is then installed, and does not get enabled, but does get started. The preset file should be respected so that the admin's wishes for managing the service state are taken into account. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.19.0-2-arm64 (SMP w/4 CPU threads) 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ddclient depends on: ii debconf [debconf-2.0] 1.5.79 ii init-system-helpers1.65.2 ii libdata-validate-ip-perl 0.30-1 ii lsb-base 11.4 ii perl 5.34.0-5 ii sysvinit-utils [lsb-base] 3.05-6 Versions of packages ddclient recommends: pn libdigest-sha-perl ii libio-socket-inet6-perl 2.73-1 ii libio-socket-ssl-perl2.075-1 ii perl [libjson-pp-perl] 5.34.0-5 ddclient suggests no packages. -- debconf information: ddclient/password-repeat: (password omitted) ddclient/password: (password omitted) * ddclient/server: * ddclient/username: fsfgfdgd ddclient/interface: * ddclient/names: fgfdfds ddclient/protocol-other: ddclient/proxy: * ddclient/password-mismatch: ddclient/blankhostslist: ddclient/run_mode: As a daemon ddclient/hostslist: * ddclient/protocol: dyndns2 ddclient/daemon_interval: 5m * ddclient/method: Web-based IP discovery service ddclient/web-url: https://api.ipify.org/ ddclient/fetchhosts: Manually ddclient/web: ipify-ipv4 https://api.ipify.org/ * ddclient/service: other
Bug#1012600:
The 2.1.5 packages have made their way into bookworm, and my system is now happily running kernel 5.18 with ZFS.
Bug#1012600:
I'm no expert, but since these packages are in 'contrib' I suspect they don't have the ability to block package upgrades in 'main'. On Sun, Jun 19, 2022 at 5:51 AM Chris Putnam wrote: > > Apologies if this question is well-answered, but why isn't this package > holding back the kernel to 5.17? In my mind an "apt upgrade" should not have > pulled 5.18, especially when the net result may well be an unbootable system. > Surely there's some way to mark this package as broken in tandem with 5.18? > > I'm also quite surprised this wasn't caught in sid before it was pulled into > testing. Is there any form of testing for this package going on in sid?
Bug#1011720: python-apt also fails with this error
Building python-apt 2.3.0 also fails with the same error, so I suspect the cause is in libapt-pkg, not libqapt.
Bug#1005282: Additional confusion
In addition to the confusion mentioned above, 'networkctl status ' reports a 'Link File' path that does not actually exist when the initramfs contains a link file that has been removed from /etc/systemd/network. It reports '/usr/lib/systemd/network/...' as the location, but when the user checks that directory the file is not there (since it was in that location on the initramfs this is logical, but confusing).
Bug#1005282: systemd: Documentation needed for initramfs copies of *.link files
Package: systemd Version: 247.3-6 Severity: normal Dear Maintainer, Recently I renamed some *.link files on a headless server (changing the names inside the files to match), but after rebooting the server I was unable to access it. After much head-scratching I realized that the previous *.link files had been copied into the initramfs during a kernel package installation some time in the past, and the new files conflicted with the old ones, so systemd- networkd could not bring up the network interfaces. After searching the bug tracker I see that a number of people have been caught in this 'trap', and the advice given has been to run update-initramfs after making changes (or adding) *.link files. While that certainly does cure the problem, I can't find any documentation in the installed system which would have lead me to know that I needed to do that. Have I overlooked documentation of this behavior? It doesn't appear in systemd.link(5), and it doesn't appear in the 'networkd' section of README.Debian.gz for the systemd package. I can't be certain that this is Debian-specific behavior (an inquiry about that on the systemd-devel list hasn't elicited any responses), but it's definitely not 'upstream' behavior. Please consider documenting this in at least those two places in a very obvious way. I wish there was a more direct way to notify users that an initramfs update will be required, but short of having a daemon watch /etc/systemd/network for changes I can't think of any way to do that. I'd be happy to provide a patch to add this documentation to those two files if that would be welcome. Thanks for your time and consideration. -- Package-specific info: -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-11-amd64 (SMP w/8 CPU threads) 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-10 ii libapparmor1 2.13.6-10 ii libaudit11:3.0-2 ii libblkid12.36.1-8+deb11u1 ii libc62.31-13+deb11u2 ii libcap2 1:2.44-1 ii libcrypt11:4.4.18-4 ii libcryptsetup12 2:2.3.5-1 ii libgcrypt20 1.8.7-6 ii libgnutls30 3.7.1-5 ii libgpg-error01.38-2 ii libip4tc21.8.7-1 ii libkmod2 28-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2 ii libmount12.36.1-8+deb11u1 ii libpam0g 1.4.0-9+deb11u1 ii libseccomp2 2.5.1-1+deb11u1 ii libselinux1 3.1-3 ii libsystemd0 247.3-6 ii libzstd1 1.4.8+dfsg-2.1 ii mount2.36.1-8+deb11u1 ii systemd-timesyncd [time-daemon] 247.3-6 ii util-linux 2.36.1-8+deb11u1 Versions of packages systemd recommends: ii dbus 1.12.20-2 Versions of packages systemd suggests: ii policykit-10.105-31+deb11u1 ii systemd-container 247.3-6 Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.140 pn libnss-systemd ii libpam-systemd 247.3-6 ii udev 247.3-6 -- no debconf information
Bug#985510: systemd: IPv6 Proxy NDP addresses are lost from interfaces after networkd adds them
Package: systemd Version: 247.3-3 Severity: normal Tags: ipv6 upstream patch Dear Maintainer, After configuring IPv6 Proxy NDP addresses on a link, and not receiving any errors, the addresses disappeared from the link during the system startup process. Restarting systemd-networkd restored the addresses to the link, and the system operated as expected. After extensive debugging, it was determined that in some cases during system startup, a NIC will temporarily lose its 'carrier' (link) status, and when this happens any previously-configured Proxy NDP addresses on the link are removed by the kernel networking stack. systemd-networkd was aware of this state change, but did not re-add the Proxy NDP addresses to the link. This was reported and confirmed upstream here: https://github.com/systemd/systemd/issues/18378 A patch was provided to upstream, and merged here: https://github.com/systemd/systemd/pull/18494 The patch was also merged to the upstream 'stable' branch here: https://github.com/systemd/systemd-stable/issues/89 -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-10 ii libapparmor1 2.13.6-9 ii libaudit11:3.0-2 ii libblkid12.36.1-7 ii libc62.31-9 ii libcap2 1:2.44-1 ii libcrypt11:4.4.17-1 ii libcryptsetup12 2:2.3.4-2 ii libgcrypt20 1.8.7-3 ii libgnutls30 3.7.0-7 ii libgpg-error01.38-2 ii libip4tc21.8.7-1 ii libkmod2 28-1 ii liblz4-1 1.9.3-1 ii liblzma5 5.2.5-1.0 ii libmount12.36.1-7 ii libpam0g 1.4.0-6 ii libseccomp2 2.5.1-1 ii libselinux1 3.1-3 ii libsystemd0 247.3-3 ii libzstd1 1.4.8+dfsg-2.1 ii mount2.36.1-7 ii systemd-timesyncd [time-daemon] 247.3-3 ii util-linux 2.36.1-7 Versions of packages systemd recommends: ii dbus 1.12.20-2 Versions of packages systemd suggests: ii policykit-10.105-30 ii systemd-container 247.3-3 Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.139 pn libnss-systemd ii libpam-systemd 247.3-3 ii udev 247.3-3 -- Configuration Files: /etc/systemd/resolved.conf changed [not included] -- no debconf information
Bug#979226: W: parser_rfc822: Iek! Don't find end of value! when using sid or testing (return of bug 904699)
Package: cdebootstrap-static Version: 0.7.7+b12 Severity: important Dear Maintainer, It appears that bug 904699 has returned; attempting to install testing or sid using cdebootstrap-static fails with the error message in the subject. Based on the analysis in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904699, it appears that one or more packages in testing have extremely long "Provides:" definitions. It may be time to increase READSIZE again. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages cdebootstrap-static depends on: ii curl7.72.0-1 ii debian-archive-keyring 2019.1 ii gpgv2.2.20-1
Bug#935336: jsvc cannot find libjvm.so as installed by JDK/JRE packages
This problem is caused by the location of libjvm.so. For example, when I install openjdk-11-jre-headless:arm64, I get this directory: /usr/lib/jvm/java-11-openjdk-arm64/lib/server which contains libjvm.so (among other files). However, jsvc looks in: /usr/lib/jvm/java-11-openjdk-arm64/lib/$(uname -m)/server This means it cannot find the necessary library. I have been working around this by adding a subdirectory under `lib` named the same as `uname -m` reports, and then creating a symlink `server` in that directory which points to the `server` directory one level up.
Bug#388756: Comments from Digium
This issue was just brought to my attention, so I'll try to clear up any confusion involved here regarding the wct4xxp driver. First, even though the .ima file is included in a tarball that contains a GPL license, it is not covered by that license. It is also not directly part of the program in that form. The build process does convert the firmware into a header file and include it into the module, though, which is (to some degree) a violation of the GPL on the kernel. Given that kernel maintainers' stance on this in the past, we are not terribly concerned about it. It also violates the GPL on Zaptel itself, but since we are the GPL licensors of Zaptel and also the distributors of the infringing code, we are not concerned about that either. Second, the driver already contains support for userspace loading of the firmware, and it's trivial to modify the Makefile/driver to _NOT_ build the firmware into the kernel module at all. This was done specifically so that people could avoid this GPL issue. The module is completely usable without the firmware, as long as the user does not have the optional Octasic module on their TE4XXP card (and most users do not have those modules). My recommendation would be for Debian to build/ship wct4xxp.ko with only userspace firmware loading enabled (not the build-time linking of the firmware into the module), and then package the firmware itself in a non-free package that just puts the firmware into the proper place for the userspace firmware loader to find it. -- Kevin P. Fleming Senior Software Engineer Digium, Inc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378354: install of php4-cli after php4-mysql does not allow cli php to use mysql
Package: php4-mysql Severity: important (all php4 packages involved here are 4.4.2-1.1) I installed (via apt-get) php4 and php4-mysql. After realizing that I also needed the cli version of php4, I installed php4-cli. However, PHP scripts run from the cli could not make MySQL connections, reporting that the MySQL 'connect' function was not found. Removing php4-mysql and reinstalling it cured the problem. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.16 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
