libv4l: don't pull qtbase into cross-compiled builds

[eryngion]

libv4l definition explicitly disables withUtils which in its turn disables withQt, but without this change the cross-compiled version still pulls in qtbase as a build-time dependency:

/nix/store/4d39hzhiafjd9a7bhwgx71pf107jam7f-qtwebengine-aarch64-unknown-linux-gnu-5.15.19.drv
└───/nix/store/vqipnyd68wllhxm06aa0a1a57rs4vrsk-ffmpeg-aarch64-unknown-linux-gnu-7.1.3.drv
    └───/nix/store/yp8hidwx2mx1ih08aqqp7pah0dgs3r5h-v4l-utils-aarch64-unknown-linux-gnu-1.32.0.drv
        └───/nix/store/s2bqx6qwch94g60axz84zs6d3cp9sjx2-qtbase-6.10.1.drv
            └───/nix/store/vkw73c46w1lkcx5vl5wa0519scahnadq-qttranslations-6.10.1.drv
                └───/nix/store/5wpq717cais7avynrwvx2p7hhcn51b9w-qttools-6.10.1.drv
                    └───/nix/store/48w6gal7n8r59bnkwiqg8n94l81zvs8x-qtbase-6.10.1.drv

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[doronbehar]

LGTM mostly.

[Yarny0]

Hi @eryngion, and thanks for your contribution!

I did some tests, on my x86_64-linux machine:

• v4l-utils yields the same derivation hash as before
• libv4l yields the same derivation hash as before
• pkgsCross.aarch64-multiplatform.v4l-utils builds without error
• pkgsCross.aarch64-multiplatform.libv4l builds without error

I can't test those cross-compiled packages, unfortunatelly, but I expect them to work.

I approve this pull request being merged.

It is good that you picked staging as the target branch, since v4l-utils usually causes mass rebuild. However, in this case, only cross-compilation is affected, so I suggest to retarget the pull request to master. Please have a look at https://github.com/NixOS/nixpkgs/blob/00c21e4c93d963c50d4c0c89bfa84ed6e0694df2/CONTRIBUTING.md#rebasing-between-branches-ie-from-master-to-staging, as changing the target branch can lead to a mess if not done right.

[eryngion]

There's one more reason I chose staging: I have a couple of other PRs that can target only staging and it'll be mildly useful to have this commit in the same branch. Yeah, it'll get merged back from master too, but it'll take slightly more time.

So, if you don't mind, I'd prefer staging. But again: not a big deal.

[Yarny0]

I'm not sure if that's really worth it, since master is merged into staging every 6 hours (actually via staging-next, so it would be 12h at most), and merging things into master instead of staging reduces the potential of conflicts for later contributions.
However, in the long run, it will not make a difference. I approve this pull request.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/2774

[eryngion]

I've rebased it onto master but changing the target on GitHub is no longer available for me.

[Yarny0]

I've rebased it onto master but changing the target on GitHub is no longer available for me.

Uh-oh! Sometimes it's best to rebase onto a merge-base of master, staging-next and staging -- that way there won't be any stray commits, no matter what the target branch is. If you can't change the target branch, it might help to change the pull request to draft state.
Otherwise, I'm out of ideas (short of closing and recreating the pull request, of course). Maybe someone else has an idea.

Review dismissed automatically

[doronbehar]

I don't have a general advice on how to deal with these kind of situation. What I did now was done with gh and I dropped the commits with git rebase --interactive.

Review dismissed automatically

[eryngion]

Updating base branch with gh have worked, thanks for the suggestion. There was no need to drop commit though: they were only shown because the PR still targeted staging.

[Yarny0]

Thanks @eryngion , for your hard work! I have no objections and reaffirm my approval.