Back
[04:02:39] <KGB-linuxcnc> 03Norbert Schechner 05master 40be0c9 06linuxcnc 10src/emc/usr_intf/gmoccapy/dialogs.py 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_0_3_1 - gremlin view click did take influence on start line * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=40be0c9
[05:18:51] <linuxcnc-build> build #96 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/96 blamelist: Norbert Schechner <nieson@web.de>
[06:24:12] <skunkworks> Would there be any issue putting the deb for circular blend rc3 somewhere? (like my site?)
[06:28:32] <skunkworks> (knowing that I will have to keep it updated)
[08:28:06] <cradek> skunkworks: you can distribute a binary package anytime you want, if you also distribute the corresponding source. so just stick the deb and the deb source (tar.gz and dsc files) at the same place on your site. there are other ways distribution is allowed, but putting binary and source alongside one another is the gold standard
[08:28:53] <cradek> (but a pointer to the buildbot is not suitable?)
[08:29:07] <skunkworks> well - the deb gets deleted after a few days...
[08:29:13] <skunkworks> (scratch builds)
[08:29:29] <cradek> ah, I see
[08:29:32] <skunkworks> Thanks though - that makes sensel
[08:29:36] <skunkworks> sense even
[08:39:32] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch ba7dceb 06linuxcnc 10(10 files in 7 dirs) fix some broken links * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ba7dceb
[08:39:32] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch bf90d4d 06linuxcnc 10docs/src/code/Contributing-to-LinuxCNC.txt fix some broken links * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bf90d4d
[09:06:54] <pcw_home> from the LinuxCNC forum:
[09:06:55] <pcw_home> "Every time the encoder.N.counts pin reaches 21475 counts, the machine quits jogging.
[09:06:57] <pcw_home> I jogged back and forth past 21475 and when it would count lower than that the machine
[09:06:58] <pcw_home> would start moving again, when it would count higher than that it would stop."
[09:07:40] <pcw_home> What the heck could cause this?
[09:09:05] <pcw_home> now that is ~215 turns of the jog wheel so maybe not seen very often
[09:23:00] <cradek> pcw_home: would be interesting to see that whole hal configuration
[09:24:04] <cradek> pcw_home: wheels tend to have 400 counts, so only 53 turns. but I'd think you'd run into either number ALL the time
[09:26:37] <jepler> is there a sim config with simulated jog wheel?
[09:26:54] <jepler> I am wondering what happens with soft limits and jog wheel if you never have homed
[09:28:29] <pcw_home> His wheel is on a 7I73 that defaults to 1x mode (100 counts/turn) if that makes a difference
[09:31:29] <archivist> I think I may have seen this with a stepper system non mesa using keyboard jog
[09:32:09] <archivist> I never really quantified what/when though
[09:34:04] <jepler> in the non-homed situation, if the increment of jog-counts times the jog-scale is more than the total machine travel, nothing happens
[09:34:21] <jepler> so e.g., this won't jog anything (but 79 would) in the basic axis sim configuration:
[09:34:26] <jepler> halcmd: setp axis.0.jog-enable 1
[09:34:26] <jepler> halcmd: setp axis.0.jog-scale 1
[09:34:30] <jepler> halcmd: setp axis.0.jog-counts 81
[09:34:38] <jepler> and this seems related to the X travel of -40..40
[09:35:21] <jepler> but this ends up doing 5in of motion:
[09:35:21] <jepler> halcmd: setp axis.0.jog-counts 21475
[09:35:21] <jepler> halcmd: setp axis.0.jog-counts 21480
[09:35:45] <pcw_home> I though only relative jog counts were used
[09:39:04] <jepler> after homing, a change in jog-counts that would go past soft limits is discarded
[09:39:45] <jepler> so except for weirdness that results from "very discontinuous" changes in jog-counts, wheel jogging via the motion controller doesn't behave too weirdly for me
[09:40:13] <jepler> but since behavior before/after homing is a bit different, I'd investigate whether the user is homing and find out about soft limits configuration
[09:40:46] <jepler> and of course whether the 21475 number is independent of jog scale
[09:40:58] <jepler> I sort of assumed it was
[09:41:09] <jepler> er, sort of assumed only one jog scale was being tested
[09:43:13] <pcw_home> I still dont really understand why is jogging is not relative
[09:43:15] <pcw_home> (say someone always does some jogging in one direction
[09:43:16] <pcw_home> on some part throughout the day, they will always run out of range)
[09:44:44] <jepler> new_jog_counts = *(joint_data->jog_counts);
[09:44:44] <jepler> delta = new_jog_counts - joint->old_jog_counts;
[09:44:44] <jepler> /* save value for next time */
[09:44:44] <jepler> joint->old_jog_counts = new_jog_counts;
[09:44:48] <jepler> distance = delta * *(joint_data->jog_scale);
[09:45:15] <jepler> the motion controller gets the "absolute" counts and computes the delta internally
[09:46:54] <jepler> pos = joint->free_pos_cmd + distance;
[09:47:20] <jepler> then min/max jog limit are applied (this is what causes the large steps in jog-counts to not jog at all)
[09:47:38] <jepler> and then the endpoint can be moved closer in "velocity mode"
[09:47:48] <jepler> the code is simple enough that the bug is not obvious :-P
[09:48:08] <jepler> oh and of course halui has its own jogging inputs; important to know whether it's halui jogging or realtime jogging
[09:48:32] <pcw_home> realtime
[09:50:05] <pcw_home> is there an issue with delta being an int (I dont know C but mixed size math make me itchy)
[09:50:30] <jepler> should be fine until jog counts get into the billions
[09:51:40] <jepler> old_jog_counts, new_jog_counts, delta are all ints
[09:52:00] <jepler> so 32 bits
[09:52:38] <jepler> and jog_counts should also be 32 bits
[10:01:53] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch 3544bb2 06linuxcnc 10docs/src/common/User_Concepts.txt 10docs/src/gcode/gcode.txt fix some broken links * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3544bb2
[10:07:29] <linuxcnc-build> build #97 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/97 blamelist: Francis Tisserant <tissf@free.fr>
[10:20:44] <pcw_home> I does seem like somehow the absolute count gets used when it should be irrelevant
[10:20:45] <pcw_home> (the OP is going to have the operator shut down linuxcnc once a day so the jog encoder counts are cleared at least once a day)
[10:46:37] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch 2218b6c 06linuxcnc 10docs/src/gui/gladevcp.txt 10docs/src/gui/gladevcp_de.txt 10docs/src/gui/gladevcp_es.txt 10docs/src/gui/gladevcp_pl.txt fix some asciidoc warnings * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2218b6c
[10:52:05] <skunkworks> pcw_home, did you try rt_preempt?
[11:01:12] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master b8c2300 06linuxcnc 10docs/src/gcode/gcode.txt 10docs/src/gcode/overview.txt 10docs/src/gcode/tool_compensation.txt 10docs/src/gui/gladevcp.txt Merge remote-tracking branch 'origin/v2.5_branch' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8c2300
[11:03:13] <seb_kuzminsky> hey folks
[11:03:36] <seb_kuzminsky> i missed the realtime jog wheel issue, is that still a problem? is it reproducible in sim?
[11:04:25] <pcw_home> skunkworks: yeah no go (Ill try 3.12 but 3.10 wont work with the new Intel video)
[11:06:26] <pcw_home> seb_kuzminsky: it look like they leave linuxcnc on all week and the encoder counts get big from many one directional jogs
[11:08:24] <cradek> but you said the count was 21475
[11:08:55] <pcw_home> Thats what the poster said
[11:09:28] <pcw_home> it should be able to be anything withou causing trouble
[11:10:55] <cradek> I'm just saying we don't seem to understand the problem yet
[11:11:05] <cradek> or maybe it's just me who doesn't
[11:11:38] <pcw_home> the jog wheel encoder count may drift over days to be any size
[11:12:19] <cradek> it's a mesa encoder counter, not software?
[11:12:22] <pcw_home> but that should not affect the jogging code in motion
[11:12:40] <pcw_home> actually he was using a software encoder
[11:12:53] <cradek> I agree with you in principle, but if it was failing at 21475 this is not the problem they're having, right?
[11:13:21] <cradek> ok, software encoder might have a problem
[11:13:48] <pcw_home> Yes when th eencoder count get to 21475 it stop jogging (but the encoder keeps counting)
[11:14:10] <cradek> that might be soft limits
[11:14:32] <pcw_home> but the encoder count shoud be irrelevant
[11:14:55] <seb_kuzminsky> is it always the same encoder count?
[11:15:22] <cradek> yes I'd expect it to stop jogging and count up past that, but then when counting downward it would jog the other way
[11:15:29] <cradek> [if soft limits]
[11:15:34] <pcw_home> yes it does
[11:16:13] <cradek> can you share the original bug report?
[11:17:19] <pcw_home> its on the LinuxCNC forum:
[11:17:21] <pcw_home> http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27620-remote-pendant-acting-erraticly
[11:19:40] <cradek> could also be ilowpass
[11:19:59] <cradek> since he was looking at encoder.0.counts but not further along
[11:25:14] <cradek> the s32 counts would roll over if someone turned the jogwheel 1rps, 8 hours a day, for 2 years
[11:25:41] <jepler> ilowpass scales by 1024 by default
[11:25:51] <cradek> setp ilowpass.0.gain 0.009
[11:25:52] <cradek> setp ilowpass.0.scale 100
[11:27:10] <cradek> that changes the two years to a week
[11:28:35] <cradek> I notice 21475 is 2^31/10000
[11:29:05] <jepler> in sim at least, when you set ilowpass0.in to above 20 million or so it sticks at the most negative number
[11:29:39] <cradek> I wish we had 64 bit counts like we have 64 bit floats
[11:30:02] <jepler> the implicit cast from double to int here apparently uses most-negative-number when the input value is not in range: 'out = value * scale'
[11:30:53] <cradek> so is this the fix: ilowpass should handle rollover on the input, and jogging should handle rollover on the input
[11:31:48] <jepler> cradek: you mean 2^31 / 100000 ?
[11:31:53] <cradek> I wonder if he had ilowpass scale 10000 when he had this problem and his report in the forum is inconsistent, or if there's still some part of it we don't understand
[11:32:06] <cradek> yes you're right
[11:33:08] <cradek> so we're losing a factor of 1e5 somewhere here and that's a lot
[11:35:25] <cradek> seb_kuzminsky: lsmod/ps/kill show up correctly in
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-i386/builds/79/steps/shell_3/logs/stdio - would you confirm that cradek/wheezysim is the right fix?
[11:35:41] <jepler> -out = value * scale;
[11:35:42] <jepler> +out = (int)(__s64)(value * scale);
[11:35:52] <jepler> this makes ilowpass behave better until it hits the __s64 limit
[11:37:04] <cradek> but it'll still fail when the output (hal pin) hits a s32 limit, right?
[11:38:58] <jepler> when I change jog-counts from 2147483647 to -2147483648 with jog-scale 1, I get a a movement of +1
[11:39:12] <cradek> wow
[11:39:57] <jepler> if we want this behavior of integers, we should make sure we specify -fno-strict-overflow, though
[11:41:00] <jepler> traditionally, arithmetic overflows on signed integers just did the natural thing
[11:41:17] <jepler> but clever compilers are starting to take advantage of the standard when it says the result of the operation is undefined
[11:41:58] <jepler> without it, "For example, the compiler will assume that an expression like `i + 10 > i` will always be true for signed i."
[11:42:32] <jepler> oh or maybe -fwrapv, which "means that integer signed overflow is fully defined: it wraps"
[11:42:47] <jepler> I think that best expresses the semantics we want when we take differences of signed integers which are counts
[11:43:08] <KGB-linuxcnc> 03Chris Radek 05cradek/wheezysim 57da699 06linuxcnc 10debian/configure Add dependency to provide /bin/fuser * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=57da699
[11:43:47] <jepler> cradek: (that diff looks sane to me)
[11:44:17] <cradek> I'd rather configure would fail if it results in brokenness - I'm looking into that
[11:58:06] <jepler> http://emergent.unpythonic.net/files/sandbox/integer-cleanups.patches.mbox
[12:04:29] <KGB-linuxcnc> 03Chris Radek 05cradek/wheezysim a46add4 06linuxcnc 10src/configure.in Fail on missing programs, instead of generating bogus scripts * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a46add4
[12:07:28] <linuxcnc-build> build #98 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/98 blamelist: Francis Tisserant <tissf@free.fr>
[12:09:08] <cradek> jepler: about your patches: thanks for being a wizard
[12:20:20] <seb_kuzminsky> cradek: those checks in configure and the build-dependencies look right to me
[12:20:42] <seb_kuzminsky> do you know if we also have the correct runtime dependencies for those programs? i bet they're installed on every real system, but just for completeness sake...
[12:21:07] <seb_kuzminsky> makes me wish we had proper linuxcnc-test packages, that we could run in a chroot...
[12:21:20] <seb_kuzminsky> maybe we could add runtests to the deb build
[12:22:11] <cradek> a spot check shows psmisc depends on libtinfo5; I would sure think they all depend on their own runtime dependencies
[12:22:23] <cradek> or am I misunderstanding your question
[12:22:57] <seb_kuzminsky> i meant, "do you know if linuxcnc (runtime-)depends on psmisc, kmod, etc?"
[12:23:29] <cradek> isn't that what I just added?
[12:23:32] <seb_kuzminsky> i bet all debs in debian.org and ubuntu.com have the correct runtime dependencies that they need, but i'm not sure if our debs do
[12:23:35] <seb_kuzminsky> err
[12:23:46] <cradek> or did I add build-deps
[12:23:49] <seb_kuzminsky> no, you added build dependencies
[12:23:54] <seb_kuzminsky> which are also needed
[12:24:12] <cradek> no, then I have it wrong
[12:24:42] <cradek> err I guess they are, so configure works
[12:25:02] <seb_kuzminsky> configure builds scripts/realtime et al, and needs those programs available at build time so the substitutions work right
[12:25:08] <cradek> yes you're right
[12:25:14] <seb_kuzminsky> but then we also need them installed at runtime, so the substituted programs actually exist
[12:25:22] <cradek> I understand
[12:26:05] <cradek> isn't there a list of basic things you can assume will work, so you don't have to runtime-depend-on them?
[12:27:45] <seb_kuzminsky> any package marked "Essential" can be assumed to be installed
[12:27:48] <cradek> for example /usr/bin/apt-key is a shell script calling #!/bin/sh, but the apt package doesn't depend on any shells
[12:28:01] <cradek> aha that's the ticket
[12:28:49] <seb_kuzminsky> err, i may be misremembering
[12:28:55] <seb_kuzminsky> is it "Priority: required"?
[12:29:00] <cradek> sed is Essential
[12:29:09] <memleak> heh debian makes packaging quite difficult!
[12:29:22] <cradek> procps is not Essential
[12:29:48] <cradek> haha procps is Priority:required
[12:29:57] <seb_kuzminsky> https://www.debian.org/doc/debian-policy/ch-binary.html#s3.8
[12:29:58] * cradek throws up his hands and goes to lunch
[12:30:46] <cradek> The base system consists of all those packages with priority required or important. Many of them will be tagged essential (see below).
[12:30:53] <seb_kuzminsky> procps is Priority:important on my wheezy box
[12:31:12] <cradek> oh you're right
[12:31:17] <seb_kuzminsky> bash is Essential:yes
[12:31:34] <seb_kuzminsky> and Priority:required
[12:31:47] <cradek> lunch lunch
[12:32:13] <seb_kuzminsky> coffee
[12:36:56] <memleak> Priority: Lunch Essential: Coffee ;)
[12:38:47] <seb_kuzminsky> heh
[12:45:02] <skunkworks> linuxcnc-build: force build --branch=circular-blend-arc-rc3 0000.checkin
[12:45:08] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[12:47:29] <KGB-linuxcnc> 03Norbert Schechner 05master 87d97e8 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_0_3_2 - version number also on settings page * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=87d97e8
[12:47:29] <KGB-linuxcnc> 03Norbert Schechner 05master 2549705 06linuxcnc Merge branch 'master' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2549705
[13:14:30] <memleak> does dpkg actually have an AI to it or something now? i heard someone was playing sudoku with it
[13:17:04] <memleak> http://algebraicthunk.net/~dburrows/blog/entry/package-management-sudoku/ there it is!
[14:06:44] <linuxcnc-build> build #99 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/99 blamelist: Francis Tisserant <tissf@free.fr>
[14:11:45] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch 14528f8 06linuxcnc 10(5 files) Cleaning for a better use of titles * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=14528f8
[14:36:55] <lair82> Hey guys, I am the one with the problem handwheel counts that pcw has been talking about.
[14:37:18] <seb_kuzminsky> hi lair82 !
[14:37:31] <seb_kuzminsky> glad you could join us here
[14:37:40] <lair82> I do have the scale value set at 100000, I will try to get that down to 1000-10000 if possible.
[14:37:47] <lair82> Thanks Seb
[14:38:33] <seb_kuzminsky> ah, interesting
[14:38:53] <seb_kuzminsky> which version of linuxcnc are you using? ("dpkg -s linuxcnc | grep Version" will tell you)
[14:38:59] <lair82> I'm not sure why the value was up that high on the encoder.N.counts value, they said that they shut the machine down late lastnight
[14:39:34] <lair82> I'm running the latest version of master
[14:39:55] <seb_kuzminsky> ok, great
[14:40:01] <lair82> I cant acces the machine right now they are making chips on it right now.
[14:40:10] <seb_kuzminsky> i'm glad to hear it's making chips :-)
[14:41:57] <seb_kuzminsky> are you using the debs from the buildbot or building linuxcnc by hand?
[14:42:22] <lair82> I build everything by hand from the terminal.
[14:42:57] <lair82> Hopefully tomorrow I can get 10 minutes on the machine and change the values down to avoid this again.
[14:43:23] <skunkworks> does the encoder count differently one way vs the other?
[14:44:10] <lair82> If you change the ilowpass scale value, it will change the ilowpass output value
[14:44:37] <skunkworks> or do you guys mostly jog it only 1 direction?
[14:45:21] <seb_kuzminsky> lair82: jepler did some work that might mitigate the overflow, he might have words of wisdom when he comes around
[14:45:21] <lair82> No it is counting up and down properly if thats what you meant.
[14:45:56] <lair82> I will have to update you guys tomorrow, I'm out of here in couple minutes, I look forward to seeing what he came up with.
[14:46:09] <seb_kuzminsky> ok cool, thanks for stopping by with the details!
[14:46:42] <lair82> And its good to now know how to get ahold you guys a little easier than through the forum
[14:47:18] <seb_kuzminsky> heh yeah... the forum is very active, but several of the developers dont go there :-(
[14:47:49] <seb_kuzminsky> this irc channel and the two mailing lists are much more widely read by the developers
[15:36:18] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch e797704 06linuxcnc 10docs/src/config/ini_config.txt 10docs/src/config/ini_config_de.txt 10docs/src/config/ini_config_es.txt 10docs/src/config/ini_config_fr.txt bad code delimiters previously entered by mystake * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e797704
[15:44:48] <asah> anyone know what bldc.N.value is on the bldc comp ? it is listed as pwm amplitude, but is this a velocity input basically? if positive should the motor spin in the positive dir infinitly? or is this a phase relative value, an offset from the absolute 0 phase angle alignment?
[15:46:08] <seb_kuzminsky> asah: the guy who'd know is andy pugh, try sending an email to the emc-developers list asking him to improve his docs ;-)
[15:46:23] <asah> =)
[15:56:09] <CaptHindsight> seb_kuzminsky: memleak just mentioned that he could support 3.10 RTAI kernels in no time, he just hasn't merged it yet
[15:56:56] <CaptHindsight> so ubuntu 14.04 with a 3.10 RTAI kernel is not a problem
[16:00:06] <seb_kuzminsky> that's great!
[16:00:48] <CaptHindsight> we're pretty much sticking with gentoo on our projects, and we'll share what we can
[16:01:27] <linuxcnc-build> build #100 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/100 blamelist: Norbert Schechner <nieson@web.de>, Sebastian Kuzminsky <seb@highlab.com>, Francis Tisserant <tissf@free.fr>
[16:01:32] <seb_kuzminsky> looks like 14.04 "trusty" is shipping 3.13 by default, how hard would that be to support?
[16:01:35] <seb_kuzminsky> http://packages.ubuntu.com/search?keywords=linux-image&searchon=names&suite=trusty§ion=all
[16:01:51] <memleak> seb_kuzminsky, 3.13 isn't LTS.
[16:02:11] <memleak> we and the rest of the group only support long-term support kernels
[16:02:16] <memleak> *me and the rest...
[16:03:02] <seb_kuzminsky> what's the nearest lts kernel?
[16:03:15] <seb_kuzminsky> 3.12, it looks like
[16:03:19] <memleak> fixes in 3.13 kernel will be backported to 3.12 and fewer in 3.10
[16:03:20] <seb_kuzminsky> https://www.kernel.org/
[16:03:25] <seb_kuzminsky> right
[16:03:44] <memleak> 3.12 might be a little easier to support
[16:04:41] <memleak> (compared to 3.13) but honestly not much has changed
[16:04:42] <seb_kuzminsky> easier than 3.10?
[16:04:45] <seb_kuzminsky> oh, i see
[16:04:48] <memleak> 3.10 is already doe
[16:04:50] <memleak> *done
[16:05:02] <memleak> but i have not merged the code to github
[16:05:40] <memleak> when i merge it though i will rebase the 3.10 support to latest 3.10 release
[16:05:59] <memleak> i think it's currently ported to 3.10.0 but thats not hard at all
[16:06:03] <seb_kuzminsky> memleak: you said up above "me and the rest of the group"... does that mean paolo and shabby? who all is working on rtai these days?
[16:06:26] <memleak> shabby doesn't touch the kernel side of things, just me and paolo.
[16:06:32] <seb_kuzminsky> and do you think any of them/you could be talked into maintaining kernel debs?
[16:07:16] <seb_kuzminsky> or anyone here in #linuxcnc-devel, for that matter?
[16:07:44] <memleak> i dont think shabby would volunteer, hes been pretty busy with other stuff and paolo has enough on his hands.
[16:07:59] <CaptHindsight> who has been making the debs so far?
[16:08:04] <seb_kuzminsky> ah yes, the hand shortage, i'm familiar with this ;-)
[16:08:06] <seb_kuzminsky> CaptHindsight: i have
[16:08:30] <memleak> paolo does more kernel-side RTAI work than i do...
[16:08:37] <seb_kuzminsky> mozmck made the ones for lucid back in 2010, and before that i think it was... maybe jepler?
[16:09:19] <memleak> andypugh is a cool guy, hes not here right now but maybe give him a shot? i could see him building debs...
[16:09:57] <seb_kuzminsky> it's mostly a managerial job of following the development process and communicating with the devs about what they're willing to support, and then running some scripts (that i've already written)
[16:10:14] <CaptHindsight> so we need someone to make and maintain the kernel debs
[16:10:19] <memleak> ah well if you write the scripts..
[16:10:37] <memleak> i never built debs before but if its already automated by you i guess i could?
[16:11:06] <seb_kuzminsky> not fully automated, but if that's what it took to hand it off i could push that part of it forward
[16:12:21] <memleak> i'm also going to be working on an updated linuxcnc livecd based off of gentoo and i have a few other things i'm working on right now but when my time frees up i could see myself doing something like that
[16:12:42] <memleak> but i dont want to commit to something while in a busy state
[16:13:12] <CaptHindsight> post a call for a volunteer
[16:13:27] <CaptHindsight> maybe someone is already interested
[16:16:53] <seb_kuzminsky> CaptHindsight: that's a good idea
[16:17:06] <seb_kuzminsky> memleak: do you have a gentoo ebuild for linuxcnc working? if so let's merge it into master!
[16:17:09] <seb_kuzminsky> bbl
[16:26:39] <memleak> seb_kuzminsky, no i dont really bother with ebuilds..
[16:26:57] * memleak has a tendency to bypass all package managers, all the time
[16:27:32] <memleak> unless i want a custom version of system-wide GCC or something like that.. then i write ebuils
[16:27:36] <memleak> *ebuilds
[16:52:01] <CaptHindsight> PCW says memleak: One vote for 3.12 instead of 3.10
[17:17:12] <memleak> ill take a look at how difficult it will be to bump support to 3.12, if its not a huge leap i can do that. it'll take time though, regardless of difficulty.
[17:17:49] <memleak> i've been working on a cubieboard2 a lot lately.
[17:19:47] <memleak> while im working on that, someone should fix the 64-bit math support (SSE -ffast-math stuff)
[17:19:55] <memleak> in linuxcnc i mean^
[17:20:40] <memleak> apparently 64-bit linuxcnc only works with RTAI on ubuntu and debian.. i cant get it all working anymore with gentoo arch slackware or fedora
[17:21:11] <memleak> compiling errors on 5kins and other modules, sincos stuff
[17:23:11] <memleak> jepler and i talked about fixing it but it seems its very sensitive to things which affect what systems 64-bit linuxcnc runs on and which ones it doesn't
[17:23:35] <memleak> at some point, there should be a proper fix that works with all systems and before the next major release, i think that should be a priority.
[17:24:25] <memleak> RTAI 64-bit itself runs flawlessly on 64-bit systems, if linuxcnc did the same, that'd solve everything really.
[17:29:12] <seb_kuzminsky> hrm, linuxcnc builds & runs on 64 bit, at least in simulation mode
[17:29:27] <memleak> debian right?
[17:29:31] <seb_kuzminsky> yeah
[17:29:48] <seb_kuzminsky> but i dont know why the underlying distro should matter
[17:29:55] <memleak> ah right because its the low-level drivers that fail
[17:30:15] <seb_kuzminsky> we use different cflags for realtime code vs userspace code, maybe that's it
[17:30:15] <memleak> seb_kuzminsky, could you test on debian (since you have it) non-sim with RTAI?
[17:30:28] <seb_kuzminsky> in 64-bit?
[17:30:30] <memleak> yes
[17:30:43] <seb_kuzminsky> yes, i'll test that
[17:31:12] <seb_kuzminsky> but first i need to make a 64-bit rtai kernel deb, and i'll need you to remind me where you 64-bit rtai kernel config is
[17:31:21] <memleak> i'm almost hoping it doesn't work for you so it's more of a global issue and more people can see the problem for themselves, in turn, better & faster fix.
[17:31:41] <memleak> it's been broken for me for more than half a year.
[17:32:39] <seb_kuzminsky> i consider the buildbot the set of configs that i'll support - if it's not in there, it's pretty much off my radar
[17:32:49] <seb_kuzminsky> i'd like to add a 64-bit rtai buildslave for precise & wheezy
[17:34:01] <memleak> ah i might need to make a new config..
[17:34:09] <memleak> i think i only made a big generic kernel for 32
[17:34:21] <memleak> the one you used to build 3.4.55 debs
[17:35:25] <memleak> should only take a second
[17:35:38] <memleak> seb_kuzminsky, what kernel version you want the config for?
[17:35:51] <memleak> 3.4.latest/XX 3.4.55?
[17:39:24] <linuxcnc-build> build #1518 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/1518 blamelist: Chris Radek <chris@timeguy.com>
[17:40:14] <linuxcnc-build> build forced [ETA 1h45m53s]
[17:40:14] <linuxcnc-build> I'll give a shout when the build finishes
[17:42:38] <linuxcnc-build> build #353 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/353 blamelist: Chris Radek <chris@timeguy.com>
[17:44:13] <linuxcnc-build> build #101 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/101 blamelist: Chris Radek <chris@timeguy.com>
[17:46:42] <linuxcnc-build> build #1524 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/1524 blamelist: Chris Radek <chris@timeguy.com>
[17:52:27] <linuxcnc-build> build #1523 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/1523 blamelist: Chris Radek <chris@timeguy.com>
[17:57:57] <seb_kuzminsky> memleak: hmm, i guess for now the same kernel we're already shipping for 32-bit: 3.4.55
[17:58:03] <seb_kuzminsky> thanks
[18:08:41] <linuxcnc-build> build #1519 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/1519 blamelist: Chris Radek <chris@timeguy.com>
[18:10:20] <jepler> it looks like maybe cradek only added fuser as a binary package dependency, but checks for it at configure time -- so this implies it has to be a build-time dependency as well
[18:10:38] <linuxcnc-build> build #1519 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/1519 blamelist: Chris Radek <chris@timeguy.com>
[18:12:04] <seb_kuzminsky> jepler: no, cradek added procps, kmod, and psmisc to EXTRA_BUILD
[18:14:17] <seb_kuzminsky> hm, so why cant it find it?
[18:15:56] <seb_kuzminsky> oh, because it obly got added to the debian-7 EXTRA_BUILD maybe? and these failures are on lucid & precise
[18:16:34] <seb_kuzminsky> the three new dependencies should maybe be added to debian/control.in's Build-Depends (and Depends)
[18:16:58] <seb_kuzminsky> cradek: no good deed goes unpunished
[18:20:02] <seb_kuzminsky> those distros failed to find fuser before cradek/wheezysim too, but it was a warning instead of a build failure, and they just kept going
[18:22:05] <seb_kuzminsky> fuser is only used in scripts/realtime's CheckMem, "check for user space processes using shared memory"
[18:22:20] <seb_kuzminsky> and then, only if it finds /dev/mbuff or /dev/rtai_shm
[18:25:27] <seb_kuzminsky> my lucid-rtai machine has neither
[18:25:47] <seb_kuzminsky> same with hardy-rtai
[18:26:15] <seb_kuzminsky> and precise-rtai
[18:26:41] <seb_kuzminsky> looks like an old vestigial snippet of code that's been broken for a long time and no one noticed
[18:27:12] <seb_kuzminsky> i think this means we can get rid of CheckMem from scripts/realtime, and remove the check for fuser
[18:27:38] <seb_kuzminsky> jepler: do you know anything about the 64-bit problem memleak was talking about above?
[18:36:12] <memleak> he wrote the section im talking about so yes :P
[18:47:42] <skunkworks> is there a place on the buildbot to see what is queued up?
[18:48:33] <jepler> seb_kuzminsky: I don't know any specifics
[18:49:48] <jepler> it's been years since I had a 64-bit rtai system personally. michael(?) buesch was another. his system needed different flags than mine, and we tried to sort it out. reportedly, these consensus cflags don't work for memleak's kernels, ...
[18:50:20] <seb_kuzminsky> hmm
[18:50:56] <jepler> in my view, rtai has a config script which is supposed to give flags that work. somebody should write a standalone, math-using kernel module and find out whether it works
[18:51:24] <seb_kuzminsky> is that script rtai-config?
[18:51:28] <jepler> right
[18:51:35] <seb_kuzminsky> and does it lie?
[18:52:34] <jepler> it has at times. for example,
http://mid.gmane.org/4B4C56BB.3070808%40gmx.net
[18:52:48] <jepler> and here's zultron in december, a thread I don't think I even read:
http://mid.gmane.org/52B94651.7060305%40zultron.com
[18:52:51] <jepler> (that is zultron, right?)
[18:53:32] <seb_kuzminsky> yesh, john morris == zultron
[18:54:24] <seb_kuzminsky> yikes
[18:56:03] <seb_kuzminsky> heh, in my precise rtai-modules package, "rtai-config --module-cflags" includes "-I."
[18:56:06] <seb_kuzminsky> d'oh
[18:56:29] <jepler> *wholebodypalm*
[18:56:36] <jepler> that seems unlikely to be right
[18:56:54] <memleak> im working on that kernel config now
[18:57:01] <seb_kuzminsky> *faceforearm*
[18:57:08] <memleak> seb_kuzminsky, where ya wan it?
[18:57:47] <memleak> is a torrent ok?
[18:58:43] <seb_kuzminsky> seems overkill for a few kB of configs, but that's fine
[18:58:49] <memleak> XD
[18:58:51] <seb_kuzminsky> filebin.com?
[18:59:20] <seb_kuzminsky> err, .ca
[18:59:27] <memleak> filebin it is!
[19:06:15] <linuxcnc-build> Hey! build 0000.checkin #1958 is complete: Success [3build successful]
[19:06:16] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/1958
[19:09:11] <cradek> my rtai machine has /dev/rtai_shm whenever realtime is running
[19:09:18] <cradek> I don't think this is dead code
[19:09:39] <cradek> crw-rw-rw- 1 root root 10, 254 Mar 25 18:49 /dev/rtai_shm
[19:10:18] <seb_kuzminsky> hmm, then how is it working at all?
[19:10:40] <cradek> if it's only used for cleanup/restart, it's just probably broken
[19:10:49] <cradek> that hasn't worked right for a while
[19:10:56] <cradek> digging...
[19:11:10] <seb_kuzminsky> ah yes, CheckMem is only called on 'realtime restart' and 'realtime stop'
[19:11:13] <seb_kuzminsky> bbl
[19:16:01] <skunkworks> linuxcnc-build: thank you
[19:16:06] <linuxcnc-build> build #102 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/102
[19:16:51] <memleak> turl.ca/zpweh
[19:17:03] <memleak> ^64-bit rtai generic kernel config for 3.4.55
[19:18:06] <memleak> based off of 3.2 kernel for amd64 systems by debian devs
[19:18:09] <skunkworks> wait - that wasn't it
[19:19:46] <memleak> was that to me? i just checked.
[19:20:06] <cradek> will buildbot tolerate me force-pushing my branch?
[19:24:37] <jepler> cradek: think that yes (buildbot)
[19:30:41] <KGB-linuxcnc> 03Chris Radek 05cradek/wheezysim 514a60b 06linuxcnc 10debian/control.in These are needed for building and running on all platforms * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=514a60b
[19:30:41] <KGB-linuxcnc> 03Chris Radek 05cradek/wheezysim 6840a0a 06linuxcnc 10src/configure.in Fail on missing programs, instead of generating bogus scripts * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6840a0a
[19:30:57] <cradek> nth try is the charm
[19:31:37] <skunkworks> micges: how is the familly?
[19:32:31] <micges> finally good, all of us were sick at the same time
[19:32:39] <skunkworks> I heard - yeck'
[19:32:57] <skunkworks> so far - we have only all had the cold at the same time\
[19:37:01] <micges> wather is crazy here, no freeze on februrary isn't so common
[19:37:52] <micges> often we had -30 celsius for few weeks
[20:00:45] <memleak> why does linuxcnc depend on PAM?
[20:01:10] <memleak> it breaks compatibility with directfb, startx, and if you don't want a display manager, just a window manager.
[20:01:50] <memleak> also some desktop managers like xdm do not support PAM, you need something bigger, lxdm being the smallest DM to support PAM
[20:02:22] <cradek> where do you see the pam dependency?
[20:02:24] <memleak> (a very recent version of lxdm too because it was just added to the tree not too long ago)
[20:02:39] <memleak> linuxcnc doesn't run without pam
[20:03:20] <cradek> in what way doesn't it run?
[20:03:44] <memleak> ulimit is hosed
[20:03:53] <cradek> in what way is ulimit hosed?
[20:04:24] <memleak> linux.die.net/man/5/limits.conf keyword: pam_limits.so
[20:06:09] <cradek> would you just say what you're talking about please?
[20:08:26] <cradek> on a non-pam setup are you having a problem with not enough locked-in memory being available? if so there must be another way to set the limit
[20:08:36] <memleak> wiki.linuxcnc.org/cgi-bin/wiki.pl?RtaiSteps "without PAM it could be a LOT more difficult, depending on your login method" -> wiki.linuxcnc.org/cgi-bin/wiki.pl?LockedMemory
[20:08:42] <memleak> yes exactly
[20:09:02] <memleak> there is another way?
[20:09:04] <cradek> ok then you need to figure out how your non-pam system sets that limit, right?
[20:09:08] <cradek> I don't know
[20:09:23] <cradek> I only just figured out what you were even talking about
[20:09:54] <memleak> sorry, i'm not a good speaker.
[20:10:11] <memleak> expressing myself i mean
[20:10:58] <memleak> i guess a better question is why does linuxcnc require 20480 of unlocked shmem?
[20:11:06] <memleak> (KiB)
[20:13:30] <jepler> because any page of code or data that might be touched by realtime code needs to be mlock()ed or equivalent.
[20:14:19] <memleak> ah i see
[20:14:52] <jepler> and that might not actually be enough for the userspace realtimes -- running axis, rtapi_app has a vsz of 46520 (KiB)
[20:15:35] <memleak> so triple the size would be good practice?
[20:17:00] <jepler> the number we have now was probably chosen a long time ago and only with rtai systems in mind: the locked size limit is applied to rtai shared memory segments--mainly the hal shared memory area, which is 262000 bytes at the moment
[20:17:16] <jepler> but the "normal" code and data of realtime modules would also never be swapped, because kernel space
[20:17:26] <jepler> while not counting against this limit
[21:06:04] <linuxcnc-build> build #103 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/103 blamelist: Francis Tisserant <tissf@free.fr>
[21:09:26] <skunkworks> logger[
[21:09:28] <skunkworks> logger[mah]_:
[21:09:29] <logger[mah]_> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-03-26.html
[21:18:26] <linuxcnc-build> build #1956 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/1956 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Francis Tisserant <tissf@free.fr>, Chris Radek <chris@timeguy.com>,
[21:18:26] <linuxcnc-build> Norbert Schechner <nieson@web.de>
[21:23:38] <linuxcnc-build> build #1957 of 1200.rip-lucid-i386 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/1957 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Francis Tisserant <tissf@free.fr>, Chris Radek <chris@timeguy.com>, Norbert
[21:23:38] <linuxcnc-build> Schechner <nieson@web.de>
[21:25:33] <cradek> ugh, what on earth have I done to rip-lucid-i386
[21:32:34] <skunkworks> what happened to innocent until proven guilty?
[21:34:29] <memleak> am i the only one who initially reads rip-environment as rest in peace instead of run in place?
[21:34:48] <skunkworks> yes
[21:34:50] <skunkworks> ;)
[21:36:04] <memleak> i have such a difficult time getting that out of my head
[21:45:14] <pcw_home> Great now I will too
[21:56:01] <linuxcnc-build> build #1959 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/1959 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Francis Tisserant <tissf@free.fr>, Chris Radek <chris@timeguy.com>,
[21:56:01] <linuxcnc-build> Norbert Schechner <nieson@web.de>
[21:58:54] <linuxcnc-build> build #1958 of 1202.rip-lucid-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/1958 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Francis Tisserant <tissf@free.fr>, Chris Radek <chris@timeguy.com>, Norbert
[21:58:54] <linuxcnc-build> Schechner <nieson@web.de>
[22:06:02] <linuxcnc-build> build #1960 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/1960 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Francis Tisserant <tissf@free.fr>, Chris Radek <chris@timeguy.com>, Norbert Schechner <nieson@web.de>
[22:21:53] <seb_kuzminsky> rest in peace
[22:21:56] <seb_kuzminsky> harmonious repose
[22:23:07] <skunkworks> build 1958 was for me.. It must take a little while for the debs to show up..
[22:23:11] <skunkworks> YAY
[22:25:56] <seb_kuzminsky> yay :-)
[22:26:13] <seb_kuzminsky> it always pleases/amazes me when something works right
[22:28:35] <seb_kuzminsky> cradek: looks like kmod is a virtual package, and that confuses the build-dependency installer helper thingy
[22:33:53] <seb_kuzminsky> that's what broke the build on lucid - the confused build-dep thingy uninstalled(!) libusb-1.0-0-dev
[22:34:00] <seb_kuzminsky> i think maybe you want module-init-tools instead?
[22:36:26] <seb_kuzminsky> kmod is raring and newer, module-init-tools is precise (and maybe older?)
[22:39:17] <memleak> it is older
[22:42:35] <seb_kuzminsky> ah, in wheezy it's called kmod, i bet that's where cradek got it from