IRC channel logs

<gforce_de1977>stikonas: PR: "Build harness in bash" - looks good to me, i would change shebang to /bin/sh and fn_exists() is simpler with just: test "$(type -t "$1")" --> this works on posix too

<fossy>gforce_de1977: /bin/sh is de-facto standard for posix compatibility

<fossy>that script is far from posix compatible

<fossy>we also don't have any shell other than bash

<fossy>also, i got the linux 2.4.26 kernel built by tcc linked, but uhhh

<fossy> https://i.imgur.com/0rz9pTu.png

<bauen1>fossy: all good osdev debugging begins with art like this

<bauen1>fossy: actually, are you using tcc to do the actual linking too ? because that is a lot less likely to work if linux has _any_ special requirements or makes any assumptions

<gforce_de1977>fossy: "that script is far from posix compatible"? i dont think so: there is just 1 little complain when doing: shellcheck --shell=dash helpers.sh

<gforce_de1977>fossy: there is just no need to enforce bash, when the script is posix anyway, and if we really stick to bash is not totally clear

<gforce_de1977>fossy: are you using .config and .patch from https://bellard.org/tcc/tccboot-0.1.tar.gz ?

<gforce_de1977>fossy: there seems to be some code to support tcc 2.4.37 | https://github.com/seyko2/tccboot

<fossy>bauen1: yes, tcc is doing the linking

<fossy>gforce_de1977: hm, i will look at this updated version, but yes i was using that

<fossy>gforce_de1977: i'll leave the bash decision up to bauen1, you are right it's not too posix incompatbile

<fossy>gforce_de1977: but also, we don't have /bin/sh (we didn't make it)

<gforce_de1977>fossy: it as easy as: cp /bin/bash /bin/sh

<gforce_de1977>bauen1: do you have some feeling about that? (bash vs. posix scripts)

<fossy>gforce_de1977: yeah, it is, correct

<fossy>it only seems to be a couple of lines that need fixing to make it fully posix compilinat

<fossy>but i guess i'm thinking more in matte rof principles, if a useful feature came up would we use it or not

<gforce_de1977>fossy: there is just 1 line to fix, and the fix is to make the line shorter: test "$(type -t "$1")"

<fossy>that's not really a fix

<fossy>that changes the behvaiour

<fossy>it needs to be a function and not anything else

<bauen1>uh, not really, my general stance would be that if you can do it with "/bin/sh" with none or only minor changes, that's probably a good diea

<bauen1>*idea

<bauen1>at least some project still spend extra attention to avoid breaking POSIX, so there's that

<gforce_de1977>bauen1: i'am on your side. especially in this early stage, it's a good idea. It's the same like 'set -x', better set it now, that later...

<gforce_de1977>fossy: if you insist, the posixly fix would be: test "$(command -V "$1")" = "$1 is a shell function"

<gforce_de1977>fossy: or with 'type': test "$(type "$1")" = "$1 is a shell function"

<gforce_de1977>or: case "$(command -V "$1")" in "$1 is a shell function") true ;; *) false ;; esac

<gforce_de1977>8-)

<gforce_de1977>fossy: another approach would be: always establish an empty function package_xy() { true; }

<gforce_de1977>and call it (the package can overwrite the function) so there is just no need to check for the function, it is just always available

<fossy>gforce_de1977: hm that's not actually a bad idea...

<stikonas[m]>But what's wrong with bash?

<fossy>nothing imo

<fossy>stikonas[m]: what if we just defined the functions

<stikonas[m]>That's the only thing we have anyway

<fossy>and then sourced the script

<fossy>which would override it..

<stikonas[m]>Oh, I didn't want that

<stikonas[m]>Deliberately

<fossy>sure, but i can't place why

<fossy>just clarity?

<stikonas[m]>I might call default implementation from overridden

<fossy>ooh, yeah

<fossy>ok

<stikonas[m]>I might need it even in flex

<stikonas[m]>E.g. I can apply patches, then touch config.h

<fossy>yeah, good design decision

