log☇︎
3500+ entries in 0.526s
ascii_field: at any rate, my patch no longer fixes the build on my boxes.
ascii_field: this is -after- i apply my http://therealbitcoin.org/ml/btc-dev/attachments/20150128/asciilifeform-porta-tronic_67d6162e1cc78b3a6aca584e2123e59fdee189f6.patch << the second half, you folks did merge the first
ascii_field: not even my old patch fixes it any more.
asciilifeform: unrelated, someone needs to take ben_vulpes's rm_rf_upnp patch and turn that into a separate executable that does upnp.
BingoBoingo: platform specific patch sets may end up being a necessary evil, even if there isn't a full split
BingoBoingo: pete_dushenski: Article up, patch applied to other article
nubbins`: asciilifeform re: uint32_t : 0.5.3.1-RELEASE doesn't include portatronic patch from http://therealbitcoin.org/ml/btc-dev/2015-January/000033.html
jurov: patch list page shows bogus data, it's my TODO
jurov: of patch contents
nubbins`: asciilifeform are those md5 checksums on the end of your patch names or what?
mod6: It requires a subtle patch to the code.
nubbins`: can't test patch just yet but new turdel_latest boots a-ok here
asciilifeform off to meatspace for a spell. wants to hear if anyone tests v2 patch.
nubbins`: ^ a monotribe taking advantage of several interesting patch points
asciilifeform: ^ what comes out after v2 patch.
asciilifeform: decimation: are you sure you are building with the patch ?
asciilifeform: you can do this with the file system overlay (see patch and readme) or using buildroot's spiffy user generator (can't help here, never tried)
trinque: asciilifeform: patch makes sense, and lol @ skull and crossbones around the telnet in inittab
asciilifeform: ('nope' as in, i did not patch anything remotely close to there)
asciilifeform: trinque: and now that you baked, read the patch. it will begin to make sense.
nubbins`: there's the patch, you tell me 8)
nubbins`: http://therealbitcoin.org/ml/btc-dev/attachments/20141112/bitcoin-asciilifeform_ea4c4745bc4b10fc19bf0a2be7d0797dfd948a33.2-https_snipsnip.patch
nubbins`: in a perfect world, remove_wallet.patch
punkman: maybe add my mining-snip patch too
mod6: nubbins`: np. i think it's just good to get it in the list for now. later we can take it, massage whatever is needed and get it into a proper patch and test it.
nubbins`: mod6 plz to emphasize that osx patch does not come with official nintendo seal of quality
danielpbarron: i thought it might have been because i was still using my own script to patch 0.5.3, but the pre-patched 0.5.3.1 i tried also failed (that was the omitted 6th attempt
ben_vulpes: <mircea_popescu> seems that's 64 bit only now o.O << ahaha in between this line and my logreading mod6 posted a patch
nubbins`: actually, looking at the pogoplug-related entries in that patch, it's all trivial stuff
nubbins`: so you didn't need anything from that patch file?
assbot: linux-3.18.5-kirkwood-tld-1.patch - Pastebin.com ... ( http://bit.ly/1C9mhOu )
asciilifeform: nubbins`: he has a patch.
mod6: it seems a bit silly to post a patch also back to the original portatronic version for this. anyone have any objections if i just publish a full copy of the 32bit auto.sh and a patch of auto.sh to the previous version (v0.0.5 included in the -RELEASE) ?
ascii_field: mircea_popescu: adding a problem++ to the list at the cost of a weekend is not on this list << astute observation, which is why my patch was specifically labeled as a proof to nail down the locus of the problem, and not an item to be used on the battlefield.
ascii_field: mod6, mircea_popescu: depending on what it means to fix the leak (total replacement for block sync mechanism and a mathematical proof for it? or something more like my patch ?) it could take anywhere from a weekend to maxint days
mircea_popescu: ascii_field you familiar with how long current foundation patch took ?
ascii_field: anyone who wants an illustration of roughly what has to be done, is invited to read my skull&crossbones patch
nubbins`: i.e. 0.5.3.2 should patch just the same
ascii_field: incidentally (i wrote) a neat little proof of concept bin patch for bitcoind on winblows.
ascii_field remembers about his unfinished 'hardwired peers' patch for 0.5.3
Adlai: that can be distributed as a separate patch, with sample files to verify that it does what is said
mod6: well, we'd have to spend some time just making sure we have the correct configure/compile flags set for openssl/bdb/boost and then create a patch or derivative of auto.sh for ppc-mac
midnightmagic: Linux on PPC builds and syncs to head based on the bigendian patch. I have not verified it against a current git yet.
ben_vulpes: (perhaps a link to the email list page for the email in which a given patch/signature was transmitted would be even better)
assbot: Logged on 17-03-2015 05:07:10; ben_vulpes: ;;later tell jurov http://therealbitcoin.org/ml/btc-dev/2015-January/000034.html << why not a patch file for this? just to make me diff it myself?
mod6: the release tarball will end up being linked up there. and the containing RELEASE_NOTES.txt file will point to the patch/script tarballs up there just so they're availble individually somewhere.
ben_vulpes: ;;later tell jurov http://therealbitcoin.org/ml/btc-dev/2015-January/000034.html << why not a patch file for this? just to make me diff it myself? ☟︎
mod6: ben_vulpes: ok good deal! i'm about to post the lastest version of the perl build script too -- which should pull v0.0.2 of the static-makefile patch.
mod6: had 2 attachments, a .patch file and a .sig file
mod6: jurov: can you see if a message got snarffed from the btc-dev list, i sent one in with the subject "Static Makefile Patch v0.0.2"
mod6: decimation: i think, in interest of time.. perhaps (with your help/testing) we'll post a patch for the makefile & the auto.sh post release.
mod6: so i'll re-submit that makefile patch and what will be v0.0.5 of the mod'd pogo script (with 'no-dso')
asciilifeform: it doesn't, if the https-snipper patch was merged.
mod6: asciilifeform: because how we'll roll out the release: 1) I'll patch the source myself and put it in a 'bitcoin' directory 2) i'll place the 'auto.sh' in the same parent directory as 'bitcoin' directory 3) tar those up 4) end user will unpack archive and execute `auto.sh'
mod6: everyone will start with an already patched codebase, unless they want to patch it manually or wrestle with one of the 2 scripts we have for this purpose
mod6: i'll use it to patch the source code, then i'll bundle up the release.
mod6: oh we're all discussing them pulling down the patch files, verifing the patch sigs and patching the base code
decimation: ~/bitcoin-v009/build/chicken/bitcoin-asciilifeform.1.patch.sig
decimation: Verifing patch signatures..
mod6: hmm, still, should be ok. i just re-ran on my side and got: >> Signature verified for bitcoin-asciilifeform.1.patch.sig
asciilifeform: on account of being a software patch away from full auto
ascii_field: but did you really expect microshit to patch without opening a new orifice? because that'd be a first.
scoopbot: New post on Qntra.net by Bingo Boingo: http://qntra.net/2015/03/windows-stuxnet-patch-left-vulnerability-open/
asciilifeform: ben_vulpes: short summary: patch submitted by google chrome devs themselves; supposedly to simplify their sandbox 'jail' mechanism ☟︎
assbot: Linux-Kernel Archive: [PATCH v6 7/9] seccomp: implement SECCOMP_FILTER_FLAG_TSYNC ... ( http://bit.ly/18sRul2 )
nubbins`: each patch is intended to be small enough that a human can read and understand it
mod6: jurov: so as far as shorter release cycles, i think going forward they will be. the foundation will focus on say, one specific problem and then tackle it, patch it, and then regression test, release.
mod6: to make it build statically, there is another patch that I still need to submit yet (probably today) and another patch & full source to submit of a modified poratronic build script.
jurov: because it does include the version bump patch
thestringpuller: but that relates to the OpenBSD patch
assbot: PKGBUILDs/archlinuxarm.patch at master · archlinuxarm/PKGBUILDs · GitHub ... ( http://bit.ly/1ADHuiZ )
ascii_field: https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-kirkwood/archlinuxarm.patch#L8563 << possibly this
assbot: PKGBUILDs/archlinuxarm.patch at master · archlinuxarm/PKGBUILDs · GitHub ... ( http://bit.ly/1FQr0Zg )
plonky: https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-kirkwood/archlinuxarm.patch
plonky: with all the patch included to kernel compilation in archlinux
mod6: last note: this is all predicated on the fact that one would have run the v0.0.8 perl script to patch the R.I. So you might need to alter line 62 to point to the correct bitcoin build directory.
mod6: the static build script seems to exit after line 53 for some reason, haven't had time to debug. if one should figure out a workaround/fix/patch for that, that'd be much appreciated. otherwise I can fix myself when I'm back.
asciilifeform: will post patch set once i can be bothered to crap one out
asciilifeform: danielpbarron: i will post a patch to the netbsd src tree
Adlai: they can backdoor the drive without the ceo having to patch usg through to the cto
assbot: siginfo_t_fix.patch - Pastebin.com ... ( http://bit.ly/1zYkzzC )
asciilifeform: ever time you sit down and submit a patch to something-or-other, knowing that it might silently break proggys used by actual people,
asciilifeform: you can't really pull out 'boost' and retain the naked-eye-plus-patch-util sense of 'this is visibly bitcoind pre-$10-per but with minor changes' thing
thestringpuller: you told me not to patch in orphanage burner yet.
asciilifeform: thestringpuller: the idiot crashy one ('classic', with memleak) or the one with questionable patch ('orphanage burner') ?
asciilifeform: 'Other Emacs stakeholders responded with confusion how this could be "a systematic effort to attack GNU packages" and also raised points on how Emacs has support for Microsoft Windows and OS X but wouldn't consider a basic patch for enabling the LLDB debugger to be used. Stallman followed up to say, "These are not similar cases. Neither Windows nor MacOS was intended to push major GNU packages out of use. What I see here appea
mircea_popescu: "It seems to be a way to extend and patch thee Bitcoin network without waiting on slow Bitcoin Core improvements."
BingoBoingo: asciilifeform> herbijudlestoids: what if you want to patch your hypothalamus ? << Don't remember if I did this or not.
mircea_popescu: you don't patch it, you burn it and get a new one.
asciilifeform: herbijudlestoids: what if you want to patch your hypothalamus ?
herbijudlestoids: what if i want to patch it
asciilifeform is not at all interested in running infinitely-memcancerous bitcoind nor can recommend it to others. but also cannot recommend the experimental patch.
BingoBoingo: asciilifeform: 0.7.2 -qt on OpenBSD with some 0.5.3.1 patches applied as they can be (i.e. scrolling reading and fingers rather than patch utility)
BingoBoingo: 0.7.2 qt, tried forever on 0.8.6 qt to avoid futzing with the BDB settings. Twas a mistake. It took the better part of a day to realize leveldb is never building for my level of skill in the necessary way and two seconds to patch that BDB shit
mod6: BingoBoingo: Thanks for the links, the second one (https://github.com/jasperla/openbsd-wip/blob/9ef1b3a903d22c946a4536f56e26cfd16429c4bb/net/bitcoin/patches/patch-src_wallet_cpp) probably fixes this warning : src/wallet.cpp:858: warning: rand() isn't random; consider using arc4random()
assbot: openbsd-wip/patch-src_wallet_cpp at 9ef1b3a903d22c946a4536f56e26cfd16429c4bb · jasperla/openbsd-wip · GitHub ... ( http://bit.ly/1DMN3Ox )
BingoBoingo: Anyone looking to build bitcoind/bitcoin-qt on OpenBSD for wallet purposes likely needs to make this source change https://github.com/jasperla/openbsd-wip/blob/9ef1b3a903d22c946a4536f56e26cfd16429c4bb/net/bitcoin/patches/patch-src_wallet_cpp
mod6: gotta add a patch for that stuff
mod6: i'll have another patch here in a minute. meanwhile, i have v0.0.8.2 of the perl script, few tweeks in case anyone cares: http://pastebin.com/raw.php?i=UNzScJP7
asciilifeform: mod6: that patch renders bitcoind-portatronic unbuildable