16:00:11 <roshi> #startmeeting F23-blocker-review
16:00:11 <zodbot> Meeting started Mon Oct 19 16:00:11 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:12 <roshi> #meetingname F23-blocker-review
16:00:12 <zodbot> The meeting name has been set to 'f23-blocker-review'
16:00:12 <roshi> #topic Roll Call
16:00:16 <roshi> who's around?
16:00:27 * pschindl is here
16:00:44 <adamw> ahoy to the oy
16:00:47 <sgallagh> .hello sgallagh
16:00:48 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:01:08 * satellit_e listening but have to go out soon
16:01:19 * kparal is here
16:01:42 * brunowolff is still sleepy.
16:01:47 * pwhalen is here
16:01:59 <roshi> sweet, good turnoug :)
16:02:20 <sgallagh> pwhalen: BTW, I saw you were running through ARM Server tests. Thanks for that
16:02:32 <roshi> #chair adamw pschindl sgallagh satellit_e kparal brunowolff pwhalen
16:02:32 <zodbot> Current chairs: adamw brunowolff kparal pschindl pwhalen roshi satellit_e sgallagh
16:02:36 * nirik is here
16:02:37 <roshi> turnout, even
16:02:43 <roshi> #chair nirik
16:02:44 <zodbot> Current chairs: adamw brunowolff kparal nirik pschindl pwhalen roshi satellit_e sgallagh
16:02:53 <roshi> #topic Introduction
16:02:53 <roshi> Why are we here?
16:02:54 <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:02:57 <pwhalen> sgallagh, np :)
16:02:58 <roshi> #info We'll be following the process outlined at:
16:03:00 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:03 <roshi> #info The bugs up for review today are available at:
16:03:05 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:08 <roshi> #info The criteria for release blocking bugs can be found at:
16:03:10 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria
16:03:13 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria
16:03:14 <danofsatx> yay! Just in time!
16:03:16 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
16:03:21 <roshi> #chair danofsatx
16:03:21 <zodbot> Current chairs: adamw brunowolff danofsatx kparal nirik pschindl pwhalen roshi satellit_e sgallagh
16:03:32 <roshi> we've got 6 proposals to look through
16:03:34 <roshi> first up...
16:03:35 <roshi> #topic (1272737) Black screen after logout
16:03:35 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1272737
16:03:35 <roshi> #info Proposed Blocker, gdm, NEW
16:04:14 * adamw is checking this with a non-SPICE VM atm
16:04:30 <adamw> myself, jpigface and kparal have all hit it in KVM testing, i tested on one  bare metal system and didn't hit it
16:05:02 <sgallagh> I have not seen this on my baremetal system either
16:06:18 * adamw stares at install percentage
16:07:16 * satellit_e memory allocation in KVM?
16:07:54 <kparal> I think it's a race and VMs are just more prone to it, maybe fewer CPUs or something
16:07:59 * roshi is testing in a vm with 4gb ram now
16:08:36 <adamw> mine has 2GB
16:08:50 <roshi> and 2 cores - just finishing up the install
16:08:50 <sgallagh> If this is still going through active testing, shall we cover the other bugs and come back to this?
16:08:58 <roshi> sure, can do
16:09:04 <roshi> #topic (1272646) gnome-keyring prevents the graphical login into a mate session
16:09:07 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1272646
16:09:10 <roshi> #info Proposed Blocker, gnome-keyring, ON_QA
16:09:31 <pwhalen> +1 this also affects the arm xfce image. fixed with the update
16:09:57 <satellit_e> affects cinnamon and mate lives after install
16:10:07 <roshi> if it hits the arm images, +1
16:10:25 <pschindl> +1
16:10:29 <satellit_e> +1
16:10:35 <adamw> +1, and the fix is confirmed
16:10:37 <kparal> this also contains fixes for  	1269581, which is already an accepted blocker
16:10:48 <sgallagh> +1 blocker
16:11:43 <roshi> proposed #agreed - 1272646 - AcceptedBlocker Final - This bug is a violation of the following Alpha criterion: "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."
16:12:08 <pschindl> ack
16:12:13 <satellit_e> ack
16:12:14 <pwhalen> ack
16:12:20 <roshi> #agreed - 1272646 - AcceptedBlocker Final - This bug is a violation of the following Alpha criterion: "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."
16:12:25 <roshi> #topic (1273102) Gnutls Servers (eg: cockpit) fail fallback with Google Chrome 46
16:12:28 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1273102
16:12:30 <roshi> #info Proposed Blocker, gnutls, NEW
16:13:10 * nirik is -1 blocker
16:13:20 <sgallagh> So, there is additional information in the bug now
16:13:32 <sgallagh> It appears to apply to any GnuTLS service
16:13:35 * nirik reloads
16:13:47 <sgallagh> Cockpit just happens to be the one that we have blocker criteria for
16:14:36 <danofsatx> Chrome is not a default browser, FF is. -1 blocker.
16:14:36 <adamw> hmm, i thought our ootb gnutls config was okay.
16:15:12 <sgallagh> danofsatx: It's not, but it also makes up a huge percentage of the browser usage.
16:15:40 <danofsatx> I understand that - but it doesn't meet blocker criteria IMHO. FF is the default browser, Cockpit works in FF.
16:16:13 <sgallagh> danofsatx: The criteria doesn't mention the browser.
16:16:35 <danofsatx> again, I understand that.
16:16:39 <nirik> well, it's also likely this will be fixable in updates?
16:17:02 <nirik> which of course won't help dvd installs... but netinstalls should get the updated gnutls
16:17:19 <sgallagh> Yeah, but the problem is that Cockpit is the face of Server
16:17:27 <kparal> unless it's a bug in google chrome, I'd assume it's an enough widely used browser to fix a server issue for
16:17:35 <roshi> are we sure this isn't a bug in chrome?
16:17:40 <sgallagh> If you can't access it off a DVD install, it's a bad first experience
16:18:28 * nirik hates blocking on some non free thing
16:18:45 <sgallagh> roshi: Trying to find out. One moment.
16:18:58 <adamw> i'm not sure we are sure.
16:19:00 <danofsatx> did it work in 45?
16:19:11 <kparal> sgallagh: so, can we reproduce the issue in epiphany by somehow working around that unrelated crash?
16:19:11 <adamw> danofsatx: that wouldn't necessarily mean anything
16:19:17 <sgallagh> danofsatx: 46 explicitly made TLS/SSL changes related to avoiding downgrade attacks
16:19:28 <adamw> there are kinda two possibilities: chrome tightened its requirements for TLS/SSL connections to a level our default gnutls doesn't honour
16:19:35 <danofsatx> it would mean it was exposed by 46, which had some pretty radical changes under the hood
16:19:35 <adamw> ...or, chrome just flat out introduced a bug
16:19:42 <sgallagh> kparal: Epiphany doesnt' work with Cockpit at all, never has.
16:19:50 <sgallagh> It lacks support for websockets
16:19:53 <kparal> ok
16:20:01 * danofsatx doesn't think Konquerer does, either
16:20:19 <danofsatx> but I'll find out here in a few minutes.
16:21:13 <sgallagh> (As an aside: I *want* to be convinced that this isn't a blocker. I'm just not comfortable with the user experience here.)
16:22:18 <danofsatx> I really don't feel we should block on a bug only visible through a non-free product that is not part of the FEdora ecosystem
16:22:44 <sgallagh> danofsatx: Well, without understanding if this is a tightening or a bug in Chrome, that's a tough call to make
16:22:46 <adamw> danofsatx: i do think we have to honour what people are using in practice
16:22:57 <adamw> and yeah, i'd like to know more
16:23:00 <sgallagh> If it's a tightening, then other browsers will also likely follow suit
16:23:07 <adamw> have we googled this to see if it's something other people are running into? might be more info out there
16:23:15 <roshi> would we block if google accounts didn't work on workstation?
16:23:20 <roshi> the online accounts bit?
16:23:28 <adamw> roshi: i don't see that that's at all comparable
16:23:54 <roshi> it's highly used, tied to non-free
16:24:20 <roshi> if chrome wouldn't even install, would we block?
16:24:39 <roshi> (this is all moot, if it's a tightening, since other browsers will follow)
16:25:36 <roshi> w/o knowing about the tightening, I lean +1 FE to cockpit to add a note to chrome users, that they should use FF for connecting to Cockpit
16:25:51 <sgallagh> roshi: FWIW, current usage estimates have Chrome representing more than 50% browser share
16:26:03 <sgallagh> So disregarding it as non-free seems... problematic
16:26:08 <danofsatx> sgallagh: have you tested Chromium, by chance?
16:26:13 <roshi> oh yeah - I'm aware of the numbers
16:26:24 <sgallagh> danofsatx: I have not.
16:26:34 <sgallagh> I don't think Chromium 46 is in the repos yet
16:26:51 <roshi> but I'm also fine leaving this up to the Server WG, as this is their baby
16:27:13 <sgallagh> I'm definitely +1 FE at the minimum.
16:27:28 <sgallagh> I'm just trying to figure out if it's worth blocking the release on if we don't have a fast solution
16:27:37 <sgallagh> s/fast/immediate/
16:27:52 <nirik> how about we FE it now and try and gather more info
16:28:00 <danofsatx> agreed
16:28:09 <adamw> that needs to have a horizon of, like, houes
16:28:12 <adamw> hours*
16:28:15 <adamw> go/no-go is thursday.
16:28:19 * danofsatx is testing as we argue
16:28:37 <danofsatx> s/argue/discuss violently
16:28:40 * nirik nods. But we aren't even sure if it's in gnutls or what versions of chrome or much... it just landed in our laps
16:28:47 <adamw> sgallagh: also https://github.com/cockpit-project/cockpit/issues/2897 ?
16:29:06 <adamw> which says Chromium 45
16:29:16 <sgallagh> adamw: Yeah, that looks like the same behavior.
16:29:19 <sgallagh> OK, so it's probably 45+
16:29:53 <nirik> gnutls seems to have a bug tracker, but also a bugs mailing list and the two don't seem to be the same. ;(
16:30:06 <adamw> my favourite kind of project!
16:30:27 <sgallagh> If it's 45+, that lends credence to the hardening argument.
16:30:40 <kalev> we have nmav working on gnutls and he's usually very very responsive
16:30:46 <sgallagh> I suspect if it was a bug, it wouldn't have survived two releases; Google is pretty good about that
16:31:33 <sgallagh> I'll try to get ahold of Nikos
16:31:38 <sgallagh> In the meantime, +1 FE?
16:31:59 <adamw> sure.
16:32:00 <kalev> I can be +1 FE, definitely.
16:32:25 <pwhalen> +1 FE
16:32:51 <nirik> +1 FE for sure
16:32:53 <danofsatx> +1 FE
16:33:08 <kparal> +1 FE
16:33:13 <roshi> proposed #agreed - 1273102 - AcceptedFreezeException Final - Due to the popularity of the Chrome, we'd consider a patch for this during freeze. However, more information is needed before we can determine blocker status on this bug."
16:33:25 <pwhalen> ack
16:33:29 <kalev> ack
16:33:30 <adamw> ack
16:33:30 <pschindl> ack
16:33:33 <roshi> #agreed - 1273102 - AcceptedFreezeException Final - Due to the popularity of the Chrome, we'd consider a patch for this during freeze. However, more information is needed before we can determine blocker status on this bug.
16:33:33 <danofsatx> ack
16:33:51 <roshi> #topic (1250712) kernel panic when booting a LiveUsb created with liveusb-creator
16:33:54 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1250712
16:33:57 <roshi> #info Proposed Blocker, liveusb-creator, NEW
16:34:30 <satellit_e> looks like fix works https://fedoraproject.org/wiki/Test_Results:Fedora_23_Final_TC11_Installation#USB_media
16:34:45 * nirik is confused as to when this bug hits.
16:35:15 <satellit_e> problem may be due to different way gnomedisks-restore dd and li format a USB
16:35:28 <adamw> this seems a little fuzzy.
16:35:33 <adamw> dd doesn't really format anything.
16:35:51 <nirik> dd should always work...
16:35:58 <satellit_e> 23 disks-restore yields iso 9660 hidden hpfs/ntfs (bootable) files structure on USB
16:36:24 <satellit_e> then need to do gparted new mbr to get it to work with liveusb-creator
16:37:11 <nirik> so it happens when you use dd and then later use l-u-c?
16:37:30 <adamw> there are two people in the report, apparently reporting different things.
16:37:30 <satellit_e> new USB is OK but not a reused one
16:38:00 <adamw> we've known for a long time that l-u-c's copy method is somewhat subject to the previous content of the stick and the parameters you pass (which is why it's the least-recommended of the recommended methods)
16:38:06 <adamw> that's nothing new or blocker-worthy
16:38:20 <satellit_e> known bugs?
16:38:31 <adamw> jpigface seems to be saying he sometimes hits problems using luc's dd mode or even dd directly (cf. #c13), which would be new, but the data seem a little thin.,
16:38:37 * adamw hasn't hit a problem with a dd write this cycle.
16:38:45 <adamw> (but i guess jpigface has done a lot more of them than me/
16:38:47 * roshi hasn't had any problems with dd
16:38:54 * nirik neither
16:38:57 <adamw> it's possible he just has a marginal usb stick.
16:39:01 <adamw> usb sticks being freaking terrible.
16:39:11 <satellit_e> dd and gnome-disks work for me but need to reformat USB for other methods
16:39:15 <kparal> please note that even with dd you can end up with corrupted medium, if you don't unmount previous partitions first. they can be later synced and some bits overwritten, even though that part table is no longer there
16:39:30 <adamw> ah, yeah, that's a point
16:39:35 * adamw is always careful to unmount first
16:39:50 <kparal> but at least with dd you can verify medium during boot. with cp mode you can't
16:39:52 <nirik> or the stick could die, or it could lie about it's size, or...
16:40:08 * adamw should check that unmounting first is in the instructions, in fact...
16:40:13 <satellit_e> (cp) works with update
16:40:16 <adamw> so i'm inclined to -1 this as no-one else has issues with dd.
16:40:29 <nirik> -1 here without further info/reproducers
16:40:35 <danofsatx> -1
16:40:37 <roshi> -1
16:40:41 <satellit_e> -1
16:40:44 <pwhalen> -1
16:41:30 <kparal> -1, let's evaluate again if more people hit this
16:41:45 <satellit_e> common bugs?
16:42:02 <roshi> proposed #agreed - 1250712 - RejectedBlocker Final - This bug doesn't clearly demonstrate where the problem actually lies, so not considered a blocker. However, if more people hit this bug and it's narrowed down, please re-propose.
16:42:10 <kalev> ack
16:42:16 <satellit_e> ack
16:42:20 <pschindl> ack
16:42:26 <adamw> ack
16:42:27 <roshi> #agreed - 1250712 - RejectedBlocker Final - This bug doesn't clearly demonstrate where the problem actually lies, so not considered a blocker. However, if more people hit this bug and it's narrowed down, please re-propose.
16:42:36 <roshi> #topic (1264012) liveusb-creator doesn't create bootable Live i686 image in default cp mode
16:42:39 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1264012
16:42:41 <roshi> #info Proposed Blocker, liveusb-creator, VERIFIED
16:42:54 * danofsatx suspects this is closely related to the previous one
16:42:56 <satellit_e> fixed for me
16:42:58 <danofsatx> so I'm -1 here, too
16:43:10 <adamw> no, it's not at all.
16:43:14 <danofsatx> ....but kparal says it's fixed
16:43:30 <adamw> it's the syslinux vs. gcc 5 issue.
16:43:50 <satellit_e> su -c 'dnf --enablerepo=updates-testing update syslinux'
16:44:02 <adamw> i think possibly the most sensible thing to do here is close it as a dupe of the other one
16:44:11 <adamw> since it turned out they *did* both have the same cause
16:44:16 <nirik> yeah, no need to have 2 bugs on the same thingie.
16:44:26 <roshi> yeah
16:44:48 <danofsatx> +1 dupe
16:44:57 <satellit_e> +1
16:44:59 <adamw> ok, i'll dupe it then
16:45:08 <roshi> thanks adamw
16:45:15 <roshi> moving on...
16:45:23 <adamw> #1263988 is the other bug for the record
16:45:40 <roshi> #info marking this bug as a dupe of #1263988
16:45:51 <roshi> #topic (1271061) [abrt] setroubleshoot-server: g_callable_info_free_closure(): python3.4 killed by SIGSEGV
16:45:54 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1271061
16:45:56 <roshi> #info Proposed Blocker, setroubleshoot, ASSIGNED
16:46:10 * satellit_e afk
16:46:21 * nirik hasn't noticed this one... :(
16:47:08 <adamw> wow, yeah, me either :( i see it now though
16:47:13 <sgallagh> I can reproduce it
16:47:30 <adamw> +1, i'd say
16:47:59 <sgallagh> Is the troubleshooter part of the default install set?
16:48:01 <sgallagh> If so, +1
16:48:07 <kparal> yes
16:48:09 <adamw> yes
16:48:42 <pwhalen> +1
16:48:47 <adamw> anyone sit near petr? :)
16:48:47 <nirik> +1 sadly
16:48:59 <nirik> note: I do not see this in rawhide FWIW
16:49:00 <roshi> +1
16:49:09 <kalev> +1
16:49:37 <roshi> proposed #agreed - 1271061 - AcceptedBlocker Final - This bug is a violation of the following Final criterion: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
16:50:02 <sgallagh> ack
16:50:14 <kparal> well it does not crash for me
16:50:21 <kparal> it's just all pre-filled with label
16:50:21 <adamw> but it doesn't work, right?
16:50:27 <kparal> there are no reports
16:50:32 <adamw> the report says it crashes when he clicks 'details'
16:50:35 <kparal> I think "label" is a default value
16:50:38 <kparal> of those fields
16:50:50 <nirik> ack
16:50:59 <adamw> hmm, hold on a bit i guess
16:51:02 <kparal> all the buttons do nothing for me
16:51:11 <adamw> i think we need to have an alert to see what happens
16:51:20 * adamw tries to think how to generate one
16:51:28 * kparal trying Live now
16:51:29 <sgallagh> HAH!
16:51:39 <sgallagh> It doesn't happen in permissive mode.
16:51:48 <sgallagh> Looks like SELinux is breaking the SELinux troubleshooter.
16:51:51 <sgallagh> That's hilarious.
16:52:29 <nirik> nice.
16:52:51 <pwhalen> heh
16:52:52 <kparal> on Live I also see no reports and buttons doing nothing, which is kinda ok
16:53:07 <kparal> how to generate a selinux denial?
16:53:12 <sgallagh> Yeah, I don't get the crash, but that's kind of irrelevant
16:54:30 <sgallagh> adamw: Can you confirm that you're not seeing it in permissive mode also?
16:54:42 <adamw> i don't think it's irrelevant.
16:54:50 <adamw> how the app behaves when there's no AVC present isn't really interesting
16:55:00 <adamw> what matters is how it behaves when there is an AVC...
16:55:00 <sgallagh> adamw: I had AVCs present
16:55:02 <adamw> ah k
16:55:18 <nirik> sudo chcon -t bin_t /etc/crontab; wait for cron to try and read it perhaps?
16:55:23 <adamw> aha, OK
16:55:26 <adamw> i actually have some AVCs
16:55:33 <adamw> and indeed with setenforce Permissive i see them properly
16:55:47 <adamw> so yeah i don't get teh crash, but the behaviour is clearly broken, it's not just a weird default state
16:55:50 <adamw> so ack
16:56:10 <roshi> #agreed - 1271061 - AcceptedBlocker Final - This bug is a violation of the following Final criterion: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
16:56:13 <kalev> I guess that's a good indication how many people here run enforcing and how many run permissive :)
16:56:19 <roshi> lol
16:56:39 <roshi> #topic Bug 1273119 - Updated PackageKit cached metadata for Workstation live media
16:56:45 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1273119
16:57:14 <roshi> #info proposed blocker, packagekit, NEW
16:57:19 <sgallagh> kalev: I run enforcing all the time. I just usually ignore AVCs unless they're stopping me from doing something :)
16:57:20 <kalev> I filed it as a blocker because gnome-software is pretty much unable to install anything right now, until it has done the daily metadata refresh in the background
16:57:45 <sgallagh> kalev: We should probably just make this part of the Release Candidate SOP
16:57:54 <sgallagh> That this has to happen at compose time
16:58:12 <kalev> I have a patch ready to go that makes it all automatic :)
16:58:30 <nirik> I'm not sure I would call this a blocker, but I am +1 to pull it in.
16:58:31 <kalev> that's actually the gist of the fix, making it all automatic so that it would just work from now on
16:58:45 <nirik> (and thanks for asking instead of just commiting to spins-kickstarts)
16:58:48 <sgallagh> I'm -1 blocker, but +1 FE
16:59:01 <adamw> +1 FE, sure
16:59:08 <kparal> kalev: you made my day :)
16:59:12 <kparal> +1 FE
16:59:14 <kalev> great :)
16:59:15 <danofsatx> -1B/+1FE
16:59:17 <adamw> though i kind of hate this mechanism from a high level perspective
16:59:27 <adamw> i hate anything which requires package rebuilds right before we ship as a matter of principle
16:59:35 <kalev> yes, I am getting rid of that!
16:59:38 * adamw knows nothing about the details, just doesn't like it ;)
16:59:51 <kalev> it used to be that we needed a package rebuild. if I land this, we don't need it any more.
16:59:51 <nirik> this is much better than that
16:59:56 <adamw> then yay
16:59:59 <kparal> :)
17:00:00 <adamw> +1 FE with gusto!
17:00:09 <nirik> verve!
17:00:12 <sgallagh> Yech, I think you got some gusto on me
17:00:15 <adamw> vigor!
17:00:15 <kparal> -1 blocker, though
17:00:25 <adamw> the little-known b-side, Pour Some Gusto On Me
17:00:34 <sgallagh> /me snorts
17:01:22 <adamw> probably -1 blocker too, it's kinda more an inconvenience
17:01:40 <roshi> proposed #agreed - 1273119 - RejectedBlocker AcceptedFreezeException Final - We'd gladly allow this to come in during freeze, but won't block release on it.
17:01:47 <nirik> ack
17:01:49 <sgallagh> ack
17:01:51 <kalev> ack
17:01:53 <pschindl> ack
17:01:58 <roshi> #agreed - 1273119 - RejectedBlocker AcceptedFreezeException Final - We'd gladly allow this to come in during freeze, but won't block release on it.
17:02:08 <roshi> ok, back to the first one
17:02:09 <roshi> #topic (1272737) Black screen after logout
17:02:09 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1272737
17:02:10 <roshi> #info Proposed Blocker, gdm, NEW
17:02:54 <nirik> do we have critera this hits?
17:02:59 <nirik> (does seem nasty tho)
17:03:01 <kparal> newer systemd didn't fix this for me
17:03:02 <adamw> so, kparal reproduced in rawhide, and i reproduced with vnc.
17:03:04 <adamw> nirik: sure
17:03:06 <roshi> so, on my vm install, I can't even log in through gdm
17:03:15 * nirik sees
17:03:16 <kparal> adamw: not with rawhide, but with systemd from rawhide
17:03:19 <roshi> I can ctrl-alt-f3 and log in there
17:03:23 <roshi> and then startx
17:03:25 <roshi> but that's it
17:03:28 <adamw> "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops."
17:03:35 <roshi> soon as I try to switch back it all freezes
17:03:40 <adamw> https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria#desktop-shutdown-reboot-logout
17:03:41 <roshi> (4GB ram and 2 cores)
17:03:59 <nirik> roshi: do you get the gdm login screen? or ?
17:04:07 <adamw> this is a conditional violation, the condition we know about so far being...use a VM? which is kind of an odd condition, so it's probably a proxy for something else (speed or RAM or whatever)
17:04:13 <roshi> yeah, it shows up - but then never actually logs in
17:04:21 <roshi> gdm does, I mean
17:04:30 <halfline> roshi: do you have nvidia with proprietary drivers?
17:04:41 <halfline> oh
17:04:43 <halfline> you said vm above
17:04:45 <roshi> yeah
17:04:52 <roshi> but yeah, it's a vm
17:04:57 <halfline> interesting
17:05:03 <nirik> but it's an installed vm? so the live booted ok to install?
17:05:04 <kparal> so far we haven't seen it with bare metal. but not tried hard enough yet
17:05:04 <halfline> what do you see after you tpye the password?
17:05:13 <halfline> roshi: just the gray texture ?
17:05:16 <roshi> yep
17:05:18 <kparal> nirik: I always tried with installed
17:05:25 <halfline> roshi: when that happens if you hit "escape" dose it log you in?
17:05:28 <roshi> the live booted fine and installed
17:05:45 <roshi> uh
17:05:46 <roshi> yeah
17:05:48 <roshi> lol
17:05:48 <halfline> (when you're sitting at the gray texture)
17:06:06 <halfline> it does?
17:06:18 <roshi> yeah, it did
17:06:28 <roshi> and the enxt login worked fine too
17:06:31 <halfline> \o/
17:06:37 <halfline> can i get a copy of your vm ?
17:06:42 <halfline> been trying to reproduce that bug for weeks
17:06:58 <halfline> it's actually what i was looking at this morning that was taking up my time
17:07:02 <roshi> 3rd I had to hit escape again
17:07:07 <halfline> yea every other time
17:07:08 <adamw> huh, i haven't seen that one yet
17:07:55 <roshi> ha, yeah, every other time
17:08:09 <halfline> adamw: https://bugzilla.gnome.org/show_bug.cgi?id=754814
17:08:22 <roshi> but I don't get the black screen after logout
17:08:24 <roshi> not once
17:08:29 <adamw> halfline: i mean, i haven't hit it myself
17:08:33 <adamw> yay for heisenbugs
17:08:43 * adamw sticks 4GB in his VM and tries again
17:09:00 <halfline> roshi: this is a throw away vm ?
17:09:04 <roshi> I did see this "got pause for" stuff
17:09:04 <halfline> roshi: can i get a copy?
17:09:19 <roshi> you mean of the xml? or the whole kit and caboodle?
17:09:21 <nirik> so where are we on this bug? I guess it's a blocker unless we can come up with a workaround or find it's hard to hit?
17:09:26 <halfline> roshi: EVERYTHING
17:09:33 <danofsatx> ALL THE THINGS
17:10:18 <roshi> sure, it's 16GB though
17:10:38 <halfline> well how many of those 16gb are zeros ? i mean if you gzip it how small is it?
17:10:57 <roshi> as for this bug, 1272737, I haven't reproduced it
17:11:10 <roshi> lemme turn it off and see
17:11:41 * danofsatx is moving to the lab. Please stand by.
17:11:48 * nirik goes to get more coffee.
17:11:48 <adamw> nirik: mmm, i'm kinda on the fence if we have no metal reproducer
17:11:53 <adamw> but if someone has a slow system to test on...
17:12:27 <nirik> if it's only on installed vm's... it could be fixed in an update as well right? (and hitting power off in a vm isn't too hard)
17:12:44 <kparal> on bare metal, I wait about 20 seconds for every log out attempt, don't know why. latest packages. so it's hard to reproduce this. but I'm working on it :)
17:13:07 <roshi> these log outs have been snappy
17:13:10 <adamw> nirik: all logout issues are by definition for installed systems only
17:13:13 <roshi> 1-2 seconds to get back to gdm
17:13:19 <adamw> but we still have the criterion because we want it to work ootb
17:13:39 <adamw> hmm, still hit it with 4GB RAM, on the third logout (first two worked)
17:14:54 <nirik> kparal: the gnome-keyring thing? or you have that?
17:15:01 <Southern_Gentlem> adamw, what iso is this
17:15:08 <kparal> nirik: yes, fixed version
17:15:17 <adamw> nirik: i'm testing the black screen on logout. i dunno what anyone else is doing.
17:15:30 <nirik> ok, just checking.
17:15:47 <halfline> (sorry to derail your meeting with a different bug earlier)
17:15:47 <adamw> and we've already confirmed it happens with the newest available gnome-keyring, yes.
17:15:50 <nirik> adamw: was wondering if that was the cause of kparal's 20 second delays on logouts... since it caused delays
17:16:09 <kparal> yes, good call. apparently it's a different bug
17:17:26 <kparal> it seems I can't reproduce black gdm screen on bare metal
17:17:49 <kparal> in VM, I sometimes needed about 10 logouts
17:18:01 <kalev> probably something timing related
17:18:32 <kparal> I'm around the same number on bare metal now. but it's hard to judge whether it's not affected or I'm just less lucky
17:18:49 <kparal> or the log out delay issue is somehow interfering with it
17:19:46 * pwhalen is setting up an arm system to try..
17:20:05 <adamw> i usually get it in the first three logouts
17:20:30 <adamw> halfline: would it be at all interesting to test with wayland disabled?
17:20:51 <halfline> yea
17:21:14 <adamw> ok, coming up.
17:21:57 <halfline> be back in a second, gotta make a phone call
17:24:00 <roshi> well, I can't reproduce, but found an elusive but
17:24:05 <roshi> *bug
17:24:24 <roshi> kparal might be in the same boat, can't find this but does another
17:24:52 <kparal> I haven't yet reproduced it with wayland disable
17:24:53 <kparal> d
17:25:32 <kparal> and I have done quite a few roundtrips
17:26:33 <kparal> adamw: what's your experience?
17:26:42 <adamw> me either
17:26:45 * adamw still doing trips
17:26:55 <kparal> I have done at least 20 logouts now
17:27:03 * adamw up to 7
17:27:18 <adamw> i think we can call it - definitely wayland
17:27:34 <kparal> quite possibly wayland
17:27:42 <kparal> :)
17:28:01 <kparal> but I'm not sure why we all reproduce it only in VM
17:28:53 * roshi never reproposed it
17:28:57 <roshi> er
17:29:00 <roshi> reproduced it
17:29:09 <roshi> man, can I haz typing skillz today?
17:29:14 <roshi> sheesh
17:29:44 <adamw> .fire roshi
17:29:44 <zodbot> adamw fires roshi
17:29:45 <kparal> I give up, can't reproduce with xorg gdm
17:29:58 <roshi> me is trying again
17:30:00 <kparal> halfline: ^^
17:30:05 <adamw> so...i'm definitely +1 FE.
17:30:24 <pwhalen> ok, think i reproduced on arm (or its really slow)root
17:30:44 <adamw> pwhalen: how long did you wait? :)
17:31:05 <adamw> pwhalen: try it a few times, and try with wayland disabled (edit /etc/gdm/custom.conf and uncomment the obvious line, then reboot)
17:31:32 <pwhalen> ok, its always been slow..but will do
17:31:35 <roshi> proposed #agreed - 1272737 - RejectedBlocker AcceptedFreezeException Final - There wasn't enough chance of reproducing this when it was attempted, so not considering this a blocker. However, we would consider a fix during freeze.
17:32:57 <kparal> are there any use cases for logging out in VM frequently?
17:33:08 <roshi> testing?
17:33:21 <kparal> perhaps streaming to a remote display in school classes?
17:33:26 <nirik> I guess I can ack that...
17:33:33 <adamw> roshi: what do you mean "there wasn't enough chance of reproducing this"?
17:33:36 <adamw> that doesn't make any sense to me.
17:33:48 <nirik> it doesn't happen all the time?
17:34:01 <nirik> or it happens infrequently enough we don't think it's a blocker?
17:34:08 <roshi> I meant it as happening sometimes, to some people
17:34:18 <adamw> eh, i'd prefer you make it clearer, then, it didn't read that way to me.
17:34:19 <sgallagh> patch
17:34:42 <adamw> but still - one person reported it, and four have tried reproducing so far (me, kparal, you, and pwhalen)
17:34:44 <roshi> proposed #agreed - 1272737 - RejectedBlocker AcceptedFreezeException Final - From several people all attempting to reproduce this, it wasn't seem often if at all, so not considering this a blocker. However, we would consider a fix during freeze.
17:34:52 <adamw> you're the only one who *hasn't* reproduced it, of those four, by my count.
17:35:04 <adamw> and...so far I've seen almost no actual votes
17:35:13 <adamw> so we seem to be skipping to the #agreed stage rather quickly
17:35:21 <roshi> votes then?
17:35:26 <roshi> I thought I'd seen votes
17:35:37 <danofsatx> -1
17:36:10 <roshi> -1 blocker, +1 FE
17:36:37 <nirik> I'm definitely +1 FE, I could go either way on blocker... it looks kinda bad, but it's just vms some of the time... so -0.5 blocker I guess
17:36:44 <adamw> nirik: we don't know that it's just VMs.
17:36:52 <adamw> we only know that *so far* we've only reproduced it in VMs.
17:37:06 <nirik> ok, kparal said he couldn't get it to happen on bare metal I thought...
17:37:17 <adamw> since we don't know what's causing the bug, we can't say that it only affects VMs. (i rather suspect it's not really about VMs at all but VM-iness is just a proxy for something else, but it's hard to be sure).
17:37:20 <adamw> sure, neither can i
17:37:30 <nirik> pwhalen: you did see it on bare arm?  ( har, bare arm)
17:37:30 <kparal> I couldn't, but there were other issues which might have affected it
17:37:30 <adamw> that's two bare metal systems out of...how many billions? :)
17:37:43 <pwhalen> i hit it first attempt on arm, trying again, but its slow
17:38:15 <adamw> some kind of timing issue seems the most likely candidate for the cause, and if that's the case i'd be surprised if at least some bare metal didn't hit it. but it's all guesswork.
17:38:22 <kparal> pwhalen: you reproduced it on bare metal arm?
17:38:31 <adamw> he think so
17:38:34 <adamw> he's confirming now
17:38:44 <kparal> ok, "great"
17:38:51 <kparal> not sure if it's good news or not :)
17:39:42 * adamw isn't necessarily saying +1, just want us to have our facts straight here. ;)
17:40:08 * roshi tried it in another VM, still didn't see it
17:40:18 <roshi> but also still saw halfline's bug
17:41:09 <adamw> roshi: on the same host
17:41:10 <adamw> ?
17:41:21 <roshi> yeah
17:41:24 <adamw> how fast is your host?
17:41:41 * roshi has reused an old vm by installing over it - so wanted to check on somethign fresh
17:41:50 <roshi> 16gb ram, 8 cores, ssd
17:42:11 <roshi> lemme try it on a slower machine
17:42:21 <roshi> all my 64bit machines are pretty close in specs
17:42:26 <roshi> ram being the difference
17:44:19 <adamw> halfline: do you have any hopes of being able to figure this out quickly?
17:44:34 * adamw could handle a punt for ~24 hours to see if halfline can figure out what's going on
17:45:23 <halfline> adamw: probably not. i have to leave to a prenatal appointment in 15 minutes
17:45:59 <halfline> so probably won't figure it out until tomorrow ish
17:46:17 <roshi> hrm
17:46:36 <roshi> testing on a slower machine once I get the image transferred over to it
17:46:46 <roshi> 22% done now
17:47:05 <adamw> if i had to vote based on what we know now i guess i'd be a reluctant -1 on the basis it's intermittent, can be fixed with an update or worked around, and seems to affect slower systems
17:47:46 * kparal will try to reproduce on bare metal tomorrow in the office
17:48:14 <kparal> right now, I don't really know what to vote
17:48:16 <adamw> we can always revote if we find it's more serious i guess
17:48:23 <kparal> fine
17:48:31 <kparal> so I'm ok with -1
17:48:31 * nirik leaves his vote as was
17:48:57 <roshi> +1 FE kparal, adamw ?
17:49:02 <adamw> sure.
17:49:13 <kparal> yes
17:50:09 <pschindl> +1 FE
17:50:16 <roshi> proposed #agreed - 1272737 - RejectedBlocker AcceptedFreezeException Final - This bug seems intermittent and looks like it only affects slower machines, so it's not considered blocker worthy. More testing is welcome, to confirm this understanding. However, we'd gladly consider a fix for this during freeze.
17:50:40 <adamw> ack
17:50:47 <kparal> ack
17:51:14 <nirik> ack
17:52:03 <danofsatx> ack
17:52:21 <roshi> #agreed - 1272737 - RejectedBlocker AcceptedFreezeException Final - This bug seems intermittent and looks like it only affects slower machines, so it's not considered blocker worthy. More testing is welcome, to confirm this understanding. However, we'd gladly consider a fix for this during freeze.
17:52:34 <roshi> ok, that's it for proposed blockers
17:52:45 <roshi> onto the FE's or go through accepted blockers right now?
17:53:06 <adamw> uh, sure?
17:53:08 <adamw> did we do https://bugzilla.redhat.com/show_bug.cgi?id=1263988 ?
17:53:56 <sgallagh> We were going to circle back around since people were actively in the middle of testing, I think?
17:54:15 <adamw> no, that was the one we just finished.
17:54:19 <roshi> I ghouthg we did
17:54:25 <roshi> thought, sheesh
17:54:42 <sgallagh> Ah, sorry. Wandered off for a few
17:54:46 <nirik> we did the one that we decided to dupe against this one.
17:54:48 <adamw> nope, we haven't done it.
17:54:49 <sgallagh> Trying to get through the rest of the Server tests
17:54:54 <adamw> nirik: right
17:55:01 <adamw> we did the luc bug and made it a dupe of 1263988
17:55:05 <adamw> but we didn't actually do 1263988
17:55:17 <roshi> we didn't
17:55:23 <roshi> #topic (1263988) livecd-iso-to-disk doesn't create bootable usb drive
17:55:26 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1263988
17:55:28 <roshi> #info Proposed Blocker, syslinux, VERIFIED
17:56:01 <nirik> +1 here.
17:57:43 <adamw> i'm still not really convinced this needs to be a blocker, but meh
17:58:13 <adamw> it'd be fine as a 0-day
17:58:24 <roshi> I could go either way
17:59:01 <kalev> definitely FE though
17:59:08 <roshi> yeah
17:59:19 <danofsatx> 1 FE
17:59:22 <danofsatx> +1, even
17:59:30 <adamw> well
17:59:35 <adamw> we have the fix, so blocker vs. FE doesn't mean a lot
17:59:47 <adamw> what i was meaning is, is there really any need to pull this through the freeze vs. amking it a 0 day update
18:00:10 <roshi> not really, but FE doesn't *hurt* anything, afaict
18:00:18 <nirik> someone might try and make other liveusbs from a new f23 install or live session?
18:00:20 <roshi> and we can test it
18:00:25 <kalev> I don't know, but if we have it already, might just as well pull it through the freeze
18:00:46 <kalev> as the package in the base repo is totally busted
18:01:05 <adamw> roshi: it gets used to build live images, iirc. shouldn't break them, but...
18:01:10 <nirik> since cloud isn't using syslinux in f23, I don't think there's much harm pulling it thru... unless it somehow affects arm? extlinux?
18:02:25 <adamw> well, just pick something and let's move on, it's not that important i guess
18:02:28 <adamw> if it breaks stuff we can back it out
18:02:46 <roshi> like I said, I could go either way - I don't have a strong feeling about it
18:02:49 <roshi> votes?
18:03:29 <kalev> +1 FE
18:03:45 <nirik> well, if it's a blocker we have to take some fix... if it's an FE we can back it out. ;)
18:03:53 <nirik> so, sure, +1 FE
18:04:21 * nirik thinks perhaps a TC11 today if we can't get an rc with these FE's we want to pull might be good...
18:04:25 <nirik> 12 sorry
18:05:34 <roshi> proposed #agreed - 1263988 - RejectedBlocker AcceptedFreezeException Final - This bug is already fixed, which can be pulled in via a 0-day update. However, to get more testing, we've accepted it as an FE for the next compose. If something breaks we can back it out.
18:06:02 <kparal> ack
18:06:06 <kalev> ack
18:06:44 <adamw> ack
18:06:59 <roshi> #agreed - 1263988 - RejectedBlocker AcceptedFreezeException Final - This bug is already fixed, which can be pulled in via a 0-day update. However, to get more testing, we've accepted it as an FE for the next compose. If something breaks we can back it out.
18:07:54 <roshi> onto the proposed FEs
18:08:12 <roshi> FEs are usually fast
18:08:13 <roshi> #topic (1273009) AttributeError: 'ZFCPDiskDevice' object has no attribute 'busid'
18:08:17 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1273009
18:08:19 <roshi> #info Proposed Freeze Exceptions, anaconda, NEW
18:10:11 <adamw> sure, +1, secondary arch storage stuff.
18:10:18 <nirik> +1 FE
18:10:18 <adamw> not likely to get in, but w/e.
18:10:27 <roshi> +1
18:10:34 <nirik> but wat is a zFCP disk... no,wait, I don't want to kno
18:10:37 <kalev> +1 FE
18:11:00 <roshi> proposed #agreed - 1273009 - AcceptedFreezeException Final - We'd gladly consider a fix during freeze for this.
18:11:00 <nirik> ah, fiberchannel. ok.
18:11:31 <sgallagh> Hang on.
18:11:32 <nirik> ack
18:11:34 <nirik> oh?
18:12:00 <sgallagh> I'm -1 FE to mucking with the storage stack
18:12:11 <adamw> usually fixes to this kind of thing are isolated to the arch in question
18:12:19 <adamw> of course we only pull those kinds of fixes
18:12:22 <sgallagh> adamw: It's the "usually" that concerns me
18:12:30 <roshi> we've done it before with no issues
18:12:31 * adamw trots out the 'FE doesn't mean we have to do it' horse
18:12:36 <roshi> lol
18:12:45 * adamw keeps it in a quick-release stable
18:12:45 <nirik> if it's invasive we can say no thanks.
18:13:25 <sgallagh> adamw: What's the point of having these meetings if we always trot out that horse?
18:13:41 <adamw> FE means we *can* include a fix.
18:13:42 <sgallagh> I'd prefer to just say "Sorry, too late, good luck with Rawhide" to anything that's risky...
18:13:45 <roshi> we don't always, it's just the nature of FEs
18:13:46 <adamw> not-FE means we definitely can't.
18:14:19 <adamw> if it's something where any fix would clearly be far too dangerous to pull, -1 makes sense.
18:15:09 <adamw> and if it's something of trivial or only post-release benefit, -1 makes sense.
18:15:09 <roshi> so, acks to the previous? unless there are more -1 votes
18:15:17 <adamw> so we have lots of grounds for -1s, and we *do* -1 issues.
18:15:17 <sgallagh> Every FE introduces some potential risk.
18:15:45 <sgallagh> I don't see that there are any realistic benefits to this fix.
18:15:53 <sgallagh> Honestly, who uses Fedora on s390x?
18:16:29 * nirik thinks this is drifting offtopic and into bad places.
18:16:55 <nirik> some folks must?
18:17:16 <nirik> in fact someone who filed the bug was even testing before release
18:17:22 <sgallagh> You're right, that was poorly stated.
18:17:23 <adamw> well, this guy, for one: https://lists.fedoraproject.org/pipermail/s390x/2015-June/001691.html
18:17:36 * roshi just reproduced the black screen on a slower machine, confirming that hypothesis in his head
18:17:53 <adamw> the population of developers to users on that list appears to be 2 to 1, but hey, it's a user. :)
18:17:55 <sgallagh> My point was more: If this *does* cause issues, that reduces the time we have to respin and test the remainder.
18:18:09 <sgallagh> I'm not sure introducing that risk is worth it to address this particular issue.
18:18:13 <adamw> well, bear in mind at this point we're only going to get any kind of fix for this with a slip.
18:18:19 <nirik> sure, so it would need to be a pretty simple fix
18:18:32 <roshi> the other s390x FE's we've pulled in haven't caused any issues I can recall
18:19:37 <nirik> one of the things we said for FE's that we would allow secondary arch stuff if it only affected that arch I thought... otherwise they would have an even worse time...
18:20:06 <nirik> anyhow, I think its pretty moot. I'm for +1 FE here, given that it very likely won't ever get pulled in. But if we slip and there's a easy fix it could be.
18:20:20 <adamw> "we approve a freeze exception, so long as we don't actually do it"
18:20:20 <adamw> :P
18:20:49 <roshi> so, ack/nack/patch to the previous?
18:20:58 * adamw is still +1 and ack because he wants to be anywhere else at all
18:21:11 <sgallagh> I am clearly outvoted, so proceed. My disagreement has been noted.
18:21:14 <pwhalen> +1 fe; ack
18:21:18 <roshi> #agreed - 1273009 - AcceptedFreezeException Final - We'd gladly consider a fix during freeze for this.
18:21:26 <roshi> #topic (1271823) freecol crashes at start up
18:21:26 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1271823
18:21:26 <roshi> #info Proposed Freeze Exceptions, freecol, ON_QA
18:22:06 <nirik> so this is on games...
18:22:32 <roshi> I'm fine with a +1 on this
18:22:33 <nirik> +1FE, sure. ack move on.
18:22:33 <brunowolff> My theory was that this one was pretty low risk, because I suspect only the games spin uses it.
18:22:46 <adamw> sure, +1
18:22:47 <kparal> +1 fe
18:22:48 <roshi> proposed #agreed - 1273009 - AcceptedFreezeException Final - We'd gladly consider a fix during freeze for this.
18:22:51 <kparal> ack
18:23:55 <pwhalen> +1; ack
18:24:04 <roshi> proposed #agreed - 1271823 - AcceptedFreezeException Final - We'd gladly consider a fix during freeze for this.
18:24:12 * roshi fixed the bug #
18:24:22 <roshi> #agreed - 1271823 - AcceptedFreezeException Final - We'd gladly consider a fix during freeze for this.
18:24:28 <roshi> #topic (1272737) Black screen after logout
18:24:28 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1272737
18:24:28 <roshi> #info Proposed Freeze Exceptions, gdm, NEW
18:24:36 <roshi> nvm, this is already accepted FE
18:25:55 <roshi> moving on
18:26:04 <roshi> #info this was already decided at blocker discussion
18:26:05 <roshi> #topic (1255070) Add CONFIG_ACPI_REV_OVERRIDE_POSSIBLE to kernel config
18:26:08 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1255070
18:26:10 <roshi> #info Proposed Freeze Exceptions, kernel, MODIFIED
18:28:07 <adamw> eh, bit late to be pulling new kernels
18:28:16 <adamw> i'd maybe be +1 with a slip, but not for this week
18:28:36 <nirik> yeah, ditto
18:29:00 <roshi> yeah
18:29:14 <sgallagh> I'd be perfectly happy with a clear -1 here.
18:29:26 <adamw> sure, can be re-proposed if circumstances change
18:29:30 <adamw> -1
18:30:40 <roshi> proposed #agreed - 1255070 - RejectedFreezeException Final - We're not comfortable pulling in kernel changes this close to GA. If we end up slipping, please repropose and we'll take another look at it.
18:31:00 <nirik> ack
18:31:05 <sgallagh> ack
18:31:11 <adamw> ack
18:31:18 <kparal> ack
18:31:23 <roshi> #agreed - 1255070 - RejectedFreezeException Final - We're not comfortable pulling in kernel changes this close to GA. If we end up slipping, please repropose and we'll take another look at it.
18:31:37 <roshi> #topic (1250712) kernel panic when booting a LiveUsb created with liveusb-creator
18:31:40 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1250712
18:31:43 <roshi> #info Proposed Freeze Exceptions, liveusb-creator, NEW
18:31:45 <roshi> eh, this is the dupe, right?
18:33:55 <nirik> yeah.
18:34:18 <roshi> #topic (1273097) Upgrade from F22 to F23 fails because F23 version is older
18:34:21 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1273097
18:34:24 <roshi> #info Proposed Freeze Exceptions, pki-core, NEW
18:35:26 <sgallagh> This one may be irrelevant if we get the distro-sync fixes done in time for release.
18:35:33 <sgallagh> Which I think we've declared a blocker, right?
18:35:34 <nirik> -1
18:35:40 <nirik> it should be fixed by yeah... that
18:36:06 <adamw> yeah
18:36:09 <roshi> -1 then
18:36:20 <adamw> and anyway, in principle i'm against pulling stuff through the freeze purely for upgrade issues, 0-days are ok
18:36:49 <sgallagh> Sure, -1. I mostly proposed it in case we got word that the DNF fixes were postponed or something
18:36:54 <sgallagh> Sorry for the noise
18:37:03 <roshi> proposed #agreed - 1273097 - RejectedFreezeException Final - This can and will be fixed via 0-day updates, no need for FE status.
18:37:18 <kparal> do we have tracker for 0-day updates?
18:37:27 <roshi> np sgallagh - better to propose and get it denied than the alternative :p
18:38:46 <roshi> acks?
18:38:50 <sgallagh> ack
18:38:53 <roshi> kparal: I don;t know, actually
18:38:59 <nirik> ack
18:39:01 <kparal> ack
18:39:11 <roshi> #agreed - 1273097 - RejectedFreezeException Final - This can and will be fixed via 0-day updates, no need for FE status.
18:39:14 <kparal> not sure how we block the release on it, then
18:39:16 <sgallagh> Not really relevant here anyway. It's already queued for stable, so it will make 0day
18:39:26 <roshi> #topic (1270663) Failure to install: systemd-219-13.fc22.x86_64 was supposed to be installed but is not!
18:39:29 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1270663
18:39:32 <roshi> #info Proposed Freeze Exceptions, rpm, NEW
18:40:49 <nirik> no new info here?
18:41:13 <sgallagh> Doesn't look like it.
18:41:20 * adamw is supposed to be proposing some process for 'special blockers' and stuff, i set up a tracker for beta, didn't do one for final yet
18:41:22 <adamw> guess i'll do it
18:41:23 <nirik> h wait, this is a different one
18:41:56 <kalev> Stef replied in the ticket at least, I am pretty sure this is new
18:42:04 <kalev> https://bugzilla.redhat.com/show_bug.cgi?id=1270663#c13
18:42:08 <nirik> yeah,, but without too much info
18:42:11 * kalev nods.
18:42:38 <kalev> I expect there will be a final rpm release soon anyway, which goes in F23
18:42:43 <adamw> upgrades get run with f22's rpm, right? not f23's.
18:42:59 <kalev> afaik f23's rpm is a RC build right now
18:43:40 <roshi> well, let
18:44:03 <roshi> 's wrap this one up real quick, we have some other late blocker proposals to go through and we're running out of time
18:44:08 <nirik> so, if you disable all but the base repo, you get the current rpm that has a bug thats fixed in the new one
18:44:32 <nirik> but I am not sure why you would disable all but the base repo...
18:45:05 * adamw still doesn't see a rationale here
18:45:08 * adamw -1
18:45:22 * kparal goes afk
18:45:25 <nirik> yeah, -1 without a clearer rationale...
18:46:18 <kalev> -1 just so that we can move on :)
18:46:38 <nirik> from the changes it seems this also only affects permissive mode
18:49:00 <roshi> proposed #agreed - 1270663 - RejectedFreezeException Final - There still doesn't seem to be enough of a reason to justify breaking freeze for this fix.
18:49:19 <adamw> ack
18:49:22 <sgallagh> ack
18:49:28 <roshi> I presume a 0-day can fix this? Which there's already a fix and it'll be out at GA, right?
18:49:40 <roshi> #agreed - 1270663 - RejectedFreezeException Final - There still doesn't seem to be enough of a reason to justify breaking freeze for this fix.
18:49:48 <roshi> #topic Moving back to blockers for a moment
18:50:06 <roshi> #topic #topic (1270663) Failure to install: systemd-219-13.fc22.x86_64 was supposed to be installed but is not!
18:50:09 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1270663
18:50:13 <roshi> meh
18:50:17 <roshi> #undo
18:50:17 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x3b39a0d0>
18:50:26 <roshi> #undo
18:50:26 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x3b39a850>
18:50:36 <roshi> #topic Bug 1273145 - TypeError: 'str' does not support the buffer interface
18:50:46 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1273145
18:50:57 <roshi> #info Proposed Blocker, anaconda, NEW
18:51:35 <adamw> so we're live debugging this AS WE SPEAK
18:52:19 <adamw> so far it seems like the anaconda crash isn't really the thing here, the thing is that the realm discovery failed
18:52:23 <roshi> oh yeah, living on the edge
18:52:57 <nirik> defer for info and vote in bug?
18:53:04 <nirik> or should we wait for a few?
18:53:41 <adamw> let's wait for a bit
18:54:19 <adamw> criterion here is Alpha "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain. "
18:55:05 <roshi> yeah, I'd like to see this get some more testing, and if it's verified - it's a clear +1 from me
18:55:19 <nirik> do we have others to hit? or is this the last?
18:56:08 <sgallagh> nirik: kalev proposed another FE around Wayland
18:56:20 <roshi> there's another
18:56:25 * roshi gets it together
18:56:34 <roshi> #topic Bug 1273146 - Include a wayland app launching fix for F23
18:56:41 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1273146
18:56:52 <roshi> #info proposed blocker, glib2, NEW
18:57:52 <nirik> well... glib2 is pretty... everywhere.
18:57:59 <roshi> yeah...
18:58:05 <adamw> "This affects all applications using GIO or GTK API to launch applications — for instance, the terminal when clicking on an URL, or double-clicking on a file in Nautilus."
18:58:18 <adamw> seems like a serious impact, but how much do we care about people using Wayland on the live image?
18:58:24 <roshi> I do agree that wayland bugs will get attention though...
18:58:26 * adamw inclined to go conservative here
18:58:33 <roshi> yeah
18:58:37 <kalev> we've drummed up wayland support quite a lot
18:58:47 <nirik> yeah, I'd say -1 and repropose if we slip?
18:58:53 <kalev> I expect people are going to try this and write bad reviews if simple things like this don't work out of the box
18:59:19 <nirik> hum.
18:59:37 <kalev> sadly, reviewers often don't apply updates :(
18:59:40 <roshi> if it wasn't glib...
19:00:17 <kalev> note that this is glib, not glibc
19:00:30 <nirik> well, ok I guess I could be +1 FE, but... I don't know that we would be able to even pull it in. There's not an update yet?
19:02:12 <kalev> sure, just needs some ninja package building
19:02:43 * adamw is still not super-convinced
19:03:03 <adamw> did anyone check why the code was setting DISPLAY in the *first* place and make sure whatever case that was for is still ahndled?
19:04:57 <kalev> I think it's matching a gtk+ commit that's already in the 3.18.1 megaupdate
19:05:41 <roshi> if it's already in the megaupdate, do we need this? seems the mega update is working fine...
19:06:01 <adamw> i think kalev means the DISPLAY stuff got moved into GTK+ or smth.
19:06:08 * kalev nods.
19:06:14 <roshi> ah
19:06:49 <adamw> https://bug754983.bugzilla-attachments.gnome.org/attachment.cgi?id=311836
19:07:14 <kalev> yup, that's the one
19:07:20 <adamw> so...hmm, with the gtk+ change but not the glib change it'd actually be getting set twice?
19:08:33 <kalev> something like that, yes
19:09:18 <kalev> it definitely needs rigourous (how do you spell that word?) testing to make sure we didn't miss anything and it's not breaking stuff
19:10:09 <adamw> rigorous
19:10:20 * adamw still kinda -1, honestly. we've got enough shit goin' on.
19:10:31 <kalev> fair enough
19:10:46 <adamw> other votes?
19:12:06 <kalev> I myself would be slightly +1, with the caveat that it should get good testing before we pull it in :)
19:12:16 <kalev> how to get that good testing at this point, I do not know, considering it's not even in updates-testing yet
19:12:46 <adamw> right, that's kind of the thing
19:12:48 <adamw> we're in release week
19:13:13 <adamw> we want to cut the RC tomorrow. well, okay, in a sane project we'd have cut it last month, but this is fedora. asking for the RC to be done two days before we sign off on it counts as QA playing hardball. ;)
19:13:13 <roshi> still leaning -1 just because of timing
19:13:22 <roshi> if we slip, then I'd be ok with FE
19:13:37 * roshi was getting a sandwich
19:14:05 <kalev> sure, makes sense
19:14:30 <kalev> I'll set a nice high karma threshold for the update and if we end up slipping, we should be much more confident if it's ok to take or not
19:15:22 <roshi> proposed #agreed - 1273146 - RejectedFreezeException Final - While we agree this would be good to get fixed for the Live images, we're not comfortable taking this on this close to the Go/No-Go decision. If we slip, please repropose, as we'll have time to test it.
19:17:01 <kalev> ack
19:17:20 <roshi> that'd be great for the karma though kalev, thanks
19:18:07 <roshi> ack, nack or patch?
19:18:23 <adamw> ack
19:19:11 <roshi> #agreed - 1273146 - RejectedFreezeException Final - While we agree this would be good to get fixed for the Live images, we're not comfortable taking this on this close to the Go/No-Go decision. If we slip, please repropose, as we'll have time to test it.
19:19:30 <roshi> back to 1273145?
19:19:59 <roshi> or call the meeting and vote in bug as it gets sussed out?
19:20:54 <sgallagh> roshi: Looks like this is actually a NetworkManager regression.
19:21:34 <sgallagh> I can prove that it works properly in F23 Beta
19:22:22 <roshi> ah, fun
19:23:53 <sgallagh> That said, I'm prepared to reduce this to an FE request, because it appears to be limited to cases where DHCP doesn't hand out a DNS address that can find the domain
19:24:10 <sgallagh> The regression from Beta is that it's not using the DNS server specified in kickstart
19:24:20 <nirik> s/regression/bug/ ;)
19:24:29 <sgallagh> Of course, this issue persists onto the installed system, so that's also bad.
19:24:55 <sgallagh> nirik: In Beta it honored the --nameserver argument, in Final it doesn't. That one is firmly in "regression" territory to me.
19:25:19 * nirik subscribes to the wwoods definition of regression.
19:25:33 <nirik> anyhow... should we go back to it and vote on FE? or just vote in bug?
19:26:28 <roshi> we
19:26:50 <sgallagh> I'm torn between blocker and FE here, because the end result is a machine that doesn't match the network configuration specified in the kickstart
19:27:01 <roshi> we're 26 minutes over time...
19:27:14 <roshi> #topic Bug 1273145 - TypeError: 'str' does not support the buffer interface
19:27:15 <adamw> i'm OK with -1 *if* the bug is what we think it is
19:27:19 <adamw> i'd like to be a bit more sure about that
19:27:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1273145
19:27:31 <nirik> so, perhaps gather more, vote in bug?
19:28:00 <adamw> so long as people promise to stick around and be available for voting :P
19:28:01 <roshi> domain join from ks seems to me to be a common route for spinning up new servers - so I'd like to be sure
19:28:08 <roshi> I'll be here
19:28:42 <sgallagh> /me will continue working on it.
19:28:48 <roshi> sounds good
19:29:11 <Southern_Gentlem> how many people try to join a domain out of the box this seems a very low number and should be a common bug and move on
19:29:19 <roshi> ping in fedora-qa when ready to re look at it sgallagh ?
19:29:25 <roshi> I can close this out for now
19:29:45 <sgallagh> Will do
19:29:45 <adamw> Southern_Gentlem: it's a key feature of server.
19:30:00 <roshi> Southern_Gentlem: imagine you're provisioning servers or workstations for your company, you would almost *need* that in the ks
19:30:02 <adamw> sgallagh: ok, i'm gonna do a bunch of bureaucracy and then i'll see if i can help.
19:30:08 <sgallagh> Southern_Gentlem: The use-case is when you're bringing up a new rack; you just fire a kickstart at all of them
19:30:10 <adamw> sgallagh: have you checked if you can capture an NM folk?
19:30:18 <sgallagh> Getting there
19:30:23 <sgallagh> adamw: Thanks
19:30:25 <Southern_Gentlem> sgallagh,  i can see for servers yes
19:30:26 * roshi hands sgallagh a Great Ball
19:30:48 <roshi> (for catching NM folks)
19:30:49 <adamw> a wild dcbw appears!
19:30:49 <sgallagh> roshi: "Have a ball"?
19:30:56 <adamw> roshi: man, these people have no clue
19:31:01 <sgallagh> adamw: I don't think dcbw works on NM anymore, actually
19:31:01 <roshi> adamw gets it
19:31:06 * kalev steps away from the computer for a bit.
19:31:28 <adamw> sgallagh: i think dcbw does but danw doesn't. but imbw.
19:31:34 <sgallagh> ok
19:31:40 <adamw> the others are europeans, i think
19:31:53 <roshi> #topic Open Floor
19:32:06 <roshi> anything else real quick? gonna close this out
19:32:37 <adamw> sgallagh: i see upstream commits from Dan in july, august and september (though clearly he's not The Guy any more)
19:32:45 <adamw> nope, hell no
19:32:51 <roshi> #info sgallagh did in fact get the joke :p
19:32:57 <adamw> please close quick so i can use the summary for secretarialization :P
19:33:06 <jkurik> on Thursday we have go/no-go & readiness meeting - anyone from QE is going to join ?
19:33:11 <roshi> thanks for coming folks!
19:33:14 <adamw> sure, me and roshi probably
19:33:18 <jkurik> thanks
19:33:20 <roshi> #endmeeting