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:
``
This is a clone of
https://github.com/gofed/go-macros/issues/56
The problem is actually in golist, not in the macros themselves. Sticking it in the macro project for now as they need to be switched to deploy in libdir if this is not fixed
According to @jcajka this needs fixing in any case, because other build options are handled the same way by the Go compiler, so deploying only the files corresponding to a particular set of options means sources can not be used with another one later. And we have some of those in Fedora, for example, optional selinux support in some container projects.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/1
Hello,
as golang got deprecated in favor of Go-toolset[1] with release of RHEL 7.6[2] and as there has been interested[3]. I have unretired and reintroduced the golang package back in to the EPEL7. For time being I will keep updates on the same cadence as for EPEL6, i.e. keeping one version of GC for the duration of its upstream support, i.e. skipping every other major(1.X) release.
Currently package is in the bodhi update[4] and also update for epel6 is there[5], karma and testing will be much appreciated for both.
Reintroduction of the golang back to EPEL7 opens question if we(I guess as Go-SIG and epel/fedora community) should pursue the same (S)RPM macros setup as we have in Fedora, so we can get the whole Fedora's Go stack there. Is it even technically possible?(changing the minimal buildroot in EPEL7?) What do you think about it? Anybody interested?
JC
[1] https://tinyurl.com/y9g2vpv9
[2] https://tinyurl.com/y74gemxs
[3] https://pagure.io/GoSIG/go-sig/issue/19
[4] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ba8845b83b
[5] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e36943c593
Guys and gals,
The SIG Group has been approved, we're rolling.
We have now a SIG specific mailing list: https://lists.fedoraproject.org/admin/lists/go-sig.lists.fedoraproject.org
It is set to private because we could receive security bugs.
We have now a group in FAS: https://admin.fedoraproject.org/accounts/group/
members/go-sig
I have added all the relevant people. You just have to relog in Pagure to
update the details there.
**Robbi Nespu (robbinespu)** and **Zachary Snyder (sadin)**, I couldn't add
you because you're not member of the packager group.
The bugzilla account for the SIG is not yet created, I'm waiting for the
bugzilla mail in the spam box.
Now the hardest part is coming, convincing all Golang maintainers to assign
the SIG to their packages. We can start with all our packages: in the package
settings on Pagure, assign the group "go-sig" as admin. Yes we have to do that
manuallyfor each package, it's gonna be a pain in the butt if you have a lot
of packages.
I will now send a mail to all Golang maintainers enjoining them to do the same
and to join the SIG.
Best regards,
Robert-André