On 3/20/24 12:38, Oliver Webb via Toybox wrote: > A target for the 0.9 release is the test suite running under mkroot,
On all the architectures mkroot supports (endianness, word size, kernel version), under qemu with a known kernel environment so we can test things like insmod with known modules, or test ifconfig and hostname without destabilizing my development laptop. > Which is also required > for passwd to be re-promoted (We need to test it in a vacuum). Eh, I can test that manually for one release. My problem is I keep getting distracted by tangents. The "create changelog" todo item made it as far as commit 40e73a387329 which has a pending TODO item I tried to fix (refill toybuf to try to span EXIF data when file is identifying JPEG files), I need to instead WRITE THAT DOWN (and leave it unfixed for now) and continue to the end of the list so I _have_ a current changelog and CAN cut a release... but haven't yet. > The main downside of this is that you have to look for the dynamic libraries > bash wants and > copy them into the fs directory, The code I wrote to do that way back when was something like: https://git.busybox.net/busybox/commit/?id=3a324754f88b I.E. recursively call ldd to see what its dependencies are, repeat until you run out of dependencies. I _can_ make this work. It's just not the direction I wanted to go in. and doing a chroot requires root permissions. Also it is very > clearly not a permanent fix (None of this is needed once toysh is ready), > just enough to get > tests for commands like passwd and chsh running. Another downside of > chroot-ing is you can't > emulate things that depend on drivers or nommu. > > Attached is a mkroot package (Not a patch), that sets up a environment to run > the test suite > under a chroot in. (./mkroot/mkroot.sh testwhost && sudo chroot root/host/fs > /test command_name). > It's not something I'm actually expecting to be merged, but that doesn't mean > it's not potentially > useful for testing the commands that modify /etc/passwd and friends. I was setting up a debootstrap to test it under, since that's presumably isolated enough, but last time I sat down to poke at that I got distracted into the Orange Pi 3b server setup which is the _other_ consumer of a debootstrap I have lying around, and then I went "too much for now but I can at least do the testing under a qemu-system-arm64 with devuan arm64 debootstrap" and hit the fact that trying to marshall a tarball into mkroot using "wget | tar xpv" spat out endless unexpected EOF files because the tarball autodetection logic had a regression and the child process thinks it's the parent process. Still have a tab open for that, trying to dig back down to fix it, been distracted by external pokes instead. > Also when making this I spotted some things in the build infrastructure we > will need to work around > in a airlock-ed test suite, test.sh needs configure, Only for single builds, not for testing all of toybox. And presumably I should add a TEST_EXISTING=1 to skip the single build and just grab the command out of the current directory and/or $PATH. (There's always more work to do on the test suite...) > and portability.sh needs something for CC or > else it will throw a fit. I know, one of my trees has a partial patch for it, but there's some design work... Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net