ends (and Build-Conflicts)
satisfied, and pybuild + the build-backend dependencies are involved in
the cleaning step.
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2
Package: lintian
Version: 2.105.0
Severity: serious
Justification: unsuitable for release in the release maanger's opinion
X-Debbugs-Cc: stu...@debian.org
Dear Maintainer,
Following up on a conversation in #debian-qa, the current wording of the
classification tag "unmerged-usr" is problematic:
C
)
Perhaps there is a rough consensus in these discussions so far:
https://bugs.debian.org/401452
https://bugs.debian.org/509935
https://bugs.debian.org/962277
cheers
Stuart
(who would welcome a resolution too: see https://bugs.debian.org/686638)
--
Stuart Prescotthttp://www.nanonanonano.net
= 0755 or $rules->is_symlink;
perhaps a better test would be (my perl is rather rusty):
$rules->operm & 0111
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E
Package: lintian
Version: 2.22.0
Severity: wishlist
Dear Maintainer,
If dh_sphinxdoc is used, either explicitly in d/rules or added to the
debhelper sequence using `--with sphinxdoc`, the relevant -doc package should
have `Depends: ${sphinxdoc:Depends}`. Not doing so will leave a symlink farm
of
all in the postinst. I'm not sure what the relative abilities of
lintian's d/rules and postinst checkers are, and whether that is a useful
snippet of information.
Cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://ww
Package: lintian
Version: 2.5.108
Severity: wishlist
Over in #910593, I reported that the maintainer script was using a feature of
update-rc.d that is not available in stretch. Could lintian spot that usage
in the maintainer script and, if a versioned dependency on init-system-helpers
is not found
people can
do but since 'true' is the most obvious noop it's probably enough for that.
(The policy around the tests obviously needs to broadly forbid noop tests in
some way beyond what lintian can actually test for; someone from RT/ci/
Policy(?) needs to document what is acc
s
> > packages do not have the binary prefix
>
> Right, exactly; would your package have triggered this error *if* the
> requirement to match /^python([23]?)-/ was not present? :)
I believe that is correct, yes.
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu..
n both Python 2 and Python 3,
but my feeling is that the vast majority of such dependencies would be
mistakes.
(yes, if this were python-translate-toolkit then it would have been caught,
but that package name would also be incorrect for the package)
cheers
Stuart
--
Stuart Prescotthttp
Package: lintian
Version: 2.5.94
Severity: wishlist
Dear Maintainer,
In the upload of translate-toolkit 2.3.0-3, I ended up with the following:
Depends: python3, python3-pkg-resources, python3-six, python3-translate,
python3:any, python:any
such that the package depended on both the Python 2 a
le to have symlinks outside /u/s/doc (and was
trying to do so today to help users find the examples that pymol-data is
shipping inside /usr/share/pymol/examples).
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/
Package: lintian
Version: 2.5.84
Severity: normal
Hi
the following lintian output is omitted:
I: pymol-data: spelling-error-in-copyright UIUC UIUC (duplicate word) UIUC
N:
N:Lintian found a spelling error in the copyright file. Lintian has a list
N:of common misspellings that it looks f
ding a
> new one as that had 99% overlap..
>
> I'd love to get this applied and uploaded today. :)
>
> commit ce133079d182f8005e8896da2c9215057304bc89
> Author: Chris Lamb
> Date: Sun Mar 18 13:11:21 2018 -0400
Looks good to me!
thanks
Stuart
--
Stuart Prescot
https://salsa.debian.org/mehdi/salsa-scripts/
For the others who have contributed to this bug -- anything else I've
forgotten?
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint
nWheezy
[3] https://salsa.debian.org/salsa/AliothRewriter/blob/master/README.md
[4] https://salsa.debian.org/mehdi/salsa-scripts/
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Package: lintian
Version: 2.5.67~bpo9+1
Severity: wishlist
udevadm can be present on the system but non-functional, due to being inside
a chroot for example. It seems that there are two common patterns used in
maintainer scripts that correctly handle that situation:
if udevadm control --reload; t
and not $fname =~ m,/_sources/license\.rst(\.txt)?$,o
BTW this should include license.txt too from sphinx before 1.6(ish).
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprin
Package: lintian
Version: 2.5.66
Severity: normal
Sphinx always wants to include a copy of the licence of the documentation
within the sources and it always includes the .rst sources of the documentation
in amongst the compiled text. This means that maintainers either end up
ignoring or overriding
Package: lintian
Version: 2.5.66
Severity: normal
The new tag python-package-depends-on-package-from-other-python-variant
complains about the relationship:
Package: python3-bumps
Suggests: python-bumps-doc, …
It's pretty standard for the documentation for Python module packages to
be shipped
in the sample command but otherwise,
that at least tells the maintainer how to fix the warning rather than giving
an instruction that does not.
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu..
Package: lintian
Version: 2.5.59
Severity: normal
Dear Maintainer,
In lintian's tag file-contains-trailing-whitespace, the maintainer is told
that they can remove the offending whitespace with:
sed -i -e 's@[ ]*$@@g' path/to/filename
However, that only removes trailing spaces, while trailing
name)
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
#x27;s fine. If not: Send patches! ;-)
Looks good to me -- thanks!
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
--
To UNSUBS
example is just
opts=pgpsigurlmangle=s/$/.asc/
and for the second is sufficiently horrid that I shall graciously decline.
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerpri
Package: lintian
Version: 2.5.27
Severity: normal
Dear Maintainer,
The package-contains-timestamped-gzip tag complains about gzipped files
that are in the upstream tarball. While it is true that these files were
compressed and contain a timestamp, it is not true that this timestamp will
be differ
st won't have people
wondering why lintian is claiming to have checked dependencies when it has
not.)
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprintBE65 FD1E
Package: lintian
Version: 2.5.10.3
Severity: wishlist
Looking at #657281 led me to look at Contents-source for other possible
occurrences of this file. I ended up using md5sum to positively identify that
the offending file in other source packages was or was not the same file.
That this file was
Package: lintian
Version: 2.5.10.1
Severity: normal
Hi!
Lintian's tag to catch accidentally empty packages (empty-binary-package)
states that the maintainer should include the information that this package
is supposed to be empty in the description:
N: If the package is deliberately empty, p
29 matches
Mail list logo
