17100+ entries in 0.028s
mod6: these are public keys that you need in your keyring
mod6: hanbot: no, sorry this is confusing.
mod6: this is basically outside of V
mod6: only in the context of verifying the packages signatures
mod6: <+mircea_popescu> try just korsgaard << i guess you could try this
mod6: place that key on your gnupg keyring via --import
mod6: and upon a few others successfully building, trinque, can you work your magic with deedbot and place that guy in there so its like deedbot.org/build-bitcoind-v99996K.sh or whatever?
☟︎☟︎ mod6: thanks danielpbarron -- hey please give this a try if you can. I figured that you might be a good one to simplify the steps and up date the wiki as soon as we get some confirmation that all is good with the script
mod6: hanbot: everything going ok? is it building or, having any hangups/questions?
mod6: !up ascii_butugychag
mod6: hanbot: ok awesome. let me know how it goes.
mod6: the one I just posted?
mod6: you just need to create a .wot dir and place keys in there, then (in the same directory do this): `./build-bitcoind-v99996.sh`
☟︎ mod6: here are my changes, please review and try this out:
mod6: ok folks, my build succeeded with the changes to moving V outside of the rotor directory.
mod6: (build is still going, hopefully will be done soon - will let you all know. salud!)
mod6: aight, i better get me some lunch to soak up this coffee. bbs.
mod6: mircea_popescu: makes sense.
mod6: ascii_butugychag: interesting they would abolish teaching something they created.
mod6: thats the one 'eh. thx guise.
mod6: how much does actual scheme differ from common lisp or lisp? can i get a book for lisp (whatever latest megabook alf has posted recently) or do I need a scheme specific book?
mod6: i've gotta take a crash course in scheme very quickly or I won't be able to make heads or tails out of these code submissions. eek!
mod6: im just excited to use something called 'sexpr'
mod6: <+ascii_butugychag> ideally a vtron ought to be able to apply ANY well-defined operation << ok sure, this could be a separate feature of V i guess... have to think on this.
mod6: !up ascii_butugychag
mod6: yup, eventually this could be a thing though, if we build our own tool
mod6: as far as comments in the vpatch that are mearly just for archaeological or annotative purposes, i think something could be done here especially when we get our own diff/patch.
mod6: not to worry about your signed genesis tho - i gardened it out. the mirror just has the right one.
mod6: hehehe. interesting thoughts here today. i need to think on this stuff.
mod6: i wonder if we couldnt find 'the right ones' with some sort of merkle tree that represents the best chain.
mod6 ponders this question for a minute.
mod6: punkman: good question, not sure at all. can try to take a peek once we get past the 1st. i've got stuff stacked to the celing right now
mod6: ascii_butugychag: i'll try to give your new patches a shot tonight.
mod6: back to CompSci 101!
mod6: anyway, speaking of great things (tm), shiva really was awesome to see working lastnight. very impressive stuff. i just gotta learn scheme now hahah.
mod6: That pie looked nice tho!
mod6: I may have had too much coffee...
mod6: tl;dr we need all of you! you are what make the republic possible!
mod6: s/sovereigns/sovereign/
mod6: We've come a very long way, and we've still got some road ahead (we all know), but we can't have a republic with out the sovereigns participants who wish to make it.
mod6: And honestly, I really look forward to working on these projects every day, and with all of you. :]
mod6: ascii_butugychag much appreciates the labours of mod6 << alf, you've put in a lot of effort too, and we all appreciate that very much.
mod6: ok the new script, having V outside of the rotor dir seems to be building just fine so far... will update again when its complete, or if fails.
mod6: !up ascii_butugychag
mod6: Things are moving really fast here sometimes, and that can be hard to keep up with, but it's part of the deal.
mod6: I wouldn't trade what we have here for anything. If I could work it out, this is all I would do every day.
mod6: b-a has honest and knowledgeable people who care about the innerworkings of the technology, on a low-level, as well as on a meta level.
mod6: <+mircea_popescu> hey mod6 how would you rate working with b-a vs working with job people ? are we just as enervating ye t? << this beats anything else I've ever encountered by a wide margin.
mod6: <+mircea_popescu> mod6 alrighty, seems it's teh consensus here. << ok lemme put this together, and will post in here for you guys to review, and people to test.
mod6: that's probably more acceptable than the following: ~/.wot by default (in the script) or stopping the script mid-processing to require human action (action should be taken prior to execution)
mod6: and I think this is what we want. So we can stick with that, and probably not break anything -- i'll just move V & .wot outside of the rotor dir.
mod6: ok so lets keep in mind that v99996 of V will only look for .wot in the current working directory unless told to look elsewhere for it explicitly.
mod6: and that is not a one-button-push solution as you asked for.
mod6: that would be fine, but then we're in the situation where every single time that someone runs it for the first time, the script will fail with an error.
mod6: <+ascii_butugychag> i still don't get why a vtron should use the net at all << I'm open to well defined explicit ideas here.
mod6: so I think that could work actually.
mod6: ./v.pl p verbose rotor/TEST2 asciilifeform_malleus_mikehearnificarum.vpatch
mod6: if we have V source and .wot adjacent to rotor dir, then we could press like the following:
mod6: so continuing with my thought here..
mod6: this was never really meant to be "the thing" just was initially meant for testing. somehow became "the way"
mod6: eh. bad things tend to happen when this script is run more than once.
mod6: <+mircea_popescu> why can't it be populated by hand ? << how can you populate by hand while the script is running?
mod6: the only actual alternative here is to create .wot adjacent to rotor directory, along with the V source
mod6: ok. so if we create a .wot in /.../rotor/ (so, rotor/.wot), then it can not be populated by hand...
mod6: then it moves into these directories to continue all of the gyrations that need to happen to build everything
mod6: mkdir -p rotor/TEST2
mod6: mkdir -p rotor/toolchain
mod6: so the script as it currently exists, creates these directories:
mod6: ok so lets talk this through a bit.
mod6: Chicken/Egg problem with that script then.
mod6: I can not reconcile this.
mod6: so it should be populated by hand, outside of the build path, and referenced only in the script for access.
mod6: I can do that just fine yes, but i don't think we should populate the .wot directory via script.
mod6: make note that V does not /expect/ or /default/ to a ~/.wot dir, it just so happens in this case, that it needs to be somewhere accessable outside of the rotor build path
mod6: .wot must be created by hand, and populated by hand.
mod6: mircea_popescu: it has to be, there is no way that we can create and populate a .wot directory inside of a directory that is created by the script
mod6: !up ascii_butugychag
mod6: ./v.pl p verbose TEST2 asciilifeform_malleus_mikehearnificarum.vpatch wd ~/.wot
mod6: so I'm going to have the script reference ~/.wot -- this seems like a resonable place to put it -- again, V will not expect it to be there, so an additional param is placed in the V command as such:
mod6: One notable change to the build script linked on the wiki: Since we're pressing out V in a directory that gets created by the script, there is no way to have a .wot inside this dir that it can find -- the script ~must~ reference a .wot directory somewhere outside of the entire rotor build area.
mod6: All: Stand-by I've made some updates to the script referenced in the wiki as to drop in the latest version of V (with the latest 3 patches in the mirror) - im gonna test it, then post it here. It'd be good to have some of you test it too.
mod6: "Eventually we can migrate the whole RPC orchestra to this." << seems reasonable.
☟︎☟︎☟︎ mod6: scheme_define(sc, sc->global_env, mk_symbol(sc, "btc-shutdown" ), mk_foreign_func(sc, btc_shutdown));
mod6: scheme_define(sc, sc->global_env, mk_symbol(sc, "btc-get-best-height" ), mk_foreign_func(sc, btc_get_best_height));