20:00:29 #startmeeting 20:00:29 Meeting started Wed Aug 15 20:00:29 2012 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:29 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:29 #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore 20:00:29 Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen 20:00:44 .fas blc@ 20:00:44 bconoboy: blc '' 20:00:50 .fas pwhalen 20:00:50 pwhalen: pwhalen 'Paul Whalen' 20:00:50 .fas jcapik 20:00:52 .fas djdelorie 20:00:53 jcapik: jcapik 'Jaromír Cápík' 20:00:54 .fas frojoe 20:00:56 djdelorie: djdelorie 'DJ Delorie' 20:00:59 Frojoe: burningfool 'Jordan Cwang' - jacwang 'Jordan Cwang' 20:01:02 * masta is here 20:01:06 .fas parasense 20:01:06 masta: parasense 'Jon Disnard' 20:01:18 .fas ctyler@ 20:01:18 ctyler: 'ctyler@' Not Found! 20:01:23 .fas ctyler 20:01:23 ctyler: ctyler 'Chris Tyler' - ctyler2621 'Christopher Tyler' 20:01:42 #topic 1a) Build status update 20:02:01 * pbrobinson is here 20:02:14 pbrobinson, how we doing on the builds? 20:02:15 @me is here 20:02:23 * agreene is here 20:02:33 .fas agreene 20:02:35 djdelorie: tag4fedora 'Tim Greene' - agreene 'Andrew Greene' 20:02:52 fine, few minor problems, mostly moving onwards and upwards 20:03:00 .fas dmarlin 20:03:00 dmarlin: dmarlin 'David A. Marlin' 20:03:12 fossjon's script suggests we're getting further away- what's the deal? 20:03:16 great 20:03:31 koji-shadow has finally managed to get itself through a full run in the last couple of days so I don't believe there should be any more mass rebuild straglers now 20:03:49 #topic 1b) packages needing attention? 20:03:53 oh i changed it to f19 20:03:56 sorry 20:04:01 i should have let the mailing list know 20:04:10 bconoboy: I don't believe we are 20:04:11 it inherits just letting everyone know 20:04:26 fossjon: Oh, so it's showing f19+f18+f17 missing? 20:05:10 i believe so 20:05:19 the twitter thing shows 96.86% 20:05:21 can you break out just f18? 20:05:24 i wasnt sure if people prefered it inheriting or not 20:05:28 I asked fossjon to add f19 to the rest of them, so we should have them all but I still only see two in the email 20:05:45 so we should have f17-updates f18 f19 20:05:56 pbrobinson which ones should i set to inherit? 20:06:05 i can add back f18 20:06:36 #info koji-shadow has made it through an entire run- few minor problems remain 20:07:08 fossjon: I'd kinda like to see without any inheritance 20:07:10 fossjon: probably them all for the time being, shouldn't be hard to change 20:07:20 .fas jonmasters 20:07:21 jonmasters: jcm 'Jon Masters' 20:07:22 alright 20:07:48 #agreed fossjon to update nightly status report to track f17-updates, f18, and f19 separately 20:07:50 bconoboy: the current biggest blocker is an avahi build issue if someone has time to look at it that would be great 20:08:20 avahi appears to have failed for lack of a dependency 20:09:04 ah, yes, perl issues, I rememeber now :-/ 20:09:10 sorry, been a massively busy week 20:09:26 #info biggest blocker: avahi, caused by perl dependencies 20:09:46 pbrobinson: anything we can do to help with perl dep issues? 20:09:52 * fossjon wonders what the highest percentage of pkgs we've ever built 20:10:19 I'll have a poke at it tonight to see if I can see what's wrong with it and poke people if I need help 20:10:43 #action pbrobinson to investigate perl issues, ask for help if needed 20:11:04 any other problem packages to note? 20:11:07 thanks Peter 20:11:17 I've got the ball on llvm, we've discussed that one enough 20:11:35 (really that means clang, but llvm is the source package) 20:12:06 #agreed jonmasters is fixing llvm to support using armv7hl-redhat-linux triplet 20:12:27 it's armv7hl-redhat-linux-gnueabi per gcc 20:12:36 #undo 20:12:36 Removing item from minutes: 20:12:44 #agreed jonmasters is fixing llvm to support using armv7hl-redhat-linux-gnueabi triplet 20:12:46 pwhalen: nope, nothing further 20:12:49 #topic 2) missing mock configs for F18 20:12:51 tnx 20:13:15 dmarlin noticed we were missing mock configs for f18 20:14:08 is this normal at this stage of development? 20:14:11 mock configs need to be updated in mainline and then we pull them back 20:14:22 who does that? when? 20:14:23 ah, okay great, any timeline as to when? 20:14:34 releng usually does that 20:14:34 it's not un normal for it to happen post branch a little later, 20:14:43 * jonmasters thinks it's pretty normal not to be done yet 20:14:49 yea 20:14:58 ok 20:15:06 #topic 3) Raspberry Pi status update 20:15:07 is the absence of these configuration files causing difficulty? 20:15:10 how do we handle mock builds in the interim ? 20:15:17 #topic 2) missing mock configs for F18 20:15:54 dmarlin: copy the f17 or rawhide one and update the repo files. It's not hard 20:16:10 On the Pi Remix - we've done the builds necessary to test the v6 optimizations except for glibc. 20:16:15 ctyler: hang on 20:16:25 #info We're waiting on releng to update mock configs 20:16:26 pbrobinson: harder than 'yum update mock' on a dozen builders 20:16:36 :) 20:16:48 #info Creating an f18 mock config by hand should work at this stage 20:17:00 dmarlin: koji generates their own configs so it doesn't matter, mock is just for local stuff 20:17:17 pbrobinson: right, and I do a lot of local stuff 20:17:45 pwhalen: ok, next. 20:17:45 #topic 3) Raspberry Pi status update 20:17:54 dmarlin: I suspect dgilmore will update the mock configs pretty quickly when he resurfaces 20:18:09 dmarlin: so for builders it doesn't matter about the configs, for the local stuff it takes 1min to copy and update your local file 20:18:49 ctyler: okay, pi status? 20:18:52 Ok, on the Pi Remix, we have just glibc to go before we can test armv6 builds. Hoping to get that done this week. 20:19:10 The rest of the packages in the remix image subset are done for v6 hard and soft. 20:19:16 #info Seneca are working on armv6 builds. glibc is outstanding. Should be done this week 20:19:28 #info Remainder of v6 builds are complete 20:19:35 #undo 20:19:35 Removing item from minutes: 20:19:40 #info Remainder of v6 hard float builds are complete 20:19:50 dmarlin: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=89690 it was done on Aug 10th on mainline, and imported into the arm.koji config on the same day actually. Case closed. 20:19:54 ctyler: Has softfp remix development stoppe? 20:19:55 bconoboy: and softfp w/ vfp support too 20:19:58 er stopped? 20:20:24 * pbrobinson wonders how you can build all the rest of the packages for v6 properly without a proper glibc? 20:20:43 dynamic linking? 20:20:51 "close enough" ABI 20:20:56 * dmarlin would like to know the performance difference between v5 an v6, when the images are complete 20:20:59 We've got what I think is a pretty solid image that's armv5tel, next thing we really want to do is see what the v6 builds do 20:21:08 ive been waiting for dgilmore to get back to ask him in more detail but i cant right now 20:21:19 #info The armv5tel f17 raspberry py remix image is "pretty solid" 20:21:31 i would like to verify if ive been building the pkgs correctly so far 20:21:43 There are some more firstboot pieces that are just done, we'll put out an armv5tel compose with those pieces tomorrow 20:21:46 the thing that made the hardfp bootstrap difficult is that the ABIs were not "close enough" 20:21:58 fossjon, perhaps email dgilmore, he is working while down under, afaik 20:22:03 fossjon: Do you specifically need dgilmore's feedback or could somebody else answer your question? 20:22:19 fossjon: feel free to ask me other others so it doesn't hold you up 20:22:31 someone who knows enough about mock/rpmbuild/building one arch from scratch on a different arch 20:22:39 pbrobinson: armv6 will interoperate sufficiently with armv7hl (on a v7 box) and armv5tel (for softfp+vfp) 20:22:41 ie armv6hl on armv7hl 20:23:00 one other pi question 20:23:03 an arch thats never been defined before either 20:23:11 bconoboy: ? 20:23:16 djdelorie: they weren't close but there were other ways we could have done it. I deliberately skewed the v7 case in favor of a complete arch bootstrap to prepare for v8 20:23:18 in #fedora-arm the other day there was a request for the compose script- can we get a pointer for the minutes? 20:23:42 jonmasters: I know, I was there :-) 20:23:48 http://huttriver.proximity.on.ca/outbound/rpfrcompose16-xfce 20:24:03 #link http://huttriver.proximity.on.ca/outbound/rpfrcompose16-xfce 20:24:19 #info The above link is the compose script Seneca are using to generate Fedora 17 Raspberry Pi remix images 20:24:25 just for context. And I think what is being done with v6 is interesting for the Pi, but I don't think it'll be more broadly used because most devices are either v5 or v7 20:24:46 ctyler, anything else to note for the pi today? 20:25:03 knowing what kind of performance gains can be had from device-specific builds might be generally useful 20:25:04 what's v5 besides kirkwood? 20:25:30 and/or how fast we can spin a semi-compatible "build everything" 20:26:10 I'm hoping softfp+vfp gives sufficient gains, so we can interoperate with armv5tel and avoid a full rebuild. 20:26:16 bconoboy: well, it is mostly kirkwood at this stage (and some cheap devices in APAC) but that's a lot of older devices 20:26:32 anyway, I don't want to pretend I care a lot about v5 longevity :) because I don't 20:26:45 ctyler: how are you going to do softfp+vfp. That's mixing softfp and hardfp 20:26:58 there's a third ABI 20:26:59 pwhalen: I have a related topic when we're ready to move to open forum 20:27:14 bconoboy, ok 20:27:15 pbrobinson: soft ABI with VFP-enabled code 20:27:21 it's hardfp insns but floats are passed in integer registers, IIRC 20:27:45 right, the VFP is used, but not for passing args to a function 20:28:24 EOF on Pi for now 20:28:32 any other pi questions from anyone? 20:28:49 #topic 4) Linaro Connect - single kernel binary status update 20:28:59 #link http://www.youtube.com/watch?v=4Lpzc_dkh9E 20:29:04 I think the first thing is to remind folks...yea, that video 20:29:33 just to summarize - Goal is to provide one kernel to boot across all ARM soc's to make life easier for everyone, speed up kernel build times and to be inline with whats done on x86. 20:29:34 I've pinged a few folks and I think the main the is it's in Deepak and Arnd's court 20:29:54 but there is a need to identify any remaining work items that need looking at 20:29:57 Realistically there will still be multiple kernels, eg - LPAE & non-LPAE, single kernel for v6 & v7, and single kernel for use with v5 platforms. 20:30:19 USB host controllers are the most obvious one. I raised the need for a standard U-Boot environment too 20:30:19 an initial build was completed on single zImage after previous Linaro Connect, with it being unable to boot on any hardware 20:30:19 #info The above link is frmom the linaro virtual connect discussing the status of unified arm kernel binaries 20:30:30 is there a written update to a mailing list somewhere so we don't have to watch an hour of video? 20:30:59 I can send something, but there's not a whole lot to say. It's being worked on upstream. We should just think of anything useful to feed back to them 20:31:08 #info As a practical matter there will at best be one kernel for v5, one for v6, one for v7, and separate kernels for LPAE vs non-LPAE 20:31:18 the need for a standard U-Boot envirnment is something I have raised 20:31:20 pwhalen: yep, we already knew about those differences 20:31:26 one of the current problems they are working through, header files need to be cleaned up, changing to unique header file names, with each driver including the specific header file name - eg omap. This will work for most header files. 20:31:55 Aproach will be to disable drivers initially to provide a working kernel on qemu, then re-enable and determine where it breaks 20:32:09 usb host controller issue is being looked in greater detail within the coming weeks (Linaro will allocate resources) 20:32:21 yep, so basically nothing has changed in all of that. Do they actually have it booting yet on the branch? Are they still aiming for 3.7 for the first merge with mainline? 20:32:26 Targeting the 3.7 merge window for incorporating the patches. 20:32:49 goal is to have single zImage working for Linaro Connect in Copenhagen (Oct 2012) to demo, not all are drivers expected to working 20:33:26 is this using device-tree to handle platform differences? 20:33:43 #info First Patches are targeted at the 3.7 kernel merge window 20:33:51 dmarlin: yea 20:33:54 so U-Boot support for device-tree becomes more important 20:33:56 device tree is one of a number of components needed 20:34:07 some of the engineers working on devicetree enablement are now shifting to single zimage 20:34:09 dmarlin: dt needs to have the drivers present, right now they can'd be built into the same image 20:34:14 #info There may be an initial unified zImage for some devices at Linaro Connect Copenhagen (Oct 2012) 20:34:16 dmarlin: not necessarily, we can append them to the end of the kernel 20:34:26 +1 device tree 20:34:42 #info Device Tree support in the bootloader is a requirement for unified zImage. 20:35:36 I think most of the last few lines are largely quotes from the etherpad we created during that connect video. I suggest rather than paste them all, we simply point people to the pad 20:35:49 jonmasters: pointer? 20:36:03 trying to find it 20:36:16 * jonmasters assumed you were copy/pasting 20:36:26 No, I'm summarizing what paul wrote. 20:36:29 jonmasters, no, couldnt find the doc they were working on 20:36:43 ah one sec 20:37:14 would it be premature to discuss how this affects our planning? 20:37:45 http://pad.ubuntu.com/QiCpcZWziq 20:37:54 #link http://pad.ubuntu.com/QiCpcZWziq 20:37:54 ^^^ contains everything mentioned above 20:38:11 #info The above link contains a summary of the meeting from the metting with more details. 20:38:44 bconoboy: I think we need this to flow down from upstream, it will affect us in the 3.7 timeframe (is that f18 updates or f19?) 20:38:51 * pbrobinson groans that it needs a login 20:39:07 one sec. 20:39:57 * ctyler never remembers his ubuntu login, he uses it *that often* 20:40:00 Nope, can't access 20:40:06 jonmasters: Please cut&paste into an fpaste 20:41:14 #undo 20:41:14 Removing item from minutes: 20:41:15 #undo 20:41:15 Removing item from minutes: 20:41:48 pwhalen: are there more topics? 20:42:15 none, open floor was next 20:42:22 perhaps we lost jonmasters 20:42:31 let's assume we have 20:42:33 #topic 5) Your topic here 20:42:51 Okay- following on with linaro's unified kernel: How is this going to affect our plans? 20:43:26 We're support kirkwood, omap, tegra, highbank, vexpress, imx today 20:43:41 Are any of thse going to work with a unified image? 20:43:44 OLPC today announced the XO-4 http://blog.laptop.org/2012/08/15/one-laptop-per-child-confirms-upcoming-launch-of-groundbreaking-dual-function-xo-4-touch/ 20:43:57 I'm thinking highbank and vexpress will 20:44:07 #link http://blog.laptop.org/2012/08/15/one-laptop-per-child-confirms-upcoming-launch-of-groundbreaking-dual-function-xo-4-touch/ 20:44:07 and omap will 20:44:14 bconoboy: a year from now, zImage will be viable across most of the archs we'll care about at that point 20:44:14 #info OLPC today announced the XO-4 20:44:53 XO-4 is a Marvell dual core A9 device 20:44:56 I would like us to add armada xp support, which will ultimately be plae 20:44:59 er lpae 20:45:14 bconoboy: when we have a kernel? 20:45:42 dmarlin: There's more to it than that though- dgilmore has been resistant to adding additional configurations because it will increase our build time which is an issue for PA 20:46:25 true, but that's not even an issue until we have a kernel in Fedora 20:46:29 which begs the question of our future builder plans? 20:46:59 future builders will be bigger and stronger and faster :-) 20:47:03 can we keep scalling out (more builders) and scale up (better builders) ? 20:47:05 pwhalen: sorry, I'm still here 20:47:06 and more of them :-) 20:47:21 masta: Yes, that's the plan 20:47:30 I thought i would have pricing on builders this week but it isn't quite ready yet. 20:47:41 maste: I'm not sure what your question is about the builders 20:47:47 masta: horizontal doesn't help much with long builds, like the kernel srpm emitting a zillion binary packages 20:48:27 #info fpaste of the single kernel zImage discussion: http://fpaste.org/IuEW/ 20:48:31 Anyway, my bigger question is: Can we drop armv5 if armv6 for pi works considerably better? Also, can we drop less popular targets like imx if they don't get unified zImage support? 20:48:49 jonmasters: thanks! 20:49:12 we'd need stats on package downloads first, I think 20:49:27 bconoboy: for v5 it would make us drop all the plug computers for a single device. I don't see the point as it offers little advantage 20:49:45 we have some stats from the nightlies. It was 90% pi downloads, followed by omap... everything else was in the noise. 20:49:46 for imx: we can review it as time goes on 20:49:51 I think dropping v5 in favor of v6 is a mistake, but that's a personal opinion. That basically gives up on everything that's older than v7 in favor of *one device* that isn't going to live forever 20:50:11 We also need to look at (Pi+APC) vs (Plug computer) volumes, though. 20:50:29 Because v5=kirkwood=older plug computers at this point, pretty much. 20:50:37 Btw, the APC is now in NewEgg 20:50:42 ctyler with v5 we can have Pi+APC+Plugs 20:50:45 when the Pi is gone, then v6 would be completely defunct. Sure, we want to kill it eventually, but the real question is how long do we plan to support the older pre-v7 devices 20:51:12 And do we want to push pre-v7 into primary? 20:51:12 jonmasters: v5 will be defunct too, since the newer plugs are v7 20:51:17 * jonmasters never likes the idea of doing an entire arch to support one platform 20:51:32 I think we leave it at v5 and eventually just drop < v7 all together 20:51:33 jonmasters: We're doing an entire arch to support kirkwood, ne? 20:51:45 but "doing an entire arch to support one platform" is exactly what we're doing with v5, if we're honest 20:52:06 bconoboy: v5 can support both kirkwood and Pi and anything else that is v5. I don't have a list of handy v5 devies, but there are more than just the kirkwood 20:52:22 yes, exactly 20:52:33 I guess our official pi image is a v5 20:52:38 well, my opinion is not /that/ strong since I'd love to kill v5 completely eventually, so whatever is best 20:52:40 Shall we revisit this question when we've wrapped up F18? 20:52:44 bconoboy: +1 20:52:54 +1 20:52:55 +1 20:52:59 and when we have v6 build performance data :-) 20:53:01 +1 20:53:17 #agreed Revisit dropping v5tel support (in favor of v6hl) after F18 is done 20:53:33 Okay, one other topic from me: 20:53:39 that means no more gurus i guess 20:54:13 Compulab have updated their trimslice uboot to support ethernet. This might mean pxe installation is possible. What is our stance on that? Do we want to pursue it? Doing so would require users update their uboot. 20:54:27 (Unless they bought a newer device that came with the new uboot) 20:54:39 updating uboot on a trimslice is easy 20:55:01 but a uboot *image* for microsd just for ethernet boot is just as easy, and safer 20:55:03 I don't think the average Fedora user is going to install a TrimSlice with PXE 20:55:14 Agreed 20:55:15 bconoboy: seems like a great feature... would rather pxe boot 20:55:42 I suspect this boils down to whether we have someone willing to run with it. 20:55:43 booting a trimslice diskless is an overall performance boost, if the server is faster than local usb disks 20:55:45 okay, so--- ignore it for now? 20:55:45 bconoboy: did they add any else interesting to uboot such as DT or uEnv support? 20:55:46 it's wonderful...on a server. It's probably useful for builders, etc. BUT the average person getting a trimslice is not running a PXE server and kickstarting it 20:56:20 I propose ignoring it unless someone steps up to make it happen. 20:56:25 +1 20:56:27 could we do it for our own selfish reasons jonmasters ? 20:56:30 pbrobinson: They simply put their changes upstream. Not aware of DT status. 20:56:51 they pushed their changed upstream? 20:56:53 masta: Want to make it happen? :-) 20:57:09 bconoboy: ok, I'll take a look 20:57:09 Into uboot 2012.04 they say 20:57:24 public git tree: https://gitorious.org/trimslice-u-boot-dts/trimslice-u-boot-dts/commits/trimslice/2012.04-upload 20:57:35 updated uboot binaries: http://www.trimslice.com/wiki/index.php/Firmware_Update 20:57:48 * djdelorie wonders if they have "just works" video drivers yet 20:57:56 #link New trimslice uboot binaries are at http://www.trimslice.com/wiki/index.php/Firmware_Update 20:57:58 masta: sure, selfishness is underrated 20:58:09 djdelorie: nope 20:58:27 2012.04 should support uEnv I think 20:58:47 That's it for me 20:58:50 2 minutes to the hour, anything else to discuss today? 20:59:03 nope! /me needs dinner! 20:59:31 last call ... 20:59:54 #endmeeting