-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Could you try this for testing method from the latest README?
- -----------------------------------------------------
There are currently two test modules that you can run after building
it. They can be run
like this:
- - cd testcode; sh path-to-source-tree/testcode/grind.sh # Assumes you
have valgrind installed.
- - cd cma; testify tests # Runs
significant python tests
For the testcode piece, you have to be in the cma directory of <i>build
tree</i>.
For the testify portion, you have to either be in the cma directory of
the source tree
or the installed version in the python install place
(on my machine that's currently
/usr/lib/python2.7/dist-packages/assimilation)
- ---------------------------------------------------------
There is a part of the C-based tests that won't work without doing a
make install. I don't think it causes the test to fail - although it
should.
So, for your environment, you might try this:
cd cma; testify tests
And, if you want to run the 'C'-based tests, you can do this:
cd testcode; sh ./grind.sh
Let me know what you find out. Thanks!
And thanks for your patience!
On 10/16/2012 10:25 AM, David Klann wrote:
> Hi Alan,
>
> Here's a build and test report on a current Gentoo system.
>
> Downloaded from the Hg repo (changeset: 288:3c9a24c075cc), and updated
> after your most recent email to Peter S. (below).
>
> I believe I'm building in the source tree; that is, I did "hg clone"
> followed by "cd assimilation", and followed the build instructions in
> README. I have all the dependencies installed (including the
> "optional" documentation tools).
>
> After what appears to be a successful build, here's what I do, and
> what I see.
>
> % ( cd cma/tests; python ./cma_test.py )
> Traceback (most recent call last):
> File "./cma_test.py", line 9, in <module>
> from frameinfo import *
> ImportError: No module named frameinfo
>
> Maybe I need to "make install"??? I haven't spent *any* time
> troubleshooting this (I'm working my day job tasks at the same
> time...), and I'm just guessing at the name of the test script to run.
>
> I can send more output if you'd like to see it.
>
> Thanks for all your work on this!
>
> ~David Klann
>
>
> On Tue, 16 Oct 2012 08:21:34 -0600 you coerced some electrons to say:
>
>> 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
- --
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlB9kJkACgkQNkLhYXF6ZA7gBgCfXFzqwtFpZjzygSvy5rmnsXCd
y0gAn08eI9yRmvE61T629cBHFLdfXaPU
=l9+a
-----END PGP SIGNATURE-----
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
