21:00:45 <pwhalen> #startmeeting 21:00:45 <zodbot> Meeting started Wed Nov 14 21:00:45 2012 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:45 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore 21:00:45 <zodbot> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen 21:00:47 * jonmasters is in 21:00:53 <jcapik> .fas jcapik 21:00:54 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com> 21:01:00 <dmarlin> .fas dmarlin 21:01:01 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com> 21:01:06 <bconoboy> .fas blc@ 21:01:09 <zodbot> bconoboy: blc '' <blc@redhat.com> 21:01:10 <pwhalen> .fas pwhalen 21:01:12 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com> 21:01:19 * masta waves 21:02:09 <pwhalen> #topic 1) Problem packages needing attention 21:03:17 <jonmasters> pleased to report openmpi is "fixed" 21:03:24 <pwhalen> pbrobinson mentioned the kernel being a major blocker 21:03:34 <jonmasters> I posted a work in progress patch for llvm that someone can poke at if they have cycles 21:07:08 <bconoboy> pbrobinson: problem packages? 21:07:29 <pbrobinson> texlive. I've got sick of waiting for someone else to look at it so I'm syncing down the fedpkg source now to try and work out the problem myself. It's taking a long time on the hotel ling 21:07:32 <pbrobinson> link 21:07:54 <pbrobinson> there's a number of other breakages due to the koji issue I mentioned on list. More on that later 21:08:22 <pbrobinson> still waiting for eclipse so bconoboy if you could poke people internally that would be fab 21:08:35 <bconoboy> ok 21:08:43 <bconoboy> #action bconoboy to ping people about eclipse 21:08:50 <bconoboy> #action pbrobinson looking at texlive 21:08:56 <pbrobinson> or some on eclipse, my eyes are glazing over as I don't care what is broken I just want it fixed! 21:09:17 <pbrobinson> some dep of eclipse.... 21:09:29 <bconoboy> it in armtracker? 21:10:04 <pbrobinson> yes 21:10:19 <pbrobinson> same bug as previously, there are details there. I think from mem it's tycho 21:10:27 <pbrobinson> but under the eclipse bug 21:10:36 <bconoboy> okay 21:10:51 <bconoboy> any other problem packages? 21:12:20 <bconoboy> pbrobinson: And, if not, anything else you want to cover since it's late there? 21:14:06 <bconoboy> pwhalen: better move on 21:14:22 <pwhalen> #topic 2) Exynos 5 (Chromebook) Kernel - Is anyone currently working on this? 21:14:46 <pwhalen> I know some of you have been lucky enough to snag one early, any work being done? 21:15:25 <jonmasters> We discussed this earlier, thought is someone needs to make a kernel variant 21:15:40 <bconoboy> dgilmore, how about you? 21:15:43 <sharkcz> dgilmore was trying to build one AFAIK 21:16:01 <bconoboy> yeah, that's what I remember too 21:16:15 * pbrobinson is back. Dumb hotel wifi 21:16:48 <pbrobinson> I've been looking at the exynos5 kernel 21:16:53 <pbrobinson> slowly when I have time 21:17:59 <pwhalen> ok, perhaps we'll ask dgilmore for an update on the list 21:18:17 <pwhalen> see if anyone else is working on it as well 21:18:26 <pbrobinson> does anyone see my updates? 21:18:29 <bconoboy> pwhalen: that your task? 21:18:32 <bconoboy> pbrobinson: yes! 21:18:45 <bconoboy> #action pwhalen to mail fedora-arm asking if anybody is doing exynos kernel work 21:18:49 <pbrobinson> no more problem packages. 21:19:06 <pbrobinson> I'm looking at a remix exynos5 kernel 21:19:18 <jcapik> do we have any list of all devices/laptops we want to support? 21:20:12 <pbrobinson> jcapik: no because we're very dependant on upstream support. It's improving. eg we should be able to support a lot more tegra devices with 3.8 with DRM even 21:20:48 <pwhalen> lets get the discussion going on the list for the Exynos 5, come back to it next meeting perhaps 21:21:04 <pwhalen> we'll cover pbrobinson's next topic before we lose him again 21:21:22 <pbrobinson> OK. I think I've worked out the problem issue with koji 21:21:22 <masta> +1 21:21:24 <pwhalen> #topic 3) Issues with koji builds/builders/rewRepos 21:21:52 <pbrobinson> basically it's a problem with newRepos. Disabling bahamas looks to have fixed the problem 21:22:10 <pbrobinson> I need Seneca to investigate further but I'd like to leave it disabled overnight 21:22:27 <pbrobinson> can someone ack they've seen those 3 points from me? 21:22:34 <bconoboy> #info There is a problem with newRepos. Disabling bahamas has temporarily fixed it 21:22:49 <bconoboy> #action Seneca team needs to investigate 21:22:55 <bconoboy> pbrobinson: ack 21:23:08 <pbrobinson> OK, I seem to be OK at the moment then. 21:23:21 <pwhalen> #link newrepo failure - http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1226603 21:23:29 <pbrobinson> I think it's fixed, its only been disabled for 15 mins or so 21:23:43 <pwhalen> pbrobinson, thats old, is that the same error? 21:23:46 <pbrobinson> but all builds I've (re)submitted have worked 21:24:04 <pbrobinson> pwhalen: no. 21:24:30 <jonmasters> would this explain why I've seen failed buildroot generation in mock? 21:24:32 <pwhalen> #undo 21:24:32 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2cd4cf10> 21:24:54 <pbrobinson> yes, it normally looks like a whole of of perl and other dep errors in the yum phase 21:25:04 <jonmasters> ah excellent, that one, great 21:25:10 <pbrobinson> example is http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1251516 21:25:13 <jonmasters> seen it a few times in the past few days 21:25:32 <pbrobinson> I've seen it a lot since before last weekend. I thought it was specific hosts at first 21:25:46 <jonmasters> yup, I thought a couple of the HSV builders were having cache problems or similar over the weekend, but this was it then 21:25:55 <jonmasters> pbrobinson: indeed, same 21:26:29 <pbrobinson> anyway I think the problem child ^W host is disabled, I'll check it again tomorrow to see how builds are looking 21:27:17 <bconoboy> #link http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1251516 21:27:31 <pwhalen> that init buildroot issue happens with shadow 21:27:36 <pwhalen> I dont see the newrepo issue 21:28:36 <pbrobinson> pwhalen: it's not a newRepo task failing.... it's basically generating bad incomplete repos. 21:29:08 <pwhalen> shadow creates a repo and sometimes pulls in packages with 'broken' deps as a result, is that a 'normal' shadow occurrence ? (it was) 21:30:01 <pwhalen> you mentioned newrepo and Bahamas, but I dont see the failures 21:30:04 <pbrobinson> pwhalen: it was happening on all builds. This is NOT a shadow problem 21:30:15 <pbrobinson> read what I wrote above please 21:30:29 <pwhalen> I did, and have seen it quite a bit with shadow 21:31:01 <pbrobinson> I AM SEEING IT ON ALL BUILDS FOR THE THIRD TIME. THIS IS _NOT_ A SHADOW PROBLEM 21:32:52 <pwhalen> #topic 4) SE Linux issue with F18 kernels - status update 21:33:20 <masta> been seeing this on panda 21:34:13 <masta> jonmasters: I have not forgot about the strace, but the issue for me... it went beyond there... right now I'm able ot make my board completely non-booting by just installing a kernel... 21:35:24 <masta> er... because the consequences are a the reboot doesn't work.... systemd goes crazy, so have to go permissive to be able to touch /.autorelabel, then sometimes it's a gamble the reboot will work when putting back enforcing 21:35:57 * jonmasters is going to investigate this some. I'll do what I usually do with systemd and ignore it :) 21:35:58 <masta> so for folks on pandaboard, it's easy to reproduce 21:36:16 <masta> permissive always works 21:36:24 <jonmasters> got my trusty hardware debugger so I can just stop the kernel and ignore systemd :) 21:36:27 <masta> enforcing triggers some problems 21:37:18 <masta> jonmasters: that sounds impressive and way above my head.... gives confidence to read 21:38:02 <jonmasters> masta: I'll triage it some right now, then summarize what I think 21:38:21 <jonmasters> masta: once I've somewhere useful for folks to poke, perhaps you can pick it up? 21:38:29 <masta> so one thing for sure.... grab the last alpha f18 image, notice NetworkManager doesn't start normally, but it works on a systemctl restart.... after doing a yum update the system will be very unhappy... at least for me 21:38:44 <pwhalen> #action jonmasters to look into SE Linux/F18 Kernel issue - update to be sent to the list 21:38:45 <jonmasters> ok 21:39:19 <pwhalen> #topic 5) SFP images for F18 Beta - What images will be produced? 21:40:09 <masta> jonmasters: yes I'll pick it up once you get something 21:40:18 <pwhalen> I think kirkwood is a given, are there any other targets we would like to support? 21:40:32 <pbrobinson> I would like to see a panda SFP image produced. 21:40:46 <pbrobinson> it should be as simple as changing the repo line 21:41:09 <jonmasters> oh, for builders? 21:41:13 <masta> pbrobinson: that's interesting, why a soft float for a chip with hard float? sry if it's a naive question? 21:41:27 <pbrobinson> masta: there are still people using softfp 21:41:39 <dmarlin> on panda? 21:41:42 <pbrobinson> so it's useful to have a half decent HW platform for them 21:42:11 <pbrobinson> dmarlin: I've heard of people on panda and beagle. 21:42:27 <dmarlin> so who would like to take ownership (for testing images) 21:42:28 <pbrobinson> if we do panda all the should have to do for beagle is to swap the uboot 21:42:43 <jcapik> they could use it for building SFP software for other platforms 21:42:48 <pbrobinson> I can test a sfp image for either beagle or panda 21:43:43 <jcapik> I can test SFP image on panda 21:43:52 <pbrobinson> I've had a number of discussions about people using it. Also the only oracle java is softfp at the moment, as are a number of other proprietary bits and I would like in the short term for them to use Fedora if possible 21:44:18 * masta can test too 21:44:29 <pbrobinson> for us it should basically be identical to the hardfp image in terms of most things so I don't see that it adds much work 21:45:10 <dmarlin> the kickstart should be a simple change (as you said) but we'll have to dedicate resources (sfp builder) to make images, and people to test 21:45:55 <dmarlin> and fix, if there are issues 21:46:33 <pbrobinson> we've had a number of people volunteer to test, and the problems should mostly be for the same as for the hardfp so I don't see that as a large burden. So it's just somewhere to build it 21:46:47 <dmarlin> right 21:47:14 <pwhalen> Seneca is looking at setting up a SFP builder for images, but have not heard the status today 21:48:35 <pwhalen> if we have Kirkwood and a Panda image for SFP, does that cover SFP to everyone satisfaction for beta/final? 21:49:01 <pbrobinson> IMO it does 21:49:22 <masta> sure 21:49:26 <pbrobinson> the process will be documented so it shouldn't be hard for people that want others to make them 21:49:28 <jcapik> yup 21:49:32 <dmarlin> it gets my vote. 21:49:43 <pwhalen> #info SFP images to be made for Kirkwood (generic) and Pandaboard for F18 Beta/Final 21:50:01 <pwhalen> #topic 6) FUDCon Lawrence ARM activity planning 21:50:56 <pwhalen> bconoboy, did you have some ideas for activities? 21:51:09 <masta> I guess we should bring our boards? 21:52:08 <bconoboy> remixathon: Everybody bring an arm device and get it working with fedora- post an image at the end. 21:52:10 <pbrobinson> hacking on the ability to install Fedora like this would be cool http://www.engadget.com/2012/10/27/ubuntu-nexus-7-installer/ 21:52:21 <jonmasters> ARMv8 bootcamp 21:52:33 <bconoboy> yeah, v8 bootstrap would be a great second topic 21:52:52 <jonmasters> well, bootcamp too - like a whole intro, walkthrough, etc. 21:53:42 <pbrobinson> giving out the RPi's that people won at last year's FUDCon if they haven't already got them? Or has that problem been solved? 21:54:23 <bconoboy> #idea ARM Remixathon at fudcon 21:54:32 <bconoboy> #idea ARMv8 bootstrap seminar/hackathon at fudcon 21:54:49 <bconoboy> #idea ARM installer hackathon 21:56:36 <pwhalen> any other ideas for FUDCon? 21:57:18 <pwhalen> #topic 7) Open floor 21:57:58 <pbrobinson> Just a FYI that I keep forgetting @FUDCon EMEA I had discussions with a company that is planning on using Fedora ARM on over 100K devices. I think that's a pretty cool achievement for the project 21:59:02 <jcapik> good start at least 21:59:45 <pbrobinson> well we already have 100K or so ARM OLPCs I believe too 22:00:02 <jcapik> really? 22:00:29 <pbrobinson> yes 22:00:30 <jcapik> that's even better 22:00:35 <pwhalen> #endmeeting