Hi,
On Mon, Feb 22, 2010 at 03:58:19PM -0700, Eric Blake wrote:
[...]
> Here's the next three patches I had to add on top of the previously posted
> one. With this series, I was able to copy the new bootstrap to libvirt
> and still get everything there to work correctly (patch to libvirt list to
On 03/14/2010 07:54 AM, Bruno Haible wrote:
> * There are five use cases of the 'bootstrap' script:
> 1) A normal user who wants to check out coreutils with the version
> of gnulib with which it was tested. Does not want to be bothered
> with versions, what gnulib is in th
Hi Jim and Eric,
Thanks for your explanations how 'bootstrap' is to be used with git. But
I still don't find the current state reasonable, because:
* There are five use cases of the 'bootstrap' script:
1) A normal user who wants to check out coreutils with the version
of gnulib w
On 03/10/2010 03:18 AM, Jim Meyering wrote:
>> I did a grep of '80cd995cdcbf4b9ded895a43621a11f11806ad8d' over the source
>> tree
>> and did not find it.
Maybe worth reporting to the git list as an enhancement request to 'git
grep' to search the textual representation of submodules? At any rate,
>> I tried the latest from gnulib via coreutils,
>> ...
>> In file included from test-string-c++.cc:23:
>> ../lib/string.h:301: error: type of 'memchr' is unknown
>
> Can you please tell me how to reproduce?
Here's a much easier way to reproduce the problem,
using only gnulib. The key is to test
>> I tried the latest from gnulib via coreutils,
>> ...
>> In file included from test-string-c++.cc:23:
>> ../lib/string.h:301: error: type of 'memchr' is unknown
>
> Can you please tell me how to reproduce?
>
> I checked out coreutils from git, saw that its "bootstrap --help" script says
> --gnul
Hi Jim,
> I tried the latest from gnulib via coreutils,
> ...
> In file included from test-string-c++.cc:23:
> ../lib/string.h:301: error: type of 'memchr' is unknown
Can you please tell me how to reproduce?
I checked out coreutils from git, saw that its "bootstrap --help" script says
--gnulib-
- "Jim Meyering" wrote:
> > +# time-stamp-end: "; # UTC"
>
> Those look fine.
> Though you might want to drop the semicolon in each.
Oh well, I already pushed with the semicolon. At least this way,
all of the timestamped scripts in build-aux have the same formatting,
regardless of sh vs. pe
Eric Blake wrote:
> And adding timestamps aids in tracking whether projects are using the
> latest bootstrap.
That seems useful.
...
> Subject: [PATCH] bootstrap, git-version-gen: use timestamp
>
> Timestamps are useful, particularly for files copied into other
> packages, to see how long since a
According to Eric Blake on 2/24/2010 9:54 AM:
> Libvirt came up with the compelling reason - Fedora Core 11 only has
> 1.6.2.5, and RPEL 5 is back at git 1.5.5. This should fix it, by
> borrowing ideas from m4's bootstrap script.
And adding timestamps aids in tracking whether projects are using t
Eric Blake wrote:
> According to Jim Meyering on 2/17/2010 10:21 AM:
>>> or should we just assume that git 1.6.4 or newer is widespread enough to
>>> not be worth the hassle?
>>
>> I'd prefer to assume git 1.6.4 to keep things simpler, at least until
>> someone comes up with a compelling reason to
According to Jim Meyering on 2/17/2010 10:21 AM:
>> or should we just assume that git 1.6.4 or newer is widespread enough to
>> not be worth the hassle?
>
> I'd prefer to assume git 1.6.4 to keep things simpler, at least until
> someone comes up with a compelling reason to add code to support olde
According to Eric Blake on 2/22/2010 9:28 AM:
> According to Eric Blake on 2/17/2010 1:20 PM:
>> Here's my first cut at it.
>>
>> From: Eric Blake
>> Date: Wed, 17 Feb 2010 11:42:16 -0700
>> Subject: [PATCH] bootstrap: use GNULIB_SRCDIR to reduce disk usage
>
> I was about to push this as-is, but
According to Eric Blake on 2/17/2010 1:20 PM:
> Here's my first cut at it.
>
> From: Eric Blake
> Date: Wed, 17 Feb 2010 11:42:16 -0700
> Subject: [PATCH] bootstrap: use GNULIB_SRCDIR to reduce disk usage
I was about to push this as-is, but noticed that libvirt stores the
submodule as ".gnulib",
On 02/17/2010 09:20 PM, Eric Blake wrote:
-git_modules_config --replace-all submodule.gnulib.url $GNULIB_SRCDIR
I think this was definitely wrong. .git/config overrides .gitmodules
exactly so that you can place submodule.*.url entries there that point
to local repositories.
--reference
According to Paolo Bonzini on 2/17/2010 10:10 AM:
> On 02/17/2010 02:57 PM, Eric Blake wrote:
> > Any objections?
>
> Where is the patch?
>
Here's my first cut at it. Beware that it is a slight semantic change
from Jim's commit 9efa515ce last November; but I actually prefer my
semantics. With Ji
Eric Blake wrote:
> git 1.6.4 learned 'git submodule add --reference dir' as a means to make
> initializing git submodules use (MUCH) less bandwidth and disk space by
> borrowing references from an existing on-disk repository, rather than
> cloning from scratch. I would like to modify the bootstra
On 02/17/2010 02:57 PM, Eric Blake wrote:
Any objections?
Where is the patch? ;-)
Paolo
git 1.6.4 learned 'git submodule add --reference dir' as a means to make
initializing git submodules use (MUCH) less bandwidth and disk space by
borrowing references from an existing on-disk repository, rather than
cloning from scratch. I would like to modify the bootstrap script to
honor $GNULIB_
19 matches
Mail list logo