ly unsupported since July of 2017. I think one can make a good
argument that both the Lintian tag description and xymon should just drop
all support for Apache versions prior to 2.4. Hopefully no one is still
running it, since it almost certainly has significant unfixed security
vulnerabilitie
nces.
That's the standard for our projects at my current employer.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ructures stored on disk (possibly including caches, depending on the
situation). In other situations, this is something that's going to
require some distribution-wide coordination that I don't think we've
started yet.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
C when running Lintian.
Lintian should probably force all output it controls to UTC for
reproducibility, including tar's, but I'm still mystified as to why it
works on the other system. This part of tar doesn't seem to have changed,
and as you mentioned replacing tar didn't change anything.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
that could also be the case for the original reporter.
Although echo -n is undefined in POSIX, Debian requires it to work in all
shells that are eligible to be /bin/sh. See:
https://www.debian.org/doc/debian-policy/ch-files.html#scripts
--
Russ Allbery (r...@debian.org) <htt
ts are being passed to the sourced
file, which is a bashism. The missing logic is understanding that a $()
block is effectively a quoted string and thus should be ignored for the
purposes of this test.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc: r...@debian.org
A section 8 manual page for a binary in /usr/libexec triggers:
I: kafs-client: spare-manual-page [usr/share/man/man8/kafs-dns.8.gz]
N:
N: Each manual page in /usr/share/man should have a reason to be there. This
Russ Allbery pushed to branch master at lintian / lintian
Commits:
8509a3f2 by Louis-Philippe Véronneau at 2022-12-23T18:04:42+00:00
Fix false-positive for missing-prerequisite-for-pyproject-backend when the
backend is specified as a Build-Depends-Indep. Closes: #1025164
- - - - -
4
Russ Allbery pushed to branch master at lintian / lintian
Commits:
899bd1b6 by Louis-Philippe Véronneau at 2022-12-23T04:00:07+00:00
Mark very-long-line-length-in-source-file as experimental, because of
the high number of false-positives
- - - - -
2 changed files:
- t/recipes/odd-inputs
ts use the approach of only updating the years when the files are
changed; others update all years on all files every year (the FSF does
this, for instance, based on legal advice from their lawyers).
This doesn't feel like something Lintian should have an opinion about.
--
Russ Allbery (r...@debi
right now is that the test suite takes an excessively long time to run,
and it would be nice to improve that. I'm dubious that we can delete
enough tags and thus tests to make a huge difference, but it does help.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery pushed to branch master at lintian / lintian
Commits:
306bab23 by Fatih Altun at 2022-11-27T00:28:23+00:00
Add yirmiuc as a known Pardus distribution
- - - - -
1 changed file:
- vendors/pardus/main/data/changes-file/known-dists
Changes
n years
since I've worked on Lintian, but some of those MRs looked pretty obvious,
so I'm merging the ones where I'm reasonably sure that I won't break
anything. Someone can always revert if I make a mistake. :)
Axel, please let me know when (I won't even say if) I mess something up.
-
there is.
If this were GitHub Actions, I'd be tempted to try to cache all of the
test packages and only rebuild them if something has changed, which I
suspect would save some time. I'm not sure how to do that with GitLab.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
.
Is there more up-to-date documentation somewhere that I should be looking
at? Or, failing that, maybe an explanation for what I saw with the hints
file would get me oriented so that I understand where to look.
Thanks!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
his paragraph in 1.1 (Scopes):
udebs (stripped-down binary packages used by the Debian Installer) do
not comply with all of the requirements discussed here. See the Debian
Installer internals manual for more information about them.
That could be as simple as saying "udebs (...) and source packages that
produce only udebs do not comply"
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
kewise, him is apparently now
in 639-5.
The conclusion I'd draw from that is that there's probably no need to add
639-2 if you include both 639-3 and 639-5, and it may be simpler to just
ignore it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
to your solution. :)
(Maybe all of this can be captured in comments for the next poor
maintainer who has to try to understand what's going on.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
of the group rather than being coded to
the 639-5 language group code. I think Lintian should still continue to
use 639-3.
That said, I'll leave it to you to decide if you want to hang on to the
bug or not. :)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ing this bug to iso-codes for further investigation and cc'ing
the maintainer.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ning.
For the record (since I'm not sure this is obvious when you're new to
Lintian), the best way to run Lintian is on the *.changes file generated
as part of the package build. That will check everything that will be
included in the upload.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
I have no opinion about whether Lintian should mark it as a spelling
mistake, but I would recommend avoiding it in favor of the more standard
subtract spelling.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
fprintf (stderr, "%s: line %d: chown
> failed\n",
This specific example is a false positive, though, correct? I think you
want to filter out hits that include a parenthesis, since those are likely
to be calls to the C library function, which
at this, but doesn't having a number
(instead of UND) in that last-but-one column mean that the symbol is
indeed built into the binary and not loaded from a library?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Thank you for implementing that!
> Yes, the exception is probably warranted. If it's okay with you,
> however, I will postpone the decision until the cruft check, which
> issues the offending tag, is fixed. It is currently malfunctioning. [2]
> Thank you!
Yes, absolutely, this is a lo
Package: lintian
Version: 2.109.0
Severity: wishlist
libpam-krb5 4.11-1 (just now uploaded and also available from Salsa)
produced the following new Lintian pedantic tags:
N:
P: libpam-krb5 source: very-long-line-length-in-source-file configure line
13223 is 704 characters long (>512)
N:
N:
definitely in favor of documenting these files in a format designed to
do so.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Felix Lechner writes:
> On Mon, Apr 5, 2021 at 1:10 PM Russ Allbery wrote:
>> See also Debian Policy 8.4, which explicitly requires this:
> Thanks for throwing that into the mix. Obviously, I accept policy and
> will implement it, but the approach reminds me of the Goldsbo
this:
If the package provides Ada Library Information (*.ali) files for use
with GNAT, these files must be installed read-only (mode 0444) so that
GNAT will not attempt to recompile them. This overrides the normal
file mode requirements given in Permissions and owners.
--
Russ Allber
Russ Allbery writes:
> Lintian now emits the following pedantic tag for packages using
> X-DhRuby-Root:
Sorry, forgot to mention: you will be able to see this behavior with the
3.17-1 version of remctl that I'm about to upload, and I'm fairly sure
that you'll see the same with 3.16-4,
Package: lintian
Version: 2.104.0
Severity: wishlist
Given that you want a reference to a package showing the problem on
all Lintian bug reports, based on recent responses, could you consider
including reportbug configuration in the package to prompt for this? A
presubj file would probably do
Package: lintian
Version: 2.104.0
Severity: normal
Lintian now emits the following pedantic tag for packages using
X-DhRuby-Root:
P: remctl source: cute-field debian/control@ruby-remctl X-DhRuby-Root vs
X-Dhruby-Root
N:
P: cute-field
N:
N: The named field uses a free-style form of
packages need at runtime have
to be installed outside of /usr/share/doc, with links to /usr/share/doc if
appropriate.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e inverse case (moving the docs to /usr/share/doc and
> linking them back to where the software expects them)?
If the files are used at runtime, Policy requires installing the files
outside of /usr/share/doc and linking them to /usr/share/doc. See Policy
12.3, second-to-last par
ks who picked 7).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> I had a package with control fields:
> Vcs-Git: https://salsa.debian.org/rra/libpgp-sign-perl.git
> Vcs-Browser: https://salsa.debian.org/rra/libpgp-sign-perl
Argh, sorry, that should have been:
Vcs-Git: https://salsa.debian.org/rra/libpgp-sign-perl
Vcs-Brows
Package: lintian
Version: 2.94.0
Severity: minor
I had a package with control fields:
Vcs-Git: https://salsa.debian.org/rra/libpgp-sign-perl.git
Vcs-Browser: https://salsa.debian.org/rra/libpgp-sign-perl
This produces the following Lintian diagnosis:
I: libpgp-sign-perl source:
Package: lintian
Version: 2.88.0
Severity: minor
Lintian produces a false-positive pedantic repeated-path-segment tag
for Perl modules that use File::ShareDir (a Perl mechanism to provide
static data files for a Perl module in a location that Perl can find
at runtime across all supported
would be ideal if the tag were specific to the
underlying problem, but I would consider it reasonable to complain that
one cannot extract the section from that .TH line since groff cannot
either.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
cobble something together without it, but
it's fairly explicitly not supported by Policy.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Felix Lechner writes:
> On Wed, Jul 1, 2020 at 8:16 PM Russ Allbery wrote:
>> I'm puzzled by why you would have changed Lintian in response to that
>> bug, given that the reported problem was only with Lintian and was
>> fixed sixteen years ago.
> I am just working thro
with Lintian and was fixed
sixteen years ago.
What problem is this tag trying to address?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
etween you and Guillem (and am not sure I
want to know), but the way you keep sniping at him is uncomfortable to
read and rather off-putting.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
is that the
classification system is more fine-grained than the users of Lintian care
about, so maintaining it is to some extent wasted effort.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
?
Sure, yes, please go ahead. After thinking about this some more, I agree
with your reasoning.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ething into Policy and
hopefully would speed up resolution of the bug.
v9 and v10 are still not deprecated, so support for v12 isn't urgent
(yet). If this bug is still unfixed by the time that v9 and v10 are
deprecated, that would probably warrant more urgency.
--
Russ Allbery (r...@debi
orrect that it doesn't help with keeping the directory in the
source package; it just makes sure it's created by the build step before
anything might use it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
by this is xfonts-jmk.
Felix Lechner writes:
> 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?
No, the root problem, and the reason why the Lintian tag e
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) <http://www.eyrie.org/~eagle/>
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) <http://www.eyrie.org/~eagle/>
a
variant of Markdown with table and definition list support, which can be a
bit hard to find.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
the results.
Given that, I would argue against having a Lintian tag at all, or at most
making it pedantic.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Felix Lechner writes:
> On Mon, Jul 8, 2019 at 12:50 PM Russ Allbery wrote:
>> The name of the files and directories installed by binary packages
>> outside the system PATH must be encoded in UTF-8 and should be
>> restricted to ASCII when it is possible to do
(namely /bin, /sbin, /usr/bin, /usr/sbin and /usr/games) must be
encoded in ASCII.
The name of the files and directories installed by binary packages
outside the system PATH must be encoded in UTF-8 and should be
restricted to ASCII when it is possible to do so.
--
Russ A
ries
changes in the future.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
the host may not be using systemd). We don't have good helpers for this
yet, so it requires some careful thought to make this work properly.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
are
in the fonts section. If ftp-master had wanted them in a different
section, that's entirely under their control, and they could have just
made that change.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
info enabled if you care about this sort of thing. Or
is this about the default view in the package tracker?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
l the things we
think are reasonably fixable."
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Jeremy Bicha writes:
> On Thu, Sep 20, 2018 at 6:18 PM Russ Allbery wrote:
>> Maybe exclude shared libraries linked with glib (and whatever the Qt
>> equivalent is)?
> One package that triggers this tag a lot is samba and it doesn't use
> glib or qt.
> https://linti
assuming the NEEDED metadata is erroneously missing even though the
library has undefined symbols, as opposed to a shared library that really
doesn't need other libraries.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
re,
since my package uses the same section as the archive uses in
debian/control. (Well, I could have made the change in Lintian... one of
these days I'll get back to doing that.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
doing based on the sections of
what's in the archive now, and they're canonical for sections (not the
packages pages on www.debian.org).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
bian.tar.xz
dpkg-source: info: applying debian-changes
gwaihir:~/tmp$ ls -al xfonts-jmk-3.0/neep/ascii
total 4
drwxr-xr-x 1 eagle eagle 24 Sep 5 15:46 ./
drwxr-xr-x 1 eagle eagle 292 Sep 5 15:46 ../
-rw-r--r-- 1 eagle eagle 341 Sep 5 15:46 .placeholder
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
>> section when a package could fall into multiple sections.
> Sounds good to me.
>
>> (I'm not sure where to report the packages.debian.org bug. Do you know?)
> Against the "www.debian.org" pseudo-package.
Thanks, filed as #907782.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: lintian
Version: 2.5.99
Severity: minor
On a personal package of a documentation tool (not in Debian yet):
I: docknot: package-contains-documentation-outside-usr-share-doc
usr/share/perl5/auto/share/module/App-DocKnot/templates/readme-md.tmpl
I: docknot:
Package: lintian
Version: 2.5.99
Severity: minor
xfonts-jmk 3.0-22 (just now uploaded to the archive) receives the tag:
P: xfonts-jmk source: source-contains-empty-directory neep/ascii/
but a patch in the quilt series adds a file to that directory. I believe
this addresses the concerns
Package: lintian
Version: 2.5.99
Severity: normal
In #878609, xfonts packages were reclassified to be in the x11 section,
resulting in the wrong-section-according-to-package-name tag being
issued if they go to the fonts section. This was based on the text in
https://packages.debian.org/en/sid/,
rectory. Generic header names are only a
>> problem at the top level of the include hierarchy.
> But of course. Almost confused why you thought an explanation was needed ;)
You're right -- that was obvious. Sorry! :) I should have just made a
patch instead.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
bdirectory. Generic header names are only a
problem at the top level of the include hierarchy.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Paul Wise <p...@debian.org> writes:
> On Mon, 2018-05-07 at 19:27 -0700, Russ Allbery wrote:
>> I just now checked, and the packages currently diagnosed with this
>> tag [1] are 100% false positives, which makes me wonder if this tag
>> should just be dele
should be warned about).
> Retitling to clarify. (Still, "SSIA" comes across as a little... lazy! :p)
Oh, ack, I'm sorry. I should have done a bit more investigation to
understand how this tag works before I replied and added noise. My fault,
and thank you for the explanation!
--
Mattia Rizzolo <mat...@debian.org> writes:
> SSIA.
Could you say more? www.gnu.org redirects to https for me, so it seems
like one can use https when referencing www.gnu.org URLs. (I would be
surprised if that weren't the case given the goals of the FSF.)
--
Russ Allbery (r...@d
icked one out of a hat (although I admit
the lack of documentation in Policy for how to declare this dependency
doesn't help). In contrast, add-ons for one specific MTA, or management
interfaces that only know how to configure one specific MTA, are fairly
common.
[1]
https://lintian.debian.org/tags/d
erimental is for. Pedantic is for best-practice
advice that's controversial, that is correct but may not be fixable (no
upstream changelog, for instance), or that is minor
quality-of-implementation details that a lot of maintainers aren't
interested in messing with (upstream/metadata, for inst
making it do nothing would be friendlier.
lintian --suggestions, maybe?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
're using Lintian wrong doesn't
seem to be working.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
I'm not sure how one could possibly be more clear. If one's definition of
lintian-clean includes --pedantic, one's definition of lintian-clean is,
well, wrong.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
be some bug in Lintian. Not that you had somehow done something horribly
wrong with your package.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
umber of free software distribution sites that currently
use FTP but would support FTP + TLS is at most a rounding error away from
zero.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
d
assume?
I think my personal maintainer page is probably more typical.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e
> something like:
> """
> This is the lintian report for Russ Allbery, who maintains 20 packages.
> Possible issues found by lintian:
> E: 10 (of which 3 are certain)
> W: 3
> Style suggestions / nits:
> I: 12
> P: 255 (of which 120 of these are file-contains-tr
eless and add a ton of space because even entirely Lintian-clean
packages have several of them. Maybe just suppress those from the
maintainer report and see what things look like then?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Russ Allbery <r...@debian.org> writes:
> I'll be open about this: I think that there's a deep mismatch between
> how we like to discuss things, which is why I'm trying to avoid getting
> into a back and forth. I think you're just trying to be clear and
> precise, but I find
previously, I'm happy to let the active Lintian
maintainers make the final call on this, since I'm not active.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ctly contrary to the entire reason I created this bug. :)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
file.
What makes you confident that the process you propose would continue to
satisfy the license going forward during normal upstream updates?
How much energy would you want to spend on defending your interpretation
of this in order to avoid installing this file in the documentation area
of t
sue entirely rather than carefully analyzing the
situation or remembering to resync copies of the upstream file.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ill die down a bit.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
although
normal Debian best practices with debian/changelog would satisfy it.)
Free software licenses have a lot more restrictions and specific
requirements than a lot of people realize they do, and there are a *lot*
of technical violations of free software licenses out there.
--
R
Vincent Bernat <ber...@debian.org> writes:
> ❦ 22 décembre 2017 19:58 -0800, Russ Allbery <r...@debian.org> :
>> Apache 2.0 requires distributing any NOTICE file along with derivative
>> works, but this is easy to forget. In many cases, we have effectively
>&g
ng Git, or that, at this point,
this isn't because of a conscious and intentional choice seems extremely
low. So you're basically warning the maintainer about something they have
already intentionally chosen to do, and that's almost never going to go
over well.
--
Russ Allbery (r...@d
Chris Lamb <la...@debian.org> writes:
> libpam-krb5 which was actually being caught by a "libfoo1" => "libs" entry
> designed for regular libraries. Fixed in Git with a testcase:
Ah! That didn't even occur to me, but that makes much more sense. Thank
you!
Package: lintian
Version: 2.5.66
Severity: normal
Lintian now wants me to change the section of my PAM module packages
to libs based on the package name. It looks like common practice in
the archive is a bit all over the place, and standardizing would be
great, but libs seems wrong to me. In
Yeah, the problem I have is that I do want all the checks when uploading
to Debian. I suspect the right thing for me to do is make my own profile,
and then just remember to use that profile for local packages. It's a
little bit awkward, but it's not too bad.
--
Russ Allbery (r...@debian.org
s would definitely work. I wonder if it would make sense to
have a file in debian/source that indicates the profile in some way?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Package: lintian
Version: 2.5.66
Severity: normal
The new tag bugs-field-does-not-refer-to-debian-infrastructure added in
the most recent version of Lintian is a false positive for non-Debian
packages. I have a pile of personal packages that I maintain in a separate
archive, but prefer to use
Chris Lamb <la...@debian.org> writes:
> Good catch. Fixed in Git:
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=6110e0f1185e26d903dd0ed8a7a8edaae14cf905
I suspect you want package.docs in the long description of the tag instead
of package.install.
--
Package: lintian
Version: 2.5.65
Severity: wishlist
Apache 2.0 requires distributing any NOTICE file along with derivative
works, but this is easy to forget. In many cases, we have effectively
the same information in debian/copyright, but even if this is the case
for a specific release, it's not
s is fallout from the
requirement that packages include a changelog for that specific version of
the package. It's in Policy, but it's semi-hidden in a footnote (and it
looks like the current www.debian.org publication of Policy has broken all
the footnote links because the multi-page Policy document isn't
1 - 100 of 2537 matches
Mail list logo
