Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t

2023-01-16 Thread Paul Gevers

Hi Axel,

On 15-01-2023 23:07, Axel Beckert wrote:

TL;DR:


[...]

You're awesome. And indeed, what a shame of your time.

Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t

2023-01-02 Thread Paul Gevers

Hi,

On 02-01-2023 21:10, Axel Beckert wrote:

Another weird point seems that
t/recipes/checks/desktop/gnome/gir/gir/eval/desc says:

   Testname: gir
   Check: desktop/gnome/gir
   Test-Architecture: amd64

So that clearly means it should only be run on amd64. So why is it run
on arm64 at all?


I suspect this is a lintian internal, but I guess you figured that out.


Ah, ok. Yeah, kinda makes sense. I kinda expected that this version is
usually the one the bug report was written against with any additional
version hints being added as secondary version via Control statements.


I cake these reports from a template and file them in with what I see on 
ci.d.n.



P.S.: Any idea how we get Salsa CI autopkgtests on arm64?


I understand the issue is on the salsa admin side where there are issues 
with shared runners or something. There is a host available that could 
run the tests, but the host can't be added for $reasons.


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t

2022-12-11 Thread Paul Gevers

Control: found -1 2.115.3
Control: tag -1 - moreinfo

On 10-12-2022 22:55, Axel Beckert wrote:

Ehm, that version no more in the archive anywhere. Did you maybe mean
2.115.3 as currently in Testing and Unstable? (Feel free to remove the
moreinfo tag once this is clarified.)


I meant, I see the issue *since* that version. But indeed, that's a bit 
weird if not commented on. I have added a `found` version now.



Will have to look into it again, but I fear in short term, it means to
either reduce the tests or only run a subset on non-amd64
architectures.


If the test can't easily support other architectures (which is fine in 
my opinion) than please ensure it only runs on amd64. I advice to do 
that by adding a "Architecture: amd64" field to d/t/control.


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t

2022-12-10 Thread Paul Gevers

Source: lintian
Version: 2.111.0
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails currently 
everywhere except on amd64. Can you please investigate the situation and 
fix it? I copied some of the output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing as are regressions on all release 
architectures.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/arm64/l/lintian/28970519/log.gz

# Hints do not match
#
# --- 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/hints.specified.calibrated
# +++ 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/hints.actual.parsed
# -gir1.2-good-42 (binary): typelib-not-in-multiarch-directory 
usr/lib/x86_64-linux-gnu/girepository-1.0 
[usr/lib/girepository-1.0/GoodExtras-42.typelib]
# -gir1.2-good-42 (binary): typelib-not-in-multiarch-directory 
usr/lib/x86_64-linux-gnu/girepository-1.0 
[usr/lib/girepository-1.0/Good-42.typelib]
# +gir1.2-good-42 (binary): typelib-not-in-multiarch-directory 
usr/lib/aarch64-linux-gnu/girepository-1.0 
[usr/lib/girepository-1.0/GoodExtras-42.typelib]
# +gir1.2-good-42 (binary): typelib-not-in-multiarch-directory 
usr/lib/aarch64-linux-gnu/girepository-1.0 
[usr/lib/girepository-1.0/Good-42.typelib]

#
#   Failed test 'Lintian passes for gir'
#   at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343.
# Looks like you failed 1 test of 1.
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t 
...



and

# Hints do not match
#
# --- 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/hints.specified.calibrated
# +++ 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/hints.actual.parsed
# +bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch sbin/our-script 
-> usr/bin/our-script [usr/bin/calls-sbin]
# +bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch bin/our-script 
-> usr/bin/our-script [usr/bin/calls-sbin]

#
#   Failed test 'Lintian passes for bin-sbin-confusion-in-elf'
#   at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343.
# Looks like you failed 1 test of 1.
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/generic.t 



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1003643: src:lintian: fails to migrate to testing for too long: unresolved RC bug

2022-04-09 Thread Paul Gevers

Hi,

On Thu, 13 Jan 2022 08:47:40 +0100 Paul Gevers  wrote:
The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:lintian has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. You have an unresolved RC bug 
that applies to the unstable package but not to the testing package, 
hence blocking migration.


It's been three months. Any progress on this?

Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1004536: lintian: suggest Testsuite: autopkgtest-pkg-* when autodep8 detects it should be added

2022-01-30 Thread Paul Gevers

Hi Paul,

On Sun, 30 Jan 2022 16:28:54 +0800 Paul Wise  wrote:

I noticed while packaging some Python modules recently that they were
not tested by debci. This is because debci only tests source packages
that contain a Testsuite field. The autodep8 tool is able to generate
the needed tests, but debci only runs it when the Testsuite field is
present and contains an autopkgtest-pkg-* value. The autodep8 tool also
contains heuristics to detect packages that could have autopkgtests but
right now there is nothing suggesting to maintainers that they should
add tests based on autodep8. I suggest that when the Testsuite field is
missing, lintian run autodep8 from the unpacked source package dir and
when autodep8 prints a test stanza on stdout, emit a tag suggesting
that the maintainer add the Testsuite field. If the Testsuite is
already present, presumably the maintainer already added some tests
that are better than the autodep8 ones. Since autodep8 also prints
warnings/errors on stderr, lintian could also emit tags there too. 


Here is an example of an affected package:

$ debsnap python-circuitbreaker 1.3.2-1
$ chronic dpkg-source -x python-circuitbreaker_1.3.2-1.dsc 
$ cd python-circuitbreaker*/

$ grep Testsuite debian/control
$ find debian/tests
find: ‘debian/tests’: No such file or directory
python-circuitbreaker-1.3.2 $ autodep8 
Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import circuitbreaker; print(circuitbreaker)" ; done
Depends: python3-all, python3-circuitbreaker, 
Restrictions: allow-stderr, superficial, 
Features: test-name=autodep8-python3


But this is only useful if the test actually passes. We don't want 
people to add the field if the test is broken. So if this is 
implemented, make sure the priority/certainty/whatever is low enough 
that people will *not* just blindly do this.


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1003643: src:lintian: fails to migrate to testing for too long: unresolved RC bug

