April 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 16 Jun '19

16 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 07 May '19

07 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 07 May '19

07 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 07 May '19

07 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 07 May '19

07 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 07 May '19

07 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 07 May '19

07 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

Re: [golang-dev] Try our new module mirror!
by Jakub Cajka 30 Apr '19

30 Apr '19

----- Original Message ----- > From: "Katie Hockman" <katie(a)golang.org> > To: golang-dev(a)googlegroups.com > Sent: Monday, April 29, 2019 10:35:38 PM > Subject: [golang-dev] Try our new module mirror! > > Hey Gophers! > > In the blog post Go Modules in 2019 <https://blog.golang.org/modules2019>, > we announced our intent to provide a module mirror for accelerating Go > module downloads, an index for discovering new modules, and a checksum > database for authenticating module content. > > We are excited to share that we are ready for developers to start alpha > testing our module mirror, index, and checksum database! > > Our privacy policy explains how we collect and use your information. The > privacy policy for all of these services is proxy.golang.org/privacy. Hello, if I'm not mistaken the page that you are linking for privacy information of the proxy seems not related to it at all. It looks like some sort of generic terms that Google is using for all of its services. It is not describing what is collected and what for, how and where it is retained and stored, etc. in context of the proxy/this new google service. Could you expand on these topics in actual go proxy context, please? What are you collecting/are you planning on collecting and what for? > > The module mirror at proxy.golang.org serves the go command’s proxy > protocol. To make the go command use it (when in module mode), set GOPROXY= > https://proxy.golang.org. > > The module index at index.golang.org serves a feed of module versions in > the order they are discovered. For example, see > https://index.golang.org/index?since=2019-03-04T18:00:15.161182-07:00 > > The module checksum database at sum.golang.org serves the URLs described in > the Secure the Public Go Module Ecosystem > <https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md> With brief look on the proposal, just from the technical perspective(kind of including modules too). Little has changed from my perspective since the initial proposal. I'm still worried that I will have to disabled/de-configured or at worst case scenario even patch it (out) to make our build system in Fedora work with Go sources that we are curating/shipping/using(i.e. occasional need to carry downstream/backport patches). Leaving out for now the privacy/MITM concerns which look nearly the same(i.e. IMHO not resolved) as previously. > proposal. If you use the Go 1.13 development version of the go command, > setting GOPROXY=https://proxy.golang.org will automatically use the > checksum database as well. To use the checksum database to protect other > code downloads, set GOSUMDB=sum.golang.org explicitly. See the development > version go command docs > <https://tip.golang.org/cmd/go/#hdr-Module_authentication_failures> for > details. If you are using Go 1.12 or earlier, you can manually check a > go.sum file against the checksum database with gosumcheck > <https://godoc.org/golang.org/x/exp/sumdb/gosumcheck>: > > go get golang.org/x/exp/sumdb/gosumcheck > > gosumcheck /path/to/go.sum > > We hope you’ll try out these new services! Note that these are in the early > stages, so even though we don’t have any planned outages, you should > recognize it is an alpha release and instability and bugs are expected. > We’ll be actively working through these and improving our services, so > please file issues <https://github.com/golang/go/issues/new> if you spot > them, with the title prefix “proxy.golang.org:” (or index.golang.org, or > sum.golang.org) We look forward to hearing about how it’s working for you! > > Cheers, > > Katie Hockman Is there anywhere a place where I or anyone else could pull the sources and contribute to all of these new Go features/services that you are deploying/running, or so I/anyone could potentially even run my own instances of proxy.golang.org, sum.golang.org and index.golang.org and help with devel? Thanks for any info. Sorry if I have missed some details. JC > > -- > 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. >

1 0

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

28 Apr '19

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

[go-rpm-macros] PR #9: Use relative symlinks for goalts; workarounds https://pagure.io/golist/issue/12 https://github.com/rpm-software-management/rpm/issues/671
by Nicolas Mailhot 19 Apr '19

19 Apr '19

nim opened a new pull-request against the project: `go-rpm-macros` that you are following: `` Use relative symlinks for goalts; workarounds https://pagure.io/golist/issue/12 https://github.com/rpm-software-management/rpm/issues/671 `` To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/pull-request/9

1 1

[golist] PR #20: Add ignored Go files install list
by Elliott Sales de Andrade 18 Apr '19

18 Apr '19

qulogic opened a new pull-request against the project: `golist` that you are following: `` Add ignored Go files install list `` To reply, visit the link below or just reply to this email https://pagure.io/golist/pull-request/20

4 7

[golist] Issue #21: Overhaul CLI
by Elliott Sales de Andrade 18 Apr '19

18 Apr '19

qulogic reported a new issue against the project: `golist` that you are following: `` I don't really like the way the command-line arguments are specified right now. Everything is an optional flag which requires writing out a redundant argument name. This would be even worse with #4. Also, urfave/cli doesn't seem to follow POSIX semantics, which is a bit annoying. I'd rather the CLI look something like: `golist <command> <package-path> [<package path> ...]` where `<command>` is one of the original flags that specified output modes. All the other flags could remain optional. This could maybe be done with `pflag` instead for optional things and just switching commands ourselves. Or maybe using `cobra`. Probably depends on how heavy these things are. `` To reply, visit the link below or just reply to this email https://pagure.io/golist/issue/21

2 2

List of Go packages not under our purview
by Robert-André Mauchin 17 Apr '19

17 Apr '19

As a reminder, I've recomputed the list of packages the SIG has no access to: buildah caddy containerd containernetworking-plugins cri-tools deepin-api deepin-daemon deepin-dbus-generator deepin-gir-generator direnv dnscrypt-proxy docker-distribution geoipupdate git-octopus glusterd2 go-bindata godep gofed golang-deepin-dbus-factory golang-deepin-go-lib golang-github-auth0-go-jwt-middleware golang-github-bep-gitmap golang-github-briandowns-spinner golang-github-bruth-assert golang-github-burntsushi-locker golang-github-BurntSushi-toml-test golang-github-client9-gospell golang-github-collectd-go-collectd golang-github-dchest-siphash golang-github-dgnorton-goback golang-github-dgrijalva-jwt golang-github-elithrar-simple-scrypt golang-github-fatih-set golang-github-fsnotify-fsnotify golang-github-fsouza-go-dockerclient golang-github-git-lfs-gitobj golang-github-git-lfs-netrc golang-github-git-lfs-wildmatch golang-github-gofrs-flock golang-github-gosexy-gettext golang-github-hako-durafmt golang-github-hashicorp-consul-migrate golang-github-hashicorp-version golang-github-jinzhu-now golang-github-karlseguin-ccache golang-github-kurin-blazer golang-github-kyokomi-emoji golang-github-libgit2-git2go golang-github-linuxdeepin-dbus-factory golang-github-linuxdeepin-go-x11-client golang-github-lpabon-godbc golang-github-lucasb-eyer-colorful golang-github-mattn-shellwords golang-github-miekg-mmark golang-github-minio golang-github-mitchellh-hashstructure golang-github-mvo5-goconfigparser golang-github-mvo5-uboot-go golang-github-nicksnyder-i18n golang-github-ojii-gettext.go golang-github-pebbe-zmq4 golang-github-pkg-xattr golang-github-remeh-sizedwaitgroup golang-github-restic-chunker golang-github-sanity-io-litter golang-github-spf13-fsync golang-github-spf13-jwalterweatherman golang-github-stathat-go golang-github-tg-gosortmap golang-github-thomsonreuterseikon-ntlm golang-github-thorduri-libusb golang-github-wellington-libsass golang-github-xlab-handysort golang-github-xrash-smetrics golang-github-yosssi-ace golang-github-yosssi-gohtml golang-gopkg-data-dog-sqlmock-1 golang-gopkg-go-check-check golang-gopkg-go-macaroon-macaroon golang-gopkg-retry-v1 golang-torproject-pluggable-transports-goptlib golang-vbom-util golist gomtree go-rpm-templates gotun heketi hub ignition jid kata-ksm-throttler kata-osbuilder kata-proxy kata-shim kompose manifest-tool mantle micro moby-engine obfs4 oci-kvm-hook oci-register-machine ocitools openvswitch-ovn-kubernetes origin oshinko-cli podman popub powerline-go rclone reg restic rkt runc singularity skopeo startdde swig tmux-top vim-go yubihsm-connector Should be at least convince the libraries owner to give us access? I don't know about he binaries, mine are not withing the SIG yet either. Some big projects like caddy, containerd, openvswitch-ovn-kubernetes, cri- tools probably won't want us to touch their stuff.

2 1

