eclass/go-env.eclass: add compile env helper to enable cross compiling Go programs by t-lo · Pull Request #33539 · gentoo/gentoo

t-lo · 2023-10-27T08:30:20Z

This PR addresses an issue with Go programs which, to the best of our knowledge (and testing) currently cannot be cross-compiled with crossdev on Gentoo.

The change adds a helper function to explicitly set CC, CXX, and GOARCH to the values returned by toolchain-funcs and carry over CFLAGS, LDFLAGS and friends to CGO equivalents, to provide a minimal sane compile environment for Go. It enables Go builds to play nice with crossdev's wrappers for emerge/ebuild etc.

Previously, Go ebuilds emitted binaries for the host architecture since Go defaults CC, CXX, and GOARCH to the host. This can be easily validated by putting the command go env into the src_compile() stage of a Go program's ebuild and then cross-emerge that program - the environment will reflect the host environment instead of the target env.

For example, when running on an x86_64 host:

   emerge-aarch64-cross-linux-gnu foo

would previously either emit binaries for x86_64 or break entirely during src_compile() from linker errors. With this PR the command will now correctly emerge Go package "foo" for aarch64 instead of x86_64.

The eclass added provides a single helper function

    go-env_set_compile_environment()

intended to be called by other Go eclasses in an early build stage. Ebuilds may also explicitly call this function.

The helper function is supposed to be called in an early build stage. Calls to this function from _src_prepare in go-module.eclass, golang-vcs-snapshot.eclass, and golang-vcs.eclass have been added to immediately un-break cross-compilation of existing Go packages.

Testing done

The PR has been tested using the Gentoo stage3 / portage containers:

A full Gentoo container image was built in accordance with https://github.com/gentoo/gentoo-docker-images
An aarch64-cross-linux-gnu crossdev environment was installed in the container, following https://wiki.gentoo.org/wiki/Crossdev

For testing purposes runc, a simple Go program, was emerged:

emerge-aarch64-cross-linux-gnu runc

This failed in stage src_compile with a linker error:

...
GOROOT_FINAL='$GOROOT' /usr/lib/go/pkg/tool/linux_amd64/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -installsuffix shared -X=runtime.godebugDefault=panicnil=1 -buildmode=pie -buildid=6MUnT5PQr_SBpvPFIWW-/eZ8c261V2-y_pzaOtVhP/YxEOWcTUB9Lsz-2nDChM/6MUnT5PQr_SBpvPFIWW- -X main.gitCommit=ccaecfcbc907d70a7aa870a6650887b901b25b82 -X main.version=1.1.9 -extld=x86_64-pc-linux-gnu-gcc $WORK/b001/_pkg_.a
...
/usr/libexec/gcc/x86_64-pc-linux-gnu/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/libexec/gcc/x86_64-pc-linux-gnu/ld: /usr/aarch64-cross-linux-gnu/tmp/portage/app-containers/runc-1.1.9/temp/go-link-738209211/000010.o: in function `getenv_int':
nsexec.c:(.text+0xd37): undefined reference to `__isoc23_strtol'
/usr/libexec/gcc/x86_64-pc-linux-gnu/ld: /usr/aarch64-cross-linux-gnu/tmp/portage/app-containers/runc-1.1.9/temp/go-link-738209211/000010.o: in function `receive_mountsources':
nsexec.c:(.text+0x1fdc): undefined reference to `__isoc23_strtol'
collect2: error: ld returned 1 exit status

make: *** [Makefile:61: runc] Error 1

From the output it's clear that Go tried to build x86_64 binaries.

The patch shipped with this PR was applied to /var/db/repos/gentoo/

runc was now cross-emerged successfully:

emerge-aarch64-cross-linux-gnu runc

And the resulting binary has the correct arch:

file /usr/aarch64-cross-linux-gnu/usr/bin/runc
/usr/aarch64-cross-linux-gnu/usr/bin/runc: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, Go BuildID=OFslkehqBcinH9G-YTjt/eYtglPhJGrLwlpqQXkK1/mDQ_zWTC3hiGroV_8tzq/ushdIjZQV322dHy6oPli, with debug_info, not stripped

Continued Maintenance of the new EClass

