Build issue
fabaff opened this issue · 6 comments
Describe the bug
The RPM build process fails when I try to create a RPM package.
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.EiN26S
+ umask 022
+ cd /home/fab/rpmbuild/BUILD
+ cd cli-4.1.0
+ for cmd in cmd/*
++ head -c20 /dev/urandom
++ od -An -tx1
++ tr -d ' \n'
++ basename cmd/addons.go
+ GOPATH=/home/fab/rpmbuild/BUILD/cli-4.1.0/_build:/home/fab/go:/usr/share/gocode
+ GO111MODULE=off
+ go build -buildmode pie -compiler gc '-tags=rpm_crashtraceback ' -ldflags '-X github.com/home-assistant/cli/version=4.1.0 -X github.com/home-assistant/cli/version.tag=4.1.0 -B 0xb05aa6dfa622eb12be0d81822bdb343a5c8825f6 -extldflags '\''-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld '\''' -a -v -x -o /home/fab/rpmbuild/BUILD/cli-4.1.0/_build/bin/addons.go github.com/home-assistant/cli/cmd/addons.go
WORK=/tmp/go-build960742279
can't load package: package github.com/home-assistant/cli/cmd/addons.go: cannot find package "github.com/home-assistant/cli/cmd/addons.go" in any of:
/usr/lib/golang/src/github.com/home-assistant/cli/cmd/addons.go (from $GOROOT)
/home/fab/rpmbuild/BUILD/cli-4.1.0/_build/src/github.com/home-assistant/cli/cmd/addons.go (from $GOPATH)
/home/fab/go/src/github.com/home-assistant/cli/cmd/addons.go
/usr/share/gocode/src/github.com/home-assistant/cli/cmd/addons.go
error: Bad exit status from /var/tmp/rpm-tmp.EiN26S (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.EiN26S (%build)Also, is not working for 4.0.0 and 3.1.2. First though was that the issue is related to the renaming. The files is present in the BUILD directory thus something other is standing in the way.
Sorry, we don't provide, maintain, build or support RPM packages.
But I do. Thus would be nice to sort this out.
This tool is distributed inside an ecosystem that does not use or rely on a system that uses RPM of any kind.
It is not in the project interest of providing an RPM. So I'm sorry to hear you have trouble with packing it, but we should also not spent time on it from a project perspective.
If you can solve it, a PR would be welcome, sure, but it is not a focus.
I agree, we have binary and you can use the binary without need compile it self. This binary are created by CI. This tool is internal and we provide soon also for generic installer a container like on OS, which is the way how we support this official.
However, if you find a bug and provide a fix, I see also no issue to merge that PR.
Re-opened as the build issue is still present. Please link the PR for the fix to close this. Thanks.
This tool is distributed inside an ecosystem that does not use or rely on a system that uses RPM of any kind.
IMHO, taking about "an ecosystem" is simply short-sighted and really not what HA is about.
There are another ecosystems beside the former Hass.io ecosystem and those ecosystems are using RPM, deb and apk. Every others systems in most environments are not part of the HA ecosystem thus our own ecosystem must support openness in very possible way and follow common standards. Otherwise we are simply moving down the same path as the smart home vendors do and create another silo.
Well, for you it might not be an use case to maintain a HA instance from remote in an automated way but for me it is and, I guess, for a part of the community as well. Especially as there is support for that.
It is not in the project interest of providing an RPM.
You don't have to provide anything. I was not asking that somebody provide a RPM. I'm doing it and it will not be part of HA. The Fedora Packaging Guidelines are strict and not working with upstream is considered bad behavior by most of the contributors in that ecosystem.
This issue mention a build issue, see #215 (comment) . To not remove context, I left the source of the failure in the report which happens to be the RPM build process which is trying to build the binary. I guess that this shifted the spot light from the build failure to the RPM.
So, who exactly is defining the project interest? You? For sure, it's not the community.
So I'm sorry to hear you have trouble with packing it, but we should also not spent time on it from a project perspective.
To which perspective are you referring to? "we", was "we" the HA community, "we" the cli maintainers or is it another "we"?
As far as I remember is there no statement present in the HA community that states not to fix bugs or not being supportive. And cli is part of that.
If you can solve it, a PR would be welcome, sure, but it is not a focus.
Fixing an issue is not the focus? This build issue only hit me today and tomorrow it might become an issue in the CI as well when builds should be hardened by default or other changes arises.
I agree, we have binary and you can use the binary without need compile it self. This binary are created by CI.
This is the problem: It's a binary. Doesn't matter how it's build or by whom. For security and privacy reasons everybody should be able to build it by themselves with their preferred compiler flags and alike. It's not about wired settings but with the standard settings of a very large project which makes the build unfortunately fails.
This tool is internal and we provide soon also for generic installer a container like on OS, which is the way how we support this official.
Sure, it's but it's not mentioned anywhere that's for "internal usage only". I'm going to quote the README here: "...if on a remote host you'll...". This suggests quite the opposite.
Containers are nice...To be honest, why should one launch a, perhaps out-dated, container locally when the same tasks can be done without a container directly from the command line and without opening a SSH tunnel first?
The tool (if available as package) will automatically be up-to-date thanks to the package maintenance tools of the distributions. While updated container images are not pulled automatically by default on my desktop system.