Back
[00:01:11] <linuxcnc-build_> build #2911 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2911
[00:08:24] <linuxcnc-build_> Hey! build 0000.checkin #3623 is complete: Success [3build successful]
[00:08:24] <linuxcnc-build_> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3623
[00:08:56] <linuxcnc-build_> build #2916 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/2916
[00:27:50] <linuxcnc-build_> build #1799 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1799 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[00:33:21] <linuxcnc-build_> build #2912 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2912
[00:43:01] <linuxcnc-build_> build #3612 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3612 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[00:44:10] <linuxcnc-build_> build #3610 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3610 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[00:46:29] <seb_kuzminsky> that's more like it
[00:47:06] <linuxcnc-build_> build #2819 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2819 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:20:21] <linuxcnc-build_> build #1771 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1771 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:21:36] <linuxcnc-build_> build #1962 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1962 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:23:50] <linuxcnc-build_> build #1281 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1281 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:23:59] <linuxcnc-build_> build #1770 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1770 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:39:16] <linuxcnc-build_> build #238 of 1502.rip-jessie-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/238 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:39:34] <linuxcnc-build_> build #238 of 1500.rip-jessie-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/238 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:39:58] <linuxcnc-build_> build #238 of 1503.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1503.rip-jessie-rtpreempt-amd64/builds/238 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:42:22] <linuxcnc-build_> build #1435 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1435 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:42:24] <linuxcnc-build_> build #238 of 1501.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1501.rip-jessie-rtpreempt-i386/builds/238 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:42:24] <linuxcnc-build_> build #3624 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3624 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:54:27] <seb_kuzminsky> now i'm glad that it's failing
[01:54:41] <seb_kuzminsky> i dont even know who i am any more
[06:02:32] <jthornton> opps
[07:27:12] <jepler> hee hee
[07:27:14] <jepler> 21:41:10 <seb_kuzminsky> the prettiest part of that website is the back end
[07:27:17] <jepler> 21:41:17 <seb_kuzminsky> that sounded dirty but i didnt mean it that way
[07:41:05] <KGB-linuxcnc> 03John Thornton 052.7 b5a6028 06linuxcnc 10docs/html/gcode.html Docs: fix file name in links * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b5a6028
[07:43:31] <jthornton> while that fixed the file name the links still don't work because the link in the generated file is g-code.html#_g0_rapid_move and the anchor is [[gcode:g0]] so I'm a bit confused at the moment
[07:55:55] <jthornton> while at the same time a link in the g-code.html to anywhere else works
[07:57:25] <jthornton> could it be because gcode.html is hand done and not part of the docs?
[08:10:28] <jepler> yes, a long time ago somebody (probably me) looked what anchors were defined in our docs and manually copied them into the hand-written gcode.html
[08:10:40] <jepler> but now those anchors don't exist anymore I guess
[08:17:55] <JT-Shop> I'll fix them
[08:37:25] <cradek> thanks, JT-Shop
[08:37:32] <jepler> yes, thank you
[08:48:11] <JT-Shop> but first there is conduit to run
[09:33:11] <jepler> nice, dreamhost.com says they are "actively working to add support for Let's Encrypt certificates"
https://discussion.dreamhost.com/thread-144626-post-185098.html#pid185098
[09:33:55] <jepler> .. once that happens, and letsencrypt leaves closed beta next week, we would be able to
https:// the www.linuxcnc.org webiste
[09:33:58] <jepler> website
[11:33:57] <CaptHindsight> did you guys just change the template for Linuxcnc forums or is Kunena a new forum?
[11:34:49] <mozmck> the forum is now a current version of kunena, it was a very old version.
[11:36:15] <CaptHindsight> very nice
[11:37:27] <mozmck> thanks to jepler! and seb_kuzminsky for re-making the website with no joomla.
[11:48:14] <jepler> CaptHindsight: hopefully we'll keep it up to date with security patches and so forth now
[11:48:24] <jepler> I intend to make sure to check weekly, we'll see how that goes
[12:07:52] <seb_kuzminsky> i'm going to be messing with the automation that uploads the docs to the website, to try to fix the mistake that let the broken links in the gcode overview go unnoticed
[12:08:23] <seb_kuzminsky> the docs links and things will probably be unstable and broken for a bit, and probably there'll be some buildbot errors here in irc
[12:20:20] <cradek> yeah that change did block the spam; I just discarded some
[12:24:24] <andypugh> Does gantrykins need the feedback wiring differently? I am trying to figure out this from the Gantrykins manpage
[12:24:27] <andypugh> “In the inverse kinematics, each joint gets the value of its corresponding axis. In the forward kinematics, each axis gets the value of the highest numbered corresponding joint. For example, with coordinates=XYYZ the Y axis position comes from joint 2, not joint 1.”
[12:25:37] <andypugh> So, in an XYZX machine, would you short-circuit the axis.0.motor-position-fb pin?
[12:28:50] <linuxcnc-build> build #2957 of 2000.docs is complete: Failure [4failed compile rsync-docs-to-www.linuxcnc.org] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/2000.docs/builds/2957 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[12:29:20] <seb_kuzminsky> so it begins
[12:49:13] <linuxcnc-build> build #2958 of 2000.docs is complete: Failure [4failed compile rsync-docs-to-www.linuxcnc.org] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/2000.docs/builds/2958 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[13:25:36] <mozmck> Hmm, so I added a disable pin to each joint, and made it act like the machine is off and set pos_cmd to pos_fb if the joint is disabled - but the TP doesn't like that :)
[13:26:33] <cradek> yeah I don't see how that can work without some major reengineering
[13:27:03] <mozmck> I'm learning a lot more about the internals of linuxcnc though :)
[13:27:27] <cradek> that's great
[13:27:32] <cradek> are you ok?
[13:27:36] <cradek> :-)
[13:27:39] <mozmck> a little green
[13:28:27] <cradek> green as in inexperienced, or green as in nauseous?
[13:28:38] <mozmck> um, yes!
[13:29:14] <mozmck> I really need to figure out a way to update the Z position after I hijacked it.
[13:29:44] <mozmck> The next item on my list is dual motor gantry homing.
[13:30:18] <cradek> seb and I got the homing test jig working (unexploded) again, and it's ready to send to you if you need it
[13:30:45] <mozmck> Oh, that might be good! I have a gantry machine in my shop I was going to test on.
[13:31:03] <mozmck> But it's steppers, and no index etc.
[13:31:07] <cradek> ah
[13:31:12] <cradek> yeah you need this, then!
[13:31:55] <mozmck> Julian's comment on the dev list: As that the tp's period is also 1ms, and the cubic interpolation is calculated every 1ms, so can i conclude that interpolationRate = 1?? If that's true, is it meaningless that we do the cubic interpolation?"
[13:32:08] <andypugh> I think that part of the puzzle is waiting for axes which share the same homing sequence to finish the current step before moving on to the next step, but I also suspect that not every state needs to wait, and that some really shouldn’t wait. Hard thought is needed.
[13:32:24] <mozmck> It looks to me that Julian is correct?
[13:32:31] <cradek> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/synchronized-homing
[13:32:40] <andypugh> I thought that he might be correct.
[13:32:42] <cradek> andypugh: you sure could be right
[13:32:54] <seb_kuzminsky> the docs builder is back & working now I think
[13:33:12] <cradek> mozmck: it's sure possible the interpolator doesn't do anything now
[13:33:27] <mozmck> It's interesting because the points are all gotten from the interpolator.
[13:33:37] <seb_kuzminsky> it now cleans up after itself, if you remove a document, it will be removed from wlo/docs/$BRANCH too (it used to be left behind forever)
[13:33:40] <cradek> as someone said, it's there because old machines used to have trouble running kins at the servo cycle (which may be more true again in the future, sadly)
[13:34:33] <andypugh> As far as I could see, it isn’t actually possible to set the traj rate.
[13:34:58] <mozmck> There is a cycle time setting in the ini for TRAJ
[13:35:01] <cradek> sure could be
[13:35:07] <mozmck> but I haven't traced that down.
[13:35:20] <cradek> 10 years ago it wasn't necessary anymore, and we all though computers were getting faster
[13:35:40] <andypugh> (I didn’t find a place that actually writes from [TRAJ]INI to the traj rate variable, but I was looking in gitweb.
[13:35:51] <cradek> mozmck: I think I looked recently and that [TRAJ]CYCLE_TIME is not ever read
[13:36:01] <mozmck> Ah, I see.
[13:36:11] <mozmck> There are a number of variables like that.
[13:36:16] <andypugh> It is readm but only used if it less than zero as a special flag, IIRC
[13:36:45] <cradek> huh weird
[13:37:03] <mozmck> I doubt it would be hard to separate the traj cycle time back out, but I wonder what it would do to the new TP?
[13:37:12] <cradek> cradek> I don't even see [TRAJ]CYCLE_TIME being read anywhere
[13:37:13] <cradek> cradek> [DISPLAY]CYCLE_TIME, [TASK]CYCLE_TIME, [EMCIO]CYCLE_TIME are all read
[13:37:45] <cradek> mozmck: yeah if we need it we could surely have it again
[13:37:54] <cradek> is this important to someone, or just academic?
[13:38:10] <mozmck> academic for me, but Julian on the dev list was asking about it.
[13:38:37] <andypugh> Sounds like we might be able to save on an expensive FP operation
[13:39:28] <mozmck> Yeah, I was just thinking that it could shave some time off to not call the interpolater for now
[13:39:52] <mozmck> Only call it if the traj time is less than the servo time or something.
[13:59:15] <jepler> without real world data to show it would help to eliminate the code for trivial machines, I'd leave it in in case nontrivial machines turn out to need it back
[13:59:29] <jepler> otoh you might be better off implementing the interpolator in hal in this century
[14:12:52] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 d23091e 06linuxcnc 10docs/src/Submakefile docs: verify the links in the French Gcode Quick Reference * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d23091e
[14:12:52] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 1f0f3bf 06linuxcnc 10docs/html/gcode_fr.html docs: fix M70-M73 links in French Gcode Quick Reference * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1f0f3bf
[14:14:19] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 5b28c2a 06linuxcnc 10debian/changelog 10docs/src/Submakefile 03docs/src/code/contributing-to-linuxcnc.txt 10src/emc/task/emctaskmain.cc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5b28c2a
[14:15:08] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 5ab82f9 06linuxcnc 10debian/changelog 10docs/src/Submakefile 10src/emc/task/emctaskmain.cc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5ab82f9
[14:18:39] <mozmck> Oh, maybe my joint_data->disable pin does work now that I fixed a bug.
[14:23:48] <cradek> either you're smarter than me, or you've missed something, or both :-)
[14:24:01] <cradek> I'd love to see a branch or patch
[14:38:01] <micges> patch for adding option to disable cubics is probably few lines
[14:38:35] <micges> then we can compare results on both systems
[14:41:13] <micges> only thing I saw is that cubic interpolation delays output command position to hal about 3ms after tp starts vector
[14:41:18] <micges> mozmck: ^
[14:42:23] <mozmck> 3ms is a long time
[14:43:32] <micges> noticeable on uber fast machines
[14:43:37] <mozmck> do you mean 3us (microsecond)?
[14:43:49] <micges> not 3ms, 3 servo cycles
[14:44:05] <mozmck> ok, which is normally 3ms
[14:44:11] <micges> yep
[14:44:12] <jepler> what is delayed 3 servo cycles related to what?
[14:44:25] <jepler> commanded motor position vs .. ?
[14:44:57] <micges> tp position fills up cubic in 3 cycles and after that cubics spit out positon to hal
[14:46:41] <mozmck> hmm, maybe that is because there is a 4 point queue?
[14:46:49] <micges> I've spot it when fighting with scurve tp
[14:46:59] <micges> yes that's it
[14:47:50] <micges> otoh path after cubics is very smooth even if tp is crazy
[14:47:57] <jepler> but considering that it's probably 100ms from pressing "run" to the machine moving, what does 3ms matter?
[14:48:15] <jepler> if it's 3ms shift between motion and something else happening in realtime it is more important
[14:48:27] <jepler> if it's just 3ms later, but everything's still coordinated, I'm not sure it's a big deal
[14:49:16] <mozmck> It would seem that it would cause a 3-cycle shift between tp and motion anyhow - but I haven't dug that deep yet.
[14:50:02] <micges> hard to tell, need more data
[14:53:56] <jepler> if you have a patch to disable it in hand, it might be interesting what would happen with spindle synch'd motion
[14:54:41] <jepler> I can see how a 3ms phase shift there could have an actual effect
[14:57:07] <micges> jepler:
http://pastebin.ca/3248167
[15:01:41] <jepler> 3 out of 3 hunks FAILED -- saving rejects to file src/emc/motion/control.c.rej
[15:01:58] <jepler> did pastebin mangle it? I'm on some recent master branch.
[15:02:57] <micges> let me check
[15:03:14] <jepler> maybe that's a patch for JA?
[15:03:49] <mozmck> I bet it is. It's about line 1249 of control.c in 2.7
[15:04:43] <micges> jepler: yes, sorry, it's for ja4
[15:05:20] <jepler> https://emergent.unpythonic.net/files/sandbox/0001-WIP-eliminate-cubic-interpolator.patch
[15:06:51] <micges> yep that's it
[15:06:57] <jepler> https://emergent.unpythonic.net/files/sandbox/zacc-lathe-interp.png https://emergent.unpythonic.net/files/sandbox/zacc-lathe-nointerp.png
[15:07:08] <jepler> here are two traces of sim/axis/lathe.ini running threading.ngc
[15:07:12] <jepler> may be different passes in the thread
[15:07:51] <jepler> I thought maybe the "zacc" trace would be better if 3ms lag from spindle to motion was eliminated, but it's about the same
[15:08:38] <jepler> the -nointerp iteration I happened to capture has a higher frequency, but from thread to thread the exact shape does vary
[15:09:35] <mozmck> interesting.
[15:11:10] <jepler> it doesn't look good either way, Z's acceleration changing by +-15in/s^2 at around 100Hz
[15:12:24] <seb_kuzminsky> i'd expect it to be smoother, especially in sim
[15:12:34] <jepler> cradek: do you know what a zacc plot looks like on a well-tuned lathe?
[15:12:36] <jepler> during threading
[15:15:15] <cradek> umm
[15:15:18] <cradek> not like that?
[15:15:52] <jepler> then we should fix sim/axis/lathe
[15:16:06] <cradek> is this 2.7?
[15:16:38] <jepler> recent master
[15:16:41] <jepler> afk
[15:24:22] <mozmck> jepler: someone reported a message with this note: "I see now that reply to other post is disable. Why? Whit old forum I can reply freely. regards Giorgio"
[15:24:48] <mozmck> Not sure what that means...
[15:26:44] <linuxcnc-build> build #1965 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1965 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[15:27:06] <linuxcnc-build> build #1284 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1284 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[15:28:40] <linuxcnc-build> build #241 of 1503.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1503.rip-jessie-rtpreempt-amd64/builds/241 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[15:28:47] <linuxcnc-build> build #241 of 1501.rip-jessie-rtpreempt-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1501.rip-jessie-rtpreempt-i386/builds/241 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[15:28:49] <seb_kuzminsky> well shit that sucks
[15:29:40] <seb_kuzminsky> oh, no, nevermind, that's fine
[15:32:35] <skunkworks> jepler: are you setting the f word to 0 before the threading? (I don't think that bug has been fixed) also what happens if you change the ARC_BLEND_RAMP_FREQ = 20 in the traj section to 1000?
[15:33:20] <cradek> !?
[15:34:01] <skunkworks> it actually defaults to 100 - so I was wondering if that is effecting the plot
[15:34:11] <linuxcnc-build> build #1802 of 1405.rip-wheezy-armhf is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1802 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[15:34:22] <skunkworks> cradek: I think it only effected machines with very low acceleration.
[15:34:34] <cradek> http://sourceforge.net/p/emc/bugs/438/
[15:35:17] <skunkworks> afk
[15:35:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 49b4b8f 06linuxcnc 10tests/motion-logger/mountaindew/expected.motion-logger tests: update motion-logger test with new 2.7 init sequence * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=49b4b8f
[15:38:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 0ac9918 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0ac9918
[15:41:55] <jepler> skunksleep: commanding F0 didn't make much difference
[15:45:53] <cradek> jepler: this makes me think ssm probably worked at f7f7f82:
http://sourceforge.net/p/emc/bugs/420/
[15:50:03] <jepler> cradek: similar problem there, plus a glitch at the start of motion
[15:50:12] <cradek> hmm
[15:50:15] <cradek> does 2.6 work?
[15:51:27] <linuxcnc-build> build #3614 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3614 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[15:52:22] <jepler> cradek: the magnitude of the Zacc changes are 1/3 as much in 2.6.
[15:52:46] <cradek> but it still oscillates?
[15:53:28] <jepler> isn't Zacc always going to be changing a little bit?
[15:53:30] <cradek> maybe there is something weird with the sim config. 2.6 threading is smooth on my real lathe.
[15:53:43] <cradek> sure, I suppose so
[15:55:42] <linuxcnc-build> build #3613 of 1300.rip-precise-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3613 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[15:56:22] <seb_kuzminsky> it would be hard to detect oscillation in Zpos around Zcommand, if the Zacc oscillations are of high frequency
[15:56:53] <seb_kuzminsky> i trust halscope more than i trust cradek's ear in this situation
[15:56:57] <jepler> it's not like the axis is reversing or anything
[15:58:04] <linuxcnc-build> build #3615 of 1306.rip-precise-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3615 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[15:58:14] <jepler> mozmck: umm just read back to your message about the forum. I don't believe that replying to posts is disabled, except if you are not logged in.
[15:59:49] <jepler> .. I just logged in as my non-admin user, and the first thread I looked at has a working reply button
[15:59:56] <jepler> the button background is grey, that might confuse some person in the world
[16:00:18] <linuxcnc-build> build #2822 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2822 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[16:01:49] <andypugh> Maybe he hasn’t noticed that he is not logged in?
[16:02:20] <mozmck> He was able to "report to moderator" apparently.
[16:03:13] <jepler> (yeah I wish it didn't say "The administrator has disabled public write access." to guests)
[16:03:45] <linuxcnc-build> build #1774 of 1403.rip-wheezy-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1774 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[16:03:50] <andypugh> Ask for a screenshot?
[16:04:19] <mozmck> The email gives a user name but no other contact information. Did you get that email andy?
[16:04:28] <linuxcnc-build> build #1773 of 1400.rip-wheezy-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1773 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[16:04:37] <jepler> you should be able to get the e-mail address in the /administrator/ pages
[16:04:51] <mozmck> I don't think I have access there.
[16:05:49] <mozmck> user name is k-1
[16:06:11] <mozmck> that reported the post.
[16:06:56] <jepler> I can increase your access level to super user if you want
[16:08:16] <andypugh> k-1 has been posting a lot. Sometimes I understand the questions. Often I don’t.
[16:09:54] <mozmck> jepler: that would be nice
[16:10:37] <jepler> mozmck: now can you log in at /administrator/ ? I am not clear on the difference between "administrator" and "super user"
[16:10:44] <jepler> I only made you "administrator" so far
[16:11:12] <mozmck> Looks like I can now - thanks!
[16:11:32] <jepler> ok, so you could get this user's e-mail now by clicking "manage" under "users", then enter the name in the obvious spot?
[16:11:35] <linuxcnc-build> build #241 of 1502.rip-jessie-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/241 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[16:12:02] <mozmck> jepler - yes.
[16:12:10] <jepler> OK, I'll leave you at "administrator" access then
[16:12:30] <jepler> afk again
[16:13:40] <linuxcnc-build> build #3614 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3614 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[16:15:22] <linuxcnc-build> build #241 of 1500.rip-jessie-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/241 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[16:16:51] <linuxcnc-build> build #1438 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1438 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[16:29:20] <linuxcnc-build> build #3617 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3617 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[16:29:20] <linuxcnc-build> build #3627 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3627 blamelist: John Morris <john@zultron.com>, Sebastian Kuzminsky <seb@highlab.com>
[17:31:38] <seb_kuzminsky> there's some kind of caching happening on dreamhost now
[17:32:07] <seb_kuzminsky> the docs that my browser retrieves are not the docs in the www.linuxcnc.org directory, the ones i get are older
[20:52:12] <skunkworks> zlog
[21:09:44] <jepler> seb_kuzminsky: that is odd
[21:10:26] <jepler> did you figure out why yet?
[21:10:45] <jepler> I notice that in the backup, docs was a symlink to stage-docs
[21:10:55] <jepler> but now it's just a directory
[21:19:29] <jepler> seb_kuzminsky: somehow, it serves the files from stage-docs still
[21:19:30] <jepler> as docs/
[21:19:37] <jepler> even though it's not a symlink
[22:02:16] <seb_kuzminsky> jepler: i did not figure it out yet
[22:12:46] <jepler> i have a vague memory that this is a thing configurable in the panel, that long long ago the docs were actually served from ~jepler on dreamhost...
[22:12:59] <jepler> but we can't look at the panel, of course
[22:16:01] <mozmck> can SWP give others access to the panel?
[22:17:06] <jepler> mozmck: I asked him about this and he said
[22:17:06] <jepler> 18:45:56 <SWPLinux> I think there are weirdnesses with the way DH gives access to accounts
[22:17:16] <jepler> 18:46:35 <SWPLinux> something where accounts created later can't access accounts that were created earlier (ie, where the content lives ...)
[22:17:27] <mozmck> That's true
[22:17:53] <mozmck> So if he has other things hosted there he may not want to do that.
[22:17:56] <jepler> right
[22:18:04] <jepler> apparently alex_joni has an account that *can* access the linuxcnc.org stuff
[22:18:20] <jepler> so when he comes back, I hope he will make sure others among us have the login credentials
[22:18:36] <jepler> but he's not around very often unfortunately
[22:18:38] <mozmck> I think though that he can add people to the account and give them access to only one site.
[22:19:16] <mozmck> This is different than adding users, and I may not understand it all correctly.
[22:19:23] <jepler> I don't know enough about how DH works, that's for sure
[22:19:47] <jepler> it's a thing to try to figure out when not in crisis mode WRT the website(s), which I think we are emerging from now with the switch to jekyll
[22:19:56] <jepler> but now it's my bedtime
[22:20:21] <seb_kuzminsky> fix'd it
[22:20:23] <mozmck> yes
[22:20:45] <seb_kuzminsky> here was a symlink named "docs", pointing at ~emcboard/stage-docs
[22:21:02] <seb_kuzminsky> i changed it to point to www.linuxcnc.org/docs instead, because that's where the buildbot rsyncs the docs
[22:21:07] <seb_kuzminsky> seems fine now
[22:22:14] <Tom_itx> how was the 1st new website day received?
[22:23:57] <seb_kuzminsky> Tom_itx: pretty quiet, which i guess is good
[22:24:17] <seb_kuzminsky> i accidentally broke the automatic updating of our docs, but we just fixed it
[22:24:33] <seb_kuzminsky> so as of now there are 0 known problems with the new website, yay
[22:26:15] <mozmck> nice!
