Glibc 2.27 Released With Many Optimizations, Support For Static PIE Executables

[monraaf]

LOL, Archlinux will have it next week as late, Gentoo already have it on glibc-9999.

And how many upstream contributions in the 2.27 release came from Arch, Solus or whatnot people?

Debian, SUSE and Fedora might not have the latest versions on release day (although Fedora Rawhide is faster than anyone else here anyway), their distribution developers are the ones who do all the work.

Of course if you use Debian or any other non rolling distro, it will take a long time but you should have accepted that fate when you decided to use a release cycle distro instead of rolling, so I don't get where the whine is coming from? it was your own choice !!!

Which feature from the 2.27 release do you need which warrants a quick update of the distribution package?

Is this some sort of pissing contest? Good distributions will actually perform integration tests and not use their users as guinea pigs for fundamental packages like glibc.

If you don't care about that, you probably don't do any actual work with your computer but just use it for its own sake.

[dungeon]

LOL, Archlinux will have it next week as late, Gentoo already have it on glibc-9999.

Of course if you use Debian or any other non rolling distro, it will take a long time but you should have accepted that fate when you decided to use a release cycle distro instead of rolling, so I don't get where the whine is coming from? it was your own choice !!!

Debian also have it in experimental since a month ago . Debian Sid users could try it easely and to see what is currently broken

But when will 75K binary packages flowing around in Debian develpment branches or 28K source packages work on about 10 supported (and many other not really release supported) architectures with it, all without issue, etc... that is another question Producing tested and stable clikete click binary distro which include this require a lot of time, testings and efforts

[jrch2k8]

And how many upstream contributions in the 2.27 release came from Arch, Solus or whatnot people?

Debian, SUSE and Fedora might not have the latest versions on release day (although Fedora Rawhide is faster than anyone else here anyway), their distribution developers are the ones who do all the work.



Which feature from the 2.27 release do you need which warrants a quick update of the distribution package?

Is this some sort of pissing contest? Good distributions will actually perform integration tests and not use their users as guinea pigs for fundamental packages like glibc.

If you don't care about that, you probably don't do any actual work with your computer but just use it for its own sake.

1.) A lot of Arch maintainers and developers are also upstream developers and they are also very active in testing and communicating with upstream on several packages beside providing one of the most complete wiki available for Linux, also the same applies to RedHat, Debian, OpenSuse, etc. maintainers/developers as well as individuals and companies.

Don't get what your point is, but whatever I guess you are trying to look smart or defense by omission another your favorite distro which is moot either way, is a community an every action no matter how small benefit us all been upstream or testing or reporting or promoting.

2.) I maintain around 100 servers running ArchLinux(from my clients not mine), plus all my PC's home and office plus several VPS many of those are running AVX2/FMA capable hardware that could potentially help performance(hence is always nice to have) from glibc updates and GCC updates, so of course it may not be much in some cases and may be in some other but is important for me to keep my clients hardware performing optimally as fast as possible and my client always welcome any improvement.

2.a) as I mentioned before if you know what you are doing ArchLinux is rock solid and has been for me since I switched from gentoo in 2008, I actually had way more problem with RHEL upgrades(RPM dependency hell back in the early days of yum) during the years than I had with ArchLinux through a decade and as a fact in 10 years neither glibc or GCC(or other core package) has broken any of my servers ever.

My desktops is another story because there I have all the staging and testing repos active plus several bleeding edge packages I build daily from AUR(Mesa/Xorg/DRM/GNOME/ZFS/MPV/etc.), so is probably broken every couple of weeks but nothing pacman cannot easily roll back or I cannot fix with a patch.

Rolling doesn't mean (un)stable/secure and cycle doesn't mean stable/secure, it all depend on how you use them and the experience of the admin, using ArchLinux staging repos is as bad as not updating Debian for a year because is more stable if you don't know what you are doing.

