Back
[00:45:28] <tom3p> emc
[00:45:50] <tom3p> sorry
[00:51:42] <skunkworks> never be sorry to say emc
[19:24:55] <NTU> hey quick question before I re-upload the rtai packages for arch linux, does EMC run if RTAI is configured for more cores on the running system, ie 8 cores on a 4 core CPU? its in Machine (x86) CONFIG_RTAI_CPUS
[19:25:42] <cpresser> NTU: I think yes. its more like a MAX_CPU thing.
[19:26:06] <psha> NTU: have you solved problem with segfaults?
[19:26:11] <NTU> yes
[19:26:17] <NTU> and thanks cpresser!
[19:26:24] <psha> I've tried to build debian packages today and it seem that everything is ok
[19:30:18] <NTU> ok in that case I'm going to throw my packages in the "community" repo and make it so that others can just install the binary packages to their hard drive without custom compiling and configuring.
[19:36:21] <NTU> this is for arch :) I don't have the access required to add into "universe" on debian or ubuntu.. i used to though..
[19:37:30] <psha> emc2 packages in main repo is a bit useless
[19:37:40] <psha> since it needs rtai kernel
[19:37:46] <NTU> no im pushing all that in
[19:38:03] <NTU> userspace and kernel rtai
[19:38:06] <psha> it's only my point of view ;)
[19:38:31] <psha> based on debian
[19:38:43] <psha> and i think it's impossible to push rtai kernel to debian
[19:39:08] <psha> but maybe i'll try to bake debian + rtai kernel
[19:39:10] <psha> not ubuntu + rtai
[19:40:47] <NTU> yeah debian might be easier anyway to build packages for since pretty much any change you make to ubuntu, usually breaks something.
[19:44:56] <psha> It's easier for me since I've written system for clean builds using pbuilder at work for local packages :)
[19:45:23] <psha> started from lot of shell scripts, ended with shell + python
[19:47:56] <NTU> heh i cant merge in my package into my wikispace page because im only allowed 10MB per file...
[19:48:33] <NTU> so i cant add this into the arch repo unless of coarse I talk to the lead guys and get them to push it into their server...
[19:50:19] <psha> btw what caused problem with segfault?
[19:50:59] <NTU> the stock -Os flag with a custom install directory
[19:51:31] <psha> optimize for size?!
[19:51:36] <NTU> yes
[19:51:41] <psha> strange :)
[19:51:45] <NTU> yes indeed
[19:52:04] <NTU> i never would have guessed that a CFLAG like that would cause such an issue...
[19:52:55] <psha> cpresser: I've sent halui-rewrite patches to ML so when there will be some reaction i'll try to push your patch with named MDI commands
[19:53:19] <psha> btw at least micges was not happy with multi-mdi functionality in halui :)
[19:53:52] <micges> I didn't said that :)
[19:54:53] <micges> I've had many issues with halui so I'll happly see they're all fixed
[20:00:25] <psha> so if anyone will ack on halui patches i'll send cpresser's one
[20:06:31] <cpresser> :)
[20:09:31] <psha> but if mdi o-call patches will be merged then multi-mdi in halui will be extremly simple
[20:09:47] <psha> just push all commands and don't bother what happens
[21:37:06] <psha> seb_kuzminsky: may I ask you some questions about emc2 debian packages
[21:38:32] <seb_kuzminsky> sure
[21:38:32] <psha> git logs say that you are maintaining debian/ subdir, am i right?
[21:38:50] <seb_kuzminsky> i hack on it from time to time, but so do a couple of other folks
[21:39:46] <psha> i was building debian packages today so i've looked in there
[21:40:05] <psha> first, if @PYTHON_VERSION@ needed in control.in/rules.in file?
[21:40:18] <psha> there are deps
[21:40:19] <psha> python (>= @PYTHON_VERSION@), python (<< @PYTHON_VERSION_NEXT@),
[21:40:19] <psha> ${python:Depends},
[21:40:19] <psha> python@PYTHON_VERSION@-tk,
[21:40:19] <psha> python@PYTHON_VERSION@-gnome2, python@PYTHON_VERSION@-glade2,
[21:40:47] <psha> as i understand debian python policy (and ubuntu too as it's derived from debian) @PYTHON_VERSION@ is not needed here
[21:42:06] <psha> first, ${python:Depends} provides line like first one
[21:43:16] <psha> also python-something depends on current python
[21:43:27] <psha> so it seem a bit excessive
[21:46:40] <psha> also maybe it's better to merge EXTRA_BUILD variable (texlive-*) into control.in to reduce needed number of substitutions?
[21:50:10] <seb_kuzminsky> the python packaging is a bit messed up at the moment...
[21:50:18] <seb_kuzminsky> patches welcome :-)
[21:50:43] <psha> have to push through review first two patchsets :)
[21:51:56] <cpresser> psha: we think a lot alike. i also stumbeled across the debian directory.
[21:52:07] <cpresser> the difference is, I am no programmer :)
[21:52:30] <psha> at first I have not found debian/configure script that creates everything )
[21:52:45] <seb_kuzminsky> yeah that's a bit usual
[21:53:00] <psha> but even then it helps only a bit
[21:53:18] <seb_kuzminsky> it's because we want to build both sim and realtime packages from the same source
[21:53:21] <psha> I'm configuring on one host (debian/testing) and then pushing build in ubuntu chroot
[21:53:38] <psha> on other host
[21:54:06] <psha> seb_kuzminsky: some things won't harm sim/not sim version
[21:54:10] <psha> for example libpth-dev
[21:54:26] <psha> or if it's found something threaded is built?
[21:55:47] <psha> so now i've added debian/configure in debian/rules to rebuild files in target environment
[21:57:58] <qq-> hm , seem COPYING has a 'hic' , say EMC1 is public domain , and his 'derivate' aka EMC2 isn't ...
[21:59:28] <psha> it's late here so leaving...
[21:59:59] <micges> qq-: that's correct, emc2 is gpl2
[22:12:17] <SWPadnos> libpth is only needed for sim, not for RT
[22:12:31] <SWPadnos> since sim uses pthreads to simulated multiple HAL threads etc.
[22:25:19] <CIA-5> EMC: 03seb 07v2.4_branch * r6b38788bf449 10/docs/man/man9/ (hm2_pci.9 hostmot2.9): better 3x20 info in hostmot2 and hm2_pci manpages