Mailing List Archive

Re: [gentoo-dev-announce] Last rites: app-text/xpdf
120127 Andreas K. Huettel wrote:
> # Andreas K. Hüttel <dilfridge@gentoo.org> (27 Jan 2012)
> # Has developed into an unmaintainable mess, and everyone who
> # knows about it is either retired or missing in action.
> # Several minor bugs and one ugly security issues (#386271).
> # Masked for removal because of lack of maintainer.

I use Xpdf frequently & have no problem with it.
The security bug you cite says there is a newer version 3.03
which fixes at least some of the security problems.
If you limit yourself sensibly to PDFs from known reliable sites,
you won't run into the problem in Bug 386271 AFAIK.
The bug I submitted is minor & has a workaround, which I use.

Is there an alternative which doesn't require eg 'kdelibs' or similar ?
In my netbook, Xpdf is the only method I have of reading PDFs,
as I use Fluxbox & don't have KDE installed at all.

There is a fork of some kind at https://github.com/rbrito/xpdf-poppler ,
which is given as the contact by 'eix'.

I very much hope there is at least an alternative
or otherwise some reconsideration of removing Xpdf from Gentoo.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
On Fri, Jan 27, 2012 at 9:58 PM, Philip Webb <purslow@ca.inter.net> wrote:
> 120127 Andreas K. Huettel wrote:
>> # Andreas K. Hüttel <dilfridge@gentoo.org> (27 Jan 2012)
>> # Has developed into an unmaintainable mess, and everyone who
>> # knows about it is either retired or missing in action.
>> # Several minor bugs and one ugly security issues (#386271).
>> # Masked for removal because of lack of maintainer.
>
> I use Xpdf frequently & have no problem with it.
> The security bug you cite says there is a newer version 3.03
> which fixes at least some of the security problems.
> If you limit yourself sensibly to PDFs from known reliable sites,
> you won't run into the problem in Bug 386271 AFAIK.
> The bug I submitted is minor & has a workaround, which I use.
>
> Is there an alternative which doesn't require eg 'kdelibs' or similar ?
> In my netbook, Xpdf is the only method I have of reading PDFs,
> as I use Fluxbox & don't have KDE installed at all.
>
> There is a fork of some kind at  https://github.com/rbrito/xpdf-poppler ,
> which is given as the contact by 'eix'.
>
> I very much hope there is at least an alternative
> or otherwise some reconsideration of removing Xpdf from Gentoo.

I use evince, myself.

--
:wq
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
On Fri, 27 Jan 2012 21:58:16 -0500, Philip Webb wrote:

> I very much hope there is at least an alternative
> or otherwise some reconsideration of removing Xpdf from Gentoo.

One of the reasons for the 30 day warning is to give you time to copy the
ebuild to a local overlay if you want to continue running the software at
your own risk. But leaving unmaintained software in the tree, especially
with security holes, is at best pointless and at worst dangerous.


--
Neil Bothwick

For security reasons, all text in this mail
is double-rot13 encrypted.
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
120128 Neil Bothwick wrote:
> One of the reasons for the 30 day warning
> is to give you time to copy the ebuild to a local overlay
> if you want to continue running the software at your own risk.

I've already copied /usr/portage/app-text/xpdf/ to /usr/local/src/ :
is there anything else I will need, if I decide to go that route ?

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
On Saturday 28 Jan 2012 10:03:42 Philip Webb wrote:
> 120128 Neil Bothwick wrote:
> > One of the reasons for the 30 day warning
> > is to give you time to copy the ebuild to a local overlay
> > if you want to continue running the software at your own risk.
>
> I've already copied /usr/portage/app-text/xpdf/ to /usr/local/src/ :
> is there anything else I will need, if I decide to go that route ?

I'm reluctant to go down this route. Things that xpdf depends may or many not
be updated, then I'll have to keep an eye out for the latest xpdf code and
download and update this manually, as well as any dependencies which may fall
out of the tree. This will create a maintenance liability for me.

