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?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 25 2022
Jun 24 2022
Feb 16 2022
Feb 15 2022
last ping before I submit?
Jan 29 2022
Any further comments?
Jan 22 2022
Undo the upgrade to a newer GCC
Dec 27 2021
Dec 26 2021
Please review. I'm not too happy with the need to set PATH, but I can leave that part out of the patch.
Dec 25 2021
Oct 8 2021
Oct 7 2021
Jul 20 2021
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
May 25 2021
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.
May 9 2021
May 7 2021
Apr 20 2021
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?
Apr 9 2021
Mar 29 2021
Jan 24 2021
can you please sent a pull request, so we can see the actions trigger?
Jan 20 2021
Jan 18 2021
Jan 11 2021
Thanks, just some nits.
Jan 8 2021
Jan 2 2021
Dec 26 2020
Dec 25 2020
an SVN checkout of stable/12 will produce this, after the MFC (i.e. nothing changes for that)
Dec 24 2020
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)?
Dec 23 2020
Dec 13 2020
Nov 26 2020
the env fix was committed with https://github.com/freebsd/freebsd/commit/5afe096970b19e2d3bc3b44a1a09ae788e33795c
Hmpf, this ran into the same issue as last time ...
Nov 25 2020
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.
Nov 24 2020
Microsoft's money isn't my concern here, but rather the FreeBSD developer time, so this stuff should be as fast as possible.
Nov 20 2020
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)
Sep 14 2020
Aug 21 2020
Aug 18 2020
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).
Aug 14 2020
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.