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