16:00:41 <pschindl> #startmeeting F24-blocker-review
16:00:41 <zodbot> Meeting started Mon May 16 16:00:41 2016 UTC.  The chair is pschindl. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:41 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:00:43 <pschindl> #meetingname F24-blocker-review
16:00:43 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:00:45 <pschindl> #topic Roll Call
16:00:47 * kparal is here
16:01:04 <pschindl> So, who is here for some short meeting?
16:01:18 * kparal is having a dinner, take your time
16:01:34 * garretraziel is here
16:01:52 * coremodule is here.
16:02:17 * cmurf is here
16:02:28 * tflink can be here for a bit
16:03:09 <pschindl> #chair kparal garretraziel tflink coremodule cmurf
16:03:09 <zodbot> Current chairs: cmurf coremodule garretraziel kparal pschindl tflink
16:03:46 <cmurf> I join Fedora, and I'm turned into furniture. Great.
16:04:02 <tflink> cmurf: is that better than being hit with a chair?
16:04:15 <cmurf> Or by a chair?
16:04:33 <tflink> the second of these is more amusing to me
16:04:48 <tflink> it's like the mops in fantasia ... just with chairs
16:04:50 <cmurf> Go ahead, make my day, punk.
16:05:03 <tflink> in other news, mickey mouse is apparently working on Fedora ...
16:05:12 * cmurf thought it was funny...
16:05:19 <tflink> :)
16:06:05 <pschindl> ok. Let's start.
16:06:31 <pschindl> #topic Introduction
16:06:33 <pschindl> Why are we here?
16:06:35 <pschindl> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:06:37 <pschindl> #info We'll be following the process outlined at:
16:06:41 <pschindl> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:43 <pschindl> #info The bugs up for review today are available at:
16:06:45 <pschindl> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:47 <pschindl> #info The criteria for release blocking bugs can be found at:
16:06:49 <pschindl> #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria
16:06:51 <pschindl> #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria
16:06:53 <pschindl> #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria
16:06:59 <pschindl> #info 3 Proposed Blockers
16:07:02 <pschindl> #info 11 Accepted Blockers
16:07:04 <pschindl> #info 5 Proposed Freeze Exceptions
16:07:06 <pschindl> #info 0 Accepted Freeze Exceptions
16:07:22 <pschindl> #topic (1317275) [abrt] gnome-software: gs_plugin_loader_get_updates_async(): gnome-software killed by SIGSEGV
16:07:25 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1317275
16:07:27 <pschindl> #info Proposed Blocker, gnome-software, NEW
16:07:52 <cmurf> I haven't run into it.
16:07:56 <kparal> do we have a secretary already?
16:08:11 * coremodule will do it.
16:08:15 <kparal> coremodule: thanks
16:08:22 <coremodule> kparal, No problem1
16:08:23 <coremodule> !
16:08:26 <pschindl> coremodule: Thanks.
16:08:34 <kparal> I tested this bug today, can't reproduce it, and according to the reporter it occurs sporadically
16:08:36 <cmurf> It'd be useful to hear from a dev, if someone hits this, exactly what information is needed that isn't already attached?
16:08:38 <pschindl> I'm -1 blocker.
16:08:42 <kparal> therefore I don't think it violates the criterion
16:08:44 <kparal> -1 blocker
16:08:54 <cmurf> Yeah I'm -1 blocker as well.
16:09:11 <tflink> -1 here as well
16:09:14 <pschindl> If it start to happen more often we can repropose it.
16:09:14 <garretraziel> -1 blocker
16:09:19 <kparal> #info coremodule will secretarialize
16:10:01 <garretraziel> it looks like it doesn't happen too often (and I guess that it is then easily fixable by update)
16:10:19 <cmurf> good point on the update
16:10:20 <kparal> garretraziel: well it's the updater that crashes
16:10:36 <kparal> so it might be tricky for gui users
16:10:42 <cmurf> but it's not reproducible
16:10:58 <garretraziel> kparal: yeah, but it doesn't happen too often, or at least you weren't able to reproduce it
16:10:59 <kparal> yeah, that's the reason why I vote -1, we can't even trigger it
16:11:01 <cmurf> so whatever intermittant crashes there may be, should still have a good chance of being fixed by update
16:12:36 <pschindl> propose #agreed 1317275 - RejectedBlocker (Final) - No one reproduced this bug for some time. It doesn't occur often enough to block release.
16:13:07 <garretraziel> ack
16:13:14 <cmurf> ack
16:13:24 <coremodule> ack
16:13:44 <kparal> ack
16:13:55 <pschindl> #agreed 1317275 - RejectedBlocker (Final) - No one reproduced this bug for some time. It doesn't occur often enough to block release.
16:14:12 <pschindl> #topic (1333106) Server deployment fails on current Fedora Rawhide (2016-05-04)
16:14:15 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1333106
16:14:17 <pschindl> #info Proposed Blocker, selinux-policy, NEW
16:14:55 <cmurf> curious title for the bug
16:14:58 <kparal> this got proposed from adamw, because being on vacation doesn't stop him from doing so
16:15:06 <cmurf> he what?
16:15:26 <kparal> I imagine he's at the beach somewhere proposing blocker bugs :)
16:15:28 <tflink> cmurf: it started in rawhide and is now apparently happening in F24
16:15:46 <cmurf> throw that laptop into the ocean!
16:16:14 <coremodule> adamw is https://www.youtube.com/watch?v=JgpmFp2DViA
16:16:43 <cmurf> I'm not watching
16:17:15 <cmurf> Anyway, I'm +1 blocker, sounds legit. However I wonder if this package was affected by the recent bodhi hiccup?
16:17:17 <kparal> seems +1, roles being broken
16:17:23 <garretraziel> hm, I don't know much about this pesky FreeIPA kerfuffle, but this looks like blocker, +1
16:17:33 <tflink> yeah, +1 if it's happening in F24 now
16:19:14 <cmurf> adamw if you read this, there's a reason wifi on beaches is slow, you're supposed to be building sand castles!
16:20:17 <pschindl> +1
16:22:24 <cmurf> ?
16:22:42 <kparal> pschindl: propose?
16:22:49 <cmurf> tick tock tick tock
16:22:53 <kparal> you have to propose to us :o)
16:22:58 <pschindl> propose #agreed 1333106 - AcceptedBlocker (Final) - It clearly violates the Alpha criterion: "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried."
16:23:12 <cmurf> ack
16:23:16 <tflink> ack
16:23:16 <kparal> ack
16:23:17 <cmurf> or the selinux one?
16:23:21 <cmurf> guess it doesn't matter
16:23:25 <garretraziel> ack
16:23:30 <pschindl> sry. I'm testing next proposed blocker and my multitasking isn't as good as Adam's one. :)
16:23:49 <pschindl> #agreed 1333106 - AcceptedBlocker (Final) - It clearly violates the Alpha criterion: "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried."
16:24:15 <pschindl> #topic (1332266) systemd-logind does not verify if system has resume device defined when checking if can.hibernate or can.hybridsleep
16:24:18 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1332266
16:24:20 <pschindl> #info Proposed Blocker, systemd, NE
16:24:30 <kparal> W
16:24:43 <kparal> sorry, qa person here
16:25:00 <cmurf> oh dear sweet jesus, now this bug is a good reason for adamw to be on vaca
16:25:22 <kparal> you want to see the screenshot from comment 6
16:25:26 <cmurf> ok so i've dug into this a lot but not as much as jhogarth
16:25:33 <cmurf> I know...
16:25:44 <kparal> that shows that popups really do lie to our users
16:25:58 <cmurf> yes
16:26:02 <kparal> they say the system will be hibernation, and in fact it will, but the resume will never work
16:26:06 <kparal> so it's misleading
16:26:08 <cmurf> yes
16:26:19 <cmurf> but here's the thing, it's data loss in any case
16:26:33 <cmurf> whether it's poweroff or hibernation, whatever the user is working on, if not saved, goes away
16:26:43 <kparal> one can argue this is a conditional violation either of the "standard desktop actions must work" or "proper shutdown" criterion
16:26:48 <kparal> or data loss
16:26:54 <cmurf> yes either
16:27:04 <cmurf> but not a systemd bug, I think it's a UI bug against all the release blocking DE's
16:27:07 <pschindl> ok. So now I tried to let my laptop starve to the death. It warned me that it will hibernate and then it did so. Then I plugged the laptop to power and start it again. And it resumed correctly (youtube video continued to play, gedit was opened where I left it and so on).
16:27:14 <cmurf> I think this bug is asking for a new systemd functionality
16:27:42 <kparal> pschindl: was it really shut down, or was it just suspend?
16:27:51 <cmurf> pschindl: that's confusing, there is not resume= by default and the fedora initramfs doesn't do it
16:27:54 <cmurf> huh
16:27:58 <cmurf> i don't have an explanation for that
16:28:00 <kparal> pschindl: what's your /proc/cmdline
16:29:04 <cmurf> cat /proc/cmdline and also sudo dracut --print-cmdline
16:29:10 <pschindl> There is some probability that it suspend instead of hibernate. How can I say?
16:29:27 <kparal> pschindl: have you immediately seen the gnome lock screen after opening the lid, or have you seen bios/grub first?
16:29:29 <cmurf> dmesg | grep -i hibernat
16:29:40 <kparal> resume from hibernation looks like a standard boot
16:29:47 <kparal> fedora logo filling up etc
16:29:56 <kparal> I think
16:30:11 <pschindl_> BOOT_IMAGE=/vmlinuz-4.5.2-302.fc24.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rd.luks.uuid=luks-fb16457f-80e1-4e8d-9eac-1a4214a0261d rhgb quiet LANG=en_US.UTF-8
16:30:19 <pschindl_> this is /proc/cmdline
16:30:23 <kparal> you have no resume= arg there
16:30:44 <pschindl> Then it was probably suspend.
16:30:53 <cmurf> I bet it was suspend to ram
16:30:58 <cmurf> not suspend to disk
16:31:02 <pschindl> So it still lies about hibernation.
16:31:12 <kparal> maybe it was hybrid
16:31:29 <kparal> in hybrid as long as battery is not completely 0%,  you can still resume immediately
16:31:42 <kparal> once the battery is dead, you need to resume from the hibernate file
16:32:12 <pschindl_> https://paste.gnome.org/pjhjnhrdl
16:32:15 <cmurf> I think there are a few questions:
16:32:47 <cmurf> 1. is this a feature request or a bug? I think for systemd as suggested in the bug report, it's a feature request and thus not a blocker.
16:32:50 <kparal> pschindl_: grep CriticalPowerAction /etc/UPower/UPower.conf
16:32:55 <pschindl> ok. I'll let it die next time. But it will take me more time then 1 hour :)
16:33:21 <cmurf> If it's a UI/Ux complaint, it might be a blocker against at least GNOME and KDE
16:33:28 <pschindl_> Guess who is right: CriticalPowerAction=HybridSleep
16:33:37 <kparal> me is right :)
16:33:43 <cmurf> The problem is GNOME and KDE depend on systemd-logind to know if suspend to disk is supported.
16:34:24 <kparal> James added a patch to systemd to check whether resume= is present
16:34:27 <pschindl> ok. I'm going to let it die during night.
16:34:27 <cmurf> So to fix the bug requires one of two things, a feature in systemd, or a hardcoded patch just for Fedora because we know anaconda doesn't include resume= as a boot parameter so resume can't ever work out of the box.
16:34:30 <kparal> at least that's what I think he did
16:34:34 <kparal> hats off to patching systemd
16:34:54 <kparal> but I have no idea how systemd maintainers will like it
16:35:07 <cmurf> This was brought up on the systemd list.
16:35:11 <kparal> I asked on #systemd for someone to look at it, but no one did
16:35:19 <kparal> cmurf: do you have a link?
16:35:21 <cmurf> The problem is that dracut on some distros supports resume in the initramfs
16:35:41 <cmurf> So considering hibernation unsupported if resume= is missing from cmdline is not reliable.
16:35:59 <cmurf> The problem is hibernation support on linux is sociopathic right now.
16:36:16 <cmurf> I don't see that QA has a way to compel a fix even though this is bad behavior.
16:36:37 <kparal> well we can ask that the messages are correct. that doesn't mean supporting hiberation
16:36:46 <kparal> force-disabling hibernation is also a solution
16:37:01 <kparal> even though I'm not thrilled about that approach
16:37:15 <kparal> but still, a simple tweak to Upower.conf can resolve this
16:37:25 <cmurf> kparal: If you really think GNOME and KDE and probably Xfce folks will accept this as a blocker, OK...
16:37:28 <cmurf> https://lists.freedesktop.org/archives/systemd-devel/2016-May/036409.html
16:37:45 <kparal> #link https://lists.freedesktop.org/archives/systemd-devel/2016-May/036409.html
16:37:45 <cmurf> that's the top of the thread
16:38:00 <cmurf> #link https://lists.freedesktop.org/archives/systemd-devel/2016-May/036489.html
16:38:21 <cmurf> that's the specific one I referred to
16:38:25 <kparal> thanks
16:39:03 <kparal> I don't see a big problem to having a Fedora-specific patch to change default action to shutdown
16:39:32 <cmurf> Sure
16:39:56 <kparal> or, can't logind be smarter about detecting whether hibernate is supported or not?
16:40:18 <cmurf> Not yet apparently.
16:40:27 <cmurf> It doesn't know how to test for resume being valid in advance.
16:40:35 <cmurf> s/valid/possible
16:41:05 <cmurf> And that test might break other configurations.
16:41:17 <kparal> this bug is killing me
16:42:03 <cmurf> Well the more mature and polished a thing gets, you start scraping the bottom of the barrel for bugs.
16:42:07 <cmurf> So in a way it's a good sign.
16:42:19 <pschindl> punt and wait for more Adams for discussion? :)
16:42:30 <cmurf> we know what he'll say :-)
16:42:56 * kparal takes a good look at our criteria
16:43:08 <cmurf> I suggest you punt but suggest that you're inclined to have upower default to shutdown so that the misleading dialog doesn't appear out of the box.
16:43:33 <kparal> "All known bugs that can cause corruption of user data must be fixed or documented at Common F24 bugs. "
16:43:38 <cmurf> sure
16:43:45 <kparal> that does not force us to actually fix it, as it is written
16:43:48 <cmurf> if data loss is corruption
16:43:55 <cmurf> yep it can also be documented
16:44:23 <kparal> "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. "
16:44:35 <kparal> that's what we use for "standard desktop buttons etc"
16:44:40 <cmurf> oh god really?
16:44:50 <cmurf> so what about the hibernation button that shows prominently in xfce?
16:44:50 <kparal> seem a bit far-fetched here, with just a popup
16:45:07 <kparal> cmurf: xfce is... actually release blocking, but just on arm
16:45:12 <cmurf> i know
16:45:15 <kparal> I'm not sure I want to add arm into the mix
16:45:19 <cmurf> ok
16:45:21 <kparal> especially hibernation on arm! :)
16:45:42 <cmurf> I'm not sure about KDE's UI in this regard
16:45:57 <kparal> "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. "
16:46:17 <kparal> adamw always points out this does not mention hibernation
16:46:21 <kparal> which is true
16:46:43 <kparal> a counter argument is that we do it by default for critical battery
16:47:04 <kparal> but still, he would have a point, we should have a discussion about amending that criterion first
16:47:35 <cmurf> I think it's the notification of "hibernation" which implies both suspend to disk operation and a successful resume, that data is safe.
16:47:38 <cmurf> But it won't be.
16:47:46 <kparal> this is like devil's advocate, using adamw spectre to counter my arguments
16:48:10 <cmurf> I asked on desktop@ about hibernation and only one person from the WG replied and they do not care about hibernation.
16:48:21 <cmurf> kernel@ team also doesn't give it any priority
16:48:32 <cmurf> So there's not a lot of capital to fix hibernation and make it work.
16:48:47 <kparal> thanks for trying
16:48:48 * kparal is sad
16:48:53 <cmurf> There's probably a legitimate case for getting rid of misleading notifications though.
16:49:07 <kparal> yes, the only question is whether it's a blocker
16:49:50 <cmurf> I see it both ways. I think you can make a strong argument the notification banner is sufficietly misleading to be a blocker.
16:49:55 <pschindl> I wouldn't block on it. We can document it in common bugs and make it FE.
16:50:09 <cmurf> And then document it if it doesn't get fixed.
16:50:11 <kparal> currently I'd either say punt and wait for adamw to passionately explain to us that it's not a blocker, or reject it
16:50:25 <kparal> one popup doesn't seem to violate any of those criteria
16:50:29 <kparal> too much
16:50:53 <cmurf> Sure, data loss, it suggests your data is safe, then it face plants on resume because of a misconfiguration we all know about.
16:51:08 <kparal> it's already in common bugs
16:51:16 <kparal> (bug 1206936)
16:51:34 <cmurf> Punt
16:51:45 <cmurf> And I'll bring up whether criticalpoweraction can be changed to shutdown.
16:51:54 <cmurf> ... on the desktop@ list.
16:52:05 <cmurf> Because it is misleading.
16:52:05 <kparal> cmurf: great, thanks
16:52:46 <kparal> #action cmurf bring up whether criticalpoweraction can be changed to shutdown on the desktop@ list
16:52:53 <garretraziel> I would like to see default action on low power changed
16:53:01 <kparal> so much for ctrl+w deleting the last word in hexchat
16:53:23 <cmurf> At least tell the user what's really going to happen: shutdown, which means, save your data now.
16:53:27 <pschindl> propose #agreed 1332266 - punt (delay decision) - We decided to discuss this problem with other teams before making the decision.
16:53:35 <cmurf> ack
16:53:38 <garretraziel> ack
16:53:44 <kparal> ack
16:53:47 <tflink> ack
16:53:51 <pschindl> #agreed 1332266 - punt (delay decision) - We decided to discuss this problem with other teams before making the decision.
16:54:07 <pschindl> and that's all from proposed blockers
16:54:30 <kparal> however, we missed our chance to approve this as a blocker before adamw gets back
16:54:39 <kparal> now we're doomed
16:54:51 <pschindl> Do we want to go through accepted?
16:55:16 <kparal> pschindl: we probably should, quickly
16:55:23 <cmurf> We should skim them.
16:55:26 <pschindl> ok.
16:55:42 <cmurf> Better to pester than to slip.
16:55:59 <pschindl> #topic (1333998) After Russian install, console keymap is 'us', not 'ru'
16:56:01 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1333998
16:56:03 <pschindl> #info Accepted Blocker, anaconda, NEW
16:56:21 <kparal> no change since last week, I'll add a comment asking for updates
16:56:52 <kparal> pschindl: feel free to give me an action
16:57:04 <pschindl> #action kparal to ask for update in comment
16:57:18 <pschindl> #topic (1325471) resolving Supplements: dependencies pull in multilib packages
16:57:21 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1325471
16:57:23 <pschindl> #info Accepted Blocker, dnf, ASSIGNED
16:58:43 <kparal> pschindl: can we go back to the previous one afterwards? thanks
16:58:58 <pschindl> kparal: ok
16:59:08 <kparal> no change here, but igor added blocker to their whiteboard
16:59:43 <kparal> I can ping jsilhan on irc to make sure they know about it
17:00:38 <pschindl> #info there is now change, but the bug is in the viewfinder
17:00:55 <kparal> no change
17:01:19 <pschindl> #action kparal to ping jsilhan on irc to make sure they know about this bug
17:01:35 <pschindl> #topic (1333998) After Russian install, console keymap is 'us', not 'ru'
17:01:38 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1333998
17:01:40 <pschindl> #info Accepted Blocker, anaconda, NEW
17:01:46 <kparal> so, I realized there are no logs in there
17:02:02 <kparal> so it seems a bit annoying to ping them while having no debug info
17:02:13 <kparal> somebody needs to volunteer, reproduce it, and attach logs
17:02:32 <kparal> do we have a volunteer?
17:02:52 <coremodule> kparal, I'll do it.
17:02:52 <pschindl> One volunteer left this meeting :)
17:03:08 <pschindl> ok and another is still here. That's better.
17:03:26 <kparal> coremodule: perfect. after an anaconda installation, there are logs in /var/log/anaconda
17:03:45 <pschindl> #action coremodule to reproduce this bug and attach logs
17:03:54 <kparal> plus `rpm -qa | sort` is useful, and in this case probably contents of /etc/locale.conf and similar
17:04:22 <kparal> /etc/vconsole.conf
17:04:24 <coremodule> kparal, Gotcha, starting now. Will post ASAP.
17:04:27 <cmurf> could cheat and just go on #anaconda and ask exactly what logs they want for that bug
17:04:52 <kparal> that as well. communication and collaboration, always helps :)
17:05:37 <coremodule> cmurf, Let's see what they say...
17:06:32 <pschindl> #topic (1164492) Please drop libvirt 'default' network dependency for F24 GA, disrupts livecd networking
17:06:35 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1164492
17:06:37 <pschindl> #info Accepted Blocker, gnome-boxes, NEW
17:08:47 <kparal> so, this needs to see an action from gnome-boxes developers
17:09:05 <kparal> none of those commenting are the devs, I believe
17:09:17 <kparal> (or packagers)
17:09:22 <cmurf> Yes
17:09:32 <cmurf> I think this became a blocker because it was a blocker for other Fedora releases.
17:09:45 <cmurf> It hasn't come up for discussion for F24 specifically.
17:09:51 <kparal> cmurf: when writing to desktop list, maybe you could mention this one as well?
17:10:03 <cmurf> OK
17:10:03 <kparal> to alert people maintaining boxes
17:10:07 <kparal> thanks
17:11:28 <kparal> #action cmurf to alert boxes maintainers on desktop@ list about this
17:11:28 <pschindl> #action cmurf to point out this bug on desktop list
17:11:35 <kparal> :)
17:11:36 <pschindl> hmm :)
17:11:49 <kparal> shall we race-condition about #undo as well?
17:11:52 <pschindl> yours is better
17:11:55 <kparal> #undo
17:11:55 <zodbot> Removing item from minutes: ACTION by pschindl at 17:11:28 : cmurf to point out this bug on desktop list
17:11:59 <kparal> done
17:12:27 <kparal> sorry for meddling, I was impatient :)
17:15:39 <kparal> pschindl: next one?
17:15:40 <cmurf> brb
17:16:11 <pschindl_> sry, my connection just dropped, so I don't know what happened here
17:16:43 <kparal> pschindl_: nothing, we waited
17:17:09 <pschindl_> ok. So it dropped just before I sent a new topic. Cool.
17:17:22 <kparal> pschindl_: you probably need to rename yourself to get chair again
17:17:31 <pschindl> ok, now I'm chair again :)
17:17:52 <pschindl> kparal: that was what I waited for. Sorry for delay
17:18:02 <pschindl> #topic (1320396) [abrt] gnome-software: magazine_chain_pop_head(): gnome-software killed by SIGSEGV
17:18:05 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1320396
17:18:07 <pschindl> #info Accepted Blocker, gnome-software, NEW
17:19:07 <kparal> I tried basically this today
17:19:09 <kparal> no crash
17:19:43 <kparal> only one crash in FAF
17:19:50 <kparal> I'd close this as fixed
17:20:01 <kparal> adamw can reopen if he can reproduce
17:20:25 <pschindl> kparal: ok. Should I write info or you are already writing it? :)
17:20:39 <kparal> I'll update the bug, #info is yours :)
17:21:20 <pschindl> #info kparal tested this and the bug seems to be fixed.
17:21:39 <pschindl> #action kparal to close this bug as fixed
17:21:52 <pschindl> #topic (1320273) chainloading bootmgr.efi on UEFI results in error: out of memory
17:21:55 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1320273
17:21:57 <pschindl> #info Accepted Blocker, grub2, NEW
17:23:04 <kparal> somebody needs to ping pjones
17:23:32 <kparal> us timezone would help
17:24:01 <kparal> cmurf: or maybe you have tried already? I recall something
17:24:12 <kparal> about pjones not responding to your requests?
17:24:12 <cmurf> back
17:24:26 <cmurf> I gave pjones requested info and it confused him.
17:24:42 <kparal> ok, so it's actively being worked on
17:24:46 <cmurf> But it's in progress as best as I can tell. Worst case, the UEFI Secure Boot patch for chainloader gets reverted.
17:24:58 <kparal> ok, in that case no action needed
17:25:52 <pschindl> #info there is some progress even though it is not visible in bugzilla
17:26:19 <pschindl> #topic (1293167) [abrt] kf5-kinit: qt_message_fatal(): kdeinit5 killed by SIGABRT
17:26:21 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1293167
17:26:23 <pschindl> #info Accepted Blocker, kf5-kinit, NEW
17:27:02 <kparal> so, there's a question whether user switching is covered by criteria
17:27:26 <kparal> not explicitly, but I'm quite sure we blocked on it in the past as a conditional violation
17:28:05 <kparal> same as here
17:28:26 <kparal> it's sad they might need to disable it completely
17:28:44 <cmurf> ahh that's there work around for it being a blocker?
17:29:04 <kparal> well it's valid
17:29:05 <cmurf> s/there/their
17:29:11 <kparal> it's all about manpower
17:29:30 <cmurf> sure but they aren't arguing it's not a blocker they're just taking out the user switching feature?
17:29:56 <kparal> I think rdieter is basically asking us whether he should do that
17:30:02 <cmurf> so they have an alternative suggestion?
17:30:21 <kparal> I don't see any
17:31:09 <cmurf> They say user switching is pretty broken
17:31:17 <cmurf> So maybe best to just see it go away if it can't be maintained
17:32:10 <cmurf> I think it stays as a blocker and leave it up to KDE to remove user switching or fix it. *shrug*
17:32:19 <kparal> I guess so
17:32:24 <kparal> I'll write up an answer
17:34:18 <pschindl> #action kparal to send comment with our suggestion
17:34:38 <pschindl> #topic (1318470) failure to mount persistent overlay when booting live USB
17:34:41 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1318470
17:34:43 <pschindl> #info Accepted Blocker, livecd-tools, ON_QA
17:34:47 <cmurf> fixed
17:35:05 <cmurf> that means it's VERIFIED?
17:35:51 <pschindl> I think so
17:36:28 <kparal> the fc24 is not stable yet
17:36:32 <cmurf> I gave it karma in bodhi
17:36:48 <kparal> we can switch to verified, but they still need to push it to stable
17:37:06 <kparal> you can ask bcl to do that, or maybe he wants to wait some more
17:37:17 <cmurf> oh wait I didn't
17:37:43 <kparal> satellit did
17:37:57 * kparal switched it to verified
17:39:02 <pschindl> #info fix was verified. The update now needs to get to stable.
17:39:20 <pschindl> #topic (1330766) [abrt] realmd: g_cancellable_is_cancelled(): realmd killed by SIGSEGV
17:39:22 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1330766
17:39:24 <pschindl> #info Accepted Blocker, realmd, NEW
17:39:46 <cmurf> seems it has a recent update
17:40:19 <kparal> yep, they're working on this
17:40:36 <kparal> no action from us needed
17:41:58 <kparal> pschindl: are you with us?
17:42:13 <kparal> #info devs are working on this, no action from us needed
17:42:28 <kparal> #chair pschindl_
17:42:28 <zodbot> Current chairs: cmurf coremodule garretraziel kparal pschindl pschindl_ tflink
17:42:37 <kparal> pschindl: I added info
17:42:47 <kparal> let's just transition to the next bug
17:43:04 <pschindl_> kparal: Thanks. I send info too, but my connection isn't in shape today :(
17:43:32 <pschindl_> #topic (1314637) SELinux is preventing fwupd from 'write' accesses on the directory 0000:00:02.0.
17:43:35 <pschindl_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1314637
17:43:37 <pschindl_> #info Accepted Blocker, selinux-policy, MODIFIED
17:43:51 <kparal> this needs testing from QA
17:43:52 <pschindl_> kparal: you sent info to 1330766?
17:44:07 <kparal> pschindl_: yes
17:44:22 <pschindl_> yes, that is my fault, I had action, I will take it again.
17:44:22 <kparal> the selinux-policy build is long stable
17:44:26 <kparal> ok
17:44:31 <kparal> I'll update the bug
17:45:54 <kparal> pschindl_: down again?
17:45:59 <kparal> I guess I'll lead it
17:46:06 <pschindl_> #action pschindl to test if this bug is really fixed as noted in comment 2
17:46:24 <kparal> still here, good :)
17:46:31 <pschindl_> #topic (1316514) SELinux is preventing colord from 'read' accesses on the file /etc/udev/hwdb.bin.
17:46:33 <pschindl_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1316514
17:46:35 <pschindl_> #info Accepted Blocker, selinux-policy, MODIFIED
17:46:42 <kparal> I guess I'd close this one
17:46:52 <kparal> all reports are with -179 build
17:47:01 <cmurf> yep
17:47:06 <kparal> -180 should have fixed it, and no report since then
17:47:44 <pschindl_> I installed F24 today and no alert after boot
17:47:50 * kparal closing this
17:47:53 <pschindl_> So I it seems to be fixed
17:48:35 <pschindl_> #info this bug is fixed and update is in stable. kparal will close it
17:48:50 <pschindl_> #topic (1318045) Incorrect keymap when decrypting encrypted partitions
17:48:53 <pschindl_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1318045
17:48:55 <pschindl_> #info Accepted Blocker, systemd, NEW
17:49:15 <cmurf> looks like it might need a nudge
17:49:30 <kparal> we need to supply some logs
17:49:32 <cmurf> there's uncertainty from systemd dev on getting journal info
17:49:39 <cmurf> yes
17:49:42 <kparal> volunteers?
17:49:52 <cmurf> maybe early debug shell being enabled might help?
17:50:09 <pschindl_> I'll do it.
17:50:28 <kparal> pschindl_: maybe ask Pavel to do this? just an idea
17:50:47 <kparal> might be too difficult for him
17:50:51 <pschindl_> #action pschindl to test this and provide some logs to developers.
17:51:03 <kparal> and that's it!
17:51:18 <pschindl_> #topic Open floor
17:51:54 <cmurf> whew!
17:51:58 <pschindl> something for discussion?
17:52:15 <pschindl> or do you have enough of meetings for today?
17:52:20 <cmurf> remember when these took 5 hours and we had a break over two days?
17:52:35 <cmurf> the early start helped
17:52:38 <pschindl> I tried to forgot :)
17:53:02 * kparal found yet another gnome-software bug. I'm cursed
17:53:11 <cmurf> oooh exciting
17:53:13 <cmurf> what bug now?
17:53:33 <kparal> we can talk after meeting is over :)
17:54:01 <cmurf> ok i have nothing
17:54:30 <coremodule> Nothing here.
17:54:42 <tflink> kparal: or gifted :)
17:54:56 <pschindl> #endmeeting