GNU bug report logs - #22070
Recreating release 1.6 from git

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22070 in the body.
You can then email your comments to 22070 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Doug Evans <dje <at> google.com>
To: bug-gzip <at> gnu.org
Subject: Recreating release 1.6 from git
Date: Tue, 1 Dec 2015 10:09:37 -0800

Hi.

Is there a recipe for recreating (as close as possible, but not
necessarily identical to) the 1.6 release from git?

There is a v1.6 tag so I can begin with that.
It's the next step I'm not clear on.
I can run the bootstrap script and get something that's buildable,
but I'm left with, IIUC, all of gnulib instead of just the pieces that
went into the 1.6 release.

There's also the issue of using the same autoconf/automake/etc. but I
can manage that as needed.

TIA

Message #8 received at 22070 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Doug Evans <dje <at> google.com>, 22070 <at> debbugs.gnu.org
Subject: Re: bug#22070: Recreating release 1.6 from git
Date: Tue, 1 Dec 2015 14:21:45 -0700

[Message part 1 (text/plain, inline)]

On 12/01/2015 11:09 AM, Doug Evans wrote:
> Hi.
> 
> Is there a recipe for recreating (as close as possible, but not
> necessarily identical to) the 1.6 release from git?

Untested, but roughly:

git checkout v1.6
./bootstrap
./configure
make dist

> 
> There is a v1.6 tag so I can begin with that.
> It's the next step I'm not clear on.
> I can run the bootstrap script and get something that's buildable,
> but I'm left with, IIUC, all of gnulib instead of just the pieces that
> went into the 1.6 release.

Bootstrap clones the gnulib submodule (although you can save disk space
if you also have a clean gnulib.git elsewhere on disk and set
$GNULIB_SRCDIR in the environment appropriately); then copies the needed
files from that submodule into the main working tree.  Then the 'make
dist' step packages just the files that are needed for the tarball (the
files from gnulib that were copied into place, rather than the entire
gnulib submodule).

> 
> There's also the issue of using the same autoconf/automake/etc. but I
> can manage that as needed.
> 
> TIA
> 
> 
> 
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 22070 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Doug Evans <dje <at> google.com>
Cc: 22070 <at> debbugs.gnu.org
Subject: Re: bug#22070: Recreating release 1.6 from git
Date: Tue, 1 Dec 2015 13:33:24 -0800

On Tue, Dec 1, 2015 at 10:09 AM, Doug Evans <dje <at> google.com> wrote:
> Hi.
>
> Is there a recipe for recreating (as close as possible, but not
> necessarily identical to) the 1.6 release from git?
>
> There is a v1.6 tag so I can begin with that.
> It's the next step I'm not clear on.
> I can run the bootstrap script and get something that's buildable,
> but I'm left with, IIUC, all of gnulib instead of just the pieces that
> went into the 1.6 release.
>
> There's also the issue of using the same autoconf/automake/etc. but I
> can manage that as needed.

Hi Doug,

You should be able to come very close by looking at
the release announcement (for selected autotools
releases) and then following the steps in README-release.
Bottom line, "make dist" does the job.

Message #14 received at 22070 <at> debbugs.gnu.org (full text, mbox):

From: Doug Evans <dje <at> google.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 22070 <at> debbugs.gnu.org
Subject: Re: bug#22070: Recreating release 1.6 from git
Date: Tue, 1 Dec 2015 14:08:27 -0800

On Tue, Dec 1, 2015 at 1:21 PM, Eric Blake <eblake <at> redhat.com> wrote:
> On 12/01/2015 11:09 AM, Doug Evans wrote:
>> Hi.
>>
>> Is there a recipe for recreating (as close as possible, but not
>> necessarily identical to) the 1.6 release from git?
>
> Untested, but roughly:
>
> git checkout v1.6
> ./bootstrap
> ./configure
> make dist

Awesome!

Thanks much. The only differences I see are due to
autoconf/automake/etc. version differences.

Message #17 received at 22070 <at> debbugs.gnu.org (full text, mbox):

From: Doug Evans <dje <at> google.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 22070 <at> debbugs.gnu.org
Subject: Re: bug#22070: Recreating release 1.6 from git
Date: Tue, 1 Dec 2015 14:14:04 -0800

On Tue, Dec 1, 2015 at 1:33 PM, Jim Meyering <jim <at> meyering.net> wrote:
> On Tue, Dec 1, 2015 at 10:09 AM, Doug Evans <dje <at> google.com> wrote:
>> Hi.
>>
>> Is there a recipe for recreating (as close as possible, but not
>> necessarily identical to) the 1.6 release from git?
>>
>> There is a v1.6 tag so I can begin with that.
>> It's the next step I'm not clear on.
>> I can run the bootstrap script and get something that's buildable,
>> but I'm left with, IIUC, all of gnulib instead of just the pieces that
>> went into the 1.6 release.
>>
>> There's also the issue of using the same autoconf/automake/etc. but I
>> can manage that as needed.
>
> Hi Doug,
>
> You should be able to come very close by looking at
> the release announcement (for selected autotools
> releases) and then following the steps in README-release.
> Bottom line, "make dist" does the job.

