Back
[08:30:06] <cradek> ETA: 21:48:37 [-33993 secs]
[08:30:08] <cradek> hmm
[08:30:15] <cradek> apparently I made it worse
[08:31:50] <jepler> doh
[08:34:13] * cradek sighs
[08:34:40] <cradek> I figured it would just skip that one...
[08:35:04] <jepler> that's a reasonable guess
[12:02:35] <cradek> jepler: fwiw, you can clone a snapshot to get it mounted normally, and then rsync works
[12:02:42] <cradek> both the clone and destroy of the clone are fast
[12:07:20] <jepler> cradek: aha I'll have to remember that tip
[12:07:42] <jepler> (troll: anybody tried zfs-on-linux with a realtime kernel?)
[12:08:01] <cradek> ugh
[12:20:17] <andypugh> What is the process for merging 2.5 into master?
[12:21:00] <andypugh> I had imagined that it happened on the server, but on reflection I suspect it is more of a big patch that is pushed?
[13:21:23] <ve7it> cradek, Do you know if the linuxcnc site is using Joomla? I notice there is a pretty bad vulnerability that needs patching.
[13:21:52] <ve7it> http://krebsonsecurity.com/2013/08/simple-hack-threatens-oudated-joomla-sites/
[13:22:10] <ve7it> http://www.marketwire.com/press-release/versafe-identifies-significant-joomla-cms-vulnerability-corresponding-spike-phishing-1819933.htm
[13:22:31] <ve7it> http://developer.joomla.org/security/news/563-20130801-core-unauthorised-uploads
[13:23:59] <jepler> andypugh: everything is local until you push it
[13:24:35] <andypugh> Yes we are using Joomla. Yes we get hacked a lot.
[13:24:55] <cradek> andypugh: you mean we used to get hacked a lot until I plugged the persistent hole
[13:25:05] <andypugh> So, what I need to do is merge 2.5 into my master, fix the conflicts then push?
[13:25:19] <cradek> yes
[13:25:37] <jepler> andypugh: well...
[13:25:47] <jepler> andypugh: you presented the case that the fix will be essentially different in master than in v2.5_branch
[13:26:07] <jepler> I proposed a workflow that will let you make a different fix in master and won't cause problems down the road
[13:26:38] <andypugh> Yes. In fact it might be an argument for somebody competent merging but leaving the conflict markers in, then I can immediately submit a patch to sort it out.
[13:26:49] <jepler> no
[13:27:06] <jepler> there is never a valid case for leaving conflict markers in
[13:27:36] <andypugh> I suspect you might have suggested the workflow when I wasn't paying attention. I will read back.
[13:27:54] <jepler> OK, I can also walk you through it again
[13:29:24] <cradek> ve7it: I'm having trouble even figuring out what version we have... this might be something alex has to deal with.
[13:29:28] <cradek> alex_joni: ^^
[13:30:59] <KGB-linuxcnc> 03jthornton 05master 08597ae 06linuxcnc 10docs/ 10(72 files in 12 dirs)
[13:30:59] <KGB-linuxcnc> Docs: add note to untranslated Spanish chapters
[13:30:59] <KGB-linuxcnc> add info for translators on how to get the latest version
[13:30:59] <KGB-linuxcnc> of that chapter before starting a translation.
[13:30:59] <KGB-linuxcnc> Signed-off-by: John Thornton <jthornton@gnipsel.com>
[13:31:15] <KGB-linuxcnc> 03jthornton 05master 2eb0d98 06linuxcnc 10docs/html/gcode.html * Docs: add m61 to quick reference
[13:31:21] <KGB-linuxcnc> 03jepler 05master c9513dd 06linuxcnc * Merge commit '2eb0d983aa4afe3fbd3397a85f38e0b3b1057c21'
[13:32:39] <cradek> that's a weird merge commit message
[13:33:39] <cradek> oh I see what you did
[13:33:44] <cradek> clever
[13:34:00] <jepler> andypugh: the workflow I think will work for your case is:
http://pastebin.com/MuPGqZ6P
[13:35:25] <jepler> this lets you make a different fix in master branch but ensures that when all is said and done, v2.5_branch is merged into master branch
[13:36:35] <andypugh> OK. I will give it a try.
[13:36:46] <jepler> if you are unsure before pushing please ask
[13:38:15] <andypugh> --dry-run will probably help my confidence
[13:43:36] <jepler> "Fight to the death... or die trying" -- video game tagline
[14:24:22] <andypugh> Hmm, unfortunately the merge does not complete without conflicts.
[14:24:41] <andypugh> Auto-merging configs/sim/axis/check_constraints.hal
[14:24:41] <andypugh> Automatic merge failed; fix conflicts and then commit the result.
[14:30:39] <andypugh> OK, no worries, it merged after a clean
[15:46:21] <andypugh> jepler: Before I push, does this look right?
http://pastebin.com/31REsFG4
[15:47:36] <jepler> that looks weird, because I expect another commit which is the one that fixes resolvers in the right way for master branch
[15:47:49] <andypugh> Yes, I just noticed that absence
[15:48:21] <jepler> $ git merge origin/master
[15:48:21] <jepler> # This merge should complete without conflicts
[15:48:21] <jepler> # Fix resolver for master; test; commit
[15:48:22] <jepler> $ git checkout master
[15:48:30] <jepler> did you fix, test, commit?
[15:51:00] <andypugh> Gah! I was in completely the wrong terminal window looking at completely the wrong PC.
[16:07:21] <andypugh> http://pastebin.com/qBQ2SJ9k
[16:07:27] <andypugh> does that look better?
[16:08:12] <andypugh> (You know where I said that a "clean" fixed it? That was when I started working in the wrong teminal. I was editing the right file, just gitting on the wrong PC..
[16:12:40] <andypugh> jepler: I am not convinced that line 53 belongs in a pushed commit?
[16:16:35] <jepler> > Merge remote branch 'origin/master' into hm2-resolver-fix-for-master
[16:16:44] <jepler> that is expected
[16:16:50] <jepler> I think that what you have is right in terms of git
[16:17:04] <jepler> I haven't studied the code enough to know if it's right :-P
[16:18:04] <andypugh> Ah, that part I am confident in. I have tested it.
[16:19:59] <andypugh> I am not _entirely_ sure how it will cope after more than 32-bits-worth of complete revolutions if there is no index in the interim. But that's a long time. 59 hours @ 20,000 rpm.
[16:20:39] <andypugh> I can't imagine that limit messing up a rigid-tapping operation.
[16:21:18] <KGB-linuxcnc> 03andy 05master 6cae47a 06linuxcnc 10src/hal/drivers/mesa-hostmot2/resolver.c
[16:21:19] <KGB-linuxcnc> Use a less bogus way to detect "index" with Resolvers.
[16:21:19] <KGB-linuxcnc> For example, one that only happens once per rev.
[16:21:19] <KGB-linuxcnc> And fix an off-by-one error in the reverse direction too.
[16:21:20] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[16:21:36] <KGB-linuxcnc> 03andy 05master c3d350d 06linuxcnc 10src/hal/drivers/mesa-hostmot2/resolver.c * Revert "Use a less bogus way to detect "index" with Resolvers."
[16:21:43] <KGB-linuxcnc> 03andy 05master 91efbf5 06linuxcnc * Merge remote branch 'origin/master' into hm2-resolver-fix-for-master
[16:21:49] <KGB-linuxcnc> 03andy 05master 492421b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/resolver.c
[16:21:52] <KGB-linuxcnc> Improve the handling of multi-turn resolvers in the hm2 driver.
[16:21:55] <KGB-linuxcnc> You now get the same zero registered as an index in both directions,
[16:21:58] <KGB-linuxcnc> and you need to pass the zero in the same direction the requisite number of times.
[16:22:00] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[16:26:31] <jepler> andypugh: thanks
[17:21:39] <andypugh> There is a slight bug in the 5-axis config. The INI needs to have a home-sequence entry for the absent joints, or you get spurious "joints must be homed" messages switching to World Mode.
[21:52:44] <cradek> linuxcnc-build: force build --branch=v2.5_branch checkin
[21:52:45] <linuxcnc-build> build forced [ETA 1h35m52s]
[21:52:45] <linuxcnc-build> I'll give a shout when the build finishes
[22:41:30] <memleak> KimK / KimK_3 did you get the 3.4.55 kernel to boot yet?
[22:42:23] <memleak> i can write you up a grub.cfg file from scratch in a few seconds if you can send me your current file
[23:09:55] <linuxcnc-build> Hey! build checkin #1273 is complete: Success [3build successful]
[23:09:55] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1273