Dear PAPT, I'm working on packaging new upstream release of the buildbot package. I've started some conversations on debian-mentors mailing list [1][2][3] concerning this package and was invited here by Sandro Tosi. Although the problem of maintainership of this package isn't solved[2] I'd like to fix the uncertain solutions described below. Due to described above maintainership problems I don't know whether it is allowed to put the sources under svn here so I still provide the URL from debian-mentors.
[1] http://lists.debian.org/debian-mentors/2010/08/msg00258.html [2] http://lists.debian.org/debian-mentors/2010/09/msg00008.html [3] http://lists.debian.org/debian-mentors/2010/09/msg00093.html The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/buildbot - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/buildbot/buildbot_0.8.1-1.dsc My changelog contains the following information: * New upstream version. Closes: #587313. - Fix homepage in debian/control Closes: #587314. - Fix CSS stylesheet is not set for index.html. Closes: #576284. * Switch to dpkg-source 3.0 (quilt) format * New manual pages for buildbot and buildslave binaries. * Split package into two according to new project structure. * Configuration is now stored in apache-like manner for better management. * Switch to /bin/sh interpreter in init-scripts Here are the things I'm not sure: 1. Changelog. The new upstream version fixes all bugs available in Debian BTS. Should I mention all of these bugs like I did or should I just set a list of bugs closed by new upstream without any details? 2. Naming. The upstream separated client and server code and now server binaries and the python package itself are still called `buildbot', and the client binaries and python package are called `buildslave'. However I used `buildbot-master' and `buildbot-slave' for naming packages and system users. The previous version of the package had one system user called `buildbot' however upstream documentation does not recommend such configuration. I could also use one user for both packages as before but I'm not sure how should postrm script work to purge the package (i.e. what to do with buildbot instances inside buildbot home directory). Should I use debconf and ask user during package installation? 3. Init scripts. Prevoius package used bash arrays defined in /etc/default/buildbot to list managed buildbot instances. I used apache-like configuration for both buildbot-master in /etc/buildbot/masters-(available|enabled) and buildbot-slave in /etc/buildbot/slaves-(available|enabled) with almost the same configuration options as were in previous package. However the init-scripts themselves grew dramatically. I also admit that such configuration still needs the buildbot configuration files in /etc/buildbot to be valid shell scripts since they are sourced by init-scripts which is definitely a bad idea. For now I don't know how to solve this problem properly. Also there is no strict mechanism to detect buildbot startup failure and some failure cases are not detected automatically. 4. Unified configuration. I tried to make some unified configuration for all system managed buildbot instances, e.g. use common places to store pids (/var/run/buildbot-*) and logs (/var/log/buildbot-*). I didn't like the way to store all logs from different buildbot instances (which especially have been running by different users) and found the solution in screen package. It uses username as a folder to store files for every user. For example, if we have buildbot master instance called `testbot' which is run by `test' user, we'll have PID-file in /var/run/buildbot-master/test/testbot.pid and log file in /var/log/buildbot-master/test/testbot.log. I should mention that upstream version 0.8.1 had some issues concerning logging (http://buildbot.net/trac/ticket/973) which is fixed in the next release so I added this fix as a patch until the next release. 5. `#! /usr/bin/env python' in scripts generated by setuptools. Curently this is fixed with `sed -i'. I wonder if there is a better solution. I really would like to hear your opinions on this. Thanks in advance. -- with best regards, Andriy Senkovych -- 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/aanlktin6zmdtypq1dojkpn+yofv5n5x3kx2ad4uac...@mail.gmail.com
