Migrate Chrome to Flathub #422

starnight · 2025-07-09T09:55:42Z

Some notes:

Install Flathub's Chrome if it is not installed and eos-apps' Chrome is installed
Some services credentials (e.g. gmail) are lost during migration (requiring re-login)
The migration always runs if ~/.var/app/com.google.Chrome/.migrated (created at the end of the migration) doesn't exist and eos-apps' Chrome is installed (/var/lib/flatpak/app/com.google.Chrome/x86_64/eos3 exists), even if ~/.var/app/com.google.Chrome exists:
- This is such that we can update ~/.config/mimeapps.list to point the new Chrome in case the old Chrome is specified as default there but the user never ran it
- And also to remove old google-Chrome.desktop shortcut on ~/.local/share/applications that'd refer to the old Chrome as the executable
- Note that the actual user profile migration is skipped if ~/.var/app/com.google.Chrome already exists or if ~/.config/google-chrome doesn't exist by the time the migration runs

https://phabricator.endlessm.com/T26944

starnight · 2025-07-10T10:52:11Z

The new version commit uses eos-update-flatpak-repos, instead of uninstalling eos-apps Chrome & installing Flathub Chrome.

wjt

This isn't going to work as written, for a number of reasons, outlined below (and discussed further in the 6 years of comments in https://phabricator.endlessm.com/T26944).

I think what will work is the following strategy (developing https://phabricator.endlessm.com/T26944#903813):

Update the eos-apps version's desktop file to be launchable directly, in such a way that its desktop file is hidden on current Endless OS versions but will become visible in a future release, which you can do using TryExec=/usr/share/eos-google-chrome-helper/magic-flag-executable
Now in an OS update:
- Use eos-application-tools to force eos-apps com.google.Chrome to be updated as part of the OS upgrade if it is installed
- Put a stub executable at that path
- Remove /usr/share/applications/google-chrome.desktop from the OS (or set it to NoDisplay=true so you can use the normal GLib MIME API to update the MIME associations to com.google.Chrome.desktop)
- Add this migration script that moves the config files but adds a symlink from the old directory to the new
- And use eos-update-flatpak-repos to, on first boot into the new OS version, rewrite the deploy file so that future updates come from Flathub
Then in a later OS update, after a checkpoint (so we can guarantee that the switcheroo has happened), and also with an eos-application-tools entry to ensure the flathub version of com.google.Chrome has been updated if installed, we can remove all this stuff.

It's a really awkward and messy transition.

wjt · 2025-07-11T12:17:03Z

eos-migrate-chrome-profile

+    We cannot use GLib's own API to query what mime types the old Chromium desktop file
+    is a handler for, because we can't construct a GDesktopAppInfo for it, because its
+    desktop file no longer exists.


The built-in desktop file has to still exist, because otherwise when the user boots their system, Chrome will disappear until it happens to be upgraded.

That's because eos-update-flatpak-repos doesn't actually install the new version from Flathub. It can't do so because it runs early in the boot process, when the network may not be available and where we don't want to block on a large download. All it does is adjust the already installed app to appear to have been installed from flathub, so that future updates come from that remote.

So you have to handle the case where the old Flatpak is installed (with its deploy file rewritten). The eos-apps version can't be launched directly, only via /usr/share/applications/google-chrome.desktop. So that desktop file has to remain on the system. We can only remove it following a checkpoint (perhaps the eos6 → eos7 transition); and even then only if we force com.google.Chrome to be updated (if installed) across the upgrade.

And then this script can indeed use the normal GLib mime API.

wjt · 2025-07-11T12:17:50Z

eos-migrate-chrome-profile

+def remove_old_desktop_shortcut(path=DESKTOP_SHORTCUTS_DIR):
+    try:
+        shortcuts = os.listdir(path)
+    except FileNotFoundError:
+        return
+
+    if OLD_DESKTOP_FILE in shortcuts:
+        os.remove(os.path.join(path, OLD_DESKTOP_FILE))


Why would google-chrome.desktop be in .local/share/applications? It lives in /usr/share/applications.

But what does live in ~/.local/share/applications are launchers for specific websites. Open YouTube in the eos-apps chrome, and choose to install it (menu -> cast, save and share -> install). Now you will have a file like this (this is what's on my system at .local/share/applications/chrome-agimnkijcaahngcdmfeangaknmldooml-Profile_1.desktop but I don't think the ID is deterministic?):

#!/usr/bin/env xdg-open [Desktop Entry] Version=1.0 Terminal=false Type=Application Name=YouTube Exec=/usr/bin/eos-google-chrome "--profile-directory=Profile 1" --app-id=agimnkijcaahngcdmfeangaknmldooml Icon=chrome-agimnkijcaahngcdmfeangaknmldooml-Profile_1 StartupWMClass=crx_agimnkijcaahngcdmfeangaknmldooml Actions=Explore;Subscriptions [Desktop Action Explore] Name=Explore Exec=/usr/bin/eos-google-chrome "--profile-directory=Profile 1" --app-id=agimnkijcaahngcdmfeangaknmldooml "--app-launch-url-for-shortcuts-menu-item=https://www.youtube.com/feed/explore?feature=app_shortcuts" [Desktop Action Subscriptions] Name=Subscriptions Exec=/usr/bin/eos-google-chrome "--profile-directory=Profile 1" --app-id=agimnkijcaahngcdmfeangaknmldooml "--app-launch-url-for-shortcuts-menu-item=https://www.youtube.com/feed/subscriptions?feature=app_shortcuts"

Looks like I miss-understood this part.

wjt · 2025-07-11T12:21:20Z

eos-migrate-chrome-profile

+            os.path.join(OLD_CHROME_CONFIG_DIR,
+                         "WidevineCdm", "latest-component-updated-widevine-cdm"))
+        os.makedirs(os.path.dirname(NEW_CHROME_CONFIG_DIR), exist_ok=True)
+        os.rename(OLD_CHROME_CONFIG_DIR, NEW_CHROME_CONFIG_DIR)


I think you additionally need a symbolic link at the old directory pointing to the new directory, so that the old version of the app can still find its config (until the update is applied).

The new commit installs Flathub's Chrome and uninstalls eos-apps Chrome. So, this avoids the symbolic link.

What happens if eos-apps Chrome is running at this point in the process? (Very much possible if the internet connection is slow.)

New commit:

Checks the installation of Flathub's Chrome as a barrier.

res = subprocess.run(["flatpak", "info", "-o", "com.google.Chrome//stable"], capture_output=True) if res.stdout != b"flathub\n": print("Flathub Chrome has not been installed", file=sys.stderr) sys.exit(1)

Moves installation of Flathub's Chrome to eos-migrate-chrome.service, which runs before gdm.service.

eos-migrate-chrome-profile.service only executes when the user login with gdm, Flathub's Chrome is installed, there is ~/.config/google-chome and there is no ~/.var/app/com.google.Chrome/config/google-chrome

What happens if you boot the computer when you're away from home and don't have a network connection? (This is not unlikely given that we have automatic updates. Maybe I shut my computer down (without knowing an update is staged), put it in my bag, and turned it on in a coffee shop.)

Does this block the boot process until some timeout is reached? Or indefinitely?

And then - when the network does come up, I'll not actually get the Chrome switch. So what do we expect to happen in that case? How will I get the update? How can we be sure it is safe to remove the eos-google-chrome-helper from the OS?

How can we be sure it is safe to remove the eos-google-chrome-helper from the OS?

I think before user's system get this migration mechanism, the system must get (1) connected internet and get the (2) release. If the system can get the release, then I think the system can download the Flathub's chrome, too.

Besides, I think existing systems will go to a checkpoint before update to EOS 7 based on GNOME OS. So, I think it is good to drop eos-browser-tools (which provides eos-google-chrome-helper) from EOS 7 and the checkpoint release. So, there should be at least one release containing this migration tool between 6.0.7 and the checkout point release.

I think the system can download the Flathub's chrome, too.

