golang June 2023

golang@lists.fedoraproject.org

8 participants
13 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] 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

[Pull Requests] gobuster and ffuf PRs awaiting merge
by Maverick Kaung 30 Jul '23

30 Jul '23

Hi folks, I have filed PRs for gobuster[0] and ffuf[1], and have been awaiting for someone in go-sig to merge them. I would appreciate it if someone could take a look and merge them. [0]: https://src.fedoraproject.org/rpms/gobuster/pull-request/5 [1]: https://src.fedoraproject.org/rpms/ffuf/pull-request/1 -Maverick

2 3

SIG opinion request - golang-github-migrate package
by Link Dupont 18 Jul '23

18 Jul '23

Hi go-sig, I have packaged up github.com/golang-migrate/migrate for Fedora. This project makes extensive use of build tags to include or exclude various databases and migration sources. Because of these build tags, I did not use the %go_generate_buildrequires macro. For my initial packaging of the project, I opted for a very minimal set of enabled databases and sources. * file (stdlib) * io/fs (stdlib) * sqlite3 (github.com/mattn/go-sqlite3) * postgres (github.com/lib/pq) The package review tree involves a couple of general package requirements: * golang-uber-atomic - https://bugzilla.redhat.com/2216829 * golang-github-hashicorp-multierror - https://bugzilla.redhat.com/2216817 As well as the dependent database packages: * golang-github-mattn-sqlite3 - https://bugzilla.redhat.com/2216821 Finally, the migrate package itself: * golang-github-migrate - https://bugzilla.redhat.com/2218606 I'd like interested members of the go-sig to take a look at the spec for migrate itself to see if the approach I took in organizing the dependencies is acceptable. Because this RPM might grow in complexity as new databases get packaged and added, I would like to get the SIG's opinions on this approach. ~link

3 4

INVESTMENT LOAN
by SANTOS＠fedoraproject.org 22 Jun '23

22 Jun '23

I am the Consultant Officer of a reputable Investment Company that specializes in raising capital for public or privately owned companies through business loans and investment funding. Currently we are sourcing for investment opportunities for our review and consideration and we provide financial and strategic advisory services to growing companies and entrepreneurs both private and institutional investors and I would be delighted to discuss further. I look forward to our further communication once I receive your response with your details (company profile/project). Regards. Chairman, Investment Group

1 0

azure-sdk-for-go goipath issue
by Mikel Olasagasti 21 Jun '23

21 Jun '23

Hello team, Newer version or rclone requires a newer release of azure-sdk-for-go, but azure-sdk-for-go has been divided into different modules, all living in a monorepo and thus requiring new packages. Each of the modules has its own release and I can create packages using version and tag: Version: 1.3.0 %global tag sdk/internal/v1.3.0 Each release contains the whole repo at that tag point. I can build a module by removing all unneeded modules/files and keeping only required files for the current module that is being packaged. The main problem is that all packages have the same goipath: %global goipath github.com/Azure/azure-sdk-for-go/ If I change the goipath to `github.com/Azure/azure-sdk-for-go/sdk/internal` for example, the resulting package is completely wrong as expected. I can keep `github.com/Azure/azure-sdk-for-go/` and use goaltipaths with `github.com/Azure/azure-sdk-for-go/sdk/internal`, but then all the packages would have `github.com/Azure/azure-sdk-for-go/` as their goipath and this causes conflicts (at least in my tests). Any idea of how this could be solved? Kind regards, Mikel

2 2

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

19 Jun '23

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang June 2023