<pmy_>
I have been waiting for the next nixos-unstable for a week.
<samueldr>
when there are issues breaking channels, they generally are found on the status page https://status.nixos.org/
<samueldr>
sometimes it's a sequence of different problems that stopped the channel advancing
<samueldr>
so yeah, it's a bit more nuanced than "once a day", what happens once a day is a new evaluation with whatever is on top of master at tha moment in time
<samueldr>
whenever the tested job succeeds _and_ all packages have been tried to be built for a given evaluation, the channel will advance to that revision
<samueldr>
so it is believable that the channel could advance twice in a day
<samueldr>
but for evals launched a one or two days before
<samueldr>
(if it had to rebuild the whole world, which we try to avoid)
<samueldr>
there is no manual way to trigger a channel advance either
<pmy_>
Indeed. Your explanation makes more sense.
<pmy_>
Nixos-unstable has been stalled for 8 days.
<abathur>
I could use feedback (from anyone, but also gchristensen and infinisil :) on a change to the resholve Nix API to support using different settings to resolve different script(s) in a single package. I don't recall seeing a pattern for this so I've gotten *creative*. https://github.com/NixOS/nixpkgs/pull/85827#issuecomment-747831206
<abathur>
^ adisbladis also relevant to your ?
m1cr0man has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
<ekleog>
Hmm… just noticed `nix-shell` ignores `lowPrio`/`hiPrio` and just takes the executables from the first buildInput that provides it. Do y'all think it's a bug or a feature, or a bug that must be considered as a feature because backwards-compatibility?
<regnat>
ekleog: dunno if it should be called a “feature”, but afaik that's the intended behavior: the priority attribute is specific to buildend/nix-env and not something that the rest of the ecosystem cares about
<halfbit>
removing -g when building gcc removes the debug symbols from libquadmath such that libquadmath no longer has references to musl-dev, but libgcc_s still does which is... interesting
<halfbit>
is libgcc_s built with gcc builder.sh as part of gcc, I'd assume so?
<ekleog>
regnat: hmm ok weird, that definitely tricked me until I got what was happening :)