2600+ entries in 0.363s
mod6: I'm prefectly happy to reconstruct the
patch with spaces to stay in alignment with the current (albiet unwated) spacing scheme.
phf: ben_vulpes: of course, that bsd
patch doesn't stand in isolation. it was produced at a certain time, was since used by several people to build a version. but there's nothing to sign, because there's only pre-v
patch phf: everything else in there is either cross platform clarification or straight up an #ifdef. it's a tiny ass
patch, if it doesn't build on rotor, linux, etc. it's a bug in a
patch phf: the ~only~ "script" aspect of the
patch is "-Wl,--whole-archive -lpthread -Wl,--no-whole-archive" which is a cross platform gcc argument that ensure that pthread is truly fully statically linked into bitcoind. the issue that some parts of it don't appear consistently with openbsd gcc ~and also on some of the linux gcc versions~. fucking says so in the original email
phf: mircea_popescu: ok, so i wouldn't say not welcome, but since neither
patch was given a courtesy of a smooth transition, i assumed that neither are seen as particularly important. спасение утопающих дело рук самих утопающих (tm) (r)
phf: basically the
patch being dropped created bunch of work for me, that i don't have bandwidth to pursue. (i.e. produce a v version, test on stator)
phf: one of the features of the openbsd
patch is that it should build cleanly on linux, i.e. naive build or a stator build. i did a naive build that work, while i was developing, but since i assume it was not included in stator i can't speak to that.
BingoBoingo: If asciilifeform reads and tests what he signs the openbsd
patch would have been missed. Timestamp may have been overlooked.
phf: when it was written and submitted it applied cleanly to the tree. to my knowledge it doesn't interfere with stator build. in fact the whole point of
patch is to make minimally intrusive changes to source so that interested parties don't have to track down silly issues when attempting a build on their own. it's my understanding that the
patch was simply dropped during v-ification, so of course now it doesn't in any way fits into
phf: openbsd
patch as written results in a working build on both linux and openbsd. it introduces necessary ifdefs to ensure cross platform support. the only change that it does to makefile is, at least according to my research, is necessary with some versions of gcc, rather then openbsd specific (has to do with static linking of pthread). without that change build ~can~ produce broken static bitcoind on both openbsd and linux. at the time
mod6: and further, the changes that we wanted to make with V (where we mechanically check to see the
patch was applied correctly by checking the hashes) also will not work on bsd unless a bunch more alterations are made, but this is a side issue.
ben_vulpes: fwiw i completely failed to get the openbsd
patch to work.
mod6: phf: your
patch(s) did work for me on openbsd. i think, once we have all of trinque's makefiles ready to go with the new (forthcoming) version of V, you and I should work together to get a new vpatch of your openbsd changes submitted.
phf: but the
patch got lost, between punkman taking over logging improvements and the v-ification
punkman: mircea_popescu: start over, meaning make a new debug_sanity
patch with more improvements (and without the gui snipping parts bundled together)
punkman: I'd like to contribute more debug-related patches, could maybe split the gui-snip stuff from debug_sanity
patch, and start over.
mircea_popescu: ok but aren't they intended to be functionally equivalent by the
patch ?
mod6: if you do a pull of that
patch (be sure to obviously run dos2unix on it to get rid of CRLF), you should see that all of the lines in key.h:Sign() have tabs in front of them.
assbot: Logged on 21-01-2016 14:40:51; mircea_popescu: that once the current version being worked upon is released, we all do a whole-source scouring of spaces, and sign the independently generated results, which will be an immediate, other
patch.
mircea_popescu: <mod6> after i apply his
patch, there are no tabs, only spaces. << i made a tab'd one, then asciilifeform wanted a different one so i made that too. which are you looking at ?
mod6: <+mod6> huh, dunno, guess i could try that. << failed to
patch mod6: who knew that creating the
patch would be harder than the code itself.
mod6: after i apply his
patch, there are no tabs, only spaces.
mod6: i gotta figure out how to get this
patch exactly correct. can't seem to do it.
mod6: it pretty much applies the same, and if then I do a vdiff of a/bitcoin/src/key.h to b/bitcoin/src/key.h (where Mr. P.'s
patch was applied in b/.../) then the diff looks the same.
BingoBoingo: pete_dushenski: Much to be said for the learning value of
patch by hand in addition to doing V-presses
assbot: Logged on 21-01-2016 14:40:51; mircea_popescu: that once the current version being worked upon is released, we all do a whole-source scouring of spaces, and sign the independently generated results, which will be an immediate, other
patch.
mod6: <+asciilifeform> mod6, shinohai: the version string
patch works. BUT you will always see the default version in the boot log!! << personally I haven't even tried this yet. but I think he was saying that he checked the getinfo and that hadn't updated either.
mod6: <+asciilifeform> mod6: what was this about 'snags' with the version
patch ? << i'll dig it up, just a sec.
mod6: <+mircea_popescu> well, i do think to some degree your
patch should be restated, but not in the sense of replacing it altogether << yeah, ok. i'll do some work here today / tonight, do a re-test and the hopefully get it to the ML before the week is out.
mircea_popescu: well, i do think to some degree your
patch should be restated, but not in the sense of replacing it altogether
mod6: <+mircea_popescu> well, honestly, this wasn't intended as a release candidate, more like a commentary item << ok good deal. was kinda wondering if the forthcoming release
patch should bundle this one in or not.
mod6: your
patch really is easier to read since leaving in the vchSig.clear() etc at the top instead of moving it to the bottom like mine had.
mircea_popescu: that once the current version being worked upon is released, we all do a whole-source scouring of spaces, and sign the independently generated results, which will be an immediate, other
patch.
☟︎☟︎ mircea_popescu: <copypaste> i've even seen "security patches" where the
patch was to make the stack bigger, even though the stack was the right size to begin with << mitigation amirite.
copypaste: i've even seen "security patches" where the
patch was to make the stack bigger, even though the stack was the right size to begin with
ben_vulpes: mod6: didja ever share an actual
patch for the code you're working on? brief face-grep through logs reveals nada
mod6: im thinking maybe, worst case, i can make a
patch with just the -lows code in there, and then wait to get the rest figured out later for -highs
mod6: had some strange issue when testing my high/low
patch lastnight; worked well when it was just if(fLowS) { // low-s Code } else { //orig der code }, but when i had 'if(fLowS) { // low-s } else if(fHighS) { // high-s } else { // orig code }', tx's that I created wern't getting picked up at all.
danielpbarron: if you want to talk about V like you would talk about the Bible, you need hooks to point to (like chapter verse). so in V terms is this signed
patch and line number or something?
danielpbarron: what like "so and so
patch begag such and such
patch" ?
jurov: i did not say anything about comfort, either. how do you propose bundling the
patch spanning several files where hunks don't make sense individually?
mod6: we could do it that way, it /may/ make things easier in the sense of V -- we've been doing it the way we are to keep the
patch count low iirc.
ascii_butugychag: what i say is that REGARDLESS of the names, if THE CRYPTO is valid, it is a VALID
patch/seal tuple.
ascii_butugychag: but you also gotta consider what your box will do if it gets an inappropriately (for whatever reason) named
patch.
ascii_butugychag: this means that if jurov's box has to verify my
patch against every known sig every single time it presses to post to www, SO SHOULD MINE
ascii_butugychag: the O(N^2) instrinsic runtime of unknown-
patch-bag+unknown-sig-bag is something i realized from the start
☟︎ ascii_butugychag: (or rather, a slightly improved 'v' will run, existing one requires
patch name to remain same)
ascii_butugychag: v will run if you rename the
patch to 'fuckyou' and the sig to 'fuckapig'
PeterL: should have
patch.vpatch and
patch.vpatch.SIGNER1.sig and
patch.vpatch.SIGNER2.sig ?
mod6: which, i think is fine because then i can sign that
patch and call it: asciilifeform-kills-integer-retardation.vpatch.mod6.sig
assbot: Logged on 16-01-2016 22:31:04; mod6: the idea of V is a versioning system based upon patches that include SHA512 hashes of the file before and after the given
patch is applied -- and checks the given signatures of the wot entities who have signed off on the
patch.
mod6: <+guruvan> mod6: bitcoin docker image is up - just testing now -
patch wasn't working for me, so it's manually applied << ah, you had it build from V?
guruvan: mod6: bitcoin docker image is up - just testing now -
patch wasn't working for me, so it's manually applied
pete_dushenski: "Bitcoin Classic will not release anything but the 2MB hardfork
patch until we have hard forked. We are focused on the hard fork." << what kind of sense is this supposed to make ? (via 'toomin' not 'j')
mod6: the idea of V is a versioning system based upon patches that include SHA512 hashes of the file before and after the given
patch is applied -- and checks the given signatures of the wot entities who have signed off on the
patch.
☟︎ guruvan: BingoBoingo: can you point me to a
patch - I'll make the change
BingoBoingo: guruvan: To sync past August you'll need the latest BDB
patch thestringpuller: Just wanna get the thing synched and run the version
patch and banhammer
mod6: I've made a
patch to remove high-S, added in
patch, recompiled, restarted bitcoind and then sent a tx. here's what I'm looking at from a dumpblock of that tx:
mircea_popescu: bitcoin split specificallyt because miners "voted" to approve the (non controversial, even here, see logs)
patch BingoBoingo: I mean before using the
patch. I've only seen bloom filter from multibit/Shildebach et al hit my node.
trinque: asciilifeform: for my curiosity, if the tubes have mouths, could your
patch be used by $enemy to alter the topology of the network in ways beneficial to it?
mircea_popescu: i would strongly advise anyone using trb in production to at least test this
patch.
mircea_popescu: sooo... it pleases me to announce that private testing shows alf's
patch not only removes 80% of bullshit "nodes" trying to connect, but it also improves network thoroughput by a factor of about 700
ben_vulpes: ;;later tell phf i'm still getting segfaults with your openbsd
patch. care to look at bitcoind.core ?
mircea_popescu: punkman but it's not necessarily surprising seeing the orphanage burner
patch.
phf: you've not ~seen~ either. you come across rocky
patch in the forest and call it mountain, you call wood chipper pile forest, etc.
pete_dushenski: i've read the
patch but "boost::int64_t" doesn't mean much to me
ascii_rear: just need to
patch gcc to stop it from taking local paths shits into the binary
assbot: Logged on 05-08-2015 03:41:54; ben_vulpes: has anyone else compiled the maxint
patch and received db.log errors of "unable to join environment"?
ascii_rear still thinks it could be interesting to set up a number of publicly identifiable (version
patch) nodez and watch the enemy reaction
mircea_popescu: <punkman>
patch that wasn't in release will have to be rebased to be in next release <<<< counterintuitively i think this is a Good Thing.