On Jan 11, 2014, at 3:08 PM, Sébastien Villemot wrote:
> Le samedi 11 janvier 2014 à 14:47 -0800, John Ralls a écrit :
>
>>> If you can get libdbi to actually fix the time_t issue (and any other
>>> issues that we might be having) that would be great and obviate the need
>>> to fork the code.
Le samedi 11 janvier 2014 à 14:47 -0800, John Ralls a écrit :
> > If you can get libdbi to actually fix the time_t issue (and any other
> > issues that we might be having) that would be great and obviate the need
> > to fork the code. Alas, right now they seem unwilling to acknowledge the
> > exi
On Jan 11, 2014, at 2:29 PM, Derek Atkins wrote:
> Hi,
>
>> The problem is rather the duplicate codebase: from the point of view of
>> the distribution (Debian) as a whole, it really means that there would
>> be two copies of libdbi in it, and it is bad for the same reasons that
>> you don't wa
Hi,
> The problem is rather the duplicate codebase: from the point of view of
> the distribution (Debian) as a whole, it really means that there would
> be two copies of libdbi in it, and it is bad for the same reasons that
> you don't want two almost identical copies of a file in a single project
Le samedi 11 janvier 2014 à 13:51 -0800, John Ralls a écrit :
> That said, what I proposed was to fork libdbi or SOCI *into gnucash*. It
> would become part of the GnuCash source code and would cause you no more
> trouble than the other bits of GnuCash lifted from other projects like LibQOF
> o
On Jan 11, 2014, at 1:30 PM, Sébastien Villemot wrote:
> Le samedi 11 janvier 2014 à 10:53 -0800, John Ralls a écrit :
>
>> Rather than depending on one of these libraries, we could fork one into our
>> own repository; if we did that with libdbi, we could even fix the time_t
>> problem.
>
>
Le samedi 11 janvier 2014 à 10:53 -0800, John Ralls a écrit :
> Rather than depending on one of these libraries, we could fork one into our
> own repository; if we did that with libdbi, we could even fix the time_t
> problem.
Please don't do that, private forks are a real pain for the free
soft
On Jan 11, 2014, at 12:51 PM, Phil Longstaff wrote:
> When I first started the sql backend, I worked with gnome-db
> (http://www.gnome-db.org/) aka libgda. This is a gobject-based database
> access technology. I started working with version 3.X and ran into some bugs
> and missing capabilit
I'd like to replace libdbi because they refused to change their use of time_t
to avoid the 2038 bug, insisting that since *BSD use a 64-bit time_t, it's not
a problem [1]. Furthermore, transactions are supported only in their new 0.9.0
version which isn't available yet in the major distros.
Unf
