tmsr - Search: patch

3300+ entries in 0.256s

asciilifeform: after satisfied with this patch, therealbitcoin folks ought to try the static build again

asciilifeform: anyway no point in recounting the lines of the patch here

asciilifeform: it is also one minor patch away from having all magic/hardcoded net addrs stripped away

trinque: asciilifeform: I lobbied the maintainer to patch the thing so it'd build

mats: > the team is disclosing full details of the Microsoft Internet Explorer research submitted after receiving confirmation that Microsoft does not intend to patch the Address Space Layout Randomization (ASLR) flaw involved.

assbot: Logged on 19-06-2015 17:17:56; BingoBoingo: tldr: Pool implements a replace by fee patch, derps herp because it means People can double spend before the transaction is committed to a block!

BingoBoingo: tldr: Pool implements a replace by fee patch, derps herp because it means People can double spend before the transaction is committed to a block! ☟︎

ascii_field: i.e. everything inside a patch file must pertain only to what was 'printed on the box', and vice-versa.

mod6: yup, i see that. thanks for linking them in the patch emails.

mod6: <+ascii_field> mod6: how are those test rigs doing ? < << If you mean the bitcoin-v0.5.3.1-RELEASE + patch(s) { Orphanage Thermonuke + TX Orphanage Amputation }, they were performed on AWS deb6 instance and have since been shutdown after full sync & performance tests completed. Main reason being to dig into compiling v0.5.3.1 + gentoo sanity patches with uclibc on Gentoo on AWS Gentoo instance. I try to only run one instance at a time to keep mo

ascii_field: shinohai: the linked patch is 5 minutes old

ascii_field: ben_vulpes: i would like to nominate above patch (and its dependency, dns-seed-remover) for mainline

trinque: shinohai: sounds like a patch to bitcoind

mod6: but im positive that i'd never get it configured correctly to use uclibc and whatever other configurations are required to even test this patch. even if I get the patch to work, how am I supposed to get this into such a state that someone else can repeat it?

mod6: could I just pull down gcc-4.8.4 itself and patch? sure. it'd be a lot easier.

mod6: im attempting to apply the gcc patch we discussed the other night: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00410.html

mod6: i would think i would need to build whatevre this is: x86_64-gentoo-linux-uclibc-gcc (Gentoo Hardened 4.8.4 p1.5, pie-0.6.1) 4.8.4 + the obscure patch in msg00410

mod6: <+decimation> https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00410.html < gcc patch that maybe fixed the issue << is there any likelihood that this patch can be applied to 4.8.4? or is 5.x required?

decimation: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00410.html < gcc patch that maybe fixed the issue ☟︎

mod6: the linker is saying that an R_X86_64_PC32 relocation against an undefined symbol can't be used in a shared object... maybe your removal of the dns shit fixes this. not sure. will try adding that patch as well if this next thing doesn't work.

mod6: well, i've got the stdint thing figured out for the time being. i've applied your patch "asciilifeform-kills-integer-retardation.patch" and "nubs-gentoo-sanity.patch".

asciilifeform: (not like it's a hard patch)

asciilifeform: i have a months-old patch on the ml, which got lost among the nuts and bolts, that nukes dns seeds

scoopbot_revived: Eulora client Freenode patch http://trilema.com/2015/eulora-client-freenode-patch/

mircea_popescu: a number of explanations are readily available : a) M works on specific code that happened to be wrung out of openssh codebase somehow. differential reading of gpg and openssh should indicate it then, and patch history should show us who knows better.

mod6: hi ascii_modem. I've got igprof built, and i tested it with the test code in the COMPILE.txt file. i've got your igprof_hooks patch applied to the v0.5.3.1-RELEASE source, and i've built it dynamically.

mod6: alright, bitcoind build cleanly with the igprof_hooks patch applied.

mod6: ok asciilifeform's igprof_hooks patch applied to v0.5.3.1-RELEASE

cazalla: never played it but i have read that it was great prior to some big patch

mircea_popescu: mod6 i don't recall, is that patch written yet ?

asciilifeform: mircea_popescu: if running tests, consider the igprof patch

mod6: asciilifeform: ok. i'll have to think on that a bit more. i wanna be sure of what these changes imply. anyway, a guy can always patch his own if he wishes in the mean time.

mod6: <+asciilifeform> mircea_popescu: and must nitpick, but it isn't the current therealbitcoin yet. not until patches are ratified. << we'll get there. I'd like to have a discussion at some point about the possible negitive effects of at least the TX Orphanage Amputation patch.

shinohai: I haven't applied that patch yet :/

