Eric Blake wrote:
> According to Jim Meyering on 8/14/2009 1:11 PM:
>>> Hmm. VC_LIST_EXCEPT excludes ChangeLog by default, but this is one case
>>> where
>>> we WANT ChangeLog's copyright updated along with everything else. Also, I
>>> think we shoul
Eric Blake wrote:
> I just noticed a problem. update-copyright is a perl script only intended for
> maintainer use, which is fine, since only maintainers are required to have
> perl
> installed (after all, we already know that maintainers have perl by virtue of
> the fact that they are running a
Eric Blake wrote:
> Eric Blake byu.net> writes:
>> I just noticed a problem. update-copyright is a perl script only intended
> for
>> maintainer use
>
> And we ought to support some form of 'build-aux/update-copyright --help' (and
> also --version), per GNU Coding Standards, before shipping packa
Eric Blake wrote:
> According to Jim Meyering on 8/15/2009 2:37 AM:
>>> It changed a bit due to the merge; here's what I'm pushing.
>
> I haven't pushed yet, in case we decide something different...
>
>> ...
>>> grep -l -w Copyright $$($(VC_
Eric Blake wrote:
> According to Jim Meyering on 8/15/2009 4:53 AM:
>>> For the record, I discovered this because 'perl -ei' fails on cygwin 1.5
>>> [but
>>> works in cygwin 1.7] because of older cygwin's inability to delete in-use
>>> fi
Eric Blake wrote:
> According to Jim Meyering on 8/15/2009 9:50 AM:
>>> I'm not sure why some invocations work and others fail, but the point is
>>> that update-copyright doesn't work as-is on cygwin 1.5; and it also has
>>> the annoying failure path
Joel E. Denny wrote:
> Hi Eric and Jim.
>
> On Sat, 15 Aug 2009, Eric Blake wrote:
>
>> According to Jim Meyering on 8/15/2009 2:37 AM:
>> >> It changed a bit due to the merge; here's what I'm pushing.
>>
>> I haven't pushed yet, in case
the problem and don't have
> time to look into a proper fix now, but thought I should mention the
> issue in case someone else wants to look into it.
Thanks!
There were actually two problems!
This fixes both:
>From 84efe726c214319385caaade0414f737ab9a05f4 Mon Sep 17 00:00:00 2001
Fro
Akim Demaille wrote:
> This change helps bootstrapping on platforms where sha1sum is actually
> gsha1sum.
>
>
> From 1832d3dfba847aba6567b5056af0cad1978dd51f Mon Sep 17 00:00:00 2001
> From: Akim Demaille
> Date: Wed, 19 Aug 2009 15:37:23 +0200
> Subject: [PATCH 1/2] bootstrap: find sha1sum when n
FYI
>From e690ea62e6d088cb4b0886e7652a84de9dbbe210 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 20 Aug 2009 16:11:45 +0200
Subject: [PATCH] selinux-at.h: avoid a dirfd shadowing warning
* lib/selinux-at.h: Rename all parameters: s/dirfd/dir_fd/
to avoid shadowing a global declarat
ed that, for now, which means the added rm -f
statements can be seen as removing $@ unnecessarily, when
the final move-into-place command uses "mv -f".
>From bd8cfad4eb68e459d9fd24144df7a106765f8c09 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Fri, 21 Aug 2009 10:56:58 +0200
Subj
GENmath.h
GENsignal.h
GENstdio.h
GENstdlib.h
GENstring.h
GENsys/stat.h
GENtime.h
GENunistd.h
And with the following patch, if you add this line
to your project's configure.ac file,
AM_SILENT_RULES([yes]) # make -
Jim Meyering wrote:
> The output from running "make" for coreutils-7.5, starts with nearly
> 500(!) lines worth of commands showing me precisely how just a few
> files in lib/ are being generated, e.g.,
...
> Subject: [PATCH] annotate automake snippets with $(AM_V_GEN) a
Akim Demaille wrote:
> Hi!
>
> Bison's bootstrap has a few changes compared to gnulib's. I'd like to
> use the stock bootstrap from gnulib, so there are a few changes that
> we would like to submit.
>
> First, a trivial matter: 'bootstrap | less' does not work as expected.
>
>
> From b490a83f8ba3f
Eric Blake wrote:
> According to Jim Meyering on 8/21/2009 3:28 AM:
>> And with the following patch, if you add this line
>> to your project's configure.ac file,
>>
>> AM_SILENT_RULES([yes]) # make --enable-silent-rules the default.
>
> Or you c
Bruno Haible wrote:
>> I'll wait for feedback before pushing.
>
> OK for me in general. However, I would combine some Makefile commands
> before adding the $(AM_V_GEN) placeholder. When you put $(AM_V_GEN)
> in front of the 'rm -f $...@-t $@' commands but use '$(AM_V_at)' in front of
> the command
Bruno Haible wrote:
> Here is a proposal to add a module 'mkostemp', using the source code changes
> from glibc. It also reduces the diffs to glibc, by incorporating parts of this
> glibc commit:
>
> http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d7e23b02a40384be1eaf00762ea36fd117c462cd
>
ice
I considered writing a test, but it would require running
libtool, and I'd rather not impose that on all users of
this module who choose to run gnulib tests.
>From 34963232379a99953721754a9b9721146f1a428b Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 24 Aug 2009 20:10:16 +0200
S
Bruno Haible wrote:
>> +2009-08-24 Jim Meyering
>> +
>> +progname: also set global program_invocation_name, when possible
>> +Before this change, a libtool-enabled program that calls glibc's
>> +error function would report the program name as
>
Sergey Poznyakoff wrote:
>> +#if HAVE_DECL_PROGRAM_INVOCATION_NAME
>> + program_invocation_name = (char *) argv0;
>> +#endif
>
> In my opinion, that's not correct. Libc (and gnulib's argp, FWIW) uses
> two variables: program_invocation_name, which points to the full program
> name as obtained fro
* ignore a function return without a compiler warning
- Copyright (C) 2008 Free Software Foundation, Inc.
+ Copyright (C) 2008-2009 Free Software Foundation, Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public Licen
Pádraig Brady wrote:
> Jim Meyering wrote:
>> Hmm... I guess you could be thinking about
>> warnings from non-gcc compilers. Yes, that's another way in which
>> (void)i is better.
>
> Right.
>
> BTW, I'm annoyed that one can't always do: (void) fu
Robert Millan wrote:
> This makes it easier to import xgethostname.c into an external program.
What's the motivation? removing dependencies?
> 2009-08-29 Robert Millan
>
> * lib/xgethostname.c: Remove `"xalloc.h"'.
> (xgethostname): Use realloc() instead of x2realloc().
>
...
> -
an-up.
>From 53181ad5a87facb5d424a04d039606a8694ce261 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 29 Aug 2009 17:24:03 +0200
Subject: [PATCH] maint.mk: remove more coreutils-specific targets; XZ_OPT=-9ev
* top/maint.mk (cvs-check): Remove target; it was just an alias
to the better-named vc-diff-check.
(main
Bruno Haible wrote:
> Pádraig Brady wrote:
>> I was wondering about this general issue a couple of days ago when pondering:
>> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=2bc0f3c
>>
>> At the application level we often want to check for this
>> "not supported" condition whil
[whoops. reposting to bug-gnulib, not bug-coreutils]
Hi Sergey,
In exclude.c, we have this:
bool
excluded_file_name (struct exclude const *ex, char const *f)
{
...
switch (seg->type)
{
case exclude_pattern:
rc = excluded_file_patt
FYI, there was a useless initialization in canonicalize_filename_mode.
[spotted by using clang: http://clang.llvm.org/StaticAnalysis.html]
This removes it:
>From 08999eb3be233d8c54c9fe00c5c263247265e897 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 31 Aug 2009 16:32:40 +0200
Subj
Simon Josefsson wrote:
> Getting gnulib to build natively on Windows was a bit difficult, "make"
> appears to break when trying to CreateProcess on /usr/bin/mkdir which
> doesn't exist as a binary. How about this patch? It allows users to
> specify the mkdir command when invoking 'make'.
>
> The
Eric Blake wrote:
> I will be pushing these later today as prerequisites to fixing fchdir and
> splitting fdopendir into its own module. This series avoids some compilation
> warnings due to missing chmod on mingw, and allows me to run gnulib testsuites
> under cygwin while cross-compiling to ming
Bruno Haible wrote:
> Jim Meyering wrote:
>> I've been lobbying to remove the obsolescent @VAR@ notation
>> in favor of $(VAR) notation for a long time.
> Using @VAR@ instead of $(VAR) removes one level of complexity, thus
> making debugging easier: If someone reports
Ralf Wildenhues wrote:
> * Bruno Haible wrote on Sun, Aug 30, 2009 at 11:30:53PM CEST:
>> > configure.ac:21: warning: The macro `AC_TRY_RUN' is obsolete.
>>
>> You can ignore these warnings. AC_TRY_RUN and AC_TRY_LINK cannot go away
>> because hundreds of autoconf macros use them.
>
> I'd venture t
FYI,
minor --help fix:
>From a96bd790af86ef28fbd95f619e390713587e2d8d Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 1 Sep 2009 08:49:27 +0200
Subject: [PATCH] announce-gen: correct formatting in --help output
* build-aux/announce-gen (usage): Move the one-line description in
--h
Bruno Haible wrote:
> Ralf Wildenhues wrote:
>> Still, the standards.texi authors found that additional flexibility so
>> useful that they explicitly document it as required for a set of tools
>> (node: Utilities in Makefiles).
>
> Citing it:
> Use the following @code{make} variables to run thos
Bruno Haible wrote:
> Jim Meyering wrote:
>> Consider consistency with automake-generated rules.
>> For example, I see these uses of $(MKDIR_P) in coreutils/lib/Makefile:
>> ...
>> I think anyone wanting to use some other MKDIR_P value
>> would be surprised (a
ose not to make it hard to ignore fts_set, since
for many uses, its return value is legitimately ignorable.
>From d7702d8443dae6073597f2cc4fa49f85dfeaaed2 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 1 Sep 2009 11:18:07 +0200
Subject: [PATCH 1/2] fts: fts_close now fails also when closi
FYI,
Here's a patch from Daniel P. Berrange to maint.mk.
Just pushed.
>From 1f6f04fa73397e0ed8de600aafdec45b976335a8 Mon Sep 17 00:00:00 2001
From: Daniel P. Berrange
Date: Tue, 1 Sep 2009 16:39:43 +0200
Subject: [PATCH] maint.mk: sort the list of syntax-check rules
* top/maint.mk (syntax-check-
Eric Blake wrote:
> Jim Meyering meyering.net> writes:
>> I suspect that it'd be very hard to trigger these close failures,
>> but it's better to be safe.
>
> While we're visiting fts, how about this patch? POSIX 2008 is clear that
> opendir should use
Eric Blake wrote:
> Eric Blake byu.net> writes:
>> > I think we need to implement opendir_safer, alongside all the other
>> > *_safer modules. Otherwise, opendir can end up placing an open directory
>> > fd in one of the standard slots, and end up interfering with the intent of
>> > all the other
Ralf Wildenhues wrote:
> * Jim Meyering wrote on Tue, Sep 01, 2009 at 08:19:55AM CEST:
>>
>> I'd welcome patches to modernize the m4/*.m4 files under my care.
>> Since I tend to use gnulib's files as models, it's worthwhile to
>> update them to use macro
Eric Blake wrote:
> Jim, what do you think of this patch, making it possible to avoid
> including "openat.h" if you only use the POSIX 2008 interfaces?
That's definitely the right thing to do.
Thanks for working on this.
I haven't looked at it carefully yet, but already
your mention of AT_EACCESS
Eric Blake wrote:
> Eric Blake byu.net> writes:
>> Here's the latest draft of my patch.
>
> While we're at it, I noticed via findutils that fts leaks fds into child
> processes. This plugs the fts leak (but completely fixing find also requires
> a
> patch to findutils).
>
> Hmm - POSIX states th
Ralf Wildenhues wrote:
> Hello All, esp. Ben, Paolo, Paul, Sergey, Simon,
>
> the patch below removes obsolete macros from modules not maintained by
> Bruno or Jim.
>
> Special here is check-math-lib.m4:gl_CHECK_MATH_LIB which uses macro
> arguments. Is this a public macro? All in-tree users do n
Eric Blake wrote:
> On on older machine (2.6.16.29 kernel, glibc 3.4.6), when using /proc
> emulation, openat(fd,"",O_RDONLY) was accidentally succeeding in opening a
> copy of /proc/self/fd/n (ie. the directory pointed to by fd) instead of
> failing with ENOENT. Fixed as follows. Fortunately, in
Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 5 Sep 2009 19:54:12 +0200
Subject: [PATCH] syntax-check: detect unnecessary inclusion of openat.h
* top/maint.mk (sc_prohibit_openat_without_use): New rule.
---
ChangeLog|5 +
top/maint.mk |5 +
2 files changed, 10 insertio
Akim Demaille wrote:
> Hi Friends,
>
> This makes Bison's and gnulib's bootstraps more alike.
Hi Akim!
Thanks. I've pushed that with a couple comment tweaks.
I think coreutils is ready for its pre-7.6 snapshot
and expect to make that tomorrow morning.
I hope to be able to use the latest from gnulib for that.
If you have doubts, or if you know of parts that are not
quite ready, please let me know.
Thanks,
Jim
Eric Blake wrote:
> Jim, what do you think of this patch, so that lchmodat only fails with
> ENOSYS when called on a symlink (when called on other file types, it would
> now succeed)?
>
> Also, should "openat.h" provide shortcuts named:
>
> accessat() => faccessat(,0)
> euidaccessat() => faccessat(
Eric Blake wrote:
> Two more *at functions. mkfifoat is rather simple; the hardest part was
> ensuring the test still compiles on mingw. renameat is more complex,
> although I intentionally made it call into a helper function, at_func2, so
> that I can reuse that function when I do linkat. The r
Hi Eric,
I would like to use strchrnul in libvirt, but its license is
listed at the default "LGPL" (as glibc-derived, I guess?)
and that conflicts with libvirt's requirement for LGPLv2+.
What do you think about relaxing it?
Jim
Eric Blake wrote:
> According to Jim Meyering on 9/8/2009 3:17 AM:
>> Hi Eric,
>>
>> I would like to use strchrnul in libvirt, but its license is
>> listed at the default "LGPL" (as glibc-derived, I guess?)
>> and that conflicts with libvirt's requir
Eric Blake wrote:
> According to Jim Meyering on 9/8/2009 2:43 AM:
>>> I suppose there might still be some pathological cases where renameat
>>> currently fails but could be made to succeed. For example,
>>> renameat(super_deep,a,root,b) will probably fail with ENAME
Eric Blake wrote:
> Eric Blake byu.net> writes:
>
>> According to Pádraig Brady on 9/7/2009 6:32 PM:
>> > gnulib 52c658e seems to have removed #include "openat.h" from fstatat.c
>> > but not replaced it with #include
>>
>> Yep; and only Solaris had the problem, because that is the only platform
>
I wanted this change in vc-dwim, since it doesn't use autoheader:
I'd rather skip autoheader than add an unnecessary AC_CONFIG_HEADERS.
>From 6588bee3103aceaf840cb073ef5717d85d3e412a Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 8 Sep 2009 22:21:59 +0200
Subject: [PATCH]
Ralf Wildenhues wrote:
> Some of the build-aux scripts weren't using the exact copyright header
> text as proposed in COPYINGv3. I only noticed when I was updating
> Autoconf files to v3. OK to apply?
Yes. Thanks!
Eric Blake wrote:
> I noticed that glibc has applied some fixes to canonicalize.c that we were
> missing; and sure enough, was able to enhance the testsuite to trip these
> bugs. They also applied some assert's proving that their optimization to
> avoid
> strcpy are safe; I left the asserts out,
I noticed that I hadn't been consistently including [stable]
or [beta] indications in the Subject of release announcements.
That's because I'd been adding them manually.
Now it's automatic:
>From 5e04fd8dbc859fa3dcb2de9cd3279df80bd3418b Mon Sep 17 00:00:00 2001
From: Jim
Eric Blake wrote:
> Jim Meyering meyering.net> writes:
>
>> > I noticed that glibc has applied some fixes to canonicalize.c that we were
>> > missing; and sure enough, was able to enhance the testsuite to trip these
>> > bugs. They also applied some assert&
Ralf Wildenhues wrote:
> * Paolo Bonzini wrote on Wed, Sep 09, 2009 at 09:22:56AM CEST:
>> On 09/08/2009 10:25 PM, Jim Meyering wrote:
>> >I wanted this change in vc-dwim, since it doesn't use autoheader:
>> >I'd rather skip autoheader than add an unnecess
with the Sat/Sun change.
I don't yet know if this change is a problem in mktime or due
to some intervening fix.
First, I'll commit this.
Then I'll write a proper test module.
Then, maybe, I'll worry about the DoW of Jan 1, year-zero ;-)
>From 6c9f1e88ada406b65f6b10098b8
Paolo Bonzini wrote:
>> --- - 2009-09-14 14:32:58.934253776 +0200
>> +++ in 2009-09-14 14:32:58.930840392 +0200
>> @@ -1,6 +1,6 @@
>> -12131415.16 13 1260713716 Sun Dec 13 14:15:16 2009
>> -12131415.16 13 1260713716 Sun Dec 13 14:15:16 2009
>> -01010
Paolo Bonzini wrote:
>>> Going backwards from "cal 1 1" you can see that in
>>> the Julian calendar 01-Jan- was a Thursday, but that's not so
>>> relevant.
>>>
>>> However cal can help seeing that 01-Jan- is a Saturday in
>>> Gregorian proleptic calendar (i.e. extending Gregorian calendar b
Eric Blake wrote:
> Jim Meyering meyering.net> writes:
>> > Eric Blake (6):
>> > canonicalize-lgpl: reject non-directory with trailing slash
>> > stdlib: sort witness names
>> > canonicalize: leave canonicalize_file_name to canonical
Jim Meyering wrote:
> Paolo Bonzini wrote:
>>>> Going backwards from "cal 1 1" you can see that in
>>>> the Julian calendar 01-Jan- was a Thursday, but that's not so
>>>> relevant.
>>>>
>>>> However cal can help s
Paolo Bonzini wrote:
>> { "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
>> { "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
>
> Uhm, why 2002? You could pre-generate all possible outputs from 2009
> to 2038 and only one of them will be checked.
Eric Blake wrote:
> Eric Blake byu.net> writes:
>> > I'm arguing that the second program should also report "No such
>> > file or directory".
>>
>> Ah, so for 'foo/', the code should distinguish between ENOENT and ENOTDIR,
>> based on whether 'foo' exists. I'll update the patch and test according
Eric Blake wrote:
> Jim Meyering meyering.net> writes:
>> FYI, here's the new test, in case anyone feels like reviewing:
>>
>> +static struct posixtm_test T[] =
>> + {
>> +{ "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 200
Eric Blake wrote:
> Eric Blake byu.net> writes:
>
>> Any objections to a patch that normalizes the outliers to drop #include?
>
> As in the following?
>
>>From 2655892372305598ee062e56f30b01c7d90ea178 Mon Sep 17 00:00:00 2001
> From: Eric Blake
> Date: Thu, 17 Sep 2009 11:49:36 -0600
> Subject:
David Lutterkort wrote:
> Just saw users.txt and thought it'd be nice to add augeas and netcf to
> the list.
Thanks!
I pushed that with a tweak to use netcf's http://
rather than https:// address.
...
> + netcf https://fedorahosted.org/netcf/
>newts http://svn.arete.cc/ne
Bruno Haible wrote:
> Hasso Tepper wrote:
>> time_t is 64 bits in recent NetBSD versions even on i386 platform,
>> therefore these assertations fail on it:
>>
>> in lib/mktime.c:
>> verify (long_int_year_and_yday_are_wide_enough,
>> INT_MAX <= LONG_MAX / 2 || TIME_T_MAX <= UINT_MAX);
>
> I'm di
Eric Blake wrote:
> According to Eric Blake on 9/16/2009 10:10 PM:
>> According to Eric Blake on 9/16/2009 9:11 AM:
I've reached this point in reading the patches.
So far they look fine.
I will read the remainder, and test tomorrow.
>>> I'll try and rebase my series before then.
>>
Eric Blake wrote:
> I'm working on a patch to fix unlink("file/") on Solaris 9. But as a
> prerequisite (to avoid anyone corrupting their file system if running the unit
> test as root, and accidentally unlinking an empty directory), I noticed that
> mingw failed to compile unlinkdir.c due to a mi
Eric Blake wrote:
> Jim Meyering meyering.net> writes:
>
>> > Meanwhile, the rmdir-errno module, in use by coreutils until today, guessed
>> > wrong for cross-compilation to Solaris (where rmdir fails with EEXIST, not
>> > ENOTEMPTY, on a populated directory
Bruno Haible wrote:
> Jim Meyering wrote:
>> >> time_t is 64 bits in recent NetBSD versions even on i386 platform,
>> >> therefore these assertations fail on it:
>> >>
>> >> in lib/mktime.c:
>> >> verify (long_int_year_and_yday_a
Jim Meyering wrote:
> Eric Blake wrote:
>
>> According to Eric Blake on 9/16/2009 10:10 PM:
>>> According to Eric Blake on 9/16/2009 9:11 AM:
>>>>> I've reached this point in reading the patches.
>>>>> So far they look fine.
>>>&
Eric Blake wrote:
> According to Jim Meyering on 9/18/2009 4:47 AM:
>> Assuming ln -s /nowhere dangling-symlink,
>> New behavior:
>>
>> $ ./readlink -fv dangling-symlink/
>> /nowhere
>>
>> Previous:
>>
>> $ readlink -fv dang
Jim Meyering wrote:
> Eric Blake wrote:
>> According to Jim Meyering on 9/18/2009 4:47 AM:
>>> Assuming ln -s /nowhere dangling-symlink,
>>> New behavior:
>>>
>>> $ ./readlink -fv dangling-symlink/
>>> /nowhere
>>>
>>>
Jim Meyering wrote:
> Paolo Bonzini wrote:
>
>>> { "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
>>> { "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
>>
>> Uhm, why 2002
Eric Blake wrote:
> According to Jim Meyering on 9/19/2009 10:46 AM:
>> +++ b/tests/test-posixtm.c
>> @@ -0,0 +1,175 @@
>> +/* Test that openat_safer leave standard fds alone.
>
> Really? This line is a bit too much copy-n-paste ;)
Hah! Thanks
, I've added this:
>From 27fc6b8b3c176038ff7216a6af6dfba82de17537 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 19 Sep 2009 19:51:05 +0200
Subject: [PATCH] syntax-check: detect unnecessary inclusion of canonicalize.h
* top/maint.mk (sc_prohibit_canonicalize_without_use): New rule.
---
ChangeLog
Eric Blake wrote:
> I'm pushing this, detected during a cygwin build:
Obviously ok. Thanks.
Eric Blake wrote:
> According to Eric Blake on 9/4/2009 11:58 AM:
>> Unfortunately, I don't have linkat working yet
>
> Still true, but here's another piece of the puzzle.
>
> fcntl_h.m4 created a symlink conftest.sym, but never cleaned it up; as a
> result, an ill-timed link-follow.m4 failed to cr
Eric Blake wrote:
> That Solaris 9 bug of ignoring trailing slash is pervasive. I'm looking at
> committing this series next, once I run it through tests on more machines.
These look like fine improvements. Although I haven't reviewed them
carefully, I suggest you go ahead and commit them whenev
Thomas Guyot-Sionnest wrote:
> On 31/08/09 09:54 AM, Simon Josefsson wrote:
>> Getting gnulib to build natively on Windows was a bit difficult, "make"
>> appears to break when trying to CreateProcess on /usr/bin/mkdir which
>> doesn't exist as a binary. How about this patch? It allows users to
>
Eric Blake wrote:
> According to Eric Blake on 9/18/2009 5:35 AM:
>> On one hand:
>>
>> ln -s dangling link => 0
>> stat dangling/ => ENOENT
>> stat link/ => ENOENT
>> mkdir link/ => 0
>
> Creating a directory through a slashed symlink works on Solaris 10, and is
> required by POSIX, but it fails
Eric Blake wrote:
> I'm currently testing these two patches, as mingw prerequisites before I can
> get linkat() working. In particular, mingw is lousy at SAME_INODE, since all
> three of [fl]stat produce st_ino == 0 for all files (then again, mingw never
> claimed POSIX compliance!). Code was alw
Simon Josefsson wrote:
> Jim Meyering writes:
>
>>> autoconf (GNU Autoconf) 2.61
>>> automake (GNU automake) 1.9.6
>>
>> That is because your version of automake is so old.
>> Use a newer one, if possible, preferably the latest: automake-1.11
>
>
Eric Blake wrote:
> According to Jim Meyering on 9/24/2009 12:29 AM:
>> bool same = false;
>> ...
>> same = SAME_INODE (source_dir_stats, dest_dir_stats);
>> if (same < 0)
>> same = (identical_basenames
>> &
Eric Blake wrote:
> According to Jim Meyering on 9/25/2009 5:59 AM:
>> When I see the tentacles of this change reaching so deeply into the core
>> of gnulib and coreutils, I have to question whether it is worthwhile
>> to accommodate mingw's lack of inode numbers.
>
If so, please tell me what version of bash it's using
so I can add that to the commit log.
>From 0f02aaf44de2d5dc0470bc9ca979f047df7df024 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 27 Sep 2009 08:41:55 +0200
Subject: [PATCH] test-yesno: use here document *without* parameter
Kurt Roeckx wrote:
> On Sun, Sep 27, 2009 at 08:51:48AM +0200, Jim Meyering wrote:
>> Thanks for the report.
>> Does the following change fix it?
>> If so, please tell me what version of bash it's using
>> so I can add that to the commit log.
>
> Note that
Bruno Haible wrote:
> Jim Meyering wrote:
>> # Test with seekable stdin; the followon process must see remaining data.
>> -cat < ${p}in.tmp
>> +cat < ${p}in.tmp
>
> This can be simplified to:
>
> tr @ '\177' < ${p}
Kurt Roeckx wrote:
> On Sun, Sep 27, 2009 at 11:03:42PM +0200, Jim Meyering wrote:
>> Thanks for the details.
>> Here's a patch that's more likely to work.
>> That this failure is specific to the sparc build
>> is a strong indication that it is a bug in
Eric Blake wrote:
> I'm trying to fix rename in order to implement renameat. So far, I've added
> workarounds for a Solaris 10 bug (rename("file","oops/") succeeded) and a
> Cygwin 1.5 bug (rename("hard1","hard2") reduced the link count of the hard
> linked file, such that when a later action unli
ld be worthwhile.
Any objection?
>From 1c233a6b61e3aca04d0edd02ad31a276d35bfcf4 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 1 Oct 2009 10:09:30 +0200
Subject: [PATCH] maint.mk: requiring "make major" was annoying, for a "minor"
release.
What is intended is "stable&qu
Paolo Bonzini wrote:
> Hi all, this is the first of a few patches to a few Win32 implementations
> of gnulib modules.
>
> This first one uses ANSI functions whenever we're passing or receiving
> strings, so that compiling with -DUNICODE succeeds. I started from the
> list of Win32 API functions, w
Eric Blake wrote:
> According to Jim Meyering on 10/1/2009 1:59 AM:
>>> So I'm guessing that the bug was related to actual directories, where rename
>>> ("dir/","new") failed (with what errno?) while rename("dir","new")
>>&g
ary branch, and removing it when done.
>From ee6bf517990504ad29488024f2f7dd089e91668c Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Fri, 2 Oct 2009 11:03:48 +0200
Subject: [PATCH 1/2] gnu-web-doc-update: New module.
Use this script to automatically update the on-line web documentation
for you
Jim Meyering wrote:
> FYI, I've just pushed this script, since I'm using it from coreutils
> and also used it for the just-announced gzip release:
>
> http://article.gmane.org/gmane.comp.gnu.gzip.bugs/258
>
> It makes lots of assumptions (see comments), and fiddle
Eric Blake wrote:
> According to Jim Meyering on 10/1/2009 1:28 PM:
>>> Here's the current state of the series, finally ready for review. If we
>>> check it in as-is, then coreutils will have everything it needs to ensure
>>> consistent behavior of '
is still possibility for failure.
> * doc/posix-functions/rename.texi (rename): Document the race.
> Reported by Jim Meyering.
...
Looks fine.
one nit
> diff --git a/doc/posix-functions/rename.texi b/doc/posix-functions/rename.texi
> index 65981db..be997aa 100644
> --- a/doc
901 - 1000 of 3902 matches
Mail list logo
