June 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

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

Delve debugger
by Mark E. Fuller 29 Jun '22

29 Jun '22

The delve debugger for go was orphaned a few years ago in Fedora (https://src.fedoraproject.org/rpms/delve) Is there anyone who would be interested in helping to get it back? I've generated a spec file and taken care of the necessary new dependency (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2098379) but it doesn't build (yet): "_build/src/github.com/go-delve/delve/pkg/terminal/terminal.go:104:9: t.line.SetCtrlZStop undefined (type *liner.State has no field or method SetCtrlZStop)" I haven't had time to dig into this yet; For anyone interested, I have opened a package review despite it not being fully ready. Thanks, -- Mark E. Fuller, Ph.D. fuller(a)fedoraproject.org fuller(a)mefuller.dev @fuller:fedora.im @fuller:one.ems.host https://www.stossrohr.net PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60

4 8

packaging: -x and -v make it difficult to diagnose build failures
by W. Michael Petullo 28 Jun '22

28 Jun '22

I maintain a number of Go packages for Fedora, including Hugo. I find that the default use of -x and -v when running "go build" makes it difficult to diagnose compile problems. A compile error does not necessarily terminate the Go build process, and with -x and -v the error message is quickly lost in the volume of output from go build. I have figured out how to run "go build" in mock without the -x and -v flags, but I sometimes have to diagnose the build log from the Fedora build server, and this is very difficult due to the volume of output. For an example of this, see: https://kojipkgs.fedoraproject.org//work/tasks/3319/88593319/build.log I would rather not redefine the default "go build" flags for my packages. Has there been any thought put into dropping -x and -v? Does anyone else have trouble with this? Does anyone benefit from the use of -x and -v? Am I missing an obvious trick? -- Mike :wq

4 3

[go-rpm-macros] PR #45: srpm/go.lua meta: Set `%gourl` after `forge.meta` call
by Maxwell G 20 Jun '22

20 Jun '22

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

2 1

Spring Cleaning go-sig/June 2022
by Fabio Alessandro Locati 19 Jun '22

19 Jun '22

Hello Golang packagers, As it happened last month, we are trying to clean the situation with golang packages. In the last month we have seen big improvements (265 ->131 packages in the list), and I really hope next month we will be able to claim such a great result again! At the moment I've gathered all packages that depend on golang and the privilege that @go-sig has on them. I would ask of all of you to make sure all your packages have been added to the @go-sig group on src.fedoraproject.org (at least with "commit" access), unless there is a very good reason not to do so (and if that is the case for a particular package on this list, I'd be interested in knowing the reason). Without that, it makes it very hard for us to keep the Go stack up-to-date and in working order, because the "go-sig" list / bugzilla account does not get CC'd on new bugs that way, and your bugs do not show up in our BugZilla queries. If you want a scripted way of adding "@go-sig" group to many packages, you can generate an API token on src.fedoraproject.org (with "Modify an existing project") access level, and use the simple Python script from this link: https://fale.fedorapeople.org/add-go-sig.py Below is the list of "incompletely set-up" packages, in alphabetic order, and at the bottom, is a list per package maintainer. Thanks, Fale ================================================================================ Maintainers per package: - android-tools: van - apptainer: dwd - asciigraph: mhayden - buildah: lsm5 - butane: bgilbert - ceph: kkeithle - cheat: tkorbar - clipman: wef - containernetworking-plugins: mheon - cri-o: haircommander - deepin-api: mosquito - deepin-daemon: mosquito - deepin-desktop-schemas: mosquito - deepin-gir-generator: mosquito - deepin-pw-check: cheeselee - docker-distribution: cverna - git-octopus: baitaand - go-bindata: lsm5 - godep: jchaloup - golang: jcajka - golang-deepin-go-lib: mosquito - golang-entgo-ent: salimma - golang-github-acobaugh-osrelease: harrymichal - golang-github-anaskhan96-soup: atim - golang-github-apparentlymart-cidr: pwouters - golang-github-apparentlymart-textseg-13: limb - golang-github-bits-and-blooms-bitset: dcavalca - golang-github-client9-gospell: mayorga - golang-github-cli-gh: mikelo2 - golang-github-cli-shurcool-graphql: jdoss - golang-github-coreos-semver: limb - golang-github-elves-elvish: appadeia - golang-github-enescakir-emoji: jdoss - golang-github-facebook-time: abulimov - golang-github-gizak-termui: atim - golang-github-gocomply-scap: isimluk - golang-github-googlecloudplatform-guest-logging: ericedens - golang-github-google-dap: alexsaezm - golang-github-google-gousb: jjelen - golang-github-gosexy-gettext: zyga - golang-github-hajimehoshi-mp3: atim - golang-github-hajimehoshi-oto: atim - golang-github-harrymichal-version: harrymichal - golang-github-heistp-irtt: tohojo - golang-github-hinshun-vt10x: jdoss - golang-github-hub: jaymzh - golang-github-hugelgupf-socketpair: dcavalca - golang-github-ianbruene-difflib: dfateyev - golang-github-jroimartin-gocui: atim - golang-github-kalafut-imohash: dcavalca - golang-github-kelvins-sunrisesunset: cheeselee - golang-github-letsencrypt-challtestsrv: pwouters - golang-github-letsencrypt-pebble: pwouters - golang-github-linuxdeepin-dbus-factory: mosquito - golang-github-linuxdeepin-go-x11-client: mosquito - golang-github-lithammer-fuzzysearch: atim - golang-github-lofanmi-pinyin: cheeselee - golang-github-lpabon-godbc: lpabon - golang-github-lunixbochs-vtclean: atim - golang-github-mbland-hmacauth: pwouters - golang-github-mbndr-figlet4go: atim - golang-github-mingrammer-commonregex: athoscr - golang-github-mitchellh-ps: szeth - golang-github-mozillazg-pinyin: cheeselee - golang-github-msprev-fzf-bibtex: dmoerner - golang-github-muesli-reflow: jdoss - golang-github-muesli-termenv: jdoss - golang-github-mvo5-goconfigparser: zyga - golang-github-netflix-expect: jdoss - golang-github-openprinting-goipp: zdohnal - golang-github-openprinting-ipp-usb: zdohnal - golang-github-pkg-browser: thomasfedb - golang-github-projectdiscovery-cdncheck: fab - golang-github-projectdiscovery-sliceutil: mikelo2 - golang-github-remeh-sizedwaitgroup: mayorga - golang-github-rickb777-date: cheeselee - golang-github-rickb777-plural: cheeselee - golang-github-rivo-uniseg: jdoss - golang-github-rubyist-tracerx: clime - golang-github-schollz-cli-2: dcavalca - golang-github-schollz-croc: dcavalca - golang-github-schollz-logger: dcavalca - golang-github-schollz-mnemonicode: dcavalca - golang-github-schollz-pake-3: dcavalca - golang-github-schollz-peerdiscovery: dcavalca - golang-github-segmentio-ksuid: gundersanne - golang-github-sqshq-sampler: atim - golang-github-teambition-rrule: cheeselee - golang-github-termie-shutil: dfateyev - golang-github-tomnomnom-xtermcolor: atim - golang-github-tscholl2-siec: dcavalca - golang-github-xiaq-persistent: appadeia - golang-github-xrash-smetrics: mayorga - golang-github-zyedidia-highlight: atim - golang-gitlab-esr-fqme: dfateyev - golang-gitlab-ianbruene-kommandant: dfateyev - golang-nanomsg-mangos-3: fab - golang-rsc-pdf: deparker - golang-starlark: alexsaezm - golie: isimluk - gomtree: vbatts - google-guest-agent: ericedens - gotun: kushal - grafana: agerstmayr - grafana-pcp: agerstmayr - graphviz: jskarvad - gron: lkiesow - ignition: dustymabe - kata-containers: etrunko - kompose: dustymabe - manifest-tool: jwboyer - oci-seccomp-bpf-hook: jnovy - origin: jcajka - osbuild-composer: obudai - pack: lsm5 - podman: mheon - podman-tui: navidys - popub: zsun - reg: mattia - reposurgeon: dfateyev - restic: copart - runc: kir - singularity: dwd - skopeo: lsm5 - stargz-snapshotter: ktock - startdde: mosquito - swig: jplesnik - tmux-top: ttomecek - toolbox: rishi - vultr-cli: mhayden - xe-guest-utilities-latest: cheeselee Packages per maintainer: abulimov (1): golang-github-facebook-time agerstmayr (2): grafana, grafana-pcp alexsaezm (2): golang-github-google-dap, golang-starlark appadeia (2): golang-github-elves-elvish, golang-github-xiaq-persistent athoscr (1): golang-github-mingrammer-commonregex atim (11): golang-github-anaskhan96-soup, golang-github-gizak-termui, golang-github-hajimehoshi-mp3, golang-github-hajimehoshi-oto, golang-github-jroimartin-gocui, golang-github-lithammer-fuzzysearch, golang-github-lunixbochs-vtclean, golang-github-mbndr-figlet4go, golang-github-sqshq-sampler, golang-github-tomnomnom-xtermcolor, golang-github-zyedidia-highlight baitaand (1): git-octopus bgilbert (1): butane cheeselee (8): deepin-pw-check, golang-github-kelvins-sunrisesunset, golang-github-lofanmi-pinyin, golang-github-mozillazg-pinyin, golang-github-rickb777-date, golang-github-rickb777-plural, golang-github-teambition-rrule, xe-guest-utilities-latest clime (1): golang-github-rubyist-tracerx copart (1): restic cverna (1): docker-distribution dcavalca (10): golang-github-bits-and-blooms-bitset, golang-github-hugelgupf-socketpair, golang-github-kalafut-imohash, golang-github-schollz-cli-2, golang-github-schollz-croc, golang-github-schollz-logger, golang-github-schollz-mnemonicode, golang-github-schollz-pake-3, golang-github-schollz-peerdiscovery, golang-github-tscholl2-siec deparker (1): golang-rsc-pdf dfateyev (5): golang-github-ianbruene-difflib, golang-github-termie-shutil, golang-gitlab-esr-fqme, golang-gitlab-ianbruene-kommandant, reposurgeon dmoerner (1): golang-github-msprev-fzf-bibtex dustymabe (2): ignition, kompose dwd (2): apptainer, singularity ericedens (2): golang-github-googlecloudplatform-guest-logging, google-guest-agent etrunko (1): kata-containers fab (2): golang-github-projectdiscovery-cdncheck, golang-nanomsg-mangos-3 gundersanne (1): golang-github-segmentio-ksuid haircommander (1): cri-o harrymichal (2): golang-github-acobaugh-osrelease, golang-github-harrymichal-version isimluk (2): golang-github-gocomply-scap, golie jaymzh (1): golang-github-hub jcajka (2): golang, origin jchaloup (1): godep jdoss (7): golang-github-cli-shurcool-graphql, golang-github-enescakir-emoji, golang-github-hinshun-vt10x, golang-github-muesli-reflow, golang-github-muesli-termenv, golang-github-netflix-expect, golang-github-rivo-uniseg jjelen (1): golang-github-google-gousb jnovy (1): oci-seccomp-bpf-hook jplesnik (1): swig jskarvad (1): graphviz jwboyer (1): manifest-tool kir (1): runc kkeithle (1): ceph ktock (1): stargz-snapshotter kushal (1): gotun limb (2): golang-github-apparentlymart-textseg-13, golang-github-coreos-semver lkiesow (1): gron lpabon (1): golang-github-lpabon-godbc lsm5 (4): buildah, go-bindata, pack, skopeo mattia (1): reg mayorga (3): golang-github-client9-gospell, golang-github-remeh-sizedwaitgroup, golang-github-xrash-smetrics mhayden (2): asciigraph, vultr-cli mheon (2): containernetworking-plugins, podman mikelo2 (2): golang-github-cli-gh, golang-github-projectdiscovery-sliceutil mosquito (8): deepin-api, deepin-daemon, deepin-desktop-schemas, deepin-gir-generator, golang-deepin-go-lib, golang-github-linuxdeepin-dbus-factory, golang-github-linuxdeepin-go-x11-client, startdde navidys (1): podman-tui obudai (1): osbuild-composer pwouters (4): golang-github-apparentlymart-cidr, golang-github-letsencrypt-challtestsrv, golang-github-letsencrypt-pebble, golang-github-mbland-hmacauth rishi (1): toolbox salimma (1): golang-entgo-ent szeth (1): golang-github-mitchellh-ps thomasfedb (1): golang-github-pkg-browser tkorbar (1): cheat tohojo (1): golang-github-heistp-irtt ttomecek (1): tmux-top van (1): android-tools vbatts (1): gomtree wef (1): clipman zdohnal (2): golang-github-openprinting-goipp, golang-github-openprinting-ipp-usb zsun (1): popub zyga (2): golang-github-gosexy-gettext, golang-github-mvo5-goconfigparser -- Fabio Alessandro Locati fale.io

2 1

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

19 Jun '22

Dear all, You are kindly invited to the meeting: Go SIG on 2022-06-20 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: Golang
by Alejandro Saez Morollon 17 Jun '22

17 Jun '22

On Fri, Jun 17, 2022 at 7:03 AM Miroslav Suchý <msuchy(a)redhat.com> wrote: > > I have been asked to add support for Go external dependencies to Mock > > https://github.com/rpm-software-management/mock/issues/919 > > I tried to get the information from > > https://developer.fedoraproject.org/tech/languages/go/go-packages.html > > However, the information there seems to be outdated. "go get" is deprecated. And even "go install" with the example > there does not work. > > Is here a hero, who will edit the page on developer portal and update it? > Not a hero but I can look into it :). Already subscribed to the github issue too. cc @golang@lists.fedoraproject.org > Miroslav > _______________________________________________ > 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 on the list, report it: https://pagure.io/fedora-infrastructure

1 0

Re: Fedora "golang-x-sys" package scratch-build errors
by Maxwell G 13 Jun '22

13 Jun '22

On Sunday, June 12, 2022 1:52:54 PM CDT Denis Fateyev wrote: > Hello, > > I'm playing with "golang-x-sys" package in Fedora [1], testing it and > rebuilding locally and in Koji (scratch builds). > > I've got confused with one thing: looking at the latest F36 update [2] — > the package build / update was successful. But, grabbing the SRPM from > there and scratch-building it with Koji under F36 and EPEL9, I got errors: > [3], [4]. > > - For EPEL9: build failed due "noarch" package differences under several > platforms; > - For F36: build failed due to issues with "s390x" architecture. > > Did I miss anything to build this package in these branches properly? > > I've requested to push "golang-x-sys" to EPEL9 [5], so interested in any > possible build peculiarities there. If you have any information, please let > me know. > Thanks! > > > [1] https://src.fedoraproject.org/rpms/golang-x-sys > > [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1976849 > > [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=88189716 > > [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=88189719 > > [5] https://bugzilla.redhat.com/show_bug.cgi?id=2095050 Hi Denis, Fyi, I'm not the primary of this package (@eclipseo is), but I occasionally help out with its maintenance as a member of the go-sig. That being said, I'm happy to help to the best of my ability :). I was not able to reproduce the F36 s390x failure, either yesterday or when I initially built the package. That may have been a transient infra issue. I'm a bit stumped regarding the EPEL 9 issue. go-rpm-macros is actually part of RHEL 9 and is not maintained by us. The RHEL maintainers made some minor changes to the go-rpm-macros package from Fedora. I wonder if those could be the culprit. [/me thinks some more and has an idea...] I tested two builds of golang-x-sys on epel9-next: one with the version of go-rpm-macros present in c9s and another one built against Rawhide's go-rpm-macros and golist (the rest of the packages were the standard CentOS Stream/EPEL 9 packages). I was able to use go-rpm-macros and golist that were built on Koji for Rawhide on c9s, because go-rpm-macros doesn't have any compiled code and golist is statically linked. This points to some issue with EL 9's go-rpm-macros package. In the first build, the -devel package had different contents on different architectures, while it didn't in the second build. I've CC'd the golang mailing list and the go-rpm-macros maintainer to see if they have any input. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

1 0

Re: Intent to retire containerd in EPEL 7 and co-maintainer request
by Maxwell G 12 Jun '22

12 Jun '22

On Thursday, June 9, 2022 5:55:34 PM CDT Stewart Smith wrote: > Unfortunately I don't think we can [help with EPEL 7] given the > likely packaging differences I'd be surprised if there's major differences, unless AL 2 backports newer go macros. > the containerd version differences containerd in EPEL 7 actually *needs to* be updated to fix the CVEs. That would be one of the first jobs of the theoretical new EPEL 7 maintainer. > that we don't have infinite time and given a choice between EPEL7 work > and jumping into modern Fedora packaging to enhance both Fedora and our > Amazon Linux 2022 efforts, I'd pick the latter. As I said, that would also be appreciated. >> Additionally, I would appreciate co-maintainers to help with the Fedora >> branches of containerd, its unbundled go dependencies, and moby-engine >> (bundled go package). Long term, I'm not sure I'll have the time or the >> interest to maintain these packages. Note that on EPEL 7, containerd >> bundles its dependencies; moby-engine is not packaged there. > > This is 100% somewhere that Amazon Linux can step in and help with. We > have a continued interest in the containerd ecosystem working in Fedora > like distros (namely Amazon Linux), and the bundled/not-bundled split > existing in some working bconds is certainly in our interest (we're > likely to continue to bundle dependencies for the forseeable future). Currently, moby-engine (equivalent to docker-ce) already uses bundled dependencies. containerd on Fedora uses unbundled dependencies, which does create more work, but doing so is recommended by our packaging guidelines where it's feasible. It shouldn't be too difficult/messy to add bundling bconds, as long as we stick to the version of go-rpm-macros in Fedora and EL 9. It starts getting messier (repeated code and lots of conditionals) when you maintain unbundled Fedora and EPEL 7-8 compatibility in the same specfile. On a related note, I recently learned that it's possible to include snippets from other files in specfiles using the %include macro. This way, you can easily create a script to update virtual provides for bundled go packages without having to copy/paste text into the specfile. This also keeps your specfile cleaner. If anyone is interested, feel free to look at moby-engine for an example. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

