* [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
@ 2015-08-24 19:31 Alan McKinnon
2015-08-24 20:04 ` Fernando Rodriguez
2015-08-25 2:28 ` Fernando Rodriguez
0 siblings, 2 replies; 13+ messages in thread
From: Alan McKinnon @ 2015-08-24 19:31 UTC (permalink / raw
To: gentoo-user
Does anyone have an opinion to offer on bug 501468?
https://bugs.gentoo.org/show_bug.cgi?id=501468
It's been annoying me for a week now with this message:
!!! existing preserved libs:
>>> package: www-client/firefox-40.0.2
* - /usr/lib64/firefox/libmozalloc.so
* used by /usr/lib64/thunderbird/components/libdbusservice.so
(mail-client/thunderbird-38.2.0)
* used by /usr/lib64/thunderbird/components/libmozgnome.so
(mail-client/thunderbird-38.2.0)
* used by
/usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so
(mail-client/thunderbird-38.2.0)
* used by 4 other files
Both Mozilla products ship this file:
$ locate libmozalloc
/usr/lib64/firefox/libmozalloc.so
/usr/lib64/thunderbird/libmozalloc.so
and according to preserved libs, thunderbird linked to the firefox copy.
The only offered solution on the bug is to use a MASK variable, which
seems to me an ugly hammer to swat a fly.
I was wondering if there's a better way been developed in the last year.
--
Alan McKinnon
alan.mckinnon@gmail.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-08-24 19:31 [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more Alan McKinnon
@ 2015-08-24 20:04 ` Fernando Rodriguez
2015-08-24 20:42 ` Alan McKinnon
2015-08-25 2:28 ` Fernando Rodriguez
1 sibling, 1 reply; 13+ messages in thread
From: Fernando Rodriguez @ 2015-08-24 20:04 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]
On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
> Does anyone have an opinion to offer on bug 501468?
>
> https://bugs.gentoo.org/show_bug.cgi?id=501468
>
> It's been annoying me for a week now with this message:
>
> !!! existing preserved libs:
> >>> package: www-client/firefox-40.0.2
> * - /usr/lib64/firefox/libmozalloc.so
> * used by /usr/lib64/thunderbird/components/libdbusservice.so
> (mail-client/thunderbird-38.2.0)
> * used by /usr/lib64/thunderbird/components/libmozgnome.so
> (mail-client/thunderbird-38.2.0)
> * used by
> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-b5ad-
a41df1933103}/components/libcalbasecomps.so
> (mail-client/thunderbird-38.2.0)
> * used by 4 other files
>
>
> Both Mozilla products ship this file:
>
> $ locate libmozalloc
> /usr/lib64/firefox/libmozalloc.so
> /usr/lib64/thunderbird/libmozalloc.so
>
> and according to preserved libs, thunderbird linked to the firefox copy.
> The only offered solution on the bug is to use a MASK variable, which
> seems to me an ugly hammer to swat a fly.
>
> I was wondering if there's a better way been developed in the last year.
This is not a solution, but I don't have that library and I think it's because
I have the jemalloc3 flag enabled so perhaps that's a better workaround.
--
Fernando Rodriguez
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-08-24 20:04 ` Fernando Rodriguez
@ 2015-08-24 20:42 ` Alan McKinnon
2015-08-25 0:58 ` Fernando Rodriguez
0 siblings, 1 reply; 13+ messages in thread
From: Alan McKinnon @ 2015-08-24 20:42 UTC (permalink / raw
To: gentoo-user
On 24/08/2015 22:04, Fernando Rodriguez wrote:
> On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
>> Does anyone have an opinion to offer on bug 501468?
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=501468
>>
>> It's been annoying me for a week now with this message:
>>
>> !!! existing preserved libs:
>>>>> package: www-client/firefox-40.0.2
>> * - /usr/lib64/firefox/libmozalloc.so
>> * used by /usr/lib64/thunderbird/components/libdbusservice.so
>> (mail-client/thunderbird-38.2.0)
>> * used by /usr/lib64/thunderbird/components/libmozgnome.so
>> (mail-client/thunderbird-38.2.0)
>> * used by
>> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-b5ad-
> a41df1933103}/components/libcalbasecomps.so
>> (mail-client/thunderbird-38.2.0)
>> * used by 4 other files
>>
>>
>> Both Mozilla products ship this file:
>>
>> $ locate libmozalloc
>> /usr/lib64/firefox/libmozalloc.so
>> /usr/lib64/thunderbird/libmozalloc.so
>>
>> and according to preserved libs, thunderbird linked to the firefox copy.
>> The only offered solution on the bug is to use a MASK variable, which
>> seems to me an ugly hammer to swat a fly.
>>
>> I was wondering if there's a better way been developed in the last year.
>
> This is not a solution, but I don't have that library and I think it's because
> I have the jemalloc3 flag enabled so perhaps that's a better workaround.
>
>
It was worth a try, but I also have jemalloc3 in USE:
# emerge -pv thunderbird firefox
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] mail-client/thunderbird-38.2.0::gentoo USE="crypt dbus
gstreamer jemalloc3 jit ldap pulseaudio startup-notification system-icu
system-jpeg system-libvpx system-sqlite -bindist -custom-cflags
-custom-optimization -debug -gstreamer-0 -hardened -lightning -minimal
-mozdom (-selinux) -system-cairo" LINGUAS="en_GB -ar -ast -be -bg -bn_BD
-br -ca -cs -cy -da -de -el -es_AR -es_ES -et -eu -fi -fr -fy_NL -ga_IE
-gd -gl -he -hr -hsb -hu -hy_AM -id -is -it -ja -ko -lt -nb_NO -nl
-nn_NO -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -sq -sr -sv_SE
-ta_LK -tr -uk -vi -zh_CN -zh_TW" 0 KiB
[ebuild R ] www-client/firefox-40.0.2::gentoo USE="dbus
gmp-autoupdate gstreamer jemalloc3 jit pulseaudio startup-notification
system-icu system-jpeg system-libvpx system-sqlite wifi -bindist
-custom-cflags -custom-optimization -debug -egl -gstreamer-0 -hardened
-minimal (-neon) (-pgo) (-selinux) -system-cairo {-test}" LINGUAS="en_GB
en_ZA -af -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -cy -da -de
-el -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -fr -fy_NL -ga_IE
-gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km -kn -ko
-lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -or -pa_IN -pl -pt_BR -pt_PT
-rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -te -th -tr -uk -vi -xh
-zh_CN -zh_TW" 0 KiB
So that's not it.
--
Alan McKinnon
alan.mckinnon@gmail.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-08-24 20:42 ` Alan McKinnon
@ 2015-08-25 0:58 ` Fernando Rodriguez
2015-08-25 1:14 ` Fernando Rodriguez
0 siblings, 1 reply; 13+ messages in thread
From: Fernando Rodriguez @ 2015-08-25 0:58 UTC (permalink / raw
To: gentoo-user
On Monday, August 24, 2015 10:42:28 PM Alan McKinnon wrote:
> On 24/08/2015 22:04, Fernando Rodriguez wrote:
> > On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
> >> Does anyone have an opinion to offer on bug 501468?
> >>
> >> https://bugs.gentoo.org/show_bug.cgi?id=501468
> >>
> >> It's been annoying me for a week now with this message:
> >>
> >> !!! existing preserved libs:
> >>>>> package: www-client/firefox-40.0.2
> >> * - /usr/lib64/firefox/libmozalloc.so
> >> * used by /usr/lib64/thunderbird/components/libdbusservice.so
> >> (mail-client/thunderbird-38.2.0)
> >> * used by /usr/lib64/thunderbird/components/libmozgnome.so
> >> (mail-client/thunderbird-38.2.0)
> >> * used by
> >> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-b5ad-
> > a41df1933103}/components/libcalbasecomps.so
> >> (mail-client/thunderbird-38.2.0)
> >> * used by 4 other files
> >>
> >>
> >> Both Mozilla products ship this file:
> >>
> >> $ locate libmozalloc
> >> /usr/lib64/firefox/libmozalloc.so
> >> /usr/lib64/thunderbird/libmozalloc.so
> >>
> >> and according to preserved libs, thunderbird linked to the firefox copy.
> >> The only offered solution on the bug is to use a MASK variable, which
> >> seems to me an ugly hammer to swat a fly.
> >>
> >> I was wondering if there's a better way been developed in the last year.
> >
> > This is not a solution, but I don't have that library and I think it's
because
> > I have the jemalloc3 flag enabled so perhaps that's a better workaround.
> >
> >
>
>
> It was worth a try, but I also have jemalloc3 in USE:
>
> # emerge -pv thunderbird firefox
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild R ] mail-client/thunderbird-38.2.0::gentoo USE="crypt dbus
> gstreamer jemalloc3 jit ldap pulseaudio startup-notification system-icu
> system-jpeg system-libvpx system-sqlite -bindist -custom-cflags
> -custom-optimization -debug -gstreamer-0 -hardened -lightning -minimal
> -mozdom (-selinux) -system-cairo" LINGUAS="en_GB -ar -ast -be -bg -bn_BD
> -br -ca -cs -cy -da -de -el -es_AR -es_ES -et -eu -fi -fr -fy_NL -ga_IE
> -gd -gl -he -hr -hsb -hu -hy_AM -id -is -it -ja -ko -lt -nb_NO -nl
> -nn_NO -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -sq -sr -sv_SE
> -ta_LK -tr -uk -vi -zh_CN -zh_TW" 0 KiB
> [ebuild R ] www-client/firefox-40.0.2::gentoo USE="dbus
> gmp-autoupdate gstreamer jemalloc3 jit pulseaudio startup-notification
> system-icu system-jpeg system-libvpx system-sqlite wifi -bindist
> -custom-cflags -custom-optimization -debug -egl -gstreamer-0 -hardened
> -minimal (-neon) (-pgo) (-selinux) -system-cairo {-test}" LINGUAS="en_GB
> en_ZA -af -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -cy -da -de
> -el -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -fr -fy_NL -ga_IE
> -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km -kn -ko
> -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -or -pa_IN -pl -pt_BR -pt_PT
> -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -te -th -tr -uk -vi -xh
> -zh_CN -zh_TW" 0 KiB
>
>
> So that's not it.
My next guess would be the minimal use flag which I have set but you don't.
I don't know what is the sdk for..native plugin or XUL development?
Calculating dependencies... done!
[ebuild R ~] www-client/firefox-40.0.2::gentoo USE="custom-cflags custom-
optimization dbus gmp-autoupdate gstreamer jemalloc3 jit minimal pulseaudio
startup-notification system-cairo system-icu system-jpeg system-libvpx system-
sqlite -bindist -debug -egl -gstreamer-0 -hardened (-neon) (-pgo) -selinux {-
test} -wifi" LINGUAS="-af -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -
cy -da -de -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -
fr -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk
-km -kn -ko -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -or -pa_IN -pl -pt_BR -
pt_PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -te -th -tr -uk -vi -xh
-zh_CN -zh_TW" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
* IMPORTANT: 1 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
fernan@navi ~ $ equery files firefox
* Searching for firefox ...
* Contents of www-client/firefox-40.0.2:
/etc
/etc/revdep-rebuild
/etc/revdep-rebuild/10firefox
/usr
/usr/bin
/usr/bin/firefox -> /usr/lib64/firefox/firefox
/usr/lib64
/usr/lib64/firefox
/usr/lib64/firefox/application.ini
/usr/lib64/firefox/bin -> /usr/lib64/firefox
/usr/lib64/firefox/browser
/usr/lib64/firefox/browser/blocklist.xml
/usr/lib64/firefox/browser/chrome
/usr/lib64/firefox/browser/chrome.manifest
/usr/lib64/firefox/browser/chrome/icons
/usr/lib64/firefox/browser/chrome/icons/default
/usr/lib64/firefox/browser/chrome/icons/default/default16.png
/usr/lib64/firefox/browser/chrome/icons/default/default32.png
/usr/lib64/firefox/browser/chrome/icons/default/default48.png
/usr/lib64/firefox/browser/components
/usr/lib64/firefox/browser/components/components.manifest
/usr/lib64/firefox/browser/components/libbrowsercomps.so
/usr/lib64/firefox/browser/extensions
/usr/lib64/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
/usr/lib64/firefox/browser/extensions/{972ce4c6-7e08-4474-
a285-3208198ce6fd}/chrome.manifest
/usr/lib64/firefox/browser/extensions/{972ce4c6-7e08-4474-
a285-3208198ce6fd}/icon.png
/usr/lib64/firefox/browser/extensions/{972ce4c6-7e08-4474-
a285-3208198ce6fd}/install.rdf
/usr/lib64/firefox/browser/icons
/usr/lib64/firefox/browser/icons/mozicon128.png
/usr/lib64/firefox/browser/omni.ja
/usr/lib64/firefox/chrome.manifest
/usr/lib64/firefox/components
/usr/lib64/firefox/components/components.manifest
/usr/lib64/firefox/components/libdbusservice.so
/usr/lib64/firefox/components/libmozgnome.so
/usr/lib64/firefox/defaults
/usr/lib64/firefox/defaults/pref
/usr/lib64/firefox/defaults/pref/channel-prefs.js
/usr/lib64/firefox/dependentlibs.list
/usr/lib64/firefox/dictionaries
/usr/lib64/firefox/dictionaries/en-US.aff
/usr/lib64/firefox/dictionaries/en-US.dic
/usr/lib64/firefox/firefox
/usr/lib64/firefox/firefox-bin
/usr/lib64/firefox/gmp-clearkey
/usr/lib64/firefox/gmp-clearkey/0.1
/usr/lib64/firefox/gmp-clearkey/0.1/clearkey.info
/usr/lib64/firefox/gmp-clearkey/0.1/libclearkey.so
/usr/lib64/firefox/libxul.so
/usr/lib64/firefox/omni.ja
/usr/lib64/firefox/platform.ini
/usr/lib64/firefox/plugin-container
/usr/lib64/firefox/removed-files
/usr/lib64/firefox/run-mozilla.sh
/usr/lib64/firefox/webapprt
/usr/lib64/firefox/webapprt-stub
/usr/lib64/firefox/webapprt/omni.ja
/usr/lib64/firefox/webapprt/webapprt.ini
/usr/lib64/firefox/xpcom-config.h
/usr/share
/usr/share/applications
/usr/share/applications/firefox.desktop
/usr/share/icons
/usr/share/icons/hicolor
/usr/share/icons/hicolor/128x128
/usr/share/icons/hicolor/128x128/apps
/usr/share/icons/hicolor/128x128/apps/firefox.png
/usr/share/icons/hicolor/16x16
/usr/share/icons/hicolor/16x16/apps
/usr/share/icons/hicolor/16x16/apps/firefox.png
/usr/share/icons/hicolor/22x22
/usr/share/icons/hicolor/22x22/apps
/usr/share/icons/hicolor/22x22/apps/firefox.png
/usr/share/icons/hicolor/24x24
/usr/share/icons/hicolor/24x24/apps
/usr/share/icons/hicolor/24x24/apps/firefox.png
/usr/share/icons/hicolor/256x256
/usr/share/icons/hicolor/256x256/apps
/usr/share/icons/hicolor/256x256/apps/firefox.png
/usr/share/icons/hicolor/32x32
/usr/share/icons/hicolor/32x32/apps
/usr/share/icons/hicolor/32x32/apps/firefox.png
/usr/share/pixmaps
/usr/share/pixmaps/firefox.png
--
Fernando Rodriguez
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-08-25 0:58 ` Fernando Rodriguez
@ 2015-08-25 1:14 ` Fernando Rodriguez
0 siblings, 0 replies; 13+ messages in thread
From: Fernando Rodriguez @ 2015-08-25 1:14 UTC (permalink / raw
To: gentoo-user
On Monday, August 24, 2015 8:58:56 PM Fernando Rodriguez wrote:
> On Monday, August 24, 2015 10:42:28 PM Alan McKinnon wrote:
> > On 24/08/2015 22:04, Fernando Rodriguez wrote:
> > > On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
> > >> Does anyone have an opinion to offer on bug 501468?
> > >>
> > >> https://bugs.gentoo.org/show_bug.cgi?id=501468
> > >>
> > >> It's been annoying me for a week now with this message:
> > >>
> > >> !!! existing preserved libs:
> > >>>>> package: www-client/firefox-40.0.2
> > >> * - /usr/lib64/firefox/libmozalloc.so
> > >> * used by /usr/lib64/thunderbird/components/libdbusservice.so
> > >> (mail-client/thunderbird-38.2.0)
> > >> * used by /usr/lib64/thunderbird/components/libmozgnome.so
> > >> (mail-client/thunderbird-38.2.0)
> > >> * used by
> > >> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-
b5ad-
> > > a41df1933103}/components/libcalbasecomps.so
> > >> (mail-client/thunderbird-38.2.0)
> > >> * used by 4 other files
> > >>
> > >>
> > >> Both Mozilla products ship this file:
> > >>
> > >> $ locate libmozalloc
> > >> /usr/lib64/firefox/libmozalloc.so
> > >> /usr/lib64/thunderbird/libmozalloc.so
> > >>
> > >> and according to preserved libs, thunderbird linked to the firefox copy.
> > >> The only offered solution on the bug is to use a MASK variable, which
> > >> seems to me an ugly hammer to swat a fly.
> > >>
> > >> I was wondering if there's a better way been developed in the last
year.
> > >
> > > This is not a solution, but I don't have that library and I think it's
> because
> > > I have the jemalloc3 flag enabled so perhaps that's a better workaround.
> > >
> > >
> >
> >
> > It was worth a try, but I also have jemalloc3 in USE:
> >
> > # emerge -pv thunderbird firefox
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> > [ebuild R ] mail-client/thunderbird-38.2.0::gentoo USE="crypt dbus
> > gstreamer jemalloc3 jit ldap pulseaudio startup-notification system-icu
> > system-jpeg system-libvpx system-sqlite -bindist -custom-cflags
> > -custom-optimization -debug -gstreamer-0 -hardened -lightning -minimal
> > -mozdom (-selinux) -system-cairo" LINGUAS="en_GB -ar -ast -be -bg -bn_BD
> > -br -ca -cs -cy -da -de -el -es_AR -es_ES -et -eu -fi -fr -fy_NL -ga_IE
> > -gd -gl -he -hr -hsb -hu -hy_AM -id -is -it -ja -ko -lt -nb_NO -nl
> > -nn_NO -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -sq -sr -sv_SE
> > -ta_LK -tr -uk -vi -zh_CN -zh_TW" 0 KiB
> > [ebuild R ] www-client/firefox-40.0.2::gentoo USE="dbus
> > gmp-autoupdate gstreamer jemalloc3 jit pulseaudio startup-notification
> > system-icu system-jpeg system-libvpx system-sqlite wifi -bindist
> > -custom-cflags -custom-optimization -debug -egl -gstreamer-0 -hardened
> > -minimal (-neon) (-pgo) (-selinux) -system-cairo {-test}" LINGUAS="en_GB
> > en_ZA -af -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -cy -da -de
> > -el -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -fr -fy_NL -ga_IE
> > -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km -kn -ko
> > -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -or -pa_IN -pl -pt_BR -pt_PT
> > -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -te -th -tr -uk -vi -xh
> > -zh_CN -zh_TW" 0 KiB
> >
> >
> > So that's not it.
>
> My next guess would be the minimal use flag which I have set but you don't.
> I don't know what is the sdk for..native plugin or XUL development?
>
> Calculating dependencies... done!
> [ebuild R ~] www-client/firefox-40.0.2::gentoo USE="custom-cflags custom-
> optimization dbus gmp-autoupdate gstreamer jemalloc3 jit minimal pulseaudio
> startup-notification system-cairo system-icu system-jpeg system-libvpx
system-
> sqlite -bindist -debug -egl -gstreamer-0 -hardened (-neon) (-pgo) -selinux
{-
> test} -wifi" LINGUAS="-af -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs
-
> cy -da -de -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi
-
> fr -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -
kk
> -km -kn -ko -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -or -pa_IN -pl -pt_BR
-
> pt_PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -te -th -tr -uk -vi -
xh
> -zh_CN -zh_TW" 0 KiB
>
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>
> * IMPORTANT: 1 news items need reading for repository 'gentoo'.
> * Use eselect news read to view new items.
>
> fernan@navi ~ $ equery files firefox
> * Searching for firefox ...
> * Contents of www-client/firefox-40.0.2:
> /etc
> /etc/revdep-rebuild
> /etc/revdep-rebuild/10firefox
> /usr
> /usr/bin
> /usr/bin/firefox -> /usr/lib64/firefox/firefox
> /usr/lib64
> /usr/lib64/firefox
> /usr/lib64/firefox/application.ini
> /usr/lib64/firefox/bin -> /usr/lib64/firefox
> /usr/lib64/firefox/browser
> /usr/lib64/firefox/browser/blocklist.xml
> /usr/lib64/firefox/browser/chrome
> /usr/lib64/firefox/browser/chrome.manifest
> /usr/lib64/firefox/browser/chrome/icons
> /usr/lib64/firefox/browser/chrome/icons/default
> /usr/lib64/firefox/browser/chrome/icons/default/default16.png
> /usr/lib64/firefox/browser/chrome/icons/default/default32.png
> /usr/lib64/firefox/browser/chrome/icons/default/default48.png
> /usr/lib64/firefox/browser/components
> /usr/lib64/firefox/browser/components/components.manifest
> /usr/lib64/firefox/browser/components/libbrowsercomps.so
> /usr/lib64/firefox/browser/extensions
> /usr/lib64/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
> /usr/lib64/firefox/browser/extensions/{972ce4c6-7e08-4474-
> a285-3208198ce6fd}/chrome.manifest
> /usr/lib64/firefox/browser/extensions/{972ce4c6-7e08-4474-
> a285-3208198ce6fd}/icon.png
> /usr/lib64/firefox/browser/extensions/{972ce4c6-7e08-4474-
> a285-3208198ce6fd}/install.rdf
> /usr/lib64/firefox/browser/icons
> /usr/lib64/firefox/browser/icons/mozicon128.png
> /usr/lib64/firefox/browser/omni.ja
> /usr/lib64/firefox/chrome.manifest
> /usr/lib64/firefox/components
> /usr/lib64/firefox/components/components.manifest
> /usr/lib64/firefox/components/libdbusservice.so
> /usr/lib64/firefox/components/libmozgnome.so
> /usr/lib64/firefox/defaults
> /usr/lib64/firefox/defaults/pref
> /usr/lib64/firefox/defaults/pref/channel-prefs.js
> /usr/lib64/firefox/dependentlibs.list
> /usr/lib64/firefox/dictionaries
> /usr/lib64/firefox/dictionaries/en-US.aff
> /usr/lib64/firefox/dictionaries/en-US.dic
> /usr/lib64/firefox/firefox
> /usr/lib64/firefox/firefox-bin
> /usr/lib64/firefox/gmp-clearkey
> /usr/lib64/firefox/gmp-clearkey/0.1
> /usr/lib64/firefox/gmp-clearkey/0.1/clearkey.info
> /usr/lib64/firefox/gmp-clearkey/0.1/libclearkey.so
> /usr/lib64/firefox/libxul.so
> /usr/lib64/firefox/omni.ja
> /usr/lib64/firefox/platform.ini
> /usr/lib64/firefox/plugin-container
> /usr/lib64/firefox/removed-files
> /usr/lib64/firefox/run-mozilla.sh
> /usr/lib64/firefox/webapprt
> /usr/lib64/firefox/webapprt-stub
> /usr/lib64/firefox/webapprt/omni.ja
> /usr/lib64/firefox/webapprt/webapprt.ini
> /usr/lib64/firefox/xpcom-config.h
> /usr/share
> /usr/share/applications
> /usr/share/applications/firefox.desktop
> /usr/share/icons
> /usr/share/icons/hicolor
> /usr/share/icons/hicolor/128x128
> /usr/share/icons/hicolor/128x128/apps
> /usr/share/icons/hicolor/128x128/apps/firefox.png
> /usr/share/icons/hicolor/16x16
> /usr/share/icons/hicolor/16x16/apps
> /usr/share/icons/hicolor/16x16/apps/firefox.png
> /usr/share/icons/hicolor/22x22
> /usr/share/icons/hicolor/22x22/apps
> /usr/share/icons/hicolor/22x22/apps/firefox.png
> /usr/share/icons/hicolor/24x24
> /usr/share/icons/hicolor/24x24/apps
> /usr/share/icons/hicolor/24x24/apps/firefox.png
> /usr/share/icons/hicolor/256x256
> /usr/share/icons/hicolor/256x256/apps
> /usr/share/icons/hicolor/256x256/apps/firefox.png
> /usr/share/icons/hicolor/32x32
> /usr/share/icons/hicolor/32x32/apps
> /usr/share/icons/hicolor/32x32/apps/firefox.png
> /usr/share/pixmaps
> /usr/share/pixmaps/firefox.png
It looks like the workaround on the bug report is being shipped with the
firefox ebuild. See the /etc/revdep-rebuild/10firefox file on the list.
--
Fernando Rodriguez
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-08-24 19:31 [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more Alan McKinnon
2015-08-24 20:04 ` Fernando Rodriguez
@ 2015-08-25 2:28 ` Fernando Rodriguez
2015-08-25 2:48 ` Fernando Rodriguez
2015-08-25 10:30 ` Alan McKinnon
1 sibling, 2 replies; 13+ messages in thread
From: Fernando Rodriguez @ 2015-08-25 2:28 UTC (permalink / raw
To: gentoo-user
On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
> Does anyone have an opinion to offer on bug 501468?
>
> https://bugs.gentoo.org/show_bug.cgi?id=501468
>
> It's been annoying me for a week now with this message:
>
> !!! existing preserved libs:
> >>> package: www-client/firefox-40.0.2
> * - /usr/lib64/firefox/libmozalloc.so
> * used by /usr/lib64/thunderbird/components/libdbusservice.so
> (mail-client/thunderbird-38.2.0)
> * used by /usr/lib64/thunderbird/components/libmozgnome.so
> (mail-client/thunderbird-38.2.0)
> * used by
> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-b5ad-
a41df1933103}/components/libcalbasecomps.so
> (mail-client/thunderbird-38.2.0)
> * used by 4 other files
>
>
> Both Mozilla products ship this file:
>
> $ locate libmozalloc
> /usr/lib64/firefox/libmozalloc.so
> /usr/lib64/thunderbird/libmozalloc.so
>
> and according to preserved libs, thunderbird linked to the firefox copy.
> The only offered solution on the bug is to use a MASK variable, which
> seems to me an ugly hammer to swat a fly.
>
> I was wondering if there's a better way been developed in the last year.
Actually, now I have a general idea of what's going on and that sounds like an
acceptable solution but perhaps I could be better. This is what happens:
1. revdep-rebuild uses ldd to find breakage. It finds breakage in
libdbusservice.so because firefox uses tricks to preload the library from it's
directory.
2. revdep-rebuild find that thunderbird provides the library and thinks it
needs to be rebuild. (And wrongly tells you that firefox links against it).
A better way would be:
1. same as step 1 above
2. revdep-rebuild checks the package that provides the broken binary (in this
case the firefox package), if this package also provides the missing library
then it's safe to ignore the problem.
3. same as step 2 above.
Another solution is to make patch firefox to use RPATH so ldd can find the
labraries, this would also make prelink work better with firefox but it's
probably not ideal to mantain.
--
Fernando Rodriguez
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-08-25 2:28 ` Fernando Rodriguez
@ 2015-08-25 2:48 ` Fernando Rodriguez
2015-08-25 10:30 ` Alan McKinnon
1 sibling, 0 replies; 13+ messages in thread
From: Fernando Rodriguez @ 2015-08-25 2:48 UTC (permalink / raw
To: gentoo-user
On Monday, August 24, 2015 10:28:36 PM Fernando Rodriguez wrote:
> On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
> > Does anyone have an opinion to offer on bug 501468?
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=501468
> >
> > It's been annoying me for a week now with this message:
> >
> > !!! existing preserved libs:
> > >>> package: www-client/firefox-40.0.2
> > * - /usr/lib64/firefox/libmozalloc.so
> > * used by /usr/lib64/thunderbird/components/libdbusservice.so
> > (mail-client/thunderbird-38.2.0)
> > * used by /usr/lib64/thunderbird/components/libmozgnome.so
> > (mail-client/thunderbird-38.2.0)
> > * used by
> > /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-b5ad-
> a41df1933103}/components/libcalbasecomps.so
> > (mail-client/thunderbird-38.2.0)
> > * used by 4 other files
> >
> >
> > Both Mozilla products ship this file:
> >
> > $ locate libmozalloc
> > /usr/lib64/firefox/libmozalloc.so
> > /usr/lib64/thunderbird/libmozalloc.so
> >
> > and according to preserved libs, thunderbird linked to the firefox copy.
> > The only offered solution on the bug is to use a MASK variable, which
> > seems to me an ugly hammer to swat a fly.
> >
> > I was wondering if there's a better way been developed in the last year.
>
> Actually, now I have a general idea of what's going on and that sounds like
an
> acceptable solution but perhaps I could be better. This is what happens:
>
> 1. revdep-rebuild uses ldd to find breakage. It finds breakage in
> libdbusservice.so because firefox uses tricks to preload the library from
it's
> directory.
> 2. revdep-rebuild find that thunderbird provides the library and thinks it
> needs to be rebuild. (And wrongly tells you that firefox links against it).
>
> A better way would be:
>
> 1. same as step 1 above
> 2. revdep-rebuild checks the package that provides the broken binary (in
this
> case the firefox package), if this package also provides the missing library
> then it's safe to ignore the problem.
> 3. same as step 2 above.
>
> Another solution is to make patch firefox to use RPATH so ldd can find the
> labraries, this would also make prelink work better with firefox but it's
> probably not ideal to mantain.
Actually it's sort of the other way around in this case...it found breakage in
thunderbird files, but everything still applies.
--
Fernando Rodriguez
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-08-25 2:28 ` Fernando Rodriguez
2015-08-25 2:48 ` Fernando Rodriguez
@ 2015-08-25 10:30 ` Alan McKinnon
2015-08-25 17:43 ` Fernando Rodriguez
1 sibling, 1 reply; 13+ messages in thread
From: Alan McKinnon @ 2015-08-25 10:30 UTC (permalink / raw
To: gentoo-user
On 25/08/2015 04:28, Fernando Rodriguez wrote:
> On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
>> Does anyone have an opinion to offer on bug 501468?
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=501468
>>
>> It's been annoying me for a week now with this message:
>>
>> !!! existing preserved libs:
>>>>> package: www-client/firefox-40.0.2
>> * - /usr/lib64/firefox/libmozalloc.so
>> * used by /usr/lib64/thunderbird/components/libdbusservice.so
>> (mail-client/thunderbird-38.2.0)
>> * used by /usr/lib64/thunderbird/components/libmozgnome.so
>> (mail-client/thunderbird-38.2.0)
>> * used by
>> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-b5ad-
> a41df1933103}/components/libcalbasecomps.so
>> (mail-client/thunderbird-38.2.0)
>> * used by 4 other files
>>
>>
>> Both Mozilla products ship this file:
>>
>> $ locate libmozalloc
>> /usr/lib64/firefox/libmozalloc.so
>> /usr/lib64/thunderbird/libmozalloc.so
>>
>> and according to preserved libs, thunderbird linked to the firefox copy.
>> The only offered solution on the bug is to use a MASK variable, which
>> seems to me an ugly hammer to swat a fly.
>>
>> I was wondering if there's a better way been developed in the last year.
>
> Actually, now I have a general idea of what's going on and that sounds like an
> acceptable solution but perhaps I could be better. This is what happens:
>
> 1. revdep-rebuild uses ldd to find breakage. It finds breakage in
> libdbusservice.so because firefox uses tricks to preload the library from it's
> directory.
> 2. revdep-rebuild find that thunderbird provides the library and thinks it
> needs to be rebuild. (And wrongly tells you that firefox links against it).
>
> A better way would be:
>
> 1. same as step 1 above
> 2. revdep-rebuild checks the package that provides the broken binary (in this
> case the firefox package), if this package also provides the missing library
> then it's safe to ignore the problem.
> 3. same as step 2 above.
>
> Another solution is to make patch firefox to use RPATH so ldd can find the
> labraries, this would also make prelink work better with firefox but it's
> probably not ideal to mantain.
that does make sense. In my case, it's not revdep-rebuild causing
problems, it's the preserved-rebuild message at the end of emerge -v
At this level is there a difference?
--
Alan McKinnon
alan.mckinnon@gmail.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-08-25 10:30 ` Alan McKinnon
@ 2015-08-25 17:43 ` Fernando Rodriguez
2015-08-25 17:58 ` Alan McKinnon
0 siblings, 1 reply; 13+ messages in thread
From: Fernando Rodriguez @ 2015-08-25 17:43 UTC (permalink / raw
To: gentoo-user
On Tuesday, August 25, 2015 12:30:09 PM Alan McKinnon wrote:
> On 25/08/2015 04:28, Fernando Rodriguez wrote:
> > On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
> >> Does anyone have an opinion to offer on bug 501468?
> >>
> >> https://bugs.gentoo.org/show_bug.cgi?id=501468
> >>
> >> It's been annoying me for a week now with this message:
> >>
> >> !!! existing preserved libs:
> >>>>> package: www-client/firefox-40.0.2
> >> * - /usr/lib64/firefox/libmozalloc.so
> >> * used by /usr/lib64/thunderbird/components/libdbusservice.so
> >> (mail-client/thunderbird-38.2.0)
> >> * used by /usr/lib64/thunderbird/components/libmozgnome.so
> >> (mail-client/thunderbird-38.2.0)
> >> * used by
> >> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-b5ad-
> > a41df1933103}/components/libcalbasecomps.so
> >> (mail-client/thunderbird-38.2.0)
> >> * used by 4 other files
> >>
> >>
> >> Both Mozilla products ship this file:
> >>
> >> $ locate libmozalloc
> >> /usr/lib64/firefox/libmozalloc.so
> >> /usr/lib64/thunderbird/libmozalloc.so
> >>
> >> and according to preserved libs, thunderbird linked to the firefox copy.
> >> The only offered solution on the bug is to use a MASK variable, which
> >> seems to me an ugly hammer to swat a fly.
> >>
> >> I was wondering if there's a better way been developed in the last year.
> >
> > Actually, now I have a general idea of what's going on and that sounds
like an
> > acceptable solution but perhaps I could be better. This is what happens:
> >
> > 1. revdep-rebuild uses ldd to find breakage. It finds breakage in
> > libdbusservice.so because firefox uses tricks to preload the library from
it's
> > directory.
> > 2. revdep-rebuild find that thunderbird provides the library and thinks it
> > needs to be rebuild. (And wrongly tells you that firefox links against it).
> >
> > A better way would be:
> >
> > 1. same as step 1 above
> > 2. revdep-rebuild checks the package that provides the broken binary (in
this
> > case the firefox package), if this package also provides the missing
library
> > then it's safe to ignore the problem.
> > 3. same as step 2 above.
> >
> > Another solution is to make patch firefox to use RPATH so ldd can find the
> > labraries, this would also make prelink work better with firefox but it's
> > probably not ideal to mantain.
>
>
> that does make sense. In my case, it's not revdep-rebuild causing
> problems, it's the preserved-rebuild message at the end of emerge -v
>
> At this level is there a difference?
I don't know the details but it seems to me that portage either uses revdep-
rebuild to find breakage (without scanning the whole system) before deleting
the old libs for good or duplicates some of it's logic. Come to think of it,
the SEARCH_DIR_MASK may not be ideal because if I understand what it does
correctly then real breakage in firefox won't be detected.
--
Fernando Rodriguez
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-08-25 17:43 ` Fernando Rodriguez
@ 2015-08-25 17:58 ` Alan McKinnon
2015-08-25 18:56 ` Fernando Rodriguez
2015-09-24 18:12 ` Fernando Rodriguez
0 siblings, 2 replies; 13+ messages in thread
From: Alan McKinnon @ 2015-08-25 17:58 UTC (permalink / raw
To: gentoo-user
On 25/08/2015 19:43, Fernando Rodriguez wrote:
> On Tuesday, August 25, 2015 12:30:09 PM Alan McKinnon wrote:
>> On 25/08/2015 04:28, Fernando Rodriguez wrote:
>>> On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
>>>> Does anyone have an opinion to offer on bug 501468?
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=501468
>>>>
>>>> It's been annoying me for a week now with this message:
>>>>
>>>> !!! existing preserved libs:
>>>>>>> package: www-client/firefox-40.0.2
>>>> * - /usr/lib64/firefox/libmozalloc.so
>>>> * used by /usr/lib64/thunderbird/components/libdbusservice.so
>>>> (mail-client/thunderbird-38.2.0)
>>>> * used by /usr/lib64/thunderbird/components/libmozgnome.so
>>>> (mail-client/thunderbird-38.2.0)
>>>> * used by
>>>> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-b5ad-
>>> a41df1933103}/components/libcalbasecomps.so
>>>> (mail-client/thunderbird-38.2.0)
>>>> * used by 4 other files
>>>>
>>>>
>>>> Both Mozilla products ship this file:
>>>>
>>>> $ locate libmozalloc
>>>> /usr/lib64/firefox/libmozalloc.so
>>>> /usr/lib64/thunderbird/libmozalloc.so
>>>>
>>>> and according to preserved libs, thunderbird linked to the firefox copy.
>>>> The only offered solution on the bug is to use a MASK variable, which
>>>> seems to me an ugly hammer to swat a fly.
>>>>
>>>> I was wondering if there's a better way been developed in the last year.
>>>
>>> Actually, now I have a general idea of what's going on and that sounds
> like an
>>> acceptable solution but perhaps I could be better. This is what happens:
>>>
>>> 1. revdep-rebuild uses ldd to find breakage. It finds breakage in
>>> libdbusservice.so because firefox uses tricks to preload the library from
> it's
>>> directory.
>>> 2. revdep-rebuild find that thunderbird provides the library and thinks it
>>> needs to be rebuild. (And wrongly tells you that firefox links against it).
>>>
>>> A better way would be:
>>>
>>> 1. same as step 1 above
>>> 2. revdep-rebuild checks the package that provides the broken binary (in
> this
>>> case the firefox package), if this package also provides the missing
> library
>>> then it's safe to ignore the problem.
>>> 3. same as step 2 above.
>>>
>>> Another solution is to make patch firefox to use RPATH so ldd can find the
>>> labraries, this would also make prelink work better with firefox but it's
>>> probably not ideal to mantain.
>>
>>
>> that does make sense. In my case, it's not revdep-rebuild causing
>> problems, it's the preserved-rebuild message at the end of emerge -v
>>
>> At this level is there a difference?
>
> I don't know the details but it seems to me that portage either uses revdep-
> rebuild to find breakage (without scanning the whole system) before deleting
> the old libs for good or duplicates some of it's logic. Come to think of it,
> the SEARCH_DIR_MASK may not be ideal because if I understand what it does
> correctly then real breakage in firefox won't be detected.
>
My thought too. To me, SEARCH_DIR_MASK is fine for things like
/opt/skype because it's binary and either works or it doesn't, and when
it doesn't there's not much I can do about it.
It may be the least sucky of all available solutions, but it's still
swatting a fly with a hammer
--
Alan McKinnon
alan.mckinnon@gmail.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-08-25 17:58 ` Alan McKinnon
@ 2015-08-25 18:56 ` Fernando Rodriguez
2015-09-24 18:12 ` Fernando Rodriguez
1 sibling, 0 replies; 13+ messages in thread
From: Fernando Rodriguez @ 2015-08-25 18:56 UTC (permalink / raw
To: gentoo-user
On Tuesday, August 25, 2015 7:58:44 PM Alan McKinnon wrote:
> On 25/08/2015 19:43, Fernando Rodriguez wrote:
> > On Tuesday, August 25, 2015 12:30:09 PM Alan McKinnon wrote:
> >> On 25/08/2015 04:28, Fernando Rodriguez wrote:
> >>> On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
> >>>> Does anyone have an opinion to offer on bug 501468?
> >>>>
> >>>> https://bugs.gentoo.org/show_bug.cgi?id=501468
> >>>>
> >>>> It's been annoying me for a week now with this message:
> >>>>
> >>>> !!! existing preserved libs:
> >>>>>>> package: www-client/firefox-40.0.2
> >>>> * - /usr/lib64/firefox/libmozalloc.so
> >>>> * used by /usr/lib64/thunderbird/components/libdbusservice.so
> >>>> (mail-client/thunderbird-38.2.0)
> >>>> * used by /usr/lib64/thunderbird/components/libmozgnome.so
> >>>> (mail-client/thunderbird-38.2.0)
> >>>> * used by
> >>>> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-
b5ad-
> >>> a41df1933103}/components/libcalbasecomps.so
> >>>> (mail-client/thunderbird-38.2.0)
> >>>> * used by 4 other files
> >>>>
> >>>>
> >>>> Both Mozilla products ship this file:
> >>>>
> >>>> $ locate libmozalloc
> >>>> /usr/lib64/firefox/libmozalloc.so
> >>>> /usr/lib64/thunderbird/libmozalloc.so
> >>>>
> >>>> and according to preserved libs, thunderbird linked to the firefox copy.
> >>>> The only offered solution on the bug is to use a MASK variable, which
> >>>> seems to me an ugly hammer to swat a fly.
> >>>>
> >>>> I was wondering if there's a better way been developed in the last
year.
> >>>
> >>> Actually, now I have a general idea of what's going on and that sounds
> > like an
> >>> acceptable solution but perhaps I could be better. This is what happens:
> >>>
> >>> 1. revdep-rebuild uses ldd to find breakage. It finds breakage in
> >>> libdbusservice.so because firefox uses tricks to preload the library from
> > it's
> >>> directory.
> >>> 2. revdep-rebuild find that thunderbird provides the library and thinks
it
> >>> needs to be rebuild. (And wrongly tells you that firefox links against
it).
> >>>
> >>> A better way would be:
> >>>
> >>> 1. same as step 1 above
> >>> 2. revdep-rebuild checks the package that provides the broken binary (in
> > this
> >>> case the firefox package), if this package also provides the missing
> > library
> >>> then it's safe to ignore the problem.
> >>> 3. same as step 2 above.
> >>>
> >>> Another solution is to make patch firefox to use RPATH so ldd can find the
> >>> labraries, this would also make prelink work better with firefox but it's
> >>> probably not ideal to mantain.
> >>
> >>
> >> that does make sense. In my case, it's not revdep-rebuild causing
> >> problems, it's the preserved-rebuild message at the end of emerge -v
> >>
> >> At this level is there a difference?
> >
> > I don't know the details but it seems to me that portage either uses
revdep-
> > rebuild to find breakage (without scanning the whole system) before
deleting
> > the old libs for good or duplicates some of it's logic. Come to think of
it,
> > the SEARCH_DIR_MASK may not be ideal because if I understand what it does
> > correctly then real breakage in firefox won't be detected.
> >
>
> My thought too. To me, SEARCH_DIR_MASK is fine for things like
> /opt/skype because it's binary and either works or it doesn't, and when
> it doesn't there's not much I can do about it.
>
> It may be the least sucky of all available solutions, but it's still
> swatting a fly with a hammer
Maybe the bug should be filed against portage to get the right people to look
at it. The fix should be simple, just check the package with the broken binary
first. It seems to use lexical order so it finds firefox before thunderbird.
It would benefit binary packages too. You cannot rebuild skype but you can
preserve the library until the vendor releases a new binary. You would get an
endless preseved-libs loop for it but that's preferable to a broken skype.
--
Fernando Rodriguez
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-08-25 17:58 ` Alan McKinnon
2015-08-25 18:56 ` Fernando Rodriguez
@ 2015-09-24 18:12 ` Fernando Rodriguez
2015-09-25 15:30 ` Alan McKinnon
1 sibling, 1 reply; 13+ messages in thread
From: Fernando Rodriguez @ 2015-09-24 18:12 UTC (permalink / raw
To: gentoo-user
On Tuesday, August 25, 2015 7:58:44 PM Alan McKinnon wrote:
> On 25/08/2015 19:43, Fernando Rodriguez wrote:
> > On Tuesday, August 25, 2015 12:30:09 PM Alan McKinnon wrote:
> >> On 25/08/2015 04:28, Fernando Rodriguez wrote:
> >>> On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
> >>>> Does anyone have an opinion to offer on bug 501468?
> >>>>
> >>>> https://bugs.gentoo.org/show_bug.cgi?id=501468
> >>>>
> >>>> It's been annoying me for a week now with this message:
> >>>>
> >>>> !!! existing preserved libs:
> >>>>>>> package: www-client/firefox-40.0.2
> >>>> * - /usr/lib64/firefox/libmozalloc.so
> >>>> * used by /usr/lib64/thunderbird/components/libdbusservice.so
> >>>> (mail-client/thunderbird-38.2.0)
> >>>> * used by /usr/lib64/thunderbird/components/libmozgnome.so
> >>>> (mail-client/thunderbird-38.2.0)
> >>>> * used by
> >>>> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-
b5ad-
> >>> a41df1933103}/components/libcalbasecomps.so
> >>>> (mail-client/thunderbird-38.2.0)
> >>>> * used by 4 other files
> >>>>
> >>>>
> >>>> Both Mozilla products ship this file:
> >>>>
> >>>> $ locate libmozalloc
> >>>> /usr/lib64/firefox/libmozalloc.so
> >>>> /usr/lib64/thunderbird/libmozalloc.so
> >>>>
> >>>> and according to preserved libs, thunderbird linked to the firefox copy.
> >>>> The only offered solution on the bug is to use a MASK variable, which
> >>>> seems to me an ugly hammer to swat a fly.
> >>>>
> >>>> I was wondering if there's a better way been developed in the last
year.
> >>>
> >>> Actually, now I have a general idea of what's going on and that sounds
> > like an
> >>> acceptable solution but perhaps I could be better. This is what happens:
> >>>
> >>> 1. revdep-rebuild uses ldd to find breakage. It finds breakage in
> >>> libdbusservice.so because firefox uses tricks to preload the library from
> > it's
> >>> directory.
> >>> 2. revdep-rebuild find that thunderbird provides the library and thinks
it
> >>> needs to be rebuild. (And wrongly tells you that firefox links against
it).
> >>>
> >>> A better way would be:
> >>>
> >>> 1. same as step 1 above
> >>> 2. revdep-rebuild checks the package that provides the broken binary (in
> > this
> >>> case the firefox package), if this package also provides the missing
> > library
> >>> then it's safe to ignore the problem.
> >>> 3. same as step 2 above.
> >>>
> >>> Another solution is to make patch firefox to use RPATH so ldd can find the
> >>> labraries, this would also make prelink work better with firefox but it's
> >>> probably not ideal to mantain.
> >>
> >>
> >> that does make sense. In my case, it's not revdep-rebuild causing
> >> problems, it's the preserved-rebuild message at the end of emerge -v
> >>
> >> At this level is there a difference?
> >
> > I don't know the details but it seems to me that portage either uses
revdep-
> > rebuild to find breakage (without scanning the whole system) before
deleting
> > the old libs for good or duplicates some of it's logic. Come to think of
it,
> > the SEARCH_DIR_MASK may not be ideal because if I understand what it does
> > correctly then real breakage in firefox won't be detected.
> >
>
> My thought too. To me, SEARCH_DIR_MASK is fine for things like
> /opt/skype because it's binary and either works or it doesn't, and when
> it doesn't there's not much I can do about it.
>
> It may be the least sucky of all available solutions, but it's still
> swatting a fly with a hammer
I may have found a better solution. I patched my ebuild [1], but you should
be able to just add the following to LDFLAGS in /etc/portage/env:
Wl,-rpath,/usr/lib/firefox,-rpath,/usr/lib/firefox/components,-
rpath,/usr/lib/browser/components
If you do the same for thunderbird (adjusting the library dirs) you should be
able to remove the SEARCH_DIR_MASK. I also patched the ebuild not to install
that file on /etc/revdep-rebuild. If you use prelink firefox will start a little
faster on a slow machine.
You can tell if it worked by running:
# ldd /usr/lib/firefox/components/libdbusservice.so | grep libxul
It should output something like:
libxul.so => /usr/lib64/firefox/libxul.so (0x00007fcc22eb8000)
instead of:
libxul.so => not found
[1] https://github.com/fernando-rodriguez/portage-overlay/blob/master/www-client/firefox/firefox-41.0.ebuild#L254
--
Fernando Rodriguez
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
2015-09-24 18:12 ` Fernando Rodriguez
@ 2015-09-25 15:30 ` Alan McKinnon
0 siblings, 0 replies; 13+ messages in thread
From: Alan McKinnon @ 2015-09-25 15:30 UTC (permalink / raw
To: gentoo-user
On 24/09/2015 20:12, Fernando Rodriguez wrote:
> On Tuesday, August 25, 2015 7:58:44 PM Alan McKinnon wrote:
>> On 25/08/2015 19:43, Fernando Rodriguez wrote:
>>> On Tuesday, August 25, 2015 12:30:09 PM Alan McKinnon wrote:
>>>> On 25/08/2015 04:28, Fernando Rodriguez wrote:
>>>>> On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
>>>>>> Does anyone have an opinion to offer on bug 501468?
>>>>>>
>>>>>> https://bugs.gentoo.org/show_bug.cgi?id=501468
>>>>>>
>>>>>> It's been annoying me for a week now with this message:
>>>>>>
>>>>>> !!! existing preserved libs:
>>>>>>>>> package: www-client/firefox-40.0.2
>>>>>> * - /usr/lib64/firefox/libmozalloc.so
>>>>>> * used by /usr/lib64/thunderbird/components/libdbusservice.so
>>>>>> (mail-client/thunderbird-38.2.0)
>>>>>> * used by /usr/lib64/thunderbird/components/libmozgnome.so
>>>>>> (mail-client/thunderbird-38.2.0)
>>>>>> * used by
>>>>>> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-
> b5ad-
>>>>> a41df1933103}/components/libcalbasecomps.so
>>>>>> (mail-client/thunderbird-38.2.0)
>>>>>> * used by 4 other files
>>>>>>
>>>>>>
>>>>>> Both Mozilla products ship this file:
>>>>>>
>>>>>> $ locate libmozalloc
>>>>>> /usr/lib64/firefox/libmozalloc.so
>>>>>> /usr/lib64/thunderbird/libmozalloc.so
>>>>>>
>>>>>> and according to preserved libs, thunderbird linked to the firefox copy.
>>>>>> The only offered solution on the bug is to use a MASK variable, which
>>>>>> seems to me an ugly hammer to swat a fly.
>>>>>>
>>>>>> I was wondering if there's a better way been developed in the last
> year.
>>>>>
>>>>> Actually, now I have a general idea of what's going on and that sounds
>>> like an
>>>>> acceptable solution but perhaps I could be better. This is what happens:
>>>>>
>>>>> 1. revdep-rebuild uses ldd to find breakage. It finds breakage in
>>>>> libdbusservice.so because firefox uses tricks to preload the library from
>>> it's
>>>>> directory.
>>>>> 2. revdep-rebuild find that thunderbird provides the library and thinks
> it
>>>>> needs to be rebuild. (And wrongly tells you that firefox links against
> it).
>>>>>
>>>>> A better way would be:
>>>>>
>>>>> 1. same as step 1 above
>>>>> 2. revdep-rebuild checks the package that provides the broken binary (in
>>> this
>>>>> case the firefox package), if this package also provides the missing
>>> library
>>>>> then it's safe to ignore the problem.
>>>>> 3. same as step 2 above.
>>>>>
>>>>> Another solution is to make patch firefox to use RPATH so ldd can find the
>>>>> labraries, this would also make prelink work better with firefox but it's
>>>>> probably not ideal to mantain.
>>>>
>>>>
>>>> that does make sense. In my case, it's not revdep-rebuild causing
>>>> problems, it's the preserved-rebuild message at the end of emerge -v
>>>>
>>>> At this level is there a difference?
>>>
>>> I don't know the details but it seems to me that portage either uses
> revdep-
>>> rebuild to find breakage (without scanning the whole system) before
> deleting
>>> the old libs for good or duplicates some of it's logic. Come to think of
> it,
>>> the SEARCH_DIR_MASK may not be ideal because if I understand what it does
>>> correctly then real breakage in firefox won't be detected.
>>>
>>
>> My thought too. To me, SEARCH_DIR_MASK is fine for things like
>> /opt/skype because it's binary and either works or it doesn't, and when
>> it doesn't there's not much I can do about it.
>>
>> It may be the least sucky of all available solutions, but it's still
>> swatting a fly with a hammer
>
> I may have found a better solution. I patched my ebuild [1], but you should
> be able to just add the following to LDFLAGS in /etc/portage/env:
>
> Wl,-rpath,/usr/lib/firefox,-rpath,/usr/lib/firefox/components,-
> rpath,/usr/lib/browser/components
>
> If you do the same for thunderbird (adjusting the library dirs) you should be
> able to remove the SEARCH_DIR_MASK. I also patched the ebuild not to install
> that file on /etc/revdep-rebuild. If you use prelink firefox will start a little
> faster on a slow machine.
>
> You can tell if it worked by running:
>
> # ldd /usr/lib/firefox/components/libdbusservice.so | grep libxul
>
> It should output something like:
>
> libxul.so => /usr/lib64/firefox/libxul.so (0x00007fcc22eb8000)
>
> instead of:
>
> libxul.so => not found
>
>
> [1] https://github.com/fernando-rodriguez/portage-overlay/blob/master/www-client/firefox/firefox-41.0.ebuild#L254
>
Thanks, using env/ files worked a charm. @preserved-rebuild is no longer
confused.
For the record and the archives, I think you hand-typed the env strings
and got the inevitable typos. Here's what the files must be for anyone
else having the same problem. Contents on one line (mailer line wrapping
...):
# cat /etc/portage/env/mail-client/thunderbird-38.2.0
LDFLAGS="${LDFLAGS}
-Wl,-rpath,/usr/lib/thunderbird,-rpath,/usr/lib/thunderbird/components"
# cat /etc/portage/env/www-client/firefox-41.0
LDFLAGS="${LDFLAGS}
-Wl,-rpath,/usr/lib/firefox,-rpath,/usr/lib/firefox/components,-rpath,/usr/lib/firefox/browser/components"
--
Alan McKinnon
alan.mckinnon@gmail.com
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-09-25 15:31 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-24 19:31 [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more Alan McKinnon
2015-08-24 20:04 ` Fernando Rodriguez
2015-08-24 20:42 ` Alan McKinnon
2015-08-25 0:58 ` Fernando Rodriguez
2015-08-25 1:14 ` Fernando Rodriguez
2015-08-25 2:28 ` Fernando Rodriguez
2015-08-25 2:48 ` Fernando Rodriguez
2015-08-25 10:30 ` Alan McKinnon
2015-08-25 17:43 ` Fernando Rodriguez
2015-08-25 17:58 ` Alan McKinnon
2015-08-25 18:56 ` Fernando Rodriguez
2015-09-24 18:12 ` Fernando Rodriguez
2015-09-25 15:30 ` Alan McKinnon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox