July 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

[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

[go-rpm-macros] PR #48: Introduce %golang_arches_future and stop using %go_arches
by Maxwell G 07 Aug '22

07 Aug '22

gotmax23 opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Introduce %golang_arches_future and stop using %go_arches `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/48

2 6

cryptic build errors in syncthing with golang 1.19
by Fabio Valentini 29 Jul '22

29 Jul '22

Hi all, I've started to see very strange build failures of syncthing since the update from go 1.18 to 1.19: https://koschei.fedoraproject.org/package/syncthing?collection=f37 I've looked at build logs, but there's no obvious source of a problem that I can see in the usual "megabyte-sized wall of inscrutable build commands / output". Grepping for "error" does not help, the build just appears to "fail" at some point. Could somebody please take a look? I don't know what's going wrong. Thanks, Fabio

2 2

Please use and convert SPECs to SPDX
by Robert-André Mauchin 20 Jul '22

20 Jul '22

Hi, I'd like to recommend you to switch to SPDX for your license fields. Please intervene on any spec you create or edit. The license conversion should be disabled in go2rpm and then the rust2rpm dependencies should be dropped at a later date. Thank you. Robert-André

1 0

Re: Fedora Golang: SPEC and SRPM for ORAS (depends on itself?)
by Robert-André Mauchin 20 Jul '22

20 Jul '22

On 7/19/22 16:19, Mark E. Fuller wrote: > see https://copr.fedorainfracloud.org/coprs/fuller/test-builds/build/4642384/ > <https://copr.fedorainfracloud.org/coprs/fuller/test-builds/build/4642384/> > > Thanks > > Mark E. Fuller, Ph.D. > HaShikma 19, Apt. 24 > Nesher 3681219, Israel > +972 (0)53-872-6579 > mark.e.fuller(a)gmail.com <mailto:mark.e.fuller@gmail.com> > fuller(a)fedoraproject.org <mailto:fuller@fedoraproject.org> > @fuller:one.ems.host Ok, so the issue is, you don't have the correct default import path, you should check it in go.mod if you have a doubt, it starts with: > module oras.land/oras-go > > go 1.17 So you must use that import path when you create your SPEC: go2rpm -C -r oras.land/oras-go -f https://github.com/oras-project/oras-go You must specify the forge so the package can be downloaded correctly. Please note that the next version is a version 2 with a new import path: oras.land/oras-go/v2 You should then create a new package for this version specifically. But, the package still won't build because of Docker/Moby shenanigans: oras.land/oras-go/pkg/auth/docker # github.com/docker/docker/registry /usr/share/gocode/src/github.com/docker/docker/registry/auth.go:144:51: cannot use challengeManager (variable of type "github.com/docker/distribution/registry/client/auth/challenge".Manager) as type "github.com/distribution/distribution/v3/registry/client/auth/challenge".Manager in argument to auth.NewAuthorizer: "github.com/docker/distribution/registry/client/auth/challenge".Manager does not implement "github.com/distribution/distribution/v3/registry/client/auth/challenge".Manager (wrong type for GetChallenges method) have GetChallenges(endpoint url.URL) ([]"github.com/docker/distribution/registry/client/auth/challenge".Challenge, error) want GetChallenges(endpoint url.URL) ([]"github.com/distribution/distribution/v3/registry/client/auth/challenge".Challenge, error) FAIL oras.land/oras-go/pkg/auth/docker [build failed] Here the full list of Docker related dependencies according to go.mod: github.com/docker/cli v20.10.17+incompatible github.com/docker/distribution v2.7.1+incompatible github.com/docker/docker v20.10.17+incompatible github.com/docker/go-connections v0.4.0 I haven't checked Docker in a while. I think gotmax did a ticket on it for the next meeting. I'll have a look. Best regards, Robert-André

1 0

Golang Mass Rebuild
by Maxwell G 19 Jul '22

19 Jul '22

Hi Fedorians and Gophers, golang 1.18.4 was released a couple days ago. This release has fixes for 9 medium (rated by Red Hat Product Security) CVEs, so I will preform a rebuild in `rawhide` and `f36` to mitigate them[^0]. See https://groups.google.com/g/golang-dev/c/frczlF8OFQ0/m/4lrZh5BHDgAJ for more information about the specific vulnerabilities. [^0]: The golang version is Fedora 35 is EOL upstream, and the maintainers have not yet had a chance to backport the changes. Only packages that provide binaries need to be rebuilt, which will make this rebuild less disruptive. These packages were determined by querying for source packages that BuildRequire `golang` or `go-rpm-macros` and then checking if they provide any binary RPMS that install files in `/usr/bin`, `/usr/sbin`, or `/usr/libexec`. No action will be required from you, unless you'd like your package to receive special treatment regarding merging `rawhide` into `f36`. I plan to handle this rebuild later this week (the week of the 17th). In light of the recent discussion about large updates, I will most likely split this into 4 Bodhi updates per branch (a total of 8; each containing ~100 packages). ## rawhide Here[1] is a list of the affected packages on `rawhide`. [1]: https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/rebuilds/golang_1… ## f36 Here[2] is a list of all of the affected packages on `f36`. However, I have further split this list down into two subgroups. [2]: https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/rebuilds/golang_1… ### Mergable from Rawhide For these packages[3], `rawhide` was determined to be mergable back to `f36`, as `f36` is up to date with `rawhide`. [3]: https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/rebuilds/golang_1… ### Not mergable These packages were determined to not be mergable[4], as `rawhide` is ahead of (or has otherwise diverged from) `f36`. Therefore, I will create a new rebuild commit and bump the release on `f36`. This will likely cause merge conflicts if you try to merge `rawhide` back into `f36` after this change. Assuming the update would be compatible and comply with the Updates Policy, I can move your package into the other list and merge `rawhide` into `f36`. Please leave a comment on https://pagure.io/GoSIG/go-sig/issue/44 if you would like me to do so. Conversely, if you believe your package is incorrectly in the mergable list, also let me know in the aforementioned ticket. [4]: https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/rebuilds/golang_1… -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

2 3

Re: helm rpm package
by Maxwell G 19 Jul '22

19 Jul '22

Jul 19, 2022 9:56:02 AM Davide Cavalca <dcavalca(a)fb.com>: > The latest version of helm picked up a dependency > on oras.land/oras-go. That library isn't currently packaged, and fails > in %check on a docker-related test due to a conflict between > docker/distribution and distribution/v3. Does it work if you add # Use new docker/distribution import path sed \ -e 's|github.com/docker/distribution|github.com/distribution/distribution/v3|' \ -i $(find . -name '*.go') in %prep and use dynamic buildrequires? -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

1 0

Re: helm rpm package
by Maxwell G 19 Jul '22

19 Jul '22

Hi Ali, On 22/07/19 02:37PM, Ali Yousefi Sabzevar wrote: > I saw that those bugs were related to golang-helm-3 package, so maybe not > directly related to the helm3 rpm package. helm is a subpackage of the golang-helm-3 source package. These bugs are very much related to helm. > > I checked on > https://packages.fedoraproject.org/pkgs/golang-helm-3/helm/ that the > maintainer is *dcavalca*, but an email to dcavalca(a)redhat.com failed > to deliver. That is not the correct way to reach out to a maintainer. Not everyone who works on Fedora is a Red Hat employee. USERNAME(a)fedoraproject.org is an alias to whatever the user's actual email is. You can look in the package %changelog or on accounts.fedoraproject.org for a user's email, as well. This email also should've reached Davide directly. > > Anyway, if you see the helm3 package is orphaned and has no active > maintainer, I will pick it up as a maintainer and make an up to date rpm > package out of it. The package is not orphaned. The maintainer just hasn't updated it in a little while. I'm sure they would appreciate a PR. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

1 0

Fedora 38 Change: Exclude golang from x86_32 (system wide change).
by Stephen Smoogen 19 Jul '22

19 Jul '22

There is a lot of work needed to keep golang libraries working in Fedora, and in order to cut down extra items that are taking time and debugging, the golang SIG would like to remove x86_32 from i686 starting in Fedora 38. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren

2 2

Re: helm rpm package
by Alejandro Saez Morollon 19 Jul '22

19 Jul '22

Not quite sure but there are a bunch of bugs open and it is marked as FTBFS. https://bugzilla.redhat.com/show_bug.cgi?id=2097975 https://bugzilla.redhat.com/show_bug.cgi?id=2067435 https://bugzilla.redhat.com/show_bug.cgi?id=2045644 https://bugzilla.redhat.com/show_bug.cgi?id=1977738 https://bugzilla.redhat.com/show_bug.cgi?id=1971091 https://bugzilla.redhat.com/show_bug.cgi?id=1971029 I cc'ed the Go SIG mailing list for awareness just in case someone knows anything about it. On Mon, Jul 18, 2022 at 9:30 PM Ali Yousefi Sabzevar <aysabzevar(a)gmail.com> wrote: > Hello, > > This is Ali. A long time Fedora user (with some contributions). > > I was about to update helm documentations to include installing helm via > dnf/yum and I noticed that helm rpm is too old (3.5.4-fc35) . > > I am wondering why we cannot/haven't updated the helm rpm package on the > fedora repo and are still using a 1-year-old package?! > > > Regards, > Ali >

1 0

Subject: F38 change retire all FTBFS golang libraries and resulting dependencies (system-wide change)
by Stephen Smoogen 18 Jul '22

18 Jul '22

The subject is a strawman proposal and goes from what was discussed from today's meeting. There are a lot of golan packages which are FTBFS and not a lot of people helping to fix. My original over-the-top subject was 'Retire golang' but since the compiler works, that is overkill. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren

1 0

Golang F35 Mini Mass Rebuild
by Maxwell G 12 Jul '22

12 Jul '22

Hi Fedorians and Gophers, Later this week, I will be a doing a mass rebuild in F35 for all packages that require `golang` and provide binaries to mitigate the following CVEs: `golang` (affects all go binaries): - CVE-2022-24675 golang: encoding/pem: fix stack overflow in Decode - CVE-2022-28327 golang: crypto/elliptic: panic caused by oversized scalar - CVE-2022-29526 golang: syscall: faccessat checks wrong group (There are some Go CVEs that are a little bit older that will also be mitigated by the rebuild for packages that haven't been updated recently) CVEs in other golang libraries that affect a subset of Go packages: - CVE-2022-21698 golang-github-prometheus-client: prometheus/client_golang: Denial of service using InstrumentHandlerCounter - CVE-2022-1996 go-restful: Authorization Bypass Through User-Controlled Key Only packages that provide binaries need to be rebuilt, which will make this rebuild less disruptive. Also, note that if your package uses vendored dependencies that are affected by the latter two CVEs and haven't been patched, you will need to handle this manually by querying upstream to update their vendored dependencies (if the bundling is done upstream) and/or fix it yourself. Thankfully, the packages don't need rebuilt in a specific order (besides golang being first) due to the nature of go, so this will be less complicated than, for example, the Python rebuilds. No action will be required from you, unless your package is affected by the aforementioned bundled dep issue, you'd like your package to receive special treatment, or if the go-sig doesn't have permissions on your package (see below). I have made a list of affected packages here[1]. I didn't want to paste it into this email, as it's pretty long. The list is split into 2 categories: ## go-sig packages ### mergable from Rawhide For these packages, `rawhide` was determined to be mergable back to `f35`, as they were up to date excluding the rebuild commit from when we rebuilt `rawhide` a week or two ago. ### Not mergable These packages were determined to not be mergable, as `rawhide` is ahead of (or otherwise has diverged from) `f35`. Therefore, I will create a new rebuild commit on `f35`. This will likely cause merge conflicts if you try to merge `rawhide` back into `f35` after this change. Assuming the update would be compatible and comply with the Updates Policy, I can move your package into the other list and merge `rawhide` into `f35`. Please leave a comment on https://pagure.io/GoSIG/go-sig/issue/41 if you would like me to do so. Conversely, if you believe your package is incorrectly in `### mergeable`, also let me know in the aforementioned ticket. ## non-go-sig packages Neither I personally nor the go-sig has access to these packages, so I will query a provenpackager to handle these. To the maintainers of these packages: You really should really add go-sig to your package. Not having the appropriate permissions delays us from mitigating CVEs in your package and generally prevents us from effectively maintaining the Go stack. @fale has already sent two reminders. Please see https://lists.fedoraproject.org/ archives/list/devel(a)lists.fedoraproject.org/message/ A4NEHUW52ELDHDMPQDCBSRJXHDPJK2QX/ for more information. For the benefit of the provenpackager who will handle this, I have compiled the same mergable and not mergable lists. Thank you for your cooperation. I understand that this is a bit disruptive for a stable release, but we don't have much of a choice. [1]: https://pad.snopyta.org/BiFivroxQdqEZsW_tach8A -- Maxwell G (@gotmax23) Pronouns: He/Him/His

1 1

Proposal: remove %ix86 from golang_arches for F37
by Robert-André Mauchin 05 Jul '22

05 Jul '22

Hi, So the change deadline is very soon, so I'd like a quick answer on this. So Fedora is dropping i686 in the near future, only plsnning to support Wine related thingie as far as I know. Could we too make a move toward this by dropping %ix86 from our supported arches? Most Go dev don't bother to do check build on 32 bits platforms and thus we find out many bugs when building on these arches. arm32 was dropped, now we only have i686 as the remaining 32 bits arch, removing it would reduce the time spent on bugs and failed builds. What's your take on it Go Folks? Please answer relaively quickly as we don't have much time before changes deadline. Best regards, Robert-André

5 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang July 2022