17:00:33 #startmeeting F20 Final Go/No-Go meeting 17:00:33 Meeting started Thu Dec 12 17:00:33 2013 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:33 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:44 #meetingname F20 Final Go/No-Go meeting 17:00:44 The meeting name has been set to 'f20_final_go/no-go_meeting' 17:00:45 #topic Roll Call 17:00:51 * rbergeron is hereeth 17:01:07 * mkrizek is here 17:01:08 * satellit listening and testing RC1.1 17:01:11 * roshi is here 17:01:12 ok, so who's here for some fun? 17:01:14 * danofsatx-dt is present and accounted for, but a non-voting member 17:01:33 let's wait a moment for folks to show in - more people today, better 17:01:39 and hi everyone! 17:01:41 hello 17:01:43 * dan408 is here 17:02:13 * Southern_Gentlem 17:02:30 * kparal lurks 17:02:46 * nirik wonders if someone woke adamw up yet. ;) 17:03:24 he has his own go/no-go in his dreams 17:03:50 * handsome_pirate waves 17:03:50 I don't know if we should be so cruel and wake him up. the dream world might be a better place 17:03:56 lol 17:04:06 Lol 17:04:08 indeed. 17:04:13 Quick, someone plug an ethernet cable into his ear 17:04:27 #topic Purpose of this meeting 17:04:47 #info Purpose of this meeting is to see whether or not F20 Final is ready for shipment, according to the release criteria. 17:04:48 #info This is determined in a few ways: 17:04:50 #info No remaining blocker bugs 17:04:51 #info Test matrices for Final are fully completed 17:04:53 #info Fedora 20 Final Release Candidate (RC) is available 17:04:54 #link http://qa.fedoraproject.org/blockerbugs/milestone/20/final/buglist 17:04:56 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Final_RC1_Install 17:04:57 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Final_RC1_Base 17:04:59 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Final_RC1_Desktop 17:05:07 * jreznik expects we go that RC1 test matrices way... 17:05:27 * satellit also RC1.1 testing 17:05:27 we have RC1.1 matrices as well, they are nearly empty 17:06:05 kparal: the agreement earlier was to use RC1, so link is to RC1 but I can link also RC1.1 if you wish 17:06:10 lookin good 17:06:38 jreznik: ok, I wasn't aware of any agreements 17:06:55 * kparal might stop testing RC1.1 then 17:06:55 ok 17:07:08 let me dig it 17:07:25 will transfer results to RC-1 then for DVD i386 17:07:31 well, 1.1 is just 1 with some old/duplicate packages removed to allow the dvd to be undersized. 17:08:10 [11:36] do i need to make new test pages, or just reuse the existing ones and have people label their 1.1 results accordingly? 17:08:12 [11:37] robatino: keep the existing ones 17:08:13 [11:37] as long as rc1.1 sanity checks, it's basically identical 17:09:15 #info RC1 test matrices will be used for RC1.1 respin (but labelled accordingly) 17:09:26 #topic Current status 17:10:27 this time we have RC available, it's a combination of RC1 and RC1.1 due to issue with oversized DVD (so only DVDs are RC1.1) 17:11:06 but we also have quite a lot of proposed blockers before we can ack this RC 17:11:11 true 17:11:15 see the bug list 17:11:27 https://qa.fedoraproject.org/blockerbugs/milestone/20/final/buglist 17:12:46 and what's worst - this is probably last time to release F20 this year (and not to slip for a month) as holidays are coming... so please, keep this in mind we're somehow constrained in time 17:13:38 #info RC available - combination of RC1 and RC1.1 due to issue with oversized DVD 17:14:03 right 17:14:35 anything else to add to the current status? otherwise I'd ask our nice QA guys if anyone could lead us through proposed blocker bugs (I'll chair you, I promise) 17:15:14 * nirik really does think we might want to have someone sms adamw. ;) 17:15:21 i can go text him. 17:15:24 for someone it could be a nice christmas present if we slip a week but I expect we don't want to do this :) 17:15:33 * jreznik does not have his number in the phone 17:15:37 rbergeron: thanks 17:15:37 I can run the blocker part 17:15:44 roshi: thanks 17:15:56 #chair roshi 17:15:56 Current chairs: jreznik roshi 17:15:57 thanks rbergeron 17:16:04 just let me get set up real quick 17:16:51 someone want to secretarialize? 17:17:00 roshi: I'll do 17:17:06 thanks guys 17:17:21 sweet, thanks kparal 17:17:24 #info We'll be following the process outlined at: 17:17:24 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:17:24 #info The bugs up for review today are available at: 17:17:24 #link http://qa.fedoraproject.org/blockerbugs/current 17:17:25 #info The criteria for release blocking bugs can be found at: 17:17:25 #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria 17:17:25 #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria 17:17:26 #link https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria 17:17:44 here's what we have to work with: 17:17:49 #info 8 Proposed Blockers 17:17:49 #info 10 Accepted Blockers 17:17:49 #info 1 Proposed Freeze Exceptions 17:17:49 #info 18 Accepted Freeze Exceptions 17:17:57 onto proposed blockers! 17:18:02 onward! 17:18:11 #topic (1021507) DeviceCreateError: ("Can't have overlapping partitions.", 'sda3') 17:18:11 #link https://bugzilla.redhat.com/show_bug.cgi?id=1021507 17:18:11 #info Proposed Blocker, anaconda, NEW 17:18:32 * nirik reads 17:18:54 skip to comment 37 probably 17:19:04 before we did not know how to reproduce that 17:19:12 then greenlion found a reliable way 17:20:17 even though I have no idea whether it is even relevant to other reported crashes in that bug 17:20:29 probably not relevant 17:20:29 do we have some anaconda guys here? 17:20:50 so this is raid, lvm, resizing, and a partradge in a pear tree? 17:21:02 no resizing 17:21:03 they might be able to say how difficult or intrusive a fix will be 17:21:10 just changing size from default one 17:21:12 * kparal asked in #anaconda 17:21:13 kparal: you reproduced it - could you do a summary for us, or greenlion and some comments on impact how often we can see such layout? 17:21:16 also, input into how long slip will be if we have slippage 17:21:21 bcl: you around? 17:21:26 roshi: 3 weeks at least, likely 4 17:21:28 well, i have hailed the adam - 17:21:30 what kind of disks were they? 17:21:39 kparal: lurking 17:21:57 bcl: can you say something about this bug, comment 37+? 17:22:13 I reproduced it in a VM with 3 empty disks, following comment 40 verbatim 17:22:21 it's a bit complex setup, lot of changes 17:22:25 roshi: yep, expect 4+ weeks (as the first go/no-go would be right after new year) 17:22:33 such crash probably could be seen in other layouts, but I admit that it is quite complex 17:22:42 so, IMHO, this is a pretty complex/corner case, so I would be -1 blocker at this point for it. 17:22:42 right, and in those cases I'm pretty stongly against blocking. 17:23:17 dlehman: discussing https://bugzilla.redhat.com/show_bug.cgi?id=1021507#c37 and further comments 17:23:22 it seems not very common layout, unless it could affect other more common ones 17:23:34 what is this? more new bugs? 17:23:42 today's batch 17:23:46 I lean -1, due to the uncommon-ness of the setup 17:23:48 dlehman: complex custom raid/lvm/kitchen sink. ;) 17:24:26 there are two raids distributed over 3 disks 17:24:27 unless dlehman says it could affect less weird stuff, I lean to -1 either 17:25:03 dlehman: c40 is the description of the reproducer 17:25:09 Well, I've run into this bug with a single disk 17:25:33 * handsome_pirate wonders how he can lose ssh connection to a vm on his laptop. 17:25:53 PPC though, so still a corner case 17:26:03 I'm afraid that traceback might be quite generic. also, please note that abrt duped it into a bug where the error in c0 is completely different 17:26:07 you realize that comment 0, comment 36, comment 37 are all actually different errors 17:26:19 yeah, just saying that 17:26:22 yeah, this is a pile on... 17:26:58 abrt-- 17:27:10 Alas, I must go back to work 17:27:23 the only reliably reproducible error from this pile is c37-c42 17:27:34 morning 17:27:42 well, unless karsten__ has reproducers for the initial report. 17:27:45 hello 17:28:02 morning 17:28:10 adamw: Are you coming to us via ethernet cable plugged into your ear? 17:28:33 * nirik hands adamw a big mug of coffee 17:28:59 so far the count is -3 vs +0 17:29:06 i'm coming to you via the 'woken by a cellphone call from rbergeron' line 17:29:07 * roshi is keeping count for sanity sake 17:29:08 * handsome_pirate just saw notting 17:29:09 :P 17:29:30 installing two software raids at once is an obvious no. 17:29:31 roshi: if it's for that complex setup yes 17:29:35 roshi: -1, also 17:29:45 roshi: So, at this point, we're -1 blocker 17:29:53 yeah 17:29:59 proposed #agreed 1021507 - RejectedBlocker - While this would be considered a blocker on more common setups, two raids distributed over three disks is too much of a corner case to block final. 17:30:06 ack 17:30:08 ack 17:30:12 ack 17:30:13 ack 17:30:14 ack 17:30:28 i'd be a bit more worried about kparal's case, but if you can't pin that one... 17:30:33 #agreed 1021507 - RejectedBlocker - While this would be considered a blocker on more common setups, two raids distributed over three disks is too much of a corner case to block final. 17:30:34 * rbergeron hands adamw a big hug and 45 more apologies :( 17:30:35 adamw: can't 17:30:41 And, I'm going to loose wireless fore a few while I'm on the elevator 17:30:49 See y'all in a few 17:30:49 #topic (1033749) NoSuchGroup: 3d-printing 17:30:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=1033749 17:30:50 #info Proposed Blocker, anaconda, ASSIGNED 17:31:01 * roshi is just going to keep rolling through the list 17:31:23 i dunno what happened in the last 5 hours, but this is the one thing i saw last night that looks plausible for blocker 17:32:08 * nirik reads 17:32:21 so this is if you start installing from online and continue with dvd? 17:32:35 out of curiousity, how common is installing the 3d printing group from the DVD? 17:32:41 roshi: you don't have to be installing it 17:33:11 I was just curious if people did 17:33:14 i think this will happen any time you change from an installation source that contains everything to one with no package from the 3d printing group on it, or almost every time 17:33:14 that's all 17:33:26 roshi: i don't think you can 17:33:33 you just want to enter software selection dialog and it crashes 17:33:40 the reason the bug happens is because it's on the mirrors but not the DVD 17:33:47 yeah - that's a nasty crash 17:34:02 would this be other groups as well then? 17:34:05 it happens when the lists are really different. 17:34:06 everything not on the dvd? 17:34:09 kparal: can you guys please separate out the three distinct bugs being reporting in 1021507 so I can track them? 17:34:36 * satellit if no netowrking also or do not upgradechecked? 17:35:01 (and my patch fixed it for my testing, switching between 2 sources) 17:35:26 well, if networking was off, you wouldn't hit it the same way as it wouldn't be able to get the repos automatically on start 17:35:27 dlehman: replied in #anaconda 17:35:30 and it doesn't happen if you do it via inst.repo=nfs: but that's the question how bad it is 17:35:35 but if networking was off you couldn't use an NFS source in the first place 17:36:23 this is not restricted to nfs, right? should happen over http as well? 17:36:29 ah, I see... so this is because it's a optionlist... 17:36:34 I can quickly test 17:36:44 kparal: if my four hours of sleep are to be trusted, i think 'yes' 17:36:45 thanks kparal 17:37:29 so, okay, the basic use case here is 'do a network install and graphically select an ISO-based repo of some kind' 17:37:36 that's the realistic thing you're gonna be doing to hit this 17:37:46 * kparal testing over http 17:38:06 can't the mirrors be fixed in time for tuesday to match the rc1 dvd? 17:38:25 eight: it wouldn't be a fix it'd be a nasty bodge 17:38:25 and then forever :) 17:38:40 and i can't think of a way to do it that doesn't also require us to rebuild the dvds, unfortunately 17:38:44 neither can dgilmore 17:38:51 the criterion we're looking at is "The installer must be able to use all supported local and remote package and installer sources." 17:38:53 * nirik ponders 17:38:59 https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Package_and_installer_sources 17:39:01 crashes also over http 17:39:11 +1 17:39:16 yeah, I mean we could remove that optionlist from comps, but thats kinda nasty... 17:39:26 i mean, can it? yeah, sure, it can... 17:39:37 nirik: the problem then is we should rebuild the images because we poked comps 17:39:47 yeah. 17:39:52 yep. 17:39:55 how fast could this be fixed? 17:39:57 we could fudge this, but it's kind of ucky 17:40:02 could this be fixed in a updates.img? 17:40:10 or i can entirely see blocking on it. 17:40:52 I'd rather fix it right. 17:40:59 how long would it take to fix? 17:41:10 if this was teh only blocker, how long? 17:41:27 i think bcl said he had a test patch already 17:41:28 dunno. it seems similar to the environments so maybe not log. 17:41:30 long. 17:41:31 for simple/fast fix we could try less than week fix... 17:41:46 adamw: no, I was referring to the patch for env. 17:41:52 bcl: oh, right. 17:42:03 so, votes? 17:42:16 * nirik sighs. trying to think of a way around. 17:42:19 bcl: what would you think about blockeriness? i mean, you can workaround it. sure. it also seems kinda easyish to hit. i dunno. 17:43:00 nirik: it's not actually that hard to fudge in purely technical terms - the criterion's vague. i just kinda feel icky doing it, it seems like we ought to fix it. 17:43:09 yeah. I know. 17:43:26 I'm just trying to think of how many people this would actually affect... 17:43:32 but then i also like christmases where i'm sane. 17:43:43 have there been any of those? ;) 17:43:49 ask my mom 17:43:51 yeah, it seems like booting a dvd and switching to network would be a common use case. 17:44:00 we at least try to make sure that they're not consecutive years of insanity :) 17:44:04 well, if you boot the dvd, it defaults to dvd right? 17:44:07 this isn't a thing that can be covered in CommonBugs "Just don't switch sources." 17:44:15 right? 17:44:15 nirik: right 17:44:31 you can work around with askmethod as well. 17:44:32 nirik: you're fairly unlikely to boot the DVD and then switch to a network source containing the dvd iso. 17:44:34 it's only if you boot netinstall, then switch to a local exploded dvd source 17:44:35 isn't it going from net to dvd that's the issue? 17:44:36 i mean, why would you do that? 17:44:47 adamw: hell if I know. ;) 17:45:04 bcl: oh, just go direct to your source? 17:45:06 roshi: it is switching between sources with different groups. 17:45:17 i can't conceive of a circumstance where you'd be using the DVD ISO as a repo where you *wouldn't* usually be booting the ysstems to be installed from netinst or the kernel pair 17:45:18 * kparal tries to boot dvd and switch to closest mirror 17:45:22 * nirik is now leaning to -1... commonbugs and say workarounds. 17:45:50 bcl: oh right, askmethod tells it not to configure the repo 17:45:52 but then if we' 17:45:57 a) dont switch sources, use net, or b) askmethod 17:46:03 nirik: a) is not a workaround 17:46:12 well, yeah, true... 17:46:12 if I boot from DVD and switch to Closest mirror, it works 17:46:19 you can't 'not switch sources' if you boot from the netinst with a working internet connection 17:46:22 just a 'way that works but doesn't do exactly what you want' 17:46:36 adamw: I can - I have a disconnected network for security reasons. We use netinst to kick off the install and point it at our local repo, which is exploded DVD 17:46:54 danofsatx: that's...um...not contrary to what I said? 17:47:07 so, I guess more clear: a) don't switch to a dvd tree, stick with everything, or b) askmethod 17:47:07 danofsatx: if you booted your clients from the DVD and then pointed it at an exploded DVD repo, that'd be contrary. 17:47:21 or c) repo=nfs:blahblah 17:47:37 does it behave same with lives? 17:47:37 yeah, so I feel less bad given the workarounds. 17:47:39 point 17:47:51 greenlion: you can't switch repos with lives 17:47:54 yeah 17:47:57 ah, true 17:48:08 It's a procedure that was in place before I arrived. I'm converting to PXEboot, so it won't be an issue for me, personally. 17:48:16 danofsatx: your case, in fact, will work fine 17:48:41 your systems are offline so they won't be able to set up the default repos 17:48:48 that case wouldn't be able to get the repos 17:48:52 or, what adamw said 17:48:53 so anyone doing things dan's way won't hit this, fwiw 17:48:57 ok, then I misunderstood the bug. I'll be under my rock if y'all need me. 17:49:08 so votes? 17:49:23 so, I will be -1 then... document and common bugs and fix for next release, if any of us are alive then. 17:49:34 I'll revise my +1 since it seems a really obfuscated means of installing 17:49:45 i still feel kinda bad about it, but given that you can definitely achieve the goal in several ways and i *think* it's not hugely common to use this 'iso-as-repo' trick interactively, slight -1 17:49:50 2013 already happened nirik - we're all in the afterlife now 17:49:59 -1 17:50:06 roshi: nooooo... this is not how I imagined it would be! :) 17:50:09 -1 blocker given that there's a workaround (inst.repo) 17:50:21 roshi: it's not that obfuscated, i don't think, but i do suspect people using it will tend to do it via cmdline or with non-internet-connected hosts, neither of which case should hit the bug 17:50:41 nirik: good thing is, you get to decide on your interpretation of where you ended up :P 17:50:42 * satellit-RC1DVD sugar HD install here 17:50:43 god christ i didn't even have coffee yet 17:50:49 on no account take any notice of anything i'm saying 17:51:02 adamw: see, you have good denialbility later. ;) 17:51:13 i seens it 17:51:15 adamw is a master 17:51:56 anyways 17:52:13 been lurking, dont think this is worth delaying the release over 17:52:16 proposed #agreed - 1033749 - RejectedBlocker - This bug has several workarounds available and is not a largely common method of installation and is thus not considered a blocker. Document as CommonBugs. 17:52:20 ack 17:52:23 ack 17:52:24 ack 17:52:40 #agreed - 1033749 - RejectedBlocker - This bug has several workarounds available and is not a largely common method of installation and is thus not considered a blocker. Document as CommonBugs. 17:52:43 * jreznik does not feel very well about it but ack 17:52:53 i am also curious to look into why we didn't know about this earlier 17:53:01 for the record, I always count myself as an implicit ack since I wrote it 17:53:01 but we can do that later 17:53:07 this is true adamw 17:53:09 ack 17:53:22 is anyone secretaryfying btw? 17:53:22 #topic (1038855) in rescue mode, when exiting rescue shell, instead of menu, get "Pane is dead" 17:53:22 #link https://bugzilla.redhat.com/show_bug.cgi?id=1038855 17:53:22 #info Proposed Blocker, anaconda, NEW 17:53:27 kparal: has it 17:53:28 oh hell no. 17:53:38 -1, next bug. 17:53:42 -1 17:53:42 * nirik reads the next item on the menu 17:53:59 -1, ugly, but oh well. 17:54:10 -1 17:54:23 we clearly don't care about this if we didn't spot it till 12-05 17:54:29 if we want to start blocking on it we ought to care. 17:54:31 adamw: Petr hit it, so we knew about it earlier but probably just saw it's modified and forget about it (for the previous one) 17:54:36 I proposed it mainly for FE if we slip 17:54:43 I'm -1 blocker as well 17:54:50 jreznik: oh, right, there was the other bug camouflaging it 17:54:51 yeah, +1 FE (hopefully it doesn't matter tho) 17:54:54 i hate those 17:54:59 +1 FE whatever. 17:55:07 +1 fe 17:55:13 +1 FE 17:55:16 +1 FE 17:55:27 +1 FE 17:55:32 proposed #agreed - 1038855 - RejectedBlocker AcceptedFreezeException - This bug is not considered to block release. A fix will be considered sometime. 17:55:44 ack 17:55:47 ack 17:55:48 ack 17:55:48 ack 17:55:49 (love the sometime) 17:55:51 ack 17:56:01 * roshi didn't expect no patch, but cool 17:56:06 #agreed - 1038855 - RejectedBlocker AcceptedFreezeException - This bug is not considered to block release. A fix will be considered sometime. 17:56:10 on a side note: it'd be nice if someone proposed a change to overhaul rescue mode 17:56:24 just don't let your installs need rescued 17:56:26 :P 17:56:29 17:56:32 yeah, not holding my breath 17:56:33 and if there were people willing to work on implementing those changes. ;) 17:56:53 :) 17:56:57 #topic (1040716) LVMError: pvcreate failed for /dev/md/00: running lvm pvcreate --dataalignment 1024k /dev/md/00 failed 17:56:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=1040716 17:56:57 #info Proposed Blocker, anaconda, NEW 17:57:38 oh i'll CONSIDER yer fix anytime, mister 17:57:42 i'm CONSIDERING yer fix right now 17:57:59 er, okay. so yeah, when i hit this i didn't think it was a blocker and i still don't 17:58:00 * pwhalen joins very late 17:58:08 -1/+1 17:58:21 I could not reproduce it 17:58:22 seems like another of the 'did a bunch of things' bugs. 17:58:26 if kparal can't reproduce that just makes me more -1 17:58:34 bcl: yep. 17:58:38 srsly, quit fuzz testing the installer! 17:58:54 bcl: it was definitely reproducible for me following my steps, and they are each actually logical things (there's no 'oops i changed my mind' or 'oops i did iit wrong') 17:59:08 but it's a very complicated layout and you *can* achieve it, by at least two other methods 17:59:11 roshi: it's not a bad idea to fuzz test installer but not for blockers 17:59:24 I was being facetious :) 17:59:27 and not this late in the game. 18:00:00 -1 18:00:03 I haven't tried to reproduce c0, just c11 18:00:09 -1 18:00:14 -1 18:00:36 -1 18:01:01 proposed #agreed - 1040716 - RejectedBlocker - This bug hasn't been reproduced and the same end result can be achieved via two other methods. 18:01:14 ack 18:01:16 ack 18:01:18 should that be a common bugs or what? since people might come back asking what the other two methods are... 18:01:18 ack 18:01:30 ack 18:01:38 please sprinkle commonbugs juice on everything, kparal 18:01:45 #agreed - 1040716 - RejectedBlocker - This bug hasn't been reproduced and the same end result can be achieved via two other methods. 18:01:54 roger, mass bugzilla update with commonbugs 18:02:05 #topic (1040922) Panorama Stitcher (panoramagui) crashes on start if not passed any files 18:02:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=1040922 18:02:05 #info Proposed Blocker, digikam, ON_QA 18:02:30 now this on the other hand is arguably harder to fudge, but i'm way happier fudging it 18:03:04 -1/+1, can be fixed in update? 18:03:12 KDE ships approximately sixty three thousand goddamn ridiculous things in its menus, esp. if installed via DVD. we should probably modify this criterion because i don't think we can toe the line for KDE 18:03:13 well, for me this one is easier to fudge - it's not on live, on DVD install it could go out as update 18:03:15 FE? 18:03:48 so i'm fine with -1ing this possibly with a #agreed to water down the relevant criterion for KDE, maybe to 'real standalone apps installed via live' 18:03:48 if it's fixed upstream seems like a simple fix? 18:03:50 adamw: as we as KDE SIG try to put as many things to DVD but recommend Live as a selection of software we stand behins 18:03:55 yeah, even more -1 if it's not on live... there's no way everything in the distro can be tested for menus (unless we had an automated test for it) 18:04:01 dan408: I already built it 18:04:18 -1 18:04:20 esp. if KDE SIG doesn't believe it wants to back the criterion as written 18:04:20 so what's wrong with FEing this? 18:04:23 j/w 18:04:29 FE, sure, if we were slipping 18:04:32 dan408: nothing. sure. 18:04:34 k 18:04:37 -1 18:04:39 also it's plugin - intended use case is to call it from digikam etc. 18:04:48 that's why this bug happened and it's pretty recent one 18:04:51 nirik: it can be tested. it involves adam with a stiff drink, swearing at the KDE developers 18:05:02 hah 18:05:11 nirik: i started counting the number of options in the KDE control center at one point, but the integer overflowed 18:05:16 yeah. 18:05:31 adamw: and many options are hidden in config files :) 18:05:39 many more 18:05:44 christ on a bike, you could fly that fucking thing to mars 18:05:56 * jreznik is -1 for the reasons he explained 18:05:57 proposed #agreed - 1040922 - RejectedBlocker - This bug is only relating to DVD installation and the KDE-SIG recommends Live installation. Criteria to be re-evaluated for F21. 18:06:11 ack 18:06:18 but in case of slip, I'm +1 FE and for chaning this criterion to cover live only for KDE 18:06:18 ack 18:06:18 ack 18:06:20 ack 18:06:37 (or we have to limit what's on DVD - but that's reason for DVD to throw things there) 18:06:41 ack 18:06:45 so how do we want to annotate FE if slip? 18:06:48 or do we? 18:06:53 roshi: yes please 18:06:53 but hey, f21 may not even have a dvd. ;) 18:07:02 nirik: I hope for :D 18:07:03 jreznik: the criteria are flexible based on what the backing teams consider the goal, to some extent. 18:07:04 lol 18:07:20 * nirik gets another cup of coffee. 18:07:24 jreznik: if KDE's goal is 'live is a polished product, DVD install has all sorts of stuff on it and some of it might not work', we can certainly make the criteria reflect that. 18:07:25 #info 1040922 to be considered FE if release slips 18:08:07 ah, shit, no-one did HW raid yet? 18:08:21 #topic (1040760) Updated build for F20 release notes 18:08:21 #link https://bugzilla.redhat.com/show_bug.cgi?id=1040760 18:08:21 #info Proposed Blocker, fedora-release-notes, ON_QA 18:08:36 roshi: there was no #agreed 18:08:40 oh 18:08:42 yeah 18:08:47 triple #undo 18:09:02 I think I can just #agree and it'll work, right? 18:09:11 the minutes will be wrong 18:09:13 #undo 18:09:13 Removing item from minutes: 18:09:15 interesting to see the blocker reviews happening on the no go meeting 18:09:15 #undo 18:09:15 Removing item from minutes: 18:09:19 #undo 18:09:19 Removing item from minutes: 18:09:36 #agreed - 1040922 - RejectedBlocker - This bug is only relating to DVD installation and the KDE-SIG recommends Live installation. Criteria to be re-evaluated for F21. 18:09:41 #topic (1040760) Updated build for F20 release notes 18:09:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1040760 18:09:41 #info Proposed Blocker, fedora-release-notes, ON_QA 18:09:49 * randomuser perks up 18:09:52 -1/+1 18:09:56 Viking-Ice: is this not normal? 18:10:13 Viking-Ice: we've done that for the last few releases... 18:10:22 I'm reluctantly +1 FE on this 18:10:26 how else can we evaluate 'em? 18:10:39 -1. we asked them for final release notes, they gave us something they called final releases notes 18:10:43 I'm aware of that but not this channel ( expectation blocker-review ) anywho 18:10:45 you don't get...release note backsies 18:10:51 let's not dwell on the subject 18:11:08 Viking-Ice: for two releases we do it this way and you were involved several times :) 18:11:17 especially not if you're going to try and invoke them the day before go/no-go when we should alreday have tested the RC and got to the bar but didn't because we suck. 18:11:32 -1 18:12:03 +1 FE if we slip for some reason, sure. 18:12:03 will only affect DVDs, right? 18:12:15 * randomuser pours a shot of jameson into adamw's coffee 18:12:15 -1/+1 and yes, I expected that previous release notes are that ONE as I talked to guys 18:12:17 moar votes? 18:12:19 -1/+1 18:12:34 roshi: anywhere the relnotes are static (shipped images, repos i think) but yeah, the online copy can keep getting updated 18:12:54 right, no problem updating the online copy 18:13:15 randomuser: i would prefer a shot of coffee at this point 18:13:22 yes. in my coffee. 18:13:25 proposed #agreed - 1040760 - RejectedBlocker - This issue is minor and will only affect static versions of the Release Notes. A fix will be considered if we slip. 18:13:39 ack 18:13:39 ack 18:13:42 ack 18:13:48 how do we annotate conditional FE? or is that fine? 18:14:09 thats fine, IMHO 18:14:10 just acceptedfe is fine 18:14:13 #agreed - 1040760 - RejectedBlocker - This issue is minor and will only affect static versions of the Release Notes. A fix will be considered if we slip. 18:14:13 we have to accept that as an FE right 18:14:16 fwiw, I was following the blocker process mostly to make sure that the newer version got in the next RC 18:14:17 there shouldn't be any need to make it conditional. 18:14:28 i mean, if we don't slip, obviously nothing gets into any builds because we don't do any. 18:14:29 right 18:14:34 * nirik nods 18:14:36 patch, or are we good? 18:14:44 good I would think 18:14:49 good for me 18:14:55 kk, moving on 18:14:57 #topic (1008965) mouse cursor sometimes disappears on login 18:14:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=1008965 18:14:57 #info Proposed Blocker, gnome-desktop, ASSIGNED 18:16:00 i haven't seen this since the fix went in 18:16:06 i asked around on IRC and no-one else seems to have 18:16:18 so i think the guy who re-opened this has either some weird corner case or some other bug entirely 18:16:32 unless people here have seen this bug since the fix went into GNOME...i'm -1 18:16:37 -/-+ 18:16:43 -/- 18:16:45 frack 18:16:46 -1 18:16:52 1-/-1 18:17:09 Viking-Ice: you have last try! 18:17:16 -1/-1 18:17:19 lol 18:17:21 -1/-1 18:17:26 -1 18:17:59 -1 18:18:10 * rbergeron will throw in her -1 as well 18:18:22 proposed #agreed - 1008965 - RejectedBlocker - This bug hasn't been seen by a preponderance of users and there are known workarounds from when the bug was first proposed. 18:18:25 (we lived with it for a while anyway it seems) 18:18:37 ack 18:18:47 ack 18:18:54 ack 18:18:55 ack 18:18:57 #agreed - 1008965 - RejectedBlocker - This bug hasn't been seen by a preponderance of users and there are known workarounds from when the bug was first proposed. 18:19:07 last one folks 18:19:19 #topic (1021749) Review Request: php-symfony - PHP framework for web projects 18:19:19 #link https://bugzilla.redhat.com/show_bug.cgi?id=1021749 18:19:19 #info Proposed Blocker, Package Review, ON_QA 18:19:35 -1/+1 18:19:55 oh, this is left on from the previous meeting 18:19:57 it's in RC1 anyway 18:19:58 rogjt 18:20:01 right 18:20:07 just handwave it and move on, no point wasting time 18:20:10 so, -1 blocker 18:20:11 yep 18:20:12 yep 18:20:13 -1 18:20:29 i don't even remember what we were gonna do after we punted, anyhow, -1 18:20:38 proposed #agreed - 1008965 - RejectedBlocker - The fix for this is already in RC1. Nothing to see here. 18:20:43 ack 18:20:45 make sure it doesn't fall off acceptedFE list though 18:20:48 ack 18:20:51 ack 18:20:53 ack. 18:20:57 #agreed - 1008965 - RejectedBlocker - The fix for this is already in RC1. Nothing to see here. 18:21:04 onto proposed FE? 18:21:19 no, accepted blockers, I think 18:21:19 or do accepted blockers? 18:21:19 the one 18:21:25 FE+ 18:21:28 expect those that are verified 18:21:41 i think for go/no-go purposes all we need is proposed blockers 18:21:46 there's no point in FE if we don't slip 18:21:49 we can do another meeting for proposed FE if we slip 18:21:49 yep 18:21:50 ok 18:22:03 more like we will if we slip 18:22:21 well, we only have three that aren't VERIFIED 18:22:23 #topic (1000891) DVD is oversized (larger than 4.7 GB) 18:22:23 #link https://bugzilla.redhat.com/show_bug.cgi?id=1000891 18:22:23 #info Accepted Blocker, distribution, NEW 18:22:29 fine with RC1.1, right? 18:22:32 1.1 was made to address this. 18:22:33 someone set it to VERIFIED 18:23:01 I can set it. has somebody verified it? :) 18:23:06 Length: 4679794688 (4.4G) [application/octet-stream] 18:23:22 sure, dgilmore and robatino 18:23:24 i'll do it and report the reduced size 18:23:36 robatino: thanks 18:23:46 wow, 0.3? should add some more to the dvd then ;) 18:23:48 #info 1000891 has already been fixed as of RC1.1 - just needed updated 18:24:07 anything else on this one? 18:24:25 * roshi moves on 18:24:27 #topic (1026860) lvm2: services specified with SYSTEMD_WANTS are not started for some LVM volumes 18:24:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=1026860 18:24:27 #info Accepted Blocker, lvm2, MODIFIED 18:24:27 next bug 18:24:33 too slow 18:24:40 heh 18:24:56 so this is just the one we decided not to take the harder fix for 18:25:02 we have the systemd workaround in RC1 18:25:45 somehow we forgot to to make note of that in the bug 18:26:09 .fire someone 18:26:09 adamw fires someone 18:26:23 so the fix is in? 18:26:34 and with that fix it was confirmed to work 18:26:50 if someone confirms it with RC1 that'd be nice. did they? i didn't look 18:27:05 #info the fix for 1026860 is in RC1 and is confirmed to work 18:27:45 I'll remove the blocker nomination then 18:27:54 thanks 18:28:00 last one not VERIFIED 18:28:02 #topic (1035536) Final spin-kickstarts build required for Fedora 20 GA 18:28:02 #link https://bugzilla.redhat.com/show_bug.cgi?id=1035536 18:28:02 #info Accepted Blocker, spin-kickstarts, ON_QA 18:28:47 well, we built a package and i listed it for final rc1 18:28:54 last comment says it's done 18:29:01 i haven't actually triple checked that it's correct 18:29:29 #info 1035536 seems to be done. 18:29:31 but i can do if you give me 5 seconds 18:29:34 sure 18:29:48 * roshi will #undo if it isn't correct 18:30:24 we also are missing the selinux issue we punted right 1040444 18:30:29 if I'm not mistaken 18:31:00 yeah, should circle back and check that. 18:31:03 huh, wonder why that hasn't come up 18:31:10 anyway, i didn't see it in rc1 testing, did anyone? 18:31:15 Viking-Ice: I removed the nomination because it doesn't occur with RC1 18:31:31 I didn't see it anywhere 18:31:34 * nirik didn't see any denials here. 18:31:35 what why not just deal with it on the meeting 18:31:35 ok 18:32:16 kparal, if you remove proposals they fall of the radar bad habit 18:32:32 I verified it's not present 18:32:35 yeah, probably would've been better to leave it on, but no harm done 18:32:36 ( think regressions between development releases ) 18:32:48 point 18:32:50 i just verified spin-kickstarts, looks fine 18:32:58 can you un-nominate things you nominate? 18:33:01 yeah, I'd still prefer to have it on list even it was invalid one 18:33:04 good to hear 18:33:14 Viking-Ice: you cant go through all of bugzilla in the meeting, after all... 18:33:21 well, that's all the blockers, proposed and otherwise 18:33:37 mclasen: we try to :) 18:33:45 and by my count, all the ones that aren't listed verified are accounted for with fixes 18:33:47 mclasen, procedures 18:34:09 so, I think all the blockers are handled - unless I'm understanding wrong 18:34:19 mclasen, they are in place for a reason 18:34:30 i don't think we missed any 18:34:43 so, from a blocker standpoint... 18:34:44 we have covered all afaik spot 18:34:45 the list seems to be cleared! 18:34:47 are we a go? 18:34:55 * roshi doesn't feel like that can be right 18:34:56 roshi: not yet 18:35:01 test coverage 18:35:05 from a blocker standpoint is all 18:35:06 as in 18:35:11 blockers are the thing stopping the go 18:35:23 it looks like there are now no outstanding unaddressed blockers, yes. 18:35:28 ok 18:35:34 that's all I was saying 18:35:36 that deserves an #indo 18:35:41 even #info 18:35:51 kparal: working on it 18:35:53 #info all blockers for F20 Final are addressed 18:35:59 yay 18:36:08 #indo All blockers for F20 Final are addressed 18:36:11 roshi: well, I wanted it in the new topic, but ok :) 18:36:12 blocker martial arts formerly known as indo 18:36:15 just for you, kparal 18:36:25 thank you 18:36:39 sorry jreznik, you can have the meeting back now 18:36:43 so I'm not going to undo it, especially as kparal is now happy :) 18:36:59 #topic Test matrices coverage 18:37:34 so we still have a few gaps 18:37:39 i'm running a hardware RAID install right now 18:37:46 pwhalen is on ARM 18:38:08 iscsi was done at tc4, might be nice to check it if someone who has a non-problematic iscsi target is around 18:38:12 let's provide the link 18:38:14 links 18:38:19 * nirik ran Xfce and cloud last night, a bunch of 32bit rc 1.1 dvd's today 18:38:25 https://fedoraproject.org/wiki/Test_Results:Fedora_20_Final_RC1.1_Desktop#Release-blocking_desktops:_x86_.2F_x86_64 18:38:26 litd-USB of i386 DVD RC1.1 work as installs to HD 18:38:28 we have RC1 and RC1.1 matrices 18:38:33 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Final_RC1_Install 18:38:34 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Final_RC1_Base 18:38:36 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Final_RC1_Desktop 18:38:49 #link https://fedoraproject.org/wiki/Test_Results:Fedora_20_Final_RC1.1_Install 18:38:50 somehow we forgot to check updates for the desktop live, but it's been fine throughout final and the packages didn't change between tc5 and rc1 18:38:51 whoops, disregard me....back under my rock 18:38:57 so seems unlikely it's magically broken 18:39:25 did anyone get secure boot recently? 18:39:40 hm, at Beta I think 18:39:44 I can test it now 18:39:49 i did desktop_menus for desktop at TC5 and it was fine, and we haven't changed any gnome apps between then and now and hell if i'm doing it all again 18:39:54 yeah, SB test would be nice 18:40:06 libreoffice still works, i checked that 18:40:39 (he said, surreptitiously checking it in the background) 18:40:40 well I experienced the shim failure update but know have shim-0.7-1 and it works fine here 18:40:49 * kparal is running SB install 18:41:06 so let's do the thing where we drag out the meeting while we check the last few boxes 18:41:28 * adamw runs random gnome apps while he waits for the hwraid install. will yell if anything breaks. 18:41:51 * Viking-Ice performs an Egyptian dance on the desk at the office 18:42:26 * jreznik will silent yelling adamw! 18:42:49 pics or it didn't happen, viking_ice ;) 18:42:57 * nirik pushes f18/f19 updates. 18:43:48 rc 1.1 KDE install works i386 to HD 18:44:39 rbergeron: nonononono. gifs or it didn't happen 18:45:08 anyone around who can do iscsi? 18:45:14 adamw: animated? ;) 18:45:30 SB install works well. tested from netinst on optical disk 18:46:21 whee 18:49:38 * satellit doing a yum install @sugar-desktop sugar-runner to RC1.1 KDE HD install atm 18:49:53 install from physical 64-bit netinst to hw raid works 18:50:29 good to hear 18:51:26 so it be clear then, are we planning on shipping just the 32bit dvd from rc 1.1, and everything else from 1? 18:51:52 i think we should ship at least both dvds from rc1 18:51:54 er rc1.1 18:51:56 for consistency 18:52:02 lives etc from rc1 18:52:12 netinst...eh, they should be identical really. rc1.1 i guess 18:52:31 adamw: the Lives are identical 18:52:40 * jreznik agrees with adamw 18:52:46 netinst images have different checksum 18:52:47 ok, so the dvd's will have slightly different Fedora/ than the tree... I guess it doesn't matter... 18:53:09 nirik: how do you mean? 18:53:10 everything under Images/, Live/ and Spins/ is identical 18:53:30 robatino: that's because they weren't built for RC1.1, they were copied from RC1 :) 18:53:38 what's in the RC1.1 dir is what we'd ship, i think. 18:54:10 adamw: the rc1 and rc1.1 Packages/ dir's are the same... but the dvd's don't have those old libreoffice packages in them. (and I assume different repodata, etc) 18:54:27 xorg-x11-server-Xephyr is not loaded with sugar-runner so have to do separate yum install of it.....(non blocking) 18:54:33 It might be dgilmore just copied over that from rc1... and we have another tree without them 18:54:54 * nirik looks more. 18:55:03 nirik: well, i assumed we'd use a tree that matched rc1.1? 18:55:59 trust but verify? :/ 18:56:05 lol 18:58:28 adamw: well, the public 1.1 tree is the same as 1. 18:58:39 ie, both have the libreoffice*-6 old packages in them 18:59:19 um. we can sort that out later if need be, right? 18:59:23 probably need to talk to dgilmore 18:59:32 yeah. I'm not sure how big a deal it is. 19:00:06 * jreznik can add it to the RC ticket confirmation for dgilmore 19:00:20 so what's missing now from matrices? 19:00:47 pwhalen: how does it look like with arm? 19:00:47 1 sec 19:01:28 jreznik, havent hit anything new, KDE desktop almost finished on the 1.1 matrix 19:01:43 so did fesco decide to push arm to primary this release or is it still on hold ? 19:01:54 release blocking images boot tested and working 19:01:55 yes, it was decided to long ago... 19:02:03 unless there were stoppers at alpha 19:02:12 pwhalen: ah, I see - you're filling in RC1.1 one! 19:02:23 one silly updates.img source test we did at tc5 19:02:35 iscsi and xen, xen was done for tc5 19:02:37 nirik, seem to have missed me and I do believe every news paper headlines 19:03:25 it's right at the top of the f20 changes... 19:03:26 pwhalen: could you copy it over to RC1 matrix? we want to use that one 19:03:27 http://fedoraproject.org/wiki/Releases/20/ChangeSet#ARM_as_primary_Architecture 19:03:42 ah ok 19:04:04 if it's not published on lwn it never happened ;) 19:04:11 jreznik, sure.. 19:04:16 pwhalen: thanks! 19:04:25 kde login, gnome updates tests, i guess 19:04:31 it was on lwn, iirc :) 19:04:55 Viking-Ice: the idea was to let it open it would lead to a real bad situations 19:05:04 gnome updates is a bit of a pain to verify now because there's no updates in the repos and i dunno what quirks there are in gnome-software if you try and test it by enabling u-t 19:05:27 pwhalen, then there you have it it's official ;) 19:07:22 it was definitely working as of tc5 and shell / gnome-software has not changed since 19:08:26 i'll try and hack up a test 19:08:56 anyone want to take KDE login? 19:09:26 will try i386 19:09:31 that was last done at tc4 19:09:58 though i've tested most login stuff in other rc1 kde testing and it's fine, just not all the 'different keyboard layout' and 'try a wrong password' shenanigans 19:11:04 I actually don't like this testcase... so I'd go with that basic login that everyone tried dozen times 19:11:27 jreznik: it's necessary because we've broken keyboard layout stuff quite often before 19:11:29 not useing keboard layout 19:11:33 since we put this test case in, it hasn't happened 19:11:43 we used to get lots of bugs like 'login screen is using the wrong layout; 19:11:59 i'd be very surprised if it was broken here, though. 19:12:22 i mean, i can do it in a bit, just on two other tests right now 19:12:28 works on HD install with 2nd user logout/login 19:13:01 * satellit to origial user 19:13:21 so covered, right? could you mark it down? 19:13:46 he didn't test with a different keymap, but otherwise yeah 19:13:49 could call it a partial pass 19:14:22 efi netinst boot and install to firmware raid, pass 19:17:40 * adamw bodging up a gnome updates test 19:19:16 i'm gonna just copy in the gnome menus test from tc5, i've done enough random sampling with rc1 to say it works 19:21:09 i haven't broken rc1 installations in any significant way 19:21:50 seeing as things break when i merely look at them, that's saying something 19:21:51 it's worked fine for me throughout all the tests 19:22:16 if you weren't so mean, cmurf, that wouldn't always happen 19:22:37 * roshi kids. Has no idea if cmurf is mean or not 19:22:39 my computers develop a distinct sense of humor, quickly 19:22:41 or fail 19:22:45 lol 19:22:49 updated KDE https://fedoraproject.org/wiki/Test_Results:Fedora_20_Final_RC1.1_Desktop#Release-blocking_desktops:_x86_.2F_x86_64 19:23:11 wrong matrice satellit 19:23:28 satellit: please use RC1 19:23:47 this is 1.1 ok will copy it 19:24:23 whew, thank christ, update notification works. 19:24:28 for a horrible second there i thought it was broken. 19:25:16 i think it may have a bug if you enable updates-testing after it's already run a check, or something, but for the usual case (just using 'updates' repo) it should be okay 19:25:51 i get notificashunz 19:26:23 i did a clean test by installing rc1 desktop live, booting to runlevel 3, enabling updates-testing then booting to runlevel 5 19:26:30 it also seems to actually do the update correctly, after reboot, yum update says nothing to update 19:26:36 yeah, mine's installing updates now 19:26:38 so that's good 19:28:25 so let's see 19:28:51 copied 19:29:11 pwhalen's signed off on the blocker arm tests for install 19:29:25 and base 19:30:04 missing update notification/install and keyring for KDE, they all work for x86 19:30:11 pwhalen: are you running those tests? 19:30:16 we also don't have any cloud tests in 19:30:22 anyone can check the clouds quickly? 19:30:36 adamw, yes 19:30:54 pwhalen: great 19:31:00 thanks :) 19:31:04 * adamw kicks off a full kde login test 19:31:32 for the delta ISO are we testing RC1.1 or RC1 19:32:28 sorry? for what deltaiso? 19:32:37 I tested openstack with rc1... ? or are we talking ami? 19:33:23 there are two DVD ISO diso files: TC5 to RC1, and RC1 to RC1.1 19:33:29 nirik: oh, so you did - but the Base results are missing 19:33:29 deltaiso for DVD should be going to rc1.1 19:33:31 test RC1? or RC1.1? 19:33:35 i think you guys forget about Base sometimes :) 19:33:46 cmurf: if you're testing something now, test RC1.1, as it's what we're looking to ship 19:33:49 sorry if I misreported... ;) whats the base cloud ? 19:33:59 nirik: https://fedoraproject.org/wiki/Test_Results:Fedora_20_Final_RC1_Base 19:34:11 three of those tests are 'active' for ARM 19:34:15 sigh, Cloud 19:34:35 yeah i just want to make sure MacEFI can still boot from a USB stick and install from DVD. That is the case for Live using LITD. 19:34:37 they're the 'does it actually work' checks 19:34:39 huh. 19:34:55 yeah, initial setup doesn't make sense there does it? 19:35:01 yeah, that's why it's greyed 19:35:35 ah, I see. 19:35:49 if you can sign off on the others (ideally with a clear conscience...) it'd be great 19:36:22 let me copy across the iscsi and xen results we have for now... 19:36:33 if anyone can do either of those quick it'd be great 19:36:53 two of them I am sure are good... I didn't check 'systemctl --all --failed'. I can real quick if you like tho 19:37:10 if you don't have anything better to do :P 19:37:26 just finishing this infra meeting, then I can 19:38:14 cool, i'm still running the kde login test 19:39:46 * nirik would like to note again for the record the 'login as fedora user' is stupid. 19:39:58 lol 19:40:22 ? 19:40:36 * satellit_f20 back from KDE testing 19:40:48 yes it should say "login as fedora god" 19:41:11 https://www.youtube.com/watch?v=E4I4OCgVAv8 19:41:34 there are a lot of libreoffice updates noted in the diso file from TC5 to RC1... 19:41:58 cmurf: yes, that was the problem with rc1 19:42:04 yeah, then rc 1.1 took them out 19:42:05 ooo 19:42:12 cmurf: it got two copies of some LO packages because depsolving is a black box no-one understands 19:42:17 rc1.1 took out the dupes 19:42:24 got it 19:42:38 i'm looking at this going WTF that's a lot of FE's for libreoffice! 19:42:42 i don't remember these conversations 19:42:53 does anyone who doesn't suck at having good test environments want to test https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_installation_source ? 19:43:05 it's a bear to test, but it hasn't been done since tc2 19:43:28 cmurf: we wanted LO -9 for RC1 because it was needed to get the desktop live under size again 19:43:39 and LO is a lot of split packages, so there'd be a bunch of changed LOs from TC5->RC1 anyway 19:43:46 then the issue with multiples makes it worse 19:43:53 ick 19:44:08 huh kernel updated also 19:44:11 for RC1.1 we just pushed -9 stable so -6 wasn't available to the builder any more. dumb, works. 19:44:18 * nirik updates base cloud test. all pass 19:44:21 kernel was for the sssd auth thing 19:44:23 nirik: yay 19:45:51 we are all in a field. we're all carefully walking forward hoping to not hear a boom. 19:45:54 * satellit finally D/L RC1.1 x86_64 DVD 2 hrs eta here 19:46:11 cmurf: =) 19:49:14 kde login looks all good to me 19:49:44 satellit: delta iso man, swear by them 19:49:51 * satellit and it shuts down...: ) 19:49:56 fakaked 19:50:00 anything else what's really, really needed to be covered now or are we getting to the ok status? 19:50:16 * jreznik has to start working on presentation he has in the morning :) 19:50:46 eh, be nice if someone tested updates.img_via_installation source, needs you to have a local mirror you can abuse 19:50:51 which i don't 19:51:02 but i'm okay taking it from tc2 if we want 19:51:17 no reason anything we changed since then ought to have broken it, and it's a pretty minor function 19:51:37 pwhalen: how are the last couple of ARM desktop tests coming? 19:51:37 I's day use tc2 for this one 19:52:15 how many people have a local mirror? 19:52:16 adamw, install through gui worked np, just doing yum now 19:52:39 panorama bug in KDE is still present in RC1, but I think we knew that, right? 19:52:50 danofsatx: yeah, we -1ed it easily 19:52:57 k, just checking 19:53:19 danofsatx-dt: yep 19:54:10 pwhalen: you're meant to test the kde graphical update thingy :P oh well 19:54:18 it works on x86, really no reason it wouldn't on arm. 19:54:35 adamw: seems like he tested gui and now he's trying yum 19:54:37 adamw, yes, gui works, trying yum 19:54:40 ohhh, i see 19:54:44 then check the damn box :P 19:54:57 +10000 :) 19:54:59 prefer to wait until yum finishes :) 19:55:36 but ok, done 19:55:38 can tese tests be moved to RC1?https://fedoraproject.org/wiki/Test_Results:Fedora_20_Final_TC5_Desktop?rd=Test_Results:Current_Desktop_Test#Non_release-blocking_desktops:_x86_.2F_x86_64 19:56:13 satellit: probably safe to, yeah, except maybe LXDE 19:56:25 oh, no, i think the LXDE changes were in tc5 already 19:56:39 so...yeah, i think there should be no change to any of the non-blocking desktops between tc5 and rc1, unless i forgot something 19:56:56 not sure how to do it.... 19:57:56 there's no clever trick 19:58:01 (unless someone invented one while i wasn't looking) 19:58:16 copy paste? 19:58:25 just enter {{result|(whatever)|previous TC5 run(|bug number)}} for each test 19:58:36 no, mark it as 'previous TC5 run' like that 19:58:38 there's an example in the key 19:58:46 ok 19:59:37 so we can wait for pwhalen to do keyring or just cut to the chase, i guess 19:59:57 * adamw goes to put his desktop back together 20:00:06 cut to the chase 20:00:35 adamw, sorry I didnt realize you guys were waiting on that last one... 20:01:31 it's the last thing in the matrices, after we copied a few from the tcs 20:01:42 no reason on earth it wouldn't work 20:02:15 so let's move on 20:02:28 adamw, it isn't 5 words! 20:04:01 adamw put the qa jinx on it wouldn't/shouldn't words of failure 20:04:06 Viking-Ice: =) 20:04:35 so any objections moving on or do we really want to wait for the last second? 20:04:39 s/for/to 20:04:59 * roshi has no objection 20:05:00 nah, fine by me, i'd say coverage is acceptable 20:05:09 drama wait over... 20:05:11 i think pwhalen did the test for tc5 anyhow 20:05:25 i'm good, macs boot both DVD and Live desktop using either dd or litd still 20:05:45 and can install (whew) 20:05:46 #info test coverage is considered acceptable by QA 20:05:54 huh, no, he always leaves it out 20:06:00 pwhalen: what've you got against the keyring test? :P 20:06:06 just set up an email account and reboot 20:06:12 if it works without asking you for the password, it's good 20:06:12 #topic Go/No-Go decision 20:06:22 cmurf: yay, we didn't bust it 20:06:34 so we are there! 20:06:58 adamw, nirik: you guys? we don't have dgilmore for releng unfotunatelly 20:07:11 adamw: yes two in a row would be less than ideal 20:07:21 I'm good with go based on what I know currently. 20:07:28 be nice if we managed to re-test absolutely everything on RC1/RC1.1, but coverage between TCs and RCs is certainly acceptable; all accepted blockers are addressed in RC1.1/RC1; so QA is 'go' to ship per our rule for voting 20:07:44 it would be nice if releng can make the RC1 vs. RC1.1 stuff consistent for release, but i'd defer to their expertise there 20:08:03 yeah, will need to check with dgilmore on that, but hopefully there's no stopper there. 20:08:04 are docs go? 20:08:06 adamw, working :) 20:08:10 pwhalen: yay 20:08:18 Viking-Ice: docs? 20:08:35 common bugs ;) 20:08:53 #info coverage between TCs and RCs is certainly acceptable; all accepted blockers are addressed in RC1.1/RC1; so QA is 'go' to ship per our rule for voting 20:09:14 we usually do common bugs after go... well, by 'we' I mean adamw. ;) 20:09:23 * roshi will work on commonbugs 20:09:30 #info devel are 'go' on what's currently known 20:09:30 hurray new victim 20:09:41 #action roshi to work on CommonBugs 20:09:44 I mean writer 20:09:51 * nirik cheers on roshi 20:09:51 Lol 20:10:24 throw any nutty partition/booting related commonbugs workarounds write-up requests to me 20:10:30 * roshi wasn't expecting an #action. No backing out now... 20:10:31 for releng part - I'd let it for the ticket, in case there would be a problem on that side, dgilmore would let us know and we can revisit the Go decision 20:10:36 Ok 20:10:44 roshi: :D 20:11:06 jreznik: sounds good. I will talk with him when he's awake too... 20:11:11 so DVDs/netinst RC1.1 and the rest RC1, right? 20:11:15 nirik: thanks 20:11:31 yep 20:12:53 roshi: most of those bugs i'm already cc'd on, if not just cc me, and then in comments ask me write something up that's coherent and i'll report back in the bug with something semi-coherent 20:13:09 :-D 20:13:13 proposal #agreed Fedora QA and Fedora Development are both Go; Fedora Release Engineering to be notified (with possibility to revisit Go decision in case of unexpected issues from releng side) 20:13:16 Sweet 20:13:42 so which go's are we missing ? 20:14:16 "Release is unanimously declared GOLD by a representative from Development, Release Engineering, and Quality Assurance." 20:14:27 Viking-Ice: it's QA, devel and releng, dgilmore is now in a different TZ so sleeping but he helped us a lot during day working on RC1.1 20:15:04 is the proposal acceptable or do we want to wait for the last go? 20:15:16 yeah, i know nothing to indicate releng would be no-go 20:15:18 ack 20:15:21 acl 20:15:23 mean ack 20:15:27 ack 20:15:30 and i think releng is the party that starts Doing Stuff when we say Go, so it's okay to do it this way 20:15:32 * jreznik messed it up and forgot dgilmore at beta, so he wants to make sure to do everything he can do 20:15:51 if it turns out dgilmore wants us to be No-Go, he can say so when he wakes up and nothing breaks 20:15:53 ack 20:15:53 yeah, the releng/infra fun begins now. :) Or continues I guess 20:15:58 #agreed Fedora QA and Fedora Development are both Go; Fedora Release Engineering to be notified (with possibility to revisit Go decision in case of unexpected issues from releng side) 20:16:32 hoorayyy! thanks guys 20:16:56 holy crap it actually happened 20:17:00 thanks everyone for all the hard work. 20:17:05 indeed 20:17:09 #action jreznik to announce Go decision and to update the compose ticket 20:17:18 until next time... 20:17:20 no no go ? 20:17:22 boring ;) 20:17:33 #action nirik to talk to dgilmore about the rc1/rc1.1 trees 20:17:35 right on the first(ish) RC 20:17:48 cmurf: first.first 20:17:59 need to call my bookie, i've won big time betting in RC1.x 20:18:07 hehe 20:18:16 cmurf: for a certain value of 'right 20:18:29 i always put .x in the contracts 20:18:36 so, thanks again - anything else to add? 20:18:39 no 20:19:37 so I'll end the meeting in 3... 20:26:30 2... 20:27:07 * nirik tries to figure out what units jreznik is using. 20:27:46 jreznik uses "I forgot to countdown" unit :D 20:27:50 1... 20:28:11 better than forgetting to end the meeting, so let's do it now... 20:28:13 #endmeeting