Did the submitter log out and then log back in again after install openoffice?

Shouldn't need to log out, but I believe this is one of those
things where we needs an smf service that rebuilds the mime type
db after installing openoffice and an ips action that restarts
that service.

*** Bug 805 has been marked as a duplicate of this bug. ***

Will fix this for now but delivering static versions of /etc/mailcap and
/etc/mime.types with the correct contents.

I had originally thought this could be addressed by delivering correct versions
of /etc/mailcap and /etc/mime.types but that's not going to work. 
Recategorizing back to the desktop component.

The most likely problem here is that the call to update-mime-database, which is
normally done as a postinstall action, via postrun,  is not being run.

Could you please try running this manually and then re-running the tests?

update-mime-database manually worked fine as indicated in #805. Something wrong
with the post-install scripts no doubt. David, this might be something to check
in the import. (I'll see if I can have a quick check myself)

This and other similar issues are discussed in this thread:
http://mail.opensolaris.org/pipermail/pkg-discuss/2008-April/002625.html

*** Bug 1860 has been marked as a duplicate of this bug. ***

Laca sent me some email on this. I'm adding the details
to this bug so that they don't get lost and (hopefully) 
the current status is recorded.

  "This is done.  We have a package called SUNWdesktop-cache
   that includes a number of SMF services for updating various
   GNOME caches.

   Unfortunately, IPS cannot yet restart these services
   automatically when needed, so users need to reboot or manually
   restart the SMF services for these to kick in.

   Note: I haven't verified that this specific bug is really
   fixed, but the proposed solution is implemented."

Note that this package is not in the WOS. It's integrated directly 
into the OpenSolaris dock.

The associated services are:

$ svcs -a  | grep desktop-cache
online          9:40:34 svc:/application/desktop-cache/mime-types-cache:default
online          9:40:35
svc:/application/desktop-cache/desktop-mime-cache:default
online          9:40:35 svc:/application/desktop-cache/gconf-cache:default
online          9:40:36
svc:/application/desktop-cache/input-method-cache:default
online          9:40:36
svc:/application/desktop-cache/pixbuf-loaders-installer:default
online          9:41:07 svc:/application/desktop-cache/icon-cache:default

I think with all this information, we can progress the bug status
to at least FIXUNDERSTOOD.

I've been putting together the package clusters for OpenOffice.org 3.0.
The new openoffice package looks something like:

package openoffice
description "OpenOffice.org 3.0"
version 3.0
import ooobasis30-base
import ooobasis30-binfilter
import ooobasis30-calc
...
import openofficeorg30-desktop-int
...
import openofficeorg-ure
end package

I've noticed that the SVR4 openofficeorg30-desktop-int package has:

1 e build etc/mime.types 0644 root bin 2546 50805 1216224190

in its pkgmap file. This is an OpenOffice.org specific shell script
(see http://defect.opensolaris.org/bz/show_bug.cgi?id=1860 )

With the solution proposed in this bug, should a line be added to
the new openoffice definition after the import for 
openofficeorg30-desktop-int to

drop etc/mime.types

?

The SVR4 edit script should clearly not be installed "as is". I also doubt that
the entries in /etc/mime.types it creates are necessary any more (at least as
long as the ODF mime types are known to gnome-vfs), so this line can be dropped
without replacement. 

Isn't there a similar one for /etc/mailcap ?

(In reply to comment #12)
> The SVR4 edit script should clearly not be installed "as is". I also doubt that
> the entries in /etc/mime.types it creates are necessary any more (at least as
> long as the ODF mime types are known to gnome-vfs), so this line can be dropped
> without replacement. 

Okay.

> Isn't there a similar one for /etc/mailcap ?

Yes:

.../openofficeorg30-desktop-int/pkgmap:

1 e build etc/mailcap 0644 root bin 3270 30386 1210842750

That'll need to be dropped to. I'll do this (for both of them as part of
bug #2198).

Thanks.

I believe there is still some value to delivering these entries via
/etc/mailcap and /etc/mime.types as well for other programs that look for MIME
information there (some of the ASCII-based mailers for example use that).

Created an attachment (id=682) [details]
Proposed patch to add /etc/mailcap and /etc/mime.types

This also includes the fix for bug #956 (add symbolic
links into /usr/share/applications for the three Java
Web Start .desktop files).

Fix generated, webrev created and copied to cr.opensolaris.org
and request for review posted. 

See:
http://mail.opensolaris.org/pipermail/pkg-discuss/2008-October/007912.html

Changing status to FIXINPROGRESS.

Fixed in changeset 25d00c5514ac1add90fb3b763d16ee7c484cc640

Verified on RC1b build.

Created an attachment (id=830) [details]
Archive Manager error dialog

Note, I still get the Archive Manager when testing this myself in RC1.

(In reply to comment #19)
> Created an attachment (id=830) [details] [details]
> Archive Manager error dialog
> 
> Note, I still get the Archive Manager when testing this myself in RC1.

Could you give me step-by-step instructions on what you are doing?

Thanks.

Staring with a clean install of OpenSolaris 2008.11 RC1 in VirtualBox:

1) pfexec pkg install openoffice
2) Browse to an Open Office document and double-click it (I accessed the Open
Office document on my Mac OS host via a smb share). In this case it was an .odp
file.

(In reply to comment #21)
> Staring with a clean install of OpenSolaris 2008.11 RC1 in VirtualBox:
> 
> 1) pfexec pkg install openoffice
> 2) Browse to an Open Office document and double-click it (I accessed the Open
> Office document on my Mac OS host via a smb share). In this case it was an .odp
> file.

I don't have Virtualbox installed and running OpenSolaris (mine's native),
but hopefully that shouldn't make a difference. I was able to successfully
start OpenOffice (Impress) for a sample.odp file both when browsing with
Nautilus (double-clicking automatically started up OOo) and browsing with
Firefox (it bought up a popup asking me if i wanted to Open this document
using OOo Impress).

