In D30239#710987, @bdrewery wrote:

In D30239#710984, @gjb wrote:

Thank you for the detailed explanation. I understand I am hard to deal with on this. I think upon human behavior sporadically and it is impossible for us to communicate our true thoughts, beliefs, or assumptions, or to easily break out of our own perspectives or assumptions. Especially over body-free text. I will try to communicate here in a way that avoids those pitfalls. Please do the same and assume I am asking innocently questions. I only wish I could always have this mindset in text. I'm only saying all of this because I've personally gotten frustrated over this discussion a lot and I'm trying to approach it differently after discussion with the Poudriere user post-commit.
I like to understand things at too deep a level sometimes, in that I need to know the root cause. I suppose I prefer quicker paced communications like IRC, or a call, to get the details out, versus this back and forth mailing list thing we've been doing. I should have asked for details or listened better in the past, like 8 years ago or whenever you ran into it.

In D30239#710983, @bdrewery wrote:

It has saved me at work before as well where we do cross-os-release builds and have to define the UNAME_* stuff anyway.

I chose to call it that because the flag IS DANGEROUS in the common case. The flag reflects the outcome if it is used and not understood. Anything benign is an open invitation for [not people here] ignorant users to use or suggest it.

In D31134#704406, @manu wrote:

I'm not sure that we want to add all possible image.
RPI was added because, unfortunately it's popular.
All the Pine devices are too and most have LTS status.
If we start adding every FriendlyElec we're in trouble because they release a lot of boards (like a lot).

In D30239#690405, @grembo wrote:

@bdrewery But don't you think that

1. A feature request from an important consumer of the ports collection should be considered;
2. There is a large number of ports where none of this (uname, osversion, etc.) matters anyway, at least in a development environment;
3. It's better to be able to clearly express "I'm willing to allow a mismatch" vs. overriding an environment variable and pretend there is none?

@gjb @bdrewery Can you imagine to agree on some compromise?

In D30239#690366, @bdrewery wrote:

In D30239#679354, @grembo wrote:

In D30239#679284, @bdrewery wrote:

This isn't simply about host not matching the jail. It's more nuanced. The jail may not match the jail.

Does this change anything about the patch though (which in the end implements a force flag, which isn't nuanced at all)? Would you prefer a different name of the flag that emphasizes that you think this error shouldn't be ignored?

If people don't understand that I am strongly against anything like this going in. But what do I care if you shoot yourselves in the foot?

That's the very nature of providing force/override/ignore warning flags, people using them are on their own. This was raised by a couple of experienced engineers, who have their workflows disrupted by the current state of affairs.

My perspective is that we have re@ trying to use it without understanding the problem. It should not be used for any official builds.

As long as the default behavior doesn't change and therefore things stay safe for normal ports tree users, I don't see any negative consequences. People will shoot themselves in the foot anyway by patching the file manually, so having a flag will at least make sure they don't start using diverging local copies of bsd.port.mk.

I have no personal interest in this beyond trying to direct our energy towards more productive discussions, this doesn't seem like something worth fighting over and being subjected to a lot of negativity in the process.

The negativity is because the problem has not been understood since the check went in which has built up frustration over years, and now there is screaming to remove or allow disabling still without understanding the problem which is causing me to get frustrated. Misunderstandings breed frustration. Now everyone is frustrated. Let's slow down and try to understand.

Hopefully this clears up the problem:

• When building a port it is possible for it to run uname to determine its target system (edit: and bake in different target runtime behavior). If that is coming back not matching the userland of the chroot/jail, how is that _ever ok_? 3rd party ports are far more likely to care about uname than __FreeBSD_version or any other FreeBSD-specific version lookup.
• OSVERSION can probably always be determined automatically. A user does not need to mess with it so long as /usr/include/sys/param.h has a __FreeBSD_version that is expected for the target system.
• OSVERSION ultimately determines *Ports framework behavior* and which patches are applied. It needs to be correct for the target system.
• The only thing that someone trying to build in a chroot must do is ensure UNAME_r is correct.
  • Explain to me why it is easier for them to set ALLOW_OSVERSION_MISMATCH rather than modifying UNAME_r once every 2-3 years or making their chroot setup script do it auto based on git branch or something?
• UNAME_r could probably be automatically determined from OSVERSION. That is a more sane proposal rather than ignoring the problem but I haven't thought deeply about it yet.

Please, anyone, explain to me why my points are wrong.

Please, anyone, explain to me what I am missing.

I cannot accept this review, due to some permission problem. Consider this comment as 'accepted'.

In D29923#684529, @mhorne wrote:

In D29923#678538, @gjb wrote:

Yes. There was a missing change to use the git repository for ports. They should be available this week.

Hi, just checking in again. I didn't see any output in the last two runs either, presumably there are still issues with the build?

I personally prefer danfe's suggestion on the knob name, but yes, I think this works.

In D29923#678516, @mhorne wrote:

In D29923#671549, @gjb wrote:

I think it might be a bit more complicated than this configuration file suggests, but please go ahead and commit it, and we'll work out the edge cases (if any) as they occur.

Indeed, I have not seen any results appear at https://download.freebsd.org/ftp/snapshots/arm/armv7/ so maybe there is something else needed on the release builder side.

I think it might be a bit more complicated than this configuration file suggests, but please go ahead and commit it, and we'll work out the edge cases (if any) as they occur.

FWIW, it builds fine for me. Please go ahead.

Works for me.