I added this originally to see if the templating was working correctly.
With the recent changes to make it a cask, it's now much longer and
obscures some of the other more valuable output, so remove it.
Previously, we used `git describe --tags` to produce a version number
for non-released builds derived from the most recent tag + some info
such as the number of commits since that tag and then `g{HASH}`.
That always confuses people because the date portion at the front
looks old (it is typically the previous release) and the hash at
the end has that `g` in it.
This commit simplifies both the tag name used when making a release
and the computed version number take the date/time from the current
commit, and then append the hash. That way the version number always
corresponds to a commit.
This scheme doesn't help detect situations where the commit is
dirty, but I don't think the old one would have helped with that
either.
CI got broken by the termwiz release. This commit teaches the
various `git describe --tags` calls to filter to the wezterm
tags which all start with the year. We're match `20*` which should
be good for the next 79 years.
I've removed the vergen dependency as there was no way to teach it
to do the equivalent matching, and it wasn't a terrible burden
to just inline the git describe call anyway.
This persuades the CI to install both the arm and intel flavors
of the rust toolchain on macOS, and the deploy script to generate
a universal binary.
* need big sur to build for M1
* Use cross-compilation compatible mlua from my fork for now
This commit provides a shell script that hooks into bash and zsh
to enable OSC 7 and semantic zones.
The packaging for Fedora and Debian deploys that script to
/etc/profile.d.
The nightly builds seem to often trip over each other when
uploading the source tarball from ubuntu20.
Restrict it to being built only on the appimage build (ubuntu16).
This is a bit of a switch-up, see this comment for more background:
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
This commit:
* Adds a pre-compiled mesa3d opengl32.dll replacement
* The mesa dll is deployed to `<appdir>/mesa/opengl32.dll` which by
default is ignored.
* When the frontend is set to `Software` then the `mesa` directory
is added to the dll search path, causing the llvmpipe renderer
to be enabled.
* The old software renderer implementation is available using the
`OldSoftware` frontend name
I'm not a huge fan of the subdirectory for the opengl32.dll, but
I couldn't get it to work under a different dll name; the code
thought that everything was initialized, but the window just rendered
a white rectangle.
Rather than scanning directories and reading in ~230 files on startup,
do the scan at build time so that we're parsing from memory rather
than local storage.
This should shave a bit of time off the startup, although I
haven't measured this, and I've only run this on a remote
linux system thus far.
refs: https://github.com/wez/wezterm/issues/264
I've been meaning to do this for a while: the intended purpose
is to use this to filter ansi escape sequences out of the prompt
in the shell pre-command hook.
tweak some container names
fixup container names and regenerate the config
Ensure that curl is installed
the rust toolchain stuff wants curl
run apt update before apt install
centralize updating apt, and install sudo
revise get-deps script for slimmer debian images
more container related tweaks
get-deps: Don't require lsb-release on debianish systems
more get-deps improvements
Explicitly ask GH actions to recursively checkout the repo
Explicitly install git
fetch tags and tweak git build for debian systems
moar adjustments
remove deb8 (its wayland is too old), fixup debian publish
Ensure git build deps are installed always, tidy up sudo usage
This commit allows loading the console functions from `conpty.dll`
instead of `kernel32.dll` which means that we can update and
track newer features than have been deployed to Windows.
In practical terms this means that we can now unlock mouse input
reporting in eg: VIM running under WSL.
refs: https://github.com/microsoft/terminal/issues/376
We're jumping the gun on this issue, which is tracking making
a proper supportable way to deploy this sort of update:
refs: https://github.com/microsoft/terminal/issues/1130
For now it seems easier just for us to bundle our own copy of
these bits.
This includes a speculative change to include those in our
Windows downloads also.
The binaries were built from
4f8acb4b9f
* take a stab at fixing the windows CI to generate 64-bit
* use actions-rs/toolchain more broadly
* fixup target dir for deploy script
* cut over to the rust action for installing rust