A computer can be online and able to connect to our ostree server while flathub's CDN is down, or Google's CDN for that matter.

If the Flathub's CDN (or related CDNs) is down, then eos-migrate-chrome cannot install Flathub's chorme and it will exit with error, which will not uninstall eos3's chrome. So, eos-migrate-chrome.service will be triggered again at next boot.

eos-migrate-chrome.service will be triggered automatically for each boot until the Flathub's chrome is installed and eos3's chrome is uninstalled.

But there is no guarantee that the user will ever boot their system and have the network be available prior to reaching GDM. Perhaps they always connect via a Wi-Fi hotspot on their phone, and they are in the habit of doing this:

Boot their laptop

Log in

Oops, I forgot! Turn on the Wi-Fi hotspot on the phone

Now the laptop is online, and can receive OS updates, but this script will not have run.

Okay, I agree this is a problem now.

eos-migrate-chrome-profile.service

starnight · 2025-07-15T06:58:09Z

The new updated commit uninstalls eos-apps' Chrome and installs Flathub's Chrome, instead of using eos-update-flatpak-repos. This avoids the complicated hacky transformation.

wjt

Getting there! This does seem simpler.

wjt · 2025-07-15T11:39:30Z

eos-update-flatpak-repos

+    # migrate Chrome to flathub (T26944)
+    {
+        'name': 'com.google.Chrome',
+        'kind': Flatpak.RefKind.APP,
+        'old-branch': 'eos3',
+        'new-branch': 'stable',
+        'old-origin': 'eos-apps',
+        'new-origin': 'flathub'
+    },


Why is this hunk still present if you're trying to avoid using this?

Thanks for the eye. Sorry for my messy brain.

wjt · 2025-07-15T11:40:32Z

eos-migrate-chrome-profile

+
+    res = subprocess.run(["flatpak", "info", "-o", "com.google.Chrome//stable"])
+    if res.returncode == 1:
+        res = subprocess.run(["flatpak", "install", "flathub", "com.google.Chrome", "-y"])


You should only install flathub Chrome if eos-apps Chrome is installed.

But this script should still run if eos-apps Chrome is not installed. Consider the case where the system has three users. Then:

User 1 logs in. This script runs, installs flathub Chrome, and removes eos-apps Chrome, and migrates user 1's config

User 2 logs in. Their config should still be migrated but no changes should be made to the installed apps

Now User 2 decides to uninstall flathub Chrome

User 3 logs in. Their config should still be migrated, but flathub Chrome should not be re-installed

For bonus points, consider what happens if User 1 and 2 are both logged in at once!

I had an idea before, but did not do like it now. Two services:

Uninstall eos-apps Chrome and install Flathub Chrome before gdm.service and having NetworkManager.service

Migrate Chrome profile service in gnome-session.target

However, according to the questions, seems like using the two services is a better solution.

Updated in the new commit.

eos-migrate-chrome-profile.service

wjt · 2025-07-15T11:43:58Z

eos-migrate-chrome-profile

+            os.path.join(OLD_CHROME_CONFIG_DIR,
+                         "WidevineCdm", "latest-component-updated-widevine-cdm"))
+        os.makedirs(os.path.dirname(NEW_CHROME_CONFIG_DIR), exist_ok=True)
+        os.rename(OLD_CHROME_CONFIG_DIR, NEW_CHROME_CONFIG_DIR)


What happens if eos-apps Chrome is running at this point in the process? (Very much possible if the internet connection is slow.)

eos-migrate-chrome

eos-migrate-chrome-profile

eos-migrate-chrome.service

wjt

We cannot rely on the network being available during the boot process to run this migration. If we are insisting on using an ad-hoc migration script, rather than using some combination of eos-update-flatpak-repos + making the eos-apps Chrome Flatpak be directly launchable + eos-updater-flatpak-installer to do the migration, then we will need to make the migration script be triggered by the network going online; or I guess another option is to have eos-updater run it directly. Either way, this means we need to handle the case where the migration runs while a user is logged in and has eos-apps Chrome installed.

