Packaging
Development:
- [x] Jenkins split, stage 1 (gramineproject/graphene#1858)
- [x] Jenkins split, stage 2 (gramineproject/graphene#1859)
- [x] Initial meson implementation (gramineproject/graphene#1879)
- [x] Python packaging (gramineproject/graphene#1909)
- [x] Remove submodules (gramineproject/graphene#1997)
- [x] First meson options (gramineproject/graphene#2003)
- [x] Manifest preprocessor (gramineproject/graphene#2288)
- [x] Make testsuites test installed graphene (~gramineproject/graphene#2064~, gramineproject/graphene#2298)
- [ ] Jenkins split, stage 3: make CI test installed graphene
- [x] packages.grapheneproject.io/distfiles (gramineproject/graphene#2119, gramineproject/graphene#2280)
- [x] Full meson, remove makefiles
- #64
- #68
- #71
- #102
- #107
- #112
- #122
- #126
- #129
- [x] Meson wraps, deprecate
Scripts/download - [ ]
meson disttarballs - [ ]
debian/,.spec - [x] repo (packages.gramineproject.io), build infrastructure
Documentation:
- [ ]
NEWS/ChangeLog/whatever - [ ] new installation procedure (#244)
- [x] new building procedure
- [ ] guide for distro maintainers/packagers
Release:
- [ ] maintainer scripts for releasing
- [ ] make a release
Outside effort:
- [x] Upstream SGX driver (merged in 5.11)
- [x]
/devexec mount options (systemd/systemd#17940) - [x] udev rules for
/dev/sgx/enclave(systemd/systemd#18944, released in 248)
Since we changed the name, we should also use gramineproject.io instead of the old grapheneproject.io.
Since we changed the name, we should also use gramineproject.io instead of the old grapheneproject.io.
Done.
@woju Could you update the TODO list? What's left to be done? Or maybe this issue can be closed now?
I think it's up to date. We didn't have scripted release, so that's unchecked. debian/ and .spec are only available from repos, they're not committed to repo, and they will be around CI reorganisation. New installation procedure is #244.
I'll just copy-paste my comment from https://github.com/gramineproject/gramine/pull/244 because I think it's important to discuss this. The context is that the current Gramine package doesn't come with DCAP attestation enabled (only EPID attestation enabled).
If you want to deploy Gramine in the cloud, you almost certainly want to use Intel SGX and SGX attestation. And in the cloud, you don't use EPID attestation these days, you always use DCAP attestation.
So even though you can run a simple HelloWorld SGX application, any real SGX workload will fail because Gramine is built/installed without DCAP-attestation support. The users will be perplexed by this; once they realize that this package doesn't have DCAP attestation, they'll curse us and will have to revert to the old-style "build from GitHub" way.
This is pretty bad actually... Even in QuickStart, we should advise a "feature complete" Gramine package. Since the package comes without DCAP attestation, we doom ourselves to unhappy users (who can successfully run local workloads, but as soon as they want to do SGX attestation, Gramine fails). We definitely need to revisit our packaging.
I think all tasks were done already. @woju Please re-open this issue (or create a new one) if something still needs to be done.
Yes, apart from testing gramine from packages.
I've unpinned this ticket from the issue tracker.