Notices by mattst88 :gentoo: (mattst88@fosstodon.org)

@duxsco @mherrb Yeah, I don't think this makes things more secure. I think the people who think disabling IPv6 makes things more secure are probably not that familiar with it and are concerned that they might not be setting up firewalls properly, etc.

@ScottE @mherrb You should have a look at what `--enable-ipv6` actually controls in packages. It's almost always just selecting between code-that-supports-ipv4-and-ipv6 and code-that-supports-ipv4 only.

There's really not an advantage to disabling IPv6 in most packages. If you want to disable IPv6, just turn it off in the kernel. That's the only thing you can reasonably do since many packages unconditionally support IPv6 anyway.

@ScottE @mherrb This is a good example of something I've noticed. If you give users a knob, they'll turn it even if they have no idea what it does.

#Gentoo should provide knobs that make sense and provide some valuable trade-off. Gentoo shouldn't provide knobs that don't do that (and instead just offer additional ways to break your system).

@ScottE @mherrb I'm not aware of any packages breaking if the kernel has IPv6 disabled, regardless of USE=ipv6 status. Are you?

AFAICT, no, `--disable-ipv6` in nearly all packages does what I said before: it selects between code that supports IPv4 & IPv6 and code that only supports IPv4.

@mherrb agreed. This has been a common problem in #Gentoo. Some users think they're making their systems more secure by disabling IPv6 on the small set of packages that allow this, but if there's any benefit at all it should come from just disabling IPv6 in the kernel.

To that end, we have been removing the IPv6 USE flag from packages.

Today's example:

A few years ago the Xserver failed to build on SPARC. @thesamesam fixed it in https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/813. The fix added a necessary bit of code to the build that had been missed in the autotools → meson transition.

Recently we discovered it had stopped compiling at some point when GCC became more strict! (Fix: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1751)

#sparc #xorg #xserver #gcc

@keithp has a saying:

> There are two types of code: tested code and broken code

Early in my career I thought "nah, there's some code that just works and doesn't need maintenance".

But once again his adage proves true.

Another fun #debugging adventure, this time with a happy ending.

A unit test in libXmu failed on x86-32 (https://gitlab.freedesktop.org/xorg/lib/libxmu/-/issues/2). I looked for the typical things first like bad casts but didn't see anything wrong.

I noticed that the unit test program runs two subtests and the log indicates that it completed the first successfully before crashing, but when I ran it under gdb the back trace showed it in the first unit test when the segfault occurred. Very strange.

Single stepping in #gdb, I ultimately came across a longjmp() call (apparently libXt handles errors this way?), and it was this call that triggered the failure.

Turns out each of the subtests checks some exceptional case and expects a function call to fail by longjmp()'ing, but only the first unit test actually prepared for the jump with a call to setjmp().

As a result, when the second subtest triggered its own longjmp() it jumped to the first subtest's function that had already completed!

It's funny seeing someone's "About" on LinkedIn describing themselves as possessing "thought leadership, and excellent communication skills" that you know is actually a massively toxic asshole.

I'm trying to fix a patch to allow #pixman's #ARM #NEON #assembly code to build with clang. They perform a lot of mechanical changes to switch to the "unified" ARM assembly syntax (`.syntax unified`), supported by both #gcc and #clang.

With clang the code builds but fails 3 of the tests in the test suite with what appear to be unaligned accesses. With gcc, the test suite passes before and after the patches.

I've muddled through as much debugging as I can. Any ideas? https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/78#note_2078065

Fine, you want to run #Gentoo built with clang and link-time optimization; linked with mold; using musl libc, libressl, slibtool; maximum hardened CFLAGS; SELinux; all on an aarch64 system runnning in big-endian mode. But please, just use udev.

I like #Gentoo and I enjoy being a developer and package maintainer. The distro offers incredible flexibility to configure your system in any way you like.

But I really wish that didn't attract complete nutters who want to run Linux with mostly modern software but e.g. don't want udev on their systems.

(Similar situations arise with dbus, rust, etc., to say nothing of systemd)

Recent hilarity (from the same user, no less!)

- Package failed to build because `QtCore/qsystemdetection.h` was missing. Turns out the user didn't want anything related to systemd on his system, so he was removing anything that matched *systemd*.
- User wanted to be able to build Xorg with GLX support but *not* DRI, because it would save 0.4 MiB (12.4 MiB on-disk vs 12.4 MiB), and somehow this configuration was supposed to play Steam games.

Any day you have to `git bisect skip` is not a good day. #git