Bug#1077854: libcurl4t64: SIGPIPE leaks in some cases
Package: libcurl4t64 Version: 8.9.1-1 Severity: critical Affects: transmission-daemon transmission-gtk Dear maintainers, Please look at the upstream bug : https://github.com/curl/curl/issues/14344 On my system, this makes transmission-gtk crash unexpectedly after a short time, without any error message. According to [1], it also affects transmission-daemon. [1] https://github.com/transmission/transmission/issues/7035 Setting severity to critical because it affects other packages (and to trigger apt-listbugs for people who use it). Regards, -- Raphaël Halimi
Bug#1077765: openssh: can't be started by ssh.socket anymore
Le 02/08/2024 à 00:12, Colin Watson a écrit : My best guess is that this has something to do with the refactoring of sshd into a listener binary and a per-session binary, which touched the re-exec path that's also involved in socket activation. I'll try to figure it out, but it may take a little while. I think we should probably also add an autopkgtest for the socket activation case. Since it's not the default and not otherwise automatically tested right now, it's easy for it to break accidentally. Dear maintainers, I confirm that this new upload fixes the problem. Thank you for acting so quickly ! :) Regards, -- Raphaël Halimi
Bug#1077765: openssh: can't be started by ssh.socket anymore
Package: openssh Version: 1:9.8p1-1 Severity: serious Dear maintainers, Since the latest openssh upgrade, ssh.socket service can't start ssh.service. It fails with the error message "fatal: Cannot bind any address", and gives up after 5 tries (which is expected), leaving the machine unreachable. ssh.service on its own starts normally. This is a regression, as previous versions of ssh.socket were able to start the service without problems. A simple workaround is to disable ssh.socket and enable ssh.service, but it would be nice to have systemd socket activation working again. Severity set to serious since it can render machine where ssh.socket is enabled unreachable after an upgrade (before ssh.service is restarted, which needs physical access). Regards, -- Raphaël Halimi
Bug#1068591: systemd-container: doesn't list a default package for default-dbus-system-bus dependency
Le 07/04/2024 à 19:34, Michael Biebl a écrit : As you correctly noticed, this is a bug/fault in debootstrap. I don't think individual packages should work around that, so I'm included to close this as wontfix (or reassign/merge to debootstrap). Fair enough, I understand. Do you want me to reassign it ? Fwiw, you might use an alternative debootstrap tool like mmdebstrap which works properly in that regard. I didn't know about this tool. Thanks for the tip :) Regards, -- Raphaël Halimi
Bug#1068591: systemd-container: doesn't list a default package for default-dbus-system-bus dependency
Package: systemd-container Version: 249.6-1 Severity: minor Dear developers, systemd-container lists "default-dbus-system-bus | dbus-system-bus" as a dependency. This is usually correct since APT is smart enough to resolve the dependency, but that's not the case with debootstrap. Since systemd-container is usually needed in systemd-nspawn containers, it should be installed at debootstrap time, but currently, running debootstrap with "--include=systemd-container" fails because no D-Bus implementation is pulled in as dependency. It used to work in versions older than 249.6-1 (before the dependency was changed from the real "dbus" package to "default-dbus-system-bus | dbus-system-bus" virtual packages, so it may qualify as a regression). Using "--include=systemd-container,dbus" (or dbus-broker) works. Could the real dbus package (since it's currently the default D-Bus implementation in Debian) be listed as an alternative dependency (and ideally, in bookworm too) ? Note 1: one could think that it's debootstrap's fault for not resolving dependencies on virtual packages; indeed, it has already been reported several times (#878961, merged with #827602 and #931760; as well as Launchpad #86536) unfortunately never fixed yet; but, IMHO, since systemd-container is usually needed in systemd-nspawn containers, and (except for the host) is usually installed via debootstrap, it makes it kind of a special case, in the sense that systemd (as a whole) should take care that systemd-nspawn containers can be built and started easily. Note 2: dbus-broker has the reputation of being better than dbus on various points, and could be considered as a clever choice for containers, but systemd-container currently lists "default-dbus-system-bus" as first alternative, which is provided by "dbus". Regards, -- Raphaël Halimi
Bug#772523: preseeding get_domain using DHCP is broken
(sorry, accidental Ctrl+Enter...) With Bookworm, it totally broke. If the preseeding happens after netcfg (url=...), when setting the hostname from the kernel parameters, d-i keeps it, but does not get the domain from DHCP as before; only setting both a hostname and a domain name makes things work (but now keeps the domain from the kernel parameters, which may be more appropriate). If the preseeding happens before netcfg (file=...), whatever hostname and/or domain is set in the kernel paramaters, and whatever domain the DHCP sends, d-i uses the values from the preseed file (unassigned-hostname and unassigned-domain). So, currently, the only way to make things work with an installation medium, is to unset both netcfg/get_hostname and netcfg/get_domain in the preseed file, and set hostname and domain in the kernel parameters. (for convenience, I attached a text file in markdown format with the results of these tests). This is a big change from the behavior of previous netcfg versions (I use preseeding since Wheezy, both with PXE or installation media), and this new behavior makes things more complicated: before, we just configured bogus values in the preseed file, and if the machine was not registered in the DNS but the DHCP provided a valid domain name, specifying a hostname in the kernel parameters was sufficient. Now, we have to specify both the hostname and the domain name in the kernel command line (think of non-QWERTY keyboards...), and this makes me consider this a severe regression. It also partly contradicts the various documentations (like the ones mentioned above). I sincerely hope this will be fixed in a forthcoming point release. Feel free to ask me if you need to test stuff, I have a suitable environment to test preseeding for both PXE or installation media. Best regards, -- Raphaël HalimiBullseye netcfg before preseed (url=...) ### cmdline: none hostname=debian, no domain name ### cmdline: hostname= hostname from cmdline, domain from DHCP ### cmdline: hostname=, domain= hostname from cmdline, domain from DHCP (different from cmdline) preseed before netcfg (file=...) ### cmdline: none hostname and domain from preseed file (unassigned-hostname, unassigned-domain) ### cmdline: hostname= hostname from cmdline, domain from DHCP ### cmdline: hostname=, domain= hostname from cmdline, domain from DHCP (different from cmdline) Bookworm netcfg before preseed (url=...) ### cmdline: none hostname=debian, no domain name ### cmdline: hostname= hostname from cmdline, no domain ### cmdline: hostname=, domain= hostname and domain from cmdline preseed before netcfg (file=...) ### cmdline: none hostname and domain from preseed file (unassigned-hostname, unassigned-domain) ### cmdline: hostname= hostname and domain from preseed file (unassigned-hostname, unassigned-domain) ### cmdline: hostname=, domain= hostname and domain from preseed file (unassigned-hostname, unassigned-domain)
Bug#1060897: furo: documentation generated with Debian's furo package doesn't work standalone
Package: furo Version: 2023.09.10+dfsg-2 Severity: important X-Debbugs-Cc: raph...@freexian.com Hello Georges, I was trying to use "furo" (as packaged in Debian) to build the debusine documentation but I figured out that multiple things were not working right: https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html - I have unwanted margins around the page, that's because "normalize.css" is not found, the Debian package hardcodes "/javascript/normalize.css/normalize.css" as the path... it's totally unreasonable to make that assumption for random documentation. It's great to reuse the Debian packaged version, but it should be reused in a way where it gets duplicated in the generated documentation so that the documentation is self-contained. - the dark/light theme switcher is hidden because I have a ".no-js" class that is not removed by _static/scripts/furo.js because that script fails on the first import line (Uncaught SyntaxError: import declarations may only appear at top level of a module). This line has been patched by the Debian packaging, but I'm not sure if the change is the source of the problem. Cheers, -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.8-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 furo depends on: ii node-normalize.css 8.0.1-5 ii python3 3.11.6-1 ii python3-bs4 4.12.2-2 ii python3-pygments2.15.1+dfsg-1 ii python3-sphinx 7.2.6-3 ii sphinx-basic-ng 1.0.0~beta2-1 furo recommends no packages. furo suggests no packages. -- no debconf information
Bug#1058758: Still not fixed for ThinkPad Compact USB Keyboard with TrackPoint (not II)
Dear developers, Unfortunately, after upgrading kernel to 6.6.8 on my Sid desktop (at home), I still witness the bug (middle click performed when releasing middle button after wheel emulation) with my ThinkPad Compact USB Keyboard with TrackPoint (old model, not II). Those spurious clicks are very annoying, since they can open links in new tabs when scrolling in Firefox, or pasting text when scrolling in terminals, or other unwanted stuff. A also have this problem at work, on a Bookworm desktop. Why did those recent patches ([1], [2], [3] oldest is two months old) end up in a stable release's kernel ? They clearly cause a very annoying regression, on a fairly high number of installations (statistically, old ThinkPad Compact USB Keyboard is probably much more widespread than the recent ThinkPad TrackPoint Keyboard II). [1] https://github.com/torvalds/linux/commit/46a0a2c96f0f47628190f122c2e3d879e590bcbe [2] https://github.com/torvalds/linux/commit/2f2bd7cbd1d1548137b351040dc4e037d18cdfdc [3] https://github.com/torvalds/linux/commit/43527a0094c10dfbf0d5a2e7979395a38de3ff65 Would it be possible to revert them at least in Bookworm's kernel, until they're stabilized and working for all ThinkPad keyboards ? Regards, -- Raphaël Halimi
Bug#1042818: firmware-amd-graphics: GPU freezes, monitors not working with kernel 6.0 and version 20230625-1
Package: firmware-amd-graphics Followup-For: Bug #1042818 X-Debbugs-Cc: alphar...@gmail.com Dear Maintainer, I think the most relevant new information is that after installing 20230625-1 from 20230515-3 on kernel version 6.0.0-2, I had the random freezes mentioned above. Also, only my DP monitor would output anything, and my wayland compositor would try to make sense of them in a loop, leading to a very unresponsive system (freezes, missed keystrokes, repeated keystrokes) and other things like keyboard settings not being applied because the config reload process got interrupted. I tried upgrading to linux 6.5.0-5, which didn't do anything. Still on that version, I manually installed 20230515-4 (instead of the original -3, but I don't think this makes a difference) and everything is working fine. The workaround for drm kernel parameters did not work for me unfortunately. Thanks, Raphaël Gomès -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-amd-graphics depends on no packages. firmware-amd-graphics recommends no packages. Versions of packages firmware-amd-graphics suggests: ii initramfs-tools 0.142 -- debconf-show failed
Bug#1054564: apache2: mod_proxy_connect insecure default server-wide AllowCONNECT value
Package: apache2
Version: 2.4.56-1~deb11u2
Severity: normal
X-Debbugs-Cc: raphael.d...@gmail.com
Dear Maintainer,
# Context
For years, one of my SSL vhost (on :443) has been relying mod_proxy_http to
(safely)
forward some requests to a backend, acting as a reverse-proxy.
```
# Something like
ProxyRequests On
SSLProxyEngine On
RewriteRule ^/.well-known/.*$ "https://gitlab-foobar/%{REQUEST_URI}; [P,L]
```
Recently, I experienced the need to (safely) forward some requests (from
another server I own)
through this server (because of some network/geoblocking problem).
I enabled `mod_proxy_connect` and (safely) configured a forward-proxy on :80
(using `Require valid-user / ip`).
```
# Something like
ProxyRequests On
Authtype Basic
AuthUserFile ...
p Require valid-user
Require ip ...
```
# Problem
While this :80 forward-proxy vhost was secure, I later discovered, that
the original (and almost forgotten) vhost had incidentally become an
open-proxy (!)
The reasons are:
- mod_proxy_connect is globally enabled (affects all vhosts)
- AllowCONNECT defaults to "443 563" (affects all vhosts)
Said otherwise, *any* secure reverse-proxy vhost configuration become de-facto
an insecure open forward-proxy vhost as soon as `mod_proxy_connect` is
globally enabled.
This sounds contrary to best security practices.
(and I bet more than one server out there is silently affected by this
insecure-by-default
configuration)
# Proposed solution
I suggest to add a server-wide `AllowCONNECT 0` directive inside
`/etc/apache2/mods-available/proxy_connect.load` (virtually disabling CONNECT)
so that individual vhosts relying on it would have to explicitely set the value
at the vhost-level.
It would be more logical (scope/side-effects) and avoid holes being punched
into existing
(and otherwise secure) reverse-proxy vhosts.
# Additional notes
To cap it all my proxy-enabled vhost was the first one (lexicographically
speaking) making it the destination of all the random internet SSL traffic
scanners.
Google-friendly list of typical log messages that should raise flags:
> AH00898: Connect to remote machine blocked returned by...
> AH00939: CONNECT: attempt to connect to ...:443 (...) failed
> AH10221: proxy: CONNECT: client flushing failed (-102)
> AH10221: proxy: CONNECT: origin flushing failed (-102)
-- Package-specific info:
-- System Information:
Debian Release: bullseye
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.2.0-35-generic (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apache2 depends on:
ii apache2-bin 2.4.56-1~deb11u2
ii apache2-data 2.4.56-1~deb11u2
ii apache2-utils2.4.56-1~deb11u2
Versions of packages apache2 recommends:
pn ssl-cert
Versions of packages apache2 suggests:
pn apache2-doc
pn apache2-suexec-pristine | apache2-suexec
Versions of packages apache2 is related to:
ii apache2 2.4.56-1~deb11u2
ii apache2-bin 2.4.56-1~deb11u2
-- Configuration Files:
/etc/apache2/apache2.conf changed [not included]
-- no debconf information
--
GPG id: 0xF41572CEBD4218F4
Bug#1054532: autopkgtest: allow use of an alternate APT solver
Package: autopkgtest Version: 5.30 Severity: wishlist X-Debbugs-Cc: raph...@freexian.com The current way to schedule autopkgtest tests on reverse dependencies prior to testing migration is not really satisfying: - it relies entirely on APT pinning - you don't have any control on the version used While working on autopkgtest's integration in debusine, I tried to improve this by submitting the precise version of the updated package that I want to validate on the command line (together with the .deb of the package providing the autopkgtests). That works well as the packages gets integrated in the local apt repository prepared. However this doesn't work when the updated package has dependencies that can only be solved in the extra repository. The requirement to use --apt-default-release to stick to the base release means that apt will refuse to install the dependencies from any other repository (unless we use --pin-packages to increase their priority). FTR here are the tries we made to reach that conclusion: https://salsa.debian.org/freexian-team/debusine/-/issues/188 I'm looking for a solution where we don't have to do that analysis of the dependency tree to figure out the set of deb that must be selected. It might not be a big issue in the context of britney, but it's definitely a showstopper in many other contexts. Until apt gets improved (which might happen in time for trixie as juliank told me he has plans to work on a better solver for APT), the best solution is likely to make it possible to use an external APT solver in that special case, just like buildd are doing for experimental builds. In https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300/diffs#note_434295 Paul Gevers said he considered the aspcud resolver but he decided against as it's not the default. I agree that it should not be the default but I still think that we should be able to opt-in to that solution for such tests where we want to run a mixed environment and not have to provide the exact combination of packages that have to be taken from the extra repository. This requires to install apt-cudf and aspcud in the image and then use a command line like this (see man apt-cudf): # apt-get --solver aspcud -o APT::Solver::Strict-Pinning=false -o APT::Solver::aspcud::Preferences="-count(solution,APT-Release:~/[an]=$extra,/),-removed,-changed,-new" install $package I used a regex matching APT-Release here to match both codename (n=) and suites/archive (a=) and I anchored with the trailing comma to be sure to match the full name. FTR the APT-Release field looks like this in the EDSP data structure: APT-Release: v=12.2,o=Debian,a=stable,n=bookworm,l=Debian,c=main,b=amd64 or APT-Release: o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64 If we have multiple extra repositories, we will likely want to have $extra be a regex like "(codename1|codename2)". Note that this is not tested and just based on my personal research so far. For reference, the buildd are using the following criteria for solving build deps of experimental packages: https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/blob/production/modules/buildd/templates/sbuild.conf.erb $aspcud_criteria = '-count(solution,APT-Release:=/experimental/),-removed,-changed,-new'; Thanks for considering! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 autopkgtest depends on: ii apt-utils 2.7.6 ii libdpkg-perl1.22.0 ii mawk1.3.4.20230808-1 ii procps 2:4.0.4-2 ii python3 3.11.4-5+b1 ii python3-debian 0.1.49 Versions of packages autopkgtest recommends: ii autodep8 0.28 ii fakeroot 1.32.1-1 Versions of packages autopkgtest suggests: pn docker.io pn fakemachine pn lxc pn lxd ii ovmf 2023.05-2 pn ovmf-ia32 ii podman 4.6.2+ds1-4 ii python3-distro-info 1.5 ii qemu-efi-aarch64 2023.05-2 ii qemu-efi-arm 2023.05-2 ii qemu-system 1:8.1.2+ds-1 ii qemu-utils 1:8.1.2+ds-1 ii schroot 1.6.13-3+b2 ii util-linux 2.39.2-4 ii vmdb20.27+really.0.26-1 ii zerofree 1.1.1-1 -- no debconf information
Bug#1052510: abook: double free detected in tcache 2
> On Sat, Sep 23, 2023 at 04:53:18PM +0200, Alejandro Colomar wrote: > > Package: abook > > Version: 0.6.1-3 > > Severity: normal > > Tags: upstream > > X-Debbugs-Cc: a...@kernel.org > > > > Dear Maintainer, > > > > abook(1) is freeing twice. https://sourceforge.net/p/abook/git/ci/b897f8a0d8e02bcd0b8d0296b4893d2b35d6de5a/
Bug#1053892: lintian: Stop emitting masked tags
Package: lintian Version: 2.116.3 Severity: wishlist X-Debbugs-Cc: raph...@freexian.com I just discovered the existence of masked tags and of the "Screen" mechanism to exclude some tags. I also notice that they are displayed together with overriden tags when you use --show-overrides. Yet they are very different. I believe that a tag that lintian decided to suppress should simply never be emitted, not even as a masked tag. Thus I would suggest to stop emitting masked tags. But if you disagree with this, it might make sense to offer the possibility to handle masked tags separately from overriden tags. (Again this is a followup from a discussion here https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300#note_434002) -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lintian depends on: ii binutils2.41-5 ii bzip2 1.0.8-5+b1 ii diffstat1.65-1 ii dpkg1.22.0 ii dpkg-dev1.22.0 ii file1:5.45-2 ii gettext 0.21-13+b1 ii gpg 2.2.40-1.1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.15.0-1 ii libapt-pkg-perl 0.1.40+b2 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b1 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b1 ii libclone-perl 0.46-1 ii libconfig-tiny-perl 2.29-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.37-1 ii libdata-dpath-perl 0.58-2 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2+b1 pn libdigest-sha-perl ii libdpkg-perl1.22.0 ii libemail-address-xs-perl1.05-1+b1 ii libencode-perl 3.19-1+b1 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-2 ii libipc-run3-perl0.048-3 ii libjson-maybexs-perl1.004005-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b1 ii libperlio-utf8-strict-perl 0.010-1 ii libproc-processtable-perl 0.636-1 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.004+ds-1 ii libsereal-encoder-perl 5.004+ds-1 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.29-1 ii libterm-readkey-perl2.38-2+b1 ii libtext-levenshteinxs-perl 0.03-5+b1 ii libtext-markdown-discount-perl 0.16-1 ii libtext-xslate-perl 3.5.9-1+b2 ii libtime-duration-perl 1.21-2 ii libtime-moment-perl 0.44-2+b1 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-2 ii liburi-perl 5.21-1 ii libwww-mechanize-perl 2.17-1 ii libwww-perl 6.72-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b1 ii libyaml-libyaml-perl0.86+ds-1 ii lzip [lzip-decompressor]1.23-6 ii lzop1.04-2 ii man-db 2.12.0-1 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.36.0-9 ii t1utils 1.41-4 ii unzip 6.0-28 ii xz-utils5.4.4-0.1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.41-5 ii libtext-template-perl 1.61-1 -- no debconf information
Bug#1053891: lintian: Document the existence of classification tags in the manual page
Package: lintian Version: 2.116.3 Severity: wishlist X-Debbugs-Cc: raph...@freexian.com Hello, the conversation in https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300#note_434002 led me to realize that as a simple lintian user reading the manual page, you can't discover the existence of classification tags and you can't figure out the syntax to enable the display of those tags. Please improve the manual page to explain what classification tags are, that they are considered like normal tags with a priority lower than everything else and that you can enable them with "--display-level +=classification". BTW in general, the whole explanation about --display-level is pretty confusing, it's not clear to me what "S|C|S/C" is supposed to mean for instance. And there's no global sorted list of usable severity so it's hard to predict the result of --display-level '>=classification'. Cheers, -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lintian depends on: ii binutils2.41-5 ii bzip2 1.0.8-5+b1 ii diffstat1.65-1 ii dpkg1.22.0 ii dpkg-dev1.22.0 ii file1:5.45-2 ii gettext 0.21-13+b1 ii gpg 2.2.40-1.1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.15.0-1 ii libapt-pkg-perl 0.1.40+b2 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b1 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b1 ii libclone-perl 0.46-1 ii libconfig-tiny-perl 2.29-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.37-1 ii libdata-dpath-perl 0.58-2 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2+b1 pn libdigest-sha-perl ii libdpkg-perl1.22.0 ii libemail-address-xs-perl1.05-1+b1 ii libencode-perl 3.19-1+b1 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-2 ii libipc-run3-perl0.048-3 ii libjson-maybexs-perl1.004005-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b1 ii libperlio-utf8-strict-perl 0.010-1 ii libproc-processtable-perl 0.636-1 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.004+ds-1 ii libsereal-encoder-perl 5.004+ds-1 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.29-1 ii libterm-readkey-perl2.38-2+b1 ii libtext-levenshteinxs-perl 0.03-5+b1 ii libtext-markdown-discount-perl 0.16-1 ii libtext-xslate-perl 3.5.9-1+b2 ii libtime-duration-perl 1.21-2 ii libtime-moment-perl 0.44-2+b1 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-2 ii liburi-perl 5.21-1 ii libwww-mechanize-perl 2.17-1 ii libwww-perl 6.72-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b1 ii libyaml-libyaml-perl0.86+ds-1 ii lzip [lzip-decompressor]1.23-6 ii lzop1.04-2 ii man-db 2.12.0-1 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.36.0-9 ii t1utils 1.41-4 ii unzip 6.0-28 ii xz-utils5.4.4-0.1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.41-5 ii libtext-template-perl 1.61-1 -- no debconf information
Bug#1053789: sbuild: should support --env=VAR=VALUE command line option like autopkgtest
Package: sbuild Version: 0.85.3 Severity: wishlist X-Debbugs-Cc: raph...@freexian.com Hello, it would be nice if sbuild supported the --env=VAR=VALUE command line option like autopkgtest: --env=VAR=value Set arbitrary environment variable in the build and test. Can be specified multiple times. I know that sbuild keeps the current environment but it does filter it and getting rid of the filter requires setting up a configuration file I assume. A bit complicated compared to the expressivenes of the above command line option that clearly says "yes I want that variable". This suggestion is the result of some design work in debusine where we want to make it easy for Debian developers to experiment with changes that can affect many packages. And we believe that the possibility of setting up an arbitrary environment variable is important in that context. https://salsa.debian.org/freexian-team/debusine/-/issues/180 Thank you for considering that idea! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 sbuild depends on: ii adduser 3.137 ii libsbuild-perl 0.85.3 ii perl5.36.0-9 Versions of packages sbuild recommends: ii autopkgtest 5.30 ii debootstrap 1.0.132 ii schroot 1.6.13-3+b2 ii uidmap 1:4.13+dfsg1-2 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.47.0-2+b1 ii kmod 30+20230601-2 ii wget 1.21.4-1+b1 -- no debconf information
Bug#1051229: tlp 1.6 doesn't conflict with power-profile-daemon anymore
Control: tags -1 wontfix Control: close -1 Dear Sebastien, Thanks for your suggestion and your patch, but I prefer to follow upstream's advice and keep the conflict in place to disallow co-installation of TLP and PPD. Regards, -- Raphaël Halimi
Bug#1028897: fontconfig: wrong name for the Noto monospace font
Le 20/08/2023 à 22:15, Gunnar Hjalmarsson a écrit : Thus, the default font for the "Monospace" alias will depend on the installed packages. That's always the case, isn't it? The output of "fc-match" or "fc-match mono" depends on a combo of available fonts and the font configuration. Yes, but what I meant was that it's a change from before 2.14, when configuration and dependencies made sure that everyone had the same default (DejaVu Sans Mono). Regards, -- Raphaël Halimi
Bug#1028897: fontconfig: wrong name for the Noto monospace font
Le 20/08/2023 à 12:33, Gunnar Hjalmarsson a écrit :
So, I just downloaded NotoSansMono-Regular.ttf from its new home [1]
(the old repository in the Debian copyright file has been archived),
opened it in font-viewer and... Sadly, the spacing is still
"Proportional" and not "Monospace" :(
Thanks for doing that. So we will probably need to live with it for the
foreseeable future. And yes, it's a bit sad.
No problem :)
Anyway, I'm now convinced that the status of Noto Sans Moto motivates a
change of the default monospace font in Debian. Well, you and I haven't
agreed on what to put there instead, so how about a compromise where we
pick both? :)
https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/6fae069d
As I understand it, this will make fontconfig select DejaVu Sans Mono on
most desktop installations (since libreoffice depends on both sets), and
Noto Mono on a handful of installations, namely, minimal installations
which will have only fonts-noto-{core,mono} installed, and not
fonts-dejavu-{core,mono}.
Thus, the default font for the "Monospace" alias will depend on the
installed packages. At least, since Noto Sans Mono is listed after Noto
Mono, and since they're both shipped by the same package, the latter
will never be selected, which will fix the core of the problem - huge
and hard-to-read terminals.
I'm okay with that. Thanks for fixing it :)
While I still hesitate, since the change affects so many users, I have
decided to act. After all we are in the beginning of the trixie
development cycle, so there is plenty of time to change it later. By
making the change in unstable and testing, we expose it to the users.
Many will probably not even notice and some will like it. And if some
users disapprove of the change, the broader discussion we haven't had
may happen later.
Yes, let's see what users think of the change. I have good hope that
most people will be satisfied.
Thanks for your perseverance!
You're welcome :)
Regards,
--
Raphaël Halimi
Bug#1028897: fontconfig: wrong name for the Noto monospace font
Le 19/08/2023 à 16:04, Gunnar Hjalmarsson a écrit : As you may have seen, I submitted <https://bugs.debian.org/1050043> and fixed it. Thanks for mentioning it! Yes I saw that, you CC'd me ; and thank you for acting on this problem. Seeing that the time I spend on writing detailed e-mails to the BTS is not in vain, is very much appreciated :) On 2023-08-17 15:34, Raphaël Halimi wrote: IMHO, if Debian wants to follow the upstream fontconfig default to use the Noto fonts, the system should work without the DejaVu packages installed, so it would make more sense to patch fontconfig to use Noto Mono as a default and keep the "Noto look" across the whole system, than to go back to DejaVu Sans Mono. As regards "Noto look", and despite of the name "Noto Mono", personally I think that DejaVu Sans Mono aligns better with Noto Sans/Serif than Noto Mono does. Look at the letter 'g', for instance. Also: * If Debian would change the default monospace font, we would not follow upstream. That's true whether we would pick Noto Mono or DejaVu Sans Mono. As I said, having a "pure" Noto set or a mix of Noto and DejaVu set by default is a personal opinion (I did state "IMHO") and I admit I didn't compare those fonts thoroughly to see which one of Noto (Sans) Mono or DejaVu Sans Mono goes better with Noto Sans/Serif. I took a guess purely based on the fact that fonts distributed as parts of the same set are supposed to go along. Since you're part of the team who maintains the package, I won't discuss your decision on that point (but I'd still prefer full-Noto or full-DejaVu over a mix of both, although I agree this may be a purely psychological bias). * There were reasons why I broke out DejaVu Sans Mono to its own package. :) Given that change, it's possible to install fonts-dejavu-mono without installing fonts-dejavu-core. This remark made me read the Debian changelog and query #1043271. Thanks for clarifying that. For those reasons I disagree with the quoted statement. As I said, we have a divergence of opinion, but as the maintainer of this package, you have the final word. Another question is if the Noto Sans Mono deficiency is important enough to motivate a Debian level change in this respect. I don't know. @Fabian, I sent this reply to you as well in the hope to broaden the discussion a bit. Here, I don't agree ; not on bringing more people in the discussion (the more thinking minds, the wiser the final decision will be), but on the very problem itself: did you see the screenshots I provided ? Won't you agree that the current default configuration is ugly, whether with Gnome Terminal or XTerm ? (I know that for XTerm it's not really the "default configuration" since it uses bitmap fonts by default, but still, I consider the font resolved by the "Monospace" alias for TrueType fonts to be some kind of default). It's worth mentioning that the fonts-noto packages in Debian ship almost 3 years old fonts. An update to latest upstream would be highly desirable. Possibly Noto Sans Mono has improved. I didn't know that. Thanks for mentioning it. So, I just downloaded NotoSansMono-Regular.ttf from its new home [1] (the old repository in the Debian copyright file has been archived), opened it in font-viewer and... Sadly, the spacing is still "Proportional" and not "Monospace" :( [1] https://github.com/notofonts/notofonts.github.io/blob/main/fonts/NotoSansMono/hinted/ttf/NotoSansMono-Regular.ttf After all this time, I seriously doubt that that Google intends to fix that. Maybe we could open an issue in the new Github repository ? My hopes are not high, though. I'm afraid it will be ignored like the ones before. Regards, -- Raphaël Halimi
Bug#1042004: systemd: systemd-run evaluates variables enclosed between single quotes
Package: systemd
Version: 254~rc1-2
Affects: pbuilder
Dear maintainers,
Yesterday I tried to build a package with pbuilder and it resulted in an
error when trying to satisfy build dependencies:
Referenced but unset environment variable evaluates to an empty string:
Version
dpkg-query: error in show format: may not be empty string
/usr/lib/pbuilder/pbuilder-satisfydepends-apt checks for apt's version
with the function package_version_is_older_than, which is defined in
/usr/lib/pbuilder/pbuilder-modules:
dpkg --compare-versions "$($CHROOTEXEC dpkg-query -W
--showformat='${Version}' "$1")" lt "$2"
CHROOTEXEC is defined in /usr/lib/pbuilder/pbuilder-checkparams:
CHROOTEXEC="chroot $BUILDPLACE "
And then (if systemd is running and its version is greater than 215) :
systemctl_run=(
systemd-run
--quiet
--scope
--description="pbuilder_${PBUILDER_OPERATION}${1:+_"$(basename "$1")"}"
--slice="$SYSTEMD_SLICE"
)
CHROOTEXEC="${systemctl_run[*]} $CHROOTEXEC"
So the resulting systemd-run command evaluates '${Version}' (in the
dpkg-query command) to an empty string. It shouldn't be evaluated since
it's enclosed between single quotes.
Downgrading systemd to version 253.5-1 fixes the problem.
Regards,
--
Raphaël Halimi
Bug#1036617: ITP: python-procset -- pure Python implementation of the interval set data structure
Package: wnpp Severity: wishlist Owner: Raphaël Bleuse X-Debbugs-Cc: debian-de...@lists.debian.org, c...@research.bleuse.net * Package name: python-procset Version : 1.0-1 Upstream Contact: Raphaël Bleuse * URL : https://gitlab.inria.fr/bleuse/procset.py * License : LGPL Programming Lang: Python Description : pure Python implementation of the interval set data structure An interval set is a memory-efficient representation of closed-interval sets. A ProcSet is an hybrid between a set and a list of indexes. More precisely, a ProcSet object is an ordered collection of unique non-negative int. It supports most of set operations: notably membership testing, mathematical operations such as intersection, union, and (symmetric) difference; with the additional ability to access its elements by position. Such a data structure is used when managing sets of resources, and is especially useful when writing schedulers.
Bug#1036034: plymouth: tribar theme should be treated as other text themes
Package: plymouth
Version: 0.9.5-3
Tags: patch
Dear developer,
Plymouth ships text themes, and graphical themes in a separate
plymouth-themes package, which have many more dependencies.
Installing only plymouth (without plymouth-themes) and selecting the
tribar theme currently makes update-initramfs fail because it can't find
the file /etc/fonts/fonts.conf (shipped with fontconfig-config), which
tribar doesn't need at all, since it's a actually a text theme
(correctly shipped with the main plymouth package, and not in the
plymouth-themes package).
This probably stayed off the radar since plymouth is rarely installed on
a system without a desktop (and thus, no fonts). That's why the
probability to mess up the initramfs is quite low, but it's nevertheless
a possibility.
This can be easily fixed by adding tribar to the dependencies test in
the initramfs hook (see provided patch).
I tested it in a VM on a standard headless system (bullseye), with and
without encrypted root; the text prompts for entering the passphrase and
reporting success or failure are correctly displayed.
Regards,
--
Raphaël Halimi--- debian/local/plymouth.hook.orig 2023-02-01 18:20:20.0 +0100
+++ debian/local/plymouth.hook 2023-05-13 19:49:20.260777891 +0200
@@ -86,7 +86,7 @@
fi
case "${THEME_NAME}" in
- text|details)
+ text|details|tribar)
;;
Bug#1034233: tlp: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Control: fixed -1 1.5.0-2 Control: thanks Forgot to mention the closed bug in the changelog. -- Raphaël Halimi
Bug#1034384: unblock: tlp/1.5.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@packages.debian.org
Control: affects -1 + src:tlp
Please unblock package tlp
[ Reason ]
The 1.5.0-1 version includes a systemd service file in /usr/lib/systemd,
which is not detected by debhelper during package build, so the sections
that are normally automatically added in the maintainer scripts to
enable the service are not added. See bug #1034233 for more information.
(sadly, as I write this, I just realized I forgot to mention the
"Closes" field in the changelog; I'll have to close the bug manually).
[ Impact ]
If the unblock isn't granted, a user installing TLP for the first time
on Bookworm won't have it enabled during install, and will have to
enable the service manually (it seems that users who upgrade from a
version which had the service previously enabled are not affected).
[ Tests ]
I tested installing the package on my Bookworm laptop, and also
upgrading from current Bookworm version, and it works as expected.
[ Risks ]
I don't believe there are any risks involved.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock tlp/1.5.0-2
Regards,
--
Raphaël Halimi[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /lib/systemd/system/tlp.service
-rw-r--r-- root/root /lib/udev/rules.d/85-tlp.rules
-rwxr-xr-x root/root /lib/elogind/system-sleep/49-tlp-sleep
-rwxr-xr-x root/root /lib/systemd/system-sleep/tlp
-rwxr-xr-x root/root /lib/udev/tlp-usb-udev
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/lib/systemd/system/tlp.service
-rw-r--r-- root/root /usr/lib/udev/rules.d/85-tlp.rules
-rwxr-xr-x root/root /usr/lib/elogind/system-sleep/49-tlp-sleep
-rwxr-xr-x root/root /usr/lib/systemd/system-sleep/tlp
-rwxr-xr-x root/root /usr/lib/udev/tlp-usb-udev
Control files: lines which differ (wdiff format)
Installed-Size: [-577-] {+575+}
Version: [-1.5.0-1-] {+1.5.0-2+}
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
-rw-r--r-- root/root /lib/udev/rules.d/85-tlp-rdw.rules
-rwxr-xr-x root/root /lib/udev/tlp-rdw-udev
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/lib/udev/rules.d/85-tlp-rdw.rules
-rwxr-xr-x root/root /usr/lib/udev/tlp-rdw-udev
Control files: lines which differ (wdiff format)
Depends: network-manager, tlp (= [-1.5.0-1)-] {+1.5.0-2)+}
Version: [-1.5.0-1-] {+1.5.0-2+}
Bug#1034233: tlp: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hi, @Laurent, thank you for highlighting this. @Andreas, the solution you suggested seems nice but ideally I'd rather keep build-dependencies to a minimal (currently there's only debhelper), so I prefer to revert usrmerge related changes introduced in 1.5, even if it means that I'll have to re-introduce them during Trixie's development cycle. Regards, -- Raphaël Halimi
Bug#1028897: fontconfig-config: default latin fonts changed from DejaVu to Noto
reassign 1028897 fontconfig retitle 1028897 fontconfig: wrong name for the Noto monospace font merge 1028897 1028643 tags 1028897 patch thanks -- Raphaël Halimi Description: Fix default monospace font With Fontconfig 2.14, upstream made the Noto fonts default, but used "Noto Sans Mono" as the default font for the monospace family, which exists, but is actually not a monospace font. The right name is "Noto Mono". Author: Raphaël Halimi Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028897 Forwarded: no Last-Update: 2023-01-14 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/conf.d/60-latin.conf +++ b/conf.d/60-latin.conf @@ -35,7 +35,7 @@ monospace - Noto Sans Mono + Noto Mono DejaVu Sans Mono Inconsolata Andale Mono
Bug#1028897: fontconfig-config: default latin fonts changed from DejaVu to Noto
reassign -1 fontconfig retitle -1 fontconfig: wrong name for the Noto monospace font merge -1 1028643 tags -1 patch thanks Le 14/01/2023 à 19:45, Raphaël Halimi a écrit : If you wish to keep DejaVu as default, here is a simple patch to do that. Ok, scratch this patch. I know that Debian don't like to diverge from upstream (and I'm a maintainer myself), so this was not a good idea. Moreover, the change from DejaVu to Noto was not the root cause of the problem. The problem is that the monospace Noto font is actually "Noto Mono" and not "Noto Sans Mono" (probably a typo on upstream's part). If you use a font manager you'll see that there is indeed a font called "Noto Sans Mono", but if you filter them out to list only the monospace fonts, you can see that there's no font called "Noto Sans Mono" among them, but there is one called "Noto Mono". Using this one (which I now believe is the "real" monospace font from Noto) as default for the monospace family does fix both Xterm and gnome-terminal (and probably other terminals too). This new patch fixes what I think is actually a bug (and which probably needs to be forwarded to upstream). Regards, -- Raphaël Halimi Description: Fix default monospace font With Fontconfig 2.14, upstream made the Noto fonts default, but used "Noto Sans Mono" as the default font for the monospace family, which exists, but is actually not a monospace font. The right name is "Noto Mono". Author: Raphaël Halimi Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028897 Forwarded: no Last-Update: 2023-01-14 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/conf.d/60-latin.conf +++ b/conf.d/60-latin.conf @@ -35,7 +35,7 @@ monospace - Noto Sans Mono + Noto Mono DejaVu Sans Mono Inconsolata Andale Mono
Bug#1028897: fontconfig-config: default latin fonts changed from DejaVu to Noto
reassign -1 fontconfig merge -1 1028643 tags -1 patch thanks Sorry, I checked the bugs reported against fontconfig-config before filing this one, I didn't think to check fontconfig also. If you wish to keep DejaVu as default, here is a simple patch to do that. Regards, -- Raphaël HalimiDescription: Keep DejaVu fonts as default for latin languages With Fontconfig 2.14, upstream made the Noto fonts the default for serif, sans-serif and monospace families for latin languages. This patch simply undoes this change. Author: Raphaël Halimi Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028897 Forwarded: not-needed Last-Update: 2023-01-14 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/conf.d/60-latin.conf +++ b/conf.d/60-latin.conf @@ -5,8 +5,8 @@ serif - Noto Serif DejaVu Serif + Noto Serif Times New Roman Thorndale AMT Luxi Serif @@ -18,8 +18,8 @@ sans-serif - Noto Sans DejaVu Sans + Noto Sans Verdana Arial Albany AMT @@ -35,8 +35,8 @@ monospace - Noto Sans Mono DejaVu Sans Mono + Noto Sans Mono Inconsolata Andale Mono Courier New
Bug#1028897: fontconfig-config: default latin fonts changed from DejaVu to Noto
Package: fontconfig-config Version: 2.14.1-3 Dear developers, In the recent upgrade from fontconfig 2.13 to 2.14, the default latin fonts changed from DejaVu to Noto, in the file "/usr/share/fontconfig/conf.avail/60-latin.conf". The default fonts in Debian is still supposed to be DejaVu, as stated in the debconf template : "Select 'Native' if you mostly use DejaVu (the default in Debian)" The difference is very slight for the serif and sans families used in most graphical applications like Firefox or Thunderbird, but for the monospace family, it makes terminals look ugly : gnome-terminal handles the spacing somewhat right, but the resulting window is square-shaped, far from what one could be accustomed to; and in Xterm (if configured to use whatever TrueType font aliased to "Monospace") it's even worse, it handles the spacing completely wrong, resulting in over-spaced characters and a comically large shaped window. I don't know if this change is intentional (to follow upstream configuration) or if it's an overlook; of course feel free to close the bug as wontfix if the change is intentional (and maybe update the debconf template), but if that's the case, please at least mention somewhere the "right" way to revert that change, as it's not intuitive. I created "/etc/fonts/conf.avail/60-latin.conf" which switches DejaVu and Noto to make the former the default, and I initially thought that re-configuring the package would pick up the file by itself (seeing that the filename is the same, the file in "/etc" superseding the one in "/usr", like other tools usually do), but it's not the case, and I had to symlink it manually in "/etc/fonts/conf.d", overwriting the original one linking to "/usr/share/fontconfig/conf.avail/60-latin.conf", which belongs to the package. Is that the correct way of changing default fontconfig settings ? Regards, -- Raphaël Halimi
Bug#1025902: tlp: Battery charge thresholds are ignored
Hi again, I contacted the upstream developer and he'd like you to open an issue there directly. The project page is at https://github.com/linrunner/TLP For starters he needs the output of : $ tlp-stat --cdiff -s -b Once you've done that, please reply here with the address of the issue report, I'll link them in the BTS. Regards, -- Raphaël Halimi
Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)
Package: xz-utils Version: 5.4.0-0.1 Dear developer, I'm not sure if it's the right place to report the bug since it involves a conflict with a backport. Today I tried to upgrade a Bullseye laptop to Bookworm. The upgrade crashed with xz-utils trying to overwrite /usr/share/man/fr/man1/xz.1.gz which belonged to manpages-fr from backports (4.16.0-3~bpo11+1). After running dpkg --force-overwrite (it's the only way I know of in such situations), a whole bunch of manual pages were overwritten : /usr/share/man/fr/man1/xz.1.gz /usr/share/man/fr/man1/xzdiff.1.gz /usr/share/man/fr/man1/xzless.1.gz /usr/share/man/fr/man1/xzmore.1.gz /usr/share/man/fr/man1/lzcat.1.gz /usr/share/man/fr/man1/lzcmp.1.gz /usr/share/man/fr/man1/lzdiff.1.gz /usr/share/man/fr/man1/lzless.1.gz /usr/share/man/fr/man1/lzma.1.gz /usr/share/man/fr/man1/lzmore.1.gz /usr/share/man/fr/man1/unlzma.1.gz /usr/share/man/fr/man1/unxz.1.gz /usr/share/man/fr/man1/xzcat.1.gz /usr/share/man/fr/man1/xzcmp.1.gz I don't see a clean solution to ensure a smooth upgrade for people who have installed this backport. Maybe coordinate with manpages-fr maintainer and release updated backports for both packages, before Bookworm is released ? Regards, -- Raphaël Halimi
Bug#1028229: libwmf-0.2-7-gtk: tries to overwrite file in libwmf0.2-7-gtk
Package: libwmf-0.2-7-gtk Version: 0.2.12-5 Dear developer, Today I tried to upgrade a Bullseye laptop to Bookworm. The upgrade crashed with libwmf-0.2-7-gtk trying to overwrite /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/io-wmf.so which belonged to libwmf0.2-7-gtk (0.2.8.4-17). Judging by the packages names I guess libwmf-0.2-7-gtk is supposed to replace libwmf0.2-7-gtk; it seems the break and replace on libwmf0.2-7 (<< 0.2.8.4-12) is too restrictive and should be extended (add libwmf0.2-7-gtk and update the version to the last one shipping this file). Regards, -- Raphaël Halimi
Bug#1025902: tlp: Battery charge thresholds are ignored
Le 08/01/2023 à 14:18, Benedikt Ahrens a écrit : Dear Raphaël, Thanks a lot for your advice. The change you propose does not solve the problem: ``` tpacpi-bat.BAT0.startThreshold = 0 [%] tpacpi-bat.BAT0.stopThreshold = 100 [%] tpacpi-bat.BAT0.forceDischarge = 0 Sorry, I didn't realize that the thresholds were at 0% and 100% (although it was written in your first report) ; they should be at 96% and 100%. Maybe your laptop is too recent and not supported yet. Please undo all the changes and revert to natacpi. I'll try to see that with upstream. Regards, -- Raphaël Halimi
Bug#1025902: tlp: Battery charge thresholds are ignored
Le 07/01/2023 à 17:07, Benedikt Ahrens a écrit : What model of ThinkPad do you have ? I have a T14 G3. It's a fairly recent model (February 2022), I can't say if it's not supported by thinkpad_acpi yet, but trying good old acpi_call may be worth it. Bear in mind that I'm only the package maintainer, not the main developer, so I'm really not sure if it's the cause of the problem. Maybe the natacpi driver doesn't work and you need another one. I don't know how to switch to another driver. Would you be able to point me to documentation on how to do that? Make sure you install the kernel headers package matching your kernel (probably linux-headers-amd64), and then install acpi-call-dkms. It should build the module automatically. Then try to load it : $ sudo modprobe acpi_call ...and tell TLP to use it by disabling natacpi (which supersedes tpacpi-bat). To do so, change the value of the NATACPI_ENABLE to 0 in tlp.conf. Restart tlp, and see if it solves your problem. If loading the module says something like "Operation not permitted", it means secure boot is enabled and you have to create a key pair, enroll it in the MOK (machine owner keys), and sign the module with it. It's far outside of the scope of TLP, so in the meantime, for the purpose of testing, just reboot into BIOS and disable secure boot. Regards, -- Raphaël Halimi
Bug#1025902: tlp: Battery charge thresholds are ignored
Le 07/01/2023 à 14:04, Benedikt Ahrens a écrit : Dear Raphaël, Thanks a lot for your advice. I have uncommented the corresponding lines in the configuration file (which I am sending in attachment). However, the output of `tlp-stat -b` still shows no change to the charge thresholds, even after reboot: What model of ThinkPad do you have ? Maybe the natacpi driver doesn't work and you need another one. Regards, -- Raphaël Halimi
Bug#1027276: apt: "apt install" should run "apt update" when some repositories metadata have not been fetched
Package: apt Version: 2.5.4 Severity: wishlist User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: arna...@kali.org, raph...@offensive-security.com Hello, there are many cases where apt will not have fetched any repository information yet: - first run of a container (no metadata fetched to keep container small) - when the user has manually added a new repository to sources.list - when running from a live image - other kind of fresh installation without network In those situations, itt would be nice if apt could be smarter than this: ┌──(root㉿carbon)-[/work] └─# apt install nano Reading package lists... Done Building dependency tree... Done Reading state information... Done Package nano is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'nano' has no installation candidate Apt could, for instance, inform the user that some repository information is missing and propose to run it for them. # apt install nano Apt is lacking metadata for some repositories. The missing metadata can be downloaded by running "apt update". Do you want to execute this command? [Y/n/q] Get:1 [...] Fetched 41.8 MB in 15s (2782 kB/s) The following NEW packages will be installed: nano 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. [...] Typing "q" would "quit" the whole process. "Y" would run apt update and then follow with the requested installation. "n" would skip apt update and still try to perform the installation. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 apt depends on: ii adduser 3.129 ii base-passwd 3.6.1 ii debian-archive-keyring 2021.1.1 ii gpgv2.2.40-1 ii libapt-pkg6.0 2.5.4 ii libc6 2.36-6 ii libgcc-s1 12.2.0-9.1 ii libgnutls30 3.7.8-4 ii libseccomp2 2.5.4-1+b2 ii libstdc++6 12.2.0-9.1 ii libsystemd0 252.3-1 Versions of packages apt recommends: ii ca-certificates 20211016 Versions of packages apt suggests: ii apt-doc 2.5.4 ii aptitude0.8.13-5 ii dpkg-dev1.21.12 ii gnupg 2.2.40-1 ii powermgmt-base 1.37 ii synaptic0.91.2 -- no debconf information
Bug#1025902: tlp: Battery charge thresholds are ignored
Hi, Sorry for the late answer, the e-mail from the BTS fell into my spam folder. Usually, in configuration files, a hash symbol (#) indicates a comment, and is ignored by the software. It seems that you didn't un-comment the lines when modifying the charge thresholds. Remove the # symbol in front of the lines you modified (the ones starting with START_CHARGE_THRESH and STOP_CHARGE_THRESH) and it should work. Regards, -- Raphaël Halimi
Bug#1022704: ccache: broken in cross-architecture chroot
Le 25/10/2022 à 18:40, Joel Rosdahl a écrit : Thanks! Now I understand the problem and will work on a fix. The issue is sharing the inode cache file between architectures. A workaround is to either use separate temporary directories for the architectures (or different cache directories when the temporary directory defaults to the cache directory, which is the case for you), or to disable the inode cache by setting inode_cache = false in the config file. Hi, I'm glad I could help you despite my lack of knowledge in this area. I confirm that disabling the inode cache does work, I'll use this workaround while waiting for a fixed version to be released. Thanks ! Regards, -- Raphaël Halimi
Bug#1022704: ccache: broken in cross-architecture chroot
Le 24/10/2022 à 20:17, Joel Rosdahl a écrit : On Mon, Oct 24, 2022, at 15:26, Raphaël Halimi wrote: Install pbuilder on an amd64 host and prepare an i386 chroot. Then, try to build a package in it (I was rebuilding timidity). It should hang during the configure phase. I've never used pbuilder before, but I've tried creating an i386 chroot now, setting CCACHEDIR according to pbuilderrc(5). I then built timidity multiple times with "pdebuild --architecture i386", but it works fine for me every time. I've checked that ccache 4.7.1-1 is being used and that the ccache directory is being utilized. I'm afraid I'll need more help to track this down. That's weird. Before filing the bug, I tried to recreate my build environment in a brand new VM, and I observed the same behavior. Maybe the problem lies in my configuration ? Regarding ccache, I just set it to /var/cache/pbuilder/ccache (some packages failed to build when I initially put it in ~/.ccache, permissions problems I think, because pbuilder makes files in there owned by 1234). 1. When you say that it systematically hangs, can you check which process is hanging and what it hangs on, e.g. using strace? I don't know how to use strace. Could you please direct me ? 2. Would it be possible for you to set CCACHE_LOGFILE (or log_file in ccache.conf in the ccache directory) to a file inside the pbuilder chroot and then publish the created log file? I'll try to do that. The file does not exist on my machine; do I just need to create /var/cache/pbuilder/ccache/ccache.conf containing a single line "log_file=..." or is there something else to do ? Regards, -- Raphaël Halimi
Bug#1022704: ccache: broken in cross-architecture chroot
Le 24/10/2022 à 14:31, Joel Rosdahl a écrit : Can you give me more some detailed hints on how I can reproduce the issue? Install pbuilder on an amd64 host and prepare an i386 chroot. Then, try to build a package in it (I was rebuilding timidity). It should hang during the configure phase. I have a complicated setup with several chroots, custom pbuilderrc, sudo snippets to let some environment variables pass, etc etc; but, from memory, this should work : sudo pbuilder create --architecture i386 apt-get source somepackage (preferably something using autotools) cd somepackage sudo pdebuild --architecture i386 Regards, -- Raphaël Halimi
Bug#1022704: ccache: broken in cross-architecture chroot
Le 24/10/2022 à 13:38, Joel Rosdahl a écrit : Hi Raphaël, Could you test if ccache 4.7.1-1 improves the situation? I also tested it, it's broken too. Regards, -- Raphaël Halimi
Bug#1022704: ccache: broken in cross-architecture chroot
Package: ccache Version: 4.7-1 Dear maintainer, I use pbuilder to build package both for native architecture (amd64) and foreign architectures (i386, armhf). Since upgrading ccache in Debian Sid to 4.7-1, package building systematically hangs during the configure phase (checking for this, checking for that, etc) for foreign architectures. It always happen, but not necessarily for the same files, although it's usually while checking for stdio.h or stdlib.h. Downgrading to 4.6.3-1 in the chroot solves the problem, both for i386 and armhf. Regards, -- Raphaël Halimi
Bug#1020614: openbox-menu: cannot find icons with dots in their name
Package: openbox-menu
Version: 0.8.0+hg20161009-3.1
Severity: minor
Tags: patch
Dear fellow developer,
openbox-menu contains a few lines of code to remove file extensions in
icon names found in desktop files. It removes everything after the last
dot, which prevents gtk_icon_theme_lookup_icon() to find an icon if its
name contains a dot, which is the case in more and more applications,
for example nearly all GNOME applications, Remmina, Wireshark or even XTerm.
Moreover, it seems that nowadays gtk_icon_theme_lookup_icon() is
perfectly capable to retrieve icons which contain a file extension.
The provided patch removes the few lines of code which remove file
extensions before the gtk_icon_theme_lookup_icon() query, allowing
openbox-menu to correctly retrieve all icons.
Regards,
--
Raphaël HalimiDescription: Don't remove file extensions in icon names
It seems that nowadays gtk_icon_theme_lookup_icon() is perfectly capable to
retrieve icons which contain a file extension, so removing them is not needed
anymore. Removing everything after the last dot prevented to find icons which
contained a dot in their name, and more packages have such icons for example
nearly all GNOME applications, Remmina, Wireshark or even XTerm.
Author: Raphaël Halimi
Last-Update: 2022-09-24
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/utils.c
+++ b/src/utils.c
@@ -189,7 +189,6 @@
{
GtkIconInfo *icon_info = NULL;
gchar *icon = NULL;
- gchar *tmp_name = NULL;
const gchar *name = menu_cache_item_get_icon (MENU_CACHE_ITEM(item));
@@ -198,16 +197,11 @@
if (g_path_is_absolute (name))
return g_strdup (name);
- /* We remove the file extension as gtk_icon_theme_lookup_icon can't
- * lookup a theme icon for, ie, 'geany.png'. It has to be 'geany'.
- */
- tmp_name = strndup (name, strrchr (name, '.') - name);
#ifdef WITH_SVG
- icon_info = gtk_icon_theme_lookup_icon (icon_theme, tmp_name, 16, GTK_ICON_LOOKUP_GENERIC_FALLBACK);
+ icon_info = gtk_icon_theme_lookup_icon (icon_theme, name, 16, GTK_ICON_LOOKUP_GENERIC_FALLBACK);
#else
- icon_info = gtk_icon_theme_lookup_icon (icon_theme, tmp_name, 16, GTK_ICON_LOOKUP_NO_SVG | GTK_ICON_LOOKUP_GENERIC_FALLBACK);
+ icon_info = gtk_icon_theme_lookup_icon (icon_theme, name, 16, GTK_ICON_LOOKUP_NO_SVG | GTK_ICON_LOOKUP_GENERIC_FALLBACK);
#endif
- g_free (tmp_name);
}
if (!icon_info) /* 2nd fallback */
Bug#1020330: pipewire-pulse: Conflict with pulseaudio is badly resolved by apt full-upgrade
Package: pipewire-pulse Version: 0.3.58-1 Severity: important X-Debbugs-Cc: raph...@freexian.com, seb...@debian.org, de...@lists.debian.org APT will not let me upgrade pipewire-pulse to the latest version because I have gnome-core installed. It will prefer to deinstall pipewire-pulse: $ sudo apt full-upgrade [...] The following packages were automatically installed and are no longer required: libappstream-glib8 libatk1.0-data libmalcontent-ui-0-0 libnautilus-extension1a libqpdf28 Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: nautilus-extension-brasero pipewire-pulse The following packages have been kept back: python3-twisted-bin tryton-client The following packages will be upgraded: gstreamer1.0-pipewire libpipewire-0.3-0 libpipewire-0.3-modules libspa-0.2-modules nautilus nautilus-data pipewire pipewire-bin 8 upgraded, 0 newly installed, 2 to remove and 2 not upgraded. Need to get 3958 kB of archives. After this operation, 938 kB disk space will be freed. Do you want to continue? [Y/n] n If I try to force install pipewire-pulse, it will propose to remove gnome-core: $ LANG=C sudo apt install pipewire-pulse Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: hyphen-en-us libappstream-glib8 libatk1.0-data libbox2d2 libfreehand-0.1-1 libgsf-bin libmalcontent-ui-0-0 libmspub-0.1-1 libpagemaker-0.0-0 libproxy1-plugin-gsettings libproxy1-plugin-networkmanager libproxy1-plugin-webkit libqpdf28 libqxp-0.0-0 libreoffice-draw libreoffice-gnome libreoffice-impress libzmf-0.0-0 mythes-en-us Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: gstreamer1.0-pipewire libldacbt-abr2 libpipewire-0.3-0 libpipewire-0.3-modules libspa-0.2-bluetooth libspa-0.2-modules pipewire pipewire-bin The following packages will be REMOVED: gnome gnome-core pulseaudio pulseaudio-module-bluetooth task-gnome-desktop The following NEW packages will be installed: libldacbt-abr2 libspa-0.2-bluetooth The following packages will be upgraded: gstreamer1.0-pipewire libpipewire-0.3-0 libpipewire-0.3-modules libspa-0.2-modules pipewire pipewire-bin pipewire-pulse 7 upgraded, 2 newly installed, 5 to remove and 4 not upgraded. Need to get 1993 kB of archives. After this operation, 5930 kB disk space will be freed. Do you want to continue? [Y/n] n The only way to get the latest version is to manually provide the working solution by indicating that we also need libspa-0.2-bluetooth (to satisfy gnome-core's "pulseaudio-module-bluetooth | libspa-0.2-bluetooth" together with its "pulseaudio | pipewire-pulse"). $ LANG=C sudo apt install pipewire-pulse libspa-0.2-bluetooth Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: libappstream-glib8 libatk1.0-data libmalcontent-ui-0-0 libqpdf28 Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: gstreamer1.0-pipewire libldacbt-abr2 libpipewire-0.3-0 libpipewire-0.3-modules libspa-0.2-modules pipewire pipewire-bin The following packages will be REMOVED: pulseaudio pulseaudio-module-bluetooth The following NEW packages will be installed: libldacbt-abr2 libspa-0.2-bluetooth The following packages will be upgraded: gstreamer1.0-pipewire libpipewire-0.3-0 libpipewire-0.3-modules libspa-0.2-modules pipewire pipewire-bin pipewire-pulse 7 upgraded, 2 newly installed, 2 to remove and 4 not upgraded. Need to get 1993 kB of archives. After this operation, 5848 kB disk space will be freed. Do you want to continue? [Y/n] That looks like it will be a disaster for users doing a dist upgrade. But I'm not sure what we can do about it. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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-pulse depends on: ii init-system-helpers 1.65.2 ii pipewire 0.3.57-1 pipewire-pulse recommends no packages. Versions of packages pipewire-pulse suggests: pn libspa-0.2-bluetooth ii pulseaudio-utils 15.0+dfsg1-4+b1 -- no debconf information
Bug#1018288: waagent: Debian specific patch breaks kali support
Package: waagent Version: 2.7.3.0-1 Severity: important User: de...@kali.org Usertags: origin-kali Hello, this patch broke kali support: https://salsa.debian.org/cloud-team/waagent/-/commit/dd8f1771d89bd255f96938f080b02b889da79ad7 The import of "DebianOSBaseUtil" has been dropped while it's clearly used further down the road: if distro_name == "kali": return DebianOSBaseUtil() Please re-add the import statement. There's a merge request lying around since one year: https://salsa.debian.org/cloud-team/waagent/-/merge_requests/3 But that merge request restores it in the wrong order so that would still keep a diff compared to upstream. I have ask the MR submitter to update it. Cheers, -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 waagent depends on: ii bind9-host [host] 1:9.18.6-1 ii ca-certificates20211016 ii eject 2.38.1-1 ii fdisk 2.38.1-1 ii iptables 1.8.8-1 ii net-tools 1.60+git20181103.0eebece-1 ii openssh-server 1:9.0p1-1+b1 ii openssl3.0.5-2 ii parted 3.5-1 ii python33.10.6-1 ii python3-distro 1.7.0-1 ii python3-pkg-resources 59.6.0-1.2 ii sudo 1.9.11p3-1 ii util-linux 2.38.1-1 waagent recommends no packages. waagent suggests no packages.
Bug#939904: Temporary network disruption during upgrade
Le 21/08/2022 à 00:41, Luca Boccassi a écrit : Yes I noticed the same thing when building images, this cross-device check is a true annoyance and can't seem to find a workaround :-/ I can't find a solution, so unfortunately it looks like we have to resort to maintainer scripts, which is awful but I can't think of anything else: https://salsa.debian.org/systemd-team/systemd/-/merge_requests/164 Sorry to annoy you again, but... Why not just leave /etc/resolv.conf alone ? After all, shouldn't it be the user's choice to link it against /run/systemd/resolve/stub-resolv.conf, /run/systemd/resolve/resolv.conf, or just manage it manually ? Plus, it would solve both problems I mentioned before. Regards, -- Raphaël Halimi
Bug#1017713: systemd: upgrade breaks DNS resolution in some cases
Package: systemd Version: 251.3-2~exp1 Severity: critical (filing the bug as critical since it "makes unrelated software on the system (or the whole system) break", feel free to downgrade) Dear developers, A recent update of systemd splits systemd-resolved in its own package, and the new systemd-resolved is not installed by default, thus, during the upgrade, the systemd-resolved service is stopped and removed (which seems to be the intended behavior). In the (admittedly probably rare) case where systemd-resolved's stub resolver was already in use beforehand (meaning, /etc/resolv.conf was already symlinked to /run/systemd/resolve/stub-resolv.conf), the upgrade completely breaks DNS resolution, since the file (which remains in /run/systemd/resolve) lists 127.0.0.53 as the only nameserver, which doesn't respond anymore since the systemd-resolved service was stopped. The breakage lasts until the user manually fixes it by installing systemd-resolved, but this simple operation may be tricky, because there's no DNS resolution anymore and apt will fail to download the new package, unless the user manually creates a temporary /etc/resolv.conf file listing a working name server, or symlinks /etc/resolv.conf to /run/systemd/resolve/resolv.conf instead (which also remains in /run after the service is stopped, and doesn't use the stub resolver since this file, unlike stub-resolv.conf, lists the upstream name servers). One possible solution would be to check in the maintainer scripts if the stub resolver is already in use (in other terms, if /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf), and, if it's the case, do what's described above (symlink /etc/resolv.conf to /run/systemd/resolve/resolv.conf instead, thus bypassing the stub resolver). This would keep DNS resolution working (until the next reboot, that is), but the user will at least have the time to read the NEWS entry, and act accordingly. Regards, -- Raphaël Halimi
Bug#1017714: systemd-resolved: deletes /etc/resolv.conf after package removal
Package: systemd-resolved
Version: 251.3-2~exp1
Severity: critical
(filing the bug as critical since it "makes unrelated software on the
system (or the whole system) break", feel free to downgrade)
Dear developers,
The new systemd-resolved package takes over /etc/resolv.conf, and
unconditionally makes it a symlink it to
/run/systemd/resolve/stub-resolv.conf. Moreover, after the package is
removed, the symlink is also removed, leaving the system with no
/etc/resolv.conf, and thus, a broken DNS resolution.
/etc/resolv.conf is not considered as a conffile since technically, it
doesn't belong to any package (and is not listed as a conffile by
systemd-resolved, which treats it as a normal file), but if it's
considered as a configuration file (it's located in /etc after all), I
believe this behavior severely transgresses Debian Policy 10.7.3 on both
points ("local changes must be preserved during a package upgrade" and
"configuration files must be preserved when the package is removed").
One (conservative) solution would be to not touch /etc/resolv.conf at
all, leaving the users create the symlink to
/run/systemd/resolve/stub-resolv.conf (or
/run/systemd/resolve/resolv.conf) themselves. This would solve both
transgressions at once. One could argue that it wouldn't make sense to
install systemd-resolved and not use it in /etc/resolv.conf, but the
service would still provide the bus and glibc APIs.
If /etc/resolv.conf is not considered a configuration file, and this new
behavior does not transgresses the Debian Policy, then the package
should at least leave the system with a working /etc/resolv.conf file
after removal, for example by copying the contents of
/run/systemd/resolve/resolv.conf (optionally stripping comments and
empty lines) in maintainers scripts.
Regards,
--
Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
Le 18/08/2022 à 21:29, Luca Boccassi a écrit : Going for a custom setup means sometimes there is, sometimes there's not. It's always a tradeoff. This breaking change means there's now a supported way to run resolved, and it's the easiest possible way for all those that weren't using it before, which is the majority given there was no support and no integration before. I'll still file two separate bugs, one against systemd for the DNS resolution breakage after the upgrade, and the other one against systemd-resolved for the removal of /etc/resolv.conf after the package is removed. Even if you think there's no problem here, I don't agree and I think those are bugs, and serious ones at that. I'll file them just for the record, so feel free to immediately close them as wontfix, I won't mind. Regards, -- Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
Le 18/08/2022 à 16:59, Luca Boccassi a écrit : No, custom and unsupported setups are unsupported. Compatibility is provided for default environments, anything outside of it can and will break at any given time, and it's not really feasible to do otherwise given the uncountable amount of possible permutations. This time there's a clear and unambiguos NEWS entry with a notification, which doesn't even always happen. What I meant is that I thought systemd-networkd (which partly relies on systemd-resolved) was considered supported since it was shipped with systemd and thus installed by default (unlike, for example, netplan), albeit not enabled. Should I understand that the only supported way to configure the network in Debian is ifupdown with a plain /etc/resolv.conf file, and everything outside of this scope is considered custom and thus, unsupported ? I'm not being ironical here, it's a legitimate question. Wrong, I always receive e-mails with news as well as changelogs during upgrades, with the more recent examples being on July 13, 22 and 25. I don't know why it didn't work this time, but I can hardly believe that it's apt-listchanges' fault. And yet it is, and it's been a known issue for quite some time: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422 OK, you're right on this point, I didn't know that. Apologies. But it also means that other sysadmins will be in the same case too when the upgrade will take place (when bookworm is released, or when systemd 251.3-2 will be backported to bullseye) and will have their DNS resolution temporarily broken after the upgrade. But I guess you'll probably argue that it's their fault for using systemd-resolved. I think you don't understand my position: I don't care about resolvconf or openresolv, I just want to use systemd-resolved (not the systemd resolvconf interface, but the systemd-resolved service itself!) and avoid breakage during upgrades for all users. Look, I'm just trying to help here. You made a change, it has serious consequences for systemd-resolved users, and I hinted them to you, that's all. I think this is a bad change, but that's another matter. Being obtuse and condescending won't help. Name-calling won't help either. Right, but at least admit that you're being a bit harsh to me since the beginning of this thread, rejecting all my arguments and refusing to see the problem here, basically saying that the resulting breakage is not your fault and systemd-resolved users brought it on themselves by using it because it's "unsupported". Again, I don't care about resolvconf or openresolv, I care about sysadmins who use systemd-networkd/resolved on their servers or containers, and I'm just trying to avoid problems for them as well as for myself in the future. systemd brought a lot of controversy when it was adopted in Debian, and I myself was amongst the people who were quite unhappy when it happened (I still think that Jessie was too soon, it was not mature enough, but that's another story). Now that we started to familiarize with its different parts and all in all find it very convenient that they're installed by default, you slowly remove them one by one (systemd-machined, systemd-timesyncd, systemd-boot, and now systemd-resolved... Which will be the next ?), forcing us sysadmins to constantly update our automated installation procedures (debian-installer hooks, ansible/puppet recipes, container images, etc etc), and defeating the very purpose of systemd to be "a suite of basic building blocks for a Linux system" that we finally embraced. It's almost as if you want to discourage us to use the non-init-related parts of systemd. Regards, -- Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
Le 18/08/2022 à 16:20, Luca Boccassi a écrit : No, it is not, because no integration nor support was provided before. It was an inhert and disabled service and binary. The NEWS file covers the change adequately for custom setups. Custom setups are always at risk of breakage. I agree that it was not enabled by default, but it was shipped by systemd, with a stable interface, and as such, it was available for the admin to use it if he/she wished. Breaking DNS resolution after an upgrade is not a serious bug in your opinion ? That would make it de-facto the default resolver on Debian, and we really don't want that at this stage. There appears to be some bug in apt-listchanges when showing changelogs is enabled making it skip NEWS files if a changelog for the same version was already displayed, and there's not much we can do about it, it's a problem to be solved by apt-listchanges. Wrong, I always receive e-mails with news as well as changelogs during upgrades, with the more recent examples being on July 13, 22 and 25. I don't know why it didn't work this time, but I can hardly believe that it's apt-listchanges' fault. Absolutely not, the alternatives system is a gigantic mess that should have never existed in the first place. If you want to use openresolv, install openresolv and remove resolved. I think you don't understand my position: I don't care about resolvconf or openresolv, I just want to use systemd-resolved (not the systemd resolvconf interface, but the systemd-resolved service itself!) and avoid breakage during upgrades for all users. Look, I'm just trying to help here. You made a change, it has serious consequences for systemd-resolved users, and I hinted them to you, that's all. I think this is a bad change, but that's another matter. Being obtuse and condescending won't help. Regards, -- Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
Le 17/08/2022 à 00:36, Luca Boccassi a écrit : Personally I see this as a regression, since resolved used to be part of systemd and thus readily available without installing additional packages. No support was provided before for resolved, it was completely inhert, hence it is not a regression. It is a change in behaviour, and thus noted in the NEWS file as expected. Yes, but this goal could be achieved by letting resolved in the main systemd package, and splitting only systemd-resolvconf in its own package. Having a single-file-package that is confusing and harder to find is not something we want to do, unless there are extremely compelling reasons for it. Supporting resolvconf is not one. Could you at least address the temporary break in DNS resolution ? This is still a serious bug, which would deserve its own bug with priority grave (if not critical). Since systemd-resolved is mainly used on servers, it could result in a very bad surprise for sysadmins when bookworm is released. Perhaps it could be fixed by promoting systemd-resolved to a recommends (instead of suggests) in systemd, so that it's installed during the upgrade ? Or don't stop the service if /etc/resolv.conf is symlinked to /run/systemd/resolve/stub-resolv.conf, so that the admin has the time to read the NEWS entry (which, again, didn't work on my system, whereas it was supposed to be sent in an e-mail by apt-listchanges), and install systemd-resolved before rebooting ? Also, I understand that you don't wish to revert your changes, but is there a reason why resolvconf, openresolv and thus systemd-resolved could coexist thanks to the alternatives system ? I know it would be more work for maintainers of those three packages, but IMHO it would be worth the effort. And, last but not the least, I see that /etc/resolv.conf is now part of systemd-resolved files, which means that it would be deleted when the systemd-resolved package is removed from the system. I think it would also deserve its own bug with some high priority. Regards, -- Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
Le 16/08/2022 à 22:59, Luca Boccassi a écrit : You want resolved? Install the resolved package. Don't want resolved? Don't install the package. Personally I see this as a regression, since resolved used to be part of systemd and thus readily available without installing additional packages. We do no want to support combining resolved with resolvconf - and in fact, the setup with conflicts+provides is exactly like other packages like openresolv are set up. Yes, but this goal could be achieved by letting resolved in the main systemd package, and splitting only systemd-resolvconf in its own package. Regards, -- Raphaël Halimi
Bug#939904: Temporary network disruption during upgrade
Dear developers, I just upgraded a sid system and I noticed that the network was broken on this machine. I suppose the reason is that I had systemd-resolved enabled and /etc/resolv.conf was symlinked to the stub resolver (/run/systemd/resolve/stub-resolv.conf), and since the systemd-resolved service had disappeared and didn't respond anymore on 127.0.0.53, the system was left with a broken DNS resolution. On a side note, the changelog says that an entry was added in NEWS.Debian to warn user of the change, but it wasn't displayed during the upgrade (this is weird, I know). I had to read the changelog to understand what was going on. And finally, my opinion: After reading the mail thread in this bug report, I thought the plan was to separate systemd-resolvconf (as Arch did, IIUC), not the entire systemd-resolved service. IMHO this is a **very** bad idea, and not only because of the broken DNS resolution broken after the upgrade in some cases... The whole point of systemd-resolved is that it's included in systemd (so basically in every Linux system nowadays) and, alongside systemd-networkd, provides an entire network configuration/management stack, without the need to install optional packages, but most importantly, standard across all distributions (no need to learn and/or master ifupdown, sysconfig, netplan, whatever, etc). If it's not too late, I strongly suggest to reintegrate systemd-resolved in the main systemd package (as it was before), and split only systemd-resolvconf. Best regards, -- Raphaël Halimi
Bug#1016370: RM: python-django-jsonfield -- ROM; Abandoned upstream, replaced by native Django field
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: hert...@debian.org Hello, please remove python-django-jsonfield from unstable. Django 3.2 already provides a generic JSONField similar to what's provided in python-django-jsonfield: https://docs.djangoproject.com/en/3.2/ref/models/fields/#jsonfield Given this, python-django-jsonfield is no longer maintained upstream and should replaced by the above field. Everybody should switch to the Django native field. There are no reverse dependencies in unstable. Thank you, Raphaël Hertzog.
Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea
Package: openvpn Version: 2.6.0~git20220518+dco-2 Severity: important User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: raph...@freexian.com Hello Bernhard, as Kali is based on Debian testing, our users started to experience the git snapshot of OpenVPN that you uploaded. Unfortunately, we got multiple reports that their VPN break because many VPN services ship .opvn files that rely on --cipher. At the same time, it's not really reasonable to expect (commercial) services to be ready for a version of OpenVPN that is not released yet. Upstream OpenVPN contributors are blaming Debian/Kali for this choice: https://forums.openvpn.net/viewtopic.php?p=107165#p107154 As such I really believe that this git snapshot should have stayed in experimental. Why was it uploaded to unstable before its upstream release? I assume it was due to OpenSSL 3 becoming the default. However I notice that upstream released 2.5.7 on May 31 that adds limited support of OpenSSL 3.x. Can we switch back to 2.5.7 until 2.6 is released upstream? (We will likely do this in Kali with a version like 2.6.0~really2.5.7) If we don't want to switch back to 2.5.x, it might make sense to temporarily revert the backwards incompatible change that breaks most people's setup, I'm speaking of this commit: https://github.com/OpenVPN/openvpn/commit/65f6da8eeb84fbcea357765e13fa73d0169a143c It seems to be the change that is causing most issues. Thank you for maintaining such an important package!
Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
Package: wireplumber Version: 0.4.10-2 Severity: important X-Debbugs-Cc: hert...@debian.org, gland...@debian.org, team+pkg-mozi...@tracker.debian.org Control: affects -1 firefox Hello, Following the recommendation of https://tracker.debian.org/news/1329911/accepted-pipewire-media-session-041-3-source-into-unstable/ I installed "wireplumber". But after having switched, Firefox started to behave strangely: any time that I would "right click" on a link or a field, or anywhere where you can expect the right click to open a contextual menu, it would "freeze" for a varying number of seconds and it would not display the contextual menu once the freeze was over. I switched back to pipewire-media-session and I created /usr/share/pipewire/media-session.d/with-pulseaudio to get the sound back and it works again now. I'm not sure how both behaviour are related, but they seem to clearly be related. When I had the issue, I tried to open "about:support", it also triggered one of those freezes but in the end I was able to see that firefox was using "alsa" as audio-backend. Now that I switched back to "pipewire-media-session" and that firefox is now behaving correctly, I see that it uses the "pulse-rust" audio backend. So somehow, wireplumber + pipewire-pulse is not properly detected as something that can be controlled with the "pulse-rust" audio backend when it likely should be that way... I don't know if this needs a fix in firefox or in wireplumber. I'm assigning it wireplumber for a start but I have cced Mike Hommey (the firefox maintainer). Thank you all for your great work on those packages! -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 wireplumber depends on: ii init-system-helpers 1.63 ii libc6 2.33-7 ii libglib2.0-0 2.72.2-2 ii libpipewire-0.3-0 0.3.51-1+b1 pn libwireplumber-0.4-0 ii pipewire 0.3.51-1+b1 Versions of packages wireplumber recommends: ii pipewire-pulse 0.3.51-1+b1 Versions of packages wireplumber suggests: pn libspa-0.2-bluetooth
Bug#1012241: dia: depends on libgtk2.0-dev
Package: dia Version: 0.97.3+git20220525-1 Severity: minor Hi, The new dia package depends on libgtk2.0-dev, which itself depends on other headers packages, resulting in nearly 70 new packages to install on an upgrade of dia. I may be wrong but I thought that binary packages are not supposed to depend on headers packages. I think this should be fixed. Regards, -- Raphaël Halimi OpenPGP_signature Description: OpenPGP digital signature
Bug#1011292: openssh-client: scp -O should be doable with a configuration file entry (in ~/.ssh/config)
Package: openssh-client Version: 1:9.0p1-1+b1 Severity: wishlist Tags: upstream X-Debbugs-Cc: raph...@freexian.com dput and dput-ng are using "scp" and don't offer any simple way to configure command line parameters and the switch to "sftp-behind-the-back" broke dput for me with some targets (cf #1011063). I would have liked to be able to add something like this in ~/.ssh/config: Host deb.freexian.com UseLegacyScp true And be done with it. But there's no such option. It would be nice if upstream could implement this. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 openssh-client depends on: ii adduser 3.121 ii dpkg 1.21.7 ii libc6 2.33-7 ii libedit2 3.1-20210910-1 ii libfido2-11.11.0-1+b1 ii libgssapi-krb5-2 1.19.2-2+b2 ii libselinux1 3.3-1+b2 ii libssl3 3.0.3-4 ii passwd1:4.11.1+dfsg1-2 ii zlib1g1:1.2.11.dfsg-4 Versions of packages openssh-client recommends: ii xauth 1:1.1.1-1 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere ii ssh-askpass-gnome [ssh-askpass] 1:9.0p1-1+b1 -- no debconf information
Bug#1011291: dput: scp upload method can break due to implicit sftp usage
Source: dput Version: 1.1.0 Severity: important X-Debbugs-Cc: raph...@freexian.com This is the equivalent of #1011063 for dput instead of dput-ng. When you run dput with openssh >= 9, and when dput is configured to use "scp", "scp" will rely on the sftp protocol to do its job (unless you pass the -O command line parameter). When the server side has configured a forced command to restrict scp to a specific directory (which is a good practice given scp's deficiencies), then scp will badly fail. Here's an example script that is configured with a ForceCommand associated to the SSH key used for upload: #!/bin/sh case "$SSH_ORIGINAL_COMMAND" in scp\ *) exec scp -p -d -t /srv/deb.freexian.com/extended-lts/incoming ;; chmod\ *) find /srv/deb.freexian.com/extended-lts/incoming -user $(whoami) -type f | xargs --no-run-if-empty chmod 0644 exit 0 ;; *) echo "ERROR: Forbidden command: $SSH_ORIGINAL_COMMAND" echo "This SSH access can only be used to upload Debian packages." exit 1 ;; esac A recent scp will call /usr/lib/sftp-server as the remote command and the case will match the third case and the sftp protocol will be confused by the answer. There's no good way to tweak that script to force sftp-server to be restricted to a specific directory. So either you switch to always "sftp" and do some other setup to restrict sftp (with the Chroot directive), or you switch to "always plain scp" by passing -O when you call scp. Thus I'm suggesting that dput starts passing -O to scp when it detects a recent OpenSSH. Or at least that it offers a way to pass command line options to scp. AfAIK ssh_config_options does not work for this. I's not an option that can be passed to "-o" and it's really specific to scp and not to ssh (which also gets called for the chmod IIRC). Note that my "proper" fix to this regression has been to force usage of sftp and to restrict sftp-server to a chroot, but dput has no support of sftp so I had to switch to dput-ng. It would certainly makes sense for dput to gain an sftp method! Cheers, -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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
Bug#1008773: ftpsync: Using commands with parameters as hooks breaks ftpsync on bullseye/debian 11
Package: ftpsync
Version: 20180513+nmu1
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: hert...@debian.org
Control: affects -1 mirrors
In Kali we have started to switch some mirrors to Debian 11 and ftpsync
started to fail with errors like this:
Apr 01 06:19:32 poseidon ftpsync-kali[191329]: Mirrorsync start
Apr 01 06:19:32 poseidon ftpsync-kali[191329]: We got pushed from 192.99.45.140
/home/archvsync/bin/ftpsync: line 276: local: `--regex=^.*\.hook1$': not a
valid identifier
/home/archvsync/bin/ftpsync: line 276: local: `--arg=kali': not a valid
identifier
/home/archvsync/bin/ftpsync: line 276: local: `/home/archvsync/hooks': not a
valid identifier
Apr 01 06:19:32 poseidon ftpsync-kali[191329]: Mirrorsync done with errors
Our ftpsync.conf contains entries like this:
## Configure hooks
HOOK1="run-parts --regex=^.*\\.hook1\$ --arg=kali /home/archvsync/hooks"
HOOK2="run-parts --regex=^.*\\.hook2\$ --arg=kali /home/archvsync/hooks"
HOOK3="run-parts --regex=^.*\\.hook3\$ --arg=kali /home/archvsync/hooks"
HOOK4="run-parts --regex=^.*\\.hook4\$ --arg=kali /home/archvsync/hooks"
HOOK5="run-parts --regex=^.*\\.hook5\$ --arg=kali /home/archvsync/hooks"
>From a quick glance, it looks like the bash version in bullseye doesn't
like some construct. Here's a minimal reproducer:
$ cat ~/tmp/test.sh
#!/bin/bash
set -e
set -u
set -E
hook () {
ARGS='HOOK[@]'
local "${!ARGS}"
echo "HOOKSCR='$HOOKSCR'"
}
HOOK1="run-parts --regex=^.*\\.hook1\$ --arg=kali /home/archvsync/hooks"
HOOK=(
HOOKNR=1
HOOKSCR=${HOOK1}
)
hook $HOOK
In buster it works fine:
$ bash ~/tmp/test.sh
HOOKSCR='run-parts --regex=^.*\.hook1$ --arg=kali /home/archvsync/hooks'
$ echo $?
0
In bullseye it fails:
$ bash ~/tmp/test.sh
/home/rhertzog/tmp/test.sh: line 9: local: `--regex=^.*\.hook1$': not a valid
identifier
/home/rhertzog/tmp/test.sh: line 9: local: `--arg=kali': not a valid identifier
/home/rhertzog/tmp/test.sh: line 9: local: `/home/archvsync/hooks': not a valid
identifier
$ echo $?
1
It seems that you can quote the variable assignation for HOOKSCR and it
works again:
HOOK=(
HOOKNR=1
HOOKSCR="${HOOK1}"
)
$ bash ~/tmp/test.sh
HOOKSCR='run-parts --regex=^.*\.hook1$ --arg=kali /home/archvsync/hooks'
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500,
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.16.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 ftpsync depends on:
ii postfix [mail-transport-agent] 3.6.4-1+b1
ii rsync 3.2.3-8
Versions of packages ftpsync recommends:
ii curl 7.82.0-2
ftpsync suggests no packages.
-- no debconf information
Bug#1005812: dkms: modules are not deleted anymore when a kernel package is removed
Package: dkms
Version: 2.8.7-2
Severity: important
Tags: patch
Hi,
Due to two typos in /etc/kernel/prerm.d/dkms, modules built with DKMS
are not deleted anymore when a kernel package is removed.
The script fails to build the two variables "$name" and "$vers" because
the final pipe to "cut -d" is put outside the backquotes. The call to
"dkms remove" then fails with an error.
Attached is a small patch to fix the problem in the prerm script.
It would also be nice to advise users (with a note on package upgrade
for example) to clean up old leftover modules, or even better, run a
script to do it automatically (basically the logic would list the
installed modules with dkms status, and clear them if that's the only
file left in /lib/modules//). I can write it for you if
you want.
Regards,
--
Raphaël Halimi
--- /etc/kernel/prerm.d/dkms.orig 2021-10-01 11:34:34.0 +0200
+++ /etc/kernel/prerm.d/dkms 2022-02-15 15:19:49.616611838 +0100
@@ -13,8 +13,8 @@
if [ -x /usr/sbin/dkms ]; then
while read line; do
- name=`echo "$line" | awk '{print $1}' | sed 's/,$//'` | cut -d'/' -f1
- vers=`echo "$line" | awk '{print $1}' | sed 's/,$//'` | cut -d'/' -f2
+ name=`echo "$line" | awk '{print $1}' | sed 's/,$//' | cut -d'/' -f1`
+ vers=`echo "$line" | awk '{print $1}' | sed 's/,$//' | cut -d'/' -f2`
arch=`echo "$line" | awk '{print $3}' | sed 's/:$//'`
echo "dkms: removing: $name $vers ($inst_kern) ($arch)" >&2
dkms remove -m $name -v $vers -k $inst_kern -a $arch
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1005375: tlp: External screen does not work when connected to laptop
Le 12/02/2022 à 11:17, Matthias Brennwald a écrit : Dear Maintainer, After I installed TLP on my laptop, the external screen connected via USB-C docking station did not work anymore. Once I uninstalled TLP and a cold-reboot, the screen came back and worked again normally. Hi, Please take a look at the configuration file. Did you try whitelisting your screen in with the option "USB_DENYLIST=" ? Regards, -- Raphaël Halimi OpenPGP_signature Description: OpenPGP digital signature
Bug#1005159: xrdp: please also source ~/.profile in startwm.sh
Package: xrdp Version: 0.9.17-2 Severity: normal Tags: patch Hi, /etc/xrdp/startwm.sh doesn't source $HOME/.profile, which results in $HOME/.local/bin not being in $PATH when a terminal is opened (most terminals execute non-login shells by default). GDM does it in /etc/gdm3/Xsession, and I guess it's also implicitly done by startx too (since a console login is a login shell, so ~/.profile would be sourced, and $PATH would be inherited by terminals opened in the X server started by startx; I didn't test this but this seems logical), so I think it's safe. I tried on my PC by directly modifying /etc/xrdp/startwm.sh and this worked as intended, with no visible side-effects. Thanks ! Regards, -- Raphaël Halimi From c8fdd8a7f3f151fd9269e59b57ba7280afcee360 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rapha=C3=ABl=20Halimi?= Date: Mon, 7 Feb 2022 20:35:10 +0100 Subject: [PATCH] startwm.sh: source ~/.profile too --- debian/startwm.sh | 4 1 file changed, 4 insertions(+) diff --git a/debian/startwm.sh b/debian/startwm.sh index 3127740a..a1d08c1a 100755 --- a/debian/startwm.sh +++ b/debian/startwm.sh @@ -10,5 +10,9 @@ if test -r /etc/profile; then . /etc/profile fi +if test -r $HOME/.profile; then + . $HOME/.profile +fi + test -x /etc/X11/Xsession && exec /etc/X11/Xsession exec /bin/sh /etc/X11/Xsession -- 2.34.1 OpenPGP_signature Description: OpenPGP digital signature
Bug#1005132: drf-yasg-nonfree: File conflicts between two different 1.20.1-1 versions
Source: drf-yasg-nonfree Version: 1.20.1-1 Severity: serious User: de...@kali.org Usertags: origin-kali drf-yasg-nonfree 1.20.1-1 was uploaded as source only on January 23th, the lack of binaries ended up in the package being removed by dak's auto-cruft. Then the maintainer rebuilt a new source package while keeping the 1.20.1-1 version and uploaded it again. deb.debian.org is a CDN and keeps in cache the package files for a very long time because they are supposed to be immutable so if you try to download drf-yasg-nonfree from deb.debian.org you get the first version of the package while the metadata refers to the second version and as such you get a checksum error (as I did in Kali, while trying to mirror bookworm): Wrong checksum during receive of 'http://deb.debian.org/debian/pool/non-free/d/drf-yasg-nonfree/drf-yasg-nonfree_1.20.1-1.dsc': md5 expected: 5c87ae878afc6adf6708439e2a0b4e97, got: 63c6925011f77e02306f451036181a13 sha256 expected: 2b3265636ef93b490b633cee9897c8462fb1cb42d1fb65226fb5a8601631ecd9, got: 834fa39b7b970704f936fc2a293ca47f9efc1939a62f5a33fcd0cea4e4a0767c size expected: 2467, got: 2434 This bug is just a request to upload 1.20.1-2 to get rid of this inconsistency that will last in deb.debian.org for as long as we don't upload a new version. The package has been temporarily removed from testing by Julien Cristau to make sure that mirroring bookworm out of deb.debian.org will work again shortly. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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
Bug#1003927: debian-cd: Move grub-theme for UEFI boot from debian-cd to debian-installer?
Package: debian-cd,debian-installer Severity: wishlist User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: raph...@offensive-security.com Hello, we were trying to harmonize our grub theme across all of Kali and we (re-)discovered that for installer images, the grub theme is actually handled at the debian-cd level (./data/$RELEASE/grub-theme.in used by tools/boot/$RELEASE/boot-x86). I believe that a derivative distribution should not have to fork debian-cd to be able to customize the grub theme. It would be much more logical if debian-cd reused files from debian-installer also for all its handling of grub for UEFI boot. That's why this bug is filed against both packages together, we really need some coordination here. Note that this move would also help to fix #982496 where we ask arm64 boot to make use of the grub theme. I don't have any concrete proposal or patch but I wanted to have this properly recorded. For now in Kali we have worked around this limitation in our build scripts to not have to fork debian-cd and still ship our own theme: https://gitlab.com/kalilinux/build-scripts/live-build-config/-/commit/bb399b8bf63635f53d2ab546f41d1924a5c84467 Given that d-i already provides syslinux configuration files, couldn't it also provide grub configuration files instead of letting debian-cd do its own grub port of those files? Cheers, Raphaël.
Bug#1003478: python-django: cannot import name 'RequestSite' from partially initialized module 'django.contrib.sites.requests' (most likely due to a circular import)
Source: python-django Version: 2:2.2.25-1~deb11u1 Severity: important Tags: patch X-Debbugs-Cc: hert...@debian.org Hello, Ever since we upgraded tracker.debian.org to Debian 11, I started to get occasional failures like shown in the traceback below. File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner 34. response = get_response(request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response 115. response = self.process_exception_by_middleware(e, request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response 113. response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python3/dist-packages/django/contrib/syndication/views.py" in __call__ 39. feedgen = self.get_feed(obj, request) File "/usr/lib/python3/dist-packages/django/contrib/syndication/views.py" in get_feed 127. current_site = get_current_site(request) File "/usr/lib/python3/dist-packages/django/contrib/sites/shortcuts.py" in get_current_site 15. from .requests import RequestSite Exception Type: ImportError at /pkg/gdb/rss Exception Value: cannot import name 'RequestSite' from partially initialized module 'django.contrib.sites.requests' (most likely due to a circular import) (/usr/lib/python3/dist-packages/django/contrib/sites/requests.py) I filed this upstream at https://code.djangoproject.com/ticket/33420 and I was told that this has been fixed recently in the main branch with this commit: https://code.djangoproject.com/changeset/78163d1ac4407d59bfc5fdf1f84f2dbbb2ed3443/ But this has not been backported to older branches and it would be nice to see this fixed in Debian stable (and bullseye-backport for 3.2) for the benefit of tracker.debian.org and other Django packaged applications. Cheers, -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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
Bug#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name
Package: autopkgtest Version: 5.19 Severity: normal User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: hert...@debian.org Usage of --pin-packages=kali-dev=src:foo results in a file like this in /etc/apt/preferences.d/autopkgtest-kali-dev Package: foo Pin: release a=kali-dev Pin-Priority: 995 Unfortunately the "a=kali-dev" only matches on the "Suite" or "Archive" field in the Release file, and not on the "Codename" field (which in my caces was the only field available). I noticed that /etc/apt/preferences.d/autopkgtest-default-release uses another syntax that seems to cover more cases: Package: * Pin: release kali-rolling Pin-Priority: 990 However that syntax doesn't seem to be documented in apt_preferences. If it's correct and allows to check on either of the 3 fields, then we should likely use the same syntax in both files. Otherwise I would like to suggest to create two entries, one with "Pin: release a=foo" and one with "Pin: release n=foo" so that we are sure to match on any of the 3 fields. Cheers, -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 autopkgtest depends on: ii apt-utils 2.3.13 ii libdpkg-perl1.21.1 ii procps 2:3.3.17-5 ii python3 3.9.8-1 ii python3-debian 0.1.42 Versions of packages autopkgtest recommends: ii autodep8 0.25 Versions of packages autopkgtest suggests: pn fakemachine pn lxc pn lxd ii ovmf 2021.11-1 pn ovmf-ia32 pn qemu-efi-aarch64 pn qemu-efi-arm pn qemu-system ii qemu-utils1:6.1+dfsg-8+b2 ii schroot 1.6.10-12 ii vmdb2 0.24-1 -- no debconf information
Bug#998319: tryton-server: Should provide a ready-to-use production-grade server config
Package: tryton-server Version: 5.0.39-1 Severity: normal X-Debbugs-Cc: raph...@freexian.com When I deployed tryton-server, I simply followed the advice of README.Debian and relied on the provided systemd service file but now after having filed https://bugs.tryton.org/issue10921 I realize that it's (no longer?) the recommended way of deploying the tryton server. It would be nice if the Debian package could document a production-grade way to deploy it and if it could provide everything required to make this trivial (maybe some apache/nginx config snippet that we can include in a new virtual host to configure the WSGI handler, or similar). -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 tryton-server depends on: ii adduser3.118 ii init-system-helpers1.60 ii lsb-base 11.1.0 pn python pn python-dateutil pn python-genshi pn python-lxml pn python-pkg-resources pn python-polib pn python-relatorio pn python-sql pn python-werkzeug pn python-wrapt ii python33.9.2-3 ii python3-bcrypt 3.2.0-1 ii python3-dateutil 2.8.1-6 pn python3-genshi ii python3-lxml 4.6.3+dfsg-1 pn python3-passlib ii python3-pkg-resources 58.2.0-1 pn python3-polib pn python3-relatorio pn python3-sql pn python3-werkzeug ii python3-wrapt 1.12.1-4+b1 Versions of packages tryton-server recommends: ii libreoffice-calc 1:7.2.2-1 ii libreoffice-writer 1:7.2.2-1 ii postgresql 14+231 pn python-bcrypt pn python-levenshtein pn python-psycopg2 pn python-pydot pn python3-gevent ii python3-html2text2020.1.16-1 ii python3-levenshtein 0.12.2-2 ii python3-pil 8.3.2-1 ii python3-psycopg2 2.9.1-1 ii python3-pydot1.4.2-1 pn python3-weasyprint ii ssl-cert 1.1.0+nmu1 ii unoconv 0.7-2 Versions of packages tryton-server suggests: ii postgresql-client-13 [postgresql-client] 13.4-3 ii postgresql-client-14 [postgresql-client] 14.0-1 pn python-sphinx ii python3-sphinx4.2.0-5 hi tryton-client 5.0.33-1 pn tryton-modules-all pn tryton-server-doc
Bug#996776: RM: logidee-tools -- ROM; no longer maintained and no longer used
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: hert...@debian.org The logidee tools are no longer maintained by anybody and I kept them alive for as long as I had some use for them but the Logidée company that created them is no longer using them and nobody else in Debian is using them either (me included). The package is currently affected by an RC bug that I don't intend to fix. Please remove logidee-tools from Debian. Thank you.
Bug#996703: RM: gnome-shell-timer -- ROM; No upstream maintainer
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: hert...@debian.org The upstream maintainer has abandoned this extension a long time ago. I kept it alive for as long as I was using it but I'm no longer using it as there's a better maintained alternative (though I haven't packaged it): https://github.com/blackjackshellac/kitchenTimer https://extensions.gnome.org/extension/3955/kitchen-timer/ So please remove gnome-shell-timer from Debian. Thank you.
Bug#994808: atftpd: Impossible to upgrade from 0.7.git20210202-3
Package: atftpd Version: 0.7.git20210202-3 Severity: important User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: hert...@debian.org Hello, In 0.7.git20210202-4 you fixed the syntax of /etc/default/atftpd but anyone that installed -1, -2 or -3 has a failed upgrade due to this syntax mistake. And the error message is very misleading for casual users and thus not trivial to fix: Preconfiguring packages ... /tmp/atftpd.config.b3vwmj: 3: /etc/default/atftpd: 69: not found atftpd failed to preconfigure, with exit status 127 [...] Setting up atftpd (0.7.git20210202-4+b1) ... /var/lib/dpkg/info/atftpd.config: 3: /etc/default/atftpd: 69: not found dpkg: error processing package atftpd (--configure): installed atftpd package post-installation script subprocess returned error exit status 127 Unfortunately, the version -3 reached Debian testing (some simple autopkgtest could have avoided this) and was thus released as part of Kali and we have many users that have thus installed -3. Can we please include some upgrade code that detects the broken case and fix it up? Thank you in advance. -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 atftpd depends on: ii debconf [debconf-2.0] 1.5.77 ii init-system-helpers1.60 ii libc6 2.32-4 ii libpcre3 2:8.39-13 ii libwrap0 7.6.q-31 ii lsb-base 11.1.0 ii tcpd 7.6.q-31 ii update-inetd 4.51 Versions of packages atftpd recommends: ii openbsd-inetd [inet-superserver] 0.20160825-5 Versions of packages atftpd suggests: ii logrotate 3.18.1-2
Bug#992966: simple-cdd: fails to validate Release file with a good signature and a signature that can't be checked
Package: simple-cdd Version: 0.6.8 Severity: normal X-Debbugs-Cc: raph...@freexian.com Right now if you try to use simple-cdd on a stretch or buster system (to build stretch/buster images), you get failures like this one: > 2021-08-24 10:45:08 ERROR verify gpg signature exited with code 2 > 2021-08-24 10:45:08 ERROR Last 3 lines of standard error: > 2021-08-24 10:45:08 ERROR verify gpg signature: gpg: Signature made Tue 24 > Aug 2021 09:21:34 AM CDT > 2021-08-24 10:45:08 ERROR verify gpg signature: gpg:using RSA > key A7236886F3CCCAAD148A27F80E98404D386FA1D9 > 2021-08-24 10:45:08 ERROR verify gpg signature: gpg: Can't check signature: > No public key > 2021-08-24 10:45:08 ERROR Signature verification failed on ['gpg', '--batch', > '--no-default-keyring', '--keyring', > '/usr/share/keyrings/debian-archive-keyring.gpg', '--keyring', > '/srv/install/simple-cdd/.gnupg/pubring.gpg', '--verify', > '/srv/install/simple-cdd/tmp/mirror/extrafiles'] > FAILURE: build-simple-cdd failed, exiting The problem is that the Release file (and the extrafiles) of stretch and buster is signed by 4 keys, including the recently added keys for bullseye. But /usr/share/keyrings/debian-archive-keyring.gpg in stretch/buster does not (yet) contain the new key and simple-cdd uses `gpg --verify` which fails with error code 2 as soon as a single signature can't be verified. But simple-cdd should fail only if none of the signatures can't be verified or if some signature fails to verify while the key is present (a bit like APT does it...). But the absence of a key should not result in a failure provided that the other signatures are working. Elements of proof: $ wget http://debian.backend.mirrors.debian.org/debian/dists/stretch/Release $ wget http://debian.backend.mirrors.debian.org/debian/dists/stretch/Release.gpg $ LANG=C gpg --keyring /srv/chroots/buster-amd64/usr/share/keyrings/debian-archive-keyring.gpg --verify Release.gpg Release gpg: Signature made Sat Aug 14 09:43:24 2021 CEST gpg:using RSA key 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC gpg: Good signature from "Debian Archive Automatic Signing Key (9/stretch) " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: E1CF 20DD FFE4 B89E 8026 58F1 E0B1 1894 F66A EC98 Subkey fingerprint: 16E9 0B3F DF65 EDE3 AA7F 323C 04EE 7237 B7D4 53EC gpg: Signature made Sat Aug 14 09:43:25 2021 CEST gpg:using RSA key 0146DC6D4A0B2914BDED34DB648ACFD622F3D138 gpg: Good signature from "Debian Archive Automatic Signing Key (10/buster) " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 80D1 5823 B7FD 1561 F9F7 BCDD DC30 D7C2 3CBB ABEE Subkey fingerprint: 0146 DC6D 4A0B 2914 BDED 34DB 648A CFD6 22F3 D138 gpg: Signature made Sat Aug 14 10:46:19 2021 CEST gpg:using RSA key A7236886F3CCCAAD148A27F80E98404D386FA1D9 gpg: Can't check signature: No public key gpg: Signature made Sat Aug 14 10:26:43 2021 CEST gpg:using RSA key 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500 gpg:issuer "debian-rele...@lists.debian.org" gpg: Good signature from "Debian Stable Release Key (9/stretch) " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 067E 3C45 6BAE 240A CEE8 8F6F EF0F 382A 1A7B 6500 $ echo $? 2 $ LANG=C gpg --keyring /srv/chroots/buster-amd64/usr/share/keyrings/debian-archive-keyring.gpg --with-subkey-fingerprints --list-keys A7236886F3CCCAAD148A27F80E98404D386FA1D9 gpg: error reading key: No public key $ LANG=C gpg --keyring /usr/share/keyrings/debian-archive-keyring.gpg --with-subkey-fingerprints --list-keys A7236886F3CCCAAD148A27F80E98404D386FA1D9 pub rsa4096 2021-01-17 [SC] [expires: 2029-01-15] 1F89983E0081FDE018F3CC9673A4F27B8DD47936 uid [ unknown] Debian Archive Automatic Signing Key (11/bullseye) sub rsa4096 2021-01-17 [S] [expires: 2029-01-15] A7236886F3CCCAAD148A27F80E98404D386FA1D9 -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 simple-cdd depends on: ii dctrl-tools 2.24-3+b1 ii debian-cd 3.1.35 ii lsb-release 11.1.0 ii python3 3.9.2-3 ii python3-simple-cdd 0.6.8 ii reprepro
Bug#991167: ftpsync: Please document how to contribute
Package: ftpsync Version: 20180513+nmu1 Severity: wishlist User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: raph...@offensive-security.com Looking at the README in https://salsa.debian.org/mirror-team/archvsync I saw no instructions on how to contribute, nor any indication of where bugs are welcome. It would be nice to tell users that found an issue that they can file bugs in the Debian BTS and that they can submit merge requests for patches (or that they can send patch to the BTS if that's your preference). IMO it would make sense to allow GitLab issues on the project too for "upstream change", but YMMV. -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 ftpsync depends on: ii postfix [mail-transport-agent] 3.5.6-1+b1 ii rsync 3.2.3-4 Versions of packages ftpsync recommends: ii curl 7.74.0-1.3+b1 ftpsync suggests no packages. -- no debconf information
Bug#991166: ftpsync: Contents* and dep11/* metadata are incorrectly updated in stage1
Package: ftpsync Version: 20180513+nmu1 Severity: important User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: raph...@offensive-security.com In Kali we encountered many failed "apt update" with a mirror that was slow to update and it always failed due to invalid checksums on "Contents-amd64.gz". Looking more closely, I discovered that "ftpsync" was not really kept up-to-date with other files that are listed in the Release file and that should be updated in stage 2 instead of stage 1. I noticed in particular that dep11/* should also be handled like we do for "i18n/*". And we might want to do it also for MD5SUMS/SHA256SUMS files of debian-installer... although updates there are not very frequent. Thank you in advance! -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 ftpsync depends on: ii postfix [mail-transport-agent] 3.5.6-1+b1 ii rsync 3.2.3-4 Versions of packages ftpsync recommends: ii curl 7.74.0-1.3+b1 ftpsync suggests no packages. -- no debconf information
Bug#990281: APT make duplicate HTTP requests with mirrorbits
Package: apt Version: 2.2.3 Severity: important User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: hert...@debian.org Control: found -1 apt/2.3.6 Hi, in Kali we have been testing "mirrorbits" as a replacement for "mirrorbrain". Our current mirrorbrain setup runs on http.kali.org and mirrorbits runs on http-staging.kali.org. We have seen strange behaviour from APT with mirrorbits where APT seems to send some HTTP requests multiple times. Whereas with mirrorbrain, it's fine. $ cat /etc/apt/sources.list deb http://http-staging.kali.org/kali kali-rolling main contrib non-free $ apt install --dry-run aria2 The following additional packages will be installed: libaria2-0 libsqlite3-0 libssh2-1 The following NEW packages will be installed: aria2 libaria2-0 libsqlite3-0 libssh2-1 0 upgraded, 4 newly installed, 0 to remove. $ sudo apt -y -d -q -o Debug::Acquire::http=true install aria2 2>&1 | grep -A1 ^GET GET /kali/pool/main/s/sqlite3/libsqlite3-0_3.34.1-3_amd64.deb HTTP/1.1 Host: http-staging.kali.org -- GET /pub/Linux/kali/pool/main/s/sqlite3/libsqlite3-0_3.34.1-3_amd64.deb HTTP/1.1 Host: ftp.jaist.ac.jp -- GET /kali/pool/main/libs/libssh2/libssh2-1_1.9.0-2_amd64.deb HTTP/1.1 Host: http-staging.kali.org -- GET /kali/pool/main/a/aria2/libaria2-0_1.35.0-3_amd64.deb HTTP/1.1 Host: http-staging.kali.org -- GET /kali/pool/main/a/aria2/aria2_1.35.0-3_amd64.deb HTTP/1.1 Host: http-staging.kali.org -- GET /kali/pool/main/a/aria2/libaria2-0_1.35.0-3_amd64.deb HTTP/1.1 Host: http-staging.kali.org -- GET /kali/pool/main/a/aria2/aria2_1.35.0-3_amd64.deb HTTP/1.1 Host: http-staging.kali.org -- GET /pub/Linux/kali/pool/main/libs/libssh2/libssh2-1_1.9.0-2_amd64.deb HTTP/1.1 Host: ftp.jaist.ac.jp -- GET /kali/pool/main/a/aria2/libaria2-0_1.35.0-3_amd64.deb HTTP/1.1 Host: mirror.anigil.com -- GET /kali/pool/main/a/aria2/aria2_1.35.0-3_amd64.deb HTTP/1.1 Host: http-staging.kali.org -- GET /kali/pool/main/a/aria2/aria2_1.35.0-3_amd64.deb HTTP/1.1 Host: mirror.anigil.com As you can see, APT seems to send the same HTTP request to mirrorbits multiple times, but the final download happens only once per file. Depending on the exact case, we get fewer duplicate requests, but it's easily reproducible. We tried to compare the HTTP headers returned by the two servers and mirrorbits/nginx sets those headers in addition to the usual ones when it sends its redirect answer (compared to mirrorbrain/apache): Content-Length: 0 Connection: keep-alive Cache-Control: private, no-cache I have also reproduced the issue with apt 2.3.6 in unstable. If you want to reproduce, just tweak your sources.list and install http://http.kali.org/pool/main/k/kali-archive-keyring/kali-archive-keyring_2020.2_all.deb to have the kali archive key to authenticate the repository. -- System Information: Distributor ID: Kali Description:Kali GNU/Linux Rolling Release:2021.1 Codename: kali-rolling Architecture: x86_64 Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages apt depends on: ii adduser 3.118 ii debian-archive-keyring 2019.1 ii gpgv2.2.20-1 ii libapt-pkg6.0 2.1.18 ii libc6 2.31-9 ii libgcc-s1 10.2.1-6 ii libgnutls30 3.7.0-5 ii libseccomp2 2.5.1-1 ii libstdc++6 10.2.1-6 ii libsystemd0 247.2-5 Versions of packages apt recommends: ii ca-certificates 20210119 Versions of packages apt suggests: pn apt-doc pn aptitude | synaptic | wajig ii dpkg-dev 1.20.7.1kali1 ii gnupg2.2.20-1 pn powermgmt-base -- no debconf information
Bug#964906: Same problem here, but not systematic
I have the same problem on two of my servers (both with similar configuration, debian buster with backports), both with a btrfs raid-1 on /root. In my case, initramfs indeed fails to mount /root, but performing a 'btrfs device scan' followed by a manual mount to /root directly on the initramfs prompts solves the problem. However, this problem is not systematically met. Even on the same server, the root may be correctly mounted after a reboot. Maybe there is a race condition, so that the '/usr/share/initramfs-tools/scripts/local-premount/btrfs' may not be launched at the right moment? Hoping this information can help.
Bug#986843: smuxi-engine: Crash when editing server information
Package: smuxi-engine Version: 1.1-1 Severity: important X-Debbugs-Cc: hert...@debian.org I'm trying to edit server information through the gnome frontend and when I validate the changes I get this crash: Exception Type: System.ArgumentNullException Exception Message: Value cannot be null. Parameter name: value Exception StackTrace: at Smuxi.Engine.UserConfig.Set (System.String key, System.Object value) [0x00079] in /build/smuxi-gSW6uG/smuxi-1.1/src/Engine/Config/UserConfig.cs:159 at Smuxi.Engine.UserConfig.set_Item (System.String key, System.Object value) [0x4] in /build/smuxi-gSW6uG/smuxi-1.1/src/Engine/Config/UserConfig.cs:101 at (wrapper remoting-invoke-with-check) Smuxi.Engine.UserConfig.set_Item(string,object) at Smuxi.Engine.ServerModel.Save (Smuxi.Engine.UserConfig config) [0x00135] in /build/smuxi-gSW6uG/smuxi-1.1/src/Engine/Config/ServerModel.cs:232 at Smuxi.Engine.ServerListController.SetServer (Smuxi.Engine.ServerModel server) [0x00029] in /build/smuxi-gSW6uG/smuxi-1.1/src/Engine/Config/ServerListController.cs:178 at Smuxi.Frontend.Gnome.ServerListView.Edit (Smuxi.Engine.ServerModel server) [0x0006e] in /build/smuxi-gSW6uG/smuxi-1.1/src/Frontend-GNOME/Preferences/ServerListView.cs:183 at Smuxi.Frontend.Gnome.ServerListView.OnEditButtonClicked (System.Object sender, System.EventArgs e) [0x0002a] in /build/smuxi-gSW6uG/smuxi-1.1/src/Frontend-GNOME/Preferences/ServerListView.cs:256 I have attached the screenshot of the screen with the data that I'm saving. I do use a ssh connection between the engine and the frontend. The engine side is running smuxi-engine 1.0.7-5. -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 smuxi-engine depends on: ii liblog4net1.2-cil1.2.10+dfsg-7.1 ii libmono-corlib4.5-cil6.8.0.105+dfsg-3 ii libmono-posix4.0-cil 6.8.0.105+dfsg-3 ii libmono-sqlite4.0-cil6.8.0.105+dfsg-3 ii libmono-system-core4.0-cil 6.8.0.105+dfsg-3 ii libmono-system-data-linq4.0-cil 6.8.0.105+dfsg-3 ii libmono-system-data4.0-cil 6.8.0.105+dfsg-3 ii libmono-system-drawing4.0-cil6.8.0.105+dfsg-3 ii libmono-system-runtime-serialization4.0-cil 6.8.0.105+dfsg-3 ii libmono-system-runtime4.0-cil6.8.0.105+dfsg-3 ii libmono-system-web4.0-cil6.8.0.105+dfsg-3 ii libmono-system-xml-linq4.0-cil 6.8.0.105+dfsg-3 ii libmono-system-xml4.0-cil6.8.0.105+dfsg-3 ii libmono-system4.0-cil6.8.0.105+dfsg-3 ii libnini1.1-cil 1.1.0+dfsg.2-5.1 ii mono-runtime 6.8.0.105+dfsg-3 smuxi-engine recommends no packages. Versions of packages smuxi-engine suggests: pn oidentd | ident-server -- no debconf information
Bug#984547: isenkramd failure with with "TypeError: argument should be integer or bytes-like object, not 'str'"
Package: isenkram
Version: 0.45
Severity: serious
X-Debbugs-Cc: hert...@debian.org
I saw this in my logs:
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: Traceback (most recent call
last):
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: File "/usr/bin/isenkramd",
line 400, in uevent_callback
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: if not
is_pkg_installed(pkg):
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: File "/usr/bin/isenkramd",
line 340, in is_pkg_installed
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: if 0 == line.find("ii "):
mars 04 20:22:14 t14-buxy isenkramd.desktop[3020]: TypeError: argument should
be integer or bytes-like object, not 'str'
It looks like that the package was not fully tested in a Python 3 context
as this is a common failure when you mix binary content and text content.
Cheers,
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 isenkram depends on:
ii gir1.2-gtk-3.0 3.24.24-3
ii gir1.2-gudev-1.0 234-1
ii gir1.2-notify-0.7 0.7.9-3
ii gir1.2-packagekitglib-1.0 1.2.2-2
ii isenkram-cli 0.45
ii packagekit 1.2.2-2
ii python33.9.1-1
ii python3-gi 3.38.0-2
isenkram recommends no packages.
isenkram suggests no packages.
-- no debconf information
Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic
Package: general Severity: normal User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: hert...@debian.org, debian-d...@lists.debian.org Control: affects -1 ftp.debian.org dpkg-dev Hi people, After having been bitten (in Kali) by failures to import Debian packages because a PGP signature file has been modified [1], this lead me to think about this problem space and I concluded that the way we are storing such signatures is not appropriate. Those files are not really meant to be immutable: - signing keys can expire and be revoked, upstream might want to update signatures of already released tarballs - the set of "upstream release managers" might evolve over time and the official signature to use might change... If we assume that the archive is meant to store immutable content under a given filename (and to me that requirement seems to be a good idea), then we should question ourselves whether we really want to store those signatures in a filename that's associated to the upstream version. They should either be tied to the Debian revision (so that they can change over time without any new upstream release) or be incorporated in the Debian tarball. After all the key to verify those signatures is already stored in the Debian tarball (when you use the uscan feature to verify those signatures), so why not store the signature there as well? I originally filed this in https://bugs.debian.org/949962 against ftp.debian.org but the bug got closed because it's not really the responsibility of ftpmasters to change this. So I'm starting a wider discussion to gather feedback of all interested parties (at least Guillem as dpkg maintainer). I won't drive this much further but I wanted to have it properly recorded and considered. Cheers, [1] For details it happened in dbus-glib: https://snapshot.debian.org/package/dbus-glib/0.110-2/ -> it has .asc file https://snapshot.debian.org/package/dbus-glib/0.110-3/ -> no .asc https://snapshot.debian.org/package/dbus-glib/0.110-4/ -> no .asc https://snapshot.debian.org/package/dbus-glib/0.110-5/ -> it has a different .asc file
Bug#982496: debian-cd: Support grub theme on arm64
Package: debian-cd Version: 3.1.33 Severity: wishlist User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: raph...@offensive-security.com We're working on getting Kali to work as a VM on the Apple M1 and so we are trying to build arm64 installer images with simple-cdd (and thus debina-cd). In this process, Steev Klimaszewski discovered that the grub configuration used for the EFI boot on arm64 does not take advantage of any theming, contrary to amd64/i386. It would be nice if we could fix this by enabling the grub theme everywhere. However this doesn't look entirely trivial as the theming is handled through a mixture of code in tools/boot/bullseye/boot-x86 and tools/boot/bullseye/parse_isolinux, and arm64 is not relying on isolinux at all. Steve, your input is thus most welcome. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 debian-cd depends on: ii apt2.1.18 ii bc 1.07.1-2+b2 ii bzip2 1.0.8-4 ii cpp4:10.2.1-1 ii curl 7.74.0-1 ii dctrl-tools [grep-dctrl] 2.24-3+b1 ii dpkg-dev 1.20.7.1 ii genisoimage9:1.1.11-3.2 pn libcompress-zlib-perl pn libdigest-md5-perl ii libdpkg-perl 1.20.7.1 ii lynx 2.9.0dev.6-1 ii make 4.3-4 ii perl [libdigest-sha-perl] 5.32.1-2 ii tofrodos 1.7.13+ds-5 ii wget 1.21-1+b1 ii xorriso1.5.2-1 Versions of packages debian-cd recommends: ii dosfstools 4.1-2 ii hfsutils 3.2.6-15 ii isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii mtools 4.0.26-1 ii netpbm 2:10.0-15.3+b2 ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii syslinux-utils 3:6.04~git20190206.bf6db5b4+dfsg1-3 debian-cd suggests no packages. -- no debconf information
Bug#981007: systemd: default syscall-filter list is incomplete for i386 and breaks tar
Package: systemd Version: 241-7~deb10u5 Severity: important Tags: patch upstream User: de...@kali.org Usertags: origin-kali Control: fixed -1 systemd/244.1-1 We are running dist-upgrade tests within systemd-nspawn containers and since we upgraded to buster, our i386 tests, running on an amd64 host machine, are failing with messages like this one: --- Fetched 7044 MB in 1617d 11h 20min 34s (50 B/s) tar: ./control: Cannot utime: Operation not permitted tar: ./md5sums: Cannot utime: Operation not permitted tar: ./shlibs: Cannot utime: Operation not permitted tar: ./symbols: Cannot utime: Operation not permitted tar: ./triggers: Cannot utime: Operation not permitted tar: .: Cannot utime: Operation not permitted tar: Exiting with failure status due to previous errors dpkg-deb: error: tar subprocess returned error exit status 2 --- Thanks to https://bugzilla.redhat.com/show_bug.cgi?id=1770154 I understood that this is actually related to the lack of some system calls in the default whitelist maintained by systemd. This has been fixed with this upstream pull request: https://github.com/systemd/systemd/pull/13975 So this issue is only affecting the stable version 241-7~deb10u5. The version in buster-backports is fine, as is the version in testing/unstable. But it would still be nice if this could be fixed via a point release. Thanks for maintaining systemd!
Bug#979233: lshw-gtk: Drop recommends on menu
Package: lshw-gtk Version: 02.18.85-0.5 Severity: normal Please drop the recommends on "menu". AFAIK the menu package does not add any functionality to your application. Applications should not depend/recommend menu, only window managers or desktop that benefit from the menu system should trigger its installation. Thank you! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lshw-gtk depends on: ii libc6 2.31-6 ii libgcc-s1 10.2.1-3 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-02.66.4-1 ii libgtk2.0-0 2.24.33-1 ii libstdc++6 10.2.1-3 Versions of packages lshw-gtk recommends: pn menu ii pciutils 1:3.7.0-5 ii usbutils 1:013-1 lshw-gtk suggests no packages. -- no debconf information
Bug#977355: UserWarning: cannot parse package relationship "i", returning it raw
Package: python3-debian
Version: 0.1.35
Severity: normal
The package tracker started to generate annoying messages in its cron job:
/usr/lib/python3/dist-packages/debian/deb822.py:1403: UserWarning: cannot parse
package
relationship "i", returning it raw
' relationship "%s", returning it raw' % raw)
This is due to a buggy package containing a dependency on "i" (it's
libmagics++-dev, bug filed already) but I don't see any reason for deb822
to fail on this dependency. It's a very short package name that we should
likely not allow in Debian but I don't a reason to not be able to parse
it (in particular when nothing else in the build machinery choked on that
dependency, starting with dpkg-gencontrol).
Please update the __dep_RE regex to accept single-character dependencies:
1421 __dep_RE = re.compile(
1422 r'^\s*(?P[a-zA-Z0-9.+\-]{2,})'
Cheers,
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 python3-debian depends on:
ii python3 3.9.0-4
ii python3-chardet 3.0.4-7
ii python3-six 1.15.0-2
Versions of packages python3-debian recommends:
ii python3-apt 2.1.7
Versions of packages python3-debian suggests:
ii gpgv 2.2.20-1
-- no debconf information
Bug#976823: uscan: have an official way to document that there's no upstream source anymore
Package: devscripts Version: 2.20.5 Severity: wishlist User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: jel...@debian.org There are cases where there's no upstream source anymore so we have nothing to put into debian/watch (either because there never was a real upstream or because the upstream repository disappeared). At the same time, the lack of debian/watch might just mean that someone forgot to create the file. So what I usually do is that I create a debian/watch file documenting the fact that I can't put anything in it... but the result is that uscan will fail and tools like the janitor bot that try to import a new upstream release will log an error, drawing the attention of developers on this specific package. Example: $ cat debian/watch version=3 # This is just a script that was posted on a website. No download available. $ uscan --report; echo $? 1 It would be better if there was a way to document that there's no upstream source and let uscan succeed while printing a warning. Maybe with a specific optional flag say "no-upstream". Desired result: $ cat debian/wa version=4 opts=no-upstream $ uscan --report; echo $? uscan info: no upstream sources are known, skipping without failing 0 Thank you for considering this request!
Bug#976372: gnome-shell-xrdesktop: FTBFS and is not built against latest libmutter
Package: gnome-shell-xrdesktop Version: 3.36.1-2 Severity: serious Justification: FTBFS User: de...@kali.org Usertags: origin-kali I noticed gnome-shell-xrdesktop depends on libmutter-6-0 which is obsolete in unstable. I wanted to rebuild the package to have it link against a newer mutter version but the package failed to build for me: PKG_CONFIG_PATH: Called `/usr/bin/pkg-config --modversion xrdesktop-0.14` -> 1 CMake binary for MachineChoice.BUILD is not cached None of 'CMAKE' are defined in the environment, not changing global flags. CMake binary missing from cross or native file, or env var undefined. Trying a default CMake fallback at cmake Did not find CMake 'cmake' Found CMake: NO No CMake binary for machine 0 not found. Giving up. Run-time dependency xrdesktop-0.14 found: NO (tried pkgconfig) ../meson.build:107:0: ERROR: Dependency "xrdesktop-0.14" not found, tried pkgconfig dh_auto_configure: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu --libdir=/usr/lib -Dbash_completion=true -Denable-networkmanager=yes -Denable-systemd=yes returned exit code 1 make[1]: *** [debian/rules:26: override_dh_auto_configure] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:17: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 gnome-shell-xrdesktop depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-1 ii evolution-data-server3.38.1-2 ii gir1.2-accountsservice-1.0 0.6.55-3 ii gir1.2-atspi-2.0 2.38.0-2 ii gir1.2-freedesktop 1.66.1-1+b1 ii gir1.2-gcr-3 3.38.0-1 ii gir1.2-gdesktopenums-3.0 3.38.0-2 ii gir1.2-gdm-1.0 3.38.2-1 ii gir1.2-geoclue-2.0 2.5.6-1 ii gir1.2-glib-2.0 1.66.1-1+b1 ii gir1.2-gnomebluetooth-1.03.34.3-2 ii gir1.2-gnomedesktop-3.0 3.38.2-1 ii gir1.2-gtk-3.0 3.24.23-3 ii gir1.2-gweather-3.0 3.36.1-1 ii gir1.2-ibus-1.0 1.5.23-1 pn gir1.2-mutter-6 ii gir1.2-nm-1.01.27.91-2 ii gir1.2-nma-1.0 1.8.30-1 ii gir1.2-pango-1.0 1.46.2-3 ii gir1.2-polkit-1.00.105-29 ii gir1.2-rsvg-2.0 2.50.2+dfsg-1 ii gir1.2-soup-2.4 2.72.0-2 ii gir1.2-upowerglib-1.00.99.11-2 ii gjs 1.66.1-1 ii gnome-backgrounds3.38.0-1 ii gnome-settings-daemon3.38.1-2 pn gnome-shell-common-xrdesktop ii gsettings-desktop-schemas3.38.0-2 ii libatk-bridge2.0-0 2.38.0-1 ii libatk1.0-0 2.36.0-2 ii libc62.31-4 ii libcairo21.16.0-4 ii libecal-2.0-13.38.1-2 pn libedataserver-1.2-24 ii libgcr-base-3-1 3.38.0-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-8 ii libgirepository-1.0-11.66.1-1+b1 ii libgjs0g 1.66.1-1 ii libgles2 1.3.2-1 ii libglib2.0-0 2.66.3-1 ii libglib2.0-bin 2.66.3-1 ii libgnome-autoar-0-0 0.2.4-2 ii libgnome-desktop-3-193.38.2-1 ii libgraphene-1.0-01.10.2-1 ii libgstreamer1.0-01.18.1-1 ii libgtk-3-0 3.24.23-3 pn libgulkan-0.14-0 ii libical3 3.0.8-2 pn libinputsynth-0.13-0 ii libjson-glib-1.0-0 1.6.0-1 pn libmutter-6-0 ii libnm0
Bug#976083: lintian: reports spelling-error-in-changelog for duplicate word even when punctuation and empty line separate two words
Package: lintian Version: 2.103.0 Severity: normal I have this warning: W: ccrypt: spelling-error-in-changelog Debian Debian (duplicate word) Debian And I believe it matches this part of the changelog entry: * Configure git-buildpackage for Debian [ Debian Janitor ] For me, it should not report this duplicate word. The empty line (and even the square bracket) should be enough to not trigger the duplicate word warning. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lintian depends on: ii binutils2.35.1-3 ii bzip2 1.0.8-4 ii diffstat1.63-1 ii dpkg1.20.5 ii dpkg-dev1.20.5 ii file1:5.39-3 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b4 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b6 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl1.20.5 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1 ii libhtml-html5-entities-perl 0.004-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.416-1+b6 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004003-1 ii libmoox-aliases-perl0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.114-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-1 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012000-1 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.05-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip1.21-8 ii lzop1.04-2 ii man-db 2.9.3-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.0-5 ii t1utils 1.41-4 ii unzip 6.0-25 ii xz-utils5.2.4-1+b1 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.59-1 -- no debconf information
Bug#976073: sbuild: support "podman" as chroot mode and provide a sbuild-create-oci command (built on top of buildah)
Package: sbuild Version: 0.80.0 Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org I know that multiple developers started using podman and buildah to manage containers where they build their Debian packages. With user namespace supports, this allows rootless building (like the "unshare" chroot mode)... you don't even need root to setup the "build chroot" since those are containers that you can download (or rebuild if you prefer). Thus it would be nice if sbuild had a "podman" chroot mode where it could use podman containers to build the packages. A "sbuild-create-oci" command would also be helpful to build the various container images, either from scratch (so that you don't have to trust images that you download) or on top of pre-existing OCI images (to save time and effort). That command should not be hard to build on top of buildah. Some links: http://tauware.blogspot.com/2020/04/building-packages-with-buildah-in-debian.html https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/ -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 sbuild depends on: ii adduser 3.118 ii libsbuild-perl 0.80.0 ii perl5.32.0-5 Versions of packages sbuild recommends: ii autopkgtest 5.15 ii debootstrap 1.0.123 ii schroot 1.6.10-11 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.45.6-1 ii kmod 27+20200310-2 ii wget 1.20.3-1+b3 -- no debconf information
Bug#975974: ITP: gnome-shell-extension-hamster -- GNOME Shell extension for the Hamster Time Tracker
Package: wnpp Severity: wishlist Owner: Raphaël Hertzog X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gnome-shell-extension-hamster Version : 0.10.0+git20200509 Upstream Author : Hamster Project * URL : https://github.com/projecthamster/hamster-shell-extension * License : GPL-3+ Programming Lang: Javascript Description : GNOME Shell extension for the Hamster Time Tracker The package will be maintained together with hamster-time-tracker in https://salsa.debian.org/projecthamster-team/
Bug#972726: dh-python: uninstallable when python-is-python2 is installed
Package: dh-python Version: 4.20200925 Followup-For: Bug #972726 User: de...@kali.org Usertags: origin-kali I made the same observation today. It seems to me that the breaks was a bit too large. You can likely keep the same effect by using a versioned breaks that would not conflict with the provides of python-is-python2. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 dh-python depends on: ii python33.8.6-1 ii python3-distutils 3.8.6-1 dh-python recommends no packages. Versions of packages dh-python suggests: ii dpkg-dev 1.20.5 ii libdpkg-perl 1.20.5 -- no debconf information
Bug#973861: apt: http acquire method still failing with "Undetermined error" or "Data left in the buffer"
Package: apt Version: 2.1.11 Severity: important User: de...@kali.org Usertags: origin-kali Hello, while the frequence of the error has really decreased since the last set of fixes, we still have occasional failures where apt ends up with "Undetermined error" or "Data left in the buffer". It's pretty annoying for APT to be unreliable in that way. The last case that triggered this bug for us in Kali was within a net-install in d-i: [...] Nov 5 23:15:48 in-target: Err:2130 http://kali.download/kali kali-rolling/main amd64 llvm-10 amd64 1:10.0.1-6 Nov 5 23:15:48 in-target: Undetermined Error [IP: 104.18.102.100 80] [...] Nov 5 23:16:14 in-target: Fetched 2,651 MB in 5min 20s (8,274 kB/s) Nov 5 23:16:14 in-target: E: Failed to fetch http://kali.download/kali/pool/main/l/llvm-toolchain-10/llvm-10_10.0.1-6_amd64.deb Undetermined Error [IP: 104.18.102.100 80] Nov 5 23:16:14 in-target: E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Nov 5 23:16:14 in-target: tasksel: apt-get failed (100) To try to reproduce it I invite you to configure a sources.lists with kali.download as mirror. Do this on a server with a very good connection. deb http://kali.download/kali kali-rolling main contrib non-free And try to run this in a loop until you reproduce it: # apt --download-only install kali-linux-large # apt clean It took me two tries to reproduce it... I had a download rate of more than 50MB/s. I tried to reproduce it with debugging options enabled: # while true; do apt -y --download-only install kali-linux-large -o Debug::Acquire::http=true -o Debug::pkgAcquire::Worker=true 2>log || break; apt clean; done And I managed to reproduce it too but after a dozen of tries this time. The log file is huge but it failed with this: E: Failed to fetch http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb Undetermined Error [IP: 104.18.102.100 80] And here are the lines that seem relevant for that specific file: -> http:600%20URI%20Acquire%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb%0aFilename:%20/var/cache/apt/archives/partial/libjs-highlight.js_9.12.0+dfsg1-5_all.deb%0aExpected-SHA256:%202347b5fd2bb741cf87f01b4243e591d094445227bea63de5d53555752b322a45%0aExpected-SHA1:%20c465af27c6a567320661436f509043587735f996%0aExpected-MD5Sum:%206d11858477ba16d6b2ffb2d518dd2735%0aExpected-Checksum-FileSize:%20300172%0aTarget-Repo-URI:%20http://kali.download/kali/%0aTarget-Site:%20http://kali.download/kali%0aTarget-Release:%20kali-rolling%0aTarget-Base-URI:%20http://kali.download/kali/%0aTarget-Component:%20main%0aTarget-Codename:%20kali-rolling%0aTarget-Suite:%20kali-rolling%0aTarget-Architecture:%20all%0aTarget-Type:%20deb%0a%0a <- http:102%20Status%0aURI:%20http://kali.download/kali/pool/main/x/xorg-sgml-doctools/xorg-sgml-doctools_1.11-1_all.deb%0aMessage:%20Waiting%20for%20headers GET /kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0%2bdfsg1-5_all.deb HTTP/1.1^M Host: kali.download^M User-Agent: Debian APT-HTTP/1.3 (2.1.11)^M ^M [...] <- http:102%20Status%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb%0aMessage:%20Waiting%20for%20headers GET /kali/pool/main/i/imagemagick/libmagickcore-6.q16-6-extra_6.9.11.24%2bdfsg-1%2bb1_amd64.deb HTTP/1.1^M Host: kali.download^M User-Agent: Debian APT-HTTP/1.3 (2.1.11)^M ^M Answer for: http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb HTTP/1.1 200 OK^M Date: Fri, 06 Nov 2020 08:10:09 GMT^M Content-Type: application/octet-stream^M Content-Length: 300172^M Connection: close^M Set-Cookie: __cfduid=dcd44a60d11f41fb354d70f7609be4f1a1604650209; expires=Sun, 06-Dec-20 08:10:09 GMT; path=/; domain=.kali.download; HttpOnly; SameSite=Lax^M Last-Modified: Sun, 29 Dec 2019 15:40:32 GMT^M ETag: "5e08c8f0-4948c"^M Expires: Mon, 04 Nov 2030 08:10:09 GMT^M Cache-Control: public, max-age=31536^M CF-Cache-Status: HIT^M Age: 264899^M Accept-Ranges: bytes^M cf-request-id: 063e342a5da30f222e81^M Server: cloudflare^M CF-RAY: 5edd5623cfbda30f-ORD^M ^M <- http:200%20URI%20Start%0aLast-Modified:%20Sun,%2029%20Dec%202019%2015:40:32%20+%0aSize:%20300172%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb <- http:400%20URI%20Failure%0aTransient-Failure:%20true%0aMessage:%20Undetermined%20Error%20[IP:%20104.18.102.100%2080]%0aURI:%20http://kali.download/kali/pool/main/h/highlight.js/libjs-highlight.js_9.12.0+dfsg1-5_all.deb ->
Bug#971744: libvorbisidec: multiple architectures not coinstallable
Package: libvorbisidec
Version: 1.2.1+git20180316-6
Tags: patch
Dear developers,
Multiple architectures of library libvorbisidec1 are not coinstallable.
I tried to rebuild the package with just adding "Multi-Arch: same" in
debian/control and the resulting amd64 and i386 packages could be
installed together without any problem.
Please consider releasing a new multi-arch friendly version of the
package. I attached a small patch to this bug report.
Regards,
--
Raphaël Halimi
From 9454bc7cca407213672dee2c42dc98171cc38faf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Halimi?=
Date: Tue, 6 Oct 2020 13:13:09 +0200
Subject: [PATCH] Add Multi-Arch: same
---
debian/control | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/control b/debian/control
index c63ebcb..0db469c 100644
--- a/debian/control
+++ b/debian/control
@@ -27,6 +27,7 @@ Description: Integer-only Ogg Vorbis decoder, AKA "tremor" (Development Files)
Package: libvorbisidec1
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Multi-Arch: same
Description: Integer-only Ogg Vorbis decoder, AKA "tremor"
libvorbisidec is an Ogg Vorbis audio decoder (also known as
"tremor"), implemented with no floating point arithmetic. This makes
--
2.28.0
OpenPGP_0x4D99F6660A59827B.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Bug#970694: numba: FTBFS: unsat-dependency: python3-llvmlite:amd64 (< 0.34)
Note that this problem does hit the python3-numba package (and not only the src:numba) as it requires python3-llvmlite (<< 0.34). An `apt upgrade` doesn't touch the python3-llvmlite on my machines, and an `apt full-upgrade` would update python3-llvmlite and remove python3-numba. I thus assume than python3-numba is now uninstallable on sid. Shouldn't this bug be opened also for python3-numba, as this package is likely to appear as uninstallable in the present state? Raphaël > Source: numba > Version: 0.50.1-2 > Severity: serious > Tags: ftbfs sid bullseye > Justification: fails to build from source (but built successfully in the past) > > numba has unsatisfiable build dependencies: > | report: > | - > | package: sbuild-build-depends-main-dummy > | version: 0.invalid.0 > | architecture: amd64 > | status: broken > | reasons: > | - > | missing: > | pkg: > | package: sbuild-build-depends-main-dummy > | version: 0.invalid.0 > | architecture: amd64 > | unsat-dependency: python3-llvmlite:amd64 (< 0.34) > > python3-llvmlite is now at version 0.34.0-1. > > Cheers > -- > Sebastian Ramacher
Bug#970749: nautilus-dropbox: New upstream release available
Package: nautilus-dropbox Version: 2019.02.14-1 Severity: wishlist Version 2020.03.04 is available in the upstream git repository: https://github.com/dropbox/nautilus-dropbox/tags It would be nice to have this version packaged. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 nautilus-dropbox depends on: ii gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-5 ii gir1.2-gtk-3.0 3.24.22-1 ii libc62.31-3 ii libglib2.0-0 2.64.4-1 ii libgtk-3-0 3.24.22-1 ii libnautilus-extension1a 3.36.3-1 ii procps 2:3.3.16-5 ii python3 3.8.2-3 ii python3-gi 3.36.1-1 Versions of packages nautilus-dropbox recommends: ii python3-gpg 1.14.0-1 Versions of packages nautilus-dropbox suggests: ii nautilus 3.36.3-1 -- no debconf information
Bug#970692: dovecot-core: fts_solr plugin failure
On Mon, 21 Sep 2020 10:43:43 -0700, Noah Meyerhans wrote: > Thanks for this report. If we're able to provide builds with this patch > backported, will you be able to validate that the issue is resolved? If > so, we should be able to get this fixed in an upcoming buster point > release. Yes, this is a bug I can reproduce.
Bug#970692: dovecot-core: fts_solr plugin failure
Package: dovecot-core Version: 2.3.4.1-5+deb10u4 Severity: important Tags: upstream Dear Maintainer, The search via the solr_plugin fails frequently on rather big accounts with that error: Error: fts_solr: received invalid uid '0' The search via imap timeout after 10 seconds. "Based on the XML response above, I investigated this problem thoroughly and determined that this is a pretty severe bug in the Solr XML response parsing code. This occurs only when the response is rather large and the boundary between two read chunks falls in the middle of a numeric value (that happens to end in '0')." https://dovecot.org/pipermail/dovecot/2019-October/117290.html This is fixed in 2.3.11.3+dfsg1-2 There is this patch that was released in 2.3.10. https://github.com/dovecot/core/commit/74c98d2a18cc9ec0edae7f887605a0959d05c8c5#diff-05c64532f105f533f1b96575f101cb81 -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dovecot-core depends on: ii adduser 3.118 ii libapparmor1 2.13.2-10 ii libbz2-1.0 1.0.6-9.2~deb10u1 ii libc62.28-10 ii libexttextcat-2.0-0 3.4.5-1 ii libicu63 63.1-6+deb10u1 ii liblua5.3-0 5.3.3-1.1 ii liblz4-1 1.8.3-1 ii liblzma5 5.2.4-1 ii libpam-runtime 1.3.1-5 ii libpam0g 1.3.1-5 ii libsodium23 1.0.17-1 ii libssl1.11.1.1d-0+deb10u3 ii libstemmer0d 0+svn585-1+b2 ii libwrap0 7.6.q-28 ii lsb-base 10.2019051400 ii openssl 1.1.1d-0+deb10u3 ii ssl-cert 1.0.39 ii ucf 3.0038+nmu1 ii zlib1g 1:1.2.11.dfsg-1
Bug#969813: make attempts to execute a directory found on PATH (fixed upstream)
Package: make Version: 4.3-4 Severity: normal Tags: upstream patch Dear Maintainer, the current version of make in Debian is affected by the following bug: https://savannah.gnu.org/bugs/index.php?57962 in which the PATH resolution does not check if the file to execute is actually a directory. This bug has been fixed in upstream's gnulib: http://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/findprog-in.c?id=6e6abd0cdfe4bb96f6412aebc511f10bf254a820 which unfortunately did not make it into Debian's make package. Could you please update make with this fix ? Regards, Raphaël
Bug#969458: perl crash in eval command trying a failing require statement
Package: perl
Version: 5.30.3-4
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: debian-d...@lists.debian.org
Control: found -1 5.32.0-2
In Kali, any source package build started to fail with a mysterious
error:
> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 127
After quite some investigation, I tracked this down to perl exiting with
that error code in the middle of an eval statement that should have failed:
https://sources.debian.org/src/dpkg/1.20.5/scripts/Dpkg/Vendor.pm/#L166
The $name tried is "Kali" and we don't ship any Dpkg::Vendor::Kali. The
code should fallback to Dpkg::Vendor::Debian and this works a few times
but after multiples calls, at some point it no longer works and the
require statement in the eval block just never returns, it seems to crash
the perl interpreter.
You can easily reproduce this on an up-to-date testing or unstable system
with dpkg 1.20.5 (that version is failing, the former version we had
in Kali was 1.19.7 and it was not triggering this issue):
$ sudo tee /etc/dpkg/origins/kali >/dev/null < Vendor: Kali
> Vendor-URL: https://www.kali.org/
> Parent: debian
> Bugs: https://bugs.kali.org/
> END
$ sudo ln -sf kali /etc/dpkg/origins/default
$ apt source hello
[...]
$ cd hello-*
$ dpkg-buildpackage -S
[...]
dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building hello using existing ./hello_2.10.orig.tar.gz
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 127
Note that I only reproduce this with "3.0 (quilt)" source packages. Native
packages have different code paths likely involving fewer calls to
run_vendor_hook() and the problem can't be reproduced with such a source
package.
I can also reproduce the bug with version 5.32.0-2 available in
experimental.
FWIW I'm working around this issue in Kali with the attached patch but
this really smells like a bug in perl, thus I'm reporting it here.
Guillem, I believe the attached patch should be applied to dpkg in any
case as it's a small optimization that avoids running the evaled code too
often.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 perl depends on:
ii dpkg 1.20.5
ii libperl5.305.30.3-4
ii perl-base 5.30.3-4
ii perl-modules-5.30 5.30.3-4
Versions of packages perl recommends:
ii netbase 6.1
Versions of packages perl suggests:
pn libtap-harness-archive-perl
ii libterm-readline-gnu-perl1.36-2+b1
ii make 4.3-4
ii perl-doc 5.30.3-4
-- no debconf information
>From 75631da697b9d2c5b3ff2c54bc225fc55d3ab9c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?=
Date: Thu, 3 Sep 2020 11:26:58 +0200
Subject: [PATCH] Work-around a perl crash during any package build
Somehow perl doesn't like the multiple execution of the eval code that tries
to "require Dpkg::Vendor::Kali;" and at some point perl just exits with
an error code of 127 when it tries to execute this line of code. When
it happens, the eval doesn't return.
To avoid the multiple execution of this code, we cache the result of the
lookup made on the parent vendor as the good result for the current
vendor as well.
There's likely some bug in perl here and somehow the update from
dpkg 1.19.7 to dpkg 1.20.5 started to trigger that bug.
---
scripts/Dpkg/Vendor.pm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/Dpkg/Vendor.pm b/scripts/Dpkg/Vendor.pm
index 196159156..5b8f66fd8 100644
--- a/scripts/Dpkg/Vendor.pm
+++ b/scripts/Dpkg/Vendor.pm
@@ -174,10 +174,12 @@ sub get_vendor_object {
my $info = get_vendor_info($vendor);
if (defined $info and defined $info->{'Parent'}) {
-return get_vendor_object($info->{'Parent'});
+$obj = get_vendor_object($info->{'Parent'});
} else {
-return get_vendor_object('Default');
+$obj = get_vendor_object('Default');
}
+$OBJECT_CACHE{$vendor} = $obj;
+return $obj;
}
=item run_vendor_hook($hookid, @params)
--
2.28.0
Bug#969173: RM: openvas openvas-libraries openvas-cli openvas-manager -- ROM; replaced by gvm
Package: ftp.debian.org Severity: normal User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: debian-security-to...@lists.debian.org Hello, GVM is replacing OpenVAS and a bunch of source packages have been renamed or are obsolete. Please remove the following source packages from unstable: * openvas(replaced by gvm) * openvas-libraries (replaced by gvm-libs) * openvas-cli(obsolete) * openvas-manager(replaced by gvmd) Thank you!
Bug#930919: dovecot: dsync broken for sieve filters
On Wed, 26 Aug 2020 11:25:50 -0700, Noah Meyerhans wrote: … > I suspect we'll also want the next commit on that file, > https://github.com/dovecot/pigeonhole/commit/382b1eacdf587cd7d20a260e19a29a4d958bf98e Indeed, I also think these two commits should be included: commit 382b1eacdf587cd7d20a260e19a29a4d958bf98e Author: Timo Sirainen Date: Wed Jul 17 12:33:09 2019 +0300 doveadm-sieve: Shared attribute iteration shouldn't list Sieve scripts Trying to get them as shared instead of as private resulted in failure. commit 0e91911d22d43621c820d7f5b28be671050fd290 Author: Aki Tuomi Date: Mon May 27 09:43:25 2019 +0300 doveadm-sieve: Fix script synchronization When dsyncing, this codepath is always called with prefix "". There is no point checking the prefix at all. Broken in 479c5e57046dec76078597df844daccbfc0eb75f I rebuilded the packages on my side. That would be nice to see this bug fixed in buster release. -- infomaniak Raphaël Walther | Administrateur système Rue Eugène-Marziano 25, 1227 Genève Swiss Made| ISO 27001 14001 50001 signature.asc Description: PGP signature
