On 25 Feb 2022 00:07, Bruno Haible wrote:
> Jeffrey Walton wrote:
> > > So far, I'm not seeing a need. Ncurses is GNU, has regular releases,
> > > and supports most platforms nicely. When a package depends on it, I
> > > just install it.
> >
> > Ncurses has a lot of problems:
> >
> > 1. Governanc
On 25 Feb 2022 14:32, Jeffrey Walton wrote:
> On Fri, Feb 25, 2022 at 2:26 PM Mike Frysinger wrote:
> > On 25 Feb 2022 04:31, Jeffrey Walton wrote:
> > > On Fri, Feb 25, 2022 at 3:58 AM Mike Frysinger wrote:
> > > > On 25 Feb 2022 02:45, Jeffrey Walton wrote:
> >
On 25 Feb 2022 04:31, Jeffrey Walton wrote:
> On Fri, Feb 25, 2022 at 3:58 AM Mike Frysinger wrote:
> > On 25 Feb 2022 02:45, Jeffrey Walton wrote:
> > > On Fri, Feb 25, 2022 at 1:53 AM Mike Frysinger wrote:
> > > > On 25 Feb 2022 00:42, Jeffrey Walton wrote:
> >
On 25 Feb 2022 02:45, Jeffrey Walton wrote:
> On Fri, Feb 25, 2022 at 1:53 AM Mike Frysinger wrote:
> > On 25 Feb 2022 00:42, Jeffrey Walton wrote:
> > > On Thu, Feb 24, 2022 at 6:07 PM Bruno Haible wrote:
> > > > Have you reported it?
> > > > https://inv
On 25 Feb 2022 00:42, Jeffrey Walton wrote:
> On Thu, Feb 24, 2022 at 6:07 PM Bruno Haible wrote:
> > Have you reported it?
> > https://invisible-island.net/ncurses/ncurses.faq.html#report_bugs
>
> Oh yeah, forgot to mention... No public bug tracker. You could have
> looked this up yourself if the
i'm not seeing how any of this feedback translates into "gnulib should fork
ncurses". as Bruno mentioned, ncurses, like gnulib, is a GNU project, so
that alone is pretty brow-raising. but even from a purely technical pov,
ncurses does a _lot_, and i struggle to see why any of it makes sense in
gn
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|@''
is there a helper script that i'm missing to update $scriptversion
automatically for me ?
-mike
signature.asc
Description: PGP signature
* 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
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
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
On 02 Dec 2016 01:40, Bruno Haible wrote:
> Pádraig Brady wrote in
> http://lists.gnu.org/archive/html/bug-gnulib/2016-04/msg00022.html
> and pushed in
> http://lists.gnu.org/archive/html/bug-gnulib/2016-11/msg00116.html:
>
> > Context in
> > http://lists.gnu.org/archive/html/bug-gnulib/2016-03
The mountlist module changes were merged independently since my v1,
but the ptsname module still hasn't been updated.
These two modules use makedev/major/minor but don't have explicit
checks for the functions. Use the existing autoconf macro which
will probe some headers for use and set up some d
On 14 Jun 2016 17:02, Tim Ruehsen wrote:
> On Tuesday 14 June 2016 10:20:59 Mike Frysinger wrote:
> > On 14 Jun 2016 15:21, Tim Ruehsen wrote:
> > > for GNU Wget we don't (explicitely) use libtool, but on some systems
> > > LTLIBICONV is set while LIBICONV is not.
&
On 14 Jun 2016 15:21, Tim Ruehsen wrote:
> for GNU Wget we don't (explicitely) use libtool, but on some systems
> LTLIBICONV is set while LIBICONV is not.
> See http://savannah.gnu.org/bugs/?48193 for details.
>
> But I also remember seeing LIBICONV set and LTLIBICONV unset in the past.
>
> At t
On 16 Apr 2016 13:20, Pádraig Brady wrote:
> On 16/04/16 11:51, Bruno Haible wrote:
> >> These two modules use makedev/major/minor but don't have explicit
> >> checks for the functions. Use the existing autoconf macro which
> >> will probe some headers for use and set up some defines.
> >
> > Does
These two modules use makedev/major/minor but don't have explicit
checks for the functions. Use the existing autoconf macro which
will probe some headers for use and set up some defines.
* lib/mountlist.c [MAJOR_IN_MKDEV]: Include sys/mkdev.h.
[MAJOR_IN_SYSMACROS]: Include sys/sysmacros.h.
* lib/
On 09 Mar 2016 11:18, Pádraig Brady wrote:
> On 08/03/16 02:18, Mike Frysinger wrote:
> > lib/mountlist.c assumes that sys/types.h includes sys/sysmacros.h
> > directly in order to provide makedev(). when it doesn't, things
> > fall apart like:
> > mountlist.c: In
lib/mountlist.c assumes that sys/types.h includes sys/sysmacros.h
directly in order to provide makedev(). when it doesn't, things
fall apart like:
mountlist.c: In function 'read_file_system_list':
mountlist.c:532:26: warning: implicit declaration of function 'makedev'
[-Wimplicit-function-declara
On 14 Jan 2016 00:59, Mathieu Lirzin wrote:
> For C projects, it is really convenient to use Gnulib as a Git submodule
> and let ‘./bootstrap’ do the job. However in the case of GNU packages
> which don't use C, It is a bit overkill to clone a full repository only
> for some maintenance scripts an
From: Jeroen Roovers
On parisc Linux, O_SYNC and O_DSYNC have the same value.
Add a check to the fcntl tests to avoid build errors:
test-fcntl-h.c:115:5: error: duplicate case value
https://bugs.gentoo.org/477680
* tests/test-fcntl-h.c (main): Check O_SYNC is different from O_DSYNC.
---
tests/t
On Tuesday 14 January 2014 13:53:02 Baruch Siach wrote:
> On Tue, Jan 14, 2014 at 05:46:50PM +, Pádraig Brady wrote:
> > I noticed this issue from:
> > http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/73294
> >
> > I've not tested the following on uclibc, but does the attached patch
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
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
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 */
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
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.
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
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
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
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
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
> >>
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
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
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
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
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
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
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
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'
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
>
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:
>
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:
> >
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 |
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_
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
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
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
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
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
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
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
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
> >
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(-)
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
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
>
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
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
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
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
> >> &
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
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
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
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.
>
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
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&
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 117 matches
Mail list logo
