[Assimilation] Missing dependencies now available in official EPEL and Fedora 18/19
Hi, These are the dependencies that were previously unavailable on RPM systems: python-ctypesgen python-py2neo (+ python3-py2neo) python-testify They are now all packaged and ready to install from the official repositories. However, one issue is the version of python-py2neo. I've packaged version 1.5 which I gather assimilation is not yet compatible with. Alan, what's the situation regarding py2neo? If there are significant API changes, I can try to create a parallel installable python-py2neo14 package or something. (NB: In my repository, the version of python-py2neo is 1.4.6 and the assimilation packages conflict with newer versions, so you'll still be able to install assimilation. You just have to do pass --skip-broken every time you want to do a yum update.) Kind regards, -- Jamie Nguyen ___ Assimilation mailing list - Discovery-Driven Monitoring Assimilation@lists.community.tummy.com http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
Re: [Assimilation] Missing dependencies now available in official EPEL and Fedora 18/19
On 16/07/13 10:40, Jamie Nguyen wrote: These are the dependencies that were previously unavailable on RPM systems: python-ctypesgen python-py2neo (+ python3-py2neo) python-testify They are now all packaged and ready to install from the official repositories. However, one issue is the version of python-py2neo. I've packaged version 1.5 which I gather assimilation is not yet compatible with. Alan, what's the situation regarding py2neo? If there are significant API changes, I can try to create a parallel installable python-py2neo14 package or something. (NB: In my repository, the version of python-py2neo is 1.4.6 and the assimilation packages conflict with newer versions, so you'll still be able to install assimilation. You just have to do pass --skip-broken every time you want to do a yum update.) Oh I forgot that neo4j is still only available in my repository, so not quite all the dependencies are official yet, but almost there :-) Kind regards, -- Jamie Nguyen ___ Assimilation mailing list - Discovery-Driven Monitoring Assimilation@lists.community.tummy.com http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
Re: [Assimilation] RPATH question as to SRPMs
On 02/07/13 21:00, R P Herrold wrote: On Tue, 2 Jul 2013, Jamie Nguyen wrote: I have just updated the SPEC and SRPM to version 0.1.0-0.22.20130623hge529aa0d0e98 http://jamielinux.fedorapeople.org/assimilation/SRPMS/ testing in process I note the file shown at your archive is built without an externally visible EVR Are you talking about the fact that the filename is assimilation-cma.src.rpm instead of assimilation-cma-VERSION.src.rpm ? That was a shortcut I took so that the latest SRPM/SPEC were always available at the same link, but I've added the versioned files now too: http://jamielinux.fedorapeople.org/assimilation/ -- Jamie Nguyen ___ Assimilation mailing list - Discovery-Driven Monitoring Assimilation@lists.community.tummy.com http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
Re: [Assimilation] RPATH question as to SRPMs, more ...
On 02/07/13 22:21, R P Herrold wrote: On Tue, 2 Jul 2013, R P Herrold wrote: testing in process Sadly the new version fairy did not fix the rpath issue; I've drilled in the 'hard way' fix to a local .spec file and am testing further. diff of the revised spec file sections at the end of this email That gets me past the RPATH issue, but there later seems to be a library issue as well: Haven't been able to reproduce the library issue but will take a closer look when I have time. Thanks for looking into the rpath issue. I found a much easier way to fix that with the -DCMAKE_SKIP_BUILD_RPATH=1 cmake flag while building, which I'm hoping achieves pretty much the same thing (though my I only have a rudimentary understanding of cmake). http://jamielinux.fedorapeople.org/assimilation/ -- Jamie Nguyen ___ Assimilation mailing list - Discovery-Driven Monitoring Assimilation@lists.community.tummy.com http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
[Assimilation] Errors when running CMA
Hi Alan, I've not had much of a chance to debug, but on the latest packages I'm getting this error when starting the CMA. Can you point me in the right direction? I think it might be my fault somehow.. Jul 5 22:45:42 jab0 systemd[1]: Starting Collective Management Authority (CMA) for Assimilation... Jul 5 22:45:42 jab0 systemd[1]: Started Collective Management Authority (CMA) for Assimilation. Jul 5 22:45:42 jab0 cma[1399]: Traceback (most recent call last): Jul 5 22:45:42 jab0 cma[1399]: File /usr/lib64/python2.7/site-packages/assimilation/cma.py, line 290, in module Jul 5 22:45:42 jab0 cma[1399]: sys.exit(main()) Jul 5 22:45:42 jab0 cma[1399]: File /usr/lib64/python2.7/site-packages/assimilation/cma.py, line 226, in main Jul 5 22:45:42 jab0 cma[1399]: io = pyReliableUDP(config, pyPacketDecoder(0)) Jul 5 22:45:42 jab0 cma[1399]: File /usr/lib64/python2.7/site-packages/assimilation/AssimCclasses.py, line 1019, in __init__ Jul 5 22:45:42 jab0 cma[1399]: pyAssimObj.__init__(self, Cstruct=Cstruct) Jul 5 22:45:42 jab0 cma[1399]: File /usr/lib64/python2.7/site-packages/assimilation/AssimCclasses.py, line 346, in __init__ Jul 5 22:45:42 jab0 cma[1399]: assert type(Cstruct) is not int Jul 5 22:45:42 jab0 cma[1399]: AssertionError Jul 5 22:45:42 jab0 systemd[1]: assimilation-cma.service: main process exited, code=exited, status=1/FAILURE Jul 5 22:45:42 jab0 systemd[1]: Unit assimilation-cma.service entered failed state. -- Jamie Nguyen ___ Assimilation mailing list - Discovery-Driven Monitoring Assimilation@lists.community.tummy.com http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
Re: [Assimilation] Just tagged RC4
On 15/04/13 00:08, Alan Robertson wrote: I just tagged 0.1.0-RC4 -- release candidate 4 for this first (0.1.0) release. Hi Alan, Builds fine on Fedora 18 but getting an error when building on CentOS 6. Probably related to version of glib2 (2.22.5). DEBUG: [ 64%] Building C object clientlib/CMakeFiles/assimilationclientlib.dir/misc.c.o DEBUG: cd /builddir/build/BUILD/assimilation-20130414hg953f5c3a4e4b/build/clientlib /usr/lib/ccache/gcc -Dassimilationclientlib_EXPORTS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -g -fPIC -I/builddir/build/BUILD/assimilation-20130414hg953f5c3a4e4b/include -I/builddir/build/BUILD/assimilation-20130414hg953f5c3a4e4b/build/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include-g -O2 -Werror -Wall -Wformat=2 -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wdeclaration-after-statement -Wpointer-arith -Wwrite-strings -Wcast-align -Winline -Wmissing-format-attribute -Wno-strict-aliasing -funsigned-char -Wextra -Wstack-protector -Wformat-security -D_FORTIFY_SOURCE=2 -o CMakeFiles/assimilationclientlib.dir/misc.c.o -c /builddir/build/BUILD/assimilation-20130414hg953f5c3a4e4b/clientlib/misc.c DEBUG: cc1: warnings being treated as errors DEBUG: /builddir/build/BUILD/assimilation-20130414hg953f5c3a4e4b/clientlib/misc.c: In function 'assim_merge_environ': DEBUG: /builddir/build/BUILD/assimilation-20130414hg953f5c3a4e4b/clientlib/misc.c:551: error: implicit declaration of function 'g_get_environ' DEBUG: /builddir/build/BUILD/assimilation-20130414hg953f5c3a4e4b/clientlib/misc.c:551: error: assignment makes pointer from integer without a cast Kind regards, -- Jamie Nguyen ___ Assimilation mailing list - Discovery-Driven Monitoring Assimilation@lists.community.tummy.com http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
Re: [Assimilation] Just tagged RC4
On 15/04/13 18:11, Jamie Nguyen wrote: RPMS updated to 0.1.0-RC4 plus the above commit. Stuff in the usual places: Spec: http://jamielinux.fedorapeople.org/assimilation/assimilation.spec Oops, that was meant to say: Spec: http://jamielinux.fedorapeople.org/assimilation/assimilation-cma.spec Kind regards, -- Jamie Nguyen ___ Assimilation mailing list - Discovery-Driven Monitoring Assimilation@lists.community.tummy.com http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
Re: [Assimilation] Just tagged RC4
On 15/04/13 18:31, Alan Robertson wrote: OK. I just /re/-tagged RC4 to include this patch. Not an ideal circumstance, but seems more useful than the alternative... Sorry I didn't get this in before you tagged! -- Jamie Nguyen ___ Assimilation mailing list - Discovery-Driven Monitoring Assimilation@lists.community.tummy.com http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
Re: [Assimilation] 0.1.0 Release Candidate 2 is out!
On 26/03/13 22:27, Jamie Nguyen wrote:
On 26/03/13 21:49, Alan Robertson wrote:
I don't see this problem on my systems...
I'm running both of these systems from the pip-extracted versions of
ctypesgen.py. Don't know if it matters...
Just to make sure, I removed the source I had, and re-extracted it and
rebuilt it. Same results.
Hmm ok so I did a build outside of mock and it doesn't have the error,
so it seems to be something different happening inside mock. Haven't
quite figured out why this is the case, but I guess something to do with
ctypesgen.
It appears the ordering of *.h files is the problem, which is related to
this line in buildtools/genpybindings.py:
hdrfiles=os.listdir(includedir)
As I understand, the ordering of listdir is arbitrary (and things like
the filesystem affect it). Here are the orders I'm getting, the first
set is working and the second set is giving the parsing error.
[no errors]
os.listdir('include')
['proj_classes.h', 'packetdecoder.h', 'compressframe.h', 'cryptframe.h',
'fsqueue.h', 'projectcommon.h.in', 'jsondiscovery.h', 'server_dump.h',
'hbsender.h', 'assimobj.h', 'listener.h', 'cmalib.h', 'nanoprobe.h',
'frameset.h', 'signframe.h', 'reliableudp.h', 'netio.h', 'seqnoframe.h',
'netaddr.h', 'pcap_min.h', 'address_family_numbers.h', 'pcap_GSource.h',
'addrframe.h', 'netgsource.h', 'generic_tlv_min.h', 'unknownframe.h',
'tlvhelper.h', 'hblistener.h', 'tlv_valuetypes.h', 'misc.h',
'intframe.h', 'discovery.h', 'configcontext.h', 'switchdiscovery.h',
'CMakeLists.txt', 'nvpairframe.h', 'cdp.h', 'cstringframe.h',
'netioudp.h', 'authlistener.h', 'ipportframe.h', 'frame.h',
'fsprotocol.h', 'lldp.h']
[parsing error]
os.listdir('include')
['fsqueue.h', 'listener.h', 'packetdecoder.h', 'netaddr.h',
'nanoprobe.h', 'jsondiscovery.h', 'cstringframe.h', 'tlvhelper.h',
'hbsender.h', 'proj_classes.h', 'switchdiscovery.h', 'hblistener.h',
'configcontext.h', 'misc.h', 'authlistener.h', 'pcap_min.h',
'generic_tlv_min.h', 'addrframe.h', 'pcap_GSource.h',
'projectcommon.h.in', 'ipportframe.h', 'nvpairframe.h', 'netio.h',
'seqnoframe.h', 'unknownframe.h', 'assimobj.h', 'compressframe.h',
'signframe.h', 'intframe.h', 'reliableudp.h', 'fsprotocol.h',
'netgsource.h', 'cryptframe.h', 'cmalib.h', 'discovery.h', 'cdp.h',
'server_dump.h', 'netioudp.h', 'CMakeLists.txt', 'lldp.h',
'tlv_valuetypes.h', 'address_family_numbers.h', 'frameset.h', 'frame.h']
It would appear that certain orders cause problems, so I guess the fix
would be to either sort or specify an explicit order manually.
Manually writing the arguments for ctypesgen to match the order of
header files in the first set made the errors disappear. I also tried
just sorting them and the errors disappeared after I applied this patch:
--- a/buildtools/genpybindings.py
+++ b/buildtools/genpybindings.py
@@ -97,7 +97,7 @@
# Starting with the full pathname to glib.h
args.append(findincfile(glibincdirs, glibheaderfile))
# Add on the pathnames of all our header files
-hdrfiles=os.listdir(includedir)
+hdrfiles=sorted(os.listdir(includedir))
hfileset={}
for hfile in hdrfiles:
if not hfile.endswith('.h'):
Kind regards,
--
Jamie Nguyen
___
Assimilation mailing list - Discovery-Driven Monitoring
Assimilation@lists.community.tummy.com
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
Re: [Assimilation] 0.1.0 Release Candidate 2 is out!
On 26/03/13 02:16, Alan Robertson wrote: I've just finished tagging RC2 for the first release (0.1.0) - WOOT WOOT!! The tag is v0.1.0-RC2. Jamie Nguyen has an RPM spec file for Fedora that you can find here: http://jamielinux.fedorapeople.org/assimilation/assimilation-cma.spec Jamie is pretty much overwhelmed with school (as he should be). If he plays hooky enough to produce a set of SRPMs for 0.1.0-RC2, I'm sure he'll let us know. But you can produce your own RPMs with is spec file. RPMS updated to 0.1.0-RC2. Stuff in the usual places: Spec: http://jamielinux.fedorapeople.org/assimilation/assimilation.spec SRPM: http://jamielinux.fedorapeople.org/assimilation/SRPMS/assimilation-cma.src.rpm Fedora 18 repository instructions: http://repos.fedorapeople.org/repos/jamielinux/assimilation/fedora-assimilation.repo RHEL/CentOS 6 repository instructions: http://repos.fedorapeople.org/repos/jamielinux/assimilation/epel-assimilation.repo I did notice a non-fatal error when building on both Fedora and RHEL, though I don't think it affects running on Linux: DEBUG: [ 83%] Generating ../../cma/AssimCtypes.py DEBUG: cd /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/build/clientlib python /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/buildtools/genpybindings.py /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/cma/AssimCtypes.py /builddir/build/BUILD/assimilation-20130325hg36236b3560f2 /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/build /builddir/build/BUILD /assimilation-20130325hg36236b3560f2/build/clientlib libassimilationclientlib DEBUG: INFO: Status: Preprocessing /tmp/tmpbwcAZl.h DEBUG: INFO: Status: gcc -E -DCTYPESGEN -D__signed__=signed -U __GNUC__ -dD -I/builddir/build/BUILD/assimilation-20130325hg36236b3560f2/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/builddir/build/BUILD/assimilation-20130325hg36236b3560f2/include -I/builddir/build/BUILD/assimilation-20130325hg36236b3560f2/build/include -Dinline= -D__inline__= -D__extension__= -D_Bool=uint8_t -D__const=const -D__asm__(x)= -D__asm(x)= -DCTYPESGEN=1 /tmp/tmpbwcAZl.h DEBUG: INFO: Status: Parsing /tmp/tmpbwcAZl.h DEBUG: ERROR: /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/include/proj_classes.h:42: Syntax error at '*' DEBUG: ERROR: /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/include/proj_classes.h:42: Syntax error at ')' DEBUG: INFO: Status: Processing description list. DEBUG: INFO: Status: Writing to /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/cma/AssimCtypes.py. DEBUG: INFO: Status: Wrapping complete. DEBUG: make[2]: Leaving directory `/builddir/build/BUILD/assimilation-20130325hg36236b3560f2/build' DEBUG: /usr/bin/cmake28 -E cmake_progress_report /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/build/CMakeFiles 48 49 50 -- Jamie Nguyen ___ Assimilation mailing list - Discovery-Driven Monitoring Assimilation@lists.community.tummy.com http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
Re: [Assimilation] 0.1.0 Release Candidate 2 is out!
On 26/03/13 21:49, Alan Robertson wrote: On 03/26/2013 02:58 PM, Jamie Nguyen wrote: I did notice a non-fatal error when building on both Fedora and RHEL, though I don't think it affects running on Linux: It might very well (and probably does) affect the CMA. DEBUG: [ 83%] Generating ../../cma/AssimCtypes.py DEBUG: cd /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/build/clientlib python /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/buildtools/genpybindings.py /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/cma/AssimCtypes.py /builddir/build/BUILD/assimilation-20130325hg36236b3560f2 /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/build /builddir/build/BUILD /assimilation-20130325hg36236b3560f2/build/clientlib libassimilationclientlib DEBUG: INFO: Status: Preprocessing /tmp/tmpbwcAZl.h DEBUG: INFO: Status: gcc -E -DCTYPESGEN -D__signed__=signed -U __GNUC__ -dD -I/builddir/build/BUILD/assimilation-20130325hg36236b3560f2/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/builddir/build/BUILD/assimilation-20130325hg36236b3560f2/include -I/builddir/build/BUILD/assimilation-20130325hg36236b3560f2/build/include -Dinline= -D__inline__= -D__extension__= -D_Bool=uint8_t -D__const=const -D__asm__(x)= -D__asm(x)= -DCTYPESGEN=1 /tmp/tmpbwcAZl.h DEBUG: INFO: Status: Parsing /tmp/tmpbwcAZl.h DEBUG: ERROR: /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/include/proj_classes.h:42: Syntax error at '*' DEBUG: ERROR: /builddir/build/BUILD/assimilation-20130325hg36236b3560f2/include/proj_classes.h:42: Syntax error at ')' snip I don't see this problem on my systems... I'm running both of these systems from the pip-extracted versions of ctypesgen.py. Don't know if it matters... Just to make sure, I removed the source I had, and re-extracted it and rebuilt it. Same results. Hmm ok so I did a build outside of mock and it doesn't have the error, so it seems to be something different happening inside mock. Haven't quite figured out why this is the case, but I guess something to do with ctypesgen. -- Jamie Nguyen ___ Assimilation mailing list - Discovery-Driven Monitoring Assimilation@lists.community.tummy.com http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
Re: [Assimilation] Generating AssimCclasses.py: WAS Re: Preliminary RPM packages for Fedora 18 and EPEL 6
On 14/03/13 21:12, Alan Robertson wrote: Currently, AssimCctypes.py is a source file -- but it's really a file generated by ctypesgen.py. I was trying to avoid everyone having to have a copy. But if you want to install somewhere other than /usr/lib/assimilation, then you need to run ctypesgen. Everything else supports that - so this should too. Also, if you want to be able to have it locate the copy in your workspace, you also need to run ctypesgen. And I definitely want to be able to do that if I can. So I have to make ctypesgen a required package - and generate two copies of AssimCtypes.py - one in my workspace, and one in the installed place. Sigh... And I have to run it automatically whenever I change any header file. Additional sigh... But that seems to be a method which will work, and will satisfy all those issues. I wrote a python script which will do these things. I'll finish it up, add the cmake rules, and commit it all this evening (or so I hope). I spotted buildtools/genpybindings.py and it looks like it'll solve the issues quite nicely. Just to make sure I'm using it right, can you give an example of the options you might pass to it? Kind regards, -- Jamie Nguyen ___ Assimilation mailing list - Discovery-Driven Monitoring Assimilation@lists.community.tummy.com http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
