Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    Glibc 2.28, the latest update to the GNU C Library, is now available to start off the month of August...

    http://www.phoronix.com/scan.php?pag...-2.28-Released

  • rene
    replied
    Originally posted by pal666 View Post
    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.

    Leave a comment:


  • rene
    replied
    Originally posted by pal666 View Post
    not everything introduced is meant to be used by you
    I f*cking did not use it! The same GNU project itself did, ..!

    Leave a comment:


  • pal666
    replied
    Originally posted by rene View Post
    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

    Leave a comment:


  • pal666
    replied
    Originally posted by rene View Post
    non standard APIs the Linux kernel and GNU introduced ? ;-) oh, ..! duh !1!!
    not everything introduced is meant to be used by you

    Leave a comment:


  • rene
    replied
    Originally posted by ZatrazZ View Post

    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.

    Leave a comment:


  • ZatrazZ
    replied
    Originally posted by rene View Post

    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.

    Leave a comment:


  • rene
    replied
    Originally posted by ZatrazZ View Post

    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

    Leave a comment:


  • ZatrazZ
    replied
    Originally posted by rene View Post

    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
    Last edited by ZatrazZ; 08-04-2018, 09:07 PM.

    Leave a comment:


  • rene
    replied
    Originally posted by ZatrazZ View Post

    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?

    Leave a comment:

Working...
X