Indeed.  :-)

IWBN if these instructions were in README-hacking or some such.
Or at least a pointer to where to find them.
There is README-release but it's generated at "make dist" time
(presumably for good reasons, but there's good stuff in there
that would be nice to be able to easily find after a git clone
and before anything else).

Message #20 received at 22070 <at> debbugs.gnu.org (full text, mbox):

From: Doug Evans <dje <at> google.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 22070 <at> debbugs.gnu.org
Subject: Re: bug#22070: Recreating release 1.6 from git
Date: Tue, 1 Dec 2015 15:00:18 -0800

Ok, last question and then you can close this.

I'm trying to verify the correct version of gnulib is being used,
but I can't see anything in the bootstrap script that
guarantees this. E.g., I expected to find a gnulib commit id
or tag or some such that specified the version of gnulib that
was used when the original 1.6 release was made.
Do you know how this is done?

Thanks again!


On Tue, Dec 1, 2015 at 2:14 PM, Doug Evans <dje <at> google.com> wrote:
> On Tue, Dec 1, 2015 at 1:33 PM, Jim Meyering <jim <at> meyering.net> wrote:
>> On Tue, Dec 1, 2015 at 10:09 AM, Doug Evans <dje <at> google.com> wrote:
>>> Hi.
>>>
>>> Is there a recipe for recreating (as close as possible, but not
>>> necessarily identical to) the 1.6 release from git?
>>>
>>> There is a v1.6 tag so I can begin with that.
>>> It's the next step I'm not clear on.
>>> I can run the bootstrap script and get something that's buildable,
>>> but I'm left with, IIUC, all of gnulib instead of just the pieces that
>>> went into the 1.6 release.
>>>
>>> There's also the issue of using the same autoconf/automake/etc. but I
>>> can manage that as needed.
>>
>> Hi Doug,
>>
>> You should be able to come very close by looking at
>> the release announcement (for selected autotools
>> releases) and then following the steps in README-release.
>> Bottom line, "make dist" does the job.
>
> Indeed.  :-)
>
> IWBN if these instructions were in README-hacking or some such.
> Or at least a pointer to where to find them.
> There is README-release but it's generated at "make dist" time
> (presumably for good reasons, but there's good stuff in there
> that would be nice to be able to easily find after a git clone
> and before anything else).

Message #23 received at 22070 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Doug Evans <dje <at> google.com>, Jim Meyering <jim <at> meyering.net>
Cc: 22070 <at> debbugs.gnu.org
Subject: Re: bug#22070: Recreating release 1.6 from git
Date: Tue, 1 Dec 2015 17:11:59 -0700

[Message part 1 (text/plain, inline)]

On 12/01/2015 04:00 PM, Doug Evans wrote:
> Ok, last question and then you can close this.
> 
> I'm trying to verify the correct version of gnulib is being used,
> but I can't see anything in the bootstrap script that
> guarantees this. E.g., I expected to find a gnulib commit id
> or tag or some such that specified the version of gnulib that
> was used when the original 1.6 release was made.
> Do you know how this is done?

Via git submodules.  The git history of the gnulib submodule shows which
version of gnulib.git was tied to a particular commit in gzip.git.
Updating to a newer gnulib commit is a conscious decision done by the
maintainer, and shows up in the gzip git history (that is, we are NOT
automatically tracking the latest gnulib.git, which also means that we
do not have to worry about the latest gnulib changes causing regressions
in gzip until we are ready to do a conscious submodule bump).  For
example, commit 34f80f4a was the most recent modification at the time of
my email, where we bumped from gnulib commit 9be0b54 to 5028090.

Sadly, 'git show v1.6:gnulib' complains 'fatal: bad object v1.6:gnulib',
at least for git 2.4.3.  You're welcome to propose a patch to upstream
git.git that would teach 'git show' how to show submodule commit ids
automatically, instead of choking.  I had to use 'git log -p v1.6
gnulib' to learn that v1.6 was made with gnulib.git commit 9be0b54.

The bootstrap script calls 'git submodule update' to forcefully update
the gnulib submodule to the correct release point, before calling the
embedded gnulib-tool to copy the appropriate files from that point in
time of the submodule into the gzip working tree.

The use of git submodules in projects that are gnulib clients is
actually desirable; because it would not scale to add lots of client
labels directly into upstream gnulib.git for every client project's
release.  So you have to read the history of the client, and not of
gnulib itself, to learn which version of gnulib a client depended on at
a given time.

[Oh, and top-posting on technical lists gets difficult to read]

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #28 received at 22070-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: 22070-done <at> debbugs.gnu.org
Subject: Re: bug#22070: Recreating release 1.6 from git
Date: Tue, 15 Mar 2016 18:55:46 -0700

tags 22070 notabug
done

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.