March 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

[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] 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] 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 #18: Golist should work without $GOPATH from any directory
by Robert-André Mauchin 17 Apr '19

17 Apr '19

eclipseo reported a new issue against the project: `golist` that you are following: `` $GOPATH is deprecated, we shouldn't use it anymore. `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/18

3 2

[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] PR #17: Replace Go internals with go/build
by Elliott Sales de Andrade 10 Apr '19

10 Apr '19

qulogic opened a new pull-request against the project: `golist` that you are following: `` Replace Go internals with go/build `` To reply, visit the link below or just reply to this email https://pagure.io/golist/pull-request/17

2 6

[golist] PR #16: Fix compile against latest urfave/cli.
by Elliott Sales de Andrade 09 Apr '19

09 Apr '19

qulogic opened a new pull-request against the project: `golist` that you are following: `` Fix compile against latest urfave/cli. `` To reply, visit the link below or just reply to this email https://pagure.io/golist/pull-request/16

1 1

go2rpm
by Robert-André Mauchin 01 Apr '19

01 Apr '19

Hello, I have written go2rpm, based off rust2rpm, to convert Go packages to RPM. It is available here: https://pagure.io/GoSIG/go2rpm It needs code review and extensive testing, as I am a Python noob. Please send merge requests. Best regards, Robert-André

3 4

New Golang Packaging Guidelines: Feedback needed and appreciated
by Robert-André Mauchin 27 Mar '19

27 Mar '19

Hello Fedora people, As you may or may not know, currently applied Golang packaging guidelines have always been simply a « draft ». Part of the new Go SIG mission is to update ours best practices and tooling. As such, Nicolas Mailhot designed a new set of macros based on lua script to improve our current situation. As a result, we needed to draft new guidelines to reflect the future implementation of these macros. I have written these new guidelines and I'd like to ask for your help in order to review them: both from current Go SIG packagers point of view and from novices in the matter, in order to make sure they are clear and understandable enough for everyone. I have uploaded a mirror of the Guidelines on my FedoraPeople space: https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/ Please, if you have 10 mn to spare, read them and send me feedback. If you wish you can also directly send me a Merge Request on Pagure: https://pagure.io/fork/eclipseo/packaging-committee/ (branch implement_golang_guidelines). Best regards, Robert-André

4 3

New time slot for the Go SIG meeting
by Jakub Cajka 27 Mar '19

27 Mar '19

Hello, we agreed to find better time slot for our meeting on our last meeting as is seems that the current slot is no good anymore. I have created new poll to find better one. https://framadate.org/QX6R7hxJ2mM6HO8m Time is in the UTC and don't pay attention to the day dates as this is just to illustrate a week. Along with the change of the slot I would like to propose to change the cadence of the meeting to bi-weekly(every 2 weeks, from current, every 3 weeks). If you want it to be held more often or less please say so. JC

1 0

Re: [golang-dev] proposal: public module authentication with the Go notary
by Nicolas Mailhot 27 Mar '19

27 Mar '19

Le jeudi 14 mars 2019 à 11:49 +0100, Nicolas Mailhot a écrit : > Le 2019-03-13 20:33, thepudds1460(a)gmail.com a écrit : > > > > However, even in advance of that, I have seen different people put > > together one-off shell scripts or similar that are capable of > > putting > > a properly formed entry into the module cache such that it can be > > used > > by GOPROXY=file://your/path. For example: > > https://github.com/komuw/goproxy/blob/master/goproxy.sh#L71 > > And I have my own (unpublished incomplete and unfinished) code to > try doing the same thing. Not elegant code I'm especially proud of, > just quick and dirty “get it to work before august” code. Anyway here is the code, not finished, not feature-complete, very lightly tested, but already doing some useful things https://pagure.io/modist/ You can add it to your collection of code that tries to do things with Go modules. That shows up pretty clearly that what should have been a very light and thin wrapping of go upstream module tools, with some custom code to translate go version syntax to rpm version syntax, is anything but light and thin, and requires digging deeply in internal go code, and extrapolating from go help messages. (for example the very light testing I did this afternoon shows that go version strings do not pass the roundtrip test, so either I can not wrap my head around go module pseudoversion documentation, or the go tool is doing something else than what is documented, or a mix of both). A thick compatibility layer (not calling directly high-level exported APIs or go commands) basically means there is a high risk of future divergence and incompatibility. And the published code still needs to grow a command to generate list files, and it's missing a call to tidy the go.mod content after the module zip content changed, and probably other things I have not identified yet. And, I have no clue how to feed the result to the go build and go test commands in addition to a GOPROXY system directory and the content of the user Go cache, since the whole point is to prepare clean candidate module files, and they can not be mixed in the same directories as other modules while this processed is not finished. But my cunning plan right now is to focus on creating and inspecting modules, and just let Jakub deal with the compiler-side problems in Fedora. I don't have enough braincells left to do both at once. And I still need to write the matching adaptation layer rpm-side, which Jakub won't do. Regards, -- Nicolas Mailhot

