21:01:19 #startmeeting Fedora ARM weekly status meeting 21:01:19 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:01:19 #chair pwhalen jonmasters bconoboy ctyler pbrobinson 21:01:19 Current chairs: bconoboy ctyler jonmasters pbrobinson pwhalen 21:01:26 .fas jonmasters 21:01:27 .fas blc@ 21:01:27 jonmasters: jcm 'Jon Masters' 21:01:27 good afternoon all 21:01:28 .fas jcapik 21:01:29 hey! 21:01:30 bconoboy: blc '' 21:01:32 .fas pwhalen 21:01:33 jcapik: jcapik 'Jaromír Cápík' 21:01:36 .fas ahs3 21:01:36 pwhalen: pwhalen 'Paul Whalen' 21:01:39 ahs3: ahs3 'Al Stone' 21:02:05 #topic 0) Status of ACTION items from previous meeting 21:02:36 checking our action items, most have been closed - 1. Highbank kernel, Fudcon items, 21:02:49 remaining is yumex, and is being worked on 21:03:05 #link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-16/fedora-meeting-1.2013-01-16-21.00.html 21:03:15 .fas chris@tylers.info 21:03:15 ctyler: ctyler 'Chris Tyler' 21:03:15 * ctyler waves 21:03:27 packages have been signed and ready to go for F18, thanks dgilmore 21:03:28 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 right 21:04:20 * jonmasters has the ball on pkexec/PackageKit. I will send out an update in a few hours 21:04:28 I just got back from a needed 1hr run :) 21:04:30 anything else to add on the actions items? 21:04:47 #action jonmasters taking over PackageKit/pkexec issue, will have update in a few hours 21:05:04 pwhalen: that's it 21:05:15 jonmasters: let me know how that goes, looks like brk() does something bad on arm 21:05:33 so we'll be able to do an f18-arm compose then this week hopefully? 21:05:43 #topic 1) Problem packages 21:06:20 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 llvm- we need this fixed in f19 21:06:51 me is going to poke at ltrace once polkit is handled 21:07:57 masta: just tell me one thing, did you poke using v5 or v7? 21:08:05 v7 21:08:12 #info llvm needs attention in F19 21:08:30 Is the llvm issue just the triplet thing? 21:08:36 yes 21:08:36 likely. 21:08:54 it's going to get worse because things are starting to require llvm 21:09:14 I thought triplet thing can be a patch in the Makefile to hardcode one in teh case of arm* 21:09:21 there is a triplet.cpp file that defines those.. so it shouldnt be terrible. 21:09:24 #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 any other packages? I saw some mention in channel earlier 21:09:44 #action masta to look into ltrace 21:10:06 jonmasters: mongodb? 21:10:06 Do we have an active list of broken, or excluded packages? 21:10:10 (going forward, anyone proposing whacky triplets and weirdness needs to be stomped on) 21:10:29 #action jonmasters to post patch for mongodb after F18 fixes, before Monday 21:10:47 did you get the atomics sorted out? 21:11:01 #info pwhalen to check on interim actions prior to next week's meeting - e.g. Monday 21:11:26 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 pwhalen: I think that's it- creating The Big List is probably a fudcon discussion point 21:12:28 jonmasters :) 21:12:43 Oh yea, we need The Big List 21:12:46 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 #action jonmasters to send photos of whiteboard out 21:12:55 #undo 21:12:55 Removing item from minutes: 21:13:16 /dereference 0x17f96050 21:13:58 moving on? 21:14:01 * jonmasters has photos from FUDCon uploading to flickr, including the photos of the whiteboard 21:14:05 I will send those out to the list 21:14:12 pwhalen: we'll come back to FUDCon 21:14:17 #topic 2) F18 final - update on remaining blockers 21:14:51 im guessing the white board was more of a blackboard by the end.. :) 21:15:12 of our blockers, we have the eclipse build pending. 21:15:29 the kernel-dtb subpackage is being worked on by dgilmore, not sure if he has an update 21:15:35 has the 3.7 kernel booted on everything yet? 21:16:04 bconoboy, I boot tested the panda, trimslice, vexpress (-x), and the Guru 21:16:09 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 all worked as expected 21:16:27 ^^^ above is based on phone call with dgilmore earlier 21:17:32 #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 jonmasters: Any thoughts on why versatile express + x doesn't work? 21:18:05 #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 bconoboy: I have not looked yet. Anyone got a syndrome description? 21:18:24 pwhalen: what happens with vexpress and x? 21:18:41 Is there any special reason we're not making the F18 final use 3.7 out of the box? 21:18:57 only a black screen when booted, no output 21:19:48 bconoboy: consistency with PA 21:20:16 bconoboy: we're about to propose going to primary, we can't be doing things that look crazy 21:20:33 pwhalen is it my scripts fauly for vexpress+x? 21:20:38 fault* 21:20:41 jonmasters: 3.7 dtbs with 3.6 kernel also looks crazy :-) 21:20:56 on vexpress I have tried a few kernels, to verify that the change to virtio had no impact, the same results 21:20:58 perhaps not as crazy though 21:21:00 bconoboy: s/crazy/more crazy/ 21:21:04 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 used the dtb from 3.7 and 3.6 21:21:28 Well we -could- defend it by saying it is a lot harder to do a kernel upgrade. 21:21:31 pwhalen: what happens? 21:21:45 nothing, no output at all 21:21:45 pwhalen: I can look at it, after PackageKit, but I need to know what happens 21:21:52 only a black screen when booted, no output 21:21:55 pwhalen: with the 3.7 kernel only? 21:22:02 jonmasters: I think it isn't attaching to the right console.. 21:22:07 and 3.6 21:22:08 pwhalen: did you boot with any debug options? 21:22:17 pwhalen: what host qemu version? 21:22:31 how did we only find this now? 21:22:47 its when using a dtb, without the dtb it works fine 21:22:53 ah ok 21:23:00 pwhalen: is this a regression? 21:23:11 pwhalen: without a dtb on 3.7 it falls over? 21:23:21 this is qemu-system-arm-1.2.2-1.fc18 21:23:22 pwhalen: I assume it doesn't boot on 3.7 without a dtb? 21:23:40 right, 3.6 will boot into x without the dtb, when including one it will not 21:23:55 ok and 3.7 will not boot regardless? 21:23:55 and 3.7 will not boot without a dtb 21:23:59 oh ok 21:24:07 for x, boots to serial fine 21:24:20 so we have two options. Tomorrow, I will look at making 3.6 boot with the dtb 21:24:38 however, otherwise we will modify the scripts we ship with vexpress images to only apply the dtb on 3.7+ kernels 21:24:55 jonmasters: I'm updating the boot script to make the dtb an optional parameter. 21:25:09 bconoboy: indeed, I saw that :) but that's not quite what I said :) 21:25:11 is there an ignore dtb flag? 21:25:23 seano: there is either a dtb parameter to qemu, or not 21:25:36 jonmasters: you want it to force the use of dtb with 3.7? 21:25:49 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 bconoboy: it is my understanding that the kernel will not boot on 3.7 without a dtb 21:26:24 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 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 3.7 will not boot at all without dtb 21:27:13 bconoboy: indeed so, we are shipping something that works. To upgrade it requires manual steps anyway 21:27:19 bconoboy: therefore, I agree, this is not a blocker 21:27:19 when does f18 plan to switch to kernel-3.7 21:27:29 dmarlin: it's zero day, immediately upon release 21:27:32 dmarlin: (so now) 21:27:45 f18 is already on 3.7 21:27:57 Has been for a while 21:27:58 so will we release with 3.7 ? 21:28:05 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 (is 3.6 even an issue) 21:28:13 dmarlin: evidently we're going to release with 3.6 21:28:22 :( 21:28:49 however, in this case (of vexpress) it's actually a good thing :) 21:29:00 because vexpress works, and an upgrade to 3.7 requires manual steps 21:29:16 #action bconoboy to modify vexpress script prior to GA allowing for dtb to be specified on 3.7 kernels 21:29:32 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 just thinking that supporting 3.6 and 3.7 makes more work for us on every platform 21:29:38 #info we will include appropriate instructions or dtb updates with 3.7 to get vexpress working with X 21:29:42 #undo 21:29:42 Removing item from minutes: 21:29:44 #info we will include appropriate instructions or dtb updates with 3.7 to get vexpress working with Xorg 21:29:53 #undo 21:29:53 Removing item from minutes: 21:30:11 #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 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 ok, so pwhalen refresh us on what hardware is working/not working? 21:31:09 pwhalen: highbank works, vexpress works, omap works, tegra works? 21:31:28 everything else is working, trimslice required the dtb in 3.7 and uboot upgrade 21:31:47 pwhalen: make sure the release notes mention a new uboot is required for trimslice 21:31:49 I didn't get a chance to verify the new kernel on highbank 21:31:54 will do 21:32:00 can you ping mlangsdorf to do that? 21:32:02 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 also, did anyone test kirkwood? 21:32:13 I'll test the highbank kernel this evening 21:32:24 I did, kernel worked on the Guruplug 21:32:31 pwhalen: outstanding 21:32:32 whoops, s/Panda/Pi/ 21:32:47 ctyler: are you sure? How did it unbreak wifi? What was the dep? 21:32:58 #link http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing#kernel-3.7.4-202.fc18 21:33:20 #action pwhalen to add trimslice uboot upgrade requirement to release notes 21:33:24 I made sure x works on the panda, just have not filled it out 21:33:32 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 ^^ contingency for users unable or unwilling to firmware update ^^ 21:34:15 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 masta, good data point, I have not tried anything appending dtb's 21:34:22 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 pwhalen: we won't support appending dtbs 21:35:07 right, why I didn't try, but good to know 21:35:08 jonmasters: I sorta think we shoudl default to appended dtb's for a while, then switch over 21:35:13 #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 the last point is the uboot upgrade on the trimslice also reduces the ram to 512, in uboot and linux 21:35:48 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 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 jonmasters: agreed, but pragmaticly the suppor tmatix looks better even though it's doing it wrong 21:36:34 doing it right is a bit subjective 21:36:42 jonmasters, will do 21:36:48 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 thanks :) 21:37:14 pwhalen: if uboot only says there is 512mb thats a uboot bug and the kernel is reporting what its told 21:37:28 jonmasters: what is the new U-Boot image format? 21:37:31 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 dmarlin: uImage.FIT 21:37:50 dgilmore: thanks 21:37:54 dmarlin: look in the docs of uboot source 21:38:02 dgilmore, right, just noting 21:38:03 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 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 U-Boot generally only updates the "chosen" property in the dtb 21:39:04 i suspect that as well.. 21:39:26 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 (which is excellent because I will be rushing out the door to the airport right then) 21:40:13 that was all the blockers.. 21:40:35 next! :) 21:40:36 So what is the timeline for the rc1 candidate? 21:40:38 Wait! 21:40:48 * jsmith freezes 21:40:50 oh it's time for Pi ;) 21:40:59 pie! :) 21:40:59 What are we doing with the js bit? Is it blocking the packagekit stuff? 21:41:26 s/blocking/breaking/ 21:41:45 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 Can we get a zeroday update then? 21:42:07 since Pi is a remix anyway, if it needs a newer version, it can ship one 21:42:15 I thought that was the plan? 21:42:36 that is the plan 21:42:38 Oh, we will :-) but I think this affects at least usb wifi on other v5 platforms. 21:42:41 dgilmore: there's going to be an F18 js update either way, right 21:42:58 ctyler: how? I asked above about that - can you tell us what the dep is? 21:43:06 ctyler: is NetworkManager somehow depending upon js? 21:43:17 I believe so, agreene has the gory details. 21:43:27 I would like to have those provided :) 21:43:40 FYI I have an F18 guruplug booting and using a USB wifi dongle 21:43:46 (And he's not on atm, should be back in a short while) 21:43:57 ok, let's ask him to mail the list with specifics 21:44:10 Well, that's good. Maybe it's just certain wifi configurations. 21:44:14 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 I thought wifi was built-in to all guruplugs? 21:44:29 seano: it is 21:45:12 #topic 3) FUDCon Recap 21:45:29 seano: I use a USB dongle for various reasons (mostly for test) 21:45:53 #action jonmasters to send out photos of the whiteboard from 2112 along with links to the youtube videos 21:46:10 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 #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 That contains a lot of the process/policy discussion notes 21:46:47 #link FUDCon Lawrence day 1 video http://www.youtube.com/watch?v=xkVb7X6YO4I 21:46:54 thanks bconoboy 21:48:03 I'm good with a vfad either day, any preferences? 21:48:23 jonmasters: Why do we need a meeting on this? 21:48:25 #info We are moving armv5 and armv7 builds to PHX on 96 Calxeda Highbank quad core systems 21:48:48 did the new hardware arrive ? 21:48:59 #info Move date will be shortly after F18 ARM goes final 21:49:00 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 new hardware is in transit right now 21:50:09 awesome, any other key points we wanted to recap here, or shall we wait to have a meeting on it ? 21:50:12 jonmasters: right, but that's the normal work of this group, the current priorities 21:50:38 #link We talked about where we are wrt secondary architecture promotion requirements (https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements) 21:51:38 #info Seneca agreed to start producing tarballs of Fedora ARM release filesystems for remix purposes 21:52:00 (right now we only ship filesystem images) 21:52:24 #action oatley to produce tarballs of Fedora ARM release filesystems for remix / new-platform-bringup purposes 21:52:28 ctyler: When will that start? Will you make one for arm beta? 21:52:34 bconoboy: produce using the livemedia-modifier script? 21:52:47 oatley: ? 21:52:51 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 dmarlin: believe so- fossjon mentioned he had a script, assume that is the one 21:53:00 bconoboy, oatley created one and put it up on scotland 21:53:07 bconoboy: excellent! 21:53:23 jonmasters: ok 21:53:24 #link http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta/ 21:53:30 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 dmarlin, yes it was done with the modifier 21:53:48 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 pwhalen: great. thanks 21:53:59 bconoboy: we're also going to have a meeting on this :) 21:54:00 both should help in creating/installing image files 21:54:06 bconoboy: but I'm compiling a quick list, one sec 21:54:10 jonmasters: we're having a meeting now. let's do it. 21:54:39 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 #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 one sec...I'll bring up the photo 21:54:59 jonmasters: Sure, we're just talking headings today. 21:55:00 fossjon: those rootfs will be very helpful for the chromebook remix =) 21:55:21 ya i updated the modifier package to hopefully produce the rootfs's right 21:55:38 #info jonmasters to help write up some info on Linaro involvement (Al and Fu Wei to assist, along with others) 21:55:53 #agreed At FUDcon we decided we would start moving the ARM content to the main fedora wiki wherever possible 21:55:55 #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 #agreed At FUDcon we decided we would start participating in the definition of release criteria with PA 21:56:17 #info Wiki page required along with process for onboarding new contributors 21:56:26 #info Board Support docs and wiki pages required 21:56:41 #info documentation on hacking/atomics/ongoing weekly technical talks 21:57:01 that's what I have handy 21:57:26 I suggest we get on all of these topics at the moment f18-arm final is out the door. 21:57:34 Or before if people have time. 21:57:43 (IE, aren't working on f18 final blockers) 21:58:09 agreed, I will start to tackle some of the pages likely tomorrow 21:58:59 anything else for the recap here? 21:59:02 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 jonmasters: If you run it I will join 21:59:41 pwhalen: I started creating the "Secret Decoder Ring" outline 21:59:51 jsmith: pointer? 21:59:53 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 pwhalen: Current outline is at http://piratepad.net/L1jH2TLCBO 22:00:06 more of that kind of miss-recollection will happen if we don't do this soon. I will run it. 22:00:08 jsmith, I grabbed the doc thanks 22:00:31 #action Jonmasters to run a fudcon followup meeting on Monday, january 28 22:00:34 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 jsmith, will do 22:01:11 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 ctyler: Of course -- will do 22:01:26 tentative time for the meeting on Monday? 22:02:13 one sec 22:02:47 1pm EST 22:03:11 #undo 22:03:11 Removing item from minutes: 22:03:35 #action Jonmasters to run a fudcon followup meeting on Monday, January 28 1pm est 22:04:03 #topic 4) Your topic here! 22:04:33 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 ctyler: Awesome :-) 22:05:57 last call.. 22:06:11 #endmeeting