[gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Alan McKinnon]

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

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Fernando Rodriguez]

[-- 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 --]

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Alan McKinnon]

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

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Fernando Rodriguez]

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

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Fernando Rodriguez]

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

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Fernando Rodriguez]

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

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Fernando Rodriguez]

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

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Alan McKinnon]

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

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Fernando Rodriguez]

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

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Alan McKinnon]

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

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Fernando Rodriguez]

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

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Fernando Rodriguez]

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

Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Alan McKinnon]

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