Maintainer needed for python-trml2pdf
Hello, I just uploaded a new version of python-trml2pdf where I removed myself from Uploaders. I originally packaged this because it's needed for Satchmo but I never went further to package satchmo. So I have no interest in this package. In the mean time it got one reverse dependency, namely kraft. So it can't be removed. Someone should step up to maintain this package, and quite possibly one of the kraft maintainers (since we're using the version released by Kraft's upstream anyway). The package is currently maintained within the python-modules SVN repository and all Debian developers have write access. It's trivial to maintain and should not require much work. On the bad side, it has no real upstream. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- 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/20120504064142.ga26...@rivendell.home.ouaza.com
Re: Help in packaging rubber
On 04. mai 2012 12:01, Hilmar Preuße wrote: Correct. It applies to a preview for a new upload, which is on my PC. I just wanted to document, which changes I've applied for the dh_pysupport - dh_python2 migration. It's kind of hard to say without seeing the whole package, but if you get it into SVN it'll be easy to see. I just sent the join request on alioth (https://a.d.org/projects/python-apps/) Should I make the package team managed, i.e. python-apps-t...@lists.alioth.debian.org as maintainer? python-apps-t...@lists.alioth.debian.org should be in either maintainer or uploaders. -- Andreas Noteng signature.asc Description: OpenPGP digital signature
Double build failures
Hi! I got some bug reports from Jakub about double build failures. I have always found those kind of tests a bit silly, but that's just my opinion. Most of the time, the failures are because of the created egg directory that is not cleaned up by the clean target of setup.py. While I could add the appropriate bits to each clean target in debian/rules, it seems better to fix the problem either in dh_python2 or in setuptools. Any thoughts? -- Vincent Bernat ☯ http://vincent.bernat.im Don't just echo the code with comments - make every comment count. - The Elements of Programming Style (Kernighan Plauger) pgpezY72eVhuG.pgp Description: PGP signature
Re: Double build failures
On 04/05/12 18:05, Vincent Bernat wrote: Hi! I got some bug reports from Jakub about double build failures. I have always found those kind of tests a bit silly, but that's just my opinion. Most of the time, the failures are because of the created egg directory that is not cleaned up by the clean target of setup.py. While I could add the appropriate bits to each clean target in debian/rules, it seems better to fix the problem either in dh_python2 or in setuptools. Any thoughts? IMHO it is a better fit in dh_auto_clean (python_distutils buildsystem) and or dh_clean. -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Double build failures
* Vincent Bernat ber...@debian.org, 2012-05-04, 19:05: I got some bug reports from Jakub about double build failures. I have always found those kind of tests a bit silly, but that's just my opinion. Most of the time, the failures are because of the created egg directory that is not cleaned up by the clean target of setup.py. While I could add the appropriate bits to each clean target in debian/rules, it seems better to fix the problem either in dh_python2 It's none of dh_python2's business. or in setuptools. Ideally, by burning it with fire. -- 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/20120504171955.ga4...@jwilk.net
Re: Double build failures
On Fri, May 4, 2012 at 7:19 PM, Jakub Wilk jw...@debian.org wrote: or in setuptools. Ideally, by burning it with fire. CPython upstreams are developing a new module to replace distutils and setuptools: packaging. It might be worth check with them if it will handle this case. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/cab4xwxxtetmgztyhxikoc6zqxr+mmaw87-mfof_rah-5oy6...@mail.gmail.com
Re: Double build failures
On Fri, 04 May 2012, Dmitrijs Ledkovs wrote: Most of the time, the failures are because of the created egg directory that is not cleaned up by the clean target of setup.py. While I could add the appropriate bits to each clean target in debian/rules, it seems better to fix the problem either in dh_python2 or in setuptools. Any thoughts? IMHO it is a better fit in dh_auto_clean (python_distutils buildsystem) and or dh_clean. +100 for dh_auto_clean ;-) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- 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/20120504172943.ge9...@onerussian.com
Re: Double build failures
On 04/05/12 18:23, Sandro Tosi wrote: On Fri, May 4, 2012 at 7:19 PM, Jakub Wilk jw...@debian.org wrote: or in setuptools. Ideally, by burning it with fire. CPython upstreams are developing a new module to replace distutils and setuptools: packaging. It might be worth check with them if it will handle this case. I swear last week it was called distribute... (if a buildsystem changes it's name more often than every 10 years think twice before using it.) -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Double build failures
* Yaroslav Halchenko deb...@onerussian.com, 2012-05-04, 13:29: Most of the time, the failures are because of the created egg directory that is not cleaned up by the clean target of setup.py. While I could add the appropriate bits to each clean target in debian/rules, it seems better to fix the problem either in dh_python2 or in setuptools. Any thoughts? IMHO it is a better fit in dh_auto_clean (python_distutils buildsystem) and or dh_clean. +100 for dh_auto_clean ;-) #652617 But... Have you read python_distutils.pm source? I did and then couldn't sleep for a few nights. ;) So I can't second the idea of adding even more dubious logic to it. -- 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/20120504180328.ga6...@jwilk.net
Re: Double build failures
On Friday, May 04, 2012 06:38:30 PM Dmitrijs Ledkovs wrote: On 04/05/12 18:23, Sandro Tosi wrote: On Fri, May 4, 2012 at 7:19 PM, Jakub Wilk jw...@debian.org wrote: or in setuptools. Ideally, by burning it with fire. CPython upstreams are developing a new module to replace distutils and setuptools: packaging. It might be worth check with them if it will handle this case. I swear last week it was called distribute... (if a buildsystem changes it's name more often than every 10 years think twice before using it.) distribute is a fork of setuptools. distutils is still distutils, so you can use it only thinking once. Scott K -- 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/4740075.3CZbIJrSJo@scott-latitude-e6320
Re: Double build failures
On 04/05/12 19:04, Scott Kitterman wrote: On Friday, May 04, 2012 06:38:30 PM Dmitrijs Ledkovs wrote: On 04/05/12 18:23, Sandro Tosi wrote: On Fri, May 4, 2012 at 7:19 PM, Jakub Wilk jw...@debian.org wrote: or in setuptools. Ideally, by burning it with fire. CPython upstreams are developing a new module to replace distutils and setuptools: packaging. It might be worth check with them if it will handle this case. I swear last week it was called distribute... (if a buildsystem changes it's name more often than every 10 years think twice before using it.) distribute is a fork of setuptools. distutils is still distutils, so you can use it only thinking once. ok. what is the relationship between 'distribute' 'packaging'? -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Double build failures
On 4 May 2012 19:06, Dmitrijs Ledkovs x...@debian.org wrote: ok. what is the relationship between 'distribute' 'packaging'? Let's see if I get all these right: distutils: basic packaging functionality, part of the Python standard library setuptools: third party module to add functionality that distutils lacked distribute: continuation of setuptools after setuptools development stopped packaging, aka distutils2: Improving on distutils but not backwards compatible, will be integrated into the standard library for Python 3.3, and might then make setuptools/distribute obsolete. Please correct me if I've got any of that wrong. Thomas -- 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/CAOvn4qiG6-kqWUh2vsHV03=6hoY9=sqy8ryo-rh2+xrvo3e...@mail.gmail.com
Re: Double build failures
On May 04, 2012, at 07:16 PM, Thomas Kluyver wrote: On 4 May 2012 19:06, Dmitrijs Ledkovs x...@debian.org wrote: ok. what is the relationship between 'distribute' 'packaging'? Let's see if I get all these right: distutils: basic packaging functionality, part of the Python standard library setuptools: third party module to add functionality that distutils lacked distribute: continuation of setuptools after setuptools development stopped packaging, aka distutils2: Improving on distutils but not backwards compatible, will be integrated into the standard library for Python 3.3, and might then make setuptools/distribute obsolete. Please correct me if I've got any of that wrong. Well done! A few minor corrections. - packaging is available in Python 3.3 (alpha) now. - distutils2 is the backport of packaging to older Pythons, available in the Cheeseshop. Actually, the Cheeseshop entry has a pretty good explanation: http://pypi.python.org/pypi/Distutils2 Cheers, -Barry -- 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/20120504142850.233c9...@resist.wooz.org
Re: Double build failures
On Fri, 04 May 2012, Jakub Wilk wrote:
* Yaroslav Halchenko deb...@onerussian.com, 2012-05-04, 13:29:
Most of the time, the failures are because of the created egg
directory that is not cleaned up by the clean target of
setup.py. While I could add the appropriate bits to each clean
target in debian/rules, it seems better to fix the problem
either in dh_python2 or in setuptools. Any thoughts?
IMHO it is a better fit in dh_auto_clean (python_distutils
buildsystem) and or dh_clean.
+100 for dh_auto_clean ;-)
#652617
But... Have you read python_distutils.pm source? I did and then
couldn't sleep for a few nights. ;) So I can't second the idea of
adding even more dubious logic to it.
LOL
I just don't know perl (un)fortunately to provide a clean patch... nor out of
my ignorance I am sure on the purpose of distributing .egg-info/ by
upstreams
$ zgrep .egg-info deb/docs/Contents-sources.gz | f1 | uniq | wc -l
365
so the question would also be either they get modified at package build-time so
that original versions would need to be placed aside (similar to what
dh_autoreconf does?) and then reverted back upon clean. So general resolution
could go a bit aside of just 'cleaning' through
* preserve present .egg-info somewhere (where below find would not find ;) )
* add to sub clean
$this-doit_in_sourcedir('find', '.', '-name', '*.egg-info', '-exec', 'rm',
'-rf', '{}', ';');
* bring them back and destroy the original copy
or if nothing get modified just remembering the list of them and
excluding them from clean up procedure
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
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/20120504183023.gq9...@onerussian.com
Re: Packaging python-mocker and cloud-init in Debian ?
On Fri, 4 May 2012, Charles Plessy wrote: Le Thu, May 03, 2012 at 11:24:34AM -0400, Scott Moser a écrit : My goal would be to keep minimal changes from debian to ubuntu, and the code there does not cause any issues that i'm aware of if there is no readahead installed. Is there some policy that explicitly calls that out? For ureadahead in particular, I was worried that it could cause problems as the package does not exist in Debian. After reading how diversions work (I never used them before), it looks like it would be harmless to keep that Ubuntu-specific code in the package for Debian. But more in general, I wonder if diversions are the good tool here. - In the cloud-init packiage they are used to disable ureadahead. Isn't there a more propre way for package A to disable a service provided by package B ? If ureadahead must never run when cloud-init is installed, its upstart job could test if cloud-init is installed and exit in that case. Or, if ureadahead and cloud-init should not be installed together, wouldn't a simple Conflicts: statement solve the problem ? Disabling of readahead via diversion is the correct path in my opinion. ureadahead is a dependency of 'ubuntu-minimal'. So that is why we've not conflicted with it. ureadahead does not make sense in any virtual machine. cloud-init was designed to run in virtual machines... so we disable it. cloud-init has recently been running more on real hardware, where re-enabling ureadahead might make sense. I just opened a bug for that at https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/994698 , but I consider it pretty low priority. - In the grub-legacy-ec2, diversions are used to take over grub-set-default from grub-legacy or grub2-common. These two packages manage this situation by conflicting with each other. Wouldn't it be simpler to also conflict with grub-legacy and grub2-common, or are there situations where they should be installed together ? grub-legacy-ec2 does conflict with grub. grub-legacy-ec2's purpose in life is to manage /boot/grub/menu.lst without worrying about installing a bootloader. This is because EC2 instances typically boot via pv-grub, which is a grub-alike that lives outside the image, but reads /boot/grub/menu.lst from inside the image. It explicitly does not conflict with grub-pc so you can create one image (like one from cloud-images.ubuntu.com) that can run with grub-pc as the bootloader or pv-grub as the bootloader. I am now looking at update-grub-legacy-ec2. It uses debconf and ucf directly, wich make the package more complex (and will trigger extra work for the translations). It looks like this was carried over from Ubuntu's grub-legacy package. Is it still necssary in grub-legacy-ec2's context ? Otherwise, I would be tempted to remove that part, in order to simplify the package. We could separate grub-legacy-ec2 into its own source package, I would support doing that, but its presense is necessary as described above.
Re: RFS: python-unicodecsv (Closes: #669678)
On Fri, 2012-04-27 at 00:39 +0200, Jakub Wilk wrote: * Thomas Bechtold thomasbecht...@jpberlin.de, 2012-04-26, 06:48: i fixed all the stuff (see comments below) and uploaded a new package to mentors.debian.net . if there are no other issues, i'll add the debian-dir to the python-modules svn Please feel free to inject the package even though there are some (minor) issues. :) We turn a blind eye to non-perfect packages in our svn. ;) done. thanks. i forwarded the patch upstream and included the patch in debian/patches I think Forwared should be simply: Forwarded: https://github.com/jdunck/python-unicodecsv/pull/11 (The DEP-3 specifications reads: “Any value other than no or not-needed means that the patch has been forwarded upstream. Ideally the value is an URL proving that it has been forwarded and where one can find more information about its inclusion status.”) Please test against all supported Python versions, not only the default one. at build time? how to do this? what are the build dependencies in debian/control python-all done. ...But you shouldn't have removed python (= 2.6.6-3~), as this version is needed for dh_python2. Alternatively, you could make python-all versioned. (This is not very important, as the required version is available in stable anyway.) fixed this already in svn. What are build/* in debian/clean and rmdir unicodecsv.egg-info | true in debian/rules for? They look suspicious to me. when i build the package, the directories build and unicodecsv.egg-info are created. i thought i have to remove both during the clean. -- 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/1336164517.11133.2.ca...@salbei.fritz.box
Re: Help in packaging rubber
On 04.05.12 Andreas Noteng (andr...@noteng.no) wrote: On 04. mai 2012 12:01, Hilmar Preuße wrote: Hi, Correct. It applies to a preview for a new upload, which is on my PC. I just wanted to document, which changes I've applied for the dh_pysupport - dh_python2 migration. It's kind of hard to say without seeing the whole package, but if you get it into SVN it'll be easy to see. The version the patch applies to is here: http://wagner.debian.org/~hilmar-guest/rubber/ I don't have write access to your SVN yet (AFAICT). I just sent the join request on alioth (https://a.d.org/projects/python-apps/) Should I make the package team managed, i.e. python-apps-t...@lists.alioth.debian.org as maintainer? python-apps-t...@lists.alioth.debian.org should be in either maintainer or uploaders. I'll fix that ASAP. H. -- http://www.hilmar-preusse.de.vu/#206401 http://counter.li.org signature.asc Description: Digital signature
Re: please help with a pbuilder error on local debug.
Hello, I had the same issue again: how to solve pbuilder-satisfydepends-dummy dependencies? https://answers.launchpad.net/ubuntu/+source/pbuilder/+question/196073 I would appreciate your help here to make the thing flow. Kind regards. -- 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/jo1lgk$8qh$1...@dough.gmane.org
Re: please help with a pbuilder error on local debug.
On 4 May 2012 23:33, Tim Michelsen timmichel...@gmx-topmail.de wrote: how to solve pbuilder-satisfydepends-dummy dependencies? https://answers.launchpad.net/ubuntu/+source/pbuilder/+question/196073 Looking at which packages it says aren't installable, I would guess that your pbuilder environment isn't set up to get packages from universe. For my pbuilder, I copied the .pbuilderrc file from here: https://wiki.ubuntu.com/PbuilderHowto#Multiple_pbuilders Note this line for Ubuntu (there's an equivalent for Debian): COMPONENTS=main restricted universe multiverse After you've changed the repositories a pbuilder environment sees, I think you need to run with --override-config for it to pick up the change. Or if you're unsure, you can just delete the environment tarball and create a new one. Thomas -- 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/caovn4qic9zj9wri5nfksv4ocnlrvfe6ts6y_pf3dcdcby7b...@mail.gmail.com
