thanks you all,
I added a MANIFEST.in file and create an entry point for the application script
I end up with this error
adding 'xrdutils-0.0.4.dist-info/licenses/LICENSE'
adding 'xrdutils-0.0.4.dist-info/METADATA'
adding 'xrdutils-0.0.4.dist-info/WHEEL'
adding 'xrdutils-0.0.4.dist-info/entry_
I found the culprite :)..
a malformed entry_point.
"toto.test" instead of "toto.test:main"
Is there a linter for the pyprojects file ?
Thanks for your help.
Fred
Hi PICCA (2025.06.12_09:12:58_+)
I: pybuild plugin_pyproject:144: Unpacking wheel built for python3.13 with
"installer" module
E: pybuild pybuild:389: build: plugin pyproject failed with:
dh_auto_build: error: pybuild --build -i python{version} -p 3.13 returned exit
code 13
make: *** [debi
On Jun 11, 2025 18:51, Stefano Rivera wrote:
>
> Hi thomas (2025.06.11_16:30:15_+)
> >As for the version, setuptools-scm understand an env var that you may set
> >with something like:
> >export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog
> >-something)
>
> You don't
On Jun 11, 2025 17:57, PICCA Frederic-Emmanuel
wrote:
>
> > This is a sitation where upstream tarballs are preferable to git.
>
> Yes but for now the package is only distributed via git...
>
> Even worse, it is use via a checkout and that's all.
>
> > If you use an sdist, the egg-inf
> Hi thomas (2025.06.11_16:30:15_+)
>>As for the version, setuptools-scm understand an env var that you may set with
>>something like:
>>export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -something)
the same kind of things is availalbe also for hatchling-vcs ?
Hi thomas (2025.06.11_16:30:15_+)
As for the version, setuptools-scm understand an env var that you may set with
something like:
export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -something)
You don't need to do that, pybuild does it for you.
Stefano
--
Stefano Rivera
h
Hi PICCA (2025.06.11_17:14:36_+)
Hi thomas (2025.06.11_16:30:15_+)
As for the version, setuptools-scm understand an env var that you may set with
something like:
export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -something)
the same kind of things is availalbe also for
Hi PICCA (2025.06.11_15:37:48_+)
There is no information about the data file list...
It is SOURCES.txt, see for example #1052854.
I don't think setuptools-scm is even parsing it (I can't see any code
doing so), it must be setuptools parsing it, itself.
Stefano
--
Stefano Rivera
http:
> However, it seems the upstream build actually depends on setuptools-scm now,
> they (you? :)) don't use any other way to tell the build system about
> the data files - the *.png images, the *.rst documentation, etc..
> This... may be a problem if the package is not built out of a Git checkout
> w
> This is a sitation where upstream tarballs are preferable to git.
Yes but for now the package is only distributed via git...
Even worse, it is use via a checkout and that's all.
> If you use an sdist, the egg-info / dist-info in the sdist will contain
> a file list that setuptools-scm can use.
On Wed, Jun 11, 2025 at 03:35:54PM +, Stefano Rivera wrote:
> Hi PICCA (2025.06.11_15:10:53_+)
> > And indded via sbuild there is no .git directory so setuptools-scm do not
> > provide the list.
> >
> > Do we know how to deal with this at the pacakging level. the upstream is
> > using th
> The version number is in the very first line of debian/changelog.
Yes I can use this and extract the version number by myself.
reading this,
https://salsa.debian.org/python-team/packages/setuptools-scm/-/blob/master/debian/README.Debian?ref_type=heads
There is no information about the data
On Wed, Jun 11, 2025 at 05:44:07PM +0200, PICCA Frederic-Emmanuel wrote:
> > However, it seems the upstream build actually depends on setuptools-scm now,
> > they (you? :)) don't use any other way to tell the build system about
> > the data files - the *.png images, the *.rst documentation, etc..
>
On Wed, Jun 11, 2025 at 05:25:41PM +0200, Santiago Vila wrote:
> El 11/6/25 a las 17:10, PICCA Frederic-Emmanuel escribió:
> > It seems that this is due to setuptools-scm which provide the list of the
> > data during the dpkg-buildpackage.
>
> That's it. You can now add setuptools-scm to build-co
Hi PICCA (2025.06.11_15:10:53_+)
And indded via sbuild there is no .git directory so setuptools-scm do not
provide the list.
Do we know how to deal with this at the pacakging level. the upstream is using
the code from the git repository, so it is not affected by this issue...
This is a
setuptools-scm is also use in order to generate the version number.
Our packaging tools are dealing with this ?
there is no policy requirement to add build-conflicts.
Or maybe it is but most people believe they are not really useful
if we all use minimal chroots.
El 11/6/25 a las 17:27, PICCA Frederic-Emmanuel escribió:
setuptools-scm is also use in order to generate the version number.
Our packaging tools are dealing with this ?
The version number is in the very first line of debian/changelog.
It seems that this is due to setuptools-scm which provide the list of the data
during the dpkg-buildpackage.
taken from the doc of setuptools-scm ---
Additionally setuptools-scm provides setuptools with a list of files that are
managed by the SCM (i.e. it automatically adds all the SCM-managed
El 11/6/25 a las 17:10, PICCA Frederic-Emmanuel escribió:
It seems that this is due to setuptools-scm which provide the list of the data
during the dpkg-buildpackage.
That's it. You can now add setuptools-scm to build-conflicts if it makes you
happy.
It might help some people (for example, yo
El 11/6/25 a las 16:52, PICCA Frederic-Emmanuel escribió:
When using dpkg-buildpackage, try at least using a chroot containing
only build-essential packages and the build-dependencies.
both are using the python -m build method...
so the setuptools build system has different behaviour depending
> When using dpkg-buildpackage, try at least using a chroot containing
> only build-essential packages and the build-dependencies.
both are using the python -m build method...
so the setuptools build system has different behaviour depending on other
installed packages ?
Fred
El 11/6/25 a las 15:39, PICCA Frederic-Emmanuel escribió:
Now if I build the package within sbuild I get this file list.
[...]
And with a simple dpkg-buildpackage on unstable distribution.
[...]
When using dpkg-buildpackage, try at least using a chroot containing
only build-essential packages
Hello I am working on this package
salsa:science-team/xrdutils
This is a pure python package, which use setuptools.
Now if I build the package within sbuild I get this file list.
(I will just take the grafit package)
dh_auto_build -O--buildsystem=pybuild
I: pybuild plugin_pyproject:129: Bui
Hi Federico (2024.06.03_16:11:27_+)
> I was in the DPMT back when it was on Alioth and I would like to join
> it again. My Salsa login is "federico".
Added, welcome back
Stefano
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Hello,
I was in the DPMT back when it was on Alioth and I would like to join
it again. My Salsa login is "federico".
I have read the policy and I accept it:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
Thank you!
--
Federico
On Thu, May 25, 2023 at 12:19:00PM +, TopologicRose wrote:
> Hi,
> want to contribute a Python package which called pyvis
> (https://pyvis.readthedocs.io/en/latest/index.html) for APT.
> A friend of mine works with it and wants it as a Debian package instead of
> pip.
Start at https://mentors
Hey,
File an ITP bug for it against wnpp pseudo package and start to package it on
https://mentors.debian.org
Ask here after you filed the RFS.
Sincerely
در ۲۵ مهٔ ۲۰۲۳ ۱۲:۱۹:۰۰ (UTC)، TopologicRose
نوشت:
>Hi,
>want to contribute a Python package which called pyvis
>(https://pyvis.readthedo
Hi,
want to contribute a Python package which called pyvis
(https://pyvis.readthedocs.io/en/latest/index.html) for APT.
A friend of mine works with it and wants it as a Debian package instead of pip.
Best regards,
Thanh-Viet Nguyen
Preamble 'foo' and 'bar' are placeholders.
( https://en.wikipedia.org/wiki/Metasyntactic_variable )
On Tue, Apr 07, 2020 at 08:13:02PM +0200, Alex Mestiashvili wrote:
> Hi Debian Python folks,
>
> Is there a good entry point for a newbie who wants to package a python
> module? I am looking for
Hi Samuel,
I want make a Talks for PyConAr (Argentina). I send a
mail https://lists.debian.org/debian-python/2019/08/msg00158.html
asking about my ideas.
So I will send my proposal with that ideas. If you (and the community)
have some comments or advices, please let me know. They are
welcomes :-)
Hello,
For information, PyConFR (in french) will take place in Bordeaux from
october 31th to november 3rd. There will most probably be an workshop
on upt (universal packaging tool, https://framagit.org/upt/upt)
Samuel
On Apr 25, 2015, at 03:42 PM, Tomasz Buchert wrote:
> * the library provides a program as /usr/bin/pyenigma.py; should I:
>(a) declare another binary package (say, pyenigma) with it and
>make it depend on python3-enigma or (b) leave it as it is now, a
>part of the library?
>(a) se
On Saturday, April 25, 2015 03:42:29 PM Tomasz Buchert wrote:
> Hi guys,
> I'm preparing a package for this library:
> https://bitbucket.org/bgneal/enigma/ It's rather trivial (see
> alioth:/git/collab-maint/python-enigma.git), but I have two questions that
> remain:
>
> * the library provides a
Hi guys,
I'm preparing a package for this library: https://bitbucket.org/bgneal/enigma/
It's rather trivial (see alioth:/git/collab-maint/python-enigma.git),
but I have two questions that remain:
* the library provides a program as /usr/bin/pyenigma.py; should I:
(a) declare another binary p
On 31 March 2015 at 17:46, Zygmunt Krynicki
wrote:
>
> Is there a way to use git but build with sbuild. I kind of don't want
> to go back to pbuilder and IIRC git-buildpackage requires it.
I build packages with --git-builder=sbuild all the time, and haven't
had any issues. You can also build sour
On Mar 31, 2015, at 05:46 PM, Zygmunt Krynicki wrote:
>Is there a way to use git but build with sbuild. I kind of don't want
>to go back to pbuilder and IIRC git-buildpackage requires it.
>> gitbp is aliased to `git-buildpackage --git-ignore-new --git-export=WC -S
>> -us -uc'
Notice the -S? I p
Is there a way to use git but build with sbuild. I kind of don't want
to go back to pbuilder and IIRC git-buildpackage requires it.
On Tue, Mar 31, 2015 at 5:43 PM, Barry Warsaw wrote:
> On Mar 31, 2015, at 04:48 PM, Antoine Musso wrote:
>
>>I have only been introduced to git-buildpackage and usi
On Mar 31, 2015, at 08:23 PM, Balasankar C wrote:
>I saw a mention about inter-operability of git-dpm and git-bp in the
>link you provided[1]. What is the current status of this
>inter-operability?
I haven't seen any discussion of this in a long time. I think it was
happening on debian-devel.
C
On Mar 31, 2015, at 04:48 PM, Antoine Musso wrote:
>I have only been introduced to git-buildpackage and using Jenkins to more or
>less automatically build them when proposing a patch or a change is merged.
Really, git-dpm is just the patch manager. There are a few others, but I
found git-dpm to
Breaking from another thread
On 31/03/15 15:57, Barry Warsaw wrote:
The team still officially supports only Subversion, but we have been
experimenting with switching to git.
https://wiki.debian.org/Python/GitPackaging
I personally favor and advocate git-dpm, but this has not yet been decided b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Barry,
> * Do we adopt git-dpm or something else?
I saw a mention about inter-operability of git-dpm and git-bp in the
link you provided[1]. What is the current status of this
inter-operability? Are there any roadblocks for the same?
AFAIK, both
On Mar 31, 2015, at 04:04 PM, Zygmunt Krynicki wrote:
>Barry the import script looks pretty cool.
Thanks!
>Any chance to package it and bless it as the official conversion script?
Either that or donate it to the git-dpm project. Either way is cool with me,
though I'd love for it to get more te
Barry the import script looks pretty cool.
Any chance to package it and bless it as the official conversion script?
Best regards
ZK
On Tue, Mar 31, 2015 at 3:57 PM, Barry Warsaw wrote:
> On Mar 31, 2015, at 01:14 PM, Balasankar C wrote:
>
>>One more doubt. Where are new packages uploaded to in
On Mar 31, 2015, at 01:14 PM, Balasankar C wrote:
>One more doubt. Where are new packages uploaded to in Python Modules
>Team? Is there a git repo or should I upload to Debian Mentors?
The team still officially supports only Subversion, but we have been
experimenting with switching to git.
https
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
> The repos creation would be (with an alioth account in the team
> project)
>
> ssh git.debian.org cd /git/python-modules ./setup-repository
> 'python-wget' 'python-wget packaging'
Thanks for the detailed instructions. I believe it is ok if I
On 31/03/15 09:44, Balasankar C wrote:
Hi,
One more doubt. Where are new packages uploaded to in Python Modules
Team? Is there a git repo or should I upload to Debian Mentors? I am
asking this because, in Ruby team, the uploads usually happen to the
git repos created inside pkg-ruby-extras folder
W dniu 31.03.2015 o 09:44, Balasankar C pisze:
Hi,
One more doubt. Where are new packages uploaded to in Python Modules
Team? Is there a git repo or should I upload to Debian Mentors? I am
asking this because, in Ruby team, the uploads usually happen to the
git repos created inside pkg-ruby-ex
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
One more doubt. Where are new packages uploaded to in Python Modules
Team? Is there a git repo or should I upload to Debian Mentors? I am
asking this because, in Ruby team, the uploads usually happen to the
git repos created inside pkg-ruby-extra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Thanks. Will correct them.
- --
Regards
Balasankar C
http://balasankarc.in
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCgAGBQJVGjmTAAoJEJbtq5sua3Fx+/MIAJ0cuM0i5RRoLqbOqkMXUQcQ
KGHL3Esc+n8mkriZ15KnYIoiEDItxItanHY+B4bTo2hHIkW067Xdb+KT7lDk
> My name is Balasankar C. I am writing a module in Python and want to
> package that for Debian. So, just to understand how packaging in python
> work, I decided to package the module 'wget'. From my knowledge in
> Ruby gem
> packaging, I tried to package wget and pushed the result to
> https://gi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
My name is Balasankar C. I am writing a module in Python and want to
package that for Debian. So, just to understand how packaging in python
work, I decided to package the module 'wget'. From my knowledge in
Ruby gem
packaging, I tried to packag
On Sep 21, 2010, at 03:02 PM, Clint Byrum wrote:
>In the java world, they use maven because it handles this for them.
>They create a maven spec file that says "I need libX, libY, and
>libZ (v1.1)". maven, during the build, goes out and finds libX and
>libY's latest versions, then finds the closest
[Clint Byrum, 2010-09-22]
> On Sep 21, 2010, at 3:26 AM, Piotr Ożarowski wrote:
> > but this way you cannot `import foo` anymore, you'll have to change all
> > import lines (s/foo/foo2/) even if your code is not affected by API change
>
> Because languages like python do runtime call resolution, t
On Sep 21, 2010, at 3:26 AM, Piotr Ożarowski wrote:
> [Simon McVittie, 2010-09-21]
>> On Tue, 21 Sep 2010 at 10:30:33 +0200, Piotr Ożarowski wrote:
>>> I see only one sane way to fix the problem - changing Python interpreter
>>> to recognize API from filenames, like foo.1.py foo.2.py foo.2.3.py
>
[Barry Warsaw, 2010-09-21]
> On Sep 21, 2010, at 10:30 AM, Piotr Ożarowski wrote:
> >I see only one sane way to fix the problem - changing Python
> >interpreter to recognize API from filenames, like foo.1.py foo.2.py
> >foo.2.3.py (with `import foo <= 2` as valid syntax) and let upstream
> >authors
On Sep 21, 2010, at 10:30 AM, Piotr Ożarowski wrote:
>[Robert Collins, 2010-09-20]
>> Path to a solution: use an API marker analgous to the ABI markers C
>> libraries have. Incompatible changes to a package bump the package
>> *name*. e.g.
>> python-zope.publication2.3 to python-zope.publication2.
[Simon McVittie, 2010-09-21]
> On Tue, 21 Sep 2010 at 10:30:33 +0200, Piotr Ożarowski wrote:
> > I see only one sane way to fix the problem - changing Python interpreter
> > to recognize API from filenames, like foo.1.py foo.2.py foo.2.3.py
> > (with `import foo <= 2` as valid syntax) and let upstr
On Tue, 21 Sep 2010 at 10:30:33 +0200, Piotr Ożarowski wrote:
> I'm not sure we should try to solve this. IMHO we should try to convince
> upstreams that breaking API/ABI so often is a bad thing instead.
... and that when they do, they need to rename the module with a version
number, just like C u
[Piotr Ożarowski, 2010-09-21]
> [Robert Collins, 2010-09-20]
> > Path to a solution: use an API marker analgous to the ABI markers C
> > libraries have. Incompatible changes to a package bump the package
> > *name*. e.g.
> > python-zope.publication2.3 to python-zope.publication2.4
> > Compatible ch
[Robert Collins, 2010-09-20]
> Path to a solution: use an API marker analgous to the ABI markers C
> libraries have. Incompatible changes to a package bump the package
> *name*. e.g.
> python-zope.publication2.3 to python-zope.publication2.4
> Compatible changes don't:
> python-zope.publication2.3-
: Fri, 20 Aug 2010 09:22:20 +1200
From: Robert Collins
To: Barry Warsaw
Subject: Python packaging, dependencies, upstream facilities
So, I'm going to give you a use case that debian packages suck at for
python (they don't for C) and how I see a path-to-a-solution.
If you were to make
On 21/04/10 05:01, Jakub Wilk wrote:
Who is your target audience? If you want this document to be read by
packaging newbies, then this document is terribly incomplete.
That, I believe, would be because of my very limited knowledge in the
field. Although I may not have explicitly said this initia
* Umang Varma , 2010-04-18, 08:30:
My general impression is that it's yet another (very) bad piece of
documentation. Feel free to ignore my opinion however, as I'm
already prejudiced. :P
It's hard to ignore your opinion (or for that matter, that of any DD
here). When you say very bad, it is cle
On Fri, Apr 16, 2010 at 06:15:20PM +0530, Umang Varma wrote [edited]:
> A few weeks back there was a small discussion I initiated on
> #debian-python about a guide for new-comers to learn about packaging
> Python applications and modules. I decided to update, restructure
A big bravo for the effort
On 18/04/10 10:58, Angel Abad wrote:
Great work! I dont like much cdbs, but thanks for the effort
Thanks. :) DktrKranz, themill and I had discussed neutrality. That line
of discussion (looking at the IRC logs now) got lost somewhere so I
eventually chose the middle path - presenting dh7
2010/4/16 Umang Varma :
> Hi,
>
> A few weeks back there was a small discussion I initiated on #debian-python
> about a guide for new-comers to learn about packaging Python applications
> and modules. I decided to update, restructure and add to a guide on the
> Ubuntu Wiki:
> https://wiki.ubuntu.co
On 18/04/10 01:01, Jakub Wilk wrote:
My general impression is that it's yet another (very) bad piece of
documentation. Feel free to ignore my opinion however, as I'm already
prejudiced. :P
It's hard to ignore your opinion (or for that matter, that of any DD
here). When you say very bad, it is c
Hello,
* Umang Varma , 2010-04-16, 18:15:
https://wiki.ubuntu.com/PackagingGuide/Python?action=recall&rev=11
My general impression is that it's yet another (very) bad piece of
documentation. Feel free to ignore my opinion however, as I'm already
prejudiced. :P
Okay, and here are some factu
Hi,
A few weeks back there was a small discussion I initiated on
#debian-python about a guide for new-comers to learn about packaging
Python applications and modules. I decided to update, restructure and
add to a guide on the Ubuntu Wiki:
https://wiki.ubuntu.com/PackagingGuide/Python?action=r
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
Jakub Wilk ha scritto:
>> * E: Don't hard-code {site,dist}-packages
>
> Uhm, what do you mean?
That's what we are trying to fix with
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-pyt...@lists.debian.org;tag=dist-packages
In case we missed some packages, or some NEW ones were included
Steve Langasek ha scritto:
>> * E: Don't hard-code {site,dist}-packages
>
> hard-coded where, and how will you detect this?
debian/rules and other control files such as debian/install and
debian/links.
>> * W: Build extension for every supported Python version
>
> how will you detect this?
Pa
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 thought of checking for f
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
>
* Luca Falavigna , 2009-11-02, 00:54:
I propose a non comprehensive list of tags I'd like to see available:
* E: Don't hard-code {site,dist}-packages
Uhm, what do you mean?
* E: Python files in incorrect python2.?/{site,dist}-packages directory
We need this check as soon as possible.
* I:
Luca Falavigna writes:
> I propose a non comprehensive list of tags I'd like to see available:
Thank you, I think this is a good start.
> * E: Don't hard-code {site,dist}-packages
> * E: Python files in incorrect python2.?/{site,dist}-packages
> directory
> * W: Build extension for every suppor
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
On Tue, Sep 15, 2009 at 03:21:41PM +0200, Alessandro Dentella wrote:
> On Tue, Sep 15, 2009 at 09:27:23AM +0200, Julian Andres Klode wrote:
> > On Tue, Sep 15, 2009 at 09:12:54AM +0200, Alessandro Dentella wrote:
> > > On Tue, Sep 15, 2009 at 07:02:23AM +0200, Adrian von Bidder wrote:
> > > > -> Po
Adrian von Bidder wrote:
> Reading only the first few messages:
> -> there was a BoF where something was discussed
> -> the Python Toolchain maintainer isn't doing his Job
> -> some ignore what was discussed/decided/requested/demanded at that BoF
> -> what this actually was and why is in the m
On Tuesday 15 September 2009 09.12:54 Alessandro Dentella wrote:
> there has been a fairly long thread with title 'XS-Python-Version vs
> pyversions ' some days ago, you may want to read it at:
>
> http://lists.debian.org/debian-python/2009/09/threads.html
Hmm.
Reading only the first few messa
On Tue, Sep 15, 2009 at 09:27:23AM +0200, Julian Andres Klode wrote:
> On Tue, Sep 15, 2009 at 09:12:54AM +0200, Alessandro Dentella wrote:
> > On Tue, Sep 15, 2009 at 07:02:23AM +0200, Adrian von Bidder wrote:
> > > -> Policy says I should ship my (private) modules in
> > > /usr/share/.
> > > H
On Tue, Sep 15, 2009 at 09:12:54AM +0200, Alessandro Dentella wrote:
> On Tue, Sep 15, 2009 at 07:02:23AM +0200, Adrian von Bidder wrote:
> > -> Policy says I should ship my (private) modules in /usr/share/.
> > How will Python find the modules?
>
> i guess you must patch your application to add
On Tue, Sep 15, 2009 at 07:02:23AM +0200, Adrian von Bidder wrote:
> Heyho!
>
> I'm fairly new to Python and absolutely new to packaging python stuff. So
> I'd be happy about a few comments [cc:s appreciated] or pointers to online
> resources (sorry, I'm working mostly offline, so I've not look
Heyho!
I'm fairly new to Python and absolutely new to packaging python stuff. So
I'd be happy about a few comments [cc:s appreciated] or pointers to online
resources (sorry, I'm working mostly offline, so I've not looked beyong the
python policy.)
My small application needs python3 (yes, I re
On mer, 2008-04-02 at 12:04 -0500, Steve M. Robbins wrote:
> The sequence shown in the build log indicates that no python-dev
> package is installed at all. This is due to another change made to
> support multiple python runtimes. The libboost-python-dev package
> used to depend on python-dev. N
[My knowledge of python is nearly zero - and I don't plan to subscribe
to -python]
On Wednesday 02 April 2008, Steve M. Robbins wrote:
> You might want to consider doing so; this allows you to be
> clear as to which version of python you support. Or, indeed,
> build support for both 2.4 and 2.
For the debian-python readers just joining in: the recent modification
of Boost to support multiple Python runtimes has some unintended
consequences; see bug #473973. Below are some questions for your
consideration.
On Wed, Apr 02, 2008 at 06:11:34PM +0200, Sune Vuorela wrote:
> If I ask specif
Thanks a lot to all of you, that clarified things for me!
On Wed, 16 Jan 2008 14:10:11 +0100 Josselin Mouette wrote:
> Le mercredi 16 janvier 2008 à 00:31 +0100, Eike Nicklas a écrit :
> > * Which value should the XS-Python-Version field have to ensure easy
> > transitions of future Python vers
Le mercredi 16 janvier 2008 à 00:31 +0100, Eike Nicklas a écrit :
> * Which value should the XS-Python-Version field have to ensure easy
> transitions of future Python versions? I tried using 'all', but then
> my (binary) package depended for example on python2.3-gtk2,
> python2.4-gtk2 and py
OoO En cette nuit striée d'éclairs du mercredi 16 janvier 2008, vers
02:29, Emilio Pozuelo Monfort <[EMAIL PROTECTED]> disait:
>> * For specifying supported Python versions, the policy recommends using
>> XS/B-Python, whereas the python-support documentation recommends
>> debian/pyversions. Wh
Eike Nicklas wrote:
> Hi Debian Python experts,
>
> I am currently trying to create Debian packages for a small python
> application I am writing. I thinks, this application is not yet ready
> for an official inclusion in Debian, but still, I have some questions
> about 'proper' packaging just out
1 - 100 of 156 matches
Mail list logo
