Back
[09:09:24] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes9 9e7e955 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9e7e955
[09:15:28] <Balestrino> i made a pull request for a fix to iconview.py
[09:18:34] <cradek> sweet, dgarr merged his stuff
[09:22:20] <jepler> does anyone know what "man page compiler warnings" dgarr means?
[09:24:20] <jepler> hm maybe something while generating pdf man pages, which I don't typically do?
[09:24:46] <cradek> look at a buildbot build?
[09:26:53] <jepler> > ./man9/lineardeltakins.9:35: warning [p 1, 5.5i]: can't break line
[09:27:16] <jepler> cradek: good idea
[09:31:15] <skunkworks> jepler, I understand the scaryness of adding m98/99. From my perspective it is such a common gcode. In my little stint running commercial cnc - I used it a lot.
[09:31:59] <skunkworks> people are comfortable with it.
[09:36:54] <skunkworks> spell checking installed - yay :)
[09:37:57] <skunkworks> (irc breaths a sigh of relief..)
[09:42:38] <seb_kuzminsky> skunkworks: are there m98/m99 patches anywhere?
[09:42:50] <cradek> the branch
[09:43:20] <skunkworks> zoltron/m98m99 (sp)
[09:43:27] <cradek> KGB-linux> John Morris zultron/m98m99 26e3f93 linuxcnc (43 files in 11 dirs) Fanuc-style m98/m99 subroutines
[09:43:43] <cradek> heh, you were faster
[09:43:48] <skunkworks> and wrong...
[09:44:05] <cradek> a common compromise
[09:44:14] <skunkworks> :)
[11:29:45] <mozmck> Is there any reason to display dmesg when an error occurs using linuxcnc-uspace?
[11:32:57] <seb_kuzminsky> mozmck: not usually
[11:33:21] <seb_kuzminsky> most uspace errors should be in the linuxcnc logs rather than the kernel log
[11:38:42] <jepler> yes seb_kuzminsky is right
[11:43:53] <pcw_home> sometimes its useful to detect system issues that cause real time problems but thats about it
[11:46:41] <mozmck> Ok. When an error occurs a window is popped up with dmesg output.
[11:47:15] <mozmck> Any pointers to where that code is so I can fix it?
[11:47:49] <jepler> probably scripts/linuxcnc.in
[11:48:28] <Roguish> hey guys: another reason for 64bit
http://linux.softpedia.com/blog/google-decides-to-end-support-for-google-chrome-on-32-bit-linux-oses-496934.shtml
[11:48:44] <mozmck> Are the linuxcnc logs just ~/linuxcnc_debug.txt and ~/linuxcnc_print.txt?
[11:49:15] <mozmck> Roguish: just one more reason to not use google anything IMO :-)
[11:49:38] <jepler> Roguish: if a supported 64-bit version is important to you, then find ways to pitch in and work on it.
[11:50:04] <jepler> each real-time kernel is a huge increment of work for us, and each distribution image similarly is a huge increment of work
[11:50:38] <Roguish> just an FYI, nothing more......
[11:50:46] <jepler> I frequently have trouble because I read fellow users' remarks as grousing that *I personally* don't volunteer more of my time to scratch their particular itch
[11:51:12] <jepler> but the truth is, I've actually spent many hours (several years ago now) making sure linuxcnc is actually quite solid on 64-bit systems
[11:51:19] <Roguish> jepler: you guys are are HEROS as far as I feel.
[11:51:48] <jepler> the remaining problem is packaging kernels and building distribution images and frankly THOSE GUYS who do evejust one image every 2 years are HEROES compared to me
[11:52:28] <jepler> even just one image
[11:53:03] <Roguish> and mozmck is right also. GOOGLE is now the evil empire, incarnate.
[11:53:10] <jepler> well thanks for listening to me complain for a minute anyway
[11:54:31] <Roguish> jepler. i saw a couple of comments over the last few days/weeks about adding new gcodes, etc. seems like lots of effort for small return. feature creep.
[11:55:29] <jepler> anyway, it's safe to say that changing anything I do in LinuxCNC because of requirements of commercial software is way down the list and possibly has a negative value to me
[11:57:32] <jepler> and fwiw I'm pretty sure 32-bit uspace would run on a 64-bit premmpt-rt kernel
[11:58:12] <Roguish> a rock solid core application is more important than bells and whistles, and scratching everyone's itch is super time consuming. not just now, but in the future support as well. most people don't think very far down the road about maintenance. so, i vote (if i have vote) is for less glitz.
[11:59:13] <archivist> I second that
[11:59:17] <Roguish> I am trying a little 64 bit. I just installed a 64bit jessie, with vanilla mate, and the rtai-5. and it even works.
[11:59:29] <jepler> that's excellent news
[12:00:00] <jepler> it's been many years since I tried 64-bit RTAI but my deve machine is 64-bit PREEMPT-RT
[12:00:15] <mozmck> Yes! I've used preempt-rt 64 bit some, and it works fine.
[12:01:17] <jepler> I wonder what fraction of our users have machines without "long mode" support these days
[12:02:53] <Roguish> what is the preferred image posting site now? is it still pastebin? or ????
[12:03:32] <jepler> I dunno, I usually post screenshots through my personal website but that is not helpful for anybody else
[12:06:10] <mozmck> Roguish: I've been using
http://pasteboard.co/
[12:06:13] <pcw_home> even Atom 330s are 64 bit I guess you need to get back to P3s/early P4s for 32 bit hardware
[12:06:25] <mozmck> It's super easy to use.
[12:15:20] <jepler> I don't know if it's bad metadata or not, but on newegg if you brose Processors - Desktops and choose "Condition: New" you get 144 SKUs. In the search refinement area there's a checkbox for "64-bit support" which gives only 92 SKUs. There's no checkbox for "not 64-bit support" so I can't easily check if they're right about the balance *not* having it
[12:18:18] <pcw_home> I think almost any (non embedded) X86 less than 10 years old is 64 bit capable
[12:18:25] <mozmck> yeah, it probably depends on what fields they populate
[12:19:39] <mozmck> I've seen those kind of filters be inaccurate before - they are only as accurate as the information they put in.
[13:18:39] <jepler> yeah, I checked the lowest-price AMD and Intel CPUs on newegg and both are 64-bit
[13:18:56] <jepler> newegg's site is not particularly quick to load
[13:33:23] <Roguish> jepler. the predominant cpus now are 64. if a hobbiest insists on pulling out an old IBM XT or something (how about a $5 RPI), it's just too bad. virtually all necessary hardware (SBC, mem, ssd, etc..) are cheap, really cheap.
[13:35:42] <cradek> if we don't have 32 bit installs, I'm pretty sure I won't ever be able to upgrade any of my three actual machines
[13:36:47] <cradek> they are currently ubuntu10, ubuntu10, wheezy
[13:41:57] <Roguish> i'm not saying dump 32, just that 64 is important too.
[13:42:33] <jepler> but imagine for a moment that our CD making effort level remains constant, instead of doubling
[13:42:35] <Roguish> I can't contribute any programming, but I can check stuff out.
[13:42:37] <jepler> so that we can offer just one CD image
[13:43:13] <cradek> if we have just one image, it should be 32 bit
[13:45:12] <Roguish> I get it. if someone wants/needs 64 there just should be a fairly easy means. scripts work pretty well. i pieced together the install from numerous docs.
[13:46:57] <Roguish> oh well, i don't mean to be a nag. next time i install i'll try and keep a record of commands and such.
[13:48:40] <jepler> having up to date information in documentation is good
[13:49:18] <Roguish> and JT is doing GREAT !!!!!!!!!!!!
[13:50:14] <jepler> and if you are able to do tasks like build kernels and rtai, you clearly have an experience level that would enable you to learn more about Debian-style packaging. Making an apt-get installable package of kernel (and rtai if appropriate) is one big hurdle on the way to having an installer image.
[13:51:04] <jepler> also you woulnd't have to learn much to contribute directly to the documentation
[13:51:27] <Roguish> you're trying to suck me in to some work...........
[13:51:37] <jepler> I didn't expect to fool you about that.
[13:52:30] <Roguish> i'll take it under advisement, and strongly consider it. If I do, you'all gotta be patient.
[13:55:38] <jepler> great. For my part, I am trying to be more encouraging than I have in the past, because our current strategies for developer "recruitment", in which I drive them away either by silence or by unconstructive criticism of their work is not a great strategy.
[13:55:55] <jepler> but it is an easy rut to find yourself in, as a greybeard of a project :-/
[13:56:33] <Roguish> i have a very thick skin.
[13:57:16] <jepler> yes, and in a lot of online communities that's basically mandatory. I think we'd be better off if that weren't the case, though.
[13:57:40] <Roguish> i'm just a dumb ass mechanical engineer that likes playing and making things move around. my programming is Fortan IV
[13:58:08] <mozmck> I can probably contribute as well. I've built kernels quite a bit including debian (ubuntu!) packaging.
[13:58:09] <Roguish> don't drop the box of cards either. it's a bitch to get 'em all back in order.
[13:58:36] <jepler> I thought the card sorter could use the line numbers to fix that
[13:59:02] <mozmck> Unfortunately I found wheezy to be too unfriendly for newbies, so I've been working with xubuntu 14.04
[14:00:02] <Roguish> if there are line numbers. after a lot of edits and inserts and such the sorter isn't much use. and a box held 1000 cards, if i remember correctly.
[14:01:53] <Roguish> mozmck. i don't find it any more hostile than others. just has peculiarities.
[14:03:33] <jepler> When it comes to Ubuntu vs Debian "friendlyness", it makes me wonder: why are xubuntu and xfce on Debian so far apart in this respect? In an ideal world, Ubuntu upstreams their fixes, including "papercut" fixes, back to xfce, and then Debian gets them when they take a fresh version of xfce in their next stable release
[14:03:47] <jepler> Is Ubuntu not successfully upstreaming their patches, and if not why not?
[14:04:30] <mozmck> I don't think it is really patches. A lot of it has to do with small details of setup.
[14:05:17] <jepler> if it's about config files then the "upstream" for those changes would be Debian itself
[14:05:51] <mozmck> Plus, wheezy is a bit old, so the versions of xfce are newer in xubuntu 14.04, and there are some nice things added.
[14:07:57] <jepler> Debian's policy says "If changes to the source code are made that are not specific to the needs of the Debian system, they should be sent to the upstream authors in whatever form they prefer so as to be included in the upstream version of the package." though I can't say I'm close enough to the project to really understand how this translates to practice
[14:08:02] <jepler> https://www.debian.org/doc/debian-policy/ch-source.html#s4.3
[14:08:53] <mozmck> I need to play with Jessie some more. If I can make tweak the installer using pre-seeding it might be a good/better option.
[14:09:21] <jepler> I failed to find whether Ubuntu has similar wording about upstreaming changes
[14:09:22] <mozmck> One thing I have seen for years is that ubuntu has had better hardware support out of the box than debian.
[14:09:35] <jepler> but I know less about where to look for information about Ubuntu development practice
[14:09:52] <jepler> the default Debian images do into include non-Free firmware.
[14:10:27] <mozmck> I think some/many of the changes I'm thinking of would not be in the source code, but just configuration, and package selection.
[14:10:32] <jepler> other than hardware that requires non-Free parts to operate, I think they have rough hardware support parity
[14:11:01] <mozmck> Yes, I know. I just installed Jessie on a server at work and had to go get some firmware for the network cards to work.
[14:11:42] <seb_kuzminsky> speaking of wheezy, a guy at the hackspace recently upgraded his big wood router from lucid to wheezy, and was surprised that his VFD stopped working
[14:11:50] <mozmck> Those kind of things are what make it not user friendly for newbies. Our customers often hardly know how to turn on a computer ;-)
[14:12:09] <seb_kuzminsky> turns out some braille usb device driver grabbed his USB serial port before linuxcnc got a chance to start
[14:12:31] <seb_kuzminsky> he thought maybe it was "xbraille", but wasnt sure
[14:12:39] <seb_kuzminsky> we should remove that from the install image next time
[14:12:48] <mozmck> So when the installer asks questions about partitioning and LVM and ??? they have no clue what those words even mean!
[14:13:44] <seb_kuzminsky> mozmck: isn't there a "guided" option that doesnt ask questions like that?
[14:13:48] <mozmck> Not that I'm trying to convince anyone to switch from Debian - just explaining why I haven't (yet at least!) gone with that.
[14:14:17] <cradek> partman-auto partman-auto/choose_recipe select /lib/partman/recipes/30atomic
[14:14:26] <cradek> I think the linuxcnc installer doesn't ask that question
[14:14:32] <mozmck> There is, but even that is somewhat confusing.
[14:15:55] <mozmck> cradek: interesting - I need to get some time to look into that more. I guess that is part of the installer config?
[14:18:54] <skunkworks> cradek,
http://bbs.homeshopmachinist.net/threads/20586-What-I-ve-been-working-on-all-week
[14:19:01] <cradek> it asks: language, country, keymap language, host/domainname, full name, username (defaults to first name), password, timezone, partitioning method (guided, use entire disk), write changes to disk yes/no
[14:19:05] <cradek> I just ran through it
[14:19:19] <cradek> I just clicked continue on the things where I didn't have to type anything
[14:20:25] <cradek> skunkworks: neato
[14:21:19] <mozmck> I guess if I could get the Jessie install that simple or better, and figure out how to ship non-free firmware in the installer then it may be ok.
[14:21:22] <cradek> I don't think you'd want to remove any of those questions except maybe the yes/no confirmation
[14:21:44] <cradek> people often seem to get confused about username/password
[14:21:52] <cradek> they forget they typed one during the install, I think
[14:21:54] <mozmck> Probably not. Does it not ask for root password separately from user?
[14:22:08] <cradek> no, it is set up to use sudo and doesn't ask that
[14:22:23] <cradek> haven't you tried our image? I worked hard on it :-)
[14:22:29] <mozmck> Ok, I haven't install wheezy for a good while.
[14:23:11] <mozmck> :-) I did, but it's been a while. I think I was more turned off by other things in the GUI and stuff there.
[14:23:43] <seb_kuzminsky> mozmck: you can switch desktop environments after the install - you're not stuck with xfce if you dont like it
[14:23:53] <skunkworks> jessie with mate is nice.
[14:24:01] <skunkworks> (just installed it this week)
[14:24:06] <mozmck> I appreciate that work! Maybe I can use some of it to modify the jessie install.
[14:24:45] <cradek> mate is the gnome2 they flogged along? I should try that (since it's separate from mint, which is badly packaged)
[14:24:47] <mozmck> seb_kuzminsky: Oh, I'm well aware of that. I have several desktop environments here that I can switch on login.
[14:25:05] <cradek> yeah those are all the questions - it just finished.
[14:25:23] <cradek> I really can't imagine an easier installation
[14:25:55] <cradek> prettier, possibly (although it's graphical and looks like buttons to click, etc)
[14:25:57] <mozmck> cradek: yes, mate is the gnome2 fork - and you can get a jessie livecd with it:
http://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/debian-live-8.2.0-amd64-mate-desktop.iso.torrent
[14:26:21] <seb_kuzminsky> cradek: i think it's fine as is, but i remember last time i installed ubuntu (12.04 probably) it guessed my country and timecode by some kind of geo-ip trick
[14:26:45] <cradek> neat trick, but those are sure not hard/confusing questions
[14:27:33] <cradek> I encountered a "smart" installation that wouldn't let me pick japanese language in US/central because of stupid/clever assumptions like that
[14:27:38] <mozmck> I wish they would show proper timezone names in *ubuntu install instead of a smattering of city names.
[14:27:39] <cradek> I wish I could remember what it was
[14:28:00] <cradek> mozmck: yes I picked "central". having to know "chicago" is really stupid.
[14:28:11] <mozmck> I agree
[14:28:31] <mozmck> I'm not anywhere close to chicago - or I could pick a city in mexico too.
[14:32:08] <andypugh> A fair question, I guess:
https://forum.linuxcnc.org/forum/25-classicladder/30008-update-classicladder#66211
[14:32:09] <jepler> mozmck: no, the time zone America/Mexico_City has different start/end DST days
[14:32:55] <jepler> hahahaah is it planned
[14:32:57] <seb_kuzminsky> andypugh: i don't have a plan to do it...
[14:33:14] <seb_kuzminsky> careful, you'll break jepler
[14:33:47] <andypugh> I tried Google Translate on that “Plan” word, and it didn’t help.
[14:34:03] <jepler> I didn't know "jepler" was one of the options to translate to
[14:34:11] <seb_kuzminsky> i think it's that thing your boss does, right before he pays you
[14:46:33] <skunkworks> is it jeplered to update the ClassicLadder to latest version
[15:56:51] <seb_kuzminsky> cradek: the problematic part of our wheezy live/install iso is apparently a package named brltty
[15:57:03] <seb_kuzminsky> here's a bug report that describes the failure mode:
https://bugs.launchpad.net/ubuntu/+source/brltty/+bug/874181
[15:57:37] <seb_kuzminsky> this bit a guy i know who updated his machine from lucid to wheezy by reinstalling using our wheezy install iso
[15:58:43] <cradek> This bug was fixed in the package brltty - 4.3-1ubuntu2
[15:59:00] <cradek> brltty:
[15:59:00] <cradek> Installed: (none)
[15:59:00] <cradek> Candidate: 4.4-10+deb7u1
[15:59:11] <seb_kuzminsky> what does wheezy have?
[15:59:36] <cradek> what I just pasted
[15:59:47] <cradek> are you sure he didn't cause it to be installed?
[16:00:05] <cradek> so we should have the "fix", but also it isn't installed by default anyway
[16:00:12] <seb_kuzminsky> hmm
[16:00:13] <seb_kuzminsky> strange
[16:21:25] <jepler> launchpad doesn't show that ubuntu considered it an upstream bug, and the Debian changelog doesn't mention them making this change
[16:21:44] <jepler> ubuntu's changelog entry said
[16:21:44] <jepler> * Comment out the udev rule line for device 10c4:ea60, as it is a generic
[16:21:48] <jepler> USB serial controller used by many other pieces of hardware (LP: #874181)
[16:21:56] <jepler> (from that launchpad item)
[16:22:05] <jepler> but there's no similar item in the debian changelog for brltty at
http://metadata.ftp-master.debian.org/changelogs/main/b/brltty/brltty_4.4-10+deb7u1_changelog
[16:23:43] <jepler> so aside from the mystery of why brltty is installed on this user's machine, we can berate Ubuntu for not attempting to upstream this fix to Debian or brltty
[16:26:52] <jepler> I wonder whether d-i uses the same udev rules to decide "oh there must be a braile tty attached" and that causes brltty to be pulled into the installed system
[16:34:26] <jepler> https://www.debian.org/releases/stable/i386/ch05s02.html.en says of the installer that "USB braille displays should be automatically detected" so this seems like a plausible theory
[20:53:49] <skunkworks> zlog:
[23:56:27] <seb_kuzminsky> skunkworks: i sometimes see overruns in the rtai testsuite/kern/latency test too, on a machine that runs without overruns on wheezy
[23:56:36] <seb_kuzminsky> it still gets good latency though