Matches for patch, 1691 total results Sorted by newest | relevance
Tue Feb 09 14:59:31 UTC 2016 <mircea_popescu> thye chain you see, X is applied on "that patch with hash h1", ie G ; and in turn Y is applied to "that patch with hash h2", ie X
Tue Feb 09 14:58:41 UTC 2016 <mircea_popescu> well i have nfi what you mean by "same level", but to my eyes and from graph theory considerations it would mean "patches applied atop the same one patch"
Tue Feb 09 14:57:13 UTC 2016 <mircea_popescu> PeterL> or am I totally confused? << a patch can only be safely applied to its antecedent. two patches at the same level CAN NOT be both applied by definition.
Tue Feb 09 14:18:42 UTC 2016 <ben_vulpes> if instead a v implementation presses each patch in the flow...
Mon Feb 08 21:20:41 UTC 2016 <phf> i recall that was first major trb patch
Mon Feb 08 19:40:37 UTC 2016 <mod6> ok, i'll leave origin in for this second beta patch.
Mon Feb 08 19:33:16 UTC 2016 <mod6> and just to verify, we *do* want to be looking at the post-patch hash value correct? the 'b' as opposed to the 'a'.
Sun Feb 07 06:13:31 UTC 2016 <ben_vulpes> http://log.bitcoin-assets.com/?date=03-02-2016#1395703 << so here's what my (unreleased, v2) vtron does: it grabs all patches and all sigs, merges them into an alphabetically sorted list, and then munches through that list attaching sigs whose name matches the previous patch to that patch. is this a blindingly stupid thing to do? i realize that it depends implicitly on the naming convention, but would like to hear about other unrealized
Sun Feb 07 05:07:03 UTC 2016 <assbot> Logged on 07-02-2016 00:25:13; ben_vulpes: asciilifeform, mod6: if pressing is intended to be curated by patch selection in the patches dir, seals in the sealsdir and keys in the wotdir, why does "press" need to take a head?
Sun Feb 07 00:25:13 UTC 2016 <ben_vulpes> asciilifeform, mod6: if pressing is intended to be curated by patch selection in the patches dir, seals in the sealsdir and keys in the wotdir, why does "press" need to take a head?
Fri Feb 05 21:55:24 UTC 2016 <ascii_butugychag> 'A post to a technical forum discovered that the non-prime parameter was introduced more than a year ago. A note in the commit indicates that Socat was not working in FIPS mode because it requires a 1024 Diffie-Hellman prime, and added that a developer named Zhiang Wang provided a patch with the new prime. The poster revealed that Wang works at Oracle and contributes to Socat.'
Fri Feb 05 06:08:33 UTC 2016 <trinque> big thanks to funkenstein for his importprivkey backport patch
Thu Feb 04 04:26:00 UTC 2016 <mod6> but not for at least a week. i need some time to look into that and to let people test the beta patch. i want to get these resolved so we can move on.
Thu Feb 04 04:25:14 UTC 2016 <mod6> so yah, if i can get something figured out for that bug, maybe there will be a beta2 patch.
Thu Feb 04 01:33:16 UTC 2016 <trinque> mod6: I just built 99996 plus funkenstein's importprivkey patch btw, bout to give it a go
Wed Feb 03 22:43:36 UTC 2016 <punkman> also could be valuable to see how B started out and then fixed, without having to diff the various versions of B patch
Wed Feb 03 22:40:38 UTC 2016 <thestringpuller> regrind is alt-version of patch, why can't it be applied linearly? (or at least force such a workflow)
Wed Feb 03 22:33:01 UTC 2016 <assbot> Logged on 03-02-2016 18:04:14; PeterL: if you have patches a->b->c and you decide to get rid of b, you should end up with a->b->c->(-b), not with a->c' (where c' is reground c without b patch) , do I understand correct?
Wed Feb 03 22:10:33 UTC 2016 <assbot> Logged on 03-02-2016 17:30:57; polarbeard: otherwise just check the sig date using pgp, last patch wins
Wed Feb 03 20:48:35 UTC 2016 <phf> if i have a gpgme key instance, is there some way to patch its trust level?