Bug 2308448 - Review Request: rust-rublk - Rust block device in userspace
Summary: Review Request: rust-rublk - Rust block device in userspace
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Fabio Valentini
QA Contact: Fedora Extras Quality Assurance
URL: https://crates.io/crates/rublk
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-08-29 08:10 UTC by Ming Lei
Modified: 2024-09-23 12:43 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-09-23 04:14:40 UTC
Type: ---
Embargoed:
decathorpe: fedora-review+


Attachments (Terms of Use)
The .spec file difference from Copr build 7953278 to 7955309 (1003 bytes, patch)
2024-08-30 14:11 UTC, Fedora Review Service
no flags Details | Diff

Description Ming Lei 2024-08-29 08:10:23 UTC
Spec URL: https://people.redhat.com/minlei/fedpkg/rublk/v1/rust-rublk.spec

SRPM URL: https://people.redhat.com/minlei/fedpkg/rublk/v1/rust-rublk-0.2.0-1.fc40.src.rpm

Description: 
   rust-ublk is one binary which implements generic linux ublk userspace 
   drivers(targets). CONFIG_BLK_DEV_UBLK is enabled in Fedora for a while,
   and is enabled in RHEL10 too.
 
   upstream: https://github.com/ublk-org/rublk

   So far, it is packaged from vendor tarball via 'rust2rpm -V' because some
   dependent crates can't be pull into Fedora in short time. Follows all
   non-present crates in Fedora:
   	
   	smol		MIT or Apache-2.0
   	qcow2-rs	MIT or Apache-2.0
   	shared_memory	MIT or Apache-2.0
   	ilog		MIT
   	derive_setters  MIT or Apache-2.0
   	block-utils	MIT
   	bitmaps		MPL-2.0+

    I'd plan to pull them step-by-step and finally package rublk in non-verndor tarball. Another motivation is that libublk-rs needs to be package too, which
is one library and can't be done in vendor mode.

    Need sponsor. 	

Fedora Account System Username: minlei2

Comment 1 Fabio Valentini 2024-08-29 17:16:01 UTC
I'll take a look.

Quick first impressions:

1. FIXME

> # FIXME: paste output of %%cargo_license_summary here
> License:        # FIXME

This needs to be addressed.

2. BuildRequires:  clang

Likely you only need clang-libs, if this is due to bindgen.

3. License:        GPL-2.0

"GPL-2.0" is a deprecated identifier in SPDX 3.0 and not valid in Fedora.
You need to fix this to be either "GPL-2.0-only" or "GPL-2.0-or-later", ideally upstream.

4. "%cargo_test -- --no-run"

This is both a) not the way to disable tests, (that would be flipping the %check bcond), and b) *if* you need to disable tests, it needs to be documented *why*.

So you need to remove the "--no-run" arg here and either 1) flip the check bcond and document why you cannot run *any* tests, or 2) run tests and just skip specific ones that can't be run.

Comment 2 mulhern 2024-08-29 18:16:29 UTC
> 
> 4. "%cargo_test -- --no-run"
> 
> This is both a) not the way to disable tests, (that would be flipping the
> %check bcond), and b) *if* you need to disable tests, it needs to be
> documented *why*.
> 
> So you need to remove the "--no-run" arg here and either 1) flip the check
> bcond and document why you cannot run *any* tests, or 2) run tests and just
> skip specific ones that can't be run.

The --no-run option does something substantially useful; it checks that the tests can be
built into an executable without actually trying to run them.
Ensuring that the tests can be built is worth doing during the package build process, I think.

For this package the tests that are available are integration tests.
The requirements to run the tests are far too heavy for the package build environment.

So, I think it should be kept as is, but adding the following comment above the %cargo_test line,
which I propose to Ming Lei:

# Just build the tests. The tests are integration tests that require extensive
# environment setup to be run, as documented in the ci directory in the upstream
# GitHub repository.

Something like that.

Comment 3 Fedora Review Service 2024-08-29 21:17:22 UTC
Copr build:
https://copr.fedorainfracloud.org/coprs/build/7953278
(failed)

