May 2019 - golang - Fedora mailing-lists

[go-rpm-macros] Issue #2: EPEL availability
by Nicolas Mailhot 29 Mar '24

29 Mar '24

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

2 4

[go-rpm-macros] Issue #3: %goprep should apply patches automatically
by Nicolas Mailhot 29 Mar '24

29 Mar '24

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

6 9

[go-rpm-macros] Issue #4: Issues building golang source package on EL7
by Gary Mann 15 Jun '19

15 Jun '19

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

2 8

[go-rpm-macros] Issue #7: %goinstall should verify explicit paths exist
by Elliott Sales de Andrade 14 Jun '19

14 Jun '19

qulogic reported a new issue against the project: `go-rpm-macros` that you are following: `` In the old version of [golang-github-pkg-errors](https://src.fedoraproject.org/rpms/golang-github-…, there was a typo, and `glide.yaml` was listed twice in the sources. This meant that `glide.lock` was never copied to the source directory. When `%goinstall glide.yaml glide.lock` was called later, it created a `glide.lock` _directory_. Now that I'm trying to fix it, it causes [an upgrade error](https://bodhi.fedoraproject.org/updates/FEDORA-2019-f01a015bb7#comme… since rpm can't handle a directory->file change. So now I need to go throw in a scriptlet to fix the directory. `%goinstall` should not accept an explicit path argument that does not exist, and should fail the build. If it really needs to be able to create arbitrary directories like that, it should be behind an explicit flag (like `install -d` is). `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/7

2 5

[go-rpm-macros] Issue #1: -devel subpackage builds differently on different arches
by Nicolas Mailhot 14 Jun '19

14 Jun '19

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

1 3

[go-rpm-macros] Issue #6: golist needs to be run outside the source tree to avoid panics
by Nicolas Mailhot 14 Jun '19

14 Jun '19

nim reported a new issue against the project: `go-rpm-macros` that you are following: `` To workaround https://pagure.io/golist/issue/7, the shell wrapper should switch to another directory (for example /usr/bin) before running `golist`, and switch back to the correct dir afterwards (so add strategic pushds popds to keep track of where the user, golist and the tests want to be) `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/6

2 4

[go-rpm-macros] PR #14: make use of golist --with-tests in dynamic buildrequires
by Nicolas Mailhot 28 May '19

28 May '19

nim opened a new pull-request against the project: `go-rpm-macros` that you are following: `` make use of golist --with-tests in dynamic buildrequires `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/14

1 1

ANN: golist 0.10.0
by Elliott Sales de Andrade 27 May '19

27 May '19

Hi, I just tagged golist 0.10.0 a little while back [1]. It fixes various bugs and RFEs that were needed to finish implementing the Go macros. I've also opened a Review Request for golang-pagure-golist [2], though it will need some coordination with the original /usr/bin/golist-providing package (go-compilers-golang-compiler) to ensure no conflicts. [1] https://pagure.io/golist/releases [2] https://bugzilla.redhat.com/show_bug.cgi?id=1714090 -- Elliott

1 0

[golist] Issue #7: runtime panic, nil dereference when running %gochecks
by Nicolas Mailhot 27 May '19

27 May '19

nim reported a new issue against the project: `golist` that you are following: `` Issue migrated from https://github.com/gofed/symbols-extractor/issues/157 This is from the mock build log: ```sh + go-rpm-integration check -i github.com/syncthing/notify -p /builddir/build/BUILDROOT/golang-github-syncthing-notify-0-0.5.20181011git116c45b.fc30.x86_64 -g /usr/share/gocode -b /builddir/build/BUILD/notify-116c45bb5ad48777321e4984d1320d56889b6097/_build -r '.*example.*' Testing: github.com/syncthing/notify panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x5ad9fd] goroutine 1 [running]: github.com/gofed/symbols-extractor/vendor/github.com/urfave/cli.HandleActio… /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/src/github.com/gofed/symbols-extractor/vendor/github.com/urfave/cli/app.go:472 +0x278 panic(0x920cc0, 0xd79220) /usr/lib/golang/src/runtime/panic.go:513 +0x1b9 github.com/gofed/symbols-extractor/pkg/util/internal/load.ImportPaths(0xc00…, 0x1, 0x1, 0x0, 0x1, 0xc0001450c8) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/src/github.com/gofed/symbols-extractor/pkg/util/internal/load/pkg.go:1888 +0x5d github.com/gofed/symbols-extractor/pkg/util/internal/load.PackagesAndErrors…, 0x1, 0x1, 0xa3c700, 0xc0002a7480, 0x1c) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/src/github.com/gofed/symbols-extractor/pkg/util/internal/load/pkg.go:1842 +0xa3 github.com/gofed/symbols-extractor/pkg/util.ListPackage(0xc0002d22f1, 0x1b, 0x1b, 0x0, 0xc000145290) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/src/github.com/gofed/symbols-extractor/pkg/util/util.go:420 +0x8f github.com/gofed/symbols-extractor/pkg/util.(*PackageInfoCollector).Collect…, 0x6d, 0xa3e6a0, 0xc0002bcc30, 0x0, 0x0, 0x0, 0xc000145328) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/src/github.com/gofed/symbols-extractor/pkg/util/util.go:181 +0x6e8 path/filepath.walk(0xc0002d22a0, 0x6d, 0xa3e6a0, 0xc0002bcc30, 0xc0002a7460, 0x0, 0x2) /usr/lib/golang/src/path/filepath/path.go:362 +0xf6 path/filepath.Walk(0xc0002d22a0, 0x6d, 0xc0002a7460, 0x9a32e6, 0x1) /usr/lib/golang/src/path/filepath/path.go:404 +0x105 github.com/gofed/symbols-extractor/pkg/util.(*PackageInfoCollector).Collect…, 0x7ffc9eabf894, 0x1b, 0x7ffc9eabf894, 0x1b) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/src/github.com/gofed/symbols-extractor/pkg/util/util.go:139 +0x158 main.main.func1(0xc0002b7a40, 0x0, 0x0) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/src/github.com/gofed/symbols-extractor/cmd/golist/golist.go:73 +0x5d2 reflect.Value.call(0x905580, 0x9c8240, 0x13, 0x9a3ba5, 0x4, 0xc0001459d0, 0x1, 0x1, 0xc0000cc200, 0x8a7ade, ...) /usr/lib/golang/src/reflect/value.go:447 +0x449 reflect.Value.Call(0x905580, 0x9c8240, 0x13, 0xc0001459d0, 0x1, 0x1, 0x1, 0x9a32d8, 0x1) /usr/lib/golang/src/reflect/value.go:308 +0xa4 github.com/gofed/symbols-extractor/vendor/github.com/urfave/cli.HandleActio…, 0x9c8240, 0xc0002b7a40, 0x0, 0x0) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/src/github.com/gofed/symbols-extractor/vendor/github.com/urfave/cli/app.go:481 +0x1fb github.com/gofed/symbols-extractor/vendor/github.com/urfave/cli.(*App).Run(…, 0xc0000ce000, 0x7, 0x7, 0x0, 0x0) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/src/github.com/gofed/symbols-extractor/vendor/github.com/urfave/cli/app.go:240 +0x47f main.main() /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/src/github.com/gofed/symbols-extractor/cmd/golist/golist.go:125 +0x791 ``` Since this crash doesn't impact the package build itself, I'm going to ignore it. But it looks like this should be fixed ... Here's a link to the affected koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=30252400 The traceback can be seen in the %check section of the build.log. `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/7