As a nice fact, my main Xeon e3-1231v3 WS is using my first Archlinux installation from 2008 today, through a decade all I had done is DD the old HDD to a new one(grow the partition of course) and restart and actually last month I migrated my first ArchLinux+ZFSoL(year it booted from ZFS, I was so proud back then) Server from an Opteron 4130 to a newer Xeon(couldn't find an Epyc server back then sadly) simply by migrating the ZFS RAID 6 to the new drives, restart and Voila!! was like nothing ever happened to that server.

Which again these are stories you will hear from other distros as well because those were people that knew what they were doing, rolling is simply easier to maintain over time as long as you know what you are doing but cycled distros are good as well, again as long as you know what you are doing!!!! <-- trying emphatically to make it clear

2.b) is not a pissing contest, the OP dude was whining because distros won't pick it tomorrow and I was simply being through, if you pick a cycle distro you are bound to that distro cycle for updates, is that simple but if you have the technical skills and wanna be ahead of that cycle rolling distros are there for you as well.

[Marc Driftmeyer]

To be fair, Debian took 6 months to roll out 2.26 on Sid. Experimental already had 2.27 to try out. That's an improvement from the past.

[heliosh]

Went through debians changelog:
glibc 2.26 was released 2017-08-02; In debian sid since 2018-01-03 (154d)
glibc 2.25 was released 2017-02-01; In debian sid since 2017-11-18 (290d)
glibc 2.24 was released 2016-08-04; In debian sid since 2016-08-31 (27d)
glibc 2.23 was released 2016-02-19; In debian sid since 2016-07-03 (135d)
glibc 2.22 was released 2015-08-14; In debian sid since 2016-03-07 (206d)
glibc 2.21 was released 2015-02-06; In debian sid since 2015-12-01 (298d)

mean 185d, stdev 103d.

[FireBurn]

So glibc 2.27 appears to be totally broken in Gentoo https://bugs.gentoo.org/646424

[duby229]

Just to be fair here, ArchLinux only breaks on GCC(on ABI changes)/glibc updates, if you enable the staging and testing repos without the technical knowledge on how to use them because as the name states very clearly is not for regular users but seasoned power users that can at the very least do a decent bug report on the breaks.

The problem with new users and arch is that they think all repos should be enabled to get everything fast when the aforementioned repos are meant for the ArchLinux developers and power users to actually do the testing they will whine doesn't happen five minutes later.

If you are not a power user or a developer just use the default "Stable" repos and you won't even notice when glibc lands because once it reaches core is bullet proof outside very obscure software that will likely get patches couple days later.

Same applies to other rolling distros, in gentoo if you unmask an -9999 ebuild be damn sure you know what you are doing because people will laugh at you otherwise when you whine is broken

Thank You! glibc-9999 is almost guaranteed to break your system. Especially on gentoo, where just a missing include can make dozens of packages fail to build. It really was meant for testing and bug reporting, not for day to day use.

[dungeon]

Went through debians changelog:
glibc 2.26 was released 2017-08-02; In debian sid since 2018-01-03 (154d)
glibc 2.25 was released 2017-02-01; In debian sid since 2017-11-18 (290d)
glibc 2.24 was released 2016-08-04; In debian sid since 2016-08-31 (27d)
glibc 2.23 was released 2016-02-19; In debian sid since 2016-07-03 (135d)
glibc 2.22 was released 2015-08-14; In debian sid since 2016-03-07 (206d)
glibc 2.21 was released 2015-02-06; In debian sid since 2015-12-01 (298d)

mean 185d, stdev 103d.

These known offending packages like new initial glibc releases are in experimental until it is safe to upload them to sid, you know - shit is waiting for good weather

Since you like reading changelogs, look a longterm a bit for example 2.19, since release it was 18 times further patched a lot until it becames stable for release . And once it was stable, 10 times futher patched for a lot of security issues and still some inconveniences... shit is shit

Do you still think their relases are shit good enough to be immediately dropped on everybody heads?

[heliosh]

I'm not in a hurry. I was just fact-checking "now we just need to wait another 10 years for distros to pick it up".

[Guest]

In Gentoo: one can emerge glibc-9999, or wait a short while for glibc-2.27 ebuild to appear in the official Gentoo package tree.

2.27 coincided with ebuild rewrite which caused it to break on multilib (didn't actually install 32bit libraries, effectively breaking 32bit programs which in turn cause 32bit stuff not compile). -r1 ebuild fixed it, even added workaround for this so you can compile -r1 without 32bit libs.
Unkeyworded (not stable or testing) glibc break in spectacular fashion on my gentoo boxes, this time it fortunately didn't break all of my boxes completely (which update every night via cronjob).