Bug 2328647

Copr build:
https://copr.fedorainfracloud.org/coprs/build/8310174
(failed)

Build log:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2328647-trustee-attester/fedora-rawhide-x86_64/08310174-trustee-attester/builder-live.log.gz

Please make sure the package builds successfully at least for Fedora Rawhide.

- If the build failed for unrelated reasons (e.g. temporary network
  unavailability), please ignore it.
- If the build failed because of missing BuildRequires, please make sure they
  are listed in the "Depends On" field


---
This comment was created by the fedora-review-service
https://github.com/FrostyX/fedora-review-service

If you want to trigger a new Copr build, add a comment containing new
Spec and SRPM URLs or [fedora-review-service-build] string.

Just a few comments:
- Why do we use 'trustee-attester' name for the source package? Upstream this is part of 'Confidential Container Tools and Components' so even if we don't package other tools from this collection now, they may come handy afterwards. Would it rather make sense to name the source package e.g. 'coco-guest-components'?

- Where does the manpage come from? Assuming it was written from scratch for Fedora, would it rather make sense to submit it upstream so it doesn't diverge when code changes?
Nitpick: I would suggest to not hardcode '.gz' for the manpage compression as these things tend to change. I'd rather do

%{_mandir}/man1/trustee-attester.1*

- It is a bit weird that the actual program comes from a patch (0001-Add-trustee-attester-a-simple-tool-to-fetch-secrets-.patch), this is fragile as it may stop building/working with upstream code changes. Any chance it can be pushed upstream?

Vitaly, thank you for reviewing.

(In reply to Vitaly Kuznetsov from comment #2)
> - Why do we use 'trustee-attester' name for the source package? Upstream
> this is part of 'Confidential Container Tools and Components' so even if we
> don't package other tools from this collection now, they may come handy
> afterwards. Would it rather make sense to name the source package e.g.
> 'coco-guest-components'?

That's a good point. I was thinking about it too.
Currently the project does not publish crates on crates.io.
When that happens the number of crates may change - for example, there
may be only 1 'dep' crate instead of 3.
Possibly trustee-attester will get its own crate in the future.

> 
> - Where does the manpage come from? Assuming it was written from scratch for
> Fedora, would it rather make sense to submit it upstream so it doesn't
> diverge when code changes?
It was written from scratch for Fedora.
I'll send it upstream too.

> Nitpick: I would suggest to not hardcode '.gz' for the manpage compression
> as these things tend to change. I'd rather do
> 
> %{_mandir}/man1/trustee-attester.1*

I'll do that.


> 
> - It is a bit weird that the actual program comes from a patch
> (0001-Add-trustee-attester-a-simple-tool-to-fetch-secrets-.patch), this is
> fragile as it may stop building/working with upstream code changes. Any
> chance it can be pushed upstream?
It is a bit weird. It's already pushed upstream, but not in release 0.10.0.
I can create a tarball based on 'main' (and git describe), instead of 'v0.10.0'

Following the suggestions by Vitaly in comment 2:
1. The package is to be renamed to trustee-guest-components.
   This ReviewRequest bug is to be closed. A new ReviewRequest for trustee-guest-components was created (bug 2332550).
2. The manpage is removed. Once sent and accepted upstream, it will be re-added.
3. The source is now based on a specific commit, and not on v0.10.0
4. There is no need for attestation-agent/deps/sev and so it too is removed from workspace members.

*** This bug has been marked as a duplicate of bug 2332550 ***