Bug#1017951: lintian: Recognize cherry-picked patches as forwarded upstream
Source: lintian Version: 2.115-2 I use this packaging workflow where I have fetched an upstream git remote: gbp pq import git cherry-pick -x 123456 gbp pq export This creates Debian patches that have this line (cherry picked from commit 12345) Although this doesn't strictly follow DEP-3, I think it complies with the general idea and I don't think these patches should get tagged as patch-not-forwarded-upstream https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Debian/Patches/Dep3.pm#L88 Thank you, Jeremy Bicha
Bug#924082: more dh-sequences
On Sat, Mar 9, 2019 at 9:27 AM Chris Lamb wrote: > https://salsa.debian.org/lintian/lintian/commit/f8887189f6bafcf799889b271ce30e8cd7311c03 > > > Support dh-sequence-{gir,gnome,python3} virtual packages as satisfying > various build-dependencies. (Closes: #924082) > We can grep through the Packages list to find more dh-sequence provides. dh-python also provides dh-sequence-pypy and dh-sequence-python2 cli-common-dev provides dh-sequence-cli debhelper provides dh-sequence-dwz, dh-sequence-installinitramfs, dh-sequence-systemd libdbi-perl provides dh-sequence-perl-dbi libimager-perl provides dh-sequence-perl-imager scour provides dh-sequence-scour Thanks, Jeremy Bicha
Bug#924082: lintian: missing-build-dependency triggered for dh-sequence
Source: lintian Version: 2.10.0 debhelper 12 supports a new special dh-sequence- build-depends feature [1]. For instance, a Build-Depends on dh-sequence-gnome (a virtual package provided by gnome-pkg-tools) will automatically pass the '--with gnome' option to dh without needing that to be specified in debian/rules. The lintian tags need to be updated for this. For instance, here's the lintian errors I got with totem 3.32.0-1 targeted at experimental. The final error "missing-build-dependency gnome-pkg-tools" triggered an auto-reject. E: totem source: missing-build-dependency-for-dh_-command dh_python3 => dh-python E: totem source: missing-build-dependency-for-dh_-command dh_girepository => gobject-introspection E: totem source: missing-build-dependency gnome-pkg-tools So if you find the dh_python3 helper is being used, a Build-Depends on dh-sequence-python3 should satisfy the requirement. If you can, I'm requesting that this issue be fixed for Buster since a growing number of packages will be using dh-sequence. [1] https://manpages.debian.org/unstable/dh#OPTIONS Thanks, Jeremy Bicha
Bug#921449: lintian: stop saying that GTK is misspelled
Source: lintian Version: 2.5.124 Severity: minor GTK+ is now GTK so I suggest dropping these 2 lines: https://salsa.debian.org/lintian/lintian/blob/master/data/spelling/corrections-case#L54-55 I don't really think it's worth complaining about GTK+ since I believe GTK3 needs to still identify itself as GTK+. References https://gitlab.gnome.org/GNOME/gtk/issues/1439 Thanks, Jeremy Bicha
Bug#920536: lintian: fails to build because of test failure
Source: lintian Version: 2.5.124 Severity: serious Tags: ftbfs lintian fails to build as seen in Ubuntu and with Reproducible Builds. The latest upload was not a source-only upload so there isn't a failure on the buildds. https://tests.reproducible-builds.org/debian/rb-pkg/lintian.html https://launchpad.net/ubuntu/+source/lintian/2.5.124/+build/16320548 Build log excerpt Tags do not match # --- t/tags/tests/legacy-libbaz/tags 2019-01-24 22:47:53.0 + # +++ /build/1st/lintian-2.5.124/debian/test-out/tags/tests/legacy-libbaz/tags.actual.parsed.sorted 2020-02-28 21:47:32.0 + # @@ -33,8 +33,12 @@ # I: libbaz1-dev: package-contains-empty-directory usr/include/ # I: libbaz1-dev: wrong-section-according-to-package-name libbaz1-dev => libdevel # I: libbaz1: binary-has-unneeded-section usr/lib/ma-dir/perl/version/auto/Foo/Foo.so .comment # +I: libbaz1: file-references-package-build-path usr/lib/libbaz1.so.1.0.3b # +I: libbaz1: file-references-package-build-path usr/lib/libbaz3.so.1.0.3b # +I: libbaz1: file-references-package-build-path usr/lib/libfoo2.so.1.0.3b # I: libbaz1: no-md5sums-control-file # I: libbaz1: symbols-file-missing-build-depends-package-field # +I: libbaz2-dbg: file-references-package-build-path usr/lib/debug/usr/lib/libbaz2.so.1.0.3b # I: libbaz2-dbg: no-md5sums-control-file # I: libbaz2-dbg: wrong-section-according-to-package-name libbaz2-dbg => debug # I: libbaz2-dev: no-md5sums-control-file # Failed test 'Lintian tags match for legacy-libbaz' # at /build/1st/lintian-2.5.124/lib/Test/Lintian/Run.pm line 334. # Looks like you failed 1 test of 1. Thanks, Jeremy Bicha
Bug#920314: lintian: vcs-field-has-unexpected-spaces has false positives
On Thu, Jan 24, 2019 at 3:43 AM Chris Lamb wrote: > * Can you confirm that "hg clone -b foo" works? If so, we > should update Policy to (at least) also permit "-b branchname" > or "[branchname]" for Mercurial repos. The manpage suggests that -b works for hg, but hg is rare enough in Debian that I'm not personally interested in updating policy for it. I agree with the suggestions here that none of these are currently valid according to Debian Policy. Could you please update the Lintian extended description for this tag to link to https://www.debian.org/doc/debian-policy/ch-controlfields.html#version-control-system-vcs-fields ? Once that's done, feel free to close this bug. Thanks, Jeremy Bicha
Bug#920314: lintian: vcs-field-has-unexpected-spaces has false positives
Source: lintian Version: 2.5.123 I think all of these are false positives except for rust-num-cpus. https://lintian.debian.org/tags/vcs-field-has-unexpected-spaces.html In particular, -b or --branch should be allowed for Vcs-Git (but not Vcs-Browser). One usecase is tot have a separate branch for each Debian series. Because you can then use git clone https://salsa.debian.org/gnome-team/atk.git -B debian/jessie It looks like hg works the same way. Thanks, Jeremy Bicha
Bug#918444: lintian: Guile-2.2 object files triggger several warnings and errors
Source: lintian Version: 2.5.119 X-Debbugs-CC:guile-...@packages.debian.org It looks like the Guile 2.2 object files are reported as errors and warnings for - binary-from-other-architecture - shared-lib-without-dependency-information - unstripped-binary-or-object An example package is aisleriot . (You can also easily switch the Build-Depends in buster from guile-2.2-dev to guile-2.0-dev to compare.) Maybe it would be helpful to exclude .go and .gox files from these checks? Note 1 - lintian isn't the only thing that has trouble with these unusual files. See https://bugs.debian.org/907061 for dh_strip. Note 2 - These are not to be confused with .go files from the Go programming language. I guess Go tends to put their files in /usr/share/ and Guile puts its files in /usr/lib/ Thanks, Jeremy Bicha
Bug#917345: lintian: Include debhelper-compat method in description of setting compat level
Source: lintian Version: 2.5.118 The description of tags like package-uses-experimental-debhelper-compat-version and package-uses-deprecated-debhelper-compat-version suggest 2 different ways of setting the debhelper compat level. It should instead suggest the new debhelper-compat Build-Depends method which looks like it is now the recommended way to set the compat level, regardless of whether you use compat level 12 yet. See https://manpages.debian.org/unstable/debhelper#COMPATIBILITY_LEVELS Thanks, Jeremy Bicha
Bug#917344: lintian: debhelper compat 12 is no longer experimental
Source: lintian Version: 2.5.118 debhelper 12 was released this week. With this release, compat level 12 is now the recommended compat level. [1] Therefore, I suggest bumping data/debhelper/compat-level recommended=12 experimental=13 [1] https://manpages.debian.org/unstable/debhelper#Supported_compatibility_levels Thanks, Jeremy Bicha
Bug#916497: package-contains-documentation-outside-usr-share-doc should ignore /usr/share/help
Source: lintian Version: 2.5.116 Please have the package-contains-documentation-outside-usr-share-doc check ignore /usr/share/help/ . https://lintian.debian.org/full/pkg-gnome-maintain...@lists.alioth.debian.org.html#deja-dup and some other GNOME packages are getting this tag emited for contribute pages. Many GNOME projects install user help to /usr/share/help/ (It was intended to be cross-desktop but KDE ended up not implementing it yet.) Since it is a widely used documentation directory, emitting this tag is wrong here. Thanks, Jeremy Bicha
Bug#909267: library-not-linked-against-libc: downgrade from error
Chris, see https://bugs.debian.org/896012 Thanks, Jeremy Bicha
Bug#909267: library-not-linked-against-libc: downgrade from error
On Thu, Sep 20, 2018 at 6:18 PM Russ Allbery wrote: > Maybe exclude shared libraries linked with glib (and whatever the Qt > equivalent is)? One package that triggers this tag a lot is samba and it doesn't use glib or qt. https://lintian.debian.org/maintainer/pkg-samba-ma...@lists.alioth.debian.org.html#samba Thanks, Jeremy Bicha
Bug#909267: library-not-linked-against-libc: downgrade from error
Source: lintian Version: 2.5.103 X-Debbugs-CC: naes...@gmail.com, s...@debian.org We noticed that library-not-linked-against-libc is triggered for several GNOME packages. [1] smcv had these comments -- "I think that tag is too high-priority tbh. In frameworks like GLib and Qt it's far from unusual to do everything with higher-level functions and not use libc directly at all, and -Wl,--as-needed turns that into no dependency. In the parts of Debian that are not GNOME the tag triggers a lot less often, because -Wl,--as-needed seems to be mostly a GNOME meme? if someone is upset about that tag, I think it's fine to objdump -Tx the offending object, say 'look, it has all the DT_NEEDED it needs' and override the tag. Bonus penguin points if you write an autopkgtest that dlopens it to prove that it's possible, I suppose." - So I'm requesting that the tag be downgraded from error. Please also downgrade the description where it claims a library to not use libc is only theoretical and not very likely. [1] https://lintian.debian.org/maintainer/pkg-gnome-maintain...@lists.alioth.debian.org.html Thanks, Jeremy Bicha
Bug#908911: lintian: Allow dir-or-file-in-etc-opt to be overridable
Source: lintian Version: 2.5.103 Affects: chrome-gnome-shell chrome-gnome-shell ships a file in /etc/opt/ [1] so that it integrates with Google Chrome. Google Chrome installs to /opt/ and uses /etc/opt/ for configuration. Although this stirred up a bit of controversy [2] in Debian, it seems to me like this is acceptable for Debian. (Despite chrome-gnome-shell's name, it also integrates with Firefox and Chromium.) I tried to set a lintian override but it looks like this tag is listed as non-overridable in profiles/debian/ftp-master-auto-reject.profile According to https://bugs.debian.org/840235 it is not actually a ftp-master autoreject any more. [1] https://lintian.debian.org/tags/dir-or-file-in-etc-opt.html [2] https://bugs.debian.org/888549 Thanks, Jeremy Bicha
Bug#907734: package-contains-documentation-outside-usr-share-doc false positive
On Mon, Sep 10, 2018 at 5:17 AM Chris Lamb wrote: > > What about cross-gcc-dev, equivs, jekyll, and the fwupd and grub > > signed templates? > > Those are covered in Git already, no? Oh, I don't read perl regex very well. :) Jeremy
Bug#907734: package-contains-documentation-outside-usr-share-doc false positive
On Mon, Sep 10, 2018 at 4:53 AM Chris Lamb wrote: > > I think there are some examples where "template" would be needed to > > avoid false positives. > > > > https://lintian.debian.org/tags/package-contains-documentation-outside-usr-share-doc.html > > Looks like we are only currently (ie. in Git) missing ones ending > in .d. I have added these here: What about cross-gcc-dev, equivs, jekyll, and the fwupd and grub signed templates? Jeremy
Bug#907734: package-contains-documentation-outside-usr-share-doc false positive
On Mon, Sep 10, 2018 at 4:22 AM Chris Lamb wrote: > I made it somewhat more generic; I don' think it should match > "templates" anywhere, at least for the time being. Applied in Git (with > test), pending upload: I think there are some examples where "template" would be needed to avoid false positives. https://lintian.debian.org/tags/package-contains-documentation-outside-usr-share-doc.html Thanks, Jeremy
Bug#908442: lintian: package-contains-documentation-outside-usr-share-doc still false positives
Package: lintian Version: 2.5.101 Severity: minor X-Debbugs-CC: r...@debian.org This is a follow-up from https://bugs.debian.org/907734 https://salsa.debian.org/lintian/lintian/commit/f6941026e6c0 Please make the template check more generic. I suggest looking for the string "template" anywhere in the path name instead of just "/templates/". My specific test case is: I: gnome-builder: package-contains-documentation-outside-usr-share-doc usr/share/gnome-builder/plugins/autotools_templates/resources/CONTRIBUTING.md I: gnome-builder: package-contains-documentation-outside-usr-share-doc usr/share/gnome-builder/plugins/autotools_templates/resources/README.md Thanks, Jeremy Bicha
Bug#897213: lintian: Please remove dependency-on-python-version-marked-for-end-of-life until after Buster releases
> Just out of interest, do you have any concrete examples? See https://bugs.debian.org/894560 which was clearly wrong because it still had lots of rdepends for the py2 library. For a recent example of where several py2 libraries were dropped with apparently almost no complaints, see the python-xstatic* packages from https://qa.debian.org/developer.php?email=openstack-devel%40lists.alioth.debian.org Personally, I don't have a problem with unused Python2 libraries being dropped now (the debian-devel conversations don't have full consensus either way). The pygame example is relatively rare and easily fixed. Thanks, Jeremy Bicha
Bug#895674: lintian: maybe-not-arch-all-binnmuable emitted for (= ${source:Version})
On Sat, Apr 14, 2018 at 5:49 PM, Chris Lamb wrote: > I don't see how any of these (*) are useful to some wishing to > uncover hidden problems with their packages. I guess I'd want to know if the source format were not 3.0 (quilt) but that's a rare enough issue that it's probably not worth the noise. I'll go ahead and turn off classification on my system. Thanks, Jeremy Bicha
Bug#895674: lintian: maybe-not-arch-all-binnmuable emitted for (= ${source:Version})
On Sat, Apr 14, 2018 at 3:32 PM, Chris Lamb wrote: > > https://salsa.debian.org/lintian/lintian/commit/800b1344880b70995c5a26754d2a891ae0ef7d5d > > … in particular: > > At this time, please do not attempt to "fix" the problem. It > is not clear what the solution is (if any at all). Nor is it clear > that this is something that will be supported. Note that that text was *removed* from the tag description in that commit (!!). > So, alas, changes may even be incorrect (!). I am unsure, hence > tagging as moreinfo for the time being. > > (As an aside, how come you show classification checks? Surely they > are far too noisy/useless..? I also wonder if this should be an > X "experimental" tag instead as that would have been less strange.) I thought some of the classification tags were useful. Do you have a list of all the classification checks to help me reconsider? I don't show experimental tags. This particular tag is problematic because it encourages people who see the tag to change the packaging so that the tag isn't emitted. ( I have done that in several packages but will undo it as I touch the packages again and notice.) Thanks, Jeremy Bicha
Bug#895674: lintian: maybe-not-arch-all-binnmuable emitted for (= ${source:Version})
Source: lintian Version: 2.5.82 Test Case When I build gnome-shell, lintian emits this: C: gnome-shell source: maybe-not-arch-all-binnmuable gnome-shell -> gnome-shell-common But gnome-shell depends on gnome-shell-common (= ${source:Version}), I am told that is a correct dependency relationship despite some of the confusing Lintian descriptions. I have however been changing these to (>= ${source:Version}) which makes the lintian output go away. https://salsa.debian.org/gnome-team/gnome-shell Thanks, Jeremy Bicha
Bug#895574: lintian: binary-compiled-with-profiling-enabled test fails on Ubuntu's armhf
Source: lintian Version: 2.5.81 Ubuntu runs its autopkgtests for all of its supported architectures. One of lintian's tests (binary-compiled-with-profiling-enabled) fails when the autopkgtest is run on armhf. armhf is a bit different than the other Ubuntu architectures because it uses a different kind of virtualization (sorry I don't remember the details); not sure if that's relevant here or not. You can see the test failures at http://autopkgtest.ubuntu.com/packages/l/lintian/bionic/armhf I'm letting you know that this issue prevents Ubuntu from being able to automatically sync lintian, but instead we need to maintain a manual diff. See http://ubuntudiff.debian.net/?query=-FPackage+lintian Thanks, Jeremy Bicha
Bug#889814: lintian: Improve long description of epoch-change-without-comment
To help reduce the need to use an epoch later, I think we should recommend packages with date-based numbering use a version number prefixed with something like 0~. For instance, the current version of fonts-noto-color-emoji in Debian is 0~20180102-1. This could possibly be a Lintian warning if a date-based format is detected for a new Debian package. Some packages can avoid the use of an epoch by using an epoch only for the specific packages that need an epoch by manipulating dh_gencontrol. For instance, this is done in fonts-ubuntu to use epochs only for the transitional packages (which we'll be able to drop in a few months). https://salsa.debian.org/fonts-team/fonts-ubuntu/blob/debian/unstable/debian/rules This trick is probably only useful when a package changes names (like gcompris will probably become a transitional package depending on gcompris-qt soon and only the gcompris package needs the epoch). Thanks, Jeremy Bicha
Bug#885974: lintian: warn about non-git Vcs fields
On Mon, Jan 1, 2018 at 1:49 AM, Russ Allbery wrote: > I would hold off on complaining about anonscm. I'm pretty sure someone > will find a way to keep it going and redirecting, similar to the intention > with the mailing lists. Should we warn now about any non-git vcs hosted at Debian? Because even if there are redirects, it would be a bit wrong to have Vcs-Svn actually point to a git repo… > (I host most of mine on my own infrastructure), and if someone wants to > use Bzr or Subversion, I'm not sure that Lintian nagging them is going to > change their mind. What about QA packages? Maybe those at least should be using git hosted with Debian. Thanks, Jeremy Bicha
Bug#885974: lintian: warn about non-git Vcs fields
Source: lintian Version: 2.5.66 I think it's time for Lintian to warn about Vcs fields other than Git. It looks like this was mentioned at https://bugs.debian.org/884503 but no separate bug was filed for it. That bug points to https://lists.debian.org/debian-devel/2015/12/msg00383.html . I think the impression there was that it wasn't important enough to add to lintian then. An important difference now is that the Debian project plans to stop offering any active VCS hosting except for git soon. Here's some wording suggestions. Feel free to modify. Modify vcs-field-bitrotted (warning) Any *.debian.org repo except salsa.debian.org All version control system hosting provided by Debian is expected to become read-only on 1 May 2018 except for git hosting at https://salsa.debian.org/ . For more information, see https://wiki.debian.org/Salsa . Add vcs-field-other-than-git (warning or info) After 1 May 2018, Debian will not offer any version control system hosting other than git. While maintainers are free to use other version control systems hosted elsewhere, most potential contributors are familiar with git. Thanks, Jeremy Bicha
Bug#885106: lintian: Please update dh_commands for scour 0.36
Package: lintian Version: 2.5.65 Please update data/debhelper/dh_commands since dh_scour is now provided by python3-scour only as of scour 0.36-1 published today. This fixes this wrong lintian error: missing-build-dependency-for-dh-addon scour => python-scour Thanks, Jeremy Bicha
Bug#884870: lintian: vcs-field-has-unexpected-spaces and vcswatch don't agree
Source: lintian Version: 2.5.65 I changed webkit2gtk's Vcs-Git field from Vcs-Git: https://anonscm.debian.org/git/pkg-webkit/webkit.git to Vcs-Git: https://anonscm.debian.org/git/pkg-webkit/webkit.git -b wk2/unstable in order to satisfy https://qa.debian.org/cgi-bin/vcswatch?package=webkit2gtk which complained that it couldn't find the current debian/changelog in HEAD. (Maybe it's time to change HEAD, but this bug is also a problem for experimental and Stable Update branches.) Now, I think (lintian's website is recovering from a typo) that this now causes lintian to emit vcs-field-has-unexpected-spaces I think the " -b BRANCHNAME" suffix should be considered valid syntax for Vcs-Git. Thanks, Jeremy Bicha
Bug#880115: lintian: Please add bionic as known Ubuntu distribution
Source: lintian Version: 2.5.57 Something like this but for bionic (future Ubuntu 18.04 LTS) https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=3053db3 Thanks, Jeremy Bicha
Bug#873520: lintian: Check for bad-distribution in debian/changelog too
On Tue, Oct 17, 2017 at 7:23 PM, Chris Lamb wrote: > However, unless I'm missing something this would mean that every > time you built a package locally as part of regular development it > would emit this tag. I don't see that as a problem, but I really don't like seeing packages with UNRELEASED changelogs in Debian. Thanks, Jeremy Bicha
Bug#873520: lintian: Check for bad-distribution in debian/changelog too
Source: lintian Version: 2.5.52 I was surprised to see that pyjunitxml 0.6-1.2 was accepted into Debian unstable with its debian/changelog still set to UNRELEASED. I guess the uploader managed to generate a valid .changes file. https://tracker.debian.org/news/859782 lintian already has a check for bad-distribution-in-changes-file I request that a bad-distribution-in-debian-changelog check be added. I think this would make a good candidate for dak auto-reject too. Thanks, Jeremy Bicha
Bug#829047: lintian: javalib-but-no-public-jars for transitional packages
On Sun, Jul 31, 2016 at 11:03 AM, Niels Thykier wrote: > I fear you may have a bug in your package. A transitional package > should use "transitional package" and not "transitional dummy package" > in their description. Maybe you missed this commit? https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=6c531ba The short description does include "transitional package". I like the idea of getting rid of the unnecessary "dummy" so perhaps that could be an additional lintian check? We'd also need to update https://wiki.debian.org/Renaming_a_Package Jeremy
Bug#693918: lintian: Add test for missing keywords
Package: lintian Version: 2.5.10.2 Severity: wishlist Keywords is a relatively new addition to the desktop entry spec that improves the ability to find apps by typing in related words. GNOME Shell, Unity, and Software Center currently support Keywords. Also, GNOME Shell 3.6 no longer uses the "Comment" field for searching so the discoverability since GNOME 3.4 will likely regress a bit until developers add keywords to their .desktop files. I'd like to see a lintian test that reports when a package includes a .desktop without Keywords (except for .desktop files that have NoDisplay=true; set). GNOME developers will probably take care of adding keywords for GNOME 3.8 core apps but this should help increase developer awareness for other apps. https://live.gnome.org/GnomeGoals/DesktopFileKeywords http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg00066.html Jeremy - -- System Information: Debian Release: wheezy/sid APT prefers raring-updates APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 'raring'), (100, 'raring-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAajCMY=jtqbr_ucm1rs5jqda4tzesyhrukcyrv9mqq7uhe...@mail.gmail.com