Re: Indentation mistake

[Simon Josefsson via Gnulib discussion list]

Collin Funk  writes:

> Hi Simon,
>
> On 5/2/24 11:25 AM, Simon Josefsson via Bug reports for the GNU Internet 
> utilities wrote:
>>> Sadly, I cannot do this, at least not easily.  After installing GNU
>>> indent, "make syntax-check" complains about many files:
>>>
>>> $ indent --version
>>> GNU indent 2.2.12
>> You need 2.2.13 :-)
>
> I see that you added the 'syntax-check' for indent in Gnulib. One
> minor problem though, it breaks if the user has an ~/.indent.pro. :)
>
> I don't use indent much, so I forgot my repository where I store
> dotfiles installs this:
>
> $ cat ~/.indent.pro 
> --gnu-style
> --no-tabs
>
> Here lets check if the code is indented:
>
> $ make sc_indent | wc -l
> maint.mk: code format error, try "make indent"
> make: *** [maint.mk:1760: sc_indent] Error 1
> 52751
>
> I was confused for a bit until I saw that file.
>
>$ rm ~/.indent.pro
>$ make sc_indent | wc -l
>1
>
> Indent has -npro that you can use to ignore the file which might be
> good.

Nice catch.  It doesn't make sense for maint.mk's indentation to be
influenced by ~/.indent.pro -- the style has to be a per-project
setting.  I pushed the patch below.

/Simon
From 6213c5bd72d15ca5e1ea9c34122899e02fed448c Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Fri, 3 May 2024 08:44:03 +0200
Subject: [PATCH] maint.mk: Don't fail on ~/.indent.pro, reported by Collin
 Funk.

* top/maint.mk (indent_args): Use --ignore-profile.
---
 ChangeLog| 5 +
 top/maint.mk | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index d967c8cfac..2781a70800 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2024-05-03  Simon Josefsson  
+
+	maint.mk: Don't fail on ~/.indent.pro, reported by Collin Funk.
+	* top/maint.mk (indent_args): Use --ignore-profile.
+
 2024-05-02  Collin Funk  
 
 	gnulib-tool.sh: Fix program name in error message.
diff --git a/top/maint.mk b/top/maint.mk
index c30e71ba6e..af865717c4 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -1746,7 +1746,7 @@ refresh-po:
 
 # Indentation
 
-indent_args ?= -ppi 1
+indent_args ?= --ignore-profile --preprocessor-indentation 1
 C_SOURCES ?= $$($(VC_LIST_EXCEPT) | grep '\.[ch]\(.in\)\?$$')
 INDENT_SOURCES ?= $(C_SOURCES)
 exclude_file_name_regexp--indent ?= $(exclude_file_name_regexp--sc_indent)
-- 
2.34.1



signature.asc
Description: PGP signature

gnulib-tool.sh: Fix program name in error message.

[Collin Funk]

When running 'gnulib-tool' with the mode --update and extra arguments:

$ env GNULIB_TOOL_IMPL=sh gnulib-tool --update --vc-files
gnulib-tool: invalid options for 'update' mode
Try 'gnulib-tool --help' for more information.
If you really want to modify the gnulib configuration of your project,
you need to use 'gnulib --import' - at your own risk!

I've attached a patch correcting the program name in this line:

you need to use 'gnulib --import' - at your own risk!

The program name should be 'gnulib-tool'.

In main() of the Python version uses a mix of APP['name'] and
hard-coded 'gnulib-tool' which is a bit strange. In this example it
uses APP['name'].

/home/collin/.local/src/gnulib/gnulib-tool.py: *** invalid options for --update 
mode
Try 'gnulib-tool --help' for more information.
/home/collin/.local/src/gnulib/gnulib-tool.py: *** Stop.

In this case the error message is incorrect, probably just out of
date. But I would also prefer just hard-code 'gnulib-tool' as the
program name.

Any objections? I think it is fine since the program name hasn't
changed in 20 years.

CollinFrom cae0e724baff3438dea796f5f7ff7bd17e04a9d8 Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Thu, 2 May 2024 16:57:13 -0700
Subject: [PATCH] gnulib-tool.sh: Fix program name in error message.

