#linuxcnc-meet Log v0.1


Recorded agenda
2013-08-24 16:59:03

!start 201308
2013-08-24 17:01:58
DISCUSS: 1: standardize on 4th Saturday
2013-08-24 17:03:14
VOTE: 1: standardize on 4th Saturday
2013-08-24 17:04:20
DISCUSS: 2: Drop hardy support after 2.5
2013-08-24 17:25:00
VOTE: 2: Drop hardy support in the branch where and when UB is merged, and in branches subsequent to that
2013-08-24 17:25:56
NEXT MEETING: Saturday 2013-09-28 1600UTC
2013-08-24 17:26:15


log row count=140
2013-08-24 16:59:03 archivist !start 201308
2013-08-24 16:59:35 seb_kuzminsky i volunteer to be secretary again
2013-08-24 16:59:47 cradek does someone else want to drive this time?
2013-08-24 16:59:55 cradek archivist?
2013-08-24 17:00:36 archivist chairing so not me :(
2013-08-24 17:00:51 cradek eh I'll do it if nobody cares
2013-08-24 17:01:08 seb_kuzminsky i think you do a good job and i appreciate you doing it
2013-08-24 17:01:20 cradek ok, let's start
2013-08-24 17:01:48 zultron Start!
2013-08-24 17:02:06 seb_kuzminsky i'll take this one
2013-08-24 17:02:17 seb_kuzminsky i don't care when we do it, as long as it's predictable
2013-08-24 17:02:17 elson I thought 4th Sat was ALREADY the agreement.
2013-08-24 17:02:33 archivist was last saturday iirc
2013-08-24 17:02:35 cradek elson: it was never quite made official I guess
2013-08-24 17:02:37 seb_kuzminsky no, i had messed up and said "the LAST saturday of the month" and ther was some pushback on that
2013-08-24 17:02:53 archivist 4th does me
2013-08-24 17:02:55 elson 4th Sat sounds more predictable than last Sat of the month
2013-08-24 17:02:56 seb_kuzminsky we talked about it and 4th saturday was not objected to
2013-08-24 17:03:01 zultron I'm good with it.
2013-08-24 17:03:02 seb_kuzminsky ready to vote?
2013-08-24 17:03:08 archivist yes
2013-08-24 17:03:17 seb_kuzminsky yes
2013-08-24 17:03:20 elson yes
2013-08-24 17:03:20 archivist yes
2013-08-24 17:03:21 cradek I vote yes
2013-08-24 17:03:22 steve_stallings yes
2013-08-24 17:03:23 zultron yes!
2013-08-24 17:03:32 seb_kuzminsky we couldnt agree more if we were twins
2013-08-24 17:04:16 cradek I guess that's everyone
2013-08-24 17:04:25 cradek zultron: please start us
2013-08-24 17:04:39 zultron Ok. I propose we drop support for Hardy.
2013-08-24 17:04:55 archivist but but, some of us run older stuff
2013-08-24 17:04:56 zultron 2.5 should be the last branch that supports it.
2013-08-24 17:05:05 elson Well, I still use 6.06 (I think that is Hardy) on my Bridgeport, the computer is old
2013-08-24 17:05:12 seb_kuzminsky is the only reason that the ub-c-2 branch needs libudev for something?
2013-08-24 17:05:13 cradek 6.06 is the release before hardy
2013-08-24 17:05:22 seb_kuzminsky 6.06 is dapper drake
2013-08-24 17:05:23 cradek hardy is the 2008 release
2013-08-24 17:05:26 elson and limited. But, I don't excpect to update it much before replacement.
2013-08-24 17:05:31 zultron No, in fact I can fix the udev problem.
2013-08-24 17:05:34 seb_kuzminsky oh
2013-08-24 17:05:48 seb_kuzminsky then what's the driver for dropping hardy support?
2013-08-24 17:05:50 archivist I have the mill on 6 and the lathe on 8
2013-08-24 17:05:58 zultron The problem is that it's old enough that it's getting difficult to keep it going.
2013-08-24 17:06:19 elson Oh, then I'm even further out of date than I thought! Well, I don't really need Hardy, either, 10.04 is good for most of my machines.
2013-08-24 17:06:45 archivist I rather hate the headlong rush in the computing world forcing upgrades
2013-08-24 17:06:58 cradek for historical knowledge: our hardy kernel is the last one that runs on machines without LAPIC, because it's a uniprocessor build. We had to sacrifice working on some old non-LAPIC machines in order to get SMP (multiprocessor) support.
2013-08-24 17:07:02 zultron I've spent quite a lot of time and tears getting the RTOS changes and kernel packages working (or not) on Hardy, and I don't want to do it anymore.
2013-08-24 17:07:25 elson Well, you don't HAVE to upgrade a working OS, unless you want to update the LinuxCNC system.
2013-08-24 17:07:38 seb_kuzminsky zultron: i see, and i'm sympathetic to that
2013-08-24 17:07:57 seb_kuzminsky it might make sense to talk about supported platforms in a more detailed way
2013-08-24 17:07:58 cradek this LAPIC requirement still occasionally bites people using legacy hardware (approximately: early P3 machines and before) and I still occasionally see people recommend the hardy install for people trying to use trouble hardware.
2013-08-24 17:08:22 steve_stallings 2.6 seems a clean break point, possibly with a few continued back ports to 2.5
2013-08-24 17:08:39 seb_kuzminsky instead of dropping hardy entirely, would it be less time & tears to drop hardy-xenomai and hardy-rt_preempt, but still keep alive hardy-sim and hardy-rtai?
2013-08-24 17:09:03 cradek we will continue to fix bugs on 2.5 after 2.6 is made, but we will not backport new features to it
2013-08-24 17:09:04 CaptHindsight do the users of Hardy need/want any of the new features in Linuxcnc? If not then they can just keep their old system as is.
2013-08-24 17:09:35 cradek CaptHindsight: seems hard to know that. probably at least some do.
2013-08-24 17:10:04 cradek does master (non-UB) currently build and work on hardy?
2013-08-24 17:10:10 seb_kuzminsky yes
2013-08-24 17:10:12 archivist there are things I want on the mill, but that forces new hardware, not possible at the moment
2013-08-24 17:10:14 zultron I think it will be the same. The problems aren't necessarily related to the particular RTOS version. I wish I'd brought a list of examples. :(
2013-08-24 17:10:21 elson We see the Lapic problem show up QUITE regularly on the forum.
2013-08-24 17:10:24 steve_stallings those that really want new features from 2.6 should not find the cost of a newer PC that significant
2013-08-24 17:10:40 archivist heh
2013-08-24 17:10:41 seb_kuzminsky i wonder if we could get memleak to build & test a non-lapic 3.4 kernel, that might work on the old hardware that can't run lucid's rtai kernel
2013-08-24 17:10:57 cradek that seems likely
2013-08-24 17:11:01 seb_kuzminsky then we would need hardy even less
2013-08-24 17:11:07 CaptHindsight we have old hardware here as well
2013-08-24 17:11:42 seb_kuzminsky i'm running lucid rtai on an old-ish (by my standards) single-processor P4
2013-08-24 17:11:49 cradek if UB gives us the ability to have our releases support more than one particular rtai build, that would make me very happy, and we could have a non-LAPIC-non-SMP kernel and a LAPIC+SMP kernel
2013-08-24 17:11:50 CaptHindsight I'll ask memleak in a few hours
2013-08-24 17:12:16 seb_kuzminsky thanks CaptHindsight (and memleak)
2013-08-24 17:12:20 zultron UB can build for multiple kernels within a flavor.
2013-08-24 17:12:32 seb_kuzminsky wow, that's pretty cool
2013-08-24 17:13:40 zultron Everyone made up their mind?
2013-08-24 17:13:42 cradek then I have an alternate proposal: drop support for hardy exactly when UB is merged. If for some reason 2.6 doesn't have the UB merge, it can have hardy support.
2013-08-24 17:13:59 steve_stallings should we postpone until the answer about alternate builds is resolved?
2013-08-24 17:14:08 seb_kuzminsky zultron: do i understand you correctly that you can build one binary that will work on (for example) two different rtai kernels, one SMP and one UP, as long as both sets of kernel hearders are available at build-time?
2013-08-24 17:14:49 zultron At this point, 'UB' stands for 'Universal Build'. I cheated and have multiple binaries. :)
2013-08-24 17:14:54 zultron But yes, that's correct.
2013-08-24 17:15:01 seb_kuzminsky ah
2013-08-24 17:15:02 cradek if our users always have the choice of a non-LAPIC kernel (either hardy, OR ditch hardy and have the new UB+rtai+nonlapic+nonSMP) I'd be tickled
2013-08-24 17:15:29 seb_kuzminsky cradek: i agree that would be a good situation for us to be in
2013-08-24 17:15:30 cradek I think these two things (drop hardy, merge UB) are what go together in my mind
2013-08-24 17:15:39 seb_kuzminsky yes
2013-08-24 17:15:50 seb_kuzminsky and "drop hardy" costs less if there's another non-lapic option
2013-08-24 17:15:55 cradek exactly
2013-08-24 17:15:58 zultron Well hold on,
2013-08-24 17:16:04 elson A newer kernel that didn't require huge memory and supported older chipsets would be a good thing.
2013-08-24 17:16:36 zultron There are a lot of folks running master right now. If master suddenly stops supporting something without a release, won't that be a problem?
2013-08-24 17:16:50 seb_kuzminsky no, master can change stuff like that without warning
2013-08-24 17:16:57 zultron Ah, ok.
2013-08-24 17:17:15 mhaberler joined chan
2013-08-24 17:17:24 seb_kuzminsky once we branch off 2.6 and make the 2.6.0 release, we promise that 2.6 won't break stuff like that
2013-08-24 17:17:32 cradek I agree with seb
2013-08-24 17:17:49 seb_kuzminsky hi mhaberler
2013-08-24 17:17:50 steve_stallings should we recap for mhaberler
2013-08-24 17:17:57 cradek is there a log?
2013-08-24 17:17:59 mhaberler no, reading back - sorry
2013-08-24 17:18:01 mhaberler yes
2013-08-24 17:18:02 seb_kuzminsky the_wench: where's the log?
2013-08-24 17:18:08 mhaberler http://meetlog.archivist.info/
2013-08-24 17:18:16 seb_kuzminsky thanks, whench ;-)
2013-08-24 17:18:36 cradek we're about out of time but I propose we extend time and not worry about it
2013-08-24 17:18:57 seb_kuzminsky i think that's fine
2013-08-24 17:19:01 seb_kuzminsky this is the last item anyway
2013-08-24 17:19:03 zultron Lucky this is the last proposal. :)
2013-08-24 17:19:27 seb_kuzminsky i've been thinking about ways to teach the buildbot what branches to build on what platforms, and i think it won't be hard
2013-08-24 17:19:38 archivist never seen any time limit
2013-08-24 17:20:04 seb_kuzminsky i think we should filter on the 3-tuple of (Distribution, Binary architecture, RTOS kernel)
2013-08-24 17:20:08 cradek zultron: would you also be satisfied by my alternate proposal?
2013-08-24 17:20:11 zultron We discussed a 15 minute time limit for discussion, but we've encountered overruns many times. :)
2013-08-24 17:20:22 memleak joined chan
2013-08-24 17:20:26 seb_kuzminsky hi memleak
2013-08-24 17:20:29 memleak hello!
2013-08-24 17:20:46 zultron My brain's a little slow today. Is it simply to drop support for Hardy when UB is merged?
2013-08-24 17:21:02 cradek yes, wherever that merge happens
2013-08-24 17:21:13 zultron That sounds good to me.
2013-08-24 17:21:38 CaptHindsight supporting older cpu's without APIC should not be a problem with a new kernel + RTAI
2013-08-24 17:21:51 seb_kuzminsky CaptHindsight: that'd be great!
2013-08-24 17:22:15 zultron Also, if Seb could filter builds based on branch so that builds that wouldn't otherwise pass on hardy don't fail, that would be great.
2013-08-24 17:22:34 seb_kuzminsky zultron: yep, i'll take care of that part of it
2013-08-24 17:22:35 cradek the only important difference would be if 2.6 doesn't have the UB merge, and I don't know the chances of that, but it seems at least possible that it's a choice seb could still make. So in more detail I propose that if UB goes in v2.6_branch we drop hardy support for that branch and master. If UB gets merged into master after v2.6_branch we'd drop hardy support in master.
2013-08-24 17:22:35 memleak Indeed, 3.x doesn't hard-code any APIC / LAPIC
2013-08-24 17:23:22 zultron That's a good clarification. I understand, and that's fine.
2013-08-24 17:23:54 cradek zultron: do you want to have a vote on that?
2013-08-24 17:24:17 seb_kuzminsky i really want UB in 2.6, but i'm still a bit overwhelmed by that branch
2013-08-24 17:24:35 seb_kuzminsky and i've been busy with getting another feature branch ready for 2.6 (joints_axes3)
2013-08-24 17:24:50 seb_kuzminsky i'm ready to vote on dropping hardy support when ub goes in
2013-08-24 17:24:58 zultron I'm good, yes.
2013-08-24 17:25:03 cradek I vote yes
2013-08-24 17:25:06 zultron yes
2013-08-24 17:25:08 steve_stallings yes
2013-08-24 17:25:09 seb_kuzminsky yes
2013-08-24 17:25:10 memleak vote yes
2013-08-24 17:25:11 elson yes
2013-08-24 17:25:11 mhaberler yes
2013-08-24 17:25:32 zultron Ah, thank you all!
2013-08-24 17:26:13 cradek now I have to go clean spam off the wiki again
2013-08-24 17:26:15 archivist !end