16:07:13 <tflink> #startmeeting f18-alpha-blocker-review-7 16:07:13 <zodbot> Meeting started Wed Sep 12 16:07:13 2012 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:07:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:07:13 <tflink> #meetingname f18-alpha-blocker-review-7 16:07:13 <zodbot> The meeting name has been set to 'f18-alpha-blocker-review-7' 16:07:13 <jreznik> adamw: morning! 16:07:17 <tflink> #topic roll call 16:07:29 * jreznik is here 16:07:35 <tflink> now that I've started the meeting in the right channel 16:07:36 <adamw> present! 16:08:00 <tflink> hrm, meetbot seems to be a bit slow today 16:08:15 * satellit still listening 16:08:16 * jreznik is also a little bit slow today :) 16:08:16 <tflink> let's try this again 16:08:22 * Martix is deplying ion-canon for killing few blocker bugs 16:08:23 <tflink> #topic Roll Call 16:09:26 <tflink> did I do something wrong w/ starting the meeting? 16:09:42 <adamw> the main reason meetbot is slow is that meetbot isn't *here* 16:09:46 <adamw> we should probably have checked that. =) 16:10:10 <jreznik> it's here 16:10:11 <tflink> but the meeting started and the logs are on meetbot.fp.o 16:10:11 <Martix> zodbot: is here 16:10:16 <adamw> oh, yeah, zodbot, i forgot 16:10:47 <adamw> oh 16:10:50 <adamw> i bet zodbot doesn't have privs to change the topic 16:11:11 <tflink> it looks like there haven't been many meetings in here 16:11:28 <tflink> the last one w/ logs was more than 2 years ago 16:11:33 <dan408> morning adamw 16:11:45 * nirik can fix that. 16:11:51 <adamw> go nirik 16:11:53 <adamw> morning dan 16:12:06 <dan408> adamw: you won i think 16:13:22 <jreznik> tflink: try it again now! 16:14:03 <tflink> #topic Roll Call 16:14:29 * jreznik is here, for the third time today :) 16:14:50 * Southern_Gentlem is always here 16:14:58 <Martix> .fas Martix 16:14:58 <zodbot> Martix: martix 'Martin Holec' <martix.cz@gmail.com> 16:14:58 <adamw> allelulia 16:15:15 <adamw> man, but this is a smooth professional operation, huh 16:15:58 <tflink> ok, now that we have that figured out, I think it's time for some always fun boilerplate 16:16:03 <tflink> #topic introduction 16:16:11 <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:16:18 <tflink> #info We'll be following the process outlined at: 16:16:18 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:16:37 <tflink> #info The bugs up for review today can be found at: 16:16:37 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current 16:16:46 <tflink> #info The criteria for release blocking bugs can be found at: 16:16:47 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria 16:16:47 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria 16:16:47 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria 16:17:30 <tflink> any objections to starting with the proposed blockers? 16:17:50 <adamw> i propose we start with whiskey 16:19:38 <jreznik> it's dangerous to drink alcohol here now, 15 people died in a last few days after methylalcohol poisoning, some kind of prohibition is on... 16:19:38 <adamw> hey, sounds like everyone agrees! 16:19:57 <tflink> #info 12 Proposed Blockers 16:19:57 <tflink> #info 11 Accepted Blockers 16:19:57 <tflink> #info 9 Proposed NTH 16:19:57 <tflink> #info 8 Accepted NTH 16:20:19 <tflink> #topic (855289) Dri files are missing in lorax ( /usr/lib64/dri/foo-dri.so: cannot open shared object file: No such file or directory ) 16:20:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855289 16:20:25 <tflink> #info Proposed Blocker, ON_QA 16:20:56 <jreznik> seems like it wasn't the right fix :( 16:21:04 <tflink> it sounds like there's still a bug here somewhere but the dri files weren't the problem 16:21:39 <tflink> I'd say punt on this 16:21:58 <jreznik> the question is how many systems are affected by this bug? and seems it's even not always reproducible on the same hw 16:22:19 <adamw> i'm not entirely sure how much bare metal testing we have, to be fair 16:22:27 <adamw> i'm okay with reject (for now) or punt 16:22:40 <tflink> not a whole lot of testing on bare metal, I suspect 16:22:41 <adamw> well, since we have go/no-go tomorrow, it'd be cleaner to reject, i guess 16:22:50 <jreznik> adamw: +1 16:23:40 <tflink> proposed #agreed 855289 - RejectedBlocker - Since there is no clear fix and there are few reports, rejecting as blocker for F18 alpha. If this turns out to be a bigger problem, please re-propose as a blocker. 16:24:14 <adamw> ack 16:24:27 <Martix> ack 16:24:37 <jreznik> ack 16:24:43 <tflink> #agreed 855289 - RejectedBlocker - Since there is no clear fix and there are few reports, rejecting as blocker for F18 alpha. If this turns out to be a bigger problem, please re-propose as a blocker. 16:24:50 <tflink> #topic (854471) anaconda stop at the "Error checking storage configuration" 16:24:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=854471 16:24:51 <tflink> #info Proposed Blocker, NEW 16:25:22 <tflink> sounds like not a blocker to me 16:26:02 <adamw> oh, we got the storage.log for this now, didn't get time to look at it yet... 16:26:06 <jreznik> same for me, just the ui needs to be polished -> so it's for beta/final maybe? 16:26:24 <adamw> ah, -1, with bcl. 16:26:48 <jreznik> -1 blocker 16:27:39 <dlehman> doesn't look the anything really stops. he just didn't finish setting up storage. 16:27:47 <adamw> yeah 16:27:52 <adamw> i should've looked at the picture sooner 16:27:56 <tflink> proposed #agreed 854471 - RejectedBlocker - Since this is more of a UI confusion issue, it was deemed not to be a blocker for F18 alpha. 16:27:58 <adamw> somehow i was reading it as a crash, when it obviously isn't 16:27:59 <adamw> ack 16:28:09 <jreznik> ack 16:28:25 <Martix> ack 16:28:27 <tflink> #agreed 854471 - RejectedBlocker - Since this is more of a UI confusion issue, it was deemed not to be a blocker for F18 alpha. 16:28:29 <tflink> #topic (852792) [Configure] button in network spoke doesn't work (nm-c-e fails to run) 16:28:32 <jreznik> dlehman: it just need some ui polishing, it could be really very confusing... but it's not alpha 16:28:33 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=852792 16:28:35 <tflink> #info Proposed Blocker, ASSIGNED 16:30:01 <tflink> this prevents any network configuration during install 16:30:21 <tflink> so netinstall w/ any wireless that requires a PW/key won't work 16:30:47 <jreznik> it's quite serious one... it wouldn't work even for wired without dhcp 16:30:49 <tflink> are networks with proxies affected as well or is that set in the repo config 16:31:01 <tflink> oh yeah, I wasn't thinking about static IPs 16:31:22 <adamw> also note that this hits the KDE live image too 16:31:44 <adamw> we fixed the other bug which broke it in the KDE live - the fact that nm-connection-editor wasn't included at all - but now the button still doesn't work in the KDE live because of *this* bug 16:31:45 <jreznik> adamw: it's not a big issue on live - there's network configuration in desktop 16:31:50 <adamw> it does work in the desktop and Xfce lives 16:31:51 <adamw> true 16:31:58 <tflink> proposed #agreed 852792 - AcceptedBlocker - Conditional violation of the following F18 release criterion for any network setup that requires configuration (wireless w/ key, static ip etc.) - "The installer must be able to use at least one of the HTTP or FTP remote package source options" 16:32:14 <adamw> well... 16:32:25 <jreznik> adamw: I was able to get it working by installing latest nmce and applet - then it worked on kde live 16:32:37 <tflink> I built a boot.iso with the new nm-applet but it still doesn't seem to be working 16:32:46 <tflink> jreznik: nmce? 16:32:51 <adamw> i'm not totally convinced we have to block on this at alpha 16:33:06 <adamw> for beta i'd definitely be +1...for alpha, it's more borderline 16:33:19 <Martix> adamw: I see it same way 16:33:27 <dan408> i know this is a meeting, sorry to interrupt, but unrelated question: why isn't fpaste in "base" or "standard"? 16:33:37 <adamw> dan408: ask notting in #fedora-devel 16:33:41 <adamw> he's looking after that stuff 16:33:51 <dan408> i did and he said it's not supposed to be 16:33:56 <jreznik> tflink: connection editor 16:33:57 <dan408> i'll follow up with him 16:34:19 <tflink> hrm, not sure I updated that for the test boot.iso 16:34:35 <adamw> it's part of network-manager-applet . 16:35:27 <tflink> yeah, it was included - I just checked my side repo 16:36:21 <Martix> " The installer must be able to complete an installation using all supported interfaces " is in Final release criteria 16:36:22 <adamw> so...what does everyone vote on this? i didn't see any votes. 16:36:34 <tflink> would we be OK with releasing alpha - knowing that it can't be netinstalled with most wireless or static IP setups? 16:36:39 <adamw> Martix: that's interfaces as in graphical, text, vnc etc 16:36:43 <adamw> not network adapters 16:36:46 <Martix> adamw: ok, I wasnt sure 16:36:47 <tflink> graphical netinstall, I mean 16:36:51 <zodbot> Ticket notification - f18betablocker: [Bug 856728] Fallback to text mode fails too. <https://bugzilla.redhat.com/show_bug.cgi?id=856728> 16:36:55 <tflink> does ks work or are there workaround? 16:37:01 <adamw> tflink: we released final for years that couldn't be netinstalled with wireless, so i'm disinclined to care about wireless at alpha 16:37:10 <jreznik_> adamw: is it part of nm-manager-applet? it's standalone package 16:37:13 <adamw> static IP is maybe a bigger thing, but still, alpha... 16:37:19 <adamw> jreznik: it comes from that .src.rpm . 16:37:25 <jreznik_> ah, k 16:37:28 <tflink> jreznik_: it's part of the same update 16:37:47 <tflink> adamw: and static IPs? 16:37:49 <jreznik_> well, I'll try it again 16:37:56 <adamw> tflink: see above, i am prevaricating 16:38:01 <jreznik_> it's definitely NTH 16:38:17 <adamw> jreznik: installing the package in the live environment may give different results from using an image into which it was built 16:38:25 <adamw> that may be part of the problem here 16:38:35 * jreznik_ understands 16:38:56 <adamw> tflink: i want other people to vote so i can carefully tailor my position to agree with the majority =) 16:39:13 <tflink> to me, it looks like there is some config/setup file missing from the boot.iso but I don't pretend to have a deep understanding of how everything fits together 16:39:44 <tflink> if it didn't work on lives, I would wonder if anaconda needed a rebuild 16:39:52 <tflink> against the new packages 16:40:02 <jreznik_> tflink: it worked for me on lives 16:40:31 <tflink> jreznik_: yeah, that's why I'm not suggesting the rebuild 16:41:21 <jreznik_> well, let's do this as NTH for now... /me still feels it more as blocker, but default config for installation is not to touch it, use wire + dhcp 16:41:38 <Martix> +1 NTH, -1 alphablocker 16:42:24 <tflink> yeah, that fits somewhat with what we've been doing with other installer issues - block alpha for issues in the default path 16:43:07 <Varikonniemi> why does f18 installer allocate 4g to swap even if ram is 2g ? 16:43:12 <tflink> and using the DVD is a workaround 16:43:39 <tflink> Varikonniemi: I believe that the general practice is to make swap == 2x memory 16:43:44 <jreznik_> ok, so +1 NTH, -1 blocker 16:43:52 <Varikonniemi> no its 1x 16:44:01 * dan408 is away: (Auto-Away after 10 mins) [BX-MsgLog On] 16:44:14 <jreznik_> Varikonniemi: pls, after blocker review... 16:44:23 <Varikonniemi> ? 16:44:43 <adamw> i have one guess at why this is happening 16:44:52 <adamw> the package has glib-compile-schemas in %post 16:45:02 <adamw> but it doesn't Requires(post) whatever package glib-compile-schemas is in 16:45:39 <jreznik_> adamw: but it should be fixed in latest build 16:45:49 <jreznik_> let me find it - that's why it worked for me on live 16:45:50 <adamw> jreznik_: no, they didn't fix that 16:45:53 <adamw> i'm looking at git master 16:45:58 <tflink> proposed #agreed 852792 - RejectedBlocker (alpha), AcceptedNTH - While this does cause netinstall for network setups requiring configuration, it doesn't directly violate any of the F18 alpha release criteria and installing from DVD is an acceptable workaround for those setups 16:46:04 <tflink> adamw: lorax issue, maybe? 16:46:34 <adamw> jreznik_: the two recent commits a) run glib-compile-schemas and b) put the file in the package, but there's no Requires(post) 16:46:50 <tflink> if it works in live, you would think that there aren't issues with the package 16:46:52 <adamw> i could see that when the environment for the DVD is built, glib2 isn't a part of it 16:46:53 <jreznik_> ok 16:46:54 <Martix> ack 16:46:57 <adamw> tflink: no, this actually explains that 16:47:22 <adamw> it would make some sense that glib2 would happen to have been installed already when the nm-connection-editor package comes up, in the desktop and xfce spins, but not kde... 16:47:23 <jreznik_> so it's missing dep 16:47:33 <adamw> possibly. i'm not gonna bet my life on it, but it could be 16:47:48 * jreznik_ is not sure what was dragged into live 16:47:55 <adamw> it would also explain why re-installing the package after booting live fixed it for jreznik, if glib2 happened to have got installed by then 16:48:15 <tflink> what would have pulled it in? 16:48:20 <tflink> oh, nvm 16:48:40 <tflink> if it wasn't installed prior to %post running, breakage would ensue 16:48:56 <jreznik_> seems like it's the case 16:49:06 <tflink> ack/nak/patch? 16:49:25 <tflink> hrm, incomplete thoughts in the proposal 16:49:49 <tflink> proposed #agreed 852792 - RejectedBlocker (alpha), AcceptedNTH - While this does prevent netinstall for network setups requiring configuration, it doesn't directly violate any of the F18 alpha release criteria and installing from DVD is an acceptable workaround for those setups 16:50:02 <Martix> ack 16:51:37 <adamw> ack 16:51:41 <jreznik> ack 16:51:49 <tflink> #agreed 852792 - RejectedBlocker (alpha), AcceptedNTH - While this does prevent netinstall for network setups requiring configuration, it doesn't directly violate any of the F18 alpha release criteria and installing from DVD is an acceptable workaround for those setups 16:51:58 <tflink> #topic (855976) In F18 Alpha, 'automatic' partitioning simply wipes your entire disk without warning you first 16:52:01 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855976 16:52:02 <adamw> i'm doing a scratch build with requires(post) added 16:52:03 <tflink> #info Proposed Blocker, NEW 16:53:29 <adamw> so...again this is alpha, but i'm pretty uncomfortable with blowing away entire disks with no indication that that's what's about to happen. 16:53:53 <Martix> and its pretty easyfix 16:54:06 <jreznik> Martix: but https://bugzilla.redhat.com/show_bug.cgi?id=855976#c9 16:54:38 <adamw> yeah, string freeze seems ridiculous at this point. 16:54:47 <adamw> i hardly think we're not going to need to change any more strings in the installer. 16:54:56 <Martix> adamw: +1 16:54:59 <adamw> and even an untranslated warning that your disk is about to be wiped seems better than *no* warning. 16:55:57 <tflink> very true 16:56:05 <Cerlyn> Is there a translated string from the previous installer that could be cherry picked? 16:56:07 <adamw> straw poll: did anyone actually understand that their disk was going to get wiped, the first time they ran an install with newui? 16:56:15 <adamw> Cerlyn: oh, good thinking. i think there may be. 16:56:30 <Martix> breaking feature freeze milestone is more worrying for me than breaking string freeze, but first one happens often 16:56:59 <msivak> Cerlyn: maybe, but we will be definitely changing more strings before alpha is out 16:57:23 <tflink> adamw: the first time that I installed, I was expecting the installer to eat babies and laugh while eating 16:57:29 * adamw pokes the jlk, who appears to have a dog in this fight 16:57:31 <adamw> tflink: heh. 16:57:44 * jlk clears throat and reviews bug 16:58:01 <tflink> but that was early pre-alpha, not a released alpha 16:58:07 <jlk> oh right, this one. 16:58:50 <jlk> that dialog is still under development and discussion. I don't really see a point in slapping something else slightly less unfinished in there in a rush, just to change it again after the alpha. 16:58:50 <tflink> if we're going to have a link on fp.o, I'm not so comfortable with no warning 16:58:59 <jlk> put a warning next to the link. 16:59:07 <jlk> it's pre-release software for cripes sakes. 16:59:41 <tflink> sure, it's pre-release software but I think it's reasonable to expect that it isn't going to stomp on your whole disk without warning @ alpha 16:59:52 <jlk> as I stated in the bug, you can vote it NTH if you really want to, but causing a(nother) alpha slip for this is just silly. 17:00:17 <jlk> tflink: there are any number of bugs lurking that could stomp on your disk anyway, even if you requested something completely different 17:00:21 <jlk> it's new code. 17:00:32 <jlk> we haven't tested in all the variety of configurations people are going to throw at it. 17:01:14 <tflink> true, there are probably still bugs in there but that doesn't mean that we shouldn't warn people when we _know_ that their disk is going to be wiped 17:01:41 <adamw> 'we shouldn't warn about the case where we know you're about to lose all your data because there's a high chance we'll screw up and wipe it all anyway'...can anyone tell they're in a fedora channel? :P 17:01:45 <jlk> and the final dialog may state that 17:02:17 <jlk> or the final product may actually default to using free space instead of all space. 17:02:30 <jlk> my point here is that if this was the only bug left, it's laughable that this would cause a slip in the release. 17:02:51 <adamw> i think laughable is putting it way too strongly. 17:03:18 <adamw> i could probably be argued out of it, but you're kind of hurting your own case by implying that anyone on the other side is being dumb. 17:03:49 <zodbot> Ticket notification - f18alphanicetohave: [Bug 852792] [Configure] button in network spoke doesn't work (nm-c-e fails to run) <https://bugzilla.redhat.com/show_bug.cgi?id=852792> 17:03:51 <adamw> if we fall back on process...this doesn't hit any of the criteria either current or proposed, that i can see 17:04:26 <adamw> do we want to do a show of hands to see where people stand on this one? 17:04:28 <jlk> adamw: I apologize. I'm trying to laugh so that I don't get overly angry :) 17:04:31 <adamw> heh 17:05:10 <msivak> jlk: how hard would it be for us to display "data loss" line next to the storage spoke on the summary hub? 17:05:46 <jlk> msivak: difficulty is not the question 17:06:07 <jlk> the question is does the lack of such a line create a reason to delay the alpha release. 17:06:22 <adamw> that is indeed the question 17:06:36 <adamw> we usually don't and shouldn't decide blocker status based on how easy the fix is 17:06:40 <jreznik_> jlk: how much time do you expect it will take? 17:06:58 <adamw> i don't think that's relevant (see above) 17:07:02 <jlk> jreznik_: it could take all the time in the world, if we make more serious bugs the priority. 17:07:05 <adamw> jlk is correct that it shouldn't be a factor 17:07:24 <jreznik> ok, ok :) 17:07:35 <adamw> the other old standby we have is this: 17:07:59 <adamw> if this were the last bug in the world in f18 alpha right now, and it was the go/no-go meeting, would you want us to hold the release for it? 17:08:49 <tflink> not sure if I'm at 'yes, absolutely', but I'm definately not 'no' 17:09:06 <dlehman> if it's clearly marked that continue on the configuration hub means "now make it so" is the argument that people don't know what we've done to configure storage but they have somehow assured themselves all the same the we didn't remove any partitions to make space? 17:09:40 <dlehman> I know it's not about people who pay attention. 17:09:48 <Martix> but today is not nogo mtg, warning can be added and images can be respined overnight, right? 17:09:59 <Martix> if we push harder 17:10:17 <adamw> Martix: yes, but we shouldn't decide on that basis 17:10:26 <adamw> it's wrong to take a bug as a blocker just because we think we can fix it, if you see what i mean 17:10:31 <tflink> Martix: that isn't the point of adam's question - we use it as one test when trying to decide whether or not to take a borderline bug as a blocker 17:10:41 <adamw> if we take a bug as a blocker it should always mean that the answer to that hypothetical question is 'yes' 17:11:11 <adamw> dlehman: the way i see it is this: it's a very strong convention in software than when you (an app) are about to deliberately delete data, if the user hasn't explicitly requested that precise operation, you warn the user 17:11:16 <Martix> I'm for +1 alphablocker regardless of time needed for fixing this 17:11:20 <adamw> people are aware of this convention, consciously or unconsciously 17:11:43 <adamw> so when they go through a process that doesn't tell them they're about to lose all they're data, their expectation is that they're not about to lose all their data 17:12:03 <Martix> that was only pragmatic approach, its doable without slipping alpha, again :-/ 17:12:06 <dlehman> perhaps we should have such a warning when leaving the configuration hub since installing packages could potentially also be destructive 17:12:13 <adamw> i expect that if you put 100 people down in front of the current newUI and asked them what was about to happen when they picked a disk and pressed 'continue', probably 0 of them would say 'well, that whole disk is about to get wiped' 17:12:32 <jreznik> adamw: yep 17:12:36 <adamw> that's just my reading, though 17:12:41 <dlehman> but what would they say? 17:12:49 <jlk> guys, not the point. 17:13:09 <jlk> I think we agree (to some extent) that a bug exists here, in that the user isn't properly notified of what's about to happen 17:13:12 <jlk> that's fine. 17:13:28 <jlk> I don't think we're debating that here 17:13:39 <adamw> well, dlehman asked about it. 17:13:47 <jlk> what we're debating is whether that problem is extreme enough to cause a slip. 17:13:52 <Martix> another question, do we want to angry more users or less? 17:14:11 <jreznik> Martix: it's Alpha... so... 17:14:11 <dlehman> yeah, it's not working as designed now 17:14:29 <jlk> Martix: users of an alpha release of Fedora, who've clicked through a pop up that warns them they are using alpha release software, which may eat their data, and that they have to accept their fate.... 17:14:49 <adamw> so we have a strong +1 blocker from martix, a wishy-washy +1 from me, strong -1 from jlk, i'm assuming a -1 from dlehman, any other votes? 17:15:02 * dlehman just gets tired of this whole "but I was just installing an operating system -- who knew something serious could happen to my computer?" mentality we seem to cater to. 17:15:04 <tflink> jlk: since when does everyone actually read and heed warnings like that 17:15:04 <jlk> you literally cannot go through the install without clicking through a warning about how this pre-release software may eat your data. 17:15:07 <jreznik> also any other bug in alpha could wipe the data also... it should not happen in final, but in alpha 17:15:19 <adamw> jlk: the thing is, we've had that warning forever. it's a generic warning that there may be bugs. no-one's going to interpret it as 'there is code here which intentionally wipes out entire disks without any notification'. 17:15:20 <Martix> jlk: ok, but we should try to avoid catastrophic scenarios if we can 17:15:20 * nirik is a weak -1 blocker. 17:15:30 <spoore> I'd vote NTH for alpha, blocker for beta....I assumed that the whole disk was going to be wiped 17:15:33 <msivak> intentional data loss without warning is bad, but they did accepted their fate.. 17:15:35 <jlk> tflink: you realize that your statement really doesn't help the argument for delaying the release for another warning dialog. 17:15:41 * jreznik is also weak -1 blocker for alpha 17:16:22 <msivak> do we have release notes and known bugs for alpha where we can document it? 17:16:24 <jlk> adamw: we may have had that warning forever, but it was in a different UI with different words and different button options 17:16:29 <jlk> adamw: it's not the same warning anymore. 17:16:36 <nirik> I'd also perhaps note it in the announcement and release notes too... "Note that this will format whatever disks you give it by default... " 17:16:38 <nanonyme> can we tag it *now* as beta blocker, btw? 17:16:40 <Viking-Ice> I assume that those that have voted on the bugs themselves are being counted as well 17:16:46 <adamw> msivak: yes, we have alpha release notes 17:16:47 <jlk> msivak: yes, we typically have release notes or known bugs. list. 17:16:53 <adamw> Viking-Ice: oop, no, i didn't count those votes, sorry 17:17:01 <nanonyme> (and remove it if it gets fixed) 17:17:07 <adamw> so we add a +1 from kamil 17:17:19 <jlk> nanonyme: yes, it can be proposed as a beta blocker now. 17:17:29 <adamw> if we reject it, i'll propose it for beta. 17:17:44 <tflink> jlk: so being pretty sure that people aren't likely to read the warnings in the way that we think we they should isn't a reason not to go that route? 17:17:51 * tflink is +1 blocker 17:18:25 <tflink> is it reasonable to expect that you can install alpha without risking your system? not so sure 17:18:37 <jlk> tflink: I'm saying that we already have a pretty dire warning that users /must/ click through. You're telling me people don't read warnings. Then you're telling me we must put a warning in. 17:18:41 <jlk> I'm failing to follow your logic. 17:18:45 <jreznik> tflink: alpha is always risk... 17:18:53 <msivak> tflink: alpha? not really and never was 17:18:59 <nanonyme> adamw, I'm fine with -1 if you go for beta blocker vote right after so I can vote +1 for it ;) 17:19:05 <dlehman> jlk makes a good point 17:19:07 <adamw> jlk: a specific message about a specific operation, directly tied to that operation, is more likely to be understood. 17:19:18 <jreznik> there could be any other bug that could lead to data loss - it's actually expected 17:19:21 <jlk> if you're trying to set an expectation that alpha software is without risk, you're going to have a hard battle. 17:19:40 <dlehman> for beta the behavior will be different clicking through that particular dialog will not automatically clear your disks 17:20:00 <Martix> jreznik: another bug could affect only part of users, unlike this one 17:20:06 <adamw> what i was envisaging was that the message that pops up saying 'You have enough space to continue!' should say instead 'We're going to destroy all the data on this disk. You have enough space to continue!'. more or less. 17:20:42 <adamw> jlk: no, that's not the expectation. just about everyone who's voted +1 has drawn a clear distinction between potential bugs and intentional destructive actions. 17:21:11 <adamw> well, good news everyone, the voting is exactly tied. :P 17:21:13 <adamw> +4 / -4 17:21:30 <adamw> note that all the +s are qa, and all the -s are not-qa... 17:21:35 <tflink> I'd be crazy to set the expectation that there is no risk in installing alpha regardless of what the popular understanding of alpha/beta is 17:21:40 <adamw> oh, except nanonyme, sorry nano. 17:22:27 <robatino> i'm +1 17:22:47 * adamw finds a tossing quarter 17:23:02 <Viking-Ice> on what are we voting upon now 17:23:13 <adamw> Viking-Ice: 855976 , blocker yay or nay 17:23:25 * jreznik is ok with blocker if QA thinks it's that serious... 17:23:40 <adamw> for those voting +1, what's your rationale wrt https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria ? 17:23:59 <Viking-Ice> thats not a blocker 17:24:02 <msivak> jreznik: and if better message solves that for alpha I suppose :) 17:24:06 <Viking-Ice> it's to be expected 17:24:10 <adamw> do you think it hits one of the criteria? or should it be accepted under the other basis in 'Alpha Blocker Bugs'? or should we create a new criterion? 17:24:17 <adamw> so, +5 / -5. this gets better. :P 17:24:36 <adamw> i suppose we can say with that many -, we certainly don't have a clear consensus that this is a blocker 17:24:46 <Viking-Ice> the logic ( as has been stated ) is simple if you care about your data dont install alpha 17:24:53 * jreznik is not sure where the message should go, as the ui is really not what I'd expect even for alpha 17:25:08 <adamw> i don't recall that we've ever really had a situation like this before, so we've never established whether the presumption is blocker or not-blocker, but i suppose the only sensible way is that the presumption is not-blocker 17:25:12 <Cerlyn> I don't see any notification requirements in the criteria 17:25:15 <adamw> so a very close vote should make it not-blocker 17:25:24 <spoore> adamw, did you count my vote as -1 blocker? (with the intention also of voting +1 blocker for beta) 17:25:54 <adamw> spoore: oop, missed yours, so +5 / -6 17:26:29 <Viking-Ice> add a note to the release criteria and make it an beta blocker and or a final 17:26:48 <msivak> I agree with Viking 17:27:02 <adamw> that's +5 / -7 17:27:03 <Viking-Ice> there already is a big fat warning when the installer loads that it will eat your babies 17:27:05 <adamw> it's looked kinda rejectedblocker 17:27:13 <adamw> s/looked/looking/ 17:27:21 <jwb> they've already said the behavior is going to change post-alpha, right? 17:27:28 <adamw> yes 17:27:34 <jwb> then -1 from me, if it counts 17:27:54 <tflink> yeah, with the criteria written as is, we don't have much to stand on criteria-wise without being hypocritical 17:27:58 <adamw> jwb: it counts for something 17:28:21 <tflink> +5/-8? looks like the rejected votes have it 17:28:26 <adamw> this is probably the closest/most debated vote we've had, so whatever we decide, i'll tabulate the votes in the bug comment 17:28:26 <jreznik> also if you care about data and you don't see reasonable info how the disk is going to be change, you click quick :) that's what I'd do 17:28:57 <adamw> tflink: do a proposal, we've been on this long enough.. 17:30:12 * kparal looks around 17:30:21 <zodbot> Ticket notification - f18alphablocker: [Bug 855644] F18 Live (alpha RC2) Anaconda custom partition layout: no access to existing LVM/LUKS volumes <https://bugzilla.redhat.com/show_bug.cgi?id=855644> 17:30:27 <tflink> proposed #agreed 855976 - RejectedBlocker (alpha), AcceptedNTH - While this has the potential to be a serious issue, it isn't a direct violation of any F18 alpha release requirements. After much voting and discussion in the bug and in IRC, it was decided not to accept this bug as a blocker for F18 alpha. Please re-propose for beta. 17:30:40 <tflink> proposed #agreed 855976 - RejectedBlocker (alpha), AcceptedNTH - While this has the potential to be a serious issue, it isn't a direct violation of any F18 alpha release requirements. After much voting and discussion in the bug and in IRC, it was decided not to accept this bug as a blocker for F18 alpha. Please re-propose as a blocker for beta. 17:31:37 <tflink> ack/nak/patch? 17:31:48 <nirik> ack 17:31:58 <tflink> proposed #agreed 855976 - RejectedBlocker (alpha), AcceptedNTH - While this has the potential to be a serious issue, it isn't a direct violation of any F18 alpha release requirements. After much voting and discussion in the bug and in IRC, it was decided (+5 blocker, -8 rejected) not to accept this bug as a blocker for F18 alpha. Please re-propose as a blocker for beta. 17:32:13 <tflink> hrm, does it even make sense to put the votes in there? 17:32:36 <nirik> not really. stick them in the bug? 17:32:38 <adamw> ack to the second one 17:32:42 <adamw> yeah, i'm writing them into the bug 17:32:52 <nirik> and then later when lots of people yell, we can see who to blame. ;) 17:33:22 <jlk> Anaconda team takes full responsibility, since we'll get the blame anyway :) 17:34:29 <tflink> OK, I need more acks before finishing the vote 17:34:36 <spoore> ack 17:34:42 <Martix> nack 17:34:44 <jlk> ack 17:34:46 <tflink> Martix: patch? 17:34:50 <Viking-Ice> ack 17:35:19 <adamw> Martix: ack doesn't mean you vote -1 blocker, just that you accept the result of the vote and the text picked by tflink 17:35:32 <Martix> adamw: I know :-) 17:35:34 <jreznik> ack to stay behind my decision 17:35:48 <tflink> Martix: what's wrong with the text, then? 17:35:56 <adamw> jlk: oh, i wrote out the vote to be sure the right people get the blame ;) 17:36:10 <zodbot> Ticket notification - f18betablocker: [Bug 855976] In F18 Alpha, 'automatic' partitioning simply wipes your entire disk without warning you first <https://bugzilla.redhat.com/show_bug.cgi?id=855976> 17:36:30 <tflink> Martix: are you writing a patch or not? 17:36:42 <Martix> tflink: pulling git 17:36:47 <adamw> er, eh? 17:36:50 <jlk> Martix: the vote is complete, you're just acking the summary of the vote. 17:36:51 <adamw> a patch for tflink's #agreed text 17:36:54 <adamw> not a patch for anaconda 17:37:02 <Martix> adamw: ok 17:37:09 <kparal> :) 17:37:13 <jlk> Martix: you don't get to vote on ignoring the vote... 17:37:23 <Martix> tflink: you know sed s/RejectedBlocker/AcceptedBlocker/" 17:37:36 <zodbot> Ticket notification - f18alphanicetohave: [Bug 855976] In F18 Alpha, 'automatic' partitioning simply wipes your entire disk without warning you first <https://bugzilla.redhat.com/show_bug.cgi?id=855976> 17:37:52 <tflink> Martix: thanks for helping the process, much appreciated 17:37:54 <robatino> ack 17:38:00 <tflink> #agreed 855976 - RejectedBlocker (alpha), AcceptedNTH - While this has the potential to be a serious issue, it isn't a direct violation of any F18 alpha release requirements. After much voting and discussion in the bug and in IRC, it was decided (+5 blocker, -8 rejected) not to accept this bug as a blocker for F18 alpha. Please re-propose as a blocker for beta. 17:38:05 <Martix> but its late, we have completed vote 17:39:01 <tflink> Martix: and you're making a long meeting longer for no good reason. I don't agree with the conclusion, either but that doesn't mean that I can ignore the results 17:39:11 <tflink> anyhow, moving on 17:39:23 <tflink> #topic (855644) F18 KDE Live (alpha TC5) Anaconda custom partition setup: no access to existing LVM/LUKS volumes 17:39:26 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855644 17:39:28 <Martix> tflink: ok, I misunderstand vote :-) 17:39:29 <tflink> #info Proposed Blocker, NEW 17:40:00 <adamw> having looked at this one again, i'm definitely -1 17:40:09 <adamw> it doesn't even hit the *existing* criterion, never mind the proposed revised one 17:40:23 <adamw> the existing criterion is about *creating* encrypted/luks partitions, not re-using existing ones 17:40:46 <msivak> that is definitely not an alpha blocker 17:40:48 <adamw> it obviously doesn't hit any of the proposals for revising the criterion that have been submitted so far, afaict. 17:40:58 <Viking-Ice> -1 blocker 17:41:16 <nirik> -1 blocker, possibly final ? 17:41:25 <jlk> -1 blocker, intent of existing criteria was that the available autopartitioning choices work, which in this case, do. 17:41:27 <adamw> yeah, final would likely be the place it winds up. 17:41:28 <Martix> I use LUKS, but -1 alphablocker, +1 betablocker? 17:41:51 <tflink> I thought that we covered this, though - pretty much anything non-default wasn't going to be alpha blocker? 17:41:57 <tflink> or am I mis-remembering? 17:42:06 <tflink> either way, it sounds like we're pretty solidly -1 blocker 17:42:18 <jreznik> tflink: it fits "the default" 17:42:22 <jreznik> -1 blocker 17:42:34 <adamw> tflink: i don't think we have a complete consensus on the revised criterion yet, but like i said, this doesn't hit the current criteria or *any* proposal for the revised criterion, so it's pretty solidly -1 :) 17:43:33 <tflink> proposed #agreed 855644 - RejectedBlocker - This doesn't violate any of the release criteria for F18 alpha, therefore it is rejected as a blocker for F18 alpha 17:43:37 <adamw> ack 17:43:42 <Viking-Ice> ack 17:43:48 <nirik> ack 17:43:52 <tflink> #agreed 855644 - RejectedBlocker - This doesn't violate any of the release criteria for F18 alpha, therefore it is rejected as a blocker for F18 alpha 17:44:06 <tflink> #topic (855646) F18 KDE Live (alpha TC5) Anaconda custom partition setup: missing volume/device identification 17:44:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855646 17:44:12 <tflink> #info Proposed Blocker, NEW 17:45:00 <jlk> -1 blocker 17:45:48 <msivak> yep, same thing as the last one, custom partitioning.. 17:46:00 <Martix> -1 blocker 17:46:05 <adamw> yup, -1. 17:46:09 <Viking-Ice> -1 blocker 17:46:12 <jreznik> -1 17:46:53 <nirik> -1 here 17:47:29 <tflink> proposed #agreed 855646 - RejectedBlocker - While this does come close to hitting the F18 alpha release criteria as written, it doesn't apply well to the new anaconda UI and more closely hits custom partitioning which is not an alpha blocking issue 17:47:52 <Martix> ack 17:47:53 <spoore> ack 17:47:55 <Viking-Ice> ack 17:48:04 <nirik> ack 17:48:10 <adamw> ack 17:48:14 <tflink> #agreed 855646 - RejectedBlocker - While this does come close to hitting the F18 alpha release criteria as written, it doesn't apply well to the new anaconda UI and more closely hits custom partitioning which is not an alpha blocking issue 17:48:23 <tflink> #topic (856096) repoclosure failure on 18 Alpha RC2 DVDs (mongodb) 17:48:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856096 17:48:23 <tflink> #info Proposed Blocker, ON_QA 17:48:39 <tflink> sounds like a clear blocker to me 17:48:45 <adamw> obvious +1 blocker per the criteria, happily should be an easy fix 17:48:52 <jreznik> +1 17:48:53 <Viking-Ice> +1 blocker 17:49:00 <tflink> proposed #agreed 856096 - AcceptedBlocker - Violates the following F18 alpha release criterion: " 17:49:12 <jreznik> nice criterion :) 17:49:27 <tflink> proposed #agreed 856096 - AcceptedBlocker - Violates the following F18 alpha release criterion: "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install" 17:49:37 <jreznik> ack 17:49:38 <spoore> ack 17:49:39 <Viking-Ice> ack 17:49:42 <nirik> acl 17:49:44 <tflink> #agreed 856096 - AcceptedBlocker - Violates the following F18 alpha release criterion: "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install" 17:49:44 <nirik> ack even 17:49:55 <tflink> #topic (852841) Mouse jumps to edges / corners when using an absolute input device (ie virtual machine usb tablet) 17:49:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=852841 17:50:01 <tflink> #info Proposed Blocker, NEW 17:50:36 <adamw> this is really annoying, but probably not quite an alpha blocker 17:50:40 <Viking-Ice> -1 blocker 17:50:41 <nirik> -1 blocker, +1 nth 17:51:03 <jreznik> ajax is looking on this 17:51:03 <adamw> i think the closest chance it has to qualify is not the criteria but the "Bug hinders execution of required Alpha test plans or dramatically reduces test coverage" clause 17:51:09 <Martix> its annoying, but -1 blocker, +1 NTH 17:51:10 <adamw> but since so little of the alpha testing is desktop stuff, probably not 17:51:15 <adamw> i might be +1 for beta on that basis, though 17:51:29 <jreznik> it's beta one definitely 17:51:30 <adamw> -1/+1 17:51:46 <tflink> yeah, if we're going to see testing on this for alpha, I don't think that much of it is going to be live-only 17:53:11 <jlk> do we really have alpha criteria that you should be able to install every package from the DVD? 17:53:11 <tflink> proposed #agreed 852841 - RejectedBlocker AcceptedNTH - While annoying, this does not clearly violate any of the F18 alpha release criteria and is therefore rejected as a blocker, accepted as NTH 17:53:24 <jlk> (sorry, got a bit behind) 17:53:59 <jreznik> ack 17:53:59 <tflink> jlk: yeah, "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install" 17:54:06 <Martix> ack 17:54:07 <spoore> ack 17:54:14 <tflink> #agreed 852841 - RejectedBlocker AcceptedNTH - While annoying, this does not clearly violate any of the F18 alpha release criteria and is therefore rejected as a blocker, accepted as NTH 17:54:20 <jlk> huh, that seems overreaching for alpha. 17:54:25 <adamw> ack 17:54:30 <tflink> #topic (856194) firstboot has to insist the first user is admin when root account is locked 17:54:33 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856194 17:54:36 <tflink> #info Proposed Blocker, NEW 17:54:56 <adamw> jlk: we've read it as 'there shouldn't be any conflicting packages on the dvd' for a long time, but i'm not sure that's how we actually _meant_ it when we started 17:55:07 <adamw> jlk: but eh, in practice it's never caused a slip, it's usually easy enough to sort out dep issues 17:55:25 <tflink> or remove a package from the DVD if needed 17:55:27 <jlk> sure, but that dodges the age old question. Would we slip the release for this :) 17:55:28 <adamw> oh goody, another controversial one 17:55:29 <Viking-Ice> lol that's a good one 17:55:41 <Viking-Ice> +1 blocker 17:55:52 <jlk> -1 blocker. 17:55:56 <msivak> text mode requires root password :) 17:55:57 <jlk> it's an easy releasenote thing 17:55:59 <adamw> basically, it's pretty stupid that if you install straight-through defaults, you get a system you can't really use. 17:56:04 <msivak> and gui says root is disabled 17:56:23 <jlk> adamw: stupid yes, blocker worthy, no. 17:56:29 <adamw> i'd see flipping the default of the checkbox in firstboot as a sufficient fix for alpha 17:56:36 <adamw> and that really is bloody easy. i was kinda hoping it'd be done yesterday. 17:56:39 <tflink> -1 blocker, +1 nth - you can workaround this through recovery mode 17:57:04 * kparal agrees with adamw 17:57:05 <Martix> -1 alphablocker, +1 nth, +1 betablocker 17:57:05 <nirik> -1 blocker, +1 nth - another one for release notes. 17:57:19 <msivak> adamw: I was playing with passwords in anaconda.. sorry :) 17:57:50 <msivak> adamw: because I intended to solve the default in anaconda 17:57:52 <Viking-Ice> persuaded since alpha reporters really should know how to rescue their system -1 blocker +1 nth 17:57:57 <jreznik> I'm actually +1 blocker as the default path is broken... 17:58:10 <tflink> proposed #agreed 856194 - RejectedBlocker (alpha), AcceptedNTH - This doesn't clearly violate any of the F18 alpha release criteria and can be fixed/worked around with rescue mode 17:58:11 <jreznik> but if someone is running alpha, should be able to fix it :) 17:58:24 <Viking-Ice> ack 17:58:44 <spoore> -1 blocker / +1 nth 17:58:45 <Martix> its poweruser fixable instead of data loss :-) 17:58:54 <Martix> ack 17:58:54 <adamw> i'm okay with -1/+1 17:59:00 <adamw> but i'd really like it if we could fix this for rc3 17:59:03 <adamw> it's such an easy damn fix 17:59:11 * adamw hints to msivak :P 17:59:41 <Martix> adamw: +1 17:59:43 <jreznik> adamw: you should not use "it's simple" here :) 17:59:45 <msivak> adamw: yeah well.. I have it on my list and will do it tommorow :) 17:59:58 <adamw> tflink: well, it's a conditional breakage of all sorts of criteria. like installing updates. we're just agreeing the condition isn't severe enough to accept it. 18:00:03 <adamw> so, patch...lemme see 18:00:09 <adamw> msivak: tomorrow's too late 18:00:15 <adamw> rc3 needs to be spun, er, right after the meeting 18:00:21 <adamw> jreznik: i meant that in relation to nth 18:00:40 <adamw> i guess i'll have to roll up my sleeves and figure out how to change the default state of a checkbox, then =) 18:00:54 <jreznik> adamw: but same could aply to the wipe data one 18:00:56 <msivak> adamw: then it is not going to be there.. I am loosing the DNS in 30 secons.. office migration 18:01:18 <jreznik> msivak: DNS is not a problem if you have IP address :) 18:01:30 <adamw> proposed #agreed 856194 - RejectedBlocker (alpha), AcceptedNTH - this is a conditional breakage of "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" in the case the user accepts the defaults during install, but we agreed Alpha users should be capable of recovering or reading instructions to create a root password or an admin user 18:01:36 <Martix> msivak: ? 18:01:43 <jreznik> msivak: you can use for example google one 18:01:50 <tflink> #chair adamw 18:01:50 <zodbot> Current chairs: adamw tflink 18:01:53 <jreznik> ack 18:01:58 <Viking-Ice> ack 18:01:58 <tflink> ack 18:01:59 <adamw> tflink: i don't need to be chair to propose it :) 18:02:01 <msivak> also dhcp and all other network services 18:02:10 <tflink> no, but I'm not reformatting that to #agree it 18:02:14 <Martix> msivak: damn 18:02:16 <tflink> :) 18:02:26 <adamw> tflink: heh 18:02:27 <jreznik> msivak: yep, but you have IP address right now... 18:02:30 <adamw> #agreed 856194 - RejectedBlocker (alpha), AcceptedNTH - this is a conditional breakage of "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" in the case the user accepts the defaults during install, but we agreed Alpha users should be capable of recovering or reading instructions to create a root password or an admin user 18:02:32 <Martix> pause mtg, /me is biking home :-D 18:02:41 <tflink> #topic (856225) PackageKit can't import Fedora GPG key 18:02:42 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856225 18:02:42 <tflink> #info Proposed Blocker, NEW 18:02:51 <msivak> I am moving home and I might try from there, but no promises 18:03:10 <Martix> msivak: its announced: 21:00 (Region's local time) 18:03:14 <adamw> this is clear +1 per current criteria, though worth noting viking-ice and I were discussing whether it _really_ makes sense to require graphical updating at alpha 18:03:41 <Martix> oh thats something else, nevermind 18:03:41 <adamw> has anyone seen hughsie, anyway? 18:03:49 <jreznik> for current criteria - it's +1 18:03:56 <jreznik> adamw: I talked to him, he's working on it 18:03:59 <adamw> cool 18:04:07 <adamw> that output you gave looks pretty useful 18:04:26 <adamw> looks like more yum 'api' breakage... 18:04:27 <jreznik> adamw: but I don't have current status from him :( 18:05:04 <jreznik> adamw: yum guy (zpavlas) told me it's probably rpm issue... but then it's strange why it hits only pkgkit and not yum 18:05:10 <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:05:14 <adamw> anyone interested in amending the criteria to reject this, or are we happy with it? 18:05:30 <jreznik> this comes from yum: Key import failed (code 2) 18:05:50 <tflink> I could go either way 18:05:56 <adamw> to elaborate on the criterion thing 18:06:09 <jreznik> adamw: if we are happy with it, it means slip... there's workaround by using yum to import key and then you have working graphical ui 18:06:09 * nirik is +1 blocker. I don't think we should change critera in the middle, because it's not a clear case where something changed 18:06:26 <nirik> no fix on the horizon? 18:06:31 <adamw> the basis for requiring graphical update to work is a bit thin, really...as i recall it, the idea is that we're supposed to be building an OS that's usable completely graphically, and so if we require update to be working at alpha, we must require graphical update as well as yum 18:07:04 <adamw> i'm not really sure anyone expects to be able to use a fedora alpha without ever touching a console 18:07:12 <jreznik> nirik: hughsie promised to inform me but he's not online right now :( 18:07:14 * nirik recalls seeing 'can't import keys' from pk about once a cycle at least. ;( 18:07:37 <adamw> and if we're happy with an alpha that blows away hard disks at the drop of a hat and defaults to installing without any access to root account at all, it seems a bit inconsistent to block on a graphical package manager... 18:07:38 <Viking-Ice> we can move that discussion to later time ( the either/or ) and proceed with the meeting 18:07:51 <tflink> yeah, I'd be OK with requiring just CLI for alpha 18:07:54 <nirik> adamw: true... 18:07:57 <adamw> Viking-Ice: well, if we move it to a later time, we accept this as a blocker. i'm okay with that if it's what we want to do. 18:08:07 <nirik> this doesn't affect live installs? only dvd/net? 18:08:11 <jlk> guys 18:08:13 <jreznik> nirik: only dvd 18:08:14 <tflink> if we're going with one, it should be yum/pk cli - whichever is in minimal 18:08:21 <jlk> please don't make Anaconda import this thing again like last time. 18:08:25 <adamw> tflink: our idea was to make it either/or. 18:08:37 <tflink> adamw: what about minimal installs w/ non-working CLI 18:08:39 <adamw> jlk: you know, i'm sure we have some kind of bug report for that. <ducks> 18:08:59 <adamw> tflink: hum, true. if we go with one, i guess it should be yum. 18:09:00 * nirik feels less +1 now... 18:09:15 <adamw> jlk: but no, that's not the plan here, the plan is 'fix PK'. 18:09:20 <jreznik> has to be yum, as console pkkit does not work either 18:09:31 <jlk> that was the plan last time, and yet anaconda had to import the goddamn thing, because PK couldn't be arsed to fix it in time 18:10:47 <adamw> i guess i'm pretty unhappy with the inconsistency between 'oh, the root password bug is rejectedblocker, alpha users should be able to use rescue mode' and 'this is a blocker because we can't expect people to use a console' 18:10:48 * tflink never saw any acks or naks 18:11:07 <jlk> I'm -1 blocker too 18:11:13 <jlk> easy work around with yum from the console 18:11:40 <Martix> -1 blocker, +1 NTH 18:11:54 <tflink> +1 blocker w/ criteria written as is 18:12:03 <Viking-Ice> I was forced to be +1 per criteria 18:12:08 <jreznik> adamw: yep, we are inconsistent... :( /me can feel everyone is pushing on "make the release possible now"... 18:12:16 <adamw> for those voting -1, can you say whether you are also voting to revise the criterion, or that you want to keep the criterion but consider using yum to import the key a sufficient workaround? 18:12:46 <tflink> that's an interesting way to put it 18:12:58 <adamw> jreznik: it's a bit different for me - it's more that i'm re-evaluating the criteria in the light of viking's thought that we just require too much for an alpha 18:12:59 <jlk> I'm voting on -1 to blocker for this particular bug, leaving criteria changes to a later discussion 18:13:01 <Martix> +1 for workaround, it could be in release notes and its nondestructive bug 18:13:03 <adamw> i think he's correct on that to an extent 18:13:13 <adamw> thinking about it again, i'm not happy with the original rationale for this criterion 18:14:10 <nirik> the main reason to avoid changing critera in process is that it moves the bar for developers. They don't know what they have to make sure works. In this case though it's relaxing that critera, not making it more strict... 18:14:12 <adamw> we should stand firmly by the criteria where they make _sense_, but... 18:14:16 <tflink> I'd be OK with saying that it is a conditional violation (only fails the first time) - using yum as a workaround 18:14:16 <jreznik> adamw: we req. too much for alpha, but the benefit is - it could help beta/final... 18:14:33 <adamw> tflink: i can go with that, and we can talk about modifying the criterion on the ml 18:14:40 <jreznik> also this time it was hard for desktop developers to even try it 18:15:05 <jreznik> we have not covered desktop in alpha yet... 18:15:09 <adamw> tflink: run a proposed up the flagpole and we'll see who salutes =) 18:15:28 <adamw> jreznik: the desktop tests for alpha are pretty minimal, in practice i think we've actually pretty much covered them 18:15:42 <adamw> obviously we've tested updates as we have this bug, and i know i've launched a browser and a terminal =) 18:15:43 <nirik> tflink: I'm ok with that too. 18:16:09 <jreznik> adamw: as I said - it was hard to actually do anything on top of alpha as we were strugling three weeks to get a system that could boot to gui 18:16:18 <tflink> proposed #agreed 856225 - RejectedBlocker AcceptedNTH - While this is a conditional violation of the following F18 alpha release criteria for the first update attempt: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops", it was decided that using yum from the CLI for the first update is an acceptable workaround 18:16:25 <adamw> ack 18:16:28 <nirik> ack 18:16:39 <spoore> ack 18:16:41 <tflink> #agreed 856225 - RejectedBlocker AcceptedNTH - While this is a conditional violation of the following F18 alpha release criteria for the first update attempt: "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops", it was decided that using yum from the CLI for the first update is an acceptable workaround 18:16:43 <jlk> ack ack ack-ack </mars-attacks> 18:16:52 <tflink> #topic (856256) Crash when unlocking screensaver 18:16:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856256 18:16:52 <tflink> #info Proposed Blocker, NEW 18:16:53 <Martix> ack 18:18:00 <tflink> not so sure this is an alpha blocker 18:18:37 <jreznik> -1 blocker, I saw it with cirrus too and sometimes it freezes during login (ui works, just no possibility to login) 18:18:52 <tflink> -1 blocker, +1 nth 18:18:54 <Martix> AFAIR I can reproduce this bug on baremetal with Intel 18:19:14 <adamw> jreznik: ajax says the cirrus case is likely a different bug 18:19:16 * nirik hasn't seen this with xscreensaver. ;) 18:19:21 <adamw> and an intel case likely would be too 18:19:21 <jreznik> adamw: ok 18:19:26 <nirik> anyhow, -1 blocker, +1 nth 18:19:38 <adamw> possibly similar code problems in different drivers, but still technically different bugs 18:19:38 <jreznik> +1 nth 18:19:41 <zodbot> Ticket notification - f18alphanicetohave: [Bug 856225] PackageKit can't import Fedora GPG key <https://bugzilla.redhat.com/show_bug.cgi?id=856225> 18:19:48 <jreznik> adamw: seems reasonable 18:19:54 <Martix> nirik: its not xscreensaver but this is part of Gnome Shell 18:19:54 <adamw> there's obviously a workaround to this - disable screen locking 18:19:57 <adamw> so that's another -1 18:20:28 <nirik> yes, I'm aware, was making a joke. ;) 18:20:36 <Martix> nirik: ok 18:21:03 <Martix> adamw: possibly physical security issue? 18:21:09 <tflink> proposed #agreed 856256 - RejectedBlocker, AcceptedNTH - This does not clearly violate any of the F18 alpha release requirements and can be worked around by disabling the screen saver. However, a tested fix would be accepted. 18:21:15 <jreznik> btw. cirrus/vnc combo makes g-s totaly unusable... while testing it 18:21:46 <Viking-Ice> ack 18:21:48 <nirik> ack 18:21:55 <Martix> I had switched to KDE as a workaround 18:22:11 <Martix> ack 18:22:23 <adamw> ack 18:22:31 <tflink> #agreed 856256 - RejectedBlocker, AcceptedNTH - This does not clearly violate any of the F18 alpha release requirements and can be worked around by disabling the screen saver. However, a tested fix would be accepted. 18:22:35 <tflink> #topic (856399) RC2 DVD is missing grub2-efi and shim packages 18:22:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856399 18:22:40 <tflink> #info Proposed Blocker, MODIFIED 18:22:49 <adamw> +1 blocker, this breaks efi installs 18:22:56 <nirik> +1 blocker 18:23:00 <jreznik> as we already voted several times that we want sb, +1 18:23:12 <jreznik> +1 blocker :) 18:23:15 <jlk> +1 18:23:36 <Martix> +1 blocker 18:23:52 <adamw> jreznik: it's not SB related 18:24:00 <tflink> proposed #agreed 856399 - AcceptedBlocker - Violated the following F18 alpha release criterion for (u)EFI systems: "The installer must boot 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 an optical disc and when written to a USB stick with at least one of the officially supported methods" 18:24:07 <adamw> jreznik: never confuse UEFI and SB: this breaks *any* UEFI install, SB doesn't have to be involved at all 18:24:08 <tflink> proposed #agreed 856399 - AcceptedBlocker - Violates the following F18 alpha release criterion for (u)EFI systems: "The installer must boot 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 an optical disc and when written to a USB stick with at least one of the officially supported methods" 18:24:18 <Viking-Ice> ack 18:24:23 <jreznik> adamw: I saw shim... 18:24:29 <Martix> ack 18:24:30 <nirik> ack 18:24:35 <adamw> ack (well, you have to combine it with one of the 'installed system must work' criteria, but eh) 18:24:35 <tflink> #agreed 856399 - AcceptedBlocker - Violates the following F18 alpha release criterion for (u)EFI systems: "The installer must boot 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 an optical disc and when written to a USB stick with at least one of the officially supported methods" 18:24:48 <adamw> jreznik: grub2-efi is missing too, not just shim 18:24:55 <jreznik> it was like a red flag for bull :) 18:25:04 <tflink> point, this affects the post-install not the install env. 18:25:08 <adamw> brb, call of nature 18:25:10 * jreznik understands the problem now 18:25:33 <tflink> #undo 18:25:33 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x7f58058b5050> 18:25:59 <Martix> ? 18:27:05 <zodbot> Ticket notification - f18betablocker: [Bug 852841] Mouse jumps to edges / corners when using an absolute input device (ie virtual machine usb tablet) <https://bugzilla.redhat.com/show_bug.cgi?id=852841> 18:27:10 <jreznik> Martix: maybe 'installed system must work' criteria? 18:27:12 <tflink> proposed #agreed 856399 - AcceptedBlocker - Violates the following F18 alpha release criterion for (u)EFI systems: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user account" 18:27:35 <jreznik> ack, /me is ok with both 18:27:41 <Viking-Ice> ack 18:27:52 <Martix> ack 18:28:04 <adamw> ack 18:28:05 <zodbot> Ticket notification - f18alphanicetohave: [Bug 852841] Mouse jumps to edges / corners when using an absolute input device (ie virtual machine usb tablet) <https://bugzilla.redhat.com/show_bug.cgi?id=852841> || [Bug 856256] Crash when unlocking screensaver <https://bugzilla.redhat.com/show_bug.cgi?id=856256> 18:28:08 <tflink> eh, the first one isn't true - the installer does boot and run on (u)EFI systems - the resulting install doesn't boot because the grub2-efi package isn't present on the DVD 18:28:17 <tflink> #agreed 856399 - AcceptedBlocker - Violates the following F18 alpha release criterion for (u)EFI systems: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user account" 18:28:23 <adamw> btw, i pushed the fix for this yesterday, so it should have mashed overnight and we shouldn't have to wait to do a compose 18:28:24 <Martix> tflink: ok 18:28:29 <jreznik> tflink: ok, this one is really tough for me :D 18:28:55 <tflink> alrighty, that's all of the proposed blockers on my list 18:29:27 <tflink> any objections to moving on to the proposed NTH? 18:29:52 <Martix> lets move on 18:30:03 <jreznik> go on 18:30:18 <tflink> #topic (855510) Alpha RC2: Cannot get past "Booting in ...... in 0 seconds" screen on iMac 2011 (booting from USB) 18:30:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855510 18:30:23 <tflink> #info Proposed NTH, NEW 18:31:30 <Viking-Ice> imac he's probably just missing some added kernel command line foo 18:32:00 <adamw> he actually seems to be doing a tour of all the worst ways to create a usb stick 18:32:08 <adamw> "I just copied the files on a bootable USB stick, should that not be enough?"...no. 18:32:16 <adamw> "Tried with liveusb-creator"...no. 18:32:19 <tflink> do we have any tests on other macs? 18:32:26 <adamw> mjg59 might have tried it, i dunno. 18:32:27 <jreznik> isn't it related to uefi on macs? 18:32:41 * kparal doesn't know whether jskladan tested Mac Mini 18:32:49 <tflink> I didn't think that liveusb-creator worked w/ EFI w/o extra command line args 18:32:54 <adamw> jreznik: quite possibly, but the uefi bug we just accepted is for post-install, the installer ought to boot via uefi. and this bug says it's not booting at all. but yeah, it's pretty vague. 18:32:55 <Viking-Ice> it takes ages using the livecd-to-using method ( compared to dd ) 18:33:04 <kparal> I can make sure I test Mac Mini tomorrow, if you want 18:33:04 <adamw> tflink: i don't know that liveusb-creator works with efi full stop 18:33:16 <adamw> the methods that definitely work are livecd-iso-to-disk --efi and dd 18:33:25 <adamw> but you have to pass --efi to litd, it doesn't create EFI stuff by default 18:33:31 <tflink> adamw: yeah, I can't remember if it was fixed or not 18:33:47 <tflink> either way, I'd say either punt or reject 18:33:53 <adamw> so even though he says he tried 'livecd updates from update-testing', and that means livecd-iso-to-disk, we don't know if he passed --efi. 18:33:59 <Viking-Ice> in anycase -1 nth we need more info and exact command line used to create that bootable stick 18:34:01 <adamw> punt, i'd like more data 18:34:03 <tflink> it sounds like the boot media wasn't created correctly 18:34:17 <jreznik> kparal could provide more data 18:34:30 <adamw> well, this guy has an iMac, not a Mac Mini 18:34:33 <jreznik> and macs are probably not going to be top consumers of f18alpha 18:34:52 <tflink> proposed #agreed 855510 - We don't have enough information to decide on NTH status for this - needs re-testing with a USB media creation method which we know works for EFI and hopfully other tests using apple hardware 18:35:02 <jreznik> ack 18:35:41 <adamw> ack 18:35:48 <nirik> ack 18:35:51 <tflink> #agreed 855510 - We don't have enough information to decide on NTH status for this - needs re-testing with a USB media creation method which we know works for EFI and hopfully other tests using apple hardware 18:35:54 <nanonyme> adamw, what was the vote result, btw? 18:35:55 <tflink> #topic (855991) jack needs rebuild for removal of libfreebob 18:35:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855991 18:35:56 <tflink> #info Proposed NTH, ON_QA 18:36:29 <nanonyme> (oops, postponing question) 18:36:30 <tflink> +1 NTH since this is a blocker for non-primary DEs 18:36:48 <Martix> someone turned lights off, moving home... 18:36:48 <Viking-Ice> agreed +1 nth 18:36:54 <jreznik> +1 nth 18:36:55 <adamw> nanonyme: on that 'warn about destroying disks' bug from earlier? it was rejected 18:37:03 <adamw> nanonyme: details in the ticket 18:37:17 <adamw> +1 nth 18:37:25 <adamw> i assumed this was going to get +1ed and we pulled it for RC1/RC2, btw. 18:37:33 <adamw> which is why we have an lxde spin. :P 18:37:45 <tflink> proposed #agreed 855991 - AcceptedNTH - Violates the following F18 alpha release criterion for non-primary DEs (LXDE, SoaS), making it an NTH bug - "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install" 18:37:51 <nirik> ack 18:38:03 <jreznik> ack 18:38:13 <adamw> ack 18:38:21 <tflink> #agreed 855991 - AcceptedNTH - Violates the following F18 alpha release criterion for non-primary DEs (LXDE, SoaS), making it an NTH bug - "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install" 18:38:26 <tflink> #topic (848305) When kernel modsetting is enabled, laptop screen remians off until Xorg starts (ironlake) 18:38:29 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=848305 18:38:32 <tflink> #info Proposed NTH, ON_QA 18:38:56 * tflink goes afk for a minute 18:40:50 <Viking-Ice> +1 nth 18:42:10 * Viking-Ice goes grabbing a coffee in the meantime 18:42:25 <adamw> so this bug is kinda 'representative' 18:42:41 <adamw> the underlying problem could actually cause many symptoms 18:43:07 <adamw> another thing it causes, for instance, is the 'cirrus' modesetting kernel module not to load properly, and so cirrus KVMs use xorg-x11-drv-vesa not xorg-x11-drv-modesetting as intended 18:43:24 <tflink> +1 NTH 18:43:28 <adamw> i suspect it might also be the cause of the weirdness people see from time to time where X and a tty seem to be present on vt1 simultaneously 18:43:48 <adamw> halfline and airlied were both of the opinion we ought to pull the new plymouth into alpha and make sure this doesn't cause any major problems we didn't catch yet 18:44:08 <adamw> so, +1 from me. 18:45:09 <tflink> proposed #agreed 848305 - AcceptedNTH - While the most obvious symptom of this bug is cosmetic, it is suspected that there could be other, major problems lurking behind it. A tested fix would be accepted for F18 alpha 18:45:12 <nanonyme> +1 as well 18:45:23 <adamw> ack 18:45:25 <nanonyme> heh, seems didn't matter ;) 18:45:52 <adamw> nanonyme: we usually get a bit slack at the NTH review stage of the meeting, because by this point lots of attendees have usually passed out through sheer despair :P 18:46:27 <nanonyme> well, I'm in a bus on my way home so I have nothing better to do than be here and vote :) 18:46:36 <Viking-Ice> I'm still at work 18:46:38 <tflink> and it's just proposed - I'd change it if we got enough -1 votes 18:46:45 <Viking-Ice> 18:45 here 18:46:58 <tflink> any other ack/nak/patch? 18:47:27 * adamw puts on a fake moustache and says 'ack' in a bogus accent 18:47:48 <adamw> the man from del monte, he say 'ack' 18:48:05 <tflink> #agreed 848305 - AcceptedNTH - While the most obvious symptom of this bug is cosmetic, it is suspected that there could be other, major problems lurking behind it. A tested fix would be accepted for F18 alpha 18:48:09 <tflink> #topic (856090) ntpd not installed, causes firstboot to hang when user selects "Sync date and time over network" 18:48:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856090 18:48:15 <tflink> #info Proposed NTH, NEW 18:48:34 <adamw> hanging firstboot is pretty crappy, so +1. 18:48:37 <tflink> +1 18:48:43 <nanonyme> +1 18:48:48 <Viking-Ice> +1 18:49:19 <tflink> proposed #agreed 856090 - AcceptedNTH - While not a blocker, firstboot hanging is a problem and a tested fix would be accepted for F18 alpha 18:49:26 <adamw> ack 18:49:30 <Viking-Ice> ack 18:50:01 <tflink> #agreed 856090 - AcceptedNTH - While not a blocker, firstboot hanging is a problem and a tested fix would be accepted for F18 alpha 18:50:11 <tflink> #topic (855784) packagekit waits for authentication forever is user is not in wheel group 18:50:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855784 18:50:17 <tflink> #info Proposed NTH, NEW 18:50:35 <adamw> +1, i guess 18:51:36 <tflink> under the assumption that a non-wheel user is supposed to be able to install updates, +1 18:52:02 <adamw> note that if you have an admin user, it works 18:52:08 <adamw> the non-admin user is prompted for the admin user's password 18:52:22 <adamw> but if there's no admin user, non-admin users should be prompted for root's password, i think, and they aren't... 18:52:46 <tflink> but that's not the bug here 18:52:56 <tflink> at least, not how I'm reading it 18:52:57 * jreznik is having connection issues... 18:53:07 <Viking-Ice> -1 to me this is just an regular bug 18:53:46 <tflink> but either way, PK shouldn't just sit there - either error out or ask for pw 18:54:03 <nanonyme> haven't yet read the bug this is claimed to be duplicate of 18:54:04 <tflink> so we're +2/-1 18:54:29 <Viking-Ice> from my point of view non admin users should not receive update notification in the first place 18:54:34 <adamw> i don't mind a -1, really 18:55:20 <adamw> since we're apparently not caring too much about broken PK anyway, it kinda could be argued that that supports +1 (because who cares if the fix breaks it worse?) or -1 (why try and fix it)? 18:57:05 <tflink> proposed #agreed 855784 - RejectedNTH - While PK shouldn't hang when run by a non-admin user, admin users are able to apply updates without issue. This was not deemed severe enough to accept as NTH for F18 alpha 18:57:09 <tflink> ack/nak/patch? 18:57:15 <Viking-Ice> ack 18:57:19 <jreznik> on live it makes difference, we have running pkgkit there... and one could argue live is that default and we should not care about DVD too much :) 18:57:28 * adamw will ack anything at this point... 18:58:36 <nanonyme> ack though uncertain enough not to vote 18:58:40 <nanonyme> ;) 18:58:47 <tflink> #agreed 855784 - RejectedNTH - While PK shouldn't hang when run by a non-admin user, admin users are able to apply updates without issue. This was not deemed severe enough to accept as NTH for F18 alpha 18:58:57 <tflink> #topic (850783) Font used in F18 grub2 configuration is too large for low resolution displays, makes it effectively impossible to edit entries in VMs 18:59:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=850783 18:59:03 <tflink> #info Proposed NTH, NEW 18:59:25 <tflink> so this is why I can't edit the boot options on a VM 18:59:27 <tflink> +1 nth 18:59:36 <nirik> +1 nth 18:59:41 <Viking-Ice> yup bloddy nuance +1 nth 18:59:42 <nirik> this bug is anoying :) 18:59:43 <nanonyme> +1 19:00:34 <tflink> proposed #agreed 850783 - AcceptedNTH - This bug prevents changing the boot options post-install and can interfere with debugging. 19:00:41 <adamw> ah, sounds like mads has a fix, that's good 19:00:42 <adamw> ack 19:00:48 <Viking-Ice> ack 19:00:49 <adamw> i was kinda struggling with it 19:00:56 <tflink> #agreed 850783 - AcceptedNTH - This bug prevents changing the boot options post-install and can interfere with debugging. 19:01:06 <tflink> #topic (856372) Package selection spoke is not respecting 'optionlist' from comps in F18 Alpha RC2 19:01:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856372 19:01:11 <tflink> #info Proposed NTH, MODIFIED 19:01:36 <jreznik> +1 nth, /me already hit this 19:02:15 <jlk> I submitted a fix upstream for this 19:02:16 * tflink hesitates to take another yum fix considering the fun we've had thus far 19:02:28 <jlk> but I'd only want to see this come in /if/ it's the only change made 19:02:30 <tflink> what else would we be getting with this fix 19:02:42 <jlk> and it only really effects writing /out/ of repodata 19:02:59 <jlk> the yum folks could jsut add this patch to the f18 branch build 19:03:06 <tflink> which means that we wouldn't get the fix unless we slip 19:03:08 <jlk> so this patch and nothing else. 19:03:26 <jlk> tflink: we're re-spinning anyway aren't we? could have a yum build in minutes 19:03:35 <adamw> yes, we need to re-spin 19:03:42 <tflink> yeah but if the problem is in the repo metadata, we'd have to wait for a new mash 19:03:46 <adamw> i'm with jlk: +1 so long as we can get a yum build that *only* changes this 19:03:52 <Viking-Ice> agreed accepted NTH with this patch and nothing else 19:04:13 <tflink> yeah, I'm OK with that - my hesitation was due to not being sure if that's all we'd get 19:04:37 <jlk> of course, there is risk that having /working/ comps data could expose an as of yet unseen anaconda bug in the software selection screen, but.... 19:04:40 <adamw> the procedure for NTH bugs is that accepting them doesn't mean we *have* to take the fix 19:04:47 <adamw> accepting them means we have the option of taking the fix 19:04:58 <adamw> so we can accept this with an explicit note that we intend to pull it only if it's the only change to yum 19:05:17 * nirik nods. sounds good. 19:05:51 <tflink> proposed #agreed 856372 - AcceptedNTH - This causes problems when selecting optional elements to package groups and can't be fixed with an update. A tested yum build with ONLY the fix for this bug would be accepted for F18 alpha 19:05:54 * Martix is back 19:06:05 <Viking-Ice> ack 19:06:13 <jreznik> jlk: then we can have a new anaconda for wipe bug if it's only about build in one minute :) 19:06:29 <jlk> jreznik: no, the solution would be to back out the yum update :) 19:06:30 <adamw> ack 19:06:35 <adamw> right 19:06:46 <adamw> it should be simple enough to smoke test this fast, and yank yum and re-spin if it breaks something 19:07:22 <tflink> I suppose that I could pull it in quick and change the boot.iso I'm waiting on to a full DVD build 19:07:36 <tflink> but a full RC would be a better test 19:07:45 <tflink> #agreed 856372 - AcceptedNTH - This causes problems when selecting optional elements to package groups and can't be fixed with an update. A tested yum build with ONLY the fix for this bug would be accepted for F18 alpha 19:08:27 <tflink> #topic (856086) Anaconda on LiveCD should use window decorations 19:08:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856086 19:08:27 <tflink> #info Proposed NTH, NEW 19:08:33 <tflink> I'd be OK with NTH on this 19:08:42 <tflink> definitely not blocker, but +1 NTH 19:09:34 <Viking-Ice> -1 nth 19:09:52 <Viking-Ice> this is just a regular bug 19:09:58 <adamw> yeah, i'm with viking. 19:10:15 <adamw> the windows of newui don't look particularly like they expect or need to be resized, to me. 19:10:28 <adamw> i don't see the benefit in fiddling with anaconda to fix this at this point. 19:10:28 <tflink> ok 19:10:37 <adamw> jlk: wdyt? 19:10:49 <jlk> you're not going to see a fix for this in alpha 19:10:50 <Viking-Ice> safer to hand them sun glass ;) 19:10:56 <Viking-Ice> mean sun glasses 19:11:19 <tflink> I didn't say that I was expecting a fix, just that I couldn't see a reason to reject a tested fix if it happened 19:12:05 <tflink> proposed #agreed 856086 - RejectedNTH - This is mostly a cosmetic issue and not severe enough to justify taking a fix past freeze for alpha 19:12:09 <msivak> adamw: so firstboot will have the admin checkbox checked in 18.3 which I am building now :) 19:12:14 <Viking-Ice> ack 19:12:15 <jreznik> ack 19:12:28 <adamw> msivak: oh great - i actually just this second did a git pull to try and figure it out myself :) 19:12:28 <jreznik> msivak: hero :) 19:12:40 <adamw> msivak: any fix for the ntp thing? or is that not actually a bug in firstboot? 19:12:45 <adamw> ack 19:12:47 <tflink> #agreed 856086 - RejectedNTH - This is mostly a cosmetic issue and not severe enough to justify taking a fix past freeze for alpha 19:13:00 <tflink> #topic (840160) specifying bootloader --password results in system that won' t boot without the password 19:13:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=840160 19:13:06 <tflink> #info Proposed NTH, NEW 19:14:51 <Viking-Ice> hm wondering if this might be a blocker? 19:15:01 <tflink> not for alpha, I don't think 19:15:09 <tflink> at least not with the current criteria 19:15:46 <jlk> it's a change in behavior between grub and grub2 IIRC 19:16:21 <adamw> it would help to get input from grub devs, yeah... 19:16:25 <adamw> we should probably CC pjones/mads 19:16:27 <tflink> I'm hesitant to take a grub fix this late for something that doesn't violate alpha criteria 19:16:29 <Viking-Ice> -1 nth let's not remotely risk messing with that stuff at this point 19:16:55 <adamw> yeah, that's a good point 19:17:06 <adamw> we learned last release not to take NTH stuff for critical packages lightly 19:17:08 <Viking-Ice> the workaround seems to be dont set "--password" in ks file 19:17:30 <jreznik> -1 nth 19:17:38 <adamw> i guess there's no easy way to achieve the desired result - a password for modifying config, but not just for booting - but that doesn't seem a significant concern for an alpha. 19:17:44 <adamw> you shouldn't need to lock down an alpha install with a password. 19:18:04 <adamw> -1 19:18:43 <jlk> also it's fairly easy to work around, put in hte password :) 19:18:56 <Viking-Ice> if you for some weird reason you do then you just have to run grubpass --> setpassword 19:18:57 <tflink> proposed #agreed 840160 - RejectedNTH - This doesn't even partially violate any of the F18 alpha release criteria, can be worked around by removing the --password option on the bootloader command and would require changes to grub if it was fixed. Deemed too risky for the benefit at this point in the release cycle and rejected as NTH for F18 alpha 19:19:16 <tflink> ack/nak/patch? 19:19:51 <Viking-Ice> ack ( could mention also grubpass --> setpassword ) 19:19:57 <msivak> adamw: what is the bugnumber for the ntp issue? 19:20:38 <nanonyme> ack though I'm still not convinced at this point whether this is a bug at all or not :) 19:21:22 <nanonyme> (as above, checking with upstream imo really necessary) 19:21:34 <tflink> #agreed 840160 - RejectedNTH - This doesn't even partially violate any of the F18 alpha release criteria, can be worked around by removing the --password option on the bootloader command and would require changes to grub if it was fixed. Deemed too risky for the benefit at this point in the release cycle and rejected as NTH for F18 alpha 19:21:44 <tflink> wheee! Done with the proposed NTH 19:21:57 <tflink> anyone still have the energy to go through the accepted blockers? 19:22:38 <Viking-Ice> nah I need to clock out before the alarm system goes on thanks for chairing 19:23:03 <tflink> np, thanks for helping out 19:23:06 <Viking-Ice> later 19:23:07 <nanonyme> chairing is caring, obviously :) 19:23:28 <adamw> msivak: er just a sec 19:23:58 <msivak> adamw: nevermind I found it 19:24:25 <tflink> actually, we only have one non-verified accepted blocker to do 19:24:55 <tflink> let's get 'er done 19:24:57 <adamw> several nth's, though 19:24:59 <tflink> #topic (852403) PolicyKit authentication in Fedora 18 Alpha TC3 results in selinux denial 19:25:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=852403 19:25:05 <tflink> #info Accepted Blocker, MODIFIED 19:26:01 <adamw> i'm okay with pulling latest selinux-policy for this. 19:26:03 <tflink> looks like a new build is available - needs testing and verification 19:26:15 <adamw> after alpha they only ever relax restrictions in selinux-policy, never tighten them, so it's usually safe and a good idea to pull the latest. 19:26:33 <tflink> #info selinux-policy-3.11.1-18 is now available and should fix this bug 19:26:49 <tflink> #undo 19:26:49 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x180ad550> 19:27:12 <tflink> #info selinux-policy-3.11.1-18 is now available and should fix this bug. It needs to be pulled into the next spin and tested 19:27:27 * jreznik confirms the fix 19:27:53 <msivak> adamw: it is system-config-date's fault, firstboot only includes that screen 19:28:00 <tflink> ok, that would be all of the accepted blockers for now 19:28:01 <jreznik> dan was probably right we should always take the latest one 19:28:11 <adamw> msivak: ok. 19:28:39 <tflink> adamw: did you want to review the accepted nth? 19:28:49 <adamw> no, sorry, i was misunderstanding your comment 19:28:59 <adamw> thought you were talking about what was needed for rc3 19:29:29 <tflink> ok, I misunderstood 19:29:35 <tflink> #topic Open Floor 19:29:55 <tflink> only 3.5 hours ... 19:30:03 <adamw> hey, not bad. 19:30:04 <tflink> any other topics to bring up? 19:30:41 <msivak> adamw: firstboot-18.3 built for f18-candidate so it is in QA's hands now 19:31:03 <jreznik> msivak: thx 19:31:06 <tflink> #info blocker tracking app update work is going on - feedback on changes would be appreciated 19:31:12 <tflink> #link http://lists.fedoraproject.org/pipermail/test/2012-September/109995.html 19:31:54 <adamw> msivak: can you submit it as an update too? 19:32:00 <adamw> msivak: i could do that, but then i couldn't give it karma 19:32:08 <adamw> mark it as fixing 856194 19:32:14 <Martix> msivak: nice 19:32:25 <tflink> #info if F18 alpha slips again, the next blocker review meeting will be 2012-09-19 @ 16:00 UTC 19:33:49 <Martix> I hope not slip again 19:33:57 <adamw> me too... 19:34:17 <Martix> many test days starts next week 19:34:19 <tflink> if there's nothing else ... 19:34:28 * tflink sets fuse for [0,5] minutes 19:34:37 <Martix> *bang* 19:35:03 <jreznik> btw. what everything we need to make it tmrw? rc3, testing - kparal, are you still here? we will need heroes tmrw, anything else? 19:35:16 <adamw> Martix: actually a lot of test days want to re-schedule for later, i need to sort that out once rc3 is done 19:35:31 <adamw> jreznik: we should be able to spin rc3 more or less now, i'll work on that next 19:35:34 <zodbot> Ticket notification - f18alphanicetohave: [Bug 856194] firstboot has to insist the first user is admin when root account is locked <https://bugzilla.redhat.com/show_bug.cgi?id=856194> 19:35:35 <adamw> then we just need to do the testing by tomorrow 19:35:54 <adamw> doing all the alpha testing in 24 hours isn't actually too hard since we have good timezone coverage and the alpha test set is a lot smaller than beta/final 19:36:00 <adamw> doing it for final is much tougher, though we can. 19:36:02 <jlk> I can probably pitch in on some of the testing 19:36:04 <tflink> the boot.iso build with the new nm is done 19:36:34 <Martix> jreznik: unfortunatelly I'll unavailable tomorrow 19:36:56 <jreznik> adamw: ok, please take care of our "night shift", I'll take care of the day :) 19:37:06 <adamw> =) thanks 19:37:34 <msivak> adamw: sure, as soon as I reset my fedora password.. 19:37:44 <adamw> msivak: thanks 19:38:48 <tflink> OK, thanks for coming everyone! 19:38:55 * tflink will send out minutes shortly 19:38:57 <tflink> #endmeeting