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
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
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
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
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
mikelo2 reported a new issue against the project: `go-rpm-macros` that you are following:
``
Google Cloud's golang SDK used to be a large package, but now each module has different lifecycle while still being a monorepo. This means that multiple subpackages need to be created.
While creating these packages I found a strange behavior with doc files: doc files are installed also in what it would be the original root goipath, causing file conflicts between all submodules.
```
Error: Transaction test error:
file /usr/share/gocode/src/cloud.google.com/go/CHANGES.md conflicts between attempted installs of golang-cloud-google-compute-metadata-devel-0.2.3-1.fc40~bootstrap.noarch and golang-cloud-google-devel-0.110.9-1.fc40~bootstrap.noarch
file /usr/share/gocode/src/cloud.google.com/go/CONTRIBUTING.md conflicts between attempted installs of golang-cloud-google-compute-metadata-devel-0.2.3-1.fc40~bootstrap.noarch and golang-cloud-google-devel-0.110.9-1.fc40~bootstrap.noarch
file /usr/share/gocode/src/cloud.google.com/go/README.md conflicts between attempted installs of golang-cloud-google-compute-metadata-devel-0.2.3-1.fc40~bootstrap.noarch and golang-cloud-google-devel-0.110.9-1.fc40~bootstrap.noarch
file /usr/share/gocode/src/cloud.google.com/go/compute/CHANGES.md conflicts between attempted installs of golang-cloud-google-compute-devel-1.23.2-1.fc40~bootstrap.noarch and golang-cloud-google-compute-metadata-devel-0.2.3-1.fc40~bootstrap.noarch
```
Checking `compute/metadata` module, it can be seen that doc files are installed in different paths (marked with `<--`):
```
(...)
/usr/share/gocode/src/cloud.google.com
/usr/share/gocode/src/cloud.google.com/go
/usr/share/gocode/src/cloud.google.com/go/CHANGES.md <--
/usr/share/gocode/src/cloud.google.com/go/CODE_OF_CONDUCT.md <--
/usr/share/gocode/src/cloud.google.com/go/CONTRIBUTING.md <--
/usr/share/gocode/src/cloud.google.com/go/README.md <--
/usr/share/gocode/src/cloud.google.com/go/RELEASING.md <--
/usr/share/gocode/src/cloud.google.com/go/SECURITY.md <--
/usr/share/gocode/src/cloud.google.com/go/compute
/usr/share/gocode/src/cloud.google.com/go/compute/CHANGES.md <--
/usr/share/gocode/src/cloud.google.com/go/compute/README.md <--
/usr/share/gocode/src/cloud.google.com/go/compute/metadata
/usr/share/gocode/src/cloud.google.com/go/compute/metadata/.goipath
/usr/share/gocode/src/cloud.google.com/go/compute/metadata/CHANGES.md <--
/usr/share/gocode/src/cloud.google.com/go/compute/metadata/CODE_OF_CONDUCT.md <--
/usr/share/gocode/src/cloud.google.com/go/compute/metadata/CONTRIBUTING.md <--
/usr/share/gocode/src/cloud.google.com/go/compute/metadata/README.md <--
/usr/share/gocode/src/cloud.google.com/go/compute/metadata/RELEASING.md <--
/usr/share/gocode/src/cloud.google.com/go/compute/metadata/SECURITY.md <--
(...)
```
The spec has the following setting for goipath:
```
%global goipath cloud.google.com/go/%{module}
```
That means that files should be installed under the module path `cloud.google.com/go/%{module}`, not in the root `cloud.google.com/go`
Checking one of the Azure's SDK spec files, that now has also subpackages as Google's, I see "root" goipath doesn't have doc files installed, only in the module goipath:
```
(...)
/usr/share/gocode/src/github.com
/usr/share/gocode/src/github.com/Azure
/usr/share/gocode/src/github.com/Azure/azure-sdk-for-go <-- no files
/usr/share/gocode/src/github.com/Azure/azure-sdk-for-go/sdk <-- no files
/usr/share/gocode/src/github.com/Azure/azure-sdk-for-go/sdk/storage <-- no files
/usr/share/gocode/src/github.com/Azure/azure-sdk-for-go/sdk/storage/azblob
/usr/share/gocode/src/github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/.goipath
/usr/share/gocode/src/github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/CHANGELOG.md
/usr/share/gocode/src/github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/CODE_OF_CONDUCT.md
/usr/share/gocode/src/github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/CONTRIBUTING.md
/usr/share/gocode/src/github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/README.md
/usr/share/gocode/src/github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/SECURITY.md
/usr/share/gocode/src/github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/SUPPORT.md
(...)
```
The spec file doesn't have anything special other than having to move the module to the root of the builddir. This is also done in the Azure spec files.
- Google's `compute/metadata` spec: https://raw.githubusercontent.com/mikelolasagasti/google-sdk-ng/main/golang…
- Azure's `storage/azblob` spec: https://src.fedoraproject.org/rpms/golang-github-azure-sdk-storage-azblob/r…
Inspecting in a mock shell I see `golang-cloud-google-compute-metadata-devel.file-list` includes all the correct and wrong paths. Moving that file and running manually `go-rpm-integration` I see less files being installed:
~~~
(...)
go-rpm-integration install -i cloud.google.com/go/compute/metadata -b /builddir/build/BUILD/google-cloud-go-compute-metadata-v0.2.3/_build/bin -s /builddir/build/BUILD/google-cloud-go-compute-metadata-v0.2.3/_build -o golang-cloud-google-compute-metadata-devel.file-list -O /builddir/build/BUILD/google-cloud-go-compute-metadata-v0.2.3 -V 0.2.3-1.fc40~bootstrap -T compute/metadata/v0.2.3 -p /builddir/build/BUILDROOT/golang-cloud-google-compute-metadata-0.2.3-1.fc40~bootstrap.x86_64 -g /usr/share/gocode -r '.*example.*'
(...)
<mock-chroot> sh-5.2# diff -u golang-cloud-google-compute-metadata-devel.file-list golang-cloud-google-compute-metadata-devel.file-list.old
--- golang-cloud-google-compute-metadata-devel.file-list 2023-11-04 18:58:25.691910878 +0100
+++ golang-cloud-google-compute-metadata-devel.file-list.old 2023-11-04 18:53:36.369990645 +0100
@@ -10,8 +10,19 @@
"/usr/share/gocode/src/cloud.google.com/go/compute/metadata/retry_linux_test.go"
"/usr/share/gocode/src/cloud.google.com/go/compute/metadata/retry_test.go"
"/usr/share/gocode/src/cloud.google.com/go/compute/metadata/tidyfix.go"
+%dir "/usr/share/gocode/src/cloud.google.com"
+%dir "/usr/share/gocode/src/cloud.google.com/go"
+%dir "/usr/share/gocode/src/cloud.google.com/go/compute"
%dir "/usr/share/gocode/src/cloud.google.com/go/compute/metadata"
%dir "/usr/share/gocode/src/cloud.google.com/go/compute/metadata/internal"
+%doc "/usr/share/gocode/src/cloud.google.com/go/CHANGES.md"
+%doc "/usr/share/gocode/src/cloud.google.com/go/CODE_OF_CONDUCT.md"
+%doc "/usr/share/gocode/src/cloud.google.com/go/CONTRIBUTING.md"
+%doc "/usr/share/gocode/src/cloud.google.com/go/README.md"
+%doc "/usr/share/gocode/src/cloud.google.com/go/RELEASING.md"
+%doc "/usr/share/gocode/src/cloud.google.com/go/SECURITY.md"
+%doc "/usr/share/gocode/src/cloud.google.com/go/compute/CHANGES.md"
+%doc "/usr/share/gocode/src/cloud.google.com/go/compute/README.md"
%doc "/usr/share/gocode/src/cloud.google.com/go/compute/metadata/CHANGES.md"
%doc "/usr/share/gocode/src/cloud.google.com/go/compute/metadata/CODE_OF_CONDUCT.md"
%doc "/usr/share/gocode/src/cloud.google.com/go/compute/metadata/CONTRIBUTING.md"
@@ -20,3 +31,5 @@
%doc "/usr/share/gocode/src/cloud.google.com/go/compute/metadata/SECURITY.md"
%doc "/usr/share/gocode/src/cloud.google.com/go/compute/metadata/migration.md"
%doc "/usr/share/gocode/src/cloud.google.com/go/compute/metadata/testing.md"
+%doc "/usr/share/gocode/src/cloud.google.com/go/testing.md"
+%license "LICENSE"
~~~
I don't know when those other `%dir`, `%doc` and `%license%` are being added, I guess it's part of `go-rpm-macros`'s job.
I modified spec's goipath from `cloud.google.com/go/%{module}` to `github.com/GoogleCloudPlatform/google.com/go/%{module} ` just for testing purposes and the package only includes the required `%docs`.
I tried removing `%global godocs` but didn't work. The only workaround I see that may work is editing `.file-list` file to remove unneeded files.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/57
eclipseo opened a new pull-request against the project: `go-rpm-macros` that you are following:
``
Disable Markdown files installation
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/58