* gnulib-tool.sh: Use 'gnulib-tool' instead of 'gnulib' as the program
name in the error message.
---
 ChangeLog  | 6 ++
 gnulib-tool.sh | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index d59f8d5c7e..d967c8cfac 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-05-02  Collin Funk  
+
+	gnulib-tool.sh: Fix program name in error message.
+	* gnulib-tool.sh: Use 'gnulib-tool' instead of 'gnulib' as the program
+	name in the error message.
+
 2024-05-02  Collin Funk  
 
 	DEPENDENCIES: Add Cygwin as supported platform.
diff --git a/gnulib-tool.sh b/gnulib-tool.sh
index b486e99b1e..521d16e47a 100755
--- a/gnulib-tool.sh
+++ b/gnulib-tool.sh
@@ -1584,7 +1584,7 @@ func_determine_path_separator
   echo "gnulib-tool: invalid options for 'update' mode" 1>&2
   echo "Try 'gnulib-tool --help' for more information." 1>&2
   echo "If you really want to modify the gnulib configuration of your project," 1>&2
-  echo "you need to use 'gnulib --import' - at your own risk!" 1>&2
+  echo "you need to use 'gnulib-tool --import' - at your own risk!" 1>&2
   func_exit 1
 fi
   fi
-- 
2.44.0

Re: Problem with boot-time on Cygwin

[Bruno Haible]

Hi Ken,

> $ ls -l /proc/cygdrive/c/pagefile.sys/
> ls: cannot open directory '/proc/cygdrive/c/pagefile.sys/': Not a directory
> 
> $ ls -ld /proc/cygdrive/c/pagefile.sys/
> drwxr-x--- 17664 Unknown+User Unknown+Group 0 1600-12-31 19:11 
> /proc/cygdrive/c/pagefile.sys//
> 
> Notice that the file is reported as a directory when 'ls -ld' is used, 
> and it has a timestamp way in the past.

This seems to be a fairly recent change in Cygwin.

> I wonder if 
> get_boot_time should simply bail out on Cygwin and always give a boot 
> time of 0.  Or do you have a better idea?

I've forwarded the question to the cygwin mailing list [1].
Let's see what they say.

Bruno

[1] https://cygwin.com/pipermail/cygwin/2024-May/255931.html

Re: Problem with boot-time on Cygwin

[Ken Brown]

Hi Bruno,

Unfortunately, fixing the cygdrive bug has made things worse from the 
point of view of emacs, at least on my system.  Namely, I can't even 
build emacs.  The build produces warnings like the following and 
ultimately fails:


Warning (unlock-file): Unlocking file: Invalid argument, 
/home/kbrown/src/emacs/lock/lisp/font-lock.elch7bJkt, ignored


This is similar to what Katsumi reported in the emacs bug report I cited 
at the beginning of this thread.


I decided to investigate /proc/cygdrive/c/pagefile.sys in a Cygwin shell 
and got the following weird results:


$ ls -l /proc/cygdrive/c/pagefile.sys/
ls: cannot open directory '/proc/cygdrive/c/pagefile.sys/': Not a directory

$ ls -ld /proc/cygdrive/c/pagefile.sys/
drwxr-x--- 17664 Unknown+User Unknown+Group 0 1600-12-31 19:11 
/proc/cygdrive/c/pagefile.sys//


Notice that the file is reported as a directory when 'ls -ld' is used, 
and it has a timestamp way in the past.


I don't know what's going on, but it seems clear that pagefile.sys can't 
be used reliably on Cygwin to get a boot time.  I wonder if 
get_boot_time should simply bail out on Cygwin and always give a boot 
time of 0.  Or do you have a better idea?


Ken

Re: Adding Cygwin and MSYS2 to DEPENDENCIES

[Collin Funk]

