IRC channel logs

<fossy>stikonas: reuse pr is up

<stikonas>fossy: ok, done

<stikonas>mostly minor comments, but I suggest more permissive license for .gitgnore and .gitmodules

<stikonas>maybe MIT or CC0?

<stikonas>especially .gitmodules is autogenerated by git command

<stikonas>so arguably there is nothing copyrightable there

<OriansJ>stikonas: well .gitmodules is just a list of paths and urls and facts like phone numbers is non-copyrightable (in the USA)

<stikonas>well, same for .gitignore

<stikonas>that's why I thought putting GPLv3 there is overkilll

<OriansJ>well .gitignore can certainly be hand written (all of them in my projects are)

<OriansJ>and when in doubt, overkill is the option to use in this sort of a project

<stikonas>well, okay...

<OriansJ>Everything has to be beyond question and above board.

<OriansJ>a delay to get proper licensing now will save us when in 4 years someone thinks to get a quick buck and shutdowns everything to do it.

<OriansJ>prepare for the worst of human nature and you'll be safe when it shows up; because it will.

<stikonas>well, both would be proper licensing... I was just thinking which license to use

<stikonas>but with reuse 3.0 every file in the repo has a license and copyright statement

<stikonas>anyway, reuse is a very nice tool by FSFE... It might be worth adopting it in other bootstrapping repositories

<fossy>stikonas: i think i'll just go with MIT for .git*

<fossy>10:58 <OriansJ> a delay to get proper licensing now will save us when in 4 years someone thinks to get a quick buck and shutdowns everything to do it.

<fossy>how do you mean OriansJ

<OriansJ>fossy: when it comes to copyright licensing and the stiff financial penalties for violation, it is best to assume bad faith and get terms up front that are favorable for the worst case in the future. Aka know for certain that it is under a free license or skip entirely to eliminate the risk.

<fossy>OriansJ: ah, i see what you mean now

***mephista is now known as spicy_icecream

<OriansJ>best to learn from the past https://en.wikipedia.org/wiki/USL_v._BSDi than to repeat the same foolish mistakes.

<OriansJ> https://en.wikipedia.org/wiki/SCO-Linux_controversies

<OriansJ>we can't afford the years of delay that such things can cause.

<OriansJ>We barely are holding on to the rope bridge of bootstrapping Guix, let alone trying to get bootstrap paths on all the nw things coming out everyday and creating paths to the pieces we don't have yet done (GHC, GCC-Ada, etc) even if they are only weeks of work

<OriansJ>We have new CPU architectures that we will need to port to and lifetimes of work to do.

<gio>fossy, stikonas[m], OriansJ: most stuff in nbs is not mine, so it goes under their own license. My stuff is BSD-2, as written in the readme.

<siraben>BSD isn't copyleft, is it?

<fossy>yes it is

<fossy>well

<fossy>basically as copyleft as MIT

<fossy>it's a more permissive license

<siraben>will that be a problem for us?

<fossy>not at all

<siraben>ok

<gforce_d11977>fossy: stikonas: I updated https://github.com/fosslinux/live-bootstrap/pull/30

<janneke>OriansJ: ah, i see; in any case, let's be pragmatic while trying hard to think forward too ;)

<gforce_d11977>fossy: stikonas: DIFF here: https://github.com/fosslinux/live-bootstrap/compare/master...bittorf:wget_cache

<janneke>today's my talk in #fosdem-declarative.minimalistic: https://fosdem.org/2021/schedule/event/gnumes

<deesix>fossy, I think you're confusing Copyleft with something else.

<siraben>janneke: yay, I enjoyed that talk

<janneke>siraben: thanks -- sorry about the technical hiccup!

<siraben>this was the whole talk right? https://fosdem.org/2021/schedule/event/gnumes/attachments/video/4690/export/events/attachments/gnumes/video/4690/gnu_mes_fosdem21.mp4

<siraben>hopefully blynn-compiler can also play a role in this graph at some point too :D

