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

[Thorsten Glaser]

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 from the upstream release
announcement).

I find that lintian is overly opinionated here. I could agree,
were this just a single line (given the tag’s stated purpose),
but not for multi-line or lists.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

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

[Thorsten Glaser]

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
  * Security fixes
[…]

I find this a little opinionated anyway, but here not quite
appropriate as the changelog “line” spans more than a physical
line. Maybe, if you won’t consider the space until the next
/^  \* / a “line”, then at least exclude itemisations from that tag?

Thanks.

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

[Thorsten Glaser]

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: commit:10065BC69BE555D6721

Description is the standard name for Subject (the same way
Author is the standard DEP 3 name for From), and it’s present,
and when Origin indicates an upstream commit (as shown here),
Author does not need to be present, per DEP 3.

bye,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………

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

[Thorsten Glaser]

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: commit:10065BC69BE555D6721

DEP 3 says the Forwarded header is only applicable for
patches that don’t originate upstream.

bye,
//mirabilos

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

[Thorsten Glaser]

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] 
[usr/share/lintian/overrides/mksh:2]

(no longer matches because it’s no longer recognised as statically linked)

W: mksh: shared-library-lacks-prerequisites [bin/lksh]

static-pie executables look like this:

t: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, 
with debug_info, not stripped
(bullseye file(1))

t: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, 
with debug_info, not stripped
(sid file(1))

By contrast, nōn-PIE static executables look like this:

/bin/lksh: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically 
linked, stripped
(both versions)

And shared libraries look like this:

t.dll: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically 
linked, with debug_info, not stripped
(both versions)

My guess is that lintian looks at 'dynamically linked' either
from inspecting file(1) output or by doing the same thing that
bullseye’s file(1) did to determine whether an object is shared
or not, without taking into account whether the object is an
executable or not, which the ELF headers have flags for.




-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 
'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 5.10.0-26-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils2.42-4
ii  bzip2   1.0.8-5.1
ii  diffstat1.66-1
ii  dpkg1.22.6
ii  dpkg-dev1.22.6
ii  file1:5.45-3
ii  gettext 0.21-14+b1
ii  gpg 2.2.40-3
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.16.0-1
ii  libapt-pkg-perl 0.1.40+b5
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b3
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b3
ii  libclone-perl   0.46-1+b2
ii  libconfig-tiny-perl 2.30-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1+b2
ii  libdata-dpath-perl  0.59-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-3
ii  libdevel-size-perl  0.83-2+b3
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.6
ii  libemail-address-xs-perl1.05-1+b3
ii  libencode-perl  3.21-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.025-1
ii  libipc-run3-perl0.049-1
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b3
ii  libperlio-utf8-strict-perl  0.010-1+b2
ii  libproc-processtable-perl   0.636-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1+b2
ii  libsereal-encoder-perl  5.004+ds-1+b2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-2
ii  libterm-readkey-perl2.38-2+b3
ii  libtext-levenshteinxs-perl  0.03-5+b3
ii  libtext-markdown-discount-perl  0.16-1+b2
ii  libtext-xslate-perl 3.5.9-2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b3
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2+b2
ii  liburi-perl 5.28-1
ii  libwww-mechanize-perl   2.18-1
ii  libwww-perl 6.77-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b3
ii  libyaml-libyaml-perl0.89+ds-1+b1
ii  lzip [lzip-decompressor]1.24.1-1
ii  lzop1.04-2
ii  man-db  2.12.0-4
ii  patchutils  0.4.2-1
ii  perl 

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

[Thorsten Glaser]

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?

[Thorsten Glaser]

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 breaks only a subset. This would have to be fixed to

No, because the not-broken subset Depends on rng-tools-debian.
(It’s a transitional package.) So, while it cannot be seen by
“just” inspecting rng-tools-debian, all possible combinations
are covered.

(Also, the transition is done and rng-tools is gone.)

bye,
//mirabilos
-- 
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against
 ╳  HTML eMail! Also,
╱ ╲ header encryption!

Bug#1036712: Replaces without Breaks or Conflicts harmful?

[Thorsten Glaser]

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 false positive:

Replaces: intel-rng-tools, rng-tools
Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate)
Conflicts: intel-rng-tools

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

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

[Thorsten Glaser]

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 normal thing to have. You only update the copyright year
for something when *you* do something relevant for copyright law (that
is passing the threshold of originality) in that year.

Having this tag is misleading because it’ll lead to people bumping the
year because they don’t know better and just to silence lintian.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 
'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils2.39-8
ii  bzip2   1.0.8-5+b1
ii  diffstat1.64-1
ii  dpkg1.21.9+b1
ii  dpkg-dev1.21.9
ii  file1:5.41-4
ii  gettext 0.21-10
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.12.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.9
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.58-3
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.124-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1+b1
ii  libsereal-encoder-perl  5.001+ds-2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.27-1+b1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.13-2
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b4
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.84+ds-1+b1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.11.1-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-4
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xz-utils5.2.8-0.0

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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 large changes,
but upstream (and, then, perhaps the source code is, for example,
commented in, and uses variable names in, French… *shudder*).

OK, so the distro’s data may give people an idea where to work on.
It may also lead to duplicated investigative efforts.

Perhaps something like repro-builds have, a repository with notes
on individual packages, where people who once investigated one thing
could note this down, and which interested porters would use as the
main entry point *instead of* the raw lintian stats, would be useful?

You could then mechanically create files in that repo for packages
which show up in lintian but don’t have such notes yet, to signal
that they show up.

Just my “five minutes of thinking about this”, nothing deep.

bye,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

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

[Thorsten Glaser]

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, 'unstable-debug'), (500, 'buildd-unstable'), (500, 
'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils2.38.90.20220713-2
ii  bzip2   1.0.8-5
ii  diffstat1.64-1
ii  dpkg1.21.9
ii  dpkg-dev1.21.9
ii  file1:5.41-4
ii  gettext 0.21-9
ii  gpg 2.2.39-1
ii  intltool-debian 0.35.0+20060710.5
ii  iso-codes   4.11.0-1
ii  libapt-pkg-perl 0.1.40+b1
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-1+b2
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-4
ii  libclone-perl   0.45-1+b2
ii  libconfig-tiny-perl 2.28-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.9
ii  libemail-address-xs-perl1.05-1
ii  libencode-perl  3.19-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-2
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-2
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.12-1
ii  libmldbm-perl   2.05-3
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.122-1
ii  libperlio-gzip-perl 0.20-1
ii  libperlio-utf8-strict-perl  0.009-1+b1
ii  libproc-processtable-perl   0.634-1+b1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1
ii  libsereal-encoder-perl  5.001+ds-1
ii  libsort-versions-perl   1.62-2
ii  libsyntax-keyword-try-perl  0.27-1
ii  libterm-readkey-perl2.38-2
ii  libtext-levenshteinxs-perl  0.03-5
ii  libtext-markdown-discount-perl  0.13-1+b1
ii  libtext-xslate-perl 3.5.9-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-2
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b3
ii  liburi-perl 5.12-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1
ii  libyaml-libyaml-perl0.84+ds-1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.10.2-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.34.0-5
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xz-utils5.2.5-2.1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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: debian-watch-uses-insecure-uri 
http://www.mirbsd.org/MirOS/dist/mir/mksh/ (line *)

-mksh: typo-in-manual-page usr/share/man/man1/mksh.1.gz ot to
+mksh: typo-in-manual-page usr/share/man/man1/mksh.1.gz line * ot to

These changes correctly override the issues.

I’ve not yet tested (e.g. by inserting an actual misspelling into the
manpage) whether the asterisk indeed allows anything to come after,
i.e. “line * ot to” isn’t equivalent to “line *”…

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

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

[Thorsten Glaser]

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) harder.

>Would it help for your override issue to relegate
>the line numbers to the end of the context? Thanks!

Can I use a wildcard then? Something like

mksh: typo-in-manual-page usr/share/man/man1/mksh.1.gz ot to *

I remember wildcards not always working right, but then, I’ve
been first using lintian in tandem with linda so I don’t know
which century that might have been not working well…

bye,
//mirabilos
-- 
 den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │  damals, als der pizzateig noch auf dem monior "gegangen" ist

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

[Thorsten Glaser]

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
  new context: file, space, "line ", line number, space, old word, space, new 
word

In both cases the old context made it perfectly usable to override
the specific instance as it was fully sufficient to find it. (I would
not, for example, want to override typo-in-manual-page for the entire
file, but the “ot” here is correct (“test file1 -ot file2”), and it
moves lines with releases and my time is better spent elsewhere than
on needless lintian override churn.)

So, please revert this change for these two tags at least, and consider
reviewing the other tags, specifically whether less context may actually
be enough to identify the issue in question, as is here, where the line
number, which is a more fragile identifier, is not needed.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

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

[Thorsten Glaser]

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 your message, movim
>0.17.1-1.1 in unstable does not seem to use it, either.) Should

I don’t follow: movim in sid depends on php-markdown:

$ apt-cache rdepends -i php-markdown libmarkdown-php
php-markdown
Reverse Depends:
  movim
  movim
libmarkdown-php
Reverse Depends:

$ apt-cache policy php-markdown libmarkdown-php
php-markdown:
  Installed: (none)
  Candidate: 1.8.0-1.1
  Version table:
 1.8.0-1.1 500
500 http://deb.debian.org/debian sid/main amd64 Packages
500 http://deb.debian.org/debian sid/main i386 Packages
libmarkdown-php:
  Installed: (none)
  Candidate: 1.0.2-3
  Version table:
 1.0.2-3 500
500 http://deb.debian.org/debian sid/main amd64 Packages
500 http://deb.debian.org/debian sid/main i386 Packages

The one lintian recommends, libmarkdown-php, seems to not have any
users though *and* is older. If it has no reverse B-D either, it
probably should be removed.

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

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

[Thorsten Glaser]

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 too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"Format: 3.0 (quilt)
Source: klibc
Binary: libklibc-dev, libklibc, klibc-utils
Architecture: linux-any
Version: 2.0.8-6.1
Maintainer: Debian Kernel Team 
Uploaders: Ben Hutchings , maximilian attems 
Homepage: https://git.kernel.org/cgit/libs/klibc/klibc.git
Standards-Version: 4.1.2
Vcs-Browser: https://salsa.debian.org/kernel-team/klibc
Vcs-Git: https://salsa.debian.org/kernel-team/klibc.git
Build-Depends: debhelper-compat (= 12), linux-libc-dev, m4 [sparc]
Build-Conflicts: ccache
Package-List:
 klibc-utils deb libs optional arch=linux-any
 libklibc deb libs optional arch=linux-any
 libklibc-dev deb libdevel optional arch=linux-any
Checksums-Sha1:
 eaa050b663783e1278c9038a76c21a605af701c9 472200 klibc_2.0.8.orig.tar.xz
 2ca3434380de25cc6b9aa9080fc5feb5752f484c 26008 klibc_2.0.8-6.1.debian.tar.xz
Checksums-Sha256:
 4e48f1398cfe3ce0b6df55ce6e70acf54fc8488e3aea3fb3610ee1622d9cb436 472200 klibc_2.0.8.orig.tar.xz
 0f02c2c6767c2cd4282dcca1065d8d5e99e46614c9628b261b8e0c92f3cfe0cd 26008 klibc_2.0.8-6.1.debian.tar.xz
Files:
 bdd05bf16fce534e7a49d98644cdec87 472200 klibc_2.0.8.orig.tar.xz
 da02991a022086b2f2e6faebc4b96809 26008 klibc_2.0.8-6.1.debian.tar.xz


klibc_2.0.8-6.1.debian.tar.xz
Description: application/xz

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

[Thorsten Glaser]

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 unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils2.35.2-2
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.26-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
ii  libdigest-sha-perl  6.02-1+b3
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.430-2
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012001-2
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.08-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.22-3
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.1-4
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35.2-2
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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 Important

This hardcodes the filename of the result, which includes the version
and architecture of the package, which makes it hard to update with
each new upload *and* not Multi-Arch safe.

Please change the output format of this tag to not embed the full
pathname; an indicator of _where_ is enough… which, IMHO, already
is given in the package name (or source name) tag.

I know that I can override it with just…

logind-considered-harmful: unknown-field

… but maybe I *do* want to be warned about others?


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils2.35.1-7
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.7.1
ii  dpkg-dev1.20.7.1
ii  file1:5.39-3
ii  gettext 0.21-3
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b4
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b6
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.7.1
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.430-2
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-2
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012000-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.06-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.21-8
ii  lzop1.04-2
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.0-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-1.0

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35.1-7
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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 make/maven/whatever target
that implies build if it was not built before. These uses, when
it can be done reliably, should also flag.

Examples for dh_auto_test:

• Many Makefiles for autotools-using packages contain lines like:

check: all

  If this is present, it should warn. But since this is not present
  everywhere, we can probably not warn due to too many false positives.

• With Maven, calling “mvn test” will *always* build the source
  if it was not already built and test the just-compiled sources.
  Here we CAN reliably flag.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*

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

[Thorsten Glaser]

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 a lintian warning
already. If too many packages rightfully use it, maintainers will
become annoyed. On the other hand, it might serve to point people
at this. Also, @builddeps@ is in the spec, even if it’s requested
to be used sparingly.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*

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

[Thorsten Glaser]

Package: lintian
Severity: wishlist
X-Debbugs-Cc: debian-j...@lists.debian.org

Hi lintian people,

the request is, of course, not generally solvable. However, for
a few buildsystems and ways to “test”, this is possible, and
these should be warned about (probably at Error level even).

It all begun with…

>  I find java packages with maven-debian-helper can be tested by:
> 
>  
>  Test-Command: dh_auto_configure; dh_auto_test

The trouble here is that, with maven-debian-helper in Build-Depends
and used (if pom.xml exists, it’s used), this calls “mvn test”, and
Maven helpfully expands this to “mvn compile test” because the source
is not yet compiled. It’s probably much more involved to do as-installed
testing with Maven… but that’s for d-java@l.d.o to figure out.

But some people are using this, and this should be an Error.


Some other buildsystems also do this. I don’t know many, but
for example some Makefile-based ones also have a “test: build”
dependency. So maybe the mere presence of dh_auto_test in a
testcase should also be warned about, but with a much lower
severity than Error. Error should be used for these we positively
know about that rebuilds 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 should let maven-debian-helper’s dh module
> > abort any building (dh_auto_{build,test}) if run under
> > autopkgtests to enforce this.
> 
> I'd suggest to start with a lintian warning about this and maybe when
> there are fewer packages using it, then change the dh module.

Good point. I’m doing so with this.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*

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

