Created attachment 226095 [details]
updates security/sequoia and security/py-sequoia
Sequoia-OpenPGP recently released version `1.3.0`.
Since both sequoia-openpgp (as well as sequoia-sq and sequoia-sqv) and the python bindings live in the same git repo, I'm handing in the updates to both ports in one go. No warnings raised by `portlint` and `make index` runs through without issue.
I added `SONAME`s for the `ffi` and `openpgp-ffi` libs. This isn't possible for `ffi-macros` as it doesn't count as "cdylib". The version supplied in `SONAME` might technically be wrong since they use the `1.3.0` version of the `sequoia-openpgp` crate and not the `0.22.0` of their own crates because this led to issues finding the libs that I couldn't resolve.
Both ports now support the `test` target and the test suites run successfully on the amd64 jail I use for testing purposes – tho for sequoia you first have to install it; otherwise it will fail to find the libs – I assume this is is caused by setting `SONAME`, as the error message specifically mentions `.so.1.3.0` but I haven't been able to properly triage the issue.
`py-sequoia` now has its own version as noted in its `setup.py` (`0.1.0`), hence the version *decreased*.
Also, for future releases, I'll probably break this up into about half a dozen different ports and maybe keep `sequoia´ as a metaport with `OPTION`s for the different crates. `sqop` was already moved into its own repo upstream and isn't part of the sequoia port anymore. I'll add it back as its own port in the future.
Would be super nice if we could get this into the next quarterlies, but I totally understand if the remaining time is a bit short for that. ^_^;
(In reply to phryk-ports from comment #0)
PORTEPOCH needs to be incremented when a version goes backward.
Do the changes pass QA (poudriere) for default and non-default Python versions?
If there's a changelog associated with this release, please include it in the URL field.
If this is a bugfix only release, please set merge-quarterly to ? It can be merged anytime if so.
Even though it's a monorepo, it looks like each component/crate can be built independently. The openpgp crate is now at 1.8.0 but for example sq is at 0.26.0. I feel like because of the version discrepancies between components/crates, separating them out might make sense. Thoughts?
Created attachment 234248 [details]
Played around a bit (not least because this is now a BUILD_DEPENDS for another port to update), looks like there's not much of a monorepo situation anymore. sq appears like the only packageable item from the sequoia repo, as the rest are rlibs. ffi, sqv, sqop, keyring-linter have their own individual repos, and python is part of the new ffi repo.
This patch creates a new security/sq, current version 0.26.0, for the epitomous command-line tool. openssl and openssl-sys crates are updated from those versions in Cargo.toml and have upstream patches (by yours truly) applied for proper build and operation with LibreSSL 3.4 and 3.5.
This successfully builds keyrings, joins and revokes keys as needed for the other port. Other functionality should work as intended.
(In reply to Charlie Li from comment #3)
Wow, that's already impressive but the libressl compat really bumps it up
Yeah, the mono-repo situation is something the Sequoia team has been putting
quite a bit of effort in to rectify. There's already sequoia-sqv, sequoia-sop,
sequoia-keystore and by now a good bunch of others, too.
I initially gave up on this port because I just didn't find the energy to
figure out how to and then set up multiple build/test environments for QA.
Currently, I'm not even using sequoia for anything because sequoia-sop's
python bindings aren't finished yet, but I have hopes for that to change
some time this year.
Do you have previous experience with developing / packaging Rust?
Because if you do, you're probably more qualified on making decisions
regarding the packaging of Sequoia components than me. :P
With the number of Sequoia components already around, I think it might
be wise to add a common prefix to their port names, tho.
(i.e. security/sq -> security/sequoia-sq)
I'm gonna see that I get some time in on the weekend to review your patch,
but honestly I assume I'm not gonna find any issue besides the naming. :P
By the way, if you're interested in the Sequoia project, I can heartily
recommend joining #sequoia on OFTC, the devs are very open to questions
and generally a delight to interact with. :)
(In reply to phryk-ports from comment #4)
Generally speaking, if cargo-install(1) doesn't have anything to do, ie no [[bin]] or [[example]] targets in Cargo.toml, there's nothing to package/port. Crates that are effectively Rust libraries (rlibs) are just built as part of those with/for executables or examples. So only sq in the sequoia repo ends up getting ported/packaged.
Just finished building ffi and openpgp-ffi, but the shared libraries are effectively unusable because SONAMEs aren't present, which prevents ldconfig from processing them. Will raise with upstream.
Not attached to any particular naming scheme, as long as it makes sense and we can work some Makefile variable games to make maintenance hopefully easier. If security/sequoia ends up becoming a meta-port after all this, not sure how the versioning will go, since each component is on different versions and defining crate dependencies (especially sequoia-openpgp) differently.
It's about time I get on OFTC in general :-)
Created attachment 234276 [details]
fix typo, move LLVM to BUILD_DEPENDS (readelf -d does not show dynamic linkage to LLVM), update libc and patch mio crates to use the correct kqueue API
For reference, vishwin and I had a conversation in Sequoias
IRC channel yesterday and we decided that he will take over
maintainership of these ports as I currently have neither
the time nor energy to actually *maintain* them and he
seems to be more experienced with both porting and Rust.