[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#759403: marked as done (lintian: Please publish machine-readable report for all packages)

Your message dated Sat, 03 Aug 2019 14:06:17 -0300
with message-id <87ef22dvqu.fsf@manticora>
and subject line Re: Bug#759403: lintian: Please publish machine-readable report for all packages
has caused the Debian Bug report #759403,
regarding lintian: Please publish machine-readable report for all packages
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 owner@bugs.debian.org
immediately.)


-- 
759403: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759403
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: lintian
Version: 2.5.25
Severity: wishlist

Hi,

on the pkg-perl team, we would like to track the hardening status of
our packages (same goes in Tails, to track the hardening status of the
packages we ship).

The easiest way for us would possibly be to retrieve data about all
packages from lintian.d.o, filter on the maintainer field, and build
statistics and graphs from that.

I've had a look at the html_reports script, which seems to be the best
place to generate the file I'd like to see on lintian.d.o. Much alike
it generates qa-list.txt already, something like packages-binary.yml
could be created there. Its format could be something like a list of:

- $BINARY_PKG_NAME:
  maintainer: ...
  version: ...
  source: ...
  tags:
    - $TAG_NAME:
      severity: ...
      certainty: ...

Of course, for consistency, generating packages-source.yml would be
good too, although I don't need that right now.

I've given it a try, but was quickly discouraged by the need for
a local lab (and mirror?), which I have no experience with.

I'd welcome any hint and guidance regarding the relevance of the
general idea, the rough design outlined above, and locally testing an
implementation I could come up with.

Cheers,
--
intrigeri

--- End Message ---
--- Begin Message --- 
Chris Lamb:
> Querying UDD directly via SQL is almost trivial to the point that it
> genuinely did not occur to me that you would try with the web
> interface.

> I highly recommend you start with that approach. :)

OK, I've added a note about this on the relevant Tails ticket ¹.
I'll try that approach on a rainy Sunday when I'll come back to
this topic. Thanks!

[1] https://redmine.tails.boum.org/code/issues/6918#note-21

Cheers,
-- 
intrigeri

--- End Message ---
Reply to: