log☇︎
138300+ entries in 0.387s
mod6: but furthermore, i tend to agree. if i thought that my V would stay in perl forever, i'd probably already have created the genesis. however, i'd like to see if I can get the Ada version off the ground.
mod6: <+trinque> genesis doesn't have to mean perfect. <+trinque> nobody's going to come for you with pitchforks << no one expects a spanish something or other either...
asciilifeform: now to see which finger...
asciilifeform: this is not the 1st time i plugged a finger into 220v. the breaker, i will however point out -- worked
mod6: never hurts to have someone measure for the n'th time for you before you cut, however.
trinque respectfully points out that at least by his eyes, V forces personal responsibility, not a pretense to being immaculately conceived.
mod6: I'll do what I can to vet it.
mod6: Additionally, if someone in the republic wishes to create a vpatch/genesis and have a second pair of eyes look it over, by all means, send it to me.
mod6: I should have examined/tested your mpi vpatches, alf. I'll continue to try to be a second pair of eyes, reading them. There's no substitute for reading. For those following along, take note.
a111: Logged on 2017-12-05 17:47 asciilifeform: ( lessee if i properly ate & shat, 'i do not consider myself a programmer, for i have another craft. let's say i am an amateur programmer. and yet though i am an amateur, i find myself having written tens of thou. of loc in this-here life. and at least a min of 10k loc for web. but wanna hear sumthing ? never have i created a security hole in any. never. do you suppose i simply had good luck ? possibly luck. or possibly i wrote the c
asciilifeform: now i'ma go and get the mop, pick up the liquishit, brb.
asciilifeform: if not tried -- wrong to say that it worx.
mircea_popescu: observe that after bitching about the quality of work in empire, along the lines of "everything works for as long as you don't use it", our pile of stuff exhibits the same exact property.
asciilifeform: mircea_popescu: at any rate, mod6 is right , i'ma have to regrind the 2nd patch. and also stuck , deservedly, with the chore of demonstrating that the payloads are unaltered.
mod6: fwiw, i've never even looked at this!
mircea_popescu: now stop doing this inane shit, it's a significant drag on resources.
asciilifeform: the bigger problem is that nobody noticed.
mircea_popescu: the larger problem is that to arrive to this conclusion, you first bitched at everyone else.
mircea_popescu: asciilifeform that's the smaller problem.
asciilifeform: but a genesis . all of the antecedents are 'false'
asciilifeform: phf how the hell did this get eaten by your vtron
mircea_popescu: asciilifeform> what means 'finished', it's a spoil of war artifact. << that's entirely not related to the discussion.
asciilifeform: how come nobody bothered to look at second_cut with naked eye ?
asciilifeform: ok this is pretty sad
diana_coman: asciilifeform, mk, so no need for the tar I gather since you can easily reproduce it anyway
asciilifeform: ( the two README are bitwise-identical )
asciilifeform: now trying to find why !
asciilifeform: ( patches themselves are never hashed , aside from by gpg when verifying sig )
asciilifeform: mod6: in this case asciilifeform is quite puzzled why it appears to need a regrind; none of the file hashes should have changed
mod6: then we have to regrind stuff.
mod6: everytime we have this problem (note it's not the first) where we have someones vpatch with garbage in it....
asciilifeform: at this point i'm quite curious re what gives
asciilifeform: now where's that tarball
mod6: it can't check the expected sha of a patch BEFORE its DONE patching.
trinque: will at some point release vpatches with sane method names. but thing works, and I'm not going to obscure history because I knew less in the past.
mod6: during the press process, it finds that shas do not match the expected, and DIES.
mod6: <+mod6> <+asciilifeform> diana_coman, mod6 , both of you appear to be suffering from mod6's barfolade-leaving vtron << wut << my V pukes exactly when it can.
mod6: Anyway, the hope was that it would replace my other PoC.
trinque: nobody's going to come for you with pitchforks
mod6: I had started a new V in Ada, had to stick it in the drawer for a while. Not getting to exactly where I wanted to go (easy to read, fits in head, no perl/perlisms) with it at this time.
trinque: genesis doesn't have to mean perfect.
mod6: Despite 2 years of development, we still arn't there yet.
mod6: <+mircea_popescu> mod6 wanna genesis your vtron ? << at this rate, doesn't look like it.
mod6: <+asciilifeform> diana_coman, mod6 , both of you appear to be suffering from mod6's barfolade-leaving vtron << wut
diana_coman: I'll wipe again and try your v too for completeness at least
asciilifeform brb, teatime.
asciilifeform: whole thing, as before.
diana_coman: wiped previous dir, took everything out with curl etc
asciilifeform: plox to tar it up and post ?
diana_coman: asciilifeform, this was FRESH
asciilifeform: diana_coman, mod6 , both of you appear to be suffering from mod6's barfolade-leaving vtron
asciilifeform: ( and fwiw phf pressed and built the demo year+ ago )
mircea_popescu admires how the "finished" mpi managed to take a whole day of 3 people's time and shakes his head displeasedly.
asciilifeform: and so is the rest of it!
asciilifeform: just as they ought to be
asciilifeform: and they are bitwise identical
asciilifeform: and diffed the READMEs
asciilifeform: whereas i just now 'pressed' the old and the new genesis with plain old patch -p1 < old and patch -p1 < new
diana_coman goes to take it again
diana_coman: is there now a problem with second_cut?
diana_coman: so then : I try to press and I get...that
diana_coman: asciilifeform, there is something I don't understand: shouldn't I be able to press the second cut now with the new genesis present?
asciilifeform: ( i.e. the text in 'UPDATE #1' )
asciilifeform: it does not appear in either the original genesis, nor the regrind, see for yourself.
asciilifeform: diana_coman, mod6 that text only appears in 'second cut'
diana_coman: aha, seems to be same here, confirmed
diana_coman: 2 out of 5 hunks FAILED -- saving rejects to file mpi/README.rej and contents of README.rej are here: http://p.bvulpes.com/pastes/J8ESM/?raw=true
asciilifeform: considering that i made the new genesis by pressing and re-vdiffing, there should be no differences aside from the timestamp cut.
diana_coman: asciilifeform, here it seems to barf on the ...README file?
asciilifeform: mod6: show me the eggog ?
mod6: when i went to press, bzzzt.
mod6: now, on the other hand, yeah, i saw the second_cut vpatch link removed from loper... but I went ahead and updated my sandbox to have alf's latest & greatest mpi-genesis.
asciilifeform goes to see
diana_coman: asciilifeform, did you take out the second_cut patch link from the updated http://www.loper-os.org/?p=1533 ? or am I just not seeing it/not getting something?
diana_coman: I can confirm that the new genesis & the old second_cut vpatch are now at least recognised by mod6's v
mod6: alright, im about to check your new ones here. i can confirm that the original 'mpi-genesis.vpatch' (f254bedf1e3241eb9de17232b630a0614f1cc54ff9c5407d87d79174e211833bcfc0135c89b4abcab2446acd93137a8e1b0798704ad7e4d498cc52c836c82c2b) gets dropped on the floor because of the addtional timestamps.
asciilifeform: ( a working vtron will immediately barf if encountering a file mismatching the claimed hash )
diana_coman: asciilifeform, thank you, I'll look in a minute; (had all hands full a minute here with all sorts)
asciilifeform: the issue is as fixed as it gets. i posted the grep item as example of how to verify, without even a vtron, that nothing has been slipped in from under the table.
asciilifeform: http://www.loper-os.org/pub/mpi/mpi-genesis.vpatch http://www.loper-os.org/pub/mpi/mpi-genesis.vpatch.asciilifeform.sig for the l0gz. ☟︎
asciilifeform: ( one is, if it isn't clear, the 2015 sad genesis; the other -- the fixed, in http://btcbase.org/log/2017-12-06#1747474 . ) ☝︎
asciilifeform: let me also demonstrate for the record:
a111: Logged on 2017-12-06 19:48 asciilifeform: having to comb l0gz to find these, is becoming painful. any chance of deedbot learning to eat vpatches+sigs, trinque ?
trinque: http://btcbase.org/log/2017-12-06#1747462 << don't want to step on phf's toes here; he's operating the logger and v-patch viewer ☝︎
asciilifeform: ( aside from some obsolete matter on trb ml )
asciilifeform: phf: if you had some code in your patch viewer to eat this type of horror, as 'special case', it is now a good time to throw it out
asciilifeform: ( pretty sure asciilifeform is not the only one who has committed this sin. )
asciilifeform: i recommend other folx to look at their vdiff, and see that it does not suffer from timestampism.
asciilifeform: fwiw asciilifeform has purged afaik all copies of old-style vdiff.sh from his boxen, so this headache should not recur.
asciilifeform: i tested with my vtron, as pictured in diana_coman's tarball, and it worx.
asciilifeform: diana_coman: plox to verify that this worx as described above, when you get a chance.
asciilifeform: clean ( in terms of not actually having any effect on pressed hashes and the descendant patch 'second cut' ) fix.
mircea_popescu: asciilifeform phf pluriously said he's doing it by hand for now ; i see no problem with this. correct procedure would thereby be to ping him with items
mircea_popescu: asciilifeform you misunderstand teh tradition!
asciilifeform: traditionally deedbot is the one who eats signed matter
mircea_popescu: atm there's bot, lam-par (terrible name), fg, mpi and ffa.
asciilifeform: having to comb l0gz to find these, is becoming painful. any chance of deedbot learning to eat vpatches+sigs, trinque ? ☟︎
asciilifeform: which immediately took me to the culprit
asciilifeform: says 'are you sure this is a vpatch'
asciilifeform: i tried it with diana_coman's copy of asciilifeform's last vtron, and it has correct barfola