IRC channel logs

2021-04-21.log

back to list of logs

<OriansJ`>well I guess I'm just gonna wing it on the AArch64 upgrades in M2libc sys/stat.h
<OriansJ`>Hopefully if there is mistakes someone who knows better will fix it.
<OriansJ`>and prototype sys/stat.h for all architectures is now up in M2libc.
<OriansJ`>So assuming I didn't screw up too badly, I should be able to convert untar.c into something that M2-Planet can compile with M2libc
<OriansJ`>looks like I forgot to define mode_t
<OriansJ`>hmm, I wonder if "wb+" is meaningfully different than "w' in the M2libc context
<OriansJ`>as there is no difference between wb and w in M2libc
<OriansJ`>and w just means O_WRONLY | O_CREAT | O_TRUNC and w+ just means O_RDWR | O_CREAT | O_TRUNC
<OriansJ`>so untar is going to read+write to a file? that seems odd for an unpacker
<OriansJ`>well let us give it a try and see what happens
<OriansJ`>guess I need to add a prototype fread and fwrite
<OriansJ`>here is an extremely rough and probably broken prototype for untar.c in M2-Planet C https://paste.debian.net/1194483/
<OriansJ`>build with: M2-Planet --architecture amd64 -f sys/types.h -f amd64/Linux/sys/stat.h -f stddef.h -f string.c -f amd64/Linux/unistd.h -f stdlib.c -f amd64/Linux/fcntl.h -f stdio.c -f bootstrappable.c -f untar.c -o foo.M1 --debug && blood-elf -f foo.M1 --64 -o foo-footer.M1 && M1 --architecture amd64 --little-endian -f amd64/amd64_defs.M1 -f amd64/libc-full.M1 -f foo.M1 -f foo-footer.M1 -o foo.hex2 && hex2 --architecture amd64
<OriansJ`>--little-endian --base-address 0x10000 -f amd64/ELF-amd64-debug.hex2 -f foo.hex2 -o foo && ./foo example.tar
<OriansJ`>and the M2libc features required are prototyped and up
<OriansJ`>The GCC build appears to work fine, the M2-Planet build isn't exactly right but I'll try to iron out those last few details tomorrow (then you can finally get rid of most git submodules)
<OriansJ`>gcc build instructions are: gcc untar.c bootstrappable.c -o foo
<OriansJ`>I've probably just made a mistake in the M2libc functions I prototyped in a rush but it shouldn't be anything exotic to get it working now that it builds from M2-Planet and runs just not quite correctly yet.
<gforce_d11977> fossy: stikonas: pylint is now happy: https://github.com/fosslinux/live-bootstrap/pull/105 - i havent tried the 'sync' issue yet but will today
<gforce_d11977>changes: https://github.com/fosslinux/live-bootstrap/pull/105/commits/7e69dcc926f0b2f9124ba5e17f3e4958d08b512b
<stikonas>ok, thanks. I'll take a look later today
***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<OriansJ`>looks like I did fread wrong
<OriansJ`>but great news everyone
<OriansJ`>untar.c now builds via M2-Planet and M2libc and produces correct output
<OriansJ`>here is the modified version of untar.c https://paste.debian.net/1194568/
<stikonas>nice!
<stikonas>which repository is it going to?
<stikonas>(probably doesn't matter too much though)
<OriansJ`> https://paste.debian.net/1194569/
<OriansJ`>stikonas: I figure it belongs as part of the mescc-tools suite that fossy is building
<OriansJ`>as they are useful bootstrapping tools that M2-Planet can build early in the bootstrapping chain.
<stikonas>this allows switching to .tar distributions so much earlier
<stikonas>even mes can be distributed as .tar archive now
<OriansJ`>basically right after stage0-posix
<stikonas>although, we migtht have to ask for uncompressed releases...
<OriansJ`>as I can include this build in stage0-posix build targets
<stikonas>at the moment only mes-*.tar.gz is provided ftp://ftp.gnu.org/gnu/mes
<OriansJ`>until someone finds a good uncompress we can build with M2-Planet
<OriansJ`>or someone ports unxz to M2-Planet's C subset
<stikonas>or gzip is ported to M2-Planet
<OriansJ`>or just gunzip
<stikonas>well, yes, it's basically the same executable anyway
<stikonas>I think it just checks for argv[0]
<stikonas>but at the moment I only tried building it with tcc
<gforce_d11977>gunzip looks simple: https://github.com/lentinj/u-boot/blob/master/lib/gunzip.c
<stikonas>that's not the whole source...
<stikonas>I think most of it is in u-boot/zlib.h
<stikonas>well, I expect gzip to be a bit more complicated than tar
<stikonas>after all, tar files are basically human readable
<stikonas>it's just concatenation of all files with a bit of extra metadata
<stikonas>probably this is somewhat closer https://github.com/richgel999/miniz/blob/master/miniz.c
<stikonas>although, it might just be simpler to provide a couple of uncompressed tarballs in the bootstrap
<stikonas>mes and janneke's patched tcc 0.9.26
<gforce_d11977>stikonas: after further thinking about it: adding xz or gunzip is a bad idea, untar is more than enough, making things simple is a good idea
<stikonas>and luckily gzip is distributed in .tar format too
<stikonas>which is already used in live-bootstrap
<Hagfish>yeah, being able to gunzip is nice from a "code golf" point of view, but the early stages of the bootstrap are trivial compared to even the zipped later sources, and human-readability/simplicity seems like a more important goal
<Hagfish>* trivial (in terms of size)
<xentrac>if you *really* wanted to reduce the size of the early stages you could use LZW
<xentrac>a decompressor is like 40-100 lines of C
<stikonas>well, it will have to be in format that mes and tinycc-0.9.26 (patched for mescc) releases are made in...
<stikonas>in any case, even uncompressed tar would only add 5 MB or so to bootstrap sources
<fossy>it dosent matter too much /what/ compression/archviver is used but what formats things are distributed in