Bug#1030586: lintian: Testsuite failure on some systems: 1h time offset in test ancient-source
On 2023-02-05, Axel Beckert wrote: > While running Lintian's testsuite on a much faster system compared to > my Sid amd64 running development workstation, I noticed the following > test suite failure when running "private/runtests" or trying to build > the package on a more modern and more performant box with Bookworm > amd64. (Use "private/runtests -o test:ancient-source" to just run the > affected test.) > > # Hints do not match > # > # --- > debian/test-out/eval/checks/unpack/ancient-source/hints.specified.calibrated > # +++ debian/test-out/eval/checks/unpack/ancient-source/hints.actual.parsed > # -ancient-source (source): unpack-message-for-source tar: > ancient-source-1.0/README: implausibly old time stamp 1969-12-31 23:59:59 > # +ancient-source (source): unpack-message-for-source tar: > ancient-source-1.0/README: implausibly old time stamp 1970-01-01 00:59:59 Wild guess would be timezone differences between the build environments? live well, vagrant
Bug#973334: lintian: URL in systemd-service-file-uses-deprecated-syslog-facility incorrect
Package: lintian Version: 2.99.0 Severity: normal The URL referenced in systemd-service-file-uses-deprecated-syslog-facility: Refer to https://github.com/systemd/systemd/blob/master/NEWS#L101 for details. This references a changing file by line number, and it tends to get new changes at the top, so the link is very likely to point to the wrong line on any project that is still making updates. It should probably point to a specific revision and/or tag, such as: https://github.com/systemd/systemd/blob/6706384a89ae0c462e7172588c80667190c4d9e2/NEWS#L724 live well, vagrant signature.asc Description: PGP signature
Bug#973335: lintian: missing-dep-for-interpreter outdated guile versions
Package: lintian Version: 2.99.0 Severity: normal X-Debbugs-CC: r...@defaultvalue.org The missing-dep-for-interpreter references old guile versions but not the newer versions: missing-dep-for-interpreter guile => guile | guile-2.0 | guile-2.2 guile-2.0 is not currently in bullseye due to RC bugs and I believe the maintainer would very much like to retire it. guile-3.0 is the newest guile present in bullseye. So lintian should at least be updated to: guile | guile-2.2 | guile-3.0 live well, vagrant signature.asc Description: PGP signature
Bug#944707: lintian: check for missing and unsigned .buildinfo files
On 2019-11-14, Chris Lamb wrote: >> It would be nice if lintian checked for the presence of a .buildinfo >> file when processing a .changes file. > > I'm obviously sold on the idea of .buildinfo files but what error or > mistake might such a missing file imply on behalf of the developer? I'm not sure it's a mistake, per se, but suggests that they're using very old tooling to build packages, or home-grown tooling, both of which might have various bugs... but that seems a weak argument to me. My goal in filing this bug is to gently nudge developers to include developer built .buildinfo files, and ideally sign them as well, which increases the number of .buildinfo files we are able to use to verify a given build. It is in Debian policy that packages *should* be reproducible, and .buildinfo files are a cruicial element to be able to demonstrate and verify that packages are reproducible. Ideally with a source-only upload, every build would have at least one .buildinfo from the build daemon and one .buildinfo from the developer who submitted the source package and at least two potential points of convergence. I would think something at the info or pedantic level would be most appropriate at this point in time, if deemed appropriate at all... All of which you're probably well aware, but at least this is forcing me to think it out more verbosely... Maybe lintian isn't the right place for this (yet), but happy to have started and to continue the conversation. live well, vagrant signature.asc Description: PGP signature
Bug#944707: lintian: check for missing and unsigned .buildinfo files
Package: lintian Version: 2.33.0 Severity: wishlist It would be nice if lintian checked for the presence of a .buildinfo file when processing a .changes file. For a stretch goal, it would be nice if it also checked if the .buildinfo file was signed. :) live well, vagrant signature.asc Description: PGP signature
Bug#929501: lintian: missing-dep-for-interpreter guile: very outdated guile versions
Package: lintian Version: 2.14.0 Severity: normal Tags: patch While packaging a new guile package, I got an error about missing dependencies that have been removed since before stretch! E: guile-ssh: missing-dep-for-interpreter guile => guile | guile-1.6 | guile-1.8 (usr/bin/ssshd.scm) #!/usr/bin/guile guile-1.6 was last present in wheezy. guile-1.8 was last present in jessie. guile-2.0 is available jessie-buster. guile-2.2 is available in buster. An untested patch attached which updates to guile-2.0 and guile-2.2. Though guile-2.0 should probably be discouraged for new packages, as there are bug reports requesting to migrate to 2.0 on a handful of packages, for example: https://bugs.debian.org/885188 Maybe that should be a lintian check as well? live well, vagrant From 9e4e6219b29fc1f246e5c1216fa9476f612fafb1 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Fri, 24 May 2019 15:39:31 -0700 Subject: [PATCH] versioned-interpreters: Add guile 2.0 and 2.2, remove 1.6 and 1.8. Guile version 1.6 was dropped in jessie, and 1.8 was dropped in stretch. --- data/scripts/versioned-interpreters | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/scripts/versioned-interpreters b/data/scripts/versioned-interpreters index 7e140590d..afd4274c8 100644 --- a/data/scripts/versioned-interpreters +++ b/data/scripts/versioned-interpreters @@ -69,7 +69,7 @@ # -guile => /usr/bin, guile-([\d.]+), guile-$1, 1.6 1.8, +guile => /usr/bin, guile-([\d.]+), guile-$1, 2.0 2.2, jruby => /usr/bin, jruby([\d.]+), jruby$1, 1.0 1.1 1.2 lua => /usr/bin, lua([\d.]+), lua$1, 40 50 5.1 5.2 octave => /usr/bin, octave([\d.]+), octave$1, 3.0 3.2 -- 2.20.1 signature.asc Description: PGP signature
Bug#658971: lintian: exits 1 without any policy violations/errors/warnings checking epoptes
Package: lintian Version: 2.5.4 Severity: normal since epoptes 0.3.2, lintian will exit 1 when checking epoptes, but produces no policy violations or other warnings or errors... you can download the .dsc from your favorite debian mirror, and: lintian epoptes_0.4.2-1.dsc ; echo $? 1 running with debug mode didn't reveal much to me, but maybe you'd find it revealing: lintian -d epoptes_0.4.2-1.dsc ; echo $? N: Lintian v2.5.4 N: Lintian root directory: /usr/share/lintian N: Configuration file: /etc/lintianrc N: Laboratory: N: N: Using profile debian/main. N: Selected action: check N: Requested data to collect: ar-info,bin-pkg-control,changelog-file,copyright-file,debfiles,debian-readme,diffstat,doc-base-files,file-info,index,init.d,java-info,md5sums,menu-files,objdump-info,override-file,scripts,strings,unpacked N: Selected checks: binaries,changelog-file,changes-file,conffiles,control-file,control-files,copyright-file,cruft,deb-format,debconf,debhelper,debian-readme,debian-source-dir,description,duplicate-files,fields,filename-length,files,group-checks,infofiles,init.d,java,manpages,md5sums,menu-format,menus,nmu,ocaml,patch-systems,po-debconf,rules,scripts,shared-libs,source-copyright,standards-version,version-substvars,watch-file N: Unpacking epoptes 0.4.2-1 [source] (source) in /tmp/z3igYqOhgL/pool/e/epoptes/epoptes_0.4.2-1_source N: Collecting info: diffstat ... N: Collecting info: unpacked ... N: Collecting info: index ... N: Reaping done jobs ... unpack epoptes 0.4.2-1 [source] (source) N: Collection script diffstat done N: Using dpkg-source to unpack epoptes N: Collection script index done N: Collection script unpacked done N: Reap done jobs ... unpack epoptes 0.4.2-1 [source] (source) N: Collecting info: override-file ... N: Collecting info: debfiles ... N: Collecting info: file-info ... N: Reaping done jobs ... unpack epoptes 0.4.2-1 [source] (source) N: Collection script debfiles done N: Collection script override-file done N: Collection script file-info done N: Reap done jobs ... unpack epoptes 0.4.2-1 [source] (source) N: Reaping done jobs ... unpack epoptes 0.4.2-1 [source] (source) N: Reap done jobs ... unpack epoptes 0.4.2-1 [source] (source) N: N: Processing source package epoptes (version 0.4.2-1, arch source) ... N: Base directory in lab: /tmp/z3igYqOhgL/pool/e/epoptes/epoptes_0.4.2-1_source N: Override file collected, loading it ... N: Running check: control-file ... N: Running check: cruft ... N: Running check: debconf ... N: Running check: debhelper ... N: Running check: debian-source-dir ... N: Running check: fields ... N: Running check: filename-length ... N: Running check: group-checks ... N: Running check: nmu ... N: Running check: patch-systems ... N: Running check: po-debconf ... N: Running check: rules ... N: Running check: source-copyright ... N: Running check: standards-version ... N: Running check: version-substvars ... N: Running check: watch-file ... N: Auto removing: unpacked ... 1 live well, vagrant -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), (120, 'unstable'), (110, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-686-pae (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 Versions of packages lintian depends on: ii binutils 2.22-5 ii bzip2 1.0.6-1 ii diffstat 1.55-2 ii file 5.09-2 ii gettext0.18.1.1-5 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.25+b1 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.31-1+b2 ii libdpkg-perl 1.16.1.2 ii libemail-valid-perl0.185-1 ii libipc-run-perl0.90-1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtimedate-perl 1.2000-1 ii liburi-perl1.59-1 ii locales2.13-24 ii man-db 2.6.0.2-3 ii patchutils 0.3.2-1.1 ii perl [libdigest-sha-perl] 5.14.2-6 ii unzip 6.0-5 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch ii dpkg-dev 1.16.1.2 ii libhtml-parser-perl3.69-1+b1 ii libtext-template-perl 1.45-2 ii man-db 2.6.0.2-3 ii xz-utils 5.1.1alpha+20110809-3 -- 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: http://lists.debian.org/20120207002813.GT3372@talon.fglan
Bug#587209: lintian: conflicting checks for dash
Package: lintian Version: 2.4.1~bpo50+1 Severity: normal if i build sdm with dependencies on dash, i get this: E: sdm: depends-on-essential-package-without-using-version depends: dash if i build sdm without any dependencies on dash, i get this: E: sdm: missing-dep-for-interpreter dash => dash (./etc/sdm/Xsession) so lintian, which is it? :) i could work around the issue by needlessly adding a versioned dependency on dash, but there's no real reason to have a versioned dependency. live well, vagrant -- 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/20100626080455.gk9...@claws.fglan
Bug#576581: lintian: empty-binary-package should skip udebs
Package: lintian Version: 2.3.4~bpo50+1 Severity: normal the new lintian check empty-binary-packge should skip udebs, as it is not uncommon for a udeb to only contain a postinst script and dependencies, and it would seem silly to flag them all as metapackages. thanks! live well, vagrant -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable'), (103, 'testing'), (102, 'unstable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (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/bash 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.29 Debian package development tools ii file4.26-1 Determines file type using "magic" ii gettext 0.17-4 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libapt-pkg-perl 0.1.22+b1Perl interface to libapt-pkg ii libclass-accessor-p 0.31-2 Automated accessor generator ii libipc-run-perl 0.80-2 Perl module for running processes 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 locales 2.7-18lenny2 GNU C Library: National Language ( ii man-db 2.5.2-4 on-line manual pager ii perl [libdigest-sha 5.10.0-19lenny2 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch (no description available) pn libtext-template-perl (no description available) ii man-db2.5.2-4on-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 Archive: http://lists.debian.org/20100405194244.ga27...@claws.fglan
Bug#564740: lintian: treats "useable" as a spelling error.
Package: lintian Version: 2.3.1 Severity: minor i get several lintian warnings with regards to the spelling of "useable": W: qemu-user-static: spelling-error-in-changelog useable usable according to wordnet, at least, "useable" and "usable" are synonyms of each other. http://en.wiktionary.org/wiki/usable also lists "useable" as an alternate form. i don't know if lintian is in a better position to be an authorative source of the english language. :) live well, vagrant -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544004: depends-on-metapackage: too strict a defintion for metapackage
On Thu, Aug 27, 2009 at 10:56:33PM -0700, Russ Allbery wrote: > Vagrant Cascadian writes: > > both education-desktop-other and ltsp-client are metapackages, or nearly > > so, containing only standard /usr/share/doc files, lintian overrides ...snip... > > how does lintian determine if a package is a "true" metapackage? > > Lintian doesn't think that either are metapackages because they are both > arch-dependent and it usually doesn't make any sense for a metapackage to > be arch-dependent. Why *are* they arch-dependent? to have architecture-specific dependencies. is this unreasonable for a metapackage? live well, vagrant -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544004: depends-on-metapackage: too strict a defintion for metapackage
Package: lintian Version: 2.2.14 Severity: wishlist thanks for maintaining lintian. for at least two packages i've worked on, it seems that they get "depends-on-metapackage" lintian errors: http://lintian.debian.org/tags/depends-on-metapackage.html "Packages that are not themselves metapackages must not depend on metapackages, since this may prevent the user from removing portions of the package set they don't need." both education-desktop-other and ltsp-client are metapackages, or nearly so, containing only standard /usr/share/doc files, lintian overrides (for the predecessor to depends-on-metapackage, depends-on-x-metapackage), and i guess education-desktop-other also contains a cdd task file. but that still confuses me why ltsp-client is treated as a metapackage. how does lintian determine if a package is a "true" metapackage? live well, vagrant -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530565: lintian: newer .dsc files trigger magic-arch-in-arch-list errors
Package: lintian Version: 2.2.10 Severity: normal dpkg-source (dpkg 1.15.1) now generates .dsc files with an Architecture line that may contain a limited set of architectures plus "all", such as the debian-edu-artwork package: Format: 1.0 Source: debian-edu-artwork Binary: debian-edu-artwork, debian-edu-artwork-usplash Architecture: all i386 amd64 powerpc sparc Version: 0.0.29 this seems to trigger the magic-arch-in-arch-list lintian error, due to an intentional change in dpkg 1.15.1: #526617 dpkg: mentions arch:any in dsc way too often i'm thinking lintian should be updated to reflect this change, unless the dpkg-source changes need more work... live well, vagrant -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
