Bug#1033894: lintian: bad-distribution-in-changes-file bookworm
On Tue, 28 Nov 2023 13:00:00 -0700 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= wrote: > The fix for this issue is still only in git at > https://salsa.debian.org/lintian/lintian/-/commit/ebb739d102d55797516c0f10452e4e4c2502644d > and there has not been any new Lintian uploads since Lintian 2.116.3 > in February 2023. > > Anybody maintaining packages in Bookworm and using Salsa-CI is bound > to hit on hard failure as Lintian will error on this one. Example > https://salsa.debian.org/otto/mariadb-server/-/jobs/4976386: > > E: mariadb changes: bad-distribution-in-changes-file bookworm The fix was released in lintian 2.117.0. But unless it's backported to bookworm, the problem you highlighted remains. -- Arnaud Rebillout / OffSec / Kali Linux Developer
Bug#930472: lintian: systemd-service-file-missing-install-key shouldn't fire for dbus activated services
Hi Chris,
On 6/13/19 11:05 PM, Chris Lamb wrote:
> tags 930472 + moreinfo
> thanks
>
> Hi Arnaud,
>
>> Upstream ships a systemd service file, and a d-bus service file. The
>> rauc daemon is d-bus activated (meaning, it's automatically started by
>> the client when needed).
> […]
>> So, well, I don't know if Lintian is aware of dbus service files that
>> get installed at `/usr/share/dbus-1/` (I'm not familiar with lintian at
>> all). If so, then Lintian could look for a key `SystemdService=` in the
>> d-bus service file, along with `BusName=` in the systemd service file.
> Perhaps I'm missing something but it looks sufficient to not emit this
> tag if the .service file contains a `BusName=` key, no need to look at
> any other files.
I did a bit of reading, but I'm not the d-bus expert, so this is just my
understanding.
1. A d-bus service that wants to "bus-activatable" ships a d-bus service
file in /usr/share/dbus-1 [1]
2. A d-bus service that wants to be started with systemd ships a systemd
service file in /lib/systemd/system, and provides `BusName=`
3. A d-bus service that wants both ships both files, and uses
`SystemdService=` in the d-bus service file, so that d-bus can let
systemd start the service.
Based on that, it seems to me that there's room for d-bus service that
just do number 2: ship a systemd service file, but don't want to be
dbus-activatable, and don't ship a d-bus service file.
Well, that's my understanding, and that's just theory.
Practice now, let me check what's up on my system
$ ack -l BusName= /lib/systemd/system | wc -l
27
$ ack -l BusName= /lib/systemd/system | xargs grep '\[Install\]' | wc -l
11
# -> a bit less than 50% of the BusName= services here have an
[Install] section
Now let's see how many of these services have a d-bus service file that
contains `SystemdService=`
$ c=0
$ services=$(ack -l BusName= /lib/systemd/system | rev | cut -d/ -f1 |
rev | sort)
$ for svc in $services; do grep -q -rn "SystemdService=$svc"
/usr/share/dbus-1/ || { echo "$svc ko"; c=$(expr $c + 1); }; done
$ echo "$c BusName= systemd services don't have a dbus service file
with SystemdService="
avahi-daemon.service ko
bluetooth.service ko
gdm.service ko
iio-sensor-proxy.service ko
ModemManager.service ko
NetworkManager-dispatcher.service ko
NetworkManager.service ko
switcheroo-control.service ko
systemd-hostnamed.service ko
systemd-importd.service ko
systemd-localed.service ko
systemd-logind.service ko
systemd-machined.service ko
systemd-timedated.service ko
14 BusName= systemd services don't have a dbus service file with
SystemdService=
I didn't look into all of them. But avahi proved to be a good example of
a the case number 2. If you look at
usr/share/dbus-1/system-services/org.freedesktop.Avahi.service, you will
see:
# This service should not be bus activated if systemd isn't running,
# so that activation won't conflict with the init script startup.
Exec=/bin/false
So this is a good example of a service that provides `BusName=` and also
requires a Install section in the systemd service file.
What do you think of all of that ?
Cheers,
Arnaud
[1]: https://dbus.freedesktop.org/doc/system-activation.txt
Bug#930472: lintian: systemd-service-file-missing-install-key shouldn't fire for dbus activated services
Package: lintian Version: 2.15.0 Severity: normal Dear Maintainer, * What led up to the situation? I'm working on the rauc package at https://salsa.debian.org/debian/rauc/ * What exactly did you do (or not do) that was effective (or ineffective)? I build the package, then lintian runs. * What was the outcome of this action? Lintian complains about systemd-service-file-missing-install-key, and it's true, there's no install key in the rauc.service file provided by upstream. * What outcome did you expect instead? The warning should not fire in this case. Upstream ships a systemd service file, and a d-bus service file. The rauc daemon is d-bus activated (meaning, it's automatically started by the client when needed). This use-case is described in the systemd service documentation, https://www.freedesktop.org/software/systemd/man/systemd.service.html#id-1.10.6, (see Example 5. DBus services). May I quote: For bus-activatable services, do not include a "[Install]" section in the systemd service file ... So, well, I don't know if Lintian is aware of dbus service files that get installed at `/usr/share/dbus-1/` (I'm not familiar with lintian at all). If so, then Lintian could look for a key `SystemdService=` in the d-bus service file, along with `BusName=` in the systemd service file. If both are found, Lintian shouldn't complain then about a missing [Install] key. We could even go as far as asking Lintian to complain about the *existence* of [Install] in this case, but maybe I'm getting carried away... Thanks, Arnaud -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.31.1-16 ii bzip2 1.0.6-9 ii diffstat 1.62-1 ii dpkg 1.19.6 ii dpkg-dev 1.19.6 ii file 1:5.35-4 ii gettext0.19.8.1-9 ii gpg2.2.12-1 ii intltool-debian0.35.0+20060710.5 ii libapt-pkg-perl0.1.34+b1 ii libarchive-zip-perl1.64-1 ii libcapture-tiny-perl 0.48-1 ii libcgi-pm-perl 4.40-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.41-1+b1 pn libdigest-sha-perl ii libdpkg-perl 1.19.6 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libio-async-perl 0.72-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b4 ii libparse-debianchangelog-perl 1.2.0-13 ii libpath-tiny-perl 0.108-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii libtry-tiny-perl 0.30-1 ii liburi-perl1.76-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.76+repack-1 ii man-db 2.8.5-2 ii patchutils 0.3.4-2 ii perl 5.28.1-6 ii t1utils1.41-3 ii xz-utils 5.2.4-1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b5 Versions of packages lintian suggests: pn binutils-multiarch ii libhtml-parser-perl3.72-3+b3 ii libtext-template-perl 1.55-1 -- no debconf information
Bug#891892: lintian: False positive: statically-linked-binary despite the Build-Depends on golang-go
Package: lintian Version: 2.5.67~bpo9+1 Severity: normal Dear Maintainer, Package concerned (should be pushed in Debian experimental soon) https://salsa.debian.org/elboulangero-guest/golang-gogottrpc Build the package with gbp clone https://salsa.debian.org/elboulangero-guest/golang-gogottrpc.git cd golang-gogottrpc gbp buildpackage --git-pbuilder --git-dist=sid Then run lintian lintian ../golang-gogottrpc*changes E: gogottrpc: statically-linked-binary usr/bin/protoc-gen-gogottrpc W: gogottrpc: binary-without-manpage usr/bin/protoc-gen-gogottrpc The statically-linked-binary warninf shouldn't be there, as the field Build-Depends contains: golang-go (>= 2:1.9~) | golang-1.9-go Best regards, Arnaud -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.28-5 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.18.24 ii file 1:5.30-1+deb9u1 ii gettext 0.19.8.1-2 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.32 ii libarchive-zip-perl 1.59-1 ii libclass-accessor-perl0.34-1 ii libclone-perl 0.38-2+b1 ii libdpkg-perl 1.18.24 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.94-1 ii liblist-moreutils-perl0.416-1+b1 ii libparse-debianchangelog-perl 1.2.0-12 ii libperl5.24 [libdigest-sha-perl] 5.24.1-3+deb9u2 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.71-1 ii libxml-simple-perl2.22-1 ii libyaml-libyaml-perl 0.63-2 ii man-db2.7.6.1-2 ii patchutils0.3.4-2 ii perl 5.24.1-3+deb9u2 ii t1utils 1.39-2 ii xz-utils 5.2.2-1.2+b1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b2 Versions of packages lintian suggests: ii binutils-multiarch 2.28-5 ii dpkg-dev 1.18.24 ii libhtml-parser-perl3.72-3 pn libtext-template-perl -- no debconf information
