Maintainer team wanted for looking after pkgsStatic

[expipiplus1]

It would be great to have pkgsStatic (or pkgsSharedStatic) a little better cared for in nixpkgs, see #89425, to stop things constantly bitrotting, breakages in pkgsStatic would have to block channel updates, but for this, there would need to be some people willing to maintain this package set.

I'm willing to be part of this team, would anyone else be willing?

If the burden of keeping pkgsStatic not breaking is too much, then this doesn't have to continue, but I think it's worth trying.

[domenkozar]

cc @matthewbauer @Mic92

[expipiplus1]

@nh2 interested?

[FRidh]

Aside from a team it is important to decide what packages are considered blocking and should be built by Hydra.

pkgsStatic is listed in the RFC as Tier 4 (x86_64-linux, gcc+musl — static). To upgrade to Tier 3 we could make the stdenv blocking. To go to Tier 2, we need to start building a lot more on Hydra, at which point we need to consider resources.

So, what packages to build, and what to block on?

cc @7c6f434c

[7c6f434c]

Aside from a team it is important to decide what packages are considered blocking and should be built by Hydra.

It's not really aside from a team. Anything above Tier-4 assumes ability to reasonably quickly find people who can investigate breakages…

`pkgsStatic` is listed in the [RFC](https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md#appendix-a-non-normative-description-of-platforms-in-november-2019) as Tier 4 (x86_64-linux, gcc+musl — static). To upgrade to Tier 3 we could make the `stdenv` blocking. To go to Tier 2, we need to start building a lot more on Hydra, at which point we need to consider resources.

If I am cc-ed as RFC-0046 specialist, I would like to remind that Tier-3 does not assume any channel blockers. Also, to claim full Tier-3 we need a team if only to understand what works and what doesn't. libX11 missing symbols needed by rev-deps doesn't sound compatible with «popular packages mostly work» to me, to be honest. I think right now the static builds are actually close to Tier 3 both in Hydra support and impact tolerance, even if the platform seems to be in a shape closer to Tier-4 package-wise. I find it perfectly fine as long as nobody is specifically annoyed by the static-build-related changes. And of course there are some general benefits of having at least something static work.

[nh2]

I'm up for participating in such team, mainly for a pkgsSharedStatic as suggested in #61575.

I think build automation is important, and I could chip in another 30 EUR/month Hetzner build server from the extra funds that my static-haskell-nix OpenCollective provides (which is targeted at static Haskell builds, but to do them I need a healthy pkgsSharedStatic equivalent).

[symphorien]

Maybe it could start with "ensuring when someone fixes a package, it does not regress"

[7c6f434c]

I think that no-regressions doesn't even apply to The Tier-1 Platform…

[symphorien]

I was more thinking of a notification on regression, like the emails hydra used to send.

[Mic92]

I will pass on this one. I am not using pkgsStatic actively to recognize breakages.

[expipiplus1]

So, what packages to build, and what to block on?

Most of the work in fixing these packages seems to stem from bespoke build systems used by packages. Packages which use well understood build systems seem to fare much better, for example Haskell package. Standard usage of autotools and CMake also seem to cope well. Perhaps to get a good bang-for-our-buck the dependencies to build CMake project, Haskell packages and sensible autotools projects would be a good start. I don't know much about other packaging ecosystems in nixpkgs, but I suspect that if we get one Rust package building then the rest probably fall out, similar for other languages maybe,

I was more thinking of a notification on regression, like the emails hydra used to send.

Where would be the best place to start on this? Alternatively is it possible to use github issues for this, i.e. the build failure triggers the creation of an issue in which the interested parties are @-mentioned?

mainly for a pkgsSharedStatic as suggested

@nh2 I believe that the closest we have at the moment is in the static-haskell-nix repo, what would it take to get pkgsSharedStatic in nixpkgs?

In terms of building packages for distribution to non-nixos systems, pkgsSharedStatic is sufficient. But I'm sure that some people are interested in this for reasons beyond that for which a package set with no dynamic linking is better suited.

[Mic92]

I was more thinking of a notification on regression, like the emails hydra used to send.

Where would be the best place to start on this? Alternatively is it possible to use github issues for this, i.e. the build failure triggers the creation of an issue in which the interested parties are @-mentioned?

I could think of a github action that is run periodically and just checks hydra. Github actions also have the API credentials to open issues.

[teburd]

I'm happy to help, as I see a lot of use for pkgsStatic/pkgsMusl for building embedded and docker images using nix

[pjjw]

hi, yeah, just found this issue but have been going through a number of things trying to get pkgsMusl working again for essentially the same set of packages in release-small. so i'm interested in this and working on it, i guess.

[stale]

I marked this as stale due to inactivity. → More info