Back
[07:42:45] <jthornton> I added a second html layout to look at
http://gnipsel.com/linuxcnc/html/
[08:06:34] <mozmck> jthornton: I like the second one better.
[08:06:45] <jthornton> me too
[08:07:04] <mozmck> I had something like that in mind the other day, but did not know how hard it was to do.
[08:07:12] <jthornton> thanks for the feedback
[08:07:36] <mozmck> thanks for the work on it!
[08:08:00] <mozmck> I think it will make it easier to use.
[08:08:01] <jthornton> easy when you know how, hard when your figuring it out
[08:08:09] <jthornton> yes
[08:08:10] <mozmck> yes, like most things
[08:12:29] <jthornton> refresh the page I cleaned it up a tad
[08:18:26] <mozmck> I can't tell any difference here.
[08:21:44] <mozmck> I notice that under API calls, the sections are next to each other instead of down the page, so the page goes wider than my screen instead of scrolling down the screen.
[08:22:46] <archivist> note lusers with mobile devices these days too, they hate wide pages
[08:23:42] <archivist> and google is threatening to downgrade non mobile friendly pages in their index
[08:43:03] <jthornton> API calls should be a bit better behaved now
[08:43:29] <jthornton> off to work!
[08:48:46] <mozmck> yes, much better
[10:24:25] <jepler> someone without too many projects already should pick one of these up and see if preempt-rt and linuxcnc will work on it
http://store.imgtec.com/us/product/mips-creator-ci20/
[10:24:33] <jepler> (mips-based, which would be new afaik)
[10:25:03] <archivist> and the spare cash :)
[10:27:28] <pcw_home> Must be good, Its Purple
[10:28:54] <jthornton> if it was blue it would be better
[10:31:14] <cradek> I can't even get a working parallel port
[10:33:41] <pcw_home> just have to buy about 6 different ones, one of they might work
[10:33:50] <pcw_home> them
[10:34:04] <cradek> it's hard to find any that aren't known not to work
[10:34:36] <cradek> I know - you should make a 5i25 firmware that does everything right
[10:35:02] <cradek> surely it will pay off for you, since it can't be hard at all
[10:37:05] <pcw_home> I have thought about it (it could also be quite a bit faster) but I _dont_ need any more projects
[10:37:40] <cradek> it would be very cool, but yeah, surely it's not even worth doing
[10:41:08] <skunkworks__> zlog
[10:46:20] <mozmck> pcw_home: thinking about projects, do you have a 7i92 with 2 IDC headers yet ? :)
[10:47:21] <pcw_home> Unfortunately still way behind
[10:47:38] <mozmck> ok, my boss keeps bugging me to ask you.
[10:47:53] <pcw_home> next set of kits we will build the 7I92H and 7I92M
[10:48:01] <pcw_home> (and 7I93)
[10:48:11] <mozmck> I know how 'behind' feels :)
[10:48:17] <mozmck> what is the 7i93?
[10:48:36] <pcw_home> 2x 50 pin version of the 7I92
[10:48:56] <mozmck> I see.
[10:49:08] <pcw_home> Kind of a Ethernet 7I43
[10:51:00] <micges> also it will have simmilar size to 7i43?
[11:01:06] <skunkworks__> ejsy snpiy yjr 7i73? :)
[11:01:10] <skunkworks__> heh
[11:01:13] <skunkworks__> what about the.
[11:09:54] <pcw_home> yes same size basically
[11:10:20] <pcw_home> 7i73s are (finally) in build process
[11:10:34] <skunkworks__> Yay!
[11:23:07] <jepler> ugh, the ci20 has its ethernet on the same bus as the onboard NAND, so if you wanted to use it with an ethernet card you'd have to ensure no "disk" access while linuxcnc was running
[11:23:42] <mozmck> cmorley: overriding the keybinding functions does a bit oddly. It seems to call my function and then the gscreen function if I use the same name function.
[11:23:46] <jepler> or not use the nand at all -- sd card seems to be on a different interface
[11:26:51] <jepler> mozmck: this advice may be way off base, but in gtk the return value from a signal is 'propagated' if the return value from the handler is False and stopped if it is True. The default return value of a Python function which reaches the end is None, which is False when converted to bool.
[11:27:12] <jepler> mozmck: so in summary, I would add 'return True' to the end of your handler and see if that changes it so that the other function doesn't also happen
[11:27:30] <jepler> https://developer.gnome.org/gtk-tutorial/stable/x1810.html
[11:27:32] <mozmck> Well, these functions do all return True
[11:27:38] <jepler> ok, darn, that must not be it then
[11:27:54] <mozmck> I checked that first.
[11:28:27] <mozmck> yeah, so I don't understand it. I changed the function name and remapped the binding and that seems to work - although my code does not yet ;(
[11:31:51] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/threadtiming d1b29cc 06linuxcnc 10src/hal/utils/halrmt.c halrmt.c fix readClient() incorrect goto finished * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d1b29cc
[11:31:51] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/threadtiming e309beb 06linuxcnc 10src/hal/utils/halrmt.c halrmt.c report thread .time pin value * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e309beb
[11:34:45] <dgarr> seb_kuzm1nsky: , others please review dgarr/threadtiming, screenshots
http://www.panix.com/~dgarrett/stuff/threadtiming/
[11:34:53] <dgarr> does anyone actually use halrmt?
[11:38:51] <seb_kuzminsky> dgarr: i don't know of anyone using halrmt
[11:39:15] <dgarr> i suspect it should be deprecated
[11:39:25] <jthornton> what does it do?
[11:40:53] <seb_kuzminsky> it's one of the buggiest programs in our repo, according to clang:
http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-662-ge743793/index.html
[11:42:04] <skunkworks> hal remote?
[11:42:10] <seb_kuzminsky> jthornton: it's kind of a remote shell for hal, iirc
[11:42:28] <seb_kuzminsky> like an mutant baby from halcmd and telnet
[11:42:36] <jthornton> lol
[11:48:01] <archivist> picking one error to that code, methinks clang needs a kick where it hurts
[11:49:59] <seb_kuzminsky> archivist: which one do you think clang is wrong about? the random one i clicked on sure looks like a silly bug in halrmt:
http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-662-ge743793/report-x1g5Zs.html#EndPath
[11:52:33] <archivist> tokens[0] seems to be initialised at line 3048 yet it whines at 3090
http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-662-ge743793/report-x1g5Zs.html#EndPath unless it spotted something about the state of pch correctly
[11:53:41] <archivist> seems to be some assumptions to find that path
[11:53:56] <seb_kuzminsky> wrong link?
[11:56:30] <archivist> dont think so
http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-662-ge743793/report-BymmME.html#EndPath is after line 3090
[11:57:15] <seb_kuzminsky> ah, that link makes sense
[11:57:42] <seb_kuzminsky> well, the strtok on 3046 can sure return NULL, which would cause this bug, right?
[11:58:51] <cradek> weird
[11:59:09] <cradek> I don't see how #2 follows from #1, likewise 6 from 5
[11:59:49] <cradek> maybe I just don't understand the presentation
[12:00:07] <seb_kuzminsky> so if halcmd is expecting to get "command arg1 arg2" (for example "setp motion.enable 1"), but the user sends just setp", then halrmt will call setSetp with uninitialized arguments
[12:00:37] <seb_kuzminsky> cradek: i agree, i think #1, #3, and #5 are inverted from what clang is really thinking
[12:00:59] <cradek> yeah, gotta be
[12:05:19] <archivist> I dont see where the buffer got set correctly for strtok either as all the calls there are (null,delim) being continuations
[12:07:47] <seb_kuzminsky> line 3310
[12:09:53] <archivist> I was expecting it in that routine rather than elsewhere :)
[12:10:56] <seb_kuzminsky> that would make sense ;-)
[12:11:34] <seb_kuzminsky> halrmt has the same kind of hand-written parser that linuxcncrsh has, they're kind of tricky to get right...
[12:13:10] <archivist> and the counter (5) is an assumption on the coders part that all commands have 5 tokens
[12:13:42] <archivist> where I agree there is a bug :)
[12:15:55] <seb_kuzminsky> yeah, that's another bug. i'm bummed clang didn't point it out
[12:18:15] <seb_kuzminsky> bah
[12:20:06] <seb_kuzminsky> the city of boulder has been sending me "flood warning" emails all night
[12:30:09] <KGB-linuxcnc> 03Norbert Schechner 052.6 908c308 06linuxcnc 10src/emc/usr_intf/gmoccapy/getiniinfo.py 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_5 - several new keyboard shortcuts * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=908c308
[12:30:56] <KGB-linuxcnc> 03Norbert Schechner 052.7 805b1a8 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=805b1a8
[12:31:28] <KGB-linuxcnc> 03Norbert Schechner 05master 4ef4cb5 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4ef4cb5
[12:35:47] <mozmck> jepler: looks like it was some bad code in my functions causing the problem
[12:36:11] <mozmck> python does weird stuff without warning if you use variables that don't exist
[12:44:55] <archivist> this one is trivial to fix if it is right
http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-662-ge743793/report-xWkuIS.html#EndPath
[14:08:07] <skunkworks> pcw_home, could a firmware for the 5i25 be made with encoder counters from pins 1 -> 8?
[14:54:21] <jthornton> wow I have to make the submakefile count...
[14:55:42] <cradek> count?
[14:56:25] <jthornton> http://pastebin.com/VaM5XC8e
[14:57:01] <jthornton> the section names have to be unique for the collapse/expand to work but I have an idea now to just add one more thing to the calling fucntion
[14:59:03] <jthornton> something like this I think but with unique names that won't be used if you add a section
http://pastebin.com/2aj80XbU
[14:59:28] <jthornton> use names like man1 man2 man3 etc
[15:00:29] <jthornton> now I wonder if ST can see that from within
http://pastebin.com/fx1mbUZQ
[15:01:37] <jthornton> I think I can make it work... but back to work in the meantime
[15:01:43] <jepler> couldn't you just use the first argument to get the section name? "sec_man1" etc ?
[15:04:00] <JT-Shop> I see what your talking about now, thanks
[15:04:18] <JT-Shop> they just have to be unique
[15:28:41] <andypugh> There is nothing like trying to use your new component to helkp you spot the glaring flaws, is there?
[15:30:21] <andypugh> This toolchanger needs to separate tool unload and tool load (because the unload sequence without a tool loaded is crashy-bad)
[15:30:54] <andypugh> So I set up two sequences. But they can’t share output pins, so can’t both drive the hardware…
[15:30:59] <skunkworks> zlog
[15:31:47] <andypugh> Well, not without a load of “or2” components, which seems messy, but possibly unavoidable.
[15:34:38] <andypugh> And actually or2 won’t work either, that prevents sequence 1 from resetting a pin from sequence 0
[15:39:51] <andypugh> I think I might need to abandon my new sequencer.comp. Which is annoying as I put quite a bit of work into it.
[15:40:07] <mozmck> can you make them IO pins instead of output?
[15:40:57] <andypugh> It’s not that sort of problem.
[15:41:05] <mozmck> ok
[15:41:51] <andypugh> Where did he go? I was about to elaborate
[15:42:30] <andypugh> mozmck: You might get a feel for it from
http://pastebin.ca/3005713
[15:43:12] <andypugh> The problem is that I need a second sequence, but that can’t (for example) undo the effect of the first sequence.
[15:44:00] <andypugh> So, if the first sequence set the arm-in relay, the second can’t unset that relay.
[15:54:10] <jepler> hm and comp *cough* doesn't facilitate sharing output between what it thinks of as independent components
[15:54:13] <cradek> what's the basis of the problem? crashy?
[15:55:31] <jepler> if the component had just one instance and all sequences were a part of that one instance, then you could have a "last sequence to change output" wins feature
[15:59:06] <andypugh> jepler: Yes, I thought about that. It’s not a huge rewrite either.
[15:59:40] <andypugh> But I think I will ponder it some more, and in the meantime work on an all-Gcode sequence for this particular setup.
[15:59:58] <andypugh> Maybe G-code isn’t as unwieldy as I imagine?
[16:00:06] <cradek> neither is ladder
[16:00:31] <andypugh> I think Ladder would have exactly the same problem
[16:00:45] <andypugh> But then I don’t know ladder.
[16:00:49] <cradek> and I don't understand the problem
[16:00:56] <cradek> :-)
[16:01:41] <jepler> "I need to set / reset a specific output due to more than one circumstance" is handled just fine in our classicladder
[16:01:51] <andypugh> If the unlad sequence has released the tool, the load sequnce needs to be able to clamp it again (for example)
[16:02:01] <jepler> but sequential processes are cumbersome to write in ladder logic
[16:02:32] <andypugh> How does ladder handle shared outputs between different sequences?
[16:03:43] <cradek> ladder has states, but I'm not sure it has sequences unless you invent them out of states
[16:04:19] <cradek> so your question might not be the right question?
[16:04:45] <andypugh> I seem to need to be able to trigger two different sequences from G-code, and have both sequences toggle the same output buts in different ways.
[16:05:00] <andypugh> (output bits)
[16:05:04] <jepler> andypugh: in classicladder, bit outputs are changed by "coils".
[16:05:21] <jepler> andypugh: a "set coil", when it becomes energized, changes that output to TRUE and a "reset coil" changes it to false
[16:05:31] <cradek> yeah you can "send" edges to coils
[16:05:41] <jepler> if multiple set/reset coils are energized at the same time, I think there's a rule that says which one "wins"
[16:05:43] <cradek> you can also have edge triggered inputs
[16:05:55] <cradek> I think this is the simplest way to make sequences
[16:06:32] <andypugh> Well, actually, the simplest way is a custom component…
[16:06:35] <jepler> hmm these docs refer to sequential, did we actually succeed in getting sequential working in CL?
[16:06:54] <andypugh> Then you can use a proper programming language and avoid this messing about
[16:07:04] <jepler> http://linuxcnc.org/docs/html/ladder/classic_ladder.html#_grafcet_programming I glanced at this and I am unenlightened
[16:07:07] <cradek> the input -|^|- lights up on a rising edge; the output -(s)- sends a "rise" command to that output
[16:07:20] <cradek> jepler: if it works, and I doubt it does, I don't know how to use it
[16:07:24] <andypugh> grafcet ought to be ideal
[16:07:33] <cradek> s = set
[16:07:41] <andypugh> (it looks exactly like what I do in the day job)
[16:08:01] <cradek> it's funny how we all think the thing we already know is ideal
[16:08:36] <andypugh> If I was writing this toolchanger for myself it would be a custom .comp
[16:09:00] <andypugh> But I am trying to create something for a non-programmer.
[16:09:21] <cradek> I have seen a lot of custom comps that do sequencing, and they're all bad. coding state machines in C is just terrible.
[16:09:46] <cradek> ok I was wrong, a thing I already know is totally not ideal
[16:10:24] <andypugh> cradek: Compared to coding state machines in G-code?
[16:11:16] <cradek> gcode might be worse syntactically, but the fundamental uglyness is the same
[16:11:35] <archivist> function pointers to hold state in C
[16:11:41] <andypugh> A C switch seems to work well for a state machine to me.
[16:11:43] <cradek> I guess a missing case/switch statement makes it a tiny bit worse in gcode
[16:13:12] <andypugh> As this changer needs to move the head and is handshaking with HAL pins to synchronise that, perhaps G-code is the sensible way anyway.
[16:20:43] <jepler> what we "need" is to abuse C macros to help implement state machines.
[16:22:12] <andypugh> Can a subroutine typically call other subroutines?
[16:22:31] <andypugh> And is it likely to be possible to do that in a remapped G-code sub?
[16:23:20] <andypugh> Ah, never mind, I can write it all out longhand.
[16:29:34] <KGB-linuxcnc> 03Daniel Rogge 052.7 d861045 06linuxcnc 10src/emc/tp/tp.c Trajectory planner: pausing during G95 fix * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d861045
[16:29:34] <jepler> http://emergent.unpythonic.net/files/sandbox/sm.comp http://emergent.unpythonic.net/files/sandbox/sm.h
[16:30:11] <cradek> andypugh: sure gcode subs can nest or recurse
[16:30:12] <jepler> with the GCC extension of "labels as values" plus gross macros you can fake up state machines in some interesting ways
[16:30:42] <andypugh> cradek: I couldn’t make it work in a remap.
[16:31:07] <jepler> Thanks rogge, if you're watching
[16:31:14] <andypugh> I got “can’t find file O<200>”
[16:31:23] <seb_kuzminsky> thx cradek
[16:32:04] <andypugh> Actual error was “ interp_error: Unable to open file <200>”
[16:32:24] <andypugh> named sub was “interp_error: Unable to open file <reset_and_wait_for_false>”
[16:32:27] <cradek> jepler: darn I don't have a screenshot of the presettable quadrature decoder I did in ladder for my carousel
[16:32:45] <andypugh> That was with the subs defined above or below the O<toolchange> remapped sub
[16:33:25] <jepler> cradek: I actually know enough ladder to imagine what it could look like
[16:33:28] <andypugh> What is the objection to state-machines as switch statements?
[16:33:42] <skunksleep> Rob has a new job so he doesn't think he will get back to linuxcnc until the summer
[16:34:03] <jepler> -| |--|^|------[U]--- # count up in transition from 00 to 01
[16:34:11] <jepler> and 3 more lines?
[16:35:34] <cradek> aha:
http://timeguy.com/cradek-files/emc/carousel-decode.png
[16:36:38] <jepler> interesting, rather than reacting to an edge on Z you check Z on the edge of A
[16:36:43] <cradek> four ways to do down, four ways to do up, reset and preset in two magic spots in the cycle
[16:36:54] <cradek> yes because of how the sensors are set up
[16:37:07] <cradek> it's only a lot like an encoder
[16:37:19] <jepler> and having |^|--| | makes more sense even though they are probably equivalent
[16:37:44] <jepler> it would not be a bad addition to comp to synthesize _rising and _falling versions of input bits
[16:39:45] <cradek> http://timeguy.com/cradek-files/emc/carousel-reverse-is-closer.png
[16:40:05] <cradek> which way is closer to the position I want - forward or reverse?
[16:40:32] <andypugh> cradek: Well, I wrote a new comp to do generic carousels, but you wouldn’t like it, it has state machines in C.
[16:40:34] <cradek> it also auto-homes the first time (after each estop) that you seek a position
[16:41:02] <cradek> andypugh: there's an expression about skinning cats, but I like cats, so I don't use it
[16:41:52] <andypugh> I suspect that allowing Gray-code or binary, and any number of input bits is a tad easier in C.
[16:42:45] <cradek> yes I bet you're right about gray code. that could get tedious.
[16:43:32] <cradek> for binary in ladder you could just have one rung for each bit that adds 1,2,4 etc to a variable
[16:44:30] <skunksleep> That is how the k&t tool reader works in ladders
[16:45:36] <cradek> bbl, off to dinner at a restaurant that thinks it's fancier than I think it is
[16:47:17] <jepler> hah
[16:51:15] <skunksleep> In Ireland we were looking for a place to eat and found this place above a bar. We looked up the stairs and the matredee
[16:53:54] <skunksleep> Was dressed to the nines. He said come on up. I said I don't think we are dressed appropriately... He said no problem. Best meal we had there..
[16:55:35] <jepler> and was it priced accordingly?
[16:55:38] <mozmck> jthornton: One thing that would IMO make the html docs as good as the pdf, is if the contents would stay on the side of each page - like this site:
http://html.net/tutorials/html/
[16:56:58] <skunksleep> jepler: I don't remember so probably
[17:12:38] <andypugh> Hmm, so, how to get the _pocket_ number of the tool in the spindle?
[17:13:12] <cradek> andypugh: just put it back in the carousel where it came from
[17:13:28] <andypugh> How do I know where it came from?
[17:13:53] <cradek> andypugh: the right pocket is already pointed at the spindle
[17:14:32] <cradek> stick it in there, then (optionally home the carousel) and then find the pocket you want
[17:14:38] <andypugh> I guess folk need to get used to unloading the tool before powering off?
[17:14:53] <cradek> nope, it's fine if not
[17:15:07] <andypugh> (tool in spindle isn’t sticky after shutdown anyway, is it? )
[17:15:23] <cradek> it is with random turned on...
[17:15:34] <andypugh> This one isn’t random
[17:15:36] <cradek> I think
[17:16:13] <andypugh> The whole tool-array thing is a horrible mess
[17:16:32] <andypugh> Yes, tool in spindle has P-number zero with a random tc
[17:16:45] <cradek> it doesn't matter does it? if t1m6 but t1 is already loaded, it will just put it in the pocket and pull it back out
[17:18:30] <andypugh> I guess so...
[17:23:52] <andypugh> Theres’s no mod in HAL is there?
[17:25:45] <andypugh> I have this Vismach model that acts quite a lot like a real VMC with a carousel, except that the simultated position increases indefinitely and that makes the gray-code go funny in a way that absolutely wouldn’t be a problem with a real carousel.
[17:26:23] <andypugh> So it’s not worth fixing it, but….
[17:27:19] <andypugh> The answer is probably to use an updown component with wrap turned on.
[17:52:33] <andypugh> Can anyone figure out why this G-code:
http://pastebin.com/4gzMgSCt gives the error: “ interp_error: 9: duplicate O-word label - already defined in line 28: 'O200 IF [#<selected_tool> GT 0]’”
[17:54:46] <andypugh> Hmm, and now it doesn’t. But I didn’t change anything...
[17:55:26] <andypugh> Oh, no, it just did in the no-tool loaded case
[17:55:57] <seb_kuzminsky> weird
[18:03:49] <andypugh> I have not yet spotted a pattern, either
[18:55:37] <cradek> andypugh: I don't think we have mod math in hal but <whisper>ladder does</whisper>
[18:56:02] <cradek> andypugh: did you figure out the duplicate thing?
[18:56:07] <andypugh> I decided to do without:
https://youtu.be/PfZwpjUs1xI
[18:56:20] <andypugh> The dupolicate thing “went away”…
[18:56:54] <cradek> ooh cool the spindle even turns!
[18:57:11] <andypugh> It has spindle-orient :-)
[18:57:19] <cradek> wow
[18:57:57] <cradek> the yellow thing is umbrella rotation lock?
[18:58:03] <andypugh> Yes
[18:58:11] <cradek> awesome
[18:58:21] <cradek> what a great setup for experimenting with tool changes
[18:58:25] <cradek> changers
[18:58:37] <andypugh> That was the point of going to that much effort
[19:04:43] <andypugh> If you want to play with the config, the whole thing is here:
http://www.linuxcnc.org/index.php/english/forum/24-hal-components/29153-vmc-related-hal-questions#58732
[19:37:50] <cmorley> mozmck : did you return true? True means not to propagate the signal... can you show the code?
[19:44:01] <cmorley> Jepler: grafcet ladder logic worked the last time i tried it (which was a long time ago) It was a bit of a pain to edit IIRC
[19:58:03] <cmorley> mozmck: I read down more and see you found the error.
[19:59:33] <cmorley> gscreen does tend to hide errors. I believe there are debug options that will show more (way more)
[21:48:28] <mozmck> cmorley: thanks. I got my jog rates working like I wanted now. I read the MAX_VELOCITY for each axis, and fill a list with that. Then I use the jog slider to set a percentage and multiply each max_velocity by the jog_percent, and then use that rate to jog each axis.
[21:49:03] <mozmck> If you hold down the shift key first it jogs the axis at it's max velocity.
[21:49:39] <Tom_itx> nice
[21:51:12] <mozmck> I couldn't use any of the gscreen jog stuff to do that though. I like how it works. An axis that is substantially slower than the others (Z for instance) does not run at max vel this way.
[22:51:11] <pcw_home> looks like Preemt-RT kernel 4.0 has just been imported into the Debian packaging repo:
[22:51:12] <pcw_home> http://www.spinics.net/lists/linux-rt-users/msg13364.html
[22:58:17] <jepler> woo
