The GNU C Library version 2.28 is now available

[Samuel Thibault]

----- Forwarded message from Carlos O'Donell <***@redhat.com> -----

From: Carlos O'Donell <***@redhat.com>
To: GNU C Library <libc-***@sourceware.org>, libc-***@sourceware.org, info-***@gnu.org
Subject: The GNU C Library version 2.28 is now available
Date: Wed, 1 Aug 2018 03:07:38 -0400

The GNU C Library
=================

The GNU C Library version 2.28 is now available.

The GNU C Library is used as *the* C library in the GNU system and
in GNU/Linux systems, as well as many other systems that use Linux
as the kernel.

The GNU C Library is primarily designed to be a portable
and high performance C library. It follows all relevant
standards including ISO C11 and POSIX.1-2008. It is also
internationalized and has one of the most complete
internationalization interfaces known.

The GNU C Library webpage is at http://www.gnu.org/software/libc/

Packages for the 2.28 release may be downloaded from:
http://ftpmirror.gnu.org/libc/
http://ftp.gnu.org/gnu/libc/

The mirror list is at http://www.gnu.org/order/ftp.html

NEWS for version 2.28
=====================

[...]

* Building and running on GNU/Hurd systems now works without out-of-tree
patches.

[Svante Signell]

Post by Samuel Thibault
NEWS for version 2.28
=====================
[...]
* Building and running on GNU/Hurd systems now works without out-of-
tree
patches.

Finally an upstream glibc that supports GNU/Hurd. Nice work Samuel :)

[Richard Braun]

Post by Samuel Thibault
NEWS for version 2.28
=====================
[...]
* Building and running on GNU/Hurd systems now works without out-of-tree
patches.

I didn't think it would actually happen. Great work :).

[Ludovic Courtès]

Hello!

Post by Richard Braun

Post by Samuel Thibault
NEWS for version 2.28
=====================
[...]
* Building and running on GNU/Hurd systems now works without out-of-tree
patches.

I didn't think it would actually happen. Great work :).

Indeed, a few months back it looked like something we wouldn’t see in
our lifetime. ;-)

Thumbs up to everyone who contributed and in particular to Samuel and
Joseph for tirelessly going through all these patches!

Ludo’.

[Samuel Thibault]

About glibc repositories, we should upgrade the Hurd glibc repository to
2.28, when would that be fine for people using it? (I'm thinking about
Guix & Arch people)

Samuel

[Manolis Ragkousis]

Post by Samuel Thibault
About glibc repositories, we should upgrade the Hurd glibc repository to
2.28, when would that be fine for people using it? (I'm thinking about
Guix & Arch people)
Samuel

This is really great!! I will update our glibc-hurd package and we will
now probably be able to remove a lot of Hurd specific parts.

This is awesome work!!

Manolis

[David Michael]

On Wed, Aug 1, 2018 at 11:37 AM, Samuel Thibault

Post by Samuel Thibault
About glibc repositories, we should upgrade the Hurd glibc repository to
2.28, when would that be fine for people using it? (I'm thinking about
Guix & Arch people)

Now that there is an upstream release with the Hurd patches (thanks
for doing that), my preference as a user would be to switch from the
Savannah repo to the upstream release tarball and apply any individual
patches required by Hurd as they pop up.

Do you think Hurd-specific patches are appropriate to send to
libc-stable for backporting to the upstream release branches?

If not, could the Savannah repo maybe have a new branch started on the
release tag that is just for cherry-picking Hurd-specific commits?
The tschwinge/Roger_Whittaker branch can be a bit unwieldy for picking
out patches, and that flat commit topology from cherry-picking is used
for stable branches in other projects like glibc, Linux, and systemd,
which is friendlier to packagers using simple Git commands or the
repo's web interface. I realize the topgit-managed branch has a
different goal, so a new branch like this would not be intended to
replace it. If you think this is worth doing, I can volunteer to do
the actual cherry-picking and conflict resolution for the latest glibc
release so it's not putting more of a maintenance burden on you.

Thanks.

David

[Samuel Thibault]

Post by David Michael
On Wed, Aug 1, 2018 at 11:37 AM, Samuel Thibault

Post by Samuel Thibault
About glibc repositories, we should upgrade the Hurd glibc repository to
2.28, when would that be fine for people using it? (I'm thinking about
Guix & Arch people)

Now that there is an upstream release with the Hurd patches (thanks
for doing that), my preference as a user would be to switch from the
Savannah repo to the upstream release tarball and apply any individual
patches required by Hurd as they pop up.
Do you think Hurd-specific patches are appropriate to send to
libc-stable for backporting to the upstream release branches?

I don't know actually. My wild guess is that upstream will be fine to
backport anything we feel is really needed, as long as it is limited to
Hurd code. For more invasive changes, it would make sense to have a
branch in the hurd repo with normal, non-topgit, cherry-picks.

Samuel

[Samuel Thibault]

Post by Samuel Thibault

Post by David Michael
On Wed, Aug 1, 2018 at 11:37 AM, Samuel Thibault

Post by Samuel Thibault
About glibc repositories, we should upgrade the Hurd glibc repository to
2.28, when would that be fine for people using it? (I'm thinking about
Guix & Arch people)

Now that there is an upstream release with the Hurd patches (thanks
for doing that), my preference as a user would be to switch from the
Savannah repo to the upstream release tarball and apply any individual
patches required by Hurd as they pop up.
Do you think Hurd-specific patches are appropriate to send to
libc-stable for backporting to the upstream release branches?

I don't know actually. My wild guess is that upstream will be fine to
backport anything we feel is really needed, as long as it is limited to
Hurd code. For more invasive changes, it would make sense to have a
branch in the hurd repo with normal, non-topgit, cherry-picks.

I have already cherry-picked one commit into release/2.28/master :)

Samuel

[David Michael]

Post by Samuel Thibault

Post by David Michael
On Wed, Aug 1, 2018 at 11:37 AM, Samuel Thibault

Post by Samuel Thibault
About glibc repositories, we should upgrade the Hurd glibc repository to
2.28, when would that be fine for people using it? (I'm thinking about
Guix & Arch people)

Now that there is an upstream release with the Hurd patches (thanks
for doing that), my preference as a user would be to switch from the
Savannah repo to the upstream release tarball and apply any individual
patches required by Hurd as they pop up.
Do you think Hurd-specific patches are appropriate to send to
libc-stable for backporting to the upstream release branches?

I don't know actually. My wild guess is that upstream will be fine to
backport anything we feel is really needed, as long as it is limited to
Hurd code. For more invasive changes, it would make sense to have a
branch in the hurd repo with normal, non-topgit, cherry-picks.

Okay, that makes sense. I'd be interested to try such a branch and
see how it works out (once new Hurd patches are available, of course).
If you would like help maintaining it, I'm not currently in the
Savannah project, but my username is dm0 there in case it can be given
permission. I'd assume the branch would follow the usual rule of
other projects' stable branches, where only cherry-picks of patches
already applied in master are allowed.

Thanks.

David

[Samuel Thibault]

Hello,

Post by David Michael

Post by Samuel Thibault
I don't know actually. My wild guess is that upstream will be fine to
backport anything we feel is really needed, as long as it is limited to
Hurd code. For more invasive changes, it would make sense to have a
branch in the hurd repo with normal, non-topgit, cherry-picks.

Okay, that makes sense. I'd be interested to try such a branch and
see how it works out (once new Hurd patches are available, of course).
If you would like help maintaining it, I'm not currently in the
Savannah project, but my username is dm0 there in case it can be given
permission. I'd assume the branch would follow the usual rule of
other projects' stable branches, where only cherry-picks of patches
already applied in master are allowed.

Indeed.

Thomas, could you add his login so he can help with it?

Samuel

[Thomas Schwinge]

Hi!

"By the way": very much yay! for "Building and running on GNU/Hurd
systems now works without out-of-tree patches". Big thank you to Samuel
for driving this effort! :-D

Post by Samuel Thibault

Post by David Michael

Post by Samuel Thibault
For more invasive changes, it would make sense to have a
branch in the hurd repo with normal, non-topgit, cherry-picks.

ACK. Though, we should consider: who will be using that branch, that is,
who are we maintaining it for?

Post by Samuel Thibault

Post by David Michael
Okay, that makes sense. I'd be interested to try such a branch and
see how it works out (once new Hurd patches are available, of course).
If you would like help maintaining it, I'm not currently in the
Savannah project, but my username is dm0 there in case it can be given
permission. I'd assume the branch would follow the usual rule of
other projects' stable branches, where only cherry-picks of patches
already applied in master are allowed.

Indeed.
Thomas, could you add his login so he can help with it?

Done, thanks!


Grüße
Thomas