I think it's right to do this in EOS 6, but we will separately need to add logic in eos-updater to prevent crossing the checkpoint and upgrading to EOS 7 if the migration is necessary and has not been completed. This will be similar to some of the previous ad-hoc checks we've used to block upgrades, such as "is nvme-remap in use".

wjt · 2025-09-02T11:24:35Z

eos-migrate-chrome-profile

+            os.path.join(OLD_CHROME_CONFIG_DIR,
+                         "WidevineCdm", "latest-component-updated-widevine-cdm"))
+        os.makedirs(os.path.dirname(NEW_CHROME_CONFIG_DIR), exist_ok=True)
+        os.rename(OLD_CHROME_CONFIG_DIR, NEW_CHROME_CONFIG_DIR)


But there is no guarantee that the user will ever boot their system and have the network be available prior to reaching GDM. Perhaps they always connect via a Wi-Fi hotspot on their phone, and they are in the habit of doing this:

Boot their laptop

Log in

Oops, I forgot! Turn on the Wi-Fi hotspot on the phone

Now the laptop is online, and can receive OS updates, but this script will not have run.

wjt · 2025-09-02T11:30:21Z

eos-migrate-chrome.service

+After=network-online.target
+Wants=network-online.target
+Before=gdm.service


systemd.special(7) tells me (emphasis mine):

network-online.target
Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a service that delays further execution until the network is sufficiently set up. What precisely this requires is left to the implementation of the network managing service.

In the case where no network is available during boot, I believe this will cause the boot process to block for 60 seconds; then NetworkManager-wait-online.service will time out; then this script will run (and fail); and only then will GDM start.

I don't think it's acceptable to block the boot for a minute waiting for a network that may never come up.

And ConditionPathExists doesn't save us here. From systemd.unit(5), in the section Conditions and Asserts (emphasis mine):

The ordering dependencies are still respected, so other units are still pulled in and ordered as if this unit was successfully activated, and the conditions and asserts are executed the precise moment the unit would normally start and thus can validate system state after the units ordered before completed initialization.

I believe this means that even if /var/lib/flatpak/app/com.google.Chrome/x86_64/eos3 does not exist, the Wants and After relationship on network-online.target will still be respected, and so this change would require the network to come up before GDM regardless of whether the migration needs to be performed.

Uhm, found For those who use systemd services that rely on a “network” connection.

After=network-online.target Wants=network-online.target

Seems waiting on network-online.target is not as expected, nor reliable anymore.

So, I check system log and notice when system connects to available internet, NetworkManager shows message: manager: NetworkManager state is now CONNECTED_GLOBAL. Then, I wondering is there any NetworkManager's dbus signal relating to CONNECTED_GLOBAL. However, after checked with DSpy, I did not find any NetworkManager's signal relating to CONNECTED_GLOBAL.

I was sure I had mentioned this but I can't find it in this thread.

Look at /etc/NetworkManager/dispatcher.d/

Thanks! I notice the scripts 01-ifupdown and 50-eos-phone-home in /etc/NetworkManager/dispatcher.d/.

Then, we have to filter the events. Only service CONNECTED_GLOBAL like event.

Have script 50-eos-migrate-chrome and link it as /etc/NetworkManager/dispatcher.d/50-eos-migrate-chrome within the new commit. It will trigger eos-migrate-chrome.service when NetworkManager changes state to CONNECTED_GLOBAL.

starnight · 2025-09-10T03:56:26Z

Although EOS master's environment is (going to be) based on GNOME OS now and this should be applied to EOS 6, it is still good be in master branch, too.

This can be reverted on master branch in the future, if we want.

starnight · 2025-09-10T06:06:10Z

Note: If one tries to build eos-boot-helper locally during this transition time, will hit the issue mentioned by commit eos-update-efi-uuid: Fix warning treated as error. Revert it as workaround if the environment is based on old EOS master.

wjt · 2025-09-10T10:35:56Z

eos-migrate-chrome.service

+Type=oneshot
+ExecStart=/usr/lib/eos-boot-helper/eos-migrate-chrome
+Restart=no
+RemainAfterExit=yes


