This is specific to git, not meta, I think -- and there is an open ticket at ~sircmpwn/git.sr.ht#170 for this.
For the record, muon does support add_project_arguments, and the only difference between the two is that global:
- is a bit of a design mistake and people nearly always want project instead
- will set arguments for subprojects too, or error out if invoked in a subproject.
I went to the patchset preparation page at https://git.sr.ht/~eschwartz/pacman/send-email
Select a branch
- build-always-stale-version (active 18 days ago)
- master (active 26 days ago)
- More branches
I'd like to prepare a patchset via a branch that's not one of the first two, so I clicked more, and then clicked through to
- meson-doc-install (active 1 year, 1 month ago) Select this branch
But this brings me to a new page https://git.sr.ht/~eschwartz/pacman/send-email?branch=meson-doc-install which apparently ignores the branch selection, and continues to offer me the original two branches.
The original two branches do not reload the page on selection, they are both in the original page and selecting one merely brings the list of commits into view.
git can use gpg to sign push actions, not just commits/tags. The resulting push signature can be used to generate a transparency log of which account pushed certain commits to any given branch, and when. It can also be used to outright reject unsigned or invalid pushes.
It would be really useful from a security perspective to advertise support for and process signed pushes, as an audit log feature. And opt in to enforcing this for all pushes for people who want to guarantee that all push actions are securely audited.
Duplicate of #158 but the other one uses the keyword "gpg".
This is now fixed in the production sr.ht instance (which migrated from alpine 3.12 -> 3.13 today and therefore upgraded busybox), so all sourcehut generated archives undergo a one-time change and then should act like comparable archives from any GNU gzip-using software forge going forward.
I misclicked on "Import mbox" instead of "Browse..." and no file was selected. Then I had to wait for idk what while it processed "something", or at least until ~sircmpwn fixed it for me.
It would be better to catch this and tell you e.g. "error: no file selected" so you can try again immediately.
Here is the ticket as requested.
The tars above show the status has not changed; srht-devtools-20190821.tar.gz continues to have a checksum of fe222eb819bf0dd410ab6a3201fc196961746e3b2f1866dae5ca5d27142da208
However, if you boot into the alpine/edge image where BusyBox v1.32.0 is installed,
busybox gzip -n < devtools-20190821.tarproduces the same file as GNU gzip.
See this test case: https://builds.sr.ht/~eschwartz/job/331650
So the fix would be to upgrade busybox on the sourcehut server, e.g. by migrating to a newer version of Alpine.
I believe the commit by ~xenrox https://git.sr.ht/~sircmpwn/builds.sr.ht/commit/1ae569174d621fa8e15800d82eb4de795826bdc8 was supposed to help here?