<stikonas>fossy: I've pused a few more changes to XZ branch, basically autoconf-2.69 and automake 1.11.2. I think Autoconf is now new enough for absolutely everything. But automake is a bit older... ***mephista is now known as spicy_icecream
<gforce_d11977>so we/you/I can fix this by using the full path or fix globbing. maybe it breaks also other things and we should really make sure, that the whole script also works with other shell interpreters and also without rich features aka globbing 8-) <gforce_d11977>also all these script should be shellchecked, e.g. this one throws warnings when checked manually <gforce_d11977>stikonas: i bet it is a missing syscall support in my kernel, but relying on such things should be avoided, i will now try a full run with these special globs removed and report <gforce_d11977>for full reference: simple globbing works, e.g. ls -l *.sh, but this does not work ls -l */*/foo <stikonas>well, bash 2.05b implements globbing itself, it does not rely on C library (meslibc does not have globs anyway). You can check which syscalls it uses <gforce_d11977>stikonas: it is not worth the hazzle, we just avoid these special globs and document this <stikonas>hmm, not sure why one vs two stars would matter <stikonas>bash just seems to recurse to the same function if there is more than one <stikonas>gforce_d11977: try glob with one start but on dir names <stikonas>it might be that globbing files works but not directories <gforce_d11977>bash -c 'mkdir /after/foo; touch /after/foo/bar; for F in /after/*/bar /after/foo/b*; do echo $F; done' <stikonas>so I think directory globbing function only uses stat call <gforce_d11977>in the long run this makes our upcoming replacement OS easier to implement 8-) <stikonas>well, I'll let fossy to devide, since he was working on bootstrpa kernels more <stikonas>I think the plan was to build kernel before bash <stikonas>but it's possible to just hardcode all those files we want to delete <gforce_d11977>i dont think about a linux kernel, but the approach of gio alike <stikonas>by the time you build bash, I think it's almost sure that you need fairly advanced kernel <gforce_d11977>ofcouse, but if the OS does not have to implement the syscall, it makes everything easier <stikonas>but it's not the only place where we glob dirs <gforce_d11977>than this needs fixing and i'am searching now for all the places <bauen1_>stikonas: you don't need a very complex kernel ***bauen1_ is now known as bauen1
<bauen1>as long as you don't need anything interactively it's very simple <stikonas>yes, but replacing all directory globs is a bit messy <stikonas>in case of automake, it might not be too bad <gforce_d11977>stikonas: but files are working, its only the directory name which is not working <stikonas> lib/*/*.pm is globbing over directories <stikonas>still a bit unsatisfactory if we have to hardcode them all <stikonas>well, according to bauen1 I guess it's not too hard to support <gforce_d11977>bauen1: do you now, which kernel CONFIG_SYMBOL is needing for supporting dirglobs? <bauen1>gforce_d11977: no, but if you have a certain syscall in mind that narrows it down a lot <bauen1>gforce_d11977: do you have your kernel .config available ? or is your kernel compiled with CONFIG_COMPAT ? <bauen1>actually, it would help me much more if i could get an strace log of your bash invokation (as i can't reproduce it either) <bauen1>and i don't see anything suspicious tbh, bash only uses opendir / readdir for the glob matching <bauen1>stikonas: right, and that is probably where it fails to detect that foo is a directory <bauen1>and my comment was more saying that to support non-interactive bash you probably don't need a very complex kernel as it's hardly more than: basic filesystem io, some process management (the hard part), and a few other bits and pieces <bauen1>i really should invest a bit more time into my kernel <bauen1>i've already gotten one of the three big problems mostly done, a decent vfs implementation with full mount support (so chroot should be very easy to pull off), it's just missing syscalls and a concept of a "process" <stikonas>yeah, but I guess detection of whether something is dir should work in your kernel, once syscalls are there <bauen1>yes, testing what type a filesystem object has and "reading" a directory as such basic operations that it's confusing why bash would fail there <bauen1>is /dev/console actually used for something in the baremetal target ? <bauen1>and i have the same question for /dev/{,u}random <bauen1>hm, shiny we have ci for baremetl <bauen1>i suppose it's just a matter of waiting for an hour to find out then <stikonas> /dev/console might be used once we have interactive bash session <bauen1>hm, /dev/console is the only thing i wouldn't want to bind mount into my "container" <stikonas>unlike /dev/console which might only be useful after bootstrapping <gforce_d11977>yes...i will try to add networking, so that i can copy out the full strace <stikonas>you can use tmux commands capture-pane -S 60000 and ^b save-buffer <stikonas>(networking might not work on your minimal kernel) <pder>that number after capture-pane should have a minus in front of it. capture-pane -S -60000 will capture 60000 lines of your scroll back buffer. <bauen1>stikonas: everything else can be bind mounted <bauen1>but as user namespaces aren't running as root you won't have access to /dev/console <bauen1>i mean i could still bind mount it, would just be pointless <bauen1>and even for a normal chroot it would be "useless" <stikonas>well, it's mostly created for real systems <bauen1>even then you'll have stdin/stderr/stdout already attached ? <bauen1>any reason to use a version linux-image instead of linux-image-amd64 ? <stikonas>I think fossy originally wrote version of linux-image <gforce_d11977>the readable output is ofcourse "/after/*/buzz" (the last lines of strace) <bauen1>so it appears that musl builds are run in bash with -e so if `test -f /dev/null` fails, the whole build will fail <fossy>gforce_d11977: stikonas I am.cm unconcerned aboi <fossy>currently unconcerned about features in kernels post make <fossy>because that is when we get new kernel in my indev branch <fossy>and we can put whatever features we need there <pder>stikonas: what was the reason you preferred building bash before gcc? <bauen1>fossy: where is your indev branch ? <stikonas>pder: new bash 5.1 segfaults with some constructs <stikonas>when I try to use stuff like ${var#glob} <stikonas>maybe we should instead downgrade that intermediate bash to bash 3.2.57... <pder>is this because technially we shouldnt have gcc 4.0.4 yet? <fossy>ill push it once kexec tools works <stikonas>so I'm trying to build more stuff pre gcc 4.0.4 <fossy>I am close I think I just have to go to a very old version <fossy>Using 1.101 purgatory makes it hang rather than crasu <stikonas>and that probably means building guile 3.0.2 (that has pp-bootstrap solved) <pder>So we need a version of gcc that doesnt require autogen but is new enough to build guile? <bauen1>i'm build a demo upkg that can build the chroot (which requires chroot binary at least) and mount + bind mounts would make things a lot easier / cleaner <stikonas>bauen1: you can easily add chroot binary to coreutils <pder>The gcc docs indicate we only need guile 1.4.1 or later <stikonas>pder: our options are only guile 1.0 or 3.0.2 <pder>where is all the info about 3.0.2 and pp syntax? <stikonas>mihi did that and emailed to bootstrappable mailing list <bauen1>and tbh i would much rather use bind mounts, as mknod won't work with user namespaces, and some things need parts of /dev to build <stikonas>bauen1: well, but I would like to keep an option to bootstrap stuff on empty baremetal system <stikonas>so some kind of support for both would be nice <stikonas>well, at the moment all mknod stuff is behind test -c <stikonas>i.e. if it's already bind mount, nothing will be done <pder>thanks, thats good news about guile. Hopefully 3.0.2 is buildable with 3.x gcc or tcc <stikonas>pder: well, trying, it needs a bunch of dependencies <stikonas>I'm having more trouble with libunistring <pder>guile 3.0.2 wants automake 1.16.2- do you think that's doable? <stikonas>maybe some minor perl tweaks to build more modules <stikonas>possibly even patchable to older automake <pder>I was looking at Makefile.in, but I dont think the version number in there is relevant. <stikonas>it's the one that was used for generation <stikonas>so I've finally built slightly patched libunistring-0.9.2.1 <stikonas>we probably need to build a lot of stuff... <stikonas>I suspect building gcc 3 will be easier...