I can never quite remember the semantics here, but I believe this means that, once the service is started once, then it will always be considered active, and so systemctl start eos-migrate-chrome.service will do nothing. If I'm right then I believe this is wrong. Consider the following sequence of events:

Computer becomes connected;

NM hook starts this service;

Computer becomes disconnected while downloading Flathub Chrome;

This service exits, but I believe it will still be considered to be running;

Now the computer goes offline and online again.

I believe in this case we would want the script to be started again, but due to RemainAfterExit=yes it won't be.

I was thinking:

Computer becomes connected;

NM hook starts this service, and the service is working;

User login and systemctl start eos-migrate-chrome.service again manually while the service is working & downloading Flathub's Chrome;

Then, eos-migrate-chrome will execute again.

But, this might be okay. Flatpak has its own lock mechanism.

System d won't launch the service a second time while the first instance is running

wjt · 2025-09-10T10:43:47Z

eos-migrate-chrome.service

+After=NetworkManager.service
+Wants=NetworkManager.service


I don't think this is necessary.

ok, updated in the new commit.

wjt · 2025-09-10T10:48:49Z

eos-migrate-chrome-profile.service

+[Install]
+WantedBy=gnome-session.target


Now that eos-migrate-chrome.service can run at any time – not just during boot – then it's not sufficient to run this at login. You need to trigger this user service for any logged-in users at the time when flathub Chrome gets installed.

I think you probably want to do this with a .path unit. Something like this (untested!) which will trigger the corresponding .service in 2 cases:

On login, if Flathub Chrome is installed

Post-login, if Flathub Chrome becomes installed

# /lib/systemd/user/eos-migrate-chrome-profile.path [Unit] Description=... [Path] PathExists=/var/lib/flatpak/app/com.google.Chrome/x86_64/stable [Install] WantedBy=gnome-session.target

and then remove the [Install] section from this file:

Suggested change

[Install]

WantedBy=gnome-session.target

Thanks! First time study systemd.path. It is interesting

Use eos-migrate-chrome-profile.path to trigger eos-migrate-chrome-profile.service in the new commit

After think twice, eos-migrate-chrome-profile.service should be installed into nome-session.target, too. Because eos-migrate-chrome-profile.path uses PathChanged=/var/lib/flatpak/app/com.google.Chrome/x86_64/stable, instead of PathExists. That takes care 2nd & more users, or user login lately and eos3 Chrome has been replaced.

Why use PathChanged? Because, systemd.path has start/trigger limited times. So, only trigger when /var/lib/flatpak/app/com.google.Chrome/x86_64/stable changes.

Updated the commit again

Sorry for the missed "WantedBy" in eos-migrate-chrome-profile.service. Fixed in the new commit again.

I think you probably want to do this with a .path unit. Something like this (untested!) which will trigger the corresponding .service in 2 cases:

On login, if Flathub Chrome is installed

Installing eos-migrate-chrome-profile.service into gnome-session.target takes care of it.

Post-login, if Flathub Chrome becomes installed

Installing eos-migrate-chrome-profile.path into gnome-session.target takes care of it. eos-migrate-chrome-profile.path keeps watch the path /var/lib/flatpak/app/com.google.Chrome/x86_64/stable is changed, or not. If Flathub's Chrome becomes installed, path /var/lib/flatpak/app/com.google.Chrome/x86_64/stable becomes existed from not existed. Then, it triggers eos-migrate-chrome-profile.service.

