17:03:38 <tflink> #startmeeting F16-blocker-review-1
17:03:38 <zodbot> Meeting started Fri Sep 30 17:03:38 2011 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:03:53 <tflink> #meetingname Fedora 16 Final Blocker Review Meeting 1
17:03:53 <zodbot> The meeting name has been set to 'fedora_16_final_blocker_review_meeting_1'
17:04:00 <tflink> #topic roll call
17:04:09 * nirik is lurking around.
17:04:53 * brunowolff is here
17:05:16 <tflink> adamw: you around? This was partially your idea
17:05:54 <nirik> he may be catching up on sleep after the marathon yesterday?
17:06:04 <brunowolff> BTW, thanks to all of the crazy people who prevented another beta slip.
17:06:26 <tflink> nirik: yeah, I'm wondering the same thing
17:07:07 <tflink> I'm still amazed how quickly the test for RC4 were done
17:07:40 <tflink> but honestly, I consider the fact that we had to do that a kind of failure
17:08:37 <nirik> yeah, would have been nice to catch the efi stuff in better time. ;(
17:08:51 <tflink> no kidding
17:09:22 * tflink is really hoping for a less sanity-draining final release
17:11:01 <tflink> well, let's try to get started.
17:11:52 <tflink> #topic Background Information
17:12:05 <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.
17:12:14 <tflink> I'll be working from the following list:
17:12:22 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:12:45 <tflink> any objections to starting with the proposed blockers?
17:13:05 <brunowolff> no
17:14:00 <tflink> #topic (736268) [abrt] GConf2-3.1.90-1.fc16: Process /usr/bin/gsettings-data-convert was killed by signal 11 (SIGSEGV)
17:14:04 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=736268
17:14:06 <buggbot> Bug 736268: unspecified, unspecified, ---, rstrode, NEW, [abrt] GConf2-3.1.90-1.fc16: Process /usr/bin/gsettings-data-convert was killed by signal 11 (SIGSEGV)
17:14:10 <tflink> #info Proposed Blocker, NEW
17:14:44 <tflink> sounds like a pretty straight forward blocker to me
17:15:02 <tflink> "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login"
17:15:51 <tflink> proposed #agreed - 736268 - AcceptedBlocker - Violates the Fedora 16 final release criteria: "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login"
17:15:58 <tflink> ack/nak/patch?
17:16:02 <brunowolff> +1
17:17:21 <tflink> hrm, not sure if this is going to work so well with just 2 of us
17:17:28 * tflink should have thought of that
17:18:17 <brunowolff> We can still get the noncontroversial stuff out of the way.
17:18:42 <brunowolff> Anthing dubious can be punted to the next meeting.
17:19:05 <tflink> yeah, the whole point was to get the list paired down
17:19:27 <tflink> oh well
17:19:30 <sgallagh> tflink: Too few attendees?
17:19:41 * sgallagh is around, if that helps.
17:20:02 <tflink> sgallagh: yeah, having another person around would help
17:20:12 <tflink> it would make for 3 people :)
17:20:23 <tflink> #agreed - 736268 - AcceptedBlocker - Violates the Fedora 16 final release criteria: "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login"
17:20:34 <tflink> #topic (739836) NetworkManager makes reboot take several minutes
17:20:44 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=739836
17:20:45 <buggbot> Bug 739836: unspecified, unspecified, ---, dcbw, NEW, NetworkManager makes reboot take several minutes
17:20:46 <tflink> #info Proposed Blocker, NEW
17:20:54 <sgallagh> Could someone just toss me a quick link to the blocker criteria?
17:21:00 <brunowolff> I think this is more NTH material than blocker.
17:21:19 <tflink> yeah, same here
17:21:30 <tflink> we've had a similar issue with LVM on f15 since before release
17:21:35 <sgallagh> NTH
17:22:08 <sgallagh> FWIW, it's an improvement over my F15 box. That one won't EVER shut down if it was initiated at the console, rather than the Gnome shutdown.
17:22:45 <tflink> proposed #agreed - 739836 - RejectedBlocker AcceptedNTH - This doesn't hit any of the release criteria since the machine does still shut down. However, delayed shutdown is an annoyance and would be nice to have fixed
17:22:49 <tflink> ack/nak/patch?
17:23:17 <tflink> sgallagh: yeah, my F15 box takes forever to shutdown/restart. I haven't actually timed it, though
17:23:32 <tflink> well, the one that I use LVM snapshots on, anyways
17:23:37 <sgallagh> tflink: Well, it's only if I call 'halt' or 'shutdown -r now' from the console.
17:23:45 <brunowolff> +1
17:23:47 <sgallagh> If I use the gnome menu, it works fine
17:23:52 <tflink> #agreed - 739836 - RejectedBlocker AcceptedNTH - This doesn't hit any of the release criteria since the machine does still shut down. However, delayed shutdown is an annoyance and would be nice to have fixed
17:24:05 <tflink> #topic (731266) TypeError: must be string, not None
17:24:05 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=731266
17:24:05 <tflink> #info Proposed Blocker, MODIFIED
17:24:07 <buggbot> Bug 731266: unspecified, unspecified, ---, akozumpl, MODIFIED, TypeError: must be string, not None
17:24:36 <brunowolff> #link http://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria
17:24:43 * tflink wonders if this was fixed already
17:24:49 <tflink> brunowolff: thanks, I forgot that one
17:25:04 <sgallagh> It's marked as MODIFIED in the bug
17:26:08 <tflink> proposed #agreed - 731266 - AcceptedBlocker - This bug intereferes with the final test case "NFSISO
17:26:11 <tflink> install variation"
17:26:12 <sgallagh> +1
17:26:39 <tflink> #agreed - 731266 - AcceptedBlocker - This bug intereferes with the final test case "NFSISO install variation"
17:26:56 * tflink is being a bit liberal for some of the obvious ones. I can undo if anyone has objections
17:27:05 <brunowolff> I was thinking that "The installer must be able to use all supported local and remote package source options" would be the criteria for this one.
17:27:21 <brunowolff> Anyway I do believe it is a blocker.
17:27:22 <tflink> #undo
17:27:22 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x10bf83ac>
17:27:52 <tflink> #agreed - 731266 - AcceptedBlocker - This bug intereferes with the final test case "NFSISO install variation" and violates the final critera "The installer must be able to use all supported local and remote package source options"
17:28:02 <brunowolff> +1
17:28:09 <tflink> that was supposed to be proposed, oh well
17:28:24 <tflink> #topic (733425) anaconda sets hostname to localhost.localdomain
17:28:24 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=733425
17:28:24 <tflink> #info Proposed Blocker, NEW
17:28:25 <buggbot> Bug 733425: medium, unspecified, ---, rvykydal, NEW, anaconda sets hostname to localhost.localdomain
17:29:10 <tflink> this sounds like a kickstart issue, no?
17:29:57 <brunowolff> I assume so with the reference to %post.
17:30:27 <tflink> possibly related:
17:30:33 <brunowolff> I am not sure how we tell which kickstart issues are blockers.
17:30:35 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=706073
17:30:36 <buggbot> Bug 706073: low, low, ---, dcbw, NEW, hostname no longer being set to dhcp hostname
17:30:44 <brunowolff> I am not too excited about this one though.
17:31:09 <sgallagh> I think this is NTH
17:31:22 <sgallagh> Relying on DHCP to set your hostname is a recipe for disaster anyway
17:31:54 <tflink> yeah NTH sounds fine to me
17:33:06 <brunowolff> I am not sure I'd go that far. At the very least I'd want a real safe fix before pulling in a new build for this.
17:33:08 <tflink> proposed #agreed - 733425 - RejectedBlocker AcceptedNTH - This is a somewhat obscure kickstart issue that doesn't hit any of the release criteria. However, it sounds like a fix is under way and it would be nice to see fixed.
17:33:23 <brunowolff> +1
17:33:53 <sgallagh> +1
17:33:54 <tflink> #agreed - 733425 - RejectedBlocker AcceptedNTH - This is a somewhat obscure kickstart issue that doesn't hit any of the release criteria. However, it sounds like a fix is under way and it would be nice to see fixed.
17:34:13 <tflink> #topic (739828) filtering screen shows loop devices
17:34:13 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=739828
17:34:13 <tflink> #info Proposed Blocker, POST
17:34:14 <buggbot> Bug 739828: medium, medium, ---, akozumpl, POST, filtering screen shows loop devices
17:35:08 <sgallagh> I'm not sure I understand the bug.
17:35:23 <brunowolff> I think this is NTH since it could cause some confusion and can't be fixed later, but see no reason to make it a blocker.
17:35:47 <tflink> it sounds like loop devices are showing up as potential installation targets
17:36:00 <sgallagh> Ah, having now looked at the screenshot it makes more sense
17:36:09 <sgallagh> Yeah, NTH
17:37:11 <tflink> we certainly don't have any criteria on unacceptable target devices
17:37:42 <sgallagh> I think it's okay to have too many devices listed.
17:37:47 <sgallagh> Too few would be a different story...
17:38:02 <tflink> since it's only on the advanced storage part, yeah I'm not as concerned with this
17:38:12 <brunowolff> But since it can't be fixed after the final release, I think it is a reasonable NTH candidate.
17:38:20 <tflink> if it was on the normal partitioning screen, I'd definitely be +1 blocker
17:39:40 <tflink> proposed #agreed - 739828 - RejectedBlocker AcceptedNTH - This doesn't hit any release criteria, only shows up with advanced storage devices and doesn't prevent installation. It can't be fixed post-release and looks bad to have in the installer.
17:40:06 <brunowolff> +1
17:40:16 <tflink> #agreed - 739828 - RejectedBlocker AcceptedNTH - This doesn't hit any release criteria, only shows up with advanced storage devices and doesn't prevent installation. It can't be fixed post-release and looks bad to have in the installer.
17:40:26 <tflink> #topic (740062) fcoe.py fails to detect FCoE NIC due to extraneous newline character
17:40:29 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=740062
17:40:31 <buggbot> Bug 740062: high, unspecified, ---, akozumpl, POST, fcoe.py fails to detect FCoE NIC due to extraneous newline character
17:40:32 <tflink> #info Proposed Blocker, POST
17:41:06 <tflink> comment 3 is odd
17:41:18 <tflink> not sure I understand why this has to be a blocker in order to fix
17:41:37 <brunowolff> I was hoping he meant that for Beta.
17:42:04 <tflink> yeah, that would make sense
17:42:19 <brunowolff> It certainly should be fixed between beta and final freezes.
17:42:28 <tflink> it does hit criteria, though
17:42:32 <tflink> "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
17:43:00 <brunowolff> Though it sounds like there is a work around, I'm leaning toward blocker.
17:43:17 <sgallagh> +1 blocker
17:43:21 <tflink> yeah, I'm +1 blocker on this
17:43:57 <tflink> proposed #agreed - 740062 - Violates the fedora 16 final release criterion: "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
17:44:00 <brunowolff> +1
17:44:01 <tflink> whoops
17:44:13 <tflink> proposed #agreed - 740062 - AcceptedBlocker -  Violates the fedora 16 final release criterion: "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
17:44:20 <tflink> #agreed - 740062 - Violates the fedora 16 final release criterion: "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
17:44:20 <brunowolff> +1
17:44:35 <tflink> #topic (741199) BOOTPROTO missing in ifcfg-eth0 in minimal install
17:44:35 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741199
17:44:35 <tflink> #info Proposed Blocker, NEW
17:44:36 <buggbot> Bug 741199: unspecified, unspecified, ---, rvykydal, NEW, BOOTPROTO missing in ifcfg-eth0 in minimal install
17:45:24 <tflink> I don't remember having to do this for beta test installs
17:45:43 <tflink> oh, nvm, I misunderstood
17:46:42 <tflink> I'm at least NTH on this
17:47:02 * tflink is looking for the related beta blocker/nth about autostarting network
17:47:33 <brunowolff> Is it using NM_CONTROLLED=no ?
17:48:11 <tflink> not sure
17:48:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=498207
17:48:23 <buggbot> Bug 498207: low, high, ---, rvykydal, CLOSED ERRATA, DVD install defaults to ONBOOT=no leaving networking down after reboot
17:48:31 <tflink> that was an NTH for beta
17:48:41 <brunowolff> I don't think network cares about BOOTPROTO.
17:49:30 <tflink> I thought that network.service was disabled by design on a minimal install
17:50:49 <tflink> I'm leaning towards punting on this one until we have more info
17:51:06 <sgallagh> It is, but the problem here is also that a simple 'service network start' doesn't work
17:51:15 <brunowolff> I think we should punt until we know more about what is supposed to happen.
17:51:18 <sgallagh> tflink: I'm okay with punting it, but I'm -1 blocker
17:51:47 <tflink> rejected blocker and proposed NTH, then?
17:52:00 <sgallagh> +1
17:52:10 <brunowolff> That seems reasonable.
17:52:44 <tflink> the part about service network start not working bugs me, even though I don't remember seeing it
17:52:56 <tflink> eh, it can be reproposed
17:53:42 <tflink> proposed #agreed - 741199 - RejectedBlocker proposed NTH - This doesn't hit any of the release criteria and there isn't quite enough information to determine NTH, will re-visit at next meeting
17:54:19 <tflink> #agreed - 741199 - RejectedBlocker proposed NTH - This doesn't hit any of the release criteria and there isn't quite enough information to determine NTH, will re-visit at next meeting and ask for more info in bug.
17:54:34 <tflink> #topic (741817) DispatchError: Can not reschedule step 'bootloader' from 'skipped' to 'requested'
17:54:37 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741817
17:54:38 <buggbot> Bug 741817: unspecified, unspecified, ---, akozumpl, ASSIGNED, DispatchError: Can not reschedule step 'bootloader' from 'skipped' to 'requested'
17:54:39 <tflink> #info Proposed Blocker, ASSIGNED
17:54:45 <brunowolff> I'm +1 blocker on this.
17:55:15 <tflink> yeah, same here
17:55:38 <tflink> the only reason it wasn't a beta blocker is that it's somewhat less common ATM
17:56:10 <sgallagh> Yeah, EFI installs on F15 are nearly nonexistent
17:56:38 <sgallagh> But nearly != completely.
17:56:43 <sgallagh> So yeah, blocker
17:56:55 <tflink> proposed #agreed - 741817 - AcceptedBlocker - Violates the Fedora 16 beta criteria "The installer must boot and run on systems using EFI other than Apple Macs"
17:57:01 <adamw> morning
17:57:15 <adamw> oh, jeez, i thought this was 11 again. sigh.
17:57:17 <tflink> adamw: look who finally shows up an hour late :-D
17:57:27 <adamw> for some reason i'm convinced blocker reviews are 11
17:57:31 <adamw> sorry :(
17:57:43 <brunowolff> +1
17:57:45 <tflink> 11 MDT until we hit DST
17:58:27 <tflink> #agreed - 741817 - AcceptedBlocker - Violates the Fedora 16 beta criteria "The installer must boot and run on systems using EFI other than Apple Macs"
17:58:42 <tflink> #topic (742123) DispatchError: Can not reschedule step 'group-selection' from 'requested' to 'skipped'
17:58:45 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742123
17:58:47 <buggbot> Bug 742123: unspecified, unspecified, ---, akozumpl, POST, DispatchError: Can not reschedule step 'group-selection' from 'requested' to 'skipped'
17:58:48 <tflink> #info Proposed Blocker, POST
17:59:25 <tflink> eh, I'm thinking -1 blocker , +1 NTH on this
17:59:26 <adamw> looks pretty simple
17:59:47 <adamw> isn't 'customize later' the default choice?
17:59:53 <adamw> so you'd hit this with any kickstart without %packages?
18:00:12 <tflink> why would you use a kickstart w/o packages?
18:00:34 <sgallagh> tflink: minimal install?
18:00:35 <tflink> is that supposed to trigger a default install?
18:01:12 <adamw> no
18:01:17 <adamw> it just means you do the packaging step interactively
18:01:29 <adamw> anything you don't expressly specify in the kickstart gets done interactively
18:01:45 <adamw> i dunno, if you want to nth it that's fine, it's gonna get fixed either way
18:01:56 <brunowolff> I think this is at least NTH, I'm not sure about blocker.
18:02:01 <adamw> +1 nth then
18:02:14 <tflink> so if you do a ks w/ the intention of handling packages and select default - crash?
18:03:35 <tflink> proposed #agreed - 742123 - RejectedBlocker AcceptedNTH - This doesn't clearly hit any release criteria but it would likely hit any ks installation w/ interactive package selection
18:04:51 <adamw> tflink: that's what it looks like to me.
18:04:56 <tflink> ack/nak/patch?
18:05:04 <brunowolff> +1
18:05:11 <adamw> ack
18:05:26 <tflink> #agreed - 742123 - RejectedBlocker AcceptedNTH - This doesn't clearly hit any release criteria but it would likely hit any ks installation w/ interactive package selection
18:05:34 <tflink> #topic (740625) After update to 3.1.92, can't submit password on login window
18:05:37 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=740625
18:05:39 <buggbot> Bug 740625: urgent, unspecified, ---, mclasen, NEW, After update to 3.1.92, can't submit password on login window
18:05:40 <tflink> #info Proposed Blocker, NEW
18:06:43 <tflink> sounds fixed/dupe?
18:06:57 <adamw> i wouldn't be sure yet
18:06:59 <brunowolff> I am not seeing that.
18:07:25 <adamw> reporter has the atk-spi2-atk package version that is 'fixed'
18:07:49 <adamw> as described, looks like +1 blocker to me, ray seems to be doing a thorough job of investigating
18:08:17 <adamw> i'd say "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention."
18:08:33 <sgallagh> +1 blocker
18:09:18 <tflink> proposed #agreed - 740625 - AcceptedBlocker - Violates the Fedora 16 alpha criteria: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any
18:09:44 <brunowolff> +1
18:10:08 <adamw> ack
18:10:16 <tflink> #agreed - 740625 - AcceptedBlocker - Violates the Fedora 16 alpha criteria: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted
18:10:23 <tflink> #topic (706756) No translation on Login-Page of the reboot-menu
18:10:25 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=706756
18:10:26 <buggbot> Bug 706756: medium, unspecified, ---, rstrode, NEW, No translation on Login-Page of the reboot-menu
18:10:28 <tflink> #info Proposed Blocker, NEW
18:12:21 <adamw> this is tricky, as we don't really have translation criteria
18:12:49 <tflink> we probably should, at least NTH
18:12:55 <adamw> i could see adding to the criterion akira cited though
18:13:14 <adamw> well, no, not that one.
18:13:20 <adamw> but...yeah, we probably need something.
18:13:39 <adamw> we could +1 nth and table blocker status, aim to propose a translation criterion this week?
18:13:50 <tflink> sounds like a plan to me
18:13:51 <brunowolff> That sounds reasonable.
18:14:36 <tflink> proposed #agreed - 705756 - AcceptedNTH - There aren't any criteria for translations at this time but there probably should be. Will propose translation criteria and re-visit next week.
18:14:43 <brunowolff> +1
18:15:00 <sgallagh> +1
18:15:08 <tflink> #agreed - 705756 - AcceptedNTH - There aren't any criteria for translations at this time but there probably should be. Will propose translation criteria and re-visit next week.
18:15:12 <tflink> #topic (738092) swell-foop blank screen
18:15:14 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=738092
18:15:15 <buggbot> Bug 738092: unspecified, unspecified, ---, rstrode, NEW, swell-foop blank screen
18:15:17 <tflink> #info Proposed Blocker, NEW
18:15:52 <tflink> if this is included by default, +1 blocker
18:16:47 <tflink> proposed #agreed - 738092 - AcceptedBlocker - Violates the Fedora 16 final release criteria: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
18:17:52 <adamw> yup
18:17:53 <adamw> ack
18:18:05 <tflink> #agreed - 738092 - AcceptedBlocker - Violates the Fedora 16 final release criteria: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
18:18:12 <adamw> (and it's still valid in 3.2.0)
18:18:17 <tflink> #topic (730985) Customizing panel objects / layout with 'Alt + Right Click' not working
18:18:20 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=730985
18:18:21 <buggbot> Bug 730985: unspecified, unspecified, ---, rstrode, NEW, Customizing panel objects / layout with 'Alt + Right Click' not working
18:18:22 <tflink> #info Proposed Blocker, NEW
18:18:46 * adamw picks up secretary duties
18:19:04 <tflink> thanks
18:19:12 <tflink> I did the go/no-go stuff this morning
18:19:49 <adamw> cool
18:20:30 <adamw> so...couple things...
18:20:32 <brunowolff> I can use alt rc to move stuff around on the panel in fallback mode or to set panel properties.
18:20:35 <adamw> how does this interfere with that test case?
18:20:53 <adamw> and interfering with test cases is usually more a reason to change the test case than consider the bug a blocker
18:21:05 <tflink> I had lots of brain farts that day, this could be an error
18:21:06 <brunowolff> If they meant to set preferences for an item and not the panel then you need to not use alt.
18:21:22 <adamw> tflink: you could be thinking of one of the panel test cases
18:21:33 <adamw> athmane is usually pretty on the ball
18:21:39 <adamw> brunowolff: is this a clean install or an updated one?
18:21:48 <brunowolff> Updated.
18:21:52 <tflink> I was referring to me proposing it as a blocker, not athmane's testing
18:22:12 <adamw> yeah, i was replying to bruno
18:22:18 <adamw> the relevant criterion here would be "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use "
18:22:20 <brunowolff> (Also updates-testing.)
18:22:33 <adamw> so if the bug report is true, it would depend whether this was 'intended' or not.
18:22:40 <adamw> maybe we can ask athmane to confirm with beta
18:23:04 <tflink> yeah, I had the wrong test case
18:23:21 <tflink> it's "Testcase_desktop_panel_basic"
18:23:30 <tflink> https://fedoraproject.org/wiki/QA:Testcase_desktop_panel_basic
18:23:51 <brunowolff> I think it would be a blocker, but I suspect the issue has been fixed.
18:24:18 <tflink> yeah, same here
18:24:19 <adamw> okay
18:24:24 <adamw> let's accept it but ask athmane to update?
18:24:26 <adamw> so +1
18:24:29 <brunowolff> +1
18:25:57 <tflink> proposed #agreed - 730985 - AcceptedBlocker - Interferes with the "Testcase_desktop_panel_basic" testcase and hits the beta criteria "No part of any release-blocking desktop's panel (or equivalent) configuration should crash or be entirely non-functional on boot of the installed system using default installation choices". Suspect that this has been fixed, ask for re-test in bug.
18:26:09 <tflink> this should have been a beta blocker, not final
18:26:22 * tflink wonders if he got any of those right after beta
18:26:28 <tflink> alpha
18:26:34 <tflink> ... and it continues
18:26:51 <adamw> heh
18:27:09 <tflink> #agreed - 730985 - AcceptedBlocker - Interferes with the "Testcase_desktop_panel_basic" testcase and hits the beta criteria "No part of any release-blocking desktop's panel (or equivalent) configuration should crash or be entirely non-functional on boot of the installed system using default installation choices". Suspect that this has been fixed, ask for re-test in bug.
18:27:17 <tflink> #topic (731251) SELinux is preventing /bin/bash from 'getattr' accesses on the archivo /lib/systemd/system/chronyd.service.
18:27:20 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=731251
18:27:21 <buggbot> Bug 731251: unspecified, unspecified, ---, bnocera, MODIFIED, SELinux is preventing /bin/bash from 'getattr' accesses on the archivo /lib/systemd/system/chronyd.service.
18:27:23 <tflink> #info Proposed Blocker, MODIFIED
18:27:23 <brunowolff> +1 blocker
18:27:28 <sgallagh> +1 blocker
18:28:14 <adamw> well
18:28:21 <adamw> that criterion really means "when you boot the system and log in"
18:28:24 <adamw> not anything else
18:28:31 <adamw> if we take this as a blocker, it would have to be a different criterion
18:28:53 <adamw> the only real candidate is "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items "
18:30:38 <adamw> oh, wait
18:30:40 <adamw> is this firstboot?
18:30:44 <adamw> i was thinking it's gnome's tool
18:31:05 <tflink> yeah, that's what I thought, too
18:31:43 <tflink> no, not firstboot
18:31:55 <tflink> see comment 6
18:32:03 <brunowolff> It happened on a live image, so not firstboot.
18:32:15 <adamw> yeah..so, i'm =1
18:32:20 <adamw> er, -1
18:32:49 <adamw> it's dangerous to read the selinux criteria too broadly or we'd just wind up with way too many blockers
18:33:03 <tflink> my bad
18:33:21 <brunowolff> I forget about that as well.
18:33:21 <adamw> this has happened before, maybe that criterion needs more clear wording somehow
18:33:32 <adamw> so it doesn't get read as 'login and use'
18:33:45 <brunowolff> Anyway there seems to be a fix, so I am not too worried about what we call it.
18:33:53 <tflink> maybe put the initial boot and login at the beginning of the sentance
18:33:57 <tflink> yeah, same here
18:33:58 <adamw> yeah
18:34:03 <adamw> +1 nth, -1 blocker
18:34:27 <adamw> (nth as it's live-visible)
18:34:28 <brunowolff> I'll change to that. +1 NTH -1 Blocker.
18:34:50 <tflink> proposed #agreed - 731251 - RejectedBlocker AcceptedNTH - Doesn't hit any of the release criteria but would be nice to see fixed. There should be a fix available, needs testing
18:35:01 <brunowolff> +1
18:35:14 <tflink> #agreed - 731251 - RejectedBlocker AcceptedNTH - Doesn't hit any of the release criteria but would be nice to see fixed. There should be a fix available, needs testing
18:35:29 <tflink> #topic (735273) Command <grub2-mkconfig -o /boot/grub2/grub.cfg> finds Windows partition, adds to grub menu, but menu entry will not boot
18:35:32 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=735273
18:35:33 <buggbot> Bug 735273: unspecified, unspecified, ---, pjones, NEW, Command <grub2-mkconfig -o /boot/grub2/grub.cfg> finds Windows partition, adds to grub menu, but menu entry will not boot
18:35:34 <tflink> #info Proposed Blocker, NEW
18:37:06 <adamw> so, bob's had this for a while, but unfortunately, we're struggling to reproduce...
18:37:24 * tflink hasn't tried a dualboot system
18:37:56 <adamw> i tested at alpha and it worked
18:38:06 <adamw> jon tested with XP and 7 and it worked
18:38:09 <adamw> hey bob
18:38:10 <tflink> ask for more testing, re-visit next week?
18:38:13 <adamw> we're playing your tune :)
18:39:02 <BobLfoot> hey adamw
18:40:02 <adamw> we're on your windows dual boot bug
18:40:16 <adamw> so i just had a thought: on the affected install, does windows boot if you restore the windows bootloader to the mbr?
18:40:26 <adamw> (i think you can do that from windows' rescue mode or smth)
18:40:30 <BobLfoot> my waking up timing is perfect then -- can I add any input / assistance?
18:40:58 <adamw> we're mostly just scratching our heads as before, wondering why it works for me and jon but is broke for you...
18:41:25 <BobLfoot> So am I
18:42:18 <adamw> the other question is whether it's reproducible - if you set up a new VM from scratch and do the same thing, does it break?
18:44:00 <tflink> How about ask for more testing in an attempt to reproduce, revisit next week and reject if no reproducers
18:44:07 <BobLfoot> I've hacen't setup a new vm since beta.rc2 ; been tar -zxf
18:44:35 <BobLfoot> I'm good with that ; it'll give me time to create a new windows vm from scratch
18:44:43 <adamw> tflink: yeah, as things stand i'd be slightly -1 as this is a fairly permissive criterion: it's more of a 'well, it's gotta work at least sometimes' criterion than a 'it must work in every case' one
18:45:11 <adamw> but obviously it'd be easier to judge with more testing, or if we manage to debug precisely what's wrong in bob's case
18:45:21 <tflink> proposed #agreed - 735273 - Ask for more testing in an attempt to reproduce, revisit next week and reject if no reproducers
18:45:40 <tflink> 'cause we've been at this for almost 2 hours already and still have a LONG way to go
18:46:13 <tflink> I count 13 proposed blockers remaining
18:46:32 <adamw> ack
18:46:42 <tflink> we're only about halfway through :(
18:46:56 <tflink> #agreed - 735273 - Ask for more testing in an attempt to reproduce, revisit next week and reject if no reproducers
18:47:08 <tflink> #topic (737339) Default timeouts are too long
18:47:09 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=737339
18:47:09 <tflink> #info Proposed Blocker, NEW
18:47:10 <buggbot> Bug 737339: unspecified, unspecified, ---, pjones, NEW, Default timeouts are too long
18:48:10 <tflink> -1 blocker, +~.3 NTH
18:49:20 <adamw> i think this was actually changed in beta, wasn't it?
18:49:27 <adamw> i somehow have the feeling it got dropped to 5s
18:49:28 <tflink> I think it was changed to be shorter
18:49:42 * tflink remembers a change in anaconda to do that
18:49:50 <adamw> https://admin.fedoraproject.org/updates/FEDORA-2011-13118
18:49:57 <adamw> Bugs Fixed
18:49:57 <adamw> 727831 - Default GRUB timeout is 20 seconds
18:50:06 <adamw> so, i guess this bug is a dupe
18:50:27 <adamw> yup. +1 dupe it and move on
18:50:48 <tflink> #agreed - 737339 - DUPLICATE of 727831
18:51:05 <tflink> #topic (738977) grub2 defaults to boot "saved" seems wrong
18:51:05 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=738977
18:51:05 <tflink> #info Proposed Blocker, NEW
18:51:08 <buggbot> Bug 738977: unspecified, unspecified, ---, pjones, NEW, grub2 defaults to boot "saved" seems wrong
18:51:52 <adamw> i still don't think this is correct...
18:52:02 <adamw> any time i install a vm and then install a kernel update, a reboot boots to the new kernel, not the old one
18:52:06 <adamw> anyone else noticed this?
18:52:19 <tflink> I haven't had any trouble with this
18:52:51 <BobLfoot> my dsl is slow - is this bug saying that updates to kernel boot old kernel not new?
18:52:57 <adamw> yes
18:53:06 <BobLfoot> haven't seen that here
18:53:20 <adamw> i'm probably -1 blocker anyway as this is something that could be fixed with an update
18:53:48 <brunowolff> There is a setting that controls this behavior. Could he have set it accidentally.
18:54:09 <adamw> reject and move on, or needinfo and move on, i reckon
18:54:19 <tflink> proposed #agreed - 738977 - RejectedBlocker - This doesn't clearly hit any release criteria, hasn't been seen elsewhere and could be fixed with an update
18:54:29 <brunowolff> I know I managed to do that one time and it took me a while to find what I needed to change to fix things.
18:54:37 <adamw> ack!
18:54:55 <brunowolff> +1
18:54:58 <tflink> proposed #agreed - 738977 - RejectedBlocker - This doesn't clearly hit any release criteria, hasn't been seen elsewhere and could be fixed with an update
18:55:01 <tflink> gah
18:55:04 <adamw> heh
18:55:09 <tflink> #agreed - 738977 - RejectedBlocker - This doesn't clearly hit any release criteria, hasn't been seen elsewhere and could be fixed with an update
18:55:17 <tflink> #topic (742226) /sbin/grub2-probe: error: cannot find a GRUB drive for /dev/mapper/nvidia_cjfffajep2
18:55:20 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=742226
18:55:23 <tflink> #info Proposed Blocker, NEW
18:55:25 <buggbot> Bug 742226: unspecified, unspecified, ---, pjones, NEW, /sbin/grub2-probe: error: cannot find a GRUB drive for /dev/mapper/nvidia_cjfffajep2
18:56:29 <adamw> this is the bios raid issue we proposed for beta and decided to punt on
18:56:43 <adamw> i think we probably need to wait for more data to decide on final status, we still don't have a really clear idea of the bug
18:56:54 <tflink> yeah, I was thinking the same thing
18:57:10 <tflink> to be honest, I'm not sure this hits any release criteria to the letter
18:57:12 <adamw> hopefully pjones may have come up with a fix or at least more details by next time
18:57:18 <tflink> but I'm splitting hairs here
18:57:19 <adamw> well, it clearly hits the one about RAID installs
18:57:27 <tflink> it installs, doesn't it?
18:57:32 <tflink> it just doesn't boot afterwards
18:57:37 <adamw> heh.
18:57:43 <tflink> nvm
18:57:46 <adamw> i...would not agree with that interpretation =)
18:57:56 <tflink> like I said ... I'm splitting hairs
18:58:04 <adamw> i think the 'boot' criterion says 'any system installed in accordance with the other criteria must boot'
18:58:09 <adamw> so i think we closed that loophole, sorry :)
18:58:09 * tflink isn't proposing that we sweep it under the rug
18:58:27 <tflink> a system that installs but doesn't run is useless
18:58:36 <brunowolff> We still don't support ALL hardware.
18:58:41 <adamw> yeah
18:58:55 <tflink> proposed #agreed - 742226 - We need information before taking action on this bug, the exact issue and resolution still aren't clear
18:58:55 <adamw> so if this turned out to be very specific to james' system we'd probably make it not a blocker
18:59:08 <adamw> but it may affect all dmraid RAID-0 installs or something, which would be a bigger problem
18:59:21 <adamw> i did get a similar fail with my intel controller + raid-0
18:59:34 <adamw> ack
18:59:45 <brunowolff> +1
18:59:52 <tflink> #agreed - 742226 - We need information before taking action on this bug, the exact issue and potential resolution still aren't clear
19:00:00 <tflink> #topic (704244) Add info about BIOS boot partition on non-EFI x86
19:00:00 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=704244
19:00:00 <tflink> #info Proposed Blocker, NEW
19:00:11 <buggbot> Bug 704244: unspecified, unspecified, ---, david, NEW, Add info about BIOS boot partition on non-EFI x86
19:00:17 <tflink> I thought this was already fixed
19:00:42 <BobLfoot> Sorry I must away so soon -- wish I had more time to help ; will read logs when I return ; keep up good work zappers.
19:01:08 <tflink> dupe of https://bugzilla.redhat.com/show_bug.cgi?id=731549  ?
19:01:09 <buggbot> Bug 731549: unspecified, unspecified, ---, dlehman, CLOSED ERRATA, message about BIOS boot partitions and GPT disklabels is hard to understand
19:01:24 <adamw> thanks bob
19:02:04 <adamw> tflink: no
19:02:07 <adamw> this is filed on the install guide
19:02:15 <adamw> we wanted it to be documented there
19:02:24 <tflink> oh, didn't see that
19:02:30 <adamw> the fact that the installer warns you about this could make this bug less important, i guess
19:02:56 <adamw> it's still valid - the install guide should have a clear, in-depth explanation of the issue - but as the installer mostly saves you from shooting yourself in the foot it may not be a blocker
19:03:04 <adamw> the only issue is that right now the installer doesn't save you in *all* cases
19:03:14 <adamw> we fudged the custom install path for beta
19:04:02 <tflink> I'm at least NTH on this
19:04:07 <adamw> i think this is probably -1 blocker, it's hard to argue it hits any blocker criteria
19:04:13 <adamw> but +1 nth
19:05:02 <tflink> proposed #agreed - 704244 - RejectedBlocker AcceptedNTH - Documentation doesn't hit any of the release criteria but this should be fixed before release.
19:06:03 <adamw> ack
19:06:11 <tflink> #agreed - 704244 - RejectedBlocker AcceptedNTH - Documentation doesn't hit any of the release criteria but this should be fixed before release.
19:06:21 <tflink> #topic (676488) update showing Error message ??? instead of actual error message
19:06:24 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=676488
19:06:25 <buggbot> Bug 676488: unspecified, unspecified, ---, smparrish, NEW, update showing Error message ??? instead of actual error message
19:06:27 <tflink> #info Proposed Blocker, NEW
19:06:48 <tflink> another i18n issue?
19:06:55 <tflink> from february
19:07:32 <tflink> same treatment as the last i18n bug? NTH and re-visit once we have i18n criteria?
19:08:16 <adamw> yeah
19:08:27 <adamw> this one definitely sounds like something we'd want to take...so we need that criterion :)
19:08:29 <tflink> proposed #agreed - 676488 - AcceptedNTH - We don't have any i18n criteria right now, will be proposing in the next week and will re-visit then.
19:08:40 <adamw> ack
19:08:43 <tflink> yeah, this is a blocker as far as I'm concerned
19:08:50 <tflink> #agreed - 676488 - AcceptedNTH - We don't have any i18n criteria right now, will be proposing in the next week and will re-visit then.
19:08:58 <tflink> #topic (727068) System fails to boot with selinux=0 :: mount failed for selinuxfs on /sys/fs/selinux
19:09:01 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=727068
19:09:03 <buggbot> Bug 727068: medium, unspecified, ---, dwalsh, MODIFIED, System fails to boot with selinux=0 :: mount failed for selinuxfs on /sys/fs/selinux
19:09:04 <tflink> #info Proposed Blocker, MODIFIED
19:09:50 <tflink> proposed #agreed - 727068 - AcceptedBlocker - Hits the Fedora 16 final criteria: "The installed system must run normally if the user chooses to install without SELinux"
19:10:39 <adamw> well...
19:10:41 <adamw> it doesn't quite hit that
19:10:51 <adamw> if you install without selinux, you don't hit the configuration that triggers this bug
19:11:06 <tflink> oh, good point
19:11:11 <adamw> the criteria don't actually cover the case where you have selinux installed, but disable it with the kernel parametert
19:11:25 <adamw> if enforcing=0 works, i'd be reluctant to take this as a blocker
19:11:57 <tflink> yeah, that makes sense
19:11:57 <adamw> i'm actually -1 blocker -1 nth on this
19:12:07 <adamw> there's just too many workarounds / other ways to achieve, and no particular install-time sensitivity
19:12:15 <tflink> doesn't really matter all that much, since it's fixed
19:12:24 <tflink> supposed to be fixed anyways
19:12:41 <adamw> yeah, i wonder why the bug got stuck in modified
19:12:52 <adamw> so, reject and close, i guess
19:13:21 <tflink> proposed #agreed - 727068 - RejectedBlocker RejectedNTH - This doesn't hit any of the release criteria and there are plenty of easy workaround.
19:13:24 <tflink> proposed #agreed - 727068 - RejectedBlocker RejectedNTH - This doesn't hit any of the release criteria and there are plenty of easy workarounds
19:13:32 <brunowolff> +1
19:13:32 <adamw> oh
19:13:34 <tflink> it hasn't been pushed to stable yet, I think
19:13:36 <adamw> it was probably only *just* pushed
19:13:51 <tflink> #agreed - 727068 - RejectedBlocker RejectedNTH - This doesn't hit any of the release criteria and there are plenty of easy workarounds
19:13:58 <adamw> Date Released: 	2011-09-30 18:27:04
19:14:00 <adamw> ack
19:14:04 <tflink> #topic (741950) F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest
19:14:07 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741950
19:14:09 <buggbot> Bug 741950: unspecified, unspecified, ---, mgracik, NEW, F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest
19:14:10 <tflink> #info Proposed Blocker, NEW
19:14:41 <tflink> ah, that's why he was asking about lorax-17.0
19:15:37 <tflink> I'd be +1 NTH on this
19:15:56 <tflink> from the Xen criteria discussion on test@, I'd say that blocker is unlikely
19:16:51 <adamw> er, really?
19:17:00 <adamw> we had only four replies to the proposal
19:17:06 <adamw> konrad is clearly +1
19:17:15 <adamw> i was +/-0 so far more or less
19:17:37 <adamw> davej seemed quite enthusiastic, say +0.5, and so was Andy
19:17:48 <adamw> okay, all the positive responses are 'interested parties', but i didn't see anyone say 'no'
19:17:57 <tflink> point taken
19:18:34 <adamw> i'd say we should punt and try to refresh the xen discussion
19:18:40 <adamw> maybe get more info about the ec2 case for e.g.
19:19:03 <tflink> if I'm really motivated, I'll take a look @ lorax
19:19:57 <tflink> proposed #agreed - 741950 - We still haven't finished hashing out the Xen release requirements, will refresh that discussion and re-visit this bug later
19:20:15 <tflink> 6 left!
19:20:55 <adamw> ack
19:21:06 <tflink> #agreed - 741950 - We still haven't finished hashing out the Xen release requirements, will refresh that discussion and re-visit this bug later
19:21:15 <tflink> #topic (741655) can't boot with encrypted logical volume inside encrypted volume group
19:21:18 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741655
19:21:19 <buggbot> Bug 741655: unspecified, unspecified, ---, lvm-team, NEW, can't boot with encrypted logical volume inside encrypted volume group
19:21:21 <tflink> #info Proposed Blocker, NEW
19:21:34 <tflink> I'm -1 blocker on this
19:23:00 <tflink> it'd be nice if anaconda gave more warning, though
19:23:50 <adamw> it's kinda arguable whether it meets the "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above " criterion
19:24:15 <adamw> that's meant to be a broad criterion, but it doesn't specify encryption, and that is a kind of different consideration as it involves more stuff than just anaconda's partitioning logic
19:24:24 <adamw> it brings plymouth and systemd and whatever else into the game
19:24:50 <tflink> NTH?
19:24:57 <adamw> yeah...i think so
19:25:08 <adamw> for encryption we only require the installer checkbox to work, not 'any encrypted layout you can design'
19:26:36 <tflink> proposed #agreed - 741655 - RejectedBlocker AcceptedNTH - This does come close to hitting the Fedora 16 final release criteria: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" but with the encryption scheme here, it doesn't squarely hit. However, it would be nice to have this boot o
19:26:45 <tflink> ooh, nice and verbose
19:26:59 <brunowolff> +1
19:27:33 <adamw> ack
19:27:37 <tflink> #agreed - 741655 - RejectedBlocker AcceptedNTH - This does come close to hitting the Fedora 16 final release criteria: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" but with the encryption scheme here, it doesn't squarely hit. However, it would be nice to have this boot or get a w
19:27:40 <adamw> (actually, already updated the bug, so you BETTER ack) :)
19:27:56 * tflink contemplates #undo
19:28:05 <tflink> but wants to be done with this
19:28:07 <tflink> #topic (726979) kwrite crashes in "Configure editor" (under some conditions)
19:28:09 <adamw> oh, move on
19:28:10 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=726979
19:28:11 <buggbot> Bug 726979: unspecified, unspecified, ---, than, ASSIGNED, kwrite crashes in "Configure editor" (under some conditions)
19:28:13 <tflink> #info Proposed Blocker, ASSIGNED
19:28:40 <adamw> seems like a blocker
19:28:55 <adamw> "All applications listed under the Applications menu or category must start successfully "
19:28:55 <tflink> "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
19:29:00 <adamw> yeah, either of those
19:29:11 <adamw> (the 'start successfully' criterion is probably redundant, really.)
19:29:15 <adamw> +1
19:29:37 <tflink> proposed #agreed - 726979 - AcceptedBlocker - Hits the following Fedora 16 final release criteria: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
19:30:38 <tflink> #agreed - 726979 - AcceptedBlocker - Hits the following Fedora 16 final release criteria: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
19:30:48 <tflink> #topic (723709) FTBFS: qt-mobility against qt-4.8.0-beta1
19:30:48 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=723709
19:30:48 <tflink> #info Proposed Blocker, ON_QA
19:30:49 <buggbot> Bug 723709: unspecified, unspecified, ---, rdieter, ON_QA, FTBFS: qt-mobility against qt-4.8.0-beta1
19:31:16 <brunowolff> I don't think FTBFS is a blocker on its own.
19:31:27 <adamw> right
19:31:32 <tflink> it got pulled in from a tracker
19:31:49 <adamw> ah
19:31:56 <adamw> oh, that KDE tracker.
19:32:00 <tflink> and the tracker blocks KDE
19:32:04 <adamw> meh, it's modified anyway. let's punt on it.
19:32:14 <adamw> it'll go away next week and we won't have to care!
19:32:22 * adamw is willing to give KDE team a bit of a long leash, as they usually know what they're doing
19:32:31 <brunowolff> Just say NTH?
19:32:45 <adamw> nah, nth makes no real sense.
19:32:52 * adamw wants to avoid the 'whatever, call it nth' trap
19:33:16 <adamw> if they put it on the tracker, it probably means it does cause some significant problem.
19:33:21 <tflink> proposed #agreed - 723709 - Need more information on how this bug is a blocker before making a decision, will re-visit
19:33:28 <adamw> they don't just throw any old crap on the KDE tracker.
19:33:32 <adamw> ack
19:33:34 <brunowolff> I like that.
19:33:40 <tflink> it looks to be blocking the build of new qt
19:33:43 <brunowolff> +1
19:33:51 <tflink> #agreed - 723709 - Need more information on how this bug is a blocker before making a decision, will re-visit
19:33:58 <tflink> #topic (728857) virtuoso-opensource: encoding error with KDE NEPOMUK.
19:33:58 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=728857
19:33:58 <tflink> #info Proposed Blocker, ON_QA
19:33:59 <buggbot> Bug 728857: medium, unspecified, ---, rdieter, ON_QA, virtuoso-opensource: encoding error with KDE NEPOMUK.
19:34:12 <tflink> another KDE blocker
19:34:49 <adamw> yeah, we're in the kde blocker deps here obviously.
19:34:50 <tflink> proposed #agreed - 728857 - Need more information on how this bug is a blocker before making a decision, will re-visit
19:34:54 <tflink> recycle!
19:35:24 <adamw> i think this hits "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items "
19:35:43 <adamw> because it means the desktop search bit of KDE doesn't work right, as indexing doesn't work right
19:35:48 <adamw> i'd be okay with +1 under that criterion
19:36:01 <tflink> oh, I was thinking virtuoso was something different
19:36:33 <adamw> i think virtuoso is used as part of the indexing process
19:36:40 <brunowolff> I think that would make it a blocker.
19:36:46 <adamw> but the ultimate user-visible effect of the bug is 'none of my desktop search stuff works because the indexes are borked'
19:37:00 <adamw> "You will reindex this file constantly" is also nasty as it'll cause increased resource use
19:37:32 <tflink> proposed #agreed - 728857 - AcceptedBlocker - Hits the following Fedora 16 final release criterion: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
19:37:41 <adamw> ack
19:37:53 <brunowolff> +1
19:37:59 <tflink> #agreed - 728857 - AcceptedBlocker - Hits the following Fedora 16 final release criterion: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items"
19:38:14 * tflink was thinking virtuoso was a virtualization tool
19:38:48 <tflink> #topic (731245) KDE fails to start inside a VM , large amount of memory [@ miCopyRegion]
19:38:52 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=731245
19:38:53 <buggbot> Bug 731245: high, unspecified, ---, sandmann, NEW, KDE fails to start inside a VM , large amount of memory [@ miCopyRegion]
19:38:54 <tflink> #info Proposed Blocker, NEW
19:39:29 <adamw> oh, god, this one.
19:39:35 <adamw> been around since alpha, we never get time to look into ti.
19:40:23 <tflink> isn't this more of a beta blocker, anyways?
19:40:28 <tflink> "The release must boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release (using Fedora's current preferred virtualization technology)"
19:40:52 <adamw> good thing i smuggled that one past you. =)
19:40:58 <adamw> well, there's a workaround - use 'basic graphics mode'
19:41:08 <tflink> or spice, I think
19:41:09 <adamw> but...yeah. it kinda sucks. it would be ugly to release this way
19:41:16 <adamw> nah, i'm using spice when i hit the bug
19:41:23 <tflink> ok
19:41:38 <adamw> dunno what oliver did
19:41:43 <tflink> either way, I'm +1 blocker on this since the same bug would be a blocker for gnome
19:41:50 <adamw> yeah. i think we should take it.
19:42:05 <adamw> i can imagine there being pressure to fudge it if this was the last blocker on go/no-go day, but...let's be firm. :)
19:42:14 <adamw> +1
19:42:28 <adamw> i'll try to suck less at investigating it and helping kevin fix
19:42:29 <tflink> proposed #agreed - 731245 - AcceptedBlocker - Hits the following Fedora 16 beta release criteria: "The release must boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release (using Fedora's current preferred virtualization technology)"
19:42:32 <adamw> ack
19:42:44 <brunowolff> +1
19:42:46 <tflink> #agreed - 731245 - AcceptedBlocker - Hits the following Fedora 16 beta release criteria: "The release must boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release (using Fedora's current preferred virtualization technology)"
19:42:51 <tflink> LAST ONE!
19:42:59 <tflink> #topic (725219) anaconda should run in clone not span mode
19:42:59 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=725219
19:42:59 <tflink> #info Proposed Blocker, NEW
19:43:00 <buggbot> Bug 725219: low, unspecified, ---, ajax, NEW, anaconda should run in clone not span mode
19:43:51 <tflink> +1 NTH, not so sure about blocker
19:44:06 <tflink> workaround -> unplug one of your monitors
19:44:15 <adamw> yeah
19:44:22 <adamw> it's annoying, but the workaround's reasonable.
19:44:40 <tflink> sounds like it got proposed so that it didn't get lost
19:45:14 <adamw> yeah
19:45:19 <adamw> that's not a terribly convincing blocker proposal =)
19:45:57 <tflink> proposed #agreed - 725219 - RejectedBlocker AcceptedNTH - This doesn't hit any of the release criteria and the workaround is simple (unplug one monitor) but it would be nice to fix.
19:46:03 <brunowolff> +1
19:46:25 <tflink> #agreed - 725219 - RejectedBlocker AcceptedNTH - This doesn't hit any of the release criteria and the workaround is simple (unplug one monitor) but it would be nice to fix.
19:47:09 <tflink> OK, done with the proposed blockers!
19:47:21 * tflink is tempted to leave the proposed NTH for next week
19:47:40 <tflink> looks like there are 8
19:48:06 <adamw> i could do 'em this week, but if you're really flagging, we can punt
19:48:16 <adamw> it's not super important to make a call on those until freeze time
19:48:23 <tflink> says the man who showed up an hour late :-P
19:48:48 <tflink> alrighty, let's just get this over with
19:48:50 <tflink> #topic (734967) /sbin/loader received SIGSEGV when using kickstart file.
19:48:53 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=734967
19:48:54 <buggbot> Bug 734967: high, unspecified, ---, akozumpl, POST, /sbin/loader received SIGSEGV when using kickstart file.
19:48:55 <tflink> #info Proposed NTH, POST
19:49:25 <adamw> oh, yeah, we should do the anaconda ones at least
19:49:35 <adamw> as anaconda have a strict policy of not pushing anything unless it's nth or blocker these days
19:49:40 <adamw> so we want to get their fixes in for tc
19:49:52 <adamw> i'm basically +1 nth for any anaconda crash, so +1.
19:50:14 <tflink> yeah, I'm ok with NTH
19:50:44 <tflink> proposed #agreed - 734967 - AcceptedNTH - This fixes an anaconda crash and a fix is ready.
19:50:51 <adamw> ack
19:51:30 <tflink> #agreed - 734967 - AcceptedNTH - This fixes an anaconda crash and a fix is ready.
19:51:43 <tflink> #topic (738607) sshd doesn't work
19:51:43 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=738607
19:51:43 <tflink> #info Proposed NTH, NEW
19:51:44 <buggbot> Bug 738607: unspecified, unspecified, ---, mgracik, NEW, sshd doesn't work
19:52:16 <adamw> hum
19:52:24 <adamw> since this has been this way approximately forever, not sure if i
19:52:26 <adamw> i'd NTH it
19:52:40 <tflink> yeah, c10 says something similar
19:53:03 <adamw> the only issue is the tight anaconda policy now, but that shouldn't mean we NTH anything that we think it's okay for anaconda to change outside of a freeze, it means we should talk to them about tweaking their policy a tad
19:53:19 <brunowolff> Plus if it ends up being RFE, then there won't be incentive to do it soon.
19:53:22 <adamw> so, by the actual intended purpose of the NTH process, -1, this isn't the kind of change i'd want to take through a freeze.
19:54:08 <tflink> proposed #agreed - 738607 - RejectedNTH - This is more of an RFE than a bug and not something that really needs to be taken during code freeze
19:54:27 <brunowolff> +1
19:54:37 <tflink> #agreed - 738607 - RejectedNTH - This is more of an RFE than a bug and not something that really needs to be taken during code freeze
19:54:43 <tflink> #topic (739861) move the fedora logo to the left
19:54:43 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=739861
19:54:43 <tflink> #info Proposed NTH, POST
19:54:44 <buggbot> Bug 739861: unspecified, unspecified, ---, anaconda-maint-list, POST, move the fedora logo to the left
19:54:54 <tflink> I was wondering where this bug went
19:55:48 <tflink> eh, I'm not sure this is NTH worthy but we do have the artwork criteria ...
19:55:52 <brunowolff> Well it's something that can't be fixed in an update. It sems kind of a minor thing, but I am not a art designer.
19:56:34 <brunowolff> (At least if they are talking about a logo displayed during install.)
19:56:58 <tflink> adamw: thoughts?
19:57:17 <adamw> yeah, same deal as the last bug to me.
19:57:17 <tflink> I guess I'd be OK with NTH since it probably should be fixed
19:57:21 <tflink> but it seems silly to me
19:57:22 <adamw> well...
19:57:34 <adamw> it is a visible polish issue
19:57:37 <adamw> but it's still kinda pushing things
19:58:20 <tflink> especially when it could just go into the next build before final freeze
19:58:20 <adamw> i guess i could just about be okay with +1 for this.
19:58:29 <brunowolff> And artwork changes have the potential to break things.
19:58:36 <adamw> given that we can refuse to take nth fixes too late post-freeze; it's a discretionary thing.
19:58:40 <adamw> but yeah...it's pretty borderline.
19:58:55 <brunowolff> Last year a several images went oversize after a late artwork change.
19:59:05 <adamw> true
19:59:17 <adamw> this change shouldn't cause _that_ problem, but it demonstrates that 'trivial' art changes can have unintended consequences
19:59:19 <tflink> all the more reason to fix it now ...
19:59:22 <adamw> yeah
19:59:39 <adamw> i think maybe -1 as this really should be done before freeze, and cite the note from the previous bug about tweaking anaconda's commit policies
20:00:12 <brunowolff> That would be a better way to do it.
20:00:25 <tflink> that makes sense to me. I'd rather not be doing NTH at this point for a fix that is ready and potenially disruptive later
20:00:32 <adamw> yup.
20:01:27 <tflink> proposed #agreed - 739861 - RejectedNTH - This is an artwork change that may not be something to take past code freeze
20:01:40 <tflink> proposed #agreed - 739861 - RejectedNTH - This is an artwork change that may not be something we want to take past code freeze
20:01:47 <brunowolff> +1
20:01:59 <tflink> #agreed - 739861 - RejectedNTH - This is an artwork change that may not be something we want to take past code freeze
20:02:06 <tflink> #topic (741446) Can't log in after Lock screen
20:02:06 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741446
20:02:06 <tflink> #info Proposed NTH, NEW
20:02:07 <buggbot> Bug 741446: unspecified, unspecified, ---, rstrode, NEW, Can't log in after Lock screen
20:02:45 <tflink> I'm +1 NTH on this, possibly blocker
20:03:04 <tflink> I tried it and I'm thinking that there might be a deeper problem
20:03:18 <brunowolff> +1 NTH
20:03:22 <tflink> the keyboard layout seems to change on an arbitrary yet predictable basis
20:03:34 <tflink> but once you lock the screen, you get what you get for a keyboard layout
20:03:50 <tflink> the widget for changing the layout appears to change but has no affect on the layout used
20:04:07 <tflink> gdm seems to be similar from my tesing, anyways
20:04:35 * tflink forgot to add info to the bug
20:04:51 <tflink> but with what we know now for the bug that is described here ...
20:05:40 <tflink> proposed #agreed - 741446 - AcceptedNTH - This is a huge pain for anyone who has a password in a non-english layout even though it doesn't directly hit any release criteria
20:05:51 <adamw> okay, +1 indeed then, if you could reproduce issues that's good enough for me
20:06:07 <tflink> #agreed - 741446 - AcceptedNTH - This is a huge pain for anyone who has a password in a non-english layout even though it doesn't directly hit any release criteria
20:06:19 <tflink> #topic (741375) default ACPI behavior makes it impossible to cleanly shutdown F16 guest from the host
20:06:22 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=741375
20:06:25 <tflink> #info Proposed NTH, NEW
20:06:25 <buggbot> Bug 741375: unspecified, unspecified, ---, bnocera, NEW, default ACPI behavior makes it impossible to cleanly shutdown F16 guest from the host
20:06:55 <tflink> eh, I'm not so enthusiastic about this one
20:07:16 <tflink> I think that I'm -1 NTH on this - I don't think its something that would need to be taken through a freeze
20:07:23 <tflink> it could be fixed with updates
20:07:27 <adamw> yeah.
20:07:54 <adamw> -1
20:08:19 <tflink> proposed #agreed - 741375 - RejectedNTH - This doesn't seem like something that should be taken past code freeze and could be fixed with updates post-release
20:09:52 <adamw> ack
20:10:02 <tflink> #agreed - 741375 - RejectedNTH - This doesn't seem like something that should be taken past code freeze and could be fixed with updates post-release
20:10:06 <tflink> #topic (678453) Grub2 Menu entries doesn't contain the name of distribution
20:10:09 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=678453
20:10:11 <tflink> #info Proposed NTH, NEW
20:10:11 <buggbot> Bug 678453: unspecified, unspecified, ---, pjones, NEW, Grub2 Menu entries doesn't contain the name of distribution
20:11:07 <tflink> I think this one falls under the same "wouldn't take past freeze" for me
20:11:16 <tflink> and could be fixed with an update
20:12:09 <drago01> doesn't sound like something where a fix would have a big impact
20:12:15 <drago01> i'd rather say nth
20:12:37 <tflink> it shouldn't have a big impact, no
20:12:37 <brunowolff> I'm -1 NTH -1 Blocker
20:12:47 <tflink> but I'd still rather not mess with grub past freeze
20:12:57 <tflink> not for something cosmetic, anyways
20:13:09 <drago01> like adding a string?
20:13:34 <tflink> if it's that easy of a fix, why does it need to be NTH?
20:13:37 <brunowolff> There is time to get the fix in now.
20:13:47 <adamw> sorry, was discussing the freeze issue with anaconda team
20:14:12 <tflink> proposed #agreed - 678453 - RejectedNTH - This is a cosmetic RFE that we probably wouldn't take past freeze
20:14:16 <brunowolff> But if it's not ready by final freeze, I think it should be deferred.
20:14:23 <tflink> ack/nak/patch?
20:14:28 <tflink> brunowolff: +1
20:14:29 <brunowolff> +1
20:14:43 <drago01> -1
20:15:07 <drago01> (I'd rather say if we have a fix take if we don't se be it)
20:15:17 <tflink> I'm +1 so were currently at +2/-1 => +1
20:15:21 <tflink> any other votes?
20:16:17 <tflink> adamw: any other votes?
20:17:36 <adamw> sorry, gimme a sec
20:17:52 <adamw> -1 nth
20:17:55 <adamw> so ack to the proposal
20:18:20 <tflink> ok, that makes 3ack/1nak
20:18:33 <tflink> #agreed - 678453 - RejectedNTH - This is a cosmetic RFE that we probably wouldn't take past freeze
20:18:47 <tflink> #topic (711489) atl1c: transmit queue timeout (Acer Aspire One 522)
20:18:47 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=711489
20:18:47 <tflink> #info Proposed NTH, ASSIGNED
20:18:51 <buggbot> Bug 711489: unspecified, unspecified, ---, kernel-maint, ASSIGNED, atl1c: transmit queue timeout (Acer Aspire One 522)
20:19:05 <tflink> didn't we see this for F15?
20:19:50 <adamw> sounds vaguely familiar, yeah
20:20:00 <brunowolff> Yes.
20:20:02 <adamw> yeah, initial report is f15
20:20:45 <tflink> I guess I'm probably -0 at most on this
20:20:51 <adamw> i'm fine with nth as it's an ugly hardware issue, the impact is severe but limited in breadth
20:21:05 <adamw> it would be a blocker if it affected more hardware
20:21:15 <brunowolff> I'm leaning toward NTH.
20:21:16 <adamw> so i think nth is okay
20:21:20 <tflink> ok
20:21:27 <adamw> it would kinda suck to have a fix for this but not take it
20:21:43 <brunowolff> I don't know how common the hardware is.
20:21:46 <tflink> proposed #agreed - 711489 - AcceptedNTH - This bug is ugly but it affects a small subset of hardware
20:21:59 <brunowolff> +1
20:22:03 <tflink> the aspire one is a reasonably common netbook
20:22:22 <adamw> there's zillions of aspire ones
20:22:26 <adamw> i think this affects one specific model
20:22:34 <adamw> but _any_ aspire one model will probably have sold quite a few, so yeah.
20:22:38 <adamw> ack
20:22:43 <tflink> #agreed - 711489 - AcceptedNTH - This bug is ugly but it affects a small subset of hardware
20:22:50 <adamw> aspire one is what acer calls all their netbooks
20:22:53 <tflink> #topic (739334) Adjust service disabling for systemd, and remove some dead wood
20:22:57 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=739334
20:22:58 <buggbot> Bug 739334: high, unspecified, ---, kanarip, NEW, Adjust service disabling for systemd, and remove some dead wood
20:22:59 <tflink> #info Proposed NTH, NEW
20:23:20 <brunowolff> This seems like something that should go in now, not after freeze.
20:23:31 <adamw> brunowolff: well sure
20:23:39 <adamw> brunowolff: it's always better to fix issues earlier
20:23:59 <adamw> brunowolff: but if a fix for this was found between, say, rc1 and rc2, i'd want to pull it in
20:24:05 <adamw> as long as it wasn't too sketchy
20:24:24 <adamw> oh wait
20:24:24 <adamw> sorry
20:24:29 <adamw> i thought we were still on the last bug :)
20:24:50 <tflink> shouldn't this be filed against spin-kickstarts?
20:25:00 <tflink> nvm, I can't read
20:25:08 <tflink> I thought that it was filed against systemd for some reason
20:25:25 <adamw> brunowolff: yeah...you're probably right
20:25:26 <brunowolff> Has Brian looked at this yet?
20:25:33 <adamw> we shouldn't be fiddling with it between rcs
20:25:41 <brunowolff> He has been doing a lot of related stuff recently.
20:25:42 <adamw> i haven't had any feedback on it from anyone
20:25:48 <adamw> brian who?
20:25:58 <brunowolff> bcl
20:26:05 <adamw> ah
20:26:09 <adamw> hadn't heard from him, no
20:26:16 <adamw> he's been working on spin kickstarts?
20:26:29 <brunowolff> Well live images.
20:27:07 <tflink> I'm -1 NTH on this - if it's working once we hit freeze, lets not mess with it
20:27:19 * nirik hasn't had time to look at it too much, but if it tests out ok, I'm fine with landing it... will make things much nicer.
20:27:25 <tflink> if it breaks something, re-propose this or something else as a blocker
20:27:28 <adamw> it tested fine for me
20:27:29 <nirik> but yeah, it should land like now...
20:27:38 <adamw> okay, -1's good with me
20:27:38 <brunowolff> Yeah I wandered a bit in trying to figure out how me might do this before freeze.
20:27:49 <adamw> but bruno and nirik, if you guys could test it and commit that'd be great
20:27:52 <adamw> i'm fairly confident it's correct
20:28:09 <brunowolff> I am one of the spin-kickstarts people, but it was on the edge of what I was comfortable with reviewing.
20:28:29 <tflink> proposed #agreed - 739334 - RejectedNTH - If the spin kickstarts are working at freeze, leave them alone. If an issue is found, re-propose this or the found issue as a blocker
20:28:46 <brunowolff> I was thinking bcl might be involved, but he really does more on the livecd-tools stuff.
20:29:12 <brunowolff> kanarip has been busy for a long time now and may not get a chance to look at it.
20:29:16 <adamw> ack
20:29:23 <adamw> kana: thanks for the heads-up
20:29:26 <adamw> erf
20:29:29 <adamw> i thought that was a /me :)
20:29:44 <tflink> #agreed - 739334 - RejectedNTH - If the spin kickstarts are working at freeze, leave them alone. If an issue is found, re-propose this or the found issue as a blocker
20:29:47 <brunowolff> I can try to look at it and do some testing.
20:29:55 <adamw> brunowolff: i think maybe the best thing to do is just for you to try it yourself and build a few lives and check them out, if you're happy, we commit it asap and see if any nightly users yell
20:30:04 <adamw> we certainly have people who use the nightlies, so if it breaks anything, we should hear
20:30:12 <tflink> ok, that's all of the proposed NTH
20:30:15 <adamw> and the earlier we commit it the longer we have to find out about breakage and revert
20:30:46 <adamw> tflink: awesome
20:30:55 <brunowolff> Yeah. I'll do at least some testing this weekend.
20:31:10 * tflink thinks that all of the currently accepted blockers were from yesterday's go/no-go
20:31:39 <tflink> nvm
20:33:21 <tflink> any desire to go through the accepted blockers as a group?
20:33:29 <tflink> I can go through and poke people otherwise
20:33:40 <tflink> some of these haven't been touched in almost a month
20:33:52 <brunowolff> I'd like to stay under 4 hrs.
20:34:14 <tflink> same here
20:34:21 <tflink> but I am glad that we did this this week
20:34:35 * tflink doesn't want to think about what the list would have looked like in another week
20:36:25 * tflink makes executive decision
20:36:31 <tflink> #topic open discussion
20:36:38 <tflink> any other topics that should be covered?
20:37:05 * tflink sets fuse for 2 minutes
20:38:06 <tflink> #info Fedora 16 final blocker bug review meeting #2 will be 2011-10-07 @ 17:00 UTC
20:38:24 <adamw> sorry, got a phone call
20:38:30 <adamw> yeah let's review accepted next week
20:38:48 <tflink> are you going to do the rest of the bug updating or am I?
20:39:45 <tflink> OK, thanks for coming everyone. This was a long one!
20:39:51 * tflink will be sending out minutes shortly
20:39:53 <tflink> #endmeeting