IRC channel logs

<oriansj>vagrantc: everything that is a git submodule in stage0-posix/mescc-tools/M2-Planet/M2-Mesoplanet can be packaged separately and M2libc can be substituted by any other libc when using a compiler different than M2-Planet

<oriansj>the only bits you might need to copy are: M2libc/bootstrappable.c and M2libc/bootstrappable.h

<oriansj>the issue of distributing source code resolves down to you need a trusted way to get source code and the bootstrap-binaries onto a computer you trust. So how you get stage0-posix is the issue you the bootstrapper need to solve. After stage0-posix, you can just use sha256sums to validate the steps after that

<oriansj>Hagfish: now that is the least accurate xkcd in relation to bootstrapping I have seen.

<oriansj>this one however seems on track: https://xkcd.com/2347/

<oriansj>stikonas: technically it isn't stage0-posix that has a cyclic dependency but rather bootstrap-seeds and that is a non-issue

<oriansj>Hagfish: and your paranoid worries is extremely healthy for this community to keep the progress honest.

<oriansj>it is up to us to both solve the technical problems that show up and to the bootstrap honest

<oriansj>^to the^to keep the^

<oriansj>and the sources of stage0-posix are now large enough to be classified as a real book

<Hagfish>yeah, if bootstrapping was a country, xkcd 2347 would be its flag :)

<oriansj>well janneke did make a bootstrapping flag

<Hagfish>that sounds half familiar now

<Hagfish>i wonder if there are physical systems that help to prove the provenance of things

<Hagfish>like carving the bootstrap binary seed into a mountain, or something

<oriansj>Hagfish: well physical reality doesn't have a sha256sum yet (and will not until we have matter compilers)

<muurkha>probably not even then

<oriansj>but the pieces of stage0-posix and stage0 are something that a single person could type onto paper tape or honestly any storage media you trust and go from there

<oriansj>The bootstrap seeds are designed to be hand toggled into memory or replaced easily

<oriansj>So although we do trust them, the task of replacing them (and providing matching functionality) is quite trivial

<oriansj>even subsets of the functionality (such as not supporting the line comments) would work if one just didn't type those in.

<oriansj>set exists as a hex0 program and can be implemented in stage0-posix without much effort and then you could have a line editor enabling you to audit the source code you are going to build and to hand type it in if needed.

<oriansj> https://github.com/oriansj/stage0/blob/master/stage1/High_level_prototypes/SET.c

<oriansj>it is around 300 instructions to implement the full functionality: https://github.com/oriansj/stage0/blob/master/stage1/SET.s

<muurkha>set?

<oriansj>Shitty expensive Typewriter

<oriansj>A more shitty remake of the PDP-1's Expensive Typewriter program

<achaninja>I know its against the spirit of everyone - but sometimes it feels like you could have done the bootstrap in private, made a kickstarter for bitcoin

<achaninja>then released it :P

<achaninja>if they are gonna be usnig it anyway without thanking yoyu

<oriansj>achaninja: I'm just glad the death threats from the Bitcoin community finally died off

<achaninja>yeah not just not thanking you - actively harming

<oriansj>no actual harm was done but some of those emails clearly indicated mental stability problems

<oriansj>So I tend to avoid the crypto-community as much as possible

<muurkha>oh, heh

<muurkha>I see the comment now

<achaninja>oriansj: I made a github issue w.r.t. changes I had to make to get mes-m2 to work

<achaninja>I can do a PR but I didn't feel totally confident I'm right

<achaninja>however its what I needed to make it work on my local machine

<achaninja>changes to the readme*

<oriansj>well janneke is the mescc expert (and primary author) and he would know best and mes-m2 might just disappear once gnu mes.c becomes buildable by M2-Planet without any changes

<achaninja>oh that would be awesome

<achaninja>I am a janet programmer (lisp like), but not a schemer lol

<vagrantc>ah, looks like m2-planet is now a dependency to build mes with --bootstrap

