[opensuse-packaging] A simple golang package fails to build due a go library
Hi, I try to build: https://github.com/volatilityfoundation/dwarf2json here: https://build.opensuse.org/package/show/home:frispete:Tumbleweed/dwarf2json It depends on https://github.com/spf13/pflag, that should be available here: https://build.opensuse.org/package/show/devel:languages:go/golang-github-spf... but that's broken. I've submitted a fix for this already, and made the fixed package available in home:frispete:Tumbleweed. The %goprep step seems to succeed, but then it fails in %gobuild: [ 2s] + go install -v -p 4 -x -buildmode=pie github.com/ volatilityfoundation/dwarf2json [ 2s] # get https://proxy.golang.org/github.com/spf13/pflag/@v/v1.0.5.mod [ 2s] # get https://proxy.golang.org/github.com/spf13/pflag/@v/v1.0.5.mod: Get "https://proxy.golang.org/github.com/spf13/pflag/@v/v1.0.5.mod": dial tcp: lookup proxy.golang.org on [::1]:53: read udp [::1]:53173->[::1]:53: read: connection refused [ 2s] go: github.com/spf13/pflag@v1.0.5: Get "https://proxy.golang.org/ github.com/spf13/pflag/@v/v1.0.5.mod": dial tcp: lookup proxy.golang.org on [::1]:53: read udp [::1]:53173->[::1]:53: read: connection refused It seems to miss the library located here (inside the build environment): /usr/share/go/1.14/contrib/src/github.com/spf13/pflag Could some kind soul help me to get over this nuisance. Thanks, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Aug 20, Hans-Peter Jansen wrote:
It seems to miss the library located here (inside the build environment):
/usr/share/go/1.14/contrib/src/github.com/spf13/pflag
Could some kind soul help me to get over this nuisance.
go 1.14 has now modules support, no idea if the old hacks do really work with it anymore. The correct "fix" from go perspective is, to use the vendor directory. So "go mod init ...", packaging the vendor directory and "go build -mod=vendor ..." Or course only if your package does not provide the vendor directory already. More and more packages do that. If there are already go.mod, go.sum files and a vendor directory,then most likely "go -mod=vendor ..." is enough.
From a build service and maintenance perspective, this is of course a nightmare: it's next to impossible to find out which packages use a module with security problems and which need an update.
Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Thorsten Kukuk
On Thu, Aug 20, Hans-Peter Jansen wrote:
It seems to miss the library located here (inside the build environment):
/usr/share/go/1.14/contrib/src/github.com/spf13/pflag
Could some kind soul help me to get over this nuisance.
go 1.14 has now modules support, no idea if the old hacks do really work with it anymore.
The correct "fix" from go perspective is, to use the vendor directory. So "go mod init ...", packaging the vendor directory and "go build -mod=vendor ..." Or course only if your package does not provide the vendor directory already. More and more packages do that. If there are already go.mod, go.sum files and a vendor directory,then most likely "go -mod=vendor ..." is enough.
From a build service and maintenance perspective, this is of course a nightmare: it's next to impossible to find out which packages use a module with security problems and which need an update.
A workaround would be to tweak the go provides generator to parse the
go.mod file and generate additional provides of this form:
Provides: bundled(golang(github.com/davecgh/go-spew)) = 1.1.1
which can be queried using standard rpm tools.
Cheers,
Dan
--
Dan Čermák
Am Donnerstag, 20. August 2020, 13:01:17 CEST schrieb Thorsten Kukuk:
On Thu, Aug 20, Hans-Peter Jansen wrote:
It seems to miss the library located here (inside the build environment):
/usr/share/go/1.14/contrib/src/github.com/spf13/pflag
Could some kind soul help me to get over this nuisance.
go 1.14 has now modules support, no idea if the old hacks do really work with it anymore.
Hmm, I just try to package this in a sane way. Most of my "knowledge" is from here: https://en.opensuse.org/openSUSE:Packaging_Go Looks pretty much outdated..
The correct "fix" from go perspective is, to use the vendor directory. So "go mod init ...", packaging the vendor directory and "go build -mod=vendor ..." Or course only if your package does not provide the vendor directory already. More and more packages do that. If there are already go.mod, go.sum files and a vendor directory,then most likely "go -mod=vendor ..." is enough.
Thanks, that helped. Since the package contains a go.mod, the magic spell was: "go mod vendor", followed by "tar cvf ../vendor.tar.xz vendor", and some spec massage.
From a build service and maintenance perspective, this is of course a nightmare: it's next to impossible to find out which packages use a module with security problems and which need an update.
.. and will be suffering from the complexity inflation soon (since it piles up any dependencies in each and every package). This process is a serious security thread in itself (because it eases to hide bad code in the ever growing vendor tarballs everywhere). No fun. <bad pun on Google redacted> Thanks Thorsten, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (3)
-
Dan Čermák -
Hans-Peter Jansen -
Thorsten Kukuk