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.
signature.asc
Description: Digital signature
