log☇︎
21100+ entries in 0.037s
mod6: a wise man told me once: life is short and art is long.
mod6: anyway, we'll get there.
mod6: but pre-milestone release, it does get hard to follow. and since I do believe it'll still be some time before we get the next milestone cut, I should prepare some sort of document so individuals can help test. (we very much appreciate the enthusiasm and the help!)
mod6: yah. we would certainly put all the patches applied to a specific baseline into RELEASE_NOTES.txt as it was for v0.5.3.1
mod6: i'm not sure what to do about this as far as the email list is concerened, yet.
mod6: there are a number of different directions these emails go in; patching for v0.5.3.1, pogotronic, gentoo, etc, etc. so I'll try my best to make this apparent when I write up a patch list, etc.
mod6: so phf brings to light a good point, reading through the email list, especially if you haven't read the b-a logs from oct-14 on is probably more than a bit hard to follow. ascii_field brings up a good point about having a 'family tree'
mod6: ah hmm
mod6: and trinque, did you hvae that -fPIC issue on gentoo with uClibC? that's the same error I was talking about all last month and in the SoBA
mod6: ah ok
mod6: ascii_field: i did have a problem with it a number of days ago when I first tried it, but it was just an environment related issue. this build, I literally just did it, worked fine.
mod6: when?
mod6: :]
mod6: !up ascii_field
mod6: it should allow you to sync off of mp's blockchain w/the appropriate cmdline params and then do dumpblock/eatblock when it's finished or whatever you like.
mod6: that btw, was built on x86-64 deb6/glibc env.
mod6: ok shinohai: http://thebitcoin.foundation/misc/stator-buildlog-wDumpBlockAndEatBlockApplied.txt
mod6: i saw that comment yesterday, I briefly looked at it's page ascii_field, I'll take a deeper look at musl soon. hopefully that'll get us further?
mod6: [jurov run's the mailman stuff, so he'd be probably more apt to grok whatever your asking for ]
mod6: jurov: can you parse this and understand what he's talking about?? ^^^
mod6: phf: yeah, im not sure what you're asking for
mod6: phf: there are specific reasons why the attachments are split into separate files.
mod6: But as I get through more of these and test more of these, I'll put something together to make this process easier.
mod6: But I've only started scratching the surface with alf's latest, so this hasn't been done yet. All of these are still in my "Highly Experemental" category. AKA: use at your own risk.
mod6: basically, instead of me making a whole bunch of different one-off scripts for peoples seperate clients and whatever stack they've got, I just create one script that will patch in & verify all the scripts at once. usually after I've tried and tested them all myself, peronsally.
mod6: are you asking me to write an email client script?
mod6: ok, i like mutt :]
mod6: <+phf> mod6: no no each email. i thought that was the whole point of ascii's approach, i.e. linux kernel style "read email, think, apply the patch" << im not sure what their process is.
mod6: plus, create a How-To guide. Both of which need updating for the flurry of recent patches that have been submitted. Just haven't had a chance yet.
mod6: <+phf> the process was needlessly complicated since my mail client lets me do a bunch of those steps (patching, gpg verifying, etc) with a single key, so if i had an mbox, i could just import it, and then use a more familiar interface << so, what I've done in the past was; create a perl script that pulls down and verifies all the patches and applies them to a common baseline.
mod6: so wait, you're just going through each email and pulling out patches? or are you on that part of jurov's website with the signed patches?
mod6: ahh. im not sure i remember mbox. and yeah, the whole thing is a bit... unwieldly
mod6: can you point me to the web-archive you're using? just curious.
mod6: ahhh
mod6: good deal!
mod6: heh, this boost compile is taking a while, because i'm also syncing at the same time haha
mod6: yw :]
mod6: I'm creating a log of this, and will post for everyone to look at once complete.
mod6: (with openssl/bdb/boost)
mod6: which, btw, they hvae patched in just fine... building the whole thing now.
mod6: ex: are you trying to patch v0.5.3 to get to v0.5.3.1? (You can just download the release tarball). Are you trying to patch v0.5.3.1-RELEASE with alf's patches? (must read emails to figure out the deps, OR you can just build the stator which includes all of alf's patches with exception of dumpblock & eatblock), those must be patched post extraction of the stator tarball -- of which im actually testing now.
mod6: phf: anyway, what exactly is it that you're trying to achieve?
mod6: I'll work on something for that within the next week probably.
mod6: I will work on a patch list and maybe a script later this month. It is a bit hard to follow. ☟︎
mod6: So a bunch have patches have been submitted in the last month. A read through each of the emails is kindof required at this point because they all have specific instructions and dependantcies.
mod6: we've got quite a lot to do before we're there anyway.
mod6: punkman: ok. i thought we had decided to leave the miner in there for now. but yeah, thanks I'll let ya know.
mod6: one of the things that pains me with the SHA1s re-written into the filenames, is if you pull these files with curl, you have to rename them to their original names before you can verify the signatures.
mod6: just a minute here.
mod6: lemme give it a shot on my end first, see what happens so I can give you valid help
mod6: sure, ok. so what we'll need to do (and even I haven't tried patching those in myself yet) is to extract the stator, then apply the patches.
mod6: yeah, that's what i was saying before: leave your v0.5.3.1-RELEASE as-is. Then setup a new environment to give the "stator" build a try -- is pre-patched, so should be able to compile and run, or if your slightly more daring, just run the included pre-compiled (by alf) binary (ensure to check sigs first!)
mod6: shinohai: ok let's work through it
mod6: !up ascii_field
mod6: <+ascii_field> incidentally, anybody ever try parallelizing sigchecking ? << this would be interesting to try & do some perf testing with.
mod6: might be just over 48hrs or something for direct sync
mod6: oh wow, your nearly there. great!
mod6: 239k+
mod6: well! crusing right along.
mod6: np
mod6: !up ascii_field
mod6: 237k+
mod6: seems like this is going faster, but we'll see how long it takes to go from 300k-350k
mod6: typical sync via irc seeding took me ~6 days
mod6: ah sweet.
mod6: how long have you been sync'ing for now? 2 days?
mod6: nice
mod6: er 207+
mod6: 107+
mod6: 192k+
mod6: cool shinohai
mod6: 180k
mod6: !up ascii_field
mod6: oh but yah, im sync'in
mod6: haha
mod6: well, maybe it doesn't make sense to do that if gribble does stuff.
mod6: !up ascii_field
mod6: 164k
mod6: !up ascii_field
mod6: i didn't know it did that for some reason
mod6: ah, punkman thanks lol.
mod6: aight might have to iron out some kinks.
mod6 looks around
mod6: %tslb
mod6: somehow cat'd that together. o.O, have to fix that
mod6: arg! lol
mod6: %bal 1FundZy7m7b8begbh9haCguKJcAdFopRJ9
mod6: for instance:
mod6: yeah, except that doesn't tell you anything unless you click through it
mod6: %d
mod6: it talks to btc.blockr.io and parses some JSON
mod6: %bal 14QPeQ2UZaMw9khqQeisVNT54j6A3U5KfE
mod6: %h
mod6: 113k
mod6: lemme see..
mod6: sometimes i feel like i should mod the old atcbot just to sit in here and do things like %addr <BTC_ADDRESS> and then spit back info, or for %block or %tx
mod6: haven't had a chance to play iwth it yet.
mod6: i need to get MY pogo going! lol. it's just been sitting here in a box.
mod6: not yet.
mod6: 20k