Hi Paul,
> * lib/regex_internal.c (build_wcs_buffer)
> (build_wcs_upper_buffer, re_string_reconstruct)
> (re_string_context_at):
Note: Karl's autoupdate from glibc reverted this change.
Bruno
Dear Tim,
The error you are quoting is triggered by gpl-2.0.texi, which we copied
1:1 from gnulib (and is current). The problem also does not arise on my
system, so I suspect what you discovered could be a bug in gnulib when
the license file is used against some particular (maybe very recent)
texi
Hi,
git-version-gen currently rejects some forms of .tarball-version:
$ cat > .tarball-version
20191011
$ build-aux/git-version-gen .tarball-version; echo
20191011
$ cat > .tarball-version
snapshot
$ build-aux/git-version-gen .tarball-version; echo
build-aux/git-version-gen: WARNING: .tarball-ver
Hi Paul,
> > Has this already been discussed in the Austin Group, or on the glibc list?
>
> Not as far as I know, though I haven't read all those mailing lists. It would
> be
> a good thing to do.
Thanks for the info. Then, on this topic, gnulib will be going ahead.
> I'm not sold on a new ty
On 10/12/19 3:48 AM, Bruno Haible wrote:
Paul, if you understand it, the better.
I am not going to pursue this further, since HP-UX/hppa, while not being
end-of-life yet [1], has very little relevance for GNU.
I looked at the source and don't see how the problem could happen. I lack access
to
On 10/13/19 10:38 AM, Bruno Haible wrote:
The type printf_len_t is meant to allow the user to write code that works with
and without _PRINTF_LARGE.
By "the user" do you mean a user of an improved POSIX API for printf-like
functions, or a user of a Gnulib wrapper around the improved POSIX API?
On 10/13/19 9:01 AM, Christian Grothoff wrote:
I suspect what you discovered could be a bug in gnulib when
the license file is used against some particular (maybe very recent)
texinfo installation/version.
I see the problem on Ubuntu 18.04.3 LTS which has GNU texinfo 6.5 and TeX Live
2017/Debi
Hi Paul,
Probably I didn't explain it well. Let me try again.
> Gnulib may need something like printf_len_t, PRIdPRINTF etc., but I don't
> quite
> see why POSIX and/or the C standard would need them.
The code will consist of two layers:
1) A layer that defines functions.
Example:
ptr
Hi,
On Sun, Oct 13, 2019 at 06:30:47PM +0200, Bruno Haible wrote:
> Hi,
>
> git-version-gen currently rejects some forms of .tarball-version:
>
> $ cat > .tarball-version
> 20191011
> $ build-aux/git-version-gen .tarball-version; echo
> 20191011
> $ cat > .tarball-version
> snapshot
> $ build-au
On 10/13/19 12:50 PM, Bruno Haible wrote:
The C or POSIX standards deal only with layer 1). However, layer 2) is
essential for programs, to make the use of the new APIs easy.
Right, and I see the need for two layers. I'm still not seeing, though, the
exact division between the two layers in th
On 10/13/19 5:20 AM, Bruno Haible wrote:
Karl's autoupdate from glibc reverted this change.
Thanks for mentioning that. I installed the attached to fix it. I do plan to
migrate this back to glibc, but one step at a time.
>From 6cfb4302b3e1da14d706198b693558290e9b00f4 Mon Sep 17 00:00:00 2001
F
Dmitry V. Levin wrote:
> > I need a non-numeric version for continuous publishing of gettext snapshot
> > tarballs, and I want the tarballs to be called gettext-snapshot.tar.gz,
>
> I wonder how users of these tarballs would be able to identify
> snapshots if there is no version information.
They
Hello Bruno,
On 2019-10-13 3:18 p.m., Bruno Haible wrote:
Dmitry V. Levin wrote:
I need a non-numeric version for continuous publishing of gettext snapshot
tarballs, and I want the tarballs to be called gettext-snapshot.tar.gz,
I wonder how users of these tarballs would be able to identify
sn
Hello Assaf,
> >> I wonder how users of these tarballs would be able to identify
> >> snapshots if there is no version information.
> >
> > I find that for CI tarballs a
> > stable URL is the more important feature.
> >
>
> Somewhat related:
>
> If you're posting the tarballs to ftp.gnu.org or
14 matches
Mail list logo
