Bug#732652: testing changed Icedove package
tags 732652 pending thanks On Tue, Feb 18, 2014 at 05:10:55PM +, Ximin Luo wrote: > Hey Carsten, I have just tested e22ad0 and it works fine. :) You can > mark this bug closed. And I don't even need to re-compile m-g-k. > Thanks everyone! Excellent! I send my latest patches to Christoph, he will prepare a new upload to unstable. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#732652: testing changed Icedove package
Processing commands for cont...@bugs.debian.org: > tags 732652 pending Bug #732652 [icedove] icedove does not load libraries from /usr/lib/icedove Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 732652: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732652 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732652: testing changed Icedove package
On 18/02/14 06:59, Carsten Schoenert wrote: > On Mon, Feb 17, 2014 at 08:37:34AM +0100, Carsten Schoenert wrote: >> Hello Mike, >> >> On Mon, Feb 17, 2014 at 07:20:16AM +0900, Mike Hommey wrote: >>> On Sun, Feb 16, 2014 at 04:05:33PM +0100, Carsten Schoenert wrote: @Mike Because you are deeper inside the whole source of Firefox/Thunderbird, do have a idea if the "issue" in the dependentlibs.list is a bug or do we something missing? >>> >>> My bet is that you're building with -Wl,--as-needed, and that breaks >>> thunderbird's assumptions. >> >> hmm, quite possible. ,) >> Thanks for the hint, I play around with this option. I thought Christoph >> has taken this option because you use it in Iceweasel too. Anyway, one >> build later we will know more. > > Mike, obviously you are right! Thank you! > > @Ximin, > I changed the debian/rules files an rebuild the whole packages. The > testing yesterday workes like a charm an as expected. I pushed the build > output once again to the URL I posted before. > All files with *gbpe22ad0* inside are with changed linker flags. > > I think that will be the solution. > Hey Carsten, I have just tested e22ad0 and it works fine. :) You can mark this bug closed. And I don't even need to re-compile m-g-k. Thanks everyone! X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732652: testing changed Icedove package
On Mon, Feb 17, 2014 at 08:37:34AM +0100, Carsten Schoenert wrote: > Hello Mike, > > On Mon, Feb 17, 2014 at 07:20:16AM +0900, Mike Hommey wrote: > > On Sun, Feb 16, 2014 at 04:05:33PM +0100, Carsten Schoenert wrote: > > > @Mike > > > Because you are deeper inside the whole source of Firefox/Thunderbird, > > > do have a idea if the "issue" in the dependentlibs.list is a bug or do > > > we something missing? > > > > My bet is that you're building with -Wl,--as-needed, and that breaks > > thunderbird's assumptions. > > hmm, quite possible. ,) > Thanks for the hint, I play around with this option. I thought Christoph > has taken this option because you use it in Iceweasel too. Anyway, one > build later we will know more. Mike, obviously you are right! Thank you! @Ximin, I changed the debian/rules files an rebuild the whole packages. The testing yesterday workes like a charm an as expected. I pushed the build output once again to the URL I posted before. All files with *gbpe22ad0* inside are with changed linker flags. I think that will be the solution. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732652: testing changed Icedove package
Hello Mike, On Mon, Feb 17, 2014 at 07:20:16AM +0900, Mike Hommey wrote: > On Sun, Feb 16, 2014 at 04:05:33PM +0100, Carsten Schoenert wrote: > > @Mike > > Because you are deeper inside the whole source of Firefox/Thunderbird, > > do have a idea if the "issue" in the dependentlibs.list is a bug or do > > we something missing? > > My bet is that you're building with -Wl,--as-needed, and that breaks > thunderbird's assumptions. hmm, quite possible. ,) Thanks for the hint, I play around with this option. I thought Christoph has taken this option because you use it in Iceweasel too. Anyway, one build later we will know more. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732652: testing changed Icedove package
On Sun, Feb 16, 2014 at 04:05:33PM +0100, Carsten Schoenert wrote: > @Mike > Because you are deeper inside the whole source of Firefox/Thunderbird, > do have a idea if the "issue" in the dependentlibs.list is a bug or do > we something missing? My bet is that you're building with -Wl,--as-needed, and that breaks thunderbird's assumptions. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732652: testing changed Icedove package
Hello Ximin, I have CC'ed Mike, hopefully he can give us clearing answer. On Sun, Feb 16, 2014 at 02:39:36PM +, Ximin Luo wrote: > >> Currently I have no real idea how to tweek these lines to fix the issue > >> without > >> the usage of -Wl,rpath. If you have a hint, please let us know. On the > >> other side, the rpath option doesn't break any thing. > >> > > > > I have found a much cleaner way to fix this. :) > > > > Simply insert "libldif60.so" before "libldap60.so" in > > /usr/lib/icedove/dependentlibs.list. It appears the order is > > important - for example, if you add it to the end of the file, > > icedove fails to start with "Couldn't load XPCOM". > > > > Actually, I don't think this version of icedove touches > > run-mozilla.sh at all. (In theory that file should even set > > LD_LIBRARY_PATH correctly, since it includes MOZ_DIST_BIN.) Guido and myself talked today about that issue, we are asking ourself what in detail is now different from version 17? Why do we need now to set the LD_LIBRAY_PATH or set the option for RPATH. > > I'm not sure if this dependentlibs.list thing is an upstream bug - I > > can file one there too if you think it's appropriate. > > > > Looking into this issue further, it is the case that plain icedove and > its libxul.so do not have libldif60.so as a dependency (readelf > --dynamic do not list it AFAICS), which could explain why it's not > included in dependentlibs.list. We have to check the version 17 if there is the dependency inside that file, if so I think the version 24 has a bug on that. > However, m-g-k does for some reason: > > $ readelf --dynamic > /usr/lib/xul-ext/gnome-keyring/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so > | grep ldif60 > 0x0001 (NEEDED) Shared library: [libldif60.so] > > I'm not doing anything special with the build process, so I am not > sure why ldif60 is in there. I'm pretty sure m-g-k doesn't need it - I > will see if I can build it without that dependency. > > But even if I tweak m-g-k like this, some questions still remain for > icedove/thunderbird: > > - if (the thunderbird developers) expect that no-one needs ldif60, why > keep it in the runtime directory? > - OTOH, if they do expect that (an extension) might need it, why not > include it in dependentlibs.list? There is no way for extensions to > load it dynamically, AFAIK. Thanks for figgering out this. @Mike Because you are deeper inside the whole source of Firefox/Thunderbird, do have a idea if the "issue" in the dependentlibs.list is a bug or do we something missing? Because we have to solve the RC bug depending on this bug report I think we can fix it in the first with the separate linker flag. And if this issue is related to an upstream bug we could get the transition to testing for the package Icedove* and related before Mozilla is releasing version 24.3.0+x. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732652: testing changed Icedove package
On 16/02/14 14:33, Ximin Luo wrote: > On 16/02/14 08:57, Carsten Schoenert wrote: >> On Sat, Feb 15, 2014 at 07:46:17PM +, Ximin Luo wrote: >>> (I assume 14 is a typo, you meant 24?) >> >> Indeed, of course. ;) >> >>> Perhaps a better fix would be to tweak the "intelligent" mechanism to >>> be aware of /usr/lib/icedove, then. I can understand why upstream >>> doesn't look here, since icedove is a Debian-specific name. This seems >>> to me to be a better fix than to hard-code the path by -Wl,rpath, >>> which AFAICS wasn't done before either (yet things still worked). >> >> Mhh, I don't think so, Why? >> The intelligence isn't really a intelligence. The wrapper script simple >> checks if the *.so file are symbolic links and if so set a LD_LIBRAY_PATH. >> The code part inside the script /usr/lib/icedove/run-mozilla.sh is the >> follwing part: >> >>> [snip] >> >> Currently I have no real idea how to tweek these lines to fix the issue >> without >> the usage of -Wl,rpath. If you have a hint, please let us know. On the >> other side, the rpath option doesn't break any thing. >> > > I have found a much cleaner way to fix this. :) > > Simply insert "libldif60.so" before "libldap60.so" in > /usr/lib/icedove/dependentlibs.list. It appears the order is important - for > example, if you add it to the end of the file, icedove fails to start with > "Couldn't load XPCOM". > > Actually, I don't think this version of icedove touches run-mozilla.sh at > all. (In theory that file should even set LD_LIBRARY_PATH correctly, since it > includes MOZ_DIST_BIN.) > > I'm not sure if this dependentlibs.list thing is an upstream bug - I can file > one there too if you think it's appropriate. > Looking into this issue further, it is the case that plain icedove and its libxul.so do not have libldif60.so as a dependency (readelf --dynamic do not list it AFAICS), which could explain why it's not included in dependentlibs.list. However, m-g-k does for some reason: $ readelf --dynamic /usr/lib/xul-ext/gnome-keyring/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so | grep ldif60 0x0001 (NEEDED) Shared library: [libldif60.so] I'm not doing anything special with the build process, so I am not sure why ldif60 is in there. I'm pretty sure m-g-k doesn't need it - I will see if I can build it without that dependency. But even if I tweak m-g-k like this, some questions still remain for icedove/thunderbird: - if (the thunderbird developers) expect that no-one needs ldif60, why keep it in the runtime directory? - OTOH, if they do expect that (an extension) might need it, why not include it in dependentlibs.list? There is no way for extensions to load it dynamically, AFAIK. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732652: testing changed Icedove package
On 16/02/14 08:57, Carsten Schoenert wrote: > On Sat, Feb 15, 2014 at 07:46:17PM +, Ximin Luo wrote: >> (I assume 14 is a typo, you meant 24?) > > Indeed, of course. ;) > >> Perhaps a better fix would be to tweak the "intelligent" mechanism to >> be aware of /usr/lib/icedove, then. I can understand why upstream >> doesn't look here, since icedove is a Debian-specific name. This seems >> to me to be a better fix than to hard-code the path by -Wl,rpath, >> which AFAICS wasn't done before either (yet things still worked). > > Mhh, I don't think so, Why? > The intelligence isn't really a intelligence. The wrapper script simple > checks if the *.so file are symbolic links and if so set a LD_LIBRAY_PATH. > The code part inside the script /usr/lib/icedove/run-mozilla.sh is the > follwing part: > >> [snip] > > Currently I have no real idea how to tweek these lines to fix the issue > without > the usage of -Wl,rpath. If you have a hint, please let us know. On the > other side, the rpath option doesn't break any thing. > I have found a much cleaner way to fix this. :) Simply insert "libldif60.so" before "libldap60.so" in /usr/lib/icedove/dependentlibs.list. It appears the order is important - for example, if you add it to the end of the file, icedove fails to start with "Couldn't load XPCOM". Actually, I don't think this version of icedove touches run-mozilla.sh at all. (In theory that file should even set LD_LIBRARY_PATH correctly, since it includes MOZ_DIST_BIN.) I'm not sure if this dependentlibs.list thing is an upstream bug - I can file one there too if you think it's appropriate. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732652: testing changed Icedove package
On Sat, Feb 15, 2014 at 07:46:17PM +, Ximin Luo wrote:
> (I assume 14 is a typo, you meant 24?)
Indeed, of course. ;)
> Perhaps a better fix would be to tweak the "intelligent" mechanism to
> be aware of /usr/lib/icedove, then. I can understand why upstream
> doesn't look here, since icedove is a Debian-specific name. This seems
> to me to be a better fix than to hard-code the path by -Wl,rpath,
> which AFAICS wasn't done before either (yet things still worked).
Mhh, I don't think so, Why?
The intelligence isn't really a intelligence. The wrapper script simple
checks if the *.so file are symbolic links and if so set a LD_LIBRAY_PATH.
The code part inside the script /usr/lib/icedove/run-mozilla.sh is the
follwing part:
> ##
> ## Set LD_LIBRARY_PATH
> ##
> ## On Solaris we use $ORIGIN (set in RUNPATH) instead of LD_LIBRARY_PATH
> ## to locate shared libraries.
> ##
> ## When a shared library is a symbolic link, $ORIGIN will be replaced with
> ## the real path (i.e., what the symbolic link points to) by the runtime
> ## linker. For example, if dist/bin/libxul.so is a symbolic link to
> ## toolkit/library/libxul.so, $ORIGIN will be "toolkit/library" instead of
> "dist/bin".
> ## So the runtime linker will use "toolkit/library" NOT "dist/bin" to locate
> the
> ## other shared libraries that libxul.so depends on. This only happens
> ## when a user (developer) tries to start firefox, thunderbird, or seamonkey
> ## under dist/bin. To solve the problem, we should rely on LD_LIBRARY_PATH
> ## to locate shared libraries.
> ##
> ## Note:
> ## We test $MOZ_DIST_BIN/*.so. If any of them is a symbolic link,
> ## we need to set LD_LIBRARY_PATH.
> ##
> moz_should_set_ld_library_path()
> {
> [ `uname -s` != "SunOS" ] && return 0
> for sharedlib in $MOZ_DIST_BIN/*.so
> do
> [ -h $sharedlib ] && return 0
> done
> return 1
> }
> if moz_should_set_ld_library_path
> then
>
> LD_LIBRARY_PATH=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARY_PATH:+":$LD_LIBRARY_PATH"}
> fi
>
> if [ -n "$LD_LIBRARYN32_PATH" ]
> then
>
> LD_LIBRARYN32_PATH=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARYN32_PATH:+":$LD_LIBRARYN32_PATH"}
> fi
> if [ -n "$LD_LIBRARYN64_PATH" ]
> then
>
> LD_LIBRARYN64_PATH=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARYN64_PATH:+":$LD_LIBRARYN64_PATH"}
> fi
> if [ -n "$LD_LIBRARY_PATH_64" ]; then
>
> LD_LIBRARY_PATH_64=${MOZ_DIST_BIN}:${MOZ_DIST_BIN}/plugins:${MRE_HOME}${LD_LIBRARY_PATH_64:+":$LD_LIBRARY_PATH_64"}
> fi
Currently I have no real idea how to tweek these lines to fix the issue without
the usage of -Wl,rpath. If you have a hint, please let us know. On the
other side, the rpath option doesn't break any thing.
> > So you propably right with the linker flag '-Wl,rpath". I rebuild
> > yesterday the current version 24.3.0 with this additional declaration to
> > LDFLAGS.
> > I uploaded the packages with this little change to
> >
> > http://openmct.org/misc/icedove24-test/
> >
>
> Thanks - could I ask you to sign the changes file so I can verify what I'm
> installing?
Yes, I uploaded a new gbp build with a signed dsc and changes file.
> This is an issue with icedove and not m-g-k though. I can only test,
> but I cannot attempt to fix it, since I'm not familiar with the
> icedove build system. You don't need to "know" m-g-k - it just helps
> you to verify that the bug is fixed, by confirming the absence of the
> "failed to load [..] .so" error message. You don't need to use m-g-k
> at all, you don't need to change any settings.
That's o.k. I'm in the opposite not familar with the
xul-ext-gnome-keyring package. ;)
> >> Here are the messages from icedove console:
> >>
> >> Could not read chrome manifest
> >> 'file:///usr/lib/icedove/components/components.manifest'.
> >
> > This should be also fixed in the packages from above. We have forgotten
> > to change the install declarations for this directory. Mozilla has added
> > the manifest file between version 17 and 24.
> >
> >> Failed to load native module at path
> >> '/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{6f9d85e0-794d-11dd-ad8b-0800200c9a66}/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so':
> >> (80004005) libldif60.so: cannot open shared object file: No such file or
> >> directory
> >> Could not read chrome manifest
> >> 'file:///usr/lib/icedove/extensions/%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D/chrome.manifest'.
> >> While creating services from category 'profile-after-change', could not
> >> create service for entry 'Disk Space Watcher Service', contract ID
> >> '@mozilla.org/toolkit/disk-space-watcher;1'
> >>
> >> Feel free to install xul-ext-gnome-keyring and play with it yourself.
I tested yesterday the last ID build against the simple installed
xul-ext-gnome-keyring package. I couldn't see the error me
Bug#732652: testing changed Icedove package
On 14/02/14 10:09, Carsten Schoenert wrote:
> Hello Ximin,
>
> On Wed, Feb 12, 2014 at 04:00:47PM +, Ximin Luo wrote:
>> All extensions are from the Debian repos. Actually I have disabled
>> everything except moz-g-k and the bug is still present. I'm not sure
>> how another extension could interfere with where icedove loads its
>> libs from.
>
> O.k. just want to be sure that no other installed software will causes
> some trouble.
>
>> I repeat, setting LD_LIBRARY_PATH=/usr/lib/icedove makes things work.
>> Perhaps you just forgot a -Wl,rpath during the build process?
>
> Mozilla has changed the starting wrapper for Thunderbird in version 14
> or so. They use some kind of "intelligent" mechanism to detect the used
> librarys and set a LD_LIBRARY_PATH if needed.
> But this covers just a included directory 'plugins/' and not
> /usr/lib/icedove.
>
(I assume 14 is a typo, you meant 24?)
Perhaps a better fix would be to tweak the "intelligent" mechanism to be aware
of /usr/lib/icedove, then. I can understand why upstream doesn't look here,
since icedove is a Debian-specific name. This seems to me to be a better fix
than to hard-code the path by -Wl,rpath, which AFAICS wasn't done before either
(yet things still worked).
> So you propably right with the linker flag '-Wl,rpath". I rebuild
> yesterday the current version 24.3.0 with this additional declaration to
> LDFLAGS.
> I uploaded the packages with this little change to
>
> http://openmct.org/misc/icedove24-test/
>
Thanks - could I ask you to sign the changes file so I can verify what I'm
installing?
> I checked the builded binary 'icedove' with readelf. The binarys now
> uses RUNPATH.
>
>> (pbuilder)root@jessie:~/icedove-24.3.0/debian/tmp/usr/lib/icedove# readelf
>> --dynamic icedove | grep PATH
>> 0x001d (RUNPATH)Library runpath: [/usr/lib/icedove]
>
> So I'd like to ask you if you please can test once again the Icedove
> package with mozilla-gnome-keyring?
> Unfortunately I never have used m-g-k and I'm having currently not much
> time and testing installations to play with m-g-k. I think you know your
> package much better then me and will find much quicker if it works
> correctly with this changes while the build process.
>
This is an issue with icedove and not m-g-k though. I can only test, but I
cannot attempt to fix it, since I'm not familiar with the icedove build system.
You don't need to "know" m-g-k - it just helps you to verify that the bug is
fixed, by confirming the absence of the "failed to load [..] .so" error
message. You don't need to use m-g-k at all, you don't need to change any
settings.
>> Here are the messages from icedove console:
>>
>> Could not read chrome manifest
>> 'file:///usr/lib/icedove/components/components.manifest'.
>
> This should be also fixed in the packages from above. We have forgotten
> to change the install declarations for this directory. Mozilla has added
> the manifest file between version 17 and 24.
>
>> Failed to load native module at path
>> '/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{6f9d85e0-794d-11dd-ad8b-0800200c9a66}/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so':
>> (80004005) libldif60.so: cannot open shared object file: No such file or
>> directory
>> Could not read chrome manifest
>> 'file:///usr/lib/icedove/extensions/%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D/chrome.manifest'.
>> While creating services from category 'profile-after-change', could not
>> create service for entry 'Disk Space Watcher Service', contract ID
>> '@mozilla.org/toolkit/disk-space-watcher;1'
>>
>> Feel free to install xul-ext-gnome-keyring and play with it yourself.
>
> Thanks for your interaction.
>
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
Bug#732652: testing changed Icedove package
Hello Ximin,
On Wed, Feb 12, 2014 at 04:00:47PM +, Ximin Luo wrote:
> All extensions are from the Debian repos. Actually I have disabled
> everything except moz-g-k and the bug is still present. I'm not sure
> how another extension could interfere with where icedove loads its
> libs from.
O.k. just want to be sure that no other installed software will causes
some trouble.
> I repeat, setting LD_LIBRARY_PATH=/usr/lib/icedove makes things work.
> Perhaps you just forgot a -Wl,rpath during the build process?
Mozilla has changed the starting wrapper for Thunderbird in version 14
or so. They use some kind of "intelligent" mechanism to detect the used
librarys and set a LD_LIBRARY_PATH if needed.
But this covers just a included directory 'plugins/' and not
/usr/lib/icedove.
So you propably right with the linker flag '-Wl,rpath". I rebuild
yesterday the current version 24.3.0 with this additional declaration to
LDFLAGS.
I uploaded the packages with this little change to
http://openmct.org/misc/icedove24-test/
I checked the builded binary 'icedove' with readelf. The binarys now
uses RUNPATH.
> (pbuilder)root@jessie:~/icedove-24.3.0/debian/tmp/usr/lib/icedove# readelf
> --dynamic icedove | grep PATH
> 0x001d (RUNPATH)Library runpath: [/usr/lib/icedove]
So I'd like to ask you if you please can test once again the Icedove
package with mozilla-gnome-keyring?
Unfortunately I never have used m-g-k and I'm having currently not much
time and testing installations to play with m-g-k. I think you know your
package much better then me and will find much quicker if it works
correctly with this changes while the build process.
> Here are the messages from icedove console:
>
> Could not read chrome manifest
> 'file:///usr/lib/icedove/components/components.manifest'.
This should be also fixed in the packages from above. We have forgotten
to change the install declarations for this directory. Mozilla has added
the manifest file between version 17 and 24.
> Failed to load native module at path
> '/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{6f9d85e0-794d-11dd-ad8b-0800200c9a66}/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so':
> (80004005) libldif60.so: cannot open shared object file: No such file or
> directory
> Could not read chrome manifest
> 'file:///usr/lib/icedove/extensions/%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D/chrome.manifest'.
> While creating services from category 'profile-after-change', could not
> create service for entry 'Disk Space Watcher Service', contract ID
> '@mozilla.org/toolkit/disk-space-watcher;1'
>
> Feel free to install xul-ext-gnome-keyring and play with it yourself.
Thanks for your interaction.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
