| 3 Jun 2021 |
|  Reventlov joined the room. | 15:16:03 |
 hexa | https://github.com/NixOS/nixpkgs/pull/125554 | 19:33:16 |
| hexa | looks like this one was embargoed, there is a gitlab.fdo link that goes 404 :) | 19:54:20 |
| hexa | and boy, do I wish we had threading in here. The backlog is a mess. | 19:55:17 |
| hexa | also I wish we had a clarification to what branch (staging 🔥, staging-next 🔥🔥, master 🔥 🔥 🔥) | 19:59:13 |
| hexa | * also I wish we had a clarification to what branch (staging 🔥, staging-next 🔥🔥, master 🔥🔥🔥) certain types of vulnerabilities go | 19:59:30 |
| hexa | this is a local privesc and the current staging cycle is like two weeks at best | 20:00:00 |
| 4 Jun 2021 |
 lukegb (he/him) | https://hydra.nixos.org/eval/1675207 for master | 00:54:29 |
 stigo | https://github.com/NixOS/nixpkgs/pull/125646 | 10:27:53 |
| hexa | looks like the polkit change went into master without a hitch | 12:05:31 |
| hexa | stigo: the darwin ofborg builder is somewhat backed up with ~100 jobs in the queue fyi | 12:05:49 |
| lukegb (he/him) | hexa: yeah, just trying to unwedge hydra | 12:06:08 |
| stigo | :-\ | 12:06:18 |
| lukegb (he/him) | It should be fine now, I kicked off another eval | 12:06:20 |
| lukegb (he/him) | https://hydra.nixos.org/eval/1675342 | 12:06:42 |
 philipp | I'm wondering how feasible it would be to leech onto debian or centos for a stable package stack. E.g. take the php/nginx/mariadb/postgresql version from debian stable and port all their patches to nixpkgs and try to support it until the support for that debian version runs out. | 14:18:25 |
 Sandro | Why do we want to downgrade our packages? | 14:25:15 |
| Sandro | Interesting. Our default postgres is also at 11 like debian stable | 14:27:57 |
| Sandro | but I saw a PR that bumps that. | 14:28:06 |
| Sandro | Found a better example: Debian Stable has nginx 1.14.2. We are already at 1.20.1 for nginx stable/mainline which is the default for nginx | 14:29:50 |
| Sandro | or another example is that our glibc is 2.32 while Debian stable is only on 2.28 | 14:31:21 |
| Sandro | so I think this will only cause issues and requires us to patch more especially around software not being compatible with newer/older compilers | 14:32:11 |
| philipp | I don't want to downgrade packages. I would introduce a separate LTS attribute set. | 14:51:48 |
| Sandro | I don't see the advantage of that nor the time to maintain that tbh | 15:13:31 |
| Sandro | maintaining two versions of core packages like glibc6 involves probably a lot of work | 15:14:52 |
 andi- | philipp: what makes you think that sticking to the Debian model is easier? Usually upstreams provide new versions (or patches for the latest versions). I think we need less actual work right now than we would need if we used older versions. Sure, we could pick patches from Debian but that would establish a dependency on them actually updating before us. | 15:46:19 |
| philipp | It's less about making it easier and more allowing for longer support intervals. | 17:40:38 |
 ris_ | quite a few security-related PRs needing review right now | 17:46:00 |
| ris_ | i think it's an interesting idea philipp i'd just wonder how much the result would end up disconnected from our non-LTS branches. andi- patches can certainly flow both ways between the two projects. i know some of my backport patches have made it back into debian | 17:49:44 |
| ris_ | i'd quite like to lure debian developers over to our side because i get the impression that debian's processes and infra for maintaining packages is a nightmare | 17:51:38 |
