Telldus Tellstick core Allows access to Telldus Tellstick USB dongles for communicating with 433MHz devices in your home. Provides "telldusd", the daemon which keeps track of your tellstick devices. Through a UNIX socket, the sensors and devices can be used/controlled from the command line tool "tdtool", or via the libtelldus-core C client library. WWW: http://www.telldus.com/products/tellstick Port tested on FreeBSD 8.4, 9.2 and 10.0. 10.0 fixes and validation by FreeBSD Forums user mix_room (https://forums.freebsd.org/viewtopic.php?f=46&t=12553#p256613), thanks! All patches except the tr1 fix (extra-patch-common_Event.h) submitted upstream: https://github.com/telldus/telldus/pull/6
Hi, if you are still interested in having this port in FreeBSD, it may (or may not) need to be reworked to support stage, and it may need updating to other newer conventions such as "USES" which is expanding all time. For staging, see http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-May/000080.html Additionally, you need to provide some sort of quality assurance. In order of preference, we are looking for: 1) "poudriere testport" or "poudriere bulk -t" logs 2) Redports or tinderbox logs 3) at least this: https://www.freebsd.org/doc/en/books/porters-handbook/porting-testing.html Please provide an updated shar file and attach a test log. Alternatively, please indicate if you are no longer interested in having this software in the Ports Collection and that we can close the PR. Thanks!
Created attachment 145554 [details] Updated shar file with minor tweaks to support stage
Created attachment 145555 [details] poudriere testport logfile Port now updated with full stage support and deprecated MANX removed. Also attached is output of 'poudriere testport -n' command executed on a FreeBSD 10.0-amd64 machine. The port builds fine on FreeBSD 9.2 as well.
Oops, extra 'pkg-plist.orig' file got into the latest shar file. Please skip that file on port inclusion.
do you have any idea what's causing the mtree error? ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist tar: mtree specification has different type for log tar: Error exit delayed from previous errors. ===> Checking for items in STAGEDIR missing from pkg-plist ===> Checking for directories owned by MTREEs ===> Checking for directories handled by dependencies ===> Checking for items in pkg-plist which are not in STAGEDIR ===> No pkg-plist issues found (check-plist) ====>> Checking for staging violations... done
Created attachment 145623 [details] poudriere testport logfile, FreeBSD 10.0
Created attachment 145624 [details] poudriere testport logfile, FreeBSD 9.2 Weird, no idea what it means, and when building again I do not get that. Added two updated logs, from 9.2 and 10.0.
Okay, the mtree stuff very well could be platform specific. Moving to patch-ready.
crap, the shar just dirtied my tree. https://www.freebsd.org/doc/en/books/porters-handbook/porting-submitting.html specifically: "Next, build the shar(1) file. Assuming the port is called oneko, cd to the directory above where the oneko directory is located, and then type: shar `find oneko` > oneko.shar" You didn't create the share from the directory above.
No mtree errors for me: =========================================================================== ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist ===> Checking for directories owned by MTREEs ===> Checking for directories handled by dependencies ===> Checking for items in pkg-plist which are not in STAGEDIR ===> No pkg-plist issues found (check-plist) ====>> Checking for staging violations... done
Oh, crap. Sorry about that. Are we good, or do you need a new shar (I guess not?)?
we're good on this port but I am having to do a lot of cosmetic stuff on Makefile (aligning tabs mostly). It seems you are using not-8 tab with in your editor sometimes.
ouch, you have <options> being included but you aren't using options. I guess you added it for $OSVERSION (which is missing ${OPSYS} == FreeBSD btw) And the first time you use LIB_DEPENDS and BUILD_DEPENDS, use "=" rather than "+="
Hm, good question.. Not sure why options was used instead of bsd.pre.mk, which I suppose is what should be used? Regarding OPSYS, wasn't aware that ports was non-FreeBSD :) Regarding indentation, yes, vim with ts=3. I'll get on and fix that for the owfs port as well, so you won't have to! Thanks
You don't need this OSVERSION stuff at all. You need USES=compiler:<right option> That has to be fixed. I'll give it a quick go, if not I'm punting it back
(In reply to johan from comment #14) > Regarding OPSYS, wasn't aware that ports was non-FreeBSD :) It is, DragonFly uses ports too, and OSVERSION is FreeBSD-specific.
actually, this is that TR1 problem. I had this once and I had to patch it out to use the right namespace. Which is what you are doing. I think we can make this patch unconditional with USES c++11 compiler library.
don't put blank lines in pkg-plist.
look here: https://www.freebsd.org/doc/en/books/porters-handbook/plist-keywords.html This port can and should use @sample keyword in pkg-plist
I'm doubting that etc/<conf sample> needs special ownership. the /var/ stuff, sure i think I'm going to limit ownership changes down to /var/ stuff
i'm alphabetizing pkg-plist too.
Thanks for your input! Seems @sample is something new, don't think it existed when I wrote the initial port? IIRC I was looking quite a bit to get those bits straight. Regarding tr1, I believe that patch was required on 10.0, but it did not work on 9.2.. But I didn't test with USES=c++11, I'm pretty new to C++11 so not sure what the optimal solution would be. Regarding ownership of config file, the daemon does writing to both the config file and the state file (/var).
is it a good idea to use /usr/local/var/telldus-core instead of /var/telldus-core ?
(In reply to johan from comment #22) > Thanks for your input! > Regarding tr1, I believe that patch was required on 10.0, but it did not > work on 9.2.. But I didn't test with USES=c++11, I'm pretty new to C++11 so > not sure what the optimal solution would be. testing this in redports now > Regarding ownership of config file, the daemon does writing to both the > config file and the state file (/var). that is very unusual to write to a config file in /usr/local/etc/ Are you sure it does and why does it?
(In reply to John Marino from comment #23) > is it a good idea to use /usr/local/var/telldus-core instead of > /var/telldus-core ? I was under the impression that local apps should use /usr/local/var, are there any guidelines? It will only use that single file to keep device state, so it will always be pretty small (mine with state of 7 devices is 300b). (In reply to John Marino from comment #24) > (In reply to johan from comment #22) > > > Regarding ownership of config file, the daemon does writing to both the > > config file and the state file (/var). > > that is very unusual to write to a config file in /usr/local/etc/ > Are you sure it does and why does it? The daemon supports adding/removing/configuring devices via it's communications interface. Those changes are written to the configuration file. See ./service/SettingsConfuse.cpp:101, 149 and more.
(In reply to johan from comment #25) > (In reply to John Marino from comment #23) > > is it a good idea to use /usr/local/var/telldus-core instead of > > /var/telldus-core ? > > I was under the impression that local apps should use /usr/local/var, are > there any guidelines? I think it's the opposite - use /var/<portname> unless there is a justifiable reason not to. It goes back to how sysadmins mount their partitions -- in some cases dedicated /var partitions. > > that is very unusual to write to a config file in /usr/local/etc/ > > Are you sure it does and why does it? > > The daemon supports adding/removing/configuring devices via it's > communications interface. Those changes are written to the configuration > file. See ./service/SettingsConfuse.cpp:101, 149 and more. Yuck. Okay, I'll put it back
(In reply to John Marino from comment #26) > (In reply to johan from comment #25) > > (In reply to John Marino from comment #23) > > > is it a good idea to use /usr/local/var/telldus-core instead of > > > /var/telldus-core ? > > > > I was under the impression that local apps should use /usr/local/var, are > > there any guidelines? > > I think it's the opposite - use /var/<portname> unless there is a > justifiable reason not to. It goes back to how sysadmins mount their > partitions -- in some cases dedicated /var partitions. > Yeah, although given the size I don't think it would make much difference. That said, I'm good with either, I have no preference either way. If changed, ensure CMAKE_ARGS+=-DSTATE_INSTALL_DIR="${PREFIX}/var/telldus" is adjusted accordingly.
it didn't work on FreeBSD 8 or 9, maybe the patch isn't good enough. In any case, it's a no-no to do compiler fixes based on OSVERSION. What a pain. It did build with gcc 4.7 though. [ 1%] Building CXX object common/CMakeFiles/TelldusCommon.dir/Event.cpp.o cd /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common && /usr/local/bin/g++47 -D_FREEBSD -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc47 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc47 -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc47 -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc47 -I/usr/local/include -I/work/a/ports/comms/telldus-core/work/telldus-core-2.1.2 -fPIC -fvisibility=hidden -o CMakeFiles/TelldusCommon.dir/Event.cpp.o -c /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp In file included from /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp:7:0: /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.h:35:10: error: 'shared_ptr' in namespace 'std' does not name a type /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.h:45:15: error: 'EventDataRef' has not been declared /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.h:46:3: error: 'EventDataRef' does not name a type /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.h:77:10: error: 'shared_ptr' in namespace 'std' does not name a type In file included from /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp:9:0: /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/EventHandler.h:24:3: error: 'EventRef' does not name a type /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp:29:12: error: 'EventDataRef' was not declared in this scope /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp:29:24: error: template argument 1 is invalid /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp:29:24: error: template argument 2 is invalid /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp: In member function 'void TelldusCore::EventBase::popSignal()': /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp:47:8: error: 'class TelldusCore::EventBase' has no member named 'takeSignal' /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp: In member function 'bool TelldusCore::EventBase::isSignaled()': /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp:56:27: error: request for member 'size' in '((TelldusCore::EventBase*)this)->TelldusCore::EventBase::d->TelldusCore::EventBase::PrivateData::eventDataList', which is of non-class type 'int' /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp: In member function 'void TelldusCore::EventBase::signal(TelldusCore::EventData*)': /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp:64:37: error: 'EventDataRef' was not declared in this scope /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp: At global scope: /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp:67:24: error: variable or field 'signal' declared void /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp:67:24: error: 'EventDataRef' was not declared in this scope /work/a/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.cpp:88:1: error: expected '}' at end of input
(In reply to John Marino from comment #28) > it didn't work on FreeBSD 8 or 9, maybe the patch isn't good enough. > In any case, it's a no-no to do compiler fixes based on OSVERSION. What a > pain. > It did build with gcc 4.7 though. maybe I need C++0x instead.
(In reply to John Marino from comment #29) > (In reply to John Marino from comment #28) > > it didn't work on FreeBSD 8 or 9, maybe the patch isn't good enough. > > In any case, it's a no-no to do compiler fixes based on OSVERSION. What a > > pain. > > It did build with gcc 4.7 though. > > maybe I need C++0x instead. I don't think the patch was used on 9, since it did not have tr1:: in base system and thus no problem. The original reason for the patch was the following error: /usr/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.h:35:15: error: no member named 'tr1' in namespace 'std' typedef std::tr1::shared_ptr<EventData> EventDataRef; More details: https://forums.freebsd.org/viewtopic.php?f=46&t=12553#p258290
> I don't think the patch was used on 9, since it did not have tr1:: in base > system and thus no problem. Errr, rather it did have std::tr1::shared_ptr, while FreeBSD 10 has std::shared_ptr.
(In reply to johan from comment #30) > I don't think the patch was used on 9, since it did not have tr1:: in base > system and thus no problem. You keep assuming "base system compiler". You can't assume that. Another compiler might be used. > /usr/ports/comms/telldus-core/work/telldus-core-2.1.2/common/Event.h:35:15: > error: no member named 'tr1' in namespace 'std' > typedef std::tr1::shared_ptr<EventData> EventDataRef; Yes, I knew as soon as I saw "TR1"
every time you are tempted to use OSVERSION, you should step back, think about why you think you need it, and test for a feature instead of an OSVERSION. ideally OSVERSION is never used and it's use is a red flag.
look at port devel/re2, maybe that's the solution
(In reply to John Marino from comment #32) > (In reply to johan from comment #30) > > I don't think the patch was used on 9, since it did not have tr1:: in base > > system and thus no problem. > > You keep assuming "base system compiler". You can't assume that. Another > compiler might be used. > (In reply to John Marino from comment #33) > every time you are tempted to use OSVERSION, you should step back, think > about why you think you need it, and test for a feature instead of an > OSVERSION. > > ideally OSVERSION is never used and it's use is a red flag. Both good points... (In reply to John Marino from comment #34) > look at port devel/re2, maybe that's the solution 22 USES= cmake 23 USES+=iconv 24 USES+= compiler:c++11-lang 25 .include <bsd.port.pre.mk> ... 45 post-patch: 46 # remove tr1 if using libc++ 47 .if ${COMPILER_FEATURES:Mlibc++} 48 @${REINPLACE_CMD} -e 's|tr1/||; s|tr1::||' ${WRKSRC}/common/Event.h 49 .endif This works on FreeBSD 10 at least. I have no 9.x at hand to try out with, upgraded all machines to 10.0 a few days ago.
tested version: https://redports.org/browser/jmarino/comms/telldus-core test results: https://redports.org/buildarchive/20140815140010-41295/ redports is having issues with 8.4 builders I think, so I'm trying to build this in a locate 8.4 poudriere jail just to be sure.
late catch: this is a new port, it should not have PORTREVISION set
FreeBSD 8.4 is happy too: ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist ===> Checking for directories owned by MTREEs ===> Checking for directories handled by dependencies ===> Checking for items in pkg-plist which are not in STAGEDIR ===> No pkg-plist issues found (check-plist) ====>> Checking for staging violations... done
A commit references this bug: Author: marino Date: Fri Aug 15 14:43:51 UTC 2014 New revision: 364977 URL: http://svnweb.freebsd.org/changeset/ports/364977 Log: Add new port comms/telldus-core PR: 189221 Submitted by: johan (stromnet.se) Allows access to Telldus Tellstick USB dongles for communicating with 433MHz devices in your home. Provides "telldusd", the daemon which keeps track of your tellstick devices. Through a UNIX socket, the sensors and devices can be used/ controlled from the command line tool "tdtool", or via the libtelldus-core C client library. Changes: head/comms/Makefile head/comms/telldus-core/ head/comms/telldus-core/Makefile head/comms/telldus-core/distinfo head/comms/telldus-core/files/ head/comms/telldus-core/files/patch-CMakeLists.txt head/comms/telldus-core/files/patch-common-CMakeLists.txt head/comms/telldus-core/files/patch-common-Socket_unix.cpp head/comms/telldus-core/files/patch-common-Thread.h head/comms/telldus-core/files/patch-service-CMakeLists.txt head/comms/telldus-core/files/patch-service-ConnectionListener_unix.cpp head/comms/telldus-core/files/patch-service-EventUpdateManager.cpp head/comms/telldus-core/files/patch-service-Sensor.h head/comms/telldus-core/files/patch-service-SettingsConfuse.cpp head/comms/telldus-core/files/patch-service-tellstick.conf head/comms/telldus-core/files/patch-tdadmin-CMakeLists.txt head/comms/telldus-core/files/patch-tdadmin-freebsd-devd-tellstick.conf head/comms/telldus-core/files/patch-tdtool-CMakeLists.txt head/comms/telldus-core/files/telldusd.in head/comms/telldus-core/pkg-descr head/comms/telldus-core/pkg-message head/comms/telldus-core/pkg-plist
I am worn out; that was brutal. But it's done.
Brutal indeed, but a lot of learning for me, thank you very much! I'll report this in the FreeBSD forums thread and at least some other users will benefit from this work as well.