[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

Fwd: Re: Questions regarding our Change proposal: Adopt new Go Packaging Guidelines
by Robert-André Mauchin 16 Apr '19

16 Apr '19

I will request the mass rebuild to Releng when the time has come.

1 0

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

14 Apr '19

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

Golang review swaps
by Robert-André Mauchin 12 Apr '19

12 Apr '19

Hello folks, In order to update a few Golang packages, new dependencies needing to be packaged have appeared. Please, if you have time to help, take a look at these. They are standard Go packages and all have been tested in Koji or COPR. golang-github-getsentry-raven-go → need github.com/certifi/gocertifi https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-certifi-gocertifi golang-github-prometheus-common → need golang-github-mwitkow-conntrack https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-mwitkow-conntrack golang-github-grpc-grpc-go → need golang-github-envoyproxy-control-plane https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-envoyproxy-contro… → need golang-istio-gogo-genproto https://bugzilla.redhat.com/show_bug.cgi?id=golang-istio-gogo-genproto → need golang-github-gogo-googleapis https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-gogo-googleapis → need golang-github-envoyproxy-protoc-gen-validate https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-envoyproxy-protoc… → need golang-github-iancoleman-strcase https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-iancoleman-strcase → need golang-github-lyft-protoc-gen-star https://bugzilla.redhat.com/show_bug.cgi?id= golang-github-hashicorp-serf → golang-github-hashicorp-memberlist → need golang-github-sean-seed https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-sean-seed golang-github-exoscale-egoscale → need golang-github-gofrs-uuid https://bugzilla.redhat.com/show_bug.cgi?id=golang-github-gofrs-uuid go-avif https://bugzilla.redhat.com/show_bug.cgi?id=go-avif I am of course available for any review in exchange. Also take a look at our future guidelines at https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/ and share what you think with us. Best regards, Robert-André

1 0

Golang SIG meeting's new slot
by Jakub Cajka 12 Apr '19

12 Apr '19

Hello, based on the poll https://framadate.org/QX6R7hxJ2mM6HO8m we have decided on this week meeting to move SIG's meeting to new slot on Tue 1600h UTC with first meeting held being next week and then with bi-week cadence. Looking forward to see you all next week, JC

1 0

[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 10 Apr '19

10 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

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

03 Apr '19

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

Re: [Fedora-packaging] Translating Go modules buildrequires in rpm syntax
by Jakub Cajka 03 Apr '19

03 Apr '19

----- Original Message ----- > From: "Nicolas Mailhot" <nicolas.mailhot(a)laposte.net> > To: packaging(a)lists.fedoraproject.org > Sent: Friday, March 29, 2019 8:33:39 PM > Subject: [Fedora-packaging] Translating Go modules buildrequires in rpm syntax > > Hi, > > For Go modules, that will become the default upstream in August, Google > invented holed BuildRequires version ranges: > – anything starting with version > – except a list of specific version exclusions (not exclusion ranges, > specific versions) > > Basically upstreams are allowed to declare incompatible versions, but > Google would really like them to keep ascendent API compatibility > (and Google requires module renaming on major version changes, so there > is no upper limit to the API compatibility) > As I perceive this might be perceived by you as my personal attack I want to be clear that this is just my take on it and my technical opinion, so please keep this in mind. I would like to avoid any unnecessary misunderstandings and conflicts. But do we really need to recreate everything that upstream put in to the constrains in specs? I think that we are carrying curated set of the packages so this is IMHO not really necessary(at least not in all cases, just ones that crept in to our package base and we should avoid them at all costs). IMO if there are "holes" in the versions we should work with the upstreams to mitigate(fix) them and I believe they will be probably for some past/intermittent versions(do you have actual cases to show as examples?) and we can pretty easily handle them preventively with conflicts statements and proper comments accompanying them like "Based on constrain in the module ... caused by ...". Or is this something that is not possible/feasible? Do you have any cases where we will have to carry them in 1:1 representation with current package set? JC PS: CC'ing wider Fedora's Go community > Is the correct way to represent those in rpm: > > BuildRequires: ((golang-module(github.com/stretchr/testify) >= 1.3.0) and > ((golang-module(github.com/stretchr/testify) < > 1.3.2~0.20180906233101.161cd47e91fd) or > (golang-module(github.com/stretchr/testify) > > 1.3.2~0.20180906233101.161cd47e91fd)) and > ((golang-module(github.com/stretchr/testify) < 1.3.2~1.pre1) or > (golang-module(github.com/stretchr/testify) > 1.3.2~1.pre1)) and > ((golang-module(github.com/stretchr/testify) < > 1.3.2~1.pre1.0.20180628173108.788fd7840127) or > (golang-module(github.com/stretchr/testify) > > 1.3.2~1.pre1.0.20180628173108.788fd7840127))) > > or am I missing something obvious? > > Best regards, > > -- > Nicolas Mailhot > _______________________________________________ > packaging mailing list -- packaging(a)lists.fedoraproject.org > To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject… >

5 13

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

golang April 2019