03:39 <midfavila> riteo: acquire immediately one (1) backup 4g connection

03:39 <midfavila> otherwise its all et finito

14:38 <riteo> midfavila: that's a really good tip but I don't think I'm going to convince my parents easily to buy a 4g plan, let alone any logisticical related things

16:10 <midfavila> :P

16:10 <midfavila> unrelated holy shit i'm going to find whoever created OMEMO and fucking kill them

16:10 <midfavila> like i'm going to reach through their computer screen and rip their throat out

16:11 <midfavila> xmpp as an ecosystem has the same shit wrong with it that matrix does

16:12 <midfavila> the core protocol has zero features so everyone implements a shitload of extensions but they all implement different extensions and in different ways that are subtly incompatible because there's no standardized module system or anything

16:12 <midfavila> and it's like, bruh

16:12 <midfavila> what the fuck

16:12 <thomas_adam> Is it?

16:12 <midfavila> how hard is it to just shell out to a program to encrypt and decrypt messages

16:23 <thomas_adam> midfavila: Because that will incur quite a bit of overhead.

16:26 <midfavila> well, sum total, of course, but really you're just spawning a new process. i know that i'd trade off having a little overhead for keeping my sanity

16:26 <midfavila> either way, i'm just running my mouth

16:39 <thomas_adam> But that would have a tonne of overhead of FDs, I/O, etc. It's not a good design at all. Not for something like a messaging protocol which is designed to operate at scale. It's like trying to cut down a tree with a bread knife...

16:41 <midfavila> yeah, at scale it would be a disaster. i'm just annoyed with xmpp and specifically the XEPs implemented for libpurple atm, that's all.

16:57 <thomas_adam> OK.

17:03 <thomas_adam> midfavila: You can imagine something analogous to why the message/exec approach would suck: Style * InitialMapCommand Foo\nDestroyFunc Foo\nAddToFunc Foo\n+ I All Exec exec xterm\n+ I All (XTerm) Exec exec xterm

22:01 <midfavila> hmm. did core/musl change recently? git fails because the regex.h that comes with kiss' default build lacks REG_STARTEND. modifying config.mak in git/build to indicate that as per git's failure message doesn't fix the issue either. worst case i patch musl for now but i wanted to know if this is like

22:02 <midfavila> a thing

22:02 <midfavila> or if it's a weird issue in my system. alpine/gentoo/etc experience it as well but i've never run into this under kiss.

22:43 <sad_plan> musl hasnt changed in the last 8 months, so I wouldnt say recently

22:43 <sad_plan> atleast for kiss that is

22:44 <sad_plan> which version are you using of git? latest?

22:44 <sad_plan> could have a look here, if youve missed something on your end https://codeberg.org/kiss-community/repo/raw/branch/master/core/git/build

22:49 <midfavila> just pulled repo like two days ago

22:49 <midfavila> so whatever version that references

22:49 <midfavila> lemme check

22:49 <midfavila> 2.47.0

22:50 <midfavila> and i mean i shouldnt be missing everything. i have basically 100% stock upstream builds running now

22:51 <midfavila> the only non-upstream bit is the toolchain.

22:53 <midfavila> s/every/any/

22:53 <midfavila> jesus its been a long couple of days

22:56 <midfavila> honestly at this point i just want to figure this out and be done with it

22:56 <midfavila> it's maddening that even with the proper options in config.mak set it just doesn't seem to give a damn