Re: c32width gives incorrect return values in C locale

On Sat, Nov 11, 2023 at 11:54:52PM +0100, Bruno Haible wrote: > > These types are all identical. Therefore you don't even need to cast. > > - char32_t comes from (ISO C 11 or newer). > - ucs4_t comes from GNU libunistring. > - uint32_t comes from . According to your mail https://lists.gnu

Re: c32width gives incorrect return values in C locale

On Wed, Nov 15, 2023 at 12:22:24AM -0800, Paul Eggert wrote: > On 2023-11-13 01:28, Patrice Dumas wrote: > > According to your mail > > https://lists.gnu.org/archive/html/bug-libunistring/2023-11/msg0.html > > > > char32_t is less portable > > That should be

Re: c32width gives incorrect return values in C locale

On Sat, Nov 18, 2023 at 09:10:09PM +, Gavin Smith wrote: > On Wed, Nov 15, 2023 at 09:42:21AM +0100, Patrice Dumas wrote: > > On Wed, Nov 15, 2023 at 12:22:24AM -0800, Paul Eggert wrote: > > > On 2023-11-13 01:28, Patrice Dumas wrote: > > > > Accord

Re: c32width gives incorrect return values in C locale

On Sun, Nov 19, 2023 at 12:26:02AM +0100, Patrice Dumas wrote: > On Sat, Nov 18, 2023 at 09:10:09PM +, Gavin Smith wrote: > > On Wed, Nov 15, 2023 at 09:42:21AM +0100, Patrice Dumas wrote: > > > On Wed, Nov 15, 2023 at 12:22:24AM -0800, Paul Eggert wrote: > > > >

patch for gendoc.sh --no-html fix

Hello, A small patch for a small typo in gendoc.sh for --no-html. -- Pat diff --git a/ChangeLog b/ChangeLog index 65982d7177..da748f4f3d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2024-01-27 Patrice Dumas + + gendocs: fix --no-html + * build-aux/gendocs.sh: fix typo in variable

patch to quote files in source archive setup

git a/ChangeLog b/ChangeLog index da748f4f3d..1c78751c02 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2024-01-27 Patrice Dumas + + gendocs: quote source files in tar call + * build-aux/gendocs.sh: quote $source_extra and re-read the source + files list to quote files. Construct th

Re: patch to quote files in source archive setup

On Sat, Jan 27, 2024 at 04:18:20PM +0100, Bruno Haible wrote: > Hi Patrice, > > > Here is a patch to have the files used in the Texinfo source archive > > quoted in the call to tar. > > The first line of your ChangeLog entry should not only be a summary of > the technical change. But rather, it s

Re: patch to quote files in source archive setup

-- which seems to be an extension, at least it does not seems to be present in solaris tar. -- Pat diff --git a/ChangeLog b/ChangeLog index da748f4f3d..7f40b7c6b9 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2024-01-27 Patrice Dumas + + gendocs: allow spaces, metacharacters and quotes in

Re: patch to quote files in source archive setup

Paul Eggert > + > + gendocs: allow other chars in source file names > + * build-aux/gendocs.sh: Generalize to also allow leading ‘-’ > + and newlines (!) in source file names. Exit if there > + is an error creating the tarball. > + > 2024-01-27 Patrice Dum

fix for source includes in gendoc.sh for future consideration

Hello, Here is a patch for gendocs.sh to be considered in the future. It allows to get the @include of the manual being targetted by gendocs.sh and gather only the manual being targetted. It uses a feature that was just added to the development version of Texinfo, the addition of --trace-include

Re: fix for source includes in gendoc.sh for future consideration

On Sun, Jan 28, 2024 at 03:36:26PM +0100, Bruno Haible wrote: > Hi Patrice, > > Patrice Dumas wrote: > 2. Wait 10 years (or such), until no one uses the older versions > any more. Look at https://repology.org/project/texinfo/versions > to get a feeling when this tim

Re: fix for source includes in gendoc.sh for future consideration

z" \ > --verbatim-files-from -T- -- "$base" $pats \ > ${source_extra+"$source_extra"} \ > && ls -l "$abs_outdir/$PACKAGE.texi.tar.gz" Ok. -- Pat diff --git a/ChangeLog b/ChangeLog index 58fd6e5d4c..6a40954843 100644 --- a/ChangeL

Use of the m4 macros and standard package

Hi, I think that the gnulib manual isn't very clear about the use of the macros provided by gnulib-tool. My understanding, after reading the macros is that whenever gl_EARLY and gl_INIT are used there is no need to explicitely call macros like AC_FUNC_ALLOCA nor to use the specific gnulib macro,

strftime LGPL depends on GPL modules

Hi, strftime which may be LGPL depends on tzset which dependes on gettimeofday and both are GPL. Maybe it would be better to flag strftime as GPL or distribute tzset and gettimeofday as LGPL. -- Pat ___ bug-gnulib mailing list bug-gnulib@gnu.org http

lgpl compatible files archive?

Hi, I am currently packaging a library under the LGPL, so I cannot use the files of the gnulib that are under the GPL. Is there somewhere a project similar with the gnulib but with files with LGPL compatible licences? -- Pat ___ bug-gnulib mailing lis

Re: lgpl compatible files archive?

> Note that many of the gnulib source files say "GPL" on them, but can > also be distributed under the terms of the LGPL; gnulib-tool will > autoconvert their copyright notice when you import them. Please see > the modules/* files for the license for each module. Yes, I saw that, and used the com

Re: lgpl compatible files archive?

> projects. I still think either a Lesser GNULib project is needed, or > that gnulib modules could become parametrized, or that gnulib could > contain multiple implementations of the same interface (with different > characteristics, license-wise, thread-safety, malloc use, etc...). It seems to me

Re: Use of the m4 macros and standard package

> Sure, it is not standard, but that's not just capriciousness or > laziness: the whole idea of gnulib is to share files *at the source > level*. If people are not comfortable with cvs checkouts (and autoconf > and ...), they shouldn't be using it. Indeed, but having gnulib only in the cvs form h

Re: Use of the m4 macros and standard package

> No, let's not imagine that. (You should be simplifying your life! :-) ;-) > This arranges to grab the latest gnulib from CVS. > > Perhaps all we need to do is to package a bootstrap script. That is an interesting solution, this is the kind of solution I depicted with shell scripts and netwo

Re: lgpl compatible files archive?

> OK, I installed the following change. > > I noticed that some modules are actually public domain, so I put that > info into each module file. This patch also adds (untested) support > for a new license 'public domain' to gnulib-tool's --lgpl option. Thanks ! -- Pat _

no rpl_mktime in mktime.c

Hi, There is no rpl_mktime defined in mktime.c, although in gl_FUNC_MKTIME there is AC_DEFUN([gl_FUNC_MKTIME], [ AC_REQUIRE([AC_FUNC_MKTIME]) if test $ac_cv_func_working_mktime = no; then AC_DEFINE(mktime, rpl_mktime, [Define to rpl_mktime if the replacement function should be used.

Re: no rpl_mktime in mktime.c

> > There is no rpl_mktime defined in mktime.c, although in gl_FUNC_MKTIME > > AC_DEFINE(mktime, rpl_mktime, > > Doesn't this cause the 'mktime' in mktime.c to be replaced by 'rpl_mktime'? > Similarly for strtod. Yes, but if in the standard headers something odd is done with the mktime symb

Re: no rpl_mktime in mktime.c

> No, those functions are never called with rpl_ prepended. Instead, > the usual pattern is something like this: > > In config.h: > > #define malloc rpl_malloc > > In malloc.c: > > #include > #undef malloc > void *rpl_malloc (size_t n) { ... malloc (n) ... } > > This way, only config.h and m

Re: no rpl_mktime in mktime.c

> Unlike some of the other modules, lib/mktime.c is not a wrapper around > the system mktime. It is a complete reimplementation, so there's no > need for an "#undef mktime" or a "rpl_mktime" in lib/mktime.c itself. So maybe there shouldn't be AC_DEFINE(mktime, rpl_mktime, in gl_FUNC_MKTIME in m4

mktime.m4 needs to be updated

Hi, The AC_FUNC_MKTIME in gnulib m4/mktime.m4 isn't in sync with the one in autoconf so it doesn't add -lm for pow, leading to a spurious link error. -- Pat ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnul

Re: mktime.m4 needs to be updated

> The AC_FUNC_MKTIME in > > doesn't mention pow. Perhaps you could be more specific about the > problem? I'm sorry, in fact there is no problem, I think I mixed up mktime and strtod, my bad..

gnulib manual patch

Hi, Here is a patch for the gnulib texi manual explaining some things I would have liked to see in the manual. -- Pat Index: gnulib.texi === RCS file: /cvsroot/gnulib/gnulib/doc/gnulib.texi,v retrieving revision 1.10 diff -u -3 -p

Re: no rpl_mktime in mktime.c

> This problem has been fixed for localtime_r in a different way, and we > could use the same method to fix it for mktime_r. That is, we could > change the role of time_r.h to mean "act like time.h, but replace > functions that need to get fixed", and then have it "#define mktime > rpl_mktime". W

Re: Web manual out-dated?

On Fri, Nov 21, 2008 at 03:25:08AM +0100, Bruno Haible wrote: > Hello Karl, > > What's the reason for mapping the node named 'index' to the file named > 'index.html'? It could also be 'inde_0078.html', no? This would leave > the name 'index.html' for the entry point into the manual. This allows t

Re: Difficulties in using getdate.texi from Texinfo documents which use full @node commands

On Mon, Apr 09, 2007 at 06:55:50PM -0500, Karl Berry wrote: > removing the prev/next/up pointers from all other chapters and > top-level nodes in the findutils manual > > Just to chime, I too say to remove 'em, from findutils and everywhere > else. Down with node pointers! > > eliz>

Re: gendocs.sh and texi2html

On Fri, May 04, 2007 at 11:35:44AM +0200, Bruno Haible wrote: > > Some hacks are needed for being able to process a .texi file with both > "texi2html" and "makeinfo --html": > > - The "Top" node must be included for "makeinfo --html" but it's pointless > in texi2html runs. Since the conditi

Re: gendocs.sh and texi2html

On Sun, May 06, 2007 at 01:48:12AM +0200, Bruno Haible wrote: > > In the manual I maintain, the "Top" node contains only redundant information: > a brief sentence what the manual documents (duplicates the manual's headline), > and a big @[EMAIL PROTECTED] menu (ignored anyway since I use --no-menu

Re: gplv3 files and updates

On Tue, Jul 03, 2007 at 01:22:05PM -0700, Paul Eggert wrote: > Bruno Haible <[EMAIL PROTECTED]> writes: > > > The sequence of events that I'm hoping for is this: > > - First, get agreement that all projects that use gnulib are OK with > > GPLv3. > > I don't hear any objection, so let's assume

Re: gplv3 files and updates

On Thu, Jul 05, 2007 at 04:38:13PM -0500, Karl Berry wrote: > OPeNDAP libdap http://scm.opendap.org:8090/svn/trunk/ > > I wrote these two. The Net::CDP author already replied saying he is > willing to relicense libcdp under GPLv3. No word from the OPeNDAP > people. OPeNDAP is under the L

Re: gplv3 files and updates

On Thu, Jul 05, 2007 at 05:04:43PM -0500, Karl Berry wrote: > OPeNDAP is under the LGPL, not GPL. > > Right, but the same issue arises. > > And if I remember well it is under LGPL 2 or above. > > I could not find any obvious statement. The source files I looked at > didn't have any cop

copy-file without preserving the owner

Hello, For some code in Texinfo (not public yet), I needed to copy a file. I used the copy-file Gnulib module code, but I did not want to preserve the owner and group as it is better in my case if the file owner is the same as the generated output files owner. So I modified the code not to keep

Re: copy-file without preserving the owner

On Fri, Aug 23, 2024 at 11:56:06PM +0200, Bruno Haible wrote: > Hi Patrice, > > > For some code in Texinfo (not public yet), I needed to copy a file. I > > used the copy-file Gnulib module code, but I did not want to preserve > > the owner and group as it is better in my case if the file owner is