Package: lintian
Version: 2.116.3
Severity: important
Tags: sid trixie
seen at https://udd.debian.org/lintian/?packages=gcc-13
lintian should not complain about /usr/libo32, it's also not complaining about
files in /usr/lib32, /usr/libx32 and /usr/lib64.
there maybe a follow-up check leading
control: tags -1 -moreinfo
On 25.02.23 15:14, Bastien Roucariès wrote:
control: tags -1 +moreinfo
Le vendredi 24 février 2023, 11:28:18 UTC Matthias Klose a écrit :
Package: lintian
Version: 2.116.3
Severity: serious
Tags: sid bookworm
seen with the binary packages from
https
Package: lintian
Version: 2.116.3
Severity: serious
Tags: sid bookworm
seen with the binary packages from
https://people.debian.org/~doko/tmp/
$ lintian -F python3.12_3.12.0~a5-1_amd64.changes
E: libpython3.12: embedded-library expat
[usr/lib/x86_64-linux-gnu/libpython3.12.so.1.0]
E:
Control: severity -1 wishlist
This is the wrong way to go, please don't implement that without further
discussion. The bug submitter didn't even look for that, but deliberately
cloned #1029641 several times for his amusement.
Package: lintian
Please show an error on static archives without any code sections. This happens
when a package ships a lib.a which is built with -flto=auto, but without
-ffat-lto-objects. dh_strip already takes care of stripping the lto sections,
but maybe is leaving the .a file unusable.
see
Package: src:lintian
Please error on pkgconfig files referencing runtime libraries without the
package having a dependency on the runtime package. This was seen in
#977282
#977283
during the boost 1.71 -> 1.74 transition. These packages don't show up on the
transition tracker, because they
Package: lintian
Version: 2.104.0
should be handled the same way as for python3-packaging
pypy-packaging_20.4-1_all.deb
I package-contains-documentation-outside-usr-share-doc
usr/lib/pypy/dist-packages/packaging-20.4.egg-info/dependency_links.txt
I
On 11/12/20 8:54 PM, Felix Lechner wrote:
> Control: retitle -1 lintian: Exempt gcc-10 and friends from breakout-link
>
> Hi Matthias,
>
>> It might be a good thing to check a new lintian release against some fixed
>> set
>> of packages, maybe including gcc-10 and gcc-10-cross.
>
> We are
Package: lintian
gcc-N binary packages trigger some dozen warnings of the form:
W: libgcc-11-dev: breakout-link usr/lib/gcc/x86_64-linux-gnu/11/libgomp.so ->
usr/lib/x86_64-linux-gnu/libgomp.so.1
These are wrong.
It might be a good thing to check a new lintian release against some fixed set
of
Package: lintian
please add a lintian error for packages dep/rec one of the python-is-* packages.
The what-is-python source package builds four packages
python-is-python2
python-dev-is-python2
python-is-python3
python-dev-is-python3
which should not be used as a build dependency,
Package: lintian
Version: 2.84.0
lintian errors on a missing shlibs file even if a symbols file is present.
Afaics there is no requirement in debian policy to ship both, always talking
about shlibs *or* symbols files. Seen in binutils (libbfd0, libbfd-nobfd0),
which is not using debhelper
Package: src:lintian
Version: 2.83.0
Severity: serious
Tags: sid bullseye
lintian fails autopkg tests on all archs except for amd64, the architecture
seems to be hard-coded.
# Literal output does not match
#
# --- ../../autopkgtest_tmp/testsuite/eval/lintian-features/html-output/literal
# +++
On 3/25/20 3:11 PM, Felix Lechner wrote:
> Hi,
>
> On Sat, Mar 21, 2020 at 4:51 AM Matthias Klose wrote:
>>
>> I don't know when that was introduced, but you see some hundred of those in
>> the
>> gcc-N packages:
>
> The tag was introduced when the so
Package: lintian
I don't know when that was introduced, but you see some hundred of those in the
gcc-N packages:
E: libx32gcc-9-dev:
ESC]8;;https://lintian.debian.org/tags/binary-is-wrong-architecture.htmlESC\binary-is-wrong-architectureESC]8;;ESC\
usr/lib/gcc/x86_64-linux-gnu/9/x32/crtend.o
So
On 3/20/20 2:15 PM, Felix Lechner wrote:
> Hi Matthias,
>
> On Fri, Mar 20, 2020 at 5:57 AM Matthias Klose wrote:
>>
>> so please differentiate between Fortran and Modula-2 modules.
>
> I have had some issues differentiating gfortran modules (#948033). In
> which
Package: lintian
running lintian on a gcc-10 build, I see
gzip: stdout: Broken pipe
gzip:
/tmp/temp-lintian-lab-i1Mvu3Lp4j/pool/g/gcc-10/libgm2-10-dev_10-20200320-1_amd64_binary/unpacked/usr/lib/gcc/x86_64-linux-gnu/10/m2/m2cor/Debug.mod:
not in gzip format
and then continues with:
Package: lintian
Severity: wishlist
seen at #950027, a packaging issue. I think it would be trivial to warn about
installations into /, however I didn't check about any false
positives.
Package: lintian
Issue #943366 asks to split out the request to emit an error for python shebangs
used in a package into a separate bug report.
This should include usage of python in autopkg tests, and maybe rules files, if
it's detectable.
#943666 has the discussion about changing the
On 24.10.19 13:17, Chris Lamb wrote:
severity 943366 wishlist
thanks
Matthias Klose wrote:
Please could lintian generate errors messages for any (build)
dependency or autopkg test dependency on python/python-dev. Maybe
even look for python shebangs in binary packages and sources
Package: lintian
bullseye will ship without the unversioned python binary and packages, details
at https://lists.debian.org/debian-python/2019/10/msg00082.html. While we aim
for removing Python2 entirely, this is probably too ambitious, and we should at
least remove the unversioned python
On 21.10.19 18:57, Chris Lamb wrote:
Matthias Klose wrote:
Thanks for the link. I don't immediately see how Lintian can
statically check for this lack of "looping" though. Can you help?
My idea would be to look at the .buildinfo file, seeing python3-all-dev, and
then pyt
On 20.10.19 23:17, Chris Lamb wrote:
Hi Matthias,
Can you clarify what you mean here regarding "not building for all
supported Python versions"? I'm looking at src:jsonnet and do not
immediately see what is wrong.
see
On 20.10.19 18:57, Chris Lamb wrote:
severity 942673 wishlist
thanks
Matthias Klose wrote:
please warn about b-d on python3-all-dev and package not building for all
supported python versions.
Can you clarify what you mean here regarding "not building for all
supported Python versions&
Package: lintian
please warn about b-d on python3-all-dev and package not building for all
supported python versions. Not sure if that's implementable, because you can
only warn about that when there are currently multiple supported python3
versions (like in python3-defaults in
Please can we also have now an error if any unversioned depdency is used (except
for the -all-) ones, or if python is used as the shebang?
Matthias
On 16.10.19 22:08, Niels Thykier wrote:
Control: tags -1 moreinfo
Matthias Klose:
Control: tags -1 - moreinfo
On 29.09.19 11:03, Niels Thykier wrote:
Control: tags -1 moreinfo
[...]
When would you need to keep these LTO sections (but not use -k to keep
everything)?
-k is aliased
Control: tags -1 - moreinfo
On 29.09.19 11:03, Niels Thykier wrote:
Control: tags -1 moreinfo
Matthias Klose:
Package: debhelper,lintian
Severity: important
Some packages build with link time optimizations enabled, which is ok,
whoever then these packages may ship with static libs which
Control: tags -1 + patch
Control: tags -1 - moreinfo
Please find attached a patch stripping the LTO information, together with an
option to explicitly keep it.
lintian probably only needs to warn about the sections found in static archives.
* dh_strip: Strip LTO sections unless --keep-lto
On 08.09.19 09:53, Chris Lamb wrote:
tags 939656 + moreinfo
thanks
Matthias Klose wrote:
Please feel free to split this issue into separate debhelper and lintian tasks
once a solution is agree upon.
Sure thing. As I am not well-versed enough in this lower-level stuff (!)
am marking
Package: debhelper,lintian
Severity: important
Some packages build with link time optimizations enabled, which is ok, whoever
then these packages may ship with static libs which still have the LTO
information in some sections of the object files (e.g. ext2fsprogs). This is
not desired in
Package: src:lintian
Version: 2.19.0
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal
Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
On 21.08.19 01:16, Chris Lamb wrote:
> tags 934853 + moreinfo
> thanks
>
> Hi Matthias,
>
>> please add an lintian warning/error for packages (b-)depending on python or
>> using the unversioned python shebang.
>
> Do we not have these already? eg. dependency-on-python-version-marked-
>
Package: lintian,dh-python
please add an lintian warning/error for packages (b-)depending on python or
using the unversioned python shebang.
Not sure if this should be one or two different lintian warnings or errors. We
definitely want to drop the python/python-dev binary packages, and not
Package: debhelper,lintian
Severity: wishlist
dwz currently doesn't handle compressed debug sections. In the first place, why
should we have these, because or dbg packages are compressed anyway. otoh, these
are enabled by some upstreams like ruby.
So what dh_dwz could do, is
- look for
Package: lintian
Seen when trying to remove Python2 dependencies. A lot of -doc packages
recommend/suggest the Python2 package, not the Python3 one.
Additionally, I'm not sure if a recommends is really appropriate.
Package: lintian
Version: 2.13.0
Severity: important
Python 3.8 alpha4 dropped the `m' modifier, so /usr/include/python3.8 is not the
correct include dir. Please reflect that change in lintian.
On 21.01.19 16:37, 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
On 15.01.19 00:48, Chris Lamb wrote:
> Adrian Bunk wrote:
>
>>> 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
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,
On 08.06.2018 20:25, Chris Lamb wrote:
Matthias,
Just to be clear, won't this cause 1000s of warnings due to most
packages depending on "python" and not "python2"?
I certainly don't want to have these warnings, at least not until dh-python
starts generating dependencies on python2. So I
On 08.06.2018 20:12, Chris Lamb wrote:
Matthias,
Please update the warning, python2 is now found in the python2/python2-minimal
packages.
Just to be clear, won't this cause 1000s of warnings due to most
packages depending on "python" and not "python2"?
I certainly don't want to have these
Package: lintian
python2-minimal 2.7.15-3 (binary)
python2 => python:any | python-minimal:any (usr/bin/pyclean) #!/usr/bin/python2
python2 => python:any | python-minimal:any (usr/bin/pycompile)
#!/usr/bin/python2
python2 => python:any | python-minimal:any (usr/share/python/pyversions.py)
Package: lintian
openjdk-11-dbg
W shared-lib-without-dependency-information
usr/lib/jvm/java-11-openjdk-amd64/lib/jexec.debuginfo
usr/lib/jvm/java-11-openjdk-amd64/lib/jli/libjli.debuginfo
These warnings should not happen.
Package: lintian
Version: 2.5.86
Severity: important
Tags: sid buster
This causes the gcc-8-cross packages built on amd64 and i386 failing the lintian
-F check during upload (packages at p.d.o/~d.../tmp).
$ lintian -F ../gcc-8-cross_16_amd64.changes 2>&1 | tee ../log.lintian
Use of uninitialized
I disagree that it should be removed. There's no harm to add a phrase that
there might be no harm to keep the python2 package for the buster release.
Package: src:lintian
Version: 2.5.72
seen with the launchpad autopkg tests and binutils 2.30:
tests::binaries-general: diff -u t/tests/binaries-general/tags
/tmp/autopkgtest.vLMxRU/autopkgtest_tmp/testsuite/tests/binaries-general/tags.binaries-general
--- t/tests/binaries-general/tags
[CCing Piotr]
On 06.01.2018 11:43, Chris Lamb wrote:
> tags 795261 + moreinfo
> thanks
>
>
add a warning for stripped python-*-dbg packages
>
> Thanks Mattia for your comments and for filing the other bug.
>
> Matthias, can you send over the name of an example package so I can be
> sure
Package: debhelper,lintian
Severity: serious
Tags: sid buster
The last gcc-8 upload was automatically rejected with
E: libgomp-plugin-nvptx1-dbgsym: usr-share-doc-symlink-to-foreign-package
libgomp-plugin-nvptx1
E: gcc-8-offload-nvptx-dbgsym: usr-share-doc-symlink-to-foreign-package
On 22.12.2017 11:20, Chris Lamb wrote:
> Hi Matthias,
>
>> please check for mismatches in python dependencies
>
> I wonder if this suitably covered (albeit not directly) by #884676?
that might solve it, does it cover https://bugs.debian.org/884692
as well?
Matthias
Package: src:lintian
Version: 2.5.63
Severity: important
Tags: sid buster
the files-multiarch-foreign-files test hardcodes the multiarch in the test:
tests::files-multiarch-foreign-files: diff -u
t/tests/files-multiarch-foreign-files/tags
ahh, and that's an error flagged as auto-reject :-/
Package: lintian
Version: 2.5.62
Severity: important
python-examples
E usr-share-doc-symlink-without-dependency
python
$ dpkg -I ../python-examples_2.7.14-3_all.deb |grep Depends
Depends: python:any (>= 2.7.14-3), python2.7-examples (>= 2.7.14-1~)
Package: src:lintian
Please raise the priority of these flags to W (warning). While these are tags
not targeted for the buster release, there are a lot of affected packages, and
these should show up on tracker.debian.org to get more visibility.
Package: lintian
Version: 2.5.60
As seen with the dput-ng binary, the
dependency-on-python-version-marked-for-end-of-life doesn't match the python:any
dependency.
Package: lintian
Version: 2.5.57
$ lintian -F ../gcc-8-cross_1_amd64.changes 2>&1 | tee ../log.lintian
Use of uninitialized value $val in split at
/usr/share/perl5/Lintian/Collect/Binary.pm line 423, <$_[...]> line 20151.
internal error: shlib usr/lib/gcc-cross/mips-linux-gnu/8/libgo.a(bzip2.o)
Package: src:lintian
Version: 2.5.53
it looks like one lintian autopkg test fails on 32bit archs (at least armhf and
i386):
tests::binaries-missing-lfs: diff -u t/tests/binaries-missing-lfs/tags
Package: lintian
Version: 2.5.49
PT_GNU_STACK change triggers ~500 new errors for the cross-toolchain-base and
cross-toolchain-base ports packages. lintian oversimplifies this check a bit
...
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=4c722ae90d4c09542ee33aa549745879ea11465c
Package: lintian
Version: 2.5.49
Severity: important
Tags: sid stretch
according to
https://lintian.debian.org/maintainer/debian-...@lists.debian.org.html#libabigail
lintian issues some meaningless warnings:
libabigail (1.0~rc5-4) Info Package Tracker Bugs (up-to-date, last processed by
On 05.09.2016 18:52, Russ Allbery wrote:
> Matthias Klose <d...@debian.org> writes:
>
>> Package: lintian
>> Version: 2.5.46
>> Severity: important
>> Tags: sid stretch
>> User: debian-...@lists.debian.org
>> Usertags: hardening-wrapper
>
Package: lintian
Version: 2.5.46
Severity: important
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: hardening-wrapper
This package builds using the hardening-includes package, which
is now replaced by dpkg-dev's DEB_BUILD_MAINT_OPTIONS settings.
Please consider dropping the build
Please only trigger this warning if no corresponding python3 module is uploaded
(at least until after the stretch release).
Package: lintian
as seen in
https://lintian.debian.org/maintainer/debian-...@lists.debian.org.html#gcc-5
lintian complains about new dev-pkg-without-shlib-symlink issues, because it
doesn't search for these files in the correct gcc lib dir, which now has a
different path on i386* archs.
Package: lintian
please add a check that libraries are installed in /usr/lib instead of
/usr/lib/DEB_HOST_MULTIARCH.
The best solution for such issues would be to make both the dev and the library
package M-A same. If that can not be done, make just the library package M-A
same. If for
On 08/27/2015 10:23 PM, Jakub Wilk wrote:
The attached patch fixes all these bugs.
awesome!
Package: lintian
When the gfortran module version changes, at least all the library packages
providing a fortran 90 module need a rebuild. Currently people have to scan the
archive them self to identify all the packages which need a rebuild. Please
warn about about -dev packages shipping a
Package: lintian
for every python2 -dbg package, lintian warns about
arch-dependent-file-not-in-arch-specific-directory. It doesn't for the
extensions built for the standard interpreter.
E: python-pil-dbg: arch-dependent-file-not-in-arch-specific-directory
Package: lintian
sent to
https://lists.debian.org/debian-python/2015/06/msg00022.html
The packages built for the Python debug interpreters should not be stripped.
Usually this has to be done on a per package basis, however when converting to
the pybuild system, this is easily missed. It is now
Package: lintian
lintian currently warns for every runtime library built by the GCC sources about
the missing symlink, because GCC ships the .so symlink together with the static
and internal libraries in /usr/lib/gcc/triplet/version. Instead of adding
50 override files for this warning, please
Package: lintian
Bash is still marked as essential while not providing the system shell anymore.
Before removing this attribute (probably not for the stretch release),
additional build dependencies and dependencies on bash need to be introduced.
- bash needed for a binary package. that usually
On 05/27/2015 03:41 PM, Jan Henke wrote:
Am 27.05.2015 um 15:04 schrieb Thorsten Glaser:
On Wed, 27 May 2015, Rene Engelhard wrote:
I know, there at least we need to kill gcj support. But until then. Or
we decide we don't care ab out 1.5/gcj now. Explicitely.
On Wed, 27 May 2015, Markus
reopen 775760
reassign 775760 openjdk-8,ftp.debian.org
thanks
On 05/18/2015 04:51 PM, Niels Thykier wrote:
close 775760
fixed 775760 lintian/2.5.31
tags 775760 - jessie
thanks
On 2015-05-18 16:39, Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
reopen
Package: lintian
Please could lintian check for mismatches in python dependencies, in that a
python module depends on python3 modules or the other way around?
Package: python3-foo
Depends: python-gi, python-gi-dev
So here it should be python3-gi, but python-gi-dev is correct, and there are
Package: lintian
please add a check that the Architecture attribute in a control file is not
multi-line.
I saw that at least twice, the last time here for #780473.
seen at
https://buildd.debian.org/status/package.php?p=kissplice
--
To UNSUBSCRIBE, email to
Package: lintian,ftp.debian.org,openjdk-8
Severity: serious
Tags: sid
openjdk-8 is rejected due to wrong a wrong (?) lintian warning, complaining
about
openjdk-8-dbg: lintian output:
'library-in-debug-or-profile-should-not-be-stripped
what is the test supposed to test? There is a test file shipped, but I can't
see yet what is being tested for. Is there a way to call objdump directly to
reproduce this issue?
Matthias
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe.
Package: lintian
This warning should not be given when the file name contains an architecture
name or the multiarch name.
https://lintian.debian.org/tags/arch-dependent-file-not-in-arch-specific-directory.html
python-renderpm-dbg
E arch-dependent-file-not-in-arch-specific-directory
Package: lintian
Version: 2.5.22.1
lintian complains about python3-stdlib-extensions's
E missing-python-build-dependency
This is wrong, python$* is always used in the pattern rules.
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe.
Am 02.04.2014 10:33, schrieb Emmanuel Bourg:
Package: lintian
Version: 2.5.22.1
Severity: normal
Hi,
Could you please support the Java 8 class version in the
unknown-java-class-version check? OpenJDK 8 is being packaged and
lintian complains about the new class version (52 for Java 8, Java 7
Package: lintian
Severity: important
lintian currently complains about this tag for every file which includes a copy
of the GFDL. The addendum reads:
ADDENDUM: How to use this License for your documents
To use this License in a document
Package: lintian
Seen now in many packages, calling
dh --with autotools-dev
instead of autotools_dev, making this a nop.
Please add a lintian check for that.
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Package: lintian
Please add a warning for this obsolete use:
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif
and suggest using dpkg-buildflags.
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject
Package: lintian
lintian should not complain about hardening-no-fortify-functions for binaries
built with -O0. fortify-source is *only* turned on for optimized builds.
examples for wrong ones are in pythonX.Y-dbg warnings.
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
Package: lintian
Severity: important
while getting python3.3 ready for multiarch, I noticed a lot of false positives:
E: libpython3.3-dev: arch-dependent-file-not-in-arch-specific-directory
usr/lib/python3.3/config-3.3m-x86_64-linux-gnu/libpython3.3m-pic.a
So maybe better check if the path
Package: lintian
openjdk-6-jre-headless
E gzip-file-is-not-multi-arch-same-safe
usr/lib/jvm/java-6-openjdk-i386/jre/man/ja_JP.eucJP/man1/java.1.gz
usr/lib/jvm/java-6-openjdk-i386/jre/man/ja_JP.eucJP/man1/keytool.1.gz
lintian should not complain, if either the architecture or the multiarch name
Package: lintian
Version: 2.5.1
Severity: important
trying to make GCC multilib/multiarch aware for armhf and armel, I see
E: libhfgcc1: triplet-dir-and-architecture-mismatch lib/arm-linux-gnueabihf/ is
for armhf
which seems to be bogus.
--
To UNSUBSCRIBE, email to
Package: lintian
Please add some support to scan build logs for a build, like
lintian changes file build log
There do exist some build log scanners for failed builds, like the one from
Lucas Nussbaum used for the grid5000 test rebuilds, but there are also some
issues which can be catched
Package: lintian
Version: 2.4.3
W: gcc-4.4-hppa64: apparently-corrupted-elf-binary
./usr/lib/gcc/hppa64-linux-gnu/4.4.5/crtbegin.o
W: gcc-4.4-hppa64: apparently-corrupted-elf-binary
./usr/lib/gcc/hppa64-linux-gnu/4.4.5/crtbeginS.o
W: gcc-4.4-hppa64: apparently-corrupted-elf-binary
Package: lintian
Version: 2.3.3
lintian complains about:
E: gcc-defaults source: missing-separator-between-items in gcc depends field
between 'gcc-${pv:gcc}' and '${reqv:gcc}'
Package: gcc
Depends: cpp (= ${version:cpp}), gcc-${pv:gcc} ${reqv:gcc}, ${misc:Depends}
imo, this is too strict.
Package: lintian
Version: 2.2.18
W: gfortran-4.5: manpage-has-errors-from-man
usr/share/man/man1/gfortran-4.5.1.gz Invalid o
r incomplete multibyte or wide character
W: gcc-4.5: manpage-has-errors-from-man usr/share/man/man1/gcc-4.5.1.gz Invalid
or incomple
te multibyte or wide character
Package: lintian
Version: 2.2.18
why complain about hppa64, when there are no warnings or errors on other
biarchs?
W: gcc-4.5-hppa64: apparently-corrupted-elf-binary
./usr/lib/gcc/hppa64-linux-gnu/4.5.0/crtbeginS.o
W: gcc-4.5-hppa64: apparently-corrupted-elf-binary
Package: ftp.debian.org,lintian
Severity: serious
Reject Reasons:
openjdk-6-jre: Overriden tag no-copyright-file found, but this tag may not be
overridden.
/usr/share/doc/openjdk-6-jre-headless is a symlink to openjdk-6-jre, which are
both in openjdk-6-jre-headless. openjdk-6-jre depends on
On 10.11.2009 14:56, Adam D. Barratt wrote:
Matthias Klose wrote:
Package: ftp.debian.org,lintian
Severity: serious
Reject Reasons:
openjdk-6-jre: Overriden tag no-copyright-file found, but this tag
may not be overridden.
/usr/share/doc/openjdk-6-jre-headless is a symlink to openjdk-6-jre
Package: lintian
Severity: wishlist
seen while looking at the ironruby package (to be uploaded)
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Russ Allbery schrieb:
Matthias Klose d...@cs.tu-berlin.de writes:
gcc checks at build time all system headers (in /usr/include) and
fixes those headers which are not ANSI compliant. Because of
conflicting -dev packages, not all headers can be checked at gcc's
build time, so that could
Russ Allbery schrieb:
Matthias Klose d...@debian.org writes:
well, more headers are fixed, but I don't include these in the gcc
package. I still think to find out how many headers are affected, we
have to run the test at least once. Not sure how many many header files
will be found.
Okay
Package: lintian
Version: 1.24.1
Severity: important
As seen on
http://lintian.debian.org/maintainer/[EMAIL PROTECTED]
lintian emits bogus errors and warnings:
lib64stdc++6-4.2-dbg
* W apparently-corrupted-elf-binary
o ./usr/lib64/debug/libstdc++.so.6.0.9
* W
Package: lintian
E: gcc-4.1-source: shell-script-fails-syntax-check
./usr/src/gcc-4.1/patches/ppc64-ada.dpatch
E: gcc-4.1-source: shell-script-fails-syntax-check
./usr/src/gcc-4.1/patches/gccbug.dpatch
not sure, if I should mark them with an overrides file or if that
could be fixed in lintian
Package: lintian
Version: 1.23.16
please add python2.5 to the list of known interpreters
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reopen 328612
thanks
$ lintian lib64gcc1_4.0.2-2_i386.deb
E: lib64gcc1: non-standard-toplevel-dir lib64/
W: lib64gcc1: file-in-unusual-dir lib64/libgcc_s.so.1
W: lib64gcc1: postinst-has-useless-call-to-ldconfig
W: lib64gcc1: postrm-has-useless-call-to-ldconfig
--
To UNSUBSCRIBE, email to
Package: lintian
Version: 1.23.12
$ lintian libgcj6-dbg_4.0.1-7_i386.deb
internal error: collect info objdump-info about package libgcj6-dbg: 256
N: Skipping check of binary package libgcj6-dbg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
1 - 100 of 106 matches
Mail list logo
