Nixpkgs updates

Nixpkgs updates

[Yureka]

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%3Ayuyuyureka


- Yureka

Re: Nixpkgs updates

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 429 bytes --]

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%3Ayuyuyureka

Can those be removed from the closure somehow?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Nixpkgs updates

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

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%3Ayuyuyureka
>
> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Nixpkgs updates

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 1257 bytes --]

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%3Ayuyuyureka
>>
>> 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)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Nixpkgs updates

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

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%3Ayuyuyureka
>>>
>>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Nixpkgs updates

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 1862 bytes --]

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%3Ayuyuyureka
>>>>
>>>> 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)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Nixpkgs updates

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

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%3Ayuyuyureka

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.dora@windriver.com/
[3]: https://inbox.sourceware.org/gdb-patches/20260217060106.1906312-5-thiago.bauermann@linaro.org/
[4]: https://cryptpad.fr/kanban/#/2/kanban/view/yLtGXWLV6U7X5+Z1ay+oXKZMrSacqQe+51nXZYRh3ck/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]