August 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] Issue #46: %gobuildflags missing double quotation marks
by Petr Hruska 29 Mar '24

29 Mar '24

hruskape reported a new issue against the project: `go-rpm-macros` that you are following: `` It seems that commit https://pagure.io/go-rpm-macros/c/359d80bbfe7f0490fc51c43af8d986863516c5bb?… breaking %gobuildflags usage in spec file. Getting error, as double quotation marks are removed. Specfile section unset LDFLAGS %make_build GOBUILDFLAGS="%{gobuildflags}" Error: + /usr/bin/make -O -j16 V=1 VERBOSE=1 'GOBUILDFLAGS=-buildmode pie -compiler gc -tags=rpm_crashtraceback' ' -ldflags ' -B 0x3433f3bcad171c4e7f8f736da295a9fac8289b8c -compressdwarf=false -extldflags '-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -a -v -x' /usr/bin/make: invalid option -- 'c' /usr/bin/make: invalid option -- 'x' Usage: make [options] [target] ... `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/46

2 3

[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

Thread to send your Golang package reviews which are waiting
by Robert-André Mauchin 07 Mar '23

07 Mar '23

Thread to send your Golang package reviews which are waiting... reply to this thread so we can sync up our efforts. Best regards Robert-André

5 6

[golist] PR #30: Don't skip testdata
by Matyáš Kroupa 21 Feb '23

21 Feb '23

krouma opened a new pull-request against the project: `golist` that you are following: `` Don't skip testdata `` To reply, visit the link below or just reply to this email https://pagure.io/golist/pull-request/30

3 3

[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] PR #29: Deduplicate CollectProjectDeps
by Matyáš Kroupa 20 Feb '23

20 Feb '23

krouma opened a new pull-request against the project: `golist` that you are following: `` Deduplicate CollectProjectDeps `` To reply, visit the link below or just reply to this email https://pagure.io/golist/pull-request/29

2 1

[go-rpm-macros] PR #47: Use Fedora's build flags for cgo.
by Maxwell G 13 Sep '22

13 Sep '22

gotmax23 opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Use Fedora's build flags for cgo. `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/47

2 6

[go-rpm-macros] PR #49: Add RPM generator for bundled Provides
by Maxwell G 02 Sep '22

02 Sep '22

gotmax23 opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Add RPM generator for bundled Provides `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/49

2 4

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

28 Aug '22

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

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

14 Aug '22

Dear all, You are kindly invited to the meeting: Go SIG on 2022-08-15 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 SIG] Meeting schedule poll
by Alejandro Saez Morollon 14 Aug '22

14 Aug '22

Hi everyone. As requested multiple times during the Go SIG meetings that we do at the IRC room, we should try to search for a new time slot. So we have two things to discuss, the cadence of the meetings and the schedule. Cadence poll: https://framadate.org/JsnSXSfqAvwNNMyz Schedule poll: https://doodle.com/meeting/participate/id/e58BjQ8d P.S: If anyone has issues with the links, just let me know, first time dealing with the tools :-/

6 8

[go-rpm-macros] PR #48: Introduce %golang_arches_future and stop using %go_arches
by Maxwell G 07 Aug '22

07 Aug '22

gotmax23 opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Introduce %golang_arches_future and stop using %go_arches `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/48

2 6

Announcing go2rpm 1.7.0
by Robert-André Mauchin 06 Aug '22

06 Aug '22

Hello, Go2rpm 1.7.0 has been published, featuring: - Use of SPDX licenses - Automatic Generation of RPM Release Fields and Changelogs are now the default. (-r flag) - By default, the cache for chosen Go import path is now cleaned. (-C flag) Best regards, Robert-André

1 0

About quic-go and qtls-go library
by Mikel Olasagasti 03 Aug '22

03 Aug '22

Hi all, This is an informative mail about how quic-go and it's golang-github-marten-seemann-qtls-goX-XX dependency work. As upstream explains[1]: "quic-go is tied to the version of the Go compiler. Any release that we cut supports the two most recent Go version.". This behavior requires a new package of `golang-github-marten-seemann-qtls-go` per major release. Currently Fedora has packaged the following versions: golang-github-marten-seemann-qtls-go1-15 golang-github-marten-seemann-qtls-go1-16 golang-github-marten-seemann-qtls-go1-17 golang-github-marten-seemann-qtls-go1-18 golang-github-marten-seemann-qtls-go1-19 Fedora has the following golang releases: rawhide: 1.19 f36 1.18 f35 1.16 epel7 1.17 This means that version for 1.15 can be retired safely now and each of the releases previous to 1.19 can be retired also from rawhide. Then, once every new golang major release is added, previous version of the golang-github-marten-seemann-qtls-go package should be retired from rawhide, as it doesn't make any sense to keep maintaining it for the next Fedora release. So, unless someone thinks this should be handled differently, I'll start retiring all versions <1.19. Kind regards, Mikel Olasagasti (mikelo2) [1] https://github.com/lucas-clemente/quic-go/wiki/quic-go-and-Go-versions

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang August 2022