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