gemini - kennedy.gemi.dev

💾 Archived View for gemini.ctrl-c.club › ~phoebos › logs › kisslinux-2021-06-04.txt captured on 2024-06-16 at 13:42:06.
-=-=-=-=-=-=-
[2021-06-04T00:15:41Z] <sad_plan> wait, didnt what I wrote go through?
[2021-06-04T00:17:34Z] <sad_plan> im guessing not seeing as it doesnt appear in the logs.. 
[2021-06-04T00:18:09Z] <sad_plan> compiler-rt doesnt build for me. anyone care to give their 2 cents, as to why? I cant pinpoint anything from readoing the log
[2021-06-04T00:18:10Z] <sad_plan> https://0x0.st/-_cQ.txt
[2021-06-04T00:18:29Z] <sad_plan> also, alsa suddenly wont give me sound :p
[2021-06-04T00:29:52Z] <kqz> sad_plan: you either need to disable sanitizers for compiler rt like so here https://github.com/wyvertux/wyverkiss/blob/master/core/llvm/build 
[2021-06-04T00:30:06Z] <kqz> or try this hacky patch https://git.sr.ht/~kqz/repo/tree/master/item/core/llvm/patches/fix-sanitizer-musl.patch
[2021-06-04T00:39:49Z] <sad_plan> yeah, that might be it. ill check them out. see if I cant make sence of them
[2021-06-04T00:50:52Z] <sad_plan> well compiler-rt is configured to not build sanitizers though
[2021-06-04T00:51:15Z] <sad_plan> in the buildscrit i mean
[2021-06-04T00:55:51Z] <dilyn> sad_plan: alsa... also does not give me sound. cute 
[2021-06-04T00:56:57Z] <sad_plan> borked after updating to latest. seems to segmentation fault. it doesnt look like it find my card anymore, for whatever reason
[2021-06-04T00:57:10Z] <dilyn> http://ix.io/3oHb interesante 
[2021-06-04T00:57:37Z] <dilyn> I get a error reported on boot about neither of my cards being *something or other*, though they appear just fine otherwise 
[2021-06-04T00:58:02Z] <sad_plan> strange
[2021-06-04T01:00:56Z] <dilyn> doesn't happen when using alpine's apkbuild 
[2021-06-04T01:01:20Z] <dilyn> asm error makes me think it's some kind of analogue to the 5.12 kernel problems 
[2021-06-04T01:01:27Z] <dilyn> though I haven't looked very closely 
[2021-06-04T01:05:17Z] <dilyn> brb testing
[2021-06-04T01:05:21Z] <sad_plan> yeah, I was wondering if the kernel might be at fault. figured id try to go back to an earlier build, but gotta build it first with my new config :p
[2021-06-04T01:05:29Z] <sad_plan> you do that. I got work to do in the mean time. lol
[2021-06-04T01:21:21Z] <dilyn> are you using gnu ld? or something else sad_plan
[2021-06-04T01:28:48Z] <dilyn> https://bugs.gentoo.org/793410 cute
[2021-06-04T01:34:48Z] <sad_plan> uhm.. if its not default, i guess not
[2021-06-04T01:35:18Z] <sad_plan> great
[2021-06-04T01:37:09Z] <dilyn> cool, it's fixed.
[2021-06-04T01:37:13Z] <dilyn> probably here https://github.com/alsa-project/alsa-lib/commit/ddfc32abf5697de1618b9e7ffdf57a0f97013090 
[2021-06-04T01:37:40Z] <dilyn> i'll make a patch, test again, and push that (so we don't have to use a source where I have to generate configure smh) 
[2021-06-04T01:38:42Z] <sad_plan> nice to see they fixed it rather quickly. yea you do that. 
[2021-06-04T01:41:29Z] <dilyn> wouldn't expect a horrifyingly broken change in such a small release but ~what the fuck do I know~
[2021-06-04T01:45:08Z] <dilyn> should be fixed now sad_plan :)  
[2021-06-04T01:51:50Z] <sad_plan> cool
[2021-06-04T02:32:56Z] <sad_plan> I still get the segmentation fault at bootup, but sound works though. which is the important part :p
[2021-06-04T03:17:40Z] <acheam> hmm i'm facing weird bug in my C program: I have a pointer to a char[], which prints fine
[2021-06-04T03:17:42Z] <acheam> however
[2021-06-04T03:18:14Z] <acheam> if I printf something else before it, then the variable filled with garbage when I try and print it
[2021-06-04T03:18:54Z] <acheam> with literally the only difference between printing fine and printing garbage, being a few characters being printed before. I can print 4 characters fine, but once I print 5 or more, the variable prints crap
[2021-06-04T03:21:58Z] <acheam> https://l.armaanb.net/cdir.c is the program. If I comment out line 62, then the printf in line 64 works as intended, however if I leave line 62 in, the printf in line 64 just prints garbage
[2021-06-04T03:22:17Z] <acheam> been stumped at this for the last 1.5hrs
[2021-06-04T03:36:37Z] <noocsharp> when things like that happen, it means the stack is getting corrupted somewhere
[2021-06-04T03:41:08Z] <june> acheam: outp.items = calloc(1, sizeof(struct dirent **));
[2021-06-04T03:41:52Z] <m3g> My m.2 makes weird noises whenever it boots up
[2021-06-04T03:41:59Z] <june> you are allocating the size of outp.items, rather than the size of what it's pointint to
[2021-06-04T03:42:27Z] <june> I recommend always writing allocations like this: foo = malloc(sizeof(*foo))
[2021-06-04T03:43:20Z] <june> that said, that's probably not the problem, since both the pointer and the thing it's pointing to are pointers
[2021-06-04T03:44:04Z] <acheam> hmm yeah that did not fix it, but thank you for the tip!
[2021-06-04T03:44:36Z] <acheam> noocsharp: thanks i'll look into that
[2021-06-04T03:44:44Z] <noocsharp> that's one problem, but it shouldn't affect anything since they are both struct dirent * and struct dirent ** are both the size of pointers
[2021-06-04T03:45:03Z] <noocsharp> im trying to figure it out as well
[2021-06-04T03:45:14Z] <june> I think the real problem is that readdir(3)'s return value is only valid until the next call to readdir(3) or to closedir(3)
[2021-06-04T03:46:15Z] <acheam> ah I see
[2021-06-04T03:46:26Z] <june> you need to copy the data out (in which case it makes more sense to have struct dirent *items)
[2021-06-04T03:46:42Z] <acheam> I will do that, thank you!
[2021-06-04T03:47:01Z] <june> or use readdir_r(3)
[2021-06-04T03:47:04Z] <acheam> would memcpy be the right way to do this?
[2021-06-04T03:47:31Z] <noocsharp> you could use strdup
[2021-06-04T03:47:41Z] <noocsharp> since you're only using the name
[2021-06-04T03:47:55Z] <acheam> I thought strdup was a glibc thing?
[2021-06-04T03:48:13Z] <acheam> or maybe just not a C99 thing
[2021-06-04T03:48:16Z] <noocsharp> no, it's posix
[2021-06-04T03:48:36Z] <acheam> ah got it just need to define _POSIX_C_SOURCE
[2021-06-04T03:48:52Z] <june> glibc is such an annoyance to program for...
[2021-06-04T03:50:43Z] <june> I think this is the most detailed history section I've seen for such a basic function:
[2021-06-04T03:50:45Z] <june> > A strdup() macro was first used in the 4.1cBSD debugger, dbx. It was rewritten as a C function for the 4.3BSD inetd(8) and first appeared in the C library of 4.3BSD-Reno.
[2021-06-04T03:51:12Z] <noocsharp> the more you know i guess
[2021-06-04T03:51:58Z] <acheam> woot memcpy fixed it, thank you june and noocsharp!
[2021-06-04T03:52:26Z] <noocsharp> tbh libc itself kind of sucks
[2021-06-04T03:53:46Z] <noocsharp> there's so much extraneous crap that no one ever uses, and basic data structures are excluded
[2021-06-04T03:55:05Z] <noocsharp> also acheam: you should include dirent.h instead of sys/dir.h
[2021-06-04T03:55:49Z] <acheam> why is that?
[2021-06-04T03:55:57Z] <june> that's the header listed in the manual
[2021-06-04T03:56:21Z] <acheam> ah okay yeah I see that now in the RATIONAL section of the manpage
[2021-06-04T03:56:54Z] <june> huh? the header is the first line of SYNOPSIS
[2021-06-04T03:57:22Z] <acheam> oh I was talking about the full difference between sys/dir.h and dirent.h
[2021-06-04T03:57:34Z] <acheam> which is explained in detail in the RATIONALE section
[2021-06-04T03:57:40Z] <acheam> but I do see what you mean in SYNOPSIS
[2021-06-04T03:57:41Z] <noocsharp> what manpage is it in?
[2021-06-04T03:57:47Z] <noocsharp> the rationale section?
[2021-06-04T03:58:02Z] <acheam> dirent.h(0P)
[2021-06-04T03:59:02Z] <acheam> the name of which should have been a tip off that I should have been using dirent.h lol
[2021-06-04T03:59:17Z] <noocsharp> i just use dirent because the manpage for opendir/readdir says so lmao
[2021-06-04T03:59:29Z] <acheam>  /shrug
[2021-06-04T03:59:32Z] <noocsharp> i didn't even know the dirent.h manpage existed
[2021-06-04T04:00:56Z] <june> I think technically if you insist on only following POSIX, you can't just memcpy dirent structs, because d_name isn't necessarily a fixed size
[2021-06-04T04:02:06Z] <june> there's a section about it in NOTES in linux-man-pages readdir(3)
[2021-06-04T04:03:28Z] <acheam> hmmmm
[2021-06-04T04:04:07Z] <acheam> i'll worry about that later
[2021-06-04T04:07:01Z] <june> well, that's why strduping d_name is a better idea
[2021-06-04T04:07:42Z] <acheam> yeah i'll do that eventually
[2021-06-04T04:08:01Z] <acheam> depends if I need the other things in the dirent struct though
[2021-06-04T04:11:39Z] <noocsharp> imagine how much simpler life would be if c had proper arrays
[2021-06-04T04:27:19Z] <acheam> that would be miraculous
[2021-06-04T05:06:57Z] <testuser[m]_> hi
[2021-06-04T13:05:47Z] <omanom> good morning
[2021-06-04T13:16:48Z] <midfavila> got my copy of intro to algos today
[2021-06-04T13:16:53Z] <midfavila> pretty hefty boi
[2021-06-04T13:17:01Z] <omanom> oof, have fun with /that/
[2021-06-04T13:17:27Z] <midfavila> a thousand or so pages :^)
[2021-06-04T13:17:46Z] <midfavila> i'm definitely not going to get through it in a comprehensive manner any time soon.
[2021-06-04T13:18:50Z] <testuser[m]_> nice
[2021-06-04T15:43:37Z] <omanom> can confirm i now have alsa issues after an upgrade as well
[2021-06-04T15:45:01Z] <omanom> hm never mind, for some reason it muted my master volume
[2021-06-04T15:45:33Z] <m3g> alsactl an funny
[2021-06-04T15:51:29Z] <omanom> it mutes on reboot now... hmm
[2021-06-04T16:13:53Z] <m3g> alsactl store?
[2021-06-04T16:17:52Z] <dilyn> could it be that alsactl is segfaulting for you as well omanom: ? 
[2021-06-04T16:17:58Z] <omanom> >udevd[160] '/usr/bin/alsactl restore 0' [171] terminated by signal 11 (segmentation fault)
[2021-06-04T16:18:02Z] <omanom> yep
[2021-06-04T16:18:16Z] <dilyn> it doesn't for me, so i'm uncertain
[2021-06-04T16:19:00Z] <omanom> weird thing is, the sound card is still loaded and i still have sound through various applications.  i just have to go in to alsamixer and unmute master 
[2021-06-04T16:20:19Z] <omanom> there's a new option i don't remember in alsamixer: "Auto-Mute Mode" which is enabled.  Rebooting re-enables it even if i mark it disabled.  Don't know if that's related
[2021-06-04T16:22:15Z] <dilyn> I think auto mute mode has always existed 
[2021-06-04T16:22:18Z] <dilyn> probably unrelated 
[2021-06-04T16:22:48Z] <dilyn> have you tried just rebuilding alsa-utils? 
[2021-06-04T16:24:20Z] <omanom> not yet, i'll do that now.
[2021-06-04T16:27:45Z] <omanom> same outcome
[2021-06-04T16:28:00Z] <dilyn> figured
[2021-06-04T16:28:01Z] <dilyn> hmhmhm
[2021-06-04T16:28:13Z] <omanom> alsa-utils v1.2.5
[2021-06-04T16:34:06Z] <omanom> rebuild of alsa-lib also doesn't change anything
[2021-06-04T18:20:59Z] <sad_plan> omanom: mine also has the same error, but sound still works. rebuilding did nothing on my end either..
[2021-06-04T18:27:06Z] <omanom> is your sound muted by default on boot now also?  or is that just mine?
[2021-06-04T18:29:57Z] <sad_plan> yeah, of it says its not, but it always is. so I always gotta open amixer, and mute/unmute master channel. aswell as the aux. may be some issue with me plugging in/out my headset all the time, but it kust about never works right when booting up..
[2021-06-04T18:34:58Z] <sad_plan> ignore the first 'of'. dunno why it got there. 
[2021-06-04T18:35:38Z] <claudia> o/
[2021-06-04T18:36:04Z] <omanom> hi!
[2021-06-04T18:36:18Z] <sad_plan> hey
[2021-06-04T18:37:40Z] <claudia> I want to mention that I also have a muted alsa master on startup since this install. (3 months old)
[2021-06-04T18:38:00Z] <claudia> omanom: 
[2021-06-04T18:38:26Z] <omanom> 3 months old, thank you claudia!  that makes it seem as though it is not part of the seg fault issue then
[2021-06-04T18:39:11Z] <claudia> Yeah, thats what I am pointing ;)
[2021-06-04T18:40:13Z] <omanom> oh @m3g `alsactl store`, i haven't tried that yet... totally read it as `alsactl restore` sorry
[2021-06-04T18:40:15Z] <claudia> where can I observe the segfault, while using something 'amixer sset Master 10%-'?
[2021-06-04T18:40:49Z] <sad_plan> mine has always been that way, and I installed kiss ~6 months ago. i also reinstalled it some time inbetween that where I switched to a new ssd
[2021-06-04T18:40:56Z] <omanom> mine occurs during boot process, it shows up immediately after "=> Starting udev..."
[2021-06-04T18:43:06Z] <omanom> ok so i unmuted master, set it to a normal gain, and then ran as root `alsactl store`.  the segfault doesn't show up on boot and master isn't muted any more
[2021-06-04T18:43:09Z] <claudia> I am using libudev-zero.(beside this great tool the name is clunky to type :p)
[2021-06-04T18:43:40Z] <omanom> figures it is my own fault!
[2021-06-04T18:45:30Z] <sad_plan> omanom: i gotta try that aswell, when I get back onto my laptop. maybe that fixes my segmentation fault aswell
[2021-06-04T18:48:34Z] <claudia> lol, on my end 'alsactl store' does not store the unmuted master
[2021-06-04T18:50:54Z] <claudia> And there is a segfault when running 'alsactl restore'
[2021-06-04T18:50:56Z] <claudia> hm...
[2021-06-04T18:51:24Z] <claudia> http://ix.io/3oKQ
[2021-06-04T18:55:05Z] <omanom> i had to do it as root
[2021-06-04T18:56:39Z] <omanom> i can confirm `alsactl restore` as normal user still segfaults like you got
[2021-06-04T18:58:38Z] <claudia> I stored as root. Restore as root gives me a permission error. http://ix.io/3oKT
[2021-06-04T18:58:41Z] <claudia> Funny
[2021-06-04T18:59:28Z] <claudia> But honstly I havent even noticed until u brough this up :]
[2021-06-04T19:00:16Z] <omanom> very interesting, i don't get that last error
[2021-06-04T19:00:16Z] <E5ten[m]> alright let's see if I can send this message through the matrix libera bridge
[2021-06-04T19:00:24Z] <omanom> got it E5ten!
[2021-06-04T19:00:29Z] <E5ten[m]> hell yeah
[2021-06-04T19:00:41Z] <omanom> welcome "back" :)
[2021-06-04T19:00:52Z] <E5ten[m]> thanks lol
[2021-06-04T19:01:51Z] <E5ten[m]> I joined like a couple days ago but kinda forgot IRC existed for a couple days cuz I've been studying for an exam, I'd joined multiple channels that moved to libera through the new bridge but hadn't actually sent a message in any of them until now
[2021-06-04T19:02:26Z] <E5ten[m]> so it's nice to have confirmed that works
[2021-06-04T19:03:56Z] <omanom> yes, i'm glad it didn't take too long for the libera bridge to get configured!
[2021-06-04T19:04:50Z] <E5ten[m]> yeah
[2021-06-04T19:29:17Z] <claudia> dilyn: I can reporduce https://github.com/kiss-community/kiss/issues/29
[2021-06-04T21:11:33Z] <dilyn> thanks for confirming claudia :)  
[2021-06-04T21:11:35Z] <dilyn> hi e5ten
[2021-06-04T21:12:37Z] <claudia> uw
[2021-06-04T21:13:18Z] <dilyn> re alsa problems. I'm pushing a couple more patches that should ensure all alsa errors relating to playback are fixed (there is going to be a bugfix release *soon*, apparently) 
[2021-06-04T21:14:17Z] <dilyn> as far as alsactl restore issues go, I *also* have one, that is nonfatal (related to ucm). doing alsactl -U restore ignores those errors (and is fine, because I don't use UCM) 
[2021-06-04T21:14:22Z] <dilyn> any other errors would be interesting to see tho
[2021-06-04T22:21:30Z] <sad_plan> dylin: is the landley guy still immensly difficult regarding managing the toybox project? I seem to recall there was some bak and forth about him making useless depencies for building it and so forth.. e5sten was also involver here iirc :p
[2021-06-04T22:24:03Z] <dilyn> it's not that he's difficult about it, he just has a vision for how the project should be built 
[2021-06-04T22:24:39Z] <E5ten[m]> yeah like I wouldn't call him difficult, I just disagree with some of his choices
[2021-06-04T22:24:43Z] <dilyn> he's requiring bash to build it because the point of toybox is that it will be able to bootstrap itself, and toysh is a bash replacement. so why bother with a POSIX build system when (eventually), it won't be a worry 
[2021-06-04T22:25:22Z] <dilyn> I'm mostly just annoyed that he won't make it POSIX buildable in the interim, considering how long toysh has been *pending* 
[2021-06-04T22:25:29Z] <E5ten[m]> sad_plan: in regards to the "still" part (rather than the "immensely difficult" part), I don't think he's changed his positions on any of that stuff
[2021-06-04T22:25:33Z] <dilyn> but like you said, e5ten (and some others) have graciously provided alternatives 
[2021-06-04T22:25:36Z] <E5ten[m]> dilyn: also hey!
[2021-06-04T22:25:40Z] <dilyn> o/ :)  
[2021-06-04T22:26:27Z] <sad_plan> aha. I see. I was just thinking about inits, and came to think about toybox, and this specific PR which I read a while ago
[2021-06-04T22:26:28Z] <sad_plan> https://github.com/landley/toybox/pull/182
[2021-06-04T22:26:38Z] <sad_plan> i belive it was this one though
[2021-06-04T22:27:55Z] <E5ten[m]> yeah that'd be the one
[2021-06-04T22:28:49Z] <sad_plan> yeah. I do agree that it would be preferable for it to be POSIX buildable, as dylin said. having stuff being portable is great. however, not everyone cares for it.
[2021-06-04T22:29:02Z] <E5ten[m]> but he also often rejects changes I propose that improve the portability of the C code (sometimes he merges, but he often rejects on the grounds that in practice, all the systems that are actually supported don't require the changes)
[2021-06-04T22:29:48Z] <dilyn> yeah
[2021-06-04T22:29:53Z] <dilyn> landley is in general very opinionated
[2021-06-04T22:29:57Z] <dilyn> and pragmatic
[2021-06-04T22:30:12Z] <sad_plan> so his purposefully rejecting portability based off of it being portable, basiclly
[2021-06-04T22:30:15Z] <sad_plan> I see :p
[2021-06-04T22:32:11Z] <sad_plan> changes based off... * not portability. wut
[2021-06-04T22:32:54Z] <dilyn> more that 'portability is not a concern because we aren't porting to anything where this isn't going to work anyways' 
[2021-06-04T22:33:29Z] <dilyn> it's like asking that #!/bin/env bash scripts comply with POSIX; that isn't (hopefully) what the target is 
[2021-06-04T22:34:42Z] <june> yeah you should just be asking that #!/bin/env bash scripts not exist :P
[2021-06-04T22:35:31Z] <dilyn> :)  
[2021-06-04T22:35:54Z] <sad_plan> ¯\_(ツ)_/¯
[2021-06-04T22:36:13Z] <sad_plan> ffs, did you have any other issues building recent ff?
[2021-06-04T22:36:28Z] <dilyn> other issues? no. still working on the previous one? yes 
[2021-06-04T22:36:33Z] <sad_plan> i get an error with 'new' file not found..
[2021-06-04T22:36:37Z] <sad_plan> oh ok
[2021-06-04T22:36:40Z] <dilyn> hm
[2021-06-04T22:37:14Z] <sad_plan> im trying to update it, with testusers LTO stuff, and ff is the only thing left really. but it fails.
[2021-06-04T22:37:43Z] <sad_plan> it first gave me an error about ccache it seemed, so I just removed it anyway. I can send you the log
[2021-06-04T22:38:46Z] <sad_plan> https://0x0.st/-_SV.txt
[2021-06-04T22:38:55Z] <sad_plan> maybe itll help you aswell
[2021-06-04T22:39:19Z] <dilyn> ah yes. I have that problem 
[2021-06-04T22:39:35Z] <sad_plan> is it just the same issue?
[2021-06-04T22:41:33Z] <dilyn> the same first issue at least; `10:54.19   cargo:warning=/home/wololo/.cache/kiss/proc/12519/build/firefox/obj-x86_64-pc-linux-musl/instrumented/dist/system_wrappers/type_traits:3:15: fatal error: 'type_traits' file not found
[2021-06-04T22:41:33Z] <dilyn> `
[2021-06-04T22:42:44Z] <sad_plan> hm
[2021-06-04T22:45:39Z] <dilyn> hm indeed. 
[2021-06-04T22:45:44Z] <dilyn> it's something supremely dumb, I'm almost certain 
[2021-06-04T22:46:41Z] <sad_plan> probably some minor bs that being missed. it usually is. 
[2021-06-04T22:48:21Z] <dilyn> yeah, i'm just missing something tiny. i've encountered this before :X  that's the most annoying part 
[2021-06-04T22:48:30Z] <dilyn> honestly I should be keeping notes on all this nonsense 
[2021-06-04T22:48:39Z] <midfavila> that's a mood.
[2021-06-04T22:49:41Z] <sad_plan> yes you most certenly should :p in any case, its never to late to start :D 
[2021-06-04T22:50:57Z] <dilyn> nope. I've gotten this far, obviously I have no need for notes :v 
[2021-06-04T22:52:14Z] <sad_plan> obviously :p lol
[2021-06-04T23:26:36Z] <dilyn> oh. urgh. hrmph. 
[2021-06-04T23:29:26Z] <dilyn> i assume clang doesn't look in /usr/include/c++/11.1.0 for c++ headers lmfao 
[2021-06-04T23:29:35Z] <dilyn> god I'm dumb. 
[2021-06-04T23:33:43Z] <sad_plan> are you implying that might fix it?:p
[2021-06-04T23:35:32Z] <dilyn> mhmm
[2021-06-04T23:35:47Z] <sad_plan> thats swell!
[2021-06-04T23:36:00Z] <dilyn> because type_traits absolutely exists, it's just not where clang is probably expecting it to be 
[2021-06-04T23:36:05Z] <dilyn> vamos a ver :)  
[2021-06-04T23:37:04Z] <sad_plan> ah, so by telling clang where it is, should fix the issue.
[2021-06-04T23:37:10Z] <sad_plan> what does that even mean? :p
[2021-06-04T23:37:25Z] <dilyn> vamos a ver? 
[2021-06-04T23:37:27Z] <dilyn> 'we will see' 
[2021-06-04T23:37:34Z] <sad_plan> aah. latin?
[2021-06-04T23:37:39Z] <dilyn> spanish
[2021-06-04T23:37:50Z] <sad_plan> ah
[2021-06-04T23:37:59Z] <sad_plan> did you take spanish in school or something?
[2021-06-04T23:38:35Z] <dilyn> mmhmm
[2021-06-04T23:39:12Z] <sad_plan> I didnt have that option. I wish I did, 'cause spanish is so much better than german.. or french for that matter
[2021-06-04T23:39:25Z] <dilyn> hablo un poco espanol, y menos rusa
[2021-06-04T23:39:33Z] <dilyn> spanish ain't shit lmfao 
[2021-06-04T23:39:36Z] <dilyn> I'd rather know french 
[2021-06-04T23:39:41Z] <sad_plan> haha why?
[2021-06-04T23:39:50Z] <dilyn> it's just far more interesting 
[2021-06-04T23:39:58Z] <dilyn> gramatically etc
[2021-06-04T23:40:11Z] <dilyn> tbf spanish gets more interesting the further you go; we got there after four years 
[2021-06-04T23:40:15Z] <dilyn> but russian was way cooler 
[2021-06-04T23:40:28Z] <sad_plan> but its horrible gramaticly and so much more. same is german. but I belive french is the worse
[2021-06-04T23:40:55Z] <sad_plan> russian is the way to go. I wouldve chosen that any day when I went in school :p
[2021-06-04T23:41:40Z] <dilyn> i spent good money to fail my russian classes :)  
[2021-06-04T23:42:21Z] <sad_plan> well aint that a waste. so school cost money in australia aswell, like in the US? 
[2021-06-04T23:43:17Z] <sad_plan> here school is free :p mostly anyway. I know theres some costs if you end up going to high school(?). but I dont belive theres neeearly as expensive as in the US :p