Here are some things to check for:

1/ What version of OpenOffice is installed on your system?

   $ pfexec pkg info openoffice

2/ Do you have /etc/mime.types installed on your system and if so, what
   does it look like?

3/ Do you have /usr/share/mime/types on your system and what does it look like?

Thanks.

Created an attachment (id=833) [details]
user/share/mine/types file

bleonard@opensolaris:~$ pkg info openoffice
          Name: openoffice
       Summary: OpenOffice.org 3.0.0
         State: Installed
     Authority: opensolaris.org
       Version: 3.0.0
 Build Release: 5.11
        Branch: 0.86
Packaging Date: Tue Nov  4 05:21:46 2008
          Size: 390.05 MB
          FMRI: pkg:/openoffice@3.0.0,5.11-0.86:20081104T052146Z


bleonard@opensolaris:~$ cat /etc/mime.types 
#--Netscape Communications Corporation MIME Information
#Do not delete the above line. It is used to identify the file type.
#mime types added by Netscape Helper
type=application/x-java-jnlp-file desc="Java Web Start" exts="jnlp"
application/vnd.oasis.opendocument.text odt
application/vnd.oasis.opendocument.text-template ott
application/vnd.oasis.opendocument.text-web oth
application/vnd.oasis.opendocument.text-master odm
application/vnd.oasis.opendocument.graphics odg
application/vnd.oasis.opendocument.graphics-template otg
application/vnd.oasis.opendocument.presentation odp
application/vnd.oasis.opendocument.presentation-template otp
application/vnd.oasis.opendocument.spreadsheet ods
application/vnd.oasis.opendocument.spreadsheet-template ots
application/vnd.oasis.opendocument.chart odc
application/vnd.oasis.opendocument.formula odf
application/vnd.oasis.opendocument.image odi
application/vnd.sun.xml.writer sxw
application/vnd.sun.xml.writer.template stw
application/vnd.sun.xml.writer.global sxg
application/vnd.stardivision.writer sdw vor
application/vnd.stardivision.writer-global sgl
application/vnd.sun.xml.calc sxc
application/vnd.sun.xml.calc.template stc
application/vnd.stardivision.calc sdc
application/vnd.stardivision.chart sds
application/vnd.sun.xml.impress sxi
application/vnd.sun.xml.impress.template sti
application/vnd.stardivision.impress sdd sdp
application/vnd.sun.xml.draw sxd
application/vnd.sun.xml.draw.template std
application/vnd.stardivision.draw sda
application/vnd.sun.xml.math sxm
application/vnd.stardivision.math smf
application/vnd.sun.xml.base odb
application/vnd.openofficeorg.extension oxt
application/vnd.openxmlformats-officedocument.wordprocessingml.document docx
application/vnd.ms-word.document.macroenabled.12 docm
application/vnd.openxmlformats-officedocument.wordprocessingml.template dotx
application/vnd.ms-word.template.macroenabled.12 dotm
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet xlsx
application/vnd.ms-excel.sheet.macroenabled.12 xlsm
application/vnd.openxmlformats-officedocument.spreadsheetml.template xltx
application/vnd.ms-excel.template.macroenabled.12 xltm
application/vnd.openxmlformats-officedocument.presentationml.presentation pptx
application/vnd.ms-powerpoint.presentation.macroenabled.12 pptm
application/vnd.openxmlformats-officedocument.presentationml.template potx
application/vnd.ms-powerpoint.template.macroenabled.12 potm

/usr/share/mime/types is attached.

Note, I am also running OpenSolaris natively. However, I also install
OpenSolaris in VirtualBox (on OpenSolaris) to give me a clean base to test
from. Two separate tests have lead to the same result.

Regards,
Brian

Well I have the following differences in my /usr/share/mime/types then
yours:

diff -c /usr/share/mime/types ~/Desktop/bug-1225-types 
*** /usr/share/mime/types    Tue Oct 28 11:23:20 2008
--- /export/home/richb/Desktop/bug-1225-types    Tue Nov 11 14:18:19 2008
***************
*** 38,52 ****
  application/vnd.mozilla.xul+xml
  application/vnd.ms-access
  application/vnd.ms-excel
- application/vnd.ms-excel.sheet.binary.macroenabled.12
- application/vnd.ms-excel.sheet.macroenabled.12
- application/vnd.ms-excel.template.macroenabled.12
  application/vnd.ms-powerpoint
- application/vnd.ms-powerpoint.presentation.macroenabled.12
- application/vnd.ms-powerpoint.template.macroenabled.12
  application/vnd.ms-tnef
- application/vnd.ms-word.document.macroenabled.12
- application/vnd.ms-word.template.macroenabled.12
  application/vnd.ms-works
  application/vnd.ms-xpsdocument
  application/vnd.oasis.opendocument.chart
--- 38,45 ----
***************
*** 64,75 ****
  application/vnd.oasis.opendocument.text-template
  application/vnd.oasis.opendocument.text-web
  application/vnd.openofficeorg.extension
- application/vnd.openxmlformats-officedocument.presentationml.presentation
- application/vnd.openxmlformats-officedocument.presentationml.template
- application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
- application/vnd.openxmlformats-officedocument.spreadsheetml.template
- application/vnd.openxmlformats-officedocument.wordprocessingml.document
- application/vnd.openxmlformats-officedocument.wordprocessingml.template
  application/vnd.rn-realmedia
  application/vnd.stardivision.calc
  application/vnd.stardivision.chart
--- 57,62 ----
***************
*** 78,84 ****
  application/vnd.stardivision.mail
  application/vnd.stardivision.math
  application/vnd.stardivision.writer
- application/vnd.sun.xml.base
  application/vnd.sun.xml.calc
  application/vnd.sun.xml.calc.template
  application/vnd.sun.xml.draw
--- 65,70 ----

But apart from that, the versions/types match.

I think it's time for some of the others cc:'ed on this bug to provide
feedback because I'm unable to reproduce the problem.

Thanks.

Brian, can you please execute

pfexec /usr/bin/update-mime-database /usr/share/mime 

and see whether it makes any difference ? At least I would expect
/usr/share/mime/types to differ from what you had before.

Reading through the comments, is it expected that OpenSolaris will have to be
rebooted before the association will work? After a reboot my association works
fine. It's only after a fresh installation of OpenOffice (without a reboot)
that it doesn't work.

(In reply to comment #26)
> Reading through the comments, is it expected that OpenSolaris will have to be
> rebooted before the association will work? After a reboot my association works
> fine. It's only after a fresh installation of OpenOffice (without a reboot)
> that it doesn't work.

If you've got RC1, then at the moment I think it needs a reboot to get
those associations in place. Bart checked in the fix for this (see bug #4660)
on the 10th November, so that should show up in the next RC candidate.

Excellent. Sorry for the trouble. I'll retest when RC2 becomes available.

On fresh installed rc2 build, after installing OpenOffice, still need reboot
machine to get the association work.

(In reply to comment #29)
> On fresh installed rc2 build, after installing OpenOffice, still need reboot
> machine to get the association work.

Bart responded to this in bug #4660

"I don't think we've pushed a new version of openoffice since I put this
back...."

: barts@cyber[59]; pkg contents -m -r openoffice | egrep restart
: barts@cyber[60];

I installed the new openoffice, but still can not open a openoffice document
without reboot the system. Does any one else see this or I missed anything?

(In reply to comment #31)
> I installed the new openoffice, but still can not open a openoffice document
> without reboot the system. Does any one else see this or I missed anything?

A new bug has just been opened for this part of the problem. See bug #5385.