<fossy>uh, this dosen't look good, lol

<fossy>objdump: vmlinux: file format not recognized

<stikonas[m]>Where did we get objdump from...

<fossy>stikonas[m]: no this is my debugging of the broken kernel

<stikonas[m]>Isn't it from binutils

<fossy>this is what it outputs on boot

<stikonas[m]>OK...

<fossy> https://i.imgur.com/0rz9pTu.png

<gforce_de1977>stikonas: whats wrong with bash? a lot 8-) but seriously:

<gforce_de1977># "Stick to portable constructs where possible, and

<gforce_de1977># you will make somebody's life easier in the future.

<gforce_de1977># Maybe your own."

<gforce_de1977>i do not like the idea to make BASH unavoidable

<stikonas[m]>Bash is unavoidable, there is no other shell here. I understand the benefits of POSIX compatibility when you distribute scripts to run in their shells. But here we literally just compiled bash and bash only

<gforce_de1977>stikonas[m]: for now, there is only bash, my feeling says that we want something simpler in the future. It's ok for now, but there is no point using bashisms, where not needed. for now your new infrastructure is already posix, so we can stick for it. what do you think about that?

<fossy>UGH

<fossy>i HATE kernels

<fossy>so the image i have built can be loaded in one way and in one way only specific to tccboot

<fossy>so, uh, yeah, i need to think more about how i'm going to make this work

<fossy>gforce_de1977: yeah, something simpler *might* be better later

<fossy>but remember we are basically time-travelling

<fossy>the whole "/bin/sh != /bin/bash" thing only occured in 2007~ when ubuntu made the switch

<fossy>up until then, there are bashisms /everywhere/ (including autotools, ironically, in some code paths)

<stikonas[m]>And dash is probably harder to build

<fossy>s/probably//

<stikonas[m]>Ironically too

<fossy>is right now, probably not so much later, but is now

<fossy>yeah

<fossy>i think i might take a break from kernels tomorrow and do reuse instead

<stikonas[m]>I looked at some other shells too, none were easy

<fossy>kernel is annoying me to all hell, lol

<stikonas[m]>Yeah, take a break

<fossy>i need to figure out how once transforms a vmlinux into a bzImage... without a shell :D

<OriansJ>siraben: well best of luck with your studies. ^_^

<OriansJ>fossy: have you looked at non-interactive shells too?

<siraben>OriansJ: thanks, also for helping to port blynn-compiler to M2-Planet

<OriansJ>siraben: hopefully I can get some of the ugly M2-Planet specific bits into more C standards. But this is a long fight but It'll all be solved together.

<siraben>Indeed. Also, the blob issue is still there but anyone familiar with lambda calculus could step in and rewrite it in Scheme.

<fossy>OriansJ: yeah, our bash is currently non interactive due to a lack of /dev.

<fossy>we tried dash (requires better than mes libc) and i looked at busybox ash (ditto). gash isnt feasiable due to lack of guile

<OriansJ>siraben: just minor more item on a very long list but we will get there ^_^

<stikonas[m]>Also lack of readline

<OriansJ>fossy: what about the toybox shell?

<stikonas>OriansJ: we now have bash anyway

<stikonas>well, unless fossy needs some simpler shell for kernel

<OriansJ>stikonas: I think fossy probably wants to reduce the bits that need to be supported to bootstrap linux; reducing the requirements on a bootstrap kernel.

<stikonas>OriansJ: yeah, I think so...

<stikonas>bash already requires a lot of syscalls

<stikonas>so ideally we have some linux and not minimal bootstrap kernel by the time we use bash

<OriansJ>gash would reduce that but we still need to get something easier to bootstrap than guile to use it.

<stikonas>yes, if it can run on mes that would be good

<stikonas>but mes-m2 is still some time away

<stikonas>anyway, there is more work to be done until we bootstrap gcc

<stikonas>it's not like everything is blocked on gash

<stikonas>fossy: I've just pushed and update to PR, it passed locally

