[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
Google Go fonts
by Nicolas Mailhot
Hi,
The Go font families (Go, Go Mono and Go Smallcaps) are now available
in Fedora 32 and 33 as normal system fonts.
You’ve all encountered them on godoc.org when reading Go source code
examples.
Regards,
--
Nicolas Mailhot
4 years, 1 month
Re: Include non-RPM content in buildroot
by Nicolas Mailhot
Le vendredi 21 février 2020 à 15:57 +0100, Martin Sehnoutka a écrit :
> Hi,
Hi,
> Go went even further in this case and it is
> common
> to bundle all the dependencies as a source code directly in the
> upstream
> repository. See this repo as an example:
> https://github.com/containers/libpod/tree/master/vendor
Since you take Go in example – vendoring (bundling) proved such a
maintenance headache upstream that Google had to create a complete new
packaging system to get rid of it. Not for Fedora or Linux people, but
because they had huge problems with unmaintained, holed and non-legal
code lurking in this kind of vendor pile.
So Go (upstream) is going away from the kind of practice you’re
advocating. And Google’s implementation of versionning in Go modules is
even stricter and more rigid than the one in rpm (precisely because
they tried the lala-lala let’s bundle everything without caring about
versions, and were badly burned).
From a technical POW, we need to improve the mapping of their packaging
system and then integrating the Go ecosystem in Fedora will be no
harder than integrating any other language component (easier, because
the language-specific package manager produces very regular sources).
From a maintenance POW dumping huge piles of unmanaged third-party code
on build farms just does not work long term. That’s why Google had to
break its vendor piles in atomic Go modules.
From a process POW, Fedora is not ready. Not because out tech does not
work but because our processes can not handle the pile of atomic
components generated by upstream practices. Since the problem is
process, not technical side, please work on the process side, instead
of trying to bypass the process with bad technical solutions.
Regards,
--
Nicolas Mailhot
4 years, 1 month
Go SIG meeting 4.2.2020(tomorrow)
by Jakub Cajka
Hello,
sorry for short notice. I will not be able to chair tomorrow Go sig meeting as I will be traveling.
Neal, Nicolas could please chair it?
Thank you,
JC
4 years, 2 months