<janneke>siraben: yes, that's it

<OriansJ>siraben: well we still have to bootstrap GHC somehow getting Mes a better scheme certainly are import goals

<stikonas>pder: I found what was causing problems in regex.c in m4-1.4.16...

<stikonas>let's see if I can build the whole program now

<stikonas>hmm, I might go for a bit earlier version of m4 if i it's easier though...

<stikonas>and if it's sufficient for bison

<stikonas>ok, built m4-1.4.6

<deesix>stikonas, amazing job!

<stikonas>well, it wasn't too hard. Just a bit of diffing through source code to find that i had to define -D_GNU_SOURCE=1

<stikonas>hopefully, bison bootstrap will now work, but need to test that...

<deesix>Well, not just this one, but all of the efforts during the last weeks!

<OriansJ>I have a stupid idea to solve the javascript problem with brute force

<stikonas>?

<stikonas>non-free javascript on the web?

<stikonas>or is this some other problem

<OriansJ>the massive unmanagable javascript problem of vendoring

<OriansJ>that even RedHat has abandon dealing with javascript packaging in RPM

<gforce_d11977>OriansJ: and what is your idea about JS?

<OriansJ>have a unique bot for each js developer and assume an incremental only development model for their dependencies

<OriansJ>Then when it finds a the oldest combo that can build the commit, generate a guix package definition and repeat for all commits.

<OriansJ>Make javascipt a seperate channel for guix because it'll become *VERY MESSY* rather quickly

<OriansJ>but enables us to not throw humans at the problem of packaging javascript

<OriansJ>instead throw a server or so at it and forget all about it.

<gforce_d11977>OriansJ: interesting 8-)

<OriansJ>It'll be more of a problem for someone more familiar with machine learning than for me but I thought the idea worth sharing.

<deesix>What would be the role of ML? Detecting patched deps?

<deesix>Does "it build" assumes "it works"?

<OriansJ>deesix: simulating a contagion model of version updates might be a better solution I guess.

<OriansJ>but yes builds with tests probably would be required to make it probbaly correct.

<OriansJ>with the developer of a software package is always patient Zero for the spread of a software release.

<stikonas>in the end it looks like m4-1.4.6 is still not sufficient to bootstrap bison :(. Anyway, it's not wasted efford because it will be easier to go to newer m4's from 1.4.6 than from 1.4.4

<stikonas>oh, it actually works, missed one define...

<stikonas>although, I've upgraded to m4-1.4.7 since it was a free upgrade (no extra work required)

<Hagfish>any idea what else bison needs?

<stikonas>Hagfish: only formalizing build process

<stikonas>we have all dependencies

<stikonas>I manually did it with busybox shell

<stikonas>so basically porting build instructions https://gitlab.com/giomasce/nbs/-/blob/master/root/scripts/continue.sh#L104 to live-bootstrap's "build system"

<stikonas>(change, paths, some defines, etc...)

<stikonas>anyway, m4 PR is up. fossy: https://github.com/fosslinux/live-bootstrap/pull/33

<pder>stikonas: nice work with getting m4 working. I went down a rabbit hole with the regex stuff

<pder>I am trying to run bisons configure script and it wants perl. Do you know if it is really needed?

<stikonas>pder: we use makefile...

<stikonas>I can try to do bison

<stikonas>since I already did it manually

<stikonas>I use makefile from nbs

<stikonas>pder: I'm actually already looking at bison now...

<stikonas>pder: by the way, did you have any more chance to look at coreutils?

<pder>I havent yet. Are there any utils you need in particular?

<stikonas>yes

<stikonas>let me try to remember

<stikonas>we need at least expr sort uname uniq

<stikonas>(I think those are frequently used by configure scripts

<stikonas>so we'll need them to run configure scripts...

<stikonas>although, most of the work was building coreutils lib...

<stikonas>I think once you have that, it's fairly easy to build binaries themselves, most of them is just one additional C file...

<stikonas>on the other hand, maybe those 4 utils need less files from coreutils lib...

<pder>since we are using musl at this stage, should we remove the current build directory, extract the original source and use a new makefile?

<stikonas>pder: current build directory is automatically removed by build function

<stikonas>but we will need new makefile

<stikonas>we can do that by overriding src_prepare function

<stikonas>but yes, clean builds please...

<pder>Currently build/coreutils-5.0 directory exists at the end of the build. But I think its because it was originally built with kaem and not the new bash method

<stikonas>bash method also leaves build dir

<stikonas>but bash method removes build dir before building

<pder>Oh ok

<stikonas> https://github.com/fosslinux/live-bootstrap/blob/master/sysa/helpers.sh#L25

<pder>stikonas: Do you find the Makefile preprocessor defines for a package by trial and error, or are you running the configure script under another environment to get the correct values

<pder>I am wondering if getting coreutils building would be easier if I first tried building it on a musl based system

<stikonas>mostly by trial and error, but I have run configure script under my normal system in glibc and occasionally check values there

<stikonas>I don't copy all config.h, I try to get bare minimum in preprocessor defines...

<stikonas>but yeah, sometimes it takes some time to figure it out...

<stikonas>I'm doing it with bison now...

<stikonas>(in my first testing I used pregenerated config.h from nsb)

<stikonas>s/nsb/nbs/

<stikonas>but basically, I try to run make without defines

<stikonas>look at the error

<stikonas>and try to see what define might be causing it

<stikonas>after I've done quite a few packages, it gets a bit quicker

<stikonas>since errors are similar

<stikonas>pder: feel free to post some errors here

<stikonas>maybe I'll be able to help

<pder> https://paste.debian.net/1184433/

<pder>Here INT does not seem to be defined

<stikonas>does -DUNSIGNED=1 help?

<pder>no, that was actually defined already in that tcc command

<stikonas>and what about

<stikonas>-DHAVE_INTTYPES_H=1 ?

<stikonas>hmm

<stikonas>it's also there...

<stikonas>pder: maybe double check which branch is taken in the preprocessor define above that line?

<stikonas>that's what helped me to figure out regex stuff

<stikonas>I added #error 1, #error 2 lines etc...

<stikonas>and noticed that it was redefined somewhere in .c file (so tcc flag was overridden)

<pder>thats a good point

<fossy><deesix> fossy, I think you're confusing Copyleft with something else.

<fossy>perhaps

<stikonas>well, MIT and BSD are not copyleft...

<stikonas>but that's not a problem for us

<fossy>well, according to the gnu, https://www.gnu.org/licenses/copyleft.en.html

<stikonas>they are still free-software licenses

<fossy>"making a program (or other work) free (in the sense of freedom, not “zero price”), and requiring all modified and extended versions of the program to be free as well."

<fossy>so yeah mit/bsd are not copyleft. My bad

<stikonas>anyway, it's not even code there

<stikonas>(.gitignore)

<fossy>yesh

<fossy>and the patches that are BSD are patches

<stikonas>fossy: merge time :D

<fossy>so it dosent really matter

<stikonas> https://github.com/fosslinux/live-bootstrap/pull/33/files

<fossy>sorry I just left for school at home I shall do it

<stikonas>sure...

<fossy>however I can review

<stikonas>it's just minor m4 update 1.4.4->1.4.7

<stikonas>1.4.7 is good enough for bison...

*fossy should put gpg login keys on laptop maybe

*fossy should also fix gpg signing of git commits

<stikonas>I tried with nbs source and I could build bison. However, building bison from scratch (without config.h) is probably a bit more complicated...

<stikonas>it's the longest config.h I've seen so far

<fossy>:/

<fossy>how many lines

<fossy>iirc bash was 800 fwiw

<stikonas>1730 lines

<fossy>aagh

<stikonas>bison when built is also 1.3 MIB

<stikonas>1.3 MiB

<stikonas>largest binary so far

<stikonas>anyway, we'll do it eventually

<stikonas>we have all dependencies...

<fossy>finally :D