Bug 242619

Comment 1 Kubilay Kocak 2019-12-13 09:24:23 UTC

This is an intended message, indicating that the system is running an end-of-life version of FreeBSD. Please update to a supported release version using one of the methods documented here: https://www.freebsd.org/doc/handbook/updating-upgrading.html

Comment 2 Kubilay Kocak 2019-12-13 09:26:44 UTC

Note: While the system is reporting 11.3-p5 (kernel), the system in question is running an older userland, likely due to an incomplete/partial upgrade process (via IRC)

i make everything and nothing even i inside to etc make conf and i set it

ALLOW_UNSUPPORTED_SYSTEM=YES

i make upgrade amd nothing the version 11.3-p5 stop install from ports then if someone to know something how i can fix it i to be happy

(In reply to mircx1 from comment #3)
I can also report this does *not* work
as expected (intended?).
I performed an experiment using a so-called
"unsupported" version. I needed to test some
ports I maintain. In any event; adding:
ALLOW_UNSUPPORTED_SYSTEM=true
effectively accomplishes nothing.
There is also the problem with each invocation
of this informational warning having a 10 second
timer attached to it.
As such setting up an environment that builds/installs
~1500-2000 ports requires waiting 15,000-20,000 additional
seconds -- that's as much as 333.33333 minutes, or 5 hours;
( 2000x10/60/60 ).
If I'm not mistaken, the knob ALLOW_UNSUPPORTED_SYSTEM
is/was intended to silence this warning.
Really. If you've seen this warning, and acknowledged it
by adding the knob to make.conf(5). You should be done.
Simply removing the "silence this message by defining
ALLOW_UNSUPPORTED_SYSTEM." from the warning, and repeating
the warning, and 10 second pause. Has no value what-so-ever.
I spent some time attempting to fix this. But got distracted
by having to fix Mk/Uses/python.mk.

I don't know that I can find the time to fix this right now.
But someone well familiar with the ports(7) framework should
be able to accomplish it in ~10-15 minutes.

This matter should *not* have been closed. If need be, I will
re-open this case by starting a fresh new pr(1) for this matter.

--Chris

(In reply to Chris Hutchinson from comment #5)
Yes, those delays are annoying, especially when ports are built in batch.  I'd suggest setting
WARNING_WAIT=0
DEV_WARNING_WAIT=0
in make.conf, which eventually become "sleep 0".  Doesn't come anywhere near fixing your problem only reducing the nuisance.

Comment 7 Kubilay Kocak 2019-12-14 06:50:13 UTC

(In reply to Chris Hutchinson from comment #5)

There's no need to create a new/separate bug for addressing the specific issue mentioned in the summary, namely: eol error being present.

However, if this specific  issue can indeed be verified, information provided such that it can be reproduced, and a 'problem' clearly described (expected vs actual behaviour), rlease re-open this issue with a proposed patch and a modification of the issue summary, if appropriate.

Open questions on this issue are:

- Is the problem that the error comes up at all on an 11.3-p5 system at this time?
- Is the problem that the error comes up in certain situations of a 
partial/incomplete upgrade process and it shouldn't come up at all?
- What are the steps to reproduce?
- What is the exact state of the system experiencing the issue?

At present this bug does not contain information sufficient to take action, hence the present resolution "works as intended".

Comments on, and the issue of the timeout, or improving it in BATCH situations should take place and addressed in a separate issue.

(In reply to Kubilay Kocak from comment #7)
I only mentioned opening a new pr(1) as this one was
closed, and because I didn't initiate it, I couldn't
re-open it. Thank you for tending to it. :)

Attempt to answer (remaining) open question(s):
 * It fires properly *when* it encounters EOL'd systems
 * It correctly informs, and directs the user for the circumstances
However
 * It does NOT respond as indicated when doing as instructed --
   adding: ALLOW_UNSUPPORTED_SYSTEM=true/yes/t/...
   will NOT silence the warning
 * which *also* (continues to) impose a 10 second pause

The *understood* purpose of the warning (and pause). Was to
inform the user that the version that their system is on, is now
EOL. They should upgrade as soon as is possible.
BUT, if for some reason they need to continue on the EOL'd
system. For convenience; you may silence this message by adding
ALLOW_UNSUPPORTED_SYSTEM=true you your make.conf(5).

This is what the message clearly states. But adding it to make.conf(5)
only removes the portion of the message that states what to
add to make.conf(5). It does NOT remove the rest of the message,
or the 10 second pause.

This is clearly not what was intended. No? :)

Thanks again, for taking the time to address this matter.

--Chris

Comment 9 Kubilay Kocak 2019-12-15 01:57:37 UTC

(In reply to Chris Hutchinson from comment #8)

I can't *unequivocally* speak to the original intention, but looking at the relevant block in Mk/bsd.port.mk:

- There are two 'variations' of the message depending on whether ALLOW_UNSUPPORTED_SYSTEM is defined or not, and 

- *both* conditions include the same message as their first section, 

- with the latter (when not defined) additionally including the "... if you silence this message by defining ALLOW_UNSUPPORTED_SYSTEM"

To me, that indicates that defining ALLOW_UNSUPPORTED_SYSTEM was *not* supposed to  or intended get rid of the EoL messaging *completely*.

I conclude that the mechanism indeed 'works as intended' on the above basis, but I believe there is some messaging improvements to be made, as I can see how "silence this message" could be taken to mean "not see any message about this EoL condition *at all*", rather than "just remove the messaging about being able to use the ALLOW_UNSUPPORTED_SYSTEM variable"

I would propose a simple change such as:

- No support will be provided if you *silence this message* by defining ALLOW_UNSUPPORTED_SYSTEM.
+ No support will be provided if you *override this error* by defining ALLOW_UNSUPPORTED_SYSTEM in /etc/make.conf

when i will make update to 11.3-p5 the ports stop to install if you know how i can fix it i to be happy

(In reply to Kubilay Kocak from comment #9)
Message returned for an EOL system:
/!\\ ERROR: /!\\
Ports Collection support for your ${OPSYS} version has ended, and no ports
are guaranteed to build on this system. Please upgrade to a supported release.
No support will be provided if you silence this message by defining ALLOW_UNSUPPORTED_SYSTEM.

PERCIEVED message:
System is no longer supported
Add ALLOW_UNSUPPORTED_SYSTEM=true/yes/t/... to make.conf(5) to silence (remove)
this message

Rational:
Having been submitted this message. I now know my system is EOL.
Now that I *know* it is EOL. I can remove this (now redundant) message,
by setting ALLOW_UNSUPPORTED_SYSTEM=true/yes/t/... in my make.conf(5)

Why:
There is
1) no *other* value in creating ALLOW_UNSUPPORTED_SYSTEM
2) I *already* know the system is EOL, and have proved that by adding
ALLOW_UNSUPPORTED_SYSTEM to make.conf(5)

Need:
I am a ports maintainer for well over 100 ports. When I need to test
against older systems. I should *not* be penalized by
1) the redundant message
2) as much as a 5 hour delay building the ports I am testing, and
related ports required to create the test.

