The code is getting arcane. This is to support debian-sid. I am very ignorant of the Linux eco-system, and my naive question is: Do we need to support debian-sid? By a quick search, sid is said to be very unstable version of debian and is never released for end users. So it seems to make little sense that we should write such arcane code to support it...

Code in ci pipelines does not have to be pretty but should be clean enough to be maintainable by future maintainers...

it's probably a short-lived bug in sid, and I say - send them a bug report, but don't bother with a dodgy workaround

Actually, debian-sid was just an example, sorry for leading both of you on the wrong track. I'll update the ticket description

Code in ci pipelines does not have to be pretty but should be clean enough to be maintainable by future maintainers...

Indeed. I've added a detailed comment.

Thank you!

hmm, isn't "minimal" something we define? install packages with pkill in, done ...

isn't "minimal" something we define?

It's something that we have defined, but not arbitrarily. It consists of the packages needed for bootstrapping and building the Sage distribution.

on Debian pkill is in procps

so let's add procps to the list of CI Debian packages

The major point of the "minimal" package configuration is to test that the documented minimal list of build requirements works. Adding random stuff to it weakens this purpose.

is pkill only used in CI? then why not just add it.

I just explained it. If we add it, then the CI no longer tests what it should test.

pkill is a part of testing infrastructure.

I just explained it. If we add it, then the CI no longer tests what it should

I just explained it. If we add it, then the CI no longer tests what it should test.

No, pkill is not part of Sage, it's a part of testing infrastructure. I don't see why you insist on testing infrastructure to be broken, doing dodgy things with /proc and what not instead. Negative review.

Please, Dima, let's increase the level of discourse here.

dodgy things with /proc and what not

/proc is the stable interface of the Linux kernel for precisely this information. I'm accessing it with standard Unix command line tools. If you have a concern about this, please be more specific.

Do we have a mechanism to resolve the dead-lock state of a PR like this one? I don't think so. As we have several such PRs (where labelling wars are going on) by now, the lack of the mechanism seems seriously hinder the progress of our project.

I know that Matthias does not like poll as the mechanism. So I suggest a mild alternative (automatic poll) to it. First let me be clear that I designed the alternative mechanism to be advantageous to the author.

(1) A PR is in dead-lock state when there are "Approving" reviews and "Requesting changes" (disapproving) reviews that appear on the "Reviewers" section on the upper right side, and the author is not accepting the work items or the reasons of the disapproving reviews. If a PR is in dead-lock state, we put both "needs work" (or "needs info") and "needs review" label to the PR.

(2) If a PR is in dead-lock state, other people may come and give their own "Approving" or "Disapproving" reviews using the GitHub review system.

(3) If a week has passed in dead-lock state with more "Approving" reviews than "Disapproving" reviews, the author attains the right to put "positive review" label to the PR, and the dead-lock state is resolved.

If both of you agree, then I may post this proposal to sage-devel to get community-wide approval.

Edit: "negative review" was replaced with "disapproving review"

[...] "Requesting changes" (negative) reviews [...]

I think I have to caution that using the phrase "negative review" in drafting such rules for PRs is already highly problematic.

The search https://github.com/sagemath/sage/issues?q=sort%3Aupdated-desc+%22negative+review%22 shows that this phrase has not been used in Sage development discussions since around 2010, until its reintroduction this year.

This phrase basically denies that:

• the standard in our community is to conduct technical discussions of the necessary depth to find the right solutions, to debate in good faith, and to generally use a constructive, collegial approach.

Instead, this phrase suggests that decisions can be taken just based on individuals being "for" or "against" something; that opinions matter but reasons do not. Designing conflict resolution based on counting "positive reviews" against "negative reviews" reinforces this.

As I see it, the cause of labelling war is "political" instead of "technical". If the issue is "technical", there is a better and right solution that we can converge into by more discussion. When the issue is "political", there are more than one good solutions (or bad solutions depending on your point of view) and it's a matter of choice to choose one rather than the other other. Then how do we know that an issue is "political"? Practically we should admit that the issue is "political" when we go on labelling war instead of doing discussion.

We may use "Disapproving review" instead of "negative review" if you prefer.

By the way, I am abusing "Requesting changes" as a means to express "Disapproving" review as there is no other alternative way.

dodgy things with /proc and what not

/proc is the stable interface of the Linux kernel for precisely this information. I'm accessing it with standard Unix command line tools. If you have a concern about this, please be more specific.

pkill is much more standard than /proc. It's present on all the systems I looked at, including even OpenBSD (which, by the way, has no /proc).

Besides, you never explained how getting pkill installed on CI is going to make CI not as good. There is absolutely no need to get into low-level system programming here.

My proposal to fix this issue is as follows:

diff --git a/build/pkgs/_prereq/distros/alpine.txt b/build/pkgs/_prereq/distros/alpine.txt
index 159c452cf30..350cc8e2c26 100644
--- a/build/pkgs/_prereq/distros/alpine.txt
+++ b/build/pkgs/_prereq/distros/alpine.txt
@@ -9,3 +9,4 @@ gcc
 g++
 ca-certificates
 coreutils
+procops
diff --git a/build/pkgs/_prereq/distros/arch.txt b/build/pkgs/_prereq/distros/arch.txt
index 9b9bf09e7e2..f2631868f4e 100644
--- a/build/pkgs/_prereq/distros/arch.txt
+++ b/build/pkgs/_prereq/distros/arch.txt
@@ -8,3 +8,4 @@ bc
 gcc
 # Needed for 4ti2:
 which
+procps
diff --git a/build/pkgs/_prereq/distros/conda.txt b/build/pkgs/_prereq/distros/conda.txt
index d76388ce7bb..26fc374139d 100644
--- a/build/pkgs/_prereq/distros/conda.txt
+++ b/build/pkgs/_prereq/distros/conda.txt
@@ -5,3 +5,4 @@ perl
 python
 tar
 bc
+procps
diff --git a/build/pkgs/_prereq/distros/debian.txt b/build/pkgs/_prereq/distros/debian.txt
index 50be6ac7e0b..e322a08ba2e 100644
--- a/build/pkgs/_prereq/distros/debian.txt
+++ b/build/pkgs/_prereq/distros/debian.txt
@@ -21,6 +21,7 @@ python3
 tar
 bc
 gcc
+procps
 # On debian buster, need C++ even to survive 'configure'. Otherwise:
 # checking how to run the C++ preprocessor... /lib/cpp
 # configure: error: in `/sage':
diff --git a/build/pkgs/_prereq/distros/fedora.txt b/build/pkgs/_prereq/distros/fedora.txt
index b35d7f64faf..250578c31ef 100644
--- a/build/pkgs/_prereq/distros/fedora.txt
+++ b/build/pkgs/_prereq/distros/fedora.txt
@@ -28,6 +28,7 @@ gcc
 gcc-c++
 # Needed according to embray at https://github.com/sagemath/sage/issues/26964:
 # The need for which comes [...] from MPIR's configure script
+procps
 findutils
 which
 diffutils
diff --git a/build/pkgs/_prereq/distros/gentoo.txt b/build/pkgs/_prereq/distros/gentoo.txt
index 1e26c46cacc..b624ae66e5d 100644
--- a/build/pkgs/_prereq/distros/gentoo.txt
+++ b/build/pkgs/_prereq/distros/gentoo.txt
@@ -18,3 +18,4 @@ dev-libs/libxml2
 sys-apps/findutils
 sys-apps/which
 sys-apps/diffutils
+sys-process/procps
diff --git a/build/pkgs/_prereq/distros/opensuse.txt b/build/pkgs/_prereq/distros/opensuse.txt
index 6f7a11fea47..718028b2557 100644
--- a/build/pkgs/_prereq/distros/opensuse.txt
+++ b/build/pkgs/_prereq/distros/opensuse.txt
@@ -27,3 +27,4 @@ gzip
 # Trac #32368
 findutils
 diffutils
