> > I propose to remove '.cppi-disable'.
>
> Sounds good to me. I don't use cppi.
Done:
2024-06-15 Bruno Haible
Drop outdated cppi configuration.
* lib/.cppi-disable: Remove file.
And some more updates:
2024-06-15 Bruno Haible
doc: Update for glibc 2.39.
* doc/posix-functions/*scanf.texi: Update.
diff --git a/doc/posix-functions/fscanf.texi b/doc/posix-functions/fscanf.texi
index 2b07c1cdb8..240007be8d 100644
--- a/doc/posix-functions/fscanf.texi
+++ b
This patch adds doc regarding the new functions in glibc 2.39.
2024-06-15 Bruno Haible
doc: Update for glibc 2.39.
* doc/glibc-functions/pidfd_getpid.texi: New file.
* doc/glibc-functions/pidfd_spawn.texi: New file.
* doc/glibc-functions/pidfd_spawnp.texi: New
Bruno Haible wrote:
> Actually, no, it is not a requirement any more that
> GNULIB_TOOL_IMPL=sh+py works in all cases.
> This strict "same output" check was useful before we switched
> to the Python implementation by default, and in the few weeks
> afterwards.
>
> It's OK now to make small changes
I wrote:
> > Do you still expect GNULIB_TOOL_IMPL=sh+py to pass by the way?
>
> Sure. We need to give users a year, at least, for migrating from
> the shell to the Python implementation. And when they migrate,
> it should be a no-op for them.
Actually, no, it is not a requirement any more that
GN
Likewise for new functionality added in glibc 2.38.
The URLs to POSIX-1.2024 man pages need to be updated once they are available.
2024-06-15 Bruno Haible
doc: Update for glibc 2.38.
* doc/posix-functions/strlcat.texi: New file.
* doc/posix-functions/strlcpy.texi: New
This patch updates Gnulib's doc regarding new functions introduced in
glibc 2.36.
2024-06-15 Bruno Haible
doc: Update for glibc 2.36.
* doc/posix-functions/c8rtomb.texi: Update.
* doc/posix-functions/mbrtoc8.texi: Update.
* doc/glibc-functions/arc4random.texi:
Hi Collin,
> Agreed, I reverted that patch and pushed it before it causes any
> trouble [1].
Thanks!
> Do you still expect GNULIB_TOOL_IMPL=sh+py to pass by the way?
Sure. We need to give users a year, at least, for migrating from
the shell to the Python implementation. And when they migrate,
i
Bruno Haible wrote:
> Yes, that's my point. Instead of using unnormalized file names nearly
> everywhere and normalized file names only in a few places, it is better
> to use normalized file names nearly everywhere and unnormalized file names
> only in a few places. It causes fewer bugs and less he
Quoting [1]:
"[Yesterday] IEEE Std 1003.1-2024 has been published by IEEE.
The Open Group Base Specifications, Issue 8 has been published by
The Open Group. At this stage only PDF is available. The HTML edition
to follow soon."
[1] http://www.opengroup.org/austin/
Collin Funk wrote:
> But I am still confused about what the point of 'newtail' is:
>
> def joinpath(head: str, *tail: str) -> str:
> '''Join two or more pathname components, inserting '/' as needed. If any
> component is an absolute path, all previous path components will be
> discarde
Bruno Haible wrote:
>> I never really looked at the joinpath() function so I just realized it
>> essentially does os.path.normpath(os.path.join(...)) unlike what it's
>> doc string says.
>
> "unlike what the doc string says"? What do you mean by that? The doc string
> said "This function also repl
Hi Collin,
> I never really looked at the joinpath() function so I just realized it
> essentially does os.path.normpath(os.path.join(...)) unlike what it's
> doc string says.
"unlike what the doc string says"? What do you mean by that? The doc string
said "This function also replaces SUBDIR/../ w
Bruno Haible writes:
>> Can you please ask ass...@gnu.org (I guess) to update it?
>
> We have already raised the topic with copyright-cl...@fsf.org (which, AFAIK,
> is identical to ass...@gnu.org). No need to raise it a second time.
May I know if there is any progress on this issue?
--
Ihor Ra
14 matches
Mail list logo