1 0

Intent to retire containerd in EPEL 7 and co-maintainer request
by Maxwell G 08 Jun '22

08 Jun '22

Hi everyone, I have been de-facto maintaining containerd in Fedora as a member of the go- sig for a little while now, as the previous maintainer no longer has time to do. In addition to the Fedora branches, this package also exists on EPEL 7. That branch has not been maintained for a while and has unpatched CVEs. I am not interested in maintaining it myself, so unless someone steps up to maintain it and fix the vulnerabilities, I will retire the package from EPEL 7 in a week from today, on June 15th. Additionally, I would appreciate co-maintainers to help with the Fedora branches of containerd, its unbundled go dependencies, and moby-engine (bundled go package). Long term, I'm not sure I'll have the time or the interest to maintain these packages. Note that on EPEL 7, containerd bundles its dependencies; moby-engine is not packaged there. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His

1 0

[golist] Issue #28: golist fails when new go-1.17 `//go:build` style is used
by Mikel Olasagasti 07 Jun '22

07 Jun '22

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

1 4

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

05 Jun '22

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

Help with go spec file
by Mark E. Fuller 03 Jun '22

03 Jun '22

Hi all, I'm fairly new to go and am looking to make a spec file and build jsonnet (https://github.com/google/go-jsonnet/, https://jsonnet.org/) The go2rpm utility has proven very helpful, but there appear to be two irregularities with building this package that I don't know offhand how to address (including from reading https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/) 1) What is the preferred way to ignore (or remove) unnecessary BUILD.bazel files? There is one in cmd/ which is obviously not a buildable command, and so this results in an error in the naive use case. 2) How should nested folders in cmd/ be built? Here, again, the basic template throws an error since cmd/internal contains no *.go files, only a BUILD.bezel file and a nested cmd directory. Thank you all, fuller -- Mark E. Fuller, Ph.D. fuller(a)fedoraproject.org fuller(a)stossrohr.net @fuller:one.ems.host https://www.stossrohr.net PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang June 2022