October 2023 - 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

[golist] Issue #32: exclude md files from install
by Robert-André Mauchin 04 Nov '23

04 Nov '23

eclipseo reported a new issue against the project: `golist` that you are following: `` We shouldn't install md files by default. `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/32

2 1

[golist] PR #33: Exclude .md files by default
by Robert-André Mauchin 29 Oct '23

29 Oct '23

eclipseo opened a new pull-request against the project: `golist` that you are following: `` Exclude .md files by default `` To reply, visit the link below or just reply to this email https://pagure.io/golist/pull-request/33

1 1

[go-rpm-macros] PR #56: Fix goname generation to match versioning guildelines
by Robert-André Mauchin 28 Oct '23

28 Oct '23

eclipseo opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Fix goname generation to match versioning guildelines `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/56

2 16

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

22 Oct '23

Dear all, You are kindly invited to the meeting: Go SIG on 2023-10-23 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: Strange(?) build failures for golang package
by Jakub Čajka 11 Oct '23

11 Oct '23

_build/src/github.com/go-task/task/internal/orderedmap/orderedmap.go:94:24 <http://github.com/go-task/task/internal/orderedmap/orderedmap.go:94:24>: type func(i K, j K) bool of less does not match inferred type func(a K, b K) int for func(a E, b E) int is the error. Jakub Čajka Oct 11, 2023, 14:02 by fuller(a)fedoraproject.org: > I am trying to update go-task for some time now and consistently getting a build error/failure with no clear indication of what's happened: > https://download.copr.fedorainfracloud.org/results/fuller/test-builds/fedor… > > Is it possible that there are build flags are default settings in the golang macros that might be leading to this? > > Thanks, > fuller > _______________________________________________ > 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

Strange(?) build failures for golang package
by Mark E. Fuller 11 Oct '23

11 Oct '23

I am trying to update go-task for some time now and consistently getting a build error/failure with no clear indication of what's happened: https://download.copr.fedorainfracloud.org/results/fuller/test-builds/fedor… Is it possible that there are build flags are default settings in the golang macros that might be leading to this? Thanks, fuller

1 0

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

08 Oct '23

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

Important: Package naming issues wrt Packaging Guidelines: an update / Please vote for the solution or propose an alternative
by Robert-André Mauchin 07 Oct '23

07 Oct '23

Hello folks, So, following the ticket to the packaging-commitee: https://pagure.io/packaging-committee/issue/1307 The summary of the meeting is the following: > We discussed this during today's meeting, and there was consensus for two things: > > we don't like that package Name is controlled by a macro where its implementation can change and could lead to situations where source package name != dist-git package name > we don't like the situation we have ended up with wrt/ the Go package naming, since the guidelines around compat packages have been around when the diverging scheme for Go packages was devised, and don't want this to set a precedent for "ignore the guidelines for long enough and it will become accepted practice" > > Our suggestions are: > > If the package names would continue to use a hyphen as separator for the version specifier ("-vN"), we would like the package suffix to be "-vN" as well. > If you would like the current Go naming practices to remain in place, we would consider documenting the exception for using a hyphen as a separator for this purpose. > > For the first option, I think no changes to the Naming Guidelines would be needed. For the second option, an exception would need to be documented in either the Naming Guidelines, or in the Go Packaging Guidelines directly. > > (if I am mis-characterizing something in this summary, please correct me). Maxwell said: >> If you would like the current Go naming practices to remain in place, we would consider documenting the exception for using a hyphen as a separator for this purpose. > > I think that's the best way forward. Carl said: >> Right, this is one of the reasons I'm hesitant to make that change at this point. We could always add a flag to enable the "new" scheme, but I'm not sure that's worthwhile. > > Rather than changing the macro implementation, we can just change the guidelines to say maintainers SHOULD NOT use %{goname}. This is already the case for "well-known application" like containerd, etcd, hugo, and more. Libraries would switch from using %{goname} to an explicit name that follows the package naming guidelines. That wouldn't make the process of requesting a new dist-git repo any easier, but it would make the spec file changes trivial. At some point after all usage of %{goname} is absent from rawhide spec files, the macro could be changed to trigger an error if it's used. > > I would prefer we pick the option that makes the most technical sense, rather than the one that has the most inertia. I'd be open to a "going forward" policy, letting non-compliant package names age out over time (or get converted gradually as people get to them). What I propose: - New packages should adopt the correct guidelines, no hyphen before version. - Older packages should be kept as is for compatibility, i.e. an exception based on existing import path. - In go2rpm we do not use the %goname macro but hardcode the result of it, so if goname change, the Name: field doesn't. - Change the Go packaging guidelines to remove reference to %goname - Progressively replace Name: %{goname} by the hardcoded value while the package are updated. As such: - in go-rpm-macro, I make a list of 130-ish goipath exception list. If it is not in the list, the goname is computed according to official guidelines. - in go2rpm, same thing, and instead of putting %goname in Name: field, we put the computed value. Here are the merge requests: - go-rpm-macros: https://pagure.io/go-rpm-macros/pull-request/56 - go2rpm: https://pagure.io/GoSIG/go2rpm/pull-request/31 Testing is done here: https://copr.fedorainfracloud.org/coprs/eclipseo/macros-fix3/builds/ /!\ I'd like your opinion as soon as possible so we can unstuck packages in fedora-scm-requests /!\ I do not want to wait for the next meeting in a week. Please vote, propose other solutions here or in the Pagure SIG ticket: https://pagure.io/GoSIG/go-sig/issue/53#comment-877603 Best regards, Robert-André

1 0

[go-rpm-macros] PR #55: Fix goname generation to match versioning guildelines
by Robert-André Mauchin 07 Oct '23

07 Oct '23

eclipseo opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Fix goname generation to match versioning guildelines `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/55

4 10

google-guest-agent future (hashicorp vault dependency)
by Major Hayden 07 Oct '23

07 Oct '23

Hey y'all, I'm the maintainer for google-guest-agent[0] and the most recent updates from upstream add some extra dependencies. Much of this stems from some additional confidential computing functionality added to the guest agent. If I follow the new chain of dependencies down the path, I eventually land on Hashicorp Vault. I'm far from a licensing expert, but it appears that the Vault license is incompatible with Fedora's licensing requirements. I see a few options here: 1) Try to pry out some of the confidential computing items from the latest upstream release. I cannot guarantee this will work and it will set Fedora back a bit on confidential computing support. 2) Try to work through the dependencies to see if the Vault dependency can be avoided somehow. 3) Find a new maintainer for the package with much better golang skills than I have. 🤣 4) Ask upstream about shortening the dependency list somehow. I'm planning to start with #4, but I'm running very low on time to maintain this package. Does anyone else have any other suggestions I might have missed? [0] https://src.fedoraproject.org/rpms/google-guest-agent -- Major Hayden

2 1

The following noarch package built differently
by W. Michael Petullo 04 Oct '23

04 Oct '23

I recently finished packaging the dependencies for golang-modernc-sqlite, and so I am trying to build golang-modernc-sqlite using "fedpkg build". I received an error that I am not familiar with: 107041465 build (rawhide, /rpms/golang-modernc-sqlite.git:4e124a5404385a63af99570ce90cbaa7bdf4c722): open (buildvm-x86-08.iad2.fedoraproject.org) -> FAILED: BuildError: The following noarch package built differently on different architectures: golang-modernc-sqlite-devel-1.25.0-1.fc40.noarch.rpm rpmdiff output was: removed PROVIDES golang(modernc.org/sqlite/internal/libc2) = 1.25.0-1.fc40 removed PROVIDES golang(modernc.org/sqlite/internal/libc2)(tag=v1.25.0) = 1.25.0-1.fc40 removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2 removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/all_test.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_darwin_amd64.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_darwin_arm64.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_freebsd_amd64.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_freebsd_arm64.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_linux_386.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_linux_amd64.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_linux_arm.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_linux_arm64.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_linux_s390x.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_netbsd_amd64.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_windows_amd64.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/capi_windows_arm64.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/libc2_netbsd.go removed /usr/share/gocode/src/modernc.org/sqlite/internal/libc2/libc2_unix.go 0 free 1 open 4 done 1 failed 107041507 buildArch (golang-modernc-sqlite-1.25.0-1.fc40.src.rpm, ppc64le): open (buildvm-ppc64le-32.iad2.fedoraproject.org) -> closed 0 free 0 open 5 done 1 failed Does anyone know what might be causing this? I think I understand the concept behind the message, but I am not sure how the error arises. The package is another one of our source/-devel Go packages. -- Mike :wq

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang October 2023