I'd like to continue using xpdf, but unless a maintainer shows up it'll have
to bite the dust. :-(

Anyhow, another alternative may be mupdf - it opens files when called from
another application (e.g. a browser) but unlike xpdf I have not found a way of
saving a file once opened without having to redownload it with the browser.
--
Regards,
Mick
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
2012/1/28 Mick <michaelkintzios@gmail.com>:
> On Saturday 28 Jan 2012 10:03:42 Philip Webb wrote:
...
> another application (e.g. a browser) but unlike xpdf I have not found a way of
> saving a file once opened without having to redownload it with the browser.

I'd look into /tmp, it'll probably be there.

--
Jesús Guerrero Botella
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
> Is there an alternative which doesn't require eg 'kdelibs' or similar ?
> In my netbook, Xpdf is the only method I have of reading PDFs,
> as I use Fluxbox & don't have KDE installed at all.

It should not stop you from trying okular (kdelibs based)
and evince (libgnome based). They are really neat.

For lightweight variants you might like to look at
app-text/epdfview and app-text/gsview or at some
pdf->something converter.

--

Sergei
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
120128 Sergei Trofimovich wrote:
>> Is there an alternative which doesn't require eg 'kdelibs' or similar ?
>> In my netbook, Xpdf is the only method I have of reading PDFs,
>> as I use Fluxbox & don't have KDE installed at all.
> It should not stop you from trying okular (kdelibs based)

Well no ! -- I don't want to have any KDE in my netbook :
I use a lot of KDE apps on my desktop, incl Okular, but not in the netbook.

> and evince (libgnome based). They are really neat.
> For lightweight variants you might like to look
> at app-text/epdfview and app-text/gsview.

Thanks for this & other comments + advice.

I've installed Evince Epdfview Zathura. Evince looks as usable as Xpdf
& Epdfview is also simple & effective; Zathura works, but relies largely
on keys (ok) & the index toggles, which is not quite as usable.
Epdfview has the advantage over Evince that it needs no deps,
so that's what I may use in my netbook.

I also noticed a note in my homemade list of installed pkgs
that I had to patch Xpdf to avoid the slow-start problem,
so I'm satisfied that it cb consigned to history.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca
Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
On 01/27/2012 07:24 PM, Michael Mol wrote:
> On Fri, Jan 27, 2012 at 9:58 PM, Philip Webb <purslow@ca.inter.net> wrote:

>> I very much hope there is at least an alternative
>> or otherwise some reconsideration of removing Xpdf from Gentoo.
>
> I use evince, myself.

Me too, but it does require some cruft from gnome.
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
On Saturday 28 Jan 2012 10:51:23 Jesús J. Guerrero Botella wrote:
> 2012/1/28 Mick <michaelkintzios@gmail.com>:
> > On Saturday 28 Jan 2012 10:03:42 Philip Webb wrote:
> ...
>
> > another application (e.g. a browser) but unlike xpdf I have not found a
> > way of saving a file once opened without having to redownload it with
> > the browser.
>
> I'd look into /tmp, it'll probably be there.

It used to be the case that FF would drop temporary downloads in /tmp, but I
can't find them in there any more. This is of particular interest for some
flash videos which after I watched them I decide to save them, but can't find
them anywhere. Ditto with Chromium, not idea where it saves such temporary
files.

PS. Opera saves them under ~.opera/cache/sesn/ if I recall correctly,
although it gives them random names and I have to run them or guess from their
size, before I know if it is the file that I wanted to save.
--
Regards,
Mick
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
On Saturday 28 Jan 2012 13:30:50 Philip Webb wrote:
> 120128 Sergei Trofimovich wrote:
> >> Is there an alternative which doesn't require eg 'kdelibs' or similar ?
> >> In my netbook, Xpdf is the only method I have of reading PDFs,
> >> as I use Fluxbox & don't have KDE installed at all.
> >
> > It should not stop you from trying okular (kdelibs based)
>
> Well no ! -- I don't want to have any KDE in my netbook :
> I use a lot of KDE apps on my desktop, incl Okular, but not in the netbook.
>
> > and evince (libgnome based). They are really neat.
> > For lightweight variants you might like to look
> > at app-text/epdfview and app-text/gsview.
>
> Thanks for this & other comments + advice.
>
> I've installed Evince Epdfview Zathura. Evince looks as usable as Xpdf
> & Epdfview is also simple & effective; Zathura works, but relies largely
> on keys (ok) & the index toggles, which is not quite as usable.
> Epdfview has the advantage over Evince that it needs no deps,
> so that's what I may use in my netbook.
>
> I also noticed a note in my homemade list of installed pkgs
> that I had to patch Xpdf to avoid the slow-start problem,
> so I'm satisfied that it cb consigned to history.

Hmm ... tried to emerge epdfview and it failed: :-(

# emerge -uaDv epdfview

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] app-text/epdfview-0.1.6-r1 USE="cups nls -test" 397 kB

[snip ...]

IJob.cxx: In static member function ‘static void*
ePDFView::IJob::dispatcher(void*)’:
IJob.cxx:62:1: warning: no return statement in function returning non-void
if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -
I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -DQT_SHARED -
I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/glib-2.0 -
I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -
I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/qt4 -
I/usr/include/qt4/QtGui -I/usr/include/libdrm -I/usr/include/qt4/QtCore -
I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -
I/usr/include/gdk-pixbuf-2.0 -march=native -O2 -pipe -Wall -Wno-long-long -
DNDEBUG -DG_DISABLE_ASSERT -MT libepdfview_a-JobFind.o -MD -MP -MF
".deps/libepdfview_a-JobFind.Tpo" -c -o libepdfview_a-JobFind.o `test -f
'JobFind.cxx' || echo './'`JobFind.cxx; \
then mv -f ".deps/libepdfview_a-JobFind.Tpo" ".deps/libepdfview_a-JobFind.Po";
else rm -f ".deps/libepdfview_a-JobFind.Tpo"; exit 1; fi
if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -
I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -DQT_SHARED -
I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/glib-2.0 -
I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -
I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/qt4 -
I/usr/include/qt4/QtGui -I/usr/include/libdrm -I/usr/include/qt4/QtCore -
I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -
I/usr/include/gdk-pixbuf-2.0 -march=native -O2 -pipe -Wall -Wno-long-long -
DNDEBUG -DG_DISABLE_ASSERT -MT libepdfview_a-JobLoad.o -MD -MP -MF
".deps/libepdfview_a-JobLoad.Tpo" -c -o libepdfview_a-JobLoad.o `test -f
'JobLoad.cxx' || echo './'`JobLoad.cxx; \
then mv -f ".deps/libepdfview_a-JobLoad.Tpo" ".deps/libepdfview_a-JobLoad.Po";
else rm -f ".deps/libepdfview_a-JobLoad.Tpo"; exit 1; fi
if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -
I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -DQT_SHARED -
I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/glib-2.0 -
I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -
I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/qt4 -
I/usr/include/qt4/QtGui -I/usr/include/libdrm -I/usr/include/qt4/QtCore -
I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -
I/usr/include/gdk-pixbuf-2.0 -march=native -O2 -pipe -Wall -Wno-long-long -
DNDEBUG -DG_DISABLE_ASSERT -MT libepdfview_a-JobRender.o -MD -MP -MF
".deps/libepdfview_a-JobRender.Tpo" -c -o libepdfview_a-JobRender.o `test -f
'JobRender.cxx' || echo './'`JobRender.cxx; \
then mv -f ".deps/libepdfview_a-JobRender.Tpo" ".deps/libepdfview_a-
JobRender.Po"; else rm -f ".deps/libepdfview_a-JobRender.Tpo"; exit 1; fi
if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -
I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -DQT_SHARED -
I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/glib-2.0 -
I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -
I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/qt4 -
I/usr/include/qt4/QtGui -I/usr/include/libdrm -I/usr/include/qt4/QtCore -
I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -
I/usr/include/gdk-pixbuf-2.0 -march=native -O2 -pipe -Wall -Wno-long-long -
DNDEBUG -DG_DISABLE_ASSERT -MT libepdfview_a-JobSave.o -MD -MP -MF
".deps/libepdfview_a-JobSave.Tpo" -c -o libepdfview_a-JobSave.o `test -f
'JobSave.cxx' || echo './'`JobSave.cxx; \
then mv -f ".deps/libepdfview_a-JobSave.Tpo" ".deps/libepdfview_a-JobSave.Po";
else rm -f ".deps/libepdfview_a-JobSave.Tpo"; exit 1; fi
if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -
I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -DQT_SHARED -
I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/glib-2.0 -
I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -
I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/qt4 -
I/usr/include/qt4/QtGui -I/usr/include/libdrm -I/usr/include/qt4/QtCore -
I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -
I/usr/include/gdk-pixbuf-2.0 -march=native -O2 -pipe -Wall -Wno-long-long -
DNDEBUG -DG_DISABLE_ASSERT -MT libepdfview_a-MainPter.o -MD -MP -MF
".deps/libepdfview_a-MainPter.Tpo" -c -o libepdfview_a-MainPter.o `test -f
'MainPter.cxx' || echo './'`MainPter.cxx; \
then mv -f ".deps/libepdfview_a-MainPter.Tpo" ".deps/libepdfview_a-
MainPter.Po"; else rm -f ".deps/libepdfview_a-MainPter.Tpo"; exit 1; fi
if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -
I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -DQT_SHARED -
I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/glib-2.0 -
I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -
I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/qt4 -
I/usr/include/qt4/QtGui -I/usr/include/libdrm -I/usr/include/qt4/QtCore -
I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -
I/usr/include/gdk-pixbuf-2.0 -march=native -O2 -pipe -Wall -Wno-long-long -
DNDEBUG -DG_DISABLE_ASSERT -MT libepdfview_a-PagePter.o -MD -MP -MF
".deps/libepdfview_a-PagePter.Tpo" -c -o libepdfview_a-PagePter.o `test -f
'PagePter.cxx' || echo './'`PagePter.cxx; \
then mv -f ".deps/libepdfview_a-PagePter.Tpo" ".deps/libepdfview_a-
PagePter.Po"; else rm -f ".deps/libepdfview_a-PagePter.Tpo"; exit 1; fi
if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -
I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -DQT_SHARED -
I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/glib-2.0 -
I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -
I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/qt4 -
I/usr/include/qt4/QtGui -I/usr/include/libdrm -I/usr/include/qt4/QtCore -
I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -
I/usr/include/gdk-pixbuf-2.0 -march=native -O2 -pipe -Wall -Wno-long-long -
DNDEBUG -DG_DISABLE_ASSERT -MT libepdfview_a-PDFDocument.o -MD -MP -MF
".deps/libepdfview_a-PDFDocument.Tpo" -c -o libepdfview_a-PDFDocument.o `test
-f 'PDFDocument.cxx' || echo './'`PDFDocument.cxx; \
then mv -f ".deps/libepdfview_a-PDFDocument.Tpo" ".deps/libepdfview_a-
PDFDocument.Po"; else rm -f ".deps/libepdfview_a-PDFDocument.Tpo"; exit 1; fi
PDFDocument.cxx: In member function ‘virtual ePDFView::DocumentPage*
ePDFView::PDFDocument::renderPage(gint)’:
PDFDocument.cxx:618:62: error: ‘poppler_page_render_to_pixbuf’ was not
declared in this scope
PDFDocument.cxx: In member function ‘virtual gboolean
ePDFView::PDFDocument::loadFile(const gchar*, const gchar*, GError**)’:
PDFDocument.cxx:231:45: warning: ignoring return value of ‘ssize_t write(int,
const void*, size_t)’, declared with attribute warn_unused_result
make[3]: *** [libepdfview_a-PDFDocument.o] Error 1
make[3]: Leaving directory `/var/tmp/portage/app-text/epdfview-0.1.6-
r1/work/epdfview-0.1.6/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/app-text/epdfview-0.1.6-
r1/work/epdfview-0.1.6/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/app-text/epdfview-0.1.6-
r1/work/epdfview-0.1.6'
make: *** [all] Error 2
emake failed
* ERROR: app-text/epdfview-0.1.6-r1 failed (compile phase):
* emake failed
*
* Call stack:
* ebuild.sh, line 85: Called src_compile
* environment, line 2093: Called _eapi2_src_compile
* phase-helpers.sh, line 577: Called die
* The specific snippet of code:
* emake || die "emake failed"
--
Regards,
Mick
Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
On 01/28/2012 10:06 AM, Mick wrote:

> It used to be the case that FF would drop temporary downloads in /tmp, but I
> can't find them in there any more.

It may depend on which FF plugin is displaying the download, not sure.
Anyway, you might try lsof while FF is still displaying it. i.e. pause
the video or whatever while you're hunting.
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
Am 28.01.2012 19:06, schrieb Mick:
> On Saturday 28 Jan 2012 10:51:23 Jesús J. Guerrero Botella wrote:
>> 2012/1/28 Mick <michaelkintzios@gmail.com>:
>>> On Saturday 28 Jan 2012 10:03:42 Philip Webb wrote:
>> ...
>>
>>> another application (e.g. a browser) but unlike xpdf I have not found a
>>> way of saving a file once opened without having to redownload it with
>>> the browser.
>>
>> I'd look into /tmp, it'll probably be there.
>
> It used to be the case that FF would drop temporary downloads in /tmp, but I
> can't find them in there any more. This is of particular interest for some
> flash videos which after I watched them I decide to save them, but can't find
> them anywhere. Ditto with Chromium, not idea where it saves such temporary
> files.
>

AFAIK, that's adobe-flash's doing, not firefox/chromium. PDFs and other
files downloaded with the "open"-action in Firefox still get dumped into
/tmp.

Regards,
Florian Philipp
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
On Sat, Jan 28, 2012 at 06:06:33PM +0000, Mick wrote:

> > > another application (e.g. a browser) but unlike xpdf I have not found a
> > > way of saving a file once opened without having to redownload it with
> > > the browser.
> >
> > I'd look into /tmp, it'll probably be there.
>
> It used to be the case that FF would drop temporary downloads in /tmp, but I
> can't find them in there any more. This is of particular interest for some
> flash videos which after I watched them I decide to save them, but can't find
> them anywhere. Ditto with Chromium, not idea where it saves such temporary
> files.

[getting OT regarding xpdf]

Yes, that's the flash plugin. It creates a file and then immediately deletes
it again. But thanks to the open architecture of a Linux system you can get it
back by copying from the file handle in /proc. I have a little script for
that which I'll attach to this message. It looks for all file handles that
link to a (now deleted) file called /tmp/Flash* and restores the link,
printing out the filename it thusly recovered. It could be a bit refined by
only looking for handles of flash player PIDs, but I guess a human wouldn't
perceive the difference anyway.

For youtube, I recommend youtube-dl. It lets you select the video format and
resolution (as offered), downloads the video and automatically renames the
file.
--
Gruß | Greetings | Qapla'
I forbid any use of my email addresses with Facebook services.

The problem with Perl jokes is that only the teller understands them.
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
120128 Mick tried to emerge epdfview and it failed:
> # emerge -uaDv epdfview
> These are the packages that would be merged, in order:
> Calculating dependencies... done!
> [ebuild N ] app-text/epdfview-0.1.6-r1 USE="cups nls -test" 397 kB
> [snip ...]
> PDFDocument.cxx: In member function ‘virtual ePDFView::DocumentPage*
> ePDFView::PDFDocument::renderPage(gint)’:
> PDFDocument.cxx:618:62: error: ‘poppler_page_render_to_pixbuf’ was not
> declared in this scope
> PDFDocument.cxx: In member function ‘virtual gboolean
> ePDFView::PDFDocument::loadFile(const gchar*, const gchar*, GError**)’:
> PDFDocument.cxx:231:45: warning: ignoring return value of ‘ssize_t write(int,
> const void*, size_t)’, declared with attribute warn_unused_result
> make[3]: *** [libepdfview_a-PDFDocument.o] Error 1
> [snip ...]

Do a resync & try emerging 0.1.8 , which is what I have.
Also, I don't use the 'nls' flag, so try '-nls' too if necessary.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
On Saturday 28 Jan 2012 19:38:26 Frank Steinmetzger wrote:
> On Sat, Jan 28, 2012 at 06:06:33PM +0000, Mick wrote:
> > > > another application (e.g. a browser) but unlike xpdf I have not found
> > > > a way of saving a file once opened without having to redownload it
> > > > with the browser.
> > >
> > > I'd look into /tmp, it'll probably be there.
> >
> > It used to be the case that FF would drop temporary downloads in /tmp,
> > but I can't find them in there any more. This is of particular interest
> > for some flash videos which after I watched them I decide to save them,
> > but can't find them anywhere. Ditto with Chromium, not idea where it
> > saves such temporary files.
>
> [getting OT regarding xpdf]
>
> Yes, that's the flash plugin. It creates a file and then immediately
> deletes it again. But thanks to the open architecture of a Linux system
> you can get it back by copying from the file handle in /proc. I have a
> little script for that which I'll attach to this message. It looks for all
> file handles that link to a (now deleted) file called /tmp/Flash* and
> restores the link, printing out the filename it thusly recovered. It could
> be a bit refined by only looking for handles of flash player PIDs, but I
> guess a human wouldn't perceive the difference anyway.
>
> For youtube, I recommend youtube-dl. It lets you select the video format
> and resolution (as offered), downloads the video and automatically renames
> the file.

Yes, I'm also using xVideoServiceThief for youtube.

Thanks for your script! I'll put it through its paces soon. :-)
--
Regards,
Mick
Re: Re: [gentoo-dev-announce] Last rites: app-text/xpdf [ In reply to ]
On Sunday 29 Jan 2012 04:53:44 Philip Webb wrote:
> 120128 Mick tried to emerge epdfview and it failed:
> > # emerge -uaDv epdfview
> > These are the packages that would be merged, in order:
> > Calculating dependencies... done!
> > [ebuild N ] app-text/epdfview-0.1.6-r1 USE="cups nls -test" 397 kB
> > [snip ...]
> > PDFDocument.cxx: In member function ‘virtual ePDFView::DocumentPage*
> > ePDFView::PDFDocument::renderPage(gint)’:
> > PDFDocument.cxx:618:62: error: ‘poppler_page_render_to_pixbuf’ was not
> > declared in this scope
> > PDFDocument.cxx: In member function ‘virtual gboolean
> > ePDFView::PDFDocument::loadFile(const gchar*, const gchar*, GError**)’:
> > PDFDocument.cxx:231:45: warning: ignoring return value of ‘ssize_t
> > write(int, const void*, size_t)’, declared with attribute
> > warn_unused_result make[3]: *** [libepdfview_a-PDFDocument.o] Error 1
> > [snip ...]
>
> Do a resync & try emerging 0.1.8 , which is what I have.
> Also, I don't use the 'nls' flag, so try '-nls' too if necessary.

Thanks Philip, 0.1.8 emerged successfully with cups and nls. It seems like a
lightweight pdf reader that does all I may need (assuming that it doesn't fall
over itself on DRM).
--
Regards,
Mick