Works for me, but why do we even bother with a small termcap at all? Is the added complexity worth any "speedup" that I'm sure might not even be measurable on today's systems?

last ping before I submit?

Any further comments?

Undo the upgrade to a newer GCC

Please review. I'm not too happy with the need to set PATH, but I can leave that part out of the patch.

In D31231#703461, @arichardson wrote:

Actually, the commit message should be updated: this no longer unbreaks github actions CI it just corrects the clang version displayed in the output.

sync to head

In D31231#703439, @arichardson wrote:

In D31231#703428, @uqs wrote:

In D31231#703323, @arichardson wrote:

This is not quite correct, the linker in that run is lld. See https://reviews.freebsd.org/D31224 (will commit shortly).

What do you mean by that? I see that this run no longer has the debug output that I added, but it is/was running the homebrew lld and then falling flat on its face.

Here's a run with -dx showing that LD=/usr/local/opt/llvm/bin/ld.lld

https://github.com/uqs/freebsd-src/runs/3112515316?check_suite_focus=true

Homebrew LLD is still LLD just with a vendor prefix (ELF linker) and not the macOS linker (Mach-O output format).

In D31231#703323, @arichardson wrote:

This is not quite correct, the linker in that run is lld. See https://reviews.freebsd.org/D31224 (will commit shortly).

ship it!

See https://github.com/uqs/freebsd-src/actions/runs/1048805719 for a passing run

I sympathize with having to field support requests of people shooting themselves in the foot. That said, there can be valid reasons to for example try a newer kernel w/o updated userland to see whether a regression was fixed. In that instance I would like (have to, really) build a new drm-kmod-current package which this check prevents me from doing.

In D29831#669973, @arichardson wrote:

@uqs Should I commit this to stable/13 and we see if the github mirror still works or would you prefer to do it?

can you please sent a pull request, so we can see the actions trigger?

Thanks, just some nits.

an SVN checkout of stable/12 will produce this, after the MFC (i.e. nothing changes for that)

update to skip HEAD as suggested by glebius

Add sample output and MFC reminder to commit message

In D27751#620263, @emaste wrote:

what will this look like on stable (eventually)?

the env fix was committed with https://github.com/freebsd/freebsd/commit/5afe096970b19e2d3bc3b44a1a09ae788e33795c

Hmpf, this ran into the same issue as last time ...

In D27290#611021, @arichardson wrote:

In D27290#610937, @uqs wrote:

https://github.com/uqs/freebsd/actions/runs/381511283

Also, why do we still have -fformat-extensions in our Makefiles? Am I wrong or is there no compiler out there that still knows about this flag, yes?

Looks like using the pre-installed system packages still takes 22s instead of 40ish? But if it works with system-provided packages that's probably better than installing a specific version.

Microsoft's money isn't my concern here, but rather the FreeBSD developer time, so this stuff should be as fast as possible.

The last change didn't break the converter, per se. But github was blocking the upload of the new file. As this is only changing an existing file, I think it'll be just fine (I know that pushing changes to these files with the CLI is ok, I've never had to add one of these .github/workflow files so far)

Looks good, do you want me to go ahead and commit this on your behalf?

While I had to do this as well to make it attach, I'm not sure if this is intentional or simply a bug that should be fixed (instead of documented).

Oh wait, if we use @sample, then config.php-dist will be copied to config.php (but it has bogus values) so the whole web config will fall on its nose. So I think the best way forward is to not use @sample at all and instead ship config.php-dist as a regular file (that get's updated with a new version).

I'm not sure the rename is worth it, just to make the @sample usage simpler. There's even support for -dist, so let's use that.