Summary: | app-text/xpdf-3.02-r1 - /etc/xpdfrc setting are not taking effect | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joseph <syscon780> |
Component: | Current packages | Assignee: | Printing Team <printing> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hiyuh.root, hyedad, prote |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
new ebuild
patch for bug 18223 new ebuild |
Description
Joseph
2007-11-22 20:35:53 UTC
yeah, SAMEHERE(tm). I confirmed 3.02-r1 would open(1p) system xpdfrc from wrong path. $ strace -e open xpdf MyAwesomeDocment.pdf 2>&1 | grep -e 'xpdfrc' open("/home/hiyuh/.xpdfrc", O_RDONLY) = -1 ENOENT (No such file or directory) open("xpdfrc", O_RDONLY) = -1 ENOENT (No such file or directory) So If user had his/her own ~/.xpdfrc, this bug won't appear. I've reading the source, and find retarded #ifdef craps for Windows' path support in config.h and GlobalParams.cc. And I realized to define SYSTEM_XPDFRC is a way to work around like, src_compile() { append-flags '-DSYSTEM_XPDFRC="\"/etc/xpdfrc\""' emake || die } It buzz me w/ lot of redefined warning at the compile phase, but ITJUSTWORKS(tm). Created attachment 145422 [details] new ebuild Here's a new ebuild implementing your fix. It also fixes the annoying warning of bug 18223 (following the suggestion of Evgeny there) by means of patch "xpdf-3.02-poppler-times.patch" (next attachment). Created attachment 145423 [details, diff] patch for bug 18223 (In reply to comment #1) > It buzz me w/ lot of redefined warning at the compile phase, > but ITJUSTWORKS(tm). > Forgot to mention: These warning are also produced by the unchanged xpdf-3.02-r1.ebuild. The problem is that xpdf is compiled to look for the system-wide configuration in /usr/local/etc/xpdfrc, while the gentoo ebuild puts the file at /etc/xpdfrc. So, either xpdf needs to be built to look at /etc/xpdfrc (I think this is the best solution) or the ebuild needs to put xpdfrc in /usr/local/etc. Sorry I was negligent and didn't look at the proposed ebuild, my apologies. (In reply to comment #5) > The problem is that xpdf is compiled to look for the system-wide configuration > in /usr/local/etc/xpdfrc, while the gentoo ebuild puts the file at /etc/xpdfrc. > So, either xpdf needs to be built to look at /etc/xpdfrc (I think this is the > best solution) or the ebuild needs to put xpdfrc in /usr/local/etc. > No, currently it is trying to look in /home/user/xpdfrc not /usr/local/etc/xpdfrc. But I'll agree best solution is to point an ebuild to /etc/xpdfrc (as this is where everybody is used to). Regards, Joseph You're right, Joseph. What I meant is that after it (correctly) checks for /home/user/xpdfrc, then it tries /usr/local/etc/xpdfrc instead of /etc/xpdfrc. Thanks, Noah Created attachment 184900 [details] new ebuild After upgrading to >=app-text/poppler-0.10.0 my ebuild didn't compile any more because it lacks the two new patches introduced by fixing bug 239195. Here is the new version including these patches. +*xpdf-3.02-r2 (29 Mar 2009) + + 29 Mar 2009; Peter Alfredsen <loki_val@gentoo.org> +xpdf-3.02-r2.ebuild: + Bump. Fixes bug 200023. Thanks to KIMURA Masaru / hiyuh + <hiyuh.root@gmail.com> for the fix and Joseph <syscon780@gmail.com> for + the report. + Thanks to everyone on this bug for their patience. |