[buildd-tools-devel] Bug#610689: sbuild cross support

[Roger Leigh]

On Mon, Dec 12, 2011 at 02:19:20PM +0000, Wookey wrote:
> +++ Roger Leigh [2011-12-12 11:51 +0000]:
> > On Sat, Dec 10, 2011 at 12:25:15AM +0000, Wookey wrote:
> > > +++ Roger Leigh [2011-12-09 16:48 +0000]:
> > > > On Fri, Dec 09, 2011 at 04:30:20PM +0000, Wookey wrote:
> > > > 
> > > > WRT building, it should build directly from git with plain
> > > > dpkg-buildpackage.  I normally configure, do a "make dist" and then
> > > > build the Debian packages (for upload) from the resulting tarball.
> > > > This shouldn't be necessary just for working on sbuild though--
> > > > that's just to get a pristine build from a clean tree.
> > > > 
> > > > I think the error is likely a result of the changes made to
> > > > configuration file parsing around 27th of February
> > > > (commit 3fa12596 and later).  It's likely the cross-build
> > > > changes to this file need reworking to fit in with the new
> > > > parsing scheme.  If you don't get anywhere with it, I'll try
> > > > to take a look on Monday as time permits.
> > > 
> > > Ah, spot-on; that was enough clue to get that fixed. 
> > > 
> > > Now I can build it but installation failed because both sbuild and
> > > schroot try to install /etc/schroot/buildd/nssdatabases
> > > 
> > > Not clear to me which package should really be in charge of that? I
> > > just let it force-overwrite for now.
> > 
> > I don't know if you saw my comments on IRC last night.  
> 
> No, My IRC-client-running server was rebooted this morning so all
> logged IRC chat has gone.
> 
> > I think this
> > is possibly due to using the buildd git branch, that is
> > buildd-0.62.5 or similar.  The actual release "release/sbuild-0.62.5"
> > and the master branch do not contain these files.
> 
> Aha. git branch -a doesn't show 'release/sbuild-0.62.5'. I picked
> 'origin/buildd-0.62.5' as a plausible-looking branch to use.
> 
> I should probably just move forward to 'master', but I wonder where
> the branch you mention has got to?

Ah, it's a (GPG-signed) release tag, rather than a branch.  You can
run "git tag -l" to view them.  They behave almost like branches,
in that you can do "git checkout $tag", and you can branch from them,
but you can't commit to them.  In this case, it's a tag on the master
branch.  The latest is release/sbuild-0.62.6.

> > I should be able to merge some of the more trivial parts such as
> > the command-line options and associated configuration parameters
> > into master later this week.
> 
> Cool. I was hoping to have something actually working by now so I
> could provide some tested patches, but I'm stuck on the queries I put
> in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610689#82
> 
> mostly 'what's the best way to get 'apt-get build-dep -aarmel
> $package' run and what mechanism to use to get dpkg foreign-arch
> config, pkg-config triplet config and apt foreign-arch sources set up.

I'm not sure about the latter bits off the top of my head, but the
"apt-get build-dep" part is fairly simple.  We don't use "apt-get
build-dep" directly--it's not sufficient due to the way it resolves
alternative (and virtual) dependencies.  Instead, we create a
"dummy" dependency package, and set up a tiny apt archive inside the
build chroot, which gets added to /etc/apt/sources.list.d.  We then
"apt-get install" the dummy package, which contains the filtered
build-dependencies.  This is the mechanism used the "apt" and
"aptitude" resolvers; the older "internal" resolver does this a
rather harder and more fragile way, but hopefully internal will
go away soon.  I don't think it's worth adding multi-arch support
to it, should multi-arch require resolver-specific work.

This mechanism also permits the addition or removal of arbitrary
deps, e.g. addition of gcc-snapshot, build-essential and other
things.  We also allow multiple dependency packages to be installed,
e.g. a core depends package containing build-essential, and
package build-depends containing the package-specific deps.  We
could also add an additional one for multiarch deps (or just add
them to the core or package deps as needed).

This system is implemented in lib/Sbuild/*Resolver*.pm.  You can
see it used in lib/Sbuild/Build.pm in run_fetch_install_package().
If you need specific packages installing for cross-builds, here
would likely be the place for it (if it's generic), or in the
resolver base (if it's package-specific).

Given that the full power of apt/aptitude's dependency resolving
is available, you can just use standard multi-arch dependency
syntax to get arch-specific packages installed.  You would probably
need to also have dpkg/apt configured to download that arch's
Packages list; this could be done either by the admin, or by
sbuild each time it's run.  If it's just an occasional cross-build,
it would be OK to fetch each time, but if it's to be used much
more frequently then manual setup might make more sense.  I think
to start with, it would help to know exactly what needs configuring
inside the chroot, then we can work out what should be responsible
for doing it.

I'm not sure what needs doing WRT pkg-config; I assumed that
setting --host and --build when running configure would suffice.
Is anything additional needed?


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.