16:02:22 #startmeeting f19final-blocker-review-1 16:02:22 Meeting started Wed May 29 16:02:22 2013 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:22 #meetingname f19final-blocker-review-1 16:02:22 #topic Roll Call 16:02:22 The meeting name has been set to 'f19final-blocker-review-1' 16:02:36 hi all! 16:02:40 kparal: because it hasn't quite started yet :-P 16:02:41 * kparal here 16:03:41 ignatenkobrain, kparal: welcome to the party! 16:04:32 another partier! 16:05:02 :) 16:05:14 where adamw? 16:06:11 good question, probably not snowboarding and apparently not here 16:06:39 i'm here 16:06:40 pipe down 16:06:56 well, I was right on one count :) 16:07:01 adamw: good. welcome 16:07:21 * nirik is lurking, but doing other things too 16:07:51 tflink: joke's on you, I had a small private mountain installed 16:08:40 adamw: with snow? 16:08:51 sure 16:09:00 anyhow, I suppose it's about time to get started 16:09:08 any volunteers for secretarialization? 16:09:16 #chair adamw kparal 16:09:16 Current chairs: adamw kparal tflink 16:09:59 sure 16:10:11 adamw: thanks, I was about to volunteer kparal :) 16:10:24 #topic Introduction 16:10:32 Why are we here? 16:10:32 #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:10:39 * kparal loves to be volunteered. maybe next time 16:10:42 #undo 16:10:42 Removing item from minutes: 16:10:58 #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 freeze exception bugs. 16:11:05 #info We'll be following the process outlined at: 16:11:05 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:11:10 #info The bugs up for review today are available at: 16:11:10 #link http://qa.fedoraproject.org/blockerbugs/current 16:11:22 #info The criteria for release blocking bugs can be found at: 16:11:22 #link https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria 16:11:25 #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria 16:11:28 #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria 16:11:31 #info Up for review today, we have: 16:11:32 #info 17 Proposed Blockers 16:11:32 #info 0 Accepted Blockers 16:11:32 #info 8 Proposed Freeze Exceptions 16:11:34 * satellit_e joins late to listen 16:11:34 #info 0 Accepted Freeze Exceptions 16:12:08 and apparently nobody (including me) reads the boilerplate in detail - somehow I'm not surprised 16:12:21 that nth reference has been in there since the first alpha review meeting 16:13:00 anyhow, I'll start with the proposed blockers shortly unless there are objections 16:13:56 #topic (958906) anaconda no longer writing out /etc/sysconfig/kernel 16:13:59 #link https://bugzilla.redhat.com/show_bug.cgi?id=958906 16:14:02 #info Proposed Blocker, anaconda, MODIFIED 16:14:48 what the heck is /etc/sysconfig/kernel for? 16:14:49 what is the file for? 16:15:00 ahhh, that file 16:15:20 I think it depends if the system boots 16:15:31 if it does, no big harm done 16:15:34 it configures package manager behaviour wrt kernel 16:15:55 i can't see that that being missing is a huge deal, you could presumably create it if you wanted to configure those settings 16:16:17 is it just kickstart or all installs? 16:16:17 "System boots fine, but new kernels are not installed as the default, so system continues to boot the original kernel unless /etc/grub2.cfg is edited by hand." 16:16:27 ah 16:16:36 hum, i wonder if that's truly due to this bug or if he hit the rawhide kernel bug? 16:16:46 which one? 16:17:13 eh, i forget the URL, but there's been a bug in the last few days where fc20 kernels weren't being added to the bootloader 16:17:35 anyhow, fix for this is already committed to anaconda so it doesn't make sense to spend too much time on it 16:17:44 i guess -1/+1` 16:18:11 block now and verify 16:18:19 * adamw testing this in a vm 16:18:35 I can't believe that nobody else has noticed this since alpha 16:18:42 I'd skip blocker vote, but put +1 FE 16:18:47 my suspicion is it's a mis-diagnosis 16:18:52 +1 16:18:57 he hit the fc20 kernel bug, went looking for a cause, and found this 16:19:01 but i can tell ya in just a seconed 16:19:28 adamw: even though he was installing w/ fc19 media? 16:19:49 the problem he observed was post-install 16:20:01 yeah, i can't reproduce the alleged symptom 16:20:16 i have a VM with no /etc/sysconfig/kernel and just did 'yum update kernel', the newly installed kernel is in grub2 as default 16:20:21 do we really need /etc/sysconfig/kernel ? 16:20:27 -1/-1 16:20:41 * adamw tries to find the kernel install bug 16:21:44 I think it's https://bugzilla.redhat.com/show_bug.cgi?id=965897 16:23:10 I'm not sure if it is intended to be gone, but I think there's nothing wrong on having +1 FE if they decide to put it back 16:23:15 which they seem to decided to 16:23:38 * nirik looks back in 16:23:45 it sounds like we're pretty clearly -1 blocker and mostly +1 FE 16:23:53 right, i just said +1 to retroactively rubber-stamp the addition to 19.31 16:24:13 * nirik nods 16:24:32 we're playing that game?, I'm almost more strongly -1 then but not going to fight it 16:24:55 oh, hum, now i look at it, i think 19.31 is post-19, 19.30.1 is for 19 final. eh i dunno. 16:25:33 It's unclear to me if they are installing nodebug/rawhide kernels or not. 16:25:54 nirik: it's just an inference i'm drawing from the fact that that bug showed up in the same timeframe, and I can't reproduce this bug with an fc19 kernel 16:26:02 yeah. 16:26:07 i have a VM with no /etc/sysconfig/kernel, I did 'yum update kernel', the new kernel installed fine and was in grub2 16:26:10 as teh default 16:26:12 note that /etc/sysconfig/kernel gives the user a bit more control. 16:26:19 but I guess they could just make it if it doesn't exist. 16:26:22 right 16:26:28 proposed #agreed 958906 - RejectedBlocker, AcceptedFreezeException - This isn't causing the symptoms stated in the bug and thus, does not qualify as a blocker for f19 final. However, it would be good to create the /etc/sysconfig/kernel file and a tested fix would be considered past freeze 16:26:35 btw, I'm not sure if it is a good idea to join our FE process with anaconda Beta-to-Final include-or-not decision system 16:26:36 ack 16:26:41 ack 16:26:49 ack 16:26:53 kparal: _1 16:26:56 +1 16:27:00 if we don't end up fixing it, we should document it. 16:27:05 #agreed 958906 - RejectedBlocker, AcceptedFreezeException - This isn't causing the symptoms stated in the bug and thus, does not qualify as a blocker for f19 final. However, it would be good to create the /etc/sysconfig/kernel file and a tested fix would be considered past freeze 16:27:31 sorry guys a bit busy with flock planning - tickets 16:27:33 #topic (872423) Add Interlingua to the list of available languages 16:27:35 #link https://bugzilla.redhat.com/show_bug.cgi?id=872423 16:27:38 #info Proposed Blocker, anaconda, MODIFIED 16:28:40 per the criteria, this is +1 16:28:56 * kparal searching what Interlingua is 16:29:04 kparal: new-age esperato 16:29:09 I see 16:29:19 +1 16:29:20 also used for cross-translation (lang1 to interlingua to lang2) 16:29:22 so somebody uses that, it seems 16:29:40 why can't this just be pulled in? 16:29:43 oh well 16:30:39 in this case I wouldn't block on it but just give FE, but criteria says so, so... 16:30:46 proposed #agreed 872423 - AcceptedBlocker - Violates the following F19 final release criterion: "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use" 16:31:14 kparal: agreed, I don't understand why interlingua translations are a blocker but oh well 16:31:32 because it's goddamn hard to write translation criteria without offending someone 16:31:34 I have to say this fails the last-bug-or-slip test 16:31:34 :P 16:31:40 for me 16:31:44 i agree, but let's not get too hung up on it for now 16:31:48 ack 16:31:50 ack 16:31:52 ack 16:32:02 #agreed 872423 - AcceptedBlocker - Violates the following F19 final release criterion: "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use" 16:32:16 #topic (966761) storage configuration failed: Not enough free space on disks for automatic partitioning 16:32:18 #link https://bugzilla.redhat.com/show_bug.cgi?id=966761 16:32:21 #info Proposed Blocker, anaconda, NEW 16:33:01 is this all multipath disks, or just ppc? 16:34:40 it sounds like all multipath disks 16:34:58 it would be nice if he tried it with a primary arch 16:35:11 where are you getting multipath from? 16:35:26 https://bugzilla.redhat.com/show_bug.cgi?id=955664#c25 16:35:36 crap 16:35:39 you would appear to be in the wrong bug 16:35:45 yeah, I just realized that 16:36:31 this appears to be related to a single-disk simple layout kickstart on a (V?)M with three scsi disks? 16:36:39 but it seems like we're thin on info 16:37:17 did we ever get any kickstart-only criteria? 16:37:49 no 16:38:02 kparal: i thought you were doing it :) 16:38:14 as things stand they're still case-by-case. 16:38:16 I vaguely remember it 16:38:30 definitely not finished though 16:38:50 and long forgotten 16:40:01 welp, i'd say punt on this one 16:40:05 there's a needinfo in already 16:40:25 yeah, works for me 16:40:39 ack 16:41:09 https://bugzilla.redhat.com/show_bug.cgi?id=967780 16:41:10 proposed #agreed - 966761 - it isn't 100% clear what is causing the problem here and the bug may have gone away. will revisit when more information is available 16:41:11 we can review later it? 16:41:13 I just added it. 16:41:54 ack 16:42:14 ignatenkobrain: mention it at the end of the blocker section 16:42:25 ack 16:42:37 kparal: ok. 16:42:40 ack 16:42:46 #agreed - 966761 - it isn't 100% clear what is causing the problem here and the bug may have gone away. will revisit when more information is available 16:43:08 #topic (955664) No multipath disks selected 16:43:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=955664 16:43:08 #info Proposed Blocker, anaconda, MODIFIED 16:44:40 it sounds like this is not ppc-specific 16:44:42 * satellit_e afk 16:44:51 only ppc ? 16:44:59 it doesn't sound that way 16:46:06 * tflink wonders what percentage of these blockers come from hamzy 16:46:33 it seems to be about 60% ui issues 16:46:40 the check mark problem again 16:46:56 but then there's also a real bug where multipath disks disappear after you ping-pong selection a bit 16:47:05 i'm at least +1 fe on that bug 16:47:45 same here, shouldn't be the bug split to two issues? do we track that ui one somewhere right now? 16:48:05 i have a bug in that's on it (kinda) 16:48:09 https://bugzilla.redhat.com/show_bug.cgi?id=967682 16:49:28 wow, this bug is a mess 16:49:38 if only ppc arch: -1 blocker and +1 fe 16:49:53 not just ppc 16:50:17 they just happen to be about the only people testing advanced storage 16:50:35 it is, but as adamw pointed out - there are two issues, ui one and that multidisk (but again connected to misunderstanding ui) - so for me it's more FE now 16:53:30 yeah, I don't think this is a blocker - it doesn't cause problems with multipath storage install 16:53:40 a bit of a pain if you had to reboot, though 16:54:21 let's go FE 16:55:02 proposed #agreed 955664 - RejectedBlocker AcceptedFreezeException - While the part about disks not showing up in the multipath tab is annoyance, it doesn't prevent install to multipath storage and is thus, not a release blocking bug for f19. A tested fix would be considered after freeze. 16:55:29 ack 16:56:03 ack 16:56:12 ack 16:56:25 #agreed 955664 - RejectedBlocker AcceptedFreezeException - While the part about disks not showing up in the multipath tab is annoyance, it doesn't prevent install to multipath storage and is thus, not a release blocking bug for f19. A tested fix would be considered after freeze. 16:56:44 #topic (967531) Kickstart installation can't use default repositories 16:56:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=967531 16:56:50 #info Proposed Blocker, anaconda, NEW 16:58:05 basically, "url" command was not required before, now it is. that means it kind of prevents a kickstarted installation that mirrors the default one as closely as possible 16:58:29 because even though you can enable the default repos using "repo", you still don't have the same package set available 16:58:55 funnily enough, anaconda generated kickstarts don't have the required arguments in them 16:59:48 however, it is not as clear cut blocker as I thought it would be when proposing it 16:59:56 kparal: what's missing from the package set? 17:00:25 seems to be a philosophical debate to some extent, but i have to say i'm on kparal's side 17:00:25 tflink: well, unless you carefully examine the repo you provide with "url", some packages might interfere with the default mirrors 17:00:39 seems to me the aim ought to be to preserve pre-f19 behaviour unless we are explicitly changing it 17:00:40 (be newer, or cause conflicts) 17:01:29 kparal: but if the default repos are disabled, how could they conflict? 17:01:57 definitely +1 fe 17:02:03 tflink: I'm talking about the state when they are enabled. because I wanted to mirror the default installation workflow 17:02:30 this sounds like it'd be hard to please everyone, but if that's the case i'd prefer to stick closer to pre-f19 behaviour than change it up for no clear net benefit 17:02:32 but I've found out that "repo" command itself is enough anymore 17:03:19 also, it might surprise some admins that their kickstart don't work anymore 17:03:31 but as I say, maybe it's more of a FE request right now 17:04:05 it's workaroundable by adding an empty repository and pointing to it with "url", or something 17:04:06 yeah, +1 fe 17:04:20 for now 17:04:24 +1 fe 17:04:42 we can wait for bcl's reply 17:05:30 +1 fe 17:06:02 proposed #agreed 967531 - AcceptedFreezeException - While this is inconvenient for some kickstart users, it isn't catastrophic. A tested fix would be considered after freeze. 17:06:09 ack 17:06:13 ack 17:06:18 ack 17:06:30 #agreed 967531 - AcceptedFreezeException - While this is inconvenient for some kickstart users, it isn't catastrophic. A tested fix would be considered after freeze. 17:06:34 #topic (965865) ValueError: ('invalid size specification', '-880.000000 MB') 17:06:37 #link https://bugzilla.redhat.com/show_bug.cgi?id=965865 17:06:39 #info Proposed Blocker, anaconda, NEW 17:07:52 can we have a rule that the proposed blocker must be reproduced with a primary arch? :-) 17:08:20 that would help 17:08:22 my issue with this bug is more that we have no idea what the partition layout is 17:08:38 kparal: feel free to request multipath hardware for testing :) 17:08:54 * kparal watching video 17:09:07 kparal: you have more patience than I do 17:09:18 yeah, i'm not +1 till we know something affects primary arch 17:09:34 that's kind of counter-productive, no? 17:10:08 or at least a bit dick-ish for some of these which have about 0% chance of being tried, much less repro'd on PA 17:10:12 I think the problem might be with the existing disk contents. I asked Vojtech today to try to reproduce that, but of course he started with a clean disks 17:10:47 is it local raid or remote storage? 17:11:05 I understood a local raid 17:11:20 when he 17:11:26 kparal: yeah i saw that too 17:11:37 kparal: when he's deleting partitions there's a note about '1 of 3 member partitions' being missing 17:11:48 really? watching again 17:12:02 tflink: i'd count 'the anaconda devs say so' as 'we know it affects a PA' 17:12:11 but so far they haven't and an attempt to reproduce on a PA failed 17:12:38 it's remote 17:12:56 at least I think it is 17:13:39 let's punt and ask mhamzy to 1) try to reproduce with clean disks 2) try to reproduce on a primary arch. then we should better know the scope 17:13:50 AFAIK, VDASD is a fibre channel attached remote storage array 17:13:51 the bug seems limited already 17:14:18 kparal: $50 says hamzy doesn't have access to equivalent PA hardware 17:15:12 if the disks are remote why can't he just plug a laptop in instead? 17:15:13 hmm. it just doesn't manifest in a VM 17:15:39 it's direct attach fibre channel storage 17:16:35 adamw: I've never seen a laptop-compatible FC HBA 17:16:39 what's our policy to secondary archs anyway? do they get blockers or just FEs? 17:17:12 not sure we ever figured that out 17:17:26 the bigger question here is what do we do about more exotic storage configs 17:18:10 kparal: by definition they only get FEs 17:18:30 i'm 'punt' on this one 17:18:33 are we willing to block when installation problems manifest for enterprise-ish storage configs? 17:19:12 AFAIK, we don't have the hardware to even consider much testing of that 17:19:21 day before the go/no-go, last blocker? I'd say no 17:20:51 sounds like punt, then? 17:22:04 I can ask Vojtech tomorrow to try to mirror more closely the layout that he has on those disks, but I'm not sure how much that will help 17:22:22 kparal: if it's a remote storage issue, I don't think that's going to work well 17:22:40 depends whether the problem is in existing layout or in the access protocol 17:23:11 we don't have all day guys :) 17:23:17 with a size of -800 MB, my money is on a remote storage hiccup 17:23:41 what exactly are we punting for, anyways? 17:23:47 waiting for, rather 17:24:21 clarification or retest with clean disks? 17:24:38 yes, probably 17:25:44 clarification of exactly what it is that triggers the bug 17:25:48 we really don't know yet, from all I see 17:26:33 prposed #agreed 965865 - There is not enough information in the bug to be clear on what is causing the issue, will revisit when there is more available information 17:26:44 ack 17:26:48 ack 17:27:04 ack 17:27:11 #agreed 965865 - There is not enough information in the bug to be clear on what is causing the issue, will revisit when there is more available information 17:27:15 #topic (964586) Anaconda does not isntall ntfs tools to allow OS-Prober to find windows partition and therefore creates no grub.cfg entry 17:27:18 #link https://bugzilla.redhat.com/show_bug.cgi?id=964586 17:27:21 #info Proposed Blocker, anaconda, NEW 17:27:38 +1 17:28:39 yeah, +1 17:28:42 so, this is a packaging issue essentially 17:28:56 either comps or a package, yes 17:29:00 "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working " 17:29:05 however, any other than minimal installation should not be affected 17:29:13 not so sure how crazy I am about adding ntfs to @base, though 17:29:16 still violates the criterion 17:29:19 or even anaconda should decide what to install to ensure existing OSes are detected correctly 17:29:33 right, we don't need to argue too much about the cure, we're only supposed to evaluate the problem 17:29:50 I support adamw 17:30:16 +1 blocker then 17:30:19 I think this is a bad decision, but it does violate criteria 17:30:32 -1 in principle, +1 per criteria 17:31:03 no, scratch that 17:31:04 -1 17:31:25 it's true that people that do minimal installation might be able to handle this problem 17:31:26 I don't see why a minimal install should have ntfs installed on it 17:31:48 or why every fedora install should have ntfs support 17:32:11 * jreznik agrees with tflink 17:32:18 should we change the criterion to require only desktop installations to probe for ntfs? 17:32:56 it would make sense 17:33:12 did anyone check this actually works for a desktop install? 17:33:32 probably depends on whether ntfs is installed 17:33:32 there were some results in the matrix 17:33:37 I suspect it is 17:33:44 tflink: that's not what +1 would mean. +1 would mean that installs alongside windows installations would be required to get ntfs. 17:33:58 adamw: I fail to see the difference 17:33:59 it would not mean "every fedora install should have ntfs support". 17:34:12 in any level I support kparal, but I think +1 17:34:16 I see the difference. the installer environment would have to detect it 17:34:27 not the installed system itself 17:34:36 kparal: well, there are various possible ways to implement it 17:34:36 and if there are windows, then make sure ntfs is installed 17:34:49 i'm just saying what a "+1 blocker" decision on this bug would require at a minimum 17:34:54 so instead of being reasonable about the criteria, we're going to force either bad installation policy or attempt to make workarounds in anaconda that they've tried hard to remove? 17:35:06 i don't see where this would be a 'workaround' for anything. 17:35:22 it's the installer's job to configure boot alongside existing OSes. 17:35:28 AFAIK, there is no support in anaconda to do a "if X, install this one extra package" 17:35:39 it's taking advantage of other tools to do that, sure, but it's still the installer's job to provide an appropriate environmenty. 17:35:45 i'm pretty sure there is. 17:36:27 jreznik: do you have a vote on this? 17:37:25 do we want to discuss more this criterion? I really would like to avoid enforcing something just to have it by criterion, on the other hand it's really anaconda responsibility to support this feature 17:37:44 I basically agree with adamw but I'm not really sure if I would insist on this behavior for the minimal installation 17:37:51 well, the criterion seems pretty self-explanatory to me. we want dual boot to be configured if you install alongside windows. 17:38:07 i mean, if it isn't, you have basically lost your pre-existing OS until you figure out how to make it come back, which probably isn't trivial. 17:38:39 linux distros have historically tried quite hard to make this work, and people are historically quite annoyed when it doesn't. 17:40:38 well it's definitely a good idea to decide on this behavior in advance, not tightly before release 17:40:49 in that respect it should work at least the same as in previous releases 17:41:04 did it work in 17 or 18? 17:41:08 good question 17:41:10 it sounds like the deps of os-prober were changed but i don't know when 17:41:11 I can try tomorrow 17:41:15 yeah, it'd be worth checking that 17:41:21 but just with Win8 17:41:23 good question 17:41:25 but anyhow, i'm still +1 on this, no-one has convinced me :) 17:41:54 if somebody wants to drop windows support for minimal install, it should be started as a regular discussion on our channels 17:42:02 I don't think we should decide it here 17:42:03 and I'm not comfortable with +1 and no proposed fix 17:42:12 however, I am outvoted 17:43:08 +1 too. if it not work in f1[78] I think in next review will change to -1 17:43:15 first we should check whether it is a regression. if it is not, I wouldn't block on it, but started the discussion. if it is, I'd block on it and started a discussion :) 17:43:36 proposed #agreed 964586 - AcceptedBlocker - This bug violates the following F19 final release criterion: "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working" 17:43:38 * jreznik is 0 now, slightly +1 as we should not make users with windows sad 17:44:30 I think the proposed solution is to have ntfs as a dep of anaconda. that way it is not in @base 17:44:47 that was *a* proposed solution 17:44:59 there are several ways this could get fixed, but i don't think it's right for us to try and prescribe one... 17:45:00 kparal: AFAIK, that wouldn't work, ntfs needs to be on the installed system 17:45:11 ack 17:45:38 adamw: that's what I meant :) 17:46:05 other ack/nak/patch? 17:46:12 фсл 17:46:13 ack 17:46:34 probably ack, but I'd be willing to waive it if it was broken in F18 as well 17:47:03 so punt and check f18? 17:47:11 I wouldn't mind 17:47:21 so 2 acks and 2 naks? 17:48:09 who's the second nak? 17:48:17 jreznik, I think 17:48:23 I honestly can't tell for either of you 17:49:19 that means we should punt it and poke relevant devs :) 17:49:26 kparal: +1 17:50:09 whoops, /me already updated the bug 17:50:14 bad me 17:50:20 adamw: to which conclusion? 17:50:23 accepted 17:50:26 i can undo if necessary 17:50:34 alright, let's accept it then :) 17:50:53 heh 17:50:54 ack 17:50:57 ack 17:51:12 #agreed 964586 - AcceptedBlocker - This bug violates the following F19 final release criterion: "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working" 17:51:22 #topic (959677) IndexError: list index out of range 17:51:22 #link https://bugzilla.redhat.com/show_bug.cgi?id=959677 17:51:22 #info Proposed Blocker, anaconda, MODIFIED 17:51:48 I think this is the "anaconda crashes if you don't select disks" bug 17:52:00 yes 17:52:06 already fixed in newer anaconda 17:52:23 +1 17:52:33 we have more guys hitting it 17:52:35 +1 17:52:37 +1 17:52:43 mostly people hit it because of the check mark UI confusion 17:52:56 +1, sure, this is the kind of thing a final release shouldn't have 17:54:56 proposed #agreed 959677 - AcceptedBlocker - Violates the following F19 beta release criterion when no disks are selected during install from usb media: "When using the custom partitioning flow, the installer must be able to ... reject or disallow invalid disk and volume configurations without crashing." 17:55:07 ack 17:55:25 ack 17:55:28 ack 17:55:50 #agreed 959677 - AcceptedBlocker - Violates the following F19 beta release criterion when no disks are selected during install from usb media: "When using the custom partitioning flow, the installer must be able to ... reject or disallow invalid disk and volume configurations without crashing." 17:56:01 #topic (967527) /root/anaconda-ks.cfg crashes anaconda 17:56:01 #link https://bugzilla.redhat.com/show_bug.cgi?id=967527 17:56:01 #info Proposed Blocker, anaconda, NEW 17:56:47 this is a race condition 17:57:44 however please note that the crashes only occurred with "clearpart --none" (and the disk was full) 17:57:53 so it might not be a frequent use case 17:58:09 0 17:58:24 clearpart --none on a full disk seems kind of odd? 17:58:25 with "clearpart --all", anaconda just refused to set up disk partitioning properly sometimes 17:58:38 adamw: we forgot to adjust the kickstart initially, that's all 17:59:00 adamw: I don't know, maybe it crashes with an empty disk as well. we haven't tried that 17:59:08 we can re-test 17:59:24 I'd be ok with punting for more data 17:59:35 yeah, me too 17:59:42 acceptedFE already though 17:59:47 so what data do you want? 17:59:48 fixing crashers is almost always a good idea 17:59:54 'does it crash with an empty disk' for a start 18:00:30 ok 18:00:55 does it crash with an empty disk using clearpart --none, does it complete with an empty disk with clearpart --all 18:01:35 the "secondary" problem that clearpart --all sometimes didn't work well is a serious issue in itself 18:01:59 but I'm not sure whether it's related or not to the main problem, so it's just a note 18:02:20 what is the configuration for the vm? how many disks? 18:02:29 1, IIRC 18:03:01 yes 18:03:35 proposed #agreed 967527 - AcceptedFreezeException - Crashers in ks are good to fix but we still need more information before making a decision on blocker status. Will revisit when there is more information on whether the errors persist with empty disks 18:03:45 ack 18:03:53 ack 18:04:03 ack 18:04:08 #agreed 967527 - AcceptedFreezeException - Crashers in ks are good to fix but we still need more information before making a decision on blocker status. Will revisit when there is more information on whether the errors persist with empty disks 18:04:12 #topic (951951) iscsi.service should not run on systems without iSCSI 18:04:15 #link https://bugzilla.redhat.com/show_bug.cgi?id=951951 18:04:18 #info Proposed Blocker, iscsi, MODIFIED 18:04:19 +1 18:04:45 i'd be -1/+1 on this one strictly 18:04:51 criteria "all services start normally" 18:05:00 i think it's OK to 'waive' the services criterion for cases where a service fails because of missing hardware 18:05:09 that case wasn't really considered in initially drafting it 18:05:16 but obviously if we can fix it better, it's good 18:05:21 adamw: agreed 18:05:30 i should probably revise that criterion somehow, but it doesn't seem easy 18:05:33 hasn't this been fixed already, though? 18:05:38 yes 18:05:38 it's ON_QA i think 18:05:51 but it wasn't verified with iscsi hardware 18:05:52 well, no-one's tested yet that it still works if you actually have iSCSI, so someone probably should :) 18:05:53 just without it 18:05:55 fixed. 18:05:58 -1 blocker, it should just be updated now 18:07:00 yeah, I'd say -1 blocker and test to make sure it isn't breaking iscsi 18:07:52 tflink: but all services shall start normally 18:07:54 although I'm a little unclear on how you'd bootstrap iscsi unless you installed w/ iscsi 18:08:22 but I could be misunderstanding the condition that's being used here 18:08:37 IIRC, you can't add a sw node until iscsi.service is running 18:08:50 I departed for 5 minutes. imho +1 18:08:54 well, the maintainer said the change made sense, so i figured that was OK... 18:09:01 but it definitely needs testing 18:09:08 yeah, I assume that he knows more than I do 18:09:15 still, add a comment to that effect 18:09:23 he may only have considered the 'iscsi present on install' case i guess 18:09:26 either way, +1/-3 18:09:53 other votes? 18:10:08 kparal: blocker vote? 18:10:21 -1 blocker 18:11:12 proposed #agreed 951951 - RejectedBlocker - This doesn't violate any of the F19 final release criteria and is thus rejected as a release blocking bug for F19 final 18:11:17 ack/nak/patch? 18:11:57 ack 18:12:09 ack 18:12:25 no 18:12:27 All services in a default install must start properly 18:12:52 ignatenkobrain: you've already been outvoted by a 3 vote margin 18:13:00 tflink: =) 18:13:19 the ack/nak is whether or not you think the #agreed represents the result of conversation/voting 18:13:23 ignatenkobrain: adamw tried to explain why it should apply in this case 18:13:31 *should not apply 18:14:28 ack 18:14:30 #agreed 951951 - RejectedBlocker - This doesn't violate any of the F19 final release criteria and is thus rejected as a release blocking bug for F19 final 18:14:43 #topic (903136) Screen brightness does not change using Hardware keys since kernel upgrade to 3.7 (Intel graphics) 18:14:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=903136 18:14:49 #info Proposed Blocker, kernel, NEW 18:15:32 most of the reports came from F18 18:15:35 problem in all new ThinkPads 18:15:56 it uses more or less the same kernel, but still F18 18:16:10 actually I don't see any report of having it broken from F19 18:16:23 ignatenkobrain: have you tried with F19? 18:16:47 I'm probably -1 blocker here - it's not that serious for livecds and could be fixed with an update in other cases 18:16:52 kparal: yep. in upstream: https://bugzilla.kernel.org/show_bug.cgi?id=51231 18:17:04 the issue is very unpleasant wrt to battery life, but fortunately can be fixed post-release 18:17:14 and I don't see any gain on blocking the release 18:17:23 yeah, i'd agree -1 on that basis, though it's unfortunate 18:17:47 -1 blocker (/me is back after forced restart) 18:19:19 -1 from me 18:20:04 Agree with other. -1 =( 18:20:14 proposed #agreed 903136 - RejectedBlocker - While unfortunate for users of affected laptops, this doesn't violate any F19 release criteria and could be fixed with a post-release update in most situations. Thus, rejected as a blocker for F19 final 18:20:17 ack 18:20:27 ack 18:20:36 ack 18:20:38 #agreed 903136 - RejectedBlocker - While unfortunate for users of affected laptops, this doesn't violate any F19 release criteria and could be fixed with a post-release update in most situations. Thus, rejected as a blocker for F19 final 18:20:54 #topic (963698) UnicodeEncodeError in pkcon install-local 18:20:54 #link https://bugzilla.redhat.com/show_bug.cgi?id=963698 18:20:54 #info Proposed Blocker, PackageKit, ASSIGNED 18:22:33 in a nutshell, this probably affects a lot of languages. and some (probably not all) third-party rpm packages 18:22:52 it kills both local pkcon and its gui 18:23:03 doesn't this sound like that bug we fixed for beta? 18:23:20 IIUC that was a different one, but very similar 18:23:30 * kparal is a bit lost in all those PK bugs 18:23:42 * IIUC-> IIRC 18:23:44 me too... 18:23:47 does it affect fedora packages? 18:24:00 tflink: not in the fedora repositories 18:24:00 or just 3rd party? 18:24:05 rpmfusion 18:24:06 is it reproducible with current PK? 18:24:19 probably -1 blocker, then 18:24:24 i.e. since https://admin.fedoraproject.org/updates/FEDORA-2013-8637/PackageKit-0.8.9-1.fc19 showed up? 18:24:39 hrm, I forgot to re-test 18:24:54 punt for re-test at least? 18:25:02 or can you do it now? 18:25:10 I'm quite sure it's still broken. but I'll re-test tomorrow 18:25:22 not now, unfortunately 18:25:25 should be simple to run reproducer from hughsie 18:25:44 jreznik: but that's not in pk 18:26:03 it's somewhere in between 18:26:13 if pk doesn't crash badly when yum does this, i'm not as worried 18:26:26 to the point where I might be -1 FE 18:26:41 seems it should go to yum, and hack is probably in pk 18:26:48 I'll ask zdenek tmrw 18:26:54 let's punt then 18:26:56 so punt? 18:27:00 punt 18:27:43 proposed #agreed 963698 - We'd like to see re-testing with the most recent PK before deciding on blocker status, will revisit when that information is available 18:27:47 ack/nak/patch? 18:27:47 brb call of nature 18:27:53 ack 18:28:14 * kparal puts on adamw's moustache and says 'ack' 18:28:21 ack 18:29:22 kparal: http://ur1.ca/e39ut ? 18:29:46 #agreed 963698 - We'd like to see re-testing with the most recent PK before deciding on blocker status, will revisit when that information is available 18:30:04 #topic (965213) poor handling of user ignoring one disk of an existing md array via ignoredisk 18:30:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=965213 18:30:10 #info Proposed Blocker, python-blivet, ASSIGNED 18:31:26 how does a device become ignored? 18:31:42 I think if you boot from it 18:31:53 or that's 'hidden' maybe 18:32:33 call in dlehman? 18:32:59 oh, look @ comment 14 18:33:21 I wonder if this is the case where there used to be sw raid and the new install is using only part of the old array 18:33:31 might be 18:34:09 tflink: that's a part of it 18:34:57 dlehman: we're just discussing 965213 18:35:16 the 'ignored' stuff is this, from the kickstart: 18:35:17 ignoredisk --only-use=sda 18:35:35 the system has more than just sda, but the kickstart instructs anaconda to 'ignore' everything else; the issue is in how that 'ignoring' is handled exactly, iiuc 18:35:51 right 18:36:00 ha, I didn't notice the ks 18:36:40 so for my money this would never be a blocker since the user is necessarily making a mess 18:36:48 I wonder why he specifies ignoredisk, when he uses --onlydisk=sda everywhere else 18:36:55 belt and braces 18:37:16 yeah, i find it a bit hard to quantify but my instinct is not a blocker because of all the moving parts...still, it'd be good to fix it 18:37:16 is it enough to hit the ks criterion? 18:37:22 the one we have? nah 18:37:35 but since we didn't write better ones, we're still on 'kickstart issues are case-by-case' 18:38:02 yeah, I don't I'd block release if this were the last bug left 18:38:22 dlehman: so basically this is going to affect cases where you specify 'ignoredisk' parameters that result in part of a pre-existing mdraid array being 'ignore'd? and...anything else? 18:38:50 could apply to any multi-device stack, so md|lvm|btrfs 18:39:08 ah, right 18:39:35 * dlehman has no sympathy for users who do this sort of thing 18:39:44 i could see that being moderately common, reluctant to +1 still. oh, +1 fe though 18:40:05 quit making messes and then complaining about the fact that there's a mess 18:40:26 there are some valid use cases for this when testing, though 18:40:31 well, less invalid 18:41:09 I see this as a valid use cases, although quite uncommon one 18:41:14 *case 18:41:28 anyhoo, votes? 18:41:44 -1/+1 18:41:45 -1/+1 18:41:47 otherse? 18:41:49 0 18:41:53 -1/+1 18:41:57 -1/+1 for me just to be clear 18:43:25 proposed #agreed 965213 - RejectedBlocker AcceptedFreezeException - While unfortunate, this bug is somewhat self-inflicted and somewhat of a corner case. Thus, it does not violate any F19 release criteria and is not a release blocking bug for F19. However, it seems like it could be common enough to justify taking a tested fix after freeze/ 18:43:31 proposed #agreed 965213 - RejectedBlocker AcceptedFreezeException - While unfortunate, this bug is somewhat self-inflicted and somewhat of a corner case. Thus, it does not violate any F19 release criteria and is not a release blocking bug for F19. However, it seems like it could be common enough to justify taking a tested fix after freeze. 18:43:35 punctuation change 18:43:42 ack 18:43:48 ack 18:44:02 ack 18:44:07 #agreed 965213 - RejectedBlocker AcceptedFreezeException - While unfortunate, this bug is somewhat self-inflicted and somewhat of a corner case. Thus, it does not violate any F19 release criteria and is not a release blocking bug for F19. However, it seems like it could be common enough to justify taking a tested fix after freeze. 18:44:21 ~ 15 minutes until the 3 hour mark 18:44:29 4 proposed blockers remaining 18:44:33 #topic (966795) DeviceCreateError: ('lvcreate failed for fedora_sharpie00/swap: running lvm lvcreate -L 6160m -n swap --config devices { filter=["r|/loop3$|","r|/loop4$|","r|/loop5$|","r|/loop6$|","r|/loop7$|"] } fedora_sharpie00 failed', 'fedora_sharpie00-swap') 18:44:37 #link https://bugzilla.redhat.com/show_bug.cgi?id=966795 18:44:39 #info Proposed Blocker, python-blivet, ASSIGNED 18:45:56 hrm, I would have thought that we would have seen this more often if it was a big problem 18:45:56 is lvm-on-raid5-md part of the criteria? 18:46:14 I think that fits under "workable partition layout" 18:46:28 nice umbrella 18:46:45 so it's specific to lvm on raid5-md? 18:47:05 yes. possibly other raid levels, but not 0 or 1 AFAIK 18:47:24 +1 18:48:03 +1 18:48:37 dlehman: we've had that umbrella criterion forever; i agree it kinda stinks but it's pretty tough to come up with something less wide but still covering everything we want to cover :/ 18:48:50 it took us like four shots to come up with workable beta criteria, never mind final 18:49:19 the fact that this crashes makes me +1 18:49:25 proposed #agreed 966795 - AcceptedBlocker - Violates the following F19 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" 18:49:30 it's fine with me as long as people are reasonable when the definition of "workable" gets tested 18:49:38 ack 18:49:42 "Fell short by a single extent" -> "missed it by that much"? :) 18:49:59 ack 18:50:05 dlehman: sure, any time you think we've pushed that too far, please mention it in the bug or a review meeting 18:50:11 ack 18:50:16 this one should be a blocker IMO 18:50:24 ack 18:50:35 #agreed 966795 - AcceptedBlocker - Violates the following F19 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" 18:50:47 #topic (892178) rngd.service should behave more elegantly in the case where no hardware RNG is present 18:50:48 dlehman: you guys effectively have a veto on what is considered 'workable' 18:50:50 #link https://bugzilla.redhat.com/show_bug.cgi?id=892178 18:50:52 #info Proposed Blocker, rng-tools, NEW 18:51:06 this is like the iscsi one from earlier 18:51:11 we 'waived' it for f18 final and i think that's fine 18:51:17 though it'd be nice to fix it if possible 18:51:53 so, -1/+1 18:51:54 +1 18:52:00 * kparal nods 18:53:07 -1/+1 18:53:19 and i'll throw a 'revise the service criterion' entry on my endless todo list 18:53:25 if someone else wants to do it, *please* do 18:53:52 moar votes? 18:54:03 we're -1/+2 overall right now 18:54:13 -1/+1, I thought it was obvious 18:54:54 -1/+1 18:55:46 proposed #agreed 892178 - RejectedBlocker AcceptedFreezeException - While this doesn't directly violate any F19 release criteria (system operation isn't dramatically affected), it would be preferred if the rngd service started properly or not at all instead of failing. A tested fix would be considered past freeze 18:55:51 ack/nak/patch? 18:56:05 ack 18:56:10 btw, we have 2 more proposed blockers and 5 minutes til the 3 hour mark 18:56:34 any objections to getting through the rest of the proposed blockers before closing out the meeting? 18:57:06 no 18:57:11 * jreznik has a different meeting but more listening one, so go on 18:58:41 * kparal pokes adamw 18:58:51 sorry 18:58:52 or jreznik 18:58:56 that works for me 18:58:58 ack' 18:59:00 #agreed 892178 - RejectedBlocker AcceptedFreezeException - While this doesn't directly violate any F19 release criteria (system operation isn't dramatically affected), it would be preferred if the rngd service started properly or not at all instead of failing. A tested fix would be considered past freeze 18:59:10 #topic (928741) Totem crashes when I try to play ogv (ogg) 18:59:10 #link https://bugzilla.redhat.com/show_bug.cgi?id=928741 18:59:10 #info Proposed Blocker, totem, NEW 19:00:01 +1 and already fixed 19:00:19 sounds like it's already fixed 19:00:23 punt or +1 19:00:24 ? 19:00:54 is it the same video? seems like not 19:00:59 I asked Petr to re-test this, but he probably forgot 19:01:24 i just played that ogv of some other bug in totem, so it works for me :) 19:01:35 kparal: video from test day gnome and all works 19:01:41 although ogv is a container format like mkv, IIRC, so behaviour can vary depending on what formats are in the container 19:01:47 let's close and ask to reopen if anybody sees that anymore 19:02:06 and I'll torment Petr for not providing a link to the video 19:02:27 kparal: from test day gnome 19:02:52 that's possible 19:03:14 ack to close 19:03:30 #info this appears to have been fixed and will be closed 19:03:35 #undo 19:03:35 Removing item from minutes: 19:03:51 #info 928741 appears to have been fixed and will be closed 19:04:16 #topic (679486) Unable to start graphical installer on RC1 KDE live image 19:04:20 #link https://bugzilla.redhat.com/show_bug.cgi?id=679486 19:04:22 #info Proposed Blocker, xorg-x11-xauth, ASSIGNED 19:05:28 the fun one 19:05:55 I saw some comment lately on the test list? that somebody was affected too 19:06:01 so it's not just Red Hatters :) 19:06:38 I'm +1 blocker 19:06:52 there are other ways to fix it then xauth, some of them are simple hacks 19:07:00 of course a proper solution would be nice 19:07:16 would running liveinst via sudo fix this? 19:07:20 yes 19:07:29 dlehman: wdyt of that? 19:07:52 i think we may have to do it for f20 anyway because of https://bugzilla.redhat.com/show_bug.cgi?id=964299 19:08:02 but i suppose it could cause something _else_ to break 19:09:33 -1/+1 19:10:17 kparal: and yeah, some guy on the test@ list was affected recently 19:10:25 what has changed to make this a blocker where it hasn't been since F15? 19:10:27 and i think i saw someone else mention seeing it again lately, i forget who 19:11:03 https://bugzilla.redhat.com/show_bug.cgi?id=679486#c65 19:11:08 "We agreed that our decision from F15 timeframe still stands and this is not a blocker bug, as it only affects a fairly small range of users (cases where DHCP hostnames are used), and it's relatively easy to work around." 19:11:22 tflink: I don't remember seeing this problem _that much_ in past releases. I can't say I never saw it, I don't know, but I don't really remember being affected 19:11:50 so probably something must have changed to trigger it much more? 19:11:56 maybe our network is slower these days :) 19:12:13 I saw it mentioned several times for korora 19:12:15 i guess i'm still -1 on it 19:12:19 though it does kinda suck 19:12:29 * jreznik is more -1 but would like to see it finally solved 19:12:32 I think the workarounds are pretty simple 19:13:11 sounds like we're mostly -1/+1 19:13:19 I mean the workarounds that can be incorporated on the CD itself 19:14:59 proposed #agreed 679486 - RejectedBlocker AcceptedFreezeException - While this doesn't directly violate any F19 release criterion and thus is not a release blocking bug, it does seem to be more commonly hit now than in the past. A tested fix would be considered past freeze. 19:15:09 ack 19:15:13 ack 19:15:17 ack 19:15:19 hail to the long-lived bugs :) 19:15:21 #agreed 679486 - RejectedBlocker AcceptedFreezeException - While this doesn't directly violate any F19 release criterion and thus is not a release blocking bug, it does seem to be more commonly hit now than in the past. A tested fix would be considered past freeze. 19:15:34 and that would be all of the proposed blockers on my list 19:15:50 huh! good 19:15:53 phew 19:15:53 since we're over the 3 hour time limit, I propose we end the meeting 19:16:04 #topic Open Floor 19:16:15 Anything else that should be brought up? 19:16:16 tflink: continue :D 19:16:59 I think I should add some points to my stamina. maybe endurance. I feel really tired after these meetings 19:17:12 yeah, I know the feeling 19:17:23 sorry kparal :( 19:17:25 we must be getting weak with no more 6+ hour meetings 19:17:30 we do need to get through the anaconda proposedFE's at some point 19:17:36 since anaconda wants us to gate for them 19:17:41 but it's definitely better than F18 19:17:55 yeah, we only really need one or two epics per milestone so far 19:18:07 true, but the whole point of starting today was due to the long list which we've done well on so far 19:18:19 hooray :) 19:18:22 we could continue tomorrow? 19:18:34 i'd be okay to do that but i don't know if anyone else wants to :) 19:19:16 other thoughts? 19:19:23 tomorrow is fine 19:19:33 I can't promise I'll join you tomorrow, but I'll try 19:19:47 but I'll need to leave in about 1.5 hours 19:19:57 * jreznik continues with another meeting now, so needs something for stamina too :) 19:20:21 ok, I'll send out an announce for a continuation tomorrow; same bat-time, same bat-channel 19:20:29 jreznik: there should be some potions for that, I heard 19:20:46 don't know the color, maybe white 19:20:48 nirik is handing out patience over in #fedora-releng 19:20:55 i don't know if he has stamina on-hand 19:20:59 :) 19:21:55 anyhow, unless there's other business, the fuse has been set 19:22:10 booom 19:22:42 kparal: you have beer ? 3 liters 19:23:18 ignatenkobrain: no, I don't have beer here. maybe that's the mistake I made :) 19:23:33 .fire kparal inadequate refreshment 19:23:33 adamw fires kparal inadequate refreshment 19:23:42 ooh, I *can* specify reasons! 19:23:50 * kparal will try better next time 19:24:27 * ignatenkobrain poke kparal 19:26:05 Thanks for coming, everyone! 19:26:19 * tflink will send out minutes and next meeting announce shortly 19:26:19 thanks guys 19:26:22 #endmeeting