Hi Peter,
Thanks for giving it another shot. Getting comments from people like
you is exactly why I announced the changes. Let's see if we can close
in on the problems:
I rearranged things so that the python in particular is installable in a
somewhat more conventional way.
The tests directory is now under the cma directory. I need to fix the
README.
Alltests is also no longer the right way to test it. I'd forgotten
these things were in the README. That's pretty old information.
Sorry :-(
One thing you can count on is that I _always_ test before pushing
upstream. My scripts for pushing upstream will refuse if the version it
creates in a clean workspace fails the tests. So, differences are
likely due to documentation errors or lingering assumptions about how I
set up my build environment.
The code now looks for the discovery scripts in /usr/share... They will
only be there if you've done a make install.
But you said something below that I didn't understand, so I can't offer
advice:
THIS STILL REFERENCE FILES THAT IS'NT there, You get mainlooptest: No such ...
Are you referring to this message?
/bin/sh: 1: /usr/share/assimilation/discovery_agents/netconfig: not
found
If so, the make install will take care of this. If not, then I didn't
understand your comment.
Oh... I bet I know what it is... I tend to build in the same tree as the
source is in. If you don't, that script might not work. I see that my
scripts make some assumptions about where the source and build trees are
relative to each other.
So I need to do this:
- clean up the documentation to match current practices (short term) [DONE]
- fix the relative pathname issues in grind.sh, and also update the
documentation [DONE]
- add some way to override where it looks for the discovery scripts so
that make install isn't necessary
(longer term) and you can test new versions of the discovery
scripts without doing a make install
In my experience, I expect to see a small number of issues with valgrind
on new/different platforms. These typically aren't memory leaks in my
program, but are associated with the glib library and how it manages
storage.
Thanks for giving this a shot. Let me know what problems you still have
after doing a make install on the newest version.
On 10/16/2012 01:41 AM, Peter Sørensen wrote:
> Hi Allan,
>
> Thanks. I've just downloaded a new copy and
> This compiles OK.
>
> Still problems with testing.
>
> README file states:
>
> @section TestingIt Running our Tests
> They are currently two test modules you can run after building it. They can
> be run
> like this:
> - cd tests, python ./alltest.....
> THIS DIR DOES'NT EXIST !!
> - cd testcode; sh ./grind.sh
> HERE the refs to maillooptest and valgrind-msg.supp are wrong. Correcting them
> Gives below and not sure how to get further.
>
> Regards
>
> Peter
>
>
> ** Message: Our OS supports dual ipv4/v6 sockets. Hurray!
> ** Message: json_discovery_new:
> FULLPATH=[/usr/share/assimilation/discovery_agents/netconfig]
> discoverytype[netconfig]
> ** Message: _jsondiscovery_discover: don't have [cmadisc] address yet -
> continuing.
> /bin/sh: 1: /usr/share/assimilation/discovery_agents/netconfig: not found
>
> ** (process:6565): WARNING **: JSON discovery from
> /usr/share/assimilation/discovery_agents/netconfig failed with status 0x7f00
> (32512) ==6565== 4 bytes in 1 blocks are still reachable in loss record 3 of
> 143
> ==6565== at 0x402BE68: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==6565== by 0x40EFFBE: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.3)
> ==6565== by 0x40F0947: g_private_get (in
> /lib/i386-linux-gnu/libglib-2.0.so.0.3200.3)
> ==6565== by 0x40B8570: g_logv (in
> /lib/i386-linux-gnu/libglib-2.0.so.0.3200.3)
> ==6565== by 0x40B8822: g_log (in
> /lib/i386-linux-gnu/libglib-2.0.so.0.3200.3)
> ==6565== by 0x417C4D2: (below main) (libc-start.c:226)
> ==6565==
> ==6565== 4 bytes in 1 blocks are still reachable in loss record 5 of 143
> ==6565== at 0x402BE68: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==6565== by 0x40B69AA: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.3)
> ==6565== by 0x40B6E42: g_malloc (in
> /lib/i386-linux-gnu/libglib-2.0.so.0.3200.3)
> ==6565== by 0x40CCC33: g_memdup (in
> /lib/i386-linux-gnu/libglib-2.0.so.0.3200.3)
>
>
> THIS STILL REFERENCE FILES THAT IS'NT there, You get mainlooptest: No such ...
>
> And I can't find it anywhere.
>
> Best regards
>
>
> Peter
> ----------------
> Hi,
>
> We've had a couple of compilation, install, and run issues.
>
> You should be able to compile and install it now.
>
> make install should install it somewhere reasonable...
>
>
> Let me know what you find out!
>
> Thanks for your feedback!
>
> It still defaults to some of my home network addresses. That's next to fix.
>
--
Alan Robertson <[email protected]> - @OSSAlanR
"Openness is the foundation and preservative of friendship... Let me claim
from you at all times your undisguised opinions." - William Wilberforce
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
