December 2018 - 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 #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

[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] 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] 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 #12: golist should be buildroot prefix aware
by Nicolas Mailhot 19 Apr '19

19 Apr '19

nim reported a new issue against the project: `golist` that you are following: `` The last stage of rpm packaging is copying a clean final copy of all the files that will be shipped in an arborescence under a `%{buildroot}` prefix. That is the deployment tree that is operated on to compute the actual requires and provides rpm will generate. As a consequence of this rpm design we can not change: * the files operated on are not in their final place but under a root prefix (`%{buildroot}/something` instead of `something`), and * absolute symbolic links that point within the target deployment tree are left dangling (they point to `something`, when `/something` is still at `%{buildroot}/something`) Since *golist* is used to compute provides and requires for Go sources, and those sources can include absolute symlinks, and will continue to prefer absolute symlinks over relative symlinks because relative symlinks are quite hard to get right, *golist* needs to learn to work in prefix mode, and learn to walk to `%{buildroot}/something` when encountering a `/something` symlink in the source tree. `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/12

2 4

[golist] Issue #8: Crash when processing github.com/kr/pretty 0.1.0
by Nicolas Mailhot 10 Apr '19

10 Apr '19

nim reported a new issue against the project: `golist` that you are following: `` golist 9f4330a, built on x86_64 with https://koji.fedoraproject.org/koji/buildinfo?buildID=1139757 crashes when processing github.com/kr/pretty 0.1.0 It should not do that ```sh + cd pretty-0.1.0 + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . + export GOIPATH=github.com/kr/pretty + GOIPATH=github.com/kr/pretty + export GOBUILDDIR=/builddir/build/BUILD/creachadair-shell-85f4313bf556/_build + GOBUILDDIR=/builddir/build/BUILD/creachadair-shell-85f4313bf556/_build + export GOPATH=/builddir/build/BUILD/creachadair-shell-85f4313bf556/_build:/usr/share/gocode + GOPATH=/builddir/build/BUILD/creachadair-shell-85f4313bf556/_build:/usr/share/gocode + export PATH=/builddir/build/BUILD/creachadair-shell-85f4313bf556/_build/bin:/builddir/.local/bin:/builddir/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin + PATH=/builddir/build/BUILD/creachadair-shell-85f4313bf556/_build/bin:/builddir/.local/bin:/builddir/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin + export GOSOURCEDIR=/builddir/build/BUILD/pretty-0.1.0 + GOSOURCEDIR=/builddir/build/BUILD/pretty-0.1.0 + export 'LDFLAGS= -X github.com/kr/pretty/version=0.1.0' + LDFLAGS=' -X github.com/kr/pretty/version=0.1.0' + rm -fr /builddir/build/BUILD/pretty-0.1.0/vendor + [[ ! -e /builddir/build/BUILD/creachadair-shell-85f4313bf556/_build/bin ]] + [[ ! -e /builddir/build/BUILD/creachadair-shell-85f4313bf556/_build/src/github.com/kr/pretty ]] ++ dirname /builddir/build/BUILD/creachadair-shell-85f4313bf556/_build/src/github.com/kr/pretty + install -m 0755 -vd /builddir/build/BUILD/creachadair-shell-85f4313bf556/_build/src/github.com/kr install: creating directory '/builddir/build/BUILD/creachadair-shell-85f4313bf556/_build/src/github.com' install: creating directory '/builddir/build/BUILD/creachadair-shell-85f4313bf556/_build/src/github.com/kr' + ln -fs /builddir/build/BUILD/pretty-0.1.0 /builddir/build/BUILD/creachadair-shell-85f4313bf556/_build/src/github.com/kr/pretty + golist --imported --package-path github.com/kr/pretty --skip-self --tests 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=0x5637f95433af] goroutine 1 [running]: panic(0x5637f99f79e0, 0x5637f9d7fd40) /usr/lib/golang/src/runtime/panic.go:556 +0x2cf fp=0xc000122e20 sp=0xc000122d90 pc=0x5637f93c01bf github.com/urfave/cli.HandleAction.func1(0xc000123a30) /usr/share/gocode/src/github.com/urfave/cli/app.go:473 +0x27a fp=0xc000122ec8 sp=0xc000122e20 pc=0x5637f983ec8a runtime.call32(0x0, 0x5637f9a7a848, 0xc0000aa230, 0x800000008) /usr/lib/golang/src/runtime/asm_amd64.s:522 +0x3d fp=0xc000122ef8 sp=0xc000122ec8 pc=0x5637f93eb86d panic(0x5637f99f79e0, 0x5637f9d7fd40) /usr/lib/golang/src/runtime/panic.go:513 +0x1bd fp=0xc000122f88 sp=0xc000122ef8 pc=0x5637f93c00ad runtime.panicmem() /usr/lib/golang/src/runtime/panic.go:82 +0x60 fp=0xc000122fa8 sp=0xc000122f88 pc=0x5637f93bf1c0 runtime.sigpanic() /usr/lib/golang/src/runtime/signal_unix.go:390 +0x186 fp=0xc000122ff8 sp=0xc000122fa8 pc=0x5637f93d5606 github.com/gofed/symbols-extractor/pkg/util/internal/load.ImportPaths(0xc00…, 0x1, 0x1, 0x0, 0x2, 0xc000038a00) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/_build/src/github.com/gofed/symbols-extractor/pkg/util/internal/load/pkg.go:1888 +0x5f fp=0xc000123038 sp=0xc000122ff8 pc=0x5637f95433af github.com/gofed/symbols-extractor/pkg/util/internal/load.PackagesAndErrors…, 0x1, 0x1, 0x5637f9a84de0, 0xc000291220, 0x0) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/_build/src/github.com/gofed/symbols-extractor/pkg/util/internal/load/pkg.go:1842 +0xa5 fp=0xc0001231b0 sp=0xc000123038 pc=0x5637f9542c55 github.com/gofed/symbols-extractor/pkg/util.ListPackage(0xc0001483a0, 0x14, 0x14, 0x0, 0xc0001232b8) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/_build/src/github.com/gofed/symbols-extractor/pkg/util/util.go:420 +0x91 fp=0xc000123220 sp=0xc0001231b0 pc=0x5637f982d8e1 github.com/gofed/symbols-extractor/pkg/util.(*PackageInfoCollector).Collect…, 0x55, 0x5637f9a868c0, 0xc000298820, 0x0, 0x0, 0x0, 0xc000123350) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/_build/src/github.com/gofed/symbols-extractor/pkg/util/util.go:181 +0x6ea fp=0xc0001232c8 sp=0xc000123220 pc=0x5637f982e21a path/filepath.walk(0xc000148360, 0x55, 0x5637f9a868c0, 0xc000298820, 0xc000291200, 0x0, 0x2) /usr/lib/golang/src/path/filepath/path.go:362 +0xf8 fp=0xc0001233a0 sp=0xc0001232c8 pc=0x5637f94bb978 path/filepath.Walk(0xc000148360, 0x55, 0xc000291200, 0x5637f984502e, 0x1) /usr/lib/golang/src/path/filepath/path.go:404 +0x107 fp=0xc000123400 sp=0xc0001233a0 pc=0x5637f94bbde7 github.com/gofed/symbols-extractor/pkg/util.(*PackageInfoCollector).Collect…, 0x7ffc75da495f, 0x14, 0x7ffc75da495f, 0x14) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/_build/src/github.com/gofed/symbols-extractor/pkg/util/util.go:139 +0x15a fp=0xc000123478 sp=0xc000123400 pc=0x5637f982a04a main.main.func1(0xc000293a40, 0x0, 0x0) /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/_build/src/github.com/gofed/symbols-extractor/cmd/golist/golist.go:73 +0x5d4 fp=0xc000123610 sp=0xc000123478 pc=0x5637f9842dc4 runtime.call32(0xc000271c50, 0x5637f9a7a920, 0xc0002911c0, 0x800000018) /usr/lib/golang/src/runtime/asm_amd64.s:522 +0x3d fp=0xc000123640 sp=0xc000123610 pc=0x5637f93eb86d reflect.Value.call(0x5637f99dc2a0, 0x5637f9a7a920, 0x13, 0x5637f98458ed, 0x4, 0xc0001239f0, 0x1, 0x1, 0xc0000aa200, 0xc000293a40, ...) /usr/lib/golang/src/reflect/value.go:447 +0x44b fp=0xc000123908 sp=0xc000123640 pc=0x5637f941bc2b reflect.Value.Call(0x5637f99dc2a0, 0x5637f9a7a920, 0x13, 0xc0001239f0, 0x1, 0x1, 0x2, 0x2, 0x1) /usr/lib/golang/src/reflect/value.go:308 +0xa6 fp=0xc000123970 sp=0xc000123908 pc=0x5637f941b6a6 github.com/urfave/cli.HandleAction(0x5637f99dc2a0, 0x5637f9a7a920, 0xc000293a40, 0x0, 0x0) /usr/share/gocode/src/github.com/urfave/cli/app.go:482 +0x1fa fp=0xc000123a18 sp=0xc000123970 pc=0x5637f983365a github.com/urfave/cli.(*App).Run(0xc0000f2480, 0xc0000a8120, 0x6, 0x6, 0x0, 0x0) /usr/share/gocode/src/github.com/urfave/cli/app.go:240 +0x481 fp=0xc000123bc8 sp=0xc000123a18 pc=0x5637f98317d1 main.main() /builddir/build/BUILD/symbols-extractor-9f4330a0f4437ca61ba92f9f30e34424c6742ad6/_build/src/github.com/gofed/symbols-extractor/cmd/golist/golist.go:125 +0x793 fp=0xc000123f98 sp=0xc000123bc8 pc=0x5637f9842613 runtime.main() /usr/lib/golang/src/runtime/proc.go:201 +0x20f fp=0xc000123fe0 sp=0xc000123f98 pc=0x5637f93c1f1f runtime.goexit() /usr/lib/golang/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc000123fe8 sp=0xc000123fe0 pc=0x5637f93ed5d1 goroutine 2 [force gc (idle)]: runtime.gopark(0x5637f9a7afe0, 0x5637f9dbdcb0, 0x1410, 0x1) /usr/lib/golang/src/runtime/proc.go:302 +0xf1 fp=0xc000046f80 sp=0xc000046f60 pc=0x5637f93c2311 runtime.goparkunlock(0x5637f9dbdcb0, 0x1410, 0x1) /usr/lib/golang/src/runtime/proc.go:308 +0x55 fp=0xc000046fb0 sp=0xc000046f80 pc=0x5637f93c23c5 runtime.forcegchelper() /usr/lib/golang/src/runtime/proc.go:251 +0xb7 fp=0xc000046fe0 sp=0xc000046fb0 pc=0x5637f93c2187 runtime.goexit() /usr/lib/golang/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc000046fe8 sp=0xc000046fe0 pc=0x5637f93ed5d1 created by runtime.init.5 /usr/lib/golang/src/runtime/proc.go:240 +0x37 goroutine 3 [GC sweep wait]: runtime.gopark(0x5637f9a7afe0, 0x5637f9dbdf40, 0x5637f93b140c, 0x1) /usr/lib/golang/src/runtime/proc.go:302 +0xf1 fp=0xc000047780 sp=0xc000047760 pc=0x5637f93c2311 runtime.goparkunlock(0x5637f9dbdf40, 0x5637f98d140c, 0x1) /usr/lib/golang/src/runtime/proc.go:308 +0x55 fp=0xc0000477b0 sp=0xc000047780 pc=0x5637f93c23c5 runtime.bgsweep(0xc000028070) /usr/lib/golang/src/runtime/mgcsweep.go:52 +0x93 fp=0xc0000477d8 sp=0xc0000477b0 pc=0x5637f93b5223 runtime.goexit() /usr/lib/golang/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc0000477e0 sp=0xc0000477d8 pc=0x5637f93ed5d1 created by runtime.gcenable /usr/lib/golang/src/runtime/mgc.go:216 +0x5a goroutine 18 [finalizer wait]: runtime.gopark(0x5637f9a7afe0, 0x5637f9ddcdc0, 0x140f, 0x1) /usr/lib/golang/src/runtime/proc.go:302 +0xf1 fp=0xc000042728 sp=0xc000042708 pc=0x5637f93c2311 runtime.goparkunlock(0x5637f9ddcdc0, 0x140f, 0x1) /usr/lib/golang/src/runtime/proc.go:308 +0x55 fp=0xc000042758 sp=0xc000042728 pc=0x5637f93c23c5 runtime.runfinq() /usr/lib/golang/src/runtime/mfinal.go:175 +0x9d fp=0xc0000427e0 sp=0xc000042758 pc=0x5637f93acb0d runtime.goexit() /usr/lib/golang/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc0000427e8 sp=0xc0000427e0 pc=0x5637f93ed5d1 created by runtime.createfing /usr/lib/golang/src/runtime/mfinal.go:156 +0x63 goroutine 19 [syscall]: runtime.notetsleepg(0x5637f9ddd1c0, 0xffffffffffffffff, 0x5637f9843f60) /usr/lib/golang/src/runtime/lock_futex.go:227 +0x3b fp=0xc000046788 sp=0xc000046758 pc=0x5637f939fffb os/signal.signal_recv(0x0) /usr/lib/golang/src/runtime/sigqueue.go:139 +0x9e fp=0xc0000467b0 sp=0xc000046788 pc=0x5637f93d65be os/signal.loop() /usr/lib/golang/src/os/signal/signal_unix.go:23 +0x24 fp=0xc0000467e0 sp=0xc0000467b0 pc=0x5637f952f254 runtime.goexit() /usr/lib/golang/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc0000467e8 sp=0xc0000467e0 pc=0x5637f93ed5d1 created by os/signal.init.0 /usr/lib/golang/src/os/signal/signal_unix.go:29 +0x43 goroutine 35 [chan receive]: runtime.gopark(0x5637f9a7afe0, 0xc00001e958, 0xc00003170d, 0x3) /usr/lib/golang/src/runtime/proc.go:302 +0xf1 fp=0xc000042ea0 sp=0xc000042e80 pc=0x5637f93c2311 runtime.goparkunlock(0xc00001e958, 0x170d, 0x3) /usr/lib/golang/src/runtime/proc.go:308 +0x55 fp=0xc000042ed0 sp=0xc000042ea0 pc=0x5637f93c23c5 runtime.chanrecv(0xc00001e900, 0xc000042fb0, 0xc0001c4001, 0xc00001e900) /usr/lib/golang/src/runtime/chan.go:520 +0x2c2 fp=0xc000042f60 sp=0xc000042ed0 pc=0x5637f939b1c2 runtime.chanrecv2(0xc00001e900, 0xc000042fb0, 0xc000148058) /usr/lib/golang/src/runtime/chan.go:407 +0x2b fp=0xc000042f90 sp=0xc000042f60 pc=0x5637f939aeeb github.com/golang/glog.(*loggingT).flushDaemon(0x5637f9dbea80) /usr/share/gocode/src/github.com/golang/glog/glog.go:882 +0x8d fp=0xc000042fd8 sp=0xc000042f90 pc=0x5637f95eae0d runtime.goexit() /usr/lib/golang/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc000042fe0 sp=0xc000042fd8 pc=0x5637f93ed5d1 created by github.com/golang/glog.init.0 /usr/share/gocode/src/github.com/golang/glog/glog.go:410 +0x205 goroutine 4 [syscall]: runtime.notetsleepg(0x5637f9dc3500, 0x6fc23484b, 0x0) /usr/lib/golang/src/runtime/lock_futex.go:227 +0x3b fp=0xc000047f58 sp=0xc000047f28 pc=0x5637f939fffb runtime.timerproc(0x5637f9dc34e0) /usr/lib/golang/src/runtime/time.go:288 +0x312 fp=0xc000047fd8 sp=0xc000047f58 pc=0x5637f93de7a2 runtime.goexit() /usr/lib/golang/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc000047fe0 sp=0xc000047fd8 pc=0x5637f93ed5d1 created by runtime.(*timersBucket).addtimerLocked /usr/lib/golang/src/runtime/time.go:170 +0x116 ``` `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/8

