stefantalpalaru repo

[stefantalpalaru]

> Since I am not an English native speaker, I sometimes use DeepL for translations; additionally Google Translator for important things.

English is my third language, out of four, so I understand the struggle. What I do not understand is how you ended up moderating an English language forum.

What qualified you for this position of power? Clearly not your mastery of the English language, if you still rely on robo-translation and see no problem with it. Could it be that, when you're part of the club, competence is irrelevant?

I suspect this mechanism plays an important part in rejecting outside contributions. Core Gentoo devs are, on some level, aware of their shortcomings as expert beginners and they band together in order to reject any criticism. In this framework, any outside contribution is a form of criticism and needs to be ignored or outright shut down. Anything else would be an admission of error and that would undermine the illusion of infallibility that binds club members together.

> The biggest disagreement seems to boil down to which EAPIs are supported and which are not.

No, it's the general incompetence of core Gentoo devs and all the behaviour stemming from that. Let me illustrate with an example (one of thousands): the sibling packages "sci-libs/caffe2" and "sci-libs/pytorch".

On December 22, 2022 I forked caffe2 to my public overlay in order to fix CUDA support - quite an important feature for PyTorch. Strangely enough, CUDA support was supposedly added to the main Gentoo repo on July 3rd - but it could not have worked, so it was "added" without even trying to build it with that USE flag, let alone test it by running an example. I also reported the problem, along with my fix, to the Gentoo bug tracker. The fix was applied in the main Gentoo repo only on February 27, 2023 - so it took over two months to fix a problem when the patch was already available.

In April 2024, a new version of "dev-util/nvidia-cuda-toolkit" appeared in the main tree and caffe2 failed to build with it. I located an upstream patch and an Arch Linux one that fixed the problem. Added them to my overlay, on April 4th, and tested them properly. Gentoo devs decided to restrict the supported nvidia-cuda-toolkit versions instead, which is a minor nuisance for those wanting the latest bug fixes and features there. What's more interesting is how long that avoidable restriction stayed in place - long after PyTorch upstream fixed its compatibility problem on July 24, by releasing 2.4.0. When did Gentoo devs remove that restriction? On October 11.

But that's just them being slow to react, right? Maybe they just don't personally care about the package so it's not a priority. Let's look at what they did when caffe2 failed to build when "dev-libs/sleef" missed one of these CPU_FLAGS_X86: avx, avx2, avx512f. First, they misunderstood the problem as being just an unavoidable AVX512 dependency, so they required sleef to be built with the corresponding USE flag. That was not enough, users kept reporting build failures, so they... required sleef to be built with all of its CPU_FLAGS_X86 enabled, for good measure.

What this shows is an inability to dig into PyTorch's build system to see what is going on and, instead of solving the root cause in an elegant way, throwing shit at the wall to see if it sticks. PyTorch only cares about sleef's support for AVX, AVX2 and AVX512. Nothing else. These dependencies are conditional on CMake variables, on PyTorch's side. It's not pretty, it's not documented, but it works and it allows us to let Gentoo users set whatever CPU_FLAGS_X86 they need, instead of blindly enabling all of them.

Now imagine seeing this level of incompetence all the time, for many years, and you will understand my "tone" when dealing with them.

> You must have me confused with someone else, because I've never banned anyone!

I see all of you Gentoo devs as an amorphous blob - a rubber wall I hit every time I try to help Gentoo users. You are the obstacle I need to work around, in order to reach them.

[pietinger]

[szatox]

Look, I get that you're tired and frustrated, and there certainly were/are things I'm not completely happy about, but ultimately "done" beats "perfect".
I don't think things are even close to being as bad as you portray them. After all, Gentoo's been dying for like 20 years by now and it's still kicking. With such utterly incompetent devs it absolutely wouldn't be possible. Overall I'd say it working pretty well.
Hell, you don't think that either. You'd have given up a long time ago if you did.

[stefantalpalaru]

> Maybe because I'm not an asshole

Yes, that's exactly it! You join the club by kissing the arses of existing members, and then you get to lord over those arsehole peasants. It's a great social mechanism for your local political party section, but it clearly does not work when dealing with technical matters, like we do in the software world.

You might be the nicest person in the house, according to your mum, but - when your gross incompetence is harming hundreds of Gentoo users - I get to criticise you.

Don't get mad. Don't remove my overlay from the official list, so "eix -sR ..." no longer shows my packages. Instead, try to also be nice to those your consider your inferiors.

> I'm an old man

But are you a wise one?

[stefantalpalaru]

> ultimately "done" beats "perfect"

No argument there. What I'm arguing against is a set of harmful practices, not those ugly hacks that are "close enough for Jazz".

> Overall I'd say it working pretty well.

Is that why I'm maintaining 906 packages in my overlay?

> People don't like having their time wasted.

Oh, the irony...

[pietinger]

[GDH-gentoo]

[Zucca]

[Hu]

I find the origin of this dispute interesting, since stefantalpalaru started it by making two mistakes. The first mistake was trying to fight against the inevitable janitorial work of a rolling release. EAPI 6 was no longer needed in the main tree, so it was removed to simplify the logic in the main tree. The Gentoo maintainers cannot reasonably hold back the tree for the sake of compatibility with every overlay in existence, or even every public overlay. I quickly found EAPI 8 is here! @ 2021-06-16 23:10, so it seems like EAPI 8 is more than 3 years old, and EAPI 7 likely even older. I also found The ultimate guide to EAPI 7 [Posted on 2018-05-03]. That post does call EAPI 7 a more significant update, but even so, it is now more than 6 years old. Therefore, in my opinion, there has been plenty of time for maintained overlays to update to at least EAPI 7, and preferably to EAPI 8. Any overlay still relying on EAPI 6 has ebuilds that are, again, in my opinion, effectively unmaintained. From that, I think a maintained overlay should not have even noticed when EAPI 6 support was removed from the main tree. stefantalpalaru still had EAPI 6 ebuilds when the main tree dropped support. He opted for the workaround of restoring EAPI 6 support, rather than updating the affected ebuilds. Although technically ugly, that would have been fine.

The second, and in my opinion much bigger, mistake was how he communicated his choice of workaround and his opinion of the need for it. If he had instead committed EAPI 6 support with a neutral message like "Add EAPI 6 support to overlay; some ebuilds here still use it.", I doubt the Gentoo maintainers would have paid much attention. Instead, he committed with an insulting message, and kept pressing his attitude at every opportunity.

[stefantalpalaru]

[pietinger]

[logrusx]

[szatox]