The original message is created by 2 variables
Setting ALLOW_UNSUPPORTED_SYSTEM only removes the portion of the message
that says you can add it. It has *no* other value. It has no *realistic*
value.

Proposal:
Make the message controlled by *only* the *second* variable. Which will
remove the message, and 10 second pause, should the user acknowledge they
know their system is EOL, by seetting ALLOW_UNSUPPORTED_SYSTEM in make.conf(5)

Thank you for your continued attention to this issue.

--Chris

Comment 12 Kubilay Kocak 2019-12-15 23:54:34 UTC

(In reply to Chris Hutchinson from comment #11)

I'm hearing a proposal that ALLOW_UNSUPPORTED_SYSTEM should not just remove the messaging about the variable being available, but to bypass the EoL message completely, given that a user has already been informed (given theyre using the variable) that the system is EoL.

That's fine, if you could provide a proposed patch to do so, that would be great

Regarding the time delay, per comment 7:

>  Comments on, and the issue of the timeout, or improving it in BATCH situations > should take place and addressed in a separate issue.

If you could create a separate issue with a patch for that, that would also be appreciated

(In reply to Kubilay Kocak from comment #12)
Forgot about this one.
In my frustration. I already patched this out
the system I was (then) working with. I'll have
a look, and see if I still have something for this.

Thanks again, Kubilay. :-)

--Chris

Comment 14 Rene Ladan 2022-03-07 19:55:21 UTC

Maintainer reset.