log
497 entries in 0.494s
asciilifeform: and the orig 'rotor', i baked for tbf, and from it we have the musl thing, etc
asciilifeform: mod6: http://edgecase.net/articles/2017-11-25_edgecase_datafeed_article_21_2017-11-25_stjohn_piano_compiling_bitcoind_trb_054_on_debian_711/rotor.tar.gz.asc , http://edgecase.net/articles/2017-11-25_edgecase_datafeed_article_21_2017-11-25_stjohn_piano_compiling_bitcoind_trb_054_on_debian_711/programmable-versionstring.vpatch , buncha others
a111: 493 results for "rotor", http://btcbase.org/log-search?q=rotor
asciilifeform: !#s rotor
asciilifeform: ( i.e. the old 'rotor'-on-conventional-linux process will finally be obsoleted )
a111: Logged on 2018-07-05 17:59 diana_coman: asciilifeform, I get it: clone of dulap is pointless because it requires rotor-style which can be equally done on existing server; but we are talking of having a box with trinque's musltronic proto-cuntoo
asciilifeform: phf: only on a system where the systemwide crapola is traditional (glibc) and your musl item is a homedir-local build, a la rotor.
asciilifeform: it's a musltronic build, like rotor. so it builds absolutely errything that is needed for a working static elf-outputting gnat.
asciilifeform: phf: ave1's recent breakthrough was specifically this -- a rotor-style cross-compile process that takes an existing amd64 gnat, and builds a particular other gnat for whatever arch
diana_coman: asciilifeform, I get it: clone of dulap is pointless because it requires rotor-style which can be equally done on existing server; but we are talking of having a box with trinque's musltronic proto-cuntoo
a111: Logged on 2018-06-21 12:34 asciilifeform: http://btcbase.org/log/2018-06-21#1827977 << 're-emerge' seems to imply systemwide ? you're more or less guaranteed a borked box, muslism has to be done either rotor-style (i.e. 100% user-local build of 1 proggy at a time) or systemwide ( trinque's cuntoo ), on account of the impossibility of cleanly linking glibc libs to musl proggy or vice versa
asciilifeform: diana_coman: you are aware that the only means of testing a musltronic build of your proggy + deps on a conventional (glibc) box, is the rotor method, yes
diana_coman: from the other side: why would rotor-style be a better option than using trinque's script above?
asciilifeform: the only way to muslate on a conventional (glibc) box, is via the rotor method.
asciilifeform: diana_coman: if this were my system, i'd build'em rotor-style ( using existing rotor script, add e.g. mysql to the deps set )
asciilifeform: i abolished it in trb ( rotor ) , ave1 -- for gnat, and really ought to end with the logical conclusion, standard cuntoo musl/headers/gcc.
asciilifeform: generally speaking unless one or moar of your deps is weird in the 'emacs' way (i.e. does something obscene with glibc-specific pheatures) it's a straight mechanical job, like rotor.
diana_coman: well, either there is cuntoo and then can try with it or there isn't, in which no choice apparently other than rotor buildroot style
asciilifeform: mod6 is the one who 100% automated asciilifeform's rotor builder; you may want to use his model, ~iff~ waiting for cuntoo is not permissible
asciilifeform: diana_coman: hence why i said 'rotor buildroot env'
asciilifeform: diana_coman: if you were making simply a musltronic version of euloratron, it could be done rotor-style (buildroot env) . but sounds like you want cuntoo straight away.
asciilifeform: http://btcbase.org/log/2018-06-21#1827977 << 're-emerge' seems to imply systemwide ? you're more or less guaranteed a borked box, muslism has to be done either rotor-style (i.e. 100% user-local build of 1 proggy at a time) or systemwide ( trinque's cuntoo ), on account of the impossibility of cleanly linking glibc libs to musl proggy or vice versa☝︎
asciilifeform: just like in earlier rotor-trb.
asciilifeform: diana_coman: you don't need cuntoo to build musl executables, ave1's gnat does this on an ~arbitrary linux. ( via similar method as the 2015 'rotor' item )
ben_vulpes: you can get the fine control with mechanical rotor pitch variation as well.
ben_vulpes: in other usg idiocies, i recently found a dood who achieved the not-insignificant feat of a constant propspeed belt-drive GAS ENGINE QUADCOPTER butbutbut the rotor pitch variation mechanism RUNS OVER WIFI
mircea_popescu: http://btcbase.org/log/2018-05-08#1811085 << minigame would host it ; so would deedbot. you saw the trb build style, specifically http://thebitcoin.foundation/trb-howto.html (the parts where it goes 'curl http://deedbot.org/deed-430460-2.txt > rotor.tar.gz.asc')☝︎
mod6: make -f Makefile.rotor bitcoind
mod6: make -f Makefile.rotor bitcoind
mod6: make -f Makefile.rotor bitcoind
mod6: make -f Makefile.rotor bitcoind
asciilifeform: http://btcbase.org/log/2018-01-21#1773685 << if this is about the 'integer retardation' issue, the 1 thing it quite definitively had 0 to do with , is gcc5 : which did not exist in the era of 0.5.3 , nor did it exist in my stator or rotor setups☝︎
shinohai: tfw sifting through old trb stuff and you find "rotor-db-configure-fix.patch"
a111: Logged on 2016-06-06 21:37 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
mircea_popescu: ben_vulpes ride the rotor train all the way to there then have it build whatever it is you're building.
asciilifeform: it's part of the rotor flow, gotta be there
asciilifeform: ideally you'd have the rotor attached to the drive shaft; by default stator is disconnected. when you want to turn the auto into generator, you put the thing in neutral, undo the clutch, and put on gas (ideally has 'cruise control' throttle)
phf: for extra lulz if you call "make" from src you're going to run rotor build, but if you want to run "legacy" build system you do make -f makefile.unix
phf: but i don't think that's the one he's using, if he's building with rotor.. that whole new build infrastructure seems to exist apart.
asciilifeform: the buildroot (aka 'rotor') thing is a dour wartime expedient, in case anyone forgot -- if we had a musltronic linux, or a bsd (i.e. non-glibc os) it would be unnecessary
asciilifeform attempts a build of traditional stator trb inside netbsd ( as rotor is unnecessary there, there is no drepper glibc )
asciilifeform: ( would be a pretty great engine if somehow rotor were coupled ONLY magnetically to outside, and in fact part of a generator )
asciilifeform: rotor needs : gcc (all versions tested to date, afaik, worked) and userland utils
trinque: what does rotor need
asciilifeform: mircea_popescu: it's a fairly obvious extension of 'rotor'
a111: 449 results for "rotor", http://btcbase.org/log-search?q=rotor
asciilifeform: !#s rotor
mircea_popescu: that build happened in ~/trb/rotor/TEST2 etc
asciilifeform: mojaheds in afghan for some reason preferred to use things other than buckshot. but is interesting to contemplate theoretically - given dispersion, how many shotgun rounds would you have to fire, from, say, 500 metres, to hit rotor.
mircea_popescu: anyway. asciilifeform is actually aware quadcopter rotors can't handle as much as a blade of grass, imagines 2 ton heli rotor can handle buckshot ?
asciilifeform: mircea_popescu: which gave us rotor etc.
asciilifeform: with that in mind, neither 'rotor', nor fuckgoats, nor phuctor, would exist if asciilifeform had not been able to do ~10,000 google searches.
asciilifeform: buildroot, at least as seen in 'rotor', is not necessary on bsd!! there is no glibc there !! afaik static linking works normally on known bsd
trinque: ftr I put that comment there. used to be that rotor lacked a -e and so would pass over the boost failing targets silently. while we don't use them, the `|| true` certainly has to go
asciilifeform: you could use trb-rotor almost as-is, if you went to this.
asciilifeform: as of rotor.
mod6: <+asciilifeform> http://btcbase.org/log/2016-09-24#1548016 << this is very spiffy and finally obsoletes the ad-hoc thing i've been using since rotor 1 - finally i can use mod6's script. will test later this weekend. << hey thanks! let us know how it goes.☝︎
asciilifeform: http://btcbase.org/log/2016-09-24#1548016 << this is very spiffy and finally obsoletes the ad-hoc thing i've been using since rotor 1 - finally i can use mod6's script. will test later this weekend.☝︎
mod6: I kinda felt like placing things like 'rotor' in 'shit'.
mod6: One of the last changes I made was to rid the 'shit' directory, and just use one directory; 'deps'. At which point the rotor & rotor patch were deedified.
asciilifeform: trinque: if i had a working mussolinic gentoo, i'd never have cooked up 'rotor'
mod6: !!deed http://mod6.net/deeds/rotor.tar.gz.asc
mod6: !!deed http://mod6.net/deeds/rotor-db-configure-fix.patch.asc
asciilifeform: http://btcbase.org/log/2016-09-13#1540902 << if mircea_popescu built a rotor, he has same STATIC musltronic binary as other people with his patchset. which includes malloc etc.☝︎
asciilifeform: mod6: see my original rotor makefile. it chdirs to the dep dirs, makes there, etc.
mod6: Actually, I forgot, trinque already did that part. Makefile.rotor exists.
mod6: so, im not 100% off the top of my head, but getting rid of the two rotor build script and integrating that portion into our makefiles ~might~ resolve at least part of the source redundancy issue.
a111: Logged on 2016-09-09 00:28 mod6: oh, if you're saying that the rotor is no longer needed, i can agree with that. to an extent anyway.
mod6: the two .sh scripts you have in there can be integrated into the makefiles directly i think. however, we'll still need the openssl-004-musl-termios.patch and rotor_buildroot_dot_config
mod6: oh, if you're saying that the rotor is no longer needed, i can agree with that. to an extent anyway.
asciilifeform: http://btcbase.org/log/2016-09-08#1537788 << at one time rotor was not the only builder, and so i cut'em off☝︎
mod6: The problem is here, that when you run `make`, it'll build everthing under: build/rotor/TEST2/bitcoin/src despite the fact that the source is really under src/
asciilifeform: incidentally (and i have nfi whether this is obvious to people) the buildroot portion of rotor, the gcc build, etc. will be quite unnecessary on a box that is running a properly musltronic build built thereby already.
asciilifeform: (e.g., armtronic, full-orchestra - yes. but not rotor per se)
asciilifeform: i dun recall rotor needing such.
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