| 20 Oct 2025 |
Vladimír Čunát | (I mean, resolving the name is a pretty easy step not really related to staging* cycles.) | 12:48:39 |
eveeifyeve | Let me provide the devshell so I can see if you can reproduce it.
{
description = "Super simple starting point for Polar development flake";
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/staging"; # Change to staging, TODO: https://nixpk.gs/pr-tracker.html?pr=453690
flake-parts.url = "github:hercules-ci/flake-parts";
systems.url = "github:nix-systems/default";
};
outputs =
inputs:
inputs.flake-parts.lib.mkFlake { inherit inputs; } {
systems = import inputs.systems;
perSystem =
{
pkgs,
system,
...
}:
{
_module.args.pkgs = import inputs.nixpkgs {
inherit system;
config = {
allowUnfree = true;
};
};
devShells.default = pkgs.mkShell {
nativeBuildInputs = with pkgs; [
nodejs_22
pnpm
(python3.withPackages (p: [
p.psycopg2-binary
p.psycopg2
]))
uv
stripe-cli
ngrok
];
};
};
};
}
| 12:49:08 |
dramforever | yeah running on staging is usually a bad idea | 12:49:23 |
dramforever | unless you feel like building all of those stuff | 12:49:34 |
eveeifyeve | For now I am doing this as I need it as a dependency for working on polar.sh. | 12:50:00 |
Vladimír Čunát | Usually you can just pick your relevant changes atop some point that does have binaries. (master, staging-next, depending on situation) | 12:50:28 |
| 21 Oct 2025 |
Fabián Heredia |  Download image.png | 05:49:32 |
Fabián Heredia | Queue is currently empty | 05:49:35 |
Fabián Heredia | If there is no other workload, could I get an eval on gcc 14 to 15 update vcunat ?
https://github.com/NixOS/nixpkgs/pull/440456
Just rebased on top of staging-next to know if there are some major breakages I should address before marking as ready (would still wait for branch-off / breaking changes being unrestricted on staging)
| 05:52:10 |
Vladimír Čunát | I'd prefer to start staging-next-25.05. | 06:16:12 |
Vladimír Čunát | * I'd prefer starting staging-next-25.05 to gcc jobset right now. | 06:16:26 |
Fabián Heredia | Sure, no worries was only if no other workload atm. | 06:29:34 |
Vladimír Čunát | I think we can merge staging-next now. | 07:03:49 |
Vladimír Čunát | Uh, no. A new blocker appeared:
https://hydra.nixos.org/build/310349106 | 07:10:58 |
K900 | Did openssh get fixed? | 07:13:03 |
K900 | Also uhh | 07:13:03 |
K900 | I may have a Qt hotfix that I'd like to get in | 07:13:04 |
Vladimír Čunát | Ah, that's just https://github.com/NixOS/nixpkgs/issues/448756 | 07:14:03 |
Vladimír Čunát | Yes. | 07:14:10 |
K900 | Can we please eat a qtdeclarative6 rebuild | 07:14:45 |
K900 | I can have a PR in like 30 minutes | 07:14:55 |
K900 | They shipped a miscompilation in the QML JIT that just makes random things randomly crash for no apparent reason | 07:15:24 |
Vladimír Čunát | Well, the staging-next merge itself is independent of that, basically. | 07:16:50 |
Vladimír Čunát | I'll do just unstable-small for now. | 07:17:16 |
Vladimír Čunát | (I don't know how expensive qtdeclarative6 is off the top of my head.) | 07:17:38 |
K900 | It isn't because it's like 8k jobs | 07:18:58 |
Vladimír Čunát | I meant that just merging won't trigger any builds. | 07:19:58 |
Vladimír Čunát | And unstable-small won't have Qt in it. | 07:20:06 |
Vladimír Čunát | The merge queue did it in the meantime. | 07:21:04 |
K900 | I just don't want to have the bad state in master | 07:23:16 |