16:00:42 <tflink> #startmeeting f19final-blocker-review-2
16:00:42 <zodbot> Meeting started Mon Jun  3 16:00:42 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:42 <tflink> #meetingname f19final-blocker-review-2
16:00:42 <tflink> #topic Roll Call
16:00:42 <zodbot> The meeting name has been set to 'f19final-blocker-review-2'
16:01:35 * kparal cheers
16:02:00 <tflink> kparal: cheer?
16:02:13 <adamw> ahoy hoy
16:02:18 <brunowolff> Can I be fired?
16:03:03 <tflink> brunowolff: that reminds me, I got fired this morning. I think that means I can leave the meeting :)
16:03:17 <kparal> tflink: like in a crowd, hands up, cheering?
16:04:08 <brunowolff> How does the wave look in irc?
16:04:15 * kparal 's dictionary also says rejoice or exult
16:04:15 <tflink> kparal: it was more confusion on why anyone would cheer for a blocker review meeting
16:04:32 <kparal> tflink: yeah, that was the intended joke
16:06:02 <jreznik> adamw: ahoj!
16:06:20 <tflink> anyhow, lets get this thing started
16:06:21 * jreznik was fired too today, he's about to leave
16:06:42 <tflink> jreznik: sometimes I wish it worked that way :)
16:06:45 <tflink> #topic Introduction
16:06:51 <tflink> Why are we here?
16:06:52 <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 freeze exception bugs.
16:06:56 <tflink> #info We'll be following the process outlined at:
16:06:56 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:02 <tflink> #info The bugs up for review today are available at:
16:07:02 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:08 <tflink> #info The criteria for release blocking bugs can be found at:
16:07:08 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria
16:07:11 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria
16:07:14 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
16:07:17 <tflink> #info Up for review today, we have:
16:07:26 <tflink> #info 14 Proposed Blockers
16:07:26 <tflink> #info 8 Accepted Blockers
16:07:26 <tflink> #info 6 Proposed Freeze Exceptions
16:07:26 <tflink> #info 12 Accepted Freeze Exceptions
16:07:32 <kparal> ouch
16:07:47 <tflink> if there are no objections, I'll get started with the proposed blockers
16:07:53 <adamw> goddamnit people, stop finding bugs
16:08:11 <tflink> #topic (969327) race condition in kickstart partitioning
16:08:11 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=969327
16:08:11 <tflink> #info Proposed Blocker, anaconda, NEW
16:08:56 <kparal> we already discussed this, now it is a separate bug
16:09:43 <kparal> Tim and me were able to reproduce this last time, Adam wasn't
16:09:55 <kparal> me->I
16:10:29 <adamw> thanks for the split
16:10:46 <kparal> if there's nothing extremely wrong with the kickstart (I don't see anything), I think this is ready for +1 blocker
16:10:49 <adamw> as noted I'm probably +1 as this obviously affects unattended installs
16:11:02 <tflink> #chair adamw kparal
16:11:02 <zodbot> Current chairs: adamw kparal tflink
16:11:20 <tflink> since I forgot before, any volunteers for secretary duty?
16:12:11 <kparal> my usual excuse is "it's too late for me" :-)
16:13:27 <adamw> sure, me
16:13:32 <tflink> adamw: thanks
16:13:42 <kparal> adamw was faster, phew :)
16:13:59 <brunowolff> Given this breaks unattended installs I think it is a blocker. (Even though it only happens sometimes, it seems often enough that we should have it fixed on media.)
16:14:24 <tflink> proposed #agreed 969327 - AcceptedBlocker - Violates the following F19 beta release criterion: "Any installation method or process designed to run unattended must do so. There should be no prompts requiring user intervention."
16:14:29 <brunowolff> ack
16:14:41 <adamw> ack
16:15:32 <kparal> ack
16:15:41 <tflink> #agreed 969327 - AcceptedBlocker - Violates the following F19 beta release criterion: "Any installation method or process designed to run unattended must do so. There should be no prompts requiring user intervention."
16:15:50 <tflink> #topic (967527) clearpart --none crashes anaconda if not enough space available
16:15:53 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=967527
16:15:55 <tflink> #info Proposed Blocker, anaconda, NEW
16:16:03 <kparal> this is the second half
16:16:21 <kparal> now only concerning --none
16:17:02 <adamw> i suppose it could turn out they're still caused by the same underlying thing, but it's clearer this way
16:17:10 <adamw> i'm probably -1/+1 on this half as it's basically an invalid config
16:17:15 <brunowolff> The mitigating factor here is the --none is the default, so there is a work around for unattended installs.
16:17:47 <kparal> adamw: I have the same opinion
16:18:02 <brunowolff> I think -1 blocker +1 FE.
16:18:13 <tflink> yeah, --all would be an acceptable workaround
16:19:25 <tflink> proposed #agreed 967527 - RejectedBlocker AcceptedFreezeException - While crashing during a kickstart scripted install is sub-optimal, using 'clearpart --none' on a non-empty disk is at least somewhat invalid and using 'clearpart --all' is an acceptable workaround
16:19:42 <brunowolff> --all is the opposite of --none.
16:19:42 <jreznik> ack
16:19:51 <adamw> well, not necessary --all
16:20:08 <adamw> just say it could be worked around with a valid config or something
16:20:11 <brunowolff> If no option was specified, then it should be the same as --none.
16:20:14 <kparal> tflink: I believe it's caused by insufficient disk space, not by having a non-empty disk
16:20:27 <adamw> brunowolff: the point is that you have to clear *something* if you don't have sufficient space
16:20:39 <tflink> proposed #agreed 967527 - RejectedBlocker AcceptedFreezeException - While crashing during a kickstart scripted install is sub-optimal, using 'clearpart --none' on a non-empty disk is at least somewhat invalid and can be worked around with a valid config or different command options
16:20:53 <adamw> there is no way 'don't delete any partitions' is going to get you a successful install. if you have sufficient space you don't have to clearpart --all, but you have to wipe _something_ (or add more disks)
16:20:58 <brunowolff> ack
16:21:03 <adamw> sigh. DON'T have sufficient space.
16:21:04 <adamw> ack
16:21:12 <adamw> er
16:21:13 <adamw> still patch
16:21:39 <tflink> adamw: what did I miss?
16:21:50 <adamw> proposed #agreed 967527 - RejectedBlocker AcceptedFreezeException - While crashing during a kickstart scripted install is sub-optimal, using 'clearpart --none' without sufficient space is invalid and so the bug can be 'worked around' with a config that will actually result in success
16:22:00 <tflink> ack
16:22:07 <jreznik> ack
16:22:26 <kparal> nicely said. bug can be worked around by working around the bug :D
16:22:28 <kparal> ack
16:22:29 <brunowolff> ack
16:23:08 <tflink> adamw: it's easier if you do the #agreed
16:23:11 <adamw> #agreed 967527 - RejectedBlocker AcceptedFreezeException - While crashing during a kickstart scripted install is sub-optimal, using 'clearpart --none' without sufficient space is invalid and so the bug can be 'worked around' with a config that will actually result in success
16:23:13 <adamw> yup, sorry
16:23:14 <tflink> thanks
16:23:20 <tflink> #topic (966761) storage configuration failed: Not enough free space on disks for automatic partitioning
16:23:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=966761
16:23:25 <tflink> #info Proposed Blocker, anaconda, NEW
16:23:49 <tflink> not sure there's much to say here - still waiting for reporter
16:24:07 <tflink> #info still waiting for reporter to re-test
16:24:25 <kparal> I think Mark is waiting for Final TC1
16:24:35 <tflink> makes sense
16:24:39 <kparal> there were no images in the meantime
16:24:55 <tflink> another argument for doing TC1 today
16:25:38 <adamw> man, i don't know when everyone got so enthusiastic about the 24x7 validation treadmill
16:26:13 <tflink> #topic (965883) "Use network login..." button in user creation spoke entirely broken
16:26:16 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=965883
16:26:19 <tflink> #info Proposed Blocker, anaconda, NEW
16:27:22 <adamw> see c#1
16:27:38 <adamw> for the record, in F18 and earlier firstboot had 'advanced' user creation that worked
16:27:46 <tflink> yeah, mostly thinking about whether network logins @ install time are enough to block over
16:27:59 <adamw> i suppose you could argue that the 'workaround' is to create a local user account and do the remote config with that
16:28:11 <adamw> i don't know if that's acceptable for all scenarios, i don't have a lot of experience with remote auth
16:28:27 <adamw> this is the time when it'd be nice to have more people in these meetings :(
16:29:25 * kparal shrugs
16:29:27 <tflink> yeah, I don't have a lot of experience with system-level remote auth either
16:29:57 <adamw> nirik: any wisdom to share?
16:30:20 * nirik looks up
16:30:55 <nirik> no idea off hand. ;) whats the question? blocker or not?
16:31:15 <tflink> yeah
16:32:20 <adamw> basically, how important is it that we have remote auth config working at install/firstboot time?
16:32:39 <adamw> probably something we should add to the criteria if we decide it's critical
16:32:43 <nirik> I don't know. ;)
16:32:48 <tflink> does it work w/ kickstart?
16:32:56 <nirik> I've not really ever used it.
16:33:28 <tflink> my suspicion is that most situations w/ remote auth either use custom base images or some sort of cfg management
16:33:54 <brunowolff> Or maybe CENTOS/RHEL instead of Fedora
16:34:30 <kparal> We should do +1 FE and ask in the bugzilla (or on devel) if anyone has any reasons why this is a blocking bug
16:34:49 <jreznik> kparal: +1
16:34:51 <kparal> if there's no push from any party...
16:34:57 <tflink> if we're going to ask seriously, it needs to be a wider audience than just the bug
16:34:58 <adamw> yeah, that sounds like a plan
16:35:08 <tflink> works for me
16:36:45 <tflink> proposed #agreed 965883 - AcceptedFreezeException - We're not 100% clear on whether the ability to setup system-wide remote auth @ install time is important enough to block over but would consider a fix for the non-functional menu after freeze. Will start conversation with wider audience WRT whether this is a release blocking issue or not.
16:38:14 <kparal> ack
16:38:21 <adamw> ack
16:38:30 <jreznik> ack
16:38:36 <brunowolff> ack
16:38:36 <tflink> #agreed 965883 - AcceptedFreezeException - We're not 100% clear on whether the ability to setup system-wide remote auth @ install time is important enough to block over but would consider a fix for the non-functional menu after freeze. Will start conversation with wider audience WRT whether this is a release blocking issue or not.
16:38:48 <tflink> #topic (965865) ValueError: ('invalid size specification', '-880.000000 MB')
16:38:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=965865
16:38:53 <tflink> #info Proposed Blocker, anaconda, NEW
16:40:04 <tflink> this is starting to look rather blockery to me
16:41:07 * adamw asking dlehman/clumens if c#24 is an accurate description
16:43:23 <adamw> not getting a reply, though...
16:43:54 <adamw> how about this: we ask for dev feedback on whether this and 959714 are dupes and whether c#24 is accurate, and if so, it's a blocker?
16:44:32 <tflink> and if not, re-evaluate at next meeting
16:44:40 <kparal> ok
16:46:05 <tflink> proposed #agreed 965865 - Still waiting for feedback from devs on summary of bug and whether #959714 is a duplicate. If the summary is correct and this is a duplicate of #959714, this is accepted as a blocker for F19 final. Otherwise, we will re-evaluate at the next blocker review meeting.
16:46:10 <tflink> hold on a sec
16:46:18 <tflink> proposed #agreed 965865 - Still waiting for feedback from devs on summary of bug and whether #959714 is a duplicate. If the summary is correct and this is a duplicate of #959714, this is accepted as a blocker for F19 final. Otherwise, we will re-evaluate at a later blocker review meeting.
16:46:24 <tflink> minor change, next to later
16:46:35 <kparal> ack
16:46:38 <brunowolff> ack
16:47:47 <adamw> ack
16:47:56 <tflink> #agreed 965865 - Still waiting for feedback from devs on summary of bug and whether #959714 is a duplicate. If the summary is correct and this is a duplicate of #959714, this is accepted as a blocker for F19 final. Otherwise, we will re-evaluate at a later blocker review meeting.
16:48:03 <tflink> #topic (969182) DeviceCreateError: ('Could not commit to disk /dev/mapper/mpatha, (py_ped_disk_commit)', 'mpatha3')
16:48:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=969182
16:48:09 <tflink> #info Proposed Blocker, anaconda, NEW
16:48:59 <tflink> this kinda smells like bad mpath setup in software or hardware to me
16:49:05 <kparal> more developer feedback needed?
16:49:32 <tflink> I used to see that commonly when the machine was trying to use paths as separate disks
16:49:49 <adamw> i've no idea who 'ben' is
16:49:55 <tflink> which confuses the heck out of the remote storage :)
16:50:02 <adamw> but yeah, i'm a bit at sea here...
16:50:36 <tflink> we need more info on what's going on here - it depends on where the issue is
16:50:50 <tflink> probably a blocker, though
16:52:09 <tflink> proposed #agreed 969182 - We're waiting for developer input on this before making a decision on release-blocking status
16:52:16 <kparal> ack
16:52:19 <tflink> I suppose that could be an info
16:52:37 <tflink> one question this brings up is whether that release criterion should even exist
16:52:55 <tflink> in general, we don't really have the hardware to touch this
16:53:12 <adamw> we shouldn't really make release criteria contingent on qa hardware coverage
16:53:15 <adamw> rather the other way around
16:53:45 <tflink> I'm not all that thrilled about the idea of setting up multipath iscsi or having fc hw around
16:54:46 <tflink> on the other hand, we might be able to convince some of the RH storage folks to help - they've been responsive in the past when I've asked them about specific test cases
16:55:11 <tflink> either way, outside the scope of this meeting
16:56:28 <adamw> yeah
16:56:30 <jreznik> any help needed to ask rh folks to do some testing - or let you access some hw?
16:56:30 <adamw> ack
16:56:51 <tflink> jreznik: we might end up there, yeah
16:57:08 * jreznik will try to investigate this option
16:57:12 <tflink> IIRC, our fancy-expensive-storage test case coverage is rather weak, though
16:57:49 <adamw> yeah, it is
16:57:56 <tflink> #agreed 969182 - We're waiting for developer input on this before making a decision on release-blocking status
16:58:02 <adamw> our storage test case coverage in general needs improving
16:58:09 * tflink still thinks that boot-from-san is borderline insane
16:58:16 <tflink> for x86 at least
16:58:47 <tflink> ppc/s390 might be a bit better of a setup
16:59:37 <tflink> #topic (969032) IOError: [Errno 9] Bad file descriptor
16:59:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=969032
16:59:37 <tflink> #info Proposed Blocker, babel, NEW
17:00:53 <adamw> well, this is weird.
17:01:05 <adamw> so long as it's single system and not reproducible and basically confusing the hell out of everyone I guess i'd be -1
17:02:09 <kparal> he should clarify whether he used the same stick on a different machine and it worked, or whether he created the stick anew on a different machine and it worked
17:02:26 <tflink> kparal: isn't that in c#18?
17:02:26 <kparal> also, he needs to run "verify and install" and tell us whether the check was ok
17:02:50 <kparal> tflink: I'm not sure what he means
17:02:52 <adamw> sounded like he tried same-stick-different-machine
17:03:04 <kparal> same stick, but created anew or not?
17:03:10 <tflink> we could ask igor, I think he's been involved in this
17:04:38 <kparal> punt and wait if more people confirm
17:04:42 <kparal> nothing else to do here
17:04:50 <kparal> it seems as a hw problem
17:05:46 <dan408__> looks like a bad usb stick
17:06:15 <adamw> kparal: well, we could reject and see if people confirm...
17:06:17 <adamw> morning dan
17:06:49 <tflink> yeah, I'm leaning towards reject as a system-specific issue ATM
17:06:54 <dan408__> happy monday adamw
17:06:55 <kparal> works for me
17:07:56 <tflink> proposed #agreed 969032 - RejectedBlocker - While severe, this appears to be an isolated case and potentially an issue with the reporter's hardware. If it turns out to be more widespread, please re-propose as a blocker
17:08:00 <adamw> ack
17:08:49 <dan408__> ack
17:09:09 <brunowolff> ack
17:09:16 <tflink> #agreed 969032 - RejectedBlocker - While severe, this appears to be an isolated case and potentially an issue with the reporter's hardware. If it turns out to be more widespread, please re-propose as a blocker
17:09:26 <kparal> ack
17:09:30 <tflink> #topic (969500) DBus Fails to start
17:09:30 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=969500
17:09:30 <tflink> #info Proposed Blocker, dbus, NEW
17:10:02 <ignatenkobrain> hi all =)
17:10:06 <adamw> morning
17:10:38 <adamw> this one seems kinda useless
17:10:40 <ignatenkobrain> what from me it is required?
17:10:41 <adamw> could do with some logs for a start
17:10:51 <adamw> ignatenkobrain: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:11:09 <tflink> ignatenkobrain: I was wondering if you had any more info on your friend's issue with the babel crash
17:11:13 <tflink> i/we
17:11:36 <tflink> but we ended up rejecting it as a blocker unless it ends up being more widespread
17:11:44 <ignatenkobrain> tflink: all info in rhbz. anything else
17:11:51 <kparal> 969500 needs more information first
17:12:10 <tflink> yeah, this sounds like a jacked up system to me
17:12:17 <adamw> yeah. i'm guessing none of us have seen anything like this?
17:12:22 <kparal> no
17:12:56 <tflink> it's a box that has been upgraded since before F14
17:13:56 <ignatenkobrain> tflink: np.
17:14:37 <tflink> punt or reject?
17:15:10 <tflink> hrm, looks like I misread this
17:16:02 <tflink> at the very least, we need more info on what is going on
17:16:04 <adamw> yes
17:16:10 <tflink> it's not clear which hds have what installs
17:16:16 <tflink> and what's hooked up when he's booting
17:16:19 <adamw> well i'd just like some more logs from the affected system really
17:16:24 <adamw> but yeah, anyway. punt, i guess.
17:17:13 <tflink> proposed #agreed 969500 - We need more information and logs before making any decision on this bug. Otherwise, it will be rejected as an isolated case.
17:17:34 <kparal> ack
17:17:48 <tflink> his definition of reproducible is also unclear - I don't think that he did a second install
17:17:58 <tflink> it sounds like this just happens @ every boot
17:18:40 <adamw> ack
17:19:52 <tflink> #agreed 969500 - We need more information and logs before making any decision on this bug. Otherwise, it will be rejected as an isolated case.
17:20:00 <tflink> #topic (969852) Software Update fails to update
17:20:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=969852
17:20:00 <tflink> #info Proposed Blocker, gnome-packagekit, NEW
17:20:57 <kparal> I've seen this one too
17:20:58 <tflink> did we ever start figuring out what the default update mechanism was?
17:21:12 <kparal> but I thought this got resolved by one of the recent PK updates
17:21:42 <adamw> tflink: you can reasonably argue that it's either online or offline, at this point. if anything i'd argue we should make sure both work, since users can easily trigger either
17:21:53 <adamw> if desktop team doesn't like it it's their own damn fault for offering both
17:22:10 <tflink> that works for me
17:22:12 * kparal agrees, both should work
17:22:23 <tflink> +1, if this is happening regularly, though
17:23:46 <kparal> this might be depending on user locale
17:24:00 <adamw> yeah, we might need to pin this down a bit, but it looks kinda +1y
17:25:00 <tflink> proposed #agreed 969852 - AcceptedBlocker - Violates the following F19 alpha release criterion for packageKit updates in the Gnome DE: "The installed system must be able to download and install updates with yum and with the default graphical package manager in all release-blocking desktops."
17:25:19 <brunowolff> ack
17:25:45 * kparal trying to reproduce now
17:26:13 <adamw> ack for now
17:26:16 <adamw> we can always revisit later
17:26:49 <kparal> I really don't understand why gpk-update-view takes 50% cpu while deltarpms are being re-created as a different process
17:26:54 <kparal> ack
17:26:58 <tflink> #agreed 969852 - AcceptedBlocker - Violates the following F19 alpha release criterion for packageKit updates in the Gnome DE: "The installed system must be able to download and install updates with yum and with the default graphical package manager in all release-blocking desktops."
17:27:10 <tflink> #topic (919855) [abrt] gnome-settings-daemon-3.7.91-1.fc19: getenv: Process /usr/libexec/gnome-settings-daemon was killed by signal 11 (SIGSEGV)
17:27:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=919855
17:27:15 <tflink> #info Proposed Blocker, gnome-settings-daemon, NEW
17:28:43 <tflink> +1 from adam in bug
17:29:06 <kparal> +1 because in my experience it's not that hard to hit
17:31:42 <tflink> how often does it happen with lives?
17:31:51 <tflink> has it happened with livemedia?
17:32:13 <tflink> if so, probably +1 otherwise, probably +/- 0
17:32:38 <tflink> it's a post-install issue and could be fixed with an update (assuming lives aren't affected badly)
17:33:06 <kparal> I haven't seen it with Live
17:33:24 <adamw> it still looks pretty crappy if you're hitting it till we ship updates
17:33:29 <kparal> but if there's 10% chance to trigger, it means that for 10% of people the desktop would not start
17:33:40 <adamw> after their initial install...right
17:33:51 <tflink> would not start on initial reboot
17:33:57 <tflink> yeah, it looks bad
17:34:33 <kparal> and the cause is known
17:34:39 <tflink> and this doesn't immediately fail the "last blocker to decide on slip" test
17:35:50 <adamw> yeah, i think i'm still +1
17:36:35 <tflink> "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."?
17:37:29 <tflink> proposed #agreed 919855 - AcceptedBlocker - Violates the following F19 alpha release criterion for approximately 1 in 10 boots to the gnome DE: "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."
17:37:32 <kparal> we're not sure if this affects also the initial login, or just the second login
17:37:47 <kparal> but I guess that's not that important
17:37:48 <adamw> close enough
17:37:49 <adamw> ack
17:37:55 <tflink> kparal: yeah, that's why I took the later boots criterion
17:37:57 <kparal> ack
17:38:12 <tflink> figured it was about the same meaning and it's more likely to happen after firstboot
17:39:00 <tflink> do we have a 3rd ack or is it  just the 3 of us now?
17:39:37 <tflink> guess so
17:39:40 <adamw> brunowolff: ^^^?
17:40:40 <tflink> #agreed 919855 - AcceptedBlocker - Violates the following F19 alpha release criterion for approximately 1 in 10 boots to the gnome DE: "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."
17:40:54 <tflink> #topic (964335) Running 3.9.2-200 kernel leads to kernel panic  virt_efi_get_variable
17:40:57 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=964335
17:41:00 <tflink> #info Proposed Blocker, kernel, NEW
17:42:28 <kparal> does somebody have a tl;dr version?
17:42:56 <tflink> UEFI mess redux
17:43:42 <adamw> this looks like it was the stuff mjg59 was mentioning in the qa meeting
17:44:08 <brunowolff> Sorry I am multitasking and was reading in a different window. I'll catch up now...
17:44:28 <adamw> np
17:45:00 <adamw> so i'm not totally sure whether 'blocker' is appropriate here as i'm not quite sure what it means. i mean, ultimately, we want the kernel team to do the best they can to make things work on as many UEFI installs as possible, but ultimately we're going to be deferring to their wisdom
17:45:27 <tflink> yeah, this has a few very excited people in the comments
17:45:33 <adamw> if we make this a blocker, what are we saying exactly? say the patch turns out to be bad, what do we do?
17:45:41 <kparal> ask jwb or mjg to come here?
17:45:46 <tflink> +1 to defering to kernel devs
17:46:49 <adamw> i've just chatted with them
17:46:53 <adamw> <mjg59> We shouldn't release in the current state. If the fix for that breaks more systems, then we should block on that too.
17:46:56 <adamw> so on that basis, +1
17:47:04 <brunowolff> (I am not sure if 919855 is what I am seeing on my Athlon / radeon 9200 machine. That has been failing pretty conistently, though I don't test gnome stuff on it very often any more.)
17:48:11 <tflink> +1
17:48:15 * kparal notes that bug 951009 is very related to all these UEFI issues, but no one from anaconda started to work on it yet, unfortunatelly
17:48:27 <brunowolff> (I do have another old machine that was failing to run gdm or gnome, that did work with a live image not too long ago.)
17:48:42 <kparal> +1, if kernels devs say don't release, we probably shouldn't
17:49:45 <brunowolff> (I see I am confused. You were just asking for another ack not if that was related to the gdm problems I was having. I should be fired, but you won't just to punish me.)
17:49:48 <tflink> proposed #agreed 964335 - AcceptedBlocker - Violates the following F19 alpha release criterion: "
17:49:57 <tflink> bah
17:50:25 <adamw> nack
17:50:26 <adamw> :P
17:50:44 <tflink> proposed #agreed 964335 - AcceptedBlocker - Violates the following F19 alpha release criterion: "All release-blocking images must boot in their supported configurations, including all system firmware types that are commonly found on the primary architectures."
17:51:44 <adamw> hum, no, not quite
17:51:56 <adamw> this is more post-install boot or install complete for UEFI installs
17:52:06 <adamw> this bug never prevents the installer itself from booting
17:52:23 <tflink> "A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account."?
17:52:27 <tflink> true
17:52:55 <adamw> well, perhaps *this* specific bug actually would. but i think post-install boot is the safest one.
17:52:58 <adamw> so yeah, sure, that one.
17:53:22 <tflink> proposed #agreed 964335 - AcceptedBlocker - Violates the following F19 alpha release criterion for many systems with UEFI firmware: " After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."
17:55:23 <adamw> ack
17:55:30 <kparal> ack
17:55:32 <brunowolff> ack
17:55:40 <tflink> #agreed 964335 - AcceptedBlocker - Violates the following F19 alpha release criterion for many systems with UEFI firmware: " After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot."
17:55:52 <tflink> #topic (969521) livecd-iso-to-disk produces unbootable media for EFI computers
17:55:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=969521
17:55:58 <tflink> #info Proposed Blocker, livecd-tools, ON_QA
17:56:00 <tflink> sounds like a clear +1
17:56:47 <tflink> proposed #agreed 969521 - AcceptedBlocker - Violates the following F19 beta release criterion for UEFI media prepared with livecd-iso-to-disk: "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods."
17:57:11 <adamw> weeelll...i could nitpick that actually the f19 livecd-iso-disk isn't that important
17:57:16 <adamw> the f18 and f17 ones are rather more important
17:57:21 <adamw> but whatever, i don't mind a +1
17:58:12 <tflink> was this really F19 only?
17:58:25 <brunowolff> I think that FE might be more appropriate.
17:58:42 <kparal> we tested F18 l-i-t-d and it worked OK
17:58:55 <kparal> so I assume this is F19 only
17:59:26 <kparal> but ack
17:59:59 <tflink> it sounds like we're more +0/+1, then?
18:00:36 <adamw> actually i don't really see the need for either blocker or fe for this thinking about it
18:00:48 <brunowolff> Isn't it going to be rare to be stuck using livecd-iso-to-disk from the media to put media on usb drives?
18:00:51 <adamw> say it's two days before release, why do we need to pull this through the freeze?
18:00:59 <adamw> what's the use case for using the frozen f19 livecd-iso-to-disk?
18:01:08 <tflink> is litd on the DVD?
18:01:41 <tflink> so, -1/-1?
18:01:46 <adamw> no
18:01:56 <adamw> er, no livecd-tools is not on the dvbd
18:01:58 <brunowolff> Even if it is on the DVD, you have to have some other way to boot the DVD to use it. At that point you should be able to get updates.
18:01:59 <adamw> yes -1/-1
18:03:15 <tflink> proposed #agreed 969521 - RejectedBlocker RejectedFreezeException - This would be a blocker on either F17 or F18 but as this bug only affects F19, it was deemed not release blocking and needing to be pulled past freeze.
18:03:59 <tflink> ack/nak/patch?
18:04:10 <adamw> ack
18:04:11 <brunowolff> The wording seems wrong. I don't think f17 or f18 packages can block f19.
18:04:50 <brunowolff> But the idea of FE not being needed since the updates can happen in f17 and f18 is good.
18:05:09 <adamw> brunowolff: they can, it's a 'special case' we have covered by precedent
18:05:21 <brunowolff> OK, then I'll ack as worded.
18:05:23 <kparal> ack
18:05:31 <adamw> 'blocker' status for such bugs means f17/f18 must have an update in the stable repo by release day
18:05:38 <adamw> or else, you know, fire and brimstone
18:06:31 <tflink> #agreed 969521 - RejectedBlocker RejectedFreezeException - This would be a blocker on either F17 or F18 but as this bug only affects F19, it was deemed not release blocking and needing to be pulled past freeze.
18:06:43 <tflink> #topic (960230) nss forgets about CAs after suspend
18:06:43 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=960230
18:06:43 <tflink> #info Proposed Blocker, nss, NEW
18:07:28 <tflink> this may end up being worse - there was a similar report in #fedora-qa as we started the review meeting
18:07:55 <tflink> but the reporter disappeared
18:09:15 * adamw suspends his F19 machines _all_ the time and hasn't seen this
18:09:15 <tflink> either way, there's not a whole lot of info on this
18:09:40 <adamw> but i can believe a bug exists
18:09:55 <adamw> i think I _once_ saw a fail in verifying my own site, but that was just one time
18:09:55 <tflink> I'm not sure it's tied to suspend
18:10:23 <adamw> the reporter seems pretty sure it is
18:10:49 * tflink is going off the other reporter in IRC who was pretty sure he had never suspended
18:11:18 <tflink> then again, I don't think that restarting the browser worked there
18:11:44 <tflink> c#1 says it happens in thunderbird w/o suspend
18:12:39 <tflink> as is, not so sure it's a blocker w/o more reports or at least more info
18:12:58 <tflink> I have a hard time seeing the use case for suspending a live image
18:13:04 <tflink> and the workaround isn't so bad
18:13:13 <tflink> a bit of a pain, sure
18:13:25 <tflink> but not sure it's worth blocking release over
18:14:00 <adamw> suspending live images is a dicey business in general, yeah
18:15:12 <kparal> +1 FE and ping nss maintainer to look at it a tell us some info
18:15:53 <tflink> I'd almost rather punt and ask for dev input
18:16:03 <tflink> instead of taking as FE right now
18:16:14 <tflink> nss FEs seem a little on the unwise side
18:17:53 <brunowolff> It seems a bit early to decide if this is FE. I think we need to know more first.
18:18:10 <adamw> yeah, punt
18:18:11 <tflink> sounds punty, then
18:18:54 <tflink> proposed #agreed 960230 - We need more information on this bug before making any decisions on blocker or FreezeException status. Will revisit when more information is available.
18:19:02 <kparal> ack
18:19:33 <adamw> ack
18:20:41 <tflink> #agreed 960230 - We need more information on this bug before making any decisions on blocker or FreezeException status. Will revisit when more information is available.
18:20:48 <tflink> #topic (955236) [abrt] yum-3.4.3-83.fc20: cli.py:1945:removeGroups:AttributeError: 'InstalledGroup' object has no attribute 'groupid'
18:20:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=955236
18:20:54 <tflink> #info Proposed Blocker, yum, MODIFIED
18:21:04 <tflink> not sure this is a blocker
18:21:20 <tflink> but it could be academic, sounds like there is an update which fixes this
18:22:39 <tflink> other thoughts?
18:23:00 <adamw> reading
18:23:14 <tflink> group remove isn't working
18:23:21 <tflink> at least that's how I'm reading it
18:23:44 <kparal> it depends what else is not working
18:23:53 <kparal> group remove is not that bad
18:23:53 <brunowolff> I don't see how group remove not working would be a blocker.
18:23:57 <adamw> right, and how bad the consequences of this are
18:24:11 <brunowolff> Group removes aren't that great on the best of days.
18:24:12 <adamw> if it fails *and corrupts your database*, we have a problem. if it just fails...meh
18:24:33 <kparal> punt and it goes away? :)
18:24:39 <adamw> sounds like a plan
18:26:33 <tflink> it will? there's no update with the yum version in question
18:27:01 <adamw> presumably they're going to submit them
18:27:04 <adamw> i can ask them to in the punt note
18:27:22 <kparal> "yum-3.4.3-93.fc19 fixes it. Thanks guys!" ?
18:27:33 <kparal> ah, bodhi update
18:27:40 <tflink> might have something to do with the build happening less than 2 hours ago
18:27:51 <tflink> http://koji.fedoraproject.org/koji/buildinfo?buildID=424321
18:27:55 <tflink> eh, 2-3 hours ago
18:28:05 <adamw> ayup
18:28:30 <tflink> punt or reject?
18:29:06 <adamw> punt
18:29:18 <adamw> punt for info on what the consequences and triggers of the bug(s) are (ostensibly)
18:29:58 <tflink> proposed #agreed 955236 - We need more information on the triggers and consequences of this bug before deciding on release blocking or freeze exception status
18:30:04 <brunowolff> ack
18:30:08 * tflink does not understand but ... whatever
18:31:22 * kparal does
18:31:23 <kparal> ack
18:31:40 <adamw> ack
18:31:42 <tflink> #agreed 955236 - We need more information on the triggers and consequences of this bug before deciding on release blocking or freeze exception status
18:31:55 <adamw> tflink: the punt is legitimate i think, but we expect it'll get closed anyway
18:32:05 <tflink> it's a failure in a yum command that I can't see being run on livemedia
18:32:07 <adamw> tflink: if not, we really _do_ need to know if it has more serious consequences before rejecting
18:32:14 <tflink> it's a solid -1 to me
18:32:30 <adamw> tflink: what if it turns out that, once you've run this, the rpm database is nerfed and you can't do a yum update any more?
18:32:40 <adamw> that could cause a game over
18:32:43 <tflink> adamw: then how did the reporter confirm the fix?
18:32:51 <adamw> i'm not saying it's likely, but i'd want to clarify it
18:33:10 <tflink> meh, either way it's not worth discussing much :)
18:33:12 <adamw> and there's the bug in comment #6 or whatever it is, which antill said is a different problem - we don't have info on the severity of that problem
18:33:13 <adamw> sure
18:33:29 <tflink> OK, we're at 2.5 hours and we're done with the proposed blocker list for today
18:33:39 <tflink> do we want to keep going or leave the rest for wednesday?
18:34:12 <adamw> are there any anaconda proposed NTHs?
18:34:35 <tflink> yes, 1
18:34:49 <tflink> that doesn't seem to have an imminent fix
18:35:03 <tflink> or exact cause yet, unless I'm misreading
18:35:52 <adamw> eh, it's just 1, throw it up there
18:36:06 <tflink> #topic (869364) Installation Destination screen is sometimes rendered not at full screen width
18:36:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869364
18:36:11 <tflink> #info Proposed Freeze Exceptions, anaconda, ASSIGNED
18:37:46 <adamw> oh, yeah, this one. we really want this fixed. +1
18:37:58 <adamw> clumens has been trying to fix this for a while
18:39:25 <kparal> I saw it once today
18:39:49 <kparal> +1 fe
18:39:56 <adamw> it's pretty easy to hit if you click around enough
18:40:52 <adamw> i want to +1 this on the basis of the anaconda 'freeze'
18:41:15 <adamw> if it was two days before release that'd be another thing, but as things stand, they want outside input on fixes even at this point, so i'm easily +1 at least up until the 'official' freeze
18:41:56 <tflink> proposed #agreed 869364 - AcceptedFreezeException - While this is mostly a cosmetic bug, it does look bad, impact installer usability and can't be fixed post-release with an update. A tested fix would be considered past freeze.
18:42:15 <adamw> ack
18:43:28 <tflink> any other ack/nak/patch?
18:43:50 <kparal> ack
18:43:58 <tflink> #agreed 869364 - AcceptedFreezeException - While this is mostly a cosmetic bug, it does look bad, impact installer usability and can't be fixed post-release with an update. A tested fix would be considered past freeze.
18:44:13 <tflink> OK, with 15 minutes left I vote for being done for the day
18:45:09 <tflink> I see no objections
18:45:15 <tflink> #topic Open Floor
18:45:25 <tflink> Anything else that should be brought up today?
18:46:51 * tflink sets fuse
18:49:08 <adamw> i think that's it
18:49:14 <adamw> just if people could upkarma anaconda it'd be good
18:49:28 <adamw> so we can get that build pushed stable and maybe do another one for tc12
18:49:29 <adamw> tc1
18:50:12 <kparal> we don't have to have it stable to release tc1, do we?
18:52:54 <tflink> anyhow, thanks for coming, everyone!
18:53:04 * tflink will send out minutes shortly
18:53:08 <tflink> #endmeeting