June 2019 - golang - Fedora Mailing-Lists

[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

1 month

5
7
0 / 0

[go-rpm-macros] Issue #19: LDFlags Macro Typos

by Brian Exelbierd (bex)

bex reported a new issue against the project: `go-rpm-macros` that you are following: `` While working with a new package, I needed some LDFlags passed. I am using this construction in my spec: ``` %build LDFLAGS="-X foo=bar " %gobuild ... ``` I have to put the space in quotes at the end as we appear to have space expansion errors. I was talking to @ignatenkobrain and he pointed out: * https://pagure.io/go-rpm-macros/blob/master/f/rpm/macros.d/macros.go-rpm#... there is a missing space * https://pagure.io/go-rpm-macros/blob/master/f/rpm/macros.d/macros.go-comp... ${LDFLAGS:-%{?currentgoldflags}} ← should be like that `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/19

2 years, 7 months

3
4
0 / 0

New Go Packaging Guidelines landed in rawhide (koji) today

by Nicolas Mailhot

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

4 years, 5 months

3
5
0 / 0

[Fedocal] Reminder meeting : Go SIG Meeting

by jcajka＠fedoraproject.org

Dear all, You are kindly invited to the meeting: Go SIG Meeting on 2019-06-25 from 16:00:00 to 17:00:00 UTC At fedora-golang(a)irc.freenode.net The meeting will be about: Meeting of Go SIG. For proposed agenda see the tagged tickets https://pagure.io/GoSIG/go-sig/issues?status=Open&tags=meeting Source: https://apps.fedoraproject.org/calendar/meeting/9344/

4 years, 5 months

1
0
0 / 0

Re: HEADS UP: DynamicBuildRequires are available

by 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-... (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

4 years, 5 months

1
0
0 / 0

[go-rpm-macros] Issue #4: Issues building golang source package on EL7

by Gary Mann

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

4 years, 5 months

2
8
0 / 0

[go-rpm-macros] Issue #18: Passing extra args to `go test`

by Elliott Sales de Andrade

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

4 years, 5 months

2
3
0 / 0

[go-rpm-macros] Issue #17: Go does not install SFiles not required by the arch

by Robert-André Mauchin

eclipseo reported a new issue against the project: `go-rpm-macros` that you are following: `` Remember we said we want noarch packages? So we include *all* files whatever the arch with IgnoredGoFiles. SFiles are similar as they can be specific to an arch, but we don't have a "IgnoredSFiles" option to include them in all builds, so we end up with packages which are not exactly the same on every arch: - https://koji.fedoraproject.org/koji/taskinfo?taskID=35534910 - https://koji.fedoraproject.org/koji/taskinfo?taskID=35535838 - https://koji.fedoraproject.org/koji/taskinfo?taskID=35536361 - https://koji.fedoraproject.org/koji/taskinfo?taskID=35537198 - https://koji.fedoraproject.org/koji/taskinfo?taskID=35537483 - https://koji.fedoraproject.org/koji/taskinfo?taskID=35537702 - https://koji.fedoraproject.org/koji/taskinfo?taskID=35539134 The immediate solution would be to include all files with the .s extension: ```golist --include-extension .s --to-install --package-path ${goipath} $(expandflags)``` `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/17

4 years, 6 months

3
5
0 / 0

[golist] PR #25: Always install SFiles whatever the arch

by Robert-André Mauchin

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

4 years, 6 months

3
8
0 / 0

Re: New Go Packaging Guidelines landed in rawhide (koji) today

by Jakub Cajka

----- Original Message ----- > From: "Zbigniew Jędrzejewski-Szmek" <zbyszek(a)in.waw.pl> > To: "Development discussions related to Fedora" <devel(a)lists.fedoraproject.org> > Cc: golang(a)lists.fedoraproject.org > Sent: Wednesday, June 12, 2019 4:20:40 PM > Subject: Re: New Go Packaging Guidelines landed in rawhide (koji) today > > On Wed, Jun 12, 2019 at 04:39:07AM -0400, Jakub Cajka wrote: > > > F31 change page: > > > https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines > > > and approval: https://pagure.io/fesco/issue/2120 > > > > It seems that this change has been accepted as Self Contained Change > > but IMHO it is System Wide Change as it seems to affect (nearly) all > > Go based packages in distribution(and will require work/attention of > > people that are not change owners, actually not accounted for in > > change proposal). For past several releases I have been doing rebase > > of Go compiler change(yet to be filed for F31) that is IMHO > > comparable(maybe a bit smaller) in scope and they were always deemed > > by FESCO as System Wide Changes. This really leaves me > > confused. Could someone from FESCO clarify? > > https://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes says > > Examples include [...] a coordinated effort within a SIG with > > limited impact outside the SIG's functional area > > So in this case, even though the change affects so many packages, it > falls into the "self contained change" category. > > That said, the difference between "system-wide" and "self-contained" > boils down to two things: some additional data required in the change > page, and filing the change a bit earlier. In this case the additional > data is mostly there in the change page, and the change was filed early, > so even if we were to change the Change to "system-wide", the effect > would be cosmetic. > > Zbyszek Thank you for clarification :). IMO it would be great if that has been recorded in https://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes, this approach can't be really inferred from it(at least I don't see it there). With that popped on my mind that may be calling it "early/late window change" would fit better along with recording the complexity of the change, rather then system wide, contained change. But this is really just my brain storm. Unfortunately no early changes for me as Golang release are aligned late in to the Fedora devel cycle. JC > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >

4 years, 6 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang June 2019