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 <rleigh@debian.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 <rleigh@debian.org>
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.
Attachment:
signature.asc
Description: Digital signature