Created attachment 208597 [details] adding mesa-dri dependency explicitly. Hi, A user of the calibre port is launching calibre from a remote machine where he is not installing the full Xorg stack, but only calibre and it's direct dependencies. He reported in bug #241485 that in this setup the calibre ebook-reader component fails to start properly. Installing mesa-dri fixed the issue for him, letting the calibre component find the swrast driver it was needing. I have reproduced his findings using to VirtualBox VMs, so I guessed qt5-gui is the port whose libraries are actually making the GL calls depending on the mesa-dri drivers. As a side note my machine has an nvidia card and in this combination things don't work anyway, I guess that's because the nvidia dirver overrides libGL and friends. Do you think it is correct to add this run time dependency? For most users installing qt5 on the machine together with the Xserver this is a noop. It could help in other situations. Thanks.
Thinking again about it, I suspect the dependency should be added to mesa-libs or through USES=gl. Any thought about this?
A commit references this bug: Author: adridg Date: Sat Feb 20 18:31:32 UTC 2021 New revision: 566177 URL: https://svnweb.freebsd.org/changeset/ports/566177 Log: Add mesa-dri dependency for qt5-gui There are cases (headless, no xorg-server) where a qt5-gui application still needs to run. It can use swrast, but only if that is installed. Add the mesa-dri dependency to make that happen automatically. For "normal" Qt5 usage, that is, Qt5 on the desktop, xorg-server already pulls this in. The only change is for systems with no X11, no Wayland, but with Qt5 GUI applications. PR: 241490 Submitted by: madpilot Reported by: madpilot Changes: head/x11-toolkits/qt5-gui/Makefile
I've gone and landed your original suggestion. I suppose a USE_GL=sw might have done as well, although we'd need to introduce that in `gl.mk` first. This is the simpler approach.
(In reply to Adriaan de Groot from comment #3) Thanks! This fixed a long standing issue about qt applications usage on remote systems.
(In reply to Guido Falsi from comment #4) But it now add unnecessary fat dependency for headless installations. Why not optional?
(In reply to VVD from comment #5) It could also be an option, but it should be enabled by default, otherwise the problem would not be fixed for people using binary packages. Also, the "fatness" is 51.9 MiB according to pkg on my laptop (amd64). Is that really relevant for modern systems with extremely cheap disk space? (On virtual hosting too)
(In reply to Guido Falsi from comment #6) > Also, the "fatness" is 51.9 MiB according to pkg on my laptop (amd64). Did you miss the elephant dependency? review D16457 is still far away. $ pkg install -qy qt5-gui $ pkg install -n mesa-dri Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. The following 7 package(s) will be affected (of 0 checked): New packages to be INSTALLED: libXv: 1.0.11_2,1 libXvMC: 1.0.12 libedit: 3.1.20191231,1 llvm10: 10.0.1_5 <------------ THIS lua52: 5.2.4 mesa-dri: 20.2.3_1 perl5: 5.32.1_1 Number of packages to be installed: 7 The process will require 759 MiB more space. 124 MiB to be downloaded.
(In reply to Jan Beich from comment #7) I may have not made my question clear. The only relevant question was about the option being disabled by default, as in would you be satisfied by mesa-dri being optional but enabled by default? I can create and propose a patch to add an option, but only if it is acceptable to have it enabled by default. Otherwise (options disabled by default) it would be as useful as not having the dependency at all for 99% of the situations I created this patch to fix. The second part about disk sizes was irrelevant to any decision, but you replied to that one only. Your objection would not persuade me anyway, but I'm not going to fight on this. As I said above I'm willing to create a patch to make this an option, with conditions described above.
There's another way about this, and that is pkg-message (which would say "if you intend to use qt5-gui headless, install mesa-dri"). I'd forgotten about monsters like llvm. However, the point is this: - without mesa-dri, a Qt5-gui-using application can't run the GUI (depending a little on which code paths it takes, I'm sure) - on the desktop, other things will pull in mesa-dri anyway So it comes down to: are uses of qt5-gui where an application (that uses qt5-gui) does *not* need mesa-dri? The original bug report has an n=1 incidence of "no". Perhaps futzing with the QPA will do it (e.g. set the QPA to use offscreen output; in which case I'd return to the pkg-message approach: at some point you have to trust the user to put the parts together that cannot be guessed)
(In reply to Adriaan de Groot from comment #9) I would have no objection to the package message approach. My original submission was a suggestion of a possible solution, which looked reasonable at the time, and also to spur discussion. I'm not "married" to the unconditional dependency approach.
The linked bug is shiboken falling over when there's a newer llvm installed; that is exposed by this change, but should be fixed independently of what this change does. @VVD: while this is a "fat" dependency, the question is: is there **any** way of using an application, which uses qt5-gui, on a headless system, without that dependency? If there is, I'll roll back and shift blame to the user with a pkg-message. If there isn't, then stripping the fat just means "this won't work". So I need a specific example.
(In reply to Adriaan de Groot from comment #11) emulators/virtualbox-ose work without mesa-dri installed via ssh -Y.
I think qbittorrent@nox also uses qt5-gui, but is actually perfectly accessible through webui.
^Triage: ports r566177 resolved the issue 'as reported', last comment is over a year old, assign to committer that resolved, and close. Please create a new issue (referencing this one in See Also), for any remaining issues, improvements or proposed changes