Back
[02:13:00] <KimK> mozmck: I second cmorley 's comment and question. Especially after I had to install FreeCAD manually (using lather-rinse-repeat method) on Debian Wheezy due to the no-PPA situation. Can you do a write-up of how you got LinuxCNC and Mint together? I have been using Cinnamon, but would be willing to switch to XFCE.
[07:32:20] <mozmck> cmorley: KimK: I am using ethernet hardware, so I only need the preempt-rt kernel, and don't have the time or incentive right now to look at doing an RTAI kernel for ubuntu 14.04/LinuxMint17
[07:33:48] <mozmck> That said, if anyone wants the kernel packages I have, I'd be glad to put them somewhere. I think I have 32 and 64 bit, and the performance seems about the same between them.
[08:19:00] <jthornton> the error that Jon Elson pointed out should it be corrected in 2.6? grep shows the error twice once in rtcomps.txt and once in GM.txt
[08:20:18] <mozmck> Aren't the ethernet cards the only ones that work with preempt-rt?
[08:24:46] <cradek> I think the pci and epp stuff works too.
[08:25:26] <mozmck> hmm, I thought pcw had said only the ethernet cards did.
[08:27:55] <cradek> the ethernets work only on preemppt-rt
[08:28:03] <cradek> bet you heard backwards
[08:32:12] <cradek> I think pluto might even work...
[08:32:59] <cradek> preempt seems good enough for everything but software stepgen
[08:38:51] <mozmck> Well, it could very well be that I heard it backwards! I was thinking the PCI drivers used RTAI? Or do they just use the RTAPI interface?
[09:17:09] <seb_kuzminsky> jthornton: if the bug is present in 2.6, then yes please fix it there and merge up
[09:22:09] <mozmck> seb_kuzminsky: if you get time can you look at my debian/ changes for 2.7?
[09:54:19] <KGB-linuxcnc> 03John Thornton 052.6 6357fad 06linuxcnc 10docs/src/drivers/GM.txt 10docs/src/hal/rtcomps.txt correct pin name * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6357fad
[09:54:23] <jthornton> seb_kuzminsky, what git command merges up?
[09:58:35] <cradek> jthornton: you checkout 2.7; merge 2.6; checkout master; merge 2.7
[09:59:04] <cradek> jthornton: or, if you know the merge is trivial and you're in no hurry, just fix it in 2.6 and the next guy who merges up will get it
[09:59:35] <mozmck> btw, I tried to merge 2.7 into master yesterday and there were conflicts with stepconf. I did not have time to look at them.
[09:59:41] <jthornton> yea it is trivial
[10:00:21] <cradek> hmm then I'd advise jthornton not bother merging until that's fixed up by someone who knows stepconf
[10:30:22] * jthornton takes cradeks advise
[11:07:37] <cradek> go ahead and commit to 2.6, no problem
[11:07:49] <cradek> just let the mergeup wait
[12:12:32] <pcw_home> 64 bit Mint 17.1 /tupperware-PC
[12:12:34] <pcw_home> http://store.hp.com/webapp/wcs/stores/servlet/us/en/pdp/desktops/hp-stream-mini-desktop---200-010-p-k5g59aa-aba--1
[12:12:35] <pcw_home> pretty lousy latency but still works ok with hm2_eth at 1 KHz:
[12:12:37] <pcw_home> http://freeby.mesanet.com/tupperware-preemt-rt3.14.png
[12:12:38] <pcw_home> will see if Preemt-RT 3.18 is better
[12:20:52] <skunkworks> cool
[12:22:26] <skunkworks> pcw_home, tom made me a bit file with the pinouts I wanted.
[12:22:28] <cradek> pcw_home: my sun1888 card has connections to pins 1,14,16,17 coming straight from the main (only) chip and with 4700 ohm pullups. if I was to boldly cut traces on it and add line drivers for those four signals in the hopes that it would make the pluto work, what chip should I use?
[12:22:41] <Roguish> pcw_home: welcome. could you check a post I just put in the forum/driver boards?
[12:22:50] <cradek> Tom's a wizard
[12:23:06] <skunkworks> Yes :)
[12:23:41] <pcw_home> probably just use a 74HCT14 (well 2 in series)
[12:24:32] <cradek> I know schmitt is useful on the far end of the wire - is it also on the sender's end?
[12:24:51] <cradek> yuck, too bad that's 2 packages then
[12:25:03] <pcw_home> Roguish: no, the firmware part is not needed
[12:25:19] <pcw_home> a 74HCT245 then
[12:26:18] <cradek> aha, just hardwire direction out
[12:26:55] <Roguish> That's what I thought. does nothing leaving it in.
[12:27:03] <pcw_home> Schmitt trigger just because of the (slow rise) open drain output
[12:27:17] <pcw_home> bbl
[12:29:56] <cradek> thanks
[12:32:05] <mozmck> cradek: 74HCT541 is what we use, similar to 74HCT245 I believe except a little nicer pinout.
[12:36:21] <tinkerer> cradec: I would suggest to ensure the sun1888 is switching to epp-mode before tinkering on the hardware
[12:37:21] <cradek> tinkerer: it works with the mesa epp board
[12:37:50] <mozmck> oops, no, the 245 is bi-directional and the 541 is not.
[12:37:52] <cradek> mozmck: on which end?
[12:38:00] <cradek> doesn't matter, I only need one direction
[12:38:35] <tinkerer> cradek: yes, the mesa-driver switches different then the pluto-driver
[12:38:52] <mozmck> we use them to buffer parport signals out on our breakout boards.
[12:39:18] <cradek> tinkerer: explain please?
[12:39:33] <mozmck> Sometimes also out close to the drives to clean up the signal again - especially if it's over a longer cable.
[12:40:31] <tinkerer> cradek: the mesa code is much more "sophisticated" ;)
[12:46:06] <tinkerer> cradek: is it possible that you show me your detailed procedures ie. with script or so? (incl. lspci aso.)
[12:46:58] <cradek> halrun -I; loadrt pluto_servo ioaddr=0 epp_wide=0 watchdog=0
[12:47:52] <tinkerer> :D
[12:48:14] <cradek> very simple!
[12:50:20] <tinkerer> yes, too simple. use the ioaddr and ioaddr_hi given from "lspci -vvv"
[12:50:35] <cradek> that does not change the behavior
[12:50:51] <tinkerer> yes i hope :)
[12:51:10] <cradek> I see they both use hal_parport_get() the same way
[12:51:20] <cradek> I have tested your suggestion with many attempts
[12:52:22] <tinkerer> the pluto is programmed in spp-mode
[12:53:02] <cradek> yes
[12:53:03] <tinkerer> then it switches to epp-mode
[12:53:52] <tinkerer> and the error message you got is from switching to epp mode
[12:55:45] <cradek> I understand
[12:56:49] <cradek> yay I found my extra pluto so I can experiment with the new machine without disassembling the lathe
[12:58:08] <cradek> halcmd: loadrt pluto_servo ioaddr=0xec00 ioaddr_hi=0xe880 epp_wide=0 watchdog=0
[12:58:11] <cradek> Error: could not insert module /usr/realtime-3.4-9-rtai-686-pae/modules/linuxcnc/pluto_servo.ko: Input/output error
[12:58:18] <cradek> ...
[12:58:18] <cradek> [ 200.861211] Failed to communicate with pluto-servo board after programming firmware.
[12:58:48] <tinkerer> and lspci -vvv
[12:58:53] <tinkerer> ?
[12:58:58] <cradek> Region 0: I/O ports at ec00 [size=8]
[12:58:58] <cradek> Region 1: I/O ports at e880 [size=8]
[12:59:13] <cradek> [ 9.911880] parport0: PC-style at 0xec00 (0xe880), irq 18 [PCSPP,TRISTATE]
[13:00:59] <tinkerer> yes, [PCSPP,TRISTATE] this means that the kernel does not found the epp functionality
[13:01:23] <cradek> hmm
[13:01:34] <cradek> but the 7i43 works?
[13:02:26] <tinkerer> yes, the hm2 driver uses different strategies
[13:03:11] <tinkerer> is this the full lspci -vvv output?
[13:03:58] <cradek> can you point to the place in the code that is the difference you are thinking of? it looks similar to me. they both write to base_hi+2 to enable epp, although hm2 writes 0x94 instead of 0x80, but I already tried that change in pluto
[13:04:25] <cradek> http://pastie.org/10208524
[13:04:33] <cradek> very bottom
[13:07:12] <cradek> [ 737.260802] PARPORT: linux parport parport0 does not support mode 4.
[13:07:12] <cradek> [ 737.260804] PARPORT: continuing anyway.
[13:07:12] <cradek> [ 737.260808] PARPORT: Using Linux parport parport0 at ioaddr=0xec00:0xe880
[13:07:19] <cradek> you are right that it isn't recognized as epp
[13:07:42] <cradek> however it must work as epp anyway, because 7i43 works
[13:07:49] <cradek> we've seen this with lots of parports
[13:07:59] <cradek> (that's why we made it continue anyway)
[13:08:17] <cradek> ... but continuing SILENTLY unless you turn on INFO messages was probably stupid
[13:11:51] <tinkerer> unload the parport_pc module
[13:13:35] <tinkerer> what do you have in: /etc/modprobe.d/linuxcnc.conf ?
[13:14:34] <cradek> nothing
[13:15:05] <tinkerer> ok, but this in: # Remove the '#' before 'install' below to prevent regular Linux programs
[13:15:05] <tinkerer> # from accessing the parallel port. This also means that the linux
[13:15:05] <tinkerer> # parport number may not be used to identify the port in loadrt hal_parport.
[13:15:05] <tinkerer> install parport_pc /bin/true
[13:15:05] <tinkerer> blacklist lp
[13:15:24] <tinkerer> its mine
[13:17:39] <cradek> what version of linuxcnc are you using?
[13:18:02] <cradek> http://pastie.org/10208539
[13:18:14] <cradek> without parport_pc loaded I get this
[13:18:30] <cradek> we have cooperated with (required) parport_pc for several (?) major versions I thought
[13:19:27] <cradek> it's possible we broke pluto then...?
[13:20:32] <tinkerer> cradek: i've to go out for a bit. cu later
[13:20:38] <tinkerer> 2.6
[13:20:42] <cradek> thanks
[13:20:48] <cradek> that is very hard to understand then
[13:20:57] <cradek> huh
[13:21:46] <tinkerer> 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc i686 GNU/Linux
[13:22:26] <tinkerer> cat /etc/debian_version = 7.8
[13:22:36] <cradek> are you sure parport_pc doesn't get loaded?
[13:22:50] <skunkworks> at what speed would you start to see the preview not following the path?
[13:23:22] <cradek> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Released_2.4.X
[13:23:27] <tinkerer> please later :)
[13:23:28] <cradek> we've cooperated with parport_pc since 2.4.0
[13:23:33] <cradek> ok thanks
[13:33:37] <skunkworks> Hmm - that probably doesn't make sense. Say I am plotting the path from another computer in axis. how do I know the path is following the actual logged information?
[13:34:38] <cradek> well it samples only every so often
[13:34:50] <cradek> those samples will be correct
[13:37:11] <skunkworks> would lowering CYCLE_TIME help?
[13:37:29] <skunkworks> I don't think it is an issue - every thing I change doesn't seem to effect the plotted path..
[13:38:38] <skunkworks> and multible runs would show different outcomes I would think. And they stay pretty darn close to the same
[13:39:55] <cradek> o.after_idle(lambda: thread.start_new_thread(self.logger.start, (.01,)))
[13:40:10] <cradek> it tries to log every .01 sec
[13:41:04] <cradek> I think it's pretty good at doing that, since it's in its own thread, but it's sure not realtime
[13:41:13] <skunkworks> sure
[13:43:03] <skunkworks> heh - and the 5i25 runs fine at 10khz
[13:48:26] <tinkerer> maybe there is some new chunk in parport_pc like:
http://lists.infradead.org/pipermail/linux-parport/2005-August/000335.html :)
[13:49:56] <cradek> but you and I have the same kernel...
[13:50:15] <cradek> I don't understand how you can load pluto_servo on that machine without parport_pc loaded
[13:50:24] <tinkerer> yes and my parport_pc is not loaded
[13:50:26] <cradek> pluto_servo from >= 2.4
[13:50:39] <tinkerer> parport is loaded
[13:50:53] <cradek> oh maybe that's it
[13:50:54] <cradek> let me try
[13:51:14] <tinkerer> lsmod |grep par
[13:51:14] <tinkerer> parport 35208 1 ppdev
[13:53:10] <cradek> yes that allowed it to load
[13:53:14] <cradek> still does not work:
[13:53:16] <cradek> [ 914.875783] Using direct parport at ioaddr=0xec00:0xe880
[13:53:16] <cradek> [ 914.875795] uploading firmware
[13:53:16] <cradek> [ 915.414152] done
[13:53:19] <cradek> [ 915.414174] Failed to communicate with pluto-servo board after programming firmware.
[13:53:20] <tinkerer> :D
[13:53:38] <cradek> programming is successful - LED does turn off
[13:54:56] <cradek> I will reboot with those two modules blacklisted and try again
[13:55:54] <tinkerer> and what shows "lspci -vv -s 02:05.0" now
[13:56:38] <cradek> http://pastie.org/10208594
[13:58:16] <cradek> darn, same problem
[13:58:18] <cradek> [ 133.375083] Using direct parport at ioaddr=0xec00:0xe880
[13:58:19] <cradek> ...
[13:58:22] <cradek> [ 133.912898] Failed to communicate with pluto-servo board after programming firmware.
[14:00:13] <cradek> coffee break!
[14:01:02] <skunkworks> Mmmm coffee...
[14:09:27] <cradek> skunkworks: come on over
[14:09:46] <cradek> have you ever been here? I don't remember.
[14:10:20] <skunkworks> No - not yet
[14:10:36] <cradek> one time I got stuart and seb and ... others? to visit, and we built some stuff. I don't remember exactly how I pulled that off.
[14:10:56] <skunkworks> heh - I don
[14:11:05] <skunkworks> I don't think it takes much arm bending...
[14:11:17] <cradek> sure but usually I end up driving :-)
[14:17:06] <tinkerer> cradek: some new approach!
[14:19:52] <tinkerer> could you read the error-bit immediately after pluto_clear_error_register(); ?
[14:20:15] <tinkerer> maybe its never cleared
[14:34:29] <cradek> do you mean inb(ioaddr+1) & 1
[14:40:12] <tinkerer> yes without the EPP stuff
[14:41:45] <cradek> [ 575.115346] Error bit correctly cleared before EPP attempt; status = 0x80
[14:41:48] <cradek> [ 575.115362] Failed to communicate with pluto-servo board after programming firmware.
[14:42:59] <cradek> http://pastie.org/10208655
[14:43:40] <tinkerer> or now without the parport_pc did you try: loadrt pluto_servo ioaddr=0xec00 ioaddr_hi=<-1 | 0> watchdog=0 epp_wide=0 test_encoder=0
[14:43:55] <tinkerer> yes such similar :)
[14:46:34] <cradek> with ioaddr_hi=-1 : [ 855.701082] Error bit correctly cleared before EPP attempt; status = 0x80
[14:50:40] <cradek> [ 1095.026052] Error bit correctly cleared before EPP attempt; status = 0x80
[14:50:43] <cradek> [ 1095.026067] Error bit set after EPP_ADDR(0); status = 0x81
[14:50:46] <cradek> [ 1095.026071] Error bit set after EPP_DIR_READ(); status = 0x81
[14:50:48] <cradek> [ 1095.026076] Error bit set after EPP_READ(); status = 0x81
[14:51:11] <tinkerer> ok
[14:51:25] <tinkerer> now we know it...
[14:53:21] <cradek> Bit 0, which was reserved in the SPP register set, now becomes the EPP Time-out Bit. This bit will be set when an EPP time-out occurs. This happens when the nWait line is not deasserted within approximately 10uS (depending upon the port) of the IOW or IOR line being asserted.
[15:06:08] <cradek> that 0x80 in status means "Busy"
[15:14:08] <tinkerer> another question
[15:14:24] <tinkerer> about your patch
[15:16:10] <tinkerer> how do you apply this patch? I'm git noob
[15:16:30] <cradek> it's not a git patch, it's just a patch
[15:16:49] <cradek> patch -p1 <savedpatchfile
[15:17:38] <cradek> updated patch:
http://pastie.org/10208729
[15:17:40] <tinkerer> ok, 'cos "diff --git"
[15:18:17] <cradek> I think this 0x80 (busy) is a problem
[15:18:32] <cradek> would be nice to see what yours shows
[15:32:01] <tinkerer> hmmmm
[15:32:41] <tinkerer> where is the log? dmesg logs nothing but pluto works
[15:33:04] <cradek> you should see "Error bit correctly cleared before EPP attempt" in dmesg
[15:39:49] <tinkerer> strange
[15:40:05] <tinkerer> it just logs:
[15:40:09] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.594241] I-pipe: head domain RTAI registered.
[15:40:09] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.594255] RTAI[hal]: compiled with gcc version 4.7.2 (Debian 4.7.2-5) .
[15:40:09] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.594338] RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs DISPATCHED), ISOL_CPUS_MASK: 0).
[15:40:09] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.594346] SYSINFO: CPUs 2, LINUX APIC IRQ 2312, TIM_FREQ 8311820, CLK_FREQ 1861883000, CPU_FREQ 1861883000
[15:40:11] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.594354] RTAI_APIC_TIMER_IPI: RTAI DEFINED 2314, VECTOR 2314; LINUX_APIC_TIMER_IPI: RTAI DEFINED 2312, VECTOR 2312
[15:40:14] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.594361] TIMER NAME: lapic; VARIOUSLY FOUND APIC FREQs: 8311820, 8311820, 8263000
[15:40:17] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.608672] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
[15:40:19] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.608762] , <uses LINUX SYSCALLs>, kstacks pool size = 524288 bytes.
[15:40:24] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.608775] RTAI[sched]: hard timer type/freq = APIC/8311820(Hz); default timing: oneshot; linear timed lists.
[15:40:27] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.608783] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 1861883000 hz.
[15:40:30] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.608789] RTAI[sched]: timer setup = 999 ns, resched latency = 2944 ns.
[15:40:33] <tinkerer> May 26 22:15:14 mimi kernel: [ 8951.631536] RTAI[math]: loaded.
[15:40:55] <cradek> are you sure you compiled and are running the right tree?
[15:47:48] <cradek> parport pin 11 is always low during and after programming
[15:48:00] <tinkerer> this was my 1st question to myself.... and i'm not sure... ;)
[15:50:43] <mozmck> Is there a HAL pin that tells if linuxcnc is estopped?
[15:51:01] <cradek> halui might have that
[15:53:31] <mozmck> halui.estop.is-activated - thanks cradek1
[15:53:45] <mozmck> cradek!
[15:55:30] <cradek> tinkerer: on the working machine, parport pin 11 (/busy) pulses high once for 9us when loading pluto_servo. On the nonworking machine it does not, it stays low
[15:55:55] <cradek> mozmck: if you see cradek2, tell him to come fold the laundry
[15:56:20] <mozmck> will do ;)
[15:56:25] <tinkerer> May 26 22:33:57 mimi kernel: [10072.759447] Error bit correctly cleared before EPP attempt; status = 0xbe
[15:56:56] <cradek> that's a lot more bits than I have
[15:57:01] <cradek> but you do have 0x80 as well
[16:11:19] <cradek> on the working machine, pin 11 signal looks bad. when I pull up pin 11 with 100 ohms to +5, pluto-servo.read.time cuts in half, ~ 12000 to 6000
[16:11:44] <cradek> I think maybe pluto's pin 11 circuitry is a problem
[16:12:55] <cradek> while it is running on the working machine, pin 11 never goes over 2 volts
[16:13:03] <cradek> on the nonworking machine pin 11 never changes from 0 volts
[16:16:46] <tinkerer> 100 ohms is very low
[16:17:14] <tinkerer> you can damage the pluto or/and the parport
[16:19:09] <Tom_itx> mozmck yes there is
[16:19:49] <tinkerer> please tryout the LEDblink
[16:21:24] <tinkerer> just to clarify...
[16:23:20] <cradek> that is a good idea. maybe it is getting enough of a program to turn off the led, but the program is wrong
[16:23:28] <cradek> I don't know what exactly turns off the led
[16:23:34] <cradek> but I have to go for now
[16:23:36] <cradek> I will try it
[16:23:40] <cradek> thanks again tinkerer
[16:24:42] <tinkerer> ok
[16:24:42] <tinkerer> cu next pluto event :)
[16:26:42] <tinkerer> no, i think it's conversed. we don' know what let glow the led when it's unprogramed
[16:41:29] <mozmck> Tom_itx: other than halui.estop.is-activated?
[16:41:59] <Tom_itx> that's probably it
[16:42:03] <mozmck> ok
[16:43:56] <Tom_itx> halui.estop.activate requests it, halui.estop.is=acivated indicates it and alui.estop.reset does that
[16:44:45] <mozmck> yes, thanks!
[17:03:11] <Tom_itx> pcw_home when you get a min, i need to find out where the 5i24 FPGA source is or a compiled ver to upload. I borked it. W10 was down when i loaded the bitfile and now it hangs the pc when plugged in
[17:12:40] <micges> Tom_itx: I saw today 6i25 that won't start in any of pcie ports on one pc, only change mb helped
[17:13:19] <Tom_itx> it worked in this one previously
[17:14:36] <micges> on that specific pc also, it stopped when they moved pc from desk to machine
[17:14:39] <Roguish> Tom_itx: Mesanet 5i24 download zip file has source, probably everything you are looking for.
[17:15:43] <Tom_itx> i've got it but wasn't too sure where to find the FPGA source
[17:15:58] <Tom_itx> a tad over my pay grade
[17:16:31] <Tom_itx> or how to configure it for that source...
[17:18:31] <Roguish> couldn't tell you myself. i just was looking for a bit file for my 7i39s.
[17:19:10] <Tom_itx> might have to make one :)
[17:20:46] <Roguish> good luck. there is a sort-of tutorial some where. i've run across it a few times.
[17:20:59] <Tom_itx> i wrote it
[17:21:17] <Tom_itx> the bitfile one anyway
[17:23:46] <Roguish> well there ya go. you're the man.
[19:54:20] <mozmck> seb_kuzminsky: you around?
[20:17:54] <KGB-linuxcnc> 03Chris Morley 052.7 1b8afff 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1b8afff
[20:21:50] <KGB-linuxcnc> 03Chris Morley 05master abb3416 06linuxcnc 10src/emc/usr_intf/stepconf/stepconf.py Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=abb3416
[21:28:46] <seb_kuzminsky> mozmck: hola
[21:28:54] <mozmck> howdy
[21:29:18] <mozmck> did you see my debian/configure and control.in changes in mozmck/2.7?
[21:29:53] <mozmck> I'd like to get those in 2.7 if you think it's ok.
[21:30:37] <seb_kuzminsky> checking...
[21:58:27] <mozmck> seb_kuzminsky: How's the basement? We've had *lots* of rain here
[22:14:54] <seb_kuzminsky> ooh, i just discovered git diff --word-diff
[22:15:19] <seb_kuzminsky> try this: git diff --word-diff-regex='[^,]' --word-diff e94446620863827925853d163bae42ff08b69945..origin/mozmck/2.7^^
[22:16:02] <seb_kuzminsky> mozmck: you left in texlive-lang-polish, was that intentional?
[22:16:40] <mozmck> well, I didn't see it in control.in, and it was only in a few distributions so I assumed they needed it for some reason
[22:16:51] <mozmck> and others did not - or did not have it?
[22:17:23] <mozmck> I only removed the ones that were in control.in, because that was obviously redundant.
[22:17:32] <seb_kuzminsky> safe bet
[22:17:47] <seb_kuzminsky> ok, i like your mozmck/2.7 branch, please push to 2.7
[22:17:56] <mozmck> ok, good!
[22:18:24] <mozmck> that --word-diff is interesting
[22:18:43] <mozmck> I don't know enough regex to do that on my own though :)
[22:19:15] <seb_kuzminsky> some people, when they have a problem, think: "I know! I'll write a regex!"
[22:19:18] <seb_kuzminsky> now they have two problems
[22:19:37] <seb_kuzminsky> did you guys see this? we're living in the future:
http://www.mpia.de/news/science/2015-05-hr8799
[22:19:58] <mozmck> haha! I'm sure they are readable if you know how - kinda like Chinese or something.
[22:20:43] <mozmck> what is the best way to get those 3 commits on 2.7? cherry-pick them?
[22:23:30] <cradek> wow that image is amazing
[22:24:36] <cradek> mozmck: git checkout 2.7; git merge mozmck/2.7
[22:24:53] <mozmck> cradek: won't that create a merge commit?
[22:25:33] <mozmck> I guess that doesn't hurt anything...
[22:25:44] <cradek> no, but if you don't like that, you can rebase instead
[22:26:11] <mozmck> oh, I forgot about that. That seems a little cleaner to me for something small like this.
[22:29:36] <cradek> well it took me like 5 commands to get that right, so I don't want to tell you how I did it, because I obviously don't know what I'm doing
[22:30:04] <mozmck> I'm looking at the man page and it looks like merging or cherry-picking is easier.
[22:30:14] <mozmck> I would have been done already :)
[22:30:34] <cradek> yeah
[22:30:36] <cradek> ok I know
[22:30:40] <cradek> you can turn it into a fast-forward merge
[22:31:07] <cradek> git checkout mozmck/2.7; git rebase 2.7
[22:31:34] <cradek> (move mozmck/2.7 onto the latest 2.7)
[22:31:40] <cradek> git checkout 2.7; git merge mozmck/2.7
[22:31:46] <cradek> (fast forward merge won't generate a merge commit)
[22:31:56] <mozmck> ah, I see.
[22:32:02] <cradek> (untested)
[22:32:03] <cradek> heh
[22:32:16] <mozmck> makes sense though. It's not ff right now
[22:32:34] <cradek> git push --dry-run origin 2.7 (check to make sure this is just your 3 changes)
[22:33:48] <cradek> then cleanup: git push origin :mozmck/2.7
[22:34:08] <cradek> er also push 2.7 after checking it of course
[22:34:17] <cradek> see isn't git easy?
[22:34:28] <cradek> what a ridiculous user interface
[22:34:54] <mozmck> I'm learning it :)
[22:35:57] <mozmck> you can also do push --delete origin mozmck/2.7
[22:36:35] <cradek> ah cool that's a little less ridiculous
[22:36:36] <mozmck> git push --dry-run origin 2.7 just returns: To ssh://m-mcknight@git.linuxcnc.org/git/linuxcnc.git
[22:36:37] <mozmck> 1b8afff..753e7c1 2.7 -> 2.7
[22:37:00] <cradek> gitk 1b8afff..753e7c1
[22:37:32] <mozmck> ah, ok
[22:37:36] <mozmck> looks right
[22:37:40] <cradek> sweet
[22:37:45] <cradek> push away
[22:37:54] <KGB-linuxcnc> 03Moses McKnight 052.7 55ae48d 06linuxcnc 10debian/configure Removed redundant dependencies from debian/configure * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=55ae48d
[22:37:54] <KGB-linuxcnc> 03Moses McKnight 052.7 d6fcee7 06linuxcnc 10debian/configure 10debian/control.in Remove libgnomeprintui2.2-dev as dependency in Ubuntu 14.04 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d6fcee7
[22:37:54] <KGB-linuxcnc> 03Moses McKnight 052.7 753e7c1 06linuxcnc 10debian/configure Combined some distributions in debian/configure * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=753e7c1
[22:38:12] <cradek> beautiful
[22:38:13] <KGB-linuxcnc> 05mozmck/2.7 f422776 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f422776
[22:38:22] <cradek> you're a wizard now too
[22:38:25] <cradek> wizards everywhere lately
[22:38:33] <mozmck> heh, thanks for the help
[22:38:49] <cradek> anytime
[22:44:44] <cradek> seb_kuzminsky: I love the "oh we already happened to have some snapshots of that from 15 years ago" twist
[22:48:17] <seb_kuzminsky> reinterpreting old data in the light of new understanding
[22:48:50] <seb_kuzminsky> nice work mozmck!
[22:48:51] <mozmck> I merged into master and it did not give any problems, should I assume it is good and push?
[22:48:58] <mozmck> thanks seb_kuzminsky!
[22:49:56] <seb_kuzminsky> mozmck: if the merge runs to completion without complaining, it nearly always did the right thing
[22:50:02] <seb_kuzminsky> so go ahead and push it
[22:50:14] <mozmck> ok. I checked the files and they look right too.
[22:50:42] <KGB-linuxcnc> 03Moses McKnight 05master 4c0ce18 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4c0ce18
[23:02:58] <cradek> I just noticed my website has not had a redesign in 10 years
[23:03:10] <cradek> that's amazing and ... I'm fine with it
[23:03:29] <cradek> and now I'm hungry and it's bedtime
[23:03:34] <cradek> long weekends are so hard :-)
[23:04:44] <Tom_itx> i just keep adding to mine
[23:04:58] <Tom_itx> too much effort to redo it
[23:09:55] <seb_kuzminsky> i hope it still has <blink>
