Lustre devel - Dec 2010 - Cannot easily build from master source anymore

Hello

I noticed there was a refactor for packaging and versioning in Lustre 
prime master branch.
Unfortunately, we cannot simply do anymore

git clone ...
sh ./autogen.sh
./configure ..
make

to build lustre source

What''s the trick now ?
Maybe it could be useful to update Wiki page: 
http://wiki.lustre.org/index.php/Building_Lustre_Code


Thanks

-- 
Aurelien Degremont

> Hello
> 
> I noticed there was a refactor for packaging and versioning in Lustre 
> prime master branch.
> Unfortunately, we cannot simply do anymore
> 
> git clone ...
> sh ./autogen.sh
> ./configure ..
> make
> 
> to build lustre source
> 
> What''s the trick now ?
> Maybe it could be useful to update Wiki page: 
> http://wiki.lustre.org/index.php/Building_Lustre_Code
Let me guess. 

checking for stdint.h... yes
checking for unistd.h... yes
checking whether to configure just enough for make dist... no
checking for buildid... configure: error: most recent tag found: v2_0_0 
does not match current version 2.0.56.
make: *** No rule to make target `rpms''.  Stop.
make: *** No rule to make target `rpms''.  Stop.

On 2010-12-01, at 12:45, James Simmons wrote:
>> I noticed there was a refactor for packaging and versioning in Lustre 
>> prime master branch.
>> Unfortunately, we cannot simply do anymore
>> 
>> git clone ...
>> sh ./autogen.sh
>> ./configure ..
>> make
>> 
>> to build lustre source
>> 
>> What''s the trick now ?
>> Maybe it could be useful to update Wiki page: 
>> http://wiki.lustre.org/index.php/Building_Lustre_Code
> 
> Let me guess. 
> 
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking whether to configure just enough for make dist... no
> checking for buildid... configure: error: most recent tag found: v2_0_0 
> does not match current version 2.0.56.
> make: *** No rule to make target `rpms''.  Stop.
> make: *** No rule to make target `rpms''.  Stop.
My recollection from Brian''s previous postings is that this is somehow
related to an old "git" version being used.

That said, I''d be happy to remove this as a requirement, and just stick
with the version if there is a mismatch, printing only a warning if the git
version is too old.

Cheers, Andreas
--
Andreas Dilger
Lustre Technical Lead
Oracle Corporation Canada Inc.

Andreas Dilger a ?crit :
> On 2010-12-01, at 12:45, James Simmons wrote:
>>> I noticed there was a refactor for packaging and versioning in
Lustre
>>> prime master branch.
>>> Unfortunately, we cannot simply do anymore
>>>
>>> git clone ...
>>> sh ./autogen.sh
>>> ./configure ..
>>> make
>>>
>>> to build lustre source
>>>
>>> What''s the trick now ?
>>> Maybe it could be useful to update Wiki page: 
>>> http://wiki.lustre.org/index.php/Building_Lustre_Code
>> Let me guess. 
>>
>> checking for stdint.h... yes
>> checking for unistd.h... yes
>> checking whether to configure just enough for make dist... no
>> checking for buildid... configure: error: most recent tag found: v2_0_0
>> does not match current version 2.0.56.
>> make: *** No rule to make target `rpms''.  Stop.
>> make: *** No rule to make target `rpms''.  Stop.
> 
> My recollection from Brian''s previous postings is that this is
somehow related to an old "git" version being used.
We are using either git v1.5.5.6. Is this so old?
> That said, I''d be happy to remove this as a requirement, and just
stick with the version if there is a mismatch, printing only a warning if the
git version is too old.
I think it will be a good idea



-- 
Aurelien Degremont
CEA

Aurelien,

On Thu, 2010-12-02 at 15:22 +0100, Aurelien Degremont
wrote:
> >> Let me guess. 
> >>
> >> checking for stdint.h... yes
> >> checking for unistd.h... yes
> >> checking whether to configure just enough for make dist... no
> >> checking for buildid... configure: error: most recent tag found:
v2_0_0
> >> does not match current version 2.0.56.
Is this in fact the problem you run into?  You didn''t actually say what
the problem you had was in your original posting, just that there was a
problem.  It''s usually a good idea to at least print the error message
when you are reporting a failure.
> >> make: *** No rule to make target `rpms''.  Stop.
> >> make: *** No rule to make target `rpms''.  Stop.
> > 
> > My recollection from Brian''s previous postings is that this
is somehow related to an old "git" version being used.
> 
> We are using either git v1.5.5.6. Is this so old?
Hrm.  TBH, I don''t think we''ve zeroed in on exactly which git
version
resolved the problem, but you can use:

$ git describe --tags

