2700+ entries in 0.24s
punkman:
patch that wasn't in release will have to be rebased to be in next release
mod6: Thanks again for posting your report & corresponding
patch. Great work.
trinque: could make him eat a genesis v-
patch of himself
assbot: Logged on 28-12-2015 00:39:31; asciilifeform: in the sense that presently
patch Q is said to have
patch P as an antecedent if ~any file~ in Q was modified by P
ben_vulpes: a
patch may have multiple antecedents, correct?
ben_vulpes: 1) only press the head
patch in question (this is how i wrote my press)
punkman: ben_vulpes: if you want to press a minimal version of a
patch, you can recursively find all antecedents of a HEAD
patch ben_vulpes: rebooting an old thread
http://log.bitcoin-assets.com/?date=14-11-2015#1323387: asciilifeform: since a
patch has multiple antecedents, would an accurate description of the correct
patch-selection algo for press be something along the lines of "given a
patch, find its antecedents. presssed version must contain the descendants of all of those antecedents."?
☝︎ mod6: different
patch though
mod6: it was this
patch that overcame that issue: bitcoin-v0_5_3-db_config.6.vpatch
mod6: And this statement is not accurate: ``With the “rm_checkpoints”
patch, the wedge issue at Block 252450 was overcome.''
mod6: read this section: [ Tabling of Checkpoints
Patch ]:
punkman: asciilifeform: but original was 'debug sanity' and did 2 very distinct, separable things, in 1
patch, which imho is mistake << agreed, but most of the wx crap was related to debug
assbot: Logged on 24-12-2015 20:19:11; asciilifeform: punkman: i like this
patch except imho 1) patches ought to do One Thing 2) printf hardcoded to stdout is Wrong Thing
mod6: ok cool. my latest
patch should do just that.
mod6: all: btw, if you do use the above test
patch for V, please remember you may need to run a dos2unix on the dpaste [dpaste.com/12M99KB.txt]
mod6: If you add the above
patch, you should end up with:
mircea_popescu: when one executes v-magic upon the genesis
patch one must end up with a ready-to-go bitcoin.
BingoBoingo: pete_dushenski: As penance you should fire up a trb node to test the new version string
patch ben_vulpes: it's vastly more likely that someone's going to need to crap out a
patch for eg openssl than replace it wholesale.
mod6: Scenario: Guy creates vpatch that utilizes irc.h (removed in vpatch asciilifeform_ver_no_5_4_and_irc_is_gone_and_now_must_give_ip.vpatch) must ensure that Guy's
patch is on it's own tree?
mod6: <+asciilifeform> it would end up as an altogether other tree in the graph << so said
patch to add documentation dir would be its own root?
mod6: oh, i see, so like if a
patch further down the line (in time) remove a file that a specific sub tree relies upon, that those become removed?
mod6: if we wait until the end, we'll save some cycles -- and mathematically the hashes wouldn't come out right if somehow the files were diddled inbetween. but I can see some merit in checking after each
patch is pressed.
BingoBoingo: ben_vulpes: LibreSSL node also runs with ~1GB of ram utilized at startup after last BDB locks
patch because OpenBSD malloc something or other
shinohai: Also asciilifeform ty for Programmable Version Strings
patch pete_dushenski: youth, to the extent that they have no
patch of anything to call their own, are inclined to jump aboard any train promising any sort of future
pete_dushenski: as well as "boomers" very strong desire to maintain, if not grow, the little
patch of earth they've thus far claimed for themselves
ben_vulpes: "no listen, we're super inclusive. get yourself a gpg key, get in the wot, read the logs, submit a
patch, and we'll talk about it."
mod6: Not a lot really remains left for v054. I'm in the process of getting all of the 3rd party deps, listed and then will sign and find a place for them on the website. Then I need to update my build script so it pulls and verifies all of that stuff from our own host. Beyond that, I just need to publish the v054-RELEASE
patch I've been sitting on. Then Mr. Vulpes & I will need to sign all the vpatches and post 'em to the mailing list.
ascii_field: i had the motherfucking 'play with barbarians'
patch jurov: the
patch adds -l dl to LIBS
mod6: if you get that igprof
patch working jurov, let me know.
jurov: the jettison
patch had it the other way
ascii_field: jurov, phf: i recommend getting that
patch of mine which lets you request EXACT bytes of heap used total at ANY TIME
phf: jurov: the goal is to get bitcoind working with pogo's limited memory. the problem is that a running bitcoind grows in memory use as a result of normal operations. we know that some processes claim a lot of memory by design, like mempool, so first step is to get a reliable way of cleaning out mempool. ascii wrote that
patch, but discovered that in practice zapmempool doesn't reduce memory use.
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)
phf: jurov: the overal goal though is to flush the mempool, but simply measuring the memory between zapmempool shows that the
patch specifically doesn't do it. there's either additional source of leak, or there's a leak in mempool, or, and that's the most likely case, the
patch in question doesn't touch al lthe places where mempool has data
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)
phf: i think maybe it's worthwhile to
patch the logger so it doesn't report until the client actually does a read/write. if you do a port scan on yourself, will have same effect
mod6: <+shinohai> mod6: have you had any sucess with bsd yet ? << yeah, OpenBSD, achieved a full sync a few months back. had to
patch it by hand.
jurov: no
patch needed since 0.8
jurov: ascii_field: electrum-server depends on bitcoin having "txindex" which 0.5.4 not sure if has, 0.7 had and the el.
patch was not heavy
phf: luckily for you today only you can get a new and improved
PATCH from me that will at least let you create context, since i only finished it like last night, i don't yet know if it will actually encrypt, but it might
trinque: you recommend a separate proggy rather than
patch to bitcoind?
ascii_field: davout: this kind of braindamage has been around for some years, yes. but until now i did not know that it has reached the point where you have to
patch ~the printer itself~ rather than merely the eeprom in the cartridge.
assbot: Logged on 28-10-2015 16:56:05; ascii_field: funkenstein_: i recommend dpasting your
patch for review before signing formally
ascii_field: funkenstein_: i recommend dpasting your
patch for review before signing formally
☟︎ mod6: vdiff.sh a b > your_patch_name.vpatch
assbot: Logged on 28-10-2015 16:30:06; funkenstein_: so after a number of tests I was going to submit the fix on this
patch, but after using V more often it has become clear that it is annoying to have patches made from different places in the directory
funkenstein_: of course V still can be used in either case to apply any
patch you like made from anywhere, just a minor annoyance
funkenstein_: so after a number of tests I was going to submit the fix on this
patch, but after using V more often it has become clear that it is annoying to have patches made from different places in the directory
☟︎ funkenstein_: in this instance, i assume a properly measured replacement of the thing is preferred to an additional
patch to fix
funkenstein_: so if anybody wants a signed antipatch for my broken
patch, let me know. otherwise, I assume the thing can be simply dropped.
mod6: yeah. that
patch won't be added into the mirror. now if someone wants to try out his
patch locally, they'll have to pull his vpatch, and add his key to the wot manually and then see what happens if they want to press out a branch that includes that vpatch.
ascii_field: (i write a
patch, sign it, throw in the hopper, everyone who has my name ticked - sees a tree with that
patch applied. but OLD LINKS MUST CONTINUE TO WORK)
ascii_field: jurov: thing is, every time a new
patch comes to exist, this is a new version.
mod6: so with V, you can use a command called "press" that will
patch up through a given HEAD.
ascii_field: (or they will turn into nonsense with every new
patch)
ascii_field: all of this is because i wanted to show funkenstein why his
patch is catastrophically mistaken