20:00:22 <pwhalen> #startmeeting
20:00:22 <zodbot> Meeting started Wed Oct 24 20:00:22 2012 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:23 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore
20:00:23 <zodbot> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen
20:00:28 <pwhalen> good day all
20:00:32 <pwhalen> .fas pwhalen
20:00:32 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
20:00:40 <jcapik> .fas jcapik
20:00:40 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:00:46 <ahs3> .fas ahs3
20:00:47 * masta waves
20:00:47 <zodbot> ahs3: ahs3 'Al Stone' <ahs3@redhat.com>
20:00:55 <dmarlin> .fas dmarlin
20:00:55 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:01:39 <bconoboy> .fas blc@
20:01:40 <zodbot> bconoboy: blc '' <blc@redhat.com>
20:01:53 * pbrobinson is here
20:02:11 <pwhalen> #topic 1) F18/19 build status - problem packages?
20:02:24 * fossjon is here
20:02:49 <pbrobinson> eclipse is one of the core problems at the moment but is being worked upon
20:02:50 <pwhalen> pbrobinson, anything causing significant grief that needs to be looked at?
20:03:20 <pbrobinson> openmpi seems to be coming higher up the list due to a couple of packages seemingly depending on it now.
20:03:26 * agreene is here
20:03:38 * Frojoe is here
20:03:54 <bconoboy> pbrobinson: this is in f19?
20:04:13 <pbrobinson> for both f18 and rawhide for those two
20:04:21 <bconoboy> ah, okay
20:04:30 <pbrobinson> in rawhide the kernel is blocking again but I'm working on the initial unified kernel so once that lands in the next day or so that should be OK
20:04:33 <bconoboy> we're still above 1400 missing packages on f19.  are these the cause?
20:04:59 <pwhalen> #info eclipse and openmpi current problem packages in F18 and rawhide that need attention
20:05:23 <pbrobinson> it seems there's an issue with java-openjdk with JNI support (whatever that is) but it seems it's only a few packages at the moment so I've filed a bug
20:05:30 <Frojoe> cd
20:05:37 <Frojoe> Whups
20:06:25 <pbrobinson> the 1400 packages I believe are mostly the those two and the kernel. the later should be fixed by COP friday or tomorrow
20:07:04 <pbrobinson> all the top problems I have in the koji-shadow are directly due to those two AFAICT
20:07:05 <bconoboy> pbrobinson: would you like some help checking deeper on what's up with the backlog?
20:07:30 <bconoboy> it just seems like the cause has been changing each week, but the 1400 remains
20:07:41 <pbrobinson> bconoboy: once i get the kernel out of the way it will allow the report to be more granular
20:07:51 <bconoboy> pbrobinson: okay- let me know if I can help
20:08:22 <pbrobinson> well the 1400 has remianed but we're building a lot and keeping up so the target is changing all the time
20:08:42 <pbrobinson> if it was a same core package that was blocking that number would be constantly going up
20:08:59 <bconoboy> y
20:09:11 <pwhalen> #topic 2) Fedora 18 ARM Alpha release - blockers from the last meeting
20:09:33 <pbrobinson> unfortunately I missed eclipse and it hits java which is turn hits anything that has java bindings
20:09:50 <pwhalen> in our last meeting we identified these issues:
20:09:59 <pbrobinson> I think for the alpha we're now looking pretty good
20:10:02 <pwhalen> 1) Highbank kernel panic 2) xfce testing on the Panda (fix if needed) 3) SE Linux settings being ignored in the kickstart
20:10:22 <pbrobinson> 2) I think is close to being closed
20:10:47 <pbrobinson> we have X working with the omap X driver with a slight work around of a xorg.conf snippet
20:11:03 <masta> but we need selinux to be enforcing, right?
20:11:05 <dmarlin> I tested the 3.6.3-2 kernel on highbank and it works, but is not being released (IIUC)
20:11:27 <pbrobinson> what do you mean by "not being released"?
20:11:35 <dmarlin> masta: define "need"
20:12:09 <masta> dmarlin: welp.. isn't that the default in PA?
20:12:10 <pbrobinson> dmarlin: it's a core mainline release requirement so it needs to be enforcing
20:12:11 <dmarlin> pbrobinson: dgilmore said it was not going to hit the repos, but a newer one would
20:12:46 <masta> dmarlin: not sure if selinux is a line item on our alpha go/no-go list?
20:13:11 <pbrobinson> it is
20:13:30 <dmarlin> where's the list (link)?
20:14:12 <pwhalen> #link F18 Alpha release criteria https://fedoraproject.org/wiki/Architectures/ARM/Fedora_18_Alpha_Release_Criteria
20:14:19 <masta> perhaps a post snippet in kistarts to touch the neato /.autorelabel ?
20:14:28 <pbrobinson> in the fedora wiki somewhere under release requirements (I'm  shit at searching the wiki)
20:14:59 <dmarlin> masta: that's what I'm doing now, but that doesn't fix the issue (kickstart settings being ignored)
20:15:41 <dmarlin> pbrobinson: O don't see it at that link
20:15:51 <dmarlin> s/O/I/
20:15:55 <pwhalen> the arm release criteria is from the PA release criteria, but I dont see selinux there (on either)
20:16:18 <pbrobinson> dmarlin: are we still using a barstardised f17/f18 anaconda/lorax for the build creation?
20:16:21 <pwhalen> #link PA Alpha release criteria http://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
20:16:29 <dmarlin> pbrobinson: yep
20:16:45 <dmarlin> pbrobinson: until F18 is fully functional
20:17:21 <dmarlin> pbrobinson: my understanding is that the anaconda guys are working on it
20:17:37 <dmarlin> pbrobinson: but have higher priorities right now (PA issues)
20:17:46 * pbrobinson is just trying to find  the selinux bit
20:18:09 <bconoboy> features we need for image creation won't be available in live media creator until f19
20:18:14 <pbrobinson> and I'm aware of the PA issues, it wasn't a blame thing it was purely a question
20:18:43 <masta> we should be enforcing, but i personally don't like that... but for the  sake of following PA.. we should
20:19:01 <masta> sucks...
20:19:14 <dmarlin> masta: define _should_ (as in why?  where is it specified)
20:20:10 <pbrobinson> dmarlin: that discussion isn't part of this meeting
20:20:18 <masta> because we want to reduce the things that people would look at  when we promote to PA
20:20:42 <dmarlin> anyway, currently due to some broken package, all images are created using enforcing, so is it really an issue
20:20:54 <dmarlin> pbrobinson: if it's a blocker, it is definitely part of this meeting
20:22:08 <pbrobinson> dmarlin: selinux not working is. the definition of why it's there and whether or not it _should_ be there is not
20:22:24 <masta> well if enforcing is not listed as blocker, then...
20:22:31 <dmarlin> masta: right
20:22:40 <jcapik> masta: +1
20:22:50 <pwhalen> the images we're producing are in enforcing
20:23:11 <dmarlin> pwhalen: and we have a workaround to make them boot/login
20:23:22 <dmarlin> pwhalen: at least for alpha
20:23:28 <pbrobinson> so the images are in "enforcing" mode but the problem is that the filesystem needs to be relabelled before it will work?
20:23:37 <dmarlin> pbrobinson: yes
20:23:44 <pwhalen> right
20:23:54 <masta> yes
20:23:57 <pbrobinson> so can we run a relabel in the %post section of the kickstart?
20:24:12 <dmarlin> pbrobinson: that's what we are doing (as I posted earlier)
20:24:12 <pbrobinson> as a work around
20:24:17 <masta> no.. likely has to be on firstboot
20:24:39 <dmarlin> masta: it works now
20:24:41 <pbrobinson> masta: why no? should be doable in the chroot?
20:24:46 <masta> correct if wrong... can a relabel work in a chroot, in anaconda?
20:25:02 <dmarlin> masta: it works when we boot the system
20:25:24 <dmarlin> masta: we set it in %post
20:25:27 <pbrobinson> dmarlin: so what was done to make that work?
20:25:34 <masta> ok, so what is the mre better idea, relabel durring anaconda post, or on first boot?
20:26:02 <dmarlin> is discussing better approaches part of the meeting, or just the criteral?
20:26:13 <pwhalen> if we can do it in anaconda great, but I think for our alpha on first boot could be acceptable?
20:26:29 <pwhalen> as its working and is tested
20:26:40 <pbrobinson> if it's working now in %post I think we should do it there.
20:26:53 <masta> dmarlin: sry if i'm off topic , my bad
20:26:59 <pbrobinson> the reason being is that it's then known good before we ship the images
20:27:16 <dmarlin> masta: no, just need to move on... other topics to hash out
20:27:25 <pbrobinson> if it's done in first boot it could fail for reasons out of our control with users
20:27:50 <dmarlin> we are doing other more invasive things on first boot (like resizing the rootfs)
20:27:58 <pwhalen> perhaps make that a beta requirement then? Make note of it in release notes?
20:27:59 <masta> yep, for now let's just get the alpha out, and it's enforcing with .autorelabel so this is all moot
20:28:21 <pbrobinson> pwhalen: make what specifically a beta requirement
20:28:39 <masta> oh that brings a good point.
20:28:45 <pwhalen> the attempt to address this in anaconda, or prior to first boot
20:28:54 <dmarlin> I'd prefer to make it a GA requirement, in case we can't get it fixed before beta
20:29:05 <dmarlin> try for beta, but not block on it
20:29:09 <masta> if ctyler were here we could ask him to fix the resize script
20:29:10 <pbrobinson> so the .autorelabel works OK even if it's slow?
20:29:16 <pwhalen> +1
20:29:31 <dmarlin> pbrobinson: it has worked for us so far
20:29:36 <pwhalen> it does, very slow on qemu, but reasonable on Panda and Trimslice
20:29:54 <masta> it works  fine
20:30:10 <pbrobinson> dmarlin: I would prefer it to be a beta and not a GA blocker, it's quite major and major if it goes wrong. GA blockers should be for minor polish
20:30:36 <dmarlin> pbrobinson: if you think it will be fixed by then, ok
20:30:41 <masta> major? it's likely a trivial thing
20:30:53 <dmarlin> masta: that was my thought
20:31:12 <masta> we have two way to solve....
20:31:28 <masta> we are on one of the ways now... .autorelabel
20:31:33 <masta> works
20:31:38 <pbrobinson> masta: trivial is a specific device not working not issues on every image we ship
20:32:50 * masta bows before pbrobinson in the device drivers, but this is trivial user space
20:32:54 <dmarlin> masta: the images should be correctly created with no need to relabel, but using F17 tools on f18 packages... who knows if it will ever work.
20:33:22 <pbrobinson> masta: but if selinux causes problems it's not trivial....
20:33:27 <dmarlin> masta: the problem should go away once the f18 tools are complete
20:33:40 <pwhalen> so we have fixes and solutions for omap and selinux.. back to the highbank kernel?
20:33:46 <pbrobinson> anyway beta or GA discussion can happen later
20:33:56 <pbrobinson> I think we have a reasonable work around for alpha
20:33:59 <pwhalen> not sure I saw which kernel would be released
20:34:04 <masta> problem complexity is low, the root cause is anaconda... those guys are busy... for now we work around with one of two ways we have talked about
20:34:50 <masta> even if the problem were solved in anaconda we have said that enforcing is "nice to have" so there we are.
20:35:00 <pbrobinson> masta: do we know categorically the problem is anaconda.... or is anaconda masking or being blamed for an underlying issue.... ?
20:35:27 <pbrobinson> but back to the alpha
20:35:35 <dmarlin> pbrobinson: we don't know at this point
20:35:58 <pbrobinson> exactly and hence not trivial.... moving on....
20:36:00 <masta> pbrobinson: ok I'll take an action item away here to run  this down... anaconda... i'll harrase them
20:36:02 <pbrobinson> pwhalen: so what's the kernel issue
20:36:02 <dmarlin> pbrobinson: we just know the images require relabel before they work with selinux enforcing
20:36:10 <dmarlin> we need a kernel in the repos that will work on highbank, dgilmore said 3.6.3-2 will not be there, unless we manually push it (sign it)
20:36:52 <dmarlin> we also know that the current misalignment patch will not go upstream.  russell king has one that will (likely)
20:37:03 <dmarlin> but that will take time...
20:37:19 <dmarlin> so, we need to decide what kernel to push and get it in the repos
20:37:48 <dmarlin> once in the repos, we can spin images to test
20:38:16 <pbrobinson> I can take that as an action item
20:38:22 <bconoboy> what is the action?
20:38:25 <pbrobinson> is the 3.6.3-2 kernel working on highbank?
20:38:33 <pwhalen> it is
20:38:33 <dmarlin> pbrobinson: yes
20:38:34 <pbrobinson> deciding the kernel
20:39:06 <pwhalen> I believe we also discussed a lookaside repo for the kernel if need be?
20:39:15 <masta> can somebody in a chair action me to run down seliux/anaconda plz ?
20:39:20 <pbrobinson> so as it stands at the moment any 3.6.3-X kernel that makes mainline will have the same patch set which currently includes the non upstream patch
20:39:35 <bconoboy> #action masta to track down selinux/anaconda problem
20:40:10 <pbrobinson> as I'm dealing with the kernel I can make sure we get an appropriate one tagged
20:40:22 <dmarlin> pbrobinson: cool
20:40:48 <bconoboy> #action pbrobinson to pick the kernel version for alpha release, tag and push
20:41:17 <pwhalen> when are we aiming for?
20:41:17 <pbrobinson> In fact there's this kernel there https://admin.fedoraproject.org/updates/FEDORA-2012-16787/kernel-3.6.3-3.fc18
20:41:58 <masta> we test highbank in qemu?
20:42:03 <pbrobinson> I'll review that change set and if it looks OK I'll make sure it's built and we should be good to go
20:42:05 <dmarlin> if we get it built for arm, we can test it
20:42:16 <dmarlin> pbrobinson: +1
20:42:54 <pwhalen> so we're looking at a possible vfad at the earliest friday? (our next topic)
20:43:01 <pbrobinson> masta: we tested highbank in qemu in the past before we had real hardware. It should still work but I don't see it as a blocker
20:43:04 <masta> what is the test for highbank? it boots, or it doesn't crash after some runtime length, or specific use case?
20:43:11 <pbrobinson> or even a criteria
20:43:30 <dmarlin> masta: we test it like other platforms
20:43:38 <pbrobinson> masta: that it boots and mostly works
20:43:50 <masta> ack
20:43:58 <pbrobinson> it doesn't have GPU so graphics isn't tested etc
20:44:17 <dmarlin> pbrobinson: I haven't used highbank qemu since we got access to hardware
20:44:25 <dmarlin> pbrobinson: not sure about it's status
20:44:45 <dmarlin> pbrobinson: I know it was broken for a while (when the kernel changed to 3.5)
20:45:06 * pbrobinson doesn't personally care about it
20:45:15 * dmarlin either
20:45:26 <masta> ok, so we have people with access to the hardware that an test, provide go/no-go... or  did the hardware go away?
20:45:37 <masta> s/an/can/
20:45:40 <pwhalen> #topic 3) F18 ARM Alpha VFAD - dependent on the kernel
20:45:45 <dmarlin> masta: we have access to hardware
20:45:50 <masta> ya
20:45:55 <dmarlin> pwhalen: on moment...
20:46:15 <dmarlin> bconoboy: any feedback on rootfs-resize, or have you had time to check yet?
20:46:16 <pwhalen> #undo
20:46:16 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x120ade50>
20:46:28 <dmarlin> bconoboy: not a blocker, but would be nice to have
20:46:36 <dmarlin> (functional)
20:47:44 <bconoboy> dmarlin: rootfs-resize- ctyler said he would try to get to it today, but maybe not till saturday.
20:47:53 <dmarlin> bconoboy: that's too late
20:48:02 <bconoboy> dmarlin: that's what I said, so he's going to try for today.
20:48:03 <masta> do we need somebody else to take over root-resize? owned by ctyler i believe, i'd love to co-own it.... want to get into packaging anyhow
20:48:08 <pwhalen> at worst we could put it in a lookaside?
20:48:16 <bconoboy> it's in a lookaside
20:48:25 <pbrobinson> what needs to be done?
20:48:34 <dmarlin> bconoboy: yes, but an unofficial lookaside
20:48:43 <bconoboy> pbrobinson: it needs to have some patches applied and be rebuilt.
20:48:51 <jcapik> I could also comaintain ....
20:48:52 <masta> if all else fails we can edit wiki  with steps to resize
20:49:04 <pbrobinson> oh christ that takes 5 minutes.... why does it take so long?
20:49:15 <jcapik> since I did the review :]
20:49:18 <pbrobinson> are the patches somewhere?
20:49:25 <dmarlin> pbrobinson: attached to the BZ
20:49:54 <masta> jcapik: +1
20:50:03 <pbrobinson> what is that, I don't remember, if I ever did. Can someone reference it for the meeting notes and I'll push the patches npw
20:50:05 <pbrobinson> now
20:50:20 <bconoboy> dmarlin: Bz#?
20:50:43 <dmarlin> bconoboy: the one I posted before... looking...
20:51:21 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=837111
20:51:25 * masta does not want to block on Seneca, no bad feelings.... just at this time we have to  be more agile
20:51:31 <pbrobinson> dmarlin: I have around 300 RHBZ in my fedora account and doesn't count my other accounts. I look at dozens every day so it's hard to remember them all :-D
20:51:36 <dmarlin> https://bugzilla.redhat.com/show_bug.cgi?id=837111
20:52:06 <masta> not that the resize is a blocker... but  major nice to have
20:52:22 <dmarlin> definitely not a blocker
20:52:25 <pbrobinson> dmarlin: so just the patch from you in comment 5?
20:52:38 <dmarlin> yes
20:53:13 <pbrobinson> will apply after this meeting and push
20:53:18 <dmarlin> pbrobinson: thank you
20:53:20 <pwhalen> #action pbrobinson to push rootfs-resize patch from dmarlin
20:53:26 <pwhalen> thanks pbrobinson
20:53:44 <pwhalen> anything else for F18 alpha?
20:54:21 * pbrobinson doesn't think so
20:54:22 <pwhalen> #topic 3) F18 ARM Alpha VFAD
20:54:58 <masta> tuesdays have been popular
20:55:04 <pwhalen> provided we get a kernel build going asap, then images I think its perhaps safest to attempt the vfad for Monday?
20:55:14 <bconoboy> prefer friday
20:55:28 <dmarlin> bconoboy: can the kernel be ready before then?
20:55:32 <masta> the sooner the better
20:55:34 <pwhalen> would be tight but doable if the kernel gets built asap
20:55:35 <bconoboy> dunno- how long does it take to build?
20:55:50 <pbrobinson> not long on appropriate builders
20:55:54 <bconoboy> we can make sure it gets put on the right builder
20:56:03 <pbrobinson> yep
20:56:12 <pwhalen> 16 hours-ish
20:56:13 <masta> ~5 hours kernel build
20:56:30 <bconoboy> okay, so conceivably if it starts building later today it'll be ready to rock tomorrow morning
20:56:34 <bconoboy> (us time)
20:57:19 <pbrobinson> and then be composed and mirrored out
20:57:34 <dmarlin> bconoboy: if we sync the repos locally (when the kernel is there) I can make the flash images in 3-4 hours
20:57:35 * masta seems to recall new kernels being enabled, samsung soc's
20:57:53 <pbrobinson> there's no samsung support
20:58:08 <masta> dgilmore: mentioned that
20:58:11 <bconoboy> pbrobinson: So, you have the kernel action, is that something you can do tonight or tomorrow?
20:58:39 <pbrobinson> there was a couple of patches added to make it easier for someone to build samsung kernels but only to f17
20:58:56 <pbrobinson> depends on how much longer this meeting goes on for :-D
20:58:59 * dmarlin wonders how late it is for pbrobinson already
20:59:04 <bconoboy> assuming it wraps up in 2 minutes...
20:59:10 <pbrobinson> it's midnight in helsinki
20:59:10 <pwhalen> then we should wrap it up :)
20:59:18 <dmarlin> +1
20:59:20 <masta> +1
20:59:36 <pbrobinson> I was going to push the resize fix and check the kernel
20:59:39 <pwhalen> okay, so provided we have a kernel, vfad Friday?
20:59:47 <pbrobinson> so it should be building shortly
20:59:57 <dmarlin> thank you pbrobinson
21:00:20 <jcapik> thx
21:00:33 <dmarlin> pwhalen: not sure how long it takes to get the compose pushed to the mirrors
21:00:35 <pbrobinson> I'm travelling Friday afternoon my time so morning your time but I'm not a blocker anyway
21:01:00 <masta> idea vfad friday?
21:01:15 <pwhalen> provided we have what we need, I will send an email tomorrow for a vfad friday
21:01:19 <pbrobinson> if the kernel is done in reasonable time tomorrow it will be in tomorrow's compose
21:01:30 <dmarlin> excellent!
21:01:32 <bconoboy> \o/
21:01:51 <pbrobinson> a side note for all....
21:02:01 <pbrobinson> I got a first unified kernel built
21:02:15 <pbrobinson> It has issues as I suspected it would
21:02:46 <pbrobinson> but I'm merging in the rest of the bits and should push the config bits to mainline soonish
21:02:55 <bconoboy> should we bother testing it?
21:03:01 <pwhalen> #agreed Tentative agreement - F18 ARM alpha VFAD to be held on Friday October 26th - provided new kernel build, images created
21:03:20 <pwhalen> #action pwhalen to send VFAD email to the fedora-arm list
21:03:51 <pbrobinson> no, I would wait for v2
21:04:03 <bconoboy> ok
21:04:12 <pwhalen> bconoboy, I tested the kernel on vexpress and highbank. Both have issues
21:04:19 <masta> i'll be happy to vfad anytime
21:04:40 <pwhalen> so if for some reason we can't do a vfad on friday, we'll do one Monday
21:04:41 <bconoboy> pwhalen: bummer.  fdt related?
21:05:12 <pwhalen> highbank had an overlap problem with the kernel and initrd, similar to the qemu issue I provided a patch for
21:05:19 <dmarlin> are we done here?   back to #fedora-arm?
21:05:23 <bconoboy> think so
21:05:29 <pwhalen> and I think vexpress needed an option added to the config
21:05:41 <masta> done
21:05:46 <pwhalen> #endmeeting