Re: Testsuite failure in (unprivileged) user namespace

Hi Collin, Collin Funk writes: > Ludovic Courtès writes: > >>> I am only a relatively new user of guix, so I can't speak for which >>> approach would be preferable from their perspective. I CC'ed Ludovic >>> since he implemented the unprivileged g

Re: Testsuite failure in (unprivileged) user namespace

Hi Bruno and all, keinflue writes: >> Instead, how about >> a) if you just ignore the test failures — since you know you are >> running them in a very special environment, or >> b) we can mark these 3 tests as expected test failures if you >> provide an identifier to mark them with

Re: [Manual] Unreadable navigation links and oversize titles

Hi, Thérèse Godefroy skribis: >> Understood. The problem I saw before this change is that the navigation >> links were too prominent and cluttering the page. Reducing the font >> size seemed like one way to address that. >> > Yes, but you can't reduce font size, use a thinner font and use a >

Re: [Manual] Unreadable navigation links and oversize titles

Hi Thérèse, Apologies if the changes had undesirable effects! I’m of course open to changes in the CSS. Thérèse Godefroy skribis: > There are 2 issues: > > 1. Navigation links. > Some people are able to easily see very small print with very low > contrast. I am not, and many people are like me

Re: bug#26441: Gnulib’s ‘test-lock’ fails to complete on machines with >= 32 cores

Hi Bruno, Bruno Haible skribis: >> The ‘test-lock’ test as shipped with gettext-0.19.8.1 fails to complete >> (or hangs?) on machines with 32+ cores, as reported here: >> >> https://bugs.gnu.org/26441 >> >> Does that ring a bell? > > Yes, this is the bug that was investigated in December 201

Re: bug#26441: Gnulib’s ‘test-lock’ fails to complete on machines with >= 32 cores

Hello Gnulib, The ‘test-lock’ test as shipped with gettext-0.19.8.1 fails to complete (or hangs?) on machines with 32+ cores, as reported here: https://bugs.gnu.org/26441 Does that ring a bell? Mathieu Othacehe found that this is fixed by gettext commit 1afbcb06fded2a427b761dd1615b1e48e1e853c

Re: relicensing libunistring to "dual LGPLv3+ or GPLv2"

Hi Bruno, Bruno Haible skribis: > === Paul, Eric, Ludovic, === > > Would you agree to relicense your changes to lib/isnan.c > under 'LGPLv3+ or GPLv2'? > Or possibly even under LGPLv2+? Yes, sure. Ludo’.

Re: ‘mktime’ replacement on glibc systems

Paul Eggert skribis: > On 07/04/2016 09:53 AM, Ludovic Courtès wrote: >> the conditional does not prevent >> mktime-internal’s configure snippet from being run. >> >> Any idea how to address it? > Perhaps your bootstrap script is calling gnulib-tool without th

Re: ‘mktime’ replacement on glibc systems

Hi, Paul Eggert skribis: > On 06/30/2016 10:21 AM, Ludovic Courtès wrote: >> Gnulib’s ‘mktime’ replacement gets used on glibc systems (glibc 2.22 >> here) due to ‘__mktime_internal’ being unavailable, even though >> gl_cv_func_working_mktime=yes on these systems. Is this

‘mktime’ replacement on glibc systems

Hello Paul, Gnulib’s ‘mktime’ replacement gets used on glibc systems (glibc 2.22 here) due to ‘__mktime_internal’ being unavailable, even though gl_cv_func_working_mktime=yes on these systems. Is this intended? Furthermore, lib/mktime.c has this: --8<---cut here---start-

Re: [PATCH] gendocs.sh: Set default TOP_NODE_UP_URL in HTML output.

Ludovic Courtès skribis: > Suggested by Gavin Smith . > Reported by myglc2 in <http://bugs.gnu.org/22651>. > > * build-aux/gendocs.sh (MANUAL_TITLE, PACKAGE, EMAIL) > (commonarg, dirargs, dirs, infoarg, generate_ascii) > (generate_html, generate_info, generate_tex,

[PATCH] gendocs.sh: Fix "dir" link in HTML output

Hello! This patch aims to fix “dir” links in HTML output, as discussed at <https://lists.gnu.org/archive/html/bug-texinfo/2016-05/msg5.html>. If there are no objections, I’d like to commit it within a couple of days. Thanks, Ludo’. Ludovic Courtès (1): gendocs.sh: Set d

