Package: lintian
Version: 2.120.0
Severity: normal
X-Debbugs-Cc: hert...@debian.org, daniel.baum...@progress-linux.org,
debian-common-l...@lists.debian.org, debian-python@lists.debian.org,
The Maintainer field is only allowed to have a single contact. When you
put two, you get a "too
Package: lintian
Version: 2.116.3
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org
The current recommended way for packaging python packages (upstream)
is to provide a pyproject.toml file and build with setuptools
(python3-setuptools). Debian python package building activates this
Package: lintian
Version: 2.116.1
Severity: wishlist
X-Debbugs-CC: debian-python@lists.debian.org
The *.pyc *.pyo files are Python bytecode and are almost always
generated from Python source code. Since Python 3 these are usually
stored in a __pycache__/ directory.
Since these files are not
On 2022-12-01 01 h 52, Stuart Prescott wrote:
Hi Scott
On 01/12/2022 15:16, Scott Kitterman wrote:
On Wednesday, November 30, 2022 10:38:30 PM EST Stuart Prescott wrote:
Hi Scott,
On 01/12/2022 02:16, Scott Kitterman wrote:
Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc
Hi Scott
On 01/12/2022 15:16, Scott Kitterman wrote:
On Wednesday, November 30, 2022 10:38:30 PM EST Stuart Prescott wrote:
Hi Scott,
On 01/12/2022 02:16, Scott Kitterman wrote:
Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org
The missing
On Wednesday, November 30, 2022 10:38:30 PM EST Stuart Prescott wrote:
> Hi Scott,
>
> On 01/12/2022 02:16, Scott Kitterman wrote:
> > Package: lintian
> > Version: 2.115.3
> > Severity: normal
> > X-Debbugs-Cc: debian-python@lists.debian.org
> >
>
Hi Scott,
On 01/12/2022 02:16, Scott Kitterman wrote:
Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org
The missing-prerequisite-for-pyproject-backend check appears to only
look for the prerequisite packages in Build-Depends, but since they
aren&#
Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org
The missing-prerequisite-for-pyproject-backend check appears to only
look for the prerequisite packages in Build-Depends, but since they
aren't needed for clean, they could be in Build-Depends-
On Tue, Aug 30, 2022 at 07:33:07PM +0200, Gregor Riepl wrote:
> > I: python3-pyxdameraulevenshtein: hardening-no-bindnow
> > [usr/lib/python3/dist-packages/pyxdameraulevenshtein.cpython-310-x86_64-linux-gnu.so]
> >
> > and there is nothing about CFLAGS or the like in the setup.py file.
> > So if
I: python3-pyxdameraulevenshtein: hardening-no-bindnow
[usr/lib/python3/dist-packages/pyxdameraulevenshtein.cpython-310-x86_64-linux-gnu.so]
and there is nothing about CFLAGS or the like in the setup.py file.
So if having this hardening flag enabled is a good thing, it should
probably be enabled
Hi!
A package I maintain within the team (python3-pyxdameraulevenshtein)
gives the following lintian message:
I: python3-pyxdameraulevenshtein: hardening-no-bindnow
[usr/lib/python3/dist-packages/pyxdameraulevenshtein.cpython-310-x86_64-linux-gnu.so]
The debian/rules file is very bland
On Tue, Feb 08, 2022 at 12:26:01AM +, Stefano Rivera wrote:
> Hi Julian (2022.02.07_06:26:38_+)
> > I'm a little confused by this. Have a look at
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005039 against
> > python3-iniconfig. It has a very straightforward debian/rules, using
Hi Julian (2022.02.07_06:26:38_+)
> I'm a little confused by this. Have a look at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005039 against
> python3-iniconfig. It has a very straightforward debian/rules, using
> pybuild, and its setup.py script has "use_scm_version=True", but it
>
On Sun, Feb 06, 2022 at 04:46:53PM +, Stefano Rivera wrote:
> Hi Julian (2022.02.06_12:19:54_+)
> > In the couple of cases I've looked at so far, it is due to the
> > upstream version using use_scm_version in setup.py. This works fine
> > for a version that is in a Git repository, but it d
> Or export SETUPTOOLS_SCM_PRETEND_VERSION.
> https://github.com/pypa/setuptools_scm#environment-variables
>
> pybuild does this for you.
i dont remember the exact details, but sometimes that doesnt work:
even just building the source package (which runs dh clean, which
invokes setup.py clean) the
Hi Julian (2022.02.06_12:19:54_+)
> In the couple of cases I've looked at so far, it is due to the
> upstream version using use_scm_version in setup.py. This works fine
> for a version that is in a Git repository, but it doesn't work for
> Debian packages, as the Git version lookup fails. So
On Sat, Feb 05, 2022 at 04:42:57PM -0500, Sandro Tosi wrote:
> > The test for this bug (and it should probably be recorded as an error,
> > not just a warning, as no Python package should have a version number
> > of 0.0.0)
>
> what exactly is the problem that would make it an 'error'?
When a pac
Package: lintian
Version: 2.111.0
Severity: wishlist
X-Debbugs-Cc: debian-python@lists.debian.org
I just ran into several Python packages that install modules with
version number 0.0.0 because of some issue with their setup.py
scripts. I just did the following on my testing system:
lz4cat
/var
Package: lintian
Version: 2.114.0
Severity: wishlist
X-Debbugs-Cc: Debian Python Team
I just hit two packages which gave me the following warning when
pkg_resources tried to load them:
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116:
PkgResourcesDeprecationWarning: 1.12.1
On Tue, Jan 18, 2022 at 03:37:13PM +0100, Thomas Goirand wrote:
> On 1/17/22 18:47, Louis-Philippe Véronneau wrote:
> > Hey folks,
> >
> > I'm following up on bug #1001677 [1] on the DPT's list to try to reach
> > consensus, as I think the Lintian tags that
On 1/17/22 18:47, Louis-Philippe Véronneau wrote:
Hey folks,
I'm following up on bug #1001677 [1] on the DPT's list to try to reach
consensus, as I think the Lintian tags that were created to fix this bug
are not recommending the proper thing.
As a TL;DR for those of you who don'
On Tuesday, January 18, 2022 3:17:31 AM EST Neil Williams wrote:
> On Mon, 17 Jan 2022 12:47:44 -0500
>
> Louis-Philippe Véronneau wrote:
> > Hey folks,
> >
> > I'm following up on bug #1001677 [1] on the DPT's list to try to reach
> > consensus, as I
On Mon, 17 Jan 2022 12:47:44 -0500
Louis-Philippe Véronneau wrote:
> Hey folks,
>
> I'm following up on bug #1001677 [1] on the DPT's list to try to reach
> consensus, as I think the Lintian tags that were created to fix this
> bug are not recommending the proper t
> I think the proper fix would be to ask people to move away from
> `py3versions -r` if there is no X-Python3-Version, and use`py3versions
> -s` instead.
>
> As such, I think we should ask the Lintian maintainers to:
>
> 1. Change the desc for tag declare-requested-python
Hey folks,
I'm following up on bug #1001677 [1] on the DPT's list to try to reach
consensus, as I think the Lintian tags that were created to fix this bug
are not recommending the proper thing.
As a TL;DR for those of you who don't want to read the whole BTS thread,
jdg saw
Package: lintian
Version: 2.110.0
Severity: normal
Hi, I see lintian 2.110 is now emitting a
package-contains-python-dot-directory tag for .egg-info directories in
binary packages.
We do not want to encourage package maintainers to remove .egg-info
directories from their Python binary packages
sensus.
>
> Thanks. This is more clear. I just uploaded with python3-pubsub to new.
BTW, I think the issue deserves a lintian warning:
package-name-different-than-loadable-python-module
or something like this.
Kind regards, Andreas.
--
http://fam-tille.de
[Ole Streicher, 2018-10-20]
> W: python3-astropy: python-module-in-wrong-location
> usr/lib/python3.7/dist-packages/astropy/
> usr/lib/python3/dist-packages/astropy/
> W: python3-astropy: python-module-in-wrong-location
> usr/lib/python3.7/dist-packages/astropy/coordinates/
> usr/lib/python3/di
8<---
I get the following lintian warnings about the generated files:
W: python3-astropy: python-module-in-wrong-location
usr/lib/python3.7/dist-packages/astropy/ usr/lib/python3/dist-packages/astropy/
W: python3-astropy: python-module-in-wrong-location
usr/li
Control: tag -1 moreinfo
On Thu, Sep 20, 2018 at 09:43:46AM +0200, Julian Andres Klode wrote:
> lintian reports ancient-python-version-field for python-apt, but removing that
> causes py{,3}versions to complain:
>
> pyversions: missing X(S)-Python-Version in control file, fall back
[Andreas Tille, 2018-08-04]
> for the new version of python-pyvcf[1] I get
>
> W: python3-pyvcf: python-module-in-wrong-location
> usr/lib/python3.7/dist-packages/vcf/ usr/lib/python3/dist-packages/vcf/
> W: python3-pyvcf: python-module-in-wrong-location
> usr/lib/python3.7/dist-packages/vcf/par
Hi,
for the new version of python-pyvcf[1] I get
W: python3-pyvcf: python-module-in-wrong-location
usr/lib/python3.7/dist-packages/vcf/ usr/lib/python3/dist-packages/vcf/
W: python3-pyvcf: python-module-in-wrong-location
usr/lib/python3.7/dist-packages/vcf/parser.py
usr/lib/python3/dist-packag
Hi,
2018-05-15 6:55 GMT+02:00 Scott Kitterman :
>
> I don't think deleting pycompat and pyversions is worth an upload. They
> are
> obsolete and should be removed, but don't actually hurt anything.
>
I agree. But maybe there are more changes in git, which in sum are worth an
upload :)
--
Best
in a while
> and that would benefit from a big cleanup).
>
> On Mon, May 14, 2018 at 3:24 AM, Ondrej Novy wrote:
> > I didn't write count and I don't have list :)
>
> The lintian tag would help getting the number easily! ;)
>
> One of my thoughts about intro
> I didn't write count and I don't have list :)
The lintian tag would help getting the number easily! ;)
One of my thoughts about introducing it on info level is that we
should probably update https://wiki.debian.org/Python/Policy (I'll
start a separate thread on that) before ha
Hi,
2018-05-14 12:14 GMT+02:00 Thomas Goirand :
> As Ondrej wrote, there's only a few packages having this. How about we
> just do a few NMUs as a team to fix that completely in the archive?
>
(imho) lintian tag is still good idea. In future we can change it to
"error"
On 05/14/2018 02:41 AM, Joseph Herlant wrote:
> Hi guys,
>
> FYI I am requesting a new lintian tag to warn about the presence of
> the debian/pyversions file as it is supposed to be obsolete since
> dh_python2 [1].
As Ondrej wrote, there's only a few packages having this. Ho
Hi guys,
FYI I am requesting a new lintian tag to warn about the presence of
the debian/pyversions file as it is supposed to be obsolete since
dh_python2 [1].
According to the policy[2], we are supposed to use the
X-Python3-Version field in debian/control to specify the version now.
Please let
Hi,
On Fri, May 11, 2018 at 1:10 AM, Ondrej Novy wrote:
> Are we sure it's completely safe to remove it globally?
Also, it's written in the python policy to do so:
https://wiki.debian.org/Python/Policy
"Another note: if there is a debian/pycompat file, you must launch
dh_python after dh_pysuppo
On Friday, May 11, 2018 09:33:20 AM Joseph Herlant wrote:
> Hi,
>
> On Fri, May 11, 2018, 1:10 AM Ondrej Novy wrote:
> > no problem, so just remove that file?
> >
> >
> > https://github.com/onovy/onovy-mass/commit/2c24adf1ecd8fc934328f69c75b2b2d
> > 9256ee3c9
> >
> > Are we sure it's completel
Hi,
On Fri, May 11, 2018, 1:10 AM Ondrej Novy wrote:
> no problem, so just remove that file?
>
>
> https://github.com/onovy/onovy-mass/commit/2c24adf1ecd8fc934328f69c75b2b2d9256ee3c9
>
> Are we sure it's completely safe to remove it globally?
>
This file has been deprecated for about 10 years i
Hi,
2018-05-11 0:19 GMT+02:00 Joseph Herlant :
> ... maybe we could delete the pycompat file
> when exists at the same time (in a separate commit of course) to to
> get rid of debian-pycompat-is-obsolete. It seems there are still 18
> python modules with that file in.
>
no problem, so just remov
On Thu, May 10, 2018 at 4:29 AM, Ondrej Novy wrote:
> Removing Python 2 version: <= 2.7 (thus all)
> Removing Python 3 version: <= 3.4 (older than jessie)
>
> Any objections?
Thanks for doing that Ondřej, maybe we could delete the pycompat file
when exists at the same time (in a separate commit o
Hi,
because of:
-
https://wiki.debian.org/Python/LibraryStyleGuide?action=diff&rev1=85&rev2=86
- https://lintian.debian.org/tags/ancient-python-version-field.html
I would like to mass commit into DPMT/PAPT this:
https://salsa.debian.org/python-team/modules/pytest/commit/a737368e75cb2e7
On Tuesday, September 29, 2015 10:31:23 PM Julien Puydt wrote:
> Le mardi 29 sept. 2015 à 15:51:44 (-0400), Barry Warsaw a écrit :
> > On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote:
> > >(and remember to remove DPMT from debian/control if it's not in SVN ;P)
> >
> > Given that the final git
On Tuesday, September 29, 2015 04:48:09 PM Barry Warsaw wrote:
> On Sep 29, 2015, at 10:31 PM, Julien Puydt wrote:
> >I still have a series of things I plan to package for Debian ; those are
> >Python Modules, and I'll use git. If that's a problem for the Debian
> >Python Modules Team, can you poin
On Sep 29, 2015, at 10:31 PM, Julien Puydt wrote:
>I still have a series of things I plan to package for Debian ; those are
>Python Modules, and I'll use git. If that's a problem for the Debian
>Python Modules Team, can you point me to a more appropriate team?
This illustrates my concern. We'v
Le mardi 29 sept. 2015 à 15:51:44 (-0400), Barry Warsaw a écrit :
> On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote:
>
> >(and remember to remove DPMT from debian/control if it's not in SVN ;P)
>
> Given that the final git migration is imminent (really! otherwise I'm going to
> scream ;), can
On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote:
>(and remember to remove DPMT from debian/control if it's not in SVN ;P)
Given that the final git migration is imminent (really! otherwise I'm going to
scream ;), can we not force people to go through this churn right now?
Yes, let's discourag
[Julien Puydt, 2015-09-29]
> Yes, that's what I said: I put myself as uploaders so lintian
> doesn't bug me about NMU.
my guess¹ is that you used different name/email in debian/control and
debian/changelog
[¹] and it's the last one, include pointer to sources next time
Hi Charles,
Much appreciated!
Regards,
Jorge
On Sat, Dec 6, 2014 at 8:38 AM, Charles Plessy wrote:
> Le Sat, Dec 06, 2014 at 08:19:39AM +, Jorge Sebastião Soares a écrit :
> > It's been a while since I posted this first.
> >
> > Is someone able to have a look at this package?
>
> Hi Jorge
Le Sat, Dec 06, 2014 at 08:19:39AM +, Jorge Sebastião Soares a écrit :
> It's been a while since I posted this first.
>
> Is someone able to have a look at this package?
Hi Jorge,
I am a bit short of time, but I will have a look next Wednesday if nobody does
before.
Cheers
--
Charles
-
It's been a while since I posted this first.
Is someone able to have a look at this package?
Jorge
On Fri, Nov 28, 2014 at 12:58 PM, Jorge Sebastião Soares <
j.s.soa...@gmail.com> wrote:
> Hi all,
>
> I have commited my last changes to [1].
>
> The test suite does not run automatically. I belie
Hi all,
I have commited my last changes to [1].
The test suite does not run automatically. I believe that pysam needs to be
installed before hand in order to test it.
I have installed python3-pysam on my system and ran the test suite and it
seemed to ran fine.
I emailed the test report to the gu
Package: lintian
Version: 2.5.25
Severity: wishlist
For applications that use python-qt4, pyqtconfig has been the standard way to
access attributes about the PyQt4 installation. Upstream has decided to drop
this for alternate methodes. For now, we can continue to use the upstream
legacy
* Barry Warsaw , 2014-05-29, 10:53:
Unfortunately, it's not just six that gets vendorized. I'd be in
favor of a lintian check if it could be generalized to warn against
all vendorizing. A warning specifically about six is helpful but
limited.
How would you implement the generaliz
d packages.
>>
>>What tool do people use to do vendorising?
>
> AFAICT it's mostly `$foreignvcs pull; cp -a; $myvcs commit`.
>
> So not very helpful. ;)
What about encouraging often-vendorised projects to include a comment
like "Project: foo" in their __init__.
On May 29, 2014, at 10:58 PM, Paul Wise wrote:
>On Thu, May 29, 2014 at 10:53 PM, Barry Warsaw wrote:
>
>> One of the things I want to add to my mythical PEP are at least declarations
>> of vendored packages.
>
>What tool do people use to do vendorising?
AFAICT it's mostly `$foreignvcs pull; cp -
On Thu, May 29, 2014 at 10:53 PM, Barry Warsaw wrote:
> One of the things I want to add to my mythical PEP are at least declarations
> of vendored packages.
What tool do people use to do vendorising? Maybe that could be patched
to include a file containing info about which projects were
vendorise
On May 29, 2014, at 04:47 PM, Thomas Goirand wrote:
>On 05/28/2014 10:02 PM, Barry Warsaw wrote:
>> Unfortunately, it's not just six that gets vendorized. I'd be in favor of a
>> lintian check if it could be generalized to warn against all vendorizing. A
>> wa
On 05/28/2014 10:02 PM, Barry Warsaw wrote:
> Unfortunately, it's not just six that gets vendorized. I'd be in favor of a
> lintian check if it could be generalized to warn against all vendorizing. A
> warning specifically about six is helpful but limited.
Hi Barry,
How woul
On 05/29/2014 01:53 AM, Julian Taylor wrote:
> Also it does not seem to have a stable API, I just changed back to
> embedded six in python-scipy because what we have in unstable now is not
> compatible with what scipy is using now (1.2).
That's a call for updating upstream code, IMO. If upstream d
On 28.05.2014 16:02, Barry Warsaw wrote:
> On May 28, 2014, at 05:18 PM, Thomas Goirand wrote:
>
>> To avoid that it grows out of proportion, can someone add a lintian
>> check for that? I'd be *very* happy to have this check for myself as
>> well, so that I don&#x
On May 28, 2014, at 05:18 PM, Thomas Goirand wrote:
>To avoid that it grows out of proportion, can someone add a lintian
>check for that? I'd be *very* happy to have this check for myself as
>well, so that I don't miss it once more (it's quite easy to miss...).
Unfortun
On May 28, 2014, at 03:47 PM, Jakub Wilk wrote:
>* Daniele Tricoli , 2014-05-28, 15:36:
>>>txclib -> urllib3 -> six
>>
>>Jakub, which version of urllib3 are you referring to?
>
>The one that is embedded in transifex-client.
That's the problem with vendorizing. Stuff like that lives in the darkes
* Daniele Tricoli , 2014-05-28, 15:36:
txclib -> urllib3 -> six
Jakub, which version of urllib3 are you referring to?
The one that is embedded in transifex-client.
I removed the embedded copy on 1.3-2 so it should be ok...
Great, thanks.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian
On Wednesday 28 May 2014 11:43:47 Jakub Wilk wrote:
> txclib -> urllib3 -> six
Jakub, which version of urllib3 are you referring to?
I removed the embedded copy on 1.3-2 so it should be ok...
Both (with version 1.8-2):
$ dpkg -L python-urllib3 | grep six
$ dpkg -L python3-urllib3 | grep
* Thomas Goirand , 2014-05-28, 17:18:
# apt-file search /six.py | wc -l
53
Eeek. Some of these embeddings are even nested:
sympy -> mpmath -> six
txclib -> urllib3 -> six
feedgenerator -> (parts of) django.utils -> six
To avoid that it grows out of proportion, can som
even discovered that it's looking like I have let
it slip in one of my packages as well.
To avoid that it grows out of proportion, can someone add a lintian
check for that? I'd be *very* happy to have this check for myself as
well, so that I don't miss it once more (it's quite ea
On Sun, Mar 23, 2014 at 7:28 PM, Ben Finney wrote:
> I think Lintian4Python installs a 'lintian4py-info(1)' command to do the
> same thing. You can then get an explanation with::
>
> $ lintian4py-info --tags missing-dependency-on-byte-compilation-helper
It's still not particularly informative
ython-all and
> python3-all?
The regular Lintian has ‘lintian-info(1)’ to give a verbose description
of a tag, including recommendations to address the problem which the tag
reports::
$ lintian-info --tags foo-bar-lintian-tag
I think Lintian4Python installs a ‘lintian4py-info(1)’ command to d
Source: lintian
Version: 2.5.2
Severity: wishlist
The are currently (at least?) 2 places where lintian lists Python
versions: checks/rules ($PYTHON2X_DEPEND, $PYTHON3X_DEPEND) and
checks/fields ($PYTHON_DEV). Theses lists can quickly get out of sync
and out of date. It'd nice if lintian
* Piotr Ożarowski , 2011-03-24, 14:26:
IMHO old-versioned-python-dependency tag should be simply removed from
lintian. These dependencies can be valid even if
dh_py{central,support,thon2} is not used (debian-python@l.d.o CCed for
confirmation)
Agreed. old-version-python-dependency was meant
2" in postinst.
IMHO old-versioned-python-dependency tag should be simply removed from
lintian. These dependencies can be valid even if dh_py{central,support,thon2}
is not used (debian-python@l.d.o CCed for confirmation)
--
Piotr Ożarowski Debian GNU
Package: lintian
Version: 2.4.3
Severity: wishlist
If a binary package ships /usr/share/pyshared-data/PACKAGENAME file, it
should have dependency on at least python-central (>= 0.6).
Normally missing/insufficient dependency on python-central indicates
that ${python:Depends} was omitted f
Package: lintian
Version: 2.4.3
Severity: wishlist
If a binary package ships files in /usr/share/python-support/, it should
have at least unversioned dependency on python-support.
If a binary package ships a /usr/share/python-support/PACAKGENAME.public
or /usr/share/python-support
On Tue, 03 Nov 2009 19:02:21 +0100 Josselin Mouette wrote:
>Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit :
>> Is there a silent Debian Python policy drafter out there who would like
>> to step forward? Or is this work now moribund?
>
>Bug reports concerning the Python policy have b
Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit :
> Is there a silent Debian Python policy drafter out there who would like
> to step forward? Or is this work now moribund?
Bug reports concerning the Python policy have been silently ignored. I’m
afraid this will last as long as the re
On Mon, 2 Nov 2009 16:50:00 +0300 anatoly techtonik wrote:
>On Mon, Nov 2, 2009 at 2:27 PM, Scott Kitterman wrote:
>>
>> I'm not aware of any ongoing work. I would be willing to help work on such
>> a thing, but we currently lack a good mechanism for developing/approving
>> such a policy.
>
>Wit
On Mon, Nov 2, 2009 at 2:27 PM, Scott Kitterman wrote:
>
> I'm not aware of any ongoing work. I would be willing to help work on such
> a thing, but we currently lack a good mechanism for developing/approving
> such a policy.
With clear policy and precise goal you won't need approving mechanism
On Mon, 02 Nov 2009 21:22:47 +1100 Ben Finney
wrote:
>Luca Falavigna writes:
>
>> Scott Kitterman ha scritto:
>> > Since we currently lack anything like a maintained Python policy, I
>> > think this is putting the cart before the horse. [ &]
>
>> [ &] we could wait for the new policy to be draft
hould have:
> W: dh_python (use dh_pysupport instead)
> in the first place.
I thought this was already defined, but probably not in Lintian.
>> * W: Arch: all package but build-dependency on python*-dev
>
> I've already filed a bug about this:
> http://b
e
>
> Well, this fits the definition of "pedantic" (people - e.g., me - don't
> agree that this check is correct). But I don't see the point in adding
> pedantic tags to lintian. :)
-dbg packages are useful for debugging purposes, so it'
Luca Falavigna writes:
> Scott Kitterman ha scritto:
> > Since we currently lack anything like a maintained Python policy, I
> > think this is putting the cart before the horse. […]
> […] we could wait for the new policy to be drafted, I'm not sure when
> this will happen, though.
I don't know
Scott Kitterman ha scritto:
>> * E: Don't hard-code {site,dist}-packages
>> * E: Python files in incorrect python2.?/{site,dist}-packages directory
>
> Since we currently lack anything like a maintained Python policy, I think
> this is putting the cart before the horse. Particularly any Error le
Ben Finney ha scritto:
>> * I: Place Python applications in private directory
>
> What would be the test for these cases? That is, what would Lintian
> actually check in the package to determine whether these should be
> emitted?
This is quite complex to say, I initially thoug
On Mon, Nov 02, 2009 at 12:54:04AM +0100, Luca Falavigna wrote:
> Currently, Lintian supports dozen of tags [1], but very few strictly
> related to Python packaging. I think maintainers and sponsors would
> benefit a lot if some common mistakes and suggestions are automatically
>
*-dev
I've already filed a bug about this:
http://bugs.debian.org/551793
Other ideas for lintian checks:
- Python source mixes tabs with spaces.
- *-dbg package contains *_d.so, but no detached symbols in
/usr/lib/debug/.
--
Jakub Wilk
signature.asc
Description: Digital signature
Build extension for every supported Python version
> * I: Place Python applications in private directory
What would be the test for these cases? That is, what would Lintian
actually check in the package to determine whether these should be
emitted?
> * W: Arch: all package but build-depend
On Mon, 2 Nov 2009 00:54:04 +0100 Luca Falavigna
wrote:
>Currently, Lintian supports dozen of tags [1], but very few strictly
>related to Python packaging. I think maintainers and sponsors would
>benefit a lot if some common mistakes and suggestions are automatically
>displayed by L
Currently, Lintian supports dozen of tags [1], but very few strictly
related to Python packaging. I think maintainers and sponsors would
benefit a lot if some common mistakes and suggestions are automatically
displayed by Lintian.
I propose a non comprehensive list of tags I'd like t
[Dmitrijs Ledkovs, 2009-09-03]
> I have no clue about the js file bit though. Remove it (via patch) and
> symlink it from the shipped package by debian? That is my wild guess.
> Or maybe contact sphinx maintainer in Debian. I hope there is an
> option to symlink it.
http://lists.debian.org/debian-
(Please reply to list as well thanks)
2009/9/3 Alessandro Dentella :
>> > Last question
>> > -
>> >
>> > When testing creating the package from my newly created sources on a newer
>> > machine (ubuntu 9.04), lintian complained:
>> &
2009/9/3 Alessandro Dentella :
>> > bad-distribution-in-changes-file
>> >
>> >
>> > If I run lintian on .changes it complains
>> > "bad-distribution-in-changes-file" but I'm unsure on what I should
thanks to anybody for the answers.
> > I forced
> > it an now lintian complains:
> >
> >san...@bluff:/misc/src/hg/py$ lintian python-sqlkit_0.8.6_all.deb
> >W: python-sqlkit: latest-debian-changelog-entry-without-new-version
> >
> >W
[Bernd Zeimetz, 2009-09-03]
> Cyril Brulebois wrote:
> > Alessandro Dentella (03/09/2009):
> >> I'm trying to produce the python-sqlkit package. I'm both the upsteam
> >> author and the mantainer. I have /debian folder in original package. I
> >> recently read is not recommended but I found
read is not recommended but I found easier to manage to have it
>> in the same mercurial repo. I have several questions:
You'll have to change that in case you want to get the package into debian.
>>
>> release version
>> ---
>>
>> The .deb
n the same mercurial repo. I have several questions:
release version
---
The .deb was lintian clean on rel 0.8.6-rc5, then I did 'dch -v 0.8.6' and
dch required -b option as felt 0.8.6-rc5 was grater than 0.8.6. I forced
it an now lintian complains:
san...@b
ave it
> in the same mercurial repo. I have several questions:
>
> release version
> -------
>
> The .deb was lintian clean on rel 0.8.6-rc5, then I did 'dch -v 0.8.6' and
> dch required -b option as felt 0.8.6-rc5 was grater than 0.8.6.
it is. You should
:
release version
---
The .deb was lintian clean on rel 0.8.6-rc5, then I did 'dch -v 0.8.6' and
dch required -b option as felt 0.8.6-rc5 was grater than 0.8.6. I forced
it an now lintian complains:
san...@bluff:/misc/src/hg/py$ lintian python-sqlkit_0.8.6_all.deb
W: p
1 - 100 of 124 matches
Mail list logo