To see what git thinks is the most recent tag in your source tree.  If
it''s not a recent (i.e. it''s v2_0_0) tag you likely have an
old git.
> 
> > That said, I''d be happy to remove this as a requirement, and
just stick with the version if there is a mismatch, printing only a warning if
the git version is too old.
> 
> I think it will be a good idea
Hrm.  I suppose a configure option to either enforce the equality (i.e.
default to being lenient) or to allow inequality (i.e. default to being
strict) is certainly doable.  Personally, I''d prefer the latter since
it''s what should happen and work fine when everything else (i.e. git)
is
working fine.  Git being too old and not working properly seems to me
like something that should be handled as the exceptional case with a
option like "--with-old-git" or something.

In fact, if we can pinpoint the version (or even get close -- we can
refine it as we learn more) of git where the behaviour is corrected, we
can probably make it all implicit.  This is something I have been
considering as more and more evidence of old git installations is coming
to light.

Cheers,
b.

Brian J. Murrell a ?crit :
> Is this in fact the problem you run into?  You didn''t actually say
what
> the problem you had was in your original posting, just that there was a
> problem.  It''s usually a good idea to at least print the error
message
> when you are reporting a failure.
Indeed it was my issue.
But I''ve realized that I cannot reproduce the issue anymore.

''git bisect'' told me that it was this commit which fix the
issue:

commit e1a8487277a83449fa2c92ba363162b692c3ebef
Author: Terry Rutledge <terry.rutledge at oracle.com>
Date:   Fri Dec 3 21:19:03 2010 -0800

     Needed to create a new tag for 2.1.0 build 09.  For some reason the
     previous tag was not being propagated out, so v2_0_58_0 is being
     created for this build.

(configure now say : "buildid: none... congratulations, you must be on a
tag"

So this is ok for me, but i''m surprised that nobody from oracle hit
this issue in-between.




-- 
Aurelien Degremont
CEA

On Dec 2, 2010, at 6:22 , Aurelien Degremont wrote:
> Andreas Dilger a ?crit :
>> On 2010-12-01, at 12:45, James Simmons wrote:
>>>> I noticed there was a refactor for packaging and versioning in
Lustre
>>>> prime master branch.
>>>> Unfortunately, we cannot simply do anymore
>>>> 
>>>> git clone ...
>>>> sh ./autogen.sh
>>>> ./configure ..
>>>> make
>>>> 
>>>> to build lustre source
>>>> 
>>>> What''s the trick now ?
>>>> Maybe it could be useful to update Wiki page: 
>>>> http://wiki.lustre.org/index.php/Building_Lustre_Code
>>> Let me guess. 
>>> 
>>> checking for stdint.h... yes
>>> checking for unistd.h... yes
>>> checking whether to configure just enough for make dist... no
>>> checking for buildid... configure: error: most recent tag found:
v2_0_0
>>> does not match current version 2.0.56.
>>> make: *** No rule to make target `rpms''.  Stop.
>>> make: *** No rule to make target `rpms''.  Stop.
>> 
>> My recollection from Brian''s previous postings is that this is
somehow related to an old "git" version being used.
> 
> We are using either git v1.5.5.6. Is this so old?
FYI, the 1.5.x versions are quite old, especially for git.  We''re not
sure which version you need for git describe to work as expected, but
it''s probably a later 1.6.x version. The the current version is
1.7.3.4, but I''m using 1.7.0.x something and it''s working
fine.

robert

On 12/16/2010 03:19 AM, Aurelien Degremont wrote:
> Brian J. Murrell a ?crit :
>> Is this in fact the problem you run into?  You didn''t actually
say what
>> the problem you had was in your original posting, just that there was a
>> problem.  It''s usually a good idea to at least print the error
message
>> when you are reporting a failure.
>
> Indeed it was my issue.
> But I''ve realized that I cannot reproduce the issue anymore.
>
> ''git bisect'' told me that it was this commit which fix
the issue:
>
> commit e1a8487277a83449fa2c92ba363162b692c3ebef
> Author: Terry Rutledge<terry.rutledge at oracle.com>
> Date:   Fri Dec 3 21:19:03 2010 -0800
>
>       Needed to create a new tag for 2.1.0 build 09.  For some reason the
>       previous tag was not being propagated out, so v2_0_58_0 is being
>       created for this build.
>
> (configure now say : "buildid: none... congratulations, you must be on
a tag"
>
> So this is ok for me, but i''m surprised that nobody from oracle
hit this issue in-between.
I believe the reason it starts working at that commit is the annotated 
tag that points to it.  Previous to that tag, Oracle was using simple 
lightweight tags (which is git tag''s default option).  With older 
versions of git, "git describe" only stopped at annotated tags, not 
lightweight tags.

So Oracle folks are probably just using newer versions of git than you.

Chris

Christopher J. Morrone a ?crit :
> I believe the reason it starts working at that commit is the annotated 
> tag that points to it.  Previous to that tag, Oracle was using simple 
> lightweight tags (which is git tag''s default option).  With older 
> versions of git, "git describe" only stopped at annotated tags,
not
> lightweight tags.
> 
> So Oracle folks are probably just using newer versions of git than you.
Ok. That makes sense.
So I''ve update to 1.7.3

EPEL git package seems to old.


Thanks for your help.

-- 
Aurelien Degremont
CEA