2022-01-12 Thread Paul Gevers

Source: lintian
Version: 2.111.0
Severity: serious
Control: close -1 2.114.0
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 999768

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:lintian has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. You have an unresolved RC bug 
that applies to the unstable package but not to the testing package, 
hence blocking migration.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=lintian



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1000476: lintian: autopkgtest regression: autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/binaries/corrupted/legacy-debug/generic.t

2021-11-23 Thread Paul Gevers

Source: lintian
Version: 2.113.0
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of lintian the autopkgtest of lintian fails in 
testing when that autopkgtest is run with the binary packages of lintian 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
lintianfrom testing2.113.0
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=lintian

https://ci.debian.net/data/autopkgtest/testing/armhf/l/lintian/16912872/log.gz

../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/tracking/generic-dh-make-2008/generic.t 
 ok
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/lintian-features/lintian-suppress-tags/generic.t 
... ok

# Literal output does not match
# # --- 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/odd-inputs/strings-elf-detection/literal
# +++ 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/odd-inputs/strings-elf-detection/literal.actual.parsed
# +W: strings-elf-detection-dbgsym: elf-error In program headers: Unable 
to find program interpreter name 
[usr/lib/debug/.build-id/45/e1c08eeb668890993873e92eb9c047c87cfb25.debug]

# #   Failed test 'Lintian passes for strings-elf-detection'
#   at /usr/share/lintian/lib/Test/Lintian/Run.pm line 341.
# Looks like you failed 1 test of 1.
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/odd-inputs/strings-elf-detection/generic.t 
. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/runner-features/runtests-options/generic.t 
. ok
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/tracking/generic-dh-make-2005/generic.t 
 ok
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/lintian-features/lintian-display-level/generic.t 
... ok
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/runner-features/runtests-calibration/generic.t 
. ok


Test Summary Report
---
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/binaries/corrupted/legacy-debug/generic.t 
(Wstat: 256 
Tests: 1 Failed: 1)

  Failed test:  1
  Non-zero exit status: 1
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/odd-inputs/strings-elf-detection/generic.t 


(Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=1447, Tests=62792, 303 wallclock secs (11.66 usr 23.72 sys + 
4309.74 cusr 32394.30 csys = 36739.42 CPU)

Result: FAIL

The test suite ran for 5 minutes and 4 seconds.

autopkgtest [00:18:34]: test build-and-evaluate-test-packages




OpenPGP_signature
Description: OpenPGP digital signature


Bug#964405: lintian: autopkgtest regression: No tests were selected by your filter:

2020-07-06 Thread Paul Gevers
Source: lintian
Version: 2.82.0
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of lintian the autopkgtest of lintian fails in
testing when that autopkgtest is run with the binary packages of lintian
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
lintianfrom testing2.82.0
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=lintian

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lintian/6153561/log.gz


Running selected and required Perl test scripts.


Files=0, Tests=0,  0 wallclock secs ( 0.26 usr +  0.07 sys =  0.33 CPU)
Result: NOTESTS


No tests were selected by your filter:

suite:tags

To select your tests, please use an appropriate argument with a
selector like:

'suite:', 'test:', 'check:', 'tag:', or 'script:'

You can also use 'minimal:', which runs only the tests that cannot
be turned off, such as the internal tests for the harness.



signature.asc
Description: OpenPGP digital signature


Bug#909270: lintian: missing-explanation-for-repacked-upstream-tarball check should look in Source:

2018-09-20 Thread Paul Gevers
Package: lintian
Version: 2.5.103

Dear lintian maintainers,

According to the policy [1], the Source fields should be used:
"""If the upstream source has been modified to remove non-free parts,
that should be explained in this field."""

That is what I do in the lazarus package. However, lintian complains
with the missing-explanation-for-repacked-upstream-tarball tag, because
it isn't in the Comments or Files-Excluded field.

Paul

[1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/



signature.asc
Description: OpenPGP digital signature


Bug#905030: lintian: please verify debian/tests/control contains more tests than "Test-Command: /bin/true"

2018-07-31 Thread Paul Gevers
Hi Chris,

On 31-07-18 16:55, Chris Lamb wrote:
>> Rather unconstructively, they refuse to fix it until lintian has the
>> warning [2].
> 
> That seems.. strange. At the very least, Lintian is not Policy.

Ack. I filed 6 bugs today against packages in their team (the ones
currently trying to migrate). They already fixed the first bug.

> Unrelated to the above, do you feel there any real fear that a /bin/
> true would simply be replaced with something else if a maintainer saw
> this tag?  There are, of course, plenty of no-op commands available in
> the base system... :)

Yes, let's make sure the message is not "don't use /bin/true (or only
true, or exit 0 or echo)" but rather, please make sure the set of
autopkgtests actually test the installed package somehow.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#905030: lintian: please verify debian/tests/control contains more tests than "Test-Command: /bin/true"

2018-07-31 Thread Paul Gevers
Hi Chris,

On 31-07-18 05:16, Chris Lamb wrote:
>> For this proposal to make sense, all deployed autopkgtests must
>> actually test the package involved to some extent.
> 
> I fully ACK and understand the issue and background but just to be more
> effective priority-wise are you aware of how many packages, if any,
> are violating this right now?

codesearch [1] suggests it may be ~170 packages. All packages by the GIS
team seem to be involved. Rather unconstructively, they refuse to fix it
until lintian has the warning [2].

Paul

[1]
https://codesearch.debian.net/search?q=Test-Command%3A%5Cs*%2Fbin%2Ftrue+path%3A%2Fdebian%2Ftests%2Fcontrol
[2]
https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2018-July/071671.html



signature.asc
Description: OpenPGP digital signature


Bug#905030: lintian: please verify debian/tests/control contains more tests than "Test-Command: /bin/true"

2018-07-30 Thread Paul Gevers
Package: lintian
Version: 2.5.93
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: issue

Dear lintian maintainers,

The Release Team has expressed their wish [1] that autopkgtest does not
simply contain /bin/true as test command:
"""
For this proposal to make sense, all deployed autopkgtests must
actually test the package involved to some extent.  We trust it will
not be necessary to establish a technical solution for this part.
"""

This has been confirmed on IRC #debian-release on 2018-07-28. Using
/bin/true is not a problem in itself, but packages that have a passing
autopkgtest of their own (and no regression otherwise) are rewarded with
a reduced age. It is this reward that is undesirable for this class of
packages as installability is already tested by piuparts (which is
considered superior in this respect) and which failure already results
in a block.

It would be great if lintian could detect it when an autopkgtest:
- has only one test
- the test command is /bin/true
This would even be true if the sole purpose of adding this check would
be, to see if such a technical solution is warranted.

Proposed text (feel free to use something more in line with other
lintian texts):

This package has an autopkgtest which will always pass if the package
can be installed as it uses the test command "/bin/true". Because the
results of autopkgtest influence [2] the migration from unstable to
testing this is not desirable [1]. Installability is better tested with
piuparts (which is also used to influence migration).
.
Please, update your autopkgtest to actually test the binary package(s)
as installed. You're welcome to have this test *additionally* to actual
tests.

Thanks for your great work on lintian.

Paul

[1] https://lists.debian.org/debian-devel-announce/2013/08/msg6.html
[2] https://lists.debian.org/debian-devel-announce/2018/05/msg1.html

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200,
'testing'), (50, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils   2.31.1-1
ii  bzip2  1.0.6-8.1
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.0.5+b1
ii  file   1:5.33-3
ii  gettext0.19.8.1-6+b1
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  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.3-2
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.26.2-6
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

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

-- no debconf information



signature.asc
Description: OpenPGP digital signature


Bug#896840: lintian: autopkgtest fails with new version of file

2018-04-26 Thread Paul Gevers
Hi Chris,

On 26-04-18 09:41, Chris Lamb wrote:
> Any thoughts before I essentially re-assign this?

No, I am too ignorant on the details of shared libraries and such.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#896840: lintian: autopkgtest fails with new version of file

2018-04-25 Thread Paul Gevers
Hi Chris,

On 25-04-18 10:44, Chris Lamb  wrote:
>> The first change is caused by changed behavior in file regarding
>> application/x-sharedlib vs application/x-pie-executable².
> 
> Hm, file appears to be recognising a .so as as "pie executable".

I was told on IRC that the thing file has to detect the delta is if the
file is executable. Has your test .so an executable bit set?

> Is that right?

To be honest, I don't know.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#896840: lintian: autopkgtest fails with new version of file

2018-04-24 Thread Paul Gevers
Source: lintian
Version: 2.5.84
Severity: normal
User: debian...@lists.debian.org
Usertags: needs-update

With the upload of version 1:5.33-1 of file, the autopkgtest of
lintian¹ started to fail with the error copied below. The first
change is caused by changed behavior in file regarding
application/x-sharedlib vs application/x-pie-executable².

Please investigate the situation and update your package accordingly.

Paul

¹ https://ci.debian.net/packages/l/lintian/
²
https://github.com/file/file/commit/7dbecfe406a6bb2de1fe7ec2fe413dcd8871ac74#diff-02f0b547c2779d25cff89672135f20e3

autopkgtest [12:51:04]: test testsuite: [---
 running tests 
mkdir -p "/tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite"
t/runtests -k -j 2 t
"/tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite"
suite:changes,debs,source,tests
ENV[LINTIAN_TEST_INSTALLED]=yes
ENV[PATH]=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
S..S...T
T...
tests::binaries-libc-link: diff -u t/tests/binaries-libc-link/tags
/tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite/tests/binaries-libc-link/tags.binaries-libc-link
--- t/tests/binaries-libc-link/tags 2018-04-23 11:50:51.0 +
+++
/tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite/tests/binaries-libc-link/tags.binaries-libc-link
2018-04-24 12:54:23.305457114 +
@@ -1,3 +1,3 @@
-E: binaries-libc-link: library-not-linked-against-libc
usr/lib/basic/libbasic-nolibc
 E: binaries-libc-link: program-not-linked-against-libc usr/bin/basic
-W: binaries-libc-link: shared-lib-without-dependency-information
usr/lib/basic/libbasic-nodeps
+E: binaries-libc-link: program-not-linked-against-libc
usr/lib/basic/libbasic-nolibc
+E: binaries-libc-link: statically-linked-binary
usr/lib/basic/libbasic-nodeps
fail tests::binaries-libc-link: output differs!
.S.S
..S.S..SS...



.S..
...S...
tests::legacy-libbaz: diff -u t/tests/legacy-libbaz/tags
/tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite/tests/libbaz/tags.libbaz
--- t/tests/legacy-libbaz/tags  2018-04-23 11:50:51.0 +
+++
/tmp/autopkgtest-lxc.x6opmumq/downtmp/autopkgtest_tmp/testsuite/tests/libbaz/tags.libbaz
2018-04-24 13:20:23.395299338 +
@@ -14,7 +14,6 @@
 E: libbaz1: maintainer-shell-script-fails-syntax-check postinst
 E: libbaz1: missing-dependency-on-perlapi
 E: libbaz1: package-must-activate-ldconfig-trigger
usr/lib/libfoo2.so.1.0.3b
-E: libbaz1: sharedobject-in-library-directory-missing-soname
usr/lib/libbaz1.so.1.0.3b
 E: libbaz1: shlib-missing-in-control-file libbaz2 1.0 for
usr/lib/libfoo2.so.1.0.3b
 E: libbaz1: shlib-with-executable-bit usr/lib/libfoo2.so.1.0.3b 0755
 E: libbaz1: symbols-declared-but-not-shlib libbaz 2
fail tests::legacy-libbaz: output differs!
..
Skipped/disabled tests:
  [debs]
deb-format-wrong-order: Unmet test dependencies: dpkg (<< 1.17.2)
  [tests]
binaries-missing-lfs: architecture mismatch
changelog-file-strange-date: Unmet test dependencies: dpkg (<< 1.18.2)
deb-format-udeb-compression: Unmet test dependencies: dpkg (<< 1.18.11)
debconf-config-not-executable: Unmet test dependencies: dpkg (<< 1.19.0)
debhelper-compat: Unmet test dependencies: debhelper (<< 9.20151101~)
debhelper-compat-empty: Unmet test dependencies: debhelper (<<
9.20151101~)
runtests-arch-i386: architecture mismatch
shared-libs-non-pic-i386: architecture mismatch
version-substvars-obsolete: Unmet test dependencies: dpkg (<< 1.17.2)

Failed tests (2)
tests::binaries-libc-link
tests::legacy-libbaz
make: *** [debian/rules:50: runtests] Error 1



signature.asc
Description: OpenPGP digital signature


Bug#891935: lintian: Wil is a common Dutch name making spelling-error-in-copyright buggy

2018-03-02 Thread Paul Gevers
Package: lintian
Version: 2.5.76
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Recently I started seeing "spelling-error-in-copyright Wil Will". I checked my
copyright file and the only Wil I could find is in the names of copyright
holders. Wil is a rather common name in the Netherlands, please don't assume it
is a spelling error.

Paul

- -- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'testing'), (50, 
'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils  2.30-5
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5
ii  file  1:5.32-2
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  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-5
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-5
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlqZoCEACgkQnFyZ6wW9
dQr8/Qf+ITyMRePzBEo48URc52DodD3CKpddhspKiCoYZAYGJU7JtI/x+u+Erl7d
/nxWQd1cmx9ngvlDoStf4fMjQBQYxu6dStwQ6syzNgiIxTQ6T4kQVU9VQpWOUSxR
olKvhBB4t7rOqYXxZYR5MHK7Ryq7DP8JnOaHSwR7VssoMn8smsXFnxt7DyJJmxo1
ydol/dMgq6JSzVEmzqrb3hBZuZsew3dBJ3RmBjp2osnesmuRg2gYl7op46Az/NyC
DJZVuJ6e/udJCYLZjOVG/pvwhFJN/nZFggpGr6lvPXEl4Xo676hpGEPGFi4FQJoR
hB+0wPc9fZ+YdUvnYoVll8hR9n+xoQ==
=n6Sz
-END PGP SIGNATURE-



Bug#883356: lintian: emacsen-common-without-dh-elpa links to non-existent man page

2017-12-02 Thread Paul Gevers
Package: lintian
Version: 2.5.60
Severity: minor
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lintian warning emacsen-common-without-dh-elpa mentions the dl-elpa(1) man
page. That page doesn't exist. It should most likely mention the dl_elpa(1) man
page.

- -- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'testing'), (50, 
'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.29.1-8
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
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.59-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-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-2
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-2
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlojHI8ACgkQnFyZ6wW9
dQrIpwf/bVvRoaZNa867TrmUyv9F+rgMyb6/Pl706KNDeov9OgTAm8YvfG2Y3ytv
7sks4Z9jOPHNnaeNXovYSgyKS82p8DBKxb9tlQu788FW0gyBxZmvpaBTtWgQFKbS
vyyuVkfO4OZoxB+PWEzbFSViiSDlv0Hpko2jEWD4Fv5waiqmSv9ANJDkKJRSA9Ww
Vt5e/g6uLMEBvnpu7T+FzbfKbtNAKoTdVtOiPoqt3QcDmav2pgjCnPoElCFbtami
YK6FHwn2WIEQ0fcrXMUpMfcBfLzv9RJu3OAU1wDKfqYHKsJtGI6SkvCJIW6yDE2a
OpFTJEuXFOpbw92lOtiXFeyptCL8DA==
=Geso
-END PGP SIGNATURE-



Bug#861897: lintian: check if the pathname part of dpkg-maint-helper script is owned by the package

2017-05-05 Thread Paul Gevers
Package: lintian
Version: 2.5.50.3
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

While trying out my latest fix for one of my packages, I got an error from
dpkg-maintscript-helper:

dpkg-maintscript-helper: error: directory '' contains files not 
owned by package , cannot switch to symlink

I mistakenly had the first and second argument swapped.

It would be nice if lintian could check that the first argument to the
symlink_to_dir, dir_to_symlink and rm_conffile calls and the first two
arguments of mv_conffile are owned by the package.

Paul

- -- System Information:
Debian Release: 9.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'experimental'), 
(200, 'testing'), (50, 'experimental'), (50, 'testing'), (1, 'experimental')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.28-4
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  file  1:5.29-3
ii  gettext   0.19.8.1-2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.32
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.23
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-2
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1-2
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2+b1

Versions of packages lintian recommends:
ii  dpkg 1.18.23
ii  libperlio-gzip-perl  0.19-1+b2
ii  perl 5.24.1-2
ii  perl-modules-5.22 [libautodie-perl]  5.22.2-5
ii  perl-modules-5.24 [libautodie-perl]  5.24.1-2

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.23
ii  libhtml-parser-perl3.72-3
ii  libtext-template-perl  1.46-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlkMeY4ACgkQnFyZ6wW9
dQqNrwf+L7tniau2A6rHA1PiCAVf9w1YflqgI3H+b0Hjgce715dulzjL2of6VEyo
TJOl08lyhCJu1A+Cd173akwrnxWcAlCIAk+jMebMrki8xCT9UNHl4SfaAXbhNLG2
fU1cDYadFuFDdntfDtq5lobseNdYVObEYMv/9SL0tIqceFOSLRMoNaKtctZ9fbZ1
nSgmQbDMuHdeuGqWKFdG/D2GiHsn0ku6TgIyIS4pstmQwsmCXCUVvTOWyqtQDJmu
vY9j+ZW2vH2Jve3wWQo6umjxNV3unqMGlrI3tAw/x9LoEoDXzAoMJE6PYUFPj6N8
LPlqFmfIcUBr34vVLwUnTYcdFmzOiQ==
=XX4x
-END PGP SIGNATURE-



Bug#825222: lintian: please allow debian/source/timestamps in unknown-file-in-debian-source

2016-05-24 Thread Paul Gevers
Package: lintian
Version: 2.5.44
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In the Free Pascal stack, it is common to have .ppu files. Consider them sort
of binary header files. Unfortunately, these files contain the timestamp of the
source file. This is undesirable because when these files are patched, the
timestamp of the build is stored in those ppu files and so:
1) the build becomes unreproducible¹
2) reverse dependent packages think the source was updated and will require a
rebuild of the source

To circumvent this I am adding a helper function to the fpc package (see
discussions on the pascal-devel list²) to store timestamps in the debian
packaging and use those to force the timestamps to something resonable. I
intent to store those timestamps in debian/source/timestamps.

I think that is a resonable place, so please don't error out on it in
unknown-file-in-debian-source.

Thanks for lintian.
Paul

¹ https://wiki.debian.org/ReproducibleBuilds/TimestampsInPPUGeneratedByFPC
² 
http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/Week-of-Mon-20160516/001234.html

- -- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (60, 'unstable'), (50, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJXRKW+AAoJEJxcmesFvXUK2loH/Rue6UlBKxIkBOuPdiDLj03o
tx0p3cl/oJuurRH9KWyO3gP1zDfkufwQP96vAPYUutCkczypOo4qoSxnyuBwAJzL
qM/qhFEwj68SVvq9PdAe4IBEy8U1/XCeZ+qkAgDWwYVMO6Hm9jF3DFMpKbi92zm3
leOqyyhXsY/8R2vA6GvAQnqodLceZw6NI3h4wEd4LAC8wlErVBlcNEx0VEActFc6
pzyrRW2rh1UX2G9FpDQhAxgoV2qnr3hLdUGlGOKMOB12imMzUrIV7if7n4NUsIPr
q/Ks9mJTkd3cs1QjNCwU/RDEmTa0nUlnefOcrlXng8Hq8AaQLwXFnccWFhax5/Q=
=PFO1
-END PGP SIGNATURE-



Bug#815994: lintian: false positive for source-is-missing in cacti package

2016-02-26 Thread Paul Gevers
Package: lintian
Version: 2.5.41
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

My package cacti contains a js file that clearly is not pre-build
javascript. The file in question is include/js/jquery.zoom.js which can be
found here:
http://anonscm.debian.org/cgit/pkg-cacti/cacti.git/tree/include/js/jquery.zoom.js

As requested by the lintian message, I report this false positive.

Thanks for your work on Lintian, it is much appreciated.

Paul

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJW0FHrAAoJEJxcmesFvXUKMHQH/2cC5uJxVhlF6sLcIb/R3w/i
LoNFOPYheqChiK8p6fjZl/CyPIV12gpJkDIypzXdG5Jj8UD/clww9ERJgDCklW/L
H3k52TezHnUYR4AtN3mr3JN8WzfmyiEn4kFMMMKKXDVEWONjRDG5H0Gt8RtiD/r/
Jdo/Zid8D/sbSLDAT3RuiKMOXHiZxDsi76ojwGUv2oCbJzzK6lFkojxeHJGQfip9
/sYCNubV/gMod47jzC3LSDIAdaUQbo3l8di3BbXR65u8UMZUFZmZCKkirVuuUpBG
p4Y3qtR8SJ49OA8sGFfZm6WccC89XAGKY+Am4nRyKzbN+iqZ5yb2AcHK8GqVgVI=
=uwYM
-END PGP SIGNATURE-



Bug#764067: lintian: prevent misuse of overrides by allowing maintainer comments

2014-10-05 Thread Paul Gevers
Package: lintian
Version: 2.5.28~bpo70+1
Severity: wishlist
X-Debbugs-CC: Debian mentors debian-ment...@lists.debian.org

Hi Lintian maintainers,

The following wish list bug results from a brief discussion (see the
final message with more information below) on the d-mentors e-mail-list.
It is noted that people use lintian overrides to hide investigated
issues that don't have a short term solution. Paul Wise mentioned this
is not where overrides are for.

So, Paul and I suggest the following:

- Add a way to document information about lintian messages, related to
the current package, such that it is clear that the message has been
investigated but can/will not be solved (in the short term).

- Add an argument to lintian to not show messages that have such a
comment to allow a maintainer to focus on unresolved/uninvestigated/new
messages instead of either abusing overrides or having to remember
everything.

Thanks for considering and the great tool that lintian is.

Paul

 Original Message 
Subject: Re: lintian overrides [Was: Bug#763540: Review of psocksxx/0.0.5-1]
Date: Sun, 5 Oct 2014 09:12:25 +0800
From: Paul Wise p...@debian.org
To: Debian mentors debian-ment...@lists.debian.org

On Sat, Oct 4, 2014 at 1:54 PM, Paul Gevers wrote:

 I have seen this before and I (as a maintainer) don't understand this
 comment so bold as it is put here. I would say that overrides can help
 you to see which items you (or your sponsee¹ in case of sponsorship)
 already investigated.

The point of lintian overrides is to hide issues shown by default that
are the fault of lintian where lintian cannot be fixed. Anything else
is not the way overrides were meant to be used.

 In the case of pedantic and info, you could even say that an override
 is allowed when the item might be still valid but for whatever reason
 is not going to be fixed (soon).

Valid suggestions by lintian shouldn't be hidden. pedantic,
experimental and info are hidden by default so there is no need to
hide them even if they are the fault of lintian and can't be fixed in
lintian, much of the time they are valid issues though.

 lintian on nearly every build I do and it help me to keep track of the
 issue I think I still need to resolve. As long as each override has an
 extensive and valid explanation, I don't see anything wrong with that
 and I prefer it over having to scroll through items that are ignored
 anyways.

That is an interesting use-case but I think just comments in
README.source or elsewhere is the way to go rather than overrides.

I think it would be interesting to be able to add comments associated
with lintian tags but not override them, so it would produce something
like the below (with pedantic turned on). That would cover your
use-case without misusing overrides.

C: No time to write manual pages, help welcome
W: codespell: binary-without-manpage usr/bin/codespell

C: Need to ask upstream about this
P: codespell: no-upstream-changelog

Could you file a bug asking for this feature?

Perhaps something like this in debian/package.lintian-comments could
be the way to go?

# No time to write manual pages, help welcome
codespell: binary-without-manpage usr/bin/codespell

# Need to ask upstream about this
codespell: no-upstream-changelog

 As a sponsor, I always check all the overrides and only accept those I
 understand. Documenting the reason goes a long way for that (as well as
 it helps in the future to remember the original reasoning).

Documentation is definitely useful, especially during sponsorship, but
it doesn't need overrides.






signature.asc
Description: OpenPGP digital signature


Bug#748452: lintian: please check if fields in machine-readable copyright file actually contain data

2014-05-17 Thread Paul Gevers
Package: lintian
Version: 2.5.22.1~bpo70+1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I accidentily created a d/copyright file which follows the format of the
machine readable style [1] but did not have any content in the Copyright:
fields of one of the paragraphs. Lintian didn't catch it (luckily I still
did myself). It would be nice if lintian didn't only check if the required
fields are there, but also if they are filled.

Example:
Files: source/component/tipue/jquery-1.7.1.min.js
 debian/source/jquery-1.7.1.js
Copyright: 
License: Expat
Comment:
 jQuery projects are released under the terms of the MIT license.

[1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

- -- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (500, 'stable'), (99, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lintian depends on:
ii  binutils   2.22-8
ii  bzip2  1.0.6-4
ii  diffstat   1.55-3
ii  file   1:5.17-1~bpo70+1
ii  gettext0.18.1.1-9
ii  hardening-includes 2.2
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.26+b1
ii  libarchive-zip-perl1.30-6
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1+b2
ii  libdpkg-perl   1.16.14
ii  libemail-valid-perl0.190-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-1+b1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtext-levenshtein-perl   0.06~01-2
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.2-1
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-21+deb7u1
ii  t1utils1.37-2

Versions of packages lintian recommends:
ii  libautodie-perl 2.19-1
ii  libperlio-gzip-perl 0.18-1+b2
ii  perl-modules [libautodie-perl]  5.14.2-21+deb7u1

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.16.14
ii  libhtml-parser-perl3.69-2
ii  libtext-template-perl  1.45-2
ii  libyaml-perl   0.81-1
ii  xz-utils   5.1.1alpha+20120614-2

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJTd0y8AAoJEJxcmesFvXUK9c0H/3i5pokYCJW90tipVfNIPltO
BPskU1HnRNRIJfjSq+3SvfSerneQ+sSsvTv1sxN2bq/rs/FirCM9OHBxcIy8eSQl
BLAty0XEXsxVADP4oMsgoSitHe5ZWNdMuqpw/rn8DeNW7v1m8JJAeS5P/ez76OXK
Dq6lUn+CuYpcx8fhCYccoOh9IctmPEF5AZEV26cWPihNP6U2K0Sk1kimdpkXY78C
ndoqvHDGF2Pbt95NiS4QmhK4nEy0WLtN8wd98kCFIVdxm2Asi+eNijTMHtippUJm
DgyQdL0PMDgVlIet/Dz6mRzLshPR6HSGCyT3bBhlAoPHxSc6PNE09U9nUPgG5Kc=
=516q
-END PGP SIGNATURE-


-- 
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/20140517114917.16845.18236.report...@wollumbin.marsaxlokk.homelinux.org



Bug#745802: Please add libcpre.gcc.o to list of not distributable files

2014-04-26 Thread Paul Gevers
On 26-04-14 12:49, Bastien ROUCARIES wrote:
 Added, notes that you should ask to remove previous version of fpc
 from datas.debian.org

Sure, but I will do that after the current version of fpc has cleared
the NEW queue.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#745802: Please add libcpre.gcc.o to list of not distributable files

2014-04-25 Thread Paul Gevers
Package: lintian

Context:
cae2spab6s3wxkx+9enfheoci2bfq4o4+h__vkup6c2a93lw...@mail.gmail.com

On 21-04-14 21:51, roucaries bastien wrote:
 Could you open a lintian bug with:
 - md5sum
 - sha1
 - sha256
 
 of the previous file.
 
 I will add to not distributable list of file

paul@wollumbin $ md5sum libcpre.gcc.o
90c983b1d401c770bb28b03ad8791f9d  libcpre.gcc.o
paul@wollumbin $ sha1sum libcpre.gcc.o
241278e1b032954bdff6405b3c963c8f0208ad51  libcpre.gcc.o
paul@wollumbin $ sha256sum libcpre.gcc.o
3db379a515ed0abd0dc74a149e1b7039b9b2978e61470c8021b1cebb02750145
libcpre.gcc.o




signature.asc
Description: OpenPGP digital signature


Bug#745546: Re: Bug#745546: lintian: False positive: openttd source: source-is-missing os/dos/cwsdpmi/cwsdpmi.txt

2014-04-25 Thread Paul Gevers
On 22-04-14 20:47, Adam D. Barratt wrote:
 On Tue, 2014-04-22 at 19:17 +0200, Matthijs Kooijman wrote:
 The file referenced is somehow detected as a binary, even though it is
 just a text file containing licensing info and documentation. The file
 itself is available here:

 http://vcs.openttd.org/svn/browser/tags/1.4.0/os/dos/cwsdpmi/cwsdpmi.txt
 
 I suspect due to (on wheezy at least):
 
 $ file /tmp/cwsdpmi.txt 
 /tmp/cwsdpmi.txt: Macromedia Flash data (compressed), version 68

So, shouldn't this bug be reassigned to the file package?

Paul
[I have indeed two such files in my fpc package].




signature.asc
Description: OpenPGP digital signature


Bug#713844: lintian: debug-file-with-no-debug-symbols reports false positives on winff-dbg

2013-06-23 Thread Paul Gevers
Package: lintian
Version: 2.5.13
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear lintian maintainers,

As a heavy user of your package I like to inform you that I get
debug-file-with-no-debug-symbols reported against my package winff-dbg.
I verified with gdb that my package does contain the wished debugging
symbols.

I don't understand why my package does not follow this DWARF spec that
is mentioned in the report, but it is likely caused by the compiler I
use: Free Pascal. It could very well be a bug in fpc that it is not
following this spec, but I am not in the position to determine if it
should. Maybe someone could comment on that.

Paul

- -- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable'), (99, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lintian depends on:
ii  binutils   2.22-8
ii  bzip2  1.0.6-4
ii  diffstat   1.55-3
ii  file   5.11-2
ii  gettext0.18.1.1-9
ii  hardening-includes 2.2
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.26+b1
ii  libarchive-zip-perl1.30-6
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1+b2
ii  libdpkg-perl   1.16.10
ii  libemail-valid-perl0.190-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-1+b1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtext-levenshtein-perl   0.06~01-2
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.2-1
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-21
ii  t1utils1.37-2

Versions of packages lintian recommends:
ii  libautodie-perl 2.19-1
ii  libperlio-gzip-perl 0.18-1+b2
ii  perl-modules [libautodie-perl]  5.14.2-21

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.16.10
ii  libhtml-parser-perl3.69-2
ii  libtext-template-perl  1.45-2
ii  xz-utils   5.1.1alpha+20120614-2

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJRxsAfAAoJEJxcmesFvXUKXLsIAKS6lhC1gkMB93KAGQo2Al3j
TLQ5sFcHroqOla6Qdz4QsJkhMyvO03L0+hpiXmQphWT1QV2UBW5qvIrQ8KNWG1Qf
GWKHUubvm1Ut8vuOhi1bdeFACfq4Y+jGy5GrLW2s9LnTQuhwAZfmltrnSen1Oa5E
ZF4FV/F+5uRtgHaslWjc4uBiBGs1RhFLrDAKKPAbM7daKsD7lEOJjUOKKzCKLfG+
Zr++wO7lJMpvTH7Ah6i2A6S7veb0bymY1+iWIZn+KEaraJPxns+r3Yq9d908FZDE
c73ocj2FkONsSEIrR4H4BtVTyK55+THNmUzPj7iXCrv7BewT3ky3MQxLAhhRceU=
=va40
-END PGP SIGNATURE-


-- 
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/20130623093008.11863.97821.report...@wollumbin.marsaxlokk.homelinux.org



Bug#683059: lintian: package-contains-broken-symlink should also check recommended packages

2012-10-26 Thread Paul Gevers
On 22-10-12 22:32, Niels Thykier wrote:
 On 2012-07-28 10:16, Paul Gevers wrote:
 In my package I want to create a symlinks to manpages in a recommended
 package (the binaries use update-alternatives to provide the proper
 variant). I would nearly consider this recommended package a dependency
 but doing so would cause a circular dependency and anyway policy [7.2]
 says:
 
 I think the error would disappear if you were to put the symlink in the
 recommended package?  I appreciate that this may not be as easy as I
 make it sound.

The point is I want to prevent duplication of data (the 2 recommended
packages could have the same file of course, but that would in case of
large data not be nice):
winff (in experimental) depends on winff-gtk2 or winff-qt
winff contains winff.1
winff-gtk2 and winff-qt both have a symlink to winff.1
winff-gtk2 and winff-qt both recommend winff (to provide menu and man page)

 So I believe that symlinks to recommended packages should be fine, and
 as such the package-contains-broken-symlink check should also consider
 recommended packages next to depends packages.

 
 Strictly speaking it would still allow the package to ship a broken
 symlink, even if the situation is rare...

True.

 But I suppose the real question is whether Recommends is strong enough
 for this purpose...

Right. In my case I think it is. I consider the man page very important,
but not critical for a package to work. But of course, in the general
case for this check it might not be true. Maybe I should just overwrite
the Lintian warning. What do you think?

Paul



signature.asc
Description: OpenPGP digital signature


Bug#683059: lintian: package-contains-broken-symlink should also check recommended packages

2012-07-28 Thread Paul Gevers
Package: lintian
Version: 2.5.10
Severity: normal

Dear Maintainer,

In my package I want to create a symlinks to manpages in a recommended
package (the binaries use update-alternatives to provide the proper
variant). I would nearly consider this recommended package a dependency
but doing so would cause a circular dependency and anyway policy [7.2]
says:

Recommends: This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found
together with this one in *all but unusual installations*. [Emphasize by
me.]

So I believe that symlinks to recommended packages should be fine, and
as such the package-contains-broken-symlink check should also consider
recommended packages next to depends packages.

Feel free to tell me I am wrong in this, but please provide arguments.

Grtz
Paul

[7.2]
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

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

Kernel: Linux 3.2.0-26-generic-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set
to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.22-7.1
ii  bzip2  1.0.6-3
ii  diffstat   1.55-3
ii  file   5.11-2
ii  gettext0.18.1.1-9
ii  hardening-includes 2.2
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.26+b1
ii  libarchive-zip-perl1.30-6
ii  libc-bin   2.13-34
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1+b2
ii  libdpkg-perl   1.16.8
ii  libemail-valid-perl0.190-1
ii  libipc-run-perl0.91-1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.2-1
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-12

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.16.8
pn  libhtml-parser-perlnone
pn  libperlio-gzip-perlnone
pn  libtext-template-perl  none
ii  man-db 2.6.2-1
ii  xz-utils [lzma]5.1.1alpha+20120614-1

-- no debconf information



signature.asc
Description: OpenPGP digital signature


Bug#683060: lintian: *-command-not-in-package could check for alternatives in dependent packages

2012-07-28 Thread Paul Gevers
Package: lintian
Version: 2.5.10
Severity: normal

Dear Maintainer,

In my package I want to provide a binary via update-alternatives to
provide the multiple variants of the same program (a gtk2 and a qt
variant). I want to ship one desktop file and one menu file in a package
that depends on the either of the variants.

Currently both desktop-command-not-in-package and
menu-command-not-in-package raise a warning on this setup, but I believe
they are false positives that could be checked on the use of
update-alternatives in dependent packages.

Grtz
Paul

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

Kernel: Linux 3.2.0-26-generic-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set
to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.22-7.1
ii  bzip2  1.0.6-3
ii  diffstat   1.55-3
ii  file   5.11-2
ii  gettext0.18.1.1-9
ii  hardening-includes 2.2
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.26+b1
ii  libarchive-zip-perl1.30-6
ii  libc-bin   2.13-34
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1+b2
ii  libdpkg-perl   1.16.8
ii  libemail-valid-perl0.190-1
ii  libipc-run-perl0.91-1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.2-1
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-12

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.16.8
pn  libhtml-parser-perlnone
pn  libperlio-gzip-perlnone
pn  libtext-template-perl  none
ii  man-db 2.6.2-1
ii  xz-utils [lzma]5.1.1alpha+20120614-1

-- no debconf information





signature.asc
Description: OpenPGP digital signature


Bug#672297: lintian: False positive package-contains-broken-symlink for files created during postinst

2012-05-09 Thread Paul Gevers
Package: lintian
Version: 2.5.6
Severity: normal

Dear Maintainer,
My package cacti replaces an upstream file with a symlink to
/etc/cacti/debian.php. This later file is created upon configuration by
dbconfig-common. I therefor think this package-contains-broken-symlink
is a false positive in that case.

Furthermore, in postinst it (tries to) create /usr/local/share/ files.
Links in the normal /usr/share/cacti try point to it to provide a place
where local administrator can put there files. Again, I believe this is
a false positive.

Paul

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

Kernel: Linux 3.2.0-24-generic-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set
to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.22-6
ii  bzip2  1.0.6-1
ii  diffstat   1.55-2
ii  file   5.11-1
ii  gettext0.18.1.1-7
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.26+b1
ii  libc-bin   2.13-32
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1+b2
ii  libdpkg-perl   1.16.3
ii  libemail-valid-perl0.190-1
ii  libipc-run-perl0.91-1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.1-2
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-10
ii  unzip  6.0-6

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch none
ii  dpkg-dev   1.16.3
ii  libhtml-parser-perlnone
ii  libtext-template-perl  none
ii  man-db 2.6.1-2
ii  xz-utils   5.1.1alpha+20110809-3

-- no debconf information





signature.asc
Description: OpenPGP digital signature


Bug#548640: lintian check for dpatch describtion could honnor DEP3 style description

2009-09-28 Thread Paul Gevers
 I assume from that that dpatch supports DEP-3 and doesn't get confused by
 comments not using that prefix?

The patches apply cleanly. So I assume, yes. Header is maintained by
dpatch-edit-patch when the @DPATCH@ tag is found (according to it's own
comments).

Paul



signature.asc
Description: OpenPGP digital signature


Bug#548640: lintian check for dpatch describtion could honnor DEP3 style description

2009-09-28 Thread Paul Gevers
 The operation that I'd want to be sure to test is modifying the patch
 and regenerating it and being sure that dpatch retained the comments
 rather than rewriting the header and losing them.

Just did that and no problem.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#548640: lintian check for dpatch describtion could honnor DEP3 style description

2009-09-27 Thread Paul Gevers
Package: lintian
Version: 2.2.17
Severity: wishlist

In my packages I put the description of patches according to DEP-3 [1].
It would be nice if lintian would not complain about
dpatch-missing-description when the fields described by DEP-3 are
available instead of the ## DP: lines.

Paul

[1] http://dep.debian.net/deps/dep3/



signature.asc
Description: OpenPGP digital signature


Bug#526435: lintian: [checks/binaries.desc] Please add to the description that the case of the string can be different

2009-05-01 Thread Paul Gevers
Package: lintian
Version: 2.2.10
Severity: wishlist

*** Please type your report below this line ***

I spend quite some time yesterday of finding a sting which was in all
CAPS. Please add some comment to the description that the string
reported might be found in any variant of capitization. Maybe also a add
comment on how to find the string yourself, i.e. use
strings binary | grep -i string.

Kind regards
Paul

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

Kernel: Linux 2.6.28-11-generic (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=nl_NL.UTF-8 (charmap=ANSI_X3.4-1968) (ignored:
LC_ALL set to C)
Shell: /bin/sh linked to /bin/bash

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



signature.asc
Description: OpenPGP digital signature


lintian.debian.org

2009-04-04 Thread Paul Gevers
Hi,

The lintian version running on lintian.debian.org is old. In sid we have
2.2.9, while the site runs 2.2.0. Should I file a bug (against lintian?)
or can this easily be updated?

With kind regards and keep up the good work.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#507526: lintian --color=always gives errors and does not show colors

2008-12-01 Thread Paul Gevers
Package: lintian
Version: 2.1.0
Severity: minor
Thanks

When running lintian in a chroot with the --color=always option I get
error messages and the errors/warnings are not shown in color. Without
the color function it works fine. If lintian has no E/W to show the
error messages do not appear. See for an example below.

# lintian --allow-root --color=always lazarus_0.9.26-2.dsc
Use of uninitialized value $_ in split at
/usr/share/perl/5.10/Term/ANSIColor.pm line 121.
Use of uninitialized value in concatenation (.) or string at
/usr/share/perl/5.10/Term/ANSIColor.pm line 187.
W: lazarus source: patch-system-but-direct-changes-in-diff Makefile and
38 more
# lintian --allow-root lazarus_0.9.26-2.dsc
W: lazarus source: patch-system-but-direct-changes-in-diff Makefile and
38 more

Paul



signature.asc
Description: OpenPGP digital signature


Bug#478930: errors while using the check files under Ubuntu/Hardy

2008-09-09 Thread Paul Gevers
I am not sure if I am doing things with these files which I am not
supposed to do (I use Ubuntu/Hardy lintian on my sid package), but I get
the following output. It look to me that find errors are a bug? I put in
one instance each file on a new line (with the first line empty after
Files:, might that be the problem? And why do the checks try to
execute the xpm file? The source of my package are available at [1].

[EMAIL PROTECTED] /var/cache/pbuilder/sid-i386/result $ lintian -I -i
winff_0.42-2_i*
W: winff source: debian-copyright-unknown-field packaged-by
N:
N:   The package contains a copyright file that has an unknown field.
N:
W: winff source: debian-copyright-unknown-field packaged-date
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]
sh: debian/winff.xpm: Permission denied
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]
find: missing argument to `-path'
sh: debian/winff.xpm: Permission denied

[1] http://mentors.debian.net/debian/pool/main/w/winff/

Paul



signature.asc
Description: OpenPGP digital signature