Re: PEP 453 affects Debian packaging of Python packages
On Sat, Sep 21, 2013 at 08:50:46AM +0200, Etienne Millon wrote: > > I find the ITP/wnpp annoying as well. I usually end up browsing > > http://www.debian.org/devel/wnpp/ , opening all links then searching > > for my package :-] I then bootup an instance and try to remember > > to report the bug against the 'wnpp' package. > FYI, you can use the wnpp-check command (from devscripts) to do this. Source package names may differ (especially when speaking about Python module packages). -- WBR, wRAR signature.asc Description: Digital signature
Re: PEP 453 affects Debian packaging of Python packages
On Sat, Sep 21, 2013 at 04:36:23PM +1000, Ben Finney wrote: > > I keep forgetting filling an ITP. It is usually caught on final review > > because for some reason lintian is not being run by default by my > > packaging chain :-( > For ‘pbuilder’, you can add a hook that automatically runs Lintian on > every package it builds. Other packaging tools will surely have a > similar feature. debuild (and so tools that call it) even have this by default. > > I find the ITP/wnpp annoying as well. I usually end up browsing > > http://www.debian.org/devel/wnpp/ , opening all links then searching for > > my package :-] > Instead, when you first create the package, edit ‘debian/changelog’ and > make “Initial Debian package of ‘foo’ (Closes: bug#NN)” the very > first bullet point in your first changelog entry. Then you won't need to > keep looking it up. dch --create and dh_make even make this entry by default. -- WBR, wRAR signature.asc Description: Digital signature
Re: PEP 453 affects Debian packaging of Python packages
Andrey Rahmatullin writes: > On Sat, Sep 21, 2013 at 04:36:23PM +1000, Ben Finney wrote: > > Instead, when you first create the package, edit ‘debian/changelog’ > > and make “Initial Debian package of ‘foo’ (Closes: bug#NN)” the > > very first bullet point in your first changelog entry. Then you > > won't need to keep looking it up. > dch --create and dh_make even make this entry by default. It has that entry, yes, but without the bug report number that was being discussed. The point is to immediately record the ITP bug report number in that entry of the changelog. That way, you have it for reference in the package while developing it, and you will no longer be nagged by Lintian to add it. -- \“I fly Air Bizarre. You buy a combination one-way round-trip | `\ticket. Leave any Monday, and they bring you back the previous | _o__) Friday. That way you still have the weekend.” —Steven Wright | Ben Finney -- 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/7wa9j6wpp5@benfinney.id.au
Re: How to help with sphinx 1.2?
Hi Jakub, On Mon, Sep 16, 2013 at 3:51 PM, Jakub Wilk wrote: > Anyway, here's a list of bugs you might want to fix before uploading Sphinx > 1.2 (beta or not) to unstable: > http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-modules-t...@lists.alioth.debian.org;tag=sphinx1.2 > https://bitbucket.org/birkenfeld/sphinx/issue/1185 I have now prepared Sphinx 1.2b2 in Subversion. Two of the bugs you mentioned have been fixed in the new release, other three bugs now have links to upstream commits attached. I hope Yaroslav will look at that soon. Will you sponsor the new package (the package is mature enough for unstable, but let's upload it to experimental until the mentioned fixes are uploaded)? -- Dmitry Shachnev -- 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/cakimphxvjtt0yjxcc5cqytpyu9vjf-om1fuwmmsf5spw_ha...@mail.gmail.com
Best practices for data files in /usr/share
Hello. I'm packaging a new version of python-babel and as it now builds 2.x and 3.x packages I decided to move the locale data into /usr/share and package it separately. Currently the data is installed using 'package_data' setup() argument and accessed via os.path.dirname(__file__). I've added some mv calls into rules and patched the code to look in /usr/share instead, but now the tests cannot be run as they execute the same code and so cannot find data files in the source directory. So, what are the best practices for moving data files out of the module directories? -- WBR, wRAR signature.asc Description: Digital signature
Re: Best practices for data files in /usr/share
On Sat, Sep 21, 2013 at 11:36:05PM +0600, Andrey Rahmatullin wrote: So, what are the best practices for moving data files out of the module directories? This is how we do it in Sphinx: 1) There's only one statement that uses __file__ (thanks, upstream!): http://sources.debian.net/src/sphinx/1.1.3%2Bdfsg-4/sphinx/__init__.py#L21 2) We run tests against source that has this line kept intact. Then we patch the line using sed: http://sources.debian.net/src/sphinx/1.1.3%2Bdfsg-4/debian/rules#L66 -- Jakub Wilk -- 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/20130921191149.ga20...@snusmumriken.jwilk.net
Re: Reverting switch to dh-python for pyflakes
Hello, On 21 September 2013 05:02, Thomas Goirand wrote: > Hi, > > I'm having issues with backporting pyflakes 0.7.3-1 to Ubuntu precise. > It would help a lot if you reverted your switch to dh-python. Do you > think that's possible? > No, I will not revert that. Instead dh-python should be backported into precise-backports, if that hasn't been done yet. Similarly how it's already been backported to stable-backports. Also note that pyflakes is using/building python3 modules as well. Not sure if pyflakes support the precise's python3. Regards, Dmitrijs. -- 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/canbhlug1vff4e1yx3pz_uqnb6qhvkqodocnmno0mb5ccdbv...@mail.gmail.com
Re: PEP 453 affects Debian packaging of Python packages
On 2013-09-20 at 15:44:05 -0700, Thomas Kluyver wrote: > Elena: > > there is an UpstreamGuide_ on the wiki: > > So promote it! I'm pretty sure I've never seen that URL before. that's exactly what I was doing :) there *is* a problem with the way debian documentation has naturally grown to a point where it is hard to find what somebody needs. I believe some people are working on solving it, I admit I wouldn't know where to start so I'm not helping (and I just use google and word-of-mouth). > > ITP bugs aren't cruft, they are a way to prevent duplication of work, > > which would lead to even more frustration. > That seems like an unlikely problem in real world cases - how often will > two people decide to package the same, currently unpackaged, piece of > software, within the couple of days or so before the first one publishes > their work. Sometimes packaging some software requires more than a couple of days, expecially when it requires packaging of multiple dependencies, or when it is expecially tricky (the latter shouldn't happen with most python modules, but mostly with other languages, however). The chance that two people could decide to package the same software in a couple of weeks or even a month aren't so low. -- Elena ``of Valhalla'' -- 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/20130921210555.gh7...@genesis.home.trueelena.org
Re: Disabling pip for root?
Le 20/09/13 10:29, Thomas Goirand a écrit : > It's really not hard to package some Python modules for Python. Having a > tool that does it automatically - even not very well -, like debpear > does, can solve this kind of trouble. Giving access to this kind of > tools to a wide user base can also help solving the "oh, but that module > isn't available in Debian" kind of problem. I did my first packages using Effing Package Management (fpm): https://github.com/jordansissel/fpm You give it a source (pypi), a target (deb) and the name of the resource. Then magic happen and you end up with a .deb. The generated .deb is installable and works fine for the simplest packages. The resulting .deb is not on par with Debian quality though and you need a bunch of additional work to make it acceptable. Maybe have a look at fpm and find out how we can get it improved for the py -> deb case? -- Antoine "hashar" Musso -- 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/523e2d11.7050...@free.fr
