16:02:28 #startmeeting f20beta-blocker-review-4 16:02:28 Meeting started Wed Oct 16 16:02:28 2013 UTC. The chair is kparal. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:28 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:34 #meetingname f20beta-blocker-review-4 16:02:34 The meeting name has been set to 'f20beta-blocker-review-4' 16:02:39 #topic Roll Call 16:02:43 who's there? 16:02:47 * pwhalen is here 16:02:48 * roshi is here 16:02:49 (knock knock) 16:03:05 * mkrizek is here 16:03:12 bananna! 16:03:48 #chair tflink adamw 16:03:48 Current chairs: adamw kparal tflink 16:04:27 kparal: i, er, already started the meeting and chaired you... 16:04:28 * jreznik is here 16:04:29 i'm here for kernel stuffs 16:04:35 oh no i didn;t 16:04:39 i'm really an idiot 16:04:50 * jreznik is now a bit confused 16:05:00 maybe too many meetings in a row today... 16:05:08 or too many beers, that happens :P 16:05:10 * satellit listening 16:05:25 * adamw started the meeting in the wrong channel 16:05:31 no, can't blame any beers 16:05:32 heheh 16:05:45 lol 16:05:58 ok, I count 8 people or so 16:06:02 let's start 16:06:02 kparal: you go ahead, i'll do secretarialization 16:06:03 satellit, your other nick... is it online now? 16:06:12 yes 16:06:19 #topic Introduction 16:06:19 Why are we here? 16:06:19 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 16:06:19 #info We'll be following the process outlined at: 16:06:19 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:06:21 for someone who knows russian it's lol-worthy 16:06:22 #info The bugs up for review today are available at: 16:06:23 #link http://qa.fedoraproject.org/blockerbugs/current 16:06:28 hmm 16:06:34 #topic Introduction 16:06:45 Why are we here? 16:06:45 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 16:06:45 #info We'll be following the process outlined at: 16:06:45 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:06:45 #info The bugs up for review today are available at: 16:06:46 #link http://qa.fedoraproject.org/blockerbugs/current 16:06:53 #info The criteria for release blocking bugs can be found at: 16:07:03 #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria 16:07:15 #info Up for review today, we have: 16:07:22 #info 4 Proposed Blockers 16:07:23 #info 8 Accepted Blockers 16:07:23 #info 5 Proposed Freeze Exceptions 16:07:23 #info 3 Accepted Freeze Exceptions 16:07:45 bear with me, I'm new to this, I'm gonna be a bit slower :) 16:07:51 ok, let's go with the proposed blockers 16:08:09 #topic (1017435) Anaconda uses LVM when Standard Partition is selected in text mode 16:08:10 #link https://bugzilla.redhat.com/show_bug.cgi?id=1017435 16:08:10 #info Proposed Blocker, anaconda, MODIFIED 16:09:08 I confirmed this on arm and x86, not sure if anyone else has run into it 16:09:15 +1, seems fairly straightforward as described 16:09:18 * adamw has not verified though 16:09:29 +1 blocker 16:09:30 +1 by the description 16:09:31 +1 16:09:32 +1 16:10:19 +1 16:10:43 proposed #agreed 1013586 - AcceptedBlocker - Violates the following F20 beta release criterion for text mode and standard partitions: "When using the guided partitioning flow, the installer must be able to: Complete an installation using any combination of disk configuration options it allows the user to select " 16:10:48 ack 16:10:50 ack 16:10:53 ack 16:10:54 ack 16:11:01 how do I know if the text is cropped or not? 16:11:08 ack 16:11:13 #agreed 1013586 - AcceptedBlocker - Violates the following F20 beta release criterion for text mode and standard partitions: "When using the guided partitioning flow, the installer must be able to: Complete an installation using any combination of disk configuration options it allows the user to select " 16:11:27 kparal: i just started getting a feel for it and hoped that someone would tell me if it was too long 16:11:34 #topic (1017977) FormatDestroyError: error wiping old signatures from /dev/vda2: 1 16:11:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=1017977 16:11:34 #info Proposed Blocker, anaconda, NEW 16:13:06 the exact cause of this seems a bit unclear 16:13:13 it's not really clear whether the reported adjusted the partitions while anaconda was running 16:13:19 *reporter 16:13:26 agreed, steps to reproduce would be better 16:13:27 that would explain the error 16:13:53 yeah, given the reporter's latest comments I'd at least want a clean reproducer of this 16:14:39 so, we can wait or reject it 16:15:19 they're kinda equivalent - either reject with 'but re-propose with a clean reproducer' or 'wait then reject next week' 16:15:22 eh, either works for me 16:15:50 -1 blocker until someone can reproduce, or clearer steps given. 16:15:51 since no one else saw the same error (at least we have no indication) and the reporter hasn't provided clear steps (and might even not reproduce it again since he deleted the VM), I think rejection is better 16:16:02 fair enough 16:16:05 yep, reject for now 16:16:21 so, do we +1 for reject or -1 for reject? 16:16:52 -1 blocker 16:16:53 roshi: er, make it clear in your statement :) 16:16:59 "-1 blocker" means reject 16:17:06 adamw: ok. -1 blocker 16:17:16 * roshi was being slightly facetious 16:17:44 proposed #agreed 1017977 - RejectedBlocker - This is rejected as a blocker until someone else can also reproduce the issue or the reporter can provide us with a clear steps that would help us reproduce the issue. 16:17:53 -1 and ask for clear reproducer if re-proposed 16:17:55 ack 16:18:01 ack 16:18:12 ack 16:18:15 ack 16:18:24 ack 16:18:30 #agreed 1017977 - RejectedBlocker - This is rejected as a blocker until someone else can also reproduce the issue or the reporter can provide us with a clear steps that would help us reproduce the issue. 16:18:42 #topic (1019541) unknown install shows up as entire disks instead of mount points of selected disks 16:18:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=1019541 16:18:42 #info Proposed Blocker, anaconda, NEW 16:19:19 kparal: is 1019405 going to be reviewed today? 16:19:32 not sure if this is a blocker anymore 16:19:41 leigh123linux: I don't see it on my list 16:19:44 the main issue for me turned out to be corrupted backup gpt tables 16:19:52 kparal: Thank you 16:20:11 leigh123linux: it's proposed as Final blocker, not Beta 16:20:34 I just wasn't sure if the other things in c#8 were severe enough to warrent blocker status 16:20:59 strange failure mode, though :) 16:21:11 -1 blocker, issue seems resolved and hw specific 16:21:30 tflink, have you tried a second time since? 16:22:08 yes, the install I mentioned in c#9 finished 16:22:21 right, but duplicate the success? 16:22:25 so what's wrong on having corrupt _backup_ gpt tables? 16:22:41 but I don't pretend to understand the stuff about bootloader selection and __init__ 16:22:49 * adamw is not totally sure about 3), that _could_ be a problem 16:22:54 kparal: I htink that blivet was choking on the corrupt backup table 16:23:15 * adamw trying to think how you could enter custom part without a valid bootloader target device but leave with one...it seems plausible, esp. in a UEFI config? 16:23:22 wow I looked that blocker list yesterday and we only had one ;( 16:24:02 * adamw pinged dlehman 16:24:06 what is the bootloader target device exactly? 16:24:25 it's where the bootloader binary goes. 16:24:37 so the area before first partition? 16:24:40 thanks dlehman 16:24:44 kparal: for a BIOS install, yeah. 16:24:46 kparal: with bios, yes 16:24:52 and uefi partition for uefi 16:24:52 with uefi, it's the EFI system partition 16:24:54 got it 16:24:55 but it's rather different for a UEFI install. I think, for a UEFI install, that would be the ESP. 16:25:05 dlehman: we're not sure how important issue 3) from your c#8 note is 16:25:16 dlehman: I was thinking it could be a major problem for UEFI custom part installs? or am I wrong? 16:25:23 the most important, I'd say 16:25:25 https://bugzilla.redhat.com/show_bug.cgi?id=1019541#c8 16:25:37 so if I don't have ESP and boot in UEFI mode, the custom part won't work for me? 16:25:45 i was thinking that might be it, but IMBW 16:25:55 it means the disk selection is lost every time someone enters the custom spoke without a valid bootloader stage1 device already present 16:26:12 so the scenario kparal mentions could be a problem, for instance? 16:26:44 ok, so on UEFI machine with 3 clean disks, I select only one, then enter custom part and see all 3 of them, right? intentionally by anaconda design 16:26:47 yes. it won't generally be problematic on BIOS because a disk w/ disklabel is a suitable stage1 there 16:26:51 right 16:26:55 so it's rare that there won't be one 16:27:06 kparal: i think 'disk selection getting lost' == 'installer blows up' 16:27:07 brand new install on a uefi machine 16:27:08 kparal: no -- if you only select one that's all you should see in custom 16:27:22 adamw: it wasn't crashing for me last night 16:27:28 huh 16:27:32 "treat the absence of a suitable stage1 bootloader device as a fatal error" 16:27:38 dlehman: what it exactly 'disk selection getting lost' means? 16:27:59 it means if you select a subset of your disks anaconda acts as though you selected them all 16:28:06 * jwb steps away for a sec 16:28:27 okay 16:28:31 so not fatal, but not behaving as intended 16:28:32 dlehman: in my example I just mentioned with 3 clean disks, there's no ESP and you said I'd see just a single disk (that I selected) 16:28:44 kparal: i think he means that is the *intended* behaviour 16:28:52 but this bug means it would actually show *all* of them 16:28:55 right? 16:29:04 kparal: are you asking about the consequences of this bug or when things are working correctly? 16:29:21 I'm not clear what behavior is intended and what is current 16:29:31 by design you should only see the disks you selected, period. UEFI doesn't matter. disk contents don't matter. 16:29:36 I'm pretty sure that's what the bug is adamw 16:29:41 ok, I get it now 16:29:47 due to this bug disk selection does _nothing_ 16:30:13 adamw: you have it right 16:30:16 ok, now let's discuss whether it is a blocker 16:30:18 why are the entire disks shown on the custom partitioning screen, though? 16:30:34 shouldn't it show nothing if there were no valid devices detected? 16:30:35 because parted rejected their disklabels and therefore no partitions were seen on them 16:30:45 OK 16:30:49 empty disk with no formatting is what they look like to us 16:30:55 so that's what you see 16:31:07 so the worst possible consequence is that you see all your disks in custom part. for a beta, that doesn't seem critical to me, and doesn't infringe any criteria directly that i see 16:31:11 sure, but shouldn't that show up as no existing volumes? 16:31:16 probably FE-worthy 16:31:20 instead of the various disks? 16:31:28 tflink: it knows the *disks* exist 16:31:35 tflink: but it thinks they have no valid *partition tables* 16:31:42 it could quite easily create some for you, though. so it doesn't hide the disks. 16:31:45 right, dlehman? 16:31:46 I understand that 16:31:53 that's not my question 16:31:54 right. unpartitioned disks can contain filesystem, lvm pv, &c 16:32:21 tflink: it doesn't seem related to the blocker discussion anyhow.... 16:32:22 normally we would create a new disklabel on them since they were selected, and _that_ would lead to an empty view in custom 16:32:32 can we now focus on whether the issue is significant enough to block the beta release? 16:32:42 ah, ic 16:32:45 my question is that in the situation where no valid partition table exists, why is custom partitioning showing me the disks which are not relevant to custom partitioning 16:32:49 ? 16:32:51 but the fallout from the bootloader error mishandling is that we throw out the scheduled actions to reinitialize the disks 16:32:52 fair enough 16:33:06 ok, I understand now 16:33:45 tflink: FWIW if you try to delete one of the disks it should disappear because we handle that by making a disklabel on it 16:33:47 dlehman: any consequences of the bug that you're aware of severe enough that it might merit blocker status? 16:34:00 hmm 16:34:05 (for beta) 16:34:21 dlehman: does that change the disk content or just queue an action to create the label? 16:34:27 the latter 16:34:47 ok, cool. good to know 16:34:49 adamw: it might be nice to see what it looks like with valid disklabels 16:35:05 peel away a few layers of doodoo 16:35:27 so, same scenario, but correct disk labels? how did that look, tflink? did you try it? 16:35:58 nope, I just fixed the disk labels and redid the install 16:36:07 those disks did have efi system partitions on them 16:36:37 so then you didn't hit the error and also custom looked normal? 16:36:56 yep 16:37:03 ah, so we haven't tried the 'clean empty disk' scenario yet 16:37:11 correct 16:37:15 given current understanding i'd be -1/+1, but maybe we should test a bit more 16:37:25 yeah, sounds like a plan to me 16:37:28 or, better yet, non-empty disks but without valid ESP 16:37:51 OK, so say a valid BIOS install of Fedora or something humdrum like that, booted in EFI mode? 16:37:58 like booting EFI with a disk that has a valid BIOS install? 16:38:03 GREAT MINDS 16:38:04 bah, too slow 16:38:20 I suspect you'll hit the error but will land in custom with things looking normal except that any uninitialized disks will appear as they did for you earlier and users will have to figure out that "delete" is how to initialize them 16:38:28 OK 16:38:42 do we want to do a conditional vote, or punt this? 16:39:03 I'd say just -1/+1 for now and re-propose if it ends up being a bigger problem than we think 16:39:09 go/no-go is 10-24 so ideally we'd want to be definitive asap 16:39:17 definitely be nice to have this fixed soon 16:39:32 as is, I can't see this blocking beta 16:39:35 do I understand correctly that there's no data loss if I don't manually adjust anything on those disks? 16:39:44 yeah, -1/+1 is still my instinct 16:39:50 yeah, there's no data loss as long as you don't start the install 16:40:05 the corruption on my disks was already there before I started the install 16:40:05 and after that? 16:40:30 it'll do what you tell it - if you start an install that deletes and re-creates partitions ... that would delete stuff 16:41:01 but if I don't touch those disks that I haven't selected (but they have appeared), no harm is done to them 16:41:04 so it is possible that a user could throw out their data because it appears that partitions have disappeared 16:41:45 tflink: I thought that happened only with invalid part tables 16:42:27 kparal: stuff not showing up correctly? I think that's the "no valid stage 1" symptom 16:42:46 no 16:42:46 right, that's what I though we were mostly voting on 16:43:23 aiui, the 'no valid stage1' symptom is that disk selection becomes irrelevant - all disks would be visible even if you had not selected some 16:43:43 but it also gets rid of some init, no? 16:43:43 the 'not showing up correctly' symptom is associated with the invalid partition labels AND the 'no valid stage1' bug... 16:43:47 oh 16:44:04 aha 16:44:09 so you'd only get that if you had invalid disk labels (partition tables). aiui, again. tricky issue to follow. :P 16:44:22 but i think verifying that is why dlehman wanted us to test a 'valid disk contents but no ESP' case. 16:44:31 should I recommend this to be proposed for Final? 16:44:44 probably 16:45:27 ok, how about this 16:45:56 tflink: you have the qa touch, clearly -- that was a real mess 16:46:08 let's do a conditional vote on the assumption that you only see the 'incorrect' display of disk contents if you have invalid disk labels 16:46:10 remind me to never let you near any of my systems 16:46:18 dlehman: the feared 'rust thumb' :P 16:46:24 :D 16:46:28 haha 16:46:30 on that conditional, i'd be -1/+1 16:46:53 if that turns out not to be true, we can re-vote either next week or in-bug 16:46:53 ^^ +1 16:47:22 proposed #agreed 1017977 - RejectedBlocker - This is rejected as a blocker because there doesn't seem to be data loss risk involved, unless in a very specific circumstances where users can reformat their disks in error. Please re-propose for Final. If disks turn out to be displayed incorrectly even with valid partition labels, we will reconsider this for Beta. 16:47:23 * jreznik is not sure he can vote on this one, trusts adamw 16:47:24 dlehman: that's what we're here for :-D I strive to have kparal's skills with getting stuff to break :) 16:47:41 god, writing these statements is hard 16:47:49 :-D 16:47:52 kparal: ain't it? :) that looks good to me 16:47:58 what about FE? 16:48:00 ack 16:48:02 oh yeah 16:48:08 ok, FE vote? 16:48:13 + FE 16:48:13 add AcceptedFE if it fits 16:48:14 +1 FE 16:48:20 +1 FE, rather 16:48:22 (that was the '+1' bit of my '-1/+1') 16:48:36 +1 fe 16:48:47 proposed #agreed 1017977 - RejectedBlocker AcceptedFreezeException - This is rejected as a blocker because there doesn't seem to be data loss risk involved, unless in a very specific circumstances where users can reformat their disks in error. Please re-propose for Final. If disks turn out to be displayed incorrectly even with valid partition labels, we will reconsider this for Beta. Accepted as a Beta FE. 16:48:59 is someone doing the secretarialization? 16:49:13 I think adamw said he was - if not I can 16:49:14 do we need that "Accepted as Beta FE" thing? 16:49:22 * adamw is already doing it 16:49:27 I can remove it 16:49:32 yeah, it's redundant 16:49:39 proposed #agreed 1017977 - RejectedBlocker AcceptedFreezeException - This is rejected as a blocker because there doesn't seem to be data loss risk involved, unless in a very specific circumstances where users can reformat their disks in error. Please re-propose for Final. If disks turn out to be displayed incorrectly even with valid partition labels, we will reconsider this for Beta. 16:49:40 ack with that change 16:49:58 ack 16:50:03 close enough. ack 16:50:03 it can be tweaked during secretarialization anyway 16:50:06 ack 16:50:08 ack 16:50:24 -ack 16:50:25 do we want to #action someone on the testing? 16:50:36 tflink: do I hear a volunteer? 16:51:01 I can do it, sure 16:51:01 let's pick.... pschindl, he's not here! :) 16:51:19 #action tflink to test 1019541 with valid partition tables 16:51:19 but I was actually thinking of voluteering roshi or one of you folks 16:51:26 since roshi has my efi test machine 16:51:38 we can reproduce this on our UEFI machine 16:51:48 ok, I'll ask our interns tomorrow 16:51:50 #undo 16:51:50 Removing item from minutes: 16:51:58 this is true I suppose :) 16:52:08 well, I've already tested with valid partition tables and it works 16:52:18 #action kparal to test 1019541 with valid partition tables 16:52:50 the test we want is a disk with a previoud BIOS install and no ESP booted with UEFI 16:52:55 previous 16:53:10 #undo 16:53:10 Removing item from minutes: 16:53:27 #action kparal to test or delegate 1019541 with valid partition tables and previous BIOS install and no ESP booted with UEFI 16:53:41 so much fun, this chairing 16:53:42 the question being if the lack of ESP causes any unexpected issues 16:53:58 what are we waiting for? ... oh, me! 16:54:08 #topic (1019500) device factories need to set a default name if empty name given for defined device 16:54:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=1019500 16:54:08 #info Proposed Blocker, python-blivet, ASSIGNED 16:55:24 seems pretty straight-forward to me 16:55:35 if I don't name the array, installation crashes? 16:55:46 the only question I have is how easy is this to hit? 16:56:06 dlehman: i tried to provide an accurate summary in https://bugzilla.redhat.com/show_bug.cgi?id=1019541#c10 , please advise if it contains any factual errors so far as you know :) thanks for the help 16:56:20 does somebody have a screenshot or something? I have no idea how you name an array 16:56:29 do you need to delete some pre-generated name or something? 16:56:44 yup this is a straight forward one 16:57:26 kparal: yeah, pretty much. there's a little "name" text entry that the user can clear out. 16:57:30 is it only in certain cases where a pre-existing array isn't named or named properly? 16:57:36 nvm 16:57:46 dlehman: is it filled out by default? 16:58:10 in that case I think I'd be fine with Final blocker 16:58:24 not something that many people would do 16:58:35 kparal: I can see this hitting the "rejecting invalid operation" criterion 16:58:55 in that case 16:59:32 oh, you're right 16:59:37 this isn't really an invalid operation, though 16:59:50 it's invalid to have no name, IIUIC 16:59:57 yeah...kinda a fine distinction :) 17:00:03 instead of 'rejecting' it the idea is to give it a default name 17:00:24 "Reject or disallow" 17:00:39 kparal: I'm not totally sure if it got cleared by us, but I think the user did it. 17:01:54 are we generally +1 blocker then? 17:02:12 yeah, +1 17:02:29 +1 17:02:52 sure +1 17:02:54 proposed #agreed 1019500 - AcceptedBlocker - Violates the following F20 beta release criterion for RAID installs with unnamed array: "When using the guided partitioning flow, the installer must be able to: Reject or disallow invalid disk and volume configurations without crashing." 17:03:07 acl 17:03:09 mean ack 17:03:27 ack 17:03:37 kparal: isn't that "when using the custom partitioning flow"? 17:03:57 ah 17:04:03 right, good catch 17:04:23 different criterion then? 17:04:33 I really dislike that we don't have anything similar for custom part 17:04:41 just s/guided/custom/ 17:05:03 the same sub-criterion is there but this situation isn't guided 17:05:03 but that's not how the criterion sounds :) 17:05:18 proposed #agreed 1019500 - AcceptedBlocker - Violates the following F20 beta release criterion for RAID installs with unnamed array: "When using the custom partitioning flow, the installer must be able to: Reject or disallow invalid disk and volume configurations without crashing." 17:05:23 ack 17:05:52 ack 17:05:58 ack 17:06:00 oh, it's actually there for custom part as well. kparal was blind 17:06:01 ack 17:06:07 ack 17:06:12 #agreed 1019500 - AcceptedBlocker - Violates the following F20 beta release criterion for RAID installs with unnamed array: "When using the custom partitioning flow, the installer must be able to: Reject or disallow invalid disk and volume configurations without crashing." 17:06:27 that's all of the proposed blockers! 17:06:44 let's continue with proposed FE 17:06:57 after a commercial break 17:07:02 TEST FEDORA! 17:07:09 break over 17:07:12 #topic (1016801) "Don't install the latest software updates" box is unchecked by default, can't be checked permanently 17:07:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=1016801 17:07:13 #info Proposed Freeze Exceptions, anaconda, ASSIGNED 17:07:23 * tflink is compelled by the not-so-subliminal messaging to test fedora 17:08:00 tflink: the subliminal message was "buy hotdogs with mustard" 17:08:45 can you buy hotdogs that already have the mustard? 17:08:57 that would be awesome 17:08:59 sure, from a hot dog stand :) 17:09:14 where is a hotdog stand? 17:09:18 :p 17:09:32 in a larger city or at a sporting event 17:09:47 mmmm mustard 17:09:59 we digress, though 17:10:11 +1 FE 17:10:38 +1 17:10:45 +1 FE 17:10:57 regular bug 17:10:59 +1 17:11:03 -1/-1 17:11:20 atleast I'm not going to risk slippage for that one 17:11:20 * satellit DVD in VirtualBox does not retain checkbox on re-entering spoke Beta TC4 just tested 17:12:20 * kparal tries to come up with a reasoning 17:12:50 its an offered option during install that isn't working 17:12:52 * satellit_RPi but it may work if you do not re-enter spoke? 17:13:02 while not a blocker, it can't be fixed with a post-release update 17:13:56 adamw, seems you have fiddled with that code how risky is it to pull in a fix? 17:14:07 proposed #agreed 1016801 - AcceptedFreezeException - Updates download checkbox might be an important feature for some people and doesn't present large risk. It can't be fixed post-release. A fix would be considered as a freeze exception. 17:14:25 ack 17:15:11 ack 17:15:14 ack 17:16:20 Viking-Ice: i didn't really fiddle with the code, just submitted a bug report, iirc 17:16:21 ack 17:16:38 #agreed 1016801 - AcceptedFreezeException - Updates download checkbox might be an important feature for some people and doesn't present large risk. It can't be fixed post-release. A fix would be considered as a freeze exception. 17:16:48 #topic (1016566) Installing a package silently fails if the GPG key for the yum repo is not installed 17:16:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=1016566 17:16:48 #info Proposed Freeze Exceptions, gnome-software, ASSIGNED 17:16:51 adamw: I suspect he's accusing you of having a double standard for how risky a fix might be 17:17:34 tflink, I see you are playing that game now 17:17:46 Viking-Ice: ? 17:18:05 if I read that wrong, I apologize 17:18:16 so where is our criterion "package installation must work"? 17:18:28 I don't see it in Final 17:18:42 tflink: he asked me a question, so I don't think that was the right reaing 17:18:55 kparal: it is not in there. and that's actually intentional. 17:19:02 adamw: how so? 17:19:03 though...it's kind of arguable. 17:19:10 kparal: simple: we chose not to require it to work. 17:19:20 we require *updates* to work. so theoretically, you update to the state where package installs work.\ 17:19:33 we're fine with release fedora _final_ with broken yum? 17:19:38 *releasing 17:19:39 in theory, yes. 17:19:49 technically, you can fix this with an update 17:19:50 I'm not fine with that. for Beta, ok, maybe 17:19:52 well, where 'broken' is 'package install fails but doesn't damage any data'. 17:20:05 this has not, to my knowledge, ever been 'tested in production', so to speak 17:20:20 i don't want to speak out of place, but sometimes documenting common sense doesn't really help anything. 17:20:21 not sure I like the idea of releasing without the ability to install software w/ default method, though 17:20:48 ok, so my question is, can we _update_ using gnome-software without the gpg key installed? 17:21:09 I suspect not if install doesn't work but we'd need to test that 17:21:28 that would be a blocker 17:21:51 jwb: trying to run a release process based on 'common sense' tends to work out remarkably badly, which is why we try to write it all down 17:22:02 either way, +1 FE for beta 17:22:10 there is a line somewhere, but it's rather more to the 'write it down' side than you might think 17:22:19 but we're not mindless zombies that can't do anything if it's not codified, either :) 17:22:21 yeah, anyway, it's a no-brainer +1 FE 17:22:22 adamw, i will defer to your experience there 17:22:28 is there some volunteer to test whether updating works? 17:22:48 kparal: it's already been done, see the matrix 17:23:06 well, i think i've tested update via the notification, which does an offline update currently 17:23:22 i don't know if the logic in GNOME is hooked up to do an online update if an offline one isn't required is hooked up yet... 17:23:37 so the update using gnome-software uses offline update? 17:23:47 and that works even without a key? 17:24:33 in my test it did 17:24:36 * satellit_RPi offline update of gnome3 f20 is very disruptive freezes laptop for 30 sec+ with no indication then 30 min upgrade on reboot did it last night 17:24:45 satellit: irrelevant. 17:24:55 ok It did work 17:25:04 kparal: the thing is, i think gnome's intended design is that it may do either online or offline, depending on the packages that need updating 17:25:08 but i don't know if that is hooked up yet 17:25:24 adamw: ok, I justed wanted to ask specifically about the missing gpg key 17:25:26 if it's theoretically possible that gnome-software might do an online update, i don't know if we've tested that yet 17:25:31 if you have tested that, that's great 17:26:06 i'm fairly sure we've checked offline updates with gpg key missing, though probably worth doing again (OOTB DVD install would test that, IIRC) 17:26:59 proposed #agreed 1016566 - AcceptedFreezeException - Installing software using gnome-software is an important feature and we will consider this fix even after freeze. If anyone finds out that update (not install) is not working with a missing gpg key, please re-propose for Beta. 17:27:01 anyhow...for now we should probably just vote FE and move on... 17:27:01 ack 17:27:09 er 17:27:10 patch 17:27:22 proposed #agreed 1016566 - AcceptedFreezeException - Installing software using gnome-software is an important feature and we will consider this fix even after freeze. If anyone finds out that update (not install) is not working with a missing gpg key, please propose this as a blocker bug. 17:27:29 (it's not a 're-proposal') 17:27:38 right 17:27:47 ack 17:27:48 ack to adamw's proposal 17:27:55 ack ^^ 17:28:18 #agreed 1016566 - AcceptedFreezeException - Installing software using gnome-software is an important feature and we will consider this fix even after freeze. If anyone finds out that update (not install) is not working with a missing gpg key, please propose this as a blocker bug. 17:28:27 #topic (1011714) btrfs scrub finds csum corruption after btrfs balance 17:28:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=1011714 17:28:27 #info Proposed Freeze Exceptions, kernel, POST 17:29:22 jwb: I think you were waiting for this one? 17:29:37 (thanks by the way for coming) 17:29:40 i was waiting to see if you guys had questions, yeah 17:29:58 i'm happy to add the patch. i updated the bug a bit ago based on the request from last week 17:30:30 as far as i know, you're only going to hit this if you run btrfs balance 17:31:42 this can get documented in Beta release notes and accepted as a FE 17:32:36 that's fine. i can get the patch added today 17:32:53 * adamw is +1 for taking this quite early, so we can do some further testing with btrfs installs and back it out if it turns out to be a bad idea 17:32:56 wouldn't want to take it later 17:32:57 jwb: do you think it's safe to include it without waiting until it's stable? 17:33:12 adamw: +1 to taking it early 17:33:16 kparal: it's not *intrinsically* a problem to run ahead of upstream's processes 17:33:33 yeah, it seems pretty safe 17:33:36 ok, I was thinking about some other risks related to btrfs 17:33:42 (i.e. it's not any *more* dangerous than doing this with any package which doesn't have strict upstream processes) 17:33:42 alright 17:33:45 josef is one of the main btrfs developers 17:34:02 i kind of implicitly trust him to not screw things up horribly 17:34:11 adamw: was that +1 to blocker or +1 FE? 17:34:23 fwiw, i don't think it should be blocker 17:34:24 it's proposed as an FE, right? 17:34:28 i'm voting as it's proposed. 17:34:34 ah, sorry 17:34:38 right 17:34:55 +1 FE 17:35:05 +1 FE 17:35:22 i think suse already added this as well 17:35:44 proposed #agreed 1011714 - AcceptedFreezeException - We would like to avoid data corruption on btrfs. A patch is ready and seems to be safe. We will consider it past freeze. 17:36:28 ack 17:36:29 ack 17:36:30 ack 17:36:45 ack 17:36:50 #agreed 1011714 - AcceptedFreezeException - We would like to avoid data corruption on btrfs. A patch is ready and seems to be safe. We will consider it past freeze. 17:37:01 btw are we past freeze already? /me doesn't know 17:37:08 yes, started yesterday 17:37:10 yeah, freeze was yesterday 17:37:14 the announcements never hit test-announce it seems 17:37:15 ok 17:37:19 kparal: yes, it was announced 17:37:36 #topic (1017683) Invalid UID in persistent keyring name 17:37:36 #link https://bugzilla.redhat.com/show_bug.cgi?id=1017683 17:37:36 #info Proposed Freeze Exceptions, kernel, MODIFIED 17:37:49 i think the announce is sent to devel-announce 17:37:56 kparal: https://lists.fedoraproject.org/pipermail/devel-announce/2013-October/001253.html 17:37:59 adamw: yep, it is 17:38:14 yeah, I don't read that every day, my fault 17:38:16 cc to test-announce might be nice 17:38:28 * kparal suggested that a few times in the past 17:38:31 this one is already built and filed. simo and sgallagh were all happy with it. it basically just builds something into the kernel that was a module before. 17:39:37 "Without this kernel patch, users relying on Kerberos for authentication and SSO will intermittently receive failures and errors (notably with misleading error messages)" - that's fairly bad 17:39:41 +1 for sure 17:39:54 arguably even a blocker 17:40:10 +1 FE 17:40:13 +1 FE 17:40:22 "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" for krb auth. but definitely FE. 17:40:29 to be clear, there is no patch. 17:40:30 +1 FE 17:40:51 +1 FE 17:41:35 it's a kernel config change, right? 17:41:36 proposed #agreed 1017683 - AcceptedFreezeException - This is a serious issue for Kerberos and SSO users. A fix would be considered past freeze. 17:41:55 patch 17:42:07 proposed #agreed 1017683 - AcceptedFreezeException - This is a serious issue for Kerberos users. A fix would be considered past freeze. 17:42:16 "Kerberos and SSO users" doesn't really...make sense. 17:42:21 ack 17:42:22 adamw, yes, a config change 17:42:26 jwb: roger. 17:42:30 ack 17:43:03 ack 17:43:15 most probably because I don't know what SSO means :) 17:43:17 basically, dhowells wrote code to allow big keys to be stored in the kernel. the module isn't loaded by default and isn't auto-loaded. libkrb5 (or whatever) was modified to use this to solve some issue i don't remember 17:43:34 and since the module doesn't auto-load, weird shit happens 17:43:41 kparal: single sign-on. you use kerberos to *do* single sign-on, it's not like kerberos and SSO are alternate, parallel systems. 17:43:58 making the module auto-load was the first approach, but that lead into requiring selinux-policy updates that weren't really viable 17:44:05 #agreed 1017683 - AcceptedFreezeException - This is a serious issue for Kerberos users. A fix would be considered past freeze. 17:44:05 so we just changed the config 17:44:11 jwb: seems sane. 17:44:25 and then i sent a patch later to make it impossible to build big_keys as a module, because it's useless in that form 17:44:30 but the patch isn't required 17:45:05 thanks for info 17:45:09 can I change the topic? 17:45:17 absolutely 17:45:23 #topic (1012141) [abrt] pulseaudio-4.0-4.gita89ca.fc20: core_free: Process /usr/bin/pulseaudio was killed by signal 6 (SIGABRT) 17:45:23 #link https://bugzilla.redhat.com/show_bug.cgi?id=1012141 17:45:23 #info Proposed Freeze Exceptions, pulseaudio, NEW 17:45:45 is this the one that abrt picks up all the time in vms? 17:46:17 yup 17:46:30 +1 FE 17:46:35 i'd be +1 FE for a relatively early and safe fix 17:46:41 might be a bit of a question if it was the final RC 17:46:42 +1 FE 17:46:50 adamw: agreed 17:47:02 can it be worse? it crashes... 17:47:07 +1 FE 17:47:12 yep, for soon and safe fix +1 FE 17:47:26 it's annoying and rather visable but not a show-stopper 17:47:34 not for beta, anways 17:48:23 proposed #agreed 1012141 - AcceptedFreezeException - This is a visible and annoying crash. An early and safe fix would be considered past freeze. 17:48:27 kparal: i think it reloads and works after crashing 17:48:34 so if the fix made it stop working...:) 17:48:38 (or eat babies, etc) 17:48:47 ack 17:48:50 * kparal is against eating babies 17:48:55 raw, at least 17:49:05 ack 17:49:46 * tflink is now concerned on a number of levels 17:50:13 tflink: what do you mean 17:50:28 kparal: that you'd know the difference between raw and not-raw babies 17:50:31 mostly 17:50:58 the latter ones are crunchy 17:51:15 ack? 17:51:18 o_O 17:51:19 ack 17:51:27 #agreed 1012141 - AcceptedFreezeException - This is a visible and annoying crash. An early and safe fix would be considered past freeze. 17:51:58 and that's all of Proposed Freeze Exceptions! 17:52:13 do you want to discuss Accepted Blockers? 17:53:00 yep pls, at least quick overview 17:53:13 * kparal has to admin he usually sleeps through that part, so he doesn't really know what happens in this section 17:53:13 yeah, we probably should 17:53:17 *admit 17:53:38 let's go then 17:53:39 #topic (1016959) ValueError: Cannot remove non-leaf device 'btrfs.14' 17:53:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=1016959 17:53:39 #info Accepted Blocker, anaconda, NEW 17:53:39 mostly just reviewing the bugs, listing out #infos with status and #actions if needed 17:53:59 kparal: we basically see if anything's needed to move forward on each bug, and if it's still actually correct for it to be open 17:54:40 I think this is waiting for developers action 17:55:12 #info this is waiting for developers action 17:55:15 yeah, it seems to be 17:55:28 dlehman: do you have any status update here? 17:57:16 adamw: not really. there are two fairly big btrfs bugs and that's one of them. the other is nested subvols, which we don't handle well at all. 17:57:53 but I am pretty covered up with other things that are more important than btrfs hand-holding. 17:58:23 would you expect that you'll have time to deal with them before go/no-go? or are we looking at a slip if we keep these as blockers? 17:58:43 when's go/no-go? 17:58:50 24th, I think 17:59:17 there's a pretty good chance I can at least take a close look before then 17:59:33 I expect this one to be quite a bit simpler than the other 17:59:40 yeah, the 24th 17:59:58 OK. 17:59:59 or the question is how important are brtfs bugs are at all... 18:00:18 well, we offer it fairly prominently and keep going on about how we want to make it default, so pretty important 18:00:29 but i don't want to start a bikeshed here, just keep tabs on status 18:01:06 moving on? 18:01:34 unless you want to make a not about the possibility of a fix before go/no-go 18:02:20 #info We don't know whether this is going to be fixed before go/no-go, dlehman is busy with other bugs 18:02:46 #topic (1010495) Apple Mac EFI: you have not created a bootloader stage1 target device 18:02:46 #link https://bugzilla.redhat.com/show_bug.cgi?id=1010495 18:02:46 #info Accepted Blocker, anaconda, ASSIGNED 18:03:17 i know bcl was wokring on this, last i heard was my most recent comment 18:04:20 #info the current patch is incomplete and we're waiting for bcl to refine the patch and submit it 18:04:42 anything to add? 18:05:11 * kparal takes that as a no 18:05:17 #topic (986575) installer fails to apply lower bound to resize requests in custom spoke 18:05:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=986575 18:05:17 #info Accepted Blocker, anaconda, ASSIGNED 18:05:46 * adamw will probably alert fesco that we're a bit worried about getting all blockers fixed on time in their meeting 18:06:14 might be a good time shortly 18:06:14 dlehman: i'm assuming this one's a fairly simple fix? 18:06:44 comment 12 suggests that 18:06:53 yes. I just need to clear off my "desk" a bit. 18:07:14 ok. so if you're going to 'miss' on anything it'll probably be one of the more complex ones. 18:07:42 #info this is a fairly simple fix, but it hasn't be implemented yet. waiting on developers 18:08:22 * kparal moves on 18:08:42 #topic (1013586) SizeNotPositiveError: spec= param must be >=0 18:08:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=1013586 18:08:42 #info Accepted Blocker, anaconda, NEW 18:09:37 dlehman: have you had time to look at the reproducer video and try that on your own? 18:10:11 I can also supply a disk image if you want, but it seemed a bit unnecessary to me, given how easy is to create one 18:10:25 haven't had time to try it 18:10:44 I'm expecting this one to be a real pain in the ass, FWIW 18:10:47 ok, feel free to ping me for more info if you need it 18:11:09 ie: the fix will touch lots of moving parts 18:11:11 dlehman: do you think it's a bug in blivet or some of the tools you use for detection? 18:11:50 kparal: I think it's a bug in blivet and possibly also anaconda. 18:12:27 #info this is still waiting for developer action. the fix is expected to be invasive and affect many parts of the installer 18:12:42 this one seemed pretty borderline to me when i read it over after the last meeting 18:12:53 unless there's something other than gnome-disks that creates partitions like this 18:12:59 adamw: gdisk 18:13:17 not by defualt though right? 18:13:20 it uses some padding doesn't it? 18:13:41 adamw: by default it creates the same layout as gnome-disks 18:13:47 adamw: i.e. it adds no padding 18:13:55 hm. 18:13:57 opposite from what gparted does 18:15:03 it starts to sound like we will be slipping 18:15:13 basically, we need to make sure minimum fs size and any resize target size is stored as an integer. 18:15:35 dlehman: do you think this makes sense as a beta blocker? any sense we made the wrong call? 18:15:38 (this is my guess) 18:15:43 hmm 18:16:07 so you get this crash just visiting the resize dialog with this pre-existing layout? 18:16:27 dlehman: by clicking on Shrink 18:17:20 I don't know what happens if you e.g. have more partitions and one of them is "bad" (not padded well enough). and you try to resize a different one 18:17:46 in this bug report it is the simplest case, a single partition covering the whole disk 18:18:42 I can't even say whether I can delete that partition, instead of shrinking. I'd have to try that 18:18:54 (if we're looking for weakening the blocker) 18:19:13 that's a good question. the bug is definitely occurring in the resize dialog 18:19:59 generally I think it's a blocker unless there's a way to say that shrink isn't in the criteria and it only happens when you try to shrink stuff. 18:20:55 i know we're fairly light on shrink, but we're tough on crashes 18:20:57 * adamw reads through 18:21:06 if we removed shrinking from the criteria, I think anaconda should be displaying big fat warning "This can eat your computer" during shrink operation 18:21:23 beta says "Remove existing storage volumes to free up space, at the user's direction" 18:21:30 that is explicitly worded *not* to include shrinking 18:21:43 adamw: we used "Complete an installation using any combination of disk configuration options it allows the user to select" when accepting it 18:22:05 that was intended to be about the stuff on the IO screen ,really, seems to be being interpreted more widely, though. 18:22:22 what we have for shrinking is this, in final: 18:22:23 " Storage volume resize 18:22:23 Any installer mechanism for resizing storage volumes must correctly attempt the requested operation. " 18:22:28 shrinking is not explicitly included anywhere, even in Final 18:22:34 yes it is ^^ 18:22:40 that was added quite recently 18:22:57 prior to that, the intent was that shrinking was explicitly not release blocking at all 18:23:07 the intent was to add it, in a limited way, for final 18:23:25 so if we start interpreting the 'any combination of disk configuration options' criterion to cover shrinking, we're kinda conflicting with ourselves 18:23:25 so, do you think we should move this to Final? 18:23:27 so can we move this one to final? 18:23:39 given the way we went about drafting the criteria so far, i'd say yeah 18:23:56 but if people really believe shrinking should be beta-blocking... 18:24:02 does the bug cause data loss? 18:24:07 adamw: no 18:24:18 the question is, at least in part, "will it crash just from clicking around in the dialog trying to decide what to do?" 18:24:26 I don't really say shrinking should be Beta, I just haven't noticed it's explicit in Final 18:24:47 dlehman: probably, for some people 18:25:14 but it's still beta... 18:25:17 I'd be OK with moving to Final 18:25:29 tflink: mkrizek: thoughts? 18:25:50 the thread for the criterion we added for final is https://lists.fedoraproject.org/pipermail/test/2013-July/116762.html , fwiw 18:25:51 crashing is bad but if there's no data loss, it's less of a huge deal for beta 18:26:05 I agree with tflink 18:26:23 yeah, my interpretation would be to move it to final 18:26:25 I'm ok with moving to final with beta fe 18:26:44 if there's a fix in time, we can discuss whether it's too big to be pulling in for beta 18:26:44 +1 to move to final 18:27:11 +1 if fix will be available and not as intrusive as dlehman thinks it will be, then beta FE 18:28:06 dlehman: thoughts on Beta FE? 18:28:30 does it even make sense to vote on that? will you have time for that? and interest to push it into Beta? 18:29:17 don't see it happening for beta 18:29:21 dlehman: let's do it as tflink says - if the patch is ready, please propose as Beta FE 18:29:35 sounds right to me 18:29:37 proposed #agreed 1013586 - AcceptedBlocker - We move this blocker from Beta to Final, because we have an explicit shrinking criterion there, as it was originally intended: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation." 18:30:04 do you want to add the bit about proposing as beta FE if a fix materializes 18:30:07 ? 18:30:25 ack either way 18:30:26 proposed #agreed 1013586 - AcceptedBlocker - We move this blocker from Beta to Final, because we have an explicit shrinking criterion there, as it was originally intended: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation.". If the fix is ready in time, please propose as Beta FE. 18:30:39 ack 18:30:44 should I avoid using "FE" abbreviation? 18:30:44 ack 18:30:59 ack 18:31:06 #agreed 1013586 - AcceptedBlocker - We move this blocker from Beta to Final, because we have an explicit shrinking criterion there, as it was originally intended: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation.". If the fix is ready in time, please propose as Beta FE. 18:31:19 #topic (1000891) DVD is oversized (larger than 4.7 GB) 18:31:19 #link https://bugzilla.redhat.com/show_bug.cgi?id=1000891 18:31:19 #info Accepted Blocker, distribution, MODIFIED 18:32:11 so, pungi bug? 18:32:43 sounds like 18:33:06 kparal: i try to avoid using the abbreviation where I can, but it's not forbidden :) 18:33:22 #info this seems to be a pungi bug, waiting for dgilmore 18:33:51 caused by langpacks patch by dmach and he told me dgilmore applied it in a bad way but that's what I heard... 18:34:35 anything to add, anyone? 18:35:12 #topic (1015234) F20 Beta TC1 ARM disk images unable to find root filesystem 18:35:12 #link https://bugzilla.redhat.com/show_bug.cgi?id=1015234 18:35:12 #info Accepted Blocker, dracut, ASSIGNED 18:35:46 I suspect this has been fixed? 18:35:49 lot of activity since last time 18:35:56 i don't think it's exactly fixed 18:35:59 it was worked around for TC2 18:36:12 a patch was posted that was supposed to actually fix it, but IIRC someone said it was insufficient 18:36:19 ah 18:36:34 we should probably ask for some clarity on exactly what the intended 'long term fix' is and whether it's what we have at present 18:38:05 action for anyone? 18:38:21 i'll do it (aprt of secretarialization) 18:38:59 #info discussion is still ongoing as how to fix this properly. it's not clear whether this is fixed with the latest compose. it would be a good idea to ask the reporter to retest 18:39:25 #action adamw to ask Harald and Dennis about bug 1015234 18:39:47 * kparal about to move on 18:39:51 go for it 18:39:54 #topic (1013767) rootfs on thinp not found, startup failure 18:39:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=1013767 18:39:55 #info Accepted Blocker, dracut, NEW 18:41:18 it seems the developers are working on this 18:41:30 yeah 18:41:33 not much to be done 18:41:38 there is a proposed patch, as well 18:41:55 a first half 18:42:08 #info the developers are working on this, nothing to do from QA perspective 18:42:14 yep, I tried to ping them and move things forward 18:42:26 * kparal about to move on 18:42:42 #topic (1013800) devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin pool 18:42:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=1013800 18:42:42 #info Accepted Blocker, python-blivet, ASSIGNED 18:43:13 more thinp fun 18:43:24 do I imagine that, or cmurphy loves complicated disk setups? 18:43:43 dlehman: did you get anywhere on this? 18:43:58 kparal: it sure seems to be his specialty 18:44:01 good thing SOMEONE does it :P 18:44:14 right 18:44:36 adamw: I have a patch for it. it's been reviewed and all. 18:44:57 #info patch is ready for this one. dlehman needs to submit it 18:44:58 coolbeans 18:45:08 so bug should be in POST i guess? 18:45:31 yeah, I'm probably going to push it today 18:45:42 ok, updated 18:45:46 this was the last one of Accepted Blockers 18:45:52 if I can untangle this mess of cloned bugs, flags, and blocker bugs 18:45:54 nice 18:45:56 want to go for Accepted Freeze Exceptions? 18:46:01 we have 15 minutes 18:46:01 dlehman: fun stuff :| 18:46:08 * adamw wants to go for dinner 18:46:13 acceptedfe discussion isn't really necessary 18:46:19 if they get fixed, they get fixed 18:46:33 that means.... 18:46:34 unless there's one with a fix we want to debate the inclusion of in TC5, I guess. but i don't think so. 18:46:38 #topic Open Discussion 18:46:45 anything else? 18:47:00 nothing from me 18:47:01 yeah, the only modified ones are the two kernel ones we already discussed 18:47:12 newp, except that i will try and kick in to the fesco meeting that we're slightly worried by teh blocker load 18:47:37 thanks 18:47:39 holy ass-covering, batman 18:48:16 btw this chairing stuff is awful, one can't sleep properly throughout the meeting 18:48:37 thanks for coming! 18:48:41 #endmeeting