Firecracker dependency crates

[David Michael]

Hi,

I submitted a bunch of PRs to Rust crates that are already packaged in
Fedora to work towards adding Firecracker.  (There is some more
context on the devel list.[0])  Here is the list of links in a
reviewable order:

https://src.fedoraproject.org/rpms/rust-crypto-common/pull-request/1
https://src.fedoraproject.org/rpms/rust-universal-hash/pull-request/1
https://src.fedoraproject.org/rpms/rust-polyval/pull-request/1
https://src.fedoraproject.org/rpms/rust-ghash/pull-request/1
https://src.fedoraproject.org/rpms/rust-aead/pull-request/1
https://src.fedoraproject.org/rpms/rust-aes-gcm/pull-request/1
https://src.fedoraproject.org/rpms/rust-cookie/pull-request/1
https://src.fedoraproject.org/rpms/rust-criterion-plot/pull-request/1
https://src.fedoraproject.org/rpms/rust-criterion/pull-request/3

These updates are all to the latest release branch of the crates in
Fedora.  I tried to check repoquery to make sure everything is updated
that depends on the crates' release branch, but I don't know if my
queries caught everything.  Updates were mostly done by running the
current rust2rpm and backporting any adjustments.

The only non-Firecracker dependency that was updated is the cookie
crate to support newer aes-gcm.  It was updated to a new patchlevel
version in the same release branch, so its dependencies shouldn't be
affected.  This would also unretire criterion, which is an optional
build dependency for around half a dozen new crates.

This is only a first step to update the crates already in Fedora.  I
have the full set of crates together in a Git repo[1].  If the PRs
look okay, I can start submitting review requests for the new crates.

Thanks.

David

[0]
https://lists.fedoraproject.org/archives/list/[e-mail].o...
[1] https://github.com/dm0-/copr-firecracker

[David Michael]

On Thu, Mar 9, 2023 at 7:30 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  This is only a first step to update the crates already in Fedora.  I
>  have the full set of crates together in a Git repo[1].  If the PRs
>  look okay, I can start submitting review requests for the new crates. 
A quick follow up to this, the criterion dependencies were patched
out, so the list of PRs is now:

https://src.fedoraproject.org/rpms/rust-crypto-common/pull-request/1
https://src.fedoraproject.org/rpms/rust-universal-hash/pull-request/1
https://src.fedoraproject.org/rpms/rust-polyval/pull-request/1
https://src.fedoraproject.org/rpms/rust-ghash/pull-request/1
https://src.fedoraproject.org/rpms/rust-aead/pull-request/1
https://src.fedoraproject.org/rpms/rust-aes-gcm/pull-request/1
https://src.fedoraproject.org/rpms/rust-cookie/pull-request/1

In addition, there are two older compatibility packages for crates
already in Fedora.  The guidelines say they don't require a package
review, but does anyone want to quickly look over the specs anyway?
They shouldn't be notably different from the latest packaged crates.

https://github.com/dm0-/copr-firecracker/blob/master/rust-bindgen0.60.spec
https://github.com/dm0-/copr-firecracker/blob/master/rust-kvm-ioctls0.12....

Thanks.

David

[Fabio Valentini]

On Fri, Mar 10, 2023 at 10:57 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  On Thu, Mar 9, 2023 at 7:30 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  > This is only a first step to update the crates already in Fedora.  I
>  > have the full set of crates together in a Git repo[1].  If the PRs
>  > look okay, I can start submitting review requests for the new crates.
>
>  A quick follow up to this, the criterion dependencies were patched
>  out, so the list of PRs is now:
>
>  https://src.fedoraproject.org/rpms/rust-crypto-common/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-universal-hash/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-polyval/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-ghash/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-aead/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-aes-gcm/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-cookie/pull-request/1 
Sorry, I've been out sick today. Not sure if I'll be able to review
your PRs this weekend.

>  In addition, there are two older compatibility packages for crates
>  already in Fedora.  The guidelines say they don't require a package
>  review, but does anyone want to quickly look over the specs anyway?
>  They shouldn't be notably different from the latest packaged crates.
>
>  https://github.com/dm0-/copr-firecracker/blob/master/rust-bindgen0.60.spec
>  https://github.com/dm0-/copr-firecracker/blob/master/rust-kvm-ioctls0.12.... 
Before you create a compat package for bindgen 0.60, consider patching
the crate that uses it to use either v0.59 or v0.63.
The API differences between bindgen versions are usually really small,
so patching the dependency to be on bindgen v0.63 instead of v0.60
should work just fine.

Fabio

[David Michael]

On Fri, Mar 10, 2023 at 5:02 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Fri, Mar 10, 2023 at 10:57 PM David Michael
> <fedora.dm0(a)gmail.com&gt; wrote:
>  >
>  > On Thu, Mar 9, 2023 at 7:30 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  > > This is only a first step to update the crates already in Fedora.  I
>  > > have the full set of crates together in a Git repo[1].  If the PRs
>  > > look okay, I can start submitting review requests for the new crates.
>  >
>  > A quick follow up to this, the criterion dependencies were patched
>  > out, so the list of PRs is now:
>  >
>  > https://src.fedoraproject.org/rpms/rust-crypto-common/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-universal-hash/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-polyval/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-ghash/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-aead/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-aes-gcm/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-cookie/pull-request/1
>
>  Sorry, I've been out sick today. Not sure if I'll be able to review
>  your PRs this weekend. 
Okay, there is no rush.  (I sent this to the list just to update
anyone who might be reading along, not to pester.)

>  > In addition, there are two older compatibility packages for
> crates
>  > already in Fedora.  The guidelines say they don't require a package
>  > review, but does anyone want to quickly look over the specs anyway?
>  > They shouldn't be notably different from the latest packaged crates.
>  >
>  > https://github.com/dm0-/copr-firecracker/blob/master/rust-bindgen0.60.spec
>  > https://github.com/dm0-/copr-firecracker/blob/master/rust-kvm-ioctls0.12....
>
>  Before you create a compat package for bindgen 0.60, consider patching
>  the crate that uses it to use either v0.59 or v0.63.
>  The API differences between bindgen versions are usually really small,
>  so patching the dependency to be on bindgen v0.63 instead of v0.60
>  should work just fine. 
The affected crate is userfaultfd-sys, and I've reverted its commit
that bumped bindgen to the 0.60 branch.  It looks like the repository
hasn't had a commit in about half a year, so if it's a slow-moving
project, staying on the 0.59 compat package avoids repeatedly having
to port to the latest bindgen branch.

So now there is just the kvm-ioctls compat package, which is a
dependency of several crates bundled in Firecracker itself.  It's
basically the same as the latest branch spec.

https://github.com/dm0-/copr-firecracker/blob/master/rust-kvm-ioctls0.12....

Thanks.

David

[Sergio Lopez]

On Fri, Mar 10, 2023 at 11:02 PM Fabio Valentini <decathorpe(a)gmail.com&gt;
wrote:

>  On Fri, Mar 10, 2023 at 10:57 PM David Michael
> <fedora.dm0(a)gmail.com&gt;
>  wrote:
>  >
>  > On Thu, Mar 9, 2023 at 7:30 PM David Michael <fedora.dm0(a)gmail.com&gt;
>  wrote:
>  > > This is only a first step to update the crates already in Fedora.  I
>  > > have the full set of crates together in a Git repo[1].  If the PRs
>  > > look okay, I can start submitting review requests for the new crates.
>  >
>  > A quick follow up to this, the criterion dependencies were patched
>  > out, so the list of PRs is now:
>  >
>  > https://src.fedoraproject.org/rpms/rust-crypto-common/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-universal-hash/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-polyval/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-ghash/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-aead/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-aes-gcm/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-cookie/pull-request/1
>
>  Sorry, I've been out sick today. Not sure if I'll be able to review
>  your PRs this weekend.
>
>  > In addition, there are two older compatibility packages for crates
>  > already in Fedora.  The guidelines say they don't require a package
>  > review, but does anyone want to quickly look over the specs anyway?
>  > They shouldn't be notably different from the latest packaged crates.
>  >
>  >
>  https://github.com/dm0-/copr-firecracker/blob/master/rust-bindgen0.60.spec
>  >
>  https://github.com/dm0-/copr-firecracker/blob/master/rust-kvm-ioctls0.12....
>
>  Before you create a compat package for bindgen 0.60, consider patching
>  the crate that uses it to use either v0.59 or v0.63.
>  The API differences between bindgen versions are usually really small,
>  so patching the dependency to be on bindgen v0.63 instead of v0.60
>  should work just fine.
>  
Same goes for rust-kvm-ioctls. From the experience of supporting 0.13 in
libkrun (which has a very similar code base), this should only require a
very small patch.

