tmsr - Search: cuntoo

600+ entries in 0.043s

ossabot: Logged on 2019-10-13 17:00:39 asciilifeform: really folx oughta thrust, imho, into actual cuntoo, when this is practical, rather than to persist with asciilifeform's old piece

asciilifeform: but to revisit upstack -- i pulled this item off shelf to help diana_coman , who has legacy softs that are known not to work in cuntoo. and for own needs, because my attempts to bake a working cuntoo have failed ( and take ~day or so to even fire off, so difficult so far to debug . )

ossabot: Logged on 2019-10-13 17:00:20 asciilifeform: begins to suspect that he's making a 'cheap chinese cuntoo', maybe this is Wrong Thing

diana_coman: http://logs.ossasepia.com/log/trilema/2019-10-13#1945172 - asciilifeform , are you saying that you can do same with cuntoo directly?

asciilifeform: really folx oughta thrust, imho, into actual cuntoo, when this is practical, rather than to persist with asciilifeform's old piece

asciilifeform begins to suspect that he's making a 'cheap chinese cuntoo', maybe this is Wrong Thing

diana_coman: I suppose in the best-ideal-great path, I could say : map all dependencies and make the move to cuntoo but this is essentially taking on another mountain of work with unclear everything.

diana_coman: 3. for as long as CS esp is not yet *fully* excised out of the dev/test server, that might *also * need non-Cuntoo

diana_coman: 2. current production server will NOT run on cuntoo either, even if available (because still needs dynamic + CS & Cal3d that are iffy)

diana_coman: 1. we don't actually have a running and tested + everything needed Cuntoo yet

asciilifeform: imho The Right Thing there would be to build new array on dulap-spare , w/ cuntoo. ( naturally after crate flies )

trinque: the cuntoo experience really did some radiation damage to my patience for the oss stack.

snsabot: Logged on 2019-05-02 09:56:16 asciilifeform: http://btcbase.org/log/2019-05-02#1910633 << there's actually not 1 but 2 'standard os' available in piz ( 'rk' and 'dulap' tarballs ) but both are stone age gentoos, they are obsoleted by cuntoo (when the latter is pronounced baked, but really even nao, it is impossible to e.g. 'emerge' packages on the vintage gentoo, the upstream package repos went full tard year ago )

asciilifeform also 'pre-cuntoo cuntoo', and pc ver. of same ; with the assoc. headaches elaborately described in the log.

asciilifeform: was iirc a pre-cuntoo attempt to cuntoo. but unfortunately not publicly given in detail .

snsabot: Logged on 2019-08-30 05:30:10 diana_coman: http://logs.nosuchlabs.com/log/trilema/2019-08-29#1932144 - do you mean cuntoo or what exactly?

lobbes: http://logs.nosuchlabs.com/log/trilema/2019-08-30#1932170 << I mean cuntoo exactly. testbed is the exact iron in this post

snsabot: Logged on 2019-08-29 22:50:59 lobbes: http://logs.nosuchlabs.com/log/trilema/2019-08-29#1932021 << indeed, testbed on trinquean cuntoo. Yeah, did not encounter same horrors (besides the need for commenting out the cache thing)

diana_coman: http://logs.nosuchlabs.com/log/trilema/2019-08-29#1932144 - do you mean cuntoo or what exactly?

diana_coman: re logger atm I am undecided as my options so far seem to be: 1. do another round of madness with flask until it works on this old (but stable at least) centos 2. replicate environment aka burn down centos and have fun installing remotely on the machine cuntoo 3. simply run irssi (as I'm otherwise running this code anyway as my client) with logging to db into an mp-wp database and be done with it (possibly each line a one comment - will end

lobbes: http://logs.nosuchlabs.com/log/trilema/2019-08-29#1932021 << indeed, testbed on trinquean cuntoo. Yeah, did not encounter same horrors (besides the need for commenting out the cache thing)

asciilifeform: i was orig. planning to attempt a cuntoo for 'm' but then barfed

trinque: possible avenue of porting is to stand up an amd64 cuntoo, and then use crossdev to rebuild all ebuilds at a specified root dir

trinque: asciilifeform: I mean whether cuntoo is desirable as is.

lobbesbot: trinque: Sent 6 hours and 25 minutes ago: <asciilifeform> didja ever post a arm64 cuntoo ?

snsabot: Logged on 2019-08-29 15:27:44 asciilifeform: !Q later tell trinque didja ever post a arm64 cuntoo ?

lobbes: asciilifeform: my testbed box is a trinqueian cuntoo (see: http://blog.lobbesblog.com/2019/02/a-bridge-to-cuntoo-for-the-lenovo-x61-x86_64/)

asciilifeform: lobbes: yours is a traditional gentoo? or a trinqueian cuntoo ?

lobbes: man, while it was a learning curve at first, I'm loving Gentoo now. Making my x86 system on this server to work like my x86 cuntoo testbed is as simple as just copying over my USE flags and package masks

asciilifeform: !Q later tell trinque didja ever post a arm64 cuntoo ?

snsabot: Logged on 2019-08-24 00:56:59 BingoBoingo: Tomorrow I am going to try the cuntoo genesis scripts on the test machine with a differrent set of found kernel configs while the Uruguayos play their annual independence day death race game. Then I'll ask alf if we have multithreading on ARM yet and suggest his next payload consist of either 4 full 1U AMD64 box, 2 1Ubox and 8 PCengines APU, or 3 1Ubox and 4 APU.

BingoBoingo: And I am indeed giving Cuntoo another try because linux kernel shit is nearly Argentine cyanoacrylate level shit. The kernel config is an essential piece of making the orchestra string yet because shitgnomes it is a very rough edge to the fault of noone here but plenty of people out of here.

BingoBoingo: Tomorrow I am going to try the cuntoo genesis scripts on the test machine with a differrent set of found kernel configs while the Uruguayos play their annual independence day death race game. Then I'll ask alf if we have multithreading on ARM yet and suggest his next payload consist of either 4 full 1U AMD64 box, 2 1Ubox and 8 PCengines APU, or 3 1Ubox and 4 APU.

lobbes: http://logs.nosuchlabs.com/log/trilema/2019-08-13#1928256 << it is inconclusive if the eggogs are a result of the znc2tmsr converter, or the znc logs themselves. Now that I have your logotron pressed onto my cuntoo workstation, I aim to get some irssi #e logs and run them through diana_coman's irssi2tmsr converter, and then snarf that into your logotron to see if I also get barf.

trinque: ha, I was just writing a few lines re: cuntoo

mp_en_viaje: i think you're exagerating, esp re your view of cuntoo work & effects.

asciilifeform: also thinking, may be interesting to try with cuntoo

mod6: http://btcbase.org/log/2019-08-01#1926112 << These go back to this, I did test those ones when they came in. iirc they did work alright when I tested them. I stopped adding these items to the working vtree (SHA512) when mircea_popescu said, and instead started working towards getting the keccak vtree built & then getting it onto cuntoo. Figured once there & stab ☝︎☝︎

asciilifeform: grr i even had 'disk' driver mostly written, was gonna build bootable simdisk w/ cuntoo...

asciilifeform: and -- ideally that each 1 gets a fresh cuntoo.

BingoBoingo: http://btcbase.org/log/2019-07-24#1924470 << M seems very useful to keep on hand for ice40 or having a base for porting Cuntoo to printed MIPS in 3-7 years ☝︎

mp_en_viaje: http://btcbase.org/log/2019-07-24#1924445 << well, cuntoo genesis. ☝︎

asciilifeform: conceivably there is a use for e.g. cuntoo that loads from memory snapshot in <3sec but runs 'like pentium 166'

trinque: http://btcbase.org/log/2019-07-19#1923536 << yes, and "cuntoo" would've contained it if I took the wad-of-shit-in-genesis approach. ☝︎

a111: Logged on 2019-07-19 14:13 diana_coman: asciilifeform: as far as I understand it, trinque's algo is http://btcbase.org/log/2019-07-19#1923467 aka in a way the precise opposite: we don't actually have cuntoo at all; we have (genesised) just a map and the rest is a sort of "for illustration purpose only"

mp_en_viaje: there's approximately 0 need of telling what work, and immense need of the actual work. if you'd like to shine, shine that way ; you can start for instance with a http://bvt-trace.net/2019/07/todo-items-and-work-plan-jul2019/#selection-11.0-23.54 ,to cover the seven month old http://trinque.org/2018/11/27/cuntoo-bootstrapper/ ☝︎

diana_coman: fwiw, taking the above view, I can fully see his despair at "but why don't you have the sources in there?" ; the only puzzler is how exactly does he see the above as more practical and pragmatic than the plain "this wad of shit is what cuntoo is atm, worms and mud and all"

diana_coman: asciilifeform: as far as I understand it, trinque's algo is http://btcbase.org/log/2019-07-19#1923467 aka in a way the precise opposite: we don't actually have cuntoo at all; we have (genesised) just a map and the rest is a sort of "for illustration purpose only" ☝︎☟︎

diana_coman: trinque: my experience is that portage will happily build sources that are locally in /cuntoo/distribution (iirc.); so I don't understand re "won't build"

asciilifeform: trinque: the idea is, i want to emplace turnkey 'tx clears and you have root' 'virtual' service at piz. with cuntoo.

asciilifeform: btw trinque i have a patched kernel, at some pt (sept?) when free hand, will be porting cuntoo userland. ☝︎

trinque: cuntoo genesis is raaaather tiny, and was intended to express what's necessary to capture

mp_en_viaje: mod6, didn't run into diana_coman 's cuntoo genesis problem then ?

mod6: Hi diana_coman! Let me post what I did (simply as a discussion point - example), for those whom are following along: http://www.mod6.net/cuntoo/test/ebuilds/starter_v-99993.ebuild

mod6: The idea being, once we're moved over to cuntoo, using keccak vtools & a keccak trb vtree, then the Foundation can go back to discussion of various patches that have been waiting in the lobby for some time.

mod6: But overall the focus has been to put forth directed effort into getting us over to cuntoo so we can stop using all of the buildroot things, and supporting debian, et. al.

mod6: Recently, on workbench, I've been trying to build up TRB on cuntoo; and most recently (last month) dipping my toe into creating ebuilds.

a111: Logged on 2019-07-15 10:05 diana_coman: trinque: from what I see though the genesis.vpatch is a snapshot of /cuntoo/portage dir *only* which means that the actual tarballs with the code are not included anyway - so basically it will still fail to find them as soon as whatever URI in the ebuild doesn't host them anymore, what am I missing?

diana_coman: to me it seems that there should be a tmsr repo with the tarballs (aka contents of /cuntoo/distfiles) but then all the ebuilds in genesis need updated too

diana_coman: trinque: from what I see though the genesis.vpatch is a snapshot of /cuntoo/portage dir *only* which means that the actual tarballs with the code are not included anyway - so basically it will still fail to find them as soon as whatever URI in the ebuild doesn't host them anymore, what am I missing? ☟︎

feedbot: http://ossasepia.com/2019/07/14/a-working-cuntoo-install-on-amd-fx-8350-with-script/ << Ossa Sepia -- A Working Cuntoo Install on AMD FX-8350 (with script)

diana_coman: in other annoying stuff: apparently the mysql ebuild I forced into use on smg test server meanwhile vanished from gentoo repos to the extent that my shiny new cuntoo just can't find it??

lobbes_field: This on the grounds that a) after reading the various cuntoo ebuild threads, it isn't clear to me that pythonisms are actually not needed and b) I actually know python/php, whereas I do not know cl

asciilifeform: the reason why posted, is that theoretically this is enuff to start the cuntoo port. supposing anyone finds himself with a free hand.

asciilifeform: ( for thread-completeness, the missing pieces afaik are : 1) handle speshulcases of 'div' and arithm. overflow trapping -- neither apparently used in linux, but presumably used ~somewhere~ 2) iron timer slave thread 3) nic 4) disk i/o 5) cuntoo port ! )