The Flatcar Maintainers team commit to maintaining this eclass. We are planning to actively use it in our downstream Flatcar Container Linux distro (which is based on Gentoo) to cross-compile Go binaries. Initially it will be used for runc, containerd, docker, docker-cli, and cri-tools. These will be cross-built regularly in our Nightlies and will undergo full scenario testing in our release tests, so regressions will be identified swiftly and be fixed in a timely manner.

gentoo-bot · 2023-10-27T08:32:04Z

Pull Request assignment

Submitter: @t-lo
Areas affected: eclasses
Packages affected: (none)

@gentoo/github

Linked bugs

No bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment.

New packages

This 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 [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

t-lo · 2023-10-27T08:39:27Z

CC: @williamh

t-lo · 2023-10-27T09:03:25Z

CI Report raised 2 issues specific to go-env.eclass:

EclassDocMissingFunc - go-env: undocumented function: go-env_set_compile_environment
NonGentooAuthorsCopyright - go-env: copyright line must state "Gentoo Authors": '# Copyright 2023 Flatcar Maintainers'

I've addressed both issues.

gentoo-repo-qa-bot · 2023-10-27T09:16:44Z

Pull request CI report

Report generated at: 2023-10-27 09:16 UTC
Newest commit scanned: ee681dc
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/9de5dd7ebf/output.html

gentoo-repo-qa-bot · 2023-10-27T10:21:44Z

Pull request CI report

Report generated at: 2023-10-27 10:21 UTC
Newest commit scanned: c5b7b8d
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/89f29b1cda/output.html

gentoo-repo-qa-bot · 2023-10-27T10:36:44Z

Pull request CI report

Report generated at: 2023-10-27 10:36 UTC
Newest commit scanned: 19e6ffc
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/0d7550387a/output.html

chewi · 2023-10-27T11:01:54Z

I'll look at this over the weekend.

gentoo-repo-qa-bot · 2023-10-27T12:16:47Z

Pull request CI report

Report generated at: 2023-10-27 12:16 UTC
Newest commit scanned: e6a0d45
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/2fb0593e19/output.html

This change adds exporting CGO_* flags to go-env.eclass; the upstream pr gentoo/gentoo#33539 has been updated accordingly. Also, CGO_ENABLED=1 has been added to coreos/../make.conf to enable gco by default. This fixes a build issue for arm64 with Docker's device-mapper storage driver: daemon/graphdriver/devmapper/deviceset.go:306:25: undefined: devicemapper.SetTransactionID ... daemon/graphdriver/devmapper/deviceset.go:867:28: undefined: devicemapper.ErrEnxio daemon/graphdriver/devmapper/deviceset.go:867:28: too many errors gco is enabled on AMD64 by default, and cgo was always enabled in the coreos docker ebuilds. This way we retain that setting for the Gentoo ebuilds.

gentoo-repo-qa-bot · 2023-10-27T15:21:41Z

Pull request CI report

Report generated at: 2023-10-27 15:21 UTC
Newest commit scanned: 3bab338
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/52ff288586/output.html

chewi · 2023-10-28T17:12:39Z

Without looking closely at the code yet, I tried it against app-crypt/age and it built when it didn't before. However, it didn't run because this was cross-prefix, and it hadn't set the interpreter to /myprefix/lib/ld-linux-armhf.so.3. It ran after fixing this manually with patchelf. Normally, I'd say that isn't important for an initial stab at this, but I know what you want this for. 😉

cross-boss sets the interpreter via LDFLAGS="-Wl,--dynamic-linker=/myprefix/lib/ld-linux-armhf.so.3". I can see that made it into CGO_LDFLAGS, but I guess it's not being picked up. I can't see that flag in the log or any of the build files, but then I can't find any of the other flags either. Perhaps they only live in the environment and are not recorded anywhere.

chewi · 2023-10-29T09:44:39Z

I tried adding a bogus flag to CGO_CFLAGS and CGO_LDFLAGS and it didn't break anything, so these don't appear to be used. append-cflags and append-ldflags didn't do anything either. This package supposedly uses gox, but GOX_linux_${GOARCH}_GCFLAGS also had no affect. It seems like GOARCH is the only thing being respected here.

chewi · 2023-10-29T09:57:28Z

Sorry, should have done some research first. I now understand cgo is only used for C code.

You can give -ldflags to go build, but we don't in golang-build.eclass for some reason. app-crypt/age also doesn't use this eclass, which seems wrong. In fact, quite a lot of Go packages don't use it. @williamh, is there a reason for that?

The eclass suggests setting EGO_BUILD_FLAGS="-ldflags \"-X main.version ${PV}\"", which may work against us if we want other LDFLAGS to be respected, assuming passing it more than once doesn't append the flags. Maybe we should have EGO_BUILD_LDFLAGS or something.

t-lo · 2023-10-29T15:19:07Z

CGO also impacts linking - if a Go application depends on C libraries at compile time / runtime it should explicitly set CGO_ENABLED=1 in the ebuild so it is linked correctly. Only with CGO_ENABLED=1 the CGO_* environment variables matter and are passed to CC and CXX respectively. Go defaults to CGO_ENABLED=1 only when GOHOSTARCH equals GOARCH, and to CGO_ENABLED=0 otherwise.

In Flatcar we default to CGO_ENABLED=1 (in coreos-go.eclass for legacy ebuilds, and in make.defaults going forward), and ebuilds must explicitly set it to 0 if they don't want it. But then we always ship full OS images, so that's a reasonable default since we always ship with all dependencies.

I'm not familiar with app-crypt/age, but if it depends on C libraries of other packages it should enable CGO. Another example for using CGO is docker's devicemapper storage back-end driver, which depends on lvm2 - if docker is cross-compiled with USE=device-mapper then CGO_ENABLED=1 must be set or else the build will fail with linker errors in docker's devicemapper Go module.

I'm not sure about introducing additional flags like EGO_BUILD_LDFLAGS - what's the benefit over setting CGO_LDFLAGS directly? It's retained in go-env.eclass if set.

I think golang-build.eclass is deprecated and replaced by go-module.eclass, maybe packages are slowly migrated?

chewi · 2023-10-29T16:14:22Z

Ah yes, hadn't noticed the deprecation. Seems odd to me though, now there's no common way to run go build.

I picked app-crypt/age because it was a simple Go-based application that I could easily test.

I set CGO_ENABLED=1 and now it just works. I wondered whether we could just make this the default, but I see that it doesn't just change how it's built, but also how it runs too. It doesn't sound like it would break anything, but some might find it undesirable.

Maybe I could make it the default for cross-prefix. I'm not sure whether normal prefix works without it either, need to test. If it doesn't, there's probably a better way of fixing it.

williamh · 2023-10-29T16:40:19Z

The golang-* eclasses are deprecated. I need to check in the main tree to see if they are still being used and remove them if they aren't. I think we have a couple of stragglers, but I'll check for sure in the next day or two.

If an ebuild is calling go directly, it should be calling ego in go-module.eclass instead.
I can also look into adding the environment variables you are setting directly to
go-module.eclass.

williamh · 2023-10-29T16:40:51Z

I'll be available tomorrow morning my time to take a look at this.

t-lo · 2023-10-29T16:54:15Z

The golang-* eclasses are deprecated. I need to check in the main tree to see if they are still being used and remove them if they aren't. I think we have a couple of stragglers, but I'll check for sure in the next day or two.

If an ebuild is calling go directly, it should be calling ego in go-module.eclass instead. I can also look into adding the environment variables you are setting directly to go-module.eclass.

That's what I did at first but then I noticed quite a few ebuilds aren't using go-module.eclass and aren't easily portable - among these are docker + friends, which we use downstream in Flatcar. So I reconed the least intrusive and most effective way forward was to provide a helper function in a separate eclass, and have all other go eclasses call it.

I mused that this way, the cross-compilation fix in this PR does not depent on the work of porting all ebuilds to go-module.eclass. Also, after everything was ported eventually, we could easily merge go-env.eclass into go-module.eclass without any side effect.

t-lo · 2023-10-29T17:31:27Z

I set CGO_ENABLED=1 and now it just works. I wondered whether we could just make this the default, but I see that it doesn't just change how it's built, but also how it runs too. It doesn't sound like it would break anything, but some might find it undesirable.

Yes, that is correct. At the end of the day it should be a per-ebuild setting but reviewing and updating all the Go app ebuilds across Gentoo is a ton of work.

From a package's perspective self-contained go apps that don't have any host library dependencies would be perfectly happy with CGO_ENABLED=0 even when GOARCH == GOHOSTARCH; the build would ship a static, self-contained binary that would run everywhere. CGO_ENABLED=1 implies "I have dependencies to external C libraries and you better make sure these are available when I run".

However, from a distro perspective CGO_ENABLED=1 might make sense since the whole point of a distro is to ensure all dependencies are shipped. My only concern was that we would change an implicit Gentoo-wide default (since Go would default to CGO_ENABLED=0 when GOARCH != GOHOSTARCH) - but on the other hand cross-compiling Go apps never worked in Gentoo in the first place (hence my PR), so no one would rely on that behaviour anyway.

It's a good point in time to make a decision for the standard behaviour going forward.

This change adds exporting CGO_* flags to go-env.eclass; the upstream pr gentoo/gentoo#33539 has been updated accordingly. Also, CGO_ENABLED=1 has been added to coreos/../make.conf to enable gco by default. This fixes a build issue for arm64 with Docker's device-mapper storage driver: daemon/graphdriver/devmapper/deviceset.go:306:25: undefined: devicemapper.SetTransactionID ... daemon/graphdriver/devmapper/deviceset.go:867:28: undefined: devicemapper.ErrEnxio daemon/graphdriver/devmapper/deviceset.go:867:28: too many errors gco is enabled on AMD64 by default, and cgo was always enabled in the coreos docker ebuilds. This way we retain that setting for the Gentoo ebuilds.

chewi · 2023-10-31T23:18:32Z

Instead of using cgo, you can set the interpreter with -ldflags "-I /myprefix/lib/ld-linux-armhf.so.3". Having the eclass set this doesn't seem feasible. It would need to know the correct interpreter path, which isn't easy to determine. I thought that perhaps cross-boss (or the user) could set this up in GOFLAGS, but go-module.eclass currently overwrites it rather than appending to it. Even then, passing -ldflags to go build (as some packages do) overrides any such flag in GOFLAGS. This is the worst of all worlds. You'd have to combine all instances of -ldflags with any passed directly to ego. Possible but not very pretty.

I have now tested normal prefix (as opposed to cross-prefix), and somehow the correct interpreter path gets used, although I don't know how.

t-lo · 2023-11-01T12:29:23Z

I thought that perhaps cross-boss (or the user) could set this up in GOFLAGS, but go-module.eclass currently overwrites it rather than appending to it.

Arguably https://github.com/flatcar/gentoo/blob/t-lo/go-env-eclass-helper/eclass/go-module.eclass#L102 could honour variables passed via the environment. However, in every other occurrence GOFLAGS is only appended to, so customisations of that variable from ebuilds and from e.g. make.defaults should survive.

In other news, we've merged the change in this PR downstream in Flatcar and will carry it forward for the time being. The whole issue bubbled up when we switched our runc, cri-tools, docker and containerd ebuilds from entirely self-made, Flatcar specific ebuilds to Gentoo upstream ebuilds. During this change we realised Gentoo crossdev doesn't support cross-compiling Go, so our Arm64 image broke 🙃 . Our next Alpha release (slated for end of November) will ship runc, cri-tools, docker and containerd built with this change.

For each release (and nightly, even) we run a thorough suite of tests to ensure Flatcar's main function - to run containers - works flawlessly. So implicitly this PR's change is getting tested a lot.

chewi · 2023-11-01T12:50:56Z

Given that this just works most of the time and a cross-prefix fix wouldn't affect this code, I'm happy for this to just go in as-is. It'll need to get sent to the gentoo-dev mailing list first though, so I'll do that.

t-lo · 2023-11-01T14:14:49Z

Awesome, thank you chewi!

t-lo · 2023-11-08T07:43:25Z

I've read Sam's feedback on gentoo-dev and have split the PR into separate commits for adding the new eclass and calling it from upper level go eclasses (each), respectively.

gentoo-repo-qa-bot · 2023-11-08T07:56:08Z

Pull request CI report

Report generated at: 2023-11-08 07:56 UTC
Newest commit scanned: bdfe480
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/eaf23aca6a/output.html

chewi · 2023-11-09T22:25:22Z

I'm afraid you missed some of his feedback, about == and the @MAINTAINER entry. I can see infra@flatcar.org isn't on our Bugzilla.

t-lo · 2023-11-10T07:29:48Z

@chewi OH I didn't read through the attached patch, thanks for pointing me to it. Will take care of this today.

Need to update the Flatcar maintainer contact email; it's actually infra@flatcar-linux.org. I've created a bugzilla account, it'll likely come in handy for other things too as we're planning to collaborate a bit more actively with our upstream in the near future.

t-lo · 2023-11-10T08:54:31Z

All feedback addressed. Thanks again for the ping.

gentoo-repo-qa-bot · 2023-11-10T09:06:18Z

Pull request CI report

Report generated at: 2023-11-10 09:06 UTC
Newest commit scanned: cfad8a9
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/b21876a2fd/output.html

chewi · 2023-11-11T23:01:51Z

eclass/go-env.eclass

+	case "${arch}" in
+		x86)	GOARCH="386" ;;
+		x64-*)	GOARCH="amd64" ;;
+		ppc64)  if [[ "$(tc-endian "${${CHOST}}")" == "big" ]] ; then