<vagrantc>well, been meaning to take a look at that for a while

<vagrantc>er, --with-bootstrap

<oriansj>vagrantc: well --bootstrap-mode is kinda of a special sort of mode

<oriansj>more about checking for cc_* compatibility than anything else

<oriansj>but somehow managed to catch a few programs who jumped to using M2-Planet before more standard behavior was adopted.

<achaninja>oriansj: what parts of the system are you most actively working on atm?

<achaninja>its taken a while to understand the layout of all the projects, but I think I get it now

<achaninja>its not as confusing as I thought

<muurkha>maybe this would be the ideal time for you to write an overview

<oriansj>achaninja: right now I am trying to figure out how to do a kernel that M2-Planet can build; so that we can give live-bootstrap a bootstrapped kernel too

<muurkha>for future people

<achaninja>muurkha: I'm sort of toying with my own version of live-bootstrap with different goals, i guess its gonna be documented

<muurkha>because six months from now you will have forgotten which things seemed non-obvious to you last week

<achaninja>my version trusts the host system slightly more so I can do parallel builds

<achaninja>optionally

<achaninja>so its not a replacement at all

<achaninja>also I personally don't care about automake and autoconf purity

<achaninja>i.e. being able to regenerate from the .ac files

<muurkha>I understand

<muurkha>(I do care!)

<achaninja>i want to get away from autoconf as fast as possible

<achaninja>not to disrespect it, it does the job, but i don't need it

<oriansj>achaninja: just not having it is a quick way to force that

<achaninja>the fact that the bootstrap depends so much on perl also annoys me, its hard to avoid

<achaninja>I guess its part of history :D

<achaninja>nearly all modern software depends on perl

<achaninja>because cmake depends on openssl which depends on perl

<achaninja>its kind of this inverted complexity pyramid

<achaninja>anyway... minor rant lol

<achaninja>wait pyramid isn't quite the right way to visualize it

<achaninja>you want more complex software sitting on top of less complex software

<achaninja>not the other way around ideally

<achaninja>maybe its like an onion

<achaninja>does that make sense to anyone? or am I just over thinking it

<AwesomeAdam54321>It's like a tower of complexity

<achaninja>also let me know if its too off topic - I don't want to be a distraction

<achaninja>AwesomeAdam54321: but a tower is supposed to have a large base haha

<achaninja>well maybe not :P

<achaninja>stage0 is like a tiny base

<achaninja>then gcc is like a fat top

<achaninja>so it would be an inverted pyramid

<achaninja>so I meant like maybe stage0 is the center of an onion and gcc is an outer layer

<achaninja>:P

<achaninja>but imagining it this way might be meaningless anyway haha

*vagrantc will take some more pokes at updating mes on debian tomorrow

*vagrantc waves

<spk121>Hey everybody. So looking at live-bootstrap...

<spk121>If I wanted to ensure that some program was bootstrappable, I'm good if I can build it up from bash, perl5, gcc-4.7.x+musl, or guile-3.0.7

<achaninja>spk121: I guess directly bootstrappable - you could still have intermediate dependencies if you set them up

<spk121>achaninja: understood. That is a foundation upon which I can build, if I don't want to go the Guix route

<littlebobeep>oriansj: who got death threats from whome, and why??? :/

<littlebobeep>oriansj: How does a kernel boot from M2-Planet help exactly, if you need a kernel image to use stage0-posix at all?

<achaninja>littlebobeep: bitcoin was using mes/stage0 for the builds - for whatever reason if the build didn't work they got mad

<achaninja>not the official people, but any random person

<achaninja>at least that is what I heard - theres an article somewhere saying the larger your audience the chance you encounter someone with severe mental illness approaches 1.0

<achaninja>which is why basically all celebrities get many death threats

<achaninja>like more than 20k people at least one person

<achaninja>so its not necessarily a problem directly caused by bitcoin

