fedora-meeting-1
LOGS
20:01:44 <pwhalen> #startmeeting
20:01:44 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:44 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore
20:01:44 <zodbot> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen
20:01:52 <dmarlin> .fas dmarlin
20:01:53 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:01:53 <pwhalen> .fas pwhalen
20:01:56 * pbrobinson waves
20:01:56 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
20:01:59 <Frojoe> .fas frojoe
20:02:00 <bconoboy> .fas blc@
20:02:00 <zodbot> Frojoe: jacwang 'Jordan Cwang' <jordan.cwang@gmail.com> - burningfool 'Jordan Cwang' <frojoe.21@gmail.com>
20:02:01 <jonmasters> .fas jonmasters
20:02:01 <maxam> .fas maxam
20:02:02 <zodbot> bconoboy: blc '' <blc@redhat.com>
20:02:05 <agreene> .fas agreene
20:02:06 <zodbot> jonmasters: jcm 'Jon Masters' <jonathan@jonmasters.org>
20:02:08 <jcapik1> .fas jcapik
20:02:09 <zodbot> maxam: maxam '' <masihul.abed@senecacollege.ca> - maxamaxim '' <maxamaxim@me.com> - maxamillion 'Adam Miller' <maxamillion@gmail.com>
20:02:12 <zodbot> agreene: tag4fedora 'Tim Greene' <tagreene@flowserve.com> - agreene 'Andrew Greene' <agreene@learn.senecac.on.ca>
20:02:15 <zodbot> jcapik1: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:02:22 <pbrobinson> what is with all the .fas BS?
20:02:46 <maxam> It means I am here! :)
20:03:11 <pwhalen> #topic 1) F18 - Mass rebuild status - Defining release criteria - Alpha Release
20:03:29 <pwhalen> we'll tackle those in order..
20:03:36 * jonmasters is on phone calls
20:03:49 <pwhalen> pbrobinson, anything to share about the rebuild or is that, going as planned?
20:03:57 <pbrobinson> yes
20:03:57 <pwhalen> saw your note about slow Koji
20:04:15 <fossjon> the koji hosts page seems slow
20:04:18 <pbrobinson> we're getting there. arm.koji has been slow, of late
20:04:22 <pwhalen> fossjon, very
20:04:32 <pwhalen> now two pages of hosts
20:04:39 <pbrobinson> and there was outage for planned maint on ML koji last night
20:05:10 <pbrobinson> 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 <fossjon> hehe i just posted this -> http://lists.fedoraproject.org/pipermail/arm/2012-August/003785.html
20:05:38 <fossjon> its not that meaningful tho
20:05:43 <pbrobinson> but we're getting there and closing stuff out relatively quickly
20:05:44 <pwhalen> pbrobinson, +1 - and queued more jobs
20:06:16 <pbrobinson> pwhalen: that's speed and stability of k-s and koji tbh :)
20:06:37 <pwhalen> awesome.. okay.. anyone have anything else to share regarding the rebuild?
20:06:42 <bconoboy> why is koji running slow?
20:07:08 <pbrobinson> fossjon: that link makes no sense to me what so ever
20:07:12 <fossjon> i think its the db
20:07:24 <fossjon> theres this state table that gets pretty huge
20:07:30 <pwhalen> Seneca folks, anything happening on Koji?
20:08:03 <pbrobinson> 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 <Frojoe> Nothing we've noticed today, we can look into it
20:08:58 <pwhalen> #action Seneca to check on the status of why Koji has been slow
20:09:09 <pbrobinson> Frojoe: dgilmore showed me this around 8 hours ago:
20:09:09 <pbrobinson> (13:35:10) dgilmore: Aug  1 01:00:01 hongkong kernel: [459278.725544] md: data-check of RAID array md5
20:09:09 <pbrobinson> (13:35:13) dgilmore: Aug  1 01:00:01 hongkong kernel: [459278.725548] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
20:09:09 <pbrobinson> (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 <pbrobinson> (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 <pwhalen> okay.. next item for F18 is defining our release criteria..
20:10:51 <bconoboy> same as f17? or more?
20:10:54 <pbrobinson> more
20:11:00 <bconoboy> maybe go with f17 primary criteria?
20:11:11 <pbrobinson> we should be aiming to be following primary promotion criteria
20:11:31 <pwhalen> I'll take a look at PA's release criteria and adapt it much like we did the first time
20:12:18 <dmarlin> same targets platforms?
20:12:19 <pbrobinson> 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 <pbrobinson> dmarlin: do you mean devices?
20:12:53 <dmarlin> yes
20:12:54 <jonmasters> http://www.cavium.com/newsevents_Cavium_Unveils_Project_Thunder.html
20:12:56 <jonmasters> ^^^ btw
20:13:00 <dmarlin> panda, vexpress, etc.
20:13:12 <pwhalen> I think we can expand the the devices to include a bit more, thoughts?
20:13:17 <pbrobinson> jonmasters: is that to do with f18 ?
20:13:21 <bconoboy> 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 <jonmasters> pbrobinson: no, just hit the wire and wanted to share
20:13:56 <pbrobinson> 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 <pbrobinson> at the moment there are no new devices we can currently support
20:14:37 <dmarlin> ok, just checking for clarification
20:14:38 <pbrobinson> 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 <dmarlin> pbrobinson: highbank shoud be, I think
20:15:11 <scientes> highbank != marvell
20:15:13 <pbrobinson> we already support highbank
20:15:16 <pwhalen> we currently only have the panda and vexpress as blockers
20:15:35 <dmarlin> highbank == calxeda... kernel support is upstream
20:15:39 <pbrobinson> pwhalen: really, we blocked on getting highbank kernel patches in for F-17
20:15:45 <bconoboy> pwhalen: suggest adding highbank.  It has anaconda option.
20:15:56 <pwhalen> bconoboy, +1
20:16:26 <pbrobinson> if highbank isn't there it should definitely be added, my understanding is that it was on the F17 list
20:16:29 <jonmasters> yea, can't block on mvebu (Marvell), but it's great that it's almost there upstream
20:17:26 <pwhalen> any others we should add?
20:17:52 <pbrobinson> nope.
20:17:53 <bconoboy> #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 <pbrobinson> I would like to review what kernels we support at some stage. I would consider possibly removing imx
20:18:20 <bconoboy> #agreed pwhalen to produce draft hybrid criteria
20:18:53 <bconoboy> we could also build armv7nhl kernels- that'd split tegra out, speeding up time
20:19:10 <bconoboy> plus there's cross-functional branding with hockey
20:19:21 <fossjon> what is nhl?
20:19:26 <fossjon> ive seen it before
20:19:28 <bconoboy> n=neon
20:19:32 <bconoboy> or national hockey league?
20:19:38 <maxam> :)
20:19:38 <fossjon> ok
20:19:45 <pbrobinson> it's neon but the kernel doesn't directly use it so I don't see the point
20:20:04 <bconoboy> cuts kernel build time as though we'd dropped a variant
20:20:31 <pbrobinson> 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 <bconoboy> or we could drop imx. that'd be okay too ;-)
20:21:45 <pbrobinson> 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 <pbrobinson> we could disable the build and leave it there for those that wish to build it themselves
20:22:41 <bconoboy> pwhalen: Is alpha release planning in scope now?
20:22:51 <pwhalen> last item for f18 - the rebuild is almost done, when do we want to start producing alpha releases?
20:22:58 <pwhalen> it is
20:23:48 <bconoboy> I think we said we would start producing images when f18 went alpha.  Still the plan?
20:24:03 <pwhalen> any idea when that is?
20:24:14 <pbrobinson> I believe we should be producing the alpha releases with lorax/media-creator/anaconda
20:24:30 <bconoboy> https://fedoraproject.org/wiki/Releases/18/Schedule
20:24:38 <bconoboy> looks like 8/28
20:24:50 <pbrobinson> so the question is when can we produce the image files we were for f-17 with media-creator
20:25:24 <bconoboy> highbank, trimslice... yes
20:25:26 <pbrobinson> 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 <dmarlin> pbrobinson: not all of them, at least not yet
20:25:31 <bconoboy> panda, beagle.... maybe?
20:25:45 <pbrobinson> we should be starting to test F-18 _NOW_
20:25:47 <bconoboy> pbrobinson: +1
20:25:54 * bconoboy is running it on his trimslice
20:26:06 <bconoboy> plugs and imx... no
20:26:10 <bconoboy> well, maybe?
20:26:12 <bconoboy> dmarlin?
20:26:31 <dmarlin> bconoboy: the only thing I've tested is highbank and trimslice
20:26:42 <pbrobinson> 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 <dmarlin> omap boards are more of a challenge due to u-boot partition requirements
20:27:03 <pbrobinson> dmarlin: no panda/panda-es?
20:27:11 <dmarlin> pbrobinson: not yet
20:27:29 <dmarlin> pbrobinson: dgilmore is working on getting the partitioning into anaconda
20:27:34 <bconoboy> I can do the mknightly thing for other nominally supported platforms if we have to.
20:27:37 <pbrobinson> 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 <pbrobinson> 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 <bconoboy> does qemu make sense?
20:29:04 <dmarlin> 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 <pbrobinson> 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 <pbrobinson> dmarlin: where was the discussion? Was it on the mailing list or in koji?
20:29:52 <dmarlin> pbrobinson: probably IRC
20:29:55 <pbrobinson> s/koji/wiki
20:30:36 <dmarlin> pbrobinson: more of a suggestion than a real discussion
20:31:08 <pbrobinson> 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 <pwhalen> 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 <dmarlin> pbrobinson: sounds good to me
20:31:38 <pbrobinson> dmarlin: btw massive kudos on kicking off the discussion on the cross-distro list about uboot A++++
20:33:05 <bconoboy> okay, er, where are we?
20:33:33 <pbrobinson> bconoboy: last was images for alpha and plans for alpha I believe
20:33:33 <dmarlin> pbrobinson: I'll post some of my notes to the list regarding the omap image creation issue
20:33:43 <pwhalen> #topic 2) Primary Architecture push
20:34:40 <pbrobinson> 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 <pbrobinson> pwhalen: did you see my sub bullets for this discussion?
20:35:21 <bconoboy> pbrobinson: it's high on our discussion list with vendors, believe me.
20:35:47 <pbrobinson> YAY!
20:35:54 <pwhalen> pbrobinson, I see it now
20:36:11 <pwhalen> #topic 2.1 ) Enterprise HW status for koji build platform
20:36:53 <pbrobinson> bconoboy: what's the status on the HW?
20:36:54 <bconoboy> hardware status: We're working on pricing.
20:37:25 <jonmasters> pbrobinson: thanks, I've got that ball (on the side note)
20:37:46 <bconoboy> 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 <scientes> do you guys support the tegra 3 yet?
20:38:02 <scientes> (nexus 7)
20:38:11 <bconoboy> don't think anybody has tried the kernel-tegra kernel with nexus 7 yet
20:38:19 <jonmasters> I think we should plan on re-visting PA once we have definitive hardware plans in place
20:38:32 <pbrobinson> scientes: can you take that to #fedora-arm and I'll fill you in there
20:39:08 <bconoboy> #action bconoboy to return with hardware update in 2 weeks
20:39:13 <pbrobinson> jonmasters: It's one component of PA and I think we need to continue moving forward on all points
20:39:18 <jonmasters> pbrobinson: agree
20:39:24 <pwhalen> #topic 2.2 ) Documentation status update
20:39:34 * jonmasters is super excited we'll have Anaconda support in F18 :)
20:39:36 <pbrobinson> basically we can't stop everything for one bit
20:40:09 * jcapik1 too
20:40:28 <bconoboy> pwhalen: Is this about wiki gardening or something else?
20:40:45 <dmarlin> jonmasters: we'll have _some_ Anaconda support in F18
20:40:50 <pwhalen> I think so, pbrobinson?
20:40:58 <dmarlin> jonmasters: not sure about _full_ Anaconda support
20:41:02 <pbrobinson> bconoboy: it was intended for the status of the documentation for the PA proposal etc
20:41:30 <bconoboy> Oh, are we running through the full fesco list?
20:41:37 <pbrobinson> so basically who owns the docs, when were they last updates, how's it looks etc.
20:41:41 <pbrobinson> Yep, basically
20:41:45 <jcapik1> dmarlin: what's exactly the difference between some and full?
20:41:57 <bconoboy> #link https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements
20:42:09 <dmarlin> jcapik1: right now, it's all kickstart driven... not fully interactive
20:42:28 <dmarlin> jcapik1: only tested via serial console
20:42:35 <pbrobinson> 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 <bconoboy> I don't believe we've worked with the fedora docs team to any extent to get arm integrated.
20:42:59 <jcapik1> dmarlin: how about framebuffer? :]
20:43:15 <pbrobinson> dmarlin: jcapik1: can we take anaconda discussion to #fedora-arm please?
20:43:27 <bconoboy> any volunteers to talk to the fedora docs team?
20:43:36 <jcapik1> pbrobinson: yup
20:43:54 <bconoboy> I think this is basically about taking our wiki knowledge and getting it into the standard docs, release-info
20:43:55 <pbrobinson> bconoboy: I was more thinking about the docs on the wiki TBH for the PA side of things
20:44:23 <bconoboy> if we do more docs on the wiki it's just another thing we'll have to do again for PA
20:44:25 <jonmasters> bconoboy: let's kick something off in #fedora-docs
20:44:32 <pbrobinson> bconoboy: things like QA and other such things that needed to be documented
20:44:36 <bconoboy> jonmasters: volunteering?
20:44:43 <jonmasters> sure, nail that puppy to me
20:44:59 <bconoboy> #agreed jonmasters will contact #fedora-docs to start discussion on arm integration
20:45:12 <bconoboy> pbrobinson: Okay, for QA I think that's a pwhalen task...
20:45:14 <pwhalen> #topic 2.3 ) package build status
20:45:43 <pwhalen> bconoboy, it is, and I will work on adding QA docs
20:45:53 <bconoboy> #link http://fedoraproject.org/wiki/Architectures/ARM/Fedora17_rawhide
20:45:54 <pbrobinson> this is partially already covered by the status earlier. The main points I wanted to cover was missing packages
20:46:03 <pwhalen> ok
20:46:21 <pwhalen> #topic 2.4 ) Status update on QA and QA process
20:46:24 <jonmasters> pwhalen: thanks paul
20:46:48 <pbrobinson> pwalen: was still typing
20:47:19 <pwhalen> 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 <bconoboy> pwhalen: Can we backup to 2.3?
20:48:11 <jonmasters> 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 <pbrobinson> 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 <pwhalen> #topic 2.3 ) package build status
20:48:42 <pbrobinson> 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 <pbrobinson> EOL
20:48:51 <bconoboy> #info per pbrobinson freeglut and webkitgtk3 are holding up some builds
20:49:13 <bconoboy> okay, back to 2.4?
20:49:29 <pwhalen> #topic 2.4 ) Status update on QA and QA process
20:49:43 <pbrobinson> yep. post branch I'll do a bigger update so it's more bullet point of what needs to be fixed
20:49:45 <pwhalen> jonmasters, excellent
20:50:31 <jonmasters> 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 <pwhalen> jonmasters, perfect
20:52:39 <pbrobinson> pwhalen: what bits are you planning on working on for QA
20:52:40 <pwhalen> pbrobinson, I'd like to talk with you more about this, whats missing you'd like to see added
20:53:06 <pbrobinson> are you engaging with adamw and the rest of QA to work out what they'll need for QA moving forward?
20:53:26 <pwhalen> I have, yes
20:54:17 <pbrobinson> 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 <pwhalen> I should have a better update next week
20:54:50 <jonmasters> I think that's an action there. Perhaps next week Paul can...yep
20:55:03 <pbrobinson> OK, great
20:55:24 <pwhalen> autoqa relies on anaconda working, so now thats there, I can start to run the actual tests
20:56:07 <pwhalen> but pbrobinson please ping me if you see something missing, or something you would like to see
20:56:08 <bconoboy> #info pwhalen to bring QA+PA update next week
20:56:10 <pbrobinson> 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 <pbrobinson> 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 <pbrobinson> 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 <pbrobinson> so that's what we need to document
20:57:59 <pwhalen> and many of those dont make sense for us
20:59:00 <pbrobinson> 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 <pwhalen> we have covered those in the vfads, which once we do an alpha compose, we can have another
20:59:52 <pbrobinson> 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 <pbrobinson> pwhalen: so if they've been covered it's all documented somewhere then right?
21:00:31 <pwhalen> the vfads? yes
21:01:15 <pbrobinson> OK, great then
21:02:19 <pbrobinson> 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 <pwhalen> agreed
21:03:06 <pwhalen> #topic 3) Raspberry Pi Remix Update
21:03:39 <Frojoe> 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 <Frojoe> fossjon and agreene are investigating the issue
21:03:55 <bconoboy> frojoe: how is that possible?
21:04:28 <Frojoe> Possibly packaging hiccups or a repo issue.
21:04:40 <pbrobinson> 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 <Frojoe> We can do that
21:06:04 <jonmasters> did anyone have thoughts on why Raspi is being criticized as "slow" compared with Debian
21:06:05 <Frojoe> 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 <jonmasters> ?
21:06:25 <jonmasters> I don't agree that it's just a lack of a v6 build that explains it
21:06:32 <pbrobinson> 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 <pbrobinson> and ask for help!
21:07:34 <Frojoe> Well, this issue popped up as of the latest compose
21:08:00 <pbrobinson> 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 <Frojoe> Correction, the issue might be fixed on the latest compose
21:08:30 <pbrobinson> Frojoe: so what packages changed and how, it should be fairly easy to slice and dice
21:08:36 <jonmasters> 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 <Frojoe> pbrobinson, issue is fixed as of newest compose
21:08:52 <jcapik1> jonmasters: has anybody measured the speed difference?
21:08:56 * Frojoe is getting up to the second details
21:08:57 <jonmasters> Frojoe: perhaps someone on the Seneca side could compare Debian and Fedora and let us know?
21:09:10 <pbrobinson> Frojoe: so the compose issue is fixed. What else is outstanding on the compose?
21:09:18 <Frojoe> We should be getting our batch of pies very soon, so we'll have the hardware for side by side testing
21:09:19 <fossjon> Raspian is armv6hl built no?
21:09:24 <pbrobinson> sorry, what's outstanding on the release
21:09:49 <pwhalen> I grabbed the raspian release to check out how it runs
21:09:52 <pbrobinson> jonmasters: if you look at the graphs the 140% increase in speed is in a few choice particular tasks
21:09:58 <Frojoe> We're working on the date fixup thing
21:10:13 <pbrobinson> right. So setting of the date on boot?
21:10:19 <Frojoe> Yup
21:10:41 <Frojoe> So right now, we're just getting feedback and fixing things
21:10:56 <Frojoe> Removing unneeded packages and whatnot
21:11:12 <Frojoe> ctyler_away, wants this release to be spot on
21:11:42 <pwhalen> Frojoe, any eta on a alpha/beta?
21:11:48 <pbrobinson> right, so if it has to be spot on it will never be released because nothing is ever perfect
21:12:13 <Frojoe> pbrobinson, need to consult ctyler on that one
21:12:14 <pwhalen> I think besting the Raspbian release is the goal
21:12:29 <fossjon> ya people love the Raspian os
21:12:31 <fossjon> :/
21:12:34 <pwhalen> the latest image looks, and works very well
21:12:43 <fossjon> we're trying really hard
21:13:21 <pwhalen> anything else to add about the Raspi?
21:13:26 <pbrobinson> 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 <pwhalen> I think its there already, just some optimizing
21:14:22 <pwhalen> #topic 4) Your topic here
21:14:39 <pwhalen> we're in overtime, but any last discussion items?
21:14:51 <bconoboy> nope
21:14:51 <Frojoe> Regarding the read only builder thing, we were debating
21:14:58 <pbrobinson> 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 <jonmasters> oh ok meh then
21:15:18 <Frojoe> 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 <pwhalen> Frojoe, cool
21:15:50 <pbrobinson> 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 <pbrobinson> Frojoe: that would be fab!!
21:16:33 <pwhalen> shall we wrap?
21:16:50 <pwhalen> #endmeeting