Bug 189221 - New port: comms/telldus-core, software for communicating with Telldus Tellstick
Summary: New port: comms/telldus-core, software for communicating with Telldus Tellstick
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: John Marino
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-02 10:40 UTC by Johan Ström
Modified: 2014-08-15 14:53 UTC (History)
1 user (show)

See Also:


Attachments
telldus-core.shar (16.75 KB, text/plain)
2014-05-02 10:40 UTC, Johan Ström
no flags Details
Updated shar file with minor tweaks to support stage (17.06 KB, text/plain)
2014-08-09 12:22 UTC, Johan Ström
no flags Details
poudriere testport logfile (69.02 KB, text/plain)
2014-08-09 12:25 UTC, Johan Ström
no flags Details
poudriere testport logfile, FreeBSD 10.0 (69.05 KB, text/plain)
2014-08-10 20:01 UTC, Johan Ström
no flags Details
poudriere testport logfile, FreeBSD 9.2 (69.69 KB, text/plain)
2014-08-10 20:03 UTC, Johan Ström
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johan Ström 2014-05-02 10:40:00 UTC
	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
Comment 1 John Marino freebsd_committer 2014-08-07 14:54:56 UTC
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!
Comment 2 Johan Ström 2014-08-09 12:22:00 UTC
Created attachment 145554 [details]
Updated shar file with minor tweaks to support stage
Comment 3 Johan Ström 2014-08-09 12:25:43 UTC
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.
Comment 4 Johan Ström 2014-08-09 12:27:15 UTC
Oops, extra 'pkg-plist.orig' file got into the latest shar file. Please skip that file on port inclusion.
Comment 5 John Marino freebsd_committer 2014-08-09 12:30:50 UTC
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
Comment 6 Johan Ström 2014-08-10 20:01:13 UTC
Created attachment 145623 [details]
poudriere testport logfile, FreeBSD 10.0
Comment 7 Johan Ström 2014-08-10 20:03:13 UTC
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.
Comment 8 John Marino freebsd_committer 2014-08-10 20:07:34 UTC
Okay, the mtree stuff very well could be platform specific.  Moving to patch-ready.
Comment 9 John Marino freebsd_committer 2014-08-15 11:47:58 UTC
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.
Comment 10 John Marino freebsd_committer 2014-08-15 11:57:47 UTC
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
Comment 11 Johan Ström 2014-08-15 12:01:50 UTC
Oh, crap. Sorry about that.

Are we good, or do you need a new shar (I guess not?)?
Comment 12 John Marino freebsd_committer 2014-08-15 12:04:28 UTC
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.
Comment 13 John Marino freebsd_committer 2014-08-15 12:06:21 UTC
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 "+="
Comment 14 Johan Ström 2014-08-15 12:09:46 UTC
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
Comment 15 John Marino freebsd_committer 2014-08-15 12:10:07 UTC
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
Comment 16 John Marino freebsd_committer 2014-08-15 12:11:23 UTC
(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.
Comment 17 John Marino freebsd_committer 2014-08-15 12:13:17 UTC
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.
Comment 18 John Marino freebsd_committer 2014-08-15 12:16:00 UTC
don't put blank lines in pkg-plist.
Comment 19 John Marino freebsd_committer 2014-08-15 12:18:36 UTC
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
Comment 20 John Marino freebsd_committer 2014-08-15 12:24:25 UTC
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
Comment 21 John Marino freebsd_committer 2014-08-15 12:25:26 UTC
i'm alphabetizing pkg-plist too.
Comment 22 Johan Ström 2014-08-15 12:31:03 UTC
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).
Comment 23 John Marino freebsd_committer 2014-08-15 12:35:13 UTC
is it a good idea to use /usr/local/var/telldus-core instead of /var/telldus-core ?
Comment 24 John Marino freebsd_committer 2014-08-15 12:37:04 UTC
(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?
Comment 25 Johan Ström 2014-08-15 12:42:03 UTC
(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.
Comment 26 John Marino freebsd_committer 2014-08-15 12:45:05 UTC
(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
Comment 27 Johan Ström 2014-08-15 12:49:02 UTC
(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.
Comment 28 John Marino freebsd_committer 2014-08-15 13:05:46 UTC
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
Comment 29 John Marino freebsd_committer 2014-08-15 13:15:59 UTC
(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.
Comment 30 Johan Ström 2014-08-15 13:20:41 UTC
(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
Comment 31 Johan Ström 2014-08-15 13:21:36 UTC
> 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.
Comment 32 John Marino freebsd_committer 2014-08-15 13:22:39 UTC
(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"
Comment 33 John Marino freebsd_committer 2014-08-15 13:24:15 UTC
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.
Comment 34 John Marino freebsd_committer 2014-08-15 13:29:30 UTC
look at port devel/re2, maybe that's the solution
Comment 35 Johan Ström 2014-08-15 13:44:56 UTC
(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.
Comment 36 John Marino freebsd_committer 2014-08-15 14:16:37 UTC
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.
Comment 37 John Marino freebsd_committer 2014-08-15 14:17:58 UTC
late catch: this is a new port, it should not have PORTREVISION set
Comment 38 John Marino freebsd_committer 2014-08-15 14:39:31 UTC
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
Comment 39 commit-hook freebsd_committer 2014-08-15 14:44:10 UTC
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
Comment 40 John Marino freebsd_committer 2014-08-15 14:45:18 UTC
I am worn out; that was brutal.  But it's done.
Comment 41 Johan Ström 2014-08-15 14:53:39 UTC
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.