<achaninja>just by large audience and being misguided

<muurkha>and audience inclined toward paranoia, maybe

<achaninja>it might skew the odds lol

<achaninja>or increase them :P

<muurkha>right, not that every bitcoin user is paranoid, but the rate is higher

<achaninja>sounds reasonable

<littlebobeep>Ehhh paranoid people don't use coins that literally broadcast their finances to the entire internet

<littlebobeep>achaninja: what does it mean the build didn't work, like bitcoind process failed to execute or was somehow unreproduceable?

<achaninja>i don't know the details, i imagine it just took time to setup

<achaninja>so people were waiting for something to be setup to get what they wanted

<achaninja>but really i don't know

<achaninja>i guess the details aren't really important since thy aren't connected to logic

<achaninja>this channel just makes yoghurt after all

<achaninja>:P

<achaninja>its like the guy at the supermarket going crazy because the yoghurt factory had an issue with their culture hehe

<Hagfish>i can imagine people being really upset at the idea of a self-propagating backdoor in compilers

<Hagfish>the options for dealing with that knowledge are: 1) ignoring it (which is the most popular response), 2) getting angry towards the people who mention it (which some small percentage of deranged people will do), or 3) realise it's an interesting problem that can be mitigated with some hard work

<Hagfish>oriansj: yes, reality doesn't have checksums, but i was pondering how to anchor the seeds in a human-readable form that is tamper-evident

<littlebobeep>It doesn't sound like the death threats ppl were mad at the mention of the problem, but rather with the results of trying to fix it? I don't know until oriansj explains what this is about

<achaninja>Hagfish: the seed is already anchored

<Hagfish>oh?

<achaninja>you can read it byte for byte

<achaninja>and cross reference it easily with the intel manual

<Hagfish>from where, though?

<achaninja>right here

<Hagfish>how do i know i'm in the right channel? or that i've been given a legit intel manual?

<achaninja> https://github.com/oriansj/bootstrap-seeds/blob/b09a8b8cbcb6d3fdb025f1bf827d98a8cb3b4d41/POSIX/x86/hex0_x86.hex0

<achaninja>you can logically reason the liklihood some one is able to pack malware into a file of that size undetected

<Hagfish>i know my concerns aren't really practical, but oriansj was saying that paranoia is helpful, so i was trying to give another example :)

<Hagfish>yes, true

<achaninja>its possible - I agree

<achaninja>but would be extremely difficult imo

<Hagfish>yes, and you can sort of trade trust for expertise

<achaninja>you are also right

<achaninja>you can't even trust your implementation of 'cat' which displays the file to you

<Hagfish>i.e. you could verify every line of source yourself for correctness, rather than relying on other people's consensus

<achaninja>so you can't trust your eyes

<Hagfish>right, yes

<achaninja>obligatory meme

<achaninja> https://knowyourmeme.com/memes/trust-nobody-not-even-yourself

<Hagfish>(speaking of which, sadly kym requires javascript to display images)

<achaninja>lame :P

<achaninja> https://i.kym-cdn.com/entries/icons/original/000/017/046/BptVE1JIEAAA3dT.jpg

<Hagfish>but yeah, that's a good meme

<Hagfish>it's almost a mixture of the "spiderman pointing" meme and the "always has been" meme

<achaninja>you also might need to validate the kaem seed

<achaninja> https://github.com/oriansj/bootstrap-seeds/blob/b09a8b8cbcb6d3fdb025f1bf827d98a8cb3b4d41/POSIX/x86/kaem-minimal.hex0

<achaninja>which is the tiny shell interpreter thing

<achaninja>used to build stage0-posix

<Hagfish>hmm, yeah

<achaninja>like this file has manual comments

<achaninja>but you might need to check they are accurate using objdump

<Hagfish>it would be nice to only have to trust a single hash, but then how would you calculate the hash of these seeds if you don't have a trusted computer?

<Hagfish>yeah

