golang May 2023

golang@lists.fedoraproject.org

6 participants
13 discussions

[go-rpm-macros] PR #34: Add BUILDTAGS to %gobuildflags
by Brian C. Lane 16 Jul '25

16 Jul '25

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

8 22

[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

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

22 May '23

Dear all, You are kindly invited to the meeting: Go SIG on 2023-05-22 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

compat packages
by Mark E. Fuller 18 May '23

18 May '23

Can anyone point me at an example of building a golang package with a 'compat' package to support an older version? I'm having trouble finding documentation to make sure it's added the 'right' way. Thanks, fuller *Mark E. Fuller, Ph.D.* *fuller(a)fedoraproject.org* *fuller(a)mefuller.dev* *@fuller:fedora.im* *@fuller:one.ems.host* *https://mefuller.dev* *PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60*

2 3

Re: Stuck package - golang-github-prometheus-node-exporter
by Mark E. Fuller 11 May '23

11 May '23

I'll try to push this along - there's a build error that needs resolving (but not at 2:30 AM) see https://bugzilla.redhat.com/show_bug.cgi?id=2112130 Anyone from the golang list want to take a look? -fuller On 02/05/2023 19:25, Pat Riehecky wrote: > golang-github-prometheus-node-exporter seems to be unmaintained at this point. There are a few open CVEs that have been corrected upstream in the last year but not made it down to the fedora package. > > In Feb I opened a maintainer check ticket : https://bugzilla.redhat.com/show_bug.cgi?id=2166945 > > Alas, I'm not able to maintain this package myself. > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

1 0

Packaging the AWS SSM Agent
by Major Hayden 10 May '23

10 May '23

Hey there, I've been working on packaging the AWS SSM Agent[0] in Fedora on and off for a few months now and I finally got a free moment to work on it again. However, there are a few problems that have me scratching my head a little. Just to level set, AWS Systems Manager[1] is an offering that allows AWS customers to manage their instances outside the instance itself. We all know (and love) cloud-init, but it really only handles the first boot provisioning of the instance. The SSM agent has similarities to Azure's WALinuxAgent as it allows for management *after* the first boot. (For reference, WALinuxAgent is already packaged in Fedora and automatically enabled when Fedora lands in an Azure instance.) The main issue is around dependencies: ---------- # No commits since Mar 2021 💀 'golang(github.com/Workiva/go-datastructures)' # Should be covered by the existing aws-sdk-go package 🤔 'golang(github.com/aws/aws-sdk-go/service/backupstorage)' 'golang(github.com/aws/aws-sdk-go/service/privatenetworks)' 'golang(github.com/aws/aws-sdk-go/service/ssm/ssmiface/mocks)' 'golang(github.com/aws/aws-sdk-go/service/ssmmds)' 'golang(github.com/aws/aws-sdk-go/service/ssmmds/ssmmdsiface)' 'golang(github.com/aws/aws-sdk-go/service/ssmmds/ssmmdsiface/mocks)' # No commits since Jan 2017 💀 'golang(github.com/carlescere/scheduler)' # No commits since Jan 2017 💀 'golang(github.com/cihub/seelog)' # No commits since Sep 2018 💀 'golang(github.com/digitalocean/go-smbios/smbios)' # No commits since Sep 2016 💀 'golang(github.com/pborman/ansi)' # Last commit Feb 2023 👍 'golang(github.com/xtaci/smux)' ---------- Some of these have not been updated in quite some time and many of them have several unresolved bugs that are years old. Although I'd like to get the SSM Agent packaged in Fedora, I don't like the idea of packaging quite a few packages which aren't being actively maintained. One potential option is to work with upstream (AWS) to change these dependencies out for actively maintained ones instead, but that likely requires significant development work. 🥵 Another option might be to vendor these dependencies in the main SSM package, but that still means we're building against unmaintained code and it likely violates some Fedora policies. 😱 How should I proceed? Thanks for reading this far? [0] https://github.com/aws/amazon-ssm-agent [1] https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-system… -- Major Hayden

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang May 2023