Menu
▾
▴
libdbi-devel — Discussion about development of the core library and DBD interface
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(7) |
Aug
(10) |
Sep
|
Oct
(5) |
Nov
|
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(28) |
Feb
(3) |
Mar
(3) |
Apr
|
May
(1) |
Jun
|
Jul
(8) |
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(13) |
Jun
(2) |
Jul
(23) |
Aug
(10) |
Sep
(31) |
Oct
(1) |
Nov
(6) |
Dec
(11) |
| 2006 |
Jan
(6) |
Feb
(5) |
Mar
(19) |
Apr
(29) |
May
(63) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(3) |
Dec
|
| 2007 |
Jan
|
Feb
(16) |
Mar
(1) |
Apr
(3) |
May
(1) |
Jun
|
Jul
(6) |
Aug
(18) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(4) |
Feb
(8) |
Mar
|
Apr
(3) |
May
|
Jun
(9) |
Jul
|
Aug
(7) |
Sep
(2) |
Oct
(11) |
Nov
(30) |
Dec
(2) |
| 2009 |
Jan
(1) |
Feb
|
Mar
(25) |
Apr
|
May
(9) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(24) |
Nov
(9) |
Dec
(2) |
| 2010 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
(22) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
(10) |
Feb
(17) |
Mar
(4) |
Apr
(9) |
May
(1) |
Jun
|
Jul
(7) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(13) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(17) |
Dec
|
| 2014 |
Jan
(16) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Balazs S. <ba...@ba...> - 2013-11-12 08:29:00
|
Great news indeed. I'll remove my libdbi conversion from github then. -- Bazsi Jan Engelhardt <je...@in...> wrote: >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, with tags and all the fluff. > >[remote "sf"] > url = git://git.code.sf.net/p/libdbi/libdbi > pushurl = ssh://git.code.sf.net/p/libdbi/libdbi >[remote "sf"] > url = git://git.code.sf.net/p/libdbi-drivers/libdbi-drivers > pushurl = ssh://git.code.sf.net/p/libdbi-drivers/libdbi-drivers > >What I noticed is that libdbi-drivers is a branch from libdbi >(started around version 0.6.7), but the commits are inconsistently >named, so I did not bother connecting the dbi and dbi-drivers tree in >any way. > |
|
From: Markus H. <mar...@mh...> - 2013-11-12 07:39:23
|
On 2013-11-12 01:10 Jan Engelhardt was heard to say: > What I noticed is that libdbi-drivers is a branch from libdbi > (started around version 0.6.7), but the commits are inconsistently > named, so I did not bother connecting the dbi and dbi-drivers tree in > any way. > This might be related to the fact that the mysql and pgsql drivers had been part of libdbi until approx. version 0.6.7. I had started a separate libdbi-drivers project back then with the consent of the libdbi maintainers. When they stopped developing libdbi actively, they donated the drivers to libdbi-drivers. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Jan E. <je...@in...> - 2013-11-12 00:10:58
|
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, with tags and all the fluff. [remote "sf"] url = git://git.code.sf.net/p/libdbi/libdbi pushurl = ssh://git.code.sf.net/p/libdbi/libdbi [remote "sf"] url = git://git.code.sf.net/p/libdbi-drivers/libdbi-drivers pushurl = ssh://git.code.sf.net/p/libdbi-drivers/libdbi-drivers What I noticed is that libdbi-drivers is a branch from libdbi (started around version 0.6.7), but the commits are inconsistently named, so I did not bother connecting the dbi and dbi-drivers tree in any way. |
|
From: <mar...@mh...> - 2013-11-11 23:10:45
|
Jan Engelhardt writes: > Hm I cannot access https://sourceforge.net/p/libdbi/admin/?source=navbar > to create a git repo. That's probably because developer and admin > are two separate roles. > (Unlike Github, SF has no 300 MB limit, has file release and webpage > capability. So I'd just keep it, given it's already there) > > As for the conversion from CVS, should I leave the abstract user > "mhoenicka" in the commit logs, or rewrite it with your current > full-name <email> identity? > Hi, the access problem should be fixed now. I assume from your past submissions to these projects that you may have low intentions to wreak havoc on them :-) I also suggest to continue to use SF resources as they conveniently provide some webspace as well. Please rewrite the username according to what is most common elsewhere. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Jan E. <je...@in...> - 2013-11-11 19:19:24
|
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 convert the existing CVS locally to something >> transferable. > >thanks for offering your help. I've added you as a developer to both >projects. Let me know if you need additional permissions or if there are >things that I should rather do myself. Hm I cannot access https://sourceforge.net/p/libdbi/admin/?source=navbar to create a git repo. That's probably because developer and admin are two separate roles. (Unlike Github, SF has no 300 MB limit, has file release and webpage capability. So I'd just keep it, given it's already there) As for the conversion from CVS, should I leave the abstract user "mhoenicka" in the commit logs, or rewrite it with your current full-name <email> identity? |
|
From: Toby T. <to...@te...> - 2013-11-11 14:45:02
|
On 11/11/13 5:31 AM, Balazs Scheidler wrote: > Hi, > > well, converting the repo itself is easy, it's a matter of a > git-importcvs command and your history is converted too. the best git > hosting site is github imho, but SF may also have something. There is also https://BitBucket.org (Mercurial and Git). --Toby > > we are hosting a private cvs->git converted repo here (way unmaintained > I'd say, so don't use that for anything): > > https://github.com/balabit/libdbi > > My point is, that the conversion it's doable, not even difficult. > > learning git is a great investment these days, practically everything > has moved to using git. > > once you understand what it means to have a local copy of the entire > repo and what the staging area means, it really becomes intuitive and > powerful. after learning it, you'll be wondering how you could work with > anything else. > > cheers, > Bazsi > > On Mon, 2013-11-11 at 08:51 +0100, Markus Hoenicka wrote: >> >> -------- Originalnachricht -------- >> Betreff: Re: [libdbi-devel] 2 libdbi patches >> Datum: 2013-11-11 08:48 >> Von: Markus Hoenicka<mar...@mh...> >> An: Balazs Scheidler<ba...@ba...> >> >> 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. >>> -- >>> Bazsi >>> >> >> Hi, >> >> that's just another "round tuit" issue. I migrated a different project >> to svn from cvs a couple of years ago, and this really paid off (this >> was before git really took off). Problem is that I basically don't have >> any time to spare, so I'll probably need some guidance to move the repo >> and to be able to make use of it myself afterwards. >> >> regards, >> Markushe >> > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > libdbi-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdbi-devel > |
|
From: Balazs S. <ba...@ba...> - 2013-11-11 14:26:13
|
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. It created 4 branches: - origin is "tracking" the CVS repo, so it can be refreshed from CVS (but can be dropped once the git becomes authoritive) - "master" is the current HEAD - "dap24" and "libdbi-0_8_3_bugfix_branch" were probably created based on branches in CVS Here are a couple of tutorials on git: * git-scm.com/docs/gittutorial * www.vogella.com/articles/Git/article.html * but you can simply find more with google, there are even SVN to git tutorials out there If you like the result, just clone the github repo I have created, decide where to host it (github would be just fine, it's free until 300MB), push it and announce its existence. If github is your service of choice, you can clone the repository under your name using simply the web interface. Let me know if you need help. Cheers Bazsi On Mon, 2013-11-11 at 12:03 +0100, Markus Hoenicka wrote: > Am 2013-11-11 11:31, schrieb Balazs Scheidler: > > Hi, > > > > well, converting the repo itself is easy, it's a matter of a > > git-importcvs command and your history is converted too. the best git > > hosting site is github imho, but SF may also have something. > > > > we are hosting a private cvs->git converted repo here (way unmaintained > > I'd say, so don't use that for anything): > > > > https://github.com/balabit/libdbi > > > > My point is, that the conversion it's doable, not even difficult. > > > > learning git is a great investment these days, practically everything > > has moved to using git. > > > > once you understand what it means to have a local copy of the entire > > repo and what the staging area means, it really becomes intuitive and > > powerful. after learning it, you'll be wondering how you could work > > with > > anything else. > > > > cheers, > > Bazsi > > > > Hi, > > ok, I'm looking forward to it. > > regards, > Markus > |
|
From: Markus H. <mar...@mh...> - 2013-11-11 11:03:27
|
Am 2013-11-11 11:31, schrieb Balazs Scheidler: > Hi, > > well, converting the repo itself is easy, it's a matter of a > git-importcvs command and your history is converted too. the best git > hosting site is github imho, but SF may also have something. > > we are hosting a private cvs->git converted repo here (way unmaintained > I'd say, so don't use that for anything): > > https://github.com/balabit/libdbi > > My point is, that the conversion it's doable, not even difficult. > > learning git is a great investment these days, practically everything > has moved to using git. > > once you understand what it means to have a local copy of the entire > repo and what the staging area means, it really becomes intuitive and > powerful. after learning it, you'll be wondering how you could work > with > anything else. > > cheers, > Bazsi > Hi, ok, I'm looking forward to it. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Balazs S. <ba...@ba...> - 2013-11-11 10:32:04
|
Hi, well, converting the repo itself is easy, it's a matter of a git-importcvs command and your history is converted too. the best git hosting site is github imho, but SF may also have something. we are hosting a private cvs->git converted repo here (way unmaintained I'd say, so don't use that for anything): https://github.com/balabit/libdbi My point is, that the conversion it's doable, not even difficult. learning git is a great investment these days, practically everything has moved to using git. once you understand what it means to have a local copy of the entire repo and what the staging area means, it really becomes intuitive and powerful. after learning it, you'll be wondering how you could work with anything else. cheers, Bazsi On Mon, 2013-11-11 at 08:51 +0100, Markus Hoenicka wrote: > > -------- Originalnachricht -------- > Betreff: Re: [libdbi-devel] 2 libdbi patches > Datum: 2013-11-11 08:48 > Von: Markus Hoenicka <mar...@mh...> > An: Balazs Scheidler <ba...@ba...> > > 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. > > -- > > Bazsi > > > > Hi, > > that's just another "round tuit" issue. I migrated a different project > to svn from cvs a couple of years ago, and this really paid off (this > was before git really took off). Problem is that I basically don't have > any time to spare, so I'll probably need some guidance to move the repo > and to be able to make use of it myself afterwards. > > regards, > Markushe > |
|
From: Markus H. <mar...@mh...> - 2013-11-11 08:53:13
|
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 convert the existing CVS locally to something > transferable. > Hi, thanks for offering your help. I've added you as a developer to both projects. Let me know if you need additional permissions or if there are things that I should rather do myself. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Jan E. <je...@in...> - 2013-11-11 08:12:06
|
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 cvs a couple of years ago, and this really paid off (this >was before git really took off). Problem is that I basically don't have >any time to spare, so I'll probably need some guidance to move the repo >and to be able to make use of it myself afterwards. 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 convert the existing CVS locally to something transferable. |
|
From: Balazs S. <ba...@ba...> - 2013-11-11 07:54:16
|
Btw, could we have libdbi converted to git? Would make my job so much easier as syslog-ng developer. -- Bazsi Jan Engelhardt <je...@in...> wrote: >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't let me take action on >>them this week. I'll let you know when I got round to it. > >How is life going? >I have more patches down the pipeline as a result of porting this >to cygwin/mingw, and generally newer automake. >This lives in a temporary git repository at > git://git.inai.de/libdbi and > git://git.inai.de/libdbi-drivers > >------------------------------------------------------------------------------ >November Webinars for C, C++, Fortran Developers >Accelerate application performance with scalable programming models. Explore >techniques for threading, error checking, porting, and tuning. Get the most >from the latest Intel processors and coprocessors. See abstracts and register >http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >_______________________________________________ >libdbi-devel mailing list >lib...@li... >https://lists.sourceforge.net/lists/listinfo/libdbi-devel > |
|
From: Markus H. <mar...@mh...> - 2013-11-11 07:51:20
|
-------- Originalnachricht -------- Betreff: Re: [libdbi-devel] 2 libdbi patches Datum: 2013-11-11 08:48 Von: Markus Hoenicka <mar...@mh...> An: Balazs Scheidler <ba...@ba...> 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. > -- > Bazsi > Hi, that's just another "round tuit" issue. I migrated a different project to svn from cvs a couple of years ago, and this really paid off (this was before git really took off). Problem is that I basically don't have any time to spare, so I'll probably need some guidance to move the repo and to be able to make use of it myself afterwards. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Markus H. <mar...@mh...> - 2013-11-11 07:43:28
|
On 2013-11-11 04:15 Jan Engelhardt was heard to say: > How is life going? > I have more patches down the pipeline as a result of porting this > to cygwin/mingw, and generally newer automake. > This lives in a temporary git repository at > git://git.inai.de/libdbi and > git://git.inai.de/libdbi-drivers Hi, I've been using libdbi on Cygwin for years in my dayjob, and I have always been thinking it's about time to replace the "separate Makefile"-style hacks in libdbi-drivers with a serious port. But then again, the hack was good enough through the years so I never got round to it. Therefore I greatly appreciate if you managed to fix some of these issues on Cygwin. As I'm no git user, I'd greatly appreciate if you could send me the magic commands to pull your patches from the repository. I'll manage to install git, but I'll be lost from there on. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Jan E. <je...@in...> - 2013-11-11 03:15:21
|
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't let me take action on >them this week. I'll let you know when I got round to it. How is life going? I have more patches down the pipeline as a result of porting this to cygwin/mingw, and generally newer automake. This lives in a temporary git repository at git://git.inai.de/libdbi and git://git.inai.de/libdbi-drivers |
|
From: Markus H. <mar...@mh...> - 2013-09-11 10:40:27
|
Am 2013-09-11 12:14, schrieb Jan Engelhardt: > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > > _______________________________________________ > libdbi-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdbi-devel Hi, thanks for the patches. I've noticed your submission on the drivers-devel list as well, but my dayjob won't let me take action on them this week. I'll let you know when I got round to it. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Peter C. <cz...@ba...> - 2013-04-29 14:47:43
|
On 04/29/2013 12:58 PM, Markus Hoenicka wrote: > Am 2013-04-29 12:11, schrieb Peter Czanik: > >>> And no, you do not have to compile cgreen at all unless you need to >>> run make check. >> Is there any easy way to disable compiling it with a configure and/or >> make parameter? > > I don' think there is such a parameter. The easiest way is to remove > "tests" from the SUBDIRS variable in the top-level Makefile.am if that > is legal in your packaging environment. It's legal, so I did it now as a workaround. > If packagers never test stuff anyways, we might consider adding a > --disable-tests option to configure. Well, I did packaging only after testing libdbi with syslog-ng. So instead of make check, I did some real life tests with syslog-ng + libdbi + sqlite + mysql + pgsql + ms sql. Updating to 0.9.0 did not break anything in my tests and sqlite support finally works. On the other hand I can't publish my package in the build service until scripts report "Errors". Making it a configure option would make further package updates easier, as with patches one needs usually to recreate them for each release. Bye, -- Peter Czanik (CzP) <cz...@ba...> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/ |
|
From: Markus H. <mar...@mh...> - 2013-04-29 10:58:37
|
Am 2013-04-29 12:11, schrieb Peter Czanik: >> And no, you do not have to compile cgreen at all unless you need to >> run make check. > Is there any easy way to disable compiling it with a configure and/or > make parameter? I don' think there is such a parameter. The easiest way is to remove "tests" from the SUBDIRS variable in the top-level Makefile.am if that is legal in your packaging environment. If packagers never test stuff anyways, we might consider adding a --disable-tests option to configure. regards, Markus regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Markus H. <mar...@mh...> - 2013-04-29 09:59:40
|
Am 2013-04-29 09:47, schrieb Peter Czanik: > No, they did not seem to fix the problem. You can see the exact > compile messages at > https://build.opensuse.org/package/rawlog?arch=i586&package=libdbi-drivers&project=home%3Aczanik%3Alibdbi&repository=openSUSE_Factory > The offending lines seem to be: > > [ 28s] gcc -DHAVE_CONFIG_H -I. -I../.. -Iinclude > -fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2 > -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables > -fasynchronous-unwind-tables -std=gnu99 -fomit-frame-pointer > -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 > -fstack-protector -funwind-tables -fasynchronous-unwind-tables -c -o > text_reporter.o `test -f 'src/text_reporter.c' || echo > './'`src/text_reporter.c > [ 28s] src/constraint.c: In function 'with_': > [ 28s] src/constraint.c:104:22: warning: assignment from > incompatible pointer type [enabled by default] > [ 28s] src/constraint.c: In function 'compare_using_matcher': > [ 28s] src/constraint.c:167:32: warning: initialization makes > pointer from integer without a cast [enabled by default] > [ 28s] src/constraint.c:168:5: warning: passing argument 1 of > 'matches' makes pointer from integer without a cast [enabled by > default] > [ 28s] src/constraint.c:168:5: note: expected 'const void *' but > argument is of type 'intptr_t' > > > BTW: Is it really necessary to compile this code? Seems to be > something testing related and I don't run 'make check' during package > building... > Bye, Hi, I'll have a look at those issues in src/constraint.c. I remember that the previous log contained a couple of additional issues. Were these fixed by my patches? And no, you do not have to compile cgreen at all unless you need to run make check. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Peter C. <cz...@ba...> - 2013-04-29 07:47:14
|
Hello, On 04/27/2013 08:55 PM, mar...@mh... wrote: > Peter Czanik writes: > > Hello, > > I don't know if it's a problem in libdbi-drivers code or in openSUSE > > Build Service code checking scripts (I can't code in C, just > > package...), but right now I can't package libdbi-drivers as I get the > > following warnings and error: > > > > [ 11s] I: Program is using implicit definitions of functions getting > > [ 11s] pointers or implemented by macros. These functions need to > > use their > > [ 11s] correct prototypes to allow correct argument passing on e.g. > > x86_64 . > > [ 11s] - Implicit memory/string functions need #include <string.h>. > > [ 11s] - Implicit *printf functions need #include <stdio.h>. > > [ 11s] - Implicit *printf functions need #include <stdio.h>. > > [ 11s] - Implicit *read* functions need #include <unistd.h>. > > [ 11s] - Implicit *recv* functions need #include <sys/socket.h>. > > [ 11s] W: libdbi-drivers implicit-pointer-decl src/unit.c:229 > > [ 11s] E: libdbi-drivers 64bit-portability-issue src/constraint.c:167, 168 > > > > The full log is available at > > https://build.opensuse.org/package/rawlog?arch=x86_64&package=libdbi-drivers&project=home%3Aczanik%3Alibdbi&repository=openSUSE_Factory > > Could you take a look at it? > > Hi, > > the offending code appears to be in the copy of cgreen which we ship > as a test harness along with the libdbi-drivers sources. I don't fully > understand what the code checking scripts complain about but > apparently some of the prototypes in the include files rely on global > include files which are only included *after* the local include > files. The appended patches revert the order of includes. Could you > please check if that helps? No, they did not seem to fix the problem. You can see the exact compile messages at https://build.opensuse.org/package/rawlog?arch=i586&package=libdbi-drivers&project=home%3Aczanik%3Alibdbi&repository=openSUSE_Factory The offending lines seem to be: [ 28s] gcc -DHAVE_CONFIG_H -I. -I../.. -Iinclude -fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -std=gnu99 -fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -c -o text_reporter.o `test -f 'src/text_reporter.c' || echo './'`src/text_reporter.c [ 28s] src/constraint.c: In function 'with_': [ 28s] src/constraint.c:104:22: warning: assignment from incompatible pointer type [enabled by default] [ 28s] src/constraint.c: In function 'compare_using_matcher': [ 28s] src/constraint.c:167:32: warning: initialization makes pointer from integer without a cast [enabled by default] [ 28s] src/constraint.c:168:5: warning: passing argument 1 of 'matches' makes pointer from integer without a cast [enabled by default] [ 28s] src/constraint.c:168:5: note: expected 'const void *' but argument is of type 'intptr_t' BTW: Is it really necessary to compile this code? Seems to be something testing related and I don't run 'make check' during package building... Bye, -- Peter Czanik (CzP) <cz...@ba...> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/ |
|
From: <mar...@mh...> - 2013-04-27 18:53:30
|
Peter Czanik writes: > Hello, > I don't know if it's a problem in libdbi-drivers code or in openSUSE > Build Service code checking scripts (I can't code in C, just > package...), but right now I can't package libdbi-drivers as I get the > following warnings and error: > > [ 11s] I: Program is using implicit definitions of functions getting > [ 11s] pointers or implemented by macros. These functions need to > use their > [ 11s] correct prototypes to allow correct argument passing on e.g. > x86_64 . > [ 11s] - Implicit memory/string functions need #include <string.h>. > [ 11s] - Implicit *printf functions need #include <stdio.h>. > [ 11s] - Implicit *printf functions need #include <stdio.h>. > [ 11s] - Implicit *read* functions need #include <unistd.h>. > [ 11s] - Implicit *recv* functions need #include <sys/socket.h>. > [ 11s] W: libdbi-drivers implicit-pointer-decl src/unit.c:229 > [ 11s] E: libdbi-drivers 64bit-portability-issue src/constraint.c:167, 168 > > The full log is available at > https://build.opensuse.org/package/rawlog?arch=x86_64&package=libdbi-drivers&project=home%3Aczanik%3Alibdbi&repository=openSUSE_Factory > Could you take a look at it? Hi, the offending code appears to be in the copy of cgreen which we ship as a test harness along with the libdbi-drivers sources. I don't fully understand what the code checking scripts complain about but apparently some of the prototypes in the include files rely on global include files which are only included *after* the local include files. The appended patches revert the order of includes. Could you please check if that helps? regards, Markus |
|
From: Peter C. <cz...@ba...> - 2013-04-26 12:57:37
|
Hello, I don't know if it's a problem in libdbi-drivers code or in openSUSE Build Service code checking scripts (I can't code in C, just package...), but right now I can't package libdbi-drivers as I get the following warnings and error: [ 11s] I: Program is using implicit definitions of functions getting [ 11s] pointers or implemented by macros. These functions need to use their [ 11s] correct prototypes to allow correct argument passing on e.g. x86_64 . [ 11s] - Implicit memory/string functions need #include <string.h>. [ 11s] - Implicit *printf functions need #include <stdio.h>. [ 11s] - Implicit *printf functions need #include <stdio.h>. [ 11s] - Implicit *read* functions need #include <unistd.h>. [ 11s] - Implicit *recv* functions need #include <sys/socket.h>. [ 11s] W: libdbi-drivers implicit-pointer-decl src/unit.c:229 [ 11s] E: libdbi-drivers 64bit-portability-issue src/constraint.c:167, 168 The full log is available at https://build.opensuse.org/package/rawlog?arch=x86_64&package=libdbi-drivers&project=home%3Aczanik%3Alibdbi&repository=openSUSE_Factory Could you take a look at it? Bye, -- Peter Czanik (CzP) <cz...@ba...> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/ |
|
From: Peter C. <cz...@ba...> - 2013-04-26 12:57:37
|
Ooops, forgot to mention: it's version 0.9.0 Have a nice weekend! Bye, CzP On 04/26/2013 02:37 PM, Peter Czanik wrote: > Hello, > I don't know if it's a problem in libdbi-drivers code or in openSUSE > Build Service code checking scripts (I can't code in C, just > package...), but right now I can't package libdbi-drivers as I get the > following warnings and error: > > [ 11s] I: Program is using implicit definitions of functions getting > [ 11s] pointers or implemented by macros. These functions need to > use their > [ 11s] correct prototypes to allow correct argument passing on > e.g. x86_64 . > [ 11s] - Implicit memory/string functions need #include > <string.h>. > [ 11s] - Implicit *printf functions need #include <stdio.h>. > [ 11s] - Implicit *printf functions need #include <stdio.h>. > [ 11s] - Implicit *read* functions need #include <unistd.h>. > [ 11s] - Implicit *recv* functions need #include <sys/socket.h>. > [ 11s] W: libdbi-drivers implicit-pointer-decl src/unit.c:229 > [ 11s] E: libdbi-drivers 64bit-portability-issue > src/constraint.c:167, 168 > > The full log is available at > https://build.opensuse.org/package/rawlog?arch=x86_64&package=libdbi-drivers&project=home%3Aczanik%3Alibdbi&repository=openSUSE_Factory > Could you take a look at it? > Bye, > -- Peter Czanik (CzP) <cz...@ba...> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/ |
|
From: <mar...@mh...> - 2013-04-19 00:02:58
|
Tom Lane writes: > mar...@mh... writes: > > thanks for your explanation. I've checked the sources, and > > interestingly src/dbi_main.c contains a declaration of dbi_conn_queryf(): > > > dbi_result dbi_conn_queryf(dbi_conn Conn, const char *formatstr, ...) __attribute__ ((format (printf, 2, 3))); > > > in addition to the declaration in include/dbi/dbi.h: > > > dbi_result dbi_conn_queryf(dbi_conn Conn, const char *formatstr, ...); > > > Was that a half-assed attempt to implement what the OP asked for? > > Would it be sufficient to move the first declaration to the header > > which is visible to the programs that actually call the function? > > Right. The __attribute__() decoration needs to be visible to the call > sites, so generally one sticks it in the header that provides the > function's extern declaration. There's no point in attaching it to the > function definition. > > regards, tom lane Thanks Tom. I've checked in the fixed files, see dbi.h.in rev. 1.14 and dbi_main.c rev. 1.104. Holger, could you please verify with your unintentional testcase whether you get the intended compiler warnings? regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Tom L. <tg...@ss...> - 2013-04-18 22:58:32
|
mar...@mh... writes: > thanks for your explanation. I've checked the sources, and > interestingly src/dbi_main.c contains a declaration of dbi_conn_queryf(): > dbi_result dbi_conn_queryf(dbi_conn Conn, const char *formatstr, ...) __attribute__ ((format (printf, 2, 3))); > in addition to the declaration in include/dbi/dbi.h: > dbi_result dbi_conn_queryf(dbi_conn Conn, const char *formatstr, ...); > Was that a half-assed attempt to implement what the OP asked for? > Would it be sufficient to move the first declaration to the header > which is visible to the programs that actually call the function? Right. The __attribute__() decoration needs to be visible to the call sites, so generally one sticks it in the header that provides the function's extern declaration. There's no point in attaching it to the function definition. regards, tom lane |
9 messages has been excluded from this view by a project administrator.
