Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

A new version of Xpdf has been released on 2007-feb-27, it has been taken care
of a lot of bugs, and finally fullscreen does work.
A new ebuild would be appreciated.

Reproducible: Always

The problem is our current xpdf has poppler as basis. And I dont have a new
poppler patch nor a new poppler. I guess I will wait for a new poppler and then
look into making the poppler patch work with the new xpdf.

If you got a better suggestion feel free to share.

There is a new poppler coming out Real Soon Now (tm) that has all those fixes
in it.

hmh, the new poppler does not compile with our xpdf. Neither with anything else
atm :(

Probably we should return to the old xpdf ebuild and just use upstream sources
instead of the poppler workaround.

Oooh, still no progress yet ?

So long time passed..

xpdf compiles with new poppler now after patching so all ok

> xpdf compiles with new poppler now after patching so all ok
> 

Is there any other problem with the new xpdf? It isn't in portage yet.(In reply
to comment #5)

No idea why's this bug closed as FIXED, nothing has been bumped. Reopen.

I added a working ebuild for xpdf-3.02 in
http://bugs.gentoo.org/show_bug.cgi?id=139805

It doesn't use poppler or include any patch but work for me.

(In reply to comment #5)
> xpdf compiles with new poppler now after patching so all ok
> 

So is the current xpdf-3.01-r8 the same as xpdf-3.02 when it is compiled with
the new poppler?

Shouldn't there be a version renaming to avoid confusion? Or am I totally off,
and xpdf-3.02 is still not in prortage?

(In reply to comment #9)
> (In reply to comment #5)
> > xpdf compiles with new poppler now after patching so all ok
> > 
> 
> So is the current xpdf-3.01-r8 the same as xpdf-3.02 when it is compiled with
> the new poppler?
> 
> Shouldn't there be a version renaming to avoid confusion? Or am I totally off,
> and xpdf-3.02 is still not in prortage?
> 

I don't think so, because, as in bug 139805
http://bugs.gentoo.org/show_bug.cgi?id=139805 xpdf-3.01-r8 doesn't show
correctly some graphics, when xpdf-3.02 show them without problem.

A test file: http://hdr.undp.org/en/media/hdr05_fr_chapter_41.pdf

Sorry if I am bugging (pun intended :-)), but what is the problem then?
I tried to make a xpdf-poppler ebuild, but I couldn't get it to compile with
it.
Is there any light at the end of the tunnel?

regards,
Thomas

Why is the reason to use poppler instead of the original sources?

Especially, does the poppler patch add any function or remove any bug to xpdf?
If it is not the case, why not to use the original sources?

(In reply to comment #11)
>Why is the reason to use poppler instead of the original sources?
>

I guess it is cleaner, since ghostscript (so generally printing) draws poppler
into your system anyway, and in that way you don't have to compile redundant
code :) 

Once more I tried to get xpdf to compile with poppler, I had some initial
success, however xpdf seems to call the function 'getContinuousView' of
'globalParams' which is not present in the current poppler-0.6.2 declaration of
GlobalParams ( I checked for possible name change, but the function is just
absent. :( )

> PDFCore.cc: In constructor 'PDFCore::PDFCore(SplashColorMode, int, GBool, Guchar*, GBool)':
>PDFCore.cc:87: error: 'class GlobalParams' has no member named 'getContinuousView'

One solution would be to patch poppler against the current xpdf version, or
just drop the poppler compiling. Stefan Schweizer comment #5 said he got it
working, could you please provide more information on this?

regards,
Thomas

(In reply to comment #13)
> (In reply to comment #11)
> >Why is the reason to use poppler instead of the original sources?
> >
> 
> I guess it is cleaner, since ghostscript (so generally printing) draws poppler
> into your system anyway, and in that way you don't have to compile redundant
> code :) 
> 

I don't care about this because I can almost always do something else when
portage is compiling. Otherwise, I can stop portage and restart it later. But
it seems that it make the life easier for maintainers: according to
http://www.gentoo.org/news/en/gwn/20060206-newsletter.xml, it greatly
simplifies the security process.

I am not convinced about this because I done a little search and found more
security reports about poppler as about xpdf. But no matter. Don't stress for
me, my system can live with my custom xpdf ebuild on comment #8.

And thank you all for the work.

Oky dok, I got it now!

There are still two problems however, first 'GlobalParams' is redundant (which
means  I have it in xpdf and in poppler) which kind of defeats the purpose, but
the xpdf version has about 1,100 lines more code, so I guess we need to patch
poppler?!
the second problem is also about poppler, in 'goo/gfiles.h' it checks for
'HAVE_DIRENT_H' a macro which would be set by 'configure' but it isn't set at
compile time of xpdf, thus it never passes this check and thus a compile error
occurs because a header file is missing. I don't know how to fix this, besides
a very ugly hack, where I just insert the header in gfiles.h by hand :p

Any suggestions?

regards,
Thomas

Created an attachment (id=136116) [details]
app-text/xpdf-3.02 ebuild (uses poppler)

This is the ebuild which works with poppler :)

Created an attachment (id=136117) [details]
xpdf-3.02-poppler source package

xpdf-3.02-poppler source package, you will need this to put in your
'distfiles/' folder, since I don't have any upload stream yet.

I got it! :)

Please test it to the max, and you will need the poppler-0.6.2-r1 ebuild with
the patch I created, have a look here
http://bugs.gentoo.org/show_bug.cgi?id=199398

Created an attachment (id=136120) [details]
xpdf-3.02-poppler source package (updated)

I found a bug in the old sources, which wouldn't let you print to PS file,
sorry.

*** Bug 199398 has been marked as a duplicate of this bug. ***

Created an attachment (id=136222) [details]
xpdf-3.02-poppler source package (works without patched poppler)

I decided that for now, the problem of a little redundant code is not as bad as
a "gentoo-only" patched poopler, which could have security issues which only
gentoo would have to keep track, so this package works without a patched
poppler, meanwhile I will try to get the patch upstream in poppler. For the
xpdf-poppler uses nothing changes, and he won't notice :)

regards,
Thomas

Created an attachment (id=136223) [details]
app-text/xpdf-3.02 ebuild (updated)

This ebuild is not anymore dependant on a patched poppler :)

This is now in the tree. We need this stable asap because the old version is
broken on the arches in CC

x86 done

I'll un-cc arches and re-add them to bug 196735.

Since this is holding back the Poppler GLSA, we need a fast reaction.

Stable for HPPA.

ppc stable

Sparc stable.  Didn't quite realize there were two bugs asking for the same
thing.  Or does this bug ask for something different than bug #196735 does?  It
also asks for stablization for xpdf-3.02.

amd64 stable for xpdf 3.02

seems i forgot the checkbox "Remove CC"

Readding all security-unsupported arches since bug 196735 is now closed.

10:33:51 <+CIA-23> vapier * gentoo-x86/app-text/xpdf/xpdf-3.02-r1.ebuild: 
10:33:51 <+CIA-23> arm/sh stable 

Closing wrt http://www.gentoo.org/news/20080210-mips-experimental-arch.xml