522 entries in 0.69s
mod6: CC='/mnt/btc-dev/
rotor/toolchain/usr/bin/x86_64-therealbitcoin-linux-musl-gcc'
mircea_popescu: how does v currently know where to connect to build the
rotor ?
assbot: Logged on 11-01-2016 15:37:56; mircea_popescu: jurov im thinking more like a
rotor script to build a local hosts out of, maybe, deedbotted things ?
mircea_popescu: jurov im thinking more like a
rotor script to build a local hosts out of, maybe, deedbotted things ?
☟︎ trinque: ben_vulpes: and in fact if the buildroot step were stuck inside Makefile.
rotor, it'd be trivial to have a Makefile.openbsd aside it
thestringpuller: i'm compiling on the same machine I'm running it on. did the whole stator+
rotor build here
trinque:
http://deedbot.org/trb-mk.tar.gz http://deedbot.org/trb-mk.tar.gz.asc << mod6, asciilifeform, ben_vulpes, et al., this thing has crapped a working trb enough times to get feedback. It's a set of makefiles for the former build script and
rotor. There are interesting knobs in the various makefiles, including (I think) an easy way to put other builders alongside
rotor (as asciilifeform mentioned). Lemme
assbot: Logged on 02-01-2016 04:57:20; thestringpuller: ugh all these expired keys is making it impossible to build
rotor with the old script
mod6: anyway, yeah, this is the build script that I created for testing the build of '
rotor', TEST2, and the static binary.
phf: i understand all that, and i was explaining that there's no conceptual integrity to it, as it stands. we have a .wot folder which is supposed to be a manually curated folder of <nick>.asc files. there were a few threads where mp and ascii argued that the folder should not be generated automatically (no sks or pre packaged tar files). so if one wants to build a
rotor they need a .wot folder with pubkeys of all the foundation
mod6: buiroot is not v-ifiable. so in the
rotor+TEST2 build script it was decided (in here) that we should check the hashes and the signatures.
thestringpuller: ugh all these expired keys is making it impossible to build
rotor with the old script
☟︎ mod6: alright cool. mind if I ask which
rotor+TEST2 script you're using?
mod6: pete_dushenski: are you trying to build
rotor+TEST2 on i686? (sorry, i'm kinda coming in the middle of this convo.)
assbot: Logged on 22-12-2015 04:58:44; mircea_popescu: anyway, for pete_d and anyone else who might have encountered difficulty with trb or fears they might : it's actually rather painless. 1. you create an account on a server ; 2. you cd /home/account_name ; 3. you create a .wot directory (mkdir .wot) ; 4. you put the pubkeys of people you trust in there as name1.asc, name2.asc etc ; 5. you download the
rotor script (curl deedbot.org/build-bitcoind-9999
trinque: so outermost makefile would do what this script is doing, then call a
rotor makefile.
ascii_field: about half of the 4MB
rotor bin is openssl crud
assbot: Logged on 23-12-2015 17:29:04; mircea_popescu: aaand in other news, the new
rotor has been mightily blackholed since last night (the usual array described here multiple times), it's got ~20k blocks through in a day or so.
mircea_popescu: aaand in other news, the new
rotor has been mightily blackholed since last night (the usual array described here multiple times), it's got ~20k blocks through in a day or so.
☟︎ mod6: <+jurov> oh it's going to be all unpacked there? << yeah, perhaps not. currently i extract & build all that stuff under '
rotor'. i guess shit should just be: <+jurov> "The shit: BDB, Boost, OpenSSL & the MANIFEST for turds" <- this stuff the turdballs and the manifest.
mod6: i think since that post, we talked about changing 'build' to '
rotor'. thoughts?
mod6: I guess we can place a small README in bitcoin/ that can direct peeps to
rotor dir.
trinque: why
rotor? is there going to be some other build system?
mod6: i'm sold on that. s/build/
rotor/
mod6: <+mircea_popescu> the manifest should live wherever the
rotor.sh lives neh ? << I would argue that all of these scripts would live outside of bitcoin source V tree.
mircea_popescu: the manifest should live wherever the
rotor.sh lives neh ?
mod6: the
rotor is out of the scope of that part.
mod6: <+mircea_popescu> my personal ideal would be that ALL directories involved in this without exception are spawned as subdirs of whatever current dir the script ran in. << this makes sense. right now you end up with /.../
rotor/ and ~/.wot, and ~/.seals iirc.
mod6: and the subsequent commands would just do something like `./v.pl p TEST2 vpatchnameforhead wd /.../
rotor/.wot` or something.
trinque: seems like the contents of
rotor.sh can easily be pasted into the bottom of the outermost script.
mod6: in the context of the script, it'd have to be altered in the script to say place the .wot in .../
rotor so you'd have /.../
rotor/.wot/
mod6: currently, what is required is that you execute the
rotor+V+TEST2 script that I wrote, and then it'll create a '
rotor' dir in that present working directory. then you'll end up with like:
rotor/TEST2/bitcoin/src/
mircea_popescu: mod6 could the default be that all dirs are made under whatever dir runs the
rotor script ?
mircea_popescu: ind-99997K.sh) and make it executable (chmod +x build-bitcoind-99997K.sh) and then you run it (./build-bitcoind-99997K.sh). that's pretty much it, takes half hour or so, spits out an executable bitcoind (in /
rotor/TEST2/bitcoin/src).
mircea_popescu: anyway, for pete_d and anyone else who might have encountered difficulty with trb or fears they might : it's actually rather painless. 1. you create an account on a server ; 2. you cd /home/account_name ; 3. you create a .wot directory (mkdir .wot) ; 4. you put the pubkeys of people you trust in there as name1.asc, name2.asc etc ; 5. you download the
rotor script (curl deedbot.org/build-bitcoind-99997K.sh > build-bitco
☟︎ mod6: I am following my exact instructions above ^^^ nearly done building a
rotor+V+TEST2.
mod6: Then if you take that paste, chmod +x it, run it, it /should/ pull down all of the deps (still not complete, grabs stuff over the web), pull down V, press a 'TEST2', then build
rotor, and then finally bitcoind inside of it.
mod6: Ok mircea_popescu asciilifeform ben_vulpes trinque : The latest version of my
rotor+V+TEST2 script is here:
http://dpaste.com/1R04312.txt : All you should need to do before hand is create a ~/.wot dir and add; "asciilifeform.asc", "mircea_popescu.asc", "mod6.asc", "ben_vulpes.asc", "trinque.asc", and "punkman.asc" into that directory.
mod6: <+asciilifeform> mod6 had a set of instructions up for cooking
rotor ab initio, but it apparently wasn't in the ml << no. it "works" as far as I and others have tried it -- it relies upon haveing my, alf's, mp's, ben's, and trinque's keys in a ~/.wot dir iirc.
trinque: it is running the
rotor/TEST2/
rotor.sh ...
trinque: yes, and after building the binary will be buried at
rotor/TEST2/bitcoin/src/bitcoind
mircea_popescu: ok, so i have /
rotor/stator/stator/distfiles/boost_1_52_0/ ; db-4.8.30/ ; openssl-1.0.1g/
mircea_popescu: asciilifeform "6) in it, set up a stator dir, e.g., /home/luser/
rotor/stator and fill distfiles with tarballs, etc. as before." << what the fuck do you think this means ?
assbot: Logged on 20-12-2015 00:17:11; asciilifeform: incidentally, gentlemen, please welcome (back) dulap! 46.166.165.30:8333 (nosuchlabs.com), a trb node running bleedingedge-asciilifeform+
rotor(musl)
mod6: i think it'll work though. my
rotor+v054 script would run this script after extracting the buildroot package
mod6: grep "_SITE"
rotor/buildroot-2015.05/package/gmp/gmp.mk
mod6: asciilifeform ascii_field: I've built '
rotor+TEST2' while logging output via `script`. I was able to capture all of the required deps from the log. The only thing that was missing from the list was the hash (easily remidied) for the linux-kernel. But it interestingly wasn't output like the others.
http://dpaste.com/2RWBT14.txt mod6: oh the
rotor+TEST2 script? Yeah, that needs to be updated.
mod6: Anyway, that's one major task still hanging out there. I'd like to get that done before we ``release''. Have all the required deps signed & hosted so that the
rotor-build script I've been passing around can be changed to pull the stuff directly from the foundation.
mod6: whaack: hi, yeah thanks for asking. 'v.pl' could certainly use some testing help. additionally, when I get my
rotor+v script finished (hopefully soon), will have that to test as well.
shinohai: !s /
rotor/TEST2/ourlibs/lib/libboost_system.a: error adding symbols: File format not recognized
mod6: oh the
rotor+V script for x86_64?
mod6: i do have a method (basically all automated) for one to build a static bitcoind via V inside of
rotor for a x86 i386/i686 env, but not for ARM :/
mod6: asciilifeform: so I basically built this script which builds a pressed v0.5.4 via my V implementation inside of
rotor mod6: neat, just did an autobuild of
rotor + TEST2 via V. build was successful, running and pulling blocks. :]
ascii_field: rather than a special-purpose item like
rotor BingoBoingo: <mircea_popescu> there's gotta be a complete bitcoin distro. kernel and all. << What,
rotor stopped making enough Linux?
mod6: shinohai: yeah sure, i'll get you all setup again with cukes,
rotor, V, etc.
jurov: so.. the ssd passed and the
rotor will have something to rotate
shinohai: and afaik
rotor doesn't use bitcoin-cli
VariaVarietatis: point me to how to test my
rotor is working? It seems to be able to getblockinfo but not getbalance using bitcoin-cli can't seem to find anything in the logs, mostly due to not knowing that to search for.