[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

clone 549407 -1
reassign -1 xutils-dev
retitle -1 imake: Must not unconditionally mangle pre-defined symbols in paths.

On Tue, Dec 08, 2009 at 03:01:12PM +0000, Roger Leigh wrote:
> 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.

Exactly. This is particularly obscure, since not all arch names have the
associated symbol defined, e.g., I could not reproduce this with amd64, and
there were no problems with other autobuilders using new sbuild, but there
were with i386, sparc and powerpc.

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

Agreed also, but note that there is the same potential problem with the
current setup. IIRC, few packages still use imake, so this is not at all
a generalized problem. 

The only action I'd currently expect to be considered from the sbuild side
is documenting this misbehavior. I agree that this is an imake misbehavior,
so I am cloning this bug report and reassigning the clone to xutils-dev.
I am keeping current RC severity, xutils-dev maintainers, please readjust at
your will.

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

Yes, that is the scheduled fix. Unfortunately, the buildd-tools mailing list
stripped the patch, this is the relevant part,

+# Make sure this symbol is disabled when imake is invoked.

and changed make->$(MAKE). In practice, this should only affect the Makefile
and Makefiles targets. However, I did not check carefully if there is other
indirect imake invocation, so doing things this way does not hurt.

I expect to upload a fixed ivtools NMU today.



Reply to: