Since I have hundrends of packages on my laptop and I run unstable, I tend to encounter various build failures. As a result, I create new issues on github about these failures to let the developers know.
Issue
My issue is the section “Steps to reproduce”
I don’t really know what to write there, what I usually do is something like “Updated and rebuilt to the latest version.”. The developer then can see my actual version from the nixos metadata section. But this looks bad.
I would like to write something less vague instead.
In the description of that section it says:
Please include a step-by-step guide for reproducing this build failure. Consider writing in concise, numbered bullet points to ensure that Nixpkgs developers can retrace your steps
Proposals
I would like to see a command of the followinh in the issue template to prompt the user to run it and test for reproducability. That way the creator of the issue will also be able to point the developer to the actual steps to reproduce the issue (and not use vague statements like I’ve been doing).
Disambiguation
2a601aafdc5605a5133a2ca506a34a3a73377247 is an example hash
package is the package that causes the build failure
Inspired by other github issues about build failures and asking K900 for help, a possible solution would be to write a command that causes the system to add the package to the system, like nix-build would. If that builds successfully, as per docs (https://nix.dev/manual/nix/2.34/command-ref/new-cli/nix3-build.html), it should create a result dir link to nix store.
Is that even an option if you use nix? The nix3 CLI doesn’t deprecate the stable nix commands, hell, there’s a bunch of stuff in them that doesn’t yet have a nix subcommand.
I think just using stable commands catches a strict superset of the nix3 commands, and the intent here is anyway for reporters to just paste stuff into their terminal, so there’s no reason to offer a nix3 alternative.
That kinda works, but surely a nix-build command that builds the result of an expression and uses fetchurl would be better?
I mean that’s the point of the build failure github issues, to report failures of packages on github, tag the developers and try to collectively work on it through github issues and pull requests. The title template of this kind of issue is Build failure: PACKAGENAME with a description Report a package that is failing to build.. Unless we are debating the need for this category as a whole.
Hydra may or may not always catch and issues help the community find which packages are more urgent to fix and fix them.
My issue is the section “Steps to reproduce”
I don’t really know what to write there, what I usually do is something like “Updated and rebuilt to the latest version.”. The developer then can see my actual version from the nixos metadata section. But this looks bad.
I think the more effort you put in steps to reproduce so that a mere brainless copy-paste is enough to reproduce, the more likely the issue will be fixed. Vague issues where you have to guess what happened, do a lot of non-copypastable configuration to hope reproducing, etc, take a lot of effort and are more likely to be ignored, imo.
I think the suggested build commands are excellent reproductions, though. Giving users who want to report build issues a way to do that trivially just makes it easier for newbies.
Yes, but not for proprietary packages. Browsing hydra is also pretty tricky, especially for new users, it’s handy to have a github issue to search for.
Indeed, there is a bug template for build failures in nixpkgs on GitHub. So I guess some people see merits in this. Maybe if Hydra does not trigger this? Or the package is unfree and not part of the Hydra pipeline?
Yeah, thats what Id like to change and use the commands in the proposals instead, which are way less vague
(I edited my post to make it less vague as well:)
Experimental command, using nix build. The --no-link option prevents the command from creating a results symlink, is less messy (as per docs https://nix.dev/manual/nix/2.34/command-ref/new-cli/nix3-build.html#options). It is the neatest of them all, but it is an experimental command (though no big issue).
All these commands could be appended with 3 options that may help:
-vvvvv which is --verbose option repeated 5 times for max verbosity. Debug verbosity is -vvvv.
--keep-going is the option to allow for multiple failures to occur (in case we want to capture multiple faillures for some reason).
--keep-failed is the option to not delete the temporary directory (usually in /tmp) in which the build takes place in case of failure. (Should probably? not be paired with --no-out-link or --no-link.)
Cleanup
Lastly, after running any of these commands, you can clear you nix store from garbage produced (if they build successfully), by running one of the following commands:
Is there a command that attempts a build, and, if the build fails, spawns an interactive shell reusing the exact same shell execution environment and working directory as the failed build? That would eliminate several fiddly steps in between “confirm that the build failure is reproducible” and “start troubleshooting”.
Gotta admit, I dont think I understand the question, but I have a feeling I wouldnt have an answer even if I understood it properly
Maybe someone else can help
(Maybe a seperate post could help with visibility?)
To clarify, if such a command existed, it would be a good thing to put in your revised instructions for build failure reproduction. I posted a separate thread as you suggested: Interactive debugging of failed builds