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
qulogic opened a new pull-request against the project: `golist` that you are following:
``
Add option for querying main and test simultaneously.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/pull-request/24
nim opened a new pull-request against the project: `go-rpm-macros` that you are following:
``
make use of golist 0.10.0 fixes
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/13
Hi,
I have submitted the first of my dependency review requests here:
https://bugzilla.redhat.com/show_bug.cgi?id=1712280
Feedback is greatly appreciated so I can clean anything up on the next
set of dependencies.
I am working on the main application packaging for gocryptfs
(https://github.com/rfjakob/gocryptfs/) and have hit a few questions:
1. The upstream provides specific source tarballs for each version
here, https://github.com/rfjakob/gocryptfs/releases - I am planning to
use these as opposed to the gomacros to determine a git tag to pull.
Is there a reason not to do this?
2. The upstream build script sets up some values to be included in the
executables version string. I presume this helps with debugging. I
am told that the Go SIG would prefer to see the macros used for
building rather than the upstream build script. This is fine, except
I am not sure how to handle these values. Specifically, they are:
GITVERSION=$(cat VERSION)
GITVERSIONFUSE=$(rpm -q golang-github-hanwen-fuse-devel --queryformat
'%{version}')
BUILDDATE=$(date +%Y-%m-%d)
These can be set, presumably, somehow in the spec file (i haven't
tested my ideas here yet).
They are passed to `go build` as part of the ldflags, specifically as:
"-X main.GitVersion=$GITVERSION -X main.GitVersionFuse=$GITVERSIONFUSE
-X main.BuildDate=$BUILDDATE" prepended to any existing ldflags
How do you pass this information with the macros?
thanks,
bex
--
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com | bex(a)pobox.com
Hi,
I am trying to package gocryptfs. It has a pair of dependencies that
have a circular dependency:
golang-github-jacobsa-oglemock
golang-github-jacobsa-ogletest
I think I am supposed to make one of them have a bootstrap
configuration so it can be built without the other and then build the
other and then rebuild the first one.
If this is right, can someone point me to an example of this, ideally
done with golang, so I can work it out?
thanks,
bex
--
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com | bex(a)pobox.com
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