log☇︎
522 entries in 0.657s
asciilifeform: in other historic lulz, 'In May 1967, "Co$t of Living's" M24-A 20mm cannon vibrated loose causing the weapon to rotate upward and fire into the forward rotor system. The blades separated and the aircraft tumbled to the ground killing all eight crewmembers on board. Then in February 1968, "Birth Control" suffered the destiny of her sisters. "Birth Control" received some bad hits from a gun run and had to auto-rotate into dry rice padd
mod6: So, yeah, added in the pull of the deeds, the checking of the sigs, uudecoded, and checked the output hashes. not just on the craptastic four; also put in explicit sig checking on the rotor and V.
mod6: or rotor? i'd have to look.
asciilifeform: pretty sure i signed a set of rotor dep hashes a while back.
asciilifeform: possibly a properly-built rotor will give same turdwise output on all boxes.
asciilifeform: http://btcbase.org/log/2016-07-09#1500503 << rotor builds armv5 binary and it is THREE MOTHERFUCKING LINES to change in the build script WTF11111 ☝︎
asciilifeform: use rotor.
asciilifeform: i find it also very interesting that all aes-like ('boxes') cryptosystems are direct descendants of rotor machines. which were known to be pseudoscientific even when first built, as vernam existed ☟︎
asciilifeform: which will need to be fed with correctly-tuned rotor kernel etc.
asciilifeform: http://btcbase.org/log/2016-05-25#1471951 << pretty sure current rotor builds just about anywhere ☝︎
phf: j-dawg: btcbase secretly tracks btcbase itself, since i'm experimenting with (load-v "foo.vpatch") type thing, but that's not public. i don't think there's a proper vtronic chain of V or rotor available, so unless i generate those myself there's nothing i can track
j-dawg: phf: btcbase.org doesn't track V itself or rotor?
asciilifeform: mircea_popescu: rotor takes you from bare metal (currently x86 and arm but potentially vax or whatever) to bitcoin.
phf: hmmm rotor script actually uses 4.9, for some reason i though it was frozen around 4.2-4.3 but maybe i'm confusing it with eulora
asciilifeform: (rotor invokes boost's jam thing but trb, recall, builds with ordinary gnumake)
asciilifeform: recently i contemplated doing a rotor port to a chinese tv box, 1G of ram, available for ~30 usd in qty. infinite. but when the fuck would i do this, a student ought to do this
assbot: Logged on 02-03-2016 03:20:58; mod6: http://log.bitcoin-assets.com/?date=01-03-2016#1418803 << i usually just modify the rotor script so that it just builds bitcoind with all of the necessary environment vars set, but comment out the building of BDB/SSL/Boost. The re-compile usually takes a few minutes. Not more than say 15.
assbot: Logged on 02-03-2016 03:20:58; mod6: http://log.bitcoin-assets.com/?date=01-03-2016#1418803 << i usually just modify the rotor script so that it just builds bitcoind with all of the necessary environment vars set, but comment out the building of BDB/SSL/Boost. The re-compile usually takes a few minutes. Not more than say 15.
ben_vulpes: mod6: this is 'rotor_bitcoin_only.sh' in the rotor tarball
mod6: or the rotor script?
mod6: http://log.bitcoin-assets.com/?date=01-03-2016#1418803 << i usually just modify the rotor script so that it just builds bitcoind with all of the necessary environment vars set, but comment out the building of BDB/SSL/Boost. The re-compile usually takes a few minutes. Not more than say 15. ☝︎☟︎☟︎
asciilifeform: as showcased in, e.g., rotor, etc.
asciilifeform: now rotor is not ~quite~ as necessary on bsd, because drepper is absent there. BUT we still need deterministic nailed-down toolchain, esp. for when we finally do the deterministic binary thing.
asciilifeform: but no one, to date - rotor.
phf: asciilifeform: there's no rotor
asciilifeform: i don't recall a ~rotor~ trb working there.
asciilifeform: re: thread: ftr i still use my original rotor builder.
mod6: gernika: what happens if you're in the rotor dir and you do `gpg --verify buildroot-2015.05.tar.gz.sign` ?
gernika: mod6 I have that fine file in rotor :)
danielpbarron: regardless, the script ended with a bitcoind in rotor/TEST2/bitcoin/src/
shinohai: if you have a rotor dir and try to run script it fails.
asciilifeform: (rotor musl build)
mircea_popescu: ROTOR_HASH=e232c07238feb16ce055211fba68ed283c47753a8716681ac47c869c21936f48768f
mod6: when he built it, it ~should~ have included your original malleus patch, see: ./v.pl p verbose rotor/TEST2 asciilifeform_malleus_mikehearnificarum.vpatch
asciilifeform: rotor.
asciilifeform: try build 'rotor' on it, for shits&gigglez, see how many days it takes.
asciilifeform: (and to sell it through swiss catamite intermediaries to anyone who'd buy, after the last rotor finally gave up the ghost)
asciilifeform: and really belong in the rubbish bin with the enigma rotor etc.
mircea_popescu: mod6 what's the scriopt called ? the one that makes rotor.sh ?
mircea_popescu: the one that makes the rotor.
mod6: yeah, cause if you don't run the script, then you need to set up everything, including the rotor, buildroot & copying around the config, and tons of other stuff.
mod6: ./v.pl p v rotor/TEST2 asciilifeform_malleus_mikehearnificarum.vpatch
assbot: Logged on 30-01-2016 17:51:53; mod6: i do a lot of testing etc. often if I'm actually going to change a line of code, i'll press out a seperate branch call it 'foo', go in there copy a & b, then make changes in b. make a vpatch. drop it in my live bitcoin branch, rebuild with the rotor. bunch of stuff.
asciilifeform: ftr i still use my original rotor build scripts.
mod6: i do a lot of testing etc. often if I'm actually going to change a line of code, i'll press out a seperate branch call it 'foo', go in there copy a & b, then make changes in b. make a vpatch. drop it in my live bitcoin branch, rebuild with the rotor. bunch of stuff. ☟︎
mod6: <+ben_vulpes> mod6 and trinque as well << hacking the codebase? << I just build the statically linked bin with rotor via the build-bitcoind script that everyone uses.
punkman: mircea_popescu: http://log.bitcoin-assets.com/?date=30-01-2016#1389596 << so like a rotor reimplementation ? << more like some rotor automation to try various builds and lets you know what compiles or not ☝︎
mircea_popescu: http://log.bitcoin-assets.com/?date=30-01-2016#1389596 << so like a rotor reimplementation ? ☝︎
assbot: Logged on 30-01-2016 01:10:38; mod6: <+mircea_popescu> ftr mod6 : i ended up with two rotor.sh scripts, one under rotor the other under rotor/test2 << yeah, if all goes well, you should ~only~ need to just execute the build script -- if you have to execute either of the rotor.sh scripts, then something went wrong.
mircea_popescu: http://log.bitcoin-assets.com/?date=30-01-2016#1389541 << i did have to run the rotor by hand. ☝︎
mod6: <+trinque> http://log.bitcoin-assets.com//?date=24-01-2016#1384068 << I designed the makefiles to take a BUILDER variable, of which there is currently only rotor. ... << for now, as far as I'm concerned, this is totally ok. we'll have to worry about other *nix's after we perfect getting linux x86-64 done with a CD to boot also. ☝︎
trinque: http://log.bitcoin-assets.com//?date=24-01-2016#1384068 << I designed the makefiles to take a BUILDER variable, of which there is currently only rotor. perhaps this is the place to add an openbsd builder, which could apply unofficial patches as they are necessary after V press ☝︎
shinohai: I just nuked my entire rotor directory on build machine every time I am doing an update
mod6: <+mircea_popescu> ftr mod6 : i ended up with two rotor.sh scripts, one under rotor the other under rotor/test2 << yeah, if all goes well, you should ~only~ need to just execute the build script -- if you have to execute either of the rotor.sh scripts, then something went wrong. ☟︎
mod6: what's the cannonical makeclean, rm -rf * in /rotor ? << yeah, i would just blowaway the entire 'rotor' directory along with all the V stuff. the stuff that I would save is just the .wot dir, the keys contained therein, and of course, your ~/.gnupg stuff (ofc. have backups etc (this is for everyone who blew their keys away once)) : then totally restart the entire script.
mircea_popescu: ftr mod6 : i ended up with two rotor.sh scripts, one under rotor the other under rotor/test2
mircea_popescu: Saving to: “/home/bitcoin/rotor/buildroot-2015.05/output/build/.gcc-4.9.2.tar.bz2.GCAtsD/output”
mircea_popescu: what's the cannonical makeclean, rm -rf * in /rotor ?
pete_dushenski: y patches directory. should i just wait until it syncs fully and build another rotor (with line 61 updated) or is there something else i can try ?
mod6: # Required Public Keys to add to your PGP Keyring. These are used to verify V, rotor, buildroot, and trinque's patch:
mod6: # Required Public Keys to add to your PGP Keyring. This are used to verify V, rotor, buildroot, and trinque's patch:
mod6: kako: http://therealbitcoin.org/ml/btc-dev/attachments/20150808/rotor-db-configure-fix_a955ba9174ccb17790dc9d7c1e2a61794a1c803d.patch
mod6: ok folks, my build succeeded with the changes to moving V outside of the rotor directory.
mod6: ok the new script, having V outside of the rotor dir seems to be building just fine so far... will update again when its complete, or if fails.
mod6: and I think this is what we want. So we can stick with that, and probably not break anything -- i'll just move V & .wot outside of the rotor dir.
ascii_butugychag: this was a common complaint about my rotor system also, recall
mod6: ./v.pl p verbose rotor/TEST2 asciilifeform_malleus_mikehearnificarum.vpatch
mod6: if we have V source and .wot adjacent to rotor dir, then we could press like the following:
mircea_popescu: the way i see this is, script tries " mkdir -p rotor/.wot " , if it succeeds it says "wot dir created, populate and re-run please" ; if it fails it proceeds with build.
mod6: the only actual alternative here is to create .wot adjacent to rotor directory, along with the V source
mircea_popescu: mkdir -p rotor/.wot
mod6: ok. so if we create a .wot in /.../rotor/ (so, rotor/.wot), then it can not be populated by hand...
mod6: mkdir -p rotor/TEST2
mod6: mkdir -p rotor/toolchain
mod6: mkdir -p rotor
mod6: make note that V does not /expect/ or /default/ to a ~/.wot dir, it just so happens in this case, that it needs to be somewhere accessable outside of the rotor build path
mircea_popescu: the script ~must~ reference a .wot directory somewhere outside of the entire rotor build area. <<< wait wut ?!
mod6: One notable change to the build script linked on the wiki: Since we're pressing out V in a directory that gets created by the script, there is no way to have a .wot inside this dir that it can find -- the script ~must~ reference a .wot directory somewhere outside of the entire rotor build area.
mod6: 2: Can you `cat rotor/TEST2/bitcoin/src/db.cpp` and post it to dpaste or somewhere else I might be able to look at it?
mod6: TomServo: Hi, if you followed the instructions via the wiki, this means you should have built via rotor & V.
BingoBoingo: polarbeard: Did rotor eat your copy too?
phf: everything else in there is either cross platform clarification or straight up an #ifdef. it's a tiny ass patch, if it doesn't build on rotor, linux, etc. it's a bug in a patch
assbot: Logged on 24-01-2016 02:26:40; mod6: <+mircea_popescu> http://log.bitcoin-assets.com/?date=24-01-2016#1383446 << wait, explain this to me ? << the idea is that our makefiles, or whatever build scripts will utilize V to build inside of the rotor (a linux thing) - the source must be compatable with that. phf's openbsd scripts are not compatible with this.
mod6: eh, sorry: does the idea of a flashable universe built from rotor still make sense.
mod6: asciilifeform: so are we basically, with rotor, able to not only build a static bitcoind, but couldn't we also build a flashable rom that contains said static binary - a flashable universe so to speak?
mircea_popescu: phf you seriously considering maintaining a bsd rotor thing ?
mircea_popescu: right. so no, rotor doesn't "do this already".
mircea_popescu: so you bring up your *bsd box, run rotor on it, does it build or doesn't it.
asciilifeform: rotor will build on nintendo.
asciilifeform: rotor does this already
mod6: <+mircea_popescu> http://log.bitcoin-assets.com/?date=24-01-2016#1383446 << wait, explain this to me ? << the idea is that our makefiles, or whatever build scripts will utilize V to build inside of the rotor (a linux thing) - the source must be compatable with that. phf's openbsd scripts are not compatible with this. ☝︎☟︎
mod6: having an alternate to linux is important to me. and i was able to build a static binary, but obviously this doesn't work with the rotor (linux only buildroot). i did build it with the stator.
mircea_popescu: but still, Three phase, four pole AC induction motor with copper rotor << this thing is well over 10k at that power.
guruvan: there some more docs on the rotor script? this looks like the mojo I'm looking for for the simple docker "whip up a node for testing" builds
asciilifeform: the whole reason i did rotor was to thermonuke whatever dependencies there were on the crud on various people's boxes
ben_vulpes: did i hear that someone managed to get rotor to clobber their whole homedir?
assbot: Logged on 17-01-2016 20:54:44; mod6: instead, just pulled the source and built inside the rotor so it would be built with the gcc/musl that comes with buildroot
asciilifeform: http://log.bitcoin-assets.com/?date=17-01-2016#1374593 << mega-recommended approach. guaranteed to work unless something is SERIOUSLY broken with the WHOLE rotor. ☝︎
mod6: instead, just pulled the source and built inside the rotor so it would be built with the gcc/musl that comes with buildroot ☟︎
mod6: just needed to build gdb inside of the rotor, that i think was my problemo.