[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
[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
Golang 1.16
by Robert-André Mauchin
Hello Jakub,
I wanted to ask you at the meeting, how is the update to Golang 1.16
shaping up? Have you tested it on a small batch of packages? Should we
expect breaking changes from upstream again?
Best regards,
Robert-André
3 years, 3 months
Implementing Go modules in F34
by Robert-André Mauchin
Hi,
Following the discussion we had at the meeting, it would be great if we
had the new tooling in F34. As you may know, RHEL9 will be based off
F34; we already missed the mark for RHEL8 which still doesn't support
our current macros, so we have to bundle everything.
I don't expect we will be able to rebuild our 1,600ish packages with Go
modules for F34, so the changes would need to be **fully** backwards
compatible, so we can target F35 without breaking F34.
Nicolas, the issue is mostly in your hands, can we count on you to push
for changes in redhat-rpm-config, package modist and update go-(s)rpm
macros? We would need to move quickly as F34 is approaching. Are your
current work on modules macros backward compatible without any changes
to current packages?
Best regards,
Robert-André
3 years, 3 months