Back
[00:06:46] <seb_kuzminsky> cmorley: i wouldn't say we "decided on debian" exactly, it's just that someone who likes debian (cradek) made a live+install cd, but no one made one for ubuntu (yet)
[00:08:09] <seb_kuzminsky> cradek: fair enough
[00:22:09] <seb_kuzminsky> cmorley: i installed libgtk2.0-doc on lucid and found this in /usr/share/doc/libgtk2.0-doc/gtk/gtk-migrating-GtkBuilder.html:
[00:24:21] <seb_kuzminsky> "GtkBuilder will not accept duplicate object ids."
[00:24:50] <seb_kuzminsky> seems like it only checks within a single .glade file, and misses the duplicate ids if they're in different .glade files
[12:02:35] <cradek> should linuxcnc-dev depend on build-essential or similar? comp doesn't run because there's (at least) no make
[12:02:58] <cradek> build-essential is enough to make it work (on debian/rtai)
[12:18:23] <ssi> is it possible to bind a function in axisrc to either a hal pin or the machine enable button in axis?
[12:25:53] <cradek> hmm, back up - what problem are you trying to solve by doing that?
[12:26:24] <ssi> I need to somehow unhome all axes and switch out of teleop mode on machine disable
[12:26:38] <ssi> if the drives are disabled, the gantry has a natural tendency to want to pull out of square
[12:26:59] <cradek> http://linuxcnc.org/docs/html/config/ini_homing.html#_volatile_home
[12:27:12] <ssi> OOO
[12:29:39] <ssi> yeah, that solves it completely, thanks :D
[12:32:47] <jepler> it's a debian faux pas to ever build-depend on build-essential.
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps https://lintian.debian.org/tags/build-depends-on-build-essential.html
[12:33:13] <jepler> (though the policy manual says "can be omitted")
[12:33:18] <jepler> (not "must be")
[13:58:55] <cradek> ok
[13:59:07] <cradek> I'll just add it to my cd separately, then
[13:59:14] <cradek> thanks for googling for me
[14:02:18] <cradek> Package glade-3 is not available, but is referred to by another package.
[14:02:18] <cradek> This may mean that the package is missing, has been obsoleted, or
[14:02:18] <cradek> is only available from another source
[14:02:18] <cradek> However the following packages replace it:
[14:02:18] <cradek> glade-gtk2
[14:03:00] <jepler> cradek: you want the binary package glade-gnome
[14:03:07] <cradek> oops, thanks
[14:03:13] <jepler> the source package is glade-3, the binary packages include glade-gtk2 and glade-gnome
[14:03:20] <jepler> glade-gnome depends glade-gtk2
[14:03:25] <jepler> stepconf, at least, uses widgets only found in glade-gnome
[14:04:59] <cradek> but this is also what fixes gladevcp?
[14:10:37] <jepler> as far as I understand it, this is what allows editing gladevcp files
[14:10:47] <jepler> if something's broken about just using them, that's news to me
[14:12:00] <cradek> cool, glade-gnome seems to be working, it's building
[14:31:39] <cmorley> stepconf in 2.6 doesn't use glade-gnome afaik
[14:34:16] <cmorley> seems like such a stupid move by gnome to make glade-builder even pickier about widget ids - kinda takes some of the advantage of separate glade files away...
[14:38:36] <jepler> (well yes, besides this other thing which is broken :-/ but nothing fixes that but us fixing our software)
[14:38:54] <jepler> (saying, "let's get gnome to fix their bug instead" is going to turn out to be .. quixotic)
[14:39:56] <cmorley> Seb_kuzminsky: advertising that 'debian 7' is the 'preferred way' is - effectively - linuxcnc choosing to switch distributions.
[14:40:26] <cmorley> jepler: oh I agree about gnome - nothing we can do about them
[14:40:55] <jepler> cmorley: the duplicate id issue affects ubuntu 12.04 and 14.04 users too, the debian 7 thing is also a tangent or red herring
[14:41:18] <cmorley> yes I know
[14:41:22] <jepler> OK
[14:43:31] <cradek> cmorley: thanks for working on it
[14:46:54] <cmorley> well i haven't done much yet but will try to get to it soon. Its annoying - as the new updated version was made because they dumped gnome widget and libglade then had bugs in the replacement widget... so I used the tabbed widget cause it will 'always' be available.. and so on... :)
[14:47:18] <jepler> that's why people like me live in mud huts and only write software in Tk
[14:47:29] <cmorley> lol
[14:47:32] <jepler> they're never going to take away one of the three widgets that actually exist in TK
[14:47:38] <cradek> I bet athena is pretty stable by now
[14:47:59] <cmorley> yes stale is pretty stable...
[14:49:16] <cradek> [there's an updated debian image on www.linuxcnc.org]
[14:49:35] <cradek> should fix editing gladevcp panels, and comp
[14:51:14] <cmorley> k thanks I will download it...
[14:51:38] <cmorley> Then at least I can see whats broken in stepconf :)
[14:59:42] <jepler> if every file was built from its own gtk.Builder() would the duplicate name problem be moot?
[15:00:38] <jepler> the docs make it sound as though the names are local to the Builder objects
[15:01:58] <cradek> cmorley: I had the same thought, but I couldn't make it work
[15:02:07] <jepler> cradek: darn and drat, then
[15:02:44] <cradek> well I might be incompetent
[15:24:49] <pcw_home> does master work on ubuntu 14.04 now?
[15:25:39] <pcw_home> there was some TK/tcl version issue before IICRC
[15:37:03] <jepler> I have lightly run master branch (including axis) on a 10.04 machine
[15:37:04] <jepler> er, 14.04
[15:39:09] <jepler> on some system where I was building linuxcnc recently there was a problem due to the version of tcl-dev installed
[15:39:16] <jepler> .. it has to match what python uses in tkinter
[15:39:22] <jepler> but I didn't note the details
[15:39:43] <pcw_home> OK I will try then (14.04 has a new enough defualt kernel that it works on Baytrail MBs)
[15:40:35] <jepler> as far as I could see there is no -rt kernel, and the rtai kernel we build is the same kernel version on ubuntu 14.04 as debian 7 afaik
[15:42:03] <pcw_home> I just want it to boot without a fight, I can build a preemt-rt kernel
[15:44:50] <jepler> heh, point taken
[15:49:16] <KGB-linuxcnc> 03Jeff Epler 05master 00f21c3 06linuxcnc 10scripts/latency-test latency-test: restore executable bit list at 30000be * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=00f21c3
[15:52:04] <cradek> oops is that 2.6 breakage?
[15:53:09] <skunkworks_> pcw_home: debian wheezy seems to run good on the gigabyte boards...
[15:54:40] <pcw_home> I have the on a USB stick ready to try but didnt want to mess up my test station quite yet
[15:55:33] <skunkworks_> (you just can't boot rtai...)
[15:56:06] <jepler> cradek: don't think so
[15:56:50] <jepler> 2.6 does not contain 30000be
[16:23:32] <jepler> cradek: it was not due to your removal of wrong +x, somehow my editor sabotaged me when I edited the script, and I didn't notice it
[16:23:41] <jepler> I wonder if git gui even showed it to me
[16:28:49] <cradek> oh ok
[16:29:30] <cradek> yay my sherline has nice switches and wheel now, for touchy
[16:29:50] <cradek> I guess I'm the pluto-servo maintainer now
[17:02:55] <skunkworks_> heh
[17:12:29] <skunkworks_> looks like you can still buy them.. (although you are crazy not to go mesa)
[17:19:18] <cradek> there's actually a bug that I'd like to fix: if you try to load pluto_servo (which programs the pluto) with the pluto's power off, you get the "Failed to communicate with pluto-servo board after programming firmware" error. that's expected.
[17:19:34] <cradek> what's not expected: if you then turn it on, you continue to get that error until you reboot.
[17:20:22] <cradek> I thought it was an obvious problem (lack of hal_parport_release on the first failure) but nope, comp does that automatically
[20:06:06] <jepler> cradek: the port must be left in a different state than at power-up. maybe EPP mode? maybe state of some output?
[20:19:39] <pcw_home> You do need the control pins set to the proper idle EPP state before starting EPP operations
[20:21:23] <pcw_home> (EPP mode is weird, the EPP handshake works automatically but you can still twiddle the control output bits like PS2 mode)
[20:28:10] <jepler> pcw_home: iirc, the pluto-p programs in SPP mode then switches to EPP mode to run
[21:18:22] <cradek> jepler: I bet you're right. The piece of the puzzle I didn't recognize was that in normal operation (starting linuxcnc several times with the pluto powered on), the subsequent programmings may still fail, but you never notice because it's already programmed.
[21:28:37] <pcw_home> Looks like a problem with simulator builds on master (it builds uspace which naturally has real time errors on a normal system)
[21:34:34] <skunkworks> https://www.youtube.com/watch?v=EwtRWZidh1U
[21:38:03] <skunkworks> logger[
[21:38:08] <skunkworks> logger[psha]:
[21:38:09] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-08-04.html