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

Bug#549407: [buildd-tools-devel] Bug#549407: ivtools 1.2.6-1 FTBFS on sparc and powerpc

On Tue, Dec 08, 2009 at 03:11:32AM +0100, Agustin Martin wrote:
> 2009/12/6 Agustin Martin <agmartin@debian.org>:
> >
> > Good news. I finally found the reason for this problem. An explanation
> > was not that far. Quoting http://www.ivtools.org/ivtools/faq.html,
> >
> > -----------------------
> > ... For example, most
> > PC-based uses of gcc have i386 defined to 1, so a path like
> > /usr/src/i386/ivtools-1.0 gets expanded to /usr/src/1/ivtools-1.0. ..
> > -----------------------
> >
> > As I understand it, this problem should also be present in other
> > packages using imake.  Not sure if many packages still use imake, but
> > if so there is a problem with the temporary dir naming in sbuild.
> In case this is ever needed, seems that is enough to change to a
> lowbar one of the hyphen $(ARCH) boundaries in tempdir name, like in
> -----------------
> --- Build.pm.orig       2009-11-20 19:48:42.000000000 +0100
> +++ Build.pm    2009-12-07 01:00:07.000000000 +0100
> @@ -233,7 +233,7 @@
>      $self->set('Chroot Build Dir',
>                tempdir($self->get_conf('USERNAME') . '-' .
>                        $self->get('Package_SVersion') . '-' .
> -                      $self->get('Arch') . '-XXXXXX',
> +                      $self->get('Arch') . '_XXXXXX',
>                        DIR => $session->get('Build Location')));
>      # TODO: Don't hack the build location in; add a means to customise
>      # the chroot directly.

Thanks for identifying the cause of the problem!

So, to state the problem clearly: Imake is substituting the
$(ARCH) part of the path to something else.  Such as 'i386' being
swapped for something else entirely, thus resulting in an
invalid path.

This is, IMO, completely broken on the part of Imake.  I'm reluctant
to alter sbuild to accommodate such bad behaviour.  For one thing,
it can substitute /any part/ of the path, so there's no guarantee it
won't randomly break on the XXXXXX random part or any other path
component for any given build.  The "fix" just makes the arch
mismatch because underscore makes the two parts a single token, but
that is not to say it will /never/ match.  I accept that it solves
the immediate issue, but it doesn't correct the fundamental
underlying defect in imake.

What's worse is that the random path might actually be /valid/, in
which case it might scribble junk into, or delete files from, a
directory other than the build directory.  Unlikely, but possible,
so a potential security problem on the buildd.

Is this possible to fix in ivtools using the -u option to undefine
things as suggested in the FAQ?  Given the package-specific nature
of the problem, I feel this would be a more appropriate place for
a fix.


  .''`.  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

Reply to: