Back
[00:01:30] <seb_kuzminsky> bye folks
[00:22:56] <cradek> jepler: maybe it is emctaskmain.cc:589
[02:41:05] <CIA-2> EMC: 03cradek 07v2.4_branch * rdc4b4af8cadf 10/src/emc/iotask/ioControl.cc: set diameter to zero when unloading a tool
[02:47:36] <CIA-2> EMC: 03jepler 07v2.4_branch * rf84ded966359 10/src/emc/task/emctaskmain.cc: Fix RFL on line that does not specify all axis words
[02:47:37] <CIA-2> EMC: 03jepler 07v2.4_branch * r1230d3db3167 10/src/emc/task/emctaskmain.cc: clear interpreter list on error
[02:47:37] <CIA-2> EMC: 03jepler 07v2.4_branch * r68f136add75c 10/src/emc/rs274ngc/gcodemodule.cc: these parameters are now pockets, not tools
[02:47:38] <CIA-2> EMC: 03jepler 07v2.4_branch * rd8df3baf4783 10/src/emc/rs274ngc/rs274ngc_pre.cc: make sure we have the right tool table after a tool change
[02:47:41] <CIA-2> EMC: 03jepler 07v2.4_branch * r183b36b4ace7 10/ (2 files in 2 dirs): fix preview of cutter comp
[02:47:41] <CIA-2> EMC: 03jepler 07v2.4_branch * rf5d2beb90623 10/src/emc/usr_intf/axis/scripts/axis.py: redraw the preview when the characteristics of the tool change
[02:47:42] <CIA-2> EMC: 03jepler 07v2.4_branch * r2072574d3554 10/lib/python/rs274/glcanon.py: make (AXIS,stop) take effect immediately
[02:53:17] <CIA-2> EMC: 03jepler 07master * r4959c8d45957 10/src/configure.in: let c/c++ know the required kernel version
[02:53:18] <CIA-2> EMC: 03jepler 07master * r2c5ed60c481b 10/src/hal/halmodule.cc: let python know the required kernel version
[02:53:19] <CIA-2> EMC: 03jepler 07master * rf06bcc026070 10/src/hal/drivers/probe_parport.c: fix naming conflicts with parport_pc
[02:53:20] <CIA-2> EMC: 03jepler 07master * r2c7e6d1a08fb 10/src/hal/halmodule.cc: Fix sim build failure introduced in 2c5ed60c481b
[02:53:21] <CIA-2> EMC: 03jepler 07master * rd6aa1bf14c27 10/docs/src/hal/rtcomps.lyx: fix typo
[02:53:25] <CIA-2> EMC: 03jepler 07master * rc21d6e314fed 10/docs/src/config/stepconf.lyx: markup fixes and add info on E-Stop
[02:53:25] <CIA-2> EMC: 03jepler 07master * rf394f6c259e4 10/src/emc/usr_intf/pncconf/pncconf.py: Fix some conditional checks / spelling typos
[02:53:26] <CIA-2> EMC: 03jepler 07master * r84b4ba051c84 10/src/emc/usr_intf/pncconf/pncconf.py: fix tests to tell you when they wont work without rt
[02:53:26] <CIA-2> EMC: 03jepler 07master * r93eb9a2d6d14 10/src/hal/utils/halcmd.c: halcmd: show errno for failed exec
[02:53:27] <CIA-2> EMC: 03jepler 07master * r46588e0ae365 10/src/hal/drivers/hal_parport.c: Fix inverted test for parport TRISTATE mode
[02:53:28] <CIA-2> EMC: 03jepler 07master * r44d5ac25ce72 10/configs/smithy/ (15 files): Add files to support new 622 versions, change 1240 machine velocities, and lower spindle speed PWM output to 100Hz
[02:53:29] <CIA-2> EMC: 03jepler 07master * r4b4a86797513 10/configs/smithy/ (11 files): Changed eztrol plugin library version numbers in anticipation of the 2.3.5 release.
[02:53:30] <CIA-2> EMC: 03jepler 07master * r61dff8e1d922 10/configs/smithy/924.ini: Fixed two typos in 924.ini.
[02:53:31] <CIA-2> EMC: 03jepler 07master * r495f5af080f5 10/src/emc/rs274ngc/interp_find.cc: make this error message less mysterious
[02:53:32] <CIA-2> EMC: 03jepler 07master * rdc4b4af8cadf 10/src/emc/iotask/ioControl.cc: set diameter to zero when unloading a tool
[02:53:33] <CIA-2> EMC: 03jepler 07master * rf84ded966359 10/src/emc/task/emctaskmain.cc: Fix RFL on line that does not specify all axis words
[02:53:34] <CIA-2> EMC: 03jepler 07master * r1230d3db3167 10/src/emc/task/emctaskmain.cc: clear interpreter list on error
[02:53:36] <CIA-2> EMC: 03jepler 07master * r68f136add75c 10/src/emc/rs274ngc/gcodemodule.cc: these parameters are now pockets, not tools
[02:53:39] <cradek> wheeeee
[02:53:41] <CIA-2> EMC: 03jepler 07master * rd8df3baf4783 10/src/emc/rs274ngc/rs274ngc_pre.cc: make sure we have the right tool table after a tool change
[02:53:42] <jepler> oh my goodness!
[02:53:42] <CIA-2> EMC: 03jepler 07master * r183b36b4ace7 10/ (2 files in 2 dirs): fix preview of cutter comp
[02:53:44] <CIA-2> EMC: 03jepler 07master * rf5d2beb90623 10/src/emc/usr_intf/axis/scripts/axis.py: redraw the preview when the characteristics of the tool change
[02:53:48] <CIA-2> EMC: 03jepler 07master * r2072574d3554 10/lib/python/rs274/glcanon.py: make (AXIS,stop) take effect immediately
[02:53:51] <CIA-2> EMC: 03jepler 07master * r58ed03bc0c49 10/src/emc/usr_intf/axis/scripts/image-to-gcode.py: Work around a numarray slicing bug (SF#2947390)
[02:53:58] <CIA-2> EMC: 03jepler 07master * r11cf6cf768f5 10/ (14 files in 10 dirs): Merge commit 'origin/v2.4_branch'
[02:54:14] <jepler> ^^ I could have spent my whole evening cherry-picking these, but instead it took just seconds.
[03:36:34] <cradek> I wonder if mshaver meant to put "Changed eztrol plugin library version numbers in anticipation of the 2.3.5 release" on master...
[03:37:00] <cradek> I suppose it can't hurt
[04:17:12] <cradek> poor buildbot...
[04:17:15] <CIA-2> EMC: 03cradek 07master * rc2fa3bf7ca66 10/src/emc/rs274ngc/interp_internal.cc: fix silly warning
[04:17:15] <CIA-2> EMC: 03cradek 07master * rfc7084e1e5b9 10/src/emc/rs274ngc/interp_internal.cc: Merge branch 'v2.4_branch'
[04:27:59] <seb_kuzminsky> pshaw, the buildbot's only happy when it's working ;-)
[04:28:26] <cradek> well it sure is tonight
[04:32:05] <cradek> I'm feeling good about 2.4 now. we fixed a lot of things tonight that were a little goofy
[04:33:41] <seb_kuzminsky> are you and jeff having a bug squash party?
[04:33:53] <cradek> we did, but it's over now
[04:33:58] <cradek> it was really productive
[04:34:06] <seb_kuzminsky> yeah, lots of commits
[13:10:24] <micges_work> hi alex_joni
[13:10:32] <micges_work> what's up?
[13:11:29] <alex_joni> lots of work
[13:11:37] <alex_joni> end of the week sprint
[13:12:20] <micges_work> I see
[14:50:20] <micges_work> cradek: hi
[14:51:56] <cradek> hi
[16:00:13] <seb_kuzminsky> "git describe" doesnt do what the buildbot wants :-(
[16:00:36] <seb_kuzminsky> whenever we merge v2.4_branch into master, git-describe in master can see the tags from the 2.4 branch
[16:00:46] <seb_kuzminsky> this messes up the package version numbers:
http://emc2-buildbot.colorado.edu/~buildmaster/dists/hardy/master-rt/binary-i386/
[16:04:59] <seb_kuzminsky> "git describe --match" can be used to restrict what describe can use, i'll tweak debian/update-dch-from-git to look at the branch and map that to tag match globs
[16:12:36] <cradek> seb_kuzminsky: I couldn't figure out why my build failed last night - was it just a fluke?
[16:13:02] <seb_kuzminsky> cradek: yes
[16:13:12] <cradek> ok good. I didn't think I could have messed up that change.
[16:13:15] <seb_kuzminsky> i meant to send an email to the commit list about it, but maybe i spaced it
[16:14:02] <seb_kuzminsky> i've been having network trouble between the buildslaves and the buildmaster, i thought i had fixed it a few weeks ago but i guess not
[16:14:23] <seb_kuzminsky> the slaves are KVM virtual machines on a Karmic box sitting next to the buildmaster
[16:14:29] <seb_kuzminsky> the master is a karmic box
[16:15:32] <seb_kuzminsky> sometimes the slaves access to the interwebs stops, then any buildstep that needs to use the net (for checking out git or downloading or uploading tarballs or dscs or debs) stops & times out & looks like a failure to the buildmaster
[16:19:34] <CIA-2> EMC: 03seb 07master * radfaf4e544c5 10/debian/update-dch-from-git: fix debian package version numbers on the buildbot
[16:22:05] <seb_kuzminsky> i removed all the bogusly numbered master packages that thought they were 2.4s
[16:23:33] <seb_kuzminsky> is the prefered work flow to cherry-pick that commit from master to v2.4_branch now?
[16:25:33] <seb_kuzminsky> grump, one more place with little magic bits information that have to be changed when we make a release branch off master :-(
[16:25:39] <seb_kuzminsky> brb
[16:33:14] <jepler> seb_kuzminsky: if you make a change on master that you later decide needs to be on 2.4, the only thing to be done is cherry-pick.
[16:33:41] <jepler> hm, I thought I'd satisfied myself that the "best tag" heuristic of git-describe worked right when merging v2.4 into master, but I see that it doesn't
[16:39:10] <jepler> seb_kuzminsky: if you make a change on master that you later decide needs to be on 2.4, the only thing to be done is cherry-pick.
[16:39:13] <jepler> hm, I thought I'd satisfied myself that the "best tag" heuristic of git-describe worked right when merging v2.4 into master, but I see that it doesn't
[16:39:38] <seb_kuzminsky> jepler: ok will do
[16:41:42] <seb_kuzminsky> jepler: i think i should have made the fix on v2.4_branch, then merged that branch into master
[16:41:45] <seb_kuzminsky> is that right?
[16:42:25] <jepler> seb_kuzminsky: if you had made that fix on the v2.4_branch then the next merge of v2.4 -> master would have made the change on master as well
[16:42:44] <jepler> if you know in advance that's what you want, that's the best way to do it
[16:43:13] <jepler> (alternately, if it's not needed on master right away, don't bother with the merge step; I'll do the merge from time to time to get new bugfixes into master)
[16:43:44] <seb_kuzminsky> oic
[16:44:24] <seb_kuzminsky> this time the bug only directly affected master, so that's why i thought to fix it there first (though the bugfix definitely is needed on both)
[16:48:53] <seb_kuzminsky> check this out:
http://emc2-buildbot.colorado.edu/buildbot/builders/lenny-x86-trunkish-realtime-rip/builds/917/steps/git/logs/stdio
[16:49:02] <seb_kuzminsky> the lenny buildslave is stuck in git fetch
[16:50:13] <seb_kuzminsky> there it goes
[16:50:21] <seb_kuzminsky> wonder why it does that...
[16:50:41] <jepler> does it always start with an empty git? it's no surprise that a new clone takes awhile..
[16:50:57] <seb_kuzminsky> no, it's configured to reuse a pristine repo
[16:51:37] <seb_kuzminsky> it's pulls that repo to the specified version, then clones it to a build repo locally for each build
[16:51:49] <aystarik> guys, what means "Zero coordinate system"? On my 2.5 git it sets G54 offsets to all zeroes, rather set relative position to zeroes...
[16:51:54] <cradek> micges 87964 0.0 0.0 21584 0 ?? IWJ - 0:00.00 /usr/local/bin/python2.5 hooks/post-receive
[16:52:02] <cradek> this is stuck sending mail maybe?
[16:52:22] <seb_kuzminsky> hmm
[16:52:23] <cradek> aystarik: yes it's supposed to reset that origin to the machine origin
[16:52:33] <cradek> aystarik: to set the current position to zero, use touch off
[16:53:18] <aystarik> probably the name should be changed to "zero offsets" then?
[16:54:53] <CIA-2> EMC: 03seb 07v2.4_branch * raa74c5431337 10/debian/update-dch-from-git: fix debian package version numbers on the buildbot
[16:55:01] <cradek> I'm not sure what the best wording is, but I agree it is a bit confusing as-is
[16:59:32] <cradek> seb_kuzminsky: I killed whatever that was; things may improve now
[16:59:41] <jepler> "Clear"?
[16:59:50] <micges> cradek: I have machine with dynamically changeable scale on axis Y (rotary)
[16:59:58] <seb_kuzminsky> cradek: ok i'll keep an eye on it
[17:00:18] <aystarik> in Help screen "shift-home" means "zero G54 offset for active axis"
[17:00:36] <micges> each scale change will cause ferror
[17:00:54] <cradek> micges: Y is rotary? what do you mean scale change?
[17:01:09] <micges> yes
[17:01:39] <micges> point is that on my rotary I do that by disable enable machine (F2)
[17:01:46] <jepler> if counts = 1000 and you change scale = 10 to scale = 20 then position changes by 1000/10 - 1000/20 = 50 units
[17:01:52] <jepler> of course you get an ferror
[17:02:37] <micges> jepler: I know why and all of that
[17:02:43] <cradek> I don't understand your machine, but sure, you can't make jumps in position
[17:03:02] <jepler> I should have let you ask your question, sorry.
[17:03:19] <cradek> yeah, I know you knew that :-)
[17:03:29] <micges> question is that: how can I change scale without disableing/enabling machine ?
[17:04:00] <cradek> I still don't know quite what you mean by change scale
[17:04:10] <micges> well
[17:04:23] <micges> I have pipe dia=300mm
[17:05:39] <micges> scale that to get 1mm to be 1mm on perimeter
[17:05:59] <micges> and then put pipe 400mm and scale axis again
[17:06:30] <cradek> you'd have to scale maxvel, maxaccel also
[17:06:46] <micges> that's minor problem
[17:07:08] <micges> I use about 50% of machine vel
[17:07:34] <cradek> this is a strange setup
[17:07:37] <micges> I've done that by sequence disable->change scale->enable
[17:08:18] <cradek> if you want changeable scale, you need to do it before all position interpolating/planning which means putting it in the interpreter
[17:08:21] <micges> but on my new machine I can't disable emc to do that
[17:09:06] <cradek> can you use your rotary as a rotary axis and just generate the gcode accordingly?
[17:09:19] <micges> need preview
[17:09:38] <cradek> I think preview works with rotary
[17:09:51] <cradek> it would preview as cylindrical - not flat
[17:10:57] <cradek> even if you added gcode scaling like we talked about so much yesterday (or day before?) you are still in trouble because you don't want isotropic in this case
[17:11:05] <jepler> there are a number of cases -- thc is another -- where it would be helpful to have a gcode that says position is being changed by some weird external force
[17:11:07] <cradek> I guess I don't know a good answer for you.
[17:13:09] <micges> jepler: agree
[17:14:01] <micges> cradek: thanks, just needed some critical point of view
[17:14:24] <cradek> probing and tool change do this query of the unknown new position
[17:15:01] <jepler> M666 P# Q0 -> gcode gives up control of axis # (X=0, Y=1, ...) M666 P# Q1 -> gcode takes control oaf axis
[17:15:09] <cradek> maybe you could abuse a probing move to do it
[17:15:26] <jepler> when M666 P0 Q0 is in effect, following errors will not occur (just like in machine off)
[17:15:48] <jepler> when M666 P0 Q1 is encountered, the current feedback position is bubbled up throgh all the layers, similar to the end of a probing move
[17:16:08] <jepler> and following error signalling is turned back on
[17:16:21] <jepler> in this case and in the case of thc, we see that we want to do this for a specific axis, not all axes
[17:16:48] <jepler> I don't know what it would mean to do it for non-trivkins machines .. what does it mean for X to be under external control on a SCARA?
[17:17:03] <cradek> that can't really be what you want can it? in probing motion always knows/drives the position. the only problem is resynching the interp afterward
[17:17:06] <jepler> (though Z could sensibly be)
[17:18:10] <cradek> I don't think you ever want to disable ferror sensing if the joint is powered
[17:18:43] <cradek> the copy-fb-to-cmd trick is only appropriate if the joint is unpowered/free
[17:19:22] <jepler> I think that's what THC wants
[17:19:55] <jepler> your THC would have to error if it wasn't successfully controlling position (be in the software estop or amplifier-enable chain)
[17:22:45] <micges> jepler: I like gcode idea
[17:23:37] <micges> but it will not work on servo joint
[17:24:10] <jepler> M666 P1 Q0 / M101 P400 / M666 P1 Q1
[17:24:24] <jepler> (where M101 P# is change-y-scale)
[17:24:30] <jepler> that's how I see my suggestion fitting with your current puzzle
[17:25:01] <micges> ah ok
[17:25:18] <cradek> how would you change cmd and fb together? I don't see how you can change the scale.
[17:26:50] <micges> when you change scale, fb will change so it will be only wanted to change joint internal offset
[17:27:22] <jepler> what? no. you want position to jump. If you're at 1 revolution then you want to be at 300mm or 400mm depending on the pipe that is in the machine.
[17:28:15] <jepler> cradek: when motion does the thing it does for M666 P1 Q1 it copies fb to cmd, then bubbles it the rest of the way up. before that, it's not signalling ferror because of the M666 P1 Q0
[17:28:21] <cradek> but you can't. the best you can do is move to the right place at the next move, just like any offset or rotation change today
[17:28:58] <jepler> (or maybe it's continuously copying, just like in machine off)
[17:29:02] <cradek> one way or another you've got to have a controlled move don't you?
[17:35:10] <micges> ok, beside scale there is velocity problem
[17:36:17] <cradek> I think a better solution is to customize interpreter or canon level to consider radius and translate Y into correct B moves
[17:36:59] <cradek> trying to manipulate all through motion, and fixing joint constraints and soft limits and homing and joint offset and all other problems is a bad approach
[17:43:22] <micges> cradek: thanks, I'll try that approach
[17:43:32] <micges> should be quite easy
[17:44:25] <micges> cradek: one thing, I have problems with THC also like jepler noticed
[17:44:55] <micges> do you have any idea about that?
[17:46:59] <cradek> sorry no, I don't know that problem very well
[17:49:05] <micges> cradek: ok, again many thanks
[17:49:43] <cradek> welcome
[18:12:30] <seb_kuzminsky> hm, looks like the buildbot doesnt know what branch its git checkout is on
[18:19:41] <jepler> yeah, your branch will always look like 'master'
[18:19:41] <jepler> git-fetch git://git.linuxcnc.org/git/emc2.git master
[18:19:55] <jepler> that fetches into the current branch which is initially master
[18:20:32] <seb_kuzminsky> it think it looks like "(no branch)"
[18:20:55] <seb_kuzminsky> there's a "git reset --hard <sha1>" after the fetch
[18:22:00] <jepler> if you're on a branch that moves the tip of the branch to that commit
[18:22:45] <seb_kuzminsky> oh ok
[18:23:05] <jepler> hmmm
[18:23:27] <seb_kuzminsky> the buildmaster knows what branch, it could pass that in to update-dch-from-git as a command-line argument
[18:23:29] <jepler> after 'git init', 'git branch' shows nothing, though 'git status' says 'On branch master'
[18:24:12] <jepler> why'd you choose to do git init + git fetch, instead of git clone?
[18:24:40] <seb_kuzminsky> the buildbot devs chose that, not me, i just use the "Git" buildstep they provide
[18:24:45] <jepler> ah
[18:24:52] <seb_kuzminsky> i'm not sure what their reason was
[18:27:08] <jepler> what version of git on that buildslave?
[18:27:46] <seb_kuzminsky> 1.6.6.1
[18:28:34] <seb_kuzminsky> 1.7.0 is available, do you think that'd help?
[18:28:46] <jepler> 1.6.6.62.g584fe here and I end up on branch 'master'
[18:28:57] <seb_kuzminsky> ok i'll try it
[18:29:05] <jepler> .. for both master and v2.4_branch, so it's no fix
[18:29:08] <seb_kuzminsky> wait, you're on master even if you reset to a commit in 2.4_branch
[18:29:10] <seb_kuzminsky> bummer
[18:29:22] <jepler> http://pastebin.ca/1812163
[18:29:28] <seb_kuzminsky> ok, i'll just tell the buildmaster to tell the update-dch script what branch its on
[18:30:27] <jepler> I think you want buildbot to run: git checkout -b v2.4_branch <sha-id>
[18:30:48] <jepler> or, before running update-dch, you can git checkout -b v2.4_branch
[18:32:20] <jepler> (since you're already at <sha-id>, you just want to call it a certain branch)
[18:37:33] <seb_kuzminsky> is that better than giving update-dch a branch name as an optional argument, and have it pick tags appropriate for that branch without messing with the repo?
[18:38:04] <jepler> maybe what you should give update-dch is the pattern? I dunno..
[18:39:05] <seb_kuzminsky> that would put the branch-to-tag-pattern info in the buildmaster, rather than the update-dch script
[18:39:34] <seb_kuzminsky> http://pastebin.ca/1812170
[18:40:20] <micges> jepler: in sim 9axis config there is: GEOMETRY = XYZBCUVW
[18:40:39] <micges> without A, is it spelling error or intentionally?
[18:42:02] <micges> hi jmkasunich
[18:43:31] <jepler> micges: iirc, I was interested in simulating a 5-axis XYZBC machine with UVW "tool coordinates" kinematics. in otherwords, A is deliberately omitted
[18:43:56] <micges> ah ok
[19:01:47] <CIA-2> EMC: 03seb 07master * rdb5d9bed8dcd 10/debian/update-dch-from-git: let the user specify the branch name
[19:02:13] <micges> cradek: I can't achieve cilindrical preview only this
http://imagebin.ca/view/lrZEGCSG.html
[19:12:08] <jepler> http://emergent.unpy.net/files/sandbox/axis-geometry-cxz.png GEOMETRY=CXZ
[19:12:39] <jepler> put X at 1 so that rotation actually does something (center of rotation is at X=Y=0)
[19:14:00] <jepler> if you want the axes to be X and A then I think you want GEOMETRY=AXZ and set Z=1 so that rotation actually does something.
[19:15:37] <micges> cool it works
[19:15:40] <micges> thx
[19:21:50] <jepler> welcome
[19:54:48] <micges> jepler: very cool preview
http://imagebin.ca/view/MJbg3L.html
[19:55:02] <micges> more better than flat
[19:55:09] <cradek> :-)
[19:55:58] <jepler> I'm not sure I see what the leftmost one is, but that's OK
[19:57:21] <alex_joni> now we need an image2gcode on the cylinder
[19:57:46] <jepler> I just fixed an i2g bug this year. can't it wait for 2012?
[20:06:59] <alex_joni> sure it can
[20:07:23] <alex_joni> next LTS after lucid
[20:15:50] <micges> G93 mode should handle velocity of that machine, and I can make some tests next week :)
[20:27:09] <jepler> oh geez, there'll be another lts to deal with too? maybe 2013 for i2g then
[20:28:16] <micges> jepler: 2011?
[20:31:09] <jepler> (I hope the next lts is called precious platypus)
[21:33:28] <alex_joni> pretty pig?
[21:34:23] <skunkworks_> rowdy rat
[21:34:28] <jepler> portly pachyderm
[21:35:07] <skunkworks_> Hungry hippo.. wait - that is taken.
[21:36:00] <micges> haha
[21:37:56] <alex_joni> https://wiki.ubuntu.com/DevelopmentCodeNames#12.04
[21:39:27] <CIA-2> EMC: 03seb 07v2.4_branch * rd0645c13ed16 10/debian/update-dch-from-git: let the user specify the branch name
[21:40:25] <alex_joni> poetic pitbull
[21:40:54] <alex_joni> or even pimpin' peacock
[21:42:33] <jepler> they can't do "penguin", that's way too easy
[21:59:44] <seb_kuzminsky> three virtual build slaves stuck in "git fetch"
[22:01:15] <seb_kuzminsky> one's doing an actual download of the repo (starting from "git init") so maybe it's using up the git server's outgoing bandwidth?
[22:01:26] <cradek> pretty bad ping times on the last hop - I bet it's just saturated
[22:01:57] <cradek> how long have they been going?
[22:08:59] <seb_kuzminsky> 10-12 minutes to do git fetch for each of them
[22:09:59] <seb_kuzminsky> i'm not sure why buildbot's git sometimes removes & re-fetches the whole repo, and sometimes cleans and fetches an existing repo
[22:10:56] <cradek> as long as it only takes fives of minutes, it doesn't matter much
[22:11:19] <cradek> ping times are back to normal - it must be done.
[22:12:30] <cradek> but yeah, if a bunch of them do it at once, it'll probably take a while for everything to unconstipate
[22:12:41] <cradek> my up speed isn't that great
[22:12:53] <seb_kuzminsky> is the git server in your house?
[22:13:05] <cradek> yes
[22:13:51] <seb_kuzminsky> i wonder if there's such a thing as a caching git proxy
[22:14:06] <seb_kuzminsky> to run on my buildslave virtualization host
[22:14:32] <cradek> I kind of doubt that exists, because git is smart about what it sends in the first place
[22:15:10] <jepler> you can 'git clone --mirror', and then clone/fetch/pull from it instead of from git.linuxcnc.org
[22:15:22] <jepler> I'm not sure how to update a 'clone --mirror', though
[22:16:08] <cradek> seems like fixing it so it doesn't nuke its repository would be better than trying to hack around it
[22:16:14] <cradek> (not that I'm volunteering)
[22:16:57] <cradek> hey, it's after 4 on a friday. why am I here?
[22:17:06] <jepler> hah
[22:17:09] <jepler> I'll follow you out
[22:17:15] <seb_kuzminsky> have a nice weekend guys
[22:17:21] <jepler> see you seb
[22:17:23] <cradek> thanks
[22:17:26] <cradek> we'll be around I'm sure
[22:17:27] <jepler> thanks for wiping up buildbot's messes for us
[22:17:34] <cradek> ditto
[22:17:41] <seb_kuzminsky> sure :-)
[22:19:09] <micges> good night
[22:26:20] <seb_kuzminsky> if git.linuxcnc.org exported the repo via http or https, i could use a regular web proxy. read-only would be fine
[22:27:35] <seb_kuzminsky> that would reduce the buildbot's use of the repo server from 11 fetches to maybe 2 or so, per commit, and the re-downloads into an empty repo would (should) cease being expensive
[22:28:58] <seb_kuzminsky> if we decide it uses too much bandwidth we could do that, until then we can ignore it
[23:19:01] <CIA-2> EMC: 03seb 07v2.4_branch * rdcb184f33e7c 10/debian/rules.in: Call the debhelper scripts in a better order
[23:54:15] <jepler> darn, seb_kuzminsky left. I was just about to tell him I have a BIT file that makes the hostmot2 driver oops during registration!
[23:56:37] <jepler> I think it's because it had no 'ioport' tag
