On Mon, Nov 21, 2005 at 10:07:29AM -0600, Peter Fales wrote:
> findutils fails to build on an HP-UX 10.20 machine because it doesn't
> have wctype.h.
Yes, along with much of the rest of the GNU tool set, GNU findutils
now assumes that it is being built on a system that complies with at
least th
Please note this correction to my earlier email, which incorrectly
stated that the 1990 ANSI C standard requires .
- Forwarded message from Geoff Clare -
From: Geoff Clare
To: James Youngman <[EMAIL PROTECTED]>
Subject: Re: findutils-4.2.26 build error on HP-UX 10.20
James,
I sa
On Sun, Nov 27, 2005 at 10:08:44PM -0800, Paul Eggert wrote:
> That doesn't sound quite right. If you compile with different C
> compilers, or the same C compiler with differing options, you should
> have to rerun 'configure'. The same sort of thing should occur if
> you compile with both a C an
On Wed, Nov 30, 2005 at 09:53:53PM +0100, Jim Meyering wrote:
> I haven't looked too closely at find, but its -execdir predicate
> makes me think having exec*at functions would be useful, too.
Only slightly. POSIX requires that -exec should happen with the
working directory the same as it was wh
On Wed, Dec 07, 2005 at 04:55:38PM +0100, Georg Schwarz wrote:
> Dear developers,
>
> findutils 4.2.27 does not compile on IRIX 5.3:
[...]
> cfe: Error: ./mbchar.h: 157: Cannot open file wchar.h for #include
[...]
> IRIX 5.3 does not have wchar.h.
Later versions (1995, I think) of the ANSI C stan
On Wed, Dec 07, 2005 at 11:59:13PM -0800, Paul Eggert wrote:
> [EMAIL PROTECTED] (James Youngman) writes:
>
> > Later versions (1995, I think) of the ANSI C standard require it. The
> > file which you can't compile is part of gnulib, but gnulib only builds
> > on AN
On Thu, Dec 08, 2005 at 01:47:08PM +0100, Georg Schwarz wrote:
> > Later versions (1995, I think) of the ANSI C standard require it. The
> > file which you can't compile is part of gnulib, but gnulib only builds
> > on ANSI-standard-compliant systems.
>
> is it possible to build fileutils witho
On Sat, Dec 17, 2005 at 08:38:06PM +0100, Georg Schwarz wrote:
> After some poking around with the findutils 4.2.27 code it turned out
> that the following patch makes it compile on IRIX 5.3:
Great. Does the test suite also pass ("make check") with this patch
installed?
> --- ./gnulib/lib/mbcha
On Fri, Dec 16, 2005 at 04:22:06PM +0100, Jim Meyering wrote:
> I've just checked in the files that complete the
> implementation of the new fprintftime module.
> In coreutils, both date and du now use fprintftime.
Any plan to have 'ls' do so too? Of course there is the problem that
the format ch
On Sat, Dec 17, 2005 at 11:36:16PM +0100, Georg Schwarz wrote:
> > On Sat, Dec 17, 2005 at 08:38:06PM +0100, Georg Schwarz wrote:
> > > After some poking around with the findutils 4.2.27 code it turned out
> > > that the following patch makes it compile on IRIX 5.3:
> >
> > Great. Does the test s
On Thu, Jan 05, 2006 at 02:03:27PM -0800, Paul Eggert wrote:
> Because the current convention is to put this declaration in the main
> program, at the top level:
>
> char *program_name;
>
> Hence the main program has allocated program_name, and has arranged
> for it to be initialized to null. If
On Thu, Jan 05, 2006 at 03:06:59PM -0800, Paul Eggert wrote:
> [EMAIL PROTECTED] (James Youngman) writes:
>
> > I would prefer an arrangement which results in a compilation or link
> > failure if the user (i.e. software maintainer) fails to initialise
> > things properl
On Thu, Jan 05, 2006 at 03:06:59PM -0800, Paul Eggert wrote:
> [EMAIL PROTECTED] (James Youngman) writes:
>
> > I would prefer an arrangement which results in a compilation or link
> > failure if the user (i.e. software maintainer) fails to initialise
> > things properl
On Mon, Jan 09, 2006 at 02:49:45PM +0100, Bruno Haible wrote:
> And how about a runtime failure that occurs in every invocation? We
> could add a check in getopt() and getopt_long(), verifying that
> program_name is non-NULL. Most GNU programs use getopt() and
> getopt_long().
I like the principl
On Tue, Jan 10, 2006 at 11:07:20PM +0900, Peter O'Gorman wrote:
> char *
> get_prog_name(void)
> {
> char * name;
> if (prog_name)
> name = prog_name;
> else
> {
> #if defined(HAVE_GETPROGNAME)
> #include
> name = getprogname();
> #elif defined(
On Tue, Jan 17, 2006 at 10:33:18PM +0100, Jim Meyering wrote:
> FTS API change:
> ==
>
> This changes the fts API.
Is there a way for autoconf-using gnulib client s to select only the
gnulib version? I'm happy to adopt the change, as long as I don;t run
the risk of having 'configur
Hi,
This savannah bug report
http://savannah.gnu.org/bugs/?func=detailitem&item_id=15587
alleges that findutils-4.2.24 won't link statically against
glibc-2.3.6 due to this error:
/usr/src/lvp_0.5.2-dev/build/generic-TRUNK-x86-lvp/ROCK/tools.cross/i386-unknown-linux-gnu/lib/libc.a(regex.o):(.rod
On 5/24/06, Bruno Haible <[EMAIL PROTECTED]> wrote:
Then the argument about the glibc behaviour and the *BSD libc behaviour is
moot: if there's a single platform where it crashes, and if the standard says
that NULL are invalid arguments, gnulib's implementation can crash as well.
I would go fu
On 5/19/06, Bruno Haible <[EMAIL PROTECTED]> wrote:
Jim Meyering wrote:
> may cause trouble for people who put the libobj directory elsewhere.
> If any of you know of such a package, please let me know.
There are many such packages:
- gettext: both libgrep and lib (not just one directory).
-
On 6/18/06, Karl Berry <[EMAIL PROTECTED]> wrote:
These are functions which I had been replacing in my usual
program-specific lib, via:
AC_REPLACE_FUNCS(memcpy memmove strdup strerror)
So, all in all, it seems that gnulib assumes that it will be responsible
for anything and everything ending u
On 7/28/06, Alexander Kostadinov <[EMAIL PROTECTED]> wrote:
I've downloaded findutils 4.2.27
my gcc is 2.95.3
On compile it returnes "cc1 got fatal signal 11"
I found out that a line in regex.c causes the problem.
#include "regcomp.c"
I don't know if this is a compiler bug or is a sign of bug in
On 8/15/06, Karl Berry <[EMAIL PROTECTED]> wrote:
we should be generating it automatically from findutils
My recollection is that James does generate it from findutils, and
checks in the new version to gnulib, or sends it to me, or something
like that. James will inform us, I'm sure.
I wo
On 8/22/06, Eric Blake <[EMAIL PROTECTED]> wrote:
I went ahead with the whole new module approach. James, I hope you don't
mind being listed as a maintainer
That's fine.There is an argument for moving findutils'
findutils/lib/regexprops.c into gnulib (and hence making findutils an
ordinary
On 10/4/06, Jim Meyering <[EMAIL PROTECTED]> wrote:
The resulting down side is that the old version of find is
susceptible to a nasty type of attack when traversing a directory
that is writable by another user.
I think even oldfind (i.e. version 4.2.x and the alternate binary in
4.3.x) has suf
On 6/19/06, Simon Josefsson <[EMAIL PROTECTED]> wrote:
"James Youngman" <[EMAIL PROTECTED]> writes:
> I believe so. In findutils I ended up working around the problem by
> defining a FINDLIB_REPLACE_FUNCS defun which populates @[EMAIL PROTECTED]
> In other wo
On 10/5/06, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
This one should work, since the file descriptor in the working
directory should prevent the inode from going away. Or is there
something I'm missing?
We like to have a way of searching a directory hierarchy 10 levels
deep without needi
[+bug-findutils since we're discussing this example in that context]
On 10/5/06, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> But what about symlinks?
>
> a g
>b h->a
> c
> f->g
>
> The moment you traverse the f->g symlink above,
> the entire tree, a/b/c/f, is no longer
I am using gettext version 0.14.6. Its version of po/Makefile.in.in
uses @MKINSTALLDIRS@, but the m4 files in current gnulib do not
substitute that variable. This means that the generated po/Makefile
contains a naked @[EMAIL PROTECTED]
I think that's an incompatibility between current gnulib a
On 11/25/06, James Youngman <[EMAIL PROTECTED]> wrote:
I am using gettext version 0.14.6. Its version of po/Makefile.in.in
uses @MKINSTALLDIRS@, but the m4 files in current gnulib do not
substitute that variable. This means that the generated po/Makefile
contains a naked @[EMAIL PRO
On 11/27/06, Bruno Haible <[EMAIL PROTECTED]> wrote:
There is no long-term stable interface between *.m4 and Makefile.in.in.
This means, you need to take both from the same version. And gnulib here
counts as the newest released gettext version.
OK. Is po/Makefile.in.in in gettext? If not,
On 11/28/06, James Youngman <[EMAIL PROTECTED]> wrote:
OK. Is po/Makefile.in.in in gettext? If not, do I need to obtain
gettext from CVS as well?
Sorrym I meant, is it in gnulib? If not, where do I get the version
that works with current gnulib?
James.
EADME file lets other people know that they might find that
list useful.
2006-11-28 James Youngman <[EMAIL PROTECTED]>
* README: Advise users that they might find the [EMAIL PROTECTED]
and autotools-announce@gnu.org mailing li
On 11/27/06, Eric Blake <[EMAIL PROTECTED]> wrote:
Based on this thread, I took a leap and ported git/cogito to cygwin, so
that they are now available from a standard cygwin installation, and am
considering using git on more projects myself. I think moving gnulib to
git would be reasonable; I pa
On 12/25/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
The 'tar' version is correct. But this is not an Autoconf issue; it
is a gnulib version issue. The gnulib fix (dated March 25) is here:
http://cvs.savannah.gnu.org/viewcvs/gnulib/gnulib/m4/regex.m4?r1=1.50&r2=1.51
but apparently findutils is
On 8/15/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
For lack of a better solution I installed this into regexprops-generic.texi.
After looking at the findutils sources I don't see how the file is
generated automatically -- perhaps some by-hand processing is
always done?
In gnulib, yes. The file
On 1/16/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
Hi,
This will be used by the second part of the Unicode string library
[...]
Is there a reason not to just use ICU (http://icu.sourceforge.net/)?
James.
I've just synced my CVS version of gnulib and it includes that
ChangeLog entry. I am using Autoconf version 2.61 and Automake
version 1.9.6.
My generated aclocal.m4 file wants to substiture mkdir_p (courtesy of
AM_PROG_MKDIR_P) but doesn't define AC_PROG_MKDIR_P. Nevertheless my
gnulib-common
On 1/22/07, Simon Josefsson <[EMAIL PROTECTED]> wrote:
"James Youngman" <[EMAIL PROTECTED]> writes:
> However, I think the problem is that on this system, the Makefile.in
> file is not actually using @MKDIR_P@ :-
Yes, I still get the same problem. I have tried Br
On 1/22/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
James Youngman wrote:
> My generated aclocal.m4 file wants to substiture mkdir_p (courtesy of
> AM_PROG_MKDIR_P) but doesn't define AC_PROG_MKDIR_P. Nevertheless my
> gnulib-common.m4 file is indeed at serial 2 and the gl
On 1/22/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
> > 2007-01-22 James Youngman <[EMAIL PROTECTED]>
> >
> > * m4/gnulib-common.m4 (AC_PROG_MKDIR_P): If AC_PROG_MKDIR_P
> > is already provided, call AC_SUBST on MKDIR_P anyway, since
> &
On 2/18/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
Hmm, should we reduce the amount of gnulib changes in this period
I hope that sort of thing would not be necessary, otherwise gnulib
will have its development stalled by the release shedules of GNU
packages other than gnulib, presumably.
Jam
On 2/5/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
This introduces a new module mbscasestr. mbscasestr() is like glibc's
strcasestr(), except it works on character strings (i.e. on multibyte strings).
Thanks for adding this. Findutils 4.3.x now uses the mbscasestr and
mbsstr modules in order t
I see that FreeBSD and NetBSD support st_birthtime. I'm considering
supporting these in findutils. Is there any interest in suporting
(i.e. maintaining if I contribute a patch) this in stat-time.h?
If there is interest in maintaining the feature, how should we handle
systems (like Linux) where
On 3/6/07, Paul Eggert <[EMAIL PROTECTED]> wrote:
"James Youngman" <[EMAIL PROTECTED]> writes:
> I see that FreeBSD and NetBSD support st_birthtime. I'm considering
> supporting these in findutils. Is there any interest in suporting
> (i.e. maintaining i
I see that getdate.y normally zeroes out the nanoseconds field (e.g.
$$.tv_nsec = 0).
Is it likely that changing the parser to accept floating-point seconds
fields would change the meaning of time specifiers that previously
were interpreted differently? It doesn't immediately seem so to me,
but
On 3/7/07, Simon Josefsson <[EMAIL PROTECTED]> wrote:
What do people think about to offer a new set of modules that use
64-bit integers for time representation?
Mildly in favour. That is, removing the year-2038 limitation seems worthwhile.
I'm thinking a time64.h:
#include
typedef int64_t
On 1/4/07, Paul Eggert <[EMAIL PROTECTED]> wrote:
Generally speaking, I find it easiest just to sync all of gnulib.
That's what everyone else does. It's simpler, since you don't need
to worry so much about integration hassles within gnulib.
[...]
If you take gnulib snapshots, you can diff the
On 3/8/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
Paul Eggert wrote:
> Clearly you don't write financial applications dealing with 30-year
> bonds. :-)
So you want that 'time64_t' type to be useful specifically for financial
applications? I'm wondering because
- For computing interests in
On 3/11/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
[...]
+ #ifdef __sun
+ /* This declaration ensures that the library will export at least 1 symbol.
*/
+ int dummy;
+ #else
[...]
Could we maybe pick an external symbol name that's less likely to
clash? I don't mind gnulib defining external
On 3/16/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
The 'dummy' module is hardly used in practice, because it gets disabled
as soon as you have at least one gnulib module with an unconditional
lib_SOURCES augmentation.
IMHO it's the things that only happen sometimes that really bite you in the
On 3/22/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
fnmatch() has a worst-case complexity O(m*n) where m is the size of the
pattern and n is the size of the sample string. Unfortunately glibc has
chosen an implementation with exponential running time.
Yes. Oddly, per some testng I did about a
Apologies if I have something signficant wrong; it's my first
nontrivial gnulib patch.
2007-03-24 James Youngman <[EMAIL PROTECTED]>
* lib/stat-time.h (get_stat_birthtime): New function for
retrieving st_birthtime as provided by UFS2 (hence *BSD).
* m4/s
On 3/25/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
This is Paul's domain; nevertheless I'd like to mention that native Woe32
platforms (mingw, msvc, but not Cygwin) implementation of stat() and
fstat() store the "file creation time" in st_ctime. This is even documented
on msdn.microsoft.com. The
should arguably skip the test
withough failing if that happens.
2007-03-27 James Youngman <[EMAIL PROTECTED]>
* lib/stat-time.h (get_stat_birthtime): New function for
retrieving st_birthtime as provided by UFS2 (hence *BSD).
* m4/stat-time.m4 (gl_STAT_BIR
Changed test_birthtime's return value to 'void', since the function falls
off without providing a return value, and since the return value is effectively
not used.
Changed NFILES from 5 to 4, to avoid using uninitialized values.
Removed the "1 || " in the test, that disabled the test_birthtime t
On 3/27/07, Paul Eggert <[EMAIL PROTECTED]> wrote:
- /* Birth time not supported. */
- pts->tv_sec = 0;
- pts->tv_nsec = 0;
- return 0;/* result is not valid */
+ /* Birth time is not supported. Set tv_sec to avoid undefined behavior. */
+ t.tv_sec = -1;
+ t.tv_nsec
On 3/28/07, Gary V. Vaughan <[EMAIL PROTECTED]> wrote:
ii) except that doesn't tell us which gnulib release was used, so we
need to factor the gnulib timestamp information too :-( I think
we can maybe get away with just making bootstrap write a gnulib
repo timestamp into a v
On 3/29/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
gnulib now has more than 600 modules, some of which are already in
subdirectories. Still, there are more than 500 modules at the top level.
I propose two new subdirectories in the modules directory, with the aim of
clarity:
1) a subdirectory
On 3/29/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
I don't think it does. One would need to pass extra -I flags to 'aclocal'.
gnulib-tool doesn't do this yet.
It would be useful to findutils if it did though, I think. Findutils
currently does this:
aclocal -I m4 -I gnulib/m4
James.
On 3/29/07, Simon Josefsson <[EMAIL PROTECTED]> wrote:
That's true. I guess it depends on the refactor discriminator.
Either based or content (crypto, unicode, string-functions,
math-functions, etc), or type (header, file, etc). To me, all the
crypto stuff seems self-contained and uninteresting
the test:
- Turn this ASSERT into an 'if' that does appropriate action if not fulfilled.
- Immediately after renaming the file, write something into it, so that also
on this weird filesystem the ctime is bumped.
Does the following patch fix the problem?
2007-03-30 James Y
It seems to me that there is a certain amount of
(confusion|disagreement) among members of the austin-group-l mailing
list, who are, almost by definition, connoisseurs of standards wording
and distinguishers of fine points.
If the members of that list cannot mostly agree on what exactly the
stand
e is a patch which should fix it (tested
on Linux and FreeBSD (with and without st_birthtime). I have no
access to FreeBSD (since it doesn't support Xen yet).
2007-04-03 James Youngman <[EMAIL PROTECTED]>
* lib/stat-time.h: (get_stat_birthtime): Check for zero-valued
Hello all,
GNU findutils currently uses the full @node command for speficying the
navigational structure of the Findutils manual. So it contains @node
commands like this:-
@menu
* Introduction::Summary of the tasks this manual describes.
* Finding Files:: Finding
[ bug-gnulib moved to BCC, bug-findutils added to CC ]
On Sun, Nov 16, 2008 at 11:34 AM, SciFi <[EMAIL PROTECTED]> wrote:
> (1) Regular 'make' finishes okay, then I'll do 'make check'.
> The first real problem I had here was linking
> coreutils-7.0/gnulib-tests/test-getdate failed because the
> m
On Thu, Nov 27, 2008 at 10:53 PM, Eric Blake <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> [dropping cygwin-patches, since posts are closed to non-subscribers, and
> adding bug-findutils and bug-gnulib. Christian is working on a patch that
> lets cygwin do initia
On Fri, Nov 28, 2008 at 7:19 PM, Jim Meyering <[EMAIL PROTECTED]> wrote:
First, many thanks for looking at this!
> +/* Map the dirent.d_type value, DTYPE, to the corresponding stat.st_mode
> + S_IF* bit and set ST.st_mode, thus clearing all other bits in that field.
> */
> +static void
> +se
On Fri, Nov 28, 2008 at 6:59 PM, Karl Berry <[EMAIL PROTECTED]> wrote:
> Some months ago we discussed a convention for supporting "special"
> characters in filenames ("sources") in error messages. Our conclusion
> then was to support C-style escapes.
I'm all for bringing a measure of consistency
On Sat, Nov 29, 2008 at 3:46 PM, Jim Meyering <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> wrote:
>> "James Youngman" <[EMAIL PROTECTED]> wrote:
>>> As far as I can see, the variable type is assigned in the function
>>> abo
On Sat, Nov 29, 2008 at 3:53 PM, James Youngman <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 29, 2008 at 3:46 PM, Jim Meyering <[EMAIL PROTECTED]> wrote:
>> Jim Meyering <[EMAIL PROTECTED]> wrote:
>>> "James Youngman" <[EMAIL PROTECTED]> wrote:
>
es/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Eric B. Decker, James Youngman, and Kevin Dalley.
Built using GNU gnulib version e5573b1bad88bfabcda181b9e0125fb0c52b7d3b
Features enabled: D_TYPE O_NO
On Wed, Dec 10, 2008 at 1:08 AM, Jan Minář <[EMAIL PROTECTED]> wrote:
> 2008/12/10 James Youngman <[EMAIL PROTECTED]>:
>> $ date -d "next `LC_ALL=C date +%A`"
>> mercredi 10 décembre 2008, 00:00:00 (UTC+)
> ^^^
>
> You'
---
ChangeLog|6 ++
lib/getopt.c | 25 +
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 7faac2b..b593588 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2008-12-14 James Youngman
+
+ getopt
On Sun, Dec 14, 2008 at 7:05 PM, Bruno Haible wrote:
> James Youngman wrote:
>> +2008-12-14 James Youngman
>> +
>> + getopt: Indicate the problem with ambiguous options clearly.
>> + * lib/getopt.c (_getopt_internal_r): Print the first and second
>> +
On Mon, Dec 15, 2008 at 12:18 AM, Bruno Haible wrote:
> However, for openat-die.c I don't see a good replacement. In particular, I
> don't see a way how openat_restore_fail() could be handled in library code.
> A program cannot simply continue when its current directory is different from
> what it
On Sat, Dec 27, 2008 at 11:42 AM, Jim Meyering wrote:
> If find were to apply this same technique, it would make the
> -noleaf predicate a no-op.
>
> FYI, when I run the modified find on a reiserfs-backed 1.6M-file maildir
> hierarchy, it takes only 80 seconds (2.6.26, athlon64 3400+, 2yr-old dis
On Sun, Jan 4, 2009 at 12:09 AM, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to James Youngman on 1/3/2009 3:04 PM:
>> 2. There exist other filesystems where (st_links - (0 or 2)) <
>> (subdirectory count). The only example I can
Please note that my contributions to gnulib-tool so far have been
nonexistent; weigh my statements accordingly...
On Sun, Jan 4, 2009 at 10:25 PM, Bruno Haible wrote:
> If gnulib-tool was to be rewritten in another programming language than
> shell + sed, what would be the good choices?
>
> The f
On Sun, Jan 11, 2009 at 10:38 PM, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Jim Meyering on 1/11/2009 3:06 PM:
>> I tried your "find -L dir-containing-loop" example
>> on ext3, tmpfs, and xfs, and it appears d_type is always DT_LNK,
>
> Is there any file
What's the effect of the change? Merely a performance difference?
Or is there a correctness issue?
On Sun, Feb 15, 2009 at 11:04 PM, Bruno Haible wrote:
> + dnl The include of is because IBM C 9.0, 10.1 (original
> + dnl versions, prior to 2009-01 updates) on AIX 6.1 supports include_next
> + dnl when used as first preprocessor directive in a file, but not when
> + dnl preceded
On Sun, Mar 8, 2009 at 8:16 AM, Frank Erens wrote:
> I'm sorry for the late response. I've tried compiling findutils-4.2.33,
> and that one didn't gave me the error. Likewise, gettext-0.17 gives
> the error, while gettext-0.16 does not. That means the problem is
> solved for me. I don't have a lot
[ adding nug-gnulib to CC since we're discussinf its fts implementation ]
On Sun, Mar 8, 2009 at 2:50 PM, George Spelvin wrote:
> James Youngman wrote:
>> The updated patches are what I actually pushed (into 4.5.x).
>
> Ah, thank you. The posted patches wouldn't a
$ git checkout jy/auto-gettext
Switched to branch "jy/auto-gettext"
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying Update to version 0.17 of GNU gettext.
error: patch failed: ChangeLog:41
error: ChangeLog: patch does not apply
Using index info to reconstruct
On Mon, Mar 9, 2009 at 12:42 AM, James Youngman wrote:
> $ git checkout jy/auto-gettext
> Switched to branch "jy/auto-gettext"
> $ git rebase master
> First, rewinding head to replay your work on top of it...
> Applying Update to version 0.17 of GNU gettext.
> error
On Mon, Mar 9, 2009 at 12:42 AM, James Youngman wrote:
> $ git rebase master
> First, rewinding head to replay your work on top of it...
> Applying Update to version 0.17 of GNU gettext.
> error: patch failed: ChangeLog:41
> error: ChangeLog: patch does not apply
> Using index i
On Wed, Mar 11, 2009 at 11:57 AM, Bruno Haible wrote:
> OK, I'll work on the creation of a GNU project called 'libunistring', that
> will export the functions from gnulib as a shared library.
My first reaction was, why isn't libunistring===glibc, but then we'd
end up in a situation where gnulib w
On Thu, Apr 2, 2009 at 1:32 AM, Reuben Thomas wrote:
> On Thu, 2 Apr 2009, Bruno Haible wrote:
>
>> That's the common convention for when you receive a package in the form of
>> a
>> tarball. For CVS or git checkouts, there is no such conventions.
>
> Well, most packages that have INSTALL have it
[ CC += bug-findutils, bug-gnulib; bug-coreutils moved to BCC ]
On Thu, Apr 16, 2009 at 8:09 PM, Ondrej Bilka wrote:
> Hello. I am writing partial fnmatch to speed up locate et al.
Please note that locate is part of GNU findutils, not GNU coreutils.
I have CC'ed this email to the correct list.
On Mon, Apr 27, 2009 at 4:09 PM, Natraj, Ashutosh wrote:
>
> Dear Sir/Madam,
> I am a masters student involved in the Master thesis project in
> vision, and I require the "glibc header files" because for my sample
> program to be executed required io.h and sys\stat.h and sys\types.h
> upon readin
2009/5/6 Pádraig Brady :
> I can see this causing compat issues?
> http://blog.aurel32.net/?p=47
> Is there anything we could/should do to avert it?
My reading of the blog post would be that eglibc would be available
_as well_ rather than _instead_. That is, people could decide to
install egli
On Fri, May 8, 2009 at 12:02 AM, Bruno Haible wrote:
>
> I think gnulib supports all possible ways the maintainer prefers:
> - If the maintainer wants always the newest fdl.texi, he uses the
> 'fdl' module or takes the 'fdl' module.
> - If the maintainer wants always the newest version of a s
On Fri, May 8, 2009 at 12:07 PM, Bruno Haible wrote:
> James Youngman wrote:
>> This conflates two separate issues though:
>> 1. Which license the developer chooses to use and their strategy for
>> updating it
>> 2. The technical process by which the project manage
On Fri, May 8, 2009 at 11:21 PM, Bruno Haible wrote:
> Andreas Schwab wrote:
>> They are free to access the object in any random order they like.
>
> The question is: How many bytes are the mem* functions free to access?
>
> How many bytes is "the object" large?
If s is NULL, there _is_ no object
On Sat, May 9, 2009 at 11:59 AM, David Bartley
wrote:
> I considered this. There are at least 3 different variants of ACL's
> (POSIX, NFSv4 and MacOS X) and they are generally incompatible. UMich
> created patches to acl/libacl so that you could set NFS4 acl's via
> getfacl/setfacl using POSIX AC
[ bug-coreutils moved to BCC, CC += bug-gnulib ]
On Wed, May 27, 2009 at 8:04 PM, Giuseppe Scrivano wrote:
> Hi Eric,
>
> Eric Blake writes:
>
>> Would it be worth starting to patch the testsuite to replace 'setuidgid -g
>> list usr cmd arg' with 'chroot --user usr --groups=list / cmd arg' in
>>
On Sun, Jun 7, 2009 at 10:35 PM, Bruno Haible wrote:
> /* Drop the gid privilege first, because in some cases dropping the gid
I think you need to delete the word "dropping" in the line above.
> privilege cannot be dropped after the uid privilege has been dropped. */
> #if HAVE_GETUID
> in
On Tue, Jun 9, 2009 at 4:40 AM, Sam Steingold wrote:
> int foo () {
> if (foo_low() == NEED_ABORT) {
> fprintf(stderr,"life sucks\n");
> abort();
> }}
>
A problem with code snippets like that in a security context is this attack:
cd /tmp
prog="root::0:0:root::"
ln -s /usr/bin/setuid-program
On Thu, Jun 11, 2009 at 10:10 PM, Bruno Haible wrote:
> Shouldn't the program also call setgroups (possibly indirectly through
> initgroups), in order to make sure that it can write any file that the
> user can write to?
That is usually necessary but not always sufficient, for example see
http://
On Fri, Jun 12, 2009 at 12:29 AM, Bruno Haible wrote:
>> That is usually necessary but not always sufficient, for example see
>> http://blogs.sun.com/peteh/date/20050614
>
> What do you mean by "not always sufficient", other than kernel bugs and
> implementation limits? Assuming a small number of
1 - 100 of 304 matches
Mail list logo
