16:24:46 <adamw> #startmeeting F22-blocker-review
16:24:46 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:24:46 <adamw> #meetingname F22-blocker-review
16:24:46 <zodbot> The meeting name has been set to 'f22-blocker-review'
16:24:47 <adamw> #topic Roll Call
16:24:56 * oddshocks present
16:25:01 <adamw> looks like we have me, oddshocks, sgallagh, potty, possibly paragan
16:25:07 <adamw> anyone else? danofsatx?
16:25:12 * satellit_e listening
16:25:33 <danofsatx> I'm here, but muy busy
16:25:41 <adamw> satellit: oops, sorry, missed ya
16:26:45 <adamw> alrighty
16:26:59 <adamw> #chair oddshocks sgallagh
16:26:59 <zodbot> Current chairs: adamw oddshocks sgallagh
16:27:09 <oddshocks> Alright! Movin' up!
16:27:13 <adamw> #topic Introduction
16:27:13 <adamw> Why are we here?
16:27:13 <adamw> #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 <adamw> #info We'll be following the process outlined at:
16:27:13 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:27:15 <adamw> #info The bugs up for review today are available at:
16:27:17 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:27:19 <adamw> #info The criteria for release blocking bugs can be found at:
16:27:21 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria
16:27:23 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria
16:27:25 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria
16:27:29 <adamw> #info 9 Proposed Blockers
16:27:29 <adamw> #info 11 Accepted Blockers
16:27:31 <adamw> #info 1 Proposed Freeze Exceptions
16:27:33 <adamw> #info 3 Accepted Freeze Exceptions
16:28:25 <adamw> who's willing to secretarialize?
16:30:05 * oddshocks happy to help, but not sure what to do
16:30:20 <oddshocks> I'm usually a minor feature of this meeting :P
16:30:29 <adamw> oddshocks: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Secretary_Duty
16:30:43 <adamw> 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 <oddshocks> That sounds easy enough.
16:30:58 <adamw> 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 <adamw> #info oddshocks will secretarialize, adamw will check his work
16:31:08 <oddshocks> So after the meeting, I can just use the logs to update the tickets?
16:31:26 <adamw> oddshocks: yeah - some people like to do it as we go along, others prefer to do it from the logs after
16:31:59 <adamw> you can ping in in #fedora-qa or privmsg if you have questions
16:32:03 <oddshocks> I'll do it after, all at once if people don't mind
16:32:09 <adamw> oddshocks: totally fine
16:32:11 <adamw> #topic (1211122) No closest mirror can be found from behind a proxy
16:32:11 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1211122
16:32:12 <adamw> #info Proposed Blocker, anaconda, POST
16:32:12 <oddshocks> cool.
16:33:18 <adamw> 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 <oddshocks> Don't look at me :P
16:33:51 <adamw> "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 <oddshocks> oh, of course! That thing!
16:34:39 <adamw> 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 <adamw> =)
16:35:09 <adamw> 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 <oddshocks> -1 from me
16:36:06 <adamw> 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 <adamw> there is, actually
16:38:35 <adamw> if we have fewer than 3 people active we usually can it
16:38:45 <oddshocks> 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 <adamw> 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 <oddshocks> sounds good
16:46:20 <potty> is still the meeting active?
16:46:34 <oddshocks> 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 <potty> :)
16:52:24 <adamw> potty: do you have a vote on this bug?
16:52:47 <potty> adamw: share me the link please
16:52:56 * potty disconnected abruptly a while ago
16:53:42 <oddshocks> potty: https://bugzilla.redhat.com/show_bug.cgi?id=1211122
16:53:52 <oddshocks> we have 2 -1s
16:53:56 * potty checking the bug
16:54:49 <potty> -1
16:55:33 <adamw> 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 <danofsatx> I'm late, but I would've been -1 also
16:57:34 <adamw> ack/nack/patch ?
16:57:44 <adamw> this is the part where you check the #agreed message and if it's OK you say ack.
16:57:54 <adamw> if you think it should be changed say nack or patch (and provide a different version).
16:58:01 <oddshocks> ack
16:58:05 <potty> ack
16:58:05 <adamw> (we do this cos sometimes the message misses something or has a typo).
16:58:12 <adamw> #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 <adamw> #topic (1211746) ValueError: new size is too large
16:58:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1211746
16:58:23 <adamw> #info Proposed Blocker, anaconda, ASSIGNED
16:59:36 <adamw> 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 <adamw> i can go +1 for this
17:01:36 <potty> +1 for me
17:01:54 <oddshocks> +1
17:04:37 <adamw> 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 <oddshocks> ack
17:06:18 <potty_> ack
17:07:59 <adamw> #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 <adamw> #topic (1214441) btrfs raid1 fails to boot after successful installation
17:08:07 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1214441
17:08:07 <adamw> #info Proposed Blocker, anaconda, NEW
17:08:41 <danofsatx> there's such a thing as btrfs RAID 1?
17:08:49 <adamw> sure, btrfs does everything...
17:09:30 <oddshocks> I mean, if it fails to boot under normal usage... +1 from me
17:10:33 <adamw> sigh, cmurf screwed the bug up with a zillion reports of a different problem
17:10:38 <adamw> let me try and unpick exactly what's broken here
17:11:07 <danofsatx> encrypted swap? wtf?
17:11:28 <adamw> so, it seems luks isn't involved, but installing from live is.
17:11:37 <adamw> raid1 btrfs installed from live == bug.
17:11:55 <sgallagh> Sorry folks, got pulled into a meeting. I'm back now.
17:12:39 <adamw> 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 <adamw> i really need to get around to writing less catch-all final storage criteria.
17:13:44 <danofsatx> I'll go -1 also, file as common bug.
17:13:54 <oddshocks> Alright, that's fine with me
17:14:08 <sgallagh> /me agrees. -1
17:14:08 * potty_ thinking...
17:14:55 <danofsatx> ....but, cmurf then filed 1215839 for the grubby stuff he found in this one.
17:15:02 <adamw> yeah, the grub stuff is a separate bug.
17:15:20 <adamw> i'd vote +1 on that, but we'll get to it later.
17:15:45 <oddshocks> groovy
17:15:46 <adamw> 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 <danofsatx> unnerstoot
17:16:16 <potty_> -1
17:18:38 <adamw> 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 <oddshocks> ack
17:18:53 <danofsatx> ack
17:18:53 <adamw> oddshocks: if you can throw the 'CommonBugs' keyword at this bug when you update it that'd be good
17:19:01 <sgallagh> ack
17:19:04 <oddshocks> adamw: roger
17:19:09 <adamw> #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 <potty_> ack
17:19:34 <adamw> #topic (1210047) [abrt] gnome-contacts: _g_log_abort(): gnome-contacts-search-provider killed by SIGTRAP
17:19:34 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1210047
17:19:34 <adamw> #info Proposed Blocker, gnome-contacts, NEW
17:20:33 <oddshocks> +1
17:20:40 <oddshocks> seems straightforward
17:20:46 <sgallagh> I'm still not sure about this one
17:20:51 <danofsatx> where's roshi to defend his bug? we kicked it last week waiting on him....
17:20:56 <adamw> 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 <adamw> danofsatx: he's been on leave
17:21:10 <adamw> roshi: oy
17:21:19 <oddshocks> he was around earlier this morning, but...
17:21:22 <adamw> oddshocks: it's not really straightforward because it doesn't always happen
17:21:23 <danofsatx> i know, jusy giving him a hard time ;)
17:21:35 <oddshocks> adamw: ahh. I didn't read well enough ;)
17:21:50 <adamw> 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 <adamw> 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 <adamw> 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 <potty_> I haven't experienced that
17:23:18 <oddshocks> I haven't seen it, though I haven't done a fresh install lately
17:23:29 <sgallagh> I've done a few fresh installs lately and have not hit this
17:23:55 <sgallagh> Honestly, I'm -1 on this unless it starts becoming more prevalent in the release candidates
17:24:02 <potty_> -1
17:24:37 <oddshocks> I'll revise to -1
17:24:43 <sgallagh> and yeah, frequency of encounter is subjective, but this one doesn't feel important enough.
17:25:02 <sgallagh> Especially since the only obvious end-user experience is a spurious crash notification and no obvious functionality loss
17:25:30 <adamw> 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 <potty_> ack
17:26:26 <oddshocks> ack
17:26:28 <sgallagh> ack
17:26:56 <adamw> #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 <adamw> #topic (1211948) Help with packagekit api
17:27:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1211948
17:27:29 <adamw> #info Proposed Blocker, gnome-software, NEW
17:27:54 <adamw> this is the one paragan proposed
17:28:17 <adamw> 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 <adamw> 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 <adamw> unless we want these features to work in the lives...
17:29:27 <potty_> -1
17:29:36 <sgallagh> Am I reading it correctly that you cannot install new input methods on the live environment?
17:29:47 <potty_> I dont see it ASAP necessary
17:30:06 <danofsatx> -1
17:30:52 <sgallagh> 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 <oddshocks> -1
17:31:04 <adamw> sgallagh: i'm not entirely sure
17:31:21 <adamw> sgallagh: it says "input method setup" but then it also says "for dictionary packages installation"...
17:31:54 <adamw> FE is an interesting question but we can tackle it if it becomes necessary
17:32:45 <adamw> 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 <oddshocks> ack
17:33:02 <sgallagh> ack
17:33:36 <potty_> ack
17:33:58 <danofsatx> ack
17:34:13 <adamw> #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 <adamw> #topic (1215839) kernel panic on first boot of newly installed system, missing initrd line in grub.cfg
17:34:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1215839
17:34:24 <adamw> #info Proposed Blocker, grubby, NEW
17:35:04 <adamw> so i'm definitely +1 to this one - it breaks all live installs.
17:35:11 <oddshocks> ah. +1
17:35:14 <adamw> might break non-live installs too, i don't recall whether it does or not off the top of my head.
17:35:17 <danofsatx> +1
17:36:02 <adamw> 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 <potty_> +1
17:36:25 <potty_> ack
17:36:27 <oddshocks> ack
17:36:46 <sgallagh> +1 and ack
17:36:49 <danofsatx> ack
17:38:14 <adamw> #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 <adamw> #topic (1211978) mock does not use "yum-deprecated" if yum >= 3.4.3-505 is installed
17:38:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1211978
17:38:22 <adamw> #info Proposed Blocker, mock, MODIFIED
17:39:19 <adamw> i don't think this needs to block the release, afaik mock isn't involved in any release critical / critpath stuff
17:39:41 <danofsatx> I'll defer to releng on this one. I don't understand the path.
17:40:10 <potty_> -1
17:40:28 <sgallagh> -1
17:40:40 <oddshocks> -1
17:41:13 <sgallagh> It doesn't sound like any part of mock that is used by Koji is affected.
17:41:44 <adamw> if it were we'd probably know about it already.
17:41:56 <adamw> it's also easy to fix in local config, so maybe they are affected and we've just done that
17:42:05 <adamw> i'll check with releng just to be safe, but for now let's go with rejected
17:42:11 <sgallagh> /me nods
17:42:41 <dgilmore> adamw: it will actually break composing once we update the compose box
17:42:48 <adamw> 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 <oddshocks> ack
17:43:15 <dgilmore> adamw: because releasever is not defined
17:43:30 <sgallagh> dgilmore: It sounds like it can be worked around by specifying 'yum-deprecated' as the yum-command
17:43:44 <potty_> ack
17:44:25 <adamw> 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 <dgilmore> sgallagh: sure. it will require unknown changes
17:45:26 <dgilmore> 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 <adamw> ok. so, still doesn't seem like a blocker.
17:46:12 <adamw> #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 <adamw> only two more to go!
17:46:27 <adamw> #topic (1160424) MDRaidError: name_from_md_node(md126p1) failed
17:46:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1160424
17:46:27 <adamw> #info Proposed Blocker, python-blivet, ASSIGNED
17:46:27 <sgallagh> adamw: I think that's incorrect
17:46:40 <adamw> sgallagh: the text?
17:46:46 <sgallagh> The reasoning for the previous RejectedBlocker seems to disagree with what dgilmore was just saying.
17:47:01 <adamw> sgallagh: do you care enough to make me count #undos and confuse everyone? :)
17:47:12 <sgallagh> We're aware of effects on release stuff, we just think it's possible to work around
17:48:05 <sgallagh> adamw: No, I suppose not
17:48:09 <adamw> k, sorry
17:48:17 <adamw> you're right, but it doesn't seem super significant
17:49:22 <adamw> from last week:
17:49:23 <adamw> "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 <adamw> so since last week...ian's uploaded two batches of logs, and that's about it
17:49:53 <adamw> we haven't heard more from dlehman (except the comment which was apparently a mistake)
17:50:02 <danofsatx> -1
17:50:17 <potty_> -1
17:51:32 <oddshocks> -1
17:51:44 <adamw> <dlehman> 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 <adamw> i'm not sure i'm ready for a -1, but...hard to know what to do
17:52:37 <sgallagh> I'd prefer to leave this one undecided for now
17:52:57 <sgallagh> Maybe make a note that the impact is concerning and that we'd appreciate investigation
17:53:28 <adamw> we have 4 dupes of this bug, so people are certainly hitting it
17:53:38 <adamw> sgallagh: dlehman's been investigating it, he just isn't finding much :)
17:54:00 <sgallagh> adamw: Did you order that fwraid hardware? :)
17:55:21 <adamw> sgallagh: i've always had fwraid hardward
17:55:30 <adamw> sgallagh: i hit this once, but then after wiping the array i didn't hit it again
17:55:44 <sgallagh> /me nods. I'm reading #anaconda as well
17:56:26 <adamw> so i'd vote to punt this a bit more
17:56:35 <sgallagh> +1
17:56:35 <adamw> though in the end we're probably just gonna have to take a guess
17:56:37 <sgallagh> (punt)
17:56:53 <sgallagh> adamw: Well, I'm of the opinion that if we're on the fence, the answer is "not a blocker"
17:57:17 <sgallagh> If no one can figure out why it happens, blocking the release on it seems a little masochistic
17:58:21 <adamw> true
17:58:36 <adamw> 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 <sgallagh> I think I'm leaning towards -1 with the option of re-proposing if more information comes up
17:59:58 <potty> I'll remain -1
18:01:37 <adamw> ok, so we seem to have a -1 consensus
18:02:49 <adamw> 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 <potty> ack
18:03:35 <sgallagh> ack
18:03:44 <oddshocks> ack
18:05:17 <adamw> #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 <adamw> #topic (1214241) KeyError: 'fedora-pool'
18:05:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1214241
18:05:56 <adamw> #info Proposed Blocker, python-blivet, POST
18:08:49 <adamw> +1 per #c15 and #c16
18:09:03 * potty is checking
18:09:25 <adamw> well, hum
18:09:54 <adamw> 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 <adamw> i'd probably be +1 for the latter, -1 blocker +1 FE for the former
18:10:07 <sgallagh> adamw: It sounds like the latter
18:10:21 <adamw> yeah, if it's based on python sorting
18:10:23 <sgallagh> Since he says it has to do with dict key sorting
18:10:31 <adamw> so, on that basis +1
18:10:39 <sgallagh> Which is always consistent, though rarely to a human's way of thinking
18:10:53 <potty> It is a dict problem, +1
18:11:11 <sgallagh> Also it's already fixed, so I can't see this not ending up in a regular update before Freeze anyway.
18:11:15 <sgallagh> So +1 rubber stamp
18:12:01 <adamw> heh
18:12:23 <adamw> 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 <potty> ack
18:12:46 <sgallagh> ack
18:13:45 <adamw> #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 <adamw> alrighty, that's all the proposed blockers
18:14:56 <adamw> do we want to blow through the accepted blockers?
18:15:04 <adamw> i'll skip the several that are awaiting karam
18:15:05 <adamw> karma
18:15:21 <potty> Ok
18:16:29 <sgallagh> adamw: Just so we're clear, what's the purpose of doing that?
18:16:51 <sgallagh> Are we thinking of dropping them, or just checking to see that they're under way, or what?
18:17:05 <adamw> usually the latter
18:17:07 <adamw> the former is possible
18:17:27 <adamw> #info moving on to accepted blocker review
18:17:29 <adamw> #topic (1212206) System doesn't boot with LVM data volume on iSCSI
18:17:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1212206
18:17:29 <adamw> #info Accepted Blocker, anaconda, MODIFIED
18:17:43 <adamw> 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 <adamw> #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 <adamw> #topic (1209941) upgraded system does not reboot automatically, ctrl+alt+del is needed: Failed unmounting /sysroot/proc
18:18:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1209941
18:18:28 <adamw> #info Accepted Blocker, fedup-dracut, NEW
18:21:03 <adamw> so lots of people have hit this, but i don't think we yet have much from wwoods
18:21:25 <adamw> we should probably post a ping to wwoods for data
18:22:21 <potty> I hit this bug on a Test Day.
18:23:08 <potty> And it was a fresh fedup upgrade.
18:23:31 * satellit /me I also saw this in f21-22 fedup testing
18:23:44 <adamw> yeah, i've hit it plenty of times too
18:24:02 <adamw> #info lots of activity from reporters here, but little from the developer
18:24:13 <adamw> #action secretary to post a comment pinging the dev and asking for status
18:24:32 <adamw> #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 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1166650
18:24:33 <adamw> #info Accepted Blocker, liveusb-creator, NEW
18:25:59 <adamw> 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 <adamw> anyone have any more on this one?
18:26:49 <potty> No
18:27:55 <satellit_e> does terminal liveusb-creator --reset-mbr work
18:29:21 <adamw> 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 <adamw> #info we haven't yet heard from the developer about this one
18:30:21 <adamw> #action secretary to post a comment requesting status from the developer
18:30:31 <adamw> #topic (1206760) Plasma desktop doesn't notify for available updates
18:30:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1206760
18:30:32 <adamw> #info Accepted Blocker, plasma-pk-updates, ASSIGNED
18:30:41 <adamw> 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 <adamw> #info KDE team is aware and actively working on this bug, no action necessary
18:32:40 <adamw> #topic (1200161) Non-Fatal SELINUX Faults exist during bootup of 22_Alpha_RC3
18:32:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1200161
18:32:40 <adamw> #info Accepted Blocker, rng-tools, NEW
18:33:40 <adamw> this is a pretty old one
18:33:43 <adamw> 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 <adamw> 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 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1172235
18:35:41 <adamw> mclasen: wrong channel?
18:35:55 <mclasen> no, commenting on that liveusb-creator bug a few lines up
18:35:58 <adamw> mclasen: ah
18:36:04 <adamw> huh. that's odd
18:36:17 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1181308 is the 'parent' execmod-on-rngd bug
18:36:26 <adamw> it's closed as a dupe of 1172235
18:36:31 <adamw> but 1172235 doesn't seem to have anything to do with it
18:36:34 <adamw> i wonder if that was a typo
18:39:12 <adamw> let's say, we need to know if there's still an outstanding issue here
18:39:18 <adamw> #info this is fairly old and may well be fixed already
18:39:38 <adamw> #action secretary to ask reporter whether the first AVC is still a problem on 22 Beta or Final TC1
18:39:58 <adamw> #topic (1190377) SELinux is preventing polkitd from 'read' accesses on the lnk_file localtime.
18:39:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1190377
18:39:58 <adamw> #info Accepted Blocker, systemd, NEW
18:42:06 <adamw> 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 <adamw> seems like the devs are active on this one, so probably doesn't need any action
18:44:55 <adamw> #info this bug seems fairly active with input from devs and testers, no action needed
18:45:21 <adamw> #topic (1200559) [abrt] totem: browse_cb(): totem killed by SIGABRT
18:45:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1200559
18:45:22 <adamw> #info Accepted Blocker, totem, NEW
18:47:27 <adamw> 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 <adamw> this is the last bug, btw
18:49:46 <adamw> #info no response from the developer yet
18:50:11 <adamw> #action secretary to post comment asking dev for status
18:51:03 <adamw> okey dokey, that's all the blockers
18:51:09 <adamw> #topic Open floor
18:51:42 <adamw> any other business, folks?
18:51:51 <adamw> or is everyone dying to escape? :)
18:52:36 <potty> nah, i escaped and came back, then escape and finally came back
18:54:10 * roshi is finally here
18:54:19 <roshi> saw a ping, reading backscroll now'
18:54:33 <adamw> potty: you clearly don't quite understand this 'escaping' concept :)
18:54:47 <potty> :(
18:55:03 <adamw> roshi: we were waiting for your input on https://bugzilla.redhat.com/show_bug.cgi?id=1210047
18:55:30 <adamw> but then we decided we hated you so we'd vote -1
18:55:45 <adamw> that's what happened, right folks? pretty sure that's what happened.
18:56:48 <roshi> sounds like it's gone
18:56:53 * roshi had forgotten about this bug
18:57:14 <roshi> if you didn't see it on i386, then I'd say it's gone
18:58:01 <adamw> hum, i might've been on x86_64
18:58:07 <adamw> guess we can try it again
18:58:23 <roshi> well, like the 5 selinux denials bug - I *only* saw this on i386
18:58:35 <adamw> 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 <adamw> some kinda timeout seems to be involved
18:58:54 <adamw> anyhow, if you can check it out and see if it's reliably reproducible on i386 we can reconisder...
18:59:46 <roshi> sure thing
18:59:48 <adamw> anything else, folks?
18:59:51 <roshi> RC3 is gold, right?
19:00:00 <adamw> #action roshi to re-check #1210047 on current i386 images
19:00:01 <roshi> or do we have a final TC out?
19:00:04 <adamw> roshi: yeah, and we have nightlies
19:00:11 <adamw> TC1 will come later today
19:00:24 <roshi> I'll get to it after that then
19:01:23 <adamw> kk
19:01:41 <adamw> 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 <adamw> thanks a lot for coming folks
19:05:37 <adamw> #endmeeting