When I try to start the ebook-reader it dumps core on me. I'm running calibre on a headless machine using "ssh -Y". Calibre outputs the following: libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i965 libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast DBusExport: Failed to connect to DBUS session bus, with error: org.freedesktop.DBus.Error.NotSupported: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i965 libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast [1025/115458.668591:ERROR:stack_trace_posix.cc(652)] Not implemented reached in bool base::debug::(anonymous namespace)::SandboxSymbolizeHelper::CacheMemoryRegions() libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i965 libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast [1025/115458.910084:ERROR:stack_trace_posix.cc(652)] Not implemented reached in bool base::debug::(anonymous namespace)::SandboxSymbolizeHelper::CacheMemoryRegions() QQuickWidget: Failed to make context current QQuickWidget::resizeEvent() no OpenGL context QQuickWidget: Failed to make context current [1025/115458.968620:ERROR:stack_trace_posix.cc(652)] Not implemented reached in bool base::debug::(anonymous namespace)::SandboxSymbolizeHelper::CacheMemoryRegions() QQuickWidget: Attempted to render scene with no context QOpenGLShaderProgram: could not create shader program QOpenGLShader: could not create shader Could not link shader program: ""
pkg info calibre calibre-4.2.0 Name : calibre Version : 4.2.0 Installed on : Mon Oct 21 09:43:02 2019 CEST Origin : deskutils/calibre Architecture : FreeBSD:12:amd64 Prefix : /usr/local Categories : python deskutils Licenses : GPLv3 Maintainer : madpilot@FreeBSD.org WWW : https://calibre-ebook.com/ Comment : Ebook management application Shared Libs required: libglib-2.0.so.0 libicudata.so.65 libQt5Gui.so.5 libQt5Core.so.5 libGL.so.1 libicuuc.so.65 libfreetype.so.6 libchm.so.0 libQt5DBus.so.5 libQt5Widgets.so.5 libmtp.so.9 libintl.so.8 libpython2.7.so.1 libpodofo.so.0 libhunspell-1.7.so.0 libicui18n.so.65 libfontconfig.so.1 libgthread-2.0.so.0 libicuio.so.65 Annotations : FreeBSD_version: 1200086 repo_type : binary repository : Synth Flat size : 59.6MiB Description : Calibre is meant to be a complete e-library solution and thus includes library management, format conversion, news feeds to ebook conversion, as well as e-book reader sync features and an integrated e-book viewer. WWW: https://calibre-ebook.com/ pkg info -d calibre calibre-4.2.0: libXrender-0.9.10_2 libXext-1.3.4,1 libX11-1.6.8,1 qt5-widgets-5.13.0_1 qt5-gui-5.13.0_2 py27-qt5-widgets-5.13.0 py27-qt5-gui-5.13.0 fontconfig-2.12.6,1 py27-qt5-webengine-5.12.1 py27-mechanize-0.4.3 py27-html5-parser-0.4.8 py27-cssselect-1.0.3 py27-css-parser-1.0.4 py27-beautifulsoup-4.8.0 py27-regex-2018.02.21 py27-qt5-xmlpatterns-5.13.0 py27-chardet-3.0.4_1 hunspell-1.7.0_2 freetype2-2.10.1 py27-qt5-network-5.13.0 py27-netifaces-0.10.9 libmtp-1.1.16 shared-mime-info-1.10_1 chmlib-0.40_1 python27-2.7.17 py27-qt5-svg-5.13.0 py27-pillow-6.2.0 poppler-utils-0.81.0_2 poppler-qt5-0.81.0_1 podofo-0.9.6_1 mesa-libs-18.3.2_2 libwmf-0.2.8.4_15 py27-dnspython-1.16.0 xdg-utils-1.1.3_1 qt5-dbus-5.13.0_1 qt5-core-5.13.0_1 py27-sip-4.19.18,1 py27-qt5-core-5.13.0 py27-msgpack-0.6.2 py27-lxml-4.3.4_1 py27-dbus-1.2.8 py27-dateutil-2.8.0 icu-65.1,1 glib-2.56.3_6,1 gettext-runtime-0.20.1 desktop-file-utils-0.23 py27-sqlite3-2.7.17_7 py27-apsw-3.29.0
Hi, As you may know the ebook-reader component of calibre has been completely rewritten in version 4.0. So my first question is, the issue appeared when updating from 3.x to 4.x? Or did the ebook-reader component work fine in your setup in 4.0 and 4.1? If you skipped 4.0 and 4.1 The errors you show indicate the software is trying to access Direct Rendering features, through OpenGL, and it's actually the QT libraries trying to perform the operation. I don't know if such rendering operations can work through a network connection. I'll try to test and see if I can replicate the problem. Could you file a bug report directly with the upstream stating your usage scenario and pasting these errors there? This would help speed up finding an explanation to these errors. Please add me as CC or link here to the bug report you file so I can follow up. Upstream bug management is here: https://bugs.launchpad.net/calibre
(In reply to Guido Falsi from comment #2) I performed a quick test with a virtual machine and I fear your usage scenario can't be supported by calibre 4.x. I simply installed calibre in a virtualbox VM and connected via ssh to it. I got the same failure you got, even if that VM had a full Xorg installation. As a side note in my case the ebook-reader component is freezing, but not crashing, it can be closed cleanly and the main calibre window keeps working. I know this is no solution, but there is no crash or actual core dump. It is strictly a runtime error. I was hoping having more Xorg components installed could be a solution and I then could add dependencies, but unluckily it does not look like that's the case. This is true for any GL program trying to use direct rendering. You can verify it by installing the "mesa-demos" package and trying to run glxgears via ssh from a remote machine: > glxgears libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 34 Current serial number in output stream: 36 The error states the same thing calibre was stating, it was unable to create a GL context to draw on. Looks like the new reader uses GL extensively and so cannot work on a remote display. I think you should anyway file a bug report upstream, so this can be tracked and maybe the developers are willing to implement a workaround.
(In reply to Guido Falsi from comment #3) I already tried this on a Linux system (using ssh -Y as well). It just works... After trying to enforce SW-rastering using "LIBGL_ALWAYS_SOFTWARE" calibre complained about not being able to load swrast_dri.so. Some digging showed that this is part of graphics/mesa-dri. I installed graphics/mesa-dri and now the viewer just works. So there is some missing dependency to graphics/mesa-dri (maybe in one of the qt libraries?)
(In reply to Matthias Pfaller from comment #4) Thanks for digging this for me. I was planning more tests but did not have time right now. My personal opinion is the dependency should be in the QT component performing the calls to the GL libraries. And it looks like it should be a runtime only dependency. From the errors I'm seeing my guess is it's x11-toolkits/qt5-gui, which calls OpenGL directly. I'll file a bug report on that port proposing a simple patch.
(In reply to Matthias Pfaller from comment #4) I tried to replicate your results, but in the VM I'm using mesa-dri is already installed, and I'm getting errors anyway, even setting LIBGL_ALWAYS_SOFTWARE=1 in the environment. Could you give me more details on your fix? Before proposing patches to ohers I need to be sure the change really fixes the issue.
(In reply to Guido Falsi from comment #6) Looks like how successful installing the mesa-dri port is depends on the combination between source and destination machine graphics hardware. I'm getting different errors when I launch calibre by going via ssh into the VirtualBOX VM and when I launch it by going via ssh to my desktop machine from the VM. My machine has an nvidia graphics card, so maybe the combination between virtualbox and my machine cannot work. I'm getting less confident that forcing a dependency for everyone is a good fix.
(In reply to Guido Falsi from comment #7) Yes, the nvidia driver replaces libGL (via libmap.conf), so this could be the cause I am unable to make it work here. Even installing the nvidia driver on the remote machine does not fix the problem. I can confirm that doing the ssh thing between two virtual box VMs makes it work. So while your solution is technically correct but not universal.
^Triage: Dependent bug 241490 was resolved in ports r566177 February 2021. Does anything remain to resolve this issue as reported?
Close as fixed, the unconditional dependency has been added.