+procps
diff --git a/build/pkgs/_prereq/distros/slackware.txt b/build/pkgs/_prereq/distros/slackware.txt
index 4c957e45264..c093cd0aeb7 100644
--- a/build/pkgs/_prereq/distros/slackware.txt
+++ b/build/pkgs/_prereq/distros/slackware.txt
@@ -16,3 +16,4 @@ flex
 ca-certificates
 libxml2
 cyrus-sasl
+procps
diff --git a/build/pkgs/_prereq/distros/void.txt b/build/pkgs/_prereq/distros/void.txt
index 552b5a415f2..257fdd94161 100644
--- a/build/pkgs/_prereq/distros/void.txt
+++ b/build/pkgs/_prereq/distros/void.txt
@@ -8,3 +8,4 @@ perl
 python3
 tar
 which
+procps

dodgy things with /proc and what not

/proc is the stable interface of the Linux kernel for precisely this information. I'm accessing it with standard Unix command line tools. If you have a concern about this, please be more specific.

pkill is much more standard than /proc. It's present on all the systems I looked at, including even OpenBSD (which, by the way, has no /proc).

Only Linux matters here because this line is executed in a Linux Docker container.

And no, for Linux, pkill is not "more standard" than the /proc, which is exactly the point of this PR, and already demonstrated by the command lines in the PR description.

That it's present on all the systems you looked at is explained by these systems having an installation of many packages.

yes, so why not just add another package?

My proposal to fix this issue is as follows:

[...]
diff --git a/build/pkgs/_prereq/distros/debian.txt b/build/pkgs/_prereq/distros/debian.txt
index 50be6ac7e0b..e322a08ba2e 100644
--- a/build/pkgs/_prereq/distros/debian.txt
+++ b/build/pkgs/_prereq/distros/debian.txt
@@ -21,6 +21,7 @@ python3
 tar
 bc
 gcc
+procps
 # On debian buster, need C++ even to survive 'configure'. Otherwise:
 # checking how to run the C++ preprocessor... /lib/cpp
 # configure: error: in `/sage':
[...]

Yes, I understood that this is what you propose when you said it in #36726 (comment)

By the way, the package name, procps, refers to the fact that this implementation of ps-like tools goes through /proc.

you never explained how getting pkill installed on CI is going to make CI not as good.

I explained it in #36726 (comment), #36726 (comment), #36726 (comment), but I'll elaborate:

1. We document the minimal requirements for installing the Sage distribution from source in _prereq/distros/*.txt (and the additional requirements for bootstrapping first in _bootstrap/distros/*.txt. This is the single source for this documentation; all other places in the documentation are generated from it.

2. That packages in the Sage distribution use restraint regarding the prerequisites that they require is a marker of quality.

   • For example, that we have to require the which tool (https://github.com/sagemath/sage/blob/develop/build/pkgs/_prereq/distros/fedora.txt#L32) is documented as being necessary because of one package. which is a "classic" UNIX utility, of course, but it cannot be expected to be installed on users' systems any more because it has long been superseded by built-in shell commands such as command -v in bash; and moreover it's a tool for interactive use and shouldn't really be used in scripting. So verifying whether which is still needed, to work with upstream to eliminate this requirement, would be an improvement for Sage.
   • We haven't allowed packages in that have unusual requirements. See for example the discussion of jsonschema in Notebook 7, ipykernel 6.27, ipython 8.17 #36129, which in the newest versions would require either a rust compiler, or foregoing our strict from-source compilability policy, or more drastic changes.

3. We cannot rely on tests on developers' machines to make sure that this documentation of the minimal build requirements remains correct -- because developers' machines are typically full of development tools. We have to test it on CI; that's what the CI runs for the -minimal configurations do, in contrast to the -standard configurations.

We need to elect one person to serve in the role of "editor" for all of these disputed PR's. In the past, that would typically be the release manager, but I don't think Volker has the bandwidth to do this. Should we just have some people nominate themselves as candidates, then vote on sage-devel, with the condition that editor term last for a certain amount of time, and we all endorse whatever the editor decides for disputed PR's?

@dimpase writes in #36726 (comment):

I don't have a hostile attitude towards this PR in particular.

I do have a hostile attitude towards the overblown ever-growing pile of vendored packages that Sage the distro is, and associated with it CI's "minimal configurations" nonsense, which only slows everything down, this is true

I think this is as close as we can get to an answer.

@dimpase In private, you are entitled to any attitude whatsoever. But you must stop bringing it to the Sage community. There is nothing that justifies it. And not only is it harmful by itself, but it has already encouraged another abuser.

@dimpase writes in #36726 (comment):

I don't have a hostile attitude towards this PR in particular.

I do have a hostile attitude towards the overblown ever-growing pile of vendored packages that Sage the distro is, and associated with it CI's "minimal configurations" nonsense, which only slows everything down, this is true

I think this is as close as we can get to an answer.

@dimpase In private, you are entitled to any attitude whatsoever. But you must stop bringing it to the Sage community. There is nothing that justifies it. And not only is it harmful by itself, but it has already encouraged another abuser.

@mkoeppe : the abuser here is you, you are trying to shut down any dissent to your designs, not even bothering to answer in any meaningful way why you made such and such questionable choices.

you are trying to shut down any dissent to your designs

That's just another harmful accusation, Dima.

I'll explain something important that seems unclear to you:

• It is the actual conduct, not someone's intentions, that can be harmful. And as members of the Sage community we have the duty to call out harmful conduct when we witness it.
• It is typically not meaningful to make accusations regarding other people's intentions -- simply because you cannot read their minds.

@dimpase writes in #36726 (comment):

we have an alternative solution for the problem at hand, by @tobiasdiez : we can for now merge it instead

This "alternative solution" was introduced in #36726 (comment) with the words:

I've opened #36941 as a concrete counterproposal. It has only two changed lines (or 4 if you are strict) and is very easy to understand, so should make those people happy that like minimal solutions.

For those who did not have a chance to look at what #36941 does: It removes the tests of most minimal configurations from the portability CI, leaving only one. (Hence, it is a further escalation of the disproportionate demands regarding the portability CI, for which I called Tobias out in #36726 (comment))

So this is another good example of mismatched scope, point 2 (a) in #36726 (comment): To "solve" the technical problem in the CI for minimal configurations, it disables them altogether. That's not just disproportionate, but it is also clear that such a change would need a proper discussion. Introducing this as an "alternative solution" creates a false dichotomy: "Either the present PR is merged, or the alternative solution". But the dichotomy has no factual basis: There is simply no need to link these two PRs.

• Merging the present PR does not make it harder to make changes to what platforms are tested in the portability CI.
• So merging the present PR does not need to wait for a discussion regarding the portability CI.

@dimpase writes in #36726 (comment):

we have an alternative solution for the problem at hand, by @tobiasdiez : we can for now merge it instead

This "alternative solution" was introduced in #36726 (comment) with the words:

I've opened #36941 as a concrete counterproposal. It has only two changed lines (or 4 if you are strict) and is very easy to understand, so should make those people happy that like minimal solutions.

For those who did not have a chance to look at what #36941 does: It removes the tests of most minimal configurations from the portability CI, leaving only one.

That's fine in my point of view - it removes the useless cruft of testing these configurations.

(Hence, it is a further escalation of the disproportionate demands regarding the portability CI, for which I called Tobias out in #36726 (comment))

So this is another good example of mismatched scope, point 2 (a) in #36726 (comment): To "solve" the technical problem in the CI for minimal configurations, it disables them altogether. That's not just disproportionate, but it is also clear that such a change would need a proper discussion.

No, why, these minimal configurations are of very questionable value for Sage. They were introduced by you without any discussion on in Sage forums, and disabling most of them is a step in the right direction, in our view.

Why does it need any discussion? If you want, we can discuss whether they are needed, certainly, but at the moment it's something you sneaked in through the back door, and I don't see how a community enforcement is needed to disable them.

It removes the tests of most minimal configurations from the portability CI, leaving only one.

That's fine in my point of view

We already know that you think that, Dima. What do you think is gained by repeating it?

I merely commented on the "further escalation" claim. It's not an escalation, that is what I meant to say.

It's not an escalation, that is what I meant to say.

It is. The previous version was a proposal to "cut the Linux CI to 2-3 platforms" (for the minimal configurations). Reducing it to 1 is the further escalation.

instead of shouting "vandalism" you could have pointed this out.

Happy to add another system or two. Just let me know which ones you would like and I will add them.

@dimpase, above in #36726 (comment) you write:

If you want, we can discuss whether [the minimal configurations] are needed, certainly

Apparently you are missing a very important basic point. Dima, we cannot have such a discussion (or any discussion), because you are refusing to act according to our community's Code of Conduct.

@dimpase, above in #36726 (comment) you write:

If you want, we can discuss whether [the minimal configurations] are needed, certainly

Apparently you are missing a very important basic point. Dima, we cannot have such a discussion (or any discussion), because you are refusing to act according to our community's Code of Conduct.

A great excuse to not fix bugs, too. "This bug does not behave according to our Code of Conduct".

You're simply not interested in discussing your questionable design decisions, it's plain obvious.

@dimpase For your reference, here's the Code of Conduct from https://github.com/sagemath/sage/blob/develop/CODE_OF_CONDUCT.md in its entirety.

Approved by the Sage community by a vote which ended on November 24, 2014
The Sage community is comprised of an international mixture of mathematicians,
computer scientists, engineers, researchers, teachers, amateurs, and others
with varied backgrounds. This diversity is one of our strengths, but it can
also lead to communication problems and unhappiness. People who love working on
Sage can more effectively collaborate with others if they follow this code.

1. Be friendly and patient.

2. Be welcoming. We strive to be a community that welcomes and supports people
   of all backgrounds and identities.

3. Be considerate. Your work will be used by other people and you in turn will
   depend on the work of others. Any decision you take will affect users and
   developers, so you should take those consequences into account when making
   decisions. Conversely, Sage is constantly evolving, and earlier decisions
   that were made in good faith may sometimes need to be reconsidered.
   Nonetheless, we should still appreciate the hard work done in the past.

4. Be respectful and polite. Not all of us will agree all the time, but
   disagreement is no excuse for poor behavior and poor manners. We might all
   experience some frustration now and then, but we cannot allow that
   frustration to morph into personal attacks. It is important to remember that
   a community where people feel uncomfortable or threatened is not a
   productive one. Members of the Sage community should be respectful when
   dealing with other developers and users.
   When we disagree, we should try to understand why. Disagreements, both
   social and technical, happen all the time. It is important that we resolve
   disagreements and differing views constructively. Being unable to understand
   why someone holds a viewpoint does not mean that they are wrong. Do not
   forget that it is human to err. Blame alone gets us nowhere, it is better to
   help resolve issues so we can all learn from our mistakes.

Do you have questions about it? Otherwise, I'll go ahead and offer an interpretation with examples of violations, as previously promised above in #36726 (comment)

It's the new year, so time to move forward with this positively reviewed PR.

@dimpase For your reference, here's the Code of Conduct from https://github.com/sagemath/sage/blob/develop/CODE_OF_CONDUCT.md [...]

Do you have questions about it? Otherwise, I'll go ahead and offer an interpretation with examples of violations, as previously promised above in #36726 (comment)

As the misconduct has continued in https://groups.google.com/g/sage-devel/c/RdSImkzRxJI/m/CMKBJ6u6BAAJ, https://groups.google.com/g/sage-devel/c/XON6NTJa33o/m/_AmwQ6s6BAAJ, #32532 (comment), I'll proceed.

Editor decision

Will merge since there is a PR ready. You can argue about minimal build images vs shortening one line in a shell script, but I just don't have strong feelings either way over something this inconsequential.