asciilifeform: BingoBoingo: speaking of the (entirely fair) 'customers, motherfuckers' prod from mp_en_viaje : i'ma take the smg broadcast as official marching order re the machine delivery, and make the purchases, so we've what to sell . ( and on that front, the mips item is ready for war. i'ma also need to cuntoo . )

diana_coman: I have just finished my cuntoo-to-be box, ha.

feedbot: http://blog.mod6.net/2019/07/cuntoo-ebuild-prototypes/ << mod6's Blog -- Cuntoo ebuild prototypes

asciilifeform: ( it's ~no good for anyffin practical until i bake a cuntoo or at the very least a clean buildroot for it, and won't get chance for a while, thing is on back burner )

a111: Logged on 2019-06-24 03:55 ave1: trinque, doesn't cuntoo with default gcc also build it with some mystery meat? it probably starts out on a host with gcc?

asciilifeform: ( 1 cuntoo's, 1 ave1's )

ave1: trinque, doesn't cuntoo with default gcc also build it with some mystery meat? it probably starts out on a host with gcc? ☟︎

mod6: For completeness, this is what happens when you try to install AdaCore 2016 (binaries) on Cuntoo (keep in mind that the install actually does place the binaries in the expected places...): http://p.bvulpes.com/pastes/vX16f/?raw=true

mod6: If the thinking is that it ~can~ be built on cuntoo, I'd much prefer an ebuild that would do that dance indeed.

mod6: so I never was able to build the ave1 musltronic tools on cuntoo, because no working gnat, I just bundled them up after I built them on a gentoo machine that had a working AdaCore 2016.

mod6: With everything in the right place... (I even needed a '/var/db/repos/mod6/metadata' directory with one file in it, 'layout.conf', that contains one single line: masters = cuntoo) then I was able to run a `ebuild ave1_musltronic_tools_x86_64-20180924.ebuild clean manifest install merge` and end up with the extracted contents in '/ave1_musltronic_tools_x86_64-20180924'.

lobbes: s/cuntoo is/cuntoo bootstrap scripts are/

lobbes: http://btcbase.org/log/2019-06-23#1919658 << naw, I took no personal offense. Only pointing out that I understood cuntoo is not a $ubuntu-installer item ☝︎

a111: Logged on 2019-06-23 00:03 lobbes: however on second run-through I indeed went back to read the scripts in tandem with the gentoo handbook (so as to actually understand what was going on) and produced a bootable genesis that verified >> http://blog.lobbesblog.com/2019/02/a-bridge-to-cuntoo-for-the-lenovo-x61-x86_64/

diana_coman: so far other parts took priority (smg comms and client) but at least my understanding was that there is work being done further on cuntoo, I had no idea that it was stuck waiting on more intensive use or something

a111: Logged on 2018-11-27 18:11 diana_coman: trinque, that looks great; if I understand correctly, the archive there contains the means to a. install cuntoo b. make the genesis of cuntoo/portage that could in principle be used to move an existing gentoo to cuntoo; is this correct?

a111: Logged on 2019-06-23 08:49 mircea_popescu: diana_coman, more practically, are we running cuntoo latest or what is the situation there ?

diana_coman: http://btcbase.org/log/2019-06-23#1919625 - s.mg test is running proto-cuntoo (non-musltronic) so not latest, no; there was this http://btcbase.org/log/2018-11-27#1875228 and http://btcbase.org/log/2019-03-09#1901069 ; as long as there is the CS dependency still on server, a move to static & musltronic only is also likely to be a lot of work. ☝︎☝︎☝︎

mircea_popescu: diana_coman, more practically, are we running cuntoo latest or what is the situation there ? ☟︎

a111: Logged on 2019-06-22 18:07 trinque: I noticed that not a soul read the scripts that bootstrap cuntoo

lobbes: however on second run-through I indeed went back to read the scripts in tandem with the gentoo handbook (so as to actually understand what was going on) and produced a bootable genesis that verified >> http://blog.lobbesblog.com/2019/02/a-bridge-to-cuntoo-for-the-lenovo-x61-x86_64/ ☟︎

lobbes will admit to committing cardinal sin of not fully reading the cuntoo bootstrap scripts before my first run-through (which trinque rightfully whacked me over the head for)

mircea_popescu: one somethong to do with trinque 's unhapiness with the cuntoo userbase ; the other something to do with wtf to do re v & portage/ebuilds.

mircea_popescu to bed. but ima try to be on tomorro (tho prolly on the viaje nick) because it seems to me there's two different layers of unhapiness preventing cuntoo from making meaningful progress, neither of which properly gotten to the bottom of.

a111: Logged on 2019-02-06 04:21 trinque: hanbot: hm, this got right past me. the cuntoo builder is 64bit only at the present.

mircea_popescu: now, if you wish for your takeaway from this to be "hanbot is not cool enough to run cuntoo" that's your priviledge, but i tell you i don't see the wisdom. for the same money you could say you never read the damned scripts, and butress the claim on eg http://btcbase.org/log/2019-02-06#1893199 ☝︎

mircea_popescu: hewhet.net/2019/03/hanbots-cuntoo-bake-test-notes-part-iv/ spanning a coupla months.

a111: Logged on 2019-06-04 12:12 diana_coman: http://btcbase.org/log/2019-06-04#1917013 -> until we change OS basically; the test one was step towards Cuntoo and that's pretty much the only real reason for having 2 since playing around with the OS on a production server is rather iffy.

a111: Logged on 2018-11-27 18:18 diana_coman: asciilifeform, smg's test machine is running proto-cuntoo so it's not just any gentoo really

a111: Logged on 2018-07-23 14:08 diana_coman: eulora server is happily compiling on proto-cuntoo with ave1's gnat+gcc; all tests passed so far, LOC greatly reduced too, loads of shit cleaned away and discarded; we are looking forward to move it to production, so any eta for cuntoo?

mircea_popescu: there's on one hand the http://btcbase.org/log/2018-07-23#1837434 / http://btcbase.org/log/2018-11-27#1875247 / http://btcbase.org/log/2019-06-04#1917021 story arch, spanning a year. there's also the http://thewhet.net/2019/02/hanbots-cuntoo-bake-test-notes-part-i/ http://thewhet.net/2019/02/hanbots-cuntoo-bake-test-notes-part-ii/ http://thewhet.net/2019/03/hanbots-cuntoo-bake-test-notes-part-iii-with-prep-script/ http://t ☝︎☝︎☝︎

a111: Logged on 2019-06-22 18:07 trinque: I noticed that not a soul read the scripts that bootstrap cuntoo

asciilifeform: mircea_popescu: yer card runs on closed vendorblob, neh. how would that even make it into a cuntoo-portage or vtree at all.

trinque: I can see the continuous symbolic space mircea_popescu wants, but the cuntoo thing was exactly "capture these packages before they can't even be built anymore" plus a snapshot of a working build toolchain to do so.

trinque: I noticed that not a soul read the scripts that bootstrap cuntoo ☟︎☟︎