<achaninja>just consider this file a 370 byte hash

<Hagfish>heh, nice

<achaninja>you could even memorize it if you really wanted

<Hagfish>hmm, has someone made a sha256 calculating circuit out of simple chips?

<oriansj>achaninja: objdump doesn't work on that file

<oriansj>in fact objdump doesn't work on any binary before blood-elf is used.

<achaninja>i thought objdump could do raw hex

<oriansj>you'd need to use ndisasm

<achaninja>ah ok

<achaninja>(which you need to trust again :P)

<oriansj>achaninja: if you do objdump -d AMD64/artifact/hex0 all you will see is: AMD64/artifact/hex0: file format elf64-x86-64 and nothing else

<oriansj>but that is why we also have xeh and sin

<achaninja>I thought there was objdump -b binary

<achaninja>actually i can just try it

<oriansj>well it certainly isn't a valid flag with: GNU objdump (GNU Binutils) 2.37

<achaninja>check man objdump

<achaninja>its here for me

<achaninja>--target=bdfname

<achaninja>bfd

<achaninja>strange

<achaninja>for me its in the man page, but not in the implementation

<oriansj>oh well

<achaninja>yeah, doesn't matter, i guess it was removed

<Hagfish>ah, here's a nice little project: https://bumbershootsoft.wordpress.com/2019/04/24/implementing-sha-256-on-the-6502/

<oriansj>but yeah, every single byte is commented for *.hex0, *.hex1 and *.hex2 files and the *.M1 files have auditable DEFINEs which can be used to know what every single byte in the binary should be

<achaninja>In the past I used https://en.wikipedia.org/wiki/SREC_(file_format)

<achaninja>srecords for boot images

<achaninja>I think binutils understood that format awhile ago :P

<achaninja>but yeah - not super relevant unless you are into these things

<oriansj>^_^ maybe

<oriansj>but yeah, sha256sum is quite possible in 64KB

<achaninja>when I was writing my C compiler i had a funny thought

<achaninja>if when like

<oriansj>Hagfish: the Monster6502 could probably run that

<achaninja>if (c == '\n') emit(".text "\n");

<achaninja>somthing like that right, then you wonder where the original definition of '\n' came from

<achaninja>since the assembler might get it from the c compiler that compiled it too

<achaninja>this is just a small example of the trust problem stage0 solves

<oriansj>oh, believe me when I say it is going to solve a boatload more

<achaninja>erm i meant emit .ascii "\n"

<achaninja>haha oh yeah

<achaninja>the kernel stuff is really important when you really think abut it

<achaninja>about*

<oriansj>Guix is doing the heavy lifting of maintaining a bootstrap tree above us, which will buy us time to make some serious progress

<oriansj>and kernel work is going to take a while to do right as I'm gonna have to write it in assembly a couple times

<oriansj>so minimal functionality is only going to just enough to run stage0-posix until M2-Planet then it'll bootstrap a more powerful version written in M2-Planet's C subset which should then provide enough functionality until we bootstrap Linux and the rest becomes easy

<Hagfish>oriansj: yeah, i was just checking the status of the MOnSter. once more people have copies of that board in their hands, it might be nice to get one of them to do some bootstrap-relevant hashes :)

<oriansj>well my plan was originally build an H11 Computer and a H10 Paper Tape Reader/Punch and have those create the paper tape of the bootstrap roots and just hand inspect it

*littlebobeep searxes for H11 and H10

<oriansj>littlebobeep: hint Heathkit computer kits

<Hagfish>nice

<Hagfish>i'm reminded of the story of companies dredging up old WW2 shipwrecks to use the iron in them that hadn't been tainted by modern nuclear tests

<Hagfish>hard to imagine a rogue AI created in the 80s that embedded backdoors in all ICs created after that date, but would make a fun story

<oriansj>well we are going to have to do some weird stuff to make even that case impossible. (like making up weird shit architectures and just bootstrapping them and using the bootstrap properties to check all existing architectures)

<littlebobeep> https://github.blog/2022-05-04-software-security-starts-with-the-developer-securing-developer-accounts-with-2fa

<oriansj>So anyone compromising our software better be prepared to handle the very hard problem of having to have backdoors for *ALL* possible future architectures

<littlebobeep>What are good options for 2fa here? TOTP? WebAuthn?

<littlebobeep>or just move to codeberg or some other Gitea instance...?

<oriansj>littlebobeep: depends on your threat model(s)

<spk121>live-bootstrap builds and runs on my laptop, with basically no tweaking on my part. That's really impressive.

<oriansj>for example for some people, https://www.themooltipass.com/ is probably a good enough solution. For other people flashing a https://solokeys.com/ is good enough and for other people building a https://tomu.im/ is what they feel they need to do

<Hagfish>oriansj: yeah, i think that the necessity for an attacker to predict all future architectures is going to be a really strong tool for defenders reasoning about the security of bootstrapping

<oriansj>Hagfish: and the fact that M2-Planet+mescc-tools does perfect reproducibity for cross-platform builds really ties things together in a nice little bow

<oriansj>the fact that every step up until M2-Mesoplanet/mes.c can run on bare metal and get the exact same output as if it ran upon an operating system give us more flexiblity for catching subversion with less effort

<littlebobeep>oriansj: When you say "up until M2-Mesoplanet/mes.c" does this mean modified mes.c that needs to be build before proper GNU Mes?

<littlebobeep>I honestly don't understand how you can get the far without a kernel, or how you suddenly introduce a kernel once you get there

<littlebobeep>oriansj: Did you see my question above about kernel build with M2-Planet you were talking about? I guess this is not related to stage0-posix, but instead a bare metal bootstrap?

<oriansj>littlebobeep: imagine 1 paper tape drive for input and 1 paper tape drive for output and a program loaded into memory just reading the input tape and producing the output tape (no kernel required)

<littlebobeep>Okay I have hard time imagining this XD .... I never used tape drives in my life and have not studied them

<littlebobeep>I am not sure how applicable this is for x86_64 or aarch64 machines I am likely to have with USB ports....

<oriansj>littlebobeep: we can dictate hardware

<oriansj>write to a serial port

<oriansj>read from a serial port

<oriansj>literally 1 byte at a time

<oriansj>no such thing as a file needs to exist

<oriansj>just incoming byte stream until EOF character and then you just halt the CPU when you are done

<oriansj>we will hack and create custom hardware if required

<littlebobeep>When you say serial port do you mean like the old DE-9 D-Sub ports?

<oriansj>We will make our own chips if need be

<oriansj>littlebobeep: honestly it can be any input you feel like makes your work easier

<oriansj>a robot arm manipulating lego bricks for visual audit if that makes you happy

<littlebobeep>Ummmm well i don't have any hardware with D-Sub ports anymore (except maybe VGA)

<oriansj>the point isn't a specific technology for the reading or writing of input/output because anyone can even create arbitrary I/O and use it and still do the same validation work

<oriansj>which means an attacker trying to compromise our reading/writing would also have to compromise *ALL* future invented I/O implementations too

<littlebobeep>Right well I'm more concerned with how to use common I/O on machines I have access to or likely to buy, as I am not quite ready to try designing my own hardware

<littlebobeep>(although it seems great to learn....)

<oriansj>littlebobeep: well I assume you have some level of trust to start with. Be it old hardware without a management engine (ideally with some cheap and simple to program I/O options)

<oriansj>or perhaps a pieced together out of individual chips to the level you feel comfortable

<littlebobeep>Ummm I lost my old x86 hardware by now, so my plan is to just ditch x86 instead of looking for used stuff

<littlebobeep>Some ARM hardware requires proprietary DDR init blobs which is weird

<oriansj>well libresilicon should have some fun stuff in the next couple years

