Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - mkbrown69

Pages: [1] 2 3 ... 15
1
Users / Re: GSD issues - all devices died.
« on: September 02, 2015, 03:01:04 am »
Hey Jason!

I'm not against rolling forward to 14.04. I'm trying to implement a SAMBA 4 AD Set-up at home (using 2 virtuals of Zentyal as PDC and BDC/NAS), and was planning on looking at seeing if I could integrate LMCE's SAMBA into at as a DC as well.

I can stay on 12.04 for a while if you want, to help troubleshoot. Just curious if more dev effort is moving towards 14.04, or if 12.04 is still the focus?

Thanks!

/Mike

2
Users / Re: GSD issues - all devices died.
« on: August 29, 2015, 05:22:32 am »
Jason,

I commented out the stuff in my ISY driver's #350, and rebooted (a reload wasn't sufficient to restart the device.

It no longer segfaults. It loads all the GSD code, and then dies at the end, and tries to re-spawn.

Code: [Select]
1843:#### START SETTERS #############################################################
#######
1844:def initialize()
1845:super
1846:@returnParamArray=Array.new
1847:end
1848:####  END  SETTERS #############################################################
#######
1849:end
1851:Return code: 134
3       08/28/15 23:07:59       189 (spawning-device)   Device died... count=2/
50 dev=189
Fri Aug 28 23:07:59 EDT 2015 died
== ATTEMPT FRESH START ==
1       08/28/15 23:08:08       /usr/pluto/bin/Spawn_Device.sh 189 (spawning-device)15473 Dev: 189; Already Running list: 15,18,113,36,16,19,31,183,38,32,189,

1       08/28/15 23:08:08       /usr/pluto/bin/Spawn_Device.sh 189 (spawning-device)15473 Device 189 was marked as 'running'. Not starting
1       08/28/15 23:08:08       /usr/pluto/bin/Spawn_Device.sh 189 (spawning-device)15473 Dev: 189; Exiting because not starting


So, #350 does look to be the cause of the segfaults, but is not the only problem. My driver does use 350 for it's subscription feed from the ISY.

The CT30/CT80 only has a Conn_close() in #350, which probably isn't a issue to leave out. However, it also dies and res-spawns.
Code: [Select]
955:#### START SETTERS #############################################################
#######
 956:def initialize()
 957:super
 958:@returnParamArray=Array.new
 959:end
 960:####  END  SETTERS #############################################################
#######
 961:end
963:Return code: 134
3       08/28/15 23:07:47       183 (spawning-device)   Device died... count=1/
50 dev=183
Fri Aug 28 23:07:47 EDT 2015 died
========== NEW LOG SECTION ==========
1       08/28/15 23:07:57       183 (spawning-device)   Starting... 2
1       08/28/15 23:07:57       183 (spawning-device)   Found /usr/pluto/bin/Ge
neric_Serial_Device
RCODE:


Looks like you and Thom are closing in on it!

HTH!

/Mike

3
Users / Re: GSD issues - all devices died.
« on: August 28, 2015, 05:05:41 am »
Jason,

Just to report back, your change in update 31133 did not resolve the problem. The devices still segfault the 50 times, then the screen session for the device is terminated.

Thanks for trying!

/Mike

4
Developers / Re: Slow and steady ... moving from Trac to Gitlab
« on: August 27, 2015, 05:32:45 am »
A separate post to give an idea of my frames of reference. At $day_job, my role is now architecture and integration to support SysAdmins (which I used to be).  To do that, and to support a varied environment consisting of many flavours of Unix, Linux, Hypervisors and hardware architectures, we implemented a configuration and compliance management tool known as Puppet.  Puppet uses it's own structured language to describe system end-states, and maintain them as a configuration and compliance engine.  So, basically, you have infrastructure as code.

So, when you have code, and a need to maintain transparency and sustainable, reproducible infrastructure, you need a version control system. Originally, that was Git and Trac for us, and we made the switch to GitLab a few months ago for better productivity and for integration into other tools like Jenkins. Because, when you deal with almost every form of *nix out there, keeping your infrastructure tooling consistent across all platforms is challenging. You can't always ensure that the vendors will be shipping exactly what you need, and so you can be dealing with even more variety in your tooling as well as the stuff your're trying to maintain! It's enough to make you want to smash something!  So, sometimes you need to roll it yourself in order to ensure you have what you need, just the way you need it, when you need it. So, we use Jenkins for building packages to ensure our infrastructure tooling is in lockstep across all platforms.