2 5

Review swaps (Golang packages)
by Robert-André Mauchin 25 Mar '19

25 Mar '19

Hello, I'd like some help to review my packages, I'll review anything in exchange: Review Request: golang-github-anacrolix-dms - A UPnP DLNA Digital Media Server that includes basic video transcoding https://bugzilla.redhat.com/show_bug.cgi?id=1684956 Review Request: golang-github-mattn-pointer - Utility for cgo https://bugzilla.redhat.com/show_bug.cgi?id=1692344 Review Request: golang-github-mattn-gtk - Go binding for GTK https://bugzilla.redhat.com/show_bug.cgi?id=1692376 Review Request: golang-github-grpc-ecosystem-middleware - Golang gRPC Middlewares: interceptor chaining, auth, logging, retries and more https://bugzilla.redhat.com/show_bug.cgi?id=1689006 Review Request: golang-uber-zap - Blazing fast, structured, leveled logging in Go https://bugzilla.redhat.com/show_bug.cgi?id=1688984 Review Request: golang-github-tmc-grpc-websocket-proxy - A proxy to transparently upgrade grpc-gateway streaming endpoints to use websockets https://bugzilla.redhat.com/show_bug.cgi?id=1688944 Review Request: golang-github-armon-consul-api - Golang API client for Consul https://bugzilla.redhat.com/show_bug.cgi?id=1688881 Review Request: golang-contrib-opencensus-exporter-ocagent - OpenCensus Go exporters for OpenCensus Agent https://bugzilla.redhat.com/show_bug.cgi?id=1687159 Review Request: golang-github-gomodule-redigo - Go client for Redis https://bugzilla.redhat.com/show_bug.cgi?id=1645286 Review Request: golang-github-snappy - Implementation of the Snappy compression format for Go https://bugzilla.redhat.com/show_bug.cgi?id=1643993 Review Request: golang-github-eapache-xerial-snappy - Xerial-compatible Snappy framing support for golang https://bugzilla.redhat.com/show_bug.cgi?id=1643996 Thanks for the help! Robert-André

1 0

[NEEDINFO from nim] New Go macros: disambiguation between goipaths / goaltipaths
by Robert-André Mauchin 21 Mar '19

21 Mar '19

Nim, Can you explain in what context would goipaths be used? What's the difference with goaltipaths? From what I tested: - goipaths will install several import paths into the same devel package - goaltipaths will generate compat-devel packages in care of renames etc. I don't understand in what use cases goipaths should be used. I don't recall ever seeing a Go source package with two import paths at the same time. Even so, why would we install both in the same devel package, instead of making one package for each import path. Can you shed a light on what is the intended use? Thanks, Robert-André

2 4

[go-rpm-macros] PR #8: Fix missing variable in license detection
by Robert-André Mauchin 21 Mar '19

21 Mar '19

eclipseo opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Fix missing variable in license detection `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/8

2 2

Fwd: [security] Vulnerability in golang.org/x/crypto/salsa20
by Jakub Cajka 21 Mar '19

21 Mar '19

FYI it seems there has been discovered security vulnerability in the golang-googlecode-go-crypto package. Hopefully we will have tracking BZ shortly. JC ----- Forwarded Message ----- From: "Filippo Valsorda" <filippo(a)golang.org> To: golang-nuts(a)googlegroups.com Sent: Wednesday, March 20, 2019 11:53:53 PM Subject: [security] Vulnerability in golang.org/x/crypto/salsa20 Hello gophers, Commit b7391e95 <https://go.googlesource.com/crypto/+/b7391e95e576cacdcdd422573063bc05723911…> fixes a vulnerability in the amd64 implementation of the golang.org/x/crypto/salsa20 and golang.org/x/crypto/salsa20/salsa packages that affects large message sizes or high counter values. If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications. The issue might affect uses of golang.org/x/crypto/nacl with extremely large messages. Architectures other than amd64 and uses that generate less than 256 GiB of keystream for a single salsa20.XORKeyStream <http://godoc.org/golang.org/x/crypto/salsa20#XORKeyStream> invocation are unaffected. The vulnerable code is derived from the amd64-xmm5 and amd64-xmm6 implementations that are distributed with SUPERCOP <https://bench.cr.yp.to/supercop.html>, NaCl <https://nacl.cr.yp.to/> and at https://cr.yp.to/snuffle.html. The issue is present in those upstreams, but is not considered a problem by their author because of the policy at https://nacl.cr.yp.to/valid.html, and because support for counters larger than 32 bits is an incomplete experiment. We attach a patch that applies to the amd64-xmm5 and amd64-xmm6 salsa20.s files for any downstream that might want to fix this issue. This issue was discovered and reported by Michael McLoughlin. Cheers, Filippo for the Go team -- You received this message because you are subscribed to the Google Groups "golang-announce" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-announce+unsubscribe(a)googlegroups.com. For more options, visit https://groups.google.com/d/optout.

1 0

Re: [golang-dev] proposal: public module authentication with the Go notary
by Jakub Cajka 19 Mar '19

19 Mar '19

----- Original Message ----- > From: "Sam Whited" <sam(a)samwhited.com> > To: "rprichard via golang-dev" <golang-dev(a)googlegroups.com> > Sent: Monday, March 4, 2019 7:06:37 PM > Subject: Re: [golang-dev] proposal: public module authentication with the Go notary > > TL;DR — Right now when fetching a module Google isn't involved, and I'd > like it to stay that way. Please let me configure and use different > notaries without also using a proxy. > > > There is no plan to allow use of alternate notaries, which would add > > complexity and potentially reduce the overall security of the system, > > allowing different users to be attacked by compromising different > > notaries. > > If you're somewhere that Google doesn't service (eg. due to U.S. export > laws) does this mean you're entirely out of luck and can't use the new > security features? It seems unfortunate that a developer in Iran would > have to fall back to the TOFU model just because Google decided to bless > themselves and not allow anyone else to run a notary or jump through > extra hoops to configure or run a proxy. > > > We originally considered having multiple notaries signing individual > > go.sum entries and requiring the go command to collect signatures from > > a quorum of notaries before accepting an entry. That design depended > > on the uptime of multiple services and could still be compromised > > undetectably by compromising enough notaries. That is, that design > > would blindly trust a quorum of notaries. > > This seems strictly superior to blindly trusting a single notary. Why > does Google think it will be more secure than Google and Mozilla, or > Google and Microsoft, or Google and <your company>? > > As far as uptime is concerned, you're always limited to the uptime of > your least available notary, I don't necessarily think Google's uptime > will be any better than any other large company that might choose to run > a notary, so that seems fine: I have the option of trusting only > notaries with high availability, meaning that it's likely no worse than > if I just trusted Google. > > > The design presented here uses the transparent log eliminates blind > > trust in a quorum of notaries and instead uses a “trust but verify” > > model with a single notary. > > We could also "trust but verify" a quorum of notaries, so this seems > like a false dichotomy. > > On a more personal note, having a non-Google controlled notary seems > like an absolute requirement to me and I would prefer to avoid using a > Google run service entirely if possible. Google doesn't need to know > anything about what modules my company is using. I do appreciate the > privacy section, which addresses this, but tying the notary use to using > a proxy or running your own proxy is likely out of reach for many > individuals (including me). > > —Sam I have a similar fears and worries here. First thing that popped on my mind(personally as a external observer) this is a move of Google to fully productize(data mine) a Go users community(for very limited payback), even if it is not a main driver it will make it irresistibly easy to do so(with google hosted notary). IMHO this feature should be opt-in and the actual default instance of the notary should be run by trustworthy and independent 3rd party(ideally NPO) with clear and transparent privacy policy and on community accessible infrastructure(so a community members can actually participate in the maintenance and verify policies surrounding it, i.e. not like a current Go infra is run, only Google employees can contribute/touch it). As I will carefully evaluate all the details of the final implementation, but from this first look I'm currently leaning to "patch out" or de-configure by default this feature in Fedora when/if it lands in upstream GC, to preserve the privacy of the users. JC PS: This is just my personal Fedora's GC maintainer take on this issue. > > On Mon, Mar 4, 2019, at 17:32, Russ Cox wrote: > > Hi all, > > > > I wanted to let people here know about the proposal design we just > > published: golang.org/design/25530-notary, for golang.org/issue/25530. > > (We also mentioned this general idea in our blog post from back in > > December, https://blog.golang.org/modules2019.) > > > > As usual, comments are welcome on the issue or, if you prefer not to > > use the issue tracker, here in this thread. > > > > Thanks. Russ > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups "golang-dev" group. To unsubscribe from this group and stop > > receiving emails from it, send an email to golang- > > dev+unsubscribe(a)googlegroups.com. For more options, visit > > https://groups.google.com/d/optout. > > -- > Sam Whited > > -- > You received this message because you are subscribed to the Google Groups > "golang-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-dev+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/d/optout. >

11 38

Glide.lock folder mess
by Robert-André Mauchin 19 Mar '19

19 Mar '19

Hi! Numerous Golang packages are plagued with an issue caused when jchaloup uploaded Glide files. In a lot of case he has doubled the glide.yaml instead of adding the qlide.lock: Source1: glide.yaml Source2: glide.yaml The problem is that when goinstall doesn't find the glide.lock file: %goinstall glide.lock glide.yaml it creates a folder instead. Now when we try to fix the problem by re-adding the glide.lock file to the Sources, we are asking RPM to replace a folder by a file at update time, which it refuses to do so to avoid losing data the user might have placed there. We get errors like: Error: Transaction check error: file /usr/share/gocode/src/github.com/mitchellh/go-homedir/glide.lock from install of golang-github-mitchellh-go-homedir-devel-1.1.0-1.fc29.noarch conflicts with file from package golang-github-mitchellh-go-homedir-devel-0-0.10.20180708gitdf55a15.fc29.noarch This is a PITA. the only workaround it to add a %pretrans lua macro to deal with the mess. # Remove in F33 # Remove erroneous glide.lock folder %pretrans devel -p <lua> path = "%{gopath}/src/%{goipath}/glide.lock" st = posix.stat(path) if st and st.type == "directory" then os.remove(path) end See https://fedoraproject.org/wiki/Packaging:Directory_Replacement#Scriptlet_to… I have no idea how many packages are affected. But it's more work on our already full plates. Best regards, Robert-André

3 6

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

13 Mar '19

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

Review Request Was: [Go-sig] [Bug 1687093] golang-github-azure-autorest-11.5.1 is available
by Robert-André Mauchin 10 Mar '19

10 Mar '19

Hey, I need a volunteer to review golang-contrib-opencensus-exporter-ocagent needed to update golang-github-azure-autorest. Thanks! On dimanche 10 mars 2019 15:06:24 CET bugzilla(a)redhat.com wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1687093 > > Robert-André Mauchin <zebob.m(a)gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Depends On| |1687159 > > > > > Referenced Bugs: > > https://bugzilla.redhat.com/show_bug.cgi?id=1687159 > [Bug 1687159] Review Request: golang-contrib-opencensus-exporter-ocagent - > OpenCensus Go exporters for OpenCensus Agent > --

1 0

Looking for volunteers for a handful of Go package reviews
by Robert-André Mauchin 03 Mar '19

03 Mar '19

Hello, I have several Go packages in need of a review for the latest Rclone version. I'm available for any review in exchange. - golang-github-anacrolix-dms https://bugzilla.redhat.com/show_bug.cgi?id=1684956 - golang-github-anacrolix-ffprobe https://bugzilla.redhat.com/show_bug.cgi?id=1684950 - golang-github-anacrolix-envpprof https://bugzilla.redhat.com/show_bug.cgi?id=1684936 - golang-github-anacrolix-missinggo https://bugzilla.redhat.com/show_bug.cgi?id=1684940 - golang-github-RoaringBitmap-roaring https://bugzilla.redhat.com/show_bug.cgi?id=1684934 - golang-github-glycerine-go-unsnap-stream https://bugzilla.redhat.com/show_bug.cgi?id=1684906 - golang-github-mschoch-smat https://bugzilla.redhat.com/show_bug.cgi?id=1684924 - golang-github-tinylib-msgp https://bugzilla.redhat.com/show_bug.cgi?id=1684919 - golang-github-philhofer-fwd https://bugzilla.redhat.com/show_bug.cgi?id=1684908 - golang-github-ttacon-chalk https://bugzilla.redhat.com/show_bug.cgi?id=1684909 - golang-github-willf-bitset https://bugzilla.redhat.com/show_bug.cgi?id=1684925 - golang-github-anacrolix-tagflag https://bugzilla.redhat.com/show_bug.cgi?id=1684948 - golang-github-bradfitz-iter https://bugzilla.redhat.com/show_bug.cgi?id=1684933 - golang-github-docopt https://bugzilla.redhat.com/show_bug.cgi?id=1684938 - golang-github-huandu-xstrings https://bugzilla.redhat.com/show_bug.cgi?id=1684929 - golang-github-ryszard-goskiplist https://bugzilla.redhat.com/show_bug.cgi?id=1684927 Thanks to all! Robert-André

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang March 2019