16:01:19 <adamw> #startmeeting F37-blocker-review 16:01:19 <zodbot> Meeting started Mon Aug 29 16:01:19 2022 UTC. 16:01:19 <zodbot> This meeting is logged and archived in a public location. 16:01:19 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 16:01:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:19 <zodbot> The meeting name has been set to 'f37-blocker-review' 16:01:19 <adamw> #meetingname F37-blocker-review 16:01:19 <zodbot> The meeting name has been set to 'f37-blocker-review' 16:01:23 <adamw> #topic Roll Call 16:01:29 <bcotton> .hello2 16:01:29 <adamw> ahoyhoy folks, who's around for blocker review fun? 16:01:29 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com> 16:01:37 <bittin-> .hello2 16:01:38 <zodbot> bittin-: Sorry, but user 'bittin-' does not exist 16:01:41 <bittin-> .hello2 bittin 16:01:42 <zodbot> bittin-: Sorry, but user 'bittin-' does not exist 16:01:51 <bittin-> oh well i am here anyways 16:02:05 <coremodule> .hello2 16:02:06 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com> 16:02:43 <TheExorcist[m]> .hello naraiank 16:02:44 <zodbot> TheExorcist[m]: naraiank 'None' <knaraian@mail.com> 16:02:49 <jonathanspw> .hi 16:02:51 <zodbot> jonathanspw: jonathanspw 'Jonathan Wright' <jonathan@almalinux.org> 16:03:14 <Penguinpee> .hello gui1ty 16:03:14 <zodbot> Penguinpee: gui1ty 'None' <gui1ty@penguinpee.nl> 16:03:42 * SumantroMukherje is here 16:04:50 <bittin-> .hello bittin 16:04:51 <zodbot> bittin-: bittin 'Luna Jernberg' <droidbittin@gmail.com> 16:05:01 <adamw> hi everyone 16:06:00 <SumantroMukherje> hey adamw! 16:06:04 <adamw> #chair bcotton coremodule 16:06:04 <zodbot> Current chairs: adamw bcotton coremodule 16:06:16 <adamw> boilerplate alert 16:06:18 <adamw> #topic Introduction 16:06:23 <adamw> Why are we here? 16:06:24 <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:06:27 <adamw> #info We'll be following the process outlined at: 16:06:29 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:06:32 <adamw> #info The bugs up for review today are available at: 16:06:35 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current 16:06:38 <adamw> #info The criteria for release blocking bugs can be found at: 16:06:44 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:06:47 <adamw> #link https://fedoraproject.org/wiki/Fedora_37_Beta_Release_Criteria 16:06:50 <adamw> #link https://fedoraproject.org/wiki/Fedora_37_Final_Release_Criteria 16:07:01 <adamw> #info for Beta, we have: 16:07:10 <adamw> #info 2 Proposed Blockers 16:07:12 <adamw> #info 2 Accepted Blockers 16:07:15 <adamw> #info 2 Accepted Freeze Exceptions 16:07:25 <adamw> #info for Final, we have: 16:07:49 <adamw> #info 3 Proposed Blockers 16:07:50 <adamw> #info 9 Accepted Blockers 16:07:50 <adamw> #info 1 Proposed Freeze Exceptions 16:07:50 <adamw> who wants to secretarialize? 16:07:59 <coremodule> ill do it 16:09:48 <adamw> thanks 16:09:53 <adamw> #info coremodule will secretarialize 16:10:03 <adamw> let's start with: 16:10:07 <adamw> #topic Proposed Beta blockers 16:10:18 <adamw> #topic (1907030) "dnf update" runs out of memory on swapless machines with 1G or less of RAM 16:10:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1907030 16:10:25 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/841 16:10:28 <adamw> #info Proposed Blocker, distribution, ASSIGNED 16:10:31 <adamw> #info Ticket vote: BetaBlocker (+0,2,-3) (bcotton, kparal, -jmracek, -adamwill, -geraldosimiao) 16:10:33 <adamw> #info Ticket vote: FinalBlocker (+0,0,-1) (-jmracek) 16:10:50 <adamw> so, this was punted for more discussion and input 16:11:01 <adamw> but on reflection, to me, it makes no sense to take it as a 37 blocker, since it's affecting 36 16:11:17 <bittin-> there was some discussion on the mailinglist, but i have not had time to read it 16:11:20 <adamw> if we block 37 on it, we're not making anything better for anyone, since the alternative is 'use 36 instead' 16:11:27 <bittin-> on fedora-devel 16:11:59 <adamw> the mailing list discussion is interesting, but not super relevant to blocker discussion, i guess 16:12:05 <geraldosimiao> .hello geraldosimiao 16:12:05 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. SimiĆ£o Kutz' <geraldo.simiao.kutz@gmail.com> 16:12:13 <adamw> except that it rather looks like there's no trivial way to fix it and it'll sort of have to be part of DNF 5 16:12:21 <bittin-> i see have not had time to read it myself 16:12:29 <ab> .hello abbra 16:12:30 <zodbot> ab: abbra 'None' <abokovoy@redhat.com> 16:12:41 <bittin-> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CRREDQUPPJYWVRMA4DOKYU2KZZLKC4D5/ 16:13:14 <bittin-> well my vote is -1 blocker 16:13:49 <bcotton> yeah, i think if we accepted this as a blocker, we'd have to waive it under the "difficult to fix" exception through at least F38 Beta anyway 16:14:29 <adamw> hi ab, thanks for dropping by 16:14:40 <adamw> yeah, i'm -1 beta and -1 final, this doesn't feel like a good fit for blocker process 16:15:47 <adamw> cmurf: did make a good point in an email, though - if we aren't going to block on fixing the bug for f37, we should at least update the requirements doc to acknowledge this problem 16:15:55 <Penguinpee> Will there be any mention of the issue in the release notes for F37? 16:16:05 <adamw> and possibly include microdnf in installs likely to be used in low-ram environments 16:16:41 <Penguinpee> microdnf might help in some cases, but it uses libdnf under the hood. 16:16:45 <bittin-> adamw: +1 16:17:03 <adamw> Penguinpee: testing in the bug report indicates it does work for most folks affected by tis 16:17:39 <Penguinpee> adamw: it being microdnf? 16:19:20 <Penguinpee> +1 for shipping microdnf 16:19:40 <Penguinpee> Otherwise you may be caught between a rock and a hard place... 16:20:19 <adamw> Penguinpee: yeah, it being microdnf 16:20:55 <adamw> anybody else want to vote on this bug, as-is, being a beta blocker? 16:21:40 <Penguinpee> -1 BetaBlocker 16:21:59 <jonathanspw> -1 16:21:59 <geraldosimiao> I'll keep my vote. Already voted. 16:22:08 <Penguinpee> +0 FinalBlocker 16:22:37 <bittin-> got it to -7 and 2 non votes (if i counted correctly) 16:24:15 <adamw> proposed #agreed 1907030 - RejectedBlocker (Beta) - this is rejected on the grounds it already affects F36 so blocking F37 on it doesn't achieve much. We also note no simple fix has been identified; fixing this may require a significant overhaul of DNF (which is already in the works as DNF 5). we note that it may be desirable to require the system requirements doc to be updated and possibly to include microdnf in installs likely to be 16:24:15 <adamw> used on low-ram deployments 16:24:21 <bittin-> ack 16:24:26 <bcotton> ack 16:24:43 <TheExorcist[m]> +1 16:25:27 <geraldosimiao> Ack 16:25:32 <Penguinpee> ack 16:26:24 <adamw> #agreed 1907030 - RejectedBlocker (Beta) - this is rejected on the grounds it already affects F36 so blocking F37 on it doesn't achieve much. We also note no simple fix has been identified; fixing this may require a significant overhaul of DNF (which is already in the works as DNF 5). we note that it may be desirable to require the system requirements doc to be updated and possibly to include microdnf in installs likely to be used on 16:26:24 <adamw> low-ram deployments 16:26:28 <adamw> #topic (2115865) dnssec-keyfromlabel fails with openssl-pkcs11-0.4.12-1.fc36 16:26:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2115865 16:26:33 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/860 16:26:36 <adamw> #info Proposed Blocker, openssl-pkcs11, ASSIGNED 16:26:39 <adamw> #info Ticket vote: BetaBlocker (+3,0,-0) (+bcotton, +geraldosimiao, +nielsenb) 16:26:48 <adamw> so this has +3 but i left it on the agenda as i felt like we should explain things clearly here 16:27:22 <adamw> so, this is effectively a replacement for https://bugzilla.redhat.com/show_bug.cgi?id=2117859 , which was discussed last week. 16:28:05 <adamw> F37 is not actually affected by 2117859 currently. it's affected by this bug. the update that causes 2117859 was intended as a fix for this bug. For F37, we're holding that update out of stable because it causes 2117859. so instead of having that bug, F37 has this bug. 16:28:58 <adamw> this bug doesn't prevent deployment of FreeIPA with dnssec enabled, or upgrade of an existing dnssec-enabled server. but it does mean that freeipa's dnssec support doesn't really work very well 16:30:21 <ab> I think we figured out that it works with older openssl-pkcs11 and does not work with this update. We do not enable DNSSEC feature by default if we see it is broken but we aren't prepared for *this* level of brokeness. Basically, openssl-pkcs11 update does not allow to read a private key from the database and thus FreeIPA DNSSEC support simply cannot generate any signatures 16:31:33 <ab> so from Fedora point of view, if openssl-pkcs11 0.4.12 verrsion is not fixed, it would be best to revert it completely to the previous version 16:32:25 <ab> otherwise, it is a blocker to beta release because we try to default to DNSSEC working if user's environment supports it and it is what usually happens for almost all environments, including private ones 16:32:46 <bcotton> does it work well enough to satisfy the release criteria, though? 16:33:12 <bcotton> my vote is predicated on the understanding that the answer is "no, it does not" 16:33:23 <ab> bcotton: we use it by default in all upstream tests (~150 test suites, ~5000 tests) 16:33:32 <ab> bcotton: this is where we caught it on Rawhide 16:33:50 <bittin-> +1 Beta blocker 16:34:47 <adamw> sorry, had to run out for a minute 16:35:09 <ab> here is upstream tracker: https://pagure.io/freeipa/issue/9216 16:35:54 <ab> we found it with weekly tests ~4 weeks ago 16:36:02 <adamw> as the criteria are written, we don't really require dnssec stuff to work at all 16:36:04 <adamw> basic criterion is "It must be possible to configure a Fedora Server system installed according to the above criteria as a FreeIPA domain controller, using the official deployment tools provided in the distribution FreeIPA packages. Once deployed, the system must handle multiple client enrolments and unenrolments, and client authentication via Kerberos. The web UI must be available and allow at least basic configuration of user 16:36:04 <adamw> accounts and permissions." 16:36:37 <ab> default installation will enable DNSSEC validation of zones and will use DNSSEC for its own zone 16:36:37 <adamw> for Beta we say it must be able to "Serve DNS host records on port 53 (assuming it is deployed with DNS capability)" and "Serve DNS SRV records for ldap and kerberos on port 53 (assuming it is deployed with DNS capability)" 16:36:56 <jonathanspw> -1 Beta blocker 16:36:56 <ab> we had to disable DNSSEC in OpenQA due to issues in Red Hat datacenter that Fedora uses 16:37:16 <jonathanspw> +1 final blocker 16:37:25 <adamw> ab: aiui, in the state f37 is currently in, the result is kinda that dnssec just kinda isn't used for the server's own domain, but the actual freeipa function works? 16:37:26 <ab> so with openssl-pkcs11 0.4.12 it will be an immediate failure 16:37:59 <ab> adamw: as I said, we enable it by default if we see DNSSEC resolution works. 16:38:00 <adamw> ab: we actually only disable dnssec on upgrade tests because of that bug. it's still enabled in the non-upgrade tests 16:38:12 <bcotton> "we don't really require dnssec stuff to work at all" not explicitly, but if it uses DNSSEC by default, I'd argue that we implicitly require it 16:38:27 <adamw> ab: the description of the bug says "When the admin adds a new dnszone with dnssec enabled, the zone is not signed" 16:38:27 <bcotton> since we don't explicitly say that we don't require it 16:38:49 <ab> adamw: yes, that's an easiest way to reproduce it 16:39:18 <adamw> ab: so as far as openQA goes, on F37, we do test with dnssec enabled on the non-upgrade tests, and the tests currently pass. i.e. this bug is not breaking openQA's tests. openQA's tests do not explicitly exercise dnssec. 16:39:56 <adamw> openQA's tests start failing if we update to the -2 build. 16:40:15 <ab> ok, so I checked what happens: we have DNSSEC support enabled by default but not DNSSEC master enabled unless it is done explicitly 16:40:31 <ab> this is why the test adds a zone and adds explicit support for DNSSEC there 16:40:37 <ab> so I'd be OK with final blocker 16:40:46 <adamw> ok. openQA uses the defaults, yes. 16:40:58 <adamw> ok 16:41:09 <Penguinpee> +1 FinalBlocker 16:41:17 <ab> if Jakub is able to fix it for beta, that would be awesome 16:41:23 <adamw> i'd be +1 beta FE for this, but of course, with the expectation that we need to fix 2117859 as well 16:41:40 <Southern_Gentlem> +1B fe 16:41:58 <adamw> i don't think this violates even the final criteria, honestly. but we can probably punt that discussion. :D 16:42:12 <adamw> we can talk about whether we should add dnssec functionality to the criteria, i guess. but it's not there now. 16:42:25 <ab> it would be a first Fedora release with broken DNSSEC zone signing ;) 16:44:33 <adamw> proposed #agreed 2115865 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this is rejected on the grounds that dnssec functionality is not covered in the criteria, and the bug does not affect default functionality. It's accepted as a freeze exception because we do consider dnssec support important and would like this fixed if we can also fix 2117859 so things work correctly 16:44:54 <adamw> that leaves the decision on final blocker open (and hopefully we fix this early enough that we don't have to have it. :>) 16:47:03 <TheExorcist[m]> +1 16:47:10 <TheExorcist[m]> ack 16:47:23 <Penguinpee> ack 16:47:36 <ab> ack 16:48:07 <Southern_Gentlem> ack 16:48:21 <adamw> #agreed 2115865 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this is rejected on the grounds that dnssec functionality is not covered in the criteria, and the bug does not affect default functionality. It's accepted as a freeze exception because we do consider dnssec support important and would like this fixed if we can also fix 2117859 so things work correctly 16:48:32 <adamw> thanks a lot for the input, ab 16:48:44 <adamw> there are no proposed Beta FEs, so let's move on to: 16:48:47 <adamw> #topic proposed Final blockers 16:49:02 <adamw> #topic (2121106) Czech qwerty layout configured in anaconda, but qwertz layout used in disk unlock and in VT console 16:49:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2121106 16:49:09 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/867 16:49:11 <adamw> #info Proposed Blocker, anaconda, NEW 16:49:14 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+geraldosimiao) 16:49:40 <bittin-> +1 Final Blocker 16:50:02 <Southern_Gentlem> +1 FB 16:51:17 <adamw> looks pretty blocker-y, yeah 16:51:49 <adamw> +1 16:51:56 <bcotton> +1 final blocker 16:52:41 <Penguinpee> +1 FinalBlocker 16:53:37 <jonathanspw> +1 final blocker 16:53:44 <adamw> i would also give this a beta FE 16:53:49 <adamw> layout issues are a drag 16:53:55 <adamw> other votes? 16:54:21 <Southern_Gentlem> i thought fb gave it fe automaticly 16:54:29 <bcotton> +1 beta FE 16:54:38 <bittin-> +1 Beta FE 16:54:43 <Southern_Gentlem> +1 b FE 16:55:16 <adamw> Southern_Gentlem: nope 16:55:27 <jonathanspw> BetaFE +1 16:55:45 <TheExorcist[m]> +1 BFE 16:55:56 <adamw> proposed #agreed 2121106 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this is a clear violation of the Final criteria, and since it affects the install process so can't be fixed with aupdate and would be annoying for Czech users, we also grant it Beta FE status 16:56:00 <bittin-> ack 16:56:03 <Penguinpee> +1 Beta FE 16:56:07 <Penguinpee> ack 16:56:12 <TheExorcist[m]> ack 16:56:44 <bcotton> ack 16:56:50 <Southern_Gentlem> ack 16:56:50 <adamw> #agreed 2121106 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this is a clear violation of the Final criteria, and since it affects the install process so can't be fixed with aupdate and would be annoying for Czech users, we also grant it Beta FE status 16:56:57 <adamw> #topic (2121110) GNOME Initial Setup uses the English keyboard, instead of the default keyboard 16:57:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2121110 16:57:12 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/868 16:57:23 <bittin-> +1 Final Blocker 16:57:25 <adamw> #info Proposed Blocker, gnome-initial-setup, NEW 16:57:28 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+geraldosimiao) 16:57:33 <jonathanspw> FinalBlocker +1 16:57:48 <Southern_Gentlem> +1 FB +1b fe 16:57:50 <jonathanspw> BetaFE +1 16:57:53 <bittin-> +1 Beta FE 16:57:55 <adamw> this looks pretty in the same bucket, same votes for me 16:57:59 <adamw> +1 final blocker, +1 beta FE 16:58:21 <Penguinpee> +1 FinalBlocker, +1 Beta FE 16:58:28 <bcotton> +1 final blocker, +1 beta FE 16:59:55 <adamw> proposed #agreed 2121110 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this is a clear violation of the Final criteria, and since it affects the install process so can't be fixed with an update and would be annoying for non-US English users, we also grant it Beta FE status 16:59:57 <bcotton> ack 17:00:00 <bittin-> ack 17:00:11 <Penguinpee> ack 17:00:12 <jonathanspw> ack 17:02:25 <adamw> #agreed 2121110 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this is a clear violation of the Final criteria, and since it affects the install process so can't be fixed with an update and would be annoying for non-US English users, we also grant it Beta FE status 17:02:29 <bittin-> ack 17:02:30 <adamw> #topic (2121944) greenboot-grub2-set-counter.service fails on 38 IoT with "cannot open `/boot/grub2/grubenv.new`: No such file or directory." 17:02:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2121944 17:02:37 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/871 17:02:38 <adamw> #info Proposed Blocker, greenboot, NEW 17:02:41 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+geraldosimiao) 17:03:22 <bcotton> i'm a little confused about this. this reads like it's in Rawhide? 17:03:42 <adamw> it affects 37 too. 17:04:26 <adamw> sorry, should've made that clear. 17:05:43 <bcotton> okay, well in that case +1 final blocker on the cited criteria in the description 17:06:02 <bcotton> aiui, the issue in comment 1 might not actually be an issue once the greenboot issue is fixed? 17:06:36 <bittin-> +-0 17:06:59 <adamw> yeah, basically, i think greenboot failing is messing with the rebase test, it doesn't prove rebases are broken 17:07:03 <adamw> but greenboot failing is a clear final criteria violation, we have a criterion that says it has to work 17:07:26 <bittin-> +1 blocker if its in the criterion then 17:07:39 <Penguinpee> +1 FinalBlocker 17:08:51 <coremodule> +1 blocker as it stands 17:09:01 <TheExorcist[m]> +1 BFE 17:09:25 <adamw> proposed #agreed 2121944 - AcceptedBlocker (Final) - this is a clear violation of IoT criterion "The Greenboot service must be present on all images and installed by default when using the ISO installer. The service must be enabled to run on boot and function as intended" and the generic "all services must start successfully" criterion 17:09:32 <adamw> oh yes, good call 17:09:36 <bittin-> ack 17:09:43 <adamw> i'm also +1 Beta FE 17:09:43 <bcotton> +1 beta FE as well 17:09:48 <bittin-> +1 Beta FE 17:09:59 <coremodule> +1 Beta FE 17:10:00 <bcotton> and hopefully it doesn't show that rebases are actually broken :-) 17:10:12 <adamw> proposed #agreed 2121944 - AcceptedBlocker (Final), AcceptedFreezeException (Beta) - this is a clear violation of IoT criterion "The Greenboot service must be present on all images and installed by default when using the ISO installer. The service must be enabled to run on boot and function as intended" and the generic "all services must start successfully" criterion. also accepted as a Beta FE as it's a significant issue we would like 17:10:12 <adamw> to be fixed out of the box on Beta 17:10:17 <bittin-> ack 17:10:36 <adamw> Ben Cotton (he/him): yeah, i'm assuming we'll fix greenboot quite promptly, but if not i'll do a manual test that rebases do actually work 17:10:58 <bittin-> @ bcotton 17:11:12 <bcotton> ack 17:11:19 <TheExorcist[m]> ack 17:11:20 <Penguinpee> ack 17:11:34 <adamw> #agreed 2121944 - AcceptedBlocker (Final), AcceptedFreezeException (Beta) - this is a clear violation of IoT criterion "The Greenboot service must be present on all images and installed by default when using the ISO installer. The service must be enabled to run on boot and function as intended" and the generic "all services must start successfully" criterion. also accepted as a Beta FE as it's a significant issue we would like to be 17:11:34 <adamw> fixed out of the box on Beta 17:11:38 <bittin-> acj 17:11:40 <bittin-> aak 17:11:43 <bittin-> ack 17:11:59 <adamw> alrighty 17:12:01 <adamw> let's do a quick check-in on: 17:12:05 <adamw> #topic Accepted Beta blockers 17:12:34 <adamw> both of these are being addressed, i need to confirm the KDE fix and push the update stable, and check in with lnie on the status of 2103835 17:13:33 <adamw> aaand that's about all i had 17:13:48 <adamw> #info both accepted beta blockers are in the process of being addressed, adamw will follow up on them 17:13:48 <adamw> #topic Open floor 17:13:49 <adamw> any other business, folks? 17:13:58 * bittin- does not have anything right now 17:14:31 <bittin-> anyone else? 17:14:57 * TheExorcist[m] feeling like anything, but nothing..! 17:15:48 <Penguinpee> Penguinpee: shakes his head 17:16:13 * Penguinpee shakes his head 17:16:17 <bcotton> i'm concerned about how few blockers we have a mere week and a half before the first go/no-go meeting :-) 17:16:32 <adamw> Ben Cotton (he/him): we do need to cover the validation testing better 17:16:43 <adamw> sumantro is setting up a validation test week starting wednesday 17:16:44 <bittin-> thats the plan for later this week 17:16:49 <bittin-> :) 17:16:49 <adamw> and i will send an email out today to relevant lists asking folks to test 17:17:07 <bittin-> will try to test when i have time most likely during the end of this week 17:17:29 <adamw> alrighty 17:17:33 <adamw> thanks a lot, everyone 17:17:42 <adamw> see you next week 17:17:45 <adamw> #endmeeting