Build log:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2308448-rust-rublk/fedora-rawhide-x86_64/07953278-rust-rublk/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.

Comment 4 Ming Lei 2024-08-30 13:54:07 UTC
Hi Fabio,

(In reply to Fabio Valentini from comment #1)
> I'll take a look.

Thanks for the review!

> 
> Quick first impressions:
> 
> 1. FIXME
> 
> > # FIXME: paste output of %%cargo_license_summary here
> > License:        # FIXME
> 

Fixed in upstream by updating Licence to GPL-2.0-or-later

> This needs to be addressed.
> 
> 2. BuildRequires:  clang
> 
> Likely you only need clang-libs, if this is due to bindgen.

Will fix it in next post.

> 
> 3. License:        GPL-2.0
> 
> "GPL-2.0" is a deprecated identifier in SPDX 3.0 and not valid in Fedora.
> You need to fix this to be either "GPL-2.0-only" or "GPL-2.0-or-later",
> ideally upstream.

Fixed in upstream by updating Licence to GPL-2.0-or-later


> 
> 4. "%cargo_test -- --no-run"
> 
> This is both a) not the way to disable tests, (that would be flipping the
> %check bcond), and b) *if* you need to disable tests, it needs to be
> documented *why*.
> 
> So you need to remove the "--no-run" arg here and either 1) flip the check
> bcond and document why you cannot run *any* tests, or 2) run tests and just
> skip specific ones that can't be run.

The test depends on device of /dev/ublk-control which isn't available in build
environment, that is why I added '--no-run'.

Now the test has been fixed to allow to run pass in case of missing '/dev/ublk-control'.


Thanks,

