16:00:26 <tflink> #startmeeting f18beta-blocker-review-4
16:00:26 <zodbot> Meeting started Wed Oct 17 16:00:26 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:26 <tflink> #meetingname f18beta-blocker-review-4
16:00:26 <zodbot> The meeting name has been set to 'f18beta-blocker-review-4'
16:00:31 <tflink> #topic Roll Call
16:00:39 <tflink> Who's ready for some blocker review?
16:01:06 * adamw loves him the blocker review
16:01:19 * nirik is lurking, will try and pay attention sometimes.
16:01:49 * jreznik is here, another meeting but...
16:01:56 <tflink> #chair adamw
16:01:56 <zodbot> Current chairs: adamw tflink
16:03:29 * tflink waits for a few more people
16:03:41 * satellit_e listening
16:03:57 <akshayvyas> Viking-Ice is here i think
16:05:13 <tflink> interesting - the sort function I use for the meeting list is case sensitive while the sorting function on the web front end is not
16:06:28 <tflink> so who all is not lurking besides adam?
16:07:21 * jreznik is ready - you know, it's about priorities :)
16:07:47 <jreznik> and you know, blocker review is more fun than platform pgms meeting :)
16:08:14 <dan408-> i would like to bring up https://bugzilla.redhat.com/show_bug.cgi?id=865073
16:08:31 <dan408-> this is causing tc4, smoke10,smoke11 netinst to fail
16:08:37 <dan408-> smoke11 dvd crashes instantly
16:08:41 <tflink> there is a smoke11?
16:08:51 <dan408-> sorry
16:09:01 <dan408-> i wish
16:09:04 <satellit_e> crashed for me on smoke 10 netinstall
16:09:11 <dan408-> i meant smoke9,smoke10
16:09:36 <dan408-> anaconda is crashing on any dependency problems
16:09:43 <nirik> this should have been fixed in todays branched compose. Make sure you are hitting a up to date mirror.
16:10:15 <tflink> nirik: I built that image late last night
16:10:30 <dan408-> hmm
16:10:37 <dan408-> booting smoke 10
16:10:37 <tflink> well, lets try to get started
16:10:46 <nirik> tflink: right, the dvd image there if you are using only it as install source would still fail that way
16:10:54 <nirik> netinstall should work now.
16:11:02 <tflink> yeah, I'll have to build another smoketest
16:11:07 <dan408-> nirik: nope
16:11:09 <satellit_e> not 10 minutes ago
16:11:23 <nirik> which mirror did you hit?
16:11:36 <dan408-> i didnt get a chance to hit a mirror this time :D
16:11:38 <tflink> the netinstall worked for me a little while ago
16:11:39 <dan408-> it's worse now
16:12:06 <jreznik> well, shouldn't we start real blocker review? :)))
16:12:08 <dan408-> okay maybe a new smoke tflink?
16:12:10 <nirik> then it's not the same bug.
16:12:22 <tflink> dan408-: like I already said, I'll have to build another one
16:12:32 <dan408-> yessir
16:12:40 <tflink> jreznik: yeah, it's about that time
16:12:47 <tflink> #topic Introduction
16:12:57 <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:13:04 <tflink> #info We'll be following the process outlined at:
16:13:04 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:13:10 <tflink> #info The bugs up for review today are available at:
16:13:10 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:13:15 <tflink> #info The criteria for release blocking bugs can be found at:
16:13:16 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
16:13:16 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
16:13:16 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
16:13:36 <tflink> #info Up for review today we have:
16:13:39 <tflink> #info 15 Proposed Blockers
16:13:39 <tflink> #info 23 Accepted Blockers
16:13:39 <tflink> #info 1 Proposed NTH
16:13:39 <tflink> #info 9 Accepted NTH
16:14:06 <tflink> any objections to starting with proposed blockers?
16:14:28 <dan408-> no
16:14:52 <akshayvyas> nope
16:14:57 <tflink> #topic (862784) error: rpmdb open failed
16:14:57 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862784
16:14:57 <tflink> #info Proposed Blocker, anaconda, NEW
16:14:58 <jreznik> go on
16:15:46 <dan408-> that bug is kind of out of date
16:16:38 * tflink re-reads the partitioning criteria thread
16:16:38 * jreznik is looking on the dupe bug
16:16:58 <dan408-> that bug references anaconda 18.11
16:17:41 <nirik> and 18.14
16:18:25 <dan408-> not fixed in 18.17
16:18:34 <tflink> We were waiting until the partitioning criteria were edited to reject this as a beta blocker
16:19:52 <dan408-> i think this is a valid blocker
16:19:53 <tflink> but I'm not seeing a consensus on test@
16:20:06 <tflink> well, consensus on specific wording
16:20:18 <akshayvyas> i think we should keep it until we get the partitioning criteria
16:20:39 <akshayvyas> would like to hear from adamw
16:20:42 <tflink> unless we have enough consensus on the criteria change to reject it
16:21:11 <adamw> sorry, i'm back
16:21:19 <jreznik> so punt now?
16:21:25 <tflink> we're sorry, too :-D
16:21:32 <adamw> so aiui this bug boils down to 'if you try to re-use an existing partition, it doesn't get formatted and you can't change that'
16:21:45 <dan408-> yes
16:21:52 <dan408-> i have reproduced this many times
16:21:52 <adamw> the question is whether we need to support assigning a mount point to an existing partition and formatting it at beta
16:22:00 <dan408-> yes
16:22:07 <adamw> obviously there's a 'workaround', which is 'create the partitions in anaconda'
16:22:13 <akshayvyas> adamw: +1
16:22:22 <adamw> so my instinct is -1 blocker, but...
16:22:30 <dan408-> +1 blocker
16:22:30 * tflink thinks this is more of a final blocker candidate
16:22:38 <adamw> we certainly didn't require this to work for beta in <18.
16:22:41 <tflink> -1 beta blocker
16:22:48 <dan408-> i think we should require it
16:22:52 <dan408-> in beta
16:23:13 <adamw> so, we don't have a consensus there, and we don't have a whole lot of people
16:23:35 <adamw> sounds punt-y
16:23:40 * adamw call of nature
16:23:43 <dan408-> if you are reinstalling with over a VM with an existing partition
16:23:57 <dan408-> you are affected
16:24:02 <tflink> proposed #agreed 862784 - We're still waiting on criteria changes in order to make a decision, will re-visit once the criteria changes have gone through
16:24:07 <akshayvyas> ack
16:24:08 <tflink> ack/nak/patch?
16:24:09 <jreznik> ack
16:24:31 <jreznik> but I'm more -1 blocker at least for beta too
16:24:59 <dan408-> nak
16:25:07 <tflink> jreznik: yeah, that sounds like the way we're leaning overall but the current criteria wording makes it less clear
16:25:08 <Viking-Ice> nak
16:25:10 <tflink> dan408-: patch?
16:25:15 <tflink> Viking-Ice: patch?
16:25:23 <dan408-> define "patch"
16:25:24 <dan408-> sorry
16:25:36 <Viking-Ice> just propose it accept as a blocker
16:25:42 <tflink> dan408-: patch to change the proposed #agreed
16:26:16 <dan408-> patch
16:26:43 <dan408-> definitely
16:26:53 <tflink> dan408-: and that patch would be ...
16:27:30 <tflink> from what I can see, if we take a vote right now, we're -3/+2 beta blocker
16:27:39 <Viking-Ice> btw "*raising* the bar for beta is the right thing to do
16:27:50 <dan408-> We shouldn't depend on criterion being defined to decide on accepted blockers, they should be decide on a case by case basis, in this case, it is blocking installs which is a beta blocker already.
16:27:58 <dan408-> decided*
16:28:55 <tflink> dan408-: it doesn't affect all installs. it would not have been a beta blocker in previous releases. beta is not supposed to be perfect
16:29:06 <adamw> we clearly don't have a majority for accepting the bug as a blocker.
16:29:18 <adamw> is anyone who's -1 on blocker changing their minds?
16:29:23 <dan408-> tflink: it is reproduceable enough
16:29:31 <dan408-> adamw: no.
16:29:50 <tflink> so we either find more votes, reject or punt
16:29:59 <tflink> there are not enough +1 votes to accept right now
16:30:09 <akshayvyas> dan408-: is it reproduceable on bare metal ??
16:30:31 <tflink> dan408-: reproducability isn't the only factor in blocker status
16:30:36 <Viking-Ice> let's take a middle ground and accepted as nth even if we change the criteria now those changes wont take effect until next release
16:31:05 <akshayvyas> Viking-Ice: +1
16:31:06 <jreznik> Viking-Ice: not sure we can raise the bar now for beta... just my pgm hat, even I'd like to... just saying :)
16:31:10 * tflink is a little wary of NTH, to be honest
16:31:13 <cmurf> if anaconda isn't going to support partition re-use it shouldn't be NTH
16:31:34 <cmurf> sounds like a feature question first, before it could even be considered a bug
16:31:38 <cmurf> let alone a blocker
16:31:43 <adamw> nth is not a middle ground between blocker and nothing
16:31:44 <tflink> I don't want to be taking a change for something like this late in freeze if its not a blocker
16:31:51 <Viking-Ice> so waiting for adamw proposals bears no meaning and the current proposal that has been used for previous release cycles are still in effect
16:31:55 <adamw> it has a specific definition - 'we would take this fix after the freeze'
16:32:27 <dan408-> i think that this is something that would even be an alpha blocker
16:32:32 <dan408-> but okay
16:32:33 <zodbot> Ticket notification - f18betablocker: [Bug 862784] newUI custom partitioning does not allow formatting of an existing partition for use in the installed system <https://bugzilla.redhat.com/show_bug.cgi?id=862784>
16:32:39 <dan408-> lets move on
16:32:54 <adamw> Viking-Ice: this whole thing about how criteria changes don't take effect until the next release is something you've dreamed up. it's not a policy, nor has it ever been. we have adjusted the criteria during the release process already this cycle and will likely do it again in future.
16:33:14 <tflink> especially since the criteria in question are new for F18
16:33:47 <tflink> the unintended consequences of their wording is why we're talking about revising them
16:33:48 <dan408-> i dont like the idea of changing crterion on the fly to push some thing out is a good idea
16:33:50 <adamw> you think criteria changes *should* only take effect with the next release, fine, but that is not in fact how things have worked up till now and it's never been adopted as policy by anyone ever so far as I can make out.
16:34:17 <adamw> so I do wish you'd stop stating it like it's a law.
16:34:22 <Viking-Ice> adamw, so you are pulling the RED  HAT WAY  just like you running around changing well defined criteria that has work every goddamn release cycles before you got put into QA
16:34:32 <dan408-> lol
16:34:38 <tflink> dan408-: your assertion is that all the criteria are worded perfectly now, even though they have been changing a lot for newui?
16:34:59 <adamw> Viking-Ice: it has nothing to do with the red hat way.
16:35:09 <adamw> Viking-Ice: you're the one who's trying to unilaterally declare a policy that you've invented.
16:35:10 <dan408-> tflink: not completely
16:35:20 <tflink> dan408-: but they can't change, they must be perfect
16:35:24 <adamw> any time I come up with some kind of policy i send it through a draft on the list and try to build consensus.
16:35:39 <dan408-> tflink: im sure a lot of crterion has been changed that i dont agree with.
16:35:40 <adamw> you're the one who just shows up to meetings and declares that something you've made up Is The Way Things Are.
16:35:58 <Viking-Ice> adamw, and you are not changing those criteria to meet the new installers deficiency because Anaconda cant meet it this release cycle ""RH has asked its staff on the anaconda team to prioritize work on a pending RHEL release over work on Fedora 18, and that is happening" .
16:36:04 <jreznik> guys, please - we have a looong list of bugs to review
16:36:04 <tflink> I notice that the two people here most irritated by the change haven't been participating much in the discussion on test@
16:36:13 <dan408-> adamw: only the crazies like me and Viking-Ice show up on irc ;)
16:36:19 <adamw> Viking-Ice: no I'm not. as we've clearly stated already, the f17 criteria do not require this to work.
16:36:26 <tflink> proposed #agreed 862784 - We're still waiting on criteria changes in order to make a decision, will re-visit once the criteria changes have gone through
16:36:31 <adamw> Viking-Ice: go back and look at 'em if you like. point me to the f17 alpha or beta criterion which makes this a blocker.
16:36:33 <dan408-> ack
16:36:38 <akshayvyas> ack
16:36:39 <Viking-Ice> ack
16:36:41 <adamw> ack
16:36:42 <jreznik> ack
16:36:43 <cmurf> ack
16:36:48 <tflink> #agreed 862784 - We're still waiting on criteria changes in order to make a decision, will re-visit once the criteria changes have gone through
16:36:51 <tflink> finally
16:36:57 <tflink> #topic (865776) kernel pair boot with inst.repo=nfs: hangs on reboot
16:36:57 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=865776
16:36:57 <tflink> #info Proposed Blocker, anaconda, NEW
16:37:54 <zeenix> vhumpa: hi
16:37:55 <dan408-> Viking-Ice: lay off a bit
16:38:14 <dan408-> Viking-Ice: im with you
16:38:27 <tflink> has anyone gotten pxe to work recently?
16:38:34 <zeenix> vhumpa: re: 867485. I can update the package if i can get the right acl
16:38:46 <dan408-> haven't tried
16:38:51 <tflink> I tried the other day and hit some errors but I haven't finished figuring out what exactly went wrong
16:40:14 <tflink> I'd be interested in finding out if this happens with regular PXE + http
16:40:28 <tflink> ie, is the loopmounted iso over nfs causing the problems
16:40:33 <cmurf> 865776: i'm not understanding if the bug is the failure to reboot, or if there is a failure in the installation, or a failure with the resulting system
16:40:40 <cmurf> sounds like the installer did use NFS
16:40:53 <dan408-> i think we should revisit this later
16:41:03 <tflink> I think it's a failure of the installer to boot completely
16:41:14 <tflink> which isn't disimilar to what I saw the other day
16:41:59 <tflink> I don't see any votes yet, punt for more info?
16:42:01 <vhumpa> zeenix: I am doing so now
16:42:17 <dan408-> punt
16:42:19 <zeenix> vhumpa: yeah, i just realized after cloning the repo :)
16:42:22 <zeenix> vhumpa: thanks!
16:42:43 <vhumpa> zeenix: I thank you :)
16:43:09 <tflink> anyone else? bueller?
16:43:11 <vhumpa> zeenix: just don't read the git log please :)
16:43:18 <adamw> this is a failure to reboot after install is complete, AIUI.
16:43:33 <zeenix> vhumpa: i wouldn't have if you hadn't said so :)
16:43:39 <adamw> which is kind of a grey area. iirc we had a similar bug for f17, we should probably check what we did with that one.
16:43:55 <adamw> "If I boot vmlinuz+initrd in a VM (this is equivalent to PXE boot) and use "inst.repo=nfs:" boot option, the system fails to reboot after the installation. Hard reboot is needed."
16:44:05 <tflink> yeah, I misread it
16:44:09 <dan408-> final not beta?
16:44:12 <adamw> the problem case here, i believe, is when you're installing to a remote system and don't necessarily have an easy way to force a reboot.
16:44:17 <zeenix> vhumpa: its ok, i had similar frustration when i updated gnome-boxes package yesterday
16:44:19 <adamw> yeah, i might be inclined to go final on this.
16:44:31 <dan408-> +1 adamw
16:44:41 <dan408-> i gotta get in the shower
16:44:44 <dan408-> brb
16:44:58 <cmurf> I think this is the installer not quitting on reboot
16:45:16 <tflink> if this happens with all pxe installs, I think this is beta
16:45:23 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=824191 is the f17 bug
16:45:27 <cmurf> ifi the resulting installed system works, then -1
16:45:27 <tflink> is/could be
16:45:36 <adamw> it was one of the ones we fudged for the final f17 release, and we in fact rejected it as a final blocker.
16:45:44 <adamw> so to be consistent we certainly shouldn't take this as a beta blocker.
16:46:09 <tflink> if it's just pxe+nfs, sure
16:46:16 <cmurf> yeah, not elegant for the installer to just cave in, but if the resulting system is usable, then ultimately it worked
16:46:19 <tflink> if it's all pxe, I'm not sure it's the same thing
16:46:20 <adamw> comment #32 is the official determination, there are in-bug votes before that.
16:46:35 <adamw> well, the bug report specifically refers to both pxe and nfs
16:46:40 <adamw> but i dunno if kparal has tried other combinations
16:46:58 <adamw> we could -1, or punt and ask kparal for data from other combos...
16:47:14 <tflink> either way, it sounds like we're pretty much -1 blocker on this
16:47:28 <tflink> I'm not that strongly +1 since we don't have enough data
16:48:13 <cmurf> does the installed system work?
16:48:26 <adamw> it's not clearly stated, but i read it as implying that it does
16:48:26 <tflink> it's not clear but I suspect that it does
16:48:38 <cmurf> let's ask, if it works, definitely -1 for me
16:49:30 <tflink> -1 and ask for re-proposal if we've missed something?
16:49:53 <cmurf> sure
16:50:13 <adamw> sounds good
16:51:09 <tflink> proposed #agreed 865776 - RejectedBlocker (beta) - This doesn't clearly violate any of the F18 beta release criteria, would affect a minority of users and results in a working system after forcing reboot. Please re-propose if something changes or has been misunderstood.
16:51:13 <tflink> ack/nak/patch?
16:51:33 <cmurf> ack
16:51:56 <dan408-> ack
16:51:59 <akshayvyas> ack
16:51:59 <Viking-Ice> ack
16:52:05 <tflink> #agreed 865776 - RejectedBlocker (beta) - This doesn't clearly violate any of the F18 beta release criteria, would affect a minority of users and results in a working system after forcing reboot. Please re-propose if something changes or has been misunderstood.
16:52:14 <tflink> #topic (866519) BIOS RAID is not shown on harddrive screen
16:52:15 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=866519
16:52:15 <tflink> #info Proposed Blocker, anaconda, NEW
16:52:45 <dan408-> isnt this another revisit?
16:53:27 <tflink> it sounds close to blocker, to me
16:53:31 <tflink> could use more testing, though
16:53:34 <cmurf> ok wait
16:53:38 <cmurf> raid10?
16:53:42 <dan408-> no
16:53:43 <cmurf> that's not in release criteria
16:53:56 <dan408-> wait
16:53:58 <dan408-> bios raid or bios boot?
16:54:10 <cmurf> this is IMSM
16:54:21 <cmurf> and it's RAID 10
16:54:23 <tflink> I think that it was tried with multiple RAID levels
16:54:23 <cmurf> -1 blocker
16:54:48 <tflink> I'm reading it as raid5 also isn't showing up
16:54:53 <dan408-> -1 blocker
16:55:13 <cmurf> this is a confusing bug report
16:55:42 <tflink> agreed - c#12 isn't written all that well
16:55:56 <tflink> reporter either has a crapton of disks, or tried in multiple configs
16:55:59 <cmurf> c11 is what i'm going to rely on
16:56:09 <dan408-> well this goes back to criterion
16:56:16 <dan408-> right adamw?
16:56:23 <adamw> kinda
16:56:25 <adamw> we discussed it on monday
16:56:27 <dan408-> yeah.
16:56:39 <adamw> the idea was we wanted to check if it's affecting all bios raid configs or just this particular one
16:56:40 <tflink> "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot"
16:56:47 <adamw> i was supposed to test my setup here but i didn't get to it yet :/
16:57:07 <dan408-> revisit
16:57:11 <adamw> the additional data from michal indicates that at least it just can't cope with _any_ sw raid config on his controller, it's not just one specific config that doesn't work, which tends towards blocker imo
16:57:14 <zodbot> Ticket notification - commonbugsrss: [Bug 865776] kernel pair boot with inst.repo=nfs: hangs on reboot <https://bugzilla.redhat.com/show_bug.cgi?id=865776>
16:57:16 <adamw> but i'm not sure it's enough data to be sure yet
16:57:25 <adamw> does anyone else have a system they can test swraid on?
16:57:34 <dan408-> yes
16:57:37 <dan408-> just need time
16:57:38 <cmurf> it can be faked
16:57:43 <tflink> yeah, I do but I only have 2 disks in it
16:57:51 <dan408-> i have 5 disks
16:57:52 <adamw> erf, bios raid, not sw raid.
16:57:53 <cmurf> you can compel mdadm to create an IMSM array
16:57:58 <dan408-> just gimme some time
16:57:59 <dan408-> and steps
16:58:01 <dan408-> thanks
16:58:08 <cmurf> intel bios raid = md sw raid with IMSM metadata
16:58:12 <adamw> dan408: well you have to read your mobo manual :)
16:58:21 <dan408-> not for sw raid!
16:58:24 <dan408-> :P
16:58:24 <adamw> this is bios raid
16:58:29 <adamw> i was wrong when i said sw raid
16:58:31 <dan408-> psh
16:58:34 <dan408-> hw raid is easy
16:58:39 <cmurf> if this is IMSM they are the same thing
16:58:39 <dan408-> i'll test that today
16:58:50 <dan408-> lets get a working anaconda first
16:59:37 <tflink> do we have enough data to take this as a blocker?
16:59:45 <cmurf> for raid 1 yes
16:59:47 <dan408-> ack
17:00:20 <adamw> cmurf: in practice they are not always the same thing, i'm pretty sure we've had cases where sw raid worked but intel bios raid did not. i dunno the technical details, but.
17:00:35 <adamw> i'm either +1 blocker or punt until one more person can test imsm.
17:00:35 <dan408-> duty calls
17:00:41 <dan408-> i'll catch up later
17:01:04 <cmurf> adamw: it's extremely buggy imo, i would eject raid5 from the criteria
17:01:29 <tflink> ok, make votes so we can move on
17:01:40 <dan408-> adamw: ideally we should have a "F"HQL
17:01:41 <cmurf> what are we voting on
17:01:42 <tflink> I see +1
17:01:47 <tflink> blocker or punt
17:02:08 <cmurf> if punt means need more info, then punt
17:02:15 <dan408-> punt
17:02:16 <cmurf> raid1 i'd block
17:02:21 <cmurf> raid10 is a nonstarter
17:02:37 <cmurf> raid5, i'd be a +0
17:02:44 <dan408-> doesnt matter what raid level
17:02:52 <dan408-> raid or not
17:03:00 <cmurf> of course it does, the criteria specifies levels
17:03:02 <tflink> proposed #agreed 866519 - We need more information on the types of configurations affected before deciding on blocker status. Another reporter would be preferred
17:03:09 <akshayvyas> ack
17:03:10 <cmurf> +1
17:03:14 <dan408-> ack
17:03:18 <cmurf> ack
17:03:21 <Viking-Ice> ack
17:03:26 <tflink> #agreed 866519 - We need more information on the types of configurations affected before deciding on blocker status. Another reporter would be preferred
17:03:36 <tflink> #topic (866730) invalid locales configured for some languages
17:03:36 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=866730
17:03:36 <tflink> #info Proposed Blocker, anaconda, NEW
17:03:58 <dan408-> +1 blocker
17:04:40 <tflink> I think I'm with adam on this one
17:04:44 <tflink> -1 blocker, +1 nth
17:04:57 <tflink> there aren't enough languages affected by this to block @ beta
17:05:02 <jreznik_> -1 blocker, +1 nth
17:05:07 <akshayvyas> +1 nth
17:05:10 <dan408-> well
17:05:14 <dan408-> something else changed in 18
17:05:18 <dan408-> relating to this
17:05:25 <dan408-> not this specific bug
17:05:34 <cmurf> -1 blocker, +1 nth
17:05:36 <dan408-> but /etc/sysconfig/keyboard changed
17:06:02 <adamw> yeah, +1 nth
17:06:07 <dan408-> im thinking this getting fixed will affect that and vice versa
17:06:09 <dan408-> +1 nth
17:06:56 <dan408-> ok im off
17:06:57 <tflink> proposed #agreed 866730 - RejectedBlocker (beta), AcceptedNTH - This is a conditional criteria violation for a limited number of languages but was deemed to be not enough languages to block for beta. However, a well-tested fix would be considered past freeze
17:07:03 <akshayvyas> ack
17:07:07 <Viking-Ice> ack
17:07:10 <cmurf> ack
17:07:24 <adamw> ack
17:07:30 <jreznik> ack
17:07:42 <tflink> #agreed 866730 - RejectedBlocker (beta), AcceptedNTH - This is a conditional criteria violation for a limited number of languages but was deemed to be not enough languages to block for beta. However, a well-tested fix would be considered past freeze
17:07:50 <tflink> #topic (867071) NameError: global name 'anaconda' is not defined
17:07:50 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=867071
17:07:51 <tflink> #info Proposed Blocker, anaconda, VERIFIED
17:08:55 <tflink> I wonder if there's a patch missing from 18.17
17:09:09 <tflink> I've been hitting this pretty regularly, though
17:10:40 <adamw> does comment #18 suggest this regressed from 18.16 to 18.17?
17:10:41 <tflink> results in non-bootable system
17:10:49 <adamw> that's how it reads to me but i'm not sure i'm grokking it right
17:11:01 <tflink> yeah, that's how I'm reading it as well
17:11:50 <cmurf> so the part that violates is the part about bootloader, right
17:12:00 <cmurf> requirement 9
17:12:07 <adamw> well it results in a non-bootable system so that's clearly a blocker, but what triggers it?
17:12:23 <tflink> looks like a missing import or something
17:12:53 <adamw> sounds like this just happens with a straight-through install, so +1 blocker.
17:12:54 <tflink> this is more basic than not touching the bootloader - I hit it with a full install, autopart after deleting partitions
17:13:02 <adamw> and set back to ASSIGNED for 18.17.
17:13:10 <cmurf> exception installing bootloader
17:13:21 <cmurf> hmm
17:13:42 <tflink> proposed #agreed 867071 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data"
17:13:44 <cmurf> yeah +1 even though i'm not seeing exactly where the face plant occurs
17:13:48 <cmurf> ack
17:14:17 <jreznik> ack
17:14:56 <adamw> ack
17:15:00 <tflink> #agreed 867071 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data"
17:15:12 <tflink> #topic (865073) DependencyError: [u'1:totem-nautilus-3.6.0-1.fc18.x86_64 requires totem = 1:3.6.0-1.fc18']
17:15:15 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=865073
17:15:17 <tflink> #info Proposed Blocker, anaconda, NEW
17:15:22 <zodbot> Ticket notification - f18betanicetohave: [Bug 866730] invalid locales configured for some languages <https://bugzilla.redhat.com/show_bug.cgi?id=866730>
17:16:21 <tflink> it sounds like this might have been a comps problem
17:16:29 <tflink> supposedly it has been fixed
17:17:02 <cmurf> i don't see a criteria that applies
17:17:04 <adamw> in general stuff that only affects netinst is -1, but this may be special
17:17:30 <tflink> it affects netinstalls that were done using the "broken" repos and DVDs that were built during the same time period
17:17:59 <cmurf> i'm -1 blocking "graceful failure from broken repos"
17:18:11 <cmurf> sounds nice though
17:18:18 <adamw> tflink: not necessarily, because the DVDs are built from stable
17:18:23 <adamw> and net install is still using updates-testing, aiui
17:18:30 <adamw> so netinst will always hit stuff that DVDs don't
17:18:38 <tflink> adamw: I think that the smoke10 dvd hit this
17:18:59 <adamw> it looks like any time anyone hits any kind of depsolv error at the start of package install, it gets marked as a dupe of this bug
17:19:03 <tflink> which was built during the affected period
17:19:13 <adamw> so really this bug is for anaconda error handling, not for any specific package issue...
17:19:37 <adamw> i think any time we have an issue on the DVD the depcheck script should catch it and robatino will file it separately
17:19:43 <adamw> so basically i'm -1 :)
17:21:26 <adamw> anyone else?
17:21:33 <cmurf> i'm still -1
17:21:40 <tflink> proposed #agreed 865073 - RejectedBlocker - This only happens when there are dependency issues in the DVD or repos used for install. As such, specific issues would be caught elsewhere and this doesn't need to be a blocker for F18 beta
17:21:44 <cmurf> ack
17:22:35 <adamw> ack
17:22:58 <akshayvyas> ack
17:23:03 <tflink> #agreed 865073 - RejectedBlocker - This only happens when there are dependency issues in the DVD or repos used for install. As such, specific issues would be caught elsewhere and this doesn't need to be a blocker for F18 beta
17:23:09 <tflink> #topic (866101) redundancy selection for btrfs device results in raid0, not raid1
17:23:12 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=866101
17:23:15 <tflink> #info Proposed Blocker, anaconda, MODIFIED
17:24:41 <tflink> cmurf: if you're -1 blocker on this, why propose it?
17:24:53 <cmurf> peer review
17:25:15 <cmurf> the question is whether release criteria can be inferred to require btrfs raid1
17:25:30 <cmurf> btrfs raid0/raid1 are not md driver dependent
17:25:34 <tflink> yeah, I'm slightly -1 blocker on this since btrfs isn't the default fs or raid
17:26:00 <adamw> yeah, even though the criteria are still in flux, i'd be surprised if we wind up covering this
17:26:02 <adamw> esp. for beta
17:26:04 <cmurf> well btrfs default isn't really the question, the criteria say installation to software raid0 or 1 regardless of filesystem
17:26:21 <cmurf> so the issue here is the ambiguity
17:26:53 <tflink> true, btrfs raid wasn't an option when the criteria was originally written
17:27:22 <cmurf> on the one  hand i'm reluctant to infer btrfs raid0/1 for F18 beta, but eventually that WOULD be the case
17:27:23 <adamw> cmurf: strictly speaking, btrfs with redundancy is not RAID>
17:27:27 <adamw> it's btrfs with redundancy.
17:27:38 <cmurf> it's in effect raid1
17:27:42 <adamw> the criterion was written before btrfs really existed.
17:27:45 <cmurf> the flag used to create the volume is -d raid1
17:27:51 <adamw> no it's not, though. RAID is a specific technology, btrfs is another one.
17:28:09 <cmurf> :-) it's referred to as btrfs raid
17:28:09 <adamw> i have a problem with reading the criterion as applying to btrfs, since it wasn't written that way. it was written specifically about *RAID*.
17:28:11 <tflink> I think we're splitting hairs here
17:28:29 <Viking-Ice> adamw, agreed
17:28:35 <cmurf> RAID is equally vague, if you want to be specific is md raid vs btrfs raid
17:28:43 <tflink> RAID => redundant array of independant dist
17:28:45 <tflink> disks
17:28:58 <tflink> how is btrfs redundancy over multiple disks not RAID?
17:29:05 <cmurf> btrfs -d raid1 is RAID
17:29:06 <adamw> hmm.
17:29:13 <tflink> but I think that the criteria implicitly refer to mdraid
17:29:27 <tflink> so still -1 blocker for F18 beta
17:29:30 <cmurf> THAT's the question
17:29:33 <adamw> well no, the criteria refer to the things that were considered to be RAID when we wrote the criterion, really...
17:29:55 <adamw> dmraid, mdraid-created-by-the-kernel, mdraid-from-imsm, hardware raid controllers
17:29:57 <tflink> there were other software raid solutions at the time?
17:30:05 <adamw> it doesn't just say software raid, though, does it?
17:30:14 <tflink> yeah, I should have been more specific
17:30:15 <cmurf> software and hardware RAID
17:30:40 <tflink> btrfs redundancy isn't hw raid, so I was comparing it to the sw raid part of the criterion
17:30:46 <cmurf> software, hardware or BIOS RAID 0, 1, 5
17:31:02 <cmurf> that's what the criterion reads
17:31:11 <adamw> true. 'software RAID' at the time that was written clearly meant 'mdraid'.
17:31:20 <tflink> either way, I think that for F18, btrfs isn't software raid in the context of that criterion
17:31:24 <cmurf> ok so in that case i'm -1 blocker +1 nth
17:31:33 <cmurf> BUT it probably should be made more clear for final
17:31:54 <cmurf> it looks like btrfs raid0 and raid1 are intended to work even for beta
17:31:55 <adamw> yeah, -1/+1
17:32:07 <adamw> cmurf: right, have to feed that into the ongoing partitioning criteria debate. le sigh
17:32:35 <tflink> proposed #agreed 866101 - RejectedBlocker, AcceptedNTH - While not specifically stated, software raid as written in the criteria implies mdraid, not btrfs and thus, this isn't a blocker. However, a well tested fix would be considered past freeze.
17:32:42 <adamw> i think you're right and i was wrong, btw, RAID is a pretty vague term and it covers btrfs as much as anything.
17:32:49 <cmurf> so for f19 i'd say that btrfs should have the same raid expectation as md raid for alpha/beta/final
17:33:12 <adamw> ack
17:33:13 <tflink> I'd say once btrfs is the default, definitely
17:33:14 <cmurf> ack
17:33:17 <tflink> F19, maybe
17:33:19 <cmurf> has nothing to do with default
17:33:21 <cmurf> nothing at all
17:33:35 <adamw> i don't think you can talk about 'default' for anything that requires custom partitioning, can you?
17:33:38 <adamw> there isn't any clear 'default'
17:33:45 <cmurf> md raid is expected to work for XFS as rootfs
17:33:48 <adamw> there's just offered device types
17:33:49 <tflink> directly, no it doesn't. I just don't want to be blocking for stuff that isn't common - default fs implies more common
17:34:08 <adamw> anyhoo
17:34:15 <cmurf> tflink: using that logic you'd reject working md raid on ext3 as a blocker
17:34:18 <tflink> #agreed 866101 - RejectedBlocker, AcceptedNTH - While not specifically stated, software raid as written in the criteria implies mdraid, not btrfs and thus, this isn't a blocker. However, a well tested fix would be considered past freeze.
17:34:22 <cmurf> it's not about the file system default status
17:34:29 <tflink> let me be more specific, then
17:34:55 <tflink> at the moment, mdraid is more common than btrfs redundency
17:35:11 <tflink> anything other than btrfs uses mdraid for sw RAID
17:36:02 <cmurf> tflink: yes but btrfs raid levels are integrated, it's merely a flag that creates them so it's actually a LOT simpler than md raid.
17:36:03 <tflink> my thought processes is that until btrfs is more common (and maybe the default fs), that shouldn't be a release blocking issue
17:36:33 <tflink> anyhow, we're getting way off into the weeds here
17:36:38 <cmurf> fair enough
17:36:56 <tflink> #topic (867296) NameError: global name 'gtk_call_once' is not defined
17:36:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=867296
17:36:56 <tflink> #info Proposed Blocker, anaconda, MODIFIED
17:37:10 * tflink isn't trying to stop the discussion, just wants to get through more of the blockers
17:37:44 <adamw> no, i think you're right
17:37:50 <adamw> dan408: still around? how'd you hit this?
17:38:03 <Viking-Ice> I agree with tflink take on btrfs raid
17:38:39 <tflink> new feature for blocker app: flog people who propose blockers w/o criteria, affect, cause or potential workarounds and know better than to do it that way
17:38:53 <adamw> the cat-o-nine-tails button
17:38:55 <cmurf> tflinnk: +1000
17:39:05 * adamw is asking msivak
17:39:09 <cmurf> i have NO idea what this bug is about
17:39:13 <cmurf> no idea what triggers it
17:39:17 <cmurf> no idea why it's a blocker
17:39:25 <cmurf> Mr. Garrison gives it an F minus
17:39:33 <adamw> "File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/source.py", line 653, in _initialize"
17:39:35 <tflink> can he do that?
17:39:39 <adamw> happens if you go into the 'Installation Source' spoke, maybe?
17:39:39 <cmurf> haha
17:39:47 <tflink> yeah, that would be my guess
17:39:52 <adamw> anyone who has smokewhatever want to try it quickly?
17:40:07 <tflink> yeah, give me a sec
17:40:16 <cmurf> where are the smoke builds?
17:40:33 <tflink> http://dl.fedoraproject.org/pub/alt/qa/18/
17:40:39 <zodbot> Ticket notification - f18betanicetohave: [Bug 866101] redundancy selection for btrfs device results in raid0, not raid1 <https://bugzilla.redhat.com/show_bug.cgi?id=866101>
17:40:40 <tflink> smoke 10 has issues, so I didn't announce it
17:41:47 <tflink> seems to be fine on netinstall
17:41:52 <adamw> hm
17:41:54 <adamw> punt then
17:41:56 <tflink> dvd is still downloading
17:42:35 <cmurf> punt with flogging
17:42:42 <jreznik> punt, I'll ask marsik tmrw morning to comment it
17:42:43 * adamw primes the cat
17:43:12 <tflink> proposed #agreed 867296 - There is nowhere near enough information in this bug to figure out what happened, much less whether it's a blocker. Will re-visit when there is more information available
17:43:31 <cmurf> ack
17:43:37 <cmurf> +1 rather
17:43:38 <adamw> ack
17:43:43 <adamw> no, you got it right =)
17:43:50 <tflink> #agreed 867296 - There is nowhere near enough information in this bug to figure out what happened, much less whether it's a blocker. Will re-visit when there is more information available
17:43:58 <tflink> looks like we lost pretty much everyone else
17:44:04 <tflink> #topic (856362) KeyError: 'la-latin1'
17:44:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856362
17:44:04 <tflink> #info Proposed Blocker, anaconda, MODIFIED
17:44:09 <cmurf> i am so easily confused
17:44:33 <cmurf> this anaconda is ancient
17:44:59 <tflink> still in the same boat - no upgrade tool to test
17:44:59 <cmurf> comment 19??
17:45:08 <adamw> ayup
17:45:08 <cmurf> well the installer isn't going to do upgrades i thought
17:45:26 <tflink> this was originally preupgrade
17:45:42 <tflink> AFAIK, it has to do with data passed into anaconda via that ks that preupgrade used to generate
17:45:44 <cmurf> ok so existing beta release criteriosn 12 is in flux?
17:46:03 <adamw> no, it's already been adjusted
17:46:05 <tflink> we have no idea if it affects upgrades
17:46:07 <cmurf> oh i see 12 wording has changed, doesn't say the installer must do this upgrade
17:46:08 <adamw> note it doesn't refer to preupgrade specifically
17:46:10 <tflink> since we have no upgrade tool to test
17:46:12 <adamw> right.
17:46:21 <adamw> may as well just punt again
17:46:26 <adamw> looks like this will be closed by next week anyway
17:46:36 <cmurf> yeah punt
17:46:39 <tflink> it turns out that this is a more general anaconda bug that preupgrade happened to hit
17:47:25 <tflink> proposed #agreed 856362 - Since we still don't have an upgrade tool to test, there is no way to test whether this bug violates the F18 upgrade criterion. Will revisit once there is an upgrade tool to test
17:47:31 <adamw> yeah, we always knew that, but we decided we couldn't make it blocker or not-blocker just on the basis of the non-upgrade case.
17:47:33 <adamw> ack
17:47:37 <dan408-> back
17:47:51 <adamw> dan408: get ready to be flogged
17:47:59 <dan408-> flog me baby
17:48:19 <tflink> um ... any more ack/nak/patch?
17:48:31 * adamw puts on false mustache and says 'ack' in dodgy belgian accent
17:48:40 <tflink> #agreed 856362 - Since we still don't have an upgrade tool to test, there is no way to test whether this bug violates the F18 upgrade criterion. Will revisit once there is an upgrade tool to test
17:48:45 <adamw> haha.
17:48:47 <adamw> that wasn't meant to *work*.
17:49:00 <tflink> #topic (864981) BootLoaderError: bootloader install failed
17:49:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864981
17:49:00 <tflink> #info Proposed Blocker, grub2, NEW
17:49:01 <cmurf> ak
17:49:14 <tflink> eh, we've punted on that bug how many times now? I don't think there will be much resistance
17:49:52 <cmurf> i read this last night, early am
17:50:23 <cmurf> if grub can't do what it's asked to do because it's not capable or not a good idea, then i don't even see this as a bug
17:50:26 <cmurf> let alone blocker
17:50:58 <dan408-> tflink: time to kick onsides
17:51:28 <tflink> dan408-: ?
17:51:33 <cmurf> needmoreinfo on comment 20
17:51:34 <dan408-> joking
17:51:44 <cmurf> i'm -1 on this presently
17:51:49 <adamw> we still don't know _exactly_ what's going on here
17:51:55 <adamw> i'm leaning -1 too, but it'd be nice to be sure
17:52:20 <cmurf> best i can tell, and 20 suspects something else but also isn't sure, is that the target whole disk was formatted
17:52:20 <tflink> yeah, I'm slightly -1 since we've not seen any more reporters and it sounds like a strange disk setup
17:52:23 <cmurf> AFTER it was partitioned
17:52:28 <adamw> if this is actually a valid disk layout and grub has a bug, that's potentially a blocker.
17:52:32 <cmurf> so instead of the partition being formatted, the disk was
17:52:37 <Viking-Ice> -1 here
17:52:49 <tflink> reject, ask to repropose if there are more reporters or it turns out to be more severe
17:52:49 <cmurf> adamw: bingo
17:52:58 <cmurf> so the question is exactly how to reproduce this?
17:53:15 <adamw> i guess it'd help to have a dd of the partition table in question or something.
17:53:26 <cmurf> i'd like to see a dd of the first 4 sectors
17:53:28 <tflink> or a reproduction
17:53:35 <cmurf> or a reproduction
17:53:36 <adamw> or, hell, get msivak in a room with the offending disk.
17:53:38 <cmurf> :-D
17:53:41 <tflink> jan has been silent on this since reporting it
17:53:55 <adamw> so, -1 or punt?
17:53:59 <cmurf> i think someone inadvertently formatted sda instead of sda1
17:54:15 <tflink> I'd be OK with rejecting
17:54:17 <Viking-Ice> I'm with tflink here reject, ask to repropose if there are more reporters or it turns out to be more severe
17:54:17 <cmurf> -1
17:54:31 <cmurf> with the "but hey if we got it wrong give us more info"
17:55:00 <adamw> yeah, -1 with repropose option is fine
17:55:35 <tflink> proposed #agreed 864981 - RejectedBlocker - With the currently available information, this does not clearly hit any release criteria and seems to be an issue with a strange disk layout. If this turns out to be more common or more information becomes available, please re-propose as a blocker.
17:55:40 <cmurf> ack
17:55:57 <jreznik> ack
17:56:04 <adamw> ack
17:56:06 <tflink> #agreed 864981 - RejectedBlocker - With the currently available information, this does not clearly hit any release criteria and seems to be an issue with a strange disk layout. If this turns out to be more common or more information becomes available, please re-propose as a blocker.
17:56:08 <jreznik> and I add it to the list of people to poke tmw (jan)
17:56:13 <tflink> #topic (865009) GString mem alloc crashes after dbus op
17:56:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=865009
17:56:13 <tflink> #info Proposed Blocker, NetworkManager, ON_QA
17:57:35 <tflink> this seems not blocker to me
17:57:41 <tflink> unless I'm missing something
17:57:51 <cmurf> agreed
17:57:55 <cmurf> i'm not seeing what it blocks
17:58:01 <cmurf> networking working isn't in release requirements
17:58:29 <tflink> ah, one of the dupes was during install
17:58:37 <Viking-Ice> well any dbus error got me on the nerves these days since it has become such integrated part of the CoreOS
17:58:37 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=866434
17:58:54 <adamw> er
17:58:56 <adamw> this is probably valid
17:59:10 <tflink> eh, 1 in 20 installs?
17:59:10 * jreznik heard it affect also installation
17:59:12 <adamw> note that https://bugzilla.redhat.com/show_bug.cgi?id=866434 was proposed as a blocker then closed as a dupe of this
17:59:27 <adamw> sorry, bad choice of wording. but it does affect installation, it's not just a post-install NM bug.
17:59:37 <cmurf> oops
17:59:39 <tflink> not sure that 1 in 20 is enough to block beta for
17:59:43 <adamw> i'm fine if we go -1 on the basis it doesn't hit many installs, just want to make sure we understand it's an install-time bug too.
18:00:12 <adamw> jirka got 1 in 20, but kamil got 2 in 5
18:00:17 <tflink> yeah, I'm -1 on the basis that it doesn't affect enough installs to block beta for
18:00:25 <Viking-Ice> agreed
18:00:25 <cmurf> -1
18:00:41 <adamw> as long as we document it and say 'just try again' i'm probably ok with -1. esp as it seems to be i686 only.
18:00:49 <adamw> +1 nth of course.
18:01:07 <jreznik> and it gets into beta as we are not frozen (not counting it for blocker decision), -1 blocker, +1 nth
18:01:37 * tflink is borderline nth
18:01:54 <tflink> not sure that taking NM builds post-freeze is the wiset thing ever
18:02:19 <cmurf> should know in about 30 minutes if we're at freeze yeah?
18:02:44 <adamw> we already decided not to, i think.
18:02:53 <adamw> tflink: i think the benefit's probably worth it.
18:02:57 <tflink> proposed #agreed 865009 - RejectedBlocker, AcceptedNTH - While this is a valid install issue, the available information makes it seem like not enough systems would be affected to justify blocking beta release.
18:03:01 <cmurf> ack
18:03:08 <adamw> ack
18:03:12 <adamw> er
18:03:16 <adamw> patch to 'not enough installs'
18:03:22 <Viking-Ice> ack
18:03:30 <tflink> proposed #agreed 865009 - RejectedBlocker, AcceptedNTH - While this is a valid install issue, the available information makes it seem like not enough installs would be affected to justify blocking beta release.
18:03:34 <cmurf> ack on patch
18:04:03 <tflink> #agreed 865009 - RejectedBlocker, AcceptedNTH - While this is a valid install issue, the available information makes it seem like not enough installs would be affected to justify blocking beta release.
18:04:20 <tflink> #topic (859855) AttributeError: 'NoneType' object has no attribute 'name'
18:04:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859855
18:04:20 <tflink> #info Proposed Blocker, preupgrade, NEW
18:04:25 <cmurf> oh i see, i'm in a different time zone, that meeting was an hour ago
18:04:48 <tflink> wait, this is a preupgrade issue - any objections to skipping?
18:04:56 <cmurf> was just gonna say
18:05:12 <cmurf> this is a -1
18:05:49 <tflink> #undo
18:05:49 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x6044bb90>
18:05:50 <tflink> #undo
18:05:50 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2b89e090>
18:05:51 <tflink> #undo
18:05:51 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2bd7f450>
18:06:05 <tflink> #topic (866441) TypeError: 'NoneType' object is not iterable
18:06:05 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=866441
18:06:05 <tflink> #info Proposed Blocker, python-meh, POST
18:06:07 <cmurf> so is preupgrade going to continue to exist and just depend on the unicorn upgrade tool?
18:06:35 <tflink> cmurf: I think that preupgrade is going to be taken out to the shed, if it hasn't already
18:06:42 <cmurf> haha
18:06:44 <dan408-> remember when yum could do all this stuff?
18:07:04 <Viking-Ice> is this fixed?
18:07:19 <adamw> cmurf: the new unicorn replaces preupgrade.
18:07:24 <Viking-Ice> "This fixes the issue, a GUI dialog appears with exception with no stack. I also verified that exceptions with stack did not regress, they display as usual."
18:07:31 <dan408-> wait you guys are serious? it's called unicorn?
18:07:36 <cmurf> ROFL
18:07:49 <cmurf> yes! and it's upgraded systems are called unicorn cookies
18:07:50 <Viking-Ice> +1 nth
18:07:56 <cmurf> its rather
18:08:05 <tflink> yeah, it sounds like it's been verified
18:08:06 <jlk> the working title was "FedUp"
18:08:14 <adamw> dan408: no, that's just me being silly.
18:08:14 <dan408-> cmurf: part of me really wants to believe you
18:08:20 <adamw> unless jesse likes the idea.
18:08:23 <Viking-Ice> I dont think this issue constitutes as blocker
18:08:29 <dan408-> adamw: +1 nth
18:08:30 <tflink> cmurf: I like the idea of unicorn chips better :)
18:08:40 <cmurf> dan408: hey here have been sightings!
18:08:41 <adamw> so let's see if we all have the same understanding of this issue
18:09:08 <Viking-Ice> people focus at task at hand worry about that rainbow upgrader later
18:09:09 <dan408-> the new unicorn will replace preupgrade and yum
18:09:11 <dan408-> yes i got it
18:09:13 <adamw> aiui, some exception with no stack trace can happen at the start of install somehow, and if that happens, reporting of any other exception is broken
18:09:29 <cmurf> not good
18:09:43 <tflink> yeah, that sounds about right
18:09:50 <adamw> so this is a conditional violation of "The installer must be able to report failures to Bugzilla and local disk, with appropriate information included", the condition being 'this mysterious no-stack exception happens'
18:10:09 <dan408-> adamw: it's happening because of broken deps isnt it?
18:10:18 <adamw> i don't see anything about deps here.
18:10:20 <dan408-> k
18:10:26 <dan408-> that's the other bug
18:10:35 <adamw> i'm not sure anyone's figured out what's causing the mystery exception
18:10:50 <dan408-> anaconda...
18:10:55 <tflink> I'm probably +1 blocker on this
18:11:00 <dan408-> +1
18:11:05 <tflink> it impedes triage of issues
18:11:10 <cmurf> +1 blocker although it appears fixed
18:11:40 <tflink> but we come back to the question of: if this was the last bug left at go/no-go, would we slip because of this bug alone?
18:11:41 <adamw> i'll go with +1, though i feel like this is the kind of bug that would get fudged if today was go/no-go and it was the last blocker :)
18:11:45 <adamw> right.
18:12:02 <tflink> as much as I would like to say yes, we would. I suspect that adam's right
18:12:04 <dan408-> i think we should focus our efforts on anaconda
18:12:11 <dan408-> and prioritize the bugs
18:12:34 <tflink> so -1 blocker, +1 nth?
18:12:43 <Viking-Ice> +1 +1nth
18:12:52 <Viking-Ice> mean -1 blocker +1 nth
18:12:55 <dan408-> -
18:12:57 <dan408-> -1
18:12:59 <dan408-> blocker
18:13:28 <adamw> okay, go with -1/+1 then?
18:13:42 <cmurf> -1 +1
18:13:47 <dan408-> 0
18:14:16 <zodbot> Ticket notification - f18betanicetohave: [Bug 865009] GString mem alloc crashes after dbus op <https://bugzilla.redhat.com/show_bug.cgi?id=865009>
18:14:31 <tflink> proposed #agreed 866441 - RejectedBlocker (beta), AcceptedNTH - While this is a conditional violation of the following F18 alpha criterion, it wasn't deemed common enough to justify blocking beta for it but a tested fix would be considered past freeze for F18 beta. "The installer must be able to report failures to Bugzilla and local disk, with appropriate information included"
18:14:38 <adamw> ack
18:14:44 <dan408-> ack
18:14:49 <Viking-Ice> ack
18:15:17 <cmurf> ack
18:15:20 <tflink> #agreed 866441 - RejectedBlocker (beta), AcceptedNTH - While this is a conditional violation of the following F18 alpha criterion, it wasn't deemed common enough to justify blocking beta for it but a tested fix would be considered past freeze for F18 beta. "The installer must be able to report failures to Bugzilla and local disk, with appropriate information included"
18:15:40 <tflink> is it just me or do most of these title look the same
18:16:40 * tflink is skipping the other upgrade bug
18:16:49 <tflink> topic (864204) AttributeError: 'YumConf' object has no attribute '_repos_persistdir'
18:16:52 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864204
18:16:55 <tflink> #info Proposed Blocker, yum, NEW
18:17:06 <cmurf> i can do one more then i've got to go
18:17:06 <dan408-> theres a bunch of anaconda attribute bugs
18:17:14 <dan408-> can we just lump themp together?
18:17:17 <dan408-> them*
18:17:36 <zodbot> Ticket notification - f18finalnicetohave: [Bug 863722] Fedora 18 Beta Xfce tracker <https://bugzilla.redhat.com/show_bug.cgi?id=863722>
18:18:08 <cmurf> weird
18:18:19 <tflink> not sure what to say about this one
18:18:20 <cmurf> this is happening only with vms?
18:18:25 <tflink> sounds like
18:18:45 <cmurf> so this is an old version of anaconda
18:18:46 <tflink> I wonder how many of these timing bugs we're going to get once F18 is released
18:18:48 <cmurf> and it's btrfs
18:18:52 <cmurf> and i can't tell if the host is btrfs
18:18:57 <cmurf> so not enough info
18:19:12 <cmurf> there have abeen a LOT of anaconda implosions on existing btrfs volumes
18:19:14 <adamw> he's talking about names of guest machines in his office, i think
18:19:27 <adamw> BTRFS-1, BTRFS-2, BTRFS-3 are just VM names
18:19:27 <tflink> I'm leaning towards -1 blocker, re-propose if it turns out to be more sever
18:19:28 <cmurf> adamw: agreed, i'm assuming they are btrfs guests
18:19:46 <adamw> i don't see how the filesystem used in the test machine affects this, since it's not to do with partitioning
18:19:57 <adamw> so it's probably some other attribute of the machines, but who knows
18:20:06 <adamw> i still haven't seen this in any testing, has anyone else>?
18:20:26 <tflink> I wonder what he's using for a hypervisor
18:20:30 <cmurf> i have seen anaconda crash just because the file system was btrfs
18:20:33 <tflink> no, I haven't seen it
18:20:33 <adamw> KVM
18:20:38 <adamw> since he refers to using spice/qxl
18:20:50 <tflink> can
18:20:57 <tflink> can't you use spice/qxl with xen?
18:21:04 <cmurf> why is the component yum?
18:21:04 <adamw> oh. i didn't _think_ so, but maybe
18:21:17 <adamw> the thing that crashes is part of yum, i think.
18:21:43 <adamw> so i'm leaning -1 just on the basis no-one else is seeing this, i guess.
18:21:52 <tflink> yeah, same here
18:21:57 <cmurf> well, the way it's filed, who would see this?
18:22:10 <cmurf> -1, and repropose with a how to to reproduce recipe
18:22:46 <zodbot> Ticket notification - f18betanicetohave: [Bug 866441] TypeError: 'NoneType' object is not iterable <https://bugzilla.redhat.com/show_bug.cgi?id=866441>
18:23:12 <tflink> proposed #agreed 866441 - RejectedBlocker - As there is still no clear cause or reproducer for this and there have been no additional reports, this is rejected as a blocker for F18 beta. If it turns out to be more common or sever than currently understood, please repropose as a blocker with details on how to reproduce.
18:23:23 <cmurf> ack
18:23:38 <adamw> cmurf: it's a libreport-filed traceback
18:23:45 <adamw> cmurf: so if anyone else hit it and reported it it should show up as a dupe
18:23:52 <adamw> no-one's been added to the CC field
18:23:53 <cmurf> got it
18:24:45 <adamw> ack
18:24:49 <tflink> #agreed 866441 - RejectedBlocker - As there is still no clear cause or reproducer for this and there have been no additional reports, this is rejected as a blocker for F18 beta. If it turns out to be more common or sever than currently understood, please repropose as a blocker with details on how to reproduce.
18:25:01 <tflink> OK, that would be all of the proposed blockers on my list
18:25:09 <Viking-Ice> ok later
18:25:29 <tflink> do we want to get through the accepted blockers today or put it off til tomorrow
18:25:59 <adamw> there aren't many, are there?
18:26:10 <adamw> we could skip the ones that are verified/on_qa/modified
18:26:13 <tflink> oh, I was counting the VERIFIED ones
18:27:04 <adamw> don't see much point in going through those
18:27:46 <cmurf> i gotta go
18:27:50 <tflink> I count 12 not in ON_QA or VERIFIED
18:27:53 <adamw> thanks cmurf
18:27:57 <cmurf> welcome
18:27:59 <adamw> how many of those are MODIFIED?
18:27:59 <cmurf> cya
18:28:00 <tflink> cmurf: thanks for helping out
18:28:03 <cmurf> np
18:28:04 <adamw> modified ones are just 'wait for 18.18'
18:28:21 <tflink> 4 and one verified that i miscounted
18:28:24 <dan408-> you just wait
18:28:43 <dan408-> 18.18 is going to be awesome
18:28:54 <tflink> eh, lets just get it done
18:28:56 <adamw> seems to me like it really only makes sense to go through NEW/ASSIGNED accepted blockers, in general
18:29:11 <tflink> NEW/ASSIGNED/POST
18:29:18 <adamw> possibly POST, i guess.
18:29:23 <tflink> since things can get stuck in post
18:29:29 <tflink> #topic (863348) ValueError: Cannot remove non-leaf device 'vda2'
18:29:29 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=863348
18:29:29 <tflink> #info Accepted Blocker, anaconda, POST
18:29:36 <tflink> brb, call of nature
18:29:44 <adamw> i asked about this one last night, sounds like it still needs review.
18:29:54 <adamw> anaconda team is aware we really want it fixed, though.
18:34:05 <tflink> #info the patch for this bug still needs review
18:34:34 <tflink> #info anaconda team is aware of the patch, is working on it
18:34:47 <tflink> #topic (864360) gpt isn't automatically created on UEFI system
18:34:47 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864360
18:34:47 <tflink> #info Accepted Blocker, anaconda, ASSIGNED
18:35:10 <tflink> no movement since last week
18:35:18 <adamw> yeah, looks like we need a poke here
18:35:27 <tflink> #info no movement on this bug since last week
18:35:28 <adamw> i don't see any action for anyone but anaconda team, the bug seems clearly understood
18:36:23 <adamw> i'll post a poke
18:36:39 <tflink> #info will poke devs on status of fix
18:36:49 <tflink> #topic (866115) ValueError: ('invalid size specification', '0 b')
18:36:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=866115
18:36:49 <tflink> #info Accepted Blocker, anaconda, POST
18:37:16 <adamw> this is like 863348, a greatest hit that needs reviewing quick
18:37:45 <tflink> #info the update from c#22 is reported to fix this, still waiting patch review
18:38:08 <tflink> #info will poke devs in bug
18:38:18 <tflink> #topic (862613) ValueError: cannot initialize a disk that has partitions
18:38:19 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=862613
18:38:19 <tflink> #info Accepted Blocker, anaconda, NEW
18:39:27 <tflink> #info this might be the same as 866895, another bug is preventing reporter from re-testing
18:40:18 <tflink> #info reporter will retest with TC5
18:40:30 <tflink> #topic (864120) LUKS encryption option has no effect
18:40:30 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864120
18:40:30 <tflink> #info Accepted Blocker, anaconda, MODIFIED
18:41:21 <tflink> #info it's not clear what the exact problem is here - this may end up being not a bug
18:41:35 <tflink> #info more testing is needed to determine exactly what is going on here
18:42:01 <adamw> i think we should probably close off this bug and ask kparal to file a new one
18:42:14 <tflink> ok, that works
18:42:19 <tflink> #undo
18:42:19 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x25e36a90>
18:42:21 <tflink> #undo
18:42:21 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x28d72a10>
18:42:40 <tflink> #info it appears as if the original issue has been fixed and another issue has been added on to it
18:43:12 <tflink> #info move bug to CLOSED and ask new reporter to file another bug with the new issue
18:44:20 <tflink> #topic (864771) KeyError: PartitionDevice instance (0x7f0f28b016d0)
18:44:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864771
18:44:20 <tflink> #info Accepted Blocker, anaconda, MODIFIED
18:45:12 <tflink> #info a fix for this bug is available but needs testing before it is moved to VERIFIED
18:45:21 <tflink> #topic (863451) AttributeError: 'DeviceFormat' object has no attribute 'peStart'
18:45:24 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=863451
18:45:27 <tflink> #info Accepted Blocker, anaconda, NEW
18:46:04 <adamw> seems like this needs some anaconda team attention
18:46:15 <tflink> #info no movement on this bug in the last week
18:46:30 <tflink> #info will poke devs in bug for status update
18:47:08 <tflink> #topic (855526) f18a tc6 anaconda cannot connect to a protected wireless network
18:47:11 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855526
18:47:14 <tflink> #info Accepted Blocker, anaconda, MODIFIED
18:47:51 <tflink> #info a fix is available for this bug
18:48:02 <tflink> #info needs testing before it is moved to VERIFIED
18:48:21 <tflink> shouldn't this be ON_QA?
18:48:34 <adamw> sorry, sec
18:48:37 <tflink> nvm, it is
18:48:45 <tflink> list was generated before push to testing
18:49:09 <tflink> #topic (853877) anaconda ignores keyboard settings
18:49:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=853877
18:49:09 <tflink> #info Accepted Blocker, anaconda, MODIFIED
18:49:47 <adamw> i thought we were skipping modified
18:49:49 <tflink> #info no movement since 2012-10-05, patch still waiting for review
18:50:07 <adamw> hum
18:50:09 <tflink> yeah, I forgot and we're almost done
18:50:11 <adamw> this was set to MODIFIED on 10-12
18:50:17 <adamw> which should indicate that it was committed
18:50:21 <adamw> but no fixed_in_version was set
18:50:24 <adamw> we should probably clarify that
18:50:35 <tflink> #undo
18:50:35 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x6044b150>
18:50:56 <tflink> eh, it's in POST, not MODIFIED
18:51:09 <tflink> nvm, I misread that
18:51:14 <adamw> no, it's in MODIFIED. :)
18:51:34 <tflink> #info this was moved to MODIFIED on 2012-10-12 but no fixed_in_version was set
18:52:06 <tflink> #info clarify with devs on whether the fix has been pushed and if there is a build available to test
18:52:19 <tflink> #topic (864765) mkfs.btrfs SIGABRT at OS install time
18:52:19 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864765
18:52:19 <tflink> #info Accepted Blocker, btrfs-progs, NEW
18:52:43 <adamw> hey, it's a bug that's not in anaconda, i feel scared and unsure
18:52:55 <dan408-> LOL
18:52:58 <adamw> looks like there's a scratch build for testing here
18:53:17 <tflink> #info a new build of btrfs-progs is available for testing
18:53:24 <adamw> i think cmurf would need a bleed build with this btrfs-progs installed to test, right?
18:53:31 <tflink> yep
18:53:52 <tflink> #action tflink to pull in the brtfs-progs scratch build into the next smoketest iso
18:54:09 <tflink> #topic (864058) anaconda main menu not visible in F18 Beta TC2 KDE Live
18:54:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864058
18:54:09 <tflink> #info Accepted Blocker, gtk3, NEW
18:54:51 <tflink> again with the push after list generation
18:55:16 <tflink> #info a fix is available, needs testing with KDE livecd
18:55:45 <tflink> probably wait until TC5 for this one
18:55:54 <tflink> or I could just spin up a kde live when I do smoke11
18:56:35 <tflink> either way
18:56:48 <adamw> right, looks under control.
18:56:49 <tflink> anywho, that's all of the accepted blockers and there are no proposed NTH right now
18:57:02 <tflink> unless you count the tracking bug that I need to remove
18:57:43 <adamw> i can do a KDE test image for that bug, easy enough to do.
18:57:55 <tflink> ok, that works, too
18:58:30 <tflink> so ...
18:58:35 <tflink> #topic Open Floor
18:58:43 <tflink> Anything else that should be brought up?
18:59:49 * tflink assumes not
19:00:17 <tflink> #info The next F18 beta blocker review will be 2012-10-24 @ 16:00 UTC
19:00:27 <adamw> yay, we actually didn't need two meetings this week!
19:00:35 * tflink sets the fuse for [0,5] minutes
19:00:39 <tflink> progress!
19:00:45 <tflink> and we're just at 3 hours, too
19:01:27 * tflink will send out minutes shortly
19:01:33 <tflink> Thanks for coming everyone!
19:01:35 <tflink> #endmeeting