Sergio.

[David Michael]

On Fri, Mar 10, 2023 at 6:23 PM Sergio Lopez <slp(a)redhat.com&gt; wrote:
>  On Fri, Mar 10, 2023 at 11:02 PM Fabio Valentini
> <decathorpe(a)gmail.com&gt; wrote:
> > On Fri, Mar 10, 2023 at 10:57 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
> > > On Thu, Mar 9, 2023 at 7:30 PM David Michael <fedora.dm0(a)gmail.com&gt;
> wrote:
> > > > This is only a first step to update the crates already in Fedora.  I
> > > > have the full set of crates together in a Git repo[1].  If the PRs
> > > > look okay, I can start submitting review requests for the new crates.
> > >
> > > A quick follow up to this, the criterion dependencies were patched
> > > out, so the list of PRs is now:
> > >
> > > https://src.fedoraproject.org/rpms/rust-crypto-common/pull-request/1
> > > https://src.fedoraproject.org/rpms/rust-universal-hash/pull-request/1
> > > https://src.fedoraproject.org/rpms/rust-polyval/pull-request/1
> > > https://src.fedoraproject.org/rpms/rust-ghash/pull-request/1
> > > https://src.fedoraproject.org/rpms/rust-aead/pull-request/1
> > > https://src.fedoraproject.org/rpms/rust-aes-gcm/pull-request/1
> > > https://src.fedoraproject.org/rpms/rust-cookie/pull-request/1
> >
> > Sorry, I've been out sick today. Not sure if I'll be able to review
> > your PRs this weekend.
> >
> > > In addition, there are two older compatibility packages for crates
> > > already in Fedora.  The guidelines say they don't require a package
> > > review, but does anyone want to quickly look over the specs anyway?
> > > They shouldn't be notably different from the latest packaged crates.
> > >
> > > https://github.com/dm0-/copr-firecracker/blob/master/rust-bindgen0.60.spec
> > > https://github.com/dm0-/copr-firecracker/blob/master/rust-kvm-ioctls0.12....
> >
> > Before you create a compat package for bindgen 0.60, consider patching
> > the crate that uses it to use either v0.59 or v0.63.
> > The API differences between bindgen versions are usually really small,
> > so patching the dependency to be on bindgen v0.63 instead of v0.60
> > should work just fine.
>
>  Same goes for rust-kvm-ioctls. From the experience of supporting 0.13 in libkrun (which
> has a very similar code base), this should only require a very small patch. 
Okay, the diff between versions just looks like additions to the API,
so I've added a patch to firecracker.spec to update it.  Now there are
no compat packages.

Relatedly, there are two new crates (cargo_toml and crc64) that have
version requirements older than their latest branch on crates.io, and
I added the specs with a version suffix to indicate the branch
dependency.  Is that an acceptable way to handle it, or should new
crates always be unsuffixed and have their users be patched whenever
they're updated?

Thanks.

David

[Fabio Valentini]

On Sat, Mar 11, 2023 at 1:29 AM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  Relatedly, there are two new crates (cargo_toml and crc64) that have
>  version requirements older than their latest branch on crates.io, and
>  I added the specs with a version suffix to indicate the branch
>  dependency.  Is that an acceptable way to handle it, or should new
>  crates always be unsuffixed and have their users be patched whenever
>  they're updated? 
It's fine if it's not the latest version, if what you're working on is
not compatible with it, but
if you're only packaging a single version, then that package must not
have a version suffix.
Suffixes are only added when there's more than one version of the same
package in Fedora.

Fabio

[David Michael]