4 16

[golist] PR #19: Initialize load.Mod* variables in ListPackage...
by Robert-André Mauchin 27 May '19

27 May '19

eclipseo opened a new pull-request against the project: `golist` that you are following: `` Initialize load.Mod* variables in ListPackage... `` To reply, visit the link below or just reply to this email https://pagure.io/golist/pull-request/19

2 2

[golist] Issue #3: golist needs a switch to process a codebase and its tests in a single pass
by Nicolas Mailhot 27 May '19

27 May '19

nim reported a new issue against the project: `golist` that you are following: `` Right now `golist` does not permit querying the imports of a project and its tests in a single pass. You can emulate most of it with two separate commands: ```sh golist --imported --package-path github.com/sirupsen/logrus --skip-self golist --imported --package-path github.com/sirupsen/logrus --skip-self --tests ``` However the second line can request things the first line decided to filter out, because they are provided by the project itself. And that will probably break some builds once https://github.com/rpm-software-management/rpm/pull/593 or https://pagure.io/fesco/issue/2004 are done. For dynamic BuildRequires to work reliably, we really need a single codebase+tests call (we can still use the codebase-only line when a packager disables tests in its specs). `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/3

2 3

[golist] PR #24: Add option for querying main and test simultaneously.
by Elliott Sales de Andrade 26 May '19

