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
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
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
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
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
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
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
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
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
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
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
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
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
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
carlwgeorge opened a new pull-request against the project: `go-rpm-macros` that you are following:
``
Update bootstrapping link
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/5
qulogic reported a new issue against the project: `golist` that you are following:
``
```
$ go get pagure.io/golist/...
package pagure.io/golist/pkg/util/internal/load: unrecognized import path "pagure.io/golist/pkg/util/internal/load" (parse https://pagure.io/golist/pkg/util/internal/load?go-get=1: no go-import meta tags ())
package pagure.io/golist/pkg/util/internal/modload: unrecognized import path "pagure.io/golist/pkg/util/internal/modload" (parse https://pagure.io/golist/pkg/util/internal/modload?go-get=1: no go-import meta tags ())
package pagure.io/golist/pkg/util/internal/work: unrecognized import path "pagure.io/golist/pkg/util/internal/work" (parse https://pagure.io/golist/pkg/util/internal/work?go-get=1: no go-import meta tags ())
```
There is no `pkg/util/internal` in the repository.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/15
Hi folks,
I'm attempting to package up a Go-based application and I'm lost :)
I've run "yum install gofed" so I've got gofed-1.0.0-0.21.rc1.fc29
installed. Here's where I tried to use it:
$ gofed repo2spec --detect https://github.com/rook/rook
Repo URL: github.com/rook/rook
Commit: 43a83f7d8fff8753eb6f492d729f9c6876105164
Name: golang-github-rook-rook
(1/4) Checking if the package already exists in PkgDB
(2/4) Collecting data
2019-01-14 17:16:34,402 - ERROR - [Errno 13] Permission denied:
'/var/lib/gofed/resource_provider/githubsourcecodeprovider-9ef70a1c8c7d4532abe3ea8cdd330ccbac5aa58d6fd842f0b55e078c033ca3df'
I'm not sure how to get past this error. I also have some general questions:
1. Am I on the right track and I should continue with gofed?
2. How can I tell gofed that I'm packaging an application (like etcd),
not a library?
- Ken