Hide Forgot
Description of problem: Updated smstools to 3.1.14 due to the following errors while using a Teltonika ModemUSB/G10: <snip> 2011-02-14 15:35:13,2, smsd: Smsd v3.0.10 started. 2011-02-14 15:35:13,2, smsd: Running as root:root. 2011-02-14 15:35:13,6, smsd: File mode creation mask: 022 (0644, rw-r--r--). 2011-02-14 15:35:13,6, GSM1: Modem handler 0 has started. 2011-02-14 15:35:13,6, smsd: outgoing file checker has started. 2011-02-14 15:35:15,6, GSM1: Checking device for incoming SMS 2011-02-14 15:35:15,6, GSM1: Checking if modem is ready 2011-02-14 15:35:15,7, GSM1: -> AT 2011-02-14 15:35:15,7, GSM1: Command is sent, waiting for the answer 2011-02-14 15:35:20,7, GSM1: put_command expected (OK)|(ERROR), timeout occurred. 2011-02-14 15:35:20,7, GSM1: <- <C9> 2011-02-14 15:35:20,7, GSM1: -> ^Z 2011-02-14 15:35:20,7, GSM1: Command is sent, waiting for the answer 2011-02-14 15:35:25,7, GSM1: put_command expected (OK)|(ERROR), timeout occurred. 2011-02-14 15:35:25,7, GSM1: <- </snip> Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install Teltonika ModemUSB/G10 2. Install smstools 3. Start smsd Actual results: GSM modem is unable to send SMS. Expected results: GSM modem is able to send SMS. Additional info: Updated and patched smstools-3.1.14-1.src.rpm is attached. Tested only on CentOS 5.5 32-bit.
Created attachment 478597 [details] Updated and patched SRPM
Created attachment 479115 [details] Makefile patch from Justin's smstools-3.1.14-1.src.rpm
Created attachment 479116 [details] perm patch from Justin's smstools-3.1.14-1.src.rpm
Justin, I was not planning to update the version of smstools in EPEL5. EPEL6, F15 branch and rawhide have 3.1.14 question to you; are you fine with that package (either ability to run el6 or ability to rpmbuild (the latter I guess is a definite yes as you made your own package anyway) As to the patches, perm-patch: I got rid of that in 3.1.5-1, any reason you keep it around? Mind you, the spec file has changed quite a bit since 3.0.10 makefile-patch: is this still needed with 3.1.14-1 in EPEL6? note: while I am @redhat.com, I am not a developer, I'm just co-maintainer on this package.
Patrick, I will have to test a build of the 3.1.14 EPEL6 SRPM. Regarding the perm-patch, I only kept it since I saw it in the EPEL5 SRPM. I was not able to test it with perm-patch removed. As for the makefile-patch, I noticed that the CFLAGS=%{optflags} in the EPEL5 specfile overrides the CFLAGS in smstools-upstream/src/Makefile and breaks the build. I renamed CFLAGS to EXTRACFLAGS in the specfile and made the patch that inserts EXTRACFLAGS into the Makefile so that the build can proceed.
Hello again. An update in the EL5 repo would be great, but without regression testing, I don't see how that will happen. Otherwise, I'd just build from SRPM. After further analysis of the patches, I think the perm-patch is unnecessary if outgoing messages don't need group read/write permissions anymore. As far as the makefile-patch is concerned, I've noticed that the most recent spec file redefines CFLAGS. Just to make it clear, the makefile-patch allows the following line: make -C src 'CFLAGS=%{optflags} -DNOSTATS -D NUMBER_OF_MODEMS=64' %{_smp_mflags} to become this: make -C src 'EXTRACFLAGS=%{optflags}' %{_smp_mflags} This allows for additional CFLAGS to be set in the spec file without disturbing whatever existing CFLAGS are set in the Makefile. Hope this helps.
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora or Fedora EPEL, please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.