20:05:25 #startmeeting 20:05:25 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:05:31 .fas dmarlin 20:05:32 dmarlin: dmarlin 'David A. Marlin' 20:05:33 #meetingname fedora-arm 20:05:33 The meeting name has been set to 'fedora-arm' 20:05:37 .fas chris@tylers.info 20:05:37 ctyler: ctyler 'Chris Tyler' 20:05:44 why do people do that? 20:05:45 .fas frojoe 20:05:45 Frojoe: jacwang 'Jordan Cwang' - burningfool 'Jordan Cwang' 20:05:50 .fas parasense 20:05:51 masta: parasense 'Jon Disnard' 20:06:08 #topic Roll Call 20:06:09 dgilmore: easy way to identify real names etc. and no more difficult than /me here 20:06:15 .fas darthjava 20:06:16 DarthJava: darthjava 'Dmitry Kozunov' 20:06:21 ctyler: i find it bizare 20:06:26 but ok 20:06:59 dgilmore: seems the odd custom here 20:07:26 ive never done it in any meeting ive attened here or elsewhere 20:07:32 but whatever floats people boats 20:07:48 :) 20:07:57 so i go no topics sent to me 20:08:16 -> http://fpaste.org/p0H7/ ? 20:08:16 lets start with #topic Raspberry pi status update 20:08:20 #topic Raspberry pi status update 20:08:22 :) 20:08:36 * jonmasters here btw 20:08:37 I guess i can talk 20:08:49 I'm working on an armv6hl version for rasp pi right now 20:08:58 i got glibc and gcc compiled for it finally 20:09:10 but I need some other dependencies built first 20:09:12 fossjon: resolved the glib missing thing? 20:09:35 i think so everything seemed to build 20:09:51 ive never dont this before so ya im hoping it install ok on this armv7 box 20:10:10 fossjon: it will need rpm and yum work im sure 20:10:21 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 fossjon: please dont wait 20:10:40 ship a sfp image 20:10:42 ya i have to work on rpm and yum still i guess 20:10:50 we can always add the hfp one 20:11:02 What I'm thinking is this: 20:11:11 but we have already lost a lot of traction by being too slow 20:11:11 fast and good enough > slow and perfect 20:11:20 - We'll ship what we have for RPFR17 armv5tel now 20:11:33 - Prepare the armv6hl release for F18 20:11:47 Now with that, a different approach for the armv6hl stuff. 20:12:10 I'm proposing that we shadow the Fedora ARM stuff with what is effectively a tertiary architecture 20:12:27 i.e., another Koji instance following the Fedora-ARM koji instance building armv6hl 20:12:43 We don't really want armv6hl in Fedora 20:12:45 ctyler: ok. 20:12:49 ever 20:12:51 * masta boggles a shadow of a shadow 20:13:18 ctyler: I think we should likely leave sfp secondary forever 20:13:19 This would effectively remain secondary as ARM moves to primary 20:13:46 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 ctyler: so we could maybe look to doing armv5tel and armv6hl as secondary and just move armv7hl to primary 20:14:09 ctyler: well i suspect we will be able to move for f19 20:14:22 but there are cards to be played yet 20:14:27 Indeed 20:14:44 ctyler: I agree on the not promoting sfp but I question a tertiary architecture 20:14:48 but we can be flexible :) 20:15:05 if v6 is really way more popular than v5, perhaps just plan to replace v5 with v6 20:15:20 jonmasters: I don't see adding another arch as a strong proposition 20:15:22 jonmasters: problem is its really not 20:15:36 jonmasters: there is the pi and the via board 20:15:38 thats it 20:15:41 dgilmore: I was told that the Pi downloads were way outnumbering any v5 20:15:45 it may not be more popular but it seems to be way faster performing for the pi at least :/ 20:15:57 * any other 20:16:01 dgilmore: more Raspis have shipped than plug computers, I'm sure 20:16:16 jonmasters: perhaps, the issue is that there is only 2 boards, most v6 systems were in phones 20:16:47 v5 is really only two boards: sheeva/pogo and guru 20:16:59 the six OpenRDs out there don't count :-P 20:17:01 ctyler: also pretty true 20:17:19 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 i dont see a huge future with v5 or v6 but they are there and we should continue to support them 20:18:10 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 Ill see what stats i can gleam from mirrormanager 20:18:34 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 That also lets up stage Koji 1.7 and do some work with koji-shadow in a non-critical context 20:19:17 and have something at seneca to run :) 20:19:18 ctyler: koji 1.7 is what primary is using 20:19:25 it hass all the patches needed for arm 20:19:49 I know some people in the synology and Drobo crowd that depend on v5 fedora packages... for their chroots 20:20:43 there will always be someone who cares about v5, or even v4t :) 20:20:55 debian still does v4t 20:21:05 (which is why I cited v4t) 20:21:05 the future is v7 and the one after :) 20:21:20 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 ctyler: ok so nothing left on raspberry pi? 20:21:58 #topic koji storage 20:22:17 ctyler: go for it 20:22:39 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 ctyler: we have been told by legal on primary that we can not remove anything from koji that has shipped 20:23:25 which means the answer to your first question is no 20:23:38 primary is currently using just over 10T of disk 20:23:46 Ok, can we migrate it to other storage? 20:23:56 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 ctyler: we can purge the signed copies of the old releases 20:24:24 ctyler: there is the signed and unsigned copies 20:24:35 and the header for the signature 20:24:47 removing the old signed copies we can get them back if needed 20:25:14 Ok, we should be able to do that for F14/15. 20:25:20 ctyler: yeah 20:25:25 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 we could setup koji-gc also 20:25:34 it may free up some packages 20:25:46 jonmasters: that doesnt work in koji 20:26:07 Assuming an F20 phx move (which is hopefully worst-case), how much storage will we likely need between now and then? 20:26:07 koji does have a split volume feature but its not at all user friendly 20:26:17 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 ctyler: my guess is 300G 20:26:43 ctyler: we will need to always use the secondary koji for any release done as a secondary 20:26:46 don't the mirrors all have copies of our stuff though? 20:26:54 why can't we just let them have it 20:27:09 fossjon: only the final signed packages, and not necessarily long-term 20:27:12 fossjon: totally understand why we can't rely just on mirrors for legal reasons, but we can setup an archive someehere 20:27:17 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 send all the old stuff to amazon ec2 cloud thingy?? 20:27:56 dgilmore: I'm more comfortable basing assumptions on F20 worst-case than F19 20:28:07 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 ctyler: well id say 300G per release 20:28:23 ctyler: this is the latest summary I got last week of the configuration 20:28:27 but thats random guess 20:28:28 jonmasters: No, that's not a limitation 20:28:43 ctyler: ok, so can you scale to add another 300GB of SSDs if we or you buy them? 20:29:17 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 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 ctyler: storage is cheap :) let's get what makes sense, as long as it can be added 20:30:58 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 if you add 600G more, it's hard to see how that's going to all be used before f19 20:31:55 ctyler: we will free up some space 20:32:02 lets add 1 more 600G 20:32:10 Ok, I'll plan on one more 600G increment. 20:32:12 we will free up signed copies of old releases 20:32:28 ctyler: and the existing controllers, etc. can all cope with the additional drives? 20:32:32 that will give us close to 1T 20:32:34 jonmasters: yes 20:32:37 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 jonmasters: we'll see what data is available 20:35:32 Ok, anything else in the queue? 20:36:01 How are things shaping up for F18 alpha? 20:36:34 <_< 20:36:46 my twitter seems to be stopped at a percentage 20:36:54 There was the VFAD we missed a while back, is that goign to be rescheduled ? 20:37:10 #topic alpha status 20:37:27 ok so as i know it we need some work on anaconda still and livemedia-creator 20:37:46 I have pungi work lined up but we can just use lorax to make us install trees 20:37:58 since we dont need a install dvd 20:38:05 can i help with any scripting? 20:38:17 fossjon: need to debug anaconda and lmc 20:38:24 i made a modifier thingy for paul and dmarlin but ya 20:38:25 your welcome to assist 20:38:30 we will also need functional kernels all all 'blocker' platforms 20:38:36 if im capable then sure :) 20:38:39 we need working kernels 20:39:27 I think we also need to work out how to support devicetree 20:39:38 yes 20:39:52 looks like 3.7 will be DT only 20:39:59 F18 will get 3.7 20:40:04 f17 likely will also 20:40:24 main thing there is to make sure each platform has a reference dtb 20:40:30 that works with 3.7, etc. 20:40:38 that means a lot of uboot updates forced on people 20:40:47 yeah :-S 20:40:50 jonmasters: well ideally vendors ship dtb files 20:41:01 dgilmore: sure, but I'm thinking for e.g. Panda images 20:41:20 I don't want to ship any dtbs, but for platforms where we do, we'll need to have something 20:41:43 jonmasters: platforms where we ship uboot files we will have to ship dtb files 20:41:59 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 we need to make sure u-boot will support both fdt and non-fdt kernels, or we will see breakage 20:42:10 dgilmore: yep, that's what I just said :) 20:42:30 just being clear 20:42:36 good call 20:42:46 anyone have questions on f18 alpha? 20:43:09 timeframe? 20:43:10 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 he's done a great job on getting the test matrix going. We need data for every board, etc. 20:43:42 ctyler: honestly no idea. its hard to know when we dont have working kernels for most things 20:43:49 makes testing difficult 20:43:59 impossible 20:44:11 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 masta: no resurecting scripts 20:44:34 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 lorax builds anaconda install trees 20:44:51 ctyler: yes, I'm a slacker that way 20:45:13 we will then need to use livemedia-creator to create images for appropriate platfoms 20:45:16 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 jonmasters: +1 20:45:50 jonmasters: sure 20:45:53 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 we need this resolved by the end of Sep. ideally 20:46:14 so can we plan on the next VFAD? 20:46:19 masta: sure 20:46:24 * jonmasters suggests sometime next week 20:46:40 ok, how about wednesday? 20:46:54 that can work. Selfishly, this week is tought 20:46:54 wwednesdays are bad for me 20:46:55 tough 20:47:08 * dgilmore suggests monday or tuesday 20:47:11 sooner the better 20:47:14 dgilmore: how are tuesdays? 20:47:14 dgilmore: oh, a different day...works for me 20:47:56 lets do tuesday 20:48:16 dgilmore: +1 20:48:16 #info tuesday to be day of teh kernel 20:48:21 +1 20:48:28 Tuesday the 18th 20:48:33 +1 20:48:52 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 the problem is mostly finding talent 20:49:46 ARM kernel engineers aren't a dime a dozen 20:50:09 most of the issues just need digging into 20:50:24 and dont need a lot of internal arm kernel knowledge 20:50:28 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 just degugging the failures 20:50:33 jonmasters: ARM kernel engineer hairlock cloning still not successful? 20:50:36 often its a Kconfig patch 20:50:48 or pull an existing patch in that wasnt pushed upstream yet 20:51:05 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 ctyler: but that's got a 20 year lead time or so 20:51:45 do we want to go over last weeks kernel testing? 20:51:51 for the record, we've chatted with a few people. It's known RH is hiring, etc. 20:52:53 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 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 #link https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing 20:53:47 who has the ball on arranging the VFAD? 20:53:49 fossjon: last week we wondered about a new-kernel-in-rawhide notification, does that look possible? 20:54:00 masta: want to run the vfad? 20:54:06 dgilmore: +1 20:54:37 dgilmore: I'll give it a shot, might need some hand holding, but tentativly sure 20:54:40 i think so ctyler 20:54:51 just need the details of what to query for? 20:54:54 masta: thanks 20:55:04 #info masta with help will run the vfad 20:55:08 masta: thanks man. We'll look for email, etc. 20:55:58 sure 20:56:11 please respond to the email with your ideas for the vfad, etc 20:57:05 ok 20:57:11 #topic open floor 20:57:21 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 Has anybody heard anything about Allwinner A10 and mainline acceptance? 20:58:29 .fas jcapik 20:58:29 jcapik: jcapik 'Jaromír Cápík' 20:58:36 or, how long until FEdora supports A10 boards 20:58:50 masta: it won't be a short road 20:59:39 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 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 masta: indeed 21:00:44 The "Pi" is aspirational. It's not about the Pi specifically. It's a class of device 21:00:56 It's like how every tissue is a "Kleenex" even if it's not 21:00:59 Definitely. Cubieboard ftw! 21:01:05 indeed 21:01:24 this why I think a lot of our concerns about v5 go away even more in another few months 21:01:46 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 (A8 in this context means Cortex-A8) 21:02:11 jonmasters: is Arnd doing anything with Amery over on github? 21:02:27 masta: I am uninformed on that status currently. I will get informed asap 21:03:56 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 anything else? 21:05:17 #info need to find status of a10 to set roadmap for fedora support 21:05:19 masta: are you setting up the VFAD on Mon or Tue? 21:05:29 Tue right? 21:05:38 tuesday the 18th 21:05:41 thanks 21:06:30 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 odoto: let's try and nail that at the vfad 21:08:17 I think that's a wrap! 21:08:27 #endmeeting