[04:22:25]
<luke> > looks like the release tarball was changed so the checksum doesn't match?
Yeah I added it to issues in git and it’s been fixed
[21:06:16]
<Fritjof> No worries :)
I tried that, and got:
CodeIgniter v4.4.1 Command Line Tool - Server Time: 2023-11-06 21:05:10 UTC+00:00
Command "castopod:update-database" not found.
[21:07:32]
<Fritjof> then I tried writing "castopod:database-update" instead, as suggested by the propmpt, and got this:
CodeIgniter v4.4.1 Command Line Tool - Server Time: 2023-11-06 21:06:43 UTC+00:00
[21:09:22]
<Fritjof> I tried just running this:
sudo -u castopod php8.2
[21:25:31]
<orhtej2> > <@fritjof:deepfunk.dk> then I tried writing "castopod:database-update" instead, as suggested by the propmpt, and got this:
> CodeIgniter v4.4.1 Command Line Tool - Server Time: 2023-11-06 21:06:43 UTC+00:00
>
Hmm, no pending updates? It's this one is instances broken by previous rollout of 1.6.5? Because I don't think there's a way to recover from it :/
[21:47:22]
<Fritjof> > Hmm, no pending updates? It's this one is instances broken by previous rollout of 1.6.5? Because I don't think there's a way to recover from it :/
😕 - I don't remember it being broken before.
[21:48:08]
<orhtej2> > <@fritjof:deepfunk.dk> 😕 - I don't remember it being broken before.
Hmmm you upgraded from what version?
[21:48:41]
<Fritjof> my current version is this: Installed version: 1.6.5~ynh1
[21:49:24]
<Aleks (he/him/il/lui)> please folks if you could just *not* use matrix threads that would be awesome ... matrix threads are the worst notifcation UX ever
[21:49:52]
<Aleks (he/him/il/lui)> like people have to open the thread even if they dont care about the discussion to mark the room as "not unread"
[21:50:10]
<Fritjof> ah pardon. I did it thinking it would be less annoying for everybody else
[21:50:23]
<Aleks (he/him/il/lui)> yeah it's like .. the opposite
[21:50:34]
<Aleks (he/him/il/lui)> until Matrix fixes them somehow idk
[21:51:06]
<Fritjof> orhtej2: continuing Castopod issues.
My server now says this:
mysqli_sql_exception #2006
MySQL server has gone away
at /var/www/castopod/vendor/codeigniter4/framework/system/Database/MySQLi/Connection.php:306
[21:52:05]
*selfhoster1312 bad mouthing that we won't have to suffer matrix threads much longer as they are being forked into oblivion + contributors license agreement by Element corporation 🍿️
https://mastodon.matrix.org/@matrix/111363858784535894
[21:52:55]
<Aleks (he/him/il/lui)> thank god
[21:52:58]
<orhtej2> > <@fritjof:deepfunk.dk> my current version is this: Installed version: 1.6.5~ynh1
Ux on this is bad as there were 2 distinct 1.6.5 rollouts
[21:53:13]
<orhtej2> When did you upgrade
[21:55:02]
<Fritjof> orhtej2: moving out of the thread here. I upgraded about two-three days ago, I think
[21:55:45]
<orhtej2> > <@fritjof:deepfunk.dk> orhtej2: moving out of the thread here. I upgraded about two-three days ago, I think
Hmm that was not supposed to break, do you still have upgrade logs available?
[21:55:56]
<orhtej2> What table is missing?
[21:57:43]
<Fritjof> > Hmm that was not supposed to break, do you still have upgrade logs available?
no. It seems to have been more than 5 days ago then. Sorry for being unprecise, the past few weeks have been busy.
[21:57:46]
<selfhoster1312> Aleks (he/him/il/lui), you're gonna hate me now that i have static invidious builds successfully for aarch64/x86_64 i'm trying the debian package approach you were cursing :D :D
(because it's still nice to be able to update openssl for security patches every now and then, and having a proper debian package would allow seamless migration across debian releases without breaking the binaries)
[21:58:01]
<selfhoster1312> 👹️
[22:06:00]
<Fritjof> > <@fritjof:deepfunk.dk> no. It seems to have been more than 5 days ago then. Sorry for being unprecise, the past few weeks have been busy.
I have a 6 day old backup that I am now trying to restore, to see if that can help the problem.
[22:07:50]
<Aleks (he/him/il/lui)> > <selfhoster1312> Aleks (he/him/il/lui), you're gonna hate me now that i have static invidious builds successfully for aarch64/x86_64 i'm trying the debian package approach you were cursing :D :D
> (because it's still nice to be able to update openssl for security patches every now and then, and having a proper debian package would allow seamless migration across debian releases without breaking the binaries)
"seamless migration" you mean like the ... seamless migration we have between every major debian upgrade ? x_x
[22:08:15]
<Aleks (he/him/il/lui)> even python virtualenv are supposed to be "seamless" and are in fact somehow tight-coupled to dist packages
[22:08:53]
<Aleks (he/him/il/lui)> it's 2023, there are probably dozens of packaging format similar to debian which achieve the same thing but are hella more modern
[22:09:26]
<Aleks (he/him/il/lui)> like uh idk AppImage seemed to be decent from what you showed me
[22:12:00]
<selfhoster1312> yeah the static build is a kind of appimage (even though an appimage usually bundles more than the binary) and it works great
[22:13:12]
<selfhoster1312> we just don't have magical security updates anymore with that approach, and it's harder to build an appimage without an automated tool like nix-appimage which requires higher capabilities when running the daemon (to mount the virtual FS)... not impossible though that's what peertube folks did with prosody for peertube chat plugin for example :)
[22:13:51]
<selfhoster1312> but that's the fully static build with musl if you wanna try: https://github.com/selfhoster1312/invidious_ynh
(tested on amd64/arm64 on real hardware) :)
[22:15:19]
<selfhoster1312> anyway for now i'm *exploring* these different options i'll post my results soon :) :)
[22:30:28]
<Aleks (he/him/il/lui)> > <selfhoster1312> but that's the fully static build with musl if you wanna try: https://github.com/selfhoster1312/invidious_ynh
> (tested on amd64/arm64 on real hardware) :)
seems definitely way too complex, and im not even sure what the specifications are before jumping into implemention, but i'm pretty sure "this needs to be understandable-ish without 3 PhD in build systems" is somewhere in there, and "mixing debian packaging, yaml and make" is certainly a no-go for this
[22:32:57]
<Aleks (he/him/il/lui)> or if it's complex, it needs to be justified by something silver-bullet~ish, ie if i understood correctly, AppImage are self-sufficient so that's a huge bonus in terms of "simplifying all the dependency management and not risking to conflict with other stuff"
[22:36:29]
<Tag> we need a #yunohost-offtopic or something /o\
[22:36:43]
<Aleks (he/him/il/lui)> yeah that should actually be in -dev 😬 sry
[22:36:51]
<Tag> np np
[22:37:26]
<Tag> (or we need a #yunohost-memes even maybe idk)
[22:37:57]
<Tag> we definitely need a yunohost.org/memes page
[22:42:18]
<Aleks (he/him/il/lui)> > * <@_bifrost_selfhoster1312=2fsupport=40conference.yunohost.org:aria-net.org> bad mouthing that we won't have to suffer matrix threads much longer as they are being forked into oblivion + contributors license agreement by Element corporation 🍿️
> https://mastodon.matrix.org/@matrix/111363858784535894
actually ... wtf o.O
[22:42:31]
<Tag> yeah!! that's huge
[22:43:12]
<Tag> forking synapse doesn't look like a real good move but I get it
[22:43:56]
<Aleks (he/him/il/lui)> uuuugh yeah i feel kinda not comfortable with the idea
[22:44:02]
<Aleks (he/him/il/lui)> sounds like an XMPP-ish move
[22:45:30]
<Aleks (he/him/il/lui)> im not sure to understand why this happens from the blog post
[22:46:08]
<Tag> I would say that Element and the Foundation have different goals
[22:47:20]
<selfhoster1312> RE: XMPP-ish move, can you name one client that was open source, has taken VC money and started making moves like this? nah in XMPP world all dirty moves happen from proprietary clients :D :D (whatsapp, zoom, etc..)
[22:47:23]
<selfhoster1312> but yes sorry for the -dev offtopic ^^
[22:47:42]
<selfhoster1312> (and of course the idea is to prevent PhD-gating packaging :D)
[22:51:47]
<Aleks (he/him/il/lui)> XMPP-ish move in the sense of "let's make sure there is no default implementation / de-facto standard for both the servers and clients such that even XMPP fans don't know what you should be installing to have decent UX even 20 years later" 😅 #ThisShouldDefinitelyGoIntoAnOffTopicChannel
[22:53:27]
<Tag> #yunofftopic
[23:00:12]
<selfhoster1312> > (EDIT: to be clear, the sole reason for a CLA is to allow Element to dual-license the software as per https://gnu.org/philosophy/selling-exceptions.html - not to give Element the ability to relicense to a non-OSI license in future. After all, Element already had that ability with the Apache license, and has not used it.)
maybe i was bad-mouthing after all :)
[23:24:21]
<tituspijean> _Impromptu server reboot folks, main applications like Website, Install script, DNS, Forge may be down._
[23:24:45]
<ninchuka> > <@Alekswag:matrix.org> im not sure to understand why this happens from the blog post
Companies/projects are using synapse/dendrite without contributing to matrix or to synapse/dendrite so that's AGPL and the CLA is so element/new vector can sell them to company's under different licences if they don't like AGPL
[23:44:19]
<Monitor Kernel Access> > <selfhoster1312> > (EDIT: to be clear, the sole reason for a CLA is to allow Element to dual-license the software as per https://gnu.org/philosophy/selling-exceptions.html - not to give Element the ability to relicense to a non-OSI license in future. After all, Element already had that ability with the Apache license, and has not used it.)
> maybe i was bad-mouthing after all :)
I avoid element like the plague for two reasons
1. Corpo crapware
2. Endorses cops openly
[23:44:28]
<selfhoster1312> ninchuka, yeah that's why the CLA is a huge disappointment to the community... AGPL is great for driving revenue & ecosystem, if you allow non-free derived products it's not clear that it's a winning situation for the ecosystem (although that's certainly a winning situation for the company holding the CLA)