On Fri, Aug 16, 2024 at 11:02:18PM +0200, Philippe Cerfon wrote:
> Hey again
>
> On Fri, Aug 16, 2024 at 6:26 PM Philippe Cerfon wrote:
> > Still I fail to understand, where that auto-completed my-script-file
> > comes from in ptpython.
> > Any ideas what I'm doing wrong?
>
> Maybe it's not me d
pfs_split_exposures.py
lrwxrwxrwx 1 root root 33 Jun 25 00:44 /usr/bin/run-clang-tidy-16.py
-> ../lib/llvm-16/bin/run-clang-tidy
And all these names are also auto-completed in ptpython when trying to import.
Maybe what's left, though, are these py3compile calls, which - I guess
dh_python -
Hey Stefano.
(Thanks, also Andrey).
On Fri, Aug 16, 2024 at 9:47 AM Stefano Rivera wrote:
> > Is that even intended to work with dh_python?
>
> dh_python doesn't care what form your python package is in. It just
> looks for the metadata in .dist-info / .egg-info.
Then there
n package dependencies in a
> Debian package.
>
> Is that even intended to work with dh_python?
dh_python doesn't care what form your python package is in. It just
looks for the metadata in .dist-info / .egg-info.
So, if your package declares dependencies in in the packaging, an
On Fri, Aug 16, 2024 at 02:52:25AM +0200, Philippe Cerfon wrote:
> Hey.
>
> I'm already using dh_python for (Python) packages where I have a
> pyproject.toml with some [project.scripts] section and use
> python3-setuptools for building, which works quite nicely.
>
Hey.
I'm already using dh_python for (Python) packages where I have a
pyproject.toml with some [project.scripts] section and use
python3-setuptools for building, which works quite nicely.
Now I do have some standalone python scripts for which it makes not
much sense to make them (P
On Mon, Oct 11, 2021 at 12:23:31PM +, c.bu...@posteo.jp wrote:
> I am not sure if I misunderstand something or if the documentation is
> inconsistent.
>
> The PythonPolicy
> https://www.debian.org/doc/packaging-manuals/python-policy/
> tells me that dh_python should be the
Hi,
> I am not sure if I misunderstand something or if the documentation is
> inconsistent.
>
> The PythonPolicy
> https://www.debian.org/doc/packaging-manuals/python-policy/
> tells me that dh_python should be the preferred tool for packaging
> (https://www.debian.org/
Hello,
I am not sure if I misunderstand something or if the documentation is
inconsistent.
The PythonPolicy
https://www.debian.org/doc/packaging-manuals/python-policy/
tells me that dh_python should be the preferred tool for packaging
(https://www.debian.org/doc/packaging-manuals/python
On Mon, Mar 26, 2018 at 01:32:10PM +0200, Piotr Ożarowski wrote:
> http://people.debian.org/~piotr/dh_python3_without_dh-python.ddlist
I've fixed
Andreas Tille
iva (U)
kissplice (U)
python-biopython (U) [ only in Git due to some other issues ]
python-csb (U)
sphinxcontrib-au
On 04/01/2018 11:55 PM, Thomas Goirand wrote:
> On 03/26/2018 01:32 PM, Piotr Ożarowski wrote:
>> Hi,
>>
>> Here's a list of packages that will FTBFS soon if dh-python will not be
>> added to Build-Depends (it's time to drop dh-python from python3's
>> Depends and old version of dh_python2 from pyt
On 03/26/2018 01:32 PM, Piotr Ożarowski wrote:
> Hi,
>
> Here's a list of packages that will FTBFS soon if dh-python will not be
> added to Build-Depends (it's time to drop dh-python from python3's
> Depends and old version of dh_python2 from python package).
>
> http://people.debian.org/~piotr/d
[Matthias Klose, 2018-03-27]
> yes. please see below for a description of such packages. Or you might share
> the
> approach how you did construct those lists you posted.
I used codesearch.d.n¹, then downloaded JSON representation of that
search² and removed all packages that Build-Depend on dh-p
On 27.03.2018 18:39, Piotr Ożarowski wrote:
> [Matthias Klose, 2018-03-27]
>> On 26.03.2018 19:32, Piotr Ożarowski wrote:
>>> Hi,
>>>
>>> Here's a list of packages that will FTBFS soon if dh-python will not be
>>> added to Build-Depends (it's time to drop dh-python from python3's
>>> Depends and ol
[Matthias Klose, 2018-03-27]
> On 26.03.2018 19:32, Piotr Ożarowski wrote:
> > Hi,
> >
> > Here's a list of packages that will FTBFS soon if dh-python will not be
> > added to Build-Depends (it's time to drop dh-python from python3's
> > Depends and old version of dh_python2 from python package).
On 26.03.2018 19:32, Piotr Ożarowski wrote:
> Hi,
>
> Here's a list of packages that will FTBFS soon if dh-python will not be
> added to Build-Depends (it's time to drop dh-python from python3's
> Depends and old version of dh_python2 from python package).
>
> http://people.debian.org/~piotr/dh_p
Hi,
2018-03-26 17:03 GMT+02:00 PICCA Frederic-Emmanuel <
frederic-emmanuel.pi...@synchrotron-soleil.fr>:
> What about teaching cme how to fix packages build-depends.
>
or just mass-commit it inside DPMT/PAPT/OpenStack Team, which is vast
majority of Python packages :).
--
Best regards
Ondřej
Hi,
Le 26/03/2018 à 13:32, Piotr Ożarowski a écrit :
> Here's a list of packages that will FTBFS soon if dh-python will not be
> added to Build-Depends (it's time to drop dh-python from python3's
> Depends and old version of dh_python2 from python package).
>
> http://people.debian.org/~piotr/dh_
What about teaching cme how to fix packages build-depends.
this way a simple
cme fix dpkg
would do the job ?
On Mon, 26 Mar 2018 at 13:32:10 +0200, Piotr Ożarowski wrote:
> Here's a list of packages that will FTBFS soon if dh-python will not be
> added to Build-Depends (it's time to drop dh-python from python3's
> Depends and old version of dh_python2 from python package).
Is there a Lintian tag for this
Le lundi 26 mars 2018 à 13:32:10+0200, Piotr Ożarowski a écrit :
> Hi,
>
> Here's a list of packages that will FTBFS soon if dh-python will not be
> added to Build-Depends (it's time to drop dh-python from python3's
> Depends and old version of dh_python2 from python package).
>
> http://people.d
Hi,
Here's a list of packages that will FTBFS soon if dh-python will not be
added to Build-Depends (it's time to drop dh-python from python3's
Depends and old version of dh_python2 from python package).
http://people.debian.org/~piotr/dh_python3_without_dh-python.list
http://people.debian.org/~pi
On Mon, Jul 22, 2013 at 1:34 PM, Luca Falavigna wrote:
> 2013/7/22 anatoly techtonik :
>> Does that mean that helper to build Python packages is finally rewritten in
>> Python?
>
> Unrelated, but yes:
To me the fact that replacement for dh_python is written in Python is
2013/7/22 anatoly techtonik :
> Does that mean that helper to build Python packages is finally rewritten in
> Python?
Unrelated, but yes:
http://anonscm.debian.org/gitweb/?p=dh-python/dh-python.git;a=tree
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsu
l is gozerbot-plugins
> [1], which should be removed from the archive very soon. I'll make
> sure python-central will be dropped from Jessie as well, as soon as
> all reverse dependencies migrate.
>
> Also, dh_python is no longer used by any package in debian [2]. A bug
> again
[Vincent Bernat, 2013-07-21]
> Unrelated, but is pybuilder planned to hit unstable soon?
dh-python (which provides pybuild) will be uploaded to unstable once
current python3-defaults migrates to testing
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl
ns
> [1], which should be removed from the archive very soon. I'll make
> sure python-central will be dropped from Jessie as well, as soon as
> all reverse dependencies migrate.
>
> Also, dh_python is no longer used by any package in debian [2]. A bug
> against debhelper has
make
sure python-central will be dropped from Jessie as well, as soon as
all reverse dependencies migrate.
Also, dh_python is no longer used by any package in debian [2]. A bug
against debhelper has been filed asking to remove dh_python helper for
good [3]. A bug against lintian will be filed as so
On 08/13/2010 10:22 PM, Jakub Wilk wrote:
> We have currently 4 different Python helpers in the archive[0], which is
> about 3 too much. dh_python has been deprecated for almost 4 years, yet
> there are still ~80 packages that use it.
We definitely need to get rid of 3 of them, but this
On 13/08/10 22:22, Jakub Wilk wrote:
> We have currently 4 different Python helpers in the archive[0], which is
> about 3 too much. dh_python has been deprecated for almost 4 years, yet
> there are still ~80 packages that use it.
Debian GNOME Maintainers
gamin (U)
This is fixed i
We have currently 4 different Python helpers in the archive[0], which is
about 3 too much. dh_python has been deprecated for almost 4 years, yet
there are still ~80 packages that use it.
[0] There are also some packages that doesn't bytecompile their Python
modules at all. Or that just
l replacement)
> > > This is a huge task, and a complete waste of time. Don’t forget that
> > > most people that were motivated to work on Python packages are tired of
> > > endless changes that had to be done in hundreds of packages because of
> > > thoughtless cha
Le mardi 19 janvier 2010 à 20:45 +0100, Piotr Ożarowski a écrit :
> [Josselin Mouette, 2010-01-19]
> > Le vendredi 15 janvier 2010 à 11:58 +0100, Piotr Ożarowski a écrit :
> > > - starting/stopping daemons problems (very long downtimes due to byte
> > > compilation via triggers) in pysupport,
I know I'm coming in the middle of this, and I'm sure I don't understand all
the issues yet, but I'll chime in here anyway. :)
On Jan 19, 2010, at 10:39 AM, Josselin Mouette wrote:
>I’m also still wondering which exact problem this proposal is trying to
>fix. Currently the only thing it does seem
[Josselin Mouette, 2010-01-19]
> Le vendredi 15 janvier 2010 à 11:58 +0100, Piotr Ożarowski a écrit :
> > - starting/stopping daemons problems (very long downtimes due to byte
> > compilation via triggers) in pysupport,
>
> This is only a problem for daemons using namespace packages, which y
Le vendredi 15 janvier 2010 à 11:58 +0100, Piotr Ożarowski a écrit :
> Here's updated dh_python proposal. Main change since my last mail:
> pycompile/pyclean will no longer search for files to compile/remove
> in public directories as Matthias will fix #552595 using triggers so I d
[Jakub Wilk, 2010-01-15]
> You want to skip only directories without __init__.py and under
> /usr/lib/python*/*-packages/, right? That's fine.
yes (at least by default)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.de
> Here's updated dh_python proposal. Main change since my last mail:
> pycompile/pyclean will no longer search for files to compile/remove
> in public directories as Matthias will fix #552595 using triggers so I
> don't
> have to care about pycentral bugs anymore and
* Piotr Ożarowski , 2010-01-15, 16:08:
symlinks / private directories if given Python version is installed
(dpkg -L output will be used to detect which files need byte compilation,
directories without __init__.py file will be skipped),
IOW, you want to skip modules that are not a part of a pack
[Jakub Wilk, 2010-01-15]
> * Matthias Klose , 2010-01-15, 14:58:
symlinks / private directories if given Python version is installed
(dpkg -L output will be used to detect which files need byte compilation,
directories without __init__.py file will be skipped),
>>>
>>> IOW, you want
* Matthias Klose , 2010-01-15, 14:58:
symlinks / private directories if given Python version is installed
(dpkg -L output will be used to detect which files need byte compilation,
directories without __init__.py file will be skipped),
IOW, you want to skip modules that are not a part of a packa
On 15.01.2010 11:58, Piotr Ożarowski wrote:
* no need for helper in Depends and Build-Depends - I want dh_python and
pycompile/pyclean to be shipped in python packages,
agreed. once these helper tools are mature for unstable/experimental, please add
yourself as an uploader to python
[Piotr Ożarowski, 2010-01-15]
> [Luca Falavigna, 2010-01-15]
> > Piotr Ożarowski ha scritto:
> > > byte compilation will not fail as it was already tested at build time,
> >
> > What about cases when code is no longer supported in a given Python
> > release? I think of "except YourFavouriteExc
On 15.01.2010 14:27, Jakub Wilk wrote:
* Piotr Ożarowski , 2010-01-15, 11:58:
* maintainer script will byte compile .pyc files for all provided
symlinks / private directories if given Python version is installed
(dpkg -L output will be used to detect which files need byte compilation,
directorie
On 15.01.2010 14:19, Luca Falavigna wrote:
* broken modules that use __file__ incorrectly will work without problems,
OK, I'd still warn loudly if that happens, though.
there are other cases where some modules/extensions do encode paths in generated
"config" files, like sip and the qt/kde bi
[Jakub Wilk, 2010-01-15]
> * Piotr Ożarowski , 2010-01-15, 11:58:
>> * maintainer script will byte compile .pyc files for all provided
>> symlinks / private directories if given Python version is installed
>> (dpkg -L output will be used to detect which files need byte compilation,
>> directorie
[Luca Falavigna, 2010-01-15]
> Piotr Ożarowski ha scritto:
> > * no need for helper in Depends and Build-Depends - I want dh_python and
> > pycompile/pyclean to be shipped in python packages,
>
> It is not clear to me how to achieve this.
Matthias promised to lend me
* Piotr Ożarowski , 2010-01-15, 11:58:
* maintainer script will byte compile .pyc files for all provided
symlinks / private directories if given Python version is installed
(dpkg -L output will be used to detect which files need byte compilation,
directories without __init__.py file will be sk
Piotr Ożarowski ha scritto:
> * no need for helper in Depends and Build-Depends - I want dh_python and
> pycompile/pyclean to be shipped in python packages,
It is not clear to me how to achieve this.
> * broken modules that use __file__ incorrectly will work without problems,
OK,
Here's updated dh_python proposal. Main change since my last mail:
pycompile/pyclean will no longer search for files to compile/remove
in public directories as Matthias will fix #552595 using triggers so I don't
have to care about pycentral bugs anymore and dpkg -L seems to be fast en
FTR: Joss and few other maintainers (whose opinion I care about) didn't
like my proposal (mainly due to binNMUs for arch:all packages) so I'm not
working on this new tool. I planed to start working on it once we'll
agree how it should look like. There's no consensus so I'm focusing on
preparing all
Kumar Appaiah wrote:
> On Tue, Aug 04, 2009 at 12:00:09PM -0400, anatoly techtonik wrote:
>> Now about the proposal (from newcomer's point of view):
>> dh_python is a shell script -- I have a strong belief that Python
>> package automation scripts should be written in P
[Matthias Klose, 2009-08-20]
> On 03.08.2009 19:16, Piotr Ożarowski wrote:
> >* about lack of XS-Python-Version and debian/pyversions
> > - if available, both previous places will be used to get
> > minimum/maximum required Python version, it will complicate
> > detection of packages that
ng able to list all files provided by packages is something we
really want to have
packaging the zope tree by choosing existing packages to include the __init__.py
files did work well. Afaik there's no other package in debian not shipping
files, and then creating these.
* dh_python
hould be explained symmetrically for both communities.
> The chances for Debian Python Packaging experts to pop up are
> magnitude less if we won't explain the situation in detail.
see chapter 6[9] of "Manoj's policy"[1]
[9] http://people.debian.org/~srivasta/manoj-pol
On Tue, Aug 04, 2009 at 12:00:09PM -0400, anatoly techtonik wrote:
> Now about the proposal (from newcomer's point of view):
> dh_python is a shell script -- I have a strong belief that Python
> package automation scripts should be written in Python, there is no
> need to lear
pop up are
magnitude less if we won't explain the situation in detail.
Now about the proposal (from newcomer's point of view):
dh_python is a shell script -- I have a strong belief that Python
package automation scripts should be written in Python, there is no
need to learn bashes when you pro
mething we
really want to have
* dh_python[1] will try to avoid moving files to pyshared if
package supports only one Python version (f.e. the latest one)
* py{,3}compile will support -X/--exclude option
I maintain one module that uses site-packages to keep templates with
.py files
will have to be provided, just like we did before pysupport 0.7. Otherwise
removing .pyc files will not be a trivial thing to do. Note that there are lots
of problems with this feature anyway (upstreams tend to use site-packages for
things that don't belong there), so removing it will improve the si
Hi Craig,
thanks for contacting us (python modules/apps team).
On Thu, Mar 12, 2009 at 08:02, Craig Small wrote:
> On Tue, Aug 05, 2008 at 09:20:47PM +0300, Jari Aalto wrote:
>> Packaging with dh-make using "single" choice, the generated
>> debian/control includes
On Tue, Aug 05, 2008 at 09:20:47PM +0300, Jari Aalto wrote:
> Packaging with dh-make using "single" choice, the generated
> debian/control includes deprecated dh_python line. During the deb
> making this is shown in message:
>
> dh_python: This program is deprecated, yo
Manoj Srivastava <[EMAIL PROTECTED]> writes:
>Copyright (c) 2006 Manoj Srivastava
>
>Revision History
>Revision 1.0.5 4^th November 2006
Setember?
--
O T A V I OS A L V A D O R
-
to the statement "Oh, just
run dh_python". This is my attempt to offer more concrete tips for
packaging. While this document started by reverse engineering dh_python,
it has, thanks to help from various people more knowledgeable about Python
than I, moved beyond that, and is c
Hi,
On Tue, 22 Aug 2006, Floris Bruynooghe wrote:
> > The changes needed in dh_pysupport are trivial. As of version 0.4, it
> > handles dependencies in more cases than dh_python, and does it only if
> > debian/pycompat isn't found. The only thing to do is to remove this
>
Le mar 22 août 2006 01:00, Josselin Mouette a écrit :
> > > * -V is a redundant interface, since it does something
> > > approximating what debian/pyversons does. So things should be
> > > able to switch to the other interface, except in edge cases
> > > (although IMHO it's not an appropriate in
On Tue, Aug 22, 2006 at 01:00:45AM +0200, Josselin Mouette wrote:
> Le mercredi 16 août 2006 à 16:21 +0200, Raphael Hertzog a écrit :
> > As I can understand him, we really should respect his wish. If Matthias
> > agrees,
> > I can extract the "dependency" gen
Le mercredi 16 août 2006 à 16:21 +0200, Raphael Hertzog a écrit :
> As I can understand him, we really should respect his wish. If Matthias
> agrees,
> I can extract the "dependency" generation code from dh_python and create
> a little perl library that would be included
On 8/20/06, Pierre Habouzit <[EMAIL PROTECTED]> wrote:
Le dim 20 août 2006 09:48, Cameron Dale a écrit :
> E: bittornado: python-script-but-no-python-dep
> ./usr/bin/bttrack.bittornado
this is a lintian "bug". when you simply need to depend upon python (not
versionned) as python-support and pyth
Le dim 20 août 2006 09:48, Cameron Dale a écrit :
> I'm currently working on updating my package to use python-support,
> and I'm having problems with the dependencies it's generating. I've
> removed dh_python from my rules file and deleted debian/pycompat so
> that
I'm currently working on updating my package to use python-support,
and I'm having problems with the dependencies it's generating. I've
removed dh_python from my rules file and deleted debian/pycompat so
that only dh_pysupport is generating the ${python:Depends}. However,
when
Raphael Hertzog wrote:
> As I can understand him, we really should respect his wish. If Matthias
> agrees,
> I can extract the "dependency" generation code from dh_python and create
> a little perl library that would be included in the python package
> (or python-dev)
Hello everybody,
as you might have seen on Joey's blog, he expressed some wishes about the
future of dh_python:
http://kitenet.net/~joey/blog/entry/proposed_transition_plan_for_removal_of_dh_python_from_debhelper.html
As I can understand him, we really should respect his wish. If Matthias a
Hi,
I have some more thoughts to offer on the example Steve
presented: in essence, he is talking about a package that has become
incompatible with the version that was in stable.
On Sun, 13 Aug 2006 23:03:13 -0700, Steve Langasek <[EMAIL PROTECTED]>
said:
> On Sun, Aug 13, 2006 at 0
On Sun, 13 Aug 2006 23:03:13 -0700, Steve Langasek <[EMAIL PROTECTED]> said:
> On Sun, Aug 13, 2006 at 07:56:09PM -0500, Manoj Srivastava wrote:
>> OK, I see I have to dot the i's and cross the t's for this case
>> here. So, here is the scenario: package python-foo packages a
>> public pure pyth
On Sun, Aug 13, 2006 at 07:56:09PM -0500, Manoj Srivastava wrote:
> OK, I see I have to dot the i's and cross the t's for this
> case here. So, here is the scenario: package python-foo packages a
> public pure python module. Package bar imports the module
> foo. Package baz is a packa
On Mon, 14 Aug 2006 11:21:07 +1000, Robert Collins <[EMAIL PROTECTED]> said:
> On Sun, 2006-08-13 at 19:56 -0500, Manoj Srivastava wrote:
>> Here there are two cases. Either module foo can't be written at all
>> for version 2.6, or it the same functionality can be provided with
> This is a littl
On Sun, 13 Aug 2006 23:37:15 +0200, Pierre Habouzit <[EMAIL PROTECTED]> said:
> Le dim 13 août 2006 22:17, Manoj Srivastava a écrit :
>> As to the BOF thing, I'll bite: Why one earth did the bof
>> come up with design decisiosn that require every single goldarned
>> python module package
On Sun, 2006-08-13 at 19:56 -0500, Manoj Srivastava wrote:
>Here there are two cases. Either module foo can't be written at all
>for version 2.6, or it the same functionality can be provided with
This is a little simplistic.
The parser changes fairly routinely in python versions. This me
Hi,
OK, I see I have to dot the i's and cross the t's for this
case here. So, here is the scenario: package python-foo packages a
public pure python module. Package bar imports the module
foo. Package baz is a package not yet written that would be written
for Python2.6 that would als
Le dim 13 août 2006 22:17, Manoj Srivastava a écrit :
> As to the BOF thing, I'll bite: Why one earth did the bof come
> up with design decisiosn that require every single goldarned python
> module package to be reuploaded every time a new version of python
> is added or removed?
actuall
On Sun, 13 Aug 2006 10:28:43 -0700, Steve Langasek <[EMAIL PROTECTED]> said:
> On Sun, Aug 13, 2006 at 03:32:27AM -0500, Manoj Srivastava wrote:
>> On Sun, 13 Aug 2006 00:01:37 -0700, Steve Langasek
>> <[EMAIL PROTECTED]> said:
>> > On Sat, Aug 12, 2006 at 12:10:07PM -0500, Manoj Srivastava wrot
On Sun, Aug 13, 2006 at 03:32:27AM -0500, Manoj Srivastava wrote:
> On Sun, 13 Aug 2006 00:01:37 -0700, Steve Langasek <[EMAIL PROTECTED]> said:
> > On Sat, Aug 12, 2006 at 12:10:07PM -0500, Manoj Srivastava wrote:
> >> >> 3.1.3. Provides
> >> >> Packages with public modules and extensions shoul
On Sun, 13 Aug 2006 00:01:37 -0700, Steve Langasek <[EMAIL PROTECTED]> said:
> On Sat, Aug 12, 2006 at 12:10:07PM -0500, Manoj Srivastava wrote:
>> >> 3.1.3. Provides
>> >>
>> >> Packages with public modules and extensions should be named, or
>> >> should provide, python-foo. Pure Python public
On Sat, Aug 12, 2006 at 12:10:07PM -0500, Manoj Srivastava wrote:
> >> 3.1.3. Provides
> >>
> >> Packages with public modules and extensions should be named, or
> >> should provide, python-foo. Pure Python public modules that support
> >> all Python versions need not have a Provides field.
> > .
h all Python version, the range of versions supported should be
>> used [34][4]
>>
>> * For packages with public modules, this should be set to the
>> string "all" (or "-", in the case of debian/pyversions), unless not
>> all versions of Python are
he developer to explicitely pass
> the directory containing the extension module.
IMHO current and current_ext are choices of implementations of
pycentral, which your following explanations truly underline.
[snip]
> > 3.1.2. Depends:
> >
> > The rules for calculatin
Le sam 12 août 2006 17:34, Matthias Klose a écrit :
> dh_pysupport doesn't
> use this information, but requires the developer to explicitely pass
> the directory containing the extension module.
that's not completely true, it only searches in /usr/lib/$pkg,
/usr/share/$pkg, /usr/lib/games/$pkg an
;-", in the case of debian/pyversions), unless
> not all versions of Python are supported (in which case the
> setting should specify the versions or range of versions actually
> supported, like ">= 2.4" or ">= 2.2, << 2.y&q
Le mardi 08 août 2006 à 14:33 -0500, Joe Wreschnig a écrit :
> > * current has not a constant meaning, as it depends of the state of the
> >package python-defaults, and not only of the state of the archive
> >when the package was uploaded. This is IMHO the biggest flaw of that
> >field
Le mar 8 août 2006 21:33, Joe Wreschnig a écrit :
> It's possible to build Python modules for all versions with only
> python-dev, if they are pure Python modules (feedparser is such a
> package, its dependency on python-all-dev is extraneous and could be
> just python-dev). So simply looking at th
Le mer 9 août 2006 01:33, Manoj Srivastava a écrit :
> Hi,
>
> Another day, another draft.
>
> Here is the latest update for my take on the new Python
> policy document. The current version, and future updates, are to be
> found at http://www.golden-gryphon.com/software/manoj-pol
policy, specifically the [1]"Packaged Modules" chapter, contains the
elements that must be present in the debian/control filename, it is not
very explicit about how the values are to be substituted. The Debian Wiki
falls back on calling dh_python, which is not helpful in underst
On Tue, 2006-08-08 at 13:41 +0200, Pierre Habouzit wrote:
> Le mar 8 août 2006 00:18, Pierre Habouzit a écrit :
> current explicitely says that the package is only built for the current
> python version, and not for any other supported in debian. But I don't
> like that value for the following re
Le mar 8 août 2006 00:18, Pierre Habouzit a écrit :
> § 2.3.3, 2.4.2, 2.5.3, 2.6.2:
> *here* the python$version alternative is correct,
> because /extensions/ can be used with a '/usr/bin/python' as soon
> as the python current version is in their supported range.
>
> so take the previous a
s for python-central and python-support, and incorporated my
> understanding of those into this document.
>
> So, this is my take on the new python policy, based on the
> analysis of the new Python policy draft and dh_python, and is
> supposed to be a rough specification of wh
policy, based on the
analysis of the new Python policy draft and dh_python, and is
supposed to be a rough specification of what the python policy is
supposed to be (based on current dh_python behaviour). The current
analysis, and future updates, are to be found at
http://www.golden-gryphon.com
It is curious that you say that, since I have not yet looked
> at pycentral, what you see here is derived ojnly from reading the
> draft policy in detail and then reverse engineering what dh_python
> does.
This is because python-central's internals use the control file.
>
On Tue, Aug 01, 2006, Manoj Srivastava wrote:
> Could you point me to documentation on python-support, what it
> does, how to use it, and how it differs from python-central?
Well, python-support is documented at the expected
/usr/share/doc/python-support and in the dh_pysupport man page
On Tue, 1 Aug 2006 09:35:56 +0200, Loïc Minier <[EMAIL PROTECTED]> said:
> On Mon, Jul 31, 2006, Manoj Srivastava wrote:
>> 2.1. [5]XS-Python-Version: 2.2. [6]XB-Python-Version:
> Your document keeps mentionning these, even as "requirements", but
> XB- isn't required for packages using python-
should also have a line:
| XB-Python-Version: ${python:Versions}
| The python:Versions is substituted by the supported Python versions of
| the binary package, based on XS-Python-Version. (If you are not using
| dh_python you will need to handle this substitution yourself.) The
| format of the field
1 - 100 of 168 matches
Mail list logo
