Spec URL: https://raw.githubusercontent.com/thebeanogamer/golang-github-bazelbuild-bazelisk/main/bazelisk.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/thebeanogamer/golang-github-bazelbuild-bazelisk/fedora-rawhide-x86_64/06390779-bazelisk/bazelisk-1.18.0-1.fc40.src.rpm Description: A user-friendly launcher for Bazel Fedora Account System Username: thebeanogamer COPR Build: https://copr.fedorainfracloud.org/coprs/thebeanogamer/golang-github-bazelbuild-bazelisk/build/6390779/ Depends On: https://pagure.io/releng/issue/11668 This package is mostly generated by go2rpm, although I have had to add a small conditional to work around an upstream limitation. I wasn't entirely sure about the package name, given that this is a command-line tool. Happy to revert to %{goname} if that's preferred.
I'll review this once the situation with the dependency is resolved.
Dependency is back in Fedora (https://packages.fedoraproject.org/pkgs/golang-github-bgentry-netrc/golang-github-bgentry-netrc-devel/), this should be ready to review. I've rebuilt the COPR and all seems fine https://copr.fedorainfracloud.org/coprs/thebeanogamer/golang-github-bazelbuild-bazelisk/build/6478204/. Thanks. -- For the benefit of fedora-review: Spec URL: https://raw.githubusercontent.com/thebeanogamer/golang-github-bazelbuild-bazelisk/main/bazelisk.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/thebeanogamer/golang-github-bazelbuild-bazelisk/fedora-39-x86_64/06478204-bazelisk/bazelisk-1.18.0-1.fc39.src.rpm
I'm busy this week, but I'll try to take a look as soon as I can. Please avoid needinfo'ing me.
How is this useful if bazel is not itself a fedora package ? There is a newer version. Use a better %description Bazelisk is a wrapper for Bazel written in Go. It automatically picks a good version of Bazel given your current working directory, downloads it from the official server (if required) and then transparently passes through all command-line arguments to the real Bazel binary. You can call it just like you would call Bazel. There are several other issues raised by fedora-review.
Hey Tom, thanks for looking at this. > How is this useful if bazel is not itself a fedora package ? Bazelisk is effectively a package manager. It will download Bazel from the official sources and install it. Whilst I'd love to package Bazel itself for Fedora, that is a substantially more complex and brittle package to maintain. I'd personally argue this is equivalent to us packaging `npm`, as a way to download something that's not available as an RPM. > There is a newer version. Apologies, the new release didn't exist when I originally made this review. I've updated the package: Spec URL: https://raw.githubusercontent.com/thebeanogamer/golang-github-bazelbuild-bazelisk/main/golang-github-bazelbuild-bazelisk.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/thebeanogamer/golang-github-bazelbuild-bazelisk/fedora-rawhide-x86_64/06834891-golang-github-bazelbuild-bazelisk/golang-github-bazelbuild-bazelisk-1.19.0-1.fc40.src.rpm [fedora-review-service-build] > Use a better %description Updated, see spec above. > There are several other issues raised by fedora-review. Sorry, but I can't see these. The only failure I get is "Reviewer should test that the package builds in mock.", which has been broken for a long time. Could you link me a fedora-review output with the failures you're seeing so I can fix them please? Having re-read the Golang packaging guide since I submitted this request, I've change the RPM name to golang-github-bazelbuild-bazelisk. Please let me know if this was in error.
Copr build: https://copr.fedorainfracloud.org/coprs/build/6835097 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2238191-golang-github-bazelbuild-bazelisk/fedora-rawhide-x86_64/06835097-golang-github-bazelbuild-bazelisk/fedora-review/review.txt Please take a look if any issues were found. --- 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.
> Sorry, but I can't see these. The only failure I get is "Reviewer should test that the package builds in mock.", which has been broken for a long time. Could you link me a fedora-review output with the failures you're seeing so I can fix them please? Nevermind, I was being silly and missed the rpmlint errors. Here's fixed versions: Spec URL: https://raw.githubusercontent.com/thebeanogamer/golang-github-bazelbuild-bazelisk/main/golang-github-bazelbuild-bazelisk.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/thebeanogamer/golang-github-bazelbuild-bazelisk/fedora-rawhide-x86_64/06835136-golang-github-bazelbuild-bazelisk/golang-github-bazelbuild-bazelisk-1.19.0-1.fc40.src.rpm [fedora-review-service-build] There are a few I can't fix: > golang-github-bazelbuild-bazelisk.x86_64: W: no-manual-page-for-binary bazelisk Upstream doesn't provide a manpage, and we can't run `help2man bazelisk` without an internet connection. Best I can do is `%doc README.md`. > golang-github-bazelbuild-bazelisk-devel.noarch: W: hidden-file-or-dir /usr/share/gocode/src/github.com/bazelbuild/bazelisk/.goipath > golang-github-bazelbuild-bazelisk-debugsource.x86_64: E: description-line-too-long This package provides debug sources for package golang-github-bazelbuild-bazelisk. Every Go project seems to have these, though if you can point me at a fix I'd be happy to apply it.
(In reply to Daniel Milnes from comment #5) > Hey Tom, thanks for looking at this. > > > How is this useful if bazel is not itself a fedora package ? > > Bazelisk is effectively a package manager. It will download Bazel from the > official sources and install it. Whilst I'd love to package Bazel itself for > Fedora, that is a substantially more complex and brittle package to > maintain. I'd personally argue this is equivalent to us packaging `npm`, as > a way to download something that's not available as an RPM. How does this help with packaging projects in fedora that use bazel ?
(In reply to Tom Rix from comment #8) > (In reply to Daniel Milnes from comment #5) > > Hey Tom, thanks for looking at this. > > > > > How is this useful if bazel is not itself a fedora package ? > > > > Bazelisk is effectively a package manager. It will download Bazel from the > > official sources and install it. Whilst I'd love to package Bazel itself for > > Fedora, that is a substantially more complex and brittle package to > > maintain. I'd personally argue this is equivalent to us packaging `npm`, as > > a way to download something that's not available as an RPM. > > How does this help with packaging projects in fedora that use bazel ? It doesn't, Bazelisk is an end-user tool. It's designed to allow people who have created repos that use Bazel to easily manage multiple versions of it. Without Bazelisk, the only real way to install Bazel is `curl -O /usr/local/bin/bazel https...`. This is why I think it's comparable to `npm`. We can't use it as part of an RPM spec, but it's very helpful to end-users who are working with Bazel. I don't think there's too much we can do to ease packaging projects which use Bazel for RPM. Bazel is designed to be hermetically-sealed and downloads its project dependencies to vendored directories, which is the opposite of Fedora's "Everything should come through the package manager" approach. I'm happy to have a discussion about that, but I think it's better suited to Matrix (thebeanogamer:fedora.im).
Created attachment 2006689 [details] The .spec file difference from Copr build 6835097 to 6840026
Copr build: https://copr.fedorainfracloud.org/coprs/build/6840026 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2238191-golang-github-bazelbuild-bazelisk/fedora-rawhide-x86_64/06840026-golang-github-bazelbuild-bazelisk/fedora-review/review.txt Please take a look if any issues were found. --- 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.
why was the specfile name changed ? why is there a devel package when no libraries are distributed ? There is this lingering rpmlint warning golang-github-bazelbuild-bazelisk.x86_64: W: unused-direct-shlib-dependency /usr/bin/bazelisk /lib64/libresolv.so.2
(In reply to Tom Rix from comment #12) > why was the specfile name changed ? Having re-read the Golang Packaging Guidelines, I think I was wrong with my original name for this package. I've renamed it to the version generated by the %{goname} macro. > why is there a devel package when no libraries are distributed ? As far as I can tell, this is the case for all Golang packages (for example: https://koji.fedoraproject.org/koji/buildinfo?buildID=2085464). I can't see any way to remove the -devel package outside of rewriting the spec file to not use any of the %go macros. All the examples around go2rpm and go-rpm-macros I can see have this behaviour. > golang-github-bazelbuild-bazelisk.x86_64: W: unused-direct-shlib-dependency /usr/bin/bazelisk /lib64/libresolv.so.2 This also appears to happen for all Golang packages. Interestingly, rpmlint doesn't flag this for me, but manually running `ldd -u` does. I'm not entirely sure why that happens and will research further.
(In reply to Daniel Milnes from comment #13) > (In reply to Tom Rix from comment #12) > > why was the specfile name changed ? > Having re-read the Golang Packaging Guidelines, I think I was wrong with my > original name for this package. I've renamed it to the version generated by > the %{goname} macro. Just to add to this, the packaging guide says the following: > Source packages that provide a well-known application such as etcd MUST be named after the application. End users do not care about the language their applications are written in. But do not name packages after an obscure utility binary that happens to be built by the package. I don't think this qualifies as "well-known", as even Prometheus doesn't have its package named like this. I'm happy to change it back through if you feel it does meet this definition.
(In reply to Daniel Milnes from comment #14) > (In reply to Daniel Milnes from comment #13) > > (In reply to Tom Rix from comment #12) > > > why was the specfile name changed ? > > Having re-read the Golang Packaging Guidelines, I think I was wrong with my > > original name for this package. I've renamed it to the version generated by > > the %{goname} macro. > > Just to add to this, the packaging guide says the following: > > > Source packages that provide a well-known application such as etcd MUST be named after the application. End users do not care about the language their applications are written in. But do not name packages after an obscure utility binary that happens to be built by the package. > > I don't think this qualifies as "well-known", as even Prometheus doesn't > have its package named like this. I'm happy to change it back through if you > feel it does meet this definition. As someone that has tried to find the tools to build TensorFlow, I think the earlier name is better. I will leave this up to you.
The reviewer's account was closed.