[Thorsten Glaser]

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 looking for the acute-accent-related bug number
again to comment an override in another package (#966316 though)
by searching for acute, found this and, having worked with nroff
(AT’s, even) quite a bit, decided to chime in.


In the xfig(1) case, there’s a *lot* of acute accents used though:

  990 e.g., '$' or '\e', are not quoted but left untouched in the text string.
  991 This is most useful for writing LaTeX equations.
  992 If this flag is not set, then the backslash character '\\' is changed

(Funnily enough, line 990 gets using \e for the backslash right,
992 doesn’t.)


A sole 「'」 gets rendered as 「’」 in gnroff’s UTF-8 mode normally.
I think Debian disabled that due to exactly this issue.

But (as we can see in the *comment* lintian tags in #966316) using
「\'」 renders 「´」 which is usually wrong. This is what lintian is
supposed to tag. However, in this case, we have 「\\'」 which only
expands to 「\'」 if it’s part of a macro which is then later evaluated.
(This is why we use \e for the backslash incidentally.)


So, no, lintian was not right here either, but it was not entirely
wrong as, under certain circumstances, this _can_ be rendered as ´.


How to get lintian to DTRT, though, is… very difficult. I think you
need a full nroff parser (mdocml, while probably friendlier to modify,
only parses certain constructs, which may or may not be enough). Or
scan for ´ in the formatted output and suppress the tag if it doesn’t
occur, as a hack (if ´ occurs and is deliberate, people will have to
override the tag anyway).

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

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

[Thorsten Glaser]

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

[Thorsten Glaser]

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 for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

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

[Thorsten Glaser]

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 tag 
testsuite-autopkgtest-missing in line 5
N:
E: malformed-override

bye,
//mirabilos

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

[Thorsten Glaser]

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.)

bye,
//mirabilos

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

[Thorsten Glaser]

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 musescore2/2.3.2+dfsg3-10
N: Finished processing group musescore2/2.3.2+dfsg3-10
E: musescore2 source: malformed-override Unknown tag 
testsuite-autopkgtest-missing in line 5
N:
E: malformed-override
N:
N:   Lintian discovered an override entry with an invalid format. An
[…]

The overrides file contains just this:

-
# github doesn’t expose those
musescore2 source: debian-watch-does-not-check-gpg-signature

# not usable / suitable / useful, unfortunately
musescore2 source: testsuite-autopkgtest-missing

# oh really?! what the ever…
musescore2 source: cute-field
-

Something really weird is happening here; lintian output has
become less reliable and more hard to parse in the last few
months…

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

[Thorsten Glaser]

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:   tarball using a cryptographic signature.
[…]

The second and third line are new and probably should not be there
(the extra N: and the P: ones).

-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils2.35-2
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.38-5
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b2
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.21-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdigest-sha-perl  6.02-1+b2
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004002-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004000-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.018+ds-1
ii  libsereal-encoder-perl  4.018+ds-1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.010005-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 1.76-2
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.04-1
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35-2
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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 copyright/licence
of the upstream sources to be present in the origtgz (I once had
one where the licence was not present in the tarball but added
in a debian diff; this was deemed inacceptable (mirrors must be
permitted to redistribute only a part), and debian/ is often not
even worth documenting.

I’ve had a package with a debian/copyright.in that copied, at
build time, the upstream copyright notice at the end. This was
deemed acceptable but not nice, and I ended up changing it to
doing to in the clean target (so the source package ships both
debian/copyright.in and debian/copyright) but this was strictly
for tooling/QA.

This is, by the way, one of the reasons why I think DEP 5 to be
complete nōnsense. It doesn’t fit the Debian model.

And yes, it’s completely acceptable to have diverging copyright
files between binary packages.

bye,
//mirabilos
-- 
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
   veni, vidi, fixi(t) ;-)

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

[Thorsten Glaser]

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:
https://metadata.ftp-master.debian.org/changelogs//main/a/antimicro/antimicro_2.23-2_copyright

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.35-1
ii  bzip2 1.0.8-4
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libsereal-decoder-perl4.017+ds-1
ii  libsereal-encoder-perl4.017+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  man-db2.9.3-2
ii  patchutils0.4.2-1
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35-1
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.35-1
ii  bzip2 1.0.8-4
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b2
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdigest-sha-perl6.02-1+b2
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libsereal-decoder-perl4.017+ds-1
ii  libsereal-encoder-perl4.017+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  man-db2.9.3-2
ii  patchutils0.4.2-1
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35-1
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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 with “.\"” which is one of the ways to add comments in nroff)
and therefore a false positive. Shouldn’t be too hard to fix (but
mind there are multiple ways for commenting in nroff).

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.35-1
ii  bzip2 1.0.8-4
ii  diffstat  1.63-1
ii  dpkg  1.20.5
ii  dpkg-dev  1.20.5
ii  file  1:5.38-5
ii  gettext   0.19.8.1-10
ii  gpg   2.2.20-1
ii  intltool-debian   0.35.0+20060710.5
ii  libapt-pkg-perl   0.1.36+b3
ii  libarchive-zip-perl   1.68-1
ii  libcapture-tiny-perl  0.48-1
ii  libclass-xsaccessor-perl  1.19-3+b5
ii  libclone-perl 0.45-1
ii  libconfig-tiny-perl   2.24-1
ii  libcpanel-json-xs-perl4.19-1
ii  libdata-dpath-perl0.58-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdevel-size-perl0.83-1+b1
ii  libdpkg-perl  1.20.5
ii  libemail-address-xs-perl  1.04-1+b2
ii  libfile-basedir-perl  0.08-1
ii  libfile-find-rule-perl0.34-1
ii  libfont-ttf-perl  1.06-1
ii  libhtml-parser-perl   3.72-5
ii  libio-async-loop-epoll-perl   0.21-1
ii  libio-async-perl  0.77-3
ii  libjson-maybexs-perl  1.004002-1
ii  liblist-compare-perl  0.53-1
ii  liblist-moreutils-perl0.416-1+b5
ii  liblist-utilsby-perl  0.11-1
ii  libmoo-perl   2.004000-1
ii  libmoox-aliases-perl  0.001006-1
ii  libnamespace-clean-perl   0.27-1
ii  libpath-tiny-perl 0.114-1
ii  libsereal-decoder-perl4.017+ds-1
ii  libsereal-encoder-perl4.017+ds-1
ii  libtext-levenshteinxs-perl0.03-4+b7
ii  libtext-xslate-perl   3.5.8-1
ii  libtime-duration-perl 1.21-1
ii  libtime-moment-perl   0.44-1+b2
ii  libtimedate-perl  2.3300-1
ii  libtry-tiny-perl  0.30-1
ii  libtype-tiny-perl 1.010002-1
ii  libunicode-utf8-perl  0.62-1+b1
ii  liburi-perl   1.76-2
ii  libxml-libxml-perl2.0134+dfsg-2
ii  libxml-writer-perl0.625-1
ii  libyaml-libyaml-perl  0.82+repack-1
ii  man-db2.9.3-2
ii  patchutils0.4.2-1
ii  perl [libdigest-sha-perl] 5.30.3-4
ii  t1utils   1.41-4
ii  xz-utils  5.2.4-1+b1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35-1
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Bug#953811: lintian: handle ADTTMP fallback code

[Thorsten Glaser]

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

[Thorsten Glaser]

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.

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#953811: lintian: handle ADTTMP fallback code

[Thorsten Glaser]

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 instead a bug in sadt(1) instead.

I’m certain it is ☻ but I wrote the autopkgtest script conservatively.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#953811: lintian: handle ADTTMP fallback code

[Thorsten Glaser]

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 present because I use sadt locally to test
the autopkgtests, which only sets ADTTMP. It also has even older
support for if both aren’t set.

Please whitelist this, perhaps don’t flag ADTTMP if it shows up
on a line beginning with “test -n "$AUTOPKGTEST_TMP" ||”.

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils 2.34-4
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.19-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.67-2
ii  libberkeleydb-perl   0.62-1+b1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.46-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libdevel-size-perl   0.83-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  libjson-perl 4.02000-2
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3200-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.008001-2
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libyaml-libyaml-perl 0.81+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.34-4
ii  libhtml-parser-perl3.72-5
pn  libtext-template-perl  

-- no debconf information

Bug#935070: [lintian] Tags are too similar

[Thorsten Glaser]

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
^^^

> As you point out, the former strips the epoch before comparing. It
> seemed to include the latter (and both tags had the same severity).

Does it?

> > PS: Personally I’m not negatively affected by removal of the latter,
> > it was always annoying for local backports, but it might have
> >saved someone else from a brown paper bag upload…
>
> Did you see a d/changelog that triggered the latter but not the former?

Yes:packagename (upstreamversion-1~wtf1)
followed by packagename (upstreamversion-1)

(or even ~bpo10+1, when there was not the word “backport” in the
changelog text)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#935070: [lintian] Tags are too similar

[Thorsten Glaser]

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… as I always understood it these are completely different:

- latest-debian-changelog-entry-reuses-existing-version checks that
  the version without the epoch is never reused, for the archive and
  snapshots to be consistent (as the epoch is not used in filenames)

- latest-debian-changelog-entry-without-new-version checks that the
  upload does not have a smaller (or equal) version number to the
  previous upload except in backports, to ensure that it’ll be newer
  and nobody forgot a version increment before uploading

Just wondering,
//mirabilos

PS: Personally I’m not negatively affected by removal of the latter,
it was always annoying for local backports, but it might have
saved someone else from a brown paper bag upload…
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

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

[Thorsten Glaser]

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
whether this should be included in the message at all).


-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils 2.33.1-6
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-6
ii  gettext  0.19.8.1-10
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b1
ii  libarchive-zip-perl  1.67-1
ii  libberkeleydb-perl   0.62-1+b1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libdigest-sha-perl   6.02-1+b2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.008000-1
ii  liburi-perl  1.76-1
ii  libxml-libxml-perl   2.0134+dfsg-1+b1
ii  libyaml-libyaml-perl 0.80+repack-2+b1
ii  man-db   2.9.0-2
ii  patchutils   0.3.4-2
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.33.1-6
ii  libhtml-parser-perl3.72-3+b4
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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 mirabilos-support/60
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
N: 
[…]

This happens neither on the .dsc nor on the .deb containing the
manpages (mirabilos-support_60_all.deb), only when doing lintian
on the .changes file.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils 2.33.1-5
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-6
ii  gettext  0.19.8.1-10
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b1
ii  libarchive-zip-perl  1.67-1
ii  libberkeleydb-perl   0.62-1+b1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libdigest-sha-perl   6.02-1+b2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-libxml-perl   2.0134+dfsg-1+b1
ii  libyaml-libyaml-perl 0.80+repack-2+b1
ii  man-db   2.9.0-1
ii  patchutils   0.3.4-2
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.33.1-5
ii  libhtml-parser-perl3.72-3+b4
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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 allowed packages to include
>these wwithout knowing more about the subtle differences between them
>all...

I must confess I don’t know either… the script I wrote that’s used
during the build process works with -minimal so I used that to keep
the B-D low, but I’m nowhere near skilled in the Python ecosystem
to answer that.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

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

[Thorsten Glaser]

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.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

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

[Thorsten Glaser]

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) sister package doesn’t
trigger it.

The -small one (doesn’t trigger) uses py3k in d/rules like this:

set -- *.[Ss][Ff]2; \
cmt=$$(sed '1,/^Licence:$$/d' debian/copyright | sed 1d; echo x); \
python3 debian/riffedit.py "$$1" builddir/tmp.sf2 \
  […]

The full one (triggers) has an additional line:

python3 debian/riffedit.py \
builddir/tmp.sf2 builddir/${sfbasename}.sf2 \
-az 'LIST/INAM' '${sfbasename}.sf2'

I suspect the check is flawed in that it checks for debian/rules
lines matching /^\tpython/ (so it doesn’t trigger when the call
is part of a pipeline; if so, the 0.1.7-2 version currently in the
archive would also trigger this false positive) and mis-detects
the py3k call as a call to python.

bye,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

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

[Thorsten Glaser]

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 references
>(vs. "my") next time -- can save some round-trips and confusion in
>many cases. :)

Sure, but this time it was about the general case of a package
long Description field ;-)

Have a nice evening,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

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

[Thorsten Glaser]

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 block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

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

[Thorsten Glaser]

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 build ONLY.

>> This fixes the issue for me when I hand-apply it in the chroot to
>> …/usr/share/perl5/Lintian/Collect/Binary.pm
>
>Thanks for testing the proposed fix. Please accept our apologies for
>the inconvenience.

No problem, and thanks for the quick fix!

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

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

[Thorsten Glaser]

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 after
>discussing the issue with Moo's author. The commit message has more
>details and is replicated below.
>
>are other similar packages in the archive.)
>
>
> https://salsa.debian.org/lintian/lintian/commit/b951f0d4d83fa76286d1f4bd5836cf256038f31c

This fixes the issue for me when I hand-apply it in the chroot to
…/usr/share/perl5/Lintian/Collect/Binary.pm

Thanks,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

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

[Thorsten Glaser]

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 fonts-campania (version 2.009-1, arch all) ...
[…]
Usage: Lintian::files::empty_package::_set_is_dummy(self, newvalue) at 
/usr/share/lintian/checks/files/empty-package.pm line 42.
internal error: cannot run files check on package 
binary:fonts-campania/2.009-1/all
warning: skipping check of binary:fonts-campania/2.009-1/all
N: Finished processing group campania/2.009-1

Both the host system and the cowbuilder chroot are freshly dist-upgraded sid.

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils 2.33.1-2
ii  bzip21.0.8-2
ii  diffstat 1.62-1+b1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-6
ii  gettext  0.19.8.1-9
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b2
ii  libarchive-zip-perl  1.67-1
ii  libberkeleydb-perl   0.62-1+b1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclone-perl0.41-1+b2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.74-1
ii  libipc-run-perl  20180523.0-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003004-2
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-simple-perl   2.25-1
ii  libyaml-libyaml-perl 0.80+repack-2+b1
ii  man-db   2.9.0-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.33.1-2
ii  libhtml-parser-perl3.72-3+b4
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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.

The string after the last hyphen-minus is the maintainer version, but
it’s almost free-form, except for not containing a hyphen-minus itself;
there are some assigned meanings (N.N means NMU, ~bpoN+N means backport,
etc.) but it can get convoluted: something like…

foo (= 1:2.3-4.5~deb6u7ubuntu8tarent9~ppa1404+1)

… is conceivable.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

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

[Thorsten Glaser]

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 --pedantic musescore_3.2.3+dfsg1-2.dsc

… with 2.23.0 also shows the message.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

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

[Thorsten Glaser]

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 (3.2.3+dfsg1-1exp1) experimental; urgency=low

… as second entry in d/changelog. The “exp” clearly is a string part.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils 2.32.51.20190909-1
ii  bzip21.0.8-2
ii  diffstat 1.62-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-5
ii  gettext  0.19.8.1-9
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36
ii  libarchive-zip-perl  1.66-2
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclone-perl0.41-1+b1
ii  libdigest-sha-perl   6.02-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.74-1
ii  libipc-run-perl  20180523.0-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b4
ii  libmoo-perl  2.003004-2
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-simple-perl   2.25-1
ii  libyaml-libyaml-perl 0.80+repack-2
ii  man-db   2.8.7-3
ii  patchutils   0.3.4-2
ii  perl [libdigest-sha-perl]5.28.1-6
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.32.51.20190909-1
ii  libhtml-parser-perl3.72-3+b3
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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:

Agreed, thanks!

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

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

[Thorsten Glaser]

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.  This

I also carry the DEPs in my acronyms database, but I would like to
avoid repeating them as “DEP 3”, “DEP-3”, “DEP3” and use only one
spelling of them.

Personally I’d prefer DEP-3, but the http://dep.debian.net/ site
uses “DEP 3” spelling (with ASCII space in between), except in
the URLs which have “dep3”.

Please d̲o̲ contact the and interact with the people behind the DEP
system; I’ve just reported this against lintian because it often
refers people to one or another DEP and therefore is probably the
most visible place for their spelling.


-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils   2.31.1-7
ii  bzip2  1.0.6-9
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.2
ii  dpkg-dev   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-9
ii  gpg2.2.11-1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.75+repack-1
ii  man-db 2.8.4-3
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.28.0-4
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-7
ii  libhtml-parser-perl3.72-3+b3
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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 for lintian
(feel free to close the bug if you agree), and I’ll
go with an override, for now. In this particular
case, being a Recommends, needed only for a helper
script shipped by the package, and given that half
the package relationship matches, I think that’s ok.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

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

[Thorsten Glaser]

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
> > Recommends so either version would suffice.
> 
> In that case, regardless of the Lintian logic here your OR is not
> correct for this package. Gven that the shebang points to
> #!/usr/bin/python (ie. Python 2.x) this would not be satisfied by the
> "| python3" suffix

hrm. Right.

> I would suggest changing the shebang to "#!/usr/bin/env python3" and
> recommending only python3.

It’s just a Recommends, sure, but this is a package that, while
I always also test it on sid, currently targets jessie and PHP5
on the customer’s site, so I’m a bit wary of requiring py3k yet
(also I didn’t test it with that old a version).

Perhaps just removing the shebang and chmod -x’ing it would si‐
lence lintian?

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**Besuchen Sie uns auf der dmexco 2018!**

12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031**

Digital Business, Marketing und Innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*

**Visit us at dmexco 2018!**

12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031**

Digital business, marketing and innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*

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

[Thorsten Glaser]

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 checks/
> scripts.pm contains Recommends and is being checked against "python:any
> | python-minimal:any | python2:any | python2-minimal:any". I wonder if
> is is the architecture restrictions.

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
Recommends so either version would suffice.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**Besuchen Sie uns auf der dmexco 2018!**

12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031**

Digital Business, Marketing und Innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*

**Visit us at dmexco 2018!**

12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031**

Digital business, marketing and innovation

[www.tarent.de/dmexco](http://www.tarent.de/dmexco)

*

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

[Thorsten Glaser]

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
>sources.debian.org etc. or one's text editor.

that sounds like a good plan, indeed.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

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

[Thorsten Glaser]

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 helpful here? It’s bound to change.

But anyway, I managed to override it by not including the, what TIL is
called “lintian extra”, so I agree to closing the bug.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

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

[Thorsten Glaser]

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 package is
called simkolab, and I get the warning once per binary package).

Incidentally, if I just use…

simkolab-blackberry: bugs-field-does-not-refer-to-debian-infrastructure

… I can successfully override it, so there’s (again… I remember
something like this happending in etch or lenny or so) a bug
when the second word of the warning is included in the override.

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut)  23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren   -- Michael Prokop über MirOS bsd4grml

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

[Thorsten Glaser]

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 #!/usr/bin/python



-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils   2.31.1-4
ii  bzip2  1.0.6-9
ii  diffstat   1.61-1
ii  dpkg   1.19.0.5+b1
ii  file   1:5.34-2
ii  gettext0.19.8.1-7
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34
ii  libarchive-zip-perl1.60-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.39-1
ii  libdigest-sha-perl 6.02-1
ii  libdpkg-perl   1.19.0.5
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.72+repack-1
ii  man-db 2.8.4-2
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.26.2-7
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-4
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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 mailto:t.gla...@tarent.de

tglase@tglase:~/Projekte/SimKolab4 $ tail -2 
debian/simkolab-blackberry.lintian-overrides
# correct
simkolab-blackberry: bugs-field-does-not-refer-to-debian-infrastructure 
mailto:t.gla...@tarent.de


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils   2.31.1-4
ii  bzip2  1.0.6-9
ii  diffstat   1.61-1
ii  dpkg   1.19.0.5+b1
ii  file   1:5.34-2
ii  gettext0.19.8.1-7
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34
ii  libarchive-zip-perl1.60-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.39-1
ii  libdigest-sha-perl 6.02-1
ii  libdpkg-perl   1.19.0.5
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.72+repack-1
ii  man-db 2.8.4-2
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.26.2-7
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-4
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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

---
 checks/cruft.desc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/checks/cruft.desc b/checks/cruft.desc
index d1ba9335a..255f52104 100644
--- a/checks/cruft.desc
+++ b/checks/cruft.desc
@@ -912,6 +912,7 @@ Info: This file appears to contain one or more lines with 
trailing
   $ sed -i -e 's@[[:space:]]*$@@g' debian/control debian/changelog
  .
  If you use Emacs, you can also use "M-x wh-cl" (whitespace-cleanup).
+ If you use jupp, you can also use "^K]".
  .
  However, if you wish to only remove trailing spaces and leave trailing tabs
  (eg. for Makefiles), you can use the following code snippet:
-- 
2.17.0



(Yes, lowercase name. Ctrl-K+] removes trailing whitespace at EOL and,
in the latest versions, also at EOF. This way of writing the keyboard
shortcut is standard for wordstar-like editors like joe and jupp.)

Thanks in advance,
//mirabilos

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

[Thorsten Glaser]

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
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.30-8
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1
ii  dpkg  1.19.0.5
ii  file  1:5.32-2
ii  gettext   0.19.8.1-6
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdigest-sha-perl6.01-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.99-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-5
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.25-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.3-2
ii  patchutils0.3.4-2
ii  perl  5.26.1-5
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.30-8
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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 probably it, yes.

>… but, just for giggles, here's another silly one:

That looks also good ;-)

>Compat level 5 (!).

Well, 5 was the standard/minimum for a long time,
and I don’t use the newer features anyway (not those
visible to the user; those in the background, such
as using gzip’s -n option, are, of course, used),
so I’d just use compat 5 and get whatever version
the target distro had with whatever of its fixes.

>(What's wrong with the  debhelper versions in
>backports, out of interest?)

I try to keep backports dependencies out if possible.

I also maintain, in my own (public) repo and in the
private one of my employer, backports much far back
than oldoldstable, for those who are still running
such systems or chroots someplace. This started out
with back to etch (but, back then, lenny was stable,
so it was not that much of a, well, stretch (no pun
intended)), but eventually we discovered a sarge sy‐
stem somewhere at the workplace, so I targetted that
with a handful of packages until we could upgrade it
(it’s long gone, thankfully, but it’s no effort to
keep what I already *have* working in the old versions,
working in those; though I don’t create new backports
to such old versions). It’s also a portability exercise…

bye,
//mirabilos
-- 
13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs
13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you
17:14⎜ Thanks big help you are :-)mira|nwt: ty again
18:36⎜«ThunderChicken:#cvs» mirabilos FTW!  23:03⎜«mithraic:#cvs» aaah. thanks

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

[Thorsten Glaser]

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 equivalent; I don’t speak Perl.)

It’s also a bit unfortunate that, if I have both
(one being a symlink to the other), I still have¹
to override that the old location is used. I prefer
my packages backportable with ease, which is why
I’m a tad annoyed at such incompatible changes,
but also (not scope of this bugreport) having to
jump to the latest debhelper version when 5 is
enough for me.

① live example: git clone \
https://evolvis.org/anonscm/git/alioth/jupp.git
  (dump http transport, so may take a minute)

-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.30-4
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1
ii  dpkg  1.19.0.5
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdigest-sha-perl6.01-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-4+b1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.1-1
ii  patchutils0.3.4-2
ii  perl  5.26.1-4+b1
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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: bugs-field-does-not-refer-to-debian-infrastructure line 39

I could, of course, override that in the mksh binary package,
but the dbgsym package is auto-generated and therefore not
available for overriding.


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.29.1-12
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1
ii  dpkg  1.19.0.4
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdigest-sha-perl6.01-1
ii  libdpkg-perl  1.19.0.4
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-2
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-4
ii  patchutils0.3.4-2
ii  perl  5.26.1-3
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.4
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information

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

[Thorsten Glaser]

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 Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.25.90.20160101-2
ii  bzip2 1.0.6-8
ii  diffstat  1.60-1
ii  file  1:5.25-2
ii  gettext   0.19.7-2
ii  hardening-includes2.8+nmu2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.29+b5
ii  libarchive-zip-perl   1.56-2
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-1+b1
ii  libdigest-sha-perl5.95-2+b1
ii  libdpkg-perl  1.18.3
ii  libemail-valid-perl   1.198-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.413-1+b1
ii  libparse-debianchangelog-perl 1.2.0-8
ii  libperl5.22 [libdigest-sha-perl]  5.22.1-4
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  man-db2.7.5-1
ii  patchutils0.3.4-1
ii  perl  5.22.1-4
ii  t1utils   1.39-2
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg 1.18.4
pn  libperlio-gzip-perl  
ii  perl 5.22.1-4
ii  perl-modules-5.22 [libautodie-perl]  5.22.1-4

Versions of packages lintian suggests:
ii  binutils-multiarch 2.25.90.20160101-2
pn  dpkg-dev   
ii  libhtml-parser-perl3.72-1
pn  libtext-template-perl  
ii  libyaml-perl   1.15-1

-- no debconf information

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

[Thorsten Glaser]

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 /usr/bin/pg_lsclusters ]; then

OK, I looked into devref, and it explicitly says:

    If you need to check for the existence of a command, you should
use something like

    if [ -x /usr/sbin/install-docs ]; then ...

But, huh? Turns out lintian false-positives that as well:

$ perl -e '$cmd = "if [ -x /usr/bin/pg_lsclusters ]; then"; if($cmd =~ 
m{\[\s+(?:!\s+)? -x \s+(/(?:usr/)?s?bin/[\w.+-]+)\s+ \]}xsm){print 
"true\n";}else{print "false\n";}'
true
$ perl -e '$cmd = "if [ -x /usr/sbin/install-docs ]; then"; if($cmd =~ 
m{\[\s+(?:!\s+)? -x \s+(/(?:usr/)?s?bin/[\w.+-]+)\s+ \]}xsm){print 
"true\n";}else{print "false\n";}'
true

This doesn’t happen in wheezy but in sid.

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils   2.25.90.20151209-1
ii  bzip2  1.0.6-8
ii  diffstat   1.60-1
ii  file   1:5.25-2
ii  gettext0.19.6-1
ii  hardening-includes 2.7
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.29+b4
ii  libarchive-zip-perl1.55-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.38-1
ii  libdigest-sha-perl 5.95-2
ii  libdpkg-perl   1.18.3
ii  libemail-valid-perl1.198-1
ii  libfile-basedir-perl   0.07-1
ii  libipc-run-perl0.94-1
ii  liblist-moreutils-perl 0.413-1
ii  libparse-debianchangelog-perl  1.2.0-8
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.69-1
ii  man-db 2.7.5-1
ii  patchutils 0.3.4-1
ii  perl [libdigest-sha-perl]  5.20.2-6
ii  t1utils1.38-4
ii  xz-utils   5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg1.18.3
pn  libperlio-gzip-perl 
ii  perl5.20.2-6
ii  perl-modules [libautodie-perl]  5.20.2-6

Versions of packages lintian suggests:
ii  binutils-multiarch 2.25.90.20151209-1
ii  dpkg-dev   1.18.3
ii  libhtml-parser-perl3.71-2
pn  libtext-template-perl  
ii  libyaml-perl   1.15-1

-- no debconf information

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

[Thorsten Glaser]

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 implemented.

This is *still* something devref explicitly suggests.

> * Axel Beckert , 2015-12-11, 18:04:
> > I guess _that_ is the part, Lintian refers, too.

The entire section is valid though, and it’s perfectly fine to
just check for a well-known tool with test -x absolute-pathname.

> Eww. There's no reason to use this monster in maintainer scripts. Please use
> which(1) instead. See also bug #747320.

Yes, which(1) is something I considered, or the sh equivalent
of whence -p (I think type or type -v or something). But…

| I'm not entirely sure why most of those packages are using a construct
| like this though:
|
|   ,---
|   if [ ! -x /usr/sbin/dpkg-statoverride ] || \
|  ! dpkg-statoverride --list $CONF > /dev/null
|   then
|   [#]
|   fi
|   `---
|
| instead of just using the command directly? Maybe cargo-culted from

let’s come back to Guillem’s message: the packages use these constructs
for several reasons:

• devref suggests it for checking whether a command exists

• a command may not exist yet or any more (especially in postrm)

• depending on a command (think Recommends or Suggests),
  the behaviour may differ (which is the case in FusionForge,
  where the non-pg_lsclusters case causes separate handling)

These are all valid cases, and while I consider Guillem’s idea
of using lintian to catch use cases of compatibility symlinks,
this is the wrong tag to use as well as the wrong check to do
(it could be done by shipping a specific list of files to check
for as legacy scripts in lintian, for example, but even then,
it would not necessarily catch all use cases as maintainer
scripts can call other scripts/programs, especially if that’s
common code shared between maintainer scripts and other code),
so I believe he’d be better off with codesearch.d.n or similar
tools instead of using lintian for it.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#800438: lintian: stop warning about versioned Provides

[Thorsten Glaser]

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 anything newer than
jessie.

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils   2.25.1-3
ii  bzip2  1.0.6-8
ii  diffstat   1.60-1
ii  file   1:5.25-2
ii  gettext0.19.6-1
ii  hardening-includes 2.7
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.29+b2
ii  libarchive-zip-perl1.53-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.38-1
ii  libdigest-sha-perl 5.95-2
ii  libdpkg-perl   1.18.3
ii  libemail-valid-perl1.196-1
ii  libfile-basedir-perl   0.07-1
ii  libipc-run-perl0.94-1
ii  liblist-moreutils-perl 0.413-1
ii  libparse-debianchangelog-perl  1.2.0-8
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.69-1
ii  man-db 2.7.3-1
ii  patchutils 0.3.4-1
ii  perl [libdigest-sha-perl]  5.20.2-6
ii  t1utils1.38-4
ii  xz-utils   5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg1.18.3
pn  libperlio-gzip-perl 
ii  perl5.20.2-6
ii  perl-modules [libautodie-perl]  5.20.2-6

Versions of packages lintian suggests:
ii  binutils-multiarch 2.25.1-3
ii  dpkg-dev   1.18.3
ii  libhtml-parser-perl3.71-2
pn  libtext-template-perl  
ii  libyaml-perl   1.13-1

-- no debconf information

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

[Thorsten Glaser]

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 can't support GCJ forever. My Java baseline is:


OK, let me rephrase my intent again.

I think it’s fair to drop GCJ support. But please do not so for
as long as doing that breaks GCJ architectures. That means, for
all affected packages, do maintainer uploads or NMUs *first*
that:

- change the B-D to require default-jdk only on an architecture
  whitelist (do not use a blacklist, that makes bootstrapping
  new architectures impossible_)

- change d/rules, d/control to only build the *-java packages
  on those architectures

- ensure these changes are in sid *first*

Thanks!

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general


--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1505271502540.12...@tglase.lan.tarent.de

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

[Thorsten Glaser]

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')
Architecture: x32 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh

Versions of packages lintian depends on:
ii  binutils   2.24.51.20140918-1
ii  bzip2  1.0.6-7
ii  diffstat   1.58-1
ii  file   1:5.19-2
ii  gettext0.19.2-2
ii  hardening-includes 2.5+nmu1
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29+b2
ii  libarchive-zip-perl1.38-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.37-1+b1
ii  libdigest-sha-perl 5.92-1+b1
ii  libdpkg-perl   1.17.13
ii  libemail-valid-perl1.195-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-2+b1
ii  libparse-debianchangelog-perl  1.2.0-1.1
ii  libtext-levenshtein-perl   0.09-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.64-1
ii  man-db 2.6.7.1-1
ii  patchutils 0.3.3-1
ii  perl [libdigest-sha-perl]  5.20.1-1
ii  t1utils1.37-2.1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl none
ii  perl5.20.1-1
ii  perl-modules [libautodie-perl]  5.20.1-1

Versions of packages lintian suggests:
ii  binutils-multiarch 2.24.51.20140918-1
ii  dpkg-dev   1.17.13
ii  libhtml-parser-perl3.71-1+b3
pn  libtext-template-perl  none
ii  libyaml-perl   1.11-1
ii  xz-utils   5.1.1alpha+20120614-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140922142109.3717.97791.report...@tglase.lan.tarent.de

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

[Thorsten Glaser]

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 I believe (but have not reviewed yet) that
embedding the CC-BY-SA logo into a CC-BY-SA document, even if done
legally, makes the resulting PDF non-free and non-distributable as
it combines those and the logos’ licence with its terms is not CC-
BY-SA compatible.

Thomas could you use the format of data/cruft/non-distributable-files :

If you mean me…

md5sum ~~ sha1 ~~ sha256 ~~ current name ~~ reason ~~ official reference

ef4fa1b112f24ea289143f14177801ba ~~ b99f06c6220c6d78c7ff7384c20d7a3ce4c4f2fa ~~ 
434962385b8a016e968c827e5356bec7bfd5c0854a5e59e48df0bb09b35eacbe ~~ 
40devnations.gif ~~ bad trademark policy ~~ http://creativecommons.org/policies
9b024361951187cbd2d4d8ae49518b16 ~~ 5c18f8c6e7cb6edf5c411095e6630e706e5c4006 ~~ 
91eb3a23dce64ce3bde26072dfb19ce41292ca0e88baf0ecdfcdf0e976435c8f ~~ 
40founders.gif ~~ bad trademark policy ~~ http://creativecommons.org/policies
00c48f8b7b7989b838fdeb16f35078bd ~~ ff7d946f2ef5d827b5b1502e2bd50a70a45c5423 ~~ 
bb4e9479a188bb15c430c37f17ec94f35e28cba96a6c3854ed2654cb1fcee2c2 ~~ 
40gnugpl.gif ~~ bad trademark policy ~~ http://creativecommons.org/policies
47c01db6a85a471ad36a6c42293334f2 ~~ fb1bae092b7ce8c03802c5c5a4b48b295940194b ~~ 
6b1e610a9ab9dc20a5163a4a1af38315b1370c371f0c2db503d8422a887095c7 ~~ 
40gnulgpl.gif ~~ bad trademark policy ~~ http://creativecommons.org/policies
bf6aa3d9c5526128638a52cc4091c0dc ~~ 0b51f00dcaebf1f3d4fc0e00f32f9dc28d4ce993 ~~ 
5799552e2c6243d7eb53ef12e5081f866a579c9ca003ac1d571865dd8f7c4213 ~~ 
40publicdomain.gif ~~ bad trademark policy ~~ 
http://creativecommons.org/policies
53e5fcd93288e384263e0ed6e77bf935 ~~ 5985c6362d760266114677a66a4fdd48e96fb98b ~~ 
577fe6508e9b2341f8eb5b340aeb150cd68f2bf4efa3cdf49e0eae840c433948 ~~ 
40sampling.gif ~~ bad trademark policy ~~ http://creativecommons.org/policies
accbc4eb3f0367009859e84de6d61e59 ~~ baa8625b13ef5df69a12389f531effd4429d4ac4 ~~ 
76cc32bba1ed4a0d45ff77a5389f0282050847c347e4840f8d403697b2f364a9 ~~ 
40sharemusic.gif ~~ bad trademark policy ~~ http://creativecommons.org/policies
4fe75250c143f2b4013dc7eb53651a69 ~~ 4427793659aa10b76705833210b0bb32752db799 ~~ 
055291c432d7e191ade715f99e0abda5717ff57ea836710e144d52c0d9d0 ~~ 80x15.png 
~~ bad trademark policy ~~ http://creativecommons.org/policies
933cb1e2f3774f2eea904b5830575154 ~~ 64ed8324d0dc22eac8b5e26a0a0b5eaea8b36792 ~~ 
0e40af5272150d0471ee7194365799b02b1c8842539a34fc9b0bfa2770088ad2 ~~ 80x15.png 
~~ bad trademark policy ~~ http://creativecommons.org/policies
97436d8236f2e2b2f7a39fc55b6ad860 ~~ 96a6571faebce29faaa39cc171ae337a902fd741 ~~ 
345c7ad61f1be3650186b5773b3777043514e4515bb1311a7678dee06ae98604 ~~ 80x15.png 
~~ bad trademark policy ~~ http://creativecommons.org/policies
97d64be3b0c343e147072789bfadedc0 ~~ 97de08e680d00140989a2a11dc94ef5ad92398de ~~ 
5283893486a4fafa05b9cfecd1181b7b41f0367a5b1cfdd693bd423a1cccf5f3 ~~ 80x15.png 
~~ bad trademark policy ~~ http://creativecommons.org/policies
9f317d5f97dc715eb0e8b839dde4a2e7 ~~ a2164425f26267e47e1d5e52625b75b3c4cbcab6 ~~ 
68083ee5e7f0959eea4ab5312f5f54207a583fea688697c3011d838d6062c1dc ~~ 80x15.png 
~~ bad trademark policy ~~ http://creativecommons.org/policies
b90a06c066af6f9f03069696fe852195 ~~ b09709ab0bf02d7284b1a44de264f2094a90a82c ~~ 
bff8d1f220fa575e545a71fe20ce51b6c4c54a1d665fd14ac874eecdac4e321d ~~ 80x15.png 
~~ bad trademark policy ~~ http://creativecommons.org/policies
c84c528cf931adad589c4a83113baf2e ~~ d52a5d4efbb4018bd2c2900a8eb6d1a430d55c48 ~~ 
cbdab52b943a12b1dba5945098b1c6678a133453fff79d78f09cc51b6fc1f67f ~~ 80x15.png 
~~ bad trademark policy ~~ http://creativecommons.org/policies
eee5c0be05dc95970595c77512a228da ~~ e3c2a44ec4ef84c5564ba3723999a8de963eba86 ~~ 
e0deea0db2f4d25b7d773221e8360a1aedc99c5f510c129a5416c00e1ad759ac ~~ 80x15.png 
~~ bad trademark policy ~~ http://creativecommons.org/policies
0a27805bbe6b6d67ef37f760dc991917 ~~ 0d491b939f2ff060749abe9186e98bf8d707943e ~~ 
09d914dd25cb0460b9042ede089b8875fdb2681390c0f365065e990cc58ce43b ~~ 88x31.png 
~~ bad trademark policy ~~ http://creativecommons.org/policies
15d99bea74da9b7ec6a0ca3bad80903c ~~ 117955cc8705d97c986e5a147f0f351285015085 ~~ 
27ac31127a5b0892a41d4095953caed2b9d706bfa98ed899b93561f3020865c9 ~~ 88x31.png 
~~ bad trademark policy ~~ http://creativecommons.org/policies
1d7fb4e154e7198dfb39d16d9800844d ~~ 1ce8995d2c1051a65ca4942604f23d01dcf38b4d ~~ 
27b8bc90586997cd048aa31c2338ce28ba2404aa76dc36fdca0a52f42c804ebf ~~ 88x31.png 
~~ bad trademark policy ~~ http://creativecommons.org/policies
1f8cec42b3c9276f1acbe2847d123083 ~~ 4f4946b613aaa3143a109449f3fa7f5d2c1c00e2 ~~ 
6a5763b42e1aea19ca862a3e4b12f9a0b591f06d802f6d9259c6fda1550698fe ~~ 88x31.png 
~~ bad trademark policy ~~ 

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

[Thorsten Glaser]

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 restrictive policy (for example,
requiring a user to download the files directly from their website).
I believe them to be nōn-redistributable, and have removed them from
Mediawiki when I first encountered this:
http://lists.alioth.debian.org/pipermail/pkg-mediawiki-commits/2013-May/000309.html

Mediawiki upstream said they were in discussion with Creative Commons™
upstream about this issue, but I have not heard from either for the
last months.

The trademark policy is: http://creativecommons.org/policies

The MD5, SHA-1 and SHA-256 hashes of the offending files, along
with their basenames, are:

ef4fa1b112f24ea289143f14177801ba  40devnations.gif
9b024361951187cbd2d4d8ae49518b16  40founders.gif
00c48f8b7b7989b838fdeb16f35078bd  40gnugpl.gif
47c01db6a85a471ad36a6c42293334f2  40gnulgpl.gif
bf6aa3d9c5526128638a52cc4091c0dc  40publicdomain.gif
53e5fcd93288e384263e0ed6e77bf935  40sampling.gif
accbc4eb3f0367009859e84de6d61e59  40sharemusic.gif
4fe75250c143f2b4013dc7eb53651a69  80x15.png
933cb1e2f3774f2eea904b5830575154  80x15.png
97436d8236f2e2b2f7a39fc55b6ad860  80x15.png
97d64be3b0c343e147072789bfadedc0  80x15.png
9f317d5f97dc715eb0e8b839dde4a2e7  80x15.png
b90a06c066af6f9f03069696fe852195  80x15.png
c84c528cf931adad589c4a83113baf2e  80x15.png
eee5c0be05dc95970595c77512a228da  80x15.png
0a27805bbe6b6d67ef37f760dc991917  88x31.png
15d99bea74da9b7ec6a0ca3bad80903c  88x31.png
1d7fb4e154e7198dfb39d16d9800844d  88x31.png
1f8cec42b3c9276f1acbe2847d123083  88x31.png
442e76a057c3408e327f61f4873c24cb  88x31.png
6ff8ed82f42f1e6d3bb3fc1210018332  88x31.png
80fb4a8b9dd7c600afda07b3d3c5efa4  88x31.png
9076ddd6ddf0bffc24e6ac71c1353d33  88x31.png
9772d34b683f8af83804659d78c38748  88x31.png
b9f4175382a404007e19d3566061e36c  88x31.png
bc13c3d2fc4b54e9175cb8ff54d59e76  88x31.png
7b6efee0e4b051bc29f954c7e066fa85  by-nc-nd.eps
82d1a936e559fef919a57afe9f6ffbfc  by-nc-nd.eps
748ea699400753f21d5be217ac36e0f5  by-nc-nd.eu.eps
3c2a630a2993c6851a19692626874866  by-nc-nd.eu.png
215b9018d303fce1cf05e27ec282e798  by-nc-nd.eu.svg
9f43ee7d315d2934e8e73946a6ee7e03  by-nc-nd.png
a4212c1a42d241a1351fc139b20de70b  by-nc-nd.png
1c681acc4a150e7236254c464bb5a797  by-nc-nd.svg
612ec4f74e231aa080a732804ce8e334  by-nc-nd.svg
94095d573f20f4b02a9ee8dd9a9c4acc  by-nc-sa.eps
d788a0d38f602dea5bf323710867efda  by-nc-sa.eps
a1089579230e51ef476423baac77191c  by-nc-sa.eu.eps
f5eff424129e9bf343605c5494edf8c3  by-nc-sa.eu.png
d146b752545b36e8ad320e17140dd8df  by-nc-sa.eu.svg
3f516ebbaf44d7f0ea43045671a01cb4  by-nc-sa.png
982c531432c4ad7e8dbf3cf52a1dc6d0  by-nc-sa.png
03dda63e80b9508d421e792236239ef1  by-nc-sa.svg
12b4b29e8453be5b7828b524d3feabce  by-nc-sa.svg
15409907d2703e9f35fa3daa8e6686b8  by-nc.eps
e0156d2664ce0eef6a10aabbbc3a4697  by-nc.eps
7f9a907b4139f603cd70324183402ada  by-nc.eu.eps
d09517dce23df08ee9c7da9864e1403e  by-nc.eu.png
b5d47e66353694de03d8b9df331fd569  by-nc.eu.svg
1f11b44025eb2759e9b61c7c3b015bd6  by-nc.png
431810d6bf98fed2e7c4f9a6b821360d  by-nc.png
b7a14267217d0e8eb706248f80df8b55  by-nc.svg
dd9cfe99ed839a4a548114f988d653f4  by-nc.svg
81cc50b974e9c7dddfff3e1e83bd20f0  by-nd.eps
8ffccb321b40d3cfbea93bece38d5d6d  by-nd.eps
091f659b165adeccdc95b3106cfb526d  by-nd.png
2550d99b6d959c4d108d6525c7e2caa6  by-nd.png
264d4bc7b510419009c17074fe2e5e8b  by-nd.svg
2d80546af20128215dc1e23ef42d06c2  by-nd.svg
54751b6908992ef915cd54a479015c55  by-sa.eps
c6e8b379a5861e1b6de383bfd5bbe7af  by-sa.eps
331e6b36b956cea4190238d9efae9224  by-sa.png
3c4f16c9dd664cab9dde1d9d80f73439  by-sa.png
5dc383049332b6645f7c076584e718c7  by-sa.svg
c696b3db81cbbfba32f66c1dc88b909a  by-sa.svg
2cd4a1ef6dd380841daa2a506bebb3a4  by.eps
b8ff8a7ee1bd2a795c3b5a9f53ba1f37  by.eps
f49a7d366082972975994a76a291aecf  by.eps
6c735b19bb55df41dbf1c0084d3ea85c  by.large.png
04d377d968557a6092bccb1617db5a65  by.png
150be7705ac0d923b326b3fa983ebcd6  by.png
39389d4b760cbd24d3fa3499f5f94445  by.png
146876126af00a90aae7f3dbb54b00cd  by.svg
6c4f8422b3725cb9f26b6c00e95fc88b  by.svg
7813b5794d8ba96aec20acb7f14ff76a  by.svg
74cfcaf2396d7d7029db882dd7d06393  cc-icons-eps.zip
1074bdd206bb45ee6e073bca40535f45  cc-icons-png.zip
5403bcd5bb8fc15432df28819c3171b0  cc-icons-svg.zip
84873ab8ad1430882b73348ba2d01f09  cc-icons.ttf
8ba5bd38f5ca9ba16cd95f4d7d3a114c  cc-zero.png
d7d547bc2080e7656ad8a60caf0a6cab  cc-zero.png
2d6242e90c3082e7892cf478be605d26  cc-zero.svg
d4a3ff599d5def7c462ef0acbdb2e2e1  cc-zero.svg
7bc48902c8db2b89c485ccbba4e5b986  cc.eps
443ce99de58f2fc557b240d07f158435  cc.large.png
29ed59a9e426fe63f2fd8e58461d1c1d  cc.logo.eps
cfcd104d0ed005dd690ddea8cbb2b909  cc.logo.large.png
e3b3aba33b18e39ed3b0a7c95224c2d5  cc.logo.png
87aa85577cf0906255ae434c7b362089  cc.logo.svg
9655f889be8b2fa213c8ddc6999a8976  cc.png

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

[Thorsten Glaser]

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 remark you have in your
file should probably be moved to another field (e.g. Comment).  You need

OK Nik, please do so for the next resubmit ;)

Thanks Niels. (I don’t use DEP-5 myself, so I’m not “fluent”.)

bye,
//mirabilos
-- 
20:49⎜«Natureshadow» Oops, jetzt hab ich mir doch glatt beim Trinken
 ⎜Mineralwasser ins Ohr gekippt…
21:04⎜«mirabilos» ist das siggbar?  █ PS: سمَـَّوُوُحخ ̷̴خ ̷̴خ ̷̴خ امارتيخ 
̷̴خ
21:05⎜«Natureshadow» mirabilos: was sollte dich davon abhalten…


--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1309051344370.22...@herc.mirbsd.org

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

[Thorsten Glaser]

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 
/tmp/buildd/fusionforge_5.1.1+evolvis70~snapshot.20120921.145452_amd64.changes

And yet, still I get:

[…]
N: Processing binary package fusionforge-plugin-projectlabels (version 
1:5.1.1+evolvis70~snapshot.20120921.145452, arch all) ...
W: fusionforge-plugin-projectlabels: package-has-long-file-name 83  80
N:
N:The package has a very long filename. This may complicate shipping the
N:package on some media that put restrictions on the length of the
N:filenames (such as CDs).
N:
N:For architecture dependent packages, the tag is emitted based on the
N:length of the longest architecture name rather than the name of the
N:current architecture.
N:
N:This length will be written in brackets after the actual length.
N:
N:Refer to http://lists.debian.org/debian-devel/2011/03/msg00943.html for
N:details.
N:
N:Severity: normal, Certainty: certain
N:
N:Check: filename-length, Type: source, binary, udeb
[…]

Am I doing something wrong or is tag exclusion really
not working right? I’d like to not display this tag for
snapshot builds because of the automatically appended-to
version (also the reason for -X nmu, as it changes the
debian/changelog file machinally for them).

Thanks in advance,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Mancke


--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.02.1209211659200.26...@tglase.lan.tarent.de

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

[Thorsten Glaser]

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 uploaded to unstable in
the first place), and the default should be that it doesn’t override
the field.

That is, specifying the distribution (e.g. unstable) to sbuild would
still be mandatory (so this wouldn’t entirely solve #529281), but by
default (unless buildd), this value would NOT be copied into the Di-
stribution field of the .changes file – instead it would behave like
cowbuilder (which uses dpkg-genchanges) and copy the field from the
package’s changelog.
This is especially useful for developers building _local_ packages
in e.g. a sid or stable chroot, to prevent them from accidentally
uploading them to Debian, but also to avoid the case of forgetting
to change away UNRELEASED before uploading.

= lintian side =

I also propose an ftpmaster autoreject (via lintian) if:
a) Distribution=unstable, Changes=experimental
b) Distribution=experimental, Changes=unstable
c) Distribution=*, Changes=UNRELEASED

All other mismatch cases should probably be a W, but for these three,
I think not just an E but an autoreject could, maybe, be justified.

= social side =

Just use cowbuilder ;-)

https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/pbuilderrc?rev=HEAD
contains a sample ~/.pbuilderrc which does multi-arch (i386 and amd64 on
an amd64 host, for example – otherwise of course just one) multi-distro
(debian, ubuntu, debian-ports) multi-suite (from dapper and sarge up to
sid and (currently) precise) cowbuilder handling, plus “multi-client ca-
pability” by setting $CUSTOM. (It also contains some “optimisations” for
the chroots, such as dropping debconf-i18n (for Perl transitions; I did
the 5.12 one on m68k with that) and file-rc, which you may or may not
want; one can also locally optimise by putting fakeroot and even debhel-
per into EXTRAPACKAGES. These are of course not suitable for when buildd
could use cowbuilder, as suggested below.)

Of course, be aware of differences between cowbuilder and sbuild, but I
have had few problems with it (as long as cowbuilder, pbuild and deboot-
strap are taken from sid on the build machine, e.g. due to architecture
wildcards) and would love to see the buildd software support to use both
so buildds could be set up with either. (It’s easier to set up.)

= What now? =

#542747 could contain discussion about the lintian checks I suggested in
the second chapter of this mail.

We could clone #559659 and discuss the changes from the first chapter of
this mail there, as they would obviously not fix #559659 but still ad-
dress the issue of packages uploaded to the archive being not rebuildable
(with cowbuilder) due to their debian/changelog last entry being UNRELEA-
SED instead of unstable. I’ve found some on snapshot.d.o this week, and
buxy had the issue today, too.

Flames as followup-to-poster please. Improvements to pbuilderrc welcome.

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut)  23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren   -- Michael Prokop über MirOS bsd4grml



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1110291610480.23...@herc.mirbsd.org

Bug#638278: Bits from the Lintian maintainers

[Thorsten Glaser]

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 the BTS stuff I like to ask
off-“list” first for some things. I met many Debian pak-
kage maintainers who prefer the BTS for even simple pat-
ches, though, but I am not one of them myself…

 Yes, probably. But you could just map 0 to root for both
 uid and gid (everything else is not standardised anyway).

That could solve a lot it, if done in the method reading the tar index.

That was the idea. And it really only works (reliably) with
the uid and gid 0 – although if Debian standardises certain
other uids or gids, that could be supported too. (On the
other hand, almost all files, if not all, in a DEB would be
root-owned anyway.)

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1108181438580.12...@herc.mirbsd.org

Bug#546927: lintian: still complains about AnonCVS

[Thorsten Glaser]

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 _still_ wrong to check for :ext:?(_)anon...@…


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-6-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash (would be mksh, but #540512 annoys)

Versions of packages lintian depends on:
ii  binutils  2.19.91.20090910-1 The GNU assembler, linker and bina
ii  diffstat  1.47-1 produces graph of changes introduc
ii  dpkg-dev  1.15.4 Debian package development tools
ii  file  5.03-1 Determines file type using magic
ii  gettext   0.17-8 GNU Internationalization utilities
ii  intltool-debian   0.35.0+20060710.1  Help i18n of RFC822 compliant conf
ii  libapt-pkg-perl   0.1.24 Perl interface to libapt-pkg
ii  libipc-run-perl   0.84-1 Perl module for running processes
ii  libparse-debianchange 1.1.1-2parse Debian changelogs and output
ii  libtimedate-perl  1.1600-9   Time and date functions for Perl
ii  liburi-perl   1.37+dfsg-1Manipulates and accesses URI strin
ii  man-db2.5.6-2on-line manual pager
ii  perl [libdigest-sha-p 5.10.0-25  Larry Wall's Practical Extraction 

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch2.19.91.20090910-1 Binary utilities that support mult
ii  libtext-template-perl 1.45-1 Text::Template perl module
ii  man-db2.5.6-2on-line manual pager

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Vcs-CVS, again

[Thorsten Glaser]

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 could just go straight to
Git?  :)

Heh, that's not even a VCS or DVCS, just a content tracker and
patch management system. Good for Linus, but… ☻

Done for the next release, although I limited it to :ext: URLs that use a
username of anoncvs or _anoncvs and therefore probably don't require
authentication.

Okay, thanks.

//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2


--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Vcs-CVS, again

[Thorsten Glaser]

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
front? I’m asking because a DD asked why I override the lintian warning
I get with the above line and similar ones in other packages. He even
suggested I move to SVN… *shudder*

You’d almost certainly just have to change %VCS_RECOMMENDED_URIS (the
cvs entry) to change :pserver: to :(ext|pserver): I’d say.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt


--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

lintian and Vcs-CVS: fields

[Thorsten Glaser]

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
not handled correctly, e.g. by packages.qa.debian.org, because CVS
doesn’t have URIs but two components ($CVSROOT and module path) that
are separated (in the Vcs-CVS: field) by {a |white}space. Someone may
want to look into it.)

Please add :ext:[user[:pa...@]server:[port]/path to the list of
allowed/preferable CVSROOT formats, too.

10x,
//mirabilos
-- 
  Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL.
 -- Henry Nelson, March 1999


--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Thorsten Glaser]

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 about
the middle two ones, probably have to add the same --package
which I used in creating it? on the other hand, mksh and dash
share this, so it's even more difficult), but with a twist:
it's dynamic.

https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/mksh/debian/mksh.postinst
will show you the current state of the art; like I said, the
code itself originated from dash...

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh

Versions of packages lintian depends on:
ii  binutils   2.19.1-1  The GNU assembler, linker and bina
ii  diffstat   1.46-1produces graph of changes introduc
ii  dpkg-dev   1.14.25   Debian package development tools
ii  file   5.00-1Determines file type using magic
ii  gettext0.17-6GNU Internationalization utilities
ii  intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libipc-run-perl0.82-1Perl module for running processes
ii  libparse-debianchangel 1.1.1-2   parse Debian changelogs and output
ii  libtimedate-perl   1.1600-9  Time and date functions for Perl
ii  liburi-perl1.37+dfsg-1   Manipulates and accesses URI strin
ii  man-db 2.5.5-1   on-line manual pager
ii  perl [libdigest-sha-pe 5.10.0-19 Larry Wall's Practical Extraction 

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarchnone (no description available)
pn  libtext-template-perl none (no description available)
ii  man-db2.5.5-1on-line manual pager

-- no debconf information


As you can see, it'd probably have to be overridden,
unless this whole diversion-for-/bin/sh thing gets
cleaned up (I already suggested to use the scheme the
debconf handbook recommends for the default window
manager, but didn't get much response from the dash
maintainers) by someone who actually understands this
stuff well.

bye,
//mirabilos
--
23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)
23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit
 ⎜  grml hab, das muss ich dann gleich mal auf usb-stick installieren
-- Michael Prokop von grml.org über MirGRML und MirOS bsd4grml



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Thorsten Glaser]

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 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh

Versions of packages lintian depends on:
ii  binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina
ii  diffstat1.45-2   produces graph of changes introduc
ii  dpkg-dev1.14.20  Debian package development tools
ii  file4.25-1   Determines file type using magic
ii  gettext 0.17-3   GNU Internationalization utilities
ii  intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf
ii  libparse-debianchan 1.1.1-2  parse Debian changelogs and output
ii  libtimedate-perl1.1600-9 Time and date functions for Perl
ii  liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin
ii  man-db  2.5.2-2  on-line manual pager
ii  perl [libdigest-sha 5.10.0-13Larry Wall's Practical Extraction 

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarchnone (no description available)
pn  libtext-template-perl none (no description available)
ii  man-db2.5.2-2on-line manual pager

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#498082: lintian: false positive in manpages

[Thorsten Glaser]

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 2.5.2-2on-line manual pager

Looks current according to packages.d.o.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in Notes on Programming in C



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]