<stikonas>I just don't see an easy way to patch libc like that <stikonas>libc's in different programs are completely independent <stikonas>I think bauen1 said you can only do that in kernel <stikonas>but then we can only do that once we have our own kernel... <stikonas>i think removing timestamps in from final files is easier <stikonas>(once installation happens with DESTDIR, it's quite easy to purge timestamps) <gef>stikonas: the monotonic increase should theoretically always work, otherwise software makes invalid assumptions about execution order. Timestamps could be a form of validation between different runs, in that the sequence of steps is stable (it is not a guarantee per se, but it will catch many a perpetrator). IMHO, this matters primarily for the earlier steps of bootstrapping. <stikonas>gef: how would libc know the previous timestamp? <gef>ah, it has to be thrown away at that point, libc arrives much later, is that what you ask? <stikonas>it sounds like some "global" inter process variable <stikonas>well, I'm just confused how one would implement this monotonically increasing timestamp <gef>idea: perhaps some higher bits of the timestamp represent a phase of the bootstrapping - does that sound interesting? <stikonas>and after all the renumberings in parts.md I'm a bit sceptical to introduce manual numbering (and this time in code) <stikonas>well, it's just that it seems to me that two executales never share any memory state <stikonas>and I think POSIX basically guaranteeds that unless some process forks, in which case two processes will share state <stikonas>but I think implementation will be a bit tricky <stikonas>i.e. we need to patch libc to have some reservered memory are between all processes <stikonas>and that will only work without threads for sequential buidls (athough at the moment that's what we have) <OriansJ>stikonas: fopen("/example.timer", "rw"); <gef>here is a bootstrapping problem for future geek generations: <gef>"The basic idea is pretty simple: The code starts with a magical snippet that gets interpreted by both architectures and basically performs a conditional jump based on which architecture is runing the code." <fossy>holy shit the stars just blew up <fossy>it went from like 5 stars to 49 stars on live bootstrap <bauen1>^ and now live-bootstrap has a lot more "to show" like gcc-4.0.4 running ***alendvai__ is now known as attila_lendvai
<melg8>Hi, i've managed to fix touch by rebuilding it on coreutils 5 second pass. But now encountered another problem. It can't handle symlinks. First available version with that setup isĀ 8.1 (2009-11-18) [stable] in contrast with our 6.10 (2008-01-22) [stable]. So, can somebody explain why 6.10 were choosed? and what problems might be, with trying 8.1 <melg8>to build? and should i add it as separate step, or try to replace 6.10? <gforce_de1977>melg8: measures needed RAM from /proc/meminfo every second and plot it <melg8>I mean, how you try to lower max ram? by doing what? <gforce_de1977>melg8: deleting sources and unneeded old stuff while compiling new stuff <melg8>so at the end there is nothing from, like M2? <gforce_de1977>dont get me wrong, this is totally unneeded work, but i was interested <melg8>nice idea, but i think that we need both options - minimal and full, so it could be build in constraint env, but also - so we could control intermediate results <gforce_de1977>you are right, i will add an --autocleanup option for this stuff later <gforce_de1977>finding somebody who has an i386 PC mit 512mb RAM will be hard, but 256mb should be possible 8-) <melg8>it would be useful if somebody will try to start 20 builds at same time) just for fun and reproducibility purposes) <gforce_de1977>melg8: i did already several 1000 builds for fun, see the 'issues' on github. there indeed some problems with reproducibility, but solveable <melg8>yea, im working on reproducibility side of things as well, but i want to clear out my diffs from all dates changes, and then try to fix the rest, hope is to achieve bit by bit reproducibility