00:56 <whitequark> fwiw most likely I'll have time to really dig into ChiPass code this Sunday, unless the stuff I'm doing before that ends up dragging for longer than I expect

00:57 <whitequark> I have like two months of OSS maintenance backlog to catch up after the ILR application, plus my day job

14:14 <illybytes> anyone here wanna review PR #58? it changes the path for gui socket on XDG platform to use the runtime dir :

14:14 <illybytes> :3c*

14:33 <binwoes> illybytes: i've done an initial review but i am likely going to sleep soon, so merging may have to wait until some later time (unless someone else gets around to it :P)

14:34 <illybytes> thanks for the review :3

14:35 <illybytes> rn fixing up thr code cus it apparently doesnt work lol

14:35 <illybytes> fixed the macro issues + trying to fix it not using the code path where its on a unix system

14:35 <illybytes> for some reason its skipping that??

14:36 <binwoes> there's an #endif before your #else block

14:41 <illybytes> yeah i have noticed that

14:41 <illybytes> also it not working is because flatpak is being stupid and not installing the bunfle at all

14:41 <illybytes> the version instead is built 30 minutes ago

14:42 <illybytes> whichh is before any of these changes lol

14:43 <illybytes> for some weird reason flatpak is refusing to bundle the latest commit????

14:44 <illybytes> im just gonna remove repo build and .flatpak-builder

15:40 <illybytes> hmmm it seems like it either chooses to do /tmp or dead locks randomly with my local patch

15:40 <illybytes> super duper strange

15:41 <illybytes> welp, ima let someone else more knowledgeable figure that out x.x

15:41 <illybytes> chipass seems to just work normally without even need /tpm access, idk why it ever needed it??

15:41 <illybytes> tmp*

15:42 <illybytes> it has its own /tmp it uses on flatpak

15:58 <binwoes> i do like the idea of avoiding usage of /tmp if we can avoid it (regardless of Flatpak, it just seems like a better design choice)

16:01 <aks> what i learned some time ago is that if i need something personal cached, i should use ~/.cache and not /tmp

16:12 <binwoes> "According to documentation we should use RuntimeLocation on *nixes, but even Qt doesn't respect this and creates sockets in TempLocation, so let's be consistent."

16:12 <binwoes> i wonder if this quote is still accurate on Qt6

16:17 <binwoes> it does kind of annoy me that Qt does a silent fallback to a tempdir without explicitly stating it in the documentation (at least, nowhere i've seen) since i'm not sure if it's a behaviour i can rely on to continue existing in the future

16:18 <binwoes> (this feels like 'implementation detail', and i do not consider those to be stable in any meaningful manner)

16:27 <illybytes> hmm alright, i wonder, how would we detect if it fails somehow? we can always check if its an empty string, but what if the implementation just gives us a directory that we dont have access to?

16:33 <binwoes> i think iff QStandardPaths::writableLocation(QStandardPaths::RuntimeLocation).empty() we fallback to QStandardPaths::writableLocation(QStandardPaths::TempLocation), because this is guaranteed to not be empty

16:33 <binwoes> at this point there is still a chance that m_lockFile->tryLock(); fails, which is an existing failure condition and i'm not certain of the best way to handle it

16:35 <binwoes> i should really get to bed and then consider design choices after i've slept though, judging by my inability to spot the usage of QDir::tempPath() ^^