On 29/10/2024 18.58, Rob Landley wrote:
On 10/24/24 03:27, Thomas Huth wrote:
Now that we are aware of binaries that are available for sh4eb,
we should make sure that there are no regressions with this
target and test it regularly in our CI.
Any progress on restoring this? Didn't see it in "git pull" just now...
I'll make sure to put the patches in my next pull request before the QEMU
soft freeze starts next week.
+class R2dEBTest(LinuxKernelTest):
+
+ ASSET_TGZ = Asset(
+ 'https://landley.net/bin/mkroot/0.8.11/sh4eb.tgz',
+ 'be8c6cb5aef8406899dc5aa5e22b6aa45840eb886cdd3ced51555c10577ada2c')
Feel free to pull binaries from my site, but from a reliability perspective
"some random dude got hit by a bus so a site went down that broke our test
infrastructure" seems a bit dodgy. (Even the Internet Archive has been
having reliability issues of late, and "as long as Brewster Kahle's dot-com
money holds out" seems a similar bus number.)
Building it yourself from source seems more reliable. Is there any sort of
policy here?
We don't really have any infrastructure in place for building such assets
within the QEMU CI, but the binaries get cached locally after the initial
download, so we should at least be able to retrieve them from these caches
in case your original site becomes unavailable ...
And even do automated smoketests on them showing it can boot, run a shell
script, and access a virtual block device and network connection:
https://github.com/landley/toybox/blob/master/mkroot/testroot.sh
... but if you're using github anyway, maybe you could also build the
binaries via github actions and publish the assets there? That would make it
easier for cloning and reproducing the stuff, I think.
Anyway, thank you very much for providing the binaries already on your site,
that's really helpful!
Thomas