On Tue, Mar 14, 2023 at 1:19 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Sat, Mar 11, 2023 at 1:29 AM David Michael
> <fedora.dm0(a)gmail.com&gt; wrote:
>  >
>  > Relatedly, there are two new crates (cargo_toml and crc64) that have
>  > version requirements older than their latest branch on crates.io, and
>  > I added the specs with a version suffix to indicate the branch
>  > dependency.  Is that an acceptable way to handle it, or should new
>  > crates always be unsuffixed and have their users be patched whenever
>  > they're updated?
>
>  It's fine if it's not the latest version, if what you're working on is
>  not compatible with it, but
>  if you're only packaging a single version, then that package must not
>  have a version suffix.
>  Suffixes are only added when there's more than one version of the same
>  package in Fedora. 
Okay, I've updated the affected specs to drop suffixes.  They are
crc64 (the 2.0 branch is latest, but versionize depends on 1.0) and
cargo_toml (the 1.16 branch is latest, but Firecracker tests depend on
1.13).

Thanks.

David

[David Michael]

On Fri, Mar 10, 2023 at 4:57 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  https://src.fedoraproject.org/rpms/rust-crypto-common/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-universal-hash/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-polyval/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-ghash/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-aead/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-aes-gcm/pull-request/1
>  https://src.fedoraproject.org/rpms/rust-cookie/pull-request/1 
Thanks for applying those changes, all of the dependencies already in
Fedora 37 are working now.  In case Fedora 36 should also be
supported, these branches would need to be fast-forwarded/created:

https://src.fedoraproject.org/rpms/rust-vmm-sys-util/commits
https://src.fedoraproject.org/rpms/rust-vm-memory/commits
https://src.fedoraproject.org/rpms/rust-kvm-bindings/commits
https://src.fedoraproject.org/rpms/rust-kvm-ioctls/commits

And these would need to be updated for Fedora 38:

https://src.fedoraproject.org/rpms/rust-kvm-ioctls/commits
https://src.fedoraproject.org/rpms/rust-timerfd/commits

On a different note, I don't know if Firecracker in Fedora will meet
the requirements of the project I am working on long term--we'll
likely end up on podman+krun.  I will still be working on it for the
near future, but I'd like to avoid adding ~15 new packages and having
to orphan them in a few months because I no longer use them.  If I
submit review requests, would anyone (or the SIG itself) co-maintain
the crates and/or Firecracker in case I am no longer able to use them
later?  Should I ask on the devel list instead?  Otherwise I think I
should probably just maintain the builds in Copr.

Thanks.

David

[Fabio Valentini]

On Tue, Mar 21, 2023 at 3:22 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  On Fri, Mar 10, 2023 at 4:57 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  > https://src.fedoraproject.org/rpms/rust-crypto-common/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-universal-hash/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-polyval/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-ghash/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-aead/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-aes-gcm/pull-request/1
>  > https://src.fedoraproject.org/rpms/rust-cookie/pull-request/1
>
>  Thanks for applying those changes, all of the dependencies already in
>  Fedora 37 are working now. 
Great! Good to know, and thanks for your help :)

>  In case Fedora 36 should also be
>  supported, these branches would need to be fast-forwarded/created:
>
>  https://src.fedoraproject.org/rpms/rust-vmm-sys-util/commits
>  https://src.fedoraproject.org/rpms/rust-vm-memory/commits
>  https://src.fedoraproject.org/rpms/rust-kvm-bindings/commits
>  https://src.fedoraproject.org/rpms/rust-kvm-ioctls/commits
>
>  And these would need to be updated for Fedora 38:
>
>  https://src.fedoraproject.org/rpms/rust-kvm-ioctls/commits
>  https://src.fedoraproject.org/rpms/rust-timerfd/commits 
The packages for the KVM related stuff are maintained by Red Hat employees.
You will probably need to reach out to them directly, I don't think
any of them are subscribed to this list.

The package for the timerfd crate has been removed ("retired") from
Fedora 38 and rawhide because no packages used it for over a year.
It would need to be un-retired. Since I retired it only four weeks
ago, that would not require a package re-review yet.
I was the previous maintainer, so if you need a timerfd package, I can
submit the paperwork to add back the package.

