[buildd-tools-devel] Bug#609151: Bug#609151: sbuild reported architecture is wrong when using a chroot with a personality

Roger Leigh rleigh at codelibre.net
Fri Jan 7 19:30:51 UTC 2011


On Thu, Jan 06, 2011 at 02:11:08PM -0600, Jamie Strandboge wrote:
> The latest versions of sbuild do not properly set 'Arch' before calling
> open_build_log() when building within a chroot with a personaility (eg,
> i386 on an amd64 host). This results in the file name of the logfile for
> the build and the logfile preamble having the wrong architecture. This
> only seems to be a problem with the reporting, as the correct chroot is
> used. For example:
> 
> $ /usr/bin/sbuild --chroot-setup-commands /tmp/umt-uPVUs9 -d maverick-i386 -A cups_1.4.4-6ubuntu2.3.dsc
> ....
> | cups 1.4.4-6ubuntu2.3 (amd64)                              04 Jan 2011 10:04
> ....
> Architecture: amd64
> ....
> | Install cups build dependencies (internal resolver)
> ....
> Get:1 http://debmirror/ubuntu/ maverick/main libexpat1 i386 2.0.1-7ubuntu1 [139kB]
> ....
> | Summary
> ....
> Architecture: i386
> ....
> 
> An easy fix is to start the chroot and set the Arch before before
> calling open_build_log(), which is what earlier versions of sbuild did.
> Attached is a patch to do just that.

I'm assuming from the above that you have an i386 chroot on an amd64
host system?

The arch is initially set from the host architecture.  You can set this
using the --arch option, which you should arguably be doing if the
host and build arches differ.

Thanks for the patch.  I've had a look at it, and I'm afraid it can't
be applied in its current form because it breaks cleanup on failure.
You have moved a chunk of the setup code earlier in the run() function,
but it's still using the old label.  Also cleanup_log is now out of
order.

Those can be fixed, but the order of the log opening is important.  If
the build log is not open when we start the session, any errors will
not be logged correctly.  They will go into the main build log rather
than the package build log.  This is something we've got wrong in the
past and which caused great annoyance to the buildd admins.  Even
harmless informational messages get into the main log, and these are
then spammed to the admins for each build (the main log is normally
completely empty except on failure, and this change breaks this
requirement).  The intention is that the main log is only filled when
there's a major failure prior to starting or after ending a package
build, and which the buildd admin must be made aware of.

The bug isn't in the position of open_build_log(), it's in the
misdetection of the architecture when we open the log.  Now, we have
not currently got any way of specifying this automatically; I may add a
suitable configuration option to schroot, I've been considering it for
a while.  But I think that at present you should be using the --arch
option which is also used to search for the correct chroot.

i.e. you should be using

  -d maverick --arch=i386

rather than

  -d maverick-386

since the latter also rewrites the architecture in the .changes; if
you want to specify a specific chroot, then use the --chroot option
rather than --dist.  --dist specifies the exact distribution, while
--chroot specifies the build chroot (which normally defaults to a
chroot based upon the distribution and architecture set e.g.
maverick-i386-sbuild).


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110107/0fe7650f/attachment.pgp>


More information about the Buildd-tools-devel mailing list