#fedora-meeting-1 log

21:00:29 <pwhalen> #startmeeting Fedora ARM weekly status meeting
21:00:29 <zodbot> Meeting started Wed Feb 27 21:00:29 2013 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:30 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore
21:00:30 <zodbot> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen
21:00:35 <pwhalen> .fas pwhalen
21:00:38 <jcapik1> .fas jcapik
21:00:46 <masta> .fas parasense
21:00:50 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
21:00:57 <zodbot> jcapik1: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
21:00:59 <zodbot> masta: parasense 'Jon Disnard' <jdisnard@gmail.com>
21:01:09 <ahs3> .fas ahs3
21:01:09 <zodbot> ahs3: ahs3 'Al Stone' <ahs3@redhat.com>
21:01:17 <dmarlin> .fas dmarlin
21:01:17 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
21:01:44 <pwhalen> #topic 0) Status of ACTION items from our previous meeting
21:01:54 <pwhalen> #info Meeting Minutes from last week:
21:02:01 <agreene> .fas agreene
21:02:01 <pwhalen> #link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-02-20/fedora-meeting-1.2013-02-20-21.00.html
21:02:03 <zodbot> agreene: tag4fedora 'Tim Greene' <tagreene@flowserve.com> - agreene 'Andrew Greene' <andrew.greene@senecacollege.ca>
21:02:23 <pwhalen> only one from last week
21:02:35 <pwhalen> #info INPROGRESS jonmasters to file bug report with llvm upstream community
21:02:37 * pbrobinson is here
21:02:57 <pwhalen> #topic 1) Problem Packages
21:02:57 <bconoboy> jonmasters: update on llvm upstream bug?
21:03:03 <pwhalen> #undo
21:03:03 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2809ee10>
21:04:07 <bconoboy> #undo
21:04:07 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2cb799d0>
21:04:19 <pbrobinson> so the two candidates are still there java-1.7.0-openjdk and eclipse. They're still being worked on, i just wish they would be a little faster
21:04:21 <bconoboy> #action INPROGRESS jonmasters to file bug report with llvm upstream community
21:04:28 <bconoboy> #topic  1) Problem Packages
21:04:54 <pbrobinson> so the two candidates are still there java-1.7.0-openjdk and eclipse. They're still being worked on, i just wish they would be a little faster
21:05:48 * bconoboy looks for bz
21:05:49 <bconoboy> s
21:06:11 <pbrobinson> eclipse 863801
21:06:27 <bconoboy> #info eclipse (bz 863801) is ongoing
21:06:52 <bconoboy> #info java-1.7.0-openjdk also ongoing, no bz yet
21:06:52 <pbrobinson> we have a new ICE caused by crash. rhbz 915830
21:06:53 <pbrobinson> crash being a package
21:07:12 <bconoboy> #info crash (bz 915830) causes gcc to ICE compiling iwmmxt.c
21:07:56 <pbrobinson> there's an issue with perl-YAML-Syck which I've not looked at because it's perl
21:07:58 * nirik is sorta here, can provide some phx2 updates at whatever time required.
21:08:19 <bconoboy> #info mongodb is still broken
21:08:27 <bconoboy> #action jonmasters to provide pointer to mongodb patch
21:08:46 <pbrobinson> ah I've got the mongo patch in my queue.... sorry, will deal with that tonight
21:08:54 <bconoboy> #undo
21:08:54 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x3ae26d0>
21:09:14 <bconoboy> #action pbrobinson to apply jonmasters' mongodb patch
21:10:04 <pwhalen> anything else to mention?
21:10:15 <bconoboy> I think there's one more, but can't recall what it is.
21:10:25 <pbrobinson> not really, there's a number of other minor issues but they're not blocking
21:10:40 <pbrobinson> blocking as in not blocking the major builds
21:10:41 <pwhalen> ok
21:10:51 <pwhalen> #topic 2) Aarch64 config.guess patching
21:11:09 <bconoboy> dgilmore: you here?
21:11:22 <pbrobinson> I'm not up to speed on this stuff because I wasn't at FUDCon but I've also not seen it documented anywhere
21:11:25 <pwhalen> he had hoped to be, but lots of snow
21:11:28 <dgilmore> i am
21:12:04 <bconoboy> dgilmore: We want to get as many config.guesses updated in f19 as possible to include the aarch64 triplet. What is the right workflow for this?
21:12:34 <dgilmore> bconoboy: i think we need to write a script to work out effected packages
21:12:38 <pbrobinson> is there a way to query what needs to be patched without just blanket doing everything even if it doesn't need it?
21:12:42 <dgilmore> then we can work a plan of attack
21:12:54 <pbrobinson> from random checks that I've done all the gnome stack is OK for example
21:13:16 <bconoboy> dgilmore: we have a script.  it produces patches for those packages that we think need it
21:13:19 <dgilmore> the things that wont be ok are likely those with mostly dead upstream
21:13:25 <pbrobinson> and jonmasters was going to followup if cmake and other builders needed patching or just auto*
21:13:27 <bconoboy> dgilmore: it even adds what we think are viable patches to the spec file
21:13:28 <dgilmore> that haveing had an update in over a year
21:13:53 <dgilmore> bconoboy: that script was completely wrong in how it did things,
21:13:59 <bconoboy> dgilmore: the script is being updated.
21:13:59 <pbrobinson> bconoboy: is there a report somewhere to say how many packages, has it been run recently?
21:14:03 <dgilmore> bconoboy: in that none of it happened in the git checkout
21:14:12 <dgilmore> where the patches could be added in a scripted manner
21:14:31 <dgilmore> bconoboy: step one is work out how many packages actually need patching
21:14:45 <dgilmore> then we can work out how big the problem is
21:14:49 <bconoboy> dgilmore: Let's say it's 500 packages, we have the patches, what then?
21:14:53 <dgilmore> if we just go to the upstreams
21:14:55 <bconoboy> (hypothetical)
21:15:06 <dgilmore> bconoboy: then ill apply them and build updates
21:15:39 <bconoboy> dgilmore: So if we deliver to you the list of packages that need patching, the patches that are confirmed to apply and not break composing, you'll apply and build?
21:15:56 <pbrobinson> I think we need some form of report as to what's needed and then we can make a decision without being hypothetical.
21:16:04 <dgilmore> bconoboy: no, what we would ideally want is a list of effected packages
21:16:12 <dgilmore> bconoboy: then we can work out the plan of attack
21:16:13 <pbrobinson> ultimately figures talk and will affect the decision
21:16:24 <dgilmore> pbrobinson: exactly
21:16:25 <pbrobinson> affected packages ;-)
21:16:34 <dgilmore> pbrobinson: :P
21:16:47 <bconoboy> dgilmore: Where's the right place for the package list? arm@lists.fp.o?
21:16:55 <pbrobinson> if it's 500 packages that's achievable, if it's 5000 probably not
21:17:26 <dgilmore> bconoboy: what do you mean by package list?
21:17:34 <pbrobinson> probably somewhere other than the list and then a mail with details, not sure we need a list of 1000s of packages to the list
21:17:34 <bconoboy> dgilmore: list of affected packages
21:17:45 <dgilmore> the discussion should probably be on arm@lists.fp.o
21:18:01 <dgilmore> bconoboy: once we work out a plan of attack we take it to devel@
21:18:07 <bconoboy> I guess the list itself could go on fpaste or similar
21:18:16 <pbrobinson> yep, sounds good
21:18:20 <bconoboy> okay
21:18:29 <pbrobinson> so I'm not sure there's anything to discuss until we have numbers
21:18:40 <bconoboy> #action bconoboy (and co) to come up with list of packages needing aarch64-specific configurey updates
21:19:04 <bconoboy> #info pointer to list to be sent to fedora-arm mailing list where plan of attack will be formed
21:19:05 <dgilmore> bconoboy: where the list goes is less important than the discussion and planing a cource of action
21:19:47 <pbrobinson> agreed, I just don't particularly want a thread with a list of 13K packages in the reply stream
21:20:06 <bconoboy> dgilmore: got it.  we'll find the scope and go from there.
21:20:34 <bconoboy> pwhalen: next
21:20:40 <pwhalen> #topic 3) A15 Kernel support in Fedora
21:21:00 <pwhalen> ctyler ping
21:21:19 <bconoboy> Is this ctyler's topic?
21:21:23 <pbrobinson> a15 lpae support is planned for 3.9 kernel
21:21:28 <pwhalen> yes, doesnt look like hes around
21:21:36 <oatley> pwhalen: ctyler is not at cdot
21:21:42 <masta> a15, aka chromebook?
21:21:52 <bconoboy> It'd be groovy if we moved to a15 vexpress support
21:22:01 <pbrobinson> masta; amongst other things
21:22:21 <pbrobinson> bconoboy: yes, planned for the lpae kernel
21:22:38 <bconoboy> pbrobinson: How long before we see 3.9 kernels show up in rawhide?
21:22:44 <DarthJawa> pwhalen: we have 2 arndales here.
21:23:00 <pbrobinson> LPAE affects other kernels as well (like on i686) so I was planning at least initially to have it there
21:23:40 <pbrobinson> bconoboy: as soon as jonmasters helps me get 3.8 into working shape for all our current users as has been discussed a number of times
21:24:19 <masta> is a15 happy in 3.9?
21:24:50 <pbrobinson> masta: time will tell but I know of people booting them on the exynos5 devices
21:25:18 <pbrobinson> and also the initial KVM support is due to land in 3.9 too
21:25:37 <pbrobinson> and a couple of the virt guys based in the UK have been bothering me about that side of things
21:26:31 <pwhalen> maybe we'll come back to this if ctyler comes on
21:26:46 <pbrobinson> ok move on then
21:26:52 <pwhalen> he was driving, horrible weather here
21:26:53 <bconoboy> #action ctyler to email what this is about
21:26:58 <pwhalen> #topic 4) ARM Tech Talks - suggestions for future talks, volunteers?
21:27:17 <pwhalen> we have an open slot for this week if anyone has an idea they would like to do a talk on
21:27:28 <pbrobinson> as I mentioned on list a JTAG debug techtalk
21:27:41 <pbrobinson> but not this week as mine hasn't arrived yet
21:28:01 <dgilmore> would be useful
21:28:12 <dramsey> :)
21:28:55 <pwhalen> any other ideas on future talks?
21:29:11 <pbrobinson> I've got some ideas for some brewing but I'll be on a plane this week and Friday isn't great for me as I'm usually panicking trying to get off site and travelling
21:29:56 <pwhalen> Chris was also looking at some ideas for the Pi, perhaps a talk on using the gpio
21:30:06 <masta> maybe some talk about making a remix of panda or general LMC usage?
21:30:13 <pbrobinson> gpio++
21:30:56 <pwhalen> ok, please forward any other ideas you may have to the list
21:31:15 <pwhalen> #topic 5) PHX update
21:31:22 <bconoboy> nirik: go!
21:31:23 <pwhalen> ping nirik
21:31:27 <nirik> so, just a few items...
21:31:41 <nirik> hopefully our nets for the rest of the SOC's will be active friday.
21:31:46 <pbrobinson> WOO!
21:31:51 <nirik> I've not gotten confirmation on it, but I am hoping
21:32:19 <nirik> next, we have an outage starting in 30min or so... I was going to update/reboot the hub/db boxes if thats ok with all of you.
21:32:44 <nirik> and finally, one builder has disk/fs errors. I stopped kojid on it, but we should probibly re-install it or something.
21:33:24 <dmarlin> nirik: could it be a physical media problem?
21:33:28 <pbrobinson> if we must I can cope can you let me know before you do it so I can deal with jobs, and again when it's done so I can bring koji-shadow back up?
21:33:47 <nirik> dmarlin: it could be. Not sure fully.
21:34:00 <nirik> pbrobinson: I'm happy to wait for a better time if you like.
21:34:04 <nirik> if you let me know what that time is.
21:34:17 <pbrobinson> nirik: not really a better time with koji-shadow so when ever
21:34:31 <bconoboy> nirik: details on the disk/fs errors?
21:34:39 <pbrobinson> just let me know so I can make some notes before it reboots
21:34:42 <nirik> ok. would it be better at the start of the window, or toward the end (it's 3hr)
21:34:52 <nirik> bconoboy: I can paste the dmesg... just a sec.
21:34:59 <pbrobinson> nirik: there's a kernel build almost finished, that's the major one :)
21:35:16 <pbrobinson> nirik: and that's almost done
21:35:44 <nirik> http://paste.fedoraproject.org/3941/
21:35:48 <nirik> ^ disk errors
21:36:37 <bconoboy> nirik: can you paste the full dmesg?
21:36:45 <masta> ipv6!!
21:36:46 <bconoboy> #info New ARM net *may* be available friday
21:37:04 <nirik> bconoboy: sure.
21:37:50 <nirik> it's got a ton of audit messages in it...
21:38:37 <masta> so the deal is some red tape in RH about ipv4 provisioning, right?
21:39:12 <nirik> masta: yeah. Getting an actual allocated net from the networking folks so we don't stomp on others or make things unmanageable for them
21:39:36 <masta> ok
21:39:48 <nirik> anyhow, I can get the dmesg, it will take some poking as it's larger than my scrollback buffer.
21:39:48 <masta> so is a /23 enough?
21:39:57 <nirik> should be
21:40:12 <pbrobinson> masta: it's end of financial years so there's been a change freeze on so there's not outages of critical infra when sales people need it most </cynical tone off?
21:40:38 <masta> will we grow beyond that? is 510 enough?
21:41:08 <nirik> well, currently we would be using 192.
21:41:37 <pbrobinson> so about 1/3 of the 500 odd addresses so it should do for the moment
21:42:17 <masta> each box is 192, right?
21:42:25 <bconoboy> each box takes 48-72
21:42:46 <bconoboy> Even if we double capacity with aarch64 hosts that's still plenty of room.
21:42:46 <nirik> masta: we are not currently using eth1 on any of them. so eth0 and mgmt
21:43:09 <pbrobinson> nirik: we need extra IPs for newRepo hosts, correct?
21:43:29 <bconoboy> aren't the arm hosts themselves going to be newrepo hosts?
21:43:57 <pbrobinson> yes, but they need a NFS mount which I believe is on a storage segment
21:44:12 <nirik> it should be available via eth0...
21:45:16 <nirik> on primary we do have a seperate storage net, but thats not the setup on that network the arm boxes are on currently
21:45:39 <pbrobinson> OK
21:45:54 <bconoboy> nirik: Are you saying the new arm network segment will have access to the nfs server?
21:45:59 <pbrobinson> I misunderstood from something said the other day then
21:46:15 <nirik> bconoboy: yes, thats my understanding.
21:46:23 <nirik> or if it doesn't we can ask them to allow it.
21:46:52 <bconoboy> ok, cool
21:47:00 <masta> so this is another  vlan?
21:47:18 <masta> sry,  just wondering....
21:47:19 <nirik> hopefully newrepos can work on them... 4GB of memory is a bit tight for them sadly. (although createrepo_c is much better)
21:47:47 <nirik> the boxes don't do vlans from my understanding, so this is just a regular network they would all be on and could reach the storage server
21:48:19 <bconoboy> you could also do a seperate network on eth1
21:48:26 <nirik> yeah.
21:48:26 <masta> ok so interface for frontside, another for storage?
21:48:27 <bconoboy> would burn through more IPs though
21:48:44 <pbrobinson> so would separate vlans on a single eth
21:48:46 <nirik> we could do eth1, but I'm not sure there's any advantage is there?
21:49:08 <pbrobinson> is there anything else on the agenda btw?
21:49:29 <pwhalen> pbrobinson, nothing just open floor after this
21:49:30 * nirik looks at the 1 gige ethernet that comes out of the chassis. If we split that out there might be, but without that... doesn't seem like it would matter.
21:50:12 <bconoboy> let's get that network in place and then discuss again afterward :-)
21:50:25 <masta> ok
21:50:42 <pwhalen> next?
21:50:58 <pwhalen> #topic 6) Open Floor
21:51:20 <pwhalen> anything else for today?
21:51:49 <bconoboy> crickets
21:51:51 * masta working on chromebook stuff
21:52:09 <masta> vboot and keernel srpm
21:52:16 * pbrobinson is living in kernel and koji-shadow :-(
21:52:47 <pbrobinson> masta: I _WILL_ do the review for vboot by the end of the weekend
21:53:01 <masta> so can we host old kernels for chromebook?
21:53:08 <bconoboy> #action pbrobinson will review vboot by the end of the weekend
21:53:12 <masta> 3.4 kernels
21:53:30 <pbrobinson> damn... knew I shouldn't have said that in the meeting ;-)
21:53:38 <bconoboy> you heard it here folks!
21:53:39 <masta> lol
21:54:39 <bconoboy> pwhalen: I think that's it
21:54:41 <masta> so some remix will want to use old kernel, is that cool? (to host on fedora)
21:55:10 <masta> fedora is latest hotness, remix == old hotness
21:55:37 <bconoboy> masta: remix can use anything, ne?
21:56:00 <pwhalen> move to #fedora-arm okay for this?
21:56:13 <masta> sure
21:56:28 <pwhalen> #endmeeting