Bug#827060: [opensmtpd] Please see Salsa MR for fixed copyright

[Felix Lechner]

Control: reassign -1 opensmtpd
Control: submitter -1 !
Control: retitle -1 [opensmtpd] Please fix d/copyright [patch]
Control: severity -1 wishlist
Control: tag -1 + patch

Hi,

I believe the tags 'missing-license-paragraph-in-dep5-copyright' that
you reported as false positives are in fact correct due to a possible
misunderstanding of the DEP-5 specification. Please find a fixed
copyright in this merge request on Salsa:

 https://salsa.debian.org/debian/opensmtpd/merge_requests/1

In the MR, I also removed the unused Lintian overrides and adjusted a
spelling-related override.

The DEP-5 specifications [2] is not very clear, and Lintian is
occasionally accused of being too strict or too severe with related
tags. (#779676) Measured against the sheer number of copyright files
in the archive, however, we receive very few complaints.

I know little about DEP-5, but I do know what works with Lintian. In
your case, you referred to multiple and also different texts as
'permissive' or 'additional-restrictions', which is not allowed. You
also used the keyword 'and' informally without tying together two
separate, "stand-alone" license stanzas.

Either way, locally Lintian issued no more copyright tags after I
applied my merge request to your git repo. That's why I assigned the
bug to your package. Please feel free to reassign back to Lintian if
you think I was mistaken.

Kind regards,
Felix

[1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Processed: [opensmtpd] Please see Salsa MR for fixed copyright

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 opensmtpd
Bug #827060 [lintian] false positive for 
missing-license-paragraph-in-dep5-copyright
Bug reassigned from package 'lintian' to 'opensmtpd'.
No longer marked as found in versions lintian/2.5.44.
Ignoring request to alter fixed versions of bug #827060 to the same values 
previously set
> submitter -1 !
Bug #827060 [opensmtpd] false positive for 
missing-license-paragraph-in-dep5-copyright
Changed Bug submitter to 'Felix Lechner ' from 
'Ryan Kavanagh '.
> retitle -1 [opensmtpd] Please fix d/copyright [patch]
Bug #827060 [opensmtpd] false positive for 
missing-license-paragraph-in-dep5-copyright
Changed Bug title to '[opensmtpd] Please fix d/copyright [patch]' from 'false 
positive for missing-license-paragraph-in-dep5-copyright'.
> severity -1 wishlist
Bug #827060 [opensmtpd] [opensmtpd] Please fix d/copyright [patch]
Severity set to 'wishlist' from 'normal'
> tag -1 + patch
Bug #827060 [opensmtpd] [opensmtpd] Please fix d/copyright [patch]
Added tag(s) patch.

-- 
827060: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827060
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Cron lintian/reporting/harness -i

[Lintian role account]

Warning: unable to close filehandle properly: No space left on device during 
global destruction.

Bug#907727: Empty directory is already present in orig tarball

[Felix Lechner]

On Sat, Aug 10, 2019 at 4:51 PM Russ Allbery  wrote:
>
> I don't think there was anything specific to
> git-buildpackage there.

Isn't the whole problem specific to git-buildpackage?

> The result is that the patches-applied Debian
> packaging tree is then representable in Git, which did seem mildly
> superior to recreating the directory in debian/rules if it had disappeared
> due to a round trip through Git.

I would prefer not to add such an obscure patch to 11,000 packages. Is
it really sufficient to create the directories in d/rules?

> I can think of a situation where it
> could mask an obscure bug: if the upstream build system expects to be able
> to write to that directory without creating it first, this will work
> correctly if the upstream tarball is unpacked, the Debian unpacked over
> it, and then debian/rules run.  But if a Git import happens in the middle
> of that process, the package will then fail to build.

That is a bug in our tools, not in upstream's delivery. Besides,
couldn't you patch the upstream build system?

> Given that, I can see some merit to adding a file to that directory in the
> Debian package or otherwise arranging for that directory to be recreated.

Why not let 'dh' take care of it via a newly added d/empty-dirs? It
would be more explicit and self-explanatory.

> It's a kind of annoying problem otherwise since whether or not it's
> reproducible depends on whether one checks the package into (or out of)
> Git or just unpacks it directly, something that most people wouldn't
> expect to make a difference.

Exactly, it's a bug in our tools. Perhaps even in git. I am sure it's
been discussed and discarded.

> If [the tag] had gone away once I added a file to
> that directory in the packaging, I would have been quite happy with the
> tag and its recommendation.

Let's not jump to conclusions, then. We will find a good solution.

Kind regards,
Felix

Bug#907727: Empty directory is already present in orig tarball

[Russ Allbery]

Felix Lechner  writes:

> Please forgive me. I misunderstood your original filing.

Oh, it's no problem!  Apologies if I came across as upset.  I think I
didn't phrase my reply very well.

> Well, I do not use git-buildpackage, and such an intricate and obscure
> solution does nothing for me.

To be clear, all I did was add a placeholder file to that directory in the
Debian packaging (which because I'm using 3.0 quilt means that it gets
included in the diff).  I don't think there was anything specific to
git-buildpackage there.  The result is that the patches-applied Debian
packaging tree is then representable in Git, which did seem mildly
superior to recreating the directory in debian/rules if it had disappeared
due to a round trip through Git.

> At the same time, I will continue to forward many items, such as
> spelling errors in manpages and binaries, to upstream. :)

Oh, sure, absolutely.

> I think the tag is wrong with or without more data. It appears in the
> archive 11,482 times, with 302 overrides. If there are no objections
> within a reasonable time frame (perhaps a month), I will propose to
> remove the tag from Lintian.

That also works for me.  That said, I can think of a situation where it
could mask an obscure bug: if the upstream build system expects to be able
to write to that directory without creating it first, this will work
correctly if the upstream tarball is unpacked, the Debian unpacked over
it, and then debian/rules run.  But if a Git import happens in the middle
of that process, the package will then fail to build.

Given that, I can see some merit to adding a file to that directory in the
Debian package or otherwise arranging for that directory to be recreated.
It's a kind of annoying problem otherwise since whether or not it's
reproducible depends on whether one checks the package into (or out of)
Git or just unpacks it directly, something that most people wouldn't
expect to make a difference.

So I'm not sure the Lintian tag is completely wrong (although pedantic is
probably the right severity).  If it had gone away once I added a file to
that directory in the packaging, I would have been quite happy with the
tag and its recommendation.

