<stikonas>Hagfish: I think you just volunteered to maintain step numbers :D <stikonas>anyway, I should look a bit more into perl crashes... <OriansJ>Hagfish: The rule around here is "whoever does, decides" <OriansJ>If you want something to be a certain way, you either put it the work or accept whatever someone else who is willing to put in the work does. <OriansJ>No exceptions. Not for me, Not for janneke. not a single exception. <OriansJ>anyone can provide input or recommendations but at the end of the day, the people doing the work decide what they are going to be doing. <stikonas>well, it's not like we don't like the numbers <stikonas>but sometimes it's more practical to at least temporarily remove part numbers <stikonas>fossy, pder: so I think I've found the cause of crashes in perl 5.6.2 <stikonas>problem in config.h caused unterminated strings <pder>oh sweet, thats great news. Does that possibly mean a path to newer perls? <stikonas>You have the wrong version of bison in your path; currently 1.875 <stikonas>2.0, 2.1, 2.3, 2.4, 2.5, 2.6 or 2.7 is required. <pder>Ha, thats very specific. I wonder whats wrong with 2.2? <pder>What input file to bison gives that error? <pder>Are you using a perl git repo? <stikonas>pder: so I think we can run newer automake and autoconf with perl 5.6 but I need to work on modules <stikonas>pder: newer autoconfs also have the same gawk error that your saw <stikonas>gawk: ./conf45203-6320/subs.awk:3: ^ unexpected newline <Hagfish>in theory i could submit a patch to add numbers of a readme that didn't have them, but that's about the limit of my abilities with this sort of project <Hagfish>also, like i say, i don't know if the aesthetic benefit of having the numbers is justified by the downsides that come with it <Hagfish>as stikonas says, it's best to wait until things are more stable <stikonas>pder: in any case, I think I can unlock perl 5.8 (that doesn't have problems with bison yet) if we need newer perl <stikonas>fossy: so perl 5.6.2 should be ready for merge <stikonas>well, for perl 5.8 we also need to build lib/Config.pm for perl 5.6... <pabs3>roptat: is your recent scala work published in the scabo repository or elsewhere? <OriansJ>and just shook out a few bugs from M2libc's string.h <fossy>stikonas[m]: is there anything bending for perl 5.6.2 <Hagfish>i interpreted "bending" as "moving", in the sense of being unstuck, but "pending" probably makes more sense ***cbaines_ is now known as cbaines
<fossy>gforce_d11977: lol, yes, typo, i meant pending <roptat>I want to make sure it works before I change everything ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<pder>stikonas: I cleaned up my branches on github. You should be able to do a git fetch --prune myremote <stikonas>later in the evening I can try to play a bit with your binutils branch <stikonas>(I'm thinking that maybe we can get binutils before building perl with extentions) <pder>By extensions do you mean loadable modules or is that different? <stikonas>well, in perl there is lib folder and there is ext folder <stikonas>but those from lib can be just loaded automatically by miniperl <pder>I dont know if its helpful, but there does exist something called staticperl, which builds many modules into one static binary <stikonas>I don't think it will be super hard to get those modules though... <stikonas>but I thought having dynamic linking might help <stikonas>but I don't know if it's hard requirement <stikonas>hmm, I think static perl needs ./Configure script to work <pder>We might also have problems with our current bash build <stikonas>but I think ./configure depends on binutils <stikonas>anyway, I think if we can get binutils, then we can start rebuilding a lot of stuff <stikonas>then we can rebuild tcc (probably also with its handrirten ./configure script) ***ericonr- is now known as ericonr
<pder>binutils might be doable without a configure script. Its just a lot of work <pder>We can also probably build individual pieces that we need initialy <stikonas>yeah, but configure script is probably doable <stikonas>just need to test some different autoconf/automake versions... <stikonas>anyway, if we need newer autoconf/automake, I'll take a look at getting perl modules <stikonas>1) try to get perl 5.6.2 or build miniperl 5.8.9 first <stikonas>I've already done some work on 5.8 a while ago <stikonas>before we started looking at older perls to regenerate those header files <stikonas>and 5.8 is probably enough to run even newest autoconf/automake <pder>stikonas: autoconf works nicely with creating configure for bash <pder>I should have a new bash build that should work better and provide an interactive shell <pder>I pushed a branch named bash that will need autoconf merged before its ready for PR <stikonas>oh, and this old bash does not even need automake <stikonas>pder: any reason you are not doing "make install" ? <stikonas>other than that I guess you can make PR (just include autoconf) in the same PR <pder>no good reason really other that we only care about the one binary <pder>Are you still making changes to autoconf? Do you mind if I rebase? <stikonas>no, I'm not doing any changes to autoconf <stikonas>you might need to adjust readme numbers... <stikonas>(and probably again after fossy merges perl 5.6.2) <stikonas>pder: oh, there is one trailing whitespace that I want to remove <stikonas>force pushed to stikonas/autotools branch <pder>Its nice being able to chroot into our environment without using busybox <pder>stikonas: I think you need to fetch. You didnt rebase on latest master ***Server sets mode: +cnt
***mephista is now known as spicy_icecream
***Noisytoot_ is now known as Noisytoot
***dftxbs3e_ is now known as dftxbs3e
<stikonas>pder1: if interactive bash works, maybe we can call bash (bash --login?) after other parts are finished ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
***roptat_ is now known as roptat
***ba is now known as bandali
<fossy>need to mknod first /dev/tty <stikonas>fossy: I already did that in my autoconf commit <stikonas>because autotools on its own is not too interesting <stikonas>but if pder can use it for something, that's read <fossy>been debugging linux kernel for a bit, still not completely sure whats wrong <stikonas>for now I'm not going to change anything <stikonas>so I might as well wait a bit to see what's needed <fossy>stikonas: can you review #50 <stikonas>pder: should I rebase autotools on top of perl? <stikonas>well, it's just autoconf, no automake yet <stikonas>hmm, for 51, maybe we can only keep numbering in README? <stikonas>or do you want to have it in kaem and bash scripts too? <fossy>i'll have a think about it - it's probably fine to just have it in README <stikonas>hmm, I'm also thinking if we can do it automatically there? <stikonas>although, I have only very minimal experience with it <fossy>stikonas: i'm trying a thing with markdown and css <stikonas>I guess pandoc can covert between md and rst <fossy>but modified for our purposes <stikonas>It might still be good to keep section/subsections <fossy>do you mean like the 1.xx like i had before <stikonas>hmm I'm not really sure which one I like more... <fossy>i prefer automatic numbering <fossy>the main thing i dislike about x.yy is it's a poor indicator of progress <fossy>when we have a better logging system we can show like 30/47 or whatever <fossy>(although some steps take significantly longer than others) <stikonas>pder: I've now rebase autotools on top of perl 5.6.2 that fossy merged <fossy>thanks i forgot about reflog <fossy>stikonas: i might look into rst now; gh strips css <stikonas>or maybe first try some test file somewhere... <fossy>but github isn't bootstrapped either :P <fossy>m, maybe,that's an annoying about of work for numbering <bauen1>ironic how you're trying to get live-bootstrap to effectively be selfhosting ... <stikonas>and it will be manually reviewed before merging anyway