January 2022 - golang - Fedora mailing-lists

[go-rpm-macros] Issue #2: EPEL availability
by Nicolas Mailhot 29 Mar '24

29 Mar '24

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

2 4

[go-rpm-macros] Issue #3: %goprep should apply patches automatically
by Nicolas Mailhot 29 Mar '24

29 Mar '24

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

6 9

[go-rpm-macros] Issue #36: Renaming BUILDTAGS and LDFLAGS to include GO prefixes
by Link Dupont 29 Mar '24

29 Mar '24

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

4 5

[go-rpm-macros] PR #41: Convert LDFLAGS to GOLDFLAGS and BUILTAGS to GOBUILDTAGS
by Robert-André Mauchin 15 Mar '24

15 Mar '24

eclipseo opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Convert LDFLAGS to GOLDFLAGS and BUILTAGS to GOBUILDTAGS `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/41

2 1

[go-rpm-macros] PR #34: Add BUILDTAGS to %gobuildflags
by Brian C. Lane 21 Feb '23

21 Feb '23

bcl opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Add BUILDTAGS to %gobuildflags `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/34

7 19

[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

[Fedocal] Reminder meeting : Go SIG
by jcajka＠fedoraproject.org 30 Jan '22

30 Jan '22

Dear all, You are kindly invited to the meeting: Go SIG on 2022-01-31 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

[go-rpm-macros] PR #42: Undefine _auto_set_build_flags in %gocheck definition
by Maxwell G 30 Jan '22

30 Jan '22

gotmax23 opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Undefine _auto_set_build_flags in %gocheck definition `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/42

2 4

[go-rpm-macros] PR #40: Try again to fix failures with https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck
by Tom Stellard 30 Jan '22

30 Jan '22

tstellar opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Try again to fix failures with https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/40

4 8

[go-rpm-macros] PR #38: Fix build failures due to https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck
by Tom Stellard 28 Jan '22

28 Jan '22

tstellar opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Fix build failures due to https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/38

3 15

golang-salsa-debian-vasudev-gospake2 license change
by Maxwell G 27 Jan '22

27 Jan '22

As part of the golang-salsa-debian-vasudev-gospake2 0.2.1 update, the license has changed from `LGPLv2+` to `MIT or GPLv3+`. -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax(a)e.email

1 0

[go-rpm-macros] PR #39: Fix gotest ldflags invocation
by Robert-André Mauchin 22 Jan '22

22 Jan '22

eclipseo opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Fix gotest ldflags invocation `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/39

1 1

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

[Fedocal] Reminder meeting : Go SIG
by jcajka＠fedoraproject.org 16 Jan '22

16 Jan '22

Dear all, You are kindly invited to the meeting: Go SIG on 2022-01-17 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

gh: Incorrect %goipath
by Maxwell G 11 Jan '22

11 Jan '22

Hi everyone, I recently became a co-maintainer of gh, and I noticed that the package's `%goipath` is incorrectly set to `github.com/cli/cli` when, according to the go.mod, it should be `github.com/cli/cli/v2`. How should I go about correcting this? We have overridden the package's `%goname` to `gh`, so I can correct the `%goipath` without again having to go through the review process, but the `%godevelname` will change from `golang-github-cli-devel` to `golang-github-cli-2-devel`. Besides obsoleting the old package (see below), is there anything else I need to do? ``` %global godevelheader %{expand: Obsoletes: golang-github-cli-devel < 2.4.0-3 } ``` Thank you for your input, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax(a)e.email

2 2

`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

[Fedocal] Reminder meeting : Go SIG
by jcajka＠fedoraproject.org 02 Jan '22

02 Jan '22

Dear all, You are kindly invited to the meeting: Go SIG on 2022-01-03 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang January 2022