16:00:04 <tflink> #startmeeting f19beta-blocker-review-4
16:00:04 <zodbot> Meeting started Wed May  8 16:00:04 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:04 <tflink> #meetingname f19beta-blocker-review-4
16:00:04 <tflink> #topic Roll Call
16:00:04 <zodbot> The meeting name has been set to 'f19beta-blocker-review-4'
16:00:14 <tflink> Wheee!!!!!
16:00:37 <tflink> Who all has sufficiently prepared themselves for some blocker review excitement?
16:01:08 * adamw puts on the Fun Suit
16:01:12 <Viking-Ice> let's hold a looonnnng meeeting like we did last release cycle
16:01:33 * Viking-Ice prepares for 4+ hours....
16:01:40 <tflink> let's .... not do that
16:01:49 * jreznik is here but from shitty coach internet on the way back to brno from my parents :)))
16:02:05 <jreznik> Viking-Ice: my bus arrives in half hour :D
16:02:42 <Viking-Ice> dam those coaches stealing all the internet ;)
16:03:07 <Viking-Ice> kevin costner should make a movie about that
16:03:16 <Viking-Ice> call it bitman
16:04:50 * tflink hopes for one more person, will start shortly otherwise
16:04:57 * brunowolff is here, but not sufficiently prepared
16:05:37 <Viking-Ice> brunowolff, what involves not being sufficiently prepared?
16:06:17 <tflink> Viking-Ice: not sufficiently prepared for the excitement, I imagine
16:06:34 <tflink> let's get this party started with some boilerplate, then
16:06:45 <tflink> #topic Introduction
16:06:52 <tflink> Why are we here?
16:06:52 <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:06:59 <tflink> #info We'll be following the process outlined at:
16:06:59 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:06 <tflink> #info The bugs up for review today are available at:
16:07:06 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:13 <tflink> #info The criteria for release blocking bugs can be found at:
16:07:14 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria
16:07:16 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
16:07:20 <tflink> #info Up for review today, we have:
16:07:26 <tflink> #info 7 Proposed Blockers
16:07:27 <tflink> #info 9 Accepted Blockers
16:07:27 <tflink> #info 4 Proposed Freeze Exceptions
16:07:27 <tflink> #info 3 Accepted Freeze Exceptions
16:07:43 <tflink> if there are no objections, I'll get started on the proposed blockers
16:07:57 <Viking-Ice> uhh a series of Anaconda blockers sounds familiar....
16:08:18 <tflink> #topic (959688) unrecoverable error when switching from BTRFS to LVM in manual partitioning
16:08:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=959688
16:08:24 <tflink> #info Proposed Blocker, anaconda, NEW
16:09:26 <Viking-Ice> -1/-1
16:10:14 <Viking-Ice> now that we have had feed back from adam it's clear that you literally have to go out of your way to trigger that one
16:10:20 <tflink> yeah, not sure about the blockery-ness of this one
16:10:46 <tflink> crap, looking at the wrong bug
16:10:52 <adamw> Viking-Ice: well if you hit the exact path that triggers it it's fairly bad, but it is a very precise path and there is a workaround
16:11:12 <adamw> so probably -1
16:11:15 <Viking-Ice> the workaround being doing it right from start ;)
16:11:26 <adamw> well, or going via 'standard partition
16:11:42 * jreznik_ is trying to open the bug to re-read but...
16:11:59 <Viking-Ice> adamw, anaconda did not hard crash did it
16:12:35 <Viking-Ice> mean the users can workaround it without having to reboot
16:12:41 <jreznik_> ok, got it, thanks adamw for the comment
16:12:55 <tflink> yeah, but that workaround is not really obvious
16:13:02 <tflink> at the same time, not sure it's a blocker
16:13:33 <jreznik_> tflink: common bugs... I'm leaning more to not a blocker, it's not very common operation I'd say
16:14:17 <tflink> not for beta, anyways
16:14:32 <Viking-Ice> that's -4 to a blocker let's move to the next...
16:14:58 <adamw> Viking-Ice: no
16:15:12 <adamw> Viking-Ice: er, no it didn't crash, yes you can figure out the workarounmd
16:15:32 <Viking-Ice> ah I took it as no to not being a blocker
16:15:38 <adamw> sorry :)
16:16:53 <tflink> proposed #agreed 959688 - RejectedBlocker - While nasty, this doesn't hit any beta release criteria and there are workarounds that don't require a reboot (even if they aren't obvious). Document as CommonBugs but rejected as a blocker for F19 beta
16:16:56 * adamw wonders if tflink has fallen down a deep, dark well
16:16:57 <adamw> ah, there he is
16:17:02 <adamw> ack
16:17:06 <brunowolff> ack
16:17:28 <Viking-Ice> ack
16:17:30 <tflink> #agreed 959688 - RejectedBlocker - While nasty, this doesn't hit any beta release criteria and there are workarounds that don't require a reboot (even if they aren't obvious). Document as CommonBugs but rejected as a blocker for F19 beta
16:17:45 <tflink> since I forgot before, any volunteers for secretary?
16:17:50 <tflink> #chair adamw
16:17:50 <zodbot> Current chairs: adamw tflink
16:18:01 <adamw> sure
16:18:08 <tflink> adamw: thanks
16:18:18 <tflink> #topic (960254) multiple disks, can't select specific disk for root
16:18:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=960254
16:18:24 <tflink> #info Proposed Blocker, anaconda, NEW
16:18:40 * adamw gets out his essay-readin' glasses
16:19:49 <adamw> so, yeah, this is confusing
16:19:50 * adamw grabs a VM
16:20:20 <tflink> it sounds like user error?
16:20:50 <adamw> if i had to guess i'd say that chris tested it very quickly, saw the greyed-out button and assumed it wouldn't possibly work
16:21:07 <adamw> reartes found that you could work around the greyed-out button and then commenced on some odyssey that's barely comprehensible
16:21:23 <adamw> i'm just trying it myself, seems simpler
16:22:18 <adamw> okay, so yeah, ignoring reartes' huge screed, the above basically holds true
16:22:54 <adamw> if I just have two disks in the machine, and create a mount point, then use the dialog to say it can only live on vdb and hit Select, then the Name field still reads vda1
16:23:09 <adamw> but if I touch the Label field (say enter 'a' then delete it) and hit Update Settings, it updates to vdb1
16:23:32 <adamw> i'm not sure if that's just a display bug, or whether the partition really isn't set to vdb until you hit Update Settings
16:23:36 <tflink> so it sounds like it is working in the backend, just not quite updating the display
16:23:39 <adamw> i could test that, but it'd take slightly longer
16:23:44 <adamw> not sure.
16:24:07 <adamw> i'll test it, up to you guys whether you want to wait
16:24:12 <Viking-Ice> would you say people with 2 or more disks are likely to encounter this bug
16:24:32 <tflink> would it be a blocker either way?
16:25:11 <Viking-Ice> I'm leaning towards blocker but would be persuaded to -1 +1 FE
16:25:28 <brunowolff> This doesn't seem like a blocker, since you can still do what you want.
16:25:37 <adamw> i'm almost sure it's just visual
16:25:48 <adamw> just flipping down to the next partition in the list and flipping back 'updates' it
16:25:48 <Viking-Ice> which makes it confusing
16:26:13 <adamw> Viking-Ice: well it's not just having two disks, it's having two disks and wanting to specify which one of the two your partitions wind up on
16:26:14 <brunowolff> It is definitely confusing, but I am not sure that rates to being a blocker in this case.
16:26:21 <adamw> but i agree it's a bit confusing, yeah
16:26:33 <adamw> i might buy it as a final blocker, but for beta? meh.
16:26:39 <Viking-Ice> adamw, which breaks the custom partitioning criteria
16:26:58 * jreznik_ has just arrived to brno, so time to disconnect :( and -1/+1 for this one as far as I understand it
16:27:21 <Viking-Ice> yeah it's not broken enough to warrant blocking the release so I'm -1/+1
16:27:36 <adamw> Viking-Ice: which one? afaics we don't cover the 'assign partition to disk' function in the criteria at all (which admittedly is an oversight)
16:27:37 <tflink> do we want to re-propose as final blocker?
16:27:41 <adamw> that sounds prudent
16:28:53 <tflink> proposed #agreed 960254 - RejectedBlocker (beta) - While this is confusing, it does not prevent install and does not violate any of the beta release criterion. Rejected as a blocker for F19 beta but re-proposed as a F19 final blocker and mark CommonBugs
16:29:18 <Viking-Ice> tflink, how did you count those vote
16:29:29 <Viking-Ice> or are you just setting the tone like that?
16:30:01 <tflink> Viking-Ice: doing multiple things at the same time, if you think I missed something, just say it
16:30:27 <brunowolff> ack
16:30:34 <tflink> are you referring to the lack of a accepted FE?
16:31:54 <adamw> ack
16:32:27 <adamw> Viking-Ice: i counted three -1s - you, me and jreznik
16:32:38 * tflink waits for viking to clarify his apparent nak
16:32:42 * brunowolff is -1 blocker
16:32:59 <adamw> patch for AcceptedFreezeException would be fine by me
16:33:05 <tflink> proposed #agreed 960254 - RejectedBlocker (beta) AcceptedFreezeException - While this is confusing, it does not prevent install and does not violate any of the beta release criterion. Rejected as a blocker for F19 beta but re-proposed as a F19 final blocker and mark CommonBugs
16:33:12 <brunowolff> ack
16:34:35 <adamw> ack
16:36:03 <tflink> #agreed 960254 - RejectedBlocker (beta), AcceptedFreezeException - While this is confusing, it does not prevent install and does not violate any of the beta release criterion. Rejected as a blocker for F19 beta but re-proposed as a F19 final blocker and mark CommonBugs
16:36:28 <tflink> I guess I can go back and change it if there end up being _specific_ objections
16:36:39 <tflink> #topic (960837) Regression to F14 Behavior concerning non-ascii Passwords
16:36:43 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=960837
16:36:45 <tflink> #info Proposed Blocker, anaconda, NEW
16:37:42 <adamw> -1 blocker, just nowhere near.
16:37:49 <Viking-Ice> tflink, yes sorry ( got stuck in ibm ips discussion ) I was refering to the lack of FE
16:38:17 <tflink> Viking-Ice: the #agreed is OK then?
16:38:19 <adamw> Viking-Ice: so it's good now? i set it as acceptedfe in the secretary
16:38:22 <Viking-Ice> tflink, yeah
16:39:05 <Viking-Ice> -1/-1
16:39:24 <tflink> yeah, this is odd but -1/-1
16:40:14 <adamw> count my -1 as -1/-1 :)
16:40:48 <tflink> proposed #agreed 960837 - RejectedBlocker, RejectedFreezeException - This does not hit any F19 release criteria and thus, does not qualify as a release blocking bug for F19 beta
16:40:58 <adamw> ack
16:41:12 <quup> uh
16:41:21 <quup> how will people with cyrillic/asian keyboards make a passowrd?
16:41:25 <Viking-Ice> ack
16:41:43 <adamw> quup: using the ASCII input they always have to use for usernames anyway?
16:41:51 <quup> adamw: I guess so
16:42:21 <adamw> all layouts which cannot input ASCII are set up with a layout which can input ASCII as an alternative, by convention.
16:42:40 <tflink> wait a second, he has non-ascii in the username, too
16:42:42 <adamw> it's (still) basically impractical to use a computer without being able to input ascii.
16:43:02 * tflink wonders if the error message is just slightly off
16:43:16 <adamw> who knows. i don't care, it's still not a blocker. :P
16:43:20 <tflink> true
16:43:34 <tflink> #agreed 960837 - RejectedBlocker, RejectedFreezeException - This does not hit any F19 release criteria and thus, does not qualify as a release blocking bug for F19 beta
16:43:53 <Viking-Ice> if people would have been bitten by this we would have know by know we are 5/6 releases after f13/f14
16:43:53 <brunowolff> ack
16:43:54 <Viking-Ice> ack
16:44:28 <tflink> #topic (947285) grub finds no bootable image after save image to disk from Fedora-19 i686 live iso
16:44:30 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=947285
16:44:33 <tflink> #info Proposed Blocker, anaconda, NEW
16:45:18 <Viking-Ice> punt and wait for a response
16:45:35 <adamw> -1 or punt, yeah
16:45:53 <tflink> yeah, sounds like it may not be an issue anymore
16:46:06 <adamw> the initial report is somewhat bizarre anyway
16:46:16 <adamw> i've never been able to figure out what he meant by "save to hard drive"
16:46:20 <adamw> *what* did he save to hard drive?
16:46:20 <Viking-Ice> I say we just -1 it and be done with it unless something crops up
16:46:30 <Viking-Ice> ( then we revisit )
16:46:34 <adamw> i'd be fine with that
16:46:48 <adamw> we have enough tests of installs from USB stick that worked
16:47:19 <Viking-Ice> I had no issue with mine which I dd ( granted it was 64bit )
16:47:35 <adamw> any other votes?
16:47:48 <tflink> proposed #agreed 947285 - RejectedBlocker - Recent test results indicate that this is no longer an issue and thus, is not a blocker. If it turns out that the issue still exists, ask reporter to clarify and repropose as blocker.
16:47:55 <Viking-Ice> ack
16:48:17 <adamw> i'll ack that
16:48:28 <brunowolff> ack
16:48:47 <tflink> #agreed 947285 - RejectedBlocker - Recent test results indicate that this is no longer an issue and thus, is not a blocker. If it turns out that the issue still exists, ask reporter to clarify and repropose as blocker.
16:48:55 <tflink> #topic (960262) installer will not launch with valid IP but no internet connection
16:48:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=960262
16:49:01 <tflink> #info Proposed Blocker, anaconda, NEW
16:49:37 <Viking-Ice> that's weird
16:49:50 <tflink> by internet access, does he mean local-only network access or that the network connection is/was severed?
16:50:07 <Viking-Ice> local-only network access as I understand it
16:50:08 <tflink> nvm
16:50:23 <adamw> yeah, weird bug
16:50:26 <tflink> he has vb set to bridged networking
16:50:38 <tflink> if it's NAT or no-networking, it works fine
16:50:49 <adamw> the error is an odd one too, nothing apparently to do with networking
16:51:03 <adamw> so this is obviously a judgement call on the 'showstopper' criterion...
16:51:16 <adamw> question is how common this configuration is?
16:51:16 <brunowolff> Could it just be a very long timeout or series of timeouts making it look like a hang?
16:51:30 <tflink> hard to say, it depends on how the bridged networking is set up
16:51:31 <adamw> that sounds possible
16:51:35 <adamw> we should ask how long he left it
16:52:05 <tflink> my first suspicion is that this is vb-specific
16:52:08 <Viking-Ice> still I dont think this is a beta blocker
16:52:22 <adamw> i'd be ok with punt or -1
16:52:26 <Viking-Ice> tflink, yeah we need to recreate this on kvm
16:52:47 <tflink> Viking-Ice: I use bridged networking with ovirt on a regular basis
16:53:28 <tflink> I'm also OK with punt or -1, I doubt this is a blocker but there are some oddities here
16:53:40 <tflink> other thoughts?
16:54:06 <brunowolff> It seems like it is an unusual enough setup to not be a beta blocker.
16:54:09 <Viking-Ice> looks like this geo location  in anaconda is whats causing this
16:55:08 <tflink> which would make sense, it doesn't even try when no-networking and something might be messed up in the bridged case so that anaconda attempts geolocation and fails
16:55:33 <Viking-Ice> yeah anyway I'm -1 or punt
16:56:15 <Viking-Ice> ( this should be fixed for final thou )
16:56:17 <adamw> tflink: i guess you get to pick :)
16:57:05 <tflink> proposed #agreed 960262 - This seems like something that wouldn't be a blocker for F19 beta (uncommon setup) but it would be nice to be certain that either KVM and bare-metal aren't affected or that it's just a long timeout. Request info from reporter, re-visit at next meeting
16:57:15 <adamw> i don't think it's geoip, fwiw
16:57:21 <Viking-Ice> adamw, ok ack
16:57:31 <adamw> ack
16:58:09 <brunowolff> ack
16:58:12 <tflink> #agreed 960262 - This seems like something that wouldn't be a blocker for F19 beta (uncommon setup) but it would be nice to be certain that either KVM and bare-metal aren't affected or that it's just a long timeout. Request info from reporter, re-visit at next meeting
16:58:22 <tflink> #topic (960271) crash when setting RAID Name
16:58:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=960271
16:58:23 <tflink> #info Proposed Blocker, anaconda, NEW
16:59:52 <adamw> seems reasonable +1
17:00:08 <Viking-Ice> yup +1
17:00:20 <tflink> yeah, assuming that I understand what he's getting at, +1
17:01:36 <tflink> proposed #agreed 960271 - AcceptedBlocker - Violates the following F19 beta release criterion for setting invalid RAID device name: "When using the custom partitioning flow, the installer must be able to Reject or disallow invalid disk and volume configurations without crashing."
17:01:46 <Viking-Ice> ack
17:02:38 <adamw> ack
17:03:00 <tflink> ack/nak/patch?
17:03:13 <brunowolff> ack
17:03:52 <tflink> #agreed 960271 - AcceptedBlocker - Violates the following F19 beta release criterion for setting invalid RAID device name: "When using the custom partitioning flow, the installer must be able to Reject or disallow invalid disk and volume configurations without crashing."
17:04:03 <tflink> #topic (928645) gnome-initial-setup should set system keyboard layout as the default Input Source
17:04:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=928645
17:04:08 <tflink> #info Proposed Blocker, gnome-initial-setup, NEW
17:05:09 <Viking-Ice> looks like an FE at best to me
17:05:23 <adamw> it's a bit messy, but yeah, that'd be my take
17:05:56 <adamw> well, i'd like to check exactly how it behaves...
17:06:16 <Viking-Ice> and compare it to F18
17:06:22 <adamw> i guess the most interesting part is, does g-i-s use en_US even if you picked French or whatever
17:06:43 <adamw> the list it displays is empty, we know that, but we don't know what layout actually winds up being active. i'd guess it's the 'right' one, but we should check
17:07:00 <Viking-Ice> you probably should test firstboot as well ( it might have worked there but does not in g-i-s )
17:07:25 <adamw> yeah
17:07:28 <adamw> punt for testing?
17:07:30 <Viking-Ice> yup
17:08:25 <adamw> well, even if that turns out to be a problem, it'd probably make 958714 a blocker, not this bug. hm.
17:08:32 <adamw> i should really ask bochecha for help too.
17:08:59 <tflink> proposed #agreed 928645 - It still isn't 100% clear what's going on here and more information is needed. Will re-visit when more testing has been done.
17:09:04 <Viking-Ice> ack
17:09:31 <brunowolff> ack
17:09:45 <adamw> ack
17:10:04 <tflink> #agreed 928645 - It still isn't 100% clear what's going on here and more information is needed. Will re-visit when more testing has been done.
17:10:14 <tflink> ok, that's all of the proposed blockers on my list
17:10:31 <Viking-Ice> any objection running through those few FE
17:10:35 <Viking-Ice> proposals
17:10:48 <tflink> ?
17:10:56 <brunowolff> There aren't that many, so I'm OK with it.
17:11:13 <tflink> I was planning to run through the proposed FE
17:11:25 <Viking-Ice> ok sometimes we do sometimes we dont hence I asked ;)
17:13:32 * tflink skips the VERIFIED one, though
17:13:42 <tflink> #topic (948117) gnome-settings-daemon should default to ibus-kkc [ja] and ibus-libpinyin [zh_CN]
17:13:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=948117
17:13:47 <tflink> #info Proposed Freeze Exceptions, gnome-settings-daemon, NEW
17:14:14 <Viking-Ice> +1
17:14:56 <Viking-Ice> the patch is non invasive enough so we should pull it in
17:15:32 <tflink> assuming this isn't another spat about IMEs, +1
17:16:59 <adamw> sorry folks, i was making an updates image for 958714
17:17:36 <adamw> doesn't actually need an FE at present, we're not frozen, but sure
17:17:37 <adamw> +1
17:17:53 <tflink> hrm, good point
17:18:28 <Viking-Ice> FE let's us keep track of it but yeah
17:19:26 <tflink> proposed #agreed 948117 - AcceptedFreezeException - This seems relatively low-risk and assuming that everything is accurate, a tested fix would be considered past freeze.
17:19:34 <brunowolff> ack
17:19:35 <adamw> ack
17:19:37 <Viking-Ice> ack
17:20:10 <tflink> #agreed 948117 - AcceptedFreezeException - This seems relatively low-risk and assuming that everything is accurate, a tested fix would be considered past freeze.
17:21:03 <tflink> #topic (922958) SELinux is preventing /usr/sbin/lightdm from 'create' accesses on the file .dmrc.T5D7TW.
17:21:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=922958
17:21:08 <tflink> #info Proposed Freeze Exceptions, selinux-policy, MODIFIED
17:21:23 <tflink> it sounds like a fix is done, just not built in repos yet
17:21:44 <brunowolff> This seems more than just an selinux policy would be needed.
17:22:07 <adamw> a new selinux-policy was submitted yesterday, i'm assuming the fix is in there. lemme see
17:22:15 <brunowolff> If this only is likely to affect non-blocking desktops, then it might be that much of a risk.
17:22:36 <Viking-Ice> #37
17:22:41 <brunowolff> They were discussion changes to lightdm to enable a policy to be able to fix this.
17:23:09 <brunowolff> Specific filenames in selinux policy can't have wild cards.
17:24:10 <brunowolff> So it looks like this will most likely be in before freeze and has already got some testing.
17:24:36 <Viking-Ice> I would say we pull it just to be sure but yeah
17:25:30 <tflink> I could go either way
17:25:48 <tflink> but I also wonder why we're even going through the proposed FE before freeze
17:26:05 <Viking-Ice> because we dont want to deal with a potentially huge list
17:26:29 <Viking-Ice> and we suffer from stockholm syndrom from last release cycle
17:26:33 <brunowolff> Yeah, we want to use light days to get ahead of the game.
17:27:02 <tflink> maybe we should just disallow FE proposal until X days before freeze
17:27:03 <adamw> yeah, i'd agree there
17:27:10 <adamw> tflink: i don'
17:27:13 <adamw> t like that really.
17:27:37 <adamw> it seems absurd to not allow showstoppers in Xfce or LXDE image being oversize etc to be proposed.
17:27:44 <brunowolff> Given the route they are taking for a solution, I'm +1 FE.
17:27:48 <tflink> eh, +100 to kparal's opinion that the FE process could be improved
17:27:51 <adamw> anyhow, +1.
17:27:56 <Viking-Ice> +1
17:27:57 <tflink> either way, getting off topic
17:28:13 <adamw> and to be honest, i'd pull the latest selinux-policy into TC4 *anyway* so it's kinda moot :)
17:28:26 <Viking-Ice> ;)
17:28:27 <adamw> for pre-freeze TCs I usually just pull the latest selinux-policy anyway.
17:28:37 <adamw> unless I forget.
17:29:31 <Viking-Ice> the last ( why was this even proposed ) one for the day
17:29:36 <tflink> proposed #agreed 922958 - AcceptedFreezeException - This causes AVC errors onlogin for lightdm which would be a blocker for primary DEs. Accepted as FE for F19 beta as lightdm is used in secondary DEs
17:29:41 <Viking-Ice> ack
17:29:54 <adamw> ack
17:30:32 <brunowolff> ack
17:30:34 <tflink> #agreed 922958 - AcceptedFreezeException - This causes AVC errors onlogin for lightdm which would be a blocker for primary DEs. Accepted as FE for F19 beta as lightdm is used in secondary DEs
17:30:43 <tflink> #topic (914557) ustr: FTBFS in rawhide
17:30:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=914557
17:30:44 <tflink> #info Proposed Freeze Exceptions, ustr, NEW
17:30:55 <Viking-Ice> why is this one on this list?
17:30:56 <brunowolff> Why is an FTBS suiteable for an FE?
17:31:20 <brunowolff> There is no comment about what having a rebuilt update would provide.
17:31:30 * Viking-Ice points finger at adamw
17:31:33 <adamw> this is just from that pile that boblfoot filed erroneously on updates
17:31:45 <adamw> it got the tag because he filed a new bug for it and I closed it as a dupe of this one
17:31:51 <tflink> yeah, the blocks went through the dupe and the rejected didn't
17:31:51 <adamw> looks like this fell through the cracks when I rejected all of those
17:32:02 <tflink> #undo
17:32:02 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x252b1190>
17:32:04 <tflink> #undo
17:32:04 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x252b1ed0>
17:32:06 <tflink> #undo
17:32:06 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x252b10d0>
17:32:31 <adamw> i've just set it to rejected
17:32:34 <tflink> ok, on to the accepted blockers which aren't ON_QA or VERIFIED
17:32:43 <tflink> #topic (950487) AttributeError: 'NoneType' object has no attribute 'format'
17:32:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=950487
17:32:49 <tflink> #info Accepted Blocker, anaconda, NEW
17:33:45 <tflink> this was just accepted 2 days ago
17:34:00 <tflink> #info this was accepted 2 days ago
17:34:04 <adamw> i think some of these may be waiting on dlehman's return
17:34:12 <Viking-Ice> he's on vacation?
17:34:21 <adamw> i can poke bcl and ask if he can have clumens or someone work on at least the *blocker* bugs in the mean time
17:34:29 <adamw> yeah, IIRC he's away for this week
17:34:40 <tflink> #info there has been some testing but nothing ATM which indicates that more people need to get involved
17:34:44 <adamw> oh, bcl assigned this one to himself yesterday
17:34:49 <adamw> so obviously he's planning to fix it
17:34:52 <Viking-Ice> yeah kinda needs to do that ( holding the release for people on vacation hmm not the best scenario )
17:35:30 <tflink> anything else?
17:35:44 <adamw> no, looks like the bug's clear and a dev is on it
17:35:46 <tflink> #topic (958424) 19 Beta TC1 DVDs are oversized (larger than 4.7 GB)
17:35:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=958424
17:35:52 <tflink> #info Accepted Blocker, distribution, NEW
17:36:41 <Viking-Ice> these oversize issue really should not be happening again and again every goddam release cycle
17:37:11 <tflink> I know there was a huge thread on devel@, but I wasn't following it all that closely
17:37:13 <Viking-Ice> we need to set packages on the dvd into stone
17:37:17 <brunowolff> I saw some email about comps work to try to address this. I am not sure how close we are now though.
17:37:28 <tflink> it looks like progress is being made slowly
17:38:07 <Viking-Ice> do we even know what blew it this time?
17:38:19 <brunowolff> This was kind of a bummer for the games spin, as I was hoping that gnome would get fixed. But it got so late I made cuts before gnome did.
17:38:21 <tflink> not sure
17:38:24 <Viking-Ice> anyway this is comps/releng problem
17:38:57 <adamw> notting's still working on it
17:39:06 <adamw> Viking-Ice: it's a combination of adding MATE and other things getting bigger
17:39:17 <adamw> if we can't make it by trimming we'll just have to drop MATE
17:39:20 <brunowolff> There can also be dependency bloat that packagers could be asked to address. I am not sure how much of that there is this time around. But it has been a big factor in the past.
17:39:50 <adamw> but yeah, there's a big thread on devel and the appropriate dev is aware and working on it, so things are in order here
17:39:56 <Viking-Ice> adamw, throw something in him to make him work faster or give him bear so he gets careless and +drops MATE faster ;)
17:40:09 <Viking-Ice> mean beer not bear
17:40:27 <tflink> it doesn't seem like many changes have happened in comps or spin-kickstarts lately
17:40:34 <tflink> well, changes that could affect this
17:40:49 <brunowolff> I think giving him a mean bear would be pretty nasty.
17:40:50 <tflink> #info the appropriate dev is aware of the problem, discussion is ongoing
17:41:02 <tflink> it would be nice to have this closer to fixed before freeze
17:41:18 <Viking-Ice> let's say fixed
17:41:58 <tflink> but outside of motivation through fear of bears or desire for beer, I'm not sure we can/should do much ATM
17:42:24 <Viking-Ice> nope we cannot we just have to wait
17:42:47 <tflink> I do believe that the next issue will have the same resolution
17:43:01 <tflink> #topic (958426) 19 Beta TC1 Desktop Lives are oversized (larger than 1 GB)
17:43:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=958426
17:43:07 <tflink> #info Accepted Blocker, distribution, NEW
17:43:17 <Viking-Ice> yup same resolution
17:43:31 <tflink> there seems to be no movement on this one, though
17:43:39 <Viking-Ice> I think we can just skip over the oversized  ones
17:43:41 <adamw> Viking-Ice: throwing a bear in him could have fascinating consequences :P
17:43:53 <tflink> adamw: in?
17:43:53 <adamw> actually desktop live is good now
17:43:58 <adamw> tflink: yes, in :)
17:44:12 <adamw> mclasen chopped like 120MB out of it
17:44:17 <adamw> it'll come out well under size in the next compose
17:44:18 <tflink> cool
17:44:25 <adamw> we should set it to MODIFIED
17:44:45 <tflink> #info this should be fixed, next beta TC should be within size restrictions
17:44:58 <tflink> I do believe that is all for today
17:45:07 <tflink> are there any bugs that I missed?
17:45:15 <adamw> none I remember
17:45:20 <Viking-Ice> we could go over that cinnamon accepted FE
17:45:51 <adamw> which one's that?
17:46:00 <Viking-Ice> 920320
17:46:38 <tflink> #topic (920320) cinnamon does not start
17:46:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=920320
17:46:38 <tflink> #info Accepted Freeze Exceptions, cinnamon, ASSIGNED
17:46:47 <tflink> any particular reason why?
17:47:03 <adamw> i don't think dan or leigh are here
17:47:13 <Viking-Ice> well then we skip it
17:47:18 * adamw pings dan in #fedora-qa
17:48:33 <adamw> nothin.
17:48:35 * Viking-Ice sneaks in and set's the fuse on
17:48:41 <robatino> https://bugzilla.redhat.com/show_bug.cgi?id=961065 was just proposed as a beta blocker
17:49:31 <Viking-Ice> assign this one to mariadb ;)+
17:49:41 <adamw> dupe of https://bugzilla.redhat.com/show_bug.cgi?id=959756 ?
17:49:52 <adamw> which is itself a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=959610
17:50:03 <Viking-Ice> maintainers but depency breakages are auto blocker for dvd
17:50:03 <brunowolff> I was just going to say a short version of that.
17:50:56 <adamw> i'll re-open 959610 as it's not fixed on a compos yet
17:51:05 <brunowolff> I am pretty sure I remember seeing this soname issue at Monday's meeting.
17:51:27 <tflink> yeah 959756 was discussed on monday
17:51:57 <tflink> #info nothing to report, devs are aware of issue and working on it
17:52:16 <tflink> I do believe that is time for ...
17:52:17 <adamw> actually a fixed package is already in stable
17:52:20 <tflink> #topic Open Floor
17:52:25 <adamw> so it should be auto-fixed in TC4, we just need to check
17:52:30 <tflink> #undo
17:52:30 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x228197d0>
17:52:43 <tflink> #info fixed package is available, should work for TC4
17:52:48 <adamw> nope
17:52:55 <tflink> eh?
17:52:57 <adamw> oh, well, i guess that's ok
17:53:04 <adamw> you didn't #undo the first #info, wasn't sure if you meant to or not
17:53:15 <tflink> #undo
17:53:15 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x22d17890>
17:53:17 <tflink> #undo
17:53:17 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x24b68950>
17:53:24 <tflink> no, not really but eitherway
17:53:27 <tflink> #info fixed package is available, should work for TC4
17:53:36 * adamw thinks tflink just loves playing with #undo
17:53:50 <tflink> #undo adamw
17:53:55 <tflink> damn, didn't work
17:53:59 <adamw> i'm meeeeeeeeeelting
17:54:06 <brunowolff> How do you guys keep track of what was really undone when you do lots of undos mixed with other # commands?
17:54:23 <adamw> brunowolff: you can normally work it out from the sequence of what type of object was undone
17:54:30 <tflink> counting and looking at the object that was undone
17:54:32 <adamw> it can be a bit of a brain teaser through :)
17:54:35 <adamw> though*
17:55:25 <tflink> anyhow ...
17:55:30 <tflink> #topic Open Floor
17:55:35 <tflink> for reals this time, even :)
17:55:46 <tflink> anything else that should be brought up in the meeting?
17:55:54 <brunowolff> It should end.
17:56:50 * tflink assumes not and sets the fedora-qa patented non-deterministic fuse for [0,5] minutes
17:57:24 <adamw> we really need to start getting royalties on that thing
17:58:45 <adamw> oh hey
17:59:21 <adamw> i t hink we missed https://bugzilla.redhat.com/show_bug.cgi?id=912303
17:59:28 <adamw> dan set it as blocking f*18* beta...
17:59:50 <adamw> i think dan was confused, but this is actually a kind of interesting bug
18:00:20 <tflink> but a blocker?
18:00:49 <adamw> well, it could bust upgrades, theoretically
18:00:55 <adamw> looks like we need to figure what package triggers the problem
18:01:32 * tflink really needs to get that email to devel@ and test@ about using the proposal GUI
18:02:04 <adamw> eh, i guess i should poke this one some more before we discuss it
18:02:26 <tflink> leave it for now, change the proposal and revisit?
18:02:41 <adamw> yeah, i've just wiped out the f18beta proposal and added a comment
18:02:42 <tflink> we can pretend that I ended the meeting before you brought it up
18:03:03 <adamw> yes let's
18:03:08 <tflink> #endmeeting