Re: adequate maintenance
On Sat, 2024-05-04 at 21:52 +0200, Serafeim Zanikolas wrote: > I'm considering to ITA the adequate package, on the condition that (i) > the folks taking care of it to date, and (ii) the lintian team would be > okay for me to rewrite it in go. I understand that go is not the most > popular of languages in Debian and that lintian tools are mostly perl > and python. I don't like the Go idea, but I'm not involved in the lintian team nor in maintenance of adequate, also it isn't maintained by lintian folks. PS: bounced your mail to the original author, CCing them too. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1070221: lintian: warn about help2man generated pages containing errors loading shared libraries
Package: lintian Severity: wishlist For manual pages generated by tools like help2man that run binaries to get usage statements for conversion to manual page format, please check that the manual pages do not contain common text indicating that the executable or script was not able to run successfully, so didn't output any usage statement and so a useful manual page was not generated. For example when running an ELF executable: $ ./src/jbig2 jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot open shared object file: No such file or directory $ zcat /usr/share/man/man1/jbig2.1.gz .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. .TH JBIG2: "1" "February 2024" "jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot open shared object file: No such file or directory" "User Commands" .SH NAME jbig2: \- encoder for JBIG2 .SH DESCRIPTION src/jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot open shared object file: No such file or directory For example when running a Python script: $ ./foo.py Traceback (most recent call last): File "./foo.py", line 2, in import bar ImportError: No module named bar $ help2man --no-discard-stderr ./foo.py .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.49.3. .TH TRACEBACK "1" "May 2024" "Traceback (most recent call last):" "User Commands" .SH NAME Traceback \- manual page for Traceback (most recent call last): .SH DESCRIPTION .SS "Traceback (most recent call last):" .IP File "./foo.py", line 2, in .IP import bar .PP ImportError: No module named bar .IP File "./foo.py", line 2, in .IP import bar .PP ImportError: No module named bar .SH "SEE ALSO" The full documentation for .B Traceback is maintained as a Texinfo manual. If the .B info and .B Traceback programs are properly installed at your site, the command .IP .B info Traceback .PP should give you access to the complete manual. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Apache/Rivet HTML manual generation practices
On Wed, 2023-11-15 at 17:12 +, Massimo Manghi wrote: > I'm the upstream developer/maintainer of Apache/Rivet. I'm also the > maintainer of > the corresponding Debian package (libapache2-mod-rivet). > Apache/Rivet source code ships with an HTML manual generated from > Docbook XML files. We regenerate the manual right before releasing and put it > in > the tarball in order to save the Apache/Rivet user the task of figuring out > what tools > are needed in order to recreate the HTML pages (being Docbook not so popular > and not so > widely used now). I expect most folks would be fine with the existing HTML manuals on the website, but what about having the HTML manuals in a separate tarball for the users who need them locally and don't want to build them? https://tcl.apache.org/rivet/html/manuals.html https://dlcdn.apache.org/tcl/rivet/binary/ https://wiki.debian.org/AutoGeneratedFiles -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1053739: lintian: check that all URL fields contain valid web URLs
Package: lintian Severity: wishlist Please check that all the debian/control debian/upstream/metadata etc fields that are supposed to contain web URLs, have valid URLs. For example this URL should be flagged as invalid, since web browsers will assume it is a relative link, which will leave a broken link on any package websites that link to the package homepage. Homepage: https:/example.org -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#1031377: UDD/lintian: Needs to run lintian on all binaries generated from same source
On Thu, 16 Feb 2023 15:05:24 +0100 Lucas Nussbaum wrote: > What could work is: > run lintian on source > for each arch in the packages's architectures (except all) > run lintian on architecture packages + architecture 'all' packages > > But would that solve all issues? I discovered that it does not solve all issues. For example src:rust-bat builds bat. When you run lintian against the dsc and the deb it emits missing-notice-file-for-apache-license for the source package, but when you run it against only the dsc or only the deb it does not emit that tag. That is because the test checks that the NOTICE file from the source package is missing from the binary package. https://lists.debian.org/msgid-search/8062de5e3a1afbe988ce3d5453d211089242ba2a.ca...@debian.org -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: https://lintian.debian.org/ Down
On Tue, 2023-09-19 at 11:52 +, Francis Murtagh wrote: > I'm trying to figure out a lintian error: privacy-breach-uses-embedded-file. Hopefully the tag description helps you figure it out. If you need more help, for packages intended for the Debian archive, you can ask on the debian-mentors list or IRC channel, otherwise the #packaging channel. $ lintian-explain-tags privacy-breach-uses-embedded-file N: E: privacy-breach-uses-embedded-file N: N: This package creates a potential privacy breach by fetching data from an N: external website at runtime. Please remove these scripts or external HTML N: resources. N: N: Instead you can use the Debian package indicated in the context if it is N: compatible. N: N: Visibility: error N: Show-Always: no N: Check: files/privacy-breach N: Renamed from: privacy-breach-may-use-debian-package N: > Unfortunately the website seems to be down. The custom lintian runner service has been replaced by having UDD run lintian instead. It doesn't publish any of the documentation though. https://udd.debian.org/lintian/ > Although the wiki says it's > https://wiki.debian.org/Services/lintian.debian.org Updated: https://wiki.debian.org/Services/lintian.debian.org?action=diff=1=2 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1041896: lintian: detect changelog with both QA upload and new maintainer
Package: lintian Severity: wishlist Recently I noticed a package enter Debian with a changelog that was both a QA upload and introducing a new maintainer. This doesn't really make sense because a QA upload means it is still orphaned but a new maintainer means it has been adopted. Perhaps the person who did the upload didn't understand what QA uploads are for. Please check for QA uploads that change the maintainer and emit a warning for them. package (1.2.3-4) unstable; urgency=medium * QA upload. * New maintainer (Closes: #1234567). * Other changes here -- Some One Tue, 25 Jul 2023 02:10:51 + -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1039869: lintian: extend Vcs-* checks to upstream Repository/Repository-Browser URLs too
Package: lintian Version: 2.116.3 Severity: wishlist I noticed that a few packages use ssh:// URLs for the Repository field in the upstream metadata file. These are suboptimal since the user might not have an account or might not be the person in the URL when a username is hardcoded. The vcs-field-uses-not-recommended-uri-format tag covers this problem for the Debian Vcs-* fields, but lintian does not appear to check the upstream Repository/Repository-Browse fields. https://codesearch.debian.net/search?q=path%3A%2Fdebian%2Fupstream+Repository.*ssh%3A=0 In addition there are some packages with insecure URLs to git repos and the vcs-field-uses-insecure-uri tag does not flag those packages yet. https://codesearch.debian.net/search?q=path%3A%2Fdebian%2Fupstream+Repository.*git%3A=0 I think it would be a good idea to extend all of the Vcs-* field checks to also check the upstream Repository/Repository-Browse fields too. https://wiki.debian.org/UpstreamMetadata -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1034631: lintian: Warn for 32bit time_t / Y2038 problems
On Fri, 2023-04-21 at 15:17 +0200, Uwe Kleine-König wrote: > I'm not aware of a decision how this should be handled. There was some discussion on debian-arm about this. Initially the plan was new architectures, but more analysis has lead towards renaming affected library packages instead. I think the folks involved intend to bring the plan to debian-devel at some point. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1029808: lintian: warnings related to *.pyc *.pyo __pycache__/
Package: lintian Version: 2.116.1 Severity: wishlist X-Debbugs-CC: debian-pyt...@lists.debian.org The *.pyc *.pyo files are Python bytecode and are almost always generated from Python source code. Since Python 3 these are usually stored in a __pycache__/ directory. Since these files are not source code, they should not be present in the Debian source packages, but there are hundreds of them in Debian: $ apt-file -I dsc search --regex '\.py[co]$' | wc -l 507 Please complain on *.pyc *.pyo being present in Debian source packages. Please also check that when they are present, that they have a *.py source file present. When it is in the same directory it will have the same name but .py extension. When the generated files are in a __pycache__/ directory then *.pyc file name will contain .cpython-NN but the *.py source file will not. Please also complain about other files in __pycache__/ directories. Since these dirs are caches and caches are often ignored by various tools, the other files could get lost from backups, VCS repos, etc. $ apt-file -I dsc search __pycache__/ | grep -vF .cpython- ack: /t/swamp/__pycache__/notes.pl asciidoc: /tests/__test_data__/plugin/backends/__pycache__/.gitkeep mypy-protobuf: /test/generated/testproto/__pycache__/__init__.py mypy-protobuf: /test/generated/testproto/dot/com/__pycache__/__init__.py -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1029479: lintian: reject packages with debmake default description
Package: lintian Severity: wishlist X-Debbugs-CC: ftp-master yq was just accepted into Debian with a completely bogus description that is the default from the debmake automatic package generator. Please add a lintian tag and add it to the ftp-master auto-rejects. $ apt-cache show yq | grep-dctrl -s Description-en . Description-en: auto-generated package by debmake This Debian binary package was auto-generated by the debmake(1) command provided by the debmake package. $ dgrep -A5 'auto-generated' debmake /usr/lib/python3/dist-packages/debmake/control.py:desc = "auto-generated package by debmake" /usr/lib/python3/dist-packages/debmake/control.py-# /usr/lib/python3/dist-packages/debmake/control.py-if para["desc_long"].rstrip(): /usr/lib/python3/dist-packages/debmake/control.py-desc_long = para["desc_long"].rstrip() /usr/lib/python3/dist-packages/debmake/control.py-elif para["desc"].strip(): /usr/lib/python3/dist-packages/debmake/control.py-desc_long = " " + para["desc"].strip() -- /usr/lib/python3/dist-packages/debmake/para.py:help="pedantically check auto-generated files", /usr/lib/python3/dist-packages/debmake/para.py-) /usr/lib/python3/dist-packages/debmake/para.py-p.add_argument( /usr/lib/python3/dist-packages/debmake/para.py-"-T", /usr/lib/python3/dist-packages/debmake/para.py-"--tutorial", /usr/lib/python3/dist-packages/debmake/para.py-action="store_true", -- /usr/share/debmake/extra0desc_long/_long: This Debian binary package was auto-generated by the /usr/share/debmake/extra0desc_long/_long- debmake(1) command provided by the debmake package. -- /usr/share/debmake/extra0desc_long/_long_tutorial: This Debian binary package was auto-generated by the /usr/share/debmake/extra0desc_long/_long_tutorial- debmake(1) command provided by the debmake package. /usr/share/debmake/extra0desc_long/_long_tutorial- . /usr/share/debmake/extra0desc_long/_long_tutorial- = This comes from the unmodified template file = /usr/share/debmake/extra0desc_long/_long_tutorial- . /usr/share/debmake/extra0desc_long/_long_tutorial- Please edit this template file (debian/control) and other package files -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1025355: lintian: check for non-breaking-space chars in name part of Maintainer/Uploaders fields
Package: lintian
Severity: wishlist
The name part of the Maintainer field for the emacs-cmake-mode package
currently contains non-breaking-space characters instead of spaces.
This has been reported against emacs-cmake-mode as bug report #1025354.
This is unlikely to break any Debian package infrastructure, but it
does mean that naive validation of the Maintainer field will error,
for example the DDPO cron job Maintainer check regex uses spaces
and generates a warning mail when the regex does not match.
The Maintainer field and each item of the Uploaders field should be
checked in both source and binary Debian packages.
Please add a check to prevent this from happening in future.
$ apt-cache showsrc emacs-cmake-mode | sed -n 's/Maintainer: //p' | sort -u
| tee /dev/stderr | tr -d -- '-@<>.a-zA-Z ' | xargs -d '\n' unicode --brief
Debian Emacsen team
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
$ apt-cache show elpa-cmake-mode | sed -n 's/Maintainer: //p' | sort -u |
tee /dev/stderr | tr -d -- '-@<>.a-zA-Z ' | xargs -d '\n' unicode --brief
Debian Emacsen team
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
U+00A0 NO-BREAK SPACE
$ /srv/qa.debian.org/data/cronjobs/ddpo
/srv/qa.debian.org/ftp/debian/dists/unstable/main/source/Sources.xz:0:
syntax error in emacs-cmake-mode Maintainer: Debian Emacsen team
at ../extract_archive.pl line 101.
/srv/qa.debian.org/ftp/debian/dists/testing/main/source/Sources.xz:0: syntax
error in emacs-cmake-mode Maintainer: Debian Emacsen team
at ../extract_archive.pl line 101.
$ grep warn.*error /srv/qa.debian.org/data/ddpo/extract_archive.pl
$pkgdata{$package}->{maintainer} =~ /(.+) <(.+)>/ or warn
"$fname:$.: syntax error in $package Maintainer:
$pkgdata{$package}->{maintainer}";
$uploader =~ /(.+) <(.+)>/ or warn "$fname:$.:
syntax error in $package Uploaders: $uploader";
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Re: lintian: add classification tags for packages that need porting to different architectures?
On Tue, 2022-11-08 at 00:50 +, Thorsten Glaser wrote: > What’s the use? (In the good sense, a pure question out of interest.) I was mainly thinking of this because of the recent influx of porters that are relatively new to Debian, for the new ports riscv64, arc and loong64. They are the reason PortTemplate and PortsDocs/New were created, to streamline the experience and process for new porter folks. The lintian tags could in theory also help with that. > Perhaps something like repro-builds have, a repository with notes > on individual packages, where people who once investigated one thing > could note this down, and which interested porters would use as the > main entry point *instead of* the raw lintian stats, would be useful? > > You could then mechanically create files in that repo for packages > which show up in lintian but don’t have such notes yet, to signal > that they show up. I like this idea a lot; build and autopkgtest every package on every port ignoring the Architecture fields and publish the status/logs for porters/maintainers to look at and provide notes etc on. There will still be some porting scenarios this will not catch though, like when debian/rules skips tests, JITs and where the arch defines are used, so lintian and other tools can feed back into the porting notes docs. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
lintian: add classification tags for packages that need porting to different architectures?
Hi all, I had the idea to add a series of lintian classification tags that will assist porters in finding packages that need fixes for their port. The current set of ideas for these tags include: * list arches that don't match Architecture in debian/control * list arches that don't match Architecture in debian/tests/control * list arches where debian/rules checks DEB_HOST_ARCH * list arches where debian/rules mentions the arch name at all * list arches where C source code references other per-arch defines but does not mention the defines for the current arch One important thing for these tags is that they be possible to query on a per-architecture basis, so that porters who care only about specific architectures can find packages that need porting to those arches. Currently UDD doesn't allow this but it should be easy to add. While some of the potential tags are possible to implement manually just using local grep-dctrl | dpkg-architecture commands, it would be useful for some teams, especially those new to Debian, to be able to just link to a precomputed list of packages for each architecture. Also some of the above ideas for these types of classification tags won't be possible to easily implement manually without a local mirror. The Debian ports infra, sysadmin, archive admin and release teams may also want to use the computed stats for determining the eligibility of individual ports for the different architecture support levels. Once these tags are created, I'll link to them from these pages: https://wiki.debian.org/PortsDocs/New#Other_work https://wiki.debian.org/PortTemplate Any thoughts? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1019980: lintian: source-is-missing check for HTML is much too sensitive
On Sun, 18 Sep 2022 00:14:07 +0100 Colin Watson wrote: > This is pretty oversensitive. Firstly, it's HTML, which is still often > enough written by hand anyway. As it happens, these particular HTML > files are generated from halibut input that's also provided in the > source package, though I can't see how Lintian could possibly expect to > know that. I am not a lintian maintainer, but: HTML is very often generated and there are many different ways to generate it. I think the right thing for lintian to do here is to know about more of the source formats and when there is generated HTML in the tarball but source is also present, then emit a new lower severity generated-files tag instead of the existing source-is-missing tag. I think the right thing for putty here is for upstream to remove the HTML from their VCS and tarballs, then add the generation process to their build system and continuous integration, so that they always know when there are problems with generating the HTML. If they refuse then you could exclude the HTML from Debian's copy of the upstream tarball. Until either lintian changes or the putty HTML gets removed, overriding the lintian warning in putty seems the correct thing to do. PS: I note that manual pages are similar to HTML in this regard and I think the same reasoning above applies to the putty manual pages and to lintian's treatment of manual pages in source packages. > I suggest restoring something like this code to check for
Bug#1017081: lintian: warn about paths in /usr/share/applications/ not named *.desktop or *-mimeapps.list
Package: lintian Version: 2.115.2 Severity: wishlist There are a couple of packages shipping files in the directory /usr/share/applications/ that are not applications or MIME lists. $ apt-file search /usr/share/applications/ | grep -vE ': /usr/share/applications/[^/]+(\.desktop|-mimeapps\.list)$' fte-xwindow: /usr/share/applications/fte32x32.xpm spread-phy: /usr/share/applications/desktop The icon should be in /usr/share/pixmaps/ or /usr/share/icons/ dirs, since its filename and contents both indicate it is an image. The desktop file should be renamed to spread-phy.desktop or similar, since its file contents indicate it is actually a .desktop file. Please add a warning to lintian suggesting that these files be moved elsewhere or renamed. Probably lintian should detect the type of file and suggest the correct location for it to be moved or renamed to. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1015297: lintian: add ftp-master reject to Debian profile for packages with XB-Popcon-Reports: no fields
Package: lintian Version: 2.115.2 Severity: wishlist X-Debbugs-Cc: debian-pop...@lists.debian.org, ftpmas...@debian.org In #681721 the popularity-contest maintainers added the ability for packages with XB-Popcon-Reports: no to skip being mentioned in the reports sent by popularity-contest to Debian. This field is meant for private packages only available outside of Debian and so it should not be used for any packages within Debian. Please add a lintian ftp-master reject to the Debian profile for packages with XB-Popcon-Reports: no. Probably the same should be added for Ubuntu too, not sure though. https://bugs.debian.org/681721 -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.38.50.20220707-1 ii bzip2 1.0.8-5 ii diffstat1.64-1 ii dpkg1.21.9 ii dpkg-dev1.21.9 ii file1:5.41-4 ii gettext 0.21-6 ii gpg 2.2.35-3 ii intltool-debian 0.35.0+20060710.5 ii iso-codes 4.10.0-1 ii libapt-pkg-perl 0.1.40+b1 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-1+b2 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b8 ii libclone-perl 0.45-1+b2 ii libconfig-tiny-perl 2.28-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.30-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-1+b3 pn libdigest-sha-perl ii libdpkg-perl1.21.9 ii libemail-address-xs-perl1.04-1+b4 ii libencode-perl 3.18-1 ii libfile-basedir-perl0.09-1 ii libfile-find-rule-perl 0.34-2 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-2 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-someutils-perl 0.58-1 ii liblist-utilsby-perl0.12-1 ii libmldbm-perl 2.05-3 ii libmoo-perl 2.005004-3 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.122-1 ii libperlio-gzip-perl 0.20-1 ii libperlio-utf8-strict-perl 0.009-1+b1 ii libproc-processtable-perl 0.634-1+b1 ii libregexp-wildcards-perl1.05-2 ii libsereal-decoder-perl 4.023+ds-1 ii libsereal-encoder-perl 4.023+ds-1 ii libsort-versions-perl 1.62-2 ii libsyntax-keyword-try-perl 0.27-1 ii libterm-readkey-perl2.38-1+b3 ii libtext-levenshteinxs-perl 0.03-5 ii libtext-markdown-discount-perl 0.13-1+b1 ii libtext-xslate-perl 3.5.9-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b4 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-1+b3 ii liburi-perl 5.12-1 ii libwww-mechanize-perl 2.10-1 ii libwww-perl 6.67-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1 ii libyaml-libyaml-perl0.83+ds-1+b1 ii lzip [lzip-decompressor]1.23-3 ii lzop1.04-2 ii man-db 2.10.2-1 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.34.0-5 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2.1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.38.50.20220707-1 ii libtext-template-perl 1.61-1 -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
[Git][lintian/lintian][master] Add more obsolete domains for former source code hosting services
Paul Wise pushed to branch master at lintian / lintian Commits: 44e902f3 by Paul Wise at 2022-06-19T07:31:16+08:00 Add more obsolete domains for former source code hosting services Found-in: duck:config/obsolete.list Found-on: https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities#Former_hosting_facilities - - - - - 1 changed file: - data/obsolete-sites/obsolete-sites Changes: = data/obsolete-sites/obsolete-sites = @@ -3,15 +3,21 @@ # # Please keep the file sorted alphabetically. +alioth.debian.org +anonscm.debian.org berlios.de +betavine.net code.google.com codehaus.org codeplex.com fedorahosted.org freecode.com freshmeat.net +git.debian.org gitorious.org +gna.org googlecode.com search.cpan.org sourceforge.jp tigris.org +titanpad.com View it on GitLab: https://salsa.debian.org/lintian/lintian/-/commit/44e902f3cadeb0f3f886ff2a6d3da6dcedc2a77d -- View it on GitLab: https://salsa.debian.org/lintian/lintian/-/commit/44e902f3cadeb0f3f886ff2a6d3da6dcedc2a77d You're receiving this email because of your account on salsa.debian.org.
Bug#1012289: O: lintian -- Debian package checker
Package: wnpp Severity: normal X-Debbugs-Cc: debian-de...@lists.debian.org, debian-lint-maint@lists.debian.org Control: affects -1 src:lintian The lintian package is now orphaned as both of the people who were actively working on lintian have stopped that work: https://lists.debian.org/msgid-search/5e4d0e28-a3f4-4302-8364-5afd93d8a...@www.fastmail.com https://lists.debian.org/msgid-search/cafhyt550_6hc-2srjqyv0z9kgpwulpgnnxvoonpohp3r+pa...@mail.gmail.com Please join the lintian group/project on salsa if you want to help maintain the lintian codebase; add tests, update for new policy etc. https://salsa.debian.org/lintian/lintian The package description is: Lintian dissects Debian packages and reports bugs and policy violations. It contains automated checks for many aspects of Debian policy as well as some checks for common errors. . This package is useful for all people who want to check Debian packages for compliance with Debian policy. Every Debian maintainer should check packages with this tool before uploading them to the archive. . This version of Lintian is calibrated for Debian Policy version 4.6.0.1. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1012172: lintian: warn about manual pages using \[en] (the en-dash – character) instead of double dashes -- prefixes
Package: lintian Version: 2.114.0 Severity: wishlist The yt-dlp manual page contains – characters (en-dash) (the \[en] sequence in the manual page source) instead of double dashes, consequently double-click in the terminal doesn't select the dash character so you can't copy the full option and if you do copy the en-dash character, it won't work when passed to yt-dlp, because it requires double-dashes instead of en-dashes for long options. https://github.com/yt-dlp/yt-dlp/issues/3814 This sort of issue does happen occasionally and is annoying to users, so it would be great if lintian could warn about the manual pages. It is potentially feasible for programs to use en-dashes for long options but is almost never done, so overrides seem like the appropriate way to deal with false positives. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1006859: lintian: warn about devhelp version 1 files
Package: lintian
Version: 2.114.0
Severity: wishlist
Please complain about files that are devhelp version 1 files, since
that version is deprecated and devhelp suggests that support for it
will be removed at some point.
$ devhelp
(devhelp:2215391): devhelp-WARNING **: 21:28:24.414: The file
'file:///usr/share/devhelp/books/python3.9/python3.9.devhelp.gz'
uses the Devhelp index file format version 1, which is deprecated. A
future version of Devhelp may remove the support for the format
version 1. The index file should be ported to the Devhelp index file
format version 2.
Reading the code, it appears the file name simply encodes the format
version, *.devhelp and *.devhelp.gz are version 1, while *.devhelp2 and
*.devhelp2.gz are version two.
So lintian needs to complain about files in these paths, but often the
subdirectory of the books directory is instead a symlink to elsewhere,
so lintian should *safely* follow any symlinks in the books directory:
/usr/share/devhelp/books/*/*.devhelp
/usr/share/devhelp/books/*/*.devhelp.gz
Here are the relevant parts of the code:
typedef enum {
FORMAT_VERSION_1,
/* The main change is that version 2 uses instead of
* .
*/
FORMAT_VERSION_2
} FormatVersion;
typedef struct {
...
FormatVersion version;
...
} DhParser;
...
gboolean
_dh_parser_read_file (GFile *index_file,
gchar **book_title,
gchar **book_id,
gchar **book_language,
GNode **book_tree,
GList **all_links,
GError **error)
{
DhParser *parser;
...
parser = g_new0 (DhParser, 1);
index_file_uri = g_file_get_uri (index_file);
if (g_str_has_suffix (index_file_uri, ".devhelp2")) {
parser->version = FORMAT_VERSION_2;
gz = FALSE;
} else if (g_str_has_suffix (index_file_uri, ".devhelp")) {
parser->version = FORMAT_VERSION_1;
gz = FALSE;
} else if (g_str_has_suffix (index_file_uri, ".devhelp2.gz")) {
parser->version = FORMAT_VERSION_2;
gz = TRUE;
} else {
parser->version = FORMAT_VERSION_1;
gz = TRUE;
}
...
/* At this point we know that the file exists, the
G_IO_ERROR_NOT_FOUND
* has been catched earlier. So print warning.
*/
if (parser->version == FORMAT_VERSION_1)
g_warning ("The file '%s' uses the Devhelp index file format
version 1, "
"which is deprecated. A future version of Devhelp
may remove "
"the support for the format version 1. The index
file should "
"be ported to the Devhelp index file format
version 2.",
index_file_uri);
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lintian depends on:
ii binutils2.38-2
ii bzip2 1.0.8-5
ii diffstat1.64-1
ii dpkg1.21.1
ii dpkg-dev1.21.1
ii file1:5.41-2
ii gettext 0.21-4
ii gpg 2.2.27-3
ii intltool-debian 0.35.0+20060710.5
ii libapt-pkg-perl 0.1.40+b1
ii libarchive-zip-perl 1.68-1
ii libcapture-tiny-perl0.48-1
ii libclass-xsaccessor-perl1.19-3+b8
ii libclone-perl 0.45-1+b2
ii libconfig-tiny-perl 2.28-1
ii libconst-fast-perl 0.014-1.1
ii libcpanel-json-xs-perl 4.27-1+b1
ii libdata-dpath-perl 0.58-1
ii libdata-validate-domain-perl0.10-1.1
ii libdata-validate-uri-perl 0.07-2
ii libdevel-size-perl 0.83-1+b3
pn libdigest-sha-perl
ii libdpkg-perl1.21.1
ii libemail-address-xs-perl1.04-1+b4
ii libencode-perl 3.16-1+b1
ii libfile-basedir-perl0.09-1
ii libfile-find-rule-perl 0.34-1
ii
Bug#1004536: lintian: suggest Testsuite: autopkgtest-pkg-* when autodep8 detects it should be added
On Sun, 2022-01-30 at 20:40 +0100, Paul Gevers wrote: > But this is only useful if the test actually passes. We don't want > people to add the field if the test is broken. So if this is > implemented, make sure the priority/certainty/whatever is low enough > that people will *not* just blindly do this. Presumably when adding the tests, people will either run them on their own systems or wait until debci runs them, then review the results and fix any issues they see. The tag long description could suggest that. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1004536: lintian: suggest Testsuite: autopkgtest-pkg-* when autodep8 detects it should be added
Package: lintian Severity: wishlist Usertags: feature X-Debbugs-CC: autod...@packages.debian.org I noticed while packaging some Python modules recently that they were not tested by debci. This is because debci only tests source packages that contain a Testsuite field. The autodep8 tool is able to generate the needed tests, but debci only runs it when the Testsuite field is present and contains an autopkgtest-pkg-* value. The autodep8 tool also contains heuristics to detect packages that could have autopkgtests but right now there is nothing suggesting to maintainers that they should add tests based on autodep8. I suggest that when the Testsuite field is missing, lintian run autodep8 from the unpacked source package dir and when autodep8 prints a test stanza on stdout, emit a tag suggesting that the maintainer add the Testsuite field. If the Testsuite is already present, presumably the maintainer already added some tests that are better than the autodep8 ones. Since autodep8 also prints warnings/errors on stderr, lintian could also emit tags there too. Here is an example of an affected package: $ debsnap python-circuitbreaker 1.3.2-1 $ chronic dpkg-source -x python-circuitbreaker_1.3.2-1.dsc $ cd python-circuitbreaker*/ $ grep Testsuite debian/control $ find debian/tests find: ‘debian/tests’: No such file or directory python-circuitbreaker-1.3.2 $ autodep8 Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import circuitbreaker; print(circuitbreaker)" ; done Depends: python3-all, python3-circuitbreaker, Restrictions: allow-stderr, superficial, Features: test-name=autodep8-python3 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#999497: lintian: complain about packages with parts of npm2deb FIX_ME or templates still present
Package: lintian Version: 2.111.0 Severity: wishlist X-Debbugs-CC: npm2...@packages.debian.org npm2deb converts node/npm packages to Debian source packages, in the process it leaves FIX_ME items and template info in various places in the Debian source package for the maintainer to clean up before upload. Sometimes these FIX_ME items even get past the NEW queue (for example node-winston). I looked at the npm2deb source code and found several strings that need to be checked for. There may be some more strings that I missed though. Note that the description_template string could contain an upstream_description string, so you will need to check for the prefix and suffix instead of the whole string. PS: I wonder if there should be a standard prefix for all template strings that all packaging tools could use in their templates or template strings and then lintian could just check for that prefix. https://wiki.debian.org/AutomaticPackagingTools npm2deb/__init__.py: self.debian_license = "FIX_ME debian license" self.debian_author = 'FIX_ME debian author' args['Description'] = 'FIX_ME write the Debian package description' self.upstream_license = "FIX_ME upstream license" self.upstream_version = 'FIX_ME version' self.upstream_description = 'FIX_ME no upstream package description' result = 'FIX_ME upstream author' result = 'FIX_ME repo url' npm2deb/templates.py: description_template = """ Write the short and long descriptions for the Debian package as explained in the Developer's Reference, §6.2.1 – §6.2.3. . You can start with the short upstream package description, “%(upstream_description)s”. . Be aware that most upstream package descriptions are not written to conform with Debian package guidelines. You need to explain the role of this package for a Debian audience. . Node.js is an event-based server-side JavaScript engine. """ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#995606: lintian: non-free font packages and {truetype,opentype}-font-prohibits-installable-embedding
On Sat, 2021-10-02 at 22:15 -0700, Felix Lechner wrote: > I too would like to see variable visibilities, but we do not currently > offer them. The traditional solution has been to introduce new tags. Splitting the tag up would also allow having different advice for packages in main vs non-free, which I guess is not an option for a single tag either, so splitting them is probably a good idea anyway. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#995606: lintian: non-free font packages and {truetype,opentype}-font-prohibits-installable-embedding
Package: lintian Severity: wishlist For non-free fonts, prohibiting embedding is often consistent with the license, so the two lintian warnings often don't really apply. On the other hand prohibiting embedding is particularly user hostile so Debian should probably try to discourage it. On balance I think the right solution is to downgrade the embedding tags to either info or pedantic for non-free packages. The openboard-extras-nonfree package is already overriding this tag, probably due to the warning vs pedantic level. truetype-font-prohibits-installable-embedding opentype-font-prohibits-installable-embedding -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#994139: lintian: warning about superficial autopkgtests is counterproductive
On Wed, 2021-09-29 at 18:59 -0700, Felix Lechner wrote: > Would you be willing to revert your commit that bumped the visibility > [1] until we can figure out a better way to proceed? Reverted. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#994139: lintian: warning about superficial autopkgtests is counterproductive
On Sun, 2021-09-12 at 23:27 +0100, Simon McVittie wrote: > I don't think it makes sense for the new superficial-tests to be considered > worse (= higher severity) than the old testsuite-autopkgtest-missing. I was initially thinking of cases were the package is perfectly possible to test properly but the maintainer just added a foo -v superficial test instead of adding a real test. I hadn't considered packages that aren't possible to test, for those I guess I assumed maintainers would just not add any tests. If the amount of packages with superficial tests that aren't possible to properly test is higher than the amount of packages that are possible to properly test, then your reasoning makes sense and the severities should be changed. From the examples you presented, I think that is correct so I agree the severities should be changed indeed. I do feel however that the value of superficial tests is usually quite minimal and so I would suggest to use the same severity for zero tests as for only superficial tests. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#743694: lintian: Downgrade most of privacy-breach* tags from severity: error to pedantic
I think that the privacy breaches that lintian complains about represent several sets of bugs that all need fixing: The browsers shipping in Debian place no barriers between local files on disk, sites on the local network and sites on the Internet. So if someone reads some local documentation they didn't get from Debian using a browser from Debian, they could have a privacy violation. The documentation available in Debian may suggest readers request resources not available as local files on disk. Even if we fix the browsers available in Debian, users may read Debian documentation using browsers not available in Debian, they could have a privacy violation. When Debian documentation is copied to the web the same occurs. The web applications available in Debian may suggest visitors request resources not available on the same web service. Since most web browsers don't block third-party requests by default, those visitors, who are only indirectly Debian users, could have a privacy violation. The same applies when Debian documentation is copied to a website. Daniel Leidert wrote: > To put packages through NEW they have to be lintian clean. Not in my experience, I haven't tested it for the privacy tags though. > The severity is not backed up by any of our policies. I believe the issues to be a violation of the social contract, albeit one of the parts that are aspirational rather than concrete. > what right do we have to remove donation requests That would be the wrong thing to do but that isn't what is requested. > you have already configured your whole system The majority people who are affected by privacy violations probably don't understand that those violations exist, nor that mitigations exist nor what those mitigations are nor how to configure them and probably those mitigations are going to break their workflows. > they are still tracked by hundreds of cookies > while browsing websites or reading mails This is being improved by the browser vendors, which are moving towards blocking third-party cookies entirely. > It just creates burden on fellow developers. I believe that the burden exists, but is fairly minimal, replacing an image with a styled button or similar is usually fairly simple. PS: there are many more types of privacy violations in Debian: https://wiki.debian.org/PrivacyIssues -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#993921: lintian-brush: lintian data files were renamed, breaking two fixers that use the filenames
Package: lintian-brush Version: 0.110 Severity: important Usertags: crash X-Debbugs-CC: lint...@packages.debian.org File: /usr/share/lintian-brush/fixers/missing-build-dependency-for-dh_-command.py File: /usr/share/lintian-brush/fixers/field-name-typo-in-tests-control.py The upgrade to lintian 2.105.0 moved files, causing two crashes: Script /usr/share/lintian-brush/fixers/field-name-typo-in-tests-control.py failed with exit code: 1 Traceback (most recent call last): File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 415, in run exec(code, global_vars) File "/usr/share/lintian-brush/fixers/field-name-typo-in-tests-control.py", line 16, in valid_field_names = set(known_tests_control_fields(vendor())) File "/usr/lib/python3/dist-packages/lintian_brush/lintian.py", line 94, in known_tests_control_fields return _read_test_fields(KNOWN_TESTS_CONTROL_FIELDS_PATH, vendor) File "/usr/lib/python3/dist-packages/lintian_brush/lintian.py", line 84, in _read_test_fields with open(path, 'r') as f: FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/lintian/data/testsuite/known-fields' Script /usr/share/lintian-brush/fixers/missing-build-dependency-for-dh_-command.py failed with exit code: 1 Traceback (most recent call last): File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 415, in run exec(code, global_vars) File "/usr/share/lintian-brush/fixers/missing-build-dependency-for-dh_-command.py", line 39, in with open(path, 'r') as f: FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/lintian/data/debhelper/dh_addons-manual' -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.21.4 ii python3 3.9.2-3 ii python3-breezy 3.2.1-1 ii python3-debian 0.1.39 ii python3-debmutate0.36 ii python3-distro-info 1.0 ii python3-dulwich 0.20.23-1 ii python3-iniparse 0.4-3 ii python3-ruamel.yaml 0.16.12-2 ii python3-upstream-ontologist 0.1.22-1 Versions of packages lintian-brush recommends: ii decopy 0.2.4.4-0.1 ii dos2unix 7.4.1-1 ii gpg 2.2.27-2 ii libdebhelper-perl13.5.1 ii lintian 2.105.0 ii ognibuild0.0.9-1 ii python3-asyncpg 0.24.0-1 ii python3-bs4 4.9.3-1 ii python3-docutils 0.16+dfsg-4 ii python3-levenshtein 0.12.2-1 ii python3-lxml 4.6.3+dfsg-0.1 ii python3-markdown 3.3.4-1 ii python3-pyinotify0.9.6-1.3 pn python3-tomlkit Versions of packages lintian-brush suggests: pn breezy-debian ii gnome-pkg-tools0.22.3 ii po-debconf 1.0.21+nmu1 pn postgresql-common -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#981935: lintian: warn about packages using Rubygems pages in the Homepage field
Package: lintian Version: 2.104.0 Severity: wishlist Please warn about packages using Rubygems pages in the Homepage field. Rubygems is a packaging system just as Debian is a packaging system and each Rubygems package has a Homepage link that points at the upstream homepage. Debian packages should point at the upstream homepage rather than the page for other packaging systems like Rubygems. There are several forms of Homepages that are used, both are URLs like this, with/without the trailing slash and with/without https: https://rubygems.org/gems// This URL is a false positive and is the correct Homepage for the Debian rubygems package manager itself. https://rubygems.org/ According to the Debian Code Search service 21 packages are affected: https://codesearch.debian.net/search?literal=0=path%3Adebian%2Fcontrol+Homepage%3A.%2Arubygem=0 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#981932: lintian: warn about packages using PyPI pages in the Homepage field
Package: lintian Version: 2.104.0 Severity: wishlist Please warn about packages using PyPI pages in the Homepage field. PyPI is a packaging system just as Debian is a packaging system and each PyPI package has a Homepage link that points at the upstream homepage. Debian packages should point at the upstream homepage rather than the page for other packaging systems like PyPI. There are two forms of Homepages that are used, the first of these is the current one, and the second one is the old one and it redirects to the current one. https://pypi.org/project// https://pypi.python.org/pypi// According to the Debian Code Search service 100 packages are affected: https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+Homepage%3A.*pypi=0 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#980987: lintian: check for duplicates in debian/py3dist-overrides
Package: lintian Version: 2.104.0 Severity: wishlist dh_python3 has an override mechanism (debian/py3dist-overrides) that lets you specify different dependencies for particular Python imports. debian/py3dist-overrides is mainly used for Python programs that use GObject introspection, since dh_python3 cannot yet detect that the packages gir1.2-*-* map to Python imports, so overrides are needed. When the same import appears twice in the file, the dependency from the first one is used and the dependency from the second one is discarded, which can lead to missing dependencies if the maintainer didn't notice. An example of a second dependency that gets ignored: gi.repository.Gst gir1.2-gst-plugins-base-1.0 gi.repository.Gst gir1.2-gstreamer-1.0 An example of a double dependency that gets kept: gi.repository.Gst gir1.2-gst-plugins-base-1.0, gir1.2-gstreamer-1.0 Please mark this check as error severity. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#980447: lintian: complain about systemd units with Documentation fields that are not valid
Package: lintian Version: 2.104.0 Severity: wishlist According to the systemd documentation, the Documentation field of systemd units must be a URI of a specific set of types: $ man systemd.unit | grep -A7 Documentation Documentation= A space-separated list of URIs referencing documentation for this unit or its configuration. Accepted are only URIs of the types "http://;, "https://;, "file:", "info:", "man:". For more information about the syntax of these URIs, see uri(7). The URIs should be listed in order of relevance, starting with the most relevant. It is a good idea to first reference documentation that explains what the unit's purpose is, followed by how it is configured, followed by any other related documentation. This option may be specified more than once, in which case the specified list of URIs is merged. If the empty string is assigned to this option, the list is reset and all prior assignments will have no effect. Currently there is only one package that I can see violating this (bug filed), but it is possible that other packages might in the future. https://codesearch.debian.net/search?q=Documentation%3D%2F=0 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#978048: lintian: KillMode=none unsafe in systemd service files
Package: lintian Version: 2.104.0 Severity: wishlist systemd complains about KillMode=none in systemd service files, I think lintian should also warn about this so that packages in Debian are more likely to get fixed before the eventual removal of this feature. Dec 25 11:58:55 systemd[1]: /lib/systemd/system/plymouth-start.service:16: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35.1-5 ii bzip2 1.0.8-4 ii diffstat1.63-1 ii dpkg1.20.5 ii dpkg-dev1.20.5 ii file1:5.39-3 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b4 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b6 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl1.20.5 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1 ii libhtml-html5-entities-perl 0.004-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.430-2 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.114-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-1 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012000-1 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.05-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip1.21-8 ii lzop1.04-2 ii man-db 2.9.3-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.0-6 ii t1utils 1.41-4 ii unzip 6.0-25 ii xz-utils5.2.4-1+b1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.35.1-5 ii libtext-template-perl 1.59-1 Versions of other relevant packages: ii systemd 247.1-3+deb11u1 -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#976363: lintian: detect debmake template comments
Package: lintian Version: 2.104.0 Severity: wishlist The debmake package is an alternative to dh_make. The debmake package contains a number of packaging templates in the /usr/share/debmake/ directory that debmake uses when generating initial packaging, which folks then customise for their use. There are a number of packages where the maintainer hasn't bothered to remove unnecessary comments that the comments in the debmake templates themselves also suggest removing. https://codesearch.debian.net/search?q=You+must+remove+unused+comment+lines+for+the+released+package.=1 I think it would be good if lintian could detect situations where comments from the debmake templates have not been removed. I think the best way to implement this would be for lintian to grow a script that is run at lintian release time and gathers all the comments from the debmake templates into a set of files containing comments that should be removed, filters out some that are reasonable to keep (such as #export DH_VERBOSE=1) and then stores those in the lintian git repository, separated out into the types of files each comment occurs in. Then the lintian check for this issue can detect all of the unnecessary debmake comments. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#932870: marked as pending in lintian
On Tue, 2020-12-01 at 17:55 -0800, Felix Lechner wrote: > Which part, please? For the level, 'warning' is too high for a > peripheral matter like tests, which are optional. From my previous mail: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932870#17 In addition I think this superficial-only-tests tag should be of a different severity to testsuite-autopkgtest-missing, perhaps raised to info or warning level instead of pedantic. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#932870: marked as pending in lintian
On Tue, 2020-12-01 at 22:15 +, Felix Lechner wrote: > The new tag resembles, pursuant to the filers request, the existing > tag testsuite-autopkgtest-missing (which has since been renamed) to > the extent that it is likewise issued with an 'info' visibility. This seems to miss part of my request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932870#17 In addition I think this superficial-only-tests tag should be of a different severity to testsuite-autopkgtest-missing, perhaps raised to info or warning level instead of pedantic. The missing testsuite tag is now at info level, so the superficial tests tag should be raised to warning level. I'll commit a fix. $ grep -hrC20 testsuite-autopkgtest-missing /usr/share/lintian Tag: missing-tests-control Severity: info Check: testsuite Renamed-From: testsuite-autopkgtest-missing Explanation: The source package declares the generic Testsuite: autopkgtest field but provides no debian/tests/control file. . The control file is not needed when a specialized test suite such as autopkgtest-pkg-perl is being used. See-Also: https://salsa.debian.org/ci-team/autopkgtest/tree/master/doc/README.package-tests.rst -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#975690: lintian: detect invalid Uploaders fields that are missing separating commas
Package: lintian Version: 2.103.0 Severity: wishlist The yubico-piv-tool package recently introduced an invalid Uploaders fields that is missing a single comma in the middle of the list. $ apt-cache showsrc yubico-piv-tool | grep -E '^$|^Version|^Uploaders' Version: 2.0.0-2 Uploaders: nicoo , Alessio Di Mauro , Klas Lindfors , Dain Nilsson Version: 2.1.1-1 Uploaders: Alessio Di Mauro , Dain Nilsson Klas Lindfors , nicoo , Version: 2.1.1-2 Uploaders: Alessio Di Mauro , Dain Nilsson Klas Lindfors , nicoo , ^ This is a violation of Debian Policy 5.6.3: https://www.debian.org/doc/debian-policy/ch-controlfields.html#uploaders List of the names and email addresses of co-maintainers of the package, if any. The format of each entry is the same as that of the Maintainer field, and multiple entries *must be comma separated*. Please detect this and emit an error about it, probably it should also get onto the ftp-master lintian reject list. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.35.1-2 ii bzip2 1.0.8-4 ii diffstat 1.63-1 ii dpkg 1.20.5 ii dpkg-dev 1.20.5 ii file 1:5.38-5 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b4 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl 0.48-1 ii libclass-xsaccessor-perl 1.19-3+b6 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl 0.10-1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl 1.20.5 ii libemail-address-xs-perl 1.04-1+b3 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl 1.06-1 ii libhtml-html5-entities-perl 0.004-1 ii libipc-run3-perl 0.048-2 ii libjson-maybexs-perl 1.004003-1 ii liblist-compare-perl 0.55-1 ii liblist-moreutils-perl 0.416-1+b6 ii liblist-utilsby-perl 0.11-1 ii libmoo-perl 2.004000-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.114-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl 2.3300-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl 1.012000-1 ii libunicode-utf8-perl 0.62-1+b2 ii liburi-perl 5.05-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl 0.82+repack-1+b1 ii lzip 1.21-8 ii lzop 1.04-2 ii man-db 2.9.3-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.0-5 ii t1utils 1.41-4 ii unzip 6.0-25 ii xz-utils 5.2.4-1+b1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.35.1-2 ii libtext-template-perl 1.59-1 -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#973333: lintian.d.o: please add a symlink/redirect to the most recent version
Package: lintian Severity: wishlist When clicking through to lintian.d.o from tracker.d.o and other places, there is an extra click from the source package page to the source package version page containing the actual lintian results. https://tracker.debian.org/pkg/iotop -> https://lintian.debian.org/sources/iotop.html -> https://lintian.debian.org/sources/iotop/0.6-24-g733f3f8-1.1.html Since most folks would only be interested in the lintian results for the latest version in unstable, it would be nice if the middle click could be eliminated using a symlink or redirect. An "all versions" link could be added for folks who are interested in that. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#966644: lintian: detect mismatches between symbols files and changelog versions
Package: lintian Severity: wishlist In #966409 I detected that libjpeg-turbo added symbols without including the epoch in the symbols version numbers. It would be great if lintian could detect when a version number in the symbols files does not match one of the upstream or Debian versions in the Debian changelog files. Versions older than the oldest version in the Debian changelog file can be ignored of course. I'd suggest structuring this as two complaints with two severities: * At error level, probably ftp-master rejected, for when a symbols version is just missing the epoch. So a check that any of the versions in the Debian changelog file would match the symbol versions if the epoch were present in the symbols version. * At pedantic level, for when symbols version just doesn't match any of the versions in the Debian changelog file. Maybe later once there is an indication of how many false positives there are, this can then be elevated to warning level. Both of these need to take into account that the versions in the symbols file might be missing the Debian revision or they might have a tilde appended to the Debian revision in order to allow backports. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: libjpeg-turbo: versions in debian/*.symbols files are missing the epochs
Control: clone -1 -2 Control: reassign -2 lintian Control: severity -2 wishlist Control: retitle -2 lintian: detect mismatches between symbols files and changelog versions On Tue, 28 Jul 2020 15:04:08 +0800 Paul Wise wrote: > The versions in the debian/*.symbols files are missing the epochs. This > means that packages using symbols newer than buster will not upgrade > libjpeg62-turbo and libturbojpeg0 when being upgraded to bullseye. It would be great if lintian could detect when a version number in the symbols files does not match one of the upstream or Debian versions in the Debian changelog files. Versions older than the oldest version in the Debian changelog file can be ignored of course. I'd suggest structuring this as two complaints with two severities: * At error level, probably ftp-master rejected, for when a symbols version is just missing the epoch. So a check that any of the versions in the Debian changelog file would match the symbol versions if the epoch were present in the symbols version. * At warning or info level, for when symbols version just doesn't match any of the versions in the Debian changelog file. Both of these need to take into account that the versions in the symbols file might be missing the Debian revision or they might have a tilde appended to the Debian revision in order to allow backports. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Reassigning multiple bugs for shell script analysis from Lintian
On Wed, 2020-07-08 at 21:41 +0100, Samuel Henrique wrote: > > Paul Wise > > It also seems unlikely shellcheck would add a bridge between Haskell > > and Perl of the kind needed to implement custom checks. > > I don't think such a thing is needed, shellcheck already provides > multiple machine-readable output formats, which is the way IDEs > integrate with it. Would you happen to be thinking about some usecase > that is not covered by this? As mentioned in your self reply this wouldn't enable custom checks, but I noticed that morbig's machine-readable output could enable them. > I couldn't find this lintshell project, would you mind to give some > references? It's the first time I'm hearing about it. It is a subset of the CoLiS work Ralf has been working on since 2015: https://www.irif.fr/~treinen/colis/ https://github.com/colis-anr/ https://github.com/colis-anr/lintshell https://debconf19.debconf.org/talks/105-symbolic-execution-of-maintainer-scripts/ https://debconf18.debconf.org/talks/90-mining-debian-maintainer-scripts/ https://debconf16.debconf.org/talks/63/ Ralf: could you link to all the CoLiS talks/presentations you and your team have made from the CoLiS website? > To add to the general discussion, the way I envision this moving > forward is that lintian integrates with linters (by their > machine-readable outputs, just like IDEs) and calls them against the > target files, with the possibility of ignoring checks that we might > agree we don't want. I'd suggest for shellcheck to at least disable the style checks, those are just going to be a lot of noise for many maintainers. > Adding Debian specific checks would depend on a bunch of factors like: > someone contributing directly to the linter tool, upstream accepting > it, and the check per-se making sense to be upstreamed, but most > importantly; providing Debian-specific checks would be a bonus, just > by having plain shellcheck run by default on things like maintscripts > would be a win. It seems unlikely that shellcheck upstream would accept checks that are truly Debian-specific, so I would think a better design would be to add either a plugin system or a machine-readable parse tree output mode to shellcheck. Or just use morbig's existing output. PS: there are a couple of other shell linting tools listed here: https://github.com/collab-qa/check-all-the-things/blob/master/data/sh.ini And also some more are on other lists of linting tools: https://github.com/collab-qa/check-all-the-things/raw/master/doc/TODO PPS: personally I'm not sure lintian is the right place to do generalised application of static/dynamic analysis tools to packages available in Debian. For the lone developer case I mostly like the way the check-all-the-things tool works. I think a centralised service could be based on DACA or Debile, check-all-the-things, maybe other code for more complicated checks, the SARIF interchange format, donated credits on the various cloud services and donated time on hardware owned by individuals and orgs for arch-specific checks. https://wiki.debian.org/qa.debian.org https://github.com/collab-qa/check-all-the-things/issues/4 https://docs.oasis-open.org/sarif/sarif/v2.0/csprd01/sarif-v2.0-csprd01.html -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#963589: lintian: detection error package-contains-timestamped-gzip
On Wed, 24 Jun 2020 15:19:28 +0900 Norbert Preining wrote: > W: texlive-fonts-extra: package-contains-timestamped-gzip > usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Regular-tlf-lgr.tfm > 2105-07-28T02:08:00 > W: texlive-fonts-extra: package-contains-timestamped-gzip > usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Regular-tosf-lgr.tfm > 2105-07-28T02:08:00 > W: texlive-fonts-extra: package-contains-timestamped-gzip > usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Thin-lf-sc-ly1.tfm > 2105-07-28T02:08:00 > W: texlive-fonts-extra: package-contains-timestamped-gzip > usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Thin-osf-sc-ly1.tfm > 2105-07-28T02:08:00 > > No, that is not a gzip file. This looks like a bug in file that gets inherited by lintian: $ file usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans* | grep -i gzip usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Regular-tlf-lgr.tfm: gzip compressed data, reserved method, has CRC, has comment, original size modulo 2^32 2758803456 usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Regular-tosf-lgr.tfm: gzip compressed data, reserved method, has CRC, has comment, original size modulo 2^32 2758803456 usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Thin-lf-sc-ly1.tfm: gzip compressed data, reserved method, has CRC, has comment, original size modulo 2^32 3782868992 usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Thin-osf-sc-ly1.tfm: gzip compressed data, reserved method, has CRC, has comment, original size modulo 2^32 3782868992 $ file --mime-type usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans* | grep -i gzip usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Regular-tlf-lgr.tfm: application/gzip usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Regular-tosf-lgr.tfm: application/gzip usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Thin-lf-sc-ly1.tfm: application/gzip usr/share/texlive/texmf-dist/fonts/tfm/huerta/alegreya/AlegreyaSans-Thin-osf-sc-ly1.tfm: application/gzip Looks like there are a lot of bugs in the .tfm detection in file: $ find usr/share/texlive/texmf-dist/fonts/tfm/ -type f -name '*.tfm' -print0 | xargs -0 file | grep -v 'TeX font metric data' | wc -l 4997 So probably the right solution is for lintian to ignore *.tfm files when searching for gzip files. You may want to talk to file upstream about the *.tfm detection issues. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#962927: lintian: detect when a package will be uploaded with a new maintainer but without any changes
Package: lintian Severity: wishlist Recently I noticed a package enter Debian with a changelog something like below. The only other change to the package was in the Maintainer field in debian/control. Rebuilds that only change the maintainer are a waste of buildd time, mirror sync bandwith and snapshot.d.o disk space and should be discouraged. It would be nice if lintian could detect these sort of uploads and have them rejected. Probably the check should work by matching the latest Debian changelog entry against the template below, allowing for inclusion or not of the bug closing and allowing for varying source package name, version, suite (unstable & experimental), uploader and date. something (1.2.3-4) unstable; urgency=medium * New maintainer. (Closes: #123456) -- Some One Sat, 16 Jun 2020 11:51:11 +0800 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Reassigning multiple bugs for shell script analysis from Lintian
On Mon, 2020-06-15 at 12:30 -0700, Felix Lechner wrote: > Over the years, Lintian accumulated many requests for features better > addressed by a shell script analyzer. If there are no objections, I > plan to assign them a copy each to morbig and shellcheck. Some caveats that make this not as feasible as you might think: morbig is in OCaml and shellcheck is in Haskell, which means that there are fewer people available to work on these tools. It seems likely that some of the features requested are Debian-specific so shellcheck is unlikely to implement them. It also seems unlikely shellcheck would add a bridge between Haskell and Perl of the kind needed to implement custom checks. I'm not sure of the development status of morbig, does it still have funding Ralf? It seems development has stopped since last year. lintshell is just a prototype, it has very few checks. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
the safety of commands run by lintian
Hi all, I discussed the safety of `dash -n` and `bash -n` with Jakub Wilk. These are used by lintian to check for bashisms. We concluded that it was possibly unsafe to use the -n option with arbitrary scripts. TBH I expect that other tools (such as binutils, see the thread below) run by lintian are similarly unsafe and I wonder if the ftp-master profile should be hardened such that it does not run any commands external to lintian and its Perl library dependencies. The alternative might be for ftp-master to run lintian on a VM or an external machine. I have a vague recollection that you mentioned that `sh -n` is unsafe in some situations. today I learned that lintian uses that to check for bashisms <_jwilk> I have this vague recollection too. I don't remember the details ATM. <_jwilk> I've found this in my IRC logs: https://lists.debian.org/87lfqriagj@mid.deneb.enyo.de <_jwilk> I fuzzed "bash -n" and "dash -n" in the past and found memory safety bug in both. <_jwilk> #878697 could probably be exploited for code execution. <_jwilk> There's also #858288, but I don't think anyone combines -n with -c. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#960367: lintian: warn about URL based fields that aren't fully qualified URLs
Package: lintian Version: 2.72.0 Severity: wishlist Please warn about Homepage and other URL based fields that do not contain fully qualified URLs. It seems that the Data::Validate::URI or URI Perl modules might be able to be used for this. There is currently one package in Debian that doesn't have a fully qualified Homepage URL: $ grep -Eh '^Homepage:[^:]+$' /var/lib/apt/lists/*Sources | sort -u Homepage: bbtools.sourceforge.net/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#960366: lintian: warn about Homepage fields pointing to download directories
Package: lintian Version: 2.72.0 Severity: wishlist Please warn about Homepage fields that point to download directories. Download directories are not "homepages" and should not be used like that. This complaint should be either info or pedantic level and should only be applied to Homepage fields not all URLs in the package. Since lintian doesn't do network requests it will have to detect solely based on the URL rather than content of the Homepage. URLs to ftp servers that end in a slash should be detected: ^ftp://.*/$ Maybe any ftp URL that doesn't end in .htm/.html should be detected? You could also detect specific servers based on the URLs: The first one that could be added is the GNU FTP server: Please match this regular expression: (https?|ftp)://ftp\.gnu\.org/gnu/(.*) and suggest replacing them with this replacement: https://www.gnu.org/software/$2 Please match this regular expression: (https?|ftp)://ftp\.gnu\.org/gnu/aspell/dict/[^/]*/ and suggest replacing them with this replacement (and ignore that URL): https://ftp.gnu.org/gnu/aspell/dict/0index.html These are the currently known ftp.gnu.org URLs: $ grep -h Homepage.*ftp.gnu.org /var/lib/apt/lists/*Sources | sort -u Homepage: ftp://ftp.gnu.org/gnu/aspell/dict/am/ Homepage: ftp://ftp.gnu.org/gnu/aspell/dict/he/ Homepage: ftp://ftp.gnu.org/gnu/aspell/dict/hy/ Homepage: ftp://ftp.gnu.org/non-gnu/chinese-fonts-truetype/ Homepage: http://ftp.gnu.org/gnu/aspell/dict/0index.html Homepage: http://ftp.gnu.org/gnu/aspell/dict/ar/ Homepage: http://ftp.gnu.org/gnu/aspell/dict/fa/ Homepage: http://ftp.gnu.org/gnu/bc/ Homepage: http://ftp.gnu.org/gnu/pem/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#954761: lintian: crashes with: coercion for "original_severity" failed: Unknown tag severity serious
Control: reassign -1 pkg-perl-tools Control: forcemerge 954331 -1 On Sun, 2020-03-22 at 18:35 -0700, Felix Lechner wrote: > This is #954331 in pkg-perl-tools, which is already done. > > Not sure how to best close this bug. Maybe 'forcemerge'? Yeah, doing with this mail. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#954761: lintian: crashes with: coercion for "original_severity" failed: Unknown tag severity serious
Package: lintian
Version: 2.58.0
Severity: serious
Control: found -1 2.59.0
Usertags: crash
Whenever I run lintian (either source or binaries) I get the following
crash. The configuration file and options used don't appear to cause
this crash. It appears to happen with all packages I try.
$ lintian nsis_3.05-1.dsc
coercion for "original_severity" failed: Unknown tag severity serious
Lintian::Tag::Info::__ANON__("serious") called at (eval 125) line 28
eval {...} called at (eval 125) line 27
Lintian::Tag::Info::original_severity(Lintian::Tag::Info=HASH(0x556c92ea6f30),
"serious") called at /usr/share/perl5/Lintian/Tag/Info.pm line 182
Lintian::Tag::Info::load(Lintian::Tag::Info=HASH(0x556c92ea6f30),
"/usr/share/lintian/tags/pkg-perl/module-build-tiny-needs-newe"...) called at
/usr/share/perl5/Lintian/Profile.pm line 224
Lintian::Profile::load(Lintian::Profile=HASH(0x556c92a0a5c8), undef,
ARRAY(0x556c9049c528), HASH(0x556c90740b90)) called at /usr/bin/lintian line 221
dplint::load_profile(undef) called at
/usr/share/lintian/commands/lintian.pm line 712
eval {...} called at /usr/share/lintian/commands/lintian.pm line 712
main::main() called at /usr/bin/lintian line 46
eval {...} called at /usr/bin/lintian line 46
main::__ANON__("/usr/share/lintian/commands/lintian.pm") called at
/usr/bin/lintian line 119
dplint::run_tool("/usr/bin/lintian", "lintian") called at
/usr/bin/lintian line 298
dplint::main() called at /usr/bin/lintian line 382
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (860,
'testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), (790,
'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690,
'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lintian depends on:
ii binutils 2.34-5
ii bzip21.0.8-2
ii diffstat 1.63-1
ii dpkg 1.19.7
ii dpkg-dev 1.19.7
ii file 1:5.38-4
ii gettext 0.19.8.1-10
ii gpg 2.2.19-3
ii intltool-debian 0.35.0+20060710.5
ii libapt-pkg-perl 0.1.36+b3
ii libarchive-zip-perl 1.68-1
ii libcapture-tiny-perl 0.48-1
ii libclass-xsaccessor-perl 1.19-3+b3
ii libclone-perl0.43-2
ii libdevel-size-perl 0.83-1+b1
ii libdpkg-perl 1.19.7
ii libemail-valid-perl 1.202-1
ii libfile-basedir-perl 0.08-1
ii libfile-find-rule-perl 0.34-1
ii libfont-ttf-perl 1.06-1
ii libhtml-parser-perl 3.72-5
ii libio-async-loop-epoll-perl 0.20-1
ii libio-async-perl 0.75-1
ii libipc-run-perl 20180523.0-2
ii libjson-maybexs-perl 1.004000-1
ii liblist-compare-perl 0.53-1
ii liblist-moreutils-perl 0.416-1+b5
ii libmoo-perl 2.003006-1
ii libmoox-aliases-perl 0.001006-1
ii libnamespace-clean-perl 0.27-1
ii libpath-tiny-perl0.108-1
ii libsereal-decoder-perl 4.011+ds-1
ii libsereal-encoder-perl 4.011+ds-1
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3200-1
ii libtry-tiny-perl 0.30-1
ii libtype-tiny-perl1.008001-2
ii liburi-perl 1.76-2
ii libxml-libxml-perl 2.0134+dfsg-2
ii libxml-writer-perl 0.625-1
ii libyaml-libyaml-perl 0.80+repack-2+b1
ii man-db 2.9.1-1
ii patchutils 0.3.4-2+b1
ii perl [libdigest-sha-perl]5.30.0-9
ii t1utils 1.41-3
ii xz-utils 5.2.4-1+b1
Versions of packages lintian recommends:
ii libperlio-gzip-perl 0.19-1+b6
Versions of packages lintian suggests:
ii binutils-multiarch 2.34-5
ii libtext-template-perl 1.58-1
-- no debconf information
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#948478: lintian: extend systemd-service-file-pidfile-refers-to-var-run tag to ListenStream as well
Package: lintian Version: 2.44.0 Severity: wishlist I see a bunch of messages like the one below in my journal log. Jan 09 14:58:17 systemd[1]: /lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update the unit file accordingly. The verify command also detects the same issue: $ systemd-analyze verify /lib/systemd/system/dbus.socket /lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update the unit file accordingly. Lintian detects this for the PIDFile option but not for ListenStream. Please extend the existing tag to cover both options, I guess it will need to be renamed in the process. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.33.1-6 ii bzip21.0.8-2 ii diffstat 1.63-1 ii dpkg 1.19.7 ii dpkg-dev 1.19.7 ii file 1:5.37-6 ii gettext 0.19.8.1-10 ii gpg 2.2.19-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b2 ii libarchive-zip-perl 1.67-1 ii libberkeleydb-perl 0.62-1+b1 ii libcapture-tiny-perl 0.48-1 ii libcgi-pm-perl 4.44-1 ii libclass-accessor-perl 0.51-1 ii libclass-xsaccessor-perl 1.19-3+b3 ii libclone-perl0.43-2 ii libdpkg-perl 1.19.7 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl 1.06-1 ii libio-async-loop-epoll-perl 0.20-1 ii libio-async-perl 0.75-1 ii libipc-run-perl 20180523.0-2 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl 0.416-1+b5 ii libmldbm-perl2.05-2 ii libmoo-perl 2.003006-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl0.108-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl1.008000-1 ii liburi-perl 1.76-1 ii libxml-libxml-perl 2.0134+dfsg-1+b1 ii libyaml-libyaml-perl 0.80+repack-2+b1 ii man-db 2.9.0-2 ii patchutils 0.3.4-2+b1 ii perl [libdigest-sha-perl]5.30.0-9 ii t1utils 1.41-3 ii xz-utils 5.2.4-1+b1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b6 Versions of packages lintian suggests: ii binutils-multiarch 2.33.1-6 ii libhtml-parser-perl3.72-3+b4 ii libtext-template-perl 1.58-1 -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#717595: Please check for update-rc.d "start" and "stop" argument usage
Control: tags -1 - moreinfo Since this problem is still an issue with packages in the archive (like x11-common), it would be nice to have lintian warn about the issues. On Tue, 17 Dec 2013 10:10:58 +0100 Bastien ROUCARIES wrote: > I am willing to implement this test but could you please provide a description A reasonable description was already provided in the mail: The update-rc.d "start" and "stop" arguments are obsoleted and replaced by the "defaults" argument. It is no longer possible to specify start and stop runlevel and sequence numbers; these must be provided by the LSB header of every init script. If start and/or stop arguments are provided, these now act as if "defaults" had been used instead, and the extra runlevel and sequence information is discarded, and a warning will be issued. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#934512: lintian false positive for source-is-missing for pmccabe2html output
On Mon, 12 Aug 2019 14:12:09 -0700 Chris Lamb wrote: > Therefore, please add an override with a suitably detailed comment to > your package. This file seems like the sort of thing that will get quickly outdated as the source code of the upstream project evolves. So it would be appropriate to always build the file from source. I suggest another option to solve this would be to have upstream remove the file from their VCS and tarballs so that it is always generated at build time. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#933305: lintian: pedantic complaint about duplicate items in a single debian/changelog entry
Package: lintian Severity: wishlist This morning I saw a package upgrade that had a changelog entry with these two lines in it. * debian/control: Use debhelper-compat 12 * debian/control: Use debhelper-compat 12 I think a pedantic complaint about the duplicate items would be appropriate to have in lintian. I would suggest each item in the changelog entry should be stripped of whitespace before comparing them so that trailing whitespace in one of them still triggers the complaint. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#933304: lintian: suggest switching from debian/compat to debhelper-compat
Package: lintian Severity: wishlist debhelper has replaced debian/compat with the debhelper-compat virtual package for most circumstances. Many packages made the switch already. https://manpages.debian.org/unstable/debhelper/debhelper.7.en.html#COMPATIBILITY_LEVELS I would like a pedantic reminder from lintian to switch from the debian/compat file to the debhelper-compat virtual package. Please note that there are some circumstances in which lintian should not complain about use of debian/compat: Note that debhelper does not provide debhelper-compat for experimental or beta compatibility levels; packages experimenting with those compatibility levels should use debian/compat or DH_COMPAT. In addition, it would probably be correct to not emit this if the debhelper build-dep allows versions before the debhelper version that added this feature (11.1.5~alpha1) or for uploads to stretch-backports or earlier suites (the feature is in debhelper in stretch-backports but isn't available in stretch itself): debhelper (11.1.5~alpha1) experimental; urgency=medium ... * Dh_Lib: Add an experimental feature to determine the requested compat level from the Build-Depends field. -- Niels Thykier Sat, 24 Feb 2018 16:01:31 + debhelper | 9.20150101+deb8u2 | oldoldstable | source, all debhelper | 10.2.5| oldstable | source, all debhelper | 12.1.1~bpo9+1 | stretch-backports | source, all debhelper | 12.1.1| stable| source, all debhelper | 12.2.3| testing | source, all debhelper | 12.2.3| unstable | source, all -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#933240: lintian: add a pedantic tag when Rules-Requires-Root is missing
Package: lintian Severity: wishlist I would like lintian to remind me when the new Rules-Requires-Root field is missing from the source stanza in the debian/control file. In the documentation for this tag, please mention that packagers should verify using diffoscope that the binaries built when the R³ field is set to no are identical to the ones produced when it is yes or absent. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#932862: lintian: check for autopkgtests that do cmd --version/--help but don't have Restrictions: superficial
Control: tags -1 - moreinfo On Wed, 2019-07-24 at 11:25 -0300, Chris Lamb wrote: > Thanks for this idea and for mentioning the "superficial" Restriction; > I was not aware of that. I guess my question at this point is how you > see this interacting, if at all, with the: no-op-testsuite tag? I would say that superficial tests do provide a small amount of test coverage (command-line parsing and options processing), while no-op commands do not test the package in any way. So superficial tests do provide a small amount of value. I think that this case is distinct enough from autopkgtests testing /bin/true that it should be a separate tag, mainly so that the two issues can be of different severity and have different explanatory text. Personally I'd promote no-op-testsuite to error (and autoreject such packages) and use warning for this one. > They are, of course, reporting on different things but they > would somewhat overlap in intention and perhaps merging them might be > worth considering, or perhaps separating them out even further. I think that what we can surmise about the intent of the people creating these errors and thus the lintian info text associated with these tags is going to be different enough to warrant separation. For example no-op-testsuite is at best naivety and at worst intentionally taking advantage of the reduced testing migration delay, while the superficial tests can either be a precursor to deeper testing or just the best one can do for some packages. For example a set of packages I maintain for Discord support can only be tested by humans since testing them would require a machine to pass reCAPTCHA, register two accounts, send messages between them and then delete the accounts. Even if the first requirement were feasible, testing like this is probably constitutes abuse of the Discord service. So superficial testing is the best that can be automatically done. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#932870: lintian: check that there are some autopkgtests that don't have Restrictions: superficial
Control: tags -1 - moreinfo On Wed, 2019-07-24 at 11:26 -0300, Chris Lamb wrote: > Parallel to my comment on #932862, what would you say to simply also > emitting testsuite-autopkgtest-missing in this case (and naturally > updating the description, etc). I would say that superficial tests do provide a small amount of test coverage (command-line parsing and options processing) so they do provide some value, so I think that this case is distinct enough from autopkgtests being entirely missing that it should be a separate tag. In addition I think this superficial-only-tests tag should be of a different severity to testsuite-autopkgtest-missing, perhaps raised to info or warning level instead of pedantic. > What I really mean to say is that I wonder whether we should zoom out > a bit and get a good picture about what we want in this area without > any duplicative code or effort. :) I agree that we should zoom out and get a more global view of the problems that could potentially arise in autopkgtests. This is my first foray into autopkgtest QA and so it is the first thing I ran into. I came into it through the uhubctl RC bug, which reports failure of a test that runs `uhubctl -v` via a script, rather than from the debian/tests/control file. I think unless lintian folks want to write some Haskell based on shellcheck or OCaml based on morbig (see Ralf's talks in recent DebConfs about shell script parsing), lintian will never be able to detect the uhubctl case as superficial. As a result I prepared an item for Misc Dev News asking people to tag their tests and to write some non-superficial tests: https://wiki.debian.org/DeveloperNews?action=diff=608=609 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#932870: lintian: check that there are some autopkgtests that don't have Restrictions: superficial
Package: lintian Version: 2.16.0 Severity: wishlist Suggested-by: dkg on #debci X-Debbugs-CC: Daniel Kahn Gillmor autopkgtests that have Restrictions: superficial do not provide significant test coverage. Please add a tag that is similar to the testsuite-autopkgtest-missing tag that is shown when there are no autopkgtests that are not marked as superficial. This will help ensure that maintainers add tests that provide tests that give much more significant test coverage and ensure the package is really functional. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#932862: lintian: check for autopkgtests that do cmd --version/--help but don't have Restrictions: superficial
Package: lintian Version: 2.16.0 Severity: wishlist A number of packages run cmd --version/--help in their autopkgtests. This test doesn't really test the functionality of the command, just of the command-line and options parsing. autopkgtest has an option called superficial for the Restrictions field that can be used to mark a test as not really exercising any real functionality. Trivial tests like running a command with the --version or --help options should be marked as superficial. Please add a lintian warning when a test runs either a command from $PATH or a test script with just a --help or --version argument but has not marked the test as superficial. There are probably a number of different ways to write a superficial that are harder to detect (like the one in uhubctl), but those will require manual review. https://codesearch.debian.net/search?q=path%3Adebian%2Ftests%2Fcontrol+--%28version%7Chelp%29 https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst#L302 https://codesearch.debian.net/search?q=path%3Adebian%2Ftests%2F+--%28version%7Chelp%29 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#928234: lintian: check for malformed debian/changelog entries
Package: lintian
Version: 2.13.0
Severity: wishlist
In LP#1827044 I reported a package that has a bogus debian/changelog:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1827044
binutils (2.29-8ubuntu1) artful; urgency=medium
* Merge with Debian; remaining changes:
- Build from upstream sources.
-- Matthias Klose Wed, 30 Aug 2017 08:13:33 +0200
*
-- Matthias Klose Wed, 13 Dec 2017 10:50:43 +
That causes the debian Python module to emit warnings:
$ python3 -c 'from debian import changelog as c; f =
open("debian/changelog"); c.Changelog(f)'
/usr/lib/python3/dist-packages/debian/changelog.py:484: UserWarning:
Unexpected line while looking for next heading of EOF: *
warnings.warn(message)
/usr/lib/python3/dist-packages/debian/changelog.py:484: UserWarning:
Unexpected line while looking for next heading of EOF: -- Matthias Klose
Wed, 13 Dec 2017 10:50:43 +
warnings.warn(message)
That changelog doesn't trigger a warning from lintian though.
It would be nice for lintian to emit warnings about changelog entries
that are missing headers, bodies or footers.
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (860,
'testing-proposed-updates'), (850, 'buildd-testing-proposed-updates'), (800,
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
LANGUAGE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /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:
ii binutils-multiarch 2.31.1-16
ii libhtml-parser-perl3.72-3+b3
ii libtext-template-perl 1.55-1
-- no debconf information
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn
On Wed, 2018-12-19 at 07:28 +, Scott Kitterman wrote: > I'm not arguing it's a bad idea to have the check, but personally, I > get tired of looking at it. If this is important, get it in Policy > as a should and then I think warning would be appropriate. > > Why don't I just fix it? I read the referenced material on what > needs doing and concluded I don't have the spare mental cycles to > learn all about this for one package. In general I think it is perfectly acceptable to ignore lintian and other QA tools when one does not have the time or energy to make the changes that they are suggesting. I also think it is reasonable to override lintian for something you don't have time or energy for and don't want to see the suggestion any more. In the this case, I think that users just installing libnitrokey-common won't get anything useful, so a lintian override is appropriate here since it cannot know that a binary package (nitrokey-app) from a different source package (nitrokey-app) is the place to add the modalias metadata. nitrokey-app already has an AppStream file, but it doesn't have the modalias metadata. So I think that libnitrokey-dev needs to expose modalias metadata for nitrokey-app to export. > It'd be much more efficient for someone who both understands what > needs doing and cares to run through the affected packages and submit > patches. I don't think I have the requisite time and understanding to do this, hopefully Petter will be interested to work on this but in general I think it will be best for individual upstreams to work on this since they know their software best and how to best expose which info. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn
On Wed, 2018-12-19 at 10:57 +0100, Chris Lamb wrote: > Hi Paul, > > > Downgrading it to info level means that almost no-one will know about > > it, so you might as well just delete the tag instead. > > I don't agree with this view of "I" tags but playing severity wars is > not my idea of a good time so I've reverted this and I'll you folks > fight it out between yourselves.. I'm sorry for the tone in this part of my response, it was inappropriate. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn
On Wed, 19 Dec 2018 01:00:43 +0100 Chris Lamb wrote: > Nobody is doubting the value here, one just has to square that with > the idea that Lintian being too pedantic, noisy or making the wrong > priority choices is bad for effectiveness of tool in its entirity. :) There are only 50 packages affected by this tag, is it really that big of a problem for it to be at warning level? https://lintian.debian.org/tags/appstream-metadata-missing-modalias-provide.html Downgrading it to info level means that almost no-one will know about it, so you might as well just delete the tag instead. Looking at the package list there are only a few packages where the tag might not apply (like zfsutils-linux) and some of the overrides are definitely bogus. The package that Scott maintains that is affected by this tag (libnitrokey-common) contains udev rules for a specific set of USB devices, so it or another package (like nitrokey-app) definitely needs to have the modalias metadata declared so that users can easily find software for the Nitrokey and other devices when they plug them in. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#913280: lintian: please warn about packages including files in /usr/share/hal/ (used by obsolete hal package)
Package: lintian Version: 2.5.111 Severity: wishlist Usertags: obsolete Three packages install files in /usr/share/hal/ but this directory is no longer looked at by any package in Debian since hal was removed in 2014 because it was replaced by udev. I will file bugs on the three affected packages but it would be good for lintian to warn about use of /usr/share/hal/ so that no new or updated packages add files there. https://bugs.debian.org/747662 $ apt-file search /usr/share/hal/ libmtp-common: /usr/share/hal/fdi/information/20thirdparty/20-libmtp9.fdi libsane-common: /usr/share/hal/fdi/preprobe/10osvendor/20-libsane.fdi ntfs-3g: /usr/share/hal/fdi/policy/10osvendor/25-ntfs-3g-policy.fdi -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.31.1-7 ii bzip2 1.0.6-9 ii diffstat 1.61-1+b1 ii dpkg 1.19.2 ii file 1:5.34-2 ii gettext0.19.8.1-8 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34+b1 ii libarchive-zip-perl1.64-1 ii libcgi-pm-perl 4.40-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.41-1+b1 ii libdpkg-perl 1.19.2 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b4 ii libparse-debianchangelog-perl 1.2.0-13 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.74+repack-1+b1 ii man-db 2.8.4-2+b1 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.28.0-3 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b5 Versions of packages lintian suggests: ii binutils-multiarch 2.31.1-7 ii dpkg-dev 1.19.2 ii libhtml-parser-perl3.72-3+b3 ii libtext-template-perl 1.53-1 -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#906722: lintian: warn about `dh_shlibdeps -V` in debian/rules
Package: lintian Severity: wishlist I was updating an old package and got a warning from dh_shlibdeps: dh_shlibdeps -V "libglc0 (>= 0.7.1)" dh_shlibdeps: You probably wanted to pass -V to dh_makeshlibs, it has no effect on dh_shlibdeps It would be nice to have lintian warn about this too since some folks might not read their build logs extensively but might pay more attention to lintian. This is what the debian/rules file in question looks like: $ grep shlib debian/rules override_dh_shlibdeps: dh_shlibdeps -V "libglc0 (>= 0.7.1)" -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#905881: lintian: detect packages containing X11 fonts that do not run update-fonts-* or do not dep on xfonts-utils
On Sat, 2018-08-11 at 10:07 +0100, Chris Lamb wrote:
>
> https://salsa.debian.org/lintian/lintian/commit/1fe8f33d7ffaab74c47d5ed61c56d8a8a0abb693
Thanks.
A few fixes are needed:
s/which comes/which come/
s/If you are using dh_installxfonts/If you are using debhelper/
The code unconditionally detects update-fonts-scale but the
dh_installxfonts code only inserts that conditionally (see below).
The code does not detect update-fonts-alias being missing but
dh_installxfonts conditionally inserts calls to that (see below).
One of the tag descriptions mentions an update-fonts-utils script,
but that does not exist:
$ find /usr/sbin/update-fonts-*
/usr/sbin/update-fonts-alias
/usr/sbin/update-fonts-dir
/usr/sbin/update-fonts-scale
Here is most of the code from dh_installxfonts:
foreach my $package (@{$dh{DOPACKAGES}}) {
my $tmp=tmpdir($package);
# Find all font directories in the package build directory.
my @fontdirs;
foreach my $parentdir ("$tmp/usr/share/fonts/X11/") {
opendir(DIR, $parentdir) || next;
@fontdirs = grep { -d "$parentdir/$_" && !/^\./ } (readdir DIR);
closedir DIR;
}
if (@fontdirs) {
# Figure out what commands the postinst and postrm will need
# to call.
my @cmds;
my @cmds_postinst;
my @cmds_postrm;
# Sort items for reproducible binary package contents.
foreach my $f (sort @fontdirs) {
# This must come before update-fonts-dir.
push @cmds, "update-fonts-scale $f"
if -f "$tmp/etc/X11/fonts/$f/$package.scale";
push @cmds, "update-fonts-dir --x11r7-layout $f";
if (-f "$tmp/etc/X11/fonts/$f/$package.alias") {
push @cmds_postinst, "update-fonts-alias
--include /etc/X11/fonts/$f/$package.alias $f";
push @cmds_postrm, "update-fonts-alias
--exclude /etc/X11/fonts/$f/$package.alias $f";
}
}
autoscript($package, "postinst", "postinst-xfonts",
{ 'CMDS' => join(";", @cmds, @cmds_postinst) });
autoscript($package, "postrm", "postrm-xfonts",
{ 'CMDS' => join(";", @cmds, @cmds_postrm) });
if (@cmds_postrm) {
addsubstvar($package, "misc:Depends", "xfonts-utils",
">= 1:7.5+2");
} else {
addsubstvar($package, "misc:Depends", "xfonts-utils");
}
}
}
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#905881: lintian: detect packages containing X11 fonts that do not run update-fonts-* or do not dep on xfonts-utils
Package: lintian
Version: 2.5.96
Severity: wishlist
As a result of a thread[1] on debian-fonts, I found that lmodern and
tex-gyre contain X11 fonts but do not run update-fonts-* from their
postinst and do not depend on xfonts-utils via ${misc:Depends}, both
of these are automatically added by dh_installxfonts if run correctly.
I filed bugs[2] about these issues but it would be nice to have lintian
detect binary packages containing X11 fonts[3] that do not depend on
xfonts-utils or do not have the dh_installxfonts snippet[4] that
debhelper installs into the maintainer scripts.
1.
https://lists.debian.org/msgid-search/CAJqvfD-A1EPXxF_mS=_baq0ftqygvwruf+23wqsqrksmygv...@mail.gmail.com
2. https://bugs.debian.org/905879
https://bugs.debian.org/905880
3. /usr/share/fonts/X11/**/*.pcf.gz
/usr/share/fonts/X11/**/*.pcf
/usr/share/fonts/X11/**/*.pfa
/usr/share/fonts/X11/**/*.pfb
/usr/share/fonts/X11/**/*.afm
4. For example:
# Automatically added by dh_installxfonts/11.3.5
if [ -x "`which update-fonts-dir 2>/dev/null`" ]; then
update-fonts-scale Type1;update-fonts-dir --x11r7-layout Type1
fi
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
LANGUAGE=en_AU.utf8 (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.31.1-2
ii bzip2 1.0.6-8.1
ii diffstat 1.61-1+b1
ii dpkg 1.19.0.5+b1
ii file 1:5.33-3
ii gettext0.19.8.1-6+b1
ii intltool-debian0.35.0+20060710.4
ii libapt-pkg-perl0.1.34
ii libarchive-zip-perl1.60-1
ii libclass-accessor-perl 0.51-1
ii libclone-perl 0.39-1
ii libdpkg-perl 1.19.0.5
ii libemail-valid-perl1.202-1
ii libfile-basedir-perl 0.08-1
ii libipc-run-perl20180523.0-1
ii liblist-moreutils-perl 0.416-1+b3
ii libparse-debianchangelog-perl 1.2.0-12
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3000-2
ii liburi-perl1.74-1
ii libxml-simple-perl 2.25-1
ii libyaml-libyaml-perl 0.72+repack-1
ii man-db 2.8.4-2
ii patchutils 0.3.4-2
ii perl [libdigest-sha-perl] 5.26.2-6
ii t1utils1.41-2
ii xz-utils 5.2.2-1.3
Versions of packages lintian recommends:
ii libperlio-gzip-perl 0.19-1+b4
Versions of packages lintian suggests:
ii binutils-multiarch 2.31.1-2
ii dpkg-dev 1.19.0.5
ii libhtml-parser-perl3.72-3+b2
ii libtext-template-perl 1.53-1
-- no debconf information
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#904414: lintian: check for Perl scripts with a shebang not using /usr/bin/perl (Policy 10.4)
Package: lintian Version: 2.5.93 Severity: wishlist Debian Policy 10.4 states: All command scripts, including the package maintainer scripts inside the package and used by dpkg, should have a #! line naming the shell to be used to interpret them. In the case of Perl scripts this must be #!/usr/bin/perl. It would be nice if lintian could detect scripts that are Perl scripts (text/x-perl MIME type or "Perl script text executable" file type) but do not use the /usr/bin/perl binary in the shebang. While arguments in shebangs are usually a bad idea, lintian should accept them here: Debian Policy 10.4 compliant: #!/usr/bin/perl #!/usr/bin/perl -T #! /usr/bin/perl #! /usr/bin/perl -T Not Debian Policy 10.4 compliant: #!/usr/bin/env perl #!/usr/local/bin/perl -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (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.31.1-1 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.19.0.5+b1 ii file 1:5.33-3 ii gettext0.19.8.1-6+b1 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34 ii libarchive-zip-perl1.60-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.39-1 ii libdpkg-perl 1.19.0.5 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.69+repack-1 ii man-db 2.8.3-2 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.26.2-6 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: ii binutils-multiarch 2.31.1-1 ii dpkg-dev 1.19.0.5 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.53-1 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#903690: lintian: check if Vcs-* fields other than Vcs-Git link to known git repository hosting locations
On Sun, 2018-07-15 at 10:32 +0100, Chris Lamb wrote: > > https://salsa.debian.org/lintian/lintian/commit/1ead3e4dbe412efda03689009ec86c2c3a7ea26e There is a typo in data/fields/vcs-hosters: s/git.hg/git,hg/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#903690: lintian: check if Vcs-* fields other than Vcs-Git link to known git repository hosting locations
On Fri, 2018-07-13 at 16:04 +0100, Chris Lamb wrote: > https://salsa.debian.org/lintian/lintian/commit/0ef5fa79db384ea97cf68a39c9bf116353a6189b Note that bitbucket.org is dual-VCS, it supports both git and hg, so this commit will introduce false positives for a few packages: $ grep -hi ^vcs- /var/lib/apt/lists/*Sources | grep -i bitbu | grep -vi vcs-git | grep -vi vcs-browser | sort -u | grep -v svn.debian Vcs-Hg: https://bitbucket.org/auto-multiple-choice/auto-multiple-choice Vcs-Hg: https://bitbucket.org/goatchurch/tunnelx Vcs-Hg: https://bitbucket.org/jwilk/adequate Vcs-Hg: https://bitbucket.org/neomantra/rubyluabridge Vcs-Hg: https://bitbucket.org/tshepang/wajig -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#903690: lintian: check if Vcs-* fields other than Vcs-Git link to known git repository hosting locations
On Fri, 2018-07-13 at 09:10 +0100, Chris Lamb wrote: > Does the package get a "vcs-deprecated-in-debian-infra" warning? Doesn't look like it: https://lintian.debian.org/full/pkg-games-de...@lists.alioth.debian.org.html#chromium-bsu -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#903690: lintian: check if Vcs-* fields other than Vcs-Git link to known git repository hosting locations
Package: lintian Version: 2.5.92 Severity: wishlist The chromium-bsu source package uses a link to a salsa git repository in a Vcs-Svn field. Consequently debcheckout fails to clone the repository and DUCK warns about the issue. vcswatch does not warn about the issue because the last uploader edited the field on vcswatch. There are two other packages affected by a similar issue but the amount could increase as people continue to migrate packages from alioth to salsa. http://duck.debian.net/static/sp/c/chromium-bsu.html https://qa.debian.org/cgi-bin/vcswatch?package=chromium-bsu $ apt-cache showsrc chromium-bsu | grep -i git | grep -i svn Vcs-Svn: https://salsa.debian.org/games-team/chromium-bsu.git $ debcheckout chromium-bsu declared svn repository at https://salsa.debian.org/games-team/chromium-bsu.git svn co https://salsa.debian.org/games-team/chromium-bsu.git chromium-bsu ... svn: E170013: Unable to connect to a repository at URL 'https://salsa.debian.org/games-team/chromium-bsu.git' svn: E160013: '/games-team/chromium-bsu.git' path not found checkout failed (the command above returned a non-zero exit code) $ grep -hi ^vcs- /var/lib/apt/lists/*Sources | grep -vi ^vcs-browser | grep -vi ^Vcs-Git | grep salsa | sort -u Vcs-Svn: https://salsa.debian.org/dmn/bgoffice-dict-downloader.git Vcs-Svn: https://salsa.debian.org/games-team/chromium-bsu.git Vcs-Svn: https://salsa.debian.org/georgesk/qspeakers.git -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (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.30.90.20180710-1 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.19.0.5+b1 ii file 1:5.33-3 ii gettext0.19.8.1-6+b1 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34 ii libarchive-zip-perl1.60-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.39-1 ii libdpkg-perl 1.19.0.5 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.69+repack-1 ii man-db 2.8.3-2 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.26.2-6 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: ii binutils-multiarch 2.30.90.20180710-1 ii dpkg-dev 1.19.0.5 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.53-1 -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#902797: lintian: check latest changelog entry for duplicate contributor information
Control: close -1 On Sun, 2018-07-01 at 10:45 +0100, Chris Lamb wrote: > Tagging as moreinfo for the time being... The discussion has revealed that we do not have consensus on what debian/changelog should look like in general so I close this bug. I don't plan on starting any wider discussion on this topic but I'll happily express my opinions if someone wants to work on this. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#902797: lintian: check latest changelog entry for duplicate contributor information
Package: lintian
Version: 2.5.91
Severity: wishlist
I recently saw a changelog entry (quoted below) for a Perl team package
where several contributors to that version had their names mentioned
multiple times with one or more changes below each instance of their
name. This made the changelog harder to read. I think it would be
useful for lintian to emit a pedantic or info-level warning for
duplicate contributor information in the latest changelog entry.
Earlier changelog entries are historical information and probably not
worth fixing but the latest one will presumably be the entry being
prepared before upload. In order to ignore all the existing entries on
lintian.d.o, this check could be applied only to UNRELEASED entries.
libdigest-hmac-perl (1.03+dfsg-2) unstable; urgency=medium
* Team upload
[ Ansgar Burchardt ]
* debian/control: Convert Vcs-* fields to Git.
[ Salvatore Bonaccorso ]
* debian/copyright: Replace DEP5 Format-Specification URL from
svn.debian.org to anonscm.debian.org URL.
[ gregor herrmann ]
* debian/control: update {versioned,alternative} (build) dependencies.
[ Salvatore Bonaccorso ]
* Change Vcs-Git to canonical URI (git://anonscm.debian.org)
* Change search.cpan.org based URIs to metacpan.org based URIs
[ gregor herrmann ]
* Update debian/repack.stub.
[ Axel Beckert ]
* debian/copyright: migrate pre-1.0 format to 1.0 using "cme fix dpkg-
copyright"
[ gregor herrmann ]
* Strip trailing slash from metacpan URLs.
[ Salvatore Bonaccorso ]
* Update Vcs-Browser URL to cgit web frontend
* debian/control: Use HTTPS transport protocol for Vcs-Git URI
[ gregor herrmann ]
* debian/copyright: change Copyright-Format 1.0 URL to HTTPS.
* Switch repackaging framework to Files-Excluded method.
* Remove Carlo Segre from Uploaders. Thanks for your work!
* Remove Zak B. Elep from Uploaders on request of the MIA team
(Closes: #863529)
[ Salvatore Bonaccorso ]
* Update Vcs-* headers for switch to salsa.debian.org
[ Florian Schlichting ]
* Bump dh compat to level 11
* Declare compliance with Debian Policy 4.1.4
-- Florian Schlichting Wed, 27 Jun 2018 21:53:39 +0200
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
LANGUAGE=en_AU.utf8 (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.30.90.20180627-1
ii bzip2 1.0.6-8.1
ii diffstat 1.61-1+b1
ii dpkg 1.19.0.5+b1
ii file 1:5.33-3
ii gettext0.19.8.1-6+b1
ii intltool-debian0.35.0+20060710.4
ii libapt-pkg-perl0.1.34
ii libarchive-zip-perl1.60-1
ii libclass-accessor-perl 0.51-1
ii libclone-perl 0.39-1
ii libdpkg-perl 1.19.0.5
ii libemail-valid-perl1.202-1
ii libfile-basedir-perl 0.08-1
ii libipc-run-perl20180523.0-1
ii liblist-moreutils-perl 0.416-1+b3
ii libparse-debianchangelog-perl 1.2.0-12
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3000-2
ii liburi-perl1.74-1
ii libxml-simple-perl 2.25-1
ii libyaml-libyaml-perl 0.69+repack-1
ii man-db 2.8.3-2
ii patchutils 0.3.4-2
ii perl [libdigest-sha-perl] 5.26.2-6
ii t1utils1.41-2
ii xz-utils 5.2.2-1.3
Versions of packages lintian recommends:
ii libperlio-gzip-perl 0.19-1+b4
Versions of packages lintian suggests:
ii binutils-multiarch 2.30.90.20180627-1
ii dpkg-dev 1.19.0.5
ii libhtml-parser-perl3.72-3+b2
ii libtext-template-perl 1.53-1
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#898136: lintian: Reduce depends-on-mail-transport-agent-without-alternatives to pedantic
Control: tags -1 - moreinfo On Mon, 2018-05-07 at 19:27 -0700, Russ Allbery wrote: > I looked at the original bug report from Paul Wise (cc'd) (#892144), and > the motivation was unclear to me. Were there packages in the archive that > depended on only one MTA and weren't MTA add-ons or otherwise > intentionally locked to just one MTA? IIRC the motivation at the time was that I had found another MTA related issue in the archive, filed a lintian bug about it, thought about other MTA issues that might exist and filed #892144 about that. > At first glance, the bug this tag is trying to diagnose seems unlikely to > me. I'm not sure how many maintainers intended to depend on a generic > mail-transport-agent and just picked one out of a hat (although I admit > the lack of documentation in Policy for how to declare this dependency > doesn't help). In contrast, add-ons for one specific MTA, or management > interfaces that only know how to configure one specific MTA, are fairly > common. I didn't go over every package in the archive before filing the issue, I think I might have wanted lintian.d.o to do that for me ;) > I just now checked, and the packages currently diagnosed with this > tag [1] are 100% false positives, which makes me wonder if this tag > should just be deleted. I haven't confirmed this, but if true, go ahead. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#897082: lintian: Please do not warn about debian-watch-uses-insecure-uri for ftp:// URIs
On Sat, 28 Apr 2018 07:49:43 +0200 Andreas Tille wrote: > I: seaview source: debian-watch-uses-insecure-uri > ftp://pbil.univ-lyon1.fr/pub/mol_phylogeny/seaview/archive/seaview_(.*)\.tar\.gz lintian is correct here, ftp URLs are insecure. > Since there is no anonymous secure ftp this info is not very helpful IMHO. FTP over TLS exists: https://en.wikipedia.org/wiki/FTPS I assume you mean there is no secure version of the URL you're using in debian/watch. In that case the appropriate action is to contact upstream and ask them to supply a secure URL for the files. Until they provide one, you should just ignore this warning. If they refuse to provide one you could override the warning with a comment. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
[lintian] branch master updated (48f066f -> d1d7333)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from 48f066f spelling: Add several corrections new d1d7333 spelling: Add another correction The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] 01/01: spelling: Add another correction
This is an automated email from the git hooks/post-receive script. pabs pushed a commit to branch master in repository lintian. commit d1d73339ee91d1dd97900708d48eb64dd70a8f3b Author: Paul Wise <p...@debian.org> Date: Sat Apr 7 13:22:56 2018 +0800 spelling: Add another correction --- data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) diff --git a/data/spelling/corrections b/data/spelling/corrections index 3e02863..2b05505 100644 --- a/data/spelling/corrections +++ b/data/spelling/corrections @@ -281,6 +281,7 @@ ang||and anlysis||analysis anniversery||anniversary annoncement||announcement +annonymous||anonymous annouce||announce annouced||announced annoucement||announcement -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] branch master updated (786da4c -> 48f066f)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from 786da4c Add offending interpreter to all X-script-but-no-X-dep tags. new 48f066f spelling: Add several corrections The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 2 ++ 1 file changed, 2 insertions(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] 01/01: spelling: Add several corrections
This is an automated email from the git hooks/post-receive script. pabs pushed a commit to branch master in repository lintian. commit 48f066fa14245d8bfba9ab4a05f4daf430393940 Author: Paul Wise <p...@debian.org> Date: Sat Apr 7 08:11:36 2018 +0800 spelling: Add several corrections --- data/spelling/corrections | 2 ++ 1 file changed, 2 insertions(+) diff --git a/data/spelling/corrections b/data/spelling/corrections index 20dbfcd..3e02863 100644 --- a/data/spelling/corrections +++ b/data/spelling/corrections @@ -2584,6 +2584,7 @@ mumbers||numbers musn't||mustn't mutiple||multiple mutliple||multiple +myslef||myself nam||name nams||names navagating||navigating @@ -4258,6 +4259,7 @@ woudn't||wouldn't woud||would would'nt||wouldn't would't||wouldn't +wraper||wrapper writeing||writing writen||written writting||writing -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] branch master updated (a742ce5 -> be909d3)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from a742ce5 spelling: Add another correction new be909d3 spelling: Add several corrections The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 2 ++ 1 file changed, 2 insertions(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] 01/01: spelling: Add several corrections
This is an automated email from the git hooks/post-receive script. pabs pushed a commit to branch master in repository lintian. commit be909d3b1eb574973278d0674293c4930076aa9e Author: Paul Wise <p...@debian.org> Date: Fri Apr 6 12:36:21 2018 +0800 spelling: Add several corrections --- data/spelling/corrections | 2 ++ 1 file changed, 2 insertions(+) diff --git a/data/spelling/corrections b/data/spelling/corrections index 64e5202..20dbfcd 100644 --- a/data/spelling/corrections +++ b/data/spelling/corrections @@ -4223,6 +4223,7 @@ whereever||wherever wheter||whether whe||when whiped||wiped +whishlist||wishlist whish||wish whitch||which whithout||without @@ -4252,6 +4253,7 @@ wnat||want wont||won't workaroung||workaround workes||works +worthing||meriting woudn't||wouldn't woud||would would'nt||wouldn't -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] branch master updated (f3b1265 -> a742ce5)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from f3b1265 spelling: Add another correction new a742ce5 spelling: Add another correction The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] 01/01: spelling: Add another correction
This is an automated email from the git hooks/post-receive script. pabs pushed a commit to branch master in repository lintian. commit a742ce5e3812179997cc3b03157ce94dc05b656e Author: Paul Wise <p...@debian.org> Date: Thu Apr 5 15:42:40 2018 +0800 spelling: Add another correction --- data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) diff --git a/data/spelling/corrections b/data/spelling/corrections index 1b44e92..64e5202 100644 --- a/data/spelling/corrections +++ b/data/spelling/corrections @@ -1592,6 +1592,7 @@ excactly||exactly excecutable||executable exceded||exceeded excellant||excellent +exceptation||expectation excercised||exercised excercise||exercise excercises||exercises -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] branch master updated (cd31f7c -> f3b1265)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from cd31f7c Spelling fixes. (Closes: #894834) new f3b1265 spelling: Add another correction The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] 01/01: spelling: Add another correction
This is an automated email from the git hooks/post-receive script. pabs pushed a commit to branch master in repository lintian. commit f3b1265323b7b292bad94d21a85e65a15996a7e4 Author: Paul Wise <p...@debian.org> Date: Thu Apr 5 07:13:17 2018 +0800 spelling: Add another correction --- data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) diff --git a/data/spelling/corrections b/data/spelling/corrections index ad134ee..1b44e92 100644 --- a/data/spelling/corrections +++ b/data/spelling/corrections @@ -1535,6 +1535,7 @@ environent||environment eqivalent||equivalent equiped||equipped equitorial||equatorial +equivalant||equivalent equivelant||equivalent equivilant||equivalent equvalent||equivalent -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] branch master updated (fe02a51 -> d1045e7)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from fe02a51 Apply a patch series from Simon McVittie to match the Gobject Introspection policy. (Closes: #881491) new d1045e7 spelling: Add several corrections The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 2 ++ 1 file changed, 2 insertions(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] 01/01: spelling: Add several corrections
This is an automated email from the git hooks/post-receive script. pabs pushed a commit to branch master in repository lintian. commit d1045e7691630c736bea3a942d45311ad794133c Author: Paul Wise <p...@debian.org> Date: Wed Apr 4 18:11:35 2018 +0800 spelling: Add several corrections --- data/spelling/corrections | 2 ++ 1 file changed, 2 insertions(+) diff --git a/data/spelling/corrections b/data/spelling/corrections index 0554085..ad134ee 100644 --- a/data/spelling/corrections +++ b/data/spelling/corrections @@ -2507,6 +2507,8 @@ messge||message messges||messages messsage||message messsages||messages +metacharater||metacharacter +metacharaters||metacharacters microprocesspr||microprocessor milisecond||millisecond miliseconds||milliseconds -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] branch master updated (e416c20 -> cd397b8)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from e416c20 spelling: Add another correction new cd397b8 spelling: Add another correction The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] branch master updated (43e8d51 -> e416c20)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from 43e8d51 spelling: Add several corrections new e416c20 spelling: Add another correction The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] 01/01: spelling: Add another correction
This is an automated email from the git hooks/post-receive script. pabs pushed a commit to branch master in repository lintian. commit e416c206f8a076d05e86909dbd2258327e012cf3 Author: Paul Wise <p...@debian.org> Date: Sun Apr 1 17:19:57 2018 +0800 spelling: Add another correction --- data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) diff --git a/data/spelling/corrections b/data/spelling/corrections index b7f6bd9..52e527c 100644 --- a/data/spelling/corrections +++ b/data/spelling/corrections @@ -3794,6 +3794,7 @@ suuport||support swaped||swapped swaping||swapping switchs||switches +swithch||switch swtich||switch syles||styles syle||style -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] branch master updated (71bbe5b -> 43e8d51)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from 71bbe5b checks/cruft.desc: Add src-orig-index for sorted_orig_index. new 43e8d51 spelling: Add several corrections The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 2 ++ 1 file changed, 2 insertions(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] 01/01: spelling: Add several corrections
This is an automated email from the git hooks/post-receive script. pabs pushed a commit to branch master in repository lintian. commit 43e8d510b36dfb177ac9b977b5bff185a7988cd7 Author: Paul Wise <p...@debian.org> Date: Sat Mar 31 23:46:24 2018 +0800 spelling: Add several corrections --- data/spelling/corrections | 2 ++ 1 file changed, 2 insertions(+) diff --git a/data/spelling/corrections b/data/spelling/corrections index 6aaa987..b7f6bd9 100644 --- a/data/spelling/corrections +++ b/data/spelling/corrections @@ -3892,6 +3892,8 @@ tigth||tight tihs||this timeing||timing timestan||timespan +timestemps||timestamps +timestemp||timestamp timetamps||timestamps timetamp||timestamp timming||timing -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] branch master updated (bb6188d -> 7b22c8b)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from bb6188d spelling: Add another correction new 7b22c8b spelling: Add another correction The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] 01/01: spelling: Add another correction
This is an automated email from the git hooks/post-receive script. pabs pushed a commit to branch master in repository lintian. commit 7b22c8b289407d1918cfa8e29ae1f28218cf9b0c Author: Paul Wise <p...@debian.org> Date: Wed Mar 28 11:53:54 2018 +0800 spelling: Add another correction --- data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) diff --git a/data/spelling/corrections b/data/spelling/corrections index 5d91bc2..6aaa987 100644 --- a/data/spelling/corrections +++ b/data/spelling/corrections @@ -3388,6 +3388,7 @@ reuqesting||requesting reuqest||request reuqests||requests revrese||reverse +rewrited||rewrote rewriten||rewritten rigth||right rigths||rights -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] branch master updated (446cde0 -> bb6188d)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from 446cde0 spelling: Add another correction new bb6188d spelling: Add another correction The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] 01/01: spelling: Add another correction
This is an automated email from the git hooks/post-receive script. pabs pushed a commit to branch master in repository lintian. commit bb6188dc525890533e7d5596495f596eb5b2980d Author: Paul Wise <p...@debian.org> Date: Tue Mar 27 14:27:41 2018 +0800 spelling: Add another correction --- data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) diff --git a/data/spelling/corrections b/data/spelling/corrections index ca560c9..5d91bc2 100644 --- a/data/spelling/corrections +++ b/data/spelling/corrections @@ -1651,6 +1651,7 @@ explainations||explanations explaning||explaining explantion||explanation explantions||explanations +explenation||explanation explicite||explicit explicitely||explicitly explicitily||explicitly -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
[lintian] branch master updated (8782e00 -> 446cde0)
This is an automated email from the git hooks/post-receive script. pabs pushed a change to branch master in repository lintian. from 8782e00 Avoid false positives in spelling detection by allowing "(s)" suffixes instead of universally stripping all parenthesis. (Closes: #894077) new 446cde0 spelling: Add another correction The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "adds" were already present in the repository and have only been added to this reference. Summary of changes: data/spelling/corrections | 1 + 1 file changed, 1 insertion(+) -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/lintian/lintian.git
