log☇︎
13500+ entries in 0.026s
mod6: i'll prepare them in this way, and re-discuss when i have 'em. probably in a day or two.
mod6: <+mircea_popescu> no good with the "reference" the thing, because you can get the thing without the reference, see ? << very much agree.
mod6: which, was my first trial. the only thing about this approach is that then to extract (uudecode), one must strip out the clearsigning text as well as the comment. not horrible, just an extra step.
mod6: <+mircea_popescu> mod6 how do you add comment with armor ? << yeah, there'd be no comment in the gpg armor'd artifacts. this would only be possible with using the uuencoded archives, placing a comment in the top, and then clearsigning the whole thing.
mod6: Think that sounds ok?
mod6: So was thinking, make these four as deeds, then create a follow on deed that is a disclaimer that references the four artifact deeds - stating that the archive extracted will have the following hashes and that my signature doesn't declare that I have written or read the code. Something to that effect.
mod6: For instance, here's trinque's results: http://wotpaste.cascadianhacker.com/pastes/ee51a593-445a-4cfe-98bc-093f47ae8310/?raw=true
mod6: I had shinohai and trinque both check my signed files and they confirm that it looks good (i tested on a variety of env's myself)
mod6: it turns out that the base64 encodings are ~5-10k bytes larger, it's pretty close, but it's nice with the `gpg --armor --sign` since you can verify and extract all in one step.
mod6: 2. used `gpg --armor --sign`
mod6: 1. made base64 encodings with `uuencode -m`
mod6: So tried out a few different things with signing the artifacts:
mod6: <+shinohai> ;;later tell mod6 experiment was successful << oh hey! didn't see this before. thanks!
mod6: oh hey, interesting log read this am.
mod6: btw, this is awesome: http://trilema.com/wp-content/uploads/2016/07/views-through-a-lens-1.jpg
mod6: yeah, bitotter stuff is still laying around.
mod6: i've got a few irons in the fire currently... but let's revisit this in a week or two after I get some more work done with the build stuff.
mod6: maybe i'll make a new one?
mod6: i miss the ticker
mod6: 1`120 of s.mg traded
mod6: asciilifeform: lol nice
mod6: that would drive me crazy.
mod6: heheh
mod6: <+shinohai> It's like a colossal shit that won't flush. << haha
mod6: must have forgotten to do that last month
mod6: i added a link to the tickets dir on the foundation website.
mod6: haha. at a bbq
mod6: how goes it shinohai
mod6: ;;bc,stats
mod6: by 'you', i mean me.
mod6: kinda weird reading stuff you wrote 3 years ago. :]
mod6: http://trilema.com/2013/do-you-know-who-knows-everything-about-power-bitcoin-people/
mod6: bah
mod6: random roll on trilema landed me ohttp://trilema.com/2013/do-you-know-who-knows-everything-about-power-bitcoin-people/
mod6: ya me too
mod6: how goes?
mod6: mornin' o/
mod6: haha
mod6: <shinohai> http://btcbase.org/log/2016-07-14#1502771 <<< remember i told you i did a test rum where i replaced V's mirror w/ mlocalhost deps and it still builds as expected. << oh yeah, forgot about that! ☝︎
mod6: werd up
mod6: weird. i'll have to look into that.
mod6: %p trb 12
mod6: dafaq
mod6: %p trb 12
mod6: %e trb 12 F "Makefiles for building full orchastra" "http://btcbase.org/log/2016-07-14#1502667" ☝︎
mod6: %p trb 12
mod6: %h
mod6: Anyway, this is great! I aught to write this up and put this into the ticket notes.
mod6: 'tis been a while.
mod6: got it.
mod6: oh thats right, it just expected you to do this manually. which i automated.
mod6: or rotor? i'd have to look.
mod6: asciilifeform: i believe that perhaps your stator script did something of the like.
mod6: Thanks for both of your input this evening.
mod6: fair enough, Sir.
mod6: asciilifeform: agreed?
mod6: To me, this seems to satisfy the requirements we've been kicking around for a while.
mod6: Then it'll continue with Mr. P.'s perscription above.
mod6: Yeah, the makefiles will do this. It'll check the "shit" folder and what not, and look. If there continue, if not, halt. UNLESS, the -go-get-the-shit flag is passed in the invocation.
mod6: So i feel like it's one or the other. People need a way to press one button and build -- not everyone is clued.
mod6: I tend to agree with you -- but i believe that the entire thing reduces to a "downloader script" outside of V if I remove the mirrors part.
mod6: Yes, you believe that one should read and verify these vpatches on their own, place them in by what they say, and who wrote them. Instead of getting a big ball of wax automatically.
mod6: A compromise.
mod6: As far as the "V Mirror" thing, that I know alf hates, I move forward on the basis that one doesn't have to use it, even though it is there. This may not be ideal, but it's bridge between both "easy" and "manual" ☟︎☟︎☟︎
mod6: I do tend to favor that, as opposed to signing my own death warrant.
mod6: mechanically checked and verified, but something i wrestle with none the less.
mod6: its the difference between "easy" and "manual".
mod6: i can see this both ways too. i still wrestle with the whole "V Mirror" thing too.
mod6: I tend to agree, overall though. It should belong with trb.
mod6: Anyway, got some time to mull it over. :]
mod6: I started there for sure. Once I actually did this, it works, no problem with that. Was just trying to think, "what will the tree look like in 10 years, 20 years?"
mod6: true, not actual cruft no, just changes.
mod6: The thing is, they /are/ really a part of trb itself.
mod6: The one staring me in the face is this: If we place them in trb's tree, we'll be adding vpatch after vpatch to the source base to update the makefiles as they require to be updated. Having them in their own tree could elimiate cruft in trb.
mod6: this really leaves one last question that has to be thought through before we move on; Do we place the makefiles into trb's tree, or do we place them in their own tree? I've thought about this quite a bit. And there are tradeoffs to both.
mod6: and the makefiles are complete.
mod6: let's fast-forward for a minute and pretend that your solution is implemented.
mod6: building up tons of technical debt that I (or someone) has to fix eventually anyway.
mod6: which isn't a bad thing; i'd rather do it slow & careful, than fast and reckless.
mod6: it is. slowly, but surely.
mod6: it'll be nice to be able to move forward from this part.
mod6: it really has been like herding cats to get all of the build infrastructure into place.
mod6: <+mircea_popescu> at least this'd allow some basis for proper management of this mess, rather than current adhocness << the nice part about the makefiles and your preposed solution is that we would finally have a solution in place for all of this.
mod6: So hopefully that'll be just fine.
mod6: <+mircea_popescu> mod6 specifically, iirc it's tens of mb not gb. amirite ? << Yes, Sir.
mod6: 52M boost_1_52_0.tar.bz2
mod6: $ du -sh boost_1_52_0.tar.bz2
mod6: 71M boost_1_52_0.tar.bz2.base64
mod6: $ du -sh boost_1_52_0.tar.bz2.base64
mod6: 954767 boost_1_52_0.tar.bz2.base64
mod6: $ wc -l boost_1_52_0.tar.bz2.base64
mod6: sure, lemme see here...
mod6: mircea_popescu: thanks for your input here, its high time that we get away from the adhoc nature of this build process.
mod6: trinque: is there a max length for deeds? (just curious about the above ^, some of these might be mightly large) ☟︎
mod6: for the buildscript and the makefiles. so that makes sense.
mod6: Yeah, it certainly has to be there.
mod6: Ok, so .wot directory is required here.
mod6: Or not, and they place the deps in there by hand, on their own. Then continue building.
mod6: a person wants to build, presumably with the makefiles, but could be a build script... they pass the builder a flag that says "get these deps for me automatically", at which time, it'll go and fetch the deed(s) and verify them, decode them, and place them in the correct place and continue building. ☟︎
mod6: we make base64 encodings of the artifacts. we deedbot those, they are signed.