Skip to content

Comments

luci-go: drop#437435

Merged
SigmaSquadron merged 1 commit intoNixOS:masterfrom
wolfgangwalther:luci-go-drop
Sep 2, 2025
Merged

luci-go: drop#437435
SigmaSquadron merged 1 commit intoNixOS:masterfrom
wolfgangwalther:luci-go-drop

Conversation

@wolfgangwalther
Copy link
Contributor

@wolfgangwalther wolfgangwalther commented Aug 27, 2025

Has been failing to build for 5 months. It doesn't seem to be useful on its own, but only in conjunction with other packages, which are not in Nixpkgs.

From #437082 (comment):

Regarding luci-go, it's a dependency for more chromium-related packages I planned to contribute, but I worked on that effort on an older checkout.

There's an alternative PR to update it to unbreak the build in #437389. I suggest to drop it instead with the option to add it again, when any other package makes use of it.

Note: It also has quite long build times, it took 14 minutes for me to actually hit the test failure. Even if successful, this build is currently a waste of resources, if unused.

Can't request him for review, thus the ping here: @zeuner

Closes #437389

Things done


Add a 👍 reaction to pull requests you find important.

Has been failing to build for 5 months. It doesn't seem to be useful on
its own, but only in conjunction with other packages, which are not in
Nixpkgs.
@pbsds
Copy link
Member

pbsds commented Aug 27, 2025

@nixpkgs-ci nixpkgs-ci bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. labels Aug 27, 2025
@nixpkgs-ci nixpkgs-ci bot added the 12.approvals: 1 This PR was reviewed and approved by one person. label Aug 27, 2025
@nixpkgs-ci nixpkgs-ci bot added 12.approvals: 2 This PR was reviewed and approved by two persons. and removed 12.approvals: 1 This PR was reviewed and approved by one person. labels Aug 27, 2025
@philiptaron
Copy link
Contributor

If you're wondering what LUCI is, here's the blurb:

Welcome to LUCI!

LUCI is a replacement for Buildbot that runs primarily on the Google Cloud Platform and is designed to scale well for large projects.

LUCI is the CI system for the Chromium project. All Chromium developers should already be using the LUCI UI (ci.chromium.org).

For more public information, see luci-py README.md. For Googlers, see go/luci.

It's sort of public, sort of private, and is extremely Google-centric. Neat software, just not packaged for Nix yet... and I suspect never will be unless someone actually uses it outside of the Googleplex.

@nixpkgs-ci nixpkgs-ci bot added 12.approvals: 3+ This PR was reviewed and approved by three or more persons. and removed 12.approvals: 2 This PR was reviewed and approved by two persons. labels Aug 27, 2025
@zeuner
Copy link
Contributor

zeuner commented Aug 27, 2025

Has been failing to build for 5 months.

A fixed build has been provided within 24 hours of the maintainer being notified of the build failure.

It doesn't seem to be useful on its own, but only in conjunction with other packages, which are not in Nixpkgs.

It contains tools that are useful for building software developed at Google, especially around Chromium. Google software does get packaged in nixpkgs, making also luci-go potentially useful for these efforts.

From #437082 (comment):

Regarding luci-go, it's a dependency for more chromium-related packages I planned to contribute, but I worked on that effort on an older checkout.

There's an alternative PR to update it to unbreak the build in #437389. I suggest to drop it instead with the option to add it again, when any other package makes use of it.

Keeping it in nixpkgs has the advantage that the build breaking can be noticed and fixed earlier, so even upcoming downstream users that already work on an older checkout are easier to port to git master.

Furthermore, it may already be useful for those concerned in supply chain security. For example, the package provides cipd, which seems to be used as a binary blob in nixpkgs, probably due to a perceived lack of an alternative in nixpkgs.

Note: It also has quite long build times, it took 14 minutes for me to actually hit the test failure. Even if successful, this build is currently a waste of resources, if unused.

Slightly OT, but is there a process for donating build capacities?

Anyway, if the package is perceived as being too big, a less destructive alternative might be to identify parts which are not useful for packaging outside of Google, and trim down the package a bit.

In conclusion, I propose not to drop the package. As someone who repeatedly worked on getting software to run without resorting to binary blobs using nixpkgs, I have always been happy if I saw that some of the tools I need are already in place. Maybe it needs a better description to find more users, though.

@zeuner
Copy link
Contributor

zeuner commented Aug 27, 2025

It's sort of public, sort of private, and is extremely Google-centric. Neat software, just not packaged for Nix yet... and I suspect never will be unless someone actually uses it outside of the Googleplex.

A lot of software shares this kind of genesis, e.g. look at bazel. Nixifying this software reduces the chance that package authors find no way other than fetching the binary blobs Google provides for whatever platforms they decide.

@wolfgangwalther
Copy link
Contributor Author

Has been failing to build for 5 months.

A fixed build has been provided within 24 hours of the maintainer being notified of the build failure.

To be clear the suggestion to drop is not "because it fails to build", but because "it seems to be unused". The "it failed to build for 5 months without anyone noticing" is merely a proxy to be able to tell "well, it probably is unused". Even if the package is fixed now, this doesn't mean that it's suddenly used.

Furthermore, it may already be useful for those concerned in supply chain security. For example, the package provides cipd, which seems to be used as a binary blob in nixpkgs, probably due to a perceived lack of an alternative in nixpkgs.

"It might potentially be used" is not an argument for me. If you think it would be valuable to use cipd from luci-go in pkgs/development/compilers/flutter/engine/tools.nix, then please propose a PR to do that.

Hypothetical usage != actual usage. But if it's actually used - great.

@SigmaSquadron
Copy link
Contributor

Since Luci is unused, this can go through. If in the future the issue of source provenance in the dependents that current vendor Luci is deemed important enough, it can always be re-added.

@SigmaSquadron SigmaSquadron merged commit 10bee29 into NixOS:master Sep 2, 2025
36 of 37 checks passed
@zeuner
Copy link
Contributor

zeuner commented Sep 2, 2025

Since Luci is unused, this can go through. If in the future the issue of source provenance in the dependents that current vendor Luci is deemed important enough, it can always be re-added.

I see. But how exactly do you expect packagers to find the previous work if it's hidden in the git history and closed PRs? The more likely scenario is that they'll think they'll have to start from scratch, lessening the chance that a source build is considered feasible. This might be just another step on nixpkgs's road towards being a database of online binary blobs to stick together.

@eclairevoyant
Copy link
Contributor

Nix expressions can exist without being in nixpkgs.

@pbsds
Copy link
Member

pbsds commented Sep 2, 2025

It's also common to look for open/closed/dropped PRs or any other forms of prior art when you're about to package something.

@wolfgangwalther wolfgangwalther deleted the luci-go-drop branch September 2, 2025 20:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. 12.approvals: 3+ This PR was reviewed and approved by three or more persons.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants