Jeremie Courreges-Anglas wrote:
On Wed, Sep 23, 2026 at 07:46:00PM +0000, David Uhden Collado wrote:
[...]
Anthony's mail was perfectly on point and you're just ignoring it.
As for AI, I think reducing the discussion to "the Makefile is too long"
Pointless complexity is a liability. Several seasoned porters have
commented on this matter already.
or "the email is too long to read"
Writing walls of text means you're effectively wasting the time of
other contributors. Using LLMs to generate said text would just be the
cherry on top, because it's so easy. Read: lazy.
is a poor argument against complexity. It
effectively defines acceptable complexity according to what someone feels
like reviewing manually
"manually"...
You're talking about human beings using their brain, time and goodwill
to review your stuff. Don't assume people will use AI tools to review
your mails. In fact, assume the opposite.
rather than according to what the software actually requires.
Anthony's proposal proved that your overly complex take could be
handled in a much more elegant and easy to understand manner,
following the idioms used in the rest of the ports tree. So you're
making a poor argument for unwarranted complexity.
As a wannabe ports contributor you're bound to listen to what people
here say, instead of nitpicking, pretending you were right and
changing the subject. If you don't listen, people will ignore you,
and very rightly so.
Stop using AI to generate ports. Use your brain, type stuff. And
pleaaase, stop drowning people with pointless blabla.
Using AI to automate part of the implementation is not equivalent to
putting in zero effort. It mostly moves the effort elsewhere, especially
into review and testing.
At the moment, you cannot realistically hand all of that testing to an
agent either. Doing so thoroughly is still too expensive and unreliable.
I have, for example, a patch for uutils that fixes a test-related
problem where the system date could be changed globally to 2020 if run
as root. Finding and validating issues like that still requires actual
testing and understanding of what the software is doing.
So I disagree with the idea that using AI automatically means being
lazy. It changes where the work happens; it does not remove the need to
understand the result or take responsibility for it.
There is another problem here as well. If deviations from the project's
preferred style are such a serious issue, then please document those
expectations clearly instead of waiting until a new contributor reaches
the mailing list and then complaining that they used the Makefile,
PLIST, MULTI_PACKAGES, comments, or some other mechanism incorrectly.
Even when I am working things out myself, I have sometimes been unsure
about where a particular responsibility belongs between the Makefile and
PLIST, or what the preferred ports idiom is for a specific case. That is
exactly the kind of knowledge that should be written down if
contributors are expected to follow it consistently.
If the expectation is that contributors must learn all of this by trial,
rejection, and mailing-list correction, then some amount of unnecessary
back-and-forth is inevitable.
So yes, I will simplify submissions and follow established ports idioms
where they are clear. But if people care this much about newcomers
following those idioms correctly, then please use those beautiful human
brains to document them properly as well.SPDX-License-Identifier: MIT
Make the uutils test suite pass on OpenBSD. Tests that rely on the
filesystem denying access are skipped when running as root, in case the
suite is run with root privileges, matching the GNU coreutils test
suite.
Never let the suite reset the system clock: the `date --set` examples call
clock_settime(2), which needs root and changes the date for every process on
the machine, including the rest of this test run and any later port tests.
Require an explicit opt-in (UUTILS_TEST_SET_SYSTEM_DATE) for those examples,
in case the suite is run as root.
Index: tests/by-util/test_date.rs
--- tests/by-util/test_date.rs.orig
+++ tests/by-util/test_date.rs
@@ -511,10 +511,19 @@
new_ucmd!().arg("+%%N").succeeds().stdout_is("%N\n");
}
+/// Setting the system clock requires root and would leave every process on the
+/// machine -- including the rest of this test run -- with a wrong date. If
the
+/// suite is run as root, the `date --set` tests that call `clock_settime` are
+/// skipped unless the operator explicitly opts in.
+#[cfg(all(unix, not(target_vendor = "apple")))]
+fn date_set_is_allowed() -> bool {
+ std::env::var_os("UUTILS_TEST_SET_SYSTEM_DATE").is_some()
+}
+
#[test]
#[cfg(all(unix, not(target_vendor = "apple")))]
fn test_date_set_valid() {
- if geteuid().is_root() {
+ if geteuid().is_root() && date_set_is_allowed() {
new_ucmd!()
.arg("--set")
.arg("2020-03-12 13:30:00+08:00")
@@ -582,7 +591,7 @@
#[test]
#[cfg(all(unix, not(target_vendor = "apple")))]
fn test_date_set_valid_2() {
- if geteuid().is_root() {
+ if geteuid().is_root() && date_set_is_allowed() {
new_ucmd!()
.arg("--set")
.arg("Sat 20 Mar 2021 14:53:01 AWST") // spell-checker:disable-line
@@ -604,6 +613,10 @@
#[test]
#[cfg(unix)]
fn test_date_for_no_permission_file() {
+ if uutests::util::is_root() {
+ // The filesystem permission checks are bypassed when running as root.
+ return;
+ }
use std::os::unix::fs::PermissionsExt;
const FILE: &str = "file-no-perm-1";
@@ -731,7 +744,7 @@
#[test]
#[cfg(all(unix, not(target_vendor = "apple")))]
fn test_date_set_valid_3() {
- if geteuid().is_root() {
+ if geteuid().is_root() && date_set_is_allowed() {
new_ucmd!()
.arg("--set")
.arg("Sat 20 Mar 2021 14:53:01") // Local timezone
@@ -743,7 +756,7 @@
#[test]
#[cfg(all(unix, not(target_vendor = "apple")))]
fn test_date_set_valid_4() {
- if geteuid().is_root() {
+ if geteuid().is_root() && date_set_is_allowed() {
new_ucmd!()
.arg("--set")
.arg("2020-03-11 21:45:00") // Local timezone