26 May '19

qulogic opened a new pull-request against the project: `golist` that you are following: `` Add option for querying main and test simultaneously. `` To reply, visit the link below or just reply to this email https://pagure.io/golist/pull-request/24

2 2

[Fedocal] Reminder meeting : Go SIG Meeting
by jcajka＠fedoraproject.org 26 May '19

26 May '19

Dear all, You are kindly invited to the meeting: Go SIG Meeting on 2019-05-28 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/

1 0

[go-rpm-macros] PR #13: make use of golist 0.10.0 fixes
by Nicolas Mailhot 21 May '19

21 May '19

nim opened a new pull-request against the project: `go-rpm-macros` that you are following: `` make use of golist 0.10.0 fixes `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/13

1 1

Review Request and Questions
by Brian (bex) Exelbierd 21 May '19

21 May '19

Hi, I have submitted the first of my dependency review requests here: https://bugzilla.redhat.com/show_bug.cgi?id=1712280 Feedback is greatly appreciated so I can clean anything up on the next set of dependencies. I am working on the main application packaging for gocryptfs (https://github.com/rfjakob/gocryptfs/) and have hit a few questions: 1. The upstream provides specific source tarballs for each version here, https://github.com/rfjakob/gocryptfs/releases - I am planning to use these as opposed to the gomacros to determine a git tag to pull. Is there a reason not to do this? 2. The upstream build script sets up some values to be included in the executables version string. I presume this helps with debugging. I am told that the Go SIG would prefer to see the macros used for building rather than the upstream build script. This is fine, except I am not sure how to handle these values. Specifically, they are: GITVERSION=$(cat VERSION) GITVERSIONFUSE=$(rpm -q golang-github-hanwen-fuse-devel --queryformat '%{version}') BUILDDATE=$(date +%Y-%m-%d) These can be set, presumably, somehow in the spec file (i haven't tested my ideas here yet). They are passed to `go build` as part of the ldflags, specifically as: "-X main.GitVersion=$GITVERSION -X main.GitVersionFuse=$GITVERSIONFUSE -X main.BuildDate=$BUILDDATE" prepended to any existing ldflags How do you pass this information with the macros? thanks, bex -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexelbie(a)redhat.com | bex(a)pobox.com

4 7

packaging bootstrap example, ideally with golang
by Brian (bex) Exelbierd 19 May '19

19 May '19

Hi, I am trying to package gocryptfs. It has a pair of dependencies that have a circular dependency: golang-github-jacobsa-oglemock golang-github-jacobsa-ogletest I think I am supposed to make one of them have a bootstrap configuration so it can be built without the other and then build the other and then rebuild the first one. If this is right, can someone point me to an example of this, ideally done with golang, so I can work it out? thanks, bex -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexelbie(a)redhat.com | bex(a)pobox.com

1 0

[Fedocal] Reminder meeting : Go SIG Meeting
by jcajka＠fedoraproject.org 12 May '19

12 May '19

Dear all, You are kindly invited to the meeting: Go SIG Meeting on 2019-05-14 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/

1 0

[golist] Issue #2: golist processing is arch and tag-specific
by Nicolas Mailhot 06 May '19

06 May '19

nim reported a new issue against the project: `golist` that you are following: `` This is the root cause behind https://pagure.io/go-rpm-macros/issue/1 When asked to list the files to deploy, golist only answers for the current tags (arch and build options) https://pagure.io/go-rpm-macros/blob/master/f/bin/go-rpm-integration#_386 Being arch-specific is annoying but not a blocker¹ However @jcajka thinks this will also remove installation of files not covered by current build tags. And that is a huge problem because that makes the result unusable, by any consumer, that needs a different tag combination than the one passed by the source code packager. ¹ The migration of Fedora’s go -devel packages to an arch-specific root can be kludged as evidenced by https://copr.fedorainfracloud.org/coprs/nim/go-rpm-macros/builds/ because they are only installed transiently `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/2

3 7

[golist] Issue #4: golist needs to be able to process multiple import path in one pass
by Nicolas Mailhot 06 May '19

06 May '19

nim reported a new issue against the project: `golist` that you are following: `` This is a similar issue to https://pagure.io/golist/issue/3 this time for packagers that try to package several import paths in a single spec (I’m told the practice is common RHEL-side). For this use pattern to work reliably, you need to compute the codebase requirements in a single pass. Otherwise `golist` will forget to filter out imports of code, already available on-system under another import path. And that will break BuildRequires computation. So we need something like ```sh $ golist --imported --skip-self --with-tests --package-path %{goipath0} --package-path %{goipath1} --package-path %{goipath2} ``` `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/4

2 4

[golist] Issue #13: golist should permit specifying its output format
by Nicolas Mailhot 06 May '19

06 May '19

nim reported a new issue against the project: `golist` that you are following: `` `golist` only implements a single output format, which means this output needs to be reprocessed in shell before being fed to other software, like rpm¹. This shell reprocessing is brittle and adds noise to Go package build logs. Mature utilities allow specifying an output format template, which simplifies their integration with other software. This can be done: * either by defining a custom format string using predefined variables (as [done](http://man7.org/linux/man-pages/man1/time.1.html) by the `time -f`command), * or by specifying a specific package dep format built-in (as done by the `fcquery --format '%{=pkgkit}'` command, that allowed direct integration [within rpm](https://github.com/rpm-software-management/rpm/blob/ff4b9111aeba01dd02… in [2009](https://bugs.freedesktop.org/show_bug.cgi?id=17107)) `golist` should implement something similar. ¹ Typically to [add `golang()`](https://pagure.io/go-rpm-macros/blob/master/f/rpm/macros.d/macros.go-rpm#_228) around dependencies, would need more processing if it ever evolves to list version constrains `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/13

2 5

[golist] Issue #14: golist should handle naming assertions cleanly
by Nicolas Mailhot 06 May '19

06 May '19

nim reported a new issue against the project: `golist` that you are following: `` Because the naming of Go projects is a mess many of them (including core Google modules) have started asserting how they should be named. This results in golist panics. Because golist is often called by other scripts (for example, rpm dependency scripts) the panic messages are unhelpful, because the recipient of those messages has not called golist directly and does not know what exact golist call resulted in this panic. golist should handle this case by default and: 1. output useful info to stderr, including what exactly it was doing at the panic time 2. abort with an error code `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/14

2 1

[golist] PR #22: Allow specifying multiple package paths at a time.
by Elliott Sales de Andrade 06 May '19

06 May '19

qulogic opened a new pull-request against the project: `golist` that you are following: `` Allow specifying multiple package paths at a time. `` To reply, visit the link below or just reply to this email https://pagure.io/golist/pull-request/22

1 1

[golist] PR #23: WIP: Add output templating
by Elliott Sales de Andrade 06 May '19

06 May '19

qulogic opened a new pull-request against the project: `golist` that you are following: `` WIP: Add output templating `` To reply, visit the link below or just reply to this email https://pagure.io/golist/pull-request/23

2 4

[go-rpm-macros] PR #12: Force GO111MODULE=off till the macros grow Go module support
by Nicolas Mailhot 03 May '19

03 May '19

nim opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Force GO111MODULE=off till the macros grow Go module support `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/12

1 1

[go-rpm-macros] PR #11: update licensing
by Nicolas Mailhot 03 May '19

03 May '19

nim opened a new pull-request against the project: `go-rpm-macros` that you are following: `` update licensing `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/11

1 1

[go-rpm-macros] PR #10: Move a lot of code unrelated to srpm creation to srpm macros
by Nicolas Mailhot 03 May '19

03 May '19

nim opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Move a lot of code unrelated to srpm creation to srpm macros `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/10

1 1

Fwd: [packaging-committee] Issue #382: Go Packaging Guidelines Draft
by Robert-André Mauchin 02 May '19

02 May '19

We have officially new guidelines! Now let's packages the macros!

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang May 2019