20:00:58 #startmeeting Fedora ARM weekly status meeting 20:00:58 Meeting started Wed Apr 24 20:00:58 2013 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:58 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:58 #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore 20:00:58 Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen 20:00:59 * masta looks around 20:01:03 .fas pwhalen 20:01:07 pwhalen: pwhalen 'Paul Whalen' 20:01:10 good afternoon all 20:01:13 .fas blc@ 20:01:14 bconoboy: blc '' 20:01:23 .fas jcapik 20:01:24 jcapik: jcapik 'Jaromír Cápík' 20:01:40 .fas dmarlin 20:01:41 dmarlin: dmarlin 'David A. Marlin' 20:02:10 * masta waves to all 20:02:12 .fas parasense 20:02:13 masta: parasense 'Jon Disnard' 20:03:22 #topic 0) Status of ACTION items from our previous meeting 20:03:23 #link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-04-17/fedora-meeting-1.2013-04-17-20.01.html 20:03:39 #info ahs3 will update the package scanner to better handle false positives and negatives 20:04:01 I wasnt able to touch base wil ahs3, not sure what the status is 20:04:19 #info ahs3/pbrobinson/dgilmore will write the updated directions for aarch64 patching 20:04:41 was any progress made there? 20:04:56 we seem to be missing ahs3 and pbrobinson 20:05:11 dgilmore? 20:06:55 pbrobinson, action item from the last meeting- ahs3/pbrobinson/dgilmore will write the updated directions for aarch64 patching 20:07:16 did anyone have a chance to make progress there? 20:07:43 ahs3 has made some movement 20:08:11 what do you think about https://bugzilla.redhat.com/show_bug.cgi?id=951442 ? 20:08:25 perhaps we should revisit this next week, doesnt look like ahs3 made it today 20:08:46 we should revisit also in light of the bz jcapik has posted 20:09:44 ok, anything else from last week? 20:10:03 #topic 1) Problem packages 20:10:32 python3 is fixed 20:10:53 java is fixed 20:11:07 #info python3, java are now fixed 20:11:35 potential fix for tog-pegasus (bz filed with patch) 20:11:50 dmarlin, BZ? 20:11:52 working on a new patch for mongodb 20:12:07 that needs to be reviewed upstream, I think jonmasters can assist with that as he's done it before 20:12:14 https://bugzilla.redhat.com/show_bug.cgi?id=922770 20:12:32 #info dmarlin posted potential fix for tog-pegasus - https://bugzilla.redhat.com/show_bug.cgi?id=922770 20:12:46 #info dmarlin working on a new patch for mongodb 20:13:36 pbrobinson: which needs to be reviewed upstream? 20:13:49 the tog patch 20:14:41 any others that come to mind? 20:14:42 looks like a good patch to me.... everyone should use the gcc atomics where possible 20:14:49 nope 20:15:12 #topic 2a) F19 ARM Alpha planning - Defining blocker hardware 20:15:32 anaconda 20:15:45 for problems? 20:16:20 well omap/vexpress/highbank are booting 20:16:26 that is enough for me HW wise 20:16:31 we had previously defined the Pandaboard and vexpress as our blockers.. do we want to change anything? 20:16:45 we don't have generatable images 20:16:58 that is the major blocker we need to care about 20:16:59 evidently w can make anaconda installer images but we can't make disk images 20:17:05 right, big problem there.. 20:17:32 the kernel included in TC3 did not boot for me on the Pandaboard using bootz 20:17:58 So, we can limit support to trimslice and highbank for f19 alpha or we can delay and work on disk image creation issue 20:17:58 that's not a blocker as it's never been tested before and it's too late to introduce that as a blocker 20:17:59 I just installed a highbank with TC3, other then having to select the media options, it finished without issue 20:19:37 (or we could use f18 to make the images, I guess) 20:20:27 we could 20:20:29 bconoboy: we cant do that 20:20:35 cue dgilmore ;-) 20:20:36 thats not an acceptable option 20:20:50 bconoboy: queue 20:21:01 dgilmore: Please suggest acceptable option 20:21:03 * dmarlin wonders if no images at all are more acceptable 20:21:07 but its not something that would be okay from primary 20:21:26 dmarlin: honestly for alpha yes 20:21:51 dmarlin: this is a problem that we've been discussing since before F17 20:22:12 pbrobinson: yes, and anaconda is more broken now than then 20:22:33 for primary alpha there was 2 live images we didnt ship because they didnt work 20:22:58 dgilmore: What do you think of just shipping tegra&highbank for alpha then? 20:23:11 so with no images for alpha, what do _we_ ship? 20:23:12 bconoboy: if thats what we can get working then sure 20:23:17 (Or anything else that can tftpboot and install) 20:23:18 those are situations where an installer image would apply? 20:23:20 dmarlin: and install tree 20:23:24 an 20:23:28 dgilmore: I'm good with htat 20:23:31 that 20:23:55 I'm also good with just shipping installer images for f19 alpha. 20:24:06 It means dropping versatile express though. 20:24:21 bconoboy: not necessarily 20:24:37 no? 20:24:48 no reason you couldnt do a install in qemu 20:24:59 bconoboy: we need images with multiplatform kernel 20:25:06 we agreed on this a while ago 20:25:27 and it was even discussed dropping tegra to remix because it wasn't MP kernel 20:25:31 pbrobinson: we may be able to make them with qemu and anaconda 20:25:59 yes we did talk about going MP only 20:26:25 yes, MP only with two images one with vfat and one without 20:26:47 and for alpha we were only planning minimal install and maybe xfce 20:27:02 pbrobinson: Er, are you saying "I do not support skipping pre-built images in f19 arm alpha"? 20:28:24 if we don't have a prebuild image how are people going to easily dd an image for testing? 20:28:32 or am i missing something 20:28:48 pbrobinson: They'll only be able to test installing with anaconda 20:29:19 so basically on highbank only then? 20:30:08 pbrobinson: Anything that can run anaconda and load images via tftp. That'd also include tegra. Maybe omap. 20:30:34 omap with a special image on SD card? 20:30:54 installing over the top of that image? 20:30:57 yeah, I'm thinking an omap image that just has the uboot pieces on it 20:31:14 really though that's mostly theoretical 20:32:00 it's a large change when we should already have alpha done with not a lot of stuff that's easily testible for a lot of people 20:32:03 bconoboy: installing is not limited only to pxe booting 20:32:04 hopefully by beta we'll have the image creation problem solved and be able to make some pre-canned stuff too. 20:32:32 dgilmore: technically I suppose any host which can *somehow* load that installer and has a network connection is viable 20:32:39 its possible we could use anaconda and qemu to make some images 20:32:39 bconoboy: "hopefully by beta" is a term I've heard pretty much every release cycle 20:33:03 and every release cycle it slips 20:33:11 bconoboy: ive been playing around with boot.scr kernel and initramfs on trimslice to make a bootable installer sdcard 20:33:22 dgilmore: that's great 20:34:19 bconoboy: until we teach anaconda to do all the bootloader configs we will have to use a kickstart 20:34:27 but it should be possibel to install 20:34:49 pbrobinson: Am open to alternate suggestions- right now we just don't have the ability to make canned images due to one or more bug in anaconda. 20:35:18 bconoboy: we cant make canned images using livemedia-creator 20:35:32 right. 20:35:33 bconoboy: there are other ways to do it 20:35:45 so lets explore those options 20:35:54 dgilmore: using fedora 19 tools? 20:35:59 oh yes? please explore aloud! 20:37:01 dmarlin: yes 20:37:47 dgilmore: explain? 20:38:05 bconoboy: i have twice in this conversation already 20:39:35 dgilmore: You're suggesting we do installations by hand then ship the result? 20:39:45 bconoboy: no 20:40:19 bconoboy: im suggesting we do a install using a kickstart 20:40:31 but using qemu to do it 20:40:38 and ship the resulting disk image 20:40:45 not tota;;y ideal 20:40:57 even a kickstart requires manual intervention, that's one of the issues with anaconda 20:41:06 bconoboy: right 20:41:16 which is why we would have to do it this way 20:41:28 bconoboy: not saying its ideal 20:41:36 but its a way to do it 20:41:37 dgilmore: you will be doing this? or somebody else? 20:41:45 bconoboy: it would be I 20:41:47 (I don't oppose, I just want to know what the plan is) 20:41:58 dgilmore: Okay- when? and what do you need before you can do so? 20:42:00 bconoboy: going to look into it 20:42:11 if it can work, I think thats certainly the better option than no images 20:42:13 bconoboy: its something i just thought of 20:42:24 so its mostly jumbled thoughts 20:42:54 #action dgilmore to experiment with making images via anaconda to work around current lmc/anaconda issues 20:43:08 shall we revisit this next week? 20:43:17 sure 20:43:18 agreed, next? We're running short on time 20:43:53 #topic 2b) F19 ARM Alpha planning - Release Criteria 20:45:23 pwhalen: pointed to release criteria today? 20:45:36 #link https://fedoraproject.org/wiki/Architectures/ARM/F19_Alpha_Release_Criteria 20:46:03 is this a straight copy of F18? 20:46:10 of f19 PA 20:46:18 ah, cool 20:46:32 any changes needed? 20:47:00 which is what we should follow, I identified some of our issues which were discussed in a QA meeting, however changes wouldnt be considered prior to primary 20:47:31 #info Release criteria are straight from F19 PA 20:47:34 release blocking desktops, installer bits 20:48:06 Okay, we have it in the official record, we can move on :-) 20:48:18 #topic 3a) Aarch64 bootstrap - patching status 20:48:51 we may need ahs3 here for this one, does anyone have an update? 20:49:07 there was an update from the rpm maintainer today 20:49:27 we need to review that as it may reduce a whole bunch of bugs that we no longer have to deal with 20:49:50 today for me was hell so I didn't get a chance to even try and sync with ahs3 about this 20:50:24 we're going to try the redhat-rpm-macros update in stage4 and see what happens 20:50:38 er redhat-rpm-config, rather 20:50:54 a new redhat-rpm-config has a patch I was carrying in the bootstrap repo + a patch to handle the config.sub/config.guess problem through rpm 20:51:16 I am building that now and it should land in the stage4 repo soon 20:51:21 * jsmith is assuming we're talking about bug https://bugzilla.redhat.com/show_bug.cgi?id=951442 20:51:24 cool so that should help out with a bunch of them 20:52:07 #link config.guess/sub patches might be rendered moot by https://bugzilla.redhat.com/show_bug.cgi?id=951442 20:52:27 jsmith: and https://bugzilla.redhat.com/show_bug.cgi?id=909788 20:52:59 #link Also https://bugzilla.redhat.com/show_bug.cgi?id=909788 20:53:05 pwhalen: Probably clear to move on 20:53:17 3b) Aarch64 bootstrap - Running the Foundation Model 20:53:27 #link https://fedoraproject.org/wiki/Architectures/ARM/AArch64/QuickStart 20:53:49 People who want to contribute to the aarch64 stage4 bootstrap should follow the directions on that page 20:54:01 All you need is an x86_64 host with some CPU power to spare 20:54:03 #info Please donate your spare CPU cycles to the bootstrap 20:54:27 If you've been holding off on getting involved now is the time to get started 20:55:07 Currently we're rebuilding the rpms from stage3 20:55:16 Which will be largely done really soon. 20:55:22 (Hours, maybe days) 20:55:34 After that we'll be adding additional srpms to the queue 20:55:48 but you can try building whatever you like 20:55:54 Cool :-) 20:55:55 just use mock to do it :-) 20:56:20 I'll also be updating the quickstart with a new rootfs/image.. takes about 10 minutes to get everything set up 20:56:25 Anyway, *everything* you need to get started is on that page. If you have any questions ask in #fedora-arm 20:56:41 It's very easy to get everything running (Even I could do it) 20:56:59 next? 20:57:05 y 20:57:07 #topic 4) Kernel Status update 20:57:48 #link http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing/Fedora_19#kernel-3.9.0-0.rc8.git0.1.fc19 20:58:48 yo 20:58:59 so kernel is starting to look quite reasonable 20:59:31 omap/tegra are looking much better than they were a week ago... they're almost even stable 21:00:06 with dgilmore's assistance we might even have mvebu working RSN 21:00:12 pwhalen: any issues when testing beyond basic "it boots" ? 21:00:32 so now we start to spit polish it 21:00:48 kernel-3.9.0-0.rc7.git3.1.fc19 worked well on the Panda, had issues with kernel-3.9.0-0.rc8.git0.1.fc19 finding the rootfs.. had to update uboot for bootz support due to multiplatform 21:00:49 I'm very glad that the 3.9 kernel will be the release kernel for F-19 21:00:54 tegra has been pretty stable as of 3.9-rc8, including high network IO 21:01:06 the highbank will reliably crash when running most 3.9 kernels 21:01:36 pwhalen: should that be in the notes? (on the wiki)? 21:01:46 was gathering fpastes now for it 21:01:57 pwhalen: way ahead of me, as usual 21:01:58 :) 21:02:08 he's a fresh highbank - http://fpaste.org/DULO/ 21:02:11 well calxeda can put some attention on that as they're the specialists 21:02:41 pbrobinson, email coming, just wanted to reproduce on another node, try the dtb from the kernel 21:02:50 perfect 21:03:07 it looks like cpuidle is pretty hosed in 3.9 on ARM so I've currently just disabled it 21:03:24 I'm starting working with upstream to get further details 21:03:39 and provide further details 21:04:15 next up will be looking closer at mvebu and beagle 21:04:22 following that will be imx 21:04:26 all : please test new kernels when you see them in koji, add your results to the wiki. :) 21:04:34 and that will likely close out 3.9 nicely 21:05:08 cool, thanks for the update Peter, anything else? 21:05:16 not from me 21:05:29 #topic 5) Open Floor 21:05:42 anything else for today folks? 21:06:49 ok, thanks everyone! 21:06:52 #endmeeting