Am Montag 07 Juni 2010, 08:48:18 schrieb Andreas Tille:
> On Sun, Jun 06, 2010 at 11:16:18AM +0200, Sebastian Hilbert wrote:
> > I did not find official packages for Fedora or Debian. For Debian a
> > package exists at http://lx-office.org/pakete/
> > It would be great to work with upstream to package to package lx-office
> > and/or sql-ledger.
> $ apt-cache show sql-ledger
> I do not know about the difference of lx-office from sql-ledger, but
> sql-ledger packages exist (since several years).
We will have to check that with regards to the following issues.
Lx-Office was supposedly forked because it was not possible to adapt it to
German needs within the project.
Lx-Office is targeted at German companies which implies that they have
possibly made the same mistake and it might not be usable outside Germany.
Lx-Office has a German and and an English interface. Someone skilled should
check it from an accounting point of view.
I have started an effort to hopefully interface GNUmed to Lx-Office. Lx-
Office-erp is essentially a fork of sql-ledger.
The goal is to call the perl scripts of lx-office on the command line instead
of inside a browser.
It is therefore neccessary to find out the command line/commands in browser's
URL for each task.
2.) create client
3.) create biller
4.) create billable items
5.) select client, biller and items
6.) produce invoice as pdf
7.) send, mail, fax or hand over pdf to GNUmed
To foster investigation I have prepared a vmware image with Lx-Office and
GNUmed installed. While this is based on Debian squeeze this work will be
handy for GNUmed on all distributions.
I did not find official packages for Fedora or Debian. For Debian a package
exists at http://lx-office.org/pakete/
It would be great to work with upstream to package to package lx-office and/or
Here is what I have found so far:
Next step would be to create a new client to be billed in lx-office. Please
help us finding out the correct command line to achieve this.
Am Sonntag 30 Mai 2010, 13:30:10 schrieben Sie:
> > Please help me understand this issue. You are talking about the tarball
> > we release (gnumed-server.tgz). This tarball is essentially a cleaned up
> > snapshot of our GIT tree structure.
> > I assume that Fedora wants the tarball itself in a certain form with a
> > certain directory structure ?
> Its not really a requirement for a particular directory structure. It
> has more to do with which files can go where.
Do you mean the final destination of the files or do you mean the origin of
the files inside the released tarball ?
> > If this is of concern we could look into rearranging the content
> > directory structure of the tarball. However for the moment I do not see
> > any purpose except for the Fedora guideline because the packager will
> > move the file to another layout anyway.
> I can easily selectively copy the different files to the required
> locations but my concern is that whether such a trick actually work.
Let us know where they are supposed to go. What about the existing Fedora
package ? Does it copy to the wrong places ?
> found a lot of hardcodings as far as the paths of files are concerned.
I don't think there is anything hardcoded. Pretty much all is handled as long
it is in the python PATH. We need to know what files you want where.
> I am afraid that if I move the python files to the required
> directories, it might break the application.
Don't worry just let us know what you want.
> The package could also be autotoolized or atleast a makefile should be
> provided so that it is easier to configure and install.
I am not capable of either. This has been discussed back and forth. Noone on
our team has the skills and we did not see any obvious benefit.
> Looking forward to working this out.