fedora-meeting-1
LOGS
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