September 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

Hashicorp Consul Packages
by Mark E. Fuller 01 Oct '22

01 Oct '22

In my continuing work on building terraform[0], I have a what appears to be a version conflict between two hashicorp consul packages: ... Error: Transaction test error: file /usr/share/gocode/src/github.com/hashicorp/consul/.goipath conflicts between attempted installs of golang-github-hashicorp-consul-sdk-devel-0.7.0-5.fc37.noarch and golang-github-hashicorp-consul-api-devel-1.9.1-7.fc38.noarch file /usr/share/gocode/src/github.com/hashicorp/consul/CHANGELOG.md conflicts between attempted installs of golang-github-hashicorp-consul-sdk-devel-0.7.0-5.fc37.noarch and golang-github-hashicorp-consul-api-devel-1.9.1-7.fc38.noarch file /usr/share/gocode/src/github.com/hashicorp/consul/go.mod conflicts between attempted installs of golang-github-hashicorp-consul-sdk-devel-0.7.0-5.fc37.noarch and golang-github-hashicorp-consul-api-devel-1.9.1-7.fc38.noarch ... Both of these packages (see [1] and [2]) are derived from the same repo, github.com/hashicorp/consul. My question is, why are there two packages pointing to the same repo? (Yes, I realize it is two different modules within it, but could they be merged?) Second, is there a way I can address this conflict on my end or are modifications to one or both of the consul packages required to resolve the issue? [0] https://download.copr.fedorainfracloud.org/results/fuller/terraform/fedora-… [1] https://src.fedoraproject.org/rpms/golang-github-hashicorp-consul-sdk/blob/… [2] https://src.fedoraproject.org/rpms/golang-github-hashicorp-consul-api/blob/… -- Mark E. Fuller, Ph.D. fuller(a)fedoraproject.org fuller(a)mefuller.dev @fuller:fedora.im @fuller:one.ems.host https://www.stossrohr.net PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60

2 2

CVE Tracking Bugs
by Maxwell G 30 Sep '22

30 Sep '22

Hi Fedorians, I think the security tracking bug filing process needs to be amended. The current process is quite frustrating for me and other contributors. This is especially bad for Go CVEs, which there are lot of. Red Hat Product Security creates a single tracking bug for Fedora{, EPEL} _and_ all Red Hat products and CCs a bunch of Fedora maintainers. They then create separate bugs for each package that they deem affected. The affected packages are oftened determined in a manner that appears overzealous and arbitrary. After the bugs are created, we get spammed with a bunch of notifications about private bugs, RH product errata, and various other things that are completely irrelevant to Fedora. These messages flood my Bugzilla mailbox and obscure actual issues that I need to address. I do not really care whether a Go CVE has been mitigated in Red Hat Advanced Cluster Management for Kubernetes 2.4 for RHEL 8" or "Red Hat Advanced Cluster Management for Kubernetes 2.5 for RHEL 8" or "Red Hat Advanced Cluster Management for Kubernetes 2.6 for RHEL 8." --- Some particularly egregious examples: I maintain an Ansible kubernetes collection, and they reported it as vulnerable to some CVE with a specific Openshift component. The collection not vulnerable. They provided no actionable information, and the description was unclear. When I asked why it was reported, they said that the package "used OpenShift." A couple Go CVEs ago[^1], they created bugs against hundreds of Go libraries. They arbitrarily chose branches and packages. The bugs were not actionable by packagers of individual go libraries. Only applications that provide binaries need to be rebuilt. They were reported shortly before the F34 EOL, so we got a huge amount of emails after the bugs were automatically closed. In fact, a Go packager reported that these messages from the _security_ team DOSed their mail server. To their credit, they have fixed this issue after one of the other Go SIG people talked to them. Now, these bugs are only filed against the golang component. [^1]: Really, it was a couple Go releases ago. There are multiple CVEs reported with each Go release these days. Another time, their automation posted the exact same comment over 200 times. --- First and foremost, there needs to be a clear way for packagers to report problems with this process to prodsec. I don't think Fedora packagers should be CCed on these global trackers. We could create a separate "Security Response" component under the "Fedora" Bugzilla product to create tracker bugs for CVEs that affect multiple Fedora components, or we could ask prodsec to only CC Fedora maintainers on the child, package-level bugs. I guess I could acomplish what I'm proposing by filtering out mails with "X-Bugzilla-Product: Security Response" headers and not have gone on this rant, but I still think this needs to be addressed. Does anyone know how to reach prodsec about this? -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His

3 2

Working on building Terraform - couple questions
by Mark E. Fuller 26 Sep '22

26 Sep '22

