RE: Daily patch: gateway
On Fri, 2002-05-31 at 11:49, Harrie Hazewinkel wrote: > > > --On Friday, May 31, 2002 12:07 PM +0200 Angel Fradejas > <[EMAIL PROTECTED]> wrote: > > > Harrie please, > > > > Would you be so kind as to comment these changes in ChangeLog? > > Done. > > > > They're somewhat described in a post from May 25 (subject: changes to the > > heartbeat code.) > > The message is the same as the commit message. > I personally, would prefer if the CVS-message during commit > is used for this. >From our former architecture, Lars: (I hope everything is ok with ex-wapit people) ChangeLog We use the file called `ChangeLog' to log changes, not CVS commit entries. CVS entries are not usable by people who don't have CVS access (e.g., they are off-line at the moment, which happens often for laptop users), and are also harder to browse than a single file. When writing an entry, please try to make sure the entry is at least somewhat understandable without referring to the actual patch it reflects. This helps immensely those who want to follow Kannel development without having to wade through millions of lines of patches per year. > > > Harrie > > Internet Management Consulting > mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ > >
RE: Daily patch: gateway
--On Friday, May 31, 2002 12:07 PM +0200 Angel Fradejas <[EMAIL PROTECTED]> wrote: > Harrie please, > > Would you be so kind as to comment these changes in ChangeLog? Done. > > They're somewhat described in a post from May 25 (subject: changes to the > heartbeat code.) The message is the same as the commit message. I personally, would prefer if the CVS-message during commit is used for this. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
RE: Daily patch: gateway
Our mails crossed, sorry Harrie. -Mensaje original- De: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] Enviado el: viernes 31 de mayo de 2002 11:41 Para: Stipe Tolj; Angel Fradejas CC: Kannel Developers Asunto: Re: Daily patch: gateway --On Friday, May 31, 2002 10:17 AM +0200 Stipe Tolj <[EMAIL PROTECTED]> wrote: > Angel, > >> > File gateway/gw/bb.h changed from revision 1.5 to 1.6 >> > File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 >> > File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 >> > File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 >> > File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 >> > File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 >> > File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 >> >> All this files have been changed without documentation on ChangeLog. Some of those, I chnaged and I did not edit ChangeLog, since I thought that was updated automatically with the CVS message provided at commit. I will put the same message in ChangeLog. Sorry about that. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
RE: Daily patch: gateway
Harrie please, Would you be so kind as to comment these changes in ChangeLog? They're somewhat described in a post from May 25 (subject: changes to the heartbeat code.) Thanks. Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stipe Tolj Enviado el: viernes 31 de mayo de 2002 10:18 Para: Angel Fradejas CC: Kannel Developers Asunto: Re: Daily patch: gateway Angel, > >File gateway/gw/bb.h changed from revision 1.5 to 1.6 > >File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 > >File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 > >File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 > >File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 > >File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 > >File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 > > All this files have been changed without documentation on ChangeLog. > > Please, this is important as we have to follow potential problems to keep > using HEAD of CVS. right, I agree. Could you please lookup who did the commits and post the request directly to hin/her (ehmmm, we don't have a 'her' yet, do we ;)) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Daily patch: gateway
--On Friday, May 31, 2002 10:17 AM +0200 Stipe Tolj <[EMAIL PROTECTED]> wrote: > Angel, > >> > File gateway/gw/bb.h changed from revision 1.5 to 1.6 >> > File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 >> > File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 >> > File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 >> > File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 >> > File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 >> > File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 >> >> All this files have been changed without documentation on ChangeLog. Some of those, I chnaged and I did not edit ChangeLog, since I thought that was updated automatically with the CVS message provided at commit. I will put the same message in ChangeLog. Sorry about that. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
Re: Daily patch: gateway
Angel, > >File gateway/gw/bb.h changed from revision 1.5 to 1.6 > >File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 > >File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 > >File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 > >File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 > >File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 > >File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 > > All this files have been changed without documentation on ChangeLog. > > Please, this is important as we have to follow potential problems to keep > using HEAD of CVS. right, I agree. Could you please lookup who did the commits and post the request directly to hin/her (ehmmm, we don't have a 'her' yet, do we ;)) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: Daily patch: gateway
>File gateway/gw/bb.h changed from revision 1.5 to 1.6 >File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 >File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 >File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 >File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 >File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 >File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 All this files have been changed without documentation on ChangeLog. Please, this is important as we have to follow potential problems to keep using HEAD of CVS. Cheers. Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08
Re: Daily patch: gateway
On Thu, 2002-05-02 at 14:18, Stipe Tolj wrote: > I don't see the necessarity of chaning the configure.in behaviour. And > it *definitly* has changed. On a system without MySQL configure breaks > claiming that MySQL is not available. Hence we have a broken configure > here. It's now fixed... mysql is disabled by default. The idea of --enable-* is to say we want and let configure discover where it is. The --with-*=path is to tell configure that the libs are there. But, yes, that's a bug... or mysql is disable by default and errors if user enables it and mysql is not found (user's fault), or if it remains enabled by default, it should just revert back to disabled if mysql is not found. > Bruno, could you please consider asking the developers list for votes > priour to commiting such changes. Thanks in advance. You know that, by Murphy's laws, nothing works at the first time ;)
Re: Daily patch: gateway
I don't see the necessarity of chaning the configure.in behaviour. And
it *definitly* has changed. On a system without MySQL configure breaks
claiming that MySQL is not available. Hence we have a broken configure
here.
Bruno, could you please consider asking the developers list for votes
priour to commiting such changes. Thanks in advance.
Stipe
> -dnl Implement the --with-mysql option. This will set HAVE_MYSQL in config.h
> -dnl accordingly and enable the usage of the libmysqlclient routines.
> +dnl Implement the --with-mysql option.
>
> +AC_CONFIG_SECTION([Configuring MySQL support])
> AC_ARG_WITH(mysql,
> -[ --with-mysql[=DIR] where to look for MySQL libs and header files
> - DIR points to the installation [/usr/local]],
> -[AC_CONFIG_SECTION([Configuring MySQL support])
> - AC_PATH_PROGS(MYSQL_CONFIG, mysql_config, no)
> - dnl check for MySQL 4.x style mysql_config information
> - if test "$MYSQL_CONFIG" = "no"; then
> - dnl mysql-3.x style
> - AC_MSG_CHECKING([for MySQL client support in])
> - if test "$withval" = "yes"; then
> - loc="/usr/local"
> - else
> - loc="$withval"
> - fi
> - AC_MSG_RESULT($loc)
> - AC_CHECK_FILE("$loc/include/mysql/mysql.h",
> - [CFLAGS="$CFLAGS -I$loc/include/mysql"; LIBS="$LIBS -L$loc/lib/mysql
>-lmysqlclient"],
> - [AC_CHECK_FILE("$loc/include/mysql.h",
> - [CFLAGS="$CFLAGS -I$loc/include"; LIBS="$LIBS -L$loc/lib -lmysqlclient"],
> - [AC_MSG_ERROR(Unable to find mysql.h under $loc)]
> - )]
> - )
> - else
> - dnl mysql-4.x style
> - AC_MSG_CHECKING([mysql version])
> - mysql_version=`$MYSQL_CONFIG --version`
> - AC_MSG_RESULT([$mysql_version])
> - LIBS="$LIBS `$MYSQL_CONFIG --libs`"
> - CFLAGS="$CFLAGS `$MYSQL_CONFIG --cflags`"
> - fi
> - AC_CHECK_HEADERS(mysql/mysql.h mysql/mysql_com.h mysql/mysql_version.h)
> - AC_CHECK_LIB(mysqlclient, mysql_init)
> - AC_DEFINE(HAVE_MYSQL)
> - MYSQL="yes"
> +[ --with-mysql[=DIR]where to look for MySQL libs and header files
> + DIR points to the installation [/usr/local/mysql]],
> +[ if test -d "$withval"; then
> +mysqlloc="$withval";
> + else
> +AC_MSG_ERROR(Unable to find MySQL libs and/or directories at $withval)
> + fi
> +])
> +
> +
> +dnl Implement the --enable-mysql option. This will set HAVE_MYSQL in config.h
> +dnl accordingly and enable the usage of the libmysqlclient routines.
> +
> +AC_MSG_CHECKING([whether to compile with MySQL support])
> +AC_ARG_ENABLE(mysql,
> +[ --enable-mysqlenable MySQL storage (default: enabled)], [
> + if test "$enableval" = no ; then
> +AC_MSG_RESULT(disabled)
> + fi
> +],[
> + dnl test only if --with-mysql has not been used
> + if test "x$mysqlloc" = "x" ; then
> +AC_MSG_RESULT(searching)
> +AC_PATH_PROGS(MYSQL_CONFIG, mysql_config, no)
> +dnl check for MySQL 4.x style mysql_config information
> +if test "$MYSQL_CONFIG" = "no"; then
> + dnl mysql-3.x style
> + found=""
> + for loc in /usr /usr/local ; do
> +if test "x$found" = "x" ; then
> + AC_MSG_CHECKING([for MySQL client support in])
> + AC_MSG_RESULT($loc)
> + AC_CHECK_FILE("$loc/include/mysql/mysql.h",
> +[CFLAGS="$CFLAGS -I$loc/include/mysql"; LIBS="$LIBS -L$loc/lib/mysql
>-lmysqlclient"]; found=1,
> +[AC_CHECK_FILE("$loc/include/mysql.h",
> + [CFLAGS="$CFLAGS -I$loc/include"; LIBS="$LIBS -L$loc/lib
>-lmysqlclient"]; found=1
> + )]
> + )
> + fi
> + done
> + if test "x$found" != "x1" ; then
> +AC_MSG_ERROR(Unable to find mysql.h)
> + fi
> +else
> + dnl mysql-4.x style
> + AC_MSG_CHECKING([mysql version])
> + mysql_version=`$MYSQL_CONFIG --version`
> + AC_MSG_RESULT([$mysql_version])
> + LIBS="$LIBS `$MYSQL_CONFIG --libs`"
> + CFLAGS="$CFLAGS `$MYSQL_CONFIG --cflags`"
> +fi
> + else
> + AC_MSG_RESULT(searching in $mysqlloc)
> + AC_CHECK_FILE("$mysqlloc/include/mysql/mysql.h",
> +[CFLAGS="$CFLAGS -I$mysqlloc/include/mysql"; LIBS="$LIBS
>-L$mysqlloc/lib/mysql -lmysqlclient"],
> +[AC_CHECK_FILE("$mysqlloc/include/mysql.h",
> + [CFLAGS="$CFLAGS -I$mysqlloc/include"; LIBS="$LIBS -L$mysqlloc/lib
>-lmysqlclient"],
> + [AC_MSG_ERROR(Unable to find mysql.h under $mysqlloc)]
> + )]
> + )
> + fi
> + AC_CHECK_HEADERS(mysql/mysql.h mysql/mysql_com.h mysql/mysql_version.h)
> + AC_CHECK_LIB(mysqlclient, mysql_init)
> + AC_DEFINE(HAVE_MYSQL)
> + AC_MSG_CHECKING([whether to compile with MySQL support])
> + AC_MSG_RESULT(yes)
> + MYSQL="yes"
> ])
[EMAIL PROTECTED]
---
Wapme Systems AG
Münsterstr. 248
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
RE: Daily patch: gateway
> -Original Message- > From: Andreas Fink [mailto:[EMAIL PROTECTED]] > > >as > >the modem does not send an OK, wait_modem_command() will return a > >timeout, which init_device() will parse as an error and > therby fail the > >initialization. > > Why did it always work before then? because a timeout returned a -10, which init_device didnot parse as an error. > >I assert that both solutions are wrong and we need to come up with a > >third one. how about calling wait_modem_command() once after > recieving > >+CPIN:READY if the modem is of a type that sends an OK after that > >message ? (or just call it anyway and discard the return > value ? at most > >it will slow some modems' initialization by the call timeout). > > no, the best way is to wait for +CPIN: READY and then wait for OK or > timeout in 1-2 seconds and dont deal this missing ok as a error. ok, so wait_modem_commands end with a timeout, you'll check the pin_ready flag and return 0 if it's set ? then you'll have to make sure either to reset the pin_ready flag to 0 at the start of the function, or make sure that who ever reads pin_ready will reset it after use. doesn't sound too bad, I can live with it :-) -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] If you don't go to other men's funerals they won't go to yours. -- Clarence Day
RE: Daily patch: gateway
> > -Original Message- >> From: kannel [mailto:[EMAIL PROTECTED]] >> Sent: Saturday, March 09, 2002 8:30 AM >> To: [EMAIL PROTECTED] >> Subject: Daily patch: gateway > >> Index: gateway/ChangeLog >> diff -u gateway/ChangeLog:1.1704 gateway/ChangeLog:1.1708 >> --- gateway/ChangeLog:1.1704Thu Mar 7 21:01:03 2002 >> +++ gateway/ChangeLog Fri Mar 8 22:28:36 2002 >> @@ -1,3 +1,48 @@ >> +2002-03-08 Andreas Fink <[EMAIL PROTECTED]> >> +* gw/smsc_at2.c: fixed a bug for +CPIN which wasnt >> waiting for OK after >> ++CPIN answer. This was screwing up AT command answers >> and Siemens TC35 >> +couldnt get initialized anymore. > >I don't think that this solution it correct - as some modems do not send >an OK after +CPIN:READY, and AFAIR, the standard does not require it. Its not a question if the standard requries it or not (I think it does). Its a question how the driver deals with it. the broken version did implement it as the result for the next command which is pretty bad. >as >the modem does not send an OK, wait_modem_command() will return a >timeout, which init_device() will parse as an error and therby fail the >initialization. Why did it always work before then? > this has been discussed before and that's the reason >that the ret = 4 line was introduced. you can go around making patches >that are known to break some implemenations just because it will make >your implemenation work. *grin* I wont comment that... >I assert that both solutions are wrong and we need to come up with a >third one. how about calling wait_modem_command() once after recieving >+CPIN:READY if the modem is of a type that sends an OK after that >message ? (or just call it anyway and discard the return value ? at most >it will slow some modems' initialization by the call timeout). no, the best way is to wait for +CPIN: READY and then wait for OK or timeout in 1-2 seconds and dont deal this missing ok as a error. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
RE: Daily patch: gateway
> -Original Message- > From: kannel [mailto:[EMAIL PROTECTED]] > Sent: Saturday, March 09, 2002 8:30 AM > To: [EMAIL PROTECTED] > Subject: Daily patch: gateway > Index: gateway/ChangeLog > diff -u gateway/ChangeLog:1.1704 gateway/ChangeLog:1.1708 > --- gateway/ChangeLog:1.1704 Thu Mar 7 21:01:03 2002 > +++ gateway/ChangeLog Fri Mar 8 22:28:36 2002 > @@ -1,3 +1,48 @@ > +2002-03-08 Andreas Fink <[EMAIL PROTECTED]> > +* gw/smsc_at2.c: fixed a bug for +CPIN which wasnt > waiting for OK after > ++CPIN answer. This was screwing up AT command answers > and Siemens TC35 > +couldnt get initialized anymore. I don't think that this solution it correct - as some modems do not send an OK after +CPIN:READY, and AFAIR, the standard does not require it. as the modem does not send an OK, wait_modem_command() will return a timeout, which init_device() will parse as an error and therby fail the initialization. this has been discussed before and that's the reason that the ret = 4 line was introduced. you can go around making patches that are known to break some implemenations just because it will make your implemenation work. I assert that both solutions are wrong and we need to come up with a third one. how about calling wait_modem_command() once after recieving +CPIN:READY if the modem is of a type that sends an OK after that message ? (or just call it anyway and discard the return value ? at most it will slow some modems' initialization by the call timeout). -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] Experience is what causes a person to make new mistakes instead of old ones.
