Bug#943525: marked as done (lintian: Create private name spaces for tags)
Your message dated Mon, 13 Jul 2020 20:40:28 -0700 with message-id and subject line Implemented as an optional feature has caused the Debian Bug report #943525, regarding lintian: Create private name spaces for tags to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 943525: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943525 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lintian Severity: wishlist Hi, Tags currently reside in a global name space, which has many drawbacks. Based on my difficulties of separating reused tags in the 'files' family of checks, the time is right to implement private name spaces. Then two checks can share the same tag name without a conflict. Some things may break, like overrides. We can probably fix those by adding the name changes to data/override/renamed-tags. I am happy to present advantages if someone wants to hang on to the current setup. For now, let's focus on: (1) What's the best tag format? (2) How can we mitigate potential breakage for custom profiles such as FTP Master and pkg-perl-tools, as well as for downstream users in Debian derivatives? Here are some suggestions for the format: debian/changelog/malformed-version debian/changelog:malformed-version debian/changelog->malformed-version debian/changelog@malformed-version debian/changelog#malformed-version malformed-version debian/changelog^malformed-version Putting the check up front means the tags sort naturally. Also, some formats interfere less with shell scripts than others. All suggestions are welcome. Which is your favorite? Kind regards, Felix Lechner --- End Message --- --- Begin Message --- Hi, Being a controversial feature, namespaces for tags were implemented as an optional feature. They are necessary to accommodate and organize tags from packaging teams, but will not affect the majority of tags Lintian issues. Most Lintian tags will remain global references, although they already depend in other ways on the checks that issue them. More details can be found here: https://salsa.debian.org/lintian/lintian/-/commit/3013d6d9ef7ad860571435d5e31c3c279e4836bf Kind regards Felix Lechner--- End Message ---
Team Lintian checks and tags now part of mainline
Dear Perl Team, Starting with Lintian's next release, your team's checks and tags are part of our mainline program. Details are available here: https://salsa.debian.org/lintian/lintian/-/commit/3afe3b88ff8f5090335e82843bb002cb1922199a No more merge requests from our side. Plus, you will eventually see your tags on lintian.d.o! Kind regards Felix Lechner
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Hi, Daniel Shahaf wrote: > After extending the key I re-pushed it to keyservers, but did not > regenerate the d/u/signing-key.asc export. (I'd like to automate > that regeneration, since my key appears in multiple packages' > signing-key.asc files, but that's a question for another thread.) That might be something for lintian-brush once a lintian check is there. Cc'ing Jelmer, the author of lintian-brush. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#819460: lintian: duplicate-updaterc.d-calls-in-postinst false positive
Hi Richard, > FYI, I also had to silence a duplicate-updaterc.d-calls-in-postinst > false positive in ddclient. The two calls to update-rc.d are in the two > branches of an 'if' statement, so it is not actually called twice. > > See lines 139 and 149 of: > https://salsa.debian.org/debian/ddclient/-/blob/debian/3.9.1-2/debian/postinst#L139 > > Commit that disabled the lintian check: > https://salsa.debian.org/debian/ddclient/-/commit/b65a60e072334f0cee52b41ed4b254bce0d02bad Glancing at this quickly, we now have: update-rc.d ddclient defaults >/dev/null invoke-rc.d ddclient start || exit 1 … yet we should be skipping the first due to: next unless /^(?:.+;|^\s*system[\s\(\']+)?\s*update-rc\.d\s+ So maybe we can fix this one. Can't immediately see why this is not working. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Package: lintian Version: 2.83.0 Severity: wishlist Tags: upstream Dear Maintainer, I noticed yesterday that the current source package of zsh-syntax-highlighting contains a debian/upstream/signing-key.asc file which contains an expired snapshot of upstream's signing key: the snapshot gives the key's expiration date as 2018-06-28.¹ I then generated and built that package on a then-current sid chroot and observed that no lintian warnings were logged about the expired key. I invoked lintian as «lintian --display-info --display-experimental --pedantic --color=always --no-tag-display-limit /build/*.changes /build/*.dsc /build/*.deb». I was wondering whether it would be a good idea for Lintian to add a check for expired keys in debian/upstream/signing-key.asc. Despite the name being in singular, signing-key.asc may contain multiple keys, just like upstream tar.gz.asc files may contain multiple people's signatures. I am not sure what the semantics of the check should be when that file contains multiple keys, only some of which are expired. When upstream's release manager (RM)'s identity changes, it can be useful to keep carrying the outgoing RM's public key, in order to make it easier to verify past and potential future upstream releases signed with that key. However, someone who had stepped down from being RM might let their key expire and not renew it until and unless they resume being the RM. An alternative point of view is that signing-key.asc should contain only keys that are currently in use, and older keys should be removed (they'll still be available in archived sourced packages). Under this point of view, there might be room for an additional check that the keys in signing-key.asc are indeed those keys used to sign the upstream tarball. Cheers, Daniel ¹ In this particular case, upstream's key is my key, and that key has been regularly extended (to 2020-07-01 and to 2021-12-31). After extending the key I re-pushed it to keyservers, but did not regenerate the d/u/signing-key.asc export. (I'd like to automate that regeneration, since my key appears in multiple packages' signing-key.asc files, but that's a question for another thread.)
Bug#964013: lintian: embedded-javascript-library should flag sphinx files too
Le 13/07/2020 à 12:43, Holger Levsen a écrit :
>
> https://salsa.debian.org/debian/developers-reference/-/commit/29014c3d02b1a44aa983557b4887f4302c2136c5
> shows how to use dh_sphinxdoc (instead of dh_linktree which also does
> and did the right thing here), which then in turn adds the right
> depends/recommends to the binary packages.
>
> (The dh_linktree solution used a hack/workaround in d/rules to turn
> the depends into recommends, but I recommend the dh_spinxdoc solution
> anyway.)
>
Thanks for your reply.
I'm already using "dh $@ --with python3,sphinxdoc --buildsystem=pybuild" [0]
and ${sphinxdoc:Depends} [1] but still get the warning.
So I've lintian-checked developers-reference binary package and found it also
has
the lintian warning (see [3] below).
language_data.js is missing from libjs-sphinxdoc, maybe that's the reason for
this.
Also dh_sphinxdoc doesn't seem to handle it like the other [2].
[0] https://salsa.debian.org/amurzeau/streamlink/-/blob/master/debian/rules#L14
[1]
https://salsa.debian.org/amurzeau/streamlink/-/blob/master/debian/control#L52
[2]
https://salsa.debian.org/python-team/modules/sphinx/-/blob/debian/master/debian/dh-sphinxdoc/dh_sphinxdoc#L326
[3]:
$ wget
http://ftp.de.debian.org/debian/pool/main/d/developers-reference/developers-reference_11.0.15_all.deb
$ lintian -EviIL +pedantic developers-reference_11.0.15_all.deb
N: Using profile debian/main.
N: Starting on group developers-reference/11.0.15
N: Unpacking packages in group developers-reference/11.0.15
N: Finished processing group developers-reference/11.0.15
N:
N: Processing binary package developers-reference
N: (version 11.0.15, arch all) ...
W: developers-reference: embedded-javascript-library
usr/share/developers-reference/_static/language_data.js please use sphinx
N:
N:This package contains an embedded copy of JavaScript libraries that are
N:now available in their own packages (for example, JQuery, Prototype,
N:Mochikit or "Cropper"). Please depend on the appropriate package and
N:symlink the library into the appropriate location.
N:
N:Refer to Debian Policy Manual section 4.13 (Convenience copies of code)
N:for details.
N:
N:Severity: warning
N:
N:Check: languages/javascript/embedded
N:
$ lintian --version
Lintian v2.83.0
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
signature.asc
Description: OpenPGP digital signature
Bug#964013: lintian: embedded-javascript-library should flag sphinx files too
Hi, On Mon, Jul 13, 2020 at 12:24:53PM +0200, Alexis Murzeau wrote: > I'm getting this new lintian warning for language_data.js, > but I can't find which binary package I should depend on. > > "sphinx" (as suggested by lintian) is a virtual package provided by > python3-sphinx > which doesn't contain "language_data.js" [0] and libjs-sphinxdoc (which seems > more > appropriate) does not contain "language_data.js" either [1]. [...] > This will help maintainers find the correct package to use. https://salsa.debian.org/debian/developers-reference/-/commit/29014c3d02b1a44aa983557b4887f4302c2136c5 shows how to use dh_sphinxdoc (instead of dh_linktree which also does and did the right thing here), which then in turn adds the right depends/recommends to the binary packages. (The dh_linktree solution used a hack/workaround in d/rules to turn the depends into recommends, but I recommend the dh_spinxdoc solution anyway.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#964013: lintian: embedded-javascript-library should flag sphinx files too
Hi, On Tue, 30 Jun 2020 13:45:07 +0200 Holger Levsen wrote: > [...] > > Out of these, three of them come from Sphinx: > - doctools.js > - language_data.js > - searchtools.js > > Please make lintian complain about embedding those. It seems the problem could > be quite widespread: > [...] I'm getting this new lintian warning for language_data.js, but I can't find which binary package I should depend on. "sphinx" (as suggested by lintian) is a virtual package provided by python3-sphinx which doesn't contain "language_data.js" [0] and libjs-sphinxdoc (which seems more appropriate) does not contain "language_data.js" either [1]. Is it an oversight, or is "language_data.js" somewhere else ? Also according to other embedded js warnings from lintian, the package name should be a binary package name (mostly libjs-something), maybe "sphinx" should be changed to the actual binary package to depend on ? (maybe libjs-sphinxdoc) This will help maintainers find the correct package to use. Thanks for your help :) [0] https://packages.debian.org/sid/all/python3-sphinx/filelist [1] https://packages.debian.org/sid/all/libjs-sphinxdoc/filelist -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#964770: lintian: lintian will get stuck on arm64
Hi Kentaro, On Sun, Jul 12, 2020 at 5:12 PM Kentaro Hayashi wrote: > > Here is the reproducible code. The failure does not reproduce on the Debian arm64 porterbox amdahl. In the code above, I removed the 'print $future' statement and replaced $loop->await with 'say $future->get'. The result is '4', presumably the number of processors on amdahl. I also forwarded your bug to the IRC channel #io-async. Someone there tested your initial filing in the docker container, as you described, on a Raspberry Pi4 and then the code you submitted later. Both ran fine. Do you have more information about your error? If you need help debugging your Perl setup, I can recommend the channel #perl-help. The good folks there would be able to shed light on it. Kind regards Felix Lechner
