Bug#1014083: Leaves many mldbm files in /tmp without cleanup
Package: lintian Version: 2.115.2 Severity: normal X-Debbugs-Cc: j...@joshtriplett.org The current version of lintian seems to create numerous temporary files in /tmp/mldbm-elf-* and /tmp/mldbm-elf-by-member-* and while some of them disappear by the time lintian finishes, others remain around without getting cleaned up. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils2.38.50.20220627-1 ii bzip2 1.0.8-5 ii diffstat1.64-1 ii dpkg1.21.8 ii dpkg-dev1.21.8 ii file1:5.41-4 ii gettext 0.21-6 ii gpg 2.2.35-2 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.8 ii libemail-address-xs-perl1.04-1+b4 ii libfile-basedir-perl0.09-1 ii libfile-find-rule-perl 0.34-1.1 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.10-1 ii libwww-mechanize-perl 2.09-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-4 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.20220627-1 pn libtext-template-perl -- no debconf information
Bug#1013946: lintian: wrongly report unknown-locale-code ber
Hi Tobias, Dr. Tobias Quathamer wrote: > The safest way for lintian would probably be to use ISO 639-3 as a source > for locale checking, because those codes represent an individual language. > The vast majority of program translations are into an individual language, > so the check seems plausible. > > For bonus points, you could also check ISO 639-5 and print a warning (or > info) that this locale code represents a language group rather than an > individual language. :-) > > This is essentially Axel's latest suggestion -- except that I'd suggest to > use ISO 639-3 instead of ISO 639-2 as authoritative source. Thanks for this summary and especially also all the history! (And for reading our long mails which showed bit by bit our experiences and discoveries. :-) > Sorry for this long e-mail, but languages and their codes are pretty > hard ... No need to be sorry! Will try to implement this in lintian. Thanks again! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1013946: lintian: wrongly report unknown-locale-code ber
Am 28.06.22 um 02:31 schrieb Axel Beckert: Still would be happy about input from Toddy on this. :-) Hi all, thanks a lot for your research and insights ... I'm not an ISO expert, either, but from my reading and understanding the relationship between the standards (and the intended use) is as follows: First, ISO 639 (without the suffix -1) was created, and it included most of the major (spoken and written) languages of the world. All included languages had a two letter code (like "en" for English). As it quickly turned out, the two letter code was not enough to categorize all written and spoken languages. :-) Therefore, ISO 639 became ISO 639-1 and the development of ISO 639-2 started. As far as I know, ISO 639-1 is a strict subset of ISO 639-2. The standard ISO 639-2 introduced a three letter code, so they could include many more languages. As the standard was intended to be used in bibliographic contexts, they created a code for every individual language which has at least a "modest body of literature" (whatever "modest" means here.) In order to accommodate languages with an even smaller proportion of literature, they created collections of languages, called "language groups" or "families". One such example are the Berber languages which you've discovered. Lastly, ISO 639-3 and 639-5 have been created. Those standards aim to make a clear distinction between individual languages (in ISO 639-3) and language groups or families (ISO 639-5). Apart from the language families (like Berber), every element that represents an individual language in ISO 639-2 is included in ISO 639-3. So for individual languages, ISO 639-2 is a strict subset of ISO 639-3. I'm not entirely sure if it's a good idea to use a language family as a locale (or in this context, program translation). It might work for the Berber example, if the Berber languages are really so similar that it doesn't matter which language it is exactly. However, I don't know anything about Berber languages, so I cannot tell if this approach makes sense. From a quick search, there are at least Kabyle language, Shilha language, the Tuareg languages, Tarifit, and Central Atlas Tamazight which are summed up as Berber languages. The safest way for lintian would probably be to use ISO 639-3 as a source for locale checking, because those codes represent an individual language. The vast majority of program translations are into an individual language, so the check seems plausible. For bonus points, you could also check ISO 639-5 and print a warning (or info) that this locale code represents a language group rather than an individual language. :-) This is essentially Axel's latest suggestion -- except that I'd suggest to use ISO 639-3 instead of ISO 639-2 as authoritative source. Sorry for this long e-mail, but languages and their codes are pretty hard ... Regards, Tobias OpenPGP_signature Description: OpenPGP digital signature
Bug#1007002: Lintian breaks existing lintian-overrides due to added []
Hi Axel, Am Wed, Jun 29, 2022 at 06:01:33PM +0200 schrieb Axel Beckert: > Andreas: Sorry if I was a bit too opposing because of assuming that > every DD uses Unstable by default. No need to be sorry, really not. I simply missed the point of that change. > (Actually I think the Dev Ref says > you should, though. ;-) Or if DDs pinned Lintian to 2.111.0 from > Testing… I'm using testing but pinned lintian on unstable - so at least in my case it was not what Lucas pointed out. It was just that I beared the change for some time ... and than my amount of patience spilled over. ;-P But its correct that some users might use lintian from testing anyway. Kind regards Andreas. -- http://fam-tille.de
Bug#1007002: Lintian breaks existing lintian-overrides due to added []
Hi again, Axel Beckert wrote: > Andreas Tille wrote: > > I'll start editing lintian-overrides then. > > Maybe wait a bit with that. Given Lucas' comment, I feel a bit more > urged to provide such a migration script. > > I will look into this for the next upload. No promises as of now, > though. A first prototype is now available in git in the branch "migrate-overrides": https://salsa.debian.org/lintian/lintian/-/blob/migrate-overrides/bin/lintian-migrate-overrides-to-pointed-hints So far the script only knows about the tags spelling-error-in-binary and package-contains-documentation-outside-usr-share-doc, but it is explicitly written to be expandable. Of course it will also get support for more tags in the (near) future. Additionally it currently only prints the transformed result to STDOUT. The plan is to also support inline editing, either with an -i option or maybe even by default if it detects that the package is maintained in git. Please give me feedback if this approach (especially after inline editing is supported) is feasible — preferably from those who are annoyed. :-) It's not yet in the master branch as neither Perl::Critic nor myself are happy about the usage of (the expression form of) "eval" in there. (Maybe one of the other JAPH has an idea on this. :-) Patches and other improvements suggestions as well as pattern sets for further tags are of course welcome as well. (Note: I will probably force-push that feature branch over and over again until I'm satisfied. If someone else wants to work on the same branch, too, we can also work without forced pushes and squash-merge the result at the end. Please contact me, if you're interested.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
[Git][lintian/lintian] Pushed new branch migrate-overrides
Axel Beckert pushed new branch migrate-overrides at lintian / lintian -- View it on GitLab: https://salsa.debian.org/lintian/lintian/-/tree/migrate-overrides You're receiving this email because of your account on salsa.debian.org.
Processed: Bug#1007002 marked as pending in lintian
Processing control commands: > tag -1 pending Bug #1007002 [lintian] lintian: transition to "pointed hints" has invalidated many overrides Added tag(s) pending. -- 1007002: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007002 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Bug#1014057 marked as pending in lintian
Processing control commands: > tag -1 pending Bug #1014057 [lintian] lintian man page: bad default for --color Added tag(s) pending. -- 1014057: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014057 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1007002: Lintian breaks existing lintian-overrides due to added []
Hi Lucas, Lucas Nussbaum wrote: > Just a note that since the last version of lintian to migrate to testing > was 2.111 (which was also the last one to be backported to stable), some > of us might not have updated since 2.111 and might be hit by changes > that happened since then. Oh, right! Thanks for that view on Andreas' mail. I indeed did not think about that case because I do nearly all Debian development work on Unstable (and occassionally on Stable when a new package starts as a quick and dirty hack to scratch my own itches at work :-). And until my reply to Andreas I also wasn't aware of when Felix actually started with this. Just knew that it wasn't a one-shot thing, but quite distributed over at least the past half year (because that's the timeframe of git commits I most often looked into in the past few weeks). Andreas: Sorry if I was a bit too opposing because of assuming that every DD uses Unstable by default. (Actually I think the Dev Ref says you should, though. ;-) Or if DDs pinned Lintian to 2.111.0 from Testing… Andreas Tille wrote: > I'll start editing lintian-overrides then. Maybe wait a bit with that. Given Lucas' comment, I feel a bit more urged to provide such a migration script. I will look into this for the next upload. No promises as of now, though. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1007002: Lintian breaks existing lintian-overrides due to added []
On 29/06/22 at 15:49 +0200, Axel Beckert wrote: > Correct, except that it happened for quite a while (7 months at least) > and was (and maybe still is — see below) a continuous transition. It > is present since at least 2.114.0 from November 2021. According to the > git history, the implementation started shortly before the 2.114.0 > upload, but the bug report which requested this is actually from 2014: > https://bugs.debian.org/743226 > > And yes, 2.115.0 (but not 2.115.1 or 2.115.2 from today) had more such > changes as there were over 200 commits from Felix included which he > did after 2.114.0, but which weren't uploaded since then. Hi Axel, Just a note that since the last version of lintian to migrate to testing was 2.111 (which was also the last one to be backported to stable), some of us might not have updated since 2.111 and might be hit by changes that happened since then. (I'm not arguing whether it should be kept or reverted, but I'm just mentioning this as other disruptive changes might be discovered in the coming days) Lucas signature.asc Description: PGP signature
Bug#1014057: lintian man page: bad default for --color
Package: lintian Version: 2.115.1 Severity: minor The Lintian man page says the default for --color is "never". It is actually "auto" since Lintian 2.5.22: + [NT] Let --color default to "auto". -- Jakub Wilk
Bug#1007002: Lintian breaks existing lintian-overrides due to added []
Hi Samuel and Axel, Am Wed, Jun 29, 2022 at 04:10:49PM +0200 schrieb Samuel Thibault: > Axel Beckert, le mer. 29 juin 2022 15:49:11 +0200, a ecrit: > > > I consider these [] not helpful […] no visible advantage. OK, thanks for making the advantages visible to me then. I'll start editing lintian-overrides then. Kind regards Andreas. -- http://fam-tille.de
Bug#1007002: Lintian breaks existing lintian-overrides due to added []
Hello, Axel Beckert, le mer. 29 juin 2022 15:49:11 +0200, a ecrit: > > I consider these [] not helpful […] no visible advantage. > > The advantage is to clearly mark what is a file with potentially a > line number in the output of lintian so that further processors like > the lintian website can do deep links to the proper code position on > e.g. sources.debian.org or salsa.debian.org. Felix called it "pointed > hints". > > From my point of view, that's quite an advantage. Yes, I fully agree. The format migration poses problem (I had to patch quite a few lintian files), but it solves a lot other current-and-future problems: we can now just ignore whole sets of warnings for a given file (typically one that is generated by some tool such as doxygen) Samuel
Bug#1007002: Lintian breaks existing lintian-overrides due to added []
Hi Andreas, Andreas Tille wrote: > I realised that lintian (at least) starting with version 2.115.1 (may be > earlier) wraps file names into [] which breaks existing > lintian-overrides. Correct, except that it happened for quite a while (7 months at least) and was (and maybe still is — see below) a continuous transition. It is present since at least 2.114.0 from November 2021. According to the git history, the implementation started shortly before the 2.114.0 upload, but the bug report which requested this is actually from 2014: https://bugs.debian.org/743226 And yes, 2.115.0 (but not 2.115.1 or 2.115.2 from today) had more such changes as there were over 200 commits from Felix included which he did after 2.114.0, but which weren't uploaded since then. Many of them were (IMHO irresponsibly) marked "Gbp-Dch: Ignore" and hence didn't show up in debian/changelog when I generated it with "gbp dch". (I though ignored that in some cases and added them manually to the debian/changelog entry, partially even retroactively.) > I consider these [] not helpful […] no visible advantage. The advantage is to clearly mark what is a file with potentially a line number in the output of lintian so that further processors like the lintian website can do deep links to the proper code position on e.g. sources.debian.org or salsa.debian.org. Felix called it "pointed hints". From my point of view, that's quite an advantage. See also https://bugs.debian.org/1007002 for the proper bug report about the issue with invalidating overrides by this transition. I've added it to the Cc of this thread and dropped lintian-ma...@debian.org instead as mails to that bug report get forwarded to the Lintian Team anyway. > since it breaks lots of lintian-overrides Felix decided that it's worth to implement this requested feature and I at least partially agree as I do clearly see the advantage and also like the possibilities which this now offers. > Could this change in lintian please be reverted? I clearly won't do that — for multiple reasons: * Far too much work for the gain (IMHO) * Losing a requested feature. * Invalidating 7 months of already updated overrides. * Better ways to invest your (and my) time. (See my proposition below.) Background: This seems not to have been one big commit but many small commits whenever a tag was touched by Felix. Reverting it to the old format would be a huge effort for which I don't have the time as there are way more pressing issues in lintian. And I'm very sure it can't be done by just doing a bunch of "git revert". So far I found 15 commits by Felix mentioning "pointed hint" reaching from November 2021 to March 2022. With about 200 other, partially quite invasive commits inbetween. And in addition to that, it's IMHO _far_ too late, because many maintainers already have updated their overrides in the past 7 months. And I'm currently not sure if I would even accept a Merge Request which tries to do that. But I doubt that anyone would a) make that effort and b) make all those maintainers angry who already updated their overrides in the past 7 months or more. Roberto C. Sánchez wrote: > Or perhaps make the new format default That was Felix' plan, yes. I just have currently no idea how many tags have been and how many haven't been converted yet. If there aren't too many tags left, I might finish this transition. If there are many tags left, I'd only do that if we have a way to cope with it with much less effort than it so far caused. And from my point of view, the only way to get out of this mess without causing too much work for anyone (maintainers of packages with affected overrides as well as the current Lintian maintainers): Someone should write a converter from the old to the new format. That doesn't sound too difficult. Main work would be gathering for each tag involved how it looked beforehand and how it looked now. This probably can be gathered from changes in git to Lintian's test suite. And maybe it should even try to output overrides which are compatible with the old and new format, at least in cases where the order of parameters didn't change. See lintian's own overrides for some examples: https://salsa.debian.org/lintian/lintian/-/blob/master/debian/source/lintian-overrides (Although this also accounts for a bug which only ever was present in Lintian's git repository and never got uploaded, but still got an RC bug report because people started using lintian off the git repo due to it no having been maintained for months: https://bugs.debian.org/1003353) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Re: Lintian breaks existing lintian-overrides due to added []
On Wed, Jun 29, 2022 at 02:49:35PM +0200, Andreas Tille wrote: > Hi, > > I realised that lintian (at least) starting with version 2.115.1 (may be > earlier) wraps file names into [] which breaks existing > lintian-overrides. Random example: > > > https://salsa.debian.org/med-team/biomaj3-user/-/blob/master/debian/lintian-overrides > > now becomes invalid by lintian claiming > > W: python3-biomaj3-user: mismatched-override script-with-language-extension > usr/bin/biomaj-users.py [usr/share/lintian/overrides/python3-biomaj3-user:2] > W: python3-biomaj3-user: script-with-language-extension > [usr/bin/biomaj-users.py] > > I consider these [] not helpful since it breaks lots of > lintian-overrides with no visible advantage. Could this change in > lintian please be reverted? Or perhaps make the new format default (I quite like it better from a visual perspective), and issue a deprecation warning for the old format (e.g., when -I is specified). Then perhaps after the next stable release drop the old format. > > Thanks a lot for maintaining lintian in any case > +1 Regards, -Roberto -- Roberto C. Sánchez
Processed: unarchiving 974641, reopening 974641
Processing commands for cont...@bugs.debian.org: > # I agree with Lucas, not with Felix > unarchive 974641 Bug #974641 {Done: Felix Lechner } [lintian] lintian: classification tag for test suite Unarchived Bug 974641 > reopen 974641 Bug #974641 {Done: Felix Lechner } [lintian] lintian: classification tag for test suite Bug reopened Ignoring request to alter fixed versions of bug #974641 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 974641: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974641 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Lintian breaks existing lintian-overrides due to added []
Hi, I realised that lintian (at least) starting with version 2.115.1 (may be earlier) wraps file names into [] which breaks existing lintian-overrides. Random example: https://salsa.debian.org/med-team/biomaj3-user/-/blob/master/debian/lintian-overrides now becomes invalid by lintian claiming W: python3-biomaj3-user: mismatched-override script-with-language-extension usr/bin/biomaj-users.py [usr/share/lintian/overrides/python3-biomaj3-user:2] W: python3-biomaj3-user: script-with-language-extension [usr/bin/biomaj-users.py] I consider these [] not helpful since it breaks lots of lintian-overrides with no visible advantage. Could this change in lintian please be reverted? Thanks a lot for maintaining lintian in any case Andreas. -- http://fam-tille.de
Bug#1014045: source-is-missing doesn't seem to understand docbook
Package: lintian Version: 2.115.1 Severity: normal The latest lintian versions are throwing a lot of these errors on postgresql-15: E: postgresql-15 source: source-is-missing [doc/src/sgml/html/acronyms.html] N: The source of the following file is missing. Lintian checked a few possible paths to find the source, and did not find it. E: postgresql-15 source: source-is-missing [doc/src/sgml/html/admin.html] E: postgresql-15 source: source-is-missing [doc/src/sgml/html/adminpack.html] E: postgresql-15 source: source-is-missing [doc/src/sgml/html/amcheck.html] E: postgresql-15 source: source-is-missing [doc/src/sgml/html/app-clusterdb.html] ... But the source is right there one level up: $ ls -l doc/src/sgml/html/acronyms.html -rw-r--r-- 1 cbe cbe 21242 27. Jun 22:15 doc/src/sgml/html/acronyms.html $ ls -l doc/src/sgml/acronyms.sgml -rw-r--r-- 1 cbe cbe 19714 27. Jun 22:11 doc/src/sgml/acronyms.sgml Am I supposed to override these? Christoph