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