Matches for patch, 1691 total results Sorted by newest | relevance
Mon Jul 06 05:06:06 UTC 2015 <ben_vulpes> sitrep: freshly provisioned server builds boost, bdb and openssl w/out a hitch, barfs on compiling bitcoind because lacking i b'leev integer retardation patch
Sun Jul 05 16:51:47 UTC 2015 <assbot> Logged on 05-07-2015 15:38:24; asciilifeform: ;;later tell danielpbarron what, if anything, is peculiar about your synced 0.5.x ? (i.e. what patch set it used? to whom connected ? for how long ? when ? )
Sun Jul 05 15:38:24 UTC 2015 <asciilifeform> ;;later tell danielpbarron what, if anything, is peculiar about your synced 0.5.x ? (i.e. what patch set it used? to whom connected ? for how long ? when ? )
Sun Jul 05 05:46:17 UTC 2015 <mod6> gernika: it might be helpful to patch in the dump block so we can examine your block(s) 168`000 & 168`001 and see what's going on there.
Sun Jul 05 05:41:02 UTC 2015 <gernika> mod6: yeah I ran into that. Put it in my patch to stator.sh. Still need to go through the process of signing everything.
Sat Jul 04 23:58:15 UTC 2015 <assbot> Logged on 03-07-2015 19:21:32; mod6: I will work on a patch list and maybe a script later this month. It is a bit hard to follow.
Sat Jul 04 23:35:47 UTC 2015 <gernika> For any interested: using phf's patch with a few mods for amd64 I have successfully built stator on OpenBSD.
Sat Jul 04 23:18:28 UTC 2015 <mod6> phf: hey, i was able to apply your patch for OpenBSD onto stator, but I hit this problem after boost compiled: http://dpaste.com/0WRAK16.txt any thoughts?
Sat Jul 04 21:16:34 UTC 2015 <mod6> <+mircea_popescu> here's what's the idea : after botching the soft fork, it seems illogical that the entire bip system should continue at all. << Very much agreed. If someone wants to change something they should write to The Foundation's btc-dev mailing list and submit a patch. And if they can't because they're not in the WoT, well they're not in the WoT. They can make a personal appeal here in person.
Sat Jul 04 04:50:18 UTC 2015 <decimation> 'please sir, accept my resonable patch in exchange for agreeing to forever accept what 'our mechanism' brings'
Sat Jul 04 04:14:18 UTC 2015 <ben_vulpes> my position being "if your notion of a valid block has to patch 0.5.*, get fucked."
Fri Jul 03 20:26:48 UTC 2015 <ascii_field> mod6: i kinda assumed you and ben_vulpes would roll the patch sequence docs into releases
Fri Jul 03 20:26:29 UTC 2015 <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.
Fri Jul 03 19:56:06 UTC 2015 <assbot> Logged on 03-07-2015 19:44:53; phf: mod6: well, lets say you have something like mutt open with the current email. it's pretty easy to write a script that takes current email and feeds it to an external script, that splits out patch, verifies it with the provided sig, and then applies it to the codebase (or pushes it into some queue of patches as a case may be). i.e. you read the email, push "p" to do everything for you, and then move on to the n
Fri Jul 03 19:47:02 UTC 2015 <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.
Fri Jul 03 19:44:53 UTC 2015 <phf> mod6: well, lets say you have something like mutt open with the current email. it's pretty easy to write a script that takes current email and feeds it to an external script, that splits out patch, verifies it with the provided sig, and then applies it to the codebase (or pushes it into some queue of patches as a case may be). i.e. you read the email, push "p" to do everything for you, and then move on to the next email
Fri Jul 03 19:41:13 UTC 2015 <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.
Fri Jul 03 19:39:20 UTC 2015 <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"
Fri Jul 03 19:35:32 UTC 2015 <phf> mod6: i don't necessarily have problems, i have a bitcoind with all the patches up to eatblock (haven't looked at stator yet, but then i'm building with enemy tools). the way i assembled patches is by reading through web archive and saving/verifying each patch as i saw it
Fri Jul 03 19:30:19 UTC 2015 <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.