Re: How does team maintenace of python module works?
On 17/02/2013 07:10, Barry Warsaw wrote: > [...] > OTOH, there's no doubt there are rough edges. Heck, I would even support a > transition to git if the workflow were largely similar to Ubuntu's source > branches, but with better quilt integration. To me, something like that is my > packaging nirvana. git-buildpackage has gbp-pq which works pretty nicely. I've been using it for a while now. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFR: python-qrcode -- native python module to generate QR codes
Am 16.02.2013 15:42, schrieb Jakub Wilk: > * Cornelius Kölbel , 2013-02-14, 16:53: >> http://mentors.debian.net/package/qrcode > > Link to .dsc for the lazy: > http://mentors.debian.net/debian/pool/main/q/qrcode/qrcode_2.4.2-1.dsc > (2.4.2-1) > > Please drop the preinst script. It's purpose was to clean up after > python-central in lenny. But this package obvious hasn't been in lenny > and have never used python-central. > > unexporting *FLAGS in d/rules makes little sense, given that this > package is pure-Python, and therefore isn't affected by any of those. > > "pedantic […] error" is an oxymoron… But anyway, I don't see a point > in mentioning in the changelog that you fixed issues reported, given > that this is an initial upload. > > lintian emits: > P: python-qrcode: no-upstream-changelog > > There's CHANGES.rst, you might want to install it as upstream changelog. > > Shipping README.rst is probably a good idea, too. > > lintian4python emits: > w: qrcode source: xs-python-version-current-is-deprecated > i: qrcode source: python-provides-considered-harmful python-qrcode > i: qrcode source: python-stdeb-boilerplate debian/rules:3 "This file > was automatically generated by stdeb 0.6.0" > w: python-qrcode: xb-python-version-is-deprecated > > Please see Developer's References §6.2.3 for guidelines for package > descriptions. > > The manual page leaves a bit to be desired: > - It doesn't document the --factory option. > - The manpage title (the first argument to .TH) should be written in > uppercase; and it should certainly should not be "man". > - The "COMMON OPTIONS" section should be renamed as "OPTIONS". > - The "INTERNET SOURCES" section should be probably renamed as "SEE > ALSO" (but I'm not sure it's worth including it at all). > - man-pages(7) strongly discourages "AUTHOR(S)" sections. > Hello Jakub, thanks a lot for your feedback. I think I took care of all your comments - although I was not able to run your lintian4py. Should I increase the version to 2.4.2-2 or is this version only increased, _after_ a package is released? Thanks a lot and kind regards Cornelius signature.asc Description: OpenPGP digital signature
Re: Package adoptions
❦ 4 février 2013 20:00 CET, Örjan Persson : > I don't have the time to maintain my packages anymore. I just wanted to > check with you guys first if you're interested in adopting the packages > before I RFA them. The packages are python-setproctitle[1], > python-greenlet[2] and python-gevent[3]. > > [1] https://github.com/op/pkg-python-setproctitle > [2] https://github.com/op/pkg-python-greenlet > [3] https://github.com/op/pkg-python-gevent I am currently too short on time to do anything but I have high interest in both setproctitle and gevent and therefore if nobody steps in, I will maintain them under the DPMPT. I could also take python-greenlet since it seems in good shape. -- Don't stop at one bug. - The Elements of Programming Style (Kernighan & Plauger) pgpCFgF5vvtXu.pgp Description: PGP signature
Re: Package adoptions
On 02/18/2013 04:43 AM, Vincent Bernat wrote: > ❦ 4 février 2013 20:00 CET, Örjan Persson : > >> I don't have the time to maintain my packages anymore. I just wanted to >> check with you guys first if you're interested in adopting the packages >> before I RFA them. The packages are python-setproctitle[1], >> python-greenlet[2] and python-gevent[3]. >> >> [1] https://github.com/op/pkg-python-setproctitle >> [2] https://github.com/op/pkg-python-greenlet >> [3] https://github.com/op/pkg-python-gevent > I am currently too short on time to do anything but I have high interest > in both setproctitle and gevent and therefore if nobody steps in, I will > maintain them under the DPMPT. I could also take python-greenlet since > it seems in good shape. I may help as well with python-greenlet if needed. It's a dependency for ceilometer, cinder, heat, keystone and nova... 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/51214a92.30...@debian.org
Re: [Openstack-devel] New version of python-fixtures for debian experimental
On 02/15/2013 03:23 PM, Robert Collins wrote: > +1 on what you've done and what you propose. If you want to set > Maintainer to DPMT and commit it to the DPMT svn repository at the > same time, that would be awesome. Robert, Both python-fixtures and python-testtools are now stored in the SVN of the python module team. Note that python-fixtures doesn't have the correct VCS fields yet, but it's not a big deal, since I was planing (with your agreement) to switch from CDBS to dh, so this will happen on the next upload. Both the latest versions of python-fixtures and python-testtools are now uploaded to Experimental. By the way, is there a Git repository for these packages? I've found one for testtools: https://github.com/testing-cabal/testtools but not for -fixtures. Cheers, 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/5121a7fb.3060...@debian.org
Re: [Openstack-devel] New version of python-fixtures for debian experimental
On 18 February 2013 17:03, Thomas Goirand wrote: > On 02/15/2013 03:23 PM, Robert Collins wrote: >> +1 on what you've done and what you propose. If you want to set >> Maintainer to DPMT and commit it to the DPMT svn repository at the >> same time, that would be awesome. > > Robert, > > Both python-fixtures and python-testtools are now stored in the SVN of > the python module team. Note that python-fixtures doesn't have the > correct VCS fields yet, but it's not a big deal, since I was planing > (with your agreement) to switch from CDBS to dh, so this will happen on > the next upload. > > Both the latest versions of python-fixtures and python-testtools are now > uploaded to Experimental. > > By the way, is there a Git repository for these packages? I've found one > for testtools: > https://github.com/testing-cabal/testtools > > but not for -fixtures. Awesome, thanks. -fixtures is currently maintained in bzr; I'm considering its hosting future at the moment, pending how the testing-cabal feel the git experiment with testtools pans out. -Rob -- Robert Collins Distinguished Technologist HP Cloud Services -- 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/caj3hoz1kl-yqpmeg-pzz9hxg1xdvxerdzaqdrlftsydg1ky...@mail.gmail.com