Just noticed this. Surely this should be $(tc-endian "${CHOST}")? But then why not just $(tc-endian)?

That's a good catch, some over-eager evals going on here. I've updated this to use plain $(tc-endian) as tc_endian has sane defaults if $1 isn't set, as you rightfully stated.

thesamesam

I'd send a fixed up version to the ML for completeness (and CC William) but given there's no substantive changes wrt v1, I'd say it's fine to go in without waiting for any further feedback then.

Thank you!

gentoo-repo-qa-bot · 2023-11-16T08:12:40Z

Pull request CI report

Report generated at: 2023-11-16 08:12 UTC
Newest commit scanned: 8c6892c
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/04e79f15c5/output.html

chewi · 2023-11-16T23:03:05Z

eclass/go-env.eclass

+# (e.g. "emerge-aarch64-cross-linux-gnu foo" run on x86_64 will emerge "foo" for x86_64
+#  instead of aarch64)
+go-env_set_compile_environment() {
+	local arch=$(tc-arch "${CHOST}}")


I was about to submit it once more when I noticed this line too! Extra } here, but again, I think this can just be $(tc-arch) in the same manner.

Good point; I checked tc-ninja_magic_to_arch() and it has the same defaults as tc-endian. Thanks for catching another spurious brace! I definitely need to read my PRs more carefully before submitting.
This worked in my test builds because tc-ninja_magic_to_arch() does pattern matching of host, so aarch64* matches against aarch64-cross-linux-gnu}. Great catch, thanks again!

