Processed: Bug#755153 marked as pending in lintian
Processing control commands: > tag -1 pending Bug #755153 [lintian] lintian: Add tag encouraging patches to be forwarded upstream Added tag(s) pending. -- 755153: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755153 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#962601: manpage-section-mismatch doesn't take into account manpages with multiple binaries
On Wednesday, July 08 2020, Felix Lechner wrote: > On Wed, Jul 8, 2020 at 7:41 PM Sergio Durigan Junior > wrote: >> >> I honestly don't feel like spending >> too much time investigating Perl's internals > > What does it have to do with Perl's internals, please? Well, according to ParseWords's documentation: https://perldoc.perl.org/Text/ParseWords.html parse_line should take a line ($line, in our case), a delimeter (\s+, in our case), and split the line into tokens respecting the delimeters. It is obviously not working the way it should when there is a backslash in the middle of the line, which is strange. I'm not saying there is a bug in the implementation, but, in this specific scenario, the documentation doesn't reflect what really happens (that is, the function doesn't return the expected tokens). >> What do you think? > > Would Text::Balanced help extract the quoted strings, and work from there? I don't know. As I said, Perl is not my specialty. But the problem here is not just removing the backslash; the real problem is that the title of the manpage (the first element in the .TH header) contains an \FB in the beginning, which seems to be wrong (there is no \fR in the line, and man doesn't render the title in bold, ignoring the \fB). Not mentioning the backslash at the end of the title, which (erroneously) escapes the double quote. I don't have the time right now to play a bit with Text::Balanced and see what comes out of it, so if you're not satisfied with the solution I proposed, my other suggestion would be to revert the original patch (and reintroduce the bug I fixed with it, of course) until we can figure out how to tackle this issue. Cheers, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Bug#962601: manpage-section-mismatch doesn't take into account manpages with multiple binaries
Hi On Wed, Jul 8, 2020 at 7:41 PM Sergio Durigan Junior wrote: > > I honestly don't feel like spending > too much time investigating Perl's internals What does it have to do with Perl's internals, please? > What do you think? Would Text::Balanced help extract the quoted strings, and work from there? Kind regards Felix Lechner
Bug#962601: manpage-section-mismatch doesn't take into account manpages with multiple binaries
On Wednesday, July 08 2020, Felix Lechner wrote:
> Hi Sergio,
Hey Felix,
> On Wed, Jun 10, 2020 at 9:57 AM Sergio Durigan Junior
> wrote:
>>
>> after calling Text::ParseWords::parse_line, we check to
>> see if the first package name has a comma as the last char. If it does,
>> then we assume that there will be at least one other package name
>> listed, and advance an index. When we reach a package name whose last
>> char is not a comma, we then assume that the next field is the manpage
>> section number.
>
> Something in that patch is not quite working. I previously added a
> safeguard for an undefined value warning, but that was not enough:
>
>
> https://salsa.debian.org/lintian/lintian/-/commit/d3c64d8ab40de6e38c96334e2515550df1957a4a
>
> In an archive-wide run, the modified patch still produced the warnings
> below. I show the complete list for the record, and not to intimidate
> anyone. It's no big deal.
>
> You may want to check out kde-dev-scripts, which generated a lot of warnings.
Ouch, thanks for the report, and sorry about the breakage. My Perl-foo
is very limited.
So, I think I found the problem, and I have a possible solution.
Apparently, some manpages have malformed .TH headers, and Perl's
Text::ParseWords::parse_line doesn't cope well with them. For example,
kde-dev-scripts's /usr/share/man/ca/man1/create_makefiles.1.gz file has:
.TH "\FBCREATE_MAKEFILES\" "1" "8 de mar\(,c del 2003" "[FIXME: source]"
"[FIXME: manual]"
Not pretty, huh? If we make simple Perl program to try to parse this
line:
use Text::ParseWords;
@words = parse_line('\s+', 0, q{.TH "\FBCREATE_MAKEFILES\" "1" "8 de mar\(,c
del 2003" "[FIXME: source]" "[FIXME: manual]"});
$i = 0;
foreach (@words) {
print "$i: <$_>\n";
$i++;
}
and run it, you will noticed that it doesn't return anything! Now, if
we tweak the line a little bit, by removing some of the backslashes for
example, we start getting somewhere:
...
@words = parse_line('\s+', 0, q{.TH "FBCREATE_MAKEFILES" "1" "8 de mar\(,c
del 2003" "[FIXME: source]" "[FIXME: manual]"});
...
Now run it:
$ perl parseline.pl
0: <.TH>
1:
2: <1>
3: <8 de mar(,c del 2003>
4: <[FIXME: source]>
5: <[FIXME: manual]>
So yeah, there's a problem here. I honestly don't feel like spending
too much time investigating Perl's internals, so I think it's possible
to detect when parse_line failed and act accordingly.
I'm attaching a patch that does just that, and prevents the
warnings/failures from happening. The idea is to check whether the size
of the @th_fields array is bigger than 0, and just perform the checks if
they are. I also took the liberty to remove the // EMPTY part, because
it shouldn't be necessary anymore.
What do you think?
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/
diff --git a/checks/documentation/manual.pm b/checks/documentation/manual.pm
index b30bf6081..350dee927 100644
--- a/checks/documentation/manual.pm
+++ b/checks/documentation/manual.pm
@@ -297,21 +297,23 @@ sub files {
next if $line =~ /^\.\\\"/; # comments .\"
if ($line =~ /^\.TH\s/) { # header
my @th_fields= Text::ParseWords::parse_line('\s+', 0, $line);
-my $pkgname_idx = 1;
-# Iterate over possible package names. If there is
-# more than one, they will be separated by a comma and
-# a whitespace. In case we find the comma, we advance
-# $pkgname_idx.
-while ((substr($th_fields[$pkgname_idx], -1) // EMPTY) eq ','){
-$pkgname_idx++;
-}
-# We're now at the last package, so we should be able
-# to obtain the manpage section number by incrementing
-# 1 to the index.
-my $th_section = $th_fields[++$pkgname_idx];
-if ($th_section && (lc($fn_section) ne lc($th_section))) {
-$self->tag('wrong-manual-section',
-"$file:$lc $fn_section != $th_section");
+if ($#th_fields > 0) {
+my $pkgname_idx = 1;
+# Iterate over possible package names. If there is
+# more than one, they will be separated by a comma and
+# a whitespace. In case we find the comma, we advance
+# $pkgname_idx.
+while ((substr($th_fields[$pkgname_idx], -1)) eq ','){
+$pkgname_idx++;
+}
+# We're now at the last package, so we should be able
+# to obtain the manpage section number by incrementing
+# 1 to the index.
+my $th_section = $th_fields[++$pkgname_idx];
+if ($th_section && (lc($fn_section) ne lc($th_section))) {
+
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#964281: marked as pending in lintian
Hi Felix, Felix Lechner wrote: > > Huh? I've never seen such a line. > > Do you use 'quilt header -e --dep3' ? Never seen that command, neither the "header" subcommand nor these options. I think I'm using quilt for like 12 or 13 years — which seems a few years longer than DEP3 exists. And I probably never checked if some kind of DEP3 support was added to it. I always write my DEP3 headers by hand according to the DEP3 specification. And this > > > This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ doesn't look like being RFC822-conforming due to the blanks in the key part. So I'm kinda suprised that this is even in there. I also can't find it in the DEP3 specification at https://dep-team.pages.debian.net/deps/dep3/ so from my point of view, this is _NO_ common nor a specified part of a DEP3 header. 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#964281: marked as pending in lintian
Hi Axel, On Wed, Jul 8, 2020 at 5:45 PM Axel Beckert wrote: > > Huh? I've never seen such a line. Do you use 'quilt header -e --dep3' ? Kind regards Felix Lechner
Bug#964281: marked as pending in lintian
Hi Felix,
Felix Lechner wrote:
> The patch change-national-encoding-to-utf-8.patch in the wml package
> did not have the nice notice added by quilt:
>
> This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Huh? I've never seen such a line. And I'm using quilt a lot on the
commandline. It's either very new or not generated by any of the quilt
commands usually in my workflow (quilt subcommands add, edit, new and
refresh). But then again that patch was generated by quilt on Debian
Unstable just a few days ago using "quilt new", "quilt add" (maybe
"quilt edit" instead) and "quilt refresh" IIRC.
> Now the check splits on '^--- ', which is presumably what the patch
> program does before applying a diff.
This is what I'd have expected. Potentially it should split on
'^Index: ', too, as that belongs to some patch formats, IIRC those
emitted by some git commands. ("quilt refresh" usually removes those
lines, though.)
> The wml package no longer emits the tag:
>
> % ./frontend/lintian /mirror/debian/pool/main/w/wml/wml_2.28.0\~ds1-1.dsc
> I: wml source: unused-override national-encoding
> debian/patches/change-national-encoding-to-utf-8.patch
Yay!
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
Processed: Bug#964281 marked as pending in lintian
Processing control commands: > tag -1 pending Bug #964281 [lintian] lintian: tag national-encoding emitted for patches fixing this tag Added tag(s) pending. -- 964281: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964281 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#962601: manpage-section-mismatch doesn't take into account manpages with multiple binaries
Processing control commands:
> reopen -1
Bug #962601 {Done: Chris Lamb } [lintian]
manpage-section-mismatch doesn't take into account manpages with multiple
binaries
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions lintian/2.81.0.
--
962601: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962601
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#962601: manpage-section-mismatch doesn't take into account manpages with multiple binaries
Control: reopen -1 Hi Sergio, On Wed, Jun 10, 2020 at 9:57 AM Sergio Durigan Junior wrote: > > after calling Text::ParseWords::parse_line, we check to > see if the first package name has a comma as the last char. If it does, > then we assume that there will be at least one other package name > listed, and advance an index. When we reach a package name whose last > char is not a comma, we then assume that the next field is the manpage > section number. Something in that patch is not quite working. I previously added a safeguard for an undefined value warning, but that was not enough: https://salsa.debian.org/lintian/lintian/-/commit/d3c64d8ab40de6e38c96334e2515550df1957a4a In an archive-wide run, the modified patch still produced the warnings below. I show the complete list for the record, and not to intimidate anyone. It's no big deal. You may want to check out kde-dev-scripts, which generated a lot of warnings. Kind regards, Felix Lechner * * * Warning in group allegro5/2:5.2.6.0-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group babeltrace2/2.0.3-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group blender/2.82.a+dfsg-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group blender/2.83.1+dfsg-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group checkit-tiff/0.2.3-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group claws-mail/3.17.5-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group comptext/1.0.1-4: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group comptty/1.0.1-4: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group dballe/8.6-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group delay/1.0-5: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group derivations/0.56.20180123.1-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group gadmin-proftpd/1:0.4.2-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group git/1:2.27.0-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group git/1:2.27.0+next.20200625-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group git-repair/1.20200102-1: Use of uninitialized value $th_fields[1] in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group gmic/2.4.5-1.1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group guymager/0.8.12-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group kde-dev-scripts/4:18.08.0-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group libapache2-mod-qos/11.63-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group lavacli/1.0-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group lava/2020.06-2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group lirc/0.10.1-6.2: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group lksctp-tools/1.0.18+dfsg-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group lxqt-config/0.14.1-4: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group manpages/5.07-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group manpages-ja/0.5.0.0.20180315+dfsg-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group manpages-zh/1.6.3.4-1: Use of uninitialized value in substr at /lcl/lechner/lintian/git/checks/documentation/manual.pm line 305. Warning in group mariadb-10.3/1:10.3.23-1: Use of uninitialized value in substr at /lcl/lechner/li
Re: Reassigning multiple bugs for shell script analysis from Lintian
> > 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? Just noticed you were talking about custom checks, as I mentioned in the last part of my previous email, I think custom checks are an extra, so this requirement could be dropped (though I'm not the person working on this) and the default checks could be implemented. Regards, -- Samuel Henrique
Re: Reassigning multiple bugs for shell script analysis from Lintian
Hello all, sorry for the late reply, > Felix Lechner > 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. If I understood correctly, your intent is to create a wishlist bug to shellcheck, but I don't understand what would be the (active) role of shellcheck in this, could you clarify? > 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? > Ralf Treinen > what I can do is look through the bug reports blocked by #629247, > create whishlist bug reports for them on the lintshell project on gitlab I couldn't find this lintshell project, would you mind to give some references? It's the first time I'm hearing about it. 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. 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. Regards, -- Samuel Henrique
Processed: Re: Bug#964281 closed by Debian FTP Masters (reply to Chris Lamb ) (Bug#964281: fixed in lintian 2.83.0)
Processing control commands:
> reopen -1
Bug #964281 {Done: Chris Lamb } [lintian] lintian: tag
national-encoding emitted for patches fixing this tag
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions lintian/2.83.0.
> found -1 2.83.0
Bug #964281 [lintian] lintian: tag national-encoding emitted for patches fixing
this tag
Marked as found in versions lintian/2.83.0.
--
964281: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964281
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#964281: closed by Debian FTP Masters (reply to Chris Lamb ) (Bug#964281: fixed in lintian 2.83.0)
Control: reopen -1 Control: found -1 2.83.0 Hi Felix, Debian Bug Tracking System wrote: >* Only check the DEP-3 header for legacy encodings in debian/patches. > (Closes: #964281) Seems not to work as expected yet. You can try it with src:wml as currently in Debian Unstable or as in git on https://salsa.debian.org/debian/wml. $ lintian -iIE --pedantic wml_2.28.0~ds1-2_amd64.changes W: wml source: national-encoding DEP-3 header debian/patches/change-national-encoding-to-utf-8.patch But the patch has not a single (visible) 8-bit character in there. I also attached the full patch in question. Hopefully it survives the mail as it contains a mixture of different encodings. I compressed it with gzip in the hope it avoids these kind of issues. :-) Here's the DEP3 header of that patch (copy and paste from a "cat" inside an xterm) though: Description: Change national encoding to UTF-8. Prompted by Lintian. Author: Axel Beckert Forwarded: no --- a/COPYRIGHT.OTHER +++ b/COPYRIGHT.OTHER [...] I hope these details help to find the culprit. Thanks again for caring and for the initial try to fix this! 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#964381: marked as done (lintian: Detecting bogus email address)
Your message dated Wed, 8 Jul 2020 21:29:11 +1000 with message-id and subject line Re: Bug#964381: lintian: Detecting bogus email address has caused the Debian Bug report #964381, regarding lintian: Detecting bogus email address to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 964381: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964381 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lintian Version: 2.82.0 Severity: normal Dear Maintainer, Since commit 6dda6b02dc83b454a576717c888307df1f2ebbb6, lintian has detected two identical entries in yaz's debian/changelog as bogus. The entries are adam@flurry.index. I'm not sure how to address this. Should I ignore lintian, override the tag or change the problem email addresses to the upstream author's actual email address (also found all over the changelog)? -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.34-8 ii bzip2 1.0.8-3 ii diffstat 1.63-1 ii dpkg 1.20.3 ii dpkg-dev 1.20.3 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+b3 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl 0.48-1 ii libclass-xsaccessor-perl 1.19-3+b5 ii libclone-perl 0.45-1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl4.19-1 ii libdata-validate-domain-perl 0.10-1 ii libdevel-size-perl0.83-1+b1 ii libdpkg-perl 1.20.3 ii libemail-address-xs-perl 1.04-1+b2 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl0.34-1 ii libfont-ttf-perl 1.06-1 ii libhtml-parser-perl 3.72-5 ii libio-async-loop-epoll-perl 0.21-1 ii libio-async-perl 0.77-3 ii libjson-maybexs-perl 1.004002-1 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl0.416-1+b5 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 libsereal-decoder-perl4.014+ds-1 ii libsereal-encoder-perl4.014+ds-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3300-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl 1.010002-1 ii libunicode-utf8-perl 0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl2.0134+dfsg-2 ii libxml-writer-perl0.625-1 ii libyaml-libyaml-perl 0.82+repack-1 ii man-db2.9.3-2 ii patchutils0.3.4-3 ii perl [libdigest-sha-perl] 5.30.3-4 ii t1utils 1.41-4 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: pn binutils-multiarch pn libtext-template-perl -- no debconf information --- End Message --- --- Begin Message --- On Wed, 8 Jul 2020 at 01:52, Felix Lechner wrote: > Adam confirmed via private email that changing the address is okay. An > internal address appeared by mistake. Thanks for following this up, Felix. I've pushed the relevant commit to the yaz repo on salsa. > Alternatively, you could wait until a new version of > Data::Validate::Domain is uploaded. At that point, the TLD validation > will probably be turned off (although it worked well in your case). > The use of that feature is worth a discussion somewhere. Indeed. It did catch this issue, so it definitely seems useful. > Please feel free to close this bug report. Will do. Thanks again.--- End Message ---
Bug#964539: qa.debian.org: man-pages.wml uses lintian.log that went away
Package: qa.debian.org X-Debbugs-Cc: lint...@packages.debian.org This seems to be the only service under qa.d.o that used lintian.log. lintian.log hasn't existed for several months, and now I went and removed our copy on quantz. We should move this service to the replacement facility the lintian maintainers will provide in the future (the voices mention some json file…). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#769066: lintian: Consider processing files in disk order
On Tue, Jul 07, 2020 at 06:34:05PM -0700, Felix Lechner wrote: > Hi, > > > access files in disk order to increase performance > > What was the speedup in man-db and dpkg, please? ~70% speedup in reinstalling a simple package using dpkg (27 seconds to 8 seconds): https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=8e31b0f0fb6b14e605407b824f4e2f1b0c12bab6 ~69% speedup in "mandb -c" (104 seconds to 32 seconds), and ~49% speedup in "man -K" (74 seconds to 38 seconds): https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=daee555135fbdca3c084a06dd3e1156f9ede24b8 This was all on rotational disks. I expect SSDs would change things a lot, though I don't think this sort of thing *hurts* on SSDs. -- Colin Watson (he/him) [cjwat...@debian.org]
Processed: py2removal bugs severity updates - 2020-07-08 07:00:39.510986+00:00
Processing commands for cont...@bugs.debian.org: > # This is an automated script, part of the effort for the removal of Python 2 > from bullseye > # * https://wiki.debian.org/Python/2Removal > # * http://sandrotosi.me/debian/py2removal/index.html > # See https://lists.debian.org/debian-devel-announce/2019/11/msg0.html > # and https://lists.debian.org/debian-python/2019/12/msg00076.html > # and https://lists.debian.org/debian-python/2020/03/msg00087.html > # mail threads for more details on this severity update > # not all bin pkgs are leaf for src:archivemail, lower severity > severity 936146 normal Bug #936146 [src:archivemail] archivemail: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 936146 to the same value. > # not all bin pkgs are leaf for src:aseba, lower severity > severity 936152 normal Bug #936152 [src:aseba] aseba: Python2 removal in sid/bullseye Severity set to 'normal' from 'serious' > # not all bin pkgs are leaf for src:astk, lower severity > severity 936159 normal Bug #936159 [src:astk] astk: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 936159 to the same value. > # not all bin pkgs are leaf for src:battery-stats, lower severity > severity 936187 normal Bug #936187 [src:battery-stats] battery-stats: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 936187 to the same value. > # not all bin pkgs are leaf for src:firefox-esr, lower severity > severity 936516 normal Bug #936516 [src:firefox-esr] firefox-esr: Python2 removal in sid/bullseye Severity set to 'normal' from 'serious' > # not all bin pkgs are leaf for src:flup, lower severity > severity 936535 normal Bug #936535 [src:flup] flup: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 936535 to the same value. > # not all bin pkgs are leaf for src:fritzing-parts, lower severity > severity 936562 normal Bug #936562 [src:fritzing-parts] fritzing-parts: Python2 removal in sid/bullseye Severity set to 'normal' from 'serious' > # not all bin pkgs are leaf for src:gnumeric, lower severity > severity 936632 normal Bug #936632 [src:gnumeric] gnumeric: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 936632 to the same value. > # not all bin pkgs are leaf for src:grokmirror, lower severity > severity 936665 normal Bug #936665 [src:grokmirror] grokmirror: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 936665 to the same value. > # not all bin pkgs are leaf for src:isospec, lower severity > severity 936752 normal Bug #936752 [src:isospec] isospec: Python2 removal in sid/bullseye Severity set to 'normal' from 'serious' > # not all bin pkgs are leaf for src:jython, lower severity > severity 936776 normal Bug #936776 [src:jython] jython: Python2 removal in sid/bullseye Severity set to 'normal' from 'serious' > # not all bin pkgs are leaf for src:ketchup, lower severity > severity 936785 normal Bug #936785 [src:ketchup] ketchup: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 936785 to the same value. > # not all bin pkgs are leaf for src:libaria, lower severity > severity 936842 normal Bug #936842 [src:libaria] libaria: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 936842 to the same value. > # not all bin pkgs are leaf for src:libgnatcoll-python, lower severity > severity 936869 normal Bug #936869 [libgnatcoll-python] libgnatcoll-bindings: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 936869 to the same value. > # not all bin pkgs are leaf for src:libwfut, lower severity > severity 936939 normal Bug #936939 [src:libwfut] libwfut: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 936939 to the same value. > # not all bin pkgs are leaf for src:macsyfinder, lower severity > severity 936977 normal Bug #936977 [src:macsyfinder] macsyfinder: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 936977 to the same value. > # not all bin pkgs are leaf for src:nekobee, lower severity > severity 937126 normal Bug #937126 [src:nekobee] nekobee: Python2 removal in sid/bullseye Severity set to 'normal' from 'serious' > # not all bin pkgs are leaf for src:ola, lower severity > severity 937186 normal Bug #937186 [src:ola] ola: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 937186 to the same value. > # not all bin pkgs are leaf for src:open-build-service, lower severity > severity 937193 normal Bug #937193 [src:open-build-service] open-build-service: Python2 removal in sid/bullseye Severity set to 'normal' from 'serious' > # not all bin pkgs are leaf for src:opencaster, lower severity > severity 937194 normal Bug #937194 [src:opencaster] opencaster: Python2 removal in sid/bullseye Ignoring request to change severity of Bug 937194 to the same value. > # not all bin pkgs are leaf for src:openjfx, lower severity > severity 937202 normal Bug #937
