| 5 Jul 2026 |
|  mkg20001 joined the room. | 22:53:31 |
| 6 Jul 2026 |
 Vladimír Čunát | In reply to @k900:0upti.me
It's entirely unrevertable An old sqlite version for this purpose? | 05:30:40 |
 K900 | We can also just patch one character | 05:49:08 |
| K900 | But that's also not very sustainable | 05:49:20 |
|  lassulus joined the room. | 07:16:42 |
 gepbird | temporarily I'd go with pinning sqlite to an older version for pnpm only
then making a new fetcherVersion that uses can only use the new sqlite (throws with an old sqlite version) and migrate pnpm 11 packages to that
but I'm also fine with patching the FOD with sed if we can make sure it doesn't cause other issues, or reverting the sqlite change that broke it if possible | 08:30:16 |
| K900 | Reverting the change is not possible and will be a world rebuild | 08:30:33 |
| K900 | And we do not want to carry the patch going forward | 08:30:41 |
| gepbird | but long term we should replace this tooling that relies on pnpm, sqlite and other binaries, probably intercept the network requests which is what Scrumplex proposed in a PR (I haven't have time to review) | 08:31:13 |
| K900 | The correct solution is probably to figure out how to not include the SQLite data in the output at all | 08:31:14 |
| K900 | And if that's impossible, to make it so it's not represented as an internal dump format | 08:31:30 |
 Grimmauld (any/all) | seems vulnix is broken rn via zodb | 08:34:55 |
| Grimmauld (any/all) | setuptools garbage | 08:35:01 |
| K900 | If it's complaining about pkg_resources, replace setuptools with setuptools_80 | 08:35:35 |
| gepbird | for now the only solution to that seems to be https://github.com/NixOS/nixpkgs/pull/531657
but I wouldn't immediately switch all packages to this before making sure it's realiable | 08:35:49 |
| gepbird | previously it wasn't a dump format but the binary database, which has it's own can of worms | 08:36:21 |
| Grimmauld (any/all) | zodb> ERROR Missing dependencies:
zodb> setuptools<81,>=78.1.1
May be able to get away with relaxDeps | 08:39:10 |
| Grimmauld (any/all) | oh great, prusa slicer is broken | 09:37:52 |
| Vladimír Čunát | To keep Hydra busy, I started staging-next-26.05 builds for some platforms. So let me open a PR, too:
https://github.com/NixOS/nixpkgs/pull/538950 | 11:54:43 |
 hexa | bumped staging-next to front 90 minutes ago, because builders were picking up staging-next-26.05 jobs while staging-next jobs were left | 11:56:03 |
| Vladimír Čunát | Ah. Maybe the scheduling could be improved from our point of view. | 11:57:05 |
| Vladimír Čunát | I'm not sure how tweakable that is
build/hydra-queue-runner.nix: stepSortFn = "WithCriticalPath";
| 11:57:45 |
| hexa | where are we with the pnmp situation? | 12:48:45 |
| hexa | because today looks like merge day | 12:48:59 |
| hexa | https://github.com/NixOS/nixpkgs/pull/538919 | 12:52:12 |
| hexa | vcunat why did you eval staging-next-26.05 without aarch64-linux? | 13:03:32 |
| hexa | it's not like a backlog in the queue for a dedicated platform will hurt us any more | 13:04:20 |
| Vladimír Čunát | I thought it had enough work so far. | 13:23:29 |
| Vladimír Čunát | Higher priority work. | 13:23:57 |
| Vladimír Čunát | * I thought aarch64-linux had enough work so far. | 13:25:09 |
