15:01:16 #startmeeting f19final-blocker-review-7.1 15:01:16 Meeting started Thu Jun 20 15:01:16 2013 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:16 #meetingname f19final-blocker-review-7.1 15:01:16 #topic Roll Call 15:01:16 The meeting name has been set to 'f19final-blocker-review-7.1' 15:01:40 * Martix is here 15:01:46 * nirik is lurking 15:03:25 * jreznik also here 15:05:55 kparal, adamw: you around? 15:07:28 * Viking-Ice sneaks in 15:07:44 ah 15:07:56 around, but only for 20-30 minutes 15:07:58 ok, I think we have enough to get started 15:08:07 * pschindl is here 15:08:10 any volunteers for secretary duty? 15:08:17 tflink: btw we might want to discuss 976389, even though not proposed as a blocker 15:09:42 kparal: yeah, that one looks like fun 15:11:02 I guess I can do the secretarialization after the meeting 15:11:05 that's an autoblocker 15:11:11 can we discuss dconf bug first? 15:11:22 Viking-Ice: it is, if it were reproducible 15:11:22 yes let's discuss dconf 15:11:24 yep, it was first on the list anyways 15:11:29 #topic Introduction 15:11:30 here kinda 15:11:35 Why are we here? 15:11:35 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and freeze exception bugs. 15:11:40 #info We'll be following the process outlined at: 15:11:40 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 15:11:46 #info The bugs up for review today are available at: 15:11:46 #link http://qa.fedoraproject.org/blockerbugs/current 15:11:52 #info The criteria for release blocking bugs can be found at: 15:11:52 #link https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria 15:11:55 #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria 15:11:58 #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria 15:12:00 tflink: because i love you 15:12:01 #info Up for review today, we have: 15:12:15 ? 15:12:17 #info 5 Proposed Blockers 15:12:18 #info 8 Accepted Blockers 15:12:18 #info 13 Proposed Freeze Exceptions 15:12:18 #info 25 Accepted Freeze Exceptions 15:12:41 since there was a request for it, we'll start with the proposed blockers 15:12:44 #topic (975521) unable to change settings using dconf 15:12:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=975521 15:12:49 #info Proposed Blocker, dconf, ASSIGNED 15:13:45 the issue seems to be quite critical 15:13:53 and it's good we can reproduce 15:14:05 I'd be +1 blocker if we know how to fix it 15:14:08 yeah, I was able to get it with an unclean shutdown on the first try 15:14:26 just from our cubicle 2 people were affected 15:14:44 and an unclean shutdown is quite a common thing, sometimes the kernel just panics or something 15:14:45 kparal: all unclean shutdowns? 15:14:52 tflink: yes 15:15:16 Petr used poweroff -f, and Jan's computer got stuck 15:15:48 is there a reasonable way to either restore the conf file or at least get things to the point where you can start changing settings again? 15:17:35 tflink: yes, remove the dconf file 15:17:41 I don't know how relevant this is but I saw it on a VM configured for RAID1, so something is able to nerf the file on both "copies" 15:17:44 just so we are clear this only happens once you start manually editing the dconf ( if thats the case to me makes it an +1 FE if not or randomly the +1 blocker ) 15:17:55 tflink: by the way, it's not just about settings, some applications stop working completly 15:18:04 kparal: ah, I hadn't hit that yet 15:18:05 Viking-Ice: no 15:18:16 Viking-Ice: you don't need to manually edit dconf 15:18:23 just have an unclean shutdown 15:18:26 * jreznik_ is back, met his boss in the doors :) 15:18:28 then stuff stopps working 15:18:36 then it's a blocker if the file corrupst after install or unclean shutdown 15:18:48 so +1 blocker 15:18:48 pschindl says that e.g. Evolution can't be resized 15:19:10 the layout inside Evolution to be exact 15:19:35 it'd be interesting to see the dconf file before and after 15:20:06 /me listening 15:20:13 * tflink also wonders if there is anything else at work here - resizing windows seems a rather odd side effect of dconf issues 15:20:25 criterion suggestions? 15:20:45 tflink: well the layout sizes are stored inside dconf 15:21:03 " All known bugs that can cause corruption of user data must be fixed or documented at Common F19 bugs " 15:21:24 +1 blocker. if we really don't know how to solve it in a reasonable timeframe, we will be forced to just document it 15:21:34 I think dconf is pushing the definition of user data, but I'm not going to fight it either 15:21:41 this is rather nasty and not that hard to hit 15:21:42 but it's visible in dconf, but most probably affects all files 15:21:47 so it's very easy to lose some data 15:22:03 yeah, that wouldn't surprise me 15:22:13 tflink: what is user data if not system settings? 15:22:16 I wonder what would happen with an unclean file and something was open 15:22:28 kparal: documents, etc 15:22:46 well, some of that is stored inside dconf. configuration of your programs, etc 15:22:46 I didn't say that dconf wasn't user data, just that it was pushing the definition a bit 15:23:54 a loss of your keyboard layout might prohibit you in logging in again 15:23:58 proposed #agreed 975521 - AcceptedBlocker - Violates the following F19 final release criterion for at least dconf data after an unclean shutdown: "All known bugs that can cause corruption of user data must be fixed or documented at Common F19 bugs" 15:24:05 ack 15:24:08 ack 15:25:04 ack and agree with kparal about reasonable timeframe & documentation 15:26:23 #agreed 975521 - AcceptedBlocker - Violates the following F19 final release criterion for at least dconf data after an unclean shutdown: "All known bugs that can cause corruption of user data must be fixed or documented at Common F19 bugs" 15:26:34 #topic (976389) Missing dependencies on Fedora-19-TC6-x86_64-DVD.iso 15:26:37 #link https://bugzilla.redhat.com/show_bug.cgi?id=976389 15:26:40 #info Proposed Blocker, distribution, NEW 15:26:47 we can skip this 15:26:56 we found out that MArtix used a 1GB drive 15:27:04 and didn't noticed the iso is oversized 15:27:06 kparal: no! 4GB 15:27:13 ah, right 15:27:17 that's still too small for a DVD 15:27:27 but current image is over 4GB then previous 15:27:33 I got a bit confused, but you get it :) 15:27:40 too small drive 15:27:41 DVDs are supposed to be 4.6 15:27:57 tflink: I know 15:28:58 #info Already closed as NOTABUG 15:29:07 #chair kparal 15:29:07 Current chairs: kparal tflink 15:29:16 #info Already closed as NOTABUG 15:29:36 ok, moving on 15:29:38 #topic (976107) gnome-games 17 to 19 update fails 15:29:38 #link https://bugzilla.redhat.com/show_bug.cgi?id=976107 15:29:39 #info Proposed Blocker, gnome-games, MODIFIED 15:30:06 I suspect that this will also cause problems with 18 ->19 upgrade 15:30:28 but I can confirm that the games in question crash after 17 -> 19 upgrade 15:31:39 +1 blocker 15:31:43 other votes? 15:32:13 +1 15:32:14 criterion? 15:32:17 .+ 15:32:20 +1 15:32:25 ah, I see, 18->19 15:32:30 I'm not that sure about that 15:32:36 but /me shrugs 15:33:08 kparal: as I understand, the problem is upgrade path from 18 to 19 15:33:22 the original report says 17->19 15:33:25 the package in 17/18 isn't properly obsoleted in 19 15:33:28 in 18 the package names are different 15:33:39 ah, I misread 15:33:51 so maybe a default install in 18 doesn't include the packages at all, or they can be upgraded just fine 15:33:53 I have no idea 15:33:54 how did this work for 17 -> 18 upgrades? 15:34:02 dunno 15:34:59 +1 FE and give somebody a short time to verify whether it affect default 18 install 15:35:07 dependency errors arent those autoblocker 15:35:27 * kparal needs to go 15:35:32 Viking-Ice: this is a bit of a special case 15:35:47 yeah, not sure about blocker right now, but +1 FE 15:36:13 well we only support default install upgrades and afaik gnome games aren't part of those so... 15:36:24 +1 FE 15:36:31 ok, then -1/+1 15:37:36 Viking-Ice: I'm pretty sure they are, they were for F17 at least 15:37:56 then those dep errors are autoblcoker 15:38:00 mean autoblocker 15:38:08 +1 blocker 15:38:35 the dep problems are from 17 to 18 15:38:58 it sounds like an 18 to 19 upgrade would not be affected by this 15:40:02 yes but we support upgrading from EOL to latest 15:40:10 so the idea was to take as a FE since there are fixed builds available and decide on blocker after more investigation to make sure that 18-19 upgrades aren't affected 15:40:31 Viking-Ice: not that I'm aware of. 17 -> 19 are more of a best effort, may not work 15:40:52 tflink: ok, let's do it this way 15:40:54 we want them to work, sure. but I'm not sure if we're going to block release if they don't 15:41:14 tflink, those whole us supporting upgrades is as I suspected due to RHEL 7 15:41:21 we should not be supporting upgrades et al 15:41:41 so we support going from the release to be EOL to latest ( which is what many users do ) 15:42:54 proposed #agreed 976107 - AcceptedFreezeException - While unfotunate, Fn-2 to Fn upgrades are not directly supported and it is unclear on whether this violates any criteria. However, a tested fix would be considered after freeze 15:43:14 ack 15:43:18 ack 15:43:29 Viking-Ice: the criteria clearly state "upgrade from previous stable release" 15:43:38 the previous release 15:44:21 any othe ack/nak/patch? 15:44:57 tflink, then that's a criteria mistake and we ( QA ) was never asked or approached with regards to if we should support upgrades. It took me long enough to get us to support minimal/default install upgrades anyway 15:45:39 let's take this as an FE and deal with upgrades later 15:45:41 Viking-Ice: huh? I'm pretty sure there was active discussion around upgrades during F18 timeframe 15:45:48 Viking-Ice: waiting for acks 15:45:55 ack 15:46:04 #agreed 976107 - AcceptedFreezeException - While unfotunate, Fn-2 to Fn upgrades are not directly supported and it is unclear on whether this violates any criteria. However, a tested fix would be considered after freeze 15:46:12 #topic (974680) Intel HDA sound issue 15:46:12 #link https://bugzilla.redhat.com/show_bug.cgi?id=974680 15:46:13 #info Proposed Blocker, kernel, NEW 15:46:43 tflink, when supporting upgrade was decided this got decided for us we did not have anything in place for it and did not for release(s), not test cases not criteria nothing 15:47:25 everyone in QA knows we cant support upgrades never regardless if we use pre-upgraded/fedup or yum upgrade 15:48:10 ( to many installation combination available for us to test ) but anyway RHEL gets to enjoy all that fun with supporting RHEL 6 - 7 upgrades ;= 15:48:16 ) 15:48:53 Viking-Ice: sure, I'm not arguing that upgrades are simple, but I am arguing that right here and right now is not the best time for a discussion on whether the criteria make sense 15:49:02 Viking-Ice: I wonder how they want to do it on rhel side :) 15:49:34 upgrades are a scary combinatorial explosion of crazy complexity 15:49:42 but we digress 15:49:51 yep, let's move on - we have another blocker on topic, move discussion to #fedora-qa or ml 15:49:53 there is not enough info here to take this bug as a blocker or FE 15:50:11 punt is fine 15:50:14 by me 15:50:16 claims, yes. enough reports or information, not enough 15:51:03 * jreznik is ok to punt this one 15:51:08 jreznik, does that not end up with you guys in brno anyway ;) 15:51:12 proposed #agreed 974680 - There is not enough information here to make a decision on blocker status for this bug. Will revisit at the next meeting but if there is still not enough information, will reject as a blocker for F19 final 15:51:16 ack 15:51:42 ack 15:52:01 jreznik, or are rh fedora-qa and rh rhel-qa completely separated groups? 15:52:17 Viking-Ice: we're pretty separated 15:52:31 tflink, sucks to be them supporting it ;) 15:52:59 tflink: hey, you have the same CEO! not completely separated :) 15:53:01 ack 15:53:03 #agreed 974680 - There is not enough information here to make a decision on blocker status for this bug. Will revisit at the next meeting but if there is still not enough information, will reject as a blocker for F19 final 15:53:21 jreznik: I didn't say completely separated 15:53:31 but there is significant disconnect 15:53:44 #topic (976415) Missing usermode-gtk in dependencies 15:53:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=976415 15:53:44 #info Proposed Blocker, liveusb-creator, NEW 15:54:15 sounds like a pretty clear blocker - has anyone else seen this? 15:55:05 * jreznik would say we can trust pschindl and the investigation guys did 15:55:07 ok, I don't think that we need this tool in criterion. It doesn't work well 15:55:28 the tool itself is not in the criterion 15:55:33 so I'm for removing it from criteria or +1 for blocker 15:55:54 any app that ships and is install by default in gnome should work so it's an autoblocker 15:56:14 also liveusb-creator didn't find usb disk for kparal and jsedlak, lbrabec 15:56:30 Viking-Ice: is it default one? 15:56:33 it is not installed by default 15:56:36 I think 15:56:45 Viking-Ice: reproducer - 1. On freshly installed Fedora 19 install liveusb-creator 15:57:53 removing it from criteria is a bad idea - this is one of the only ways to create install media from windows 15:58:03 ah 15:58:23 tflink: I hope that it works better in Windows 15:58:39 * satellit_e important to create a Soas "sugar on a stick" 15:58:39 because in linux it is a terrible use experience 15:59:00 jreznik, I mistok it for being installed by default 15:59:07 then this is just a regular bug 15:59:09 I thought liveusb-creator was written in qt, anyways 15:59:11 from my end 15:59:17 no, it's a blocker 15:59:24 * tflink is looking for the criterion 15:59:26 ? 16:00:07 if we need it for windows mostly, then there's no reason to have it in criteria (/me waits for criterion) 16:00:30 jreznik, it's a bit stupid for us blocking for tools that cannot run properly on other os 16:01:13 "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods." 16:01:27 jreznik, or do you want us to block our own release because app1 does not work on windows or app2 does not work on apple ios or app3 does not work on any of the 400+ distro's out there ? 16:01:51 Viking-Ice: when it involves getting windows users to start using fedora, yes 16:02:15 and we're talking about the only supported method for doing that as far as I know 16:02:28 tflink: but if the issue is related to our own packaging issue in fedora, not on windows? I'm more +1 FE on this one 16:03:04 the tool is important on windows but this bug is about our own packaging 16:03:04 tflink, that means the project has officially taken stance on reducing the microsoft windows user base kinda does it not and so far I'm not aware of such statement 16:03:16 +1 FE from my end if we can fix it we should 16:03:45 +1 blocker - it's a clear violation of criteria 16:04:17 I'm +1 blocker (and it shouldn't be hard to fix) 16:04:20 * satellit_e it runs in memory on booted Soas live though... 16:04:33 when installed from CD 16:04:41 jreznik, Viking-Ice: are you both -1 blocker? 16:04:53 morning 16:04:55 d'oh, we started at 8am? sorry guys 16:05:05 .fire adamw for being late 16:05:05 adamw fires adamw for being late 16:05:17 I'm -1 blocker until offical announce from the board that we are targeting existing windows users for use of Fedora 16:05:32 Viking-Ice: this bug has nothing to do with windows users 16:05:41 the tool does, this bug does not 16:05:50 this bug is about running it in *fedora* 16:05:58 why can't this be fixed with an update? 16:06:03 unless I'm reading it wrong, this bug is a clear cut criteria violation 16:06:03 is luc even on any of the release media? 16:06:04 that's what I said 16:06:21 adamw: from bug report it seems it's not 16:06:36 * satellit_e KDE? 16:06:47 tflink: the criterion talks about the USB sticks being bootable, which implies the tools *working*, but stretching it to cover the tools' deps seems like quite a stretch 16:07:27 how can you possibly use a tool to create usb media when the tool itself isn't working 16:07:51 there are other ways to create that usb media 16:08:07 yes, but the criterion explicity says "ANY supported method" 16:08:26 which is the difference from alpha when we only require one of the methods to work 16:08:30 tflink: by using it on any other fedora, or on windows, or using the fixed update we'll no doubt ship 16:09:24 liveusb-creator is not in spin-kickstarts and only in comps as 'optional' (which with current anaconda is effectively 'not in comps') 16:09:26 so we're at -3/+2 on blocker and pretty much unanaimous FE? 16:09:27 how's the "supported method" is defined? /me does not understand having everysingle tool covered by criteria makes sense... 16:09:30 i can't see a reason to block on this 16:09:50 jreznik: we should change it to 'recommended', but it's the ones we document: dd, litd, luc 16:10:13 jreznik: we have to support each of those because there are users not covered by each one, but we don't want to support anything else 16:10:39 jreznik, well we need to remove any reference to support in our criteria regardless of what ever decides to officially support or not for us 16:11:06 adamw, not recommended either. seriously how can your recommend project a over project b in fedora 16:11:17 Viking-Ice: very easily: we have a fedora document which says 'project a is recommended' 16:11:19 votes? 16:11:28 I only see +2/-1 16:11:31 -1 16:11:40 * lmacken reading the liveusb-creator usermode-gtk bug for the first time... if it's an easyfix I can push it today 16:11:42 i'm not even sure about fe; what's the point if it's not on any media 16:12:06 jreznik: vote? 16:12:08 adamw, recommended by whom 16:12:44 Viking-Ice: The Project. same way the project does anything: someone declares it, we all argue about it for six months, it gets referred to fesco, fesco supports the original decision, then we have an argument about it on devel@ every year just to keep ourselves in shape 16:12:52 surely you know how Fedora works by now! 16:13:00 indeed 16:13:21 -2/-2 16:13:30 so we are voting for the FE now? 16:13:37 i think he meant +2/-2 16:13:37 oh 16:13:40 as in blocker votes 16:13:41 yeah, I did 16:13:46 +2/-2 16:13:57 moar voting 16:14:03 jreznik: blocker vote? 16:14:04 +1 16:14:08 btw, using liveusb-creator on f19 to write f19 live usbs is surely going to be the least common operation out of the lot 16:14:18 adamw: agreed 16:14:26 tflink: sorry, I was afk 16:14:44 * jreznik is reading backlog 16:14:56 i just don't see how this fits the criterion or any actual good reason to block on it, and i wrote the damn criterion... 16:15:42 tflink: do you honestly see this passing the 'last blocker' smell test? 16:15:58 -1 (and good point adamw about last blocker) 16:16:13 adamw: probably not, but I'm not always in agreement with the "ship it now, damnit" crowd 16:16:14 that's +3/-3 16:16:22 no, +2/-3 16:16:29 we've got RC16 images all ready to go, it's 3pm Thursday, and everyone says 'ooh, yeah, we've got to fix a tool that's not even ON these images before we release them'? 16:16:29 petr was already in the +2 16:16:53 well then that's decided next one.. 16:16:56 fine, we need to fix the criterion then 16:17:22 whatever, enough bikeshedding 16:17:50 tflink: i really don't see that this clearly touches the criterion at all. 16:18:07 the release-blocking live images certainly boot when written to a USB stick with liveusb-creator. 16:18:45 do we have some criterion for working tools? 16:18:50 no 16:18:53 proposed #agreed 976415 - RejectedBlocker - The images are writable to USB and this bug can be fixed with an update post-release. 16:18:58 if a tool was actually 100% broken i'd argue it violated this criterion 16:19:14 but 'it doesn't run from the graphical user menu, in the most unlikely scenario for its use' does not seem to constitute 100% broken to me 16:19:17 ack 16:19:40 ack 16:19:41 if liveusb-creator actually *didn't work at all* then you could say 'well, you can't write a usb stick with it, so obviously one doesn't boot'. but this? no. 16:20:06 ack 16:20:13 #agreed 976415 - RejectedBlocker - The images are writable to USB and this bug can be fixed with an update post-release. 16:20:41 ok, that's all of the proposed blockers for today 16:20:48 moving on to the proposed FEs 16:20:52 is anyone else secretaryalizing or shall i pick up the backlog? 16:21:06 adamw: I was going to do it after the meeting but I'm not going to fight you for it 16:21:13 * adamw bares teeth 16:22:16 I really should be pre-filtering these bugs 16:23:18 any objections to skipping the proposed FEs that aren't at least MODIFIED? 16:23:55 i'm fine with it 16:24:04 no objections 16:24:08 #topic (976306) PHP 5.5.0 final 16:24:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=976306 16:24:08 #info Proposed Freeze Exceptions, php, MODIFIED 16:25:17 i'll see if there are any others to pull out at the end 16:25:19 I'm personally fine with pulling this in 16:25:33 but I'm unsure what this is doing with us 16:25:41 non-free sources in the SRPM? sounds bad. 16:25:51 yeah, that doesn't make sense to me 16:25:56 just based on the topic line I was 'big red NO', but that seems a reasonable reason 16:26:11 if we don't grant it a freeze exception we'll have the 'bad' SRPM in the release repository forever. hardly the end of the world, but i guess it's nice not to. 16:26:23 php may be on the DVD too, actually. 16:26:39 so 16:26:49 so the bug is that there are non-free sources on the DVD? 16:27:01 basically, at least if i'm interpreting it right 16:27:11 there's probably background to this somewhere, would've been nice for the reporter to include it 16:27:16 this is fesco issue right ? 16:27:29 * Viking-Ice confused what this is doing with us 16:27:34 Viking-Ice: even if so, in practice we'd best give it an FE to get it through the freeze as fesco currently has no process for that 16:27:51 Viking-Ice: right now the blocker/FE process is really the only defined process for getting anything through the freeze 16:28:06 "I'm personally fine with pulling this in" so I'm an obvious +1FE 16:28:06 the only other way would be for releng to submarine it in based on an email or irc request, which leaves basically no paper trail. 16:28:11 yeah, I'm OK with FE for getting non-free source off the DVD and out of the base repo 16:28:14 +1 16:28:20 +1 16:28:20 +1 16:28:34 (assuming we read the problem correctly, I'll ask for clarification in the comment) 16:29:24 proposed #agreed 976306 - AcceptedFreezeException - As we understand it, the fix would remove non-free sources from the base F19 repo and from the DVD. As this is important to do, a tested fix would be considered after freeze. 16:29:28 if I'm understanding this correctly those nonfree sources only exist in the srpm "non-free sources still included in the source RPM" 16:29:32 ack 16:29:53 * Viking-Ice which is why I was getting confused with the dvd and stuff 16:29:59 Viking-Ice: oh, point, the srpms aren't on the DVD. but we do still ship a 'source image', i think 16:30:06 which exactly no-one ever looks at or uses 16:30:13 still, they're in the base repo. 16:30:29 tflink: patch to remove 'and from the DVD'? 16:30:49 well no one within the project but I supposed derivatives might be using it 16:31:13 proposed #agreed 976306 - AcceptedFreezeException - As we understand it, the fix would remove non-free sources from the base F19 repo. As this is important to do, a tested fix would be considered after freeze. 16:31:21 ack 16:31:47 ack 16:32:02 #agreed 976306 - AcceptedFreezeException - As we understand it, the fix would remove non-free sources from the base F19 repo. As this is important to do, a tested fix would be considered after freeze. 16:32:14 #topic (976017) Please push latest selinux policy to fix denials for gvfs and others 16:32:17 #link https://bugzilla.redhat.com/show_bug.cgi?id=976017 16:32:19 #info Proposed Freeze Exceptions, selinux-policy, MODIFIED 16:32:22 I'm not clear why dan did this 16:33:19 I don't understand this enough to say much either way on FE 16:33:20 there's another acceptedFE which happens to cover it, but i don't see a lot of harm in taking this one too. i guess it can track the gvfs fix 16:33:35 tflink: next build will be getting -54 either way, so it doesn't matter too much. 16:33:43 er, i think tc6 has -54 actually. 16:34:20 yeah, I'm not arguing against the effect just not a huge fan of the "please push X" bug 16:34:51 i don't mind either way on this as it has no practical effect. 16:37:34 anyone have strong thoughts on this one? 16:37:45 no not really 16:37:47 no strong thoughts 16:38:24 toss a coin 16:38:52 which side you are on? 16:38:56 arent we pulling in the latest selinux policy anyway? 16:39:39 proposed #agreed 976017 - RejectedFreezeException - There aren't many details in this bug and the requested build is already being pulled in to F19 final TC6 anyways. 16:39:51 ack 16:39:57 ack 16:40:34 #agreed 976017 - RejectedFreezeException - There aren't many details in this bug and the requested build is already being pulled in to F19 final TC6 anyways. 16:41:03 Viking-Ice: we are, that's why it doesn't matter... 16:41:04 any other proposed FEs to go over before we move on to the accepted blockers? 16:41:05 ack 16:41:13 gimme two ticks 16:41:25 did we leave out that vmware stuff 16:42:01 https://bugzilla.redhat.com/show_bug.cgi?id=975497 is actually ON_QA or better, but i think dgilmore was having second thoughts about including it 16:42:08 dgilmore: what did you decide about that in the end? 16:43:09 ? 16:43:10 https://bugzilla.redhat.com/show_bug.cgi?id=970030 seems like the latest incarnation of the bug for the cat's name 16:43:30 i'd like to get +1s on https://bugzilla.redhat.com/show_bug.cgi?id=962092 as it's a clear polish bug on the desktop 16:43:52 and https://bugzilla.redhat.com/show_bug.cgi?id=975649 is a bit bad if you happen to hit it. 16:46:36 if we want to go through these ones, let's do it 16:46:38 unsure why the cloud stuff is a blocker, I'm +1 to the cat's latest incarnation +1 on the clear polish bug and punt on the bad bit until the reporter provides the maintainers requested info 16:46:41 * jreznik has to leave soon 16:47:02 yeah, i know i suck. 16:47:08 fair enough on the needinfo. 16:47:09 ;) 16:47:25 the cloud stuff i was mostly leaving up to dgilmore's judgement since he's closer to it than any of us 16:47:55 what criteria does it violate? 16:48:03 these are FEs, no? 16:48:58 right, this is proposed FE, not blocker 16:49:03 #topic (970030) F19 release-name “Schrödinger’s Cat” shown as "Schrôdingerūs Cat" on the linux console 16:49:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=970030 16:49:08 aiui it's an inconvenience for the cloud images 16:49:08 #info Proposed Freeze Exceptions, kernel, NEW 16:49:23 +1, in general, to safe fixes that fix whatever the remaining goddamn cat problems are 16:50:00 if the cloud stuff is not violating any criteria it's splitting a package this late in the game hence it might potentially mess with size or break dependency's 16:50:16 how do you know it would be safe fix? /me is not going to read all that mess in the bug 16:50:23 i don't think cloud-utils is pulled into anything but the cloud images 16:50:28 jreznik: evaluate at point of inclusion 16:50:52 adamw: wfm, +1 16:51:05 * ignatenkobrain here. 16:51:07 +1 16:53:07 what exactly is the fix for this? 16:54:31 there's no fix now, as adamw said - evaluate at point of inclusion 16:54:47 I'm pretty sure we need to block the release regardless of what the fix is 16:55:34 we kinda cant release and present our release name all messed up to our users 16:56:03 proposed #agreed 970030 - AcceptedFreezeException - It would be good to have the release name show up correctly on consoles and a relatively safe, tested fix would be considered after freeze 16:56:14 ack 16:56:17 ack 16:56:27 ack 16:56:42 ack 16:58:00 #agreed 970030 - AcceptedFreezeException - It would be good to have the release name show up correctly on consoles and a relatively safe, tested fix would be considered after freeze 16:58:08 #topic (962092) [abrt] gnome-initial-setup-0.9-2.fc19: _clutter_stage_window_get_geometry: Process /usr/libexec/gnome-initial-setup-player was killed by signal 11 (SIGSEGV) 16:58:12 #link https://bugzilla.redhat.com/show_bug.cgi?id=962092 16:58:15 #info Proposed Freeze Exceptions, gnome-initial-setup, NEW 16:58:47 +1 obviously, it's an AVC that sometimes shows up after g-i-s, no super clear pattern 16:58:59 er, not avc, crash. 16:59:20 +1 as I mentioned earlier 16:59:22 +1 17:00:12 proposed #agreed 962092 - AcceptedFreezeException - While the exact cause of this isn't 100% clear right now, crashing on the introduction video is bad form and a relatively safe, tested fix would be considered after freeze 17:00:14 ack 17:00:48 ack 17:00:55 ack 17:01:16 #agreed 962092 - AcceptedFreezeException - While the exact cause of this isn't 100% clear right now, crashing on the introduction video is bad form and a relatively safe, tested fix would be considered after freeze 17:01:26 #topic (975497) subpackage growpart so the package doesn't pull unnecessary deps into cloud image 17:01:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=975497 17:01:31 #info Proposed Freeze Exceptions, cloud-utils, NEW 17:01:44 if dgilmore (or any other cloud folk) isn't around we should probably punt on this 17:01:47 unless someone wants to claim expertise 17:02:01 punt 17:02:07 it's just a change to lower deps... 17:02:20 * nirik doesn't really think it's that important either way in the end. 17:02:23 meh, it sounds like something that would be nice, but isn't likely to have a huge effect 17:03:05 I'm probably more -1 at this point unless it's a bigger deal than I'm understanding 17:03:16 me to 17:03:31 yeah, it's a bit of space, but there's no cloud image size target issue or anything. 17:04:20 we can -1 now and if there would be desire with arguments to make it FE, it could be reproposed 17:04:28 sure. 17:05:45 proposed #agreed 975497 - RejectedFreezeException - While it might be nice to have, this doesn't seem to be a big enough problem to justify changing things after freeze. However, if we've misunderstood something here, feel free to repropose as a freeze exception with more explanation on why this needs to change now. 17:05:53 ack 17:05:56 ack 17:06:10 ack 17:07:02 #agreed 975497 - RejectedFreezeException - While it might be nice to have, this doesn't seem to be a big enough problem to justify changing things after freeze. However, if we've misunderstood something here, feel free to repropose as a freeze exception with more explanation on why this needs to change now. 17:07:16 OK, any other proposed FEs? 17:08:49 the vmware one maybe? eh. 17:08:57 I can come with one or two, if you like :-) 17:09:32 * jreznik has to leave very soon, so would be nice to move on :) 17:10:02 the vmware one is a mess 17:10:17 jreznik: ok, I'll keep them for F20 ;-) 17:11:01 anaconda should only install it if on vmware ( if possible ) if not admins need to add to their ks or manually install it afterwards 17:12:10 that seems like a policy discussion. the vm agents group was pretty heavily discussed on devel@ before it happened 17:12:20 i'm not that comfortable with dictating package group policy via the bug/fe process 17:12:25 I don't see a fix proposed in the vmware bug, so let's move on to the accepted blockers 17:12:36 and what adamw said 17:13:14 adamw, throw back to fesco for approving it ;) but let's move on 17:13:21 #topic (975159) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 0: ordinal not in range(128) 17:13:24 #link https://bugzilla.redhat.com/show_bug.cgi?id=975159 17:13:26 #info Accepted Blocker, anaconda, MODIFIED 17:13:42 i think all the MODIFIED should be in TC6 17:14:00 let's skip those then 17:14:01 er, all the anaconda mODIFIED 17:14:15 looks like the anaconda update didn't get any bug IDs again 17:14:20 there's something wonky in the process there, bcl says 17:14:46 tflink: skip anything with fixed in 19.30.9, they're all in tc6 17:14:52 #topic (924162) A software selection with dependency errors is allowed to proceed if the dependency check runs twice 17:14:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=924162 17:14:58 #info Accepted Blocker, anaconda, NEW 17:15:12 looks like this one has ponged back to clumens 17:16:11 * adamw checking with him 17:16:22 well he atleast should be informed now ;) 17:17:04 looks like he stepped away 17:17:16 either way, it doesn't look like there's anything we need to do at this moment 17:17:16 * adamw has to jump in the shower, just realized i have a haircut in 1hr 17:17:19 yeah 17:17:42 #info devs are aware of the problem, progress is being made. nothing for us to do at the moment 17:17:56 #topic (958426) 19 Final TC1 x86_64 Desktop Live is oversized (larger than 1 GB) 17:17:59 #link https://bugzilla.redhat.com/show_bug.cgi?id=958426 17:18:02 #info Accepted Blocker, LiveCD, NEW 17:19:03 well, they're still working on this 17:19:16 and we accepted one FE to help with it 17:19:23 looks like the i386 media is OK, x86_64 is still oversized 17:20:07 #info for F19 final TC6: the i386 media is OK, x86_64 is still oversized 17:20:35 not sure there's anything for us to do here ATM, just keep an eye on things and make sure that progress keeps moving forward 17:20:45 #topic (964006) cloud-init hostname service failing on initial boot 17:20:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=964006 17:20:51 #info Accepted Blocker, selinux-policy, MODIFIED 17:21:13 sounds like a fix is available - waiting for a new spin to verify the fix 17:22:06 #info fix has been submitted, waiting for new spin to test the fix 17:22:40 #info TC6 cloud images are available to test the fix 17:23:23 yeah, this should be in tc56 17:23:25 tc6 17:23:46 * Viking-Ice hopes for tc56 NOT! :) 17:24:16 #info waiting for verification of fix right now 17:24:20 #topic (679486) Liveinst doesn't start if hostname changes 17:24:20 #link https://bugzilla.redhat.com/show_bug.cgi?id=679486 17:24:20 #info Accepted Blocker, xorg-x11-xauth, ASSIGNED 17:24:50 #info no movement on this since monday when it was accepted as a blocker 17:25:08 #info will be keeping an eye on progress 17:25:19 * jreznik sent heads up to ajax, t8m thinks it's not a pam issue but xauth one 17:25:23 OK, that's all of the non-VERIFIED accepted blockers for today 17:25:59 should we take on 974680 so we have a clean blocker bug proposal status til next week ? 17:26:51 it looks like a clear -1 as is 17:27:01 but there's this vague "There have been quite a few Intel HDA reports in the last 48 hours." from dan 17:27:10 which i should follow up with him' 17:27:25 Viking-Ice: you want to go over that bug again? 17:28:09 oh, it's changed recently 17:28:13 yeah, that sounds pretty -1 17:28:20 do we want to re-visit 17:28:20 ? 17:28:37 we could say -1 to the volume bug and file a separate one if there's some kind of new hda showstopper somewhere 17:29:52 wfm 17:29:57 #topic (974680) Intel HDA volume haywire after kernel-3.6.10 17:29:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=974680 17:29:58 #info Proposed Blocker, kernel, NEW 17:30:19 -1 17:30:43 -1 as for what's in the ticket right now 17:30:59 proposed #agreed 974680 - RejectedBlocker - The issue as described does not violate any of the F19 release criteria and thus is rejected as a release blocking bug for F19 final. If there is a new showstopper in Intel HDA, please file as a new bug. 17:31:08 ack 17:31:15 ack 17:31:33 * adamw out for a couple hours 17:31:38 will finish secretaryization when i'm back 17:31:44 ack 17:31:49 #agreed 974680 - RejectedBlocker - The issue as described does not violate any of the F19 release criteria and thus is rejected as a release blocking bug for F19 final. If there is a new showstopper in Intel HDA, please file as a new bug. 17:31:53 adamw: ok 17:32:00 I do believe that is it this time :) 17:32:04 anything else? 17:32:08 #topic Open Floor 17:32:23 wheee! 8.5 hours of review meeting for the week 17:32:26 fun times 17:33:02 if there's nothing else to cover today, I'll set the fuse for [0,5] minutes 17:33:07 it's still not f18 (at least now and I hope it will stay "calm") 17:33:18 jreznik, far from it 17:33:26 that was like 3+ meeting per week 17:33:32 each 3 hours or more 17:33:33 true, it hasn't been like this every week :) 17:33:54 thanks guys, I have to run now I'll be poking open blockers tomorrow 17:33:57 see you 17:34:14 Thanks for coming, everyone! 17:34:19 * tflink will send out minutes shortly 17:34:21 I'm still unhappy with how many Anaconda bugs we have hit this release but let's hop it gets smaller for F20 17:34:36 it's getting better, though :) 17:34:40 forward progress! 17:34:46 #endmeeting