Back
[00:00:02] <KGB-linuxcnc> 03git 05rtos-integration-preview3 2f7ee73 06linuxcnc 03src/hal/drivers/bcm2835.h * hal_gpio.c: add bissing bcm2835.h
[00:00:08] <KGB-linuxcnc> 03charles 05rtos-integration-preview3 ab889e2 06linuxcnc 10src/rtapi/rtapi_pci.c * fix to writefile() to open file in write only mode
[00:00:15] <KGB-linuxcnc> 03git 05rtos-integration-preview3 de4f830 06linuxcnc 10src/ 10Makefile 10hal/utils/Submakefile * pci_read, pci_write: build and install when BUILD_DRIVERS == yes
[00:00:23] <KGB-linuxcnc> 03john 05rtos-integration-preview3 76e962b 06linuxcnc 10src/configure.in * add CFLAG for unset CONFIG_CC_STACKPROTECTOR in Xenomai
[00:00:28] <mhaberler> uminded: this makes a thread function visible by name so you can addf it in halcmd
[00:00:28] <KGB-linuxcnc> 03john 05rtos-integration-preview3 da08cbd 06linuxcnc 10src/Makefile.inc.in * Makefile.inc.in: emacs mode setting
[00:00:35] <KGB-linuxcnc> 03git 05rtos-integration-preview3 f31f8a4 06linuxcnc 10scripts/rtapi.conf.in 10src/Makefile.inc.in 10src/Makefile.modinc.in 10src/configure.in * configure: rename ARCH to ARCHITECTURE
[00:00:43] <KGB-linuxcnc> 03charles 05rtos-integration-preview3 3c4559b 06linuxcnc 10src/rtapi/rtapi_pci.c * Begin modifying rtapi_pci to use sysfs-pci style mmap of resources
[00:00:50] <KGB-linuxcnc> 03git 05rtos-integration-preview3 e4a0ac1 06linuxcnc 10src/ 10(6 files in 2 dirs) * RTAPI cleanup: no more include files with executable code
[00:00:56] <KGB-linuxcnc> 03git 05rtos-integration-preview3 65e361e 06linuxcnc 10src/ 10(6 files in 2 dirs) * RTAPI: do the same to the rt-preempt code
[00:01:03] <KGB-linuxcnc> 03git 05rtos-integration-preview3 7fa32bb 06linuxcnc 10src/ 10rtapi/Submakefile 10rtapi/linux_common.c 03rtapi/rtapi_msg.c 10rtapi/sim_common.c * rtapi: factor out msg code into a single copy for userthreads styles
[00:01:11] <KGB-linuxcnc> 03john 05rtos-integration-preview3 c46feaa 06linuxcnc 10.gitignore 10src/.gitignore * .gitignore: modules.order; additional emacs droppings
[00:01:18] <KGB-linuxcnc> 03john 05rtos-integration-preview3 a80ba07 06linuxcnc 10scripts/linuxcnc.in * scripts/linuxcnc.in: add a -V option to add -V to halcmd
[00:01:25] <KGB-linuxcnc> 03john 05rtos-integration-preview3 5b6fed1 06linuxcnc 10src/ 10(24 files in 2 dirs) * Cleanups stage 1: linux_* gone; new rt-preempt-user.*, generic rtapi-* files
[00:01:32] <KGB-linuxcnc> 03john 05rtos-integration-preview3 aad2285 06linuxcnc 10src/rtapi/rt-preempt-user.c * rt-preempt-user.c: drop unneeded functions
[00:01:38] <KGB-linuxcnc> 03john 05rtos-integration-preview3 b43cacf 06linuxcnc 10src/Makefile * Makefile: remove 'print_copy_configs' target
[00:01:45] <KGB-linuxcnc> 03john 05rtos-integration-preview3 dbaa6cc 06linuxcnc 10src/rtapi/rtapi.h * rtapi/rtapi.h: clarify some macro conditionals
[00:01:51] <KGB-linuxcnc> 03john 05rtos-integration-preview3 c642500 06linuxcnc 10src/Makefile * Makefile: add rtapi/$(THREADS).h to header install
[00:01:58] <KGB-linuxcnc> 03john 05rtos-integration-preview3 b055c34 06linuxcnc 10src/ 10(14 files) * fold ULAPI in (currently broken); more shuffling
[00:02:05] <KGB-linuxcnc> 03john 05rtos-integration-preview3 ed0a4d1 06linuxcnc 10src/rtapi/rtapi_time.c * rtapi_time.c: fix mismatch btw. function definition and prototype
[00:02:11] <KGB-linuxcnc> 03john 05rtos-integration-preview3 1a757a3 06linuxcnc 10src/rtapi/rtapi_task.c * rtapi_task.c: fix mismatch between function definition and prototype
[00:02:18] <KGB-linuxcnc> 03john 05rtos-integration-preview3 0ddaa0b 06linuxcnc 10src/rtapi/rt-preempt-user.c * rt-preempt-user.c: fix warning from disabled pthread mutexes
[00:02:26] <KGB-linuxcnc> 03john 05rtos-integration-preview3 3ec0a8c 06linuxcnc 10src/ 10Makefile 10rtapi/Submakefile * Makefile muddling; still broken
[00:02:32] <KGB-linuxcnc> 03john 05rtos-integration-preview3 d10c7f7 06linuxcnc 10src/rtapi/Submakefile * rtapi/Submakefile: revert broken changes; these may work, but still probs
[00:02:39] <KGB-linuxcnc> 03john 05rtos-integration-preview3 b5f08b1 06linuxcnc 10src/rtapi/Submakefile * rtapi/Submakefile: fix generation of rtapi-objs
[00:02:46] <KGB-linuxcnc> 03john 05rtos-integration-preview3 63f07e4 06linuxcnc 10src/rtapi/rt-preempt-user.c * rt-preempt-user.c: Remove empty rtapi_init/exit
[00:02:52] <KGB-linuxcnc> 03john 05rtos-integration-preview3 07e6d5d 06linuxcnc 10src/hal/hal_priv.h * hal/hal_priv.h: set stacksize to 32768 for all thread systems
[00:02:59] <KGB-linuxcnc> 03john 05rtos-integration-preview3 e8aad2d 06linuxcnc 10src/ 10hal/Submakefile 10rtapi/Submakefile * Fix rtapi Submakefile for rtapi_app; change XENO_LINK to ULAPI_LINK
[00:03:07] <KGB-linuxcnc> 03john 05rtos-integration-preview3 f5b9f14 06linuxcnc 10src/ 10(7 files in 2 dirs) * Fix hal_init duplicate component problem; remove pthread mutexes
[00:03:09] <uminded> mhaberler: I used it to export my GPIO output funtion. So i can use that first arg to do whatever with? Say siggen.0.sin?
[00:03:14] <KGB-linuxcnc> 03john 05rtos-integration-preview3 bd1bb2d 06linuxcnc 10src/ 10hal/hal_lib.c 10rtapi/rt-preempt-user.c * Fix rtapi_init hack in HAL from previous commit
[00:03:21] <KGB-linuxcnc> 03john 05rtos-integration-preview3 8e5993c 06linuxcnc 10src/rtapi/README * rtapi/README: update file descriptions
[00:03:27] <KGB-linuxcnc> 03john 05rtos-integration-preview3 640b86f 06linuxcnc 10src/ 04rtapi/linux_common.h 04rtapi/linux_ulapi.c * Remove accidentally-re-committed linux_common.h and linux_ulapi.c
[00:03:35] <KGB-linuxcnc> 03git 05rtos-integration-preview3 53ec303 06linuxcnc 10src/rtapi/sim_rtapi.c * rtapi: delete fluff which misleads 'make depend'
[00:03:42] <KGB-linuxcnc> 03mah 05rtos-integration-preview3 5cc8c7d 06linuxcnc 10src/hal/classicladder/Submakefile * precise: put libraries after objects
[00:03:44] <uminded> mhaberler: as its a void *arg, I have no idea what kind of data it will recieve
[00:03:48] <KGB-linuxcnc> 03john 05rtos-integration-preview3 c11a66b 06linuxcnc 10src/ 10(16 files in 2 dirs) * Merge xenomai-user thread system
[00:03:54] <KGB-linuxcnc> 03git 05rtos-integration-preview3 e78672d 06linuxcnc 10src/ 10Makefile 10configure.in * configure: add Beaglebone: --with-platform=beaglebone
[00:03:57] <mhaberler> please pastebin code, I cant tell
[00:04:01] <KGB-linuxcnc> 03mah 05rtos-integration-preview3 ca6faf8 06linuxcnc 10src/configure.in * configure: fix missing 'test', improve messages
[00:04:08] <KGB-linuxcnc> 03git 05rtos-integration-preview3 e259ab2 06linuxcnc 10src/hal/drivers/ 03beaglebone_gpio.h 03hal_bbio.c * beaglebone: start work on gpio/pwm/adc/led module
[00:04:15] <KGB-linuxcnc> 03john 05rtos-integration-preview3 329cb16 06linuxcnc 10src/ 10rtapi/rtapi_time.c 10rtapi/xenomai-user.c * xenomai-user and rtapi_time: fix clocks
[00:04:19] <linuxcnc-build> build #32 of precise-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/32 blamelist: Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <mah@bb1.(none)>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[00:04:22] <KGB-linuxcnc> 03john 05rtos-integration-preview3 41c6f10 06linuxcnc 10src/ 10rtapi/rt-preempt-user.h 10rtapi/rtapi_io.c 10rtapi/xenomai-user.c 10rtapi/xenomai-user.h * rtapi_io.c: change default {in,out}[bw]() funcs; hook funcs inlined
[00:04:31] <KGB-linuxcnc> 03john 05rtos-integration-preview3 b1be188 06linuxcnc 10src/ 10rtapi/rt-preempt-user.c 10rtapi/rtapi_common.h 10rtapi/sim_rtapi.c * Replace MAX_MODULES macro with RTAPI_MAX_MODULES
[00:04:38] <KGB-linuxcnc> 03john 05rtos-integration-preview3 9993a5e 06linuxcnc 10src/rtapi/rt-preempt-user.c * rt-preempt-user.c: move variable init to top of function block
[00:04:45] <KGB-linuxcnc> 03john 05rtos-integration-preview3 0ea7d18 06linuxcnc 10src/ 10rtapi/rt-preempt-user.h 10rtapi/rtapi_common.h 10rtapi/xenomai-user.h * Fix THREAD_TASK_DATA macro semicolons
[00:04:52] <KGB-linuxcnc> 03john 05rtos-integration-preview3 42c2508 06linuxcnc 10src/rtapi/rtapi_app.h * rtapi_app.h: don't include linux/module.h
[00:04:56] <uminded> mhaberler:
http://pastebin.com/xik1dnDK
[00:04:59] <KGB-linuxcnc> 03john 05rtos-integration-preview3 7201b5c 06linuxcnc 10src/rtapi/rtapi_bitops.h * rtapi_bitops.h: clarify #ifdef condition
[00:05:06] <KGB-linuxcnc> 03john 05rtos-integration-preview3 56ca7bc 06linuxcnc 10src/ 10rtapi/rtapi_task.c 10rtapi/xenomai-user.c 10rtapi/xenomai-user.h * rtapi_task_wrapper: silence gcc pointer cast warnings on 64 bit
[00:05:13] <KGB-linuxcnc> 03john 05rtos-integration-preview3 96028a9 06linuxcnc 10src/rtapi/rtai.h * rtai.h: remove unneeded #ifdef blocks (and formatting)
[00:05:20] <KGB-linuxcnc> 03john 05rtos-integration-preview3 38d741d 06linuxcnc 10src/ 10rtapi/rtapi_common.h 10rtapi/rtapi_task.c * MIN_STACKSIZE macro added, and raised to 32k
[00:05:27] <KGB-linuxcnc> 03john 05rtos-integration-preview3 a509e3b 06linuxcnc 10src/rtapi/rtapi_shmem.c * rtapi_shmem.c: replace MAX_SHM with RTAPI_MAX_SHMEMS
[00:05:34] <KGB-linuxcnc> 03john 05rtos-integration-preview3 32cfab5 06linuxcnc 10src/rtapi/rtapi_shmem.c * rtapi_shmem.c: revert to mutex locking from rtapi.h
[00:05:40] <KGB-linuxcnc> 03john 05rtos-integration-preview3 047e406 06linuxcnc 10src/rtapi/rtapi_task.c * rtapi_task.c: merge MAX_TASKS into RTAPI_MAX_TASKS
[00:05:47] <KGB-linuxcnc> 03john 05rtos-integration-preview3 4567d16 06linuxcnc 10src/rtapi/rtapi_shmem.c * rtapi_shmem.c: fix bungled patch application
[00:05:54] <KGB-linuxcnc> 03john 05rtos-integration-preview3 1da4768 06linuxcnc 10src/rtapi/rtapi_task.c * rtapi_task.c: finish merging MAX_TASKS into RTAPI_MAX_TASKS
[00:06:00] <KGB-linuxcnc> 03john 05rtos-integration-preview3 3cb1cf0 06linuxcnc 10src/rtapi/rt-preempt-user.c * rt-preempt-user.c: revert mistaken change to msg_level type
[00:06:07] <KGB-linuxcnc> 03john 05rtos-integration-preview3 6a0aa87 06linuxcnc 10src/ 10hal/Submakefile 10rtapi/Submakefile * Refactor rtapi/Submakefile. Again.
[00:06:15] <KGB-linuxcnc> 03john 05rtos-integration-preview3 e83c433 06linuxcnc 10src/rtapi/Submakefile * rtapi/Submakefile: fix RT_LDFLAGS for xenomai-kernel
[00:06:21] <KGB-linuxcnc> 03john 05rtos-integration-preview3 589bd36 06linuxcnc 10src/ 10(7 files in 2 dirs) * hack xenomai-kernel support back in for working baseline
[00:06:28] <KGB-linuxcnc> 03john 05rtos-integration-preview3 5677d48 06linuxcnc 10src/rtapi/xenomai-kernel.h * xenomai-kernel.h: updated for cleanups
[00:06:34] <KGB-linuxcnc> 03john 05rtos-integration-preview3 e8a962f 06linuxcnc 10src/ 10(5 files in 2 dirs) * rtapi_io.c: merged xenomai-kernel
[00:06:41] <KGB-linuxcnc> 03john 05rtos-integration-preview3 84bfdf8 06linuxcnc 10src/ 10(10 files in 2 dirs) * rtapi_msg.c: merged xenomai-kernel; other minor changes
[00:06:48] <KGB-linuxcnc> 03john 05rtos-integration-preview3 3456077 06linuxcnc 10src/ 10(7 files in 2 dirs) * rtapi_time.c: merged xenomai-kernel
[00:06:54] <KGB-linuxcnc> 03john 05rtos-integration-preview3 dbbebf1 06linuxcnc 10src/ 10(11 files in 2 dirs) * rtapi_task.c: merge xenomai-kernel
[00:07:01] <KGB-linuxcnc> 03john 05rtos-integration-preview3 47668e9 06linuxcnc 10src/ 10(10 files in 2 dirs) * rtapi_module.c: new file; merge xenomai-kernel
[00:07:08] <KGB-linuxcnc> 03john 05rtos-integration-preview3 898fab5 06linuxcnc 10src/ 10(10 files in 2 dirs) * rtapi_shmem.c: merge xenomai-kernel; main cleanups done
[00:07:14] <KGB-linuxcnc> 03john 05rtos-integration-preview3 0814989 06linuxcnc 10src/ 10(7 files in 2 dirs) * Fix build problems for userspace kernel systems
[00:07:21] <KGB-linuxcnc> 03john 05rtos-integration-preview3 13219cc 06linuxcnc 10src/rtapi/Submakefile * rtapi/Submakefile: get rid of testing mess and final uglies
[00:07:28] <KGB-linuxcnc> 03john 05rtos-integration-preview3 d076652 06linuxcnc 10src/Makefile * Makefile: cleanups
[00:07:34] <KGB-linuxcnc> 03john 05rtos-integration-preview3 4476b59 06linuxcnc 10src/rtapi/Submakefile * rtapi/Submakefile: add -lrt to posix LDFLAGS
[00:07:41] <KGB-linuxcnc> 03john 05rtos-integration-preview3 c3425cb 06linuxcnc 10src/ 10Makefile 10rtapi/Submakefile * Makefile, rtapi/Submakefile: merge rt-preempt and posix builds
[00:07:48] <KGB-linuxcnc> 03john 05rtos-integration-preview3 5e0431f 06linuxcnc 10src/ 10rtapi/rt-preempt-user.c 10rtapi/rtapi_module.c * rt-preepmpt-user.c, rtapi_module.c: formatting changes
[00:07:55] <KGB-linuxcnc> 03john 05rtos-integration-preview3 fc1011c 06linuxcnc 10src/ 10rtapi/rt-preempt-user.h 10rtapi/rtapi_common.h * rt-preempt-user.h, rtapi_common.h: Remove semicolon from THREAD_MODULE_DATA
[00:08:03] <KGB-linuxcnc> 03john 05rtos-integration-preview3 468f021 06linuxcnc 10src/ 10rtapi/rt-preempt-user.c 10rtapi/rt-preempt-user.h * rt-preempt-user.[ch]: merge tdata struct fields into task_data
[00:08:11] <KGB-linuxcnc> 03john 05rtos-integration-preview3 b1c4449 06linuxcnc 10src/rtapi/rt-preempt-user.c * rt-preempt-user.c: get rtapi_{init,exit} closer to merge
[00:08:18] <KGB-linuxcnc> 03john 05rtos-integration-preview3 8aedc28 06linuxcnc 10src/ 10(5 files in 2 dirs) * Merge posix threads with RT_PREEMPT threads
[00:08:24] <KGB-linuxcnc> 03john 05rtos-integration-preview3 d5835c7 06linuxcnc 10src/ 10rtapi/rt-preempt-user.c 10rtapi/sim_rtapi_app.cc * rt-preempt-user.c,sim_rtapi_app.cc: ignore errs in simulator mode
[00:08:38] <mhaberler> unminded - I dont understand your question ' So i can use that first arg to do whatever with? Say siggen.0.sin?' -see
http://www.linuxcnc.org/docs/devel/html/man/man3/hal_export_funct.3hal.html
[00:09:28] <mhaberler> what do you want to do except addf it to a thread in hal? or are you talking naming conventions?
[00:11:20] <uminded> I am quite new to linuxcnc. I want to give hal the ability to toggle a gpio based off the stepgen.
[00:12:00] <mhaberler> that is, a hal driver
[00:12:22] <andypugh> KimK: I have found that things go wrong if the filename and component name don't match.
[00:12:56] <andypugh> uminded: Isn't that exactly what a stepgen already does?
[00:13:20] <mhaberler> no, stepgen is not a driver
[00:14:05] <uminded> mhaberler: hal_pin_bit_newf() sets my naming convention so I can attach pins, is the hal_write_port() I have only to update the values?
[00:14:14] <linuxcnc-build> build #833 of hardy-amd64-sim is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/833 blamelist: Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <mah@bb1.(none)>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[00:14:18] <mhaberler> yes
[00:14:44] <mhaberler> naming only happens at setup time
[00:15:00] <mhaberler> have a look at hal_parport or hal_gpio for examples
[00:15:26] <linuxcnc-build> build #831 of hardy-i386-sim is complete: Failure [4failed configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/831 blamelist: Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <mah@bb1.(none)>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[00:15:33] <KimK> andypugh: Thanks, Andy, I'll take your advice.
[00:15:35] <mhaberler> yes hal_write_port is the thread function
[00:15:40] <linuxcnc-build> build #830 of hardy-amd64-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-realtime-rip/builds/830 blamelist: Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <mah@bb1.(none)>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[00:15:42] <uminded> mhaberler: Ahh, so I can export all my pins then just parse the structure as needed when write is called. This seems a bit slow... I guess i could export a funtion to update just a single pin, but could I pass that pin name as an arg?
[00:15:50] <mhaberler> it is only there to pass hal pins to the driver and vice versa
[00:16:22] <mhaberler> take timings before you think it is too slow, the time you spend there is meaningless IMO
[00:17:04] <mhaberler> what structure do you want to parse? you fetch the pin value, pass it to the hardware, or the other way around
[00:17:08] <linuxcnc-build> build #831 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/831 blamelist: Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <mah@bb1.(none)>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[00:17:55] <andypugh> uminded: I am almost sure that what you are trying to do is already trivial. Can you describe exactly what it is?
[00:18:16] -!- adb has quit [Ping timeout: 260 seconds]
[00:19:01] <uminded> mhaberler: I have to do some actual testing as i wrote this away from hardware. I am writing a driver for my boards gpio. I want to be able to set each pin as input or output and toggle as fast as possible
[00:19:52] <mhaberler> sure, but you dont make it fast by lots of thread functions - you do all pins in one go
[00:19:57] <uminded> I have atomic bit access but if I parse a structure I could just output whole words to the gpio at a time and that would make things quick enough
[00:20:25] <uminded> Is each addf going to spawn a new thread?
[00:20:36] <mhaberler> no
[00:21:22] <andypugh> uminded: Ah, ignore what I said if you are writing a hardwre driver.
[00:21:24] <mhaberler> it executes functions in turn on the thread you specify - I think you might want the manual before optimzing hal drivers
[00:22:07] <uminded> I probably should get a full working system then worry about optimizing as well. I just didn't want to reinvent the wheel
[00:22:07] <mhaberler> your best bet is to take an existing driver like hal_parport and adapt that
[00:22:15] <mhaberler> absolutely
[00:22:20] <uminded> I used hal_gpio as my base
[00:23:04] <mhaberler> that was a quick hack to get something going, but it looses time in the loops - again: read hal_parport.c and go from there
[00:23:27] <uminded> I was going to write my driver to setup sysfs gpio's and export pin states through that but decided to do raw memory writes for initial testing
[00:23:33] <andypugh> uminded: Have a look at plc720.comp That's a hardware driver written in comp, much simpler to understand. It's a GPIO driver for an ISA card.
[00:23:41] <mhaberler> that wont work
[00:23:43] <uminded> I will check out hal_paraport this weekend
[00:23:50] <mhaberler> forget sysfs
[00:24:01] <mhaberler> and forget any existing kernel drivers
[00:24:09] <uminded> lol alright, too much overhead to use?
[00:24:17] <mhaberler> you cannot use kernel services from a realtime thread
[00:24:19] <andypugh> (pcl720.comp, I mean)
[00:24:50] <andypugh> I think all the hardware drivers use inb and outb
[00:25:15] <mhaberler> or memory mapped io on non-intel
[00:25:33] <andypugh> Which sounds even easier.
[00:26:05] <uminded> I am using mmap on mine, might as well stick with that I guess. Not like the addresses are going to change on my embeded device eh
[00:26:46] <andypugh> uminded: I am pretty sure you can write your driver in comp, and let that do all the hard work.
[00:27:50] <uminded> got a web link to plc720.comp? Im currently riding in a truck and dont have any sources.
[00:28:30] <andypugh> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/hal/drivers/pcl720.comp;h=35fbca94620a330d288be4527ef82ea8c65f4e2e;hb=refs/heads/v2.5_branch
[00:28:44] <uminded> thanks
[00:31:40] <uminded> comp is wierd
[00:36:16] <andypugh> It's a bunch of pin declarations, then a bit of C
[00:38:44] <KGB-linuxcnc> 03git 05rtos-integration-preview3 c48bb57 06linuxcnc 10src/rtapi/rtai-kernel.h * rtapi/rtai: include linux/delay.h
[00:40:21] <andypugh> The triple-quoted multi-line strings look a bit odd at first.
[00:40:55] <uminded> I will bang around a bit and see what pops out this weekend
[00:45:06] <uminded> I see calls to ioaddr, am I safe to use my standard /dev/mem and mmap method in comp?
[00:46:16] <KGB-linuxcnc> 03git 05rtos-integration-preview3 4507d9d 06linuxcnc 10debian/ 10configure 10control.in * debian: make libudev-dev a prerequisite
[00:47:41] <linuxcnc-build> build #831 of lucid-i386-realtime-rip is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/831 blamelist: Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <mah@bb1.(none)>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[00:47:42] <linuxcnc-build> build #829 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/829 blamelist: Charles Steinkuehler <charles@steinkuehler.net>, Michael Haberler <mah@bb1.(none)>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>
[00:48:33] <andypugh> uminded: I can't see why not. Note that in that comp ioaddr is nothing more than a modparam passed on the ladrt line.
[00:48:58] <andypugh> ie, loadrt pcl720 ioaddr=0x234
[00:50:17] <uminded> Thanks for all the help, I'm off for now. If I get a decent driver working I will be sure to submit it
[00:51:19] <KGB-linuxcnc> 03git 05rtos-integration-preview3 9c49219 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_pci.c * hm2_pci.c: include rtapi_pci.h if USERMODE_PCI
[00:51:37] -!- uminded has quit [Quit: Leaving]
[00:56:31] <andypugh> Gah! I hate it when I crash rtai, make changes, reboot, try again and crash rtai because I forgot to recompile after making the changes...
[01:00:22] <linuxcnc-build> build #834 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/834 blamelist: Michael Haberler <git@mah.priv.at>
[01:00:41] <linuxcnc-build> build #831 of hardy-amd64-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-realtime-rip/builds/831 blamelist: Michael Haberler <git@mah.priv.at>
[01:00:51] -!- mhaberler has quit [Ping timeout: 276 seconds]
[01:00:59] <linuxcnc-build> build #832 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/832 blamelist: Michael Haberler <git@mah.priv.at>
[01:01:33] <linuxcnc-build> build #832 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/832 blamelist: Michael Haberler <git@mah.priv.at>
[01:03:14] -!- mhaberler [mhaberler!~mhaberler@extern-187.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[01:04:27] -!- zzolo has quit [Quit: zzolo]
[01:06:28] -!- rob_h has quit [Ping timeout: 240 seconds]
[01:06:36] -!- zzolo has quit [Client Quit]
[01:15:38] <KGB-linuxcnc> 03git 05rtos-integration-preview3 b01d7e0 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_pci.c * hm2_pci.c: include rtapi.h for int types
[01:18:40] -!- zzolo has quit [Client Quit]
[01:21:47] <KGB-linuxcnc> 03git 05rtos-integration-preview3 2fc5998 06linuxcnc 10src/ 10Makefile 10hal/drivers/mesa-hostmot2/hm2_test.c * hm2_test: reenable & portify to usermode PCI
[01:26:39] -!- rob_h [rob_h!~rob_h@027c16a0.bb.sky.com] has joined #linuxcnc-devel
[01:27:05] <linuxcnc-build> build #33 of precise-i386-realtime-rip is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/33 blamelist: Michael Haberler <git@mah.priv.at>
[01:30:37] -!- jfire has quit [Quit: Leaving.]
[01:35:00] <linuxcnc-build> build #832 of lucid-i386-realtime-rip is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/832 blamelist: Michael Haberler <git@mah.priv.at>
[01:35:01] <linuxcnc-build> build #830 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/830 blamelist: Michael Haberler <git@mah.priv.at>
[01:46:25] -!- jfire has quit [Quit: Leaving.]
[01:48:00] <linuxcnc-build> build #835 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/835 blamelist: Michael Haberler <git@mah.priv.at>
[01:48:11] <linuxcnc-build> build #832 of hardy-amd64-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-realtime-rip/builds/832 blamelist: Michael Haberler <git@mah.priv.at>
[01:48:43] <linuxcnc-build> build #833 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/833 blamelist: Michael Haberler <git@mah.priv.at>
[01:48:46] -!- rob_h has quit [Ping timeout: 245 seconds]
[01:49:05] <linuxcnc-build> build #833 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/833 blamelist: Michael Haberler <git@mah.priv.at>
[01:53:44] <seb_kuzminsky> hmm, hardy doesnt have libudev-dev
[01:55:33] <seb_kuzminsky> that's going to be a problem when we merge rtos into master
[01:56:49] -!- andypugh has quit [Quit: andypugh]
[02:03:55] <jepler> have we otherwise kept compatible with hardy in master branch?
[02:04:23] -!- odogono has quit [Quit: odogono]
[02:08:22] <mhaberler> jepler: there's one remaining problem with the debian directory and the rtos builds, and I dont understand the cause
[02:08:56] -!- Wildhoney has quit [Ping timeout: 276 seconds]
[02:09:36] <mhaberler> this
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=commit;h=7dd08993edfc3acfaf4dba5404d176cbf2f67480 and
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=commit;h=4507d9d59299556f5c81cb91dd4ae55d66944189 were the changes I made
[02:10:25] <mhaberler> during build I get a list of
[02:10:27] <mhaberler> Files exist in debian/tmp, but should not:
[02:10:27] <mhaberler> debian/tmp/usr/share/man/man3/rtapi_get_msg_level.3rtapi
[02:10:28] <mhaberler> debian/tmp/usr/share/man/man3/hal_param_u32_new.3hal
[02:10:29] <mhaberler> debian/tmp/usr/share/man/man3/hal_link.3hal
[02:10:54] <mhaberler> etc plus module .so's and includes
[02:11:01] <mhaberler> any idea why?
[02:18:26] <mhaberler> seb: what are the kernel versions for the rt-preempt and xenomai build vm's? are those shown in the buildbot output anywhere yet?
[02:20:42] -!- FinboySlick has quit [Quit: Leaving.]
[02:20:52] -!- FinboySlick1 has quit [Client Quit]
[02:21:54] <linuxcnc-build> build #831 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/831 blamelist: Michael Haberler <git@mah.priv.at>
[02:22:16] <skunkworks> to make an omelet - you have to break a few eggs... ;)
[02:32:15] <seb_kuzminsky> jepler: yes, master builds on hardy through precise
[02:32:18] <jepler> mhaberler: it seems like linuxcnc-dev.files must not be getting the right contents.
[02:32:38] <mhaberler> ah, ok, will look there
[02:32:54] <jepler> all those files are expected to be moved into debian/linuxcnc-dev/usr/share/man3/.... by dh_movefiles which looks at linuxcnc-dev.files
[02:32:58] <seb_kuzminsky> mhaberler: that "files exist in debian/tmp" means that new files are getting installed from src/Makefile, but not getting sorted into the correct debs
[02:33:05] <seb_kuzminsky> oh i see that jepler just said that..
[02:33:57] <seb_kuzminsky> mhaberler: i haven't stood up the xenomai & preempt buildslaves yet, but when i do i'll use the kernels zultron et al provide
[02:34:33] <mhaberler> I thought these were done? at least John implied he understood you so?
[02:34:54] <seb_kuzminsky> i talked with john last night and we agreed on a plan, but i have not done the buildbot work yet
[02:35:04] <mhaberler> aha
[02:35:26] <mhaberler> zultron dont provide a rt-preempt kernel but there are ones out in debian
[02:35:57] <jepler> mhaberler: it looks like since your package name is linuxcnc-xenomai-dev you need to generate the file debian/linuxcnc-xenomai-dev.files from debian/configure
[02:35:59] <seb_kuzminsky> do you have the new rtos kernel available somewhere?
[02:36:17] <mhaberler> ah!. lost in naming hell ;) thanks!
[02:36:25] <mhaberler> yes, as per wiki
[02:36:28] <mhaberler> let me see
[02:36:58] <mhaberler> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernelPackages
[02:36:59] <seb_kuzminsky> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernelPackages
[02:37:01] <seb_kuzminsky> heh
[02:37:03] <jepler> you should be able to test this without a buildbot .. debian/configure; dpkg-buildpackage -B
[02:38:07] <mhaberler> yes, I tried locally before; but the bb also finds stuff which I dont on my lucid-only thing here
[02:38:56] <jepler> OK, just so you know
[02:39:28] <seb_kuzminsky> if amster doesn't build on hardy, that'll be annoying
[02:40:04] <mhaberler> is there any substantial difference to 'fakeroot debian/rules binary' which I understand the bb uses?
[02:40:23] <seb_kuzminsky> we'll have to maintainthe buildbot builds debs in pbuilder
[02:40:40] <jepler> dpkg-buildpackage -B will also check build deps, I don't think fakeroot debian/rules binary will
[02:41:05] <seb_kuzminsky> pbuilder is a minimal chroot install of the os, useful for checking for missing build dependencies
[02:41:15] <jepler> '
[02:41:17] <jepler> night guys
[02:41:18] <jepler> good luck
[02:41:20] <mhaberler> well first things first, there is more than one way to patch up the libudev thing for hardy, but I would really like to get the less historic builds through first
[02:41:23] <seb_kuzminsky> seeya jeff
[02:41:28] <mhaberler> cu!
[02:41:44] <seb_kuzminsky> sure, one thing at a time
[02:42:28] <mhaberler> the libudev thing is harmless, but I need to talk to Charles to see which parts he used
[02:43:31] <mhaberler> what is the agreed timeframe for hardy support life?
[02:43:49] <mhaberler> or are we in 'would be nice' space?
[02:44:07] <seb_kuzminsky> "as long as someone's willing to maintain it"
[02:45:32] <mhaberler> well somebody running master on hardy is a rather exotic combo today, given the complete breakage glade gives on hardy, so I dont see much point to start with (you cant edit UI files on hardy such that they run on hardy anymore)
[02:46:01] <mhaberler> read as: gscreen: no, gladevcp: no
[02:46:49] <mhaberler> you can of course keep a lucid or precise box around, edit UI files and then copy them over to hardy
[02:48:35] <mhaberler> strictly libudev isnt needed for rtai builds, but it needs more config massage and building drivers for sim isnt possible either (this is possible in manual config but not as per default build right now)
[02:53:50] <seb_kuzminsky> there's two issues there: one is what src/configure wants, and the other is what debian/control wants
[02:54:10] <seb_kuzminsky> both record dependencies, sort of
[02:55:01] <mhaberler> what I am saying is - the udev thing can be fixed so sim and rtai builds work on hardy
[02:55:15] <seb_kuzminsky> that would be convenient
[02:55:32] <seb_kuzminsky> supporting different branches on different platforms is possible, of course, it's just a pain in the ass
[02:55:33] <mhaberler> I'll look into it
[02:55:55] <seb_kuzminsky> thanks
[02:56:03] <mhaberler> but we cant assume any platform any branch, that falls off the cliff on hardy
[02:56:26] <seb_kuzminsky> i bet almost no one does new installs of hardy these days, but i bet there are some folks who upgrade old hardy machines to newer linuxcnc versions
[02:56:46] <mhaberler> well those can be assumed to be locked-in to rtai
[02:57:55] <seb_kuzminsky> there's three dimensions to our build matrix, i guess: distribution on one axis (hardy/lucid/precise), rtos on another axis (sim/rtai/xenomai/preempt), and branch on the final axis (2.5, master, various derivatives)
[02:58:23] <mhaberler> the rtos axis will go away
[02:58:38] <seb_kuzminsky> the current situation is that all branches build on all distros in sim, and all branches build on rtai on a certain set of distros
[02:58:41] <mhaberler> 3 months from now I'd guess
[02:59:11] <seb_kuzminsky> the rtos axis will not go away, exactly, we'll still want dedicated machines of the RTOSes we support, for runtests
[02:59:40] <seb_kuzminsky> but maybe you meant that all rtoses will build with the same configure command?
[02:59:52] <mhaberler> well from a running os perspective yes, but not from a package stream view
[03:00:03] -!- RangerRick has quit [Remote host closed the connection]
[03:00:07] <seb_kuzminsky> i don't know anything about that
[03:00:14] -!- Keknom has quit [Quit: Leaving.]
[03:00:26] <mhaberler> no, what John is working on is a _single_ package which will run on any OS and do sim too
[03:00:26] <seb_kuzminsky> and i dont want to talk about it now: one thing at a time, yes? ;-)
[03:00:40] <mhaberler> well you started the axis thing ;)
[03:01:20] <mhaberler> anyway I will look around for a decent stock rt-preempt kernel for your vm, I think Charles is up to speed on this
[03:02:03] <seb_kuzminsky> ok cool, i'm going to go try some rtai debugging things paolo wanted, and try to add a precise-x86-xenomai buildslave
[03:02:03] <mhaberler> the xenomai kernel from the wiki page repo should be painless, I use it all the time on vbox
[03:02:16] <mhaberler> great
[03:08:44] <mhaberler> ok, I'm off - cu
[03:08:49] <seb_kuzminsky> seeya
[03:08:52] -!- mhaberler has quit [Quit: mhaberler]
[03:42:18] -!- erictheise has quit [Quit: erictheise]
[03:48:58] -!- zzolo has quit [Quit: zzolo]
[03:57:20] -!- Valen has quit [Quit: Leaving.]
[03:57:55] -!- sumpfralle has quit [Remote host closed the connection]
[04:19:35] -!- Tecan has quit [Quit: Ex-Chat]
[04:19:46] -!- jfire has quit [Quit: Leaving.]
[04:37:07] -!- AR_ has quit [Ping timeout: 264 seconds]
[04:40:34] -!- ve7it has quit [Remote host closed the connection]
[04:41:14] -!- FinboySlick has quit [Quit: Leaving.]
[04:53:23] -!- pjm has quit [Read error: Connection reset by peer]
[05:14:50] -!- kwallace [kwallace!~kwallace@smb-152.sonnet.com] has parted #linuxcnc-devel
[05:24:00] -!- jfire has quit [Quit: Leaving.]
[05:38:31] -!- joe9 has quit [Read error: Connection reset by peer]
[05:40:04] -!- krusty_ar has quit [Remote host closed the connection]
[05:43:15] -!- joe9_ [joe9_!~user@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[05:46:11] -!- joe9_ has quit [Remote host closed the connection]
[06:02:35] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:05:01] -!- JT-Shop has quit [Ping timeout: 245 seconds]
[06:05:20] -!- jthornton has quit [Ping timeout: 246 seconds]
[06:05:49] -!- JT-Shop [JT-Shop!~John@162.72.171.228] has joined #linuxcnc-devel
[06:06:25] -!- jthornton [jthornton!~john@162.72.171.228] has joined #linuxcnc-devel
[06:09:34] -!- jthornton has quit [Read error: Connection reset by peer]
[06:13:24] -!- JT-Shop has quit [Ping timeout: 264 seconds]
[06:16:11] -!- JT-Shop [JT-Shop!~John@162.72.171.228] has joined #linuxcnc-devel
[06:16:16] -!- jthornton [jthornton!~john@162.72.171.228] has joined #linuxcnc-devel
[06:22:32] -!- JT-Shop has quit [Read error: Connection reset by peer]
[06:22:32] -!- jthornton has quit [Read error: Connection reset by peer]
[06:26:04] -!- redfr0g has quit [Ping timeout: 252 seconds]
[06:29:36] -!- nevyn has quit [Quit: leaving]
[06:30:34] -!- DaViruz has quit [Read error: Connection reset by peer]
[06:34:49] <seb_kuzminsky> ran linuxcnc under rtai on linux 3.5.7 tonight!
[06:35:02] <seb_kuzminsky> my mill ran away and crashed!
[06:35:06] <seb_kuzminsky> it was very exciting
[06:37:45] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[06:38:37] -!- jthornton [jthornton!~john@162.72.171.228] has joined #linuxcnc-devel
[06:38:37] -!- JT-Shop [JT-Shop!~John@162.72.171.228] has joined #linuxcnc-devel
[06:45:47] -!- JT-Shop has quit [Ping timeout: 255 seconds]
[06:46:39] -!- jthornton has quit [Ping timeout: 276 seconds]
[06:49:29] -!- JT-Shop [JT-Shop!~John@162.72.171.228] has joined #linuxcnc-devel
[06:50:08] -!- jthornton [jthornton!~john@162.72.171.228] has joined #linuxcnc-devel
[06:51:59] -!- krusty_ar has quit [Remote host closed the connection]
[06:57:08] -!- dhoovie has quit [Ping timeout: 246 seconds]
[07:03:22] -!- dhoovie|2 has quit [Read error: Connection reset by peer]
[07:11:50] -!- dhoovie has quit [Ping timeout: 246 seconds]
[07:13:35] -!- dhoovie|2 has quit [Ping timeout: 246 seconds]
[07:28:29] -!- mhaberler [mhaberler!~mhaberler@extern-187.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[07:37:29] -!- erictheise has quit [Quit: erictheise]
[07:44:30] -!- Valen has quit [Quit: Leaving.]
[07:48:41] -!- tomate_ [tomate_!~quassel@2a01:e34:ee61:a5f0:e5f0:d49f:8325:a7ff] has joined #linuxcnc-devel
[07:49:22] -!- racycle has quit [Quit: racycle]
[08:09:43] -!- Loetmichel has quit []
[08:12:37] <mhaberler> seb: for sim builds on bb: do you execute 'debian/configure sim', or do you run a vanilla kernel and expect 'debian/configure -r' to do the right thing, or both?
[08:19:32] -!- asdfasd has quit [Read error: Connection reset by peer]
[08:28:13] -!- RangerRick has quit [Quit: No Ping reply in 180 seconds.]
[08:34:38] -!- b_b has quit [Changing host]
[08:35:11] zq is now known as bzzzz
[08:35:27] bzzzz is now known as zq
[08:44:02] -!- charlie_ has quit [Quit: Leaving]
[08:49:41] -!- emel has quit [Excess Flood]
[09:01:33] -!- rob_h [rob_h!~rob_h@027c16a0.bb.sky.com] has joined #linuxcnc-devel
[09:02:20] -!- tomate_ has quit [Remote host closed the connection]
[09:13:14] -!- b_b has quit [Changing host]
[09:15:13] -!- 20WAB4G4M [20WAB4G4M!~quassel@2a01:e34:ee61:a5f0:9c0c:129a:1515:29ee] has joined #linuxcnc-devel
[09:17:19] -!- ink_ has quit [Ping timeout: 264 seconds]
[09:18:00] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[09:23:20] -!- toastydeath has quit [Read error: Connection reset by peer]
[09:29:01] -!- Wildhoney has quit [Read error: Connection reset by peer]
[09:40:09] -!- Wildhoney has quit [Ping timeout: 256 seconds]
[09:51:10] -!- Wildhoney has quit [Read error: Connection reset by peer]
[09:52:08] -!- emel has quit [Excess Flood]
[09:52:08] -!- dhoovie has quit [Read error: Connection reset by peer]
[09:55:51] -!- Wildhoney has quit [Read error: Connection reset by peer]
[09:58:09] -!- Wildhoney has quit [Read error: Connection reset by peer]
[09:58:21] -!- eykreinecke1 has quit [Read error: Connection reset by peer]
[10:12:20] -!- snkashis has quit [Quit: Leaving.]
[10:13:33] -!- Wildhoney has quit [Read error: Connection reset by peer]
[10:16:06] -!- Wildhoney has quit [Read error: Connection reset by peer]
[10:17:00] -!- micges [micges!~micges@eit199.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[10:17:52] -!- 45PAAAONL has quit [Quit: Leaving.]
[10:36:37] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[10:36:50] -!- skunkworks has quit [Remote host closed the connection]
[10:49:02] -!- mourner has quit [Quit: mourner]
[11:08:26] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:25:14] -!- dhoovie has quit [Ping timeout: 246 seconds]
[11:26:59] -!- dhoovie|2 has quit [Ping timeout: 246 seconds]
[11:31:41] <KGB-linuxcnc> 03git 05rtos-integration-preview3 aae4e0e 06linuxcnc 10src/configure.in * src/configure: dont require libudev if not building drivers and posix
[11:31:41] <KGB-linuxcnc> 03git 05rtos-integration-preview3 cdcf27c 06linuxcnc 10debian/ 10configure 10control.in 10rules.in
[11:31:41] <KGB-linuxcnc> debian: carry over kernel autodetection from src/configure, remove libudev-dev dep
[11:41:47] -!- V0idExp has quit [Read error: Connection reset by peer]
[11:42:00] -!- V0idExp1 has quit [Client Quit]
[11:44:51] -!- dhoovie|3 has quit [Read error: Connection reset by peer]
[11:46:17] <linuxcnc-build> build #836 of hardy-amd64-sim is complete: Failure [4failed configure-debian-control compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/836 blamelist: Michael Haberler <git@mah.priv.at>
[11:46:24] <linuxcnc-build> build #833 of hardy-amd64-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-realtime-rip/builds/833 blamelist: Michael Haberler <git@mah.priv.at>
[11:47:22] -!- cncbasher_ [cncbasher_!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has parted #linuxcnc-devel
[11:47:51] <linuxcnc-build> build #834 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/834 blamelist: Michael Haberler <git@mah.priv.at>
[11:57:35] <linuxcnc-build> build #633 of precise-amd64-sim-clang is complete: Failure [4failed configure-debian-control] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/633 blamelist: Michael Haberler <git@mah.priv.at>
[12:13:22] <linuxcnc-build> build #833 of lucid-i386-sim is complete: Failure [4failed configure-debian-control] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/833 blamelist: Michael Haberler <git@mah.priv.at>
[12:15:07] <linuxcnc-build> build #837 of precise-amd64-sim is complete: Failure [4failed configure-debian-control] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/837 blamelist: Michael Haberler <git@mah.priv.at>
[12:15:58] <linuxcnc-build> build #835 of precise-i386-sim is complete: Failure [4failed configure-debian-control] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/835 blamelist: Michael Haberler <git@mah.priv.at>
[12:18:47] <linuxcnc-build> build #833 of lucid-amd64-sim is complete: Failure [4failed configure-debian-control] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/833 blamelist: Michael Haberler <git@mah.priv.at>
[12:19:34] -!- R2E4 has quit [Read error: Connection reset by peer]
[12:23:58] <linuxcnc-build> build #834 of hardy-i386-sim is complete: Failure [4failed configure-debian-control] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/834 blamelist: Michael Haberler <git@mah.priv.at>
[12:23:59] <linuxcnc-build> build #832 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/832 blamelist: Michael Haberler <git@mah.priv.at>
[12:29:23] -!- mackerski has quit [Quit: mackerski]
[12:46:05] <KGB-linuxcnc> 03git 05rtos-integration-preview3 1a2bddc 06linuxcnc 10debian/configure * fix sim build
[12:49:14] -!- adb has quit [Ping timeout: 252 seconds]
[13:00:32] <linuxcnc-build> build #834 of hardy-amd64-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-realtime-rip/builds/834 blamelist: Michael Haberler <git@mah.priv.at>
[13:01:04] <linuxcnc-build> build #837 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/837 blamelist: Michael Haberler <git@mah.priv.at>
[13:02:36] <linuxcnc-build> build #835 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/835 blamelist: Michael Haberler <git@mah.priv.at>
[13:12:02] <cradek> kaboom
[13:12:37] -!- zzolo has quit [Ping timeout: 258 seconds]
[13:14:49] <mhaberler> oh really
[13:17:24] <cradek> mhaberler: at least a partial answer to your question:
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/829/steps/configure-debian-control/logs/stdio
[13:20:37] -!- mk0 has quit [Quit: Leaving]
[13:21:51] -!- phantoneD has quit [Ping timeout: 276 seconds]
[13:24:47] -!- pjm_ has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
[13:25:22] -!- dway has quit [Quit: NOOOOOOooooooooo……]
[13:29:37] <seb_kuzminsky> the bbot currently gives different args to src/configure and to debian/configure depending on it it's building on sim/posix or rtai
[13:30:34] <seb_kuzminsky> it might be good tp make both autodetect (while still letting the user override the autodetector)
[13:36:54] -!- micges has quit [Read error: Connection reset by peer]
[13:38:27] <linuxcnc-build> build #833 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/833 blamelist: Michael Haberler <git@mah.priv.at>
[13:47:10] <mhaberler> hm, it seems pci_ioremap_bar() isnt available with the hardy kernel
[13:48:45] -!- vladimirek has quit [Quit: Leaving]
[13:50:43] -!- fomox has quit [Ping timeout: 260 seconds]
[14:01:26] -!- odogono has quit [Read error: Connection reset by peer]
[14:01:51] -!- phantoxeD has quit [Read error: Connection reset by peer]
[14:02:07] -!- cncbasher_ [cncbasher_!~cncbasher@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[14:02:40] <mhaberler> that OTHER_MAIN_PACKAGE_NAME stuff in debian/configure stops making sense if you have 4, not 2 package variants
[14:04:22] <mhaberler> I mean debian/control.in
[14:05:27] -!- odogono has quit [Read error: Connection reset by peer]
[14:06:45] -!- Tom_itx has quit [Ping timeout: 260 seconds]
[14:07:56] <seb_kuzminsky> yeah, there'll be some trickiness for sure to expand our debian framework to handle 4 packages instead of 2
[14:08:13] -!- asdfasd has quit [Ping timeout: 256 seconds]
[14:10:02] -!- psha[work] has quit [Quit: Lost terminal]
[14:13:43] -!- ravenlock has quit [Ping timeout: 264 seconds]
[14:21:11] -!- Brandonian has quit [Quit: Brandonian]
[14:23:39] -!- mhaberler_ [mhaberler_!~mhaberler@extern-187.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[14:23:55] -!- mhaberler has quit [Read error: No route to host]
[14:23:55] mhaberler_ is now known as mhaberler
[14:29:04] <mhaberler> ok, the hardy build has 3 issues which will be fixed; the libudev-dev dep is gone for rtai though so thats not an issue any more
[14:30:16] <KGB-linuxcnc> 03git 05rtos-integration-preview3 d85a23e 06linuxcnc 10debian/configure * one more try
[14:30:17] <KGB-linuxcnc> 03git 05rtos-integration-preview3 9ad1795 06linuxcnc 10debian/ 10configure 10control.in * debian: switch to lists for conflicting packages
[14:30:36] -!- kwallace [kwallace!~kwallace@tmb-238.sonnet.com] has joined #linuxcnc-devel
[14:31:15] -!- RangerRick has quit [Ping timeout: 260 seconds]
[14:37:31] -!- Brandonian has quit [Quit: Brandonian]
[14:38:18] -!- JT-Shop has quit [Read error: No route to host]
[14:40:42] -!- JT-Shop [JT-Shop!~John@162.72.171.228] has joined #linuxcnc-devel
[14:42:29] -!- mourner has quit [Quit: mourner]
[14:42:55] -!- krusty_ar has quit [Remote host closed the connection]
[14:44:25] -!- wboykinm has quit [Remote host closed the connection]
[14:44:30] <linuxcnc-build> build #838 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/838 blamelist: Michael Haberler <git@mah.priv.at>
[14:44:37] <linuxcnc-build> build #835 of hardy-amd64-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-realtime-rip/builds/835 blamelist: Michael Haberler <git@mah.priv.at>
[14:46:42] <linuxcnc-build> build #836 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/836 blamelist: Michael Haberler <git@mah.priv.at>
[14:50:43] -!- mhaberler has quit [Quit: mhaberler]
[14:53:37] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[15:06:19] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[15:16:01] <mhaberler> hm, there seems to be no precise-amd64-realtime
[15:19:27] -!- mackerski has quit [Ping timeout: 240 seconds]
[15:19:27] mackerski_ is now known as mackerski
[15:21:29] -!- 18WAC22GU has quit [Ping timeout: 246 seconds]
[15:22:58] <seb_kuzminsky> that is the case
[15:23:04] <linuxcnc-build> build #834 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/834 blamelist: Michael Haberler <git@mah.priv.at>
[15:23:11] <seb_kuzminsky> rtai is 32-bit only still
[15:28:41] -!- sumpfralle has quit [Ping timeout: 256 seconds]
[15:28:47] -!- sumpfralle1 has quit [Read error: Connection reset by peer]
[15:30:28] -!- Santolina has quit [Ping timeout: 245 seconds]
[15:33:27] -!- mourner has quit [Quit: mourner]
[15:35:46] <mhaberler> aha
[15:35:49] -!- ler_hydra has quit [Remote host closed the connection]
[15:37:11] <mhaberler> well that doesnt look so bad except for the hardy buglings; curious how the package build goes
[15:39:58] -!- nfell2009 has quit [Client Quit]
[15:42:12] -!- stsydow has quit [Remote host closed the connection]
[15:42:15] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[15:42:17] -!- Wildhoney has quit []
[15:44:55] -!- mackerski has quit [Quit: mackerski]
[15:44:55] <seb_kuzminsky> this looks familiar:
https://github.com/ShabbyX/URT
[15:45:09] <seb_kuzminsky> by Shabby, who's a contributor to RTAI
[15:45:37] <seb_kuzminsky> i just mailed him with pointers to our rtapi code, which serves a similar function
[15:55:14] -!- ravenlock has quit [Remote host closed the connection]
[16:00:11] -!- tmcw has quit [Remote host closed the connection]
[16:00:25] <mhaberler> hm, interesting, cc me on conversation
[16:00:56] <mhaberler> there's an obvious 'market' for that kind of thing, people dont want tie-ins with this or that school of rt thinking
[16:02:08] <mhaberler> the old rtapi code didnt really abstract much away over RTAI, there were lots of subtle dependencies on RTAI semantics; in particular wrt shm segment lifecycle
[16:21:24] <cradek> we've only ever had two rt systems, and I suppose they were both pretty rtai-like
[16:21:52] -!- mackerski has quit [Quit: mackerski]
[16:22:04] -!- joe9 [joe9!~user@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[16:26:00] <seb_kuzminsky> cradek: i got a strange behavior last night
[16:26:17] <seb_kuzminsky> i fixed the timer-on-UP bug in rtai and ran linuxcnc on it
[16:26:30] <seb_kuzminsky> at first when i started it, hm2 got a watchdog timeout right away
[16:26:42] <seb_kuzminsky> i cleared the timeout via the hm2 hal pin, and it timed out right away again
[16:26:57] <seb_kuzminsky> i restarted linuxcnc and the machine ran away and crashed the Z axis
[16:26:59] <seb_kuzminsky> :-/
[16:27:10] <seb_kuzminsky> it seems like pci access to the fpga is messed up somehow
[16:27:26] <skunkworks> yeck
[16:27:30] <seb_kuzminsky> it correctly sent the firmware to the card, and correctly read all the module descriptors and pin descriptors and stuff back from it
[16:27:32] <cradek> good grief
[16:27:42] <cradek> perhaps not real hardware next time
[16:27:50] <seb_kuzminsky> that would be smart
[16:27:55] -!- sumpfralle2 has quit [Read error: Operation timed out]
[16:28:00] <cradek> lemme loan you some little stepper motors... :-/
[16:28:16] <cradek> did it ruin anything?
[16:28:22] <seb_kuzminsky> i should dig out the little steppers i used to use for hm2 testing
[16:28:31] <seb_kuzminsky> nothing seems damaged
[16:28:46] <cradek> did it jam?
[16:28:49] <skunkworks> no limit switches?
[16:28:57] <seb_kuzminsky> the quill jammed itself up agains the z timing pulley
[16:29:07] <seb_kuzminsky> this has happened once before (operator error that time)
[16:29:11] <cradek> seems like that limit switch needs to be moved down
[16:29:27] <seb_kuzminsky> skunkworks: it tripped the +Z limit switch, but i guess it had enough momentum to crash anyway
[16:29:35] <skunkworks> ah
[16:29:47] <seb_kuzminsky> by removing some of the cast iron from the head you can see the pulley on the quill
[16:30:07] <cradek> does that limit switch estop, or just disable the amps?
[16:30:07] <seb_kuzminsky> i have a handy little bar of aluminum from last time, with which i can hammer the timing pulley and cause it to spin free
[16:30:17] <cradek> handy :-)
[16:30:23] <seb_kuzminsky> the limit switch estops the machine
[16:30:33] <seb_kuzminsky> which cuts power to all servos
[16:30:40] <seb_kuzminsky> but does not apply any brakes or anything
[16:30:43] <cradek> I thought that had braking contactors that kick in on actual estop
[16:30:52] <seb_kuzminsky> hmm
[16:30:56] <seb_kuzminsky> i may be wrong
[16:31:00] <cradek> are you sure it's triggering the real estop?
[16:31:24] <skunkworks> Bang! then silence. (when the k&t goes into estop)
[16:31:27] <cradek> they may have depended on that to stop it, and if you've defeated it, it could explain why the switches are too far out
[16:34:22] <mhaberler> I'm not blaming rtai, I just noted it had necessarily occur when you extend it - thats where the implicit assumptions come belly up
[16:42:48] <seb_kuzminsky> when i push the limit switch by hand, the contactors that supply power to the amps open, and the estop input to linuxcnc goes high
[16:42:57] <seb_kuzminsky> i'm not sure what else happens electrically in the machine
[16:43:15] <cradek> seb_kuzminsky: oh ok, maybe those contactors are not what I think
[16:43:38] <cradek> seb_kuzminsky: I thought they disconnected and shorted out the motors, perhaps through a resistor. they might be incoming power, though.
[16:43:44] <seb_kuzminsky> i should look at the electrical diagrams again, but i dont think we changed any of that
[16:44:18] <seb_kuzminsky> on a different topic...
[16:44:54] <seb_kuzminsky> i want to change the behavior of "debian/configure" and "src/configure" so that if you don't give any arguments (or give some new argument) they autodetect between sim and rtai
[16:45:10] <seb_kuzminsky> this will help integrate the new rtos branch
[16:45:32] <seb_kuzminsky> currently if you don't give src/configure any arguments, it finds the current running rtai kernel, and aborts if it can't find it
[16:47:01] <seb_kuzminsky> currently you give src/configure the "--enable-simulator" argument to make it build sim
[16:47:52] <seb_kuzminsky> we can keep --enable-simulator to force a sim build, but i'd like some way to automatically autodetect among all the (currently 2, soon 4 or more) different build configurations
[16:48:03] -!- joe9 has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
[16:49:46] <seb_kuzminsky> i'd also like it if all our branches built in the same way, so there's only one recipe - would you accept a change like the above in 2.5?
[16:50:05] <seb_kuzminsky> it's be "nearly backwards compatible", only a little different if no configure argument is given
[16:52:03] <seb_kuzminsky> alternatively i guess we could leave the current two command-lines alone, and add a --enable-autodetect or something
[16:52:15] -!- joe9 [joe9!~user@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[16:54:25] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[16:55:58] <cradek> we're not adding new realtime options to v2.5_branch, so I don't understand why you have to change it, or why you need it to be the same as other branches, when it's already working
[16:56:38] <cradek> oh I guess builder to branch correlation is not 1:1
[16:56:40] <cradek> ?
[16:56:57] <cradek> you want a particular builder to be able to handle all branches the same way
[16:58:27] -!- Turkishviking has quit [Client Quit]
[16:59:21] <seb_kuzminsky> i totally agree we're not adding any realtime options to 2.5
[17:00:08] <seb_kuzminsky> we have a builder for each supported platform (platform = arch + distro + kernel)
[17:00:34] <seb_kuzminsky> the overall goal is to make it so all builders do something reasonable on all branches
[17:00:52] <seb_kuzminsky> maybe you're right, that we don't need to change anything in 2.5 to make that happen
[17:01:32] <cradek> I didn't say that exactly - but I am trying to understand the goal, which may or may not make it necessary to change v2.5_branch
[17:01:43] <seb_kuzminsky> yeah, good
[17:02:15] <seb_kuzminsky> if we add a xenomai builder, and show it today's 2.5 or master, there's two options
[17:02:36] <seb_kuzminsky> option 1 is "./configure --enable-simulator", which would build sim (i think)
[17:03:06] <seb_kuzminsky> option 2 is "./configure" with no args, which would cause it to try to autodetect the rtai version, and error out
[17:03:40] <cradek> what is the reason for giving a xenomai builder the v2.5_branch, which can only result in a failed (rtish) or redundant (sim) build?
[17:04:23] <seb_kuzminsky> because otherwise we need to maintain a mapping of branches-to-builders, and each temporary feature branch needs to be included in that mapping :-/
[17:04:38] <cradek> ugh
[17:05:04] <cradek> in that case, since waiting for useless builds is useless, don't you just want a quick failure anyway?
[17:05:18] <seb_kuzminsky> if we could have ./configure tell us what would happen, then the buildbot could check the result right after configuring, and abort (with success, probably) that builder
[17:05:31] <seb_kuzminsky> something like this:
[17:05:33] <cradek> i.e. 'building v2.5_branch on xenomai failed again, just like we expect'
[17:05:45] <seb_kuzminsky> i'd rather not have expected failures
[17:05:55] <seb_kuzminsky> "./configure --enable-autodetect"
[17:06:37] <seb_kuzminsky> "grep $RTOS_DETECTED config.log", compare to a per-builder expected value
[17:06:41] <cradek> it'd be really simple and safe to make debian/configure --whatever-new-argument fail on v2.5_branch
[17:07:30] <seb_kuzminsky> short-circuit the build if (for example) the xenomai builder got "sim" for its RTOS_DETECTED, because it ran on an older branch that doesnt know about xenomai
[17:07:59] <cradek> yeah, debian/configure could "exit 77" or something that means to short-circuit
[17:08:05] <seb_kuzminsky> yeah, i'm less worried about the debian side of things
[17:08:20] <seb_kuzminsky> i'm focusing on rip first, then we'll deal with the debian stuff
[17:08:35] <cradek> oh right, you don't always run debian/configure first
[17:08:41] <seb_kuzminsky> the bbot first builds rip & runs the tests, and only if that passes does it try to build debs
[17:08:49] <cradek> ok
[17:09:13] <cradek> then I guess you do have to mess with src/configure(.in)
[17:09:53] <seb_kuzminsky> or we could add a new script that autodetects the rtos, and short-circuit the old build if that new script doesnt say the right thing for the current builder
[17:10:01] <seb_kuzminsky> but that seems more messy, not less
[17:10:06] * seb_kuzminsky shrugs
[17:10:11] * cradek shrugs too
[17:11:06] <cradek> I suppose you can do a simple thing (add an --argument that makes it return a controlled failure) to src/configure without breaking it
[17:11:19] <seb_kuzminsky> hm, i wonder if there's even a way to say, in the buildbot language, "stop running this build, it worked already!"
[17:11:29] <cradek> hm
[17:12:08] <cradek> I'm sure I don't know that
[17:12:42] -!- phantoxeD has quit [Read error: Connection reset by peer]
[17:12:43] * seb_kuzminsky looks
[17:13:02] <cradek> wait I have 11 more steps to try! /buildbot
[17:15:00] <seb_kuzminsky> yes i think it can do this
[17:15:08] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[17:15:11] <seb_kuzminsky> http://buildbot.net/buildbot/docs/0.8.6/manual/cfg-buildsteps.html
[17:15:25] <seb_kuzminsky> haltOnFailure=True && flunkOnFailure=False should do it
[17:15:55] <cradek> ./configure --error-now-if-you-dont-support-xenomai
[17:16:21] <cradek> er no
[17:16:50] <seb_kuzminsky> no matter what, i think we need the buildbot to know what rtos each builder has
[17:17:12] <seb_kuzminsky> and all branches need to be able to tell us what they would build, if run on "this machine"
[17:17:18] <mhaberler> seb: the rtos autodetect is already in place in debian/configure and src/configure, see here:
[17:17:23] <cradek> configure does immediately fail on any unrecognized option
[17:17:41] <seb_kuzminsky> mhaberler: yes i know
[17:17:51] <seb_kuzminsky> we're talking about how to integrate that with 2.5
[17:18:33] <mhaberler> ah ok, sorry I'm busy elswehere
[17:18:34] <seb_kuzminsky> it's ok :-)
[17:19:19] <seb_kuzminsky> cradek: we could have "--enable-xenomai", "--enable-rtai" and have them fail if the enabled thing is not available
[17:19:47] <seb_kuzminsky> but failure of the configure step is suboptimal, imo
[17:20:14] <cradek> what would be more optimal?
[17:20:22] <seb_kuzminsky> because sometimes configure failures are for other reasons (missing build dependencies), and you want to know about that and fail the build with an error, instead of skip and pretend it worked
[17:20:32] <cradek> oh, sure
[17:21:11] <seb_kuzminsky> that's why i'm thinking of this "teach all branches to autodetect, then teach the buildbot to compare the detected RTOS to the builders expected RTOS"
[17:22:12] <cradek> an aside: is autodetecting actually possible?
[17:22:16] <seb_kuzminsky> if we add a new --enable-autodetect, we can leave the current behaviors ("--enable-simulator" and "") alone, and not affect current work flows
[17:22:32] <seb_kuzminsky> i think so, with some heuristics
[17:22:47] <seb_kuzminsky> 2.5 with no configure arguments currently looks for /usr/realtime-$(uname)
[17:22:49] <cradek> on my rt machine I can usefully build as either rt or sim
[17:23:06] <seb_kuzminsky> yeah, same here, and that's something we should not break
[17:23:07] <cradek> and maybe there are even more choices now...?
[17:23:07] <mhaberler> can I suggest you try to build the rtos branch and see how configure works - it is much better and covers much of what you want
[17:23:24] <mhaberler> you will save yourselves a lot of work
[17:23:51] <seb_kuzminsky> mhaberler: you look in /boot/config-$(uname) for some rtos-specific strings, is that right?
[17:24:00] <mhaberler> yes
[17:24:14] <mhaberler> because kernel headers are the wrong criterium
[17:24:21] <mhaberler> not needed for xeno and rt-preempt
[17:24:33] <seb_kuzminsky> and you provide configure arguments to override the detected config for one the user specifies?
[17:24:38] <mhaberler> determine from config, then check if khdeaders present if needed
[17:24:43] <mhaberler> yes
[17:25:05] <seb_kuzminsky> that sounds right to me
[17:25:20] <mhaberler> I build for preempt by just pointing at a preempt kconfig in /boot, the kernel isnt installed or needed to _build_
[17:25:36] <cradek> looking in /boot/config-$(uname -r) is clever
[17:25:52] <mhaberler> patching around in the 2.5 configure is a really bad idea
[17:25:59] <mhaberler> http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=debian/configure;h=f6689a80e53121d60346ff905dc8d6f3ec51ed79;hb=2651df3000e004eac355aad76fc574429bc1c5ed#l45
[17:26:14] <mhaberler> this is the detect code in debian/configure
[17:26:22] <mhaberler> function inspect_kernel
[17:26:59] <mhaberler> optionall it falls back to /proc/config.gz for the arm builds which do not have /boot/config-xxx
[17:27:01] -!- mourner has quit [Quit: mourner]
[17:27:48] <cradek> bbl
[17:28:17] -!- fomox_ has quit [Ping timeout: 258 seconds]
[17:28:28] <seb_kuzminsky> seeya chris, thanks for the suggestions etc :-)
[17:29:49] <seb_kuzminsky> mhaberler: that looks nice and clean
[17:30:22] <mhaberler> it took me to subscribe and talk to 3 kernel mailing lists to make that bulletproof
[17:30:24] <seb_kuzminsky> (as a nitpick, i would flatten out the nested if/else/if with if/elif/elif)
[17:30:26] -!- mackerski has quit [Quit: mackerski]
[17:31:07] <seb_kuzminsky> bbl
[17:31:17] <mhaberler> cu
[17:31:54] -!- redfr0g has quit [Ping timeout: 264 seconds]
[17:32:06] -!- Vq has quit [Ping timeout: 245 seconds]
[17:34:01] -!- dway has quit [Quit: NOOOOOOooooooooo……]
[17:40:55] -!- 20WAB4G4M has quit [Remote host closed the connection]
[17:43:49] -!- andypugh has quit [Quit: Page closed]
[17:44:01] -!- tmcw has quit [Remote host closed the connection]
[17:50:01] -!- adb has quit [Read error: Operation timed out]
[17:51:36] -!- V0idExp has quit [Quit: Leaving.]
[17:55:10] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[17:55:29] <KGB-linuxcnc> 03charles 05rtos-integration-preview3 2651df3 06linuxcnc 10src/rtapi/rtapi_pci.h
[17:55:29] <KGB-linuxcnc> Add pci_ioremap_bar replacement for really old kernels
[17:55:29] <KGB-linuxcnc> Fix goof with #ifdef placement while I'm here
[17:55:35] <KGB-linuxcnc> 03git 05rtos-integration-preview3 7b6bd4b 06linuxcnc 10src/rtapi/rtapi_pci.h * rtapi_pci.h: fix dev to pdev
[18:01:27] <mhaberler> maybe somebody could look at outgoing mail from forum - there are very long delays (got a complaint for no signup reply mail)
[18:02:50] <cradek> do you have one with full headers that shows where it was delayed?
[18:05:59] <mhaberler> hm, let me see
[18:08:30] -!- zzolo has quit [Ping timeout: 264 seconds]
[18:08:48] <pcw_home> The forum seems to go through spells of slowness every other week or so (emails sometimes a day or so late and out of order)
[18:09:20] <linuxcnc-build> build #839 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/839 blamelist: Michael Haberler <git@mah.priv.at>, Charles Steinkuehler <charles@steinkuehler.net>
[18:09:45] <linuxcnc-build> build #836 of hardy-amd64-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-realtime-rip/builds/836 blamelist: Michael Haberler <git@mah.priv.at>, Charles Steinkuehler <charles@steinkuehler.net>
[18:10:08] <cradek> the answer is probably that they're stuck in a dreamhost abyss, but if so, it'd be nice to know what particular abyss
[18:10:25] <cradek> we unfortunately don't have much control, but we could possibly complain if we have good data
[18:10:43] <cradek> (we could complain without, but nothing would likely come of it)
[18:11:15] <pcw_home> I'll save one that I know to be late when it happens again
[18:11:18] <cradek> thanks
[18:11:40] <mhaberler> sorry, cant find it right now, it was a post yesterday which I got this morning I think, and a local guy complained to me about the signup response; he's gotten it since though
[18:14:48] <pcw_home> found one with a 2 hour delay...
[18:16:10] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[18:17:55] -!- OpenSourceWay_ has quit [Ping timeout: 264 seconds]
[18:22:05] -!- erictheise has quit [Quit: erictheise]
[18:38:53] -!- OpenSourceWay__ has quit [Ping timeout: 246 seconds]
[18:48:50] <linuxcnc-build> build #835 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/835 blamelist: Michael Haberler <git@mah.priv.at>, Charles Steinkuehler <charles@steinkuehler.net>
[18:53:47] ttuner is now known as toxx
[18:54:41] -!- mhaberler has quit [Read error: Operation timed out]
[18:55:28] -!- r00t4rd3d has quit [Ping timeout: 272 seconds]
[19:21:35] -!- mackerski has quit [Ping timeout: 256 seconds]
[19:21:35] mackerski_ is now known as mackerski
[19:25:11] -!- mackerski has quit [Read error: Connection reset by peer]
[19:27:05] -!- mackerski has quit [Remote host closed the connection]
[19:28:45] -!- mackerski_ has quit [Client Quit]
[19:32:21] -!- mackerski has quit [Ping timeout: 256 seconds]
[19:35:24] -!- cncbasher_ has quit [Quit: Leaving]
[19:36:48] -!- theorbtwo has quit [Ping timeout: 245 seconds]
[19:37:00] theorb is now known as theorbtwo
[19:39:59] -!- mhaberler [mhaberler!~mhaberler@extern-180.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[19:43:35] -!- cncinator has quit [Ping timeout: 258 seconds]
[19:49:24] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 18.0/20130108033621]]
[19:52:24] -!- syyl has quit [Ping timeout: 264 seconds]
[20:05:19] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:14:40] -!- gasbakid has quit [Max SendQ exceeded]
[20:40:46] -!- cevad has quit [Ping timeout: 252 seconds]
[20:40:47] -!- micges [micges!~micges@eit199.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[20:47:28] -!- mourner has quit [Quit: mourner]
[20:49:23] -!- tronwizard has quit []
[20:55:19] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:55:26] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[20:55:29] -!- Horwitz has quit [Ping timeout: 248 seconds]
[21:09:18] -!- tandoori has quit [Read error: Connection reset by peer]
[21:09:28] -!- vladimirek has quit [Remote host closed the connection]
[21:09:39] -!- tandoori has quit [Changing host]
[21:15:19] -!- Jymmm has quit [Remote host closed the connection]
[21:17:04] -!- FinboySlick has quit [Quit: Leaving.]
[21:18:14] -!- rob_h has quit [Read error: Connection reset by peer]
[21:18:30] -!- rob_h [rob_h!~rob_h@027c16a0.bb.sky.com] has joined #linuxcnc-devel
[21:30:18] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[21:30:27] shdhdfghd is now known as asdfasd
[21:41:17] -!- V0idExp has quit [Quit: Leaving.]
[21:43:49] -!- AphelionZ has quit [Quit: Page closed]
[21:59:43] -!- zzolo has quit [Quit: zzolo]
[22:09:12] -!- Loetmichel has quit [Ping timeout: 264 seconds]
[22:19:55] -!- DJ9DJ has quit [Quit: bye]
[22:23:54] -!- chillly has quit [Quit: Leaving]
[22:48:13] r00t4rd3d_ is now known as r00t4rd3d
[22:48:28] -!- r00t4rd3d has quit [Changing host]
[22:55:42] -!- micges has quit [Quit: Leaving]
[22:59:23] -!- OpenSourceWay_ has quit [Quit: Se casse d'ici, ça craint.]
[23:01:34] -!- bpuk [bpuk!~ben@boopotter.plus.com] has joined #linuxcnc-devel
[23:04:26] -!- tmcw has quit [Remote host closed the connection]
[23:07:19] -!- mourner has quit [Quit: mourner]
[23:10:54] -!- r00t4rd3d has quit [Read error: Connection reset by peer]
[23:23:40] -!- zzolo has quit [Quit: zzolo]
[23:36:52] -!- mackerski has quit [Ping timeout: 260 seconds]
[23:47:48] -!- Nick001-Shop has quit [Remote host closed the connection]
[23:53:32] -!- asdfasd has quit [Ping timeout: 246 seconds]
[23:55:12] -!- bedah has quit [Quit: Ex-Chat]
[23:59:01] -!- mourner has quit [Quit: mourner]