2 5

[golist] Issue #1: golist relies on an obsolete release of gopkg.in/urfave/cli.v1 (1.18) and does not work with the current one (1.20)
by Nicolas Mailhot 10 Apr '19

10 Apr '19

nim reported a new issue against the project: `golist` that you are following: `` golist relies on an obsolete release of gopkg.in/urfave/cli.v1 (1.18) and does not work with the current one (1.20) + go build -buildmode pie -compiler gc '-tags=rpm_crashtraceback ' -ldflags ' -X github.com/gofed/symbols-extractor/version.commit=aecba475bf76f5269c11367da… -X github.com/gofed/symbols-extractor/version=0 -B 0x53a515e8225a08687fb15659311c31138f10deef -extldflags '\''-Wl,-z,relro '\''' -a -v -x -o _bin/golist github.com/gofed/symbols-extractor/cmd/golist … cd /builddir/build/BUILD/symbols-extractor-aecba475bf76f5269c11367da0a190419cd9a133/_build/src/github.com/gofed/symbols-extractor/cmd/golist /usr/lib/golang/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -shared -p main -complete -installsuffix shared -buildid W7hFQx2bLlwdklLGWaGL/W7hFQx2bLlwdklLGWaGL -goversion go1.10 -D "" -importcfg $WORK/b001/importcfg -pack ./golist.go # github.com/gofed/symbols-extractor/cmd/golist cmd/golist/golist.go:25:40: cannot use nil as type string in field value cmd/golist/golist.go:25:68: cannot use "" (type string) as type bool in field value cmd/golist/golist.go:25:72: cannot use false (type bool) as type *cli.StringSlice in field value cmd/golist/golist.go:26:41: cannot use nil as type string in field value cmd/golist/golist.go:26:74: cannot use "" (type string) as type bool in field value cmd/golist/golist.go:26:78: cannot use false (type bool) as type *cli.StringSlice in field value cmd/golist/golist.go:27:42: cannot use nil as type string in field value cmd/golist/golist.go:27:87: cannot use "" (type string) as type bool in field value cmd/golist/golist.go:27:91: cannot use false (type bool) as type *cli.StringSlice in field value cmd/golist/golist.go:28:61: cannot use "" (type string) as type bool in field value cmd/golist/golist.go:28:61: too many errors `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/1

