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
Hi,
Fedora’s new Go packaging macros landed in rawhide (koji) today.
The corresponding Fedora Go packaging conventions are therefore
EFFECTIVE for new rawhide builds. For the first time in Fedora’s
history, we will be able to perform Go package builds conforming to an
approved Fedora Packaging Guideline.
Packaging documentation:
https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/
and approval: https://pagure.io/packaging-committee/issue/382
The go-rpm-templates package provides more complete info.
F31 change page:
https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
and approval: https://pagure.io/fesco/issue/2120
While the guidelines will feel familiar to anyone who created a Fedora
Go packages in the last two years, they DO include a backwards-
incompatible change. Making GOPATH manipulation robust required moving
the corresponding logic to %prep with a new %goprep macro.
Therefore, existing specs are expected to fail without the addition of
the %goprep call.
This is of course not the end of the road, just a key step.
It opens the way to a mass cleanup and refresh of the Fedora Go stack.
https://pagure.io/packaging-committee/issue/901
A preview of this refresh is available here:
https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/builds/
Enormous thanks to
– Robert-André Mauchin (eclipseo) for the gigantic work done reviewing
updating and cleaning-up all those packages, and to
– Elliott Sales de Andrade (Qulogic), that picked up maintenance of
golist and fixed many of its long-standing bugs and limitations.
Many thanks to the mock, rpm and redhat-rpm-config maintainers,
that integrated the changes, we built upon (Igor Gnatenko, Florian
Festi, Miroslav Suchý, Panu Matilainen)
The macro set supports Go DynamicBuildRequires
https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
They will be usable in mock as soon as rpm 4.15 lands
https://fedoraproject.org/wiki/Changes/RPM-4.15
Use in koji or copr will have to wait for the corresponding refresh
buldsystem-side. So this part of the change is a technology preview for
now.
Best regards,
--
Nicolas Mailhot
Le 2019-06-18 10:19, Miroslav Suchý a écrit :
> Dne 18. 06. 19 v 3:27 Igor Gnatenko napsal(a):
>> as of today, builders have been updated (thanks to Kevin) and
>> DynamicBuildRequires finally work in Rawhide.
>>
>> Change Page:
>> https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
>> Example of real build:
>> https://koji.fedoraproject.org/koji/buildinfo?buildID=1286391
>
> On the Change page we have two examples: one general minimal example
> and example of Rust.
> If any of you have more examples how to dynamically generate
> BuildRequires e.g., for nojs, ruby, golang... then please
> send it to me privately or here in this thread. I would love to add it
> to the documentation.
The necessary tooling is already available Go-side and has been pushed
as part of the
https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
change last week (in rawhide only because it depends on changes in
redhat-rpm-config not available in previous releases).
As documented in the templates provided in go-rpm-templates, activating
them is just a
%go_generate_buildrequires
call in %generate_buildrequires
https://pagure.io/go-rpm-macros/blob/master/f/templates/rpm/spectemplate-go…
(you need the rest of the Go packaging template for this to work)
As noted in the template, this generates un-versioned BuildRequires
(like our automated Go Requires).
Versioning information will be available after we switch to modules our
Go stack (the Golang module concept, not the Fedora one). That means Go
1.14 at the earliest, end of the year. The module support in Go 1.13,
scheduled for this summer, is not complete enough to be used in rpm
packages.
@eclipseo: that means you can re-add automated BuildRequires to our Go
packaging guidelibnes, it was removed because the Fedora infra was not
ready yet.
Regards
--
Nicolas Mailhot
mooz reported a new issue against the project: `go-rpm-macros` that you are following:
``
I'm trying to build a golang package for EL7 but I'm unable to create a SRPM from a spec file after installing the go RPM macros. I'm receiving the below error:
```
rpmbuild -bs golang-github-jedisct1-clocksmith.spec
error: Bad file: /home/test/rpmbuild/SOURCES/%{archivename}.%{archiveext}: No such file or directory
RPM build errors:
Bad file: /home/test/rpmbuild/SOURCES/%{archivename}.%{archiveext}: No such file or directory
```
I thought maybe the issue was caused by the macros.forge file not being included in the latest EL7 build of redhat-rpm-config (as mentioned at https://fedoraproject.org/wiki/More_Go_packaging#Testing_the_proposal) but trying to copy the file over from a later Fedora release didn't change the behavior.
Not too familiar with the entire process on Go packaging, is there something I'm missing?
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/4
qulogic reported a new issue against the project: `go-rpm-macros` that you are following:
``
While `gocheckflags` exists, it gets passed to `go-rpm-integration`, but ignored after that. For example, if I add:
```
%global gocheckflags -timeout 30m
```
then it appears when `go-rpm-integration` is called:
```
+ go-rpm-integration check -i go.etcd.io/bbolt -b /builddir/build/BUILD/bbolt-1.3.3/_build/bin -s /builddir/build/BUILD/bbolt-1.3.3/_build -V 1.3.3-1.fc31 -p /builddir/build/BUILDROOT/golang-etcd-bbolt-1.3.3-1.fc31.x86_64 -g /usr/share/gocode -timeout 30m -v
Testing in: /builddir/build/BUILD/bbolt-1.3.3/_build/src
PATH: /builddir/build/BUILD/bbolt-1.3.3/_build/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin
GOPATH: /builddir/build/BUILD/bbolt-1.3.3/_build:/usr/share/gocode
GO111MODULE: off
command: go test -buildmode pie -compiler gc -ldflags "-X go.etcd.io/bbolt/version=1.3.3 -extldflags '-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld '"
testing: go.etcd.io/bbolt
```
but it's not there in the `command: go test ...`.
I also tried `export GO_TEST_FLAGS="-timeout 30m"`, but this gets overwritten by something else.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/18
eclipseo opened a new pull-request against the project: `golist` that you are following:
``
Always install SFiles whatever the arch
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/pull-request/25