Re: POSIX 2008 available

On Tuesday 09 December 2008 17:02:51 Eric Blake wrote: > POSIX 2008 is now freely available at: > > http://www.opengroup.org/bookstore/catalog/c082.htm > > which, once you accept a cookie, redirects to: > > http://www.opengroup.org/onlinepubs/9699919799/toc.htm wonder if the canonical link will be

mem*/strr*/etc... obsolete warnings

a bunch of modules were labeled as obsolete recently, but no information was included explaining why. perhaps the toplevel NEWS should be updated, as well as the "Notice" section of each module pointing people to the place for more information and/or just telling them why right there ... as it

working with "good enough" functions

the gnulib implementations of POSIX functions are pretty damn complete. for most of my uses though, they're *too* complete :). for example, current gnulib will often enable printf functions on modern systems (such as Linux w/glibc 2.9). this is because extended floating point support breaks f

Re: choice of implementation language

On Sunday 04 January 2009 17:25:40 Bruno Haible wrote: > If gnulib-tool was to be rewritten in another programming language than > shell + sed, what would be the good choices? > > The foremost criteria IMO should be the maintainability, i.e. the ability > for us and for new contributors to gnulib t

Re: working with "good enough" functions

On Monday 05 January 2009 05:24:17 Paolo Bonzini wrote: > >> is there a standard way for addressing this ? or should i cheat and set > >> the vars to yes before calling gl_{EARLY,INIT} ? if i add a line like > >> this: gl_cv_func_printf_infinite_long_double=yes > > > > Yes, that (seeding the cach

Re: choice of implementation language

On Wednesday 07 January 2009 09:39:06 Sam Steingold wrote: > Bruno Haible wrote: > > If gnulib-tool was to be rewritten in another programming language than > > shell + sed, what would be the good choices? > > a popularity contest is not the way to choose a language. > > and why aren't you even con

Re: choice of implementation language

On Wednesday 07 January 2009 11:12:57 Sam Steingold wrote: > Mike Frysinger wrote: > > On Wednesday 07 January 2009 09:39:06 Sam Steingold wrote: > >> Bruno Haible wrote: > >>> If gnulib-tool was to be rewritten in another programming language than > >>> s

Re: working with "good enough" functions

On Thursday 08 January 2009 04:49:16 Paul Eggert wrote: > Mike Frysinger writes: > > i explicitly pulled in the > > printf-posix module because i want a posix implementation on crappy > > systems. but i dont care if said systems have broken floating point > > imple

Re: working with "good enough" functions

On Thursday 08 January 2009 11:55:03 Simon Josefsson wrote: > Mike Frysinger writes: > > On Thursday 08 January 2009 04:49:16 Paul Eggert wrote: > >> Mike Frysinger writes: > >> > i explicitly pulled in the > >> > printf-posix module because i want a pos

Re: working with "good enough" functions

On Saturday 17 January 2009 15:34:39 Bruno Haible wrote: > Mike Frysinger and Simon Josefsson wrote: > > >> If this happens often enough, perhaps gnulib should have a > > >> printf-posix-no-fp module that does what you want? > > > > > > i would certain

Re: mem*/strr*/etc... obsolete warnings

On Saturday 17 January 2009 15:24:36 Bruno Haible wrote: > Mike Frysinger wrote on 2009-01-04: > > a bunch of modules were labeled as obsolete recently, but no information > > was included explaining why. > > They were marked obsolete because the problems that they fix don&

Re: mem*/strr*/etc... obsolete warnings

On Saturday 24 January 2009 10:44:22 Bruno Haible wrote: > Mike Frysinger wrote: > > > What extra information would you find useful here? > > > > the simple explanation you posted in your e-mail should be in the > > documentation. and the modules file should point

Re: mem*/strr*/etc... obsolete warnings

On Tuesday 27 January 2009 18:11:33 Bruno Haible wrote: > Mike Frysinger wrote: > > any reason for not adding a note when > > warning about obsolete stuff ? rather than updating every module that is > > marked obsolete, the gnulib tool itself could include the pointer. >

Re: mem*/strr*/etc... obsolete warnings

On Wednesday 28 January 2009 05:02:37 Bruno Haible wrote: > Mike Frysinger wrote: > > i mean something simple like this (and the output from gnulib-tool still > > looks sane to me): > > --- a/modules/memcpy > > +++ b/modules/memcpy > > @@ -5,7 +5,7 @@ Stat

new mmap() module (for windows) and license choice

i wrote a mmap/munmap replacement for windows for another project of mine after i got it working, i realized that ive used gnulib in quite a bit of things and it kind of sucks that there is no mmap module already. so i looked at contributing it to gnulib and had some questions regarding copyri

Re: Bugs in unexpand(1) version 6.10

On Tuesday 10 February 2009 15:10:59 Jim Meyering wrote: > Mike Frysinger wrote: > > On Friday 06 February 2009 01:13:13 Jim Meyering wrote: > >> Pádraig Brady wrote: > >> > Mike Frysinger wrote: > >> >> On Tuesday 03 February 2009 03:28:58 Jim M

Re: Bugs in unexpand(1) version 6.10

On Wednesday 11 February 2009 02:04:11 Jim Meyering wrote: > Mike Frysinger wrote: > ... > > >> > i was thinking a common change to the version-etc module to add a > >> > "packager" field rather than having every package out there allow > >> &

Re: Bugs in unexpand(1) version 6.10

On Wednesday 11 February 2009 13:31:57 Karl Berry wrote: > $ ls --version > ls (GNU coreutils) 6.12 > Packaged by ... some distro string here ... > > That looks like the right place to me. I'd be tempted to put a blank > line between "Packaged by ..." and "Copyright ...". the attached

Re: linker-script.m4?

On Monday 02 March 2009 06:27:49 Bruno Haible wrote: > Simon Josefsson wrote: > > The version script file is documented in the LD manual, but a short > > example would be: > > > > SHISHI_0.0 { > > global: > > shishi*; > > > > local: > > *; > > }; > > Could you please explain what the en

Re: Installing gnulib from git

On Wednesday 01 April 2009 11:17:25 Reuben Thomas wrote: > I just decided to stop using Debian packages, which I have to download from > sid in order to keep up to date in any case, and just do the obvious thing > and get gnulib from git, which I can update whenever I like. > > However, I can't see

Re: Installing gnulib from git

On Wednesday 01 April 2009 15:32:36 Reuben Thomas wrote: > On Wed, 1 Apr 2009, Mike Frysinger wrote: > > the `git clone` is the install. just execute the gnulib-tool script from > > there. > > Right. So I just add the directory to my PATH? Or symlink gnulib-tool into >

Re: malloc(0) problem again

On Sunday 26 April 2009 18:15:52 Bruno Haible wrote: > Ralf Wildenhues wrote: > > AC_FUNC_MALLOC should define malloc to rpl_malloc and > > the code from the malloc module should be used and fix this issue, no? > > My modules don't use AC_FUNC_MALLOC. From a performance perspective, > I see no poin

[PATCH] mktime & nanosleep: make sure SIGALRM is not blocked

time on Linux systems (google for "SIGALRM blocked" for examples). Not sure if the m4 files need to depend on some other signal checks ... Signed-off-by: Mike Frysinger --- m4/mktime.m4|6 +- m4/nanosleep.m4 |6 +- 2 files changed, 10 insertions(+), 2 deletions(-)

Re: [PATCH] mktime & nanosleep: make sure SIGALRM is not blocked

On Monday 18 May 2009 23:38:13 Eric Blake wrote: > According to Mike Frysinger on 5/18/2009 9:11 PM: > > @@ -170,6 +170,10 @@ main () > >/* This test makes some buggy mktime implementations loop. > > Give up after 60 seconds; a mktime slower than that > >

Re: [PATCH] mktime & nanosleep: make sure SIGALRM is not blocked

On Tuesday 19 May 2009 06:22:05 Bruno Haible wrote: > Mike Frysinger wrote: > > Some systems might have SIGALRM blocked when running configure. If that > > is the case, the nanosleep() test will sleep for practically ever as the > > signal generated by alarm() is never de

Re: [PATCH] mktime & nanosleep: make sure SIGALRM is not blocked

On Tuesday 19 May 2009 07:08:37 Bruno Haible wrote: > Mike Frysinger wrote: > > we're of course trying to > > figure out who is blocking the signal in the first place, but it isnt > > exactly a trivial affair when it crops up on some users systems and they > > cant

build failure when system does not provide MB_CUR_MAX

looking through the gnulib source code, i dont see any checks/replacements for when MB_CUR_MAX does not exist (like in a uClibc build where all multibyte related stuff has been disabled). for example, zile falls apart like so: ../../zile-2.3.7/lib/mbrtowc.c: In function ‘rpl_mbrtowc’: ../../zile

Re: build failure when system does not provide MB_CUR_MAX

On Tuesday 26 May 2009 18:40:23 Bruno Haible wrote: > Mike Frysinger wrote: > > i dont see any checks/replacements for when MB_CUR_MAX does not exist > > This is because MB_CUR_MAX is part of ANSI C + amendment 1 (ca. 1995), and > no platforms are known that lack it (see > gnu

Re: build failure when system does not provide MB_CUR_MAX

On Tuesday 26 May 2009 19:13:51 Bruno Haible wrote: > Mike Frysinger wrote: > > it's disabled explicitly because we dont want multibyte sucking up space > > on a system that doesnt need it. there are a few packages (like zile) > > which dont currently have a way

Re: build failure when system does not provide MB_CUR_MAX

On Wednesday 27 May 2009 01:18:26 Simon Josefsson wrote: > Mike Frysinger writes: > > On Tuesday 26 May 2009 19:13:51 Bruno Haible wrote: > >> Mike Frysinger wrote: > >> > it's disabled explicitly because we dont want multibyte sucking up > >> > spac

[PATCH] version-etc: extend for packagers

g/>. GNU coreutils home page: <http://www.gnu.org/software/coreutils/>. General help using GNU software: <http://www.gnu.org/gethelp/>. Signed-off-by: Mike Frysinger --- lib/version-etc.c | 12 m4/version-etc.m4 | 35 +++ modu

Re: [PATCH] version-etc: extend for packagers

On Sunday 31 May 2009 01:52:13 Mike Frysinger wrote: > +# ifndef PACKAGE_PACKAGER_VERSION > +# define PACKAGE_PACKAGER_VERSION "" > +# endif mmm looks like i lost a change between coreutils/gnulib. i think it makes sense for this line to read: > +# define PACKAGE_

[PATCH v2] version-etc: extend for packagers

g/>. GNU coreutils home page: <http://www.gnu.org/software/coreutils/>. General help using GNU software: <http://www.gnu.org/gethelp/>. Signed-off-by: Mike Frysinger --- v2 - incorporate suggestions by Bruno lib/version-etc.c | 13 + m4/version-etc.m4 |

Re: [PATCH] version-etc: extend for packagers

On Sunday 31 May 2009 04:44:17 Bruno Haible wrote: > Mike Frysinger wrote: > > > +# ifndef PACKAGE_PACKAGER_VERSION > > > +# define PACKAGE_PACKAGER_VERSION "" > > > +# endif > > > > i think it makes sense for this line to read: > >

Re: [PATCH v2] version-etc: extend for packagers

On Monday 01 June 2009 06:21:34 Bruno Haible wrote: > Mike Frysinger wrote: > > + *) AC_DEFINE_UNQUOTED(AS_TR_CPP([PACKAGE_$1]), ["$withval"], [$2]) ;; > > We try to avoid unintended m4 expansion of identifiers by using brackets > around arguments where possible: >

Re: [PATCH v2] version-etc: extend for packagers

On Monday 01 June 2009 06:21:34 Bruno Haible wrote: > Mike Frysinger wrote: > > + *) AC_DEFINE_UNQUOTED(AS_TR_CPP([PACKAGE_$1]), ["$withval"], [$2]) ;; > > We try to avoid unintended m4 expansion of identifiers by using brackets > around arguments where possible: >

Re: [PATCH v2] version-etc: extend for packagers

On Monday 01 June 2009 20:04:22 Bruno Haible wrote: > Mike Frysinger wrote: > > actually i just tried this and it didnt work. config.h ended up with: > > /* Packager info for bug reports (URL/e-mail/...) */ > > #undef AS_TR_CPP > > Oops, you're right. Sorry. I

gettime build failure with recent gnulib for mingw systems

i upgraded gnulib in a project recently and started getting failures in gettime.c when building with a mingw32 toolchain the gnulib commit i'm using is dcc2f67b6ffab6e9def088ccbf7627edcda4bbac. newer changes dont appear to be related. here is the build output (/proj/ is a truncated path to make

Re: gettime build failure with recent gnulib for mingw systems

On Friday 19 June 2009 17:47:27 Bruno Haible wrote: > lib/timespec.h includes , which is supposed to define 'struct > timespec'. > > The config.log that you sent contains > SYS_TIME_H_DEFINES_STRUCT_TIMESPEC='0' > TIME_H_DEFINES_STRUCT_TIMESPEC='0' > These two definitions together should ensure

Re: whoa: server-side repo size just shrank by 20x

On Friday 09 October 2009 04:40:46 Jim Meyering wrote: > I noticed that gnulib.git was consuming nearly 700MB, so did this: > > $ du -sh .; git gc; du -sh . > 692M. > Counting objects: 78817, done. > Delta compression using up to 4 threads. > Compressing objects: 100% (1907

Re: glibc segfault on "special" long double values is _ok_!?

On Thursday 07 June 2007, Jan-Benedict Glaw wrote: > On Wed, 2007-06-06 22:44:17 +0100, James Youngman <[EMAIL PROTECTED]> wrote: > > If I read a stream of data (from a file, a network socket, etc.) which > > is supposed to contain valid floating-point data, it is reasonable for > > a program to pr

Re: glibc segfault on "special" long double values is _ok_!?

On Thursday 07 June 2007, Jan-Benedict Glaw wrote: > On Thu, 2007-06-07 12:06:58 -0400, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Thursday 07 June 2007, Jan-Benedict Glaw wrote: > > > On Wed, 2007-06-06 22:44:17 +0100, James Youngman <[EMAIL PROTECTED]> &g

Re: glibc segfault on "special" long double values is _ok_!?

On Thursday 07 June 2007, Jan-Benedict Glaw wrote: > On Thu, 2007-06-07 13:27:49 -0400, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > read what i said again ... the clients are doing write()/read() on the > > double directly, but one side has debugging enabled so it additio

[patch] make acl support optional

forward ported it to current gnulib git. -mike signature.asc Description: This is a digitally signed message part. 2007-07-25 Mike Frysinger <[EMAIL PROTECTED]> * m4/acl.m4 (AC_FUNC_ACL): Wrap all ACL logic in a call to AC_ARG_ENABLE(acl). diff --git a/m4/acl.m4 b/m4/acl.m4 index 6

Re: git and grep

On Monday 17 September 2007, Bruno Haible wrote: > What do you use for recursive grepping? Is "grep -r --exclude=dir=.git" > working fine? there is no way to filter directories with grep directly ... you have to chain find|xargs-grep sort of junk since git only takes up the toplevel with .git it

Re: m4-1.4.10 segfault with x86_64 during ./configure when checking whether printf supports infinite 'long double' arguments

On Thursday 13 December 2007, Eric Blake wrote: > According to Gilles Espinasse on 12/12/2007 3:29 PM: > > Hi Gilles, > > > -- System Information: > > Debian Release: 4.0 > > APT prefers stable > > APT policy: (500, 'stable') > > Architecture: amd64 (x86_64) > > Shell: /bin/sh linked to /bin/b

Re: [patch] make acl support optional

On Wednesday 25 July 2007, Mike Frysinger wrote: > posted this to the coreutils a list sometime ago ... idea is to be able to > disable automatic ACL detection via --disable-acl since this can often > times take the form of an external library rather than part of the system > libc. &

Re: memmem speedup

On Saturday 05 January 2008, Eric Blake wrote: > I've finished my implementation of a Two-Way plus Boyer-Moore hybrid > string search algorithm for the memmmem module. This patch has passed > everything I've thrown at it so far, and it has the nice properties of > avoiding alloca/malloc (hence it

Re: memmem speedup

On Saturday 05 January 2008, Eric Blake wrote: > Mike Frysinger gentoo.org> writes: > > on the topic of integrating it elsewhere ... the comment header states > > that this is part of the GNU C library. > > The original, before my hacks, was a straight copy from glibc; so

Re: [patch] make acl support optional

On Saturday 29 December 2007, Mike Frysinger wrote: > On Wednesday 25 July 2007, Mike Frysinger wrote: > > posted this to the coreutils a list sometime ago ... idea is to be able > > to disable automatic ACL detection via --disable-acl since this can often > > times take th

Re: [patch] make acl support optional

On Monday 07 January 2008, Jim Meyering wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Saturday 29 December 2007, Mike Frysinger wrote: > >> On Wednesday 25 July 2007, Mike Frysinger wrote: > >> > posted this to the coreutils a list sometime ago ...

Re: [patch] make acl support optional

On Tuesday 08 January 2008, Jim Meyering wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > 2008-01-08 Mike Frysinger <[EMAIL PROTECTED]> > > > > * m4/acl.m4 (gl_FUNC_ACL): Wrap all ACL logic in a call to > > AC_ARG_ENABLE(acl). > > >

Re: GNU-style ChangeLog merge driver for Git

On Sunday 10 February 2008, Bruno Haible wrote: > Micah Cowan wrote: > > Are you claiming that people who are capable of fetching the sources > > with "git clone" will be incapable of "git log"? > > Most of them, yes, sure. The "git clone" command is shown in the > homepage

argz.m4: error_t handling wrt argz.h and errno.h

the argz.m4 header checks to see if error_t is defined, but only does so by including the argz.h header. if you try to build on a system that does provide error_t, but not argz.h, the argz replacement module fails to build. on glibc systems, error_t is defined in errno.h. perhaps the gl_FUNC_

Re: argz.m4: error_t handling wrt argz.h and errno.h

On Wednesday 13 February 2008, Ralf Wildenhues wrote: > * Mike Frysinger wrote on Wed, Feb 13, 2008 at 05:38:05AM CET: > > the argz.m4 header checks to see if error_t is defined, but only does so > > by including the argz.h header. if you try to build on a system that > >

Re: argz.m4: error_t handling wrt argz.h and errno.h

On Wednesday 13 February 2008, Ralf Wildenhues wrote: > * Mike Frysinger wrote on Wed, Feb 13, 2008 at 07:26:16PM CET: > > On Wednesday 13 February 2008, Ralf Wildenhues wrote: > > > * Mike Frysinger wrote on Wed, Feb 13, 2008 at 05:38:05AM CET: > > > > the argz.m4 h

touch and utimens troubles on new/old software combinations

a recent gnulib commit (faeb3e6b21...) causes trouble for some packages (such as touch in coreutils) on certain combinations of software. for example, if you're running a recent version of glibc (say 2.7) compiled against recent kernel headers (say 2.6.25) but execute on an older kernel (say 2.

Re: touch and utimens troubles on new/old software combinations

On Monday 02 June 2008, Jim Meyering wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > a recent gnulib commit (faeb3e6b21...) causes trouble for some packages > > (such as touch in coreutils) on certain combinations of software. for > > example, if you're r

Re: touch and utimens troubles on new/old software combinations

On Monday 02 June 2008, Daniel Jacobowitz wrote: > On Mon, Jun 02, 2008 at 01:50:13PM -0600, Bob Proulx wrote: > > Jim Meyering wrote: > > > Mike Frysinger wrote: > > > > for example, if you're running a recent version of glibc (say 2.7) > > > > com

Re: touch and utimens troubles on new/old software combinations

On Monday 02 June 2008, Andreas Schwab wrote: > Mike Frysinger <[EMAIL PROTECTED]> writes: > > also after reading it, i dont think gnu/stubs.h would help in this > > particular case. gnulib would need a runtime test to detect that > > utimensat() is actually not av

Re: touch and utimens troubles on new/old software combinations

On Monday 02 June 2008, Bob Proulx wrote: > Daniel Jacobowitz wrote: > > Bob Proulx wrote: > > > Most common systems only support backward compatibility. I have not > > > heard of a system which supported forward compatibility. > > > > > > In other words, compiling on a platform usually results in

[PATCH] printf-parse: pull in features.h for __GLIBC__

Signed-off-by: Mike Frysinger --- lib/printf-parse.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/lib/printf-parse.h b/lib/printf-parse.h index 67a4a2a..3bd6152 100644 --- a/lib/printf-parse.h +++ b/lib/printf-parse.h @@ -25,6 +25,9 @@ #include "printf-a

[PATCH] argp: fix program_invocation_name detection

The current program_invocation_name symbol detection fails if the argp.h header is missing. So check for the header first before detecting if the symbol exists. Signed-off-by: Mike Frysinger --- m4/argp.m4 | 15 +-- 1 files changed, 13 insertions(+), 2 deletions(-) diff --git a

Re: [PATCH] printf-parse: pull in features.h for __GLIBC__

On Thursday, November 18, 2010 19:40:34 Bruno Haible wrote: > > --- a/lib/printf-parse.h > > +++ b/lib/printf-parse.h > > @@ -25,6 +25,9 @@ > > > > #include "printf-args.h" > > > > +#ifdef HAVE_FEATURES_H > > +# include /* for __GLIBC__ */ > > +#endif > > > > /* Flags */ > > #define FLAG

Re: [PATCH] argp: fix program_invocation_name detection

On Thursday, November 18, 2010 19:52:28 Bruno Haible wrote: > Mike Frysinger wrote: > > The current program_invocation_name symbol detection fails if the argp.h > > header is missing. > > Your patch would make sense if there was a platform with an that > declares prog

Re: [PATCH] argp: fix program_invocation_name detection

On Thursday, November 18, 2010 22:38:18 Bruno Haible wrote: > Mike Frysinger wrote: > > > > The current program_invocation_name symbol detection fails if the > > > > argp.h header is missing. > > > > > > Your patch would make sense if ther

Re: stdint.m4: HAVE_SYS_INTTYPES_H set to "" breaks build

the m4 code also seems to have problems expanding BITSIZEOF_SIZE_T correctly which leads to further errors when using SIZE_MAX -mike signature.asc Description: This is a digitally signed message part.

Re: stdint.m4: HAVE_SYS_INTTYPES_H set to "" breaks build

On Friday, November 19, 2010 11:46:23 Paul Eggert wrote: > On 11/18/2010 10:48 PM, Mike Frysinger wrote: > > this is because m4/stdint.m4 only defines HAVE_SYS_INTTYPES_H when > > gl_cv_header_working_stdint_h is "no" and i my case, it's yes. > > Sorry, I'

Re: stdint.m4: HAVE_SYS_INTTYPES_H set to "" breaks build

On Friday, November 19, 2010 18:36:40 Eric Blake wrote: > On 11/19/2010 04:15 PM, Mike Frysinger wrote: > > On Friday, November 19, 2010 11:46:23 Paul Eggert wrote: > >> On 11/18/2010 10:48 PM, Mike Frysinger wrote: > >>> this is because m4/stdint.m4 only de

Re: stdint.m4: HAVE_SYS_INTTYPES_H set to "" breaks build

On Friday, November 19, 2010 19:36:12 Ralf Wildenhues wrote: > * Mike Frysinger wrote on Sat, Nov 20, 2010 at 01:31:13AM CET: > > that isnt quite the case here. when i do `make clean`, lib/stdint.h does > > get removed. but the `make` still does GEN on stdint.h even after the &g

[PATCH] spawn.h: fix header inclusion for uClibc systems

From: Khem Raj uclibc defines __GLIBC__ but it does not expose struct shed_param as much as glibc and is not needed too per standard. gnulib attempts to use it but we have to account for it because in this case uclibc does not behave like glibc. Signed-off-by: Khem Raj Signed-off-by: Mike

Re: __GLIBC__ and uClibc

On Saturday, November 20, 2010 13:15:48 Bruno Haible wrote: > Mike Frysinger writes: > > uclibc defines __GLIBC__ > > More exactly, uClibc *usually* defines __GLIBC__, but not always. you can say the same exact thing about glibc. uClibc defines it in the same way -- via features

Re: [PATCH] printf-parse: pull in features.h for __GLIBC__

On Saturday, November 20, 2010 17:50:44 Bruno Haible wrote: > Mike Frysinger wrote: > > --- a/lib/printf-parse.h > > +++ b/lib/printf-parse.h > > @@ -25,6 +25,9 @@ > > > > #include "printf-args.h" > > > > +#ifdef HAVE_FEATURE

Re: unistd.h: daemon

On Sunday, November 21, 2010 18:45:26 Bruno Haible wrote: > There's even a package that wraps a shell command 'daemonize' around it: > git://github.com/bmc/daemonize.git the even more standard `setsid` does the same thing minus the fd closure -mike signature.asc Description: This is a digitall

git-version-gen headaches

the current git-version-gen script and its usage in packages such as coreutils is causing me headaches wrt distros. it currently assumes one of two states: - the current tree is a valid git repo belonging to the related project - the current tree is not a git repo (all the way bac

Re: git-version-gen headaches

On Saturday, February 19, 2011 14:49:32 Jim Meyering wrote: > Jim Meyering wrote: > > Mike Frysinger wrote: > >> further, some of the commands used in git-version-gen require write > >> access to the .git repo (i.e. git update-index --refresh), which our > >>

Re: GPLv3 blobs in C

On Wed, Mar 30, 2011 at 5:25 PM, Simon Josefsson wrote: > I put what I believe are the "appropriate parts" of the GPLv3 text into > a .h file, see below.  It occured to me now that this may be useful to > have in gnulib -- other applications may want to be able to output the > same information.  Th

Re: test-version-etc.sh fails when using the --with-packager-... configure options

On Wednesday 18 November 2009 22:43:04 Eric Blake wrote: > According to Mike Frysinger on 11/18/2009 8:12 PM: > > the test-version-etc.sh falls over when configured with: > > --with-packager=Gentoo --with-packager-version='8.1 (p1)' > > > > ! COPYRIGHT Free So

Re: lib/regex_internal.h uses #if _LIBC instead of #if defined (_LIBC)

On Tuesday 29 December 2009 18:05:11 Eric Blake wrote: > Vladimir 'φ-coder/phcoder' Serbinenko gmail.com> writes: > > It's inconsistent with the rest of this file. > > That may be true, but it's not enough to worry about. i dont personally care one way or the other, but trunk gcc has sometimes

Re: source builds vs. RPMs

On Friday, June 04, 2010 05:05:56 Bruno Haible wrote: > Where does the thinking come from that it is bad to have something not > recognized by the package system? because it is bad. i rarely install packages onto my system anymore without a way of tracking them via my PM. if i do, i leverage DI

Re: source builds vs. RPMs

On Saturday, June 05, 2010 07:52:45 Bruno Haible wrote: > Mike Frysinger wrote: > > packages install way too much cruft that changes over versions to sanely > > track without a PM, and `make uninstall` is way too inconsistent and > > "helpful" to even think about

Re: [bug-inetutils] inetutils-1.8: ftp build error

On Sunday, July 25, 2010 14:00:08 Chet Ramey wrote: > On 7/25/10 10:33 AM, Alfred M. Szmidt wrote: > >> This is a known bug, the reason if I recall is that readline > >> exports xmalloc and xrealloc is to allow programs to hook their > >> own version into readline. So the readline main

Re: [bug-inetutils] inetutils-1.8: ftp build error

On Sunday, July 25, 2010 17:18:02 Chet Ramey wrote: > On 7/25/10 2:36 PM, Mike Frysinger wrote: > > why do you need to use those function names ? using a name spaced > > function like rl_malloc or _rl_malloc would keep the same functionality > > without clashing with othe

Re: detecting uses of "%zu"

On Tue, Aug 17, 2010 at 6:41 PM, Bruno Haible wrote: > Eric Blake wrote: >> it still requires auditing code >> and forbidding "%zu" in favor of "%"PRIuSIZE (or whatever other name we >> settle on). > > You could hack GCC, clang, or even xgettext to produce a warning when it > sees a 'z' size modifi

Re: strstr broken on alpha GNU/Linux

On Wednesday, September 08, 2010 16:36:13 Eric Blake wrote: > I received an off-list report of a test-strstr failure on m4 1.4.15: > > Linux xxx 2.6.34-gentoo-r1 #1 SMP Sun Aug 8 17:45:07 MDT 2010 alpha > GNU/Linux > gcc (Gentoo 4.4.3-r2 p1.2) 4.4.3 > > /bin/sh: line 1: 30207 Segmentation fault

glob resource exhaustion [CVE-2010-2632]

i havent seen any mention on glibc or gnulib lists of CVE-2010-2632. the report claims glibc is affected, and since the gnulib/glibc implementations are pretty similar, gnulib would be as well. i dont suppose there is a bug report somewhere i could follow for status on this ? http://securityr

Re: glob resource exhaustion [CVE-2010-2632]

On Wednesday, October 13, 2010 18:38:14 Bruno Haible wrote: > Mike Frysinger wrote: > > i havent seen any mention on glibc or gnulib lists of CVE-2010-2632. the > > report claims glibc is affected, and since the gnulib/glibc > > implementations are pretty similar, gnulib woul

Re: how to do findutils cross-compilation for ARM platform?

On Wednesday 28 December 2011 09:09:08 Eric Blake wrote: > On 12/25/2011 09:43 PM, chunrong lai wrote: > > I tried to build a ARM version of findutils in my ubuntu 10.10 (x86_64) > > with below commands > > ./configure CC=arm-linux-gnueabi-gcc CFLAGS="-g" \ > --build arm-cross-linux-gnueabi --hos

Re: AM_CPPFLAGS best practice

On Thursday 02 February 2012 15:10:11 Eric Blake wrote: > Is there any specific reason that gnulib recommends builddir (generated > files) before srcdir? my gut tends to prefer builddir over srcdir. but that could be due more to poorly managed packages than a "best practices" setup. in cases wh

Re: AM_CPPFLAGS best practice

On Thursday 02 February 2012 15:40:59 Eric Blake wrote: > Yes, hacks like that render the question of stale files moot. But > without resorting to sledge-hammers, can we come to a consensus on which > way things should listed be in a best-practices project? i have my personal opinion, but i'm amb

Re: [j...@gentoo.org: [lftp] [PATCH] Fix building against GNU libc 2.16 (gets undefined)]

On Friday 10 August 2012 00:29:29 Alexander V. Lukyanov wrote: > Please consider this patch for gnulib. it's already been fixed in gnulib. you need to update your gnulib checkout and regenerate your local copy. -mike signature.asc Description: This is a digitally signed message part.

[PATCH] timer-time: fix linking order with pthreads/rt

When statically linking pthreads with rt, the current order is: -lpthread -lrt But when statically linking, the -lpthread will be discarded as it isn't used. It needs to come after the -lrt. * m4/timer_time.m4 (LIB_TIMER_TIME): Swap order of variables. --- m4/timer_time.m4 |2 +- 1

glob() does not set GLOB_MAGCHAR properly when globbing subdirs

i've found (with a pointer from Michał Górny) that using glob("*/") does not set GLOB_MAGCHAR in gl_flags. for example, this code: #include #include #include #include #include #include int main() { glob_t g; int ret; size_t i; /* Create test tree */

[PATCH] fchownat, renameat, unlinkat: update statat dependencies

These module only uses lstatat(), so depend on the statat module which was split out recently from fstatat. * modules/fchownat, modules/unlinkat: Change fstatat to statat. * modules/renameat: Likewise. Also delete fstat. URL: http://bugs.gentoo.org/468790 Reported-by: Mike Frysinger Signed-off

[PATCH] acl: include quote.h

These files use quote(), so include quote.h for it otherwise we fail to build with errors like: copy-acl.c: In function 'copy_acl': copy-acl.c:51:7: error: implicit declaration of function 'quote' [-Werror=implicit-function-declaration] * lib/copy-acl.c: Include quote.h. * lib/set-acl.c: L

Re: license: comma or semicolon?

On 03 Jan 2022 00:26, Bernhard Voelker wrote: > Comparing some of the license headers, I found that some modules are using a > comma or > a semicolon in the 3rd line of the text: > > $ ~/gnulib> GIT_PAGER= git grep -B2 -A1 'either version' -- doc/gpl-3.0.texi > doc/gpl-3.0.texi-This program i

Re: license: comma or semicolon?

On 04 Jan 2022 00:28, Bernhard Voelker wrote: > On 1/3/22 01:17, Mike Frysinger wrote: > > according to gnu.org, it should be a comma. > > https://www.gnu.org/licenses/gpl-3.0.html#howto > > The attached would change it, and shows how the change was done: > > Su

[PATCH] gendocs: update copyright footer year

* doc/gendocs_template: Change 2020 to 2022. --- doc/gendocs_template | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/gendocs_template b/doc/gendocs_template index c8c8fc610010..0415d947be65 100644 --- a/doc/gendocs_template +++ b/doc/gendocs_template @@ -87,7 +87,7 @@ the

helper to bump scriptversion=

is there a helper script that i'm missing to update $scriptversion automatically for me ? -mike signature.asc Description: PGP signature

Re: CentOS 7 and %reldir% not replaced?

On 20 Feb 2022 20:17, Simon Josefsson via Gnulib discussion list wrote: > Hi. I updated gnulib in libidn2, and it fails on CentOS7 like this: > > mv string.h-t string.h > /usr/bin/mkdir -p '%reldir%/sys' > sed -e 1h -e '1s,.*,/* DO NOT EDIT! GENERATED AUTOMATICALLY! */,' -e 1G \ > -e 's|@''

  1   2   >