<OriansJ>stikonas: the question becomes would the effort be more effectively spent if we assumed magic and then made it happen.

<stikonas>later in bootstrap chain it probably doesn't matter

<OriansJ>eg assumed a bootstrap scheme capable of running gash and gash-utils

<stikonas>it's only the question for kernel

<stikonas>well, maybe much later when we need some other arches

<stikonas>but I think most of the problems wouldn't be coming from utils

<stikonas>probably the problems will be in toolchain... tcc/binutils/libc

<stikonas>e.g. if we need risc v there or something like that

<OriansJ>stikonas: hence the simplification of the bootstrap path even if it means a few custom pieces along the way.

<OriansJ>The less pieces we have to work with, the less that can break or become issues later.

<stikonas>true, but I expect most issues in compilers/binutils and various libc...

<OriansJ>stikonas: porting compilers and libraries to new architectures is just work, not magic and we are experienced at this point in how to do it.

<stikonas>I guess at some point we need to port live-bootstrap to arm64, it will make it more apparent where the problems are

<OriansJ>stikonas: and powerpc, mips, etc.

<OriansJ>The more architectures the better.

<stikonas>yeah, of course, although I don't have suitable powerpc or mips hardware...

<stikonas>well, I have low RAM mips

***janneke_ is now known as janneke

<stikonas>but router is not good enough for bootstrapping

<OriansJ>stikonas: you aren't expected to do the bootstrapping work for platforms you don't have.

<OriansJ>we just need to make it easier for the people who do to help us gain those roots as well.

<OriansJ>It is about making the job for the next person easier.

<OriansJ>Like Snowball debt payments. We kill off the highest interest technical debt first and work our way down until we are all free of the bootstrapping technical debt we were all born with.

<OriansJ>M2-Planet + mescc-tools might not be great programming languages but they are a fuckload more portable and easier to work with than the alternatives.

<deesix>I guess one issue for some archs is that the compilers don't have support, because the arch is newer than the version of the compiler. So I guess one option is to bootstrap on x86 until the support is there, but does not feel elegant :/

<OriansJ>deesix: well the M3 plan would solve that but would require help

<OriansJ>as the bootstrap path would become M2-Planet+mescc-tools->M3->GCC->everything else

<OriansJ>then porting to a new architecture just requires the generation of a new mescc-tools-seed and updating of 3 major pieces

<deesix>Another plan is to backport support to older GCC, I guess.

<OriansJ>deesix: there are no easily solutions here; as bootstrapping a new architecture will always require significant effort.

<deesix>Of course I'm not saying it's easy.

<deesix>... or even possible.

<OriansJ>It'll get easy once bootstrappable builds becomes part of everyone's build chains but that will require a lot more politics than I have the stomach for.

<stikonas>everything is possible, it's just the amount of work needed

<OriansJ>getting it into Guix's took us 4 years of hardwork.

<deesix>Well, yes... you know what I mean, to the point that gcc whatever can be still called gcc with all that backport/rewrite.

<OriansJ>and that is with guix developers actually helping us.

<OriansJ>getting bootstrappable into Debian will probably be much harder

<OriansJ>after that it'll be all down hill

<OriansJ>deesix: we have done the impossible enough times to know when most people say bootstrapping is impossible, it just means they are not willing to do the required work.

<OriansJ>So we pick up the shit they left on the floor and solve the problems one by one until we did the impossible again.

<siraben>OriansJ: I'm curious, how did we collectively lose the bootstraps as a society?

<OriansJ>siraben: people threw away things they were ashamed of or thought had no purpose.

<gforce_de1977>siraben: on the other hand it seems wise, to rely on already done stuff and concentrate on new ideas.

<OriansJ>why keep the code for a hex build system when you had a better optimizing assembler?

<deesix>wrt. the conversation of a few days ago about old/ancient versions of toolchains, I guess the context is this amazing bug hunting https://lwn.net/Articles/842122/

<siraben>In a way we're recreating all of that "negative space" left behind, code that was deleted or never committed, heh

<gforce_de1977>OriansJ: book, paper and program code will always be there an will not "rotten"

<OriansJ>these people were not stupid or evil. They just did not place value in the things that they no longer needed.

<siraben>Of course

<OriansJ>deesix: indeed the world is moving on; letting go of the problems of the past but losing the history needed to restart correctly.

<OriansJ>much like the nano material manufactoring technique of the Lycurgus Cup; humanity has a bad time remembering how to do things and likes to forget leading steps.

<stikonas>deesix: also free software was not bootstrapped with free software in the first place

<siraben>Reminds me of the Collapse OS project which is aimed at providing some cushion come the apocalypse

<OriansJ>stikonas: a technical debt, knowingly taken by Stallman as a sacrifice to get the FSF off the ground.

<stikonas>well, there was no other way to quickly get off

<OriansJ>siraben: there are repeating patterns in human nature. Fear of losing everything in the future is just one pattern that keeps playing out over and over again. Rarely working together in large groups.

<OriansJ>stikonas: and he couldn't have afforded the 4 year delay that we paid to get as far as we have.

<OriansJ>debt is sometimes a good thing to take; it sometimes even being cheaper than trying to save up to buy.

<stikonas>yeah, that's often the case

<stikonas>not many people rent until they can save 100% for house

<stikonas>that would be more expensive

<OriansJ>For example some religions forbid house mortgages; so the followers spend their lives saving up cash to buy the house in cash.

<OriansJ>And I know someone who is actually doing that right now

<OriansJ>Even though I showed him that it would save him $78K to just take a loan, he still refused to even consider the option.

<OriansJ>And that isn't even considering the rate of rising house prices in the area he wanted to live in.

<stikonas>yeah, that is unfortunate...

<OriansJ>let alone rent increases which will certainly happen before then

<OriansJ>it is why I am ok with taking on tiny, low interest technical debts to clear off far more expensive high interest debts in our bootstrap.

<OriansJ>the blobs in blynn-compiler are small and low interst debt to solve but having a Haskell Compiler gives us a path to elimination of the high interest bootstrap debt of GHC and everything that depends upon it

<OriansJ>punting on Guile, having the pieces restrict themselves to a subset of r7rs scheme save a bunch of time because it might take 4 years to solve the scheme bootstrap problem but it is a static target

<OriansJ>and it keeps an straight path to everything thanks to the work Gnu Guix is maintaining for us

<OriansJ>Our efforts are better spent just assuming guile on a POSIX, getting that clean enough for all Linux distros to be able to bootstrap Guix; then solving GHC

<OriansJ>I know everyone just wants to be done

<OriansJ>but every programming language on the planet is running away from us.

<OriansJ>we need to catch them while we still can.

<OriansJ>because reconstructing those steps is a far harder problem than just recording them in guix

<siraben>How come?

<OriansJ>siraben: inside the bootstrap of every new language is shame and mistakes; the very things people want to get past quickly.

<OriansJ>So old versions get deleted

<OriansJ>git histories get rewritten

<siraben>will we be able to bootstrap golang with GCC?

<OriansJ>polished over by people who can't and will not allow their mistakes to haunt them.

<OriansJ>siraben: we already bootstrapped golang "sorta"; the problem is the generated bits need to be redone properly but we caught it early enough that it is a problem we can reasonably address when we get a developer to work on it

<siraben>What's important to those devs (their past mistakes) is likely not a matter of concern for others

<siraben>and of course makes our goal of bootstrapping a lot harder

<OriansJ>siraben: They don't care about our job because it isn't their job too.

<OriansJ>it is why Gnu Guix and the Software Heritage project have to download sources and host them *FOREVER*

<siraben>is it also on IPFS or distributed torrents?

<OriansJ>people no one else is likely to keep a copy of that super essential minor release that enabled xyz required feature.

<OriansJ>siraben: I think there was discussion about adding support for IPFS into Guix but I don't think anyone actually got it working yet.

<OriansJ>but it wouldn't be too hard to just run IPFS on your /gnu/store

<stikonas>siraben: golang is quit easy to bootstrap

<OriansJ>I think I even have a version of IPFS written in C somewhere too

<stikonas>especially on older arches where you can build golang 1.4 with C and then jump to latest golang

<stikonas>other arches can be bootstrapped via gccgo

<gforce_de1977>fossy: i just checked, and Autoconf seems to emit shell-scripts for posix-shells (no bashisms), just for the record

<OriansJ> https://github.com/Agorise/c-ipfs.git (you'll want to do git clone --recursive)

<stikonas>gforce_de1977: which autoconf? we'll likely use old autoconf

<stikonas>but in any case, I think rootfs.sh is better candidate from cleaning bashisms than things in actual bootstrap

<stikonas>we don't have many anyway

<siraben>OriansJ: nice

<siraben>C, for all its quirks, pitfalls and poor design choices, when simplified, is a great bootstrapping language

<siraben>I was surprised from the start to see that Forth programmers haven't put in the work to show how Forth can be used as a bootstrapping language

<OriansJ>siraben: they did for a little bit and just gave up

<siraben>How come?

<OriansJ>siraben: they didn't say. They just stopped contributing when they hit the part of FORTH where you have to encode assembly instructions to get stuff done

<OriansJ>: JUMP-TO, 0x3C000008 , , 0x2E60FFFC , 0x0D010000 , ; just isn't that portable now is it?

<OriansJ> https://github.com/oriansj/stage0/blob/master/stage3/inital_library.fs

<OriansJ>Thus the really short version is FORTH isn't actually portable

<OriansJ>and it requires far more primitives than even C does

<OriansJ>Interpreters are always a harder program than Compilers to get right and far less forgiving too.

<siraben>Right

<OriansJ>xentrac did an amazing job with stone-knife FORTH but eventually opcodes still has to show up eventually.

<OriansJ>as mes.c and mes-m2 and countless other scheme interpreters have shown; there are no magic languages that make bootstrapping easy.

<OriansJ>Only bits that are easier to bootstrap than others or able to attract enough developers where it stops being a problem.

<OriansJ>cc_* was easier than FORTH or Scheme but gash+gash-utils attracted more developers

<stikonas>what about https://raw.githubusercontent.com/peterferrie/brainfuck/master/brainfuck_nc.asm :D only 100 bytes

<stikonas>argh, I might want to scale down on subshells in bootstrap...

<stikonas>bash-2.05b doesn't seem to support -E, so I can't error out nicely

<stikonas>from a few subshells in

<stikonas>ok, I think a bit ugly but working solution is to kill shell with kill $$

<OriansJ>stikonas: if you wish to bootstrap a C compiler from brainfuck; no one here will stop you. As whoever does decides. But int 0x21 indicates DOS and I don 't see a read anywhere; so it is likely a DEBUG.com load with file contents put into memory (thus larger than 100bytes)

<stikonas>no, I'm not bootstrapping C from BF. I don't think it would be readable even if somebody does it

<stikonas>bootstrap should be readable

<theruran>so GNAT Ada has a bootstrap problem? Does it mean a mes/Guile compiler should be written?

<theruran>Ada compiler written in Guile/mes*

<OriansJ>theruran: does GCC not support Ada enough to support it?

<theruran>I guess it needs Ada to build! so GNAT is not available in Guix or Nix :/

<OriansJ>I guess that info needs to be added to: https://bootstrapping.miraheze.org/wiki/Boostrapping_Specific_Languages as a TODO

<theruran>got it

<OriansJ>as we find unbootstrappable from C languages, all we can really do is document that they can't be bootstrapped and what is currently known that might help someone sort out that problem and then document the solution.

<OriansJ>enable the Guix community to build out proper bootstrap chains that they will maintain, while we go after the next bootstrapping problem for them.

<theruran>I am looking at the Gentoo ebuild for clues

<OriansJ>blobs and pre-generated "code" is usually what we find.

<theruran>if use bootstrap; then GCC=...gnat-gpl-2014-x86_64-linux-bin...

