<stikonas>fossy: well, I'm also trying complete rewrite of the whole rootfs... <stikonas>I think we were also creating quite a few unnecessary sumbolic links <stikonas>although, like I said, I might have a full rewrite of rootfs program anyway <stikonas>well, I think we are reaching the limit where bash is maintainable... <fossy>are you rewriting in a different langugage <fossy>just it needs to be kept simple <stikonas>yeah, I'm trying to make it much more structured <fossy>people need to be able to make a rootfs by hand without too much work <stikonas>which let's running a few bootstraps simultaneosly <stikonas>actually, I'm even trying toremove some unnecessary steps that we were doing <stikonas>also remove all symlinks from preparation step <fossy>from when other things were done <stikonas>and in some place I'm just installing into another dir <stikonas>well, some things are a bit more complicated than in bash... <stikonas>but in general I think there is more flexibility <OriansJ`>janneke: if you remember mes-m2 is pre-guix and that we previously worked together to setup mes-m2 with a copy of mescc that works with the exmaple commands in the README; however it appears the version of mes.c that is buildable by M2-Planet and able to build TCC; unfortunately includes a version of mescc that isn't runnable by guile. <OriansJ`>but it is not able to build TCC with the version of mescc we previously setup. ***lukedashjr is now known as luke-jr
<gforce_d11977>good morning(here), after having a 500 (!) full ci-runs, the bash-issue seems solved (adding "sleep 15" after "sync" in bash-5.1.sh), so i will have another try with shorter sleep... <gforce_d11977>stikonas: fossy: bauen1: pder: i really have no explanation for that: we do not make parallel runs, there are no concurrent programs/jobs, it's just a single-core-qemu run, it's a RAM-Disk: how is it possible, that we have variations? <gforce_d11977>i'am glad to help further and have now an easy setup for making parallel qemu invokations (48 at the same time, so ~500 runs in 5 hours) <gforce_d11977>bauen1: Q: "are compute resources an issue for you at all ?" -> i'am unsure what that means? i have several "strong" computers, if you need SSH access, no problem: or maybe even an external host with github actions? <stikonas>gforce_d11977: thanks for testing parallel runs. So I guess we have 3% failure rate or so... <gforce_d11977>stikonas: regarding coreutils6: why do we install date? wouldnt it be better to use a stub like "#!/bin/sh\necho 2000-01-01" or something alike? <gforce_d11977>or in other words: do you know which package *needs* the 'date' program? <stikonas>gforce_d11977: nothing needs and nothing uses it... <gforce_d11977>in steps.rst, there is also "mktemp" and sha256sum mentioned, but i dont see them in main.mk?! <bauen1>gforce_d11977: i was just wondering since you're doing so many full runs <bauen1>gforce_d11977: timing can still cause variation in the runs <gforce_d11977>bauen1: i was unsatisfied with not finding the reproducibility issues and wanted *results*. having many qemu instances running seemed like an easy option. <bauen1>maybe there are some options to make the qemu runs more "volatile" to make it easier to reproduce the issues <gforce_d11977>but timing should NOT be an issue, only if any built piece uses timestamps <bauen1>gforce_d11977: i'm more thinking about race conditions if a `sleep 15` solves some of the issues <gforce_d11977>bauen1: if we just copy kernel + initrd to uniq files and boot them, then i can not imagine any race cinditions <bauen1>you're running the VMs with KVM i suspect ? <bauen1>maybe you can try a few runs without kvm and see if the issue can still happen (but that's just a semi random idea of "throw everything at the wall and see what sticks") <bauen1>gforce_d11977: it's quite possible that you're hitting a bug in some of the software <bauen1>and race conditions can still happen in a single core because you still have multiple processes <bauen1>gforce_d11977: and for the nothing to be done for all you could try to run make with --debug to have it show **why** it thinks it doesn't need to do anything, that could very well be a timing issue <bauen1>btw does anything in the build rely on random data ? (/dev/{,u}random, getrandom) <gforce_d11977>'git grep random' only shows, that run.sh makes the devnodes <gforce_d11977>stikonas: which program uses /dev/random and/or /dev/urandom ? we do we need them? <stikonas>e.g. openssl might be very unhappy without random <gforce_d11977>thats terrible. we have too many things "just build" or enabled, which are not really needed <stikonas>they will be built anyway just a bit later if we exclude them <stikonas>once we build next coreutils with autotools <stikonas>but yes, some of them were built as a test <stikonas>e.g. seq is probably not used, but it was good to figure out some mes bug <stikonas>bauen1, gforce_d11977 : since that race affects bash 2, it'ls likely to be related to mes libc <stikonas>although, might be something wrong in old bash too, but less likely <fossy>stikonas: feel free to PR your python thingy whenever ready <stikonas>fossy: yeah, I'll first do tar-1.34 this evening <fossy>there are 50000 different versions of it, people applying patches here and there, inconsistent results, etc, etc <stikonas>if that's so bad, another option is to build 5.8 using our method <fossy>also Perl's configure explicitly says "feel free to submit patches against this generated Configure" <fossy>i'm trying this thing that might work according to the README but if it dosen't then i'll just do that <stikonas>fossy: maybe it's worth asking on some perl channel? how do you rebuild Configure? <stikonas>although, if it's partially generated, partially handwritten, that's a real mess <bauen1>O_o that's some mad scientist level madness <OriansJ`>never under estimate the lengths programers go to avoid having to write code. <fossy>stikonas: i think i will be told "Don't" <fossy>however i have got Configure working <fossy>but config_h.SH is not generating <bauen1>i've now switched to using upkgs/$pkgname-$pkgversion-$versionsuffix <bauen1>that allows e.g. to "link" multiple packages at once etc.. <stikonas>fossy: by the way, which version of python is that? <bauen1>fossy: because we do sometimes have multiple of those and they can interfer with each other ... <fossy>i just patched out the check <stikonas>after all, it worked in earlier pythons too <fossy>python getting to the brain :P <stikonas>not sure which python... In my day job we also use some python <stikonas>other languages too, but right now I'm doing something in python <stikonas>fossy: I saw some strange restriction on perl on gcc page though <bauen1>stikonas: looks quite nice, ideally i'd want a way not to use sudo and to invoke mount / umount directly, and the not mounting a tmpfs won't work quite yet <stikonas>but I think it says Perl 5.6 - 5.24 or something like that <stikonas>bauen1: well, at the moment it's the same as rootfs.sh in regards to mount/unmount <stikonas>(just probably slightly better unmounting because it is int the destructor) <stikonas>but yes, it would be nicer to avoid sudo <stikonas>(without making the whole thing run as root) <bauen1>stikonas: sudo breaks with user namespaces as i'm currently using them, so i have to edit rootfs.sh to fix things <bauen1>but yeah i'll see about making a nice commit of my user namespace thingy <bauen1>currently even chroot still has network access <bauen1>i think seperating the downloading and the chroot creation (copying and extraction) part would make things easier, or i need to figure out why tar starts complaining about invaid uids when run with unshare --map-root-user <stikonas>is that host tar used to unpack first tar-1.12? <bauen1>user namespaces messes with tar trying to chown things i believe <bauen1>yes, tar tries to chown 1000:1000 , which won't work in the user namespace <bauen1>oh, gnu tar is smart and if run as root tries to chown, which it doesn't as normal user <bauen1>so i'd have to add `--no-same-owner --no-same-permissions` in the rootfs script invokations of tar (and possibly inside the chroot too) <stikonas>anyway, it might be that nobody just updated the page <stikonas>just like perl's regen_perly.pl unnecesserily limits bison versions <bauen1>uhm, interesting looks like the makefile generated for autoconf-2.13 does not support DESTDIR ._. <stikonas>bauen1: oh, worth looking at what distros do <stikonas>after all, they do install autoconf-2.13 <bauen1>i'll try to just supply prefix="${DESTDIR}${PREFIX}" into the Makefile, easier than doing a proper patch for now <bauen1>yeah this will achieve the same thing <pder>gforce_d11977: How do you reproduce the issue with pipesize.h having the wrong value? Do I need a specific kernel? What percentage of runs are you getting the failure? I'd like to try to build a simpler test that I can run repeatedly and quickly. <gforce_d11977>pder: i cannot reproduce it. about 3-6% of all runs are affected. i change the minikernel ("./rootsfs.sh minikernel") to this invocation: <gforce_d11977>(my qemu has no support for --cpu 386, so i have to go for 486) <gforce_d11977>but maybe it does not help you: i added some debug stuff to the scripts, e.g. cat pipesize.h and base64 /after/bin/bash <pder>Do you get 512 for pipesize when it fails? <gforce_d11977>(sorry, cannot find other logs for now, i have some where do "cat pilesize.h" and you can see #define PIPESIZE 512 <stikonas>gforce_d11977: maybe you can open issues on gh with all intermittent errors you found (one issue per error)? <stikonas>we have no way of reproducing, but at least something not to forget... <bauen1>^ with links to the logs, and in the best case the binaries that have a sha256 mismatch <bauen1>btw intercity-vpn.de doesn't have https <bauen1>so the next problem i'm facing is that while the autohell binaries have a version appended the info files don't so they woud conflict if i try to link autoconf-2.53 and autoconf-2.52 at once <bauen1>i don't think we need them, but i'll just stuff them into $prefix/info/autohell-$ver/ instead <gforce_d11977>stikonas: good idea, i will open issues for all these things <bauen1>so this might take a bit longer, i need to change the way checksums work <bauen1>is there any reason why we're not using pushd / popd in the bash scripts ? <stikonas>it might be better if we do, but first test if it works... <stikonas>I initially wanted to do it with subshells for cd but that was not working well <stikonas>(subshells in principle have the advantage that whatever package does would not polute other packages) <stikonas>but traps were not working well in bash2, so I couldn't get subshells to work properly with errors <stikonas>anyway, feel free to fix it. That looks like a good thing to do <gforce_d11977>if you ask me, i'am against using very special bash features (popd/pushd), i still like the idea auf using a posix shell for bootstrapping. just saying... <bauen1>gforce_d11977: i'm using it to change directory to DESTDIR before invoking sha256 sum, maybe there is a better way ? <bauen1>and that still requires me to go edit every checksum file to remove the leading / <bauen1>uh and what ever is using helpers.sh doesn't support pushd / popd :D <stikonas>bauen1: and when I used destdir with autotools packages to create checksum files, I had to add leading / to all of them... <stikonas>well, popd/pushd wouldn't be too much of a problem on posix shell... <stikonas>it's very easy for somebody to implement in pure posix... <stikonas>something like store $PWD in a variable and change back <stikonas>and it looks like bauen1 might need to do something like that anyway <bauen1>stikonas: it's a bit more than that you need to implement a stack <bauen1>but yeah i'm trying `cd $DESTDIR ... cd -` now <stikonas>well, if you need it more than 1 depth... <stikonas>I'm sure there must be already some stack implementations in posix shell that one can "steal" <bauen1>mostly how i can adapt earlier packages to also use /after/upkgs and it's a bit messy <stikonas>bauen1: we can probably put some of it into build function? <bauen1>stikonas: yes, i'm thinking about that <bauen1>for now i want to get a working prototype and then i'll try to make a general solution <bauen1>but deciding what package to link / unlink and at what point probably needs to be in run.sh for now, unless i want to go all in and build things in a chroot <stikonas>well, maybe we can have a few different wrappers... <stikonas>link/unlink I guess doesn't have to happens at the same time? <stikonas>build automake-1.6.3-stage3; remove automake-1.6.3-stage2; install automake-1.6.3-stage3 <gforce_d11977>bauen1: without pushd/popd you also just do MYDIR="$PWD" and late cd $MYDIR <stikonas>gforce_d11977: yeah, that's what we talked about earlier... <bauen1>that's kind of what i'm doing just with --stow for linking and --delete for unlinking (stow terminology is a bit weird) <stikonas>that's why I'm thinking that we should abstract it out in more "package manger" usual terms <stikonas>all of them can probably be very short wrapper functions... <bauen1>i just couldn't be bothered to try to do long options parsing for a wrapper, and want to keep the ability to do multiple "operations" in a single invokation, e.g. when we need to change perl <bauen1>but yes i see what you're getting at ***sm2n_ is now known as sm2n
<bauen1>see OriansJ` message about programmers avoiding to write code at all cost above lol <stikonas>e.g. replace wrapper takes two arguments (pkg2, pkg1) <stikonas>well, but once you have your wrapper, I guess it's easy to add another layer... <stikonas>which makes calling your wrapper easy... <stikonas>multiple operations (to change perl) is a good point though <bauen1>i can add short cuts on top of the upkg_stow_wrapper1 it's the smallest common denominator for all operations <stikonas>well, we can think about interface a bit later... <stikonas>I just want those run.sh scripts to be very readable... <stikonas>e.g. like now everything is done by a single build keyword <stikonas>obviously you need more keywords if you have packages... <bauen1>another thing that i then want to do (probably requires chroot to do properly) is have `build` (or upkg-build) take a hash of all dependencies, build script and source, and store them, so we can skip the build if everything is the same <bauen1>and a hash of the result (probably just tar up /upkgs/$pkgname... as a pseudo package format) <bauen1>doing so obviously requires a decent tar that can build the result reproducibly <stikonas>I also want to add tarball checksums inside chroot... <stikonas>well, first of all we need to add SHA256SUMS file in (which I added in rootfs.py) <bauen1>also having "packages" of the earlier parts is required if we want to build later packages in a chroot, so there will probably be a lot of very ugly `ln` mess <bauen1>so make doesn't handle a missing command too well: `make: *** [scan.c] Segmentation fault` <fossy>hmst, I dont think packages are very doable in the earliest parts <bauen1>fossy: it's mostly installing to /after/upkgs and creating symlinks to it, it's certainly messy, but then you can wipe any trace of the early broken things with a short command <stikonas>well, we can rebuild most of the early packages later... <bauen1>alternatively hunt down what you need later <bauen1>currently i'm kind of aiming for chroot after perl-5.6.2 because then we have stow and write a small chroot / mount wrapper in perl <stikonas>fossy: I'm now continuing with roofs.py, got working up to tar-1.12, so almost done. Currently thinking about API for get_file function...