tmsr - Search: rotor

500+ entries in 0.393s

ossabot: Logged on 2020-02-17 18:32:47 dorion: I'll let him show and tell, his patch removes the whole rotor orchestra since Gales is musl static anyway.

dorion: I'll let him show and tell, his patch removes the whole rotor orchestra since Gales is musl static anyway.

dorion: 2. I modified the build/Makefile and build/Makefile.rotor to build the aarch64 toolchain, bdb and openssl.

dorion: 1. I used the buildroot menuconfig to produce a rotor_buildroot_aarch64_dot_config.

asciilifeform: re : honest 'virtual hosts' , and re asciilifeform's backlog of outputs to be published : i have a working kernel and userland for that mips emu . runs as buildroot, a la 'rotor' . will be featured in conveyor article.

asciilifeform: girlattorney: mod6's build system ( based on asciilifeform's earlier 2015 'rotor' (see logs) ) builds first a frozen-in-amber gcc & friends, ~then~ the depds (db etc) , ~then~ trb per se

asciilifeform: it makes sense now, you kept only skeleton from 'rotor'.

mod6: Otherwise, the 'rotor.sh' and 'rotor_bitcoin_only.sh' are not actually utilized. So we could cut those loose too, if desired.

mod6: I hope I'm not doing anything redundant really. The Makefiles itself take care of the compilation of Boost/BDB/OpenSSL. The one thing that I still need from the rotor.tar.gz is 'openssl-004-musl-termios.patch'

asciilifeform: interesting : this happens on ave1's gcc, but not orig rotor's ?!

asciilifeform: cuntoo, per my current understanding, obsoletes 'rotor' entirely (by doing same thing to ~entire system~ right off the bat)

asciilifeform: ( ... or didja substitute ave1's for rotor's ..? )

asciilifeform: mod6: plox to detail ( e.g. if on musltronic cuntoo, why needs 'rotor' system ? it existed only to build musltronic gcc 1st, and ~then~ trb, on heathen envirs , recall )

mod6: Evenin'. I've built trb on cuntoo with ave1's 20180924 tools, with rotor only. Quick test shows pulls connects, pulls blocks.

asciilifeform: trinque: i put it in its coffin in 2015, with 'rotor' , and wasn't even aware that there was contemplation of keeping it alive until mircea_popescu asked last mo

asciilifeform: mircea_popescu: recall the 9000 headaches of folx who tried to build pre-rotor trb ? asciilifeform did not resort to 'and now run this 4 hour script that builds a gcc, and then builds with it a gcc, and ~then~ builds deps, and ~then~ trb' just to make life moar interesting.

a111: Logged on 2019-01-31 02:14 asciilifeform: theoretically should produce ~same~ binary as the rotor build.

asciilifeform: where i got 'rotor' to build a bootable linux, with bare bones envir

a111: Logged on 2015-07-30 04:08 asciilifeform: but ~i personally~ will from now on support ~only~ rotor. and soon after, only rotolinux (buildroot for arbitrary arch that includes therealbitcoin and its deps, and toolchain to reconstruct self and the latter.)

asciilifeform: the orig 'rotor' thing was prompted by heathen gentoo having random crapolade instead of a sane compiler, libc, etc

asciilifeform: ( cuntoo per se, if you recall, is apprx a generalization of 'rotor' )

asciilifeform: theoretically should produce ~same~ binary as the rotor build. ☟︎

asciilifeform: mod6: the 1 obv change with cuntoo is that it dun need 'rotor' build process at all

asciilifeform: ( 'rotor' & descendants, on musl )

asciilifeform: ( given a musltronic cuntoo, the 'rotor'-descended buildroot process for trb is theoretically redundant )

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

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.