<OriansJ>But we are like force Recon here; we lack the fire power to take on a hardened target but we can punch holes in bootstrapping problems to the point that a more conventional force can finish them off for us.

<theruran>OriansJ: how goes the Haskell bootstrap?

<bauen1>actually having an overview of every non-bootstrappable (or cyclic dependency) is already very valuable on its own

<OriansJ>theruran: Haskell doesn't bootstrap yet, it still depends on a GHC binary seed in guix

<malina>OriansJ, unfortunately one can't bootstrap Ada in its entirety, it's closed source

<malina>so it's not something one would want, in a gnu centric (guix) kinda env anyway. (Unfortunately). it SEEMS that Dlang however

<OriansJ>malina: not an acceptable answer.

<theruran>OriansJ: I was referring to your Blynn compiler

<malina>which also needed the closed backend, somehow now works withougt.

<malina>sorry, why not acceptable?

<malina>I am just stating what Ada is. . it's not an open source seed

<OriansJ>malina: if GCC-Ada isn't source what is?

<malina>it NEEDS ada to boostrap itself

<malina>actually.. gcc ada has _never_ had a full source bootstrap

<OriansJ>malina: and GCC needs a C compiler to bootstrap itself

<malina>it's a frontend which used Ada to build itself. again, as I say.. unfortunately.

<malina>yes, but my point is, you NEED access to Ada's source code then, you won't get it

<malina>it's not open source....

<malina>this is just me telling you.. I am not with Ada or anything you know

<OriansJ>malina: the problem is how to build it from the sources we have

<OriansJ>not the sources we don't and will not have

<malina>the way gcc builds it is

<malina>grab a seed from Ada core company thing

<malina>then use that to build the gcc-ada front end

<malina>dlang used to be closed binary too, the backend, but I managed to build it in the cross I did recently and I am think it has changed and become fully open.. although I am not 100% sure, if it took something from my host.

<OriansJ>malina: Document exactly the problems with Ada in the wiki so that we can address them until the bootstrap problem is solved.

<malina>OriansJ, yes, I was simply trying to help ... w.r.t. Ada once you have gcc you will have the gcc-ada.

<theruran>There are some experimental Ada compilers written in Ada..

<malina>you guys seeminly show me a cold shoulder, and I have no idea how to use a wiki, I simply tried to giveyou a beneficial advice but

<malina>theruran, ye, I wuldn't know.. I was simply being informative sigh.

<theruran>I'm wondering how big the closed-source seed is, and what it does

<OriansJ>We are not giving up on bootstrapping any language;

<theruran>I am adding a simple note to that wiki page

<OriansJ>malina: a wiki in this case is just a text file you add Ascii text to

<malina>good question. I wanted ot write my PM (package manager) in Ada once, but ye, it's not open. Ravenports, which is a very good,ubiquitous posix package manager is written in Ada, but

<OriansJ>malina: specific facts that are verifiable and directly related to the bootstrap of GCC-Ada please

<malina>I am fairly certain you know more than I do about gcc bootstrapping. Again, it did seem like maybe you missed that Ada is a closed source language, which gcc has, and maintains, a front end to. That's all, That's all I have to say.

<theruran> https://www.gnu.org/software/gnat/ just refers to the GCC pages

<OriansJ>Ok, so we have a potential bootstrap problem with Ada that needs to be confirmed and the exact issue needs to be documented in a fashion that others can verify and could potentially start working on.

<OriansJ>FUD doesn't help solve the problem but clear and easily verifiable facts that we can address in a structured fashion.

<malina> http://www.linuxfromscratch.org/blfs/view/8.3/general/gcc-ada.html <- the 2nd paragraph exemplifies the isssue. When bootstrapping my distro, I certinaly could not do ada from pure sources, so it's a "bad boy" as far as I am concerned. But maybe things change or you can access the full sources of the process. I wasn't aware of this then.

<malina>fine, if you call it FUD, fine. not gonna say a single hting here more then