This change adds a helper function to explicitly set CC, CXX, and GOARCH, and carrying over CFLAGS, LDFLAGS and friends to CGO equivalents, to provide a minimal sane compile environment for Go. It enables Go builds to play nice with crossdev's wrappers for emerge/ebuild etc. Previously, Go ebuilds emitted binaries for the host architecture. For example, when running on an x86_64 host: emerge-aarch64-cross-linux-gnu foo will now correctly emerge Go package "foo" for aarch64 instead of x86_64. The eclass provides a single helper function go-env_set_compile_environment() intended to be called by other Go eclasses in an early build stage. Ebuilds may also explicitly call this function. Signed-off-by: Thilo Fromm <thilo.alexander@gmail.com>

This change calls go-env_set_compile_environment in go-module's src_unpack to set up a sane compile environment early in the go build process. This un-breaks cross compiling of all golang ebuilds that inherit go-module. Signed-off-by: Thilo Fromm <thilo.alexander@gmail.com>

This change calls go-env_set_compile_environment in golang-vcs-snapshot's src_unpack to set up a sane compile environment early in the go build process. This un-breaks cross compiling of all golang ebuilds that inherit golang-vcs-snapshot. Signed-off-by: Thilo Fromm <thilo.alexander@gmail.com>

This change calls go-env_set_compile_environment in golang-vcs's src_unpack to set up a sane compile environment early in the go build process. This un-breaks cross compiling of all golang ebuilds that inherit golang-vcs. Signed-off-by: Thilo Fromm <thilo.alexander@gmail.com>

