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