dev-go/act: new package #19411
dev-go/act: new package #19411
Conversation
Pull Request assignmentSubmitter: @waebbl dev-go/act: @gentoo/proxy-maint (new package) Linked bugsBugs linked: 770043 New packagesThis Pull Request appears to be introducing new packages only. Due to limited manpower, adding new packages is considered low priority. This does not mean that your Pull Request will not receive any attention, however, it might take quite some time for it to be reviewed. In the meantime, your new ebuild might find a home in the GURU project repository: the ebuild repository maintained collaboratively by Gentoo users. GURU offers your ebuild a place to be reviewed and improved by other Gentoo users, while making it easy for Gentoo users to install it and enjoy the software it adds. In order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
gentoo-bot
added
new package
|
The package does not use the standard go layout, hence the functions from golang-build.eclass can IMO not be used. |
Pull request CI reportReport generated at: 2021-02-11 07:30 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
dev-go/act/act-1.6.0.ebuild
Outdated
| go_arch() { | ||
| # By chance most portage arch names match Go | ||
| local portage_arch=$(tc-arch $@) | ||
| case "${portage_arch}" in | ||
| x86) echo 386;; | ||
| x64-*) echo amd64;; | ||
| ppc64) [[ $(tc-endian $@) = big ]] && echo ppc64 || echo ppc64le ;; | ||
| s390) echo s390x ;; | ||
| *) echo "${portage_arch}";; | ||
| esac | ||
| } | ||
|
|
||
| go_arm() { | ||
| case "${1:-${CHOST}}" in | ||
| armv5*) echo 5;; | ||
| armv6*) echo 6;; | ||
| armv7*) echo 7;; | ||
| *) | ||
| die "unknown GOARM for ${1:-${CHOST}}" | ||
| ;; | ||
| esac | ||
| } | ||
|
|
||
| go_os() { | ||
| case "${1:-${CHOST}}" in | ||
| *-linux*) echo linux;; | ||
| *-darwin*) echo darwin;; | ||
| *-freebsd*) echo freebsd;; | ||
| *-netbsd*) echo netbsd;; | ||
| *-openbsd*) echo openbsd;; | ||
| *-solaris*) echo solaris;; | ||
| *-cygwin*|*-interix*|*-winnt*) | ||
| echo windows | ||
| ;; | ||
| *) | ||
| die "unknown GOOS for ${1:-${CHOST}}" | ||
| ;; | ||
| esac | ||
| } | ||
|
|
||
| go-tuple() { | ||
| echo "$(go_os $@)_$(go_arch $@)" | ||
| } |
There was a problem hiding this comment.
Do we really need to care about all this? I see lib3mf is only keyworded for amd64 arm64 x86.
There was a problem hiding this comment.
I'm not sure about what we can remove here. As far as I understand this, go needs a tuple set before being called. We can probably cleanup the go_os (all non-linux) and go_arch (ppc and s390) until lib3mf gets keyworded for any of those.
We could also simplify it by hardcoding linux for go-os in go-tuple
There was a problem hiding this comment.
What do you think about the last changes?
Pull request CI reportReport generated at: 2021-03-14 11:30 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Closes: https://bugs.gentoo.org/770043 Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Bernd Waibel <waebbl-gentoo@posteo.net>
Pull request CI reportReport generated at: 2021-03-16 21:59 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
|
Sadly, I don't have a arm machine to test this. I don't actually know exactly how go is working, found those functions in the dev-lang/go ebuild and thought the env vars are needed to properly run go. I can be wrong on this. Yet, those env vars control the way go is building packages in some way, see |
| go_arm() { | ||
| case "${1:-${CHOST}}" in | ||
| armv5*) echo 5;; | ||
| armv6*) echo 6;; | ||
| armv7*) echo 7;; | ||
| *) | ||
| die "unknown GOARM for ${1:-${CHOST}}" | ||
| ;; | ||
| esac | ||
| } | ||
|
|
||
| src_compile() { | ||
| export GOARCH=$(go_arch) | ||
| export GOOS=linux | ||
| if [[ ${ARCH} == arm ]]; then | ||
| export GOARM=$(go_arm) | ||
| fi |
There was a problem hiding this comment.
@thesamesam what do you think? Are these relevant for arm64? I don't think they are. AFAIK this doesn't need to be keyworded with arm at all, just arm64.
There was a problem hiding this comment.
AFAIK this doesn't need to be keyworded with arm at all, just arm64.
That's correct, lib3mf-1 has only support for arm64.
There was a problem hiding this comment.
This'll do for now, but please speak to William about possibly including this in golang-base. It's fine to keep this in because there's no sense in gatekeeping future support.
| SLOT="0" | ||
| KEYWORDS="~amd64 ~x86" | ||
|
|
||
| RESTRICT="strip test" |
There was a problem hiding this comment.
Sadly no. There's an Examples/UnitTest directory but it looks like it's not updated for this version.
|
Thanks! Added bb5b84a for a verbose build. |
|
Thanks! |
Closes: https://bugs.gentoo.org/770043
Package-Manager: Portage-3.0.14, Repoman-3.0.2
Signed-off-by: Bernd Waibel waebbl-gentoo@posteo.net
Package is needed to bump media-libs/lib3mf-2.1.0. This package has pre-built binary blobs available for x86_64, win64 and darwin, but not for x86_32 and arm, hence the keywords had to be dropped temporarily. This package should be able to re-enable those keywords.