Glibc 2.28 Released With Unicode 11.0 Support, Statx & Intel Improvements

[rene]

this is irrelevant for anything but ranting. other maintainers are able to pull gnulib update, users should consume maintainters' work, or at least should have required skills

This is as relevant as news about esoteric and rarely used new features, maybe even more important as it is a heads up warning that some integration work and fixing regressions is needed, ..! You're welcome.

[rene]

not everything introduced is meant to be used by you

I f*cking did not use it! The same GNU project itself did, ..!

[pal666]

This was just a newsworthy data point for others, e.g. users of source distirbutions or other maintainers.

this is irrelevant for anything but ranting. other maintainers are able to pull gnulib update, users should consume maintainters' work, or at least should have required skills

[pal666]

non standard APIs the Linux kernel and GNU introduced ? ;-) oh, ..! duh !1!!

not everything introduced is meant to be used by you

[rene]

And the gnulib issue is neither a glibc regression as I explain. Anyway fell free to open bug reports or approach us on mailing list if you find a regression or bug, I just kindly ask you to actually provide useful information instead of just bashing the project.

That the glibc update breaks compiling coreutils, gnuzip, m4 is a major regression. Actually a showstopper bootstrapping a Linux distribution. That this are even native GNU packages makes the breakage even more sad. Wether you like it or not. I'm aware that this is neither a support nor bug report database. This was just a newsworthy data point for others, e.g. users of source distirbutions or other maintainers.

Have a good night.

[ZatrazZ]

Please stop putting this questionable negativity into my post that was not there. I quoted the 2.18 gnulib regressions in detail, and the quoted video shortly mentioned glibc-2.17 segfaults on sparc64. It is also not my fault that the GNU project's own gnulib used internal APIs for decades and this was neither fixed nor coordinated with new releases before the release of glibc-2.18.

I understand your frustration, but mine is not there. Stop shooting the messenger, I sit here in peace and harmony between my sparc64, ppc64 and mips64 and did neither ask for help nor was a I ranting. PS: another unrelated YT video to improve your Sunday mood: https://www.youtube.com/watch?v=_-MgF4YXl5Y

And the gnulib issue is neither a glibc regression as I explain. Anyway fell free to open bug reports or approach us on mailing list if you find a regression or bug, I just kindly ask you to actually provide useful information instead of just bashing the project.

[rene]

You explict stated the new 2.28 release brought new regression, linked a totally unrelated video with brfts issues on sparc and some links with outdated embedded gnulib code with abused the API constraint. When I asked to further information to actually check if your issue is a real one you dismiss me.

And I never stated it is an issue with your build system, I just suggest it might be (I actually never heard about it until now). And yes, installation on a living system is not supported (it is clear stated in FAQ [1]) and while I do agree it is not optimal, it is a hard problem to provide atomicity and no one has suggested a better alternative (patches are welcome).

Now I understand you frustration and I do not want minimize or dismiss as unimportant. However if you want to move foward and help us narrow down where the issue might be you will need also to change your tone. If you have time, please address with issue on libc-alpha with as much information as possible. There are developers, including myself, that would sincere try to help you there.

[1] https://sourceware.org/glibc/wiki/FA..._just_built.3F

Please stop putting this questionable negativity into my post that was not there. I quoted the 2.18 gnulib regressions in detail, and the quoted video shortly mentioned glibc-2.17 segfaults on sparc64. It is also not my fault that the GNU project's own gnulib used internal APIs for decades and this was neither fixed nor coordinated with new releases before the release of glibc-2.18.

I understand your frustration, but mine is not there. Stop shooting the messenger, I sit here in peace and harmony between my sparc64, ppc64 and mips64 and did neither ask for help nor was a I ranting. PS: another unrelated YT video to improve your Sunday mood: https://www.youtube.com/watch?v=_-MgF4YXl5Y

[ZatrazZ]

Some people focus on their snowflake safespace ranting terminology, others to solve actual problems. I not once said the segfaults are related to any gnulib compile issue, and specifically said the segfaults started with the previous 2.17. And yes, blame my "build system", maybe something is rather wrong with the make install not using atomic install / moves and instead overwrite an existing shared library while mapped in memory already – like I remember happing with some release nearly two decades ago.

Why do you even continue replying and accusing me of ranting, have you nothing more positive to do?

You explict stated the new 2.28 release brought new regression, linked a totally unrelated video with brfts issues on sparc and some links with outdated embedded gnulib code with abused the API constraint. When I asked to further information to actually check if your issue is a real one you dismiss me.

And I never stated it is an issue with your build system, I just suggest it might be (I actually never heard about it until now). And yes, installation on a living system is not supported (it is clear stated in FAQ [1]) and while I do agree it is not optimal, it is a hard problem to provide atomicity and no one has suggested a better alternative (patches are welcome).

Now I understand you frustration and I do not want minimize or dismiss as unimportant. However if you want to move foward and help us narrow down where the issue might be you will need also to change your tone. If you have time, please address with issue on libc-alpha with as much information as possible. There are developers, including myself, that would sincere try to help you there.

[1] https://sourceware.org/glibc/wiki/FA..._just_built.3F

[rene]

Assuming the segfauts are unrelated to gnulib build issue, It sounds like a rant because you do not provide any useful information so someone could debug or check where the issues lies. I might be just something wrong in your build system for instance.

Some people focus on their snowflake safespace ranting terminology, others to solve actual problems. I not once said the segfaults are related to any gnulib compile issue, and specifically said the segfaults started with the previous 2.17. And yes, blame my "build system", maybe something is rather wrong with the make install not using atomic install / moves and instead overwrite an existing shared library while mapped in memory already – like I remember happing with some release nearly two decades ago.

Why do you even continue replying and accusing me of ranting, have you nothing more positive to do?

[ZatrazZ]

What is ranting in specifically pointing out each and every glibc related gnulib build error? Btw. the massive segfaults just started again, now I realised it starts when rebuilding glibc a second time natively after initial cross compilation. This did not happen the last 10 years up until 2.27

PS: yes this is still not an in depth analyses, as I also have other things to do and can not spend the whole day looking into this, ..!

Assuming the segfauts are unrelated to gnulib build issue, It sounds like a rant because you do not provide any useful information so someone could debug or check where the issues lies. I might be just something wrong in your build system for instance.