[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

We need gnucash in stable



[Resending this to debian-gtk-gnome, since I forgot to change the sender
address from mail@ to debian@, and lists.d.o does not allow mail@. It
was originally also sent to 192101@bugs.debian.org]

Hi treacy,
Hi those interested in the package,
Hi those listening to the rc-bugs-maillinglist,
Hi those on debian-gtk-gnome, (hope you don't mind this message)

there are rumours about a freeze for sarge soon, and we still do not
have gnucash in testing. I think gnucash is very important, since it is
probably the most advanced free accounting program, has support for HBCI
(online banking standard popular in Germany) and is ready for serious
use. It also was present in woody (quite a old version now, of course,
since upstream is quite active). I trust it my money on a daily basis.

Currently, gnucash fails to go to testing [1] because it fails to build
on certain architectures (s390, alpha, mips{,el}, hppa, arm) while it
builds on others (i386, powerpc, ia64, m68k, sparc). The cause for the
failure is somewhere hidden in the guile tests.

There were efforts to fix these problems, and some have been fixed (i46
works now again). But it is unlikely that we can fix these build
problems in a short period of time. So here is my train of thought:

 * Not having gnucash is stable helps nobody, and is a decrease in
quality compared to woody.
 * Having gnucash in stable only for some architectures is at least
better that that.

Now we have two options:

     A. We drop gnucash for those architectures not supported
        (Architecture: field in debian/control). This is in favour for
        our users on i386 and powerpc etc, and no worse for those on
        other archs. As soon as I have access to these machines, I will
        try to find the error and maybe we can upload the remaining
        architectures in a later revision of sarge
     B. We disable the failing checks and find out - with help from
        upstream - which part of the actual program now should behave
        wrongly, hoping the the test itself is somehow buggy, not the
        code it's testing. This way we _could_ have gnucash on all
        architectures.

Personally, I'd prefer option A, especially since gnucash as an
accounting program works on quite crucial data.

nomeata

[1] http://packages.qa.debian.org/gnucash
    http://bugs.debian.org/192101
-- 
Joachim "nomeata" Breitner
  e-Mail: mail@joachim-breitner.de | Homepage: http://www.joachim-breitner.de
  JID: joachimbreitner@amessage.de | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
            PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html
-- 
Joachim "nomeata" Breitner
  e-Mail: mail@joachim-breitner.de | Homepage: http://www.joachim-breitner.de
  JID: joachimbreitner@amessage.de | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
            PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Reply to: