16:02:30 <adamw> #startmeeting F28-blocker-review
16:02:30 <zodbot> Meeting started Mon Mar 19 16:02:30 2018 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:30 <zodbot> The meeting name has been set to 'f28-blocker-review'
16:02:30 <adamw> #meetingname F28-blocker-review
16:02:30 <adamw> #topic Roll Call
16:02:30 <zodbot> The meeting name has been set to 'f28-blocker-review'
16:02:35 <frantisekz> .hello2
16:02:36 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:02:40 <kalev> .hello2
16:02:41 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:02:45 <lruzicka> hello
16:03:00 <lruzicka> .hello2
16:03:01 <zodbot> lruzicka: lruzicka 'None' <lruzicka@redhat.com>
16:03:14 * coremodule is here, will secretarialize!
16:03:38 <adamw> morning folks, who's around for blockertimes?
16:03:40 <adamw> thanks coremodule!
16:04:05 <coremodule> adamw, no problem!
16:04:11 <roca> hello and good morning all
16:04:14 * lbrabec is here
16:04:19 * lruzicka is here
16:05:30 * kparal is here
16:08:49 <adamw> hi folks
16:08:52 <adamw> welp, let's get rollin
16:09:06 <adamw> #chair frantisekz lruzicka
16:09:06 <zodbot> Current chairs: adamw frantisekz lruzicka
16:09:39 <frantisekz> hi, I'll be around just for about 90 minutes
16:09:40 <adamw> (note for newer folks, we always chair a couple of extra people in case the person running the meeting loses his connection or suddenly wins the lottery and retires to a desert island, so the meeting can continue)
16:09:47 <adamw> #chair kparal
16:09:47 <zodbot> Current chairs: adamw frantisekz kparal lruzicka
16:09:56 <adamw> #topic Introduction
16:09:56 <adamw> Why are we here?
16:09:56 <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:09:56 <adamw> #info We'll be following the process outlined at:
16:09:56 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:58 <adamw> #info The bugs up for review today are available at:
16:09:58 <lruzicka> adamw: What does a chair do?
16:10:00 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:10:04 <adamw> #info The criteria for release blocking bugs can be found at:
16:10:06 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:10:08 <adamw> #link https://fedoraproject.org/wiki/Fedora_28_Beta_Release_Criteria
16:10:10 <adamw> #link https://fedoraproject.org/wiki/Fedora_28_Final_Release_Criteria
16:10:19 <adamw> lruzicka: so long as i keep things rolling, nothing :P
16:10:40 <adamw> if i suddenly type "YESS HAHAHAHAH SEE YOU MORONS NEVER" and drop offline, then you can either pick up and carry on the meeting, or just close it out. at that point i won't care. :P
16:10:52 * pwhalen is here
16:11:04 <lruzicka> adamw: Sounds reasonable :D
16:11:24 <adamw> so, for Beta, we have:
16:11:24 <adamw> #info 7 Proposed Blockers
16:11:24 <adamw> #info 4 Accepted Blockers
16:11:24 <adamw> #info 0 Accepted 0-day Blockers
16:11:25 <adamw> #info 1 Accepted Previous Release Blockers
16:11:25 <adamw> #info 3 Proposed Freeze Exceptions
16:11:28 <adamw> #info 6 Accepted Freeze Exceptions
16:11:38 <adamw> #info for Final, we have:
16:11:39 <adamw> #info 5 Proposed Blockers
16:11:39 <adamw> #info 2 Accepted Blockers
16:11:43 <adamw> #info 1 Proposed Freeze Exceptions
16:13:04 <adamw> so, we may be here a while :P
16:13:11 <adamw> #info coremodule will secretarialize
16:13:36 <adamw> #info we'll start with proposed Beta blockers
16:13:36 <adamw> #topic (1557472) Anaconda installing in text mode fails to report errors to Bugzilla.
16:13:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1557472
16:13:37 <adamw> #info Proposed Blocker, anaconda, NEW
16:15:02 <kparal> seems like a blocker to me, in text mode
16:16:11 <lruzicka> I think that error reporting should be working everywhere, because that is how we can collect feedback from people.
16:16:30 <lruzicka> And if it does not, it should be fixed.
16:16:49 <adamw> the criterion doesn't exactly state which installer modes it applies to - it just says "The installer must be able to report failures to Bugzilla, with appropriate information included." - so i guess technically this is a conditional violation, the condition being 'text mode'.
16:17:20 <kparal> yes. +1
16:17:23 <pwhalen> I seem to recall someone else filing this, it crashes but the BZ's got posted?
16:17:34 <adamw> still, on that basis, i'm inclined to +1
16:17:38 <frantisekz> +1
16:17:39 <kalev> +1
16:17:41 <pwhalen> +1 as well
16:17:42 <adamw> ah, i hadn't got around to testing it yet...
16:17:44 <roca> +1
16:17:46 <Southern_Gentlem> +1
16:17:49 <kparal> lruzicka: did the bug get created?
16:18:04 * mkolman also has not yet looked into this issue
16:18:09 <adamw> worth noting, go/no-go is this thursday
16:18:21 <coremodule> +1
16:18:24 <adamw> so accepting blockers at this point is giving us not much time to fix them. just as a point to consider as we go along.
16:18:48 <kparal> adamw: of course, that information can't affect our unbiased decision process
16:18:49 <lruzicka> I am not sure, I know that there were several reported fake bugs, so it might have
16:19:08 <lruzicka> I can have a quick look
16:19:16 <adamw> proposed #agreed 1557472 - AcceptedBlocker (Beta) - this is accepted as a conditional violation of Basic criterion "The installer must be able to report failures to Bugzilla, with appropriate information included", we consider 'that always crashes in text mode' to be a sufficient violation to constitute a blocker
16:19:23 <frantisekz> ack
16:19:24 <adamw> kparal: remember, it is allowed to now. we wrote it down. :P
16:19:36 <kalev> ack
16:19:37 <pwhalen> ack
16:19:50 <coremodule> ack
16:19:56 <Southern_Gentlem> ack
16:19:56 <roca> ack
16:20:04 <kparal> ack
16:20:16 <adamw> #agreed 1557472 - AcceptedBlocker (Beta) - this is accepted as a conditional violation of Basic criterion "The installer must be able to report failures to Bugzilla, with appropriate information included", we consider 'that always crashes in text mode' to be a sufficient violation to constitute a blocker
16:20:45 <lruzicka> ack, but the crashed anaconda managed to file the zilla
16:20:52 <lruzicka> https://bugzilla.redhat.com/show_bug.cgi?id=1557463
16:21:02 <lruzicka> https://bugzilla.redhat.com/show_bug.cgi?id=1557471
16:21:24 <adamw> hum, i suspect i might wind up changing my vote in that case, if push comes to shove.
16:21:34 <adamw> since the main point of the criterion is "we get the crash report", not "the process looks good to the user"
16:21:35 <adamw> anyhoo
16:21:36 <kparal> I'd fine with moving to Final
16:21:44 <adamw> should we revote on that basis, or move along?
16:21:52 <kparal> let's move it right now
16:21:56 <adamw> anyone else feel like changing their vote?
16:22:06 <pwhalen> I am also fine with final
16:22:06 <roca> yes, if that's the case
16:22:07 <lruzicka> I am fine with final
16:22:22 <kparal> the problem is not that it crashes, but that it doesn't give you bug URL
16:22:23 <coremodule> Agreed, OK with final.
16:22:41 * kalev doesn't mind moving it to final.
16:22:52 <lruzicka> kparal: True, it does not.
16:23:49 <kparal> so, #undo?
16:23:51 <pwhalen> hrm, no url will be confusing
16:24:12 <mkolman> well, one should generally get an email about the new bug ?
16:24:19 <mkolman> not ideal but still something
16:24:23 <kparal> mkolman: after there's some activity in it
16:24:33 <pwhalen> both people who filed this didnt know the bz was posted and filed a new bug on it
16:24:41 <adamw> ok
16:24:43 <mkolman> ah, ok
16:24:43 <kparal> but I think this is fine for Beta, it gets reported. but for Final, the URL should be returned
16:24:45 <adamw> kparal: nah, i'll do a new agreement
16:25:46 <adamw> proposed #agreed 1557472 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - on second thought, we make this an FE for Beta and blocker for Final, as anaconda did manage to file the bug, it just crashed afterwards. we think this is OK for Beta (though fixing it would be nice), but should block Final.
16:26:06 <kalev> ack
16:26:10 <sumantro> ack
16:26:12 <coremodule> ack
16:26:12 <pwhalen> acl
16:26:14 <lruzicka> ack
16:26:16 <frantisekz> ack
16:26:17 <roca> ack
16:26:20 <Southern_Gentlem> ack
16:26:41 <kparal> ack
16:26:51 <adamw> #agreed 1557472 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - on second thought, we make this an FE for Beta and blocker for Final, as anaconda did manage to file the bug, it just crashed afterwards. we think this is OK for Beta (though fixing it would be nice), but should block Final.
16:27:01 <adamw> #topic (1557529) Setting root password on live images fails since anaconda-28.22.2-3.fc28
16:27:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1557529
16:27:01 <adamw> #info Proposed Blocker, anaconda, NEW
16:28:28 <Southern_Gentlem> +1
16:28:39 <adamw> so, we have a bit of new info on this too: it only happens if you *both* create a user and set a root password
16:28:45 <adamw> it doesn't happen if you only set root password
16:29:03 <kparal> funny
16:29:04 <kparal> +1
16:29:07 <adamw> however, that means you can still lock yourself out quite badly, as you could create a non-admin user and set the root password; that way you still can't get root without some emergency surgery.
16:29:09 <roca> +1
16:29:18 <pwhalen> +1
16:29:20 <frantisekz> +1
16:29:32 <sumantro> +!
16:29:34 <sumantro> +1*
16:29:57 <lruzicka> +1
16:31:03 <adamw> proposed #agreed 1557529 - AcceptedBlocker (Beta) - this is accepted as a blocker as a violation of "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system.
16:31:03 <adamw> 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.", read as applying to the root account
16:31:08 <adamw> grr, way too long.
16:31:11 * adamw chops
16:31:27 <adamw> proposed #agreed 1557529 - AcceptedBlocker (Beta) - this is accepted as a blocker as a violation of "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system", read as applying to the root account
16:31:50 <kparal> ack
16:31:51 <roca> ack
16:31:52 <pwhalen> ack
16:31:52 <adamw> if anyone can cite a better criterion...
16:31:56 <frantisekz> ack
16:32:23 <lruzicka> ack
16:32:24 <adamw> #agreed 1557529 - AcceptedBlocker (Beta) - this is accepted as a blocker as a violation of "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system", read as applying to the root account
16:33:39 <adamw> #topic (1558022) upgrading from fedora 27 server to fedora 28 server fails rpm transaction for docker
16:33:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1558022
16:33:39 <adamw> #info Proposed Blocker, docker, NEW
16:33:44 <adamw> this one's new on me
16:34:06 <pwhalen> i'm attempting to verify while I do the upgrade test on arm
16:34:26 <adamw> https://openqa.fedoraproject.org/tests/207089 doesn't show it...
16:34:51 <adamw> maybe arm-only?
16:34:52 <kalev> is docker in the server default install set?
16:34:57 <kparal> what funny language does dennis use?
16:35:04 <pwhalen> adamw, maybe?
16:35:17 <adamw> kparal: spanish
16:35:25 <lruzicka> kparal: Spanish?
16:35:27 <adamw> kalev: i don't think it is.
16:35:40 <adamw> also, Server on 32-bit ARM is not blocking.
16:35:51 <adamw> i think i'm -1 on this without more justification.
16:36:33 * kparal looks for docker in Server repo
16:36:40 <kalev> I'm -1 as well. If it's a general problem with rpm being completely broken on arm, that might be a different story, but if it's just docker failing on 32 bit ok, I don't think that's enough for beta blocker
16:36:52 <pwhalen> -1 blocker, +1 FE. will update the bz if I can/cant reproduce
16:37:00 <kparal> it's there
16:37:11 <kparal> does it mean it's in default install?
16:37:17 <kparal> http://dl.fedoraproject.org/pub/fedora/linux/development/28/Server/x86_64/os/Packages/d/
16:40:43 <adamw> no
16:40:53 <adamw> the install tree / dvd has several optional groups
16:41:21 <adamw> it's in the 'container-management' group in comps
16:41:51 <adamw> and indeed, 'container-management' is in the 'optionlist' for the 'server-product-environment' env group
16:41:52 <kparal> ok
16:42:06 <adamw> which basically means 'this is an optional group for server-product-environment'
16:42:13 <adamw> which means it'll be on the dvd and selectable for install, but not default
16:42:51 <adamw> so, this may not be arm-only, as i don't think any of the other openqa upgrade tests would have docker installed either
16:42:55 <adamw> so we should probably test it on other arches
16:43:20 <adamw> i'm -1 blocker for now as it's not in any blocking default package sets we know of. other than that, waiting for more info.
16:43:24 <lruzicka> I can test it tomorrow, if you want.
16:43:43 <adamw> sure, that'd be useful
16:44:42 <lruzicka> settled then
16:45:06 <adamw> any other votes, or shall we go with -1 blocker for now?
16:45:38 <frantisekz> -1 blocker sounds just right
16:45:43 <sumantro> -1 blocker
16:45:51 <kparal> -1
16:46:07 <roca> -1
16:46:09 <lruzicka> -1
16:46:44 <lbrabec> -1
16:47:45 <adamw> oh, do we want to go +1 FE right away? or wait for more details?
16:47:56 <adamw> i think i'd be +1 FE even if it's 32-bit ARM only, tbh. upgrade issues suck.
16:48:21 <Southern_Gentlem> +1 fe
16:48:58 <sumantro> +1 fe
16:49:02 * pwhalen is still +1 FE
16:49:24 <lruzicka> +1 fe
16:49:32 <coremodule> +1 FE
16:49:37 <roca> +1 FE
16:49:52 <kparal> +1 FE
16:50:00 <lbrabec> +1 fe
16:50:01 <adamw> okey dokey
16:50:18 <adamw> proposed #agreed 1558022 - RejectedBlocker (Beta) - so far it's not clear if this is ARM-only, 32-bit-only, or affects all installs with Docker. however, we are fairly sure Docker is not actually included in any default release-blocking package sets, meaning this cannot be a blocker. we accept it as a freeze exception, though, as it's obviously a significant package and fixing upgrade issues is desirable.
16:50:20 <adamw> grr
16:50:21 <adamw> patch
16:51:00 <adamw> proposed #agreed 1558022 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - it's not clear if this is ARM-only, 32-bit-only, or affects all arches. however, we are fairly sure Docker is not in any default release-blocking package sets, so it cannot be a blocker. we accept it as a freeze exception, though, as it's obviously a significant package and fixing upgrade issues is desirable.
16:51:13 <lruzicka> ack
16:51:15 <Southern_Gentlem> ack
16:51:21 <pwhalen> ack
16:51:22 <kalev> ack
16:51:29 <lbrabec> ack
16:51:37 <roca> ack
16:52:29 <sumantro> ack
16:53:00 <adamw> #agreed 1558022 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - it's not clear if this is ARM-only, 32-bit-only, or affects all arches. however, we are fairly sure Docker is not in any default release-blocking package sets, so it cannot be a blocker. we accept it as a freeze exception, though, as it's obviously a significant package and fixing upgrade issues is desirable.
16:54:53 <adamw> #topic (1557609) Login to FreeIPA web UI as regular user fails
16:54:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1557609
16:54:53 <adamw> #info Proposed Blocker, freeipa, NEW
16:55:53 <coremodule> +1
16:56:07 <lruzicka> +1
16:56:26 <kparal> +1
16:56:35 <lbrabec> +1
16:56:41 <roca> +1
16:56:46 <kalev> +1
16:56:51 <frantisekz> +1
16:56:58 * adamw checking it still happens
16:57:13 <adamw> yup, same result in today's nightly.
16:57:18 <Southern_Gentlem> +1
16:58:21 <pwhalen> +1
16:59:48 <adamw> proposed #agreed 1557609 - AcceptedBlocker (Beta) - this is accepted as a Beta blocker as a violation of "The core functional requirements for all Featured Server Roles must be met, without any workarounds being necessary", core requirement "The FreeIPA configuration web UI must be available and allow at least basic configuration of user accounts and permissions"
17:00:08 <coremodule> ack
17:00:16 <pwhalen> ack
17:00:22 <sumantro> ack
17:00:25 <lbrabec> ack
17:00:26 <frantisekz> ack
17:00:31 <kalev> ack
17:00:31 <lruzicka> ack
17:00:44 <Southern_Gentlem> ack
17:01:16 <roca> ack
17:01:42 <adamw> #agreed 1557609 - AcceptedBlocker (Beta) - this is accepted as a Beta blocker as a violation of "The core functional requirements for all Featured Server Roles must be met, without any workarounds being necessary", core requirement "The FreeIPA configuration web UI must be available and allow at least basic configuration of user accounts and permissions"
17:01:51 <adamw> #topic (1558064) Gnome-software does not allow to work with packages at all.
17:01:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1558064
17:01:52 <adamw> #info Proposed Blocker, gnome-software, NEW
17:02:18 <kalev> I am pretty sure this is a manifestation of the openh264 repo fallout
17:02:25 <adamw> yeah, me too
17:02:37 <adamw> that is, https://bugzilla.redhat.com/show_bug.cgi?id=1544193
17:02:43 <kparal> sounds likely
17:02:49 <kparal> lets dupe them
17:02:52 <adamw> current situation seems to be that the repo was created but there is some issue between the repo and packagekit relating to signatures
17:03:02 <adamw> note that 1544193 is an accepted blocker
17:03:18 <kparal> lruzicka: do you want to test removing the h264 repo whether that will fix gnome-software?
17:03:35 <lruzicka> now?
17:03:41 <kalev> I just tested with dnf and it fails with the same error
17:03:48 <lruzicka> if you give me some time
17:03:50 <adamw> kalev: aha, go hit dennis with that one then :P
17:04:12 <kalev> nod, updating the other ticket
17:04:59 <lruzicka> I checked the, cisco repo is disabled on my system
17:05:06 <lruzicka> and GS does not work properly.
17:05:46 <kalev> lruzicka: changing enabled_metadata to 0 in fedora-cisco-openh264.repo should make gnome-software work again
17:06:28 <lruzicka> kalev: That is my setting. Does not work though.
17:06:28 <kparal> lruzicka: killall gnome-software
17:06:54 <kparal> you must not expect gnome-software to just work after simply closing the window. that would be too easy
17:07:35 <lruzicka> well, if I kill it, repos disabled, the behaviour stays the same.
17:07:55 <adamw> lruzicka: do you get an error message somewhere?
17:07:59 <lruzicka> I only can install Facebook, Twitter, Telegram and Google Plus
17:08:00 <kparal> well then, let's accept it and debug the details later
17:08:10 <adamw> kalev: where should it log? i remember reading that now it should be logging errors, but i don't think the message siad where
17:08:13 <adamw> console? journal?
17:08:17 <kalev> adamw: journal
17:08:46 <lruzicka> kalev: failed to call gs_plugin_refine on packagekit-refine: failed to resolve package_ids: cannot update repo 'fedora-cisco-openh264': repomd.xml GPG signature verification error: Signature verify error - no signatures
17:08:57 <kalev> yeah, that's the same openh264 issue
17:08:58 <adamw> that's 1544193, yeah
17:08:59 <kparal> lruzicka: maybe remove the whole .repo file
17:09:08 <lruzicka> aha, strange
17:09:13 <lruzicka> I will remove
17:09:34 <adamw> it'd be worth investigating this angle more, but i don't think i'd block on 'it's weirdly hard to get Software to ignore a repo'
17:09:57 <adamw> lruzicka: just to confirm, try moving the repo file away and rebooting to get a clean slate...
17:10:04 <adamw> if that works i think we can say this is a dupe
17:10:42 <lruzicka> rebooting would cut me off
17:10:46 <lruzicka> I will try VM
17:11:14 <kalev> lruzicka: try 'sudo killall -9 packagekitd; killall gnome-software; rm /etc/yum.repos.d/fedora-cisco-openh264.repo' and then start gnome-software again
17:11:58 <kalev> I fixed a bunch of issues in packagekit/gnome-software so that most .repo file errors now correctly show up inside gnome-software
17:12:12 <kalev> but a gpg check issue seems to have slipped through, sorry
17:12:22 <kalev> so it's just logged on console
17:12:32 <lruzicka> I can confirm its working noew
17:12:33 <kalev> err, journal
17:12:36 <kalev> ah good
17:12:46 <lruzicka> I havent killed packagekit before
17:13:25 <Southern_Gentlem> dup +1
17:13:25 <kparal> ok, let's dupe it
17:14:38 <kalev> gnome-software should be able to survive most .repo errors, but errors in openh264 are hard errors because it says skip_if_unavailable=False in the .repo file
17:15:00 <adamw> ok
17:15:01 <kalev> I've tried to advocate for removing that line but releng didn't like the idea
17:15:57 <adamw> proposed #agreed 1558064 - close as duplicate of 1544193 - investigation during the meeting confirmed that lruzicka's failure was in fact caused by the existing accepted blocker #1544193
17:16:05 <kalev> ack
17:16:11 <Southern_Gentlem> +1
17:16:21 <lbrabec> ack
17:16:28 <roca> ack
17:16:30 <sumantro> ack
17:16:30 <lruzicka> ack
17:16:33 <Southern_Gentlem> or ack whichever
17:17:20 <pwhalen> ack
17:17:44 <kparal> ack
17:17:56 <frantisekz> ack
17:18:30 <adamw> #agreed 1558064 - close as duplicate of 1544193 - investigation during the meeting confirmed that lruzicka's failure was in fact caused by the existing accepted blocker #1544193
17:18:30 <adamw> <kalev> ack
17:18:32 <adamw> grr
17:18:42 <adamw> #topic (1557659) aacraid: Host adapter abort request
17:18:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1557659
17:18:42 <adamw> #info Proposed Blocker, kernel, NEW
17:20:08 <adamw> aacraid is, what, adaptec RAID
17:20:59 <adamw> these are usually a bit squishy...
17:21:12 <adamw> "I've tried three times,all failed,but installation of f27/rhel to the save server is successful." is worrying, though
17:21:22 <kparal> so is this a combination of FCoE and RAID?
17:21:55 <lruzicka> what about an upgrade on existing system? can that be a workaround?
17:22:09 <kparal> lruzicka: nope
17:22:22 <kparal> certainly not for our criteria :)
17:23:13 <adamw> kparal: it *is*, but this looks like the FCoE part isn't really involved
17:23:42 <adamw> this just looks like a bug/error in the kernel driver for the RAID controller
17:23:49 <adamw> of course, i could be missing something.
17:24:16 <kparal> ok. so we need to decide if that raid controller is important enough
17:24:20 <kparal> I have no idea
17:24:36 <adamw> yeah, this is also a very squicky criterion
17:24:41 <adamw> since not many people really test it
17:24:50 <adamw> we usually wind up going with more or less the first test result we get :/
17:25:03 * adamw updating his kernel checkout
17:25:04 <kparal> btw, I proposed another firmware raid bug as blocker as well
17:25:08 <adamw> yay
17:25:14 <lruzicka> kparal: This is what I meant by the workaround, I cannot find if we support this RAID controller
17:25:15 <kparal> some time ago, it should be on the list
17:25:16 <adamw> i think this is actually hwraid, btw.
17:25:22 <adamw> lruzicka: we don't have a specific list
17:25:29 <adamw> all we have is this rather vaguely-worded criterion which some idiot wrote
17:25:36 <adamw> (wonder who that was)
17:25:41 <kparal> let's fire him
17:25:45 <kparal> problem solved
17:25:54 <adamw> .fire adamw woohoo pina colada time
17:25:54 <zodbot> adamw fires adamw woohoo pina colada time
17:26:08 <kparal> adamw: no slacking!
17:26:24 * kparal doubles adamw's work instead
17:26:37 <kparal> *workload
17:26:56 <adamw> there's been quite a lot of activity on the driver lately, it seems...
17:27:04 <adamw> around january
17:27:11 <kparal> so punt and ask somehow who knows more than us?
17:27:15 <kparal> *someone
17:27:17 * adamw looking at upstream kernel tree, not sure where f28 is up to
17:27:26 <adamw> i'd say 'yes', only we're quite tight on time
17:27:49 * adamw sees if we have any kernel maintainers around
17:31:09 * adamw talking to jforbes
17:33:07 <jforbes> While this is a bug, and should be fixed, I wouldn't call it a blocker by even a stretch
17:33:35 <lruzicka> :)
17:33:55 <kparal> we should re-discuss our criterion then
17:34:06 <jforbes> fcoe over aacraid isn't a common, or even ever necessary configuration
17:34:19 <adamw> jforbes: well, i was kinda figuring the fcoe part here wasn't involved
17:34:22 <adamw> but i guess we don't really know that
17:35:35 <adamw> well, maybe we do know whether it's involved, do the logs say?
17:36:40 <adamw> oh, hmm, yes, i see. the raid device itself is being accessed over fcoe. duh.
17:36:41 <jforbes> Error retrieving target FID from name server.
17:36:42 <jforbes> 
17:36:42 <jforbes> ERROR: Failed to connect to any configured disk!
17:37:01 <adamw> so, yeah, i think we can reasonably say this isn't blocker at least so long as it involves the *combination* of the two.
17:37:14 <adamw> then we can put lili in the kparal isolation unit to ensure no testing of aacraid without fcoe is done, and we'll be good. :P
17:37:46 <kparal> good idea, I'll lend her my unit
17:38:06 <adamw> wait. no. we need to build another.
17:38:11 <adamw> can't possibly leave you without one, after all.
17:38:12 <kparal> damn
17:38:32 <lruzicka> maybe the unit can hold two
17:39:36 <adamw> proposed #agreed 1557659 - punt (delay decision) - so long as this involves a combination (RAID device accessed over FCoE) we think that's too esoteric to be considered as violating the criteria. if testing indicates that aacraid is entirely broken for a *local* adapter, we will consider whether that is blocker-worthy.
17:39:47 <adamw> (we could also say RejectedBlocker, it's kinda a wash)
17:39:54 <kparal> ack
17:39:57 <lruzicka> ack
17:39:58 <sumantro> ack
17:39:59 <roca> ack
17:40:00 <adamw> if anyone prefers to reject-without-prejudice, say so, and i'll patch
17:40:09 <lbrabec> ack
17:40:27 <jforbes> ack from my end, I would say that aacraid local adapter broken would definitely be worth blocker consideration.
17:40:32 <pwhalen> ack
17:41:36 <kalev> ack
17:42:22 <coremodule> ack
17:43:25 <frantisekz> ack
17:43:52 <adamw> okay
17:43:56 <adamw> #agreed 1557659 - punt (delay decision) - so long as this involves a combination (RAID device accessed over FCoE) we think that's too esoteric to be considered as violating the criteria. if testing indicates that aacraid is entirely broken for a *local* adapter, we will consider whether that is blocker-worthy.
17:44:11 <adamw> #topic (1557957) TypeError: __init__() got an unexpected keyword argument 'wwn'
17:44:11 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1557957
17:44:11 <adamw> #info Proposed Blocker, python-blivet, NEW
17:44:51 <lruzicka> +1
17:45:47 <kparal> look, a raid bug. what a surprise
17:46:03 <roca> +1
17:46:06 <sumantro> +1
17:46:13 <lruzicka> kparal: This one's pretty severe :)
17:46:43 <frantisekz> +1
17:46:58 <lbrabec> +1
17:47:01 <adamw> yeah, looks like +1
17:47:02 <coremodule> +1
17:47:06 <mkolman> broken RAID ? IMPOSSIBLE! ;-)
17:47:11 <adamw> intel fwraid is the most common kind...
17:47:16 <pwhalen> +1
17:48:07 <adamw> proposed #agreed 1557957 - AcceptedBlocker (Beta) - this is accepted as a blocker as a violation of "The installer must be able to detect and install to hardware or firmware RAID storage devices", it looks like a showstopper for all Intel firmware RAID cases, which is one of the most common firmware RAID cases.
17:48:17 <pwhalen> ack
17:48:18 <sumantro> ack
17:48:19 <frantisekz> ack
17:48:22 <lbrabec> ack
17:48:27 <Southern_Gentlem> ack
17:48:28 <lruzicka> ack
17:48:31 <coremodule> ack
17:49:10 <adamw> #agreed 1557957 - AcceptedBlocker (Beta) - this is accepted as a blocker as a violation of "The installer must be able to detect and install to hardware or firmware RAID storage devices", it looks like a showstopper for all Intel firmware RAID cases, which is one of the most common firmware RAID cases.
17:49:19 <adamw> OK, that's all the proposed beta blockers
17:49:28 <adamw> let's do Beta FEs next, as we're close to the beta deadline
17:49:34 <adamw> #info next, proposed Beta FEs
17:49:40 <adamw> #topic (1554966) Include GNOME 3.28.0 in Fedora 28 Beta
17:49:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1554966
17:49:40 <adamw> #info Proposed Freeze Exceptions, distribution, ON_QA
17:50:35 <frantisekz> +1 FE
17:50:44 <sumantro> +1 FE
17:50:59 <kalev> lots of positive feedback so far
17:51:11 <Southern_Gentlem> +1 FE
17:51:14 <kalev> and we took the one controversial thing (cantarell update) out of this
17:51:17 <kalev> +1 FE
17:51:36 <lruzicka> +1 FE
17:52:12 <kparal> kalev: have you figured which package failed the rpmdeplint task? or is still not pushable?
17:52:16 <Southern_Gentlem> hopefully we can get a build with it included to test by thursday
17:52:41 <kalev> kparal: no idea, let me try to submit to batched now and see what happens
17:52:59 <kparal> ok. +1 FE
17:53:06 <adamw> we can always waive the failure, right?
17:53:35 <roca> +1 FE
17:53:38 <kalev> if we figure out what the failure is :) all I know so far is "1 of 117 required tests failed"
17:53:44 <adamw> is the list failing to load?
17:53:44 <kalev> anyway, submitting to batched was successful
17:53:50 <adamw> oh, yay.
17:54:09 <kalev> yep, just timing out (or at least it was on friday, still loading now but I bet it times out again)
17:54:15 <kparal> kalev: you can submit the waiver for all builds :)
17:54:21 <kalev> ahh :)
17:54:53 <adamw> hah, true.
17:54:55 <pwhalen> +1 FE
17:54:58 <adamw> "ALL DEPENDENCIES ARE FINE"
17:56:02 <kparal> don't forget to prefix that with sudo
17:56:41 <adamw> proposed #agreed 1554966 - AcceptedFreezeException (Beta) - in general we like to get the latest GNOME in Beta we plausibly can, so tests are run with up-to-date code, and this fixes several other known bugs. It's been quite extensively tested, with positive results.
17:57:01 <kalev> if possible, can we get a stable push with this included as soon as possible, so that we see if it breaks anything in nightly builds?
17:57:04 <kalev> ack
17:57:08 <lruzicka> ack
17:57:12 <adamw> kalev: i'll do a stable push request today, most likely.
17:57:22 <pwhalen> ack
17:57:47 <sumantro> ack
17:57:55 <roca> ack
17:58:01 <kparal> ack
17:58:16 <adamw> #agreed 1554966 - AcceptedFreezeException (Beta) - in general we like to get the latest GNOME in Beta we plausibly can, so tests are run with up-to-date code, and this fixes several other known bugs. It's been quite extensively tested, with positive results.
17:58:31 <adamw> kalev: given that you built a live image and that worked, though, i don't expect any problems.
17:58:54 <adamw> if there is a real broken dep, it should show up in the nightly report, i guess.
17:59:35 <adamw> #topic (1554279) pconfigintrin.h missing on x86_64
17:59:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1554279
17:59:36 <adamw> #info Proposed Freeze Exceptions, gcc, ASSIGNED
17:59:44 <adamw> oh, i should've unproposed this, i think.
17:59:52 <adamw> seems the problem is likely not in f28, per gcc maintainers.
18:01:24 <lruzicka> seems so, based on what they wrote in the bugzilla
18:01:46 <adamw> #info as the proposer, adamw is unproposing this, per gcc maintainer stating the problem is not in f28
18:02:31 <adamw> #topic (1554986) [abrt] gnome-software: gs_plugin_loader_app_create(): gnome-software killed by SIGTRAP
18:02:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1554986
18:02:31 <adamw> #info Proposed Freeze Exceptions, gnome-software, ON_QA
18:02:42 <lruzicka> +1
18:02:44 <adamw> this seems to be fixed by the mega-update, so perhaps a bit academic?
18:02:54 <roca> +1
18:03:10 <adamw> still, on the merits, +1.
18:03:12 <kalev> yes, I filed it in case the mega-update doesn't get accepted
18:03:29 <kalev> with the plan to split gnome-software out of the megaup-date in that case
18:03:30 <adamw> i'm fine with accepting it, just in case we have to take the mega-update back out for some reason.
18:03:32 <kparal> +1 or skip
18:03:44 * adamw predicted kparal
18:03:49 <adamw> spooooooky
18:03:53 <kalev> sure, +1 then
18:03:59 * lruzicka is sorry, nature calls
18:03:59 <satellit> adamw: got gnome-software failure today https://bugzilla.redhat.com/show_bug.cgi?id=1557808  is it pointed to right repo?
18:04:32 <adamw> satellit: https://bugzilla.redhat.com/show_bug.cgi?id=1544193
18:04:41 <pwhalen> +1
18:04:57 <adamw> satellit: although, yours may be different. can you post a full log?
18:05:33 <adamw> proposed #agreed 1554986 - AcceptedFreezeException (Beta) - this should be covered by the 3.28.0 exception, but in case that has to be backed out, we accept this as an FE on its own merits and would accept a separate fix
18:05:39 <kalev> ack
18:05:39 <satellit> I only have a screeshot atm
18:05:49 <roca> ack
18:05:53 <adamw> satellit: check the journal.
18:05:59 <satellit> k
18:06:12 <kalev> satellit: if you manage to reproduce it, some more info would be useful: rpm -q gnome-software, rpm -q PackageKit, anything relevant from journalctl
18:06:27 <kalev> I suspect it's some kind of transient failure that's not handled very well in gnome-software and has disappeared by now
18:06:41 <adamw> one more ack?
18:06:48 <Southern_Gentlem> ack
18:07:06 <pwhalen> ack
18:07:15 <lruzicka> ack
18:07:29 <sumantro> ack
18:08:10 * adamw dies, buried in acks
18:08:12 <adamw> rip me
18:08:16 <adamw> #agreed 1554986 - AcceptedFreezeException (Beta) - this should be covered by the 3.28.0 exception, but in case that has to be backed out, we accept this as an FE on its own merits and would accept a separate fix
18:08:44 <adamw> again since we're on a short schedule, let's quickly look at:
18:08:49 <adamw> #info checking in on accepted Beta blockers
18:09:05 <adamw> three are clearly under controlish, the one that concerns me is:
18:09:06 <adamw> #topic (1520580) Unable to log in on arm disk images
18:09:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1520580
18:09:06 <adamw> #info Accepted Blocker, selinux-policy, NEW
18:10:08 <adamw> pwhalen: it looks like we're getting *somewhere* with this, but do you think we're gonna be able to pin it down soon?
18:10:15 <adamw> looks like perhaps label setting during image creation isn't working right?
18:10:32 <pwhalen> it does, not sure how quickly it can be fixed
18:11:24 <adamw> okay. is there anything we can do to hurry it along at all, or are all useful eyes already on it?
18:13:15 <pwhalen> not sure, I think the nudge helped
18:13:47 <adamw> okay.
18:14:18 <adamw> #info there is some progress being made on this now, it seems to be the most concerning of current accepted blockers in terms of getting fixed on time, however. we will continue to monitor it
18:14:27 <adamw> so, let's quickly go for the:
18:14:33 <adamw> #info proposed Final blockers
18:15:27 <adamw> note, 1554550 is fixed.
18:16:33 <adamw> #topic (1558027) The network.service failed LSB in Fedora Cloud.
18:16:34 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1558027
18:16:34 <adamw> #info Proposed Blocker, initscripts, NEW
18:18:52 <kparal> that cloud image was spun up using testcloud
18:19:03 <kparal> so that's why there's no such network device I guess
18:19:20 <kparal> the question is whether that's the problem or the missing dhclient-script
18:20:00 <lruzicka> lnykryn:
18:20:01 <lruzicka> this looks like a bug:
18:20:02 <lruzicka> Mar 19 12:54:32 testcloud network[461]: Determining IP information for eth0.../usr/sbin/dhclient-script: line 220: run-parts: command not found
18:22:16 <adamw> it'd be good to know if this works with f27, since lruzicka is getting started with running these tests
18:22:29 <adamw> perhaps there's something non-obvious about doing this test with testcloud...
18:22:32 * adamw has never done it
18:23:25 <kparal> lbrabec has been testing the images using testcloud in the past
18:23:28 <kparal> and they worked
18:23:34 <kparal> e.g. the F27 ones
18:23:54 <kparal> it just spins up a pretty default libvirt VM
18:24:01 <lruzicka> lbrabec was helping me to test this one, he wondered why that did not work
18:24:38 <kparal> of course it would be nice to test the bug in a real cloud env
18:24:52 <kparal> we do have some people to bug about that, right?
18:25:27 <adamw> yeah, there's a test matrix for it and everything...
18:26:24 <adamw> per https://www.happyassassin.net/testcase_stats/28/Cloud/QA_Testcase_Services_start__lt_b_gt_x86_64_lt__b_gt_.html , someone filed a pass for this test in openstack for the 20180130 nightly
18:26:26 <adamw> nothing since
18:26:57 <adamw> i'd say maybe punt till we're more sure what's going on here, but it sure looks like a problem
18:27:05 <lruzicka> I would also like to say that the networking in the VM was working fine
18:28:56 <adamw> so, the service fails, but the network actually works?
18:29:02 <adamw> that's a lot better than the other way around. :P
18:29:22 <lruzicka> it works indeed, I do not know why it fails :)
18:29:33 <adamw> networking is fun.
18:29:40 <adamw> check if NetworkManager is enabled, for a start.
18:29:46 <lruzicka> maybe, it does not fail, just reports wrong status
18:29:58 <adamw> or, it gets far enough to bring up the important interface before failing.
18:30:07 <adamw> the 'network' "service" is really just a pile of bash.
18:30:22 <adamw> if you're interested, go ahead and poke through it, it's educational!
18:30:34 <adamw> anyhoo, anyone else for punting?
18:30:44 <Southern_Gentlem> +1
18:30:49 <lruzicka> I will try to check NM tomorrow
18:30:52 <adamw> i'd at least like to know if the service shows as failed in our supported cloud environments
18:31:12 <Southern_Gentlem> +1 punt for more info
18:31:57 <roca> more info
18:32:57 <adamw> proposed #agreed 1558027 - punt (delay decision) - we certainly think there could be a blocker issue here, but we'd like more clarity on what's going on. we'd particularly like to know if the service fails in our supported cloud environments.
18:34:09 <lruzicka> ack
18:34:27 <adamw> any more acks, any more acks, any any any more aaaaacks
18:34:32 <kparal> ack
18:34:49 <kparal> ack (with a mustache on)
18:35:01 <kalev> ack
18:35:07 <roca> ack
18:35:37 * adamw counts four acks from kparal
18:35:43 <adamw> okay, we're good
18:35:44 <pwhalen> aaaaack
18:35:50 <adamw> #agreed 1558027 - punt (delay decision) - we certainly think there could be a blocker issue here, but we'd like more clarity on what's going on. we'd particularly like to know if the service fails in our supported cloud environments.
18:36:02 <adamw> #topic (1555292) Fedora Workstation Live can't resume after suspend when booted from DVD connected via an external drive
18:36:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1555292
18:36:02 <adamw> #info Proposed Blocker, kernel, NEW
18:36:28 <kparal> a spicy topic, finally
18:36:32 <adamw> instinctively, i think i'd be happier blocking on 'auto-suspend should be disabled on live images' than 'suspending live images should work'
18:36:43 <kparal> well, that's one solution to the problem
18:36:49 * kalev has to leave now, sorry guys.
18:37:03 <adamw> kalev: you have any quick opinions on this?
18:37:24 <kparal> that might be the reason why he has to leave :)
18:37:48 <mkolman> run! ;-)
18:37:59 <adamw> =)
18:38:16 * adamw looks at the kalev-shaped hole in the wall and the cloud of dust disappearing into the distance
18:38:25 <kparal> we tested one bare metal with internal drive, that worked. on the same machine with external drive, it worked as well. but on a different bare metal with external drive, this bug happens 100%
18:39:11 <kparal> so, we don't have too much hardware to guess how frequent this is
18:39:28 <satellit> auto suspend messes up DVD installs times out
18:39:48 <kparal> but since firmware is often buggy and there's no benefit in having auto suspend on livecd, I'd say this is a very stupid thing to have enabled by default
18:40:14 <kparal> also, it should be very easy to disable, if we want
18:40:23 <adamw> well....possibly not with the gdm wrinkle.
18:40:28 <kparal> or rather if someone else doesn't object too much
18:40:35 <adamw> but at least it should be *as* easy to get that done in the kickstart as getting it done anywhere else.
18:40:46 <kparal> adamw: nope, but you get auto-logged in on live
18:41:03 <adamw> true, i do feel like the gdm timeout is a time bomb just sitting around waiting to get tripped somehow, though.
18:41:12 <adamw> maybe we can change the schema default in livesys? not sure if that'd work.
18:41:14 <lruzicka> agreed
18:41:18 <adamw> i mean, it *should*.
18:41:28 <kparal> adamw: it should. we already adjust similar stuff there
18:42:16 <adamw> satellit: anaconda inhibits suspend. autosuspend should never happen *during* installation.
18:42:45 <kparal> adamw: if you feel like the gdm timeout issue should be proposed as a blocker, I can file it in bugzilla and propose it. but I'm not sure how to justify the proposal
18:42:56 <adamw> so...i think maybe i'd propose this: we punt with a specific intent
18:43:17 <adamw> we send out a call for testing asking people just to try booting live as they usually would, let the system auto-suspend, and see if they can resume and it works.
18:43:41 <kparal> they can suspend manually, no need to wait for it
18:44:03 <adamw> eh, i mean, mostly, yeah, but i've actually experienced different behaviours for suspend depending on exactly how it's triggered and how long it's left suspended...
18:44:04 <kparal> testing optical media is a big plus, but usb is also great
18:44:12 <adamw> but sure, we can say that, in general results should be the same
18:44:48 <adamw> so, we do that, and if that indicates significant issues with suspending live images, that would justify (I think) blocking on 'live suspend should either be made to magically work as well as installed system suspend, or suppressed'
18:45:04 <adamw> using maybe a loose reading of 'live images should boot to working desktop' or whatever
18:45:11 <kparal> the question is whether we need to do this, or we straight away ask gnome team to disable it on livecd. have they provided a good reason why they want to have it enabled?
18:45:15 <adamw> at least, it lets us kick the can down the road. :P
18:45:30 <adamw> kparal: we could refresh the thread, for sure
18:45:49 <adamw> the discussion kinda went off down various paths and i don't think the simple question of whether we should just disable it for live sessions was properly considered
18:45:57 <roca> I'm mixed on this
18:46:04 <adamw> that can be another thing we do while punting on this.
18:46:21 <mclasen> the reason to have it enabled is 'live system should give you a preview of what the installed system is like'
18:46:34 <mclasen> of course, if it doesn't work, that is not very useful
18:46:55 <adamw> right. i'd say that's not sufficient justification *if* we can show that this is commonly broken.
18:47:18 <roca> mclasen: agreed yet I haven't been able to reproduce this bug off a live usb
18:47:34 <kparal> does it have to be commonly broken? if it breaks just for a few people, is this still worth it having it enabled? I don't see any benefit
18:47:39 * satellit persistence on live USB...how does it affect persistence section?
18:48:07 <kparal> does microsoft installer auto-suspend? I hardly think so. (but I could try)
18:48:37 <kparal> aaanyway, it seems we'll call for wider testing
18:48:56 <lruzicka> I am generally not a fan of suspending by default. Suspending a live system is quite an overkill.
18:50:23 <lruzicka> so I am going to support the idea to switch it off for a live system.
18:50:31 <adamw> yeah, i think we should punt for more chin-stroking on this, in general. :P
18:51:31 <adamw> proposed #agreed 1555292 - punt (delay decision) - we'd like to do two things before making a decision here: call for wider testing of suspending of live images to see just how commonly it fails, and re-start the desktop@ discussion about whether it would make sense to disable auto-suspend of the live image just on general principles
18:51:46 <adamw> kparal: btw, does the machine where this fails have less RAM than the one where it succeeds?
18:51:50 <mclasen> kparal: great argument, I'll remember that for the next time selinux is discussed...
18:52:04 <adamw> i generally suspect that RAM size is gonna be a big factor in this.
18:52:10 <kparal> adamw: I'm not sure, but both have at least 4GB, more probably 8GB
18:52:17 <adamw> since the entire live system is loaded into RAM, and then suspended to RAM.
18:52:32 <kparal> adamw: it's not "suspended into RAM", it says in RAM. it doesn't increase its usage
18:52:36 <kparal> *stays
18:52:40 <adamw> mathematically, if the running live session consumes 2GB, it wouldn't surprise me if suspending it into 4GB of RAM fails.
18:52:47 <adamw> are you sure?
18:52:49 * adamw isn't
18:52:50 <adamw> :P
18:53:02 <kparal> you're mixing hibernation and suspend
18:53:05 <adamw> oh, right. duh
18:53:13 <adamw> oh well, i dunno then, let's just test it.
18:53:19 <adamw> like the test monkeys we are!
18:53:19 <kparal> hibernation is ram saved to disk. suspend is just keeping ram modules powered
18:53:23 <adamw> right.
18:53:30 * adamw knows computers
18:53:48 <adamw> ack/nack/patched?
18:53:57 <adamw> quickly, cos we've got 7 minutes and two more to do?
18:53:58 <kparal> mclasen: selinux is disabled during installation
18:54:17 <kparal> ack
18:54:19 <lruzicka> ack
18:54:25 <roca> ack
18:54:50 <sumantro> ack
18:55:15 <pwhalen> ack
18:55:24 <satellit> ack
18:56:09 <adamw> touche, kparal
18:56:09 <adamw> :P
18:56:17 <adamw> #agreed 1555292 - punt (delay decision) - we'd like to do two things before making a decision here: call for wider testing of suspending of live images to see just how commonly it fails, and re-start the desktop@ discussion about whether it would make sense to disable auto-suspend of the live image just on general principles
18:56:21 <adamw> #topic (1544507) [abrt] pulseaudio: pa_sink_assert_ref(): pulseaudio killed by SIGABRT
18:56:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1544507
18:56:21 <adamw> #info Proposed Blocker, pulseaudio, ON_QA
18:57:24 <adamw> i'm kinda -1 on this. seems to be too much of a 'hardware support is not perfect, film at 11' case for me.
18:57:48 <kparal> lbrabec also saw this
18:58:11 <kparal> it feels like it affects a lot of people
18:58:15 <lruzicka> I did not have the issue on t460, Bugzilla claims it is fixed
18:58:40 <roca> A few dups of this. I believe I filed one... checking
18:59:16 <roca> Happens every single time. I'm on a Lenovo Yoga
18:59:21 <adamw> lruzicka: the 'fix' is in updates-testing, per the bug
18:59:29 <adamw> so if you're got the updated pulseaudio from u-t, yes, it's fixed
18:59:35 <kparal> I think broken jack output is kinda +1 blocker
18:59:45 <lruzicka> adamw: I do.
18:59:55 <adamw> so, yeah, for *you* it's fixed.
19:00:05 <adamw> but until the update is pushed stable, the issue isn't closed so far as the distro is concerned.
19:00:11 <adamw> oop, we're at time limit
19:00:14 <kparal> perhaps we should do Beta FE as well?
19:01:15 <kparal> it has a lot of karma
19:01:24 <adamw> i'm open to that
19:01:30 <kparal> I'm +1 Final blocker / +1 Beta FE
19:01:38 <adamw> i'm +1 beta FE, +/-0 final blocker
19:01:52 <lruzicka> same as kparal
19:02:03 <kparal> I assume that broken jack output not only means broken headphones but also broken loudspeakers
19:02:03 <sumantro> +1 beta FE
19:02:08 <lruzicka> +1 FB, +1 BFE
19:02:19 <kparal> so for desktops, it violates the criterion completely
19:02:27 <kparal> for laptops, it's not that harsh
19:02:51 <adamw> .fire lruzicka you're too new to make up acronyms, damnit
19:02:51 <zodbot> adamw fires lruzicka you're too new to make up acronyms, damnit
19:02:52 <roca> Audio still works
19:03:04 <roca> so I'm +1 FE
19:03:14 <roca> https://bugzilla.redhat.com/show_bug.cgi?id=1555115
19:03:53 <pwhalen> +1 FE
19:04:35 <adamw> proposed #agreed 1544507 - AcceptedFreezeException (Beta), AcceptedBlocker (Final) - we accept this as a Beta freeze exception as it appears to affect a lot of commonly-used hardware and will affect live sessions. we accept it as a Final blocker as a conditional violation of "The installed system must be able to play back sound with gstreamer-based applications"
19:04:57 <kparal> ack
19:05:02 <nb> ack
19:05:06 <sumantro> ack
19:05:11 <kparal> that's it for today, right?
19:05:15 <adamw> #agreed 1544507 - AcceptedFreezeException (Beta), AcceptedBlocker (Final) - we accept this as a Beta freeze exception as it appears to affect a lot of commonly-used hardware and will affect live sessions. we accept it as a Final blocker as a conditional violation of "The installed system must be able to play back sound with gstreamer-based applications"
19:05:21 <adamw> yup, per the rules, we're over time limit, so we wind up here
19:05:24 <roca> ack
19:05:28 <kparal> ok
19:05:31 <adamw> #topic Open floor
19:05:45 <adamw> #info per the meeting policy we're over the time limit, so we leave the remaining proposed Final blocker for next meeting
19:05:57 <adamw> any super-urgent Beta business that wasn't covered?
19:06:01 <adamw> otherwise i'll wind things up
19:06:01 <kparal> nope
19:06:20 <lruzicka> ack
19:07:07 <adamw> thanks for coming, everyone!
19:07:11 <adamw> sorry for the long meeting
19:07:11 <kparal> thanks
19:07:13 <adamw> #endmeeting