<malina>what a twat

<OriansJ>ok, so yes GCC-Ada needs an Ada compiler; let us see what we can find that might help address that issue.

<OriansJ>malina: thank you for that specific bit of information. However please refrain from personal attacks; it doesn't generally promote cooperation.

<theruran>alright, I added a few notes here: https://bootstrapping.miraheze.org/wiki/Bootstrapping_Specific_Languages#Ada_and_SPARK

<pabs3>(malina left the channel after their last comment)

<rain1>that is good information thanks for adding it theruran

<theruran>👍 and there's a few Ada compilers on GitHub written in Java, Python, C, ...

<rain1>nice!

<theruran>yeah, quite a few, in various states, typically from university compiler courses

<stikonas>anyway, circular dependency doesn't mean something is closed source

<rain1>yeah it just means it is not yet bootstrappable

<theruran>this translator/interpreter looks the most complete I've found so far, written in C, from New York University, GPLv2: https://github.com/daveshields/AdaEd

<theruran>and there's a compiler for the Pascal subset of Ada with Ada tasking from the source linked in that AdaEd commit message: https://web.archive.org/web/20181018033600/http://www2.informatik.uni-stuttgart.de/iste/ps/ada-software/html/dos_ada.html

<OriansJ>now that is really useful info theruran thank you.

<OriansJ>This seems much more solvable of a problem. Probably need someone to spend a week or two to find the key points that might be missing; get the working bits into Guix and then update the wiki with any remaining work needed for bootstrapping.

<OriansJ>hmm guix has gnu/packages/ada.scm

<OriansJ>and ada-ed is already bootstrapped in there by the looks of it

<OriansJ>which looks like it was the first Ada in the chain of Gnat: https://en.wikipedia.org/wiki/Gnu_ada

<OriansJ>So it might just be a matter of finding the newest version of Ada that can be built with it and repeating until the chain is complete.

<OriansJ>So perhaps only a couple days work

<OriansJ>So one can probably skip doing a Mes/Ada probably and do a Guix/Ada bootstrap tree and then we can put that potential bootstrap problem to rest forever.

<Hagfish>"The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."

<Hagfish>at what point can we say that the GPL requires bootstrappability?

<Hagfish>if not because a bootstrap path is "the preferred form of the work", then because it is the source code "used to control compilation"?

<OriansJ>Hagfish: well that would cause a great deal of trouble real fast for every Distro that isn't Guix

<Hagfish>and you're saying that's a bad thing? ;)

<OriansJ>No but a hard political move

<Hagfish>indeed

<OriansJ>Now FSF and GNU should make it strictly required per policy

<OriansJ>as we need a hard line there

<Hagfish>yeah

<OriansJ>but I have gotten no response of any kind from gnueval@ in regards to getting Gnu bootstrap seeds into Gnu as an official project.

<OriansJ>So the question becomes how will they take the expectation internally.

<Hagfish>if Gnu accepted it, they might start to be more militant about interpreting the license that way

<Hagfish>"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

<Hagfish>if a compiler depends on a binary of itself, then does the "special exception" apply or not?

<Hagfish>bit of a philosophical question

<OriansJ>Hagfish: well not entirely if cross-platform builds are put into consideration.

<Hagfish>ah, good point

<OriansJ>As we will never have the source for Windows but we should have software that can run on Windows.

<OriansJ>So as long as we can build from Gnu sources everything; it should be perfectly acceptable.

<OriansJ>If we have the source and can build it in guix, it should be clear and valid.

<OriansJ>But if guix can't build it even with the cross-platform build behavior, it might be a valid issue.

<OriansJ>So depending on non-free libraries might actually be something to crack down upon.

<OriansJ>So you can say that GPLv3+ program can't depend on that binary blob library but it can be built to run on that binary blob system as a matter of freedom.

<Hagfish>i think the idea of running Free software on non-Free platforms was a compromise that the FSF accepted from the start

<OriansJ>and one maintained to help those people escape, nothing more

