110900+ entries in 0.063s
mod6: Before we said "all antecedents must be present for a descendant
to be in
the flow".
mod6: I suspect
that is
the problem with
the rules.
mircea_popescu: omg i just pointed out
the cause : he links
the wrong version of xalloc
mod6: i need
to do a deep debugging session
to figure out
the root cause.
mod6: there is a reason
that
those
two vpatches are being
thrown out.
mod6: It sucks up way
to much of my
time.
mod6: Someone needs
to write and maintain a proper V for
the republic.
mod6: I don't have
time
to debug
this shit now. but at some point I'll have
to actually look at
this project and
try
to figure out what
the graph is ~supposed~
to look like and why my V chokes on it.
a111: Logged on 2018-04-09 06:34 mircea_popescu:
that's
the fucking problem!
the vtools_fixes_static_tohex uses xalloc.h 98BA when it should instead use its own line (earlier) version of C89B.
phf:
http://btcbase.org/log/2018-04-09#1794530 << you can see
two lines going into vtools_fixes_static_tohex, one from vdiff_fixes_newline_gcc and another from vdiff_sha_fixes_newline_gcc.
they are both from 98BA and either should satisfy
the requirement.
the other
two lines in are from vtools_vpatch only for 7EBF and 02A0.
☝︎ a111: Logged on 2018-04-09 05:04 mod6: 3) Check
the flow, see
that vtools_fixes_static_tohex.vpatch is not in
the flow, and check
to ensure
that
the seal verifies, and it dows
shinohai: Will be happy
to serve as extra set of eyes if you want
to dig further mod6
a111: Logged on 2018-04-09 04:25 hanbot: phf et al: attempted
to press latest vtools
to
the keccak head. v (mod6's) reports vtools_vpatch_newline not in flow, neither its antecedent vtools_fixes_static_tohex, despite both patches and (verified good) sigs present (they neither show up via flow command). v will press
to vtools_vpatch.vpatch, but no further. see
http://p.bvulpes.com/pastes/oNRhE/?raw=true .
mircea_popescu: read
the log,
they had a whole
thing recently with like 100kgs worth of various shit.
mircea_popescu: ah,
that may work out.
talk
to ben_vulpes when he wakes.
ckang: and a place
that doesn't care about DMCA
mircea_popescu: well,
talk
to ben_vulpes ; not enough machines yet, but yes, more being shipped
ckang: I wanted some offsite / bulletproof storage, I am moving entirely off
the 'cloud'
mircea_popescu: ckang BingoBoingo is in uruguay building
the pizarro.isp ; see pizarroisp.net and you know,
ckang: I was wondering if
there was any details about
that available yet?
ckang: oh, I
think I need
to be unvoiced, says I cant myself yet
douchebag: he also is more into stuff at
the network level
douchebag: i'm more experienced with web stuff
than him
douchebag: he's a bit more into lower level stuff
than me
ckang: i guess
that is a big vague
though, i poke
things until
they break
ckang: I have used
the suckless irc bot
though
mircea_popescu: ckang are you
the guy with
the gopher stuff / suckless morphing ?
mircea_popescu: that's
the fucking problem!
the vtools_fixes_static_tohex uses xalloc.h 98BA when it should instead use its own line (earlier) version of C89B.
☟︎ mircea_popescu: phf oh! it
tries
to press vdiff_sha / etc because
they're actually a dependency for
tohex ?! why did you write it
this way ?
ckang: ive heard stories about
this place and decided i needed
to see it for myself
douchebag: He seemed curious
to see what
this place is about after discussing
this
douchebag: I've known
this guy for awhile now, mainly discuss
technical
topics and such with him
mircea_popescu: anyway, it's not an emergency, sleep
tight also we see
tomorro
mircea_popescu: phf it's incomprehensible
to me as
the manifest.txt varies wildly.
phf: i can only say
that i
think
that btcbase presser is doing
the same
thing, with
the "5 steps down keccak and 2 steps down sha", but
the grapher doesn't. i
think grapher uses more Graph
Theory, but i neither remember what
the difference is, nor can i debug it now (was about
to go
to sleep myself)
mod6: i need
to call it a night.
mircea_popescu: this makes no sense. basically it goes 5 steps down
the keccak
tree and
then jumps
to step 1 and 2 on
the sha
tree.
mircea_popescu: mod6 ok here's what i don't understand : for some reason
the "flow" goes from vtools_vpatch, which is in
the keccak line,
to vdiff_sha_fixes, which is in
the other line (sha line).
mod6: *these were removed in
the "ante_check" subroutine
mod6: this was removed in
the "ante_check"
mod6: these vpatches are
thrown out as
they fail a previous check.
mod6: it isn't in
the flow.
that's
the problem.
mircea_popescu: death("HEAD: $press[1] not found in flow\n") if !grep /^$press[1]$/, @flow <<
this specifically. how can it fail if it lists
the item in flow ?
mod6: im done with
this
thing.
mod6: someone else now needs
to step up and write a V.
mod6: i don't
think im
the right person for
this.
mircea_popescu: well
the hope is
that eventually we iron out all
the edges...
mircea_popescu: mod6 but specifically as
to
the point, can you see why v.pl spits out
that error message
there ? am i right in reading
the script as "if
the file is not found by name" ?
mod6: so
tired of fucking with v.
mod6: this is why i don't want
to write
this
thing any more.
mircea_popescu: i still don't know why
they don't ; but as far as i can see
there isn't an actual problem with his patches or seals.
mod6: this violates rules
that we've previously put in place
then.
mircea_popescu: as long as
the patches don't collide, ie, have
the same hash ; and as long as
they're properly chained and signed
they should press.
mod6: oh, im specifically
talking about
the patch set from your latest post.
mircea_popescu: mod6 no, listen, i don't see what
the problem you see is. so a number of different patches, which are
themselves distinct, nevertheless depend on
the same version of a file (here, xaloc).
this isn't, nor can be a problem ; and was not a prtoblem before, either.
phf: mod6:
this might've been encountered before, but i'm
talking about
the vtools patchset
that was
there before regrind
mod6: then both vdiff_sha_static.vpatch and vtools_fixes_static_tohex.vpatch
try
to use
the same input.
douchebag: Hey is it cool if I invite a friend in here, he's a pretty good chatter and he's a
technical dude
mod6: here's where
two vpatches have
the same outputs for 'xalloc.h'
mod6: but
this
time, i dunno wtf is going on here. it's a mess.
mod6: phf: i
thought last
time we encountered a problem like
this we dropped out a vpatch,
then it was fine.
mircea_popescu is
thoroughly confused
through
the working of his own ineptitude, will need a moment
to extract self.
a111: Logged on 2018-04-09 05:23 mod6:
this is different
than what i'm saying.
the
two distinct vpatches, 'vdiff_sha_fixes_newline_gcc.vpatch' and 'vdiff_fixes_newline_gcc.vpatch', contain
the same output, '98ba7212fafa4a61f6d6096f1a2953a67a70fcf185965ed7199a223f6897c9b9f2996d391a3f363282236889413973d0beada0e36d57068549bea672fd110d8d'
mod6: 'vtools_fixes_static_tohex.vpatch' is not
the only one
to be dropped out, so is 'vdiff_sha_static.vpatch'; i didn't notice on
the first pass.
mod6: this is different
than what i'm saying.
the
two distinct vpatches, 'vdiff_sha_fixes_newline_gcc.vpatch' and 'vdiff_fixes_newline_gcc.vpatch', contain
the same output, '98ba7212fafa4a61f6d6096f1a2953a67a70fcf185965ed7199a223f6897c9b9f2996d391a3f363282236889413973d0beada0e36d57068549bea672fd110d8d'
☟︎ mircea_popescu: mod6 well i dun see how we can have collisions and live. i can't even understand how
the fuck
this was possible,
two patches with DIFFERENT antecedents hash-colliding ?!
mod6: i'd have
to fully debug
the problem here, im only showing
the symptoms here.
mod6: and a good question, is
this a problem for 'theory of v' ?
mod6: <+mircea_popescu> oh,
they don't,
they just have
the same antecedent. why is
this a problem ? << im not sure at
this point. could be an edge case im not catching, or could be buried in old rules built into my v.
mod6: 'vdiff_sha_fixes_newline_gcc.vpatch' and 'vdiff_fixes_newline_gcc.vpatch' indeed have
the same output hash.
mircea_popescu: 99994 and 99993 correctly press past
this split, you're aware.
mircea_popescu: oh,
they don't,
they just have
the same antecedent. why is
this a problem ?
mircea_popescu: mod6 how
the heck can both sha fixes and fixes newline have
the same hash
mod6: I'm not sure how
to reconsile
this. If you have a different v
tool
that will help you work around
this, by all means.
mod6: one will notice
that
these antecedent origins are from
two separate press-paths.
mod6: 6) We're not missing an antecedent vpatch; however, '98ba7212fafa4a61f6d6096f1a2953a67a70fcf185965ed7199a223f6897c9b9f2996d391a3f363282236889413973d0beada0e36d57068549bea672fd110d8d' matches
two antecedents
mod6: 5) Check
the origins of
the antecedent hashes in 'vtools_fixes_static_tohex.vpatch'
to see if we're missing one.
mod6: 4) Check
the press paths --
there are ~two~ (phf said
this was experimental previously)
mod6: 3) Check
the flow, see
that vtools_fixes_static_tohex.vpatch is not in
the flow, and check
to ensure
that
the seal verifies, and it dows
☟︎ mod6: 2) Once I have all
the files, I put
them in
the proper place.
Then grab
the latest V (99993) and verify
that it's correct.
mod6: and i've found
the issue.