16:24:46 #startmeeting F22-blocker-review 16:24:46 Meeting started Tue Apr 28 16:24:46 2015 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:24:46 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:24:46 #meetingname F22-blocker-review 16:24:46 The meeting name has been set to 'f22-blocker-review' 16:24:47 #topic Roll Call 16:24:56 * oddshocks present 16:25:01 looks like we have me, oddshocks, sgallagh, potty, possibly paragan 16:25:07 anyone else? danofsatx? 16:25:12 * satellit_e listening 16:25:33 I'm here, but muy busy 16:25:41 satellit: oops, sorry, missed ya 16:26:45 alrighty 16:26:59 #chair oddshocks sgallagh 16:26:59 Current chairs: adamw oddshocks sgallagh 16:27:09 Alright! Movin' up! 16:27:13 #topic Introduction 16:27:13 Why are we here? 16:27:13 #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:27:13 #info We'll be following the process outlined at: 16:27:13 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:27:15 #info The bugs up for review today are available at: 16:27:17 #link http://qa.fedoraproject.org/blockerbugs/current 16:27:19 #info The criteria for release blocking bugs can be found at: 16:27:21 #link https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria 16:27:23 #link https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria 16:27:25 #link https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria 16:27:29 #info 9 Proposed Blockers 16:27:29 #info 11 Accepted Blockers 16:27:31 #info 1 Proposed Freeze Exceptions 16:27:33 #info 3 Accepted Freeze Exceptions 16:28:25 who's willing to secretarialize? 16:30:05 * oddshocks happy to help, but not sure what to do 16:30:20 I'm usually a minor feature of this meeting :P 16:30:29 oddshocks: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Secretary_Duty 16:30:43 oddshocks: it's the thing where you add comments to the bugs and change their blocks / whiteboard fields to mark their status 16:30:53 That sounds easy enough. 16:30:58 always good to have more people able to do it...so if you don't mind giving it a shot that'd be great :) 16:31:06 #info oddshocks will secretarialize, adamw will check his work 16:31:08 So after the meeting, I can just use the logs to update the tickets? 16:31:26 oddshocks: yeah - some people like to do it as we go along, others prefer to do it from the logs after 16:31:59 you can ping in in #fedora-qa or privmsg if you have questions 16:32:03 I'll do it after, all at once if people don't mind 16:32:09 oddshocks: totally fine 16:32:11 #topic (1211122) No closest mirror can be found from behind a proxy 16:32:11 #link https://bugzilla.redhat.com/show_bug.cgi?id=1211122 16:32:12 #info Proposed Blocker, anaconda, POST 16:32:12 cool. 16:33:18 i for one still do not understand entirely what all was the problem here, but at least it seems like anaconda team actually found one. 16:33:45 Don't look at me :P 16:33:51 "Ends up the dnf config didn't have its proxy settings setup from inst.proxy, so it would only work if individual repos had a proxy set." 16:34:38 oh, of course! That thing! 16:34:39 so, as a fix is going in, the only significance of the blocker decision is what happens if the fix is busted. 16:34:42 =) 16:35:09 i'm probably borderline -1 on it, it's ugly but we could document various workarounds if we shipped with it broken 16:35:54 -1 from me 16:36:06 anyone else? 16:36:50 * oddshocks hopes there isn't a rule about the meeting being void if not enough people vote :P 16:38:27 there is, actually 16:38:35 if we have fewer than 3 people active we usually can it 16:38:45 let me poke folks :P 16:38:47 * adamw wonders where sgallagh and satellit_e and potty went 16:39:41 * oddshocks pinged a few channels 16:41:41 worst case we'll just do it tomorrow, some more folks will be available then 16:42:07 * oddshocks still happy to secretarize tomorrow 16:43:38 * adamw brb, call of nature, we'll see if anyone shows by then 16:43:44 sounds good 16:46:20 is still the meeting active? 16:46:34 potty: adamw just went to the bathroom. we were hoping someone like you would show up to make a solid 3 people voting :) 16:47:08 :) 16:52:24 potty: do you have a vote on this bug? 16:52:47 adamw: share me the link please 16:52:56 * potty disconnected abruptly a while ago 16:53:42 potty: https://bugzilla.redhat.com/show_bug.cgi?id=1211122 16:53:52 we have 2 -1s 16:53:56 * potty checking the bug 16:54:49 -1 16:55:33 proposed #agreed 1211122 - RejectedBlocker - this is a problem for those using proxies, but it would be sufficiently workaroundable. (In practice the fix is landing anyway.) 16:56:14 I'm late, but I would've been -1 also 16:57:34 ack/nack/patch ? 16:57:44 this is the part where you check the #agreed message and if it's OK you say ack. 16:57:54 if you think it should be changed say nack or patch (and provide a different version). 16:58:01 ack 16:58:05 ack 16:58:05 (we do this cos sometimes the message misses something or has a typo). 16:58:12 #agreed 1211122 - RejectedBlocker - this is a problem for those using proxies, but it would be sufficiently workaroundable. (In practice the fix is landing anyway.) 16:58:23 #topic (1211746) ValueError: new size is too large 16:58:23 #link https://bugzilla.redhat.com/show_bug.cgi?id=1211746 16:58:23 #info Proposed Blocker, anaconda, ASSIGNED 16:59:36 so presumably this happens if you try and resize an LV larger than it can be (when it should just be capped to the max possible size) 16:59:47 i can go +1 for this 17:01:36 +1 for me 17:01:54 +1 17:04:37 proposed #agreed 1211746 - AcceptedBlocker - accepted as a blocker as a violation of "When using the custom partitioning flow, the installer must be able to: Reject or disallow invalid disk and volume configurations without crashing." 17:05:05 ack 17:06:18 ack 17:07:59 #agreed 1211746 - AcceptedBlocker - accepted as a blocker as a violation of "When using the custom partitioning flow, the installer must be able to: Reject or disallow invalid disk and volume configurations without crashing." 17:08:07 #topic (1214441) btrfs raid1 fails to boot after successful installation 17:08:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=1214441 17:08:07 #info Proposed Blocker, anaconda, NEW 17:08:41 there's such a thing as btrfs RAID 1? 17:08:49 sure, btrfs does everything... 17:09:30 I mean, if it fails to boot under normal usage... +1 from me 17:10:33 sigh, cmurf screwed the bug up with a zillion reports of a different problem 17:10:38 let me try and unpick exactly what's broken here 17:11:07 encrypted swap? wtf? 17:11:28 so, it seems luks isn't involved, but installing from live is. 17:11:37 raid1 btrfs installed from live == bug. 17:11:55 Sorry folks, got pulled into a meeting. I'm back now. 17:12:39 i'm probably -1 on the grounds this is somewhat obscure stuff and there's an easy workaround (use a non-live installer). 17:12:49 i really need to get around to writing less catch-all final storage criteria. 17:13:44 I'll go -1 also, file as common bug. 17:13:54 Alright, that's fine with me 17:14:08 /me agrees. -1 17:14:08 * potty_ thinking... 17:14:55 ....but, cmurf then filed 1215839 for the grubby stuff he found in this one. 17:15:02 yeah, the grub stuff is a separate bug. 17:15:20 i'd vote +1 on that, but we'll get to it later. 17:15:45 groovy 17:15:46 well, rather - this bug is probably in grub or grubby, but the bug with the missing initramfs line that cmurf spent some time on is something different, and got split out. 17:16:00 unnerstoot 17:16:16 -1 17:18:38 proposed #agreed 1214441 - RejectedBlocker - this is in a fairly uncommonly used configuration (btrfs RAID) and there is a simple workaround (using the non-live installer). we believe documenting the workaround is sufficient to deal with this case. 17:18:50 ack 17:18:53 ack 17:18:53 oddshocks: if you can throw the 'CommonBugs' keyword at this bug when you update it that'd be good 17:19:01 ack 17:19:04 adamw: roger 17:19:09 #agreed 1214441 - RejectedBlocker - this is in a fairly uncommonly used configuration (btrfs RAID) and there is a simple workaround (using the non-live installer). we believe documenting the workaround is sufficient to deal with this case. 17:19:31 ack 17:19:34 #topic (1210047) [abrt] gnome-contacts: _g_log_abort(): gnome-contacts-search-provider killed by SIGTRAP 17:19:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=1210047 17:19:34 #info Proposed Blocker, gnome-contacts, NEW 17:20:33 +1 17:20:40 seems straightforward 17:20:46 I'm still not sure about this one 17:20:51 where's roshi to defend his bug? we kicked it last week waiting on him.... 17:20:56 so the criterion here is basically a polish one - we think it looks unfortunate if we know every system installed (with a particular image) will see a crash notificaiton (even if the practical consequences of the crash aren't too dire) 17:21:02 danofsatx: he's been on leave 17:21:10 roshi: oy 17:21:19 he was around earlier this morning, but... 17:21:22 oddshocks: it's not really straightforward because it doesn't always happen 17:21:23 i know, jusy giving him a hard time ;) 17:21:35 adamw: ahh. I didn't read well enough ;) 17:21:50 the decision's clear in the case where a crash *always* happens but we never really set a threshold - what if it happens 90% of the time? 50%? 10%? 17:22:13 from the upstream report it looks like it's been possible to hit this crash at least since f20 (though i don't know if you'd ever see it right after install on f20) 17:22:38 my personal experience has been that i don't see this one very often so i'm inclined to -1, but of course others may be seeing it more frequently 17:23:02 I haven't experienced that 17:23:18 I haven't seen it, though I haven't done a fresh install lately 17:23:29 I've done a few fresh installs lately and have not hit this 17:23:55 Honestly, I'm -1 on this unless it starts becoming more prevalent in the release candidates 17:24:02 -1 17:24:37 I'll revise to -1 17:24:43 and yeah, frequency of encounter is subjective, but this one doesn't feel important enough. 17:25:02 Especially since the only obvious end-user experience is a spurious crash notification and no obvious functionality loss 17:25:30 proposed #agreed 1210047 - RejectedBlocker - this does not seem to be occurring frequently enough (given the data we have) to be a blocker (the point of the criterion is not to look unprofessional by triggering crashes on all installs; this seems to happen only rarely) 17:26:07 ack 17:26:26 ack 17:26:28 ack 17:26:56 #agreed 1210047 - RejectedBlocker - this does not seem to be occurring frequently enough (given the data we have) to be a blocker (the point of the criterion is not to look unprofessional by triggering crashes on all installs; this seems to happen only rarely) 17:27:28 #topic (1211948) Help with packagekit api 17:27:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1211948 17:27:29 #info Proposed Blocker, gnome-software, NEW 17:27:54 this is the one paragan proposed 17:28:17 it seems to be a problem with cases where we have apps that want to trigger Software to install language-related addons 17:28:34 i'm probably -1 as it doesn't really hit any of the criteria/critpath requirements and can be fixed with an update 17:28:40 unless we want these features to work in the lives... 17:29:27 -1 17:29:36 Am I reading it correctly that you cannot install new input methods on the live environment? 17:29:47 I dont see it ASAP necessary 17:30:06 -1 17:30:52 I guess I'd probably give this a Freeze Exception if we were in freeze, but I'm -1 on blocker status 17:30:59 -1 17:31:04 sgallagh: i'm not entirely sure 17:31:21 sgallagh: it says "input method setup" but then it also says "for dictionary packages installation"... 17:31:54 FE is an interesting question but we can tackle it if it becomes necessary 17:32:45 proposed #agreed 1211948 - RejectedBlocker - this is certainly a significant bug that should be treated with priority, but it does not seem to be worth blocking the release for. It could be satisfactorily fixed with a post-release update if it cannot be fixed before release. If a fix appears after the Final freeze we would be willing to consider freeze exception status. 17:32:57 ack 17:33:02 ack 17:33:36 ack 17:33:58 ack 17:34:13 #agreed 1211948 - RejectedBlocker - this is certainly a significant bug that should be treated with priority, but it does not seem to be worth blocking the release for. It could be satisfactorily fixed with a post-release update if it cannot be fixed before release. If a fix appears after the Final freeze we would be willing to consider freeze exception status. 17:34:23 #topic (1215839) kernel panic on first boot of newly installed system, missing initrd line in grub.cfg 17:34:24 #link https://bugzilla.redhat.com/show_bug.cgi?id=1215839 17:34:24 #info Proposed Blocker, grubby, NEW 17:35:04 so i'm definitely +1 to this one - it breaks all live installs. 17:35:11 ah. +1 17:35:14 might break non-live installs too, i don't recall whether it does or not off the top of my head. 17:35:17 +1 17:36:02 proposed #agreed 1215839 - AcceptedBlocker - violates e.g. "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." 17:36:06 +1 17:36:25 ack 17:36:27 ack 17:36:46 +1 and ack 17:36:49 ack 17:38:14 #agreed 1215839 - AcceptedBlocker - violates e.g. "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." 17:38:21 #topic (1211978) mock does not use "yum-deprecated" if yum >= 3.4.3-505 is installed 17:38:21 #link https://bugzilla.redhat.com/show_bug.cgi?id=1211978 17:38:22 #info Proposed Blocker, mock, MODIFIED 17:39:19 i don't think this needs to block the release, afaik mock isn't involved in any release critical / critpath stuff 17:39:41 I'll defer to releng on this one. I don't understand the path. 17:40:10 -1 17:40:28 -1 17:40:40 -1 17:41:13 It doesn't sound like any part of mock that is used by Koji is affected. 17:41:44 if it were we'd probably know about it already. 17:41:56 it's also easy to fix in local config, so maybe they are affected and we've just done that 17:42:05 i'll check with releng just to be safe, but for now let's go with rejected 17:42:11 /me nods 17:42:41 adamw: it will actually break composing once we update the compose box 17:42:48 proposed #agreed 1211978 - RejectedBlocker - we're not aware of any case where this bug affects release critical or critpath stuff, so it could be fixed as a regular update if necessary. 17:43:13 ack 17:43:15 adamw: because releasever is not defined 17:43:30 dgilmore: It sounds like it can be worked around by specifying 'yum-deprecated' as the yum-command 17:43:44 ack 17:44:25 dgilmore: so will it be OK to set the configuration on the affected boxes, or do we need to treat this as a blocker so it's fixed in the package? 17:44:38 sgallagh: sure. it will require unknown changes 17:45:26 adamw: we can do either, I would prefer it fixed inpackages so we do not forget it or forget to undo it for f23. but I can cope with either 17:46:07 ok. so, still doesn't seem like a blocker. 17:46:12 #agreed 1211978 - RejectedBlocker - we're not aware of any case where this bug affects release critical or critpath stuff, so it could be fixed as a regular update if necessary. 17:46:26 only two more to go! 17:46:27 #topic (1160424) MDRaidError: name_from_md_node(md126p1) failed 17:46:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=1160424 17:46:27 #info Proposed Blocker, python-blivet, ASSIGNED 17:46:27 adamw: I think that's incorrect 17:46:40 sgallagh: the text? 17:46:46 The reasoning for the previous RejectedBlocker seems to disagree with what dgilmore was just saying. 17:47:01 sgallagh: do you care enough to make me count #undos and confuse everyone? :) 17:47:12 We're aware of effects on release stuff, we just think it's possible to work around 17:48:05 adamw: No, I suppose not 17:48:09 k, sorry 17:48:17 you're right, but it doesn't seem super significant 17:49:22 from last week: 17:49:23 "It was decided to delay the decision by one week - this is at least potentially a blocker, but it depends how commonly it occurs (it does not affect *all* firmware RAID installs). New information seems to be arriving quite often, so we will check in next week and see if this is clearer then." 17:49:42 so since last week...ian's uploaded two batches of logs, and that's about it 17:49:53 we haven't heard more from dlehman (except the comment which was apparently a mistake) 17:50:02 -1 17:50:17 -1 17:51:32 -1 17:51:44 adamw: I really have no idea on that one. I still think something other than anaconda/blivet is deactivating his array, but I have no idea what or exactly when. 17:52:01 i'm not sure i'm ready for a -1, but...hard to know what to do 17:52:37 I'd prefer to leave this one undecided for now 17:52:57 Maybe make a note that the impact is concerning and that we'd appreciate investigation 17:53:28 we have 4 dupes of this bug, so people are certainly hitting it 17:53:38 sgallagh: dlehman's been investigating it, he just isn't finding much :) 17:54:00 adamw: Did you order that fwraid hardware? :) 17:55:21 sgallagh: i've always had fwraid hardward 17:55:30 sgallagh: i hit this once, but then after wiping the array i didn't hit it again 17:55:44 /me nods. I'm reading #anaconda as well 17:56:26 so i'd vote to punt this a bit more 17:56:35 +1 17:56:35 though in the end we're probably just gonna have to take a guess 17:56:37 (punt) 17:56:53 adamw: Well, I'm of the opinion that if we're on the fence, the answer is "not a blocker" 17:57:17 If no one can figure out why it happens, blocking the release on it seems a little masochistic 17:58:21 true 17:58:36 what do the folks who voted -1 think - are you ok with punting or would you rather -1 now? 17:59:03 * potty thinking 17:59:18 I think I'm leaning towards -1 with the option of re-proposing if more information comes up 17:59:58 I'll remain -1 18:01:37 ok, so we seem to have a -1 consensus 18:02:49 proposed #agreed 1160424 - RejectedBlocker - this is a worrying bug but so far it has been difficult to pin down and appears to only affect RAID sets in specific states. If more details emerge that indicate it is very commonly encountered by those attempting to install on firmware RAID, we will reconsider it. 18:03:04 ack 18:03:35 ack 18:03:44 ack 18:05:17 #agreed 1160424 - RejectedBlocker - this is a worrying bug but so far it has been difficult to pin down and appears to only affect RAID sets in specific states. If more details emerge that indicate it is very commonly encountered by those attempting to install on firmware RAID, we will reconsider it. 18:05:55 #topic (1214241) KeyError: 'fedora-pool' 18:05:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=1214241 18:05:56 #info Proposed Blocker, python-blivet, POST 18:08:49 +1 per #c15 and #c16 18:09:03 * potty is checking 18:09:25 well, hum 18:09:54 there's one question: when he says it happens 'randomly' does it mean if you reboot a couple of times it'll work? or just if you're one of the unlucky ones, every attempt will fail? 18:10:04 i'd probably be +1 for the latter, -1 blocker +1 FE for the former 18:10:07 adamw: It sounds like the latter 18:10:21 yeah, if it's based on python sorting 18:10:23 Since he says it has to do with dict key sorting 18:10:31 so, on that basis +1 18:10:39 Which is always consistent, though rarely to a human's way of thinking 18:10:53 It is a dict problem, +1 18:11:11 Also it's already fixed, so I can't see this not ending up in a regular update before Freeze anyway. 18:11:15 So +1 rubber stamp 18:12:01 heh 18:12:23 proposed #agreed 1214241 - AcceptedBlocker - violates "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." 18:12:43 ack 18:12:46 ack 18:13:45 #agreed 1214241 - AcceptedBlocker - violates "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." 18:13:52 alrighty, that's all the proposed blockers 18:14:56 do we want to blow through the accepted blockers? 18:15:04 i'll skip the several that are awaiting karam 18:15:05 karma 18:15:21 Ok 18:16:29 adamw: Just so we're clear, what's the purpose of doing that? 18:16:51 Are we thinking of dropping them, or just checking to see that they're under way, or what? 18:17:05 usually the latter 18:17:07 the former is possible 18:17:27 #info moving on to accepted blocker review 18:17:29 #topic (1212206) System doesn't boot with LVM data volume on iSCSI 18:17:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1212206 18:17:29 #info Accepted Blocker, anaconda, MODIFIED 18:17:43 so this one i think should actually be ON_QA in the new anaconda update, it just got missed - i've poked sbueno\ 18:18:21 #info this is probably fixed in the pending anaconda update (and hence will be in Final TC1), the update just needs editing to list it 18:18:28 #topic (1209941) upgraded system does not reboot automatically, ctrl+alt+del is needed: Failed unmounting /sysroot/proc 18:18:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=1209941 18:18:28 #info Accepted Blocker, fedup-dracut, NEW 18:21:03 so lots of people have hit this, but i don't think we yet have much from wwoods 18:21:25 we should probably post a ping to wwoods for data 18:22:21 I hit this bug on a Test Day. 18:23:08 And it was a fresh fedup upgrade. 18:23:31 * satellit /me I also saw this in f21-22 fedup testing 18:23:44 yeah, i've hit it plenty of times too 18:24:02 #info lots of activity from reporters here, but little from the developer 18:24:13 #action secretary to post a comment pinging the dev and asking for status 18:24:32 #topic (1166650) [abrt] liveusb-creator: connection.py:651:call_blocking:DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist 18:24:33 #link https://bugzilla.redhat.com/show_bug.cgi?id=1166650 18:24:33 #info Accepted Blocker, liveusb-creator, NEW 18:25:59 so again, no input from the dev yet - we need to ping and find out how likely it is this is going to get fixed in time 18:26:24 anyone have any more on this one? 18:26:49 No 18:27:55 does terminal liveusb-creator --reset-mbr work 18:29:21 from the comments, i'd think probably it's affected. 18:30:09 * satellit_e need to test....been a week since I have used it 18:30:14 #info we haven't yet heard from the developer about this one 18:30:21 #action secretary to post a comment requesting status from the developer 18:30:31 #topic (1206760) Plasma desktop doesn't notify for available updates 18:30:32 #link https://bugzilla.redhat.com/show_bug.cgi?id=1206760 18:30:32 #info Accepted Blocker, plasma-pk-updates, ASSIGNED 18:30:41 I don't think any action's required here, we know the KDE team's well aware and working on it 18:31:30 * satellit_e just tested latest KDE Plasma plasma-pk-updates is present but not selected once selected it works 18:32:32 #info KDE team is aware and actively working on this bug, no action necessary 18:32:40 #topic (1200161) Non-Fatal SELINUX Faults exist during bootup of 22_Alpha_RC3 18:32:40 #link https://bugzilla.redhat.com/show_bug.cgi?id=1200161 18:32:40 #info Accepted Blocker, rng-tools, NEW 18:33:40 this is a pretty old one 18:33:43 it may well have gone away in the mean time 18:35:09 * mclasen notes that it might be nice to make it use udisks2 while we're at it 18:35:11 hum, so if i look for execmod denials on rngd, i do find one that's still open (with a bunch of dupes): 18:35:12 https://bugzilla.redhat.com/show_bug.cgi?id=1172235 18:35:41 mclasen: wrong channel? 18:35:55 no, commenting on that liveusb-creator bug a few lines up 18:35:58 mclasen: ah 18:36:04 huh. that's odd 18:36:17 https://bugzilla.redhat.com/show_bug.cgi?id=1181308 is the 'parent' execmod-on-rngd bug 18:36:26 it's closed as a dupe of 1172235 18:36:31 but 1172235 doesn't seem to have anything to do with it 18:36:34 i wonder if that was a typo 18:39:12 let's say, we need to know if there's still an outstanding issue here 18:39:18 #info this is fairly old and may well be fixed already 18:39:38 #action secretary to ask reporter whether the first AVC is still a problem on 22 Beta or Final TC1 18:39:58 #topic (1190377) SELinux is preventing polkitd from 'read' accesses on the lnk_file localtime. 18:39:58 #link https://bugzilla.redhat.com/show_bug.cgi?id=1190377 18:39:58 #info Accepted Blocker, systemd, NEW 18:42:06 so this is the one which occurs "I've only seen this on i386 and only when g-i-s is used to create the user" 18:44:44 seems like the devs are active on this one, so probably doesn't need any action 18:44:55 #info this bug seems fairly active with input from devs and testers, no action needed 18:45:21 #topic (1200559) [abrt] totem: browse_cb(): totem killed by SIGABRT 18:45:21 #link https://bugzilla.redhat.com/show_bug.cgi?id=1200559 18:45:22 #info Accepted Blocker, totem, NEW 18:47:27 we probably need to ping the maintainer here to make sure he's aware it's a blocker and needs priority 18:48:46 * oddshocks steps away for a few moments 18:49:32 this is the last bug, btw 18:49:46 #info no response from the developer yet 18:50:11 #action secretary to post comment asking dev for status 18:51:03 okey dokey, that's all the blockers 18:51:09 #topic Open floor 18:51:42 any other business, folks? 18:51:51 or is everyone dying to escape? :) 18:52:36 nah, i escaped and came back, then escape and finally came back 18:54:10 * roshi is finally here 18:54:19 saw a ping, reading backscroll now' 18:54:33 potty: you clearly don't quite understand this 'escaping' concept :) 18:54:47 :( 18:55:03 roshi: we were waiting for your input on https://bugzilla.redhat.com/show_bug.cgi?id=1210047 18:55:30 but then we decided we hated you so we'd vote -1 18:55:45 that's what happened, right folks? pretty sure that's what happened. 18:56:48 sounds like it's gone 18:56:53 * roshi had forgotten about this bug 18:57:14 if you didn't see it on i386, then I'd say it's gone 18:58:01 hum, i might've been on x86_64 18:58:07 guess we can try it again 18:58:23 well, like the 5 selinux denials bug - I *only* saw this on i386 18:58:35 it's more a case of it not always happening rather than it being gone, btw. the bug doesn't seem to be fixed upstream, but we were figuring it doesn't always happen. 18:58:43 some kinda timeout seems to be involved 18:58:54 anyhow, if you can check it out and see if it's reliably reproducible on i386 we can reconisder... 18:59:46 sure thing 18:59:48 anything else, folks? 18:59:51 RC3 is gold, right? 19:00:00 #action roshi to re-check #1210047 on current i386 images 19:00:01 or do we have a final TC out? 19:00:04 roshi: yeah, and we have nightlies 19:00:11 TC1 will come later today 19:00:24 I'll get to it after that then 19:01:23 kk 19:01:41 alrighty, we're at the time limit and it sounds like there's nothing else to discuss, so let's close it out! 19:01:47 thanks a lot for coming folks 19:05:37 #endmeeting