On 5/2/24 3:50 PM, Bruno Haible wrote:
>> Would the following be correct?
>>
>>   command = ['sh', '-c', f'patch {shlex.quote(test_driver)} < 
>> {shlex.quote(diff)}']
>>   try:
>>  result = sp.call(command, stdout=sp.DEVNULL, stderr=sp.DEVNULL)
>>   except OSError as exc:
>>  ...
> 
> Yes, this looks correct. But it needs to be conditionalized, so that we 
> continue
> to keep the simpler (and often also faster) code on Unix.

Yeah, off the top of my head it doesn't seem like it would be too
difficult to do something like:

 def execute_script(command: str) -> None:
 # Check platform, avoid shell=True if possible.

but I haven't put too much thought into it yet.

Thanks for the help!

Collin

Re: Adding Cygwin and MSYS2 to DEPENDENCIES

[Bruno Haible]

Collin Funk wrote:
> Ah, good point. I didn't realize it was possible to use a native
> Windows Python3 (os.name == 'nt') with Cygwin tools.

It appears that's what the original reporter is doing [1]: you see
file names with backslashes and you see Windows error codes being
reported, rather than POSIX error codes.

> What would be the proper way to invoke 'sh' there? For example this
> command in GLTestDir.py:
> 
> command = f'patch {shlex.quote(test_driver)} < {shlex.quote(diff)}'
> try:
> result = sp.call(command, shell=True, stdout=sp.DEVNULL, 
> stderr=sp.DEVNULL)
> except OSError as exc:
> ...
> 
> Would the following be correct?
> 
>   command = ['sh', '-c', f'patch {shlex.quote(test_driver)} < 
> {shlex.quote(diff)}']
>   try:
>  result = sp.call(command, stdout=sp.DEVNULL, stderr=sp.DEVNULL)
>   except OSError as exc:
>  ...

Yes, this looks correct. But it needs to be conditionalized, so that we continue
to keep the simpler (and often also faster) code on Unix.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00543.html

Re: Adding Cygwin and MSYS2 to DEPENDENCIES

[Collin Funk]

On 5/2/24 3:28 PM, Bruno Haible wrote:
>> Can I apply the attached patched?
> 
> Yes, now it is OK to push.

Done.

>> Also, last night when fixing the quoting issue I was thinking if
>> gnulib-tool.py should quit on unsupported platforms (native Windows).
> 
> Yes, this is reasonable, since we already determined that our
> unsupported platforms are unsupported for a good reason: no adequate
> support for running shell scripts, autoconf, automake.
> 
> However, you need to define "native Windows" here.
>   - A Cygwin (or MSYS2) installation combined with a Cygwin-built Python
> will work, even without modifications in the subprocess.* calls.
>   - A Cygwin (or MSYS2) installation combined with a native Python
> will need modifications in the subprocess.* calls, namely to insert a
> first argument "sh" in many places. (I wouldn't use shell=True in
> this case, unless we can guarantee that it will call "sh", not "cmd".)
> Maybe it will also need other modifications, I don't know. Hopefully
> not.

Ah, good point. I didn't realize it was possible to use a native
Windows Python3 (os.name == 'nt') with Cygwin tools.

What would be the proper way to invoke 'sh' there? For example this
command in GLTestDir.py:

command = f'patch {shlex.quote(test_driver)} < {shlex.quote(diff)}'
try:
result = sp.call(command, shell=True, stdout=sp.DEVNULL, 
stderr=sp.DEVNULL)
except OSError as exc:
...

Would the following be correct?

  command = ['sh', '-c', f'patch {shlex.quote(test_driver)} < 
{shlex.quote(diff)}']
  try:
 result = sp.call(command, stdout=sp.DEVNULL, stderr=sp.DEVNULL)
  except OSError as exc:
 ...

In that case the patch command will be $0 and will be quoted correctly
for when sh is invoked if I am not mistaken.

Collin

Re: Adding Cygwin and MSYS2 to DEPENDENCIES

[Bruno Haible]

Hi Collin,

> Can I apply the attached patched?

Yes, now it is OK to push.

> Also, last night when fixing the quoting issue I was thinking if
> gnulib-tool.py should quit on unsupported platforms (native Windows).

Yes, this is reasonable, since we already determined that our
unsupported platforms are unsupported for a good reason: no adequate
support for running shell scripts, autoconf, automake.

However, you need to define "native Windows" here.
  - A Cygwin (or MSYS2) installation combined with a Cygwin-built Python
will work, even without modifications in the subprocess.* calls.
  - A Cygwin (or MSYS2) installation combined with a native Python
will need modifications in the subprocess.* calls, namely to insert a
first argument "sh" in many places. (I wouldn't use shell=True in
this case, unless we can guarantee that it will call "sh", not "cmd".)
Maybe it will also need other modifications, I don't know. Hopefully
not.

> On Cygwin and MSYS2 'os.name' seems to be 'posix' [1]. Should we check
> that before running?

os.name == 'nt' would also be valid, if "sh" can be found.

Bruno

Re: Adding Cygwin and MSYS2 to DEPENDENCIES

[Collin Funk]

Hi Bruno,

On 5/2/24 2:29 AM, Bruno Haible wrote:
> I would additionally format it as a subsection, so that it clearly stands
> out from the rest:

Can I apply the attached patched?

Also, last night when fixing the quoting issue I was thinking if
gnulib-tool.py should quit on unsupported platforms (native Windows).

On Cygwin and MSYS2 'os.name' seems to be 'posix' [1]. Should we check
that before running?

I'm not sure how the Windows cmd.exe and powershell stuff works. I
assume it would be nicer to fail upfront than run the risk of
executing invalid shell commands (or valid ones that break things).

[1] https://docs.python.org/3/library/os.html#os.name

CollinFrom 0f6c664fa65ba617923e198dc63c30a4fbbf2d2c Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Thu, 2 May 2024 14:22:14 -0700
Subject: [PATCH] DEPENDENCIES: Add Cygwin as supported platform.

* DEPENDENCIES: Mention Cygwin as a supported platform for building
Windows binaries.
---
 ChangeLog|  6 ++
 DEPENDENCIES | 17 +
 2 files changed, 23 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 8192b43aa7..d59f8d5c7e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-05-02  Collin Funk  
+
+	DEPENDENCIES: Add Cygwin as supported platform.
+	* DEPENDENCIES: Mention Cygwin as a supported platform for building
+	Windows binaries.
+
 2024-05-02  Bruno Haible  
 
 	doc: Add appendix about Gnulib history.
diff --git a/DEPENDENCIES b/DEPENDENCIES
index b700c05bc6..893daef0a7 100644
--- a/DEPENDENCIES
+++ b/DEPENDENCIES
@@ -197,3 +197,20 @@ at any time.
 https://www.gnu.org/software/tar/
   + Download:
 https://ftp.gnu.org/gnu/tar/
+
+
+Prerequisites needed on specific platforms
+==
+
+Prerequisites on Windows
+
+
+* Cygwin
+  + Required.
+Provides a POSIX-like environment and binary packages necessary to
+build and run software. Native Windows binaries can be built with
+a packaged mingw tool chain. This method is preferred over MSYS2.
+  + Homepage:
+https://cygwin.com/
+  + Download:
+https://cygwin.com/install.html
-- 
2.44.0

Re: Problem with boot-time on Cygwin

[Bruno Haible]

Ken Brown wrote:
> I don't know anything about Docker containers or jails, but it's my 
> understanding that /proc/cygdrive always exists.

Thanks for the confirmation.

Bruno

Re: Problem with boot-time on Cygwin

[Ken Brown]

Hi Bruno,

On 5/1/2024 6:52 PM, Bruno Haible wrote:

I did not know about /proc/cygdrive; thanks for teaching us. I guess it can be
assumed that /proc/cygdrive exists, because unlike in Linux, there are no
Docker containers and unlike in FreeBSD, there are no jails?


I don't know anything about Docker containers or jails, but it's my 
understanding that /proc/cygdrive always exists.



I'm committing this patch:


2024-05-01  Bruno Haible  

readutmp, boot-time: Improve for some Cygwin installations.
Reported by Ken Brown  in
.
* lib/boot-time-aux.h (get_windows_boot_time): Use /proc/cygdrive/
instead of /cygdrive/.

diff --git a/lib/boot-time-aux.h b/lib/boot-time-aux.h
index 8b966fe691..a94cdb3f30 100644
--- a/lib/boot-time-aux.h
+++ b/lib/boot-time-aux.h
@@ -306,7 +306,8 @@ get_windows_boot_time (struct timespec *p_boot_time)
   process, namely C:\pagefile.sys.  */
const char * const boot_touched_file =
  #if defined __CYGWIN__ && !defined _WIN32
-"/cygdrive/c/pagefile.sys"
+/* It is more portable to use /proc/cygdrive/c than /cygdrive/c.  */
+"/proc/cygdrive/c/pagefile.sys"
  #else
  "C:\\pagefile.sys"
  #endif


Thanks.

Ken

doc: Add appendix about Gnulib history

[Bruno Haible]

Paul and Jim, feel free to correct this where I'm wrong...


2024-05-02  Bruno Haible  

doc: Add appendix about Gnulib history.
* doc/gnulib-history.texi: New file.
* doc/gnulib.texi: Include it.

diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index aa0eb57f62..55cf6ebcc9 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -89,6 +89,7 @@
 * Build Infrastructure Files::  Non-modules files for the build system.
 * Release Management Files::Non-modules files for preparing releases.
 * GNU Free Documentation License::  Copying and sharing this manual.
+* Gnulib history::
 * Index::
 @end menu
 
@@ -7364,6 +7365,12 @@
 @include fdl-1.3.texi
 
 
+@node Gnulib history
+@appendix Gnulib history
+
+@include gnulib-history.texi
+
+
 @node Index
 @unnumbered Index
 
=== doc/gnulib-history.texi ===
@c Gnulib history

@c Copyright 2024 Free Software Foundation, Inc.

@c Permission is granted to copy, distribute and/or modify this document
@c under the terms of the GNU Free Documentation License, Version 1.3 or
@c any later version published by the Free Software Foundation; with no
@c Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.  A
@c copy of the license is at .

In the beginning, Richard Stallman maintained the regular expression engine
of GNU and made it available to other GNU packages, such as
@code{sed}, @code{awk}, @code{grep}, so that they could use the same engine.
Recall that there was no GNU C library at the time.

A couple of years later, Jim Meyering, who was maintaining
the shell utilities, the file utilities, and the text processing utilities,
collected the common parts of these three packages in the same repository.
Paul Eggert joined in, with code coming from a few GNU packages that he
maintained,
and so did Bruno Haible, with reusable code from the GNU gettext package.

As they cared for portability, many changes in the C code were accompanied
by changes in the build infrastructure.
Copying these changes into packages --- it was all done manually --- became
cumbersome.  So they wrote a program, called @samp{gnulib-tool}, that does
this job of copying the requested shared code into a particular package.
This was in 2002.

Providing a substitute / override for a system function was relatively easy.
Providing a substitute / override for a system header file was significantly
harder, but was done successively:
for @code{stdint.h} in 2004,
for @code{stdarg.h}, @code{sys/socket.h}, @code{sys/stat.h} in 2006,
for @code{sys/time.h}, @code{wchar.h} in 2007,
and the development of the corresponding idioms took until 2010.

Unicode string modules (that make up GNU libunistring) were added in 2007--2009.

Modules for numeric functions (@code{}) were added in 2010--2011.

Modules for container data structures were added between 2006 and 2018.

Versatile bit-set modules were added in 2018.

POSIX threads on non-POSIX platforms, as well as ISO C threads on all
platforms, were added in 2019.

The @code{posix_spawn} facility was brought to completion on native Windows
in 2022, providing the world's first @code{posix_spawn} implementation for
this platform.

Support for Android was added in 2023 and immediately used by GNU Emacs
for Android.

Functions for working with Unicode characters in multibyte representation,
based on @code{mbrtoc32}, were added in 2023.

Modules for manipulating the floating-point environment (@code{fenv.h}) were
added in 2023.

The @samp{gnulib-tool} rewrite in Python, that was started by Dmitry Selyutin
in 2012 but lay unfinished for many years, was completed by Collin Funk and
Bruno Haible in 2024.

Re: Adding Cygwin and MSYS2 to DEPENDENCIES

[Bruno Haible]

Hi Collin,

> I read the emails you sent and INSTALL.windows in gettext. How about
> this revised version based on that information?
> 
> Since Cygwin is preferred we can just have a single section for that.
> Mention explicitly that it is preferred over MSYS2.

Pretty good already.

> diff --git a/DEPENDENCIES b/DEPENDENCIES
> index b700c05bc6..9bb66fbcd9 100644
> --- a/DEPENDENCIES
> +++ b/DEPENDENCIES
> @@ -197,3 +197,13 @@ at any time.
>  https://www.gnu.org/software/tar/
>+ Download:
>  https://ftp.gnu.org/gnu/tar/
> +
> +* Cygwin
> +  + Optional. Needed only for Windows users.
> +Provides a POSIX-like environment and binary packages necessary to
> +build and run software. Native Windows binaries can be built with
> +a packaged mingw tool chain. This method is preferred over MSYS2.
> +  + Homepage:
> +https://cygwin.com/
> +  + Download:
> +https://cygwin.com/install.html

I would additionally format it as a subsection, so that it clearly stands
out from the rest:

Prerequisites needed on specific platforms
==

Prerequisites on Windows


* Cygwin
  + Required.
Provides ...
  ...


Bruno

Re: gnulib-tool.py: Don't leave temporary directories on exit.

[Bruno Haible]

Hi Collin,

> ... It seems like a pain to track
> down every code path that can lead to 'sys.exit()' or 'exit()' with a
> temporary directory still existing.
> ...
> Therefore, we can use tempfile.TemporaryDirectory as a context manager
> and let Python cleanup for us [1]:
> 
>  def main_with_exception_handling() -> None:
>  try:  # Try to execute
> -main()
> +with tempfile.TemporaryDirectory() as temporary_directory:
> +main(temporary_directory)
>  except GLError as error:
>  errmode = 0  # gnulib-style errors
>  errno = error.errno

Yes, that's a nice improvement. I agree, the 'with' statement with
automatic resource cleanup is exactly the right tool for this situation.

Bruno

Re: gnulib-tool.py: Quote file names passed to 'patch'.

[Bruno Haible]

Collin Funk wrote:
> I noticed that the file names when running 'patch' on test-driver
> weren't quoted. I guess that would cause problems in practice if you
> used spaces in directories

Indeed. Thanks for fixing that!

> Since we assume POSIX shells we can just use shlex.quote() to deal
> with any theoretical shell injections too [1].

Yes, I agree. We don't need to write the equivalent of module 'sh-quote'
in Python, when it already exists.

Bruno

gnulib-tool.py: Don't leave temporary directories on exit.

[Collin Funk]

It looks like gnulib-tool.py never cleaned up temporary directories
for modes other than the --import, --create-testdir, and related.

Since the --extract-* functions seem less used, hopefully this hasn't
caused too much spam yet.

In gnulib-tool-tests:

$ rm -rf /tmp/glpy*
$ ./test-all.sh
$ find '/tmp' -name 'glpy*' -type d 2> /dev/null | wc -l
54

in gnulib-tool-tests/info-tests:

$ rm -rf /tmp/glpy*
$ ./test-all.sh
$ find '/tmp' -name 'glpy*' -type d 2> /dev/null | wc -l
54

GLImport.__init__() and main() are pretty massive and ideally I would
like to make them a bit easier to read. It seems like a pain to track
down every code path that can lead to 'sys.exit()' or 'exit()' with a
temporary directory still existing.

With that said, GLConfig's are only created in two places. Once in
main() for the lifetime of the program. The other in
GLImport.__init__() to represent 'gnulib-cache.m4'. The one
representing the cache has it's temporary directory removed right
after.

Therefore, we can use tempfile.TemporaryDirectory as a context manager
and let Python cleanup for us [1]:

 def main_with_exception_handling() -> None:
 try:  # Try to execute
-main()
+with tempfile.TemporaryDirectory() as temporary_directory:
+main(temporary_directory)
 except GLError as error:
 errmode = 0  # gnulib-style errors
 errno = error.errno


Solves the spam and seems like the best solution for now. I applied
the attached patch doing this.

[1] https://docs.python.org/3/library/tempfile.html#tempfile.TemporaryDirectory

CollinFrom 3169fd03dc5c917dbfe3096ec54921ca0e5f7253 Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Thu, 2 May 2024 00:49:58 -0700
Subject: [PATCH] gnulib-tool.py: Don't leave temporary directories on exit.

* pygnulib/main.py (main_with_exception_handling): Use
tempfile.TemporaryDirectory as a context manager so it is removed before
the program exits.
(main): Expect a temporary directory to be passed as an argument.
* pygnulib/GLConfig.py (GLConfig.__init__): Accept an optional temporary
directory parameter instead of creating one.
* pygnulib/GLImport.py (GLImport.__init__): Don't remove the cache's
temporary directory since it doesn't create one anymore.
(GLImport.execute): Don't remove the temporary directory explicitly. It
is handled by the usage of a context manager.
* pygnulib/GLTestDir.py (GLTestDir.execute, GLMegaTestDir.execute):
Likewise.
---
 ChangeLog | 16 
 pygnulib/GLConfig.py  |  4 ++--
 pygnulib/GLImport.py  |  2 --
 pygnulib/GLTestDir.py |  2 --
 pygnulib/main.py  |  9 +
 5 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index bd2c45d9af..2257857847 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,19 @@
+2024-05-02  Collin Funk  
+
+	gnulib-tool.py: Don't leave temporary directories on exit.
+	* pygnulib/main.py (main_with_exception_handling): Use
+	tempfile.TemporaryDirectory as a context manager so it is removed before
+	the program exits.
+	(main): Expect a temporary directory to be passed as an argument.
+	* pygnulib/GLConfig.py (GLConfig.__init__): Accept an optional temporary
+	directory parameter instead of creating one.
+	* pygnulib/GLImport.py (GLImport.__init__): Don't remove the cache's
+	temporary directory since it doesn't create one anymore.
+	(GLImport.execute): Don't remove the temporary directory explicitly. It
+	is handled by the usage of a context manager.
+	* pygnulib/GLTestDir.py (GLTestDir.execute, GLMegaTestDir.execute):
+	Likewise.
+
 2024-05-01  Collin Funk  
 
 	gnulib-tool.py: Quote file names passed to 'patch'.
diff --git a/pygnulib/GLConfig.py b/pygnulib/GLConfig.py
index 92aa49d700..b8a7fc5b0b 100644
--- a/pygnulib/GLConfig.py
+++ b/pygnulib/GLConfig.py
@@ -20,7 +20,6 @@
 #===
 import os
 import copy
-import tempfile
 from typing import Any
 from .constants import (
 MODES,
@@ -44,6 +43,7 @@ class GLConfig:
 table: dict[str, Any]
 
 def __init__(self,
+ tempdir: str | None = None,
  destdir: str | None = None,
  localpath: list[str] | None = None,
  auxdir: str | None = None,
@@ -82,7 +82,7 @@ def __init__(self,
  errors: bool | None = None) -> None:
 '''Create new GLConfig instance.'''
 self.table = dict()
-self.table['tempdir'] = tempfile.mkdtemp(prefix='glpy')
+self.table['tempdir'] = tempdir
 # Check and store the attributes.
 # Remove trailing slashes from the directory names. This is necessary
 # for m4base (to avoid an error in func_import) and optional for the
diff --git a/pygnulib/GLImport.py b/pygnulib/GLImport.py
index 833e186b8f..a11da0e63d 100644
--- a/pygnulib/GLImport.py
+++ b/pygnulib/GLImport.py
@@ -92,7 +92,6 @@ def __init__(self, config: GLConfig, mode: int) -> None: