What is happening with glibc and gcc packages?

M-Reimer · 2022-02-01 19:09:51

jancici wrote:

just quick note: I did install manjaro on son laptop some weeks ago and of course, doing updates. there is also glibc 2.33-5. But I dont know more details, son is just using it ;-)

Most probably exactly the same packages as on Arch. I searched their glibc PKGBUILD and they don't publish one. So my guess is that everything, they don't have their own PKGBUILD for, is just "imported" from Arch.

loqs · 2022-02-01 19:26:11

M-Reimer wrote:

Again: I do not use "clean chroot" building. Did you try to just call "makepkg"?

To avoid the build being influenced by the hosts configuration.

M-Reimer wrote:

Maybe glibc never built in this "clean chroot" situation? If so, then this has not changed with my PKGBUILD as I did not change anything there.

Agreed the current glibc does not build either.
Possibly the minimum changes needed are to the repo PKGBUILD are:

diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
index 7651618..b9b2d1c 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -13,7 +13,7 @@ url='https://www.gnu.org/software/libc'
 license=(GPL LGPL)
 makedepends=(git gd lib32-gcc-libs python)
 optdepends=('perl: for mtrace')
-options=(!strip staticlibs)
+options=(!strip staticlibs !lto)
 #_commit=3de512be7ea6053255afed6154db9ee31d4e557a
 #source=(git+https://sourceware.org/git/glibc.git#commit=$_commit
 source=(https://ftp.gnu.org/gnu/glibc/glibc-$pkgver.tar.xz{,.sig}
@@ -85,7 +85,7 @@ build() {
   echo "rootsbindir=/usr/bin" >> configparms
 
   # remove fortify for building libraries
-  CPPFLAGS=${CPPFLAGS/-D_FORTIFY_SOURCE=2/}
+  CFLAGS=${CFLAGS/-Wp,-D_FORTIFY_SOURCE=2/}
 
   #
   CFLAGS=${CFLAGS/-fno-plt/}

M-Reimer wrote:

I compiled my PKGBUILD with an more or less unchanged up-to-date stock makepkg.conf. I just switched back the resulting package format to tar.xz because of ... personal preference.

If your makepkg.conf is up-to-date stock except for compression selection does it not have lto enabled?

M-Reimer wrote:

If I compare your error message to the error message of @kjtsanaktsidis then the reason is that LTO is enabled. Can you try if it helps to disable this in the PKGBUILD (add !lto to the options= array in the PKGBUILD)? If this helps I would add this in my repo. I don't want to change too much in software that I don't know in depth so if !lto does the trick I would prefer this over trying to fiddle something together to make building with lto enabled work.

I stated the cause was lto in post #38. So yes I have already tested that.
Edit:
@afader what if you use the standard CFLAGS or at least reduce the optimization level to 2?

Last edited by loqs (2022-02-01 19:30:37)

M-Reimer · 2022-02-01 19:33:48

loqs wrote:

To avoid the build being influenced by the hosts configuration.

That's why I have a virtual Arch setup in Virtual Box. I have a snapshot directly after installing and updating for the first time and I regularly restore to this. After some time I usually restore to the snapshot, do a full system update, and create a new snapshot.

loqs wrote:

If your makepkg.conf is up-to-date stock except for package format does it not enabled lto?

No: https://github.com/archlinux/svntogit-p … g.conf#L94
For whatever reason the config installed for building "on host" is different to the config used for the "clean chroot" build tools.

loqs wrote:

I stated the cause was lto in post #38. So yes I have already tested that.

I've just added this to my PKGBUILD. https://github.com/M-Reimer/glibc-PKGBU … cc4b34aa8a

Probably I should also just drop the whole "check()" routine. That's just wasted time if it never causes errors for failed checks.

loqs · 2022-02-01 19:43:45

M-Reimer wrote:

loqs wrote:
If your makepkg.conf is up-to-date stock except for package format does it not enabled lto?
No: https://github.com/archlinux/svntogit-p … g.conf#L94
For whatever reason the config installed for building "on host" is different to the config used for the "clean chroot" build tools.

I thought the pacman supplied makepkg.conf gained lto when with the last FLAGS update. My mistake.

If you want to try release/2.33/master again this is diffed against the repo PKGBUILD

diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
index 7651618..02c5c22 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -7,55 +7,33 @@
 pkgbase=glibc
 pkgname=(glibc lib32-glibc)
 pkgver=2.33
-pkgrel=5
+pkgrel=5.1
 arch=(x86_64)
 url='https://www.gnu.org/software/libc'
 license=(GPL LGPL)
 makedepends=(git gd lib32-gcc-libs python)
 optdepends=('perl: for mtrace')
-options=(!strip staticlibs)
-#_commit=3de512be7ea6053255afed6154db9ee31d4e557a
-#source=(git+https://sourceware.org/git/glibc.git#commit=$_commit
-source=(https://ftp.gnu.org/gnu/glibc/glibc-$pkgver.tar.xz{,.sig}
+options=(!strip staticlibs !lto)
+_commit=3e2a15c666e40e5ee740e5079c56d83469280323 # release/2.33/master glibc-2.33-108-g3e2a15c666
+source=(git+https://sourceware.org/git/glibc.git#commit=$_commit
+#source=(https://ftp.gnu.org/gnu/glibc/glibc-$pkgver.tar.xz{,.sig}
         locale.gen.txt
         locale-gen
         lib32-glibc.conf
-        sdt.h sdt-config.h
-        bz27343.patch
-        0001-nptl_db-Support-different-libpthread-ld.so-load-orde.patch
-        0002-nptl-Check-for-compatible-GDB-in-nptl-tst-pthread-gd.patch
-        0003-nptl-Do-not-build-nptl-tst-pthread-gdb-attach-as-PIE.patch)
+        sdt.h sdt-config.h)
 validpgpkeys=(7273542B39962DF7B299931416792B4EA25340F8 # Carlos O'Donell
               BC7C7372637EC10C57D7AA6579C43DFBF1CF2187) # Siddhesh Poyarekar
-md5sums=('390bbd889c7e8e8a7041564cb6b27cca'
-         'SKIP'
+md5sums=('SKIP'
          '07ac979b6ab5eeb778d55f041529d623'
          '476e9113489f93b348b21e144b6a8fcf'
          '6e052f1cb693d5d3203f50f9d4e8c33b'
          '91fec3b7e75510ae2ac42533aa2e695e'
-         '680df504c683640b02ed4a805797c0b2'
-         'cfe57018d06bf748b8ca1779980fef33'
-         '78f041fc66fee4ee372f13b00a99ff72'
-         '9e418efa189c20053e887398df2253cf'
-         '7a09f1693613897add1791e7aead19c9')
+         '680df504c683640b02ed4a805797c0b2')
 
 prepare() {
   mkdir -p glibc-build lib32-glibc-build
 
-  [[ -d glibc-$pkgver ]] && ln -s glibc-$pkgver glibc 
-  cd glibc
-
-  # commit c3479fb7939898ec22c655c383454d6e8b982a67
-  patch -p1 -i "$srcdir"/bz27343.patch
-
-  # nptl_db: Support different libpthread/ld.so load orders (bug 27744)
-  patch -p1 -i "$srcdir"/0001-nptl_db-Support-different-libpthread-ld.so-load-orde.patch
-
-  # nptl: Check for compatible GDB in nptl/tst-pthread-gdb-attach
-  patch -p1 -i "$srcdir"/0002-nptl-Check-for-compatible-GDB-in-nptl-tst-pthread-gd.patch
-
-  # nptl: Do not build nptl/tst-pthread-gdb-attach as PIE
-  patch -p1 -i "$srcdir"/0003-nptl-Do-not-build-nptl-tst-pthread-gdb-attach-as-PIE.patch
+  [[ -d glibc-$pkgver ]] && ln -s glibc-$pkgver glibc || : 
 }
 
 build() {
@@ -85,7 +63,7 @@ build() {
   echo "rootsbindir=/usr/bin" >> configparms
 
   # remove fortify for building libraries
-  CPPFLAGS=${CPPFLAGS/-D_FORTIFY_SOURCE=2/}
+  CFLAGS=${CFLAGS/-Wp,-D_FORTIFY_SOURCE=2/}
 
   #
   CFLAGS=${CFLAGS/-fno-plt/}

M-Reimer · 2022-02-01 19:58:46

Do the patches, that are in the repo PKGBUILD, no longer apply? Or are they actually part of release/2.33/master? I wouldn't feel good with just leaving them out.

progandy · 2022-02-01 20:09:14

M-Reimer wrote:

Do the patches, that are in the repo PKGBUILD, no longer apply? Or are they actually part of release/2.33/master? I wouldn't feel good with just leaving them out.

You can look for them in this list: https://sourceware.org/git/?p=glibc.git … .33/master

loqs · 2022-02-01 20:16:29

M-Reimer wrote:

Do the patches, that are in the repo PKGBUILD, no longer apply? Or are they actually part of release/2.33/master? I wouldn't feel good with just leaving them out.

I have listed the matching commits off release/2.33/master below each patch

bz27343.patch

17f0ff097887008b2d3dca270c8ffbb4b43a8749 see also 3e880d733753183696d1a81c34caef3a9add2b0c

0001-nptl_db-Support-different-libpthread-ld.so-load-orde.patch

ea299b62e83cc38b0d910bbd1a879f7d1f836e96

0002-nptl-Check-for-compatible-GDB-in-nptl-tst-pthread-gd.patch

36783141cf090412e3e6f042f25f7f6c63d6a14a

0003-nptl-Do-not-build-nptl-tst-pthread-gdb-attach-as-PIE.patch

3f5080aedd164c1f92a53552dd3e0b82ac6d2bd3

NuSkool · 2022-02-01 21:13:37

Sorry OT but it was mentioned in this thread.

Allan wrote:

No - me returning to packaging just helps patch over the problems of the distro. I'd prefer them to be exposed.

To me, this seems as important as anything else being discussed here. Out of date toolchain doesn't matter if this trend continues due to unresolved issues behind the scenes.

It's alarmingly serious to me, I'm out of the loop and is there any way to get up to speed on this? What can we as users do to help this situation?

kjtsanaktsidis · 2022-02-02 05:40:30

Allan wrote:

To be blunt, if you can not solve that error, then you are no help packaging glibc. The solution is readily found by searching for the error message...

Just FYI, I found this phrasing pretty offensive. Perhaps not a great way to encourage people to pitch in to the Arch project. In any case, I wasn't posting here asking for help in making glibc build on my machine, but rather pointing out that the current PKGBUILD for glibc doesn't work as another data point for "the general state of toolchain maintenance". Seemed relevant because a lot of the rest of the discussion had been about backporting fixes or upgrading glibc, but I feel like it's also important that the PKGBUILD actually works all the time too, whatever version it's at.

loqs wrote:

Agreed the current glibc does not build either.
Possibly the minimum changes needed are to the repo PKGBUILD are:

The changes around

-D_FORTIFY_SOURCE=2

made sense to me - the format string handling in syslog is one of the things that FORTIFY_SOURCE wraps, and so the attributes from the fortified wrapper, including __attribute__((always_inline)), wound up getting applied to the actual syslog implementation which is very very not inlineable. Compiling glibc itselfwith FORTIFY_SOURCE makes little sense because of this - the wrappers would otherwise conflict with the actual implementation of all the memory & string handling functions.

However, I was _REALLY_ stumped as to why LTO could cause a _preprocessor_ error

gcc ../sysdeps/unix/sysv/linux/x86_64/getcontext.S -c  -U_FORTIFY_SOURCE   -I../include -I/startdir/src/glibc-build/stdlib  -I/startdir/src/glibc-build  -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/linux/x86/include -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/x86/nptl  -I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu  -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86/include -I../sysdeps/x86  -I../sysdeps/ieee754/float128  -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include /startdir/src/glibc-build/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h  -DPIC     -DTOP_NAMESPACE=glibc -DASSEMBLER -fcf-protection -include cet.h -g -fdebug-prefix-map=/startdir/src=/usr/src/debug -Werror=undef -Wa,--noexecstack   -o /startdir/src/glibc-build/stdlib/getcontext.o -MD -MP -MF /startdir/src/glibc-build/stdlib/getcontext.o.dt -MT /startdir/src/glibc-build/stdlib/getcontext.o
../sysdeps/unix/sysv/linux/x86_64/getcontext.S:121:5: error: "SIG_BLOCK" is not defined, evaluates to 0 [-Werror=undef]
  121 | #if SIG_BLOCK == 0
      |     ^~~~~~~~~
cc1: some warnings being treated as errors

I hunted around a bit at what's going on here. The _actual_ problem is in a script called

scripts/gen-as-const.py

which is used to generate header files containing just #defines from other header files. That script is used to generate, amongst other things, ucontext_i.h, which is where getcontext.S is expecting to find a definition for SIG_BLOCK. The way that script works, however, is by:
* Generating a C source file with a function containing statements like

asm("@@@value@@@%%0" : : \"i\" ((long int) THE_VALUE)

,
* Compiling that C source file down to assembly with, essentially, "gcc $CFLAGS -S -o test.s test.c"
* Parsing out the emitted assembly into Python to find out what the value of THE_VALUE was, according to the C compiler,
* And generating a C header file with those values

However, when -flto is in CFLAGS, the asm statements don't actually get emitted into test.s. Instead, test.s is just a few .sections full of .ascii data, which would presumably be codegened into actual code at link time. The gen-as-const.py script of course has no idea how to actually parse that, so ucontext_i.h winds up empty, leading to the preprocessor error we see.

Of course, glibc won't build with LTO even if this issue in gen-as-const.py is patched, but for more normal reasons that actually look like they have something to do with LTO (e.g.):

gcc pthread_getattr_np.c -c -std=gnu11 -fgnu89-inline  -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -flto -Wp,-D_FORTIFY_SOURCE=2 -Wall -Wwrite-strings -Wundef -fmerge-all-constants -frounding-math -fstack-protector-strong -Wstrict-prototypes -Wold-style-definition -fmath-errno   -fPIC -fcf-protection   -ftls-model=initial-exec   -U_FORTIFY_SOURCE   -I../include -I/home/kj/glibc/build/nptl  -I/home/kj/glibc/build  -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/linux/x86/include -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/x86/nptl  -I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu  -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86/include -I../sysdeps/x86  -I../sysdeps/ieee754/float128  -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include /home/kj/glibc/build/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h  -DPIC -DSHARED     -DTOP_NAMESPACE=glibc -o /home/kj/glibc/build/nptl/pthread_getattr_np.os -MD -MP -MF /home/kj/glibc/build/nptl/pthread_getattr_np.os.dt -MT /home/kj/glibc/build/nptl/pthread_getattr_np.os
In file included from ../sysdeps/x86/ldsodefs.h:65,
                 from ../sysdeps/gnu/ldsodefs.h:46,
                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
                 from pthread_getattr_np.c:29:
../sysdeps/generic/ldsodefs.h:701:14: error: ‘__libc_stack_end’ causes a section type conflict with ‘_rtld_global_ro’
  701 | extern void *__libc_stack_end
      |              ^~~~~~~~~~~~~~~~
../sysdeps/generic/ldsodefs.h:678:36: note: ‘_rtld_global_ro’ was declared here
  678 | extern const struct rtld_global_ro _rtld_global_ro
      |                                    ^~~~~~~~~~~~~~~
make[2]: *** [../o-iterator.mk:9: /home/kj/glibc/build/nptl/pthread_getattr_np.os] Error 1

Some reading suggests that glibc isn't supposed to work with LTO because "glibc makes extensive use of separate compilation as a barrier to information flow to do low-level things that are not valid C when the separate translation units are visible to the compiler at the same time" (https://sourceware.org/bugzilla/show_bug.cgi?id=19649) so disabling it makes sense.

---------------------

But really, the main point is this:

NuSkool wrote:

To me, this seems as important as anything else being discussed here. Out of date toolchain doesn't matter if this trend continues due to unresolved issues behind the scenes.
It's alarmingly serious to me, I'm out of the loop and is there any way to get up to speed on this? What can we as users do to help this situation?

I'll admit I'm not at all part of the Arch community, so I'm on the outside here providing some unsolicited advice, but it really seems like there's several underlying reasons for this situation that need to be looked at -

* When the defaults in pacman were changed to add LTO/fortify source, should it have been verified that the toolchain still built successfully afterwards?
* Why has the glibc maintainer not released a new toolchain build based on glibc 2.34? What resources, help, whatever are they missing to be able to do this?
* Who is supposed to be responsible for finding out about security vulns in core packages like glibc, and making sure patches are applied? I gather that in the first instance that's the maintainer's responsibility, but https://security.archlinux.org/AVG-1621 - that list is slightly concerning and for a core component like glibc, maybe there should have been some follow up from the security team at some point?
* From what I gather here, and from the recent thread from the mailing lists about x86_64_v3, it seems that a core contributor to all of the above is a lack of automation around package updates and rebuilds?

I suspect it boils down to "time and resources". In which case, what can users do to step up and help?

Allan · 2022-02-02 06:14:19

kjtsanaktsidis wrote:

Allan wrote:
To be blunt, if you can not solve that error, then you are no help packaging glibc. The solution is readily found by searching for the error message...
Just FYI, I found this phrasing pretty offensive. Perhaps not a great way to encourage people to pitch in to the Arch project.

I did say I was being blunt... To clarify, glibc as a package does not stand alone - it interacts with other parts of the toolchain (gcc, binutils, linux-api-headers). Getting glibc to build is one of the easier aspects to maintaining the toolchain.

kjtsanaktsidis wrote:

In which case, what can users do to step up and help?

Given a user posted a complete set of working packages for the toolchain (which included updates and a lot of improvements) about 5 months ago on the bugtracker, a pessimist would conclude there is nothing to be done in this particular case.

dogknowsnx · 2022-02-02 11:06:56

kjtsanaktsidis wrote:

I'll admit I'm not at all part of the Arch community

Well, you're not only taking part in this discussion, but you're also offering you're help (thank you and appreciation from my side), which makes you very much part of this community, imho.

I'dont know @Allan personally, but given his long lasting dedication to Arch (again, thank you and appreciation from my side) I'm pretty sure his intentions weren't to discourage anybody from contributing, rather than emphasizing the reality of what it means to maintain core packages (on a voluntary basis) from a "been there done that" perspective.

Thank you and my appreciation to everybody helping to keep this ship floating present and past - in case I didn't make this point clear enough, already

(On a sidenote, I'm currently patching mesa for two different devices, one of which I wouldn't even be able to use, having reported the issues upstream where they are being worked on, Arch's excellent documentation has helped me as an average not-techie Joe to maintain running and stable systems. Just to point out one of the many great things Arch has to offer).

afader · 2022-02-02 17:52:06

Allan wrote:

Given a user posted a complete set of working packages for the toolchain (which included updates and a lot of improvements) about 5 months ago on the bugtracker, a pessimist would conclude there is nothing to be done in this particular case.

If there's already a complete set of working packages - can we at least update messaging or documentation to let users know if that if they want to patch these vulns, they can use the packages you describe? Where would I begin in finding the packages, and what are the caveats? Do I need to ditch multilib, potentially making certain programs e.g. Steam or Wine unusable? I haven't dual-booted Windows in a good few years and I wasn't wanting to, since I can run everything I want to run on Linux nowadays.

5 months is a pretty long lag time for feedback or for someone to take it on themselves to carry through the needed work. For those of us who are technical enough to understand how to edit a PKGBUILD or simple bash scripts, or understand gdb stack traces, but don't have the specialized knowledge needed to build the toolchain specifically, what is our recourse? Just use Debian, Gentoo or Fedora?

I've been using Arch for almost a decade primarily because it's a good balance of functionality, security, stability, customization, and a solid community. Is the community dying or is there something amiss among the leadership or trusted users? If so what can be done about this? It's not just Glibc. I appreciate the do-it-yourself mentality and the blunt directness of Arch contributors. Nobody owes anyone a contribution. But I'd be willing to donate or sponsor a volunteer's time to actually shore up some security issues so I can know that my system isn't vulnerable. It's 2022 and there are indeed Linux malware targets, UEFI bootkits, all kinds of scary shit out there.

Trilby · 2022-02-02 17:59:59

afader wrote:

Is the community dying or is there something amiss among the leadership or trusted users?

Other than the inmates running the asylum?

agapito · 2022-02-03 08:07:02

The GNU C Library version 2.35 is now available: https://sourceware.org/pipermail/libc-a … 36040.html

Allan · 2022-02-03 10:17:24

afader wrote:

]If there's already a complete set of working packages - can we at least update messaging or documentation to let users know if that if they want to patch these vulns, they can use the packages you describe?

They were working 5 months ago when submitted. Our buildflags have changed since then, making them not working now.

johnyan · 2022-02-03 14:31:37

Hello,

Is there a documented process on how the community helpers could participate/join the core team to help issues like this?

I am a C/C++ developer with many years of experience in Linux and open source and recently join the Arch family by running arch as my daily driver.
If there's help needed, I would be happy to offer some of my free time.

Thanks.

WorMzy · 2022-02-03 14:43:48

https://wiki.archlinux.org/title/Gettin … _Developer

M-Reimer · 2022-02-03 17:02:12

So probably something happened which was discussed in some internal forum or mailing list. So no user can actually know what's wrong in the Arch team.

I wonder what the plannings for the near future are. IMHO a distribution which no longer manages to get security updates to users is dead. Security has to be top priority. Then there is a big gap and then follows "up to date feature updates".

Is there already some fork in the works which reuses tools like PKGBUILD or pacman?

8BitAce · 2022-02-03 18:16:18

I've been trying to be more active in the community when I can. Submitting some (very niche) packages to the AUR, donating where I can, keeping up with the public mailing lists, etc.

It's rather unnerving seeing comment in threads like this about the core team apparently being run by "asylum patients" without any further explanation. What's the point of having a community-centered distro if the community is left out of these discussions? Why have people who are apparently "in-the-know" giggle about it on the public forums as if it's some secret club?

seth · 2022-02-03 20:25:49

I think Trilby was just making an off-hand joke about some peers and not necessarily in relation to the situation related to this topic.

I guess at some point somebody will have to make a more straight forward statement on the situation.
Both, because one cannot expect assistance w/ a problem that's not even revealed and also because the innuendo will keep triggering scared to frustrated responses.
Until then, all one can do is to not freak out about "maybes" and wait. If the development makes using the distro individually unbearable, one will have to decide whether or not to look out for a new favorite.

No, idk what the deeper problem is.
I read Barts goodbye message and he seemed unhappy w/ either the state or direction of the distro and that makes me wonder whether that's a widerspread sentiment - and try to not worry about that.
There's only one thing certain about the future: it will eventually come.

johnyan · 2022-02-03 22:30:03

Has anyone contacted the glibc maintainer Mr Giancarlo Razzolini? Did he make any comments on the state of development? Is it possible for us to see any PR opened for that matter?

Morn · 2022-02-03 23:01:59

seth wrote:

If the development makes using the distro individually unbearable, one will have to decide whether or not to look out for a new favorite.

Unfortunately the selection of reasonably popular BSD-like distros with a huge (via AUR) number of supported packages is rather slim; it's really just Arch and Slackware. And Slackware-current is also stuck with glibc 2.33, so no improvement there.

I really hope the Arch developers can work out their issues somehow…

Trilby · 2022-02-03 23:09:05

seth wrote:

I think Trilby was just making an off-hand joke...

I've made more than a few jokes before that were taken far too seriously. So I guess it's only fair that a serious comment is occasionally seen as a joke. While tongue-in-cheek it is a genuine view. But it is most certainly not by someone "in the know" giggling about anything.

My thoughts on this are not - and could not be - in any way informed by my former role in the forums. I've never been active in any other way (not on the bug tracker, wiki, or certainly not any development/TU work, I don't even follow the mailing lists). My views here are just what I take in as a community member seeing the culture of the community shift over time and seeing skilled competent people leaving, "downsizing" their involvement, or being forced out of roles in the dev team, bug tracker, etc due to those shifts in culture. I am most definitely not giggling. I'm mourning.

However, even if declining, or with some parts in disrepair, arch is a far better fit for my tastes than any other distro out there. So I stick around. And I hope the cultural shifts may be temporary, or perhaps swing as a pendulum and self-correct. I hope.

Last edited by Trilby (2022-02-03 23:15:23)

cowlick · 2022-02-03 23:11:47

Morn wrote:

seth wrote:
If the development makes using the distro individually unbearable, one will have to decide whether or not to look out for a new favorite.
Unfortunately the selection of reasonably popular BSD-like distros with a huge (via AUR) number of supported packages is rather slim; it's really just Arch and Slackware. And Slackware-current is also stuck with glibc 2.33, so no improvement there.
I really hope the Arch developers can work out their issues somehow…

I really hope arch developers cannot work out their issues.

08d09 · 2022-02-04 00:23:36

Sorry if I missed a post but is there any official work being done on the toolchain? According to glibc's page there is a maintainer but something else must be going on judging upon the current situation. It would be nice to know it there's a maintainer at all or if he's having issues with the new versions.

Allan's packages are very helpful and a nice alternative but they will cause some problems if you use wine and dkms. Downgrading gcc and binutils for every dkms rebuild or just using a self-compiled kernel is possible but not convenient at all. At least wine seems to work fine if you force install lib32-glibc without downgrading glibc (it requires glibc2.33) so a dummy package providing glibc2.33 alongside allan's glibc2.35 could work as a workaround until the official package gets updated, right?

Arch Linux

#51 2022-02-01 19:09:51

Re: What is happening with glibc and gcc packages?

#52 2022-02-01 19:26:11

Re: What is happening with glibc and gcc packages?

#53 2022-02-01 19:33:48

Re: What is happening with glibc and gcc packages?

#54 2022-02-01 19:43:45

Re: What is happening with glibc and gcc packages?

#55 2022-02-01 19:58:46

Re: What is happening with glibc and gcc packages?

#56 2022-02-01 20:09:14

Re: What is happening with glibc and gcc packages?

#57 2022-02-01 20:16:29

Re: What is happening with glibc and gcc packages?

#58 2022-02-01 21:13:37

Re: What is happening with glibc and gcc packages?

#59 2022-02-02 05:40:30

Re: What is happening with glibc and gcc packages?

#60 2022-02-02 06:14:19

Re: What is happening with glibc and gcc packages?

#61 2022-02-02 11:06:56

Re: What is happening with glibc and gcc packages?

#62 2022-02-02 17:52:06

Re: What is happening with glibc and gcc packages?

#63 2022-02-02 17:59:59

Re: What is happening with glibc and gcc packages?

#64 2022-02-03 08:07:02

Re: What is happening with glibc and gcc packages?

#65 2022-02-03 10:17:24

Re: What is happening with glibc and gcc packages?

#66 2022-02-03 14:31:37

Re: What is happening with glibc and gcc packages?

#67 2022-02-03 14:43:48

Re: What is happening with glibc and gcc packages?

#68 2022-02-03 17:02:12

Re: What is happening with glibc and gcc packages?

#69 2022-02-03 18:16:18

Re: What is happening with glibc and gcc packages?

#70 2022-02-03 20:25:49

Re: What is happening with glibc and gcc packages?

#71 2022-02-03 22:30:03

Re: What is happening with glibc and gcc packages?

#72 2022-02-03 23:01:59

Re: What is happening with glibc and gcc packages?

#73 2022-02-03 23:09:05

Re: What is happening with glibc and gcc packages?

#74 2022-02-03 23:11:47

Re: What is happening with glibc and gcc packages?

#75 2022-02-04 00:23:36

Re: What is happening with glibc and gcc packages?

Board footer