Pádraig Brady wrote:
> I've noticed a few times when re-running bootstrap
> within my coreutils directory, that the build will fail because
> it seems that the timestamps of the symlinks in m4/ are used,
> rather than those of the target m4 files.
>
> For example recently, @HAVE_SIGHANDLER_T@ was l
On 05/12/11 23:15, Markus Duft wrote:
> maybe i could even implement a futimes by memorizing the timestamps and
> re-setting them after closing the file...
>
> would that be better than hacking around in gnulib? libsuacomp is required
> anyway to get a more sane system.
Yes, thanks, that sounds
On 05/12/11 18:10, Paul Eggert wrote:
> On 05/12/11 01:38, Markus Duft wrote:
>> this doesn't help, and doesn't even compile, as interix also doesn't have
>> sync()
>
> OK, how about this patch to utimens.c instead?
tested, but doesn't help either. the problem is, that fdutimensat calls
utimens
Hi,
I don't have an explanation for this. I'm working with libvirt
0.9.1 which pulls in gnulib. When I build on a bare machine or
a minimal lxc container, test-poll passes. When I build in an
schroot, it fails because when it does a poll after the other
end has shut down, it does not get the ex
From: James Youngman
* m4/fnmatch.m4: Use gnulib's fnmatch if the system fnmatch
doesn't allow the literal matching of a lone "[" (which is
required by POSIX).
* tests/test-fnmatch.c (main): Check that "[/b" matches itself.
---
ChangeLog|8
m4/fnmatch.m4|2 ++
From: James Youngman
* lib/fnmatch_loop.c (FCT): When matching '[' keep track of
beginning and fall back to matching as normal character if the
string ends before the matching ']' is found. This is what POSIX
requires.
---
ChangeLog |8
lib/fnmatch_loop.c | 11 +-
On Thu, May 12, 2011 at 1:57 AM, Bruno Haible wrote:
> No tabs in gnulib source code. Can you please untabify the file before
> committing it in gnulib?
I'll resend the patch with the fixes you indicated, but I can't submit
directly (perhaps my use of "git commit -s" was misleading, sorry).
Jame
On 05/12/11 01:38, Markus Duft wrote:
> this doesn't help, and doesn't even compile, as interix also doesn't have
> sync()
OK, how about this patch to utimens.c instead?
diff --git a/lib/utimens.c b/lib/utimens.c
index c190411..f738c68 100644
--- a/lib/utimens.c
+++ b/lib/utimens.c
@@ -58,6 +58,
On 12/05/11 16:04, Jim Meyering wrote:
> Eric Blake wrote:
>> On 05/12/2011 08:55 AM, Eric Blake wrote:
>> Then again, './gnulib-tool --with-tests --test fclose' worked for me.
>> Is this a case of you building incrementally but the replacement
>> for iwhd hasn't been replaced to reflect the chang
Eric Blake wrote:
> On 05/12/2011 08:55 AM, Eric Blake wrote:
>> On 05/12/2011 08:52 AM, Jim Meyering wrote:
>>> Hi Eric,
>>>
>>> This test would fail for me when I made iwhd use the latest from gnulib:
>>>
>>> FAIL: test-fclose (exit: 134)
>>> =
>>> test-fcl
On 05/12/2011 08:55 AM, Eric Blake wrote:
> On 05/12/2011 08:52 AM, Jim Meyering wrote:
>> Hi Eric,
>>
>> This test would fail for me when I made iwhd use the latest from gnulib:
>>
>> FAIL: test-fclose (exit: 134)
>> =
>> test-fclose.c:77: assertion failed
>
On 05/12/2011 08:52 AM, Jim Meyering wrote:
> Hi Eric,
>
> This test would fail for me when I made iwhd use the latest from gnulib:
>
> FAIL: test-fclose (exit: 134)
> =
> test-fclose.c:77: assertion failed
>
> It looks pretty obvious, but I'll wait for yo
Hi Eric,
This test would fail for me when I made iwhd use the latest from gnulib:
FAIL: test-fclose (exit: 134)
=
test-fclose.c:77: assertion failed
It looks pretty obvious, but I'll wait for your ACK, just in case.
>From 05c18b2e33ce1130287b87fb81d22c0eb
On 05/12/11 09:20, Paul Eggert wrote:
> On 05/11/11 23:51, Markus Duft wrote:
>> the fd in fdutimensat is 4, whereas in utimens, which is then called from
>> somewhere in there,
>> it is -1, so i can't do a fsync()
>
> If I understand things correctly, there's a simpler fix. fdutimensat calls
>
On 05/12/11 05:41, Paul Eggert wrote:
> On 05/11/11 01:49, Markus Duft wrote:
>> fsync(fd) before setting the timestamp helps, and i have a 1.26 patch
>> (attached),
>> for now limited to interix only, although i saw it on linux too.
>
> Can you describe the GNU/Linux scenario? That would be a s
On 05/11/11 23:51, Markus Duft wrote:
> the fd in fdutimensat is 4, whereas in utimens, which is then called from
> somewhere in there,
> it is -1, so i can't do a fsync()
If I understand things correctly, there's a simpler fix. fdutimensat calls
futimens (fd, ts), which invokes fdutimens (fd, N
16 matches
Mail list logo
