Where do package-specific issues go?

Meta Moderation
1

I have an issue with a specific package (opencv), and (with the help of another user) found the default.nix for it on NixOS/nixpkgs. I think there’s an issue, but creating a new issue on nixpkgs wouldn’t really notify people who specifically work with opencv or python packages.

So (not just for opencv) where/how should we as users post issues and get in contact with the relevant package maintainers?

2

If the issue is with the package, and not how it is packaged, you should go to the upstream developers.
Otherwise, its really just the issue tracker. Check the expression for the maintainers and cc them. If there are none, you could ask people that have modified the expression in the past.

3 Likes
3

Thanks, I went ahead an made one :+1: And yeah, the issue is with the nix build, and possibly related to the package being in /nix/store rather than wherever it would normally be in a non-nix install.

While that works for me

  • Since contributors ≠ maintainers. How do I know which is which without looking at commit history for the file and guessing who is still a maintainer? (this is a legitimate question, as I’m not sure what you mean by “Check the expression for the maintainers”)
  • It seems like @-ing all 16 contributors with no way for them to mute on a per-package basis isn’t great
  • Subscribing to all issues/PRs for a particular package (e.g. me, as a non-contributor, wanting to know if package X gets a new PR or issue) doesn’t seem to be possible. I subscribe to repos to get notified new for releases and major issues
  • For repos/software in general, after failing to find an existing issue from searching, I often browse the list of issues and see my problem under a name I didn’t think to search for. It seems the current nixpkg method makes this harder. (sometimes I don’t have time to post a (possibly) duplicate issue and be redirected, I just either need to find the existing issue, or move on and use an apt-get package instead)
  • Since this method isn’t super intuitive/standard, I think would-be-issue-reporters might just give up instead of 1. Searching the internet for this thread to learn the expected way to search/post issues for the package 2. Knowing how, and looking up the default.nix for their package (I still don’t know how, given I was using python37.opencv4 and the default.nix was under opencv/4.x.nix) 3. Looking up the contributor history for that file and then copying and @-ing all the contributors before getting started on 4. the actual work of writing up an issue report with reproducible steps, OS information, logs, etc.

Would this thread be a good place for talking about potentially better issue-reporting methods? Like maybe adding package labels so people can filter by package (which is likely to have problems, but just as an example).

4

Each package (and some other parts) can have meta.maintainers attribute. That’s what you’re missing, I guess? Example:

$ nix repl .
nix-repl> :p opencv.meta.maintainers
[ { email = "mdaiter8121@gmail.com"; github = "mdaiter"; githubId = 1377571; name = "Matthew S. Daiter"; } { email = "v.dijk.bas@gmail.com"; github = "basvandijk"; githubId = 576355; name = "Bas van Dijk"; } ]

nix edit -f . opencv

That doesn’t seem useful; the GitHub label system isn’t meant for such huge number of labels… and the package-specific issues should have the package name in title, so they should be easy to find and spot.

3 Likes
5

Thanks @vcunat I appreciate taking the time to write out the commands, that helps. Sadly it looks like I’m still to much of a novice as they just error out for me (no default.nix, so I guess I’m supposed to download the opencv build file and rename it default.nix then re-run the command). The other trouble I had was that I expected python37.opencv4 to be different from opencv, but I suppose that might also be some kind of attribute as well that I should try to look up.

I agree, I just meant it as an example. I was hoping a discussion of that might make it possible for non-expert users to find/report bugs too. There’s a pretty high barrier to entry that results in posts like these from novices like myself adding to the todo-list of maintainers like yourself.

6

These assume you’re in a nixpkgs repo checkout (that’s the dot in those commands). REPL makes sense even with other path like nix repl https://github.com/nixos/nixpkgs/archive/master.tar.gz

1 Like
7

You can run nix edit nixpkgs.opencv to see the file in your current version of nixpkgs, or use nix repl '<nixpkgs>' to start a repl on your current nixpkgs. If you do find the opencv build files, that would tell you the same thing in the meta = ... part.

2 Likes