16:00:59 <adamw> #startmeeting F29-blocker-review
16:00:59 <zodbot> Meeting started Mon Oct  1 16:00:59 2018 UTC.
16:00:59 <zodbot> This meeting is logged and archived in a public location.
16:00:59 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:59 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:01:00 <adamw> #meetingname F29-blocker-review
16:01:00 <adamw> #topic Roll Call
16:01:00 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:01:05 <frantisekz> .hello2
16:01:06 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:01:09 <adamw> morning folks, who's around for some lovely blocker review?
16:01:28 * pwhalen is here
16:02:02 <adamw> hi pwhalen
16:02:35 * coremodule is here. On secretary duty!
16:03:17 <adamw> hi coremodule
16:03:31 <coremodule> Good morning adamw
16:03:46 <pwhalen> good afternoon adamw :)
16:04:04 <pwhalen> ..and all the other fine folks here today
16:04:04 * jlanda is lurking around
16:06:26 <adamw> nirik: sgallagh: mattdm: mboddu: pingles
16:06:41 * lbrabec is here
16:06:42 <sgallagh> Sorry, can't do it today.
16:07:26 <adamw> dangit, my glue trap failed?
16:11:05 <adamw> hi bowlofeggs
16:11:11 <adamw> welp, looks like we have a few folks anyway, let's get rolling
16:11:19 <adamw> #chair pwhalen coremodule
16:11:19 <zodbot> Current chairs: adamw coremodule pwhalen
16:11:20 <bowlofeggs> heyo
16:11:25 <mboddu> adamw: I can join, but in 15 min
16:11:26 <bowlofeggs> .hello2
16:11:26 <adamw> #topic Introduction
16:11:26 <adamw> Why are we here?
16:11:26 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
16:11:27 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:11:27 <adamw> #info We'll be following the process outlined at:
16:11:28 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:11:30 <adamw> #info The bugs up for review today are available at:
16:11:32 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:11:34 <adamw> #info The criteria for release blocking bugs can be found at:
16:11:36 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:11:38 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria
16:11:40 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria
16:11:42 <adamw> mboddu: roger
16:14:00 <adamw> we have:
16:14:08 <adamw> #info 7 Proposed Blockers
16:14:08 <adamw> #info 9 Accepted Blockers
16:14:11 <adamw> #info 1 Accepted Previous Release Blockers
16:14:11 <adamw> #info 2 Proposed Freeze Exceptions
16:14:18 <adamw> let's start with proposed blockers!
16:14:27 <adamw> #info starting with proposed blockers
16:14:30 <adamw> #topic (1632656) The installer failed to use the iscsi target if authentication is set
16:14:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1632656
16:14:31 <adamw> #info Proposed Blocker, anaconda, ASSIGNED
16:17:14 <bowlofeggs> according to the basic criteria, only "locally connected storage interfaces" are blockers if i'm reading this right
16:17:33 <bowlofeggs> i confess i haven't read all of the criteria, so please let me know if there's one about remote interfaces
16:18:10 <adamw> no, there is one.
16:18:12 <coremodule> +1 blocker, seems clear to me per this:
16:18:13 <coremodule> https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria#Network_attached_storage
16:18:21 <adamw> "The installer must be able to detect (if possible) and install to supported network-attached storage devices."
16:18:39 <adamw> the question here, I guess, is whether we block on auth
16:18:42 <adamw> it works without authentication
16:18:47 <adamw> the criterion doesn't specify either way.
16:19:04 <bowlofeggs> ah yeah that's interesting
16:19:22 <bowlofeggs> seems like you'd probably normally want to use auth, but if the criteria don't specify i guess that's a technicality
16:19:23 <adamw> probably in real life auth is pretty typically used with iscsi, so i guess i'd incline towards blocking
16:19:23 <coremodule> my thought would be without user interaction to disable auth
16:19:30 <adamw> (and maybe we should enhance the openQA test to test this...)
16:20:30 <bowlofeggs> ah "network attached storage" doesn't appear in the basic page, but does appear in the f29 page
16:20:48 <bowlofeggs> i'd +1 blocking on that since i'd consider that the "normal" use case
16:20:55 <bowlofeggs> the unauth'd use i'd call unusual
16:21:05 <pwhalen> +1 blocker
16:23:12 <adamw> bowlofeggs: it's a Final criterion
16:23:14 <adamw> ok
16:24:06 <adamw> proposed #agreed 1632656 - AcceptedBlocker (Final) - this is accepted as a violation of Final criterion "The installer must be able to detect (if possible) and install to supported network-attached storage devices" - the criterion does not explicitly say whether auth is blocking, but we believe it is sufficiently commonly used in the real world that we should accept the bug
16:24:11 <coremodule> ack
16:24:28 <frantisekz> ack
16:24:40 <bowlofeggs> ack
16:25:19 <lbrabec> ack
16:25:39 <pwhalen> ack
16:26:49 <adamw> #agreed 1632656 - AcceptedBlocker (Final) - this is accepted as a violation of Final criterion "The installer must be able to detect (if possible) and install to supported network-attached storage devices" - the criterion does not explicitly say whether auth is blocking, but we believe it is sufficiently commonly used in the real world that we should accept the bug
16:27:01 <adamw> #topic (1625645) selinux prevents loading of anything inside /etc/cron.d
16:27:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625645
16:27:01 <adamw> #info Proposed Blocker, cronie, ASSIGNED
16:27:05 <adamw> sooo, where'd we leave this one
16:27:27 <adamw> i still don't see a criteria proposal
16:27:33 <adamw> lbrabec: pwhalen: has kamil said anything about proposing one?
16:27:52 <adamw> er
16:27:56 <adamw> i didn't mean pwhalen
16:28:01 <adamw> i meant frantisekz :P
16:28:14 <pwhalen> ok, good, I had no idea :)
16:29:06 <frantisekz> we didn't talk about that too much just yet, I think he would prefer to have some criteria about that...
16:29:24 <adamw> ok, well
16:29:29 <frantisekz> but he didn't seem to want to actually write one :P :D
16:29:29 <adamw> it's been sitting on the list for weeks
16:29:39 <adamw> i think we can reject it for now, but with the option to revisit if a criteria gets written
16:29:57 <adamw> i'm certainly willing to +1 FE it though, just to ensure we can get a fix in if one shows up during freeze, selinux fixes are usually safe
16:30:13 <bowlofeggs> +1 FE
16:30:15 <frantisekz> sure, seems like the best way for now, +1 FE lgtm, it wouldn't be forgotten at least
16:31:10 <lbrabec> yep, +1 FE
16:31:48 <adamw> proposed #agreed 1625645 - RejectedBlocker (Final) - this is rejected for now as it does not appear to violate any specific criterion, but it could be revisited if one is proposed. We accept it as a freeze exception issue as it'd obviously be for the best if this can be fixed as promptly as possible, and SELinux policy fixes are usually safe
16:32:07 <frantisekz> ack
16:32:23 <lbrabec> so no FE then?
16:32:36 <coremodule> ack
16:32:59 <adamw> oh sorry
16:33:00 <adamw> good point
16:33:09 <adamw> proposed #agreed 1625645 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected for now as it does not appear to violate any specific criterion, but it could be revisited if one is proposed. We accept it as a freeze exception issue as it'd obviously be for the best if this can be fixed as promptly as possible, and SELinux policy fixes are usually safe
16:33:15 <lbrabec> ack
16:33:27 <adamw> lbrabec++ for correct proposal review
16:33:27 <zodbot> adamw: Karma for lbrabec changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:33:49 <Southern_Gentlem> ack
16:33:52 <coremodule> ack
16:33:54 <pwhalen> ack
16:33:59 <adamw> oh hey, btw, i'm gonna have to run out in about 40 mins or so
16:33:59 <frantisekz> lbrabec++ saved the day!
16:33:59 <zodbot> frantisekz: Karma for lbrabec changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:34:03 <frantisekz> ack
16:34:06 <adamw> so if we're still going, i'll need someone to take over
16:34:08 <adamw> just a heads-up
16:34:13 <adamw> #agreed 1625645 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected for now as it does not appear to violate any specific criterion, but it could be revisited if one is proposed. We accept it as a freeze exception issue as it'd obviously be for the best if this can be fixed as promptly as possible, and SELinux policy fixes are usually safe
16:34:22 <adamw> #topic (1631002) gnome-control-center stuck and starts consume memory abnormally if I try to change the background or lock screen image.
16:34:22 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1631002
16:34:22 <adamw> #info Proposed Blocker, gnome-control-center, NEW
16:34:55 <adamw> so someone mentioned in QA meeting today they couldn't reproduce this
16:35:06 <adamw> <jlanda> nop here, woprking weel on my tests. I can't either reproduce the big Pictures/ issue :S
16:35:46 <adamw> with that i'm kinda inclined to reject
16:36:07 <bowlofeggs> i don't know what criteria this would violate anyway
16:36:18 <jlanda> oh, you're faster than my 4g reconnecting
16:36:20 <bowlofeggs> if this is a real bug i'd +1 an FE but wouldn't consider it a blocker
16:36:36 <jlanda> i was writing that when I went
16:36:42 <jlanda> inside a tunnel ;)
16:36:43 <coremodule> seems very specific, and even then it sounds like gnome-control-center *does* indeed change the wallpaper, just with a memory leak...
16:36:46 <adamw> bowlofeggs: either the app 'basic functionality' criterion or the panel functionality one i guess
16:36:55 <coremodule> -1 blocker
16:37:06 <adamw> proposal reads " because changing background  is a basic functionality of gnome-control center"
16:37:12 <bowlofeggs> ah
16:37:25 <adamw> that's referring to 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:37:29 <bowlofeggs> but not being able to reproduce it makes me -1 anyway
16:37:46 <frantisekz> -1 Blocker
16:37:48 <sgallagh> I'd still be -1 on the grounds that it still withstands the functionality test, it's just wasting resources.
16:37:59 <adamw> sgallagh: hey you're not even supposed to *be* here today
16:38:00 <adamw> ;)
16:38:02 <sgallagh> So it's irritating, but not strictly violating it.
16:38:08 <sgallagh> adamw: Found a few minutes
16:38:13 <jlanda> we can do further investigation, I can try to collect literally gbs of different photos for Pictures/
16:38:22 <adamw> the description does claim gcc gets 'stuck'
16:38:27 <adamw> not quite clear exactly what he means by that
16:38:31 <adamw> jlanda: sure, kick it a bit more
16:38:42 <pwhalen> -1 here as well
16:38:54 <sgallagh> adamw: Not impossible it's an I/O issue.
16:39:15 <adamw> sure
16:39:29 <adamw> i'm +-/0 on FE as we have no real idea what the bug or fix might be
16:39:37 <jlanda> m, I tryed with an nvme disk, do we now if the rwpoeter has mechanical disk?
16:39:38 <adamw> i might be +1 for a simple fix but i'd be -1 for a complicated one
16:39:44 <sgallagh> Yeah, I'd defer an FE decision for now
16:39:48 <adamw> also you're not too likely to encounter it as described on a live image
16:40:04 <adamw> so:
16:40:05 <adamw> proposed #agreed 1631002 - RejectedBlocker (Final) - jlanda was not able to reproduce this, and it does not seem a serious or commonly-encountered enough issue to constitute a violation of the 'basic functionality' criterion.
16:40:12 <adamw> if anyone wants an FE decision, speak now :P
16:40:12 <bowlofeggs> ack
16:40:16 <bowlofeggs> +1
16:40:16 <sgallagh> ack
16:40:17 <jlanda> that could be a big difference on IO
16:40:17 <jlanda> s/rwpoeter/reporter
16:40:21 * mboddu is here now
16:40:24 <adamw> jlanda: don't think we know
16:40:25 <adamw> hi mboddu
16:40:44 <jlanda> ok, I'll try with an old 5.4k rpm disk :D
16:40:48 <adamw> diligent :)
16:40:59 <sgallagh> jlanda: I meant that it's possible they found a deadlock in btrfs or something
16:41:04 <mboddu> adamw: Hi, sorry for the delay :)
16:41:15 <sgallagh> or busy-lock, rather
16:41:22 <adamw> jlanda: ack/nack/patch?
16:41:34 <jlanda> ack
16:41:54 <Southern_Gentlem> ack
16:41:56 <pwhalen> ack
16:41:58 <jlanda> m, sorry if I need time to reply, I'm in the middle of a train travel ;)
16:42:12 <coremodule> ack
16:42:19 <adamw> #agreed 1631002 - RejectedBlocker (Final) - jlanda was not able to reproduce this, and it does not seem a serious or commonly-encountered enough issue to constitute a violation of the 'basic functionality' criterion.
16:42:19 <adamw> rgr
16:42:29 <adamw> #topic (1625142) In Gnome Wayland, forward-key-event does not work well, breaks space key completely
16:42:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625142
16:42:29 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:42:33 <adamw> so, we have some more info on this one
16:43:01 <adamw> per mfabian, it breaks the default Korean input method
16:43:27 <adamw> it also breaks a non-default Vietnamese input method, and it breaks ibus-typing-booster. both of those are certainly things some folks will try and use.
16:44:28 <adamw> with that this is really on the fence for me
16:45:07 <adamw> having input be this broken on Workstation on a language we support is pretty bad, otoh, would it survive the "last blocker" test?
16:45:09 <bowlofeggs> that does sound bad
16:45:33 <jlanda> it sounds worst that last week
16:45:35 <bowlofeggs> don't forget that red star os is a downstream of fedora - we wouldn't want that to break
16:45:36 <adamw> for reference, we are in a case of https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F here
16:45:41 <adamw> bowlofeggs: :P
16:45:51 <adamw> this is one of those 'conditional blockers'
16:46:17 <mboddu> bowlofeggs: :D
16:46:39 <adamw> i'd say it's a conditional violation of " 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" in the affected language case (a desktop you can't type into usefully is not really a 'working' desktop)_
16:46:40 * mboddu reading the criteria
16:46:43 <sgallagh> adamw: This is defnitely nasty, but I agree: it probably wouldn't survive the "last blocker at Go/No-Go" test.
16:47:04 <adamw> and i guess, technically, we can claim that Korean users could manage to install a post-release update without typing anything
16:47:05 <Southern_Gentlem> +1 blocker
16:47:08 <bowlofeggs> +1 blocker
16:47:13 <adamw> though I know how that'd make me feel if i was korean. :P
16:47:22 <bowlofeggs> yeah i would not like that
16:47:27 <pwhalen> +1 blocker
16:48:07 <sgallagh> -1 blocker
16:48:09 <jlanda> i speak a minorized language and l10n is a big plua for me in oss +1 blocker
16:48:19 <lbrabec> adamw, regarding the gnome-control-center bug, i just tested it right now, but testing took longer longer than I expected and you already acked; I created 3333 copies of a wallpaper in ~/Pictures and while I had no issues with memory, control center froze and crashed after a while, can we punt it and I will properly test it tomorrow?
16:48:20 <sgallagh> +1 PrioritizedBug
16:48:55 <Southern_Gentlem> sgallagh, why not both
16:49:29 <sgallagh> Southern_Gentlem: If we got to Go/No-Go and this was the only thing standing between us and release, I'd argue strongly against waiting for it
16:49:53 <adamw> lbrabec: thanks, we can maybe circle back later
16:50:07 <sgallagh> But I *do* think it's important, so we should escalate it through the PrioritizedBug process at least
16:50:36 <Southern_Gentlem> i will agree to disagree with you
16:50:39 <adamw> as a process note, this meeting can't decide on PrioritizedBug status, that's not our job. we could *propose* it as one, but then, sgallagh alone can propose it as one. :P
16:50:47 <adamw> so we have +4 -1 and i didn't vote yet
16:50:49 <sgallagh> right
16:51:20 <sgallagh> If we don't come down in favor of blocker, I *will* make that proposal
16:52:07 <mboddu> I agree with sgallagh, it will be definitely shot down as a blocker if its the only blocker
16:52:19 <mboddu> So, +1 to proposing as a PrioritizedBug
16:52:21 <adamw> mboddu: what would *your* vote be, though?
16:52:24 <adamw> for blocker status
16:52:51 <mboddu> -1 Blocker for now, but definitely propose as a ProritizedBug
16:52:55 <adamw> ok
16:52:57 <adamw> so +4 / -2
16:52:59 <adamw> i am really on the fence
16:52:59 <Southern_Gentlem> -1 blocker
16:53:07 <adamw> that's +3 / -3...:P
16:53:13 <bowlofeggs> ahah
16:53:16 <adamw> so
16:53:17 <bowlofeggs> adamw: you have to decide now!
16:53:18 <mboddu> adamw: Thats why you should vote early :D
16:53:30 <sgallagh> and often!
16:53:32 <adamw> i'm gonna propose we should punt this again due to lack of clear consensus
16:53:36 <bowlofeggs> i'm not a strong -1, but i think i choose to stay -1 for inclusivity reasons
16:53:46 <bowlofeggs> fair enough
16:54:00 <adamw> is everyone +1 FE for this?
16:54:01 <mboddu> adamw: Yeah, we can punt it and get back to it
16:54:02 <adamw> i would be
16:54:08 <adamw> if we get a fix during freeze we should definitely take it
16:54:10 <bowlofeggs> if it were english that were broken, i presume we'd block
16:54:11 <sgallagh> Yeah, +1 FE without hesitation
16:54:13 <pwhalen> adamw, +1 FE
16:54:19 <bowlofeggs> +1 FE
16:54:25 <Southern_Gentlem> +1 fe
16:54:26 <mboddu> Definitely +1 FE
16:54:33 <adamw> ok
16:56:09 <adamw> proposed #agreed 1625142 punt (delay decision) on blocker status, AcceptedFreezeException (Final) - with the information that this breaks Korean but no other known case out of the box, we had a very split vote on this (~ +3/-3). we will delay the decision till a clearer consensus can be reached. We do grant freeze exception status, and will propose the bug as a PrioritizedBug
16:56:20 <mboddu> ack
16:56:24 <pwhalen> ack
16:56:47 <bowlofeggs> ack
16:56:54 <sgallagh> ack
16:56:57 <adamw> #agreed 1625142 punt (delay decision) on blocker status, AcceptedFreezeException (Final) - with the information that this breaks Korean but no other known case out of the box, we had a very split vote on this (~ +3/-3). we will delay the decision till a clearer consensus can be reached. We do grant freeze exception status, and will propose the bug as a PrioritizedBug
16:57:05 <adamw> #topic (1626862) Broken Fedora/Windows dualboot
16:57:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1626862
16:57:05 <adamw> #info Proposed Blocker, grub2, NEW
16:57:22 <adamw> so, I got this from pjones today:
16:57:22 <adamw> "<pjones> https://bugzilla.redhat.com/show_bug.cgi?id=1626862 I have no idea, but I'll go and see if we actually changed anything in that path"
16:57:41 <adamw> pjones doesn't think this and 1634386 actually *are* the same
16:57:45 <adamw> so we're still a bit unclear on this one
16:57:56 <adamw> i'd incline either punt or -1 on currently-available info
16:58:58 <frantisekz> I'd rather punt it, we don;t have any idea how many MBs or configurations could be affected
16:59:00 <sgallagh> I have some info here
16:59:00 <mboddu> I would punt it rather than -1 it
16:59:02 <bowlofeggs> without a reprocer i'm -1
16:59:07 <adamw> ooo info
16:59:11 <bowlofeggs> *reproducer
16:59:39 <adamw> as a general note, remember decisions can always be revisited if new information emerges; a -1 is never final until the release goes out
16:59:48 <sgallagh> I installed F29 Beta on a Windows system and after bootup,  there was no entry for Windows in the bootloader
17:00:11 <sgallagh> However! After a subsequent kernel upgrade, the grub entry for windows miraculously reappeared
17:00:22 <bowlofeggs> oh that's weird
17:00:29 <adamw> that sounds vaguely familiar.
17:00:30 <mboddu> sgallagh: Can you try it with recent f29 nightly?
17:00:44 <mboddu> Probably it got fixed and we can just close the bug
17:00:45 <sgallagh> mboddu: Not at present. I'm about 1300 miles from that machine :-/
17:00:46 <adamw> hum, can't find a report, though.
17:01:07 <sgallagh> adamw: I mentioned it in #fedora-qa at the time and someone suggested installing a kernel to fix it
17:01:27 <sgallagh> I didn't report because I assumed that with that quick a reply, the fix was already known
17:01:30 <adamw> how do you see that being relevant to this, though?
17:01:42 <adamw> in this case it seems fedora didn't boot
17:01:50 <sgallagh> Oh, hmm. I may have misread this.
17:02:14 <sgallagh> I thought it "skipped" grub because there was only the Fedora option on the list
17:02:26 <sgallagh> Maybe that's not the same issue then
17:02:39 <sgallagh> Sorry
17:02:39 <frantisekz> my UEFI somehow tries to boot something even if only Fedora is enabled
17:02:59 * sgallagh has to disappear again
17:03:03 <adamw> cya sgallagh
17:03:08 <adamw> thanks for stopping by
17:03:28 <adamw> so we have a couple votes for punt, one for -1, i'm ok with either
17:03:30 <adamw> any other votes?
17:03:57 <pwhalen> +1 punt
17:04:03 <lbrabec> +1 punt
17:04:06 <adamw> ok
17:04:17 <bowlofeggs> i'm fine with punting too
17:04:27 <mboddu> +1 Punt
17:04:36 <bowlofeggs> i just don't see a reason to say it's a blocker at this time since there isn't a reproducer
17:04:51 <adamw> proposed #agreed 1626862 - punt (delay decision) - it is still not clear exactly what is going on in this case and we do not have sufficient info to make a blocker decision yet. we ask frantisekz and pjones to try and get more info on what's going on here
17:05:02 <frantisekz> ack
17:05:03 <lbrabec> ack
17:05:04 <bowlofeggs> ack
17:05:07 <adamw> bowlofeggs: well, i mean, there *is* a reproducer: go try frantisek's system
17:05:08 <mboddu> ack
17:05:13 <adamw> bowlofeggs: it reproduces every time on that. :P
17:05:18 <bowlofeggs> adamw: heh, i suppose that's true ☺
17:05:18 <mboddu> bowlofeggs: Well, I guess its hardware specific
17:05:24 <adamw> #agreed 1626862 - punt (delay decision) - it is still not clear exactly what is going on in this case and we do not have sufficient info to make a blocker decision yet. we ask frantisekz and pjones to try and get more info on what's going on here
17:05:25 <bowlofeggs> i guess i mean independent reproducer
17:05:39 <adamw> bowlofeggs: unfortunately not uncommon with bootloader stuff :(
17:05:50 <adamw> #topic (1634386) Even cannot reach grub menu but show recovery blue screen
17:05:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1634386
17:05:51 <adamw> #info Proposed Blocker, grub2, NEW
17:05:52 <bowlofeggs> yeah
17:06:05 <adamw> this is another bootloader / dual-boot-y issue, but pjones thinks this one comes down to the presence of two ESPs.
17:06:07 <bowlofeggs> alright, i need to take off, sorry i can't stick the meeting out :/
17:06:27 <adamw> <pjones> looks like *probably* user error, but *possibly* we need a new efivar build because we've built a boot variable wrong
17:06:27 <adamw> <pjones> also anaconda probably shouldn't be letting you partition that way, but that's neither here nor there
17:08:44 <lbrabec> +1 punt
17:08:51 <Southern_Gentlem> +1 punt
17:09:07 <frantisekz> +1 punt
17:09:20 <mboddu> +1 Punt, need more info
17:09:32 <pwhalen> +1 punt
17:09:34 <adamw> yeah, we at least have an avenue to investigate here, but need more info
17:10:28 <adamw> proposed #agreed 1634386 - punt (delay decision) - we are homing in on what's going on in this case (likely to do with multiple ESPs), but still need a bit more info to determine how significant it's likely to be. we will try to reproduce this independently and investigate further
17:10:41 <frantisekz> ack
17:10:43 <lbrabec> ack
17:11:26 <adamw> any mor acks?
17:11:55 <adamw> meh
17:11:58 <adamw> #agreed 1634386 - punt (delay decision) - we are homing in on what's going on in this case (likely to do with multiple ESPs), but still need a bit more info to determine how significant it's likely to be. we will try to reproduce this independently and investigate further
17:11:59 <adamw> #topic (1630943) laptop with lid closed and external monitor can't log in to wayland session
17:11:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1630943
17:11:59 <adamw> #info Proposed Blocker, mutter, POST
17:12:02 <adamw> ok, with that i have to run out
17:12:05 <adamw> this is the last proposed blocker
17:12:08 <adamw> can someone take over from here?
17:16:25 <mboddu> adamw: I can run the irc part, but I dont know if anything needs to be done after the meeting ended
17:18:28 <lbrabec> mboddu, coremodule volunteered as secretary
17:18:55 <mboddu> mboddu: Okay, thanks
17:20:59 <jlanda> mboddu++
17:20:59 <zodbot> jlanda: Karma for mohanboddu changed to 15 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:21:14 <lbrabec> and it seems that adamw is really afk
17:21:18 <lbrabec> mboddu++
17:21:20 <zodbot> lbrabec: Karma for mohanboddu changed to 16 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:22:41 <mboddu> So, coremodule will take care of the stuff that happens after the meeting?
17:24:24 <mboddu> Anyway, any votes on this? This seems definitely like a blocker
17:25:04 <frantisekz> -1 Blocker, +1 FE as it looks for me
17:25:13 <frantisekz> or whatever :D
17:26:16 <Southern_Gentlem> -1 blocker +1 fe
17:26:20 <mboddu> Also, it seems there is a fix for it
17:26:34 <lbrabec> -1 blocker, +1 fe
17:27:45 <mboddu> Okay, that is +3 FE, but I thought its a blocker based on https://bugzilla.redhat.com/show_bug.cgi?id=1630943#c7
17:28:46 <frantisekz> i'd be +1 blocker if it affected not only laptops with closed lid :/
17:29:13 <pwhalen> has anyone reproduced this?
17:31:21 <mboddu> I haven't, I think I will try it and update the ticket later today
17:33:20 <lbrabec> so that sounds like punt :)
17:33:22 <pwhalen> +1 fe then, if its happening more often we can reclassify
17:33:32 <mboddu> Okay, lets go with FE then
17:35:24 <mboddu> agreed 1630943 - Proposed Freeze Exception - Since its affecting only laptops with closed it we consider it as a Freeze Exception, if its happening more often then we will reclassify
17:36:13 <frantisekz> mboddu, i think you need to add "proposed" at the beginning
17:36:24 <frantisekz> and # before agreed
17:36:25 <mboddu> proposed #agreed 1630943 - Proposed Freeze Exception - Since its affecting only laptops with closed lid we consider it as a Freeze Exception, if its happening more often then we will reclassify
17:36:27 <frantisekz> yep
17:36:28 <frantisekz> ack
17:36:33 <lbrabec> ack
17:36:34 <mboddu> frantisekz: Yup, got it :)
17:36:46 <frantisekz> mboddu++ :) :D
17:36:47 <zodbot> frantisekz: Karma for mohanboddu changed to 17 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:37:24 <mboddu> any more acks?
17:37:31 <pwhalen> ack
17:37:51 <mboddu> #agreed 1630943 - Proposed Freeze Exception - Since its affecting only laptops with closed lid we consider it as a Freeze Exception, if its happening more often then we will reclassify
17:38:06 <mboddu> Okay, thats it then
17:38:37 <mboddu> Thank you all for joining
17:38:53 <frantisekz> thank you for leading it for a while!
17:39:41 <mboddu> frantisekz: :)
17:39:46 <mboddu> #endmeeting
17:40:02 <frantisekz> oh
17:40:08 <frantisekz> you are not a chair it seems
17:40:17 <mboddu> frantisekz: Yes, someone has to end it
17:40:28 * mboddu checking who are all the chairs
17:40:34 <frantisekz> pwhalen, are you here?
17:40:56 <mboddu> I think its only adamw
17:40:57 <pwhalen> frantisekz, I am
17:41:04 <frantisekz> can you #endmeeting?
17:41:06 <pwhalen> #endmeeting