gnucash crashed with ImportError in /usr/share/gnucash/python/ No module named gnucash

Bug #1369273 reported by Reinhard Tartler on 2014-09-14
This bug affects 21 people
Affects Status Importance Assigned to Milestone
gnucash (Debian)
Fix Released
gnucash (Ubuntu)

Bug Description

just starting gnucash

ProblemType: Crash
DistroRelease: Ubuntu 14.10
Package: gnucash 1:2.6.3-1build1
ProcVersionSignature: Ubuntu 3.16.0-14.20-generic 3.16.2
Uname: Linux 3.16.0-14-generic x86_64
ApportVersion: 2.14.7-0ubuntu2
Architecture: amd64
CrashCounter: 1
CurrentDesktop: Unity
Date: Sun Sep 14 10:11:01 2014
ExecutablePath: /usr/bin/gnucash
ProcCmdline: gnucash
SourcePackage: gnucash
Title: gnucash crashed with ImportError in /usr/share/gnucash/python/ No module named gnucash
 Traceback (most recent call last):
   File "/usr/share/gnucash/python/", line 3, in <module>
     from gnucash import *
 ImportError: No module named gnucash
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm admin cdrom dialout fuse libvirtd lpadmin plugdev sambashare sbuild sudo

Reinhard Tartler (siretart) wrote :
Reinhard Tartler (siretart) wrote :

this problem disappears after installing the "python-gnucash" package

tags: removed: need-duplicate-check
Changed in gnucash (Ubuntu):
importance: Undecided → Medium
information type: Private → Public
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnucash (Ubuntu):
status: New → Confirmed
Tin Tvrtkovic (tinchester) wrote :

Can confirm this happens to me when starting Gnucash since the upgrade to Utopic. Gnucash starts up normally though, but apport claims Gnucash has crashed. Can confirm installing python-gnucash solves it.

Should we just add python-gnucash as a dependency to the gnucash package?

Scott Holmes (scottholmes) wrote :

I have the same problem and I installed python-gnucash. It still crashes but with new errors:

In ice-9/boot-9.scm:
 157: 16 [catch #t #<catch-closure cefa20> ...]
In unknown file:
   ?: 15 [apply-smob/1 #<catch-closure cefa20>]
In ice-9/boot-9.scm:
3597: 14 [process-use-modules (((gnucash price-quotes)))]
 702: 13 [map #<procedure c8dee0 at ice-9/boot-9.scm:3597:25 (mif-args)> ((#))]
3598: 12 [#<procedure c8dee0 at ice-9/boot-9.scm:3597:25 (mif-args)> (#)]
2864: 11 [resolve-interface (gnucash price-quotes) #:select ...]
2789: 10 [#<procedure c80800 at ice-9/boot-9.scm:2777:4 (name #:optional autoload version #:key ensure)> # ...]
3065: 9 [try-module-autoload (gnucash price-quotes) #f]
2401: 8 [save-module-excursion #<procedure 1384b70 at ice-9/boot-9.scm:3066:17 ()>]
3085: 7 [#<procedure 1384b70 at ice-9/boot-9.scm:3066:17 ()>]
In unknown file:
   ?: 6 [primitive-load-path "gnucash/price-quotes" ...]
In gnucash/price-quotes.scm:
  41: 5 [#<procedure 16155a0 ()>]
In ice-9/boot-9.scm:
3597: 4 [process-use-modules (((www main)))]
 702: 3 [map #<procedure c8dee0 at ice-9/boot-9.scm:3597:25 (mif-args)> ((#))]
3598: 2 [#<procedure c8dee0 at ice-9/boot-9.scm:3597:25 (mif-args)> ((www main))]
2867: 1 [resolve-interface (www main) #:select ...]
In unknown file:
   ?: 0 [scm-error misc-error #f "~A ~S" ("no code for module" (www main)) #f]

ERROR: In procedure scm-error:
ERROR: no code for module (www main)

Tin Tvrtkovic (tinchester) wrote :

I've come to find that installing python-gnucash, while helping with startup, will actually make Gnucash lock up when quitting. I'm back to not having python-gnucash installed.

dardhal (ubuntu-24x7linux) wrote :
Download full text (7.1 KiB)

This has been affecting me since upgrading to 14.10 the other day. I did some testing, to rule out anything related to the user running the application, or the data file being used (goes back more a decade worth of transactions).

So I created a fresh new user and ran gnucash from the command line with core dumping enabled. gnucash started fine after lots of first-time initializations (as shown in the console output, due to GUILE_AUTO_COMPILE set to on).

Just after gnucash completed startup, I quitted the application from the menu. It got into a somewhat lengthy wait (10-20 seconds), to end up dumping core. A simple run of the core file through gdb shows as follows:
$ gdb /usr/bin/gnucash core
GNU gdb (Ubuntu 7.8-1ubuntu4)
Reading symbols from /usr/bin/gnucash...(no debugging symbols found)...done.
[New LWP 12161]
[New LWP 12168]
[New LWP 12162]
[New LWP 12169]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/".
Core was generated by `gnucash'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xa4a3d649 in dbi_shutdown_r () from /usr/lib/i386-linux-gnu/
(gdb) thread apply all bt

Thread 4 (Thread 0xa5d49b40 (LWP 12169)):
#0 0xb76f0c7c in __kernel_vsyscall ()
#1 0xb6adfd6b in poll () at ../sysdeps/unix/syscall-template.S:81
#2 0xb6c1fe80 in g_poll () from /lib/i386-linux-gnu/
#3 0xb6c10eb4 in ?? () from /lib/i386-linux-gnu/
#4 0xb6c10ff6 in g_main_context_iteration () from /lib/i386-linux-gnu/
#5 0xb6c11050 in ?? () from /lib/i386-linux-gnu/
#6 0xb6c380ba in ?? () from /lib/i386-linux-gnu/
#7 0xb6bb3f16 in start_thread (arg=0xa5d49b40) at pthread_create.c:309
#8 0xb6aea9ae in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129

Thread 3 (Thread 0xb014db40 (LWP 12162)):
#0 0xb76f0c7c in __kernel_vsyscall ()
#1 0xb6adfd6b in poll () at ../sysdeps/unix/syscall-template.S:81
#2 0xb6c1fe80 in g_poll () from /lib/i386-linux-gnu/
#3 0xb6c10eb4 in ?? () from /lib/i386-linux-gnu/
#4 0xb6c10ff6 in g_main_context_iteration () from /lib/i386-linux-gnu/
#5 0xb015448b in ?? () from /usr/lib/i386-linux-gnu/gio/modules/
#6 0xb6c380ba in ?? () from /lib/i386-linux-gnu/
#7 0xb6bb3f16 in start_thread (arg=0xb014db40) at pthread_create.c:309
#8 0xb6aea9ae in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129

Thread 2 (Thread 0xaf6f0b40 (LWP 12168)):
#0 0xb76f0c7c in __kernel_vsyscall ()
#1 0xb6adfd6b in poll () at ../sysdeps/unix/syscall-template.S:81
#2 0xb6c1fe80 in g_poll () from /lib/i386-linux-gnu/
#3 0xb6c10eb4 in ?? () from /lib/i386-linux-gnu/
#4 0xb6c112d9 in g_main_loop_run () from /lib/i386-linux-gnu/
#5 0xb63b46f5 in ?? () from /usr/lib/i386-linux-gnu/
#6 0xb6c380ba in ?? () from /lib/i386-linux-gnu/
#7 0xb6bb3f16 in start_thread (arg=0xaf6f0b40) at pthread_create.c:309
#8 0xb6aea9ae in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129

Thread 1 (Thread 0...


dardhal (ubuntu-24x7linux) wrote :

Adding to my last comment (#7), now I had to enter some additional transactions to gnucash, even after crashing on shutdown as described, transactions seem to be kept open fine, and on further startup, the application doesn't complain about the lock file being in use, so it looks like the crash takes place at the very end of the shutdown process, and other than the crash, nothing bad seems to be happening behind the scenes.

dardhal (ubuntu-24x7linux) wrote :
Download full text (3.9 KiB)

Some more details. This is the latest output from "strace" as running against an existing gnucash process, just before hitting the "File->Quit" option:
[pid 13334] 17:18:16 open("/home/username/.gnucash/expressions-2.0", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 14
[pid 13334] 17:18:16 write(14, "", 0) = 0
[pid 13334] 17:18:16 close(14) = 0
[pid 13334] 17:18:16 open("/home/username/.gnucash/stylesheets-2.0", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 14
[pid 13334] 17:18:16 fcntl64(14, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE)
[pid 13334] 17:18:16 _llseek(14, 0, [0], SEEK_CUR) = 0
[pid 13334] 17:18:16 fstat64(14, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
[pid 13334] 17:18:16 write(14, "(let ((template (gnc:html-style-sheet-template-find \"Plain\")))\n (if template \n (let ((options ((gnc:html-style-sheet-template-options-generator template)))) \n\n; Section: Tables\n\n\n; Section: General\n\n\n; Section: Fonts\n\n(let ((option (gnc:lookup-option options\n \"Fonts\"\n \"Text cell\")))\n ((lambda (option) (if option ((gnc:option-setter option) \"Ubuntu 9\"))) option))\n\n(let ((option (gnc:lookup-option options\n \"Fonts\"\n \"Number header\")))\n ((lambda (option) (if option ((gnc:option-setter option) \"Ubuntu 9\"))) option))\n\n(let ((option (gnc:lookup-option options\n \"Fonts\"\n \"Account link\")))\n ((lambda (option) (if option ((gnc:option-setter option) \"Ubuntu Italic 9\"))) option))\n\n(let ((option (gnc:lookup-option options\n \"Fonts\"\n \"Number cell\")))\n ((lambda (optio"..., 3954) = 3954
[pid 13334] 17:18:16 close(14) = 0
[pid 13334] 17:18:16 close(3) = 0
[pid 13334] 17:18:16 munmap(0xb7430000, 4096) = 0
[pid 13334] 17:18:16 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x9aa0740} ---
[pid 13336] 17:18:16 <... poll resumed> ) = ? <unavailable>
[pid 13348] 17:18:47 +++ killed by SIGSEGV (core dumped) +++
[pid 13336] 17:18:47 +++ killed by SIGSEGV (core dumped) +++
[pid 13335] 17:18:47 +++ killed by SIGSEGV (core dumped) +++
17:18:47 +++ killed by SIGSEGV (core dumped) +++

FD number 3 happened to be:
gnucash 13334 username 3u REG 8,3 176 2490542 /tmp/gnucash.trace
And the referred file contents were as follows after the crash on shutdown:
$ cat /tmp/gnucash.trace
* 17:12:12 WARN <gnc.backend.dbi> [gnc_module_init_backend_dbi()] No DBD drivers found
* 17:12:33 WARN <gnc.backend.dbi> [gnc_module_init_backend_dbi()] No DBD drivers found

That seems to match quite well the crash on dbi_shutdown_r reported earlier on, so despite only logging a WARNING, the root cause for the crash on shutdown may lay there.

So I took one additional step: trying to provide gnucash with some valid libDBI implementation for DB backends. Prior to that, I only had the following installed regarding DBI:
$ dpkg --get-selections | grep dbi


Brad (mrbradgray) wrote :

Installing both packages reported by dardhal has fixed my crashing problems. I would suggest both be flagged as dependencies.

dardhal (ubuntu-24x7linux) wrote :

And for whatever reason, without having changed anything at all (at least, intentionally, gnucash resumes crashing on shutdown, but this time it looks a bit different, or maybe not):
  Installed: 1:2.6.3-1build1

Program received signal SIGSEGV, Segmentation fault.
0xa631d649 in dbi_shutdown_r () from /usr/lib/i386-linux-gnu/
(gdb) bt
#0 0xa631d649 in dbi_shutdown_r () from /usr/lib/i386-linux-gnu/
#1 0xa631d6dd in dbi_shutdown () from /usr/lib/i386-linux-gnu/
#2 0xa63322f4 in gnc_module_finalize_backend_dbi () from /usr/lib/i386-linux-gnu/gnucash/gnucash/
#3 0xa6332314 in qof_backend_module_finalize () from /usr/lib/i386-linux-gnu/gnucash/gnucash/
#4 0xb7c9fb79 in qof_finalize_backend_libraries () from /usr/lib/i386-linux-gnu/gnucash/
#5 0xb7cb03e5 in qof_close () from /usr/lib/i386-linux-gnu/gnucash/
#6 0xb7d32469 in gnc_engine_shutdown () from /usr/lib/i386-linux-gnu/gnucash/gnucash/
#7 0xb7e8dfef in gnc_shutdown () from /usr/lib/i386-linux-gnu/gnucash/gnucash/
#8 0xb7b3b38d in ?? () from /usr/lib/
#9 0xb7b11dfd in ?? () from /usr/lib/
#10 0xb7b9b8e7 in ?? () from /usr/lib/
#11 0xb7b74fb9 in ?? () from /usr/lib/
#12 0xb7bb3f20 in ?? () from /usr/lib/
#13 0xb7bb4539 in ?? () from /usr/lib/
#14 0xb7b1c4f3 in scm_call_4 () from /usr/lib/
#15 0xb7b9bacf in scm_catch_with_pre_unwind_handler () from /usr/lib/
#16 0xb7b9bbd4 in scm_c_catch () from /usr/lib/
#17 0xb7b125d1 in ?? () from /usr/lib/
#18 0xb7b126d3 in scm_c_with_continuation_barrier () from /usr/lib/
#19 0xb7b98f7e in ?? () from /usr/lib/
#20 0xb69c92c1 in GC_call_with_stack_base () from /usr/lib/i386-linux-gnu/
#21 0xb7b993e6 in scm_with_guile () from /usr/lib/
#22 0xb7b3b5dc in scm_boot_guile () from /usr/lib/
#23 0x08049f06 in main ()

A. Eibach (andi3) wrote :

This is for 2.6.3.

Wish I knew why 2.6.4 has been released _without_ fixing this "No module" bug.

dardhal (ubuntu-24x7linux) wrote :
Download full text (4.4 KiB)

So this is how things _seem_ to go for this Bug:
(gdb) bt
#0 0xa62c5649 in dbi_shutdown_r () from /usr/lib/i386-linux-gnu/
#1 0xa62c56dd in dbi_shutdown () from /usr/lib/i386-linux-gnu/
#2 0xa62da2f4 in gnc_module_finalize_backend_dbi () from /usr/lib/i386-linux-gnu/gnucash/gnucash/
#3 0xa62da314 in qof_backend_module_finalize () from /usr/lib/i386-linux-gnu/gnucash/gnucash/
#4 0xb7c9fb79 in qof_finalize_backend_libraries () from /usr/lib/i386-linux-gnu/gnucash/

- In frame #4 some Gnucash library function is called without any arguments:
253 void
254 qof_finalize_backend_libraries(void)
255 {
256 GSList* node;
257 GModule* backend;
258 void (*module_finalize_func) (void);
260 for (node = backend_module_list; node != NULL; node = node->next)
261 {
262 backend = (GModule*)node->data;
264 if (g_module_symbol(backend, "qof_backend_module_finalize",
265 (gpointer)&module_finalize_func))
266 module_finalize_func();
268 }
269 }

- This seems to call a formerly registered function by the name of "qof_backend_module_finalize", if it exists, which it must because it is found in the conditional, for each and one of the backends (dbi being one, don't know if there are others though):
1939 qof_backend_module_finalize( void )
1940 {
1941 gnc_module_finalize_backend_dbi();
1942 }
1943 #endif /* GNC_NO_LOADABLE_MODULES */
1945 void
1946 gnc_module_finalize_backend_dbi( void )
1947 {
1948 dbi_shutdown();
1949 }

- That lead us to frames #3 and #2 without anything very interesting to say about it. Let's dig deeper and closer to the real deal:
 274 void dbi_shutdown() {
 275 dbi_shutdown_r(dbi_inst_legacy);
 276 }

- So we are calling some function which description in the library documentation is as follows:
Frees all loaded drivers and terminates the libdbi instance. You should close each connection you opened before shutting down, but libdbi will clean up after you if you don't.
Inst: The instance handle

- Then control passes on to frame #0, and then die after a SIGSEGV:
 243 void dbi_shutdown_r(dbi_inst Inst) {
 244 dbi_inst_t *inst = (dbi_inst_t*) Inst;
 245 dbi_conn_t *curconn = inst->rootconn;
 246 dbi_conn_t *nextconn;
 248 dbi_driver_t *curdriver = inst->rootdriver;
 249 dbi_driver_t *nextdriver;
 251 while (curconn) {
 252 nextconn = curconn->next;
 253 dbi_conn_close((dbi_conn)curconn);
 254 curconn = nextconn;
 255 }
 257 while (curdriver) {
 258 nextdriver = curdriver->next;
 259 curdriver->functions->finalize(curdriver);
 260 _safe_dlclose(curdriver);
 261 free(curdriver->functions);
 262 _free_custom_functions(curdriver);
 263 _free_caps(curdriver->caps);
 264 free(curdriver->filename);
 265 free(curdriver);
 266 curdriver = nextdriver;
 267 }
 268 #if HAVE_LTDL_H
 269 (void)lt_dlexit();
 270 #endif
 271 free(inst...


A. Eibach (andi3) wrote :

I second that.

Kai Mast (kai-mast) wrote :

Happens to me in vivid :(

Kai Mast (kai-mast) wrote :

Installed 2.6.5 from source and it runs fine.

Gábor Lipták (gliptak) wrote :

I see the same warning when running on command line:

Traceback (most recent call last):
  File "/usr/share/gnucash/python/", line 3, in <module>
    from gnucash import *
ImportError: No module named gnucash

But gnucash does come up.

I do not have python-gnucash installed:

$ dpkg --list | grep gnucash
ii gnucash 1:2.6.3-1build1 amd64 personal and small-business financial-accounting software
ii gnucash-common 1:2.6.3-1build1 all common files for the financial-accounting software Gnucash
ii gnucash-docs 2.6.3-1 all Documentation for gnucash, a personal finance tracking program

Geert Janssens (gjanssens) wrote :

Regarding comment #5: this is a different issue from the other issues mentioned here. The most likely cause is guile autocompilation. (This Fedora bug has more details: )

This has been dealt with for gnucash 2.6.5. If you can't upgrade to that version yet, you can also fix it by clearing guile 2's cache:
rm -rf ~/.cache/guile

Geert Janssens (gjanssens) wrote :

I would think the python-gnucash dependency issue is a packaging bug. One could mark python-gnucash as a mandatory dependency. That may cause circular dependencies though because python-gnucash should depend on gnucash.

The other option is alter the package contents slightly. (Caveat: I'm not a packager so I may be talking nonsense)

From gnucash' point of view the python binding are really optional. It will not try to load any python script if the module is not found. So I think that if this module is moved to the python-gnucash package, python-gnucash can really be a true optional module.

There may be one issue: if python-gnucash is an architecture independent package, can't just moved into that package because that would make it architecture dependent. If that's the case, I'll have to pass the issue to real packagers...

Reinhard Tartler (siretart) wrote :

Ubuntu vivid now ships with gnucash version 1:2.6.4-3, which contains this changelog entry:

gnucash (1:2.6.4-1) unstable; urgency=medium

  * Imported Upstream version 2.6.4
    + Fixes formula parsing error with scheduled mortgage transactions.
      (Closes: #748594)
    + No longer crashes on exit when python-gnucash is installed.
      (LP: #1312411)
  * Add missing dependency of python-gnucash on python-gtk2.
  * Bump Standards-Version to 3.9.6, no changes needed.

 -- Sébastien Villemot <email address hidden> Sun, 28 Sep 2014 11:28:11 +0200

I'm updating the bug's status based on this.

Changed in gnucash (Ubuntu):
status: Confirmed → Fix Released
Changed in gnucash (Ubuntu Trusty):
status: New → Triaged
Changed in gnucash (Ubuntu Utopic):
status: New → Triaged
Reinhard Tartler (siretart) wrote :

I've just recompiled and installed debian package version 1:2.6.4-3, and can confirm that the bug has *NOT* been fixed:

>> gnucash
Traceback (most recent call last):
  File "/usr/share/gnucash/python/", line 3, in <module>
    from gnucash import *
ImportError: No module named gnucash
Found Finance::Quote version 1.35

Changed in gnucash (Ubuntu):
status: Fix Released → Triaged
Changed in gnucash (Debian):
status: Unknown → Incomplete
Changed in gnucash (Debian):
status: Incomplete → Confirmed
Hannes Erven (hannes-erven) wrote :

Ran into this on vervet (upgraded from a recent utopic install).

Per , a "rm -rf .cache/guile/ccache/*" fixed the issue for me.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnucash - 1:2.6.4-3ubuntu1

gnucash (1:2.6.4-3ubuntu1) vivid; urgency=low

  * Avoid apport trying to report: "gnucash crashed with ImportError in
    /usr/share/gnucash/python/ No module named gnucash". Gnucash
    is trying to load the gnucash python module, technically a .so that
    won't load without the gnucash-python package present. The crash, a
    failed python import, itself does not affect user experience, but is
    nevertheless caught by apport. Until the right fix enters Debian
    (cf. #778999), ensure that python-gnucash is always present.
    LP: #1369273.
 -- Reinhard Tartler <email address hidden> Sun, 05 Apr 2015 20:45:37 -0400

Changed in gnucash (Ubuntu):
status: Triaged → Fix Released
Tin Tvrtkovic (tinchester) wrote :

I'm not getting this any more on Vivid. Cool!

dardhal (ubuntu-24x7linux) wrote :

Since upgrading to Vivid (15.04), I am no longer getting any of the errors reported with gnucash anymore.

A pity this wasn't fixed or at least working for me while on 14.10, anyways, thank you for fixing it.

A. Eibach (andi3) wrote :

Reinhard, you did the right thing in assuming that python-gnucash is always present.
However, this is only legitimate because Sebastien made it an *essential* dependency (see comment 20). So it wouldn't have been a legit fix unless these two things get _combined_.

Good work both of you.

Changed in gnucash (Debian):
status: Confirmed → Fix Released
Haggai Eran (haggai-eran) wrote :

This bug apparently also affects Xenial:

Package: gnucash
Version: 1:2.6.12-1
Priority: extra
Section: universe/gnome
Origin: Ubuntu
Maintainer: Ubuntu Developers <email address hidden>
Original-Maintainer: Dmitry Smirnov <email address hidden>
Installed-Size: 9,586 kB
Depends: gnucash-common (= 1:2.6.12-1), guile-2.0-libs, libaqbanking35 (>= 5.6.0beta), libc6 (>= 2.14), libcairo2 (>= 1.2.4), libdbi1 (>= 0.9.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.41.1), libgnome-keyring0 (>= 2.20.3), libgnomecanvas2-0 (>= 2.11.1), libgoffice-0.8-8 (>= 0.8.8), libgtk2.0-0 (>= 2.24.0), libgwengui-gtk2-0 (>= 3.99.16), libgwenhywfar60 (>= 3.99.1), libktoblzcheck1v5, libofx6, libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libpython2.7 (>= 2.7), libwebkitgtk-1.0-0 (>= 1.3.10), libx11-6, libxml2 (>= 2.7.4), libxslt1.1 (>= 1.1.25), zlib1g (>= 1:1.1.4), libaqbanking35-plugins, perl, guile-2.0, libfinance-quote-perl, libwww-perl, libhtml-tree-perl, libhtml-tableextract-perl, libcrypt-ssleay-perl, libdate-manip-perl
Recommends: gnucash-docs, python-gnucash, yelp
Suggests: libdbd-mysql, libdbd-pgsql, libdbd-sqlite3
Breaks: gnucash-common (<< 1:2.4.8-1~)
Replaces: gnucash-common (<< 1:2.4.8-1~)
Download-Size: 2,183 kB
APT-Manual-Installed: yes
APT-Sources: http://localhost:3142/ xenial/universe amd64 Packages
Description: personal and small-business financial-accounting software
 Gnucash provides accounting functions suitable for use by small businesses and
 individuals. It can track finances in multiple accounts, keeping running and
 reconciled balances. There is support for customer, vendor and employee
 processing. It has an X based graphical user interface, double entry, a
 hierarchy of accounts, expense accounts (categories), and can import Quicken
 QIF files and OFX files.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.