<littlebobeep>I am not sure how much that would b0rk the process

<oriansj>well those sorts of things just make the work harder

<oriansj>and honestly less hard targets will just get bootstrapped sooner

<littlebobeep>Well not all ARM hardware has these DDR init blobs, but I'm guessing most have some kind of firmware burned into the SOC in form of maskrom

<stikonas[m]>littlebobeep: yes, they have something like maskrom but that can be considered hardware some it is on ROM

<fossy>stikonas[m]: hmm, i am getting assert fail: alloc: out of memory in chroot mode with your PR... but i'm not out of memory..

<fossy>can't tell why this is happening at all

<fossy>at tcc

<stikonas[m]>Hmm, that is strange

<stikonas[m]>I'll test again in the evening

<stikonas[m]>But I don't think I saw anything like that yesterday

<stikonas[m]>tcc 0.9.26?

<fossy>yep

<stikonas[m]>That shouldn't even interact with your chsnges

<stikonas[m]>Hmm

<stikonas[m]>And qemu mode?

<fossy>i haven't tried qemu mode

<stikonas[m]>Maybe worth trying in case it's your environment

<fossy>yeah i'lll do that next

<fossy>just trying without my changes rebased jyust in case its that

<stikonas[m]>I did 3 or do runs yesterday and they all worked

<fossy>does seem to have something to do with my changes... works fine without them

<fossy>i pushed my rebased version to the stikonas branch if you can see if you can repro

<stikonas[m]>This one runs out of ram?

<stikonas[m]>I'll try in 6h or so...

*muurkha runs out of ram

<dongcarl>Hi all, I'm late, but want to congratulate janneke and team for GNU Mes 0.24! What a monumental achievement!

<janneke>dongcarl: thanks!

<vagrantc>should older (~0.23) mes build ok with mescc-tools 1.4 ?

<vagrantc>if so, i can just go ahead and upload that to debian at least while i sort out the rest

<vagrantc>i've got some test builds running, but just figured i'd ask if it would be known to break

<vagrantc>known backwards-incompatibilites, etc.

<stikonas[m]>vagrantc: you might have problems

<stikonas[m]>blood-elf now requires more command line arguments

<janneke>maybe it works, as long as you're not compiling with "-g" (debug info)

<janneke>as for the rest, i think mescc-tools 1.4.0 is backwards compatible

<vagrantc>seems to have built successfully

<vagrantc>and tests passed

<janneke>\o/

<stikonas>fossy: yes, I can reproduce it...

<stikonas>although so far I don't know what's causing it

<littlebobeep>.

<stikonas>fossy: I found the workaround, but I think I need to recalculate checksums, your rebase broke checksums

<littlebobeep>stikonas[m]: That is the position the FSF takes, yes, but it does not make much sense to me. Software that is immutable is still software.

<littlebobeep>And I think there is still a freedom issue with it

<stikonas[m]>littlebobeep: then hardware is also software

<stikonas[m]>Most hardware is programmed these days and automatically synthesised

<stikonas[m]>So you either make no distinction which is a bit unrealistic or you just arbitrarily draw line somewhere

<stikonas[m]>And immutable ROM is basically the only somewhat logical place to draw it

<littlebobeep>Well once it's a bunch of transistors it's not really software technically but yes the HDL and netlists are code sure

*vagrantc falls down a git submodule rabbit hole and has no idea where to start

<vagrantc>looks like mes now needs m2-planet to bootstrap, m2-planet needs stage0, stage0 has git submodules ... which have submodules of their own that include ... m2-planet

<vagrantc>i mean, i know recursive self-dependencies are kind of what bootstrapping is all about...

<stikonas>vagrantc: you are getting confused because you shouldn't look at stage0, stage0-posix is what you should be looking at

<stikonas>stage0 is for baremetal bootstrap

<vagrantc>aha!

<stikonas>stage0-posix has M2-Planet, M2libc, mescc-tools and mescc-tools-extra as submodules

<stikonas>some of those have an extra copy of M2libc for standalone building but if you build it as part of stage0-posix, top level M2libc is used

<stikonas>oh and there is also bootstrap seeds submodule

<stikonas>then output of stage0-posix is M2-Planet and those tools

<vagrantc>trying to figure out what makes sense to package this in Debian

<stikonas>you can use M2-Planet to build mes-m2

<stikonas>hmm, maybe stage0-posix should be source package that builds a few binary debs?

<stikonas>like M2-Planet, mescc-tools, mescc-tools-extra

<vagrantc>i already have mescc-tools and mes in debian, trying to update them so i can build mes

<stikonas>M2-Planet can be used to build mes

<stikonas>mescc-tools can be built separately with gcc if you want that

<stikonas>it depends on what toolchain you are going to use

<vagrantc>or, maybe it's a combinatorial confusion because there are multiple different paths that kind of arrive at a similar place?

<vagrantc>yeah, surely i'm building mescc-tools using gcc

<stikonas>yes, there are different paths...

<vagrantc>and i can build mes, but ./configure --with-bootstrap now requires M2-Planet ... where it basically builds mescc with gcc and then builds mescc with mes

<stikonas>there is development path using guile and gcc

<stikonas>and there is bootstrap path using 357 byte hex0 seed

<stikonas>anyway, I'm out for an hour or so

<vagrantc>stikonas: thanks for streering me a bit less lost :)

<vagrantc>but yeah, the hex0 seed seems to be the most exciting path

<janneke>vagrantc: hmm, that sounds like a bug

<vagrantc>janneke: oh!

<vagrantc>janneke: or maybe it has nothing to do with M2-Planet and it's just a bug

<janneke>i mean, if --bootstrap requires m2-planet, and then not uses it..?

*janneke hasn't looked at --bootstrap

<vagrantc>janneke: --with-bootstrap?

<janneke>only at the regular build, and the kaem build

<janneke>ah yes

<stikonas[m]>I haven't used bootstrap either, I used kaem scripts

<vagrantc>janneke: git begs to differ, given that you implemented it, but it has been a while :)

<stikonas[m]>kaem script can build mes-m2

<janneke>vagrantc: ah sure, i meant: i forgot to look at it for 0.24

<vagrantc>janneke: let me get you a better error log

<vagrantc>better than me rambling about red herrings on irc

<vagrantc>janneke: https://paste.debian.net/1240056/

<vagrantc>running another build to get more state, that's just a snippet from the build log

<vagrantc>of course, it's a bug very late in the build process...

<janneke>vagrantc: thanks...hmm, that's a weird bug

<janneke>is this using --with-bootstrap?

<janneke>hmm, i cannot reproduce the dependency on m2-planet; seems optional to me; anyway happy to get a bug report but for now

*janneke -> zZzzz

<oriansj>vagrantc: well mescc-tools has the relationship with mescc that binutils has with GCC. One doesn't *need* mescc-tools to build mescc but it is needed by mescc to actually build working binaries

<oriansj>also M2-Planet is only a dependency for mes.c IF and only IF one is doing a bootstrap.

<oriansj>If I remember correctly a single gcc command should be all one needs to build mes.c (unless that magically broke somehow *again*)

<oriansj>nyacc would also be a runtime dependency (hopefully it is packaged too)

<vagrantc>janneke: yes, using --with-bootstrap

<vagrantc>janneke: yeah, the m2-planet thing may have just been me misreading the documentation and making assumptions

<vagrantc>any dependency needed to build mes 0.23 is packaged, anything newly introduced i'll have to package (already updated mescc-tools to 1.4 since it seemed to build mes 0.23+patches fine)

<oriansj>vagrantc: well mescc-tools isn't needed to build mescc

<oriansj>and there was only a single breaking change for mescc with mescc-tools involving blood-elf needing an endian flag

IRC channel logs

2022-05-05.log