7, a better number. Or is it? The newspost on PyPI’s deprecation of PGP laid bare some internal discussion I hadn’t been privy to. Such as that PGP’s keyserver network (SKS) has been dead for years! Yet, so much software still offers to upload and use servers in this network. I guess individual servers (and those are probably going to be Ubuntu’s or MIT’s) can still serve as an index for keys.
I yanked my key from this website (WKD) last year, due to having stopped using PGP. Nearly nobody else does, and UX is despite many trying to improve, quite bad. I wish more people cared, autocrypt makes it quite easy, but they don’t, developers included; still very few muas support autocrypt fully, by which I mean automatically updating keys without user intervention.
I learned something new yesterday. As someone who grew up in the keyboard age, and gets wrist cramps when writing more than 3 minutes, I stumbled across Lloyd Reynolds' videos on calligraphy and handwriting. What did I learn? That Serifs get your ink flowing! He does not outright say this is why serifs exist, but it would make an afwul lot of sense, wouldn’t it? So I’m going to assume it is so until proven otherwise. Neat.
Arbor is distributed among others as Spack package. Spack is an interesting project, it aims be a platform independent (as in, not tied to a particular operating system or Linux distro) package manager. In that it is similar to (home)brew. What’s different is that you’re supposed to formulate any dependencies as dependencies on other Spack packages, such that Spack has a full view of the dependency tree. Spack can build (or concretize) a single environment with all packages that you request, and make sure all dependencies are solved and built in a compatible way. It’s a project started by HPC centers, which can use Spack to build an environment for all its user in a single and reproducible way.
Admirable! And it does work, although the only places I use it is on my local machine when making changes to Arbor’s package.py and testing Arbor over on the Ebrains Lab, which as of earlier this year is building itself through Spack. As part of that project, I need to make the existence of any tests (whatever they are, in our case: some unit tests and executing the examples) known to Spack. This was a bit more complicated than I thought, so I’ll document how I got there. Note: the actual tests were already written.
The Spack documentation is extensive, but that also makes it easy to lose important details in the sea. The documentation often includes log dumps or long examples, which together with sparse headering, makes it difficult to scan a section for something you might need (good example: The “Installing Packages” section. It also took me until today to discover the Tutorial section. Yes, it’s quite prominently placed in the side menu on the main documentation page, but its title “Tutorial: Spack 101” and lack of listed subitems led me to believe this was more of an intro to the conception and basic intended use of Spack, while in actuality, there’s also tons of tutorial material for developers of packages. I suppose a project like Spack needs to communicate to 3 different kinds of audience: users (e.g. scientists requiring a tool at a supercomputer), sysadmins (people who operate the software present at these supercomputers) and tool developers (scientists or software developers who write re-usable software that makes up the repository of tools buildable by Spack).
We will need to make some minor changes to the Arbor repo, so we need to set up Spack so we can work from local source. spack edit arbor will show you the package.py, which might also require modification. This is however the copy that lives in the Spack repo, and contains instructions of where to get Arbor, and we don’t want any release or master branch, we want a local copy where we can make other changes. The Developer workflows Tutorial explains that we do this by setting up a Spack environment (which means Spack must be added to your PATH). Let’s start:
. ~/path/to/spack/share/spack/setup-env.sh # Adding Spack to PATH
mkdir ~/tmp/spacktest
cd ~/tmp/spacktest
spack env create -d .
spacktivate .
spack add arbor
spack install # in my case Arbor was already installed, so nothing needed to be built.
spack develop arbor@master
Now you should find Arbor checkout out in subdirectory arbor, git and all (@master told Spack to get Arbor from the master branch at the git repo after all). After you make any changes in the directory, you can trigger rebuild as follows:
spack concretize -f
spack install
If you want to rebuild, sometimes (especially if you’ve made no changes) it looks like you should remove the build dir, which will look something like spack-build-kw7pxqj.
If you want to run your projects (install-time) tests (e.g. execute make check), then run:
spack install --test=root
Error messages/reports won’t bubble up, so if this fails, see the test output in install-time-test-log.txt.
That’s it! But! After this journey did I discover dev-build, which seems like it’d accomplish the same in fewer steps? I’ll check it out next time I need to make changes.
Now that Gitter is Matrix-only, I have reason to revisit my overview slightly. I now have reason to log in to separate accounts; in addition to the account I have at kde.org, also through the Gitter homeserver using Github SSO. Turns out Cinny, my client of choice, does not support multiple accounts. Neither does Element! There are some clients that do, and I picked Fluffy. But then it turns out Fluffy does not allow for sign-ins using SSO… Neochat does, but it’s E2EE support is WIP. Those’re all the clients I checked out then. Other clients supporting multiple accounts and SSO, E2EE and Spaces are Hydrogen and Mirage. Hydrogen appears to be a new, lighter weight, but beta client by the Vector-IM folks (who also write Element), but isn’t packaged as a desktop app. Mirage, the only other client supporting these, says it is alpha quality. So, I guess I going to have to go live without a multi-account client for now.