Back
[03:46:21] <KGB-linuxcnc> 03Michael Haberler 05unified-build-candidate-3 0e9ef9d 06linuxcnc 10(5 files in 2 dirs) Merge remote-tracking branch 'origin/master' into unified-build-candidate-3 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0e9ef9d
[03:46:21] <KGB-linuxcnc> 03Michael Haberler 05unified-build-candidate-3 cc03a7f 06linuxcnc Merge pull request #7 from cdsteinkuehler/MachineKit-ubc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cc03a7f
[03:46:21] <KGB-linuxcnc> 03Michael Haberler 05unified-build-candidate-3 3030135 06linuxcnc 10src/rtapi/rt-preempt.c 10tests/threads.0/README rtapi/posix: try to set SCHED_FIFO, and explain what to do if unable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3030135
[03:46:24] <KGB-linuxcnc> 03Michael Haberler 05unified-build-candidate-3 e3de5bb 06linuxcnc Merge remote-tracking branch 'origin/unified-build-candidate-3' into unified-build-candidate-3 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e3de5bb
[04:53:33] <linuxcnc-build> build #28 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/28 blamelist: Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, Chris S Morley <chrisinnanaimo@hotmail.com>, Chris Morley
[04:53:33] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, John Thornton <jthornton@gnipsel.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[04:53:45] <linuxcnc-build> build #28 of deb-precise-xenomai-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-x86/builds/28 blamelist: Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, Chris S Morley <chrisinnanaimo@hotmail.com>, Chris Morley
[04:53:45] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, John Thornton <jthornton@gnipsel.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[04:56:02] <linuxcnc-build> build #28 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/28 blamelist: Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, Chris S Morley <chrisinnanaimo@hotmail.com>, Chris Morley
[04:56:02] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, John Thornton <jthornton@gnipsel.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[04:56:07] <linuxcnc-build> build #28 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/28 blamelist: Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, Chris S Morley <chrisinnanaimo@hotmail.com>, Chris
[04:56:07] <linuxcnc-build> Morley <chrisinnanaimo@hotmail.com>, John Thornton <jthornton@gnipsel.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[05:25:18] <linuxcnc-build> build #1320 of deb-lucid-sim-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-sim-binary-i386/builds/1320 blamelist: Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, Chris S Morley <chrisinnanaimo@hotmail.com>, Chris Morley
[05:25:18] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, John Thornton <jthornton@gnipsel.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[05:25:38] <linuxcnc-build> build #1326 of deb-precise-sim-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-i386/builds/1326 blamelist: Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, Chris S Morley <chrisinnanaimo@hotmail.com>, Chris Morley
[05:25:38] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, John Thornton <jthornton@gnipsel.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[05:26:04] <linuxcnc-build> build #1325 of deb-precise-sim-binary-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-amd64/builds/1325 blamelist: Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, Chris S Morley <chrisinnanaimo@hotmail.com>, Chris Morley
[05:26:04] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, John Thornton <jthornton@gnipsel.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[05:27:56] <linuxcnc-build> build #155 of deb-precise-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rt-binary-i386/builds/155 blamelist: Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, Chris S Morley <chrisinnanaimo@hotmail.com>, Chris Morley
[05:27:56] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, John Thornton <jthornton@gnipsel.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[05:30:59] <archivist> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MeetingsOnIRC points to last year
[05:31:32] <archivist> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Meeting201312 also points recursively
[05:31:40] <archivist> phail
[05:42:47] <linuxcnc-build> build #1320 of deb-lucid-sim-binary-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-sim-binary-amd64/builds/1320 blamelist: Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, Chris S Morley <chrisinnanaimo@hotmail.com>, Chris Morley
[05:42:47] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, John Thornton <jthornton@gnipsel.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[05:43:06] <linuxcnc-build> build #1321 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1321 blamelist: Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, Chris S Morley <chrisinnanaimo@hotmail.com>, Chris Morley <chrisinnanaimo@hotmail.com>,
[05:43:06] <linuxcnc-build> John Thornton <jthornton@gnipsel.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[06:35:30] <jthornton> alex_joni, HI!
[08:20:50] <KGB-linuxcnc> 03Norbert Schechner 05master d8d555d 06linuxcnc 10configs/sim/gmoccapy/lathe.tbl 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py 10share/gscreen/skins/gmoccapy/release_notes.txt gmoccapy_0_9_9_9_1 - solved tool touch off bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d8d555d
[08:20:50] <KGB-linuxcnc> 03Norbert Schechner 05master f142bd4 06linuxcnc Merge branch 'master' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f142bd4
[09:00:14] <linuxcnc-build> build #1711 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1711 blamelist: Norbert Schechner <nieson@web.de>
[09:24:08] <linuxcnc-build> build #1713 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1713 blamelist: Norbert Schechner <nieson@web.de>
[10:07:54] <zultron> cradek, you're running glo, right? Looks like you turned off forced push?
[10:08:45] <zultron> Trying to decide how to avoid test branch proliferation. Maybe merge...
[10:11:08] <zultron> Whoops, seems I made that up. n/m!
[10:11:20] <KGB-linuxcnc> 03John Morris 05zultron-ubc3-dev dade4b7 06linuxcnc 10src/Makefile Makefile: install /etc files with correct permissions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dade4b7
[10:11:20] <KGB-linuxcnc> 03John Morris 05zultron-ubc3-dev 95f4392 06linuxcnc 10tests/bitops.0/test.sh tests/bitops.0/test.sh: change include dir to /include from /src/rtapi * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=95f4392
[10:11:20] <KGB-linuxcnc> 03John Morris 05zultron-ubc3-dev 094c5cf 06linuxcnc 10tests/hm2-idrom/test.sh hm2-idrom test: fix "too many arguments" error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=094c5cf
[10:11:22] <KGB-linuxcnc> 03John Morris 05zultron-ubc3-dev 5ac9e51 06linuxcnc 10scripts/realtime.in realtime.in: recursively remove kmods and depending modules at unload * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5ac9e51
[10:11:25] <KGB-linuxcnc> 03John Morris 05zultron-ubc3-dev a65b050 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c 10src/hal/drivers/mesa-hostmot2/watchdog.c mesa-hostmot2 driver: Remove int->double conversions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a65b050
[11:17:49] <linuxcnc-build> build #29 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/29 blamelist: John Morris <john@zultron.com>, Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, John Thornton
[11:17:49] <linuxcnc-build> <jthornton@gnipsel.com>, Chris Radek <chris@timeguy.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett
[11:17:49] <linuxcnc-build> <dgarrett@panix.com>
[11:18:36] <linuxcnc-build> build #29 of deb-precise-xenomai-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-x86/builds/29 blamelist: John Morris <john@zultron.com>, Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, John Thornton
[11:18:36] <linuxcnc-build> <jthornton@gnipsel.com>, Chris Radek <chris@timeguy.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett
[11:18:36] <linuxcnc-build> <dgarrett@panix.com>
[11:19:38] <linuxcnc-build> build #29 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/29 blamelist: John Morris <john@zultron.com>, Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, John Thornton
[11:19:38] <linuxcnc-build> <jthornton@gnipsel.com>, Chris Radek <chris@timeguy.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett
[11:19:38] <linuxcnc-build> <dgarrett@panix.com>
[11:19:42] <linuxcnc-build> build #29 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/29 blamelist: John Morris <john@zultron.com>, Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, John Thornton
[11:19:43] <linuxcnc-build> <jthornton@gnipsel.com>, Chris Radek <chris@timeguy.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett
[11:19:43] <linuxcnc-build> <dgarrett@panix.com>
[12:09:27] <linuxcnc-build> build #1322 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1322 blamelist: John Morris <john@zultron.com>, Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, John Thornton <jthornton@gnipsel.com>, Chris Radek
[12:09:27] <linuxcnc-build> <chris@timeguy.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[12:53:59] <owhite> Hello people. I'm using gmoccapy and it looks really great. Does anyone have experience running two monitors with 12.04? I'm wondering how difficult it is to set up one touchscreen running gmoccapy, and the other would be a "regular" desktop.
[13:50:20] <norbert> owhite: As I am coding gmoccapy, I can tell you that I do use it with a faytech 17 " Touchscreen, and it does perform fine, I never tried with two displays, but it should not give any problems.
[14:06:22] <seb_kuzminsky> zultron: hey, i saw you pushed a branch based on my seb/ubc3-deb branch,
[14:06:34] <zultron> Hi seb_kuzminsky, yes
[14:06:51] <seb_kuzminsky> be warned that i'm not done with that branch yet and i plan to rebase it to clean it up before i merge it into ubc
[14:06:59] <zultron> That's ok. Thanks!
[14:07:47] <zultron> I wanted your rsyslog.conf file so the RPM specfile can be in a more final form right now.
[14:08:01] <seb_kuzminsky> cool
[14:54:04] <seb_kuzminsky> zultron: your commit dade4b7b doesn't seem to honor DESTDIR
[14:54:11] <seb_kuzminsky> but the code you're replacing didn't either
[15:01:36] <KGB-linuxcnc> 03Chris Morley 05master 2190b97 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py gscreen -Don't automatically load the second screen glade file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2190b97
[15:01:41] <zultron> Ah, yes, thanks.
[15:02:30] <zultron> Ugh, those files...
[15:12:18] <zultron> seb_kuzminsky, what's your idea about those? Those rules install system files in a RIP build.
[15:12:37] <zultron> They're needed for the RIP build to work.
[15:13:54] <zultron> The idea behind installing them for RIP builds is so that those of us doing those won't be broken when using ubc3 for the first time.
[15:15:56] <zultron> I don't like them, though. I'd prefer something like the message from scripts/check-logging.sh
[15:17:29] <zultron> It does make sense to put them into the non-RIP install, though, like $(DESTDIR)$(sysconfdir)/rsyslog.d/linuxcnc.conf
[15:17:49] <seb_kuzminsky> those files should definitely be installed during 'make install'
[15:17:53] <seb_kuzminsky> yeah
[15:18:32] <seb_kuzminsky> i don't like it when rip's 'make' copies or creates files outside the git repo
[15:19:13] <seb_kuzminsky> i guess i prefer informative error messages when those 'system files' are missing, and let the user do it
[15:19:14] <zultron> Me neither, and it seems like abuse of sudo when doing so while running 'make setuid'.
[15:19:27] <seb_kuzminsky> i totally agree
[15:20:13] <seb_kuzminsky> 'sudo make setuid' used to be a contained disaster, but now it spils outside of the working directory and into system teritory, and that definitely violates the principle of least surprise
[15:20:16] <zultron> Ok. I'll think about it. The check-logging.sh script seems like it's doing a reasonable thing, so maybe I'll take that path.
[15:20:46] <zultron> Yes.
[15:20:47] <seb_kuzminsky> yeah
[15:20:51] <zultron> Yup.
[15:20:54] <zultron> ;)
[15:20:55] <seb_kuzminsky> uh-huh
[15:21:26] <seb_kuzminsky> maybe check-logging could be extended to something like check-sysconf, and it could look for the ulimit and other things too
[15:21:37] <zultron> That's what I'm thinking.
[15:47:59] <KGB-linuxcnc> 03Chris Morley 05master feeaf0c 06linuxcnc 03configs/sim/gscreen/gscreen_custom/gaxis_no_plot.ini 03share/gscreen/skins/gaxis_no_plot/gaxis_no_plot.glade 03share/gscreen/skins/gaxis_no_plot/gaxis_no_plot_handler.py gscreen -add a gaxis with-no-live-plot sim configuration * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=feeaf0c
[16:03:28] <cradek> zultron: do you think we should keep using syslog? it has several problems that I don't see how we can allay
[16:03:52] <cradek> (log file permissions and having to turn off rate-limiting globally)
[16:03:54] <zultron> I'd like to get rid of it, but I don't know how.
[16:04:11] <seb_kuzminsky> did you implement that part, or was it michael, or someone else?
[16:04:25] <zultron> mhaberler collects logs with rtapi_msgd. That's where it would be done.
[16:05:30] <zultron> At the moment, I think it can be told to log to either syslog or stderr.
[16:06:14] <zultron> I'd like it to also be able to log to a configurable file.
[16:06:47] <zultron> That would solve the problems you list, and also fix issues with runtests.
[16:09:27] <seb_kuzminsky> seems reasonable
[16:10:52] <zultron> Just occurred to me, as long as we're logging to a separate /var/log/linuxcnc.log file, a logrotate.d config needs to be put in packaged.
[16:11:06] <zultron> * needs to be packaged
[16:11:30] <cradek> doing it ourselves would allow us to clear/rewrite the file each run
[16:12:12] <cradek> I think it's obnoxious [with our current dmesg system, and also with syslog] to make the user have to figure out which lines came from the most recent run
[16:12:14] <zultron> Or that, yes. Similar to Xorg.*.log, perhaps, where they roll.
[16:12:25] <cradek> yeah possibly
[16:14:31] <cradek> there is no provision in msgd for doing anything but syslog [also printing to stderr, which is an option it has, is a feature of syslog]
[16:15:02] <cradek> but I really don't see anything hard about printing to a file instead
[16:15:26] <zultron> No, I've looked too.
[16:15:36] <cradek> oh hey, new xenomai kernels in the repo
[16:15:38] <cradek> neat
[16:17:17] <zultron> Was that announced somewhere? Where are they?
[16:18:11] <cradek> http://www.linuxcnc.org/dists/precise/base/binary-i386/
[16:18:22] <cradek> no, I just "noticed" their appearance
[16:18:42] <cradek> I watch all our web stuff pretty carefully for spam/sploits
[16:19:56] <zultron> Oh yeah! Someone's been hard at work. :)
[16:39:47] <memleak> ASUS released a new BIOS for my motherboard! now i can remove coreboot!
[16:39:58] <memleak> whoops wrong channel
[16:40:56] <memleak> oh seb_kuzminsky what version of ubuntu are you supposed to use with your debs?
[16:41:03] <memleak> 11.04 was it?
[16:45:38] <zultron> For non-root access to RT services, Xenomai may be configured to allow a special group.
[16:45:44] <zultron> Is there anything like this in RTAI?
[16:46:11] <cradek> well I (mostly) added log-to-file to msgd but then I find that rtapi_app calls syslog directly, so I'm kind of stumped
[16:46:44] <cradek> zultron: there are the permissions on /dev/rtai_stuff that sort of enforce that?
[16:47:04] <zultron> Yeah, that's exactly what I was asking.
[16:47:05] <memleak> chown / chmod does the trick for me if needed
[16:47:24] <memleak> for unloading and loading kernel modules though :/
[16:47:29] <memleak> that i dont know about
[16:47:29] <zultron> How is that managed currently?
[16:48:01] <cradek> loading and unloading kernel modules is done by the setuid module helper - you could enforce access control there too
[16:48:08] <memleak> ah yes!
[16:48:24] <memleak> that's perfect!
[16:48:40] <zultron> Yup, I know about that. How is access to the /dev entries managed?
[16:48:46] <cradek> udev
[16:49:25] <memleak> if available. systemd can work too
[16:49:37] <memleak> i advise against systemd however
[16:49:41] <cradek> looks like we install /etc/udev/rules.d/99-rtai.rules
[16:49:53] <cradek> KERNEL=="rtai_shm", MODE="0666" - etc
[16:50:02] <memleak> yes and with mode 666 you c.. right
[16:50:16] <memleak> that :P
[16:50:47] <zultron> Ok, world writeable, sounds good.
[17:03:34] <cradek> mhaberler: can you help me understand why rtapi_app does its own openlog instead of passing messages to msgd? [lots of context above]
[17:03:50] <mhaberler> hi cradek
[17:03:53] <cradek> hey
[17:06:10] <mhaberler> which context - any problems?
[17:08:20] <cradek> yeah we have several problems with using syslog, and I was exploring making msgd write to a file instead. that's trivial, but then I found that rtapi_app also logs, but independent of msgd
[17:08:20] <mhaberler> there are two different ways to log from app, one is via the rtapi loaded modules space, and the other one is say syslog
[17:08:54] <mhaberler> the rt logging uses a ringbuffer in shm which means rtapi and hal_lib need to be loaded
[17:09:23] <mhaberler> meaning you couldnt log through it before that is established, which is when all the important stuff happens
[17:09:31] <cradek> oh so it's a kind of bootstrap problem
[17:09:39] <mhaberler> yes, chicken and egg
[17:10:00] <mhaberler> the alternative is rather costly: a shm layer _below_ rtapi which goes first
[17:10:31] <mhaberler> can you summarize the problems with syslog?
[17:10:39] <cradek> I wonder if both could just open the logfile with fopen "a"
[17:11:34] <mhaberler> are you tallking per session logrotation?
[17:12:12] <cradek> well two are stupid bugs in rsyslog: if using directory.d/ config files, you can't actually set the permission of the generated log files; also rate limiting - which we had to disable or at least defang - applies to all logs
[17:12:41] <cradek> the per-session problem is minor but yes it's another advantage to writing to our own files
[17:12:59] <cradek> also zultron has a runtest-related problem where syslog is a pain (I don't know these details)
[17:13:31] <cradek> in general I don't see any advantage to using syslog, and many problems (most are rsyslog defects)
[17:14:12] <mhaberler> I do remember Seb advocating syslog on the list big time, so why dont you guys make up your mind first..
[17:16:12] <zultron> Hey, drive-by comment: runtest problem is related to how stderr/stdout are handled. msgd writing to a file would fix things, or fixing runtests to separate debug output to stderr from 'results' output would work, too.
[17:18:40] <mhaberler> I took
http://sourceforge.net/mailarchive/message.php?msg_id=30533761 as reasonable and went with it
[17:28:28] <cradek> well, if you'll read down you'll see the disagreement I registered. I think the blame is mostly with the irritatingly-defective rsyslog, but you can declare fault wherever you please, I don't care. I bet seb is mature enough to handle having been wrong and/or not predicting the future accurately.
[17:31:15] <mhaberler> fair enough - so I'll continue to use the syslog protocol and am happy to have users use the syslog demon of their choice, which are two completely different issues
[17:32:53] <cradek> what precisely is your reason to want to continue using it?
[17:37:34] <zultron> At the risk of being burned for butting into an argument, I think configurable output to syslog, stderr or a named file all could be desirable, depending on the use case.
[17:37:36] <mhaberler> not sure this is a serious question?
[17:40:54] <cradek> Sure it is. I've described several problems with using syslog. The reason so far you've said you want to continue using it is seb told you to. I would like to know the real reasons.
[17:41:35] <cradek> zultron: that's what I've already mostly added, just this multiple-openers thing threw me a bit. I'm not sure if two processese can fopen "a" the same file, but if so, no problem.
[17:42:47] <cradek> zultron: (the changes to msgd are really minor)
[17:43:24] <cradek> I'd prefer that we all agree on an approach that solves all the problems
[17:44:53] <cradek> zultron: (you're not butting in, and I don't see any need for arguing; we all have the same goals)
[17:47:54] <mhaberler> No, I prefer you come up with a significantly improved solution if you find one because I dont see that as relevant to the problems at hand, so I'm not inclined to discuss such minutiae because I think it is a waste of time
[17:49:09] <cradek> my significantly improved solution is to write to a certain file instead of going through syslog, because that solves all the problems at once, and is very easy.
[17:49:33] <mhaberler> fine, send a pull request
[17:49:43] <mhaberler> sorry, got to go for the day - cu
[17:51:22] <Tom_itx> developers.
[17:52:52] <cradek> zultron: do you know about how multiple fopens in append mode would work, or do you see a better answer?
[17:53:08] <Tom_itx> same file handle?
[17:54:00] <Tom_itx> doesn't each append issue a temporary file lock until it's done?
[17:54:26] <Tom_itx> and each fopen is assingned a separate handle
[17:54:29] <cradek> I don't think there's any locking
[17:54:40] <Tom_itx> at least that's my understanding of it
[17:56:04] <mozmck> http://stackoverflow.com/questions/1842909/fopen-two-processes
[17:56:36] <cradek> yuck. (thanks)
[17:57:29] <cradek> I think messages could get intermingled
[17:57:37] <Tom_itx> agreed
[17:57:42] <mozmck> I guess that's where a daemon is handy - it can handle all the file IO and take messages from many processes.
[17:57:56] <mozmck> Maybe we should write a daemon! :)
[17:58:06] <cradek> yes and msgd is almost that - except there's a bootstrap problem
[17:58:49] <Tom_itx> it would somewhat depend on the c implementation
[17:58:54] <mozmck> yad - yet another daemon
[18:00:17] <cradek> seems like we could just use blocking advisory locks. these are userland processes.
[18:00:32] <Tom_itx> would multiple processes be accessing the file at once?
[18:00:42] <cradek> writing to - yes possibly
[18:00:54] <Tom_itx> open it, write the error, close it
[18:01:08] <cradek> that does not solve the problem
[18:01:10] <Tom_itx> does fopen check to see if it's open? probably not
[18:01:15] <Tom_itx> i know
[18:04:11] <Tom_itx> http://stackoverflow.com/questions/17665788/can-i-fopen-with-shared-read-write
[18:06:19] <cradek> interesting, man 2 open / O_APPEND implies but doesn't explicitly say that corruption will not occur if not using nfs
[18:06:50] <cradek> it implies there is no race between the seek and write
[18:07:14] <cradek> like kids say "I need an adult!", I need a real programmer :-/
[18:07:35] <Tom_itx> don't ask in #c they'll just talk over your head
[18:07:48] <cradek> it's a unix question, not a c question
[18:07:58] <Tom_itx> i've never tried fopen stuff in a shared environment
[18:09:40] <Tom_itx> http://linux.die.net/man/2/flock
[18:10:02] <cradek> aha man 2 write: "The adjustment of the file offset and the write operation are performed as an atomic step."
[18:10:05] <Tom_itx> if it sees a lock, retry
[18:10:55] <Tom_itx> i would think it to be good to lock _just_ before the write
[18:37:57] <Tom_itx> good to use fsync() as well
[18:38:05] <Tom_itx> to flush the buffer
[18:38:53] <Tom_itx> or fdatasync
[19:54:16] <KimK> May I interrupt for a short Ubuntu/Debian install question? I know there is a way to export a list of installed packages from a first install, and then auto-install those packages on a second install. Is there a way to export a list of hardware/drivers/setup/whatever from a first install, and then install for that hardware/those drivers/etc on a second install? The reason I'm asking is...
[19:58:26] <KimK> ...I borrowed a hard drive from another system to shink the install and add partitions for more OSs. Rather than returning the HDD to the original system and then installing as usual, I was wondering if I can do the installs on the borrowed PC, but install *for* the final PC? Is that possible? (I've had mixed results with dpkg-reconfigure, etc., etc.) Advice and suggestions appreciated.
[20:00:07] <KimK> (All the OSs to be installed are apt/deb, Ubuntu/Kubuntu/Debian/etc.)
[21:22:44] <cradek> KimK: do I understand right: you want to move not package lists, but manually-made settings, from one OS distro to another?
[21:24:07] <KimK> Well, if manually-made-settings means whatever the original install decided to do to enjoy its original hardware.
[21:24:41] <cradek> hm, but you do mean from one particular distro to another?
[21:27:13] <KimK> Yes. Although I never thought about only installing only the same distro. That probably wouldn't work in this case anyway, a later upgrade might be as likely to cause trouble as not.
[21:28:55] <cradek> I don't really know of any way to do that, sorry. you could clone the whole system exactly, or extract the list of installed packages (like you said) but I think those are the only two approaches
[21:29:00] <KimK> What is happening is that I have 10.04 (only) installed on that machine now, and I would like to make room for (at least) 12.04, 14.04, maybe others?
[21:29:28] <cradek> you can't just add a drive?
[21:32:20] <KimK> OK, thanks, I wondered if that might not be the case. Thanks for thinking about it anyway. Yes, I could install a drive, but I'd have the same problem, I couldn't load it here now (for *that* hardware). But that's OK, it can wait a little while, and then install in the usual way. (The weekend will be over soon enough, lol.)
[21:33:20] <cradek> modern distros are pretty tolerant of changing hardware under them
[21:33:50] <KimK> It looks like you guys are making good progress on many fronts, scrolling back above.
[21:36:54] <KimK> I would like to give another try to the Seb's install (was it rt_preempt? I forgot), in whatever form it is since I quit trying to install it some months ago. I'm sure it's better since then. I'll have to ask Seb about it. Maybe the xenomai install I have is stale now too?
[21:38:10] <cradek> yeah I'm not the one to ask. I installed the new rtai and ran hardware with it. I have not run hardware with any of the new rt styles.
[21:38:14] <KimK> Those I can work on now, since I have access to them.
[21:39:30] <KimK> Yes, I forgot if the "Seb's debs" install was for rt_preempt or rtai. Maybe it was rtai?
[22:30:19] <cradek> zultron, seb_kuzminsky:
http://timeguy.com/cradek-files/emc/0001-POC-Log-to-a-file-cleared-each-run-instead-of-syslog.patch
[22:30:50] <cradek> er crap, I need license statements
[22:30:56] <cradek> don't push that anywhere yet
[22:32:27] <cradek> there are two paths to contemplate: if we also still want syslog support, I have to add some stuff; if we don't, I have to remove some stuff.
[22:36:20] <cradek> I am getting this [with or without my changes]:
[22:36:21] <cradek> msgd:0: rtapi_app exit detected - shutting down
[22:36:21] <cradek> :28209:user RTAPI:0 ERROR: munmap(0x00414c32) failed: Invalid argument
[22:36:21] <cradek> normal shutdown - global segment detached
[22:36:40] <seb_kuzminsky> good evening folks
[22:36:44] <cradek> hey
[22:36:59] <seb_kuzminsky> that was me that pushed the xenomai debs
[22:37:12] <zultron> Nice POC.
[22:37:17] <seb_kuzminsky> i'm impressed you pay close enough attention that you noticed right away
[22:37:24] <zultron> I definitely want to keep syslog support.
[22:37:44] <zultron> That's a lot of work going on over there, Seb!
[22:37:50] <seb_kuzminsky> eh, it
[22:38:03] <seb_kuzminsky> it's mostly your work - i used your awesome kernel builder
[22:38:25] <zultron> And it would be great to keep everything configurable.
[22:39:07] <cradek> ok, I can sure accept that
[22:39:15] <zultron> Can the 'logfd' param be hidden in rtapi_syslog.c?
[22:39:34] <zultron> Is there ever a need for more than one logfd at a time?
[22:39:51] <cradek> I think no, because they'd all wrongly share it
[22:40:04] <cradek> well help me think this through
[22:40:14] <zultron> Who're 'all'?
[22:40:27] <cradek> my thinking is that each process has to open the file, and will get a different fd
[22:40:39] <zultron> I know about the chicken-and-egg problem, if that's what you mean
[22:40:47] <cradek> rtapi_msgd and rtapi_app both open the (same) log file separately
[22:40:56] <zultron> But don't understand it well enough.
[22:41:07] <seb_kuzminsky> cradek: if you statically link rtapi_syslog.o, it can use a static global for the fd
[22:41:19] <seb_kuzminsky> if it's dynamic you need something more complicated
[22:41:26] <seb_kuzminsky> err, if it's dynamically linked, i mean
[22:41:39] <zultron> Is that the chicken+egg problem, that the two both open the same log separately?
[22:42:12] <cradek> seb_kuzminsky: oh of course you're right - it's linked in to both programs
[22:42:33] <cradek> I will fix that
[22:43:10] <seb_kuzminsky> isnt there some special kind of segment for "link-local" globals, in shared libraries? (i'm way out of my depth here, in case it's not obvious)
[22:43:13] <cradek> zultron: my understanding is that both processes need to log, but rtapi_app can't log through rtapi_msgd
[22:44:18] <zultron> My understanding (not from looking at the code) is rtapi_app must log separately until the global shmem segment is established, after which it can log through rtapi_msgd.
[22:44:28] <cradek> that sure could be
[22:45:11] <zultron> But I'd have to go dig around before I could think meaningfully about how to solve this problem, if there actually is one.
[22:46:27] <cradek> requiring less digging: would you verify my vsnprintf/strcat/strlen don't-overflow stuff
[22:47:54] <seb_kuzminsky> cradek: i think you can print one more byte in your vsnprintf:
[22:48:11] <seb_kuzminsky> snprintf() and vsnprintf() do not write more than size bytes (including the terminating null byte
[22:48:14] <seb_kuzminsky> from the manpage
[22:48:25] <cradek> seb_kuzminsky: that byte is for the strcat
[22:48:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 7363fe7 06linuxcnc 10debian/rules.in deb/rules: drop the self-remaking parts * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7363fe7
[22:48:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 532c94a 06linuxcnc 10debian/rules.in deb/rules: remove unused python_version * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=532c94a
[22:48:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 3a63703 06linuxcnc 10debian/rules.in deb/rules: dont need to care about BUILD_SYS * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3a63703
[22:48:41] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 979ec6e 06linuxcnc 10debian/.gitignore deb: dont ignore package-dirs we no longer build * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=979ec6e
[22:48:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb d4a757d 06linuxcnc 10(16 files) deb: new debian/configure and debian/control* * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d4a757d
[22:48:48] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 8269ba6 06linuxcnc 10(6 files in 2 dirs) add a linuxcnc-test.deb, with all the tests in it * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8269ba6
[22:48:52] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 7e679f9 06linuxcnc 10debian/configure deb/conf: accept -a to mean -r * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7e679f9
[22:48:56] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb a5ee66a 06linuxcnc 10debian/control.in deb/control: get rid of ancient Provides in control * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a5ee66a
[22:49:00] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb ae6280a 06linuxcnc 10debian/control.posix.in 10debian/control.rtai.in 10debian/control.rtpreempt.in deb/control: relax the Conflicts * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ae6280a
[22:49:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 795a4b7 06linuxcnc 10debian/rules.in deb/rules: dont use cpio when cp will do * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=795a4b7
[22:49:08] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb ae5f899 06linuxcnc 10debian/linuxcnc.files.in 10src/Makefile install rsyslogd.conf file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ae5f899
[22:49:12] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 31dc5d4 06linuxcnc 10src/configure.in 10src/rtapi/ulapi_autoload.c give dlopen the path to the ulapi library * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=31dc5d4
[22:49:16] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb d7a8469 06linuxcnc 10src/Makefile 10src/rtapi/Submakefile put ulapi-$flavor.so straight into rtlib/, not lib, so the dlopen can look in EMC2_RTLIB_DIR * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d7a8469
[22:49:24] <seb_kuzminsky> cradek: oh, right
[22:49:40] <seb_kuzminsky> i think i'm too tired to be of use tonight :-/
[22:50:29] <seb_kuzminsky> but i think the xenomai buildslaves are one step closer to making debs now - the xeno debs are in the linuxcnc.org deb archive, and the buildslaves have proper pbuilder chroots for it
[22:50:35] <seb_kuzminsky> we'll see what breaks next
[22:50:41] <cradek> that's really great
[22:51:44] <zultron> Looks fine to me, the strcat/strlen stuff.
[22:51:51] <cradek> thanks
[22:52:02] <cradek> that stuff always deserves n extra looks
[22:52:53] <zultron> I sometimes try to be clever (at others' expense) by omitting the 'if(len >= MAXSYSLOGLEN-1)'
[22:53:16] <zultron> But that saves more typing than anything else.
[22:53:21] <cradek> yeah, I wrote what the manpage said, as directly as possible
[22:54:42] <zultron> seb_kuzminsky, this buildbot business is like whack-a-mole.
[22:54:58] <zultron> Wait 'til Debian/Ubuntu hit you with systemd.
[22:55:22] <seb_kuzminsky> zultron: how's y'alls buildbot coming along?
[22:55:57] <zultron> my buildbot is sometimes awesome, mostly breaky. It's firming up.
[22:55:59] <cradek> is systemd a clever way to break recovery mode boots, chroots, and other stuff?
[22:56:41] <zultron> I think this temp link works from the outside:
http://junction.ext.zultron.com:8010/
[22:57:00] <cradek> nope
[22:57:19] <zultron> Oh, try leaving off the port number, I think I changed that some time back
[22:57:41] <cradek> nope, not that either
[22:57:52] <zultron> Ah well. Another thing to fix.
[22:58:01] <cradek> moles!
[22:58:55] <zultron> systemd looks pretty cool. Like init, but everything looks integrated: cgroups, udev, etc. etc.
[23:01:50] <zultron> Threw me for a real loop first by setting memlock separately from /etc/security/limits.d, then again with cgroups and rtprio.
[23:02:32] <zultron> There's a faction in Debian pushing for it, so brace yourselves.
[23:11:51] <memleak> /etc/security/limits.conf ?