IRC channel logs
2023-01-24.log
back to list of logs
<stikonas[m]>Though I actually don't remember if cp file dir works <nektro>i was checking it out because i tried to do 'cp dir dir' and it segfaulted and discovered its not supported <stikonas>nektro: oh cp dir dir is not supported even by normal cp <stikonas>and the one from mescc-tools-extra is far more dumb <stikonas>we basically just use it to copy cp file1 file2 <stikonas>touch we can actually just use catm for that purpose <stikonas>fossy, doras: so far removing build of doc from automake seems promising <nektro>oh you're so right heh, i forgot to inlcude * at the end for the sources expansion <oriansj>nektro: well if you look above: dest[strlen(dest) - 1] == '/' would set it to true; so yes it would be correct for the case when something is not a directory <stikonas>even cp from coreutils has no idea what * is <oriansj>and cp in mescc-tools-extra is just copying the contents of one file to another; we don't even properly set file permissions and file ownership <nektro>yeah im using bash as the runner in the place where im calling cp <stikonas>well, bash might expand * into multiple arguments <stikonas>but that will confuse cp from mescc-tools-extra <stikonas>hmm, actually removing "doc" from SUBDIRS in automake/Makefile.am exposes another intermittent failure, probably will take tike till I can sort this out :( <stikonas>oh, actually, maybe I'll have a fix for it... <stikonas>I stupidly edited Makefile.am after running ./bootstrap <nektro>anyone have off hand the _def for COPY_rsp_to_rbp ? <stikonas[m]>nektro: note that i'm slowly replacing these with mov_rbp,rsp <doras>fossy, stikonas: it seems that we keep around all the Python versions installed in parallel in the final system. Is that intentional? <doras>I think you also package up and install Python's tests. <doras>The final system jumped from ~471 MB to 1.1 GB after cleanup of /usr/src and /distfiles with the Python addition. <doras>I also see a bunch of .py files installed under /usr/lib/python* that I don't see in my Fedora installation for example. <doras>I could be wrong, but I think xbps did this automatically <doras>Or at least this was my impression at the time <doras>Well, almost half of the added size is what appears to be Python tests alone. Perhaps we're installing a bit too much? <stikonas[m]>Perhaps we can add upgrade function to helpers.sh that takes 1 extra argument (package to remove) <pder>rickmasters: I recently fetched your latest boot2now and builder-hex0 projects and was excited to see Fiwix build under your kernel. Outstanding work! <rickmasters>pder: thanks! I'm hard at work building a file system for it and trying to boot it. <rickmasters>I've also been able to sort of boot Fiwix but I'm running into problems which is not a big surprise. <rickmasters>It only boots with kvm disabled and there are issues with the ext2 drive that I'm working through. <pder>Interesting, are you using qemu to boot Fiwix? <rickmasters>This is a kexec style transition from builder-hex0 straight into Fiwix but yes the whole thing is under qemu. <rickmasters>In other words, it's not a separate qemu session. That already works - even with kvm. <pder>So, is it currently possible to launch live-bootstrap with this Fiwix kernel in qemu mode? <rickmasters>Yes. But that's a hack job I've done for my own testing and haven't shared yet. <rickmasters>It requires some modifications to prepare an ext2 initrd, which current live-bootstrap doesn't support. <pder>so it sounds like some addtional tools will needed to be built after tcc but before booting Fiwix? <rickmasters>Right, that's what I'm working on. A tool which creates an ext2 ram drive and another program which loads Fiwix and the ext2 into memory and jumps to the new kernel <rickmasters>Thanks. The plan was coming along smoothly until the Fiwix boot problems. With kvm enabled it can't write to the serial port and hangs detecting the floppy. <rickmasters>Works fine with kvm disabled so I may have to dig into qemu next which I'm not really looking forward to. <pder>I dont know much about kexec, other than it might have some challenges booting Fiwix when hardware is in an unknown state, vs an actual reboot <rickmasters>pder: Yes, that's exactly the issue. The thing is - builder-hex0 doesn't mess with the hardware much at all - certainly not the floppy. <rickmasters>pder: The hardware state issues was something I'd read about as a potential problem for kexec of Linux but I wasn't expecting it here. <rickmasters>builder-hex0 doesn't use the serial port either. It uses bios interrupts to display to the console. <pder>have you tried doing a kexec from Linux to Fiwix? <rickmasters>No. That would be an entirely different method I'd have to write. <rickmasters>My current tool for builder-hex0 does the setup and launch of Fiwix from user land which is possible because there is no memory protection <rickmasters>It's not kexec, it just doesn't do a hard reboot which is similar, in that way, to using kexec <stikonas>fossy: so python versions between 2.3.7 and 3.1.5 all have the same problem as curl <fossy>stikonas: ah, that's unfortunate, would you like to fix that or shall i? (python, that is) <fossy>also, gcc 10 is coming along nicely <stikonas>fossy: getting close to done with gcc 10? <fossy>gcc 10 is really slow to compile though <stikonas>maybe do gcc 10 PR first, before doing gcc 12 <fossy>hmm, its hard to see the finish line, because im not sure how far through the build im getting right now <fossy>but yeah, i will pr 10 separate to 12 <stikonas>I noticed on my Gentoo system too that gcc is not fast to build these days <fossy>there's a few gcc arguemnts the build uses that arent supported by gcc 4.7, but most of those can either be easily patched out or added as an no-op to gcc 4.7 itself <stikonas>I was playing a bit with python packages that live-bootstrap provides though so far unless they are installed into /usr, I can only run them with bwrap <stikonas>with something like "bwrap --bind . / bin/python3" <stikonas>so that directory where musl and python are unpacked is mapped to / <fossy>hmm, that is a little unfortunate <stikonas>I wonder if there is a away to tell python to run from elsewhere <stikonas>previous static binaries were very nice as they could be run from anywhere <fossy>perhaps after gcc i might try static python again, but only for newer pythons... i gave up because the support for it was absymal, but it might have improved since 2.5 when it just wouldn't work <stikonas>anyway, I should first look at reproducibility issue <stikonas>there are command line args --enable-ipv6 <fossy>hopefully that is sufficient and python's build system doesn't do any stupid stuff <stikonas>yeah, I think it's just another case of automagic dependency <mihi>Also, I cannot find where the type of a BLOB is set to PROCESSED, also when reading type, sometimes it is treated as a bitmask (i.e. NEWLINE is also PROCESSED) and sometimes not. <mihi>probably nobody ever uses DEFINE token "some string"? <stikonas>no, so far they are all DEFINE token string