Re: Bug#415844: ITP: python-fpconst -- Utilities for handling IEEE 754 floating point special values
Heya, > > Just these days I've hijacked the python-soappy package, with the > agreement of the python-modules team since Ed did not reply to their > ping a long time ago. > > See http://lists.debian.org/debian-python/2007/03/msg00042.html. > He had replied to me within a few days, I missed to post it to d-py, though. > My python-soappy package is ready and you can find the current version > in the svn repository of the alioth project 'python-modules'. I was > going to upload in a few days. > > Please do not fork the effort. > not a problem at all, all I did was to get the last NMUs ready and done. > What about you packaging fpconst and integrate the needed changes in my > starting version of a new python-soappy package? > If it's ok with you I'll fpconst and edit your packaging in svn accordingly. I need to get an account on Alioth first, though. Depending on how long that will take I'll probably just mail you a patch Cheers, -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Any interest in the PDIS-Xpath module?
Heya, one of the dependencies of Zenoss (ITP #361253) is the PDIS-Xpath module ([1], [2]). Upstream does not develop on it anymore, but is willing to fix any bugs. According to the author it is not widely used, so I'd like to know if there's any interest to see this as package in Debian. If not, I'll just package it together with Zenoss. Cheers, Bernd [1] This is a pure-Python XPath evaluator based on ElementTree. It supports a substantial fraction of the XPath 1.0 specification, notwithstanding the limitation that only the self, child, and attribute axes are supported. The parser underlying the evaluator attempts to handle all of XPath 1.0. [2] http://pdis.hiit.fi/pdis/download/ -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where to install non-debianized python modules?
Heya, > > Try: python setup.py --prefix=/usr/local > > More info is available in "Installing Python Modules", available at /usr/ > share/doc/python/html/inst/ if you install the python-doc package, or > online at <http://docs.python.org/inst/inst.html>. > and if you want to avoid a messy /usr/local, consider to use stow to manage it. As this module seems to be pretty useful for you should also consider to post a RFP (request for packaging) bug against the pseudo-package wnpp (see [1]). I'm quite happy that you've posted the link to pypedal, as I was searching for such modules for a new open source project, so I'm probably willing to package it, but as I won't find the time to work myself into the whole theme, test the module and package it. If you send in a RFP, probably somebody else will package it, or I'll have a look at it when I start with the project - which won't be this summer. Cheers, Bernd [1]: http://www.debian.org/devel/wnpp/#l1 -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-imaging 1.1.6
> I was sondering why python-imaging is frozen to version 1.1.5 even in sid. > Version 1.1.6 came out six months ago, and Ubuntu Feisty has package for > it (same mantainer of debian) since december... I guess the maintainer is waiting for unknown reasons until the new python2.5 package is built on _all_ architectures. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new upstream versions of DPMT's packages
Hi, > uscan detected some new upstream versions of packages maintained within > the team (see below). My question is: how can I help you with uploading > these new versions into Debian? If there are any problems, please ask on > the mailing list or on #debian-python channel. > seems you've setup a cronjob to check for the pacakges? Some weekly or monthly output to the -team list would be nice to have in my opinion. Also I can take care of pyusb, I'm listed as Uploader anyway. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new upstream versions of DPMT's packages
> For now it runs only on my local machine, here's the command: > > $ uscan --check-dirname-level 0 --report python-modules/packages/*/trunk/ > that would mean I'd have to checkout all modules, I wanted to avoid that. > >> Also I can take care of pyusb, I'm listed as Uploader anyway. >> > > ping me on #debian-python when you will need an upload > > sure, will do so. Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Full checkout with svn:externals
> BTW, I discovered that there might be a way to checkout everything out of > trunk without extracting tags and branches. The idea would be to have a > directory all-packages with the property "svn:externals" listing all the > trunk of all packages: > http://svnbook.red-bean.com/en/1.0/ch07s03.html > > Might be worth considering... and documenting so that people add the new > packages there as well. > that's a really good idea! But I think managing the svn:externals property could be done by a cronjob - at leat I hope so, I've never ried to modify svn properties by a script. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: preparing for python2.5 / python -dbg packages
> python version for lenny. Still hoping to drop support for 2.4 once a > zope2.x version supporting 2.5 is released... Today I heard that opensuse run Zope with python 2.5 since Zope version 2.9.4. Did anybody ever try to run Zope in 2.5? If there's something not working, we should take care of it. TOday I've suggested to organize a session in Extremadura to the Zope developers[1] - probably something liek that would be useful for the python team, too? Merging python-support and -central would be a good idea probably, although that would require to have both authors around ;) I didn't look for other stuff that needs to be done, so just take it as a suggestion. Cheers, Bernd [1] http://lists.alioth.debian.org/pipermail/pkg-zope-developers/2007-July/003489.html -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: preparing for python2.5 / python -dbg packages
> Did they ever actually run the tests then? > > no clue, I know why I'm not using suse ;) > http://archives.free.net.ph/message/20070616.183425.b42a7509.en.html#zope-zodb-dev > > That mail was just over a month ago. > as I understand one of the mails in the thread this problem seems to be solved in one of the latest dev versions, we should keep an eye on it. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: modpython and python2.5
Hi, > Then I changed the simlink of /usr/bin/python to python2.5 > and then: > pycentral updatedefault python2.4 python2.5 > > But modpython still loads python2.4. I have also copied modpython directory > from the sitepackages to python2.5/sitepackages > > Please, I really need help on this. I have a web down, and I have no idea > what > to do. > First please note that python 2.5 is NOT supported in Etch, so it may work, or not. YMMV. You need to rebuild mod-python for new python versions. try apt-get -b source libapache2-mod-python Install the resulting package. If it will work at all - no clue. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python Egg Guidelines across distros
> The most obnoxious things in setuptools, like automatic downloading of > dependencies at runtime and shipping everything in egg files that have > to be all decompressed on-the-fly by any python application being run, > were deactivated in Debian. (I can't imagine an operating system where > these would be good ideas, but well... not our problem.) I've allready seen logs from our buildds where setuptools tried to download eggs from the net for various reasons That's clearly somethin we don't want to have. My way to get rid of the trouble when packaging a python module is usually to patch setup.py to get rid of setuptools and use distutils instead. I'm not the only one who thinks like that, for example the developers from Zenoss got rid of setuptools completely, as it made more trouble than anything else. In my opinion there's no need for more than one tool for setup.py. Distuils may have bugs, but they can be fixed. The egg and 'I'm better than your systems package manager' features of seuptools are something sane people should get rid of - YMMV. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
> That's where the distutils and setuptools place them by default, > yes. I don't know what magic is required to put them elsewhere; that > may be part of the answer, if someone can instruct me on how to do it. You shoul dupload your work somewhere, "teaching" you is almost impossible if one can't see what's wrong. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
> If the policy recommends that packages be set up a particular way
> ("put package-specific modules in '/usr/share/package/'"), but the
> standard tools behave differently ("put all modules by default in
> '/usr/lib/pythonX.Y/site-packages/'"), then there's a step that needs
> to be taken to get from the default behaviour to the behaviour
> recommended by policy.
The standard tools Do it right. So there must be a bug somewhere in your
packaging or upstream's source. Unfortunately this bug is not shown in
my fishbowl.
You can read trough http://wiki.debian.org/DebianPython/NewPolicy and
check if your packaging contains all the pieces mentioned there. If you
think it does, show your code.
--
Bernd Zeimetz
<[EMAIL PROTECTED]> <http://bzed.de/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
> As an example, here's a Python package I'm trying to get packaged for
> Debian. (I am the upstream author of this one, but I'm interested in a
> solution that *doesn't* involve significant changes to the upstream
> code.)
>
> http://cheeseshop.python.org/pypi/gracie/>
The first thing I'd do here is to patch the ez_ stuff away, together
with setuptools. ez_... is known to break things badly (like trying to
download things on buildds and other really broken things). Setuptools
is broken by design imho (see a thread some time ago about this), but it
may work. But as I run into trouble with it too often (like missing
__init__.py files in random directories), I replace it by distutils.
Since we're not building eggs there's not need for setuptools at all
(afaik distutils is able to build eggs now, too - at least the egg info
files, which is enough for us).
Better to patch those things before getting FTBFS reports form the buildds.
Although I didn't test it, there should be no special thign to do with
your setup.py while building a package, python setup.py build/install
--root= should do the job (with and without ez_... and setuptools).
http://svn.debian.org/wsvn/python-modules/packages/python-contract/trunk/debian/rules?op=file&rev=0&sc=0
is a pretty simple debian/rules file, which also tries to build the
package for all python versions and runs the tests to ensure nothing is
buggy.
If you like it really simple, cdbs is something you can use:
http://svn.debian.org/wsvn/python-modules/packages/ll-core/trunk/debian/rules?op=file&rev=0&sc=0
Aa you can see on the cdbs example, sometimes upstream does not install
all files in the way one would like it to have in debian, often out of
personal taste - that's easy to fix though. Although at least I
appreciate if upstras isntalls everything at the proper place, at least
distutils supports installing completely non-py related files into the
right directories.
Depending on what you like you have to call dh_py{central,support} to
move your installed files in their directories, of course you need to
add the neccessary informations for them at the apropriate places (like
which python versions you want to support).
> How should I construct the command line for 'setup.py' when I create
> the 'install-python%' target in 'debian/rules' for this package?
Have a look at the first example.
Both will work for arch: all and arch: any packages. For arch: all
packages you don;t need to build/install with all python versions, just
using the default one is enough, everythign else will be handled by
python-support/central while installing the package. It makes sense to
build them all, though, especially when you want to run tests.
Hope that helps,
Bernd
--
Bernd Zeimetz
<[EMAIL PROTECTED]> <http://bzed.de/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tool support for private modules
> > I'm confused, then. How does this fit with the implication (in the > above quoted teset) that upstream should have "thought of [changing > the location of the modules]"? If downstream hackery is required, I > don't see what upstream is expected to have done. > > That is imho nothing upstream needs to take care of. PYTHONPATH needs to include the directory where the modules are installed, and that's something downstream needs to take care of. If you 'import yourmodule' in your program, Python will know how to find. http://docs.python.org/inst/inst.html is probably interesting to read for you. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Report on the situation of python2.5 in Debian
Hi, > Now, for the bad news. The following packages have various kinds of > issues that prevent them from working with python2.5. Some of them are > trivial, some are much more tricky. In all cases, we need to focus on > these bugs if we want to see those packages in lenny: You have missed Zope. It is not possible to run Zope 2.X with Python 2.5 yet, same for Zope 3. The problems in there are nothing a maintainer could fix, except somebody is willing to pay several days (weeks!?) of work. Changing the default python version also means to go trough all Zope packages and replace /usr/bin/python by /usr/bin/python2.4. > The following packages do not support multiple versions of python at > once. This is where we have the most serious regression compared to the > situation of the python2.4 transition. It is understandable not to > rebuild the gimp or OpenOffice.org packages for several python versions, > but many of these packages are using distutils and are therefore > *trivial* to get to work with several versions. Does the list include those packages which are not conform to the new Python policy? There're still several of them out there. A zero-day NMU policy would be good to have here, too. http://bugs.debian.org/from:[EMAIL PROTECTED];pend-exc=done;exclude=fixed > Please note that they can all be binNMUed after python2.5 has become the > default, but all of them will have to migrate to testing at once. We > must make this list shorter unless we want this transition to recall bad > memories to the release team. > mod-wsgi It's not possible to use more than one python version with mod-wsgi, therefore it will only work and be build against the default python version. A binNMU after changing the version should work well. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Report on the situation of python2.5 in Debian
>>> Please note that they can all be binNMUed after python2.5 has become the >>> default, but all of them will have to migrate to testing at once. We >>> must make this list shorter unless we want this transition to recall bad >>> memories to the release team. >>> mod-wsgi >> It's not possible to use more than one python version with mod-wsgi, >> therefore it will only work and be build against the default python >> version. A binNMU after changing the version should work well. > > yes, for some packages it makes sense, Joss didn't asked for an empty > list, merely a shorter one, and I agree with him. I agree with him, too - just wanted to make sure nobody tries to "fix" mod-wsgi. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Report on the situation of python2.5 in Debian
Josselin Mouette wrote: > Le vendredi 05 octobre 2007 à 20:42 +0200, Bernd Zeimetz a écrit : >> You have missed Zope. >> It is not possible to run Zope 2.X with Python 2.5 yet, same for Zope 3. >> The problems in there are nothing a maintainer could fix, except >> somebody is willing to pay several days (weeks!?) of work. >> Changing the default python version also means to go trough all Zope >> packages and replace /usr/bin/python by /usr/bin/python2.4. > > My guess is that must have already been done, because all zope packages > (except those I have listed) already depend on python2.4. They depend on python2.4, but I'm pretty sure a lot of them use #!/usr/bin/python, unfortunately. I'm forwading the mail to the Zope lsit therefore. >> Does the list include those packages which are not conform to the new >> Python policy? There're still several of them out there. A zero-day NMU >> policy would be good to have here, too. >> http://bugs.debian.org/from:[EMAIL PROTECTED];pend-exc=done;exclude=fixed > > AFAICT the remaining packages shouldn't prevent python2.5 to migrate to > testing. Still, these bugs also deserve a 0-day NMU policy indeed. As far as I remember several of them were supposed to be orphaned anyway, removing instead of fixing would be the way for them. >>> mod-wsgi >> It's not possible to use more than one python version with mod-wsgi, >> therefore it will only work and be build against the default python >> version. A binNMU after changing the version should work well. > > I think it should be possible, by building several versions and using a > rtupdate hook to change a symbolic link pointing to one of them. Probably I'll implement that, and provide a module for every python version. That's something I have to talk trough with upstream first, though. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Report on the situation of python2.5 in Debian
Josselin Mouette wrote: > Le samedi 06 octobre 2007 à 09:07 +0200, Josselin Mouette a écrit : >> Le vendredi 05 octobre 2007 à 20:04 +0200, Josselin Mouette a écrit : >>> The following packages should also work with python2.5 after a round of >>> binNMUs, as some dependencies were relaxed in python-support 0.7.4: >>> dia >>> exaile >>> k3d >> You can add: >> mod-wsgi >> which in fact enters in this category. > > Or not. These dependencies are explicitly added by debian/rules for no > reason. Sorry , but there is a very good reason to do so: If the default python version changes running applications with mod-wsgi will badly fail. Therefore it depends in a relaxed way (python <<2.5, but >=2.4) on the actual default python version which was used to build the package. If you rebuild it with python2.5 as default python version, it'll just add the right dependencies. This was tested on Ubuntu and works well. It's nothing but an extra safety to stop people from upgrading python or mod-wsgi, they need to be upgraded both. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Report on the situation of python2.5 in Debian
Bernd Zeimetz wrote: > Josselin Mouette wrote: >> Le samedi 06 octobre 2007 à 09:07 +0200, Josselin Mouette a écrit : >>> Le vendredi 05 octobre 2007 à 20:04 +0200, Josselin Mouette a écrit : >>>> The following packages should also work with python2.5 after a round of >>>> binNMUs, as some dependencies were relaxed in python-support 0.7.4: >>>> dia >>>> exaile >>>> k3d >>> You can add: >>> mod-wsgi >>> which in fact enters in this category. >> Or not. These dependencies are explicitly added by debian/rules for no >> reason. > > Sorry , but there is a very good reason to do so: If the default python > version changes running applications with mod-wsgi will badly fail. > Therefore it depends in a relaxed way (python <<2.5, but >=2.4) on the > actual default python version which was used to build the package. If > you rebuild it with python2.5 as default python version, it'll just add > the right dependencies. This was tested on Ubuntu and works well. It's > nothing but an extra safety to stop people from upgrading python or > mod-wsgi, they need to be upgraded both. -> it needs to be binNMUed AFTER changing the default python version. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Report on the situation of python2.5 in Debian
> Which is quite annoying for the transition of python to testing. > > I have sent you a multi-build patch for mod-wsgi. As you can see, it > isn't that complicated. And for most packages in the list, the required > changes are much simpler. I indeed didn't know about rtupdate - it seems to be missing on http://www.debian.org/doc/packaging-manuals/python-policy/ Google found it in http://people.debian.org/~srivasta/manoj-policy/index.html which is not a quite obvious place for a documentation. Thanks for the patch, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Report on the situation of python2.5 in Debian
> Given the number of packages that don't follow the policy or declare > wrong values in XS-Python-Version, for most packages it was possible to > decide only by looking at debian/rules by hand. Policy does not require to set XS-Python-Version except for pycentral - at least that's how Manoj[1] and myself seem to understand [2]. It is only appreciated to set it for all packages. It would make sense to make setting XS_Python-Version a must or all packages which wouldn't have 'all' in there. Cheers, Bernd [1]: http://people.debian.org/~srivasta/manoj-policy/x316.html#AEN328 [2]: http://wiki.debian.org/DebianPython/NewPolicy -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PyGPU
> BTW: join DPMT[1] - we will try to help you maintain this package also join #debian-python on OFTC - home of DPMT and also a good place to get all kinds of related questions answered fast ;) -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gaphor package depends on zope
Hi, > I think zope.interface is already available as a separate package, > python-zopeinterface, which is self-contained. > > Perhaps similar thing can be done to zope.component? Without looking more deep into it, that should be possible. You want to file a wishlist bug against Zope3. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging software for Cheeseshop and Debian
> I develop and package webcheck [0] (a python application with private > modules). I put all stuff in /usr/share/webcheck and use python-support > for compiling the stuff there. I ship an /usr/bin/webcheck symlink > to /usr/share/webcheck/webcheck.py. This seems to work fine. You can also drop a python script to /usr/bin directly - python doesn;t try to create .pyc files there, even when runnign as root. >>> I don't know if setuptools or distutils supports packaging private >>> modules. >> Then what is meant by the Python policy speaking of such things? > > I have only recently had a look at distutils [1] and have the impression > that it is only meant for stuff that should end up in the system python > path (please correct me if I'm wrong). distutils and setuptools are able to do the same thing, usually you can just exchange them - with the difference that setuptools is broken most of the time imho. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging software for Cheeseshop and Debian
Simon McVittie wrote: > On Wed, 24 Oct 2007 at 10:03:09 +0200, Bernd Zeimetz wrote: >>> I develop and package webcheck [0] (a python application with private >>> modules). I put all stuff in /usr/share/webcheck and use python-support >>> for compiling the stuff there. I ship an /usr/bin/webcheck symlink >>> to /usr/share/webcheck/webcheck.py. This seems to work fine. >> You can also drop a python script to /usr/bin directly - python doesn;t >> try to create .pyc files there, even when runnign as root. > > This isn't because it's /usr/bin, it's because the file is the main > executable. Right, that was worded confusing, indeed. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging software for Cheeseshop and Debian
> Thanks for this response. Unfortunately I've looked at 'webcheck', and > it doesn't teach me how to use Python's distutils to achieve this > (since, as you note, it doesn't use either of them). Instead of looking at packages you should read the distutils documentation. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
>> * you've missed some packages in Depends (for modules: gtk, qt, PyQt4, >> Tkinter) > > Since python-avc is multiplatform, a user will probably use only one > among the supported toolkits. So python-avc really needs to depend from > them all or it only suggests them? How is decided which toolkit avc uses? If there's a preferred one, let's call it foo, I'd add Recommends: foo | bar | fuzz if not, I'd add them all to suggests. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
Fabrizio Pollastri wrote: > Bernd Zeimetz wrote: >>>> * you've missed some packages in Depends (for modules: gtk, qt, PyQt4, >>>> Tkinter) >>> Since python-avc is multiplatform, a user will probably use only one >>> among the supported toolkits. So python-avc really needs to depend from >>> them all or it only suggests them? >> >> How is decided which toolkit avc uses? > > By user selection: he imports from python-avc the proper module for the > desired toolkit, i.e. for gtk 'from avc.avcgtk import *'. Then I'd add them all to Suggests: Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
Josselin Mouette wrote:
> Hi,
>
> Le lundi 05 novembre 2007 à 15:40 +0100, Piotr Ożarowski a écrit :
>> Hi Fabrizio
>>
>>> I am looking for sponsorship for my new python module: python-avc,
>>>ITP http://bugs.debian.org/448646,
>>>mentors http://mentors.debian.net/debian/pool/main/p/python-avc.
>> * remove "Provides: ${python:Provides}" - architecture independent
>> packages don't need it
>
> Of course they do. What if a package Depends: python2.5, python2.5-avc?
No, they don't.
Please get the _official_ Python Policy fixed and such requirements
included if you like to have them. Neither the wiki nor Manoj's home are
the appropriate place for that. Coming up with random requirements or
undocumented things here is not the way to go.
http://wiki.debian.org/DebianPython/NewPolicy requires Provides:
${python:Provides} in two cases:
- if the package used to build pythonX.Y-foo binary packages
(the package didn't exist before, so I never built such packages)
- if your package provides public extensions.
(no extensions here - please note that it defines an extension as .so
file some lines above)
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
says:
2.5 Provides
Provides in packages of the form python-foo must be specified, if the
package contains an extension for more than one python version. Provides
should also be added on request of maintainers who depend on a
non-default python version.
--> Same here - contains an _extension_. An arch:all package doesn't
ship extensions. The policy defines extensions in the same way as the
wiki does.
Not to forget that the policy is still outdated.
Even Manoj's start of a new policy document says the same:
http://people.debian.org/~srivasta/manoj-policy/x316.html#AEN469
Public pure Python modules that have a subset of all python versions
supported, or for public extensions, the Provides field indicates which
versions of Python are supported (for which one may import the module).
For every version of python supported the package should provide
pythonX.Y-foo packages. This assumes that the package correctly depends
on all the appropriate versions of any version specific module that it
itself requires.
--> We neither have an extension here, nor does it support a _subset_ of
Python versions.
I'd suggest it's time to replace the more than outdated policy by
Manoj's new version, which seems to be fine (didn't read everything yet).
--
Bernd Zeimetz
<[EMAIL PROTECTED]> <http://bzed.de/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
Josselin Mouette wrote: > Le mardi 06 novembre 2007 à 00:22 +0100, Bernd Zeimetz a écrit : >> Please get the _official_ Python Policy fixed and such requirements >> included if you like to have them. > > The official Python policy is currently unmaintained. > Then let's maintain it again. We maintain a lot of packages in a team, so I can't see a problem to maintain the policy there, too. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
Josselin Mouette wrote:
> Le lundi 05 novembre 2007 à 23:57 +0100, Piotr Ożarowski a écrit :
>>>> * remove "Provides: ${python:Provides}" - architecture independent
>>
>>>> packages don't need it
>>> Of course they do. What if a package Depends: python2.5, python2.5-avc?
>> Depends: python2.5, python-avc (>=new_policy_version)
>
> Sorry, but that dependency is incorrect. What if a later python-avc
> version starts requiring python >= 2.6 ?
Then you have a problem anyway - all packages Depending on python-avc
(which is the only sane default for packages which work for all python
versions AND depend on a different package) will need to be updated.
Adding versioned depends again brings us back to the old policy.
--
Bernd Zeimetz
<[EMAIL PROTECTED]> <http://bzed.de/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Joining the team and RFS python-avc
reassign 447231 debian-policy,python-defaults thanks [adding the debian-python list again, I guess you've missed it]. Matthias Klose wrote: > Bernd Zeimetz writes: >> Then let's maintain it again. We maintain a lot of packages in a team, >> so I can't see a problem to maintain the policy there, too. > > The policy files are not unmaintained; They are. Maintaining is more than having a minimal update every other year. > proposed policy changes should > be filed as bug reports against python-defaults. If that's the preferred way - I'm reassigning a related bug from d-policy to d-policy AND python-defaults to make sure it's not forgotten. Also in my opinion the Python policy should be team-maintained (preferable by a small and _active_ team) like most Python related packages. Manoj's Python 'policy' is much more complete, formal and uptodate then the official one, so it should replace the current one. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the python editor 'spe' package needs an update.
SPE Stani's Python Editor wrote: > At the moment I am still working on the new release which can be > packaged for Debian. This version (the latest SPE in subversion) works > with python-wxgtk2.6 and 2.8, so there is no need for Debian to > provide a python-wxgtk2.8 package. Seems the current plan is to skip 2.8 due to too many bugs and package 3.0 instead. > If SPE keeps on being orphaned I > will try to package SPE myself, although it would be nicer if a debian > developer wants to adopt SPE. The wnpp bug was renamed to an ITA by Stefano Canepa <[EMAIL PROTECTED]> - adding him as CC to this mail. Stefano, what's the status of your adoption efforts? Best regards, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the python editor 'spe' package needs an update.
Moin, > Bernd Zeimetz schrieb: >> The wnpp bug was renamed to an ITA by Stefano Canepa <[EMAIL PROTECTED]> - >> adding him as CC to this mail. >> > What's this bug in a closer description? > Haven't heared of it really, sorry. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379374 but you're probably looking for http://www.debian.org/devel/wnpp/ Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the python editor 'spe' package needs an update.
Stefano Canepa wrote: > Il giorno dom, 11/11/2007 alle 23.12 +0100, Bernd Zeimetz ha scritto: >> Stefano, what's the status of your adoption efforts? > > I'll have a package ready for the upload at the end of the week. > > I need to understand how to manage it in the pyton apps group, but I'm > studing. have a look at http://python-apps.alioth.debian.org/policy.html Best thing is to join us in #debian-python on OFTC, especially when you have questions or need a sponsor. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: permission denied when creating a directory for a new project
Hi, > I want to package cython in the PAPT team and I am getting: I get the impression that you want to package some math software... just forgot the name :) Let me know if you need help. > $ svn mkdir svn+ssh://[EMAIL PROTECTED]/svn/python-apps/packages/cython/ > > Committed revision 211. > > Warning: 'post-commit' hook failed with error output: > Use of uninitialized value in concatenation (.) or string at > /srv/home/groups/pkg-perl/scripts/qa/DebianQA/Config.pm line 21. > Error opening cache: Permission denied > > > am I doing something wrong? not you, but Tincho - adding him to the loop :) But the directory was created just fine. btw, svn-inject can take care of creating the directory, too. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: permission denied when creating a directory for a new project
Ondrej Certik wrote: >> I get the impression that you want to package some math software... just >> forgot the name :) Let me know if you need help. > > libmesh. The packages are here: ah ok, I though about http://www.sagemath.org/ Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
>> Build-Depends: cdbs (>= 0.4.43), python-all-dev, python-all-dbg, >> python-central (>= 0.5.6), refblas3-dev [!arm !m68k], lapack3-dev >> [!arm !m68k], debhelper (>= 5.0.38), g77, patchutils, python-docutils, >> fftw3-dev lapack3-dev and refblas3-dev should exist on all architectures now. >> Build-Conflicts: lapack-dev [!arm !m68k], blas-dev [!arm !m68k], >> atlas2-base, atlas2-base-dev, atlas3-base, atlas3-base-dev >> 1. Why is there the build-conflict in the first place? This is the >> question to original maintainers (Marco, Alexandre, Jose, Matthias) > > I added the build-conflict because without it, dpkg-shlibdeps would > make them depend exclusively on blas and lapack, instead of depending > on the virtual package (because all other packages provide blas and > lapack) The packages should not be installed on the buildds anyway, so I think ti shoudl work without build-conflicts. >> 2. Why are there the exceptions to m68k and arm? > > Because m68k and arm don't have atlas. but they have lapack/blas now, which should be enough. >> 3. If the build-conflict is needed, how can we fix the package so that >> it builds on buildbots? try it without the Build-Conflicts. I guess it works. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
>> There's no garantee about which packages are *not* installed on the >> buildds, since packages are not uninstalled after builds. >> Build-conflicts is the good way to solve that. if you look into a random log you'll see that the build chroot is cleaned up after a build. There're only packages left if something really goes wrong. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pycha packaging
Vincent Bernat wrote: > OoO En cette nuit nuageuse du vendredi 04 janvier 2008, vers 00:56, je > disais: > >>> * add python-setuptools (>= 0.6b3-1) to Build-Depends > > lintian asked me to add it to Build-Depends-Indep unless it was > necessary for clean. Since python setup.py clean is called on clean > target, I have added a lintian override. wrong way to go - Please report this as bug against lintian. > >> I have removed it. I will upload this to SVN shortly and will ask you >> for upload when the description review by debian-l10n-english is >> complete. > > I have uploaded to SVN using svn-inject -o. Because of the modified > SOURCES.txt, I have now a not-so-clean SVN tree. Should I leave as is or > should I remove SOURCES.txt from trunk and branches? please remove it and add a patch using quilt or dpatch. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pycha packaging
Vincent Bernat wrote: > On Fri, 4 Jan 2008 09:29:11 +0100, Piotr Ożarowski <[EMAIL PROTECTED]> > wrote: > >>>> I have uploaded to SVN using svn-inject -o. Because of the > modified >>>> SOURCES.txt, I have now a not-so-clean SVN tree. Should I leave as is > or >>>> should I remove SOURCES.txt from trunk and branches? >>> please remove it and add a patch using quilt or dpatch. >> or just remove this file in clean rule, it will be regenerated with >> every ./setup.py call... > > The file exists in the upstream tarball, so I cannot remove it. sure, you can. Just delete it in the clean target. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Vincent Bernat] Re: [Python-modules-team] python-axiom REMOVED from testing
Hi, >> I attach a diff for this change using quilt. I have also upgraded the >> package to the new 0.5.27. I have added myself to Uploaders. I have >> tried to commit this but I get this error: >> svn: Commit failed (details follow): >> svn: Authorization failed the best way to take care of this is to join the python modules team on alioth. Fastest way to get a sponsoring or answers to your questions is to join us in #debian-python on the OFTC network. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [python-odtwriter] package name wrong?
Hi, > Then, the main reason why I have chosen to use this name is that calling > it rst2odt would be inconsequent; python-docutils also contains rst2* > scripts and is not named after them, even though they arguably provide > the interface that is used most of the time. Python module packages are supposed to be anmed after the module they contain. So if you use import foo in your code to import a module, the package would be called python-foo. > So I think it is not the > worst solution to stick with “python-odtwriter”—something like > “python-docutils-odtwriter” would still make sense to me, but that’s a > bit bulky. So python-docutils-writers-odtwriter would be the right name in theory, but this doesn't make sense, indeed. I don't have a better idea than python-odtwriter, though. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request to join Python Modules Packaging Team
Hi, Andrew Straw wrote: > I would like to request membership in the python modules packaging team. Welcome to the team! I've also added you to the python applications team as some of the things you want to package look more like applications than modules. See you in #debian-python on OFTC, cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Adding python-osd to the team list
Hi, > Currently I'm the maintainer of python-osd and i would like to add > this package to the svn repository, do i need to add Uploaders/Vcs-* > fields to debian/control and reupload this package? or just by doing a > svn-inject is fine? Please have a look at http://python-modules.alioth.debian.org/python-modules-policy.html if you have any questions, fast way to get them answered is in #debian-python on oftc. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Boost.Python: Build and Install with Python 2.4 and 2.5?
Hi, I'd suggest to do > 3. Put the libraries in different subdirectories, e.g. > > /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a > /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a and add a symlink to /usr/lib which points to the library version for the current default python version. You could use rtupdate to handle the symlink, so there's no need to rebuild the package when the default Python version is changed. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using python2.5 + mysql on Etch?
Hi, > (Paul pointed me here, so if you're getting this twice: my apologies) > > > I'm looking to run my python2.5-dependent application (uses hashlib) on Etch, > connecting to a mysql database. > It appears the python-mysqldb package only provides for 2.3/2.4. > I tried serveral things (link modules, compile mysqldb myself) but > couldn't really get it working. > > What are the best/easiest options for this situation? I could upload a proper package to backports.org - python2.5 is not officially supported in Etch. I'll put that on my todo list. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-sclapp and pytagsfs (new packages)
Hi, > I am looking for a long-term sponsor for sclapp, a python module and > pytagsfs, a FUSE filesystem application. These are new packages [1] [2] > that I ITPed. we'll take care of that in #debian-python :) welcome to the teams! Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-sphinx or sphinx?
Hi, > If it's just a tool, that name is fine. But if it also contains modules, then > I > think you should go for python-*. Perhaps you could make two binary packages, > one for the module(s) and one for the tool, although that could be > overkilling... looks more like a module in my eyes, so python-sphinx Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-openopt (corrected address - reply to this one)
Hi, > Within your project we are going to make use of OpenOpt project > http://scipy.org/scipy/scikits/wiki/OpenOpt > which as you see is a part of scikits. > > To don't duplicate the effort I decided first to check on the lists > (since there were no ITP yet): noone mentioned it before? made any > tentative package? is there an interest in having such a beast in Debian > (besides for our group)? may be someone aware of incompatibilities with > relevant python modules (eg scipy/numpy, though I didn't mention any at > sid box) we have in Debian now? Speaking from the Python teams' POV, I know nobody who is working on packages of OpenOpt. If I remember right, Ondrej Certik is working on scipy (related) packages. As usual, you're welcome to maintain all packages within the Python teams, join us in #debian-python on the OFTC network if you want to talk, or especially if you're looking for a sponsor :) Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: numpy 1.2.1, switching to git?
Monty Taylor wrote: > /me whinges that switching to bzr for packaging in general would be a > much nicer thing overall, since then ubuntu downstream is pretty well > bzr... unfortunatelt I don't know why they use bzr as it is really ugly to use (that's just my subjective opinion, please don't start a flame war now) Switching to git would be a good thing, but only if most people of the team are ok with the switch. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Steve Langasek wrote: > On Sat, Dec 20, 2008 at 06:43:19PM +0100, Bernd Zeimetz wrote: >> Monty Taylor wrote: >>> /me whinges that switching to bzr for packaging in general would be a >>> much nicer thing overall, since then ubuntu downstream is pretty well >>> bzr... > >> unfortunatelt I don't know why they use bzr > > Because bzr was developed in conjunction with Ubuntu? :) (This might mean > Ubuntu is somewhat biased in favor of bzr; OTOH, it also means that bzr > developers are responsive to the needs of Ubuntu developers.) Actually I didn't know that it was developed by Ubuntu people, all I know is that Ubuntu uses bzr everywhere. After using cvs, svn, arch, bzr, darcs, git and other weird things I prefer git - although it has a steep learning curve, it is much more intuitive to use at the end, comes with a *lot* more features and is much faster than all other tools. From the idea how a distributed revision control system should work darcs is still my favourite - unfortunately I had way too much trouble with bugs when using it and it is missing a lot of features compared with git, so I don't use it anymore. My opinion based on the daily use von the tools is really subjective as all tools do the job they should do most of the time, but using git is just less pain at the end - although I have to admit that it scared me a bit at the beginning. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITP: Name for "real" python-pgsql module
Paweł Tęcza wrote: > So, I'm affraid that packaging of python-pypgsql module is necessary > in that situation. I'm not a Python programmer and don't want to change > the sources. Well.. you could ask upstream. Actually I'd vote against adding just another PG binding as the others implement the DB api well and work well - so as long as I can't see any additional features pypgsql brings, I'm not conviced to sponsor it. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Cyril Brulebois wrote: > Tristan Seligmann (20/12/2008): >> My personal preference ordering would probably be: >> >> hg, bzr, svn, git > > git, FD, * +1 :) http://whygitisbetterthanx.com -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Matthias Klose wrote: > I only trust my own comparsion without any date and version numbers. > And honestly I don't care about a checkin of the usual 2-5 files > taking half a second longer. What annoys me most with git is the > steep learning curve and the non-intuitive UI, therefore I do prefer > bzr over hg over svn over others. In my opinion git is much more intuitive than any other tool - but you have to climb a bit on the learning curve before you realize it. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Ondrej Certik wrote: > Agree. We talked with Sandro on IRC, the problem is in a bad internet > connection --- it takes ~40min to download 10MB -- then of course > every MB matters. For me it takes just couple seconds, so it doesn't > really matter if I am downloading tarball+debian dir separately, or > together in a git repo. but then if you need the original sources to build a package - it doesn't matter much if you get the tarball or clone a git repository. > I just assumed that everyone has a decent internet connection these > days, and I was wrong. :) unfortunately not... Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: please test the numpy package
Hi, Ondrej Certik wrote: > I really want it in unstable. It's because the new scipy won't build > without this upload etc. and many people are just waiting for it. It's > a legitimate question though, but so far I understood that this is > what unstable is for. Otherwise people will have to move from unstable > to experimental to get the latest packages. Is this what we want? I > prefer it in unstable, but I am open to other opinions. I didn't look at the package, but if I remember right a lot of packages depend on numpy, so I would wait with an upload until Lenny is released definitely, except you're absolutely sure that the new version won't break other packages in unstable and won't mess up the migration path fro unstable to testing for them in case there's something to fix. People who want to or need to use the package in the meantime can use experimental, that's what experimental is for. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ok to upload cython 0.10.3-1?
Hi! Ondrej Certik wrote: > is it ok if I upload 0.10.3-1? E.g. will it break the sage build (or > anything else)? Lenny will be released in 5 days - is it really a problem to wait for that? Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Michal Čihař wrote: >> Various >> --- >> >> There are other things which may be worth a look. > > - Can you guys please finally sit down and agree on one solution for > handling python modules? I still think that having two (slightly > different) ways of doing this task is not the way to go. I really do > not see technical reason for this situation. I have no preference at > all and I'm actually using both things in my packages, but I really > do not think it is way to go. And it would be great if we can have > single tool, which gets more testing and will have less bugs than > current concurrent solutions. Ack. Please guys, get together, discuss it in a *sane* way (why do I fear that's not possible...) and merge both tools or drop both of them and do something else useful - together. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#520834: dh_auto_{build,install,clean} should support different python versions
Joey Hess wrote: > Julian Andres Klode wrote: >> pyversions -r lists all supported versions if the field in debian/control >> and debian/pyversions are both missing. If debian/pyversions is empty it >> would fail, but debian/pyversions should never be empty. >> >> At least this is what I saw in my local testing. > > You're right. Use pyversions -s if pyversions -r fails. pyversions -s will work always as it lists all supported Python versions. If a package doesn'tlimit itself to Python versions it works with, it should be built for all supported versions. >> If they use the standard functionality provided by python distutils, >> python-distutils-extra or python-setuptools it should work. >> >> As far as I know cdbs also builds for all requested python versions, >> so it should be safe to adapt this way of building. Right. Also setup.py *must* work for all supported Python versions (or for the versions specified in debian/pyversions), otherwise it is broken and will fail on the next transition. So the best way is to run it with all Python versions as it will save people from headaches and FTBFS when we migrate to a new Python version. >> I CCed debian-python@lists.debian.org, so we can get some feedback >> from there. > > I'm mostly worried about breaking any existing packages that use dh or > dh_auto_*, and somehow contain something that breaks if it's changed to > start building multiple times for multiple python versions. (There are > probably few if any such packages, but I do have to worry about backward > compatability when I change dh_auto_*.) They should not break as building for all Python versions is the right way to go. Modules should also be built with all Python versions to ensure they won't fail to build at install time when pysupport compiles them. If a package breaks due to that, it is *not* a bug in dh but a bug in the package. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#520834: dh_auto_{build,install,clean} should support different python versions
Josselin Mouette wrote: > Le jeudi 18 juin 2009 à 10:33 +0200, Bernd Zeimetz a écrit : >> Use pyversions -s if pyversions -r fails. pyversions -s will work always as >> it >> lists all supported Python versions. If a package doesn'tlimit itself to >> Python >> versions it works with, it should be built for all supported versions. > > AFAIK pyversions -r gives the same output as pyversions -s if no version > information is found. > b...@think /tmp/A% pyversions -r pyversions: error parsing Python-Version attribute 1 b...@think /tmp/A% pyversions -s python2.4 python2.5 b...@think /tmp/A% Doesn't seem so... Joey, is it possible to fixes this bug *REALLY* soon? Otherwise we'll end up with more and more packages which need to be binNMUed when the bug is fixed or will FTBFS because they were never built with all Python versions. Fixing this is really urgent. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#520834: dh_auto_{build,install,clean} should support different python versions
Bernd Zeimetz wrote: > b...@think /tmp/A% pyversions -r > pyversions: error parsing Python-Version attribute > 1 b...@think /tmp/A% pyversions -s > python2.4 python2.5 > b...@think /tmp/A% > > Doesn't seem so... *sigh* it works well if there is a debian/control file. Thanks for useful error messages... pyversions even complains if debian/control is empty :\ -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: pygpgme (2nd attempt)
Miguel Di Ciurcio Filho wrote: > Dear mentors, > > I am looking for a sponsor for my package "pygpgme". Chances to find a sponsor for Python related pacakges are *much* higher if you put the package into the python modules team's svn. Join #debian-python on oftc if you have any questions... http://python-modules.alioth.debian.org/python-modules-policy.html -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: pygpgme (2nd attempt)
Hi Miguel, what's the status of the package? I'd like to ues it soon :D Piotr Ożarowski wrote: > [Miguel Di Ciurcio Filho, 2009-07-14] >> http://mentors.debian.net/debian/pool/main/p/pygpgme/pygpgme_0.1+bzr20090707-1.dsc > > * replace python-dev with python-dev-all and build extensions for all > supported Python versions (pyversion -rv) (it will be easier once > #520834 will be fixed) Fixed, use debhelper >= 7.3.5 currently in experimental > * how about adding -dbg package? supported by the debhlper version above, too. > * don't depend on setup.py's executable bit (i.e. add "python ") or just use dh, see above :) Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Building extensions / dbg packages with dh
Hi, with debhelper >= 7.3.5 it is possible to build Python extensions and -dbg packages, as long as they come with a distutils/setuptools based setup.py. By default dh will call setup.py with all requested Python versions, starting with /usr/bin/python aka. the default Python version (if it was requested to build with it). Then dh will build with all other requested Python versions, if they're installed. This ensures that there is no need to build depend on python-all(-dev) if you don't need to. Of course you need to take care of your build-dependencies, dh won't help you here, at it won't fail to build if there are some missing. For all requested Python versions dh will also look into debian/control to figure out if you build-depend on a python.*-dbg package (yes, python-dbg and python-all-dbg will be recognized, too...) which installs the python dbg interpreter in this version. If an according build-dependency was found, the dbg extensions will be built. As they'll end up in debian/tmp together with the normal build, you'll have to write proper debian/package.install files to put them into the right package. Let me know if you find any problems. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F signature.asc Description: OpenPGP digital signature
Re: Building extensions / dbg packages with dh
Bernd Zeimetz wrote: > with debhelper >= 7.3.5 it is possible to build Python extensions and -dbg > packages, as long as they come with a distutils/setuptools based setup.py. In case you're looking for examples: python-usb and python-cjson use the new dh now. python-cjson builds a dbg package and python-usb not. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: pycentral pkginstall fails to byte-compile
Toni Mueller wrote: > > What's the right way to fix this, please? No real idea, but I'd give python-support a try. Often it just works then... -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
Christoph Egger wrote: > > I have some of the trac-plugins ITA/ITPed and would probably consider > following trac itself into one of the python Teams. However I wonder how > the $VCS will be handled, throwing away trac's git history doesn't sound > like a good idea to me. > > As my packages have (following trac itself) a git history and the one > I've ITA-ed has some HG history I'm interested in what the team thinks > so I can decide if / what to move in. We're thinking about migrating the modules/apps teams repositories to git for a long time, actually there is even a plan (at least in my head) to make it possible to have modules in git or svn while still being able to checkout all of them in a useful way, but that means writing new code, and I didn't have the time to do so yet. Dropping the history doesn't make sense indeed, so I'm not sure what the best way to handle this is *now* - on the long run I;m sure we'll find a way to include it properly. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
Cyril Brulebois wrote: > Bernd Zeimetz (28/08/2009): >> long time, actually there is even a plan (at least in my head) to >> make it possible to have modules in git or svn while still being >> able to checkout all of them in a useful way, but that means writing >> new code, and I didn't have the time to do so yet. > > You meant putting a few lines into a .mrconfig file? no. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VCS for Python code Was: Trac team almost dead?
anatoly techtonik wrote: > If we are all Python developers to some degree and know about PEP 374 > - what do you think about switching from SVN to HG for maintaining > Debian packages? There is also "convert" extension that may allow to > convert history from other sources to HG and PEP 385 that may help > admins to decide how to move from SVN. That won't happen as the main sponsors and the most active people in the team will not touch hg. We'll stick with svn for now, but chances are good that we'll add git support in the future. The reasons behind that were discussed often enough, no need to start that again. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: lintian troubles and .changes doubts
Cyril Brulebois wrote: > Alessandro Dentella (03/09/2009): >> Hi, > > Hello, > >> 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 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 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 have used “0.8.6~rc5”, which sorts lower than > “0.8.6”, while “0.8.6-rc5” sorts higher. dpkg --compare-versions is helpful here, if you don't know the details :) -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: XS-Python-Version vs pyversions
Steve Langasek wrote: > On Sun, Sep 06, 2009 at 07:59:13PM +0200, Luca Falavigna wrote: >> Il giorno Sun, 6 Sep 2009 19:32:34 +0200 >> Alessandro Dentella ha scritto: >>>pyversions: missing XS-Python-Version in control file, fall back to >>>debian/pyversions > >> It's fine to have debian/pyversions without XS-Python-Version when you >> use python-support, just ignore this notice. > > FSVO "fine" that includes "completely destroying the value of the python > policy for the Debian release team". Please do not even think about talking about the so called Python policy, which is not maintained at all, does not reflect the current state of packaging, is missing a lot of information and is far away from reality. Even Manoj managed to write a much more complete version of the policy out of his own interest. #447231 is oopen since a long time now -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: XS-Python-Version vs pyversions
Steve Langasek wrote: > The XS-Python-Version field was specified as a tool for detecting, without > having to download and inspect individual source packages, that a given > package can be successfully rebuilt for a python transition, to aid the > release team in this work. As mentioned somewhere else in this thread it makes much more sense to loog at the build-dependencies. Packages which need a special (single) version of Python are easy to detect on their biuild-dependencies. For the few packages which depend on python-all(-.*), although they build modules only for a limited number of Python versions, it is still a good idea to rebuild them to ensure that they still build with the tools from the latest version (like pyversions, python.mk, your $favourite python helper). >From the 90 packages in the Python Modules team which use debian/pyversions, there are only 5 which have the Python versions limited to <<2.5, so they'll be gone as soon as Python 2.4 is removed. So I fail to see a reason why the XS-Foo stuff is necessary. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: XS-Python-Version vs pyversions
Steve Langasek wrote: > On Tue, Sep 08, 2009 at 03:53:31PM +0700, Mikhail Gusarov wrote: > >> Twas brillig at 20:21:31 07.09.2009 UTC-07 when vor...@debian.org did gyre >> and gimble: > >> >> SL> They were part of the design that came out of the python >> >> SL> packaging BoF in DebConf 6 that you then proceeded to ignore >> >> SL> entirely. > >> >> Is this design and rationale written down somewhere? It's hard to >> >> follow policy which contains completely opaque requirements. > >> SL> No, it's pretty much bitrotted away by now > >> Thanks to those who did not communicate ideas outside of the DC >> attendants. > > Bullshit. Spare me your ignorant preaching and go read the mailing list > archives. Oh yet another BoF where the people taking part started to think they can rule the rest of the world without talking to it. >> SL> thanks to people deciding to discard all the efforts of the session >> SL> in question > >> Which were not documented. > > They were documented. The documentation has bitrotted because consensus was > abandoned. > > It once lived at <http://people.debian.org/~piman/python-policy/> - before > the python policy process degenerated into such an absurd mess that the > maintainer left Debian entirely. There was a policy process? Asking the Python maintainer about the way the policy is changed the answer was pretty much "it is decided and written by the Python maintainer, an nobody else". There is no process, there is a one man show. >> Single "why?" document would help to resolve situation much better than >> endless whining about "bad python-support developers". Just accept the >> facts that you've failed to communicate ideas behind policy, > > Bullshit. The python-support maintainer knows the reasons already. This > was not a failure of communication, only a failure of collaboration. Or a 'no I don't implement useless ideas'. >> reevaluate situation and propose something that is constructive, this will >> be beneficial for all of us. > > And why would that work any better now than it did three years ago? If > anything, the responses in this thread show that the list is far more beset > with python-support apologists now, who are even less willing to approach > the problem from a policy perspective and are only interested in defending > their favorite tool. The reason why people prefer python-support is easy: - the upstream author is responsive - the upstream author fixes bugs in time - it just works as expected - it doesn't need such ugly workarounds like "nomove" That alone are more than enough reasons to to use -central. Its not my fault that the upstreams of both helpers are not able to collaborate, but if you have the choice, you choose the better tool, which is python-support now. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: XS-Python-Version vs pyversions
Steve Langasek wrote: > On Tue, Sep 08, 2009 at 04:49:54PM +0700, Mikhail Gusarov wrote: > >> Twas brillig at 02:42:09 08.09.2009 UTC-07 when vor...@debian.org did gyre >> and gimble: > >> SL> Spare me your ignorant preaching and go read the mailing list >> SL> archives. > >> Mailing list archives are not documentation. > > They're documentation that you're wrong. Stop wasting my time. Oh snap. Come on Steve, the only useful written documentation about the new Python policy was (is?) a wiki page. Not even the "official" policy is complete. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: XS-Python-Version vs pyversions
Josselin Mouette wrote: > Le mardi 08 septembre 2009 à 19:06 +0200, Piotr Ożarowski a écrit : >>> Since the build-dep approach should have agreement from all the helper >>> maintainers before it moves forward, I think it would be a good first >>> step to mark pyversions deprecated (initially in favor of XS-* and >>> later in favor of the build depends approach) and leave it up to >>> package maintainers if they care to change in the near term. >> how about using build dependencies *if* pyversions and XS-P-V are not >> set and removing support of these fields once all packages will >> use the new approach? > > I think that’s the most efficient approach indeed. For that, we need to > either: > * patch /usr/bin/pyversions to use them instead > * or introduce a new script that does this, and get cdbs and dh7 > to use it instead If there is really a consensus about that, it would not be too hard to implement it in dh directly. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: will 2.6 be default?
Josselin Mouette wrote: > Le samedi 12 septembre 2009 à 13:23 -0400, Scott Kitterman a écrit : >> One thing that would make the transition simpler (that could be done now) >> is to get CDBS to add the patch in >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537373 > > Marc Dequènes agreed for a NMU to add this patch, so I guess you can go > ahead if you want. The patch looks pretty much hackish and I could imagine that it will break a backport of cdbs to Lenny as python2.4 is called with --install-layout=deb, too. And what I really fail to understand is why you need to tar the directories and rename them... or so. Cheers, Bernd ... who knows why he does not use cdbs... -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: will 2.6 be default?
Josselin Mouette wrote: > Le dimanche 13 septembre 2009 à 02:23 +0200, Bernd Zeimetz a écrit : >> The patch looks pretty much hackish and I could imagine that it will break a >> backport of cdbs to Lenny as python2.4 is called with --install-layout=deb, >> too. > > Of course, if you backport things without thinking of what they do, this > will produce broken backports. > >> And what I really fail to understand is why you need to tar the directories >> and >> rename them... or so. > > This allows to let existing packages that manipulate stuff in > site-packages/ directories work as is, instead of having to change them > all to work with python2.6. I'm not conviced this is a good idea, sorry. There is /usr/share/python/python.mk if you need to figure out the name of the directory. Everything else is a hack. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python packaging
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 minds of a few people and not > written down. > > I don't think I want to read that. Ack. Probably do what most people (no, I didn't count them) seem to do: Use python-support and debian/pyversions. And if you run into problems, you join #debian-python on OFTC and just ask for help. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: python shebang, and other interpreters.
Wolodja Wentland wrote:
> I can see your need as a python application maintainer to be *sure* that
> the python version distributed with debian is used to run that program.
Exactly.
> But the '/usr/bin/env python' scheme will result in exactly that
> behaviour if the administrator/user has not intentionally installed a
> *unsupported* Python environment.
If the behaviour is the same, why use '/usr/bin/env python' then. If the
admin/user/fool wants to install a different python version, they're able to
modify/reinstall the application in a sane way, and probably under the new
Python environment (which is the only proper way, mixing stuff likes to break
things).
>
> I always had the impression that Debian relies on the fact that users
> install software via the package manegment system provided by Debian,
> but are still given the freedom to make adjustments to their environment
> for which they take full responsibilty. IMHO installing a new Python
> environment not provided (and supported) by Debian falls into this
> freedom. But this comes with responsibility ...
Exactly. You're not forced to install something via apt. There is /usr/local and
$PATH.So if you install a new Python environment, please install all the
necessary stuff for it on your own. Thats the only way that makes sense for a
distribution, otherwise there is absolutely no sane way to react on bug reports
and other issues.
> [..]
> To alleviate this problem a little Debian could give precise
> instructions on how to install external Python environments. Which would
> for example mean, that if a user installs Python 2.6 / 3.1 / whatever
> she will delete /usr/local/bin python and can use the new version by
> explicitly calling python{2.6,3.1}. If this is done '/usr/bin/env
> python' still runs the program with the standard Debian version.
Just use http://pypi.python.org/pypi/virtualenv
> I am aware of the fact that this might cause a lot of bug reports by
> users who don't know what they are doing, and expect their system to
> "just work" whatever stupid decisions they take as an administrator.
Something which should be avoided clearly.
> This could be solved by providing feedback to the user that they are
> using a unsupported Python version whenever they try to report a bug
> with reportbug and it is found that '/usr/bin/env python' is indeed not
> the Python environment as distributed by Debian.
Which will only work as long as reportbug is run in the same environment... and
which will probably just fail again, as reportbug is using Python.
> If however the *env python scheme is enforced in the policy the problems
> I outlined in my original post are solved without additional problems
> (?). If there are any i would like to know about them!
There are probably not more problems than the few which were mentioned already,
but they are such large issues that thinking about enforcing the use ov env is
absolutely insane.
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: new dh_python proposal
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 Python, there is no >> need to learn bashes when you program Python - do not expect that >> package maintainers will be able to debug their scripts in shell >> language. > [skipping the rest of your mail] > > I got the impression that dh_python will be written in Piotr's > favourite language, Python, but may need to be rewritten in Perl for > inclusion in debhelper: > > http://lists.debian.org/debian-python/2009/08/msg6.html Time for a python binding to debhelper then? ;) But indeed the only proper way to write a debhelper tool is in perl. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [pkg-fso-maint] Bug#547510: zhone refuse to start
Joey Hess wrote: > Bernd, did you get it backwards when writing the above code? > > Build order does not actually matter, but installation order does. > At least in this case, the last python version to run the install > overwrites the script from the other version, so default should be last. Normally the scripts are not copied a second time, if they exist at the destination (have a look at winpdb, for example - if you want to build it in a chroot, don't forget to s/python/python-all/ in the build-deps. So usually - and in my experience - dh does the right thing as it is now. The last time we had such an issue it was due to the setup.py doing weird things (like creating the to-be-installed script on the fly). I didn't have the time to investigate in zhone, but I'm kinda sure its an issue with its setup.py. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fw: RFS: python-coverage 3.0.1-1
Ben Finney wrote: > The changelog entry for ‘debhelper’ 7.3.5 says: > > * python_distutils buildsystem: Build for all supported Python > versions that are installed. Ensure that correct shebangs are > created by using `python' first during build and install. > Closes: #520834 > Also build with python*-dbg if the package build-depends > on them. > > What does it mean “if the package build-depends on them”? If “them” > means “debug packages”, why would any non-debug package depend on a > debug package? Checking if -dbg interpreters are installed is not enough to decide if you want to buiid with them as you don't necessarily have a clean chroot. So dh needs to look into the build-deps. > >> debian/python-coverage.dirs: >> * Useless. > > I can't find where ‘/usr/bin/’ is excluded from requirement to be > created; is it in a part of Policy that I've overlooked? There is no need to use a .dirs file if setup.py creates the directory for you. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: License entry in egg info files
Ben Finney wrote: > Paul Wise writes: > >> Do you object to spelling-error-in-binary, >> duplicated-key-in-desktop-entry, embedded-zlib, duplicate-font-file or >> the other lintian tests that check upstream stuff? > > I think they lead to widely-used, persistent overrides, and I think such > overrides are an indicator that the specific check is inappropriate. Usually an override is a fail in the maintainer's brain or a bug in lintian. Only in rare cases overrides are the right way to go. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#556148: installs files into /usr/local for Python >= 2.6
Dirk Eddelbuettel wrote:
> | Starting from Python 2.6, the installation paths for distutils have
> | changed. /usr/local is now used by default.
> |
> | When rebuilt against python-all{,-dev,-dbg} (and thus python2.6) from Debian
> | experimental, your package contained these files:
>
> I don't have access to experimental in my pbuilder. So how should I test this?
Create a pbuilder basetgz for experimental? Thats plain easy. If you really have
no clue how to do it, use my .pbuilderrc:
http://git.recluse.de/?p=users/bzed/dotfiles.git;a=blob;f=.pbuilderrc;h=b1b9517bc31b3a3e36de87b9c1a2474f709e0b4b;hb=HEAD
Then all you need to do is pbuilder --create if your debian/changelog says
experimental.
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559237: python-asterisk: FTBFS with Python2.6
Package: python-asterisk Version: 0.1a3+r160-4 Severity: important Tags: patch User: debian-python@lists.debian.org Usertags: python2.6 python-asterisk ftbfs with Python2.6, which will hit unstable soon. Please import the changes from Ubuntu, which fixed the bugs (hopefully): https://launchpad.net/ubuntu/+source/py-asterisk Thanks, Bernd -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.1-think (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-asterisk depends on: ii python2.5.4-2An interactive high-level object-o ii python-support1.0.4 automated rebuilding support for P python-asterisk recommends no packages. python-asterisk suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: python2.6 vs python-json
Alexandre Quessy wrote: > Hello everyone, > It seems like python-json should either be renamed of deprecated. > > Meanwhile, all the Python application and modules that use JSON should > be careful when importing the json module. Here's how I do it. (see the > code extract below) > The other option is using python-anyjson, although I start to wonder how they make a difference betweek py2.6's json and python-json, if its necessary at all for anyjson. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b7b1b46.9020...@debian.org
Re: python 2.6 deb for lenny ?
On 04/01/2010 10:27 AM, Toni Mueller wrote: > I'm sorry to say that I forgot to upload my semi-broken attempts - just > "fixed" it - maybe they still provide a useful starting point: > >> http://people.debian.org/~toni/python2.6/ > > > Please send feedback my way! I think Fabio (kob...@d.o) also wanted to / is working on a backport, might make sense to co-maintain that with him. CCed him :) -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bce35ea.6070...@bzed.de
Bug#579111: RFP: pybindgen -- Python bindings generator
Package: wnpp Severity: wishlist * Package name: pybindgen Upstream Author : Gustavo Carneiro * URL : https://launchpad.net/pybindgen/ * License : GNU LGPL v2.1 Programming Lang: Python/C/C++ Description : Python bindings generator PyBindGen is a Python module that is geared to generating C/C++ code that binds a C/C++ library for Python. It does so without extensive use of either C++ templates or C pre-processor macros. It has modular handling of C/C++ types, and can be extended with Python plugins. The generated code is almost as clean as what a human programmer would write. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100425122339.17726.85977.report...@think.mg.bzed.de
Re: Python talks at DebConf
On 05/08/2010 10:55 AM, Piotr Ożarowski wrote: > The only reason I got from Ubuntu for doing transitions outside Debian > and allowing Debian to do it later (and forcing us to fix after them) > is... "because you are slow". Of course Ubuntu is faster, they fixed all the python2.6 bug by disabling the tests which showed the bugs... -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4be57c9a.2060...@bzed.de
Re: DPMT and PAPT request
On 05/28/2010 09:10 PM, Barry Warsaw wrote: > I realize that I've never formally requested addition to DPMT and PAPT. Since > I maintain both upstream Python applications and modules, and since I'm on the > core Python development team, I would like to request admission to both Debian > teams. I'll start off by maintaining the various packages that I author, > independently, as spin-offs from the GNU Mailman project, and various others > that I use and hack on. Of course, I'm also very interested in helping to > maintain Python itself. Welcome to the teams, glad to have you on board! > For reasons I'm not quite sure of, my Alioth user id is warsaw-guest. I've > requested membership through the respective groups on Alioth. That will be fixed as soon as you are a Debian Developer. You should make sure you become one quickly! :) The reason behind the -guest is that the accounts from the debian ldap are synchronized with alioth, so it is necessary to have a way to distinguish between DDs and non-DDs, especially to ensure that an account is not used on alioth already when a new DD requests to have the name. Hope that explains it :) Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c01849d.3090...@bzed.de
Re: Policy for "Specifying Supported Versions" for Python3
On 06/18/2010 07:11 PM, Scott Kitterman wrote: > I don't think we need a new debian/control field to achieve the separation. > pyversions (as of yesterday's upload) ignores any python3 versions it gets > and py3versions ignores anything less than 3. +1. Adding more control fields just makes the mess bigger. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c1ca4bb.5000...@bzed.de
Re: Bug#585627: hplip: Error with hpmudext module : hp-* dont works
On 06/20/2010 06:42 AM, Mark Purcell wrote: > We have pyversions and are using python-support, but still are not getting > what we need. I can't see where you're building the files for all Python versions... > If we build the hplip package with python2.5 installed, then it places the > modules under /usr/lib/python2.5/site-packages: > http://packages.debian.org/sid/ia64/hplip/filelist > > If we build the hplip package with python2.6 installed then it places the > modules under /usr/lib/python2.6/dist-packages: > http://packages.debian.org/sid/i386/hplip/filelist Thats right, the location for those files changed from 2.5 to 2.6. > The python2.5 built packages (/usr/lib/python2.5/site-packages) do not work > if python2.6 is installed, as it cannot locate the correct modules.. :-( Python 2.6 does nto search in the 2.5 directory obviously - but you're using a private module directory anyway (/usr/share/hplip) - so I can't see the issue why it can't find the modules. Also I'm wondering if you need to rebuild everything for each python version as - on the first look - I didn't see any extension in the packages. > So how do I force depends to be set to ensure the correct version of python > is installed, or how to I ensure that either version of python will look in > either location for the modules?? Both ways are wrong. python-support handles that for you (in case you're using non-private module directories). -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c1e3700.8050...@debian.org
Re: Bug#585627: hplip: Error with hpmudext module : hp-* dont works
Hi, as it is a bit urgent to get the Python transition done I've uploaded a fixed package to delayed/1. Please let me know if I should remove or delay it, but it would be appreciated if the problems could be fixed ASAP. Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c1e802c.5070...@debian.org
Re: RFH: Debugging symbols of pyside
On 06/28/2010 04:34 PM, Yaroslav Halchenko wrote: > AFAIK: > > - regular python build symbols files are useful for anyone willing to > troubleshoot the problem which is not too complicated and he wouldn't > need to explore the state of Python at the troublesome moment. > > - _d* files for python*-dbg are extremely useful if someone needs to > triage the problem which cannot be easily comprehended by just looking > at the stack of compiled extension. Then various tricks (Python's > ./Misc/gdbinit, or new way ./Tools/gdb/libpython.py) allow much easier > bug/problem triage in Python extensions using debug build of Python also - and that is the much more important imho part for pyside - if you want to run something else in the debug interpreter which uses pyside, you need the _d build of pyside, too. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2b5662.5080...@bzed.de
Re: Hello DPMT!
On 06/30/2010 10:03 PM, Clint Byrum wrote: > Hello DPMT... > > I'm Clint, I work for Canonical, and I want to help! :) > > I am interested in joining the DPMT, in part to improve python module > support for server applications in Debian and Ubuntu. Specifically I'd > like to start by helping to facilitate the upload and maintenance of > python-libgearman, for which I will forward a more formal request for > sponsorship shortly. I'm also keenly insterested in the ongoing > maintenance of python-pylibmc. > > Per the policy, my alioth login, which I just created, is spamaps-guest. Welcome to the team, I've added you some seconds ago. Please make sure you read our policy http://python-modules.alioth.debian.org/python-modules-policy.html before committing to the svn. For sponsoring requests and general discussion the best place to join is #debian-python on the OFTC network. Hint: usually we don't sponsor packages which are not in the team's svn Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2c6c19.3050...@bzed.de
Re: RFH: Debugging symbols of pyside
On 06/30/2010 05:03 PM, Didier 'OdyX' Raboud wrote: > Hi Bernd and Yaroslav, hi again debian-python, > > So, if I summarize: > > Bernd Zeimetz wrote: >> On 06/28/2010 04:34 PM, Yaroslav Halchenko wrote: >>> AFAIK: >>> >>> - regular python build symbols files are useful for anyone willing to >>> troubleshoot the problem which is not too complicated and he wouldn't >>> need to explore the state of Python at the troublesome moment. > > i) the stripped symbols from the standard build are important. > >>> - _d* files for python*-dbg are extremely useful if someone needs to >>> triage the problem which cannot be easily comprehended by just looking >>> at the stack of compiled extension. Then various tricks (Python's >>> ./Misc/gdbinit, or new way ./Tools/gdb/libpython.py) allow much easier >>> bug/problem triage in Python extensions using debug build of Python > > ii) the "pythonic debug build" is important. > >> also - and that is the much more important imho part for pyside - if you >> want to run something else in the debug interpreter which uses pyside, you >> need the _d build of pyside, too. > > AFAIK, that's what I am doing: > > $ dpkg -L python-pyside-dbg | grep QtCore > /usr/lib/debug/usr/lib/pyshared/python2.6/PySide/QtCore.so > /usr/lib/debug/usr/lib/pyshared/python2.5/PySide/QtCore.so > /usr/lib/pyshared/python2.6/PySide/QtCore_d.so > /usr/lib/pyshared/python2.5/PySide/QtCore_d.so I think you misunderstood me :) Imagine you have a file in your project which does import cjson from Pyside import QtCore and you want to debug whats going on with cjson in your project by running it with the debug interpreter, then you need debug build of pyside, too. I'm in favour of having debug builds for all extensions, at least if its possible to build them easily. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2ce788.3040...@bzed.de
Re: Hello DPMT!
On 07/07/2010 07:18 PM, Clint Byrum wrote: > On Thu, 2010-07-01 at 12:21 +0200, Bernd Zeimetz wrote: >> Welcome to the team, I've added you some seconds ago. >> Please make sure you read our policy >> http://python-modules.alioth.debian.org/python-modules-policy.html >> before committing to the svn. >> >> For sponsoring requests and general discussion the best place to join is >> #debian-python on the OFTC network. >> Hint: usually we don't sponsor packages which are not in the team's svn >> > > Thanks very much Bernd. > > I went ahead and uploaded python-libgearman to the svn repository. I > think it may be tagged a bit incorrectly, as I forgot to include my > change to have the Maintainer: field set to DPMT. I committed that, but > svn-buildpackage --retag didn't seem to send the tag to the repository. Please only tag things when they were actually uploaded to the archive, otherwise we have to retag too often :) If re-tagging doesn't work, just delete the tag directory with svn, then we can tag again later. > I would appreciate it very much if somebody could review the package, > provide any feedback, and/or possibly sponsor it into Debian. Easiest thing for such requests is usually to come into #debian-python on OFTC and ask for review, most of the time somebody is around who can and will do so and spnsor the package. Poke me, for example :) -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c34d1b1.70...@bzed.de
Re: Help with Python 2.6 migration
On 07/10/2010 07:55 PM, Piotr Ożarowski wrote: > [Andreas Tille, 2010-07-10] >> pkg_resources.DistributionNotFound: SQLObject>=0.12 > > python-sqlobject is not shipping egg-info dir/file (anymore?) > > ping python-sqlobject maintainer Fixed, although I'm not the maintainer. CCing the real one :) -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c38ddbd.4020...@bzed.de