gentoo-repo-qa-bot · 2023-11-17T09:47:59Z

Pull request CI report

Report generated at: 2023-11-17 09:47 UTC
Newest commit scanned: e578229
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/c7a6d4d079/output.html

gentoo-bot added the need assignment It was impossible to assign the PR correctly. Please assign it manually. label Oct 27, 2023

t-lo force-pushed the t-lo/go-env-eclass-helper branch from ecbaba3 to ee681dc Compare October 27, 2023 09:01

t-lo mentioned this pull request Oct 27, 2023

app-containers: switch to upstream docker, containerd, runc, bump docker to v24 flatcar/scripts#1305

Merged

t-lo force-pushed the t-lo/go-env-eclass-helper branch 4 times, most recently from fc7fd2c to 19e6ffc Compare October 27, 2023 10:21

chewi self-requested a review October 27, 2023 11:01

t-lo force-pushed the t-lo/go-env-eclass-helper branch from 19e6ffc to e6a0d45 Compare October 27, 2023 12:00

t-lo force-pushed the t-lo/go-env-eclass-helper branch from e6a0d45 to 3bab338 Compare October 27, 2023 14:59

t-lo mentioned this pull request Oct 27, 2023

[Tracking] Upstream merge of go-env.eclass flatcar/Flatcar#1221

