[gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
120127 Andreas K. Huettel wrote: > # Andreas K. Hüttel (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
[gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
On 01/27/2012 07:24 PM, Michael Mol wrote: > On Fri, Jan 27, 2012 at 9:58 PM, Philip Webb 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.
[gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
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: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
On Fri, Jan 27, 2012 at 9:58 PM, Philip Webb wrote: > 120127 Andreas K. Huettel wrote: >> # Andreas K. Hüttel (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: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
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. signature.asc Description: PGP signature
Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
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: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
2012/1/28 Mick : > 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: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
> 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 signature.asc Description: PGP signature
Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
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-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
On Saturday 28 Jan 2012 10:51:23 Jesús J. Guerrero Botella wrote: > 2012/1/28 Mick : > > 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
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 -
Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
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 : >>> 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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
On Sat, Jan 28, 2012 at 06:06:33PM +, 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. #!/bin/sh for h in `find /proc/*/fd -ilname "/tmp/Flash*" 2>/dev/null`; do path=`readlink "$h" | cut -d' ' -f1` [ -f "$path" ] || { echo "$path" ln -s "$h" "$path"; } done pgpGnQDeIJ1qs.pgp Description: PGP signature
Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
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: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
On Saturday 28 Jan 2012 19:38:26 Frank Steinmetzger wrote: > On Sat, Jan 28, 2012 at 06:06:33PM +, 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf
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 signature.asc Description: This is a digitally signed message part.