18500+ entries in 0.045s
mod6: shinohai: btw, i can walk you through getting an openbsd version going. you have to manually add some patches posted to the ML by 'phf'?
mod6: also -verifyall should be an option for you with TEST2
mod6: one thing at a time though.
mod6: <+trinque> yes but this is seriously layered and needs to be smashed into one script. << this is a good point there a bunch of gyrations in the current script that could be folded all into one better script.
mod6: cause it died right then. heh.
mod6: <+mircea_popescu> seriously mod6, VERY nice job with this. 19 yo can use it! << this
mod6: <+mircea_popescu> wut sarc << oh thought you had sarc tag on about the seals warning your 19yo got. :]
mod6: There's a bunch of loose ends. We're getting there...
mod6: I've got a short week this week. I'll get some of that cleaned up.
mod6: yea, we need a "get your TEST2 up and going" section.
mod6: ah, ok. It's not super easy to follow unless you've been keeping up with all the testing. I'm trying to keep the ML clean so people don't get tripped up later.
mod6: mircea_popescu: I'll reflect on this conversation and your trials/tribulations and use it to guide us going forward to the finish line here.
mod6: ofc it could be helpful and spit that stuff out to stdout and let a fella know.
mod6: yeah, noted. i think the design decision there was "if i put it in pwd, someone might not know where it is, they may just check ~/ first."
mod6: on an old ass core2duo too :]
mod6: mine took ~30 minutes.
mod6: yeah mine just finished.
mod6: hehhe, we went through that once didn't we.
mod6: it /will/ get easier. it's our mission.
mod6: this is a good point kako.
mod6: i think i usually execute this like: `LC_ALL=C ./bitcoind -myip=1.2.3.4 ... ect`
mod6: <+mircea_popescu> listen we really gotta pick one of these and stick to it. << will sort this out with the manifest/file-o-hashes
mod6: If anyone else wants to do this tonight, to replicate my thing, I am here.
mod6: I am following my exact instructions above ^^^ nearly done building a rotor+V+TEST2.
mod6: yeah, the manual says about ".asc"
mod6: danielpbarron: do you have "asciilifeform.asc" in your .wot directory?
mod6: Then if you take that paste, chmod +x it, run it, it /should/ pull down all of the deps (still not complete, grabs stuff over the web), pull down V, press a 'TEST2', then build rotor, and then finally bitcoind inside of it.
mod6: Ok mircea_popescu asciilifeform ben_vulpes trinque : The latest version of my rotor+V+TEST2 script is here:
http://dpaste.com/1R04312.txt : All you should need to do before hand is create a ~/.wot dir and add; "asciilifeform.asc", "mircea_popescu.asc", "mod6.asc", "ben_vulpes.asc", "trinque.asc", and "punkman.asc" into that directory.
mod6: is that with my 'V', or post the log line where he gave you that.
mod6: Who/What/Where/When DPB
mod6: if you don't tell it where to put them it creates ~/.wot ~/.seals and then drops the patchdir in your pwd.
mod6: this is all in the doc.
mod6: and yah, btw, you can tell V where to put .wot .seals and your patchdir.
mod6: so where are you at now, and how can I help you accomplish your goal.
mod6: <+mircea_popescu> as it is i put .wot in /trb/.wot but the .seals are still up one level ;/ << noted.
mod6: <+mircea_popescu> mod6 as a purely aesthetic point, i hate that your v puts its files/dirs straight under ~. it would be much better if it made them under current dir. << alright
mod6: +asciilifeform> looks like mod6's script actually fetches it from openssl site << yes. for now, for testing. i haven't actually put up the stuff yet because until yesterday, wasn't finalized, wasn't signed etc.
mod6: but until we wrap up the final parts as discussed yesterday, i wont clutter up the ml
mod6: <+asciilifeform> mod6 had a set of instructions up for cooking rotor ab initio, but it apparently wasn't in the ml << no. it "works" as far as I and others have tried it -- it relies upon haveing my, alf's, mp's, ben's, and trinque's keys in a ~/.wot dir iirc.
mod6: <+mircea_popescu> seriously mod6, VERY nice job with this. 19 yo can use it! << sarc?
mod6: Alright, good talk.
mod6: so just those three then? and the rest are outside the scope then.
mod6: buildroot + its deps included in this list?
mod6: so just to be clear, so I'm not holding anything up here; hashes of the following tarballs in V: BDB, openssl, and boost.
☟︎ mod6: there's just a ton of stuff to do, 'tis all.
mod6: i don't think anyone is slacking.
mod6: as crazy as that might be
mod6: yeah, i think we need to write our own crypto lib
mod6: or simply just a manifest of tarballs/deps required for the one-button-push deployment of trb
mod6: they're all a can-o-worms
mod6: think its worthwhile just to put out the changes for V to have the checking of the hashes in place, while skipping over any "b" that is false? (files that since been deleted?)
mod6: but then alf said it's not ``'V'ifiable'' or something of the kind.
☟︎☟︎☟︎ mod6: my original idea was the former.
mod6: or re-package the entire source under our own "fork" of these pacakages?
mod6: dl'em, sign 'em, hash 'em, put 'em in a manifest and distribute?
mod6: <+ben_vulpes> freeze 'em. << what is specifically meant by this?
mod6: so I think programatically I have it worked out on how to make this happen, was about to test last weekend? lemme dig up the logs on this.
mod6: 2.4 was ubercrasher for me
mod6: I've been in halt mode for a week now, not sure if this has been sorted yet.
mod6: ben_vulpes, mircea_popescu, asciilifeform: what are we to do about the deps for buildroot?
mod6: asciilifeform: ok. i'll think about how to implement these changes to V. right now, im not sure.
☟︎ mod6: haha blow your vuvuzela
mod6: ah, yeah, sorry -- following the arrows in the graph.
mod6: so then those antecedents would point to the new vpatch (at the same node level as asciilifeform_ver_no_5_4_and_irc_is_gone_and_now_must_give_ip.vpatch) but a separate node.
mod6: <+asciilifeform> it splits off from the node immediately prior to the removal << so in this scenario, the antecedents of asciilifeform_ver_no_5_4_and_irc_is_gone_and_now_must_give_ip.vpatch are [dns_thermonyukyoolar, rev-bump, static_makefile_v002, genesis ]
mod6: i thought 'wild' mode is simply when no one in wot has provided a seal corresponding to a given vpatch
mod6: i haven't quite figured out what to do about this scenario yet.
mod6: Scenario: Guy creates vpatch that utilizes irc.h (removed in vpatch asciilifeform_ver_no_5_4_and_irc_is_gone_and_now_must_give_ip.vpatch) must ensure that Guy's patch is on it's own tree?
mod6: I guess that makes sense since it wouldn't share any antecedents with the original graph.
mod6: <+asciilifeform> it would end up as an altogether other tree in the graph << so said patch to add documentation dir would be its own root?
mod6: oh, i see, so like if a patch further down the line (in time) remove a file that a specific sub tree relies upon, that those become removed?
mod6: disconnected graphs?