qutebrowser-qt5: replace qt5.qutebrowser

[dotlambda]

Description of changes

see #251660

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[ghost]

This package is already named qutebrowser.

We already have a package named qutebrowser-qt6.

There is no need to pollute top-level/all-packages.nix with yet-more decorated package names. Prior to #250171 we were automatically detecting and using the newest available version of QT for the qutebrowser package. That's the right way to do it.

[dotlambda]

Prior to #250171 we were automatically detecting and using the newest available version of QT for the qutebrowser package.

We were? Afaict we were simply using Qt5 by default.

[dotlambda]

While I agree that it's annoying some people would have to replace qutebrowser with qutebrowser-qt5 after this change I see a benefit in having qutebrowser be the default that upstream suggests, i.e. Qt6. Until #245322 is ready we sadly can't choose the correct version for people.

[rnhmjoj]

We already have a package named qutebrowser-qt6.

qutebrowser should default to Qt6, because that's what upstream recommends.

There is no need to pollute top-level/all-packages.nix with yet-more decorated package names.

Agreed, and that's why qutebrowser-qt6 should be removed as well, it should not have been introduced in the first place. Unfortunately the upgrade to Qt6 took so long that people got impatient...

[nrdxp]

If we care about not polluting the top-level we do have the option of nesting the qt5 variant inside the top-level derivation attribute somewhere, although I'm not sure if there is any precedent for that elsewhere.

[thiagokokada]

In general this looks good to me, but I think this kinda of change (defaulting to Qt6 instead Qt5) should have a entry in release notes.

The qutebrowser maintainers agree that the Qt 6 version should be the default.

[ghost]

This pr does not change any defaults

Then why was my review deleted with "The qutebrowser maintainers agree that the Qt 6 version should be the default." as the justification?

[Artturin]

Which is worse, a top-level attr or a non qt package in the qt5 set

[ghost]

Which is worse, a top-level attr or a non qt package in the qt5 set

We have plenty of packages besides python in the pythonPackages set.

Indeed, the difference between python310Packages and python311Packages is precisely which version of python your python-using package uses.

[Artturin]

Which is worse, a top-level attr or a non qt package in the qt5 set

We have plenty of packages besides python in the pythonPackages set.

Indeed, the difference between python310Packages and python311Packages is precisely which version of python your python-using package uses.

Python programs are not supposed to be in pythonPackages, only modules.

this is not the hill to die on

[Artturin]

It needs to have -qt5 appended to the pname

nixpkgs/pkgs/applications/networking/browsers/qutebrowser/default.nix

Line 29 in 40e5c02

pname = "qutebrowser";

Because nix-env uses name , idk what it does when 2 derivations have the same pname and version

[dotlambda]

I honestly don't care, nix-env shouldn't be used. This might be fixed by marking the Qt 5 version insecure though.

[Artturin]

Added it

[Artturin]

@amjoseph-nixpkgs I don't think there's anything here (functionally) that you should be against since it's just moving the attr.

We have done -X suffixed attrs before too, though usually they're done via a callPackage arguments.

[ghost]

Indeed, the difference between python310Packages and python311Packages is precisely which version of python your python-using package uses.

Python programs are not supposed to be in pythonPackages, only modules.

Can you imagine how bonkers it would be if every package that depended on python had three top-level variations?

• pytorch
• pytorch-python310
• pytorch-python311

... and people had to deal with the version that works for them being renamed from pytorch to pytorch-python310 while the python311 bugs in pytorch got sorted out?

[ghost]

We should mark qt6Packages.qtbase as meta.broken if stdenv.buildPlatform != stdenv.hostPlatform.

[ghost]

Suggested change

	inherit (__splicedPackages.qt6Packages) qtbase qtwebengine wrapQtAppsHook qtwayland;
	};
	qutebrowser-qt5 = callPackage ../applications/networking/browsers/qutebrowser {
	inherit (__splicedPackages.libsForQt5) qtbase qtwebengine wrapQtAppsHook qtwayland;
	inherit (if stdenv.buildPlatform == stdenv.hostPlatform then __splicedPackages.qt6Packages else __splicedPackages.libsForQt5)
	qtbase qtwebengine wrapQtAppsHook qtwayland;
	};

[dotlambda]

I don't think we should make it intransparent to the user that they're using a different Qt version when cross-compiling.

[dotlambda]

We should mark qt6Packages.qtbase as meta.broken if stdenv.buildPlatform != stdenv.hostPlatform.

That can be done in a separate PR.

[dotlambda]

Can you imagine how bonkers it would be if every package that depended on python had three top-level variations?

It would be. That's why you have to use override if you want to use a different Python version with a Python application. I think that would be a perfectly fine solution with qutebrowser too, but I think qutebrowser-qt5 can be added for your convenience.

[Artturin]

https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/qt5-packages.nix and https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/qt6-packages.nix seems to be the places for packages like this?

[dotlambda]

https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/qt5-packages.nix and https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/qt6-packages.nix seems to be the places for packages like this?

No, that's for Qt libraries.

[dotlambda]

@Artturin Do you think this can be merged?

[rnhmjoj]

It seems to be working normally, though I noticed this warning:

WARNING: QtWebEngine version mismatch - unexpected behavior might occur, please open a bug about this.
  Early version: QtWebEngine 5.15.4, based on Chromium 87.0.4280.144 (from PyQt)
  Real version:  QtWebEngine 5.15.14, based on Chromium 87.0.4280.144

[github-actions]

Successfully created backport PR for release-23.11:

• [Backport release-23.11] qutebrowser-qt5: replace qt5.qutebrowser #269626

[rnhmjoj]

So... is the "QtWebEngine version mismatch" warning not important?

[Artturin]

So... is the "QtWebEngine version mismatch" warning not important?

IDK, it was happening before so /shrug.

[trofi]

Minor eval failure fix around tests.cross.sanity: #283737