[go-rpm-macros] Issue #2: EPEL availability
by Nicolas Mailhot
nim reported a new issue against the project: `go-rpm-macros` that you are following:
``
The macro code needs massaging to also work on EPEL.
Most of the work is spec side since some of the macros are going to collide with the ones provided by previous iterations of Go macro packages
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/2
3 weeks, 6 days
[go-rpm-macros] Issue #3: %goprep should apply patches automatically
by Nicolas Mailhot
nim reported a new issue against the project: `go-rpm-macros` that you are following:
``
`%goprep` should apply patches automatically, so there is no convenience gap with `%autosetup`.
This is generic work that should be done *redhat-rpm-config* side in forge macros and then reused in`%goprep`. Basically:
1. define a `patch_flags<suffix>` rpm variable holding the parameters that should be passed to `%patch<suffix>`
2. define a `default_flags<suffix>` fallback
3. define a `source_patches<suffix>` holding an ordered space separated list of patch suffixes associated with a particular forge/go source.
And then write the usual lua loops to apply it all at the right moment in the spec.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/3
3 weeks, 6 days
[go-rpm-macros] Issue #36: Renaming BUILDTAGS and LDFLAGS to include GO prefixes
by Link Dupont
linkdupont reported a new issue against the project: `go-rpm-macros` that you are following:
``
In #34 and #35, it was brought up to rename the `BUILDTAGS` variable to `GOBUILDTAGS` in order to be more explicit about the intended use of the variables and to avoid any potential namespace collision with other variables. I looked into what packages are using `BUILDTAGS` today to figure out how much of an impact a rename like this will have.
As of this writing, the following packages are using `BUILDTAGS` in some capacity:
```
buildah.spec
containernetworking-plugins.spec
cri-tools.spec
go-compilers.spec
golang-github-prometheus-node-exporter.spec
golang-github-prometheus.spec
grafana.spec
hugo.spec
moby-engine.spec
oci-seccomp-bpf-hook.spec
pack.spec
podman.spec
reg.spec
runc.spec
skopeo.spec
snapd.spec
source-to-image.spec
stargz-snapshotter.spec
syncthing.spec
weldr-client.spec
```
And the follow packages use `LDFLAGS`:
```
aerc.spec
age.spec
butane.spec
clash.spec
containerd.spec
doctl.spec
fzf.spec
geoipupdate.spec
git-lfs.spec
golang-github-aliyun-cli.spec
golang-github-colinmarc-hdfs-2.spec
golang-github-haproxytech-dataplaneapi.spec
golang-github-hub.spec
golang-github-jsonnet-bundler.spec
golang-github-magefile-mage.spec
golang-github-prometheus.spec
golang-github-rfjakob-gocryptfs.spec
golang-github-tdewolff-minify.spec
golang-github-theoapp-theo-agent.spec
golang-mvdan-editorconfig.spec
ignition.spec
kiln.spec
micro.spec
open-policy-agent.spec
osbuild-composer.spec
rclone.spec
reg.spec
source-to-image.spec
syncthing.spec
tinygo.spec
vgrep.spec
weldr-client.spec
```
I identified these packages by grepping the contents of the [current spec tarball](https://src.fedoraproject.org/repo/rpm-specs-latest.tar.xz).
To avoid breaking these packages that are currently using `BUILDTAGS` or `LDFLAGS`, there are two possible approaches I see to safely rename the variables:
#### 1. Rebuild everything in a side-tag
Patch `go-rpm-macros` to rename `BUILDTAGS` and `LDFLAGS` to `GOBUILDTAGS` and `GOLDFLAGS` respectively. Then patch the above packages and stage them all in a side-tag to update them in one monolithic Bodhi update.
#### 2. Support both old and new variables at the same time
Patch `go-rpm-macros` to support **both** `BUILDTAGS`/`LDFLAGS` *and* `GOBUILDTAGS`/`GOLDFLAGS` simultaneously. Then patch the above packages over time until everything has been ported over to using `GOBUILDTAGS` and `GOLDFLAGS`, and then drop the old variables from `go-rpm-macros`.
I'm not sure how easy either of these approaches will be. They are both moving targets as new packages are constantly getting added. It might just be a constant effort to try and keep on top of all the patches as new packages come along and patches need to be rebased onto their target's changes.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/36
3 weeks, 6 days
[golist] Issue #28: golist fails when new go-1.17 `//go:build` style is used
by Mikel Olasagasti
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>
sys.exit(main())
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
https://pagure.io/golist/issue/28
1 year, 10 months
golang 1.16 for epel7?
by Dave Dykstra
What will it take to get golang updated on epel7 from the no longer
supported version 1.15? RHEL8.5 reports a long list of security
problems that are fixed in 1.16.
Dave
2 years, 3 months
`BuildArch: noarch` on -devel only packages
by Maxwell G
Hi everyone,
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.
Thanks,
Maxwell
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8
PGP Keyserver: hkp://keyserver.ubuntu.com
gotmax(a)e.email
2 years, 3 months
go builds broken in rawhide?
by Mikel Olasagasti
Hi folks,
Koschei reported failure on some of my packages and also received some
F36FailsToInstall BZs.
Checking root.log and F36FailsToInstall reports I can see the
following output for one package, but the rest are similar with less
missing deps.
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[1] I can see some F36FailsToInstall have been
reported also. But checking Koschei I can see a lot of builds were
successful today[2] with just a few failures.
I see 1.18beta1[3] was pushed two days ago, maybe it is related?
Is anyone else experiencing this problem?
Is there any way to fix or workaround it?
Kind regards,
Mikel
[1] https://packager-dashboard.fedoraproject.org/user/go-sig
[2] https://koschei.fedoraproject.org/?collection=f36&order_by=-started%2Crun...
[3] https://bodhi.fedoraproject.org/updates/FEDORA-2021-3f38293040
2 years, 4 months
