16:00:04 <roshi> #startmeeting F23-blocker-review
16:00:04 <zodbot> Meeting started Mon Sep 14 16:00:04 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:04 <roshi> #meetingname F23-blocker-review
16:00:04 <zodbot> The meeting name has been set to 'f23-blocker-review'
16:00:05 <roshi> #topic Roll Call
16:00:25 * kparal is here
16:00:25 <roshi> who's around for some blocker review goodness?
16:00:50 <roshi> we've got 3/3 proposed for beta/final
16:00:55 <kparal> goodness, that's exactly how I'd describe it
16:01:10 * garretraziel is here
16:01:16 <roshi> #chair kparal garretraziel adamw
16:01:16 <zodbot> Current chairs: adamw garretraziel kparal roshi
16:01:28 * satellit listening
16:01:40 <roshi> #topic Introduction
16:01:40 <roshi> Why are we here?
16:01:40 <roshi> #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:01:44 <roshi> #info We'll be following the process outlined at:
16:01:46 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:01:49 <roshi> #info The bugs up for review today are available at:
16:01:51 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:01:54 <roshi> #info The criteria for release blocking bugs can be found at:
16:01:56 * pschindl is here
16:01:56 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria
16:01:59 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria
16:02:02 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
16:02:06 <roshi> #chair pschindl satellit
16:02:06 <zodbot> Current chairs: adamw garretraziel kparal pschindl roshi satellit
16:02:15 <roshi> we'll give adamw a minute to get back
16:02:23 <kparal> so much attendance today, damn! :)
16:02:41 <roshi> sshh, you'll frighten them away
16:03:22 * nirik is lurking around in the back
16:03:29 <roshi> #topic (1258569) SElinux kickstart directive and cli directive not honoured
16:03:32 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1258569
16:03:34 <roshi> #info Proposed Blocker, anaconda, NEW
16:04:16 * danofsatx is here
16:04:40 <nirik> if that parameter works, it's just a doc/user error...
16:04:42 <adamw> -1 blocker.
16:04:48 <nirik> -1 blocker
16:04:48 <roshi> yeah
16:05:00 <roshi> assuming the parameter works still
16:05:11 <adamw> the only part of this that's arguably a bug is that anaconda doesn't handle 'selinux=0' as expected, but the criterion really doesn't require it to, for me.
16:05:20 <roshi> me either
16:05:20 <adamw> and 'noselinux' is an obvious alternative.
16:05:28 <garretraziel> -1 blocker
16:05:33 <roshi> I always read that as "nose-linux"
16:05:34 <pschindl> -1
16:05:45 <danofsatx> -1
16:05:49 <kparal> roshi: :)
16:06:38 <kparal> So when “selinux=0” is used, SELinux will be disabled both in the installation environment and in the installed system, but when “inst.selinux=0” is used SELinux will only be disabled in the installed system.
16:06:42 <kparal> https://rhinstaller.github.io/anaconda/boot-options.html#inst-selinux
16:06:52 * kparal just linking current docs
16:07:14 <kparal> if the docs are incorrect, it should still be a blocker until they fix the docs or the code?
16:07:20 <roshi> proposed #agreed - 1258569 - RejectedBlocker Beta - This bug doesn't violate the criteria. If the "noselinux" flag doesn't work, please repropose.
16:07:50 <pschindl> ack
16:07:53 <danofsatx> ack
16:08:13 <sgallagh> /me arrives late
16:08:24 * kparal understands people don't want to block on docs, he just has a perfectionist syndrome
16:08:29 <adamw> ack
16:08:35 <roshi> #agreed - 1258569 - RejectedBlocker Beta - This bug doesn't violate the criteria. If the "noselinux" flag doesn't work, please repropose.
16:08:40 <adamw> kparal: i don't think it really merits a blocker even for that.
16:08:51 <roshi> who wants to secretarialize?
16:08:53 <adamw> kparal: the criterion was not actually intended to mean 'disabling it via anaconda must work'
16:08:55 * adamw will do it
16:09:01 <kparal> alright
16:09:02 <roshi> thanks adamw
16:09:03 <sgallagh> adamw: Re-proposing doesn't mean it'll be accepted
16:09:11 <roshi> #topic (1258236) mouse scroll wheel no longer works after upgrade f22->f23
16:09:14 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1258236
16:09:16 <roshi> #info Proposed Blocker, gtk3, MODIFIED
16:09:29 <adamw> kparal: though i recognize it's a bit ambiguous. the only thing that the criterion was really meant to require was 'selinux must be enabled by default'
16:09:38 <sgallagh> Sorry, I think I confused two concurrent lines of conversation there
16:09:43 <adamw> sgallagh: never mind :)
16:10:28 <danofsatx> -1
16:10:36 <adamw> "I consider having regular mouse wheel working (under Xorg) as a minimum to release a new milestone"
16:10:40 <roshi> -1 for me
16:10:45 <roshi> there are so many other ways
16:10:48 <roshi> and there's a patch
16:10:49 <adamw> nice try, cole, but i'm pretty sure the release criteria don't include a "whatever cole thinks" entry. :P
16:10:52 <sgallagh> I'd be happy to take an FE for this, but not a blocker
16:10:53 <roshi> I'd be +1 FE though
16:10:57 <adamw> -1. bug? sure. annoying? sure. blocker? no.
16:10:58 <roshi> this is beta, after all
16:11:00 <sgallagh> -1 Blocker, +1 FE
16:11:03 <adamw> i'd be OK with fe if the fix isn't too icky
16:11:24 <sgallagh> adamw: https://bug753431.bugzilla-attachments.gnome.org/attachment.cgi?id=310997
16:11:29 <danofsatx> according to bz, it's already patched and working, so +1 fe
16:11:44 <pschindl> -1 blocker, +1 fe (for final)
16:11:58 <sgallagh> Someone reused 'i' for an iterator when they shouldn't have...
16:12:13 <roshi> proposed #agreed - 1258236 - RejectedBlocker AcceptedFreezeException Beta - This bug doesn't violate any criteria so isn't considered a blocker. However, if there's a patch to test, we'd consider letting the fix in during freeze.
16:12:26 <kparal> ack
16:12:32 <pschindl> ack
16:12:39 <garretraziel> ack
16:12:48 <roshi> #agreed - 1258236 - RejectedBlocker AcceptedFreezeException Beta - This bug doesn't violate any criteria so isn't considered a blocker. However, if there's a patch to test, we'd consider letting the fix in during freeze.
16:12:55 <roshi> #topic (1244394) Upgrade stuck on script
16:12:55 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1244394
16:12:56 <roshi> #info Proposed Blocker, initial-setup, NEW
16:12:57 <sgallagh> ACk
16:13:16 <adamw> this one seems a bit uncertain
16:13:24 <danofsatx> I'm not sure if this one viloates any specific criteria.
16:13:34 <adamw> normally i'd want to punt for more data, but we're pretty close to the deadline...
16:13:45 <danofsatx> dnf will hang due to a bug in the postun of initial-setup .35
16:13:56 <sgallagh> I'm pretty sure we have an "upgrade must complete and result in a functional system" criterion
16:14:06 <sgallagh> (Though, I forget which milestone that is)
16:14:09 <danofsatx> the updates happen, but the cleanup phase gets stuck.
16:15:04 <adamw> sgallagh: beta.
16:15:13 <adamw> danofsatx: that can result in a substantially messed-up system
16:15:17 <danofsatx> http://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria#Updates
16:15:25 <danofsatx> The installed system must be able to download and install updates with the default console package manager.
16:15:31 <danofsatx> so, +1 blocker then.
16:15:33 <adamw> that's updates, not upgrades.
16:15:54 <danofsatx> I hit it on an update of an already installed F23
16:15:59 <adamw> but: the upgrade criterion says "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed.  ...  The upgraded system must meet all release criteria."
16:16:06 <kparal> c9 says it happened during an update as well
16:16:08 <adamw> danofsatx: oh, this same thing with i-s? fun
16:16:20 <adamw> so i'm inclined to give this at least a provisional +1
16:16:20 <danofsatx> yes, exact same thing.
16:16:24 <adamw> we can always de-blocker it later if appropriate
16:16:50 <danofsatx> but, what is weird - I have two Dell D630 laptops with the exact same configuration. One hit this, the other didn't.
16:16:58 <kparal> I wonder if somebody reproduced this with dnf system-upgrade, and just dnf update --releasever=23
16:17:24 <sgallagh> kparal: You mean with both?
16:17:32 <kparal> *and not just
16:17:54 <sgallagh> danofsatx: Were you using 'dnf system-upgrade'?
16:18:06 <kparal> it seems the reporters were live upgrading their systems
16:18:13 <kparal> which is not exactly supported
16:18:32 <kparal> but c9 says it happened during regular package update, not system upgrade, which is covered by our criteria
16:19:12 * danofsatx is spinning up an F22 VM to test
16:19:18 <danofsatx> we can revisit in a bit
16:19:20 <sgallagh> kparal: Yeah, I strongly suspect that this only happens when an upgrade occurs without being in the clean update env.
16:19:31 <sgallagh> Which we still need to fix, but I don't think is deserving of a blocker
16:19:39 <sgallagh> Since it's not an officially-supported upgrade mechanism,
16:19:43 <roshi> punt, test and vote in bug?
16:19:57 <roshi> or come back to after we do the final proposals?
16:19:58 <sgallagh> roshi: Just a moment.
16:20:12 <sgallagh> I want to finish describing my thought process here.
16:20:31 * satellit_e using the latest spins updated or with fully updated make a diffence?
16:20:41 * satellit_e lives
16:20:45 <danofsatx> my question is, why is i-s even getting an update on an installed system
16:20:55 <sgallagh> 1) danofsatx's case: presumably you updated to F23 early in the cycle, before the latest initial-setup packages that cause this.
16:21:04 <adamw> danofsatx: why wouldn't it?
16:21:08 <sgallagh> danofsatx: Because the package exists.
16:21:17 <adamw> it seems to me like the appropriate thing here is to drop the systemd restart macros
16:21:29 <adamw> since we never actually expect i-s to be acting as some kind of daemon
16:21:30 <sgallagh> danofsatx: And in your case, you installed a pre-release, which means you'll pick up any changes to i-s before it's released.
16:21:53 <sgallagh> (i-s being updated post-release is a different question, but let's skip it for now)
16:22:07 <danofsatx> these two systems were installed from F23 Alpha - Cinnamon
16:22:22 <sgallagh> adamw: I strongly suspect that this cannot be hit if we boot into the systemd offline updates mode
16:22:29 <sgallagh> (Based on the discussion in the BZ)
16:22:59 <sgallagh> We should strongly urge that it be fixed before Final to aid those who don't use the supported upgrade mech, but I don't think it is a beta blocker
16:23:30 <sgallagh> EOF
16:23:44 <adamw> sgallagh: sure, but what about on a regular update?
16:23:55 <adamw> danofsatx is saying that he hit it just updating his installed F23.
16:24:01 <sgallagh> adamw: within a pre-release is a special case (IMHO)
16:24:14 <adamw> meh, /me not convinced.
16:24:15 <sgallagh> You're accepting a certain degree of risk
16:24:39 <sgallagh> Particularly since we leave updates-testing on
16:24:47 <adamw> still, since the issue is with post-install updates, we don't really need to fix this in the frozen package set, i guess.
16:24:51 <sgallagh> If we were stable-only, I'd be more inclined to hesitate
16:25:40 <kalev> I am with adamw here, I think it's one of the worst things that can happen if an update doesn't complete
16:25:49 <kalev> it's terribly hard to recover from a messed up rpmdb
16:26:04 <sgallagh> kalev: I don't disagree that it needs to be fixed. I disagree with the assertion that we couldn't ship Beta without fixing it first
16:26:04 <adamw> on the other hand, i'm not sure the blocker process gets us anywhere with something that affects updates
16:26:15 <kalev> sgallagh: it means it's impossible to update beta
16:26:23 <kalev> or not impossible, but requires manual workarounds
16:26:52 <roshi> I lean towards blockers on things that break any update mechanism
16:26:59 <kalev> it's not just updates, it's the packages that's in the frozen set that's not uninstalling correctly
16:27:00 <roshi> but I'm not sure on this one, tbh
16:27:03 <sgallagh> I'm not sure that's true, kalev
16:27:24 * kalev double checks the error message in the ticket.
16:27:34 <adamw> kalev: f23 installs pull from  u-t by default
16:27:41 <adamw> er, updates
16:27:47 <adamw> so as soon as a fix for this hits u-t, it is effectively fixed
16:27:51 <adamw> it doesn't need to go to stable
16:27:53 <kalev> loooking at the ticket, it says "Sep 13 18:03:40 ERROR Non-fatal POSTUN scriptlet failure in rpm package initial-setup"
16:28:08 <kalev> does it mean that if one installs beta and has the bad package, any updates _from_ that package are broken?
16:28:12 <danofsatx> correct, a non-fatal error that hangs dnf.
16:28:14 <kalev> because its postun script is bad?
16:28:22 <danofsatx> that's the way I see it
16:28:23 <adamw> kalev: yeah, true
16:28:25 <adamw> well
16:28:29 <adamw> i think saying 'any' is going too far
16:28:37 <sgallagh> kalev: The problem appears to be due to a systemd service getting restarted during postin
16:28:42 <sgallagh> Which shouldn't be
16:28:53 <sgallagh> So it's still fixable in an update
16:28:54 <adamw> as there's a factor we haven't worked out here: the bug only happens when i-s is actually running, and we haven't figured out the circumstances in which that happens yet
16:29:01 <adamw> sgallagh: no, it's postun
16:29:05 <kalev> postin is ok in the sense that this is fixable with an update; postun is not because that requires that the fix is in the frozen package set
16:29:05 <adamw> not post
16:29:14 <danofsatx> I think the bad script is only in initial-setup-0.3.35-1.fc23.x86_64 so once that one is out of the tree we should be good
16:29:18 <sgallagh> I misread, then
16:29:23 * adamw checks
16:30:05 <adamw> current git master and f23 both have postun_with_restart.
16:30:26 <adamw> so, i guess i'll say i'd be at least in favour of an FE here, since it seems like we have a decent rationale for one
16:30:37 <sgallagh> I'm fine with that.
16:30:50 <sgallagh> If the problem is really with the F22 postun, there's nothing we can block on that would fix it in any case.
16:30:58 <adamw> for me the question of whether it's a blocker kinda depends on the question of what's the circumstance, exactly, in which you have a stray initial-setup running when you run an update.
16:31:16 <adamw> sgallagh: we're not thinking about f22 here
16:31:17 * danofsatx is updating F22 vm, upgrade to 23 will start shortly
16:31:26 <sgallagh> adamw: To me, the obvious solution would be just kill any running i-s in %pre
16:31:45 <adamw> sgallagh: we're thinking about a case where you install f23 beta (with an initial-setup package that has the bug) and then run a normal update
16:31:50 * kalev nods.
16:32:29 <kalev> yes, that's the case that needs the fix in the frozen package set. F22->F23 updates are fixable with an update and don't require a fix in the frozen set
16:32:30 <adamw> sgallagh: i guess that might help, but it smells like a hack. is there anything wrong with my idea of just not using the restart-y postun?
16:32:38 <roshi> I wouldn't think bugs from a broken TC in the same milestone would block, though
16:32:51 <sgallagh> adamw: Because that would have to have been on the old package, wouldn't it?
16:32:57 <roshi> so this is updates from a previously installed F23 Beta, right?
16:33:02 <adamw> roshi: so far as we know the bug is still in i-s *right now*. i.e. if we built Beta today, its i-s package would have the restart-y postun.
16:33:08 <roshi> ah
16:33:10 <roshi> hrm
16:33:12 <adamw> sgallagh: sure, but if we give it an FE...:)
16:33:26 <sgallagh> adamw: Still doesn't address the F22 side...
16:33:34 <adamw> sgallagh: ship an F22 update.
16:33:44 <adamw> or, i mean, just upgrade the proper way.
16:34:06 <adamw> this only affects 'live' upgrade from F22, so far as we know, i.e. not using dnf system-upgrade.
16:34:21 <sgallagh> right, but since a lot of people are set in their ways, that's still going to bite them
16:34:43 <adamw> well, look, we can debate the right way to fix it outside this meeting
16:35:06 <adamw> but i'm gonna say we should at least give this a +1 FE as it's *conceivable* that we want to change the postun for Beta to fix this
16:35:13 <sgallagh> Absolutely +1 FE
16:35:14 <adamw> we don't have to *use* the FE if we wind up doing something else
16:35:17 <sgallagh> I remain -1 Blocker
16:36:05 <roshi> votes?
16:36:22 <kalev> I'd be +1 to a blocker here, not because of the F22->F23 updates, but because it must be possible to update F23 beta installs afterwards
16:36:33 <danofsatx> the F22 initial setup is 0.3.31-1 - I'll let you know if it is broken in a bit.
16:36:54 <adamw> i'm kinda +/-0 on blocker right now, +1 FE.
16:37:00 <kalev> I mean, it's kinda fine if the beta doesn't install at all -- then the testers just keep away from it. but if it installs fine but explodes after first upgrade, it's extremely frustrating
16:37:28 * danofsatx wanted to put SSDs in the laptops anyway....
16:37:38 <kalev> also note that I am mostly only arguing for the sake of Server and KDE -- afaik we don't even install initial-setup in Workstation
16:37:55 <sgallagh> Server doesn't include initial-setup either
16:38:07 <danofsatx> and since I hit it in Cinnamon, a non-blocking desktop....
16:38:08 <kalev> ahh, that weakens the blocker case
16:38:24 <adamw> i guess i'd tend slightly -1 blocker, as we probably *can* do something abou this without needing to fix the frozen package (i.e. %pre hack or whatever)
16:38:25 <roshi> proposed #agreed - 1244394 - AcceptedFreezeException Beta - This bug still needs some testing to determine blocker status. However, we'd like to see a fix for this during freeze.
16:38:42 <adamw> ack
16:38:44 <kalev> ack
16:38:45 <danofsatx> ack
16:38:48 <sgallagh> ack
16:38:49 <satellit_e> ack
16:38:51 <garretraziel> ack
16:38:54 <pschindl> ack
16:39:12 <roshi> #agreed - 1244394 - AcceptedFreezeException Beta - This bug still needs some testing to determine blocker status. However, we'd like to see a fix for this during freeze.
16:39:42 <roshi> ok, we're onto Final proposals
16:39:44 <roshi> #topic (1262599) Fedora 23 artwork (background/wallpaper) not applied by default
16:39:47 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1262599
16:39:50 <roshi> #info Proposed Blocker, f23-kde-theme, NEW
16:40:15 <roshi> +1
16:40:20 <pschindl> +1
16:41:31 <sgallagh> +1
16:41:40 <kalev> +1
16:41:45 <satellit_e> +1 saw it in testing
16:41:47 <roshi> proposed #agreed - 1262599 - AcceptedBlocker Final - This bug is a clear violation of the following criterion: "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme."
16:41:58 <kparal> ack
16:42:18 <kalev> ack
16:42:19 <adamw> ack
16:42:21 <garretraziel> ack
16:42:21 <roshi> #agreed - 1262599 - AcceptedBlocker Final - This bug is a clear violation of the following criterion: "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme."
16:42:22 <sgallagh> ack
16:42:23 <satellit_e> ack
16:42:29 <roshi> #topic (1262600) Plasma live session notifies for available updates
16:42:32 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1262600
16:42:35 <roshi> #info Proposed Blocker, plasma-pk-updates, NEW
16:42:54 <adamw> +1, it shouldn't do that.
16:43:22 <kparal> +1
16:43:30 <pschindl> +1
16:43:31 <danofsatx> +1
16:43:32 <sgallagh> +1, seems straightforward
16:43:33 <kalev> +1
16:43:34 <garretraziel> +1
16:43:39 <sgallagh> And Rex looks like he's on it
16:44:09 <roshi> proposed #agreed - 1262600 - AcceptedBlocker Final - This bug is a clear violation of the following criterion: "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
16:44:34 <kalev> ack
16:44:39 <pschindl> ack
16:44:47 <adamw> ack
16:44:55 <sgallagh> ack
16:44:56 <danofsatx> ack
16:45:01 <roshi> #agreed - 1262600 - AcceptedBlocker Final - This bug is a clear violation of the following criterion: "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
16:45:05 <roshi> #topic (1261721) preexisting btrfs snapshot cannot be assigned as mountpoint for new installation
16:45:08 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1261721
16:45:11 <roshi> #info Proposed Blocker, python-blivet, NEW
16:46:01 <sgallagh> Didn't we already say no to this?
16:46:02 <danofsatx> is btrfs a blocking setup?
16:46:20 <danofsatx> no, we said we needed more info, which cmurf appears to have provided
16:48:47 <adamw> just to be clear, at the time of blocker review last week, this was proposed as being something to do with encryption (not btrfs), and all we knew was that it was likely some kind of cmurf special setup
16:48:54 <adamw> since then we've got quite a lot more info on what's going on
16:49:24 <adamw> i believe dlehman is fairly clear that this is effectively a feature request - it's not something in anaconda that's broken, it's just something anaconda doesn't currently support
16:49:27 <adamw> i'm -1
16:51:25 <sgallagh> I'm -1 as well
16:51:48 <roshi> -1
16:52:32 <roshi> proposed #agreed - 1261721 - RejectedBlocker Final - This bug doesn't violate any criteria and is not considered a blocker.
16:53:26 <pschindl> ack
16:53:37 <adamw> ack
16:53:40 <sgallagh> ack
16:53:42 <garretraziel> ack
16:53:43 <roshi> #agreed - 1261721 - RejectedBlocker Final - This bug doesn't violate any criteria and is not considered a blocker.
16:54:01 <roshi> ok, we've got one beta FE proposal
16:54:07 <roshi> #topic (1262484) Fedora 21 doesn't contain F23 gpg keys: upgrade with dnf fails
16:54:11 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1262484
16:54:13 <roshi> #info Proposed Freeze Exceptions, fedora-release, ON_QA
16:54:41 <sgallagh> This isn't really an FE, since it just has to be pushed to the previous release
16:54:43 <kalev> I don't think this needs a freeze exception, just needs to have the F21 package go stable
16:54:45 <sgallagh> And is already in teseting there
16:54:46 <kalev> yeah
16:55:13 <sgallagh> Though it affects upgrades, so maybe this qualifies as a "special blocker"?
16:55:29 <sgallagh> (Which begs the question if N->N+2 direct upgrades are supported)
16:55:40 <roshi> -1, it'll get into f21 and not be an issue
16:55:43 <sgallagh> In any case, no special handling should be needed by us
16:55:46 <adamw> 'supported' isn't the word
16:55:48 <sgallagh> So -1
16:55:58 <sgallagh> adamw: "Expected to work", then
16:55:59 <adamw> the question of whether they're supported is a tricky one, but they clearly don't *block*, which is what we care about here
16:56:01 <pschindl> -1
16:56:06 <danofsatx> -1
16:56:09 <kalev> -1
16:56:10 <kparal> we had the same issue last cycle
16:56:15 <adamw> the criterion specifically states "the previous stable Fedora release", i.e., not the one before that
16:56:17 <kparal> don't remember the vote outcome, though
16:56:24 <sgallagh> /me nods
16:56:29 <adamw> so if this was a blocker it'd be a special blocker, but it's not a blocker so it's nothing. :P
16:56:29 <adamw> -1
16:56:42 <sgallagh> (Thanks for not phrasing that as *a* previous stable Fedora release :) )
16:56:51 <roshi> proposed #agreed - 1262484 - RejectedFreezeException Beta - There's no need for an FE to get this fixed, as it's an F21 issue.
16:57:12 <kalev> ack
16:57:12 <pschindl> ack
16:57:35 <danofsatx> ack
16:57:37 <adamw> ack
16:57:42 <sgallagh> ack
16:58:10 <roshi> #agreed - 1262484 - RejectedFreezeException Beta - There's no need for an FE to get this fixed, as it's an F21 issue.
16:58:26 <roshi> ok, go through the accepted blockers for beta, or close out and get with the testing
16:58:29 <roshi> ?
16:58:46 <roshi> there's 7 accepted blockers if we go that route
16:59:14 <sgallagh> I think we have to go through them
16:59:14 <pschindl> Maybe the only NEW one?
16:59:41 <sgallagh> I think NEW and MODIFIED at least
16:59:44 <pschindl> ok
16:59:45 <adamw> i more or less know where we're at, so it won't take long.
16:59:47 <danofsatx> +1 close
16:59:58 <sgallagh> Oh, and I tested 1260875 just a little while ago
17:00:07 <sgallagh> Anyone have an issue with my marking it VERIFIED?
17:00:09 * danofsatx is in too much physical pain to go through the rest
17:00:34 <roshi> ok, sounds good to go through the NEW and MODIFIED
17:00:49 <roshi> #topic Accepted Blocker Review
17:00:50 <roshi> #topic (1260318) TypeError: uid should be integer, not str
17:00:50 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1260318
17:00:50 <roshi> #info Accepted Blocker, anaconda, MODIFIED
17:01:59 <roshi> looks like we were right about it being common enough
17:02:20 <sgallagh> Which version of anaconda was in TC5?
17:02:32 <adamw> this one is not fixed in TC5
17:02:45 <sgallagh> Oh wait. Yeah, I see the TC5 reports.
17:02:47 <adamw> there will be new anaconda/blivet builds today that will address all the issues that are MODIFIED
17:02:48 <sgallagh> ok
17:02:54 <adamw> ones that are ON_QA/VERIFIED were in TC5 (or earlier)
17:03:11 <roshi> ok, cool
17:03:23 <roshi> so the only other one is 1260394
17:03:30 <roshi> #topic (1260394) plasma-desktop and plasma-workspace packages break KDE session loading
17:03:33 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1260394
17:03:36 <roshi> #info Accepted Blocker, plasma-desktop, NEW
17:04:48 <adamw> so the KDE folks are clearly on this, but i don't know the exact current status
17:04:51 <sgallagh> So this is still broken and shows no signs of resolution? :(
17:04:54 <adamw> it was on my list to talk to them about it today
17:05:02 <adamw> i think 'shows no signs of resolution' is unnecessarily pessimistic.
17:05:49 <satellit> TC-5 has 5.4.0 here in virt-manager
17:05:58 <sgallagh> Sorry, I meant to say that none of the comments indicate a solution is impending
17:08:19 <adamw> well, not sure i agree with that either.
17:08:32 <adamw> seems to me the downside of just doing "Requires: sddm-breeze" is pretty tiny.
17:08:48 <adamw> and if we need to we can just do that and tell 'enterprise users' who are incapable of deploying a config file to go hang.
17:08:54 <adamw> (controversial? moi?)
17:09:14 <roshi> anything for us to do for this bug here in meeting?
17:10:11 <adamw> don't think so, sgallagh and i are on it like donkey kong.
17:10:18 <adamw> am i a chair?
17:10:22 <roshi> yeah
17:10:34 <sgallagh> adamw: Depends, do you have a pillow on your lap?
17:10:48 <adamw> #info adamw and sgallagh are following up with KDE and DNF teams, at least a workaround for this should be viable easily enough
17:11:07 <roshi> that's it then, we can move on
17:11:12 <roshi> #topic Open Floor
17:11:15 <adamw> sgallagh: message for you from NBC's commissioning department: don't call us, we'll call you
17:11:18 <roshi> anyone have anything for this?
17:11:26 <sgallagh> Plans for RC1?
17:11:46 <adamw> basically it's waiting on the KDE bug at this point
17:11:56 <sgallagh> Right, which sounds like a short rebuild away.
17:11:59 <adamw> anaconda should be done soon
17:12:10 <sgallagh> So barring disaster, plan for RC1 to build tonight?
17:12:18 * roshi hopes for it
17:12:20 <adamw> sounds like a plan
17:12:47 <sgallagh> Three days for release validation. Will wonders never cease?
17:13:12 <kalev> that sounds so much better than 6 hours
17:13:25 <kalev> or how much was it last time? :)
17:14:05 <sgallagh> kalev: I think we had a full 9
17:14:32 * adamw hopes somebody is standing by in brno with the large roll of kparal duct tape
17:15:04 * kparal intends to work from home for the full next month. doors locked
17:15:19 <sgallagh> /me changes the isolation chamber delivery address
17:15:23 <roshi> well, I guess let's call this meeting, do some testing and hope for an RC1 tonight
17:15:52 <roshi> just give him my normal ration of bourbon over an hour or something, should hold him up for a while
17:16:04 <roshi> make sure adamw is pouring
17:16:27 <adamw> fine canadian whisky is on standby
17:16:37 * roshi sets the fuse
17:16:44 <roshi> thanks for coming folks! great turnout today
17:16:46 <roshi> 3...
17:17:14 <roshi> 2...
17:17:24 <jkurik> hi there, one quick question
17:17:36 <roshi> go for it :)
17:17:46 <jkurik> who from QE is goint to be on Readiness meeting ?
17:17:50 <jkurik> this Thursday
17:17:56 <roshi> I'll be there
17:18:01 <jkurik> ok, thanks
17:18:10 <roshi> I'm sure others will be as well
17:18:14 * adamw may or may not depending on how much overnight blocker heroism is needed
17:18:18 <adamw> but yeah, we'll be there one way or another
17:18:22 <jkurik> then please continue countdown ...
17:18:38 <roshi> 1...
17:18:44 <roshi> thanks folks!
17:18:47 <roshi> #endmeeting