3 9

[golist] Issue #9: incomplete import detection for tests
by Nicolas Mailhot 31 Jan '19

31 Jan '19

nim reported a new issue against the project: `golist` that you are following: `` ```sh $ golist --imported --package-path github.com/sirupsen/logrus --skip-self --tests ``` only outputs ``` github.com/stretchr/testify/assert ``` for sirupsen logrus, when the terminal_check_notappengine.go test imports ``` golang.org/x/crypto/ssh/terminal ```` `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/9

2 5

[golist] Issue #10: unexpected directory layout (whatever that means)
by Nicolas Mailhot 31 Jan '19

31 Jan '19

nim reported a new issue against the project: `golist` that you are following: `` golist fails to output project go files on github.com/rubiojr/go-vhd ```sh Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.NZHyXq + umask 022 + cd /builddir/build/BUILD + '[' /builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64 '!=' / ']' + rm -rf /builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64 ++ dirname /builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64 + mkdir -p /builddir/build/BUILDROOT + mkdir /builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64 + cd go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b + go-rpm-integration install -i github.com/rubiojr/go-vhd -s /builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b -b /builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/_build -o devel.file-list -p /builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64 -g /usr/share/gocode -r '.*example.*' install: creating directory '/builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64/usr' install: creating directory '/builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64/usr/share' install: creating directory '/builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64/usr/share/gocode' install: creating directory '/builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64/usr/share/gocode/src' Installing: github.com/rubiojr/go-vhd install: creating directory '/builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/_build' install: creating directory '/builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/_build/src' install: creating directory '/builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/_build/src/github.com' install: creating directory '/builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/_build/src/github.com/rubiojr' 2018/03/23 16:49:12 unexpected directory layout: import path: _/builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/_bui… root: /builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/_build/src dir: /builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/_build/src/github.com/rubiojr/go-vhd/vhd expand root: /builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/_build/src expand dir: /builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/vhd separator: / install: creating directory '/builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64/usr/share/gocode/src/github.com' install: creating directory '/builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64/usr/share/gocode/src/github.com/rubiojr' install: creating directory '/builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64/usr/share/gocode/src/github.com/rubiojr/go-vhd' '/builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/notes.md' -> '/builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64/usr/share/gocode/src/github.com/rubiojr/go-vhd/notes.md' '/builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/README.md' -> '/builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64/usr/share/gocode/src/github.com/rubiojr/go-vhd/README.md' '/builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/.goipath' -> '/builddir/build/BUILDROOT/golang-github-rubiojr-vhd-0-0.1.4.20180320git0bfd3b3.el7.llt.x86_64/usr/share/gocode/src/github.com/rubiojr/go-vhd/.goipath' '/builddir/build/BUILD/go-vhd-0bfd3b39853cdde5762efda92289f14b0ac0491b/.goflags' -> '/builddir/build ``` After much investigation in https://github.com/gofed/symbols-extractor/issues/147 it seems triggered by the `./vhd` in ```go package main import ( "./vhd" "fmt" ... ) ``` https://github.com/rubiojr/go-vhd/blob/master/cli.go#L4 `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/10

2 2

[golist] Issue #6: didn't find "github.com/google/go-cmp/cmp"
by Nicolas Mailhot 31 Jan '19

31 Jan '19

nim reported a new issue against the project: `golist` that you are following: `` Migrated from https://github.com/gofed/symbols-extractor/issues/158 When I use golist in the project cloud.google.com/go, the commands ```sh golist --imported --package-path cloud.google.com/go --skip-self golist --imported --package-path cloud.google.com/go --skip-self --tests ``` don't find the package "github.com/google/go-cmp/cmp" in the unit test cloud.google.com/go/civil `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/6

2 3

Skipping the 26th Dec Go -SIG meeting
by Jakub Cajka 22 Dec '18

22 Dec '18

Hello, I propose to skip the next meeting as I will be unavailable to chair that meeting. 26th is a public holiday in CZ and I will be 100% offline on that day. JC

1 0

[Fedocal] Reminder meeting : Go SIG Meeting
by jcajka＠fedoraproject.org 21 Dec '18

21 Dec '18

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

2 1

[golist] Issue #11: golist should permit identifying Go packages that import a specific import path
by Nicolas Mailhot 04 Dec '18

04 Dec '18

nim reported a new issue against the project: `golist` that you are following: `` This is a continuation and modernization of https://github.com/gofed/go-macros/issues/35 When bootstrapping a set of Go projects, with circular dependencies, you need to identify quickly the parts that participate in the loop, so they can be culled in the initial bootstrap package For example if `docker-x` depends directly or indirectly on `docker-y`, and `docker-y` imports `docker-x` in its own code (or tests), you want to identify the `docker-x` parts that use `docker-y` and remove them in `%prep`. And then, once the result is built, and permits an initial built of `docker-y`, you can use the resulting `docker-y` to build `docker-x` without removing anything This could be done by adding a `-x` `--exclude-import-path` switch to golist. The switch can occur several times, to specify several exclusions in one pass, as some codebases participate in several loops at once `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/11

1 0

[golist] Issue #5: [RFE] list buildable commands in a Go project
by Nicolas Mailhot 04 Dec '18

04 Dec '18

nim reported a new issue against the project: `golist` that you are following: `` It would be awfully nice if `golist` had a mode that outputed, for every path that can be built as a binary: * the buildable path * a separator that can not occur in paths * the expected command output name (via heuristics if necessary) The result could then be fed to `%gobuild` by [go-rpm-macros](https://pagure.io/go-rpm-macros/) `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/5

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang December 2018