2300+ entries in 0.244s
phf: i already have jquery there because i wanted to add jumping from hunk to hunk on
patch page by j/k
mod6: also, re: regrind, this is for sure: when doing this task, it forces you to read and understand the
patch that needs regrinding. nothing wrong with this as far as I can tell.
mircea_popescu: but in any case, what i expect in practice is - a lot of cross signing, of people who know each other ; and a ready spot for corporate investment. "make me a mod6+alf
patch" is a job.
assbot: Logged on 20-02-2016 23:33:14; asciilifeform: to the point where i cannot even release a
patch because wtf, against ~what~ do i
patch phf: "i, ordained computron mircea lifeform, in the year of our republic 1932, having devoted three months to the verification of checksums, with my heart pure and my press clean, sit down to transcribe vee
patch ascii_limits_hack, signed by the illustrious asciilifeform, mircea_popescu, ben_vulpes and all saints."
☟︎ ben_vulpes: you will get a release
patch and you will press to it. there is your hammer.
ben_vulpes: *i* want to press specified
patch sets without doing so by hand.
assbot: Logged on 20-02-2016 20:07:06; asciilifeform: pete_dushenski: you still have to specify the
patch set
assbot: Logged on 18-02-2016 18:44:46; linton_s_dawson: I thought about what may improve the TMSR infrastructure and figured that the logs themselves are somewhat difficult to navigate. "Catching up" with the logs means reading through the whole conversation until you stumble upon what matters. I.e. "a new
patch was proposed" or "MP uncovered the next scam in the making".
linton_s_dawson: I thought about what may improve the TMSR infrastructure and figured that the logs themselves are somewhat difficult to navigate. "Catching up" with the logs means reading through the whole conversation until you stumble upon what matters. I.e. "a new
patch was proposed" or "MP uncovered the next scam in the making".
☟︎ phf: (so to wrap up previous thread, patches will remain, until clicking any
patch in that graph produces a press, ideally clicking on one of the patches from mod6 release should produce press identical to mod6's press even in the presence of conflicting patches. i'll solve this problem sometime this week)
phf: mircea_popescu: there's another
patch there that's named differently that does same thing
punkman: phf, seems so. my initial suggestion was releases as
patch sequence files, but I don't think anyone liked this idea. My vtron does .seq files with "foo.vpatch \t sha512(foo.vpatch) \n" inside, which works for my blobby vtronized things.
mod6: so what would be great here, is if you apply the
patch, or use the v.pl attached to the email (check the sigs ofc), then start clean, do a fresh `./v.pl i
http://thebitcoin.foundation`, and then press out the entire tree, `./v.pl p v v054 asciilifeform_maxint_locks_corrected.vpatch`, then `cd v054` and run that find command at the top of this paste
http://dpaste.com/2SQ1VZ7.txt mod6: i even had a thought, and im not even sure its feasible technically or just logically, but; we could perhaps create a wrapper for gnu
patch where we strip out lines that are surrounded with "%%" or something similar to how it does with "@@", this would ultimately be needed in vtron as well to avoid issues. But the thought is, then we could put comments directly in the vpatch (surrounded by '%%') and
phf: maybe press a new genesis with skull&crossbones in comments of header of every file.
patch file contents will be identical, but hashes all different
mod6: and also in other news... I'm going to publish a one line change to add a bit more strictness (less fuzz) to the map building part of V -- was basically overlooked on the last beta
patch (#3). So this one will be #4, and barring any further big issues, this should be it.
mircea_popescu: "* An example of Red Hat's "find and fix the whole issue, not just the obvious part", is shell shock. After the initial CVE for shell shock, several people proposed different ways of fixing it. Florian was one, he quickly worked on it and released a proposed
patch. Over the next few days there were three MORE CVEs for shell shock, covering different variations on the same theme. Florian's initial
patch covered all of t
mod6: morning, just a heads up here. ben has been testing V for me, and we're going through it. might need another
patch tonight.
mod6: ok, so instead what I'll do here is add an automated test to check for this, so i don't regress later. and then most likely will put out a 3rd beta
patch for people to test/review.
mod6: last chance to test that beta_2
patch for V if you still want to do so.
mircea_popescu: i am thinking : maybe including a comment line as "this
patch is intended to be applied on prev hash blabla" would do it.
ben_vulpes: perhaps a better formulation would be that there are those who curate their own
patch selection and those who delegate to the foundation.
mod6: well, we need to make a 1 line change to the 99996 build script, and then update the wiki. BUT on the other hand we're gonna need 99995 soon anyway, as soon as some people beat up on my latest
patch for V.
mod6: huh. for some reason, it didn apply that
patch ben_vulpes: mircea_popescu: file hash alone does not specify which
patch to which you pressed.
mod6: when he built it, it ~should~ have included your original malleus
patch, see: ./v.pl p verbose rotor/TEST2 asciilifeform_malleus_mikehearnificarum.vpatch
funkenstein_: I would resubmit the privkeytools
patch to ml, but I'm unsure where the rebase should go (in
patch order) and - would rather await further tests from trinque and others, seeing as this touches live ammunition
gernika: mod6 verified in v99995_beta2 that it no longer presses a non-existent
patch name and throws an error instead.
assbot: Logged on 09-02-2016 15:16:19; ben_vulpes: press a
patch without hashes in the headers
assbot: Logged on 09-02-2016 14:57:13; 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.
mod6: ben_vulpes: here's a peek at the squshed beta 1 & beta 2 vpatches - unless something changes between now and tonight, i'll be sending this one to the ML. All you need to do to apply is get V [v99996], copy `v.pl' to `v.pl.v99996`, then place this
patch in the same dir and do: `
patch -p0 < V_v99995_beta2.vpatch` and give it a go
assbot: Successfully added a rating of 2 for phf with note: provided example CL code for next deedbot, made excellent v-
patch viewer, intelligent fellow
trinque: !rate phf 2 provided example CL code for next deedbot, made excellent v-
patch viewer, intelligent fellow
mod6: shipping? it'll just be a whole bundle once we do a bit of testing -- but tonights
patch will be a squashed
patch of the one from last week, and the additional changes here.
ben_vulpes: mod6: what kind of
patch are you shipping? ri
patch or v
patch?
mod6: if/when you can get the new
patch applied, give it a try and let me know. thx.
mod6: <+ben_vulpes> press a
patch without hashes in the headers << i've actually got that one covered in the
patch im about to put out there tonight.
mircea_popescu: you necessarily and always specify the order when you write the
patch, because it includes the hash of the thing you want it applied on top of.
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
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"
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.
☟︎ ben_vulpes: if instead a v implementation presses each
patch in the flow...
phf: i recall that was first major trb
patch mod6: ok, i'll leave origin in for this second beta
patch.
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'.
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
☝︎ 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?
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?
☟︎ 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.'
☟︎ trinque: big thanks to funkenstein for his importprivkey backport
patch 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.
mod6: so yah, if i can get something figured out for that bug, maybe there will be a beta2
patch.
gernika: mod6: testing out v99995. I notice that if I attempt to press a non-existant v.
patch, there is no error, and it goes ahead and presses *something* (seems to generate the full source in the target dir). Not sure if this is intended behavior or not.
trinque: mod6: I just built 99996 plus funkenstein's importprivkey
patch btw, bout to give it a go
punkman: also could be valuable to see how B started out and then fixed, without having to diff the various versions of B
patch thestringpuller: regrind is alt-version of
patch, why can't it be applied linearly? (or at least force such a workflow)
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?
assbot: Logged on 03-02-2016 17:30:57; polarbeard: otherwise just check the sig date using pgp, last
patch wins
phf: if i have a gpgme key instance, is there some way to
patch its trust level?
PeterL: so in my example, if you add a
patch d, it could equally be added to (-b) or (c') ?
ascii_butugychag: punkman: if a
patch creates a cycle, it is ipso facto invalid.
PeterL: is the antimatter
patch the correct way to do it?
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?
☟︎ mod6: I'll probably just send the
patch to the ML to recruit people to help me test over the next two weeks.
mod6: in other news, ive got a
patch for V that's not only the fix for the post-press hash checking, but also for the problem when running the graphing tool with a node that has no decendants. and a couple of small cleanup things.
ascii_butugychag is still not sure why it was necessary to discard the history and compress the old
patch + its fix into a new one
phf: fwiw deleting a
patch doesn't "remove it" as such, but ensures that all descendants are unpressable
ascii_butugychag: every
patch ever written ~is in the tree~ as it appears to archaeologists