16:03:56 <adamw> #startmeeting F30-blocker-review
16:03:56 <zodbot> Meeting started Mon Apr 15 16:03:56 2019 UTC.
16:03:56 <zodbot> This meeting is logged and archived in a public location.
16:03:56 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:56 <zodbot> The meeting name has been set to 'f30-blocker-review'
16:03:56 <adamw> #meetingname F30-blocker-review
16:03:56 <zodbot> The meeting name has been set to 'f30-blocker-review'
16:03:56 <adamw> #topic Roll Call
16:04:04 <adamw> ahoyhoy folks, who's around for some meeting fun
16:04:06 <frantisekz> .hello2
16:04:07 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:04:09 * pwhalen is here
16:04:13 <jlanda> .hello2
16:04:14 <zodbot> jlanda: jlanda 'Julen Landa Alustiza' <julen@zokormazo.info>
16:04:33 <bcotton> .hello2
16:04:34 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:04:40 <coremodule> .hello2
16:04:41 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:05:11 <coremodule> Good morning! /me is willing to secretarialize, and won't forget it this week!
16:05:21 <lruzicka> .hello2
16:05:22 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:05:27 <cmurf> .hello2
16:05:28 <zodbot> cmurf: Sorry, but you don't exist
16:05:30 <cmurf> YES!
16:07:27 <adamw> .fire coremodule
16:07:27 <zodbot> adamw fires coremodule
16:07:33 <adamw> #chair bcotton jlanda
16:07:33 <zodbot> Current chairs: adamw bcotton jlanda
16:07:39 <coremodule> ...not again!
16:07:44 <adamw> INCOMING BOILERPLATE ALERT
16:07:46 <adamw> #topic Introduction
16:07:46 <adamw> Why are we here?
16:07:46 <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:07:46 <adamw> #info We'll be following the process outlined at:
16:07:46 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:49 <adamw> #info The bugs up for review today are available at:
16:07:51 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:52 <coremodule> THat's the fifth time this year!
16:07:53 <adamw> #info The criteria for release blocking bugs can be found at:
16:07:55 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:07:57 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria
16:07:59 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Final_Release_Criteria
16:08:08 <adamw> we have:
16:08:15 <adamw> #info 5 Proposed Blockers
16:08:15 <adamw> #info 4 Accepted Blockers
16:08:19 <adamw> #info 6 Proposed Freeze Exceptions
16:08:19 <adamw> #info 2 Accepted Freeze Exceptions
16:08:32 <adamw> .fire coremodule here, let's make it a round half-dozen
16:08:35 <zodbot> adamw fires coremodule here, let's make it a round half-dozen
16:08:55 <adamw> #info coremodule will secretarialize (without pay, obvs)
16:08:55 <coremodule> *facepalm*
16:09:01 <jlanda> 7 would be 111, it's nice :D
16:09:14 * adamw tempted
16:09:24 <adamw> #info let's get started with the proposed blockers
16:09:56 <adamw> #topic (1699280) Fedora 30 beta install fails with Error in <unknown> scriptlet in rpm package breeze-icon-theme
16:09:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1699280
16:09:57 <adamw> #info Proposed Blocker, breeze-icon-theme, MODIFIED
16:10:35 <adamw> it seems like this is alleged to happen only on kickstart installs for some reason?
16:10:45 <lruzicka> I am installing the latest version of the breeze package to see if it works at the moment.
16:10:45 <adamw> which is...interesting in its own right
16:11:14 <adamw> i would sort of expect it to affect a network install of KDE
16:11:22 <adamw> and/or the compose of the KDE live image
16:11:38 <coremodule> hmmm...
16:11:44 <jlanda> -2 is fixed
16:14:10 <adamw> okay
16:14:21 <adamw> so, we probably don't need to worry *too* hard about it...
16:14:23 <bcotton> i mean if -2 fixes it, then i'm fine with calling it a blocker :-)
16:14:39 <adamw> .fire bcotton clear violation of Good Blocker Procedure
16:14:39 <zodbot> adamw fires bcotton clear violation of Good Blocker Procedure
16:15:25 <coremodule> look out everyone, adamw has a case of the Mondays!!
16:15:49 <coremodule> +1 blocker
16:16:10 <cmurf> well tomorrow is freeze yeah so it needs to be an FE at least to make sure it gets in
16:17:22 <bcotton> +1 blocker
16:17:29 <sumantro> +1 blocker
16:17:49 <pwhalen> +1 Blocker
16:17:53 <frantisekz> +1 B
16:18:06 <adamw> what criterion are you all using here?
16:18:21 <cmurf> yeah i was just gonna ask this
16:18:32 <coremodule> The installer must be able to use all available kickstart delivery methods.
16:18:33 <adamw> the one we have is "The installer must be able to complete a scripted installation which duplicates the default interactive installation as closely as possible"
16:18:36 <adamw> but this doesn't affect that
16:18:48 <coremodule> https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria#Kickstart_delivery
16:18:56 <adamw> (we've always struggled to decide exactly what kickstart requirements we should have, because kickstart can do *anything*)
16:19:13 <adamw> although the whole concept of 'the default interactive installation' is a bit...creaky, i suppose
16:19:18 <coremodule> this seems broad enough to cover it...
16:19:26 <jlanda> But, it's a ks with an error on a package that is part of a release blocker
16:19:35 <jlanda> This seems a good one to block
16:19:37 <adamw> yeah, but the criteria don't really cover that
16:19:44 <jlanda> sure
16:19:49 <adamw> jlanda: that is not how the system works, if we all relied on common sense it'd be a disaster ;)
16:19:58 <cmurf> I'm -1 blocker at the moment
16:20:04 <cmurf> But +1 FE
16:20:07 <adamw> iirc that criterion was kinda written when we didn't have editions and flavors and things
16:20:17 <adamw> and all non-live installers would've defaulted to a GNOME desktop install
16:20:24 <adamw> so implicitly that's what it sort of meant to cover
16:20:35 <coremodule> hmmmm
16:20:45 <adamw> the criterion could probably stand to be reconsidered for the Current Age (tm)
16:20:48 <jlanda> Didn't mention common sense, just ks error on a release blocking paclage ;)
16:20:49 <bcotton> i'm a little serious about "it's already fixed so whatever". whether we call it a blocker or an FE seems like a bit of wasted time we could use arguing about other BZs
16:20:51 <cmurf> This doesn't actually affect the KDE image we're creating correct?
16:20:59 <adamw> bcotton: yes, i agree
16:21:01 <coremodule> what bcotton said...
16:21:10 <frantisekz> okay, I am fine with +1FE too, bcotton++
16:21:24 <adamw> so my personal opinion is either punt or reject on the basis the criteria don't really cover this
16:21:29 <adamw> it will go away anyway since it's fixed
16:21:35 <adamw> and we can reconsider the criterion on list
16:21:46 <pwhalen> wfm
16:21:48 <lruzicka> I would like to know whether it is only connected to that two repositories that are mentioned in the bug.
16:21:52 <sumantro> wfm too
16:22:11 <bcotton> okay, i'll modify to -1 blocker, +1 FE
16:22:19 <bcotton> based on what adam said
16:22:25 <coremodule> sounds good, -1 blocker, +1 fe
16:22:26 <lruzicka> I have tried to install netinst using a special repo to add the new version of breeze and the installation worked ok
16:22:55 <lruzicka> the system even boots
16:23:21 <adamw> okay
16:23:35 <adamw> lruzicka: well...the new version of breeze *fixes* it
16:23:37 <adamw> so that would be expected?
16:24:13 <lruzicka> yeah, I am saying to confirm
16:24:16 <adamw> the two repos mentioned in the bug report are (respectively) "the frozen Beta content" and "current F30 stable"
16:24:35 <adamw> the bug will go away with the second URL after this update is pushed stable and a new compose is run
16:24:35 <adamw> anyway
16:25:05 <lruzicka> +1 FE so that it can land there even post freeze
16:25:43 <adamw> proposed #agreed 1699280 - RejectedBlocker AcceptedFreezeException (Beta) - rejected as the current criteria do not really cover this, the existing requirement in historical context covered the pre-Fedora.next default install which was GNOME. We believe the criterion could be revisited, but as this bug is fixed anyway, we will handle that separately
16:25:44 <jlanda> The saturday compose built kde iso, and that's after bug filling but before fix :S
16:25:58 <frantisekz> ack
16:25:59 <bcotton> ack
16:25:59 <adamw> jlanda: but we already knew that
16:26:00 <jlanda> ack
16:26:01 <lruzicka> ack
16:26:08 <adamw> jlanda: the image is release blocking, so the compose would die if this bug affected it
16:26:19 <pwhalen> ack
16:26:20 <adamw> #agreed 1699280 - RejectedBlocker AcceptedFreezeException (Beta) - rejected as the current criteria do not really cover this, the existing requirement in historical context covered the pre-Fedora.next default install which was GNOME. We believe the criterion could be revisited, but as this bug is fixed anyway, we will handle that separately
16:26:34 <jlanda> true
16:26:47 <adamw> #topic (1693409) gdm/X start fails on 'nomodeset' UEFI boot on multiple bare metal systems: "Cannot run in framebuffer mode. Please specify busIDs          for all framebuffer devices"
16:26:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1693409
16:26:47 <adamw> #info Proposed Blocker, gdm, NEW
16:26:57 <adamw> so, nomodeset time!
16:27:03 <adamw> last meeting, we punted on this to get more info
16:27:18 <adamw> we did get quite a lot of feedback in the bug and on lists, and it seems like just about everyone who's tried it ran into this
16:27:47 <adamw> i suppose one thing i should have done is asked people to try f28 and f29 too...
16:28:08 <frantisekz> so, just to reiterate, with gdm-3.32.0-2.fc30, I got nomodeset booting in UEFI just fine on [AMD/ATI] Turks PRO
16:28:20 <coremodule> frantisekz, is that the lastest one?
16:28:25 <adamw> frantisekz: is that reproducible? and did it fail with the previous gdm?
16:28:31 <lruzicka> and I did not on another AMD and on Intel XEON
16:28:34 <adamw> because frankly i would find that very odd
16:28:41 <frantisekz> no, the latest one is -3, it failed with previous gdm if i remember correctly
16:28:42 <jlanda> -3 just pushed, but for the slowdown thing
16:28:44 <adamw> the change in gdm 3.32.0-2 should not actually affect this bug at all
16:28:49 <frantisekz> but I can try if it fails with old
16:28:57 <frantisekz> and how is it with -3
16:28:58 <adamw> also try a few tmes
16:29:06 <adamw> nothing that is changing in gdm should affect this bug at all
16:29:10 <adamw> this is an error from the X session
16:29:17 <jlanda> The macbook thing concerns me, he can't boot neither on normal nor nomedeset
16:29:28 <jlanda> But dunno how common is, at looks pretry uncommon
16:29:39 <jlanda> s/at/and
16:30:03 <adamw> jlanda: which comment is that? i don't see it
16:30:20 <coremodule> jlanda, I can't boot at all on a MacBook either...
16:30:31 <jlanda> M, i think it was a mail from coremodule
16:30:36 <coremodule> I thought it was just the age of this ancient mac, but it appears not.
16:30:39 <jlanda> There :D
16:30:44 <coremodule> oh gotcha, it *was* me... :D
16:30:46 <adamw> so both coremodule *and* coremodule can't boot on a mac?! this is awful
16:30:50 <adamw> there is clearly only one possible solution
16:30:54 <coremodule> you should fire one of them
16:30:58 <adamw> .firecoremodule and his little macbook too
16:31:00 <cmurf> which mac model?
16:31:04 <coremodule> SON OF A
16:31:05 <adamw> .fire coremodule and his little macbook too
16:31:05 <zodbot> adamw fires coremodule and his little macbook too
16:31:19 <cmurf> this is a dual GPU one? AMD and i915?
16:31:24 <jlanda> One witj an ati x1900 or similar
16:31:27 <coremodule> its one of the early macbooks, no its ancient
16:31:28 <jlanda> Pre gcn amd
16:31:30 <coremodule> let me see...
16:32:05 <coremodule> its got this graphics set
16:32:06 <coremodule> 02:00.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 03)
16:32:10 <cmurf> well i have a 2011 and that's at least two epochs ago so, what is ancient?
16:32:37 <coremodule> that is!
16:32:38 <coremodule> https://everymac.com/systems/apple/macbook/specs/macbook-core-2-duo-2.4-black-13-early-2008-penryn-specs.html
16:32:56 <cmurf> oh yeah that's three epochs ago
16:33:06 <coremodule> but is *is* efi so... :)
16:33:17 <cmurf> is it 64bit efi or 32bit efi
16:33:24 <coremodule> 64
16:33:29 <cmurf> it's right around that era where apple did that asshatery
16:33:47 <coremodule> yeah, i think the predecessor to it was where they switched
16:34:05 <cmurf> hmm i'm not sure, but if it has only intel graphics it really should work, it doesn't have that goofy gmux stuff
16:34:25 <coremodule> nothing, when I boot it it just hangs like all the other ones...
16:34:26 <frantisekz> adamw, just tried that, it's broken on gdm-3.32.0-1.fc30 and working fine on gdm-3.32.0-2.fc30 (tried about 4 times now)
16:34:33 <cmurf> is it a kernel regression? if it is then it's an upstream bug and they basically have to fix it
16:34:59 <frantisekz> it's weird, but from 3 desktops we have in the office, gdm-3.32.0-2.fc30 actually fixed it on one
16:35:15 <coremodule> rf 1.2
16:35:19 <coremodule> whoops
16:36:35 <adamw> frantisekz: that's just...really odd. i cannot think of a plausible explanation for that at all.
16:36:45 <adamw> unless...it's not actually doing the same thing any more. anyway. we can look into that later.
16:37:14 <adamw> i don't think it's reasonable to believe that 3.32.0-2.fc30 actually fixes this bug, though. especially since we have lots of systems where it doesn't, and i actually initially discovered the bug using a package that's effectively identical to that.
16:38:09 <lruzicka> adamw, that version does not fix anything else accept that computer ... I tried with two other machines and ... niete.
16:38:28 <lruzicka> s/accept/except
16:38:53 <adamw> yeah.
16:39:03 <adamw> so...i still kinda wish we had graphics team input here
16:39:15 <adamw> but i think i'm willing to give this a weak +1 at this point since it seems to affect almost every system we try it on
16:39:18 <frantisekz> 3.32.0-3.fc30 works just fine as 3.32.0-2.fc30 on that pc
16:39:21 <adamw> we can always reverse the decision later if we get more data
16:39:35 <jlanda> Yep :S
16:39:40 <frantisekz> yeah, +1 here
16:39:56 <jlanda> I continue on +1 too
16:39:58 <cmurf> I'm a +1 until the graphics folks draw an actual line in the sand ala: if it works without nomodeset, then nomodeset is allowed to not work
16:40:02 <coremodule> Im +1
16:40:04 <bcotton> +1
16:40:10 <pwhalen> +1
16:40:32 <lruzicka> gladly +1 blocker
16:40:38 <cmurf> cuz it seems like for almost everyone it does NOT work for, graphics works fine without nomodeset
16:41:47 <jlanda> For all except that macbook, throw it from the window coremodule :D
16:42:57 <frantisekz> adamw, so apparently, that desktop was installed in bios mode, scratch all my comments
16:43:02 <adamw> proposed #agreed 1693409 - AcceptedBlocker (Final) - accepted as a violation of "The generic video driver option ('basic graphics mode' - as described in the Basic criteria) on all release-blocking installer and live images must function as intended (launching the installer or desktop and attempting to use a generic driver)...", as current feedback indicates this affects almost all tested systems
16:43:11 <adamw> frantisekz: whew, okay, that makes much more sense.
16:43:24 <adamw> my confidence in my understanding of how software works is very slightly restored :P
16:43:32 <jlanda> ack
16:43:34 <coremodule> ack
16:43:38 <frantisekz> :D sorry for undermining it for a while...
16:43:39 <frantisekz> ack
16:43:53 <pwhalen> ack
16:43:58 <adamw> #agreed 1693409 - AcceptedBlocker (Final) - accepted as a violation of "The generic video driver option ('basic graphics mode' - as described in the Basic criteria) on all release-blocking installer and live images must function as intended (launching the installer or desktop and attempting to use a generic driver)...", as current feedback indicates this affects almost all tested systems
16:44:07 <adamw> #topic (1699099) gnome-initial-setup 3.32.0+ crashes due to SELinux denials
16:44:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1699099
16:44:08 <adamw> #info Proposed Blocker, gnome-initial-setup, ASSIGNED
16:44:39 <adamw> so, me and the g-i-s team and selinux team are all having fun trying to get on the same page about precisely what broke what when and whose fault it is atm
16:44:53 <adamw> but it is fairly clear that this bug is really happening and is in current F30 stable, which is all we need to know for it to be a blocker
16:45:14 <pwhalen> +1
16:45:16 <adamw> ok, 'boot in permissive mode' is a workaround, but we can't realistically tell everyone who installs F30 workstation to do that :P
16:45:20 <bcotton> +1 blocker
16:45:23 <frantisekz> +1
16:45:30 <coremodule> +1 blocker
16:45:37 <sumantro> +1 blocker
16:45:43 <bcotton> adamw: plus, dan walsh will run out of tissues
16:45:57 <jlanda> +1b
16:46:19 <lruzicka> +1 blocker
16:46:57 <jlanda> boot permissive mode is a workaround for a lot of bugs, we could entirely get rid of the "selinux denials notifications" criteria :D
16:48:06 <adamw> true =)
16:48:26 <mclasen> adamw: there is no g-i-s team
16:49:08 <adamw> proposed #agreed 1699099 - AcceptedBlocker (Final) - clear 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" for all Workstation installs
16:49:13 <frantisekz> ack
16:49:14 <jlanda> ack
16:49:16 <adamw> mclasen: sorry, i meant desktop team
16:49:28 <lruzicka> ack
16:49:31 <bcotton> ack
16:49:36 <pwhalen> ack
16:50:11 <adamw> #agreed 1699099 - AcceptedBlocker (Final) - clear 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" for all Workstation installs
16:50:12 <lruzicka> ack
16:50:44 <sumantro> ack
16:51:23 <adamw> .fire lruzicka you can't ack a proposal and then ack the agreement!
16:51:23 <zodbot> adamw fires lruzicka you can't ack a proposal and then ack the agreement!
16:51:34 <adamw> #topic (1698550) Fedora install media error out with SecureBoot or Grub error in UEFI-only mode on T450s
16:51:34 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1698550
16:51:35 <adamw> #info Proposed Blocker, shim, NEW
16:52:36 <lruzicka> adamw, thanks, I did not plan it, but I somehow killed my client
16:55:05 <bcotton> +1 blocker. Release-blocking images must boot from all system firmware types that are commonly found on the primary architectures. For the x86_64 architecture, UEFI with Secure Boot configured in accordance with Microsoft's Windows certification requirements is considered a 'commonly found' firmware type.
16:55:05 <coremodule> kparal, did you find this bug testing for the last bug?
16:55:08 <adamw> so we know of only one affected system so far, right?
16:55:11 <adamw> but this is a bad bug...
16:55:38 <adamw> kparal: this broke in f29, right?
16:55:38 <frantisekz> I didn't see this one anywhere else
16:55:40 <jlanda> coremodule: he at least found it now and not two weeks later
16:55:53 <frantisekz> kparal is not around :/
16:56:11 <lruzicka> could ping him if he is available
16:56:34 <tablepc> .hello
16:56:34 <zodbot> tablepc: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:56:37 <jlanda> He said on the mail that f29 was broken and 28 partially broken
16:58:45 * kparal is here
16:58:59 <adamw> did we test this on other thinkpads around the office?
16:59:29 <kparal> I did test with T480s, works
16:59:35 <kparal> also frantisekz tested with his...
16:59:41 <kparal> T470s?
16:59:43 <kparal> also worked
16:59:49 <frantisekz> yeah, worked fine on T470s
17:00:24 <kparal> one good thing would be to convince Lenovo to push latest bios to LVFS for T450s
17:00:27 <adamw> other models from the same gen as t450s might be interesting i guess?
17:00:30 <kparal> of course we don't want to block on that
17:00:32 <adamw> rather than 'same model different gen'
17:00:53 <kparal> the new bios fixes SB, but it still doesn't fix CSM off
17:01:47 * jlanda is burning a 0413 usb to try on a different vendor
17:02:01 <cmurf> if SB is on, CSM must be off
17:02:14 <cmurf> so you mean if SB is off and CSM is off, it fails?
17:02:18 <cmurf> that's goofycakes
17:02:22 <kparal> but it's something that's also affected on our end, because F28 works ok (but I haven't tested the latest bios, just the one before)
17:02:53 <kparal> cmurf: correct, it currently fails with black screen with SB is off and CSM is off
17:03:07 <kparal> i.e. pure uefi boot without SB
17:04:05 <adamw> so, this seems a bit tough
17:04:07 <cmurf> that's hilarious
17:04:08 <adamw> on the one hand, bad bug
17:04:17 <cmurf> conditional blocker?
17:04:20 <adamw> on the other hand, same bug exists in our current release it seems, and we only know of one affected model
17:04:39 <cmurf> if it failed on SB, that's a security problem
17:04:47 <kparal> I don't think we should block on a single machine. I filed it because I wanted us to investigate whether it affects more hw
17:05:13 <cmurf> there's no downside to being "forced" to use SB as the work around for this bug
17:05:24 <jlanda> we should try this on different boxes, and tbh i totally forgot it at least :D
17:05:25 <adamw> does this affect both traditional install images and lives?
17:05:29 <kparal> adamw: yes
17:05:32 <adamw> so
17:05:41 <adamw> we did that call for testing for uefi basic graphics mode
17:05:46 <kparal> cmurf: yes, the current workaround is to install latest bios manually and then force SB on
17:05:56 <adamw> implicitly, everyone who replied to that and did *not* say "hey my system couldn't boot at all!" didn't run into this
17:06:05 <adamw> unless they had the latest firmware installed and SB enabled, right?
17:06:15 <kparal> adamw: no, because that call didn't imply CSM has to be off (or SB has to be on)
17:06:31 <adamw> oh...so native UEFI boot works *if CSM is enabled*?
17:06:36 <adamw> so you're not using it, but it's enabled?
17:06:36 <kparal> a very frequent default setting is uefi+legacy, or legacy+csm
17:06:45 <kparal> adamw: correct
17:06:51 <adamw> huh. like cmurf said...weird.
17:06:53 <cmurf> what's the default for this hardware?
17:07:03 <coremodule> thats a good point adamw
17:07:06 <cmurf> if you go into firmware settings and "load defaults" or whatever
17:07:07 <jlanda> I use to disable sb, I'll try now with sb on :D
17:07:13 <kparal> cmurf: no idea. I'm not sure whether a bios reset resets those fields. I can try
17:07:15 <cmurf> is it legacy(CSM) enabled?
17:07:23 <cmurf> it really doesn't matter... just curious
17:07:40 <adamw> so...i'm either -1 or punt on this
17:07:55 <cmurf> if legacy is the default then yes telling people to both upgrade firmware and use UEFI+SB is a bit of a narrow corridor for a work around
17:08:26 <adamw> even if we haven't explicitly tested a lot of systems specifically for this bug, the fact that we didn't get more people yelling about it in general testing or the UEFI nomodeset call for testing suggests to me that it's not a big problem
17:08:33 <cmurf> for some people it won't be possible if they have Windows installed, since we don't support dual boot with BIOS based Windows, and UEFI based Fedora (nor should we)
17:08:42 <kparal> I think it's a good idea to send an email to test list to ask people to verify with SB on or SB off/CSM off/UEFI only
17:08:58 <kparal> if this affects just this machine, it's common bugs but not a blocker, I believe
17:08:59 <adamw> even if the bug *does* affect more hardware but people aren't hitting it because of their firmware configurations...that still means, hey, most people don't have the FW configuration that triggers the bug
17:09:03 <cmurf> kparal good idea
17:09:10 <adamw> which means it's less of a problem
17:09:21 <adamw> if the config that hits the bug isn't default and most people don't pick it...it's not really a big deal
17:09:37 <kparal> the most curious thing is that it affects only install media but my installed system works fine
17:09:44 <kparal> in any configuration
17:09:47 <adamw> well, the install media are a bit magic
17:10:08 <cmurf> adamw: exactly
17:10:09 <adamw> the whole hybrid setup to make them bootable on bios and uefi and mac
17:10:13 <adamw> installed systems aren't like that
17:10:15 <cmurf> they might be triggering "bugs" in the firmware
17:10:19 <adamw> right
17:10:48 <jforbes> We should just drop support for bios...
17:10:48 <adamw> if you have tons of spare time you could hack up an installer iso with the 'isohybrid' call skipped and see if that works :P
17:10:49 * jlanda can't reproduce it, my laptop boots with sb on on 0413 compose
17:10:50 <coremodule> -1 blocker based off the (currently known) scope of this, but we should make an action item to send out an email like kparal talked about
17:10:56 <frantisekz> -1B, +1CB
17:11:00 <cmurf> an interesting test would be cleanly partitioned sticks, e.g. using l-i-t-d
17:11:27 <adamw> yeah, messing with different livecd-iso-to-disk options would be interesting too i guess
17:11:32 <kparal> cmurf: well I used media writer, i.e. dd approach
17:11:44 <cmurf> right so that preserves the isohybrid stuff
17:11:44 <jlanda> I used media writer too
17:12:14 <cmurf> our images are frankensteined, it's amazing work really but not standard at all
17:12:28 <kparal> I can try litd but it was too fragile for me every time, mostly didn't boot
17:12:29 <cmurf> it's gpt, mbr, *apple partition map* and ISO 9660 all in one
17:12:45 <jlanda> -1b +1cb +1 further investigation to see if hits more hardware or just kparal's one
17:13:49 <adamw> how about FE?
17:13:49 <cmurf> kparal ping me on fedora-qa when you want to test with litd there's some unintuitive combination of flags to use
17:13:52 <adamw> i'm probably +1 FE
17:13:57 <adamw> if we can identify a specific bug and a safe fix here
17:14:08 <cmurf> and it might be that we have to manually zero out the first 440 bytes of the stick to make sure it contains no code
17:14:13 <frantisekz> +1FE, depending on how is fix going to look like
17:14:35 <cmurf> UEFI is supposed to ignore those 440 bytes, however
17:14:39 <lruzicka> +1FE, if there is a useful fix
17:14:52 <cmurf> +1 punt
17:15:06 <cmurf> i wanna see what pjones or mjg59 have to say about it
17:15:44 <jlanda> Yeah, it worth it an exception, but... should we see the fix first? We don't want a mess trying to fix it :D
17:16:14 <adamw> jlanda: we vote on whether the bug is worth a *possible* freeze exception effectively
17:16:19 <adamw> we can't always see what it would be before voting
17:16:22 <cmurf> i trust those guys but it really comes down to bandwidth between their fixes landing and how much time we have to test
17:16:31 <adamw> getting an FE doesn't mean a fix would definitely be pulled in
17:16:34 <cmurf> but adamw can just say NOPE
17:16:41 <cmurf> right
17:16:42 <jlanda> adamw: yeah, but we concern about those fixes too :D
17:16:45 <adamw> once a potential fix appears releng and qa together make a judgement call on whether to pull it in
17:16:52 <cmurf> adamw can just say, that breaks shit, yank it out
17:17:28 <cmurf> changing from punt to +1 FE
17:17:46 <adamw> proposed #agreed 1698550 - RejectedBlocker (Final) AcceptedFreezeException (Final) - for now this appears to be too specific to justify accepting as a blocker, we only know that it affects one laptop model with one specific non-default firmware configuration. However, for affected users it's a critical bug, so we would consider a safe fix for post-freeze inclusion. This decision may be changed based on further investigation
17:18:04 <jlanda> ack
17:18:07 <bcotton> ack
17:18:17 <coremodule> ack
17:18:29 <frantisekz> ack
17:18:33 <kparal> not sure if it's non-default
17:18:37 <kparal> but ack
17:19:06 <adamw> i don't think i can make the agreement any longer :P
17:19:12 <lruzicka> ack
17:19:14 <kparal> :)
17:19:19 <adamw> i would be surprised if 'pure UEFI only without SB' were the default though. that seems an odd default
17:19:25 <adamw> #agreed 1698550 - RejectedBlocker (Final) AcceptedFreezeException (Final) - for now this appears to be too specific to justify accepting as a blocker, we only know that it affects one laptop model with one specific non-default firmware configuration. However, for affected users it's a critical bug, so we would consider a safe fix for post-freeze inclusion. This decision may be changed based on further investigation
17:19:33 <kparal> right
17:19:39 * kparal off
17:21:07 <cmurf> agreed, i expect it's either UEFI+SB enabled, or legacy (CSM) enabled
17:21:49 <cmurf> but I don't know the era of this hardware, quite a lot of Windows Vista and Windows 7 hardware were UEFI with CSM enabled out of the box and were BIOS Windows installed
17:22:48 <jlanda> firmware defaults are... well, firmware things are a lot unsense for external viewers too many times :D
17:23:10 <frantisekz> cmurf, T450s is 2015 hardware, but I had CSM enabled by default on my T470s (2017 hardware)
17:23:20 <adamw> #topic (1697591) modesetting driver on some Intel hardware fails to start after kernel 4.20.13 update
17:23:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1697591
17:23:20 <adamw> #info Proposed Blocker, xorg-x11-server, ASSIGNED
17:23:26 <jlanda> I wanna thing they have sense for firmware people :D
17:24:23 <jforbes> ajax actually posted some patches for this upstream a while ago, but they seem to have not gone anywhere
17:27:05 <adamw> as in, upstream doesn't want them, or just didn't look at them?
17:28:04 <jforbes> I am guessing just didn't look at them
17:28:30 <adamw> i guess we can ask ajax to poke it again
17:28:56 <jforbes> https://gitlab.freedesktop.org/xorg/xserver/merge_requests/36
17:30:41 <coremodule> punt for upstream to do what they gotta do?
17:31:28 <jforbes> They aren't doing anything
17:31:58 <jforbes> And kernel team has no intention of maintaining a revert for an additional 6 months for F30 users
17:31:59 <cmurf> they need to be lightly harassed
17:32:15 <coremodule> "lightly harassed"
17:32:17 <coremodule> lol
17:32:18 <adamw> we can't punt to upstream, really
17:33:17 <adamw> i'm kinda inclined to accept this, as multiple folks seem to be running into it
17:33:31 <adamw> and we've known about it all along and specifically worked around it in f29
17:33:43 <adamw> i understand kernel team's position to not keep carrying the kernel workaround
17:34:25 <cmurf> if it's a kernel regression that affects user space, then it's an upstream problem to revert
17:34:31 <jforbes> Plus there are additional patches upstream which may solve the issue
17:34:42 <jlanda> this is the dell edp thing that we talked on test@ or is a different bug? I'm a bit confussed with so many graphic related bugs on this cycle :D
17:34:46 <cmurf> they need to fix it or revert it, and not expect Fedora kernel folks to do that for them
17:35:14 <jforbes> cmurf: The problem existed before a kernel update. The update is not a regression, it just exposed more users to the existing bug in userspace
17:35:36 <cmurf> ohgod that's worse
17:35:39 <jforbes> And upstream kernel has been very clear on the fact that they will not revert the patch
17:36:14 <jlanda> so, know upstream will have to look on the fact that have ignored for the last 6 months
17:36:43 <jlanda> since more people are hitting them, but who knows :S
17:37:00 <cmurf> ok so this is a userspace bug that needs to be fixed, not a kernel thing at all?
17:37:06 <jforbes> So we are carrying a revert in F28/29, but the longer we carry it, the worse it will be to maintain. Adding F30 to that list is another 6 months
17:37:12 <jforbes> cmurf: correct
17:37:42 <jforbes> jlanda: This originally hit in 4.20, upstream has been ignoring it anyway
17:37:51 <cmurf> ok so back to "lightly harassing" the proper upstream which is whatever the userspace thing is that needs fixing
17:37:54 <jlanda> correct :S
17:38:24 <jforbes> jlanda: I mean the bug is older than 4.20, but the exposing more people to it happened in 4.20
17:38:28 <cmurf> and look if that upstream doesn't care about these users then they just need to be clear about that
17:38:55 <jlanda> jforbes: yeah, i got it, so they ignored the exposition for 4 months too
17:38:57 <jforbes> I would really like to see ajax feedback since he actually wrote a patch series to address it
17:39:07 <jlanda> so is worst than I tought :S
17:39:29 * cmurf +1 to lightly harassing ajax about status of his patch series
17:40:07 <cmurf> anyway I'm -1 to blocking on this
17:40:11 <cmurf> +1 FE
17:40:24 <adamw> cmurf: on what basis? not enough people affected, or hwat?
17:40:24 <cmurf> and +1 to moving on :D
17:40:53 <cmurf> adamw not enough upstream support and it's not Fedora kernel devs team responsibility to clean up all the messes by carrying reverts this long
17:40:56 <jlanda> i just read some dell xyz users affected, do we have more info about?
17:41:58 <cmurf> if there aren't resources enough for a proper userspace fix, then that's basically it, we can't indefinitely block Fedora on it
17:42:44 <jlanda> well, there are some already written patches, dunno how many work would be to rebase and maintain to current source (they're 6 month old)
17:43:14 <jforbes> The userspace patches were written by a fedora contributor even
17:43:36 <adamw> cmurf: accepting it as a blocker isn't saying hte kernel team has to keep maintaining the revert
17:43:39 <adamw> it is saying the bug has to be fixed
17:44:02 <jlanda> we could downstream patch userspace instead of reverting on kernelspace, we need ajax's input :D
17:44:29 <cmurf> adamw: I understand, but we don't have a word from ajax if blocking on this means it's actually going to get fixed anytime soon
17:44:44 <cmurf> no point in blocking if it can't be fixed in a sane timeframe
17:45:56 <cmurf> adamw: do we have enough votes for a blocker? if so use that as leverage to at least get a response on how likely/unlikely a fix is before go-nogo or if it for sure means slip or whatever
17:46:34 <adamw> we haven't had many votes yet
17:46:46 <cmurf> ok where are you?
17:46:54 <adamw> i guess we could punt for input from ajax on whether he thinks this can be fixed either upstream or downstream on X server side in f30 timeframe
17:47:01 <adamw> i'm a weak +1
17:47:16 <frantisekz> +1 punt for ajax sounds good
17:47:18 <pwhalen> +1 punt
17:47:31 <jlanda> I'm more on punting, i would like to know how many people is affected by this, i just read some people with almost the same hardware all the time, same vendor, same epoch...
17:47:45 <cmurf> well punt comes with "lightly harassing" ajax :D
17:47:52 <lruzicka> +1 punt and see
17:47:59 <cmurf> otherwise it's just punting indefinitely which is not compatible with kernel dev team's concerns
17:48:05 <jforbes> There are a large number impacted by this
17:48:57 <jlanda> well, then i'm on +1b then, many people that can't get an output on their laptop screen...
17:49:05 <jlanda> it sounds bad
17:49:21 <jlanda> we can't workaround with "move your 37" screen with you"
17:49:33 <pwhalen> I am inclined to be +1 blocker as well
17:50:05 * cmurf is changing from -1 blocker to +0.5 blocker
17:50:17 <cmurf> adamw rounds up to the nearest integer anyway
17:50:29 <adamw> i have a highly advanced, adaptive AI-based vote counting system
17:50:36 <adamw> it is far too complicated to explain
17:50:40 <cmurf> i think it's better than that
17:51:02 <bcotton> +1 blocker, but we'll have to think about that this means if we can't get a fix in the next few weeks
17:51:03 <lruzicka> if we decide a blocker, which I could accept, we need to really block on that
17:51:22 <lruzicka> as bcotton is saying ...
17:51:34 <cmurf> if it means one or two slips for at least a significant minority of users, fine
17:51:49 <lruzicka> and I think there will be attempts to unblock the closer we are to release
17:52:49 <adamw> yeah, this is definitely a candidate for the 'last blocker' test
17:52:49 <coremodule> I'm +1 punt for info
17:53:03 <cmurf> s/for at least/on behalf of fixing it for
17:53:06 <adamw> i'm gonna propose we punt one week and specifically ask ajax to comment, and we commit to making a call one way or the other next week
17:53:11 <coremodule> I could be +1 blocker if we think that'll light the fire we need though to get it fixed before release...
17:53:14 <jlanda> there is a potential fix already written on PRdto upstream, would be able to patch downstream with it?
17:53:24 <bcotton> adamw: i can live with that
17:53:43 <adamw> jlanda: that's one thing i will ask ajax, yes
17:53:54 <adamw> coremodule: i don't like using the process that way
17:54:07 <jlanda> then +1 to your punt, thats the info we need to know
17:54:23 <coremodule> but if that whats it takes...
17:54:58 <coremodule> my take is that we seem pretty certain that the upstream guys aren't going to go for it unless really pushed
17:55:02 <adamw> proposed #agreed 1697591 - punt (delay decision) - we are very concerned about this bug and quite inclined to accept it, but we would like ajax's input on how wide the scope is and how practical it would be to fix before we make a final decision
17:55:09 <bcotton> ack
17:55:12 <coremodule> which, I can respect punting to try to talk it out
17:55:14 <coremodule> ack
17:55:18 <lruzicka> ack (and see next week)
17:55:19 <adamw> coremodule: upstreams don't historically care a lot about whether a bug blocks a downstream distro's release
17:55:19 <pwhalen> ack
17:55:21 <jlanda> ack
17:55:30 <adamw> so calling this a blocker wouldn't pressure *them* much
17:55:36 <adamw> it puts much more pressure on our downstream devs/packagers
17:55:49 <coremodule> adamw, right, but having it blocking is a potential for more leverage, should someone have a heart for helping or Fedora
17:56:08 <coremodule> yeah, that makes sense
17:56:27 <frantisekz> ack
17:56:30 <coremodule> i understand our position, just saying I could see it both ways
17:56:59 <cmurf> adamw: although if upstream says they're just going to abandon a bunch of users, it's going to affect all their downstreams
17:57:02 <cmurf> Fedora is just the canary
17:57:41 <jlanda> ack
17:57:57 <adamw> #agreed 1697591 - punt (delay decision) - we are very concerned about this bug and quite inclined to accept it, but we would like ajax's input on how wide the scope is and how practical it would be to fix before we make a final decision
17:58:16 <lruzicka> I wonder if we can do anything about that for Fedora users, if upstream does not want to fix it.
17:58:26 <adamw> lruzicka: sure we can, we can just patch it downstream
17:58:30 <jforbes> all questions for ajax
17:58:42 <adamw> it's just that we try to avoid that where we can, as it tends to become a progressively growing maintenance burden
17:58:43 <jforbes> I don't see upstream unwilling to fix this though
17:58:51 <adamw> life is much simpler if you stay close to upstream
17:59:01 <adamw> yeah, it may just be a case of poking people hard enough to care
17:59:11 <lruzicka> adamw, yeah, I understand that
17:59:11 <adamw> #topic Proposed freeze exceptions
17:59:19 <adamw> as freeze will happen very shortly, we need to review this!
17:59:24 <adamw> #topic (1698529) crash early in initialize_network()
17:59:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1698529
17:59:24 <adamw> #info Proposed Freeze Exceptions, anaconda, ASSIGNED
18:01:32 <pwhalen> +1 FE, I hit this on some arm hardware
18:01:56 <adamw> "The crash makes Fedora 30 for s390x uninstallable and because we are alternative arch, proposing as FreezeException."
18:01:59 <adamw> seems fairly clear
18:02:06 <adamw> anaconda crashing is bad!
18:02:07 <adamw> +1
18:02:14 <coremodule> +1FE
18:02:27 <cmurf> +1 FE
18:02:29 <lruzicka> +1 FE
18:02:46 <bcotton> +1 FE
18:02:56 <jlanda> +1
18:05:20 <adamw> proposed #agreed 1698529 - AcceptedFreezeException (Final) - this causes install to fail on s390, clearly cannot be fixed with an update
18:05:30 <cmurf> ack
18:05:33 <lruzicka> ack
18:06:04 <pwhalen> ack
18:06:33 <adamw> #agreed 1698529 - AcceptedFreezeException (Final) - this causes install to fail on s390, clearly cannot be fixed with an update
18:06:38 <coremodule> gotta take a break, be back in 15 if you're all still here
18:06:47 <adamw> #topic (1699280) Fedora 30 beta install fails with Error in <unknown> scriptlet in rpm package breeze-icon-theme
18:06:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1699280
18:06:47 <adamw> #info Proposed Freeze Exceptions, breeze-icon-theme, MODIFIED
18:06:54 <adamw> we already accepted thi
18:06:54 <adamw> s
18:06:57 <adamw> #info we already accepted this
18:07:01 <adamw> #topic (1677379) Changes/MongoDB Removal
18:07:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1677379
18:07:02 <adamw> #info Proposed Freeze Exceptions, Changes Tracking, MODIFIED
18:08:27 <jlanda> coremodule: don't forget the secretarialice thing :D
18:08:49 <adamw> it seems mongodb is not blocked in koji
18:09:00 <adamw> anyway, we can figure out the details later
18:09:04 <adamw> i certainly agree with an FE
18:09:13 <jlanda> +1 fe
18:09:17 <bcotton> +1 FE
18:09:20 <lruzicka> +1fe
18:09:22 <adamw> note that even if no package update is actually needed, infra follows a freeze policy too
18:09:30 <pwhalen> +1 FE
18:09:34 * nirik wonders if he should just go do it.
18:09:39 <frantisekz> +1FE
18:09:42 <adamw> so we sometimes grant FEs which signal to infra that a change can be made during the infra freeze
18:09:51 <adamw> (i should probably write this up in the sop...)(
18:10:14 <adamw> nirik: maybe check all other aspects of retirement process too? perhaps it wasn't done properly
18:10:34 <nirik> yeah, I see it's dead.packaged... will look
18:11:07 <adamw> proposed #agreed 1677379 - AcceptedFreezeException (Final) - accepted as the package not being properly retired causes problems for upgrades, and may mean a non-free package being kept in the final release package set which we would not want.
18:11:19 <adamw> nirik: yeah i saw it had dead.package but wasn't blocked, which is a red flag
18:11:20 <bcotton> ack
18:11:46 <cmurf> ack
18:11:54 <jlanda> ack
18:11:59 <lruzicka> ack
18:12:00 <adamw> #agreed 1677379 - AcceptedFreezeException (Final) - accepted as the package not being properly retired causes problems for upgrades, and may mean a non-free package being kept in the final release package set which we would not want.
18:12:11 <adamw> #topic (1699977) Package group Fedora Eclipse contains obsolete package eclipse-recommenders
18:12:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1699977
18:12:12 <adamw> #info Proposed Freeze Exceptions, comps, NEW
18:12:25 <adamw> this is a good example of where the infra freeze would be relevant - comps is under it
18:12:32 <frantisekz> +1 FE
18:12:35 <adamw> so technically any change to comps during freeze requires an FE bug
18:12:37 <adamw> so, +1
18:12:40 <bcotton> +1 FE
18:13:12 <adamw> fix is already merged...but anyway, let's accept it and move on.
18:13:14 <lruzicka> +1 fe
18:13:32 <pwhalen> +1 fe
18:13:40 <adamw> proposed #agreed 1699977 - AcceptedFreezeException (Final) - this package remaining in the group causes issues on upgrade for systems with the group installed, would be good to fix that during freeze
18:13:43 <bcotton> ack
18:13:46 <frantisekz> ack
18:13:47 <jlanda> ack
18:13:56 <lruzicka> ack
18:14:41 <pwhalen> ack
18:16:43 <adamw> #agreed 1699977 - AcceptedFreezeException (Final) - this package remaining in the group causes issues on upgrade for systems with the group installed, would be good to fix that during freeze
18:16:50 <adamw> #topic (1698504) No seamless upgrade to fc30 because of eclipse
18:16:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1698504
18:16:50 <adamw> #info Proposed Freeze Exceptions, eclipse, ON_QA
18:16:59 <adamw> another similar case, upgrade bug
18:17:05 <bcotton> +1 FE
18:17:11 <adamw> +1 for this
18:17:24 <jlanda> +1 fe
18:17:30 <lruzicka> +1fe
18:17:31 <pwhalen> +1 FE
18:17:52 <cmurf> +1 FE
18:18:20 <adamw> proposed #agreed 1698504 - AcceptedFreezeException (Final) - this is another typical 'packaging issue affects upgrade' bug, we always like to fix these during freeze so upgrades work
18:18:25 <frantisekz> ack
18:18:29 <bcotton> ack
18:18:37 <lruzicka> ack
18:18:41 <jlanda> ack
18:18:49 <pwhalen> ack
18:19:18 <adamw> #agreed 1698504 - AcceptedFreezeException (Final) - this is another typical 'packaging issue affects upgrade' bug, we always like to fix these during freeze so upgrades work
18:19:27 <adamw> #topic (1699852) No seamless upgrade to fc30 because of httpcomponents-client
18:19:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1699852
18:19:27 <adamw> #info Proposed Freeze Exceptions, httpcomponents-client, NEW
18:19:30 <adamw> oh hey and another one!
18:19:36 <bcotton> +1 FE
18:19:40 <cmurf> +1 FE
18:19:43 <jlanda> Another +1
18:19:44 <adamw> hmm
18:19:48 <adamw> isn't this the same as the last one?
18:19:50 * adamw checks
18:19:51 <cmurf> haha
18:20:42 <jlanda> Are they all related to eclipse? Omg, let get all java stack out :D
18:20:57 <adamw> they're all eclipse, but it looks like there's two bugs
18:21:16 <adamw> i don't think the change marked as fixing 1698504 will fix this one
18:21:21 <adamw> so, let's keep them separate for now...
18:22:16 <jlanda> Btw, should be commonbugs upgrades with eclipse while we fix them?
18:22:48 <jlanda> It seems we have some bugs to fix before a proper upgrade with eclipse
18:23:11 <adamw> maybe, yeah
18:23:33 <jlanda> And is not a rare package, quite common
18:23:44 <adamw> proposed #agreed 1699852 - AcceptedFreezeException (Final) - this is another typical 'packaging issue affects upgrade' bug, we always like to fix these during freeze so upgrades work (also seems different from 1698504)
18:23:51 <jlanda> ack
18:23:53 <bcotton> ack
18:24:30 <lruzicka> ack
18:25:31 <adamw> #agreed 1699852 - AcceptedFreezeException (Final) - this is another typical 'packaging issue affects upgrade' bug, we always like to fix these during freeze so upgrades work (also seems different from 1698504)
18:25:46 <adamw> #topic Accepted blockers
18:25:54 <adamw> we probably don't need to go bug-by-bug this week, just let me give a summary
18:26:03 <cmurf> thanks adamw
18:26:14 <adamw> #info 1683197, 1691909 - halfline is aware of these and working through them
18:26:36 <adamw> #info 1690429 - desktop team is aware of this and doing its best, though it's not a straightforward fix and they have other things to work on too
18:26:56 <adamw> #info 1688462 - dnf team is working on this and the elements of the fix are landing at present
18:27:09 <adamw> that's all i got - anyone have further thoughts or notes on any of the accepted blockers?
18:28:13 <lruzicka> not so far
18:28:20 <jlanda> not on my side
18:29:54 <lruzicka> must go, guys ... see you later
18:30:06 <adamw> alrighty
18:30:11 <adamw> #topic Open floor
18:30:15 <adamw> any other f30-y, blocker-y business?
18:30:45 <tablepc> This is the first B FE meeting I've attended. Very educational.
18:30:46 <frantisekz> bye all, thanks adamw for leading this
18:31:35 <coremodule> thanks for hosting adamw, I'll have this secretarialized by 20:30UTC
18:32:29 <adamw> tablepc: glad you enjoyed it
18:32:32 <adamw> thanks coremodule
18:32:38 <jlanda> thanks everyone
18:34:22 <adamw> #endmeeting