16:00:56 <tflink> #startmeeting f18-beta-blocker-review-2
16:00:56 <zodbot> Meeting started Wed Oct  3 16:00:56 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:56 <tflink> #meetingname f18-beta-blocker-review-2
16:00:56 <zodbot> The meeting name has been set to 'f18-beta-blocker-review-2'
16:01:00 <tflink> #topic Roll Call
16:01:11 <tflink> Who's ready for some blocker review awesome-ness?
16:01:46 <Martix> kparal: adamw could I propose some nouveau blockers or leave them for next week?
16:02:13 * kparal is here
16:02:49 <kparal> satellit: just change your language in control center
16:03:40 <satellit> ok will try it....
16:03:51 * satellit listening
16:04:09 <tflink> oh my, long list today
16:04:33 <Martix> tflink: I can add also nouveau...
16:04:50 <Martix> tflink: we can vote on all suspend bugs together?
16:05:07 * Viking-Ice half in half at $dayjob
16:05:37 <tflink> Martix: I don't think that suspend bugs qualify as blockers
16:06:18 <tflink> Martix: do you have a bug list?
16:06:19 <Martix> tflink: maybe final?
16:07:36 <tflink> Martix: they can be fixed with an update and we have no release criteria covering suspend (unless I'm remembering wrong)
16:07:48 <tflink> I'm not saying don't propose them, I'm just not sure that they would be accepted
16:07:59 <adamw> yo
16:08:16 <Martix> I removed 3  ATI FirePro V4800 because works for me, need proper reproducer
16:08:20 <tflink> looks like we have 3.5 people including me
16:08:24 <kparal> tflink: do you happen to know the time of the fesco-anaconda-beta-freeze meeting?
16:08:30 <kparal> is it today?
16:08:40 <tflink> kparal: off the top of my head, no. it'll be during the blocker meeting, though
16:09:04 <kparal> tomorrow's lunch will be during the meeting as well :)
16:09:16 <kparal> when seeing the blocker list
16:09:19 <tflink> yeah, we have 37 proposed blockers ATM
16:09:48 <Martix> is multihead betablocker?
16:10:03 <tflink> Martix: I don't think so, no
16:10:20 <Martix> when it breaks X?
16:10:26 <tflink> if it affects operation of the livecd, then it could be
16:10:45 <kparal> Martix: we have this funny page, go and check it ;) https://fedoraproject.org/wiki/Fedora_Release_Criteria
16:10:58 <Martix> kparal: I heard about that page once
16:10:58 <tflink> well, let's get this party started before I run away in terror
16:11:06 <tflink> #chair kparal adamw
16:11:06 <zodbot> Current chairs: adamw kparal tflink
16:11:06 <adamw> Martix: tflink is right, we usually don't accept suspend bugs as blockers. it'd have to be something like 'suspend never works for anyone and eats data'
16:11:11 <kparal> Martix: and probably de-nominate some of the blockers, if they don't fit at all. thanks
16:11:33 <tflink> #topic Introduction
16:11:40 <tflink> hy are we here?
16:11:40 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:11:48 <tflink> #info We'll be following the process outlined at:
16:11:49 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:11:56 <tflink> #info The bugs up for review today are available at:
16:11:56 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:12:02 <tflink> #info The criteria for release blocking bugs can be found at:
16:12:02 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
16:12:02 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
16:12:03 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
16:12:18 <tflink> Up for review today, we have:
16:12:21 <tflink> #info 39 Proposed Blockers
16:12:22 <tflink> #info 7 Accepted Blockers
16:12:22 <tflink> #info 5 Proposed NTH
16:12:22 <tflink> #info 4 Accepted NTH
16:12:37 <Martix> kparal: Im trying
16:13:07 <tflink> any objections to starting with the proposed blockers?
16:14:00 <adamw> oh boy howdy.
16:14:37 <tflink> #topic (847831) kickstart boot fails
16:14:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=847831
16:14:37 <tflink> #info Proposed Blocker, ASSIGNED
16:15:12 <tflink> no update since last week
16:16:06 <adamw> right, we probably need an action item for someone to try and reproduce/poke anaconda team
16:16:10 <adamw> any volunteers? :)
16:16:47 <zodbot> Ticket notification - f18betablocker: [Bug 861106] X Test Day: Video breaks when secondary monitor is connected <https://bugzilla.redhat.com/show_bug.cgi?id=861106> || [Bug 855560] F18 Live Alpha : nVidia GeForce 8600M GT, graphic driver (nouveau): very poor performance (vesa is fluid) <https://bugzilla.redhat.com/show_bug.cgi?id=855560>
16:16:47 * kparal says let's assign to someone not here
16:17:01 * tflink doesn't see jskladan around :)
16:17:17 <kparal> that's what I'm talking about!
16:17:37 <tflink> I can do it, though. I have a cobbler setup and it sounds like that's what the reporter is/was using
16:18:01 <tflink> #action tflink to investigate 847831 and poke anaconda devs if needed
16:18:09 <kparal> I don't think we need action item per say, I try to go through the blocker list and reproduce what I can. I just didn't have enough time. I assume everyone does the same
16:18:30 <adamw> kparal: it can help to have it explicit.
16:18:31 <tflink> yeah, I assume that I'm more likely to do it with an #action
16:18:37 <kparal> ok
16:18:41 <tflink> unless someone else wants to do it
16:18:54 <adamw> i'm disorganized enough to need a todo list to work off =)
16:19:20 <tflink> proposed #agreed 847831 - We're still waiting for data on what exactly is broken here - will revisit once that data is available
16:19:25 <tflink> ack/nak/patch?
16:19:39 <Viking-Ice> ack
16:20:02 <adamw> ack
16:20:04 <kparal> ack
16:20:12 <tflink> #agreed 847831 - We're still waiting for data on what exactly is broken here - will revisit once that data is available
16:20:19 <tflink> #topic (841451) polkitd doesn't start in F18/rawhide upgraded from F17 using yum due to failure to create polkitd user/group
16:20:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=841451
16:20:25 <tflink> #info Proposed Blocker, NEW
16:23:36 <adamw> why the hell does this one keep popping up
16:23:44 <adamw> whatever we did to take it out last time apparently didn't work
16:23:53 <kparal> we skipped it last time, because it was upgrade issue
16:24:07 <kparal> now we have upgrade criteria
16:24:09 <kparal> or do we?
16:24:22 <adamw> no
16:24:29 <Viking-Ice> we do but this is not upgrade with the official tool hence it does not count ;)
16:24:33 <tflink> kparal: we accepted the new criteria on monday, I changed the wiki a couple of hours ago
16:24:36 <Viking-Ice> adamw, we do have criteria ;)
16:24:45 <kparal> so the ones are live now
16:24:47 <adamw> i meant no, we didn't skip it because it was an upgrade issue
16:24:51 <kparal> ah
16:24:55 <adamw> we meant to take it out of the list, but failed
16:25:01 <adamw> "We're pretty confident this isn't causing 849990, so we're dropping that dep, which takes it out of the list again."
16:25:06 * Martix1 removed 4 more proposed blockers
16:25:16 <adamw> i think we should just go ahead and close this as a dupe of 844167. we're pretty sure that's what it is, after all.
16:25:19 <kparal> adamw: well it blocks F18Beta directly
16:25:20 <tflink> yeah, but the blocks F18beta wasn't remove
16:25:57 <adamw> yeah. i think i thought it wasn't blocking f18beta for some reason
16:26:04 <adamw> anyway, propose we just close it as a dupe to get rid of it once and for all
16:26:09 <tflink> no movement since 2012-08-29, I think it can be closed
16:26:51 <tflink> proposed #agreed (841451) - There has been no objection to closing this as a dupe of 849990 - close as a dupe
16:27:13 <adamw> patch
16:27:18 <adamw> 844167, not 849990.
16:27:30 <tflink> ah, reading too quickly
16:27:42 <tflink> proposed #agreed (841451) - There has been no objection to closing this as a dupe of 844167 - close as a dupe
16:28:36 <adamw> ack
16:29:00 <kparal> ack
16:29:30 <tflink> #agreed (841451) - There has been no objection to closing this as a dupe of 844167 - close as a dupe
16:29:36 <tflink> #topic (847472) DM configuration migration on upgrade not working
16:29:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=847472
16:29:37 <tflink> #info Proposed Blocker, ON_QA
16:30:03 <Viking-Ice> and ack
16:30:57 <Viking-Ice> We have to retest this one with the official upgrade if/when it surfaces ;)
16:31:02 <tflink> I'm not even sure we can do much about this right now
16:31:16 <adamw> Viking-Ice: yeah, i noted that in the bug comment
16:31:29 <adamw> Viking-Ice: we've heard enough about that bug that if it affects the official upgrade tool, we'll know what it is =)
16:32:26 <Viking-Ice> I think on this meeting we can just come up with generic wait of upgrade tool to appear response to put on all those upgrade related blocker bugs
16:32:30 <adamw> tflink: we appear to have fixed it
16:32:33 <tflink> do we punt on this or denominate
16:32:44 <tflink> adamw: fixed it 4 times, even :)
16:32:48 <adamw> looking at the details of this one i think we can probably accept it
16:32:51 <adamw> the systemd update keeps getting revised
16:33:24 <adamw> it's to do with the systemd trigger thing on upgrade, making sure the DM service is properly enabled, it sounds like there was a genuine bug that lennart and halfline both accept, i'm willing to go with that
16:33:40 <adamw> and since it's to do with the package scripts, the mechanism used to upgrade shouldn't really matter
16:33:46 <zodbot> Ticket notification - f18betablocker: [Bug 752613] Nivida 100M on Lenovo W520 Wont boot if using Discrete Graphics <https://bugzilla.redhat.com/show_bug.cgi?id=752613> || [Bug 860477] nouveau Xorg crash following boot (GTX 580) <https://bugzilla.redhat.com/show_bug.cgi?id=860477> || [Bug 860624] Gnome-shall hangs when requested activities <https://bugzilla.redhat.com/show_bug.cgi?id=860624> || [Bug 861646] Sporadic GPU Lockups when Fast User Switching <https://bugzilla.redhat.com/show_bug.cgi?id=861646> || [Bug 861746] GDM login screen artefacts and corruption with Geforce 210 <https://bugzilla.redhat.com/show_bug.cgi?id=861746>
16:34:02 <tflink> works for me
16:34:04 <adamw> so i'd vote +1
16:34:11 <adamw> Viking-Ice: does that sound right to you too?
16:34:22 <adamw> as our local systemd expert =)
16:34:49 <Viking-Ice> yup
16:35:20 <tflink> proposed #agreed 847472 - AcceptedBlocker - Violates the following F18 beta release criterion: "It must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with the 'minimal' package set or the package set for a release-blocking desktop, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria." Since this bug is in the package upgrade for syst
16:35:32 <Viking-Ice> ack
16:36:08 <kparal> cropped
16:36:16 <tflink> kparal: how bad?
16:36:22 <kparal> package upgrade for syst
16:36:58 <adamw> ack
16:36:59 <tflink> proposed #agreed 847472 - AcceptedBlocker - Violates the following F18 beta release criterion: "It must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with the 'minimal' package set or the package set for a release-blocking desktop, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria." This will not be affected by upgrade mechanism
16:37:08 <adamw> tflink: just do it with the criterion, i'll explain the details in the bug comment
16:37:10 <adamw> ack
16:37:12 <kparal> ack
16:37:14 <tflink> proposed #agreed 847472 - AcceptedBlocker - Violates the following F18 beta release criterion: "It must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with the 'minimal' package set or the package set for a release-blocking desktop, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria."
16:37:15 <Viking-Ice> ack
16:37:15 <adamw> that one wasn't cropped
16:37:23 <tflink> #agreed 847472 - AcceptedBlocker - Violates the following F18 beta release criterion: "It must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with the 'minimal' package set or the package set for a release-blocking desktop, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria."
16:37:24 <adamw> second one is fine
16:37:28 <adamw> ...oh well =)
16:37:34 <tflink> too late :-P
16:37:45 <tflink> #topic (855976) In F18 Alpha, 'automatic' partitioning simply wipes your entire disk without warning you first
16:37:48 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855976
16:37:50 <tflink> #info Proposed Blocker, MODIFIED
16:38:47 <tflink> not sure this really violates any release criteria, as much as I think it should be a blocker
16:38:58 <adamw> it does. i wrote one specially for it. =)
16:39:17 <adamw> may i introduce you to "The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"
16:39:29 <tflink> ah
16:39:34 <tflink> then clear blocker
16:39:40 <Viking-Ice> really you are installing an operating system and somehow you dont expect the default option to wipe your hardrive ?
16:39:58 <adamw> we may actually have to tweak the wording on that, because we now have 'automatic partitioning' both outside of and inside 'custom partitioning', which makes things a bit icky. we need terminology to distinguish them. but the criterion was written for the 'automatic partitioning outside of custom partitioning' definition.
16:40:15 <adamw> Viking-Ice: fedora never has defaulted to that.
16:40:16 <tflink> proposed #agreed 855976 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"
16:40:22 <adamw> ack
16:40:22 <kparal> actually that criterion does not influence that bug
16:40:30 <kparal> it does not say anaconda has to warn you
16:40:49 <Viking-Ice> adamw, for some weird reason I do believe every other OS in the existence does exactly that
16:41:04 <adamw> kparal: well, anaconda team have used it as the bug for 'improve the automatic partitioning stuff'
16:41:06 <kparal> and it does not say anaconda can't wipe the whole disk, if it also provides a way not to wipe your disk automatically
16:41:09 <tflink> not directly, no but IIRC, it isn't possible to use free space + autopart ATM regardless of whether anaconda warns you or not
16:41:16 <adamw> kparal: it's MODIFIED by the patches clumens posted to make autopart smarter.
16:41:29 <kparal> I was just nitpicking
16:41:39 <adamw> so this is effectively the bug for 'add an option to install into free space', which is what the criterion's about.
16:41:59 <kparal> ok, I wasn't able to read it through completely
16:42:06 <Viking-Ice> nack on blocker ack on NTH ;)
16:42:11 <zodbot> Ticket notification - f18betablocker: [Bug 745202] gnome-shell does not display correctly with NV3x adapters - multicolor corruption of panel, Shell-style menus and text [nvfx] <https://bugzilla.redhat.com/show_bug.cgi?id=745202>
16:42:39 <adamw> Viking-Ice: how about this, we release f18 in a state where automatic partitioning can only be used to entirely wipe out a drive, and you deal with all the hate mail. ;)
16:42:52 <tflink> so we're at +2 -1 blocker
16:42:57 <tflink> kparal: vote?
16:43:13 * tflink isn't clear whether you're +1 or -1
16:43:15 <Viking-Ice> adamw, I'm used to dealing with hate mail with my work with systemd migration so just BRING IT ON ;)
16:43:35 <kparal> so the bug title should say: anaconda should be able to install alongside other system into free space without wiping it first?
16:43:41 <Viking-Ice> I'm -1 to blocker +1 NTH
16:43:50 <adamw> kparal: that's what it's being used for, yep.
16:44:03 <Viking-Ice> and +1 for FINAL
16:44:07 <Martix1> +1 blocker for me
16:44:10 <kparal> adamw: ok, +1 blocker then according to the criteria, provided that we change the title
16:44:18 <tflink> +4 -1 blocker
16:44:27 <adamw> kparal: i'll add that to the explanation too
16:44:43 <adamw> kparal: i kinda expected clumens would've added a comment, but no, he just set MODIFIED and fixed in version.
16:45:06 <Martix1> kparal is AFK
16:45:11 <tflink> proposed #agreed 855976 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"
16:45:24 <adamw> ack
16:45:28 <Martix> ack
16:45:36 <tflink> sounds like time for some #actions for kparal while he's AFK, then
16:45:47 <Martix> :-D
16:45:53 <Martix> agreed
16:46:09 * kparal is back
16:46:14 <tflink> #action kparal to test all of F18 beta - the rest of us engage in operation pina colada
16:46:15 <Martix> tflink: too late
16:46:17 <tflink> crap, too late
16:46:22 <tflink> #undo
16:46:22 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x28d8dc90>
16:46:22 <kparal> nack
16:46:44 <kparal> ack to the proposal
16:46:52 <tflink> #agreed 855976 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"
16:47:28 <tflink> #topic (835648) kernel freeze after [drm] Initialized drm 1.1.0 20060810 on T520 with Quadro NVS 4200M
16:47:31 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=835648
16:47:34 <tflink> #info Proposed Blocker, NEW
16:47:41 <kparal> there is only way to do operation pina colada properly, and that is with me
16:47:49 <Viking-Ice> ack to pina colada proposal
16:47:59 <adamw> i'll get the pina if you get the colada
16:48:08 <kparal> *one way
16:49:06 <Martix> #agreed we need more pina coladas
16:49:17 <adamw> oh goody, we're into the subjective-assessment hardware bugs
16:49:24 <tflink> yep
16:49:28 <tflink> I think this can be rejected, though
16:49:52 <tflink> I suppose we probably need more data, though
16:49:53 <adamw> so to give the potted history i usually give when these start coming up...these kind of bugs hit the "There may be times where a requirement is unmet only in a particular configuration" text in the preamble
16:49:58 <kparal> NVS 140M + VT-d works for me
16:49:58 <Martix> adamw: *firmware bugs
16:50:32 <adamw> and we have to consider a sort of multiplication of (bug severity * difficulty of workaround * amount of hardware affected) equation to decide on blocker status
16:50:32 <tflink> I'd say reject it, if it turns out that VT-d disabling isn't enough and lots of people hit this - it can be reproposed
16:50:37 <zodbot> Ticket notification - f18betablocker: [Bug 855976] In F18 Alpha, 'automatic' partitioning wipes entire disk without warning, should also allow 'install to free space' <https://bugzilla.redhat.com/show_bug.cgi?id=855976>
16:50:45 <Viking-Ice> "Boot Fedora 17" <--
16:50:48 <kparal> I don't think this is serious enough for Beta
16:51:05 <adamw> in this case i'd say the bug is very severe, the amount of hardware affected is moderate (seems to be several thinkpad models, which are popular in fedoraland), and the ease of workaround is 'relatively easy'
16:51:07 <kparal> so just reject Beta blocker and talk about it again for Final
16:51:18 <adamw> so i'd say it's pretty close, but -1 for beta.
16:51:21 <Viking-Ice> just a regular bug
16:51:24 <Viking-Ice> -1 for beta
16:51:26 <tflink> it sounds like we're pretty much -1 beta blocker
16:51:56 <adamw> seems like it.
16:52:21 <adamw> +1 nth, though
16:52:24 <adamw> any nth votes?
16:52:30 <kparal> +1 nth
16:52:47 <tflink> proposed #agreed 835648 - RejectedBlocker - While serious, it affects a minority of hardware configurations and appears easy to workaround. Rejected as blocker for F18 beta, please re-propose if it turns out that the workaround doesn't work or more HW is affected than our current understanding
16:52:52 <tflink> -1 nth
16:53:04 <Martix> +1 NTH
16:53:05 <adamw> tough on nth, i like it.
16:53:17 <Viking-Ice> -1 nth
16:53:18 <akshayvyas> oh i was on bugzappers
16:53:26 <tflink> I don't see this as important enough to pull in post-freeze
16:53:37 <drago01> ugh a dmar bug ... prepare pitchforks and find dwmw2 ;)
16:53:37 <Viking-Ice> agreed
16:54:17 <tflink> it looks like we're +3, -2 on NTH
16:54:30 <adamw> i think i'll go for -1, on consideration
16:54:30 <Martix> agreed
16:54:31 <tflink> any other votes?
16:54:41 <adamw> so make it +2 / -3
16:54:43 <tflink> ok, +1 -4
16:54:50 <Martix> lol
16:55:01 <kparal> no hard feelings here
16:55:04 * adamw will stop being too NTH-liberal one of these days
16:55:13 <tflink> proposed #agreed 835648 - RejectedBlocker - While serious, it affects a minority of hardware configurations and appears easy to workaround. Rejected as blocker for F18 beta, please re-propose if it turns out that the workaround doesn't work or more HW is affected than our current understanding
16:55:20 <Martix> ack
16:55:23 <adamw> patch RejectedNTH
16:55:36 <tflink> proposed #agreed 835648 - RejectedBlocker, RejectedNTH - While serious, it affects a minority of hardware configurations and appears easy to workaround. Rejected as blocker for F18 beta, please re-propose if it turns out that the workaround doesn't work or more HW is affected than our current understanding
16:55:43 <drago01> I'd label it final blocker though
16:56:02 <tflink> drago01: I don't think that it even qualifies as a final blocker
16:56:10 <tflink> but that's me
16:56:14 <Viking-Ice> and me
16:56:15 <kparal> ack
16:56:18 <tflink> you're welcome to propose it as such
16:56:20 <adamw> let's punt it for final
16:56:28 <adamw> ack
16:56:29 <drago01> tflink: that hardware is not that uncommon
16:56:36 <Viking-Ice> ack
16:56:41 <drago01> tflink: ie that specific laptop (w520)
16:56:50 <tflink> drago01: it can be fixed with an update, doesn't affect live media and is not too hard to workaround
16:57:04 <tflink> #agreed 835648 - RejectedBlocker, RejectedNTH - While serious, it affects a minority of hardware configurations and appears easy to workaround. Rejected as blocker for F18 beta, please re-propose if it turns out that the workaround doesn't work or more HW is affected than our current understanding
16:57:07 <Martix> tflink: it affects live
16:57:26 <drago01> tflink: "kernel freeze while booting"
16:57:28 <Martix> tflink: you need to disable VTd
16:57:37 <drago01> tflink: how does that not affect live? or the installer?
16:57:40 <tflink> Martix: oh yeah - for some reason I have it in my head that it only affects virt
16:57:47 <drago01> tflink: that cannot be fixed by an update
16:57:56 <tflink> drago01: yes, I was mistaken
16:58:06 <tflink> we can deal with it @ final time, though
16:58:27 <tflink> #topic (856938) Native UEFI install from F18 Alpha RC3 DVD written to USB with livecd-iso-to-disk fails to boot
16:58:30 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856938
16:58:33 <tflink> #info Proposed Blocker, VERIFIED
16:59:19 <tflink> I believe that this can be moved to VERIFIED, no?
16:59:23 <zodbot> Ticket notification - f18betablocker: [Bug 844167] Error in PREIN scriptlet in rpm package libvirt-daemon-0.9.11.4-3.fc17.x86_64 <https://bugzilla.redhat.com/show_bug.cgi?id=844167>
16:59:26 <kparal> it is verified
16:59:38 <kparal> so let's just skip it?
17:00:08 <adamw> yeah, skip it.
17:00:09 <tflink> did we ever get data on how many systems are affected?
17:00:14 <tflink> ok
17:00:21 <adamw> not really, but it's definitely fixed, so doesn't really matter.
17:00:27 <adamw> no way we're releasing beta with anaconda 18.8. =)
17:00:28 <zodbot> Ticket notification - commonbugsrss: [Bug 835648] kernel freeze after [drm] Initialized drm 1.1.0 20060810 on T520 with Quadro NVS 4200M <https://bugzilla.redhat.com/show_bug.cgi?id=835648>
17:00:50 <tflink> #info this bug is fixed but update is not yet in stable - doesn't need any review - skipping
17:01:01 <tflink> #topic (859632) Cannot edit boot entries
17:01:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859632
17:01:02 <tflink> #info Proposed Blocker, NEW
17:02:02 <adamw> note, this is _not_ the font size issue.
17:02:04 <tflink> ah FESCO meeting just started
17:02:08 <adamw> seems to be to do with german l10n somehow.
17:02:31 <adamw> tflink: yeah, i'll try and be around for the 946 discussion there
17:02:46 <tflink> I imagine we'll pause the blocker review when that time comes
17:02:47 <Viking-Ice> +1 for blocker
17:02:50 <adamw> could this possibly be related to the anaconda bad locale bug?
17:03:08 <adamw> which reminds me, i should re-propose that one.
17:03:09 * kparal notes fesco meeting starts in #fedora-meeting
17:03:29 <Viking-Ice> I dont care what the cause is by beta users should be able to edit grub on baremetal and on vm
17:03:39 <tflink> yeah, c#11 makes me wonder about the locale setting issue in anaconda
17:03:53 * Viking-Ice goes out for a smoke
17:04:04 <kparal> the locale bug might potentially break a lot of pieces
17:04:07 <adamw> do we have a criterion that would be hit by this?
17:04:14 <adamw> kparal: yeah, which is why i want to re-propose it
17:04:25 <tflink> for beta, not sure
17:04:43 <tflink> the first one that comes to mind is the i18n/l10n final criterion
17:05:05 <tflink> I propose we put the review on hold for the upgrade discussion in #fedora-meeting
17:05:13 <Martix> ack
17:05:20 * tflink presses pause button
17:05:25 <akshayvyas> tflink:+1
17:07:51 <zodbot> Ticket notification - f18betablocker: [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8 <https://bugzilla.redhat.com/show_bug.cgi?id=858591>
17:15:52 <Martix> there are "only" 11 proposed X Test Week blockers after cleanup :-)
17:19:21 <adamw> yay =)
17:19:25 <adamw> unpause?
17:20:34 <adamw> tflink: unpause?
17:20:38 <akshayvyas> tflink: ping
17:21:38 <adamw> tflink appears to have hung
17:21:40 <adamw> i'll take over
17:21:51 * tflink figured that it  was implicit
17:21:57 <adamw> oh, okay. un-taking over.
17:22:33 <adamw> this does seem like a significant issue, but i don't see an obvious criterion, and not entirely sure we really want to require grub menu editing at beta...
17:22:41 <adamw> also, i rather suspect it could be part of the locale issue
17:22:43 <adamw> punt for more data?
17:23:08 <tflink> works for me
17:23:24 <kparal> yep
17:23:47 <tflink> proposed #agreed 859632 - More data on the cause of this bug is needed before we make a decision on blocker status
17:23:59 <akshayvyas> ack
17:24:16 <adamw> ack
17:24:23 * adamw wonders how big viking's cigarettes are
17:24:47 <zodbot> Ticket notification - f18betablocker: [Bug 858837] ATI Mobility Radeon X1350 doesn't boot LiveCD <https://bugzilla.redhat.com/show_bug.cgi?id=858837>
17:24:59 <tflink> #agreed 859632 - More data on the cause of this bug is needed before we make a decision on blocker status
17:25:07 <tflink> #topic (856362) KeyError: 'la-latin1'
17:25:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856362
17:25:07 <tflink> #info Proposed Blocker, NEW
17:25:19 <Viking-Ice> adamw, I smoke pipe ;)
17:25:47 <tflink> punt, need to know whether new tool is affected first
17:26:09 <Viking-Ice> yup
17:26:14 <adamw> Viking-Ice: holy crap, you _really_ should be in a lord of the rings movie, not fedora qa =)
17:26:41 <adamw> sure, punt
17:26:53 <adamw> i'd kinda like to just close off all the preupgrade bugs, but probably best leave that to wwoods.
17:27:10 <tflink> proposed #agreed 856362 - This was filed against preupgrade - we need to see if the new tool is affected before deciding on blocker status
17:27:11 <Viking-Ice> adamw, there is but one trilogy and it aint lord of the rings ;)
17:27:56 <adamw> ack
17:28:09 <Viking-Ice> ack
17:28:13 <akshayvyas> ack
17:28:29 <tflink> #agreed 856362 - This was filed against preupgrade - we need to see if the new tool is affected before deciding on blocker status
17:28:36 <tflink> #topic (859855) AttributeError: 'NoneType' object has no attribute 'name'
17:28:36 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859855
17:28:36 <tflink> #info Proposed Blocker, NEW
17:28:48 * tflink is tempted to just skip all the preupgrade bugs
17:28:55 <Viking-Ice> do it
17:29:28 <Viking-Ice> any objections tflink does that?
17:29:42 <adamw> eh, sure
17:30:05 <akshayvyas> #19 says something
17:30:21 <adamw> akshayvyas: what wrote his kickstart file was preupgrade =)
17:30:56 <akshayvyas> ohk
17:30:59 <tflink> #undo
17:30:59 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x26966850>
17:31:00 <tflink> #undo
17:31:00 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2d1d06d0>
17:31:01 <tflink> #undo
17:31:01 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2d1d0890>
17:31:15 <tflink> #topic (859224) Please take systemd-logind's handle-power-key/handle-suspend-key/handle-hibernate-key/handle-lid-switch inhibitor locks if GNOME wants to handle the respective keys on its own
17:31:19 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859224
17:31:22 <tflink> #info Proposed Blocker, ON_QA
17:32:10 <Viking-Ice> nth
17:32:17 <adamw> "Not doing this leads to pretty bad double-suspend behaviour, so putting this on the F18Beta"
17:32:20 <adamw> seems pretty vague
17:32:25 * adamw goes to see if he can rope an mclasen
17:32:30 * kparal needs to travel, should be back in about 30 minutes
17:32:54 <tflink> kparal: another opportunity to sneak in #actions :-D
17:33:07 <kparal> sure, feel free
17:33:19 <Viking-Ice> ok so since kparal is gone I suggest he ...
17:33:23 <adamw> =)
17:33:28 <adamw> we have "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work"
17:33:33 <adamw> i'm asking mclasen now if this affects that
17:33:45 <adamw> if it only affects suspend then i agree with viking, it's NTH. especially since suspend isn't the default any more.
17:34:09 <adamw> <mclasen> its fixed by the g-s-d I built yesterday
17:34:09 <adamw> before that, you would get 2 suspends on lid close
17:34:09 <adamw> first systemd suspends
17:34:09 <adamw> and then, when you open the lid again, gsd suspends
17:34:32 <Viking-Ice> yay :)
17:34:51 <tflink> I'm not even sure of NTH
17:34:55 <Viking-Ice> 50% more suspend
17:35:04 <Viking-Ice> since the fix is there
17:35:44 <tflink> non-blocker g-s-d fixes past freeze seems like a questionable choice - especially at this point
17:36:01 <tflink> -1 blocker, propose as NTH/blocker later if the problem still exists post-freeze
17:36:02 <adamw> well, that behaviour does sound kinda crappy.
17:36:05 <adamw> sounds good
17:36:15 <adamw> -1 assuming no impact on shutdown, agree with tflink on punting for nth
17:36:52 <Viking-Ice> yeah I go with that
17:37:15 <adamw> practically this'll likely get pushed before next week anyway, so hey.
17:37:15 <tflink> proposed #agreed 859224 - RejectedBlocker - Since this appears to only affect suspend, it doesn't affect any of the F18 beta release criteria and thus is not a blocker for F18 beta. If this is still a significant issue during freeze, please re-propose as NTH
17:37:20 <adamw> ack
17:37:33 <Viking-Ice> ack
17:38:33 <tflink> did we scare everyone else off already?
17:38:52 <tflink> #agreed 859224 - RejectedBlocker - Since this appears to only affect suspend, it doesn't affect any of the F18 beta release criteria and thus is not a blocker for F18 beta. If this is still a significant issue during freeze, please re-propose as NTH
17:39:09 <tflink> #topic (862221) repo.getPackage(po) fails with yum-3.4.3-44 but works using git master
17:39:12 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862221
17:39:14 <tflink> #info Proposed Blocker, ON_QA
17:39:20 <Viking-Ice> or kparal was but more than one man
17:39:37 <tflink> what's the offline update feature?
17:39:55 <Viking-Ice> some useless I crap I think
17:40:15 <Viking-Ice> I dont think this one hits any criteria thus -1 blocker
17:41:02 <Viking-Ice> http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
17:41:11 <adamw> yeah, we have a solid principle that incomplete features are not blockers
17:41:26 <tflink> yep, -1 blocker, -1 nth
17:41:41 <adamw> maybe we need to update the criteria for this offline update thing, but as things stand, this doesn't violate the update criterion.
17:41:45 <Viking-Ice> I doubt that plymouth is ready for this
17:42:10 <Viking-Ice> ( showing the end users some we are conducting update + progress bar )
17:42:45 <tflink> proposed #agreed 862221 - RejectedBlocker, RejectedNTH - This does not violate any F18 beta release criteria and thus does not qualify for blocker status. This does affect a F18 feature but that doesn't qualify for NTH by itself, either
17:42:51 <Viking-Ice> ack
17:42:53 <adamw> also, this bug sounds like it only happens when you're using a side repo anyway.
17:42:58 <adamw> which we don't support for updates.
17:42:58 <adamw> ack.
17:43:03 <akshayvyas> ack
17:43:07 <tflink> #agreed 862221 - RejectedBlocker, RejectedNTH - This does not violate any F18 beta release criteria and thus does not qualify for blocker status. This does affect a F18 feature but that doesn't qualify for NTH by itself, either
17:43:16 <tflink> #topic (860791) IOError: [Errno 2] No such file or directory: '/etc/sysconfig/network-scripts/ifcfg-wlan0'
17:43:19 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=860791
17:43:22 <tflink> #info Proposed Blocker, POST
17:44:15 <Viking-Ice> nth
17:44:25 <tflink> when does this happen?
17:44:31 <Viking-Ice> Patch posted for review.
17:44:34 <tflink> wireless during installation?
17:44:46 <akshayvyas> nth
17:45:02 <tflink> or installing on a system that has wireless?
17:45:11 <Viking-Ice> In Live install after installing bootloader this backtrace happene or
17:45:11 <Viking-Ice> Correction, this happens after the installation is complete, in the "Configuring installed system" step.
17:45:14 <akshayvyas> tflink #18
17:45:37 <Viking-Ice> I think this bug report is vague indeed
17:45:41 <tflink> so you get an anaconda crash during installation if the system has wireless?
17:46:18 <Viking-Ice> after install it seems "Just for the record the system does boot after this backtrace"
17:47:29 <akshayvyas> in the "Configuring installed system" ??
17:47:39 <akshayvyas> does that mean firstboot??
17:47:45 <tflink> akshayvyas: part of the install, after installing packages
17:47:47 <Viking-Ice> nope sometime after package install
17:47:53 <tflink> at least, that's how I'm reading it
17:48:00 <Viking-Ice> me too
17:48:05 <tflink> either punt or +1 blocker
17:48:18 <tflink> I think wireless is common enough to justify blocker status
17:48:22 <adamw> i'm with viking, this is vague as hell
17:48:28 <Viking-Ice> I say NTH since the fix is there and we are pulling in anaconda changes anyway
17:48:44 <akshayvyas> Viking-Ice: +1
17:48:54 <akshayvyas> nth
17:49:13 <tflink> if it's too vague -> punt
17:49:17 <adamw> Viking-Ice: well a patch in for review can still fall through the cracks
17:49:22 <adamw> it's happened before
17:49:30 <tflink> if it's too vague for blocker, it's too vague for NTH
17:49:38 <adamw> we can only be totally sure a fix is going to show up in an anaconda build when they set MODIFIED and change the 'fixed in version' field
17:49:49 <Viking-Ice> tflink, we could also just revisit it after kparal comes back
17:49:49 <adamw> oh, which is the case here =)
17:49:57 <adamw> so it should be fine. we can punt and it'll go away.
17:49:59 <tflink> adamw: assuming that it doesn't get forgotten :)
17:50:06 <Viking-Ice> yup
17:50:19 <adamw> tflink: once they edit the 'fixed in version' field, that means it's already gone into git and can't now get lost
17:50:34 <adamw> you just have to know how to read the anaconda tea leaves =P
17:50:40 <tflink> adamw: my point was that it's still a human process
17:50:59 <tflink> but I'm nitpicking when we still have far too many bugs to review
17:51:01 <adamw> well sure, but it's already committed. they can't 'lose' it now. any 18.12 build will inevitably include this.
17:51:02 <Viking-Ice> let's just move to next one and hear from kparal
17:51:18 <adamw> say we're punting for data on exactly when this happens, we're really punting so it goes away.
17:51:34 <tflink> proposed #agreed 860791 - This bug is really vague and we need more information before making a decision on blocker status
17:51:40 <adamw> ack!
17:51:41 <Viking-Ice> ack
17:51:42 <akshayvyas> ack
17:52:31 <tflink> #agreed 860791 - This bug is really vague and we need more information before making a decision on blocker status
17:52:48 <tflink> #topic (860276) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 10: ordinal not in range(128)
17:52:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=860276
17:52:53 <tflink> #info Proposed Blocker, NEW
17:54:21 * tflink is not a huge fan of these new abrt filed anaconda bugs with no real information
17:54:33 <tflink> no easily discoverable summary, rather
17:55:05 <Viking-Ice> is it abrt doing those vague description
17:55:05 <adamw> this looks to be part of 858591.
17:55:08 <adamw> should probably close it as a dupe.
17:55:17 <adamw> see comment #9
17:55:44 <adamw> also has the happy side effect of giving us a reason to take 858591 as a blocker...
17:56:42 <Viking-Ice> yeah let's block 858591 and close 860276 as dupe of 858591
17:56:47 <adamw> i can easily reproduce this as a cause of 858591
17:56:56 <adamw> running firstboot with es_ES.UTF-8 works fine
17:57:00 <adamw> running it with es.UTF-8 crashes
17:57:08 <tflink> works for me
17:57:40 <tflink> is 858591 proposed as a blocker?
17:57:55 <nanonyme> no vote from me since I'm having trouble getting trace open with my cell phone
17:58:10 <adamw> tflink: i re-proposed it during the meeting
17:58:21 <adamw> though the status of that bug is rather complex so the app might barf on it
17:58:47 <adamw> but yeah, it is proposed, if it doesn't show up in the list i'll bring it up later.
17:58:51 <adamw> so, propose we mark this as a dupe.
17:59:21 <tflink> proposed #agreed 860276 - This appears to be a symptom of 858591, mark as a duplicate
17:59:25 <adamw> ack
17:59:27 <Viking-Ice> ack
17:59:29 <akshayvyas> ack
17:59:35 <tflink> #agreed 860276 - This appears to be a symptom of 858591, mark as a duplicate
17:59:44 <tflink> #topic (860430) RFE: dual boot support in newui
17:59:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=860430
17:59:45 <tflink> #info Proposed Blocker, NEW
18:00:08 <tflink> isn't this final instead of beta?
18:00:37 <tflink> I see, nvm
18:01:11 <adamw> god, i still suck.
18:01:16 <adamw> i knew there was something else i had to do this week.
18:01:26 <Viking-Ice> is this for multiple hd or for dual boot support ?
18:01:39 <tflink> I read it more as multiple HD and bootloader location choosing
18:02:11 * kparal is back
18:02:16 * Martix too
18:02:26 <Viking-Ice> "multi-boot support / bootloader configuration"
18:02:59 <Viking-Ice> so kparal and martix are one and the same for extra votes
18:02:59 <adamw> this is basically for bootloader location, yeah
18:03:21 <adamw> like i said, i think there's probably grounds to take this as a blocker but i need to go and figure what they are, and i still didn't get around to it :/
18:03:36 <Viking-Ice> punt for final
18:03:45 <tflink> punt, then? I don't see any criterion violations
18:04:04 <Viking-Ice> two for punt
18:04:26 <Viking-Ice> do I hear more
18:04:38 <adamw> tflink: i think it turns out to cause issues that block beta if you can't pick bootloader location, but again, i need to go back to f16 and look at the issues we hit then to be sure
18:04:50 <tflink> proposed #agreed 860430 - This may be a blocker but as currently written, does not violate any criteria. Will re-visit at a later meeting once it has been clarified
18:05:03 <adamw> it's not straightforward, it's the kind of indirect 'not being able to pick bootloader location causes $OTHER_SYMPTOM which is a beta blocker' kind of stuff
18:05:26 <adamw> now i think about it it might have involved upgrading, too, in which case it may be different with the new tool. eh.
18:05:27 <Viking-Ice> we cant block on hypotheticals
18:05:44 <tflink> Viking-Ice: which is why we're not accepting it
18:05:52 <adamw> Viking-Ice: sure, i'm just explaining why it keeps coming up, it's my fault for not nailing down the rationale :/
18:06:18 <Viking-Ice> tflink, yes I want to punt it to final instead of later beta meeting
18:06:33 <Viking-Ice> when adamw has done his homework ;)
18:06:37 <adamw> Viking-Ice: how about this, if i can't manage to get it nailed down by next week i'll change it to a final proposal
18:07:20 <adamw> ack
18:08:03 <tflink> any other votes?
18:08:31 * kparal has not read this bug, will vote on next one
18:08:33 <Viking-Ice> adamw, remember adding criteria etc... during review
18:09:08 <Viking-Ice> ack ( can always punt it for final on next meeting )
18:09:35 <tflink> #agreed 860430 - This may be a blocker but as currently written, does not violate any criteria. Will re-visit at a later meeting once it has been clarified
18:09:44 <adamw> Viking-Ice: i don't think we'd need to add criteria for this, just check on the big issues we had in f16 and see if we're likely to hit them again because of this. we covered it under the criteria at the time.
18:09:48 <tflink> #topic (859485) « Copy settings » to system in G-C-C's « Region & Language » panel causes weird keyboard behavior
18:09:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859485
18:09:53 <tflink> #info Proposed Blocker, NEW
18:11:03 <tflink> another clear-as-mud bug
18:11:06 <adamw> another mclasen nomination
18:11:10 <adamw> i'm asking him for a rationale
18:11:26 <adamw> well the bug seems pretty clear, but i don't immediately see a reason it needs to block release
18:11:42 <adamw> <mclasen> I just put bad bugs on the list
18:11:43 <adamw> I'll leave it to you to figure out criteria
18:11:49 <adamw> well, if he's leaving it to us, this don't look like blocker material to me.
18:11:52 <tflink> yep
18:11:59 <Viking-Ice> nope just a regular bug
18:12:10 <akshayvyas> i would say nth
18:12:28 <adamw> i can kinda see nth on the basis that people might well poke this setting before upgrading
18:12:31 <adamw> definitely not blocker though
18:12:31 <tflink> proposed #agreed 859485 - RejectedBlocker - This doesn't hit any of the F18 beta release criteria and thus is rejected as a blocker.
18:12:33 <Viking-Ice> reporters should do fresh beta install hence they are unlikely to hit this
18:12:34 <Viking-Ice> ack
18:12:36 <adamw> s/upgrading/updating/
18:12:43 <akshayvyas> ack
18:12:44 <adamw> ack
18:12:49 <Martix> ack
18:12:58 * tflink is -1 NTH if we're going that route
18:12:59 <kparal> isn't this clean install?
18:13:23 <tflink> #agreed 859485 - RejectedBlocker - This doesn't hit any of the F18 beta release criteria and thus is rejected as a blocker.
18:13:39 <Viking-Ice> yup but might be affected by the local bug we discussed earlier
18:13:40 <tflink> #topic (859614) [abrt] systemd-analyze-191-2.fc18: connection.py:651:call_blocking:DBusException: org.freedesktop.DBus.Error.Failed: Resource temporarily unavailable
18:13:43 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859614
18:13:46 <tflink> #info Proposed Blocker, NEW
18:14:07 <Viking-Ice> really systemd-analyze does not block the release
18:14:20 <Viking-Ice> this is just an regular bug
18:14:46 <Viking-Ice> + I dont think systemd-analyze gets installed by default these days
18:14:48 <Viking-Ice> anyway
18:15:08 <tflink> what exactly is the behavior fixed here?
18:15:23 <tflink> it sounds like there is more than just systemd-analyze with all the dupes
18:15:30 <Martix> -1
18:16:09 <Viking-Ice> selinux + systemd issue
18:16:19 <adamw> oh, this is the general selinux+systemd bug
18:16:23 <adamw> we should update the topic
18:16:35 <tflink> yeah, I see some blocker-worthy bugs in the dupes
18:16:37 <adamw> it has serious consequences
18:16:42 <tflink> 862387
18:16:49 <adamw> most obvious is Alpha "When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should boot to a state where it is possible to log in through at least one of the default virtual consoles"
18:16:59 <adamw> with selinux enabled you get no ttys right now
18:17:06 <Viking-Ice> I just pinged lennart to drop by
18:17:17 <Viking-Ice> so we can get status update on this
18:17:26 <adamw> however, there's a complicating factor
18:17:35 <adamw> systemd 190 isn't actually in stable
18:17:45 <tflink> ah
18:17:48 <adamw> i haven't checked, but tc1 should have 188, not 190, so it wouldn't be affected by this
18:17:58 <tflink> so you'd hit this with netinstall or post-install?
18:18:12 <adamw> yeah. we probably shouldn't take it as a blocker unless 188 goes to stable.
18:18:23 <tflink> adamw: you mean 190?
18:18:23 <adamw> sigh. 190+
18:18:25 <adamw> yeah.
18:18:31 <adamw> well, we're up to 193 now. but it's still broken.
18:18:38 <tflink> but it would get pulled in w/ netinstall
18:18:41 <adamw> as long as the systemd update doesn't get pushed stable until this is fixed, we're okay.
18:18:53 <adamw> tflink: yes, but we can't really take things as blockers on that basis, since what you get from netinstall is always going to be changing.
18:18:55 <tflink> assuming netinstall still pulls in updates-testing
18:19:08 <Martix> just run: "restorecon -R /" and move on next bug\
18:19:14 * Viking-Ice where's that German efficiency when you need one
18:19:21 <adamw> we can only take issues in stable as blockers, really.
18:19:27 <tflink> so reject for now, repropose if 190+ goes to stable?
18:19:33 <poettering> Viking-Ice: i am here
18:19:36 <adamw> i'd say we should executive unpropose rather than reject
18:19:42 <adamw> it's a small distinction, but hey
18:19:47 <Viking-Ice> we need status update on https://bugzilla.redhat.com/show_bug.cgi?id=859614
18:19:50 <Viking-Ice> and related bugs
18:20:10 <poettering> the systemd+selinux issue?
18:20:17 <Viking-Ice> yup
18:20:33 <poettering> currently writing the NEWS file for an update with this all fixed
18:20:39 <adamw> i like that kinda status!
18:20:39 <tflink> proposed #agreed 859614 - Since this bug isn't against the stable version of systemd, it doesn't qualify as a blocker for F18 beta. De-propose as a blocker for F18 beta, if 190+ is pushed stable before freeze, re-propose as blocker
18:20:42 <poettering> tested this earlier today with dwalsh in his cubicle
18:20:53 <Viking-Ice> see also https://bugzilla.redhat.com/show_bug.cgi?id=862798
18:20:55 <adamw> poettering: just to be safe, we obviously don't want the update pushed stable until the issue is confirmed fixed
18:21:01 <poettering> will now roll the release and upload it
18:21:17 <adamw> poettering: and if that requires an selinux-policy update too then the selinux-policy update should be included in the systemd update, ideally
18:21:20 <Martix> ack
18:21:25 <poettering> adamw: well, in 1h our so there should be an update in koji, and i'll edit the bodhi ticket and push it into testing
18:21:35 <poettering> adamw: it's up to you guys when you want to pull it in then
18:21:54 <poettering> adamw: it shouldn't need it right away
18:22:12 <adamw> poettering: well you can theoretically push it to stable at any time. we don't actually need to pull the update for the beta at all. we just want to make sure you don't push it in broken state.
18:22:19 <poettering> adamw: note that there might be corner cases where the policy needs more updating, but at least the most obvious things should be gone with this, i.e. getty should just work
18:22:25 <adamw> OK
18:22:31 <adamw> as long as we all know where we are i think it's fine
18:22:34 <poettering> adamw: i definitely want to see this new version in the beta
18:22:45 <poettering> it contains a ton of fixes, and i want the feedback
18:22:59 <adamw> sure, it's fine to push it stable when we're sure the big stuff is fixed. actually i think we do need it to fix some other blocker issue.
18:23:05 <Viking-Ice> so let's pull it in then
18:23:17 <adamw> #action adamw to re-test the tty bug with the new systemd build when lennart submits it
18:23:43 <tflink> sounds like punt for a later meeting, then
18:23:52 <adamw> i'd say un-propose, like i said earlier
18:24:07 <adamw> on the basis that this shouldn't be proposed as a blocker while the broken systemd is only in updates-testing
18:24:08 <Viking-Ice> ack
18:24:21 <adamw> but the potential exists that we could screw something up and put the broken packages in stable, then we'd need to have it as a blocker
18:25:11 <tflink> I see 2 acks and one implicit ack
18:25:16 <tflink> proposed #agreed 859614 - Since this bug isn't against the stable version of systemd, it doesn't qualify as a blocker for F18 beta. De-propose as a blocker for F18 beta, if 190+ is pushed stable before freeze, re-propose as blocker
18:25:27 <Viking-Ice> ack
18:25:29 <Martix> ack
18:25:38 <adamw> ack
18:26:09 <akshayvyas> ack
18:26:09 <tflink> #agreed 859614 - Since this bug isn't against the stable version of systemd, it doesn't qualify as a blocker for F18 beta. De-propose as a blocker for F18 beta, if 190+ is pushed stable before freeze, re-propose as blocker
18:26:23 <tflink> #topic (862612) anaconda freezes after clicking on "+" in keyboard layout settings
18:26:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862612
18:26:28 <tflink> #info Proposed Blocker, NEW
18:27:26 <garretraziel> I was unable to find suitable criterion for this, but it freezes, so...
18:27:33 <akshayvyas> can any one test this now
18:27:55 <adamw> this sounds a bit like that bug we had...last week...?...where it freezes if you do things in a particular order
18:28:01 <adamw> which we decided was too corner case-y to be a blocker
18:28:34 <Viking-Ice> this actually sounds like it's the live image not the installer " Boot live desktop of F18 Beta TC1"
18:28:54 <adamw> Viking-Ice: well, sounds like he was running a live install, since he's talking specifically about anaconda.
18:29:02 <adamw> it'd be interesting to know if it happened from dvd/netinst as well as live, yeah.
18:29:17 <garretraziel> it's anaconda in live
18:29:23 <adamw> i'm okay with considering this a conditional violation of a really basic criterion, as jan proposed.
18:29:56 <adamw> in the past that would have been obvious because you _had_ to go through the keyboard selection dialog
18:30:09 <garretraziel> mea culpa, I hadn't tested it in DVD/netinstall, but I think that kparal encountered similar bug in netinst...
18:30:12 <adamw> it's a bit less obvious now with the hub/spoke thing, but in practice, we should assume non-english speakers are naturally going to go and pick their keyboard layout first.
18:30:30 <kparal> yeah, I think I saw it in netinst as well
18:30:47 <Viking-Ice> yup and by beta they should be able
18:30:54 <adamw> yeah.
18:31:03 <adamw> we can just count it as part of the basic install path.
18:31:05 <Viking-Ice> +1 on blocker
18:31:25 <tflink> proposed #agreed 862612 - AcceptedBlocker - Conditional violation of the following F18 alpha release criterion for non-english keyboards: "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
18:31:30 <adamw> i'm just checking if i can reproduce
18:31:31 <akshayvyas> ack
18:31:36 <tflink> actually, wouldn't it be non-us keyboards
18:31:45 <adamw> yeah, that's more specific.
18:31:57 <adamw> funky british keyboards with everything in the wrong place. =)
18:32:36 <tflink> proposed #agreed 862612 - AcceptedBlocker - Conditional violation of the following F18 alpha release criterion for non-US keyboards: "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
18:32:40 <adamw> yup, reproduced.
18:32:46 <adamw> as simple as the report says.
18:32:47 <adamw> ack
18:32:47 <tflink> adamw: that's OK, we don't care about british people :-P
18:32:51 <adamw> =)
18:32:57 <Martix> ack
18:32:58 <akshayvyas> ack
18:33:03 <kparal> ack
18:33:07 <tflink> #agreed 862612 - AcceptedBlocker - Conditional violation of the following F18 alpha release criterion for non-US keyboards: "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
18:33:08 <Viking-Ice> ack
18:33:21 <tflink> #topic (862613) ValueError: cannot initialize a disk that has partitions
18:33:21 <Viking-Ice> English is something to conquer not learn
18:33:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862613
18:33:21 <tflink> #info Proposed Blocker, NEW
18:33:30 <Viking-Ice> Just like stable is for horses ;)
18:33:46 <tflink> hits the new criterion: The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched
18:34:20 <Martix> +1 bblocker
18:34:29 <Viking-Ice> blocker
18:34:33 <akshayvyas> mee too
18:35:07 <tflink> proposed #agreed 862613 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"
18:35:15 <Martix> ack
18:35:21 <kparal> ack
18:35:43 <akshayvyas> ack
18:35:54 <adamw> ack i guess.
18:35:57 * adamw catching up
18:36:14 <tflink> #agreed 862613 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"
18:36:22 <tflink> #topic (851114) RepoError: SQLite objects created in a thread can only be used in that same thread
18:36:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=851114
18:36:28 <tflink> #info Proposed Blocker, ASSIGNED
18:36:53 <tflink> yay, timing bugs!
18:37:10 <kparal> this is a clear blocker
18:37:15 <kparal> it crashes really often
18:37:20 <adamw> this seems easy enough to hit that even if there's a timing element to it, it's a blocker.
18:37:39 <tflink> agreed
18:37:42 <adamw> criterion "The installer must be able to install each of the release blocking desktops, as well as the minimal package set, with each supported installation method "
18:37:43 <adamw> (alpha)
18:37:50 <Viking-Ice> block block and block!
18:38:05 <Martix> block
18:38:34 <tflink> proposed #agreed 851114 - AcceptedBlocker - Conditional violation of the following F18 alpha release criterion (it is a timing bug that is very easy to hit): "The installer must be able to install each of the release blocking desktops, as well as the minimal package set, with each supported installation method"
18:38:40 <adamw> ack
18:38:46 <kparal> ack
18:38:48 <akshayvyas> ack
18:38:55 <tflink> #agreed 851114 - AcceptedBlocker - Conditional violation of the following F18 alpha release criterion (it is a timing bug that is very easy to hit): "The installer must be able to install each of the release blocking desktops, as well as the minimal package set, with each supported installation method"
18:39:07 <tflink> #topic (862557) repoclosure failure on 18 Beta TC1 DVDs (kernel)
18:39:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862557
18:39:07 <tflink> #info Proposed Blocker, ASSIGNED
18:39:54 <tflink> this is a repoclosure issue?
18:40:04 <Viking-Ice> sure blocker if is
18:40:25 <tflink> I agree that it sounds like a blocker but I'm skeptical that it's a repoclosure issue
18:40:39 <kparal> I don't really get comment #1
18:40:42 <Viking-Ice> looks local hence rejected
18:40:55 <Viking-Ice> "from myrepo"
18:41:00 <tflink> multiple reports of the DVDs failing to boot, though
18:41:10 <kparal> maybe Josh didn't understand it's part of DVD repo?
18:41:11 <zodbot> Ticket notification - f18betablocker: [Bug 862742] TypeError: coercing to Unicode: need string or buffer, NoneType found <https://bugzilla.redhat.com/show_bug.cgi?id=862742>
18:41:19 <adamw> i think 'myrepo' is what shows up for stuff pulled into composes via bleed
18:41:24 <adamw> dgilmore: is that correct?
18:41:47 <adamw> if anyone has a copy of the TC1 DVD handy they can loop mount it and just check what files are actually present
18:41:49 <kparal> I think myrepo is the name robatino used when using the repoclosure script
18:41:54 <adamw> ah
18:42:00 * adamw doesn't have it downloaded yet
18:42:11 * kparal trying quickly
18:42:16 <adamw> i'm +1 assuming it's actually the case that the kernel-tools package on the TC1 DVDs is mismatched.
18:42:46 <Viking-Ice> if it is it's a sure blocker
18:43:13 <tflink> oh, I'm on the wrong bug
18:43:13 <kparal> gimme a sec
18:43:15 <tflink> gah
18:43:23 <kparal> see https://fedoraproject.org/wiki/QA:Testcase_Mediakit_Repoclosure
18:43:25 <kparal> myrepo
18:43:46 * kparal running repoclosure
18:44:07 <kparal> confirmed: http://www.fpaste.org/LPfy/
18:44:11 <adamw> okay, then +1
18:44:19 <Viking-Ice> +1
18:44:21 <kparal> the package might be missing on the DVD
18:44:24 <kparal> or something
18:44:24 <adamw> i'll re-assign to distribution or something and clarify for jwb that it's a DVD compose issue not a kernel package issue
18:44:52 <tflink> that seems odd since pungi uses lorax for the install env creation
18:45:14 <tflink> nvm, I still have the other bug I was reading stuck in my head
18:45:23 * adamw slaps tflink upside the head
18:46:02 <tflink> proposed #agreed 862557 - AcceptedBlocker - Violates the following F18 alpha release criterion: "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install"
18:46:05 <satellit> tflink: FYI DVD works fine if edit command line https://bugzilla.redhat.com/show_bug.cgi?id=862537#c10
18:46:22 <adamw> ack
18:46:26 <Viking-Ice> ack
18:46:45 <Martix> ack
18:46:50 <tflink> #agreed 862557 - AcceptedBlocker - Violates the following F18 alpha release criterion: "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install"
18:46:55 <tflink> #topic (862784) error: rpmdb open failed
18:46:57 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862784
18:47:00 <tflink> #info Proposed Blocker, NEW
18:47:29 <Viking-Ice> satellit, I hit your comment 4 after updating last evening
18:47:49 <Viking-Ice> Gnome seem to insist wanting to install :lang=c
18:48:09 <Viking-Ice> in weird places I might add
18:48:13 <kparal> I saw djasa produce this bug. it happens if you do specific procedure inside custom partitioning
18:48:22 <tflink> is this a dupe of 862613?
18:48:44 <kparal> no
18:48:51 <kparal> almost certainly
18:49:12 <kparal> djasa just opened up custom partitioning and put / into root partition mount point
18:49:15 <kparal> and it exploded
18:49:24 <Viking-Ice> does this not hit our fine new criteria
18:49:55 <tflink> doesn't it? or am I being slow
18:50:03 <tflink> reusing a partition, no?
18:50:27 <kparal> not reusing, the partition was newly created
18:50:29 <Viking-Ice> yup ( step 2 comment 14 )
18:50:49 <adamw> it is re-using, by the looks of comment #14, he's talking about pre-creating partitions
18:50:57 <kparal> empty disk -> click partition spoke -> click custom -> click root partition -> put / into mount point -> click ok -> explode
18:50:58 <Viking-Ice> kparal, he first creates the partition then reboots into anaconda right
18:51:12 <adamw> it sounds like right now newui doesn't give you a great indication of whether the partition is going to be formatted or not...
18:51:17 <tflink> which is re-using an existing partition from the perspective from an install
18:51:23 <Viking-Ice> yup
18:51:32 <Viking-Ice> hence an blocker
18:51:46 <adamw> i'd like to do the reproduction myself to be totally clear about this one
18:51:55 <tflink> punt for more data?
18:52:07 <Viking-Ice> ?
18:52:30 <adamw> hm
18:52:31 <Viking-Ice> so we punt to confirm now is so we need to do it with everybug yay!
18:52:49 <tflink> I'm not clear on whether this was a valid partition layout
18:52:50 <adamw> actually, as written, the criterion i wrote rather does appear to cover re-using arbitrary partitions
18:53:08 <adamw> since i wrote "Creating, destroying and assigning mount points to partitions", which makes it sound like any one of those three actions should work
18:53:31 <adamw> that wasn't actually my intent, the idea was only to cover the case where anaconda is creating the partitions and assigning mount points to them, not re-use
18:53:55 <adamw> d'oh.
18:54:20 <adamw> i think for re-use we were going to consider covering the 're-use /home' scenario, but we weren't intending to cover 're-use arbitrary existing partitions', especially not for beta...
18:54:24 <tflink> wait, why is there a BIOS boot partition w/ GPT layout?
18:54:43 <adamw> a GPT layout is the _only_ time you should have a BIOS boot partition.
18:55:13 <tflink> wow, my mind must be somewhere else today
18:55:16 <adamw> bios boot / GPT disk is the configuration which requires a BIOS boot partition. bios boot / ms-dos label doesn't require any special partition. uefi boot / GPT label requires an EFI system partition.
18:55:35 <adamw> anyhoo
18:55:36 <adamw> uh
18:55:46 * kparal trying to reproduce quickly
18:55:57 * Viking-Ice goes out for a smoke in the meantime
18:55:59 <tflink> since I seem to be unable to think at the moment, what do we want to do with this right now?
18:56:00 <adamw> can we punt this to re-consider what we actually want the criterion to cover, and look at the exact newui design, perhaps even with 18.12?
18:56:07 <adamw> my fault for the bad wording, sorry
18:56:19 <kparal> so I think he had to be reusing existing partitions
18:56:27 <adamw> yeah, he clearly is
18:56:28 <kparal> it doesn't blow up for me
18:56:38 <adamw> there's even two cases of 're-use existing partitions', though
18:56:48 <adamw> use an existing partition but format it / use an existing partition without formatting it
18:57:07 <adamw> i didn't intend for the criterion to cover either, really, but we might want it to cover the first, or not, i think we need to think about it =)
18:57:11 <kparal> I saw his screen and it looked like new partition, but anaconda is very difficult to understand there
18:57:17 <kparal> so it was an existing one, clearly
18:57:27 <tflink> proposed #agreed 862784 - As currently written, this does violate the F18 beta release requirements but this is an unintended consequence of recent re-wording. Will re-visit next meeting once there has been a chance for criteria revision
18:57:33 <adamw> ack
18:57:36 <kparal> ack
18:57:47 <adamw> #action adamw to discipline himself for bad drafting
18:57:52 <adamw> .fire adamw
18:57:52 <zodbot> adamw fires adamw
18:58:33 <tflink> #agreed 862784 - As currently written, this does violate the F18 beta release requirements but this is an unintended consequence of recent re-wording. Will re-visit next meeting once there has been a chance for criteria revision
18:58:38 <tflink> #topic (862006) NameError: global name 'size_func_kwargs' is not defined
18:58:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862006
18:58:39 <tflink> #info Proposed Blocker, NEW
18:59:10 * tflink goes to get more coffee for brain jump-start. back in a sec
18:59:26 <kparal> see the dupe for more details
18:59:43 <kparal> I just wanted to create LVM layout
19:02:34 <adamw> we never really decided for sure if we're blocking on LVM at Beta, did we?
19:02:43 <kparal> didn't we?
19:02:53 <kparal> it's still in the criteria though
19:03:04 <adamw> wrt rescue mode?
19:03:11 <kparal> oh, just detect and mount
19:03:15 <kparal> my bad
19:03:26 <kparal> bad bad kparal
19:03:38 <adamw> i guess it becomes a case of 'is this a commonly used filesystem type'
19:03:50 <adamw> yay conditionals
19:04:00 <adamw> somehow we managed to avoid nailing this down in all the debates, heh
19:04:01 <kparal> 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
19:04:03 <kparal> it's Final
19:04:07 <adamw> that's final
19:04:08 <tflink> I would say yes because it has been the default for a while
19:04:14 <kparal> so I think reject Beta accept Final
19:04:17 <adamw> it's clearly a final blocker
19:04:21 <Viking-Ice> yup
19:04:29 <tflink> but I'm not against rejecting for beta
19:04:29 <Viking-Ice> reject beta accept final
19:04:33 <adamw> well, remember the final criterion is older wording, it wasn't explicitly written to tie in with the beta criteria
19:04:56 <adamw> we had _no_ beta criteria for partitioning with oldui, it was a simple 'autopart works at alpha, custompart works at final' split
19:04:59 <adamw> it's more complicated now
19:05:10 <adamw> we want some stuff in custom to work at beta, we've defined what it is to some extent, but not completely
19:05:47 <Viking-Ice> there are three acks for reject for beta accept final
19:06:11 * adamw is trying to muddy the waters =)
19:06:15 <Viking-Ice> we are barely have way through the list of proposed blockers
19:06:44 <adamw> Viking-Ice: i'm worried that we'd simply set a precedent we never block beta for lvm...which wasn't really agreed upon when drafting the criteria
19:06:54 <adamw> i don't mind if we choose to set that precedent but it isn't _dictated_ by the criteria as they stand
19:07:01 <adamw> it's not just a no-brain decision
19:07:01 <Viking-Ice> we dont default to lvm any more
19:07:08 <Viking-Ice> hence it's a ok
19:07:39 <tflink> but we did default to lvm, therefore it's a commonly used partition type
19:07:42 <adamw> kparal: tflink: so are you still -1 beta on that basis? (i'm not pressuring, just wanted to clarify the question, 'yes' is a perfectly fine answer...)
19:07:57 <tflink> I'm not -1 but I'm not going to fight rejecting all that much
19:08:15 <kparal> I think we should clarify with anaconda guys the status of LVM for Beta
19:08:20 <Viking-Ice> we also used to default to a lot of other old stuff
19:08:25 <adamw> tflink: right, that's my worry, at least for f18 i suspect many people might go for LVM since it's what they're used to...
19:08:29 <adamw> but hard to say.
19:08:33 <adamw> Viking-Ice: i asked, no reply yet
19:08:48 <adamw> sorry, that was meant to be kparal:
19:08:55 <kparal> let's accept for Final and put for Beta, wait for the reply
19:08:58 <kparal> *punt
19:09:13 <Viking-Ice> yup
19:09:17 <adamw> ok with me
19:09:28 <tflink> if we're going to punt, just punt - the status gets strange if we accept for final now and leave proposed for beta
19:09:42 <Viking-Ice> there nothing preventing us moving it to beta blocker if we deem it so
19:09:44 <adamw> i can note in the bug comment that we agreed to accept it as a final blocker.
19:09:59 <adamw> Viking-Ice: the problem is that AcceptedBlocker doesn't distinguish between releases
19:10:01 <tflink> Viking-Ice: if it isn't proposed for beta, it's likely to get forgotten
19:10:12 <tflink> adamw: that works for me
19:10:14 <adamw> so if we set blocks: f18beta f18blocker whiteboard: acceptedblocker, it looks like it's accepted as a beta blocker
19:10:29 <kparal> just use the comment
19:10:31 <adamw> if we set blocks: f18beta f18blocker, no whiteboard, it doesn't look like it's accepted for final
19:10:37 <adamw> inadequacy of the system, i know
19:11:15 <adamw> tflink: proposal?
19:11:36 <tflink> proposed #agreed 862006 - AcceptedBlocker (final) - It's still unclear whether or not this qualifies as a beta blocker for F18 but is a clear final blocker - will re-visit beta blocker status once we have more clarity on the status of LVM as a common partition type
19:11:48 <Viking-Ice> ack
19:11:50 <kparal> ack
19:12:39 <Viking-Ice> hello?
19:13:08 <tflink> adamw: vote?
19:13:18 <Viking-Ice> and yours ?
19:13:34 <tflink> I don't count for ack/nak since I wrote it
19:13:48 <Viking-Ice> did not know that
19:14:15 <Viking-Ice> then it's clear anyway 2 acks against adamw
19:14:31 <tflink> I'll accept shortly if we don't hear from adam but I also figured that he might have a different idea for wording
19:14:47 <adamw> ack
19:14:52 <Viking-Ice> finally
19:14:54 <tflink> #agreed 862006 - AcceptedBlocker (final) - It's still unclear whether or not this qualifies as a beta blocker for F18 but is a clear final blocker - will re-visit beta blocker status once we have more clarity on the status of LVM as a common partition type
19:14:59 <adamw> sorry, i was assuming it had gone through and writing the bug note
19:15:04 <adamw> my bad
19:15:18 <Viking-Ice> yeah we are wasting alot of time waiting for each others nack
19:15:22 <Viking-Ice> ack
19:15:33 <adamw> just my fault, sorry :/
19:15:34 <kparal> tflink: that's stupid, you can vote as well
19:15:45 <tflink> #topic (862801) Anaconda hangs when 'Configuring installed system'
19:15:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862801
19:15:46 <tflink> #info Proposed Blocker, NEW
19:16:04 <kparal> this is +1 blocker, happens _very_ often
19:16:08 <tflink> kparal: I didn't say no vote - ack/nak isn't the same thing. it's just agreeing that the wording of the #agreed represents what we decided
19:16:12 <adamw> kparal: ack/nack is a sanity/wording check on the agreement, not voting on the blocker/notblocker status, so it doesn't make sense for the person who writes it to vote on it. but it should probably go through with two acks.
19:16:55 <adamw> is this one possibly a dupe of the ifcfg bug from earlier?
19:16:58 <Viking-Ice> different from the other one we hit that happened around "Configuring installed system"
19:17:04 <Viking-Ice> ?
19:17:05 <kparal> oh, scratch my last comment
19:17:12 <kparal> I am mistaken
19:17:16 <adamw> oh no, that one was a crash
19:17:20 <adamw> this is a hang
19:17:24 <adamw> so _probably_ not the same
19:17:34 <Martix> blocker
19:17:41 <kparal> actually we saw this one on just one machine
19:17:45 <tflink> I've seen something similar once or twice
19:17:47 <kparal> it might be hardware related
19:17:53 <adamw> i think i saw it once too
19:17:55 <tflink> have no idea if it's the same bug, though
19:18:00 <adamw> seems a bit vague, but...
19:18:16 <kparal> otoh we can easily reproduce it, it has 100% failure rate
19:18:21 <kparal> on that particular machine
19:18:33 <Viking-Ice> what's so special about that machine?
19:18:45 <tflink> I'd say punt or reject with something hw specific
19:18:54 <tflink> and few reporters
19:18:57 <tflink> kparal: which machine?
19:19:05 <kparal> tflink: our uefi enabled asus
19:19:14 <kparal> amd cpu + amd graphics
19:19:29 <satellit> https://bugzilla.redhat.com/show_bug.cgi?id=862801#c8
19:19:31 <tflink> I have an AMD uefi box I could also try it on
19:19:35 <kparal> but this happened regardless of uefi
19:19:40 <Viking-Ice> ERR anaconda: unknown selinux state: None
19:19:46 <tflink> but not until tomorrow at the latest - I don't have the machine here right now
19:19:53 <tflink> s/latest/earliest
19:19:57 <kparal> maybe it's related how the usb stick got burned
19:20:01 <kparal> we will test more
19:20:03 <adamw> satellit: definitely a hang not a crash?
19:20:06 <kparal> punt for more data is ok
19:20:13 <Viking-Ice> punt it is
19:20:18 <adamw> yeah, i'd rather punt than reject, since it sounds like we have other sufferers
19:20:27 <satellit> it worked but put up a failed message
19:20:39 <satellit> ?
19:20:43 <Viking-Ice> that sounds like the other case
19:20:48 <adamw> satellit: a 'failed message'? a crash report?
19:20:58 <adamw> satellit: if so that sounds like https://bugzilla.redhat.com/show_bug.cgi?id=860791
19:21:01 <satellit> I did not keep it   sorry
19:21:12 <tflink> proposed #agreed 862801 - We need more information on what exactly is causing this and whether it is hardware specific before making a decision on blocker status
19:21:29 <adamw> ack
19:21:35 <Viking-Ice> ack
19:21:38 <akshayvyas> ack
19:21:42 <tflink> #agreed 862801 - We need more information on what exactly is causing this and whether it is hardware specific before making a decision on blocker status
19:21:56 <tflink> #topic (790365) Can't resume from suspend to RAM: Black screen and laptop frozen
19:21:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=790365
19:22:02 <tflink> #info Proposed Blocker, NEW
19:22:25 <adamw> suspend, no blocker.
19:22:35 <kparal> it has been unproposed
19:22:43 <kparal> tflink: maybe refresh your list
19:22:45 <Martix> tflink: you should refresh blocker page
19:22:51 <tflink> thanks, I figured that out
19:22:54 <Martix> tflink: I cleaned it a bit
19:23:10 <kparal> tflink: Martix did a lot of changes on the fly during the meeting
19:23:11 <tflink> refreshing the list is a non-trivial PITA
19:23:24 <kparal> (I mean a _lot_ of changes)
19:23:49 * tflink glares at Martix
19:23:56 <kparal> but we can just check whether those bugs has been unproposed, that's ok
19:23:59 <Martix> tflink: adamw anyway, I have low battery, so I vote on all GPU related proposed blockers as: +1 betablocker
19:24:21 <adamw> Martix: roger
19:24:31 <adamw> what, we didn't put power sockets in that new brno office yet? =)
19:24:43 <kparal> actually he's in pub!
19:24:54 <Martix> adamw: me and kparal are in the pub :-D
19:24:56 <kparal> damn
19:25:12 <kparal> Martix: run out of battery now!
19:25:17 <adamw> you're working in the pub?! that's...approved qa team style, have a raise.
19:25:18 <Viking-Ice> drink that strong alcohol while you still can
19:25:36 <Martix> kparal: give me power adapter!
19:25:53 <Martix> kparal: your welcome
19:26:01 <Martix> //about raise
19:26:18 * adamw assumes tflink is rejigging his list
19:26:31 <adamw> rejigging his list...oooh, matron.
19:26:42 <tflink> trying to figure out where we are in the new list
19:27:02 <Viking-Ice> great
19:27:23 <tflink> #topic (847818) Radeon RS690M/X1200 screen corruption beyond kernel-3.4.6-2.fc17.i686
19:27:24 <Martix> Radeon RS690M/X1200 screen corruption beyond kernel-3.4.6-2.fc17.i686
19:27:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=847818
19:27:29 <tflink> #info Proposed Blocker, NEW
19:27:38 <Viking-Ice> how about we put time limit on this meeting and continue tomorrow 3 hours is stretching it 4 hours is to much
19:27:45 <Martix> Radeon RS690M/X1200 screen corruption beyond kernel-3.4.6-2.fc17.i686
19:27:52 <Martix> that right
19:28:11 <adamw> tflink: how many bugs to go now?
19:28:22 <Viking-Ice> like he knows afer all the changes
19:28:32 <Martix> http://qa.fedoraproject.org/blockerbugs/current
19:28:47 <tflink> 19, I think
19:28:49 <Viking-Ice> next time let's not alter the http://qa.fedoraproject.org/blockerbugs/current while we are trying to follow it
19:28:50 <Martix> we are behind half of proposed
19:29:19 <adamw> Viking-Ice: well the alterations were to take a lot of bugs *out*, to shorten the meeting...
19:29:33 <tflink> Viking-Ice: yeah, I'm tempted to implement a pause feature for these meetings
19:29:37 <adamw> this sounds like a single-adapter bug to me, which we don't usually take as beta blockers.
19:29:41 <Viking-Ice> it´s better to split this over more days
19:29:46 <adamw> pausing after a few hours doesn't sound like a terrible idea though, yeah.
19:29:56 <adamw> especially with so many people in europe.
19:30:08 <adamw> do this bug then carry on tomorrow?
19:30:10 <tflink> I meant pause as in stop bz sync so the list doesn't change mid-meeting
19:30:14 <adamw> ah.
19:30:21 <adamw> i like the pause-the-meeting idea too though =)
19:30:26 <tflink> or flog people who change blockers during the meeting
19:30:37 <Martix> Viking-Ice: sorry, I finished testing bunch of GPU today and I started proposing blockers 10 mins before mtg
19:30:42 <tflink> either way, lets get this one done
19:30:55 * kparal prepares his whip
19:31:00 <adamw> yeah. like i said, our precedent has been not to take single-adapter bugs as blockers, usually
19:31:05 * kparal looks at Martix
19:31:08 <adamw> tends to need to be more like several cards or even a generation
19:31:11 <tflink> yeah, this is older and I don't think it's all that common
19:31:22 <tflink> common enough to justify blocker by itself, anyways
19:31:23 <adamw> especially for beta
19:31:26 <Viking-Ice> yup thats how we handle it
19:31:48 <adamw> +1 nth, though
19:31:59 <Viking-Ice> is there actually anyone handling radeon these days?
19:32:03 <tflink> proposed #agreed 847818 - RejectedBlocker - This appears to only affect a single adapter which isn't enough to justify blocker status for F18 beta
19:32:13 <adamw> Viking-Ice: airlied.
19:32:24 <Viking-Ice> I though he moved to intel hw
19:32:37 <adamw> Viking-Ice: afaik it's ajax for intel, airlied for radeon, darktama for nouveau
19:33:07 <Viking-Ice> yeah I knew that but I somehow was sure airlied was working on other stuff now
19:33:25 <Viking-Ice> must have dreamt it or something
19:33:28 <adamw> well he does do some work on x server itself i think
19:33:37 <adamw> i think ajax and airlied split that
19:33:40 <adamw> not 100% sure
19:33:45 <adamw> we need 5 more of each of them, anyways =)
19:33:51 <tflink> ack/nak/patch?
19:33:53 <Viking-Ice> ack
19:33:56 <tflink> adamw: no kidding :)
19:33:57 <adamw> patch AcceptedNTH?
19:34:04 <adamw> anyone else +1 nth?
19:34:10 <Viking-Ice> -1 nth
19:34:26 <tflink> I wish I was able to fix gfx bugs - I'm stuck on 3.0.x on my laptop right now due to an intel gfx bug
19:34:26 <adamw> why? 'graphics don't work' is something that's good to fix...
19:34:27 <Viking-Ice> dont want to pull in something that might potentally corrupt all those cards that do work
19:34:39 <adamw> well, there's that, but we usually check before pulling in nth fixes.
19:34:58 <tflink> yeah, I can see NTH on this
19:35:07 <tflink> as long as we're strict and we only pull in the fix for this
19:35:11 <adamw> if we're split on nth, just do the rejectedblocker and i'll propose it for nth and we can kick it around later.
19:35:23 <Viking-Ice> nah just make it nth
19:35:58 <tflink> proposed #agreed 847818 - RejectedBlocker AcceptedNTH - This appears to only affect a single adapter which isn't enough to justify blocker status for F18 beta. However, it is enough to justify NTH - a well tested fix would be accepted past freeze
19:36:03 <adamw> ack
19:36:09 <Viking-Ice> ack
19:36:26 <adamw> so do we want to vote on viking's idea to pause the meeting and finish it tomorrow?
19:36:29 <adamw> cos i for one am +1 :P
19:36:33 <tflink> I'm not against the idea
19:36:41 <adamw> we don't have any severe time pressure to finish the review off right now
19:37:11 <adamw> and it's not like we'd be setting a bad precedent or anything, it's usually just the first meeting or two of a cycle when there's a big pile of proposals to evaluate, no reason we shouldn't split it into manageable loads
19:37:23 <tflink> doesn't sounds like there are any objections
19:37:34 <Viking-Ice> that's just because we three are left
19:37:36 * adamw is going to bet that kparal and martix wouldn't be unhappy
19:37:44 <Viking-Ice> and kparal and martix drunk
19:37:48 <adamw> =)
19:37:49 <tflink> proposed #agreed - the next person who makes big changes to the blocker list mid-meeting gets the cat-o-9
19:37:54 * kparal is still here and Martix is looking over my shoulder
19:37:57 <adamw> patch: as long as it's not me
19:38:01 <adamw> :P
19:38:22 <tflink> anyhow, it sounds like we're all OK with continuing later
19:38:23 <Viking-Ice> so what 3 hour limit then split?
19:38:46 <tflink> Viking-Ice: depends on where we are in the release - if we're right before go/no-go, I'd say no
19:39:05 <tflink> since we're still unfrozen, it doesn't matter if we don't finish today
19:39:09 <tflink> #topic Open Floor
19:39:24 <tflink> Continue tomorrow, same bat-time, same bat-channel?
19:39:27 <kparal> was the last bug accepted?
19:39:28 <akshayvyas> oh cool
19:39:31 <tflink> ah
19:39:35 <kparal> I don't see #agreed
19:39:37 <tflink> whoops
19:39:39 <tflink> #undo
19:39:39 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x23015110>
19:39:45 <adamw> kparal: rejectedblocker acceptednth
19:39:45 <kparal> but ack from me
19:39:55 <tflink> #agreed 847818 - RejectedBlocker AcceptedNTH - This appears to only affect a single adapter which isn't enough to justify blocker status for F18 beta. However, it is enough to justify NTH - a well tested fix would be accepted past freeze
19:39:57 <satellit> https://bugzilla.redhat.com/show_bug.cgi?id=862591  nice to have?
19:40:03 <tflink> #topic Open Floor
19:40:10 <tflink> #unfo
19:40:12 <tflink> #undo
19:40:12 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x28d7b890>
19:40:21 <tflink> #topic Next Meeting
19:40:35 <tflink> so, tomorrow @ same time?
19:40:42 <Viking-Ice> yup
19:40:56 * kparal will have 1 hour, then he will have to leave
19:41:07 <Viking-Ice> party time?
19:41:14 <kparal> Fedora presentation time
19:41:22 <kparal> @ local university
19:41:23 <Viking-Ice> at the pub?
19:41:32 <zodbot> Ticket notification - commonbugsrss: [Bug 847818] Radeon RS690M/X1200 screen corruption beyond kernel-3.4.6-2.fc17.i686 <https://bugzilla.redhat.com/show_bug.cgi?id=847818>
19:41:35 <adamw> tomorrow's good for me
19:41:39 <akshayvyas> party will start tmrw at 1600 UTC :P
19:41:40 <adamw> send out an announcement, tflink?
19:41:48 <tflink> yeah, will do after the meeting
19:42:10 <tflink> #info Blocker review will continue 2012-10-04 @ 16:00 UTC
19:42:15 <tflink> #topic Open Floor
19:42:25 <tflink> anything else that needs to be brought up?
19:42:43 <Viking-Ice> not from me
19:43:12 * tflink will send out minutes and announcement for tomorrow's continuation shortly
19:43:20 <tflink> fuse is set for  [0,5] minutes
19:43:24 * kparal picks up Martin from under the table
19:43:29 <kparal> *Martix
19:43:33 <kparal> ygg,l'\
19:44:02 <kparal> he's so drunk
19:44:12 <tflink> kparal: sounds like you guys have other things to be doing, anyways :)
19:44:28 <tflink> thanks for coming everyone!
19:44:33 <tflink> #endmeeting