[go-rpm-macros] Issue #2: EPEL availability
by Nicolas Mailhot
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
3 weeks, 6 days
[go-rpm-macros] Issue #3: %goprep should apply patches automatically
by Nicolas Mailhot
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
3 weeks, 6 days
[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
3 weeks, 6 days
[go-rpm-macros] Issue #46: %gobuildflags missing double quotation marks
by Petr Hruska
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/359d80bbfe7f0490fc51c43af8d986863516c5b... 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
3 weeks, 6 days
Go leaves will be mass retired in one month
by Maxwell G
(Resending as it seems this didn't reach the ML the first time...)
Hi Fedorians,
Changes/Mass_Retire_Golang_Leaves [1] has been approved by FESCo. As
part of this Change, all Go library packages that are leaves will be be
mass retired and removed from the Fedora 39 repositories in
approximately one month.
The following maintainers/groups own co-maintain or watch at least one
package that we have identified as a leaf:
@deepinde-sig
@go-sig
@osbuild-sig
agerstmayr
anthr76
athoscr
atim
carlwgeorge
dcavalca
dctrud
eclipseo
fab
fale
fuller
gundersanne
jchaloup
jdoss
jjelen
laiot
logic
mayorga
mgoodwin
nathans
obudai
pwouters
qulogic
rga
rominf
yanqiyu
I will forward this message to those users separately instead of BCCing.
Apparently, some people have broken filters that hide any email sent to
the ML even if it's addressed to them directly.
See [2] for a full list of leaves and [3] for a maintainer by maintainer
breakdown. Maintainers may opt out by cloning
https://pagure.io/GoSIG/go-leaves/ and pushing an `opt-out/{PKGNAME}`
file with a short justification.
Something like:
```
git clone ssh://git@pagure.io/GoSIG/go-leaves.git
cd go-leaves
echo "Dependency for foo (review bug #XXXXX)" > ./opt-out/bar
git add ./opt-out/bar
git commit -m "opt out bar"
git push origin
```
All Go SIG members have write access to this repository. Other users can
submit a pull request. You're also welcome to file an issue and I'll
push the file for you.
After a month has passed, we'll remove Go SIG write access from the
repository and stop accepting additional opt-outs. Then, we'll preform
test builds in Copr to make sure there's no false positives in the list.
Finally, I'll verify the results, opt out any additional false
positives, and preform the mass retirement. As usual, anybody can
unretire packages without a re-review within eight weeks by filing a
releng ticket.
[1] https://fedoraproject.org/wiki/Changes/Mass_Retire_Golang_Leaves
[2] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves
[3] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves-by-maintainer
Thank you for your cooperation,
--
Maxwell G (@gotmax23)
Pronouns: He/They
1 year, 1 month
Using %gobuildflags with %meson
by Link Dupont
I have a package[1] that I'm updating to a new upstream version. Upstream, the project uses meson to compile the binaries (written in Go), as well as generate and install a number of data files. I want to use meson to compile and install the project downstream because I feel meson does a good job managing all the data files and installation directories.
I am trying to replicate the logic of the %gobuild macro so that I can continue to use meson *and* use as much of the go-rpm-macros as possible, with as little duplication as possible. Upstream, I have defined custom_targets[3] for the Go binaries with the following command array:
> [go, 'build', gobuildflags, '-o', '@OUTPUT@', '-ldflags', goldflags, packagename]
gobuildflags is an array that is constructed[4] from a meson build option[3].
In my spec %build, I attempt to set the gobuildflags meson build option like so:
> %meson -Dgobuildflags=%{shescape:%gobuildflags}
When meson parses the incoming gobuildflags value and splits the string into an array, it separates the value of the -tags flag into two separate single-quoted command line arguments like this (extracted from the resulting ninja.build):
> COMMAND = /usr/bin/go build -buildmode pie -compiler gc '-tags="rpm_crashtraceback' '$${BUILDTAGS:-}"' ...
Is there some other way I can pass the output of %gobuildflags into meson as a build option that doesn't split apart the double-quoted values like this?
1: https://src.fedoraproject.org/rpms/yggdrasil
2: https://github.com/RedHatInsights/yggdrasil/blob/main/cmd/yggd/meson.buil...
3: https://github.com/RedHatInsights/yggdrasil/blob/main/meson_options.txt#L4
4: https://github.com/RedHatInsights/yggdrasil/blob/main/meson.build#L25
1 year, 1 month
