2400+ entries in 0.263s
ascii_butugychag: ~
patch submitter~ has the responsibility of coming up with a unique name.
polarbeard: I mean a timestamp in the filename author_patch_thing_$(date +%s).vpatch
jurov: anyway, matching the signature against all versions of one
patch isn't so big thing to swallow
ascii_butugychag: polarbeard: because sigs submitted arbitrarily later than the
patch !!!
ascii_butugychag: jurov: how will you deal with sigs produced after the
patch submission date ?
jurov: not really, sigs were supposed to carry SHA1 of the
patch they apply to
mod6: ascii_butugychag: is this kinda what you were asking for yesterday? A vdiff of a pressed original patches (minus PVS fix) + shiva with pressed mod6's integrated
patch + malleus regrind + shiva ?
ascii_butugychag: so long as every
patch ever submitted can be pressed to, the thing works correctly.
polarbeard: otherwise just check the sig date using pgp, last
patch wins
☟︎ ascii_butugychag: (which ~really~ needs to be come the canonical
patch swallower and lxr replacement )
polarbeard: actually git comes handy to manage trb
patch-sets
mod6: ;;later tell funkenstein_ thanks. yeah, that
patch will be useful. will try to get it in right after the release.
funkenstein_: it got hung up when i added another
patch "chuck_checkpoints" with mistake.. now sits there for eyeballs if anyone is interested
phf: well, the idea is that you want to click on the
patch and see how to press it. if i were to click in polarbeard_* presumably i want to press the tree that includes old malleus?
phf: jurov: i don't handle
patch conflicts yet, until there's some kommunitee resolution. and if the answer is "remove them from your patches" probably going to add some kind of tree walk in addition to topo. fwiw right now on the site you can see patches that wouldn't press cleanly in "pink"
punkman: I remember some mentions of a backport
patch for key import
mircea_popescu: ascii_butugychag> my intent was that the user would include ALL of the leaves he is interested in by using a custom
patch dir, and then press to the last. << this is not a bad approach (for dev work). i wouldn't want it in the press-for-deploy, but different story.
mod6: ok, well, we can worry about that later when we write our own
patch-o-matic
ascii_butugychag: the result of a '
patch' ever not matching the hash, SHOULD NOT HAPPEN
ascii_butugychag: my intent was that the user would include ALL of the leaves he is interested in by using a custom
patch dir, and then press to the last.
ascii_butugychag: PeterL: my original vtron was controlled by manually selecting
patch sets
polarbeard: I'm aliasing potch='
patch --fuzzy 1000'
mircea_popescu: jesus i wonder how much "mission critical code" was really written by
patch itself.
mod6: before i re-grind this
patch, im gonna look into V a bit while I wait for ascii to give me the green light on the other two reground from lastnight.
ascii_butugychag: i thought mod6's vtron actually verified each
patch operation ?
jurov: is that always decidable? if i have A, which has a child
patch B, and author regrinds A into A' which is to be kept?
ascii_butugychag: an obsolete
patch is simply one that doesn't keep getting built on.
ascii_butugychag: ty mod6. i'd like to note that in a time of 'fog of war', when some
patch is up in the air, it is not necessary to hold off on ~all~ work, but only things which concern the affected subsystems.
mod6: if anyone else is in the middle of creating a
patch - maybe hold off a day or so before you submit until I can straighten out the tree & test everything.
mod6: looks like it compiled fine -- even though the
patch had to apply with Hunk offset garbage
mod6: whats weird here, is that the hashes in the
patch, before and after, match nothing that i've got. so i've gotta figure that out.
polarbeard: ben_vulpes, mircea_popescu: hey thanks for reviewing and submitting my
patch mod6: something is wrong with that
patch, and V isn't doing anything about it.
assbot: Logged on 02-02-2016 14:14:45; mircea_popescu: trinque so not with the intent to pressure you, but : is deedbot
patch insertion likely to come online soon or should i re-learn how to do it via email ?
mircea_popescu: trinque so not with the intent to pressure you, but : is deedbot
patch insertion likely to come online soon or should i re-learn how to do it via email ?
☟︎ mircea_popescu: as annoying as b c etc might be they're mostly minor and could be fixed by a further
patch. a however is a killer, and colors both b and c in similar tones, because it betrays the fundamental problem with this
patch : it doesn't flow from a structured approach given in depth consideration, but merely from your desire to help and impressive stamina.
jurov: i just happened to stumble upon it cuz vulpes' test data has only one - alf's signature per
patch mod6: in the case of v, if she had created a
patch, and she was the only one who signed it and her key expired tomorrow, well, someone better grok it and sign it who's in the current lordship
trinque: trb node is at 384k; I will be switching to that with anti-heathen command
patch very soon
mod6: and a similar situation in V would be like 69 patches to
patch the original
patch.
mod6: anyway, i created a new
patch for PVS and did a regrind on malleus (since this one depends on main.cpp)
mod6: hey ascii_butugychag, so i figured out what my dumbass did yesterday. somehow, when looking at your fix
patch - I missed the portion where you changed main.cpp altogether.
polarbeard: so if I can add another
patch on top of these I will keep working on it but I'm tired of rediffing...
polarbeard: to be honest, I see this thing going forward if I don't have to generate a new
patch again
polarbeard: mircea_popescu: I didn't know it was expected to solve it, but ok, I see this
patch is consuming too much time from everybody...
mircea_popescu: polarbeard it won't hurt anything writing a backport
patch for it if you feel like it.
kakobrekla: you must be getting banned by that banhammer
patch mod6: asciilifeform: yeah, i dunno what i screwed up with that integration
patch of mine, but yeah, your vpatch fix pressed and compiled fine.
mod6: thanks for taking a look at that. did you see my replacement
patch then?
ben_vulpes: eg that `v press shiva stans_sweet_patch.vpatch && v press shiva stans_sweet_patch.vpatch' must result in the same tree as running the command once.
mod6: mircea_popescu: that part is just in reference to V's release in R.05, not the high/low S
patch which is R.09
assbot: Logged on 31-01-2016 14:42:22; mircea_popescu: just, if you want to add a
patch, should be able to dump it as dpaste also.
mod6: asciilifeform: <+mod6> so... i've integrated asciilifeform's fix into a new
patch that will replace the old one:
http://dpaste.com/2KCXN8A.txt << <+mod6> ahh, and then there is this now -- when compiling with alf's fix incorporated: <+mod6>
http://dpaste.com/1AVK5ZP.txt << any thoughts on how to fix0r this?
ben_vulpes: so if i press those individually, in order, they work. but if i press the last
patch, i believe that it fails to find its antecedents.
mod6: im gonna test this revised
patch, if works, send it, then get that SoBA in ship-shape.
phf: asciilifeform: original conception requires "sufficiently smart
patch" then, unless i'm missing something
phf: ah that gives you ability to press purely from wot knowledge, without reading the
patch phf: mircea_popescu: is that a list of names that correspond to .wot? i.e. each
patch has (asciilifeform, mod6, etc.) and then there's a set of all wots for current press?
mod6: start without this
patch : asciilifeform_malleus_mikehearnificarum.vpatchasciilifeform-programmable-versionstring.vpatch, or th mod6_der_high_low_s.vpatch
mod6: your
patch should have antecedent: bc602bfbc512259fbb6c01f2c1633ff142966bf0752612e9a488cee8a95da7921b98abe646e2f7002243f1981939372e0b53948646398e40525ed442c377f449
mod6: this
patch just comes after the original
phf: asciilifeform: so that new version replaces old
patch?