And another patch to stop gnulib-tool.py from messing with copyright
headers. This patch is just doing the same as this commit did for
gnulib-tool:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f3553bdefc9202e81996c73686e3ca53cd827417
I assume that this commit somehow escaped being adde
Collin Funk wrote:
> These two TODO entries were pretty simple. One of the ChangeLog
> entries listed to a test case Bruno wrote that worked for testing both
> of them.
>
> [collin@debian gnulib]$ gnulib-tool.py --create-testdir --dir=testdir-all
> --single-configure
> module parse-datetime2 depe
Collin Funk wrote:
> And another patch to stop gnulib-tool.py from messing with copyright
> headers. This patch is just doing the same as this commit did for
> gnulib-tool:
>
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f3553bdefc9202e81996c73686e3ca53cd827417
Thanks! The gnu_make tw
Paul Eggert wrote:
> I installed the
> attached patch into coreutils. With it, 'sort -R' continues to use MD5
> but on GNUish platforms 'sort' links libcrypto dynamically only if -R is
> used (Bruno's suggestion). This doesn't significantly affect 'sort -R'
> performance, and reduces the startu
On 27/02/2024 11:15, Bruno Haible wrote:
Paul Eggert wrote:
I installed the
attached patch into coreutils. With it, 'sort -R' continues to use MD5
but on GNUish platforms 'sort' links libcrypto dynamically only if -R is
used (Bruno's suggestion). This doesn't significantly affect 'sort -R'
perfo
Thanks for the patch. I was hoping that we didn't need to worry about
older platforms needing -ldl. Oh well.
The patch causes 'configure' to search for dlopen even when there's no
crypto library. 'configure' could instead use AC_SEARCH_LIBS only if the
AC_LINK_IFELSE fails (or simply put AC_LI
Paul Eggert wrote:
> Thanks for the patch. I was hoping that we didn't need to worry about
> older platforms needing -ldl. Oh well.
Distros with glibc < 2.34 include:
Debian 11
CentOS 8 stream
Fedora 34
openSUSE 15.5
Slackware 15
These are not obsolete, so far.
> The patch causes 'conf
Pádraig Brady wrote:
> > Does this work for all the various names of libcrypto in various distros?
> >
> > Debian 12 libcrypto.so.3
> > Ubuntu 22.04libcrypto.so.1.1 libcrypto.so.3
> > Slackware 15libcrypto.so.1.1
> > openSUSE 15.5 libcrypto.so.1.1
> > CentOS Stream 9 libcrypto.so.3
Here is a patch fixing an issue I've noticed in the output of
configure.ac (and configure) created by gnulib.py.
When running the following command,
gnulib-tool.py --create-testdir --dir test-dir-python dummy
creates a configure.ac like so:
gl_source_base='gllib'
\
m4_ifval(gl_LIBSOURCES_LIS
Collin Funk wrote:
> When running the following command,
>
> gnulib-tool.py --create-testdir --dir test-dir-python dummy
>
> creates a configure.ac like so:
>
> gl_source_base='gllib'
>
> \
> m4_ifval(gl_LIBSOURCES_LIST, [
> m4_syscmd([test ! -d ]m4_defn([gl_LIBSOURCES_DIR])[ ||
> ...
>
[CCing bug-gnulib]
-- Forwarded Message --
Subject: gnulib: isnan: Fix compilation error in C++ mode
Date: Dienstag, 27. Februar 2024, 23:08:47 CET
From: Christian Weisgerber
To: Bruno Haible
Hi,
regarding
isnan: Fix compilation error in C++ mode on macOS 14.4 / Xcode 15.2
Hi Bruno,
On 2/27/24 2:39 PM, Bruno Haible wrote:
> I guess I wasn't very familiar with raw strings when I did this change.
No worries, it was pretty easy to find and fix. I remember a professor
in college telling us to always use them for Python regular
expressions. It seems this is also recomme
Hi,
Christian Weisgerber wrote:
> isnan: Fix compilation error in C++ mode on macOS 14.4 / Xcode 15.2
> https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00121.html
>
> I just came across the same problem on OpenBSD 7.5-beta (clang 16.0.6).
> I guess the defined() check needs to be extende
Collin Funk wrote:
> > I guess I wasn't very familiar with raw strings when I did this change.
>
> No worries, it was pretty easy to find and fix. I remember a professor
> in college telling us to always use them for Python regular
> expressions. It seems this is also recommended by the Python peo
On 2/27/24 3:39 PM, Bruno Haible wrote:
> $ pycodestyle *.py
> ...
> GLEmiter.py:535:26: W605 invalid escape sequence '\.'
> GLEmiter.py:535:35: W605 invalid escape sequence '\.'
> ...
I discovered it that way too. I like using Eglot from Emacs though. If
you are using Emacs 29+ the `eglot' comman
When creating a Makefile for example, the diff between gnulib-tool and
gnulib-tool.py is:
diff --git a/lib/gnulib.mk.in b/lib/gnulib.mk.in
index a718c17c0e8..15d15970051 100644
--- a/lib/gnulib.mk.in
+++ b/lib/gnulib.mk.in
@@ -1,5 +1,5 @@
## DO NOT EDIT! GENERATED AUTOMATICALLY!
-# Copyright (C)
Hi Collin,
> When creating a Makefile for example, the diff between gnulib-tool and
> gnulib-tool.py is:
>
> diff --git a/lib/gnulib.mk.in b/lib/gnulib.mk.in
> index a718c17c0e8..15d15970051 100644
> --- a/lib/gnulib.mk.in
> +++ b/lib/gnulib.mk.in
> @@ -1,5 +1,5 @@
> ## DO NOT EDIT! GENERATED AU
On 2/27/24 6:07 PM, Bruno Haible wrote:
> When I wrote this piece of code (2022-08-05), it was for the --version
> output. I had apparently overlooked that the method GLInfo.copyright
> also gets used in other contexts than for processing the --version
> option.
Ah I see. I probably should have gr
Collin Funk wrote:
> I tried to run --version and got this:
>
> [collin@debian gnulib]$ gnulib-tool.py --version
> Traceback (most recent call last):
> File "/home/collin/.local/src/gnulib/pygnulib/main.py", line 1197, in
>
> main()
> File "/home/collin/.local/src/gnulib/pygnulib/main.py
On 2/27/24 6:26 PM, Bruno Haible wrote:
> git log -n 1 ChangeLog | grep ^Date:
Ah, I see what is happening.
[collin@debian gnulib]$ git log -n 1
commit 431d6a7615245e6b32d95b4b27aab5d3af65ad2b (HEAD -> master, origin/master,
origin/HEAD)
Author: Bruno Haible
AuthorDate: Wed Feb 28 00:33:49
On 2/27/24 6:51 PM, Collin Funk wrote:
> [collin@debian gnulib]$ git log --pretty=medium -n 1 | grep '^Date:'
It seems that the 'git command-name --pretty=medium' existed before
git version 1. I've found the commit that introduced the version I was
using that caused breakage [1]. It seems that my
21 matches
Mail list logo
