Re: Update textproc/xpdf

2017-10-30 Thread Matthias Kilian
Hi,

On Tue, Oct 24, 2017 at 07:48:03PM +0200, Ingo Schwarze wrote:
> > tiff export still doesn't work).
> 
> That's strange, it just works for me with the patch as you sent it,
> both for a small text-only PDF and for a large graphics-heavy PDF.

Oh, the joy of modern plugin-based software "architecture".

After some more tracing, it looks like x11/qt5/qtimageformats is
required at runtime (but not necessarily at build time) by xpdf to
export to tiff.

Updated diff (completely untested for now) appended to this mail.
Maybe the dependencies are still not optimal (e.g. make qtimageformats
both build and run dep and drop tiff instead), but this is something
which can be done later.

> > For printing (using DXPDFWIDGET_PRINTING=true), the cmake magic
> > fails to add -L${LOCALBASE}/lib when linking the xpdf executable.
> > I really need some help from a cmake expert here (CMAKE_LIBRARY_PATH
> > doesn't help).
> 
> As far as i understand, CMAKE_LIBRARY_PATH only tells commands like
> find_library() to search such places when detecting libraries, but
> doesn't by itself pass any options to the linker.
> 
> The problem is here:
> 
>   c++ [...] -o xpdf-qt/xpdf -L/usr/local/lib/qt5/.  -L/usr/X11R6/lib \
> -Wl,-rpath,/usr/local/lib/qt5/.:/usr/X11R6/lib: \
>   -lQt5PrintSupport -lcups -lcups -lfreetype -lpthread \
>   -lQt5Widgets -lQt5Gui -lQt5Core \
> -Wl,-rpath-link,/usr/X11R6/lib:/usr/local/lib
> 
> The path /usr/local/lib is already mentioned, but too late, after -lcups.
> 
> I poked around quite a bit but still have no idea why cmake screws
> up the order of the arguments so badly.
> 
> Yet i got a bit further.  With the dirty patch below, to be applied
> on top of what you sent, i got the port to build, package, pass
> lib-depends-check, run, and display a "Print" menu item and dialogue.
> But it is not yet useful.  The only "Printer Name" that dialogue
> offers is "Print to file (PDF)", no default printer, even though:
[...]

I hope to find some cmake, cups and qt experts in Berlin and get
them drunk enough to explain things to me before I'm too drunk to
understand ;-)

Until then, I'll just ignore the "xpdf doesn't print" problem.

Ciao,
Kili

ps: there's a new xpdf/XpdfReader version around (4.00.01), fixing
printing problems, but AFAIK that only affects Windows builds.


Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
retrieving revision 1.89
diff -u -p -r1.89 Makefile
--- Makefile26 Jul 2017 22:45:31 -  1.89
+++ Makefile30 Oct 2017 21:08:47 -
@@ -2,33 +2,49 @@
 
 COMMENT=   PDF viewer for X11
 
-DISTNAME=  xpdf-3.04
+DISTNAME=  xpdf-4.00
 CATEGORIES=textproc x11
-REVISION=  2
 
-MASTER_SITES=  ftp://ftp.foolabs.com/pub/xpdf/ \
-   http://mirror.ctan.org/support/xpdf/
+MASTER_SITES=  https://www.xpdfreader.com/dl/
 
-HOMEPAGE=  http://www.foolabs.com/xpdf/
+HOMEPAGE=  https://www.xpdfreader.com/
 
 # GPLv2 only or GPLv3 only or both (at our choice)
 PERMIT_PACKAGE_CDROM=  Yes
 
-LIB_DEPENDS+=  graphics/png x11/motif
-USE_GMAKE= Yes
-CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS=--enable-multithreaded \
-   --without-Sgm-library \
-   --without-libpaper-library
-
-CONFIGURE_ENV=  CPPFLAGS='-I${X11BASE}/include/freetype2 -I${X11BASE}/include 
-I${LOCALBASE}/include -DLOCALBASE="\"${LOCALBASE}\""' \
-   LDFLAGS="-L${X11BASE}/lib -L${LOCALBASE}/lib -lm -lz"
-MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -lXm'
+MODULES=   devel/cmake \
+   X11/qt5
 
 RUN_DEPENDS=   print/ghostscript/gnu-fonts
 
-WANTLIB=   ICE SM X11 Xext Xpm Xt freetype Xm \
-   c m png pthread ${COMPILER_LIBCXX} z
+# Add jpeg, png, tiff as rdep and bdep so cmake always pick them up and
+# xpdf is able to export to those formats. Not strictly needed for jpeg
+# and png, because they are pulled in by qt and its dependencies, but
+# better be explicit here.
+# In addtion, qtimageformats is required at runtime to let tiff export
+# work.
+RUN_DEPENDS += graphics/jpeg \
+   graphics/png \
+   graphics/tiff \
+   x11/qt5/qtimageformats
+
+BUILD_DEPENDS +=graphics/jpeg \
+   graphics/png \
+   graphics/tiff
+
+# Don't pick up libpaper -- the build currently fails to link against
+# it.
+CONFIGURE_ARGS +=  -DHAVE_PAPER_H=0
+
+# XXX
+# Doesn't work, neither with -DCMAKE_LIBRARY_PATH=${LOCALBASE}/lib nor
+# with CMAKE_LIBRARY_PATH=${LOCALBASE}/lib in the environment.
+# CONFIGURE_ARGS +=-DXPDFWIDGET_PRINTING=true
+
+CXXFLAGS+= -DLOCALBASE=\\\"${LOCALBASE}\\\"
+
+WANTLIB=   Qt5Core Qt5Gui Qt5Widgets freetype c m png pthread \
+   ${COMPILER_LIBCXX} z
 
 NO_TEST=   Yes
 
@@ -37,13 +53,9 @@ post-install:
${INSTALL_DATA} ${WRKSRC}/doc/sample-xpdfrc \
${PREFIX}/share/examples/xpdf/xpdfrc
 # already in poppler-utils
-

Re: Update textproc/xpdf

2017-10-24 Thread Ingo Schwarze
Hi Matthias,

Matthias Kilian wrote on Mon, Oct 23, 2017 at 10:27:01PM +0200:

> tiff export still doesn't work).

That's strange, it just works for me with the patch as you sent it,
both for a small text-only PDF and for a large graphics-heavy PDF.

> For printing (using DXPDFWIDGET_PRINTING=true), the cmake magic
> fails to add -L${LOCALBASE}/lib when linking the xpdf executable.
> I really need some help from a cmake expert here (CMAKE_LIBRARY_PATH
> doesn't help).

As far as i understand, CMAKE_LIBRARY_PATH only tells commands like
find_library() to search such places when detecting libraries, but
doesn't by itself pass any options to the linker.

The problem is here:

  c++ [...] -o xpdf-qt/xpdf -L/usr/local/lib/qt5/.  -L/usr/X11R6/lib \
-Wl,-rpath,/usr/local/lib/qt5/.:/usr/X11R6/lib: \
  -lQt5PrintSupport -lcups -lcups -lfreetype -lpthread \
  -lQt5Widgets -lQt5Gui -lQt5Core \
-Wl,-rpath-link,/usr/X11R6/lib:/usr/local/lib

The path /usr/local/lib is already mentioned, but too late, after -lcups.

I poked around quite a bit but still have no idea why cmake screws
up the order of the arguments so badly.

Yet i got a bit further.  With the dirty patch below, to be applied
on top of what you sent, i got the port to build, package, pass
lib-depends-check, run, and display a "Print" menu item and dialogue.
But it is not yet useful.  The only "Printer Name" that dialogue
offers is "Print to file (PDF)", no default printer, even though:

  schwarze@isnote $ pkg_info | grep cups
  cups-libs-2.2.4p1   CUPS libraries and headers
  schwarze@isnote $ rcctl check lpd  
  lpd(ok)

Regarding patch-xpdf-qt_CMakeLists_txt, i found no way to get the
desired effect using find_file(), find_library(), find_package(),
or something similar - everything i tried failed in various ways
for reasons that remain mysterious to me.  The only way i found was
hardcoding /usr/local/* for the "xpdf" target.

Regarding patch-xpdf-qt_XpdfWidgetPrint_cc, that looks like a
serious instance of the well-known All-the-world-is-Linux-Syndrom.

Maybe we should just give up and drop printing support from xpdf?
I mean, linking it against a behemoth like cups-libs isn't all that
nice, even if we could get it to work...

Yours,
  Ingo


--- Makefile.kili   Tue Oct 24 14:46:54 2017
+++ MakefileTue Oct 24 19:17:35 2017
@@ -15,9 +15,11 @@
 MODULES=   devel/cmake \
X11/qt5
 
+LIB_DEPENDS += print/cups,-libs
+
 RUN_DEPENDS=   print/ghostscript/gnu-fonts
 
-# Add jpeg, png, tiff as rdep and bdep so cmake always pick them up and
+# Add jpeg, png, tiff as rdep and bdep so cmake always picks them up and
 # xpdf is able to export to those formats. Not strictly needed for jpeg
 # and png, because they are pulled in by qt and its dependencies, but
 # better be explicit here.
@@ -37,11 +39,12 @@
 # XXX
 # Doesn't work, neither with -DCMAKE_LIBRARY_PATH=${LOCALBASE}/lib nor
 # with CMAKE_LIBRARY_PATH=${LOCALBASE}/lib in the environment.
-# CONFIGURE_ARGS +=-DXPDFWIDGET_PRINTING=true
+CONFIGURE_ARGS +=  -DXPDFWIDGET_PRINTING=true
 
 CXXFLAGS+= -DLOCALBASE=\\\"${LOCALBASE}\\\"
 
-WANTLIB=   Qt5Core Qt5Gui Qt5Widgets freetype c m png pthread \
+WANTLIB=   Qt5Core Qt5Gui Qt5PrintSupport Qt5Widgets \
+   c cups freetype m png pthread \
${COMPILER_LIBCXX} z
 
 NO_TEST=   Yes
Index: patches/patch-xpdf-qt_CMakeLists_txt
===
RCS file: patches/patch-xpdf-qt_CMakeLists_txt
diff -N patches/patch-xpdf-qt_CMakeLists_txt
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-xpdf-qt_CMakeLists_txt24 Oct 2017 17:26:44 -
@@ -0,0 +1,23 @@
+$OpenBSD$
+
+Index: xpdf-qt/CMakeLists.txt
+--- xpdf-qt/CMakeLists.txt.orig
 xpdf-qt/CMakeLists.txt
+@@ -40,6 +40,7 @@ if ((QT4_FOUND OR Qt5Widgets_FOUND)
+ else ()
+   add_definitions(-DXPDFWIDGET_PRINTING=1)
+   set(XPDFWIDGET_PRINT_MODULES XpdfWidgetPrint.cc)
++  include_directories(/usr/local/include)
+ endif ()
+   else ()
+ set(XPDFWIDGET_PRINT_MODULES "")
+@@ -80,7 +81,8 @@ if ((QT4_FOUND OR Qt5Widgets_FOUND)
+ ${XPDFWIDGET_MOC}
+ ${XPDF_ICONS}
+   )
+-  target_link_libraries(xpdf ${QT_LIBRARIES} ${EXTRA_QT_LIBRARIES}
++  target_link_libraries(xpdf -L/usr/local/lib 
++${QT_LIBRARIES} ${EXTRA_QT_LIBRARIES}
+ ${FREETYPE_LIBRARY} ${FREETYPE_OTHER_LIBS}
+ ${DTYPE_LIBRARY} ${LCMS_LIBRARY}
+ ${CMAKE_THREAD_LIBS_INIT})
Index: patches/patch-xpdf-qt_XpdfWidgetPrint_cc
===
RCS file: patches/patch-xpdf-qt_XpdfWidgetPrint_cc
diff -N patches/patch-xpdf-qt_XpdfWidgetPrint_cc
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-xpdf-qt_XpdfWidgetPrint_cc24 Oct 2017 17:26:44 -
@@ -0,0 +1,23 @@
+$OpenBSD$
+
+Index: xpdf-qt/XpdfWidgetPrint.cc
+--- xpdf-qt/XpdfWidgetP

Re: FWD: Re: Update textproc/xpdf

2017-10-23 Thread Matthias Kilian
Hi,

On Mon, Oct 23, 2017 at 06:05:08PM +0200, Alexander Bluhm wrote:
> On Sun, Oct 22, 2017 at 06:26:15PM +0200, Matthias Kilian wrote:
> > I'll try it later this evening. But I always wondered why one wants
> > to print a pdf out of a pdf *viewer* ;-)
> 
> I have always used xpdf to convert the wanted pages to postscript
> and send them with lpr to my printer.  You can even type "ssh
> myprinthost lpr" in the command field and do it remotely.
> 
> What is wrong with that workflow?  Is there a better way to print
> pages of pdf on a postscript printer?  ghostview?

Did you miss the smiley above?

Anyway, here's an updated diff, with some suggestions included
(remove USE_GMAKE, add rdeps/bdeps for jpeg, png, tiff, allthough
tiff export still doesn't work).

For printing (using DXPDFWIDGET_PRINTING=true), the cmake magic
fails to add -L${LOCALBASE}/lib when linking the xpdf executable.
I really need some help from a cmake expert here (CMAKE_LIBRARY_PATH
doesn't help).

And for tiff export, all I see (after some stat(2) and lstat(2) calls)
ist this:

 31413 xpdf CALL  
open(0x8305c186498,0x10601,0666)
 31413 xpdf NAMI  "/home/kili/apu2/foo.tiff"
 31413 xpdf RET   open 14/0xe
 31413 xpdf CALL  fcntl(14,F_SETFD,FD_CLOEXEC)
 31413 xpdf RET   fcntl 0
 31413 xpdf CALL  close(14)
 31413 xpdf RET   close 0
 31413 xpdf CALL  unlink(0x8305c186498)
 31413 xpdf NAMI  "/home/kili/apu2/foo.tiff"
 31413 xpdf RET   unlink 0

Ciao,
Kili

Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
retrieving revision 1.89
diff -u -p -r1.89 Makefile
--- Makefile26 Jul 2017 22:45:31 -  1.89
+++ Makefile23 Oct 2017 20:18:11 -
@@ -2,33 +2,47 @@
 
 COMMENT=   PDF viewer for X11
 
-DISTNAME=  xpdf-3.04
+DISTNAME=  xpdf-4.00
 CATEGORIES=textproc x11
-REVISION=  2
 
-MASTER_SITES=  ftp://ftp.foolabs.com/pub/xpdf/ \
-   http://mirror.ctan.org/support/xpdf/
+MASTER_SITES=  https://www.xpdfreader.com/dl/
 
-HOMEPAGE=  http://www.foolabs.com/xpdf/
+HOMEPAGE=  https://www.xpdfreader.com/
 
 # GPLv2 only or GPLv3 only or both (at our choice)
 PERMIT_PACKAGE_CDROM=  Yes
 
-LIB_DEPENDS+=  graphics/png x11/motif
-USE_GMAKE= Yes
-CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS=--enable-multithreaded \
-   --without-Sgm-library \
-   --without-libpaper-library
-
-CONFIGURE_ENV=  CPPFLAGS='-I${X11BASE}/include/freetype2 -I${X11BASE}/include 
-I${LOCALBASE}/include -DLOCALBASE="\"${LOCALBASE}\""' \
-   LDFLAGS="-L${X11BASE}/lib -L${LOCALBASE}/lib -lm -lz"
-MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -lXm'
+MODULES=   devel/cmake \
+   X11/qt5
 
 RUN_DEPENDS=   print/ghostscript/gnu-fonts
 
-WANTLIB=   ICE SM X11 Xext Xpm Xt freetype Xm \
-   c m png pthread ${COMPILER_LIBCXX} z
+# Add jpeg, png, tiff as rdep and bdep so cmake always pick them up and
+# xpdf is able to export to those formats. Not strictly needed for jpeg
+# and png, because they are pulled in by qt and its dependencies, but
+# better be explicit here.
+# But note that tiff export doesn't work.
+RUN_DEPENDS += graphics/jpeg \
+   graphics/png \
+   graphics/tiff
+
+BUILD_DEPENDS +=graphics/jpeg \
+   graphics/png \
+   graphics/tiff
+
+# Don't pick up libpaper -- the build currently fails to link against
+# it.
+CONFIGURE_ARGS +=  -DHAVE_PAPER_H=0
+
+# XXX
+# Doesn't work, neither with -DCMAKE_LIBRARY_PATH=${LOCALBASE}/lib nor
+# with CMAKE_LIBRARY_PATH=${LOCALBASE}/lib in the environment.
+# CONFIGURE_ARGS +=-DXPDFWIDGET_PRINTING=true
+
+CXXFLAGS+= -DLOCALBASE=\\\"${LOCALBASE}\\\"
+
+WANTLIB=   Qt5Core Qt5Gui Qt5Widgets freetype c m png pthread \
+   ${COMPILER_LIBCXX} z
 
 NO_TEST=   Yes
 
@@ -37,13 +51,9 @@ post-install:
${INSTALL_DATA} ${WRKSRC}/doc/sample-xpdfrc \
${PREFIX}/share/examples/xpdf/xpdfrc
 # already in poppler-utils
-.for i in pdffonts pdfimages pdfinfo pdftoppm pdftops pdftotext
+.for i in pdffonts pdfimages pdfinfo pdftohtml pdftoppm pdftops pdftotext
rm ${PREFIX}/man/man1/$i.1
rm ${PREFIX}/bin/$i
 .endfor
-# forgotten in Makefile.in (there's also a pdfthtml, but it conflicts
-# with poppler-utils):
-   ${INSTALL_PROGRAM} ${WRKBUILD}/xpdf/pdftopng ${PREFIX}/bin
-   ${INSTALL_MAN} ${WRKSRC}/doc/pdftopng.1 ${PREFIX}/man/man1
 
 .include 
Index: distinfo
===
RCS file: /cvs/ports/textproc/xpdf/distinfo,v
retrieving revision 1.18
diff -u -p -r1.18 distinfo
--- distinfo8 Jun 2014 18:56:33 -   1.18
+++ distinfo23 Oct 2017 20:18:11 -
@@ -1,2 +1,2 @@
-SHA256 (xpdf-3.04.tar.gz) = ETkMdHM6vLJiqspNtocQ8T///UK/4qCGGl38kSspd+U=
-SIZE (xpdf-3.04.tar.gz) = 825519
+SHA256 (xpdf-4.00.tar.gz) = /z2SxCFm41sbpq7JtfCt/7X8BaPrldxJUFtuNE5CF

Re: FWD: Re: Update textproc/xpdf

2017-10-23 Thread Marc Espie
On Mon, Oct 23, 2017 at 06:05:08PM +0200, Alexander Bluhm wrote:
> On Sun, Oct 22, 2017 at 06:26:15PM +0200, Matthias Kilian wrote:
> > I'll try it later this evening. But I always wondered why one wants
> > to print a pdf out of a pdf *viewer* ;-)
> 
> I have always used xpdf to convert the wanted pages to postscript
> and send them with lpr to my printer.  You can even type "ssh
> myprinthost lpr" in the command field and do it remotely.
> 
> What is wrong with that workflow?  Is there a better way to print
> pages of pdf on a postscript printer?  ghostview?

Cups should be happy to do so as well... just saying



Re: FWD: Re: Update textproc/xpdf

2017-10-23 Thread Alexander Bluhm
On Sun, Oct 22, 2017 at 06:26:15PM +0200, Matthias Kilian wrote:
> I'll try it later this evening. But I always wondered why one wants
> to print a pdf out of a pdf *viewer* ;-)

I have always used xpdf to convert the wanted pages to postscript
and send them with lpr to my printer.  You can even type "ssh
myprinthost lpr" in the command field and do it remotely.

What is wrong with that workflow?  Is there a better way to print
pages of pdf on a postscript printer?  ghostview?

Does every postscript printer understand pdf natively?

bluhm



Re: Update textproc/xpdf

2017-10-22 Thread Antoine Jacoutot
> > It does spew crap to stderr that i didn't notice with previous
> > versions, but i may have missed it.  Probably such splatter is
> > to be expected with "modern" software (sigh).
> > 
> >   QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> > '/tmp/runtime-schwarze'
> 
> I'll have to ask the Qt gurus about this. Other Qt5 applications produce
> the same warning (stellarium from astro/stellarium, for example).

That's a systemd stuff (logind component I think).
IIRC on non-systemd OSes it should default to ~/.cache/...

-- 
Antoine



Re: Update textproc/xpdf

2017-10-22 Thread Matthieu Herrb
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



Re: Update textproc/xpdf

2017-10-22 Thread Stuart Henderson
On 2017/10/22 19:57, Ingo Schwarze wrote:
> 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
> 
> 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.

I'm not sure why but sysmerge -b usually leaves the xdm/xenodm files for
a later manual sysmerge run.



Re: Update textproc/xpdf

2017-10-22 Thread Rafael Sadowski
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
> 
> 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.
> 

No, unless CMakeLists.txt is lying to use or you don't need pdftopng/pdftohtml:

if (NOT PNG_FOUND)
  message(WARNING "Couldn't find libpng -- will not build pdftopng or 
pdftohtml.")
endif ()



Re: Update textproc/xpdf

2017-10-22 Thread Ingo Schwarze
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

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
+++ MakefileSun 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.



Re: FWD: Re: Update textproc/xpdf

2017-10-22 Thread Stuart Henderson
On 2017/10/22 18:26, Matthias Kilian wrote:
> Hi,
> 
> On Sun, Oct 22, 2017 at 05:03:50PM +0100, Stuart Henderson wrote:
> > It seems to have lost the ability to print. There's a build flag
> > (-DXPDFWIDGET_PRINTING=true) which might fix that, but I haven't got
> > it to build yet.
> 
> I'll try it later this evening. But I always wondered why one wants
> to print a pdf out of a pdf *viewer* ;-)

I use it when I want to print just one page of a longer pdf, there are
other ways to do that, but this is nice and easy (much simpler than looking
up the option in cups version of lpr(1) for example).

> > > I see this in my output:
> > > 
> > >   -- Found TIFF: /usr/local/lib/libtiff.so.40.1 (found version "4.0.8") 
> > > 
> > > but:
> > > 
> > >   $ pkg_info -S xpdf
> > >   Information for inst:xpdf-4.00
> > >   Signature: 
> > > xpdf-4.00,0,@ghostscript-fonts-8.11p3,@png-1.6.31,@qtbase-5.9.1p4,Qt5Core.2.1,Qt5Gui.2.1,Qt5Widgets.2.1,c++.1.0,c++abi.0.0,c.90.0,freetype.28.1,m.10.0,png.17.4,pthread.24.0,z.5.0
> > > 
> > > No tiff in there.  Any idea what is going on?
> > > 
> > > Maybe that's all harmless, but who knows, i thought i'd better mention it.
> > 
> > Something funny going on there indeed.. Possibly not helped by Qt's
> > propensity for dlopen()'ing things..
> 
> It really doesn't use libtiff by itself:
> 
> [kili@knecht:xpdf-4.00]$ find . -type f| xargs grep -i tiff 
> ./cmake-config.txt:#--- look for libtiff
> ./cmake-config.txt:find_package(TIFF)
> ./xpdf/Stream.cc:default:   // no predictor or TIFF 
> predictor
> ./xpdf/Stream.cc:  // apply TIFF (component) predictor
> ./xpdf-qt/XpdfViewer.cc:  { "TIFF", "TIFF files (*.tiff)", "TIFF" }
> ./CHANGES:Fixed a bug in end-of-stream detection with the TIFF predictor.
> ./CHANGES:Fixed a bug in the TIFF image component predictor which shows up 
> with
> ./CHANGES:The TIFF predictor code for the 1-bit-per-pixel case was broken.
> 
> xpdf-3.04 didn't use libtiff, either.

Any idea what's happening with jpeg? It's not linked either but has the
cmake check and there's code which looks like it uses it ..



Re: Update textproc/xpdf

2017-10-22 Thread Rafael Sadowski
Thanks Matthias for the diff. Comments below.

On Sun Oct 22, 2017 at 06:10:01PM +0200, Matthias Kilian wrote:
> Hi Ingo,
> 
> (cc'ing back to ports)
> 
> On Sun, Oct 22, 2017 at 12:38:09AM +0200, Ingo Schwarze wrote:
> > > As libpaper seems fairly useless to me, i guess you might want to take
> > > the second approach, disable it explicitly.
> > > 
> > > I'm now investigating how to do that...
> > 
> > Applying the patch appended at the end on top of your patch lets
> > xpdf build, package, install (with pkg_add -r), and run for me.
> 
> Thanks! I've added it to my version.
> 
> > It does spew crap to stderr that i didn't notice with previous
> > versions, but i may have missed it.  Probably such splatter is
> > to be expected with "modern" software (sigh).
> > 
> >   QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> > '/tmp/runtime-schwarze'
> 
> I'll have to ask the Qt gurus about this. Other Qt5 applications produce
> the same warning (stellarium from astro/stellarium, for example).

Yes other qt5 applications produce the same warning. On Linux
XDG_RUNTIME_DIR is set by default through pam_systemd:

https://www.freedesktop.org/software/systemd/man/pam_systemd.html

> 
> >   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).  I'm using xenodm,
> which should take care of it (/etc/xenodm/GiveConsole):
> 
> if [ -c /dev/drm0 ]; then
> chown $USER /dev/drm0
> fi
> 
> For not-so-normal setups, or when using startx(1), I'm not sure how
> to fix it in a generic way. However, I'd expect that you get the
> same error from other X11 programs using drm, too.
> 
> > Looking at the build log, this looks somewhat strange:
> > 
> >   ===>   Applying OpenBSD patch patch-xpdf_GlobalParams_cc
> >   Hmm...  Looks like a unified diff to me...
> >   The text leading up to this was:
> >   --
> >   |$OpenBSD: patch-xpdf_GlobalParams_cc,v 1.4 2015/04/06 21:05:07 ajacoutot 
> > Exp $
> >   |--- xpdf/GlobalParams.cc.orig  Wed May 28 20:50:50 2014
> >   |+++ xpdf/GlobalParams.cc   Fri May 30 14:27:13 2014
> >   --
> >   Patching file xpdf/GlobalParams.cc using Plan A...
> >   Hunk #1 succeeded at 103 (offset -17 lines).
> >   done
> > 
> > Does the "offset -17 lines" mean that the patch should be regenerated?
> > Same for patch-xpdf_XRef_cc.
> 
> I didn't include regenerated patches in my diff. The new diff contains
> regenerated patches.
> 
> > 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.
> 
> > I see this in my output:
> > 
> >   -- Found TIFF: /usr/local/lib/libtiff.so.40.1 (found version "4.0.8") 

You can save as tiff, png and jpeg (see in xpdf-qt/XpdfViewer.cc). I
would prefer it as BUILD,RUN_DEPENDS.

> > 
> > but:
> > 
> >   $ pkg_info -S xpdf
> >   Information for inst:xpdf-4.00
> >   Signature: 
> > xpdf-4.00,0,@ghostscript-fonts-8.11p3,@png-1.6.31,@qtbase-5.9.1p4,Qt5Core.2.1,Qt5Gui.2.1,Qt5Widgets.2.1,c++.1.0,c++abi.0.0,c.90.0,freetype.28.1,m.10.0,png.17.4,pthread.24.0,z.5.0
> > 
> > No tiff in there.  Any idea what is going on?
> 
> It looks like it checks for libtiff but then doesn't use it anywhere.
> 
> Here's a new diff:
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/textproc/xpdf/Makefile,v
> retrieving revision 1.89
> diff -u -p -r1.89 Makefile
> --- Makefile  26 Jul 2017 22:45:31 -  1.89
> +++ Makefile  22 Oct 2017 16:05:37 -
> @@ -2,33 +2,33 @@
>  
>  COMMENT= PDF viewer for X11
>  
> -DISTNAME=xpdf-3.04
> +DISTNAME=xpdf-4.00
>  CATEGORIES=  textproc x11
> -REVISION=2
>  
> -MASTER_SITES=ftp://ftp.foolabs.com/pub/xpdf/ \
> - http://mirror.ctan.org/support/xpdf/
> +MASTER_SITES=https://www.xpdfreader.com/dl/
>  
> -HOMEPAGE=http://www.foolabs.com/xpdf/
> +HOMEPAGE=https://www.xpdfreader.com/
>  
>  # GPLv2 only or GPLv3 only or both (at our choice)
>  PERMIT_PACKAGE_CDROM=Yes
>  
> -LIB_DEPENDS+=graphics/png x11/motif
> -USE_GMAKE=   Yes
> -CONFIGURE_STYLE=gnu
> -CONFIGURE_ARGS=  --enable-multithreaded \
> - --without-Sgm-library \
> - --without-libpaper-library
> -
> -CONFIGURE_ENV=  CPPFLAGS='-I${X11BASE}/include/freetype2 
> -I${X11BASE}/include -I${LOCALBASE}/include -DLOCALBASE="\"${LOCALBASE}\""' \
> - LDFLAGS="-L${X11BASE}/lib -L${LOCALBASE}/lib -lm -lz"
> -MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -lXm'
> +MODULES= devel/cmake \
> + X11/qt5
>

Re: FWD: Re: Update textproc/xpdf

2017-10-22 Thread Matthias Kilian
Hi,

On Sun, Oct 22, 2017 at 05:03:50PM +0100, Stuart Henderson wrote:
> It seems to have lost the ability to print. There's a build flag
> (-DXPDFWIDGET_PRINTING=true) which might fix that, but I haven't got
> it to build yet.

I'll try it later this evening. But I always wondered why one wants
to print a pdf out of a pdf *viewer* ;-)

> > I see this in my output:
> > 
> >   -- Found TIFF: /usr/local/lib/libtiff.so.40.1 (found version "4.0.8") 
> > 
> > but:
> > 
> >   $ pkg_info -S xpdf
> >   Information for inst:xpdf-4.00
> >   Signature: 
> > xpdf-4.00,0,@ghostscript-fonts-8.11p3,@png-1.6.31,@qtbase-5.9.1p4,Qt5Core.2.1,Qt5Gui.2.1,Qt5Widgets.2.1,c++.1.0,c++abi.0.0,c.90.0,freetype.28.1,m.10.0,png.17.4,pthread.24.0,z.5.0
> > 
> > No tiff in there.  Any idea what is going on?
> > 
> > Maybe that's all harmless, but who knows, i thought i'd better mention it.
> 
> Something funny going on there indeed.. Possibly not helped by Qt's
> propensity for dlopen()'ing things..

It really doesn't use libtiff by itself:

[kili@knecht:xpdf-4.00]$ find . -type f| xargs grep -i tiff 
./cmake-config.txt:#--- look for libtiff
./cmake-config.txt:find_package(TIFF)
./xpdf/Stream.cc:default:   // no predictor or TIFF 
predictor
./xpdf/Stream.cc:  // apply TIFF (component) predictor
./xpdf-qt/XpdfViewer.cc:  { "TIFF", "TIFF files (*.tiff)", "TIFF" }
./CHANGES:Fixed a bug in end-of-stream detection with the TIFF predictor.
./CHANGES:Fixed a bug in the TIFF image component predictor which shows up with
./CHANGES:The TIFF predictor code for the 1-bit-per-pixel case was broken.

xpdf-3.04 didn't use libtiff, either.

Ciao,
Kili



Re: Update textproc/xpdf

2017-10-22 Thread Matthias Kilian
Hi Ingo,

(cc'ing back to ports)

On Sun, Oct 22, 2017 at 12:38:09AM +0200, Ingo Schwarze wrote:
> > As libpaper seems fairly useless to me, i guess you might want to take
> > the second approach, disable it explicitly.
> > 
> > I'm now investigating how to do that...
> 
> Applying the patch appended at the end on top of your patch lets
> xpdf build, package, install (with pkg_add -r), and run for me.

Thanks! I've added it to my version.

> It does spew crap to stderr that i didn't notice with previous
> versions, but i may have missed it.  Probably such splatter is
> to be expected with "modern" software (sigh).
> 
>   QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> '/tmp/runtime-schwarze'

I'll have to ask the Qt gurus about this. Other Qt5 applications produce
the same warning (stellarium from astro/stellarium, for example).

>   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).  I'm using xenodm,
which should take care of it (/etc/xenodm/GiveConsole):

if [ -c /dev/drm0 ]; then
chown $USER /dev/drm0
fi

For not-so-normal setups, or when using startx(1), I'm not sure how
to fix it in a generic way. However, I'd expect that you get the
same error from other X11 programs using drm, too.

> Looking at the build log, this looks somewhat strange:
> 
>   ===>   Applying OpenBSD patch patch-xpdf_GlobalParams_cc
>   Hmm...  Looks like a unified diff to me...
>   The text leading up to this was:
>   --
>   |$OpenBSD: patch-xpdf_GlobalParams_cc,v 1.4 2015/04/06 21:05:07 ajacoutot 
> Exp $
>   |--- xpdf/GlobalParams.cc.orig  Wed May 28 20:50:50 2014
>   |+++ xpdf/GlobalParams.cc   Fri May 30 14:27:13 2014
>   --
>   Patching file xpdf/GlobalParams.cc using Plan A...
>   Hunk #1 succeeded at 103 (offset -17 lines).
>   done
> 
> Does the "offset -17 lines" mean that the patch should be regenerated?
> Same for patch-xpdf_XRef_cc.

I didn't include regenerated patches in my diff. The new diff contains
regenerated patches.

> 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.

> I see this in my output:
> 
>   -- Found TIFF: /usr/local/lib/libtiff.so.40.1 (found version "4.0.8") 
> 
> but:
> 
>   $ pkg_info -S xpdf
>   Information for inst:xpdf-4.00
>   Signature: 
> xpdf-4.00,0,@ghostscript-fonts-8.11p3,@png-1.6.31,@qtbase-5.9.1p4,Qt5Core.2.1,Qt5Gui.2.1,Qt5Widgets.2.1,c++.1.0,c++abi.0.0,c.90.0,freetype.28.1,m.10.0,png.17.4,pthread.24.0,z.5.0
> 
> No tiff in there.  Any idea what is going on?

It looks like it checks for libtiff but then doesn't use it anywhere.

Here's a new diff:

Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
retrieving revision 1.89
diff -u -p -r1.89 Makefile
--- Makefile26 Jul 2017 22:45:31 -  1.89
+++ Makefile22 Oct 2017 16:05:37 -
@@ -2,33 +2,33 @@
 
 COMMENT=   PDF viewer for X11
 
-DISTNAME=  xpdf-3.04
+DISTNAME=  xpdf-4.00
 CATEGORIES=textproc x11
-REVISION=  2
 
-MASTER_SITES=  ftp://ftp.foolabs.com/pub/xpdf/ \
-   http://mirror.ctan.org/support/xpdf/
+MASTER_SITES=  https://www.xpdfreader.com/dl/
 
-HOMEPAGE=  http://www.foolabs.com/xpdf/
+HOMEPAGE=  https://www.xpdfreader.com/
 
 # GPLv2 only or GPLv3 only or both (at our choice)
 PERMIT_PACKAGE_CDROM=  Yes
 
-LIB_DEPENDS+=  graphics/png x11/motif
-USE_GMAKE= Yes
-CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS=--enable-multithreaded \
-   --without-Sgm-library \
-   --without-libpaper-library
-
-CONFIGURE_ENV=  CPPFLAGS='-I${X11BASE}/include/freetype2 -I${X11BASE}/include 
-I${LOCALBASE}/include -DLOCALBASE="\"${LOCALBASE}\""' \
-   LDFLAGS="-L${X11BASE}/lib -L${LOCALBASE}/lib -lm -lz"
-MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -lXm'
+MODULES=   devel/cmake \
+   X11/qt5
+
+LIB_DEPENDS+=  graphics/png
 
 RUN_DEPENDS=   print/ghostscript/gnu-fonts
 
-WANTLIB=   ICE SM X11 Xext Xpm Xt freetype Xm \
-   c m png pthread ${COMPILER_LIBCXX} z
+USE_GMAKE= Yes
+
+# Don't pick up libpaper -- the build currently fails to link against
+# it.
+CONFIGURE_ARGS+=   -DHAVE_PAPER_H=0
+
+CXXFLAGS+= -DLOCALBASE=\\\"${LOCALBASE}\\\"
+
+WANTLIB=   Qt5Core Qt5Gui Qt5Widgets freetype c m png pthread \
+   ${COMPILER_LIBCXX} z
 
 NO_TEST=   Yes
 
@@ -37,13 +37,9 @@ post-install:
${INSTALL_DATA} ${WRKSRC}/doc/sample-xpdfrc \
${PREFIX}/share/examples/xpdf/xpdfr

Re: FWD: Re: Update textproc/xpdf

2017-10-22 Thread Stuart Henderson
On 2017/10/22 16:51, Ingo Schwarze wrote:
> Reposting here, maybe i should have done that in the first place
> to avoid duplicate work, sorry sthen@ and aja@...

Thanks :)

> It does spew crap to stderr that i didn't notice with previous
> versions, but i may have missed it.  Probably such splatter is
> to be expected with "modern" software (sigh).
> 
>   QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to 
> '/tmp/runtime-schwarze'
>   libGL error: failed to open drm device: Permission denied
>   libGL error: failed to load driver: i965

Sounds "normal" to me. Also has the "normal" thing that I see with
a lot of software using Qt where if I move the pointer out of a pop-up
window it warps back to the middle of the window (possibly something
to do with cwm).

It seems to have lost the ability to print. There's a build flag
(-DXPDFWIDGET_PRINTING=true) which might fix that, but I haven't got
it to build yet.

> Looking at the build log, this looks somewhat strange:
> 
>   ===>   Applying OpenBSD patch patch-xpdf_GlobalParams_cc
>   Hmm...  Looks like a unified diff to me...
>   The text leading up to this was:
>   --
>   |$OpenBSD: patch-xpdf_GlobalParams_cc,v 1.4 2015/04/06 21:05:07 ajacoutot 
> Exp $
>   |--- xpdf/GlobalParams.cc.orig  Wed May 28 20:50:50 2014
>   |+++ xpdf/GlobalParams.cc   Fri May 30 14:27:13 2014
>   --
>   Patching file xpdf/GlobalParams.cc using Plan A...
>   Hunk #1 succeeded at 103 (offset -17 lines).
>   done
> 
> Does the "offset -17 lines" mean that the patch should be regenerated?
> Same for patch-xpdf_XRef_cc.

Yes.

> 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?
> 
> I see this in my output:
> 
>   -- Found TIFF: /usr/local/lib/libtiff.so.40.1 (found version "4.0.8") 
> 
> but:
> 
>   $ pkg_info -S xpdf
>   Information for inst:xpdf-4.00
>   Signature: 
> xpdf-4.00,0,@ghostscript-fonts-8.11p3,@png-1.6.31,@qtbase-5.9.1p4,Qt5Core.2.1,Qt5Gui.2.1,Qt5Widgets.2.1,c++.1.0,c++abi.0.0,c.90.0,freetype.28.1,m.10.0,png.17.4,pthread.24.0,z.5.0
> 
> No tiff in there.  Any idea what is going on?
> 
> Maybe that's all harmless, but who knows, i thought i'd better mention it.

Something funny going on there indeed.. Possibly not helped by Qt's
propensity for dlopen()'ing things..



FWD: Re: Update textproc/xpdf

2017-10-22 Thread Ingo Schwarze
Reposting here, maybe i should have done that in the first place
to avoid duplicate work, sorry sthen@ and aja@...

- Forwarded message from Ingo Schwarze  -

From: Ingo Schwarze 
Date: Sun, 22 Oct 2017 00:38:09 +0200
To: Matthias Kilian 
Subject: Re: Update textproc/xpdf

Hi,

Ingo Schwarze wrote on Sat, Oct 21, 2017 at 11:40:15PM +0200:

> So either it has to be added as a dependency and passed to the linker,
> or it has to be disabled during cmake autoconfiguration even if it
> happens to be installed.
> 
> As libpaper seems fairly useless to me, i guess you might want to take
> the second approach, disable it explicitly.
> 
> I'm now investigating how to do that...

Applying the patch appended at the end on top of your patch lets
xpdf build, package, install (with pkg_add -r), and run for me.

It does spew crap to stderr that i didn't notice with previous
versions, but i may have missed it.  Probably such splatter is
to be expected with "modern" software (sigh).

  QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-schwarze'
  libGL error: failed to open drm device: Permission denied
  libGL error: failed to load driver: i965

Looking at the build log, this looks somewhat strange:

  ===>   Applying OpenBSD patch patch-xpdf_GlobalParams_cc
  Hmm...  Looks like a unified diff to me...
  The text leading up to this was:
  --
  |$OpenBSD: patch-xpdf_GlobalParams_cc,v 1.4 2015/04/06 21:05:07 ajacoutot Exp 
$
  |--- xpdf/GlobalParams.cc.orig  Wed May 28 20:50:50 2014
  |+++ xpdf/GlobalParams.cc   Fri May 30 14:27:13 2014
  --
  Patching file xpdf/GlobalParams.cc using Plan A...
  Hunk #1 succeeded at 103 (offset -17 lines).
  done

Does the "offset -17 lines" mean that the patch should be regenerated?
Same for patch-xpdf_XRef_cc.

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?

I see this in my output:

  -- Found TIFF: /usr/local/lib/libtiff.so.40.1 (found version "4.0.8") 

but:

  $ pkg_info -S xpdf
  Information for inst:xpdf-4.00
  Signature: 
xpdf-4.00,0,@ghostscript-fonts-8.11p3,@png-1.6.31,@qtbase-5.9.1p4,Qt5Core.2.1,Qt5Gui.2.1,Qt5Widgets.2.1,c++.1.0,c++abi.0.0,c.90.0,freetype.28.1,m.10.0,png.17.4,pthread.24.0,z.5.0

No tiff in there.  Any idea what is going on?

Maybe that's all harmless, but who knows, i thought i'd better mention it.

Apart from that, the build log looks reasonable to me.

I'll let you know if i notice any other oddities while running the
program.

Thanks again,
  Ingo


--- MakefileSun Oct 22 00:05:34 2017
+++ Makefile.is Sat Oct 21 23:56:22 2017
@@ -21,6 +21,8 @@
 
 USE_GMAKE= Yes
 
+CONFIGURE_ARGS+= -DHAVE_PAPER_H=0
+
 CXXFLAGS+= -DLOCALBASE=\\\"${LOCALBASE}\\\"
 
 WANTLIB=   Qt5Core Qt5Gui Qt5Widgets freetype c m png pthread \

- End forwarded message -



Re: Update textproc/xpdf

2017-10-22 Thread Antoine Jacoutot
On Sun, Oct 22, 2017 at 02:00:00AM +, Stuart Henderson wrote:
> On 2017/10/21 22:41, Matthias Kilian wrote:
> > Hi,
> > 
> > Here's an update to xpdf-4.00.
> > 
> > Now uses Qt instead of Motif :-(
> > 
> > Tests and comments are welcome.
> 
> I see some offsets in the patches, is that expected?
> 
> Build fails on my workstation:
> 
> xpdf/CMakeFiles/xpdf_objs.dir/GlobalParams.cc.o: In function 
> `GlobalParams::GlobalParams(char const*)':
> /usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc04): 
> undefined reference to `paperinit'
> /usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc09): 
> undefined reference to `systempapername'
> /usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc16): 
> undefined reference to `paperinfo'
> /usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc21): 
> undefined reference to `paperpswidth'
> /usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc32): 
> undefined reference to `paperpsheight'
> /usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc6a): 
> undefined reference to `paperdone'

Looks like it picked up print/libpaper


> 
> cmake output looks like this:
> 
> ===>  Configuring for xpdf-4.00
> -- The C compiler identification is Clang 5.0.0
> -- The CXX compiler identification is Clang 5.0.0
> -- Check for working C compiler: /usr/obj/ports/xpdf-4.00/bin/cc
> -- Check for working C compiler: /usr/obj/ports/xpdf-4.00/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/obj/ports/xpdf-4.00/bin/c++
> -- Check for working CXX compiler: /usr/obj/ports/xpdf-4.00/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Looking for mkstemp
> -- Looking for mkstemp - found
> -- Looking for mkstemps
> -- Looking for mkstemps - found
> -- Looking for popen
> -- Looking for popen - found
> -- Performing Test HAVE_STD_SORT
> -- Performing Test HAVE_STD_SORT - Success
> -- Looking for fseeko
> -- Looking for fseeko - found
> -- Looking for fseek64
> -- Looking for fseek64 - not found
> -- Looking for _fseeki64
> -- Looking for _fseeki64 - not found
> -- Found FreeType (old-style includes): /usr/X11R6/lib/libfreetype.so.28.1
> -- Found ZLIB: /usr/lib/libz.so.5.0 (found version "1.2.3") 
> -- Found PNG: /usr/local/lib/libpng.so.17.5 (found version "1.6.32") 
> -- Found JPEG: /usr/local/lib/libjpeg.so.68.1  
> -- Found TIFF: /usr/local/lib/libtiff.so.40.1 (found version "4.0.8") 
> -- lcms2 not found
> -- Qt5 found
> CMake Deprecation Warning at cmake-config.txt:263 (cmake_policy):
>   The OLD behavior for policy CMP0020 will be removed from a future version
>   of CMake.
> 
>   The cmake-policies(7) manual explains that the OLD behaviors of all
>   policies are deprecated and that a policy should be set to OLD only under
>   specific short-term circumstances.  Projects should be ported to the NEW
>   behavior and not rely on setting a policy to OLD.
> Call Stack (most recent call first):
>   CMakeLists.txt:15 (include)
> 
> 
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Looking for pthread_create
> -- Looking for pthread_create - not found
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Found Threads: TRUE  
> CMake Deprecation Warning at xpdf-qt/CMakeLists.txt:27 (cmake_policy):
>   The OLD behavior for policy CMP0020 will be removed from a future version
>   of CMake.
> 
>   The cmake-policies(7) manual explains that the OLD behaviors of all
>   policies are deprecated and that a policy should be set to OLD only under
>   specific short-term circumstances.  Projects should be ported to the NEW
>   behavior and not rely on setting a policy to OLD.
> 
> 
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /usr/obj/ports/xpdf-4.00/build-amd64
> 

-- 
Antoine



Re: Update textproc/xpdf

2017-10-21 Thread Stuart Henderson
On 2017/10/21 22:41, Matthias Kilian wrote:
> Hi,
> 
> Here's an update to xpdf-4.00.
> 
> Now uses Qt instead of Motif :-(
> 
> Tests and comments are welcome.

I see some offsets in the patches, is that expected?

Build fails on my workstation:

xpdf/CMakeFiles/xpdf_objs.dir/GlobalParams.cc.o: In function 
`GlobalParams::GlobalParams(char const*)':
/usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc04): 
undefined reference to `paperinit'
/usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc09): 
undefined reference to `systempapername'
/usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc16): 
undefined reference to `paperinfo'
/usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc21): 
undefined reference to `paperpswidth'
/usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc32): 
undefined reference to `paperpsheight'
/usr/obj/ports/xpdf-4.00/xpdf-4.00/xpdf/GlobalParams.cc:(.text+0xc6a): 
undefined reference to `paperdone'

cmake output looks like this:

===>  Configuring for xpdf-4.00
-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- Check for working C compiler: /usr/obj/ports/xpdf-4.00/bin/cc
-- Check for working C compiler: /usr/obj/ports/xpdf-4.00/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/obj/ports/xpdf-4.00/bin/c++
-- Check for working CXX compiler: /usr/obj/ports/xpdf-4.00/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for mkstemp
-- Looking for mkstemp - found
-- Looking for mkstemps
-- Looking for mkstemps - found
-- Looking for popen
-- Looking for popen - found
-- Performing Test HAVE_STD_SORT
-- Performing Test HAVE_STD_SORT - Success
-- Looking for fseeko
-- Looking for fseeko - found
-- Looking for fseek64
-- Looking for fseek64 - not found
-- Looking for _fseeki64
-- Looking for _fseeki64 - not found
-- Found FreeType (old-style includes): /usr/X11R6/lib/libfreetype.so.28.1
-- Found ZLIB: /usr/lib/libz.so.5.0 (found version "1.2.3") 
-- Found PNG: /usr/local/lib/libpng.so.17.5 (found version "1.6.32") 
-- Found JPEG: /usr/local/lib/libjpeg.so.68.1  
-- Found TIFF: /usr/local/lib/libtiff.so.40.1 (found version "4.0.8") 
-- lcms2 not found
-- Qt5 found
CMake Deprecation Warning at cmake-config.txt:263 (cmake_policy):
  The OLD behavior for policy CMP0020 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  CMakeLists.txt:15 (include)


-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
CMake Deprecation Warning at xpdf-qt/CMakeLists.txt:27 (cmake_policy):
  The OLD behavior for policy CMP0020 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


-- Configuring done
-- Generating done
-- Build files have been written to: /usr/obj/ports/xpdf-4.00/build-amd64



Re: update textproc/xpdf

2014-06-07 Thread Fred

On 06/07/14 22:38, Matthias Kilian wrote:

On Fri, May 30, 2014 at 04:37:58PM +0200, Matthias Kilian wrote:

Update to xpdf-3.04.

[...]

Tests, comments and oks are welcome.


Are only Patrick Keshishian and me using this?



Yes - I'd forgotten to test - it's working fine for me on amd64.

Cheers

Fred



Re: update textproc/xpdf

2014-06-07 Thread Matthias Kilian
On Fri, May 30, 2014 at 04:37:58PM +0200, Matthias Kilian wrote:
> Update to xpdf-3.04.
[...]
> Tests, comments and oks are welcome.

Are only Patrick Keshishian and me using this?

> Index: Makefile
> ===
> RCS file: /cvs/ports/textproc/xpdf/Makefile,v
> retrieving revision 1.83
> diff -u -p -r1.83 Makefile
> --- Makefile  11 Mar 2013 11:42:47 -  1.83
> +++ Makefile  30 May 2014 14:06:49 -
> @@ -2,12 +2,10 @@
>  
>  COMMENT= PDF viewer for X11
>  
> -DISTNAME=xpdf-3.03
> -REVISION=0
> +DISTNAME=xpdf-3.04
>  CATEGORIES=  textproc x11
>  
>  MASTER_SITES=ftp://ftp.foolabs.com/pub/xpdf/ \
> - ftp://gd.tuwien.ac.at/publishing/xpdf/ \
>   http://mirror.ctan.org/support/xpdf/
>  
>  HOMEPAGE=http://www.foolabs.com/xpdf/
> @@ -15,7 +13,7 @@ HOMEPAGE=   http://www.foolabs.com/xpdf/
>  # GPLv2 only or GPLv3 only or both (at our choice)
>  PERMIT_PACKAGE_CDROM=Yes
>  
> -LIB_DEPENDS+=x11/openmotif
> +LIB_DEPENDS+=graphics/png x11/openmotif
>  USE_GMAKE=   Yes
>  CONFIGURE_STYLE=gnu
>  CONFIGURE_ARGS=  --enable-multithreaded \
> @@ -29,7 +27,7 @@ MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -
>  RUN_DEPENDS= print/ghostscript/gnu-fonts
>  
>  WANTLIB= ICE SM X11 Xext Xpm Xt freetype Xm \
> - c m pthread stdc++ z
> + c m png pthread stdc++ z
>  
>  NO_TEST= Yes
>  
> @@ -42,5 +40,9 @@ post-install:
>   rm ${PREFIX}/man/man1/$i.1
>   rm ${PREFIX}/bin/$i
>  .endfor
> +# forgotten in Makefile.in (there's also a pdfthtml, but it conflicts
> +# with poppler-utils):
> + ${INSTALL_PROGRAM} ${WRKBUILD}/xpdf/pdftopng ${PREFIX}/bin
> + ${INSTALL_MAN} ${WRKSRC}/doc/pdftopng.1 ${PREFIX}/man/man1
>  
>  .include 
> Index: distinfo
> ===
> RCS file: /cvs/ports/textproc/xpdf/distinfo,v
> retrieving revision 1.17
> diff -u -p -r1.17 distinfo
> --- distinfo  1 Oct 2011 19:46:35 -   1.17
> +++ distinfo  30 May 2014 13:14:12 -
> @@ -1,5 +1,2 @@
> -MD5 (xpdf-3.03.tar.gz) = r3X3cr7g5a5KgR/50D6sWg==
> -RMD160 (xpdf-3.03.tar.gz) = 7xM2wYkCb7Ds0Wnis3taWqIuBL4=
> -SHA1 (xpdf-3.03.tar.gz) = SZQj6KeV4O/XbKeYI5600NUv4kg=
> -SHA256 (xpdf-3.03.tar.gz) = As9j2PYybtpkQJbND5aeFYhwKthyIsHpOIqTwnD7zso=
> -SIZE (xpdf-3.03.tar.gz) = 795537
> +SHA256 (xpdf-3.04.tar.gz) = ETkMdHM6vLJiqspNtocQ8T///UK/4qCGGl38kSspd+U=
> +SIZE (xpdf-3.04.tar.gz) = 825519
> Index: patches/patch-doc_sample-xpdfrc
> ===
> RCS file: /cvs/ports/textproc/xpdf/patches/patch-doc_sample-xpdfrc,v
> retrieving revision 1.4
> diff -u -p -r1.4 patch-doc_sample-xpdfrc
> --- patches/patch-doc_sample-xpdfrc   1 Oct 2011 19:46:35 -   1.4
> +++ patches/patch-doc_sample-xpdfrc   30 May 2014 13:14:12 -
> @@ -1,6 +1,6 @@
>  $OpenBSD: patch-doc_sample-xpdfrc,v 1.4 2011/10/01 19:46:35 kili Exp $
>  doc/sample-xpdfrc.orig   Mon Aug 15 23:08:53 2011
> -+++ doc/sample-xpdfrcThu Aug 18 21:10:22 2011
> +--- doc/sample-xpdfrc.orig   Wed May 28 20:50:50 2014
>  doc/sample-xpdfrcFri May 30 14:26:13 2014
>  @@ -56,7 +56,7 @@
>   
>   # Set the default PostScript file or command.
> @@ -10,7 +10,7 @@ $OpenBSD: patch-doc_sample-xpdfrc,v 1.4 
>   
>   # Set the default PostScript paper size -- this can be letter, legal,
>   # A4, or A3.  You can also specify a paper size as width and height
> -@@ -88,5 +88,5 @@
> +@@ -87,5 +87,5 @@
>   # Set the command used to run a web browser when a URL hyperlink is
>   # clicked.
>   
> Index: patches/patch-splash_Makefile_in
> ===
> RCS file: /cvs/ports/textproc/xpdf/patches/patch-splash_Makefile_in,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-splash_Makefile_in
> --- patches/patch-splash_Makefile_in  25 Jan 2004 06:02:40 -  1.1
> +++ patches/patch-splash_Makefile_in  30 May 2014 13:14:12 -
> @@ -1,12 +1,12 @@
>  $OpenBSD: patch-splash_Makefile_in,v 1.1 2004/01/25 06:02:40 brad Exp $
>  splash/Makefile.in.orig  2004-01-24 23:49:23.0 -0500
> -+++ splash/Makefile.in   2004-01-24 23:49:34.0 -0500
> +--- splash/Makefile.in.orig  Wed May 28 20:50:50 2014
>  splash/Makefile.in   Fri May 30 14:29:41 2014
>  @@ -16,7 +16,7 @@ GOOLIBDIR = ../goo
>   FOFISRCDIR = $(srcdir)/../fofi
>   FOFILIBDIR = ../fofi
>   
> --CXXFLAGS = @CXXFLAGS@ @DEFS@ -I.. -I$(GOOSRCDIR) -I$(FOFISRCDIR) 
> -I$(srcdir) @t1_CFLAGS@ @freetype2_CFLAGS@
> -+CXXFLAGS = @CPPFLAGS@ @CXXFLAGS@ @DEFS@ -I.. -I$(GOOSRCDIR) -I$(FOFISRCDIR) 
> -I$(srcdir) @t1_CFLAGS@ @freetype2_CFLAGS@
> +-CXXFLAGS = @CXXFLAGS@ @DEFS@ -I.. -I$(srcdir)/.. -I$(GOOSRCDIR) 
> -I$(FOFISRCDIR) -I$(srcdir) @freetype2_CFLAGS@
> ++CXXFLAGS = @CPPFLAGS@ @CXXFLAGS@ @DEFS@ -I.. -I$(srcdir)/.. -I$(GOOSRCDIR) 
> -I$(FOFISRCDIR) -I$(srcdir) @freetype2_CFLAGS@
>   
>   CXX

Re: update textproc/xpdf

2014-05-30 Thread Matthias Kilian
On Fri, May 30, 2014 at 10:26:50AM -0700, patrick keshishian wrote:
> > The fix from miod@ (dates back to 2009) shouldn't be necessary any
> > longer, but to be safe I prefer to keep some asserts around for a
> > while.
> 
> Are there test-cases which can be shared?

Miod mentioned this one, but the domain no longer resolves:

http://www.tadpole.com/upload/specifications/Sparcle_DataSheet.pdf

I found it today here:

http://www.portableunix.com/datasheets/Sparcle_DataSheet.pdf

But I'm not sure wether it's *exactly* the same document (and I
can't find the old one on my disks).

I tested today with an unpatched version of xpdf-3.03, and it did
*not* crash. But one bug happened back in 2009 (xpdf-3.02pl3) and
was fixed by this commit:

http://marc.info/?l=openbsd-ports-cvs&m=124386213328887&w=2

There was another fix added later (right after an update to
xpdf-3.02pl5):

http://marc.info/?l=openbsd-ports-cvs&m=129145958711529&w=2

The original mail to ports:

http://marc.info/?l=openbsd-ports&m=124386213428901&w=2


Ciao,
Kili



Re: update textproc/xpdf

2014-05-30 Thread patrick keshishian
On 5/30/14, Matthias Kilian  wrote:
> Update to xpdf-3.04.
>
> See http://www.foolabs.com/xpdf/CHANGES for a full list of changes.
>
> Tested with a couple of (broken and evil) pdf documents on amd64.
>
> The fix from miod@ (dates back to 2009) shouldn't be necessary any
> longer, but to be safe I prefer to keep some asserts around for a
> while.

Are there test-cases which can be shared?

> I added pdftopng(1) but not pdftohtml(1), because poppler-utils
> already contains a program with this name. No idea which one is
> more useful.
>
> Tests, comments and oks are welcome.

Only tested a few minutes on amd64, but it does open the
postgresql-9.3-US.pdf much(!) quicker than previous version.

Thanks for the quick update to the port.

--patrick


> Ciao,
>   Kili
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/textproc/xpdf/Makefile,v
> retrieving revision 1.83
> diff -u -p -r1.83 Makefile
> --- Makefile  11 Mar 2013 11:42:47 -  1.83
> +++ Makefile  30 May 2014 14:06:49 -
> @@ -2,12 +2,10 @@
>
>  COMMENT= PDF viewer for X11
>
> -DISTNAME=xpdf-3.03
> -REVISION=0
> +DISTNAME=xpdf-3.04
>  CATEGORIES=  textproc x11
>
>  MASTER_SITES=ftp://ftp.foolabs.com/pub/xpdf/ \
> - ftp://gd.tuwien.ac.at/publishing/xpdf/ \
>   http://mirror.ctan.org/support/xpdf/
>
>  HOMEPAGE=http://www.foolabs.com/xpdf/
> @@ -15,7 +13,7 @@ HOMEPAGE=   http://www.foolabs.com/xpdf/
>  # GPLv2 only or GPLv3 only or both (at our choice)
>  PERMIT_PACKAGE_CDROM=Yes
>
> -LIB_DEPENDS+=x11/openmotif
> +LIB_DEPENDS+=graphics/png x11/openmotif
>  USE_GMAKE=   Yes
>  CONFIGURE_STYLE=gnu
>  CONFIGURE_ARGS=  --enable-multithreaded \
> @@ -29,7 +27,7 @@ MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -
>  RUN_DEPENDS= print/ghostscript/gnu-fonts
>
>  WANTLIB= ICE SM X11 Xext Xpm Xt freetype Xm \
> - c m pthread stdc++ z
> + c m png pthread stdc++ z
>
>  NO_TEST= Yes
>
> @@ -42,5 +40,9 @@ post-install:
>   rm ${PREFIX}/man/man1/$i.1
>   rm ${PREFIX}/bin/$i
>  .endfor
> +# forgotten in Makefile.in (there's also a pdfthtml, but it conflicts
> +# with poppler-utils):
> + ${INSTALL_PROGRAM} ${WRKBUILD}/xpdf/pdftopng ${PREFIX}/bin
> + ${INSTALL_MAN} ${WRKSRC}/doc/pdftopng.1 ${PREFIX}/man/man1
>
>  .include 
> Index: distinfo
> ===
> RCS file: /cvs/ports/textproc/xpdf/distinfo,v
> retrieving revision 1.17
> diff -u -p -r1.17 distinfo
> --- distinfo  1 Oct 2011 19:46:35 -   1.17
> +++ distinfo  30 May 2014 13:14:12 -
> @@ -1,5 +1,2 @@
> -MD5 (xpdf-3.03.tar.gz) = r3X3cr7g5a5KgR/50D6sWg==
> -RMD160 (xpdf-3.03.tar.gz) = 7xM2wYkCb7Ds0Wnis3taWqIuBL4=
> -SHA1 (xpdf-3.03.tar.gz) = SZQj6KeV4O/XbKeYI5600NUv4kg=
> -SHA256 (xpdf-3.03.tar.gz) = As9j2PYybtpkQJbND5aeFYhwKthyIsHpOIqTwnD7zso=
> -SIZE (xpdf-3.03.tar.gz) = 795537
> +SHA256 (xpdf-3.04.tar.gz) = ETkMdHM6vLJiqspNtocQ8T///UK/4qCGGl38kSspd+U=
> +SIZE (xpdf-3.04.tar.gz) = 825519
> Index: patches/patch-doc_sample-xpdfrc
> ===
> RCS file: /cvs/ports/textproc/xpdf/patches/patch-doc_sample-xpdfrc,v
> retrieving revision 1.4
> diff -u -p -r1.4 patch-doc_sample-xpdfrc
> --- patches/patch-doc_sample-xpdfrc   1 Oct 2011 19:46:35 -   1.4
> +++ patches/patch-doc_sample-xpdfrc   30 May 2014 13:14:12 -
> @@ -1,6 +1,6 @@
>  $OpenBSD: patch-doc_sample-xpdfrc,v 1.4 2011/10/01 19:46:35 kili Exp $
>  doc/sample-xpdfrc.orig   Mon Aug 15 23:08:53 2011
> -+++ doc/sample-xpdfrcThu Aug 18 21:10:22 2011
> +--- doc/sample-xpdfrc.orig   Wed May 28 20:50:50 2014
>  doc/sample-xpdfrcFri May 30 14:26:13 2014
>  @@ -56,7 +56,7 @@
>
>   # Set the default PostScript file or command.
> @@ -10,7 +10,7 @@ $OpenBSD: patch-doc_sample-xpdfrc,v 1.4
>
>   # Set the default PostScript paper size -- this can be letter, legal,
>   # A4, or A3.  You can also specify a paper size as width and height
> -@@ -88,5 +88,5 @@
> +@@ -87,5 +87,5 @@
>   # Set the command used to run a web browser when a URL hyperlink is
>   # clicked.
>
> Index: patches/patch-splash_Makefile_in
> ===
> RCS file: /cvs/ports/textproc/xpdf/patches/patch-splash_Makefile_in,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-splash_Makefile_in
> --- patches/patch-splash_Makefile_in  25 Jan 2004 06:02:40 -  1.1
> +++ patches/patch-splash_Makefile_in  30 May 2014 13:14:12 -
> @@ -1,12 +1,12 @@
>  $OpenBSD: patch-splash_Makefile_in,v 1.1 2004/01/25 06:02:40 brad Exp $
>  splash/Makefile.in.orig  2004-01-24 23:49:23.0 -0500
> -+++ splash/Makefile.in   2004-01-24 23:49:34.0 -0500
> +--- splash/Makefile.in.orig  Wed May 28 20:50:50 2014
>  splash/Makefile.in   Fri May 30 14:29:41 2014
>  @@ -16,7 +16,7 @@ GOOLIBDIR = ../g

Re: update textproc/xpdf

2011-09-12 Thread patrick keshishian
On Mon, Sep 12, 2011 at 11:10 AM, Matthias Kilian
 wrote:
> On Sun, Sep 11, 2011 at 08:19:55PM -0700, patrick keshishian wrote:
>> Hmm... I am trying to build xpdf but looks like
>> patches/patch-splash_SplashXPathScanner_cc does not apply correctly.
>
> It has been removed. You forgot to run patch(1) with -E.

I did run with -E. The problem was something more subtle and on my side.

the port is working great here on amd64 btw.

Thanks,
--patrick



Re: update textproc/xpdf

2011-09-12 Thread Matthias Kilian
On Sun, Sep 11, 2011 at 08:19:55PM -0700, patrick keshishian wrote:
> Hmm... I am trying to build xpdf but looks like
> patches/patch-splash_SplashXPathScanner_cc does not apply correctly.

It has been removed. You forgot to run patch(1) with -E.

Ciao,
Kili



Re: update textproc/xpdf

2011-09-11 Thread patrick keshishian
On Sun, Sep 11, 2011 at 8:19 PM, patrick keshishian  wrote:
> On Thu, Sep 8, 2011 at 2:59 PM, Matthias Kilian  
> wrote:
>> On Tue, Sep 06, 2011 at 07:39:53PM -0500, Amit Kulkarni wrote:
>>> I checked this out... working fine on amd64. everything okay.
>>
>> Thanks for testing. I'll commit it in two weeks if nobody gives any
>> negative report.
>
> Hmm... I am trying to build xpdf but looks like
> patches/patch-splash_SplashXPathScanner_cc does not apply correctly.
>
>
> ===>  Extracting for xpdf-3.03
> ===>  Patching for xpdf-3.03
> ===>   Ignoring patchfile patch-Makefile_in.orig
> ===>   Ignoring patchfile patch-doc_sample-xpdfrc.orig
> 2 out of 3 hunks failed--saving rejects to splash/SplashXPathScanner.cc.rej
> ***>   patch-splash_SplashXPathScanner_cc did not apply cleanly
> ===>   Ignoring patchfile patch-splash_SplashXPathScanner_cc.orig
> ===>   Ignoring patchfile patch-splash_SplashXPathScanner_cc.rej
> ===>   Ignoring patchfile patch-splash_SplashXPath_cc.orig
> ===>   Ignoring empty patchfile patch-xpdf_Catalog_cc
> ===>   Ignoring patchfile patch-xpdf_Catalog_cc.orig
> ===>   Ignoring patchfile patch-xpdf_GlobalParams_cc.orig
> ===>   Ignoring empty patchfile patch-xpdf_Object_h
> ===>   Ignoring patchfile patch-xpdf_Object_h.orig
> ===>   Ignoring empty patchfile patch-xpdf_SplashOutputDev_cc
> ===>   Ignoring patchfile patch-xpdf_SplashOutputDev_cc.orig
> ===>   Ignoring empty patchfile patch-xpdf_Stream_cc
> ===>   Ignoring patchfile patch-xpdf_Stream_cc.orig
> ===>   Ignoring patchfile patch-xpdf_XRef_cc.orig
> *** Error code 1



hmm... applying Matthias's patch I see this:

Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: patches/patch-splash_SplashXPathScanner_cc
|===
|RCS file: patches/patch-splash_SplashXPathScanner_cc
|diff -N patches/patch-splash_SplashXPathScanner_cc
|--- patches/patch-splash_SplashXPathScanner_cc 3 Mar 2011 21:22:13 -
1.3
|+++ /dev/null  1 Jan 1970 00:00:00 -
--
Patching file patches/patch-splash_SplashXPathScanner_cc using Plan A...
Empty context always matches.
Hunk #1 failed at 0.
1 out of 1 hunks failed--saving rejects to patches/patch-splash_SplashXPathScann


Manually removing this patch file, make install is continuing along just fine.

--patrick



Re: update textproc/xpdf

2011-09-11 Thread patrick keshishian
On Thu, Sep 8, 2011 at 2:59 PM, Matthias Kilian  wrote:
> On Tue, Sep 06, 2011 at 07:39:53PM -0500, Amit Kulkarni wrote:
>> I checked this out... working fine on amd64. everything okay.
>
> Thanks for testing. I'll commit it in two weeks if nobody gives any
> negative report.

Hmm... I am trying to build xpdf but looks like
patches/patch-splash_SplashXPathScanner_cc does not apply correctly.


===>  Extracting for xpdf-3.03
===>  Patching for xpdf-3.03
===>   Ignoring patchfile patch-Makefile_in.orig
===>   Ignoring patchfile patch-doc_sample-xpdfrc.orig
2 out of 3 hunks failed--saving rejects to splash/SplashXPathScanner.cc.rej
***>   patch-splash_SplashXPathScanner_cc did not apply cleanly
===>   Ignoring patchfile patch-splash_SplashXPathScanner_cc.orig
===>   Ignoring patchfile patch-splash_SplashXPathScanner_cc.rej
===>   Ignoring patchfile patch-splash_SplashXPath_cc.orig
===>   Ignoring empty patchfile patch-xpdf_Catalog_cc
===>   Ignoring patchfile patch-xpdf_Catalog_cc.orig
===>   Ignoring patchfile patch-xpdf_GlobalParams_cc.orig
===>   Ignoring empty patchfile patch-xpdf_Object_h
===>   Ignoring patchfile patch-xpdf_Object_h.orig
===>   Ignoring empty patchfile patch-xpdf_SplashOutputDev_cc
===>   Ignoring patchfile patch-xpdf_SplashOutputDev_cc.orig
===>   Ignoring empty patchfile patch-xpdf_Stream_cc
===>   Ignoring patchfile patch-xpdf_Stream_cc.orig
===>   Ignoring patchfile patch-xpdf_XRef_cc.orig
*** Error code 1



Re: update textproc/xpdf

2011-09-08 Thread Matthias Kilian
On Tue, Sep 06, 2011 at 07:39:53PM -0500, Amit Kulkarni wrote:
> I checked this out... working fine on amd64. everything okay.

Thanks for testing. I'll commit it in two weeks if nobody gives any
negative report.

Ciao,
Kili



Re: update textproc/xpdf

2011-09-06 Thread Amit Kulkarni
I checked this out... working fine on amd64. everything okay.

thanks

On Tue, Sep 6, 2011 at 2:49 PM, Matthias Kilian  wrote:
> Anyone? Only edd@ reported back until now.
>
> On Sun, Aug 21, 2011 at 08:51:20PM +0200, Matthias Kilian wrote:
>> I removed PKGNAME-main by accident. Please use this diff instead
>> of the one i sent last friday.
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/textproc/xpdf/Makefile,v
>> retrieving revision 1.79
>> diff -u -p -r1.79 Makefile
>> --- Makefile  10 Apr 2011 18:02:55 -      1.79
>> +++ Makefile  21 Aug 2011 11:24:35 -
>> @@ -3,25 +3,20 @@
>>  COMMENT-main=        PDF viewer for X11
>>  COMMENT-utils=       PDF conversion tools
>>
>> -DISTNAME=    xpdf-3.02
>> -PKGNAME-main=        xpdf-3.02.5
>> -REVISION-main=       2
>> -PKGNAME-utils=       xpdf-utils-3.02.5
>> +DISTNAME=    xpdf-3.03
>> +PKGNAME-main=        xpdf-3.03
>> +PKGNAME-utils=       xpdf-utils-3.03
>>  CATEGORIES=  textproc x11
>>
>>  MASTER_SITES=        ftp://ftp.foolabs.com/pub/xpdf/ \
>>               ftp://gd.tuwien.ac.at/publishing/xpdf/ \
>> -             ftp://tug.org/xpdf/
>> -PATCHFILES=  xpdf-3.02pl1.patch xpdf-3.02pl2.patch \
>> -             xpdf-3.02pl3.patch xpdf-3.02pl4.patch \
>> -             xpdf-3.02pl5.patch
>> -PATCH_DIST_STRIP=-p1
>> +             http://mirror.ctan.org/support/xpdf/
>>
>>  HOMEPAGE=    http://www.foolabs.com/xpdf/
>>
>>  MULTI_PACKAGES=      -main -utils
>>
>> -# GPLv2
>> +# GPLv2 only or GPLv3 only or both (at our choice)
>>  PERMIT_PACKAGE_CDROM=        Yes
>>  PERMIT_PACKAGE_FTP=  Yes
>>  PERMIT_DISTFILES_CDROM=      Yes
>> @@ -39,14 +34,13 @@ CONFIGURE_ENV=  CPPFLAGS='-I${X11BASE}/i
>>  MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -lXm'
>>
>>  LIB_DEPENDS-utils=
>> -LIB_DEPENDS-main=    devel/t1lib ${LIB_DEPENDS}
>>  RUN_DEPENDS-utils=   print/ghostscript/gnu-fonts
>>  RUN_DEPENDS-main=    ${RUN_DEPENDS-utils} \
>>                       ${FULLPKGNAME-utils}:textproc/xpdf,-utils
>>
>>  WANTLIB-utils=               c m pthread stdc++ z
>>  WANTLIB-main=                ${WANTLIB} ${WANTLIB-utils} ICE SM X11 Xext 
>> Xpm Xt \
>> -                     freetype t1>=3 Xm
>> +                     freetype Xm
>>
>>  NO_REGRESS=  Yes
>>
>> Index: distinfo
>> ===
>> RCS file: /cvs/ports/textproc/xpdf/distinfo,v
>> retrieving revision 1.16
>> diff -u -p -r1.16 distinfo
>> --- distinfo  4 Dec 2010 10:44:31 -       1.16
>> +++ distinfo  21 Aug 2011 11:24:35 -
>> @@ -1,30 +1,5 @@
>> -MD5 (xpdf-3.02.tar.gz) = WZ3EzGWgfuhoz5KmZ6kT0g==
>> -MD5 (xpdf-3.02pl1.patch) = h3EYeG3+J9G3qlpnWcxuRQ==
>> -MD5 (xpdf-3.02pl2.patch) = OlyxZa5meB4LIeYhmuBnlQ==
>> -MD5 (xpdf-3.02pl3.patch) = WBlj7eD7VxXhpp8BtbjOYw==
>> -MD5 (xpdf-3.02pl4.patch) = cLdScWeY3TQaS/iQ319v3A==
>> -MD5 (xpdf-3.02pl5.patch) = UEkCyl6dZsZ+7QNjbsaxYw==
>> -RMD160 (xpdf-3.02.tar.gz) = 6QDLhnC4xDC+qkWJX7R0QRyxlY0=
>> -RMD160 (xpdf-3.02pl1.patch) = XDEPlnYPcunBBisAxXwu0DWsZ1c=
>> -RMD160 (xpdf-3.02pl2.patch) = ACTj0gPWngc6RYVwzsVnniYK0gQ=
>> -RMD160 (xpdf-3.02pl3.patch) = hZ7DEx08RSamB17mOcXrcEGUIRs=
>> -RMD160 (xpdf-3.02pl4.patch) = QoBl6Mljm2eZcFsha+YD9S77iiI=
>> -RMD160 (xpdf-3.02pl5.patch) = 9QKnxTEek18+Sl/Vt3C0TmjAmno=
>> -SHA1 (xpdf-3.02.tar.gz) = +ZQGmIQMioBFZ36L5oq4WAkD4go=
>> -SHA1 (xpdf-3.02pl1.patch) = zTyO1uH9NgYJi4XVzIp9GqMFJm0=
>> -SHA1 (xpdf-3.02pl2.patch) = 0ILr4NNsrQwEYDlQIW9cUt4cJZM=
>> -SHA1 (xpdf-3.02pl3.patch) = I/SWgEgCo9pTDx0Lq4lLrj6Tj8I=
>> -SHA1 (xpdf-3.02pl4.patch) = GqMIehx4gohK59OlAiQKVazKZf0=
>> -SHA1 (xpdf-3.02pl5.patch) = Cs1J5zu6R/oex7R5648TmKM+q7w=
>> -SHA256 (xpdf-3.02.tar.gz) = szp9VvRUwzGuUJlvmJ6GyRZuV6+Xt03ijN3z1RrBHwA=
>> -SHA256 (xpdf-3.02pl1.patch) = WPYTsAtBSoaqd2t2/NiZu0FeTuTtwhhMinxO0QBNu/M=
>> -SHA256 (xpdf-3.02pl2.patch) = 0cHYh7C4pSg/BPgl5E8IXy6S2ve1GIiazxvInqB+2dk=
>> -SHA256 (xpdf-3.02pl3.patch) = WUzo+9I7/ynqzd+uNTPGPH6GtKJPfUXkTxk309GeU0s=
>> -SHA256 (xpdf-3.02pl4.patch) = sIRDlUETGHZu91CYd4f3eCMelLwV8E9/fRb0H9WBiLA=
>> -SHA256 (xpdf-3.02pl5.patch) = kvyzCDoZ43swlpeAQ/rqjHd+eq7KODS4Mtmbwq8xcbo=
>> -SIZE (xpdf-3.02.tar.gz) = 674912
>> -SIZE (xpdf-3.02pl1.patch) = 1050
>> -SIZE (xpdf-3.02pl2.patch) = 20843
>> -SIZE (xpdf-3.02pl3.patch) = 30727
>> -SIZE (xpdf-3.02pl4.patch) = 6982
>> -SIZE (xpdf-3.02pl5.patch) = 1065
>> +MD5 (xpdf-3.03.tar.gz) = r3X3cr7g5a5KgR/50D6sWg==
>> +RMD160 (xpdf-3.03.tar.gz) = 7xM2wYkCb7Ds0Wnis3taWqIuBL4=
>> +SHA1 (xpdf-3.03.tar.gz) = SZQj6KeV4O/XbKeYI5600NUv4kg=
>> +SHA256 (xpdf-3.03.tar.gz) = As9j2PYybtpkQJbND5aeFYhwKthyIsHpOIqTwnD7zso=
>> +SIZE (xpdf-3.03.tar.gz) = 795537
>> Index: patches/patch-Makefile_in
>> ===
>> RCS file: /cvs/ports/textproc/xpdf/patches/patch-Makefile_in,v
>> retrieving revision 1.1
>> diff -u -p -r1.1 patch-Makefile_in
>> --- patches/patch-Makefile_in 10 Feb 2008 20:25:14 -      1.1
>> +++ patches/patch-Makefile_in 21

Re: update textproc/xpdf

2011-09-06 Thread Matthias Kilian
Anyone? Only edd@ reported back until now.

On Sun, Aug 21, 2011 at 08:51:20PM +0200, Matthias Kilian wrote:
> I removed PKGNAME-main by accident. Please use this diff instead
> of the one i sent last friday.
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/textproc/xpdf/Makefile,v
> retrieving revision 1.79
> diff -u -p -r1.79 Makefile
> --- Makefile  10 Apr 2011 18:02:55 -  1.79
> +++ Makefile  21 Aug 2011 11:24:35 -
> @@ -3,25 +3,20 @@
>  COMMENT-main=PDF viewer for X11
>  COMMENT-utils=   PDF conversion tools
>  
> -DISTNAME=xpdf-3.02
> -PKGNAME-main=xpdf-3.02.5
> -REVISION-main=   2
> -PKGNAME-utils=   xpdf-utils-3.02.5
> +DISTNAME=xpdf-3.03
> +PKGNAME-main=xpdf-3.03
> +PKGNAME-utils=   xpdf-utils-3.03
>  CATEGORIES=  textproc x11
>  
>  MASTER_SITES=ftp://ftp.foolabs.com/pub/xpdf/ \
>   ftp://gd.tuwien.ac.at/publishing/xpdf/ \
> - ftp://tug.org/xpdf/
> -PATCHFILES=  xpdf-3.02pl1.patch xpdf-3.02pl2.patch \
> - xpdf-3.02pl3.patch xpdf-3.02pl4.patch \
> - xpdf-3.02pl5.patch
> -PATCH_DIST_STRIP=-p1
> + http://mirror.ctan.org/support/xpdf/
>  
>  HOMEPAGE=http://www.foolabs.com/xpdf/
>  
>  MULTI_PACKAGES=  -main -utils
>  
> -# GPLv2
> +# GPLv2 only or GPLv3 only or both (at our choice)
>  PERMIT_PACKAGE_CDROM=Yes
>  PERMIT_PACKAGE_FTP=  Yes
>  PERMIT_DISTFILES_CDROM=  Yes
> @@ -39,14 +34,13 @@ CONFIGURE_ENV=  CPPFLAGS='-I${X11BASE}/i
>  MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -lXm'
>  
>  LIB_DEPENDS-utils=
> -LIB_DEPENDS-main=devel/t1lib ${LIB_DEPENDS}
>  RUN_DEPENDS-utils=   print/ghostscript/gnu-fonts
>  RUN_DEPENDS-main=${RUN_DEPENDS-utils} \
>   ${FULLPKGNAME-utils}:textproc/xpdf,-utils
>  
>  WANTLIB-utils=   c m pthread stdc++ z
>  WANTLIB-main=${WANTLIB} ${WANTLIB-utils} ICE SM X11 Xext Xpm 
> Xt \
> - freetype t1>=3 Xm
> + freetype Xm
>  
>  NO_REGRESS=  Yes
>  
> Index: distinfo
> ===
> RCS file: /cvs/ports/textproc/xpdf/distinfo,v
> retrieving revision 1.16
> diff -u -p -r1.16 distinfo
> --- distinfo  4 Dec 2010 10:44:31 -   1.16
> +++ distinfo  21 Aug 2011 11:24:35 -
> @@ -1,30 +1,5 @@
> -MD5 (xpdf-3.02.tar.gz) = WZ3EzGWgfuhoz5KmZ6kT0g==
> -MD5 (xpdf-3.02pl1.patch) = h3EYeG3+J9G3qlpnWcxuRQ==
> -MD5 (xpdf-3.02pl2.patch) = OlyxZa5meB4LIeYhmuBnlQ==
> -MD5 (xpdf-3.02pl3.patch) = WBlj7eD7VxXhpp8BtbjOYw==
> -MD5 (xpdf-3.02pl4.patch) = cLdScWeY3TQaS/iQ319v3A==
> -MD5 (xpdf-3.02pl5.patch) = UEkCyl6dZsZ+7QNjbsaxYw==
> -RMD160 (xpdf-3.02.tar.gz) = 6QDLhnC4xDC+qkWJX7R0QRyxlY0=
> -RMD160 (xpdf-3.02pl1.patch) = XDEPlnYPcunBBisAxXwu0DWsZ1c=
> -RMD160 (xpdf-3.02pl2.patch) = ACTj0gPWngc6RYVwzsVnniYK0gQ=
> -RMD160 (xpdf-3.02pl3.patch) = hZ7DEx08RSamB17mOcXrcEGUIRs=
> -RMD160 (xpdf-3.02pl4.patch) = QoBl6Mljm2eZcFsha+YD9S77iiI=
> -RMD160 (xpdf-3.02pl5.patch) = 9QKnxTEek18+Sl/Vt3C0TmjAmno=
> -SHA1 (xpdf-3.02.tar.gz) = +ZQGmIQMioBFZ36L5oq4WAkD4go=
> -SHA1 (xpdf-3.02pl1.patch) = zTyO1uH9NgYJi4XVzIp9GqMFJm0=
> -SHA1 (xpdf-3.02pl2.patch) = 0ILr4NNsrQwEYDlQIW9cUt4cJZM=
> -SHA1 (xpdf-3.02pl3.patch) = I/SWgEgCo9pTDx0Lq4lLrj6Tj8I=
> -SHA1 (xpdf-3.02pl4.patch) = GqMIehx4gohK59OlAiQKVazKZf0=
> -SHA1 (xpdf-3.02pl5.patch) = Cs1J5zu6R/oex7R5648TmKM+q7w=
> -SHA256 (xpdf-3.02.tar.gz) = szp9VvRUwzGuUJlvmJ6GyRZuV6+Xt03ijN3z1RrBHwA=
> -SHA256 (xpdf-3.02pl1.patch) = WPYTsAtBSoaqd2t2/NiZu0FeTuTtwhhMinxO0QBNu/M=
> -SHA256 (xpdf-3.02pl2.patch) = 0cHYh7C4pSg/BPgl5E8IXy6S2ve1GIiazxvInqB+2dk=
> -SHA256 (xpdf-3.02pl3.patch) = WUzo+9I7/ynqzd+uNTPGPH6GtKJPfUXkTxk309GeU0s=
> -SHA256 (xpdf-3.02pl4.patch) = sIRDlUETGHZu91CYd4f3eCMelLwV8E9/fRb0H9WBiLA=
> -SHA256 (xpdf-3.02pl5.patch) = kvyzCDoZ43swlpeAQ/rqjHd+eq7KODS4Mtmbwq8xcbo=
> -SIZE (xpdf-3.02.tar.gz) = 674912
> -SIZE (xpdf-3.02pl1.patch) = 1050
> -SIZE (xpdf-3.02pl2.patch) = 20843
> -SIZE (xpdf-3.02pl3.patch) = 30727
> -SIZE (xpdf-3.02pl4.patch) = 6982
> -SIZE (xpdf-3.02pl5.patch) = 1065
> +MD5 (xpdf-3.03.tar.gz) = r3X3cr7g5a5KgR/50D6sWg==
> +RMD160 (xpdf-3.03.tar.gz) = 7xM2wYkCb7Ds0Wnis3taWqIuBL4=
> +SHA1 (xpdf-3.03.tar.gz) = SZQj6KeV4O/XbKeYI5600NUv4kg=
> +SHA256 (xpdf-3.03.tar.gz) = As9j2PYybtpkQJbND5aeFYhwKthyIsHpOIqTwnD7zso=
> +SIZE (xpdf-3.03.tar.gz) = 795537
> Index: patches/patch-Makefile_in
> ===
> RCS file: /cvs/ports/textproc/xpdf/patches/patch-Makefile_in,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-Makefile_in
> --- patches/patch-Makefile_in 10 Feb 2008 20:25:14 -  1.1
> +++ patches/patch-Makefile_in 21 Aug 2011 11:24:35 -
> @@ -1,7 +1,7 @@
>  $OpenBSD: patch-Makefile_in,v 1.1 2008/02/10 20:25:14 landry Exp $
>  Makefile.in.orig Mon Nov 12 11:33:36 2007
> -+++ Makefile.in  Mon Nov 12 11:34:40 2007
> -@@ -94,

Re: update textproc/xpdf

2011-08-21 Thread Matthias Kilian
I removed PKGNAME-main by accident. Please use this diff instead
of the one i sent last friday.

Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
retrieving revision 1.79
diff -u -p -r1.79 Makefile
--- Makefile10 Apr 2011 18:02:55 -  1.79
+++ Makefile21 Aug 2011 11:24:35 -
@@ -3,25 +3,20 @@
 COMMENT-main=  PDF viewer for X11
 COMMENT-utils= PDF conversion tools
 
-DISTNAME=  xpdf-3.02
-PKGNAME-main=  xpdf-3.02.5
-REVISION-main= 2
-PKGNAME-utils= xpdf-utils-3.02.5
+DISTNAME=  xpdf-3.03
+PKGNAME-main=  xpdf-3.03
+PKGNAME-utils= xpdf-utils-3.03
 CATEGORIES=textproc x11
 
 MASTER_SITES=  ftp://ftp.foolabs.com/pub/xpdf/ \
ftp://gd.tuwien.ac.at/publishing/xpdf/ \
-   ftp://tug.org/xpdf/
-PATCHFILES=xpdf-3.02pl1.patch xpdf-3.02pl2.patch \
-   xpdf-3.02pl3.patch xpdf-3.02pl4.patch \
-   xpdf-3.02pl5.patch
-PATCH_DIST_STRIP=-p1
+   http://mirror.ctan.org/support/xpdf/
 
 HOMEPAGE=  http://www.foolabs.com/xpdf/
 
 MULTI_PACKAGES=-main -utils
 
-# GPLv2
+# GPLv2 only or GPLv3 only or both (at our choice)
 PERMIT_PACKAGE_CDROM=  Yes
 PERMIT_PACKAGE_FTP=Yes
 PERMIT_DISTFILES_CDROM=Yes
@@ -39,14 +34,13 @@ CONFIGURE_ENV=  CPPFLAGS='-I${X11BASE}/i
 MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -lXm'
 
 LIB_DEPENDS-utils=
-LIB_DEPENDS-main=  devel/t1lib ${LIB_DEPENDS}
 RUN_DEPENDS-utils= print/ghostscript/gnu-fonts
 RUN_DEPENDS-main=  ${RUN_DEPENDS-utils} \
${FULLPKGNAME-utils}:textproc/xpdf,-utils
 
 WANTLIB-utils= c m pthread stdc++ z
 WANTLIB-main=  ${WANTLIB} ${WANTLIB-utils} ICE SM X11 Xext Xpm Xt \
-   freetype t1>=3 Xm
+   freetype Xm
 
 NO_REGRESS=Yes
 
Index: distinfo
===
RCS file: /cvs/ports/textproc/xpdf/distinfo,v
retrieving revision 1.16
diff -u -p -r1.16 distinfo
--- distinfo4 Dec 2010 10:44:31 -   1.16
+++ distinfo21 Aug 2011 11:24:35 -
@@ -1,30 +1,5 @@
-MD5 (xpdf-3.02.tar.gz) = WZ3EzGWgfuhoz5KmZ6kT0g==
-MD5 (xpdf-3.02pl1.patch) = h3EYeG3+J9G3qlpnWcxuRQ==
-MD5 (xpdf-3.02pl2.patch) = OlyxZa5meB4LIeYhmuBnlQ==
-MD5 (xpdf-3.02pl3.patch) = WBlj7eD7VxXhpp8BtbjOYw==
-MD5 (xpdf-3.02pl4.patch) = cLdScWeY3TQaS/iQ319v3A==
-MD5 (xpdf-3.02pl5.patch) = UEkCyl6dZsZ+7QNjbsaxYw==
-RMD160 (xpdf-3.02.tar.gz) = 6QDLhnC4xDC+qkWJX7R0QRyxlY0=
-RMD160 (xpdf-3.02pl1.patch) = XDEPlnYPcunBBisAxXwu0DWsZ1c=
-RMD160 (xpdf-3.02pl2.patch) = ACTj0gPWngc6RYVwzsVnniYK0gQ=
-RMD160 (xpdf-3.02pl3.patch) = hZ7DEx08RSamB17mOcXrcEGUIRs=
-RMD160 (xpdf-3.02pl4.patch) = QoBl6Mljm2eZcFsha+YD9S77iiI=
-RMD160 (xpdf-3.02pl5.patch) = 9QKnxTEek18+Sl/Vt3C0TmjAmno=
-SHA1 (xpdf-3.02.tar.gz) = +ZQGmIQMioBFZ36L5oq4WAkD4go=
-SHA1 (xpdf-3.02pl1.patch) = zTyO1uH9NgYJi4XVzIp9GqMFJm0=
-SHA1 (xpdf-3.02pl2.patch) = 0ILr4NNsrQwEYDlQIW9cUt4cJZM=
-SHA1 (xpdf-3.02pl3.patch) = I/SWgEgCo9pTDx0Lq4lLrj6Tj8I=
-SHA1 (xpdf-3.02pl4.patch) = GqMIehx4gohK59OlAiQKVazKZf0=
-SHA1 (xpdf-3.02pl5.patch) = Cs1J5zu6R/oex7R5648TmKM+q7w=
-SHA256 (xpdf-3.02.tar.gz) = szp9VvRUwzGuUJlvmJ6GyRZuV6+Xt03ijN3z1RrBHwA=
-SHA256 (xpdf-3.02pl1.patch) = WPYTsAtBSoaqd2t2/NiZu0FeTuTtwhhMinxO0QBNu/M=
-SHA256 (xpdf-3.02pl2.patch) = 0cHYh7C4pSg/BPgl5E8IXy6S2ve1GIiazxvInqB+2dk=
-SHA256 (xpdf-3.02pl3.patch) = WUzo+9I7/ynqzd+uNTPGPH6GtKJPfUXkTxk309GeU0s=
-SHA256 (xpdf-3.02pl4.patch) = sIRDlUETGHZu91CYd4f3eCMelLwV8E9/fRb0H9WBiLA=
-SHA256 (xpdf-3.02pl5.patch) = kvyzCDoZ43swlpeAQ/rqjHd+eq7KODS4Mtmbwq8xcbo=
-SIZE (xpdf-3.02.tar.gz) = 674912
-SIZE (xpdf-3.02pl1.patch) = 1050
-SIZE (xpdf-3.02pl2.patch) = 20843
-SIZE (xpdf-3.02pl3.patch) = 30727
-SIZE (xpdf-3.02pl4.patch) = 6982
-SIZE (xpdf-3.02pl5.patch) = 1065
+MD5 (xpdf-3.03.tar.gz) = r3X3cr7g5a5KgR/50D6sWg==
+RMD160 (xpdf-3.03.tar.gz) = 7xM2wYkCb7Ds0Wnis3taWqIuBL4=
+SHA1 (xpdf-3.03.tar.gz) = SZQj6KeV4O/XbKeYI5600NUv4kg=
+SHA256 (xpdf-3.03.tar.gz) = As9j2PYybtpkQJbND5aeFYhwKthyIsHpOIqTwnD7zso=
+SIZE (xpdf-3.03.tar.gz) = 795537
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/textproc/xpdf/patches/patch-Makefile_in,v
retrieving revision 1.1
diff -u -p -r1.1 patch-Makefile_in
--- patches/patch-Makefile_in   10 Feb 2008 20:25:14 -  1.1
+++ patches/patch-Makefile_in   21 Aug 2011 11:24:35 -
@@ -1,7 +1,7 @@
 $OpenBSD: patch-Makefile_in,v 1.1 2008/02/10 20:25:14 landry Exp $
 Makefile.in.orig   Mon Nov 12 11:33:36 2007
-+++ Makefile.inMon Nov 12 11:34:40 2007
-@@ -94,13 +94,8 @@ install: dummy
+--- Makefile.in.orig   Mon Aug 15 23:08:52 2011
 Makefile.inThu Aug 18 21:10:22 2011
+@@ -102,13 +102,8 @@ install: dummy
$(INSTALL_DATA) $(srcdir)/doc/pdfimages.1 
$(DESTDIR)@mandir@/man1/pdfimages.1
-mkdir -p $(DESTDIR)@mandir@/man5
$(INSTALL_DATA) $(srcdir)/doc/xpdfrc.5 $(DESTDI

Re: [UPDATE] textproc/xpdf

2010-12-03 Thread Miod Vallat
> Update to xpdf 3.02pl5 (which simply applies fixes for CVE-2010-3702 and
> CVE-2010-3704), and update the splash/SplashXPath.cc bounds checking fix
> to survive yet another killer pdf
> (ATT2100_Microprocessor_Hardware_Specification_Mar91.pdf from bitsavers,
> if you're curious; xpdf would dump core when trying to display page
> #14).
> 
> While there, remove USE_GROFF, the various manpages seem to be rendered
> correctly with mandoc(1).

Sorry, now with the correct diff.

Index: Makefile
===
RCS file: /cvs/ports/textproc/xpdf/Makefile,v
retrieving revision 1.76
diff -u -p -r1.76 Makefile
--- Makefile20 Nov 2010 19:56:52 -  1.76
+++ Makefile3 Dec 2010 21:23:23 -
@@ -4,16 +4,17 @@ COMMENT-main= PDF viewer for X11
 COMMENT-utils= PDF conversion tools
 
 DISTNAME=  xpdf-3.02
-PKGNAME-main=  xpdf-3.02.4
-REVISION-main= 3
-PKGNAME-utils= xpdf-utils-3.02.4
+PKGNAME-main=  xpdf-3.02.5
+REVISION-main= 0
+PKGNAME-utils= xpdf-utils-3.02.5
 CATEGORIES=textproc x11
 
 MASTER_SITES=  ftp://ftp.foolabs.com/pub/xpdf/ \
ftp://gd.tuwien.ac.at/publishing/xpdf/ \
ftp://tug.org/xpdf/
 PATCHFILES=xpdf-3.02pl1.patch xpdf-3.02pl2.patch \
-   xpdf-3.02pl3.patch xpdf-3.02pl4.patch
+   xpdf-3.02pl3.patch xpdf-3.02pl4.patch \
+   xpdf-3.02pl5.patch
 PATCH_DIST_STRIP=-p1
 
 HOMEPAGE=  http://www.foolabs.com/xpdf/
@@ -28,7 +29,6 @@ PERMIT_DISTFILES_FTP= Yes
 
 USE_MOTIF= openmotif
 USE_GMAKE= Yes
-USE_GROFF =Yes
 CONFIGURE_STYLE=gnu
 CONFIGURE_ARGS+= --enable-multithreaded \
 --without-Sgm-library \
Index: distinfo
===
RCS file: /cvs/ports/textproc/xpdf/distinfo,v
retrieving revision 1.15
diff -u -p -r1.15 distinfo
--- distinfo15 Oct 2009 12:51:13 -  1.15
+++ distinfo3 Dec 2010 21:23:23 -
@@ -3,23 +3,28 @@ MD5 (xpdf-3.02pl1.patch) = h3EYeG3+J9G3q
 MD5 (xpdf-3.02pl2.patch) = OlyxZa5meB4LIeYhmuBnlQ==
 MD5 (xpdf-3.02pl3.patch) = WBlj7eD7VxXhpp8BtbjOYw==
 MD5 (xpdf-3.02pl4.patch) = cLdScWeY3TQaS/iQ319v3A==
+MD5 (xpdf-3.02pl5.patch) = UEkCyl6dZsZ+7QNjbsaxYw==
 RMD160 (xpdf-3.02.tar.gz) = 6QDLhnC4xDC+qkWJX7R0QRyxlY0=
 RMD160 (xpdf-3.02pl1.patch) = XDEPlnYPcunBBisAxXwu0DWsZ1c=
 RMD160 (xpdf-3.02pl2.patch) = ACTj0gPWngc6RYVwzsVnniYK0gQ=
 RMD160 (xpdf-3.02pl3.patch) = hZ7DEx08RSamB17mOcXrcEGUIRs=
 RMD160 (xpdf-3.02pl4.patch) = QoBl6Mljm2eZcFsha+YD9S77iiI=
+RMD160 (xpdf-3.02pl5.patch) = 9QKnxTEek18+Sl/Vt3C0TmjAmno=
 SHA1 (xpdf-3.02.tar.gz) = +ZQGmIQMioBFZ36L5oq4WAkD4go=
 SHA1 (xpdf-3.02pl1.patch) = zTyO1uH9NgYJi4XVzIp9GqMFJm0=
 SHA1 (xpdf-3.02pl2.patch) = 0ILr4NNsrQwEYDlQIW9cUt4cJZM=
 SHA1 (xpdf-3.02pl3.patch) = I/SWgEgCo9pTDx0Lq4lLrj6Tj8I=
 SHA1 (xpdf-3.02pl4.patch) = GqMIehx4gohK59OlAiQKVazKZf0=
+SHA1 (xpdf-3.02pl5.patch) = Cs1J5zu6R/oex7R5648TmKM+q7w=
 SHA256 (xpdf-3.02.tar.gz) = szp9VvRUwzGuUJlvmJ6GyRZuV6+Xt03ijN3z1RrBHwA=
 SHA256 (xpdf-3.02pl1.patch) = WPYTsAtBSoaqd2t2/NiZu0FeTuTtwhhMinxO0QBNu/M=
 SHA256 (xpdf-3.02pl2.patch) = 0cHYh7C4pSg/BPgl5E8IXy6S2ve1GIiazxvInqB+2dk=
 SHA256 (xpdf-3.02pl3.patch) = WUzo+9I7/ynqzd+uNTPGPH6GtKJPfUXkTxk309GeU0s=
 SHA256 (xpdf-3.02pl4.patch) = sIRDlUETGHZu91CYd4f3eCMelLwV8E9/fRb0H9WBiLA=
+SHA256 (xpdf-3.02pl5.patch) = kvyzCDoZ43swlpeAQ/rqjHd+eq7KODS4Mtmbwq8xcbo=
 SIZE (xpdf-3.02.tar.gz) = 674912
 SIZE (xpdf-3.02pl1.patch) = 1050
 SIZE (xpdf-3.02pl2.patch) = 20843
 SIZE (xpdf-3.02pl3.patch) = 30727
 SIZE (xpdf-3.02pl4.patch) = 6982
+SIZE (xpdf-3.02pl5.patch) = 1065
Index: patches/patch-fofi_FoFiType1_cc
===
RCS file: patches/patch-fofi_FoFiType1_cc
diff -N patches/patch-fofi_FoFiType1_cc
--- patches/patch-fofi_FoFiType1_cc 13 Oct 2010 11:37:25 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,31 +0,0 @@
-$OpenBSD: patch-fofi_FoFiType1_cc,v 1.1 2010/10/13 11:37:25 jasper Exp $
-
-Security fix for CVE-2010-3704. Patch from upstream poppler git:
-http://cgit.freedesktop.org/poppler/poppler/commit/?id=39d140bfc0b8239bdd96d6a55842034ae5c05473
-
 fofi/FoFiType1.cc.orig Wed Oct 13 13:18:58 2010
-+++ fofi/FoFiType1.cc  Wed Oct 13 13:21:25 2010
-@@ -18,6 +18,14 @@
- #include "FoFiEncodings.h"
- #include "FoFiType1.h"
- 
-+#if defined(__GNUC__) && (__GNUC__ > 2) && defined(__OPTIMIZE__)
-+# define likely(x)  __builtin_expect((x), 1)
-+# define unlikely(x)__builtin_expect((x), 0)
-+#else
-+# define likely(x)  (x)
-+# define unlikely(x)(x)
-+#endif
-+
- //
- // FoFiType1
- //
-@@ -224,7 +232,7 @@ void FoFiType1::parse() {
-   code = code * 8 + (*p2 - '0');
- }
-   }
--  if (code < 256) {
-+  if (likely(code < 256 && code >= 0)) {
- for (p =