On 31 March 2014 18:54, Jelmer Vernooij <jel...@samba.org> wrote: > Note that Brian is also a DD and maintainer of various packages. He should > be > aware of the process. :) > http://qa.debian.org/developer.php?login=bam
Need to think about it if is worth while for Debian as a whole. I am starting to get an accumulation of Packages that in my private repository, some of these perhaps should get pushed to Debian. http://code.vpac.org/debian/dists/sid/main/binary-amd64/Packages Generally, there are three categories: * Packages that are not in Debian, but I need. * Packages that are too old (and in some cases completely broken) in Debian (e.g. django-celery). * Packages that are buggy in Debian, and are unusable without patching (e.g. django-south). Getting back on track, I have an old version of pbs_python (using the non-debian complaint name used by upstream debian/control file), , however was looking at the latest version. It isn't a high priority. In fact, I am not even sure how to test it. I have inherited django-pbs, which requires it. http://code.vpac.org/debian/pool/main/p/pbs-python/ Unfortunately, pbs_python seems to be rather ... creative ... in its packaging techniques. eg. autoconf builds Makefile and setup.py from Makefile.in and setup.py.in, and the Makefile calls setup.py. My initial attempts at creating a Debian package result in errors from the Makefile (looks like it is trying to install the LICENSE.openpbs file in /). My limited understanding is that python packages are suppose to be distributed with a setup.py, not a setup.py.in. -- Brian May <br...@microcomaustralia.com.au>
