IRC channel logs

2021-10-10.log

back to list of logs

<vagrantc>are there releases of mescc-tools somewhere other than github? the github tarball doesn't include the M2lib git submodule ...
<stikonas[m]>Either forgotten or you need to get M2libc separately
<stikonas[m]>oriansj, which one it is?
<vagrantc>githhub doesn't typically auto-generate tarballs with submodules, so i think you have to manually generate and upload a thing if you want that
<vagrantc>i can work around it in debian with multiple upstream tarballs; it's only minorly troublesome :)
<oriansj>vagrantc: the master repo of mescc-tools is savannah: https://savannah.nongnu.org/projects/mescc-tools
<oriansj>as it says in the readme
<stikonas>well, in any case there are no tarballs that include m2libc inside mescc-tools
<oriansj>also since Debian branched mescc-tools, adding the contents of M2libc in a commit and adding a script to update those files would certainly be a valid solution.
<oriansj>but I choose not to deal with that maintance task.
<stikonas[m]>fossy: chroot build and works fine in live-bootstrap
<stikonas[m]>Maybe tomorrow I'll try to chain sysa and sysc internally
<fossy>ok, nice
<vagrantc>oriansj:
<vagrantc>oriansj: oh! somehow i missed that
<vagrantc>oriansj: easier thing is to just generate a tarball from the appropriate M2lib commit, which i did for 1.3 upload to debian experimental
<oriansj>45:09.43 down to 14:03.24 on the raspberryPI
<oriansj>vagrantc: you know better about debian than I and I trust that you'll do the right thing
<vagrantc>there is no "right" thing to deal with git submodules in debian, there are some good enough things, though :)
<oriansj>and now all bootstrap seeds execute kaem.${ARCH} instead of kaem.run
<oriansj>fair, they also tend to catch people who just do git clone; so in a few places I had to create notes to alert users.
<oriansj> https://github.com/oriansj/stage0/blob/master/vm.c#L27
<vagrantc>did i overhear that mescc-tools 1.3 requires changes to mes to build or something? or should that still be compatible?
<oriansj>vagrantc: yes adding support for RISC-V required breaking changes in mescc-tools
<oriansj>So to build mes.c (mes-m2) from M2-Planet requires changes in the build script (which is already done) and changes in MesCC itself (patches were posted today by me, just need janneke to merge)
<vagrantc>ok, good i uploaded to experimental rather than unstable, then :)
<vagrantc>and ... RISC-V !!! :)
<oriansj>yeah it break mes *HARD*
<oriansj>the big change is considerably better support for word based architectures
<oriansj>So things like SPARC, MIPS, PowerPC, Itanium will be much easier to port support for in mescc-tools and M2-Planet
<oriansj>If I get the time, I'll probably do a DEC Alpha port and try to convince my wife to let me buy some old hardware to play with.
<vagrantc>oriansj: are the patches for mescc posted publicly?
<oriansj>yes on this very channel http://logs.guix.gnu.org/bootstrappable/2021-10-09.log with the link https://paste.debian.net/1214862/
<oriansj>I do have janneke's contact info in Signal, so in theory I could message him or call him to suggest incorporating the patch. But I am hoping he reads IRC messages tagged with his name as I did earlier
<vagrantc>ah
<vagrantc>maybe could also mail bug-mes@gnu.org
<oriansj>I guess it would be polite to do so
<vagrantc>that's a pretty smallish patch, at least
<oriansj>done
*vagrantc does a test build applying the patch to mes 0.23 ...
<oriansj>well the changes are tiny. use --little-endian arguments instead of --LittleEndian arguments to remove the warnings and add --little-endian to blood-elf's arguments to address the only breaking change in the release
<oriansj>one of these days I really need to find time to finish the ARMv7l port of stage0-posix
<vagrantc>well, i can confirm the patch works :)
<oriansj>good
<janneke>oriansj: will do, thanks for the headsup!
<janneke>oriansj: it looks like some release tags (notably Release_0.8.0, Release_0.9.0) are missing from http://git.savannah.nongnu.org/cgit/mescc-tools.git
<janneke>oh wait, dunno where i got those from ;)
<oriansj>janneke: only annotated tags get pushed, So any other tags are those that you made for yourself
<oriansj>possibly to build tarballs for the distribution with MesCC as there are no references to them in the CHANGELOG and the commit history shows mustly just kaem work between them. None of which would help MesCC do anything other than having a nicer kaem build script.
***janneke is now known as janneke[cm]
***janneke[cm] is now known as janneke_
***janneke_ is now known as janneke
***ChanServ sets mode: +o janneke[cm]
<fossy>stikonas[m]: looking at your PRs now
<fossy>your kernel works with this PR w/out using deblobbing
<stikonas>moving chroot was less messy than I initially thought
<fossy>if you use deblobbing then it runs out of ram
<stikonas>oh I see...
<fossy>i'm trying to compile gawk now to save on RAM
<fossy>because sed uses like 2+ GB of RAM doing the deblobbing
<fossy>(this PR = 139)
<stikonas>fossy: maybe 4096 MB ram?
<stikonas>not 4000\
<fossy>hm, yes
<fossy>i don't think that will help with sed
<stikonas>yeah, sed is probably just too wasteful
<fossy>oops, forgot to shell and pylint
<stikonas>yeah, other than that looks alright
<stikonas>fossy: don't we have gawk already?
<stikonas>or is it too old?
<fossy>yes but it's too old
<fossy>or tcc dodgy, can't remember which
<stikonas>or could be makefile rather than autotools build dodginess
<fossy>could be that too
<stikonas>anyway, we should be able to build much newer gawk by that time
<stikonas>with gcc and autotools
<fossy>unfortunatley, that does not seemto be the case, it's only 0.1 version higher
<fossy>because even old versions require new automake
<stikonas>hmm, it should be possible to move newer automake back a bit
<stikonas>and build before linux
<stikonas>hmm
<fossy>maybe, if this works can just leave it, otherwise i'll look into that