Closed

t-lo force-pushed the t-lo/go-env-eclass-helper branch from 3bab338 to bdfe480 Compare November 8, 2023 07:41

t-lo force-pushed the t-lo/go-env-eclass-helper branch from bdfe480 to cfad8a9 Compare November 10, 2023 08:53

chewi reviewed Nov 11, 2023

View reviewed changes

thesamesam approved these changes Nov 12, 2023

View reviewed changes

t-lo force-pushed the t-lo/go-env-eclass-helper branch from cfad8a9 to 8c6892c Compare November 16, 2023 07:59

chewi reviewed Nov 16, 2023

View reviewed changes

t-lo added 4 commits November 17, 2023 10:26

t-lo force-pushed the t-lo/go-env-eclass-helper branch from 8c6892c to e578229 Compare November 17, 2023 09:31

gentoo-bot closed this in 0c931a2 Nov 20, 2023

Conversation

t-lo commented Oct 27, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Testing done

Continued Maintenance of the new EClass

Uh oh!

gentoo-bot commented Oct 27, 2023

Pull Request assignment

Linked bugs

New packages

Uh oh!

t-lo commented Oct 27, 2023

Uh oh!

t-lo commented Oct 27, 2023

Uh oh!

gentoo-repo-qa-bot commented Oct 27, 2023

Pull request CI report

Uh oh!

gentoo-repo-qa-bot commented Oct 27, 2023

Pull request CI report

Uh oh!

gentoo-repo-qa-bot commented Oct 27, 2023

Pull request CI report

Uh oh!

chewi commented Oct 27, 2023

Uh oh!

gentoo-repo-qa-bot commented Oct 27, 2023

Pull request CI report

Uh oh!

gentoo-repo-qa-bot commented Oct 27, 2023

Pull request CI report

Uh oh!

chewi commented Oct 28, 2023

Uh oh!

chewi commented Oct 29, 2023

Uh oh!

chewi commented Oct 29, 2023

Uh oh!

t-lo commented Oct 29, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chewi commented Oct 29, 2023

Uh oh!

williamh commented Oct 29, 2023

Uh oh!

williamh commented Oct 29, 2023

Uh oh!

t-lo commented Oct 29, 2023

Uh oh!

t-lo commented Oct 29, 2023

Uh oh!

chewi commented Oct 31, 2023

Uh oh!

t-lo commented Nov 1, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chewi commented Nov 1, 2023

Uh oh!

t-lo commented Nov 1, 2023

Uh oh!

t-lo commented Nov 8, 2023

Uh oh!

gentoo-repo-qa-bot commented Nov 8, 2023

Pull request CI report

Uh oh!

chewi commented Nov 9, 2023

Uh oh!

t-lo commented Nov 10, 2023

Uh oh!

t-lo commented Nov 10, 2023

Uh oh!

gentoo-repo-qa-bot commented Nov 10, 2023

Pull request CI report

Uh oh!

chewi Nov 11, 2023

Choose a reason for hiding this comment

Uh oh!

t-lo Nov 16, 2023

Choose a reason for hiding this comment

Uh oh!

t-lo commented Oct 27, 2023 •

edited

Loading

t-lo commented Oct 29, 2023 •

edited

Loading

t-lo commented Nov 1, 2023 •

edited

Loading

thesamesam left a comment •

edited

Loading