On 06/07/2012 05:09 AM, John W. Eaton wrote:
> I was expecting to find a simple interface
but unfortunately what you found is what's needed
to implement GNU 'mkdir -p'. Among other things,
the permissions of the parent directories differ
from the permissions of the child directory. It
of course
Hi Jim!
Maybe you missed this one.
Le 7 juin 2012 à 17:00, Akim Demaille a écrit :
> This time, it's gnu-web-doc-update. I can't fully test it
> now, as I had not defined manual_title in v2.5.1 :(
>
> From bc0749a1d9c7d8b05bbe49d45205a2e5576678bd Mon Sep 17 00:00:00 2001
> From: Akim Demaille
Akim Demaille wrote:
> My announcements for Bison referred to ../../NEWS :)
>
> The interface is "backward-compatible", so you should
> pass
>
> --srcdir=. --news=./NEWS
>
> (i.e., the call to --news remains the same). But _if_
> breaking backward compatibility, under the assumption that
> n
On 06/07/2012 09:21 AM, Paolo Bonzini wrote:
>>> ... which is to wrap MB_CUR_MAX and pretend that it is 3.
>>
>> Actually, MB_CUR_MAX of UTF-8 is 6, thanks to surrogate pairs.
>
> No, it is 6 mostly thanks to the original 32-bit definition of
> ISO-10646. UTF-8 codes that decode to 0xD800 -> 0xD
My announcements for Bison referred to ../../NEWS :)
The interface is "backward-compatible", so you should
pass
--srcdir=. --news=./NEWS
(i.e., the call to --news remains the same). But _if_
breaking backward compatibility, under the assumption that
no one calls announcement-gen by hand
Le 7 juin 2012 à 17:15, Jim Meyering a écrit :
> Thanks for the improvements!
> A couple of nits:
Thanks a lot! Fixed, and installed.
Le 7 juin 2012 à 17:02, Jim Meyering a écrit :
>> Subject: [PATCH] readme-release: also require announce-gen and
>> maintainer-makefile.
>>
>> * modules/readme-release (Depends-on): here.
>> * modules/announce-gen, modules/do-release-commit-and-tag,
>> modules/gnu-web-doc-update, modules/maintai
Il 07/06/2012 16:51, Eric Blake ha scritto:
> On 06/07/2012 08:13 AM, Paolo Bonzini wrote:
>> Il 07/06/2012 14:50, Eric Blake ha scritto:
> The fix could be to have two different locale_charset() functions,
> one that returns "US-ASCII" and another one that returns "UTF-8".
> The first
Akim Demaille wrote:
> Le 7 juin 2012 à 15:15, Jim Meyering a écrit :
>
>> That is fine, too. Thanks.
>>
>> You can tell that I rarely run these rules from a non-srcdir
>> build directory.
>
> Yeah, shame on you :)
>
> Don't you have several builds in parallel? Different generations
> of the com
Akim Demaille wrote:
> Le 7 juin 2012 à 15:05, Jim Meyering a écrit :
>
>> Akim Demaille wrote:
>>> Le 5 juin 2012 à 12:05, Akim Demaille a écrit :
>>>
I have been trying to follow README-release as a guide
for releasing Bison, unfortunately step after step I
discovered that I needed
This time, it's gnu-web-doc-update. I can't fully test it
now, as I had not defined manual_title in v2.5.1 :(
From bc0749a1d9c7d8b05bbe49d45205a2e5576678bd Mon Sep 17 00:00:00 2001
From: Akim Demaille
Date: Thu, 7 Jun 2012 16:17:36 +0200
Subject: [PATCH] gnu-web-doc-update: VPATH builds.
* buil
On 06/07/2012 08:13 AM, Paolo Bonzini wrote:
> Il 07/06/2012 14:50, Eric Blake ha scritto:
The fix could be to have two different locale_charset() functions,
one that returns "US-ASCII" and another one that returns "UTF-8".
The first one to be used when MB_CUR_MAX and mbrtowc() are u
Le 7 juin 2012 à 15:15, Jim Meyering a écrit :
> That is fine, too. Thanks.
>
> You can tell that I rarely run these rules from a non-srcdir
> build directory.
Yeah, shame on you :)
Don't you have several builds in parallel? Different generations
of the compilers, and different compiler opti
Le 7 juin 2012 à 15:05, Jim Meyering a écrit :
> Akim Demaille wrote:
>> Le 5 juin 2012 à 12:05, Akim Demaille a écrit :
>>
>>> I have been trying to follow README-release as a guide
>>> for releasing Bison, unfortunately step after step I
>>> discovered that I needed modules that were not reque
On 06/07/2012 03:13 PM, Paolo Bonzini wrote:
> Il 07/06/2012 14:50, Eric Blake ha scritto:
The fix could be to have two different locale_charset() functions,
one that returns "US-ASCII" and another one that returns "UTF-8".
The first one to be used when MB_CUR_MAX and mbrtowc() are u
Il 07/06/2012 14:50, Eric Blake ha scritto:
>> > The fix could be to have two different locale_charset() functions,
>> > one that returns "US-ASCII" and another one that returns "UTF-8".
>> > The first one to be used when MB_CUR_MAX and mbrtowc() are used as
>> > well, the second one to be used by
Akim Demaille wrote:
> There is many small issues with VPATH builds, in the
> release procedure. A first one.
>
> From c1a33e591861261dcdc9361511835c83c0a22f9c Mon Sep 17 00:00:00 2001
> From: Akim Demaille
> Date: Thu, 7 Jun 2012 12:21:36 +0200
> Subject: [PATCH] maint.mk: fix VPATH issues.
>
>
Akim Demaille wrote:
> Le 5 juin 2012 à 12:05, Akim Demaille a écrit :
>
>> I have been trying to follow README-release as a guide
>> for releasing Bison, unfortunately step after step I
>> discovered that I needed modules that were not requested
>> by Bison. It seems sane that if you want README-
On 06/06/2012 04:39 PM, Michael Goffioul wrote:
> Hi,
>
> While compiling octave under MSVC with current gnulib, I got the following
> problems (leading undefined references at link stage):
>
> 1) dirchownmod uses fchown, but this is not available on Windows and
> there's no replacement in gnulib
On 06/07/2012 06:07 AM, Bruno Haible wrote:
> Stephen Butler wrote:
>> POSIX says that the "C" locale should treat text data is binary input,
>
> Can you please point to where this is written?
POSIX doesn't explicitly say that the "C" locale treats text as binary,
although it does have several in
On 7-Jun-2012, Paul Eggert wrote:
| Much of gnulib has never been ported to MSVC / MingW
| and apparently octave is using that part. I suggest
| using Cygwin.
If it were up to me, I'd go a step further and say, "don't use
Windows," but the reality is that that's not going to fly with many of
Oc
Stephen Butler wrote:
> POSIX says that the "C" locale should treat text data is binary input,
Can you please point to where this is written?
IMO [1] describes the behaviour of the "C" locale only for characters
that belong to what we know as "US-ASCII" (i.e. bytes 0x00..0x7F).
As soon as you pas
Le 7 juin 2012 à 13:51, Eric Blake a écrit :
> On 06/07/2012 05:37 AM, Akim Demaille wrote:
>> Hi!
>>
>> There is many small issues with VPATH builds, in the
>> release procedure. A first one.
>>
>> From c1a33e591861261dcdc9361511835c83c0a22f9c Mon Sep 17 00:00:00 2001
>> From: Akim Demaille
On 06/07/2012 05:37 AM, Akim Demaille wrote:
> Hi!
>
> There is many small issues with VPATH builds, in the
> release procedure. A first one.
>
> From c1a33e591861261dcdc9361511835c83c0a22f9c Mon Sep 17 00:00:00 2001
> From: Akim Demaille
> Date: Thu, 7 Jun 2012 12:21:36 +0200
> Subject: [PATCH
Hi!
There is many small issues with VPATH builds, in the
release procedure. A first one.
From c1a33e591861261dcdc9361511835c83c0a22f9c Mon Sep 17 00:00:00 2001
From: Akim Demaille
Date: Thu, 7 Jun 2012 12:21:36 +0200
Subject: [PATCH] maint.mk: fix VPATH issues.
* top/maint.mk (news-check): GNU
Someone just wrote a rant in a bug report for a program I maintain
about gnulib being the cause of many portability problems. I tracked
it down to the points raised here:
http://www.etalabs.net/musl/faq.html
Have you any plans to address these problems? In particular, it does
seem odd to place a
Le 5 juin 2012 à 12:05, Akim Demaille a écrit :
> I have been trying to follow README-release as a guide
> for releasing Bison, unfortunately step after step I
> discovered that I needed modules that were not requested
> by Bison. It seems sane that if you want README-alpha,
> you also want the
Le 6 juin 2012 à 22:44, Jim Meyering a écrit :
> Akim Demaille wrote:
>> Le 5 juin 2012 à 12:12, Jim Meyering a écrit :
>>
>>> Good idea. This has burned even me ;-)
>>> Please commit.
>>
>> EPERM.
>
> You should be able to push that, now.
Thanks, installed!
On Thu, Jun 07, 2012 at 12:29:03AM -0700, Paul Eggert wrote:
On 06/07/2012 12:19 AM, John Darrington wrote:
> Surely using a symbol instead of a literal constant makes maintenance
easier not
> harder?
I don't see why. For example:
remove ("a/b");
On 06/07/2012 12:19 AM, John Darrington wrote:
> Surely using a symbol instead of a literal constant makes maintenance easier
> not
> harder?
I don't see why. For example:
remove ("a/b");
is simpler and easier to maintain than:
#if DIRECTORY_SEPARATOR == '/'
#define DIRECTORY_SEPARAT
On Wed, Jun 06, 2012 at 01:07:41PM -0700, Paul Eggert wrote:
On 06/06/2012 12:43 PM, John Darrington wrote:
> If as you say, windows prefers \ is there a good reason NOT to use it?
Mostly to avoid the maintenance hassle.
Surely using a symbol instead of a literal constant mak
Much of gnulib has never been ported to MSVC / MingW
and apparently octave is using that part. I suggest
using Cygwin.
32 matches
Mail list logo
