My systems attempted to build a spectrum image against nixpkgs master last night, and failed because of pkgsMusl.netpbm and pkgsMusl.gdb, which are known blockers since the GCC 15 updates: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue%20state%3Aopen%20author... - Yureka
On 2/9/26 03:02, Yureka wrote:
My systems attempted to build a spectrum image against nixpkgs master last night, and failed because of pkgsMusl.netpbm and pkgsMusl.gdb, which are known blockers since the GCC 15 updates:
https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue%20state%3Aopen%20author...
Can those be removed from the closure somehow? -- Sincerely, Demi Marie Obenour (she/her/hers)
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 2/9/26 03:02, Yureka wrote:
My systems attempted to build a spectrum image against nixpkgs master last night, and failed because of pkgsMusl.netpbm and pkgsMusl.gdb, which are known blockers since the GCC 15 updates:
https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue%20state%3Aopen%20author...
Can those be removed from the closure somehow?
I'm pretty sure I answered a very similar question last time, but just in case: it would likely be more ongoing maintenance work to maintain closure reducing overrides than it would be to fix the occasional build failure of a dependency that is not strictly required, at least until we have better tooling for identifying problematic Nixpkgs changes. In addition, that larger amount of work would have less overall utility, because package fixes benefit other Nixpkgs users, whereas adding to an ever-expanding list of local overrides does not.
On 2/9/26 14:41, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 2/9/26 03:02, Yureka wrote:
My systems attempted to build a spectrum image against nixpkgs master last night, and failed because of pkgsMusl.netpbm and pkgsMusl.gdb, which are known blockers since the GCC 15 updates:
https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue%20state%3Aopen%20author...
Can those be removed from the closure somehow?
I'm pretty sure I answered a very similar question last time, but just in case: it would likely be more ongoing maintenance work to maintain closure reducing overrides than it would be to fix the occasional build failure of a dependency that is not strictly required, at least until we have better tooling for identifying problematic Nixpkgs changes. In addition, that larger amount of work would have less overall utility, because package fixes benefit other Nixpkgs users, whereas adding to an ever-expanding list of local overrides does not.
What would the plan be if Spectrum had already been released? Not being able to ship security fixes while nixpkgs is fixed would be bad. -- Sincerely, Demi Marie Obenour (she/her/hers)
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 2/9/26 14:41, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 2/9/26 03:02, Yureka wrote:
My systems attempted to build a spectrum image against nixpkgs master last night, and failed because of pkgsMusl.netpbm and pkgsMusl.gdb, which are known blockers since the GCC 15 updates:
https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue%20state%3Aopen%20author...
Can those be removed from the closure somehow?
I'm pretty sure I answered a very similar question last time, but just in case: it would likely be more ongoing maintenance work to maintain closure reducing overrides than it would be to fix the occasional build failure of a dependency that is not strictly required, at least until we have better tooling for identifying problematic Nixpkgs changes. In addition, that larger amount of work would have less overall utility, because package fixes benefit other Nixpkgs users, whereas adding to an ever-expanding list of local overrides does not.
What would the plan be if Spectrum had already been released? Not being able to ship security fixes while nixpkgs is fixed would be bad.
We'd, in rough order of preference: - Use an overlay to apply a patch downstream - Use an overlay to temporarily disable dependencies - Use a modified Nixpkgs input
On 2/23/26 06:28, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 2/9/26 14:41, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 2/9/26 03:02, Yureka wrote:
My systems attempted to build a spectrum image against nixpkgs master last night, and failed because of pkgsMusl.netpbm and pkgsMusl.gdb, which are known blockers since the GCC 15 updates:
https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue%20state%3Aopen%20author...
Can those be removed from the closure somehow?
I'm pretty sure I answered a very similar question last time, but just in case: it would likely be more ongoing maintenance work to maintain closure reducing overrides than it would be to fix the occasional build failure of a dependency that is not strictly required, at least until we have better tooling for identifying problematic Nixpkgs changes. In addition, that larger amount of work would have less overall utility, because package fixes benefit other Nixpkgs users, whereas adding to an ever-expanding list of local overrides does not.
What would the plan be if Spectrum had already been released? Not being able to ship security fixes while nixpkgs is fixed would be bad.
We'd, in rough order of preference:
- Use an overlay to apply a patch downstream - Use an overlay to temporarily disable dependencies - Use a modified Nixpkgs input
Thank you! I've seen Fedora delay updates for too long because of problems like this, and I know that Spectrum aims to be a rolling release which means regular updates. So it's good to know that it will be able to keep updating even when glitches like this arise. -- Sincerely, Demi Marie Obenour (she/her/hers)
Yureka <yuka@yuka.dev> writes:
My systems attempted to build a spectrum image against nixpkgs master last night, and failed because of pkgsMusl.netpbm and pkgsMusl.gdb, which are known blockers since the GCC 15 updates:
https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue%20state%3Aopen%20author...
Thanks! I looked into both of these. Proposed a fix to netpbm in Nixpkgs[1], but for gdb we should probably wait for a second submission of this patch[2], since the current version relying on Glibc-internal macros in not great. A second gdb patch[3] is also necessary for aarch64, which looks fine to apply whenever we're ready. I've added all these patches to the upstream bug/patch tracking board[4]. Send me a contact request on there if you want write access. :) [1]: https://github.com/NixOS/nixpkgs/pull/492997 [2]: https://inbox.sourceware.org/gdb-patches/20260213152151.3224544-1-sunilkumar... [3]: https://inbox.sourceware.org/gdb-patches/20260217060106.1906312-5-thiago.bau... [4]: https://cryptpad.fr/kanban/#/2/kanban/view/yLtGXWLV6U7X5+Z1ay+oXKZMrSacqQe+5...
participants (3)
-
Alyssa Ross -
Demi Marie Obenour -
Yureka