17:03:19 #startmeeting f18beta-blocker-review-7 17:03:19 Meeting started Wed Nov 7 17:03:19 2012 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:03:19 #meetingname f18beta-blocker-review-7 17:03:19 The meeting name has been set to 'f18beta-blocker-review-7' 17:03:24 #topic Roll Call 17:03:28 * kparal here 17:03:30 kparal: so you changed UTC :) 17:03:31 * pschindl is here 17:03:32 * jreznik is here 17:03:37 * nirik is lurking 17:04:22 wow, that was quick :) 17:04:57 * Cerlyn is here 17:05:25 I believe that we have enough to get started 17:05:35 anyone want to volunteer to play secretary? 17:06:00 * jreznik can't today, multitasking two meetings :( 17:07:02 I can try. I should just add comments to bugzilla, right? 17:07:03 * adamw is here, just got out of the shower 17:07:18 kparal: yeah, that and change bug status as needed 17:07:36 well, if adamw is here, I'll gladly give up this priviledge :) 17:07:44 either way :) 17:08:00 * kparal spells privilege properly 17:08:06 eh, sure, i'll do it. 17:09:13 * satellit listening 17:09:28 ok, boilerplate time 17:09:34 #topic Introduction 17:09:43 Why are we here? 17:09:43 #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:09:50 #info We'll be following the process outlined at: 17:09:50 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:09:56 #info The bugs up for review today are available at: 17:09:56 #link http://qa.fedoraproject.org/blockerbugs/current 17:10:03 #info The criteria for release blocking bugs can be found at: 17:10:03 #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria 17:10:04 #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria 17:10:04 #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria 17:10:16 Up for review today, we have: 17:10:19 #info 5 Proposed Blockers 17:10:19 #info 11 Accepted Blockers 17:10:19 #info 3 Proposed NTH 17:10:19 #info 40 Accepted NTH 17:10:37 wow, that's a lot of accepted nth 17:10:54 any objections to starting with the proposed Blockers? 17:11:03 no objection, go on 17:11:21 #topic (873224) TypeError: cannot concatenate 'str' and 'NoneType' objects 17:11:21 #link https://bugzilla.redhat.com/show_bug.cgi?id=873224 17:11:21 #info Proposed Blocker, anaconda, NEW 17:12:44 seems like -1 beta blocker but for final - not to blow up 17:12:45 it sounds like this is an issue with anaconda blowing up if a degraded RAID array is encountered 17:13:34 it is quite similar to my case of incomplete LVM 17:13:45 we decided +1 Beta NTH, +1 Blocker Final, IIRC 17:14:01 that works for me 17:14:15 same for me 17:14:32 let's propose 17:15:00 +1 to that 17:15:08 actually 17:15:13 -1 to that. not nth. not now. too late. 17:15:21 kparal: do you recall which criterion was used? 17:15:32 we really need to start focusing on blockers at some point. 17:15:46 adamw: +1 nth to be consistent with lvm but you're right 17:15:54 tflink: 869185 17:17:07 proposed #agreed 873224 - RejectedBlocker (beta), AcceptedBlocker (final) - While anaconda doesn't support degraded RAID arrays, it shouldn't crash when one is encountered and is a conditional violation of the following F18 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the 17:17:14 ack 17:17:32 ack 17:17:35 of the 17:17:41 ack 17:18:13 proposed #agreed 873224 - RejectedBlocker (beta), AcceptedBlocker (final) - While anaconda doesn't support degraded RAID arrays, it shouldn't crash when one is encountered and is a conditional violation of the F18 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" 17:18:31 * tflink really needs to figure out a better way of doing this, the trial and error is no good 17:18:46 either that or figure out how to get the max length increased 17:18:53 #agreed 873224 - RejectedBlocker (beta), AcceptedBlocker (final) - While anaconda doesn't support degraded RAID arrays, it shouldn't crash when one is encountered and is a conditional violation of the F18 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" 17:18:59 #topic (868535) AttributeError: 'NoneType' object has no attribute 'get' 17:19:02 #link https://bugzilla.redhat.com/show_bug.cgi?id=868535 17:19:04 #info Proposed Blocker, anaconda, VERIFIED 17:19:59 damnation, this is verified 17:20:03 #undo 17:20:03 Removing item from minutes: 17:20:04 #undo 17:20:04 Removing item from minutes: 17:20:06 #undo 17:20:06 Removing item from minutes: 17:20:15 #topic (873459) Upgraded system does not reboot if a kernel upgrade is part of the upgrade 17:20:18 #link https://bugzilla.redhat.com/show_bug.cgi?id=873459 17:20:20 #info Proposed Blocker, fedup-dracut, NEW 17:20:23 well verified but not accepted 17:20:24 this one. fun times 17:20:28 kparal: it's NTH 17:20:40 tflink: ah 17:20:43 we can go over it as a blocker but I figured it didn't matter a whole lot 17:20:52 ok 17:20:55 tflink: reason? 17:21:06 hm was that an nth when the installer did not reboot? 17:21:06 jreznik: reason for ...? 17:21:20 tflink: you mean for the previous undo bug, I get it now 17:21:41 I can go back if anyone wants to 17:21:57 no it's fine 17:22:12 to clean the list but... 17:22:18 clean up 17:22:22 ok, back to the fedup funtime broken rebooted system bug 17:22:42 basically, there are issues with fedup that are most prominent when a kernel upgrade is involved 17:23:00 do we know where the fix for this is going to come next? 17:23:06 I have yet to see an upgrade w/ kernel update that didn't end in a non-bootable system 17:23:16 thats a blocker right 17:23:41 I'm seeing other issues with a bare-metal upgrade and kvm/qemu that might be related but I'm not certain of that 17:23:44 mkrizek reported today he managed to successfully upgrade F17 17:24:19 +1 blocker 17:24:25 if you don't get a kernel upgrade (which you won't right now if you don't specify a side repo or updates-testing during upgrade), you won't hit the most obvious symptoms of this 17:24:36 upgrade broken, +1 blocker 17:25:09 +1 blocker 17:25:12 yeah, we can hardly rely on not getting a kernel upgrade 17:25:24 +1 blocker on the face of it, my only question is the usual one with fedup, do we need to fix this in the frozen packages. 17:25:27 do we have a test matrice for upgrades? 17:25:28 which never seems to get a clear answer :) 17:25:36 jreznik: it's at the bottom of the install matrix. 17:25:53 adamw: it depends on what we end up doing for the upgrade initramfs 17:25:58 * nirik is also +1 blocker... no idea where the problem is tho 17:26:00 which I still don't have a clear answer on 17:26:09 jreznik: we don't have a test case yet 17:26:22 * tflink is working on a test plan and test cases 17:26:42 kparal: would be great to have one, so we will be able to track success rate 17:26:48 adamw: it's not there, we commented out preupgrade test cases 17:26:54 (and anaconda ones) 17:27:11 the last time I talked to will about it, he was looking into including the upgrade bits in the regular installer initramfs but was hitting problems with lvm being disabled 17:27:21 jreznik: once it doesn't require black magic, we can write a test case :) 17:27:30 kparal: oh, well we can uncomment them again at some point. 17:27:41 the last I heard, we might get a separate initramfs for upgrade generated by lorax but I have no idea about that status 17:27:42 adamw: but they are still obsolete 17:27:55 like I said, I'm working on the test cases 17:27:59 tflink: but this is related to the stuff in the initramfs either way? 17:28:06 adamw: yes 17:28:26 without question, this is an issue with stuff that is in the initramfs and not part of the stuff that's in F17 17:28:44 then +1 blocker for sure 17:28:51 but like kparal said, I'd rather have less black magic and hacky-ness before we turn everyone loose on fedup testing 17:29:41 I think this one is agreed 17:29:41 I'm keeping track of the worst bugs and current process here: https://fedoraproject.org/wiki/QA:Fedora_18_Upgrade_Testing 17:29:50 Viking-Ice: yeah 17:29:53 I can only do one thing at a time 17:30:52 should not that info be in a fedup testday 17:31:01 proposed #agreed 873459 - AcceptedBlocker - This is a violation of the following F18 beta release criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria." 17:31:07 ack 17:31:08 ack 17:31:22 ack 17:31:25 why is it that I get poked when I'm not fast enough but nobody else is bothered when there are delays in votes or acks? 17:31:32 #agreed 873459 - AcceptedBlocker - This is a violation of the following F18 beta release criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria." 17:31:35 eh? no-one's poking anyone 17:31:43 Viking-Ice: fedup test day? 17:31:54 yeah that wiki page 17:32:06 which information, it should be pretty up to date 17:32:22 btw we usally did create a wikipage on our own wiki namespace then move it to the official one once accepted 17:32:31 https://fedoraproject.org/wiki/QA:Fedora_18_Upgrade_Testing 17:32:39 if it's missing something, let me know. I can take a look at it after the meeting 17:33:00 Viking-Ice: I was more interested in getting everything written down at the time 17:33:10 if I messed up the wiki policy, I apologize 17:33:22 #topic (873576) parted hangs trying to inspect newly-created Intel fwraid RAID-1 array 17:33:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=873576 17:33:28 #info Proposed Blocker, kernel, NEW 17:33:36 Viking-Ice: that's needless bureaucracy, especially in this case 17:34:13 let's move on I'm not in the mood of yet another things you red hatters thing is needless 17:34:13 tflink: there's no policy i'm aware of. it's fine to just create a page on the wiki to provide information on something. we have all kinds of random pages like that. 17:34:54 adamw, I guess you had not started when we where working like that then 17:35:28 Viking-Ice: do you have to be so negative? tflink was working on testing fedup so he created a page to share his knowledge. 17:35:35 allthou I think I recollect you fixing my spelling few times before moving it under the official one but I might be confusing you for James 17:35:53 being overly negative about that isn't going to encourage tim to create a 'proper' page in future, it'll just encourage him not to create anything at all. 17:36:03 because then you won't have anything to complain about. 17:36:21 adamw, I only pointed out that we usually created that page under our own namespace before moving it under the official one 17:36:42 in any case let's move on 17:36:51 Viking-Ice: we waste most of the time talking to you when you complain about _anything that happens_ 17:36:53 yes, lets 17:37:20 so let's keep that at least outside of the meeting 17:37:21 we can debate wiki policy and namin later 17:37:27 let's get through the blockers 17:38:04 Viking-Ice: oh, sorry, i missed the part about namespace drafts, i thought we were still talking about a test day. 17:38:30 so i would like it if someone else could try and reproduce this, but finding people with intel fwraid when you want to always seems oddly hard. 17:38:53 I can try. my box with intel fwraid was being used for fedup testing until this morning 17:39:12 it took a while to dig that upgrade out of non-bootable hell :) 17:39:16 ah, mkovarik reproduced at least 17:39:31 yep, just typing that 17:39:47 +1 blocker 17:39:56 so i'm more comfortable about making this a blocker 17:40:29 conditional violation of "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot " , in the case of Intel fw RAID-1 or RAID-5. 17:40:38 raid-0 works, but that's hardly an alternative :) 17:40:55 it affects also raid-5 17:40:58 proposed #agreed 873576 - AcceptedBlocker - Violates the following F18 beta release criterion for Intel FW RAID1: "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot" 17:40:59 that dupe 17:41:01 yeah, i wrote that. 17:41:05 ack 17:41:07 adamw: I use RAID0 for ALL my backups ;) 17:41:10 ack (or add raid5) 17:41:11 ack 17:41:13 ack 17:41:15 proposed #agreed 873576 - AcceptedBlocker - Violates the following F18 beta release criterion for Intel FW RAID1/RAID5: "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot" 17:41:15 CRCinAU: :P 17:41:19 missed the RAID5 part 17:41:29 consider acked 17:41:35 #agreed 873576 - AcceptedBlocker - Violates the following F18 beta release criterion for Intel FW RAID1/RAID5: "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot" 17:41:40 Jes is in Barcelona, LinuxCon, he can take a look on Friday 17:41:50 #topic (844167) Error in PREIN scriptlet in rpm package libvirt-daemon-0.9.11.4-3.fc17.x86_64 17:41:53 #link https://bugzilla.redhat.com/show_bug.cgi?id=844167 17:41:56 #info Proposed Blocker, selinux-policy, MODIFIED 17:42:11 this one, again :) 17:42:19 yeah that punter 17:42:30 did you manage to figure out whether it affects fedup yet? 17:42:31 I finally got this tested with fedup 17:42:34 or still blocked on that? 17:42:35 yay! 17:42:36 I don't think so, no 17:42:55 I'm seeing other issues with the VM but I don't think it's related to this bug 17:43:12 the VM starts and suddenly kills due to qemu errors 17:44:13 i think if you hit this bug the system will start up at least 17:44:29 error: qemuMontiroIO:606 : internal error End of file from monitor 17:44:30 but you might not be able to log in via gdm, and a few other things are screwy. but you do get a booted system. 17:45:07 if you have enough time when the system starts up, you could check if the 'polkitd' user exists. 17:45:19 there is a crash but abrt hit problems and didn't finish collecting the crash 17:45:38 after much coaxing, the upgraded virthost does boot 17:45:53 the shutdown I'm talking about is in the VM on the upgraded virthost 17:46:16 oh, i see. 17:46:26 both qemu and polkitd users exist 17:46:53 I think this is either fixed or didn't affect fedup 17:48:13 but there are still quite a few workarounds needed to get a working upgraded system 17:48:42 including an extra one on this upgrade that I want to reproduce before filing 17:49:01 okay, but it sounds like we can take this particular bug out of blocker consideration. finally. 17:49:05 -1 blocker! 17:49:21 -1 blocker throw it in the trash 17:49:32 and let's hope it does not resurface ;) 17:50:03 amen 17:50:04 proposed #agreed 844167 - RejectedBlocker - After testing with fedup, this either appears to not affect that process or has been fixed in selinux-policy. Thus, rejecting as a blocker for F18 beta. 17:50:11 ack 17:50:12 ack 17:50:13 ack 17:50:19 #agreed 844167 - RejectedBlocker - After testing with fedup, this either appears to not affect that process or has been fixed in selinux-policy. Thus, rejecting as a blocker for F18 beta. 17:50:36 alrighty, I think that's all of the proposed blockers 17:50:55 * kparal likes 17:51:09 time for some proposed NTH 17:51:14 #topic (873865) langsupport groups not getting added 17:51:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=873865 17:51:14 #info Proposed NTH, anaconda, POST 17:52:26 I think mkrizek reported he received F18 KDE without all necessary language packs 17:52:37 I thought that we already had an NTH for this 17:52:40 and he had to install them manually 17:53:13 tflink: maybe 868869? 17:53:15 tflink: this is a different but similar bug 17:54:11 * tflink is probably OK with this as NTH 17:54:21 I don't really know what is the difference between the two, but missing fonts can be very problematic 17:54:23 it sounds like the change is minimal 17:55:02 +1 nth 17:55:10 +1 nth 17:55:53 proposed #agreed 873865 - AcceptedNTH - While not a blocker, it would be good to have all the needed fonts for non-english installs. 17:56:09 ack 17:56:18 ack 17:56:21 ack 17:56:32 #agreed 873865 - AcceptedNTH - While not a blocker, it would be good to have all the needed fonts for non-english installs. 17:56:41 #topic (872989) gnome-screenshot does not work in fallback mode 17:56:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=872989 17:56:41 #info Proposed NTH, cairo, ON_QA 17:57:24 not so sure about taking a cairo fix this close to release 17:57:44 me neither 17:57:51 * tflink is leaning towards -1 NTH since this only shows up in fallback mode 17:58:00 most people should be able to run shell, even in VMs 17:58:24 other thoughts? 17:58:26 but some graphics adapter issues might trigger fallback mode, and you may want to screenshot them 17:58:31 this is tricky 17:59:12 other tools are working, like ksnapshot 17:59:14 -1 nth 17:59:31 fallback mode is supposed to be deprecated anyway right 17:59:34 with 3.6 17:59:41 true but is the subset of users that are 1) running livemedia and 2) running a system that gets them into fallback mode. enough to justify taking a cairo fix this late? 17:59:51 is it used in safe graphics mode I believe 18:00:03 no 18:00:09 you'd get software rendered shell in that case 18:00:17 ok, that's good 18:00:21 aiui the only case where you get fallback mode any more is when you have a blacklisted adapter 18:00:30 since we still haven't fixed it so that blacklisted adapters go to llvmpipe 18:00:31 I would rather not take cairo update then 18:01:36 proposed #agreed 872989 - RejectedNTH - While a potential issue, the only way that this can be hit is if you're running livemedia on a blacklisted adapter. This doesn't seem as if it would affect enough users to justify taking a cairo fix this late in beta. 18:01:47 akc 18:01:48 ack 18:01:49 *ack 18:01:58 ack 18:02:00 #agreed 872989 - RejectedNTH - While a potential issue, the only way that this can be hit is if you're running livemedia on a blacklisted adapter. This doesn't seem as if it would affect enough users to justify taking a cairo fix this late in beta. 18:02:09 #topic (873342) RuntimeError: no window manager available 18:02:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=873342 18:02:09 #info Proposed NTH, firstboot, ON_QA 18:03:15 there is already one +1 NTH from the comments 18:03:35 I'm +1 NTH as well, it breaks MATE installs and MATE is a non-release-blocking DE 18:03:46 adamw: I don't get comment 17 18:04:01 msivak updated firstboot, and dan updated mate-window-manager 18:04:05 aha 18:04:13 it seems like they both need updating to fix the bug, or something. 18:04:25 oh, it was leigh, not dan. 18:04:31 * nirik notes fesco meeting in #fedora-meeting for anyone from qa that wants to provide input 18:04:38 proposed #agreed 873342 - AcceptedNTH - This breaks MATE installs and as a non-release-blocking DE, this is NTH. A tested fix would be accepted past freeze. 18:04:43 the mate-w-m update adds "Provides: firstboot(windowmanager)" 18:04:46 ack 18:04:47 ack 18:04:57 ack 18:05:18 is anyone actually maintaining mate btw? 18:05:52 people seem to be active around mate 18:05:57 I don't remember any names 18:06:20 leigh and dan, i thought. 18:06:31 yeah, search 'mate' in bodhi and you get plenty of packages from those two. 18:06:49 Viking-Ice: if you mean upstream, i think the answer is 'yes, but there is lots of scepticism about whether they have the expertise to keep it going long term'. 18:07:07 yeah I was thinking upstream 18:07:18 i don't really have the details but right now i think it's been mostly a ' 18:07:22 'run sed on the entire codebase' deal 18:07:34 I thought Gnome and most other DE developers gave a big fat warning doing things this way 18:07:41 i'm not sure they have the expert coders to be able to deal with stuff like consolekit->systemd migration and so on 18:07:48 but i guess time will tell. 18:08:27 adamw: ok, the fix for 873865 just went into master upstream. Would like to get it into the beta to avoid bugs about odd missing packages in non-english installs. 18:08:29 dont tell me fesco did not make that an absolute requirement before acceptance 18:08:44 adamw: worst it can do is add a few extra packages to some installs 18:09:23 jlk: we're doing NTH review now, actually. 18:09:29 tflink: are you pausing the meeting for fesco? 18:09:30 jlk: we accepted that as NTH 18:09:42 oh, awesome. 18:09:46 sorry, trying to do two things at the same time 18:09:58 #agreed 873342 - AcceptedNTH - This breaks MATE installs and as a non-release-blocking DE, this is NTH. A tested fix would be accepted past freeze. 18:11:18 jlk: just did the bureaucracy on it. 18:11:28 just pushed it :) 18:11:40 I'll join in for the bug review. 18:13:03 jlk: the meeting is now a bit paused because of fesco discussion in #fedora-meeting 18:13:13 gotcha 18:26:03 * adamw munches popcorn 18:26:13 this is like american politics. terrifying yet fascinating. 18:28:59 not really 18:29:19 they should lift the freeze set date and stop worrying about holidays 18:30:55 jlk, how diverged has the code between beta and final become in anaconda? 18:31:38 is it not better to lift freeze and slip few weeks and pull those changes in and iron out the remaining issue once that has been done? 18:33:51 Viking-Ice: hard to say, not super diverged. 18:34:50 we would be better of with an unfreeze and an pull and freeze again at later date then freeze slip week at a time 18:35:53 I agree. 18:45:18 yeah, like i said in the meeting, i don't think unfreezing is going to bring in any massive regressions to the TCs/RCs. 18:49:55 adamw: ping 18:50:41 rishi: yo. 18:50:46 did you catch that link earlier? 18:50:54 adamw: No. 18:51:14 rishi: https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation 18:52:45 adamw: ah, so that' the page. it's kinda hard to find it just by following links from QA page 18:52:53 yeah, it kinda is 18:53:23 adamw: ideally we could link it from Bodhi 18:53:26 the short version is, 'add the test case to Category:Package_(packagename)_test_cases' 18:53:34 kparal: sure, ask luke 18:54:44 adamw: Cool. 18:55:04 rishi: the mechanism is simple, explaining/promoting it turned out not to be :( at least to me 18:55:05 tflink: should we end the meeting or will we continue it? 18:55:06 improvements welcome... 18:55:14 Looking at http://fedoraproject.org/wiki/Category:Package_yum_test_cases as an example 18:55:17 yeah i think we may as well continue, not sure we can provide much more input to fesco... 18:55:38 kparal: we're done with all the proposed bugs 18:55:51 if we're going to unfreeze, there is little point of reviewing the accepted blockers 18:56:39 open floor then? 18:56:47 oh, we finished proposed nth? 18:56:52 tflink: why? 18:57:00 we still need to work on fixing blockers whether we're frozen or not... 18:57:34 adamw: good point 18:57:50 what the freeze affects is mainly nth 18:57:50 either way, let's wait until this part of the fesco meeting is done 18:57:59 when we're unfrozen there's not much point worrying about nth 18:58:06 but it's always worth worrying about blockers 18:59:57 Why does https://fedoraproject.org/wiki/Category:Package_gnome-shell_test_cases have all these non-gnome-shell components? Is it meant to cover entire GNOME? 19:00:23 rishi: I can fix that 19:01:28 Martix: I created a new Category:Package_gnome-online-accounts_test_cases 19:01:30 Is that ok? 19:01:48 Shall I go ahead and create one for empathy, and so on? 19:02:21 I think this category is too narrow, maybe we can create Gnome 3 Applications category 19:03:17 Martix: Yeah, or maybe just rename the gnome-shell category to gnome for the moment and dump everything there. 19:03:23 We can narrow it later? 19:03:40 Martix: the Package_ categories are used in Bodhi 19:04:05 Martix: see https://admin.fedoraproject.org/updates/FEDORA-2012-16988 19:04:09 I'm finishing some test cases, we can discuss wiki categories later :-) 19:04:24 Martix: so only include gnome-shell test cases in Package_gnome-shell category 19:04:32 kparal: >>> rishi 19:04:34 kparal: Ok. 19:05:07 kparal: martix: yeah, that looks right. 19:05:13 worth checking the history t osee who put them all in there 19:05:15 oh 19:05:23 kparal: I'll clean that later 19:07:54 adamw: I used other test cases as a template for writing news and didn't cared about categories, will fix when I finish more visible things related to tomorrows Test Day 19:08:41 anyway, please try and review test cases marked with {{result|pass}} 19:09:07 Martix: just remove the categories and it's fixed, that's trivial change 19:09:54 anyway, we finished proposed bugs, I'm leaving 19:10:16 kparal: I envy you :-) 19:10:26 I guess the fesco discussion may still take a long time 19:10:51 yeah, let's get the meeting done 19:11:13 * tflink will start but still wants to watch the resolution on beta freeze entrance 19:11:52 * tflink will skip any VERIFIED bugs 19:11:56 #topic (872446) ValueError: new size same as old size 19:11:56 #link https://bugzilla.redhat.com/show_bug.cgi?id=872446 19:11:56 #info Accepted Blocker, anaconda, ON_QA 19:13:32 jreznik_: are you going to send out announcements about unfreeze/schedule change? 19:13:50 some of these probably *are* verified and just keep getting squelched by fucking bodhi 19:14:06 does this need re-testing? 19:14:06 nirik: yep, I'll do it 19:14:07 this one's slightly special though 19:14:20 i think the current status here is that some cases of this are fixed, but not all 19:14:37 jreznik_: thanks. 19:14:39 now we're unfrozen it's probably less important, but i asked bcl for feedback in #31 and didn't get it yet 19:15:12 so, poke bcl again and/or wait for more testing? 19:15:51 given that we are unfrozen it's a question if we dont punt all blocker bug meetings until next week? 19:16:17 Viking-Ice: we still need to handle blockers - they don't get any less blockery 19:16:30 yeah, go/no-go should get punted, and possibly other meetings. 19:16:35 nirik: yep 19:16:53 for blocker meetings - should stay 19:16:58 and I guess infra is unfrozen, so wheee. ;) 19:17:18 #info still waiting on information from devs in bug about whether the most recent report is just a corner-case 19:18:12 anything else on this one? 19:18:24 not really 19:18:24 tflink, the anaconda guys are going to be pulling in fixes from master to beta so to me we should punt meetings until they have and we have an update to post for reporters to test to see if fixes have been applied 19:18:57 Viking-Ice: pulling from master won't really change things wrt any blockers, since the stuff that's in post-beta is everything that's not a blocker or nth fix, by definition. 19:19:37 Viking-Ice: I disagree. the earlier we find/approve blockers and poke fixes that may have stalled, the less likely we are to have a panic right before release or slip again 19:19:48 #topic (872739) AttributeError: 'NoneType' object has no attribute 'get' 19:19:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=872739 19:19:48 #info Accepted Blocker, anaconda, ON_QA 19:20:21 looks like this needs testing 19:20:32 this is VERIFIED 19:20:38 just got squelched by bodhi 19:21:03 #info this is actually VERIFIED, was moved back to ON_QA by bodhi 19:21:21 #topic (872791) TypeError: Argument 1 does not allow None as a value 19:21:22 #link https://bugzilla.redhat.com/show_bug.cgi?id=872791 19:21:22 #info Accepted Blocker, anaconda, ASSIGNED 19:21:47 failed QA in 18.26. 19:21:53 i need to reproduce it and add the tb. 19:22:07 can be reproduced just by installing in German, for me (i built a live to test) 19:22:24 #info this failed QA for anaconda-18.26 19:22:31 * jlk steps out to lunch 19:22:33 #info waiting for reproduction, logs and traceback 19:22:56 #topic (867593) installer must stop relying on being able to tell kpartx to use a disk/partition delimiter 19:22:59 #link https://bugzilla.redhat.com/show_bug.cgi?id=867593 19:23:02 #info Accepted Blocker, anaconda, ON_QA 19:23:24 #info this needs re-testing to check the fix 19:23:48 tflink: from someone with multipath or dmraid, note, which may be tricky 19:23:50 assuming that I understand the HW requirements here, I can probably do this later today 19:23:55 i have it in needinfo YOU at present :) 19:24:22 yeah, I need to figure out whether I have the HW to do this or not - I suspect not if you don't have the HW, though 19:25:03 well i don't have any multipath anything 19:25:10 i kinda thought you did or had access to one in beaker or smth 19:25:12 I think I have a box that uses dmraid 19:25:24 ah, that's the other option...dmraid is any *non* intel fw raid 19:25:38 nvidia fwraid is a common choice 19:25:39 yeah, I have a box with NVRAID and another with promise 19:25:43 ah, that should do it then 19:25:53 i only have intel fwraid and then *hw* raid 19:25:56 * tflink has way too much HW :-/ 19:26:21 anywho, I'll get to that later today 19:26:38 #action tflink to re-test w/ dmraid 19:26:49 #topic (869391) LUKSError: luks device has no key/passphrase 19:26:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=869391 19:26:49 #info Accepted Blocker, anaconda, ON_QA 19:27:44 looks like this still needs testing 19:27:50 I'm not seeing any VERIFIED in the history 19:28:13 #info a fix is available, more testing is needed 19:28:17 yeah. shouldn't be too hard to re-test. 19:28:26 #info request testing in bug 19:28:47 #topic (873463) TypeError: sequence item 1: expected string, DiskDevice found 19:28:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=873463 19:28:47 #info Accepted Blocker, anaconda, MODIFIED 19:30:02 it sounds like testing was done on the fix but it still needs re-testing on a released anaconda 19:30:15 yeah, i need an image with 18.26 to confirm 19:30:21 or 18.27. 19:30:56 adamw: smoke 15 is done but I forgot to say anything last night 19:31:18 haven't had the chance to test it myself and satellit seemed to be hitting some issues with it 19:31:35 ah 19:31:40 #info the fix has been tested in isolation but this still needs testing with a released anaconda 19:32:25 we have an 18.27? 19:32:50 #topic (868834) can't use package section in kickstart 19:32:51 #link https://bugzilla.redhat.com/show_bug.cgi?id=868834 19:32:51 #info Accepted Blocker, anaconda, ON_QA 19:33:12 sigh, another squelched VERIFIED 19:33:23 #info this is actually VERIFIED, was moved back to ON_QA by bodhi 19:33:51 tflink: we don't have 18.27, but we will 19:33:58 since we're unfreezing the idea is to kick anaconda back to master and kinda 'reset' 19:34:00 #topic (872047) fedup-dracut builds do not exist in F18 19:34:00 #link https://bugzilla.redhat.com/show_bug.cgi?id=872047 19:34:00 #info Accepted Blocker, fedup-dracut, ON_QA 19:34:08 so do an 18.27, a smoke16 (presumably), and see where we stand 19:34:27 * tflink wishes that the image building service was working, would love to trigger smoke builds on any successful anaconda build 19:34:48 as long as I'm in fantasy land, ponies anyone? 19:34:58 they're mighty tasty :-P 19:35:33 Sorry busy at fesco meeting and kinda need to run home now from work I'm starving 19:35:34 not sure what to do about this one. we do have fedup-dracut builds in F18 right now 19:35:56 so technically, we could move it to VERIFIED and wait for karma 19:36:18 but I'd be more -1 karma on the current build 19:36:49 any thoughts? 19:36:51 not sure we have to care too much at this point. 19:36:54 so long as we know where we are. 19:37:04 it's just bureaucracy with the current state of fedup. 19:37:37 yeah, I'm not testing from the currently packaged version, anyways 19:37:48 but the upgrade.img on fedorapeople is built from that 19:37:50 either way 19:38:19 #info there are now fedup-dracut builds in f18 updates-testing 19:38:38 #info move to VERIFIED and wait for a build to be pushed to stable 19:38:50 #topic (872361) parted shouldn't de-reference symlinks for named md devices(?) - this is blocking Intel fwraid support for F18 Beta 19:38:53 #link https://bugzilla.redhat.com/show_bug.cgi?id=872361 19:38:55 #info Accepted Blocker, parted, VERIFIED 19:39:13 oops 19:39:15 #undo 19:39:15 Removing item from minutes: 19:39:17 #undo 19:39:17 Removing item from minutes: 19:39:19 #undo 19:39:19 Removing item from minutes: 19:39:28 #topic (873387) After minimal install there is no login prompt on tty1 19:39:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=873387 19:39:28 #info Accepted Blocker, systemd, NEW 19:40:09 looks like there is active conversation in the comments, work is ongoing 19:40:42 i asked spot to look at this yesterday 19:40:55 that comment from bill came pretty early yesterday, so i'm not sure the pace is as frantic as i'd like 19:41:05 but hey, on the positive side, this will almost certainly magically go away now we're unfreezing 19:41:19 #info testing and some investigation is going on 19:41:30 adamw: the slow pace or the bug? 19:41:41 the bug. 19:41:45 since it doesn't happen with netinst 19:42:01 i bet that when we pull everything into stable, this'll magically disappear with tc8 19:42:38 #info retest with TC8 once everything has been pulled into stable, this may be fixed since it doesn't happen with netinstall 19:42:56 ok, I think that's all of the bugs on the list for today 19:43:00 did I miss anything? 19:43:10 gin? 19:43:55 I didn't really miss that, wasn't looking for it :) 19:43:58 beer, maybe 19:44:26 #topic Open Floor 19:44:54 rishi: thanks for your changes, feel free to modify/create test cases marked with {{result|fail}} 19:45:13 rishi: I need to leave now, see you tomorrow! 19:45:20 CRCinAU wanted to bring up the following bug as a possible final blocker 19:45:24 Martix: Have a nice evening! 19:45:32 rishi: thanks 19:45:36 https://bugzilla.redhat.com/show_bug.cgi?id=872608 19:45:59 * tflink doesn't quite know what to say about it, though 19:46:06 How can I set virt-manager network bridge it ? I set for my wifi card but I can't see local IPs in my virt-F18 ? any help hand please ? 19:46:44 it doesn't sound like a blocker to me, but I could be wrong 19:48:00 anyhow, it doesn't sound like there are people jumping to comment 19:48:34 #info if there are bugs that could be blockers, please propose them - preferrably with a criterion that the bug is violating 19:48:42 if there's nothing else ... 19:49:08 #info next blocker bug review meeting will be on 2012-11-14 @ 17:00 UTC 19:49:25 I think, it's at 17:00 UTC now since my announcement was corrected 19:49:33 either way ... 19:50:08 * tflink sets fuse for some discrete value GEQ 0 19:50:16 * tflink will send out minutes shortly 19:50:22 Thanks for coming everyone! 19:50:26 #endmeeting