17:01:01 #startmeeting f17-final-blocker-bug-review-1 17:01:01 Meeting started Fri Apr 20 17:01:01 2012 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:01 #meetingname f17-final-blocker-bug-review-1 17:01:01 The meeting name has been set to 'f17-final-blocker-bug-review-1' 17:01:06 #topic Roll Call 17:01:34 * brunowolff is here 17:01:39 who's ready for the wonderful fun that is the first final blocker review meeting 17:02:09 At least I don't have to worry about taxes this weekend. I might actually get some Fedora stuff done. 17:04:12 I'm just glad that I remembered to do mine - I didn't even think about it until last friday 17:04:17 * satellit_Tris55R listening 17:04:30 satellit_Tris55R: welcome to the party 17:04:51 : ) 17:06:11 any volunteers to play secretary? 17:08:15 * tflink is still waiting for enough people to have a quorum 17:09:07 hello 17:09:23 zaza224_: hello. you here for the blocker review meeting? 17:10:22 I am 17:10:27 no, I just dropped in to see what was happening; I thought the meeting started at 21:00 17:10:35 other than brunowolff, is anyone planning to vote? It sounded like most of the people are planning to be mostly lurking 17:11:08 I plan to vote, but could get interrupted since I'm at work. 17:11:21 yo 17:11:26 i'm votin' 17:11:38 adamw: I was wondering where you went :) 17:11:59 i was trying to send you that email 17:12:03 fighting the vagaries of gpg 17:13:11 well, I suppose we should get started. if we lose quorum, we'll just have to start hunting down more people to help :) 17:13:47 still don't have a volunteer to be secretary, though 17:13:55 What does that involve? 17:14:30 Octayn: translating the decisions made here to bz (modifying the whiteboard and providing a summary of the decision) 17:15:26 #topic Introduction 17:15:41 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 17:15:57 We will be following the list of current blockers at: 17:16:03 I'm still a newb but I can do it if you hold my hand a little 17:16:10 #link https://fedoraproject.org/wiki/Current_Release_Blockers 17:16:40 The process for the meeting is outlined at: 17:16:43 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:17:02 And the release criteria for F17 are found at: 17:17:05 #link https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria 17:17:12 #link https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria 17:17:14 Wow, this is going to be a long meeting I think. 17:17:16 #link https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria 17:17:21 brunowolff: no kidding 17:17:29 up for review today are: 17:17:37 #info 31 proposed blockers 17:17:37 #info 5 accepted blockers 17:17:37 #info 10 proposed NTH 17:17:38 tflink: i didn't catch up with secretaryizing the LAST meeting yet :/ 17:17:42 i'll do this one as we go along. 17:17:44 oh holy shit. 17:18:26 Octayn: do you have access to the whiteboard in BZ? I don't think that we ever got the wider bz permission thing figured out 17:18:47 adamw: yeah, I'm regretting skipping the meeting last week 17:18:57 but this list has been pretty long for a while 17:19:12 unless there are any objections, I'm going to start with the proposed blockers 17:19:21 tflink: I don't believe so 17:20:02 go for it 17:20:07 tflink: i'll do the secretarying 17:20:18 adamw: thanks 17:20:46 Octayn: if you're interested in helping, we can get you the appropriate bz permissions after the meeting 17:20:56 tflink: sure, thanks! 17:21:05 diving in ... 17:21:08 #topic (755335) Shutting down while auto-updating breaks the system 17:21:08 #link http://bugzilla.redhat.com/show_bug.cgi?id=755335 17:21:08 #info Proposed Blocker, NEW 17:21:24 Octayn: if you want to see what the secretaryization stuff looks like, just keep an eye on the bugs we discuss - look at each one a few minutes _after_ we finish discussing it and you should see a comment and a couple of changes to the blocks: and whiteboard: fields from me 17:22:12 this one seems nasty. 17:22:13 hrm, this sounds kind of nasty but I don't think it directly hits any of the release criteria 17:22:23 when did we switch to auto-installing updates? 16? 17:22:34 I didn't think we had switched to that 17:22:38 final, 15: "All known bugs that can cause corruption of user data must be fixed or documented at Common F17 bugs" 17:22:48 maybe a bit of a stretch, _probably_ can't hit that 17:22:57 tflink: we auto-install security updates 17:23:32 look at 'software settings', the box marked 'Automatically install:' - it's set by default to 'Only security updates', it was changed in 15 or 16 or so 17:24:02 hrm, I guess that i've never noticed 17:24:10 then again, I tend to avoid PK 17:24:38 well, you can't really 'avoid' this, it just sort of happens 17:24:50 (unless you remove packagekit, of course.) 17:25:27 it's easy not to actually notice it happening, though, it doesn't really tell you what it's doing. sometimes when PK is blocking yum, it's because it's installing updates. hey, actually, i wonder if this is the cause of that bug about PK blocking yum 'too much'. 17:25:48 that would fit 17:25:54 how about alpha "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"? 17:26:05 if you hit this bug, it can leave the rpm/yum database screwed, no more installing updates... 17:26:26 The issue itself is fixable in an update. I am thinking this isn't a blocker. 17:26:27 yeah, I think that I'm +1 blocker on this even if we have to shoehorn it in a bit 17:26:52 brunowolff: that is a consideration, but it does seem like anyone doing an install from DVD has a reasonable chance at hitting this 17:27:08 do a DVD install, boot the installed system up, click around a bit, (auto-update happens to kick off in background), shutdown, boom 17:27:36 Would using smaller transactions with rollbacks on shutdown help mitigate this? 17:27:44 Or is changing the transactions not something that can happen. 17:27:55 Is this a regression from how things have been in the past? 17:28:14 Octayn: I doubt that would happen this late in the release but that sounds like a possible solution 17:28:16 i don't think we know that 17:29:05 it sounds like we're at ~ +2/-1 ATM 17:29:08 any other thoughts? 17:29:22 brunowolff: the fact that we didn't do auto-update until f15 is significant, though 17:30:14 if this has been possible for ~ 1 year and this is the first report, that says something for how common it is, though 17:30:33 the bug was reported against 16 in november 17:30:49 kparal's 'colleague' hit it and then kamil reproduced it and nominated it as blocker last week 17:30:55 so that's three occurrences (one intentionally produced) at least 17:30:57 ah, I missed that part 17:31:25 other people may well have hit it and not known what happened - it's a long way from 'i rebooted and now my system doesn't seem to be working quite right' to 'hey, i must have shutdown while an automatic update was happening' 17:31:37 especially since we don't give the user any info that an automatic update is happening... 17:31:40 also true 17:31:53 It may also be that most of the time a busted transaction doesn't hose the machine. 17:32:01 since we don't triage every bug filed, it's hard to know if there are other filed bugs which actually were caused by this. 17:32:02 brunowolff: yup 17:32:12 or at least some of the time. 17:32:25 proposed #agreed - 755335 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops 17:32:38 ack/nak/patch? 17:32:45 ack 17:33:06 I'm a pretty weak -1, so I don't object to being outvoted and will ack the proposal. 17:33:27 i'd be open to changing to -1 if we get info from dan that this isn't as bad as it sounds, of course. 17:33:35 same here 17:33:55 #agreed - 755335 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops 17:34:08 #topic (810530) PackageKit locks out yum way too often & for too long 17:34:08 #link http://bugzilla.redhat.com/show_bug.cgi?id=810530 17:34:08 #info Proposed Blocker, ASSIGNED 17:35:13 I'm not sure this is so much a blocker as it is a feature request 17:36:13 I think it's worse in F17 but I've hit this in F15 and F16, too 17:36:17 I'm -1 blocker, though I will admit I don't like auto updates and disable them myself. 17:36:25 possibly earlier releases that I'm not remembering off hand 17:36:49 I think that I'm -1 blocker, -1 NTH 17:37:15 I think the kind of people that manually run yum to do updates, should be able to turn off or slow down automatic updates. 17:37:18 less -1 blocker than I am -1 NTH, though. This doesn't seem like something that we should be changing post-freeze unless it's a blocker 17:37:34 yeah, my usual workaround is to kill the pk process 17:38:35 Octayn: if you look at the previous bug now, you can see the 'secretaryization' changes 17:38:35 tflink: if i'm right, the auto-security updates may explain this 17:38:49 it would explain why it seems 'worse' lately 17:39:00 we've had the repos frozen for like a month because of beta delays 17:39:08 so there are probably a pile of updates in updates-testing marked as 'security' 17:39:18 proposed #agreed - 810530 - RejectedBlocker RejectedNTH - While an annoyance, this doesn't hit any of the F17 release criteria and doesn't seem wise to take as an NTH fix 17:39:27 so shortly after a new f17 beta install, you'll presumably have a fairly long-running PK process in the background installing security updates... 17:39:34 i'm guessing that's what a lot of people have seen. but i'm not sure. 17:39:53 i think ack...this one _does_ seem like it could be fixed with updates, too. 17:40:01 ack 17:40:11 #agreed - 810530 - RejectedBlocker RejectedNTH - While an annoyance, this doesn't hit any of the F17 release criteria and doesn't seem wise to take as an NTH fix 17:41:28 For anyone who's interested/new - if you have any questions about the process we're going through, feel free to ask. We like new people :) 17:41:38 #topic (737508) grub2 cannot install when /boot is md and first partition starts at sector 63 17:41:41 #link http://bugzilla.redhat.com/show_bug.cgi?id=737508 17:41:44 #info Proposed Blocker, NEW 17:44:13 i'm still -1 on this one, even with kparal's new reasoning. 17:44:24 we just can't do enough to 'mitigate' this to make it reasonably release-blocking. 17:44:25 * tflink is still wading through the comments 17:44:52 tflink: you probably only really need #56. 17:46:22 yeah, I'm not sure about blocker on this 17:46:42 putting /boot in LVM is non-default, no? 17:46:48 yeah. 17:47:07 i'd want to consider the windows criterion as a very narrow one 17:47:12 then I'm a weak -1 on this 17:47:21 it's too much of a corner case 17:47:26 as long as we possibly _can_ get dual boot to work, that's good enough. we really can't go around trying to support every possible dual-boot permutation. 17:47:43 agreed 17:48:42 proposed #agreed - 737508 - RejectedBlocker - While this bug does affect dual-booting with windows - it's using a non-standard partition layout and was deemed too much of a corner case to take this as a blocker 17:48:46 ack/nak/patch? 17:49:48 Does this actually break existing setups, or just fail to install? I tried quickly reading through the bug, but it had a lot of notes and took a few twists. 17:50:10 yeah, it sounds like there was some confusion in the middle there 17:50:13 ack 17:50:29 as I'm understanding it, the windows install would still work but the linux partition would be fubar 17:50:37 s/partition/install 17:50:52 If it is just fails to install, I don't think it is a blocker. 17:50:57 or would the whole thing be fubar if you're using grub to chainload windows 17:51:21 this should probably be documented, though 17:51:35 do you have to do a custom layout if you're installing alongside windows? 17:52:05 brunowolff: i think in most cases it shouldn't. it _might_ cause problems on upgrade, but even then, the old grub should usually work. 17:52:06 the ultimate upshot of the bug is grub2 doesn't get installed to the MBR, but it shouldn't result in whatever was there previously being wiped. if what was there before was the Windows bootloader, I can't see why it wouldn't continue to work. 17:52:53 ack (the proposal) 17:53:08 #agreed - 737508 - RejectedBlocker - While this bug does affect dual-booting with windows - it's using a non-standard partition layout and was deemed too much of a corner case to take this as a blocker 17:53:14 tflink: no, you don't. 17:53:39 ok, I can't dual-boot on my current machine and I hadn't done it in a while 17:53:49 tflink: if you know what you're doing, you resize the windows partition ahead of time so there's free space, or just leave free space when installing windows in the first place 17:53:49 #topic (748209) KeyError: '/boot/efi': anaconda will try to do an EFI install if there is an existing EFI system partition but it has not been set as /boot/efi 17:53:52 #link http://bugzilla.redhat.com/show_bug.cgi?id=748209 17:53:54 #info Proposed Blocker, ON_QA 17:54:04 then you can tell anaconda 'use free space' and it'll do a typical fedora filesystem layout - separate /boot, LVM root and /home - in the free space 17:54:18 adamw: yeah, I usually install windows first in a limited area and install fedora in the remaining free space 17:54:19 if you don't know what you're doing, you can try and resize NTFS partition during install, which also isn't 'custom layout; 17:54:34 either of those ought to work, from the standpoint of this bug anyhow. 17:54:36 oy, 3 bugs in 45 minutes ... nice and fast :) 17:54:54 :/ 17:54:59 -1 on this. too corner case-y. 17:55:18 oh, actually. hold that. 17:55:42 humph. i am in two minds, apparently. =) 17:56:00 so...it's bad form, like i said in my proposal. but it's probably not really serious enough to be blocking. 17:56:29 it'll be fixed ahead of freeze anyway, so kinda academic. i either withdraw the proposal or vote -1, whichever. 17:56:30 maybe more so as we get more uEFI systems but right now, I agree 17:56:48 It looks like there is already a fix, too? 17:56:54 you still have to be installing alongside a native EFI install of something else and do something 'wrong' (though easy to get wrong) in manual partitioning to hit this. 17:57:09 actually, you're probably more likely to get it wrong than right. but still, meh. 17:57:24 * adamw goes to lay in some beer 17:57:41 proposed #agreed - 748209 - RejectedBlocker - This is too much of a corner case to block release for. Making a mistake in custom partitioning is required in order to hit this and it only affects EFI systems with pre-existing installs 17:57:45 I'm leaning -1, but since its academic, I don't think we need to spend too much time on this one. 17:57:52 ack 17:58:05 on a related note, I'm wondering if we should do a test image w/ the new anaconda 18:00:01 #agreed - 748209 - RejectedBlocker - This is too much of a corner case to block release for. Making a mistake in custom partitioning is required in order to hit this and it only affects EFI systems with pre-existing installs 18:00:07 back 18:00:12 #topic (784828) boot option 'noselinux' doesn't work 18:00:12 #link http://bugzilla.redhat.com/show_bug.cgi?id=784828 18:00:12 #info Proposed Blocker, ASSIGNED 18:00:46 Is it broken in F16 too? 18:01:02 -1 blocker. You can use selinux=0 as a work around. 18:01:15 warren: I don't think so, I believe this was due to noloader 18:01:40 If fact Will's comment suggests that people should be usning selinux=0 inpreference to noselinix. 18:01:41 brunowolff: does that actually work for installing w/o selinux? 18:02:18 I read that as "this might change to selinux=0 in the future" rather than "it works today" 18:02:31 I am not sure. The bug said using selinux=0 worked, but maybe this was in a different place? 18:03:05 * tflink missed that line - needs to start reading more slowly 18:03:23 yeah, I'm probably -1 blocker on this too 18:03:39 * adamw seems to recall we have a criterion about this, don't we? 18:03:57 I don't see it for F17, though 18:04:03 I remember it for F16 18:04:53 the one I was thinking of was for F16 final - "The installed system must run normally if the user chooses to install without SELinux " 18:05:02 not quite what is here, though 18:05:26 yeah 18:05:32 and if there's a parameter that works anyway...-1 18:05:44 proposed #agreed - 784828 - RejectedBlocker - There are no release criteria around being able to install w/o SELinux and using 'selinux=0' is an acceptable workaround 18:05:51 ack 18:07:05 ack 18:07:18 #agreed - 784828 - RejectedBlocker - There are no release criteria around being able to install w/o SELinux and using 'selinux=0' is an acceptable workaround 18:07:32 #topic (790348) If specified repo= doesn't contain package repository, fall back to default online repos 18:07:35 #link http://bugzilla.redhat.com/show_bug.cgi?id=790348 18:07:38 #info Proposed Blocker, NEW 18:09:48 so afaict this is the bug for 'you can't specify an incomplete repo with repo=', basically 18:09:57 sounds like a pretty clear blocker with the new criterion 18:10:11 you should be able to specify a repo which only has squashfs.img in it, and pull packages from somewhere else. or a repo which has a few packages in it, and pull the rest of the packages from somewhere else. but you can't. 18:11:26 so i'm +1, i think. 18:11:39 +1 blocker 18:12:23 proposed #agreed - 790348 - AcceptedBlocker - It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to r 18:12:31 ack 18:13:10 ack 18:13:17 #agreed - 790348 - AcceptedBlocker - It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to run. 18:13:20 wow, this is some nice beer. 18:13:23 #topic (800609) maximum window size is 800x600, should be full screen 18:13:26 #link http://bugzilla.redhat.com/show_bug.cgi?id=800609 18:13:28 #info Proposed Blocker, MODIFIED 18:13:52 not sure this is a blocker 18:14:10 -1 blocker, but it seems to have a fix, so i won't fight hard. 18:14:53 proposed #agreed - 800609 - RejectedBlocker - This doesn't prevent the installer from functioning and doesn't hit any of the F17 release criteria 18:15:36 ack 18:15:43 What are the criterion for a NTH? 18:15:54 bcl proposed it as a blocker 18:16:01 so i'd probably want to at least ask him why... 18:16:08 * adamw doesn't feel like he understands the bug entirely 18:16:44 shouldn't this be closed anyhow? 18:16:54 Octayn: there aren't many formal requirements around NTH, mostly that it would be impossible/difficult to fix with an update in addition to having enough impact to justify breaking freeze for a fix 18:17:19 I'm not authorized to view the referenced bug. 18:17:22 the blocker bugs for the non-primary DEs (XFCE, Sugar etc.) fall into this 18:18:02 referenced bug? 18:18:17 750764 18:18:23 nvm, I was looking at the wrong bug 18:18:25 bug 750764 18:18:32 brunowolff: it's a RHEL bug. i can't see any particular reason it's marked as confidential. it's just about bad handling of dual displays. 18:18:48 I thought that we had a fedora bug about that, anyways 18:19:02 I was wondering if it had more info on how fixed this actually is now? 18:20:33 800609 can be closed, according to bcl. 18:20:34 so move on. 18:20:40 whatever it was, it's in anaconda now. =) 18:21:05 * adamw closes bug 18:21:09 ack 18:21:10 yay for not knowing what's going on! 18:21:13 yay 18:21:17 now you know how i feel all the time! 18:21:40 #info 800609 has been fixed and closed - it doesn't need to be evaluated as a blocker any more 18:21:58 adamw: it doesn't matter if you know what you're doing ... as long as it looks like you do :) 18:22:13 #topic (804846) dracut fails to retrieve network kickstart file, possibly PXE-specific, timing issue 18:22:16 tflink: words to live by! 18:22:17 #link http://bugzilla.redhat.com/show_bug.cgi?id=804846 18:22:19 #info Proposed Blocker, NEW 18:22:50 I have yet to hit this in my PXE testing 18:23:32 and I'm wondering if this is related to the PXE+incomplete repo thing 18:24:17 i don't immediately see how, he seems to be using public repos 18:24:26 This one sounds intermittant, which would be different. 18:24:30 method=http://fedora.cora.nwra.com/development/17/x86_64/os/ 18:24:54 and k.wic used dl.fedoraproject.org 18:24:56 The later comments suggest a problem with network setup. 18:26:22 those options look funny, though 18:26:52 do we have any docs on how the anaconda options are changing? 18:27:00 method= is a synonym for repo=, iirc 18:27:15 https://fedoraproject.org/wiki/Anaconda/Options 18:27:15 I was looking at the inst.repo and inst.ks 18:27:26 should be functionally identical to repo= and ks= 18:27:36 wwoods wants them all to be prefixed with inst. in future, for some reason. 18:27:44 _should_ - sure but is it? 18:28:21 er, i think so. =) 18:28:35 could just be some kinda timing thing? 18:28:39 * adamw has no handle on this. 18:29:09 yeah, it might be timing or some other obscure thing w/ dracut 18:29:39 it seems ironic to me that we moved to systemd to get away from obscure shell magic yet we seem to be diving head first into dracut 18:30:11 punt until we have more data? 18:30:29 just because I'm not seeing this doesn't mean that it isn't a bug or a blocker 18:30:45 the confusion around new args for noloader isn't helping 18:31:17 an interesting difference - I'm not using hostnames, just straight ipv4 18:31:24 yeah, maybe try and get everyone to test with as close as possible to the same setup as possible and see what happens 18:31:36 IPs? 18:31:37 interesting 18:31:50 could be a nameserver issue 18:32:31 proposed #agreed - 804846 - We need more data on this before voting on it - it would be nice if the reporters could all test with as close to the same setup as possible 18:33:53 ack 18:34:18 ack 18:34:23 #agreed - 804846 - We need more data on this before voting on it - it would be nice if the reporters could all test with as close to the same setup as possible 18:34:34 #topic (806931) "network --device link --activate" in kickstart inside initrd.img breaks anaconda 18:34:37 #link http://bugzilla.redhat.com/show_bug.cgi?id=806931 18:34:39 #info Proposed Blocker, ASSIGNED 18:35:30 I think this is already accepted 18:35:58 nvm, I spoke too soon 18:36:43 yeah...we don't have a criterion that covers kickstart contents, really 18:36:51 it seems like a tricky area 18:37:53 so..it seems like the bug here is 'if you use ks=file:/blah.cfg and specify network --device link --activate in the kickstart file, you get trouble' 18:37:58 if the kickstart doesn't have that line you're okay 18:38:11 if the kickstart has that line but you source it via http or nfs you're okay 18:38:13 doesn't that suggesst that the syntax is invalid? 18:38:18 oh 18:38:19 no, it's valid syntax. 18:39:41 with the criteria written as is, I'm -1 on this 18:40:53 Since there are easy work arounds, I am -1 blocker. 18:41:17 i'm with tflink..as things stand we don't cover this, but, maybe we want to. 18:41:29 define workarounds - I don't think there is one for the install automation that hits this regularly 18:41:57 adamw: the problem in my mind is how to phrase it. If we have a release criterion for anaconda syntax, that implies that we need to test everything 18:42:36 yeah, it's a tricky area. 18:42:40 either way, not a discussion we need to have here, I think 18:44:18 proposed #agreed - 806931 - RejectedBlocker - This does not hit any of the release criteria as currently written - if the criteria change to make this a blocker, please re-propose 18:45:31 ack 18:45:55 Why is secratarying needed? it seems the meetbot stuff is pretty consistent, is there something particularly bad about having an automated script do it? 18:46:05 #agreed - 806931 - RejectedBlocker - This does not hit any of the release criteria as currently written - if the criteria change to make this a blocker, please re-propose 18:46:16 Octayn: someone would have to write the code to go through and make the changes 18:46:29 it's been on my list of stuff to do for a while but I've never gotten around to it 18:46:51 * Octayn can write code, what would it be an extension to meetbot? 18:47:15 Octayn: i think it would be better as a standalone script since bugzilla logins would be needed 18:47:46 #topic (811242) PXE and repo=nfs or repo=nfsiso freezes installer 18:47:46 #link http://bugzilla.redhat.com/show_bug.cgi?id=811242 18:47:46 #info Proposed Blocker, NEW 18:49:15 this does seem like a pretty clear blocker with the new criterion 18:49:24 seems like it... 18:49:27 have you reproduced this 18:49:28 ? 18:49:46 proposed #agreed - 811242 - AcceptedBlocker - It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to r 18:49:52 adamw: haven't tried, to be honest 18:50:03 all my PXE testing has used http sourced repos 18:50:47 my nfs setup is currently borked and I haven't spent the time to fix it 18:51:10 ack 18:51:34 tflink: ping me about it later; I have free time 18:51:50 Octayn: will do, I'd love to see more of this automated :) 18:52:22 ack then 18:52:23 #agreed - 811242 - AcceptedBlocker - It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to run. 18:52:36 #topic (814643) "Words" corrupting (all) odt documents. 18:52:37 #link http://bugzilla.redhat.com/show_bug.cgi?id=814643 18:52:37 #info Proposed Blocker, MODIFIED 18:53:30 I don't think this is a blocker 18:53:41 just got pulled in due to the kde blocker bug 18:53:46 -1 blocker, -1 NTH 18:54:31 well, it could hit "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" 18:54:43 since I think this part of the default KDE install 18:55:50 yeah, that's probably why it's on there 18:56:00 kde team only put stuff on KDEBlocker that they genuinely consider worthy of blocking release 18:56:24 and it sounds like this is worthy if I'm understanding everything correctly 18:56:27 i think 'calligra' is what koffice turned into 18:56:38 yeah, I think I'm +1 here - this sounds like it can corrupt user data on a blocking spin, not good 18:57:01 I have been convinced to switch to +1 blocker. 18:57:09 * tflink is +1 after thinking it through completely 18:57:49 proposed #agreed - 814643 - AcceptedBlocker - Violates the following F17 final release criteria "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" for KDE 18:57:54 ack 18:58:32 #agreed - 814643 - AcceptedBlocker - Violates the following F17 final release criteria "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" for KDE 18:58:37 #topic (802381) Port Printers panel to FirewallD1 API 18:58:39 #link http://bugzilla.redhat.com/show_bug.cgi?id=802381 18:58:42 #info Proposed Blocker, MODIFIED 18:59:12 has there been any movement on whether firewalld was going to be backed out for F17? 18:59:43 sounds like there is a fix for this, though 19:00:17 it's on the next fesco meeting agenda 19:00:43 this obviously has more import if we keep firewalld as default, but even in that case i'm -1, i think 19:01:07 it's annoying, but doesn't hit any criteria (we don't cover printing) and can be fixed in an update 19:01:14 very true 19:01:42 proposed #agreed - 802381 - RejectedBlocker - This doesn't hit any release criteria for F17 and could be fixed with an update 19:02:08 ack 19:03:05 #agreed - 802381 - RejectedBlocker - This doesn't hit any release criteria for F17 and could be fixed with an update 19:03:08 #topic (748920) Setting back time breaks boot 19:03:11 #link http://bugzilla.redhat.com/show_bug.cgi?id=748920 19:03:13 #info Proposed Blocker, NEW 19:03:57 as much as these tend to suck, I'm not sure about blocker 19:04:33 sorry i'm a bit behind, catching up with secretarying 19:05:29 yeah, I'm -1 blocker on this. it does 19:05:42 't hit any criteria that I can think of and could be fixed w/ update 19:06:39 well, it's a conditional breakage of the 'system must boot' criterion 19:06:43 if your system clock is off, it doesn't 19:06:52 i'm not a clear -1 on this to be honest, it is a pretty crappy breakage 19:06:54 if your system clock changes, you mean 19:07:14 this has been fixed for the liveinstall case 19:07:16 yeah 19:07:22 there do seem to be quite a few people who've hit this 19:07:30 and the only way you could hit this AFAIK is to change your system clock 19:07:39 which is kind of stupid 19:07:43 the bug, I mean 19:08:26 if we couldn't fix w/ updates, I'd be more +1 on this 19:08:51 mm... 19:10:03 i guess i'm +/-0 19:10:07 do we have any votes in the bug? 19:10:25 I think that it's pretty safe to say that kamil is +1 19:10:37 doesn't look like it 19:10:54 note https://bugzilla.redhat.com/show_bug.cgi?id=798328 influences this 19:11:01 as at present we have no rescue shell for you to run fsck from 19:11:07 or something. 19:11:27 I'm more +1 blocker on that one 19:11:32 how about we punt this till a meeting where we have more representation? 19:11:49 we don't have any devel/fpl/releng representation here, so i'm uncomfortable about making any controversial calls 19:11:50 yeah, it's hard to do this with just 2 of us 19:11:59 I am slightly -1 on this. I don't think it happens in enough cases to block the release. 19:12:22 brunowolff: how are you on punting? :) 19:12:50 proposed #agreed - 748920 - We need more information and opinions from devel before making a decision on this since it's not a clear violation of criteria but is still an ugly failure mode 19:12:58 Footballs or the decision? 19:13:12 ack 19:13:33 #agreed - 748920 - We need more information and opinions from devel before making a decision on this since it's not a clear violation of criteria but is still an ugly failure mode 19:13:39 brunowolff: footballs, of course :) 19:13:49 I suck at punting footballs. 19:13:54 #topic (808759) firewall-applet - Icon could not be loaded 19:13:54 #link http://bugzilla.redhat.com/show_bug.cgi?id=808759 19:13:54 #info Proposed Blocker, MODIFIED 19:15:40 isn't this a rehash of the firewalld-has-no-gui issue? 19:15:54 if so, I'm +1 on punt until FESCo decides on firewalld 19:15:55 Is there a criteria on running gui apps from a terminal session? 19:16:38 not that I'm aware of, no 19:16:49 no, it's not about has-no-gui 19:17:03 it's about the applet having no icon unless you have system-config-firewall installed, i think 19:17:14 an applet with no icon is very difficult to distinguish from a non-existent applet =) 19:17:32 i'm not sure the s-c-f thing is even true, but i'm not at my desktop so i can't check. 19:17:48 would this hit "All Applications listed in the system menus (or equivalent) must have icons which have a consistent appearance and sufficiently high resolution to avoid appearing blurry", then? 19:17:57 no 19:17:59 that's about the menus 19:18:10 if it hits anything it's "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use " 19:18:27 if systemd is default then its applet is part of the default panel configuration, and if it's invisible that's not 'functioning correctly'... 19:18:46 systemd? 19:19:23 +1 blocker. But the bug claims there is a fix, so it's probably not a big deal either way. 19:20:00 (Assuming they get an upstream update soon.) 19:20:02 er, firewalld. 19:20:04 proposed #agreed - 808759 - AcceptedBlocker - Violates the following F17 final release criterion: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use" 19:20:07 ack 19:20:11 ack 19:20:18 #agreed - 808759 - AcceptedBlocker - Violates the following F17 final release criterion: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use" 19:20:35 #topic (814696) When installing, after reboot only black screen with "X" cursor shows up instead of firstboot 19:20:38 #link http://bugzilla.redhat.com/show_bug.cgi?id=814696 19:20:40 #info Proposed Blocker, NEW 19:21:48 hard to vote on w/o root cause 19:22:23 ask for more info/testing and vote on next week, I think 19:22:36 this could be any number of things but does sound blocker-ish 19:22:56 problem with firstboot using kwin? 19:23:04 you'd think it'd affect any kde-only install... 19:23:08 I'm +1 blocker if this impacts most KDE users. 19:23:21 but i'm pretty sure i tested that with beta and didn't see it. 19:23:28 damn, wish i was on my desktop. 19:23:29 same here 19:23:36 There was a recent firstboot update. 19:23:49 I can re-test 19:23:52 report says "Fedora 17 Beta" 19:23:57 i.e. not a nightly 19:24:04 and they used live image, so no network repos 19:24:19 but the dualboot part could be causing problems 19:24:20 i guess i'm voting 'punt, investigate further' 19:24:23 i don't see how 19:24:32 just looking at how its different 19:24:59 proposed #agreed - 814696 - We need more information and re-testing on this before deciding on blocker status 19:25:05 ack 19:25:35 I looked at the firstboot rpm changelog and didn't see anything that looked like a fix for this. 19:25:45 ack 19:25:48 #agreed - 814696 - We need more information and re-testing on this before deciding on blocker status 19:25:58 brunowolff: it was just reported earlier today, though 19:26:12 #topic (814220) Logomarks should be removed and replaced with text 19:26:12 #link http://bugzilla.redhat.com/show_bug.cgi?id=814220 19:26:12 #info Proposed Blocker, MODIFIED 19:27:15 I have no idea where this falls wrt legal 19:27:33 -1 blocker, +1 NTH 19:27:39 Is this package in the default install? 19:27:54 good question, I doubt that it's on the dvd 19:28:12 but if its a legal issue, I imagine that releasing with the logos in a bad state would be unacceptable 19:28:29 If not, then -1 blocker, -1 nth. 19:29:19 -1 blocker, legal issues aren't covered by this process. 19:29:30 as i read it, anyway, this is a case of trying to make things nicer for re-use of fedora 19:29:42 we aren't going to get into legal trouble with anyone _else_ for using our own logos in the product, afaict. 19:30:06 proposed #agreed - 814220 - RejectedBlocker - The blocker process does not cover legal issues 19:30:10 oh 19:30:17 unless it's talking about other distros' logos. but, eh. 19:30:18 ack 19:30:55 ack 19:30:57 #agreed - 814220 - RejectedBlocker - The blocker process does not cover legal issues 19:31:10 #topic (803434) [swell-foop] Help -> Content function is broken 19:31:11 #link http://bugzilla.redhat.com/show_bug.cgi?id=803434 19:31:11 #info Proposed Blocker, ASSIGNED 19:31:43 this has been reported to be fixed 19:31:53 waiting for the fix to go to stable before closing 19:32:52 which it hasn't yet 19:32:57 pending push to stable 19:34:23 proposd #agreed - 803434 - AcceptedBlocker - Violates the following F17 final release criterion: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use." 19:34:54 huh. my name resolution seems to be playing up. 19:34:59 but ack. 19:35:10 name resolution? 19:35:18 #agreed - 803434 - AcceptedBlocker - Violates the following F17 final release criterion: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use." 19:35:30 #topic (799667) [abrt] gnome-settings-daemon-3.3.90.1-1.fc17: g_logv: Process /usr/libexec/gnome-settings-daemon was killed by signal 5 (SIGTRAP) 19:35:33 #link http://bugzilla.redhat.com/show_bug.cgi?id=799667 19:35:36 #info Proposed Blocker, NEW 19:36:24 tflink: this chat is working, but i can't seem to resolve any addresses. odd. 19:37:04 oh, vpn connection died. sigh 19:38:16 so this one causes GNOME to fail to start up if certain wacom tablets are connected, IIRC. 19:38:32 i'm trying to remember if we ever precisely isolated the conditions to reproduce, i talked to olivier about it quite a bit. 19:38:33 * adamw checks logs 19:38:36 How common our those? 19:38:37 that seems clear blocker to me 19:38:50 brunowolff: wacom tablets in general, pretty common. 19:40:13 seems like the closest we got is 'specific sub-models of the Bamboo line; 19:40:43 this is pretty borderline for me just because it's not a lot of hardware that's affected, and there's a 'workaround' (unplug the tablet)...but probably weak +1 19:42:11 I'm about +/-0 on this for blocker 19:43:10 Without knowing what fraction of people this affects, it's hard to decide. 19:43:32 Definitely +1 NTH. 19:45:14 should we just punt it? 19:45:22 ideally it gets fixed and stops being a problem. =) 19:45:53 there hasn;t been movement for a while, though 19:46:25 NTH? 19:47:17 We can at least mark the bug NTH for now, pending a later blocker decision. 19:47:25 Works for me 19:47:27 +1 to NTH and punt on blocker 19:47:38 well, 'movement'...we basically know what the fix is 19:47:49 i don't really know why it's taking time to land, afaict it's pretty much a solved problem 19:47:55 i'll poke olivier in the rear 19:48:24 proposed #agreed - 799667 - AcceptedNTH - It's not clear whether this affects enough HW to be a blocker but there is a fix that needs to be applied and is a bit nasty to hit right after install 19:48:51 ack 19:49:33 ack 19:49:41 #agreed - 799667 - AcceptedNTH - It's not clear whether this affects enough HW to be a blocker but there is a fix that needs to be applied and is a bit nasty to hit right after install 19:49:49 #topic (791130) segfault in _clutter_actor_finish_queue_redraw 19:49:49 #link http://bugzilla.redhat.com/show_bug.cgi?id=791130 19:49:49 #info Proposed Blocker, NEW 19:50:03 sounds like there is fix that needs re-testing 19:52:27 see https://bugzilla.redhat.com/show_bug.cgi?id=791130#c61 19:52:39 This seems to have hit a lot of people doing different things, so I think it is general enough to justify blocker status. 19:52:48 i'm somewhat -1 on taking shell crashes as blockers in general because the visible impact is pretty small, but a lot of people wanted to make it one 19:55:38 rbergeron and tflink effectively voted +1 final at the beta review meeting. 19:56:06 we could punt and hope that the update fixes this 19:56:16 The bug reporting is probably the biggest impact on end users. 19:56:44 It can be fixed up in an update except on live images. 19:57:37 We can at least mark it NTH like the last bug. 19:58:11 * adamw is actually on a 'let's not just auto-NTH everything' campaign =) 19:58:26 if we're going to take shell fixes post-freeze, I'd rather they be blockers 19:58:40 right 20:00:21 I'm + .5 blocker on this, I think - it's not horrible but looks really bad on lives 20:01:04 I'm inclined to blocker as well for live images, but not really strongly. 20:01:29 punt and hope it goes away? 20:01:30 can we just remove gnome ;) 20:01:46 something tells me that there would be resistance to that :-P 20:02:30 i think its likely a blocker, and maybe fixed in updates-testing 20:02:54 sounds like we're more +1 blocker than -1 blocker 20:02:55 * adamw votes 0 20:03:01 i don't mind if we go blocker, really. 20:03:17 id rather shell not crash 20:03:57 * tflink is looking for a criterion 20:06:29 I'm not seeing one, though 20:07:11 yeah, nothing obvious springs to mind. 20:07:38 which makes it more NTH 20:08:14 it doesn't crash in all cases right away, which nixes the 'abrt crash notification' criterion, and it doesn't make anything unusable. 20:08:30 exactly, it mostly looks bad and is a bit of a pain 20:08:51 can't think of any precedents either. 20:09:42 so either punt or reject blocker and re-propose NTH 20:11:05 punt it before we all die of old age. 20:11:07 proposed #agreed - 791130 - RejectedBlocker - This doesn't hit any release critera or precedents and therefore is not a blocker. Re-propose as NTH and it will be re-evalued if not fixed with new update 20:11:24 ack 20:11:39 proposed #agreed - 791130 - RejectedBlocker - This doesn't hit any release critera or precedents and therefore is not a blocker. Re-propose as NTH and it will be re-evaluated if not fixed with new update 20:11:43 fixed typo 20:12:20 ack 20:12:24 #agreed - 791130 - RejectedBlocker - This doesn't hit any release critera or precedents and therefore is not a blocker. Re-propose as NTH and it will be re-evaluated if not fixed with new update 20:12:49 ack 20:12:50 bah, 3 hours and we're barely halfway through 20:12:56 #topic (804835) Failed to install GRUB2 into boot partition 20:12:56 #link http://bugzilla.redhat.com/show_bug.cgi?id=804835 20:12:56 #info Proposed Blocker, NEW 20:13:17 I'm -1 blocker on this one 20:13:51 Pretty much for the same reason as for Beta 20:14:28 yeah -1 blocker 20:14:33 -1 blocker 20:15:07 note that i was probably wrong at beta, this is likely a real bug and not just a 'doctor it hurts' 20:15:13 the workaround is a workaround, not the right way of doing things 20:15:29 proposed #agreed - 804835 - RejectedBlocker - This doesn't violate any of the F17 release criteria and is a non-standard method of installation 20:15:34 but still, the workaround _works_, and this is still not something we explicitly cover in criteria and something of a corner case, so still -1. 20:15:50 patch: "This doesn't violate any of the F17 release criteria and is a non-standard method of installation, and there is a workaround available" 20:15:54 proposed #agreed - 804835 - RejectedBlocker - This doesn't violate any of the F17 release criteria and is a non-standard method of installation - a workaround is available. 20:15:58 ack 20:16:05 we'll get the fix in anyway, though. 20:16:39 ack 20:16:41 #agreed - 804835 - RejectedBlocker - This doesn't violate any of the F17 release criteria and is a non-standard method of installation - a workaround is available. 20:16:48 #topic (802106) ipw2200 bg doesn't work in f17 20:16:48 #link http://bugzilla.redhat.com/show_bug.cgi?id=802106 20:16:48 #info Proposed Blocker, NEW 20:17:22 I got the smolt data I needed for this, I just haven't gotten around to designing a query that answers the question of how many ipw2200 installs there were 20:18:53 with the number of reports we have been seeing, I'm not sure about accepting this as a blocker w/o more data 20:19:26 so I'd say punt and I'll get an answer to the "how many" question or reject 20:20:31 i'm okay punting 20:21:07 proposed #agreed - 802106 - we still need data on how many ipw2200 installs are registered in smolt - will vote once we have that data 20:21:22 #action tflink to find better numbers on how many affected installs are in smolt 20:22:06 ack 20:22:23 #agreed - 802106 - we still need data on how many ipw2200 installs are registered in smolt - will vote once we have that data 20:22:32 #topic (796479) firewalld conflicts with libvirt's default network 20:22:32 #link http://bugzilla.redhat.com/show_bug.cgi?id=796479 20:22:32 #info Proposed Blocker, ASSIGNED 20:23:48 I think this depends entirely on whether firewalld remains on by default 20:23:55 if it does, +1 blocker 20:23:59 if not, -1 blocker 20:24:50 yeah...it's fixable with an update, probably, but i think we want usable vm hosting ootb, really. 20:25:04 we have to act for now as if firewalld is default, because it is. 20:25:08 I suppose we could take it as a blocker 20:25:16 if firewalld isn't on by default, it'd just be closed 20:25:40 firewalld is supposed to be on by default 20:25:52 so im +1 blocker 20:26:03 proposed #agreed - 796479 - AcceptedBlocker - Violates the F17 beta release criterion "The release must be able host virtual guest instances of the same release, using Fedora's current preferred virtualization technology" 20:26:42 ack 20:27:05 #agreed - 796479 - AcceptedBlocker - Violates the F17 beta release criterion "The release must be able host virtual guest instances of the same release, using Fedora's current preferred virtualization technology" 20:27:09 only 9 left 20:27:18 #topic (813905) livecd-iso-to-disk does not create USB correctly from a DVD image 20:27:21 #link http://bugzilla.redhat.com/show_bug.cgi?id=813905 20:27:24 #info Proposed Blocker, MODIFIED 20:27:32 this one is a bit of a mess 20:27:44 and I think a couple of things are being proposed 20:28:12 the documentation needs to be cleared up around the --format issue 20:28:21 which I think has been done already 20:28:47 and I believe the bcl has added a warning if there is no --format and the partitioning is not correct 20:29:17 since the previous behavior would make litd copy the iso to / if the partitions weren't right 20:29:37 so I'm +1 blocker on the --format doc issue and warning 20:29:45 * dgilmore is +1 blocker 20:30:09 * adamw reads 20:30:10 I'm -1 blocker on the other tangled issue about the inability to use a 1tb HDD as installation media without changing partitions 20:31:16 +1 blocker that requirement to use --format should be enforced or at the least _documented_ 20:31:23 though it's a 'special blocker' as it's in livecd-tools 20:31:40 yep, a non-spin-blocking release blocker 20:31:52 * tflink was tempted to call it a non-release-blocking release-blocker 20:32:21 paging mr. kafka, cleanup in aisle #3 20:33:01 * nirik is around if he can help with anything. 20:33:20 proposed #agreed - 813905 - AcceptedBlocker - The documentation needs to cover use cases that require --format and there needs to be a warning if the process is going to fail. The approved blocker does NOT cover any claims of lost functionality, though. 20:33:44 ack/nak/patch? 20:34:15 ack 20:35:11 #agreed - 813905 - AcceptedBlocker - The documentation needs to cover use cases that require --format and there needs to be a warning if the process is going to fail. The approved blocker does NOT cover any claims of lost functionality - that would need to be filed in another bz 20:35:29 * tflink changed it slightly but didn't think it would be an issue, can #undo if needed 20:35:38 speaking of which - something I should have done @ the start 20:35:41 #chair adamw 20:35:41 Current chairs: adamw tflink 20:35:52 #topic (799132) numastat is written in perl 20:35:52 #link http://bugzilla.redhat.com/show_bug.cgi?id=799132 20:35:53 #info Proposed Blocker, ON_QA 20:37:12 -1 blocker, I think 20:37:16 yay a chaor 20:37:19 * adamw throws chair 20:37:30 * adamw should probably stop drinking 20:37:41 heh. interesting summary. 20:37:46 * tflink is reminded of pro wrestling when someone talks about being #chaired 20:37:48 'tools written in perl ARE UNACCEPTABLE!' 20:37:56 perl is a blocker 20:38:47 * adamw stands by comment #7 - 'this would be nice' isn't a blocker. 20:38:50 -1 20:39:00 proposed #agreed - 799132 - RejectedBlocker - As written, this bug does not hit any of the F17 release criteria 20:39:07 this doesn't hit any critera I can think of. ;) 20:39:49 ack 20:40:01 we could always propose a release requirement that "it can't be written in perl" 20:40:10 but that seems a bit ... odd to say the least 20:40:31 #agreed - 799132 - RejectedBlocker - As written, this bug does not hit any of the F17 release criteria 20:40:38 ack 20:40:53 #topic (813548) pulseaudio terminates very often 20:40:53 #link http://bugzilla.redhat.com/show_bug.cgi?id=813548 20:40:53 #info Proposed Blocker, NEW 20:42:53 This doesn't seem to be affecting enough people to accept as a blocker yet but then again, it was first reported earlier this week 20:43:44 proposed #agreed - 813548 - There haven't been enough reports of this to justify taking as a blocker - will wait another week to see if there are more reports before deciding on blocker status 20:44:32 * adamw reading 20:44:46 seems reasonable to me. 20:44:52 ack 20:45:05 (I got distracted for a while with work.) 20:45:14 yeah...ack 20:45:18 #agreed - 813548 - There haven't been enough reports of this to justify taking as a blocker - will wait another week to see if there are more reports before deciding on blocker status 20:45:21 of course, we should check if we can reproduce 20:45:44 #undo 20:45:44 Removing item from minutes: 20:46:16 #agreed - 813548 - There haven't been enough reports of this to justify taking as a blocker - will wait another week to see if there are more reports before deciding on blocker status. It would be nice to see more testing on this 20:46:22 #topic (804216) pungi doesn't use yum transactions, which is a problem with langpacks 20:46:24 #link http://bugzilla.redhat.com/show_bug.cgi?id=804216 20:46:27 #info Proposed Blocker, NEW 20:46:28 +1 blocker 20:46:36 +1 blocker. should get fixed. 20:47:19 proposed #agreed - 804216 - AcceptedBlocker - Violates the F17 final release criterion "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use" 20:47:33 ack 20:47:38 ack 20:47:46 #agreed - 804216 - AcceptedBlocker - Violates the F17 final release criterion "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use" 20:47:49 ack, kde updating is probably a 'critical path action'. 20:47:59 let's hope no-one looks through this log and compares our logic to the beta go/no-go. =) 20:48:14 * adamw points all reading journalists at that shiny object outside the window there 20:48:14 why not? 20:48:22 oh yeah, that's a final criterion. whew. 20:48:33 * adamw puts down the beer 20:48:35 #topic (799591) SELinux is preventing NetworkManager from 'read' access on the file /etc/sysctl.conf. 20:48:38 #link http://bugzilla.redhat.com/show_bug.cgi?id=799591 20:48:40 #info Proposed Blocker, MODIFIED 20:48:49 adamw: didn't you say you were going to do that a while ago? :-P 20:49:15 tflink: promises, promises 20:49:18 i said i SHOULD do it 20:49:20 not that i WOULD 20:49:24 point taken 20:49:54 how soon after boot/login is this happening? 20:50:05 i'm getting it at boot, i think. 20:50:07 if it's NM, I assume pretty early in the process 20:50:19 if so, a pretty clear blocker 20:50:25 in f16, anyhow 20:50:30 uh, i think it's fixed in f17 20:50:50 i re-opened it because it's still happening in f16, just to poke mgrepl to push an update. but it probably shouldn't block 17. 20:51:04 yep, I just noticed that 20:51:40 #info this was fixed in F17 but re-opened when the same bug showed up in F16 - will remove from consideration for F17 final blocker 20:51:51 #topic (740280) /dev/live no longer exists 20:51:51 #link http://bugzilla.redhat.com/show_bug.cgi?id=740280 20:51:51 #info Proposed Blocker, NEW 20:53:13 I'm a little confused on why this is a blocker 20:53:19 breaks live image persistence 20:53:30 oh 20:53:48 also encrypted /home for live 20:54:44 we don't have criteria for this, so it's hard to take it as is. but maybe we should. 20:54:52 I don't think that we have a criteria for this, though 20:56:23 as in, maybe we should have criteria 20:56:31 I'd be leaning more towards "should be a blocker" even if we have to propose new criteria 20:56:53 releasing with tools that create persistant overlays even though there is no chance of them working seems bad 20:57:06 Would this be fixed in livecd-iso-to-disk? If so that could be done after release. But if the issue is in the ISO, it would be nice to have it fixed before release. 20:57:10 f16 shipped this way? huh... 20:57:59 or was it broken post-release? 20:57:59 brunowolff: it's in livesys 20:58:09 nirik: uh, i may have been wrong, we may have reverted it for f16 or some crap. 20:58:25 yeah, I would have thought there would have been a large outcry. 20:58:30 brunowolff: we couldn't fix it with a post-rel update i don't think 20:58:37 * nirik is +1 blocker. even if we need to make a new critera for it. 20:58:44 i dunno how many people actually _use_ overlays. but yeah, i'd've figured to hear more about it. 20:58:56 satellit_: you've tested overlay stuff right? 20:58:59 what's the status? 20:59:20 * tflink wonders if this was covered in the usb-media test day 20:59:22 comment #2 "move to F17... /dev/live is present again in F16" 21:00:08 i was probably smoking crack in #15 or something. 21:00:34 proposed #agreed - 740280 - This is not a blocker with the current release criteria, will re-evaluate if new criterion is accepted 21:00:56 anyone feel like volunteering to propose a new criterion? 21:01:04 adamw Libeusb-creator work....overlay 21:01:23 works 21:01:36 ack 21:01:38 tflink: usually when we have strong consensus to propose a new criterion for a bug we either accept it as blocker pending the new criterion or punt, we don't reject it 21:02:11 adamw: who said anything about rejecting it? 21:02:29 l=i-t-d creates persisent overlays for bios and EFI that work 21:03:07 have to go....sorry 21:03:17 tflink: "not a blocker" read like rejecting to me 21:03:20 satellit_: thanks 21:03:27 so, according to satellit, overlays are somehow working anyway... 21:03:34 ye look at 4.1 test day 21:03:37 maybe this got fixed up in livesys but not noted 21:03:39 proposed #agreed - 740280 - This is not a blocker with the current release criteria but we feel that it should be. No status change WRT blocker status of this bug; will re-evaluate if new criterion is accepted 21:05:36 patch to acknowledge unclear nature of impact? 21:06:38 if overlays are working this is less severe... ;) 21:07:03 proposed #agreed - 740280 - This is not a blocker with the current release criteria but we feel that it should be if it is indeed impacting the ability to create persistent overlays for live images on USB. No status change WRT blocker status of this bug; will re-evaluate if new criterion is accepted and 21:07:04 right. 21:07:08 ack 21:07:13 proposed #agreed - 740280 - This is not a blocker with the current release criteria but we feel that it should be if it is indeed impacting the ability to create persistent overlays for live images on USB. No status change WRT blocker status of this bug; will re-evaluate if new criterion is accepted 21:07:20 extra 'and' 21:07:24 ack 21:07:30 #agreed - 740280 - This is not a blocker with the current release criteria but we feel that it should be if it is indeed impacting the ability to create persistent overlays for live images on USB. No status change WRT blocker status of this bug; will re-evaluate if new criterion is accepted 21:07:31 ack 21:07:44 #topic (798328) No rescue shell is offered for fsck errors 21:07:44 #link http://bugzilla.redhat.com/show_bug.cgi?id=798328 21:07:44 #info Proposed Blocker, NEW 21:08:24 if there really is no fsck in the dracut shell, I'm +1 blocker 21:08:46 wait, is this dracut shell or systemd rescue shell 21:09:02 wasn't this an issue for F16, too? 21:09:56 This is fixable in an update, and only comes into play when there is a problem with fsck. 21:10:36 Unless problems are more common than I expect, I don't think this rates as a blocker. 21:11:41 it's an icky area. 21:12:06 i did hit this the other day, though, actually. and i was able to fix it all up from the boot process. so i got a console when i needed one. 21:12:41 * rbergeron doesnt think adamw should stop drinking 21:13:00 rbergeron: hic 21:13:04 I'm remembering something in F16 where you wouldn't get the rescue shell unless you rebooted 21:13:27 but you would get the rescue shell after reboot 21:15:20 didn't see that. but yeah, i remember something like that too. 21:15:26 i think if i drink more it might help my memory. 21:16:59 if we have a workaround, I'm ok with -1 blocker 21:17:25 but either this or the system time bug probably needs to be fixed before release 21:17:35 i'd feel more comfortable having kparal around, since he seems to understand it better. 21:18:36 if you change the system time on the host, doesn't the VM pick that up? 21:19:06 * nirik sees sandeen just updated the time fsck bug 21:19:11 i don't know. in some sense, i guess, yeah. 21:19:56 I'm not comfortable rejecting this without more data 21:20:17 releasing without an acceptable recovery mechanism seems like really bad form, even if it can be fixed w/ an update 21:20:58 and if you hit the bug, how do you install the update... 21:21:13 if a workaround like rebooting will get you to the recovery console, I'd be OK with that 21:21:23 so I say punt and ask for more info 21:22:31 proposed #agreed - 798328 - We need more information and testing on this before deciding on blocker status. While it could be fixed with an update, if you hit it before updating, that doesn't help. It would also be good to know if there are any possible workarounds for the issue 21:22:45 ack 21:23:42 ack 21:23:44 #agreed - 798328 - We need more information and testing on this before deciding on blocker status. While it could be fixed with an update, if you hit it before updating, that doesn't help. It would also be good to know if there are any possible workarounds for the issue 21:23:55 only 2 more proposed blockers! 21:24:04 #topic (802552) wlan0: WPA: Failed to get master session key from EAPOL state machines - key handshake aborted 21:24:07 #link http://bugzilla.redhat.com/show_bug.cgi?id=802552 21:24:09 #info Proposed Blocker, NEW 21:24:41 do we have an idea of how common this actually is? 21:25:33 I see it as 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" 21:26:34 never seen it...reading 21:26:45 "WPA PEAP MSCHAPV2" 21:26:46 ah. 21:26:56 * adamw goes to ping peter 21:27:11 * tflink thinks that this is what his university uses but they have almost no support for linux 21:27:26 three dupes, and peter thinks it's a blocker...i trust him 21:27:33 waiting for a ping reply now 21:30:03 nothing doing 21:30:16 * adamw pings dcbw instead 21:30:22 "I downgraded to the 0.2.fc17 and things work again." 21:30:25 so this is a regression 21:31:11 https://bugzilla.redhat.com/show_bug.cgi?id=811447 states "PEAP does not work" 21:32:22 looks like any kind of EAP is broken with wpa-supplicant 1.0-0.3, and quite a few reporters. i'm going with +1 blocker. 21:32:34 we could always revoke blocker status later 21:33:31 yeah, nothing is permanent. 21:33:39 proposed #agreed - 802552 - AcceptedBlocker - Conditional violation of the F17 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" for PEAP wireless APs 21:33:49 ack 21:33:57 adamw: very philosophical :) 21:35:11 hic 21:35:41 ack 21:35:43 #agreed - 802552 - AcceptedBlocker - Conditional violation of the F17 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" for PEAP wireless APs 21:35:55 #topic (810161) Regression: change to 16 bpp by default in virt breaks KDE Plasma desktop 21:35:58 #link http://bugzilla.redhat.com/show_bug.cgi?id=810161 21:36:01 #info Proposed Blocker, NEW 21:37:20 ehhh. it's a polish bug, ultimately. it's not broken. it's unintentionally pink. 21:37:26 * adamw is feeling pretty +/-0. 21:38:48 yeah, I'm not strongly +1 on this 21:39:22 I'm thinking not blocker - would consider NTH 21:39:28 +1 blocker 21:40:14 it's kinda 'how bad do we think a cosmetic bug in one of the common Fedora virt stack configs with one of the supported Fedora desktops is'. 21:40:31 i guess i'd want more votes. 21:40:42 damn conditional blockers. 21:41:01 it would be really nice to fix... I'm def +1 NTH... might be blocker... it just looks bad 21:41:19 it's easy to say 'hey, we got weeks to fix before final, let's just make it a blocker and make kevin happy', but that's kinda the easy out. 21:41:37 would i want to hold the release for a week if this was go/no-go and everything else was good? ehhhhhh. 21:41:39 maybe, 21:41:49 probably not 21:42:26 thought experiment, the bug is in gnome not kde...change anyone's mind? 21:42:33 because it shouldn't. i'd still be kinda ehhh. 21:42:48 I'd still say probably not 21:42:57 I guess it's only virt, etc... +1 NTH tho. 21:43:04 either way, it's a corner case that is as much a bug in the defaults for libvirt as anything 21:44:29 the default seems to be set by a gconf key, btw. which may be why we get different people seeing different defaults. 21:44:51 but i haven't investigated any reasons why it doesn't get changed with schema updates or why there seem to be two similarly named keys or what have you. 21:45:30 i'd probably feel better having more votes, and maybe getting kevin in to orate. 21:45:37 punt? 21:45:52 we can do that, I guess 21:45:58 there's possibly several ways to fix it... not that it matters for voting on it... 21:46:07 I'm OK with RejectedBlocker and AcceptedNTH, though 21:46:18 I just can't see slipping release for this 21:46:27 i wouldn't lose any sleep, but i'm not feeling confident enough to cast a vote. 21:46:31 taking a tested fix after freeze? Sure 21:46:45 i guess by a strict interpretation of the criteria it's -1. 21:46:50 since nothing is unusable. 21:46:56 slipping release just because one of the primary DEs looks funny in one possible default virt env? No 21:48:07 btw, let me at this point channel the spirit of KK in his absence to say we're all crazy and quite possibly evil too, and we're killing KDE. 21:48:47 oh, I imagine this won't be the last we hear of this if it isn't fixed by freeze 21:49:16 but as far as blocker is concerned - I'm seeing +1/-1/2x0 21:49:19 you'll hear about simply because of this convo if nothing else. he likes to comment :) 21:49:56 any other votes? 21:50:05 screw it, i like to argue with kevin, i'll make mine a -1 according to criteria. 21:50:08 i dont know enough about the bug to even comment. ~pass 21:50:15 the bug just doesn't break stuff enough to constitute blockeriness. 21:50:26 +1/-2/1x0 21:51:38 proposed #agreed - RejectedBlocker AcceptedNTH - This is a cosmetic polish issue that only hits certain VM configurations - it doesn't clearly violate any of the release criteria and doesn't seem severe enough to justify slipping release for but a well tested fix would be considered after final freeze 21:52:38 ack 21:53:08 ack 21:53:17 #agreed - RejectedBlocker AcceptedNTH - This is a cosmetic polish issue that only hits certain VM configurations - it doesn't clearly violate any of the release criteria and doesn't seem severe enough to justify slipping release for but a well tested fix would be considered after final freeze 21:53:28 * adamw dons asbestos bodysuit and starts scanning the horizon for incoming Kofler projectiles 21:53:40 * fenrus02 brings popcorn 21:53:48 And that would be the last of the proposed blockers for today! 21:54:05 just short of 5 hours 21:54:34 we still have 9 proposed NTH 21:54:48 any thoughts on powering through or leaving them for later? 21:55:36 depends how quickly they can be run through really. i highly doubt anyone wants to be around another 5hrs to talk about those right now 21:56:22 well, if we keep going at the same rate, it would be ~ 1.5 hours 21:56:41 we seem to be doing about 10 min per bug 21:57:44 i've only got another hour or so before i need to run. 21:57:51 let's just leave it for the next meeting. 21:58:00 nth status isn't terribly important, and even less so outside of freezes. 21:58:02 when is the next scheduled? 21:58:05 next friday 21:58:07 next week 21:58:15 so a mere 10 minutes from now, right? :) 21:58:15 cool 21:58:22 adamw: I won't fight you on that 21:58:44 10 minutes? I suppose that depends on how you define the week 21:58:58 #topic Open Floor 21:59:20 #info there were no objections to not reviewing the NTH this week. Will revisit next week 21:59:36 I think we're in for another not-short meeting next week 21:59:37 tflink: we've been here 6 days, 23 hours and 50 minutes, right? 21:59:40 it sure feels like it =) 22:01:01 anything that I missed or that anyone wants to bring up? 22:01:21 god, no. 22:01:38 #info Next blocker review meeting will be on 2012-04-27 @ 17:00 UTC 22:02:08 * tflink sets the fuse for ~ 5 minutes 22:02:16 ... give or take 5 minutes :) 22:02:40 * adamw blows on fuse 22:06:14 * fenrus02 watches crickets chirp 22:06:31 #endmeeting