Re: Bug in test-fcntl.c

2021-05-08 Thread Nicholas Gaya
I ran into this issue when running tests for the MacPorts port of oath-toolkit (https://ports.macports.org/port/oath-toolkit/) on Mac OS 10.14.6. I don't know the specific reason, but it seems like the test process inherits a lot of open files from its parent, as the actual fd returned by fcntl

Re: Bug in test-fcntl.c

2021-05-08 Thread Bruno Haible
Hi, Nicholas Gaya wrote: > fd 10 is already in use (which happens to be the case in the testing > environment where I ran into this bug) 3 questions: 1) What is this environment that leaves fd 10 open when it starts a process? 2) For which purpose does it use this fd? 3) What would happen if we c

Bug in test-fcntl.c

2021-05-08 Thread Nicholas Gaya
Hello, I believe I have found a bug in gnulib's test-fcntl.c. In order to test the functionality of fcntl with FD_DUPFD_CLOEXEC, the test dups an open file descriptor using the flag and execs a child process to check that the file descriptor gets closed on exec. The problem is that the current

Re: maint.mk suggestion for gnupload

2021-05-08 Thread Simon Josefsson via Gnulib discussion list
Eric Blake writes: > It was pointed out to me that for multiple years, m4's > 'm4-latest.tar.XX' links were out of date at https://ftp.gnu.org/gnu/m4/ > - the links were created in in 2013 when I released m4-1.4.17, but never > updated in 2016 when I released m4-1.4.18. > > I managed to fix the l

maint.mk suggestion for gnupload

2021-05-08 Thread Eric Blake
It was pointed out to me that for multiple years, m4's 'm4-latest.tar.XX' links were out of date at https://ftp.gnu.org/gnu/m4/ - the links were created in in 2013 when I released m4-1.4.17, but never updated in 2016 when I released m4-1.4.18. I managed to fix the latest links today with: $ build