Back
[06:52:07] <skunkworks_> cradek,
http://pastebin.ca/2817129
[06:56:22] <skunkworks_> when I plug a usb device in - nothing changes in dmesg
[07:35:31] <jepler> linux/lastlog linux 3.4.8
[07:35:32] <jepler> oops
[07:38:45] <jepler> skunkworks_: I googled around some, but no guesses at anything to try
[07:40:19] <skunkworks_> there was some comments about unloading ehci_hcd - but didn't seem to help
[08:11:27] <skunkworks_> maybe I should just install and see what happens then
[08:12:41] <cradek> if you boot the installer, you'll get a different kernel (you can just stop as soon as it starts asking questions). you can go to the alt-f2 screen and start a console. it would be interesting to know if you get messages when plugging in usb things, when booted that way.
[08:14:06] <cradek> I'm surprised to see in that dmesg that it recognizes a bunch of usb stuff, but then it apparently doesn't work
[08:14:21] <jepler> yeah, that's how I read it too
[08:14:33] <jepler> skunkworks_: you tried all the usb ports?
[08:14:54] <skunkworks_> yes - there are some 3's and 2's on the back. all seem to not work
[08:15:11] <skunkworks_> (well - they work up to a point in the booting process
[08:15:25] <CaptHindsight> which kernel is this?
[08:15:42] <jepler> CaptHindsight: 3.4.87 with some version of the rtai kernel patch
[08:17:02] <CaptHindsight> jepler: memleak will be back later, is the kernel config posted somewhere?
[08:17:37] <CaptHindsight> sounds like config vs RTAI problem
[08:18:38] <jepler> cradek: are the kernel packages at an official place yet?
[08:18:57] <cradek> linuxcnc.org wheezy base
[08:19:55] <jepler> weird, there's a -amd64 kernel but it's in the binary-i386 directory
[08:20:17] <jepler> CaptHindsight: so I think this is the .deb which is on the live media skunkworks_ is using:
http://linuxcnc.org/dists/wheezy/base/binary-i386/linux-image-3.4-9-686-pae_3.4.87-1~linuxcnc.1_i386.deb
[08:21:08] <jepler> I think this is the config:
http://emergent.unpythonic.net/files/sandbox/config-3.4-9-rtai-686-pae
[08:21:17] <cradek> I wonder if Rob intended one of us to merge his hotfix/g61-exactstop branch
[08:22:18] <skunkworks_> I forgot to talk to him about that..
[08:22:58] <skunkworks_> he has been pretty busy with his new business
[08:23:24] <CaptHindsight> just fyi
http://dpaste.com/22CPR57 preempt_rt kernel v3.12.22-rt34 kernel config that works well ~30uS latency jitter
[08:23:32] <mozmck> skunkworks_: how was the meeting?
[08:23:58] <skunkworks_> it was fun. tormachs facilty is pretty cool. not what I expected.
[08:24:09] <skunkworks_> minimal amount of linuxcnc bashing
[08:24:19] <mozmck> that's nice :)
[08:25:05] <skunkworks_> got to meet rob - he gave a nice talk about the new TP
[08:25:41] <skunkworks_> also met Jason Kridner of beaglebone/ti fame
[08:27:07] <skunkworks_> he talked about the linuxcnc/machinekit project is probably one of the bigest
[08:27:12] <mozmck> interesting!
[08:28:09] <skunkworks_> (I was only there saturday)
[08:28:20] <jepler> one of the biggest .. ?
[08:28:58] <CaptHindsight> skunkworks_: are they all using 2+ PC systems with printers and machines? One for motion control and the others for GUI?
[08:29:18] <skunkworks_> who are they?
[08:29:34] <CaptHindsight> machinekit users and devs
[08:29:36] <skunkworks_> machinekit?
[08:29:37] <skunkworks_> ah
[08:29:50] <cradek> possibly phones and tablets and stuff too?
[08:29:51] <skunkworks_> that is one of their goals..
[08:29:58] <skunkworks_> right
[08:30:27] <skunkworks_> so the hal/realtimey stuff would be the only thing running on say the BBB and the gui would be on something else non realtimey
[08:31:12] <CaptHindsight> so the main benefit is using a phone or tablet to monitor a machine?
[08:31:46] <skunkworks_> I think it is bigger than that - but I may not know all the in/out..
[08:33:00] <skunkworks_> http://www.machinekit.io/
[08:34:10] <CaptHindsight> I don't see cnc shops going to remote monitoring of machines anytime soon to replace an operator
[08:35:51] <skunkworks_> I think part of it is (atleast mah's big push) is finding a reatime subsystem that works - like maybe the bbb - that will work without having to worry if the video/whatever hardware plays nice with it.
[08:36:23] <seb_kuzminsky> jepler: the -amd64 kernel is (i think) actually an i386 kernel, just with optimizations for 64-bit processors
[08:36:37] <seb_kuzminsky> just like there's a flavor for -486 and for -686-pae
[08:37:46] <seb_kuzminsky> it gets built along with the other i386 kernels
[08:37:56] <seb_kuzminsky> i should maybe disable it in my linux-image config
[08:52:25] <seb_kuzminsky> that amd64 kernel is linux-image-3.4-9-amd64_3.4.87-1~linuxcnc.1_i386.deb, the trailing _i386.deb indicates that it's a 32-bit kernel, and the -amd64 as part of the package name indicates that it's targetted for amd64 processors
[08:52:28] <skunkworks_> omg - I swear some times I should not get out of bed. I somehow managed to enter the password twice wrong... (won't let me log in..)
[08:52:29] <seb_kuzminsky> clear as mud?
[08:52:36] <seb_kuzminsky> heh
[08:52:47] <seb_kuzminsky> at least you didnt enter it into your irc winow
[08:57:56] <skunkworks_> heh
[09:37:28] <skunkworks_> oh hey - wheezy asks for your username first... duh
[09:49:45] <cradek> seb_kuzminsky: I'm getting 403 for
http://buildbot.linuxcnc.org/dists/
[09:53:51] <skunkworks_> is this normal?
http://pastebin.ca/2817165
[09:53:55] <skunkworks_> heh
[09:54:01] <skunkworks_> I think that is the same error
[09:59:19] <cradek> yeah, same
[10:01:13] <KGB-linuxcnc> 03Robert W. Ellenberg 05master e9613c2 06linuxcnc Merge branch 'hotfix/g61-exactstop' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e9613c2
[10:03:10] <cradek> sweet
[10:03:21] <skunkworks_> yay - did he hear us?
[10:03:32] <cradek> I don't know
[10:15:18] <jepler> cradek: my memory of the hm2_pci memcpy() bug's history seems to have been wrong.
[10:18:19] <cradek> jepler: is all well?
[10:29:43] <JT-Shop> seb_kuzminsky, you see my reply to your question?
[10:30:16] <cradek> seb_kuzminsky: ohh, it's the thing you already fixed in 3e97b6f5 but I guess it was never built or something?
[10:30:59] <cradek> http://git.linuxcnc.org/gitweb?p=hostmot2-firmware.git;a=commitdiff;h=3e97b6f53ad3
[10:31:00] <seb_kuzminsky> cradek: thanks for the bug report about the buildbot
[10:31:26] <seb_kuzminsky> it's out of disk
[10:31:30] <cradek> seb_kuzminsky: also the source for hostmot2-firmware-* is missing in wheezy
[10:31:35] <seb_kuzminsky> ok
[10:31:37] <cradek> uh-oh!
[10:31:52] <skunkworks_> get all the porn off of it!
[10:32:08] <cradek> virtual machines are even worse than porn
[10:35:20] <seb_kuzminsky> ugh, it's got 8 gigs of ancient build logs
[10:35:25] <seb_kuzminsky> me gets out the pruners
[10:36:46] <skunkworks_> cradek, how do I do sudo apt-get build-dep linuxcnc on wheezy?
[10:37:37] <seb_kuzminsky> skunkworks_: is that a trick question?
[10:37:42] <cradek> skunkworks_: in /etc/apt/sources.list.d/linuxcnc.list, add a deb-src line that's otherwise the same as the deb line
[10:37:51] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 0000.checkin
[10:37:54] <cradek> (I've added that now)
[10:37:56] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[10:38:12] <skunkworks_> ah
[10:38:13] <skunkworks_> thaks
[10:38:15] <skunkworks_> thanks
[10:38:30] <seb_kuzminsky> ok, i made some space be removing the old hardy-amd64 logs, we'll see if it rebuilds correctly now
[10:39:02] <skunkworks_> duh
[10:40:16] <linuxcnc-build> build #2211 forced
[10:40:16] <linuxcnc-build> I'll give a shout when the build finishes
[10:40:32] <seb_kuzminsky> cradek: yeah, it was fixed in 3e97b6f53, and the hm2 buildbot built it
[10:41:22] <cradek> I guess that's not what's in wheezy/base
[10:42:23] <skunkworks_> stupid question - what is the text editor on wheezy? (that is a gui)
[10:42:58] <cradek> there's one on the menu but I forget its name
[10:43:09] <skunkworks_> ok - I will keep looking
[10:43:11] <cradek> mousepad??
[10:49:18] <skunkworks_> yes
[10:50:20] <seb_kuzminsky> hm2 debs here:
http://buildbot.linuxcnc.org/hm2/dists/
[10:50:40] <seb_kuzminsky> i should copy the debs to wlo
[10:51:27] <seb_kuzminsky> this is the apt line for the hm2 buildbot: deb
http://buildbot.linuxcnc.org/hm2 hm2-firmware master
[10:51:29] <seb_kuzminsky> this is all horribly disorganized and untested and all those kinds of bad things
[10:51:54] <seb_kuzminsky> 0.8.10 is available frmo the buildbot, vs 0.8 available on wlo
[10:52:08] <seb_kuzminsky> all that's changed is some packaging infrastructure to make the buildbot happy, no firmware changes
[11:03:49] <skunkworks_> wow - I am dense today.. So - I added the deb-src line to the linuxcnc.list. Did the sudo apt-get update - everything looked fine except for the buildbot issue.. but when I do a sudo apt-get build-dep linuxcnc it cannot find the packages
[11:04:37] <seb_kuzminsky> if you're still getting 403 from the buildbot, it won't have learned what i needs for the build-deps to work right
[11:05:21] <seb_kuzminsky> Err
http://buildbot.linuxcnc.org precise/2.6-sim Sources 403 Forbidden
[11:05:45] <seb_kuzminsky> oh! i added deb archive signing to the linuxcnc buildbot
[11:05:46] <skunkworks_> ok
[11:06:21] <skunkworks_> great! (what does that mean?)
[11:06:27] <seb_kuzminsky> please everyone do this:
[11:06:29] <seb_kuzminsky> sudo apt-key adv --keyserver hkp://keys.gnupg.net --recv-key E0EE663E
[11:06:38] <seb_kuzminsky> then it'll stop complaining about untrusted packages frmo the buildbot
[11:06:57] <seb_kuzminsky> bbl
[11:22:16] <seb_kuzminsky> skunkworks_, cradek : i think the buildbot 403 issue is fixed
[11:22:26] <seb_kuzminsky> thanks for cluing me in about it
[11:43:35] <linuxcnc-build> Hey! build 0000.checkin #2211 is complete: Success [3build successful]
[11:43:35] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2211
[11:51:57] <skunkworks_> I am still doing something wrong..
http://pastebin.com/896x8bvT
[11:55:03] <cradek> maybe I've lost track of what you've installed
[11:55:25] <cradek> linuxcnc.list should be: deb
http://linuxcnc.org wheezy base 2.6
[11:55:36] <cradek> deb-src
http://linuxcnc.org wheezy base 2.6
[11:55:42] <cradek> I think you don't have the 2.6
[11:56:06] <cradek> you should probably just remove the buildbot entries now
[11:56:21] <cradek> the livecd no longer depends on buildbot since we have 2.6.0~pre4 for wheezy
[11:59:34] <skunkworks_> ok
[12:04:39] <skunkworks_> changing it to 2.6 helped... (neither deb line had 2.6 at the end)
[12:04:41] <skunkworks_> but
http://pastebin.com/uTmtR12q
[15:24:19] <seb_kuzminsky> the new rtai kernel (3.4-9-rtai-*) has problems on dgarr's machine and on one of mine
[15:24:43] <seb_kuzminsky> the old 3.4.55-rtai-2 kernel did not have any trouble on my machine, and i do not recall any bug reports against it
[15:25:17] <seb_kuzminsky> therefore i think i should recompile the old version using the new build system & debian packaging, and we should ship that for precise & wheezy
[15:25:27] <seb_kuzminsky> comments?
[15:28:57] <seb_kuzminsky> the current 3.4-9-rtai packages also have a bogus mismatch between the kernel patch and the userspace part:
[15:29:32] <seb_kuzminsky> i'm using the latest rtai kernel patch, for 3.4.87, but the latest rtai userspace doesn't build (i'm in communication with shabby about it) so i'm using the old userspace fro mthe 3.4.55-rtai-2 debs
[15:29:48] <seb_kuzminsky> i'm suggesting i should revert the kernel to match the userspace
[15:39:58] <seb_kuzminsky> i think the only alternative is to fix both the rtai kernel patch and the rtai userspace, and then ship that
[15:41:18] <seb_kuzminsky> and i dont think we should hold up 2.6 for that
[15:52:44] <cradek> do you think 3.4.55 is more widely tested than the new kernel?
[15:53:12] <cradek> I think your reasoning is sound, but I'm unsure of that premise
[15:56:49] <cradek> if you fix the packaging I think it's likely it will present no challenges to use it on the cd
[15:57:44] <seb_kuzminsky> i dont know how widely the 3.4.55 kernel was used by others. I've been running it on my bridgeport since i first created it, with 0 problems
[15:58:02] <seb_kuzminsky> also, i have one machine that works fine with 3.4.55 and fails with 3.4.87
[15:58:07] <seb_kuzminsky> so, i donno
[15:58:52] <jepler> did dgarr or skunkworks try .55 on their troublesome computers?
[16:00:03] <cradek> I have also run hardware with that 3.4.55 kernel
[16:00:19] <jepler> seb: did your script upload this to the wrong page, or is there sense to an "i386" package for "amd64" hardware?
http://linuxcnc.org/dists/wheezy/base/binary-i386/linux-image-3.4-9-amd64_3.4.87-1~linuxcnc.1_i386.deb
[16:00:33] <cradek> jepler: scroll back
[16:00:49] <jepler> cradek: ok, will look
[16:01:07] <jepler> OK, I see he answered me the first time, but that answer surprises me
[16:01:14] <cradek> heh
[16:01:36] <jepler> that'll teach me to not read irc for 6 hours
[16:01:40] <jepler> and then ask the same question again :-/
[16:02:57] <seb_kuzminsky> i didnt perceive skunkworks' problem as due to the rtai kernel, did i miss something
[16:03:00] <seb_kuzminsky> ?
[16:03:12] <jepler> seb_kuzminsky: it could still be different from .55 to .87, one supposes
[16:04:34] <cradek> I asked him to try booting 3.2.0.whatever (by running the installer) and then see if usb works. I don't know if he did, because I didn't scroll back.
[16:05:58] <seb_kuzminsky> heh
[16:35:39] <skunkworks> oh - I didn't try that
[16:36:04] <skunkworks> did anyone see my build dependancy issue? what the heck am I doing wrong?
[16:42:51] <micges-dev> seb_kuzminsky: remember my hm2 encoder Nan velocity error? I think I got it here again
[16:43:41] <seb_kuzminsky> micges-dev: did it say "uh-oh, encoder vel is broken"?
[16:44:55] <micges-dev> seb_kuzminsky: not really becouse I've extracted hm2 encoder code to userspace library, but seems to same lines
[16:48:38] <seb_kuzminsky> that's going to make it hard for me to help debug it
[16:51:19] <micges-dev> seb_kuzminsky: it seems to be compiler error here, I'll compare it with hm2 driver maybe I'll find something
[16:51:36] <seb_kuzminsky> which compiler?
[16:51:47] <micges-dev> gcc in 12.04
[16:52:06] <seb_kuzminsky> jepler and cradek recently worked around a compiler bug in debian wheezy
[16:52:07] <micges-dev> 4.6.3
[16:52:48] <seb_kuzminsky> does your branch contain ... 5bbab25f?
[16:52:59] <seb_kuzminsky> oh, i think 4.6 is not affected by this bug, only 4.7
[16:53:13] * seb_kuzminsky awards micges-dev the gcc-bug-of-the-week award
[16:54:57] <micges-dev> heh
[17:50:40] <andypugh> I have tweaked my version of the hal_spinbutton widget
[17:50:41] <andypugh> http://pastebin.com/PcRHGnrh
[17:50:55] <andypugh> I wonder if it makes sense to push the change?
[17:51:23] <andypugh> What it means is that it will do some simple unit conversions right there in the box.
[17:52:06] <seb_kuzminsky> that sounds handy
[17:53:00] <andypugh> it is for me, as I do all my lathe work with my little GUI thing, and recently I have been doing some imperial stuff.
[17:53:49] <andypugh> Being able to type “19tpi” and have the box update to “1.337” is rather neat
[17:54:36] <andypugh> <feature creep> I should make it parse “1 15/32” too.
[17:56:29] <andypugh> I can’t help feeling that the python code could be more elegant.
[17:58:50] <seb_kuzminsky> so if i type "1 in" it converts to 25.4 (assuming i want mm), and if i type "25.4 mm" it converts to 1 (assuming i want inches)?
[18:01:31] <andypugh> Indeed
[18:02:00] <seb_kuzminsky> that is a surprising behavior, to me
[18:02:00] <andypugh> The theory being that you wouldn’t bother with any conversion in machine-native units
[18:02:08] <seb_kuzminsky> right
[18:02:35] <andypugh> (and, in fact, you typically wouldn’t even notice that the behaviour was there)
[18:03:36] <seb_kuzminsky> the kwallaces are multiplying
[18:04:22] <andypugh> I could just put the behaviour in a special handler for my GUI.
[18:05:06] <andypugh> But it seems handy (and harmless) behaviour to me for the general gladevcp widget
[18:05:26] <seb_kuzminsky> i can't tell if it's harmless or not
[18:05:47] <kwallace4> Oops, I got knocked off the net. Me too.
[18:06:00] <seb_kuzminsky> if i knew i could type units in, i would expect to have the thing know my native units and convert to that, not convert either way based on input
[18:06:12] <andypugh> (It isn’t like you would be typing “tpi” in the box by accident, or even on the assumption that it would do something)
[18:06:27] <seb_kuzminsky> that's true
[18:06:46] <seb_kuzminsky> but i might type "1 in" even when my native units are imperial
[18:06:54] <seb_kuzminsky> and be surprised by a 2-foot move
[18:07:00] <andypugh> How does the GladeVCP widget know the machine native units?
[18:07:13] <seb_kuzminsky> i dont think it does, currently
[18:07:20] <andypugh> I don’t think it can
[18:07:33] <kwallace4> linuxcnc.status ?
[18:07:39] <seb_kuzminsky> can it read it out of the ini file at startup?
[18:07:49] <andypugh> What INI file?
[18:08:01] <seb_kuzminsky> the one in getenv("INI_FILE")
[18:08:15] <seb_kuzminsky> if it's started from the linuxcnc starter script
[18:08:32] <andypugh> Why do I have to have an INI file for a standalone Glade interface?
[18:09:15] <andypugh> (for example, I am testing here in halcmd, I have no INI, no linuxcnc.status (AFAIK)
[18:09:22] <seb_kuzminsky> i didn't mean to say you need that
[18:10:04] <seb_kuzminsky> i just meant that if i type "1 in" i expect to get 1 inch no matter what, instead of 1 inch if i'm on a metric machine and 25.4 inches if i'm on an imperial machine
[18:10:32] <kwallace4> http://www.linuxcnc.org/docs/html/common/python-interface.html#_linuxcnc_stat_attributes
[18:10:38] <seb_kuzminsky> i understand that's not how you're using it - you know to omit the units if they match the machine's native units
[18:10:45] * seb_kuzminsky click
[18:11:09] <andypugh> Anyway, you wouldn’t be totally surprised by the 2’ move, as (slightly unexpectedly, because of the events being captured) the conversion happens the instant you type the ’n’ of ‘in'
[18:11:38] <seb_kuzminsky> oh, it changes the thing i typed, before i hit enter & before it goes out on a hal pin?
[18:11:48] <andypugh> So you would see “25.4” in the box before you pressed “enter” and set the hal pin
[18:11:57] <andypugh> Yes
[18:12:14] <seb_kuzminsky> ah
[18:12:27] <andypugh> (so you can change it back, by typing something else)
[18:12:43] <seb_kuzminsky> by backspacing away the 25.4 and then not typing units
[18:12:51] <andypugh> I am now working on trapping /2 /4 /16 etc
[18:13:42] <seb_kuzminsky> fractions are nice and unambiguous, unlike the units behavior you described above
[18:13:45] <andypugh> Well, you could type 1 - i - n - m - m and have a “1” in the box at the end :-)
[18:13:53] <seb_kuzminsky> heh
[18:15:17] <andypugh> Or, with the fractions, if I type 3 3/4 then there will be an immediate conversion to 3.75, and then I can type “in” and get “95.25”
[18:16:25] <seb_kuzminsky> i can see how that's a handy shortcut, but i'm still bothered by the incorrect conversion if the user-entered units match the machine units
[18:16:32] <andypugh> It can just live in my own handler code, I guess, if you don’t like it.
[18:17:04] <andypugh> And I can’t see a way to work round the fact that there might simply not be any machine units.
[18:17:47] <seb_kuzminsky> could you teach the widget its native units via some mechanism other than ini files? command-line argument maybe?
[18:18:13] <seb_kuzminsky> if there are no machine units, then what do the conversions mean?
[18:19:03] <seb_kuzminsky> i sure like it when i can do simple math in number-entry boxes (like the Axis touch-off entry dialog)
[18:19:58] <seb_kuzminsky> maybe if the widget learns that it has no native units, it should not convert?
[18:20:40] <andypugh> Well, basically “mm” is a shortcut for “divide by 25.4” and “in” is a code word to mean “multiply by 25.4”. They don’t really embody any sense of units as such.
[18:22:00] <seb_kuzminsky> by using the strings "mm" and "inch" you make the user expect to get units-like behavior
[18:22:26] <andypugh> You can happily keep typing “m” and the number changes every time.
[18:22:36] <seb_kuzminsky> and the current implementation doesn't provide that imo
[18:22:43] <seb_kuzminsky> yes, that's confusing
[18:23:47] <andypugh> Ah, forget it then. I’ll just keep it for myself.
[18:24:28] <seb_kuzminsky> i like the direction you're heading, but i dont think the current implementation you're proposing is the right one
[18:24:38] <seb_kuzminsky> but i'm just some guy, don't let me discourage you
[18:25:44] <andypugh> I can’t see a way to do what you think it should do.
[18:26:30] <seb_kuzminsky> could you make an aggregate widget with a text entry box and a pull-down list (or something) of native units?
[18:27:07] <seb_kuzminsky> or do you think that's the wrong direction to go for this feature?
[18:27:31] <andypugh> I think it is beyond my enthusiasm
[18:30:28] <seb_kuzminsky> bbl
[18:56:55] <andypugh> cradek: Did you have a MaxNC?
[19:02:31] <cradek> I still have some parts of it
[19:02:55] <andypugh> Someone on the other channel is trying to get one working.
[19:03:36] <cradek> there's nothing special about the hardware, but long after mine, the switched to some magic closed loop stepper thing - no idea how it communicates
[19:03:39] <cradek> they
[19:04:09] <cradek> mine was winding activation, but that was like 1993? vintage
[19:04:20] <cradek> mine's step/dir now
[19:04:47] <andypugh> He’s got a G540 on order, so it might get easy.
[19:04:55] <cradek> yeah that's gotta be the smart way
[19:43:57] <skunkworks> logger[psha]_:
[19:43:57] <logger[psha]_> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-07-02.html
[21:12:24] <jepler> maybe if you defined the units with the widget
[21:12:51] <jepler> there are at least two units packages in python
[21:13:48] <jepler> python-quantities - Library for computation of physical quantities with units
[21:14:03] <jepler> only one I see packaged in debian, and if it's "based on numpy" it may be heavyweight
[21:39:40] <skunkworks> jepler: the wine is gone too. It was pleasant. - little dry but totally drinkable plane
[21:40:01] <skunkworks> (never tried it with 7-up)
[21:46:18] <skunkworks> heh
[21:46:20] <skunkworks> plain.
[21:52:11] <jepler> skunkworks: glad you enjoyed it
[22:15:26] <cradek> I'm rebuilding with deb-src fixed, and all firmwares included (manually, since hostmot2-firmware-all doesn't quite work yet)
[22:15:44] <cradek> won't fix dewey's or sam's problems, though
[22:22:03] <skunkworks> which problem?
[22:22:09] <skunkworks> the usb issue?
[22:22:21] <skunkworks> I can try the stock (non rt) kernel tomorrow.
[22:22:25] <skunkworks> I didn't catch taht
[22:22:27] <skunkworks> that
[22:22:51] <skunkworks> there was an issue with deb-src?
[22:37:10] <cradek> it was missing - you had to add it
[22:37:28] <cradek> yeah it won't fix your usb thing because we didn't change anything
[22:37:39] <cradek> but I can still fiddle with the other details
[22:38:11] <skunkworks> ok - but the issue with me installing the dependancies? is that still something I am doing wrong?
[22:38:33] <cradek> the python thing? I'm not sure, but it's not a cd issue, it may be in our linuxcnc package
[22:39:05] <skunkworks> ok
[22:39:10] <skunkworks> I can play some more tomorrow
[22:40:56] <skunkworks> it was this
http://pastebin.com/uTmtR12q
[22:41:07] <skunkworks> I started going down the rabbit hole
[22:42:43] <cradek> Installed: 2.7.3-6+deb7u2
[22:42:48] <cradek> Version table:
[22:42:48] <cradek> *** 2.7.3-6+deb7u2 0
[22:42:48] <cradek> 500
http://http.debian.net/debian/ wheezy/main i386 Packages
[22:43:13] <cradek> it's in main. not sure why you didn't get it...
[22:43:20] <cradek> oh libssl-dev
[22:43:33] <cradek> wonder if I'm missing some security updates source for main
[22:44:05] <cradek> we'll be able to figure it out tomorrow I bet