log
500+ entries in 0.027s
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 ☟︎☟︎
asciilifeform: http://btcbase.org/log/2019-06-22#1919166 << trinque sweated out a draft cuntoo, which sadly i have not had chance to test in anger. i have a physical box that is destined for it , when get chance, and also will be porting it to the sim-mips, ditto. but i promised to mircea_popescu not to undertake any elaborate works until ffa suitable for 'discard gpg' and extension to other (gossipd, trbi, what else is waiting on it) paths ☝︎
a111: Logged on 2019-06-15 19:14 asciilifeform: aim is a 'mips 4000' compat. item (for ease of hardwarization, when time comes) if anyone cares. and at some pt will also have to port gnat, cuntoo... to it.
asciilifeform: speaking of linux lulz, asciilifeform recently obtained a 'huawei' to test cuntoo. but this is on back conveyor currently. ☝︎
a111: Logged on 2019-06-15 19:14 asciilifeform: aim is a 'mips 4000' compat. item (for ease of hardwarization, when time comes) if anyone cares. and at some pt will also have to port gnat, cuntoo... to it.
asciilifeform: aim is a 'mips 4000' compat. item (for ease of hardwarization, when time comes) if anyone cares. and at some pt will also have to port gnat, cuntoo... to it. ☟︎☟︎
asciilifeform: would be a mighty useful thing, tho, 'drop coin in this-here slot and get root on a mips cuntoo'
diana_coman: indeed; I suppose there might be a case for keeping the production server only and then getting the test/cuntoo one only when there is finally what to put on it
diana_coman: to answer the q directly: not permanently, I'd hope! But it does seem to be rather long term since atm I have my hands full with SMG Comms on both client+server and otherwise we don't yet have a full Cuntoo setup to deploy and say that's fixed
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. ☝︎☟︎
BingoBoingo: asciilifeform: The dulap spare was yet another monthly, that one strictly billed as a colo, which hanbot played with cuntoo and then the subscription was canceled when that experiment was aborted. The S.NSA spare is cold at present.
asciilifeform: oughta be doable on any linuxism with relatively recent (3+) kernel, iirc. incl. the cuntoo draft.
feedbot: http://blog.mod6.net/2019/05/building-trb-on-cuntoo-part-1/ << mod6's Blog -- Building TRB on Cuntoo: Part 1
asciilifeform: cuntoo, per my current understanding, obsoletes 'rotor' entirely (by doing same thing to ~entire system~ right off the bat)
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: http://edgecase.net/articles/offline_installation_of_a_c_compiler_on_centos_69_minimal_on_kalkin << tried 'cuntoo' yet ?
asciilifeform: mp_en_viaje: are you thinking of planting cuntoo ?
billymg: anyways, ty, going to do some shopping for a future cuntoo box
BingoBoingo: Ah, thought this may be Cuntoo related
Mocky: http://btcbase.org/log/2019-05-01#1910435 << using gns as proposed, I don't see any other way than passing out ip based links. I can't send a blog link to a slut on fetlife who doesn't have cuntoo, nor can i send a link to cuntoo guide. The whole thing seems like tree forts connected with tin cans and string. For gossipd I have no objection, for name resolution of published material? How is it even published if 'must be this tall to ☝︎
diana_coman: asciilifeform: that was a proto-cuntoo, essentially not exactly the current cuntoo
asciilifeform: iirc diana_coman built the cuntoo that runs on the 2nd s.mg box, on this gentoo.
asciilifeform: if you want another s.mg-style box, can be baked very quickly. but it does not reduce the amount of sweat needed to install cuntoo at later point.
diana_coman: yes but I struggle to understand why was it that hanbot struggled so much with getting a cuntoo first since apparently there is actually this image that is frozen and usable
asciilifeform: there is not however a mechanism for 'convert from stone age gentoo to cuntoo w/out nuking disk', afaik .
diana_coman: asciilifeform: re dulap-tarball, does that mean that it's in fact *that* the gentoo image hanbot was looking for as stepping stone towards cuntoo? i.e. deploy that first and then from there move on to cuntoo?
asciilifeform: that'd be cuntoo, as i understand. sorta whole pt.
asciilifeform: ( and gotta be replaced with cuntoo )
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 ) ☝︎
mircea_popescu: it historically worked -- eg trinque birthed cuntoo etc.
BingoBoingo: Have you baked yourself a cuntoo yet?
asciilifeform: BingoBoingo: currently i'm thinking, 2 x dulap-style, 2 x 1u w/ ea. 4 x apu1 'amd g' where cuntoo in write-protected rom . ( i have a rom booter for the latter, built on ancient 'coreboot' )
asciilifeform: iirc BingoBoingo has performed a successful beta-cuntoo installation , for own needs. you may choose to delegate the task to him.