20:00:19 <pwhalen> #startmeeting
20:00:19 <zodbot> Meeting started Wed Oct 10 20:00:19 2012 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:19 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore
20:00:19 <zodbot> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen
20:00:30 * masta waves
20:00:31 <pwhalen> .fas pwhalen
20:00:33 <dmarlin> .fas dmarlin
20:00:34 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
20:00:36 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:00:41 <rsc> .fas Robert Scheck
20:00:42 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:01:13 <revident> .fas revident
20:01:15 <zodbot> revident: srsullivan 'Scott Sullivan' <scott@ss.org>
20:01:23 <bconoboy> .fas blc@
20:01:23 <zodbot> bconoboy: blc '' <blc@redhat.com>
20:01:57 * ahs3 pays attention...
20:02:09 * pbrobinson waves
20:02:19 <dgilmore> hola
20:02:23 <pwhalen> #topic 1) F18/19 Build status - problem packages
20:02:41 <jcapik> .fas jcapik
20:02:42 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:03:12 <pwhalen> pbrobinson, not sure if theres anything to discuss here?
20:03:16 <pbrobinson> a few minor ones higher up the stack. Eclipse is being worked upon. Nothing of major interest.
20:03:26 <bconoboy> Why is F19 so far behind?
20:03:27 <pbrobinson> I'm working more on the kernel
20:04:15 <masta> the kernel seems to be *the* problem package lately :(
20:04:34 <pbrobinson> bconoboy: it's not compared to a week or so ago. It's around 1400 now, it was up around 2000 so we're coming down but the reason it's taking so long is because koji is really slooooow while the raid rebuild is happening and that is still going on
20:04:49 <pbrobinson> masta: lately??? it always is :-P
20:05:04 <dgilmore> bconoboy: the raid rebuild looks like it will go for another week
20:05:10 <bconoboy> a week!?
20:05:12 <dgilmore> its majorly slowing down everything
20:05:18 <dgilmore> yes
20:05:26 <bconoboy> how big is this array?
20:05:38 <pbrobinson> it's glacial
20:05:43 <bconoboy> why?
20:06:02 <bconoboy> did somebody forget to bump up the dev.raid.speed_limit_min sysctl?
20:06:03 <masta> would the raid rebuild go faster if koji-shadow were acquiesced?
20:06:04 <pbrobinson> it's a weird configuration and isn't an enterprise platform?
20:06:13 <rsc> what does big mean in GB or TB and is it SW or HW raid?
20:06:48 <dgilmore> rsc: its a weird setup ~3tb
20:06:50 <pbrobinson> TB and SW, but ultimately it's not the only considerations
20:06:50 <bconoboy> can anybody at seneca comment on this?
20:07:08 <dgilmore> thereis  a raid0 of ssds thats setup with a raid1 to a real dis
20:07:10 <dgilmore> disk
20:07:22 <rsc> dgilmore: define weird? And why is it a SW raid?
20:07:32 <dgilmore> the sata disk was added back in and the raid1 sync is taking a long long time
20:07:58 <dgilmore> rsc: i just explained how its setup
20:08:32 <rsc> dgilmore: why can't we use a bunch of huge disks + a powerful HW raid?
20:08:46 <masta> so it's a raid 0+1
20:09:02 <bconoboy> So it's filesystem(raid1(raid0(ssd1,2,3,4),(spinnydisk)))
20:09:27 <bconoboy> there is no reason this should take more than 2 days
20:09:48 <dgilmore> bconoboy: its been going for a week
20:09:59 <dgilmore> and has about 1 week more to go
20:10:02 <revident> did someone forget to change the BIOS to AHCI mode for the SATA?
20:10:05 <pbrobinson> rsc: basically it's historical and the reason is of no real significance and it's been discussed no end over the last couple of years
20:10:42 <rsc> pbrobinson: okay. Means somebody needs to donate new HW?
20:10:53 <pbrobinson> masta: it's balanced 0+1 with reads coming from the SSD for speed but using the HDD for resilience
20:11:19 <bconoboy> okay, let's continue this one at the end of the meeting
20:11:20 <masta> so for another week we will live with slow mode
20:11:28 <masta> nothing we can do about this
20:11:46 <pwhalen> #topic 2) Uboot on OMAP - status update (2012.07, 2012.10)
20:12:00 <dgilmore> masta: correct
20:12:10 <pwhalen> it works! sorry about the misleading reports, all is fine when using the correct MLO
20:12:17 <dgilmore> pwhalen: ok
20:12:25 <bconoboy> #info OMAP is now working
20:12:46 <pbrobinson> nope, but we're mostly keeping up with f18 and I'm now running two rawhide koji-shadow instances and we're slowly catching up so it's not all bad, it's just the reason we're not as fast as we'd like and why there's issues with mashing and hence syncing out the latest updates to mirrors as the mash is high IO
20:13:09 <pwhalen> not sure if there was anything else to add here. Perhaps some information on our wiki about how users would upgrade uboot as you have to do it manually, and replacing the MLO is required
20:13:09 <dmarlin> pwhalen: please point to the test matrix showing the uboot and kernel version on which rootfs
20:13:45 <bconoboy> For F18 won't we be providing an updated mlo/uboot for omap targets?
20:13:47 <pwhalen> dmarlin, sounds like your referring to the device tree testing I've done
20:14:02 <dmarlin> pwhalen: no, just for the uboot on omap
20:14:15 <pwhalen> no such matrix
20:14:16 <dmarlin> pwhalen: what combination is known to work
20:14:36 <dgilmore> pwhalen: did you test with dt?
20:14:36 <dmarlin> (tested, functional boot and usb network)
20:14:42 <pwhalen> dmarlin, you need to use the MLO packed with that specific version of uboot
20:14:59 <pwhalen> dgilmore, I did, no change there
20:15:30 <pwhalen> I've tested 2012.07, 2012.10 uboots, both working
20:16:07 <dmarlin> pwhalen: with which kernel?
20:16:07 * masta notes omapdrm is working again for hdmi/dvi. wifi needs to be tested, it was broken durring 3.4/3.5 on panda.
20:16:50 <pwhalen> dmarlin, 3.6.0-3
20:16:55 <dmarlin> pwhalen: thanks
20:17:37 <pwhalen> move on?
20:17:40 <dmarlin> I'm making an f18 image that includes uboot-panda-2012.07-0.2.rc1.fc18.armv7hl and kernel-omap-3.6.0-3.fc18.armv7hl
20:17:46 <pbrobinson> so I believe we should be using 12.10 rc as we should be releasing F18 with 12.10 final and a 3.6.x kernel
20:17:56 <dgilmore> dmarlin: that uboot is not the latest stable uboot
20:18:12 <dmarlin> dgilmore: it's what we have in the repo
20:18:19 <dmarlin> dgilmore: and that's what I use
20:18:21 <pbrobinson> dgilmore: the latest isn't on the mirrrors yet I don't think. It might be in updates-testing though
20:18:35 <dgilmore> arm-koji latest-pkg f18 uboot-tools
20:18:35 <dgilmore> Build                                     Tag                   Built by
20:18:38 <dgilmore> ----------------------------------------  --------------------  ----------------
20:18:40 <pbrobinson> dmarlin: we should be turning on updates-testing for an alpha release
20:18:41 <dgilmore> uboot-tools-2012.07-1.fc18                f18                   pbrobinson
20:18:52 <dgilmore> dmarlin: its is not what should be in the repo
20:19:03 <dgilmore> if it is thats due to the io issues in koji
20:19:14 <dmarlin> exactly
20:19:49 <pbrobinson> dgilmore: http://alt.fedoraproject.org/pub/fedora-secondary/development/18/armhfp/os/Packages/u/
20:20:03 <dgilmore> pbrobinson: yeah that tree is a week old
20:20:59 <pbrobinson> dgilmore: exactly, so while 12.07 final should be there it's not because the tree on the mirrors is a week old :)
20:21:24 <pbrobinson> but it is in updates-testing.
20:21:45 <pbrobinson> dmarlin: turn on t he updates-testing repo and you'll get the right uboot
20:22:09 <masta> proposal:  can we agree that for image creation we use update-testing?
20:22:30 <masta> got my +1
20:22:49 <dmarlin> can we expect more broken images if we do?
20:22:56 <dmarlin> (things untested)
20:23:03 <dgilmore> masta: -1
20:23:03 <pbrobinson> for alpha releases I have no issues with using updates-testing
20:23:11 <dgilmore> its not whats done on primary
20:23:33 <dgilmore> but we have a process to pull builds in into a side repo on primary
20:23:40 <dgilmore> we should pull the correct uboot in
20:24:15 <masta> so aligning to primary has more weight over pragmatic things like adding the testing repo??
20:24:34 <pbrobinson> yes, but to at least get some images out even for testing in the short term until we can mash and actually push to mirrors I see no problem with it. call it alpha TC1 or something
20:24:49 <dgilmore> as a test compose add updates-testing
20:24:55 <dgilmore> but not a RC compose
20:25:06 <dmarlin> masta: if it fails testing on primary, do we really want it in our images?
20:25:15 <masta> fair enough
20:25:18 <pbrobinson> call it alpha+updates-testing-TC1-may-kill-your-cat even
20:25:35 <dgilmore> pbrobinson: :)
20:25:50 <pbrobinson> dmarlin: there's a lot of differences between here and primary at the moment
20:26:19 <masta> I'll take back my vote and go +0 in light of being able to test compose
20:26:23 <pbrobinson> and the package set isn't even the same as mainline alpha so the point is some what mute at this particular point in time
20:27:37 <pwhalen> anyone have differing opinions? or all agreed?
20:27:43 <dgilmore> pbrobinson: we do have a f18-Alpha tag thats pretty close to primary alpha
20:28:34 <dgilmore> but im ok with whats stable today being used for alpha, lets do a TC with updates-testing enabled, then a RC when we get a completed f18 branched mash
20:28:48 <pbrobinson> dgilmore: but there's core things in there like the kernel that break that so it's still a mute point
20:29:02 <pwhalen> dgilmore, +1
20:29:23 <dmarlin> dgilmore: +1
20:29:36 <masta> dgilmore: +1
20:29:46 <bconoboy> dgilmore: +1
20:29:46 <pbrobinson> and ultimately it's also a package set in the past so I don't see much point in doing massive testing against something that is old and in the past and hence not that relevant as to where we need to be aiming which is beta
20:29:48 <jcapik> +1
20:29:58 <masta> so this goes back to waitting a week for the repo to get happy, right?
20:30:05 <dgilmore> pbrobinson: right
20:30:06 <bconoboy> #info We'll use the current source base for f18arm alpha rather than the source base of primary alpha
20:30:09 <pwhalen> #agreed release f18 alpha TC with updatse-testing enabled
20:30:17 <dgilmore> masta: hopefully not a week
20:30:28 <pbrobinson> masta: no, if we include updates-testing while we get the mash in order it allows us to move forward
20:30:52 <dgilmore> we can get some good testing from a TC
20:31:05 <pwhalen> #topic 3) Reverting the Highbank alignment patch
20:31:43 <dmarlin> I think we have upstream agreement this is the best approach in the short term while a real solution is worked out
20:31:54 <masta> so this is going into mainline later, we are doing this in in our kernel?
20:32:52 <dmarlin> reverting the patch in our kernel, is my understanding... jonmasters ?
20:33:21 <masta> can somebody tell me like I'm five, what is the impact of this?
20:34:12 <dmarlin> masta: a recent patch exposed a latent bug (missalignment)... this patch reverts it until the bug can be fixed
20:34:14 <pbrobinson> dmarlin: what upstream agreement, no one has managed to point me to that discussion so I can see the agreement
20:35:05 <pbrobinson> masta: me too because I don't yet see any discussion about it and what the problem is, just a non upstreamed patch thrown at me and being told to apply it.
20:35:20 <dmarlin> pbrobinson: I think you were cc'd on several emails showing buy-in from the parties involved
20:35:51 <pbrobinson> I need to see the upstream discussion so I can reference it rather than a random "Yes, this is the agreement of upstream I promise"
20:36:21 <masta> looks like jcm is posting to g+ durring this meeting, can somebody bump him out of band to join the discussion?
20:36:32 <bconoboy> pbrobinson: I think you're saying you need to be able to reference a public discussion so third parties can look and see?
20:36:34 <pbrobinson> dmarlin: a closed email with responses from just you and jon is not an upstream discussion with buy in from the mainline kernel maintainers
20:37:13 <dgilmore> bconoboy: exactly
20:37:22 <masta> oh wait, is this the IPv6 thing?
20:37:23 <pbrobinson> bconoboy: yes, a public mailing list discussion, that's what I mean by upstream mailing list referenced discussions
20:38:52 <bconoboy> preetty sure jonmasters is on his way to the airport
20:39:09 <bconoboy> perhaps somebody who has been on this private email thread would ask the others to take it public?
20:39:53 <dmarlin> bconoboy: sure, I'll follow up
20:40:29 <bconoboy> #info dmarlin to ask kernel maintainers to publicly support reverting a patch that is causing issues
20:40:33 <bconoboy> #unfo
20:40:35 <bconoboy> #undo
20:40:35 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x26786ed0>
20:40:41 <bconoboy> #action dmarlin to ask kernel maintainers to publicly support reverting a patch that is causing issues
20:40:45 <pbrobinson> bconoboy: the indications from jonmasters is that the discussion has happened, I haven't seen it, I have no idea which of the dozen kernel mailing lists it could have occurred on to even begin to search if I had the time to actually troll the lists
20:41:11 <pwhalen> I think the mailing list item may have been posted in channel on Friday
20:41:18 <bconoboy> pbrobinson: Right- once we have a pointer for you and there is public consensus, we're all set from your standpoint though, yes?
20:41:51 <masta> would be nice to write the link to whatever list in the comment for this revert... so we can know WTF
20:42:18 <masta> just saying
20:42:31 <pbrobinson> bconoboy: yes
20:42:55 <dmarlin> pwhalen: do you have a link to that?
20:43:00 * dmarlin does not have that log
20:43:05 <bconoboy> #info Once public consensus is to revert patch, pbrobinson will pull it in
20:43:20 <pbrobinson> bconoboy: like with the sata patch which I pulled from mainline once it was there I don't have a problem with it
20:43:23 <pwhalen> no, scrollback doesnt go that far, looked back
20:43:27 <dmarlin> bconoboy: define "public consensus"
20:43:34 <pbrobinson> even just an upstream commit reverting it is fine
20:43:41 <pbrobinson> well it's better than nothing
20:44:02 <pwhalen> alright, next..
20:44:05 <pwhalen> #topic 4) Device tree testing
20:44:11 <dgilmore> something showing its the upstream direction
20:44:30 <pwhalen> #link http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Device_Tree_testing#Fedora_18
20:45:14 <pwhalen> theres the results of my testing so far, very interested to see what happens in 3.7. So far only vexpress has been booted successfully
20:45:15 <bconoboy> so vexpress works?
20:45:26 <masta> so device tree versus vendor provided u-boot : fight!
20:45:31 <pwhalen> bconoboy, it does, but just including the dtb
20:45:39 <dgilmore> masta: no
20:45:42 <pwhalen> s/but/by/
20:45:44 <bconoboy> pwhalen: You mean appending the dtb to the image?
20:46:15 <pwhalen> no, by just passing it to qemu.
20:46:41 <pwhalen> I have not tried appending yet, on any platform
20:46:42 <bconoboy> oh, as a flag. got it.
20:46:51 <bconoboy> I tried appending it on my trimslice.  No go.
20:46:57 <dmarlin> pwhalen: do we know if the kernel does anything with device tree on vexpress?
20:47:09 <masta> I believe the new trimslice uboot does the 3rd load addr thing, was hoping to setup a test doing that.
20:47:20 <dmarlin> (actually uses it)
20:47:26 <bconoboy> I tried the new uboot with dgilmore's trimslice dtb.  Also fails.
20:47:29 <pwhalen> when pbrobinson built 3.6 he mentioned enabling some bits specifically for vexpress
20:47:40 <bconoboy> Fails appended.  Fails loaded separately and passed as a parameter.  The system does not boot at all.
20:47:55 <bconoboy> this was with 3.6.0-1
20:47:59 <pbrobinson> pwhalen: I've enabled a lot of DT stuff all over, not just vexpress.
20:48:02 <bconoboy> Are we sure that dtb support is built into the kernels?
20:48:23 <pbrobinson> pwhalen: have you tested device tree on panda with the matching MLO and uboot as yet?
20:48:25 <pwhalen> pbrobinson, okay, you specifically were interested in vexpress though.
20:48:31 <bconoboy> Last week we thought MMC support was built in and it wasn't, so I'm wondering if it's the same thing here.
20:48:41 <pbrobinson> pwhalen: I'm interested in all of them ;-)
20:48:44 <pwhalen> pbrobinson, I did, no change when using the correct combo of MLO and uboot
20:49:07 * pbrobinson is looking for a page he has about DT on panda for reference
20:49:54 <pbrobinson> http://www.digipedia.pl/usenet/thread/19013/27691/
20:50:21 <pbrobinson> it says we need this:
20:50:21 <pbrobinson> +	select USE_OF
20:50:21 <pbrobinson> +	select ARM_APPENDED_DTB
20:50:21 <pbrobinson> +	select ARM_ATAG_DTB_COMPAT
20:50:21 <pbrobinson> +	select PROC_DEVICETREE
20:50:41 <pbrobinson> which I've enabled on the omap kernels (in fact in all arm kernels)
20:50:58 <pbrobinson> but that might be a reasonable start for others to look at as well
20:51:10 <pwhalen> dgilmore, mentioned that dt was default on omap as well
20:52:00 <dgilmore> pwhalen: yes the kernel enables both DT and board file support when you enable a SOC
20:52:22 <dgilmore> there was not specific SOC DT config options
20:52:49 <Frojoe> (Sorry about the late appearance.  The team had some Seneca business we had to deal with)
20:52:52 <bconoboy> pbrobinson: How recently were those options turned on?
20:53:07 <masta> pbrobinson: nice link
20:53:24 <bconoboy> (I just checked the config for the 3.6.1-1 tegra kernel and those options are indeed turned on)
20:53:57 <pbrobinson> bconoboy: when I cross checked most of them had been there for a while. They were all most definitely in the 3.6 final
20:54:32 <bconoboy> Okay, I'll double check with this version.
20:54:46 <pbrobinson> so that's one of the better "DT for dummies" I've managed to find to date, most of the DT stuff is for kernel developers, not end users
20:55:56 * masta will spend the next week hacking DT on panda/trimslice
20:56:14 <pbrobinson> masta++
20:56:31 <pwhalen> CONFIG_MACH_TEGRA_DT=y, CONFIG_MACH_OMAP_DT=y are missing from the configs in boot, yet they appear in the fedora configs.
20:56:58 <masta> those look important
20:57:37 * pbrobinson will check the generation/inheritance for that tehn
20:57:39 <pbrobinson> then
20:58:10 <bconoboy> #action pbrobinson to check kernel config to ensure all necessary _DT options are turned on
20:58:41 <pwhalen> pbrobinson, thank
20:58:45 <pwhalen> thanks
20:58:57 <pwhalen> #topic 5) Raspberry Pi status update
20:59:08 <masta> pbrobinson: thanks in advance for checking on those DT options
20:59:11 <dgilmore> [dennis@adria kernel (f18)]$ grep -r CONFIG_MACH_OMAP_DT kernel-3.6.fc18/linux-3.6.0-3.fc18.x86_64/
20:59:15 <dgilmore> [dennis@adria kernel (f18)]$
20:59:49 <Frojoe> We're fixing up some issues in a couple of the educational packages we're shipping in the remix
21:00:25 <bconoboy> frojoe: Is there going to be a final f17 remix?
21:00:28 <Frojoe> And we're gearing up for release very soon.   I don't have word on what the consensus is
21:00:30 <pbrobinson> Frojoe: ETA? I'm seriously getting sick of A) lack of updates B) being asked when it's going to be released
21:01:15 <masta> Frojoe: release early, release often :)
21:01:16 <dgilmore> pbrobinson: indeed, open communications are a must
21:01:19 <pbrobinson> Frojoe: this week? Month? before F-18 mainline? This year? I've been hearing "soon" for a long time
21:01:39 <Frojoe> As I said, I'm out of the loop when it comes to that decision.  Before the end of the month to be sure
21:01:53 <bconoboy> frojoe: whose decision is it?
21:01:56 <pbrobinson> Frojoe: so who is in the loop?
21:02:02 <pbrobinson> and why aren't they here?
21:02:19 <Frojoe> I think it is Ctyler who has final say
21:02:20 <dgilmore> Frojoe: there needs to be posted a list of release blockers, and frequent updates on them, i.e. daily
21:02:43 <pbrobinson> sorry to push but this is getting very embarrassing. There's been no updates to the list and F-17 has been stable for a long time now
21:02:56 <Frojoe> Alright.  I will pass that on to the team.  I want to get this thing out the door sooner rather than later
21:03:06 <masta> Frojoe: :)
21:03:32 <Frojoe> The one thing I can say for sure is that we want it out the door before FSOSS on the 25th I believe
21:03:37 <pbrobinson> Frojoe: all the armv6hl work should now be happening on f18 or even rawhide, release f17 on armv5tel and move on
21:03:46 <pwhalen> ok, we're past the hour and have another item to discuss, is there any other update?
21:03:57 <pbrobinson> nope
21:03:58 <Frojoe> pbrobinson, fossjon is working hard on v6 stuff
21:04:02 <Frojoe> I will get him to email the list
21:04:06 <masta> pwhalen: plz move ahead
21:04:20 <pwhalen> Frojoe, is that f18 v6 or f17?
21:04:57 <pwhalen> #topic 6) Discussion on dropping Kirkwood support
21:05:07 <Frojoe> From what I understand, we're working on a v6 f17 package set
21:05:19 <Frojoe> We have another koji set up to koji-shadow ours for f18 packages
21:05:32 <pwhalen> heated on the list, but bconoboy's last email summed it up well I think
21:05:36 <dgilmore> pwhalen: i think that as arm moves primary armv5tel should stay secondary
21:05:40 <pwhalen> Frojoe, thanks
21:05:54 <pwhalen> dgilmore, +1
21:06:04 <dmarlin> dgilmore: +1
21:06:08 <bconoboy> does anybody here want to keep on with armv5tel maintenance?
21:06:19 <pbrobinson> pwhalen: once I clarified with jonmasters he confirmed that in the short term he was talking about support blocking a release if it doesn't work for alpha etc for the F-18 release
21:06:24 <masta> dgilmore: +1
21:06:37 <pbrobinson> I confirmed with him that kirkwood had never blocked the relase
21:06:42 <jcapik> poor little armv5tel :]
21:06:59 <masta> bconoboy: never want to troubleshoot glibc atomics again, mind numbing
21:07:09 <pbrobinson> so for F-18 lets leave it at that for the moment, and leave discussions about Primary support for later
21:07:13 <bconoboy> dgilmore: I don't agree it should be part of primary push, rather it should be part of moving to PHX, which may happen before primary push.
21:07:34 <dgilmore> bconoboy: we are not moving anything to PHX
21:07:47 <bconoboy> pardon?
21:07:50 <dgilmore> bconoboy: koji will stay where it is.
21:07:54 <pbrobinson> bconoboy: we don't even have hardware yet so it's a mute discussion at the moment
21:08:09 <bconoboy> pbrobinson: now that is true
21:08:10 <dgilmore> bconoboy: we will add builders in phx to primary koji as part of the move to primary
21:08:32 <pbrobinson> lets keep on topic please, we're over time
21:08:33 <dgilmore> bconoboy: thats been my plan all along
21:08:47 <bconoboy> right, revisit this one later
21:08:52 <dgilmore> but yes there is little to nothing to discuss right now
21:09:11 <pbrobinson> dgilmore: exactly so why are you still doing so ;-)
21:09:19 <dgilmore> pbrobinson: i stopped
21:09:51 <revident> I would like to keep kirkwood around, but that is out of self interest and I'll admit I don't have the skill set for the package maintenance folks are highlighting.
21:10:05 <pbrobinson> right, so for F-18 kirkwood won't block release as was the case in F-17 (which I believe was just omap and vexpress, maybe tegra that where classed as "supported" )
21:10:27 <dgilmore> pbrobinson: indeed
21:10:39 <pbrobinson> so we'll keep the kirkwood kernel but it will need community testing and assistance regarding kernel support
21:11:00 <dgilmore> yes
21:11:02 <pwhalen> pbrobinson, right, to date its been hard to get kirkwood tested
21:11:32 <pbrobinson> so if people want to keep kirkwood around they need to step up to prove how much they love it
21:11:33 <pwhalen> leave this one on the list?
21:11:55 <pbrobinson> rather than just lip service on the list
21:11:56 <Frojoe> We have a ton of guruplugs that are collecting dust now.  We could maybe devote a couple to kirkwood stuff.
21:11:57 <dgilmore> pwhalen: maybe just to check if people have stepped up to help
21:12:01 * revident has been trying to crack that, but it's a spare time project and is not yet there
21:12:42 <pwhalen> #topic 7) Your topic here
21:13:14 * dgilmore just wants to say ill see whoever is at fudcon on the weekend
21:13:22 <pwhalen> we've gone late, and its even later for others..
21:13:33 <pbrobinson> revident: my time on ARM is my own time and I don't have kirkwood devices nor the time or interest if I had them so people that have them and want them supported need to at least test them
21:13:43 <pbrobinson> post midnight here
21:13:47 <pbrobinson> night all
21:13:48 <pwhalen> one item is a VFAD, once we produce a test image, then we'll send something out on the list as to when we should do it
21:13:55 <dgilmore> night pb
21:14:05 <bconoboy> pwhalen: Think we'll be ready by friday?
21:14:15 <bconoboy> g'night pbr
21:14:22 <pwhalen> bconoboy, possible, will be testing images tonight, so we should know tomorrow where we stand
21:14:34 <pwhalen> friday sounds reasonable, dmarlin ?
21:14:47 <dmarlin> pwhalen: if the test images all check out
21:15:02 * dgilmore needs to go afk also
21:15:04 <dgilmore> adios
21:15:08 <masta> these are the test images with updates-testing?
21:15:17 <jcapik> c.u.
21:15:25 <masta> dgilmore: good night
21:15:31 <bconoboy> pwhalen: Friday might be too ambitious. Let's see where we are tomorrow.
21:15:42 <dmarlin> masta: no, just what's in development
21:15:50 <dmarlin> masta: they were created before this meeting
21:16:01 <dmarlin> masta: we just need to verify them
21:16:02 <masta> dmarlin: count on me to help
21:16:03 <pwhalen> okay, I'll email the list with the plan tomorrow
21:16:13 <dmarlin> thanks pwhalen
21:16:22 <pwhalen> anything else folks?
21:16:36 <pwhalen> #endmeeting