[PATCH] gendocs.sh: Set default TOP_NODE_UP_URL in HTML output.

Suggested by Gavin Smith . Reported by myglc2 in . * build-aux/gendocs.sh (MANUAL_TITLE, PACKAGE, EMAIL) (commonarg, dirargs, dirs, infoarg, generate_ascii) (generate_html, generate_info, generate_tex, outdir) (source_extra, split, srcfile, texarg): Move above 'version'

Re: [PATCH 2/2] Port better to Alpine Linux

Paul Eggert skribis: > + Port better to Alpine Linux > + Its diff implementation does not support -c, but does support -U3. Apparently it’s Busybox’s ‘diff’, so not specific to Alpine. Ludo’.

Re: Bug#801825: autogen: non-free file "doc/gendocs_template" (CC-BY-ND-3.0)

Paul Eggert skribis: > Bruce Korb wrote: >> This file comes from gnulib. > > Its copyright notice came from Texinfo and I assume that was from its > original contributor. Ludovic, do you know what's going on with the > copyright notice of doc/gendocs_template? All I know is from Gnulib’s Git hi

Re: ‘unlinkat’ bug in Linux 4.0.2 leads to tar test failure

Pádraig Brady skribis: > On 24/05/15 12:33, Ludovic Courtès wrote: [...] >> unlinkat(4, "foo_file", 0) = 0 >> unlinkat(AT_FDCWD, "foo", AT_REMOVEDIR) = 0 >> unlinkat(5, "bar_file", 0) = 0 >> unlinkat(4,

‘unlinkat’ bug in Linux 4.0.2 leads to tar test failure

(Please keep 20...@debbugs.gnu.org Cc'd.) (Gnulib: please scroll further down for the ‘unlinkat’ issue.) Andy Patterson skribis: > > I suppose this is Guix 0.8.2 on top of another distribution, right? Did > > you install from source or from the binary tarball? Did you enable > > substitutes (i

Re: [PATCH] gendocs.sh: default to a common CSS style sheet for HTML output

l...@gnu.org (Ludovic Courtès) skribis: > From 0a9320dd0f1d0d93d9204768a6cce5198c9ae8a1 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= > Date: Thu, 11 Dec 2014 16:49:21 +0100 > Subject: [PATCH] gendocs.sh: default to a common CSS style sheet for HTML > out

Re: gendocs.sh --tex ARG (patch)

Hi Karl, Karl Berry skribis: > My impression from the last exchange was that Ludo wanted to make all > changes himself. You got the wrong impression. Paul suggested in to mark it as collectively maintained, which is what I di

Re: [PATCH] gendocs.sh: default to a common CSS style sheet for HTML output

Log index 41dd857..c0b4895 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2015-04-01 Ludovic Courtès + + gendocs.sh: default to a common CSS style sheet for HTML output + * build-aux/gendocs.sh (htmlarg): Change default value. + 2015-03-24 Pádraig Brady quotearg-simple-tests: add miss

Re: [PATCH] gendocs.sh: default to a common CSS style sheet for HTML output

Assaf Gordon skribis: > On Mar 31, 2015, at 11:51, Ludovic Courtès wrote: > > <...> >> <http://gnu.org/s/gnulib/manual.css>, and then to update gendocs.sh to >> refer to that by default. >> >> Objections? Suggestions? > > This URL results i

Re: [PATCH] gendocs.sh: default to a common CSS style sheet for HTML output

Reviving this old thread... http://lists.gnu.org/archive/html/bug-gnulib/2014-12/msg00157.html l...@gnu.org (Ludovic Courtès) skribis: > The patch below intends to make on-line manuals prettier by default, and > to make it easier to change their style in the future. > > It assume

Re: gendocs years and urls

k...@freefriends.org (Karl Berry) skribis: > As Paul said, certainly no problem with the patches, but > like I said, aside from the changing the maintainer, the texinfo > url/mailing list references in gendocs.sh need to be changed. I’ve pushed the attached patch to that effect. Thanks, Ludo’.

Re: gendocs years and urls

Paul Eggert skribis: > On 01/02/2015 12:40 PM, Ludovic Courtès wrote: >> (BTW, I’m happy to make >> it ‘all’ instead of me, but I just didn’t want to bother everyone) > > It's actually less bother (for me, at least) if you put 'all' there. > Either way, i

Re: gendocs years and urls

k...@freefriends.org (Karl Berry) skribis: > 0) Since you wanted to take over gendocs, and since (I guess) you wanted > to maintain it in gnulib, do you follow bug-gnulib? I don't see your > address(es), but maybe you read it through gmane or whatever. Yes, I read via Gmane. Ludo’.

Re: gendocs years and urls

-) diff --git a/modules/gendocs b/modules/gendocs index d70449d..40b3380 100644 --- a/modules/gendocs +++ b/modules/gendocs @@ -18,4 +18,4 @@ License: GPLed build tool Maintainer: -Karl Berry +Ludovic Courtès -- 2.1.2 >From dd79179ebaaa344bab27e1990f07e64e2c01ddd6 Mon Sep 17 00:00:00 2001

Re: [PATCH] gendocs: Change maintainer.

k...@freefriends.org (Karl Berry) skribis: > I feel the need to clarify that I did not "suggest" it. My exact words > were "that would be fine". In other words, I was willing for it to > happen, since although I find your proposed CSS changes quite wrong, I > didn't (and don't) want to debate it

[PATCH] gendocs: Change maintainer.

diff --git a/modules/gendocs b/modules/gendocs index d70449d..40b3380 100644 --- a/modules/gendocs +++ b/modules/gendocs @@ -18,4 +18,4 @@ License: GPLed build tool Maintainer: -Karl Berry +Ludovic Courtès -- 2.1.2 signature.asc Description: PGP signature

Re: [PATCH] gendocs.sh: default to a common CSS style sheet for HTML output

k...@freefriends.org (Karl Berry) skribis: > To the best of my knowledge, you can use --html or override MAKEINFO or > probably other things to get whatever css you want into the gendocs.sh > output. Feel free to do that for your own manuals. > > I don't want to change the defaults in any such wh

Re: [PATCH] gendocs.sh: default to a common CSS style sheet for HTML output

rekado skribis: > Ludovic Courtès writes: >> Perhaps also this: >> >> p { text-align: justify; } >> >> But then it looks like spacing around paragraphs would need to be >> slightly increased, WDYT? > > In my experience, paragraph justification oft

Re: [PATCH] gendocs.sh: default to a common CSS style sheet for HTML output

rekado skribis: >>> It assumes that would be copied to >>> as a starting point. >> >> Seems like a good idea to me. >> Projects can override this if they want. >> >> We can merge this after the global css is in place. > > FWIW

[PATCH] gendocs.sh: default to a common CSS style sheet for HTML output

--- ChangeLog| 5 + build-aux/gendocs.sh | 6 +++--- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5fac19d..f5fe7fe 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2014-12-11 Ludovic Courtès + + gendocs.sh: default to a common CSS style

Re: nl_langinfo and localized day/month names

Eli Zaretskii skribis: >> Date: Wed, 11 Jun 2014 18:38:09 +0300 >> From: Eli Zaretskii >> >> > Date: Tue, 10 Jun 2014 21:08:08 +0300 >> > From: Eli Zaretskii >> > >> > Currently, gnulib's nl_langinfo provides on C-locale names for week >> > days and months, thus any program that uses it can o

Re: gnulib-tool dependency list broken?

Eric Blake skribis: > On 03/11/2014 03:58 PM, Ludovic Courtès wrote: >> Hello, >> >> Running gnulib-tool in Guile today shows a weird module list: >> > >> v0.1-92-g546ff82 >> >> $ ~/src/gnulib/gnulib-tool --update >> Module list with in

gnulib-tool dependency list broken?

Hello, Running gnulib-tool in Guile today shows a weird module list: --8<---cut here---start->8--- $ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en

Re: hstrerror for MinGW

Eli Zaretskii skribis: >> From: l...@gnu.org (Ludovic Courtès) >> Cc: Eli Zaretskii , bug-gnulib@gnu.org >> Date: Wed, 26 Feb 2014 22:52:38 +0100 >> >> Simon Josefsson skribis: >> >> > You wrote: >> > >> >> >> This c

Re: hstrerror for MinGW

Simon Josefsson skribis: > You wrote: > >> >> This came up on guile-users while discussing the MinGW build of >> >> Guile, see >> >> >> >> http://lists.gnu.org/archive/html/guile-user/2013-06/msg00028.html >> >> http://lists.gnu.org/archive/html/guile-user/2013-06/msg00039.html >> >> >> >>

Re: hstrerror for MinGW

Eli Zaretskii skribis: > Ping! (more than half a year passed) Indeed, time flies. :-) [...] >> This came up on guile-users while discussing the MinGW build of Guile, >> see >> >> http://lists.gnu.org/archive/html/guile-user/2013-06/msg00028.html >> http://lists.gnu.org/archive/html/guil

Re: [PATCH] savedir: optionally produce ordered directory list

Sergey Poznyakoff skribis: >> FWIW I think it’s very important that tar --sort=name remains the >> default, as it guarantees that archive production is deterministic. > > Actually, the default is not to sort directory entries at all: tar > stores them in the same order as returned by the underlyi

Re: [PATCH] savedir: optionally produce ordered directory list

Hi, Sergey Poznyakoff skribis: > According to [1], using directory lists ordered by inode can speed up > tar archivation by up to 40% on ext[34] filesystems (confirmed by my own > measurements). Please take a look at the attached patch. Is it OK > to apply? FWIW I think it’s very important th

Re: test-fdutimensat failure

Bernhard Voelker skribis: > On 01/11/2014 11:40 AM, Ludovic Courtès wrote: >> An i686-linux-gnu build of Coreutils 8.21 with Guix failed like this >> (see <http://hydra.gnu.org/build/34068/nixlog/1/raw>): >> >> --8<---cut here---s

test-fdutimensat failure

Hi, An i686-linux-gnu build of Coreutils 8.21 with Guix failed like this (see ): --8<---cut here---start->8--- FAIL: test-fdutimensat (exit: 134) == test-lutimens.h:64: assertion fa

Re: [PATCH] use libcrypto routines in gnulib

l...@gnu.org (Ludovic Courtès) skribis: > Pádraig Brady skribis: > >> The speed of md5 and sha* hashes has lagged a bit in gnulib. >> So to address that and to take advantage of the architecture >> specific assembly used in libcrypto, the attached gnulib patch >>

Re: [PATCH] md5, sha1, sha256, sha512: add 'auto', and a way to specify default

Paul Eggert skribis: > I needed something like this for Emacs, and these changes should > affect existing uses so I took the liberty of pushing them. BTW, wouldn’t it be a problem if OpenSSL got linked into Emacs? In general, it’s not advisable to link OpenSSL into GPL’d programs AIUI, so I won

Re: [PATCH] use libcrypto routines in gnulib

Pádraig Brady skribis: > The speed of md5 and sha* hashes has lagged a bit in gnulib. > So to address that and to take advantage of the architecture > specific assembly used in libcrypto, the attached gnulib patch > allows projects to configure --with-openssl to use that if > available or fall ba

Re: There is no returning

Bruce Korb skribis: > On 11/17/13 13:18, Ludovic Courtès wrote: >> What would you think of sticking to the standard and less problematic >> ‘_Noreturn’ identifier in Gnulib? >> >> (I also agree that it’s better for Guile’s public headers to use >> ‘__noreturn

Re: There is no returning

Paul Eggert skribis: > A better solution, if you want to be portable to > MSVC, is to use _Noreturn instead of noreturn. > This is for reasons described in stdnoreturn.in.h. > > '_Noreturn' is a bit ugly; if you don't care about > MSVC, then __attribute__((__noreturn__)) is > a good way to go. N

Re: [PATCH] readline: Support libedit.

Mats Erik Andersson skribis: > I can add, that in the GNU Inetutils project, the module "readline" > is useless precisely of the above reason. Given that Inetutils is unlikely to be used on non-GNU systems, what about supporting just Readline? Thanks, Ludo’.

Re: [PATCH] readline: Support libedit.

Eric Blake skribis: > On 10/16/2013 02:08 PM, Ludovic Courtès wrote: >> Mats Erik Andersson skribis: >> >>> I would like to see the module readline to access also libedit, >>> should libreadline be missing on a particular system. The patch >>> contain

Re: [PATCH] readline: Support libedit.

Mats Erik Andersson skribis: > I would like to see the module readline to access also libedit, > should libreadline be missing on a particular system. The patch > contained here successfully links against libedit on NetBSD and > Debian GNU/kFreeBSD. Likewise, it still behaves correctly with > lib

Re: Relicensing policy & weak copyleft

"Richard W.M. Jones" skribis: > On Thu, Sep 19, 2013 at 02:23:29PM +0200, Ludovic Courtès wrote: >> Hello, >> >> I’m wondering about the asymptotic behavior of the current policy: >> aren’t all modules going to be LGPLv2+ as time tends to +∞? > > Spea

Relicensing policy & weak copyleft

Hello, I’m wondering about the asymptotic behavior of the current policy: aren’t all modules going to be LGPLv2+ as time tends to +∞? This would ironically be the opposite of the official GNU licensing policy. Ludo’.

Re: regexp_exec thread-unsafe

Paul Eggert skribis: > On 05/14/2013 02:21 PM, Ludovic Courtès wrote: > >> How should that be fixed? Shouldn’t __libc_lock_unlock & co. be rebased >> on top of pthread_mutex_t? > > Yes, thanks, that sounds right. I pushed the following patch into gnulib; > could

regexp_exec thread-unsafe

Hello, Guile imports Gnulib ‘regexp’ module, and for some reason it gets compiled even on glibc systems. The problem is that Gnulib’s ‘regex_internal.h’ reads this: #if defined _LIBC # include #else # define __libc_lock_init(NAME) do { } while (0) # define __libc_lock_lock(NAME) do {

Re: ccan

The main focus of Gnulib is portability, which seems to be quite different from that of CCAN. Ludo’.

Re: stat-time.h vs. pthread-win32

Sorry, there was a thinko in the patch I posted: that doesn’t solve anything since the user’s gets included anyway. The root of the problem is that Guile’s ‘configure’ was defining HAVE_STRUCT_TIMESPEC, hence the problem: http://git.sv.gnu.org/cgit/guile.git/commit/?h=stable-2.0&id=7e7c6f6a93

Re: stat-time.h vs. pthread-win32

orted at <http://lists.gnu.org/archive/html/bug-gnulib/2013-03/msg00096.html>. --- ChangeLog |8 lib/time.in.h |6 ++ 2 files changed, 14 insertions(+) diff --git a/ChangeLog b/ChangeLog index 3843c33..61fd612 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +

stat-time.h vs. pthread-win32

Hi, time.in.h reads: --8<---cut here---start->8--- /* Some systems don't define struct timespec (e.g., AIX 4.1, Ultrix 4.3). Or they define it with the wrong member names or define it in (e.g., FreeBSD circa 1997). Stock Mingw does not define it, but th

Re: [PATCH] extensions: port better to MINUX 3, HP-UX, autoheader 2.62

Paul Eggert skribis: > When deciding whether to define _XOPEN_SOURCE, inspect the > preprocessor macro __hpux instead of the more-heavyweight > operation of requiring AC_CANONICAL_HOST. Define _NETBSD_HOST on > MINUX, for MINUX 3. I think you meant “MINIX 3”. :-) Ludo’.

Re: diffutils test failure on nixos/hydra's solaris build

Hi, Paul Eggert skribis: > On 08/28/2012 05:13 AM, Jim Meyering wrote: >> Since that same test passes just fine on a Solaris 10 system >> to which I have access, I'm going to ignore it for now. > > The same test also passes on a Solaris 11 system > that I have access to, so perhaps it's somethin

Re: [PATCH 2/2] canonicalize[-lgpl]: properly handle "guessing" values when cross-building

Thanks, Ludo’.

Re: [PATCH 1/2] canonicalize: make the right guess when cross-compiling to GNU

Bruno Haible skribis: >> canonicalize: make the right guess when cross-compiling to GNU > > By the way, there are many more cross-compilation guesses in gnulib. > If you want to have them support GNU/Hurd, Note that most of the time, libc features are the same on *-gnu and gnu*. > the w

Re: [PATCH 1/2] canonicalize: make the right guess when cross-compiling to GNU

Hi Bruno, Bruno Haible skribis: > Hi Ludo, > >> [case "$host_os" in >> # Guess yes on glibc systems. >> -*-gnu*) gl_cv_func_realpath_works="guessing yes" ;; >> +*gnu*) gl_cv_func_realpath_works="guessing yes" ;; >> # If we don't know, assu

[PATCH 2/2] canonicalize[-lgpl]: properly handle "guessing" values when cross-building

* m4/canonicalize.m4 (gl_FUNC_CANONICALIZE_FILENAME_MODE, gl_CANONICALIZE_LGPL): Check whether $gl_cv_func_realpath_works matches "*yes" instead of just "yes". Regression introduced in commit e0bcf6626cde8dad4bfbdc4045c744f0cd8b9e24. --- ChangeLog |6 ++ m4/canonicalize.m4

[PATCH 1/2] canonicalize: make the right guess when cross-compiling to GNU

hangeLog b/ChangeLog index 94b3a9d..639f157 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2012-07-07 Ludovic Courtès + + canonicalize: make the right guess when cross-compiling to GNU + * m4/canonicalize.m4 (gl_FUNC_REALPATH_WORKS): Match "*gnu*" to + determine whe

fsusage.c fails to build on GNU

Hello, On GNU/Hurd, ‘struct statfs’ is defined in . However, fsusage.c ends up including only , and thus, ‘struct statfs’ and the ‘statfs’ function aren’t defined/declared, leading to: fsusage.c: In function 'get_fs_usage': fsusage.c:222:17: error: storage size of 'fsd' isn't known fsusage

Re: [PATCH] localcharset: Use an absolute path in TESTS_ENVIRONMENT

Hi Bruno, Bruno Haible skribis: > Hello Ludo, > >> This patch allows running unit tests that are in a subdirectory from >> another directory. > > Thanks, makes sense. Applied (with a corrected ChangeLog entry). Thank you! Ludo’.

Re: Accessing the environment's locale encoding settings

Hi, Since adding an implicit setlocale(LC_ALL, "") cannot be done in Guile 2.0 (it would change the default port encoding as a side effect, etc.), I committed something similar to the hack proposed in [0]. Bruno Haible skribis: > If I were you, I would start using the gnulib-tool option --local

[PATCH] localcharset: Use an absolute path in TESTS_ENVIRONMENT

-12-15 Ludovic Courtès(tiny change) + + * modules/localcharset (LOCALCHARSET_TESTS_ENVIRONMENT): Use + $(abs_top_srcdir) instead of $(top_srcdir). + 2011-12-14 Alex Nelson(tiny change) strftime-tests: also test nanoseconds diff --git a/modules/localcharset b/modules/localcharset in

Re: gl_FUNC_FSTATAT doesn’t support cross-compilation

s-compiling, guess yes on all platforms except AIX. > Reported by Ludovic Courtès . Thanks! Coreutils people: would it be possible for you to update the Gnulib submodule? Ludo’.

Re: gl_FUNC_FSTATAT doesn’t support cross-compilation

Hi, Bruno Haible skribis: > + [case "$host_os" in > +linux*) gl_cv_func_fstatat_zero_flag="guessing yes";; > +*) gl_cv_func_fstatat_zero_flag="guessing no";; I’m actually interested in cross-compilation to GNU/Hurd, which doesn’t have the problem I suppose.

gl_FUNC_FSTATAT doesn’t support cross-compilation

Hi, (Adding bug-gnulib + Paul.) ludo-mXXj517/z...@public.gmane.org (Ludovic Courtès) skribis: > Rob Vermaas skribis: > >>> On x86_64-linux, the new build doesn't look healthy: >>> (http://hydra.nixos.org/build/1302194) >>> >>> checking whether fs

Re: gnulib largefile support

Hi Bruno, Bruno Haible skribis: > You are confusing trigger and cause. While a gnulib update *triggered* > a malfunction [1], the *cause* was a guile bug [2], and it was fixed in > guile 2.0 already two years ago [3]. I agree about the cause being a Guile bug. That said, if the change to _FILE

Re: test-readlink failure on GNU/Linux

Hi Bruno, Bruno Haible skribis: > Ludovic Courtès asked: >> > Gnulib has already been relaxed to work around the Linux violation of >> > POSIX, >> >> Are you referring to commit 68483ca35c0dbd347744327b1020b2e4215454f1? > > He was referring to commit d

Re: test-readlink failure on GNU/Linux

Hi Eric, Eric Blake skribis: > On 10/14/2011 04:25 PM, Ludovic Courtès wrote: >> Hello, >> >> ‘test-readlink’ from GNU M4 1.4.16 fails on GNU/Linux with Linux 3.0.4 >> and GNU libc 2.13 with an assertion failure at test-readlink.h:41: >> >> 40: A

test-readlink failure on GNU/Linux

Hello, ‘test-readlink’ from GNU M4 1.4.16 fails on GNU/Linux with Linux 3.0.4 and GNU libc 2.13 with an assertion failure at test-readlink.h:41: 40: ASSERT (func ("", buf, sizeof buf) == -1); 41: ASSERT (errno == ENOENT); It turns out that errno is set to EINVAL instead of ENOENT, which

Re: ‘iconv’ fails to build on NetBSD 5.1

Hi Bruno, Bruno Haible skribis: >> The ‘iconv’ modules fails to build on NetBSD 5.1 (see gcc70 of the GCC >> Compile Farm): > > Can you show the gnulib-tool invocations that you used when builting > the tarball of your package? In particular, which of the modules > 'iconv', 'iconv-h', 'iconv_ope

‘iconv’ fails to build on NetBSD 5.1

Hi, The ‘iconv’ modules fails to build on NetBSD 5.1 (see gcc70 of the GCC Compile Farm): --8<---cut here---start->8--- depbase=`echo iconv.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; /bin/ksh ../libtool --tag=CC--mode=compile gcc -DHAVE_CONFIG_H -I. -I../.

getaddrinfo on MinGW

Hello, The ‘getaddrinfo’ module doesn’t seem to work as advertised ;-) when cross-building for MinGW. >From , a file that includes Gnulib’s fails to build like this: --8<---cut here---start->8--- /bin/sh ../libtool --tag

Re: PATH_MAX and test-stat.h

Hello, k...@freefriends.org (Karl Berry) skribis: > I am aware that conceptually there is no PATH_MAX on Hurd and no > requirement for it to be a smallish constant, but it seems to me that > any real-world system has to define PATH_MAX as a reasonable constant > simply for compatibility with all

Re: unistr use of undefined macros

Hi Eric, Eric Blake writes: > On 12/07/2010 02:24 PM, Ludovic Courtès wrote: >> Hello, >> >> Commit c98cb289 changed #ifdefs in unistr.in.h to #ifs. As a >> side-effect, this prevents compilation of users of this file, such as >> Guile, with ‘-Wundef’: > &

unistr use of undefined macros

Hello, Commit c98cb289 changed #ifdefs in unistr.in.h to #ifs. As a side-effect, this prevents compilation of users of this file, such as Guile, with ‘-Wundef’: --8<---cut here---start->8--- In file included from bytevectors.c:43:0: ../lib/unistr.h:161:5: erro

Re: nproc -> LGPL

Bruno Haible writes: > Glen Lenker wrote: >> > Glen, do you also agree with Ludo's request? >> >> It is fine with me; nproc is quite libraryish. > > OK, I've pushed the license change. Great, thanks! Ludo’.

nproc -> LGPL

Hello! I’d like to use ‘nproc’ in libguile, which is LGPLv3+. Could you change the license accordingly? Thanks, Ludo’.

Re: have-lib: ‘additional_libdir’ set to ‘PREFIX/lib64’

Hi Paolo, Paolo Bonzini writes: > On 09/29/2009 01:11 AM, Ludovic Courtès wrote: >> (Actually, bi-arch support wouldn’t make much sense under Nix’s view of >> the world.) > > Why not? What doesn't make sense is the /lib and /lib64 distinction, > but you could c

Re: have-lib: ‘additional_libdir’ set to ‘PREFIX/lib64’

Hi Bruno, (Reviving a year-old thread...) Bruno Haible writes: > >> When passed ‘--with-PACKAGE-prefix=/p’, ‘AC_LIB_LINKFLAGS_BODY’ >> deduces ‘additional_libdir=/p/lib64’ on x86_64. > > Yes, this is expected on the common bi-arch Linux systems. > >> This doesn’t work on NixOS which doesn’t (qu

Re: TinyCC bugs

Hi Ralf, Ralf Wildenhues writes: > * Ludovic Courtès wrote on Sun, Oct 17, 2010 at 12:16:30AM CEST: >> BTW, TinyCC compiles all the configure tests and Gnulib files in Guile. >> It eventually bails out because Libtool insists on invoking it with >> ‘-rpath’, which it does

Re: TinyCC bugs

Hi, Bruno Haible writes: >> > I can reproduce it like this: >> > >> > stdlib.h >> > #include >> > foo.c --- >> > #include >> > -- >> > $ /arch/x86-linux/gnu-inst-tcc/0.9.25/bi

Re: TinyCC bugs

Hi Bruno, Bruno Haible writes: >> and a bit of sed to point it to the right libc: >> >> >> https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/development/compilers/tinycc/default.nix > > Well, this is still not going to work for me. On Linux bi-arch systems, 64-bit > libraries are found in /

Re: [PATCH] isnan: Add support for TinyCC

Hi Bruno, Bruno Haible writes: > With tcc 0.9.25 on i386-linux-gnu (I can't even build it for x86_64) I also > get other errors (with a testdir of all posix-modules): Actually, it’s 0.9.25 plus a couple of patches adding ‘alloca’ support (!) and a bit of sed to point it to the right libc: h

[PATCH] isnan: Add support for TinyCC

Hello, The patch below adds support for TinyCC. Without it, tcc bails out: isnan.c:132: division by zero in constant Tested with tcc 0.9.25 on x86_64-linux-gnu. Thanks, Ludo’. 2010-10-15 Ludovic Courtès * lib/isnan.c (FUNC): Treat TinyCC (`__TINYC__') like `__SUN

Re: isnan/isinf -> LGPL

Bruno Haible writes: > 2010-09-05 Bruno Haible > > isinf, isnan: Relax license. > * modules/isinf (License): Change from GPL to LGPL, with consent from > Ben Pfaff. > * modules/isnan (License): Likewise. > Requested by Ludovic Courtès. Thanks! Ludo’.

isnan/isinf -> LGPL

Hello, We’d like to use ‘isnan’ and ‘isinf’ in libguile, which is LGPLv3+. Could you make these two modules LGPL? Thanks, Ludo’. pgpFaDhnxjeDm.pgp Description: PGP signature

Re: Error building octave make dist: operator '||' has no right operand

Hi, The problem was fixed in the mean time: http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=21a2a33e06810921f68b66061a255fc07a472502 Thanks, Ludo’.

Re: iswblank failure

Hello! Bruno Haible writes: > 2010-09-02 Bruno Haible > > wctype: Avoid compilation error on IRIX 6.5.30. > * lib/wctype.in.h (iswblank): Declare with a replacement if > REPLACE_ISWBLANK is set. > * m4/wctype_h.m4 (gl_WCTYPE_H): Check also whether iswblank is > d

Re: failure to build due to ignoring fwrite() result

Hi Bruno, FWIW I’d prefer more “neutral” wording, which couldn’t be interpreted as discouraging use of static analysis tools, and at the same time try to discuss trade-offs rather than taste: Bruno Haible writes: > --- doc/standards.texi.orig Wed Sep 1 01:25:45 2010 > +++ doc/standards.texi

Re: stat-time -> LGPLv3+

Hi Jim, Jim Meyering writes: > * modules/stat-time (License): Change from GPL to LGPL, > with consent from all contributors, for use in libguile. Thanks! Ludo’.

Re: stat-time -> LGPLv3+

Hi, James Youngman writes: > On Tue, Jul 27, 2010 at 12:32 AM, Bruno Haible wrote: >> [Adding James to the CC] >> >>> > We’d like to use ‘stat-time’ in libguile, but libguile is LGPLv3+. >>> > Could you make the license change? >>> >>> Or LGPL v2.1+ too. >>> >>> Anyway, CCed the other contribut

stat-time -> LGPLv3+

Hello! We’d like to use ‘stat-time’ in libguile, but libguile is LGPLv3+. Could you make the license change? Thanks, Ludo’. pgpKD10rjyIsW.pgp Description: PGP signature

Re: [bug-libunistring] Avoiding heap allocations in ‘u32_conv_from_encoding’

Hi, >> Can you also comment on this: >> >> > BTW, it’s unclear to me from the manual whether RESULT_LEN above should >> > be the size in bytes or the size in uint32_t. > > It's documented in chapter 2 "Conventions" of the manual [1]. The *LENGTHP > value indicates the string length in units (i.e.

  1   2   3   >