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#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#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#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#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#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#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#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#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#959176: gammu-smsd: cannot start (wrong path in systemd service file)
Package: gammu-smsd
Version: 1.41.0-1
Severity: grave
Tags: patch
Dear maintainer,
The current version (1.41.0-1) of gammu-smsd cannot start the service
because the systemd service file installed in the package uses cmake
substitutions, so instead of "/usr/bin", the service file has
"${CMAKE_INSTALL_FULL_BINDIR}".
This variable is supposed to be substituted during package build, but
currently it's not, because the configure script does not find systemd
and thus, does not install the modified file; also, dh-install is
instructed to take the unmodified file from sources.
The correct way to fix this is to make systemd detectable by the
configure script, and use the modified file installed by the build
system instead of the unmodified file from sources.
Here is a patch that does this: it adds systemd to the build
dependencies so that the configure script can detect it, and instructs
dh-install to use the file installed by the build system instead of the
one from sources.
Regards,
--
Raphaël Halimi
From 7073610f61db4309df5102536320a52a72f2c948 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Halimi?=
Date: Thu, 30 Apr 2020 11:20:21 +0200
Subject: [PATCH] Fix systemd service file
---
debian/control| 3 ++-
debian/gammu-smsd.install | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/debian/control b/debian/control
index 24a16f8..ac2fab8 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,8 @@ Build-Depends: debhelper (>= 9.20160709),
libdbi-dev,
libbluetooth-dev [linux-any],
libgudev-1.0-dev [linux-any],
- libglib2.0-dev
+ libglib2.0-dev,
+ systemd
Standards-Version: 4.5.0
Vcs-Browser: https://salsa.debian.org/debian/gammu
Vcs-Git: https://salsa.debian.org/debian/gammu.git
diff --git a/debian/gammu-smsd.install b/debian/gammu-smsd.install
index 4abdaeb..1dd92a7 100644
--- a/debian/gammu-smsd.install
+++ b/debian/gammu-smsd.install
@@ -5,4 +5,4 @@ usr/share/man/man1/gammu-smsd*
usr/share/man/man7/gammu-smsd*
usr/share/man/man5/gammu-smsd*
debian/gammu-smsdrc /etc/
-contrib/init/gammu-smsd.service lib/systemd/system/
+lib/systemd/system/gammu-smsd.service
--
2.26.2
signature.asc
Description: OpenPGP digital signature
Bug#951364: tlp: Typo in package description
Le 15/02/2020 à 11:53, Beatrice Torracca a écrit : > with a recent upgrade (I think in 1.3.1-1) a typo has sneaked in into > the package description. > > In particular Bluetooth has been changed in "luetooth". Thanks for the report, I'll prepare a new upload. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#951013: tlp: description of configuration order misleading or order wrong
Le 09/02/2020 à 20:42, Norbert Preining a écrit : > If this is true, local configurations as suggested in /etc/tlp.d/*.conf > will **NOT** override the Debian /etc/tlp.conf. > > Is this intended? Yes, it is. I had this discussion with upstream during the beta phase and he was adamant on the fact that /etc/tlp.conf must have priority over everything else. The default /etc/tlp.conf has every setting commented, hence the advice to make changes to the configuration only through /etc/tlp.d/*.conf. Since English is not my native language, I may have missed something here. Is your bug report filed against the respective priorities of the different configuration files, or against the NEWS entry itself that you find somewhat not clear ? Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#950702: tlp: New upstream version 1.3 is available
Control: tags -1 +pending Control: thanks Le 05/02/2020 à 04:34, Yuan-Chen Cheng a écrit : > It provide new feature like: /etc/tlp.d/*.conf, which will be very > helpful for extra config file maintaining. > > Please kindly consider upgrading the new verison. Hi, 1.3.0 is already in the Git repository (for unstable, buster-backports and stretch-backports-sloppy), but I intentionally didn't upload it to Debian yet, because upstream advised me to wait a bit for 1.3.1, which will be released very soon. As I understood it, the bug fixed in 1.3.1 is important enough for upstream not wanting 1.3.0 to go to the next Ubuntu LTS release without this fix. See https://github.com/linrunner/TLP/issues/460 for more information. If you can't wait, checkout the Git repository and build the package yourself. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#943434: Please add /etc/alternatives in the list of directories bind-mounted by bubblewrap
Package: libgnome-desktop-3-18 Version: 3.34.1-1 Severity: minor Affects: ffmpegthumbnailer libblas3 (As advised in #902288, I'm reporting the bug against libgnome-desktop instead of ffmpegthumbnailer or libblas, adding them as affected by the bug) Hi, I use ffmpegthumbnailer instead of totem-thumbnailer to generate thumbnails in Nautilus. For maybe a week or so (but since I rarely reboot my Sid machine or logout from this session, the upgrade which triggered this bug may be older than that), I noticed that the thumbnails were not generated anymore. By manually running a command similar to the one used by nautilus to run the thumbnailer in bubblewrap, I have this error message: ffmpegthumbnailer: error while loading shared libraries: libblas.so.3: cannot open shared object file: No such file or directory It turns our that /usr/lib/x86_64-linux-gnu/libblas.so.3 is a symlink pointing to /etc/alternatives/libblas.so.3-x86_64-linux-gnu, itself pointing to /usr/lib/x86_64-linux-gnu/blas/libblas.so.3. So the library is actually in the container, but the binary can't find it because of the symlink in /etc/alternatives, which isn't bind-mounted. By adding "--ro-bind /etc/alternatives /etc/alternatives" to the bwrap command line, ffmpegthumbnailer didn't complain anymore and the thumbnail was generated as expected. I think it would be nice to patch the Debian package of libgnome-desktop to also bind /etc/alternatives when running a command in bubblewrap, as ffmpegthumbnailer may not be the only binary run by Nautilus through bubblewrap that may need stuff in /etc/alternatives (now or in the future). Since /etc/alternatives is Debian-specific, I think it shouldn't be necessary to report this bug to upstream. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#942378: zoneminder: should depend on libnumber-bytes-human-perl
Le 16/10/2019 à 08:38, Dmitry Smirnov a écrit : > On Wednesday, 16 October 2019 5:21:22 PM AEDT Raphaël Halimi wrote: >> Just to know, is there a plan to backport this fix through stable updates ? > > Not at this time, unfortunately. To backport Zoneminder it must migrate to > "testing" first but it is blocked by #922724: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922724 I didn't mean to backport a new version, but just a new Debian revision with updated dependencies. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#942378: zoneminder: should depend on libnumber-bytes-human-perl
Hi again, Thank you for your quick reply. Le 16/10/2019 à 01:20, Dmitry Smirnov a écrit : > Thanks. This is already done in the git repository [1] and will be fixed in > the next upload. > > [1]: https://salsa.debian.org/debian/zoneminder/commit/42c42d27 Ah, sorry, I didn't think to look at the Salsa repo, I just quickly parsed the BTS before reporting. Just to know, is there a plan to backport this fix through stable updates ? Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#942378: zoneminder: should depend on libnumber-bytes-human-perl
Package: zoneminder Version: 1.32.3-2 Hi, One of ZoneMinder's modules, zmfilter.pl, which is used to process filters, including basic ones like email/SMS sending, needs the Perl module Number::Bytes::Human. Hence, zoneminder should depends or at least recommend libnumber-bytes-human-perl to allow such basic functions to work as expected. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#935918: cups: can't read hpcups PPDs
After upgrading hplip to 3.19.8+dfsg0-7 and re-adding the printer, I can confirm that the problem is fixed, at least for my printer. Thanks to all for the good work ! Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#935918: cups: can't read hpcups PPDs
Le 30/09/2019 à 20:27, Didier 'OdyX' Raboud a écrit : > FTR, this was circumvented in Debian's hplip package version 3.19.8+dfsg0-6. That's what hplip's changelog says, but unfortunately, after upgrading, I tried to re-add my printer (HP Envy 5030) and again, the PPD was rejected with an error, but it worked once I modified it manually. Maybe not all PPDs were correctly fixed ? Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#935918: cups: can't read hpcups PPDs
Package: cups Version: 2.2.12-1 Hi, Today I was unable to print on a HP Envy 5030 connected with USB that used to work perfectly. The error message in CUPS web interface was "filter failed" or something (from memory). Not able to find the problem, I tried to reinstall the printer; curiously, it worked with hpijs but not with hpcups. The error message was "Unable to copy PPD file" (again from memory). Using the hpijs driver was not satisfying because the printing is not centered (in CUPS test page, the upper and right-most frame borders are missing, even after setting paper size to A4 from the default Letter), and it can't be corrected because the options are very limited, so I was determined to find why adding the printer with the hpcups driver was not working. Adding it through HP ToolBox (from hplip) failed too, with an error message I don't remember. Adding it manually with lpadmin failed too, but with a much more explicit message: raph@arche:~$ LANG=C sudo lpadmin -p HP_ENVY_5030 -v "usb://HP/ENVY%205000%20series?serial=redacted=1" -m "drv:///hpcups.drv/hp-envy_5000_series.ppd" -D "HP Envy 5030" lpadmin: Unable to open PPD "/tmp/0587f5d6ca5c8": Illegal option keyword string on line 198. Line 198 reads: *PageSize Custom/Custom: "<>setpagedevice" Googling some more, I found a very recent thread on the ArchLinux forum which described exactly the same problem: https://bbs.archlinux.org/viewtopic.php?id=248631 Unlike this Arch user, I didn't want to fiddle with the PPD (more precisely, it may seem silly, but I stalled because I wasn't sure about what I could replace the word "Custom" with...) So instead I downgraded all cups packages from 2.2.12-1 to 2.2.10-6 and that solved the problem completely (long live snapshot.debian.org), I could add the printer with the hpcups driver and print documents as expected. Aside from that, other reasons that make me think that the problem comes from the cups upgrade and not from printer-driver-hpcups are: - the generated PPDs are identical (on failure, lpadmin left it in /tmp; I compared it to the one in /etc/cups/ppd generated after the downgrade) - cups was upgraded very recently (08/18 according to apt log) whereas printer-driver-hpcups was not upgraded since I installed my Sid box (06/06) and I clearly remember printing without problems between those dates I was tempted to file this bug with a high severity since it prevents installing a printer or simply printing, but since it also seems limited to hpcups, I'll let you decide on this. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#934040: tasksel: doesn't provide transitional package for task-print-server
Package: tasksel Version: 3.54 Hi, Following #696658, task-print-server was renamed to task-print-service. Running "apt-get dist-upgrade" on current Sid tries to remove task-print-server, without installing task-print-service to replace it. This could be a problem for inexperienced users in the future when Bullseye will be released and they upgrade from Buster. I guess the best solution is to provide an updated version of tasksel which provides a transitional dummy package named task-print-server depending on task-print-service. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#851774: Bug#928931: more info
Le 02/07/2019 à 00:06, Cyril Brulebois a écrit : >> (There was also a merge request based on this patch [2] which didn't >> receive any answer) > > Merge request, MR. > > So you're pointing out exactly what I was referring to. Hum. I'm disappointed in myself. >> Please enlighten me (I'm not being ironic here, this is a legitimate >> question, I really don't understand how releasing Buster with a partly >> broken apt-setup is preferable to merging a patch which is admittedly >> not tested by a lot of people, but is so simple that it's very >> unlikely to fail, especially when 60local nearly **always** fail >> without a fix). > > Because it makes no sense to be making changes until the very last > minute. Especially for a highly specific use case where one would expect > advanced users to be able to find the relevant bug report(s). Well, I wasn't able to, when I first submitted the duplicate bug report (#929911). Keep in mind that the error in the installer syslog is very cryptic: "apt-setup: warning: /usr/lib/apt-setup/generators/60local returned error code 255; discarding output" It's really not obvious that it's caused by the absence of gnupg, I didn't get it until you closed the duplicate and pointed me to #928931. Note that, before filling the bug report, I briefly searched through the current d-i bugs; I don't remember the patterns I used, but I didn't find this one (although I admit I find it weird that I didn't search for "local" or "apt-setup"; that being said, looking at the time of my e-mail, I was probably a bit tired after a long night of work). > If you personally don't mind, you may want to just trust us to make the > right call. Hypothetical users that haven't been testing release > candidates and haven't noticed the issue can surely 1) find bug reports > when they run into this issue; 2) apply a workaround; 3) or wait until > 10.1 is released. Right. My apologies. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#851774: Bug#928931: more info
Le 01/07/2019 à 22:46, Moritz Mühlenhoff a écrit : > This is already broken in Stretch, so you're overly dramatic... Wrong :) I may be overly dramatic, but Stretch didn't have this problem. The reason is simple: gnupg was "Priority: important" on Stretch, so it was installed with the base system, alongside apt (during the initial debootstrap), so apt-key didn't fail to add a key to its trusted keyring. With Buster, gunpg was demoted to "Priority: optional", **and** demoted to a Suggests in apt dependencies (whereas it used to be a Recommends), so, unless gnupg is installed manually before the apt-setup phase, apt-key can't add a key to its trusted keyring. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#851774: Bug#928931: more info
Hi Cyril, Le 29/06/2019 à 16:20, Cyril Brulebois a écrit : >> If installing gnupg is what it takes to fix the bug, IMHO it should be >> done; anyway, with this patch, it would be installed only if a local >> repository with a GnuPG key is used at all. > > Well, I proposed doing so a while ago but that didn't happen. Looking at > the current gnupg package, it's not about installing just a single, > extra package: > > Depends: dirmngr (<< 2.2.13-2.1~), dirmngr (>= 2.2.13-2), gnupg-l10n (= > 2.2.13-2), gnupg-utils (<< 2.2.13-2.1~), gnupg-utils (>= 2.2.13-2), gpg (<< > 2.2.13-2.1~), gpg (>= 2.2.13-2), gpg-agent (<< 2.2.13-2.1~), gpg-agent (>= > 2.2.13-2), gpg-wks-client (<< 2.2.13-2.1~), gpg-wks-client (>= 2.2.13-2), > gpg-wks-server (<< 2.2.13-2.1~), gpg-wks-server (>= 2.2.13-2), gpgsm (<< > 2.2.13-2.1~), gpgsm (>= 2.2.13-2), gpgv (<< 2.2.13-2.1~), gpgv (>= 2.2.13-2) I agree with you on the fact that the dependencies are quite heavy. I noticed that, but I didn't realize that the GnuPG keys could just be dropped in /etc/apt/trusted.gpg.d/ (more on that later). Good point. > I'm also not sure what part of dirmngr and/or gpg-agent are going to > stay around running, after calling “apt-key add” with gnupg installed. I didn't even know that could be a problem. Again, good point. > Testing that was conceivable a couple of weeks/months back; a few days > before an archive freeze, not so much. Well, the patch in [1] (which is far better than mine, by the way) dates from April 9th, 2018, so it was not for a lack of trying... :) > Plus, we've got a MR against apt-setup now, see #851774. It's also come > late and nobody reviewed it yet. Plus, the other, serious bug report was > marked as buster-ignore by a release team member, so there's no *need* > to fix this before buster. What exactly does "MR" mean ? I googled but I didn't find anything. > All in all, it looks like we're instead going to consider the MR at the > beginning of the bullseye release cycle, and backport the fix to buster > if it proves to be working fine. That's where I disagree. More precisely, I don't understand how the current situation (which is that generators/60local crashes systematically, unless in the very rare case that an unsigned repository is configured, **and** debian-installer/allow_unauthenticated is set) can be preferable to merging the patch in [1] before release. (There was also a merge request based on this patch [2] which didn't receive any answer) Please enlighten me (I'm not being ironic here, this is a legitimate question, I really don't understand how releasing Buster with a partly broken apt-setup is preferable to merging a patch which is admittedly not tested by a lot of people, but is so simple that it's very unlikely to fail, especially when 60local nearly **always** fail without a fix). Personally, I don't mind, since my PXE server has a complex preseed system with preseed file snippets, scripts and hooks everywhere, so adding a hook to replace 60local for Buster was very easy; but I'm thinking of people who use a single preseed file, they will have a really bad surprise when Buster is released. If you don't change your mind, please at least agree that this bug (and its possible workarounds) must absolutely be documented with big fat warnings in the preseed documentation [3]. I have to say that I **really** miss the times when a new Debian release was ready "when it's ready"... :( [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851774#61 [2] https://salsa.debian.org/installer-team/apt-setup/merge_requests/1 [3] https://www.debian.org/releases/stable/amd64/apb.html.en Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#928931: Bug #928931: more info + patch
Control: tags -1 +patch Hi, I don't mean to rush you, but I noticed that this bug is still not fixed in d-i RC2. My current workaround is to add a hook in base-installer.d (because it has to be done just before apt gets configured) to replace /usr/lib/apt-setup/generators/60local with a version including a line to install gnupg before "apt-key add" is called (patch included). (the modification can also be done manually during the base system installation phase, but it is error-prone, has to be done very quickly at the right moment, and of course completely defeats the purpose of an unattended installation) I noticed that gnupg used to be Priority: important, whereas it's now Priority: optional. If installing gnupg is what it takes to fix the bug, IMHO it should be done; anyway, with this patch, it would be installed only if a local repository with a GnuPG key is used at all. I hope this fix (or another one of your own choice) will make it to d-i before release. Regards, -- Raphaël Halimi --- 60local.orig 2018-08-10 21:20:36.0 +0200 +++ 60local 2019-06-29 10:36:46.0 +0200 @@ -35,6 +35,7 @@ while :; do if fetch-url "$key" "$ROOT/tmp/key$i.pub"; then # add it to the keyring +$chroot $ROOT apt-get --yes --no-install-recommends install gnupg $chroot $ROOT apt-key add "/tmp/key$i.pub" rm -f "$ROOT/tmp/key$i.pub" break signature.asc Description: OpenPGP digital signature
Bug#930613: steam: depends on dummy package libgl1-mesa-glx
Package: steam Version: 1.0.0.59-4 Tags: patch libgl1-mesa-glx is a dummy package which itself depends on libgl1 and libglx-mesa0. After checking every binary file in ~/.steam, it seems that none of them depends on the libraries provided by libglx-mesa0 (libGLX_mesa.so.0, libGLX_indirect.so.0), but some of them depend on libGL.so.1, provided by libgl1. Hence, it's probably safe to replace the dependency on libgl1-mesa-glx with libgl1. Here is a (very small) patch to fix that. It would be very nice if this fix made it to Buster. Regards, -- Raphaël Halimi Index: steam-1.0.0.59/debian/control === --- steam-1.0.0.59.orig/debian/control +++ steam-1.0.0.59/debian/control @@ -25,7 +25,7 @@ Pre-Depends: Depends: libgl1-mesa-dri, libgl1-mesa-dri (>= 17.3) | libtxc-dxtn0, - libgl1-mesa-glx, + libgl1, libgpg-error0 (>= 1.10), libudev1, libxcb-dri3-0 (>= 1.11.1), signature.asc Description: OpenPGP digital signature
Bug#930611: openjdk-11-jre: depends on dummy package libgl1-mesa-glx
Package: openjdk-11-jre Version: 11.0.4+4+really11.0.3+7-2 Tags: patch libgl1-mesa-glx is a dummy package which itself depends on libgl1, therefore a dependency on libgl1-mesa-glx | libgl1 makes no sense. Here is a (very small) patch to fix that. It would be very nice if this fix made it to Buster. Regards, -- Raphaël Halimi Index: openjdk-11-11.0.4+4+really11.0.3+7/debian/rules === --- openjdk-11-11.0.4+4+really11.0.3+7.orig/debian/rules +++ openjdk-11-11.0.4+4+really11.0.3+7/debian/rules @@ -602,7 +602,7 @@ ifneq ($(with_nss),no) endif dlopen_hl_recommends = dlopen_jre_depends = \ - libglib2.0-0 (>= 2.24), libgtk2.0-0 | libgtk-3-0, libxrandr2, libxinerama1, libgl1-mesa-glx | libgl1 + libglib2.0-0 (>= 2.24), libgtk2.0-0 | libgtk-3-0, libxrandr2, libxinerama1, libgl1 dlopen_jre_recommends = # .desktop files need to be multiarch installable signature.asc Description: OpenPGP digital signature
Bug#930609: xorg: depends on dummy package libgl1-mesa-glx
Package: xorg
Version: 1:7.7+19
Tags: patch
libgl1-mesa-glx is a dummy package which itself depends on libgl1,
therefore a dependency on libgl1-mesa-glx | libgl1 makes no sense.
Here is a (very small) patch to fix that.
It would be very nice if this fix made it to Buster.
Regards,
--
Raphaël Halimi
Index: xorg-7.7+19/debian/control
===
--- xorg-7.7+19.orig/debian/control
+++ xorg-7.7+19/debian/control
@@ -88,7 +88,7 @@ Package: xorg
Architecture: any
Depends:
xserver-xorg (>= ${binary:Version}),
- libgl1-mesa-glx | libgl1,
+ libgl1,
libgl1-mesa-dri,
libglu1-mesa,
xfonts-base (>= 1:1.0.0-1),
signature.asc
Description: OpenPGP digital signature
Bug#930608: xserver-xorg-core: depends on dummy package libegl1-mesa
Package: xserver-xorg-core
Version: 2:1.20.4-1
Tags: patch
libegl1-mesa is a dummy package which itself depends only on libegl1,
therefore a dependency on libegl1-mesa | libegl1 makes no sense.
Here is a (very small) patch to fix that.
It would be very nice if this fix made it to Buster, since this bug is
present in it, but also in stretch-backports.
Please also look at #785574, which was valid for Stretch, but not
anymore for Buster, so you may want to close it as well.
Regards,
--
Raphaël Halimi
Description: Fix xserver-xorg-core dependency on dummy package libegl1-mesa
Package xserver-xorg-core depends on libegl1-mesa | libegl1. libegl1-mesa is a
dummy package which itself depends on libegl1. This patch removes the dummy
package from the alternative dependency.
Author: Raphaël Halimi
Last-Update: 2019-06-16
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: xorg-server-1.20.4/debian/control
===
--- xorg-server-1.20.4.orig/debian/control
+++ xorg-server-1.20.4/debian/control
@@ -90,7 +90,7 @@ Depends:
udev (>= 149) [linux-any],
devd [kfreebsd-any],
# for glamor; not a shlibdep because we use epoxy
- libegl1-mesa [linux-any kfreebsd-any] | libegl1 [linux-any kfreebsd-any],
+ libegl1 [linux-any kfreebsd-any],
${shlibs:Depends},
${misc:Depends},
Recommends:
signature.asc
Description: OpenPGP digital signature
Bug#929910: installation-reports: d-i rc1 - wrong defaultroot
Package: installation-reports Severity: normal Dear Maintainer, * What led up to the situation? I have a TFTP server that holds several releases of Debian, and preseed files. It works well for current and past releases, but I noticed two problems with the current Buster installer (RC1). * What exactly did you do (or not do) that was effective (or ineffective)? Since that for testing and unstable, booting from TFTP always fail at some point of the installation (cannot find modules from the current kernel), I booted the ISO installer from an USB stick. * What was the outcome of this action? Adding "url=tftp://autoserver; on the "Automatic install" command line, the installer built a wrong value for auto-install/defaultroot (d-i/stretch/./preseed.cfg). It then downloaded the wrong preseed file, and in turn, had a wrong value for mirror/suite (stable). * What outcome did you expect instead? The installer should have built the right value for the default root (d-i/buster/./preseed.cfg). Feeding the whole URL to the file, including the default root (url=tftp://autoserver/d-i/buster/./preseed.cfg) was not sufficient to make it work. The value of mirror/suite was correct (testing), indicating that it downloaded the right preseed file, but the default root was still set to "d-i/stretch/./preseed.cfg". To get it working as expected, I had to specify both the url and the default root on the command line, like this: url=tftp://autoserver auto-install/defaultroot=d-i/buster/./preseed.cfg -- Package-specific info: Boot method: USB Stick Image version: https://cdimage.debian.org/cdimage/buster_di_rc1/multi-arch/iso-cd/debian-buster-DI-rc1-amd64-i386-netinst.iso Date: 2019-06-02 Machine: Libvirt/QEMU virtual machine Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Apart of this problem (and another described in a different bug report), the installation went well. Regards, -- Raphaël Halimi -- == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="10 (buster) - installer build 20190410" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux test 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:01.0 VGA compatible controller [0300]: Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 04) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:02.0 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.1 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.2 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.3 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.4 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.5 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.6 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9) LPC Interface Controller [8086:2918] (rev 02) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] [8086:2922] (rev 02) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 01:00.0 Ethernet controller [0200]: Red Hat, Inc Virtio network device [
Bug#929911: installation-reports: d-i rc1 - apt-setup: local repositories broken
Package: installation-reports Severity: normal Dear Maintainer, * What led up to the situation? I have a TFTP server that holds several releases of Debian, and preseed files. It works well for current and past releases, but I noticed two problems with the current Buster installer (RC1). * What exactly did you do (or not do) that was effective (or ineffective)? Since that for testing and unstable, booting from TFTP always fail at some point of the installation (cannot find modules from the current kernel), I booted the ISO installer from an USB stick. * What was the outcome of this action? The preseed files set up local repositories (apt-setup/local0/repository etc etc). With the current Buster installer (RC1), these local repositories are never set. The installer log says: apt-setup: warning: /usr/lib/apt-setup/generators/60local returned error code 255; discarding output Despite my best efforts, I couldn't debug it any further. I tried with several older Buster installer releases, and noticed that it worked until alpha2. It stopped working starting with alpha3. * What outcome did you expect instead? I expected the local repositories to be added to /etc/apt/sources.list. -- Package-specific info: Boot method: USB Stick Image version: https://cdimage.debian.org/cdimage/buster_di_rc1/multi-arch/iso-cd/debian-buster-DI-rc1-amd64-i386-netinst.iso Date: 2019-06-02 Machine: Libvirt/QEMU virtual machine Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Apart of this problem (and another described in a different bug report), the installation went well. Regards, -- Raphaël Halimi -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="10 (buster) - installer build 20190410" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux test 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:01.0 VGA compatible controller [0300]: Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 04) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:02.0 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.1 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.2 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.3 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.4 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.5 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.6 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9) LPC Interface Controller [8086:2918] (rev 02) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] [8086:2922] (rev 02) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 01:00.0 Ethernet controller [0200]: Red Hat, Inc Virtio network device [1af4:1041] (rev 01) lspci -knn: Subsystem: Red Hat, Inc Device [1
Bug#925873: tlp: Problem while booting on Battery power
Le 27/03/2019 à 21:36, Repu a écrit : >After install of Debian testing while booting on battery power system >just hangs with sometimes corrupted (xfce4) log-in screen or just a plain >black screen with corrupted mouse cursor. >No, i can't access the terminal/console with a Ctrl+Alt+F1. > >Proplem is probably connected with tlp, because removing it renders system >bootable on battery power. >(it could be connected with my laptop having Dual AMD Radeon HD GPUs in >crossfire) Hi, What is the exact model of your laptop ? It may be useful for upstream to understand what's going on and hopefully fix the bug. Could you please try to disable one GPU in the BIOS (as pointed out in the TLP FAQ Graphics section [1]) and see if this fixes the problem ? I don't know if a project equivalent to Bumblebee exists for AMD Dual graphics, but reading [2], [3] and [4] might help (don't forget to adapt names for AMD chips). [1] https://linrunner.de/en/tlp/docs/tlp-faq.html#graphics [2] https://wiki.archlinux.org/index.php/hybrid_graphics [3] https://wiki.archlinux.org/index.php/PRIME [4] https://wiki.debian.org/NvidiaGraphicsDrivers/Optimus Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#879084: 879084: more info, and three possible fixes
ackages to provide such a symlink. In any case, apart of a fix in unstable, a bugfix release for Stretch would be much appreciated, even if only two people complained about that bug in 7 years... :) Note that, for the sake of completeness, I also looked at the equivalent for shell plugins (utils.sh), but they don't seem to suffer from the same problem, since they source $PROGPATH/utils.sh, with $PROGPATH being extracted from $0. Hope it helps. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#839591: Update keytab-lilo to work on modern Debian systems
Hi,
Here is a refreshed patch (in Git format) to be applied on version 1:24.2-4.
Since it adds a quilt patch, the warnings about white space errors from
git am are normal.
Regards,
--
Raphaël Halimi
From 1854cbba093384d44bb670eb8237ece85f52d6e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Halimi?=
Date: Sun, 2 Oct 2016 16:14:04 +0200
Subject: [PATCH 1/2] Add patch to fix keytab-lilo.pl
---
debian/patches/10_fix-keytab-lilo.patch | 45 +
debian/patches/series | 1 +
2 files changed, 46 insertions(+)
create mode 100644 debian/patches/10_fix-keytab-lilo.patch
diff --git a/debian/patches/10_fix-keytab-lilo.patch b/debian/patches/10_fix-keytab-lilo.patch
new file mode 100644
index 000..343e7b5
--- /dev/null
+++ b/debian/patches/10_fix-keytab-lilo.patch
@@ -0,0 +1,45 @@
+Description: Various fixes for keytab-lilo
+ This patch updates keytab-lilo to work on modern Debian systems:
+ - Support for kbd 2.0.3 format (from Olivier Brunel, see
+ http://www.syslinux.org/archives/2015-December/024690.html)
+ - Use new keymaps ".kmap" extension (from syslinux upstream)
+ - Add headers (from syslinux upstream)
+Author: Raphaël Halimi
+Origin: other
+Last-Update: 2016-10-02
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/keytab-lilo.pl
b/keytab-lilo.pl
+@@ -1,4 +1,8 @@
+ #!/usr/bin/perl
++
++eval { use bytes; };
++eval { binmode STDOUT; };
++
+ $DEFAULT_MAP = "us";
+ $DEFAULT_EXT = ".kmap";
+
+@@ -6,8 +10,8 @@
+ {
+ print STDERR
+ "usage: $0 [ -p old_code=new_code ] ...\n".
+- (" "x(8+length $0))."[path]default_layout[.map] ] ".
+- "[path]kbd_layout[.map]\n";
++ (" "x(8+length $0))."[path]default_layout[.kmap] ] ".
++ "[path]kbd_layout[.kmap]\n";
+ exit 1;
+ }
+
+@@ -44,9 +48,9 @@
+ $empty = 1;
+ while () {
+ chop;
+- if (/^(static\s+)?u_short\s+(\S+)_map\[\S*\]\s+=\s+{\s*$/) {
++ if (/^(static\s+)?(u_|unsigned )short\s+(\S+)_map\[\S*\]\s+=\s+{\s*$/) {
+ die "active at beginning of map" if defined $current;
+- $current = $pfx.":".$2;
++ $current = $pfx.":".$3;
+ next;
+ }
+ undef $current if /^};\s*$/;
diff --git a/debian/patches/series b/debian/patches/series
index 69f49c8..39129ad 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@
07_hardening-cflags+cppflags.patch
08_small-typos-in-manpages.patch
09_fix-manpage-lilo-conf-5.patch
+10_fix-keytab-lilo.patch
--
2.19.1
signature.asc
Description: OpenPGP digital signature
Bug#839596: Please provide keytab-lilo in its own package
Hi,
Here is a refreshed patch (in Git format) to be applied on version 1:24.2-4.
Regards,
--
Raphaël Halimi
From 93281bc01553c0ec1220abbf7253aa7cde26dd57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Halimi?=
Date: Sun, 2 Oct 2016 16:39:58 +0200
Subject: [PATCH 2/2] Split keytab-lilo into its own package
---
debian/control | 12
debian/keytab-lilo.dirs | 1 +
debian/keytab-lilo.install | 1 +
debian/keytab-lilo.manpages | 1 +
debian/lilo.install | 1 -
debian/lilo.manpages| 1 -
6 files changed, 15 insertions(+), 2 deletions(-)
create mode 100644 debian/keytab-lilo.dirs
create mode 100644 debian/keytab-lilo.install
create mode 100644 debian/keytab-lilo.manpages
diff --git a/debian/control b/debian/control
index 16a9a17..b3653be 100644
--- a/debian/control
+++ b/debian/control
@@ -37,3 +37,15 @@ Description: LInux LOader - Documentation for the classic OS boot loader
.
This package contains the old HTML and README documentations of lilo
version 21.5 (of year 2000).
+
+Package: keytab-lilo
+Architecture: all
+Depends: perl, console-data, ${misc:Depends}
+Description: LInux LOader - compile keytables files for use with LILO
+ You can use LILO to manage your Master Boot Record (with a simple text
+ screen, text menu or colorful splash graphics) or call LILO from other
+ Boot-Loaders to jump-start the Linux kernel.
+ .
+ This package contains the keytab-lilo tool, which is a Perl script that can
+ compile keytable files to use with LILO and other tools (for example SYSLINUX,
+ which uses the same keytable format).
diff --git a/debian/keytab-lilo.dirs b/debian/keytab-lilo.dirs
new file mode 100644
index 000..236670a
--- /dev/null
+++ b/debian/keytab-lilo.dirs
@@ -0,0 +1 @@
+usr/sbin
diff --git a/debian/keytab-lilo.install b/debian/keytab-lilo.install
new file mode 100644
index 000..c7a73f8
--- /dev/null
+++ b/debian/keytab-lilo.install
@@ -0,0 +1 @@
+usr/sbin/keytab-lilo
diff --git a/debian/keytab-lilo.manpages b/debian/keytab-lilo.manpages
new file mode 100644
index 000..b53d61e
--- /dev/null
+++ b/debian/keytab-lilo.manpages
@@ -0,0 +1 @@
+man/keytab-lilo.8
diff --git a/debian/lilo.install b/debian/lilo.install
index fbbeb91..89b5eb1 100644
--- a/debian/lilo.install
+++ b/debian/lilo.install
@@ -1,6 +1,5 @@
sbin/lilo
usr/sbin/mkrescue
-usr/sbin/keytab-lilo
usr/sbin/liloconfig
usr/sbin/lilo-uuid-diskid
etc/kernel/post*
diff --git a/debian/lilo.manpages b/debian/lilo.manpages
index 23864c9..2ac0e7e 100644
--- a/debian/lilo.manpages
+++ b/debian/lilo.manpages
@@ -1,4 +1,3 @@
-man/keytab-lilo.8
man/lilo.8
man/lilo.conf.5
man/mkrescue.8
--
2.19.1
signature.asc
Description: OpenPGP digital signature
Bug#915121: Typo in man page resulting in wrong indentation of several subsections
Package: screen Version: 4.6.2-3 Severity: minor Tags: patch Hi, Here is a patch to fix a nasty typo in the manpage. In "CUSTOMIZATION" section, the "displays" subsection has an indented paragraph, but it's not reverted afterwards, making several following subsections (from "digraph" up to and including "resize") wrongly indented twice. This small (one line) patch fixes that. It's in quilt format, with DEP-3 headers. Regards, -- Raphaël Halimi Description: Fix a typo in man page resulting in wrong indentation In "CUSTOMIZATION" section, the "displays" subsection has an indented paragraph, but it's not reverted afterwards, making several following subsections (from "digraph" up to and including "resize") wrongly indented twice. This small (one line) patch fixes that. Author: Raphaël Halimi Forwarded: no Last-Update: 2018-11-30 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/doc/screen.1 +++ b/doc/screen.1 @@ -1901,6 +1901,7 @@ \*QDisplays\*U needs a region size of at least 10 characters wide and 5 characters high in order to display. .RE +.RE .TP .IR "\fBdigraph\fR " [ preset [ unicode-value ]] .RS 0 signature.asc Description: OpenPGP digital signature
Bug#911750: Race condition in d-i leading to kernel from security.debian.org to be kept back
Le 24/10/2018 à 14:15, Ben Hutchings a écrit : >> When the kernel metapackage (linux-image-) is initially installed, >> APT doesn't install recommended packages, and security.debian.org >> repository is not configured yet, so the installer naturally fetches the >> latest kernel from the core suite. After APT configuration, and other >> repositories and suites are available, debian-installer runs an upgrade; >> but if a newer version of linux-image- is found in one of those >> newly available repositories (security.debian.org in this case), it's >> not installed because APT refuses to install the recommended packages >> (firware-linux-free, irqbalance) to satisfy dependencies, so the kernel >> metapackage is kept back. > > I'm fairly sure it's the ABI bump in the kernel that prevents > upgrading, not the recommended packages. This is tracked as #908711. You're right, it seems so obvious now. Sorry for the duplicate, I did search the web for "bugs debian-installer kernel not upgraded during installation" but the title of this bug was too different, and I missed it. Do you want me to close this one, or to merge it ? Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#911750: Race condition in d-i leading to kernel from security.debian.org to be kept back
Package: debian-installer Version: 20170615+deb9u4 Hi, I just noticed a race condition in d-i, which may lead to a mild security risk. When the kernel metapackage (linux-image-) is initially installed, APT doesn't install recommended packages, and security.debian.org repository is not configured yet, so the installer naturally fetches the latest kernel from the core suite. After APT configuration, and other repositories and suites are available, debian-installer runs an upgrade; but if a newer version of linux-image- is found in one of those newly available repositories (security.debian.org in this case), it's not installed because APT refuses to install the recommended packages (firware-linux-free, irqbalance) to satisfy dependencies, so the kernel metapackage is kept back. It won't be installed until the admin runs an upgrade manually, once the system is booted. This may put it at risk during a certain period of time between the first boot, and the first upgrade (and reboot). Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#905285: tlp activates suspend even when on AC
Le 02/08/2018 à 16:30, alberto a écrit : > I just substituted my stolen thinkpad x250 with a x270. Sorry for your loss. I experienced that myself in late 2012, this is a terrible experience. Fortunately, mine was fully encrypted, and I had a recent (less than one week) full backup. I hope you took the same precautions. > Despite that tlp-stat reports correctly that the power source is AC, tlp > always starts the suspend process after some inactivity even if I configured > PM (through xfce GUI) not to suspend on AC. > > This is the log: > > Aug 2 11:20:26 systemd[1]: Starting TLP suspend/resume... > Aug 2 11:20:26 systemd[1]: Started TLP suspend/resume. > Aug 2 11:20:26 systemd[1]: Reached target Sleep. > Aug 2 11:20:26 systemd[1]: Starting Restart Syncthing after resume... > Aug 2 11:20:26 systemd[1]: Starting Suspend... > Aug 2 11:20:26 systemd[1]: Started Restart Syncthing after resume. > Aug 2 11:20:26 systemd-sleep[11509]: Suspending system... > Aug 2 11:20:26 kernel: [ 1685.988411] PM: suspend entry (deep) > > Note that this never happened with the x250. > > BTW, I tried to perform some diagnostics but I could not find anything. > I do not even find a proper setting to avoid this (tried searching into > /etc/default/tlp). Are you positively sure that it's not something triggered by XFCE ? AFAIK, TLP doesn't activate suspend at all (hence the lack of such a setting in the configuration file). You may have been mislead by the log messages showing "TLP suspend/resume", which merely indicate that TLP's pre/post suspend hooks are being run. I don't know XFCE very well, so I'll ask you to double-check every setting even remotely related to power management. Also, if you want to be absolutely sure, try to purge TLP, and see if your computer still exhibits the same behavior. > I don't know if this is relevant but I found other stuffs related to > thinkpad in syslog: > > Aug 2 15:57:13 kernel: [ 7848.767292] thinkpad_ec: > thinkpad_ec_request_row: arg0 rejected: (0x01:0x00)->0x00 > Aug 2 15:57:13 kernel: [ 7848.767298] thinkpad_ec: > thinkpad_ec_read_row: failed requesting row: (0x01:0x00)->0xfffb > Aug 2 15:57:13 kernel: [ 7848.767305] thinkpad_ec: initial ec test > failed > > In addition, tlp-stat says: > +++ ThinkPad Battery Features > tp-smapi = inactive (unsupported hardware) > tpacpi-bat = active > > and, actually, I can use tlp BAT settings even without smapi. That's perfectly normal. Lenovo discarded the SMAPI interface starting with the X230 (read [1]). Newer models must use tpacpi-bat (which uses acpi-call) to set the battery (dis)charge thresholds. This also explains your error messages emanating from thinkpad_ec : it can't find the interface it's looking for. Normally, on your X270, you shouldn't install tp-smapi-dkms, but acpi-call-dkms instead. I'm not sure about the improved hdaps driver, though, but I guess you got an SSD with your new X270, so you shouldn't need it anyway. [1] http://www.thinkwiki.org/wiki/Tp_smapi Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#903320: debian-installer: drops ULA address after network setup
Package: debian-installer Version: stable Tags: d-i ipv6 Hi, I have a purely virtual bridge (no physical device attached to it) to serve libvirt/QEMU/kvm virtual machines. I'm trying to implement an IPv6-only test network. On this network, hosts each get two addresses : a stateful ULA address (served by DHCPv6), and an SLAAC global address (configured from plain Router Advertisements only). Both prefixes are advertised by radvd. The global prefix is provided from my ISP, and passed to the virtual network through prefix delegation. The DNS server also has an ULA address inside this prefix, and is only reachable through that address (the firewall is configured to accept connections from addresses from the same prefix only). This works well with a fully installed system: both addresses are automatically brought up, and I can reach remote global addresses as well as local ULA addresses (from this prefix or from other ones), provided iptables allows the forwarding. However, d-i behaves in a way that prevents it to run successfully in this network. During the network setup, it does indeed get both addresses, sets up routes accordingly, and also gets other settings from the DHCP server (domain name, DNS server, etc etc). At this time, I'm still able to ping remote and local hosts in the console. But, after setting the host name and the domain name, for an unexplained reason, d-i immediately drops the ULA address (it's noted in the log) and keeps only the global address. This prevents the installation to proceed afterwards (when the network is needed to download packages), because although the Internet is still accessible, name resolution doesn't work (since the DNS server drops packets coming from the global address). I also tried without advertising the global prefix with radvd, and again, at the same point during the installation process, d-i removes the ULA address (which leaves the system with only the link-local address this time). Note that I tried with Buster alpha 3 image too, and d-i behaves exactly the same. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#895416: gpg hangs and consumes 100% CPU (Thunderbird -> Enigmail -> GPG)
Dear maintainer, I'd like to inform you that for some days, I can't observe these symptoms anymore on my Sid box; Enigmail is again able to fetch unknown GPG keys and display a green banner once the signature is verified. Since there were no update of Thunderbird or Enigmail recently, but there was a GnuPG update on 2018-06-09, it seems it was indeed a GnuPG bug after all. As far as I'm concerned, this bug can be closed. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#895416: gpg hangs and consumes 100% CPU (Thunderbird -> Enigmail -> GPG)
Control: fixed -1 1:52.8.0-1 For a couple of days now, thunderbird doesn't exhibit those symptoms anymore, and I was able to let an instance sitting on a workspace for two whole days without having the CPU go crazy. Note that according to APT history log, Thunderbird was upgraded from 1:52.7.0-1 to 1:52.8.0-1 on May 20, which matches the disappearance of the symptoms. I initially had a doubt about which package to file the report against (Thunderbird or Enigmail), but it seems that my guess was right after all (it can't be a coincidence since there were no GnuPG or Enigmail update on that day). On the other hand, Enigmail now fails to automatically retrieve **any** signature from the key server, and displays a yellow header with the "Import key" button, which can't import the key either. After manually downloading the key (from command line), Enigmail is able to correctly verify the signature and a green header is displayed, which indicates that the problem indeed lies in the communication between Enigmail and the key server. I tried to change the key server option in Enigmail's preferences from "pool.sks-keyservers.net" to "hkps.pool.sks-keyservers.net", to "hkps://hkps.pool.sks-keyservers.net", to "pgp.mit.edu", but it made no difference. The gpg command used by Enigmail is: /usr/bin/gpg --charset utf-8 --display-charset utf-8 --no-auto-check-trustdb --batch --no-tty --status-fd 2 --keyserver-options auto-key-retrieve --keyserver pool.sks-keyservers.net --sender --verify /tmp/data.sig By copying file /tmp/data.sig before it's deleted, and trying to run the very same command line on the copied file, I get this: gpg: no signed data gpg: can't hash datafile: No data So this bug report can be closed (no more random key fetching nor abnormal CPU consumption) but a new bug appeared. What else can I do to help debugging this ? Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#781923: Bug #781923: more info
Hi, My doubts about this being "the same bug" are confirmed: this was not. My system actualy suffered from #897572, which was almost entirely fixed by plymouth 0.9.3-3. I say "almost" because there is still a 4-5 seconds difference between boot times with or without plymouth (I didn't test again without plymouth today, but now systemd-analyze still shows an average boot-time of approximately 15 seconds, instead of 10 without plymouth during my tests a week ago), but the huge delay with the graphical theme is gone, and the graphical splash screen is again properly displayed (also, when I did my tests a week ago, I figured that trying to get a console by repeatedly pressing Ctrl-Alt-F2 kind of shortened this huge delay, which concurs with the behavior described in #897572). The shutdown delay still happens occasionally though, but now I'm not sure anymore if it's caused by plymouth. So, this last e-mail was not about #781923 but really about #897572, which can be considered as fixed as far as I'm concerned. Sorry for the confusion. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#781923: Bug #781923: more info
I have a sid box which I don't reboot often, and it currently suffers from the same symptoms. I'm not sure it's the same bug, but here are my observations. Without plymouth: Startup finished in 5.468s (kernel) + 4.736s (userspace) = 10.204s graphical.target reached after 4.726s in userspace With plymouth, non-graphical theme (details): Startup finished in 5.698s (kernel) + 8.751s (userspace) = 14.450s graphical.target reached after 8.740s in userspace With plymouth, graphical theme (softwaves): Startup finished in 2min 52.748s (kernel) + 8.743s (userspace) = 3min 1.492s graphical.target reached after 8.733s in userspace Funny thing is, with the last test, plymouth doesn't even display a splash screen, only the console with a blinking cursor on top left corner. Also with the last test, the shutdown is slowed down too, with the message: A stop job is running for User Manager for UID 127 On this machine, UID 127 matches Debian-gdm. As a side note, this machine used to have SysV as init system but I recently (2018-04-11) switched it so systemd. I'm not sure that's related (I don't remember if the bug hit me after the change or not), but I specify it for the sake of completeness. Hope it helps. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#896890: Consider swapping aliases and completion stanzas in /etc/skel/.bashrc
Package: bash Version: 4.4.18-2 Severity: wishlist Hi, If you source completion files from ~/.bash_aliases, to use them for your aliases (a trick I learned in the New Maintainer's Guide, see [1]), a non-login shell (like Gnome Terminal's default, or a default screen session) outputs errors at the beginning, complaining about the missing "_have" function (which is indeed not yet sourced). The simple fix for this problem is to source the completion files before the ~/.bash_aliases file. Please consider making this the default for newly created users by swapping the order of the last two stanzas in /etc/skel/.bashrc. [1] https://www.debian.org/doc/manuals/maint-guide/modify.html Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#896889: Consider removing useless "auth-nxdomain no;" (now default) from named.conf.options
Package: bind9 Version: 1:9.11.3+dfsg-1 Severity: wishlist Hi, Since Bind version 9, the default value for "auth-nxdomain" is "no", which now makes it useless to set it to "no" in /etc/bind/named.conf.options. It could confuse users by leading them to think that the default is "yes", which was true for bind 8, but not anymore. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#895898: [Pkg-libvirt-maintainers] Bug#895898: virt-install adds "method=" boot parameter, which is copied to Grub config
Le 18/04/2018 à 19:13, Guido Günther a écrit : > That's a good start. Please forward this upstream (the actual fix will > likely have to be in a slightly different location) Hi, According to [1], the bug was already was already fixed upstream (but not in version 1.5 (which is still to be packaged), after a look at [2]; probably for a future release). I'll let to your appreciation what to do with my small patch, packaging it in unstable (or even stable, if you plan to backport 1.4.3 or 1.5 someday) would be nice, but if you don't want to bother with a bug which will eventually be fixed upstream after 1.5, I'd understand. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1569485#c1 [2] https://github.com/virt-manager/virt-manager/blob/40c678783e6c7d1f1c5c9b09e2640a54eb8be5a4/virtinst/urlfetcher.py Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#895416: gpg hangs and consumes 100% CPU (Thunderbird -> Enigmail -> GPG)
Rectification: the second gpg process spawned is not exactly identical, it uses an hkp:// URI instead of hkps://. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#895898: [Pkg-libvirt-maintainers] Bug#895898: virt-install adds "method=" boot parameter, which is copied to Grub config
Le 18/04/2018 à 08:45, Guido Günther a écrit :
> Check _kernelFetchHelper where it adds the method arg. I doubt this is
> needed at all on Debian but rather a leftover of other distros.
Hi again,
Thanks to your hint, and after a bit of fiddling (remember I don't know
python), I came up with the simple patch attached.
It implements the second solution (remove "method=" altogether if the
distribution is detected as "Debian").
It should be tested with other guest distributions though.
Also, I think you could also check if self.name is equal to "Ubuntu",
but I'm not sure if ubuntu-installer needs (or support) "method=" or not.
Do you want me to create and forward a bug upstream ?
Regards,
--
Raphaël Halimi
--- /usr/share/virt-manager/virtinst/urlfetcher.py.orig 2017-09-14 23:49:00.0 +0200
+++ /usr/share/virt-manager/virtinst/urlfetcher.py 2018-04-18 17:29:08.902639187 +0200
@@ -661,7 +661,8 @@
args = ''
if not self.fetcher.location.startswith("/"):
-args += "%s=%s" % (self._get_method_arg(), self.fetcher.location)
+if self.name != "Debian":
+args += "%s=%s" % (self._get_method_arg(), self.fetcher.location)
try:
initrd = self.fetcher.acquireFile(initrdpath)
signature.asc
Description: OpenPGP digital signature
Bug#895898: virt-install adds "method=" boot parameter, which is copied to Grub config
Package: virtinst Version: 1:1.4.0-5 Severity: minor Hi, I'm trying to fully automatically install virtual machines by means of a preseed file. I set "--location" to the desired URL and add some parameters to "--extra-args" to ask debian-installer to run an automated installation, tell it where to fetch the preseed file, and add some parameters that I want copied to the installed system's boot configuration (for example "elevator=noop"). This works almost perfectly, but there one slight problem: for a reason I don't understand, virt-install adds "method=" to the kernel parameters (qemu's "-append" option), *after* the contents of "--extra-args". As stated in its documentation, debian-installer will copy most kernel parameters found after "--" or "---" to the installed system's boot configuration (eg. in /etc/default/grub), filtering the ones it thinks are destined to itself; so if the "--extra-args" option contains "--" or "---", the "method=..." argument ends up being copied in /etc/default/grub, which of course is not desired. Obviously, debian-installer filter doesn't catch it. Now, I'm not sure what would be the correct fix for this. I see two possibilities: - the conservative (and simple) one: modify virt-install to add "method=..." *before* the contents of "--extra-args", so that if the latter contains "--" or "---", "method=..." will be positioned before those, and won't be copied to the installed system's boot configuration. - the risky one: modify virt-install to not add "method=..." at all; after re-reading debian-installer's documentation, I didn't see this parameter mentioned anywhere. Come to think of it, this shouldn't be needed: virt-install already fetches the kernel and initrd, and passes them to the VM, so I can't see why debian-installer should need to know how they were fetched. If the second suggestion is totally wrong, and debian-installer does know (and thus, sometimes need) "method=..." (it should be documented, then !), maybe the bug should be reassigned to debian-installer, and ask to add "method=..." to the list of filtered parameters, to prevent it to be passed to Grub. I tried to find by myself where the "-append" option is constructed, to provide a patch for the first fix, but I don't know much python and couldn't understand the scripts. If you give me a hint about this, I'll be glad to (try to) help. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#895418: systemd-shim: incompatibility with a new version of systemd
Package: systemd-shim Version: 10-3 Severity: important Affects: gdm3 Hi, I admit I didn't spend much time investigating this issue (I need a working Sid box), but from past experience, I guess it comes from a new systemd-shim incompatibility introduced by some change in systemd-logind (or GDM, but IMHO it's less unlikely than systemd). The symptoms are identical to #801749 (but since people there mention journalctl, I guess they were not using SysV init, so it can't be a duplicate of this bug): GDM doesn't start (the screen keeps displaying the console, with the cursor blinking frenetically), and syslog shows lots and lots of "gdm3: Child process XYZ was already dead." and "gdm3: Unable to kill session worker process". lightdm (under SysV init) does start normally. Switching the init system to systemd gets rid of the problem, and allows GDM to start normally (this is why I'm filing this report against systemd-shim). Please note that I didn't try to downgrade systemd or GDM to find the exact culprit (or the version introducing the change), I made an educated guess and switched the init system directly, which worked. I have a lot of stuff to do on my Sid box ATM and I can't afford the time. Please also note that I don't reboot this box very often, so the incompatibility may have been introduced by a systemd update a long time ago, not necessarily the latest one. Regards, -- Raphaël Halimi
Bug#895416: gpg hangs and consumes 100% CPU (Thunderbird -> Enigmail -> GPG)
Package: thunderbird Version: 1:52.7.0-1 Severity: important Hi, I'm not quite sure about which component in the chain (Thunderbird -> Enigmail -> GPG) is the root cause of this, feel free to reassign as appropriate of course. I'm also not sure of which update introduced this bug, because I don't reboot or restart applications on my Sid box very often. The latest Thunderbird update was done on 2018-03-27, but I noticed this behavior since yesterday only. Also, please note that I chose to set the severity to "important" because the CPU consumption makes the PC fans quite noisy, to the point that I cannot keep Thunderbird sitting on an unused workspace anymore. Feel free to drop it if you think that's not justified. The symptoms are as follows: Thunderbird randomly tries to import public GPG keys (it's really random, it happens when I'm not even using Thunderbird to read e-mails, it's just sitting on a different workspace) and the CPU consumption becomes very high. Looking for the culprit with top, I can see a GPG process using one whole CPU core, spawned by Thunderbird, and with the following options: /usr/bin/gpg --charset utf-8 --display-charset utf-8 --no-auto-check-trustdb --batch --no-tty --status-fd 2 --keyserver hkps://hkps.pool.sks-keyservers.net:443 --recv-keys Killing the process immediately spawns a new identical one; killing the second one makes Thunderbird rest for some time, until the problem occurs again with a new key ID (generally in a matter of minutes). Trying to fetch the key manually by copying the GPG command line in a terminal works perfectly, which makes me think that the problem comes from Thunerbird (or Enigmail), not from GPG. Note that the key IDs belong to people related to free software; I'm subscribed to a lot mailing lists (mostly Debian ones), but through Gmane (and consequently Thunderbird NNTP reader). Could it be that Thunderbird silently reads new entries in those newsgroups and tries to fetch the GPG keys ? This would be surprising, given that normally Thunderbird doesn't update the newsgroups unless I specifically ask it to (by clicking on a group, or selecting "Get new messages" on the news account, in the left panel), but that's the only explanation I could find for the source of the random GPG key IDs it tries to fetch. Regards, -- Raphaël Halimi
Bug#895413: No software cursor with Xwayland (bright cursor with Night Light enabled)
Package: gnome-shell Version: 3.28.0-1+b1 Severity: minor Hi, I'm not quite sure about which Gnome (or Wayland) component is the cause of this, feel free to reassign as appropriate of course. With Gnome on Wayland session (now the default) and Night Light mode, the cursor in unaffected by the change in color temperature, which gives it a bright blue aspect that makes it eye-catching. This is a known problem with redshift, for which the fix is to force software cursor in Xorg configuration. "Gnome on Xorg" session seems to do this automatically, because the cursor's color temperature is the same as the rest of the screen, without needing to modify Xorg configuration; "Gnome on Wayland" doesn't. Switching to "Gnome on Xorg" session gets rid of the problem. Regards, -- Raphaël Halimi
Bug#895238: postfix: consider changing the default mailer type to "Local only" instead of "Internet site"
Le 08/04/2018 à 20:26, Scott Kitterman a écrit : > Your example isn't relevant to Debian. In Ubuntu, Postfix is the > default MTA. In Debian, it's not. If a non-default MTA is being > pulled in by a package that only needs a generic MTA, then it's buggy > and should be fixed. Ah, sorry, I don't use Ubuntu, so I didn't know. Feel free to close the bug then, if you think it's not relevant. Regards, -- Raphaël Halimi
Bug#895238: postfix: consider changing the default mailer type to "Local only" instead of "Internet site"
Package: postfix Version: 3.3.0-1 Severity: wishlist Hi, I report this bug following my own advice in [1]. I have set the severity to wishlist, but from a security point of view, it could be considered much higher. The default Postfix configuration, when keeping the default debconf answers, listens on all network interfaces. Unlike what's said in #418511, this doesn't make it an open relay though, since mynetworks is restricted to localhost. Nevertheless, OP in [1] is IMHO quite right, this is still a "network-exposed attack surface". My rationale is : until Stretch, the "standard" installation comprised exim4-daemon-light, which fulfilled all dependencies on the "mail-transport-agent" virtual package, which in turn implicated that users installing Postfix did so manually, and knew what they were doing. Unfortunately, from Stretch onward, now that no MTA is present in the standard installation, some dependencies chains can end up installing a random MTA "unexpectedly" (I put quotes around "unexpectedly", because one should always carefully read the list of installed dependencies when installing a package, but we all know that users are not always that careful). IMHO it would be wise to change the default answer to the debconf question "postfix/main_mailer_type" to "Local only" instead of "Internet site", in order to limit the security risk in case Postfix was installed "unexpectedly" due of an overlooked dependency chain. [1] https://bugs.launchpad.net/debian/+source/tlp/+bug/1758798 Regards, -- Raphaël Halimi
Bug#894740: acpi-call-dkms: Bad return status for module build on kernel: 4.14.0-0.bpo.2-amd64
Le 05/04/2018 à 19:23, Lorenzo Ancora a écrit : > For business users (like me), backports packages are not stable and > therefore are still in the testing phase. From the point of view of > those who configure the machines in the company it is always convenient > to reduce the number of experimental packages in use, even if - for > obvious security and compatibility reasons - on the most used machines > the kernel must be recent (of course the longterm branch of the Linux > kernel is always well tested). That's true, but my remark remains: if your hardware doesn't absolutely need a backported kernel, you shouldn't use a backported kernel. If you do so, there are packages that the kernel expects to be at some compatible version. That being said, I'm not quite comfortable with your wording: backports are not "experimental". Backported packages are taken from testing, which means, among other things, that they have already been for some time in unstable (and sometimes, even before, in **experimental**) and no serious bug has been reported for a certain period of time. Please read [1] for more information. [1] https://wiki.debian.org/DebianTesting Now, if you want to continue this discussion, I suggest we do so privately, and stop spamming this bug report; the bug was found and fixed long ago. Regards, -- Raphaël Halimi
Bug#894740: acpi-call-dkms: Bad return status for module build on kernel: 4.14.0-0.bpo.2-amd64
Le 04/04/2018 à 01:26, Lorenzo Ancora a écrit : > I was not able to find bug #868110 in reportbug: > As you can see the list is blank, except for this and another bug > report. Probably due to the version mismatch. > Next time I will make the archaeologist directly on the website, > ignoring the official app. :-) Hi Lorenzo, Sorry if I've been a bit harsh. I rarely use reportbug, I do prefer relying on the good old BTS, with its web and mail interfaces. I didn't even know that there was no way in reportbug to search for closed and/or archived bugs. Also, similarly to what you did, I received half a dozen reports from Launchpad for the very same bug around the time the HWE kernel (which is some kind of backport if I understand correctly) hit Xenial, whereas the fix was already available in Artful. I hate that both BTSs default to hide closed bugs, but on the other hand, bugs are supposed to be reported against unstable, not stable. Kernel modules are peculiar in this regard, because people often need to run backported kernels due to hardware support needs. >> [...] a backport for Stretch is available since August 28th, 2017. > We are in 2018 and it dates back to 8 months ago. Why is not part of > Stable after so much time? > Good to know there is a quick solution. :-) Simple, that's because the mainline kernel in Stretch is still 4.9, and 1.1.0-3 does compile correctly with it. If you use a backported kernel, you should also use backported versions of many packages needed by the kernel, among them are the kernel modules like acpi-call. > Thank you, the experimental version compiles correctly. Backports and experimental are two totally different things in Debian ;) Regards, -- Raphaël Halimi
Bug#894740: acpi-call-dkms: Bad return status for module build on kernel: 4.14.0-0.bpo.2-amd64
Control: forcemerge 868110 -1 This bug is a duplicate of #868110, which was fixed in 1.1.0-4, and a backport for Stretch is available since August 28th, 2017. Please double check the archived bugs next time you report a bug. Regards, -- Raphaël Halimi
Bug#894511: Please emphasize in the documentation a possible race condition in if-*.d hooks with systemd
Package: ifupdown Version: 0.8.31 Severity: wishlist tl;dr A major difference in handling the "auto" and "allow-hotplug" interfaces between systemd and sysinit script leads to a possible race condition when a hook in if-*.d isn't protected against multiple concurrent runs (example: iptables scripts) Long version: With /etc/init.d/networking script, network interfaces configured with class "auto" are raised first, and only when that's done, interfaces configured with class "allow-hotplug" are then raised: ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose With systemd, the unit file only calls: /sbin/ifup -a --read-environment ...letting udev (I guess) take care of the interfaces configured with class "allow-hotplug", the major difference being that both steps are done concurrently. (by the way, it may deserve its own bug report, but "--read-environment" isn't documented anywhere) This leads to situation where a given hook in /etc/network/if-*.d can end up running multiple times simultaneously. To be precise, I encountered the problem with a hook which sets iptables rules (the idea of putting it in pre-up.d was that the interfaces were firewalled before even being raised; I admit this may be a questionable practice, but that's not the subject of this bug report), with iptables producing errors when a chain was flushed by a second instance of the script, while the first instance, which already flushed this same chain before, now tried to add rules to it. This never posed a problem with SysV, but this happens with systemd, because it calls "ifupdown -a" (which runs all hooks with IFACE="--all", even when no interface is configured with class "auto", as described in the manual page), and simultaneously lets udev try to raise the single network interface (which is configured with class "allow-hotplug" by debian-installer by default). Note that in my case, replacing "allow-hotplug" with "auto" in /etc/network/interfaces was sufficient to work around the problem, but things may be different with custom hooks doing other stuff. The NEWS.Debian file's entry for 0.8 states that: "Ifupdown will now be more strict when errors occur, and will also properly return a non-zero exit code when (de)configuring an interface fails. Please ensure your /etc/network/interfaces is correct and that your interfaces can be brought up and down without errors, especially during system startup." IMHO, this doesn't emphasize enough on the fact that a given hook in if-*.d must be able to run several times simultaneously, as the SysV init script did everything sequentially, whereas systemd raises "auto" and "allow-hotplug" interfaces concurrently, so a hook which worked perfectly fine with SysV can produce errors when run with systemd. I suppose the aggressive parallelizing done by systemd is expected behavior, and my goal is not to question that here - by no means am I suggesting to fix the unit file so that it mimics the init script - but IMHO, there should be at least some kind of warning documented somewhere (hence the wishlist severity). It may seem late, but I guess I'm not the only admin who decided to wait until Jessie+N to start letting systemd handle the init process, and such a warning in the docs may help other people in the future, saving them a lot of time if they wonder why systemd randomly fails to raise their network interfaces, when SysV didn't. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#886517: More info
Hi, I just stumbled upon this bug while installing munin-node on a Stretch machine. It seems due to the fact that the "time" package used to be Priority: standard, whereas in Stretch it's now Priority: optional. "time" is also a shell keyword in bash (but not in dash), and this one doesn't understand the "-f" option. So, despite the fact that the plugin uses /bin/bash in its shebang, it does indeed need the real "time" binary from the "time" package. The plugin could also be patched to throw an error at some point if the "$time_bin" variable is empty, but it would be much easier (and useful) to just add the dependency. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#883976: nfs-common: Shell script executed by systemd to mount net /home * /var fails
Le 09/12/2017 à 23:32, Duncan Hare a écrit :
> Why during boot are the messages:
>
> mount: can't find 192.168.1.10:/nsfroot/b827eb/c23849/var /var in /etc/fstab
> mount: can't find 192.168.1.10:/nsfroot/b827eb/c23849/home /home in /etc/fstab
>
> being generated as though the root id during boot is a normal unprivilaged
> unser?
> /usr/bin/setup-var-home.sh:
> #!/bin/bash
> H=$(hostname);
> #H="b827ebc23849";
> /bin/mount 192.168.1.10:/nsfroot/${H:0:-6}"/"${H:6:12}"/var /var";
> /bin/mount 192.168.1.10:/nsfroot/${H:0:-6}"/"${H:6:12}"/home /home";
I'm not sure a shell script is the best way to mount NFS exports at boot
(I have read your other recent bug reports, I'm aware that you're
currently encountering problems with NFS mounts at boot, but running a
shell script for solving this seems a bit overkill to me), but in this
case, this has nothing to do with NFS or systemd, it's your shell script
which is flawed.
More precisely, you placed the double-quotes in a way that makes the
shell consider everything after /bin/mount as one long argument. You
could remove those double-quotes altogether, since it seems you name
your NFS exports according to your machines' hostnames, and a hostname
can't contain spaces ([1]), but if you absolutely want to hold onto
them, try to correctly quote the different arguments, for example:
/bin/mount 192.168.1.10:/nsfroot/"${H:0:-6}"/"${H:6:12}"/var /var
or:
/bin/mount 192.168.1.10:/nsfroot/"${H:0:-6}/${H:6:12}"/var /var
or:
/bin/mount 192.168.1.10:/nsfroot/"${H:0:-6}/${H:6:12}/var" /var
or, to be absolutely clear as to what the mount command expects, and how
to quote arguments accordingly:
/bin/mount "192.168.1.10:/nsfroot/${H:0:-6}/${H:6:12}/var" "/var"
I understand that you may be a bit frustrated with those aforementioned
problems you're currently encountering with your NFS mounts at boot, but
filing bug reports at the drop of a hat is counter-productive. Not only
are you nagging this package's maintainers, but also other people (like
me) who don't maintain this package but subscribed to receive its bug
reports.
After verifying that what I'm suggesting works as you expect (but then
again, I sincerely doubt a shell script is the way to go here), please
spare the maintainers a bit of their (precious) time and close this bug.
[1] https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames
Regards,
--
Raphaël Halimi
signature.asc
Description: OpenPGP digital signature
Bug#882764: pbuilder: invokes debootstrap with option --arch twice
Package: pbuilder Version: 0.229 Severity: minor Hi, Trying to investigate the inability for pbuilder to create/use a wheezy chroot (it's in fact due to a bug in fakechroot, which affects debootstrap, see #650234), I noticed in pbuilder's debug log that debootstrap is invoked with the --arch option twice: + debootstrap --arch=amd64 --include=apt --arch amd64 --variant=buildd --force-check-gpg wheezy /var/cache/pbuilder/build/12539 http://ftp.fr.debian.org/debian/ I guess it's harmless, but it may be confusing when reading the debug logs. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#650234: More information
Hi, This bug is still present and nowadays prevents debootstrap to create an amd64 wheezy chroot on a current amd64 sid, or pbuilder to work with a previously created wheezy base-tgz. I'm not coder, so maybe this remark will seem obvious to some, but creating an i386 wheezy chroot on a current amd64 sid system works correctly though. I imagine that the difference in architectures forces fakechroot to use the linker (or some other part, I don't quite understand the problem) from the chroot. Can't this behavior be mimicked when the architecture is the same ? Again, I'm no coder, please don't take offense if this is a silly question. As wheezy is now LTS, this bug is quite annoying since it prevents maintainers to use pbuilder to maintain packages for wheezy (I currently have to use a VM). Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#832111: Please add a fake "status" function to init script (like in procps)
Ping ? Now that Standards-Version 4.0.0 recommends support for a "status" init script argument... Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Bug#881925: gnome-tweak-tool: overwrites all values in key /org/gnome/settings-daemon/plugins/xsettings/overrides
Package: gnome-tweak-tool
Version: 3.22.0-1
Severity: normal
Tags: upstream
Hi,
I use the dconf-key
/org/gnome/settings-daemon/plugins/xsettings/overrides to set the
xsettings keys "Gtk/ButtonImages" and "Gtk/MenuImages" to 1, in order to
display icons in GTK menus.
Unfortunately, this is overwritten by gnome-tweak-tool when enabling or
disabling "Application menu" in the "Top bar" tab (sorry, this may not
be the exact text, I'm translating from French, "LANG=C
gnome-tweak-tool" doesn't work), by replacing the whole string with
"{'Gtk/ShellShowsAppMenu':<1>}" (or 0), regardless of other xsettings
overrides that were already present.
This is very annoying, gnome-tweak-tool should detect if other keys are
already present, and add its override to the string, not overwrite the
whole string.
The bugs is at least present in Stretch and Sid, although I suspect (but
can't confirm) that it appeared way before that.
Regards,
--
Raphaël Halimi
signature.asc
Description: OpenPGP digital signature
