20:00:29 <pwhalen> #startmeeting
20:00:29 <zodbot_> Meeting started Wed Aug 15 20:00:29 2012 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:29 <zodbot_> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:29 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore
20:00:29 <zodbot_> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen
20:00:44 <bconoboy> .fas blc@
20:00:44 <zodbot_> bconoboy: blc '' <blc@redhat.com>
20:00:50 <pwhalen> .fas pwhalen
20:00:50 <zodbot_> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
20:00:50 <jcapik> .fas jcapik
20:00:52 <djdelorie> .fas djdelorie
20:00:53 <zodbot_> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:00:54 <Frojoe> .fas frojoe
20:00:56 <zodbot_> djdelorie: djdelorie 'DJ Delorie' <dj@redhat.com>
20:00:59 <zodbot_> Frojoe: burningfool 'Jordan Cwang' <frojoe.21@gmail.com> - jacwang 'Jordan Cwang' <jordan.cwang@gmail.com>
20:01:02 * masta is here
20:01:06 <masta> .fas parasense
20:01:06 <zodbot_> masta: parasense 'Jon Disnard' <jdisnard@gmail.com>
20:01:18 <ctyler> .fas ctyler@
20:01:18 <zodbot_> ctyler: 'ctyler@' Not Found!
20:01:23 <ctyler> .fas ctyler
20:01:23 <zodbot_> ctyler: ctyler 'Chris Tyler' <chris@tylers.info> - ctyler2621 'Christopher Tyler' <chris@mowisp.com>
20:01:42 <pwhalen> #topic 1a) Build status update
20:02:01 * pbrobinson is here
20:02:14 <pwhalen> pbrobinson, how we doing on the builds?
20:02:15 <agreene> @me is here
20:02:23 * agreene is here
20:02:33 <djdelorie> .fas agreene
20:02:35 <zodbot_> djdelorie: tag4fedora 'Tim Greene' <tagreene@flowserve.com> - agreene 'Andrew Greene' <agreene@learn.senecac.on.ca>
20:02:52 <pbrobinson> fine, few minor problems, mostly moving onwards and upwards
20:03:00 <dmarlin> .fas dmarlin
20:03:00 <zodbot_> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:03:12 <bconoboy> fossjon's script suggests we're getting further away- what's the deal?
20:03:16 <pwhalen> great
20:03:31 <pbrobinson> koji-shadow has finally managed to get itself through a full run in the last couple of days so I don't believe there should be any more mass rebuild straglers now
20:03:49 <pwhalen> #topic 1b) packages needing attention?
20:03:53 <fossjon> oh i changed it to f19
20:03:56 <fossjon> sorry
20:04:01 <fossjon> i should have let the mailing list know
20:04:10 <pbrobinson> bconoboy: I don't believe we are
20:04:11 <fossjon> it inherits just letting everyone know
20:04:26 <bconoboy> fossjon: Oh, so it's showing f19+f18+f17 missing?
20:05:10 <fossjon> i believe so
20:05:19 <masta> the twitter thing shows 96.86%
20:05:21 <bconoboy> can you break out just f18?
20:05:24 <fossjon> i wasnt sure if people prefered it inheriting or not
20:05:28 <pbrobinson> I asked fossjon to add f19 to the rest of them, so we should have them all but I still only see two in the email
20:05:45 <pbrobinson> so we should have f17-updates f18 f19
20:05:56 <fossjon> pbrobinson which ones should i set to inherit?
20:06:05 <fossjon> i can add back f18
20:06:36 <bconoboy> #info koji-shadow has made it through an entire run- few minor problems remain
20:07:08 <bconoboy> fossjon: I'd kinda like to see without any inheritance
20:07:10 <pbrobinson> fossjon: probably them all for the time being, shouldn't be hard to change
20:07:20 <jonmasters> .fas jonmasters
20:07:21 <zodbot_> jonmasters: jcm 'Jon Masters' <jonathan@jonmasters.org>
20:07:22 <fossjon> alright
20:07:48 <bconoboy> #agreed fossjon to update nightly status report to track f17-updates, f18, and f19 separately
20:07:50 <pbrobinson> bconoboy: the current biggest blocker is an avahi build issue if someone has time to look at it that would be great
20:08:20 <bconoboy> avahi appears to have failed for lack of a dependency
20:09:04 <pbrobinson> ah, yes, perl issues, I rememeber now :-/
20:09:10 <pbrobinson> sorry, been a massively busy week
20:09:26 <bconoboy> #info biggest blocker: avahi, caused by perl dependencies
20:09:46 <bconoboy> pbrobinson: anything we can do to help with perl dep issues?
20:09:52 * fossjon wonders what the highest percentage of pkgs we've ever built
20:10:19 <pbrobinson> I'll have a poke at it tonight to see if I can see what's wrong with it and poke people if I need help
20:10:43 <bconoboy> #action pbrobinson to investigate perl issues, ask for help if needed
20:11:04 <pwhalen> any other problem packages to note?
20:11:07 <jonmasters> thanks Peter
20:11:17 <jonmasters> I've got the ball on llvm, we've discussed that one enough
20:11:35 <jonmasters> (really that means clang, but llvm is the source package)
20:12:06 <bconoboy> #agreed jonmasters is fixing llvm to support using armv7hl-redhat-linux triplet
20:12:27 <jonmasters> it's armv7hl-redhat-linux-gnueabi per gcc
20:12:36 <bconoboy> #undo
20:12:36 <zodbot_> Removing item from minutes: <MeetBot.items.Agreed object at 0x2416f490>
20:12:44 <bconoboy> #agreed jonmasters is fixing llvm to support using armv7hl-redhat-linux-gnueabi triplet
20:12:46 <pbrobinson> pwhalen: nope, nothing further
20:12:49 <pwhalen> #topic 2) missing mock configs for F18
20:12:51 <jonmasters> tnx
20:13:15 <pwhalen> dmarlin noticed we were missing mock configs for f18
20:14:08 <pwhalen> is this normal at this stage of development?
20:14:11 <pbrobinson> mock configs need to be updated in mainline and then we pull them back
20:14:22 <bconoboy> who does that? when?
20:14:23 <pwhalen> ah, okay great, any timeline as to when?
20:14:34 <ctyler> releng usually does that
20:14:34 <pbrobinson> it's not un normal for it to happen post branch a little later,
20:14:43 * jonmasters thinks it's pretty normal not to be done yet
20:14:49 <jonmasters> yea
20:14:58 <pwhalen> ok
20:15:06 <pwhalen> #topic 3) Raspberry Pi status update
20:15:07 <bconoboy> is the absence of these configuration files causing difficulty?
20:15:10 <dmarlin> how do we handle mock builds in the interim ?
20:15:17 <pwhalen> #topic 2) missing mock configs for F18
20:15:54 <pbrobinson> dmarlin: copy the f17 or rawhide one and update the repo files. It's not hard
20:16:10 <ctyler> On the Pi Remix - we've done the builds necessary to test the v6 optimizations except for glibc.
20:16:15 <bconoboy> ctyler: hang on
20:16:25 <bconoboy> #info We're waiting on releng to update mock configs
20:16:26 <dmarlin> pbrobinson: harder than 'yum update mock' on a dozen builders
20:16:36 <dmarlin> :)
20:16:48 <bconoboy> #info Creating an f18 mock config by hand should work at this stage
20:17:00 <pbrobinson> dmarlin: koji generates their own configs so it doesn't matter, mock is just for local stuff
20:17:17 <dmarlin> pbrobinson: right, and I do a lot of local stuff
20:17:45 <dmarlin> pwhalen: ok, next.
20:17:45 <pwhalen> #topic 3) Raspberry Pi status update
20:17:54 <ctyler> dmarlin: I suspect dgilmore will update the mock configs pretty quickly when he resurfaces
20:18:09 <pbrobinson> dmarlin: so for builders it doesn't matter about the configs, for the local stuff it takes 1min to copy and update your local file
20:18:49 <bconoboy> ctyler: okay, pi status?
20:18:52 <ctyler> Ok, on the Pi Remix, we have just glibc to go before we can test armv6 builds. Hoping to get that done this week.
20:19:10 <ctyler> The rest of the packages in the remix image subset are done for v6 hard and soft.
20:19:16 <bconoboy> #info Seneca are working on armv6 builds.  glibc is outstanding.  Should be done this week
20:19:28 <bconoboy> #info Remainder of v6 builds are complete
20:19:35 <bconoboy> #undo
20:19:35 <zodbot_> Removing item from minutes: <MeetBot.items.Info object at 0x23a6aad0>
20:19:40 <bconoboy> #info Remainder of v6 hard float builds are complete
20:19:50 <pbrobinson> dmarlin: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=89690 it was done on Aug 10th on mainline, and imported into the arm.koji config on the same day actually. Case closed.
20:19:54 <bconoboy> ctyler: Has softfp remix development stoppe?
20:19:55 <ctyler> bconoboy: and softfp w/ vfp support too
20:19:58 <bconoboy> er stopped?
20:20:24 * pbrobinson wonders how you can build all the rest of the packages for v6 properly without a proper glibc?
20:20:43 <bconoboy> dynamic linking?
20:20:51 <djdelorie> "close enough" ABI
20:20:56 * dmarlin would like to know the performance difference between v5 an v6, when the images are complete
20:20:59 <ctyler> We've got what I think is a pretty solid image that's armv5tel, next thing we really want to do is see what the v6 builds do
20:21:08 <fossjon> ive been waiting for dgilmore to get back to ask him in more detail but i cant right now
20:21:19 <bconoboy> #info The armv5tel f17 raspberry py remix image is "pretty solid"
20:21:31 <fossjon> i would like to verify if ive been building the pkgs correctly so far
20:21:43 <ctyler> There are some more firstboot pieces that are just done, we'll put out an armv5tel compose with those pieces tomorrow
20:21:46 <djdelorie> the thing that made the hardfp bootstrap difficult is that the ABIs were not "close enough"
20:21:58 <pwhalen> fossjon, perhaps email dgilmore, he is working while down under, afaik
20:22:03 <bconoboy> fossjon: Do you specifically need dgilmore's feedback or could somebody else answer your question?
20:22:19 <pbrobinson> fossjon: feel free to ask me other others so it doesn't hold you up
20:22:31 <fossjon> someone who knows enough about mock/rpmbuild/building one arch from scratch on a different arch
20:22:39 <ctyler> pbrobinson: armv6 will interoperate sufficiently with armv7hl (on a v7 box) and armv5tel (for softfp+vfp)
20:22:41 <fossjon> ie armv6hl on armv7hl
20:23:00 <bconoboy> one other pi question
20:23:03 <fossjon> an arch thats never been defined before either
20:23:11 <ctyler> bconoboy: ?
20:23:16 <jonmasters> djdelorie: they weren't close but there were other ways we could have done it. I deliberately skewed the v7 case in favor of a complete arch bootstrap to prepare for v8
20:23:18 <bconoboy> in #fedora-arm the other day there was a request for the compose script- can we get a pointer for the minutes?
20:23:42 <djdelorie> jonmasters: I know, I was there :-)
20:23:48 <fossjon> http://huttriver.proximity.on.ca/outbound/rpfrcompose16-xfce
20:24:03 <bconoboy> #link http://huttriver.proximity.on.ca/outbound/rpfrcompose16-xfce
20:24:19 <bconoboy> #info The above link is the compose script Seneca are using to generate Fedora 17 Raspberry Pi remix images
20:24:25 <jonmasters> just for context. And I think what is being done with v6 is interesting for the Pi, but I don't think it'll be more broadly used because most devices are either v5 or v7
20:24:46 <pwhalen> ctyler, anything else to note for the pi today?
20:25:03 <djdelorie> knowing what kind of performance gains can be had from device-specific builds might be generally useful
20:25:04 <bconoboy> what's v5 besides kirkwood?
20:25:30 <djdelorie> and/or how fast we can spin a semi-compatible "build everything"
20:26:10 <ctyler> I'm hoping softfp+vfp gives sufficient gains, so we can interoperate with armv5tel and avoid a full rebuild.
20:26:16 <jonmasters> bconoboy: well, it is mostly kirkwood at this stage (and some cheap devices in APAC) but that's a lot of older devices
20:26:32 <jonmasters> anyway, I don't want to pretend I care a lot about v5 longevity :) because I don't
20:26:45 <pbrobinson> ctyler: how are you going to do softfp+vfp. That's mixing softfp and hardfp
20:26:58 <djdelorie> there's a third ABI
20:26:59 <bconoboy> pwhalen: I have a related topic when we're ready to move to open forum
20:27:14 <pwhalen> bconoboy, ok
20:27:15 <ctyler> pbrobinson: soft ABI with VFP-enabled code
20:27:21 <djdelorie> it's hardfp insns but floats are passed in integer registers, IIRC
20:27:45 <ctyler> right, the VFP is used, but not for passing args to a function
20:28:24 <ctyler> EOF on Pi for now
20:28:32 <pwhalen> any other pi questions from anyone?
20:28:49 <pwhalen> #topic 4) Linaro Connect - single kernel binary status update
20:28:59 <pwhalen> #link http://www.youtube.com/watch?v=4Lpzc_dkh9E
20:29:04 <jonmasters> I think the first thing is to remind folks...yea, that video
20:29:33 <pwhalen> just to summarize - Goal is to provide one kernel to boot across all ARM soc's to make life easier for everyone, speed up kernel build times and to be inline with whats done on x86.
20:29:34 <jonmasters> I've pinged a few folks and I think the main the is it's in Deepak and Arnd's court
20:29:54 <jonmasters> but there is a need to identify any remaining work items that need looking at
20:29:57 <pwhalen> Realistically there will still be multiple kernels, eg - LPAE & non-LPAE, single kernel for v6 & v7, and single kernel for use with v5 platforms.
20:30:19 <jonmasters> USB host controllers are the most obvious one. I raised the need for a standard U-Boot environment too
20:30:19 <pwhalen> an initial build was completed on single zImage after previous Linaro Connect, with it being unable to boot on any hardware
20:30:19 <bconoboy> #info The above link is frmom the linaro virtual connect discussing the status of unified arm kernel binaries
20:30:30 <pbrobinson> is there a written update to a mailing list somewhere so we don't have to watch an hour of video?
20:30:59 <jonmasters> I can send something, but there's not a whole lot to say. It's being worked on upstream. We should just think of anything useful to feed back to them
20:31:08 <bconoboy> #info As a practical matter there will at best be one kernel for v5, one for v6, one for v7, and separate kernels for LPAE vs non-LPAE
20:31:18 <jonmasters> the need for a standard U-Boot envirnment is something I have raised
20:31:20 <pbrobinson> pwhalen: yep, we already knew about those differences
20:31:26 <pwhalen> one of the current problems they are working through, header files need to be cleaned up, changing to unique header file names, with each driver including the specific header file name - eg omap. This will work for most header files.
20:31:55 <pwhalen> Aproach will be to disable drivers initially to provide a working kernel on qemu, then re-enable and determine where it breaks
20:32:09 <pwhalen> usb host controller issue is being looked in greater detail within the coming weeks (Linaro will allocate resources)
20:32:21 <pbrobinson> yep, so basically nothing has changed in all of that. Do they actually have it booting yet on the branch? Are they still aiming for 3.7 for the first merge with mainline?
20:32:26 <pwhalen> Targeting the 3.7 merge window for incorporating the patches.
20:32:49 <pwhalen> goal is to have single zImage working for Linaro Connect in Copenhagen (Oct 2012) to demo, not all are drivers expected to working
20:33:26 <dmarlin> is this using device-tree to handle platform differences?
20:33:43 <bconoboy> #info First Patches are targeted at the 3.7 kernel merge window
20:33:51 <jonmasters> dmarlin: yea
20:33:54 <dmarlin> so U-Boot support for device-tree becomes more important
20:33:56 <pbrobinson> device tree is one of a number of components needed
20:34:07 <jonmasters> some of the engineers working on devicetree enablement are now shifting to single zimage
20:34:09 <ctyler> dmarlin: dt needs to have the drivers present, right now they can'd be built into the same image
20:34:14 <bconoboy> #info There may be an initial unified zImage for some devices at Linaro Connect Copenhagen (Oct 2012)
20:34:16 <pbrobinson> dmarlin: not necessarily, we can append them to the end of the kernel
20:34:26 <masta> +1 device tree
20:34:42 <bconoboy> #info Device Tree support in the bootloader is a requirement for unified zImage.
20:35:36 <jonmasters> I think most of the last few lines are largely quotes from the etherpad we created during that connect video. I suggest rather than paste them all, we simply point people to the pad
20:35:49 <bconoboy> jonmasters: pointer?
20:36:03 <jonmasters> trying to find it
20:36:16 * jonmasters assumed you were copy/pasting
20:36:26 <bconoboy> No, I'm summarizing what paul wrote.
20:36:29 <pwhalen> jonmasters, no, couldnt find the doc they were working on
20:36:43 <jonmasters> ah one sec
20:37:14 <bconoboy> would it be premature to discuss how this affects our planning?
20:37:45 <jonmasters> http://pad.ubuntu.com/QiCpcZWziq
20:37:54 <bconoboy> #link http://pad.ubuntu.com/QiCpcZWziq
20:37:54 <jonmasters> ^^^ contains everything mentioned above
20:38:11 <bconoboy> #info The above link contains a summary of the meeting from the metting with more details.
20:38:44 <ctyler> bconoboy: I think we need this to flow down from upstream, it will affect us in the 3.7 timeframe (is that f18 updates or f19?)
20:38:51 * pbrobinson groans that it needs a login
20:39:07 <bconoboy> one sec.
20:39:57 * ctyler never remembers his ubuntu login, he uses it *that often*
20:40:00 <bconoboy> Nope, can't access
20:40:06 <bconoboy> jonmasters: Please cut&paste into an fpaste
20:41:14 <bconoboy> #undo
20:41:14 <zodbot_> Removing item from minutes: <MeetBot.items.Info object at 0x22d32610>
20:41:15 <bconoboy> #undo
20:41:15 <zodbot_> Removing item from minutes: <MeetBot.items.Link object at 0x22d32ad0>
20:41:48 <bconoboy> pwhalen: are there more topics?
20:42:15 <pwhalen> none, open floor was next
20:42:22 <pwhalen> perhaps we lost jonmasters
20:42:31 <bconoboy> let's assume we have
20:42:33 <pwhalen> #topic 5) Your topic here
20:42:51 <bconoboy> Okay- following on with linaro's unified kernel: How is this going to affect our plans?
20:43:26 <bconoboy> We're support kirkwood, omap, tegra, highbank, vexpress, imx today
20:43:41 <bconoboy> Are any of thse going to work with a unified image?
20:43:44 <pbrobinson> OLPC today announced the XO-4 http://blog.laptop.org/2012/08/15/one-laptop-per-child-confirms-upcoming-launch-of-groundbreaking-dual-function-xo-4-touch/
20:43:57 <bconoboy> I'm thinking highbank and vexpress will
20:44:07 <bconoboy> #link http://blog.laptop.org/2012/08/15/one-laptop-per-child-confirms-upcoming-launch-of-groundbreaking-dual-function-xo-4-touch/
20:44:07 <pbrobinson> and omap will
20:44:14 <ctyler> bconoboy: a year from now, zImage will be viable across most of the archs we'll care about at that point
20:44:14 <bconoboy> #info  OLPC today announced the XO-4
20:44:53 <pbrobinson> XO-4 is a Marvell dual core A9 device
20:44:56 <bconoboy> I would like us to add armada xp support, which will ultimately be plae
20:44:59 <bconoboy> er lpae
20:45:14 <dmarlin> bconoboy: when we have a kernel?
20:45:42 <bconoboy> dmarlin: There's more to it than that though- dgilmore has been resistant to adding additional configurations because it will increase our build time which is an issue for PA
20:46:25 <dmarlin> true, but that's not even an issue until we have a kernel in Fedora
20:46:29 <masta> which begs the question of our future builder plans?
20:46:59 <jsmith> future builders will be bigger and stronger and faster :-)
20:47:03 <masta> can we keep scalling out (more builders) and scale up (better builders) ?
20:47:05 <jonmasters> pwhalen: sorry, I'm still here
20:47:06 <djdelorie> and more of them :-)
20:47:21 <jsmith> masta: Yes, that's the plan
20:47:30 <bconoboy> I thought i would have pricing on builders this week but it isn't quite ready yet.
20:47:41 <pbrobinson> maste: I'm not sure what your question is about the builders
20:47:47 <ctyler> masta: horizontal doesn't help much with long builds, like the kernel srpm emitting a zillion binary packages
20:48:27 <jonmasters> #info fpaste of the single kernel zImage discussion: http://fpaste.org/IuEW/
20:48:31 <bconoboy> Anyway, my bigger question is: Can we drop armv5 if armv6 for pi works considerably better?  Also, can we drop less popular targets like imx if they don't get unified zImage support?
20:48:49 <bconoboy> jonmasters: thanks!
20:49:12 <djdelorie> we'd need stats on package downloads first, I think
20:49:27 <pbrobinson> bconoboy: for v5 it would make us drop all the plug computers for a single device. I don't see the point as it offers little advantage
20:49:45 <bconoboy> we have some stats from the nightlies.  It was 90% pi downloads, followed by omap... everything else was in the noise.
20:49:46 <pbrobinson> for imx: we can review it as time goes on
20:49:51 <jonmasters> I think dropping v5 in favor of v6 is a mistake, but that's a personal opinion. That basically gives up on everything that's older than v7 in favor of *one device* that isn't going to live forever
20:50:11 <ctyler> We also need to look at (Pi+APC) vs (Plug computer) volumes, though.
20:50:29 <ctyler> Because v5=kirkwood=older plug computers at this point, pretty much.
20:50:37 <ctyler> Btw, the APC is now in NewEgg
20:50:42 <pbrobinson> ctyler with v5 we can have Pi+APC+Plugs
20:50:45 <jonmasters> when the Pi is gone, then v6 would be completely defunct. Sure, we want to kill it eventually, but the real question is how long do we plan to support the older pre-v7 devices
20:51:12 <bconoboy> And do we want to push pre-v7 into primary?
20:51:12 <ctyler> jonmasters: v5 will be defunct too, since the newer plugs are v7
20:51:17 * jonmasters never likes the idea of doing an entire arch to support one platform
20:51:32 <pbrobinson> I think we leave it at v5 and eventually just drop < v7 all together
20:51:33 <bconoboy> jonmasters: We're doing an entire arch to support kirkwood, ne?
20:51:45 <ctyler> but "doing an entire arch to support one platform" is exactly what we're doing with v5, if we're honest
20:52:06 <jonmasters> bconoboy: v5 can support both kirkwood and Pi and anything else that is v5. I don't have a list of handy v5 devies, but there are more than just the kirkwood
20:52:22 <pbrobinson> yes, exactly
20:52:33 <masta> I guess our official pi image is a v5
20:52:38 <jonmasters> well, my opinion is not /that/ strong since I'd love to kill v5 completely eventually, so whatever is best
20:52:40 <bconoboy> Shall we revisit this question when we've wrapped up F18?
20:52:44 <jonmasters> bconoboy: +1
20:52:54 <masta> +1
20:52:55 <pbrobinson> +1
20:52:59 <ctyler> and when we have v6 build performance data :-)
20:53:01 <ctyler> +1
20:53:17 <bconoboy> #agreed Revisit dropping v5tel support (in favor of v6hl) after F18 is done
20:53:33 <bconoboy> Okay, one other topic from me:
20:53:39 <fossjon> that means no more gurus i guess
20:54:13 <bconoboy> Compulab have updated their trimslice uboot to support ethernet.  This might mean pxe installation is possible.  What is our stance on that?  Do we want to pursue it? Doing so would require users update their uboot.
20:54:27 <bconoboy> (Unless they bought a newer device that came with the new uboot)
20:54:39 <djdelorie> updating uboot on a trimslice is easy
20:55:01 <djdelorie> but a uboot *image* for microsd just for ethernet boot is just as easy, and safer
20:55:03 <jonmasters> I don't think the average Fedora user is going to install a TrimSlice with PXE
20:55:14 <ctyler> Agreed
20:55:15 <masta> bconoboy: seems like a great feature... would rather pxe boot
20:55:42 <ctyler> I suspect this boils down to whether we have someone willing to run with it.
20:55:43 <djdelorie> booting a trimslice diskless is an overall performance boost, if the server is faster than local usb disks
20:55:45 <bconoboy> okay, so--- ignore it for now?
20:55:45 <pbrobinson> bconoboy: did they add any else interesting to uboot such as DT or uEnv support?
20:55:46 <jonmasters> it's wonderful...on a server. It's probably useful for builders, etc. BUT the average person getting a trimslice is not running a PXE server and kickstarting it
20:56:20 <ctyler> I propose ignoring it unless someone steps up to make it happen.
20:56:25 <djdelorie> +1
20:56:27 <masta> could we do it for our own selfish reasons jonmasters ?
20:56:30 <bconoboy> pbrobinson: They simply put their changes upstream. Not aware of DT status.
20:56:51 <pbrobinson> they pushed their changed upstream?
20:56:53 <bconoboy> masta: Want to make it happen? :-)
20:57:09 <masta> bconoboy: ok, I'll take a look
20:57:09 <bconoboy> Into uboot 2012.04 they say
20:57:24 <bconoboy> public git tree: https://gitorious.org/trimslice-u-boot-dts/trimslice-u-boot-dts/commits/trimslice/2012.04-upload
20:57:35 <bconoboy> updated uboot binaries: http://www.trimslice.com/wiki/index.php/Firmware_Update
20:57:48 * djdelorie wonders if they have "just works" video drivers yet
20:57:56 <bconoboy> #link New trimslice uboot binaries are at http://www.trimslice.com/wiki/index.php/Firmware_Update
20:57:58 <jonmasters> masta: sure, selfishness is underrated
20:58:09 <pbrobinson> djdelorie: nope
20:58:27 <pbrobinson> 2012.04 should support uEnv I think
20:58:47 <bconoboy> That's it for me
20:58:50 <pwhalen> 2 minutes to the hour, anything else to discuss today?
20:59:03 <pbrobinson> nope! /me needs dinner!
20:59:31 <pwhalen> last call ...
20:59:54 <pwhalen> #endmeeting