[Pkg-openmpi-maintainers] [Fwd: Re: debian/patches/99autoconf]

[Dirk Eddelbuettel]

On 27 June 2007 at 16:26, Manuel Prinz wrote:
| Am Mittwoch, den 27.06.2007, 09:52 -0500 schrieb Dirk Eddelbuettel:
| > Ok, now for the slow-witted folks in the corner like myself:
| > -- why, ie what does 10opal* do ? Was there a bug report on it?
| 
| It compiles the assembler stuff in the opal directory with some sort of
| stack protection. At least that is my understanding of it. (I just
| started digging into that matter, I'm not really familiar with it.)

I really appreciate your digging through this!

[ As an aside, has anybody figured out what to do with the test/ directory? I
could not find a 'make check' or 'make test' entry.  If we had unit tests
from upstream, then comparing the config changes would be simpler :-/ ]

| I've not seen a bug report on that. The patch was done by Florian. I can
| ask him or just try to understand it. I kind of have the feeling that
| the patch is not needed at all.
| 
| > -- why does it have to re-applied in a second patch ?
|
| I don't get what you mean by "re-applied"?

Sorry, let me try again:   If there is a 10opal* patch, why do we need to
patch a second time via autoconf?

| > <grin> So *WHAT* is the actual difference?    We have been circling this
| > question for a few days now...
| 
| I'm totally confused about this whole stuff now. Probably the answer is
| short and simple: none.

Would be nice to confirm.  The one (semi-strong) argument in favour is that I
have learned, at some cost :), to just trust Steve Langasek. If he was
involved in the patch at some point, there must be a reason. But from the
changelog I can't quite decipher what he did -- some FTBFS issue?

| > | if there's anything we can do about it to shrink the patch in size.
| > | 
| > | Running autoconf during the build process would modify some files and
| > | I'm wondering if that would break some QA tests like rebuilding the same
| > | package twice, since debian/rules clean is expected to take back any
| > | modifications done to the sources. Can we keep track of that when we run
| > | autoconf at build time? That was the intension of the patch because one
| > | can easily deapply it.
| > 
| > I tried to answer this in a previous email via
| > 
| >     But let me just try to think out loud here:
| > 
| >     1)  debian/patches/99* modifies some .am/.ac files
| >     2)  before calling configuire, we call autoconf/automake as needed
| > 
| >     3)  we build as usual thanks to 1) and 2)
| > 
| >     4)  clean removes the generated configure script
| >     5)  dpatch unapplies the diffs from 1) and we're fine
| > 
| >     Now, all of that is of course hypothetical unless we get the set of changes
| >     to the .ac/.am files back. Do you still have them?  
| > 
| > So far nobody has said that this can't work so...
| 
| I kind of misunderstood it in the first read, I guess. I think the
| overall procedure might work as expected, as long as only configure is
| affected by running autoconf/automake.

Makefiles are too, but those are (or should be) getting cleaned by make clean.
 
| Nevertheless, I have increasing doubts that we need the 10opal* nor the
| 99* patch at all. They seem to be kind of useless, unless I'm missing
| the obvious. But I have to do a little more reading to understand the
| issue. http://www.gentoo.org/proj/en/hardened/gnu-stack.xml seems to be
| related and somewhat interesting in this respect.

Also, they stem from the 1.1* series that Florian started with and may well
have gotten obsolete now.  

Cheers, Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison