Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#13221 - Trouble opening .odt files with openoffice-base 3.0.1-1

Attached to Project: Arch Linux
Opened by Tim Weinzirl (wcentauri) - Thursday, 12 February 2009, 06:11 GMT
Last edited by Andreas Radke (AndyRTR) - Sunday, 15 February 2009, 10:02 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture i686
Severity Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I am having problems opening certain pre-existing files with Openoffice. This was tested extensively with swriter, but simpress was observed to exhibit similar behavior. New .odt files can be saved and re-opened. Old .odt files (i.e. files from last November) created with the a previous Arch build of Openoffice 3.0 do not open; attempting to do so causes Openoffice to become unresponsive and requires a force quit. The same problem is seen with recent .odt and .sxw files created by other users (e.g. with Openoffice 3.x on Windows). However, .doc files created with the Windows version of Openoffice 3 do appear to open correctly.

I tried deleting the old .openoffice* hidden directories, but this did not help.

Additional info:
Affected package: openoffice-base 3.0.1-1
As far as I know, this problem originated after the 3.0.0-4 -> 3.0.1-1 update.

Steps to reproduce:
Attempt to open a new .odt/sxw created with another Openoffice installation. Or try an old .odt file made prior to the 3.0.0-4 -> 3.0.1-1 update.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Sunday, 15 February 2009, 10:02 GMT
Reason for closing:  Not a bug
Comment by Tim Weinzirl (wcentauri) - Saturday, 14 February 2009, 06:00 GMT
This appears fixed by a system reboot. How odd!

Loading...