22. November 2022

[dimakuv]

Agenda

(please write your proposed agenda items in comments under this discussion)

• Discuss FOSDEM 2023 participation (deadline is 2. December).
• Discuss "plugins in separate repos":
  • MS Azure specific plugins in new gramine-azure-integration GitHub repo?
  • OpenSSL Engine plugin in contrib GitHub repo?
  • Where do we put Microsoft Azure Attestation (MAA) version of RA-TLS then?
  • Michal's take: strongly against splitting it into multiple repositories.
  • Mona's take: use contrib for now as we figure out the repo structure.
• Discuss Debian packaging (see [pkg] Initial debian/ #512)

Discuss Debian packaging

(See #512 for context. Summary by Michal (four discussion points): #512 (review) .

Woju: the summary by Michal is correct.

• [ Discussion for point 3 ] For single arch, there may be multiple PALs (SGX and SEV and TDX). The only real dependency is the Linux kernel, which is shared for all PALs of the single arch. Other dependencies can be installed in parallel (even e.g. AMD SEV packages on Intel-CPU systems). Rationale: using one debian-packaging directory could be problematic if we would build separate-PAL packages, but since we can do a single multi-backends packaging process we can just have one directory.

• [ Discussion for point 1 ] If we would have a helper script, then e.g. a reproducible build will generate a trace of the "unclean" state (after the helper script was run), instead of the "absolutely clean" state of the git repo (with specific commit).

  • Woju's stance: the state of the project is the state of the git repo, without any modifications.
  • Michal's stance: the helper script can also be considered a "state" of the git repo, and its execution deterministically characterizes the final built package.

• [ Discussion for point 2 ] What would one do with e.g. Fedora (RPM packages)? RPM packages require a single .spec file in the whole directory hierarchy, which contradicts the LTP sub-repo (it is a git sub-module, and it has its own .spec file).

  • Michal: doesn't want to change our Gramine repo to this format (moving LTP from git sub-module to meson sub-project).
  • Woju: we should probably think of it later, once we work on RPM.

• Woju will refuse to do the helper script (insists on the top-level debian/ dir). It will be his responsibility to do the packaging (mostly), and he believes that the helper script will add complexity for this whole build process.

  • Woju fears that the helper script will have problems with (1) dependencies, (2) reproducible builds, (3) who knows what.
  • Alternative approach: Woju can create a separate branch that will be periodically updated to the master. And this branch will have this additional top-level debian/ dir.
    • But then it's unclear how CI can test this packaging. Only manually...
    • It's wrong and unmaintainable.

• Michal: not convinced by Woju's arguments (complexity of running a helper script before the packaging process, need to read the README on how to do packaging properly).

  • But Michal won't insist.
  • Dmitrii also doesn't insist.

• Mona: how hard would it be to commit to Michal's approach with the helper script, see how it goes for several months, and then change to Woju's approach if something is hard/breaking.

  • Woju: not a good option.

Final decision: choose Woju's top-level debian/. (Note: Borys was against such decision offline, but he wasn't present during the meeting.)

Discuss FOSDEM 2023 participation

Vijay: could prepare an abstract until the deadline on 2. December. Vijay could also present.