golang November 2020

golang@lists.fedoraproject.org

4 participants
10 discussions

[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] PR #20: Use --with-tests when running checks also.
by Elliott Sales de Andrade 05 Sep '21

05 Sep '21

qulogic opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Use --with-tests when running checks also. `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/20

1 2

[go-rpm-macros] PR #23: macros: Accept options for %gotest
by Alexander Todorov 21 Jun '21

21 Jun '21

atodorov opened a new pull-request against the project: `go-rpm-macros` that you are following: `` macros: Accept options for %gotest `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/23

4 7

[go-rpm-macros] Issue #25: Consider using -trimpath
by Debarshi Ray 26 Apr '21

26 Apr '21

rishi reported a new issue against the project: `go-rpm-macros` that you are following: `` See [this](https://github.com/containers/toolbox/pull/448) [Toolbox](https://github.com/containers/toolbox) discussion for context. It might be good to include `-trimpath` in `%gobuild` and `%gobuildflags`. Apparently Arch Linux already uses it. `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/25

4 9

[go-rpm-macros] Issue #19: LDFlags Macro Typos
by Brian Exelbierd (bex) 20 Apr '21

20 Apr '21

bex reported a new issue against the project: `go-rpm-macros` that you are following: `` While working with a new package, I needed some LDFlags passed. I am using this construction in my spec: ``` %build LDFLAGS="-X foo=bar " %gobuild ... ``` I have to put the space in quotes at the end as we appear to have space expansion errors. I was talking to @ignatenkobrain and he pointed out: * https://pagure.io/go-rpm-macros/blob/master/f/rpm/macros.d/macros.go-rpm#_3… there is a missing space * https://pagure.io/go-rpm-macros/blob/master/f/rpm/macros.d/macros.go-compil… ${LDFLAGS:-%{?currentgoldflags}} ← should be like that `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/19

3 4

[go-rpm-macros] PR #26: Remove tildes from goname
by Benjamin Lowry 20 Apr '21

20 Apr '21

blowry opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Remove tildes from goname `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/26

6 13

[Fedocal] Reminder meeting : Go SIG Meeting
by jcajka＠fedoraproject.org 21 Nov '20

21 Nov '20

Dear all, You are kindly invited to the meeting: Go SIG Meeting on 2020-11-23 from 19:00:00 to 20:00:00 Europe/Prague At fedora-golang(a)irc.freenode.net The meeting will be about: Meeting of Go SIG. For proposed agenda see the tagged tickets https://pagure.io/GoSIG/go-sig/issues?status=Open&tags=meeting Source: https://apps.fedoraproject.org/calendar/meeting/9758/

1 0

[Fedocal] Reminder meeting : Go SIG Meeting
by jcajka＠fedoraproject.org 07 Nov '20

07 Nov '20

Dear all, You are kindly invited to the meeting: Go SIG Meeting on 2020-11-09 from 19:00:00 to 20:00:00 Europe/Prague At fedora-golang(a)irc.freenode.net The meeting will be about: Meeting of Go SIG. For proposed agenda see the tagged tickets https://pagure.io/GoSIG/go-sig/issues?status=Open&tags=meeting Source: https://apps.fedoraproject.org/calendar/meeting/9758/

1 0

Packaging of Go modules
by Olivier Lemasle 06 Nov '20

06 Nov '20

Hi all, I have two questions related to the packaging of Go modules. 1. When a new major version of a Go module is released, breaking backwards compatibility, the module path should be changed [1]. According to the Golang Packaging Guidelines, it means updating the goipath and renaming the package, right? goaltipaths is then set to the old import path, right? Looking for examples of Go packages with such a transition, I found the opposite: for example gotest.tools was updated to gotest.tools/v3, but Fedora package golang-gotest [2] has the following in spec: %global goipath gotest.tools %global goaltipaths gotest.tools/v3 Shouldn't it be the opposite? Is it required for all Go Fedora packages to be renamed when a new major version is released? It will cause quite a burden if this require a review request for every upgrade. 2. What should be done for multi-module repositories [3]? These repositories contain multiple Go modules (each one with its go.mod); git tags are created for each module (with the form path/version). An example of such a multi-modules repository is https://github.com/moby/sys, which contains 3 modules; - github.com/moby/sys/mount - github.com/moby/sys/mountinfo - github.com/moby/sys/symlink Tags are created for each module [4]; each module has a different version. Current Fedora package golang-github-moby-sys [5] package it like any other Go package, but tags do not follow monotonically increasing versions. I suppose it could be possible to version such a package as if there was no tagged release (so Version: 0, and git hash in release number). But it seems perhaps more logical to have a Fedora package for each Go module in the repository, as a project may depend on each module with a different version... Thanks, -- Olivier Lemasle FAS: olem [1] https://blog.golang.org/v2-go-modules [2] https://src.fedoraproject.org/rpms/golang-gotest [3] https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories [4] https://github.com/moby/sys/tags [5] https://src.fedoraproject.org/rpms/golang-github-moby-sys

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang November 2020