From: Jan Engelhardt
Date: 2013-09-07 22:51:05.518210575 +0200
build: resolve rpmlint aborting due to bad code
gcc:
src/constraint.c:167:32: warning: initialization makes pointer from integer without a cast [enabled by default]
src/constraint.c:168:5: warning: passing argument 1 of 'ma
On Wednesday 2013-09-11 12:26, Markus Hoenicka wrote:
>Am 2013-09-11 12:14, schrieb Jan Engelhardt:
>>[2 patches for libdbi-drivers, 2 for libdbi]
>
>Hi,
>
>thanks for the patches. I've noticed your submission on the
>drivers-devel list as well, but my dayjob won&#
On Monday 2013-11-11 08:51, Markus Hoenicka wrote:
>Am 2013-11-11 08:36, schrieb Balazs Scheidler:
>> Btw, could we have libdbi converted to git?
>>
>> Would make my job so much easier as syslog-ng developer.
>
>that's just another "round tuit" issue. I migrated a different project
>to svn from
On Monday 2013-11-11 09:53, Markus Hoenicka wrote:
>On 2013-11-11 09:11 Jan Engelhardt was heard to say:
>> Perhaps you would like to delegate some work?
>> My Sourceforge username is jengelh, if you feel like adding me
>> to the projects.
>> Meanwhile, I'll con
On Monday 2013-11-11 15:25, Balazs Scheidler wrote:
>hi,
>
>I've just made a quick conversion using git-cvsimport and pushed the
>result to github:
>
>https://github.com/bazsi/libdbi
>
>But it was nothing but a mere "git cvsimport" invocation on a fresh CVS
>checkout.
Git repositories are now up,
On Thursday 2013-11-14 00:32, markus.hoeni...@mhoenicka.de wrote:
>Jan Engelhardt writes:
> > Git repositories are now up, with tags and all the fluff.
> >
> > [remote "sf"]
> > url = git://git.code.sf.net/p/libdbi/libdbi
> > push
I have a 2-patch here which I would like to share before merging.
SQL databases such as Mysql support dates from 1000-01-01 to
-01-01. However, even "reasonable" dates like 1968-02-14 cannot
be reliably retrieved through libdbi. The root problem is that time_t
only starts at 1970, and MSVCRT
libdbi replaced dbi_data_t's datetime field by datetimex and switched
from _dbd_parse_datetime for _dbd_parse_datetimex to support dates
outside the range of time_t. Adjust the drivers to follow suit.
---
drivers/db2/dbd_db2.c | 2 +-
drivers/firebird/utility.c| 2 +-
drivers/freetds
Dates before the epoch are not (always) representable in time_t. In
particular, the Microsoft C runtime's mktime function rejects any
dates before 1970, which is different from glibc which tries to
produce negative time_t values.
The sensible thing to do is to expose the broken-down date, for
exam
On Monday 2014-01-06 15:57, Mike Rylander wrote:
>While I can certainly understand the desire to improve handling of
>dates and times in libdbi (I helped a bit with the timezone code a few
>years back), I think breaking the API for all current applications is
>a bit heavy handed.
Thanks for your
On Tuesday 2014-01-21 10:27, jpac...@redhat.com wrote:
>Hi,
>
>libdbi ships with archaic version of automake which doesn't support e.g.
>aarch64 which is currently officially supported in many (not-only Linux)
>distributions (Fedora, Gentoo, etc.).
>
>Could you please update the automake scripts (
On Friday 2014-01-24 00:07, markus.hoeni...@mhoenicka.de wrote:
>In any case, what do you think about adding "--force-missing" to the
>automake call in ./autogen.sh to facilitate easier updating to newer
>automake releases?
gmake is usually capable of refreshing things "as needed", so when
autor
On Friday 2014-01-24 09:17, Markus Hoenicka wrote:
>At 2014-01-24 02:50 Jan Engelhardt was heard to say:
>> Speaking of which, autogen.sh has too much cruft. It should be removed
>> and/or replaced to only call `autoreconf -fi`. And perhaps `rm -Rf
>> autom4te.cache` bec
On Friday 2014-01-24 13:55, Markus Hoenicka wrote:
>At 2014-01-24 13:23 Jan Engelhardt was heard to say:
>>
>> Now, release?
>
>Well, why not. We just need to take care of your changes of the driver
>interface. Although this does not affect the libtool versioning (if I
It is currently impossible to distinguish an SQL column of decimal(m,n)
type from an SQL column of string type within libdbi, because both get
mapped to DBI_TYPE_STRING.
I feel inclined to break this up such that SQL DECIMAL gets mapped to
DBI_TYPE_DECIMAL, and SQL FLOAT/DOUBLE get mapped to a
On Thursday 2014-10-02 20:12, Holger Freyther wrote:
>
>> Ubuntu has updated their version from libdbi 0.8.x to 0.9.0 and
>> in Debian unstable. One issue is that we have used _get_uint where
>> we now need to use _get_ulonglong to not generate a dbi error. The
>> other issues seem to be genuine
On Thursday 2014-10-02 21:35, Holger Hans Peter Freyther wrote:
>On Thu, Oct 02, 2014 at 08:43:58PM +0200, Jan Engelhardt wrote:
>
>> You posted the SQL CREATE statements; do you also have a testcase
>> available?
>
>if you still have a copy of the OpenBSC tree. Just execut
17 matches
Mail list logo