Comment 5 Ming Lei 2024-08-30 13:55:08 UTC
(In reply to Fedora Review Service from comment #3)
> Copr build:
> https://copr.fedorainfracloud.org/coprs/build/7953278
> (failed)
> 
> Build log:
> https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-
> review-2308448-rust-rublk/fedora-rawhide-x86_64/07953278-rust-rublk/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
> 

Sorrry for the build failure, which is caused by obsolte .spec in src.rpm, since
'cargo test' is still run.

Comment 6 Ming Lei 2024-08-30 13:58:10 UTC
Hello Guys,

Please review v2, in which all issues in comment #1 and #3 are addressed.


Spec URL: https://people.redhat.com/minlei/fedpkg/rublk/v2/rust-rublk.spec

SRPM URL: https://people.redhat.com/minlei/fedpkg/rublk/v2/rust-rublk-0.2.1-1.fc40.src.rpm

Description: 
   rust-ublk is one binary which implements generic linux ublk userspace 
   drivers(targets). CONFIG_BLK_DEV_UBLK is enabled in Fedora for a while,
   and is enabled in RHEL10 too.
 
   upstream: https://github.com/ublk-org/rublk

   So far, it is packaged from vendor tarball via 'rust2rpm -V' because some
   dependent crates can't be pull into Fedora in short time. Follows all
   non-present crates in Fedora:
   	
   	smol		MIT or Apache-2.0
   	qcow2-rs	MIT or Apache-2.0
   	shared_memory	MIT or Apache-2.0
   	ilog		MIT
   	derive_setters  MIT or Apache-2.0
   	block-utils	MIT
   	bitmaps		MPL-2.0+

    I'd plan to pull them step-by-step and finally package rublk in non-verndor tarball. Another motivation is that libublk-rs needs to be package too, which
is one library and can't be done in vendor mode.

    Need sponsor. 	

Fedora Account System Username: minlei2

Rawhide build on V2:

      https://copr.fedorainfracloud.org/coprs/minlei2/rust-rublk/build/7955281/

Comment 7 Fedora Review Service 2024-08-30 14:11:13 UTC
Created attachment 2045067 [details]
The .spec file difference from Copr build 7953278 to 7955309

Comment 8 Fedora Review Service 2024-08-30 14:11:15 UTC
Copr build:
https://copr.fedorainfracloud.org/coprs/build/7955309
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2308448-rust-rublk/fedora-rawhide-x86_64/07955309-rust-rublk/fedora-review/review.txt

Found issues:

- No gcc, gcc-c++ or clang found in BuildRequires
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/

Please know that there can be false-positives.

---
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.

Comment 9 Ming Lei 2024-08-30 14:18:27 UTC
(In reply to Fedora Review Service from comment #8)
> Copr build:
> https://copr.fedorainfracloud.org/coprs/build/7955309
> (succeeded)
> 
> Review template:
> https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-
> review-2308448-rust-rublk/fedora-rawhide-x86_64/07955309-rust-rublk/fedora-
> review/review.txt
> 
> Found issues:
> 
> - No gcc, gcc-c++ or clang found in BuildRequires
>   Read more:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/
> 
> Please know that there can be false-positives.

Yes, `BuildRequires:  clang-libs` is in .spec.

Please see Fabio's comment #1:

```
2. BuildRequires:  clang

Likely you only need clang-libs, if this is due to bindgen.
```

Comment 10 Fabio Valentini 2024-09-02 11:20:22 UTC
> # FIXME: paste output of %%cargo_license_summary here
> License:        GPL-2.0-or-later

This is still not addressed, and just adding the same License tag as for the source package itself is wrong.

The documentation for this should be here, but looks like it was recently lost:
https://docs.fedoraproject.org/en-US/legal/license-field/#bundling

Comment 11 Ming Lei 2024-09-02 11:45:51 UTC
Hi Fabio,

Thanks for the review!

(In reply to Fabio Valentini from comment #10)
> > # FIXME: paste output of %%cargo_license_summary here
> > License:        GPL-2.0-or-later
> 
> This is still not addressed, and just adding the same License tag as for the
> source package itself is wrong.

So the correct license should be "GPL-2.0-or-later or MIT or Apache-2.0 or MPL-2.0+"?

Then all dependent crates can be covered.

Otherwise, can you share details about the mistake?

> 
> The documentation for this should be here, but looks like it was recently
> lost:
> https://docs.fedoraproject.org/en-US/legal/license-field/#bundling

Thanks,

Comment 12 Fabio Valentini 2024-09-02 12:39:03 UTC
> # FIXME: paste output of %%cargo_license_summary here

Please read this line and do what it says.
Then I can tell you what the correct license tag would be ...

Comment 13 Ming Lei 2024-09-02 14:14:44 UTC
(In reply to Fabio Valentini from comment #12)
> > # FIXME: paste output of %%cargo_license_summary here
> 
> Please read this line and do what it says.
> Then I can tell you what the correct license tag would be ...

OK, the macro collects licence from all dependent crates, follows the result:

# 0BSD OR MIT OR Apache-2.0
# Apache-2.0 OR BSL-1.0
# Apache-2.0 OR MIT
# Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT
# BSD-2-Clause OR Apache-2.0 OR MIT
# BSD-3-Clause
# GPL-2.0-or-later
# MIT
# MIT OR Apache-2.0
# MIT OR Zlib OR Apache-2.0
# MPL-2.0+
# Unlicense OR MIT

So the correct answer is to combine the above all with AND?

Just wondering why 'rust2rpm -V' doesn't figure it out and fill up in .spec automaically?
At least it may provide a hint.

Thanks,

Comment 14 Ming Lei 2024-09-04 08:32:12 UTC
Hello Fabio,

Please review v3, in which the package licence issue in comment #10 is addressed.


Spec URL: https://people.redhat.com/minlei/fedpkg/rublk/rust-rublk.spec

SRPM URL: https://people.redhat.com/minlei/fedpkg/rublk/rust-rublk-0.2.1-1.fc40.src.rpm

Description: 
   rust-ublk is one binary which implements generic linux ublk userspace 
   drivers(targets). CONFIG_BLK_DEV_UBLK is enabled in Fedora for a while,
   and is enabled in RHEL10 too.
 
   upstream: https://github.com/ublk-org/rublk

   So far, it is packaged from vendor tarball via 'rust2rpm -V' because some
   dependent crates can't be pull into Fedora in short time. Follows all
   non-present crates in Fedora:
   	
   	smol		MIT or Apache-2.0
   	qcow2-rs	MIT or Apache-2.0
   	shared_memory	MIT or Apache-2.0
   	ilog		MIT
   	derive_setters  MIT or Apache-2.0
   	block-utils	MIT
   	bitmaps		MPL-2.0+

    I'd plan to pull them step-by-step and finally package rublk in non-verndor tarball. Another motivation is that libublk-rs needs to be package too, which
is one library and can't be done in vendor mode.

    Need sponsor. 	

Fedora Account System Username: minlei2

Comment 15 Ming Lei 2024-09-07 10:02:35 UTC
Hello Fabio,


Friendly ping...

Thanks

Comment 16 Fabio Valentini 2024-09-09 20:23:35 UTC
I'm getting errors when trying to download the files with "fedora-review" ...

ERROR: 'Error <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1000)> downloading https://people.redhat.com/minlei/fedpkg/rublk/rust-rublk-0.2.1-1.fc40.src.rpm'

Is people.redhat.com having issues with its HTTPS certificate?

========================================

You have (BSD-2-Clause OR Apache-2.0 OR MIT) in your License tag.
When doing a local build, I don't get any dependency in the package's dependency tree with that license string.

You will need to check *for every new version* that the summary and license tag are still accurate.
The output of the %cargo_license_summary macro during the build of the current version is

# 0BSD OR MIT OR Apache-2.0
# Apache-2.0 OR BSL-1.0
# Apache-2.0 OR MIT
# Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT
# BSD-3-Clause
# GPL-2.0-or-later
# MIT
# MIT OR Apache-2.0
# MIT OR Zlib OR Apache-2.0
# MPL-2.0+
# Unlicense OR MIT

(which is what you should also paste into the spec file above the subpackage's License tag, as instructed by the spec generated by rust2rpm)

========================================

Your package also statically links the regex-syntax crate, which has (for our standards in Fedora / Red Hat) incomplete license information. It bundles code that's  derived from Unicode data, resulting in code covered by the Unicode-DFS-2016 license. For the Fedora package, we're fixing this here:

https://src.fedoraproject.org/rpms/rust-regex-syntax/blob/rawhide/f/regex-syntax-fix-metadata.diff

So when building with vendored crates, you will need to add "Unicode-DFS-2016" to the license tag manually.

Comment 17 Ming Lei 2024-09-13 15:34:15 UTC
Hi Fabio,

Thanks for the review!

(In reply to Fabio Valentini from comment #16)
> I'm getting errors when trying to download the files with "fedora-review" ...
> 
> ERROR: 'Error <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate
> verify failed: unable to get local issuer certificate (_ssl.c:1000)>
> downloading
> https://people.redhat.com/minlei/fedpkg/rublk/rust-rublk-0.2.1-1.fc40.src.
> rpm'
> 
> Is people.redhat.com having issues with its HTTPS certificate?

I don't know, maybe it is one transient issue, can you check it again?

I just try to download the src.rpm from one fresh VM and my android mobile phone,
not see such issue.

> 
> ========================================
> 
> You have (BSD-2-Clause OR Apache-2.0 OR MIT) in your License tag.
> When doing a local build, I don't get any dependency in the package's
> dependency tree with that license string.
> 
> You will need to check *for every new version* that the summary and license
> tag are still accurate.
> The output of the %cargo_license_summary macro during the build of the
> current version is
> 
> # 0BSD OR MIT OR Apache-2.0
> # Apache-2.0 OR BSL-1.0
> # Apache-2.0 OR MIT
> # Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT
> # BSD-3-Clause
> # GPL-2.0-or-later
> # MIT
> # MIT OR Apache-2.0
> # MIT OR Zlib OR Apache-2.0
> # MPL-2.0+
> # Unlicense OR MIT
> 
> (which is what you should also paste into the spec file above the
> subpackage's License tag, as instructed by the spec generated by rust2rpm)
> 
> ========================================
> 
> Your package also statically links the regex-syntax crate, which has (for
> our standards in Fedora / Red Hat) incomplete license information. It
> bundles code that's  derived from Unicode data, resulting in code covered by
> the Unicode-DFS-2016 license. For the Fedora package, we're fixing this here:
> 
> https://src.fedoraproject.org/rpms/rust-regex-syntax/blob/rawhide/f/regex-
> syntax-fix-metadata.diff
> 
> So when building with vendored crates, you will need to add
> "Unicode-DFS-2016" to the license tag manually.

OK, will fix the license tag.

Comment 18 Ming Lei 2024-09-13 15:35:25 UTC
Hello Fabio,

Please review v4, in which the package license issue in comment #16 is addressed.


Spec URL: https://people.redhat.com/minlei/fedpkg/rublk/rust-rublk.spec

SRPM URL: https://people.redhat.com/minlei/fedpkg/rublk/rust-rublk-0.2.1-1.fc40.src.rpm

Description: 
   rust-ublk is one binary which implements generic linux ublk userspace 
   drivers(targets). CONFIG_BLK_DEV_UBLK is enabled in Fedora for a while,
   and is enabled in RHEL10 too.
 
   upstream: https://github.com/ublk-org/rublk

   So far, it is packaged from vendor tarball via 'rust2rpm -V' because some
   dependent crates can't be pull into Fedora in short time. Follows all
   non-present crates in Fedora:
   	
   	smol		MIT or Apache-2.0
   	qcow2-rs	MIT or Apache-2.0
   	shared_memory	MIT or Apache-2.0
   	ilog		MIT
   	derive_setters  MIT or Apache-2.0
   	block-utils	MIT
   	bitmaps		MPL-2.0+

    I'd plan to pull them step-by-step and finally package rublk in non-verndor tarball. Another motivation is that libublk-rs needs to be package too, which
is one library and can't be done in vendor mode.

    Need sponsor. 	

Fedora Account System Username: minlei2

Comment 19 Fabio Valentini 2024-09-14 11:33:35 UTC
There is no need to NEEDINFO me.
If you *really* need sub-24-hour response times, then Red Hat should consider paying me.

I'll make another review pass shortly.

Comment 20 Fabio Valentini 2024-09-14 11:57:45 UTC
Package looks mostly good now. Two minor issues:

1. Please document why clang-libs dependency is necessary, for example like this:

```
# dependency for bundled vendored crate
BuildRequires:  clang-libs
```

When switching away from building with vendored dependencies, that will make it obvious that this can be removed at that point.

2. The license summary is still not documented in the spec file, only the resulting License tag.

While I think this is no longer strictly required, documenting it this way makes it *much* easier to update the License tag when packaging new versions (or, in this case, when updating the vendor tarball).

I would suggest to do something like this:

```
# rublk and crate dependencies:
# =============================
# 0BSD OR MIT OR Apache-2.0
# Apache-2.0 OR BSL-1.0
# Apache-2.0 OR MIT
# Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT
# BSD-3-Clause
# GPL-2.0-or-later
# MIT
# MIT OR Apache-2.0
# MIT OR Zlib OR Apache-2.0
# MPL-2.0+
# Unlicense OR MIT
# code derived from Unicode data:
# Unicode-DFS-2016 (in regex-syntax)
License:        (0BSD OR MIT OR Apache-2.0) AND (Apache-2.0 OR BSL-1.0) AND (Apache-2.0 OR MIT) AND (Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT) AND BSD-3-Clause AND GPL-2.0-or-later AND MIT AND (MIT OR Apache-2.0) AND (MIT OR Zlib OR Apache-2.0) AND MPL-2.0+ AND (Unlicense OR MIT) AND Unicode-DFS-2016
# LICENSE.dependencies contains a full license breakdown
```

Additionally, there's some duplication in the License tag. For example, "(Apache-2.0 OR MIT)" and "(MIT OR Apache-2.0)" are equivalent, you can drop one of them.

===

When do you plan to start submitting missing review requests for the missing dependencies?

Comment 21 Fabio Valentini 2024-09-14 12:00:21 UTC
Sorry, there was a copy-paste issue, I meant this:

```
# dependency for vendored bindgen crate
BuildRequires:  clang-libs
```

Comment 22 Ming Lei 2024-09-14 12:14:28 UTC
(In reply to Fabio Valentini from comment #19)
> There is no need to NEEDINFO me.
> If you *really* need sub-24-hour response times, then Red Hat should
> consider paying me.

Oops, NEEDINFO is just one practice in RH for Cc/notifying people, instead of
any required response time. 

Will not do in the following review, sorry.

Comment 23 Ming Lei 2024-09-14 12:17:55 UTC
(In reply to Fabio Valentini from comment #20)
> Package looks mostly good now. Two minor issues:

Thanks for the review!

> 
> 1. Please document why clang-libs dependency is necessary, for example like
> this:
> 
> ```
> # dependency for bundled vendored crate
> BuildRequires:  clang-libs
> ```
> 
> When switching away from building with vendored dependencies, that will make
> it obvious that this can be removed at that point.
> 
> 2. The license summary is still not documented in the spec file, only the
> resulting License tag.
> 
> While I think this is no longer strictly required, documenting it this way
> makes it *much* easier to update the License tag when packaging new versions
> (or, in this case, when updating the vendor tarball).
> 
> I would suggest to do something like this:
> 
> ```
> # rublk and crate dependencies:
> # =============================
> # 0BSD OR MIT OR Apache-2.0
> # Apache-2.0 OR BSL-1.0
> # Apache-2.0 OR MIT
> # Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT
> # BSD-3-Clause
> # GPL-2.0-or-later
> # MIT
> # MIT OR Apache-2.0
> # MIT OR Zlib OR Apache-2.0
> # MPL-2.0+
> # Unlicense OR MIT
> # code derived from Unicode data:
> # Unicode-DFS-2016 (in regex-syntax)
> License:        (0BSD OR MIT OR Apache-2.0) AND (Apache-2.0 OR BSL-1.0) AND
> (Apache-2.0 OR MIT) AND (Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR
> MIT) AND BSD-3-Clause AND GPL-2.0-or-later AND MIT AND (MIT OR Apache-2.0)
> AND (MIT OR Zlib OR Apache-2.0) AND MPL-2.0+ AND (Unlicense OR MIT) AND
> Unicode-DFS-2016
> # LICENSE.dependencies contains a full license breakdown
> ```
> 
> Additionally, there's some duplication in the License tag. For example,
> "(Apache-2.0 OR MIT)" and "(MIT OR Apache-2.0)" are equivalent, you can drop
> one of them.

OK, will fix the above two in V5.

> 
> ===
> 
> When do you plan to start submitting missing review requests for the missing
> dependencies?

It has been started actually, futures-locks is one dependency, once it
is merged, qcow2-rs can be ready to go.

Then I can work on other dependencies, and the biggest blocker should be smol.

thanks,

Comment 24 Fabio Valentini 2024-09-16 13:22:14 UTC
Thank you for the update, package looks good to me now.

There's just two minor issues pointed out by rpmlint that need to be clarified:

> rublk.x86_64: W: unused-direct-shlib-dependency /usr/bin/rublk /lib64/libm.so.6

Not sure where this comes from?

> rublk.x86_64: E: missing-call-to-setgroups-before-setuid /usr/bin/rublk

This one looks slightly concerning - is rublk supposed to be a SUID binary?

Those have been getting phased out since Fedora 15 (!):
https://fedoraproject.org/wiki/Features/RemoveSETUID

*If* the rublk executable is supposed to be a SUID binary, then it needs to be marked as such in packaging with the correct attribute, otherwise the SUID bit will not be set on the file.

And independently, it looks like the setuid code isn't handled correctly upstream, according to the rpmlint error.

Comment 25 Ming Lei 2024-09-17 15:45:31 UTC
(In reply to Fabio Valentini from comment #24)
> Thank you for the update, package looks good to me now.

Thanks for the review!

> 
> There's just two minor issues pointed out by rpmlint that need to be
> clarified:
> 
> > rublk.x86_64: W: unused-direct-shlib-dependency /usr/bin/rublk /lib64/libm.so.6
> 
> Not sure where this comes from?

It should be from `libc` crate, which is used by rublk.

Google shows this warning is very common.

> 
> > rublk.x86_64: E: missing-call-to-setgroups-before-setuid /usr/bin/rublk
> 
> This one looks slightly concerning - is rublk supposed to be a SUID binary?
> 
> Those have been getting phased out since Fedora 15 (!):
> https://fedoraproject.org/wiki/Features/RemoveSETUID
> 
> *If* the rublk executable is supposed to be a SUID binary, then it needs to
> be marked as such in packaging with the correct attribute, otherwise the
> SUID bit will not be set on the file.
> 
> And independently, it looks like the setuid code isn't handled correctly
> upstream, according to the rpmlint error.

I think this one is a false positive since rublk does not call setuid/setgid.

'objdump -D's shows both setuid/setgid are called from daemonize crate symbols only, which
is one Fedora package, and rublk binary needn't to change uid/gid.

Any application built against rust-daemonize-devel should trigger such
rpmlint warning if it is built as rpm, since I can see similar setuid/setgid
pattern in the built daemonize hello-world binary.


Thanks,

Comment 26 Fabio Valentini 2024-09-18 13:02:02 UTC
It looks like you're correct that this is a false positive.

The code in the daemonize crate explicitly has a setgroup call *before* a setuid call:
https://github.com/knsd/daemonize/blob/master/daemonize/src/lib.rs#L417-L423

And in any case, rublk sets neither uid nor gid:
https://github.com/ublk-org/rublk/blob/main/src/main.rs

So this looks good to me.

PS: I've started submitting some of the missing dependencies for review, starting with smol.
    So I hope that using vendored dependencies will be a temporary solution here.

===

Package was generated with rust2rpm, simplifying the review.

✅❌❓🫤

✅ package contains only permissible content
✅ package builds and installs without errors on rawhide
✅ test suite is run and all unit tests pass
✅ latest version of the crate is packaged
✅ license matches upstream specification and is acceptable for Fedora
✅ vendored dependencies are handled correctly
✅ licenses of statically linked dependencies are correctly taken into account
✅ license file is included with %license in %files
✅ package complies with Rust Packaging Guidelines

Package APPROVED.

===

Recommended post-import rust-sig tasks:

- set up package on release-monitoring.org:
  project: $crate
  homepage: https://crates.io/crates/$crate
  backend: crates.io
  version scheme: semantic
  version filter: alpha;beta;rc;pre
  distro: Fedora
  Package: rust-$crate

- add @rust-sig with "commit" access as package co-maintainer
  (should happen automatically)

- set bugzilla assignee overrides to @rust-sig (optional)

- track package in koschei for all built branches
  (should happen automatically once rust-sig is co-maintainer)

Comment 27 Fedora Admin user for bugzilla script actions 2024-09-22 13:00:25 UTC
The Pagure repository was created at https://src.fedoraproject.org/rpms/rust-rublk

Comment 28 Fedora Update System 2024-09-23 04:11:25 UTC
FEDORA-2024-0b41fb3760 (rust-rublk-0.2.3-1.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-0b41fb3760

Comment 29 Fedora Update System 2024-09-23 04:14:40 UTC
FEDORA-2024-0b41fb3760 (rust-rublk-0.2.3-1.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 30 Fabio Valentini 2024-09-23 12:27:31 UTC
FYI, please do *not* commit source files (*.crate / *.tar.xz) into the git repository:
https://src.fedoraproject.org/rpms/rust-rublk/tree/rawhide

This is redundant with the lookaside cache (a git-lfs-like system) *and* makes using this repository very hard due to the large file sizes that are tracked by git.

Please ask your sponsor if you're unsure with how to deal with certain tasks instead of moving ahead and making mistakes like that.

Comment 31 Richard W.M. Jones 2024-09-23 12:43:31 UTC
I have fixed this, and also talked to Ming Lei about how to do it correctly in future.


Note You need to log in before you can comment on or make changes to this bug.