Bug#1069697: lintian: debian-changelog-line-too-short CVEs

Richard Lewis dixit: >would it make a difference if the somewhat ambiguous line "CVEs" was >changed to "Fixes the following CVEs:" ? It’s very much not ambiguous, as the entire entry is a list of fixes, that’d be reducing the signal:noise ratio (besides this part of the changelog is copy-pasted

Bug#1069697: lintian: debian-changelog-line-too-short CVEs

Package: lintian Version: 2.117.0 P: openjdk-8-doc: debian-changelog-line-too-short CVEs [usr/share/doc/openjdk-8-doc/changelog.Debian.gz:4] The changelog in question is: * New upstream release * CVEs - CVE-2024-21011 - CVE-2024-21085 - CVE-2024-21068 - CVE-2024-21094 *

Bug#1068324: lintian: patch-not-forwarded-upstream for upstream patches

Hi Nilesh, >Right. AFAICS, lintian spews that warning because the header in that patch in >incomplete. It also needs a "From" and "Subject" (which can be same as commit this is not entirely correct. The full patch header is: Description: fix typeset -p confusion between empty and unset Origin:

Bug#1068324: lintian: patch-not-forwarded-upstream for upstream patches

Package: lintian Version: 2.116.3 (at least bookworm’s) lintian complains about… I: mksh source: patch-not-forwarded-upstream [debian/patches/typeset-p-fix.diff] … for patches whose DEP 3 metadata clearly state they are a cherry-pick or backport from upstream. Here (cherry-pick): Origin:

Bug#1068304: lintian: static-pie misdetected as libraries

Package: lintian Version: 2.117.0 Severity: normal X-Debbugs-Cc: t...@mirbsd.de lintian misdetects static-pie binaries such as these which can now be created by musl, but TTBOMK also from glibc: W: mksh: mismatched-override statically-linked-binary [bin/lksh]

Bug#1050428: lintian: unknown-field Static-Built-Using

Package: lintian Version: 2.116.3 This field was added with bookworm’s dpkg, so AIUI it can now be used by packages in trixie/sid.

Bug#1036712: Replaces without Breaks or Conflicts harmful?

Helmut Grohne dixit: >> > rng-tools-debian >> >> Also false positive: >> >> Replaces: intel-rng-tools, rng-tools >> Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate) >> Conflicts: intel-rng-tools > >This is *not* a false positive, but a real issue. It replaces any >rng-tools, but

Bug#1036712: Replaces without Breaks or Conflicts harmful?

Helmut Grohne dixit: > openjdk-8 (U) Should be convered by the Depends lines in the respective binary packages, e.g: Depends: openjdk-8-jre (>= ${source:Version}), openjdk-8-jdk (>= ${binary:Version}), ${misc:Depends} Replaces: openjdk-8-jdk (<< 8u20~b26-1~) > rng-tools-debian Also

Bug#1025644: lintian: should not have the update-debian-copyright tag at all

Package: lintian Version: 2.115.3 Severity: normal X-Debbugs-Cc: t...@mirbsd.de The update-debian-copyright tag gives bad advice: N: The most recent copyright year mentioned for files in ./debian lags behind N: the year in the timestamp for the most recent changelog entry. This is a fully

Re: lintian: add classification tags for packages that need porting to different architectures?

Paul Wise dixit: >Any thoughts? What’s the use? (In the good sense, a pure question out of interest.) For example, there’s software that upstream is written in a way to only work correctly on little-endian platforms, e.g. because its file parser doesn’t do letoh32() and friends. These need

Bug#1019235: lintian: 'licence' is not a misspelling

Package: lintian Version: 2.115.3 Followup-For: Bug #1019235 X-Debbugs-Cc: t...@mirbsd.de Spotted this too, please fix it, licence is proper English spelling, not oversea barbarian dialect. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500,

Bug#995850: lintian: more context is not always a good thing

Felix Lechner dixit: >By the way, you should also be able to use the wildcards * and ? in >lieu of the line numbers right now. Please let me know if that works. So indeed: -mksh source: debian-watch-uses-insecure-uri http://www.mirbsd.org/MirOS/dist/mir/mksh/ +mksh source:

Bug#995850: lintian: more context is not always a good thing

Felix Lechner dixit: >At first glance, the line numbers seemed like a customer-friendly way >to distinguish hints, but I see your point. (Many more hints are fixed >than overridden.) Indeed, but it makes overriding them in the case where that’s truly the correct action (at no fault of lintian)

Bug#995850: lintian: more context is not always a good thing

Package: lintian Version: 2.107.0 Please reconsider changing and extending the context of various tags. More specifically: • debian-watch-uses-insecure-uri old context: the URI new context: the URI plus " (line 2)" • typo-in-manual-page old context: file, space, old word, space, new word

Bug#898867: lintian: embedded-php-library libmarkdown-php vs. php-markdown confusion

Felix Lechner dixit: >> Surprised, I discovered that we have *two* versions of the same >> michelf/php-markdown source in Debian, libmarkdown-php being the >> older 1.0 version. > >Even though some time has passed, neither version seems to be used by >other packages in bullseye. (And, despite

Bug#942013: lintian: non-consecutive-debian-revision: false positive for NMUs

On Wed, 5 May 2021, Felix Lechner wrote: > > X: klibc source: non-consecutive-debian-revision 2.0.8-6 -> 2.0.8-6.1 > > Where may I find your NMU for klibc, please? I haven’t uploaded it yet, let’s give bwh a chance to do it first ;) Attached. bye, //mirabilos -- Sometimes they [people] care

Bug#942013: lintian: non-consecutive-debian-revision: false positive for NMUs

Package: lintian Version: 2.104.0 Followup-For: Bug #942013 X-Debbugs-Cc: t...@mirbsd.de This bug is still pertinent: X: klibc source: non-consecutive-debian-revision 2.0.8-6 -> 2.0.8-6.1 N: P: non-consecutive-debian-revision -- System Information: Debian Release: 11.0 APT prefers

Bug#980560: lintian: unknown-field not meaningfully overridable

Package: lintian Version: 2.104.0 Severity: normal X-Debbugs-Cc: t...@mirbsd.de The renaming of unknown-field-in-dsc and unknown-field-in-control to unknown-field makes it not meaningfully overridable. We now get: W: logind-considered-harmful: unknown-field logind-considered-harmful_73_all.deb

Bug#976669: lintian: please warn about autopkgtests that test rebuilt source, not as-installed, where possible

On Wed, 23 Dec 2020, Andrius Merkys wrote: > false-positives. Even dh_auto_configure appears to be used legitimately dh_auto_configure is the one I’d expect to be used (with autotools). dh_auto_build is the one that raises red flags, and for *some* buildsystems dh_auto_test invokes a

Bug#976669: lintian: please warn about autopkgtests that test rebuilt source, not as-installed, where possible

On Mon, 7 Dec 2020, Andrius Merkys wrote: > In general, autopkgtests should not depend on build tools: compilers, Not entirely true; sometimes, tests need to be built but hopefully against the installed code, only compiling the tests themselves. I’m not entirely sure about pointing that out as

Bug#976669: lintian: please warn about autopkgtests that test rebuilt source, not as-installed, where possible

s are caused and that the rebuilt code is the code being tested. Perhaps specialists for other buildsystems could also be asked whether theirs do that, and errors tagged for those. On Sun, 6 Dec 2020, Paul Wise wrote: > On Sat, Dec 5, 2020 at 6:45 PM Thorsten Glaser wrote: > > > We probably

Bug#966803: acute-accent-in-manual-page: false positive '\\'

On Thu, 19 Nov 2020, Felix Lechner wrote: > Lintian points out only line 992, but not line 86 (see below). Does > that mean Lintian was right but used a misleading tag name? Thanks! Lintian pointed out the ‘'’ part, but it’s the ‘\\’ part which this subthread was about for. Background: I was

Bug#972878: lintian: Wide character in say at Lintian::Output line 156

Felix Lechner dixit: >Feel free to try it. The test case is attached. tglase@tglase-nb:~ $ perl /tmp/x Wide character in say at /tmp/x line 13. UTF-8: ✓ (☃) So lintian maybe behaves different from that testcase? bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#972878: lintian: Wide character in say at Lintian::Output line 156

Felix Lechner dixit: >The issues have been open since 2007 and 2011. We do not currently >have a plan for mitigation. AIUI this only affects buster anyway and not sid? So it will just go away if we wait long enough. bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx

Bug#972844: lintian: E: musescore2 source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 5

Felix Lechner dixit: >"wide-character" Perl warning? No, the first few lines of lintian’s output are literally: N: Using profile debian/main. N: Starting on group musescore2/2.3.2+dfsg3-10 N: Finished processing group musescore2/2.3.2+dfsg3-10 E: musescore2 source: malformed-override Unknown

Bug#972844: lintian: E: musescore2 source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 5

Felix Lechner dixit: >We are unsure about the last bug, especially because you did not >report it in unstable (and it would have been hard to miss). The Perl Ehm, but I’m running unstable and reported it against the version in unstable. (I was actually seeing this in a cowbuilder buildd chroot.)

Bug#972844: lintian: E: musescore2 source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 5

Package: lintian Version: 2.99.0 I’ve been recompiling musescore2_2.3.2+dfsg3-10.dsc (currently in sid) on latest sid, to test it for Qt 5.14 compatibility and latest lintian overrides (modulo #969398, still unfixed). I’m getting this: N: Using profile debian/main. N: Starting on group

Bug#969398: lintian: weird tag doubling (regression)

Package: lintian Version: 2.92.0 Severity: normal X-Debbugs-Cc: t...@mirbsd.de I get output like this: X: sfarklib source: debian-watch-does-not-check-gpg-signature N: P: debian-watch-does-not-check-gpg-signature N: N: This watch file does not specify a means to verify the upstream N:

Bug#672284: lintian: False positive: no-debian-copyright when packages supply debian/$pkgname.copyright

On Mon, 14 May 2012, Jakub Wilk wrote: > But I always thought that we were supposed to documented license and > copyright holders of all files in the _source_ package, so having No. The copyright file exists for the binary packages, and the binary packages alone. ftpmasters require the complete

Bug#966821: lintian: false positive: copyright-without-copyright-notice in antimicro

Package: lintian Severity: normal X-Debbugs-Cc: t...@mirbsd.de https://lintian.debian.org/sources/antimicro/2.23-2.html (unsure which lintian version was used) triggers an FP on copyright-without-copyright-notice as you can see on:

Bug#942013: lintian: non-consecutive-debian-revision: false positive for NMUs

Package: lintian Version: 2.85.0 Followup-For: Bug #942013 This bug still persists (popped up again, apparently; I never saw it before). -- System Information: Debian Release: bullseye/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'),

Bug#966316: lintian: false positive acute-accent-in-manual-page in nroff comment

Package: lintian Version: 2.85.0 Severity: normal X-Debbugs-Cc: t...@mirbsd.de I: makefs: acute-accent-in-manual-page usr/share/man/man8/makefs.8.gz:42 42 .\" * ' generates ’ in gnroff, \' generates ´, so use \*(aq While, yes, the sequence “\'” is there, it’s in a comment (the line begins

Bug#930679: apt-listchanges: changelogs for tglase.lan.tarent.de

On Sat, 25 Apr 2020, root wrote: > * Detect "dh $*" as using the Debhlper sequencer. (Closes: #930679) I’d rather warn on that; $* and $@ are extremely disjunct in GNU make (unlike in shell) and using $* has the chance to break, e.g. if a slash or period ever occur in a rule. bye, //mirabilos

Bug#953811: lintian: handle ADTTMP fallback code

Mattia Rizzolo dixit: >AUTOPKGTEST_TMP is set by sadt since version 2.18.2, which is older than Oh, oops…

Bug#953811: lintian: handle ADTTMP fallback code

Chris Lamb dixit: >Debian tool that is within our locus of control, so I would very much >prefer that src:devscripts is fixed instead of preventing Lintian Oh… looking at it now, it appears that the sid version is indeed fixed. I’ll be keeping this though, for now… I may need it for backports.

Bug#953811: lintian: handle ADTTMP fallback code

Chris Lamb dixit: >Thorsten Glaser wrote: > >> I need to have this code present because I use sadt locally to test >> the autopkgtests, which only sets ADTTMP. > >Noted. However, given that ADTTMP is actually deprecated I would like >to confirm that this is not inste

Bug#953811: lintian: handle ADTTMP fallback code

Package: lintian Version: 2.55.0 Severity: wishlist W: rs source: uses-deprecated-adttmp debian/tests/regress (line 4) This is caused by: tglase@tglase-nb:~/Misc/Vendor/rs $ sed -n 4p debian/tests/regress test -n "$AUTOPKGTEST_TMP" || AUTOPKGTEST_TMP=${ADTTMP:-$TMPDIR} I need to have this code

Bug#935070: [lintian] Tags are too similar

On Fri, 24 Jan 2020, Felix Lechner wrote: > > - latest-debian-changelog-entry-reuses-existing-version checks that ^^^ > > - latest-debian-changelog-entry-without-new-version checks that the

Bug#935070: [lintian] Tags are too similar

On Mon, 19 Aug 2019, Chris Lamb wrote: > > latest-debian-changelog-entry-without-new-version > > latest-debian-changelog-entry-reuses-existing-version > I just checked that they don't have different severities which could > have been a justification for different tags (they don't). Umm…

Bug#947269: lintian: spelling mistake in no-dh-sequencer tag

Package: lintian Version: 2.42.0 Severity: minor For a package that does not use dh7-style debhelper, this is shown: […] N:The debian/rules does not use the dh &@ sequencer. […] I believe the “&@” is a misspelling (probably of “$@”), and people might consider it line noise, too (ponder

Bug#946471: lintian: Use of uninitialized value $section in numeric eq (==) at /usr/share/lintian/checks/manpages.pm line 387.

Package: lintian Version: 2.41.0 Severity: minor Within a directory with the contents from http://www.mirbsd.org/~tg/Debs/dists/sarge/wtf/Pkgs/mirabilos-support/ when I run: lintian -vIiE mirabilos-support_60_i386.changes I get the following: […] N: Unpacking packages in group

Bug#944551: lintian: missing-python-build-dependency false positive

Chris Lamb dixit: >Actually, I believe Lintian is just not considering your python3- >minimal dependency has an adequate Python dependency. Ah okay, that plus the way of detection. >I assume it works fine with that "minimal" version in your package, >but I'm a little hesitant to enlarge the

Bug#942493: 5000 is a tad too small (was Re: lintian: Please warn about overly-long header fields)

Hi Chris, >> […] long Description field > >That's actually a good point, I've left the limit at 5000 and simply >allowed long "long descriptions". great, thank you! bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“

Bug#944551: lintian: missing-python-build-dependency false positive

Package: lintian Version: 2.34.0 musescore-general-soundfont (0.1.8-1) which I’m about to upload triggers this… E: musescore-general-soundfont source: missing-python-build-dependency … despite Build-Depending on python3-minimal. Incidentally, the musescore-general-soundfont-small (0.1.8-1)

Bug#942493: 5000 is a tad too small (was Re: lintian: Please warn about overly-long header fields)

Hi Chris, >I'd prefer to keep it consistent otherwise we run the risk of tweaking >these forever and making it a little bit more transparent for both >developers and users. Bumping to 16,384 now.. ok, thanks! >> [..] my Description > >Not needed or relevant here but do please include concrete

Bug#942493: 5000 is a tad too small (was Re: lintian: Please warn about overly-long header fields)

Hi *, I understand that 5000 is a lot for most fields, but my Description field is a mere 7526 chars long, and the original request was for a warning above 16384 chars(? bytes?). Please reconsider: adjust limits depending on which field it is. bye, //mirabilos -- Stéphane, I actually don’t

Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

Hi Felix, >> Yes, it’s a direct Depends of lintian or one of its direct Depends. > >FTR, I only see it as recommended by libmoo-perl (which is required). indeed, I misspoke as the script uses -o APT::Install-Recommends=true to override the buildd default of false for installing lintian after the

Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

Felix Lechner dixit: >Also, please let us know if your chroot or cowbuilder environment had >libclass-xsaccessor-perl installed. (Note the XS in the name; there Yes, it’s a direct Depends of lintian or one of its direct Depends. >I also committed another fix, which I found more appropriate

Bug#943724: lintian: internal error in Lintian::files::empty_package::_set_is_dummy

Package: lintian Version: 2.31.0 Followup-For: Bug #943724 I’ve just hit this as well, but only in cowbuilder; I cannot seem to reproduce it outside of the chroot. Perhaps a missing dependency (or (recursive) Recommends) that’s installed outside but not inside? N: Processing binary package

Bug#941395: lintian: tries to do math on package version strings: Argument "1exp1" isn't numeric in addition (+)

On Mon, 30 Sep 2019, Chris Lamb wrote: > Thanks. Looks like this was introduced in: > > > https://salsa.debian.org/lintian/lintian/commit/2d29518cfa51025ceaa296b6e8f622f78a6eb5f6 (adding .diff makes that readable in lynx) Erk, this is very Perl-y… I’m sorry to say I don’t know what it does.

Bug#941395: lintian: tries to do math on package version strings: Argument "1exp1" isn't numeric in addition (+)

found 941395 2.24.0 thanks On Mon, 30 Sep 2019, Thorsten Glaser wrote: > Package: lintian > Version: 2.23.0 Oops sorry, I forgot to make the version match the one used in the chroot during build; here, the host version bled through. That being said, running… $ lintian -vIiE --pe

Bug#941395: lintian: tries to do math on package version strings: Argument "1exp1" isn't numeric in addition (+)

Package: lintian Version: 2.23.0 Severity: normal […] N: Processing source package musescore (version 3.2.3+dfsg1-2, arch source) ... Argument "1exp1" isn't numeric in addition (+) at /usr/share/lintian/checks/debian/changelog.pm line 211. […] This is from the presence of… musescore

Bug#914562: lintian: please decide on Debian Enhancement Proposal spelling (harmonise)

Chris Lamb dixit: >I believe Lintian should treat dep.debian.net as the canonical >acronymisation at this point and adopt that. If there is a >consensus and enough hunger for this to change "upstream" then >Lintian will very adopt to it. > >In that light, I've (at least) made it consistent here:

Bug#914562: lintian: please decide on Debian Enhancement Proposal spelling (harmonise)

Package: lintian Version: 2.5.112 Severity: wishlist I found this: /usr/share/lintian/checks/patch-systems.desc:Info: The patch contains a standard DEP-3 template description vs. /usr/share/lintian/checks/upstream-metadata.desc:Info: The DEP 12 metadata file in the source is not readable.

Bug#906211: lintian: python-script-but-no-python-dep despite Recommends

Hi Chris, > > Just wondering what the next steps for Lintian are here? > > Gentle ping on this? sorry, this got lost in the INBOX pile. As you pointed out, there’s currently no way to model the right thing, given the implicit choice in the shebang line. So I think there’s nothing left to do

Bug#906211: lintian: python-script-but-no-python-dep despite Recommends

Hi Chris, > > It might be the python 2-or-3 thing. The lines used to read > > Recommends: python > > and it did not trigger this rule, but recently it started to > > trigger another rule (obsolete python version), so I ported > > the script to work with both 2.7 and 3.6 and extended the > >

Bug#906211: lintian: python-script-but-no-python-dep despite Recommends

Hi Chris, > > Recommends: python | python3 > > > > Binary package also contains the Recommends line (checked). > > > > E: simkolab-common: python-script-but-no-python-dep usr/share/simkolab/ > > php_unserialize.py #!/usr/bin/python > > Can't seem to work out why this triggers. $all_parsed in

Bug#906209: lintian: bugs-field-does-not-refer-to-debian-infrastructure: cannot override

Hi Chris, >I see your point for now. However, the idea is that eventually (!) the >line number and filename will be included in all tags as a bit of >semantic metadata that would not be a required part of an override. > >This will allow us to «inter alia» link to the exact line on

Bug#906209: lintian: bugs-field-does-not-refer-to-debian-infrastructure: cannot override

Hi Niels, >The lintian extra is: "mailto:t.gla...@tarent.de (line 23)" […] >This is not the first time this issue has appeared and I doubt it will >be the last unless lintian gets some features to be more helpful. thanks for this detailled explanation. Is including the line number really

Bug#906209: lintian: bugs-field-does-not-refer-to-debian-infrastructure: cannot override

tags 906209 - moreinfo thanks Hi Chris, >> $ tail -2 debian/simkolab-blackberry.lintian-overrides > >Should this not be debian/source.lintian-overrides or debian/source/ >lintian-overrides? See the "FILES" section in lintian(1) for more info. no, this is a binary package warning (the source

Bug#906211: lintian: python-script-but-no-python-dep despite Recommends

Package: lintian Version: 2.5.96 Severity: normal Source package stanza: Package: simkolab-common […] Recommends: python | python3 […] Binary package also contains the Recommends line (checked). E: simkolab-common: python-script-but-no-python-dep usr/share/simkolab/php_unserialize.py

Bug#906209: lintian: bugs-field-does-not-refer-to-debian-infrastructure: cannot override

Package: lintian Version: 2.5.96 Severity: normal I get both of these at the same time. WTF‽ W: simkolab-blackberry: bugs-field-does-not-refer-to-debian-infrastructure mailto:t.gla...@tarent.de (line 23) I: simkolab-blackberry: unused-override bugs-field-does-not-refer-to-debian-infrastructure

lintian: file-contains-trailing-whitespace only mentions Emacs

Hi, would you please be so kind as to apply the following patch? >From a61fe2c073740c7f843636bca22ce2200eb7ad90 Mon Sep 17 00:00:00 2001 From: mirabilos Date: Fri, 4 May 2018 16:58:37 +0200 Subject: [PATCH] file-contains-trailing-whitespace: also mention jupp ---

Bug#895573: lintian: please add spelling check: “toogle” (toggle)

Package: lintian Version: 2.5.81 Severity: wishlist Hi, I’ve just seen a patch doing s/Toogle/Toggle/ in a package, and lintian doesn’t check for “toogle” currently, so I thought to report in case it might get added ;-) -- System Information: Debian Release: buster/sid APT prefers unreleased

Bug#890361: lintian: handling of new source override location possibly buggy

Hi Chris, >I think you're right. Here's one patch - can you quickly test it works >for you? sorry, I don’t even have a testcase. I only noticed it during looking at the source, trying to figure out whether a symlink in the new position was good enough. > +last if $file; But this is

Bug#890361: lintian: handling of new source override location possibly buggy

Package: lintian Version: 2.5.74 Severity: minor I’m fairly sure the code around lines 56-62 of /usr/share/lintian/collection/override-file does NOT prefer the first (cf. line 44ff.) but the last override file found. I think there’s a break missing in lines 58 and 60. (Or, well, the Perl

Bug#886426: lintian: reports unoverridable bugs in auto-created dbgsym packages

Package: lintian Version: 2.5.67 Severity: minor When building a modified package for my own repo, I get this: N: Processing binary package mksh (version 56b.20180105+wtf1, arch i386) ... N: N: Processing binary package mksh-dbgsym (version 56b.20180105+wtf1, arch i386) ... W: mksh-dbgsym:

Bug#812756: lintian: please make -v imply --no-tag-display-limit

Package: lintian Version: 2.5.40.2 Severity: wishlist Hi, please make -v imply the new option --no-tag-display-limit for those of us who wish to see everything and have muscle memory (or pbuilder hook scripts ;-) for calling lintian -vIiE --pedantic [--color] *.changes Thanks! -- System

Bug#807695: lintian: false positive for command-with-path-in-maintainer-script

Package: lintian Version: 2.5.38.1 Severity: normal I got a false positive for FusionForge in sid: W: gforge-db-postgresql: command-with-path-in-maintainer-script postinst:8 /usr/bin/pg_lsclusters […] N:See particularly the function pathfind() in devref. The line in question: if [ -x

Bug#807695: lintian: false positive for command-with-path-in-maintainer-script

Jakub Wilk dixit: > Guillem Jover requested that command-with-path-in-maintainer-script should > trigger also for "[ -x ... ]" constructs in #769845. Unfortunately, the tag I think his reasoning for that is wrong, more below. > description wasn't adequately updated when this change was

Bug#800438: lintian: stop warning about versioned Provides

Package: lintian Version: 2.5.37 Severity: normal E: texlive-full-without-ruby: versioned-provides texlive-lang-japanese (= 2015) Versioned Provides can be used in sid TTBOMK (they started working with dpkg from jessie), so lintian should stop marking this as an error iff the package targets

Bug#786895: lintian: incompatible-java-bytecode-format warning needs update for Java 1.7

On Wed, 27 May 2015, Rene Engelhard wrote: I know, there at least we need to kill gcj support. But until then. Or we decide we don't care ab out 1.5/gcj now. Explicitely. On Wed, 27 May 2015, Markus Koschany wrote: Niels and Emmanuel have already pointed out the most important facts why we

Bug#762460: lintian: out of sync with Policy (3.9.6.0 is out)

Package: lintian Version: 2.5.27 Severity: wishlist Just a reminder that lintian should recognise Policy v3.9.6.0 before the freeze occurs ☺ -- System Information: Debian Release: jessie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')

Bug#758030: lintian: non-free creative commons files

Bastien ROUCARIES dixit: Could we have a clear statement ? The policy is pretty clear on the additional non-free requirements. Mediawiki upstream hinted at them being in talk with CC about this, but that was a year ago or so, and I’d rather not have these files in here. To add insult to injury

Bug#758030: lintian: non-free creative commons files

Package: lintian Version: 2.5.25 Severity: wishlist Hi! https://lists.debian.org/debian-devel-announce/2014/02/msg0.html requested bugreports with information about nōn-free files. Creative Commons™ uses trademarked and/or otherwise protected files, logos, images, etc. with a rather

Bug#681616: lintian: False positive: unused-license-paragraph.. when two licenses are given and described in different places

Niels Thykier dixit: If there are no remaining lines, [...]. Otherwise, this field should either include the full text of the license(s) or include a pointer to the license file under /usr/share/common-licenses. [...] Ah so this is an either-or. license in /usr/share/common-licenses). The

Bug#688320: lintian: --suppress-tags not working?

Package: lintian Version: 2.5.10.1 Severity: minor Hi, in a Debian wheezy cowbuilder instance on one of our Jenkins buildbots, I am calling lintian like this: lintian -vIi --display-experimental --pedantic --suppress-tags package-has-long-file-name -X nmu --allow-root

Bug#647028: sbuild and the Distribution field in .changes

Hi, my thoughts on this: = sbuild side = Apparently, sbuild is used by buildds and developers, with differing needs. There should be a switch to sbuild, which buildd calls but developers don’t, that enables Distribution overriding (for example for binNMUs to packages in testing that were

Bug#638278: Bits from the Lintian maintainers

Niels Thykier dixit: I did (BCC it), the bug is #638278. I took the liberty of marking you as the submitter. OK, no problem. Emails in my inbox has a way of disappearing even if I tag them TODO etc, so when I can I file bugs if I cannot handle them immediately. Yeah, still before doing all

Bug#546927: lintian: still complains about AnonCVS

Package: lintian Version: 2.2.15 Severity: minor $ dget http://incoming.debian.org/mksh_39.1-1.dsc $ lintian -vIi mksh_39.1-1.dsc yields: I: mksh source: vcs-field-uses-not-recommended-uri-format vcs-cvs :ext:_anon...@anoncvs.mirbsd.org:/cvs contrib/hosted/tg/deb/mksh Apparently, the regex is

Re: Vcs-CVS, again

Russ Allbery dixit: future could you please file a bug if you run into a false positive like this? I work on Lintian pretty much entirely from the BTS, so if it isn't a bug, it tends to fall off my radar. Oh ok. No, it was a regular mail, IIRC. Yeah, why would you go to Subversion when you

Vcs-CVS, again

Hi again! Lintian gives me an informative message about: Vcs-CVS: :ext:_anon...@anoncvs.mirbsd.org:/cvs contrib/hosted/tg/deb/mksh As far as I can see, it “chokes” on the :ext: (since :pserver: ought to have died long ago…) I think I reported that already, some time ago. Any news from this

lintian and Vcs-CVS: fields

Hi all! $ tail -1 /usr/src/contrib/hosted/tg/deb/mksh/debian/source.lintian-overrides mksh source: vcs-field-uses-not-recommended-uri-format vcs-cvs :ext:_anon...@anoncvs.mirbsd.org:/cvs contrib/hosted/tg/deb/mksh Sorry, but pserver must die. (By the way, Vcs-CVS: fields are often

Bug#519268: lintian: same problem in mksh, but with a twist

Package: lintian Version: 2.2.8 Severity: normal E: mksh: diversion-for-unknown-file $2 postinst:16 E: mksh: package-uses-local-diversion postinst:24 E: mksh: package-uses-local-diversion prerm:16 E: mksh: orphaned-diversion $2 postinst I have the same problem (although I'm not exactly sure

Bug#498075: lintian: unusual-interpreter … #!/bin/mksh

Package: lintian Version: 1.24.2.1 Severity: wishlist #!/bin/mksh is not recognised by lintian yet. Please refer to the mksh package for a candidate. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux

Bug#498082: lintian: false positive in manpages

reassign 498082 man-db thanks Russ Allbery dixit: The error message is coming from man --warnings. It's possible that it may have some sort of problem. Can you double-check first that you have the most current man-db package? If so, I'll transfer the bug there. Oh okay. Sure. ii man-db