So, basically I'm a SysAdmin using GitLab to maintain the tools my team needs to manage hundreds of systems. Our Git workflow represents a fairly linear model as a result.  We're just always making releases to increase capabilities or service catalog products, or just to deal with the fact that things change (like System V init to systemd). As such, we maintain a fairly simple workflow.

Master is always production-ready. Features get developed in their own branches. The develop brand is where integration happens, and dedicated "life-cycle systems management" instances are subscribed to that branch for dev/test and regression testing. Releases are tagged, and pulled into master.  Master gets pulled into the systems management tool, and applied to client test/dev systems. Upon acceptance from them, they get applied to validation systems. If those are good, it gets air-gapped across to client staging/pre-prod instances and tested against a back-flush of prod.  Assuming no regressions, it gets promoted to Production systems. Rinse, repeat for next cycle.

So, in a lot of ways, workflow gets determined by how much risk someone is willing to accept. In a high availability environment, very little risk is accepted; hence a rigorous process with many gates and go/no-go decision points. Tooling always has to support the process. More risk tolerance lends itself to more of a continuous-integration type workflow, where small changes are integrated often and distributed widely, and the tooling usually supports a quick reversion capability if things go badly.

Most of the opensource projects that get used in the enterprise space operate on a two-pronged approach. Nightly builds for those who develop or who like living on the edge. Stable releases are for those who have to depend on it.

So, do we want to model or mimic workflows of similar projects (some of whom are on GitHub)?  The fork, branch, pull-request model does work well for most of those projects. We just need to consider the other tooling (like the builders)  and the overall release process for getting it out into the wild. However, LinuxMCE has challenges that something like OpenHab or AgoControl won't have. LMCE's "auto-magic" functionality requires deep hooks into operating system components, and those are OS version specific. So our processes and workflows may need to consider and allow for supporting an 'n', 'n+1', and 'n-1' release strategy.  Branching may or may not reflect that strategy, depending on how other processes and tooling handle it.

We have community contributors, and there's also Dianemo/CHT. Do we treat them any different from the community?  GitLab allows for personal workspaces and team workspaces... GitLab also allows for branches to be "protected", limiting those who can commit to it. This is a good idea for production branches.

More food for thought. Opportunities to cast aside legacy, and the cost is to consider all the options, and possibly blaze a new trail.

/Mike

5
Developers / Re: Slow and steady ... moving from Trac to Gitlab
« on: August 27, 2015, 03:54:23 am »
Ok.... It could be a case of the blind leading the blind here... ;p

To develop workflows, we'll have to decide on how we're going to handle branches and tags.  I'd suggest folks take a read here: https://about.gitlab.com/2014/09/29/gitlab-flow/

The "Gitlab" flow may be what we want to consider.  Right now, we have everything dumped into "master". Maybe we want to consider master as the common code repository, and create branches for each version release? That does mean maintaining pulls across however many streams (10.04, 12.04, 14.04) we intend to maintain. Tags can be used for release candidates or versions.

Or we go with master as production ready, and put conditionals into the code for every stream supported for the builders. Develop and feature branches are where all the work gets done. Tags can still be used to mark versions, milestones, RCs, etc.  Releases get pulled over to master for the builders to crank out release packages. Develop could get nightlies. 

I think a lot of this now comes down to release planning. Are we running a continuous integration type release process, or a waterfall staged type process?

Just some points to consider...  HTH!

/Mike

6
Users / Re: GSD issues - all devices died.
« on: August 21, 2015, 04:32:54 am »
Jason,

Thanks for the tip on using screen. Here's the output from each time the device dies.

Code: [Select]
LOG: ========== NEW LOG SECTION ==========
1       08/20/15 22:23:57       189 (spawning-device)   Starting... 40
1       08/20/15 22:23:57       189 (spawning-device)   Starting... 40
1       08/20/15 22:23:57       189 (spawning-device)   Found /usr/pluto/bin/Generic_Serial_Device
1       08/20/15 22:23:57       189 (spawning-device)   Found /usr/pluto/bin/Generic_Serial_Device
Generic_Serial_Device, v.2.0.0.46.15060430777
Visit www.plutohome.com for source code and license information

embed: [BUG] Segmentation fault
ruby 1.9.3p0 (2011-10-30 revision 33570) [i686-linux]

-- Control frame information -----------------------------------------------
c:0001 p:0000 s:0002 b:0002 l:ffffdfc4 d:ffffdfc4 TOP


-- C level backtrace information -------------------------------------------
/usr/lib/libruby-1.9.1.so.1.9(+0x15e4dd) [0x26e4dd]
/usr/lib/libruby-1.9.1.so.1.9(+0x4e111) [0x15e111] vfscanf.c:1784
/usr/lib/libruby-1.9.1.so.1.9(rb_bug+0x44) [0x15e8f4] vfscanf.c:1013
/usr/lib/libruby-1.9.1.so.1.9(+0xf7b5c) [0x207b5c] argp.h:586
[0xa20410]
/usr/lib/libruby-1.9.1.so.1.9(+0x63b24) [0x173b24] fxprintf.c:47
/usr/lib/libruby-1.9.1.so.1.9(+0x63c37) [0x173c37] printf-parsemb.c:152
/usr/lib/libruby-1.9.1.so.1.9(+0x656bf) [0x1756bf] libioP.h:985
/usr/lib/libruby-1.9.1.so.1.9(rb_newobj+0x23c) [0x17624c] iopopen.c:346
/usr/lib/libruby-1.9.1.so.1.9(+0x102d65) [0x212d65] ../sysdeps/unix/sysv/linux/readonly-area.c:88
/usr/lib/libruby-1.9.1.so.1.9(rb_enc_str_new+0x2a) [0x214faa] wcpcpy_chk.c:38
/usr/lib/libruby-1.9.1.so.1.9(+0xa252e) [0x1b252e] ../stdlib/strtod_l.c:1615
/usr/lib/libruby-1.9.1.so.1.9(+0xab6e7) [0x1bb6e7] getdate.c:270
/usr/lib/libruby-1.9.1.so.1.9(+0xb8dd5) [0x1c8dd5] ../sysdeps/unix/sysv/linux/i386/setgid.c:36
/usr/lib/libruby-1.9.1.so.1.9(+0x160601) [0x270601]
/usr/lib/libruby-1.9.1.so.1.9(+0xa24e1) [0x1b24e1] ../stdlib/strtod_l.c:1601
/usr/lib/libruby-1.9.1.so.1.9(rb_iseq_compile_with_option+0x64) [0x255cc4] ../sysdeps/i386/i686/multiarch/strcmp-ssse3.S:1853
/usr/lib/libruby-1.9.1.so.1.9(rb_iseq_compile+0x3b) [0x255eeb] ../sysdeps/i386/i686/multiarch/strcmp-ssse3.S:1950
/usr/lib/libruby-1.9.1.so.1.9(+0x15358a) [0x26358a]
/usr/lib/libruby-1.9.1.so.1.9(rb_eval_string+0x4f) [0x263bff]
/usr/pluto/bin/Generic_Serial_Device(_ZN7EMBRUBY11RubyEmbeder9_loadcodeEm+0x23) [0x8077e1d] RubyEmbeder.cpp:109
/usr/lib/libruby-1.9.1.so.1.9(rb_protect+0xce) [0x16299e] vfscanf.c:2318
/usr/pluto/bin/Generic_Serial_Device() [0x8077b54] RubyEmbeder.cpp:79
/usr/pluto/bin/Generic_Serial_Device() [0x808d448] RubyIOManager.cpp:463
/usr/pluto/bin/Generic_Serial_Device(_ZN3DCE8IOThread11_threadprocEPv+0x2a) [0x80775fe] IOThread.cpp:79
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c) [0x597d4c] pthread_create.c:308
/lib/i386-linux-gnu/libc.so.6(clone+0x5e) [0xe46b8e] ../sysdeps/unix/sysv/linux/i386/clone.S:130

-- Other runtime information -----------------------------------------------

* Loaded script: embed

* Loaded features:

    0 enumerator.so

* Process memory map:

00110000-0030e000 r-xp 00000000 fd:01 131209     /usr/lib/libruby-1.9.1.so.1.9.1
0030e000-00311000 r--p 001fd000 fd:01 131209     /usr/lib/libruby-1.9.1.so.1.9.1
00311000-00313000 rw-p 00200000 fd:01 131209     /usr/lib/libruby-1.9.1.so.1.9.1
00313000-00323000 rw-p 00000000 00:00 0
00323000-00341000 r-xp 00000000 fd:01 654464     /usr/pluto/lib/libSerializeClass.so
00341000-00342000 r--p 0001d000 fd:01 654464     /usr/pluto/lib/libSerializeClass.so
00342000-00343000 rw-p 0001e000 fd:01 654464     /usr/pluto/lib/libSerializeClass.so
00343000-00357000 r-xp 00000000 fd:01 1442801    /lib/i386-linux-gnu/libz.so.1.2.3.4
00357000-00358000 r--p 00013000 fd:01 1442801    /lib/i386-linux-gnu/libz.so.1.2.3.4
00358000-00359000 rw-p 00014000 fd:01 1442801    /lib/i386-linux-gnu/libz.so.1.2.3.4
00359000-00383000 r-xp 00000000 fd:01 1455536    /lib/i386-linux-gnu/libm-2.15.so
00383000-00384000 r--p 00029000 fd:01 1455536    /lib/i386-linux-gnu/libm-2.15.so
00384000-00385000 rw-p 0002a000 fd:01 1455536    /lib/i386-linux-gnu/libm-2.15.so
00385000-0038d000 r-xp 00000000 fd:01 1455548    /lib/i386-linux-gnu/libcrypt-2.15.so
0038d000-0038e000 r--p 00007000 fd:01 1455548    /lib/i386-linux-gnu/libcrypt-2.15.so
0038e000-0038f000 rw-p 00008000 fd:01 1455548    /lib/i386-linux-gnu/libcrypt-2.15.so
0038f000-003b6000 rw-p 00000000 00:00 0
003d5000-003dc000 r-xp 00000000 fd:01 654359     /usr/pluto/lib/libSerial.so
003dc000-003dd000 r--p 00006000 fd:01 654359     /usr/pluto/lib/libSerial.so
003dd000-003de000 rw-p 00007000 fd:01 654359     /usr/pluto/lib/libSerial.so
003de000-004bf000 r-xp 00000000 fd:01 655506     /usr/pluto/lib/libDCECommon.so
004bf000-004c0000 r--p 000e0000 fd:01 655506     /usr/pluto/lib/libDCECommon.so
004c0000-004c3000 rw-p 000e1000 fd:01 655506     /usr/pluto/lib/libDCECommon.so
004c3000-004d4000 rw-p 00000000 00:00 0
0056c000-0058c000 r-xp 00000000 fd:01 1455488    /lib/i386-linux-gnu/ld-2.15.so
0058c000-0058d000 r--p 0001f000 fd:01 1455488    /lib/i386-linux-gnu/ld-2.15.so
0058d000-0058e000 rw-p 00020000 fd:01 1455488    /lib/i386-linux-gnu/ld-2.15.so
00591000-005a8000 r-xp 00000000 fd:01 1447355    /lib/i386-linux-gnu/libpthread-2.15.so
005a8000-005a9000 r--p 00016000 fd:01 1447355    /lib/i386-linux-gnu/libpthread-2.15.so
005a9000-005aa000 rw-p 00017000 fd:01 1447355    /lib/i386-linux-gnu/libpthread-2.15.so
005aa000-005ac000 rw-p 00000000 00:00 0
005e9000-0064a000 r-xp 00000000 fd:01 654266     /usr/pluto/lib/libPlutoUtils.so
0064a000-0064b000 r--p 00061000 fd:01 654266     /usr/pluto/lib/libPlutoUtils.so
0064b000-0064d000 rw-p 00062000 fd:01 654266     /usr/pluto/lib/libPlutoUtils.so
00692000-0076a000 r-xp 00000000 fd:01 131619     /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
0076a000-0076b000 ---p 000d8000 fd:01 131619     /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
0076b000-0076f000 r--p 000d8000 fd:01 131619     /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
0076f000-00770000 rw-p 000dc000 fd:01 131619     /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16
00770000-00777000 rw-p 00000000 00:00 0
00782000-0078d000 r-xp 00000000 fd:01 1454921    /lib/i386-linux-gnu/libnss_files-2.15.so
0078d000-0078e000 r--p 0000a000 fd:01 1454921    /lib/i386-linux-gnu/libnss_files-2.15.so
0078e000-0078f000 rw-p 0000b000 fd:01 1454921    /lib/i386-linux-gnu/libnss_files-2.15.so
007c4000-007e0000 r-xp 00000000 fd:01 1439086    /lib/i386-linux-gnu/libgcc_s.so.1
007e0000-007e1000 r--p 0001b000 fd:01 1439086    /lib/i386-linux-gnu/libgcc_s.so.1
007e1000-007e2000 rw-p 0001c000 fd:01 1439086    /lib/i386-linux-gnu/libgcc_s.so.1
00887000-008c1000 r-xp 00000000 fd:01 654944     /usr/pluto/lib/libMessageTranslation.so
008c1000-008c2000 r--p 0003a000 fd:01 654944     /usr/pluto/lib/libMessageTranslation.so
008c2000-008c3000 rw-p 0003b000 fd:01 654944     /usr/pluto/lib/libMessageTranslation.so
008c3000-008c4000 rw-p 00000000 00:00 0
0093a000-0093d000 r-xp 00000000 fd:01 1455565    /lib/i386-linux-gnu/libdl-2.15.so
0093d000-0093e000 r--p 00002000 fd:01 1455565    /lib/i386-linux-gnu/libdl-2.15.so
0093e000-0093f000 rw-p 00003000 fd:01 1455565    /lib/i386-linux-gnu/libdl-2.15.so
00a20000-00a21000 r-xp 00000000 00:00 0          [vdso]
00a40000-00cdc000 r-xp 00000000 fd:01 135635     /usr/lib/i386-linux-gnu/libmysqlclient.so.18.0.0
00cdc000-00cdf000 r--p 0029c000 fd:01 135635     /usr/lib/i386-linux-gnu/libmysqlclient.so.18.0.0
00cdf000-00d55000 rw-p 0029f000 fd:01 135635     /usr/lib/i386-linux-gnu/libmysqlclient.so.18.0.0
00d55000-00d58000 rw-p 00000000 00:00 0
00d58000-00efb000 r-xp 00000000 fd:01 1455578    /lib/i386-linux-gnu/libc-2.15.so
00efb000-00efd000 r--p 001a3000 fd:01 1455578    /lib/i386-linux-gnu/libc-2.15.so
00efd000-00efe000 rw-p 001a5000 fd:01 1455578    /lib/i386-linux-gnu/libc-2.15.so
00efe000-00f01000 rw-p 00000000 00:00 0
00f2c000-00f33000 r-xp 00000000 fd:01 1455485    /lib/i386-linux-gnu/librt-2.15.so
00f33000-00f34000 r--p 00006000 fd:01 1455485    /lib/i386-linux-gnu/librt-2.15.so
00f34000-00f35000 rw-p 00007000 fd:01 1455485    /lib/i386-linux-gnu/librt-2.15.so
08048000-080b3000 r-xp 00000000 fd:01 552583     /usr/pluto/bin/Generic_Serial_Device
080b3000-080b4000 r--p 0006b000 fd:01 552583     /usr/pluto/bin/Generic_Serial_Device
080b4000-080b5000 rw-p 0006c000 fd:01 552583     /usr/pluto/bin/Generic_Serial_Device
09364000-09478000 rw-p 00000000 00:00 0          [heap]
b4800000-b4828000 rw-p 00000000 00:00 0
b4828000-b4900000 ---p 00000000 00:00 0
b4a00000-b4afa000 rw-p 00000000 00:00 0
b4afa000-b4b00000 ---p 00000000 00:00 0
b4bff000-b4c00000 ---p 00000000 00:00 0
b4c00000-b5400000 rw-p 00000000 00:00 0
b5400000-b545e000 rw-p 00000000 00:00 0
b545e000-b5500000 ---p 00000000 00:00 0
b5538000-b55dc000 rw-p 00000000 00:00 0
b55ff000-b5600000 ---p 00000000 00:00 0
b5600000-b5e00000 rw-p 00000000 00:00 0
b5e00000-b5e21000 rw-p 00000000 00:00 0
b5e21000-b5f00000 ---p 00000000 00:00 0
b5f1f000-b5f20000 ---p 00000000 00:00 0
b5f20000-b6720000 rw-p 00000000 00:00 0
b6720000-b6721000 ---p 00000000 00:00 0
b6721000-b6f21000 rw-p 00000000 00:00 0
b6f21000-b6f22000 ---p 00000000 00:00 0
b6f22000-b7728000 rw-p 00000000 00:00 0
b773d000-b773e000 rw-p 00000000 00:00 0
b773e000-b773f000 ---p 00000000 00:00 0
b773f000-b7746000 rw-p 00000000 00:00 0
bfe5b000-bfe7c000 rw-p 00000000 00:00 0          [stack]


[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html

/usr/pluto/bin/Spawn_Device.sh: line 170: 17427 Aborted                 (core dumped) /usr/pluto/bin/Spawn_Wrapper.sh "$Path$cmd_line" -d "$device_id" -r "$ip_of_router" -l "$LogFile"
LOG: Return code: 134
3       08/20/15 22:23:57       189 (spawning-device)   Device died... count=40/50 dev=189
3       08/20/15 22:23:57       189 (spawning-device)   Device died... count=40/50 dev=189
LOG: Thu Aug 20 22:23:58 EDT 2015 died
^C
[screen is terminating]


It's 12.04 updated to the latest GSD package and Ruby 1.9.1. The GSD device is segfaulting. Someone more knowledgeable about the GSD device and C have any ideas?

Thanks!

/Mike

7
Developers / Re: Slow and steady ... moving from Trac to Gitlab
« on: August 12, 2015, 05:58:16 am »
Sweeet!  And thanks for your efforts! 

At work, we switched from Git/Trac to Git/Gitlab, and it's sooo much more of a productive environment. We've got hooks from certain projects into Jenkins for building RPM's 5 minutes after a commit, and that's sweet from a packaging point of view. Jenkins really rocks as well!  (BTW, there's a .deb builder plugin for Jenkins if that's of interest to you)

I have a small request of you and the core devs.  Gitlab represents a real opportunity to enable more people to get involved in LinuxMCE development and testing. In the past, I didn't want to have any form of SVN access;  I know enough to know I don't know enough about LMCE to event want any commit access (bull in a china shop syndrome). So, that limited me to filing tickets with diffs attached.

Gitlab changes all of that. The core devs can steward the main linuxmce project, and personal workspaces allow more novice folks like myself the opportunity to contribute through an isolated environment and merge requests. So, I would like to make the following request:

Could you folks create a wiki page with some example workflows that would enable folks like myself to contribute more, while minimizing the level of effort on the core devs to take advantage of what we do?

I'm thinking of example workflows like:
  • simple bug fix for existing code
  • significant bug fix for existing code or refactoring
  • simple new feature (new code)
  • significant new feature (majorly intrusive)

I think that giving us examples of how you want us to work would be good for us novices to learn, while making life easier for those already overcommitted core devs.   Maybe even a quick page on how issues should be filed might be good for standardizing and leveraging Gitlab's capabilities...

Just thought I'd put this out there for your consideration.

Thanks again for your hard work on this!  I'm sure it wasn't easy, but it will be worth it in the long run!

/Mike

8
Users / Re: GSD issues - all devices died.
« on: August 12, 2015, 05:29:16 am »
Jason,

Thanks for the quick response!  I'm a Canuck as well, in Ottawa, so we have the same Tstat. You're in Kingston, right?

Nice to see you're using DT2243; I did some work on that one a ways back. Still have some ideas for it; they'll have to wait.  I'll re-sync up my local code with what's in SQLCVS and see what's changed, and go from there.

The ISY template has some major changes coming, so I may have to revert my local code to match SQLCVS, and then slowly roll forward with the new code. I have a Z-wave module coming soon for my ISY, so I hope to add support for that in the next batch of updates.

Is most of the development effort towards putting out a 12.04 release, or going past it to 14.04 instead?  Just wondering where to expend my effort...

Thanks for the assistance!

/Mike

9
Users / Re: GSD issues - all devices died.
« on: August 12, 2015, 03:03:10 am »
Ruby will not be reverted to 1.8 going forward.  1204 is using Ruby 1.9.1 and 1404 is using Ruby 2.0.

There have been many changes in the ruby language that are biting some people during the alpha transition.  These issues will need to be worked through.  The biggest issue is changes in ruby syntax from 1.8->1.9.1.

Again, the issue here is ruby syntax changes.  Device Templates will have to be updated and will not be backwards compatible unless people are very careful about the changes.

I have a RadioThermostat here.  I am having very few issues with it since updating the ruby code.  Please do an sqlcvs update to get the latest code for it.  It should be completely backwards compatible with ruby 1.8 as well.

J.

Phenigma,

A few questions if you don't mind...

Which Radio Thermostat template are you using; The 3M50 or the CT-30/CT-80 one?  Which model thermostat do you have?  I'm running a CT-80 myself...

It also sounds like you've seen some common changes that have to be done to the templates. Could you point out what you've seen, so I have an idea as to where to start if I have to debug the ISY template?

Thanks to you and posde for your guidance on this!

/Mike


10
Users / Re: GSD issues - all devices died.
« on: August 07, 2015, 05:34:25 am »
The Forum software limits the attachment size, so I can't post the GSD package here.

Looking into other options.

HTH!

/Mike

11
Users / GSD issues - all devices died.
« on: August 04, 2015, 04:06:35 am »
Hi folks!

I have an issue with all my GSD devices are dying and re-spawning until they hit the 50 retries. Both (the Radio Thermostat and the ISY994i driver) die with the same result code.

Code: [Select]
1843:#### START SETTERS #############################################################
#######
1844:def initialize()
1845:super
1846:@returnParamArray=Array.new
1847:end
1848:####  END  SETTERS #############################################################
#######
1849:end
1851:Return code: 134
3       08/03/15 09:59:41       189 (spawning-device)   Device died... count=34
/50 dev=189

I'm running 12.04 with the latest updates.  I notice from the 12.04 Wiki page that the requirement for Ruby 1.9 was added recently. Both Ruby 1.8 and 1.9 are presently on the system.

I'm wondering if anyone else has experienced similar issues. My likely next steps are to look at either reverting the 1.9 installation back to 1.8, or removing all the 1.8 Ruby packages. 

Anyone know what result code 134 means?

Thanks!

/Mike

Update:  I reverted back to pluto-generic-serial-device_2.0.0.46.14081629241_i386.deb (as it was the only previous version I could find in my package caches), and removed Ruby 1.9, restarted DCERouter, and my GSD devices are back in business!

/Mike

12
Installation issues / Re: NIC Issue (Working Solution)
« on: August 04, 2015, 03:54:57 am »
Huh,

I've seen the same thing on a number of occasions.  Looks like one of the networking "automagic" scripts is leaving a template stub behind after it's done it's business. Haven't had time to track it down and lodge a ticket/patch.

Just wanted to confirm that you aren't the only one who's seen it.

HTH!

/Mike

13
Installation issues / Re: LMCE-1404 20150308181930157 reboot loop
« on: March 28, 2015, 04:11:54 am »
Phenigma,

14.04 is using Samba 4.1, vs the Samba 3 in 12.04. There was/is a bug in the Ubuntu issue tracker for nmbd starting before smbd, so that could be an issue.  There's also two new init scripts in /etc/init.d (samba and samba-ad-dc) which may play into this.  It could also be that the current LMCE managed smb.conf file is not compatible with Samba 4.1.

I haven't looked into this specifically, but I am starting to look at Samba AD support in 14.04 (playing with Zentyal 4 right now).

Just thought I'd point that out as a possibility.  HTH!

/Mike


14
Developers / Re: Developing a Weather Plugin, videos
« on: December 23, 2014, 05:17:23 am »
Thanks Thom and Phenigma! 

Much appreciated!  I hope Thom's feeling better soon, so he can enjoy the holidays!

(Unfortunately, you have to get used to it;  when you have young kids, they pretty much get sick every winter for the first 6 years.  Been there, done that twice; now dealing with the "tween" stage  ;) )

Happy Holidays to the LMCE community!

/Mike

15
Developers / Re: Developing a Weather Plugin, videos
« on: December 22, 2014, 04:10:19 am »
Thom,

Looks like there's a missing graphic file that's causing the proxy orbitor to crash when selecting the radar button, if there isn't a radar graphic in the feed.  I would've filed it into Trac, but it doesn't seem to use the same credentials as the forum.

In the file here:  http://svn.linuxmce.org/trac/browser/trunk/src/Weather_PlugIn/Weather_PlugIn.cpp

Line 54 references #define FILE_NO_RADAR_DATA "/usr/pluto/share/weather_no_radar_data.jpg"

That file is not present in the latest packages.  Everything else seems to be working fine though!

I've got current conditions going from the ISY driver to the weather plugin, and it's working well. Just working on getting all the forecast stuff parsing properly from the ISY subscription feed, and then that'll be straight forward to feed into your weather plugin.

Excellent work!  Thanks!

/Mike

Pages: [1] 2 3 ... 15