16:03:33 <tflink> #startmeeting f18-beta-blocker-review-1
16:03:33 <zodbot> Meeting started Wed Sep 26 16:03:33 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:33 <tflink> #meetingname f18-beta-blocker-review-1
16:03:33 <zodbot> The meeting name has been set to 'f18-beta-blocker-review-1'
16:03:46 <tflink> #topic Roll Call
16:03:54 <adamw> morning
16:03:58 <tflink> Wheeee! Who's ready for some blocker review fun?
16:04:02 * nirik is lurking around.
16:04:13 * Viking-Ice follows the peanut trail to the blocker bug meeting
16:04:27 <tflink> gah, looking at the current blocker tracking app is bad when I'm used to the devel version
16:04:51 <Viking-Ice> I feel like alpha blocker bugs meetings where just yesterday
16:05:00 * Martix is here and testing radeon
16:05:06 <kparal> oh, it's here?
16:05:14 * Cerlyn is here
16:05:21 * kparal was watching #fedora-bugzappers
16:05:25 <Viking-Ice> yup
16:05:26 <adamw> Viking-Ice: ah, the innocent past
16:05:51 <kparal> actually the emails says #fedora-bugzappers
16:05:54 <Martix> tflink: you did you advertised in e-mail #fedora-bugzappers?
16:05:54 <kparal> *email
16:05:58 <jlk> I'm lurking, waiting for a phone call to begin.
16:06:13 <tflink> Martix: yeah, I screwed up on that one. didn't realize it until just a little while ago
16:06:28 * jreznik is ready...
16:07:01 <tflink> the devel version of the blocker tracking app is up at http://supermegawaffle.com/blockerbugs-devel/ if anyone's interested in poking at it
16:07:33 <jreznik> Viking-Ice: I see the list of blocker bugs that grew over time and alpha seems to be like ages ago :)
16:08:32 <tflink> ok, I think we have enough people to get this party started
16:08:32 <jreznik> tflink: what's the font used?
16:08:45 <tflink> jreznik: comfortaa and cantarell
16:08:51 <tflink> for the devel version
16:08:52 <adamw> jreznik: skynet analyzes your brainwaves and picks the font you find most comforting
16:09:01 <adamw> it's all part of its plan to lull you into a false sense of security
16:09:43 <tflink> there's an icon font, too for the star (shows up as a 14 if js and/or web fonts aren't enabled)
16:09:47 <jreznik> adamw: the font I find the most dis-comforting :) but probably it's ok if it's default gnome one - some sort of masochism is not a bad idea during blocker bugs review :D
16:09:52 <kparal> tflink: looks great. I want it pushed to production! remember our motto :)
16:10:07 <adamw> 'we don't know what the hell we're doing'?
16:10:11 <adamw> oh, you meant our OTHER motto
16:10:18 <tflink> kparal: no production without a working admin interface, unfortunately
16:10:37 <Cerlyn> so the blocker tracking app has blocker bugs itself
16:10:38 <tflink> anywho ...
16:10:55 <jreznik> block the blocker!
16:11:05 <Martix> jreznik:  we need to go deeper!
16:11:11 <tflink> Cerlyn: the process isn't exactly straightforward, to be honest - especially now that it's tracking updates
16:11:13 <adamw> blue pill! BLUE PILL!
16:11:18 <Viking-Ice> hm question if I clock out now and run home be back in twenty minutes instead of being stuck here at work for the next 3 hours
16:11:32 <adamw> Viking-Ice: we'll probably be making bad jokes for the next 20 minutes anyhow, i say go for it :P
16:11:41 <Viking-Ice> adamw, you are at that age /me runs home
16:11:56 <tflink> it looks to be a long meeting, anyways :-/
16:12:06 <tflink> #topic Introduction
16:12:13 <jreznik> Viking-Ice: that's my problem too - I have meetings for another few hours... so 11 pm seems like a good time to go home from the office :D
16:12:17 <tflink> Why are we here?
16:12:17 <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:12:29 <tflink> #info We'll be following the process outlined at:
16:12:29 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:12:38 <tflink> #info The bugs up for review today are available at:
16:12:38 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:12:48 <tflink> #info The criteria for release blocking bugs can be found at:
16:12:48 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
16:12:48 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
16:12:48 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
16:13:06 <tflink> Since there are several release criteria still up for revision, I have a proposal to make
16:13:44 <kparal> let's not follow criteria?
16:13:45 <tflink> proposed #agreed - Ignore all proposed blockers which would hit a criterion currently proposed for revision
16:14:12 <tflink> so any blockers that are upgrade or partitioning related would be left alone for now until we get the criteria finalized
16:14:14 <kparal> let's just skip them and evaluate them next week, right
16:14:39 <tflink> since the whole point of this is to get the list down to a more managable number
16:14:46 <jreznik> I'd say not ignore but use it as an another input to release criteria discussion? but whatever makes this meeting shorter, I'm +1 :)
16:15:12 <adamw> ack
16:15:48 <tflink> proposed #agreed - Leave all proposed blockers which would hit a criterion currently proposed for revision for a later review meeting
16:15:55 <tflink> less strong than ignore
16:16:06 <tflink> but since there were no strong naks to the last wording
16:16:12 <jreznik> ack to the new proposal
16:16:13 <tflink> #agreed - Leave all proposed blockers which would hit a criterion currently proposed for revision for a later review meeting
16:16:39 <tflink> these numbers will be a bit off since we're skipping some, but ...
16:16:41 <tflink> #info 32 Proposed Blocker
16:16:42 <tflink> #info 0 Accepted Blocker
16:16:42 <tflink> #info 6 Proposed NTH
16:16:42 <tflink> #info 0 Accepted NTH
16:16:59 <tflink> unless there are objections, we'll start with the proposed blockers
16:17:06 <tflink> before I forget ...
16:17:11 <tflink> #chair adamw kparal
16:17:11 <zodbot> Current chairs: adamw kparal tflink
16:17:58 <tflink> #topic (824191) nfsiso install hangs during reboot
16:17:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=824191
16:17:58 <tflink> #info Proposed Blocker, NEW
16:19:22 <kparal> I think this can't be tested yet
16:19:31 <kparal> because nfsiso installation doesn't work yet
16:19:36 <kparal> so we can't verify
16:20:26 <tflink> is nfsiso expected for beta?
16:20:56 <kparal> see criteria #5 and #6
16:21:13 <kparal> I would say yes, but only NFS is explicitedly stated
16:21:20 <kparal> *explicitly
16:21:28 <tflink> let me rephrase - is anaconda going to have code for this in beta?
16:21:39 <kparal> ah, a different question
16:21:44 <tflink> eh, we'll deal with that potential issue later
16:22:29 <kparal> I asked wwoods about nfsiso support in some bug,  because current anaconda documentation doesn't talk about it at all. he didn't reply
16:22:56 <adamw> i don't see any anaconda folks present for this meeting
16:22:59 <adamw> so looks kinda punt-y
16:23:06 <tflink> I thought pjones joined
16:23:39 <adamw> oh, yes. pjones, any idea?
16:23:55 <jreznik> let's ask on #anaconda, maybe someone replies later there...
16:24:30 <wwoods> nfsiso should be supported.
16:24:52 <wwoods> there were other bugs in the way at the time which made testing that difficult.
16:25:07 <adamw> wwoods: 'should be supported'...now (18.8)? by beta time?
16:25:27 <tflink> proposed #agreed - 824191 - AcceptedBlocker - Accepted as a blocker for F18 beta due to violation of the following criterion: "The installer must be able to use the HTTP, FTP and NFS remote package source options"
16:25:48 * jreznik is waiting for wwoods answer... before acking
16:27:14 * pjones reads back
16:27:40 <pjones> yeah, no idea.  kinda not what I'm working on ATM
16:29:12 <jreznik> well that's the question if we should block bugs for beta on this if we are not sure it's in criteria and it will be in beta...
16:29:33 <kparal> well it is in current criteria
16:29:46 <tflink> and this criterion isn't currently proposed for revision
16:29:47 <adamw> we've read 'nfs' as including 'nfsiso' up till now, yeah.
16:29:55 <adamw> i guess ack is fine for now
16:30:25 <kparal> let's ack and I'll try to verify, provided nfsiso is already supported in anaconda
16:30:38 <tflink> I see 2 acks ... any more?
16:31:21 <jreznik> ok, ack
16:31:31 <tflink> #agreed - 824191 - AcceptedBlocker - Accepted as a blocker for F18 beta due to violation of the following criterion: "The installer must be able to use the HTTP, FTP and NFS remote package source options"
16:31:43 <tflink> #topic (847831) kickstart boot fails
16:31:43 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=847831
16:31:44 <tflink> #info Proposed Blocker, ASSIGNED
16:32:00 <tflink> pretty clear blocker to me
16:32:59 <tflink> proposed #agreed 847831 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to use all kickstart delivery methods"
16:33:13 <wwoods> we didn't drop support for nfsiso. do note that "nfsiso:..." is just an obsolete synonym for "nfs:..."
16:33:13 <jreznik> ack
16:33:13 <Martix> ack
16:33:52 <adamw> er
16:33:54 <adamw> nack
16:33:58 <adamw> you have to read all the way through
16:34:02 <tflink> adamw: patch?
16:34:16 <adamw> by comment #19 it's looking like an issue with a specific line in a specific kickstart, not a general 'kickstarts don't work'
16:34:22 <tflink> you mean that it has to do with the %pre that's being used in this case?
16:34:29 <adamw> see comment #17
16:34:29 <kparal> but no one tested that with a different kickstart
16:34:32 <kparal> so we don't know
16:35:01 <tflink> if it's all %include, I would say that it still hits
16:35:18 <tflink> but I'd be OK with punting
16:35:44 <jreznik> ...So I imagine it may work for many kickstarts, just not the one I use... <- do we want to be specific on which ks should work or not? it should work for correct ones...
16:36:01 <adamw> jlk: do you have a specific read on this one?
16:36:01 <kparal> I think the correct criterion for this one is:  The installer must be able to successfully complete a scripted installation, using the installer's preferred scripting system, which duplicates the default interactive installation as closely as possible
16:36:09 <adamw> right
16:36:15 <tflink> kparal: good point
16:36:38 <kparal> maybe we should mention 'kickstart' word there and not be too much generic
16:36:42 <kparal> but that's off-topic
16:36:51 <adamw> the 'kickstart delivery methods should work' criterion is more about being able to initiate a kickstart install; a case where the kickstart file was accepted but processing it failed doesn't hit that criterion
16:36:55 <tflink> proposed #agreed 847831 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to successfully complete a scripted installation, using the installer's preferred scripting system, which duplicates the default interactive installation as closely as possible"
16:37:01 <adamw> still nack
16:37:20 <adamw> then this criterion kparal just cited is about a kickstart install being able to complete, but it's a very limited one
16:37:20 <tflink> adamw: -1 blocker or nak on the proposal?
16:37:45 <kparal> let's punt and wait until we see whether some other kickstart works
16:37:52 <kparal> let's give action item to someone!
16:37:53 <adamw> the gloss on this one is that it means 'you should be able to do a default install and then re-run it using the generated /root/anaconda-ks.cfg'
16:38:00 <adamw> and _only_ that
16:38:09 <adamw> it's a fairly limited criterion, not an open-ended one
16:38:27 <kparal> that is the intended meaning?
16:38:31 <adamw> yeah
16:38:32 <kparal> I didn't read it like that
16:38:40 <adamw> i really need to draft better, i guess =)
16:38:59 <tflink> so we never block if some kickstart features don't work?
16:39:09 <kparal> now I know why the last sentence is there
16:39:12 <adamw> kparal: the thread is 'Release criteria: kickstart' from august 2011
16:40:05 * kparal has the same question as tflink
16:40:14 <adamw> so if you read through the thread
16:40:21 <adamw> there were lots of suggestions but no clear consensus
16:40:45 <adamw> so in a mail on 2011-08-30 i proposed this minimalist criterion just to get *something* done, and explicitly glossed it as described above
16:40:59 <adamw> "i.e. if you take /root/anaconda-ks.cfg from a
16:40:59 <adamw> click-through install and pass it to anaconda, it should successfully
16:40:59 <adamw> install. (Maybe with the small wrinkle that you uncomment the
16:40:59 <adamw> partitioning stuff, so it becomes a true unattended kickstart)"
16:41:18 <adamw> final paragraph was "We can then elaborate the criteria from there based on 'case law', i.e.,
16:41:18 <adamw> we can evaluate actual kickstart bugs as they're proposed as blockers
16:41:18 <adamw> and propose criteria based on the results of those discussions. How does
16:41:18 <adamw> that sound?"
16:41:34 <tflink> either way, punt on this?
16:41:50 <tflink> %include being broken and ks not working at all are different bugs, either way
16:41:50 <adamw> i think so, because we don't know specifically enough what's wrong
16:42:02 <adamw> it would be a candidate for the 'case law' thing, but only once we know exactly what the issue is
16:42:14 <adamw> then we could debate whether we consider that particular form of breakage something criterion-worthy
16:42:30 <tflink> proposed #agreed 847831 - There isn't enough information on what exactly is going wrong here to make a decision on blocker/NTH - will revisit after more testing
16:42:41 <adamw> ack
16:42:47 <kparal> ack
16:42:49 <adamw> and i'll put the gloss and stuff in the bug note
16:43:09 <adamw> i should really write that 'annotated guide to the release criteria', it seems =)
16:43:24 <kparal> illustrated!
16:43:46 <jreznik> ack
16:43:46 <Martix> as a comic book
16:43:49 <tflink> adamw: if you're going to do that soon, please tell me. I was going to write some wiki scraping code in the near future
16:43:52 <tflink> #agreed 847831 - There isn't enough information on what exactly is going wrong here to make a decision on blocker/NTH - will revisit after more testing
16:44:03 <tflink> wow, 2 bugs in 45 minutes - this is going to be a LONG meeting
16:44:11 <tflink> #topic (841451) polkitd doesn't start in F18/rawhide upgraded from F17 using yum due to failure to create polkitd user/group
16:44:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=841451
16:44:17 <tflink> #info Proposed Blocker, NEW
16:44:43 <tflink> this is a potential upgrade issue as I'm reading it
16:44:54 <tflink> I propose we leave it alone for now
16:45:47 <tflink> any objections?
16:46:11 <kparal> no
16:46:35 <tflink> proposed #agreed 841451 - This is a potential upgrade issue and as the upgrade criterion is currently up for revision, not evaluating more today
16:46:49 <kparal> ack
16:48:01 <adamw> ack
16:48:11 <tflink> #agreed 841451 - This is a potential upgrade issue and as the upgrade criterion is currently up for revision, not evaluating more today
16:48:22 <tflink> #topic (847472) DM configuration migration on upgrade not working
16:48:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=847472
16:48:22 <tflink> #info Proposed Blocker, MODIFIED
16:48:39 <adamw> actually, we should probably un-propose 841451, but eh.
16:49:00 <tflink> proposed #agreed 847472 - This is a potential upgrade issue and as the upgrade criterion is currently up for revision, not evaluating more today
16:49:09 <kparal> ack
16:49:10 <adamw> ack
16:49:16 <tflink> #agreed 847472 - This is a potential upgrade issue and as the upgrade criterion is currently up for revision, not evaluating more today
16:49:25 <tflink> #topic (853961) power-off/reboot results in log out after a long timeout
16:49:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=853961
16:49:25 <tflink> #info Proposed Blocker, NEW
16:49:50 <tflink> pretty clear blocker to me
16:50:20 <tflink> proposed #agreed 853961 - AcceptedBlocker - Violates the following F18 beta release criterion: "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work"
16:50:25 <tflink> ack/nak/patch?
16:50:28 <kparal> I have to admin I haven't seen it in a while
16:50:30 <kparal> it's probably fixed
16:50:32 <adamw> well...yeah
16:50:36 <kparal> but that doesn't really matter
16:50:39 <kparal> we can still accept it
16:50:44 <adamw> there's also the question is anyone but kparal seeing it
16:50:59 <adamw> if only kparal saw it, not an auto-blocker...
16:51:01 * tflink just got started testing F18 on real HW
16:51:18 <adamw> i've been on f18 for a while and didn't see this
16:51:38 <kparal> let's skip and give me an action item to re-test then
16:51:48 <kparal> I'm 80% sure it's gone now
16:51:53 <tflink> #action kparal to re-test 853961
16:52:45 <tflink> proposed #agreed 853961 - Not enough people reported seeing this to accept it as a blocker right now, more testing is needed
16:52:53 <kparal> ack
16:52:55 <Viking-Ice> ack
16:53:10 <Viking-Ice> for the record I have not seen this one either
16:53:36 <adamw> Viking-Ice: welcome back, you missed about two bugs :)
16:53:46 <adamw> ack
16:53:49 <tflink> #agreed 853961 - Not enough people reported seeing this to accept it as a blocker right now, more testing is needed
16:54:01 <tflink> #topic (853964) gdm freezes after authentication failure
16:54:01 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=853964
16:54:01 <tflink> #info Proposed Blocker, NEW
16:54:16 <tflink> sounds like this was reported by multiple people but it should be fixed
16:54:24 <tflink> accept or punt and hope it goes away?
16:54:48 <kparal> accept
16:55:16 <kparal> definitely
16:55:24 <garretraziel> yep, I saw it too, ack
16:55:36 <Viking-Ice> I have not experienced this one either but it's an ack from me
16:56:02 <adamw> yeah, +1 blocker
16:56:07 * jreznik is going to be disconnected for a few minutes...
16:56:27 <adamw> wrong criterion, though
16:56:46 <tflink> which criterion? It doesn't completely hit the one kparal specified since gdm does work as long as you enter OK credentials
16:57:05 <tflink> "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"?
16:57:14 <tflink> which isn't quite right, either
16:57:25 <adamw> the one kparal specified is about 'non-graphical installs', more to the point.
16:57:53 <tflink> alpha, then?
16:57:58 <tflink> "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 partitions when the correct passphrase is supplied"
16:58:19 <kparal> we don't have a perfect criterion, but we all agree it's a blocker, let's just ack it
16:58:22 <adamw> yeah, that's possibly the closest
16:58:24 <tflink> gah, that's not the one that I was looking for
16:58:38 <tflink> eh, works for me
16:58:55 <adamw> it's a violation of the https://fedoraproject.org/wiki/QA:Testcase_desktop_login testcase, which is marked as Beta
16:59:04 <adamw> though it kind of indicates we need better criteria to match that test case
16:59:27 <tflink> proposed #agreed 853964 - AcceptedBlocker - Violates the following F18 alpha release criterion: "
16:59:35 <adamw> #action adamw to propose Alpha and Beta criteria for login manager behaviour (see https://fedoraproject.org/wiki/QA:Testcase_desktop_login)
16:59:37 * tflink hit enter by accident
16:59:47 <Viking-Ice> hmm actually I think anyone that hit this with or during alpha will need to retest all bugs with beta or fully updated alpha and confirm if it's still an issue
17:00:22 <adamw> Viking-Ice: we're expecting it's fixed already, but that doesn't mean it's not a blocker, just that it's a blocker that will soon be closed :)
17:01:05 <tflink> proposed #agreed 853964 - AcceptedBlocker - Violates the following F18 alpha release criterion: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention."
17:01:14 <adamw> close enough.
17:01:15 <adamw> ack
17:01:17 <kparal> ack
17:01:20 <Viking-Ice> ack
17:01:23 <tflink> #agreed 853964 - AcceptedBlocker - Violates the following F18 alpha release criterion: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention."
17:01:38 <tflink> #topic (853877) anaconda ignores language / keyboard settings
17:01:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=853877
17:01:38 <tflink> #info Proposed Blocker, NEW
17:02:24 <Viking-Ice> ah the classic ack from me
17:03:05 <tflink> is this beta or final?
17:03:19 <Viking-Ice> beta I believe
17:03:38 <kparal> I don't see any i18n criteria
17:03:40 <adamw> i'm trying to remember what criterion we usually use for this
17:03:48 <tflink> the only thing I see is final
17:03:49 <Viking-Ice> adamw, none
17:03:57 <Viking-Ice> we voted upon it
17:03:58 <tflink> "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
17:04:39 <kparal> that's Final
17:04:44 <adamw> don't we normally consider the case of username/password?
17:04:58 <adamw> if the keyboard layout used in the installer and in the installed system don't match, you could be unable to login or it could be difficult
17:05:02 <tflink> yeah, that sounds right
17:05:18 <adamw> so it's a conditional breakage of that criterion, in the case of 'using a non-US keyboard map'
17:05:38 <tflink> which would have made it alpha, actually
17:05:45 <Viking-Ice> probably encrypted partitions + passwords as well
17:06:07 <adamw> right, encrypted partitions and root passwords, i think is what we're considering...
17:06:22 <adamw> so basically, "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 partitions when the correct passphrase is supplied "
17:06:49 <tflink> proposed #agreed 853877 - AcceptedBlocker - Violates the following F18 alpha criterion for non-US keyboards: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied"
17:07:05 <tflink> is that too long?
17:07:17 <kparal> nope
17:07:25 <Viking-Ice> ack
17:07:31 <Martix> ack
17:07:32 <adamw> maybe we should really have an explicit criterion for this, i dunno
17:07:32 <kparal> ack
17:07:39 <adamw> the amount of criteria judo seems excessive
17:07:41 <adamw> anyhoo, ack
17:07:50 <adamw> criteria twister!
17:07:53 <tflink> #agreed 853877 - AcceptedBlocker - Violates the following F18 alpha criterion for non-US keyboards: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied"
17:08:13 <tflink> yeah, keymaps seem to be important enough to justify a criterion
17:08:24 <tflink> someday, I'm going to get a non-US keyboard
17:08:31 <tflink> assuming I ever remember to do so
17:08:35 <Viking-Ice> yup for beta+ not so much for alpha
17:09:10 <tflink> #topic (855284) hanging gnome session processes cause gdm to think user still has an X session (was: gdm Session selection UI disappearing)
17:09:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855284
17:09:15 <tflink> #info Proposed Blocker, MODIFIED
17:09:17 * jreznik is Czech but nearly does not use non-english keyboard at all...
17:09:29 <adamw> i think we had a thread about i18n criteria once and it turned messy
17:09:49 <Viking-Ice> keyboard layout kinda is a must work by beta
17:10:54 <adamw> this sounds like a dupe of the previous one, no?
17:10:55 <jreznik> Viking-Ice: yep
17:11:12 <adamw> oh, no
17:11:16 <adamw> "Actually now I see there is already a report for the password lockup:
17:11:16 <adamw> bug 853964 so I will change this bug just to cover the Session UI
17:11:16 <adamw> disappearing."
17:11:41 <adamw> so this is about GDM's session chooser not showing up. i'm not convinced that's a blocker.
17:11:48 <adamw> anyone can cite a criterion? or think there ought to be one?
17:12:08 <tflink> "GDM regularly loses UI elements for the password prompt
17:12:09 <tflink> and session chooser."
17:12:24 <tflink> if it loses the UI elements for the password prompt, I'd say it's blocker
17:12:35 <tflink> otherwise, I agree that it's not a blocker
17:12:46 <satellit> session chooser needed for 2 DE install if one is gnome
17:12:52 <adamw> on the i18n criteria issue - we had https://fedorahosted.org/fedora-qa/ticket/81 , though i closed it. we might re-evaluate comment #2 and re-open it.
17:13:05 <adamw> tflink: the password prompt part is a dupe of the bug we already accepted.
17:13:14 <adamw> tflink: this bug is now only for the session chooser (see that comment I just quoted).
17:14:03 <kparal> accept as final blocker?
17:14:07 <Viking-Ice> I'm nack on this as a beta criteria
17:14:29 <adamw> satellit: sure, but is that in the criteria?
17:14:34 <tflink> adamw: the partial dupe says nothing about a disappearing password prompt
17:14:55 <tflink> nvm, it does
17:15:03 <tflink> just not in the original report
17:15:46 <tflink> are we sure that the gdm freezing and the password prompt going away are the same bug?
17:15:49 <adamw> so, i'm -1 on this for the session chooser issue. annoying bug, not in the criteria, probably doesn't need to be.
17:16:01 <adamw> well, jens seems to be.
17:16:34 <adamw> and anyway, this bug has been clearly used just to cover the session chooser issue. if there's still a problem with login after #853964 is fixed, it would be best to file a new bug, not use this one for two issues.
17:16:52 <jreznik> disappearing password prompt happened for me but not sure I hit gdm freeze...
17:18:01 <tflink> sounds like we're pretty much -1 blocker, though
17:18:19 * tflink still isn't sure that the bugs were split up correctly
17:19:00 <tflink> proposed #agreed 855284 - RejectedBlocker - The session choosing UI component in GDM is not part of any release criteria and thus rejected as a blocker bug for F18 beta
17:19:14 <adamw> ack
17:19:44 <kparal> ack
17:20:07 <jreznik> ack
17:20:14 <tflink> #agreed 855284 - RejectedBlocker - The session choosing UI component in GDM is not part of any release criteria and thus rejected as a blocker bug for F18 beta
17:20:31 <tflink> #topic (855976) In F18 Alpha, 'automatic' partitioning simply wipes your entire disk without warning you first
17:20:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855976
17:20:36 <tflink> #info Proposed Blocker, NEW
17:21:25 <tflink> do we skip this since it's partitioning related?
17:21:43 <tflink> ATM, the only criterion I can see that's related is the final "data eating is bad" criterion
17:21:52 <adamw> yeah, I think so
17:22:08 <adamw> (punt)(
17:22:16 <jreznik> skip it - we'll recheck with a new ui...
17:22:44 <tflink> proposed #agreed 855976 - Skipping review of this bug for now as partitioning related criteria are still under revision
17:23:12 <kparal> ack^3
17:23:18 <tflink> #agreed 855976 - Skipping review of this bug for now as partitioning related criteria are still under revision
17:23:35 * kparal has god powers, yay
17:23:35 * tflink isn't sure what ack to the third power is, but it seems to have worked :)
17:23:46 <adamw> mega-ack!
17:23:56 <tflink> cubic-ack?
17:23:57 <Viking-Ice> ack
17:24:05 <tflink> #topic (855083) Fail to start graphical installation on cirrus card in qemu
17:24:05 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855083
17:24:06 <tflink> #info Proposed Blocker, NEW
17:25:09 <tflink> so, the question becomes whether cirrus counts for blocking in the beta virt requirement
17:25:23 <kparal> virtualbox uses cirrus, right?
17:25:26 <tflink> since qxl is now the default, not sure if we really want to block for cirrus
17:25:44 <Viking-Ice> agreed
17:25:53 <tflink> kparal: not sure but I don't think that VB counts for the virt criterion even though lots of people seem to use it
17:26:08 <drago01> well the thing is cirrus is a "hardware plattform"
17:26:14 <drago01> I'd say even a common one
17:26:25 <jreznik> drago01: common one? really? these times?
17:26:26 <adamw> i don't think vbox uses cirrus, it uses either vesa or its own driver, doesn't it?
17:26:30 <adamw> cirrus is 'some KVMs'
17:26:44 <drago01> jreznik: qemu-kvm
17:26:52 <adamw> real hardware cirruses are dead, we do not care about them. no-one knows if the driver even works on them any more. it exists strictly for VMs.
17:26:56 <drago01> jreznik: we can't expect people to only run fedora on fedora virt
17:27:06 <drago01> jreznik: so "qxl is the default" does not change much really
17:27:11 <jreznik> drago01: in kvm, yes... but not as real hw...
17:27:13 <adamw> virtualbox is not in the criteria
17:27:20 <adamw> only KVM and Xen
17:27:27 <jreznik> drago01: for us, qxl is the default...
17:27:29 <drago01> jreznik: that's why I have used quotes around it
17:27:30 <adamw> so, forget vbox.
17:27:32 <muep> can qxl be used for remote VMs, too?
17:27:33 <tflink> IIRC, the kernel team doesn't always take VB related kernel bugs
17:27:50 <drago01> jreznik: you missed the point
17:27:56 <adamw> the only relevant cases here are KVMs that use the cirrus adapter, it's just a case of when we decide enough people are using qxl to not care about cirrus any more
17:28:09 <jreznik> drago01: cirrus has to die, sooner, better (in kvm)
17:28:12 <adamw> btw, i know what the bug is here, we just need to put the 'modesetting' driver in the anaconda environment instead of the 'cirrus' driver.
17:28:25 <muep> i.e. when you connect to a remote libvirtd with a local virt-manager
17:28:36 <drago01> jreznik: it will over time
17:28:36 <jreznik> adamw: is it still missing? I thought it was already imported...
17:28:42 <adamw> xorg-x11-drv-cirrus is no longer supposed to be used, the new design is the 'cirrus' kernel module (which does basic KMS) plus the xorg-x11-drv-modesetting X driver.
17:29:04 <adamw> jreznik: I think we've fixed it for live images and the installed system, but not for the environment of the traditional installer itself
17:29:35 <tflink> is cirrus the only platform affected?
17:29:47 <tflink> or does this affect other graphics platforms?
17:29:48 <adamw> this bug is clearly cirrus-specific.
17:29:51 <jreznik> tflink: if it's what's adamw is talking, then yes
17:30:30 <tflink> NTH?
17:30:34 <jreznik> well I'm more inclined to NTH, even we probably know simple solution
17:30:40 <jreznik> tflink: you were faster :D
17:30:44 <tflink> I'm not sure cirrus is enough for beta blocker
17:30:54 * jreznik should learn fast-typing
17:31:04 <adamw> i think for f17 we took some major cirrus issues as blockers but rejected some minor ones
17:31:14 <adamw> there's clearly some kind of transition curve between cirrus and qxl...
17:31:15 <Viking-Ice> ack on nth for beta
17:31:36 <adamw> i don't mind saying we're not blocking on cirrus as of f18, i guess.
17:31:37 <tflink> adamw: wasn't cirrus still default for F15, though?
17:31:54 <adamw> i think we've looked into the 'which one is default' question a few times and it's more subtle than it seems
17:31:56 <adamw> i forget the details though
17:32:17 <tflink> yeah, there was something about upgrading in there and libvirt/vmm not stomping on pre-existing defaults
17:32:33 <adamw> oh right
17:32:39 <adamw> i think it all tracked back to gconf keys and stuff
17:32:42 <tflink> either way, it sounds like we're OK with -1 blocker, +1 nth
17:32:48 <adamw> and that if you installed before a certain time, you had cirrus in your gconf and it was never getting out
17:32:58 <jreznik> there's also very simple workaround -> set qxl...
17:33:01 <tflink> which I thought was fixed
17:33:01 <adamw> right
17:33:05 <adamw> or vga, or anything else
17:33:30 <jreznik> vm*are :)
17:33:36 <adamw> or boot nomodeset
17:33:42 <adamw> or 'basic graphics mode'
17:33:47 <jreznik> -1 blocker, +1 nth...
17:34:25 <tflink> proposed #agreed 855083 - RejectedBlocker, AcceptedNTH - This bug only affects cirrus adapters which are no longer the default in Fedora's virt platforms. Since qxl is not affected, rejecting as a blocker for F18 beta. As cirrus is not uncommon, accepting as NTH
17:34:37 <Viking-Ice> ack
17:34:48 <adamw> ack
17:34:53 <Cerlyn> ack
17:35:13 <tflink> #agreed 855083 - RejectedBlocker, AcceptedNTH - This bug only affects cirrus adapters which are no longer the default in Fedora's virt platforms. Since qxl is not affected, rejecting as a blocker for F18 beta. As cirrus is not uncommon, accepting as NTH
17:35:22 <tflink> #topic (856894) 18 Alpha RC3 64-bit XFCE Live is > 700 MiB
17:35:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856894
17:35:23 <tflink> #info Proposed Blocker, NEW
17:35:43 * nirik looks up.
17:35:45 <tflink> -1 blocker, +1 NTH
17:35:52 <drago01> -1 its 2012
17:35:53 <nirik> I've not had a chance to look into this.
17:35:54 <tflink> XFCE is not a release-blocking desktop
17:36:29 <kparal> let's dump the 700MB requirement altogether
17:36:34 <adamw> right, oversize for a non-blocking desktop -> NTH
17:36:37 <Viking-Ice> yup
17:36:41 <adamw> kparal: that's the spin SIG's decision, not ours
17:36:42 <jreznik> kparal: yep
17:36:55 <adamw> kparal: KDE and GNOME have decided they're going with bigger limits for F18 already, Xfce could if they choose to
17:36:58 <tflink> proposed #agreed 856894 - RejectedBlocker, AcceptedNTH - Violates the following F18 beta release criterion for the XFCE spin: "The network installation image, DVD image, and live images for release-blocking desktops must meet current size requirements". Since XFCE is not a release-blocking DE, this is NTH instead of blocker.
17:37:01 <jreznik> adamw: then it's not a blocker - if XFCE spin SIG is happy with it
17:37:03 <Viking-Ice> actually I think that requirement has already been drop no?
17:37:04 <adamw> we just check whatever limit they decide they want
17:37:11 <Viking-Ice> yup
17:37:20 <jreznik> ok
17:37:29 <adamw> where's the page that says what the current target sizes are? I always forget
17:37:41 <nirik> Xfce spin is still targeting 700MB
17:37:46 <nirik> we have no plans to change off hand.
17:38:05 <nirik> https://fedoraproject.org/wiki/Releases/18/Spins
17:38:21 <jreznik> nirik: does it make sense for you to try to stick with 700 mb? isn't it shooting to the knee?
17:38:55 <adamw> off-topic for this meeting
17:39:05 <adamw> which is going to take long enough, so please, skip it :)
17:39:11 <nirik> well, with gnome/kde going to 1GB, I'm perfectly happy to cater to those people who still have spinning media. ;)
17:39:16 * nirik nods
17:39:37 <drago01> well last time I checked dvds are spinning media too ;)
17:39:46 <drago01> *were
17:40:04 <adamw> ack
17:40:09 <jreznik> ot, move on :) nirik - there's no other way for us... it pains to try to make 700 mb...
17:40:11 <Martix> -1 anyblocker +1 NTH
17:40:14 <jreznik> ack
17:40:20 <Viking-Ice> ack
17:40:21 <nirik> ack
17:40:26 <tflink> #agreed 856894 - RejectedBlocker, AcceptedNTH - Violates the following F18 beta release criterion for the XFCE spin: "The network installation image, DVD image, and live images for release-blocking desktops must meet current size requirements". Since XFCE is not a release-blocking DE, this is NTH instead of blocker.
17:40:29 <kparal> ack
17:40:40 <tflink> #topic (856090) ntpd not installed, causes firstboot to hang when user selects "Sync date and time over network"
17:40:42 <Martix> ack
17:40:43 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856090
17:40:45 <tflink> #info Proposed Blocker, NEW
17:41:06 <adamw> er, actually, 856894 is a dupe of 853590, which we'll hit in proposed NTH later if we get there
17:41:21 <adamw> any objections to me just marking it as a dupe and throwing acceptednth on 853590? no objections? good!
17:41:35 <tflink> works for me
17:41:50 <zodbot> Ticket notification - f18betanicetohave: [Bug 855083] Fail to start graphical installation on cirrus card in qemu <https://bugzilla.redhat.com/show_bug.cgi?id=855083>
17:42:03 <tflink> proposed #agreed 856090 - Mark as duplicate of 853530
17:42:13 <garretraziel> it seems that ntp works in newest anaconda
17:42:13 <tflink> er, that's not quite right
17:42:36 <tflink> #info 856090 is a duplicate of 853590 which is already proposed as NTH
17:42:59 <tflink> #info will handle this issue when 853590 comes up as a proposed NTH
17:43:11 <tflink> #topic (857886) X crash when unlocking Gnome Shell
17:43:11 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=857886
17:43:11 <tflink> #info Proposed Blocker, NEW
17:43:49 <adamw> wait. no.
17:43:54 <garretraziel> not anymore. fixed in newest update. it's still not present in alpha rc3, though
17:43:55 <adamw> get out the undo gun.
17:44:01 <tflink> #undo
17:44:01 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x383748d0>
17:44:03 <tflink> #undo
17:44:03 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x218d4e10>
17:44:05 <tflink> #undo
17:44:05 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x24b36490>
17:44:07 <adamw> it's 856894 which was the dupe, the Xfce over-size bug.
17:44:25 <adamw> the bug *before* 856090, not 856090 itself.
17:44:41 <tflink> #undo
17:44:41 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x24b36450>
17:44:43 <tflink> #info
17:44:57 <tflink> #undo
17:44:57 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2b92e590>
17:45:10 <tflink> damnation, where am I in the undo process?
17:45:31 <adamw> erm
17:45:44 <adamw> i think you just undid "856090 is a duplicate of 853590 which is already proposed as NTH"
17:45:54 <adamw> so we're in the right place now
17:46:01 <tflink> ok, sounds good
17:46:11 * tflink doesn't want to go back to the previous bug - is lazy like that
17:46:18 <tflink> since #undo is so much work :-P
17:46:21 <adamw> yeah, that's fine, we'll just do 856090.
17:46:57 <adamw> we don't actually have any tighter firstboot requirements after alpha afaics
17:47:01 <adamw> though we might have intended to write some
17:47:22 <Martix> damn, you skipped my bug! :-P
17:47:38 <tflink> what did we do in F17 with the ntp not installed stuff?
17:47:47 <adamw> ref https://fedorahosted.org/fedora-qa/ticket/79
17:47:51 <tflink> Martix: I did? Which bug?
17:47:57 <tflink> wait a second - the title is wrong
17:48:06 <adamw> the channel topic is wrong because #undo doesn't hit it
17:48:11 <adamw> but the meeting minutes should be right
17:48:18 <adamw> you could #undo the topic and re-do it, i guess
17:48:25 <tflink> #undo
17:48:25 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x33eb0750>
17:48:26 <tflink> #undo
17:48:26 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x35243c50>
17:48:27 <tflink> #undo
17:48:27 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x352437d0>
17:48:52 <adamw> one more...
17:48:53 <tflink> #undo
17:48:53 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x35243910>
17:48:57 <adamw> that should be the bunny
17:49:01 <tflink> #topic (856090) ntpd not installed, causes firstboot to hang when user selects "Sync date and time over network"
17:49:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856090
17:49:06 <tflink> #info Proposed Blocker, NEW
17:49:13 <tflink> which means that we weren't where I thought we were in the undo stack
17:49:21 <adamw> so yeah, our only firstboot criterion at present is that user creation has to work. per the criteria we don't care about anything else.
17:49:25 <adamw> https://fedorahosted.org/fedora-qa/ticket/79
17:49:36 <tflink> didn't we hit this in F17, too?
17:50:16 <adamw> i think it was that the checkbox didn't work, don't think it hung
17:50:49 <adamw> i don't mind this for beta, it seems like it maybe should block final though...
17:51:16 <tflink> IIRC, it doesn't become completely unresponsive, either
17:51:30 <tflink> you can turn off ntp and firstboot comes back
17:51:33 <tflink> at least it did for me
17:51:56 <tflink> other thoughts on beta/final?
17:52:44 <adamw> reject it for beta and punt for final?
17:52:46 <jreznik> +1 for final
17:54:21 <Martix> so 857886 is fixed, right?
17:54:53 <adamw> we haven't got to it yet
17:54:59 <adamw> we didn't skip it, we went back in time to before it
17:55:00 <Martix> ok
17:55:02 <adamw> we'll get to it after this one
17:55:22 <Martix> doing some GPU testing, cant follow
17:55:45 <adamw> propose #agreed 856090 RejectedBlocker, AcceptedNTH - doesn't hit any Beta criteria, but NTH as it's a visible flaw in common firstboot functionality
17:55:56 <tflink> ack
17:55:59 <jreznik> ack
17:56:01 <tflink> sorry for being slow
17:56:03 <kparal> ack
17:56:04 <Viking-Ice> ack
17:56:08 <adamw> #agreed 856090 RejectedBlocker, AcceptedNTH - doesn't hit any Beta criteria, but NTH as it's a visible flaw in common firstboot functionality
17:56:12 <adamw> i'll re-propose it for final in the bug.
17:56:19 <tflink> #topic (857886) X crash when unlocking Gnome Shell
17:56:19 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=857886
17:56:19 <tflink> #info Proposed Blocker, NEW
17:56:54 <tflink> assuming that the two reports are the same bug, this would seem to hit "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"
17:57:08 <tflink> but not really since it isn't part of the panel
17:57:56 <adamw> if anything for me this is just a 'functional desktop' or whatever the alpha wording is
17:58:19 <adamw> "working graphical environment"
17:58:42 <zodbot> Ticket notification - f18betanicetohave: [Bug 856090] ntpd not installed, causes firstboot to hang when user selects "Sync date and time over network" <https://bugzilla.redhat.com/show_bug.cgi?id=856090>
17:58:47 <adamw> or we take it under the escape clause as an urgent severity bug in a critical path package
17:59:45 <adamw> i'm not sure it scales to add criteria for every case of 'perfectly normal operation causes an X crash'
17:59:53 <tflink> proposed #agreed 857886 - AcceptedBlocker - Violates the following F18 alpha release criterion: "after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention."
18:00:11 <adamw> i'm okay with that
18:00:35 <jreznik> I agree with adamw - I expect this to be part of working graphical env.
18:00:54 <Martix> +1
18:01:54 <adamw> that's three acks
18:01:55 <garretraziel> (only note - it's already fixed, in updates, but it's not in alpha rc3)
18:02:12 <Martix> garretraziel: will check that tomorrow
18:03:03 <tflink> #agreed 857886 - AcceptedBlocker - Violates the following F18 alpha release criterion: "after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention."
18:03:15 <tflink> #topic (849707) AttributeError: 'BTRFSVolumeDevice' object has no attribute 'isMagic'
18:03:19 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849707
18:03:21 <tflink> #info Proposed Blocker, ASSIGNED
18:04:29 <tflink> if it wasn't btrfs, I'd say this is enough to take as a blocker since it's not quite partitioning related
18:04:40 <tflink> partitioning screen related, I mean
18:04:59 <adamw> i'm pretty +1 on this already
18:05:09 <adamw> i mean, it's pretty bad: the installer just blows up.
18:05:17 <adamw> like tflink says it's not really anaconda partitioning-related.
18:06:25 <adamw> it may be fixed already, too, based on the last comment - i'm asking dlehman now if it's in 18.8
18:06:41 <tflink> what criterion do we use, though?
18:06:53 <adamw> oh, take your pick
18:07:06 <adamw> any one of alpha 9 through 12
18:07:24 <adamw> conditionally, with the condition being 'you have an existing btrfs partition'
18:07:50 <tflink> proposed #agreed 849707 - AcceptedBlocker - Violates the following F18 alpha release criterion for systems with btrfs partitions: "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
18:08:07 * adamw checking with dlehman that it's as general as he thinks it is
18:09:51 <tflink> ack/nak/patch?
18:09:55 <Martix> ack
18:10:07 <tflink> or are we waiting to hear back from dlehman
18:10:19 <jreznik> waiting...
18:10:53 <adamw> eh, he's not responding
18:10:56 <adamw> ack on that basis, we can always change later
18:11:00 <adamw> it'll get closed soon probably anyhow
18:11:48 <tflink> #agreed 849707 - AcceptedBlocker - Violates the following F18 alpha release criterion for systems with btrfs partitions: "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
18:12:04 <tflink> #topic (835648) kernel freeze after [drm] Initialized drm 1.1.0 20060810 on T520 with Quadro NVS 4200M
18:12:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=835648
18:12:09 <tflink> #info Proposed Blocker, NEW
18:12:54 <tflink> it seems like several people are hitting this
18:13:01 <tflink> not sure which criteria it hits, though
18:13:32 <tflink> boot to working desktop with specific nvidia?
18:14:12 <adamw> yeah, it's one of those where it depends how much hardware is affected.
18:14:31 <adamw> seems to affect quite a few thinkpads
18:14:37 <Martix> I can confirm this and according to comments it affects various nvidia hw
18:14:48 <adamw> comment #12 is interesting, try turning off VT-d
18:14:51 <tflink> mostly optimus, no?
18:14:51 <Martix> but it got better, see last comment
18:15:26 <adamw> tflink: i'm not sure whether optimus is particularly relevant to the bug
18:15:52 <Martix> not Optimus, I tested this with discrete graphics only in BIOS
18:16:23 <tflink> I thought that just the presence of optimus (regardless of whether its enabled or not) could cause problems
18:17:32 <adamw> tflink: not really, if the BIOS offers a 'discrete' option then that basically turns the machine into a single gfx card system
18:17:48 <Martix> +1 adamw
18:17:49 <adamw> the other graphics card just does not appear to the post-BIOS environment at all, as far as fedora is concerned it doesn't exist
18:18:05 <adamw> some machines don't have a proper discrete option, but that's not the case here.
18:18:08 <tflink> that's how it's supposed to work, yes
18:18:28 <tflink> either way, thoughts on blockery-ness?
18:19:03 <adamw> i'd like to know if the VT-d workaround works for everyone
18:19:08 <adamw> if it does that'd probably be OK for beta for me
18:19:27 <adamw> i'd also probably want to check through the nouveau test day results again, i think there were a few bugs in there that may be dupes of this.
18:19:34 <tflink> even though disabling VT-d would break KVM?
18:19:43 <adamw> no it doesn't
18:19:47 <adamw> i've made that mistake before :)
18:19:48 <tflink> how's that?
18:19:53 <tflink> qemu would still work, yes
18:20:01 <adamw> VT-d is not VT-x.
18:20:02 <tflink> but IIRC, KVM requires HW support
18:20:05 <tflink> oh
18:20:17 <tflink> that's right VT-d is virtio
18:20:24 <adamw> see http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM
18:20:35 <Martix> disabling VT-d workarounds this bug for me, but this bug should be fixed in drivers, W7 has no such problem on same machine :-P
18:20:55 <adamw> Martix: oh sure it's definitely a bug and i'd want it fixed for final
18:20:59 <tflink> punt for now?
18:21:00 <adamw> but i think VT-d workaround is probably ok for beta
18:21:07 <adamw> yeah, punt for data i think
18:21:08 <Martix> adamw: ok
18:21:08 <jreznik> for beta it's ok
18:21:59 <Martix> -1 beta, +1 final
18:22:01 <tflink> proposed #agreed 835648 - Waiting for more information before deciding on blocker status for beta - disabling VT-d is probably an OK workaround for beta, may reject and move to final blocker
18:22:07 <adamw> ack
18:22:42 <Martix> ack
18:22:57 <jreznik> ack
18:23:04 <tflink> #agreed 835648 - Waiting for more information before deciding on blocker status for beta - disabling VT-d is probably an OK workaround for beta, may reject and move to final blocker
18:23:16 <tflink> #topic (856225) PackageKit can't import Fedora GPG key
18:23:16 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856225
18:23:16 <tflink> #info Proposed Blocker, ASSIGNED
18:24:02 <tflink> I forget, did the 'all' part of updates get moved to beta or final?
18:24:18 <jreznik> I'd say it's beta... but not sure
18:24:47 <adamw> beta i think
18:25:02 <tflink> "The default update manager in release-blocking desktops must not periodically check for updates when the system is booted live, but must periodically check for updates when running on an installed system" ?
18:25:15 <adamw> nah, that's about checking for updates not installing them
18:25:54 <adamw> actually
18:25:58 <adamw> we didn't change the criteria
18:26:09 <adamw> viking and I are planning to propose it, but for Alpha all we did was say this was 'workaroundable'
18:26:15 <adamw> we didn't waive the graphical update criterion
18:26:25 <adamw> so that would still be the applicable one
18:26:29 <adamw> "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops "
18:26:50 <adamw> question is whether we're still happy with the workaround of 'run yum once' for beta
18:26:51 <jreznik> well, if this criteria is under review -> skip it
18:26:58 <adamw> no, there's no active proposal
18:27:25 <tflink> proposed #agreed 856225 - AcceptedBlocker - Violates the following F18 alpha release criterion: "
18:27:28 <jreznik> sorry, I was just confused...
18:27:28 <tflink> The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
18:27:34 <tflink> crap
18:27:39 <tflink> proposed #agreed 856225 - AcceptedBlocker - Violates the following F18 alpha release criterion: "
18:27:41 <kparal> personally I am not fine with 'run yum once' for Beta
18:27:42 <tflink> The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops
18:27:56 <tflink> proposed #agreed 856225 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
18:27:58 <jreznik> adamw: for beta it's not a nice workaround...
18:28:00 <tflink> third time's the charm!
18:28:10 <kparal> ack
18:28:15 <adamw> yeah, i think i'm ack for a beta
18:28:17 <jreznik> ack
18:28:23 <adamw> Viking-Ice: wdyt? still around?
18:30:01 <tflink> #agreed 856225 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
18:30:15 <tflink> #topic (856256) Crash when unlocking screensaver
18:30:15 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856256
18:30:15 <tflink> #info Proposed Blocker, NEW
18:31:27 * tflink wonders if this and 857886 are the same bug
18:32:00 <tflink> I'd say accept it, add a note and if devs say they're dupes, one of them will disappear
18:32:17 * jreznik thinks so
18:32:20 <adamw> ajax said they're likely not
18:32:23 <adamw> even if the symptoms are the same
18:32:34 <adamw> it's pretty unusual for crashes in two completely different drivers to be caused by the same bug
18:32:34 <tflink> ok
18:32:38 <adamw> so i was leaving them separate for now
18:32:53 <jreznik> fair enough
18:32:59 <adamw> "ajax says the trace looks specific to qxl"
18:33:17 <adamw> has anyone reproduced this since alpha, btw?
18:33:48 * adamw checks in a vm with the test day image installed
18:34:27 <tflink> I haven't seen this on either VMs or bare metal w/ nouveau recently
18:34:32 <tflink> not sure how common it was, though
18:34:32 <kparal> question is whether the fix is in master
18:34:33 <adamw> yeah, doesn't seem to be happening on the test day image
18:34:35 <adamw> it was common
18:34:51 <adamw> it seemed 100% reproducible to me with alpha
18:34:52 <kparal> it was 100% reproducible
18:35:08 <adamw> kparal: true, i pulled in a few things that weren't stable, though not qxl
18:35:25 <tflink> either way, votes on blockery-ness
18:35:28 <adamw> i'm probably +1 on this, same as the nouveau one
18:35:29 * tflink assumes +1 blocker
18:35:37 <kparal> seems fixed
18:35:40 <adamw> since qxl is the one we care about
18:35:49 <adamw> kparal: with latest stable?
18:35:54 <kparal> yup
18:35:56 <adamw> ok
18:36:01 <adamw> i propose we just close it then
18:36:07 <adamw> re-open if anyone can reproduce with stable
18:36:12 <kparal> I'll test more before we close it
18:36:16 <tflink> proposed #agreed 846256 - AcceptedBlocker - Violates the following F18 alpha release 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:36:42 <kparal> ack
18:36:45 <Martix> ack
18:37:18 <kparal> my VM was not even fully updated
18:38:12 <adamw> sure, ack
18:38:14 <tflink> #agreed 846256 - AcceptedBlocker - Violates the following F18 alpha release 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:38:33 <tflink> topic (855849) could not UEFI boot F18 Alpha (TC6 through RC3) DVD or netinst written to optical disc or dd'ed to USB: /dev/root does not exist
18:38:36 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855849
18:38:38 <tflink> #info Proposed Blocker, NEW
18:39:39 <tflink> seems +1 blocker to me
18:40:07 <tflink> proposed #agreed 856256 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to a USB stick with any of the officially supported methods"
18:40:19 <kparal> ack
18:40:37 <garretraziel> I was unable to install fedora using uefi on any hardware (it worked only on Mac Mini, iirc), so ack
18:41:02 <tflink> garretraziel: I think that USBs created using livecd-iso-to-disk are working
18:41:05 <adamw> right, as we modified the criteria this is clearly a blocker.
18:42:03 <tflink> any more ack/nak?
18:42:36 <adamw> ack
18:42:39 <tflink> proposed #agreed 856256 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to a USB stick with any of the officially supported methods"
18:42:44 <tflink> #agreed 856256 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to a USB stick with any of the officially supported methods"
18:42:49 <tflink> fail
18:42:56 <tflink> #topic (858233) automatic partitioning hangs when removing existing LVs
18:42:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=858233
18:42:56 <tflink> #info Proposed Blocker, MODIFIED
18:43:06 <tflink> are we skipping this one?
18:43:25 <tflink> it seems outside of the "what autopart methods are going to exist" issue
18:43:33 <Viking-Ice> sorry I was afk for a while a visitor dropped by
18:43:57 <tflink> LVs have been a part of the default install for a long time - autopart shouldn't crash when it encounters them even if it doesn't support LVM for F18
18:44:10 <tflink> s/crash/hang
18:44:30 <tflink> but we only have one reporter for this
18:44:35 * adamw reads
18:44:46 <tflink> would be good to have more instances of the hang before taking as a blocker
18:44:50 <kparal> it is in modified now, so something was fixed
18:44:55 <kparal> i.e. a bug was found
18:45:03 <kparal> and confirmed by anaconda dev
18:45:03 <tflink> should be fixed in 18.8
18:45:09 <tflink> which is in smoketest1
18:45:37 <kparal> yeah, I can try. unfortunately this bug was highly non-deterministic
18:45:40 <adamw> "But it is hard to reproduce, the same installation went fine on a second attempt on one machine, but also failed on a second attempt on a different machine. So it's not really deterministic."
18:45:51 <Viking-Ice> nth
18:46:02 <tflink> even more reason to punt for more data
18:46:07 <Viking-Ice> ah yes
18:46:07 <adamw> clumens set it to MODIFIED
18:46:28 <tflink> should be ON_QA, no?
18:47:09 <tflink> or closed since 18.8-1 is stable
18:47:34 <tflink> either way, sounds like punt time
18:47:40 <kparal> ack
18:47:54 <Viking-Ice> ack
18:48:21 <tflink> proposed #agreed 858233 - We would like to see more data and testing on this before deciding on blocker status. This may be fixed in anaconda-18.8-1 but confimation would be helpful
18:48:45 <adamw> i'm asking clumens when exactly it'd be triggered
18:50:05 <adamw> eh, punt is fine
18:50:07 <adamw> let's move on
18:50:07 <adamw> ack
18:50:36 <tflink> #agreed 858233 - We would like to see more data and testing on this before deciding on blocker status. This may be fixed in anaconda-18.8-1 but confimation would be helpful
18:50:55 <tflink> #topic (858270) basic graphics mode doesn't create Xorg conf file specifying vesa
18:50:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=858270
18:51:01 <tflink> #info Proposed Blocker, NEW
18:52:29 <Viking-Ice> based on Adams input there I view this just as an regular bug
18:52:30 <kparal> seems that some xorg patching is needed instead
18:53:11 <adamw> right, i think my assertion that this will usually turn out to work okay stands for beta and probably final
18:53:34 <kparal> but we should verify basic graphics with UEFI
18:53:38 <Viking-Ice> + there is not supposed to be xorg.conf file since what F9 or something
18:53:41 <adamw> the only cases where 'nomodeset' alone isn't, in practice, enough to cause vesa to be used are on systems where the graphics adapter uses a driver which still have UMS code
18:54:07 * jreznik is on board meeting, will be silent for some time
18:54:10 <adamw> Viking-Ice: what's supposed to get written is an xorg.conf.d snippet, which is fine. writing the snippet would be the correct behaviour. it's just that in practice, the bug isn't terribly important
18:54:20 <adamw> there's almost no drivers with UMS code any more.
18:54:36 <kparal> ajax says the snippet could break UEFI systems
18:54:41 <adamw> oh, missed that
18:54:43 <kparal> so I don't really know how to adjust the tet case
18:54:49 <kparal> *test case
18:55:21 <pjones> uefi basic graphics is basically "X needs to work with fbcon in cases where there's no KMS driver"
18:55:23 <adamw> ah, okay. well that's kind of a new wrinkle
18:55:55 <adamw> ajax's plan seems fine to me, implement some kind of directive for X to force whatever the proper fallback behaviour ought to be, and change 'basic graphics mode' to do that.
18:57:11 <tflink> according to the current release criteria, I don't see any reason that this wouldn't be a blocker
18:57:18 <tflink> am I missing something
18:57:45 <tflink> proposed #agreed 858270 - AcceptedBlocker - Violates the following F18 alpha release criterion:
18:57:53 <tflink> wow, I seem to have fat fingers today
18:58:07 <Viking-Ice> five thumbs?
18:58:17 <tflink> proposed #agreed 858270 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The boot menu for all installation images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer and attempting to use the generic driver"
18:58:39 <tflink> I also keep switching back and forth between very different keyboards - I'm using that as my excuse :)
18:58:46 <adamw> nack.
18:59:03 <tflink> adamw: patch?
18:59:06 <adamw> again, the fact is that at present, the simple presence of 'nomodeset' causes the right thing to happen in almost every case.
18:59:21 <adamw> so in practice, the menu option works. it's just doing so more or less by accident. :)
18:59:36 <Viking-Ice> how likely are we going to see this properly fixed before final?
18:59:53 <Viking-Ice> ( As in the solution that ajax mentions there )
18:59:56 <adamw> well if ajax says the X side is easy...it should be perfectly possible
19:00:08 <adamw> the anaconda/liveinst side is similarly straightforward, i could likely patch it myself even
19:00:26 <adamw> so there's no reason we couldn't do it, but of course if it's not a blocker we might not get around to it.
19:00:31 <nanonyme> Doesn't sound easy to me but ajax knows X better than me anyhow.
19:00:37 <tflink> So I'm confused - there's no bug here, it's not a blocker or the fix is easy?
19:00:58 <Viking-Ice> more like if not a blocker it probably wont get fixed?
19:01:01 <adamw> tflink: there's a bug, the fix is probably quite easy, and in practice, the bug doesn't really break stuff.
19:01:17 <adamw> Viking-Ice: it still could, it'd just require me to remember to keep bugging ajax about it most likely.
19:01:24 <Viking-Ice> nth?
19:01:25 <tflink> as long as you're not stuck on UEFI with a broken gfx driver?
19:01:46 <adamw> i don't think nth is really appropriate since the changes to fix this would be quite large (though they ought to be simple) and don't have much practical effect
19:01:47 <nanonyme> Also doesn't a Xorg.conf file specifying vesa blow up if you have KMS?
19:01:53 <nanonyme> Erm, xorg.conf even.
19:02:05 <nanonyme> That's what it used to do anyway
19:02:15 <adamw> nanonyme: if you don't pass 'nomodeset', yes
19:02:36 <adamw> nanonyme: but the 'basic graphics driver' mechanism is supposed to *both* pass nomodeset *and* write an xorg.conf.d snippet
19:02:53 <adamw> the history is that it used to _just_ write an xorg.conf or xorg.conf.d snippet which specified vesa
19:03:04 <adamw> then when KMS came in, we found that broke for KMS drivers, because the KMS driver would conflict with vesa
19:03:09 <adamw> so we made it also pass 'nomodeset'
19:03:12 <pjones> tflink: if your firmware driver is broken, that's not a problem with meeting the release criteria, that's a problem with your hardware.
19:03:14 <nanonyme> Ah, okay. Sounds good enough to me then.
19:03:39 <adamw> now the xorg.conf.d snippet writing bit appears to be broken...but the fact that we added the 'nomodeset' bit, happily, means it still pretty much works, since passing 'nomodeset' forces you to vesa.
19:04:00 <adamw> tflink: does that make it any clearer? :)
19:04:39 <tflink> not really but it sounds like rejected blocker is pretty much agreed
19:04:53 * kparal shrugs
19:05:11 <kparal> can somebody tell me how should I adjust the test case?
19:05:12 <nanonyme> Of course, would be nice to have the proper mechanism if it's actually easy imo.
19:05:46 <tflink> proposed #agreed 858270 - RejectedBlocker - While not behaving in an ideal manner, there is little that is actually broken from a practical perspective. Therefore this bug is rejected as a blocker for F18 beta
19:05:50 <tflink> ack/nak/patch?
19:06:07 <kparal> ack
19:07:27 <Viking-Ice> ack
19:07:28 <nanonyme> ack
19:07:38 <tflink> #agreed 858270 - RejectedBlocker - While not behaving in an ideal manner, there is little that is actually broken from a practical perspective. Therefore this bug is rejected as a blocker for F18 beta
19:07:56 <tflink> #topic (856938) Native UEFI install from F18 Alpha RC3 DVD written to USB with livecd-iso-to-disk fails to boot
19:07:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856938
19:08:01 <tflink> #info Proposed Blocker, POST
19:09:04 <adamw> kparal: as it stands i don't think the test case really needs much adjustment, because all the things it tests for should strictly be there. it's just that we're saying the test case failing is not a blocker because of the practical consequences.
19:09:18 <adamw> kparal: if we change the mechanism the way ajax suggests, we'll have to change the test case.
19:09:48 <kparal> adamw: I just don't want all testers to report the same bug over and over again. adding info box
19:10:01 <adamw> kparal: yeah, an infobox linking to the bug might be a good idea.
19:11:29 <tflink> any thoughts on this as a blocker for beta?
19:12:00 <tflink> since it seems to only affect some UEFI systems and not others
19:13:22 <adamw> i don't think we really have the data to decide
19:13:25 <adamw> we know exactly what the problem is
19:13:46 <adamw> but we just don't really have any way of knowing how many UEFI firmwares can cope with the trailing \ not being present, and how many can't cope
19:13:50 <Viking-Ice> oh great I just manage to fill my /tmp by choosing to open a file with archive manager instead of saving it to a specific location in firefox <hurray tmp on tmpfs bug filed>
19:13:51 <tflink> just not how many UEFI systems  would be affected?
19:13:59 <adamw> right
19:14:09 <adamw> pjones: agree?
19:14:45 <pjones> I think we have to take the patch, but we also already took the patch.
19:15:39 <adamw> sure
19:15:43 <adamw> it's a bit academic
19:15:57 <adamw> oh hey, is the patch in 18.8?
19:16:16 <tflink> OK, lets get some votes, then
19:16:25 <adamw> i'd say punt
19:16:27 <tflink> we still have 11 more blockers to go through
19:16:32 <adamw> and with any luck close it before we have to care again
19:16:39 <adamw> pjones: did the fix go in 18.8, do you know?
19:16:43 <adamw> if it did i can re-test with smoketest and close it
19:17:03 <pjones> checking
19:17:07 <tflink> proposed #agreed 856938 - Problem was identified but the number of affected UEFI systems is still unclear - will revisit once more data is available
19:17:32 <pjones> looks like it's in 18.9-1
19:17:39 <adamw> ok
19:17:46 <adamw> i'll re-test when we get an 18.9 build
19:17:49 <pjones> I think we saw enough machines break that we can assume it's a large number of machines.
19:18:38 <adamw> ack on the punt
19:19:21 <tflink> any other ack/nak-patch?
19:20:24 <tflink> I believe that we've lost pretty much everyone else
19:20:37 <tflink> #agreed 856938 - Problem was identified but the number of affected UEFI systems is still unclear - will revisit once more data is available
19:20:45 * kparal is still a bit alive
19:20:52 <tflink> #topic (854643) XklWrapperError: Failed to remove layout 'us ()'
19:20:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=854643
19:20:52 <tflink> #info Proposed Blocker, MODIFIED
19:21:05 <tflink> kparal: as long as you haven't zombified :)
19:21:05 <adamw> damnit, must...stab...kparal...harder...
19:21:31 <tflink> "I'm not dead yet. I don't want to go in the cart"
19:21:38 <kparal> adamw: is it the next level of firing people?
19:21:38 <adamw> hehe
19:23:04 <adamw> this seems somewhat obscure
19:23:26 <tflink> since you have to remove a layout to hit it?
19:23:45 <adamw> it seems you have to do things in a very specific order
19:23:58 <adamw> remove the english layout before adding the new layout, then add the new layout in a particular way
19:24:18 <adamw> "It works most of the time, except today."
19:24:32 * kparal proposes nth
19:24:41 <adamw> yeah, nth seems right
19:24:47 <adamw> we have a fix already so no need to argue too hard
19:25:01 * adamw eyes golf clubs
19:25:32 <Viking-Ice> happy gilmore time?
19:26:00 <Viking-Ice> is not that the Canadian way hockey stick instead of golf clubs
19:26:12 <tflink> proposed #agreed 854643 - RejectedBlocker, AcceptedNTH - This seems a bit obscure to take as a blocker since you have to add and remove keyboard layouts in a specific order
19:26:15 <adamw> ack
19:26:16 <Viking-Ice> ack
19:26:37 <kparal> ack
19:26:42 <tflink> #agreed 854643 - RejectedBlocker, AcceptedNTH - This seems a bit obscure to take as a blocker since you have to add and remove keyboard layouts in a specific order
19:27:13 <tflink> #topic (855526) f18a tc6 anaconda cannot connect to a protected wireless network
19:27:16 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855526
19:27:18 <tflink> #info Proposed Blocker, NEW
19:27:25 <tflink> we still have 10 more proposed blockers to go :-/
19:28:17 <adamw> this feels dupe-y?
19:28:28 <tflink> didn't we hit this in F17
19:28:33 <adamw> well, maybe not
19:28:38 <tflink> where WPA2-enterprise didn't work when others did?
19:28:44 <adamw> don't ask me to remember F17.
19:28:50 <adamw> "My network uses WPA2 Personal, and it doesn't work with that"
19:28:52 <kparal> that was for a specific driver
19:28:57 <kparal> in F17
19:28:59 <kparal> I remember that
19:29:38 <adamw> oh, https://bugzilla.redhat.com/show_bug.cgi?id=856852 is a bit more familiar to me
19:29:48 <adamw> seems like this may be Intel wireless-specific, or possibly just wireless-specific
19:30:14 <Viking-Ice> intel or not what does the criteria say?
19:30:21 <tflink> 856852 was closed as a dupe of 855526
19:30:24 <adamw> it's a conditional breakage of network install
19:30:40 <adamw> tflink: right, just saying i remember reading the dupe
19:31:04 <Viking-Ice> in beta wireless network support in anaconda ought to be working from my pov
19:31:08 * kparal will be back in 10 minutes
19:31:15 <adamw> if the issue is actually "15:22:02,672 WARNING NetworkManager: <warn> No agents were available for this request.", then I'd say this is a conditional breakage of the network install criteria in the case of trying to install over a wireless network which has any kind of security.
19:31:19 <zodbot> Ticket notification - f18betanicetohave: [Bug 854643] XklWrapperError: Failed to remove layout 'us ()' <https://bugzilla.redhat.com/show_bug.cgi?id=854643>
19:31:48 <adamw> it kind of sounds like there's nothing for NM to pop up to ask for the authentication details.
19:32:07 <adamw> 15:22:02,660 INFO NetworkManager: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
19:32:07 <adamw> 15:22:02,668 INFO NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
19:32:07 <adamw> 15:22:02,672 WARNING NetworkManager: <warn> No agents were available for this request.
19:32:07 <adamw> 15:22:02,688 INFO NetworkManager: <info> (wlan0): device state change: need-auth -> failed (reason 'no-secrets') [60 120 7]
19:32:19 <adamw> it goes to need-auth, no agent is found, need-auth fails...
19:32:29 <Viking-Ice> do we have input from the anaconda team where the network spoke stands at this point?
19:32:51 <Viking-Ice> as in what is *supposed* to be working
19:33:17 <adamw> i don't think we have anything specific, but it's pretty much outsourced to NetworkManager
19:33:32 <adamw> i'm pretty sure WPA wireless is supposed to work
19:33:56 <adamw> we've only had support for wireless networking in installation since anaconda started using NM, really, but it seems like something that should work these days
19:34:18 <tflink> sounds like we're pretty +1 blocker on this?
19:34:29 <adamw> if we take the bug as 'any kind of wireless connection that needs auth isn't going to work', i'm +1.
19:34:31 <Viking-Ice> I'm +1 blocker on this
19:35:23 <tflink> proposed #agreed 855526 - AcceptedBlocker - Violates the following F18 alpha release criterion for wireless networks which require authentication: "
19:35:28 <tflink> once again ...
19:35:37 <tflink> proposed #agreed 855526 - AcceptedBlocker - Violates the following F18 alpha release criterion for wireless networks which require authentication: "The installer must be able to use at least one of the HTTP or FTP remote package source options"
19:35:48 <adamw> ack
19:36:05 <Viking-Ice> ack
19:36:44 * adamw stabs kparal
19:37:01 <tflink> adamw: I don't think that's going to help get him to ack
19:37:10 <adamw> it puts the ack in the channel!
19:37:27 <tflink> if it were a comic book, it might
19:37:32 <tflink> we need bill the cat
19:37:56 <tflink> #agreed 855526 - AcceptedBlocker - Violates the following F18 alpha release criterion for wireless networks which require authentication: "The installer must be able to use at least one of the HTTP or FTP remote package source options"
19:37:59 * adamw was adapting silence of the lambs, but never mind
19:38:02 <Viking-Ice> hm do we have an alpha release criteria for wireless network in anaconda, wired should suffice for alpha
19:38:25 <adamw> Viking-Ice: we don't have criteria for specific network methods, it just comes under the 'some cases break' thing where it's a subjective call
19:38:37 <adamw> we could make it explicit if we wanted to i guess
19:38:49 <tflink> or use the beta "all remote sources" criterion
19:39:24 <adamw> Viking-Ice: so for Alpha i'd have voted -1 on the basis that we don't reckon wireless is important enough for alpha, but same criterion
19:39:35 <Viking-Ice> I see
19:39:50 <Viking-Ice> in anycase let's move along we can punt that for later
19:39:56 <adamw> yup
19:40:15 <tflink> #topic (854959) Exception handling in Anaconda doesn't work if dump contains non-ascii characters
19:40:15 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=854959
19:40:15 <tflink> #info Proposed Blocker, POST
19:41:00 <tflink> still not sure this is a beta blocker
19:41:14 <tflink> I'd probably be +1 nth, though
19:41:15 <adamw> we rejected this for alpha
19:41:25 <Viking-Ice> agreed +1 nth
19:41:38 <adamw> yeah, probably -1/+1
19:41:44 * kparal is back just to realize he has been stabbed to death
19:41:46 <adamw> especially since it's already partly fixed
19:42:19 <Viking-Ice> kparal, and resurrected and stabbed again!
19:42:35 <kparal> +1nth
19:43:58 <tflink> proposed #agreed 854959 - RejectedBlocker, AcceptedNTH - This has been partially fixed already and doesn't clearly hit any of the alpha or beta release criteria - rejecting as blocker. It would be good to get all non-ascii crashdumps so accepted as NTH for F18 beta
19:44:08 <adamw> ack
19:44:13 <kparal> ack
19:44:40 <Viking-Ice> ack
19:44:44 <tflink> proposed #agreed 854959 - RejectedBlocker, AcceptedNTH - This has been partially fixed already and doesn't clearly hit any of the alpha or beta release criteria - rejecting as blocker. It would be good to get all non-ascii crashdumps so accepted as NTH for F18 beta
19:44:49 <tflink> #agreed 854959 - RejectedBlocker, AcceptedNTH - This has been partially fixed already and doesn't clearly hit any of the alpha or beta release criteria - rejecting as blocker. It would be good to get all non-ascii crashdumps so accepted as NTH for F18 beta
19:45:09 <tflink> #topic (859285) initrd is used in grub2 for efi system (initrdefi should be used)
19:45:12 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859285
19:45:15 <tflink> #info Proposed Blocker, NEW
19:45:58 <adamw> this seems pretty bad
19:46:05 <tflink> alpha 1?
19:46:14 <adamw> though it only affects updates
19:46:27 <adamw> some people seem convinced we number our pre-releases. i've no idea why.
19:46:28 <kparal> so you update -> boom ?
19:46:48 <tflink> therefore, can't be fixed with an update and a blocker ?
19:46:55 * tflink isn't being serious
19:47:26 <adamw> kparal: well, boom-ish - you can at least boot the previous kernel
19:47:27 <tflink> this does seem like a rather nasty problem, though
19:47:39 <adamw> in theory i think we could fix this with updates
19:47:50 <tflink> would be good to get some other reporters, though
19:47:51 <adamw> you'd have to ship a grubby update and make sure the kernel package required at least that version of grubby
19:47:51 <kparal> you would have to update in the correct order
19:47:56 <kparal> right
19:47:57 <adamw> so kernel didn't get updated with the old grubby
19:48:06 <zodbot> Ticket notification - f18betanicetohave: [Bug 854959] Exception handling in Anaconda doesn't work if dump contains non-ascii characters <https://bugzilla.redhat.com/show_bug.cgi?id=854959>
19:48:09 <adamw> tflink: i never upgraded any of my test efi installs
19:48:31 <adamw> i guess i'm -1 on the basis this issue affects updates only and can be handled properly through updates even though it's a bit sensitive
19:48:41 <kparal> however, shouldn't it concern F17 too?
19:48:48 <kparal> I don't have problem with kernel updates
19:48:49 <adamw> no, f17 used grub-efi not grub2
19:48:50 <tflink> me neither - I was going to update an EFI box from F17 yesterday but had a crappy network connection
19:48:54 <kparal> ah
19:48:59 <adamw> grub-efi has different syntax
19:49:07 <kparal> sounds like a blocker
19:49:22 <adamw> why isn't handling it in updates enough?
19:49:40 <Viking-Ice> blocker to me
19:49:40 <tflink> hopefully, it
19:49:47 <kparal> will it surely work?
19:49:59 <adamw> well i'm not god, but...
19:50:06 <adamw> i can't see how it wouldn't work
19:50:13 <tflink> wait, what?
19:50:32 <adamw> i suppose we could say the risk of it not being properly handled is too great
19:50:41 <tflink> while severe, it does fall into our "could be fixed with an update" category
19:51:02 <adamw> i guess it's almost like one of the 'special case' packages
19:51:04 <Viking-Ice> by beta kernel updates should just work flawlessly
19:51:05 <adamw> livecd-tools etc
19:51:12 <adamw> where we take it as a blocker but don't block the compose on it
19:51:26 <adamw> i.e., we say it has to be fixed up in the repos by ship time...
19:51:27 <Viking-Ice> pjones around for input?
19:51:41 <pjones> what's the question?
19:51:47 <pjones> I haven't been paying attention.
19:51:57 <tflink> adamw: if we're saying that it's too risky to fix w/ an update, shouldn't it be required to be on the compose?
19:52:36 <adamw> tflink: well the risk is more just that it simply doesn't get *done*
19:52:41 <adamw> not that the fix might not work if it was done
19:52:48 <tflink> ah, I see
19:52:50 <adamw> pjones: https://bugzilla.redhat.com/show_bug.cgi?id=859285
19:53:18 <adamw> tbh looking at the grubby changes mads linked i don't see how this isn't fixed
19:53:23 <adamw> maybe we should punt and test it ourselves
19:53:38 <tflink> we have only one reporter so far
19:53:40 <adamw> those changes sure look like grubby should handle initrdefi fine
19:53:47 <adamw> and punting gets us out of our roadblock :P
19:53:57 <tflink> one reporter on an issue that should only affect a minority of users
19:53:58 <pjones> I think the steps to recreate are probably wrong
19:54:21 <adamw> pjones: you're thinking he did the update with an old grubby?
19:54:30 <pjones> right now fresh installs should get linuxefi/initrdefi and updates from /those/ installs should get them, but /yum/ updates from f17 won't magically switch.
19:54:52 <adamw> he doesn't appear to be updating from f17
19:55:06 <adamw> okay, let's just punt and test this ourselves.
19:55:15 <tflink> proposed #agreed 859285 - We'd like to see more testing and more than one reporter before deciding on blocker status - will revisit when there is more data available
19:55:18 <adamw> ack
19:55:30 <pjones> adamw: Well, yes, that's why I said I think the steps to reproduce are wrong
19:55:42 <pjones> hrm.
19:55:47 <adamw> pjones: well, a yum upgrade from f17 should still be using grub-efi anyway, so should behave completely differently, right?
19:55:52 <adamw> i mean, it wouldn't look anything like this bug.
19:55:55 <pjones> Actually, let me check.  There's a chance grubby will do the wrong thing.
19:55:59 <adamw> ah, okay.
19:56:20 <adamw> brb, call of nature
19:56:43 * tflink requests more ACK
19:57:01 * Viking-Ice waiting for input from pjones check
19:57:25 * jreznik is back, Board meeting is over!
19:57:46 <kparal> ack
19:59:05 <pjones> Yeah, I can see how we could be writing out the wrong thing.
19:59:21 <Viking-Ice> nack + 1nth
20:00:10 <adamw> ah.
20:00:37 <tflink> I don't really see this as an NTH issue since it could be fixed w/ update
20:00:55 <tflink> either blocker or not
20:01:23 * adamw just doesn't care any more.
20:01:25 <adamw> :P
20:01:33 <adamw> everyone else vote and then i'll agree with the majority!
20:01:35 <pjones> the big hazard there is that it /must/ be fixed before the first kernel update.
20:01:35 <Viking-Ice> wont this affect "upgrades"
20:01:51 <kparal> +1 nth can't do any harm
20:01:55 <adamw> pjones: right, and to be double sure, we'd have to make the kernel depend on the fixed grubby so they don't get ordered wrong.
20:02:01 <tflink> and blocker?
20:02:02 <pjones> adamw: right
20:02:19 <adamw> seems like making it blocker is probably safest, really.
20:02:22 <pjones> Viking-Ice: upgrades need to be a special case already; right now unless you manually switch them over they'll keep grub-efi
20:02:23 <adamw> that way we make sure we don't stuff it up.
20:02:35 <kparal> what about "Hey, it's Beta!" argument? :)
20:02:36 <adamw> so i guess +1
20:02:40 <Viking-Ice> pjones, ok
20:02:48 <Viking-Ice> adamw, yup +1
20:03:44 <tflink> proposed #agreed 859285 - AcceptedBlocker - Violates the following F18 alpha criterion for kernel updates on UEFI systems - "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
20:03:47 <adamw> ack
20:03:51 <Viking-Ice> ack
20:03:52 <adamw> i'll explain the wrinkles in the comment
20:04:00 <kparal> ack
20:04:03 <pjones> I think I'll have a fix for this in a few minutes.
20:04:17 <tflink> #agreed 859285 - AcceptedBlocker - Violates the following F18 alpha criterion for kernel updates on UEFI systems - "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
20:04:34 <tflink> #topic (859460) gnome-shell fix for  polkit auth_admin authentication
20:04:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859460
20:04:34 <tflink> #info Proposed Blocker, NEW
20:05:09 <tflink> kparal: criteria for this one?
20:05:21 <kparal> update through packagekit
20:05:34 <kparal> without the fix the authentication shouldn't work
20:05:48 <tflink> ah, this isn't the RPM issue for certs?
20:05:56 <kparal> nope
20:06:20 <kparal> polkit was fixed to work for users outside wheel group
20:06:26 <kparal> but gnome-shell also needs a fix
20:06:36 <kparal> now it works just for yumex and stuff
20:06:44 <kparal> xfce etc
20:07:03 <kparal> packagekit uses gnome-shell auth dialogs
20:07:05 <kparal> that's this bug
20:07:05 <tflink> votes on blockery-ness? It sounds +1 to me
20:07:12 <kparal> +1 blocker
20:07:13 <adamw> so the case where you have to auth as root was still broken for a default GNOME config?
20:07:23 <adamw> borderline +1 (since default is to have an admin user)
20:07:26 <Viking-Ice> +1 blocker ( plus fix seem to be in updates-testing )
20:07:32 <kparal> adamw: I think it's broken just if your user is not in wheel group
20:07:52 <adamw> kparal: the commit message is specific about root.
20:07:53 <kparal> so yes, new installs should have now users in wheel group, that's good
20:07:59 <adamw> "If we're asking for root's password, we don't show an avatar"
20:08:19 <adamw> anyhow, sure, +1, move on.
20:08:26 <kparal> I'm not fully sure
20:08:31 <kparal> about the commit message
20:08:49 <kparal> I'm saying what I gathered from the reports
20:09:10 <tflink> proposed #agreed 859460 - AcceptedBlocker - Violates the following F18 alpha release criterion for users not in the wheel group on systems using gnome-shell "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
20:09:15 <kparal> ack
20:09:16 <adamw> ack
20:09:46 <Viking-Ice> ack
20:09:53 <tflink> #agreed 859460 - AcceptedBlocker - Violates the following F18 alpha release criterion for users not in the wheel group on systems using gnome-shell "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
20:09:58 <tflink> #topic (859632) Cannot edit boot entries
20:09:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859632
20:09:58 <tflink> #info Proposed Blocker, NEW
20:10:21 <tflink> isn't this the grub font bug?
20:10:37 <kparal> qxl bug I would say
20:11:10 <Viking-Ice> do we have any spesific vm criteria to cover this?
20:11:22 <jreznik> seems no to be font bug from screencast
20:11:31 <kparal> we already kinda dumped cirrus, grub editing should work at least for qxl then
20:11:32 <tflink> oh, that is different
20:11:48 <kparal> ah, different one?
20:11:49 <tflink> either way, it's not the same bug I've been seeing
20:12:02 <adamw> it does look a bit different
20:12:05 <kparal> it's true that qxl bug has an empty rectangle
20:12:08 <kparal> this one doesn't
20:12:11 <tflink> in the screencast, there is nothing in the menu - not just an empty box with big text around it
20:12:14 <Viking-Ice> I saw a different with in alpha and kvm
20:12:22 <adamw> but we don't have a grub build with the font fix yet
20:12:27 <adamw> so it could still be the same cause i guess
20:12:59 <adamw> why didn't the rest of us see this though? seems a bit strange
20:13:01 <kparal> I think we need more data. how installed - clean or upgrade?
20:13:02 <adamw> maybe needs more info?
20:13:03 <adamw> yeah
20:13:08 <kparal> which driver
20:13:11 <kparal> etc
20:13:12 <Viking-Ice> yup
20:13:59 <tflink> proposed #agreed 859632 - This could possibly be another symptom of 850783 but more details are needed before we decide on blocker status (graphics driver, installation method, versions etc.)
20:14:03 <adamw> ack
20:14:10 <Viking-Ice> ack
20:14:11 <jreznik> ack
20:14:24 <tflink> #agreed 859632 - This could possibly be another symptom of 850783 but more details are needed before we decide on blocker status (graphics driver, installation method, versions etc.)
20:14:36 <tflink> #topic (856362) KeyError: 'la-latin1'
20:14:36 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856362
20:14:36 <tflink> #info Proposed Blocker, NEW
20:15:16 <kparal> upgrade bug?
20:15:20 <Viking-Ice> yup
20:15:34 <adamw> "But this is a more general problem of using console keymap in kickstart because internally, we now use X layouts."
20:15:48 <adamw> sounds like the issue here is that if you specify a console keymap in a kickstart it'll bork
20:15:51 <adamw> preupgrade was doing that
20:16:03 <adamw> i think i'm a bit -1 on this
20:16:28 <adamw> preupgrade would be the important case but we know the current incarnation of preupgrade is dead wrt f18
20:16:49 <tflink> wait, aren't we skipping all upgrade and partitioning related bugs for now?
20:16:53 <adamw> i don't think we gain anything wrt the whole upgrade question by having this bug open, is i guess how i'd phrase it
20:16:55 <kparal> tflink: +1
20:17:00 <adamw> tflink: well this isn't strictly an upgrade bug really
20:17:08 <adamw> it's a kickstart bug
20:17:12 <adamw> just that preupgrade happens to use kickstarts
20:17:29 <kparal> but still it must not blow up
20:17:39 <Viking-Ice> if it's a kickstart bug it must hit some criteria for beta
20:17:47 <adamw> given that we're going to have a whole new upgrade tool, the preupgrade case becomes irrelevant, it's just a 'if you do this in a kickstart it'll fail' bug
20:17:49 <kparal> but we don't know how preupgrade criteria will look like in Beta
20:18:03 <adamw> kparal: we don't know if the new tool will use kickstarts. or anaconda.
20:18:10 <tflink> assuming that the "new" tool doesn't use kickstarts
20:18:11 <kparal> so skip
20:18:17 <adamw> i'd say 'so reject'.
20:18:40 <kparal> but maybe, just maybe, preupgrade will stay, and upgrade criterion will stay in Beta
20:18:41 <tflink> adamw: even though the mythical new tool could just be a modified preupgrade?
20:18:42 <adamw> the chances of whatever our new upgrade system turns out to be hitting this bug are so minuscule as to not bother worrying about.
20:18:45 <Viking-Ice> does network install only cover gui?
20:18:46 <kparal> then this would be a valid blocker
20:18:55 <adamw> eh, i guess.
20:19:04 <adamw> Viking-Ice: oh, you missed the kickstart discussion earlier, right
20:19:07 <tflink> adamw: how so, wwoods said that the new tool could be based off of preupgrade
20:19:10 <adamw> Viking-Ice: we only have very minimal criteria for kickstart atm
20:19:17 <tflink> unless there has been another upgrade discussion I missed
20:19:18 <adamw> tflink: i guess.
20:19:45 <adamw> we can consider the simple case of 'i wrote a kickstart with a console keymap id in it', though.
20:19:48 * tflink loves unicorn hunting
20:19:54 <adamw> if we reckon that's a blocker then this bug is a blocker, regardless of the upgrade case.
20:20:02 * kparal is still for punt, until we know more
20:20:10 <tflink> we have no idea what the unicorn looks like but we've been told it exists and will appear in time
20:20:24 <adamw> so to recap from earlier, this doesn't hit our current kickstart criterion, but the idea is that we evaluate kickstart bugs as they come up to see if we want to add them to the criteria
20:20:44 <Viking-Ice> dam I was hoping for a leprechaun with a pot of gold
20:21:33 <adamw> purely from the kickstart perspective i wouldn't want to add a criterion for 'specifying a console keymap must work' if anaconda is now expecting an X keymap - it'd be nice to translate, but i don't think blocker-worthy. so that would be a vote to punt until we can consider the upgrade case.
20:21:43 <Viking-Ice> let's just put this one on ice for now we can always revisit it later when we know a bit more
20:22:15 <adamw> sounds like three votes for punt
20:23:06 <tflink> proposed #agreed 856362 - As the upgrade situation for F18 is still unknown, this may or may not be a blocker-worthy issue. Will revisit once we have more information on how upgrades to F18 will work
20:23:14 <Viking-Ice> ack
20:23:14 * tflink prefers http://www.thinkgeek.com/product/e5a7/
20:23:36 <kparal> ack
20:23:37 <tflink> other ack/nak/patch?
20:24:31 <adamw> good enough
20:24:40 <tflink> #agreed 856362 - As the upgrade situation for F18 is still unknown, this may or may not be a blocker-worthy issue. Will revisit once we have more information on how upgrades to F18 will work
20:24:44 <tflink> #topic (859855) AttributeError: 'NoneType' object has no attribute 'name'
20:24:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859855
20:24:44 <tflink> #info Proposed Blocker, NEW
20:24:54 <tflink> 4 blockers left
20:25:28 <kparal> upgrade issue
20:25:31 <kparal> skip?
20:25:39 <adamw> upgrade, skip
20:26:08 <tflink> proposed #agreed 859855 - As the upgrade tool situation for F18 is still unknown, this may or may not be a blocker-worthy bug. Will revisit once we have more information on how upgrades to F18 will work.
20:26:15 <kparal> ack
20:27:32 <tflink> #agreed 859855 - As the upgrade tool situation for F18 is still unknown, this may or may not be a blocker-worthy bug. Will revisit once we have more information on how upgrades to F18 will work.
20:27:42 <tflink> #topic (858591) anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8
20:27:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=858591
20:27:46 <youlysses> Is thee an eta when GNOME3.6 will make it into the Alpha?
20:27:47 <tflink> #info Proposed Blocker, NEW
20:28:00 <adamw> youlysses: it's already in updates-testing.
20:28:26 <youlysses> adamw: Oh wow! Thanks for the info.
20:28:36 <adamw> this looks like final blocker to me
20:28:40 <adamw> +1 nth
20:28:57 <adamw> "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use " from final
20:29:52 <tflink> translations != invalid locale, though
20:29:56 <kparal> there are other hiccups related
20:30:13 <kparal> I have seen a problem with PackageKit asking me to install more fonts every 10 seconds
20:30:15 <adamw> tflink: well, the basic effect of an invalid locale is you don't see translations, right?
20:30:16 <adamw> ah
20:30:19 <kparal> because I had invalid locale
20:30:27 <tflink> adamw: and can't type properly
20:30:28 <kparal> but that was a custom PackageKit from hughsie
20:31:00 <adamw> tflink: keyboard layout isn't defined by locale setting, i don't think.
20:31:11 <kparal> nope
20:31:21 <tflink> so it's just display of translations?
20:31:25 <adamw> i can switch to Japanese input now if i want to, without changing locale.
20:31:49 <kparal> locale influences translations, date formatting, monatery signs and similar stuff
20:31:52 <adamw> tflink: and possibly other wrinkles, but i'd want to know specifics before +1ing on that
20:32:06 <adamw> right, none of those is terribly blocker-ish
20:32:27 <adamw> it's possible having a completely invalid locale specified could cause something we don't know about yet to barf, but we'd need specific data on that.
20:32:54 <kparal> yes. seems like nth to me
20:33:08 <adamw> we could ack it as final blocker, since it seems pretty clear.
20:33:12 <kparal> yes
20:33:16 <kparal> we can do that right now
20:33:40 <adamw> propose away, maestro
20:33:52 <kparal> beta nth, final blocker
20:34:17 <tflink> proposed #agreed 858591 - RejectedBlocker (Beta), AcceptedNTH (Beta), AcceptedBlocker (final) - While this does hit the F18 final release criterion "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use", it doesn't hit any beta criteria and is rejected as a blocker for beta. Accepted as NTH for beta due to nastiness. Accepted as a final blocker due to violation
20:34:32 <kparal> ack
20:35:18 <adamw> ack
20:35:37 <tflink> #agreed 858591 - RejectedBlocker (Beta), AcceptedNTH (Beta), AcceptedBlocker (final) - While this does hit the F18 final release criterion "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use", it doesn't hit any beta criteria and is rejected as a blocker for beta. Accepted as NTH for beta due to nastiness. Accepted as a final blocker due to violation of previo
20:35:50 <tflink> #topic (860430) RFE: dual boot support in newui
20:35:50 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=860430
20:35:50 <tflink> #info Proposed Blocker, NEW
20:36:01 <Viking-Ice> ack
20:36:03 <tflink> I think this might have been mis-proposed for beta
20:36:50 <adamw> nope. i did it on purpose.
20:36:55 <adamw> the description is slightly misleading.
20:36:58 <tflink> yeah, I see that now
20:37:01 <adamw> it's really the bug for 'we need bootloader location selection'.
20:37:21 <adamw> i couldn't totally recall the myriad messy cases we found in f16 when you couldn't select the bootloader location, but i'm pretty sure we had it blocking beta.
20:37:36 <adamw> sorry i didn't come up with a better proposal yet :/
20:37:38 <adamw> we could punt it.
20:37:44 <Viking-Ice> yeah let's punt it
20:38:02 <jreznik_n9> punt it
20:38:43 <zodbot> Ticket notification - f18betanicetohave: [Bug 858591] anaconda setting invalid system locale xx.UTF-8 not xx_YY.UTF-8 <https://bugzilla.redhat.com/show_bug.cgi?id=858591>
20:39:07 <kparal> I am ok with +1 blocker, but surely we can punt
20:39:11 <tflink> proposed #agreed 860431 - While the name suggests that this is just a dual-booting issue, there have been issues in the past where we have seen issues when unable to select the bootloader location. Will revisit once there has been more chance to find the specific problems from F16
20:39:24 <adamw> ack
20:39:27 <kparal> ack
20:39:31 <jreznik_n9> ack
20:39:39 <tflink> #agreed 860431 - While the name suggests that this is just a dual-booting issue, there have been issues in the past where we have seen issues when unable to select the bootloader location. Will revisit once there has been more chance to find the specific problems from F16
20:39:49 <tflink> #topic (860276) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 10: ordinal not in range(128)
20:39:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=860276
20:39:55 <tflink> #info Proposed Blocker, NEW
20:40:29 <kparal> see https://bugzilla.redhat.com/attachment.cgi?id=617024
20:40:32 <tflink> would have been ice to get more data
20:40:38 <adamw> martix?
20:40:45 <kparal> it seems to be related to password field
20:40:47 <tflink> but I assume that this happens when a user is created with non-ascii chars
20:40:48 <adamw> oh, he's gone
20:40:51 <adamw> punt for data i guess
20:40:52 <Viking-Ice> ack
20:41:00 <kparal> yes, require more data
20:41:05 <jreznik_n9> agree
20:41:26 <tflink> actually, it looks like a translation issue with the password strength messages
20:41:35 <tflink> but I'm ok with punting
20:42:10 <kparal> are we done for today?
20:42:26 <tflink> proposed #agreed 860276 - There is very little data on how often this happens and when it happens. Will revisit once there is more data on this bug
20:42:35 <tflink> unless we want to go through the proposed NTH
20:42:38 <kparal> ack
20:42:44 <jreznik_n9> kparal, nth?
20:42:58 <tflink> kparal: ack to the proposal or going through the proposed NTH?
20:43:00 <tflink> :-D
20:43:06 <kparal> ack to the proposal
20:43:19 <adamw> ack to the proposal
20:43:23 <adamw> nack to going through nth :P
20:43:32 <adamw> nth doesn't matter till freeze reaally anyhow
20:43:38 <jreznik_n9> acknack
20:43:49 <tflink> jreznik_n9: huh?
20:43:53 <kparal> it does matter a bit, it helps developers to focus on accepted bugs
20:44:02 <kparal> but I think we had enough today
20:44:07 <tflink> but at almost 5 hours already ...
20:44:19 <tflink> seriously, someone else ack the proposal
20:44:28 <kparal> tflink: you can ack too
20:44:35 <jreznik_n9> tflink, typing from phone, trying to be super short, ack for proposal, nack for nth
20:44:36 <tflink> I usually ignore myself since I wrote it
20:44:42 <tflink> jreznik_n9: ok
20:44:55 <tflink> #agreed 860276 - There is very little data on how often this happens and when it happens. Will revisit once there is more data on this bug
20:45:11 <tflink> it sounds like nobody is itching to go through the 6 proposed NTH today
20:45:17 <tflink> so ...
20:45:19 <jreznik_n9> quite late, waiting for latest tram...
20:45:25 <tflink> #topic Open Floor
20:45:36 <tflink> Anything I missed or that someone wants to bring up?
20:45:54 <tflink> other than sources unicorn meat?
20:46:26 <jreznik_n9> btw. good job leading five hours meeting!
20:46:44 <tflink> oh, we've had worse :(
20:46:48 * tflink shudders at the thought
20:47:22 <kparal> it'd be easy to fill in the day status report if we had one -> blocker bug meeting :-)
20:47:58 <tflink> kparal: depends on if you're working more than 8 hours in a day, I suppose
20:48:23 <tflink> anywho, it sounds like nothing else ...
20:48:23 <adamw> kparal: you mean you did nothing the other 3 hours?
20:48:30 * adamw fires kparal on his way to the golf course
20:48:30 <kparal> yeah, that's true, I would have to fill two reports today
20:49:09 <tflink> #info next F18 beta blocker review meeting will be 2012-10-3 @ 16:00 UTC
20:49:22 <jreznik_n9> it's openarena, sorry red hat week ;-)
20:50:02 <kparal> jreznik_n9: sssh, don't tell our team leader
20:50:17 <kparal> it's X test week as well, you know
20:50:37 * tflink sets fuse for [0,infinite] minutes, looks for his unicorn call
20:50:56 <jreznik_n9> kparal, yep, you test X using oa ;-)
20:51:00 * finalzone wishes Add/Remove Software features an undo installation based on yum history undo last or something...
20:51:22 * tflink will send out minutes shortly
20:51:33 <tflink> Thanks for coming and enduring the epic meeting, everyone!
20:51:36 <tflink> #endmeeting