16:01:40 <tflink> #startmeeting f19alpha-blocker-review-4
16:01:40 <zodbot> Meeting started Wed Apr  3 16:01:40 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:40 <tflink> #meetingname f19alpha-blocker-review-4
16:01:40 <tflink> #topic Roll Call
16:01:40 <zodbot> The meeting name has been set to 'f19alpha-blocker-review-4'
16:01:52 <kparal> eeeeehw
16:02:03 <tflink> Who's ready for some blocker review awesomeness?
16:02:11 <tflink> kparal: that was a rapid change
16:02:21 <tflink> #chair adamw kparal
16:02:21 <zodbot> Current chairs: adamw kparal tflink
16:02:23 <jreznik> wheee means ready? or eeeehw?
16:02:42 * brunowolff is here
16:03:12 <kparal> jreznik: https://www.youtube.com/watch?v=VBLHsh_4z_8
16:03:53 <adamw> morning!
16:04:33 <jreznik> morning adamw!
16:05:06 <tflink> jreznik: he did a 180 degree turn and now everything is backwards
16:05:13 <tflink> or running away from the fun
16:05:28 * satellit_e listening
16:06:50 <tflink> I think we have enough people - let's get this party started
16:06:55 <adamw> he's running towards the meeting so fast we heard him backwards
16:07:04 <adamw> http://www.what-if.xkcd.com/37/
16:07:14 <tflink> any volunteers for secretary duty?
16:07:19 <adamw> sure
16:07:47 <tflink> adamw: thanks
16:07:54 <tflink> #topic Introduction
16:07:59 <tflink> Why are we here?
16:07:59 <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:08:06 * nirik is lurking.
16:08:07 <tflink> #info We'll be following the process outlined at:
16:08:07 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:13 <tflink> #info The bugs up for review today are available at:
16:08:13 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:21 <tflink> #info The criteria for release blocking bugs can be found at:
16:08:21 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
16:08:42 <tflink> info Up for review today, we have:
16:08:50 <tflink> #info Up for review today, we have:
16:08:58 <tflink> #info 12 Proposed Blockers
16:08:58 <tflink> #info 8 Accepted Blockers
16:08:58 <tflink> #info 1 Proposed Freeze Exceptions
16:08:58 <tflink> #info 2 Accepted Freeze Exceptions
16:09:15 <tflink> any objections to starting with the proposed blockers?
16:09:42 <jreznik> go on
16:10:10 <tflink> #topic (928287) anaconda crashing to black screen at end of Fedora 19 Alpha install
16:10:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=928287
16:10:15 <tflink> #info Proposed Blocker, anaconda, POST
16:10:55 <kparal> +1 blocker, I hit it twice today out of two attempts
16:11:19 <adamw> seems like enough people are hitting this for it to be +1
16:11:29 <jreznik> +1, saw it too
16:13:30 <tflink> yeah, I've seen this as well. figured it was a return of the "can't wake up if display sleeps" thing that I had seen in F18
16:14:09 <akshayvyas> +1 here
16:14:40 <tflink> thoughts on criterion?
16:14:53 <akshayvyas> same with live cd so +1
16:15:18 <tflink> "A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account." ?
16:15:27 <jreznik> yep
16:15:47 <kparal> it's not really installed, but whatever. we don't have a generic 'must install' criterion
16:15:59 <adamw> there's a sub-para about 'showstoppers' in there
16:16:09 <kparal> maybe even "The installer must run when launched normally from the release-blocking images. " can be used
16:16:14 <adamw> "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces. "
16:16:23 <adamw> sub-para reads "This criterion covers showstopper bugs in the installer for which there isn't any other specific criterion: obviously, it can't 'complete an installation' if there's a showstopper."
16:16:42 <adamw> just remember to 'search for showstopper' to find it
16:17:06 <tflink> proposed #agreed 928287 - AcceptedBlocker - Violates the following F19 alpha release criteria: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
16:17:10 <adamw> ack
16:17:11 <jreznik> ack
16:17:14 <kparal> ack
16:17:15 <brunowolff> ack
16:17:25 <akshayvyas> ack
16:17:42 <tflink> #agreed 928287 - AcceptedBlocker - Violates the following F19 alpha release criteria: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
16:17:52 <tflink> #topic (929373) No Swap Install of some DE {Gnome , XFCE } in arch x8664 fails at package xml-common
16:17:55 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=929373
16:17:58 <tflink> #info Proposed Blocker, anaconda, NEW
16:18:19 * tflink makes mental note to fix the sort order mismatch between the irc buglist and the web front end
16:18:55 * jreznik will be back in a sec...
16:19:15 <kparal> so this is probably OOM crash
16:19:22 <kparal> but anaconda doesn't warn about missing swap
16:19:38 <kparal> (and it should also warn about low memory AND no swap)
16:19:54 <tflink> proposed #agreed flog people who propose blockers w/o listed criteria and should know better
16:20:27 <brunowolff> -1 blocker
16:20:28 <adamw> yeah, OOM's the obvious guess.
16:20:49 <adamw> -1 blocker
16:20:55 <adamw> +1 flogging
16:21:37 <akshayvyas> well not sure....i am installing xfce now ...lets see....for now +/-1
16:21:39 <brunowolff> I'm slightly -1 FE given this is anaconda.
16:22:47 <tflink> proposed #agreed 929373 - RejectedBlocker - While not ideal, this is a bit on the self-inflicted side to be considered a release blocking bug (low memory, no swap). A warning @ install time would be nice but not required
16:23:05 <brunowolff> ack
16:23:06 * satellit_e FYI I use no swap ext4 for USB installs
16:23:10 <kparal> well I'm -1 for Alpha, but I'd definitely recommend to propose it for Final
16:23:42 <kparal> hell, we should do that ourselves, instead of asking the reporter to do it
16:24:00 <adamw> ack
16:24:02 <kparal> so -1 Alpha, but move the proposal to Final
16:24:04 <jreznik> -1 for alpha, but nice to have (don't beat me for using the that nth term), I mean it how I mean it :)
16:24:19 <adamw> i'd be -1 FE for alpha
16:24:34 <adamw> but re-propose for final seems reasonable. i'll let kparal do that. with a criterion ;)
16:25:01 <tflink> proposed #agreed people who propose blockers without criteria violations when they should know better or use NTH terminology now that we've done away with it should be flogged
16:25:05 <tflink> :)
16:25:17 <brunowolff> As a blocker or FE? It seems like it would be FE for final via the not fixable in an update reason.
16:25:54 <tflink> proposed #agreed 929373 - RejectedBlocker - While not ideal, this is a bit on the self-inflicted side to be considered a release blocking bug (low memory, no swap). A warning @ install time would be nice but not required for alpha. Re-propose as blocker for F19 final.
16:25:57 <jreznik> brunowolff: more FE I'd say
16:26:10 <tflink> proposed #agreed 929373 - RejectedBlocker - While not ideal, this is a bit on the self-inflicted side to be considered a release blocking bug (low memory, no swap). A warning @ install time would be nice but not required for alpha. Re-propose as FE for F19 final.
16:26:19 <kparal> I meant Final blocker
16:26:20 <brunowolff> ack
16:26:20 <jreznik> and it leads us back to the discussion about minimal system requirements...
16:26:41 <kparal> I'll draft that criterion if needed
16:26:41 <tflink> are we thinking more FE or blocker for final?
16:26:47 <brunowolff> What we be the final blocker criteria?
16:27:13 <brunowolff> Not issuing a warning message doesn't jump at me and shout blocker.
16:27:25 <jreznik> brunowolff: yep
16:27:37 <tflink> yeah, this seems a bit self-inflicted to be a blocker
16:27:53 <adamw> we can argue about that bridge when we crash into it
16:28:17 <tflink> ack/nak/patch?
16:28:39 <brunowolff> ack (repeated for clarity)
16:29:39 <adamw> ack with moustache
16:30:16 <kparal> ack
16:30:46 <tflink> #agreed 929373 - RejectedBlocker - While not ideal, this is a bit on the self-inflicted side to be considered a release blocking bug (low memory, no swap). A warning @ install time would be nice but not required for alpha. Re-propose as FE for F19 final.
16:30:56 <tflink> #topic (947261) AttributeError: 'module' object has no attribute 'memInstalled' (anaconda fails to boot with 512mb ram in TEXT MODE)
16:30:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=947261
16:31:01 <tflink> #info Proposed Blocker, anaconda, NEW
16:31:17 <tflink> again, apologies about the sort order mismatch - it seems worse than usual today
16:32:04 <tflink> thi
16:32:17 <tflink> this sounds like "text mode doesn't work with 512m ram"
16:32:34 <adamw> yeah, probably -1 for alpha
16:32:34 <tflink> -1 blocker unless I'm missing something
16:32:35 <jreznik> no, I'd say it will fail because of the check of enough ram
16:32:46 <akshayvyas> -1 blocker
16:32:51 <adamw> yeah, it might be something like 'the RAM check causes an ugly crash in text mode' or something
16:32:52 <jreznik> or there's no proof it will work with 512+
16:32:56 <adamw> but even that still doesn't sound blockery.
16:33:01 <kparal> > 00:28:06,062 INFO anaconda: check_memory(): total:512, needed:512, graphical:512
16:33:28 <adamw> pyanaconda/isys/__init__.py if someone wants to go poking the innards.
16:33:35 <tflink> yeah, that makes more of a differnce since it isn't doing the warning properly but I still think not alpha blocker
16:33:41 <tflink> FE?
16:33:45 <adamw> hm
16:33:58 <jreznik> text mode criteria?
16:34:00 <adamw> can i just take a few mins to verify this one is actually to do with the amount of ram?
16:34:09 <tflink> i suppose it depends on what the anaconda folks think about it
16:34:10 <jreznik> adamw: yes, please
16:34:23 * jreznik can't try it, my virt-manager got crazy :(
16:34:52 <kparal> I just booted with 2GB RAM, text mode boots
16:35:02 <brunowolff> If it works with more memory, -1 alpha blocker. It'd be easy to document limitation.
16:35:04 <adamw> i tried graphical mode 512MB and got the same thing
16:35:13 <adamw> i think this is the RAM checker causing a crash not a nice error message
16:35:17 <akshayvyas> i booted with 1 gig :)..it worked
16:35:32 <tflink> yeah, sounds like an issue with the error message
16:35:33 <jreznik> if it is really working with 512+, -1 Alpha blocker
16:35:36 <adamw> let me try a few more combinations
16:37:19 * adamw tests 384
16:37:35 <adamw> heh, 384 causes a kernel trace.
16:37:50 <adamw> anyway, 768MB gets to the first screen with text and graphical, so -1.
16:38:01 <jreznik> thanks
16:38:34 <jreznik> seems really to be in error message
16:38:49 <adamw> the only odd part is that text should succeed with 512, not fail
16:38:50 <adamw> but eh
16:40:04 <tflink> proposed #agreed 946261 - RejectedBlocker - This appears to be an issue with the error message that should show up when there is insufficient memory to do the install and thus, is not a release blocking issue for F19 alpha
16:40:24 <kparal> FE?
16:40:27 <tflink> actually, that code makes me think that the install would have started if it wasn't for the warning
16:40:32 <adamw> ack
16:40:37 <akshayvyas> ack
16:40:47 <adamw> tflink: the text one probably would start, but i'll bet dollars to donuts it won't finish
16:40:47 <tflink> the error message says that it doesn't have enough memory for VNC
16:40:52 <adamw> ah
16:41:09 <kparal> ack
16:41:10 <tflink> it doesn't say that there isn't enough memory to do the install
16:41:18 <adamw> oh yeah, it's a VNC check...
16:41:36 <adamw> so that's a bit worse. still, afaict the only really bad case is 512MB, text
16:41:41 <adamw> and i rather suspect that'd fail anyhow
16:41:55 <brunowolff> ack
16:42:14 <tflink> thoughts on FE?
16:42:50 <adamw> it kinda depends if the install would succeed anyway...not sure if we can test that easily
16:42:54 <adamw> well, an updates.img to fix the bug, i guess
16:43:09 <kparal> let's include "Developers, please propose for FreezeException if you want to have this fixed in Alpha"
16:43:12 <adamw> i'd say i'd be +1 FE if we can actually demonstrate a successful install of Alpha with 512MB?
16:43:17 <adamw> kparal: reasonable
16:43:26 <kparal> sure, it's my idea
16:43:33 <kparal> :P
16:43:46 <brunowolff> I think -1 FE. I don't think we need that particular case to get extensive testing. People can either use more memory or a graphical install instead.
16:44:20 <brunowolff> I'd be inclined to go with a final blocker though.
16:44:45 <adamw> let's just go with kparal's idea
16:44:54 <tflink> proposed #agreed 946261 - RejectedBlocker - This appears to be an issue with the error message that should show up when there is insufficient memory to do the install and thus, is not a release blocking issue for F19 alpha. Would consider FE if developers are interested in fixing for F19 alpha
16:45:00 <adamw> ack
16:45:04 <akshayvyas> ack
16:45:05 <adamw> er, nack
16:45:06 <brunowolff> ack
16:45:17 <tflink> adamw: patch?
16:45:21 <adamw> the text doesn't reflect your discovery that this is to do with the VNC memory check, not the installer's check
16:47:31 <adamw> proposed #agreed 946261 - RejectedBlocker - This this only has a really bad effect on the case of 512MB RAM text installs, all other configs which would pass the anaconda memory check work, and thus, is not a release blocking issue for F19 alpha. Would consider FE if developers are interested in fixing for F19 alpha
16:47:39 <tflink> #agreed 946261 - RejectedBlocker - This appears to be an issue with the "not enough memory for VNC install" interfering with a text install which was not intending to use VNC. While not severe enough to be considered as a release blocking issue for F19 alpha, it would be considered for FE if developers are interested in fixing for F19 alpha
16:47:45 <tflink> #undo
16:47:45 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x282b95d0>
16:48:17 <tflink> that was supposed to have proposed on it and I like adam's version better anyways
16:48:26 <tflink> ack (adamw's version)
16:48:40 <kparal> ack
16:48:54 <akshayvyas> ack
16:49:24 <jreznik> ack
16:49:34 <tflink> adamw: you're chair and it's easier for you to do the #agreed
16:49:45 * tflink is lazy :)
16:50:32 <adamw> #agreed 946261 - RejectedBlocker - This this only has a really bad effect on the case of 512MB RAM text installs, all other configs which would pass the anaconda memory check work, and thus, is not a release blocking issue for F19 alpha. Would consider FE if developers are interested in fixing for F19 alpha
16:50:43 <tflink> #topic (927922) root account accessible without password when administrator user is created but no root passwd set
16:50:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=927922
16:50:48 <tflink> #info Proposed Blocker, anaconda, NEW
16:52:14 <brunowolff> Shipping in this state seems irresponsible. +1 alpha blocker.
16:52:42 <kparal> I'm quite the opposite opinion, I think bugs like these don't really matter for Alpha and Beta, just Final
16:53:33 <adamw> alpha isn't ever meant to be deployed on any kind of production environment, yeah.
16:54:15 <brunowolff> Even if it is deployed in  test environment, being able to login as root without a password seems problematic. Are root ssh logins disabled by default?
16:54:27 <tflink> I don't think so
16:54:41 <adamw> brunowolff: 'seems problematic' is a handwave. how is it problematic exactly?
16:54:57 <kparal> brunowolff: you can't log in over ssh if you don't have a password
16:55:10 <adamw> that's true (try it in a vm)
16:55:17 <kparal> (unless of course you use a public certificate)
16:55:23 <brunowolff> That was the case I was most worried about.
16:56:11 <brunowolff> Problems from local users isn't that big of a deal for test environments where you expect to have only trusted people playing with stuff.
16:56:42 <adamw> why would you let untrusted people have access to your test environment? that doesn't seem like a thing. and even if you did, why would you care if they blow up your test environment? it's a test environment...
16:56:44 <jreznik> so seems we are more -1 blocker in this case, and repropose for final if not fixed
16:56:50 <adamw> and you still have to explicitly choose not to set a password.
16:56:51 <tflink> sounds like we're mostly -1, then?
16:57:08 <brunowolff> Yeah, you convinced me.
16:57:11 <adamw> yeah, i'm still -1
16:57:15 <akshayvyas> yeah -1 for alpha but +1 for final
16:57:25 <kparal> -1, but please repropose for Final right away
16:57:42 <kparal> as part of the secretary work
16:58:06 <tflink> proposed #agreed 927922 - RejectedBlocker - While this is an issue, issues with root logins on a local machine don't seem severe enough to be release-blocking at alpha since root ssh logins would not be allowed. If this is not fixed by final, please re-propose as final blocker
16:58:19 <adamw> FE?
16:58:19 <brunowolff> ack
16:58:19 <jreznik> ack
16:58:21 <akshayvyas> ack
16:58:23 <adamw> i'd be +1 FE
16:58:36 <adamw> and we are frozen now, so it matters
16:58:36 <brunowolff> +1 FE
16:58:37 <jreznik> sure, +1 FE
16:58:58 <kparal> I'd use my phrase again, same as last time
16:59:40 <tflink> proposed #agreed 927922 - RejectedBlocker - While this is an issue, issues with root logins on a local machine don't seem severe enough to be release-blocking at alpha since root ssh logins would not be allowed. If this is not fixed by final, please re-propose as final blocker. If developers are interested in fixing this for F19 alpha, please propose as FE.
16:59:50 <kparal> ack
17:00:28 <akshayvyas> ack
17:00:40 <brunowolff> ack
17:00:51 <adamw> um
17:00:52 <tflink> #agreed 927922 - RejectedBlocker - While this is an issue, issues with root logins on a local machine don't seem severe enough to be release-blocking at alpha since root ssh logins would not be allowed. If this is not fixed by final, please re-propose as final blocker. If developers are interested in fixing this for F19 alpha, please propose as FE.
17:00:56 <adamw> doesn't that create a roadblock?
17:01:06 <adamw> they write a fix tomorrow and propose it as FE, when does it get voted on? next week?
17:01:25 <kparal> yes, that's a problem we need to fix somehow
17:01:27 <adamw> i don't like this kparal's-new-FE-process-by-the-back-door idea, though nice submarine attempt, kparal ;)
17:01:51 * tflink is OK with FE on this
17:01:52 <adamw> i proposed it as an FE above, effectively. it got a bunch of +1 votes. a #agreed that says 'propose it as an FE if you write a fix' is a horse of a different color.
17:01:56 <kparal> adamw: haven't we voted in bugzilla for FEs in the past?
17:02:02 <kparal> when we required quick resolution?
17:02:17 <adamw> well we've voted in bz for various things, but it's a workaround that some people don't like, so we shouldn't just use it all the time
17:02:19 <tflink> bugzilla voting is a bad idea that I don't want to encourage more of
17:02:56 <tflink> other thoughts on FE?
17:02:59 <kparal> in that case we either need to vote on everything in advance, or do the meetings more often
17:03:13 <kparal> or find a third way
17:04:04 <adamw> voting on FE proposals as they come up is what we've always done before. it's not like it's some kind of radical departue.
17:04:15 <adamw> it'd be making them all 'propose as FE when you've written the fix' that'd be a departure.
17:04:22 * kparal agrees
17:04:49 <kparal> ('or before you have written the fix')
17:05:20 <kparal> so let's just vote on FEs
17:05:32 <tflink> are there enough +1 FEs to undo the agreed?
17:05:32 <kparal> I'm +1 FE as well here
17:05:44 <kparal> yes
17:06:11 <jreznik> +1 FE
17:06:21 <tflink> #undo
17:06:21 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x2af3e690>
17:06:40 <adamw> implied +1 from me as the proposer
17:06:42 <brunowolff> +1 FE
17:07:26 <tflink> #agreed 927922 - RejectedBlocker AcceptedFreezeException - While this is an issue, issues with root logins on a local machine don't seem severe enough to be release-blocking at alpha since root ssh logins would not be allowed. However, a tested fix would be considered for pulling during Freeze. If this is not fixed by final, please re-propose as final blocker.
17:08:19 <tflink> bah, forgot the proposed
17:08:25 <adamw> good enough
17:08:28 * tflink can undo if needed
17:09:14 <jreznik> no need to to undo
17:09:38 <tflink> #topic (928279) anaconda doesn't start on LiveCD (in Gnome)
17:09:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=928279
17:09:38 <tflink> #info Proposed Blocker, anaconda, NEW
17:10:39 <kparal> I saw this on probably every bare metal I tried
17:10:47 <akshayvyas> well i installed gnome an ryt now installing xfce with live iso...it works for me
17:10:58 <kparal> akshayvyas: bare metal?
17:11:06 <akshayvyas> nope..vm
17:11:12 <kparal> VMs don't seem to be affected
17:11:44 <akshayvyas> well its going real slow and i got anaconda not responding 2 times but installation went successful
17:12:10 <adamw> i didn't try live on metal yet, but if it hits multiple machines for kparal, that seems worth caring about
17:13:05 <kparal> I saw this probably on three machines already
17:13:13 <kparal> maybe two
17:14:26 <akshayvyas> can any one try it now ?? :)
17:14:32 <kparal> I think it can be the same problem as bug 928287
17:14:49 <kparal> I think this should be +1 blocker
17:15:47 <brunowolff> It seems to be happening enough to be a blocker.
17:16:13 <adamw> i just pinged #anaconda about it, but i'm okay with +1 at least for now if they don't have any read atm
17:17:01 <akshayvyas> https://dl.dropbox.com/u/95286161/Fedora%2019%20xfce_.png
17:17:34 <adamw> i can test startup at least on my laptop but i have to write a usb stick first
17:17:43 * satellit_e dd usb to test liveinst from desktop x86_64 on bare metal atm
17:17:47 <akshayvyas> still not sure about bare metal
17:17:47 <tflink> proposed #agreed 928279 - AcceptedBlocker - Violation of the following F19 alpha criterion for some bare metal installs (not sure the exact trigger, seems to be enough to not be too hw specific): "The installer must run when launched normally from the release-blocking images."
17:18:13 <kparal> ack
17:18:31 <adamw> ack, will check if i can reproduce
17:19:22 <brunowolff> ack
17:19:47 <tflink> #agreed 928279 - AcceptedBlocker - Violation of the following F19 alpha criterion for some bare metal installs (not sure the exact trigger, seems to be enough to not be too hw specific): "The installer must run when launched normally from the release-blocking images."
17:20:00 <tflink> #topic (947616) anaconda validate architecture from remote installation sources (one can boot X86_64 dvd media and install a 32-BIT one via NFS Installation Source)
17:20:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=947616
17:20:06 <tflink> #info Proposed Blocker, anaconda, NEW
17:20:33 <jreznik> -1 blocker, see my comment
17:21:00 <tflink> -1 blocker
17:21:34 <kparal> I wonder whether a 32bit anaconda can install a 64b tree
17:21:49 <akshayvyas> -1 blocker
17:22:01 <kparal> but sure, -1 blocker
17:22:06 <adamw> definitely -1
17:22:21 <tflink> proposed #agreed 947616 - RejectedBlocker - While the result did not match the initial intentions, the installation was successful and produced a bootable system.
17:22:45 <akshayvyas> ack
17:22:48 <adamw> well, that and 'we can't magically guess your intentions'
17:22:55 <brunowolff> ack
17:22:59 <adamw> ack
17:23:07 <jreznik> ack
17:23:11 <tflink> #agreed 947616 - RejectedBlocker - While the result did not match the initial intentions, the installation was successful and produced a bootable system.
17:23:42 <tflink> #topic (928982) Bootloader install fails on UEFI install to clean VM: "failed to set new efi boot target"
17:23:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=928982
17:23:47 <tflink> #info Proposed Blocker, anaconda, NEW
17:23:57 <tflink> sounds pretty +1 blocker to me
17:24:48 <tflink> proposed #agreed 928982 - AcceptedBlocker - Violates the following F19 alpha release criterion for uEFI systems: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
17:24:56 <adamw> i've only done it once, but it seemed like a pretty straightforward one. be good if anyone else can reproduce. my attempt at a bare metal UEFI install hit the 'crash to black screen' bug at the end of install.
17:25:18 <adamw> oh, and there's a clear error in the logs, of course, which helps.
17:25:33 <kparal> +1
17:26:05 <kparal> ack
17:26:07 <brunowolff> ack
17:26:12 <akshayvyas> ack
17:26:18 <adamw> ack
17:26:24 <jreznik> ack
17:26:49 <tflink> #agreed 928982 - AcceptedBlocker - Violates the following F19 alpha release criterion for uEFI systems: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces."
17:27:00 <tflink> #topic (929289) user account created in anaconda is ignored in gnome-initial-setup
17:27:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=929289
17:27:06 <tflink> #info Proposed Blocker, gnome-initial-setup, NEW
17:28:26 * jreznik tried to ask jasper and msivak to clarify plans - at least martin is not anymore working on initial-setup, handled it to vpodzime
17:29:31 <tflink> while sub-optimal, not sure it's an alpha blocker
17:29:40 * kparal needs to leave
17:29:48 <kparal> -1 blocker I think
17:30:16 <adamw> um
17:30:20 <adamw> this is *gnome*-initial-setup
17:30:20 <jreznik> and we can disable gie for alpha if the interaction between anaconda would not be delivered
17:30:22 <adamw> not initial-setup
17:30:39 <jreznik> yes, it's initial setup but it has to talk with gie
17:30:52 <jreznik> and seems the interaction is not yet implemented
17:31:06 <tflink> jreznik: it sounds more like gie doing its own thing and ignoring the system state
17:31:41 <adamw> um
17:31:53 <adamw> i don't think that's right. initial-setup and gnome-initial-setup are alternatives.
17:32:11 <adamw> the way we have it set up, you get the gnome-initial-setup package if you install GNOME, and the initial-setup package if you install any other desktop. you can't easily get both.
17:32:12 <jreznik> adamw: but the user is created in anaconda
17:32:19 <adamw> sure
17:32:21 <jreznik> that's the issue here
17:32:29 <adamw> both initial-setup and gnome-initial-setup have to check what anaconda did
17:32:38 <tflink> ah, is this reproducable with another DE that isn't using gis?
17:32:43 <jreznik> so if you create it in anaconda, you have to tell initial-setup and gie not to create another users
17:32:47 <adamw> well yes, but that's a separate bug
17:32:54 <adamw> and initial-setup guys are already aware of it and fixing it
17:33:01 <adamw> jreznik: no, that's not the design
17:33:18 <adamw> the design is just that initial-setup and g-i-s look at what anaconda did, not that anaconda sets some kind of special signal for them. aiui, anyway
17:33:38 <jreznik> adamw: I meant it this way, sorry, wasn't clear
17:33:41 <brunowolff> This doesn't seem like an alpha blocker.
17:34:12 <adamw> jreznik: hm, msivak has a different understanding, but that's not how it's set up in comps at all. so i'm not sure who's right.
17:34:12 <jreznik> (and it somehow has to interact - doesn't matter how)
17:34:36 <adamw> anyway, i'm -1 blocker, but we _really_ need initial-setup, gnome-initial-setup and anaconda to get their story straight at this point. i should crack some heads.
17:35:14 <jreznik> adamw: I'm trying to crack some heads, already started
17:35:25 <adamw> okay
17:35:27 <jreznik> I'll try to reach vrata personally tomorrow
17:35:33 <adamw> just so long as they all agree how it should be designed. and actually do it.
17:35:46 <jreznik> (would be better, wasn't aware martin already left anaconda0
17:36:05 * adamw is terminally confused about how it's supposed to work at this point =)
17:36:07 <jreznik> adamw: well, I remember the first discussion how to handle it year ago...
17:36:57 <adamw> how about FE for this? i'd be generally in favour of taking improvements to anaconda/i-s/g-i-s interaction as FE, at least before the weekend
17:37:08 <tflink> WFM
17:37:26 <jreznik> adamw: same here, works for me
17:38:11 <tflink> proposed #agreed 929289 - RejectedBlocker, AcceptedFreezeException - While not severe enough to block the release of F19 alpha, it is a polish issue and an annoyance. A tested fix would be considered past freeze.
17:38:40 <jreznik> ack
17:38:54 <adamw> ack
17:39:49 <brunowolff> ack
17:39:51 <tflink> #agreed 929289 - RejectedBlocker, AcceptedFreezeException - While not severe enough to block the release of F19 alpha, it is a polish issue and an annoyance. A tested fix would be considered past freeze.
17:40:06 <tflink> #topic (946964) after default install of 19 Alpha TC3 in KVM, can't log in from gdm
17:40:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=946964
17:40:11 <tflink> #info Proposed Blocker, gnome-shell, NEW
17:40:45 <adamw> seems like an odd one
17:41:08 <robatino> i seem to be the only one seeing this. i also have trouble logging in on vbox but can manage it with difficulty
17:41:18 <tflink> fwiw, I didn't see this with an install to a 1gb vm effectively running kvm and spice
17:41:22 <robatino> afaik no one else has trouble with either
17:41:48 <tflink> wait, that vm had 2gb memory. NVM
17:43:50 <tflink> punt or reject?
17:45:43 <robatino> the behavior persists with all updates as of today, btw
17:45:54 <adamw> robatino: have you tried tweaking the VM config? 2GB?
17:46:14 <robatino> i could try with 1.5 or maybe 2, my host only has 4 GiB
17:46:25 <adamw> i guess we could punt and try to reproduce precisely, it looks like a few moving parts here
17:46:33 <adamw> at least 'use KVM and create the user in g-i-s', right?
17:47:03 <adamw> and 'install from dvd'
17:48:07 <tflink> punt and attempt to reproduce?
17:48:08 <robatino> i believe i skipped creating the user in anaconda
17:48:35 <robatino> am booting the 32-bit kvm guest right now with 2 GiB
17:48:52 <robatino> will let you know in a minute what happens
17:49:31 <satellit> does initial-setup from root login work?
17:50:56 <robatino> at this point i don't see any difference
17:52:23 <robatino> initial-setup from a root prompt in a VT does work
17:54:01 <robatino> but i already had a working root and user account
17:54:33 <robatino> i see no difference with 2 GiB
17:55:12 <tflink> propose #agreed 946964 - It's unclear how widespread this issue is, will re-evaluate when there is more data on how many users are affected
17:55:29 <adamw> ack
17:55:30 <robatino> +1
17:55:38 <robatino> ack
17:56:24 <jreznik> ack
17:56:35 <tflink> #agreed 946964 - It's unclear how widespread this issue is, will re-evaluate when there is more data on how many users are affected
17:56:42 <tflink> #topic (929403) initial-setup-graphical.service is not enabled by default, so initial-setup does not run after install (KDE, LXDE, Xfce...)
17:56:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=929403
17:56:47 <tflink> #info Proposed Blocker, initial-setup, NEW
17:57:34 <tflink> seems like a pretty clear blocker
17:57:47 <adamw> unless i'm missing something, yeah.
17:58:04 <adamw> i wondered if maybe they were expecting anaconda to enable it or something, but that seems stupid and not something anaconda would do.
17:58:21 <tflink> propose #agreed 929403 - AcceptedBlocker - Violates the following F19 alpha release criteria for KDE: "A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account."
17:58:34 <brunowolff> ack
17:58:44 <jreznik> well, the workaround exists - create user in anaconda...
17:59:51 <adamw> true, but we kinda decided we didn't want to catch people out who didn't know they need to do that, we took a similar bug as a blocker before
17:59:55 <adamw> there was aNOTHER bug in i-s
18:00:30 <jreznik> not saying I'm not ok with blocker
18:02:11 <tflink> other ack/nak/patch?
18:03:06 <jreznik> ack but I'd like to have the criterion updated (we talked about it - the firstboot rename, anaconda "firstboot" part...)
18:03:55 <tflink> #info note that while the criteria have not yet been updated - firstboot encompasses initial-setup and gnome-initial-setup
18:04:54 <adamw> ack
18:04:59 <adamw> jreznik: yeah, i need to bump that thread
18:05:28 <tflink> #agreed 929403 - AcceptedBlocker - Violates the following F19 alpha release criteria for KDE: "A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account."
18:05:53 <tflink> #topic (928994) Installer doesn't create /run directory leading to boot failure
18:05:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=928994
18:05:58 <tflink> #info Proposed Blocker, LiveCD - KDE, NEW
18:06:49 <tflink> this is oddly filed - why would that be unique to the kde livecd
18:07:21 <tflink> looks like it needs testing and is likely a dupe of 928339
18:07:32 <adamw> yeah
18:07:37 <adamw> which itself got closed as a dupe
18:07:54 <adamw> this is one it'd be nice to have a TC4 to check the status of, but i wanted the fix for the anaconda crash-to-black-screen before doing tc4
18:09:35 <tflink> proposed #agreed this is likely a dupe of #928339 but it should be tested with TC3 or the pending TC4 before closing as a dupe - will revisit if this turns out not to be a duplicate
18:09:47 <adamw> ack
18:10:55 <jreznik> ack
18:11:10 <brunowolff> ack
18:11:58 <tflink> #agreed this is likely a dupe of #928339 but it should be tested with TC3 or the pending TC4 before closing as a dupe - will revisit if this turns out not to be a duplicate
18:12:07 <tflink> #topic (928303) F19 KDE contains F18 artwork
18:12:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=928303
18:12:07 <tflink> #info Accepted Blocker, schroedinger-cat-kde-theme, MODIFIED
18:12:14 <tflink> whoops
18:12:17 <tflink> #undo
18:12:17 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2a5eee10>
18:12:19 <tflink> #undo
18:12:19 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2a5ee250>
18:12:21 <tflink> #undo
18:12:21 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2a5eeb10>
18:12:33 <tflink> opic (922988) python-blivet not creating /sys and /run on /mnt/sysimage
18:12:36 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=922988
18:12:39 <tflink> #info Proposed Blocker, python-blivet, MODIFIED
18:12:43 <tflink> #undo
18:12:43 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2a5ee110>
18:12:44 <tflink> #undo
18:12:44 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2817e790>
18:12:51 <tflink> #topic (922988) python-blivet not creating /sys and /run on /mnt/sysimage
18:12:54 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=922988
18:12:56 <tflink> #info Proposed Blocker, python-blivet, MODIFIED
18:13:05 <tflink> now that I got the FAIL out of my system ...
18:13:15 <adamw> =)
18:13:47 <adamw> i'm a bit confused about this one with the differing reports about what exactly is busted and when...but it may be a case of 'just check with tc4'
18:16:10 <tflink> shouldn't the acceptedblocker from 928339 have been transferred with the duplicate?
18:18:45 <adamw> yeah, probably
18:18:49 <adamw> so we can call it an acceptedblocker
18:19:09 <jreznik> +1
18:19:42 <tflink> #info an accepted blocker was marked as a duplicate of this bug and the acceptedblocker should have transferred - does not need to be re-evaluated
18:20:14 <tflink> ok, that's all the proposed blockers on my list
18:20:18 <tflink> on to the proposed FE
18:20:31 <tflink> #topic (928704) gnome-terminal crashes when new profile (or profile edit) is requested
18:20:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=928704
18:20:36 <tflink> #info Proposed Freeze Exceptions, gnome-terminal, MODIFIED
18:21:59 <tflink> +1 fe - terminal profile editing should work, fix is ready
18:22:13 <jreznik> +1 fe
18:22:35 <adamw> +1 this early, might be -1 later. but sure
18:23:07 <tflink> proposed #agreed 928704 - While not critical enough to block the release of F19 alpha, it would be nice to fix this before release. A tested fix would be considered after freeze
18:24:55 <tflink> ack/nak/patch?
18:25:05 <adamw> ack
18:26:11 <jreznik> ack
18:26:21 <tflink> #agreed 928704 - While not critical enough to block the release of F19 alpha, it would be nice to fix this before release. A tested fix would be considered after freeze
18:26:49 <tflink> OK, that's all of the proposed FE - on to the accepted blockers not ON_QA or later
18:27:37 <tflink> #topic (926913) rescue mode fails with traceback
18:27:37 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=926913
18:27:37 <tflink> #info Accepted Blocker, anaconda, MODIFIED
18:28:12 <adamw> should be fixed for TC4, we just need to spin it and test
18:28:45 <tflink> ah, it changed since the list was generated
18:29:10 <tflink> #info this is now ON_QA - we have a build and just need a new spin to test it
18:29:23 <tflink> #topic (928353) firefox i686 crashes for a number of web pages
18:29:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=928353
18:29:23 <tflink> #info Accepted Blocker, firefox, NEW
18:30:02 <tflink> it sounds like this might be fixed
18:30:09 <jreznik> seems we have workaround
18:30:27 <tflink> probably more accurate than fixed
18:31:15 <jreznik> disabled JIT
18:31:23 <adamw> we can ask whether  they'd want to mark the bug as fixed or handle it differently
18:31:28 <tflink> odd, there's no update for it
18:31:42 <jreznik> but it's built - http://koji.fedoraproject.org/koji/buildinfo?buildID=408680
18:31:48 <adamw> so we need them to file an update
18:31:49 <jreznik> so martin probably forgot it
18:32:00 <tflink> and it's already f19-updates-pending
18:32:00 <adamw> do we also need to ask for the same workaround for webkit and qtscript?
18:32:28 <tflink> er, f19-updates-candidate
18:32:34 <jreznik> not as blocker, for kde spin, konqueror does not have JIT
18:33:13 <tflink> #info a build with the workaround described in bug is available:
18:33:26 <tflink> #link http://koji.fedoraproject.org/koji/buildinfo?buildID=408680
18:33:58 <tflink> #info request update for the xulrunner build so that it can be included in the next TC
18:34:13 <adamw> true
18:35:28 <tflink> anything else?
18:35:56 <adamw> i think that's good for this bug, i've updated it
18:36:13 <tflink> #topic (929054) repoclosure failure on 19 Alpha TC3 DVDs (libmateui)
18:36:16 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=929054
18:36:18 <tflink> #info Accepted Blocker, libmateui, MODIFIED
18:37:26 <tflink> sounds like this is pretty much fixed
18:37:32 <jreznik> yep
18:37:42 <tflink> #info the problematic package has been retired, the problem should be fixed
18:38:26 <adamw> i guess we confirm with TC4 then close
18:38:31 <tflink> yeah
18:38:45 <tflink> #info confirm fix with TC4 and close if it is fixed
18:38:58 <tflink> #topic (926916) anaconda can't report traceback to bugzilla
18:38:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=926916
18:38:59 <tflink> #info Accepted Blocker, libreport, ASSIGNED
18:39:19 <adamw> 20 minutes to the 3 hour cutoff
18:39:31 <jreznik> it depends on https://bugzilla.redhat.com/show_bug.cgi?id=929181
18:39:41 <adamw> yeah, that's the only change...
18:39:50 <tflink> we have 4 more accepted blockers before we;re done
18:40:01 <adamw> ah, patch has been sent, i'll try and make sure it gets reviewed
18:40:06 <jreznik> and it's going to be fixed on libreport side, they were arguing what side it should be fixed
18:40:21 <jreznik> python-meh side, sorry
18:40:40 * jreznik talked to guys
18:41:11 <tflink> #info the problem has been identified, devs are figuring out where to fix the issue
18:41:22 <adamw> oh, okay. well, wherever it's getting fixed, it needs t oget fixed soon...we could really do with working crash reporting
18:41:26 <tflink> #info patch has been sent, still needs to be reviewed
18:41:38 <tflink> #info related to https://bugzilla.redhat.com/show_bug.cgi?id=929181
18:42:20 <tflink> 929181 should probably be a blockeras well
18:43:55 <adamw> it's an implied blocker
18:44:07 <adamw> a bug that blocks a blocker should be considered a blocker, i thought we had logic for that?
18:44:24 <tflink> if we don't, we should
18:44:48 * jreznik expected it works this way
18:45:22 <tflink> we can cross that bridge if/when we get there
18:45:47 <adamw> yeah, we've covered the bug
18:45:52 <tflink> I don't think it would be a hard sell, unless we want to vote on this now
18:45:58 <tflink> #topic (947680) Bogus dependency on "seavgabios" in qemu-1.4.0-7.fc19
18:46:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=947680
18:46:04 <tflink> #info Accepted Blocker, qemu, MODIFIED
18:46:07 <adamw> this just needs karma.
18:46:20 <tflink> more ON_QA changes since the list was generated
18:46:35 <tflink> #info this bug changed to ON_QA since the list was generated
18:46:49 <tflink> #info fix is available, needs testing and karma
18:47:04 <tflink> #topic (924256) repoclosure failure on 19 Alpha TC1 DVDs (resteasy)
18:47:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=924256
18:47:10 <tflink> #info Accepted Blocker, resteasy, NEW
18:47:42 <jreznik> we need https://bugzilla.redhat.com/show_bug.cgi?id=947519 pulled in
18:47:59 <tflink> yep
18:48:26 <tflink> #info there is a new package which will fix this (jboss-servlet-2.5-api)
18:48:41 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=947519
18:48:58 <tflink> #info there should be a build available later today
18:49:27 <adamw> we should make sure they know to submit it via bodhi, i'll post that.
18:49:38 <tflink> sounds good, thanks
18:49:57 <tflink> and the last accepted blocker for the day ...
18:50:00 <tflink> #topic (928303) F19 KDE contains F18 artwork
18:50:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=928303
18:50:00 <tflink> #info Accepted Blocker, schroedinger-cat-kde-theme, MODIFIED
18:50:20 <tflink> sigh, other one that went ON_QA during the meeting
18:50:35 <tflink> #info this bug went to ON_QA during the meeting
18:50:48 <tflink> #info a fix is available, needs testing after TC4 spin
18:51:01 <tflink> #topic Open Floor
18:51:19 <tflink> Anything else for today?
18:51:47 <adamw> i think i'm good
18:52:18 <brunowolff> The llvmpipe issue turns out to be limited to CPUs without SSE2 so the impact is less than originally thought.
18:52:22 <tflink> otherwise, I'm setting the fuse for [0,5] minutes
18:52:40 <tflink> brunowolff: that means P2 and older, right?
18:52:41 <jreznik> just one question - do we want more frequent blocker review meetings now? at least to check status?
18:52:54 <tflink> want? probably not
18:53:07 <adamw> well, we can do the post-meeting one on monday
18:53:08 <tflink> should? maybe
18:53:16 <brunowolff> And some AMD machines. I have a pentium M machine and and athlon MP machine with the issue.
18:53:21 <tflink> plan on one for friday?
18:53:47 <tflink> brunowolff: isn't pentium M the mobile p2?
18:54:03 <brunowolff> Maybe. I don't know.
18:54:05 * jreznik is not sure he can attend Friday one this week - travelling... but will try to follow up...
18:54:33 <jreznik> but definitely votes for monday's post meeting one to see where we are before go/no-go
18:54:39 <tflink> #info will decide whether it's worth scheduling another blocker review meeting for friday later today or tomorrow
18:55:08 <tflink> #info will schedule blocker review meeting for after monday's qa meeting to check status
18:55:24 <brunowolff> Please avoid the board meeting if you make it tomorrow.
18:55:27 * jreznik should run home or he will be killed at home by anett :)
18:55:47 <jreznik> brunowolff: well, I definitely don't want to meetings in the same time :)
18:56:00 <tflink> brunowolff: I think tomorrow would be a bit early for another blocker review meeting
18:56:49 * tflink sets the fuse for [0,3.5] minutes
18:57:05 <brunowolff> I misread the message. I thought the or tomorrow meant the meeting not the decision about whether to meet on Friday.
18:57:47 <tflink> ok
18:58:15 <tflink> Thanks for coming, everyone!
18:58:24 * tflink will send out minutes shortly
18:58:28 <tflink> #endmeeting