[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#610689: sbuild: cross build support

Hi Roger,

A bit late, but I have not found the time before to look into this.

2011/3/10 Roger Leigh <rleigh@codelibre.net>:

> [...]
> The first part all looks good.


>>   Install cross toolchains in the chroot
>>     schroot -u root -c /srv/chroot/sid-amd64-sbuild
>>     echo "deb http://emdebian.org/debian squeeze main" >>
>> /etc/apt/sources.list.d/emdebian.list
>>     apt-get update
>>     apt-get install linux-libc-dev-armel-cross libc6-dev-armel-cross \
>>         gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi
> This part can be done by the xapt resolver directly, without any
> special user setup required.


> For the cross-packages, you can add these to the core build
> dependencies list, so they will be installed along with build-essential
> etc.  Or (better) you can add a separate XAPT_DEPENDS variable which can
> be appended to CORE_DEPENDS in Build.pm prior to installing the core
> dependencies.  Does xapt not bring in these packages directly, or do
> they always need installing by hand?

xapt downloads the foreign architecture packages using APT with -o
APT::Architecture=$HOST_ARCH into a directory controlled by xapt
(/var/lib/xapt/, irrc), then throws dpkg-cross into that directory to
convert those packages and installs them.

> Well, when we install the build dependencies the package isn't yet
> unpacked.  The unpacking is done in the build() function.  But there's
> no reason we can't reorder it if we need to.  The unpacking could
> be split out of build() into a separate unpack_source() function,
> which could be run earlier if xapt/embuilddeps is in use.
> What information does embuilddeps require from the unpacked source
> package?  Is this information also available in the .dsc? (We do
> have the .dsc information directly to hand).

It is possible to use .dsc information, but embuilddeps does not know
how (yet). :-)

> xapt is doing two jobs it seems:
> 1) from the package list, make a list containing all the cross packages
>   needed

That is given with simulation option (-n).

> 2) install them (but it doesn't list them in the list of packages to
>   install, which makes removal harder potentially)
> From the resolver POV, what would be really good if it could just do
> (1).  This way, we can just give the expanded list back to the
> resolver for it to install.  Because we need to clean up after
> ourselves, the apt and aptitude resolvers build a dummy
> "dependency package" from the dependency list, and then get apt/
> aptitude to install it.

This is how old pbuilder used to do it, but it does not work with
cross packages as adding dependencies on
$foreign_package-$HOST_ARCH-cross won't work, as those packages are
output from dpkg-cross and not available from repositories.

> We then reverse the process to clean up
> after the build.  So ideally, we don't really want xapt to do any
> installation: we just want it to give us the package list.  If
> this is possible, it might not even be require to have a separate
> XaptResolver--we just expand the cross-dependencies and give them
> to the regular resolver.
> If xapt can't do this directly, how complex is the code that
> implements (1)?  Would it be possible to split it out as a separate
> tool?

embuilddeps -a armel -d /path/to/source -n will give you that
information, and /path/to/dsc might be in the way.
We really need to think more about how we are going to do it to be
able to fit multiarch in the cooking.

> I've rebased your patches against current sbuild.git master, and
> they may be found here: git://git.debian.org/users/rleigh/sbuild.git

I tried to work on top of that, but it did not build for me.

I'll be looking into how to fit pieces together for cross and
multiarch support. Let you know once I get something.

Best regards,
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html

Reply to: