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