Changelog, rpm-build, and qubes-builder

[rocodes]

Add changelog, rpm-build, and qubes-builder and qubes-builder compatibility. (Some commits pulled in from qubes-skeleton repo).

The reproducible rpm logic from our own build process is retained with the containerized build script (make build-rpm), but will not be retained via qubes-builder - needs discussion. We also deviate slightly from the qubes-skeleton repo (setting a version, release, and changelog in the spec vs via commandline parameters like @CHANGELOG@).

To test rpm reproducibility:

make build-rpm from the tip of this branch and see

Build complete! RPMs and their checksums are:

108c022a5955ccbb0c9c17b9eec1e395c36f14d9ba0babb47679f1076f9540cf  rpm-build/RPMS/noarch/securedrop-workstation-keyring-0.1.0-1.fc37.noarch.rpm
2e4fecfa97e9e5708a0e18b8eb1a0d536b9251097816bf60b66b016cd555471a  rpm-build/RPMS/noarch/securedrop-workstation-keyring-0.1.0-1.noarch.rpm

[deeplow]

I didn't manage to get it working, unfortunately. I'm simply runnning make build-rpm. Should I be running something else beforehand?

(update: never mind: forgot to checkout your branch!) -- buit succesfully a hashes do match

[deeplow]

The reproducible rpm logic from our own build process is retained with the containerized build script (make build-rpm), but will not be retained via qubes-builder - needs discussion.

Sadly, from what I recall, the official builds run offline (akin to how Debian does it). This may mean that the container router will be challenging. If this is confirmed, we may need to do the reproducibility the way the Qubes team does it (which may make review easier) or try to reuse what we have already but outside a container environment (whichever is easiest, I'm guessing).

(edit: I'm now having second thoughts, because I recall seeing in builder-v2's output it pulling lots of docker images. And checking my local qubes-builder-dvm it is indeed network connected 🤔)

We also deviate slightly from the qubes-skeleton repo (setting a version, release, and changelog in the spec vs via commandline parameters like @CHANGELOG@).

Sounds like a good thing to flag in case some other builder component expect things in the original places. But I'm guessing it should be fine because the spec file is doing the work.

[rocodes]

@deeplow : thank you for review; I'm not anticipating the dockerized build will be used at all by Qubes, I'm anticipating they will just use their qubes-builder mechanics. I would like to merge this for testing purposes in order to test out the qubes-builder vs our dockerized build side by side, and to include the requisite qubes builder and gitlab ci config. I imagine some packaging aspects will need to change once we get closer to qubes-contrib and once this repo is owned by FPF (for example there is no CI right now.)

[deeplow]

For reference, here I included a link to my Qubes-builder-compatible implementation. Maybe you can use that for comparison? Also, you have trouble getting the Qubes builder v2 up and running, do let me know it has some quirks which are not immediately obvious.

[rocodes]

Thanks, I looked at your repo and the original qubes-skeleton files, you'll see I have pulled in some of those commits.

The modifications I have made as compared to what's in your repo are:

• We don't need to support qubes 4.1 CI targets, so I have dropped those from the gitlab configuration.
• We don't need the PACKAGE_SET variable afaict because we don't have optional dom0 or VM targets, we always target one single spec file.
  In addition:
• the spec file in your repo looks like it came directly from my github comment (I see the [snip] in there where I was trying to just omit some text in the github comment for brevity) but it takes out the reproducible rpm logic, so I added it back in
• I removed the source tarball step from the build since we don't actually need a tarball, we're just placing files.

Since this is for testing/prototyping, I'd like to merge it, and have a wider discussion with the team about build process, at which point I anticipate things will change further.

[cfm]

I've caught up with @rocodes about the state of this repository and pull request and agree that this diff looks good for:

1. getting this set up with our usual containerized building in GitHub Actions for rapid iteration; and
2. laying the foundation for later building via qubes-builder in GitLab.

[rocodes]

Thank you @cfm and @deeplow for the reviews. What I think I will do since this is now an FPF repo is merge this PR, submit a followup with some basic housekeeping (CI, security.md and license file), and do some comparisons as @deeplow suggests with qubes-builder. I anticipate some more changes as we figure out exactly our building/packaging story, and I know it's a bit unusual to have both types of builds in the repo for now, but I view this as iterative and subject to change as we move towards a prod package, and for now the flexibility is helpful.

thanks both :)