900+ entries in 0.081s
phf: i suspect you only have the first
patch applied, which comes with a makefile, and which will indeed produce a vdiff that doesn't know how to hash
mod6: oh, that's right, the
patch is pressed, ~then~ each of the files touched is hashed & verified. makes sense now.
mod6: (alf's
patch reground onto phexdigit -- for my peronsal use only at this point)
a111: Logged on 2018-10-24 19:57 phf:
http://btcbase.org/log/2018-10-23#1865503 << i threw your
patch on btcbase, it looks good, though i'm not sure i agree with the decision to put temp file in /tmp. the point of putting it in same hierarchy as press, was to avoid the whole cross-file-system issue
phf: i grok the reasoning, but there are two issues: as of right now nobody's mounting to nfs, but at least in my stack tmp is not always as secure as other places i might be pressing, and the
patch doesn't respect the environment TMP/TMPDIR convention.
phf:
http://btcbase.org/log/2018-10-23#1865503 << i threw your
patch on btcbase, it looks good, though i'm not sure i agree with the decision to put temp file in /tmp. the point of putting it in same hierarchy as press, was to avoid the whole cross-file-system issue
☝︎☟︎ a111: Logged on 2018-10-15 15:44 asciilifeform: in unrelated noose, mod6 et al : loox like trb doesn't remove banned peers from its addr table ! i.e. offers their addrs up to others, as if they were proper noades!! i never noticed this previously, it had to wait to be found empirically. really oughta be fixed, and pretty simple
patch.
mircea_popescu: (better than "i'll wait to
patch it in directly at the right time" because the "right time" mioght never come seeing how the people in question don't know what you're patching)
mircea_popescu: anyway -- in this particular case it makes sense to genesis item so downstream can actually invite you to
patch on their tree
mircea_popescu: i was thinking, has major chances of being pulled as a
patch into eulora-something.
a111: Logged on 2018-10-15 15:44 asciilifeform: in unrelated noose, mod6 et al : loox like trb doesn't remove banned peers from its addr table ! i.e. offers their addrs up to others, as if they were proper noades!! i never noticed this previously, it had to wait to be found empirically. really oughta be fixed, and pretty simple
patch.
a111: Logged on 2018-10-15 01:42 phf: bvt: your
patch has "Binary files..." at the very end of it. i assume it wasn't made with vdiff
mircea_popescu: so -- looking back to the crc32 situation, suppose that for whatever reason the consensus wasn't "yeah, should definitely have both" but "division is stupid, only tables are needed". at that juncture, ave1 could have made an alternate
patch to the crc32-lookup consisting of merely a changed manifest, saying "Hey, for so and so reasons I think this should be a crc32-division, I intend to do it later."
diana_coman: ave1, please update so I can sign the
patch a111: Logged on 2018-10-15 06:49 diana_coman:
http://btcbase.org/log/2018-10-15#1862722 -> hm, multi for the sake of it would anyway be taken care of via who signs and who doesn't sign the various patches or trees; but anyway - do you mean you think there should be explicit multi-tree dependencies? this is what I was talking about there: tree A effectively links to
patch B.3 in tree B so if B's maintainer regrinds then A's maintainer has to go on a shouting spree (as per "talk to peop
a111: Logged on 2018-10-15 03:57 mircea_popescu: in any case, type1 might get i dunno, later-
patch-taking-advantage-of-ddram whereas type 2 might get later-
patch-needed-for-old-arms etc.
diana_coman:
http://btcbase.org/log/2018-10-15#1862722 -> hm, multi for the sake of it would anyway be taken care of via who signs and who doesn't sign the various patches or trees; but anyway - do you mean you think there should be explicit multi-tree dependencies? this is what I was talking about there: tree A effectively links to
patch B.3 in tree B so if B's maintainer regrinds then A's maintainer has to go on a shouting spree (as per "talk to peop
☝︎☟︎ a111: Logged on 2018-10-14 16:18 asciilifeform: imho 'unifiers' (i.e.
patch that pulls in specific state from a parallel tree) is a cleaner way of accomplishing this than cut&paste, but i was unable to persuade.
mircea_popescu: in any case, type1 might get i dunno, later-
patch-taking-advantage-of-ddram whereas type 2 might get later-
patch-needed-for-old-arms etc.
☟︎ trinque: not blocked on anything afaik, improvements to vtools can come in as another
patch for the ebuild tree
phf: diana_coman: i've updated eucrypt to keccak, i also added ave1's
patch there. also brought udp up to date.
phf: bvt: your
patch has "Binary files..." at the very end of it. i assume it wasn't made with vdiff
☟︎ diana_coman: maybe I didn't understand then what you mean by "
patch that pulls in specific state from a parallel tree"
ave1: yes, I see! I will try that too. I have no idea how it could automatically resolve (i.e. How could
patch that has your original
patch as it's parent ever work on top of this one)
a111: Logged on 2018-10-12 16:32 mircea_popescu: ave1 you can literally make it alternate
patch to the table crc32, so one can press either, according to need/want.
mircea_popescu: asciilifeform the reason i even called it ideological
patch is because the pretense that shitropy-eaters have anyhthing to do with entropy, or us, must be shot in the head.
mircea_popescu: ave1 you can literally make it alternate
patch to the table crc32, so one can press either, according to need/want.
☟︎ mircea_popescu: (but, importantly, /dev/random === /dev/urandom is a fundamental ideological
patch. fuck the fucking idiocy!)
a111: Logged on 2018-10-11 19:59 phf: but it also seems that before that becomes reality we either have to
patch linux kernel or implement a rng daemon or somesuch
phf: tmp file gets created when you have any sort of patching operation, gets cleaned up when you no longer need it. but you could conceivably have it for the duration of the runtime. (except instead of doing file move at the end of a single file
patch, you do file copy)
phf: but it also seems that before that becomes reality we either have to
patch linux kernel or implement a rng daemon or somesuch
☟︎ phf: format breaks only in a sense that gnu
patch won't press it. current vpatches that don't delete/rename (since the feature is not there) will never the less work with any future changes to vtools
diana_coman: well, if it's "give" then it will have to be signed tar as far as I can tell, I still don't see why one would basically import gnu
patch just in order to "give n00b" anything; the options are always either "take what exists i.e. on trust " (in which case archive) or "go and make your own" in which case what's the problem
a111: Logged on 2018-10-06 16:40 phf: apropos i want to move vtools to keccak, but i'm not sure what's the best way to solve bootstrapping problem. a signed tar archive of a press that can be used to bootstrap or manual press instructions using gnu
patch?
mircea_popescu: as long as you
patch on his keccak tree i can't see how it could not be.
phf: apropos i want to move vtools to keccak, but i'm not sure what's the best way to solve bootstrapping problem. a signed tar archive of a press that can be used to bootstrap or manual press instructions using gnu
patch?
☟︎ a111: Logged on 2018-10-01 14:08 asciilifeform: incidentally, does anyone remember wtf happened to the 'log timestamps'
patch for trb ? who wrote it, and how come it never made it into the flagship tree ?
mod6: I love trb, and doing the foundation. I take a very measured, meticulous, methodical, and detail oriented approach to the work to provide a very sound
patch set -- as best as I can.
a111: Logged on 2018-10-01 14:08 asciilifeform: incidentally, does anyone remember wtf happened to the 'log timestamps'
patch for trb ? who wrote it, and how come it never made it into the flagship tree ?
a111: Logged on 2018-10-01 03:22 mircea_popescu: diana_coman is that getting a
patch or what ?
diana_coman: anyways, I'll get around to
patch my node and see what that gets
trinque: lovely, I'll have to dust off my wallet excision
patch and submit too
a111: Logged on 2018-09-27 17:54 asciilifeform: phf: imho your approach , i.e. dispensing with gnupatch, is The Right Thing, historically there was quite a bit of grief from gnupatch's habit of eagerly attempting to apply an invalid (by vtronic lights) but 'partially ok' by barbarian lights
patch phf: re esthlos's work i think it's a shame that he chose to reimplement own keccak, but is still calling out to gnu
patch. he could just focus on graph resolution/signature/wot checking, and offload the validation on vpatch: construct the press list, feed the patches in-order to vpatch, if vpatch succeeds then you know _for certain_ that the sequence of patches is valid, hashes and all
a111: Logged on 2018-09-27 15:33 phf: asciilifeform: this has been extensively discussed in the logs. there was never a need for "new style v". v works just fine. one of the design goals of vtools was to nail down (and improve upon) the
patch format. vtools are explicitly designed to be used with an existing v (for example i use it with v.py). vdiff produces wellformed vpatches and vpatch presses them ensuring that the format is valid and that the hashes stand. there's no
phf: when i started working on vtools there was already a handful of battle tested V implementations, that relied on vdiff.sh/gnu
patch combination. vtools is a "drop in" replacement for the later. you get valid vpatch on the input, valid press on the output. the purpose is to nail down the format, and gradually replace out its parts (e.g. transparent sha->keccak transition)
phf: asciilifeform: this has been extensively discussed in the logs. there was never a need for "new style v". v works just fine. one of the design goals of vtools was to nail down (and improve upon) the
patch format. vtools are explicitly designed to be used with an existing v (for example i use it with v.py). vdiff produces wellformed vpatches and vpatch presses them ensuring that the format is valid and that the hashes stand. there's no
☟︎ diana_coman: re using vtools, I currently first check sig (so by hand, separate 1-line) and if ok, then feed
patch to vtools
BingoBoingo: <trinque> does it now properly verify hashes? << I am still at the point where I hand read input,
patch, and output
a111: Logged on 2018-09-26 18:46 diana_coman: asciilifeform, udp tester seems to be nicely running uk->uy and uy->uk so my next step on this will be to publish all the relevant code; since this is effectively on top of udplib, I'd
patch it on your tree; mind moving it though to keccak?
mircea_popescu: the things that end up discussed as a result of "wouldja publish proper tree so others can
patch on it already"
diana_coman: asciilifeform, udp tester seems to be nicely running uk->uy and uy->uk so my next step on this will be to publish all the relevant code; since this is effectively on top of udplib, I'd
patch it on your tree; mind moving it though to keccak?
☟︎ hanbot: <mircea_popescu> hanbot scheduled to
patch ? << iirc this is second instance of query. i'll
patch it this week, yes.
ave1: phf,
http://btcbase.org/log/2018-09-23#1852924, I've tried on debian and I can reproduce the problem, Unfortunately I have no solution yet (it will probably be a
patch). It seems the default/internal gcc spec defines "-isystem /usr/include/x86_64-linux-gnu
☝︎ trinque: I can next hand-craft a descendent
patch for a similar "tmsr" base profile, and torch all the rest
trinque: what I've done instead is slurped out just the profiles used, without concatenating. this fits with my strategy of the genesis
patch being as close to "what was found" as possible, with only machine transformations involved in the leap from gentoo to cuntoo
diana_coman: asciilifeform, I combed your
patch and did not see any fix for this - did I miss anything? (I did not press it because my code was already changed anyway in all sorts of ways; I read the
patch though)
mircea_popescu: there's no by-
patch state machine wtf is wrong with you.
mircea_popescu: this isn't going to become a monthly cycle, is it ? "i don't like this vtree" "do you have a
patch ?" "no, i just don't like it" "well... come back with a
patch"
diana_coman: and I actually have both on for now, hence yeah, I just pressed your
patch with old V
mircea_popescu: or you mean "regrind the
patch" ? usually regrind means you know, the whole tree.