Re: Git migration schedule
On Fri, 2015-10-09 at 10:47 -0400, Barry Warsaw wrote: > I'd also like to send an email to debian-devel@ inviting people who > may have abandoned the DPMT because of our use of subversion, to come > back to the team. Perhaps an email to d-d-announce would be in order. I for one don't regularly read debian-python (pyton-*-team even less for that matter). A short email of what changed with a few pointers to how we are working now. I think the wiki page may also be very useful for other teams. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Git migration schedule
On Fri, 2015-10-09 at 13:34 -0400, Barry Warsaw wrote: > On Oct 09, 2015, at 06:46 PM, Arthur de Jong wrote: > > Perhaps an email to d-d-announce would be in order. > > Good idea, thanks. Thanks everyone for the hard work. Time for me to learn a new tool ;) -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: [DPMT] radical changes: automation, carrot and stick
On Fri, 2015-10-02 at 09:12 -0700, Nikolaus Rath wrote: > I always assumed that it was generally preferred to have Python > packages be maintained in the Python team, even if the maintainer has > little interest or time in contributing to other Python packages. Same here. I have a few packages in DPMT and PAPT because I think it improves the overall quality of Debian packages if they are centrally maintained. Having centralised infrastructure and policy makes it much easier to fix things across many packages (e.g. helper package migrations or updating the (XS-)Vcs-* fields). I can't say I contribute regularly to other package in either of the repositories but once in a while I do have time to do QA-like work on a few packages that are team maintained. In short, I don't see why I am considered a problem for the team. I'm not saying I'm a hugely positive addition but removing my packages because I don't contribute much to other packages will not motivate me to do more and will probably have the opposite effect for when I do have some time to spare. Thanks, -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: [DPMT] radical changes: automation, carrot and stick
On Wed, 2015-10-07 at 14:18 +0200, Piotr Ożarowski wrote: > I assume you all like other ideas, like no team in Maintainer, right? I kind of liked the differentiation between the two options: - I'm the primary maintainer and welcome other people working on my packages (me in Maintainer, team in Uploaders) - I don't feel primarily responsible for the package but the package is useful (team in Maintainer, me in Uploaders) I think I only added packages in the first category but I also think I mostly contributed to other packages in the second category. For most of my packages I'm also upstream and I usually manage so I would appreciate a heads-up before someone else makes major changes to my packages. On the other hand, anything that would make it less work to help other packages would be positive. Avoiding spending time on trying to get feedback from people would be good. I think I'm OK with giving up some authority to my packages in exchange for lowering the total work required for maintaining all packages. In general it is probably a net positive for Debian to have less individual ownership of packages because it creates bottlenecks. I would welcome having more tools and policy around this. In that sense, switching to Git can probably help (thanks to everyone working on that). For example mailing pack...@packages.debian.org with a pull request would be great. By the way, still can't promise I'll be able to do much work on other packages in the near future ;) -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
getting rid of python-central
Hello lists, I've been seeing what it would take to remove python-central from my system and it wasn't actually that much so I sent patches to the BTS for the remaining packages and fixed a few python-apps-team and python-modules-team packages in SVN. The list of packages that remain to be fixed is not that long: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pycentral-deprecation;users=debian-python@lists.debian.org Would anyone object if I start working on updating packages in python-apps-team and python-modules-team SVN repositories that: - use python-central - and have the maintainer set to the respective team (apps: gmail-notify, modules: libapache2-mod-python, python-axiom, pyopengl) I would update the packages to use dh_python2 instead. I would also consider uploading to unstable if the other outstanding changes seem reasonable (assuming the package is already in unstable). What about updating these packages to use the dh sequencer in debian/rules? (again assuming this is not too disruptive) What about doing the same for the packages that have the respective team in the Uploaders field (apps: fusion-icon, hotssh, wapiti, andvare, autokey, modules: bugz, rope, pyexcelerator, louie, python-pytc, python-authkit, ropemacs, python-pysearch, sclapp, python-socksipy, python-xmltv, python-reportlab, python-irclib). I'd like to get some input on whether this is useful or considered meddling in someone else's packages. What about other kind of cleanup operations (e.g. while searching I found a couple of control files that grep-dctrl had issues with due to spaces being present on lines that should be blank, packages that seem to be in both repositories, etc)? Thanks, -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Bug#563391: Package Trac 0.12 as well
On Mon, 2011-07-11 at 17:05 +0200, W. Martin Borgert wrote: Quoting Arthur de Jong adej...@debian.org: I've updated the Trac packaging in svn://svn.debian.org/svn/python-apps/packages/trac/trunk to 0.12 and done some migration and cleaning up (see debian/changelog for details). Btw. could you please remove my now unused path svn://svn.debian.org/svn/python-apps/packages/trac-0.12/trunk please? Done. - Is the run-time dependency on python-setuptools required (or should it only be Build-Depends)? python-setuptools is indeed used by Trac (at least in 0.11), maybe for the plugins. Don't touch it :~) Thanks for the clarification. - There is a debian/package-it script that seems to do something similar to svn-buildpackage. Should it be removed? I assume that this script has been used by former maintainers. Just remove it. Done. I've tested the package and some basic things seem to work OK. As a test I've also upgraded a 0.11 environment and that also seemed to work OK, including a few plugins. I haven't tested all plugins or all functionality but that can be done in unstable shortly. Anyone want to provide a backport for squeeze? -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Bug#563391: Package Trac 0.12 as well
I've updated the Trac packaging in svn://svn.debian.org/svn/python-apps/packages/trac/trunk to 0.12 and done some migration and cleaning up (see debian/changelog for details). There are a few questions remaining: - Is the run-time dependency on python-setuptools required (or should it only be Build-Depends)? - There is a debian/package-it script that seems to do something similar to svn-buildpackage. Should it be removed? The package hasn't been tested yet and the trac plugins also need to be checked to see if they still work (maybe add Breaks where needed). Any help with testing is appreciated. If anyone could take a look at the packaging (I changed quite a lot) that would also be nice. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Packaging software for Cheeseshop and Debian
On Mon, 2007-10-22 at 10:09 +1000, Ben Finney wrote: Unfortunately, it doesn't run, failing with an ImportError. The modules are not installed to '/usr/lib/pythonX.Y/...', but only to '/usr/share/pycentral/gracie/site-packages/gracie/' which isn't on the system path for Python modules. A 'find /' for the modules shows that they *only* exist in that location. Isn't 'python-central' supposed to automatically put them in the version-specific locations? I develop and package webcheck [0] (a python application with private modules). I put all stuff in /usr/share/webcheck and use python-support for compiling the stuff there. I ship an /usr/bin/webcheck symlink to /usr/share/webcheck/webcheck.py. This seems to work fine. I don't know if setuptools or distutils supports packaging private modules. Then what is meant by the Python policy speaking of such things? I have only recently had a look at distutils [1] and have the impression that it is only meant for stuff that should end up in the system python path (please correct me if I'm wrong). [0] http://packages.debian.org/webcheck [1] http://www.python.org/doc/2.4/dist/dist.html -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
please review webcheck package
Hello list, I have revived the webcheck (website crawler) package and it has just been accepted into unstable. This is however my first experience with python and python packaging and I would appreciate a quick review from anyone who can spare the time. Some links: homepage: http://ch.tudelft.nl/~arthur/webcheck/ demo output: http://ch.tudelft.nl/~arthur/webcheck/demo/ package: http://packages.qa.debian.org/webcheck itp: http://bugs.debian.org/326429 I have a couple of questions also: webcheck ships webcheck.css and fancytooltips.js files that are installed in /usr/lib/python2.3/site-packages/webcheck/webcheck.css and /usr/lib/python2.3/site-packages/webcheck/fancytooltips/fancytooltips.js. This was done because they are searched for at runtime in the python path. Is there some better way of packaging webcheck? I have looked into the autoconf/automake that seems to do the trick. Is there some standard or preferred well documented way to install python applications? Thanks for any comments. Feel free to file bugs on any problems you find or mail me directly (I'm on the list but I rarely read it). -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
