qt4: remove

[ajs124]

Description of changes

qt4 has been EOL since the end of 2015. A look at a calendar tells us it is 2023 now.

Closes #33248

Still WIP. I'm trying to fix/update what I can, but if packages are dead upstream or updates non-trivial and maintainers don't respond, packages will be removed.

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/)
• 22.05 Release Notes (or backporting 21.11 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
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[ajs124]

@GrahamcOfBorg eval

[ajs124]

Qt4 has been EOL since the end of 2015 and a lot of distributions removed it years ago (e.g. Ubuntu 20.04). #33248 was opened in 2017.

I tried to update what I could, but these aren't my packages, so this will still end up removing a few dozen packages.

I'm notifying you, because you are listed as maintainer for one or more of these packages.

Maintainer(s)	Package(s)
tstrobel (has no github handle or id in maintainers/maintainer-list.nix)	omapd
@7c6f434c	eql dssi fmbt
@FRidh	ssr
@Forkk	screencloud
@Hodapp87	appleseed structure-synth seexpr
@MarcWeber	yate scribus_1_4
@Mounium	aliza
@Yarny0	clickshare-csc1
@bjornfor	qwt6_qt4
@bugworm	qtstyleplugin-kvantum-qt4
@cillianderoiste	hydrogen_0
@coroa	fbreader
@danielbarter	avogadro
@dezgeg	gambatte
@drperceptron	tworld2
@edwtjo @offlinehacker	dogecoin
@ehmry	acoustidFingerprinter
@eikek	sqliteman
@fgaz	qremotecontrol-server miniaudicle
@gebner	ibus-qt
@infinisil	namecoin (GUI support)
@lebastr	qmidiroute
@leenaars	animbar
@magnetophon @pmahoney	faust2(alqt|jaqt|lv2)
@orivej-nixos	qmetro
@pSub	valkyrie
@peterhoeg	qscintilla-qt4
@puffnfresh	natron
@qknight	qt-mobility keepassx keepassx2
@roconnor	texmacs (only darwin version)
@steveej	cups-kyodialog3
@svanderburg @orivej-nixos @lovek323	qt4
@svanderburg	qca2 pyqt4
@vanzef	qtscrobbler
@viric	scantailor qucs
nobody	subdownloader qshowdiff windows.jom resim navipowm qtscriptgenerator qimageblitz libbluedevil prison ntrack libjreen libdbusmenu_qt qfsm pyside*

[pSub]

I am fine with the removal of valkyrie. The last release was on 21 October 2010.

[peterhoeg]

If applications are still otherwise working, I see no reason to drop them (and as a consequence no reason to drop qt4). We still carry applications that use GTK2 as an example.

[ajs124]

GTK2 reached it's end of life roughly 4 years after QT4: https://blog.gtk.org/2020/12/16/gtk-4-0/

"applications are still working" is always debatable. python2 "stilI works", as well, but it's unsupported, libraries aren't remaining compatible and it's most likely a security hazard.

IMO this is mainly about maintainability and trying to have software, especially something as large and integral as a framework like QT, in our repository where there is an upstream that at least tries to support and maintain it. Nobody is stopping anyone from having a flake or maintaining these things out of tree, which is why I think something like https://github.com/fossar/nix-phps is a commendable project, but having these things in nixpkgs creates the illusion of being able to support them in an official capacity. Which we are 100% not able to.

[eikek]

Regarding sqliteman, it can be removed IMHO. There are alternatives like sqlitebrowser in nixpkgs.

[klemensn]

Regarding sqliteman, it can be removed IMHO. There are alternatives like sqlitebrowser in nixpkgs.

Agreed, this is what other systems like OpenBSD have done as well:
https://github.com/openbsd/ports/blob/c524e3289150b021496ee47f6027b13850b3ab8d/devel/quirks/files/reference#L6

[klemensn]

GTK2 reached it's end of life roughly 4 years after QT4: https://blog.gtk.org/2020/12/16/gtk-4-0/

"applications are still working" is always debatable. python2 "stilI works", as well, but it's unsupported, libraries aren't remaining compatible and it's most likely a security hazard.

IMO this is mainly about maintainability and trying to have software, especially something as large and integral as a framework like QT, in our repository where there is an upstream that at least tries to support and maintain it. Nobody is stopping anyone from having a flake or maintaining these things out of tree, which is why I think something like https://github.com/fossar/nix-phps is a commendable project, but having these things in nixpkgs creates the illusion of being able to support them in an official capacity. Which we are 100% not able to.

Exactly.

Keeping unmaintained frameworks/languages/etc. around is a huge burden.
There will always be incompatible future changes breaking obsolete software and (security related) bugs in unmaintained software.

Transitions to newer versions, e.g. Python 2 to 3 or Qt 4 to 5, are a huge ordeal already as they practically always cause waves of new issues for both maintainers and users.

Beating dead horses like Python 2, Qt 4, etc. just keeps adding overhead.

[ajs124]

I think it would be nice if we could get this in, before RFC140 is fully implemented.

[Atemu]

This appears to have broken uim:

qtPreHook
Error: wrapQtAppsHook is not used, and dontWrapQtApps is not set.