<OriansJ>But the age of depending on binary blobs in our build process is over.

<Hagfish>it's like a second renaissance for Free software

<OriansJ>well we need Gnu to take the newly created bootstrap powers to heart.

<OriansJ>Get bootstrapping a core value in Gnu and then start chipping away at all that remain.

<Hagfish>yup, that will be a good sustainability milestone

<OriansJ>Everytime a new language shows up, we get its bootstrap into Guix or hammer it until we can get it properly bootstrapped.

<OriansJ>No more compromise for software; source only builds

<OriansJ>Guix will need to make the generation of their bootstrap binaries more trivial for third parties but we are miles ahead of where we were 4 years ago.

<Hagfish>for a long time, i thought that the goal of bootstrappability would be mostly achieved by Rob Landley, who is extremely talented and has some views i respect, but also has an odd opposition to the GPL

<OriansJ>Hagfish: all great progress comes at the cost of countless people who's contributions to the cause get lost in the sands of time.

<Hagfish>standing on the shoulders of invisible giants?

<OriansJ>What matters is that the struggle for Freedom remains active and pushing towards new heights.

<OriansJ>Hagfish: indeed.

<OriansJ>We are not going to stop with just software

<OriansJ>We are going to go into hardware

<OriansJ>and carve a path so wide the world can't ignore

<OriansJ>We have known freedom, long enough to never wish to give it up.

<OriansJ>No compromise. No Surrender.

<Hagfish>something like that

<OriansJ>It might take us another 35 years but what started on 4 October 1985; will become so much more than ever imaged possible to even RMS back then.

<Hagfish>certainly there is a synergy(?), where society can't be free if our tools aren't free, and our tools can't be free if our society isn't

<Hagfish>"The Right to Read" was published in 1997

<stikonas>fossy: so I've now updated my PRs I think both are ready to be merged...

<stikonas>there were some issues with yesterday's version but now it's fixed

<fossy>stikonas: thanks I'll look

<stikonas>fossy: so 2.1.14 is the newest flex I was able to build...

<stikonas>2.5.14...

<stikonas>2.5.15 starts using more libc functions

<fossy>ok, is that sufficient for bison

<stikonas>I think bison also uses more libc functions

<stikonas>we'll have to do somethngn about libc

<fossy>grr

<stikonas>yeah...

<fossy>even old version?

<stikonas>well, regarding gawk, I think I can try something else

<stikonas>old versions of bison are not bootstrappable

<stikonas>you need that particular version

<stikonas>it has custom parser written by gio in C

<stikonas>instead of gawk, I can try https://github.com/eunuchs/heirloom-project/tree/master/heirloom/heirloom/nawk

<fossy>oh right, forgot about that

<stikonas>ok, yacc segfaults on nawk... so this way is not good

<stikonas>fossy: hmm, I'm a bit out of ideas what can be done next...

<stikonas>hmm, I think we need to build uname from coreutils too for configure scripts

<stikonas>argh, that is ugly...

<stikonas>it depends on sys/utsname.h

<stikonas>hmm, maybe we can use one from linux-headers

<deesix>M2-Planet has some support for utsname (now also in M2libc), for get_machine. For that seems simple enough (of course, I don't know how much uname needs).

<stikonas>well, so far I was unable to run a single configure script, all of them for different reasons...

<stikonas>one wasnted uname, the other date, etc...

<pder>what is guix doing in its bootstrap for bison that is different from live-bootstrap?

<stikonas>pder: pregenerated C files?

<stikonas>pder: although, it's not just bison that we are stuck with...

<stikonas>I'm unable to think of anything right now

<stikonas>most of the stuff that I tried to play with needs much more libc support than mes libc provides

<stikonas>maybe we can try to build binutils with custom make, but binutils without ./configure is ugly :(

<stikonas>pder: so far the only minor thing that I managed to do after flex is sleep from coreutils

<stikonas>somehow we missed it

<stikonas>so maybe we have to try to fix musl...

<stikonas>which is argh :(

IRC channel logs

2021-01-30.log