log☇︎
3000+ entries in 0.226s
ascii_field: that requires either modified 'patch' util, or wrapped in perl etc
mod6: it does now, or it will because we must now reinvent diff/patch ?
jurov: no, must roll ou our won diff/patch
mod6: ok and that sha512 hash is of the file /before/ the changes were made resulting in the patch?
jurov: mod6 you have seen alf's patch with embedded sha512 example?
ascii_field: while preserving the simultaneously total and minimal representation of .patch
jurov: and metadata what the patch applies on
jurov: turdatron needs to take bundles of patch + manifest (at least, can be any other files aside from patches)
mod6: and /patch.html imho should not draw off of just any submission, only signed submissions from ben, myself and the author.
mod6: how does anything get into /patch.html ?
ben_vulpes: mod6: not that my browser will do anything with the patch files but download them.
danielpbarron: what about this: gzip the patch and clearsign that
mod6: i've been thinking alot about the ML issues that have been brought up lately. and lastnight I bascially came up with: Mailing list A: for all submissions testing or experimental or otherwise.. Mailing list B: for accepted, signed and released patches, in order. And jurov's /patch.html (or w/e its called) should draw from there.
mod6: will deedbot take 2 parameters, a non-signed .patch file and a detached signature and somehow colese them?
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. ☟︎☟︎
ben_vulpes: what was the rollover patch called?
punkman: a question that future patch submitters might have: should I patch against last release or most active branch?
punkman: but I'm guessing as to patch order, branches, etc
jurov: (currently on has to clearsign the .txt, make detached armored sig for .patch and use non-braindamaged email client to put them together)
jurov: how would it look for user? got a .txt, a .patch , now what?
asciilifeform marvelling that no one, apparently, ever noticed the glaring omission in 'patch'
asciilifeform: incidentally it is not necessary to alter the unix patch util. the checksums can be added by a proggy which eats standard patch file and the 'before' tree, and shits - this
asciilifeform: but now both sides of the patch (author and applier) will need the custom util.
asciilifeform: jurov: it was not a thing before, because there was no way to guarantee that the contents are what the patch author thought they were
asciilifeform: i will add, if it isn't obvious, that patches like the one i suggested will apply on a standard unix patch util
jurov: i like it. to be able to remove files without dumping whole contents, patch should be patched, too
asciilifeform: hence the 'never, ever include a patch in message text' thing.
mircea_popescu likes, perhaps irrationally, the patch format
jurov: though, with this in-band signalling we will limit ourselves to patch format
mircea_popescu: asciilifeform actually a hashed diff / patch-util is a must irrerspective of anything else.
asciilifeform: thinking of a modified unix-patch util that stuffs sha512 into comment preceding each file diff
asciilifeform: mircea_popescu: i once thought about placing antecedent hashes in patch headers ☟︎
punkman: with some metadata in diff files, we could have a script that creates a branched git repo entirely out of signed patch files
decimation: thus, you need the whole repo state per patch
decimation: which you can't get unless you have the whole repo stepped forward to the state of ap articular patch
decimation: asciilifeform: for one thing, you would need to see the patch in context
decimation: for each patch
trinque: dev is its own concern which might have other processes; you could say that a particular feature branch eventually gets flattened down into a release patch
decimation: it would be nice to have a button to click: download the 'original tree' plus patches to get to this patch
asciilifeform: see the text of the patch.
decimation: asciilifeform: are the maps in question contained in your 'mempool zap patch'?
asciilifeform: ;;later tell ben_vulpes i have nothing against 'git', 'mercurial', etc., and even sometimes use these in civilian life, there is even somewhere ~horror~ a 'github' page with my name and some old crud, yes. but the ~canonical walk from pedigreed 0.5.3 to therealbitcoin~ has to be in .patch form!
asciilifeform: btw the db patch is not marked with antecedents because it has none (since last release)
trinque: the patch signing is great, but it's not a process by itself
ben_vulpes: if you're up to date on the patching, submit a patch and note its antecedents.
ben_vulpes: not even a note in correction about "lol sry first patch doesn't work"
ben_vulpes: so ofc i /try/ first patch
ben_vulpes: second patch contained a link to mp's "dis wat i do, yo"
asciilifeform: just 'here's a patch, i'd better eat it'
asciilifeform: srsly, ben_vulpes managed to install the uncorrected patch in the minutes between it and the new one ??
asciilifeform: ben_vulpes: go get the first (not 'CORRECTED') version of the patch
ben_vulpes: asciilifeform: did you find a reason why maxint wouldn't work, or is the second patch just using mircea_popescu's lock values for 'myzteeri0us reezuns'?
ben_vulpes: however the build i made on 7-15 with the dumpblock patch boots from the same datadir.
asciilifeform: ben_vulpes: ~which~ patch did you apply ?
asciilifeform: got 3 (well, 3 public, 1 test platform) nodez running, with patch
ben_vulpes: has anyone else compiled the maxint patch and received db.log errors of "unable to join environment"? ☟︎
mod6: i.e. I dont have to rebuild the buildroot & "universe" every time I want to add a patch, just rebuild 'stator'.
gernika: mod6 asciilifeform fyi I just successfully built stator bitcoind on top of rotor. Gentoo inside Parallels. Needed trinque's patch.
mod6: Thanks all for working lastnight to get the db locks issue resolved! I've got a new bitcoin-v0_5_4-TEST2 bundle created. Patch added was `asciilifeform_maxint_locks_corrected.patch'. Applies cleanly. All automated tests passed.
assbot: New Per Block Transaction Highs Wedge Some Nodes: Patch Available | Qntra ... ( http://bit.ly/1IBUueb )
asciilifeform: BingoBoingo: http://qntra.net/2015/08/new-per-block-transaction-highs-wedge-some-nodes-patch-available/#comment-36511
assbot: New Per Block Transaction Highs Wedge Some Nodes: Patch Available | Qntra ... ( http://bit.ly/1IBTiHF )
BingoBoingo: Herpity Derp Derp http://qntra.net/2015/08/new-per-block-transaction-highs-wedge-some-nodes-patch-available/#comment-36507
scoopbot_revived: New Per Block Transaction Highs Wedge Some Nodes: Patch Available http://qntra.net/2015/08/new-per-block-transaction-highs-wedge-some-nodes-patch-available/
asciilifeform: do not use this patch!
BingoBoingo: asciilifeform: I think we just copied that number from some patch Luke-Jr pointed us to
mod6: yeah. the patch itself is mundged when sent like that because gnupg tries to escape hyphens; which is why "- ---" and "- -../dist/configure ..." happens.
asciilifeform: looks like trinque forgot to link his patch here? >>>> http://therealbitcoin.org/ml/btc-dev/2015-July/000136.html <<<<
jurov: http://log.bitcoin-assets.com/?date=31-07-2015#1218903 as patch processing is part of scrubbing, easiest would be to just turn everything off and keep just ordinary mailing list ☝︎
asciilifeform: trinque: post patch plz
asciilifeform: ;;later tell trinque please consider submitting patch to the ml !
assbot: Eulora client Freenode patch on Trilema - A blog by Mircea Popescu. ... ( http://bit.ly/1KzhUDk )
jurov: http://trilema.com/2015/eulora-client-freenode-patch/ < dis
mod6: isn't rotor just 'old-stator' (from a few months ago) + buildroot & openssl patch?
asciilifeform: hanbot: the stator in question is precisely the customary stator (with the patches of your choice) but for the patch in 14-1 and the script 14-2 and 14-3 in place of the usual stator.sh and stator_bitcoin_only...
asciilifeform: hanbot: you will have a dir, outermost, named what you like - e.g., 'rotor', and then rotor/toolchain and rotor/buildroot-xxx and rotor/stator, inside the latter - quite the same thing as in normal stator, other than the musl patch and the rotor.sh script (replacing the old stator.sh)
shinohai: and holy shit I got the patch to apply
shinohai: Asks me for file to patch, then says file not found, lemme try again
ascii_field: and did the patch apply ?
ascii_field: by the patch
asciilifeform: phun phakt. ubiquitous series of ethernet cards by 'realtek' take (optional) microcode updates. (they are volatile, live in a kind of 'patch ram' until next reset.) they do not appear to match any known cpu arch (i tried a dozen or so.)
mod6: i still need to update the old how-to-patch guide etc. im actually pretty much complete on that... as soon as we give the green light on the test bundle i'll post my changes for that too.
mod6: section 0x9? are you talking about the how-to-patch guide? it's a separate thing.
mod6: I made brief mention of dignork's patch in the SoBA from December: http://thebitcoin.founation/ml/btc-dev/2014-December/000017.html
mod6: this patch was submitted: http://thebitcoin.foundation/ml/btc-dev/2014-October/000004.html but it is /already/ applied in v0.5.3 base, we never applied this patch. Here's the spot: http://btc.yt/lxr/satoshi/source/src/main.cpp#0665
mod6: <+asciilifeform> mod6: patch the result of my patch << will do!
BingoBoingo: <asciilifeform> mod6: patch the result of my patch << So if I figure out "diff" should I submit mintxrelayfee flag against 0.5.3.1, stator, or specify all preceeding patches.
asciilifeform: mod6: patch the result of my patch
mod6: <+asciilifeform> mod6: i'd prefer if you patched my patch << huh, ok. i kinda figured it'd be less messy the other way around. but... sure.
asciilifeform: mod6: i'd prefer if you patched my patch
mod6: i have a replacement patch ready to go if you're alright with that change.
mod6: What you want to do is to start with v0.5.3.1 and go through his messages that he linked and patch 'em in one at a time after verifying the hashes and the sigs.
hanbot: (not every single patch on the mailing list, just the 8 needed for stator)
mod6: that was poorly worded. i wouldn't bother trying to go through that list of emails unless what you want to do is this: download & extract v0.5.3.1-RELEASE and go through every email, one by one, and patch by hand.
hanbot: okay got the planned patch spaghetti untangled, ty asciilifeform. mod6 volunteered to let me torture him tomorrow with release issues. i'll report on how all this goes.
asciilifeform: you might also want the 'verifyall' patch, http://therealbitcoin.org/ml/btc-dev/2015-July/000120.html
hanbot: asciilifeform i sketched the patch tree like so:
asciilifeform: the sequence in http://therealbitcoin.org/ml/btc-dev/2015-June/000101.html followed by the patch in http://therealbitcoin.org/ml/btc-dev/2015-April/000080.html
mod6: <+mod6> so... yah, a bash script or removal by hand. would be fine i'd think. but now i gotta test it a bit harder. if we leave empty directories in there, im worred that patch might come along at a later time and be helpful again, removing those object output diretories. << so if i do remove them by hand, have to ensure that these empty dirs wont get nuked later on accident
assbot: Logged on 19-07-2015 18:34:53; mod6: but now I'm scared that even if i /do/ remove them by hand, they might get accidentially pruned by a downstream patch (later in time) causing the makefile to puke.