Monday, 2026-04-20

@mnasiadka:matrix.orgClark: not really, if the module sets no_log for these arguments and you don’t use shell/command - it’s fine04:20
@mnasiadka:matrix.orgI have stopped old mirror servers (to wait another 24 hours before removing them)06:51
- mirror02.dfw.rax.opendev.org (since we moved to mirror03 some time ago)
- mirror02.ord.rax.opendev.org
- mirror03.gra1.ovh.opendev.org
@mnasiadka:matrix.orgUh oh, review03.opendev.org is in SHUTOFF - it seems it has been stopped with req-8d3a5247-592f-4cb9-b28d-684361bb26b4 whatever that means (cc: mnaser )08:12
@mnasiadka:matrix.orginfra-root: I started review03.opendev.org and started gerrit using `docker compose up -d`08:22
@mnasiadka:matrix.orgHopefully that's fine, although I've seen [DiskCache-Store-0] WARN  com.google.gerrit.server.cache.h2.H2CacheImpl : Cannot put into cache jdbc:h2:file:///var/gerrit/cache/diff_summary-v2 and `org.h2.jdbc.JdbcBatchUpdateException: Timeout trying to lock table "DATA"`08:27
@noonedeadpunk:matrix.orgfolks, can you kindly dequeue the https://zuul.opendev.org/t/openstack/status?change=985276 ? As it looks like being stuck for some reason (maybe related somehow to gerrit issues?)11:37
@noonedeadpunk:matrix.orgAs I don't see any conflict tbh...11:37
@noonedeadpunk:matrix.orgOr you mean it conflicts with https://review.opendev.org/c/openstack/openstack-ansible-os_tempest/+/98531911:38
@noonedeadpunk:matrix.orghm11:38
@noonedeadpunk:matrix.orgok, forget this, they're indeed conflict between each other11:39
@clarkb:matrix.orgmnasiadka: I think starting the server then starting the service is the correct process there. Re the diff summary cache H2 v2 is apparently more sensitive to unexpected shutdowns than H2 v1 was and this is our first experience with what that looks like. I think we should check that the cache appears to be in use now (can check /home/gerrit2/review_site/cache timestamps maybe? Or maybe one of the cache info ssh commands will report info back). Mostly concerned we are not using that particular cache and any others that may not be lockable as a result of the shutdown13:59
@clarkb:matrix.orgI think if we find they are not in use then shutting down and deleting the caches and letting them rebuild after starting Gerrit again is the process we would use13:59
@clarkb:matrix.orgThen on the cloud side I want to say last time this happened it was due to memory oversubscription on the hypervisor and mnaser or someone else at vexxhost mitigated that14:00
@clarkb:matrix.orgI can take a closer look in about an hour or so14:02
@clarkb:matrix.orgLooking at timestamps for the caches the diff summary cache has updated as recently as a few minutes ago. Most of the caches have. There are a small number that haven't and I think that is beacuse we don't update them as often? Things like git tags, oauth tokens, groups, projects, and reverts15:01
@clarkb:matrix.organd looking at the error_log the db errors appear to have all clustered around the startup time. I notice that db pruning appears to have happened during that time period as well. I'm thinking that maybe the issue wasn't corrupted db files, but instead contention around db pruning during startup and operational tasks being unable to write during that time?15:01
@clarkb:matrix.orgI ran `gerrit show-caches` over the ssh port and it did not error and the output looks mostly as I expect. The one thing that maybe looks wrong is that the git_tags cache says it has 0.00k on disk15:05
@clarkb:matrix.orgmaybe that changes if someone pushes a git tag?15:05
@clarkb:matrix.orgBut overall this seems like it is working. I would say keep eyes open for any unexpected behavior particularly around tags. And if we need to we can shutdown Gerrit intentionally, clear out any h2 db backing files that we suspect are a problem then start it up again. Note if you delete web_sessions-v2.mv.db everyone will need to log back in again afterwards15:06
@fungicide:matrix.orgrackspace just sent us a notification that we have 5 trove databases running mysql 5.6 that will be upgraded automatically (disruptively) to 5.7 if we don't do so in the next two days15:10
@clarkb:matrix.orgstoryboard and zanata and wiki? I can't think of anything else that might still be there15:11
@fungicide:matrix.orgsome may be non-production15:11
@fungicide:matrix.orgcacti is one, apparently15:14
@clarkb:matrix.orgfungi: google says that the upgrade may impact queries using GROUP BY if they aren't constructed properly and tables using old TIMESTAMP or DATETIME columns will need to be repaired/rebuilt after the move15:14
@clarkb:matrix.orgI see at least one group_by in storyboard's code base15:15
@fungicide:matrix.orgfwiw, the wiki is using a local mysqld so i don't think either of the wiki trove instances they listed is in use15:16
@clarkb:matrix.orgoh cacti is the other15:17
@clarkb:matrix.orgso we probably need a list of things that will be affected and maybe we manually run mysqldumps if we aren't already doing so. And then hope for the best? I honestly don't feel like I'm in a position to try and correct any database issues with such an upgrade right now15:17
@fungicide:matrix.orgstoryboard and storyboard-dev are running local mysqld processes too, but not sure if they're using those15:18
@clarkb:matrix.orgtheir connection strings are theoretically in the app config? that is probably the easiest way to check?15:19
@fungicide:matrix.org/etc/storyboard/storyboard.conf has `connection=mysql+pymysql://REDACTED:REDACTED@localhost:3306/storyboard?charset=utf8mb4`15:20
@clarkb:matrix.orgok so should be using the local db. We should identify what each of the reported DBs is from the rax dashboard, then cross check with services. But it seems like maybe cacti and zanata are things to worry about?15:21
@fungicide:matrix.orgoh, while there is a local mysqld on the wiki server, /srv/mediawiki/Settings.php contains `$wgDBserver = "REDACTED.rackspaceclouddb.com";`15:22
@fungicide:matrix.orgso it probably will be affected15:22
@clarkb:matrix.orgbasically if we get a human readable list of dbs from the rax side, then cross check against service configs we should get a complete list of things we should then backup.15:23
@clarkb:matrix.organd maybe we just do that and hope for the best because ya I'm not really feeling in a position to do more than that right now15:23
@fungicide:matrix.orgfunny, there's a local mysqld running on cacti too15:23
@fungicide:matrix.orgi wonder if that's in use15:24
@fungicide:matrix.orgoh yep, /etc/dbconfig-common/cacti.conf has `$database_hostname = "REDACTED.rackspaceclouddb.com";`15:25
@clarkb:matrix.orgfungi: it is also possible some of those DBs won't be upgraded, but based on the email I suspect both cacti and wiki will be (but we should login and double check and confirm)15:25
@fungicide:matrix.orgthere's no mysqld nor mariadbd running on translate, so while i didn't check its config zanata probably is also affected15:26
@clarkb:matrix.orgbased on some cacti docs I'm hopeful that 5.7 won't be a big deal there15:31
@clarkb:matrix.orgfungi: I think we do already have backups running for translate (good idea to double check they look like we expect in borg). I don't see backups for cacti and I need to use an old key for wiki I think that I don't have loaded so haven't checked that one15:33
@clarkb:matrix.orgI need to finish breakfast things then jump into a PTG meeting in about 20 minutes. Maybe after (or during if we get bored) we start putting together an etherpad with the info we're collecting15:38
@fungicide:matrix.orgyeah, i'm in ptg sessions until 18z and then planning to find something to eat, but can put something together after that15:40
@clarkb:matrix.orgsounds good thanks15:40
@clarkb:matrix.orgI suspect that the biggest risks are wiki and zanata simply because we can't easily upgrade them. We'd likely be left reconfiguring them to speak to a local db of the expected version if 5.7 doesn't work15:41
@clarkb:matrix.orgcacti is a much simpler service with far less visibility, but also probably has the same fallback approach. So mostly we should make sure there isn't anything else that will be impacted, make sure we have backs for everything that is to make the fallback possible, and then ya take it from there I guess15:42
@clarkb:matrix.organd notes to track it all become important give the variety of things impacted and the differences in setup15:42
@fungicide:matrix.orgtranslate01 has recent dumps in /var/backups/mysql_backups/ but they look empty15:44
@clarkb:matrix.orgfungi: does it run the regular borg backup script? Maybe it switched to off host backups?15:44
@fungicide:matrix.orgyes, it's running borg in crontab15:45
@fungicide:matrix.organd has mysql streams configured to dump the db at rackspace15:46
@fungicide:matrix.orgsame for wiki15:47
@fungicide:matrix.orgcacti is not though, that i can tell15:48
@clarkb:matrix.orgYa cacti isn't. We can probably reduce our to-do list to confirm translate and wiki DB backups in borg look good. Manually run cacti DB backup. Check for any other services that might be affected15:51
@clarkb:matrix.orgI'm finding some evidence that cacti won't work with 5.7 in Google searches. But it's hard to say definitively15:52
@clarkb:matrix.orghttps://forums.cacti.net/viewtopic.php?t=11262 specifically this15:53
@clarkb:matrix.orgSo we may need to edit the 5.7 server my.ini to set that SQL mode?15:54
@fungicide:matrix.orgi was about to say we can just dump it to the local mysqld and switch to point there, but that server also has 5.7 installed15:55
@clarkb:matrix.orgI wonder if it is worth asking if we can have more time? 2 days isn't much notice and comes at a very busy time for the two of us15:56
@clarkb:matrix.orgThe next ~3 weeks are busy busy15:56
@fungicide:matrix.orgunrelated, i've got most of the important e-mail from the rackspace infra-root mailbox copied over to the gmail-hosted replacement, and am cleaning out folders which aren't being copied. the subfolder for the review@ address has 266k messages in it currently (i'm obviously not migrating those)16:13
@clarkb:matrix.orgthanks I noticed the new account had more content in it this morning'16:13
@clarkb:matrix.orghttps://www.mediawiki.org/wiki/Compatibility#Database is the mediawiki compatbility matrix. Its not super clear how far + goes though16:36
@clarkb:matrix.orgI don't really feel super confident in any of these tools talking to a newer database without changing the code or configs16:36
@clarkb:matrix.orghttps://hub.docker.com/layers/library/mysql/5.7-debian/images/sha256-8ba532f113f22d112fd3f8cbf9173c2a151c8699c968238cb0a6442818427fbf here is a mysql 5.7 on debian container image we can probably try to load the backups into to find any immediate problems?16:59
@clarkb:matrix.orgReally I'm starting to feel the timing more than anything else is the issue here. We've gone from openstack release to ddos to gerrit upgrade to ptg and next week I have LF travel and then week after that i Think fungi is on vacation. I think it asking for a delay would be helpful from my perspective. But all three of these services have been on life support and if we have to accept brokeness for a bit maybe that is ok?17:02
@jim:acmegating.comyeah if cacti is briefly broken we'll survive17:03
@clarkb:matrix.orgI just want a week where I can focus on what I thought was important on Friday and not the next fire :)17:04
@fungicide:matrix.orgi'll note that moving wiki to a local db is probably not too hard, the mysqld already running on the server is 5.517:06
@clarkb:matrix.orgack17:06
@clarkb:matrix.orgthough I can't currenly ssh into that server (I think I need to load my old rsa key then I will be able to)17:06
@clarkb:matrix.orgJust haven't had time to test that yet this morning17:06
@fungicide:matrix.orgi can replace ssh public keys on there if anyone needs17:07
@clarkb:matrix.orgI think the issue may be that my new key doesn't work on that old server?17:09
@clarkb:matrix.orgI think I can solve this but I want to test it. I'll do that after PTG ends for the morning17:09
-@gerrit:opendev.org- Michal Nasiadka proposed on behalf of Tony Breeds: [opendev/system-config] 921321: Add an opendev specific build of mediawiki https://review.opendev.org/c/opendev/system-config/+/92132117:12
@mnasiadka:matrix.orgClark: what's the next thing to pick up from the servers upgrade etherpad? I did some mini changes on https://review.opendev.org/c/opendev/system-config/+/921321 that should revive this stream a bit17:13
@mnasiadka:matrix.org(and I'm doing some work on the greptimedb long term storage for Prometheus, should be ready to upload tomorrow)17:14
@clarkb:matrix.orgmnasiadka: zp02 getting a replacement should be straightforward as well as insecure-ci-registry as they are largely stateless applications. The registry relies on swift to store the data. And then other than cacti/prometheus I think updating the backup servers probably has tbe biggest impact but is likely to be a bit more involved. For the backup servers we would want to create new servers with new volumes and point backups to them. Then we can detach the existing volumes from the existing backup servers and attach them to the new backup servers so that we have that data for a time. Then we can remove the old backup servers17:16
@clarkb:matrix.orgthen in a year or similar time frame we can remove the old backup volumes from the new server and clean up the old volumes and rely only on the new volumes from that point fowrard17:16
@mnasiadka:matrix.orgOk, zp02 first - one thing at a time :)17:16
@clarkb:matrix.orgworks for me. All of this is a great help as it reduces the scope of the problem space17:17
@mnasiadka:matrix.org(and I need to remove the old mirror instances from OpenStack - but one hour after I stopped them gerrit went SHUTOFF) :)17:17
@mnasiadka:matrix.org(and remove the volumes of the old mirror nodes)17:17
@fungicide:matrix.orgClark: on wiki ssh, i have a `Host wiki.openstack.org` in my .ssh/config where i override the `IdentityFile` and also set `HostkeyAlgorithms +ssh-rsa` and `PubkeyAcceptedAlgorithms +ssh-rsa`17:18
-@gerrit:opendev.org- Michal Nasiadka proposed on behalf of Tony Breeds: [opendev/system-config] 921322: Initial dump or mediawiki role and config https://review.opendev.org/c/opendev/system-config/+/92132217:19
@clarkb:matrix.orgfungi: thanks. I forgot about the hostkey algorithm thing but that may also be useful here17:19
@clarkb:matrix.orgfungi: I left some notes about static02-04 on https://etherpad.opendev.org/p/opendev-server-upgrade-planning since they were captured there17:22
@clarkb:matrix.orgI don't think that is urgent, but maybe you can check that the notes I wrote make sense given the current state of things17:23
@clarkb:matrix.orgGerrit 3.13 added back a feature flag to disable teh AI button17:24
@clarkb:matrix.orgso we can set that when we upgrade to 3.13 to avoid the confusion and hardcoded templates17:25
@clarkb:matrix.orgI don't think it is in a release yet so our test image doesn't support it, But we could rebuild 3.13 from stable-3.13 or whatever if it comes to that17:25
@mnasiadka:matrix.orgClark: Any objections to remove the old mirror instances that I shut down in the morning? They have been removed from DNS and inventory last week, so I'd assume it's extra safe to do that.17:26
@clarkb:matrix.orgno objections from me, but I haven't actively checked anything related to that this morning. I tried to double check things last week when I was approving the changes though17:27
@mnasiadka:matrix.org#status log Replaced mirror03.gra1.ovh.opendev.org (e4cf1ba1-4d0a-48d2-87b7-13899fa20128, volume 3768d0fc-ffb4-4c86-b094-1ae5ae595816) with mirror04.gra1.ovh.opendev.org17:29
@status:opendev.org@mnasiadka:matrix.org: finished logging17:29
@clarkb:matrix.orgmnasiadka: I think one difference with zp02 and other non mirror nodes is that you should be updatingthe test node label in system-config for that nodes as you update them17:32
@clarkb:matrix.orgwhereas with the mirrosr we were already testing the variety of platforms we run on17:32
@clarkb:matrix.orgthats a minor thing I just wanted to note it17:33
@mnasiadka:matrix.org#status log Replaced mirror02.ord.rax.opendev.org (4b16a662-761e-47a5-ada1-33256d4de297, volume 234c2b09-a2a9-4aba-b3d1-2bb7a0310f1f) with mirror03.ord.rax.opendev.org17:33
@status:opendev.org@mnasiadka:matrix.org: finished logging17:33
@mnasiadka:matrix.orgClark: ack17:33
@mnasiadka:matrix.org#status log Replaced mirror02.dfw.rax.opendev.org (7e608502-6e33-4a59-aa1a-b4e2257d0a11, volume 2172fe8e-3d0e-4f29-a2d1-ba12bd2cfb77) with mirror03.dfw.rax.opendev.org17:36
@status:opendev.org@mnasiadka:matrix.org: finished logging17:36
@mnasiadka:matrix.orgOk, mirrors done17:37
@clarkb:matrix.orgawesome17:37
@clarkb:matrix.orgfungi: I have managed to ssh into wiki now. I did just need the right key. I'm going to work on cleaning up old leaked images in rax classic as that was on my todo list from last week and it should hopefully be straightforward once I start working on it18:03
@clarkb:matrix.orgbut then after lunch I can probably help with filling out the db upgrade etherpad you volunteered to create18:03
@fungicide:matrix.orgyeah, i'm about to pop out for food now that the ptg is on break18:07
@clarkb:matrix.orgI've cleaned up rax-dfw and rax-ord of obviously leaked images. rax-iad is in progress and is a bit slower because there are more leaked images and some of them have duplicate names so I need to do a second pass hwere I use UUIDs instead of names18:35
@clarkb:matrix.orgI also notice that there are maybe more zuu-launcher images than I expected so we may be leaking those as well18:36
@clarkb:matrix.orgbut I haven't looked into that angle yet. I'm focused on cleaning up the old nodepool images and the bionic images at the moment18:36
@clarkb:matrix.org#status log Cleaned up leaked Nodepool and Bionic images from rax classic cloud regions19:12
@status:opendev.org@clarkb:matrix.org: finished logging19:12
@fungicide:matrix.orgthanks!19:31
@fungicide:matrix.orgi'm catching back up and will then return to looking at our wiki database options, since that seems like the biggest potential impact19:32
@fungicide:matrix.orgstrangely, the translate database indicates it's 5.7 already19:54
@fungicide:matrix.orgthe wiki db does say it's 5.6 though, as does cacti19:55
@fungicide:matrix.orgi resized the volume for the translate db from 6gb to 7gb since it was 90% utilized19:56
@fungicide:matrix.orgthe wiki server does have current local dumps of the trove db, fwiw19:57
@clarkb:matrix.orgfungi: maybe translate trove DB is not one in the list they shared? We probably do need to login and check the specific list against our services. But good to know one less service to worry about likely19:59
@fungicide:matrix.orgyeah, i'm logged in and see only 5 trove instances in total across all regions20:00
@clarkb:matrix.orgThey had DB names in the email are all five matching the 5 from the email? If so weird that the trove DB shows up. Probably worth a follow up to indicate that one appears to already be 5.7? And maybe even ask for a bit more time?20:01
@fungicide:matrix.orgi do see random reports across the internet of people running mediawiki 1.28 with mysql 5.720:03
@clarkb:matrix.orgIt could be that cacti is the only real concern and presumably with the SQL mode workaround I found that will work too20:04
@traylenator:matrix.org> <@traylenator:matrix.org> Thanks for the reply. That sounds plausible. I tried a few weeks back and could not get in for a different error. One of the things I tried then was deleting and re-creating in U.1. 20:07
> Deleting/disabling/updating the old id in gerrit sounds correct . Whenever you or someone gets a chance.
>
Clark: If you are able to sort my account that would be great, I have half a dozen simple py3.15a8 fixes from the openstack on rawhide I want to submit.
@fungicide:matrix.orgClark: oh! the e-mail from rackspace was html-only, and my mail client is configured to use w3m to conver it to plaintext. i guess the list of affected databases was supposed to be a table of uuids and names, so actually it's only 3 it just looked like 5 the way it came out20:11
@fungicide:matrix.orgcacti, wiki-dev (which is unused), and wiki20:11
@fungicide:matrix.orgso that matches what i'm finding in their dashboard20:12
@clarkb:matrix.orgOh it looked like 5 to me too in thunderbird20:13
@clarkb:matrix.org> <@traylenator:matrix.org> Clark: If you are able to sort my account that would be great, I have half a dozen simple py3.15a8 fixes from the openstack on rawhide I want to submit.20:13
I can probably take a look in a bit. Are you ok with the old account being disabled so that a new account can be created?
@fungicide:matrix.orgClark: okay, even in the ticket system it's spread over 5 lines, but looks like the three uuids listed there correspond to the three names listed (i just manually compared them all)20:16
@fungicide:matrix.orgi made an on-demand backup of the wiki-dev-mysql trove instance called "Wiki-Dev-MySQL-backup_2026-04-20_before_deletion" and am deleting it, mainly just a safety measure though i'm quite certain the server i was using that with has been gone for years already20:25
@fungicide:matrix.orgso that gets us down to two20:25
@fungicide:matrix.orgsince i see indication that people elsewhere are successfully running the same mediawiki version as us on mysql 5.7 i'm inclined to just upgrade and then deal with the fallout if something goes sideways, since we do have backups20:26
@clarkb:matrix.orgfungi: thats not the db that the current wiki server talks to?20:27
@fungicide:matrix.orgcorrect20:27
@clarkb:matrix.orgI guess the instance is wiki dev but it talk to the prod db?20:27
@clarkb:matrix.organd re that plan I guess that works. It probably works for cacti too given the thread I found?20:27
@fungicide:matrix.orgyeah, i had a series of wiki-dev servers i was using when trying to get the configuration management implemented years ago20:27
@fungicide:matrix.orgi deleted the last wiki-dev server but not the test copy of the database i'd been using with it20:28
@clarkb:matrix.orggot it20:28
@fungicide:matrix.orgthe production database instance is "Wiki-MySQL" and that's still intact20:28
@clarkb:matrix.orggiven that we think this may be a bit less of a crisis than perviously anticipated I guess I'll context switch to cleaning up Steve Traylen's old gerrit account. I've found the ID for the old account in Gerrit's error_log and found my notes from the last time I had to do this.20:31
@clarkb:matrix.orgIt will probably take a bit to page it all back in but I think I have what I need to do the necessary cleanups20:31
@clarkb:matrix.orgI actually think this may be a simpler cleanup as it looks like maybe the preferred email address for the old account is not the conflicting email? In that case I can probably leave the old account as is and simply remove the conflicting email address. But I'm inferring this through the web ui for now. need to double check in the notedb and via api requests20:32
@clarkb:matrix.orgSteve Traylen: I think the necessary cleanup is done now20:51
@clarkb:matrix.orgnote I didn't disable the old account since in this case the conflict only appeared to be as an extra email address. I only removed that one conflict from the old account20:51
@clarkb:matrix.orginfra-root: I'm working on putting my notes together and will stash them on review03 like I have been doing20:51
@clarkb:matrix.orgthe log file is now at review03:/home/clarkb/gerrit_user_cleanups/logs/ in a file with todays date as a prefix20:56
@clarkb:matrix.orgI have deescalated my privs now too. I think that concludes this cleanup assuming Steve Traylen is able to log in now20:57
@clarkb:matrix.orgfungi: oh we don't have cacti backups though. Should we try to do one of those locally or via the trove backup system like you did with wiki?20:57
@clarkb:matrix.orgfungi: I figure I'll defer to you on that since you've just been doing it for wiki, but I think we should have a cacti backup just in case20:58
@fungicide:matrix.orgoh, sure i can do that, can probably also make a local dump to the server for convenience20:59
@clarkb:matrix.orgthat would be great, thank you21:00
@fungicide:matrix.orgit's being created as `cacti-MySQL-backup_2026-04-20_before_upgrade`21:01
@fungicide:matrix.organd done21:01
@clarkb:matrix.orgis that within rax or locally?21:02
@fungicide:matrix.orgwithin rax. working on the mysqldump now21:02
@clarkb:matrix.orggot it21:02
@fungicide:matrix.orgi dumped it to ~fungi/2026-04-20.sql.gz21:10
@fungicide:matrix.orgshould i go ahead and upgrade in trove?21:10
@clarkb:matrix.orgyou mean now rather than waiting for wednesday?21:10
@fungicide:matrix.orgyeah, as in do we want to be in control of when the upgrade happens, so we can check that things are still working?21:11
@clarkb:matrix.orgI don't strongly object, but I'm not in a great spot to debug it if it goes sideways right now. I promised I would get some other stuff done today and I'm running out of time for that so will context switch shortly21:11
@clarkb:matrix.orgmaybe we want to do that tomorrow isntead?21:11
@fungicide:matrix.orgyeah that's fine. i can always do new backups tomorrow too21:11
@fungicide:matrix.orgnow that we've worked out the details21:11
@clarkb:matrix.orgya I think I'll be able to juggle paying attention to that tomorrow morning after ptg stuff (which is earlier for me tomorrow than it was today)21:12
@fungicide:matrix.orgthe database dumps for wiki and cacti don't take long at all21:12
@fungicide:matrix.orgsame for backup snapshots in rackspace21:12
@fungicide:matrix.orgso i could do new backups of each one right before upgrading, in case we need to fall back on them21:13
@clarkb:matrix.orggreat. Does your ptg schedule go late tomorrow? I think mine ends at 1500 UTC21:13
@clarkb:matrix.orgthe email had a suggested upgrade process too. We can decide if we want to follow that21:13
@clarkb:matrix.orgoh inclusivity wg is 16-170021:14
@clarkb:matrix.orgso maybe a bit later than I thought but not as late as today21:14
@fungicide:matrix.orgyeah, i was about to say i have that, but am free the hour before and after21:14
@clarkb:matrix.orgthe hour prior we have our meeting :) so ya lets aim for ~1700 UTC then21:15
@fungicide:matrix.orgah yep, for some reason my mind blocks out memory of all other scheduled meetings during the ptg21:29

Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!