This prevents a PR named "libsdl: xyz" being tagged as "6.topic: bsd".
This is slightly more robust than simply checking if the strings
"bsd" or "darwin" or "macos" are present in the title.
Thanks to Rosetta 2, we can build x86 packages on aarch64-darwin
machines (although, it's not perfect).
This adds a new configuration option -- `additional_build_systems` --
which will cause the builder to spawn additional async tasks for each
additional build system.
The tests were failing for me because I have git configured to use
"main" instead of "master" as the default initial branch name for new
repositories. Having the tests use global git configuration from
developer systems is just asking for trouble with non-reproducibility,
but fortunately git gives us a mechanism to disable it.
This also means we don't need to worry about GPG any more.
For some reason, the overlay at nix/overlay.nix doesn't appear to be respected
(or, maybe `defaultCrateOverrides` isn't being respected). Either way, this is
necessary for darwin builds to succeed.
This has been superceded by just invoking `cargo update` in the regular
development shell (now that we've switched to using `buildRustPackage` instead
of `crate2nix`).
Nixpkgs recently gained the ability to fetch cargo dependencies based on
the Cargo.lock file which means we can get rid of all the generated Nix
expressions. The only downside to that is that we are now building
everything in one go and do not have the semi-incremental builds as we
had before.
By switching to the tools bundled within nixpkgs we can provide a much
more "pure" development environment that doesn't randomly change over
time.
Previously we would be using the latest and greatest version of the
formatting and linting tools while our development environment only
offered whatever was in the (old) nixpkgs pin. Nowadays we have all the
tools we need in nixpkgs and can thus use those instead. By following
nixpkgs more closely we can make sure to make use of those tools in this
project as well. Hopefully removing the "yearly churn" of doing big
migrations.
For the meantime I allowed the upper case acronyms check (and a few
other minor lints) in the clippy configuration. This will allow a
smoother transition towards the newer clippy code that is decoupled from
the actual linting changes.
It has been almost three years since this was introduced for the sake of
fixing builds on TravisCI. The project since moved to GitHub Actions and
this shouldn't be required anymore.
This is perhaps a bit controversial. The only acronym that I allowed is
the NixOS acronym all the others are required to follow the clippy
naming conventions.
The current darwwin builder is reset very, very frequently (mostly due to its
storage constraints necessitating it), so there's much less of a reason to limit
the people who can utilize it. (Enabling it for everybody will also guarantee
more frequent resets, as well.)
However, it is kept as an option so that it can be re-enabled some time in the
future, if anything were to happen.
* If the sha we're operating on already has checks beginning with the old
`grahamcofborg-` prefix (e.g. someone just used `@ofborg eval`, `@ofborg build`,
or `@ofborg test`), continue using that prefix.
* If the sha we're operating on doesn't have any checks beginning with the old
`grahamcofborg-` prefix, use the new `ofborg-` prefix. This will take effect on
all new PRs immediately, and after a force-push for all existing PRs.
There are some out of pkgs/development/ocaml-modules paths like
pkgs/applications/networking/jackline which would be nice, but
ultimately maintaining that list would be a bit of a nightmare.
Alyssa Ross
Winter Cute
Jörg Thalheim