>  On a different note, I don't know if Firecracker in Fedora will
> meet
>  the requirements of the project I am working on long term--we'll
>  likely end up on podman+krun.  I will still be working on it for the
>  near future, but I'd like to avoid adding ~15 new packages and having
>  to orphan them in a few months because I no longer use them.  If I
>  submit review requests, would anyone (or the SIG itself) co-maintain
>  the crates and/or Firecracker in case I am no longer able to use them
>  later?  Should I ask on the devel list instead?  Otherwise I think I
>  should probably just maintain the builds in Copr. 
If people think that having Firecracker packages available in Fedora
is worthwhile, then sure, the Rust SIG (so at this point, mostly me)
will keep library dependencies and Firecracker itself in working
order.
*hint hint* https://github.com/sponsors/decathorpe

Fabio

[David Michael]

On Tue, Mar 21, 2023 at 10:40 AM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Tue, Mar 21, 2023 at 3:22 PM David Michael
> <fedora.dm0(a)gmail.com&gt; wrote:
>  > And these would need to be updated for Fedora 38:
>  >
>  > https://src.fedoraproject.org/rpms/rust-kvm-ioctls/commits
>  > https://src.fedoraproject.org/rpms/rust-timerfd/commits
>
>  The package for the timerfd crate has been removed ("retired") from
>  Fedora 38 and rawhide because no packages used it for over a year.
>  It would need to be un-retired. Since I retired it only four weeks
>  ago, that would not require a package re-review yet.
>  I was the previous maintainer, so if you need a timerfd package, I can
>  submit the paperwork to add back the package. 
Okay, I could also submit the request to be the primary maintainer
since Firecracker is the only user of it, but if you want to take the
package again, that would be helpful.  I'll send PRs and branch
requests for the other crate repos.  Here are review requests for the
new crates, mostly unmodified from automatically generated specs:

https://bugzilla.redhat.com/show_bug.cgi?id=2181020 cargo_toml
https://bugzilla.redhat.com/show_bug.cgi?id=2181021 crc64
https://bugzilla.redhat.com/show_bug.cgi?id=2181022 device_tree
https://bugzilla.redhat.com/show_bug.cgi?id=2181023 event-manager
https://bugzilla.redhat.com/show_bug.cgi?id=2181025 linux-loader
https://bugzilla.redhat.com/show_bug.cgi?id=2181028 userfaultfd
https://bugzilla.redhat.com/show_bug.cgi?id=2181029 userfaultfd-sys
https://bugzilla.redhat.com/show_bug.cgi?id=2181030 versionize
https://bugzilla.redhat.com/show_bug.cgi?id=2181033 versionize_derive
https://bugzilla.redhat.com/show_bug.cgi?id=2181035 vm-allocator
https://bugzilla.redhat.com/show_bug.cgi?id=2181036 vm-fdt
https://bugzilla.redhat.com/show_bug.cgi?id=2181038 vm-superio
https://bugzilla.redhat.com/show_bug.cgi?id=2181039 firecracker

And in case binary builds are useful, this is the Copr link again:
https://copr.fedorainfracloud.org/coprs/dm0/Firecracker

>  > On a different note, I don't know if Firecracker in Fedora
> will meet
>  > the requirements of the project I am working on long term--we'll
>  > likely end up on podman+krun.  I will still be working on it for the
>  > near future, but I'd like to avoid adding ~15 new packages and having
>  > to orphan them in a few months because I no longer use them.  If I
>  > submit review requests, would anyone (or the SIG itself) co-maintain
>  > the crates and/or Firecracker in case I am no longer able to use them
>  > later?  Should I ask on the devel list instead?  Otherwise I think I
>  > should probably just maintain the builds in Copr.
>
>  If people think that having Firecracker packages available in Fedora
>  is worthwhile, then sure, the Rust SIG (so at this point, mostly me)
>  will keep library dependencies and Firecracker itself in working
>  order.
>  *hint hint* https://github.com/sponsors/decathorpe 
The project owner sponsored you, thanks for all your help.

David

[Fabio Valentini]

