On Mon, Nov 15, 2010 at 08:59:31PM +0100, Philipp Kern wrote: > On Mon, Nov 08, 2010 at 12:10:23PM +0000, Roger Leigh wrote: > > I'm afraid this isn't just minimal bugfixing, it's basically three new > > upstream releases worth of changes. But, I think it's important to > > have in squeeze for these key improvements: > > > > • dpkg-source v3 support > > The buildd-0.60.0 branch in production is based on... 0.60.0. So it should > already have that support? Could you please clarify? Certainly. The buildd branch has the dpkg-source v3 code backported into it from the master branch; the version of sbuild in unstable and testing can not build v3 sources. It may be able to build some v3 packages, but it's limited to sources using .dsc/.diff.gz/.orig.tar.gz; no .tar.bz2 or quilt or multiple tarballs etc. Specifically, it's missing commit ba54dd628d1f5a3c72286242e5e6c6731fe3367a Author: Roger Leigh <firstname.lastname@example.org> Date: Mon May 3 13:55:48 2010 +0100 Sbuild::Build: Remove DSC filename assumptions breaking new source formats commit 7594a18ca7b7612af3f81a637cc378d484d642c7 Author: Roger Leigh <email@example.com> Date: Sat Jun 12 16:58:43 2010 +0100 Sbuild::Build: Don't use '-sn' with 'dpkg-buildpackage -x' The latter is just cosmetic to avoid dpkg-source moaning that -sn is unsupported with v3 sources. The former is absolutely required. > > • integration with the schroot version in squeeze (currently it has no > > namespace support, and the sbuild-* helper programs are broken) > > • correct removal and reinstallation of Build-Conflicts > > > > and these "nice to have" improvements: > > > > • uses the aptitude build dependency resolver in place of the old, buggy, > > and unmaintainable internal resolver > > Which is still used in production... Absolutely. As discussed on #debian-buildd, we'll be keeping it as the default until it's replaced on the buildds. But it's certainly buggy and unmaintainable going forward, and the newer apt and aptitude resolvers are far simpler, delegating all dependency resolving to the package manager. While there are still concerns about predictability/ determinism of the new resolvers which we have yet to fully test and satisfy, this is not an issue for end-users running squeeze who want to build packages. > > • direct building from unpacked source trees, á la debuild et al > > • support for running lintian and piuparts > [...] > > If you would consider this for migration to testing, that would be > > great. I do anticipate making another release to address any issues > > that come up over the next week, so there's no rush to get the current > > version in unstable in right now; I just want to have a less buggy > > version in the squeeze release that's worthy of putting in the release. > > I'm not exactly sure that the new version is fit for releasing. Are there any particular issues which need addressing? There's the required libdpkg-perl issue you've already fixed in git, but this doesn't affect squeeze/unstable, only lenny. Regarding bugginess, I've fixed over 30 bugs in the past fortnight, and a lot of those were hard to tackle issues, some of which had been outstanding for years. It's in far, far better shape than what we have in squeeze. It certainly won't hurt to let it sit in unstable for a few weeks to shake out any potential regressions, but it would be nice for squeeze users to be able to build dpkg-source v3 sources. If nothing else, an upload to t-p-u containing just the above two commits would be better than leaving it. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Description: Digital signature