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

[Dirk Eddelbuettel]

On 28 June 2007 at 00:05, Manuel Prinz wrote:
| I did some investigation on that. To cut a long story short, I'm pretty
| sure that the 10opal* patch is obsolete and can be safely removed from
| trunk, along with the 99* patch. More details follow, if you're

Ok. That is definitely something we can try for one of the next releases.

| interested. Otherwise, you can stop reading here.
| 
| 
| Am Mittwoch, den 27.06.2007, 10:44 -0500 schrieb Dirk Eddelbuettel:
| > I really appreciate your digging through this!
| 
| Thanks! It's part of maintaining, after all. ;)
| 
| > [ 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 :-/ ]
| 
| On my system, the tests seem to be created as part of the regular build
| process. Invoking "make check" in the root directory runs them. (The
| results get lost in way too much output, nevertheless.)

But not in the normal Debian build, right? 

edd at basebud:~/src/debian/SVN/build-area> grep 'make check' openmpi_1.2.3-1_i386.build
edd at basebud:~/src/debian/SVN/build-area>            

I also noticed that debian/rules isn't quite as 'complete': if you do
'debian/rules install' it doesn't know to call configure and make. I can add
all that.

| > Sorry, let me try again:   If there is a 10opal* patch, why do we need to
| > patch a second time via autoconf?
| 
| I think the reasoning was to seperate the "source" patch from the
| "binary" patch, meaning to keep the changes in the autogenerated files
| seperate from the "real" patch, so one doesn't need to worry about
| those. We do actually, so this is kind of not working.
| 
| > 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?
| 
| Seems to be the result of some Etch RC bug squashing or something. I am
| not sure.
| 
| > Also, they stem from the 1.1* series that Florian started with and may well
| > have gotten obsolete now.  
| 
| As mentioned earlier, I'm quite sure they are.
| 
| I compiled the unmodified upstream version and checked it with scanelf
| and readelf for the GNU-stack note. I didn't find any. I created a list
| of all assember files and those file containing the string "GNU-stack".
| Those list didn't match because some files are platform-specific and not
| build.

Ok.
 
| Anyway, configure checks if the GNU-stack node is needed. The Perl
| script in ./opal/asm modifies the assembler files, adding a GNU-stack
| note if it's required. The assembler files all seem to ship without one,
| so it's added during the build.

Ok.
 
| To me, it looks like upstream thought about this issue and I'm quite
| sure that configure will handle the situation on other architectures
| correctly; I can't test that anyway. So compiling with --noexecstack is
| useless because upstreams version doesn't create files that expect an
| executable stack, making the 10opal* patch obsolete. And since 99*
| contains only changes due to the 10opal* patch, it's obsolete too.
| 
| I'll have to delete those patches and recompile to check if it still
| works but don't see a reason why it wouldn't.

I think in the simplest case removing them from debian/patches/00list also
excludes them, so that would be a start.

Dirk

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