-- 
Russ Allbery (r...@debian.org)   

Cron lintian/reporting/harness --no-generate-reports -i

[Lintian role account]

Warning: unable to close filehandle properly: No space left on device during 
global destruction.

Bug#907727: Empty directory is already present in orig tarball

[Felix Lechner]

Hi Russ,

On Sat, Aug 10, 2019 at 3:36 PM Russ Allbery  wrote:
>
> I would like Lintian to stop complaining about this when a file is
> explicitly added to that directory by the packaging.  It's otherwise
> unactionable by the maintainer.

Please forgive me. I misunderstood your original filing.

I agree with you, and I have the same problem with my packages. The
burden of dealing with empty directories in upstream sources should be
placed on our tools. The recommendation, in the tag description, that
upstream should remove the directory is awful. I tried that once; it
was embarrassing. That part should be erased from the tag description.

> > Adding placeholder solely to your debianized sources
> > will not help.
>
> Why not?

I was just stating fact.

> why is that not a reasonable solution to
> the underlying problem ...
> The directory is now representable in Git and other
> directory-unaware views of the Debian package, since it now has a file in
> it.

Well, I do not use git-buildpackage, and such an intricate and obscure
solution does nothing for me. Perhaps the tag should be removed from
Lintian. A warning in git-buildpackage, if possible, would be more
appropriate.

> Maybe I should say explicitly that I think of Lintian as a linter for the
> *Debian packaging*, not a linter for the upstream package, so I'm a little
> dubious of tags that report purely upstream problems the Debian packager
> cannot fix without changing upstream.

I like that perspective very much. Thank you for sharing. Your comment
shall help guide me in the future.

At the same time, I will continue to forward many items, such as
spelling errors in manpages and binaries, to upstream. :)

> I can add an override if I need to, but I do feel like this tag is wrong
> in a way that Lintian *could* get right with more data.

I think the tag is wrong with or without more data. It appears in the
archive 11,482 times, with 302 overrides. If there are no objections
within a reasonable time frame (perhaps a month), I will propose to
remove the tag from Lintian.

> I totally understand if you don't think it's worth fixing, but I'm not
> sure what Lintian could reasonably expect me to do about it other than
> what I already did.

Sorry, my previous response was based on a misunderstanding. Your
concern is important, and you are right.

Kind regards,
Felix

Bug#907727: Empty directory is already present in orig tarball

[Russ Allbery]

Felix Lechner  writes:

> I don't think this is a bug in Lintian.

> The source tarball xfonts-jmk_3.0.orig.tar.gz contains an empty
> directory 'neep/ascii/':

> $ dget 
> http://deb.debian.org/debian/pool/main/x/xfonts-jmk/xfonts-jmk_3.0-22.dsc
> $ tar tf xfonts-jmk_3.0.orig.tar.gz
> . . .
> jmk-x11-fonts-3.0/neep/
> jmk-x11-fonts-3.0/neep/Makefile
> jmk-x11-fonts-3.0/neep/Makefile.chardesc
> jmk-x11-fonts-3.0/neep/Makefile.fonts
> jmk-x11-fonts-3.0/neep/Makefile.fonts.in
> jmk-x11-fonts-3.0/neep/Makefile.neep
> jmk-x11-fonts-3.0/neep/ascii/ <<
> jmk-x11-fonts-3.0/neep/fragments/
> jmk-x11-fonts-3.0/neep/fragments/Makefile
> . . .

> That triggers the tag when the file index for the orig tarball is examined:

> 
> https://salsa.debian.org/lintian/lintian/blob/master/checks/cruft.pm#L450-451

Yes.  That's the bug report.  :)

I would like Lintian to stop complaining about this when a file is
explicitly added to that directory by the packaging.  It's otherwise
unactionable by the maintainer.

> The comment in the tag description [1] about adding a placeholder to
> the directory "as needed" applies to upstream before they ship the
> orig tarball. Adding placeholder solely to your debianized sources
> will not help.

Why not?

Or, to be more precise, I understand that it doesn't suppress the Lintian
tag (hence the bug report), but why is that not a reasonable solution to
the underlying problem that prompted Lintian to complain about this in the
first place?  The directory is now representable in Git and other
directory-unaware views of the Debian package, since it now has a file in
it.

Maybe I should say explicitly that I think of Lintian as a linter for the
*Debian packaging*, not a linter for the upstream package, so I'm a little
dubious of tags that report purely upstream problems the Debian packager
cannot fix without changing upstream.

> With upstream defunct, wouldn't a Lintian override, or perhaps even a
> repacking of the source, be good options for you?

I can add an override if I need to, but I do feel like this tag is wrong
in a way that Lintian *could* get right with more data.  I tend to report
those as bugs rather than adding overrides (as opposed to cases where I
can't imagine a way for Lintian to be able to do better).

The tag is only pedantic, so it's not any sort of urgent or important bug
and I totally understand if you don't think it's worth fixing, but I'm not
sure what Lintian could reasonably expect me to do about it other than
what I already did.  Surely this isn't important enough to warrant
repacking the upstream tarball and thus breaking verifiable provenance?

-- 
Russ Allbery (r...@debian.org)   

Bug#926799: marked as done (lintian: hangs when dpkg-source fails)

[Debian Bug Tracking System]

Your message dated Sat, 10 Aug 2019 15:15:28 -0700
with message-id 

and subject line Lintian no longer hangs but exits gracefully, and provides a 
helpful error message
has caused the Debian Bug report #926799,
regarding lintian: hangs when dpkg-source fails
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.)


-- 
926799: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926799
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lintian
Version: 2.12.0~bpo9+1
Severity: normal

Hi,

While processing old packages, I noticed that lintian hangs on some of
them when dpkg-source fails to extract them.

Example, using:
http://snapshot.debian.org/archive/debian/20130509T215232Z/pool/main/u/usbredir/usbredir_0.6-2.dsc


$ lintian usbredir_0.6-2.dsc 
dpkg-source: error: expected ^--- in line 3 of diff 
'/tmp/temp-lintian-lab-vcUvBQH1iD/pool/u/usbredir/usbredir_0.6-2_source/unpacked/debian/patches/update-usbredirserver-whatis-entry.diff'
internal error: dpkg-source -x failed with status  2 at 
/usr/share/perl5/Lintian/Util.pm line 1177.
Lintian::Util::internal_error("dpkg-source -x failed with status ", 2) 
called at /usr/share/lintian/collection/unpacked line 74
Lintian::coll::unpacked::collect("usbredir", "source", 
"/tmp/temp-lintian-lab-vcUvBQH1iD/pool/u/usbredir/usbredir_0.6"...) called at 
/usr/share/perl5/Lintian/CollScript.pm line 242
Lintian::CollScript::collect(Lintian::CollScript=HASH(0x55d35d11c150), 
"usbredir", "source", 
"/tmp/temp-lintian-lab-vcUvBQH1iD/pool/u/usbredir/usbredir_0.6"...) called at 
/usr/share/perl5/Lintian/Unpacker.pm line 412
eval {...} called at /usr/share/perl5/Lintian/Unpacker.pm line 412
Lintian::Unpacker::__ANON__() called at 
/usr/share/perl5/IO/Async/Loop.pm line 1943
eval {...} called at /usr/share/perl5/IO/Async/Loop.pm line 1943
IO::Async::Loop::fork(IO::Async::Loop::Poll=HASH(0x55d35cb387b0), 
"code", CODE(0x55d35e922518), "on_exit", CODE(0x55d35e926f20)) called at 
/usr/share/perl5/Lintian/Unpacker.pm line 461
eval {...} called at /usr/share/perl5/Lintian/Unpacker.pm line 385
Lintian::Unpacker::__ANON__("unpacked-source:usbredir/0.6-2", 
Lintian::CollScript=HASH(0x55d35d11c150), 
Lintian::Lab::Entry=HASH(0x55d35c8280b0), 
Lintian::DepMap::Properties=HASH(0x55d35e8e05d8)) called at 
/usr/share/perl5/Lintian/Unpacker.pm line 476

Lintian::Unpacker::process_tasks(Lintian::Unpacker=HASH(0x55d35d1108d8), 
HASH(0x55d35c4e18b0)) called at /usr/share/lintian/commands/lintian.pm line 957
main::unpack_group("usbredir/0.6-2", 
Lintian::ProcessableGroup=HASH(0x55d35c827f48)) called at 
/usr/share/lintian/commands/lintian.pm line 730
main::__ANON__() called at /usr/share/lintian/commands/lintian.pm line 
1658
main::timed_task(CODE(0x55d35e9003b0)) called at 
/usr/share/lintian/commands/lintian.pm line 733
main::__ANON__() called at /usr/share/lintian/commands/lintian.pm line 
1658
main::timed_task(CODE(0x55d35e8f3fe8)) called at 
/usr/share/lintian/commands/lintian.pm line 762
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 114
dplint::run_tool("/usr/bin/lintian", "lintian") called at 
/usr/bin/lintian line 290
dplint::main() called at /usr/bin/lintian line 359
warning: collect info unpacked about package usbredir failed (512)
warning: skipping check of source package usbredir


I would expect lintian to exit with an error instead.

A list of packages for which it hang:

acpica-unix_20140424-1
cb2bib_1.4.4-3
cnews_cr.g7-37
cnews_cr.g7-38
cnews_cr.g7-39
cnews_cr.g7-40
cnews_cr.g7-40.1
cnews_cr.g7-40.2
cnews_cr.g7-40.4
dwm_6.0-3
dwm_6.0-5
dynare_4.2.1-2
flite_1.4-release-8
foremost_1.5.7-4
fslint_2.16-1
getfem++_4.1.1-10
getfem++_4.1.1-9
getfem++_4.1.1+dfsg1-11
getfem++_4.2+dfsg1-1
grpn_1.1.2-3.1
herculesstudio_1.3.0-2
hfsutils_3.2.6-12
icedove_3.0.11-2
katoob_0.5.9.1-3
katoob_0.5.9.1-4
katoob_0.5.9.1-4.1
kvpm_0.8.6-2
kvpm_0.8.6-3
lazarus_1.2~rc2+dfsg-1
lldpad_0.9.43+git20111215.c0498b-1
lldpad_0.9.44-1
lldpad_0.9.46-1
lldpad_0.9.46-2
lurker_2.3-4
lurker_2.3-4.1
lutefisk_1.0.7+dfsg-1
moodle_1.9.9.dfsg2-4
moodle_1.9.9.dfsg2-5
ncmpcpp_0.5.5-1
nsnake_1.5-1
ompl_0.13.0+git20130920.01d0ca4-1
ompl_0.14.1-1
opencryptoki_2.3.1+dfsg-1
openms_1.9.0-4
openms_1.9.0-4.1
openoffice-python_1:0.1+20110129-1
piwigo_2.3.1-1
puppet_2.7.17-1
python-virtualenv_1.7-1
python-webob_1.2.3-4
qemu_1.7.0+df

Processed: Re: source-contains-empty-directory when a patch adds a file to that directory

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 907727 + moreinfo
Bug #907727 [lintian] source-contains-empty-directory when a patch adds a file 
to that directory
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
907727: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907727
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#907727: Empty directory is already present in orig tarball

[Felix Lechner]

Hi Russ,

I don't think this is a bug in Lintian.

The source tarball xfonts-jmk_3.0.orig.tar.gz contains an empty
directory 'neep/ascii/':

$ dget 
http://deb.debian.org/debian/pool/main/x/xfonts-jmk/xfonts-jmk_3.0-22.dsc
$ tar tf xfonts-jmk_3.0.orig.tar.gz
. . .
jmk-x11-fonts-3.0/neep/
jmk-x11-fonts-3.0/neep/Makefile
jmk-x11-fonts-3.0/neep/Makefile.chardesc
jmk-x11-fonts-3.0/neep/Makefile.fonts
jmk-x11-fonts-3.0/neep/Makefile.fonts.in
jmk-x11-fonts-3.0/neep/Makefile.neep
jmk-x11-fonts-3.0/neep/ascii/ <<
jmk-x11-fonts-3.0/neep/fragments/
jmk-x11-fonts-3.0/neep/fragments/Makefile
. . .

That triggers the tag when the file index for the orig tarball is examined:


https://salsa.debian.org/lintian/lintian/blob/master/checks/cruft.pm#L450-451

> but a patch in the quilt series adds a file to that directory.  I believe
> this addresses the concerns described in that tag, and will ensure
> that any view of the source package will contain that directory.

The comment in the tag description [1] about adding a placeholder to
the directory "as needed" applies to upstream before they ship the
orig tarball. Adding placeholder solely to your debianized sources
will not help.

With upstream defunct, wouldn't a Lintian override, or perhaps even a
repacking of the source, be good options for you?

Please feel free to close the bug if you agree with the beginning of
this letter. :)

Kind regards,
Felix

[1] https://lintian.debian.org/tags/source-contains-empty-directory.html

Bug#865847: Use reStructuredText for Lintian manual

[Russ Allbery]

Felix Lechner  writes:

> As you already wrote, RST and Markdown are not that different,
> certainly when compared to Docbook. RST, however, is a lot better
> suited for technical documentation, especially APIs. [1]

For what it's worth, we looked at Markdown for Debian Policy and went with
RST instead because Markdown just doesn't have enough features for large
documents.  Lintian's documentation may not be large enough for it to
matter, but Markdown, while more featureful than POD, isn't that much more
featureful and has some definite gaps.  (Even assuming that one uses a
variant of Markdown with table and definition list support, which can be a
bit hard to find.)

-- 
Russ Allbery (r...@debian.org)   

Cron lintian/reporting/harness --no-generate-reports -i

[Lintian role account]

Warning: unable to close filehandle properly: No space left on device during 
global destruction.

Bug#865847: Use reStructuredText for Lintian manual

[Felix Lechner]

Hi Chris,

tldr; I am comfortable with any format you like, but please consider
that I have to re-write much of the documentation. Could we convert to
Markdown when I am done?

On Sat, Aug 10, 2019 at 10:17 AM Chris Lamb  wrote:
>
> So, whilst this might sound like the usual tedious "my format is
> better than your format" argument, the consensus and trend over the
> most recent couple of years has been free software projects either
> starting or migrating text to using Markdown over every other format
> else bar none.
>
> For example, GitLab (including Salsa) and GitHub (ie.
> the "rest" of the internet, sigh...) are certainly are using this
> format.

Hey, I am not alone! The person who made Github and Gitlab possible,
and therefore enabled Markdown's meteoric rise, actually likes
reStructuredText better. The Linux kernel switched from Docbook to
reStructuredText in 2016. Is that not a reasonable step for Lintian to
emulate?

I also asked on #debian-mentors, where RST came up.

As you already wrote, RST and Markdown are not that different,
certainly when compared to Docbook. RST, however, is a lot better
suited for technical documentation, especially APIs. [1]

Is popularity always a good measure? Nearly 90% of desktop computers
run MS Windows. [2] :)

> Thus, would it be a lot of work to quickly move to that from here
> whilst we are making the time and effort to make the change?

In general, it should be super easy. RST has a lot more features,
which sometimes causes problems when converting [3] but the Lintian
manual is relatively short, and only one document, so it can't be a
huge problem.

Please allow me point out, however, that I plan substantial changes
for Lintian (of course, with your approval) in addition to the ones we
have already made. I therefore expect to spend a lot of time creating
new documentation. Could we perhaps convert it to Markdown when I am
done with it?

Kind regards,
Felix

[1] http://www.zverovich.net/2016/06/16/rst-vs-markdown.html
[2] 
https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Desktop_and_laptop_computers
[3] https://stackoverflow.com/questions/45633709/how-to-convert-rst-files-to-md

Bug#934322: Split reporting code from Lintian proper

[Felix Lechner]

Hi Chris,

On Sat, Aug 10, 2019 at 10:17 AM Chris Lamb  wrote:
>
> How would this work? We don't install the lintian binary package on
> lindsay.debian.org so this wouldn't bring in extra dependencies
> automatically.

I slowly figured that out with help from olasd and adsb. Why are we
not limiting ourselves to backports on lindsay?

Kind regards,
Felix

Bug#934322: Split reporting code from Lintian proper

[Chris Lamb]

Hi Felix,

> Going forward, lintian.d.o would simply depend on 'lintian', in
> addition to any installation prerequisites for the reporting package.

How would this work? We don't install the lintian binary package on
lindsay.debian.org so this wouldn't bring in extra dependencies
automatically. Perhaps I'm missing something...


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#865847: Use reStructuredText for Lintian manual

[Chris Lamb]

Hi Felix,

> Lintian's manual was converted to reStructuredText format. This MR uses 
> rst2html to generate the HTML version.

First, thanks for working on this. Really appreciated.

So, whilst this might sound like the usual tedious "my format is
better than your format" argument, the consensus and trend over the
most recent couple of years has been free software projects either
starting or migrating text to using Markdown over every other format
else bar none. For example, GitLab (including Salsa) and GitHub (ie.
the "rest" of the internet, sigh...) are certainly are using this
format.

Thus, would it be a lot of work to quickly move to that from here
whilst we are making the time and effort to make the change? I think
you have done most of the work, at the very least; the formats are
very similar.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#934325: Separate tag-related bug reports from other functionality issues

[Chris Lamb]

Hi Felix,

> Could we use usertags (or any other mechanism) to separate tag-related
> bug reports from other functionality issues? I like to work on the
> latter.

So, triaging Lintian's many bug reports is already is a bit of a
mission and indeed a little while ago I even removed some categories
and awkward splits similar to these in the bug reports in the name of
simplicity. This really helped IMHO.

I would thus be a -0 on adding more ways of classifiying bugs unless
there was a real and genuine demand/use-case. :)  To wit, is it really
difficult to locate such issues amongst the tag reports? The latter
do, after all, usually include some-kind-of-long-tag-name-like-this
that makes them obvious. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Re: lintian jobs on jenkins.d.n

[Holger Levsen]

Hi Chris,

On Sat, Aug 10, 2019 at 12:56:21PM +0100, Chris Lamb wrote:
> [Let me know if you would no longer like direct CCs for qa-jenkins-dev@ mails]

not being cc:ed would indeed be nice here.

> Please keep them for now; we have not totally replaced them Salsa jobs
> yet (see #930487 et al.) and they sometimes catch other things. To be
> investigated...

ok & absolutly fine. 

> Thanks for asking and maintaining jenkins.debian.net.

my pleasure and thanks for maintaining lintian(.d.o)!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Cron lintian/reporting/harness --no-generate-reports -i

[Lintian role account]

Warning: unable to close filehandle properly: No space left on device during 
global destruction.

Bug#849752: lintian: fails when orig tarball not present in same directory

[Drew Parsons]

On 2019-08-10 01:36, Felix Lechner wrote:

Hi Drew,

On Tue, Aug 6, 2019 at 4:24 AM Drew Parsons  
wrote:


This
error running lintian simply means the orig tarball is not present in
the same directory as the changes file that lintian is run against.


Would you please post your *.changes and your *.dsc?




dijitso is one simple example.

$ lintian dijitso_2019.1.0-2_amd64.changes
Non-zero status 1 from dpkg-source:
cp: cannot stat 
'/tmp/temp-lintian-lab-E1bM9mxvNz/pool/d/dijitso/dijitso_2019.1.0-2_source/dijitso_2019.1.0.orig.tar.gz': 
No such file or directory
dpkg-source: error: cp 
/tmp/temp-lintian-lab-E1bM9mxvNz/pool/d/dijitso/dijitso_2019.1.0-2_source/dijitso_2019.1.0.orig.tar.gz 
to 
/tmp/temp-lintian-lab-E1bM9mxvNz/pool/d/dijitso/dijitso_2019.1.0-2_source/dijitso_2019.1.0.orig.tar.gz 
subprocess returned exit status 1

warning: collect info unpacked about package dijitso failed (512)
warning: skipping check of source package dijitso
N: 0 tags overridden; 2 unused overrides


Format: 3.0 (quilt)
Source: dijitso
Binary: python3-dijitso
Architecture: all
Version: 2019.1.0-2
Maintainer: Debian Science Team 

Uploaders:  Johannes Ring , Drew Parsons 

Homepage: https://fenicsproject.org
Standards-Version: 4.4.0
Vcs-Browser: https://salsa.debian.org/science-team/fenics/dijitso
Vcs-Git: https://salsa.debian.org/science-team/fenics/dijitso.git
Testsuite: autopkgtest
Testsuite-Triggers: @builddeps@, mpi-default-bin, python3-pytest
Build-Depends: debhelper-compat (= 12), dh-python, python3-all, 
python3-setuptools, python3-numpy
Package-List:
 python3-dijitso deb python optional arch=all
Checksums-Sha1:
 24b18765447e6b5cecfd0e0c0a8762bd842276e6 51317 dijitso_2019.1.0.orig.tar.gz
 ff2a42b1713407c1933390713fdf32daf43bec9c 488 dijitso_2019.1.0.orig.tar.gz.asc
 db11f4ba0dba9a51e186f2b733d7bd1376adcf61 5020 dijitso_2019.1.0-2.debian.tar.xz
Checksums-Sha256:
 eaa45eec4457f3f865d72a926b7cba86df089410e78de04cd89b15bb405e8fd9 51317 
dijitso_2019.1.0.orig.tar.gz
 fbb6273ab66b8bef6c6bf28873d95ab10c59206f23eb9ab6cf5ac5c27f467747 488 
dijitso_2019.1.0.orig.tar.gz.asc
 b79c2f611602ea6bf4a5dcbda711dd121437a3b92a9992b29c624628d368d0e1 5020 
dijitso_2019.1.0-2.debian.tar.xz
Files:
 e66414b8a07e0a748aa6e725d70b0ce4 51317 dijitso_2019.1.0.orig.tar.gz
 46fe9f37facc6f90f258e562269d8a2e 488 dijitso_2019.1.0.orig.tar.gz.asc
 ae4f27c9b57147b13176f850d6771734 5020 dijitso_2019.1.0-2.debian.tar.xz
Format: 1.8
Date: Wed, 31 Jul 2019 11:59:05 +0800
Source: dijitso
Binary: python3-dijitso
Architecture: source all
Version: 2019.1.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Team 

Changed-By: Drew Parsons 
Description:
 python3-dijitso - distributed just-in-time building of shared libraries 
(Python 3)
Changes:
 dijitso (2019.1.0-2) unstable; urgency=medium
 .
   * Standards-Version: 4.4.0
   * drop python-dijitso
Checksums-Sha1:
 50844a4d46ab4b4aa6765cd750025371e3118ec2 1501 dijitso_2019.1.0-2.dsc
 db11f4ba0dba9a51e186f2b733d7bd1376adcf61 5020 dijitso_2019.1.0-2.debian.tar.xz
 f1dccbfcb6e7c5fb2beef540e8d78a749588202b 5355 
dijitso_2019.1.0-2_amd64.buildinfo
 82ce2b1f9235edd10a9c0c5821ae1c25f1540e11 24848 
python3-dijitso_2019.1.0-2_all.deb
Checksums-Sha256:
 8b951f4875e82ecd2d79d0a7368827789b9746d969d4588b9cc3f9d0c163051b 1501 
dijitso_2019.1.0-2.dsc
 b79c2f611602ea6bf4a5dcbda711dd121437a3b92a9992b29c624628d368d0e1 5020 
dijitso_2019.1.0-2.debian.tar.xz
 2ab47e360bc219a626cae24e8cf5883f348b4a1db5b4f06c3bd630372dca07cf 5355 
dijitso_2019.1.0-2_amd64.buildinfo
 70d6e7e80562116a9ad0380df2f3f67168c46df7478ccecb70eeef27f8a5ff38 24848 
python3-dijitso_2019.1.0-2_all.deb
Files:
 083323ba8fab95774cb5b94f3771ad9c 1501 python optional dijitso_2019.1.0-2.dsc
 ae4f27c9b57147b13176f850d6771734 5020 python optional 
dijitso_2019.1.0-2.debian.tar.xz
 61a8243b374441a2cbb4bd044173c412 5355 python optional 
dijitso_2019.1.0-2_amd64.buildinfo
 8533f895aeee7422d9a505b80951b375 24848 python optional 
python3-dijitso_2019.1.0-2_all.deb

Re: lintian jobs on jenkins.d.n

[Chris Lamb]

[Let me know if you would no longer like direct CCs for qa-jenkins-dev@ mails]

Hi Holger,

> do you still need/use the lintian related tests on jenkins.d.n or have
> you already replaced them with Salsa / Debian CI?

Please keep them for now; we have not totally replaced them Salsa jobs
yet (see #930487 et al.) and they sometimes catch other things. To be
investigated...

Thanks for asking and maintaining jenkins.debian.net.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Processed: tagging 865847

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 865847 + patch
Bug #865847 [lintian] lintian: Migrate manual generation away from jw to 
something that supports UTF-8 natively
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
865847: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865847
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#865847: Use reStructuredText for Lintian manual

[Felix Lechner]

 Control: tag -1 + patch

Lintian's manual was converted to reStructuredText format. This MR uses
rst2html to generate the HTML version.

https://salsa.debian.org/lintian/lintian/merge_requests/245

This RST file was generated from the existing manual in Docbook format
using:

pandoc -f docbook -t rst doc/lintian.xml > doc/lintian.rst

The resulting file showed the following three errors when used to generate
HTML with rst2html from python3-docutils:

lintian.rst:366: (ERROR/3) Unexpected indentation.
lintian.rst:363: (WARNING/2) Inline literal start-string without
end-string.
lintian.rst:367: (WARNING/2) Block quote ends without a blank line;
unexpected unindent.

The errors disappeared after a single, multi-space indent in line 366 was
removed manually using an editor.

RST does not have a facility to split documents into multiple output files
(although a 'toctree' directive could link multiple documents.) For now,
the HTML manual is one large, contiguous file.

Installs the single HTML file and the reStructuredText file in the user
package. Sets a link to the RST version with the ending *.txt in hope of
avoiding breakage.

Updates doc-base entries to point to the single HTML file and to the RST
file in lieu of plain text documentation.