21:01:19 <pwhalen> #startmeeting Fedora ARM weekly status meeting
21:01:19 <zodbot> Meeting started Wed Jan 23 21:01:19 2013 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:01:19 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson
21:01:19 <zodbot> Current chairs: bconoboy ctyler jonmasters pbrobinson pwhalen
21:01:26 <jonmasters> .fas jonmasters
21:01:27 <bconoboy> .fas blc@
21:01:27 <zodbot> jonmasters: jcm 'Jon Masters' <jonathan@jonmasters.org>
21:01:27 <pwhalen> good afternoon all
21:01:28 <jcapik> .fas jcapik
21:01:29 <fossjon> hey!
21:01:30 <zodbot> bconoboy: blc '' <blc@redhat.com>
21:01:32 <pwhalen> .fas pwhalen
21:01:33 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
21:01:36 <ahs3> .fas ahs3
21:01:36 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
21:01:39 <zodbot> ahs3: ahs3 'Al Stone' <ahs3@redhat.com>
21:02:05 <pwhalen> #topic 0) Status of ACTION items from previous meeting
21:02:36 <pwhalen> checking our action items, most have been closed - 1. Highbank kernel, Fudcon items,
21:02:49 <pwhalen> remaining is yumex, and is being worked on
21:03:05 <pwhalen> #link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-16/fedora-meeting-1.2013-01-16-21.00.html
21:03:15 <ctyler> .fas chris@tylers.info
21:03:15 <zodbot> ctyler: ctyler 'Chris Tyler' <chris@tylers.info>
21:03:15 * ctyler waves
21:03:27 <pwhalen> packages have been signed and ready to go for F18, thanks dgilmore
21:03:28 <jonmasters> yumex is not a priority. It's being used to triage other stuff, but PackageKit is the requirement
21:03:48 * masta is here
21:03:57 <pwhalen> right
21:04:20 * jonmasters has the ball on pkexec/PackageKit. I will send out an update in a few hours
21:04:28 <jonmasters> I just got back from a needed 1hr run :)
21:04:30 <pwhalen> anything else to add on the actions items?
21:04:47 <bconoboy> #action jonmasters taking over PackageKit/pkexec issue, will have update in a few hours
21:05:04 <bconoboy> pwhalen: that's it
21:05:15 <masta> jonmasters: let me know how that goes, looks like brk() does something bad on arm
21:05:33 <fossjon> so we'll be able to do an f18-arm compose then this week hopefully?
21:05:43 <pwhalen> #topic 1) Problem packages
21:06:20 <pwhalen> Peter doesnt appear to be around for the meeting, shall we skip this one? or is anyone aware of packages needing attention?
21:06:35 <bconoboy> llvm- we need this fixed in f19
21:06:51 <masta> me is going to poke at ltrace once polkit is handled
21:07:57 <jonmasters> masta: just tell me one thing, did you poke using v5 or v7?
21:08:05 <masta> v7
21:08:12 <pwhalen> #info llvm needs attention in F19
21:08:30 <seano> Is the llvm issue just the triplet thing?
21:08:36 <jonmasters> yes
21:08:36 <bconoboy> likely.
21:08:54 <jonmasters> it's going to get worse because things are starting to require llvm
21:09:14 <masta> I thought triplet thing can be a patch in the Makefile to hardcode one in teh case of arm*
21:09:21 <seano> there is a triplet.cpp file that defines those.. so it shouldnt be terrible.
21:09:24 <jonmasters> #action jonmasters to co-ordinate with Linaro and upstream LLVM community on de-Debiantuifying the triplet handling in LLVM and making it correct
21:09:29 <pwhalen> any other packages? I saw some mention in channel earlier
21:09:44 <bconoboy> #action masta to look into ltrace
21:10:06 <bconoboy> jonmasters: mongodb?
21:10:06 <seano> Do we have an active list of broken, or excluded packages?
21:10:10 <jonmasters> (going forward, anyone proposing whacky triplets and weirdness needs to be stomped on)
21:10:29 <jonmasters> #action jonmasters to post patch for mongodb after F18 fixes, before Monday
21:10:47 <seano> did you get the atomics sorted out?
21:11:01 <jonmasters> #info pwhalen to check on interim actions prior to next week's meeting - e.g. Monday
21:11:26 <jonmasters> seano: it's a trivial patch, I just need a few min. And I'm doing pkexec first. As Carlos says, I can do anything, not everything. I love that quote.
21:12:24 <bconoboy> pwhalen: I think that's it- creating The Big List is probably a fudcon discussion point
21:12:28 <fossjon> jonmasters :)
21:12:43 <jonmasters> Oh yea, we need The Big List
21:12:46 <pwhalen> seano, we do have a page, I can't  find the link to it. bugtrackers are linked on the main arm page, does anyone have a link to Peters page?
21:12:51 <jonmasters> #action jonmasters to send photos of whiteboard out
21:12:55 <jonmasters> #undo
21:12:55 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x17f96050>
21:13:16 <fossjon> /dereference 0x17f96050
21:13:58 <pwhalen> moving on?
21:14:01 * jonmasters has photos from FUDCon uploading to flickr, including the photos of the whiteboard
21:14:05 <jonmasters> I will send those out to the list
21:14:12 <jonmasters> pwhalen: we'll come back to FUDCon
21:14:17 <pwhalen> #topic 2) F18 final - update on remaining blockers
21:14:51 <seano> im guessing the white board was more of a blackboard by the end.. :)
21:15:12 <pwhalen> of our blockers, we have the eclipse build pending.
21:15:29 <pwhalen> the kernel-dtb subpackage is being worked on by dgilmore, not sure if he has an update
21:15:35 <bconoboy> has the 3.7 kernel booted on everything yet?
21:16:04 <pwhalen> bconoboy, I boot tested the panda, trimslice, vexpress (-x), and the Guru
21:16:09 <jonmasters> so dgilmore has the ball on kernel-dtb. It's more involved than it seems because of how the build is done, but he will do that and is talking to legal. For the record, the plan is to take the kernel-dtb from 3.7 and rip out the dtb files for the platforms we need, then ship those in the 3.6 based final RC/F18 GA builds, along with a text file referencing the build with the source to the dtbs in the zero day 3.7 update kernel
21:16:11 <pwhalen> all worked as expected
21:16:27 <jonmasters> ^^^ above is based on phone call with dgilmore earlier
21:17:32 <jonmasters> #info eclipse build is here: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=108801 (thanks to blc for re-issuing until it stuck last night)
21:18:01 <bconoboy> jonmasters: Any thoughts on why versatile express + x doesn't work?
21:18:05 <pwhalen> #action dgilmore to create kernel-dtb subpackage for 3.7, use those for shipping F18 GA with 3.6 kernel (pending approval)
21:18:18 <jonmasters> bconoboy: I have not looked yet. Anyone got a syndrome description?
21:18:24 <jonmasters> pwhalen: what happens with vexpress and x?
21:18:41 <bconoboy> Is there any special reason we're not making the F18 final use 3.7 out of the box?
21:18:57 <pwhalen> only a black screen when booted, no output
21:19:48 <jonmasters> bconoboy: consistency with PA
21:20:16 <jonmasters> bconoboy: we're about to propose going to primary, we can't be doing things that look crazy
21:20:33 <fossjon> pwhalen is it my scripts fauly for vexpress+x?
21:20:38 <fossjon> fault*
21:20:41 <bconoboy> jonmasters: 3.7 dtbs with 3.6 kernel also looks crazy :-)
21:20:56 <pwhalen> on vexpress I have tried a few kernels, to verify that the change to virtio had no impact, the same results
21:20:58 <bconoboy> perhaps not as crazy though
21:21:00 <ctyler> bconoboy: s/crazy/more crazy/
21:21:04 <jonmasters> bconoboy: blame that on the lack of a standard platform - but we have a story there and people know it's going to UEFI+ACPI
21:21:13 <pwhalen> used the dtb from 3.7 and 3.6
21:21:28 <seano> Well we -could- defend it by saying it is a lot harder to do a kernel upgrade.
21:21:31 <jonmasters> pwhalen: what happens?
21:21:45 <pwhalen> nothing, no output at all
21:21:45 <jonmasters> pwhalen: I can look at it, after PackageKit, but I need to know what happens
21:21:52 <bconoboy> <pwhalen> only a black screen when booted, no output
21:21:55 <jonmasters> pwhalen: with the 3.7 kernel only?
21:22:02 <seano> jonmasters: I think it isn't attaching to the right console..
21:22:07 <pwhalen> and 3.6
21:22:08 <jonmasters> pwhalen: did you boot with any debug options?
21:22:17 <jonmasters> pwhalen: what host qemu version?
21:22:31 <jonmasters> how did we only find this now?
21:22:47 <pwhalen> its when using a dtb, without the dtb it works fine
21:22:53 <jonmasters> ah ok
21:23:00 <ctyler> pwhalen: is this a regression?
21:23:11 <jonmasters> pwhalen: without a dtb on 3.7 it falls over?
21:23:21 <pwhalen> this is qemu-system-arm-1.2.2-1.fc18
21:23:22 <jonmasters> pwhalen: I assume it doesn't boot on 3.7 without a dtb?
21:23:40 <pwhalen> right, 3.6 will boot into x without the dtb, when including one it will not
21:23:55 <jonmasters> ok and 3.7 will not boot regardless?
21:23:55 <pwhalen> and 3.7 will not boot without a dtb
21:23:59 <jonmasters> oh ok
21:24:07 <pwhalen> for x, boots to serial fine
21:24:20 <jonmasters> so we have two options. Tomorrow, I will look at making 3.6 boot with the dtb
21:24:38 <jonmasters> however, otherwise we will modify the scripts we ship with vexpress images to only apply the dtb on 3.7+ kernels
21:24:55 <bconoboy> jonmasters: I'm updating the boot script to make the dtb an optional parameter.
21:25:09 <jonmasters> bconoboy: indeed, I saw that :) but that's not quite what I said :)
21:25:11 <seano> is there an ignore dtb flag?
21:25:23 <jonmasters> seano: there is either a dtb parameter to qemu, or not
21:25:36 <bconoboy> jonmasters: you want it to force the use of dtb with 3.7?
21:25:49 <jonmasters> pwhalen: I'll track down what's going wrong with the dtb, but I might not get to it in time, etc. so bconoboy modifying the script is prudent
21:26:04 <jonmasters> bconoboy: it is my understanding that the kernel will not boot on 3.7 without a dtb
21:26:24 <jonmasters> bconoboy: if the vexpress kernel will boot on 3.7 normally to x without a dtb, I'm game with just making it optional
21:26:49 <bconoboy> jonmasters: I guess the real question is: Do we need to block the release on this? I don't think so. It's a script that is outside the maintenance of yum update, as are the files that it needs.
21:26:50 <pwhalen> 3.7 will not boot at all without dtb
21:27:13 <jonmasters> bconoboy: indeed so, we are shipping something that works. To upgrade it requires manual steps anyway
21:27:19 <jonmasters> bconoboy: therefore, I agree, this is not a blocker
21:27:19 <dmarlin> when does f18 plan to switch to kernel-3.7
21:27:29 <jonmasters> dmarlin: it's zero day, immediately upon release
21:27:32 <jonmasters> dmarlin: (so now)
21:27:45 <j_dulaney> f18 is already on 3.7
21:27:57 <j_dulaney> Has been for a while
21:27:58 <dmarlin> so will we release with 3.7 ?
21:28:05 <jonmasters> dmarlin: yes, I know this is somewhat contrived, and we could just ship 3.7, but PA did not do that and we are trying to make a case that we are ready to be just like them
21:28:08 <dmarlin> (is 3.6 even an issue)
21:28:13 <bconoboy> dmarlin: evidently we're going to release with 3.6
21:28:22 <dmarlin> :(
21:28:49 <jonmasters> however, in this case (of vexpress) it's actually a good thing :)
21:29:00 <jonmasters> because vexpress works, and an upgrade to 3.7 requires manual steps
21:29:16 <jonmasters> #action bconoboy to modify vexpress script prior to GA allowing for dtb to be specified on 3.7 kernels
21:29:32 <pwhalen> right, not sure how many ever go to the point of upgrading the kernel, as you have to copy it out of the image
21:29:37 <dmarlin> just thinking that supporting 3.6 and 3.7 makes more work for us on every platform
21:29:38 <jonmasters> #info we will include appropriate instructions or dtb updates with 3.7 to get vexpress working with X
21:29:42 <jonmasters> #undo
21:29:42 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x9dcafd0>
21:29:44 <jonmasters> #info we will include appropriate instructions or dtb updates with 3.7 to get vexpress working with Xorg
21:29:53 <jonmasters> #undo
21:29:53 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x1d07a950>
21:30:11 <jonmasters> #info we will include appropriate instructions or dtb updates with subsequent 3.7-based kernels in F18 updates to get vexpress working with Xorg
21:30:51 <seano> by shipping the 3.6 kernel we at least have a reversion path if something else bombs in 3.7 that we haven't found. ;)
21:30:52 <jonmasters> ok, so pwhalen refresh us on what hardware is working/not working?
21:31:09 <jonmasters> pwhalen: highbank works, vexpress works, omap works, tegra works?
21:31:28 <pwhalen> everything else is working, trimslice required the dtb in 3.7 and uboot upgrade
21:31:47 <jonmasters> pwhalen: make sure the release notes mention a new uboot is required for trimslice
21:31:49 <pwhalen> I didn't get a chance to verify the new kernel on highbank
21:31:54 <pwhalen> will do
21:32:00 <jonmasters> can you ping mlangsdorf to do that?
21:32:02 <ctyler> Q: The js scratch build is working ok, are we incorporating that into final? (It unbreaks usb wifi at least on the Panda)
21:32:09 <jonmasters> also, did anyone test kirkwood?
21:32:13 <pwhalen> I'll test the highbank kernel this evening
21:32:24 <pwhalen> I did, kernel worked on the Guruplug
21:32:31 <jonmasters> pwhalen: outstanding
21:32:32 <ctyler> whoops, s/Panda/Pi/
21:32:47 <jonmasters> ctyler: are you sure? How did it unbreak wifi? What was the dep?
21:32:58 <pwhalen> #link http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing#kernel-3.7.4-202.fc18
21:33:20 <bconoboy> #action pwhalen to add trimslice uboot upgrade requirement to release notes
21:33:24 <pwhalen> I made sure x works on the panda, just have not filled it out
21:33:32 <jonmasters> ctyler: and I think unless we find the js build fixes something else it just goes out as an update
21:33:44 * masta notes trimslice works without new u-boot is using appended dtb
21:34:09 <masta> ^^ contingency for users unable or unwilling to firmware update ^^
21:34:15 <jonmasters> the js build does not fix pkexec or PackageKit or that stuff - this was false information from somewhere and dennis actually checked the deps earlier. We should have done that before.
21:34:20 <pwhalen> masta, good data point, I have not tried anything appending dtb's
21:34:22 <ctyler> jonmasters: agreene has been tracking down a bug with the Pi wifi, and found that it was a service startup issue (dbus activation I think). He tested today that the scratch js build fixes the wifi issue.
21:34:40 <jonmasters> pwhalen: we won't support appending dtbs
21:35:07 <pwhalen> right, why I didn't try, but good to know
21:35:08 <masta> jonmasters: I sorta think we shoudl default to appended dtb's for a while, then switch over
21:35:13 <jonmasters> #info dgilmore is looking at a new U-Boot image format that allows multiple kernels to be combined with boot options and chosen at boot time. For F19. But a useful data point here.
21:35:43 <pwhalen> the last point is the uboot upgrade on the trimslice also reduces the ram to 512, in uboot and linux
21:35:48 <jonmasters> masta: I disagree, but I see your point. In appending dtbs we are encouraging the notion that they are provided by the kernel, which they should not be
21:36:12 <jonmasters> pwhalen: please make sure there is a release note on that as part of the upgrade instructions, as well as a BZ on it
21:36:16 <masta> jonmasters: agreed, but pragmaticly the suppor tmatix looks better even though it's doing it wrong
21:36:34 <masta> doing it right is a bit subjective
21:36:42 <pwhalen> jonmasters, will do
21:36:48 <jonmasters> masta: respectfully, though, using separate dtbs is known to work and we have a plan. We should stick to the agreed plan rather than redebate it
21:37:04 * masta nods
21:37:10 <jonmasters> thanks :)
21:37:14 <dgilmore> pwhalen: if uboot only says there is 512mb thats a uboot bug and the kernel is reporting what its told
21:37:28 <dmarlin> jonmasters: what is the new U-Boot image format?
21:37:31 <jonmasters> that is not to say we cannot have instructions or info on using appended dtbs for those who want hacks and options
21:37:43 <dgilmore> dmarlin: uImage.FIT
21:37:50 <dmarlin> dgilmore: thanks
21:37:54 <dgilmore> dmarlin: look in the docs of uboot source
21:38:02 <pwhalen> dgilmore, right, just noting
21:38:03 <jonmasters> dgilmore: can probably hack around that in dtb. I'll look into it, but we need an open BZ and this is not a release blocking priority
21:38:46 <jonmasters> I suspect the dtb is providing the wrong memory information to the kernel since that is where the kernel gets that info
21:39:01 <jonmasters> U-Boot generally only updates the "chosen" property in the dtb
21:39:04 <seano> i suspect that as well..
21:39:26 <jonmasters> I can look at it...let's get an open BZ and have it tracked somewhere and Paul can poke me next week
21:39:57 <jonmasters> (which is excellent because I will be rushing out the door to the airport right then)
21:40:13 <pwhalen> that was all the blockers..
21:40:35 <jonmasters> next! :)
21:40:36 <seano> So what is the timeline for the rc1 candidate?
21:40:38 <ctyler> Wait!
21:40:48 * jsmith freezes
21:40:50 <jonmasters> oh it's time for Pi ;)
21:40:59 <seano> pie! :)
21:40:59 <ctyler> What are we doing with the js bit? Is it blocking the packagekit stuff?
21:41:26 <ctyler> s/blocking/breaking/
21:41:45 <jonmasters> ctyler: dgilmore checked the deps. The js stuff is a red herring. Unless it's proven to be an issue with one of these blockers, per what I said above, we will not ship the updated js in the final
21:42:02 <ctyler> Can we get a zeroday update then?
21:42:07 <jonmasters> since Pi is a remix anyway, if it needs a newer version, it can ship one
21:42:15 <jonmasters> I thought that was the plan?
21:42:36 <bconoboy> that is the plan
21:42:38 <ctyler> Oh, we will :-)  but I think this affects at least usb wifi on other v5 platforms.
21:42:41 <jonmasters> dgilmore: there's going to be an F18 js update either way, right
21:42:58 <jonmasters> ctyler: how? I asked above about that - can you tell us what the dep is?
21:43:06 <jonmasters> ctyler: is NetworkManager somehow depending upon js?
21:43:17 <ctyler> I believe so, agreene has the gory details.
21:43:27 <jonmasters> I would like to have those provided :)
21:43:40 <jonmasters> FYI I have an F18 guruplug booting and using a USB wifi dongle
21:43:46 <ctyler> (And he's not on atm, should be back in a short while)
21:43:57 <jonmasters> ok, let's ask him to mail the list with specifics
21:44:10 <ctyler> Well, that's good. Maybe it's just certain wifi configurations.
21:44:14 <jonmasters> and this is not an F18 blocker as it can be fixed in an update that can be pulled into the Pi remix
21:44:19 <seano> I thought wifi was built-in to all guruplugs?
21:44:29 <ctyler> seano: it is
21:45:12 <pwhalen> #topic 3) FUDCon Recap
21:45:29 <jonmasters> seano: I use a USB dongle for various reasons (mostly for test)
21:45:53 <jonmasters> #action jonmasters to send out photos of the whiteboard from 2112 along with links to the youtube videos
21:46:10 <jsmith> The wiki page from the ARM hackfest at FUDCon is located at https://fedoraproject.org/wiki/Architectures/ARM/Meetings/FUDCon_Lawrence_2013
21:46:27 <jonmasters> #info specific meeting required to ponder all FUDCon actions and ensure we've noted things down, quickly. Perhaps VFAD on Friday or Monday to handle this
21:46:27 <jsmith> That contains a lot of the process/policy discussion notes
21:46:47 <bconoboy> #link FUDCon Lawrence day 1 video http://www.youtube.com/watch?v=xkVb7X6YO4I
21:46:54 <jonmasters> thanks bconoboy
21:48:03 <pwhalen> I'm good with a vfad either day, any preferences?
21:48:23 <ctyler> jonmasters: Why do we need a meeting on this?
21:48:25 <bconoboy> #info We are moving armv5 and armv7 builds to PHX on 96 Calxeda Highbank quad core systems
21:48:48 <masta> did the new hardware arrive ?
21:48:59 <bconoboy> #info Move date will be shortly after F18 ARM goes final
21:49:00 <jonmasters> ctyler: because we need to go over every item individually and make sure we've got wiki pages setup, BZs filed, everything has some actual movement
21:49:05 <bconoboy> new hardware is in transit right now
21:50:09 <pwhalen> awesome, any other key points we wanted to recap here, or shall we wait to have a meeting on it ?
21:50:12 <ctyler> jonmasters: right, but that's the normal work of this group, the current priorities
21:50:38 <bconoboy> #link We talked about where we are wrt secondary architecture promotion requirements (https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements)
21:51:38 <bconoboy> #info Seneca agreed to start producing tarballs of Fedora ARM release filesystems for remix purposes
21:52:00 <bconoboy> (right now we only ship filesystem images)
21:52:24 <ctyler> #action oatley to produce tarballs of Fedora ARM release filesystems for remix / new-platform-bringup purposes
21:52:28 <bconoboy> ctyler: When will that start? Will you make one for arm beta?
21:52:34 <dmarlin> bconoboy: produce using the livemedia-modifier script?
21:52:47 <ctyler> oatley: ?
21:52:51 <jonmasters> ctyler: I'm concerned that we promised we'd get a page of low hanging fruit setup, we promised to start wiki docs, we said lots of other good things and we should sit down asap and make sure it's all properly written up before we miss-remember stuff, and that things are started
21:52:59 <bconoboy> dmarlin: believe so- fossjon mentioned he had a script, assume that is the one
21:53:00 <pwhalen> bconoboy, oatley created one and put it up on scotland
21:53:07 <dmarlin> bconoboy: excellent!
21:53:23 <ctyler> jonmasters: ok
21:53:24 <pwhalen> #link http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta/
21:53:30 <bconoboy> jonmasters: enumerate here, it'll go in the logs and we'll catch anythign we missed in next week's Item 0: actions from last wek
21:53:40 <pwhalen> dmarlin, yes it was done with the modifier
21:53:48 <fossjon> i have the livemedia-modifier script to help produces tailored images and i also almost have the fedora-arm-installer package in fedora 18 soon
21:53:52 <dmarlin> pwhalen: great.  thanks
21:53:59 <jonmasters> bconoboy: we're also going to have a meeting on this :)
21:54:00 <fossjon> both should help in creating/installing image files
21:54:06 <jonmasters> bconoboy: but I'm compiling a quick list, one sec
21:54:10 <bconoboy> jonmasters: we're having a meeting now. let's do it.
21:54:39 <jonmasters> bconoboy: unless you want to go off for the next couple of hours and make wiki pages and the like, we are still having a separate session to make sure they're done :)
21:54:44 <bconoboy> #info Somebody (?) will create a wiki page on the current state of fedora on various pieces of supported and unsupported hardware.  This will be a long term sustainable page.
21:54:46 <jonmasters> one sec...I'll bring up the photo
21:54:59 <bconoboy> jonmasters: Sure, we're just talking headings today.
21:55:00 <masta> fossjon: those rootfs will be very helpful for the chromebook remix =)
21:55:21 <fossjon> ya i updated the modifier package to hopefully produce the rootfs's right
21:55:38 <jonmasters> #info jonmasters to help write up some info on Linaro involvement (Al and Fu Wei to assist, along with others)
21:55:53 <bconoboy> #agreed At FUDcon we decided we would start moving the ARM content to the main fedora wiki wherever possible
21:55:55 <jonmasters> #info PA promotion plan sent out by blc. Comments and input appreciated
21:56:05 * ctyler recommends use of #action instead of #info where a person is assigned
21:56:15 <bconoboy> #agreed At FUDcon we decided we would start participating in the definition of release criteria with PA
21:56:17 <jonmasters> #info Wiki page required along with process for onboarding new contributors
21:56:26 <jonmasters> #info Board Support docs and wiki pages required
21:56:41 <jonmasters> #info documentation on hacking/atomics/ongoing weekly technical talks
21:57:01 <jonmasters> that's what I have handy
21:57:26 <bconoboy> I suggest we get on all of these topics at the moment f18-arm final is out the door.
21:57:34 <bconoboy> Or before if people have time.
21:57:43 <bconoboy> (IE, aren't working on f18 final blockers)
21:58:09 <pwhalen> agreed, I will start to tackle some of the pages likely tomorrow
21:58:59 <pwhalen> anything else for the recap here?
21:59:02 <jonmasters> bconoboy: I'd like to have a session to make sure we get these things going. How about tentatively Monday, assuming all the blockers are done?
21:59:19 <bconoboy> jonmasters: If you run it I will join
21:59:41 <jsmith> pwhalen: I started creating the "Secret Decoder Ring" outline
21:59:51 <bconoboy> jsmith: pointer?
21:59:53 <jonmasters> any more than a week after FUDCon and things will start to get hazy. We already had that with the dtb plan. If you recall, I summarized what was agreed (what we are doing) and several others miss-recalled thinking that dgilmore was not ok with shipping 3.7 dtbs in the 3.6 image
21:59:53 <jsmith> pwhalen: Current outline is at http://piratepad.net/L1jH2TLCBO
22:00:06 <jonmasters> more of that kind of miss-recollection will happen if we don't do this soon. I will run it.
22:00:08 <pwhalen> jsmith, I grabbed the doc thanks
22:00:31 <bconoboy> #action Jonmasters to run a fudcon followup meeting on Monday, january 28
22:00:34 <jsmith> Feel free to send ideas, suggestions, and written documentation to me, and I'll get it whipped up into an official Fedora doc
22:00:56 <pwhalen> jsmith, will do
22:01:11 <ctyler> jsmith: Can you send a message to the list so everyone including those who weren't at FUDCon will see it, and explain the scope of the SDR?
22:01:24 <jsmith> ctyler: Of course -- will do
22:01:26 <pwhalen> tentative time for the meeting on Monday?
22:02:13 <jonmasters> one sec
22:02:47 <jonmasters> 1pm EST
22:03:11 <pwhalen> #undo
22:03:11 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x3d915410>
22:03:35 <pwhalen> #action Jonmasters to run a fudcon followup meeting on Monday, January 28 1pm est
22:04:03 <pwhalen> #topic 4) Your topic here!
22:04:33 <pwhalen> open floor, anyone have anything else?
22:04:50 * ctyler notes that the he-likes-it-much-better 2.0 version of rootfs-resize is headed to PA updates
22:05:01 <jsmith> ctyler: Awesome :-)
22:05:57 <pwhalen> last call..
22:06:11 <pwhalen> #endmeeting