[13:02:59]
<kayou> we don't [need that](https://github.com/YunoHost/yunohost/commit/f02d4a437612087d1e468d3087058c85a76d5b2b#diff-8769a4702e3c26668f38118a26262d4f9de006279ba4bd7bcfe715f4cbe7c8f4L3) during tests?
[13:03:21]
<kayou> we can preinstall these pip packages in image_builder
[13:04:35]
<kayou> > <@yunohostinfra:matrix.org> [yunohost] 🔴 Pipeline [#1406280798](https://gitlab.com/YunoHost/yunohost/-/pipelines/1406280798) failed on branch bookworm
26 minutes omg
[13:06:28]
<kayou> thank you Ale ks
[13:06:32]
<kayou> <3
[13:28:16]
<Aleks (he/him/il/lui)> > <@kayou:matrix.org> we don't [need that](https://github.com/YunoHost/yunohost/commit/f02d4a437612087d1e468d3087058c85a76d5b2b#diff-8769a4702e3c26668f38118a26262d4f9de006279ba4bd7bcfe715f4cbe7c8f4L3) during tests?
in full test yes actually since we start with the "before-install" image (i need to put the line back), but otherwise the pytest stuff is installed in the new "core-tests" image so i wanted to save running pip that takes idk 10ish sec ? (no idea) just to find out that the deps are already installed
[13:29:49]
<Aleks (he/him/il/lui)> but yeah now the lint/build run in 10~20 secs each or lower
[13:31:08]
<rodinux> Je voulais tester l'ISO x86 sur un petit serveur. Mais il a 2 coeurs. Par contre dans le bios je peux désactiver Multi traitement des coeurs. Désactivé : seul un coeur est disponible pour le système. On peut considérer que ce sera équivalent à du x86 ?
[13:32:49]
<Aleks (he/him/il/lui)> heuu, pas compris le rapport
[13:32:58]
<Aleks (he/him/il/lui)> si c'est du x86, c'est du x86 peu importe le nombre de coeur ?
[13:33:14]
<Aleks (he/him/il/lui)> x86 = 32 ou 64 bits "classique", en opposition aux architectures ARM ou autre
[13:41:35]
<rodinux> OK, je pensais qu'il y avais une histoire de CPU...
[14:14:25]
<rodinux> Bon un lspcu me confirme que c'est une archi 64-bit
[14:51:39]
<Yunohost Git/Infra notifications> [issues] bganne labeled :space_invader: bug on [issue #2429](https://github.com/YunoHost/issues/issues/2429): ping yunohost.org return Destination Port Unreachable preventing installation script to start
[14:51:40]
<Yunohost Git/Infra notifications> [issues] bganne opened [issue #2429](https://github.com/YunoHost/issues/issues/2429): ping yunohost.org return Destination Port Unreachable preventing installation script to start
[14:51:54]
<Yunohost Git/Infra notifications> [issues] bganne edited [issue #2429](https://github.com/YunoHost/issues/issues/2429): ping yunohost.org return Destination Port Unreachable preventing installation script to start
[18:14:01]
<Salamandar> Crap, the new yunohost.portal header conflicts with home assistant…
[18:14:09]
<Salamandar> i got 401s in the hass api if i'm logged in the yunohost portal
[18:14:32]
<Salamandar> and once i remove the yunohost.portal header, everything works fine
[18:15:05]
<Salamandar> i can confirm logging out of yunohost fixes the home assistant web pages
[18:15:21]
<Salamandar> (my home assistant is not an app but a proxied home assistant OS)
[18:19:52]
<Salamandar> setting auth_header=false in this helps :
```
"redirect.main": {
"auth_header": false,
"public": true,
```
[18:21:20]
<Salamandar> FYI that's an issue i've had like forever, but i had found the fix to restart nginx (of course, that logs me out…)… now i understand the underlying issue
[18:22:41]
<Salamandar> Also that's exactly the reason for those issues :
https://forum.yunohost.org/t/homeassistant-le-flux-de-configuration-na-pas-pu-etre-charge-401-unauthorized/27721
https://forum.yunohost.org/t/home-assistant-probleme-chargement-integrations/14664
https://forum.yunohost.org/t/unable-to-add-integrations-in-home-assistant/22485
https://forum.hacf.fr/t/ha-api-401-unauthorized/33935
[18:25:19]
<Salamandar> what's "funny" is that if I curl directly to my hass server with the problematic cookie, it works…
[18:50:04]
<Salamandar> Ah yes ok i figured it out, ssowat adds `authorization: basic` that conflicts with the `authorization bearer` from home assistant…
[19:29:00]
<Émy - OniriCorpe> > <@Salamandar:matrix.org> Ah yes ok i figured it out, ssowat adds `authorization: basic` that conflicts with the `authorization bearer` from home assistant…
maybe add a toggle in the configpanel?
[19:29:45]
<Salamandar> > <@oniricorpe:im.emelyne.eu> maybe add a toggle in the configpanel?
yeah that might be an idea
[19:29:52]
<Émy - OniriCorpe> or in the domain name settings if it has to be handled by the core?
[21:13:52]
<Aleks (he/him/il/lui)> the issue is that the Authorization header set by SSOwat replaces the one from the client ?
[21:13:52]
<Aleks (he/him/il/lui)> maybe the previous behavior aint reproduced idk
[21:13:52]
<Aleks (he/him/il/lui)> > <@Salamandar:matrix.org> Ah yes ok i figured it out, ssowat adds `authorization: basic` that conflicts with the `authorization bearer` from home assistant…
hmmm wasnt that fixed in the past with the "old" auth_header: false or something