* m4/canonicalize.m4 (gl_FUNC_CANONICALIZE_FILENAME_MODE,
gl_CANONICALIZE_LGPL): Check whether $gl_cv_func_realpath_works
matches "*yes" instead of just "yes". Regression introduced in commit
e0bcf6626cde8dad4bfbdc4045c744f0cd8b9e24.
---
ChangeLog |6 ++
m4/canonicalize.m4
* m4/canonicalize.m4 (gl_FUNC_REALPATH_WORKS): Match "*gnu*" to
determine whether cross-compiling to glibc systems, so as to
include GNU/Hurd.
---
ChangeLog |7 +++
m4/canonicalize.m4 |2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLo
[resending this email via another email, as there seems to have been a problem
the first time around...?]
Hi again,
On 23.06.2012, at 18:36, Paul Eggert wrote:
> On 06/23/2012 07:54 AM, Paolo Bonzini wrote:
>> I'm waiting for feedback from the Gnulib guys.
>
> Can you please summarize the issu
Hi again,
On 23.06.2012, at 18:36, Paul Eggert wrote:
> On 06/23/2012 07:54 AM, Paolo Bonzini wrote:
>> I'm waiting for feedback from the Gnulib guys.
>
> Can you please summarize the issue, the proposed fixes,
> and the pros and cons of each? The discussion has been
> spread out for so long th
ChangeLog |6 ++
lib/timespec-sub.c |1 -
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 785f92f..94b3a9d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2012-07-06 Paul Eggert
+
+ timespec-sub: avoid duplicate inclu
On Fri 06 Jul 2012 17:45, Jim Meyering writes:
> How about writing a function -- with description similar to the comments
> you've added below -- and doing something like the following?
> Then we should be able to avoid that duplication.
>
> elif test "`git log -1 --pretty=format:x . 2>&1`" =
() Jim Meyering
() Fri, 06 Jul 2012 17:49:03 +0200
We want warnf '%s\n' a b c d
to print this (as printf would do):
$me: a
$me: b
$me: c
$me: d
With that added "%s: ", and with "$me" inserted into the
list of arguments, we'd get this:
$me: a
On 07/06/12 06:11, Akim Demaille wrote:
One other tiny nit that is helpful in a die() function:
It isn't necessarily true that "die" always gets invoked
from the main process. If it gets invoked from a subprocess
for any of a variety of reasons, this:
+die() { warn_ "$@"; exit 1; }
won't work.
Thien-Thi Nguyen wrote:
> () Akim Demaille
> () Fri, 6 Jul 2012 16:40:37 +0200
>
>But we have to worry about ',' in $me, which is $0, not
>its basename. Do you want me (Akim, not the variable)
>to change me (the variable, not Akim; not that I am
>immutable) to basename and use /
Andy Wingo wrote:
> On Fri 06 Jul 2012 16:32, Jim Meyering writes:
>
>> It'd be nice to say "why" this change is useful.
>> At worst, just refer to the URL for this mailing list thread.
>
> OK.
>
>> Protecting against envvars by those names is a good idea.
>> That's a fix that merits mention in th
() Akim Demaille
() Fri, 6 Jul 2012 16:40:37 +0200
But we have to worry about ',' in $me, which is $0, not
its basename. Do you want me (Akim, not the variable)
to change me (the variable, not Akim; not that I am
immutable) to basename and use / in the sed command,
instead of ','?
Hi Jim,
On Fri 06 Jul 2012 16:32, Jim Meyering writes:
> It'd be nice to say "why" this change is useful.
> At worst, just refer to the URL for this mailing list thread.
OK.
> Protecting against envvars by those names is a good idea.
> That's a fix that merits mention in the ChangeLog, if not
Akim Demaille wrote:
> Le 6 juil. 2012 à 16:09, Jim Meyering a écrit :
>
>> You're welcome to leave the pipe-to-sed.
>> Worrying about an extra process when processing a diagnostic
>> is probably a pre-optimization anyhow. Besides, then
>> we don't have to worry about whether $me is printf-safe.
>
Le 6 juil. 2012 à 16:09, Jim Meyering a écrit :
> You're welcome to leave the pipe-to-sed.
> Worrying about an extra process when processing a diagnostic
> is probably a pre-optimization anyhow. Besides, then
> we don't have to worry about whether $me is printf-safe.
But we have to worry about
On 07/06/2012 07:09 AM, Jim Meyering wrote:
> You're welcome to leave the pipe-to-sed.
> Worrying about an extra process when processing a diagnostic
> is probably a pre-optimization anyhow.
... unless the diagnostic is something like "program failed"
due to lack of enough system resources to fork
Andy Wingo wrote:
> On Fri 06 Jul 2012 15:56, Stefano Lattarini
> writes:
>
>> On 07/06/2012 03:53 PM, Andy Wingo wrote:
>>>
>>> @@ -121,6 +126,9 @@ if test -z "$tarball_version_file"; then
>>> exit 1
>>> fi
>>>
>>> +echo $match
>>>
>> Huh? Forgotten debugging code perhaps?
>>
>>> +match=
On Fri 06 Jul 2012 15:56, Stefano Lattarini
writes:
> On 07/06/2012 03:53 PM, Andy Wingo wrote:
>>
>> @@ -121,6 +126,9 @@ if test -z "$tarball_version_file"; then
>> exit 1
>> fi
>>
>> +echo $match
>>
> Huh? Forgotten debugging code perhaps?
>
>> +match="${match:-$prefix\*}"
>> +echo $mat
Akim Demaille wrote:
> Le 6 juil. 2012 à 15:21, Stefano Lattarini a écrit :
>
>> Why not shave off the extra forks here?
>>
>>printf "$me: $warnf_format_" "$@" >&2
>>
>> This shouldn't cause problems, unless '$me' contains '%' or '\' characters.
>
> Or end of line. Elsewhere, where I use simil
Le 6 juil. 2012 à 15:54, Stefano Lattarini a écrit :
> On 07/06/2012 03:28 PM, Akim Demaille wrote:
>>
>> Le 6 juil. 2012 à 15:21, Stefano Lattarini a écrit :
>>
>>> Why not shave off the extra forks here?
>>>
>>> printf "$me: $warnf_format_" "$@" >&2
>>>
>>> This shouldn't cause problems,
On 07/06/2012 03:53 PM, Andy Wingo wrote:
>
> @@ -121,6 +126,9 @@ if test -z "$tarball_version_file"; then
> exit 1
> fi
>
> +echo $match
>
Huh? Forgotten debugging code perhaps?
> +match="${match:-$prefix\*}"
> +echo $match
>
Likewise.
> tag_sed_script="${tag_sed_script:-s/x/x/}"
>
> nl=
On 07/06/2012 03:28 PM, Akim Demaille wrote:
>
> Le 6 juil. 2012 à 15:21, Stefano Lattarini a écrit :
>
>> Why not shave off the extra forks here?
>>
>>printf "$me: $warnf_format_" "$@" >&2
>>
>> This shouldn't cause problems, unless '$me' contains '%' or '\' characters.
>
> Or end of line.
Hi,
In guile sometimes we make changes on the stable branch and then merge
the whole stable branch to master. This can bork the git-version-gen
output on master. The attached patch allows us to control the tags that
are matched by git describe, as suggested here:
http://kerneltrap.org/mailarc
Le 6 juil. 2012 à 15:21, Stefano Lattarini a écrit :
> Why not shave off the extra forks here?
>
>printf "$me: $warnf_format_" "$@" >&2
>
> This shouldn't cause problems, unless '$me' contains '%' or '\' characters.
Or end of line. Elsewhere, where I use similar routines,
it is useful to
Akim Demaille wrote:
> Le 6 juil. 2012 à 14:44, Jim Meyering a écrit :
>
>> No, but if you think it's better, somehow...
>> I meant that warnf would be a very thin wrapper around printf:
>>
>>$ printf '%s\n' a b c
>>a
>>b
>>c
>>
>>> Or should warnf expect a single %s
>>
>> or multip
On 07/06/2012 03:11 PM, Akim Demaille wrote:
>
> --- a/build-aux/bootstrap
> +++ b/build-aux/bootstrap
> @@ -1,6 +1,6 @@
> #! /bin/sh
> # Print a version string.
> -scriptversion=2012-07-06.11; # UTC
> +scriptversion=2012-07-06.13; # UTC
>
> # Bootstrap this package from checked-out sources.
>
Le 6 juil. 2012 à 14:44, Jim Meyering a écrit :
> No, but if you think it's better, somehow...
> I meant that warnf would be a very thin wrapper around printf:
>
>$ printf '%s\n' a b c
>a
>b
>c
>
>> Or should warnf expect a single %s
>
> or multiple %-directives:
>
>$ prin
Le 6 juil. 2012 à 14:44, Jim Meyering a écrit :
> No, but if you think it's better, somehow...
> I meant that warnf would be a very thin wrapper around printf:
>
>$ printf '%s\n' a b c
>a
>b
>c
>
>> Or should warnf expect a single %s
>
> or multiple %-directives:
>
>$ prin
On 07/06/2012 02:37 PM, Akim Demaille wrote:
> Le 6 juil. 2012 à 14:24, Jim Meyering a écrit :
>
>>warnf '%s\n' "Error: '$app' version == $inst_ver is too old" \
>> " '$app' version >= $req_ver is required"
>
> Don't you mean warnf '%s\n%s\n'? Or should warnf expect a si
Akim Demaille wrote:
> Le 6 juil. 2012 à 14:24, Jim Meyering a écrit :
>
>> Akim Demaille wrote:
>>> Le 6 juil. 2012 à 13:56, Jim Meyering a écrit :
>>>
Um... this is a good reason to post an adjusted patch.
What I meant was that it is fine to continue to print that diagnostic
on one
Le 6 juil. 2012 à 14:24, Jim Meyering a écrit :
> Akim Demaille wrote:
>> Le 6 juil. 2012 à 13:56, Jim Meyering a écrit :
>>
>>> Um... this is a good reason to post an adjusted patch.
>>> What I meant was that it is fine to continue to print that diagnostic
>>> on one line, but not using echo; u
Akim Demaille wrote:
> Le 6 juil. 2012 à 13:56, Jim Meyering a écrit :
>
>> Um... this is a good reason to post an adjusted patch.
>> What I meant was that it is fine to continue to print that diagnostic
>> on one line, but not using echo; using the new "warn".
>>
>> It should use warn, and warn sh
Le 6 juil. 2012 à 13:56, Jim Meyering a écrit :
> Um... this is a good reason to post an adjusted patch.
> What I meant was that it is fine to continue to print that diagnostic
> on one line, but not using echo; using the new "warn".
>
> It should use warn, and warn should be defined as in init.
Akim Demaille wrote:
> Le 6 juil. 2012 à 12:01, Jim Meyering a écrit :
>
>> Akim Demaille wrote:
>>
>>> It is also very useful to have a single command that issues
>>> several lines. This is the case here for instance:
>>
>> I would debate the "very useful" part ;-)
>> How about "might be nice, in
Le 6 juil. 2012 à 12:01, Jim Meyering a écrit :
> Akim Demaille wrote:
>
>> It is also very useful to have a single command that issues
>> several lines. This is the case here for instance:
>
> I would debate the "very useful" part ;-)
> How about "might be nice, in the rare event someone sees
Akim Demaille wrote:
> Hi Jim!
>
> Le 6 juil. 2012 à 11:43, Jim Meyering a écrit :
>
>> Thanks for the patch.
>>
>> Those all look like improvements, but I'd prefer that
>> you change the name s/stderr/warn/: "stderr" is not normally
>> used as a verb.
>
> OK. I avoided "warn" because I felt it w
Hi Jim!
Le 6 juil. 2012 à 11:43, Jim Meyering a écrit :
> Thanks for the patch.
>
> Those all look like improvements, but I'd prefer that
> you change the name s/stderr/warn/: "stderr" is not normally
> used as a verb.
OK. I avoided "warn" because I felt it would be valid
for it to include a "
Akim Demaille wrote:
> Independently of the other thread we're having about set -e,
> I had refactored bootstrap a bit.
> -8<---
>
> * build-aux/bootstrap (stderr, die): New.
> Use them.
> ---
> build-aux/bootstrap | 94
> ++---
> 1 file changed, 47
Independently of the other thread we're having about set -e,
I had refactored bootstrap a bit.
-8<---
* build-aux/bootstrap (stderr, die): New.
Use them.
---
build-aux/bootstrap | 94 ++---
1 file changed, 47 insertions(+), 47 deletions(-)
diff --g
Hi Eric,
Le 5 juil. 2012 à 17:28, Eric Blake a écrit :
> On 07/05/2012 09:16 AM, Akim Demaille wrote:
>>
>> Le 5 juil. 2012 à 16:53, Jim Meyering a écrit :
>>
>>> This script doesn't use set -e.
>>> I'd say that having to limit such use of "&&" is a good reason
>>> not to use "set -e".
>>
>> I
39 matches
Mail list logo
