golang December 2021

golang@lists.fedoraproject.org

9 participants
11 discussions

[go-rpm-macros] Issue #36: Renaming BUILDTAGS and LDFLAGS to include GO prefixes
by Link Dupont 20 Jun '22

20 Jun '22

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 4

[golist] Issue #28: golist fails when new go-1.17 `//go:build` style is used
by Mikel Olasagasti 07 Jun '22

07 Jun '22

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 4

golang 1.16 for epel7?
by Dave Dykstra 21 Jan '22

21 Jan '22

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

5 9

`BuildArch: noarch` on -devel only packages
by Maxwell G 04 Jan '22

04 Jan '22

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 1

debug_package when using go_generate_buildrequires
by Mikel Olasagasti 20 Dec '21

20 Dec '21

Hi all, I was updating some golang specs I've and switching them to use go_generate_buildrequires. I realized that some specs that are using it fail to build if `%global debug_package %{nil}` is not set. Same spec with all BuildRequires defined works just fine. Example: - Full spec (go2rpm): https://mikel.olasagasti.info/tmp/fedora/golang-github-alecaivazis-survey-2… - go_generate_buildrequires spec: https://raw.githubusercontent.com/mikelolasagasti/github-cli/main/golang-gi… - Full spec build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79642572 - go_generate_buildrequires build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79642147 Is this expected? Is adding `%global debug_package %{nil}` correct or good practice for this scenario? Kind regards, Mikel Olasagasti (mikelo2)

4 4

go builds broken in rawhide?
by Mikel Olasagasti 20 Dec '21

20 Dec '21

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%2Crunni… [3] https://bodhi.fedoraproject.org/updates/FEDORA-2021-3f38293040

2 2

[go-rpm-macros] PR #37: srpm/go.lua: fix handling of version numbers with multiple digits
by Tommi Rantala 19 Dec '21

19 Dec '21

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 https://pagure.io/go-rpm-macros/pull-request/37

3 3

[Fedocal] Reminder meeting : Go SIG
by jcajka＠fedoraproject.org 19 Dec '21

19 Dec '21

Dear all, You are kindly invited to the meeting: Go SIG on 2021-12-20 from 20:00:00 to 21:00:00 Europe/Prague At fedora-golang(a)libera.chat The meeting will be about: Fedora's Go SIG meeting More information available at: [https://pagure.io/GoSIG/go-sig/](https://pagure.io/GoSIG/go-sig/) Source: https://calendar.fedoraproject.org//meeting/10012/

1 0

About how Go is updated in Fedora
by Alejandro Saez Morollon 18 Dec '21

18 Dec '21

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 it. 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. The problem: 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 rebuild phase. 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 [0]. 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 [1] 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. [0] https://github.com/containers/podman/pull/12544 [1] https://alexsaezm.fedorapeople.org/report.html -> let it load, it has a JS that allows you to search

2 3

[Fedocal] Reminder meeting : Go SIG
by jcajka＠fedoraproject.org 05 Dec '21

05 Dec '21

Dear all, You are kindly invited to the meeting: Go SIG on 2021-12-06 from 20:00:00 to 21:00:00 Europe/Prague At fedora-golang(a)libera.chat The meeting will be about: Fedora's Go SIG meeting More information available at: [https://pagure.io/GoSIG/go-sig/](https://pagure.io/GoSIG/go-sig/) Source: https://calendar.fedoraproject.org//meeting/10012/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang December 2021