GNU bug report logs - #8423
Questions about checking out 6.7 using 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 8423 in the body.
You can then email your comments to 8423 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: Kai Yu <yukai <at> nlsde.buaa.edu.cn>
To: bug-coreutils <at> gnu.org
Subject: Questions about checking out 6.7 using git
Date: Mon, 4 Apr 2011 23:00:36 +0800

Hi, I'm currently investigating how to fight software regressions with
git bisect. I git clone coreutils and type "git checkout
COREUTILS-6_7" to switch to the version 6.7. After type "./bootstrap",
an error arises:

ln: creating symbolic link `lib/uniwidth/cjk.h': No such file or directory

By looking into commit history, I found this problem was solved by
this commit, which modifies bootstrap:
http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e7368caf47c9bcdd853f1f9dac4382935d4caa6f

After modification and run './bootstrap' again, the above error disappears.
Then I type "./configure" and it is OK.
However, when use "make" to complie the package, another error arises:

sed: read error on ../.: Is a directory
make[1]: *** [inttypes.h] Error 4
make[1]: Leaving directory `/home/coreutils/lib'
make: *** [all-recursive] Error 1

Could anybody tell me how to check out and compile coreutils-6.7 by using git?

I would appreciate any replies on this issue, thank you.

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

From: Jim Meyering <jim <at> meyering.net>
To: 8423 <at> debbugs.gnu.org
Subject: Re: Questions about checking out 6.7 using git
Date: Sun, 17 Apr 2011 08:34:01 +0200

tags 8423 notabug
close 8423
thanks

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

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: jim <at> meyering.net (Jim Meyering)
Cc: 8423 <at> debbugs.gnu.org
Subject: Re: bug#8423: Questions about checking out 6.7 using git
Date: Sun, 17 Apr 2011 02:18:49 -0500 (GMT+5)

Jim Meyering writes:
> 
> tags 8423 notabug
> close 8423
> thanks

That's disappointing. I was looking forward to seeing a response to this
question. I also recently tried to find the origin of a bug with git bisect
and quickly ended up with an uncompilable mess.

If you want to see a complete demonstration, I could make another attempt and
log it all. But if you're trying to tell us that checking out old versions
from the repository and compiling them shouldn't be expected to work... then
you're wrong.

-- 
Alan Curry

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

From: Jim Meyering <jim <at> meyering.net>
To: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
Cc: 8423 <at> debbugs.gnu.org
Subject: Re: bug#8423: Questions about checking out 6.7 using git
Date: Sun, 17 Apr 2011 10:27:48 +0200

Alan Curry wrote:
> Jim Meyering writes:
>>
>> tags 8423 notabug
>> close 8423
>> thanks
>
> That's disappointing. I was looking forward to seeing a response to this
> question. I also recently tried to find the origin of a bug with git bisect
> and quickly ended up with an uncompilable mess.
>
> If you want to see a complete demonstration, I could make another attempt and
> log it all. But if you're trying to tell us that checking out old versions
> from the repository and compiling them shouldn't be expected to work... then
> you're wrong.

Thanks for pointing that out.  I should have explained here.
This user posted the same request to at least two
other mailing lists and there was a fine response on
at least one of those others.

Here's some explanation and an outline:

coreutils-6.7 was released on 2006-12-08, which was before we had a
gnulib git submodule.  Actually, that was back when bootstrap would
pull the gnulib sources via cvs.  coreutils itself had switched to
git only two months before.

Hence, without a submodule, and with no other record of which gnulib
commit was used, you'll have to resort to dates to find approximately
which gnulib was used.  Or compare with the release tarball.

Since cvs access to gnulib may not do what you want, I suggest
using a ../gnulib directory.  You'd git-reset it to a commit from
the date corresponding to 6.7 and then reference ../gnulib via the
GNULIB_SRCDIR=../gnulib envvar setting that bootstrap uses.

From there on, you'll just have to debug problems as you find them.
There is no general recipe.

Previous Next

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