assbot: Logged on 01-06-2015 14:53:54; mod6: <+shinohai> To whatever peers it connects to instead of specifying ip's << hi! glad you're having some success,.. I thought we added ascii's dns snip patch? Or did I mis-remember that? you did have to use "addnode=" in your bitcoin.conf right?

mod6: <+shinohai> To whatever peers it connects to instead of specifying ip's << hi! glad you're having some success,.. I thought we added ascii's dns snip patch? Or did I mis-remember that? you did have to use "addnode=" in your bitcoin.conf right? ☟︎☟︎

asciilifeform: (it works without the patch but you can't take runtime heap snapshots then)

asciilifeform: mod6: the igprof thing was its own patch

assbot: 18385 results for 'patch gribble OR nanotube' : http://s.b-a.link/?q=patch+gribble+OR+nanotube

Adlai: !s patch gribble OR nanotube

assbot: Logged on 31-05-2015 12:11:09; mircea_popescu: http://log.bitcoin-assets.com/?date=31-05-2015#1148837 << i would like to see a patch which maintains VALUED list of other nodes.

asciilifeform: (incidentally, a while ago i posted a patch that kills log rollover. might be of interest to some of you)

mircea_popescu: http://log.bitcoin-assets.com/?date=31-05-2015#1148837 << i would like to see a patch which maintains VALUED list of other nodes. ☝︎☟︎☟︎

decimation: with the thermonuke patch applied

decimation: I'm not sure, I need to get back on the patch train

ben_vulpes dreams of a box beefy enough to run sync tests for every patch submitted

asciilifeform: ;;later tell mircea_popescu this patch sorta sits right down and has lunch right on top of your 'clean air filter' third rail discussed in c3. but this gordian knot -will- have to be cut one way or another.

asciilifeform: ;;later tell mod6 please consider this patch for your test rig

asciilifeform: ben_vulpes: it will make sense once you read the patch.

danielpbarron: confirming that the patch did in fact remove it

jurov: yes. pls mind the instructions about file naming so that the filename contains original patch ID

jurov: looks like you haven't used the patch IDs

jurov: http://therealbitcoin.org/ml/btc-dev/patches.html propped up...but it looks no one signed someone's other patch yet?

mod6: <+jurov> mod6, ben_vulpes, everyone: http://bluesky/ml/test/patches.html needs to manually fill data for "Released in/Based on" columns - just version strings for every patch, help appreciated << this is 404 for me.

jurov: mod6, ben_vulpes, everyone: http://bluesky/ml/test/patches.html needs to manually fill data for "Released in/Based on" columns - just version strings for every patch, help appreciated

ben_vulpes: trinque: dpaste with patch vanished. plz to turdalize.

jurov: it's the nubbins` tax patch

ben_vulpes: asciilifeform: 0.5.3 (virginal, aside from db lock patch), 0.5.3.1-RELEASE and 0.5.3.1-RELEASE + orphanage thermonuke

jurov: well, our problem is not patch management, but *reading* them

decimation: ascii_field, mod6, ben_vulpes > have you seen this tool for managing patches? > http://julipedia.meroh.net/2013/11/patch-management-with-quilt.html

trinque: ben_vulpes: that said a working dieharder can be built with my naive patch listed in that bug report

trinque: yeah I'll make a patch

trinque: yeah I'm figuring out a patch

mod6: well, actually, i'd post the orphanage-thermonuke patch test data now, but it's 113 mb of raw nmon captures.

mod6: Now, currently, I'm running a very similar test with v0.5.3.1-RELEASE (as a baseline) without your OrphanageThermonuke patch included... it did oomkill once, yesterday.

asciilifeform: (not to be confused with much earlier orphanage burner patch)

asciilifeform: danielpbarron: thread concerned 0.5.3.1 with orphanage-thermonuke patch.

mod6: <+asciilifeform> mod6: please post any data you may have collected at the moment of the oomkill << so just to reiterate here, the current perf test I'm running is with the v0.5.3.1-RELEASE which oomkill'd (as it's known to do). I'll post the nmon charts, log, and vmstat log. no core file was created. However, as a reminder, the previous perf test that I ran with v0.5.3.1-RELEASE+{asciilifeform_orphanage_thermonuke.patch}(http://thebitcoin.foun

mod6: After this one is done, I was going to run a vanilla v0.5.3 to get a baseline from that as well. And I will do that, but did remember that it /does/ at least require the db patch to achieve full sync.

assbot: LKML: "Jason A. Donenfeld": [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities ... ( http://bit.ly/1FaaxwI )

mod6: anyway, I was considering running another full-sync without the OrphanageThermonuke patch -- just a v0.5.3.1-RELEASE baseline.

ascii_field: mircea_popescu did read the patch iirc

Azelphur: Actually working on electrum atm that said, it hates me because I'm British so I'm having to patch it

davout: asciilifeform: so i managed to get "busybox mkfs.ext2 /dev/sda1" working on the pogo by using buildroot-2015.05-rc1 instead of 2015.02, applying your patches (which do apply cleanly), apply my WIP-patch, and boot on that

mats: asciilifeform: monkey patch for sure, but it does have its place... with a dozen other mitigations.

mod6: I started it up few days ago just after I looked over the Orphanage_Thermonuke Patch: # ps aux | grep "bitcoind"

mircea_popescu: "“They want everything for nothing. They wouldn’t go for five seconds without being paid. And they’ll bitch about how much they’re paid, and want more. I should do a freebie for Warner Brothers? What, is Warner Brothers out with an eye patch and a tin cup on the street? Fuck, no."

mod6: for comparison sake, here's what the machine looked like before and just after bitcoind with this patch was executed: http://dpaste.com/094DT78.txt

jurov: nope. had to manually patch "GaramondNo8" ttf files

mod6: I also want to focus on the testing of your patch ascii_field. If it is to be merged, we must ensure that we do not regress.

ascii_field: mircea_popescu: take a few min. to read the patch, if you have not. the behaviour should be logically equivalent to virginal 0.5.3 with an orphanage of zero

mod6: ascii_field: I'm running with this patch: http://therealbitcoin.org/ml/btc-dev/attachments/20150504/asciilifeform_orphanage_thermonuke_2d219fdd1a0da960be38797566e9c0820df11ce6.patch

assbot: Logged on 06-05-2015 14:27:11; asciilifeform: l0l, 4th google hit is my patch

asciilifeform: l0l, 4th google hit is my patch ☟︎

davout: asciilifeform: am i correct in my understanding of the thermonuke patch that it will try to reverse-sync starting from any arbitrary block it receives?

ascii_field: unrelated: therealbitcoin is still unbuildable for cross-arm using anything but old makefile + my (unmerged) portatronic patch

davout: asciilifeform: really curious to see how the orphanage thermonuke patch will work in the field

jurov: http://log.bitcoin-assets.com/?date=05-05-2015#1120242 if you have any better idea how to come up with patch ID and propagate it ☝︎

mod6: 9d7cab14db48000ed91d12301f19341ce55e86fe919922f8a4f80f49625b881b296deb037d35ef899996e097b4f1c0ab5a035c2ced04758b9838f3924ce4ed78 asciilifeform_orphanage_thermonuke.patch

mod6: # sha512sum asciilifeform_orphanage_thermonuke.patch

asciilifeform: sha512(asciilifeform_orphanage_thermonuke.patch) == 9d7cab14db48000ed91d12301f19341ce55e86fe919922f8a4f80f49625b881b296deb037d35ef899996e097b4f1c0ab5a035c2ced04758b9838f3924ce4ed78

danielpbarron: http://therealbitcoin.org/mailman/listinfo/btc-dev The system will rename the patch and add unique identifier (SHA-1 hash of the contents) to the filename, both in the outgoing email and in the archives. Any additional signatures must refer to this received filename including the hash.

danielpbarron: the patch.sig is by ascii's key, so it shouldn't matter what it hashes to or what btc-dev says

mod6: yep, got that too... but check the sha256's of the dl'd patch files, see if they match the checksums that the ml inserted into the file name.

mod6: -rw-r--r-- 1 root root 4007 May 5 00:19 asciilifeform_orphanage_thermonuke.patch

mod6: curl -s http://therealbitcoin.org/ml/btc-dev/attachments/20150504/asciilifeform_orphanage_thermonuke_6f320afb2423a2892d89e855829e3915c8b7a170.patch.sig -o asciilifeform_orphanage_thermonuke.patch.sig

mod6: curl -s http://therealbitcoin.org/ml/btc-dev/attachments/20150504/asciilifeform_orphanage_thermonuke_2d219fdd1a0da960be38797566e9c0820df11ce6.patch -o asciilifeform_orphanage_thermonuke.patch

mod6: anyway, moving on. I'll get the test in motion for asciilifeform's new patch.

mod6: so, I have that deb6 aws env still... I used to use MRTG, but now I guess this 'RRD' thing is all the rage. I know for sure that I can test mem on a 1s interval with vmstat and capture that with `script`. I'd really like to compare the network traf of full sync with the patch, and without.