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
eclipseo reported a new issue against the project: `go-rpm-macros` that you are following:
``
When packaging: `code.gitea.io/tea`
The goname is reduced to `golang-codeea-tea`
Also the download link is wrong: it is resolved to
`https://gitea.com/gitea/tea/archive/0.7.0.tar.gz`
whereas it should be
`https://gitea.com/gitea/tea/archive/v0.7.0.tar.gz`
Can someone with knowledge of Lua regex fix this?
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/32
qulogic opened a new pull-request against the project: `go-rpm-macros` that you are following:
``
Use --with-tests when running checks also.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/20
I noticed that a package I recently submitted (golang-sr-spc-log) has some odd Provides: values. I can't figure out how they're getting generated this way, or why. From the build log[1]:
Provides: golang(git.sr.ht/~spc/go-log/go-log-0.1.0) = 0.1.0-1.fc34 [...]
Why is the package version (0.1.0) appended to the import path name? I looked at the only other package hosted on git.sr.ht (golang-sr-sircmpwn-getopt), and it does not have the versioned provides. From the build log[2]:
Provides: golang(git.sr.ht/~sircmpwn/getopt) = 0-0.1.20210615git23622cc.fc34 [...]
Investigating the go-rpm-macros some, I found that the go-rpm-integration script claims[3] that it will "tag" the provides with a version if called with the "-v" flag. I discovered that go-rpm-integration is used in the %__go_provides macro in fileattrs/go.attr[4]. However, now I'm stuck. What expands the macro (if it is even a macro) in go.attr and invokes it? Where in all these layers of macros, Lua scripts and bash scripts is the "-v" flag getting appended to the call to go-rpm-integration?
~link
1: https://kojipkgs.fedoraproject.org//packages/golang-sr-spc-log/0.1.0/1.fc34…
2: https://kojipkgs.fedoraproject.org//packages/golang-sr-sircmpwn-getopt/0/0.…
3: https://pagure.io/go-rpm-macros/blob/master/f/bin/go-rpm-integration#_64
4: https://pagure.io/go-rpm-macros/blob/master/f/rpm/fileattrs/go.attr#_5