19100+ entries in 0.034s
mod6: no, it sync's stuff from the mirror via wget, currently
mod6: how will the secure population of the pubkey dir work? just by pulling keys manually or is this an automated function?
mod6: hmm. well, i can take all of the sync stuff out for sure. will reduce a ton of code.
mod6: One can do this for sure. The idea was, if the user just has the scrpit, and nothing else, they could sync all the latest wots/seals/vpatches from a mirror.
☟︎ mod6: I guess I could just not print who signed the mirrors. Leave the mirror list sigs in place on the server, and they can be checked later by hand if anyone wants. but i kinda like how it shows who signed it.
mod6: will have to think on that a bit. :]
mod6: hmm. chicken/egg type of problem, maybe not so simple. if one wants to check the signed mirrors before init, how can sigs be checked from wot if no wot yet exists.
mod6: anyway, simple change. let me know if something out sticks out.
mod6: found a bug. will fix on next time posted. for now; after `./v.pl init
http://thebitcoin.foundation` is run, run `./v.pl w` to ensure all of the WoT's get imported to the keyring.
mod6: thanks mircea_popescu & ben_vulpes; plz let me know if you have questions or wanna discuss anything about how it works.
mod6: (Hint: Please rtfm at least one of the guides before anyone says "Doesnt work!")
mod6: Thanks in advance for your feedback.
mod6: Ok, so I've posted my version of V for some review before it goes to the ML. Inside the archive you'll find a `v.pl', `v_quick_start.txt', and `v_users_manual.txt' - and each with a corresponding sig.
mod6: neat, just did an autobuild of rotor + TEST2 via V. build was successful, running and pulling blocks. :]
mod6: arg! i gotta finish the documentation on this thing so i can play new eulora!
mod6: lol during kindergarten years
mod6: eh, maybe not the same place
mod6: ah cool, you got a chance to walk through there!
mod6: haha. i recall there was a guy before phf's time that was like, "i can't hang in here! too much sedition!" or something
mod6: that might have been a different d00d
mod6: ok, updated mod6.net with my pubkey.
mod6: nothing in logs, or in terminal stderr or whatnot.
mod6: not that I saw, no.
mod6: oh guess i was wrong, wasn't 377906, was: height=377901
mod6: beware: this is ~10Mb
mod6: that actually doesn't seem like that many.
mod6: 87825 attempts on ssh since Oct 1st.
mod6: nice. ok, might have just been me.
mod6: that might have had an impact.
mod6: looks like i sustained a port 22 attack over the last 3 days.
mod6: ok asciilifeform will look
mod6: ok node is all caught up
mod6: its catching up now...
mod6: After I restarted it did an immediate REORGANIZE
mod6: i didn't see any messages like that. nothing weird in the logs. just stopped at one point.
mod6: I'm gonna fire it back up and see how far it is behind.
mod6: Def didn't run out of disk space or anything. And I don't see anything insane in the logs.
mod6: It /had/ been keeping sync for over 2 months.
mod6: So not sure what happened yesterday, but my bitcoin v0.5.4-TEST2 died yesterday while I wasn't looking.
mod6: so awesome. every exciting stuff.
mod6: asciilifeform: ya, you were right... got nice looking option control now with only @ARGV. not sure what my malfunction was before.
mod6: asciilifeform: yeah, ok - this works just fine now, seems even more clean than getopt::long.
mod6: ascii_field: so yah, now that the code is pretty much complete, I'll see if I can get rid of getopt::long and elegantly implement the options handling on my own.
mod6: Eh, who knows, maybe I can take another wack at that part before I'm finished here.
mod6: Tried out Getopt::Long and it was able to do what I wanted with much less arm-wrestling.
mod6: I actually started with this, but .. it got hairy to control some of the input.
mod6: perhaps later, i could rebuild my own or something.
mod6: its just how it determines options from values.
mod6: one major difference is i'm using Getopt::Long to control user input -- which ends up altering flags instead of 'w' for wot, ends up being '-w' or '--wot' but I think we can get over that.
mod6: ah, no this thing doesn't prompt at all. just command line flags. works a lot like your implementation. no caching, etc.
mod6: I saw your comments in your monthly s.nsa broadcast :)
mod6: then will publish to th elist.
mod6: so that's the only thing left and then just user documentation. and then can start passing around the first version for people to try out to ensure of zero major defects.
mod6: yeah. i mean, "cucumber automated test that surrounds (gives coverage to) the press function"
mod6: sweet, V code is basically complete. one remaining test left to write surrouding 'press' (shouldn't take long), then just documentation to write about the thing.
mod6: ascii_field: iirc only ben_vulpes, mod6, and pete_dushenski had children << I don't have any offspring of my own.
mod6: thx asciilifeform, i knew that didn't look right.
mod6: So, if I make a test-release.vpatch to tie up the leafs for what we have in "v0.5.4-TEST2" or what we're calling "v0.5.4" then it ties up "asciilifeform_add_verifyall_option.vpatch" and "asciilifeform_maxint_locks_corrected.vpatch". If your patches are added after that, they become leafs along with the "test-release.vpatch".
☟︎ mod6: then yours will be added after that.
mod6: like alf and I were discussing last week - we're going to create a release vpatch that will take all leaf edges and tie them up with a new release vertex.
mod6: oh and also, your vpatches won't be added until after the release... so the graph will look a bit different with your 3 vpatches.
mod6: like i said, loose ends :]
mod6: i guess i could add a method that'll check if dot is installed, and if it is, then will generate the svg html file for you... but *shrug*
mod6: at this point, what it'll do is build a whole graphviz dotfile and output that to stdout or a file. the only part that it wont do (because you have to install `dot' separately) is for example: `dot -Tsvg <dotfile> > graph.html`
mod6: i'm trying to wrap up all these automated cucumber tests & loose ends on some stuff.
mod6: I might be able to throw that together. my version should be out for testing in the next week or so though if you just wanna wait. it'll build the whole graph for you with wild patches.
mod6: <+funkenstein_> mod6, thanks for the updated tutorial! << yw
mod6: asciilifeform: ok, done this now. created 'test-release.vpatch' which has incoming edges from all current leaves; this was a decent test for my code too.
mod6: appreciate the input here, im gonna ponder this for a bit.
mod6: am I understanding that correctly?
mod6: ok so. release vpatch would be creating a new vertex that has edges coming from the current leafs.
mod6: right, i want the sync mech to work inside of the bounds of V.
mod6: asciilifeform: hey, thanks for your input/thoughts there.
mod6: ty, having fun building it. :]
mod6: anyway sorry for the verbosity, thanks for listening. just wanted to see if I was on the right track before I get too far along.
mod6: we could have a signed list of mirrors in the same location as the manifest so that there is some redundancy
mod6: also, i'm leaving some room here for mirrors.
mod6: (incase there are patches added to the site webdirectory that are not included in the release manifest)
mod6: or you can pull individual patches if one likes.
mod6: So I added subroutines to pull all patches, wots and seals from the foundation site, and/or audit what's already local by checking the local vpatch hashes against the manifest.