Fedora Account System
Red Hat Associate
Red Hat Customer
I am trying to apply spectool to a specfile generated successfully by go2rpm. Most of the time it works, when the forge to be used is GitHub. But, when using any other, it fails. Version-Release number of selected component (if applicable): $ rpm -q rpmdevtools rpmdevtools-9.6-7.fc40.noarch $ spectool --version spectool 1.1.0 How reproducible: cat << 'EOF' > golang-x-net.spec # Generated by go2rpm 1.14.0 %bcond check 1 %bcond bootstrap 0 %if %{with bootstrap} %global debug_package %{nil} %endif %if %{with bootstrap} %global __requires_exclude %{?__requires_exclude:%{__requires_exclude}|}^golang\\(.*\\)$ %endif # https://go.googlesource.com/net %global goipath golang.org/x/net %global forgeurl https://go.googlesource.com/net Version: v0.19.0 %global tag v0.19.0 # REMOVE BEFORE SUBMITTING THIS FOR REVIEW # --- # New Fedora packages should use %%gometa -f, which makes the package # ExclusiveArch to %%golang_arches_future and thus excludes the package from # %%ix86. If the new package is needed as a dependency for another package, # please consider removing that package from %%ix86 in the same way, instead of # building more go packages for i686. If your package is not a leaf package, # you'll need to coordinate the removal of the package's dependents first. # --- # REMOVE BEFORE SUBMITTING THIS FOR REVIEW %gometa -L -f %global common_description %{expand: # FIXME} %global golicenses LICENSE PATENTS %global godocs CONTRIBUTING.md README.md http2/h2i/README.md Name: golang-x-net Release: %autorelease Summary: None License: BSD-3-Clause URL: %{gourl} Source: %{gosource} %description %{common_description} %gopkg %prep %goprep -A %autopatch -p1 %if %{without bootstrap} %generate_buildrequires %go_generate_buildrequires %endif %if %{without bootstrap} %build for cmd in html/atom http2/h2i http2/hpack ipv4 ipv6 publicsuffix webdav; do %gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd done %endif %install %gopkginstall %if %{without bootstrap} install -m 0755 -vd %{buildroot}%{_bindir} install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/ %endif %if %{without bootstrap} %if %{with check} %check %gocheck %endif %endif %if %{without bootstrap} %files %license LICENSE PATENTS %doc CONTRIBUTING.md README.md http2/h2i/README.md # REMOVE BEFORE SUBMITTING THIS FOR REVIEW # --- # New Fedora packages should not use globs to avoid installing conflicting # binaries. # Write a _bindir line per each of the binaries the package will install. # --- # REMOVE BEFORE SUBMITTING THIS FOR REVIEW %{_bindir}/* %endif %gopkgfiles %changelog %autochangelog EOF spectool -Rag golang-x-net.spec Another way of generating the spec I generated would be: go2rpm -t v0.19.0 -f go.googlesource.com/net golang.org/x/net Reproducible: Always Steps to Reproduce: 1. Generate the SPEC file using go2rpm 2. Try spectool on it. Actual Results: $ go2rpm -t v0.19.0 -f go.googlesource.com/net golang.org/x/net $ spectool -Rag golang-x-net.spec $ ll ~/rpmbuild/SOURCES/ total 0 $ head -n 17 golang-x-net.spec # Generated by go2rpm 1.14.0 %bcond check 1 %bcond bootstrap 0 %if %{with bootstrap} %global debug_package %{nil} %endif %if %{with bootstrap} %global __requires_exclude %{?__requires_exclude:%{__requires_exclude}|}^golang\\(.*\\)$ %endif # https://go.googlesource.com/net %global goipath golang.org/x/net %global forgeurl https://go.googlesource.com/net Version: v0.19.0 %global tag v0.19.0 Expected Results: It should download the source code tarball.
Thanks for the report! This is an issue with the forge macros, not the Go macros. The go.googlesource forge is not supported, so it does not come up with a valid %{forgesource}. Implementing this would require adding a new forge entry to forge.lua and writing the appropriate test cases. This is frankly not a super high priority, as all the Google Go stuff is mirrored to Github, and the Go packages in Fedora already consume those repositories. See the existing golang-x-net specfile in Fedora for an example: https://src.fedoraproject.org/rpms/golang-x-net/blob/rawhide/f/golang-x-net.spec. Is there a reason why you are writing a new one when Fedora already maintains this package?
Renich, if you are familiar with the URL structure to download source archives from go.googlesource, some insight on that here would likely get this implemented more quickly.
(In reply to Maxwell G from comment #1) > Thanks for the report! This is an issue with the forge macros, not the Go > macros. The go.googlesource forge is not supported, so it does not come up > with a valid %{forgesource}. Implementing this would require adding a new > forge entry to forge.lua and writing the appropriate test cases. This is > frankly not a super high priority, as all the Google Go stuff is mirrored to > Github, and the Go packages in Fedora already consume those repositories. > See the existing golang-x-net specfile in Fedora for an example: > https://src.fedoraproject.org/rpms/golang-x-net/blob/rawhide/f/golang-x-net. > spec. Is there a reason why you are writing a new one when Fedora already > maintains this package? Hello, Maxwell G. Thank you for the explanation. Well, there are a few reasons: * The URL is for the actual primary source of the packages. I think it's more reliable than GitHub. * My boss needs xq ported to CentOS Stream 9 and AlmaLinux. I've created a script to help me backport the packages using the actual requires from go. For example: github.com/sibprogrammer/xq v1.2.4 github.com/spf13/pflag v1.0.5 github.com/PuerkitoBio/goquery v1.8.1 github.com/antchfx/xmlquery v1.3.18 github.com/spf13/viper v1.18.2 github.com/fatih/color v1.16.0 github.com/antchfx/xpath v1.2.4 golang.org/x/text v0.14.0 golang.org/x/net v0.19.0 github.com/spf13/cobra v1.8.0 github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da github.com/spf13/cast v1.6.0 github.com/fsnotify/fsnotify v1.7.0 github.com/sagikazarmark/slog-shim v0.1.0 github.com/mitchellh/mapstructure v1.5.0 github.com/spf13/afero v1.11.0 github.com/subosito/gotenv v1.6.0 github.com/hashicorp/hcl v1.0.0 gopkg.in/ini.v1 v1.67.0 github.com/magiconair/properties v1.8.7 github.com/pelletier/go-toml/v2 v2.1.0 gopkg.in/yaml.v3 v3.0.1 github.com/andybalholm/cascadia v1.3.2 github.com/mattn/go-colorable v0.1.13 github.com/mattn/go-isatty v0.0.20 golang.org/x/sys v0.15.0 My script parses that output and gets the source from the goipath. If you, for instance, visit: https://golang.org/x/text/ it will redirect you here: https://pkg.go.dev/golang.org/x/text and the official source listed there is: https://cs.opensource.google/go/x/text. Sadly, nobody knows how to clone from there. Yet, there is a pointer to: https://go.dev/doc/contribute in every one of those go repositories in that website. IN that document, they always suggest cloning from: https://go.googlesource.com/ Sorry for the long explanation but I wanted you to know how I got to where I am. This is why I want to get it from there. (In reply to Maxwell G from comment #2) > Renich, if you are familiar with the URL structure to download source > archives from go.googlesource, some insight on that here would likely get > this implemented more quickly. Well, for my text example, one can get the tgz from: https://go.googlesource.com/text/+archive/refs/tags/v0.17.0.tar.gz. One can get to a tarball through the GUI by clicking: <tag> > tgz; for example. The software used for these is gitiles: https://gerrit.googlesource.com/gitiles/ and the docs are here: https://gerrit.googlesource.com/gitiles/+/HEAD/Documentation/ Let me know if that helped. ;)
The de facto source of Go code is Github. That's where the contributions from outside Google are primarily accepted and reviewed. Anyways, it seems the macros already support code.googlesource.com which is the same codebase as go.googlesource.com, so it's not too difficult to add support for it.
https://git.sr.ht/~gotmax23/forge-srpm-macros/commit/6be567e9c697063b40b81ab23315a16d5f6d9fb5
(In reply to Maxwell G from comment #5) > https://git.sr.ht/~gotmax23/forge-srpm-macros/commit/ > 6be567e9c697063b40b81ab23315a16d5f6d9fb5 OK, nice. Thank you. When can I test it? Or, should I apply the patch or something? Was looking for it in bodhi but couldn't find the update yet.
You can try the latest version from https://copr.fedorainfracloud.org/coprs/gotmax23/forge-srpm-macros-dev/ until this is released to stable.
FEDORA-2024-e0a60c41e6 (forge-srpm-macros-0.4.0-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2024-e0a60c41e6
FEDORA-2024-e0a60c41e6 (forge-srpm-macros-0.4.0-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.