18600+ entries in 0.023s
mod6: yeah, otherwise `sha512sum` returns "No such file found".
mod6: so the ones that it /does/ skip is when 'b' == 'false' -- where the file was ~removed~ from a given vpatch.
mod6: looks like it did what it was supposed to do.
mod6: anyway, yeah, will still test that.
mod6: and if a new file is introduced the 'a' should be 'false' and the 'b' will be some sha512 hash, and will still be verifyable. correct?
mod6: <+asciilifeform> mod6: have you tested it with 'false' entries? (files which were newly created) << this is a good test. it should just do what its supposed to do 'as is' I think? this line will grab the 'b' of the vdiff; my $file_hash = $vp_map{$vp}{$src_file_name}{b};
mod6: I think this is pretty much what we want. I'll start writing some automated tests for this.
mod6: then if everything passes, etc, will publish a new version [v99996]
mod6: it's not fully tested yet -- tomorrow I'll pass the testable version around and some people can give it a try.
mod6: ok I have made some additions, and this is what I've come up with:
mod6: will check after each and die if not valid.
☟︎ mod6: <+mircea_popescu> if you check "at the end" now you have state. << do we want this?
mod6: i suppose i can just 'die' if one doesn't verify after each vpatch pressed. maybe that makes better sense.
mod6: if we wait until the end, we'll save some cycles -- and mathematically the hashes wouldn't come out right if somehow the files were diddled inbetween. but I can see some merit in checking after each patch is pressed.
mod6: s/vpressed/pressed/
mod6: asciilifeform et. al. V question: Should I verify the hashes after all patches are vpressed, or after each pressed vpatch in the topological order?
☟︎☟︎ mod6: <+mircea_popescu> i suppose should prolly call it fleet in being for historical reasons, but anywya. << gotcha
mod6: <+mircea_popescu> anyone in the foundation leadership familiar with the military strategy concept ? ben_vulpes mod6 ? << not in a very formal sense.
mod6: asciilifeform: ok, so add the ability to check the hash of the output file (post press) against 'b' in the vpatch?
mod6: if it does, I may have overlooked that somehow.
mod6: at least mine doesn't.
mod6: so no, it does not verify them.
mod6: <+asciilifeform> ;;later tell mod6 does yours (or anybody else's) 'v' verify the hashes ? << mine uses the vpatch hashes to build the dep map
☟︎ mod6: <+asciilifeform> incidentally, anybody ever succeed in getting a ~heap dump~ of a running trb ? << thanks.
mod6: <+jurov> mod6 asciilifeform yes putting it together but it needs good writeup << awesome, thx.
mod6: <+asciilifeform> might help if jurov actually posted his methods << yes, please do. you're doing good work, many thanks.
mod6: IPs on wiki.bitcoin-assets.com/the_real_bitcoin/nodes are up-to-date right?
mod6: thx for the heads up
mod6: TheNewDeal: hey, thanks!
mod6: <+jurov> which version is the -TEST2? asciilifeform_add_verifyall_option? << yeah.
mod6: it'll just need some very deep examination and testing one way or another.
mod6: true. this is a good point.
mod6: yeah getting rid of openssl is going to be, an adventure. not only does the crypto need to be implemented, a perfect backward compatibility needs to be maintained.
mod6: im of the persuasion that bitcoin should get it's own OS, eventually, when it can be built.
mod6: in the short term, is there a way to maybe do this better that I'm missing?
mod6: many wheels to reinvent.
mod6: it's a tough pill to swallow to sign & rely on such garbage
mod6: i do see what you're saying in a sense I think.
mod6: i have one more bridge to cross yet, and I havent gotten that far yet; having a script of my own somehow check the sigs & hashes after the file xfrs are complete.
mod6: i think it'll work though. my rotor+v054 script would run this script after extracting the buildroot package
mod6: im not sure this is the best way to handle this
mod6: so what I'm hoping to accomplish here is to alter the .mk files that accompany buildroot, so they pull the 3rd party reqs directly from the foundation site instead of wherever they currently point to.
☟︎ mod6: (this by no means is finished, but interested to see what you think about the direction i'm taking)
mod6: you wanna see my script I'm workin on?
mod6: we're getting close.
mod6: anyway, yeah, I'm looking forward to getting the website cleaned up and putting V up there with vpatches.
mod6: Thanks for the reminder though.
mod6: <ascii_field> trb www still shows non-v patches ?! << ok so no, not yet. after ben and I sign everything for the release, we'll be updating the website.
mod6: ok. let's see here...
mod6: <+mircea_popescu> mod6 perhaps an announcement that the bitcoin foundation maintains and will continue to maintain a real bitcoin client, notwithstanding continued attacks from well known usg agents on the core values of sound money ? << sounds good, will write something up by EOD.
mod6: looking forward to that.
mod6: hoping to test it with the required packages in a test dir on the foundation site this weekend.
mod6: got a fair chunk of a script to alter the buildroot .mk files working.
mod6: could have been longer even. can't remember. *blush*
mod6: Hey, took one guy a whole day to figure out the recipes go in the mind slot :D << lol!
mod6: WARNING: no hash file for linux-3.18.14.tar.xz << ah, found this in that `script` log.
mod6: good thoughts. i appreciate it.
mod6: further, if bitcoin does indeed get it's own os, we may not need to worry about busybox... but until then (which could be a while), yeah.
mod6: yeah, we can certainly do that. i still sort of feel like bitcoin is going to get it's own OS.
mod6: So the current plan, subject to change, is that I'll get these packages, create a web-repository of them with clearsigned hash files and signature files that can and should be mirrored.
mod6: so just keep/maintain a repository of these packages