Bug 664759: python-tox request for review/sponsorship
Bug 664759 is the ITP for python-tox. Back in June, Bradley M. Froehle provided an initial packaging. I finally found some time to take his work, add a few things (manpage, updated to latest tox version, debian/watch, lintian clean), and svn-injected it into the PAPT repo. http://anonscm.debian.org/viewvc/python-apps/packages/tox/trunk/ Reviews welcome, sponsorship even more so. :) Cheers, -Barry P.S. I know the manpage sucks; I'm trying to find some examples of Sphinx-generated manpages, after which I'll improve that. signature.asc Description: PGP signature
Re: pyxs review
On Friday, November 09, 2012 01:32:53 PM Thomas Kluyver wrote: > On 9 November 2012 12:44, Maykel Moya wrote: > > Even in the case of the more restrictive license applying only to > > debian/* work? Could you/someone elaborate a little the implications of > > this (link to fine documentation is welcomed)? > > I'm not sure if there's a Debian rule about it, but I'd consider it good > etiquette, if you're adding something to a much larger work, to follow the > author's lead on licensing. > > For instance: say you patch the code to fix a bug you notice while you're > packaging. You don't forward the patch at the time, but the upstream author > later sees it and wants to include it. If debian/ is under the same > license, he's free to use your code and credit you. If debian/ is more > restricted, he has to try to contact you to get an appropriate license. This isn't just a theoretical concern. I've had to do this when trying to upstream a patch that was provided to Debian with GPL licensing terms for a BSD licensed package. 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/6631952.Zg323h08oV@scott-latitude-e6320
Re: Sponsorship ??
* Joseph Mills , 2012-11-07, 16:51: Hello there I am not sure that this is going to the correct team but here it goes. I found this upstream http://qt.gitorious.org/qt-labs/gimp-qmlexporter so I took it and packaged it. Now I want to get it into debian so that it will make its-way to Ubuntu. What the plugin does. It takes Gimp images and exports them to qml. here is a video of it working. http://www.youtube.com/watch?v=2Hgo9CWV400 so as you can see it is just a plugin for gimp. But it is wrote in python so I thought that I would try this mailing list. I uploaded to mentors but I am not sure if it is there yet. For those who want to take a look, it's here: http://mentors.debian.net/debian/pool/main/g/gimp-qmlexporter/gimp-qmlexporter_0.0.1-8.dsc I don't intend to sponsor this, but here's my very quick review: Lintian emits: P: gimp-qmlexporter source: debian-control-has-unusual-field-spacing line 12 P: gimp-qmlexporter source: debian-control-has-unusual-field-spacing line 17 P: gimp-qmlexporter source: debian-control-has-unusual-field-spacing line 18 P: gimp-qmlexporter source: source-contains-git-control-dir .git X: gimp-qmlexporter source: python-depends-but-no-python-helper gimp-qmlexporter I: gimp-qmlexporter source: debian-watch-file-is-missing W: gimp-qmlexporter: empty-binary-package The last one is caused by a combination of missing build-dependencies and bug #683551. Once the build-dependencies are fixed, lintian4python emits: e: gimp-qmlexporter: python-module-not-byte-compiled usr/lib/gimp/2.0/plug-ins/qmlexporter.py w: gimp-qmlexporter: inconsistent-use-of-tabs-and-spaces-in-indentation usr/lib/gimp/2.0/plug-ins/qmlexporter.py:71 w: gimp-qmlexporter: usr-bin-env-python-shebang usr/lib/gimp/2.0/plug-ins/qmlexporter.py -- 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/20121109145433.ga8...@jwilk.net
Re: GUI tool for packaging
On Fri, 2012-11-09 at 13:19 +, Thomas Kluyver wrote: > In my opinion, the best way to do that is to build a GUI that holds > the user's hand through the process of packaging, showing them the > options available. It should be particularly useful for occasional > packagers who don't want to remember a load of commands and options. [... snipped ...] > So, I'd like to know: > - Do you think this is worth spending time on? Bear in mind it's > primarily aimed at new & occasional packagers, not experts who already > know the tools. > - Is there already anything like this? > - Would you be interested in helping to develop it? > > Of course, this should be useful for any packages, not just > Python-based ones. But I thought I'd float the idea here first, to get > some feedback before I take it any further. I think it is an excellent idea. There is a general problem of discovering rarely-used commands and/or options and using them to do something one does not need to do frequently. Existing documentation and help information are geared toward novices who will become experts, who make frequent use of the software. Such people eventually remember all the options of the software. What is missing is help for experts, who learned the software sometime ago but use it rarely and therefore with time they forget the minutiae and the details of using the software's options. --- Omer -- Your liberty to swing your fist ends just where my nose begins. Your freedom of expression ends where my freedom of expression begins. Your freedom of religion ends where my rights for equality and accessibility begin. My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html -- 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/1352468465.31981.74.camel@c4
Re: pyxs review
* Maykel Moya , 2012-11-09, 13:44: I'd advise you not to use a more restrictive license than upstream uses. Even in the case of the more restrictive license applying only to debian/* work? Could you/someone elaborate a little the implications of this (link to fine documentation is welcomed)? I couldn't find anything better than this (and I'm too lazy to elaborate in my own words :P): http://upsilon.cc/~zack/blog/posts/2012/02/gpl_d_debian_software_skew/ "[...] I don't have any issue with packaging in general being release under a different license, because most of it does not get linked or otherwise combined with upstream code. What worries me is that a different packaging license might induce unexpected license mixtures unless the maintainer is very careful. For one thing, debian/patches/ should not be under a different license than upstream software; doing so is dangerous in terms of license incompatibilities and in most cases would also make it very hard if not impossible to push the patch upstream. But that's not the only case, as there might be other Debian-specific code generated during build that might end up being loaded by upstream code." -- 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/20121109133345.ga6...@jwilk.net
Re: pyxs review
On 9 November 2012 12:44, Maykel Moya wrote: > Even in the case of the more restrictive license applying only to > debian/* work? Could you/someone elaborate a little the implications of > this (link to fine documentation is welcomed)? > I'm not sure if there's a Debian rule about it, but I'd consider it good etiquette, if you're adding something to a much larger work, to follow the author's lead on licensing. For instance: say you patch the code to fix a bug you notice while you're packaging. You don't forward the patch at the time, but the upstream author later sees it and wants to include it. If debian/ is under the same license, he's free to use your code and credit you. If debian/ is more restricted, he has to try to contact you to get an appropriate license. Thanks, Thomas
GUI tool for packaging
This is an idea I've had knocking around for a while. Packaging is complex - there are lots of different tools and syntaxes you have to understand to do a good job of it - quilt, debhelper, watch files, etc. - along with specialist terminology. I know various CLI tools aim to simplify things, but not everything can be automated, and the tools end up with lots of options to learn about. The upshot is that most open source developers rely on a relatively small number of specialist packagers to do the rather esoteric work of preparing Debian packages. To get this to scale, I think we need to encourage more upstreams to provide packaging - whether it's for inclusion in Debian, or to provide .deb packages themselves, like Google Chrome, MongoDB and Dropbox do. In my opinion, the best way to do that is to build a GUI that holds the user's hand through the process of packaging, showing them the options available. It should be particularly useful for occasional packagers who don't want to remember a load of commands and options. Ultimately, I envisage a kind of packaging IDE. But the bit I picked to implement first is a wizard to create a watch file. The user can select popular sites like Github or PyPI, enter a couple of details, and a (hopefully correct) watchfile is generated. Screenshot: http://i.imgur.com/YM2LT.png Code: https://bitbucket.org/takluyver/packagebench/src I imagine wizards like this could be a large part of this tool, for tasks like "Add a documentation package" or "Make DEP-8 tests". So, I'd like to know: - Do you think this is worth spending time on? Bear in mind it's primarily aimed at new & occasional packagers, not experts who already know the tools. - Is there already anything like this? - Would you be interested in helping to develop it? Of course, this should be useful for any packages, not just Python-based ones. But I thought I'd float the idea here first, to get some feedback before I take it any further. Thanks, Thomas
Re: pyxs review
El 08/11/12 23:08, Jakub Wilk escribió: Hello > I'd advise you not to use a more restrictive license than upstream uses. Even in the case of the more restrictive license applying only to debian/* work? Could you/someone elaborate a little the implications of this (link to fine documentation is welcomed)? I'll take care of the issues noted here, including contacting upstream regarding the blob and the inclusion of GPL-3 text. Thanks for the review. Regards, maykel -- 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/509cfac9.7000...@mmoya.org
