Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf

2012-01-29 Thread Mick
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

2012-01-29 Thread Mick
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.


Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf

2012-01-28 Thread Neil Bothwick
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

2012-01-28 Thread Philip Webb
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

2012-01-28 Thread Mick
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-01-28 Thread Jesús J . Guerrero Botella
2012/1/28 Mick michaelkintz...@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: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf

2012-01-28 Thread Sergei Trofimovich
 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

2012-01-28 Thread Philip Webb
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




[gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf

2012-01-28 Thread walt
On 01/27/2012 07:24 PM, Michael Mol wrote:
 On Fri, Jan 27, 2012 at 9:58 PM, Philip Webb purs...@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: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf

2012-01-28 Thread Mick
On Saturday 28 Jan 2012 10:51:23 Jesús J. Guerrero Botella wrote:
 2012/1/28 Mick michaelkintz...@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


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf

2012-01-28 Thread Mick
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 

[gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf

2012-01-28 Thread walt
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

2012-01-28 Thread Florian Philipp
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 michaelkintz...@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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf

2012-01-28 Thread Frank Steinmetzger
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

2012-01-28 Thread Philip Webb
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




[gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf

2012-01-27 Thread Philip Webb
120127 Andreas K. Huettel wrote:
 # Andreas K. Hüttel dilfri...@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: [gentoo-user] Re: [gentoo-dev-announce] Last rites: app-text/xpdf

2012-01-27 Thread Michael Mol
On Fri, Jan 27, 2012 at 9:58 PM, Philip Webb purs...@ca.inter.net wrote:
 120127 Andreas K. Huettel wrote:
 # Andreas K. Hüttel dilfri...@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