20:01:44 #startmeeting 20:01:44 Meeting started Wed Aug 1 20:01:44 2012 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:44 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:01:44 #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore 20:01:44 Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen 20:01:52 .fas dmarlin 20:01:53 dmarlin: dmarlin 'David A. Marlin' 20:01:53 .fas pwhalen 20:01:56 * pbrobinson waves 20:01:56 pwhalen: pwhalen 'Paul Whalen' 20:01:59 .fas frojoe 20:02:00 .fas blc@ 20:02:00 Frojoe: jacwang 'Jordan Cwang' - burningfool 'Jordan Cwang' 20:02:01 .fas jonmasters 20:02:01 .fas maxam 20:02:02 bconoboy: blc '' 20:02:05 .fas agreene 20:02:06 jonmasters: jcm 'Jon Masters' 20:02:08 .fas jcapik 20:02:09 maxam: maxam '' - maxamaxim '' - maxamillion 'Adam Miller' 20:02:12 agreene: tag4fedora 'Tim Greene' - agreene 'Andrew Greene' 20:02:15 jcapik1: jcapik 'Jaromír Cápík' 20:02:22 what is with all the .fas BS? 20:02:46 It means I am here! :) 20:03:11 #topic 1) F18 - Mass rebuild status - Defining release criteria - Alpha Release 20:03:29 we'll tackle those in order.. 20:03:36 * jonmasters is on phone calls 20:03:49 pbrobinson, anything to share about the rebuild or is that, going as planned? 20:03:57 yes 20:03:57 saw your note about slow Koji 20:04:15 the koji hosts page seems slow 20:04:18 we're getting there. arm.koji has been slow, of late 20:04:22 fossjon, very 20:04:32 now two pages of hosts 20:04:39 and there was outage for planned maint on ML koji last night 20:05:10 there's a few blockers. bit ones at the moment are webkitgtk3 is blocking most of gnome. freeglut is blocking some things 20:05:23 * pbrobinson wishes koji-shadow was more stable 20:05:34 hehe i just posted this -> http://lists.fedoraproject.org/pipermail/arm/2012-August/003785.html 20:05:38 its not that meaningful tho 20:05:43 but we're getting there and closing stuff out relatively quickly 20:05:44 pbrobinson, +1 - and queued more jobs 20:06:16 pwhalen: that's speed and stability of k-s and koji tbh :) 20:06:37 awesome.. okay.. anyone have anything else to share regarding the rebuild? 20:06:42 why is koji running slow? 20:07:08 fossjon: that link makes no sense to me what so ever 20:07:12 i think its the db 20:07:24 theres this state table that gets pretty huge 20:07:30 Seneca folks, anything happening on Koji? 20:08:03 dgilmore says there was a raid rebuild happening on the arm.koji hub this morning, fossjon's comment indicates that maybe seneca hasn't noticed that issue 20:08:05 Nothing we've noticed today, we can look into it 20:08:58 #action Seneca to check on the status of why Koji has been slow 20:09:09 Frojoe: dgilmore showed me this around 8 hours ago: 20:09:09 (13:35:10) dgilmore: Aug 1 01:00:01 hongkong kernel: [459278.725544] md: data-check of RAID array md5 20:09:09 (13:35:13) dgilmore: Aug 1 01:00:01 hongkong kernel: [459278.725548] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. 20:09:09 (13:35:16) dgilmore: Aug 1 01:00:01 hongkong kernel: [459278.725551] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check. 20:09:09 (13:35:19) dgilmore: Aug 1 01:00:01 hongkong kernel: [459278.725558] md: using 128k window, over a total of 416460668k. 20:10:17 okay.. next item for F18 is defining our release criteria.. 20:10:51 same as f17? or more? 20:10:54 more 20:11:00 maybe go with f17 primary criteria? 20:11:11 we should be aiming to be following primary promotion criteria 20:11:31 I'll take a look at PA's release criteria and adapt it much like we did the first time 20:12:18 same targets platforms? 20:12:19 I feel if we don't follow it exactly and document the issues we have we'll never make Primary in the f19 or f20 timeframe so we may as well not bother. It should be a dry run for primary promotion 20:12:42 dmarlin: do you mean devices? 20:12:53 yes 20:12:54 http://www.cavium.com/newsevents_Cavium_Unveils_Project_Thunder.html 20:12:56 ^^^ btw 20:13:00 panda, vexpress, etc. 20:13:12 I think we can expand the the devices to include a bit more, thoughts? 20:13:17 jonmasters: is that to do with f18 ? 20:13:21 so I guess the goal here is to shoot for F17 PA release criteria with consideration for the exceptions in FESCO's SA->PA guidelines 20:13:38 pbrobinson: no, just hit the wire and wanted to share 20:13:56 I think for the time being we need to stay with the devices we have and then we can review as new devices come up 20:14:07 at the moment there are no new devices we can currently support 20:14:37 ok, just checking for clarification 20:14:38 I'm aware of the Marvell server platform but the stuff currently going to mainline doesn't make it usable in the current kernel cycle 20:15:00 pbrobinson: highbank shoud be, I think 20:15:11 highbank != marvell 20:15:13 we already support highbank 20:15:16 we currently only have the panda and vexpress as blockers 20:15:35 highbank == calxeda... kernel support is upstream 20:15:39 pwhalen: really, we blocked on getting highbank kernel patches in for F-17 20:15:45 pwhalen: suggest adding highbank. It has anaconda option. 20:15:56 bconoboy, +1 20:16:26 if highbank isn't there it should definitely be added, my understanding is that it was on the F17 list 20:16:29 yea, can't block on mvebu (Marvell), but it's great that it's almost there upstream 20:17:26 any others we should add? 20:17:52 nope. 20:17:53 #idea Shoot for F17 PA release criteria with consideration for the exceptions in FESCO's SA->PA guidelines. Add highbank as release blocker. 20:18:11 I would like to review what kernels we support at some stage. I would consider possibly removing imx 20:18:20 #agreed pwhalen to produce draft hybrid criteria 20:18:53 we could also build armv7nhl kernels- that'd split tegra out, speeding up time 20:19:10 plus there's cross-functional branding with hockey 20:19:21 what is nhl? 20:19:26 ive seen it before 20:19:28 n=neon 20:19:32 or national hockey league? 20:19:38 :) 20:19:38 ok 20:19:45 it's neon but the kernel doesn't directly use it so I don't see the point 20:20:04 cuts kernel build time as though we'd dropped a variant 20:20:31 it would parallelise the build a little but it makes it more complex and would break yum/rpm to a degree so I'd prefer not to 20:20:56 or we could drop imx. that'd be okay too ;-) 20:21:45 I'd like to consider it as it still doesn't properly support video which makes them useless for most mainline use cases people are interested in esp the smartbook 20:22:09 we could disable the build and leave it there for those that wish to build it themselves 20:22:41 pwhalen: Is alpha release planning in scope now? 20:22:51 last item for f18 - the rebuild is almost done, when do we want to start producing alpha releases? 20:22:58 it is 20:23:48 I think we said we would start producing images when f18 went alpha. Still the plan? 20:24:03 any idea when that is? 20:24:14 I believe we should be producing the alpha releases with lorax/media-creator/anaconda 20:24:30 https://fedoraproject.org/wiki/Releases/18/Schedule 20:24:38 looks like 8/28 20:24:50 so the question is when can we produce the image files we were for f-17 with media-creator 20:25:24 highbank, trimslice... yes 20:25:26 bconoboy: I think we should be producing images PRIOR to alpha so that we have an alpha release at the same time! 20:25:29 pbrobinson: not all of them, at least not yet 20:25:31 panda, beagle.... maybe? 20:25:45 we should be starting to test F-18 _NOW_ 20:25:47 pbrobinson: +1 20:25:54 * bconoboy is running it on his trimslice 20:26:06 plugs and imx... no 20:26:10 well, maybe? 20:26:12 dmarlin? 20:26:31 bconoboy: the only thing I've tested is highbank and trimslice 20:26:42 from the development side of things F-17 is now dead to us. We as a team need to have 100% dev focus on rawhide/F-18. F-17 is there for support 20:26:55 omap boards are more of a challenge due to u-boot partition requirements 20:27:03 dmarlin: no panda/panda-es? 20:27:11 pbrobinson: not yet 20:27:29 pbrobinson: dgilmore is working on getting the partitioning into anaconda 20:27:34 I can do the mknightly thing for other nominally supported platforms if we have to. 20:27:37 dmarlin: at the moment they're the only ones currently on the support list (and now just highbank) so they should be the focus IMO 20:28:30 so the real question is what needs to be done to get media-creator working for pandaboard / versatile (qemu) and highbank - ie the platforms we wish to support 20:28:52 does qemu make sense? 20:29:04 pbrobinson: there was discussion about creating a more 'generic' omap image using livemedia-creator, and using a deployment tool to created the board specific partitions (beagle, panda, etc.) 20:29:08 we need to start thinking along the lines of "will this take us towards primary architecture and / or the f-18 release" 20:29:39 dmarlin: where was the discussion? Was it on the mailing list or in koji? 20:29:52 pbrobinson: probably IRC 20:29:55 s/koji/wiki 20:30:36 pbrobinson: more of a suggestion than a real discussion 20:31:08 dmarlin: "probably IRC" means that the discussion didn't really happen. Can we take that to the list so it can be discussed and documented (in the archives) please. 20:31:21 I spoke with fossjon about adapting his raspberry pi deployment tool, but they were busy with the remix so he and I didnt get too far into it 20:31:22 pbrobinson: sounds good to me 20:31:38 dmarlin: btw massive kudos on kicking off the discussion on the cross-distro list about uboot A++++ 20:33:05 okay, er, where are we? 20:33:33 bconoboy: last was images for alpha and plans for alpha I believe 20:33:33 pbrobinson: I'll post some of my notes to the list regarding the omap image creation issue 20:33:43 #topic 2) Primary Architecture push 20:34:40 dmarlin bconoboy jonmasters: a side note: can we point the vendors that RH is talking to at that discussion and ask them to take notice about standardising uboot bits to make it easier for us to support their platforms (before uEFI becomes standard if that's the way it all eventually goes) 20:35:05 pwhalen: did you see my sub bullets for this discussion? 20:35:21 pbrobinson: it's high on our discussion list with vendors, believe me. 20:35:47 YAY! 20:35:54 pbrobinson, I see it now 20:36:11 #topic 2.1 ) Enterprise HW status for koji build platform 20:36:53 bconoboy: what's the status on the HW? 20:36:54 hardware status: We're working on pricing. 20:37:25 pbrobinson: thanks, I've got that ball (on the side note) 20:37:46 server soc's are a little pricey now because they don't benefit from full-scale production runs the way omap and tegra chips are churning out. Should have an update in a couple weeks. 20:37:58 do you guys support the tegra 3 yet? 20:38:02 (nexus 7) 20:38:11 don't think anybody has tried the kernel-tegra kernel with nexus 7 yet 20:38:19 I think we should plan on re-visting PA once we have definitive hardware plans in place 20:38:32 scientes: can you take that to #fedora-arm and I'll fill you in there 20:39:08 #action bconoboy to return with hardware update in 2 weeks 20:39:13 jonmasters: It's one component of PA and I think we need to continue moving forward on all points 20:39:18 pbrobinson: agree 20:39:24 #topic 2.2 ) Documentation status update 20:39:34 * jonmasters is super excited we'll have Anaconda support in F18 :) 20:39:36 basically we can't stop everything for one bit 20:40:09 * jcapik1 too 20:40:28 pwhalen: Is this about wiki gardening or something else? 20:40:45 jonmasters: we'll have _some_ Anaconda support in F18 20:40:50 I think so, pbrobinson? 20:40:58 jonmasters: not sure about _full_ Anaconda support 20:41:02 bconoboy: it was intended for the status of the documentation for the PA proposal etc 20:41:30 Oh, are we running through the full fesco list? 20:41:37 so basically who owns the docs, when were they last updates, how's it looks etc. 20:41:41 Yep, basically 20:41:45 dmarlin: what's exactly the difference between some and full? 20:41:57 #link https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements 20:42:09 jcapik1: right now, it's all kickstart driven... not fully interactive 20:42:28 jcapik1: only tested via serial console 20:42:35 we should be monitoring our F-18 progress against the FESCo requirements and our documents to ensure we follow F-18 even though it's not going to be an official feature 20:42:37 I don't believe we've worked with the fedora docs team to any extent to get arm integrated. 20:42:59 dmarlin: how about framebuffer? :] 20:43:15 dmarlin: jcapik1: can we take anaconda discussion to #fedora-arm please? 20:43:27 any volunteers to talk to the fedora docs team? 20:43:36 pbrobinson: yup 20:43:54 I think this is basically about taking our wiki knowledge and getting it into the standard docs, release-info 20:43:55 bconoboy: I was more thinking about the docs on the wiki TBH for the PA side of things 20:44:23 if we do more docs on the wiki it's just another thing we'll have to do again for PA 20:44:25 bconoboy: let's kick something off in #fedora-docs 20:44:32 bconoboy: things like QA and other such things that needed to be documented 20:44:36 jonmasters: volunteering? 20:44:43 sure, nail that puppy to me 20:44:59 #agreed jonmasters will contact #fedora-docs to start discussion on arm integration 20:45:12 pbrobinson: Okay, for QA I think that's a pwhalen task... 20:45:14 #topic 2.3 ) package build status 20:45:43 bconoboy, it is, and I will work on adding QA docs 20:45:53 #link http://fedoraproject.org/wiki/Architectures/ARM/Fedora17_rawhide 20:45:54 this is partially already covered by the status earlier. The main points I wanted to cover was missing packages 20:46:03 ok 20:46:21 #topic 2.4 ) Status update on QA and QA process 20:46:24 pwhalen: thanks paul 20:46:48 pwalen: was still typing 20:47:19 so we have a working instance of autoqa thats been running for a while. With new anaconda support I can start to delve more into the actual testing. I was hoping to start asap, with hardware access 20:48:08 pwhalen: Can we backup to 2.3? 20:48:11 pwhalen: you could start by using one of the highbank systems we have because it ought to "just work" once the anaconda bits land 20:48:15 the status is improving. I've crossed a number of the list, we need people to look at more. luckily the attention for the bi-annual pre branch package killing has broadened and there's a whole lot of packages that are ftbfs being either fixed or killed so the list should narrow a lot shortly. 20:48:26 #topic 2.3 ) package build status 20:48:42 so we'll know a lot better what the current outstanding tasks are in a week or so when we branch for alpha 20:48:43 EOL 20:48:51 #info per pbrobinson freeglut and webkitgtk3 are holding up some builds 20:49:13 okay, back to 2.4? 20:49:29 #topic 2.4 ) Status update on QA and QA process 20:49:43 yep. post branch I'll do a bigger update so it's more bullet point of what needs to be fixed 20:49:45 jonmasters, excellent 20:50:31 pwhalen: we can always take one of the internal builders offline for this kind of thing, getting autoqa bent into shape is going to be awesome progress toward PA 20:51:22 jonmasters, perfect 20:52:39 pwhalen: what bits are you planning on working on for QA 20:52:40 pbrobinson, I'd like to talk with you more about this, whats missing you'd like to see added 20:53:06 are you engaging with adamw and the rest of QA to work out what they'll need for QA moving forward? 20:53:26 I have, yes 20:54:17 ultimately for QA it's very open ended so you'll need to engage with QA and work with them to define who does what so I was sort of hoping for an update on where this is going in relation to PA 20:54:44 I should have a better update next week 20:54:50 I think that's an action there. Perhaps next week Paul can...yep 20:55:03 OK, great 20:55:24 autoqa relies on anaconda working, so now thats there, I can start to run the actual tests 20:56:07 but pbrobinson please ping me if you see something missing, or something you would like to see 20:56:08 #info pwhalen to bring QA+PA update next week 20:56:10 autoqa is a tiny component of QA though, there's all sorts of tests that are gone through for every stage of the release 20:57:15 there's whole chunks of process on the wiki with matixes for every stage of the release that need to have lots of green ticks in them for the release to be able to progress forwards to the next stge 20:57:41 we need to be defining for PA where and how ARM will fix into those, where and what bits we need to block a release on etc. 20:57:51 so that's what we need to document 20:57:59 and many of those dont make sense for us 20:59:00 pwhalen: I'm not saying they necessarily do. But things like "install a working system" and "update packages" "browse the web with the default browser" do make senes 20:59:37 we have covered those in the vfads, which once we do an alpha compose, we can have another 20:59:52 but ultimately the work to get us to PA requires us to identify what does, and document how those bits might be different, and those that don't and document why they don't 21:00:20 pwhalen: so if they've been covered it's all documented somewhere then right? 21:00:31 the vfads? yes 21:01:15 OK, great then 21:02:19 moving forward I believe we need to follow the PA processes as closely as possible for the F-18 cycle. We need to get use to this because when we block as release in the move to PA and people start yelling we need to justify 21:02:38 agreed 21:03:06 #topic 3) Raspberry Pi Remix Update 21:03:39 So at the moment we're working on a fresh compose. We've run into an issue where older versions of updated packacges are being pulled in 21:03:52 fossjon and agreene are investigating the issue 21:03:55 frojoe: how is that possible? 21:04:28 Possibly packaging hiccups or a repo issue. 21:04:40 why don't you just move them into an archive repository so they're available for reference but don't impact the compose 21:05:17 We can do that 21:06:04 did anyone have thoughts on why Raspi is being criticized as "slow" compared with Debian 21:06:05 Agreene, on his way too and from the armory, said that he is fine with doing that. So, we can start it tomorrow 21:06:05 ? 21:06:25 I don't agree that it's just a lack of a v6 build that explains it 21:06:32 I agree it's likely packaging issues that need to be fixed, but why don't you split it out into two tasks. One person fix the packages while one operates on a separate repo for the compose so you don't block on it 21:06:42 and ask for help! 21:07:34 Well, this issue popped up as of the latest compose 21:08:00 jonmasters; I looked at the review on that and there's a few spots where it was much faster but in most stats it was only a percentage point here and there. And for most of the much higher I'm not convinced we couldn't close most of those gaps with arm6l builds 21:08:09 Correction, the issue might be fixed on the latest compose 21:08:30 Frojoe: so what packages changed and how, it should be fairly easy to slice and dice 21:08:36 pbrobinson: really? was that all? someone was whining about "3x" factors and other nonsense. If that's all, I don't much care :) 21:08:47 pbrobinson, issue is fixed as of newest compose 21:08:52 jonmasters: has anybody measured the speed difference? 21:08:56 * Frojoe is getting up to the second details 21:08:57 Frojoe: perhaps someone on the Seneca side could compare Debian and Fedora and let us know? 21:09:10 Frojoe: so the compose issue is fixed. What else is outstanding on the compose? 21:09:18 We should be getting our batch of pies very soon, so we'll have the hardware for side by side testing 21:09:19 Raspian is armv6hl built no? 21:09:24 sorry, what's outstanding on the release 21:09:49 I grabbed the raspian release to check out how it runs 21:09:52 jonmasters: if you look at the graphs the 140% increase in speed is in a few choice particular tasks 21:09:58 We're working on the date fixup thing 21:10:13 right. So setting of the date on boot? 21:10:19 Yup 21:10:41 So right now, we're just getting feedback and fixing things 21:10:56 Removing unneeded packages and whatnot 21:11:12 ctyler_away, wants this release to be spot on 21:11:42 Frojoe, any eta on a alpha/beta? 21:11:48 right, so if it has to be spot on it will never be released because nothing is ever perfect 21:12:13 pbrobinson, need to consult ctyler on that one 21:12:14 I think besting the Raspbian release is the goal 21:12:29 ya people love the Raspian os 21:12:31 :/ 21:12:34 the latest image looks, and works very well 21:12:43 we're trying really hard 21:13:21 anything else to add about the Raspi? 21:13:26 pwhalen: I think we should get a reasonable release out that works and is stable and move on and aim for f-18. 21:13:46 I think its there already, just some optimizing 21:14:22 #topic 4) Your topic here 21:14:39 we're in overtime, but any last discussion items? 21:14:51 nope 21:14:51 Regarding the read only builder thing, we were debating 21:14:58 jonmasters: http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/ if you look at the graphs the "improvements between 4 and 40%" is mostly in h264 and mp3 decode which in theory should be all done on the GPU and hence not be affected 21:15:16 oh ok meh then 21:15:18 Adding something to the koji daemon to report a not ready if a read only filesystem is detected so that read-only builders don't mess up builds 21:15:39 Frojoe, cool 21:15:50 and for the rest I think we can get most of the rest of it with some select builds of armv6l packages to make the most of the v6 feature set. 21:16:18 Frojoe: that would be fab!! 21:16:33 shall we wrap? 21:16:50 #endmeeting