20:01:12 #startmeeting 20:01:12 Meeting started Wed Sep 19 20:01:12 2012 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:12 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:01:12 #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore 20:01:12 Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen 20:01:16 .fas pwhalen 20:01:17 pwhalen: pwhalen 'Paul Whalen' 20:01:23 .fas blc@ 20:01:23 bconoboy: blc '' 20:01:29 hi 20:01:30 .fas parasense 20:01:30 masta: parasense 'Jon Disnard' 20:02:01 .fas Frojoe 20:02:01 Frojoe: jacwang 'Jordan Cwang' - burningfool 'Jordan Cwang' 20:02:06 .fas dmarlin 20:02:06 dmarlin: dmarlin 'David A. Marlin' 20:02:39 so first item.. 20:02:49 #topic 1) F18 Build status - problem packages 20:03:13 .fas jbwillia 20:03:13 Southern_Gentlem: jbwillia '' - jbwilliams 'Jason Williams' 20:03:19 .fas jcapik 20:03:20 jcapik: jcapik 'Jaromír Cápík' 20:03:32 I think Peter said he would likely miss today. I have not had any real time to look at the ks logs.. does anyone have any updates on f18/19 problem packages? 20:04:14 I haven't been tracking it... 20:04:43 Nor have I 20:05:17 it looks like we've been hovering around 300 missing packages for weeks 20:05:24 peter is on holidays 20:05:38 bconoboy: well primary floodgates opened up 20:05:58 we have had about 1k updated packages the last 2 days 20:06:04 are we talking about this: http://arm.koji.fedoraproject.org/status/ 20:06:09 dgilmore: okay, so builders will be busy, eh? 20:06:24 bconoboy: well alot of it was built in updates-testing 20:06:31 masta that page is very old and out of date 20:06:34 bconoboy: but it might unstick some things 20:06:46 Same | Newer | Older | Local | Remote | Missing | 20:06:49 ------------------------------------------------------------------------------------------ 20:06:52 11820 | 8 | 155 | 1 | 311 | 329 | 20:07:06 why we have 8 newer id like to know 20:07:15 pwhalen: will you be managing koji-shadow while pbrobinson is away? 20:07:15 they should get pushed to primary 20:07:21 would be nice to bring it back, had shadow logs available for all to see 20:07:29 I think pbrobinson mentioned python-greenlet needed some attention. not sure if anyone has looked at it. 20:07:31 bconoboy, I have been given access to the logs as is 20:07:42 the 311 remote would be nice to work out if they are excluded or if there is some reason they are not built 20:07:58 dgilmore http://142.204.133.82/jon/koji/kc.f18.diff.html 20:08:25 gmt, fpdns, gdesklets, imagefactory, libservicelog, msp, olpc 20:08:40 peter has mentioned somebody needing to look at python-greenlet 20:08:41 assuming its correct 20:09:20 i have inheritence turned on for f18 checks 20:09:42 fossjon: thats wrong 20:09:51 it looks like olpc-kbdshim was built manually, i guess the developer doesnt know that shadowing happens 20:09:56 fossjon: the only place that should have inheritance turned on is rawhide 20:09:59 #info same: 11820, newer: 8, older: 155, local: 1, remote: 311, missing: 329 20:10:00 the equivalent build is also on primary - but it is in updates-testing 20:10:07 dsd: ok' 20:10:17 bconoboy so your numbers match mine tho? 20:10:39 fossjon: I'm just putting a meetingbot record from dgilmore's numbers 20:10:49 oh oh 20:11:45 well i can turn inherit off 20:11:47 :) 20:12:11 anyway, i havent really calculated if theres any major blockers for that 20:12:18 it'd be interesting to check 20:12:19 bconoboy: my numbers were from fossjon's email today 20:12:33 so my numbers match my own then! 20:12:37 #info python-greenlet still needs attention - http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1145082 20:13:01 We also have a serious F19 blocker, but that's another topic 20:13:55 do we have anyone here who would like to look at python-greenlet? 20:14:02 we're using F18 for OLPC development, things seem as good as ever. updates-testing hasnt been pushed for a couple of weeks, so hasnt been tested, but dgilmore suggested today that there will be a push soon :) 20:14:57 dsd: still waiting on packages to be signed 20:15:02 but they are getting there 20:15:41 DEBUG util.py:257: Requires: libxml2.so.2(LIBXML2_2.4.30) 20:16:12 fossjon, was that the f17 build? 20:16:20 ya im checking python-greenlet now 20:16:58 which is weird because we have libxml2-2.7.8-8.fc17 built for f17 20:17:02 maybe its not tagged? 20:17:13 hmmm 20:17:29 fossjon, ks issue, that may either fail as the f18 did 20:17:49 or perhaps build.. 20:18:12 fossjon: got a link to that log? i think the lines above it might be interesting 20:18:29 http://arm.koji.fedoraproject.org/koji/getfile?taskID=1144414&name=root.log dsd 20:18:37 thats the failed v7hl log for python-greenlet 20:18:52 ok, so the problem package is shared-mime-info 20:19:00 built against an old libxml2 20:19:05 oh i thought it was the requires part :/ 20:19:19 1 line above :) 20:20:24 may be worth while to re-queue that build as it looks like an init buildroot issue with shadow 20:20:37 move on thenn? 20:20:41 yep 20:20:49 #topic 2) What will we ship for F18? Format and platforms 20:21:00 so my thoughts here 20:21:15 we should make images for omap devices 20:21:28 we should have the kickstart setup the image so it can be dd'd 20:21:37 with no messing around after 20:21:50 ideally we have a vexpress image also 20:22:16 we would need images for kirkwood 20:22:28 tegra? 20:22:36 highbank? 20:22:37 tegra, highbank, imx, vexpress we should only need to have install images 20:22:52 dgilmore: why? 20:23:21 bconoboy: there is little point to images for them, if anaconda works 20:23:26 fossjon: actually shared-mime-info is fine. i agree with just kicking off another build and hoping that the problem has gone 20:23:38 bconoboy: hopefully we can get a working framebuffer on tegra rsn 20:23:45 dgilmore: anaconda will only work on trimslices with new uboot versions which most trimslices do not have. 20:23:47 has anyone tested anaconda on tegra? 20:24:00 bconoboy: well it will be a requirement 20:24:05 have to upgrade uboot 20:24:37 I prefer to just create a flash image for trimslice... works on existing systems with no u-boot update 20:24:38 dgilmore: I think that's a mistake. we should make images for tegra this time around- use anaconda for f19. 20:24:44 dmarlin: with all the crazies with the new uboot, sry I tried and gave up 20:24:52 bconoboy: why? 20:25:08 dgilmore: because it works 20:25:14 dgilmore: I'm not even *able* to boot with the new uboot on trimslice. Telling everybody to upgrade will immediately break all F17 installs for one thing. 20:25:18 dmarlin: but it wont 20:25:36 GA doesn't work with the new uboot. 20:25:41 so we have the case where in f18 we are going to have to be required to use dtb 20:26:01 we can burn that bridge when we come to it. :) 20:26:09 +1 20:26:11 bconoboy: did you file bugs with compulab? 20:26:16 dgilmore: yes. 20:26:23 dmarlin: it will be less than 1 month after GA 20:26:52 that buys us a month then 20:27:01 dmarlin: not at all 20:27:01 dgilmore: I'm just saying, for F18, we shoudl support both. No bootable images means we're raising the bar for using fedora on trimslice. That's not desirable. 20:27:09 because we need to be working on it now 20:27:29 bconoboy: i disagree its raising the bar 20:27:51 can we have (shudder) two images for trimslice, one for the new uboot and another for the old? There are nasty complications with the new uboot 20:27:57 ? 20:28:13 dgilmore: Forcing a firmware ugprade that breaks an existing installation so somebody can then run a PXE installer to try out F18 is raising the bar. You must see that. 20:28:14 masta: I'd prefer fewer images, not more 20:28:21 agreed 20:28:25 masta: we already have more than we have time to test 20:28:37 bconoboy: they wont be running a pxe installer 20:28:55 with what we have, they won't be running at all 20:29:05 bconoboy: we will have a boot.img like the boot.iso that can be dd'd onto a sdcard and will boot and run anaconda 20:29:28 dgilmore: and you have tested this? 20:29:40 I believe wcohen has his TS working on the new uboot, but so far been unable to reproduce his results 20:29:50 dmarlin: not yet. no one has tested any f18 thing right now 20:30:01 exactly 20:30:12 dmarlin: your missing my points 20:30:41 Maybe we should take a step back- are we talking about F18 final or f18 alpha? Because right now we're pre-alpha. 20:30:43 we do need to have a clear list of what we will deliver 20:30:55 And in our pre-alpha state we're way far behind where we were with F17. 20:31:16 bconoboy: ideally we ship the same things for alpha beta and ga 20:31:16 So I'm all for adding cool stuff to F18. But let's get alpha criteria down. 20:31:29 dgilmore: Ideally we ship in 2012. 20:31:36 bconoboy: if we ship images for tegra for alpha and installer images for beta and ga so be it 20:31:37 anaconda is not ready. 20:31:59 so if anaconda becomes ready for beta, let's use it for beta 20:32:01 bconoboy: thats BS 20:32:16 i heard anaconda was broken with f18 for primary? 20:32:19 anaconda is buggy 20:32:19 someone told me 20:32:32 is that still true? 20:32:33 fossjon: if it was broken we wouldnt have shipped alpha 20:32:41 its got bugs 20:32:45 its not perfect 20:32:49 but its not broken 20:32:54 once we get a working f18 kernel/userland on the latesr TS uboot, I'll test anaconda over pxe. 20:32:55 it doesn't support text mode yet, right? 20:33:05 bconoboy: it does 20:33:18 bconoboy: its just not in the way livemedia-creator wants 20:33:19 the rewrite is done? 20:33:25 bconoboy: its not complete 20:33:29 but it does work 20:33:48 bconoboy: we need to rely on people doing there work and do ours 20:34:00 not sit around and go oh thats broken so ill do something else 20:34:33 * dgilmore is frustrated right now that we are getting hung up on things and not moving forward generally 20:34:34 right but if something is buggy on there end it makes no sense to work with it on our end until they fix it right? 20:34:42 their* 20:35:01 fossjon: no, the idea of alpha is to make beta better 20:35:06 and GA better still 20:35:16 dgilmore: I'm not exactly sure what you're proposing. If livemedia-creator support isn't finished and we can't use it, what are you suggesting? 20:35:22 ok so we try to move forward with omap and vexpress... we are hung up on tegra 20:35:49 bconoboy: im trying to get us to have a list of what the fuck we are going to ship. in an ideal world 20:36:07 assuming the next kernel is working on omap, can we then move to make an image using the tool? 20:36:16 if we end up needing to go down different routes so be it 20:36:34 the world is not ideal, so we should also have a fall-back plan 20:36:48 minimal set of things to release 20:37:36 dgilmore: Okay, ideal world, but not necessarily The Plan of Action? I'm cool with that. 20:37:46 this is just my personal preference, but I'd like to just make images for things that 'can' boot from flash (trimslice, panda) 20:38:21 easy to make, easy to install, easy to test 20:38:26 * masta +1 20:38:48 I think, ideally, we could include directly writeable images as we did in F17 for the same platforms as F17. On top of that we would add installer support for platforms where it makes sense. Not sure if that's anything other than highbank. Perhaps armada-xp if upstream support lands in time. 20:39:23 Ideally, we'll consolidate on a unified kernel for the targets that support it. 20:39:26 unlikely armada-xp will be upstream for f18 20:39:36 I think its support is in 3.7 20:39:54 bconoboy: i suspect that we will ship with 3.6 20:40:00 but 3.7 will require dtb 20:40:18 and we will get 3.7 when 3.7.1 is released 20:40:41 Is there anything we can do now to handle dtb in a 3.7 update? 20:41:17 the dtb format is supposed to be stable 20:41:23 so we should be using dtb in 3.6 20:41:36 how? 20:41:39 we should ship f18 using dtb everywhere 20:41:45 we have to work that out 20:41:52 ideally vendors ship the dtb 20:41:53 okay, probably beyond scope for this meeting 20:42:02 yes 20:42:20 If we can use dtb everywhere with f17 3.6 I'm for it. It sounds aspirational though. 20:43:17 we really dont have much choice 20:43:40 imx? 20:43:41 has anyone managed to boot using dtb on any of our device (except highbank)? 20:43:57 dmarlin: ive booted panda with an appended dtb 20:44:05 I think we're supporting vexpress, omap, tegra, highbank, kirkwood. Anything else? Is imx staying? 20:44:10 which is not the ideal way to do it 20:44:20 bconoboy: id be ok dropping it 20:44:44 not sure thatthe framebuffer will ever get upstream 20:45:02 i think the efika smarttop is sold out 20:45:09 you can only get the smartbook 20:45:15 and it only works with f13 20:45:27 bconoboy: for f17 'blockers' was a smaller list... same for f18? 20:45:29 #info We may drop IMX support 20:45:39 +1 to dropping imx 20:45:45 +1 20:45:57 #info Plan is to support vexpress, omap, tegra, highbank, kirkwood in F18 20:46:48 #info Reach-goal is to support DTB on all possible platforms with 3.6 kernel in preparation for unified 3.7 kernel 20:46:48 bconoboy: for f17, we only blocked on vexpress, panda, and highbank, correct? 20:46:57 dmarlin: think so 20:47:03 anybody want to change that? 20:47:04 bconoboy: same for f18? 20:47:23 * dmarlin is for keeping it the same 20:47:24 #info Blocker platforms: vexpress, omap, highbank 20:47:26 those seem reasonable to me 20:47:32 +1 20:47:41 bconoboy, no panda? 20:47:46 sorry 20:47:48 nm 20:47:49 :-) 20:47:57 id like tegra to be a blocker if we get the tergadrm module in 20:48:01 That's a good question though- we going to support beagle and panda? 20:48:03 change omap -> panda 20:48:04 it then becomes a viable desktop 20:48:10 dgilmore, agreed 20:48:20 +1 the blocker platforms 20:48:24 #info Tegra becomes a blocker iff tegradrm support lands 20:48:24 dgilmore: _1 20:48:30 dgilmore: +1 20:49:04 did we reach a consensus on what we ship, or revisit? 20:49:18 pwhalen: we did not 20:49:28 There's requirements and goals, right? 20:49:36 shall we come back to this next week, or continue? we are closing in on the hour 20:49:44 lets take it to the list 20:49:45 I'd say requirements are: Directly installable images for any target we can't use anaconda on 20:49:50 ill kick off a thread 20:49:54 sounds good 20:49:57 ok 20:50:06 we need to have all platforms supported be installable 20:50:12 how that works is up to debate 20:50:24 #info Installer vs Writable image debate to follow on Fedora's arm mailing list 20:50:50 #topic 3) Fedora 18 kernel status a)mmc driver issues b)Kernel testers (including those willing to look at FTBFS) 20:51:02 * dgilmore is about to test a omap kernel 20:51:13 rebooting into it now 20:51:14 dgilmore, we eagerly await 20:51:17 dgilmore: Are you testing kernel changes or anaconda changes? 20:51:22 er, dracut rather 20:51:26 s/anaconda/dracut/ 20:51:28 bconoboy: its actually both 20:51:36 pwhalen has tested 3.6 on f18 fof vexpress 20:51:44 bconoboy: enabled OMAP_DRM as a module in the kernel 20:51:53 and a dracut change to pull the module in 20:51:53 dmarlin: that test failed because of mmc issue, y? 20:52:02 bconoboy: nope, it works 20:52:14 really? 20:52:16 bconoboy: unfortunately, rc5 breaks again 20:52:23 but due to memory overlap 20:52:39 ah 20:52:42 https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing#kernel-3.6.0-0.rc5.git2.1.fc18 20:52:55 #link https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Testing#kernel-3.6.0-0.rc5.git2.1.fc18 20:53:02 dgilmore: Are you making changes to dracut so we get the modules on each supported platform, or is it just a change to support omap right now? 20:53:03 ok thats special 20:53:04 http://www.fpaste.org/5YAw/ 20:53:07 those were my latest 20:53:21 bconoboy: right now omap but we will need to do all platforms 20:53:37 the dma engine gets loaded but still not used 20:53:59 Just to repeat what I said yesterday: I think we should build the mmc drivers into the kernel, at least for alpha, so we can test the total platform right away. 20:54:42 bconoboy: we are working on that 20:54:56 dmarlin: I mean =y rather than =m 20:55:04 bconoboy: interim solution until dgilmore gets dracut fixed 20:55:33 dmarlin: these are just scratch kernels though, no? 20:55:41 bconoboy: yes, at this time 20:55:42 maybe we need to make the dma engine =y and then =m the other stuff ? 20:56:03 of course =y all the mmc code path would be handy 20:56:12 Okay, if this is still an issue next wednesday can we move to =y in non-scratch kernels? 20:56:51 +1 20:57:01 we cannto wait forever 20:57:12 dgilmore? 20:57:20 +1, we can always revert to =m later, when working 20:57:55 bconoboy: i dont think it will matter 20:58:05 because i think we will ahve it fixed by then 20:58:06 why? 20:58:11 cool 20:58:17 if not...? 20:58:18 dgilmore: in that case can we have your tentative support if it isn't fixed? 20:58:29 bconoboy: im staying out 20:58:34 ill make up my mind later 20:58:35 bconoboy: think positive. :) 20:58:47 :-) 20:58:48 okay 20:59:10 #action dgilmore is fixing the kernel and dracut to support initramfs inclusion of mmc drivers for all supported platforms 20:59:18 alright, positive thoughts on 'speak like a pirate day'. This will be fixed by next week. no ifs 20:59:33 yar! 20:59:36 #info Tentative agreement to build modules in if it's not fixed in 1 week 20:59:47 #undo 20:59:48 Removing item from minutes: 21:00:00 #info Tentative agreement to build mmc drivers into vmlinux if it's not fixed in 1 week 21:00:23 and the last 30 seconds... 21:00:26 #topic 4) Your topic here 21:00:41 F19 needs glibc love 21:00:53 anybody available to dig in? 21:01:02 ! 21:01:16 is there support for out-of-tree kernel module ? 21:01:35 on f17 kernel-devel it's failing with: 21:01:41 I've narrowed it down to a change between glibc-2.16.90-5 and glibc-2.16.90-6 21:01:46 /usr/src/kernels/3.4.2-3.fc17.armv5tel/arch/arm/include/asm/timex.h:15:24: fatal error: mach/timex.h: No such file or directory 21:01:59 kwizart: this is not the right forum for that question 21:02:05 bconoboy: is that the significant f19 problem? 21:02:33 the reason f19 has 1500 unbuilt packages is this glibc problem. 21:03:10 bconoboy: tell me like I'm five, what is the problem? FTBFS all over? only in arm? 21:03:24 ftbfs for armv5tel 21:03:38 hang on, I'll pull up a build log.. 21:03:53 (on an unrelated topic, why is arm.koji so slow?) 21:03:53 last one was v7 21:03:57 http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1140903 21:04:31 masta: see https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1135741 21:05:00 The failure in -2 has been fixed. The problem in -10 and -11 is current. 21:05:16 pwhalen: What you posted is for -2- I Fixed that :-) 21:05:21 bconoboy, ctyler was looking at that yesterday, it seemed to get a little quicker. he mentioend a bottleneck on the db server but yes, horribly slow. 21:05:31 awesome 21:05:39 masta: Are you volunteering on glibc? :-) 21:05:48 hosts page, forget about it 21:06:03 our hosts page is horrible because of this sessions/states table in postgresql which has grown to be huge i believe 21:06:13 #info F19 glibc build failure is blocking 1500+ builds 21:06:39 #info glibc failure was introduced between glibc-2.16.90-5 and glibc-2.16.90-6 21:07:50 bconoboy: I will see what I can do, but I'm cautious about owning it.... lack of self confidence 21:08:03 nothings permanent :) 21:08:16 masta: I have a diff if you want to run through it :-) 21:08:25 pwhalen: I think we're petering out 21:08:43 sorry, was looking at glibc.. 21:08:46 anything else?! 21:09:00 last call.... 21:09:07 #endmeeting