Show Idle (>14 d.) Chans
← 2019-03-09 | 2019-03-11 → ↓
00:06 mircea_popescu o right the registers. i recall.
00:07 mircea_popescu http://btcbase.org/log/2019-03-10#1901119 << because 8 cubed.
↖
00:07 a111 Logged on 2019-03-10 03:21 asciilifeform: http://btcbase.org/log/2019-03-10#1901103 << i cannot resist to bite : why 512 ?
~ 4 hours 15 minutes ~
04:23 mircea_popescu asciilifeform so i take it your ideal cpu would actually be simply state machines + registers, no actual ram ?
↖
~ 6 hours 46 minutes ~
11:09 diana_coman http://btcbase.org/log/2019-03-09#1901066 -> I ran those and I got exactly the same genesis.vpatch (i.e. diff on this vs the one obtained from the script itself returned empty)
11:09 a111 Logged on 2019-03-09 22:43 trinque: diana_coman, other folks that have cuntooed, can y'all confirm that the paths that ended up in your genesis.vpatch do not in fact exist? I'd like you to reproduce the commands starting at line 114 of scripts/make_portage_tree.sh in your build directories, i.e. cd ~/src/cuntoo/build/cuntoo and then run them, as root
11:10 diana_coman onth in unexpected results and assorted ugh: vdiff ends up in stack overflow ran on those
↖
11:11 diana_coman trinque, which are exactly the paths that don't match? since I don't have the original genesis.vpatch I can't really know what to check to look if indeed those paths actually exists or not or wtf
~ 1 hours 30 minutes ~
12:42 mircea_popescu asciilifeform thinking about whart you said, i can't repress the suspicion that maybe the memory model is acrtually profoundly fucked,as a central driver of the whole cs insanity.
↖
12:43 mircea_popescu ie, that structured data should really be much better hardware supported, that memory should include much more processor per storage cell, that in fact memory should look a lot more like trees than the current flat, democratic lines of "all cells are equal"
↖
12:43 mircea_popescu ie, socialism fails yet again, and calling itself "democracy" dun help anything -- flat is fail, no two ways about it.
12:44 mircea_popescu trinque no deedbot ?
12:45 mircea_popescu http://btcbase.org/log/2019-03-10#1901145 << say this again ?! vdiff blows the stack when processing the two diffs ?
12:45 a111 Logged on 2019-03-10 15:10 diana_coman: onth in unexpected results and assorted ugh: vdiff ends up in stack overflow ran on those
~ 17 minutes ~
13:02 mircea_popescu perhaps the correct republican approach is not to bake cpu, but to ~bake memory~. why even bother with the whole turdpile that's ddr init when could simply have sane ram, and rk with it.
↖
13:02 a111 Logged on 2018-09-25 00:39 asciilifeform: the only binball is that coupla kB of ddr ram init thing.
13:03 mircea_popescu make a 18446744073709551616 byte ram arm board, for the keks.
13:04 mircea_popescu 16 exabytes ftw!!!
~ 25 minutes ~
13:29 asciilifeform http://btcbase.org/log/2019-03-10#1901142 << programmable interconnect fabric ( similar to what's sold as fpga ) . iirc i detailed this in old thrd.
13:29 a111 Logged on 2019-03-10 08:23 mircea_popescu: asciilifeform so i take it your ideal cpu would actually be simply state machines + registers, no actual ram ?
13:30 asciilifeform http://btcbase.org/log/2019-03-10#1901147 << it indeed is, and in precisely the way described.
13:30 a111 Logged on 2019-03-10 16:42 mircea_popescu: asciilifeform thinking about whart you said, i can't repress the suspicion that maybe the memory model is acrtually profoundly fucked,as a central driver of the whole cs insanity.
13:31 asciilifeform http://btcbase.org/log/2019-03-10#1901148 << imho the ( ~homogeneous~ variant of ) fpga is actually the correct model. i.e. you get to stitch it later into however many parallel mechanisms you happen to need on a given occasion.
13:31 a111 Logged on 2019-03-10 16:43 mircea_popescu: ie, that structured data should really be much better hardware supported, that memory should include much more processor per storage cell, that in fact memory should look a lot more like trees than the current flat, democratic lines of "all cells are equal"
13:32 asciilifeform http://btcbase.org/log/2019-03-10#1901153 << bake 'pile of reconnectable flipflop' and then you aint gotta ever bake anyffin else again. iirc i detailed this in ancient thread, mircea_popescu barfed ( iirc answered 'why waste so many transistor on interconnects' ) , but can't currently dig up where we had this
13:32 a111 Logged on 2019-03-10 17:02 mircea_popescu: perhaps the correct republican approach is not to bake cpu, but to ~bake memory~. why even bother with the whole turdpile that's ddr init when could simply have sane ram, and rk with it.
13:34 asciilifeform http://btcbase.org/log/2019-03-10#1901140 << the down side of 'let's 512b bus' is that most cpu time (where it runs, not counting idles on i/o here) is spent in 'inner loops' where yer counting to e.g. 3. and nao you gotta move 512bits when yer counting to... 3
13:34 a111 Logged on 2019-03-10 05:07 mircea_popescu: http://btcbase.org/log/2019-03-10#1901119 << because 8 cubed.
13:37 diana_coman mircea_popescu, yes, vdiff on the 2 genesis.vpatch files overflows the stack; while on same machine and same files, diff seems to have no such trouble
13:38 mircea_popescu phf ^ ?
13:38 asciilifeform ( the style of programming that would appear on ' asciilifeform's ideal cpu ' is best illustrated in http://btcbase.org/patches/fg-genesis/tree/fg.v . i.e. all of the independent pieces in fact run in parallel, and in deterministic time, there are no interrupts, no scheduler, etc. )
13:39 asciilifeform mircea_popescu: we found that vdiff overflows during http://btcbase.org/log/2018-10-20#1864346
13:39 a111 Logged on 2018-10-20 01:44 asciilifeform: !Q later tell phf i found today that your keccak-vdiff is unable to eat a 40MB file ( dies politely with stack overflow )
13:39 asciilifeform phf promised to fix, but then went on his ill-fated voyage
13:39 diana_coman asciilifeform, ftr this is a 4.7MB file
13:40 diana_coman and yes, I had this idea in my head that "previous problem, was solved"
13:40 asciilifeform diana_coman: i do not presently know where is the barf threshold, i suspect it depends on yer stack size
13:40 asciilifeform i'd like to see phf come back to life and fix. failing this, 1 of us will have to
↖
13:40 mircea_popescu asciilifeform that was size, this is ???
13:41 mircea_popescu diana_coman try it with the megastack size from before, calling tests ?
13:41 diana_coman ulimit -s sez 8192
13:41 asciilifeform diana_coman: iirc it throws whole file on the stack, but then also keccak eats stack
13:41 diana_coman mircea_popescu, this is a different machine, the cuntoo-guinea pig
13:41 asciilifeform so hard to say 'on napkin' what mass chokes it
13:41 diana_coman I can give it unlimit stack anyway and see what happens, sure
13:43 diana_coman yep, unlimited stack -> fine
13:43 diana_coman (i.e. it runs, it returns fine, no differences between the files)
13:44 asciilifeform !Q later tell phf fughet for nao about http://btcbase.org/log/2019-03-01#1899897 , but wouldja pleez fix vdiff ? and tell us what sorta swamp yer stuck in, what wouldja need to get to surface ?
13:44 a111 Logged on 2019-03-01 08:57 phf: asciilifeform: give me until end of march to resolve it one way or another, feel free to neg rate me then
13:44 lobbesbot asciilifeform: The operation succeeded.
13:46 asciilifeform diana_coman: i think he's trapped in some sorta cube hell; the squarebracket thing mircea_popescu asked for also not happened yet etc
13:48 asciilifeform trinque: deedbot dead ??
13:50 asciilifeform diana_coman: the 'errything on stack' approach has its limits; it is why i wrote the mmap thing (currently stuck in limbo , but i'ma have to revive it and fix, cuz ffa 17 also is hitting against this wall, you can't expect to put 100MB on stack, you gotta mmap it
13:52 asciilifeform i'ma detail, ftr : 'ffacalc' runs 'as fed', i.e. 1 command at a time. but 'peh' , adult version, has support for functions and loops, and therefore requires the 'tape' to exist in memory. so currently i have 'tape can be 1000000 bytes', but this is not acceptable obv. in the long term
13:52 asciilifeform so it will have to have the mmap routine.
↖
13:54 * asciilifeform wonders if phf hung on waiting for asciilifeform to fix the mmap lib
13:54 asciilifeform mmap is the obv. logical method to handle multi-MB inputs for e.g. vdiff , without introducing heapisms
13:55 asciilifeform tho not neccessarily required, in vdiff, the process as i understand it does not actually demand random access to the entire input
14:07 mircea_popescu diana_coman see, if it is broken code, then it just eats all stack available. but i suspect here code is sound, demand on stack defensibly large.
14:08 mircea_popescu the whole "low stack by default" thing is a low level "let's stimulate heap usage", in the same exact way the empire of smegma would impose a high import tax on soap.
14:08 mircea_popescu asciilifeform it's not at all evident vdiff is broken. what'd you have him do ?
14:09 asciilifeform mircea_popescu: ideally, mmap the inputs
↖
14:10 diana_coman mircea_popescu, yes, I don't suspect the code is broken as such but it is a limitation of the approach and I did not really expect bumping into it at 7MB
14:11 diana_coman I don't recall it being discussed in detail (i.e. with numbers for stack size and input size) anywhere and I think it should be, if it stays as it is
14:15 mircea_popescu well, stack by default is small.
14:16 mircea_popescu asciilifeform imo it is the job of the kernel to expose all available memory (ram, and fucking hell, disk, too, ALL available memory) to me as i fucking want it : stack, cpu registers, heap, whatever it is i wanna call it.
14:17 mircea_popescu ie, yes "ideally mmap it", but not i! it.
14:17 asciilifeform mircea_popescu: kernel ( linus's , that is ) -- exposes. the tricky bit was/is the ada glue.
14:17 asciilifeform !#s horsecocks
14:17 a111 28 results for "horsecocks", http://btcbase.org/log-search?q=horsecocks
14:17 asciilifeform ^ the various drafts of this item
14:20 mircea_popescu myeah.
14:34 BingoBoingo asciilifeform: It's march 10th, what is the window for a supply run looking like and what issues appear to be blocking?
14:36 asciilifeform BingoBoingo: currently hands full restarting ffa conveyor; however will be ordering irons in next 2 wks, and scheduling flight when the items with least predictable shipment windows are in hand
14:37 BingoBoingo asciilifeform: Aite. We don't do these very often yet, so getting things in hand trumps getting plane ticket arranged.
14:37 asciilifeform BingoBoingo: i'd ~really~ like to avoid the scenario where i go out with a half-empty crate
14:38 BingoBoingo Right. Half empty crates are for testing new couriers.
~ 38 minutes ~
15:16 mircea_popescu can i help you guys with anything ?
15:25 asciilifeform mircea_popescu: possibly you have an iron that wants to go in the crate ?
15:25 asciilifeform i'm reluctant to do the massive rk thing until we have a semblance of working gnat for arm
15:27 mircea_popescu that makes sense.
15:27 mircea_popescu i don't really, and besides my/our policy has mostly been to have pizarro own iron, hence the snsa sale etc.
15:28 asciilifeform we also host owner-operated iron (e.g. dulap is still snsa ; and trinque has some, and mod6 )
15:31 asciilifeform ^ this goes for other folx! bring out thy irons.
15:34 * asciilifeform bbl : meat chores
15:41 mircea_popescu true enough. nevertheless, in my view owning iron helps give pizarro some meat on its bones.
15:44 phf http://btcbase.org/log/2019-03-10#1901176 << i'll put it to the top of the stack, i remember fixing it, but never completing the patch.
↖
15:44 a111 Logged on 2019-03-10 17:40 asciilifeform: i'd like to see phf come back to life and fix. failing this, 1 of us will have to
15:44 lobbesbot phf: Sent 2 hours ago: <asciilifeform> fughet for nao about http://btcbase.org/log/2019-03-01#1899897 , but wouldja pleez fix vdiff ? and tell us what sorta swamp yer stuck in, what wouldja need to get to surface ?
15:45 BingoBoingo <mircea_popescu> true enough. nevertheless, in my view owning iron helps give pizarro some meat on its bones. << That it does
15:46 phf the problem is that our ada keccak explodes whatever char buffer it gets into an array of octets, which means that, while diff keeps the size of chunks under some particular value, keccak explodes that value x8
15:47 phf rather not array of octets, but array of bits
15:54 trinque diana_coman: http://p.bvulpes.com/pastes/rWreS/?raw=true << here's the diff of your genesis and mine again
15:55 trinque you'll notice it thinks your home dir is sitting in the profiles dir, which is mighty strange! maybe it is?
15:56 phf http://btcbase.org/log/2019-03-10#1901200 << that is not at all the problem. i can read the file just fine, but as i do i feed chunks of it to keccak. keccak doesn't take char buffers, it wants "bitstream" i.e. arrays of bits, which means whatever char
↖
15:56 a111 Logged on 2019-03-10 18:09 asciilifeform: mircea_popescu: ideally, mmap the inputs
15:57 phf buffer needs to be converted to 8x bitstream, which is in turn allocated on the stack
16:00 phf there are three possible solutions, a) make sure that stack is arbitrarily large b) feed keccak buffers no larger than some magic size c) rewrite keccak to operate on char arrays directly without the need for bitstream allocation
↖
16:00 phf ksum right now works for any sized file, because it goes the b) route: http://btcbase.org/patches/vtools_tempfile_standalone_notmp/tree/vtools/src/ksum.adb#L12
16:07 diana_coman trinque, that's weird; fwiw: no, my home dir as far as I can see is *not* in the profiles directory
16:17 trinque seems as though there's a dereferenced symlink munged into the path.
16:19 diana_coman trinque, this is probably having to do with the drive being external, connected via USB and how it's mounted, I don't see any other explanation
16:19 trinque thing is, my src directory is also a mount on my dev machine.
16:20 mod6 <+asciilifeform> we also host owner-operated iron (e.g. dulap is still snsa ; and trinque has some, and mod6 ) << The Foundation's 2nd box ("lovelace") is with ben_vulpes, currently. He's going to find a home for it in his new area, last we had talked about it. I don't have any machines on-hand that are waiting to go to .uy. However, I might be interested in buying a UY1 style machine from alf...
16:23 trinque diana_coman: I'm running again with a vdiff pressed to http://btcbase.org/patches/vtools_ksum per http://btcbase.org/log/2018-12-03#1878057
16:23 a111 Logged on 2018-12-03 21:48 diana_coman: hm, if it's indeed the tmp thing, it might be worth a try to press vtools to current leaf (i.e. vtools_tempfile_standalone or _notmp) and see if that cures it; my archive contains pressed vtools to ksum patch only, not further
16:23 mod6 Ok, I'm gonna shutdown the cuntoo box, and boot my original gentoo ssd (where I built cuntoo from). I'll see what I can find out from the genesis.vpatch thing.
16:24 diana_coman trinque, I'm trying here to even *see* this "profiles/" path in any other way than in the vpatch but so far no luck
16:24 diana_coman fwiw a test file created there and vdiffed resulted in no such nonsense
16:25 feedbot http://qntra.net/2019/03/french-ophthalmologists-demand-police-rubber-ball-bullet-ban-after-epidemic-of-eye-injuries/ << Qntra -- French Opht...ists Demand Police Rubber Ball Bullet Ban After Epidemic Of Eye Injuries
16:28 trinque diana_coman: there oughta be a cuntoo/portage dir inside the build dir
16:28 trinque this is what's vdiff'd to produce genesis
16:28 diana_coman yes, that one is there; but I don't see the path that vdiff seems to see
16:28 * trinque will brb, grabbing food real quick
16:28 diana_coman cp -R portage would fail otherwise anyway
16:29 trinque right, this is what leads me to believe there's some vdiff bug to discover
16:29 diana_coman ha, wait, there actually IS a b/profiles/home/...
16:30 diana_coman trinque, what should be in the portage/profiles dir?
16:32 diana_coman apparently vdiff is correct after all and there is this thing it sees - it just took me a bit to find it as I thought it was just a misplaced path rather than...the actual thing,huh
16:33 mircea_popescu phf pretty sure that's the wrong version of it ? iirc there was also a keccak that didn't explode ? diana_coman ?
16:33 bvt trinque: i also confirm that under /cuntoo/portage/profiles there is a directory structure that corresponds to my bootstrap environment
16:33 lobbesbot bvt: Sent 22 hours and 22 minutes ago: <asciilifeform> http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/comment-page-1/#comment-12
16:33 diana_coman mircea_popescu, when he says "explodes" he means that keccak implementation expects as input a bitstream where each bit is stored in an octet
16:34 diana_coman i.e. there isn't yet a bit-level keccak implemented, no
16:34 bvt something like i.e. /cuntoo/portage/profiles/root/cuntoo/build/usr/portage/profiles/features/musl/use.mask
16:35 mircea_popescu ah, i vaguely recalled we had two of them, one bit the other byte.
16:35 trinque bvt: you confirm that this exists in your genesis, but is not a valid path?
16:35 diana_coman mircea_popescu, that's at...another level
16:35 mircea_popescu what ?
16:35 trinque i.e. one that physically exists on disk?
16:36 bvt i confirm that it is both in genesis and is a valid path. i'm testing live cuntoo though, have no access to bootstrap env currently
16:37 bvt i.e. there is really directory structure /cuntoo/portage/profiles/root/cuntoo/build/...
16:37 trinque o,0
16:37 trinque this is an interesting clue. I'll be back shortly
16:37 bvt but it does but is missing under /usr/portage/...
16:38 diana_coman mircea_popescu, http://btcbase.org/log/2018-10-12#1860813
16:38 a111 Logged on 2018-10-12 13:08 diana_coman: asciilifeform, hm, the bit version blows up buffers even more because it uses *internally* arrays of bits as per http://www.dianacoman.com/2018/02/01/eucrypt-chapter-8-bit-level-keccak-sponge/#selection-51.100-51.594
16:38 bvt ugh, *but it is missing under...
16:39 diana_coman trinque, bvt put clearly what I was trying to say: here I have the same: the full directory structure inside /cuntoo/portage/profiles
16:40 mircea_popescu diana_coman do you see the wisdom in implementing a keccak variant that uses eucomms-style fields ? so that something like "hello world" would be passed as 0x01146865 6c6c6f77 6f726c64
16:41 bvt i.e. like this http://p.bvulpes.com/pastes/k88Le/?raw=true
16:42 diana_coman mircea_popescu, from keccak's pov there is no meaning to the input so I don't quite see what you mean there
16:42 mircea_popescu to be clear : i expect that in the regular course of republican work, GB-sized vdiffs will occur -- strictly because we're contemplating confiscating all sort and manner of heathen artefact, and by now bloat is just a synonym for heathen. the "increase stack" fix works ok as a stop-gap, but we can't really 8x everything just for boredom.
16:42 mircea_popescu diana_coman i mean that instead of keccak receiving array of bits stored in octets, keccak receives (and processes) a eucomms field.
16:43 diana_coman that requires simply a bit-level keccak; which requires in turn someone with the time to do the transformation as it were
16:43 mircea_popescu 0x(01 => length of 2nd field is 1) (14 => length of 2nd field is 20) (6865 6c6c6f77 6f726c64 = hello world).
16:46 mircea_popescu !!up bflame
16:46 deedbot bflame voiced for 30 minutes.
16:46 diana_coman that seems to be at most at reading-chunk-from-file level which is not really related to keccak and not a problem if I understand correctly what phf says; specifically on one hand he said http://btcbase.org/log/2019-03-10#1901225 and then option c from http://btcbase.org/log/2019-03-10#1901236
16:46 a111 Logged on 2019-03-10 19:44 phf: http://btcbase.org/log/2019-03-10#1901176 << i'll put it to the top of the stack, i remember fixing it, but never completing the patch.
16:46 a111 Logged on 2019-03-10 20:00 phf: there are three possible solutions, a) make sure that stack is arbitrarily large b) feed keccak buffers no larger than some magic size c) rewrite keccak to operate on char arrays directly without the need for bitstream allocation
16:46 mircea_popescu bflame how about you make yourself useful and implement a keccak as discussed ^ then patch diana_coman 's tree with it.
16:46 diana_coman so perhaps the text coding etc would help at chunking-file stage if needed but what is that to do with keccak
16:46 mircea_popescu diana_coman well, apparently it expects to be called with a bitstream, which is a peculiarly inconvenient datastruct in practice.
16:47 mircea_popescu i really do not wish to see c strings, and i don't perceive char buffer to be different. "bitstream" does not exist. so my thinking is, to henceforth mandate datapassing as such a field.
16:48 mircea_popescu as a universal c-string / charbuffer replacement.
16:48 mircea_popescu poor man's tagged data, if you will.
16:50 diana_coman mircea_popescu, what is the gain vs having as input octets or words?
16:52 mircea_popescu that you always know how large the field is.
16:52 diana_coman what, a number attached?
16:52 mircea_popescu the ~problem~ with c-strings is that to know how loing it is you must look ~at the end~.
16:52 diana_coman ada doesn't have c-strings anyway
16:52 mircea_popescu the problem with any other datastruct, such as octets or words, is that you never know how large it is.
16:53 mircea_popescu the correct solution then seems to be, prefix size.
16:53 diana_coman uhm, no
16:53 * mircea_popescu has to go now, but will bbs to continue this.
16:53 diana_coman k
17:03 asciilifeform mircea_popescu et al : there are no cstrings in ada, unless one explicitly bakes'em in order to throw to c linked liquishit. all arrays carry their bounds with'em.
17:03 * asciilifeform also gotta bbl
17:05 bvt http://btcbase.org/log/2019-03-09#1901061 << iirc there were restriction on what regs can be used as base and index; another example of isa ugliness is MOV http://archive.is/w0IAC#selection-607.0-945.2
↖
17:05 a111 Logged on 2019-03-09 22:35 asciilifeform: btw, bvt , rax etc. ~are~ encoded as 1-8, the iron dun see reg names at all, the classic names are a convention of the asmers and the vendor docs. and imho remains on acct of the asinine x86isms like MUL which use fixed input and output regs, makes'em slightly easier to remember.
17:06 bvt http://btcbase.org/log/2019-03-09#1901064 << well, IMO nvidia's "denver" managed to beat even them.
17:06 a111 Logged on 2019-03-09 22:40 asciilifeform: when you build 1 of these things, there's a set of decisions that end up determining shape of whole thing; and it so happens that intel made ~all~ of the most retarded possible choices.
17:06 bvt ('denver' is arm at frontend and vliw inside, dynamic jit tries to continuously improve translation: if you have a loop, the 1st, 100th and 1000th loop iterations can execute totally different vliw code)
17:06 bvt http://btcbase.org/log/2019-03-10#1901101 << I decided against inline assembly because the asm source is quite large, it's inconvenient to have 100+ lines of asm inline with comments.
17:06 a111 Logged on 2019-03-10 02:44 mircea_popescu: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/#selection-15.295-19.176 << why this, specifically ? is there no ada asm calling method besides this ?
17:08 bvt there are Import(Ada,...) and Import(Asm,...), which do the same thing according to the docs (http://archive.is/XEHW0#selection-17075.0-17109.171), and I did not manage to find any ABI docs with 'ada calling sequence'.
17:13 mod6 trinque: Ok, immediately I notice that in my /home/mod6/cuntoo/nomods/cuntoo working directory, from which I ran `./bootstrap.sh -k config/cuntoo-test1 -d /dev/sdb` there is currently nothing in the 'build' directory.
17:15 trinque didn't you just say you were going to reboot?
17:15 mod6 I've looked at the genesis.vpatch that was genereated ( http://www.mod6.net/cuntoo-blog-2/nomods.genesis.vpatch ), and at first glance I don't see these files in their paths. (even if I remove the preceeding 'a/').
17:16 mod6 trinque: aha. yeah, powered down, plugged my gentoo SSD back in, and am booted into gentoo where i've built cuntoo.
17:16 trinque ok. so what happens to mounts when you reboot
17:17 mod6 http://p.bvulpes.com/pastes/CLgnR/?raw=true
17:18 mod6 Is this what you're asking?
17:18 trinque no dude, why would the drive still be mounted on the build dir if you rebooted?
17:18 trinque I don't know why you find this surprising
17:19 mod6 Oh, sorry, I guess I wasn't excatly sure what you were asking me to look for, and where. I never had /dev/sdb mounted when I did the bootstrap.
17:19 mod6 It was just "plugged in" to SATA channel 2.
17:19 trinque you didn't read the script either and would otherwise know that it mounted that for you.
17:20 mod6 Gotcha.
17:21 mod6 Is there anything else I can check for you while I have your ear?
17:21 trinque anyhow, bvt, can I get you to paste an ls -R starting from build/cuntoo ?
17:22 mod6 I have also posted the entire typescript (47Mb WARNING) of the build to my website: http://www.mod6.net/cuntoo-blog-2/nomods.cuntoo.build.typescript
17:22 mod6 I also have tar'd up the entire cuntoo build directory, but have not posted it. It's like 1.7G, but will send it somewhere if someone wants it.
17:25 * mod6 bbl
17:32 bvt as i mentioned, currently i can show results only from live cuntoo
17:32 bvt ls -R /cuntoo http://wotpaste.cascadianhacker.com/pastes/hHbuq/?raw=true find /cuntoo http://wotpaste.cascadianhacker.com/pastes/gAtS2/?raw=true
17:37 trinque /cuntoo/portage/profiles/root/cuntoo << and you built this in /root/cuntoo eh?
17:38 bvt correct, it was a liveusb system
17:38 trinque ah for fucks sake, I found it
17:39 trinque scripts/make_portage_tree.sh << line 14, I do string-munging on the path that's specific to my own filesystem layout
↖ ↖
17:39 trinque shame on me!
17:40 trinque bvt: thanks very much for posting this for me! I now know what to fix, back shortly.
17:42 bvt yw
~ 1 hours 4 minutes ~
18:47 mircea_popescu diana_coman what ended up being the problem then, i'm not getting something here.
18:48 mircea_popescu bvt i see.
~ 39 minutes ~
19:27 feedbot http://pizarroisp.net/2019/03/10/pizarro-isp-march-10th-update/ << PizarroISP -- Pizarro ISP March 10th Update
19:28 trinque bvt: diana_coman: I wager that if you change line 14 of scripts/make_portage_tree.sh to the following, my sig will verify on the resulting genesis.vpatch : dest=$pdir/profiles/${src#$bdir/usr/portage/profiles/}
↖ ↖ ↖
19:29 trinque just running scripts/make_portage_tree.sh again oughta be enough.
~ 20 minutes ~
19:49 mircea_popescu trinque nice find.
~ 41 minutes ~
20:30 feedbot http://trilema.com/2019/antiqua-sanctorum-patrum-or-the-lordship-list-sixth-year/ << Trilema -- Antiqua Sanctorum Patrum, or -- The Lordship list, sixth year.
~ 2 hours 1 minutes ~
22:32 BingoBoingo So in trends, the neon nazis shifted to memeing against Trump in favor of a candidate promising 1000 "dollars" a month
~ 49 minutes ~
23:21 hanbot BingoBoingo please reboot me again at your leisure, any time tomorrow or tuesday'd be fine
← 2019-03-09 | 2019-03-11 → ↑

Random(trilema) | Download hourly DB snapshot | Get Source Code

Theme: Light | Dark | System Default