20:00:23 <pwhalen> #startmeeting Fedora ARM weekly status meeting
20:00:23 <zodbot> Meeting started Wed Mar 20 20:00:23 2013 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:23 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore
20:00:23 <zodbot> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen
20:00:31 <bconoboy> .fas blc@
20:00:32 <zodbot> bconoboy: blc '' <blc@redhat.com>
20:00:33 <pwhalen> .fas pwhalen
20:00:35 <ctyler> .fas chris@tylers.info
20:00:35 <ctyler> Howdy all!
20:00:35 * pbrobinson waves
20:00:35 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
20:00:38 <zodbot> ctyler: ctyler 'Chris Tyler' <chris@tylers.info>
20:00:39 * masta looks in
20:00:43 <dmarlin> .fas dmarlin
20:00:44 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:00:56 * j_dulaney waves
20:00:56 <jsmith> .fas jsmith@
20:00:57 <zodbot> jsmith: 'jsmith@' Not Found!
20:01:07 <jonmasters> .fas jonmasters
20:01:08 <zodbot> jonmasters: jcm 'Jon Masters' <jonathan@jonmasters.org>
20:01:10 <jsmith> .fas jsmith
20:01:11 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com> - mikejsmith11 'Mike J. Smith ' <mikejsmith11@gmail.com>
20:01:13 <j_dulaney> .fas jdulaney
20:01:14 <zodbot> j_dulaney: iain 'John Dulaney' <jdulaney@starfishnet.com> - jdulaney 'John Dulaney' <j_dulaney@live.com>
20:01:23 <masta> .fas parasense
20:01:24 <j_dulaney> Oops
20:01:24 <zodbot> masta: parasense 'Jon Disnard' <jdisnard@gmail.com>
20:01:24 <bconoboy> jsmith: I use blc@ since 'blc' is ambiguous
20:01:32 <j_dulaney> Okay
20:01:35 <jsmith> bconoboy: I tied that and failed :-(
20:01:37 <jcapik> .fas jcapik
20:01:38 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:01:43 * j_dulaney has two fases, it seems
20:01:55 <bconoboy> jsmith: there is only one jsmith :-)
20:01:58 <pbrobinson> first agenda item?
20:02:04 <jsmith> bconoboy: Thank goodness!
20:02:07 <pwhalen> #topic 0) Status of ACTION items from our previous meeting
20:02:36 <pwhalen> #info - COMPLETE - ahs3 to do another package scan this evening for aarch64 patching, send to the list for review
20:03:28 <pwhalen> #info - INPROGRESS - pbrobinson/dgilmore to provide feedback on aarch64 patches
20:04:03 <pwhalen> I know their busying filing bugs now, so no feedback iiuc
20:04:10 <pbrobinson> it's still in progress, due to other escalations we've been slower than planned, hope to close the mass bug spam by EOW
20:04:55 <pwhalen> excellent
20:04:59 <bconoboy> pbrobinson: if there is very little uptake are you planning on checking in some yourself?
20:05:17 <pbrobinson> checking in some what?
20:05:22 <bconoboy> the patches
20:05:27 <bconoboy> if maintainers don't respond
20:05:30 <j_dulaney> bconoboy:  I volunteer to herd the cats
20:05:42 * j_dulaney helped do that for systemd
20:05:45 <pbrobinson> lets get the bugs reported first and check the up take and go from there
20:06:08 <pbrobinson> rough plan is to give them a couple of weeks and then slice and dice
20:06:11 <ahs3> +1
20:06:27 <pbrobinson> priotise the core packages
20:06:39 <bconoboy> okay, sounds good
20:06:39 <j_dulaney> ie, crit path
20:06:45 <pbrobinson> divide those up with people that have approp rights
20:06:59 <bconoboy> I can provide a high priority list if needed
20:07:00 <masta> sounds good
20:07:20 <jonmasters> ok
20:07:24 <jonmasters> is there a tracker bug?
20:07:28 <pwhalen> we do have aarch64 patching on the agenda for today, ready for problem packages?
20:07:29 <pbrobinson> bconoboy: we're not at that stage yet
20:07:29 <masta> bconoboy: sure, go for it
20:07:43 <pbrobinson> jonmasters: you're cc:ed on the tracker, check your mail
20:07:47 <bconoboy> pbrobinson: sure, waiting a couple weeks first makes sense
20:08:03 <j_dulaney> pbrobinson:  Could you cc me, as well?
20:08:04 <pbrobinson> I don't see the point in doing a bunch of work if the maintainers will
20:08:34 <pbrobinson> j_dulaney: I believe I added it to the armtracker, else I'll dig it out
20:08:46 <jcapik> what priority/severity will the bugs have?
20:09:16 <pbrobinson> standard prio/sev because that's what it is
20:09:30 * nirik notes fedora doesn't use those fields, it doesn't matter what they are. ;)
20:09:46 <bconoboy> pwhalen: anything else on the list from last week?
20:09:51 <jcapik> nirik: maintainers care about those fields
20:09:55 <pbrobinson> #info bug is https://bugzilla.redhat.com/show_bug.cgi?id=922257 Alias is ARM64
20:10:04 <nirik> they can optionally, I don't know any who do off hand. ;)
20:10:05 <pwhalen> bconoboy, no, that was it
20:10:19 <pwhalen> #topic 1) Problem Packages
20:10:34 <pbrobinson> we won't set them by default, I refuse, if the maintainer uses them that's up to them
20:11:09 <pwhalen> we had tog-pegasus, java, python-pillow last week
20:11:19 <pbrobinson> java is still #1. Comms from maintainers said they'll have something this week. Not holding breath, heard it all before!
20:11:26 <pbrobinson> py-pillow I've fixed
20:11:38 <bconoboy> #info java still outstanding- devs say it will be done by end of week
20:11:38 <pbrobinson> tog-p is still broken
20:11:47 <bconoboy> #info py-pillow is fixed
20:11:50 <bconoboy> bz for tog-p?
20:11:59 * pbrobinson looking
20:12:21 <pbrobinson> https://bugzilla.redhat.com/show_bug.cgi?id=922770
20:12:35 <bconoboy> #bz tog-python is broken, https://bugzilla.redhat.com/show_bug.cgi?id=922770
20:12:39 <bconoboy> oops
20:12:43 <bconoboy> #link tog-python is broken, https://bugzilla.redhat.com/show_bug.cgi?id=922770
20:12:55 <pwhalen> thought that was a new one :)
20:12:56 <pbrobinson> this week we've added some ruby packages, would like someone who knows that stuff that can help out
20:13:01 <bconoboy> #info Other misc broken packages:
20:13:04 <bconoboy> #link javasqlite: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1584679
20:13:05 <bconoboy> #link pure: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1498064
20:13:05 <bconoboy> #link OpenImageIO: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1606987
20:13:05 <bconoboy> #link pygrub: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1607151
20:13:17 <bconoboy> Any ruby devs here?
20:13:17 <pwhalen> I think pygrub is fixed
20:13:25 <bconoboy> is it?
20:13:26 <bconoboy> #undo
20:13:26 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x29996490>
20:13:31 <pwhalen> pygrib
20:13:36 <pbrobinson> yep, pygrib (not grub) is fixed.
20:13:38 <pwhalen> yes, it just needed a non shadow submit
20:14:17 <pbrobinson> I don't have the ruby packages on hand but anyone can ping me if they can help
20:14:18 <bconoboy> cool
20:14:32 <bconoboy> #info If you know Ruby please ping pbrobinson
20:15:03 <pwhalen> anything else?
20:15:04 <jcapik> I have few colleagues who know ruby and python
20:15:20 <pbrobinson> I've starting to do some stats on other leaf packages so will post a list to the arm@list soon
20:15:32 <bconoboy> 3.9 kernel update? or is that later?
20:15:38 <pbrobinson> later
20:15:48 <pbrobinson> kernel can be separate
20:15:50 <bconoboy> #action pbrobinson to post a list of leaf packages to arm@lists.fp.o
20:16:18 <pwhalen> #topic 2) Aarch64 patching
20:16:27 <pbrobinson> wasn't that covered?
20:16:34 <pwhalen> you guys covered it at the beginning, anything else you want to discuss?
20:16:36 <pbrobinson> in outstanding
20:16:51 <pwhalen> ok
20:17:00 <pbrobinson> unless ahs3 has something to add
20:17:06 <pbrobinson> or jonmasters
20:17:27 <pwhalen> ok. moving on then..
20:17:36 <ahs3> nope, nothing from me
20:17:43 <pwhalen> #topic 3) Creating test candidate images for F19
20:17:59 <jonmasters> nothing else from me at this point on aarch64
20:18:05 <bconoboy> dmarlin?
20:18:10 <pwhalen> not sure if dgilmore is around, but do we have a plan for images?
20:18:25 <bconoboy> I think this is where we talk about the state of live-media creator.
20:18:30 <pbrobinson> he's not that I'm aware
20:18:45 <pwhalen> he mentioned he would likely not be here
20:18:49 <dmarlin> bconoboy: at the moment livemedia-creator in f19 is a non-starter
20:18:51 <pbrobinson> presumably this is blocking on the tool that dgilmore spoke about
20:18:55 <j_dulaney> dgilmore is asleep, I believe
20:19:09 <pbrobinson> he's not asleep
20:19:09 <masta> oh dang, I forgot to send dgilmore patches for moving our kickstarts to the spins-kickstarts
20:19:10 <bconoboy> #info livemedia-creator in f19 is broken meaning we cannot use it to make f19 images
20:19:21 <pbrobinson> masta: I have commit for that as well
20:19:23 <dmarlin> bconoboy: I tried using f18 to make f19 images, but no kernel is installed (multiplatform issue)
20:19:46 <bconoboy> #info Using fedora 18's livemedia-creator to make f19 images results in problems due to the emerging unified kernel
20:20:19 <dgilmore> bconoboy: using a previous release to make images is never acceptable
20:20:30 * dgilmore just got here
20:20:30 <masta> what is the details of this problem?
20:20:40 <dgilmore> we need to fix anaconda propperly
20:20:52 <bconoboy> dgilmore: Which means we really need to fix this situation :-)
20:21:04 <masta> so the problem involves the install and handling of the kernel rpm?
20:21:07 <bconoboy> dmarlin: Is it fair to say the kernel issue with f18's lmc is likely present in f19 as well?
20:21:19 <dmarlin> bconoboy: yea
20:21:21 <dgilmore> bconoboy: there is a lot of things we need to fix
20:21:46 <dmarlin> dgilmore: right now, f19 won't even make PA images, IIUC
20:21:53 <pbrobinson> it was discussed in dgilmore's email to the list and only bconoboy has bothered to reply
20:22:24 <dgilmore> dmarlin: possibly not, lots of things are broken in fun ways, and they all need fixing not bypassing and papering over
20:22:25 <fossjon> should there be a wiki with a prioritized list of things to fix?
20:22:27 <bconoboy> pbrobinson: that's the boot thing- this is just making images, one step removed
20:22:45 <pbrobinson> bconoboy: not completely
20:22:46 <dmarlin> dgilmore: and I think the anaconda team is diligently working on it
20:22:49 <dgilmore> bconoboy: its one and the same
20:23:02 <bconoboy> dgilmore: Well, we need both to work, that's for sure
20:23:27 <bconoboy> So we have a bunch of things that need to be worked out, here's my naive list:
20:23:30 <pbrobinson> bconoboy: ultimately anaconda want something from us to call, preferably as a library
20:23:36 <bconoboy> 1. lmc actually builds images (working or not)
20:23:48 <bconoboy> 2. pulling in the right kernel when composing images
20:24:07 <bconoboy> 3. using a kickstart we all agree on
20:24:13 <bconoboy> 4. generated image actually boots
20:24:24 <bconoboy> of those, only #1 is being worked on.
20:24:34 <bconoboy> and only for primary- so it it works for arm it's a coincidence
20:24:41 <dmarlin> bconoboy: and configuring the bootloader (script)
20:24:53 <pbrobinson> bconoboy: kernel is easy.... other than tegra (which we only nominally support) it's one kernel for F19.
20:24:54 <bconoboy> dmarlin: yeah, that's #4 I think
20:25:04 <bconoboy> pbrobinson: Okay, that's good info!
20:25:08 <jonmasters> (aside - about that list thread, we have discussed the platform/dt stuff, but currently decided to hold pending dmarlin investigating the Linaro GRUB2 U-Boot port)
20:25:13 <bconoboy> #info F19 kernel will be unified except for tegra
20:25:28 <pbrobinson> it's all about the bootloader / dtb selection and whether we need a fatfs and if so what uboot
20:25:36 <bconoboy> pbrobinson: Is there any chance we can get tegra running unified?
20:25:38 <dmarlin> bconoboy: #4 is getting a working load address in the image
20:25:40 <dmarlin> ?
20:25:52 <pbrobinson> I think we do a omap and a "unified" (ie without fatfs) image
20:25:55 <bconoboy> dmarlin: load address, dtb, yes
20:26:11 * ctyler hopes Samsung lands their Exynos5 clock code pre-3.9
20:26:13 <pbrobinson> bconoboy: not for final as final will be 3.9 kernel
20:26:28 <pbrobinson> ctyler: it won't be in 3.9
20:26:33 <bconoboy> I'd like to propose something that I have not thought through: How about F19 only supports unified kernel?
20:26:36 <dmarlin> bconoboy: but with a unified kernel, there will be only one load address.  how will that work across platforms
20:26:42 <pbrobinson> ctyler: and exynos isn't unified yet either so it's off the list
20:26:49 <jonmasters> bconoboy: I like that idea :)
20:27:02 <pwhalen> I notice ubuntu only supports omap4 and server installs now
20:27:03 <bconoboy> Anything that isn't unified we can treat as a remix.
20:27:05 <pbrobinson> bconoboy: I've thought of that, I've even discussed it with jonmasters
20:27:11 <dgilmore> bconoboy: there is a very high chance we will only have a unified kernel for f19
20:27:23 <dgilmore> bconoboy: we will need to have a omap and  other image
20:27:30 <bconoboy> Considering the sorry state of trimslice uboot support I don't mind dropping it
20:27:43 <dgilmore> bconoboy: because of teh different (i.e. vfat partitioon) boot requirements on omap
20:27:45 <bconoboy> dgilmore: perhaps multiple omap images
20:27:45 <pbrobinson> dgilmore: bconoboy: exactly, and do trimslice/tegra as a remix
20:28:07 <jonmasters> +1
20:28:14 <pbrobinson> dgilmore: bconoboy: panda and bbone need differnet uboot unfortunately
20:28:20 <dgilmore> bconoboy: one with a empty vfat partition, and a tool to put the right boot bits in place
20:28:39 <bconoboy> dgilmore: That seems like a good idea to me.
20:28:48 <masta> I will miss the trimslice, but I would support dropping it due to bad u-boot
20:29:04 <jonmasters> if - if - the GRUB2 stuff is supported by the U-Boots we have on our official targets, that would also clean up loading
20:29:07 <masta> but I still like the idea of non-unified images
20:29:21 <ctyler> So non-unified (remix) will be trimslice/tegra and exynos5/arndale/chromebook
20:29:28 <bconoboy> folks can still install f18 on their trimslice and yum update, or they can use an f19 remix for trimslice
20:29:38 <dgilmore> ctyler: remixes are out of our scope
20:29:47 <bconoboy> #idea Let's just use a unified kernel for F19
20:30:00 <bconoboy> #idea Anything not in unified is treated as a remix
20:30:02 <pbrobinson> dgilmore: bconoboy: like han's tool used for the allwinner
20:30:03 <ctyler> dgilmore: I'm trying to understand what we're dropping out of our scope
20:30:08 <masta> as long as we provide a good rootfs we be nice people about dropping official images and going the way of remix
20:30:09 <jonmasters> #info agree on unified only f19 kernel
20:30:14 <dgilmore> pbrobinson: similiar yes
20:30:28 <bconoboy> masta: Yeah, we'll still make a rootfs available
20:30:34 <masta> ok then
20:30:35 <masta> +1
20:30:39 <bconoboy> ... that's been very popular in f18 and we should keep it
20:30:40 <dmarlin> jonmasters: have we worked out how to handle the different load addresses (zreladdr) with a unified kernel?
20:31:11 <pbrobinson> masta: bconoboy: it would be using the unified image and just changing the kernel
20:31:12 <jonmasters> dmarlin: this is why I requested you look at GRUB2
20:31:28 <jonmasters> dmarlin: we need to know what the capability there is before we come back to the DT/other stuff
20:31:34 <dmarlin> ok
20:31:59 <pbrobinson> jonmasters: it's not upstream yet.......
20:32:03 <j_dulaney> dmarlin:  I'd like to help with grub2; at the least it would be a learning experience
20:32:17 <jonmasters> dmarlin: if we can find that every target is supportable with GRUB2 (i.e. all the U-Boot versions provide the U-Boot ABI that GRUB needs) then we can consider that as the load environment for the kernel
20:32:44 <masta> interesting
20:32:45 <bconoboy> pbrobinson: There is a uboot->grub2 chain loader that LEG have done.  dmarlin is evaluating its utility
20:32:53 <jonmasters> pbrobinson: understood, I just want to have some more data before we come back to whether we need to hack up DTBs. Haven't ignored that thread, just changing its direction
20:33:08 <bconoboy> pbrobinson: Which platforms can we support in 3.9 with a unified kernel?
20:33:23 <pbrobinson> jonmasters: we're nearing alpha.... need to be feature complete now!
20:33:39 <j_dulaney> +1
20:33:52 <j_dulaney> Hell, we need fucking images tomorrow
20:33:53 <pbrobinson> so platforms for 3.9 are omap/highbank/mvebu and some other minor ones
20:33:59 <masta> yes i'd like to know the things that work in unified, so I can plan which new dev boards to order
20:34:01 <jonmasters> default is we continue as before, no worse, except we still have the problem with anaconda and multiplatform kernels
20:34:11 <bconoboy> pbrobinson: vexpress lpae?
20:34:12 <pbrobinson> j_dulaney: we're not mainline and language please
20:34:18 <j_dulaney> Roger
20:34:34 <pbrobinson> bconoboy: yes, vexpress, there's a lpae kernel but will need testing
20:34:44 <j_dulaney> pbrobinson:  However, if you want to be mainline, then you'll not need to be way behind x86
20:34:47 <pbrobinson> so a9 and a15 vexpress possibly
20:35:05 <bconoboy> #info Unified kernel will minimally support omap, highbank, mvebu, vexpress (a9), possibly vexpress a15
20:35:10 <pbrobinson> j_dulaney: yep
20:35:38 <jonmasters> suggest dropping A9 vexpress if the A15 works fine (dmarlin is investigating)
20:35:40 <dmarlin> bconoboy: has anyone tested mvebu unified kernel ?
20:35:42 <masta> ok, so we need to get people with mvebu boards
20:35:52 <dgilmore> jonmasters: this is really all things that should have been sorted out
20:35:52 <masta> aka Marvel
20:35:55 <bconoboy> dmarlin: I tested pbrobinson's first version- no good
20:35:56 <pbrobinson> j_dulaney: ultimately in a lot of ways we're not far behind mainline, we need tools and anaconda
20:36:05 <ctyler> So the only lpae there is mvebu and possibly vexpress-a15
20:36:09 <dgilmore> Fedora 19 features are supposed to be testable not just getting worked out
20:36:26 <jonmasters> we've reached out to the mvebu folks, will update
20:36:34 <j_dulaney> +1 to dgilmore
20:36:48 <jonmasters> but for lpae suggest vexpress A15 as the official target for now
20:36:49 <pbrobinson> jonmasters: there will be an a9 kernel on the non lpae kernel, and a a15 kernel on lpae so you get both now shut up about vexpress a15 already
20:36:50 <bconoboy> For mvebu we have hardware inside RH- jsmith has a board too
20:37:07 <j_dulaney> pbrobinson:  What is missing tool-wise?
20:37:09 <jsmith> bconoboy: Two boards starting tomorrow
20:37:15 <j_dulaney> And why was this not poked a month ago?
20:37:19 <pbrobinson> ctyler: no mvebu for a15 as it's not upstream
20:37:24 <bconoboy> jsmith: you're a glutton for punishment
20:37:39 <pbrobinson> j_dulaney: anaconda and supporting tools.... see above
20:38:07 <pbrobinson> I have a cubox too on loan and that will work with mvebu
20:38:10 <j_dulaney> pbrobinson:  Which leads back to:  Why is it *now* that this is being discussed?
20:38:15 <jonmasters> pbrobinson: however only one vexpress target should be supported if there's a choice, no need to do both A9 and A15. But sure, we can leave that for now
20:38:26 <bconoboy> If the uboot->grub2 chain loader supports all targets and isn't invasive I'd like to use it, but we'll clearly have to follow process to get it in place.
20:38:49 <jonmasters> bconoboy: +1 let's find out in the coming days (dmarlin is going to look) and then we'll update the group
20:39:14 <pbrobinson> jonmasters: there is a choice of lpae and non lpae..... there's kernel issues enabling lpae across the board.... hence the reason we need the separate kernel.... that came from you.....
20:39:16 <bconoboy> Meanwhile, issues #1-4 are still on the table
20:39:29 <bconoboy> to reiterate:
20:39:30 <bconoboy> <bconoboy> 1. lmc actually builds images (working or not)
20:39:30 <bconoboy> <bconoboy> 2. pulling in the right kernel when composing images
20:39:30 <bconoboy> <bconoboy> 3. using a kickstart we all agree on
20:39:30 <bconoboy> <bconoboy> 4. generated image actually boots
20:39:36 <bconoboy> #1 is being worked on upstream
20:39:55 <bconoboy> It sounds like #2 we may need to do some work to harness the unified kernel
20:40:04 <jonmasters> pbrobinson: ah, not disagreeing just setting an expectation for e.g. what we say we support. So vexpress can be A9 or A15 and I'm saying e.g. on the wiki we will only give instructions for installing/using vexpress A15 kernel. Anyway, let's move on.
20:40:10 <bconoboy> How to do that is outstanding- let's push it to next week.
20:40:12 <dgilmore> bconoboy: not really how i see it
20:40:15 <pbrobinson> bconoboy: grub won't be in there for F19.... it's not upstream and we don't want to pull it in post alpha and cause issues with mainline
20:40:20 <bconoboy> For #3, who is managing kickstarts?
20:40:38 <dgilmore> bconoboy: kickstarts is managed through spins-kickstarts
20:40:40 <j_dulaney> bconoboy:  Easy solution to #2:  Use a different repo for each image
20:40:59 <pbrobinson> jonmasters: that's the point i've been trying to make to you for weeks.... thanks
20:41:02 <dgilmore> j_dulaney: not viable
20:41:17 <bconoboy> dgilmore: Okay, since you end up composing images are you saying that spins-kickstarts is the right forum to ensure consensus on content?
20:41:22 <j_dulaney> For #3, go with the default xfce kicstart and modify to support arm
20:41:27 <dgilmore> bconoboy: yes
20:41:39 <dgilmore> j_dulaney: no
20:41:54 <bconoboy> #agreed The spins-kickstarts repo will be used to generate official f19 images- get your changes in!
20:41:58 <dgilmore> j_dulaney: ive been splitting out the package lists
20:42:08 <j_dulaney> Ah
20:42:11 <dgilmore> all thats needed is the arm specific snippets
20:42:18 <bconoboy> #4 is pending like #2
20:42:18 <j_dulaney> Okay
20:42:19 <dgilmore> and include the package lists
20:42:31 <bconoboy> dgilmore: Have you made any progress on your boot.scr generator idea?
20:42:37 <dgilmore> bconoboy: 2 will be unified kernel
20:43:10 <masta> yep, %post snips and %package snips should be %included from files
20:43:12 <dgilmore> bconoboy: ive slowly been working on it. it will be more than just boot.scr
20:43:41 <bconoboy> dgilmore: Cool, thanks
20:43:45 <bconoboy> next topic?
20:44:11 <pwhalen> #topic 4) Open Floor
20:44:13 <dgilmore> bconoboy: please
20:44:27 <pbrobinson> so kernel update here?
20:44:34 <bconoboy> please
20:45:50 <jonmasters> pwhalen is looking at highbank issues. I've asked him to build a debug kernel, we'll sync with Mark
20:45:50 <pbrobinson> so 3.8.x has gone out to stable. We've had mixed results with highbank, vexpress has issues but the rest look OK and we need to move forward
20:46:01 <pbrobinson> we can iterate 3.8 as necessary
20:46:28 <pwhalen> vexpress 3.8+ will only work on f19 qemu
20:46:39 <jonmasters> (on vexpress, agree, and we just have to say not-ideal situation of e.g. F19 qemu)
20:46:41 <pbrobinson> I'll send out and update to list
20:46:51 <bconoboy> #info 3.8.x has gone out to stable.  The vexpress version needs F19's qemu to boot.  Some highbank issues in 3.8.
20:46:53 <pbrobinson> followup on my previous email
20:46:55 <mlangsdorf> I'm working with pwhalen on the hgihbank kernel.
20:47:19 <mlangsdorf> I think the problem is DTB related because I can't reproduce it locally.
20:47:22 <bconoboy> #action pwhalen and mlangsdorf are working on the highbank issues- every reason to expect a speedy recovery
20:47:47 <pbrobinson> mlangsdorf: I have no idea how many devices you have out there but the "need to patch the dtb" isn't really enterprise so it would be nice to have an updated firmware
20:48:51 <pbrobinson> mlangsdorf: can you test the 2.1.5 firmware, also what revision of the SoC (or energy card) is being tested here
20:48:56 <mlangsdorf> probinson: no kidding. i'm pushing the issue internally.
20:49:21 <mlangsdorf> probinson: i'm using x04s. i'll try to test the 2.1.5 firmware and confirm Paul's issues by the end of the week.
20:49:29 <pbrobinson> thanks!
20:49:51 <bconoboy> we are likewise using x04s for testing
20:49:52 <pwhalen> mlangsdorf, thanks
20:50:01 <pbrobinson> on 3.9 I did the first mass pass for bringing in omap to unified and adding a lpae. There's some issues with usb conflicting between mvebu and omap and I'm going to need to pull in some patches
20:50:15 <pbrobinson> I plan to have something for testing over the weekend because work this week has been hell
20:51:13 <pbrobinson> I'm also looking for a way to make it easier for people to build their own configs for the 3.9 kernel.
20:51:25 <pbrobinson> which would likely help ctyler with exynos builds
20:51:47 <pbrobinson> that's me done mostly
20:51:52 <bconoboy> is exynos in 3.9 far enough along for chromebook use?
20:52:13 <masta> no video
20:52:15 <bconoboy> #action pbrobinson will update 3.9 kernel config over weekend and spin out a new test build
20:52:45 * pbrobinson wonders if I managed to land all the action items :-P
20:53:01 <j_dulaney> bconoboy:  You can ssh in, but the screen is black with 3.9
20:53:05 <bconoboy> #agreed pbrobinson is a man of action
20:53:40 <jonmasters> bconoboy: it's like a said with 3.9 on Chromebook - it's good enough for e.g. virt folks to play but not for a desktop
20:53:47 <pbrobinson> right, anything else? I'm hank marvin.....
20:53:56 <bconoboy> #info goal for new 3.9 test build is to resolve usb driver conflicts between omap and mvebu
20:54:15 <bconoboy> anybody else have something for open floor?
20:54:18 <pbrobinson> which will allow it to actually build ;-)
20:54:31 <pwhalen> going once..
20:55:02 <pwhalen> #endmeeting