log☇︎
522 entries in 0.696s
mod6: CC='/mnt/btc-dev/rotor/toolchain/usr/bin/x86_64-therealbitcoin-linux-musl-gcc'
mircea_popescu: and rotor is mechanized comunion, strangely enough.
ascii_butugychag: http://log.bitcoin-assets.com/?date=11-01-2016#1366935 << and rotor is..? ☝︎
ascii_butugychag: (recall when we diffed rotor builds ??)
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 ? ☟︎
asciilifeform: i wrote 'rotor', which lets you build for nintendo if you like.
asciilifeform: actually rotor doesn't give a damn what you build on, so long as it is specified
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
asciilifeform: go compile rotor.
thestringpuller: rotor also blew up in my face on debian wheezy
asciilifeform: (locally, a la rotor, is another matter, and works great for its purpose)
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
asciilifeform: (the ~4MB elf we get from a rotor run)
trinque: so outermost makefile would do what this script is doing, then call a rotor makefile.
asciilifeform: and also 'rotor' is a generalization of it
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/
ascii_field: i'd name '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.
asciilifeform: (my rotor.sh would have been a standard makefile, but gnumake has problems invoking makes recursively)
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: polimedi@polimedia.us [~/trb/rotor]#
mircea_popescu: rotor.tar.gz.sig v_quick_start.txt.mod6.sig
mircea_popescu: rotor.tar.gz v_quick_start.txt*
mircea_popescu: right. so i now notice it made a rotor dir
mircea_popescu: anyway, rm -rf rotor and let's see this script
mircea_popescu: and fwiw i'm on rotor 99998 iirc.
asciilifeform: http://dpaste.com/2CNDJ6Y << my rotor.sh
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 ?
asciilifeform: ;;later tell mircea_popescu if you do musl rotor correctly, after stripping the elf you get a roughly 4M bin.
assbot: [BTC-dev] Rotor! ... ( http://bit.ly/1hbPG4Q )
assbot: [BTC-dev] Rotor! ... ( http://bit.ly/1InQxW4 )
mircea_popescu: does your rotor live anywhere ?
asciilifeform: mod6 had a set of instructions up for cooking rotor ab initio, but it apparently wasn't in the ml
asciilifeform: (rotor is a superset of stator that builds own compiler with - in my latest ver. - musl)
asciilifeform: for the rest, you need rotor or stator (your choice)
asciilifeform: all 3 of my currently operating trb nodes are using a rotor-on-musl build
asciilifeform: gentlement, please welcome (back) bucephalus: 216.15.33.203:8333 - a trb node, now running asciilifeform's bleeding-edge (on musl-rotor)
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)
asciilifeform: (rotor, if anyone forgets, is a static build from a locally-built gcc toolchain)
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: asciilifeform: i updated that rotor+V script: http://dpaste.com/15RZASM.txt
asciilifeform: (stator + rotor + misc.)
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.
assbot: 0 results for '/rotor/TEST2/ourlibs/lib/libboost_system.a: error adding symbols: File format not recognized' : http://s.b-a.link/?q=%2Frotor%2FTEST2%2Fourlibs%2Flib%2Flibboost_system.a%3A+error+adding+symbols%3A+File+format+not+recognized
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
thestringpuller: rotor pretty much builds the static on anything...
mod6: neat, just did an autobuild of rotor + TEST2 via V. build was successful, running and pulling blocks. :]
asciilifeform: it is not hard to make a musl-based linux; i have this working with rotor
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.
asciilifeform: and certainly will not build in rotor.
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.
ben_vulpes: did you successfully run your rotor?
funkenstein_: if I ever plan to rotor west
assbot: [BTC-dev] Rotor! ... ( http://bit.ly/1UxROR0 )