Arch Linux

Please provide links for each patch to the bug it solves.
Why include patches for Architectures Arch does not support IBM POWER9 and Z14? Same question in relation to the SELinux patches.

And please read https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines before reporting more "critical" issues

loqs (loqs) _commit=b5711025bc138c0c94d90b2015d57eda404decbe https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.33/master

The commit log for the 2.33 branch shows over 40 commits since release. Does that include the patches you are suggesting Arch include?

glibc-c-utf8-locale.patch Has that been submitted upstream yet?
glibc-cpu-check-1.patch / glibc-cpu-check-2.patch / glibc-cpu-check-1.patch replaces SIGILL termination of loading dynamic libs compiled with unsupported HWCAPS with a nicer error message on architectures Arch does not support?
glibc-cs-path.patch not upstreamed?
glibc-deprecated-selinux-nscd.patch / glibc-deprecated-selinux-nscd.patch Arch does not build with SELinux and has removed nscd which is deprecated.
glibc-fedora-linux-tcsetattr.patch not upstreamed? What kernel bug? What is the status of the kernel bug? patch is over 8 years old https://src.fedoraproject.org/rpms/glibc/c/fb633eaa14bb4c2b35f26c6ec2f4d829f27819ac?branch=rawhide and not accepted upstream
glibc-rh819430.patch not upstreamed? https://sourceware.org/bugzilla/show_bug.cgi?id=14185 upstream fix is different https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a79328c745219dcb395070cdcd3be065a8347f24;hp=5a664d7ae8e42d641a7b4b436987ff67ab483b08
glibc-rh827510.patch not upstreamed? https://sourceware.org/bugzilla/show_bug.cgi?id=14247

It's Fedora 34 patches. This patches is't in upstream. Upstream pacthes added with commit b5711025bc138c0c94d90b2015d57eda404decbe
https://src.fedoraproject.org/rpms/glibc/tree/f34

glibc-cpu-check-1.patch / glibc-cpu-check-2.patch / glibc-cpu-check-3.patch Future patches from 2.34. glibc-cpu-check-2.patch and glibc-cpu-check-3.patch not nedeed for Arch Linux.
glibc-cs-path.patch It is marked as not needed. But I added it because Arch Linux have symlink bin -> usr/bin the same as in Fedora.
glibc-deprecated-selinux-nscd.patch / glibc-deprecated-selinux-nscd.patch decided to leave nscd patches. The best solution in my opinion:
# https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/usingnscd-sssd
sed -i -E 's/enable-cache(\s+)(passwd|group|netgroup|services)(\s+)yes/enable-cache\1\2\3no/Ig' "${pkgdir:?}/etc/nscd.conf"

glibc-fedora-linux-tcsetattr.patch - I had a link to this bug somewhere. But now I can't find it. Even if the bug only manifests itself in Fedora, this patch add only extra checks.

Which patches in the upstream branch 2.33 branch justify not waiting for a new upstream release? Which ones fix the performance issues you mentioned? Do any fix security issues?

glibc-fedora-linux-tcsetattr.patch If you could provide a link to the bug report that would be great. There must be a reason Fedora has been carrying the patch for over 8 years without it being upstreamed.
glibc-c-utf8-locale.patch What bug in Arch is it fixing? Are you proposing changing the default locale to C.utf8 if so that should be a separate feature request.
glibc-rh819430.patch Could you find out why [1] was not backported to 2.33? If upstream has rejected Fedora's proposed fix why should Arch use it?
glibc-rh827510.patch [2] the upstream bug and Fedora's proposed fix are nine years old. Why start carrying it now?

[1] why https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a79328c745219dcb395070cdcd3be065a8347f24;hp=5a664d7ae8e42d641a7b4b436987ff67ab483b08
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=14247

"Which patches in the upstream branch 2.33 branch justify not waiting for a new upstream release?" All. 2.33 branch only contains bug and security fixes. The migration to 2.34 won't be smooth. It will probably take another month to fix existing 2.34 bugs.


glibc-rh819430.patch "This needs to be reviewed thoroughly and go upstream with a new test case."
glibc-rh827510.patch The bug is still showing itself. https://www.sourceware.org/bugzilla/show_bug.cgi?id=14247

I doubt Fedor's patches are unnecessary. If they added, then there are errors. They add bug fix patches and release packages faster than Arch Linux.
And they actively send patches to developers. I can't know why certain patches are not accepted. It often depends on the project maintainers.

I also consider it necessary to replace --enable-lock-elision with --disable-lock-elision. It use intel tsx https://www.phoronix.com/scan.php?page=news_item&px=Intel-TSX-Off-New-Microcode
This degrades performance on non-Intel processors. --enable-cet to --disable-cet Only work on intel cpu. We already use --enable-stack-protector=strong and cet excessive.
Worth deleting LDFLAGS=${LDFLAGS/,-z,now/} did not find any bugs solved by this method in glibc.
Leaving -z now gives us better security https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro

I doubt Fedor's patches are unnecessary. If they added, then there are errors. They add bug fix patches and release packages faster than Arch Linux.

Are you suggesting that Arch should make Fedora rawhide glibc its upstream?

