Problems running GnuCash 1.9.0 on kubuntu 5.10

[Neil Williams]

On Sunday 12 February 2006 1:44 am, Aaron Larson wrote:
> Thanks, that got it.  Perhaps this is a good place to mention that I
> was pretty confused when installing the dependencies mentioned in
> http://svn.gnucash.org/trac/browser/gnucash/trunk/README.dependencies
> The packages listed in the ubuntu 5.10 section don't seem to match
> what I had to install 

If you've got a record of what you did install or just have a list of package 
names and versions from 'dpkg -l' to replace the ones that don't exist on 
Ubuntu, send them to the list as a patch for README.dependencies. I don't 
know if Ubuntu changes package names between releases - would package names 
in Breezy be any different to Dapper?

> It 
> seems like it would be "a good idea" to have a package specification,
> or an apt-get command line, or something that would retrieve the
> required packages. 

If you have an update from your own setup, send it in. The need for so many 
libg* libraries is because you're running Kubuntu which is predisposed to 
KDE, IIRC. It may merit a different section in README.dependencies compared 
to Ubuntu which may carry some of the gnome libraries by default.

Remember, gnucash has been updated to Gnome2 libraries but those are still 
Gnome libraries, not KDE ones. It will run under KDE (I do it that way) - it 
just needs some libraries, not the entire Gnome desktop.

> Pointers to such a thing would be appreciated, or 
> if it doesn't exist and its a good idea to have one, suggestions for
> what form it should take and where I could construct it are solicited.

OK. If you know which packages are different:
$ dpkg -l <package-name>
will give you what we need for that package. (that's a lower-case L if it's 
unclear.)

> Now, I think I have my first (mini) bug.  When opening a file that the
> user doesn't have read access to, the error is a bit cryptic:
>
>   The file type of file <FILENAME> is unknown.

I know how that happens - gnucash tries to identify the file by letting each 
backend try to open it in turn. If none can open it, it complains that it 
cannot understand which type of file it is meant to be. We can't use 
mimetypes to distinguish the forms (as two are text/xml and we've never 
enforced a mime-type on old files) so we do have to open the file to 
determine the type.

> Rather than some permission error. 

I think we can determine if the problem is the wrong type or the wrong 
permissions - probably by trying a fopen() fclose() prior to trying to 
determine the type.

The best thing is to submit this to Bugzilla.

> It had me thinking I missed some 
> upgrade note or something indicating the file format had changed.  I
> couldn't find a reference to this in Bugzilla.  Is this sort of thing
> considered "bug worthy"?

Yes. If error messages are not helpful or actually misleading, that is a bug.
(normal severity).

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060212/79c72eab/attachment.bin