golang March 2024

golang@lists.fedoraproject.org

6 participants
11 discussions

Issues packaging transifex-cli
by Mikel Olasagasti 16 Apr '24

16 Apr '24

Hi all, I'm trying to package transifex-cli but I find the following error in the %install phase: /usr/bin/strip: /builddir/build/BUILDROOT/transifex-client-1.6.10-1.fc41.x86_64/usr/bin/tx(__.PKGDEF): Unable to recognise the format of file: file format not recognized /usr/bin/strip: /builddir/build/BUILDROOT/transifex-client-1.6.10-1.fc41.x86_64/usr/bin/tx(_go_.o): Unable to recognise the format of file: file format not recognized %check phase is OK and during the final phase this is reported: Provides: transifex-client = 1.6.10-1.fc41 transifex-client(x86-64) = 1.6.10-1.fc41 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Processing files: transifex-client-debugsource-1.6.10-1.fc41.x86_64 error: Empty %files file /builddir/build/BUILD/cli-1.6.10/debugsourcefiles.list RPM build errors: Empty %files file /builddir/build/BUILD/cli-1.6.10/debugsourcefiles.list Finish: rpmbuild transifex-client-1.6.10-1.fc41.src.rpm Finish: build phase for transifex-client-1.6.10-1.fc41.src.rpm Spec[1] doesn't have anything special and build logs are available[2]. It fails for all current Fedora versions. Any idea what could be happening? Regards, Mikel [1] https://github.com/mikelolasagasti/transifex-client-specs [2] https://copr.fedorainfracloud.org/coprs/mikelo2/transifex-client/build/7232…

1 1

The Docker Stack and Go Vendoring
by Maxwell G 12 Apr '24

12 Apr '24

Hi everyone, Intro There have been on-and-off discussions within the Go SIG about vendoring dependencies. To put my thoughts into words, I wrote a blog post [0] about the issues with Go dependency de-vendoring that Fedora currently does. Docker stack vendoring I worry that the current approach to dependency management is unfeasible—especially for complex package stacks like Containerd/Docker/Moby. These packages and the underlying libraries have huge dependency trees and circular dependencies and have been out-of-date for months or longer. moby-engine already takes a complicated, hybrid approach to vendoring (part of the package uses vendored dependencies, part does not), while containerd is all un-bundled. Getting everything up-to-date will require a significant amount of work that nobody has stepped up to do, and in my view, is ultimately unsustainable. Last year, I onboarded new contributors, as I no longer could dedicate time to maintain these packages, but it was also difficult for them to keep up with the web of dependencies. I propose we start with fully vendoring the Docker stack. As I said, parts of moby-engine are already bundled, and so are podman, kubernetes, cri-o, containernetworking-plugins, and other applications in the written-in-Go containerization stack. I have been working on revamped Docker stack packages at [1]. I believe that the simplified packaging approach will entice new maintainers to come onboard—I have already reached out to one. I also wrote specfiles for Docker Buildx and Docker Compose v2 that were not feasible to package with the previous approach. Overall Go ecosystem Then, we can re-evaluate the overall state of the Go library ecosystem. I am not proposing that we immediately mass retire all Go libraries and vendor everything, but I think we need to consider the overall health of Go applications in Fedora and consider vendoring in at least some cases. I will also note the Go Packaging Guidelines' current stance on the vendoring[2]: > At the moment golang projects packaged in Fedora SHOULD be unbundled > by default. It means projects are built from dependencies packaged in > Fedora. > > For some project it can be reasonable to build from bundled > dependencies. Every bundling needs a proper justification. > Vendoring the Docker stack is allowed under this guideline. Any more drastic steps to mass de-vendor certain packages or use vendoring for any new packages would obviously require guidelines changes—but again, we are not there yet. There is more tooling work to be done and more discussion to be had. go-vendor-tools I have been working on go-vendor-tools [3], a tool to enable packaging vendored Go applications in a Guidelines-compliant way, for the past couple weeks. go-vendor-tools aims to make creating fully reproducible vendor archives and handling licensing a relatively frictionless process. The tool also natively supports regenerating vendor tarballs to apply security updates[4]. See [5] for instructions to test the latest go-vendor-tools and the current iteration of the go2rpm code to allow automatically generating vendored Go package specfiles. I look forward to your feedback. *** If you have read this far, thank you! Any feedback about the Docker stack or Go vendoring overall is welcome. Best, Maxwell [0] https://gtmx.me/blog/fedora-go-unbundling-is-broken/ [1] https://git.sr.ht/~gotmax23/docker-ng [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_bundled_… [3] https://fedora.gitlab.io/sigs/go/go-vendor-tools/ [4] https://fedora.gitlab.io/sigs/go/go-vendor-tools/scenarios/#security-updates [5] https://gitlab.com/fedora/sigs/go/go2rpm/-/merge_requests/4 -- Maxwell G (@gotmax23) Pronouns: He/They

4 7

[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] Issue #64: %license LICENSE vendor/modules.txt fails with certain module.txt files
by Brad Smith 29 Mar '24

29 Mar '24

buckaroogeek reported a new issue against the project: `go-rpm-macros` that you are following: `` Processing vendor/modules.txt file for kubernetes will fail. Error (using modified code to show problem) is similar to: ``` # gopkg.in/yaml.v2 v2.4.0 # gopkg.in/yaml.v3 v3.0.1 # k8s.io/api v0.0.0 => ./staging/src/k8s.io/api Traceback (most recent call last): File "/home/bgsmith/tmp/go/vendor2provides.py", line 55, in <module> exit(main()) ^^^^^^ File "/home/bgsmith/tmp/go/vendor2provides.py", line 38, in main ipath, version = replace_regex.sub("", dep[2:]).split(" ")[:2] ^^^^^^^^^^^^^^ ValueError: not enough values to unpack (expected 2, got 1) ``` The modules.txt file can be found at: https://github.com/kubernetes/kubernetes/blob/master/vendor/modules.txt. In https://github.com/kubernetes/kubernetes/blob/master/staging/README.md the kubernetes team writes: "Kubernetes code uses the repositories in this directory via a Go workspace and module replace statements. For example, when Kubernetes code imports a package from the k8s.io/client-go repository, that import is resolved to staging/src/k8s.io/client-go relative to the project root:" It appears that using Replace directive in go.mod and/or go.work results in the lines like ```# k8s.io/api v0.0.0 => ./staging/src/k8s.io/api``` which are not (yet) handled by the script. I do not know if these lines should be parsed or just skipped? If parsing is needed, then how to get the correct version? `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/64

2 2

[go-rpm-macros] PR #65: go_mod_vendor.prov: handle local replace directives
by Maxwell G 29 Mar '24

29 Mar '24

gotmax23 opened a new pull-request against the project: `go-rpm-macros` that you are following: `` go_mod_vendor.prov: handle local replace directives `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/65

2 2

New version of Hugo, new dependencies
by W. Michael Petullo 17 Mar '24

17 Mar '24

I have some review requests for Go packages that are required for Hugo 0.124.0: https://bugzilla.redhat.com/show_bug.cgi?id=2269893 https://bugzilla.redhat.com/show_bug.cgi?id=2269901 Once these are approved, I will update our Hugo package to 0.124.0. I am working through updating the existing packages to the versions required by Hugo 0.124.0 in COPR: https://copr.fedorainfracloud.org/coprs/mikep/golang/builds/ -- Mike :wq

2 1

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang March 2024