| 14 Jul 2021 |
 RqndomHax | Heyyyy | 23:48:25 |
| 15 Jul 2021 |
 Arian | Welcome | 07:33:53 |
| RqndomHax | Thanks :D | 08:24:47 |
|  maxine (they/them) joined the room. | 22:59:00 |
| 16 Jul 2021 |
|  clean garbage left the room. | 06:04:23 |
|  Andrea Pascal joined the room. | 07:17:05 |
|  formerly joined the room. | 11:27:09 |
| 17 Jul 2021 |
| maxine (they/them) changed their display name from maxine [they] to maxine (they/them). | 12:04:11 |
|  Bas joined the room. | 16:14:14 |
| 18 Jul 2021 |
|  aanderse joined the room. | 15:56:36 |
| aanderse changed their display name from Aaron Andersen to aanderse. | 15:58:44 |
| 19 Jul 2021 |
|  cjbayliss (they/them) changed their display name from cjbayliss to cjbayliss (they/them). | 03:10:55 |
| 26 Jul 2021 |
 andi- | I am lookinat the v249 upgrade right now. I kinda don't want to enable FIDO2 and TPM2 support by default. Just like we don't enable homed etc.. yet.
The closure to build a minimal system is just getting bigger and bigger and I've to introduce yet another "minimal" version of another package (pstools) for the build to actually start..
My current opinion is that if someone enables any of the tpm2 features in their system configuration the systemd.package package should also have that flag enabled otherwise not.
This will lead to a couple of new systemd flavours on hydra but since basically nothing (but VM tests?) depend on them that sounds okay to me.
Opinions?
| 16:47:34 |
| andi- | The alternative is to allow runtime dependency resolution via dlopen and linker search paths... Just like we do with OpenGL. IMHO not a desirable as that means we will have to running system vs shell environment mismatches. | 16:48:39 |
| Arian | We can keep it disabled for now until we find a way to support it | 17:10:28 |
| Arian | This shouldn't block a version bump. Even though I'd like to have it | 17:10:45 |
| Arian | Most of the FIDO2 dependencies are already in closure through openSSH atm though. (Which is kind of a bug on its own IMO) | 17:11:22 |
| Arian | Most of these dependencies are only interesting in initrd anyway. And we already build initrd 'on demand' todau | 17:12:29 |
| Arian | So having it optional isn't all that crazy | 17:12:37 |
| andi- | I've also played around with DNSoTLS support in resolved for a few weeks now on a spare device. It has been working fine so far in "opportunistic" mode. | 17:51:58 |
| andi- | Unfortunately I haven't managed to be stuck in a DB train for several hours yet to verify if that hobby-dns-resolved improved :) | 17:52:35 |
| andi- | My WIP stuff: https://github.com/NixOS/nixpkgs/pull/131618
The systemd test works as it starts a graphical interface.. anything else doesn't seem to work.. Not entirely sure what the issue with resolution of units is. I've create a log if anyone feels like digging through that while I sleep: https://gist.github.com/andir/04bc585ace6722c86bb8e3b731101c9c | 21:14:04 |
|  Jeremy Cantrell joined the room. | 23:45:34 |
| 27 Jul 2021 |
| Jeremy Cantrell left the room. | 00:30:37 |
|  hexagonk joined the room. | 14:34:15 |
| aanderse | ok i'm pretty sure i've confirmed it (through testing, not reading source code): systemd-tmpfiles is bad news and should be used very sparingly
why? when you use d to create a directory it wipes out ACLs when it actually operates on that directory | 20:30:45 |
| aanderse | example: add d '/var/lib/foo' 0700 root somesystemuser to your systemd.tmpfiles.rules, then imperatively run sudo setfacl -m u:yourownuser:rx /var/lib/foo after your system has activated
activate your system again (or run sudo systemd-tmpfiles --create) and note your ACLs are mucked up | 20:34:18 |
| aanderse | hmm... "wips out ACLs" was the wrong thing to say
it mucks the mask and makes them ineffective | 20:34:47 |
| andi- | and if you use D? Isn't that supposed to be (almost) a no-op if it already exists? | 20:47:42 |
| aanderse | D removes the directory after a period | 20:54:39 |
