| From: |
| "Andreas K. Huettel" <dilfridge-AT-gentoo.org> |
| To: |
| libc-alpha-AT-sourceware.org |
| Subject: |
| Re: Glibc stable release process (Glibc 2.26.1) |
| Date: |
| Sat, 30 Sep 2017 18:28:32 +0200 |
| Message-ID: |
| <2000297.QMxbJEGknr@porto> |
| Cc: |
| Arjan van de Ven <arjan-AT-linux.intel.com>, Romain Naour <romain.naour-AT-gmail.com>, Joseph Myers <joseph-AT-codesourcery.com>, "Gabriel F. T. Gomes" <gabriel-AT-inconstante.eti.br>, Siddhesh Poyarekar <siddhesh-AT-sourceware.org>, "Yann E. MORIN" <yann.morin.1998-AT-free.fr> |
Am Samstag, 30. September 2017, 02:38:53 CEST schrieb Arjan van de Ven:
> On 9/29/2017 1:17 PM, Romain Naour wrote:
> > Hello All,
> >
> > As suggested by Siddhesh Poyarekar in BZ-22146 [0], I'd like to continue
> > the discussion about tagging a 2.26.1 release.
> >
> > Glibc 2.26 introduced some regressions (notably BZ-21930 and BZ-22146) on
> > major architectures (x86 and x86_64) that are already fixed in the stable
> > branch. Without them, we can't compile C++ any code using mathematical
> > functions (ex: std::fpclassify() when libstdc++ is compiled with -Os).
> >
> > Siddhesh Poyarekar said that is no plan for a new release since most
> > distributions prefer to backport patches. But for downstream users like
> > build tools (Buildroot, crosstool-ng, Yocto...) that use the release
> > archives, it means that a lot of patches need to be backported (42 at the
> > time of writing).
> as someone who does glibc for a distro... I strongly prefer tarbal releases.
> There's a lot less ambiguity in terms of what is running, and distros
> generally are set up to take tarbals anyway....
>
> taking a patch or two is fine, but doing this over and over again makes it
> less obvious what exact stack is running etc.
+1 (another distro voice, Gentoo)
Even if we apply some patches downstream, having a common reference point, as
e.g. a 2.26.1 release, would be nice.
--
Dr. Andreas K. Hüttel
tel. +49 151 241 67748 (mobile)
e-mail mail@akhuettel.de
http://www.akhuettel.de/