[00:02:52]
<Aleks (he/him/il/lui)> https://lwn.net/Articles/842319/ Interesting discussion about the feasability of packaging nodejs (or pip or similar stuff) -based software into Debian or distros in general
[00:18:54]
<Aleks (he/him/il/lui)> Imho we're kind of stuck until both a major distro like Debian decides to create a new modern packaging format which is as easy to adopt as Dockerfiles, AND we need a collective cultural shift in that you cant be a serious software project and yoloassume the setup has "whatever amount of RAM is necessary" and you cant yolorequire a major dependency which is less than say 6 months
[00:18:54]
<Aleks (he/him/il/lui)> Which imho ultimately boils down to "language-specific package managers and Docker have encouraged devs to not give a fuck about distribution in general and the distro-teams cant keep up with all the work this implies, despite the fact that distributions *are* quite important to, for example, have consistent security tracking and fixes" - or just simple upgrades in general
[00:26:55]
<Aleks (he/him/il/lui)> Or maybe unifying all the language-specific package managers idk x_x
[00:28:09]
<Aleks (he/him/il/lui)> #StuffThatAreNeverGoingToHappen
[00:31:51]
<Tag> yet another flatAppsnapImage ? 🤪
[00:40:28]
<Aleks (he/him/il/lui)> Yeah idk, never digged how flatpakappimagewhatever works, it doesnt seem to be a sensible distribution scheme like apt/dpkg/debian is/was with like a stable base with common dependencies etc
[00:43:02]
<Aleks (he/him/il/lui)> Imho it just feels like cyberecology : at the end of the day, if devs dont give a fuck about distribution, we're fucked, and having no modern + defacto standard encourages nobody and we're left with Docker which is just the big ugly solution of "lets add another layer of abstraction such that developers have their own individuak playground where they can ignore the complexity of distribution"
[00:43:03]
<Aleks (he/him/il/lui)> Imho it just feels like cyberecology : at the end of the day, if devs dont give a fuck about distribution, we're fucked, and having no modern + defacto standard encourages nobody and we're left with Docker which is just the big ugly solution of "lets add another layer of abstraction such that developers have their own playground where they can ignore the complexity of distribution"
[00:43:03]
<Aleks (he/him/il/lui)> Anyway, </rant> 😅
[00:47:38]
<Aleks (he/him/il/lui)> We really need something like DevOps but for packaging/distribution, like idk, "PackOps", " DistOps", break the dichotomy between dev and distribution, like Docker, but like, *not* Docker
[07:31:26]
<lapineige> > <@Alekswag:matrix.org> Yeah idk, never digged how flatpakappimagewhatever works, it doesnt seem to be a sensible distribution scheme like apt/dpkg/debian is/was with like a stable base with common dependencies etc
In this field, only appimage feel convinient and sensible to me, as you basically get a standalone executable and that's it.
[08:05:36]
<mrflos> > <@Alekswag:matrix.org> We really need something like DevOps but for packaging/distribution, like idk, "PackOps", " DistOps", break the dichotomy between dev and distribution, like Docker, but like, *not* Docker
I personnally start to dig into [Nix](https://www.adaltas.com/fr/2022/02/08/nixos-installation/), for now even if it's complex, it's really enjoyable, you can declare exact versions, services and environment vars per project, and rollback is working
[08:14:25]
<mrflos> (it can also be used for devops, CI/CD, packaging) , for example the packaging of nextcloud https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/web-apps/nextcloud.nix and the available options https://search.nixos.org/options?channel=23.05&from=0&size=50&sort=relevance&type=packages&query=services.nextcloud
btw, monorepo for packages seems great 😉
[08:18:37]
<selfhoster1312> > Or maybe unifying all the language-specific package managers idk x_x
you should really checkout nix/guix that's really what it's about, a universal (or rather, two universal) build/package system :)
(not saying it's really appropriate for yunohost packaging because it requires learning a new language, but it does fix the problem in an elegant way)
[08:19:58]
<mrflos> > <selfhoster1312> > Or maybe unifying all the language-specific package managers idk x_x
> you should really checkout nix/guix that's really what it's about, a universal (or rather, two universal) build/package system :)
> (not saying it's really appropriate for yunohost packaging because it requires learning a new language, but it does fix the problem in an elegant way)
same reaction 😉
[08:21:11]
<selfhoster1312> mrflos, personally i'm allergic to nix language, i find guix easier and more consistent (also in CLI UX)... but both have shortcomings in developer UX... my main gripe is that the two languages (nix and GNU/Guile) evaluate types at runtime like python so you end up with runtime exceptions :D
[08:21:47]
<selfhoster1312> if only we could have a statically-typed *ix (like rix for rust + nix?) that would be paradise and much more easier to get into for beginners like me :)
[08:25:43]
<selfhoster1312> btw Aleks (he/him/il/lui) when i was talking about making debian packages for apps i didn't mean high-quality debian packages that follow debian standards and can be easily upstreamed into debian proper... i just meant using the dependency/versioning system from deb packages so that we get updates when we need them...
example with invidious: https://github.com/selfhoster1312/invidious_ynh/blob/master/.github/workflows/ci.yml
^ here it's just a yolo-package that dynamically links to system dependencies but embeds crystal dependencies directly from crystal package manager (which is against debian rules)
[08:25:48]
<mrflos> > <selfhoster1312> if only we could have a statically-typed *ix (like rix for rust + nix?) that would be paradise and much more easier to get into for beginners like me :)
thanks for the feedback on differences between guix and nix, i didn't try guix for now, but yeah, at my level i'm not aware of benefits of statically typed languages, i'm from the php world, so yolo 😄
[08:27:18]
<selfhoster1312> mrflos, guix is nicer because it has a *real* programming language (instead of reinventing one) and has had 10 years after nix started to work out the CLI interface :) :)
otherwise it's really the same concept, but it's LISP all the way down
[08:28:41]
<selfhoster1312> (end off-topic about the first paradigm shift in packaging since the 70s :D)
[09:15:27]
<Tag> > <selfhoster1312> btw Aleks (he/him/il/lui) when i was talking about making debian packages for apps i didn't mean high-quality debian packages that follow debian standards and can be easily upstreamed into debian proper... i just meant using the dependency/versioning system from deb packages so that we get updates when we need them...
>
> example with invidious: https://github.com/selfhoster1312/invidious_ynh/blob/master/.github/workflows/ci.yml
> ^ here it's just a yolo-package that dynamically links to system dependencies but embeds crystal dependencies directly from crystal package manager (which is against debian rules)
I don't get it, we already create a meta-package with dependencies etc... while installing apt dependencies
[09:24:38]
<selfhoster1312> Tag, yes but:
- we recompile everything from scratch on every app update
- we don't update apps alongside debian packages, so every major debian release can break compiled apps (because of glibc/openssl/etc incompatible ABI)
[09:25:53]
<selfhoster1312> now that i have invidious packages for bullseye/bookworm for amd64/arm64 architectures https://github.com/selfhoster1312/invidious_ynh/releases/tag/v2023.11.07-1824
i plan to make a proper debian repo to test that upgrading to bookworm upgrades invidious package too and breaks nothing :)
[09:26:07]
<selfhoster1312> maybe it's not the best way, i'm just exploring
[09:26:28]
<selfhoster1312> an alternative could be to produce builds for both debian releases like i did, and trigger reinstall of all apps after major debian upgrade???
[11:58:19]
<Aleks (he/him/il/lui)> hmm github webhooks are broken i guess
[11:58:50]
*tituspijean hides in the bush
[11:59:46]
<tituspijean> service restarted, but repeatedly fails
[12:00:36]
<Yunohost Git/Infra notifications> 🏗️ Starting build for yunohost/11.2.5+202311081200 for bullseye/unstable/all ...
[12:03:08]
<tituspijean> (still failing, I dunno where this comes from)
[12:03:13]
<Yunohost Git/Infra notifications> ✔️ Completed build for yunohost/11.2.5+202311081200 for bullseye/unstable/all.
[12:04:31]
<tituspijean> `No module named 'sanic'`, yeah sure...
[12:04:39]
<Aleks (he/him/il/lui)> similar to the autoreadme, had to recreate the venv
[12:04:41]
<tituspijean> ooooh nooooo
[12:04:45]
<Aleks (he/him/il/lui)> and then stuff exploded because of sanic's version
[12:04:45]
<Aleks (he/him/il/lui)> zzblerg
[12:04:49]
<tituspijean> I deleted the admin user, and guess who the service requires...
[12:05:04]
<tituspijean> but that doesn't fix the missing sanic lib
[12:05:47]
<tituspijean> creating a `webhooks` user then...
[12:06:34]
<Aleks (he/him/il/lui)> 😬
[12:06:45]
<Aleks (he/him/il/lui)> #howwasitevenworkingbefore
[12:11:14]
<tituspijean> 🪄
[13:31:39]
<Yunohost Git/Infra notifications> [yunohost] @tituspijean [commented](https://github.com/YunoHost/yunohost/pull/1740#issuecomment-1801897526) on [issue #1740](https://github.com/YunoHost/yunohost/pull/1740) Translations update from Weblate: (testing the webhooks)
[13:32:05]
<Yunohost Git/Infra notifications> [yunohost] @tituspijean [commented](https://github.com/YunoHost/yunohost/pull/1740#issuecomment-1801897526) on [issue #1740](https://github.com/YunoHost/yunohost/pull/1740) Translations update from Weblate: (testing the webhooks)
[13:32:54]
<tituspijean> I put a bit of a stupid version requirements, and patched the script to give the Sanic() instantiation a `name` attribute
[13:40:50]
<tituspijean> > <@yunohostinfra:matrix.org> [yunohost] @tituspijean [commented](https://github.com/YunoHost/yunohost/pull/1740#issuecomment-1801897526) on [issue #1740](https://github.com/YunoHost/yunohost/pull/1740) Translations update from Weblate: (testing the webhooks)
mmmh, we should handle the `delete` action 😕
[15:19:49]
<Aleks (he/him/il/lui)> https://github.com/creativeprojects/resticprofile :o
[15:36:47]
<Aleks (he/him/il/lui)> The more i learn about restic the more it seems better or equivalent to borg ? The ability to use "passive" S3 etc sounds like a big deal ?
[15:56:49]
<ljf> In the past, there was performance issues with >1TB .
[15:57:01]
<ljf> I don't know if it's still the case
[15:58:01]
<ljf> But yes restic is a good solution too, and it could be use to send the backup into a Garage cluster...
[16:04:40]
<lapineige> > <@Alekswag:matrix.org> The more i learn about restic the more it seems better or equivalent to borg ? The ability to use "passive" S3 etc sounds like a big deal ?
What's a passive S3 ?
[16:06:01]
<lapineige> > <@ljf:sans-nuage.fr> But yes restic is a good solution too, and it could be use to send the backup into a Garage cluster...
Right now I'm trying to configure that, but without a cluster (only 1 server for now), it's not easy 😅
[16:06:16]
<Aleks (he/him/il/lui)> s3 storage is, as far as i understand it, a standardized way to expose a storage place over network, and i mean "passive" because it basically has no complex mechanism in opposition to borg which require to have a specific borg-server running on the other side
[16:40:58]
<lapineige> Oh yeah you mean it's agnostic considering the backup used, as long as it supports S3
[16:42:02]
<lapineige> Indeed, that's a strong advantage if the other server is not based on Yunohost (borg support not guaranteed)
[18:11:57]
<Yunohost Git/Infra notifications> [yunohost-portal] @Axolotle pushed 5 commits to main ([fd95f788c90e...fe29d6db9163](https://github.com/YunoHost/yunohost-portal/compare/fd95f788c90e...fe29d6db9163))
[18:12:03]
<Yunohost Git/Infra notifications> [moulinette] @Axolotle pushed 1 commit to bookworm: cors: fix some http response error not being catched by cors decorator ([924fd782](https://github.com/YunoHost/moulinette/commit/924fd7825e3e43d53daeb7c33e7ff1d7816bc223))
[18:15:25]
<Yunohost Git/Infra notifications> 🏗️ Starting build for moulinette/12.0.0+202311081815 for bookworm/unstable/all ...
[18:17:29]
<Yunohost Git/Infra notifications> ✔️ Completed build for moulinette/12.0.0+202311081815 for bookworm/unstable/all.
[18:17:38]
<Yunohost Git/Infra notifications> 🏗️ Starting build for yunohost-portal/12.0+202311081815 for bookworm/unstable/all ...
[18:23:47]
<Yunohost Git/Infra notifications> ✔️ Completed build for yunohost-portal/12.0+202311081815 for bookworm/unstable/all.
[19:48:06]
<selfhoster1312> yeah s3 is just blob storage, no folders/tags (though you can implement it on top), just id => content
[19:48:49]
<selfhoster1312> axolotle, making patches on the new alpha portal? :)
[20:06:04]
<axolotle> selfhoster1312: i'm trying to finish the front-end ; ) still some error management and translation but it should be testable very soon
[20:21:23]
<selfhoster1312> nice axolotle
[20:21:41]
<selfhoster1312> weird request here but do you plan to make it usable without javascript? (and make it lighter at the same time ^^)
[20:21:59]
<selfhoster1312> i'm all for tailwind if that makes you happy but for simple pages i really don't see any advantage for JS :(
[20:23:54]
<selfhoster1312> i had a beginning of something here inspired by the new portal: https://github.com/selfhoster1312/yunohost-portal-noscript
it was ~20x lighter (20KB vs 460KB) according to my last measurement here: https://github.com/YunoHost/issues/issues/2028#issuecomment-1679259138
[20:26:03]
<axolotle> well yeah it is probably overkill, i guess we can iterate later on a simpler js frontend (just vue with unocss for an easy development experience)
[20:26:36]
<axolotle> but it wont work without js...
[20:27:08]
<selfhoster1312> tailwind has nice property that you can "precompile" it so it works on all browsers and doesn't eat resources :D
[20:27:14]
<selfhoster1312> it's just CSS at the end of the day ^^
[20:28:03]
<axolotle> i'm in favor of custom portals "apps" but idk how it will be possible
[20:28:23]
<selfhoster1312> idk i mean i'd be willing to take some time for this issue (i'll have more time in the coming weeks) to try and find a solution that makes everyone happy but breaking noscript even for the most basic login page sounds real bad for me :-/
[20:29:07]
<selfhoster1312> axolotle, it should be possible! the fact that i made this yunohost-portal-noscript repo shows it although we have some debates about CSRF ^^
[20:32:09]
<axolotle> yes i've seen it! i guess this should be available as an option somewhat (like an app that you can install to replace the default js portal app)
[20:33:19]
<selfhoster1312> sry i don't mean to be dismissive but the real question for me is why would you add JS in the first place on the main portal? :-/
[20:33:35]
<axolotle> i thought a webapp with a common framework would have been easier to improve/maintain
[20:33:45]
<selfhoster1312> hmmm, you think adding a new language makes it easier ? :-/
[20:34:06]
<axolotle> without another service to run beside the portal api
[20:34:32]
<axolotle> well it's more or less the same as the webadmin
[20:34:59]
<selfhoster1312> maybe that's because i started making web pages before javascript was a thing but i always find it easier tojust have html+css ^^"
[20:35:21]
<selfhoster1312> but yes there's always a server-side component, whether it's a JSON API or HTML "API" :)
[20:37:00]
<selfhoster1312> anyway nice to see you're making changes, can't wait to try the new version :D
[20:42:37]
<axolotle> yeah i'm actually in favor of simplicity, but adding another service was maybe overkill since there's already the api
[20:43:14]
<axolotle> the idea was to add some more functionnality which can be challenging to develop without js frameworks
[20:45:02]
<axolotle> in terms of ux, reactivity is quite interesting, even for a11y
[20:45:45]
<axolotle> i hope we can implement the possibility to install other portal easily
[20:47:37]
<axolotle> and maybe we will go back to some server-side stuff, but for me the `no-script` is quite difficult to obtain even with a server-side site
[22:00:59]
<Yunohost Git/Infra notifications> [issues] @stilobique labeled :space_invader: bug on [issue #2282](https://github.com/YunoHost/issues/issues/2282): Error with the POP3 activation
[22:01:01]
<Yunohost Git/Infra notifications> [issues] @stilobique opened [issue #2282](https://github.com/YunoHost/issues/issues/2282): Error with the POP3 activation
[22:26:48]
<Aleks (he/him/il/lui)> > <selfhoster1312> sry i don't mean to be dismissive but the real question for me is why would you add JS in the first place on the main portal? :-/
basically the rationale was:
- we want to have a generic "portal API" on top of which any front end can be built
- at the same time, we need a default portal which interacts with this API
- so either we go for server-side rendering which creates the need for a new additional daemon
- or we go for client-side rendering with JS that interacts with the API
- we went for the client-side rendering in part because i'm paranoid about having "yet another daemon" which is "yet another reason stuff may crash because of OOM or random lib issues"
- and because JS is not evil in essence (even though we all know the current state of web bloated with JS etc)
[22:27:44]
<Aleks (he/him/il/lui)> (and yes being able to create no-JS frontends is a relevant side quest)
[22:42:54]
<Tag> and nothing prevent us from developing another portal front-end which will use server-side rendering, if you want no js
[22:44:49]
<Tag> (or a generated static portal, etc...)
[23:35:40]
<selfhoster1312> > in terms of ux, reactivity is quite interesting, even for a11y
curious what's reactivity?
[23:36:57]
<selfhoster1312> > creates the need for a new additional daemon
curious why it couldn't be the same portal-api daemon? almost all code is already there except for a bit of templating
[23:38:18]
<selfhoster1312> > (or a generated static portal, etc...)
haha i need to get back to this but i had a prototype for exactly this :) :)
can't beat static pages for speed/reliability :D
[23:39:38]
<selfhoster1312> i mean unless you have 10000 users it certainly is more interesting to generate the pages just once instead on every page load ^^
[23:41:51]
<selfhoster1312> i also had a server-rendered page written in rust which told me if i had unread mails... that's a silly feature but i love it
[23:42:08]
<selfhoster1312> https://xmpp-upload.kl.netlib.re/upload/wY25nEDfkrVp6928/Capture%20d%e2%80%99%c3%a9cran%20du%202023-11-09%2000-41-40.png
[23:42:15]
<selfhoster1312> ^ of course i still have unread emails :(
[23:42:36]
<selfhoster1312> i should replace this "you got mail" light with a proper counter to keep track ^^
[23:45:41]
<selfhoster1312> more experiments to finish, only 24h in a day... :(