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. Some notes: 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] security/sq v1 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 another notch. 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] security/sq v2 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.
both chameleon and sq build OOTB, at least on 14.0-CURRENT: - https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg - https://gitlab.com/sequoia-pgp/sequoia-sq I'm not really keen on the python part, but I can at least get these 2 rusty parts into ports to start with. Any objections, or do either of you have plans already?
I have it working locally as well, since it's needed for archlinux-keyring, but still reworking the port bits mostly due to not everything having endpoints.
So upstream have deprecated the FFI bits in favour of "point solutions", so that removes a complexity point I've been dealing with. This deprecation includes the existing Python bindings, for which PySequoia serves as the replacement. Only crates that contain executables will be ported. For now, I will convert security/sequoia into a meta-port, structured similarly to graphics/gimp. Since we have only had sq ported before, it will serve as the meta-port's one dependency until other crates under the official sequoia umbrella are ported over.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3835bb252e91cda64657878b8438f6440342f516 commit 3835bb252e91cda64657878b8438f6440342f516 Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2023-06-09 05:20:21 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2023-06-09 05:32:56 +0000 security/sequoia: convert to meta-port and update sq split to security/sequoia-sq. More programs to be ported later. FFI deprecated upstream and removed from the port. PR: 256877 Approved by: phryk-ports[at]wzff[dot]de (maintainer, transfer) Event: SouthEast LinuxFest 2023 UPDATING | 11 + security/Makefile | 1 + security/sequoia-sq/Makefile (new) | 50 ++ security/sequoia-sq/Makefile.crates (new) | 439 ++++++++++ security/sequoia-sq/distinfo (new) | 881 +++++++++++++++++++++ security/sequoia-sq/pkg-descr (new) | 5 + security/sequoia-sq/pkg-plist (new) | 63 ++ security/sequoia/Makefile | 337 +------- security/sequoia/distinfo (gone) | 551 ------------- security/sequoia/files/patch-Makefile (gone) | 11 - security/sequoia/files/patch-ffi_Makefile (gone) | 11 - .../files/patch-openpgp-ffi_Makefile (gone) | 11 - security/sequoia/files/patch-rust-1.64.0 (gone) | 80 -- security/sequoia/files/patch-sop_Makefile (gone) | 12 - security/sequoia/files/patch-sqv_Makefile (gone) | 12 - security/sequoia/files/patch-store_Makefile (gone) | 12 - security/sequoia/files/patch-tool_Makefile (gone) | 12 - .../sequoia/files/sequoia-openpgp.pc.in (gone) | 11 - security/sequoia/files/sequoia.pc.in (gone) | 11 - security/sequoia/pkg-descr | 7 +- security/sequoia/pkg-plist (gone) | 29 - 21 files changed, 1460 insertions(+), 1097 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=bc106728715d27f7724f51e17e27b90a1b1c0369 commit bc106728715d27f7724f51e17e27b90a1b1c0369 Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2023-06-09 05:29:28 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2023-06-09 05:32:57 +0000 security/py-sequoia: remove Deprecated upstream; security/sequoia no longer includes the parts necessary for this to work. PySequoia is the designated replacement and will be ported later, and MOVED will be updated accordingly. PR: 256877 Approved by: phryk-ports[at]wzff[dot]de (maintainer, transfer) Event: SouthEast LinuxFest 2023 MOVED | 1 + security/Makefile | 1 - security/py-sequoia/Makefile (gone) | 32 ------------------------- security/py-sequoia/distinfo (gone) | 3 --- security/py-sequoia/files/patch-Makefile (gone) | 12 ---------- security/py-sequoia/files/patch-setup.py (gone) | 11 --------- security/py-sequoia/pkg-descr (gone) | 2 -- 7 files changed, 1 insertion(+), 61 deletions(-)
Updated to sequoia-openpgp crate's nominal version 1.16.0, even though security/sequoia is a meta-port now. sq to 0.30.1. Expect the meta-port to feel like the xorg meta-ports where every program/component become OPTIONS.