3100+ entries in 0.303s
mod6: <+punkman> mod6: ben reminded me to add a
patch that removes the 5 .gitignore files. << I dunno why
patch was needed for this, just remove them manually in next release << yeah, i mentioned that after the fact lastnight. but was discussed here:
http://log.bitcoin-assets.com/?date=19-07-2015#1206370 << this makes sense.
☝︎ punkman: mod6: ben reminded me to add a
patch that removes the 5 .gitignore files. << I dunno why
patch was needed for this, just remove them manually in next release
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.
mod6: the only thing in the obj-test directory before applying that
patch is '.gitignore' so why wouldn't it be removed like obj/test and obj/nogui?
mod6: i might just be dumb. build a test env with
http://dpaste.com/23VKWD8.txt and see if anyone can get the rm_gitignore.
patch file to apply without removing the obj/test obj/nogui or obj-test dirrs
mod6: anyway i'll work on it. just don't use the rm_gitignore
patch.
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.
mod6: yah, and when applied `
patch` ends up removing the dirs along with the .gitignore files because it renderes those directories empty.
mod6: ben reminded me to add a
patch that removes the 5 .gitignore files. seems easy enough, so crated a quick
patch, attempted to apply, worked fine -- I didn't notice that it blew away the directories as well though. : obj/test obj/nogui obj-test
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.
☟︎☟︎ mod6: check out `man 1
patch` -E
mod6: i searched lastnight for a looong time to find anything to tell
patch to no prune empty directories, but it doesnt seem like an available option.
mod6: so yeah this is annoying with `
patch`. if you do `
patch -p1 --posix < rm_gitignore.
patch` it doesn't remove the dirs /or/ the files, just leaves 'em truncated. which is dumb too.
mod6: <+ben_vulpes> AND if i'm reading this thread correctly if we blow away the DIR (!?!) compilation fails? << yeah, it's not really linus or git, it's
patch that does the dirty work. and yeah, the makefile depends on being able to write to some of the dirs.
mod6: perhaps we just don't use my submitted
patch and then I just prune the baracles by hand in the release source base.
mod6: `man 1
patch`: -E When
patch removes a file, it also attempts to remove any empty ancestor directories. << i can't get it to leave the empty dirs.
mod6: so yah, looks like the
patch blows away the obj/nogui dir along with the .gitignore file (it's the only file in the dir at the time - a clue maybe?) but if replaced, the compiles fine.
mod6: lol. own
patch rejected.
mod6: oh hmm, for some reason, i don't understand this (maybe someone can look at my
patch and tell me why??) but apparently not only were the .gitignore files removed, but the directories were too.
mod6: bascially, what I do is; extract v0.5.3.1,
patch up through -verifyall then apply the rm_gitignore
patch. then this ^^
mod6: normally diff will put the flags passed to it into the
patch file.
mod6: <+punkman> mod6, what's missing from git output? << if you used -pU, it doesn't reflect that in the
patch mod6: ben_vulpes: the old one did not, because of perhaps something the ML did to the
patch; stripping out an empty line at the end of the file.
ben_vulpes: mod6: does the
patch not apply cleanly?
ben_vulpes: so yeah a
patch to excise the wx crap is great and wonderful and thank you etc, but i'd like to see it split from changes to logging behavior
mod6: <+punkman> (I did -pU, didn't change anything) << ah ok. git must have stripped that helpful information from the
patch. fuck git.
mod6: i'm gonna throw in debug_sanity-part1-corrected to my next build/sync test, and look at the output/impact of the
patch. i should have some more meaningful comments after that.
mod6: for anything to make it into the next release, the
patch must be 100% perfect and apply perfect. if I hvae to do any mental gymnastics or gyrations to apply a
patch or whatever, it wont make it in. there's already a large enough scope on this release.
mod6: especially if anyone is helping test or whatever and they need debug_sanity they can just apply the
patch to their local codebase.
ascii_field: (i forget precisely where. oughta be a
patch!)
danielpbarron: i think much of the issue is solved with BingoBoingo's
patch that lets 0.5.3 bitcoin.conf have a line defining the minimum tx fee for relaying
BingoBoingo: Will likely get actual minrelaytxfee
patch in first
mod6: asciilifeform: point taken. glad we talked about it. and yeah, very much so read and examine every
patch.
phf: mod6: ah good to know. i'll resubmit, not sure how my
patch interacts with recent changes from punkman yet
punkman: mod6: try adding a newline at end of .
patch file
mod6: punkman: thanks for your
patch submission!
punkman: it's still a mess, will need debug_sanity_part2.
patch punkman: I see sent
patch ending with "}\n " and original with "}\n \n"
jurov: there is one empty line in the end of received .
patch jurov: if different, send me your ones and upload the
patch, say, to dpaste for me to compare
punkman: hmm I downloaded .
patch attachment and it fails indeed
jurov: it does not read the
patch at all
punkman: made this
patch with "git diff", hope it works
phf: ascii_modem: that's what kept me from continuing to work on that
patch, but i still ended up hacking the code for bulk export, since O(n^3)
phf: ben_vulpes: i started writing a
patch that would let dumpblock accept cut's number range syntax, i.e. 1,7-100,200- but didn't think anyone would need it. i can pick it up again in a day or two, though i suspect you need it now?
phf: were you guys trying to put symbol documentation into slime-autodoc results? that seems pretty easy, just
patch whatever swank:autodoc returns. though seems like it would be distracting since multiline docs will keep resizing modeline every time your point is at a new function
mod6: asciilifeform: testnet
patch looks good at first read-through. i'll apply these to my sources bases (on top of stator + patches { dump/eat block }) and continue testing. i'll also add these to my build-with-patches guide.
assbot: Logged on 09-07-2015 22:38:18; asciilifeform: ^^ i dare to suggest that the
patch be considered by therealbitcoin ^^
BingoBoingo: shinohai: I don't have a formal
patch for this, just a recipe in dpaste. Not comfortable enough to formally submit. All it is supposed to do is allow you to set the -minrelaytxfee flag in Bitcoin.conf which isn't a big deal because if you are building it you can just change the number in main.h
BingoBoingo: So stator with experimental minrelaytxfee option
patch was syncing well as a drop in replacement for previous stator on testbed then laptop became unplugged and battery dead. Restarted with -rescan because BDB hates stopping suddenly and the blockindex is screwed.
mod6: I see that nubs' gentoo sanity
patch isn't applied, wanna get some testing in there. I'm putting a guide together so someone can
patch by hand if they like.
BingoBoingo: <asciilifeform> ^^ i dare to suggest that the
patch be considered by therealbitcoin ^^ << This is a bitcoin.conf option
mod6: it was from a
patch, but not from the email you just sent in...
phf: mod6: is that with the
patch i posted to ml?
assbot: Logged on 06-07-2015 18:54:35; ben_vulpes: trivial
patch to apply for anyone who's vested.
punkman: need mega-debug-sanity
patch ben_vulpes also suspects that alf is holding this
patch in abeyance
ben_vulpes can barf up this
patch sometime this week if not beaten to punch
ben_vulpes: trivial
patch to apply for anyone who's vested.
☟︎ 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 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 ? )
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.
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.
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.
gernika: For any interested: using phf's
patch with a few mods for amd64 I have successfully built stator on OpenBSD.
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.
decimation: 'please sir, accept my resonable
patch in exchange for agreeing to forever accept what 'our mechanism' brings'
ben_vulpes: my position being "if your notion of a valid block has to
patch 0.5.*, get fucked."