[16:27:41]
<Aleks> >Me: \[suggest fix\] and see if `ping google.com -c1` is happier
>User:
```# ping google.com -c1 is happier
ping: happier: No address associated with hostname```
I have no words
[16:28:19]
<Aleks> > Me: \[suggest fix\] and see if `ping google.com -c1` is happier
> User:
>```
>$ ping google.com -c1 is happier
>ping: happier: No address associated with hostname
>```
I have no words
[16:28:36]
<tituspijean> `ping worldpeace`
[16:28:46]
<tituspijean> Damn. 😑
[18:20:47]
<Aleks> alrighty, i pushed some super yolo commits to fix all the annoying issues
[18:21:02]
<Aleks> but completely untested, because otherwise where's the fun in that 🎵
[19:52:11]
<Dante> Hi 😄 does anyone know if the `ynh_use_logrotate --nonappend` option works on latest Yuno? I had this issue report recently https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh/issues/59 I tried to fix it using `--nonappend` but it only seemed to work when I used `--non-append` which is supposed to be legacy option 🤷♂️ any help would be appreciated 😄
[20:05:16]
<Aleks> Dante: not sure either and i don't know much about these ... But I'm very confused like, in what case would one append ? I mean why wouldnt we _always_ want to replace the entire file ?
[20:06:40]
<Aleks> ah because sometimes there are multiple log files
[20:06:53]
<Aleks> hmpf this is shitty design
[20:09:46]
<Aleks> only a bunch of apps use `ynh_use_logrotate` in upgrade script without `--non-append` (or `--nonappend`) option ... sounds like a bug ...
[20:12:46]
<Aleks> anyway it makes no sense that the legacy option would work better than the modern option é_è
[20:13:40]
<Dante> > <@Alekswag:matrix.org> only a bunch of apps use `ynh_use_logrotate` in upgrade script without `--non-append` (or `--nonappend`) option ... sounds like a bug ...
yeah I saw that :/ but I tried to check the helper code but didn't really get why `--nonappend` wouldn't work... it seemed fine to me
[20:14:34]
<Aleks> maybe in the full log we can see what exactly happens inside the helper
[20:15:10]
<Aleks> ... if you read bash debug fluently ... which is ... a more advanced skill than just being fluent in bash ... which is already a skill only sadomasochists aim for
[20:15:45]
<Dante> 😂😂
[20:16:55]
<Dante> I will give it another shot and try to debug it a bit further but yeah bash debug sucks
[20:17:13]
<Aleks> Renaissance folks trying to understand bash debug outputs: https://i.imgflip.com/eo62r.jpg
[20:17:30]
<Dante> hahahaha
[20:17:48]
<Dante> good thing is I'm used to wander around Hell
[20:18:16]
<Dante> but wish me luck anyways 😂
[20:23:09]
<Aleks> https://i.imgflip.com/6puzty.jpg
[20:23:44]
<Dante> 😂😂😂
[20:27:13]
<Aleks> https://i.imgflip.com/6pv090.jpg
[20:27:38]
<Aleks> (sorry, i get carried away when i start meming)
[20:30:57]
<Dante> hahahaha
[20:31:15]
<Dante> they help getting a better mood before that debugging session
[20:32:23]
<kayou> > <@Alekswag:matrix.org> Support right now be like : "Immatriculer une galère ?! Je vous ai déjà dit que le port est au bord de la mer !"
https://c.tenor.com/GZVsGe8KU7wAAAAd/la-maison-qui-rend-fou-maison-des-fous.gif
[20:33:30]
<Aleks> accurate representation of the forum right after any debian migration gets released 👍️
[20:33:48]
<kayou> https://github.com/YunoHost/yunohost/commit/3cb1a41aa8acd352c95ecd94900b5ad9fec86aff
[20:33:48]
<kayou> FYI
[20:34:22]
<Aleks> holy cow
[20:41:13]
<Aleks> yeah it always crashes somehow like a few hours after getting restarted...
[20:41:13]
<kayou> metronome is down in saperlipopette:
```
cat /var/log/metronome/metronome.err
Aug 13 18:10:23 adns error Exhausted all 1 configured DNS servers, next lookup will try 127.0.0.1 again
```
```cat
cat /var/log/metronome/metronome.log
[...] a bunch of:
Aug 13 20:37:01 socket debug accepted incoming client connection from: 127.0.0.1 36722 to 5290
Aug 13 20:37:01 socket debug try to close client connection with id: 5561841e1f60
Aug 13 20:37:01 socket debug closing delayed until writebuffer is empty
Aug 13 20:37:01 socket debug closing client after writing
Aug 13 20:37:01 socket debug closing client with id: 5561841e1f60 client to close
```
[20:41:27]
<tituspijean> Might be related to the work I did with Maranda. Now the MUC is hosted by him. But I may have broken something...
[20:43:07]
<tituspijean> I basically commented out the MUC settings in metronome, and changed DNS on OVH to point to aria-net
[20:43:07]
<kayou> i restart it every days for a week
[20:43:07]
<tituspijean> kayou: ^
[20:44:53]
<kayou> but matterbridge still use metronome in saperlipopette
[20:46:24]
<tituspijean> Can matterbridge connect to metronome without the MUC being hosted locally?
[20:46:54]
<Maranda> And yes it can
[20:46:54]
<Maranda> 🤔
[20:46:54]
<kayou> i have 0 knowledge on how all this stuff works
[20:47:42]
<Maranda> It's a bot it just needs a valid xmpp account to connect to
[20:50:27]
<Maranda> I'll try to sort out the crashes in the 4.0.0 release since I also moved from lua5.2 to lua5.3
[20:50:37]
<kayou> ```
> cat matterbridge.toml
[...]
[xmpp]
[xmpp.jabber]
Server="localhost:5222"
[...]
Muc="conference.yunohost.org"
```
[20:50:37]
<kayou> ```
> cat matterbridge.toml
[...]
[xmpp]
[xmpp.jabber]
Server="localhost:5222"
[...]
Muc="conference.yunohost.org"
[...]
```
[20:51:46]
<Maranda> kayou: the server string needs to be obviously changed but you don't Need matterbridge anymore anyways
[20:51:56]
<Maranda> Bifrost does the bridging
[20:52:49]
<Maranda> The IRC bridge bridges to Matrix and Bifrost bridges that to XMPP
[21:07:56]
<kayou> because it's not the case (same for matterbridge btw)
[21:09:27]
<Curator> it's not?
[21:12:02]
<kayou> hmm ok
[21:13:52]
<Curator> So now that I'm hosting the MUC maybe I can figure out *why* it's crashing.
[22:30:36]
<Maranda> .
[22:34:04]
<Curator> Okay the XMPP server should have stabilized
[22:34:59]
<Curator> I guess one of the crashing reasons could be dnsmasq or unbound or whatever other DNS resolver you have on the system is rate limiting requests (hence the resolution failed errors)
[22:35:43]
<Curator> with Bifrost restarting I had Metronome at 100% CPU for a while
[22:35:56]
<Curator> (for the single core it can use)
[22:42:04]
<Aleks> uuuuh https://yunohost.org/fr/images ... can anybody confirm that our new RPi image is for RPi 3 / 4 (arm64) only .. ?
[22:42:13]
<Aleks> ( ljf ?)
[22:43:11]
<Navan> shouldn't it support Zero 2 W too?
[22:43:19]
<Navan> because it has the Pi 3 chip
[22:43:29]
<Aleks> yeah zero 2W too according to what's written
[22:44:23]
<Navan> should we put a disclaimer that running the 64 version on zero 2w should be discouraged?
[22:44:58]
<Navan> it only has 512MB of ram, and the 32 bit version would be better suited for it
[22:46:07]
<Aleks> no idea, i'd be surprised that our image is in fact arm64 and not armhf ... The upstream has a special "arm64" branch ...
[22:47:21]
<Navan> let me download and tell
[22:48:12]
<Aleks> or maybe our branch is based on the arm64 branch 🤔 the content of https://github.com/YunoHost/rpi-image/blob/yunohost-bullseye/export-noobs/00-release/files/os.json seems to match with that hypothesis
[22:49:09]
<Aleks> https://github.com/YunoHost/rpi-image/blob/yunohost-bullseye/scripts/common#L12 👍️
[22:50:17]
<Aleks> ¯\_(ツ)_/¯ pretty cool then
[23:15:04]
<Aleks> https://twitter.com/d_feldman/status/1558309810801631233
[23:15:06]
<Aleks> wat