April 2022 - golang - Fedora Mailing-Lists

by Matyáš Kroupa

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 months, 1 week

3
3
0 / 0

[go-rpm-macros] PR #34: Add BUILDTAGS to %gobuildflags

by Brian C. Lane

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

3 months, 1 week

7
19
0 / 0

[golist] PR #29: Deduplicate CollectProjectDeps

by Matyáš Kroupa

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

3 months, 1 week

2
1
0 / 0

[go-rpm-macros] PR #45: srpm/go.lua meta: Set `%gourl` after `forge.meta` call

by Maxwell G

gotmax23 opened a new pull-request against the project: `go-rpm-macros` that you are following: `` srpm/go.lua meta: Set `%gourl` after `forge.meta` call `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/45

11 months, 2 weeks

2
1
0 / 0

[go-rpm-macros] Issue #36: Renaming BUILDTAGS and LDFLAGS to include GO prefixes

by Link Dupont

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

11 months, 2 weeks

3
4
0 / 0

[golist] Issue #28: golist fails when new go-1.17 `//go:build` style is used

by Mikel Olasagasti

mikelo2 reported a new issue against the project: `golist` that you are following: `` golist fails when golang-1.17 new `//go:build` style is used: ``` $ go2rpm https://github.com/google/log4jscanner //go:build comment without // +build comment Traceback (most recent call last): File "/usr/bin/go2rpm", line 8, in <module> sys.exit(main()) File "/usr/lib/python3.10/site-packages/go2rpm/__main__.py", line 598, in main buildrequires = to_list(get_buildrequires(forge, subdir)) File "/usr/lib/python3.10/site-packages/go2rpm/__main__.py", line 442, in get_buildrequires buildrequires = subprocess.check_output( File "/usr/lib64/python3.10/subprocess.py", line 420, in check_output return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, File "/usr/lib64/python3.10/subprocess.py", line 524, in run raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command '['golist', '--imported', '--skip-self', '--package-path', 'github.com/google/log4jscanner']' returned non-zero exit status 1. ``` From go-1.17 release notes: ` The go command now understands //go:build lines and prefers them over // +build lines. The new syntax uses boolean expressions, just like Go, and should be less error-prone. As of this release, the new syntax is fully supported, and all Go files should be updated to have both forms with the same meaning. To aid in migration, gofmt now automatically synchronizes the two forms. For more details on the syntax and migration plan, see https://golang.org/design/draft-gobuild. ` `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/28

12 months

1
4
0 / 0

[Fedocal] Reminder meeting : Go SIG

by jcajka＠fedoraproject.org

Dear all, You are kindly invited to the meeting: Go SIG on 2022-04-25 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 year, 1 month

1
0
0 / 0

CVE-2022-27191 tickets

by Mikel Olasagasti

Hi all, CVE-2022-27191 was published recently for golang-x-crypto and a BZ ticket[2] has been opened for every package that depends on it. It has a 7.5 score for CVSS 3.x. FWIU, in order to fix this CVE, a new version of golang-x-crypto and rebuilding all dependent packages is required. I opened a PR[3] to update golang-x-crypto as the first step. As I'm still not part of go-sig, can someone review, merge if OK and build it for current Fedora releases? I applied today to be a member of go-sig[4] to help with this and other tasks, but don't know how long it will take to be accepted. Kind regards, Mikel Olasagasti (mikelo2) [1] https://nvd.nist.gov/vuln/detail/CVE-2022-27191 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2064702 [3] https://src.fedoraproject.org/rpms/golang-x-crypto/pull-request/2 [4] https://pagure.io/GoSIG/go-sig/issue/1#comment-792166

1 year, 1 month

3
5
0 / 0

go-sig permissions

by Fabio Alessandro Locati

Hi everyone, Trying to work out a way to do the x/crypto rebuild in a way that is as little painful as possible, I've went back to some scripts I was playing with few weeks ago, and I've decided to write this email. Counting only non-orphan packages, and package whose name start with `golang-`, we have more that 250 packages on which @go-sig have no permission whats so ever. This means that, at the end of the day, for big rebuilds events we will still need provenpackagers, which is not optimal in my opinion. Do we have a clear rule around the @go-sig permissions assignation? If so, where can I find it? If not, would it make sense to have such a rule? What can we do to ensure that go-sig have appropriate permissions on all golang packages? I'm willing to write the code to create the list of packages with wrong permissions (and potentially to fix them), but I guess we will need a clear rule and and an agreed processes before we can run such script. What's your take on this? Thanks a lot, Fale -- Fabio Alessandro Locati fale.io

1 year, 1 month

1
0
0 / 0

[Fedocal] Reminder meeting : Go SIG

by jcajka＠fedoraproject.org

Dear all, You are kindly invited to the meeting: Go SIG on 2022-04-11 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 year, 1 month

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang April 2022