Source: lintian
Version: 2.117.0
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
This is most likely caused by a change
Package: lintian
Version: 2.117.0
Severity: normal
X-Debbugs-Cc: lu...@debian.org
Example:
vagrant@testing:~$ lintian pytorch-audio_0.13.1-1.dsc
Warning in processable pytorch-audio_0.13.1-1.dsc: Tried to issue duplicate
hint in check testsuite: drop-python-version-declaration
Package: lintian
Version: 2.117.0
Severity: normal
X-Debbugs-Cc: lu...@debian.org
Hi,
lintian outputs some warnings on some packages. Example with fq:
vagrant@testing:~$ lintian fq_0.9.0-2.dsc
fq_0.9.0-2.dsc (patched): Warning while running readelf
onformat/elf/testdata/regression/bigstrtab:
Package: lintian
Version: 2.117.0
Severity: normal
X-Debbugs-Cc: lu...@debian.org
$ lintian ruby-rspec_3.13.0c0e0m0s1-2.dsc
Warning in processable ruby-rspec_3.13.0c0e0m0s1-2.dsc: Can't locate object
method "unpack_errors" via package "Lintian::Index" at
Hi,
On 17/11/23 at 15:11 +0800, Otto Kekäläinen wrote:
> Hi!
>
> On Wed, 27 Sept 2023 at 13:27, Lucas Nussbaum wrote:
> >
> > Hi,
> >
> > #1042428 is the bug for "no explanation for lintian tags on UDD"
> >
> > On 26/09/23 at 21:35 -070
On 26/09/23 at 21:35 -0700, Otto Kekäläinen wrote:
> Hi!
>
> Thanks for the context - so there is no need technical incompatibility
> at play, but mostly a matter of having resources and time to do it.
I think it's worth adding that the new implementation (as part of UDD)
is less ambitious on
Hi,
#1042428 is the bug for "no explanation for lintian tags on UDD"
On 26/09/23 at 21:35 -0700, Otto Kekäläinen wrote:
> I know Lintian tag info is available via command line, but I
> frequently need to educate upstreams about Lintian rules, and thus
> really also need a URL to share to them.
On 24/09/23 at 12:16 -0700, Otto Kekäläinen wrote:
> > I don't know if it is just me, but even udd gives me a 500
> > when I try to check lintian output for any (existing) package.
> >
> > For example: https://udd.debian.org/lintian/?packages=nim
>
> I also just get error 500 when trying to look
Hi,
On 27/02/23 at 10:24 -0500, Scott Kitterman wrote:
> Package: lintian
> Version: 2.116.3+reprocess
> Severity: normal
>
> The UDD lintian report currently lists this warning as being applicable
> to dkimpy-milter [1], but the watch file does verify the download. I
> downloaded a new version
(Adding lintian-ma...@debian.org to Cc for input)
On 16/02/23 at 11:18 +0800, Paul Wise wrote:
> On Thu, 2023-02-16 at 01:17 +0100, Guillem Jover wrote:
>
> > it would need to get the list of binary packages for a source and
> > lint all of them with the same lintian call.
>
> The usual way of
Package: lintian
Version: 2.115.3
Severity: important
Hi,
I noticed that lintian fails when checking that package.
root@ip-10-84-234-37:/tmp# lintian libvcflib_1.0.7+dfsg-2.dsc
running with root privileges is not recommended!
Warning in processable libvcflib_1.0.7+dfsg-2.dsc: YAML::XS::Load
Package: lintian
Version: 2.115.3
Severity: normal
Hi,
dh_ruby (the ruby packaging helper) defines a ruby:Depends substition
variable based on the content of the package's gemspec file.
dpkg-gencontrol issues a warning when it is not used in debian/control:
dpkg-gencontrol: warning: package
Hi,
As there has been discussions about removing tags that are no longer
emitted, I wanted to point that it might make sense to keep those tags
for at least three use cases:
1) to check old source packages that were removed from Debian,
before they are reintroduced in Debian
2) to check
Package: lintian
Version: 2.115.3
Severity: normal
Hi,
To check unidic-mecab_2.3.0+dfsg-6.dsc, lintian requires a lot of memory
(at least around 30 GB). This makes it hard to check using the
UDD archive-wide runner, as it runs for over one day (probably due to
swapping).
There might be
Package: lintian
Version: 2.115.3
Severity: important
Hi,
lintian fails on latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb
which can be downloaded at
http://ftp.debian.org/debian/pool/main/l/latex-cjk-chinese-arphic/latex-cjk-chinese-arphic-gbsn00lp_1.24_all.deb
$ lintian
Hi Holger,
On 22/08/22 at 11:34 +, Holger Levsen wrote:
> hi,
>
> first: it's great that lintian is under active development again!
> second: it's great that UDD now has up2date information from current lintian
> runs!
>
> (I've bcc:ed abe@d.o and lucas@d.o out of courtesy, so they see
Hi,
On 01/07/22 at 16:59 +0200, Christoph Berg wrote:
> Package: lintian
> Version: 2.115.2
> Severity: normal
>
> Hi,
>
> Lintian is currently failing in salsa-ci on postgresql-15:
>
> https://salsa.debian.org/postgresql/postgresql/-/jobs/2941498
>
> lintian --suppress-tags
Hi,
This still affects v2.115.2.
$ lintian r-cran-swagger_3.33.1-1.dsc
Warning in processable r-cran-swagger_3.33.1-1.dsc: Complex regular
subexpression recursion limit (65534) exceeded at
/usr/share/lintian/lib/Lintian/Check/Cruft.pm line 449.
Warning in processable
On 29/06/22 at 15:49 +0200, Axel Beckert wrote:
> Correct, except that it happened for quite a while (7 months at least)
> and was (and maybe still is — see below) a continuous transition. It
> is present since at least 2.114.0 from November 2021. According to the
> git history, the implementation
(Adding debian-qa@ to Cc to broaden the discussion a bit)
Hi,
On the issue of lintian.d.n/lintian.d.o/UDD/tracker.d.o, I wonder if the
separation of concerns is the right one.
I think that in Debian, we would aim for a better separation between:
A/ QA tools development, focused on getting the
On 13/04/21 at 11:49 -0700, Felix Lechner wrote:
> Hi,
>
> On Tue, Apr 13, 2021 at 11:27 AM Lucas Nussbaum wrote:
> >
> > From the UDD point of view, I would very much prefer to get a full dump
> > something I can import every few hours, than having to deal w
On 13/04/21 at 18:45 +0200, Mattia Rizzolo wrote:
> [ Adding lucas@ to CC since he is the main person behind UDD after all ]
>
> On Sun, Apr 11, 2021 at 12:45:14PM -0700, Felix Lechner wrote:
> > On Sat, May 9, 2020 at 5:33 PM Mattia Rizzolo wrote:
> > > have lintian decide on a nice
On 13/11/20 at 04:45 -0800, Felix Lechner wrote:
> Hi Lucas,
>
> On Fri, Nov 13, 2020 at 3:46 AM Lucas Nussbaum wrote:
> >
> > (In that specific case, I agree that it's probably easy enough, and I
> > can live with that... But I wonder a bit about the general policy h
On 13/11/20 at 02:57 -0800, Felix Lechner wrote:
> Hi Lucas,
>
> On Thu, Nov 12, 2020 at 11:51 PM Lucas Nussbaum wrote:
> >
> > Could you please reintroduce a classification tag that makes it possible
> > to say whether a package has a test suite?
>
Package: lintian
Version: 2.101.0
Severity: normal
Hi,
Until this change:
https://salsa.debian.org/lintian/lintian/-/commit/c81fb3dbc4425c4322c67f0f3eeb2c208e337736
it was possible to rely on 'testsuite-autopkgtest-missing' to determine
whether a package has a test suite.
That tag was marked as
Package: lintian
Version: 2.52.0~bpo10+1
Severity: wishlist
Hi,
In the context of https://trends.debian.net/, it would be interesting to
track the status of packages shipping services, to know whether
maintainers are dropping init.d scripts.
This would ideally require:
- a tag to indicate
Package: lintian
Version: 2.52.0~bpo10+1
Severity: normal
Hi,
The code for rules-requires-root-explicitly is:
# Check Rules-Requires-Root
if (defined(my $r3 = $processable->source_field('rules-requires-root'))) {
if ($r3 eq 'no') {
Package: lintian
Version: 2.15.0
Severity: normal
Hi,
$ lintian --no-cfg --color never -E -I -L "+=pedantic" -L "+=classification"
--show-overrides tea_47.0.1-1.dsc
[...]
> C: tea source: debian-build-system other
> P: tea source: package-does-not-use-debhelper-or-cdbs
[...]
While the content
Package: lintian
Version: 2.12.0~bpo9+1
Severity: normal
Hi,
While processing old packages, I noticed that lintian hangs on some of
them when dpkg-source fails to extract them.
Example, using:
http://snapshot.debian.org/archive/debian/20130509T215232Z/pool/main/u/usbredir/usbredir_0.6-2.dsc
$
Package: lintian
Version: 2.9.1~bpo9+1
Severity: wishlist
Tags: patch
Hi,
I'm working on generating historical stats about Debian packages, using
lintian to extract information from packages.
One thing I'd like to track is the VCS in use by packages, and the VCS
hosting provider. Example such
Package: lintian
Version: 2.9.1
Severity: wishlist
Tags: patch
Hi,
I'm working on generating historical stats about Debian packages, using
lintian to extract information from packages.
One thing I'd like to track is the usage of source formats, and for 1.0,
the usage of patch systems. An
Package: lintian
Version: 2.9.1
Severity: wishlist
Tags: patch
Hi,
I'm working on generating historical stats about Debian packages, using
lintian to extract information from packages.
One thing I'd like to track is the debhelper compatibility level in use
by packages. An example graph is
Source: lintian
Version: 2.5.118
Severity: serious
Justification: FTBFS on amd64
Tags: buster sid
Usertags: ftbfs-20181229 ftbfs-buster
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> make[1]: Entering directory '/<>'
>
On 08/02/18 at 22:43 +0530, Chris Lamb wrote:
> tags 858588 + pending
> thanks
>
> Okay, after confusing myself even more for a bit, this is now
> pending upload:
>
>
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=0848266e444d029c6fa826f1a6d3e8dd2dad0739
Thanks!
- Lucas
On 08/02/18 at 20:05 +0530, Chris Lamb wrote:
> Hi Lucas,
>
> > I could even argue that the above tag is misnamed, and should be e.g.
> > systemd-no-service-file-for-init-script-but-other-init-scripts-have-
> > service-file
>
> Oh wow. Indeed, this is actually quite badly misnamed which
On 03/02/18 at 04:00 +0530, Chris Lamb wrote:
> tags 858588 + moreinfo
> thanks
>
> Hi Lucas,
>
> > It would be great to add a classification tag in the case where
> > no service file is provided for an init script, even if the maintainer
> > did not make any other effort to make the package
Package: lintian
Version: 2.5.50.1
Severity: wishlist
Hi,
In <2af5949a-7683-b668-0a96-e4f85f4fa...@dogguy.org>, Mehdi mentioned
"All packages with daemons provide a unit file for SystemD" as a
possible idea for the roadmap.
it seems that lintian is not able to track this yet, because
Source: lintian
Version: 2.5.50
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170128 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed to build on
amd64.
Relevant part (hopefully):
>
Source: lintian
Version: 2.5.49
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20161118 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed to build on
amd64.
Relevant part (hopefully):
> [tests]
>
Source: lintian
Version: 2.5.45
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160728 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed to build on
amd64.
Relevant part (hopefully):
> [debs]
>
Hi Niels,
On 06/03/16 at 19:11 +, Niels Thykier wrote:
> Hi,
>
> I took a stab at implementing classification tags (see attached patches
> or [1]). These tags are intended solely as a means to classify (an
> aspect of) a package and are by no means an issue people need to fix.
>
> * The
Package: lintian
Version: 2.5.39
Severity: wishlist
Hi,
In the thread https://lists.debian.org/debian-devel/2015/12/msg00383.html, and
specifically in
https://lists.debian.org/20151228134852.ga17...@xanadu.blop.info
there was a discussion about adding several pedantic warnings for:
Package: lintian
Version: 2.5.17
Severity: minor
Tags: patch
Hi,
The patch below makes the description for
desktop-entry-lacks-keywords-entry point to
https://wiki.gnome.org/GnomeGoals/DesktopFileKeywords, which provides a
detailed explanation of the issue.
The patch applies to the version of
On 28/08/13 at 19:48 +0200, bastien ROUCARIES wrote:
Package: lintian
Version: 2.5.14
May be time to ask to mailing list ?
Is there a consolidated list of concerns about 3.0 (quilt) somewhere?
Would it be possible to not display the tag in case the package fits in
one of the cases where we
On 29/03/13 at 01:28 +0100, Niels Thykier wrote:
Hi,
I am not sure we can in general promote the use of 3.0 (quilt) over 1.0
via Lintian at the moment[1].
Though I noticed that people are writing their own tools to extract
things like what source format is used or what build systems are
Source: lintian
Version: 2.5.9
Severity: serious
Tags: wheezy sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20120624 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed to build on
amd64.
Relevant part:
On 24/06/12 at 17:52 +0200, Niels Thykier wrote:
On 2012-06-24 11:34, Lucas Nussbaum wrote:
Source: lintian
Version: 2.5.9
Severity: serious
Tags: wheezy sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20120624 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During
Package: lintian
Version: 2.4.3
Severity: normal
(this request sounds obvious, but I couldn't find a bug about it)
Hi,
According to http://upsilon.cc/~zack/stuff/dpkg-v3/, there is now
basically one third of the packages using the 3.0 (quilt) format.
It would be great if lintian could suggest
: guile-1.8.5/build-aux/ltmain.sh: implausibly old time stamp
1970-01-01 00:00:00
tar: guile-1.8.5/guile-readline/ltmain.sh: implausibly old time stamp
1970-01-01 00:00:00
Have you considered redirecting them elsewhere, so they don't end up in
the log?
--
| Lucas Nussbaum
| lu...@lucas-nussbaum.net
Package: lintian
Severity: wishlist
Hi,
I ran into a bug in libspf, where dh_makeshlibs was called *after*
dh_installdeb.
Would lintian be a good place to test that dh_* scripts are called in a
coherent order?
(libspf is fixed now)
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas
a list of those would be interesting, especially
since some bashisms cause non-deterministic failures. A cool example is
the patch of bug #374004, which replaces a bashism that causes the build
to fail with a bashism that causes rm -rf debian/tmp to be executed in
a subshell. (!)
--
| Lucas
Hi,
On the per-maintainer view of lintian.d.o, it would be great to include
co-maintained packages.
See
http://www.bononia.it/~zack/blog/posts/2007/07/uploaders_vs_maintainers.html
for a rationale :-)
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL
52 matches
Mail list logo
