First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 206554
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Kevin F. Quinn (RETIRED) <kevquinn@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Antek Grzymala <awaria@chopin.edu.pl>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 206554 depends on: Show dependency tree
Show dependency graph
Bug 206554 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2008-01-18 17:27 0000
It's not necessary for acroread-8.1.x to build either
www-client/mozilla-firefox or net-libs/xulrunner (these are both very heavy
builds) as acroread can just as well use the libgtkembezmoz.so shared library
from the www-client/seamonkey-bin package (/opt/seamonkey/libgtkembedmoz.so).

There could also be some einfo telling the user how to select the correct
location of the library in his acroread preferences or maybe even a way of
setting it systemwide in some rc file. Will look into this possibility later.

I would even suggest that this library/dependency be optional, as acroread
requires it for certain optional (non-PDF) content and works more or less just
fine without it.

Reproducible: Always

Steps to Reproduce:

------- Comment #1 From Antek Grzymala 2008-01-18 17:32:39 0000 -------
(In reply to comment #0)

> There could also be some einfo telling the user how to select the correct
> location of the library in his acroread preferences or maybe even a way of
> setting it systemwide in some rc file. Will look into this possibility later.

By this I meant that current einfo is a bit vague (a user may have no idea
where to look for the library), so it would be nice if einfo provided the
library's actual location in the filesystem.

------- Comment #2 From Timo Gurr 2008-01-30 20:38:29 0000 -------
Dependencies are fixed in CVS, seamonkey(-bin) can now also be used.
I didn't change the ewarn text for now since it shouldn't happen that no
gtkembedmoz.so is installed (via dependency) and properly located by the
ebuild.

------- Comment #3 From Chad Martin 2008-02-17 20:19:31 0000 -------
While that's a great idea to reduce build times, something got broken during
implementation.  Now acroread wants to pull in seamonkey-bin even though I have
the source seamonkey package in world.

[nomerge      ] app-text/acroread-8.1.2 [7.0.9-r1] USE="cups nsplugin -ldap"
LINGUAS="en -da -de -es -fi -fr -it -ja -ko -nb -nl -pt -sv -zh_CN -zh_TW" 
[ebuild  N    ]  www-client/seamonkey-bin-1.1.8  14,435 kB 

Is it time for a new bug, or just reopen this one?

------- Comment #4 From Timo Gurr 2008-02-17 22:54:42 0000 -------
(In reply to comment #3)
> While that's a great idea to reduce build times, something got broken during
> implementation.  Now acroread wants to pull in seamonkey-bin even though I have
> the source seamonkey package in world.
> 
> [nomerge      ] app-text/acroread-8.1.2 [7.0.9-r1] USE="cups nsplugin -ldap"
> LINGUAS="en -da -de -es -fi -fr -it -ja -ko -nb -nl -pt -sv -zh_CN -zh_TW" 
> [ebuild  N    ]  www-client/seamonkey-bin-1.1.8  14,435 kB 
> 
> Is it time for a new bug, or just reopen this one?
> 

If you are on 64bit this is on purpose since acroread is 32bit it also needs a
32bit libgtkembedmoz.so in order to work as expected. And currently
seamonkey-bin is the only -bin package which provides the 32bit version of
libgtkembedmoz.so on a 64bit platform.

First Last Prev Next    No search results available      Search page      Enter new bug