20:05:25 <dgilmore> #startmeeting
20:05:25 <zodbot> Meeting started Wed Sep 12 20:05:25 2012 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:05:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:05:31 <dmarlin> .fas dmarlin
20:05:32 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:05:33 <dgilmore> #meetingname fedora-arm
20:05:33 <zodbot> The meeting name has been set to 'fedora-arm'
20:05:37 <ctyler> .fas chris@tylers.info
20:05:37 <zodbot> ctyler: ctyler 'Chris Tyler' <chris@tylers.info>
20:05:44 <dgilmore> why do people do that?
20:05:45 <Frojoe> .fas frojoe
20:05:45 <zodbot> Frojoe: jacwang 'Jordan Cwang' <jordan.cwang@gmail.com> - burningfool 'Jordan Cwang' <frojoe.21@gmail.com>
20:05:50 <masta> .fas parasense
20:05:51 <zodbot> masta: parasense 'Jon Disnard' <jdisnard@gmail.com>
20:06:08 <dgilmore> #topic Roll Call
20:06:09 <ctyler> dgilmore: easy way to identify real names etc. and no more difficult than /me here
20:06:15 <DarthJava> .fas darthjava
20:06:16 <zodbot> DarthJava: darthjava 'Dmitry Kozunov' <dmitry.kozunov@senecac.on.ca>
20:06:21 <dgilmore> ctyler: i find it bizare
20:06:26 <dgilmore> but ok
20:06:59 <masta> dgilmore: seems the odd custom here
20:07:26 <dgilmore> ive never done it in any meeting ive attened here or elsewhere
20:07:32 <dgilmore> but whatever floats people boats
20:07:48 <masta> :)
20:07:57 <dgilmore> so i go no topics sent to me
20:08:16 <fossjon> -> http://fpaste.org/p0H7/ ?
20:08:16 <dgilmore> lets start with #topic Raspberry pi status update
20:08:20 <dgilmore> #topic Raspberry pi status update
20:08:22 <fossjon> :)
20:08:36 * jonmasters here btw
20:08:37 <fossjon> I guess i can talk
20:08:49 <fossjon> I'm working on an armv6hl version for rasp pi right now
20:08:58 <fossjon> i got glibc and gcc compiled for it finally
20:09:10 <fossjon> but I need some other dependencies built first
20:09:12 <jonmasters> fossjon: resolved the glib missing thing?
20:09:35 <fossjon> i think so everything seemed to build
20:09:51 <fossjon> ive never dont this before so ya im hoping it install ok on this armv7 box
20:10:10 <dgilmore> fossjon: it will need rpm and yum work im sure
20:10:21 <fossjon> we have a f17 armv5 image but we'd like to wait a bit and see if this armv6 is a better candidate for release
20:10:36 <dgilmore> fossjon: please dont wait
20:10:40 <dgilmore> ship a sfp image
20:10:42 <fossjon> ya i have to work on rpm and yum still i guess
20:10:50 <dgilmore> we can always add the hfp one
20:11:02 <ctyler> What I'm thinking is this:
20:11:11 <dgilmore> but we have already lost a lot of traction by being too slow
20:11:11 <masta> fast and good enough > slow and perfect
20:11:20 <ctyler> - We'll ship what we have for RPFR17 armv5tel now
20:11:33 <ctyler> - Prepare the armv6hl release for F18
20:11:47 <ctyler> Now with that, a different approach for the armv6hl stuff.
20:12:10 <ctyler> I'm proposing that we shadow the Fedora ARM stuff with what is effectively a tertiary architecture
20:12:27 <ctyler> i.e., another Koji instance following the Fedora-ARM koji instance building armv6hl
20:12:43 <ctyler> We don't really want armv6hl in Fedora
20:12:45 <dgilmore> ctyler: ok.
20:12:49 <ctyler> ever
20:12:51 * masta boggles a shadow of a shadow
20:13:18 <dgilmore> ctyler: I think we should likely leave sfp secondary forever
20:13:19 <ctyler> This would effectively remain secondary as ARM moves to primary
20:13:46 <ctyler> I think we should drop SFP when we move to primary, if it's in the F20 timeframe as it appears to be shaping up
20:13:53 <dgilmore> ctyler: so we could maybe look to doing armv5tel and armv6hl as secondary and just move armv7hl to primary
20:14:09 <dgilmore> ctyler: well i suspect we will be able to move for f19
20:14:22 <dgilmore> but there are cards to be played yet
20:14:27 <ctyler> Indeed
20:14:44 <jonmasters> ctyler: I agree on the not promoting sfp but I question a tertiary architecture
20:14:48 <dgilmore> but we can be flexible :)
20:15:05 <jonmasters> if v6 is really way more popular than v5, perhaps just plan to replace v5 with v6
20:15:20 <ctyler> jonmasters: I don't see adding another arch as a strong proposition
20:15:22 <dgilmore> jonmasters: problem is its really not
20:15:36 <dgilmore> jonmasters: there is the pi and the via board
20:15:38 <dgilmore> thats it
20:15:41 <jonmasters> dgilmore: I was told that the Pi downloads were way outnumbering any v5
20:15:45 <fossjon> it may not be more popular but it seems to be way faster performing for the pi at least :/
20:15:57 <jonmasters> * any other
20:16:01 <ctyler> dgilmore: more Raspis have shipped than plug computers, I'm sure
20:16:16 <dgilmore> jonmasters: perhaps, the issue is that there is only 2 boards,  most v6 systems were in phones
20:16:47 <ctyler> v5 is really only two boards: sheeva/pogo and guru
20:16:59 <ctyler> the six OpenRDs out there don't count :-P
20:17:01 <dgilmore> ctyler: also pretty true
20:17:19 <jonmasters> dgilmore: agreed, aware of that. I chatted with someone about the v5/v6 thing a while back and we pondered that it's weird and strange the world we're in but if the Pi is really the dominant device that we'd even remotely care about !v7, we shouldn't have both v5 and v6
20:17:33 <dgilmore> i dont see a huge future with v5 or v6  but they are there and we should continue to support them
20:18:10 <jonmasters> well, my $0.02 is that it's hard enough to support v5 and v7, and adding a third one isn't a good idea if we can kill off v5 sooner :)
20:18:11 <dgilmore> Ill see what stats i can gleam from mirrormanager
20:18:34 <ctyler> Let's start with v6hl as a tertiary, we can move it to secondary in due course if/when that makes sense
20:18:59 <ctyler> That also lets up stage Koji 1.7 and do some work with koji-shadow in a non-critical context
20:19:17 <fossjon> and have something at seneca to run :)
20:19:18 <dgilmore> ctyler: koji 1.7 is what primary is using
20:19:25 <dgilmore> it hass all the patches needed for arm
20:19:49 <masta> I know some people in the synology and Drobo crowd that depend on v5 fedora packages... for their chroots
20:20:43 <jonmasters> there will always be someone who cares about v5, or even v4t :)
20:20:55 <dgilmore> debian still does v4t
20:21:05 <jonmasters> (which is why I cited v4t)
20:21:05 <fossjon> the future is v7 and the one after :)
20:21:20 <ctyler> Speaking of primary/secondary etc., I have a couple questions about storage (mentioned briefly last week, was going to take to the list but didn't get around to it yet) ...
20:21:50 <dgilmore> ctyler: ok so nothing left on raspberry pi?
20:21:58 <dgilmore> #topic koji storage
20:22:17 <dgilmore> ctyler: go for it
20:22:39 <ctyler> we have pretty much filled the 600G SSD we added this summer. I'm wondering how (a) we can get rid of the pre-F15 packages without upsetting Koji and (b) what storage projections look like for now-until-PHX move.
20:23:13 <dgilmore> ctyler: we have been told by legal on primary that we can not remove anything from koji that has shipped
20:23:25 <dgilmore> which means the answer to your first question is no
20:23:38 <dgilmore> primary is currently using just over 10T of disk
20:23:46 <ctyler> Ok, can we migrate it to other storage?
20:23:56 <nirik> FYI, we are putting together budget for next year and trying to allocate space for arm in phx2... but no idea when that would be ready. ;)
20:24:03 <dgilmore> ctyler: we can purge the signed copies of the old releases
20:24:24 <dgilmore> ctyler: there is the signed and unsigned copies
20:24:35 <dgilmore> and the header for the signature
20:24:47 <dgilmore> removing the old signed copies we can get them back if needed
20:25:14 <ctyler> Ok, we should be able to do that for F14/15.
20:25:20 <dgilmore> ctyler: yeah
20:25:25 <jonmasters> dgilmore: if there are older packages that aren't needed anywhere for a buildroot inheritance then they could also just be archived to *different* storage
20:25:27 <dgilmore> we could setup koji-gc also
20:25:34 <dgilmore> it may free up some packages
20:25:46 <dgilmore> jonmasters: that doesnt work in koji
20:26:07 <ctyler> Assuming an F20 phx move (which is hopefully worst-case), how much storage will we likely need between now and then?
20:26:07 <dgilmore> koji does have a split volume feature but its not at all user friendly
20:26:17 <jonmasters> but for some older packages, Koji doesn't need them any more. Can't we prune old builds and just backup the packages somewhere else?
20:26:20 <dgilmore> ctyler: my guess is 300G
20:26:43 <dgilmore> ctyler: we will need to always use the secondary koji for any release done as a secondary
20:26:46 <fossjon> don't the mirrors all have copies of our stuff though?
20:26:54 <fossjon> why can't we just let them have it
20:27:09 <ctyler> fossjon: only the final signed packages, and not necessarily long-term
20:27:12 <jonmasters> fossjon: totally understand why we can't rely just on mirrors for legal reasons, but we can setup an archive someehere
20:27:17 <dgilmore> ctyler: so if we ship f19 as primary its updates will come from primary but f17 and f18 will have its updates from secondary
20:27:36 <fossjon> send all the old stuff to amazon ec2 cloud thingy??
20:27:56 <ctyler> dgilmore: I'm more comfortable basing assumptions on F20 worst-case than F19
20:28:07 <jonmasters> ctyler: my understanding is that the current hardware configuration has a bunch of SSDs and a rotational disk in a RAID1 or similar? Are you constrained by the size of the rotational piece?
20:28:20 <dgilmore> ctyler: well id say 300G  per release
20:28:23 <jonmasters> ctyler: this is the latest summary I got last week of the configuration
20:28:27 <dgilmore> but thats random guess
20:28:28 <ctyler> jonmasters: No, that's not a limitation
20:28:43 <jonmasters> ctyler: ok, so can you scale to add another 300GB of SSDs if we or you buy them?
20:29:17 <ctyler> We can do that, but if we burned through 600G in the last few months, and there's an F19 rebuild (likely), isn't 300G on the small side?
20:29:36 <jonmasters> ctyler: as an aside, if any of those Intel SSDs have an hdparm/smart command to report on erase block use, that would be interesting to know how they are wearing in use
20:30:05 <jonmasters> ctyler: storage is cheap :) let's get what makes sense, as long as it can be added
20:30:58 <ctyler> We're working in 600G increments, so one more group should do the trick? I'd rather know that we need 2 or 3 now than have to revisit this on a surprise recurring basis :-)
20:31:48 <jonmasters> if you add 600G more, it's hard to see how that's going to all be used before f19
20:31:55 <dgilmore> ctyler: we will free up some space
20:32:02 <dgilmore> lets add 1 more 600G
20:32:10 <ctyler> Ok, I'll plan on one more 600G increment.
20:32:12 <dgilmore> we will free up signed copies of old releases
20:32:28 <jonmasters> ctyler: and the existing controllers, etc. can all cope with the additional drives?
20:32:32 <dgilmore> that will give us close to 1T
20:32:34 <ctyler> jonmasters: yes
20:32:37 <jonmasters> good
20:33:06 * jonmasters suggests checking the SMART stats on the existing drives to see if any are also in need of replacement, and to get field data on how long they last in reality
20:33:22 <ctyler> jonmasters: we'll see what data is available
20:35:32 <ctyler> Ok, anything else in the queue?
20:36:01 <ctyler> How are things shaping up for F18 alpha?
20:36:34 <Frojoe> <_<
20:36:46 <fossjon> my twitter seems to be stopped at a percentage
20:36:54 <masta> There was the VFAD we missed a while back, is that goign to be rescheduled ?
20:37:10 <dgilmore> #topic alpha status
20:37:27 <dgilmore> ok so as i know it we need some work on anaconda still and livemedia-creator
20:37:46 <dgilmore> I have pungi work lined up but we can just use lorax to make us install trees
20:37:58 <dgilmore> since we dont need a install dvd
20:38:05 <fossjon> can i help with any scripting?
20:38:17 <dgilmore> fossjon: need to debug anaconda and lmc
20:38:24 <fossjon> i made a modifier thingy for paul and dmarlin but ya
20:38:25 <dgilmore> your welcome to assist
20:38:30 <dmarlin> we will also need functional kernels all all 'blocker' platforms
20:38:36 <fossjon> if im capable then sure :)
20:38:39 <dgilmore> we need working kernels
20:39:27 <dgilmore> I think we also need to work out how to support devicetree
20:39:38 <masta> yes
20:39:52 <dgilmore> looks like 3.7 will be DT only
20:39:59 <dgilmore> F18 will get 3.7
20:40:04 <dgilmore> f17 likely will also
20:40:24 <jonmasters> main thing there is to make sure each platform has a reference dtb
20:40:30 <jonmasters> that works with 3.7, etc.
20:40:38 <masta> that means a lot of uboot updates forced on people
20:40:47 <ctyler> yeah :-S
20:40:50 <dgilmore> jonmasters: well ideally vendors ship dtb files
20:41:01 <jonmasters> dgilmore: sure, but I'm thinking for e.g. Panda images
20:41:20 <jonmasters> I don't want to ship any dtbs, but for platforms where we do, we'll need to have something
20:41:43 <dgilmore> jonmasters: platforms where we ship uboot files we will have to ship dtb files
20:41:59 <jonmasters> it's something to test with 3.6 kernels. Once the first rc kernels are available, then we can verify what other updates will actually be required
20:42:07 <dmarlin> we need to make sure u-boot will support both fdt and non-fdt kernels, or we will see breakage
20:42:10 <jonmasters> dgilmore: yep, that's what I just said :)
20:42:30 <dgilmore> just being clear
20:42:36 <jonmasters> good call
20:42:46 <dgilmore> anyone have questions on f18 alpha?
20:43:09 <ctyler> timeframe?
20:43:10 <jonmasters> when Paul is back, I'll ask him to focus on the QE effort for F18
20:43:17 * dgilmore will look into getting pungify working for secondary arches
20:43:38 <jonmasters> he's done a great job on getting the test matrix going. We need data for every board, etc.
20:43:42 <dgilmore> ctyler: honestly no idea. its hard to know when we dont have working kernels for most things
20:43:49 <dgilmore> makes testing difficult
20:43:59 <dmarlin> impossible
20:44:11 <masta> do we have a way right now to make vexpress, highbank, panda images? I noticed lorax was mentioned. do we resurect the scripts from f17?
20:44:32 <dgilmore> masta: no resurecting scripts
20:44:34 <ctyler> dmarlin: pfft, you give up on testing just because you can't boot?!
20:44:35 * jonmasters suggests a series of VFADs focused on kernel testing/debugging/fixing
20:44:42 <dgilmore> lorax builds anaconda install trees
20:44:51 <dmarlin> ctyler: yes, I'm a slacker that way
20:45:13 <dgilmore> we will then need to use livemedia-creator to create images for appropriate platfoms
20:45:16 <jonmasters> probably needs time set aside explicitly for it, even if there's only a small set of folks qualified to make the fixes
20:45:31 <dmarlin> jonmasters: +1
20:45:50 <dgilmore> jonmasters: sure
20:45:53 <jonmasters> for me, it's easier to do it if I think "all of today is set aside to fixing kernels"
20:46:04 * dgilmore needs to try get f18 up on everything he has
20:46:12 <jonmasters> we need this resolved by the end of Sep. ideally
20:46:14 <masta> so can we plan on the next VFAD?
20:46:19 <jonmasters> masta: sure
20:46:24 * jonmasters suggests sometime next week
20:46:40 <masta> ok, how about wednesday?
20:46:54 <jonmasters> that can work. Selfishly, this week is tought
20:46:54 <dgilmore> wwednesdays are bad for me
20:46:55 <jonmasters> tough
20:47:08 * dgilmore suggests monday or tuesday
20:47:11 <dgilmore> sooner the better
20:47:14 <masta> dgilmore: how are tuesdays?
20:47:14 <jonmasters> dgilmore: oh, a different day...works for me
20:47:56 <dgilmore> lets do tuesday
20:48:16 <jonmasters> dgilmore: +1
20:48:16 <dgilmore> #info tuesday to be day of teh kernel
20:48:21 <ctyler> +1
20:48:28 <masta> Tuesday the 18th
20:48:33 <fossjon> +1
20:48:52 <jonmasters> until we have a Fedora kernel person (it's being investigated in internal budgeting) for ARM, we'll probably need to look at doing these VFADs more periodically
20:49:34 <jonmasters> the problem is mostly finding talent
20:49:46 <jonmasters> ARM kernel engineers aren't a dime a dozen
20:50:09 <dgilmore> most of the issues just need digging into
20:50:24 <dgilmore> and dont need a lot of internal arm kernel knowledge
20:50:28 <jonmasters> sure, I think we'll make good progress in the VFADs. We do need a dedicated resource who understands the code also
20:50:31 <dgilmore> just degugging the failures
20:50:33 <ctyler> jonmasters: ARM kernel engineer hairlock cloning still not successful?
20:50:36 <dgilmore> often its a Kconfig patch
20:50:48 <dgilmore> or pull an existing patch in that wasnt pushed upstream yet
20:51:05 <jonmasters> ctyler: nope, I keep threatening Will Deacon with a cloning lab. It was pointed out that I'd need a whole lock of his hair, including the root.
20:51:27 <jonmasters> ctyler: but that's got a 20 year lead time or so
20:51:45 <masta> do we want to go over last weeks kernel testing?
20:51:51 <jonmasters> for the record, we've chatted with a few people. It's known RH is hiring, etc.
20:52:53 <jonmasters> masta: I can't usefully comment yet. I need to get some boards updated at home. I'll get onto that, same as dgilmore
20:53:16 * jonmasters has a Trimslice running F18, but it's a few weeks out of date now kernel wise
20:53:26 <masta> ok then, fyi  https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing
20:53:41 * jonmasters suggests we discuss on the list prior to the VFAD
20:53:43 <dgilmore> #link https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing
20:53:47 <jonmasters> who has the ball on arranging the VFAD?
20:53:49 <ctyler> fossjon: last week we wondered about a new-kernel-in-rawhide notification, does that look possible?
20:54:00 <dgilmore> masta: want to run the vfad?
20:54:06 <jonmasters> dgilmore: +1
20:54:37 <masta> dgilmore: I'll give it a shot, might need some hand holding, but tentativly sure
20:54:40 <fossjon> i think so ctyler
20:54:51 <fossjon> just need the details of what to query for?
20:54:54 <dgilmore> masta: thanks
20:55:04 <dgilmore> #info masta with help will run the vfad
20:55:08 <jonmasters> masta: thanks man. We'll look for email, etc.
20:55:58 <masta> sure
20:56:11 <masta> please respond to the email with your ideas for the vfad, etc
20:57:05 <dgilmore> ok
20:57:11 <dgilmore> #topic open floor
20:57:21 <dgilmore> anyone have anything they want to bring up?
20:57:53 * dgilmore notes that for the rest of the year ill be travelling a bit and not always available
20:58:18 <masta> Has anybody heard anything about Allwinner A10 and mainline acceptance?
20:58:29 <jcapik> .fas jcapik
20:58:29 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:58:36 <masta> or, how long until FEdora supports A10 boards
20:58:50 <ctyler> masta: it won't be a short road
20:59:39 <jonmasters> masta: I know Arnd quite likes the Allwinner stuff
21:00:06 * jonmasters has not looked at the code there, but I'm encouraged when the upstream says it's a better story than the Pi
21:00:13 <masta> Those boards are showing up all over, and I think they will pickup where raspi leave things to be desired
21:00:22 * jonmasters agrees
21:00:34 <dgilmore> masta: indeed
21:00:44 <jonmasters> The "Pi" is aspirational. It's not about the Pi specifically. It's a class of device
21:00:56 <jonmasters> It's like how every tissue is a "Kleenex" even if it's not
21:00:59 <ctyler> Definitely. Cubieboard ftw!
21:01:05 <masta> indeed
21:01:24 <jonmasters> this why I think a lot of our concerns about v5 go away even more in another few months
21:01:46 <jonmasters> in 6-12 months, there will be so many inexpensive at least A8 parts that nobody is going to care about v6
21:02:05 * ctyler thinks a bit longer than that, but yes
21:02:10 <jonmasters> (A8 in this context means Cortex-A8)
21:02:11 <masta> jonmasters: is Arnd doing anything with Amery over on github?
21:02:27 <jonmasters> masta: I am uninformed on that status currently. I will get informed asap
21:03:56 <masta> great, do let us know what you findout
21:04:23 * jonmasters has been reviewing a lot of aarch64 patches recently. We can discuss aarch64 soon, but not now.
21:04:56 <dgilmore> anything else?
21:05:17 <dgilmore> #info need to find status of a10 to set roadmap for fedora support
21:05:19 <jonmasters> masta: are you setting up the VFAD on Mon or Tue?
21:05:29 <jonmasters> Tue right?
21:05:38 <masta> tuesday the 18th
21:05:41 <jonmasters> thanks
21:06:30 <odoto> I meant to bring this one up https://bugzilla.redhat.com/show_bug.cgi?id=834977 but after listening here I feel like you guys got enough problems already with the arm kernels ;)
21:07:37 <ctyler> odoto: let's try and nail that at the vfad
21:08:17 <jonmasters> I think that's a wrap!
21:08:27 <dgilmore> #endmeeting