You proposed 10 none upstreamed patches. Of which you agree six are not required for Arch's supported Architectures and feature set.
glibc-fedora-linux-tcsetattr.patch awaiting your bug report link
glibc-c-utf8-locale.patch again what bug is it fixing? Why not wait for upstream or open a seperate feature request asking for the default locale to be changed?
glibc-rh819430.patch you have not explained the benefit of that patch over [1].
glibc-rh827510.patch you agree is still not fixed upstream. Why not work with upstream to get a solution accepted? Then Arch would automatically have the fix from upstream on the next release.

[1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a79328c745219dcb395070cdcd3be065a8347f24;hp=5a664d7ae8e42d641a7b4b436987ff67ab483b08

"Are you suggesting that Arch should make Fedora rawhide glibc its upstream?"
Did you read badly?
I gave a link to f34 https://src.fedoraproject.org/rpms/glibc/tree/f34
But somehow you started watching rawhide. F34 It's stable Fedora release.
If you don't like patches, you can simply add patches only from 2.33 branch.
glibc-c-utf8-locale.patch Gentoo use it too https://dev.gentoo.org/~dilfridge/distfiles/glibc-2.33-patches-4.tar.xz
https://bugzilla.redhat.com/show_bug.cgi?id=902094
https://sourceware.org/bugzilla/show_bug.cgi?id=17318
https://bugs.gentoo.org/671024
glibc-cs-path.patch https://bugzilla.redhat.com/show_bug.cgi?id=1063607


You can do nothing. It doesn't matter to me personally, I have my own package repository and my own vision for fixing and working with packages, and active communication with developers.
"Why not work with upstream to get a solution accepted?" I do not know why. There are also stupid reasons, for example, just as zlib did not accepted the zlib-ng patches.
It all depends only on the maintainer.

Yes I missed you linked to f34. My apologies.

Please see attached diff. This updates glibc to b5711025bc138c0c94d90b2015d57eda404decbe the latest commit in release/2.33 branch you mentioned and drops patches that have been applied upstream.

The performance changes from the removal of hardening flags I would suggest is a separate feature request.

The C.utf8 locale a separate issue, it is not limited to glibc.

The reintroduction of nscd a separate issue.

Dropping support for kernels before 5.10.1 a separate issue.

The other none upstreamed patches again I would suggest should be a separate issue limited to those patches.

My job was to suggest changes. Then it's up to you to decide.
Still, I try to add patches, even if they are not upstream, because they help to close potential problems in advance.
And the best practices of the developers from redhat, gentoo, suse carry more weight to me than the Arch Linux developers.
Therefore, it is not surprising to me why large companies and developers such as Oracle prefer Redhat more often.
I have my own way, I'm more interested in the experience of building with Clang and LLVM Toolchain.
Just going through a large number of packages, I noticed that the Arch Linux developers do not read upstream bug reports and no hurry to close problems.

"Dropping support for kernels before 5.10.1 a separate issue." It was my choice, you don't need it. I have the best support for modern hardware and new features.
For me, the main concern is performance.

"The reintroduction of nscd a separate issue." It is included in Arch Linux glibc. I suggested only to change nscd settings.

I also suggest deleting --enable-stackguard-randomization https://sourceware.org/git/?p=glibc.git;a=commit;h=f294306ba1385b096f4e4cac9146a989f1e6d1c0

My job was to suggest changes. Then it's up to you to decide.
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

And the best practices of the developers from redhat, gentoo, suse carry more weight to me than the Arch Linux developers.
Which is not relevant to upstream patches which was your initial request.
Keeping to one issue per report allows for a focused review. How is that any different than other distributions models?
Other distributions support different Architectures and feature sets. You added six none upstreamed patches you agreed have no benefit to Arch.
Of the ten none upstreamed patches you have not provided a link to any issue anyone encountered under Arch they would fix.
You have linked to feature requests and bugs on other distributions.

"The reintroduction of nscd a separate issue." It is included in Arch Linux glibc. I suggested only to change nscd settings.
My confusion was from your addition of --enable-nscd in [1] which had the commit message "Performance optimization" with no mention that nscd is already enabled or why given that the change was made.
Why include it in a bug fix labeled add upstream patches? Why did you only include a link to your repo rather than a diff against the current Arch PKGBUILD with the changes you wanted, split by topic?


"Dropping support for kernels before 5.10.1 a separate issue." It was my choice, you don't need it. I have the best support for modern hardware and new features.
For me, the main concern is performance.
As noted previously how is anyone else supposed to know which choices you intend just for your repo and which you intend for Arch when you do not split them as such?

[1] https://github.com/h0tc0d3/arch-packages/commit/5f7ee6518c71afa3a356f2a3b6fe693139449992

"you do not split them as such?" Yes.


After some tests, removed nscd, removed se linux patches, add amd patches, replace C.UTF-8 patch with more complex newer patch
https://sourceware.org/git/?p=glibc.git;a=commit;h=736019081977706528bda62e2c156043ca59594a

Also:
--disable-nscd # Deprecated
--disable-cet
--disable-stackguard-randomization # BZ #27872 Commit f294306ba1385b096f4e4cac9146a989f1e6d1c0
--disable-lock-elision

https://github.com/h0tc0d3/arch-packages/tree/master/glibc


Rebuild of the kernel is required, for some reason perf showed unresolved symbols. Kernel rebuild fixit.
I think it has something to do with the removal of the nscd code.

There are now some patched CVEs fixed in the 2.33 branch, too; any chance someone can pick up toolchain maintenance?

https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.33/master