I know it would have been better if I would have asked a request for adoption, but, honestly, the package didn't had a maintainer in the last year and that would have been lying to everybody.
The package is quite important and I would hate to see it leave the official archive since many people do need it and use it regularly (I know for sure the GNOME, Perl and the Debian Games Team use it) and I have enjoyed working on the package while I was motivated.
The code is maintained in SVN and the trunk can be viewed at:
and can be checked out with any of these commands:
# read-only copy
svn co svn://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/trunk svn-buildpackage
# read write, if you have an account on alioth.debian.org:
svn co svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/trunk
Also, note that the package has several features which the new maintainer(s) should be aware of and must make sure they all work when changing the code. Also, there are some things to remember:
- there is support for native and non-native packages
- non-native packages' repo can be a complete repo (with an upstream branch) or an incomplete repo (just the differences from the upstream - most times the debian directory, but not always)
- there is an interactive and a non-interactive mode, both have to work properly
- the packages can be stored in the repo under 2 different layouts and both have to work since they are both used; support for an arbitary layout would be great and I have a few ideas about how to implement that, so please contact me if you want to work on that
- team maintainance workflow MUST be supprted and should be one of the highest concerns for the maintainer; this means that being able to work on a new package without issuing more than one command to have all necessary stuff for the build, package upgrades to be done is the target to reach for (currently the situation is a lot better than it was in the past)
- there is on misfeature from the past that should be finally dealt with - something that was supposed to work as a cache ended up working like an override; meanwhile the effect for new packages/checkout has been minimised, but the code could do better at dealing with old checkouts affected but this (drop the old file name for the overrides, use a new one and scream when the old file name is encountered)
- 0.6.24 is waiting for an upload
- a test frame is missing and would be most welcome; I already started working on this based on the git test frame, but didn't managed to have a good-enough-to-publish code
These being said, I am really hoping svn-buildpackage will find a new maintainer since it deserves a lot more attention than I am providing. Don't forget, 0.6.24 is wating for an upload already.
Update: Neil Williams answered and agreed to take over maintenance, but he doesn't usually use svn-inject and svn-upgrade, so somebody taking care of those would be needed. Ironically, those two scripts are the ones in the worst shape of the three main scripts.