crossdev: Bootstrap the full LLVM toolchain

[vadorovsky]

Include llvm-libunwind and libcxx in the LLVM-based cross environments,
so they are fully ready to build any package.

[thesamesam]

Nice! I think @Arniiiii is interested in doing some work on this as well.

[vadorovsky]

Depends on gentoo/gentoo#39280

@thesamesam I added a GitHub Actions workflow which should be able to test crossdev. But it seems like actions need to be enabled for this repo.

[thesamesam]

I think it'll Just Work once it's merged.

[vadorovsky]

Usually when I'm adding workflows to new repos, they start executing already in the PR introducing them. I would double-check if there is any setting to enable.

But if that doesn't work, I can try making an another PR, where I could start with testing GNU targets.

[thesamesam]

Checking the settings is awkward because of how we have things setup. But right now, it looks to me the same as every other repo we have in gentoo. Please do make that other PR and I'll merge it.

[Arniiiii]

Depends on gentoo/gentoo#39280

@thesamesam I added a GitHub Actions workflow which should be able to test crossdev. But it seems like actions need to be enabled for this repo.

AFAIK you can enable GitHub actions for your fork somewhere in settings of your fork.

Nice! I think @Arniiiii is interested in doing some work on this as well.

Definitely ! Thanks for mentioning!

In current upstream we see checking next setups:
- aarch64-unknown-linux-gnu on openrc+gcc+glibc
- aarch64-unknown-linux-gnu on openrc+gcc+musl
- aarch64-unknown-linux-musl on openrc+gcc+glibc
- aarch64-unknown-linux-musl on openrc+gcc+musl

I think this is small amount of setups. Even your work on enabling cross-compiling with llvm via the crossdev script is not checked.

I guess there's a small problem with automatic testing of the project: checking valuable amount of targets requires a lot of time. I wrote a bash script for all of this, you can check at my fork: https://github.com/Arniiiii/crossdev/blob/master/test.bash . It took on a laptop with Intel's i7-13700HX at 4-5 GHz around 600 mins IIRC.

Now there's a problem: GitHub allows only 2000 mins of Linux CI/CD per month per user.

So only 1,2 or maybe 3 such checks can be done per month per user. That's not good.

AFAIK there's a relatively newly added feature in GitHub called self-hosted runners. Gitea, Forgejo, Gitlab have this feature and I can confirm it works there, but I haven't setup it on GitHub yet.

In a week or in a month I can provide a laptop with znver2 CPU with 12 threads and 16GB as a self-hosted runner. It can solve the problem at least partially. I guess after this it would be logically to consider what targets going to be checked and when ( at push or at merge or whenever).

[vadorovsky]

@Arniiiii check out this PR #28 - I'm adding more architectures there. And we could discuss the details about CI there. 🙂

I don't think there is a limit of 2000 hours per month for free repos, or at least I wasn't able to find any information about that. According to https://docs.github.com/en/actions/administering-github-actions/usage-limits-billing-and-administration#usage-limits, the only limitation relevant to us is 6h limit per job - which we are not exceeding in any case so far.

[Arniiiii]

I don't think there is a limit of 2000 hours per month for free repos, or at least I wasn't able to find any information about that. According to https://docs.github.com/en/actions/administering-github-actions/usage-limits-billing-and-administration#usage-limits, the only limitation relevant to us is 6h limit per job - which we are not exceeding in any case so far.

Indeed. I was misled by their documentation at a github's CI/CD documentation page.

It seems for public repositories there's no such limit.

Then it seems that the only problem is to write a good enough CI script

@Arniiiii check out this PR #28 - I'm adding more architectures there. And we could discuss the details about CI there. 🙂

Indeed. I see you did a good job. I'm currently busy, maybe next weekends I can take a better look at what else can be done.

[thesamesam]

The CI failure at https://github.com/gentoo/crossdev/actions/runs/12083265774/job/33696034437?pr=24#step:3:3479 is really odd:

 >>> Emerging (3 of 9) dev-libs/libunistring-1.3::gentoo for /usr/aarch64-unknown-linux-gnu/
Unable to unshare: EPERM (for FEATURES="ipc-sandbox network-sandbox pid-sandbox")
!!! Fetched file: libunistring-1.3.tar.xz VERIFY FAILED!
!!! Reason: Insufficient data for checksum verification
!!! Got:      
!!! Expected: BLAKE2B BLAKE2S MD5 RMD160 SHA1 SHA256 SHA3_256 SHA3_512 SHA512 WHIRLPOOL

>>> Failed to emerge dev-libs/libunistring-1.3 for /usr/aarch64-unknown-linux-gnu/, Log file:

I don't see how that can happen unless the tree is broken, but it wasn't. I committed that ebuild in 1e31a6372a27b3d2508a5b9fd357cc23b320989d and the Manifest was there, and nothing changed afterwards either.

[vadorovsky]

I'm wondering if it has something to do to the fact I'm fetching my custom branch from github here:

crossdev/scripts/container_test.sh

Lines 109 to 111 in b66f902

	# FIXME(vadorovsky): Remove once https://github.com/gentoo/gentoo/pull/39280 is
	# merged.
	run_in_container bash -c "curl -L https://github.com/vadorovsky/gentoo/archive/cross-llvm.tar.gz | tar -xzf - --strip-components 1 -C /var/db/repos/gentoo"

I'm doing this to test my changes from gentoo/gentoo#39280 - it contains the necessary changes to bootstrap the full LLVM toolchain with crossdev.

Let my try rebasing my branch, but I still don't understand the error. It would mean that this ebuild is somehow broken on my branch.

I'm wondering if I have to do something else apart from unpacking the tarball to /var/db/repos/gentoo.

[thesamesam]

emerge-webrsync will use non-thin manifests, whereas yours will use thin.

[vadorovsky]

I see. Any ideas how to use my branch correctly then? I would like to avoid emerging git and eselect-repository. But if it's really necessary, I can follow https://wiki.gentoo.org/wiki/Portage_with_Git

[thesamesam]

I don't have a particularly good idea for now. Maybe have the CI script fetch from https://github.com/gentoo-mirror/gentoo (as a tarball) for now.

[vadorovsky]

Good idea. If we ditch emerge-websync all together and just use the tarballs from github, we could add an argument to the script for using a custom repo and branch, so testing custom trees would be possible without modifying the script itself.

[thesamesam]

That'd work for me. No real attachment to emerge-webrsync for this, it was just the first thing I thought of wrt the problem we had before.