Bug#1029633: lintian should give an error for binary-all binary packages containing Built-Using
On Fri, Feb 10, 2023 at 11:10:42AM +0100, Andreas Beckmann wrote: > On Wed, 25 Jan 2023 20:26:56 +0200 Adrian Bunk wrote: > > built-using-field-on-arch-all-package already exists, > > but it has two problems: > > > > 1. It is only info, not error. > > What's the problem with arch:all using Build-Using? >... > (Yes, you can't binNMU the package to bump the B-U in order to kick old > source packages from the archive that are solely kept to satisfy B-U). The release team binNMUs a 4 digit number of packages before a release (and sometimes between releases in unstable) to get Extra-Source-Only ideally down to 0. Extra-Source-Only means we might even have our mirrors serve sources of packages that were removed years ago due to "not distributable". > Andreas cu Adrian
Re: Bug#1029044: gcc-12-cross-mipsen: source and binary version go out of sync
Control: tags -1 ftbfs
Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10
Control: reassign -2 src:gcc-10-cross
Control: retitle -2 gcc-10-cross: source and binary version go out of sync
Control: reassign -3 src:gcc-10-cross-ports
Control: retitle -3 gcc-10-cross-ports: source and binary version go out of sync
Control: reassign -4 src:gcc-11-cross
Control: retitle -4 gcc-11-cross: source and binary version go out of sync
Control: reassign -5 src:gcc-11-cross-ports
Control: retitle -5 gcc-11-cross-ports: source and binary version go out of sync
Control: reassign -6 src:gcc-11-cross-mipsen
Control: retitle -6 gcc-11-cross-mipsen: source and binary version go out of
sync
Control: block -6 by -4
Control: reassign -7 src:gcc-12-cross
Control: retitle -7 gcc-12-cross: source and binary version go out of sync
Control: block -1 by -7
Control: reassign -8 src:gcc-12-cross-ports
Control: retitle -8 gcc-12-cross-ports: source and binary version go out of sync
Control: reassign -9 src:gcc-13-cross
Control: retitle -9 gcc-13-cross: source and binary version go out of sync
Control: reassign -10 src:gcc-13-cross-ports
Control: retitle -10 gcc-13-cross-ports: source and binary version go out of
sync
On Mon, Jan 16, 2023 at 09:21:52PM +0100, Paul Gevers wrote:
> Source: gcc-12-cross-mipsen
> Version: 1+c2
> Severity: serious
>
> Dear maintainer,
>
> The current version in unstable is stuck, because the mips64el build
> is kept in Uploaded state. Asking around on #d-buildd, I got the
> following discussion:
>
> [20:09:34] mips64el 3days in uploaded state feels like an issue,
> right? https://buildd.debian.org/status/package.php?p=gcc-12-cross-mipsen
> [20:18:32] probably means dak rejected it
> [20:18:45] Your upload included the binary package
> cpp-12-mips-linux-gnu, version 12.2.0-13cross1, for mips64el,
> [20:18:48] however unstable already has version 12.2.0-14cross2.
> [20:19:09]
> coccia:/srv/ftp-master.debian.org/queue/reject/gcc-12-cross-mipsen_3+c1_mips64el-buildd.changes.reason
> [20:29:57] the higher version is
> [20:29:57] Source: gcc-12-cross-mipsen (2+c1)
> [20:30:23] so the generated version numbers are broken
> [20:32:07] not for the first time afair
> [[21:04:30] adsb: thanks for looking; but the source is 3+c1, no? or
> did the older one generate a newer binary?
>
> You may want to check your logic.
The packaging is copied from gcc-12-cross,
problems have to be fixed there first,
and also in the other gcc-*-cross* packages.
There are at least 3 problems:
1. The way debian/new_cross_version.sh uses "apt-cache policy" to create
a version number makes the package not reproducible even if the same
versions of the build dependencies are installed, and it also causes
problems like this one here.
Other packages using {binutils,gcc-*,gdb}-source seem to get it right, e.g.:
Package: gcc-xtensa-lx106
Source: gcc-xtensa-lx106 (8)
Version: 10.2.1-6+8+b1
Built-Using: gcc-10 (= 10.2.1-6)
There is no reason why the gcc-*-cross* packages could not use similar
versioning.
2. binary-any packages built from the same gcc-*-cross* packages
currently have >= dependencies on binary-all packages built from
the same sources. Since the version number of the gcc-*-cross* packages
packages contains the version of the gcc-*-source package, this does
not only prevent binNMUs (which itself is already an RC bug) but also
similarly causes problems like #1028441 when packages are built later
on an architecture (in this case due to #1026129, which was caused by
#1026245 in src:gcc-12).
The correct solution is to make such binary-all packages binary-any,
which allows = dependencies and removes all such race conditions and
non-binNMUableness.
3. Built-Using in the binary-all packages is something that should IMHO
become a non-overridable automatic REJECT in dak.
The gcc-*-cross* packages seem to avoid the
built-using-field-on-arch-all-package
lintian tag by not declaring the Built-Using in debian/control, but
adding it during the build.[1]
Example package: lib32gcc-s1-s390x-cross
I've just filed #1029633 asking for a lintian tag for that.
> Paul
cu
Adrian
[1] https://sources.debian.org/src/gcc-12/12.2.0-14/debian/rules.conf/#L1286
Bug#944707: lintian: check for missing and unsigned .buildinfo files
On Wed, Nov 13, 2019 at 11:36:37PM -0800, Vagrant Cascadian wrote: > 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... >... Or passing the --buildinfo-option=-O/tmp/dpkgisstupid option to dpkg-buildpackage because buildinfo files don't make sense for source-only uploads. cu Adrian
Bug#944707: lintian: check for missing and unsigned .buildinfo files
On Fri, Nov 15, 2019 at 10:17:04PM -, Chris Lamb wrote: >... > For starters, if Lintian complained about unsigned .buildinfo files it > would seem sensible to warn about unsigned .changes "first", >... The logical logical order is that lintian runs before signing, signing potentially broken packages feels wrong. dput already rejects unswigned changes, and this is the right place for the check. cu Adrian
Bug#961973: lintian: Please warn on x86_64-linux-gnu in debian/not-installed
Package: lintian Version: 2.78.0 Severity: wishlist With dh compat 13 many maintainers add debian/not-installed. A common problem (e.g. #961104, #961960) is that maintainers add files under /usr/lib/x86_64-linux-gnu/ It would be good to have a warning like: debian/not-installed contains an entry with 'x86_64-linux-gnu'. This is usually a bug that will cause build failures on architectures other than amd64. Using '*' as wildcard is possible.
Bug#919957: Please check for binaries depending on unused libraries
On Mon, Jan 21, 2019 at 09:42:26AM -0800, Josh Triplett wrote: > On January 21, 2019 8:48:35 AM PST, Chris Lamb wrote: > >Hi Matthias, > > > >> [...] I think I'll enable that by default in GCC 9 for bullseye. > > > >Cool. I think that therefore asking Developers to add it manually > >via Lintian would therefore not be ideal - what do you think? > > I think there'd still be value in catching binaries that still end up with > unused dependencies for some reason, but making --as-needed the default will > certainly reduce the incidence of such issues. It clearly doesn't make sense to have the warning before the default changed and a large part of the archive has been rebuilt with the changed default. After that, the problem will be that lintian would be mostly reporting the special cases where linking with a library is required despite no symbol used. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#919957: Please check for binaries depending on unused libraries
[ Josh: The BTS does not Cc submitter or commenters, so I didn't get your email. ] On Mon, Jan 21, 2019 at 03:37:02PM +, Chris Lamb wrote: > [Adding d...@debian.org to CC] > > Josh Triplett wrote: > > > > This does not sound like a good idea to me, since fixing such warnings > > > would result in many ugly (and sometimes not upstreamable) hacks. > > > > In most cases, fixing such warnings would involve either adding > > --as-needed or just removing a library from linking for a given program. > > I believe Adrian's wider point was more that there would be no need to > add --as-needed if it were made the default in Debian. Correct, manually adding --as-needed on a per-package basis would be more work for less benefits. > I believe doko (added to CC) was working on this (eg. #916831); is there > a status, ETA, tracking bug, etc.? These are FTBFS in Ubuntu, which switched to --as-needed as default 8 years ago. > Regards, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#919957: Please check for binaries depending on unused libraries
On Sun, Jan 20, 2019 at 03:45:35PM -0800, Josh Triplett wrote: > Package: lintian > Version: 2.5.122 > Severity: normal > > I'd love to see lintian catch issues like this: > > $ ldd -u /sbin/badblocks > Unused direct dependencies: > /lib/x86_64-linux-gnu/libblkid.so.1 > > Lintian already parses binaries and libraries with objdump, so catching > this seems reasonable. This does not sound like a good idea to me, since fixing such warnings would result in many ugly (and sometimes not upstreamable) hacks. People blindly removing libraries due to lintian might also introduce new bugs, there are some nasty special cases where this might not be safe. Instead of doing this manually on a per-package basis, making --as-needed the default as Ubuntu already does would be the proper way forward. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#909696: lintian: debian-rules-should-not-use-custom-compression-settings overzealously also reports -Zgzip
On Thu, Sep 27, 2018 at 01:02:11AM +0200, Axel Beckert wrote: > Package: lintian > Version: 2.5.106 > > Hi, Hi Axel, first of all apologies for the late reply (and thanks to Chris for the ping). > according to the bugreport https://bugs.debian.org/829100 this tag was > primarily meant to catch too high xz compression settings. Also the > lintian long description seems to be targetted towards that case. Agreed that the description for this tag as well as for debian-source-options-has-custom-compression-settings is no lomger correct. What about adding the following pararaph after the "Whilst higher levels" paragraph: Other compression level or algorithm changes are less harmful, but unless there is an exceptional reason why different settings are important for a package the defaults should be used. This also makes future archive-wide changes of the defaults easier. > But this tag is also emitted on the rather conservative "-Zgzip" option > which is not that uncommon if you want to keep a package being able to > be installed on Debian Wheezy ELTS or Ubuntu 12.04 ESM (both are still > supported to some degree and have dpkg 1.16.x. And at least dpkg in > Wheezy has no xz support). It is not supported to install packages that were built on buster on distributions older than stretch, the recommended way is to rebuild the package for the target release - even the hello binary package in stretch has a libc6 dependency that cannot be fulfilled in wheezy. Also note that only 7 of the 234 emitted tags are for -Zgzip. I can see that the one in debootstrap was intentional, and the "-Zgzip -z1"in the 3 ufoai-* packages might have been due the contents already compressed. But these are rare exceptions, and noone is objecting to a lintian override in such cases. The other 3 -Zgzip usages look incorrect at first sight. For debian-source-options-has-custom-compression-settings 24 out of 503 warnings are for gzip. Except for debootstrap (again) there is none that looks at first sight justified. > So IMHO this tag should not be emitted with legacy compression formats > like gzip or bzip2 The bzip2 cases I have seen so far were manual settings to a better compression than the then-default gzip long ago, that do now give worse compression than the current default. In general I do not see any usecase anywhere left for bzip2, gzip is more portable and xz compresses better. > (at least not with those which were default in the > past), just with too high (but not too low) xz compression settings or > more exotic (never having been default, like IIRC lzma) compression > formats. AFAIK lzma is not permitted in the archive. > I though see that explicitly using legacy compression formats > (especially bzip2 comes to my mind) may no more be supported in dpkg in > some future release, so it might be good to warn about that, too. But > that's by far less severe that too heavy xz compression settings. > > So maybe this should be split up into two tags: > > * too exotic/strong settings (warning level; current long desc.) > * conservative, maybe not future-proof settings which once were default > (pedantic level; new long desc.) In my experience ~ 99% of all packages that fiddle with compression options shouldn't have been doing that ever, and that this should be a warning level lintian message so that it gets fixed and won't interfere if the defaults get changed again in the future. Like hundreds of packages doing nothing other than the default with -Zxz right now is clearly not severe, but with a lintian warning it becomes visible for the maintainer that this should be removed. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#909510: please add a lintian note to inform/warn about python in the shebang (instead of python2/python2.7)
On Mon, Sep 24, 2018 at 06:26:15PM +0200, Matthias Klose wrote: > Package: lintian > Severity: wishlist > > please add a lintian note to inform/warn about python in the shebang (instead > of > python2/python2.7). > > There is discussion upstream about updating PEP 394 to recommend soft-linking > python to python3 on newer distributions. Not a good idea from my point of > view, but it would be better if we remove the usage of python as a shebang in > our packages. Replacing that with python2 or python2.7 should be easy and > safe. > It would be nice if lintian could help with this task. Maybe first as a note > so > we can get an overview. Isn't it too late for such a lintian warning to make sense? We are only 5.5 months away from the buster freeze, and there is no realistic chance of fixing this archive-wide until then. Unless plans have changed python2 will not be part of bullseye, and for that to happen removal of any python2 usage has to start aggressively directly after the release of buster. The lintian warning would be moot then. If such an upstream change will be in bullseye or later, the realistic solution would be to add a Breaks: python-minimal Replaces: python-minimal to python3-minimal. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907423: lintian should give an error when both foo-dbg and foo-dbgsym are built
Control: tags -1 - moreinfo On Thu, Sep 06, 2018 at 11:32:07AM +0100, Chris Lamb wrote: > tags 907423 + moreinfo > thanks > > Hi Adrian, > > > > > lintian should give an error when both foo-dbg and foo-dbgsym are > > > > built > > Sorry for the delay in getting back to you. I wonder; why not rely on > the existing debian-control-has-obsolete-dbg-package tag? That's for a related but different problem (and currently not even a warning). It cannot find #907422 due to https://sources.debian.org/src/lintian/2.5.99/data/common/dbg-pkg/#L4 > Regards, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907423: lintian should give an error when both foo-dbg and foo-dbgsym are built
On Mon, Aug 27, 2018 at 09:18:43PM +0100, Chris Lamb wrote: > Hi Adrian, > > > lintian should give an error when both foo-dbg and foo-dbgsym are > > built > > Could you provide another draft description? Thank you in advance. Both -dbg and -dbgsym are built for this package. Only one should be built for the debug symbols. Usually the -dbg should be dropped in favour of the -dbgsym. In some cases (e.g. for Python modules) the -dbg contains more than just the debug symbols. In these cases the -dbgsym should not be built. > Regards, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907423: lintian should give an error when both foo-dbg and foo-dbgsym are built
Package: lintian Version: 2.5.98 Severity: normal #907362 and #907422 are examples of this problem. Note that it is not always the -dbg that is wrong, e.g. #907422 is a python case where the -dbgsym are likely bogus.
Bug#907276: lintian should give an error on Multi-Arch: same packages calling py{,3}compile in maintainer scripts
On Sat, Aug 25, 2018 at 08:58:36PM +0100, Chris Lamb wrote:
> Hi Adrian,
>
> > #889053 is an example why Multi-Arch: same packages
> > calling py{,3}compile in maintainer scripts is a
> > broken situation.
> >
> > More background is in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812228#36
>
> Thanks.
>
> Can you provide some example text for the description? Happy to rework
> an initial draft, but getting the background from someone definitely
> "in the know" about the issue whilst it is fresh in their mind would be
> ideal.
pycompile and py3compile do not support installing several architectures
of the same package.
If the contents of the package is not architecture-dependent,
it should usually be made binary-all.
If the contents of the package is architecture-dependent,
it should usually get a dependency on the python interpreter
for the same architecture.
Since installing multiple architecture versions of the
same python interpreter is not allowed, this makes the
Multi-Arch: same not have any effect.
<-- snip -->
The above test uses "usually" to express that there can be special cases
like gir1.2-ibus-1.0 that might end up being handled differently.
pycompile/py3compile with Multi-Arch: same is fatal in any case.
> Regards,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Bug#907276: lintian should give an error on Multi-Arch: same packages calling py{,3}compile in maintainer scripts
Package: lintian
Version: 2.5.97
Severity: normal
#889053 is an example why Multi-Arch: same packages
calling py{,3}compile in maintainer scripts is a
broken situation.
More background is in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812228#36
Bug#906610: lintian should check that changes and changelog distribution are identical
On Sat, Aug 18, 2018 at 10:43:07PM +0100, Chris Lamb wrote: > tags 906610 + moreinfo > thanks > > Hi Adrian, > > > > > https://lists.debian.org/debian-changes/2018/08/msg00012.html > > > > > > > > Distribution: stretch > > > > python-stem (1.6.0-4~bpo9+1) stretch-backports; urgency=medium > > > > > > Would this specific instance have been covered by #906155? > > > > This specific instance, yes. > > > > But not for example > > https://tracker.debian.org/news/978910/accepted-sane-backends-1027-1experimental6-source-into-unstable/ > > Gotcha. > > Julien, thoughts on expanding your previous tag to catch ones like > this? I'm a little hesistant to simply warn on mismatching > distributions; I'm sure there are some fancy "tricks" done for security > foo that you might be aware of.. I would be surprised if there is any case where this has to happen. Usually these are accidents due to a "feature" of sbuild. > Regards, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#906610: lintian should check that changes and changelog distribution are identical
On Sat, Aug 18, 2018 at 10:35:00PM +0100, Chris Lamb wrote: > Adrian, > > > https://lists.debian.org/debian-changes/2018/08/msg00012.html > > > > Distribution: stretch > > python-stem (1.6.0-4~bpo9+1) stretch-backports; urgency=medium > > Would this specific instance have been covered by #906155? This specifc instance, yes. But not for example https://tracker.debian.org/news/978910/accepted-sane-backends-1027-1experimental6-source-into-unstable/ > Regards, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#906610: lintian should check that changes and changelog distribution are identical
Package: lintian Version: 2.5.97 Severity: normal https://lists.debian.org/debian-changes/2018/08/msg00012.html Distribution: stretch python-stem (1.6.0-4~bpo9+1) stretch-backports; urgency=medium This is a relatively common problem for people using sbuild. It would be good if lintian could check that the the distribution in changes and the distribution in the changelog entry are identical
Bug#906611: rules-xz-compression-level-too-high should be changed to package-uses-custom-compression
Package: lintian Version: 2.5.97 Severity: normal There are actually two issues: First, lintian should warn for any usage of -Z/-S/-z no matter the values. Manual fiddling with these tends to cause future problems without actual benefits, uses-deprecated-compression-for-data-tarball is another example for such problems. For having any visible effects such changes anyways have to be done globally in the archive, not at a per-package level. Second, debian/source/options also has to be checked. Example: https://sources.debian.org/src/vtk-dicom/0.7.10-1/debian/source/options/
Bug#898077: lintian: False positive in missing-build-dependency-for-dh-addon, python package
On Sun, May 06, 2018 at 08:42:00PM +, Niels Thykier wrote: > Chris Lamb: > > tags 898077 + pending > > thanks > > > >> Lintian should perhaps check of there is a python package that meets the > >> dependency requirement? Or allow e.g. "*scour"? > > > > We can't do a wildcard (!) It would also have been wrong in this case, since the Python 3 module package does not (and should not) have a dependency on the dh addon. In stretch the dh addon is (wrongly) in the Python 2 module package, that's the only reason why we ended up with the python-scour -> scour dependency. > > but we can also check for > > python-scour. I've done this in Git, pending upload: > > > > > > https://salsa.debian.org/lintian/lintian/commit/fc69686ae2d6aff415762812e805af4e5e9ca627 > > > > data/debhelper/dh_addons-manual | 1 + > > debian/changelog| 4 > > 2 files changed, 5 insertions(+) > > > > > > Regards, > > > > Hi, > > I am not entirely convinced this is a good idea. As I understand it, > that dependency is a temporary measure to avoid breakage but the plan is > to remove the dependency (i.e. packages will be required to build-depend > directly on "scour" for the add-on). >... python-scour is Python 2, so the plan is that python-scour will be removed after buster. Looking at scenarios like stretch-backports, it might be easiest to consider python-scour build dependencies as fine here for now and handle them after buster with the general Python 2 removal. > Thanks, > ~Niels cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#896840: lintian: autopkgtest fails with new version of file
Control: severity -1 serious Control: found -1 2.5.83 On Tue, Apr 24, 2018 at 09:32:33PM +0200, Paul Gevers wrote: > 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². >... This is also a FTBFS: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/lintian.html > Paul >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#896079: lintian: misleading description for dependency-on-python-version-marked-for-end-of-life
Package: lintian Version: 2.5.83 Severity: normal "The package specifies a dependency on Python 2.x which is due for deprecation and will not be maintained past 2020." This is misleading, since Debian will (security) support Python 2.7 until at least mid-2022 (EOL for buster). Please change this to: "The package specifies a dependency on Python 2.x which will likely be dropped after buster."
Bug#895831: lintian should warn on sanitize=+all in debian/rules
Package: lintian Version: 2.5.81 Severity: wishlist Example: #895811, with debian/rules containing: export DEB_BUILD_MAINT_OPTIONS = hardening=+all qa=+all sanitize=+all >From dpkg-buildflags(1): Note: these options should not be used for production builds as they can reduce reliability for conformant code, reduce security or even functionality.
Bug#893326: lintian: check that patch licenses are compatible with licenses of files they modify
On Sun, Mar 18, 2018 at 01:31:05PM +0800, Paul Wise wrote: > On Sun, 2018-03-18 at 01:50 +, Chris Lamb wrote: > > > I am unsure that a debian/ directory plus the upstream source really > > creates a derived work. > > It definitely does when there are patches to the upstream code in > debian/, which is the case I'm talking about with this feature request. >... What is supposed to be checked here, and how should that be fixed outside the trivial case where all upstream files are under the same licence? As an example, think of a kernel patch that touches two files: 1. source file with SPDX-License-Identifier: GPL-2.0 2. userspace header with SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note "same license as upstream" are two different licences for different parts of the patch, and the Debian kernel maintainer is usually not the author of a patch cherry-picked from upstream. Want copyright information do you want to make mandatory for patches in src:linux? DEP-5 listing of every patch, and for patches like the example above a detailed explanation which parts of a patch are under which licence? IMHO it would be more reasonable to treat debian/patches/ as special case, defaulting to "same licence as the patched code". > bye, > pabs cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#890920: lintian should warn about very short changelog entries
Package: lintian Version: 2.5.75 Severity: normal lintian should warn if the changelog for the current version contains a very short (< 10 characters?) entry. Example from a recent upload: * dh 11 * R³ Suggested tag description: debian/changelog for the current version contains a very short entry. This makes it usually harder to read the changelog. Often the problem is excessive use of abbreviations. Keep in mind that: * Many users will read the changelog through apt-listchanges. * The information in debian/changelog is permanent. It is not uncommon that people read changelog entries that are more than a decade old for understanding why a package works in a specific way. Example for too short entries: * dh 11 * R³ Suggestion how to improve this example: * Switch to debhelper compat 11. * Rules-Requires-Root: no
Bug#889016: lintian: Please update dh_commands for scour 0.36-2
Package: lintian Version: 2.5.69 Severity: normal This was changed in #885106 but has to be changed again since dh_scour is after #886203 in an own scour package.
Bug#888074: lintian FTBFS on armhf: spelling-error-in-binary false positives (?)
Source: lintian Version: 2.5.70 Severity: serious https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/lintian.html ... tests::binaries-golang: diff -u t/tests/binaries-golang/tags /build/1st/lintian-2.5.71/debian/test-out/tests/binaries-golang/tags.binaries-golang --- t/tests/binaries-golang/tags2018-01-21 05:24:47.0 + +++ /build/1st/lintian-2.5.71/debian/test-out/tests/binaries-golang/tags.binaries-golang 2018-01-21 11:16:29.392843265 + @@ -0,0 +1 @@ +I: binaries-golang: spelling-error-in-binary usr/lib/foo/static cymK CMYK fail tests::binaries-golang: output differs! . tests::binaries-general: diff -u t/tests/binaries-general/tags /build/1st/lintian-2.5.71/debian/test-out/tests/binaries-general/tags.binaries-general --- t/tests/binaries-general/tags 2018-01-21 05:24:47.0 + +++ /build/1st/lintian-2.5.71/debian/test-out/tests/binaries-general/tags.binaries-general 2018-01-21 11:16:39.152838686 + @@ -6,6 +6,7 @@ E: binaries-general: library-in-debug-or-profile-should-not-be-stripped usr/lib/debug/usr/share/foo/basic E: binaries-general: statically-linked-binary usr/bin/static E: binaries-general: unstripped-binary-or-object usr/bin/unstripped +I: binaries-general: spelling-error-in-binary usr/bin/static cymK CMYK W: binaries-general: binary-compiled-with-profiling-enabled usr/share/foo/basic W: binaries-general: binary-without-manpage usr/bin/static W: binaries-general: binary-without-manpage usr/bin/unstripped fail tests::binaries-general: output differs! ..S.S.S. ..S.S..SS... S... S... ...SS.. tests::legacy-binary: diff -u t/tests/legacy-binary/tags /build/1st/lintian-2.5.71/debian/test-out/tests/binary/tags.binary --- t/tests/legacy-binary/tags 2018-01-21 05:24:47.0 + +++ /build/1st/lintian-2.5.71/debian/test-out/tests/binary/tags.binary 2018-01-21 11:37:39.777391006 + @@ -59,6 +59,10 @@ I: binary: desktop-entry-lacks-keywords-entry usr/share/applications/goodbye.desktop I: binary: desktop-entry-lacks-keywords-entry usr/share/applications/hello.desktop I: binary: no-md5sums-control-file +I: binary: spelling-error-in-binary boot/hello/hello-static cymK CMYK +I: binary: spelling-error-in-binary usr/bin/hello-static cymK CMYK +I: binary: spelling-error-in-binary usr/bin/hello.static cymK CMYK +I: binary: spelling-error-in-binary usr/bin/static-hello cymK CMYK W: binary source: ancient-standards-version 3.2.1 (released 2000-08-24) (current is CURRENT) W: binary source: debian-rules-ignores-make-clean-error line 14 W: binary source: debian-rules-missing-recommended-target build-indep fail tests::legacy-binary: output differs! . Skipped/disabled tests: [debs] deb-format-wrong-order: Unmet test dependencies: dpkg (<< 1.17.2) [tests] binaries-from-other-arch: architecture mismatch binaries-multiarch: architecture mismatch binaries-multiarch-wrong-dir: 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~) files-multiarch-foreign-files: architecture mismatch runtests-arch-amd64: architecture mismatch runtests-arch-i386: architecture mismatch shared-libs-non-pic-i386: architecture mismatch upstream-metadata-invalid-yml: (disabled) YAML::XS executes code by default and code has not been converted version-substvars-obsolete: Unmet test dependencies: dpkg (<< 1.17.2) Failed tests (3) tests::binaries-golang tests::binaries-general tests::legacy-binary debian/rules:48: recipe for target 'runtests' failed make[1]: *** [runtests] Error 1
Bug#886163: closed by Chris Lamb <la...@debian.org> (Bug#886163: fixed in lintian 2.5.68)
Control: reopen -1 On Tue, Jan 09, 2018 at 03:39:22PM +, Debian Bug Tracking System wrote: >... >* t/tests/files-multiarch-foreign-files: > + [CL] Ensure that we install to a multiarch directory on all >architectures to prevent a FTBFS on, for example, i386. >(Closes: #886163) >... This seems to have only moved the test failure: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/lintian.html ... -E: libfoo-dev: multiarch-foreign-cmake-file usr/lib/TRIPLET/cmake/foo.cmake -E: libfoo-dev: multiarch-foreign-pkgconfig usr/lib/TRIPLET/pkgconfig/libfoo.pc -E: libfoo-dev: multiarch-foreign-static-library usr/lib/TRIPLET/libfoo.a +E: libfoo-dev: triplet-dir-and-architecture-mismatch usr/lib/TRIPLET/ is for amd64 ... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#886163: lintian FTBFS on i386: fail tests::files-multiarch-foreign-files: output differs!
Source: lintian Version: 2.5.66 Severity: serious https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/lintian.html ... tests::files-multiarch-foreign-files: diff -u t/tests/files-multiarch-foreign-files/tags /build/1st/lintian-2.5.67/debian/test-out/tests/files-multiarch-foreign-files/tags.files-multiarch-foreign-files --- t/tests/files-multiarch-foreign-files/tags 2018-01-01 14:58:24.0 + +++ /build/1st/lintian-2.5.67/debian/test-out/tests/files-multiarch-foreign-files/tags.files-multiarch-foreign-files 2019-02-04 09:30:53.054375012 + @@ -1,3 +0,0 @@ -E: libfoo-dev: multiarch-foreign-cmake-file usr/lib/TRIPLET/cmake/foo.cmake -E: libfoo-dev: multiarch-foreign-pkgconfig usr/lib/TRIPLET/pkgconfig/libfoo.pc -E: libfoo-dev: multiarch-foreign-static-library usr/lib/TRIPLET/libfoo.a fail tests::files-multiarch-foreign-files: output differs! SS.. Skipped/disabled tests: [debs] deb-format-wrong-order: Unmet test dependencies: dpkg (<< 1.17.2) [tests] 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-amd64: architecture mismatch upstream-metadata-invalid-yml: (disabled) YAML::XS executes code by default and code has not been converted version-substvars-obsolete: Unmet test dependencies: dpkg (<< 1.17.2) Failed tests (1) tests::files-multiarch-foreign-files
Bug#882154: lintian: Raise level for -dbg packages
On Sun, Nov 19, 2017 at 06:14:54PM +0100, Christoph Biedl wrote: >... > Related, unless there's still a situation where -dbg packages serve a > purpose - I'm not aware of such and cannot think of any either - I > wouldn't mind if ftp-master starts to autoreject such packages, perhaps > with NMUs as an exception. There are various reasons where -dbg packages are still required. One example are the python -dbg packages that also use python-dbg. Another example are -dbg packages that have reverse dependencies. > Christoph cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#878806: debug-file-with-no-debug-symbols: mention lack of -g as common cause
Package: lintian Version: 2.5.55 Severity: minor Tags: patch Mention the most (?) common cause of debug-file-with-no-debug-symbols: diff --git a/checks/binaries.desc b/checks/binaries.desc index 73f789a59..708ad263a 100644 --- a/checks/binaries.desc +++ b/checks/binaries.desc @@ -424,6 +424,8 @@ Ref: #668437 Info: The binary is installed as a detached "debug symbols" ELF file, but it does not appear to have debug information associated with it. . + A common cause is not passing -g to GCC when compiling. + . Implementation detail: Lintian checks for the ".debug_line" and the ".debug_str" sections. If either of these are present, the binary is assumed to contain debug information.
Bug#877147: closed by Chris Lamb <la...@debian.org> (Bug#877147: fixed in lintian 2.5.54)
Control: reopen -1 On Fri, Sep 29, 2017 at 06:09:09PM +, Debian Bug Tracking System wrote: >... >* t/tests/binaries-from-other-arch/debian/debian/dumpobj: > + [CL] Apply patch from Jakub Wilk to prevent test failures on >armhf/arm64, etc. (Closes: #877147) >... Now tests::binaries-from-other-arch is even listed twice as failed on arm64/armhf: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/lintian.html Failed tests (2) tests::binaries-from-other-arch tests::binaries-from-other-arch > Date: Fri, 29 Sep 2017 10:45:04 +0300 > From: Adrian Bunk <b...@debian.org> > To: Debian Bug Tracking System <sub...@bugs.debian.org> > Subject: lintian: test failures on i386/arm64/armhf > > Package: lintian > Version: 2.5.52 > Severity: serious > > Some change in unstable between 2017-08-26 and 2017-09-13 > makes tests fail on i386/arm64/armhf (but not amd64): > > https://tests.reproducible-builds.org/debian/history/lintian.html > > > The failing tests are: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/lintian.html > > Failed tests (1) > tests::binaries-missing-lfs > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/lintian.html > > Failed tests (1) > tests::binaries-from-other-arch > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/lintian.html > > Failed tests (2) > tests::binaries-from-other-arch > tests::binaries-missing-lfs cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#877147: lintian: test failures on i386/arm64/armhf
Package: lintian Version: 2.5.52 Severity: serious Some change in unstable between 2017-08-26 and 2017-09-13 makes tests fail on i386/arm64/armhf (but not amd64): https://tests.reproducible-builds.org/debian/history/lintian.html The failing tests are: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/lintian.html Failed tests (1) tests::binaries-missing-lfs https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/lintian.html Failed tests (1) tests::binaries-from-other-arch https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/lintian.html Failed tests (2) tests::binaries-from-other-arch tests::binaries-missing-lfs
Bug#873490: latest-debian-changelog-entry-without-new-date should become an error
Package: lintian Version: 2.5.52 Severity: normal See #873489 - only a warning for something suggested for autoreject sounds wrong.
Bug#870199: lintian: file-contains-fixme-placeholder is "Certainty: certain" but has false positives
Package: lintian Version: 2.5.52 Severity: normal E: geany-plugins source: file-contains-fixme-placeholder debian/control:119 FIXME N: N:This file appears to be incomplete or insufficiently modified as it N:contains a "FIXME" placeholder text. These can often be generated by N:package generation tools such as dh_make or npm2deb. N: N:Please double-check the file and replace the placeholder with the N:required command or information. N: N:Severity: important, Certainty: certain N: N:Check: cruft, Type: source N: That's a false positive: Package: geany-plugin-addons Source: geany-plugins ... Description-en: miscellaneous plugins for Geany This plugin adds various small addons to Geany which aren't worth an individual plugin, but might still be useful for people. * DocList: This addon places a new item in the toolbar and when clicked offers a menu listing all open files plus the 'Close All' and 'Close Other Documents' menu items. This can be useful to quickly access open files and switch to them. * OpenURI: Adds 'Open URI' and 'Copy URI' menu items to the editor menu when the word under the cursor looks like a URI. 'Open URI' uses the browser command configured in Geany to open it. * Tasks: The tasks plugin goes through a file being edited and picks out lines with "TODO" or "FIXME" in them. It collects the text after those words and puts them in a new "Tasks" tab in the message window. Clicking on a task in that tab takes you to the line in the file where the task was defined. * Systray: Adds a status icon to the notification area (systray) and provides a simple popup menu with some basic actions. It can also be used to quickly show and hide the Geany main window. . Geany is a small and lightweight integrated development environment using the Gtk+ toolkit.
Bug#868462: lintian: obsolete-url-in-packaging doesn't check the Homepage: field
Package: lintian Version: 2.5.51 Severity: normal obsolete-url-in-packaging doesn't check the Homepage: field, which is actually the most user-visible location for such URLs. Example: https://tracker.debian.org/pkg/autokey Homepage: http://code.google.com/p/autokey/ obsolete-url-in-packaging debian/control http://code.google.com/p/autokey/ debian/copyright http://autokey.googlecode.com/ debian/watch http://code.google.com/p/autokey/downloads/list?can=1
Re: Bug#866405: libindicate: FTBFS: recipe for target 'binary-install/libindicate-doc' failed
Control: reassign -1 debhelper 10.5.1 Control: affects -1 src:libindicate Works with debhelper 10.2.5, FTBFS with debhelper 10.5.1 and 10.6 On Thu, Jun 29, 2017 at 08:37:52AM -0700, Daniel Schepler wrote: > Source: libindicate > Version: 0.6.92-4 > Severity: serious > > >From my pbuilder build log: > > ... > dh_lintian -plibindicate-doc > dh_bugfiles -plibindicate-doc > dh_install -plibindicate-doc > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/base.html' > with './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/base.html' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/home.png' > with './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/home.png' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/index.html' > with './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/index.html' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/IndicateIndicator.html' > with > './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/IndicateIndicator.html' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/IndicateListener.html' > with > './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/IndicateListener.html' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/IndicateServer.html' > with > './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/IndicateServer.html' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/ix01.html' > with './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/ix01.html' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/left-insensitive.png' > with > './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/left-insensitive.png' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/left.png' > with './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/left.png' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/libindicate.devhelp2' > with > './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/libindicate.devhelp2' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/listeners.html' > with './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/listeners.html' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/right-insensitive.png' > with > './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/right-insensitive.png' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/right.png' > with './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/right.png' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/style.css' > with './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/style.css' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/up-insensitive.png' > with './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/up-insensitive.png' > cp: will not overwrite just-created > 'debian/libindicate-doc//usr/share/gtk-doc/html/libindicate/up.png' > with './debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/up.png' > dh_install: cp --reflink=auto -a > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/base.html > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/home.png > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/index.html ./d > ebian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/IndicateIndicator.html > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/IndicateListener.html > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/IndicateServer.html > ./de > bian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/ix01.html > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/left-insensitive.png > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/left.png > ./debian/tmp/gtk2/usr/share/gt > k-doc/html/libindicate/libindicate.devhelp2 > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/listeners.html > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/right-insensitive.png > ./debian/tmp/gtk2/usr/share/gtk-doc/ht > ml/libindicate/right.png > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/style.css > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/up-insensitive.png > ./debian/tmp/gtk2/usr/share/gtk-doc/html/libindicate/up.png ./deb > ian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/base.html > ./debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/home.png > ./debian/tmp/gtk3/usr/share/gtk-doc/html/libindicate/index.html > ./debian/tmp/gtk3/usr/share/gtk-doc/html/ > libindicate/IndicateIndicator.html >
Bug#856312: lintian.debian.org should also check -dbgsym packages
Package: lintian Version: 2.5.50.1 Severity: normal lintian.debian.org should also check -dbgsym packages. Example: https://lintian.debian.org/maintainer/packa...@qa.debian.org.html#vbrfix This misses: W: vbrfix-dbgsym: debug-file-with-no-debug-symbols usr/lib/debug/.build-id/76/438ccdc4d5078085e273992db0049ba600d48b.debug
Bug#856155: Turn hardening-no-pie into a warning and improve the description
Package: lintian Version: 2.5.50.1 Severity: normal Tags: patch The attached patch turns hardening-no-pie into a warning and improves the description. This should help to reduce the number of cases where PIE is accidentally disabled (most notably hardening=+all,-pie). >From b2f0146901669b7b2e3e911a4805213a1ae26174 Mon Sep 17 00:00:00 2001 From: Adrian Bunk <b...@debian.org> Date: Sat, 25 Feb 2017 19:31:28 +0200 Subject: Turn hardening-no-pie into a warning and improve the description --- checks/binaries.desc | 23 +++ 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/checks/binaries.desc b/checks/binaries.desc index c3f9d8563..8a43d1891 100644 --- a/checks/binaries.desc +++ b/checks/binaries.desc @@ -394,34 +394,25 @@ Info: This package provides an ELF binary that lacks the "bindnow" Ref: https://wiki.debian.org/Hardening Tag: hardening-no-pie -Severity: wishlist +Severity: normal Certainty: certain Info: This package provides an ELF executable that was not compiled as a position independent executable (PIE). . - In Debian, gcc-6 as of version 6.2.0-9 will compile ELF binaries with - PIE by default. In most cases a simple rebuild will be sufficient to - remove this tag. + In Debian, since version 6.2.0-7 of the gcc-6 package GCC will + compile ELF binaries with PIE by default. In most cases a simple + rebuild will be sufficient to remove this tag. . PIE is required for fully enabling Address Space Layout Randomization (ASLR), which makes "Return-oriented" attacks more difficult. . Historically, PIE has been associated with noticeable performance - overhead on i386. However, GCC-5 has implemented an optimization + overhead on i386. However, GCC >= 5 has implemented an optimization that can reduce the overhead significantly. . - If you use dpkg-buildflags, you may have to add - hardening=+pie or hardening=+all to - DEB_BUILD_MAINT_OPTIONS. - . - The relevant compiler flags must be passed both to the compiler - and the linker (e.g. for C that would be commonly be - CFLAGS and LDFLAGS). - . - If your upstream build compiles either of the above, you may have to - patch the build to ensure that only ELF executables are compiled with - PIE. + If you use dpkg-buildflags with hardening=+all,-pie + in DEB_BUILD_MAINT_OPTIONS, remove the -pie. Ref: https://wiki.debian.org/Hardening, https://gcc.gnu.org/gcc-5/changes.html, https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode -- 2.11.0
Bug#753165: lintian needs Provides: funny-manpages ( 1.3-5.1)
Package: lintian Version: 2.5.24 Severity: serious -- snip -- Unpacking lintian (2.5.24) over (2.5.21) ... dpkg: error processing archive /var/cache/apt/archives/lintian_2.5.24_all.deb (--unpack): trying to overwrite '/usr/share/lintian/overrides/lintian', which is also in package funny-manpages 1.3-5 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) -- snip -- This was a bug in funny-manpages, but lintian has to add a Provides: funny-manpages ( 1.3-5.1) to avoid users running into it when upgrading lintian. -- 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/20140629172001.25881.62972.reportbug@localhost
Bug#753165: Ups, Replaces: not Provides:
retitle 753165 lintian needs Replaces: funny-manpages ( 1.3-5.1) thanks brownpaperbag It is of course Replaces: not Provides: /brownpaperbag cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140629174055.gj29...@bunk.dyndns.info
Bug#276822: lintian: please make usr-doc-symlink-without-dependency strict again
Package: lintian Version: 1.23.3 Severity: normal Quoting a mail I wrote in #249414: Besides the copyright file, there's a similar problem with the changelog file (which obviously implies the current check for exactly the same version is correct): The first paragraph of section 12.7. of your policy is: -- snip -- Packages that are not Debian-native must contain a compressed copy of the `debian/changelog' file from the Debian source tree in `/usr/share/doc/package' with the name `changelog.Debian.gz'. -- snip -- I'd read this section of your policy that /usr/share/doc/package/changelog.Debian.gz must always point to a compressed copy of the `debian/changelog' file from the Debian source tree package was built from. Since this is a must, a violation through a dependency that is not on exactly the same version of the package containing the actual file seems to be a RC bug.
Bug#264218: lintian: init.d-script-not-{marked-as-conffile, included-in-package} false positives
Package: lintian Version: 1.23.2 Severity: normal W: aolserver4: init.d-script-not-marked-as-conffile /etc/init.d/$PACKAGE E: aolserver4: init.d-script-not-included-in-package /etc/init.d/$PACKAGE The postinst of aolserver4 contains: -- snip -- ... PACKAGE=aolserver4 ... INIT=/etc/init.d/$PACKAGE ... $INIT start ... -- snip --
Bug#263377: Already reported, and lintian is correct
merge 249414 263377 thanks Hi Joey, first of all, this issue was already discussed to dead in #249414. My opinion why lintian is correct: The first paragraph of section 12.7. of your policy is: -- snip -- Packages that are not Debian-native must contain a compressed copy of the `debian/changelog' file from the Debian source tree in `/usr/share/doc/package' with the name `changelog.Debian.gz'. -- snip -- I'd read this section of your policy that /usr/share/doc/package/changelog.Debian.gz must always point to a compressed copy of the `debian/changelog' file from the Debian source tree package was built from. Since this is a must, a violation through a dependency that is not on exactly the same version of the package containing the actual file seems to be a RC bug. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Bug#249414: lintian: Fails to detect usr-doc-symlink
On Wed, Jun 30, 2004 at 01:52:07AM +0100, Colin Watson wrote: On Tue, Jun 29, 2004 at 11:24:45PM +0200, Adrian Bunk wrote: The first paragraph of section 12.7. of your policy is: -- snip -- Packages that are not Debian-native must contain a compressed copy of the `debian/changelog' file from the Debian source tree in `/usr/share/doc/package' with the name `changelog.Debian.gz'. -- snip -- I'd read this section of your policy that /usr/share/doc/package/changelog.Debian.gz must always point to a compressed copy of the `debian/changelog' file from the Debian source tree package was built from. Since this is a must, a violation through a dependency that is not on exactly the same version of the package containing the actual file seems to be a RC bug. It's not in http://release.debian.org/sarge_rc_policy.txt, and therefore not release-critical. According to section 1.1. of your policy, a violation of a must in your policy is a serious bug. AFAIK the word of your RM is not worth more than the text written in your policy (or one word of your RM would be worth more than the whole policy process; in this case your RM should become the official maintainer of your policy). Clearly your RM can say that some RC bugs are ignored for the next release because fixing them would not be easily possible and they would be tagged sarge-ignore (which would be silly for easy bugs as the ones this discussion is about). Cheers, cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Bug#249414: lintian: Fails to detect usr-doc-symlink
On Tue, Jun 29, 2004 at 08:31:56PM +0200, Jeroen van Wolffelaar wrote: On Tue, Jun 01, 2004 at 04:40:08PM +0200, Jeroen van Wolffelaar wrote: On Mon, May 31, 2004 at 11:55:21PM +0200, Rafael Laboissiere wrote: * Marc 'HE' Brockschmidt [EMAIL PROTECTED] [2004-05-31 14:32]: No problem. /usr/share/doc/$pkg/copyright is the reason. As the copyright notice is one of the most important files in a package (at least seen from a legal pov) we have to ensure that it is always right. This is only possible if both packages come from the same source package and the same source version. We still have a little problem in those cases where the version of a binary package differs from the version of another binary package linking its /usr/share/doc/dir to it. The goal of detecting incoherences in the copyright files is very noble, but Hm, we trust to the maintainers to get this kind of dependencies right in most cases... That is, a depends on the latest significantly (that is, incompatible) changed version, and conflict on the latest incompatible package. copyright files don't change that often, is it really needed to demand a strict depends? Based also on the referred d-d thread, I'm tending to revert the extra check introduced at the request of #201470 Once lintian supports proper cross-package checking, this test can be made perfect, by simply checking whether the copyright file is indeed identical. Besides the copyright file, there's a similar problem with the changelog file (which obviously implies the current check for exactly the same version is correct): The first paragraph of section 12.7. of your policy is: -- snip -- Packages that are not Debian-native must contain a compressed copy of the `debian/changelog' file from the Debian source tree in `/usr/share/doc/package' with the name `changelog.Debian.gz'. -- snip -- I'd read this section of your policy that /usr/share/doc/package/changelog.Debian.gz must always point to a compressed copy of the `debian/changelog' file from the Debian source tree package was built from. Since this is a must, a violation through a dependency that is not on exactly the same version of the package containing the actual file seems to be a RC bug. --Jeroen cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
