I have a quick question: is there a reason that we don't add `BuildArch: noarch` to source only go packages? To be clear, the `-devel` subpackages themselves have `BuildArch: noarch`, but the main packages don't. Unless I'm missing something, Koji still seems to create separate build jobs for each architecture.
Maxwell G (@gotmax23)
PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8
PGP Keyserver: hkp://keyserver.ubuntu.com
mikelo2 reported a new issue against the project: `golist` that you are following:
golist fails when golang-1.17 new `//go:build` style is used:
$ go2rpm https://github.com/google/log4jscanner
//go:build comment without // +build comment
Traceback (most recent call last):
File "/usr/bin/go2rpm", line 8, in <module>
File "/usr/lib/python3.10/site-packages/go2rpm/__main__.py", line 598, in main
buildrequires = to_list(get_buildrequires(forge, subdir))
File "/usr/lib/python3.10/site-packages/go2rpm/__main__.py", line 442, in get_buildrequires
buildrequires = subprocess.check_output(
File "/usr/lib64/python3.10/subprocess.py", line 420, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib64/python3.10/subprocess.py", line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['golist', '--imported', '--skip-self', '--package-path', 'github.com/google/log4jscanner']' returned non-zero exit status 1.
From go-1.17 release notes:
The go command now understands //go:build lines and prefers them over // +build lines. The new syntax uses boolean expressions, just like Go, and should be less error-prone. As of this release, the new syntax is fully supported, and all Go files should be updated to have both forms with the same meaning. To aid in migration, gofmt now automatically synchronizes the two forms. For more details on the syntax and migration plan, see https://golang.org/design/draft-gobuild.
To reply, visit the link below or just reply to this email
Koschei reported failure on some of my packages and also received some
Checking root.log and F36FailsToInstall reports I can see the
following output for one package, but the rest are similar with less
No matching package to install: 'golang(crypto/rand)'
No matching package to install: 'golang(encoding/json)'
No matching package to install: 'golang(mime)'
No matching package to install: 'golang(net)'
No matching package to install: 'golang(net/http)'
No matching package to install: 'golang(os)'
No matching package to install: 'golang(reflect)'
No matching package to install: 'golang(testing)'
No matching package to install: 'golang(time)'
Checking go-sig packages I can see some F36FailsToInstall have been
reported also. But checking Koschei I can see a lot of builds were
successful today with just a few failures.
I see 1.18beta1 was pushed two days ago, maybe it is related?
Is anyone else experiencing this problem?
Is there any way to fix or workaround it?
tomranta opened a new pull-request against the project: `go-rpm-macros` that you are following:
srpm/go.lua: fix handling of version numbers with multiple digits
To reply, visit the link below or just reply to this email
I've been thinking a little about how Go is updated in Fedora. I would like
to hear other opinions about the current state of the releases and improve
This is not related to the Fedora proposal that I'm planning to submit
today regarding the update of Go. I do not pretend to change anything for
the next Fedora release, but at least have an idea of if what we are doing
right now can be improved.
The current state:
Each Fedora release has a major release of Go available.
For example, Fedora 33 had 1.15, and Fedora 34 had 1.16.
I see two main issues with this approach.
1. Both Go and Fedora have release cycles of 6 months, so the schedule
is a little tight. Go releases can be delayed and have issues in the mass
2. A user needs to wait for the next Fedora release to get a new major
version of Go. So consequentially, they will tend to download from
upstream, making the Go package just necessary for dependencies but with
little use on its own. Also, backport bugs to Fedora releases might be a
problem. Releasing packages that depend on new features are an issue too
What I think is an improvement:
Suppose a new Go major version is released in the middle of a Fedora life
cycle. In that case, I think it is an improvement for the user to be able
to update to the following Go release.
A hypothetical new release cycle would look like this:
- Fedora N release follows Go upstream as close as we can.
- Fedora N-1 sticks with the latest major version of Go that was
available on it until the release of Fedora N.
Another hypothetical approach could be using modules with each upstream
supported release in a stream.
To help in the decision, I made a report tool/web page  that shows the
current state of the packages that depend on Go (Thanks to the COPR API).
It compares the builds of every single Go dependent package in Fedora 35
using the current available Go package with the same list of Go packages
but using the Go package is available on Fedora Rawhide. To rephrase it, it
compares Fedora 35 packages built with Go 1.16 with Fedora 35 packages
built with Go 1.17.
As you can see, right now, from the 1901 packages that depend on Go, 196
have some sort of change and 1705 built exactly the same. You can search
for "Same results" or "Something has changed" to see this. Or by the name
of the package.
The report is not smart enough to say what happened right now so some
"issues" are in fact improvements like golang-github-cactus-statsd-client,
others like golang-github-briandowns-spinner are real issues.
My idea is to improve this report with your suggestions. Hence, if a new Go
major release is available, we can confidently say that the package can be
updated in the middle of a Fedora release.
 https://alexsaezm.fedorapeople.org/report.html -> let it load, it has a
JS that allows you to search
I've been talking with the awesome people at Sourcegraph, and they're
interested in indexing our packages. Still working out what that'l look like
exactly, but I'm pretty excited about it. (They're an open-source company
with a SaaS product. Also at least some of their folks run Fedora Linux, so
that's extra cool.)
In our conversation, they mentioned that it'd be nice to have their
command-line tool packaged. Anyone interested in taking that on? Looks
pretty straightforward, although I'm not sure of any Go lang pitfalls that
(Also, we already have a package named `src`, which is a apparently and RCS
(!!!!?!?!?!) wrapper. So we'll need to figure out a different comand name;
maybe src-cli, maybe 'sourcegraph', dunno.)
They'd also be interested in having the actual search engine tool itself
packaged (https://github.com/sourcegraph/sourcegraph) -- but that's a bigger
project. (Still, volunteers welcome!)
Fedora Project Leader