Some notes: - The Chrome migration service installs Flathub's Chrome if it is not installed and eos-apps' Chrome is installed, then uninstalls the eos-app's Chrome. - This Chrome migration service will be triggered by NetworkManager dispatcher script 50-eos-migrate-chrome. - The Chrome's profile migration service runs if Flathub's Chrome is installed, '~/.config/google-chrome' (eos-apps Chrome' config) exits and '~/.var/app/com.google.Chrome/config/google-chrome' (Flathub Chrome's config) does not exist. - Chrome's profile migration service will be triggered by either eos-migrate-chrome-profile.path which keeps monitoring the key path, or user login (gnome-session) - This is such that we can update '~/.config/mimeapps.list' to point the new Chrome in case the old Chrome is specified as default there but the user never ran it - Note that the actual user profile migration is skipped if '~/.var/app/com.google.Chrome/config/google-chrome' already exists or if '~/.config/google-chrome' doesn't exist by the time the migration runs - Some services credentials (e.g. gmail) are lost during profile migration (requiring re-login) https://phabricator.endlessm.com/T26944

starnight requested review from dsd and wjt July 9, 2025 10:06

starnight marked this pull request as draft July 10, 2025 07:41

starnight force-pushed the T26944-migrate-chrome-to-flathub branch from 7db5f46 to c79c1e3 Compare July 10, 2025 10:50

starnight marked this pull request as ready for review July 10, 2025 10:51

wjt requested changes Jul 11, 2025

View reviewed changes

starnight force-pushed the T26944-migrate-chrome-to-flathub branch from c79c1e3 to 32c6528 Compare July 15, 2025 06:51

starnight marked this pull request as draft July 15, 2025 06:51

starnight force-pushed the T26944-migrate-chrome-to-flathub branch from 32c6528 to ea0799e Compare July 15, 2025 06:53

starnight marked this pull request as ready for review July 15, 2025 06:54

starnight requested a review from wjt July 15, 2025 06:58

starnight marked this pull request as draft July 15, 2025 10:51

starnight force-pushed the T26944-migrate-chrome-to-flathub branch from ea0799e to 11f784f Compare July 15, 2025 11:02

starnight marked this pull request as ready for review July 15, 2025 11:03

wjt requested changes Jul 15, 2025

View reviewed changes

starnight force-pushed the T26944-migrate-chrome-to-flathub branch from 11f784f to 95d29a8 Compare July 16, 2025 09:12

starnight requested a review from wjt July 16, 2025 09:24

wjt reviewed Aug 21, 2025

View reviewed changes

eos-migrate-chrome Outdated Show resolved Hide resolved

wjt reviewed Aug 21, 2025

View reviewed changes

eos-migrate-chrome-profile Outdated Show resolved Hide resolved

wjt reviewed Aug 21, 2025

View reviewed changes

eos-migrate-chrome.service Outdated Show resolved Hide resolved

starnight force-pushed the T26944-migrate-chrome-to-flathub branch from 95d29a8 to d982997 Compare September 2, 2025 06:30

wjt requested changes Sep 2, 2025

View reviewed changes

starnight force-pushed the T26944-migrate-chrome-to-flathub branch from d982997 to 6c3cc7a Compare September 9, 2025 11:21

starnight requested a review from wjt September 10, 2025 03:52

wjt requested changes Sep 10, 2025

View reviewed changes

starnight force-pushed the T26944-migrate-chrome-to-flathub branch from 6c3cc7a to 5bbd9d8 Compare September 11, 2025 10:43

starnight requested a review from wjt September 11, 2025 10:45

starnight force-pushed the T26944-migrate-chrome-to-flathub branch from 5bbd9d8 to ff002ff Compare September 11, 2025 11:24

starnight marked this pull request as draft September 11, 2025 12:16

starnight force-pushed the T26944-migrate-chrome-to-flathub branch from ff002ff to efb5564 Compare September 11, 2025 12:22

starnight marked this pull request as ready for review September 11, 2025 12:23

		After=NetworkManager.service
		Wants=NetworkManager.service

Migrate Chrome to Flathub #422

Are you sure you want to change the base?

Migrate Chrome to Flathub #422

Uh oh!

Conversation

starnight commented Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

starnight commented Jul 10, 2025

Uh oh!

wjt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

starnight commented Jul 15, 2025

Uh oh!

wjt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wjt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

starnight commented Jul 9, 2025 •

edited

Loading

starnight Sep 9, 2025 •

edited

Loading

starnight commented Sep 10, 2025 •

edited

Loading

starnight Sep 11, 2025 •

edited

Loading