On Sun, Oct 22, 2017 at 07:57:08PM +0200, Ingo Schwarze wrote: > Hi Matthias, > > Matthias Kilian wrote on Sun, Oct 22, 2017 at 06:10:01PM +0200: > > On Sun, Oct 22, 2017 at 12:38:09AM +0200, Ingo Schwarze wrote: > > >> libGL error: failed to open drm device: Permission denied > >> libGL error: failed to load driver: i965 > > > Hmm. This happens if you don't own /dev/drm0. > > I bet you get the same error messages when running glxgears(1). > > You were right on both points. > > > I'm using xenodm, > > Me too. > > > which should take care of it (/etc/xenodm/GiveConsole): > > > > if [ -c /dev/drm0 ]; then > > chown $USER /dev/drm0 > > fi > > Strange. I still had > > DisplayManager._0.setup: /etc/X11/xenodm/Xsetup_0 > DisplayManager._0.startup: /etc/X11/xenodm/GiveConsole > DisplayManager._0.reset: /etc/X11/xenodm/TakeConsole > > in /etc/X11/xenodm/xenodm-config; after changing that to > > DisplayManager.unix_0.setup: /etc/X11/xenodm/Xsetup_0 > DisplayManager.unix_0.startup: /etc/X11/xenodm/GiveConsole > DisplayManager.unix_0.reset: > /etc/X11/xenodm/TakeConsole
Hmm the commit that needed this was reverted. Looks like either you haven't fully upgraded your system or that something else is broken. > > DRM works now. I would have expected sysmerge(8) to maintain that > file for me, no idea why it didn't. Whatever, that's unrelated to > the task at hand. > > >> Why do you list png explicitly in LIB_DEPENDS, but not jpeg? > >> Given that the only other direct lib dependency, qtbase, requires > >> both jpeg and png directly and that the xpdf cmake run explicitly > >> tests for both, what is the difference? > > > Sloppiness on my side. png could have been removed in the past, too > > because even x11/motif pulled it in. Now removed in the new diff. > > Looks like you say so, but didn't, you still have: > > > +LIB_DEPENDS+= graphics/png > > Confirming rsadowski@'s observation that it builds without gmake(1) > - at least on amd64 - and using his suggestion about BUILD- and > RUN_DEPENDS (with comments explaining why), see at the end for more > to apply on top of what you already have. > > Regarding printing - i developed a habit of always printing all PDF > documents with xpdf(1) many years ago, if i remember correctly > because the HP PostScript printers i used back then often were > unhappy with PDF files and printing from xpdf(1) sent them real > PostScript code (if i understood correctly back then). Right now, > i tried printing one of my PDF documents (created with pdflatex(1)) > directly with lpr(1) on a Kyocera PostScript printer and was surprised > that it just works. I'm not saying all this makes much sense > nowadays (or even back then), probably i should simply change my > habits, i'm merely telling you because you asked whether anybody > uses xpdf(1) for printing... > > Yours, > Ingo > > > --- Makefile.kili Sun Oct 22 18:42:29 2017 > +++ Makefile Sun Oct 22 19:40:26 2017 > @@ -15,11 +15,18 @@ > MODULES= devel/cmake \ > X11/qt5 > > -LIB_DEPENDS+= graphics/png > +# The cmake autoconfiguration systems checks for the presence > +# of these libraries at configuration time, even though they > +# are not used for building or linking. > +BUILD_DEPENDS+= graphics/jpeg \ > + graphics/tiff > > -RUN_DEPENDS= print/ghostscript/gnu-fonts > - > -USE_GMAKE= Yes > +# Even though xpdf is not linked against libjpeg and libtiff, > +# Qt loads these libraries at run time, and the two file formats > +# can be selected in the "File > Save Image" menu. > +RUN_DEPENDS= graphics/jpeg \ > + graphics/tiff \ > + print/ghostscript/gnu-fonts > > # Don't pick up libpaper -- the build currently fails to link against > # it. -- Matthieu Herrb