On Wed, Mar 22, 2023 at 11:21 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  On Tue, Mar 21, 2023 at 10:40 AM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  > On Tue, Mar 21, 2023 at 3:22 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  > > And these would need to be updated for Fedora 38:
>  > >
>  > > https://src.fedoraproject.org/rpms/rust-kvm-ioctls/commits
>  > > https://src.fedoraproject.org/rpms/rust-timerfd/commits
>  >
>  > The package for the timerfd crate has been removed ("retired") from
>  > Fedora 38 and rawhide because no packages used it for over a year.
>  > It would need to be un-retired. Since I retired it only four weeks
>  > ago, that would not require a package re-review yet.
>  > I was the previous maintainer, so if you need a timerfd package, I can
>  > submit the paperwork to add back the package.
>
>  Okay, I could also submit the request to be the primary maintainer
>  since Firecracker is the only user of it, but if you want to take the
>  package again, that would be helpful.  I'll send PRs and branch
>  requests for the other crate repos.  Here are review requests for the
>  new crates, mostly unmodified from automatically generated specs: 
I've also filed the paperwork to get rust-timerfd un-retired:
https://pagure.io/releng/issue/11354

>  https://bugzilla.redhat.com/show_bug.cgi?id=2181020 cargo_toml
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181021 crc64
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181022 device_tree
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181023 event-manager
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181025 linux-loader
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181028 userfaultfd
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181029 userfaultfd-sys
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181030 versionize
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181033 versionize_derive
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181035 vm-allocator
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181036 vm-fdt
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181038 vm-superio
>  https://bugzilla.redhat.com/show_bug.cgi?id=2181039 firecracker
>
>  And in case binary builds are useful, this is the Copr link again:
>  https://copr.fedorainfracloud.org/coprs/dm0/Firecracker 
Great, I'll go through the reviews over the next days.

>  > > On a different note, I don't know if Firecracker in
> Fedora will meet
>  > > the requirements of the project I am working on long term--we'll
>  > > likely end up on podman+krun.  I will still be working on it for the
>  > > near future, but I'd like to avoid adding ~15 new packages and having
>  > > to orphan them in a few months because I no longer use them.  If I
>  > > submit review requests, would anyone (or the SIG itself) co-maintain
>  > > the crates and/or Firecracker in case I am no longer able to use them
>  > > later?  Should I ask on the devel list instead?  Otherwise I think I
>  > > should probably just maintain the builds in Copr.
>  >
>  > If people think that having Firecracker packages available in Fedora
>  > is worthwhile, then sure, the Rust SIG (so at this point, mostly me)
>  > will keep library dependencies and Firecracker itself in working
>  > order.
>  > *hint hint* https://github.com/sponsors/decathorpe
>
>  The project owner sponsored you, thanks for all your help. 
Awesome, this was a very nice surprise :) Thanks!

Fabio

[David Michael]

On Thu, Mar 23, 2023 at 9:46 AM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181020 cargo_toml
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181021 crc64
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181022 device_tree
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181023 event-manager
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181025 linux-loader
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181028 userfaultfd
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181029 userfaultfd-sys
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181030 versionize
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181033 versionize_derive
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181035 vm-allocator
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181036 vm-fdt
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181038 vm-superio
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2181039 firecracker
>  >
>  > And in case binary builds are useful, this is the Copr link again:
>  > https://copr.fedorainfracloud.org/coprs/dm0/Firecracker
>
>  Great, I'll go through the reviews over the next days. 
Thanks again for reviewing those.  All of the crates are now in Fedora 37+.

The last one, Firecracker itself, is still unassigned, though.  Were
you intending to review that as well or should I ask about it in
devel?  (While it's not automatically generated like the others, the
spec is basically just running "cargo build" in a workspace.)

Thanks.

David

[Fabio Valentini]

On Thu, Mar 30, 2023 at 3:26 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  On Thu, Mar 23, 2023 at 9:46 AM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181020 cargo_toml
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181021 crc64
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181022 device_tree
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181023 event-manager
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181025 linux-loader
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181028 userfaultfd
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181029 userfaultfd-sys
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181030 versionize
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181033 versionize_derive
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181035 vm-allocator
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181036 vm-fdt
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181038 vm-superio
>  > > https://bugzilla.redhat.com/show_bug.cgi?id=2181039 firecracker
>  > >
>  > > And in case binary builds are useful, this is the Copr link again:
>  > > https://copr.fedorainfracloud.org/coprs/dm0/Firecracker
>  >
>  > Great, I'll go through the reviews over the next days.
>
>  Thanks again for reviewing those.  All of the crates are now in Fedora 37+.
>
>  The last one, Firecracker itself, is still unassigned, though.  Were
>  you intending to review that as well or should I ask about it in
>  devel?  (While it's not automatically generated like the others, the
>  spec is basically just running "cargo build" in a workspace.) 
I planned on reviewing firecracker as well once all dependencies are
available (unless somebody beats me to it).
There's some other things I need to work on today, so I might not get
to it until tomorrow or this weekend.

Fabio

[David Michael]

On Thu, Mar 30, 2023 at 11:53 AM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Thu, Mar 30, 2023 at 3:26 PM David Michael
> <fedora.dm0(a)gmail.com&gt; wrote:
>  > On Thu, Mar 23, 2023 at 9:46 AM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181020 cargo_toml
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181021 crc64
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181022 device_tree
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181023 event-manager
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181025 linux-loader
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181028 userfaultfd
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181029 userfaultfd-sys
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181030 versionize
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181033 versionize_derive
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181035 vm-allocator
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181036 vm-fdt
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181038 vm-superio
>  > > > https://bugzilla.redhat.com/show_bug.cgi?id=2181039 firecracker
>  > > >
>  > > > And in case binary builds are useful, this is the Copr link again:
>  > > > https://copr.fedorainfracloud.org/coprs/dm0/Firecracker
>  > >
>  > > Great, I'll go through the reviews over the next days.
>  >
>  > Thanks again for reviewing those.  All of the crates are now in Fedora 37+.
>  >
>  > The last one, Firecracker itself, is still unassigned, though.  Were
>  > you intending to review that as well or should I ask about it in
>  > devel?  (While it's not automatically generated like the others, the
>  > spec is basically just running "cargo build" in a workspace.)
>
>  I planned on reviewing firecracker as well once all dependencies are
>  available (unless somebody beats me to it).
>  There's some other things I need to work on today, so I might not get
>  to it until tomorrow or this weekend. 
Let me know if you don't expect to have time for this review for a
while, and I can ask about it on devel.

I saw the new supported-arches option in rust2rpm specifically
mentioned being used to allow enabling more features.  Is that the
only intended use case, or could it be used in place of Exclu*eArch in
all lib crates?  I'm specifically wondering about the linux-loader
crate here.  While it isn't a feature dependency, allowing it to be
installed on unsupported platforms would support cross-compiling which
could be handy in general.  (Firecracker has other dependencies like
kvm-ioctls that would also need to be updated for it to be
cross-compiled from an unsupported platform, but linux-loader is the
only affected package in this set.)

Thanks.

David

[Fabio Valentini]

On Thu, Apr 6, 2023 at 6:13 PM David Michael <fedora.dm0(a)gmail.com&gt; wrote:
>  On Thu, Mar 30, 2023 at 11:53 AM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  > I planned on reviewing firecracker as well once all dependencies are
>  > available (unless somebody beats me to it).
>  > There's some other things I need to work on today, so I might not get
>  > to it until tomorrow or this weekend.
>
>  Let me know if you don't expect to have time for this review for a
>  while, and I can ask about it on devel. 
Sorry about the delay. I've been out sick since last weekend, and my
eyes still hurt when I look at screens for too long.
I will try to get an initial review pass done today.

>  I saw the new supported-arches option in rust2rpm specifically
>  mentioned being used to allow enabling more features.  Is that the
>  only intended use case, or could it be used in place of Exclu*eArch in
>  all lib crates?  I'm specifically wondering about the linux-loader
>  crate here.  While it isn't a feature dependency, allowing it to be
>  installed on unsupported platforms would support cross-compiling which
>  could be handy in general.  (Firecracker has other dependencies like
>  kvm-ioctls that would also need to be updated for it to be
>  cross-compiled from an unsupported platform, but linux-loader is the
>  only affected package in this set.) 
This feature is intended to make library crates *available* on
unsupported architectures as a workaround for limitations of RPM and
Fedora build infrastructure ... but using system packages for cross
compilation is most likely never going to work (mostly because we need
to apply non-portable patches). Cross compilation is - for now - not a
supported use case at all (see also the other thread about compiling
librsvg2 for MinGW).

Fabio