20500+ entries in 0.031s
mod6: it does remove dirs.
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: But you'll still have to create your own distfiles + ourlibs then drop in ssl/bdb/boost into distfiles. then pull down stator and build.
mod6: So this can be used as a test platform for all the patches, etc. . If you're really ambitious you can install gentoo as above ^^ then use this to pull down the v0.5.3.1 basecode and apply these patches:
http://dpaste.com/23VKWD8.txt mod6: oh and there is a new Gentoo guide for nomultilib/glibc -- I created it yesterday & trinque verified as well:
mod6: <+punkman> oic now, forgot to put ShrinkDebugFile back in after deleting in first version, sorry! << np, just resubmit and i'll give it another try. or even just pass me a version before submit if you like just to be sure it works. np.
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: <+ben_vulpes> mod6: were they using .gitignore files as .gitkeeps? << it seems that way kinda. i guess people tend to use .gitkeep (an unsupported work around instead. but w/e)
mod6: leaving the necessary directories.
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: if anyone has any ideas on this, let me know. im stumped
mod6: so that isn't gonna work.
mod6: i can't get it to remove the file and leave the dir, or to just truncate the file and leave the dir.
mod6: this problem is really goofy.
mod6: maybe i should just leave it for now.
mod6: i think that one can go away ^^
mod6: I don't see any ref's in the makefile to src/obj/test
mod6: i guess src/obj-test needs to stay because of the test stubs & it's ref'd in the makefile. that's fine.
mod6: after an actual test.
mod6: i think those can actually go away, but src/obj/nogui/ needs to stay.
mod6: does anyone see a reason to keep src/obj-test and src/obj/test ?
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: does any one have any clue why removing .gitignore files would cause this?!
mod6: And for something that's really making my head scratch..
mod6: i've got 22 tomato plants, 8 pepper plants and 4 cucumbers. tomatoes are starting to ripen...
mod6: thanks for the reminder ben_vulpes!
mod6: There is no time specific timeline for this in the public domain yet.
mod6: There will be a testing phase with a distributed full-patched bundle... call it RC1.
mod6: I still do need to sign that I've read the patches, might get to that tonight yet. Or tomorrow. We'll see how it goes.
mod6: <+ascii_modem>
http://log.bitcoin-assets.com/?date=18-07-2015#1205870 << wai wut - ?? - no one signed that he has read, tested - and straight to release? << I certainly did not mean to imply immediate release. Just that I'll build a test plan surrounding what i've indicated. Process is already underway.
☝︎ mod6: i'm gonna need another box to test on anyway.
mod6: one other thing I gotta do is update the gentoo-uclibc guide to a new guide for nomultilib glibc, should be fairly easy. then test it on my pos box.
mod6: thanks for your offer to help trinque!
mod6: or something like that perhaps
mod6: yeah, there would just be: Scenario: Create static bitcoind via buildroot, tfpt (or whatever??) to device, begin full sync
mod6: personally, i'm pretty clueless with the whole thing as of now.
mod6: yeah, i think there will be some further discussion around that. maybe dbp can help head up that side of the testing if he's willing (other than alf) he's probably got the most exp with the thing.
mod6: but people could certainly and appreciatedly take this task on for themselfs.
mod6: i don't/haven't ever setup the buildroot stuff.
mod6: i think the arm/pogo stuff is going to be have to be tested separately perhaps.
mod6: We'll be on the R.C. until we're satisfied everything is the way we want it.
mod6: cool! thanks. yeah, we're gonna need as much help as we can get testing. and as soon as we have a solid test plan developed, then we'll cut a release candidate for testing.
mod6: well, planned 22 so far.
mod6: i've got 22 scenarios worked up
mod6: im workin on that test matrix now.
mod6: gentoo nomultilib glibc: 322021
mod6: my obsd 5.6 full sync is up to block: 189480
mod6: i dunno, i guess im just used to the other way.
mod6: i want to make it clear that it seems /slightly less readable/ to me because of: @@ -45,24 +45,6 @@ Object JSONRPCError(int code, const string& message) << this type of thing.
mod6: i dunno yet. i haven't tried the new one.
mod6: normally diff will put the flags passed to it into the patch file.
mod6: diff --git a/src/bitcoinrpc.cpp b/src/bitcoinrpc.cpp
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.
mod6: and then do a `diff -uNr`
mod6: anyway, i'll have to just repatch up everything myself and re-add your changes.
mod6: <+punkman> (I did -pU, didn't change anything) << ah ok. git must have stripped that helpful information from the patch. fuck git.
mod6: @@ -45,24 +45,6 @@ Object JSONRPCError(int code, const string& message)
mod6: does stuff like this:
mod6: doesnt look like that one was generated with -pU either though.
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: that needed to happen at somepoint.
mod6: which was nice for sure
mod6: phf: keep an eye out for punkman's debug_sanity-part2 -- or maybe you both can coordinate together so that all three of these patches will play together nicely: debug_sanity-part1-corrected, debug_sanity-part2 and milli timestamps
mod6: I think it's great. If you've got an idea or something you wanna discuss for submission, this is where that type of discussion happens. Keep it up! :]
mod6: Anyway, most of the submissions so far have been pretty top notch. We want to encourage people in the WoT to submit patches. If something is submitted but doesn't make it into a release right away, that certainly doesn't mean it won't be pulled in to a later milestone.
☟︎ 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: make something work for you on your end, see if it makes sense, and if it does, perhaps submit the changes.
mod6: honestly I don't have anything in mind at all.
mod6: TomServo: it's not my recipe. i'll dig it up
mod6: same as any of the others: dump/eat block, verifiy all etc.
mod6: especially if anyone is helping test or whatever and they need debug_sanity they can just apply the patch to their local codebase.
mod6: punkman has his debug_sanity, but I hvane't had a chance to test version two, and it's not a super high priority for me at this very moment.
mod6: not a huge deal. nothing super critical there, just nice-to-have type of ones.
mod6: ascii only has 3 patches post blockdump (eatblock, rm testnet, verifyall)
mod6: Haven't had enough spare time to dig into it. Been hectic enough just trying to keep up with all the incoming patches.
mod6: <+shinohai> mod6: is your stator on a pogo? << nope