16:00:59 #startmeeting f19alpha-blocker-review-7 16:00:59 Meeting started Mon Apr 15 16:00:59 2013 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:59 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:00 #meetingname f19alpha-blocker-review-7 16:01:00 The meeting name has been set to 'f19alpha-blocker-review-7' 16:01:00 #topic Roll Call 16:01:05 Who all's 16:01:09 yay blocker review! it's my favourite time of the day 16:01:13 here for some blocker review fun time? 16:01:24 well, my second favourite, right after Blackout Drinking O'Clock 16:01:51 * satellit_e still listening 16:01:53 one follows the other, I assume? 16:02:04 inspires, rather 16:02:05 * jreznik just got a call to come home asap to have an icecream - sounds like better offer than blocker review fun! 16:02:30 * pschindl is here 16:02:35 tflink: =) 16:02:43 jreznik: now that's just crazy talk 16:02:52 jreznik: oh, you go. you eat that ice cream. but remember, it may be THE LAST ICE CREAM YOU EVER EAT 16:04:26 it would be nice death :) 16:04:31 * jreznik is dreaming 16:04:52 anyhow, I suppose we're ready to get this party started 16:05:02 #topic Introduction 16:05:08 Why are we here? 16:05:08 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 16:05:16 #info We'll be following the process outlined at: 16:05:16 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:05:17 * brunowolff is here (but also doing work stuff) 16:05:22 #info The bugs up for review today are available at: 16:05:23 #link http://qa.fedoraproject.org/blockerbugs/current 16:05:30 #info The criteria for release blocking bugs can be found at: 16:05:30 #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria 16:05:36 #info Up for review today, we have: 16:05:44 #info 3 Proposed Blockers 16:05:44 #info 3 Accepted Blockers 16:05:45 #info 10 Proposed Freeze Exceptions 16:05:45 #info 9 Accepted Freeze Exceptions 16:06:20 is our blocker bug process broken? there are way to little reports there ;) 16:06:39 alpha has been relatively solid 16:06:57 if there are no objections, lets start with the proposed blockers 16:07:00 either that, or it blew up people's computers so badly they couldn't report anything. 16:07:08 #topic (927564) F19 release-name “Schrödinger’s Cat” shown as "SchrA¶dingerâÇÖs Cat" on the linux console 16:07:11 #link https://bugzilla.redhat.com/show_bug.cgi?id=927564 16:07:13 #info Proposed Blocker, anaconda, NEW 16:07:59 Hm thought this was supposed to be fixed already 16:08:36 -1 16:08:44 -1 16:08:53 -1 16:08:55 -1 16:08:55 okay, good catch on the criterion, but the intent is to prevent people being confused about what they're running 16:09:02 even though bob is technically correct 16:09:08 it looks a little wacky as things are, but it doesn't make you think you're running f18 16:09:14 yeah 16:09:45 adamw: yep, I think it was an intention - so the wording should be different or be less pedantic for alpha/beta? 16:09:55 maybe we need to tweak the criterion a little, this kind of situation didn't occur to us when drafting it 16:10:02 jreznik: right, i'll see if I can come up with something 16:10:20 tflink: can we get some chairs? 16:10:54 proposed #agreed 927564 - RejectedBlocker - While this could be interpreted as a F19 alpha criteria violation, the intention of the criteria was to eliminate possible confusion between releases which is not the case here. Thus rejected as a release blocking issue for F19 alpha. 16:10:57 * satellit_e It is not on efi grub 2 16:11:07 #chair adamw jreznik 16:11:08 Current chairs: adamw jreznik tflink 16:11:17 ack 16:11:24 ack 16:11:37 ack 16:11:54 #agreed 927564 - RejectedBlocker - While this could be interpreted as a F19 alpha criteria violation, the intention of the criteria was to eliminate possible confusion between releases which is not the case here. Thus rejected as a release blocking issue for F19 alpha. 16:12:13 #topic (906031) kickstart failure "Error accessing file for config" 16:12:16 #link https://bugzilla.redhat.com/show_bug.cgi?id=906031 16:12:19 #info Proposed Blocker, anaconda, NEW 16:12:48 oh, i'll secretaryalize 16:12:58 adamw: thanks 16:14:48 "ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf" 16:16:03 seems like a few people are hitting this occasionally, with no clear link between the cases... 16:16:17 yeah, doesn't look like there is a root cause yet 16:16:30 what does this file store exactly? 16:16:40 the yum config for anaconda 16:16:40 :P 16:17:26 other than dan's install which has precious few details, one used a dynamic url for the kickstart and the other is using btrfs 16:17:32 i'd tend to -1 just on the basis we clearly have a lot of cases where this *doesn't* happen, or there'd be more red on the matrices 16:17:39 but it'd be nice to have a clear grip 16:17:41 +1 blocker these seems not to be limited to ks installs 16:17:52 but not all that common 16:18:08 -1 because it isn't happening often enough to block alpha for 16:18:28 ah so that's the measurement not happening enough to block these days 16:18:38 other votes? we're currently @ -2/+1 16:19:20 * jreznik would like to see a word from anaconda guys 16:19:22 -1 16:19:28 Viking-Ice: if it was happening with autopart and defaults, I'd be more +1 16:19:48 IIRC, ks is beta and custom partitioning is beta/final depending on the details 16:19:55 tflink, when something as fundamental as this breaks it should be fixed 16:20:10 tflink: jreznik and I pinged #anaconda, no word yet 16:20:14 Viking-Ice: well, define 'breaks'? 16:20:15 Viking-Ice: define "this" 16:20:18 =) 16:20:19 and this is breaking both in ks and from ui 16:20:19 ok, -1, I see a commnent saying "Out of 16 installation only one hit this issue." 16:20:26 we don't know what's broken, and it really doesn't seem to be happening much 16:20:30 but it's custom partitioning and ks 16:20:39 we don't know what dan did for his install 16:20:45 maybe it's related to that chroot bug we hit during f18? 16:21:11 at the very least, we can say that none of the rr 16:21:21 reports are using the graphical installer defaults 16:21:57 (-3/+1) any more votes? 16:22:21 -1 blocker 16:22:29 -4/+1 16:23:21 no feed back from anaconda devs yet 16:23:41 proposed #agreed 906031 - RejectedBlocker - While this does represent several failed installs, it appears as if none of them were using the defaults in the graphical installer and don't appear to be all that common. Thus, rejected as a blocker for F19 alpha. 16:24:00 ack 16:25:32 patch - it can be re-proposed if we get more specifics 16:26:08 proposed #agreed 906031 - RejectedBlocker - While this does represent several failed installs, it appears as if none of them were using the defaults in the graphical installer and don't appear to be all that common. Thus, rejected as a blocker for F19 alpha. Please re-propose if details emerge which would make this more of a release blocking issue. 16:26:13 ack 16:26:17 ack 16:26:23 ack 16:27:16 #agreed 906031 - RejectedBlocker - While this does represent several failed installs, it appears as if none of them were using the defaults in the graphical installer and don't appear to be all that common. Thus, rejected as a blocker for F19 alpha. Please re-propose if details emerge which would make this more of a release blocking issue. 16:27:25 #topic (951761) hangs when loading initramfs on EFI 16:27:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=951761 16:27:25 #info Proposed Blocker, grub2, NEW 16:28:09 ATM, this sounds like a single-system bug 16:28:18 yes, but t.c. makes a good point 16:28:39 with the other UEFI bugs, it's unlikely many/any other testers had made it this far at the point he reported the bug 16:28:58 so there is at least a possibility it'd be widespread. there've been a few successful testers of TC6 since then (satellit), but it'd be nice to have more data 16:29:09 are tester testing this with kvm or real hw 16:29:16 satellit uses real HW 16:29:19 * satellit_e this was RC2 before fix? 16:29:32 Viking-Ice: bare metal, it sounds like (mentions dell EFI) 16:29:32 satellit: it's not the bug that TC6 fixed 16:29:36 see comment #4 16:29:49 punt til wednesday for more testing? 16:29:58 this idiotic comment single-system bugs are not Alpha blockers. 16:30:06 initramfs 95% of the time - could it be hw related issue? 16:30:16 Viking-Ice: it's still very difficult to test UEFI in a VM, it turns out - even with that stuff crobinso posted, there's a limitation of the virtual UEFI firmware which means anaconda can't properly update the EFI boot manager on install, so you can do a UEFI install, but it's very hard to actually trigger the installed system to boot 16:30:21 my macBook i7 is not UEFI 16:30:33 so for right now, most UEFI testing is bare metal 16:30:38 gummiboots works fine here ;) 16:30:53 right, but then you're outside of what we actually need to be testing. 16:31:17 tflink: yeah, if we had to call it right now i'd lean -1, but i think it's best to punt 16:32:01 -1 but follow it closely - not to miss in case it's more widespread with more uefi testing 16:32:11 -1 16:32:42 adamw: yeah, same here 16:33:11 is anyone against punting til wednesday? 16:33:37 can we expect any new info by that time or are we punting just for punt's sake 16:33:50 * jreznik is more to reject it but not to lost track of this one 16:33:53 sure, more people will have tested uefi by then 16:34:00 especially if i'm gonna send out a call for testing 16:34:04 Viking-Ice: I don't think it's unreasonable to hope that we'd have more data by wednesday 16:34:06 adamw: and we can always repropose it 16:34:14 yep 16:34:15 right now we have, i guess, one "fail" and maybe two "passes", which is kinda minimal data 16:34:28 if we have one "fail" and ten "passes", that makes it a lot clearer. or five "fails" and five "passes", or whatever 16:34:34 oh as minimal as the anaconda bug 16:34:51 Viking-Ice: no, we have way more data on that. 16:35:02 adamw: for uefi generally - yes, this one seems at least for me hw related as it behaves randomly (and sometimes it works on that system) 16:35:04 Viking-Ice: any 'pass' result on the install matrix is an indication that bug didn't happen to that install. 16:35:27 Viking-Ice: doesn't apply for this bug, though, as most tests are not UEFI. 16:36:23 we are -2 already more votes? 16:36:36 proposed #agreed 951761 - There is not a whole lot of data on this bug right now, request more UEFI testing and revisit at the next blocker review meeting 16:36:47 +1 punt 16:36:56 3p/-2 16:37:01 any other votes? 16:37:21 +0/3p/-2 to be more specific 16:37:34 i'll ack a punt or a -1. 16:38:17 so it's either sit here hoping for more votes or -1 ... 16:38:23 * tflink doesn't care enough either way 16:38:31 +1 for punt 16:38:34 we punted a lot last cycle for no benefit 16:38:54 so I rather we close and re-open than over-punting for no good reason 16:39:02 Viking-Ice: +1 16:39:06 4p/-2 16:39:15 this is punting for a clear reason, though: we anticipate having more data on wednesday. 16:39:34 if there's no more data on wed, reject 16:39:45 adamw, I anticipated winning the lottery every Wednesday has not happened yet 16:39:54 heh 16:40:03 like i said, i'll ack either way. 16:40:09 Viking-Ice: then stop buying tickets if you don't win this week 16:40:44 we have more flexibility on the punt side, so in the interests of getting this meeting done ... 16:40:53 tflink, and stop my risk investment ;) 16:41:18 punt it but let's not punt it again 16:41:29 punt limit of 1 16:41:32 heh 16:42:03 well, seems like punt is today's lottery winner - let's move (or ack who wants to punt) 16:42:06 so acs to the proposal 16:42:10 ack 16:42:26 proposed #agreed 951761 - RejectedBlocker - The small amount of information available at this time does not indicate that this is wide spread enough to justify blocking f19 alpha. please re-propose if more information turns up after more UEFI testing 16:42:43 ack 16:42:49 tflink appears to be swimming upstream from the rest of us. 16:42:58 :P 16:43:01 but sure, ack, whatever. 16:43:03 I just don't care so muc 16:43:07 much either way 16:43:41 it isn't worth debating more, to be honest - time better spent testing or doing other things 16:43:59 yeah, icecream, move on! 16:44:04 the punt votes are already in 16:44:22 tflink: pick one of the proposeds and go with it 16:44:24 ack if you insist 16:44:41 proposed #agreed 951761 - There is not a whole lot of data on this bug right now, request more UEFI testing and revisit at the next blocker review meeting. If there is no more information available at that time, will reject as a blocker for F19 alpha. 16:44:47 #agreed 951761 - There is not a whole lot of data on this bug right now, request more UEFI testing and revisit at the next blocker review meeting. If there is no more information available at that time, will reject as a blocker for F19 alpha. 16:44:54 forgot to remove the proposed 16:44:58 ack 16:45:00 grr 16:45:02 next thing! 16:45:38 on to proposed FEs that aren't sitting @ new 16:46:32 #topic (949002) anaconda crashes while trying to select wireless network 16:46:35 #link https://bugzilla.redhat.com/show_bug.cgi?id=949002 16:46:37 #info Proposed Freeze Exceptions, anaconda, POST 16:46:52 this has a patch but that patch seems mostly untested 16:47:33 i think this is probably a bit late now 16:47:40 yep 16:47:43 agreed 16:47:45 if a fix had showed up a day after I proposed it that'd be one thing, but not right now 16:48:00 yeah, I'm definitely not +1 on this 16:48:56 proposed #agreed 949002 - RejectedFreezeException - This is not a huge problem and it's too late to be considering a yet untested fix to anaconda. Thus, rejected as a FreezeException for F19 alpha 16:49:08 ack 16:49:09 ack 16:49:11 ack 16:49:11 ack 16:49:21 #agreed 949002 - RejectedFreezeException - This is not a huge problem and it's too late to be considering a yet untested fix to anaconda. Thus, rejected as a FreezeException for F19 alpha 16:49:37 #topic (951276) "ValueError: invalid target size request" when selecting preinstalled NTFS partition in custom partitioning 16:49:40 #link https://bugzilla.redhat.com/show_bug.cgi?id=951276 16:49:42 #info Proposed Freeze Exceptions, anaconda, POST 16:50:18 kinda the same really 16:50:26 it's been set to POST, but absolutely no info on the patch or testing, it seems 16:50:41 -1 16:50:44 https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-April/003794.html is the patch 16:50:49 yeah but no comments on dev not able to repro either 16:51:11 and this one would touch partitioning... 16:51:16 hrm, that looks like a trivial patch 16:51:27 famous last words ;) 16:51:33 =)_ 16:51:40 yeah, I know 16:51:42 -1 16:51:52 yeah, i think -1 for safety here 16:52:04 I'd say -1 unless we end up slipping again on wed 16:52:06 -1 16:52:27 tflink: yep 16:53:38 proposed #agreed 951276 - RejectedFreezeException - While this appears to be a simple fix, the risk of taking this fix this late was deemed too high and thus rejected as FreezeException for F19 alpha. Please re-propose if F19 alpha ends up slipping again. 16:53:46 ack 16:54:00 ack 16:54:13 come to think of it, if we're mostly of the mind that we'd take it if we somehow end up slipping again, would it be better to just leave it alone? 16:54:14 ack 16:54:22 either way is fine by me, though 16:54:56 It might get some more testing before we'd make the final decision of whether to FE it. 16:54:58 I was actually wondering if the reporter should be the one that re-proposes it 16:55:29 well, we don't need to burn that bridge right now 16:55:32 since it's us ( as in those that made the decision to reject ) that should just keep tap on it 16:56:32 Viking-Ice: yeah, I wasn't trying to suggest that the reporter keep tabs on whether or not alpha is GO this week 16:56:49 any naks? 16:57:20 ack 16:57:31 #agreed 951276 - RejectedFreezeException - While this appears to be a simple fix, the risk of taking this fix this late was deemed too high and thus rejected as FreezeException for F19 alpha. Please re-propose if F19 alpha ends up slipping again. 16:57:40 #topic (951225) gnome-session doesn't start on ppc64 due to missing support for swrastc 16:57:43 #link https://bugzilla.redhat.com/show_bug.cgi?id=951225 16:57:46 #info Proposed Freeze Exceptions, gnome-session, MODIFIED 16:58:02 do we care about ppc64 16:58:25 dgilmore says this is how we've done it before 16:58:26 we already accepted a few last time 16:58:38 this can be fixed via update right 16:58:41 i don't honestly recall it, but... 16:59:01 * tflink is -1 w/o more information on what actually changed 16:59:04 it's exactly the same patch as already is in f18 16:59:07 well it makes sense to accept sec archs as freeze exception same we do it for non blocking desktops 16:59:14 it just hadn't been applied to f19 16:59:28 jreznik: it doesn't exactly 'make sense', i wouldn't say 16:59:31 so it's tested 16:59:32 jreznik: except for that secarch aren't held to the same release date 16:59:46 if it's already in use on GA let's pull it in 16:59:47 jreznik: famous last words ... 16:59:54 jreznik: if we patch lxdm, then really the worst thing that can happen is we break LXDE. which isn't a major problem. 17:00:00 ? 17:00:06 oh 17:00:09 jreznik: if we patch GNOME for an issue in a secondary arch, we have the risk that we break it for a primary arch. 17:00:17 that risk does not apply to the case where we patch a non-blocking component. 17:00:20 tflink: well, that's the reason why they proposed it as freeze exception - they want to be in sync with primary 17:00:23 does anyone care about the debranders these days? 17:00:26 And the consequences of it breaking can be worse if it is broken on an install image rather than an update. 17:00:35 it's also the only thing preventing g-s on ppc64 working, and it can have _zero_ impact on primary arch since we don't build swrastc on primary 17:00:46 ajax: see "famous last words" above =) 17:00:48 I think this is the same as the last one - take it if we slip again 17:00:49 so adding it to the whitelist will just not matter 17:01:30 ajax: blowing on stuff lightly has been known to make it break before. sod's law says just doing a straight rebuild without a single code change can break stuff. i'm sure that's happened...:) 17:01:54 I'd say the same thing if a non-primary DE required some fix to glibc or pygobject etc. 17:02:07 right, that's the key difference here 17:02:26 i think we probably need to discuss this whole 'what to do with secondary arch specific fixes' thing at a higher level, but for now i'd tend -1 on this 17:02:48 one countering factor is we _do_ have a bit of time to play with 17:02:55 if we slip again, I'd probably be OK with taking it that same day - as long as we had enough time to retest after backing out the change IF it did happen to break something 17:02:56 -1 FE unless we slip. 17:03:07 if we get the kernel fix today, we do have time to do a build tonight and then do another tomorrow that backs out something that turned out to be a problem 17:03:20 well, then we can skip all proposed FEs now 17:03:37 jreznik: not really. it's a cost/benefit. the benefit here is quite small. 17:04:09 this is fixable via update right or "network" install 17:04:09 i particularly want to hit https://bugzilla.redhat.com/show_bug.cgi?id=950510 . 17:04:24 Viking-Ice: well sure, but it's a GNOME showstopper, so you need to do your update from a console or some other DE. 17:04:35 that's not a state we'd accept for the primary arches. 17:04:57 primary desktop for secondary arch... that's the question 17:05:18 adamw, what do you think he is doing there on the ppc64 17:05:24 we have to accept it as a exceptioon 17:05:27 I see -3, not sure how many +1s we have. at least +1 from viking 17:05:35 dgilmore: why do we have to? 17:05:37 if it breaks things on primar y they will break via an update aslo 17:05:51 updates can be squelched easily. release images can't. 17:05:59 adamw: because its not something that would be acceptable on primary 17:06:08 its blocking the secondary arch 17:06:16 it will get pushed as an update 17:06:22 yes. that doesn't make it a freeze exception according to any policy i'm aware of. 17:06:40 an automatic freeze exception, anyways 17:06:43 i'm sure in the past we just let secondary arch builds pull in different packages where necessary 17:06:48 adamw: it violates the desktop must be functional rule 17:06:52 i really don't recall us taking these 'secondary arch NTH' bugs for previous releases 17:07:08 adamw: we really have not allowed it 17:07:22 and the tooling has gotten stricter about enforcing sameness 17:07:40 well, i'd rather we fit tooling to policy than policy to tooling. 17:08:22 adamw: the policy is that they are supposed to be the same 17:08:23 if you ignore tooling limitations, it seems theoretically safer to allow secondary arch builds to pull in different packages where appropriate than to risk primary arch builds unnecessarily. 17:08:34 what policy is this exactly? 17:08:38 * jreznik tends to be generally in support for FEs for secondary archs, this one seems to be pretty well tested on F18, with the risk - I'm 0 17:08:58 proposed #agreed 951225 - RejectedFreezeException - While this is unfortunate for gnome on PPC, the risk to primary of taking a gnome fix this late was deemed too high and thus, this is rejected as a FreezeException for F19 alpha. If we end up slipping F19 alpha again this week, re-propose as FE. 17:09:23 ack 17:09:27 tflink: well, i'd rather we get on the same page with releng... 17:10:04 make up your mind people 17:10:29 https://fedoraproject.org/wiki/Architectures#Divergence_from_Primary_Architectures 17:10:40 adamw: for me i want them to all be the same 17:11:03 dgilmore: but why does it have to be pulled in right now? 17:11:07 adamw: as we are getting better tooling for secondary arches they are getting to be much much closer 17:11:13 that seems to be a general packaging policy, it doesn't say anything specific about exactly what builds should be in pre-release / release images for each arch. 17:11:57 well technically we should be working toward one policy for all on both sides ( qa/releng ) in anycase ack or nack people 17:11:58 I'm not arguing about the fix or that it shouldn't be pulled in, just that changing primary right now is too risky - either do it after we release F19 alpha or we'll take it right after declaring a slip (if that happens) 17:12:00 adamw: maybe not but its true also of pre-release / release images 17:12:01 tflink: i think dgilmore wants to have the secondary arch alpha images built from the exact same package set as primary arch. 17:12:16 adamw: i really do 17:12:16 ah, ok 17:12:40 though i suspect that arm at least will need a newer kernel 17:12:45 which, I mean, I can see, but we kinda should've worked it out in advance. 17:13:03 adamw: i beleived it was worked out 17:13:16 in that secondary arche blockers were primary NTH 17:13:21 smoke images with the new packages, then? 17:13:25 i don't recall that ever being discussed. 17:13:36 maybe it was all in my mind 17:13:48 and nth doesn't mean that it has to be pulled in, anyways 17:13:52 but thats the principle ove always worked on 17:13:59 tflink: right 17:14:30 * Viking-Ice goes out side smoking until you guys/gals figure this out 17:14:30 dgilmore: https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process#Freeze_exception_bug_principles talks about the 'non-default desktop blockers are FE' case, but says nothing at all about secondary arches. 17:15:00 dgilmore: as I said, I agree with it and I like the idea 17:15:26 if releng is really hot on this i could go +1 for this particular bug 17:15:44 but we should figure out how we want to handle this stuff in the future 17:15:50 as it is a pretty safe change, sod's law notwithstanding, and i kinda wanted to do the 'adventurous rc3 with an option for rc4' plan anyhow 17:15:53 yes 17:16:38 I'm not -1 enough to fight all that much but I also don't want to set any precident - taking gnome fixes this late is risky in general 17:17:24 could we spin quick smoke image just to boot to gnome with this one? nothing more 17:18:05 we really don't have to pull it in in case it will fail horribly for smoke 17:18:16 i really want to avoid too much smokeage 17:18:24 but sure, i guess 17:18:59 * dwa is +1 for this but is very biased ;-) 17:19:04 I'll play the devils advocate here and point out that two people have filed -karma for the mesa update you are talking about 17:19:17 kalev: this isn't a mesa update 17:19:24 can we re-vote on this? I got lost in all the discussion 17:19:27 ahh, fair enough, never mind me then. 17:19:37 it sounds like we're mostly +1 FE 17:19:39 (I don't think) 17:19:39 with smoke, I'm +1 17:19:50 reluctant +1 17:20:17 Based on RE thinking this is important, I'm a +1 17:20:51 and of course +1 for tflink's (to discuss it) and +1 for dgilmore's proposal of primary blockers being freeze exception for secondary (and yeah, we have to sort out what to do in case it's too risky - how much sec arch can diverge in the worst case) 17:21:00 kalev: it's just a gnome-session build with a change to the whitelist 17:21:01 reluctant +1 on just this bug, this is not a tacit acceptance of secondary arch == primary FE from me 17:21:23 noted :) 17:21:28 than that's we can discuss the rest later 17:21:35 settled 17:21:49 jreznik: adamw: tflink: if you do have a discussion about secondary arch blocker = primary arch FE please include me. fwiw, we (secondary) always try to have our specific fixes be as minimal as possible. 17:21:58 adamw: ahh, not much that can go wrong with the gnome-session build, if you verify that the acceleration detection isn't completely broken on primary 17:23:00 proposed #agreed 951225 - AcceptedFreezeException - This seems to be a relatively minor fix and was requested by releng to keep the package sets in sync, so accepted as FreezeException for F19 alpha. 17:23:00 Right, but squeezing in a second build and getting tested before Go/No-Go is getting very tight. 17:23:03 dwa: ok, maybe it's even time to take a look on how we do sec arches in more details... OT here, let's move 17:23:05 ack 17:23:22 ack 17:23:49 * jreznik would patch it to require smoke testing before pulling it in 17:24:19 other thoughts on requiring smoke testing? 17:24:28 Would the smoke test really hit much quicker than the next rc? 17:24:36 meh. like i said, i was kinda planning on rc3 being a 'smoke test'. but it won't hurt. 17:24:43 not at all, I haven't gotten set up for smoke building yet 17:24:54 tflink, adamw: then ok, skip it 17:24:56 well, we don't know exactly when we'll get the EFI fix, though it sounds positive. 17:25:05 which I need to do, but it's going to take a little while 17:25:11 i can do a live image easily ernough 17:25:20 i'll do that after the meeting 17:25:30 adamw: thanks 17:25:35 other ack/nak/patch? 17:25:56 ack 17:26:02 #agreed 951225 - AcceptedFreezeException - This seems to be a relatively minor fix and was requested by releng to keep the package sets in sync, so accepted as FreezeException for F19 alpha. 17:26:30 actually, I think we need to re-examine the FE process at some point, but that's post F19 material 17:26:41 #topic (950510) AttributeError: 'Iso9660FS' object has no attribute 'partedDisk' 17:26:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=950510 17:26:47 #info Proposed Freeze Exceptions, python-blivet, POST 17:27:22 i'd kinda like to take this 17:27:25 it makes dd'ed live images work again 17:27:41 and it's been tested via updates.img 17:27:49 which is pretty handy for people who don't have a fedora install to run litd from 17:27:54 yep 17:27:54 yeah 17:28:00 +1 FE from me 17:28:03 +1 17:28:05 if it was tested, +1 FE 17:28:24 https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-April/003792.html is the patch 17:28:42 +1 It's been tested and makes using live USB simpler 17:28:54 the only thing that worries me there is "+ # there's no need to filter partitions on members of multipaths or 17:28:54 + # fwraid members from lvm since multipath and dmraid are already 17:28:54 + # active and lvm should therefore know to ignore them" 17:29:02 proposed #agreed 950510 - AcceptedFreezeException - This makes dd'd isos work again for F19 alpha and the fix has been tested by more than one person using an updates.img - please pull into the next TC/RC 17:29:05 it has the 's word' in it 17:29:20 but multipath and dmraid is beta stuff, so shouldn't be too horrible even if it borked something. 17:29:21 ack 17:29:26 where are we with "enterprise" storage in F19 17:29:26 ack 17:29:32 ack 17:29:38 #agreed 950510 - AcceptedFreezeException - This makes dd'd isos work again for F19 alpha and the fix has been tested by more than one person using an updates.img - please pull into the next TC/RC 17:29:44 Viking-Ice: i know there's a lot of wrok going on on it, i'm not sure we tested it much yet 17:29:45 no idea, haven't even tried it yet 17:29:48 Viking-Ice: i plan to try and test at least iSCSI 17:29:52 probably should, 17:30:18 adamw, iSCSI probably works best of them ;) 17:30:39 /me doesn't have any really fancy storage HW, though 17:30:55 #topic (948750) systemd seems to be ignoring FONT setting in /etc/vconsole.conf 17:30:58 #link https://bugzilla.redhat.com/show_bug.cgi?id=948750 17:31:00 #info Proposed Freeze Exceptions, systemd, POST 17:31:29 this seems a bit murky? 17:31:51 related to the schrodingers cat bug that we got before? 17:31:52 this can be fixed after install 17:31:54 well, no, maybe not. 17:32:04 but yeah, seems fixable post-install easily enough, and the impact isn't really awful 17:32:14 -1 17:32:19 and it's systemd and there are few details on how invasive the change is 17:32:22 also -1 17:32:30 and can be worked around by using a cmdline parameter I think 17:32:42 the fix doesn't look horrible - it just moves some logic from one place to another - but still -1. 17:32:47 Is that even a bug? 17:32:57 and if we made this +1, systemd guys would probably just send us 201. 17:33:06 brunowolff: yeah, it looks like one. 17:33:12 Why wouldn't a kernel param override something in .etc? 17:33:20 -1 17:33:26 -1 FE 17:33:35 brunowolff: the problem is that if you pass a kernel parameter for _any one_ of the settings in the /etc/vconsole.conf file, systemd ignores _all_ the settings in the file 17:33:41 it doesn't just ignore the single setting you overrode 17:33:59 and we pass some parameter on cmdline by default. 17:34:13 so it's obviously a bug, but the impact doesn't seem terrible. 17:34:18 proposed #agreed 948750 - RejectedFreezeException - This should be fixable post-install with an update, is workaround-able and is a bit too risky to be taking this close to release. 17:34:20 Oh. That would be a bug. But I'm still -1 FE for this at this time. If we slip, then it can be reproposed. 17:34:22 ack 17:34:31 ack 17:34:35 ack 17:34:50 #agreed 948750 - RejectedFreezeException - This should be fixable post-install with an update, is workaround-able and is a bit too risky to be taking this close to release. 17:35:07 I believe that is all of the bugs for today 17:35:19 did I miss any that are on the list? 17:35:54 depends on which list you have been working on 17:35:59 * tflink assumes not 17:36:06 very true 17:36:06 * jreznik thinks it's all 17:36:12 #topic Open Floor 17:36:15 I thought the llvmpipe / sse2 was a FE. But the fix isn't good enough to be worth pulling, so it wouldn't get taken in any case. 17:36:23 isn't it accepted alreadyt? 17:36:39 yes, it is. 17:36:46 Anything else to be brought up? 17:36:47 have we done the lxdm one and the selinux one 17:36:50 should we note that https://bugzilla.redhat.com/show_bug.cgi?id=949761 seems to be fixed in TC6? 17:36:54 Maybe it's already in. It didn't make things worse, so it shouldn;t be a problem. 17:37:04 Viking-Ice: they're NEW, so ignoring them 17:37:25 adamw: yep 17:37:33 oh didn't do the accepted blockers 17:37:33 wow 17:37:38 #undo 17:37:38 Removing item from minutes: 17:37:57 #topic (949761) EFI installed system fails to boot (Fedora-19-Alpha-TC5) 17:38:00 #link https://bugzilla.redhat.com/show_bug.cgi?id=949761 17:38:01 brunowolff: we don't usually review accepted FE automatically 17:38:02 #info Accepted Blocker, grub2, NEW 17:38:22 so TC6 seems to 'fix' this. the 'fix' was really a workaround, though, so i didn't want to set the bug to MODIFIED/ON_QA/VERIFIED 17:38:31 i'll check in with pjones how he wants to handle it 17:38:38 ok 17:38:55 I'm still trying to figure out the root cause. 17:39:12 #info TC6 seems to 'fix' this using a workaround 17:39:15 pjones: so we shou;d leave the bug open and just drop the blocker status when anaconda goes stable 17:39:27 tflink: note that it'll only fix it on new installs. 17:39:35 #undo 17:39:35 Removing item from minutes: 17:39:39 adamw: it's still a pretty serious bug 17:39:49 #info TC6 seems to 'fix' this for new installs using a workaround in anaconda 17:40:49 pjones: roger. i've added a comment to the bug to note what'll happen 17:41:02 then I suppose the question is whether or not the workaround is enough to allow F19a out the door 17:41:05 we could always propose it as a Beta blocker at the appropriate time if it looks like that's a good idea 17:41:15 tflink: it pretty clearly is, as we only care about fresh installs for alpha. 17:41:20 we don't care about upgrades of any kind. 17:41:24 * tflink is probably ok with it 17:41:36 the efi install on F18 is broken anyway 17:42:05 it puts the partition under /boot/efi not /boot 17:42:14 #info as the workaround in TC6 fixes the symptom, the F19 alpha blocker status will be removed from this bug 17:42:21 Viking-Ice: what are you even talking about? 17:42:35 pjones, the risk of upgrades 17:42:55 go on? 17:43:02 can we *not* go on? 17:43:08 this sounds pretty off-topic. 17:43:10 or go on elsewhere? 17:43:12 yes. 17:43:50 Well, if there's serious installation problem with EFI I'd like to know what it is. 17:44:20 pjones: sure, so 'elsewhere' maybe? 17:45:04 anything else on this bug? 17:45:10 okay for me. 17:45:19 ok 17:45:26 #topic (947142) write to /sys/firmware/efi/vars/new_var results in ENOSPC 17:45:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=947142 17:45:32 #info Accepted Blocker, kernel, NEW 17:45:48 so, as noted in the qa meeting, we're hopeful the fix for this will show up shortly 17:45:48 am i in time? 17:46:05 it's upstream right 17:46:12 jwb: we just started talking about this less than a minute ago 17:46:16 Viking-Ice, no 17:46:17 sorry, I'm afraid you missed the changing of the guard. 17:46:42 tflink, yay, then i'm in time. 17:46:44 Viking-Ice: no, mjg59/jwb are working on the fix, then they need to get it signed off by upstream, then we can put it in a fedora build. 17:47:35 adamw: could you please follow up with mjg/jwb today, I'm quite dead now, I'll try to be online when I come home 17:47:47 okay, i think it should be under control. 17:49:13 #info mjg59 and jwb are working on the fix - once it is signed off by upstream, we can get a fedora build to test 17:49:34 anything else to note on this bug 17:49:50 ? 17:49:51 anything, jwb>? 17:50:20 nothing directly, no 17:50:45 indirectly? :) 17:50:46 ok, I think that's really all for today this time 17:50:59 unless there is something indirect 17:51:18 when is the drop dead day for another slip? 17:51:49 wednesday would be the hero day, i guess. 17:52:01 that would require us to knock out all the testing overnight. tuesday is the 'reasonable' deadline. 17:52:11 technically we should be slipping since we ought to be testing smoke builds 17:52:20 oh, ok. i think that should be fine. did TC6 include the updated kernel? 17:52:26 the rc6.git2.1? 17:52:38 it would make things a lot nicer if we could get it today, though, because i'd like to do an RC3 build with a new anaconda with FE fixes, but have flexibility to ditch it and do RC4 with just kernel if necessary. 17:52:40 or we can try friday go/no-go and wed release 17:52:41 jwb: yes, it did 17:52:48 oh, excellent 17:54:03 it's bad practice throwing in fixes day before no go meeting I would say today and no go meeting friday 17:55:07 Viking-Ice: let's be flexible now - go/no-go on thursday and then move it or slip by day 17:55:18 but it sounds like we're done with discussing this particular bug for now? 17:55:28 yeah 17:55:39 #topic Open Floor 17:55:42 * satellit_e should the l-i-t-d test page instructions include the " --efi " switch ? it does not seem to affect booting of the same USB on non EFI PC's 17:55:49 yep, even I'd like to see a plan B... but I trust jwb/mjg to make it soon :) 17:55:58 satellit: it'd be worth mentioning it 17:56:00 in any case I got to run later 17:56:03 Anything else need to be brought up during the meeting? 17:56:11 just this plan i've been mentioning 17:56:22 so the thing is that strictly all we *need* for the next compose is a new kernel package 17:56:44 * jreznik will be online on phone from now (that _z10 jreznik) 17:56:45 we aren't required to touch anything else - the only blocker is in kernel. but actually i'd like to pull in anaconda for the FE issues we have fixes for, as they're quite icky 17:57:04 do we want to set a deadline for TC6/RC3? 17:57:14 * jreznik is ok with adamw's plan + that ppc one 17:57:18 so my basic plan, assuming we get kernel fix today, is to do RC3 tonight with kernel fix and new anaconda, if new anaconda borks things, we fire RC4 tomorrow with just the kernel, drop back to the anaconda from TC 17:57:19 TC6 17:57:33 works for me 17:57:44 wfm 17:57:46 if kernel fix doesn't come today, we _could_ do a TC7 with the anaconda FE changes tonight 17:57:53 i guess we'll play it by ear 17:58:05 and do more uefi testing on it 17:58:09 yeah 17:58:16 sounds like a plan to me 17:58:33 okay, i'll work with #anaconda on getting a new build 17:58:56 thanks guys 17:59:32 anything else aside from watching out for zombie_jreznik later? 17:59:55 * adamw readies flamethrower 17:59:56 That plan sounds good. 18:00:19 * tflink sets fuse for [0,5] minutes 18:00:42 too late for icecream but time to head home, see you! 18:01:18 have a beefy miracle 18:02:28 Thanks for coming, everyone! 18:02:35 * tflink will send out minutes shortly 18:02:41 #endmeetign 18:02:44 bah 18:02:47 #endmeeting