2900+ entries in 0.325s
mod6: just ran the `
patch -p1 < genesis.vpatch` in an empty dir, and then volla, bitcoin source exists
trinque: danielpbarron: that appears to be in need of my
patch ben_vulpes: i've taken to using the -d flag with
patch *always*
mod6: i'll compare my raw
patch above with MP's posted one above side-by-side here when i get a chance.
assbot: Logged on 19-08-2015 15:40:35; phf: thestringpuller: you should try patching that
patch, by adding
http://www.cplusplus.com/reference/map/map/begin/, for(...) { delete iter->second; } for mapTransactions and mapNextTx in the JettisonMempool function. seems like an easy fix, i don't have my env setup at the moment
phf: thestringpuller: you should try patching that
patch, by adding
http://www.cplusplus.com/reference/map/map/begin/, for(...) { delete iter->second; } for mapTransactions and mapNextTx in the JettisonMempool function. seems like an easy fix, i don't have my env setup at the moment
☟︎ mod6: did you add that
patch to your currently running node on aws?
mod6: <+thestringpuller> the intent is to jettison the entire pool? (hopefully I'm reading the
patch correctly). mod6 informed me of the boost datastructure idiocy << wait, wat?!
assbot: Logged on 19-08-2015 14:32:04; asciilifeform: thestringpuller: this
patch does not work as described, on account of boost idiocy (removal of items from the hash does not invoke their destructures! believe)
thestringpuller: the intent is to jettison the entire pool? (hopefully I'm reading the
patch correctly). mod6 informed me of the boost datastructure idiocy
BingoBoingo: <asciilifeform> this, too, is fit subject for a
patch; << I imagine orphanage stomping patches will be joined with "Fuck off out of my kitchen" set
assbot: Logged on 19-08-2015 00:41:43; asciilifeform: ;;later tell BingoBoingo if you write a
patch for the verson string thing, i'll read it!
pete_dushenski: hanbot: your stator build didn't get wedged even though you didn't add the asciilifeform_maxint_locks_corrected.
patch ?
assbot: Logged on 16-08-2015 00:54:40; hanbot:
http://log.bitcoin-assets.com//?date=11-08-2015#1235149 << for the record i bungled this, built a (seemingly working nevertheless) frankenstein
patch-quilt (dnsseed_snipsnip, thermonyukyoolar_kleansing, kills-integer-retardation, ver_now_5_4_endless_name_string, zap_hardcoded_seeds, showmyip_crud, if anyone's interested).
hanbot:
http://log.bitcoin-assets.com//?date=11-08-2015#1235149 << for the record i bungled this, built a (seemingly working nevertheless) frankenstein
patch-quilt (dnsseed_snipsnip, thermonyukyoolar_kleansing, kills-integer-retardation, ver_now_5_4_endless_name_string, zap_hardcoded_seeds, showmyip_crud, if anyone's interested).
☝︎☟︎ mod6: orchestra/rel2-pre.
patch v. orchestra/test-v054-patches/rel2-pre-test.
patch mod6: orchestra/rel1.
patch v. orchestra/test-v0531-patches/rel1-test.
patch mod6: So I've basically been able to reproduce both of your rel1.
patch & rel2-pre.
patch -- and I went through your
patch with my script's created
patch side by side by hand and verified the sha512s
mod6: asciilifeform: I have successfully reproduced the rel1.
patch on my own now with the same matching antecedent/new hashes. I have script that reproduces this all the way up through v0.5.3.1 -- will continue on and do the same for up through v0.5.4 before let everyone see. But, so far, so good.
jurov:
patch | tail -n +1 | sha512sum
assbot: Logged on 15-08-2015 16:54:38; mod6: asciilifeform: Are you planning on posting each
patch (that we've since included in rel1, rel2) in a separate email to the list with a detached sig and included sha512?
mod6: asciilifeform: ok cool! rel1.
patch and rel2-pre.
patch do apply cleanly to all of the existing patches
mod6: asciilifeform: Are you planning on posting each
patch (that we've since included in rel1, rel2) in a separate email to the list with a detached sig and included sha512?
☟︎ gernika: mod6 I applied asciilifeform_maxint_locks_corrected.
patch mod6: do you have the maxint_locks_corrected
patch applied?
gernika: FYI OpenBSD w/o db
patch wedged at 367850
n6: "
patch: **** strip count l is not a number" *
n6: i'm getting "
patch -pl < buildroot-asciilifeform-pogov4_0567b86c55934a8b5d1351b4ccba9306ee3406c3.
patch" when running
patch -p1 < buildroot-asciilifeform-pogov4.
patch n6: I don't see buildroot-asciilifeform-pogov4.
patch in the list of files.
mod6: Meanwhile, I can offer you a script that I use to
patch up through maxint_locks_corrected from v0.5.3.1 -- it's not a guide, but if you read the steps, it's what needs to happen and in what order. The new (forthcoming) guide will be based on these steps:
http://dpaste.com/0YVSD6Q.txt phf: gernika, ben_vulpes: new
patch, 7129357156859d81c987e210d26ba552fdc49350
ben_vulpes: anyways, hit me up when you push your
patch phf: ben_vulpes: one sec, i almost pushed another
patch hanbot: still want to build stator, "manually": 0.5.3.1 release + six-
patch battery required to achieve stator. verified release will run on my (32bit) ubuntu box w/ mod6. so now, patching (for which i was following said guide, all six patches sha1sum & sig verified)
hanbot: the ml patching guide (
http://therealbitcoin.org/ml/btc-dev/2015-March/000067.html) step 0x07] Clean Source Base involves manifests which i take it are part of the guide's referenced
patch tarballs. given the stator
patch battery is single .
patch file only, how's one to handle this step (and why does guide assume
patch will come in ball?)?
ben_vulpes: asciilifeform: and what happened with that db locks
patch of yours
mod6: trinque: sig verifies &
patch applies cleanly. thx again.
mod6: yah, I left him a note to re-send a
patch with a detached sig to the ML. can help or do it for him if required, etc.
mod6: once we have that, and a new
patch from trinque, i can complete my script and have a rotor that builds these test bundles with x86-64
mod6: <+hanbot> re ml: where are sha256sums for, eg,
http://therealbitcoin.org/ml/btc-dev/2015-February/000040.html (
patch)? << Hi, in the case of that
patch email, the SHA1 sum is embedded in the file name. For example: asciilifeform_dnsseed_snipsnip_192f7bc7c14c1d31c7b417c9cd77be51c4d255f2.
patch -- if you were to download this
patch, you could then run `sha1sum asciilifeform_dnsseed_snipsnip_192f7bc7c14c1d31c7b417c9cd77be51c4d255f2.
patch` and it sh
mod6: trinque: would you be opposed to resubmitting your
patch for the rotor to the ML as a attachment with a detached sig? I have a list of concise steps that is basically a simple script to do all of the steps to build rotor/static-deterministic-stator just need to get that piece into place. that's the only manual step at this point.
ascii_field: the '
patch' on my systems eats these happily, disregarding the extra bit
phf_mobile: i have a mac os x
patch, but as i recall that's the only change required, and since i don't understand the implications, i didn't post it. it works when building with clang, but needs investigation why duplicate function to begin with
BingoBoingo: n6: Practice on different *nic first. Install OpenBSD upgrade to stable. May have to
patch bitcoind, but learn building from source in very documented way.
ascii_field: this recipe produces a diff usable by '
patch' ~containing antecents~ and ~postcondition~ !!!
davout: ascii_field: if you could have a separate pgptron for checking sigs, and the ability to manually insert a signed
patch into it?
trinque: I actually grow to like the wiki suggestion best for the
patch tree
trinque: you've got "who signed this
patch" and also "what is the parent node
patch of this
patch"
assbot: Logged on 06-08-2015 01:59:06; *: BingoBoingo thinks whole problem is that '
patch' demands line numbers instead of using nearby lines of code as landmarks
punkman: not that I'd mind
patch deeds, but can basically deed
patch hashes already
mod6: that way it sort of also solves the problem of keeping track of who signed which
patch. since deedbot stores these sigs in a horizontal fashion next to the address.
BingoBoingo thinks whole problem is that '
patch' demands line numbers instead of using nearby lines of code as landmarks
☟︎ mod6: oh, i think he was saying that he would need to implement accepting a second argument and making it so that the URL contains a hash of the original plaintext
patch.
mod6: but what if we then, say, at the end of a testing/release cycle were to (instead of signing or as well as posting to the mailing list) post the plaintext
patch and a detach signature from the originating author, myself & ben to deedbot as a perm storage for these patches?
mod6: well and probably error prone if he/she has to cut the upper text out just to get down to "bare"
patch to re-clearsign and submit to deedbot... could miss line, something bad.
ascii_field: throw message prior to the first 'diff ....' in the ,
patch mod6: ok so another question i have about the deedbot way.. would be: if we submit a
patch to deedbot, how do we tie a message to that same submission? say we wanna be like "Hey, this thing is neat!" Will it need to reference anothe deedbot submission or does the
patch have to come after our statment in the clearsigned message?
mod6: <+jurov> mod6 decrypt on *clearsigned* file << this indeed works. created file A.txt. copied A.txt to B.txt and subtracted some lines. created a unified diff of both. clearsigned the diff -- which is mutilated for escaped hyphens. upon `gpg --decrypt` of the clearsigned output
patch file, i get the same hash as the pre-clearsigned hash file.
mircea_popescu: pruning the tree of all ulteriors that depend on an unclicked
patch mircea_popescu: trinque and with a bonus "click here for this
patch" and "click here for this
patch + all its antecedents" spew.
mod6: i guess for me thats the one big thing, we can't have any mutilation of the
patch files. or we'll just find ourselves banging our heads all the time.
jurov: well, if gpg can't undo it and it causes the
patch to fail...then it fails.
assbot: Logged on 05-08-2015 18:55:16; mod6: now, it might be that I'm not exactly understanding what the proceedure for submitting to deed bot would be. but if clearsigned .
patch files, that can not work.
assbot: Logged on 05-08-2015 18:55:16; mod6: now, it might be that I'm not exactly understanding what the proceedure for submitting to deed bot would be. but if clearsigned .
patch files, that can not work.
jurov: but it's universally usable to (1) determine what version
patch applies to (2) allows to remove files without listing whole contents