Hi all, I'm working on a COPR to try to get Terraform built so that I can get it into Fedora and I have just a few minor issues outstanding that I could use some feedback/help on: 1) https://download.copr.fedorainfracloud.org/results/fuller/terraform/fedora-… ... cannot find package "github.com/hashicorp/aws-sdk-go-base/tools" in any of: /usr/lib/golang/src/github.com/hashicorp/aws-sdk-go-base/tools (from $GOROOT) /builddir/build/BUILD/aws-sdk-go-base-0.4.0/_build/src/github.com/hashicorp/aws-sdk-go-base/tools (from $GOPATH) /usr/share/gocode/src/github.com/hashicorp/aws-sdk-go-base/tools ... Can anyone suggest why I would get the error that this package cannot find one of its own internal modules? 2) https://download.copr.fedorainfracloud.org/results/fuller/terraform/fedora-… ... No matching package to install: 'golang(github.com/tencentyun/qcloud-cos-sts-sdk/go)' ... Here I have already built golang(github.com/tencentyun/qcloud-cos-sts-sdk) in my COPR, but the module references above ($TL/go) isn't found. Any thoughts? 3) And finally, I've disabled tests in a few places - doing so with e.g. "-d folder" works fine, but e.g. "-d internal/folder" for a subfolder doesn't seem to work right? Is there a syntax issue I'm missing, or did I just misread something and both examples I gave here are correct? Thanks all, fuller -- Mark E. Fuller, Ph.D. fuller(a)fedoraproject.org fuller(a)mefuller.dev @fuller:fedora.im @fuller:one.ems.host https://www.stossrohr.net PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60

3 2

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

25 Sep '22

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

Re: Non-responsive maintainer check for olem
by Maxwell G 25 Sep '22

25 Sep '22

On Fri Sep 2, 2022, Maxwell G via devel wrote: > > Sep 2, 2022 5:36:41 AM Fabio Valentini <decathorpe(a)gmail.com>: > > > Does anybody know whether olem still wants to maintain their Fedora > > packages? > I'm fairly sure that they no longer wish to maintain Fedora packages. I > reached out to them about moby-engine and containerd at the end of May, > and they said they no longer have time to maintain them. I have been > maintaining those packages myself for a while. > > Side note: I have asked for co-maintainers for those packages a couple > times, but so far, I have not found any. Perhaps one of the CoreOS people > would be interested? It seems those packages are used a lot there based > on the bug reports we've gotten. It looks like the nonresponsive maintainer process is going to proceed. I've done some analysis of the Go packages that will be orphaned so the Go SIG can figured out how to handle this. This was done by hand, so please excuse any errors. The following packages are dependencies of golang-github-docker{,-cli} and/or containerd: 1. golang-github-hanwen-fuse 2. golang-github-fvbommel-sortorder 3. golang-github-containerd-nri 4. golang-github-moby-locker 5. golang-github-moby-term 6. golang-github-tonistiigi-rosetta 7. golang-github-google-containerregistry 8. golang-github-containerd-stargz-snapshotter (FTBFS) 9. golang-github-kyokomi-emoji is a dependency of hugo olem also maintained open-policy-agent and some of its dependencies: - open-policy-agent - golang-github-yashtewari-glob-intersection (open-policy-agent is the only dependent) - golang-uber-automaxprocs (dependency of both open-policy-agent and clash) This maintainer also maintained golang-github-jsonnet-bundler and golang-github-containerd-cni. These packages are leaves. I sent a separate message to the golang list about retiring these. I suppose we could just wait for it to happen automatically. Many of these libraries are out of date, but only one of them FTBFS (according to Koschei), which I'd consider pretty good. Updating these packages will likely require packaging a bunch of new dependencies. I think eclipseo has been doing some work on the docker side of things, though. Thanks for that! I have been keeping containerd and moby-engine up to date. moby-engine could use a cleanup. Currently, docker-proxy (github.com/moby/libnetwork) docker-init (bundled tini-static), dockerd (github.com/moby/moby) and the docker cli (github.com/docker/cli) are all part of the moby-engine package. This makes the specfile rather cumbersome. Ideally, it should be split up. I just haven't had the time to do so. docker cli should be straightforward. github.com/moby/libnetwork will soon be merged into github.com/moby/moby, so docker-proxy doesn't make sense to split out right now. For docker-init, we should investigate whether we could configure docker to look for the existing tini-static binary or at least create a symlink. It expects the binary to be installed to %{_libexecdir}/docker/docker-init. I am really not a fan of the bundled tini-static. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His

2 1

[go-rpm-macros] Issue #50: arched devel packages
by Mikel Olasagasti 23 Sep '22

23 Sep '22

mikelo2 reported a new issue against the project: `go-rpm-macros` that you are following: `` Currently there is no option to ship arched devel packages. The ask is to have a macro, `%go_arched_devel` for example, to allow certain packages's devel package, `golang-x-crypto` for example, to be arched rather than noarch, so package depending on them can benefit from extra performance. The rest of the devel packages that don't declare the macro would be still noarch. `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/50

3 4

golang-github-containerd-cri
by Maxwell G 21 Sep '22

21 Sep '22

Hi everyone, golang-github-containerd-cri is no longer needed by anything. The repository is archived upstream[1], as it has moved into containerd itself (github.com/containerd/containerd/pkg/cri) I would like to retire this package. $ sudo dnf repoquery -q --repo=rawhide{,-source} --whatrequires golang-github-containerd-cri-devel (nothing) [1]: https://github.com/containerd/cri/blob/release/1.4/README.md -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His

1 0

[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

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

11 Sep '22

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang September 2022