Add Upgrade Functionality #1683

silverhadch · 2025-07-14T12:03:19Z

toolbox upgrade: Add package manager detection and upgrade capability

This PR introduces a new toolbox upgrade command that:

Key Features

Automatically detects the container's package manager (supports 11 package managers)
Performs full system upgrades using the native package manager
Works with both individual containers (--container) and all containers (--all)
Provides clear output showing detected package manager and upgrade progress

Supported Package Managers

✔️ dnf/microdnf/yum (RHEL/Fedora)
✔️ apt (Debian/Ubuntu)
✔️ pacman (Arch)
✔️ zypper (openSUSE)
✔️ apk (Alpine)
✔️ And 5 others (xbps, emerge, slackpkg, swupd)

Usage Examples

# Upgrade specific container
toolbox upgrade --container fedora-toolbox-38

# Upgrade all containers
toolbox upgrade --all

Implementation Details

Uses existing runCommand infrastructure
Gracefully handles errors during upgrade process
Includes comprehensive man page documentation
Follows established toolbox patterns

This provides users with a simple, unified way to keep all their toolbox containers updated regardless of distro.

softwarefactory-project-zuul · 2025-07-14T13:27:39Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/6243812c3cc0426981bee485ffca293b

softwarefactory-project-zuul · 2025-07-17T07:49:20Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/58e7ac1e61604d2db4a8e18459105b79

softwarefactory-project-zuul · 2025-07-19T15:26:57Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/0e024dbcd57a48b68f0e655569fd32b1

debarshiray

Thanks for working on this, @silverhadch !

There are a few different use-cases for handling updates to Toolbx containers. #580 is about a minimal command line interface banner. #1358 is about rebasing an existing container over an image for a new operating system version, which is a variant of rebasing over an image for the same OS version, and they are both related to #873

So, we need to think through how all those different use-cases will fit together. eg., the mechanism to show a CLI banner overlaps with the changes in this pull request. Do you have any ideas for that? If nothing else, it can impact the name of the new command. :)

By the way, the Git commits in the feature branch for this PR needs some fixing, because there's a merge commit within the branch itself.

debarshiray · 2025-07-22T23:56:18Z

doc/toolbox-upgrade.1.md

+toolbox\-upgrade - Upgrade packages in Toolbx containers
+
+## SYNOPSIS
+**toolbox upgrade** [*--all* | *-a*] [*--container* | *-c* *CONTAINER*]


Wouldn't it be better to be able to toolbox upgrade CONTAINER, without the --container option? It's less typing, and the pattern is already used in the create, enter, rm and rmi commands.

We would still need the --all option.

I meant that we shouldn't have the --container at all, and just use the positional argument:

$ toolbox upgrade CONTAINER

The --container is used by the run command, because the command to be run takes up the positional argument; and it's used by the create and enter commands only for backwards compatibility with old POSIX shell implementation and is no longer documented in their manual pages.

@martymichal made this change when writing the Go implementation because it's a lot more natural to type toolbox create CONTAINER or toolbox enter CONTAINER, than toolbox create --container CONTAINER or toolbox enter --container CONTAINER; and in this case it lets you specify multiple containers with toolbox upgrade CONTAINER1 CONTAINER2.

So, let's not introduce a --container option here, and let's just stick to the new style.

debarshiray · 2025-07-23T00:08:00Z

src/cmd/upgrade.go

+		{"command -v apk", "sudo apk update && sudo apk upgrade", "apk"},
+		{"command -v emerge", "sudo emerge --sync && sudo emerge -uDN @world", "emerge"},
+		{"command -v slackpkg", "sudo slackpkg update && sudo slackpkg upgrade-all", "slackpkg"},
+		{"command -v swupd", "sudo swupd update", "swupd"},


It will be better to encode the package manager metadata in the image. That way any image that's not built into Toolbx can easily specify its own metadata without requiring changes to the Toolbx code, a new Toolbx release, etc..

One option is to express these through the image's labels. eg., com.github.containers.toolbox.package-manager.update="sudo dnf --assumeyes update".

If the label is missing, we error out by saying that the container doesn't support updates. With passing time, as the newer images propagate, this will happen less and less. If the labels are there, we can directly try the command without the command -v ... step.

Thanks a lot!

I realized that I should have written toolbx, not toolbox for the name of the label. So: com.github.containers.toolbx.package-manager.update.

I should have checked my copy-paste. My apologies for the trouble!

Labels are annoying to migrate, so let's go with the new name of the project from the beginning.

silverhadch · 2025-07-23T04:00:45Z

I agree it would be better if we use metadata instead. Will work on this soon.

softwarefactory-project-zuul · 2025-07-27T20:43:05Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/3d8f832f05e745669282da7b9de0ff4d

softwarefactory-project-zuul · 2025-07-28T13:58:38Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/093bd44335a048d39fa2966e52e9e8ea

silverhadch · 2025-07-28T15:03:21Z

@debarshiray
I applied the suggestions. Now the upgrade command reads the update command from the container’s labels and no longer requires the --container flag if the container name is passed as a positional argument.

So the upgrade subcommand updates the container as intended.

Other use cases are out of scope for this PR and will be implemented later. This PR focuses purely on the updating functionality.

Planned future PRs:

Displaying a banner to notify the user if security updates are available.
Adding a rebase subcommand to handle rebasing containers.

softwarefactory-project-zuul · 2025-07-28T16:14:15Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/428e71e86b5d4ab4a846551d8e66b9b8

✔️ unit-test SUCCESS in 2m 23s
✔️ unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 31s
✔️ unit-test-restricted SUCCESS in 2m 18s
❌ system-test-fedora-rawhide-commands-options FAILURE in 1h 14m 39s
✔️ system-test-fedora-rawhide-runtime-environment-arch-fedora SUCCESS in 59m 20s
✔️ system-test-fedora-rawhide-runtime-environment-ubuntu SUCCESS in 13m 40s
❌ system-test-fedora-42-commands-options FAILURE in 1h 14m 44s
✔️ system-test-fedora-42-runtime-environment-arch-fedora SUCCESS in 1h 04m 07s
✔️ system-test-fedora-42-runtime-environment-ubuntu SUCCESS in 16m 45s
❌ system-test-fedora-41-commands-options FAILURE in 1h 15m 22s
✔️ system-test-fedora-41-runtime-environment-arch-fedora SUCCESS in 1h 05m 40s
✔️ system-test-fedora-41-runtime-environment-ubuntu SUCCESS in 17m 43s

silverhadch · 2025-08-08T05:20:02Z

@debarshiray
It would be nice if you take a look again. Since its slowing down progress in KDE Kontainer since we added a lot of Code for Downstream Toolbox Features which these PRs are trying to upstream.

debarshiray

I applied the suggestions. Now the upgrade command reads the update command from the container’s labels and no longer requires the --container flag if the container name is passed as a positional argument.

Thanks for updating the pull request, @silverhadch !

Other use cases are out of scope for this PR and will be implemented later. This PR focuses purely on the updating functionality.

Ok. I spent some time thinking about the name of the new command. I agree that upgrade is more appropriate than rebase for the command introduced by this pull request.

It would be nice if you take a look again. Since its slowing down progress in KDE Kontainer since we added a lot of Code for Downstream Toolbox Features which these PRs are trying to upstream.

My apologies. Two things got in the way.

I had to switch focus to understanding the impact of some security issues that got marked as critical and high. They eventually needed a new release, and some downstream paperwork.

I am leaving for a two week vacation tomorrow, which meant that I had a ton of miscellaneous things to wrap up before leaving.

However, I didn't want to leave you hanging for another two weeks. So, while I didn't get the chance to try out and test your PR, I think it's headed in the right direction. I will get it merged once I am back, and then into a release.

In the meantime, some thoughts:

Would you be motivated to write some tests? I suppose writing tests to actually update the container will be difficult until we update all the images, but at least you can start with some tests for the error paths.

You can update the built-in images for Arch Linux and Ubuntu at images/arch and images/ubuntu. /cc @Foxboron @Jmennius

The Fedora and RHEL images are more complicated because they are built elsewhere. We will update them once this PR is ready and merged.

src/cmd/utils.go

softwarefactory-project-zuul · 2025-08-13T08:30:44Z

Build succeeded.
https://softwarefactory-project.io/zuul/t/local/buildset/ed141600adcb454e9e659d16c8ed3cfd

silverhadch · 2025-08-15T07:36:55Z

@debarshiray
I added Tests and Updated the Images.

softwarefactory-project-zuul · 2025-08-15T09:05:56Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/57504c2b3321488fa82fb2f40ceafe7f

✔️ unit-test SUCCESS in 2m 14s
✔️ unit-test-migration-path-for-coreos-toolbox SUCCESS in 4m 08s
✔️ unit-test-restricted SUCCESS in 2m 35s
❌ system-test-fedora-rawhide-commands-options FAILURE in 1h 01m 00s
✔️ system-test-fedora-rawhide-runtime-environment-arch-fedora SUCCESS in 42m 00s
✔️ system-test-fedora-rawhide-runtime-environment-ubuntu SUCCESS in 10m 16s
❌ system-test-fedora-42-commands-options FAILURE in 1h 27m 37s
✔️ system-test-fedora-42-runtime-environment-arch-fedora SUCCESS in 1h 16m 07s
✔️ system-test-fedora-42-runtime-environment-ubuntu SUCCESS in 18m 42s
❌ system-test-fedora-41-commands-options FAILURE in 1h 22m 10s
✔️ system-test-fedora-41-runtime-environment-arch-fedora SUCCESS in 1h 08m 54s
✔️ system-test-fedora-41-runtime-environment-ubuntu SUCCESS in 19m 49s

softwarefactory-project-zuul · 2025-08-15T21:42:38Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/2a2d49a61ed6468189b26b9a1882a039

✔️ unit-test SUCCESS in 2m 55s
✔️ unit-test-migration-path-for-coreos-toolbox SUCCESS in 4m 12s
✔️ unit-test-restricted SUCCESS in 2m 36s
❌ system-test-fedora-rawhide-commands-options FAILURE in 57m 53s
✔️ system-test-fedora-rawhide-runtime-environment-arch-fedora SUCCESS in 39m 21s
✔️ system-test-fedora-rawhide-runtime-environment-ubuntu SUCCESS in 10m 24s
❌ system-test-fedora-42-commands-options FAILURE in 1h 25m 43s
✔️ system-test-fedora-42-runtime-environment-arch-fedora SUCCESS in 1h 12m 27s
✔️ system-test-fedora-42-runtime-environment-ubuntu SUCCESS in 18m 04s
❌ system-test-fedora-41-commands-options FAILURE in 1h 21m 11s
✔️ system-test-fedora-41-runtime-environment-arch-fedora SUCCESS in 1h 06m 31s
✔️ system-test-fedora-41-runtime-environment-ubuntu SUCCESS in 18m 07s

silverhadch · 2025-08-16T06:33:57Z

@debarshiray
The Tests will fail till the images are updated. But hey atleast the error path is getting indirectly tested.

softwarefactory-project-zuul · 2025-08-16T07:56:26Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/e835ab30073b4d9c83f5f5ffc7c7a6b6

✔️ unit-test SUCCESS in 2m 11s
✔️ unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 31s
✔️ unit-test-restricted SUCCESS in 2m 06s
❌ system-test-fedora-rawhide-commands-options FAILURE in 52m 24s
✔️ system-test-fedora-rawhide-runtime-environment-arch-fedora SUCCESS in 38m 49s
✔️ system-test-fedora-rawhide-runtime-environment-ubuntu SUCCESS in 9m 06s
❌ system-test-fedora-42-commands-options FAILURE in 1h 22m 00s
✔️ system-test-fedora-42-runtime-environment-arch-fedora SUCCESS in 1h 02m 46s
✔️ system-test-fedora-42-runtime-environment-ubuntu SUCCESS in 17m 37s
❌ system-test-fedora-41-commands-options FAILURE in 1h 21m 02s
✔️ system-test-fedora-41-runtime-environment-arch-fedora SUCCESS in 1h 04m 50s
✔️ system-test-fedora-41-runtime-environment-ubuntu SUCCESS in 16m 46s

Signed-off-by: Hadi Chokr <[email protected]>

softwarefactory-project-zuul · 2025-08-18T19:20:27Z

Build failed.
https://softwarefactory-project.io/zuul/t/local/buildset/0bdff452429245ccbc76b7798a063a70

✔️ unit-test SUCCESS in 2m 07s
✔️ unit-test-migration-path-for-coreos-toolbox SUCCESS in 4m 31s
✔️ unit-test-restricted SUCCESS in 2m 08s
❌ system-test-fedora-rawhide-commands-options FAILURE in 54m 17s
✔️ system-test-fedora-rawhide-runtime-environment-arch-fedora SUCCESS in 41m 05s
✔️ system-test-fedora-rawhide-runtime-environment-ubuntu SUCCESS in 9m 06s
❌ system-test-fedora-42-commands-options FAILURE in 1h 21m 48s
✔️ system-test-fedora-42-runtime-environment-arch-fedora SUCCESS in 1h 06m 28s
✔️ system-test-fedora-42-runtime-environment-ubuntu SUCCESS in 17m 29s
❌ system-test-fedora-41-commands-options FAILURE in 1h 27m 22s
✔️ system-test-fedora-41-runtime-environment-arch-fedora SUCCESS in 1h 07m 47s
✔️ system-test-fedora-41-runtime-environment-ubuntu SUCCESS in 17m 54s

debarshiray

Thanks for continuing to update your branch, and especially the tests!

Other than some nitpicky details, I have one comment about prompting the user. See below.

debarshiray · 2025-09-12T00:19:09Z

test/system/111-upgrade.bats

+
+@test "upgrade(Arch): Upgrade Arch container" {
+  create_distro_container arch latest arch-toolbox-test
+  assert_success


Is it really necessary to use assert_success here? It's supposed to be used to check the exit code of the command invoked by the run helper.

When we only need to check that a command succeeded, there's no need to use run or check anything, because Bats sets set -e for all tests and the test will automatically fail.

debarshiray · 2025-09-12T00:24:01Z

src/cmd/upgrade.go

+	}
+
+	if !upgradeAll && upgradeContainer == "" {
+		return errors.New("must specify either --all or a container name")


We should show:

Error: missing argument for "upgrade" Run 'toolbox --help' for usage.

... as we do for the other commands. eg., see src/cmd/rm.go

debarshiray · 2025-09-12T00:29:57Z

doc/toolbox-upgrade.1.md

+toolbox-upgrade - Upgrade packages in Toolbx containers
+
+## SYNOPSIS
+**toolbox upgrade** [*--all* | *-a*] [*--container* | *-c* *CONTAINER*] [*CONTAINER*]


Don't you want to support specifying multiple containers by name:

$ toolbox upgrade CONTAINER1 CONTAINER2

The rm and rmi commands support that.

debarshiray · 2025-09-12T00:35:57Z

src/cmd/upgrade.go

+
+	inspectedcontainer, err := podman.InspectContainer(container)
+	if err != nil {
+		return errors.New("Failed to inspect Metadata.")


The error should be:

fmt.Errorf("failed to inspect container %s", container)

... as is used elsewhere in the code base.

debarshiray · 2025-09-12T00:44:41Z

src/cmd/upgrade.go

+	labels := inspectedcontainer.Labels()
+	pkgline := labels["com.github.containers.toolbox.package-manager.update"]
+	if pkgline == "" {
+		return errors.New("'com.github.containers.toolbox.package-manager.update' Label not set in Containers Metadata.")


We need an error message that a user, who doesn't know about the internal implementation details, can understand and suggests how to move forward. :)

Something like:

Error: container CONTAINER does not support "upgrade" Recreate it with a newer image or file a bug.

debarshiray · 2025-09-12T00:54:58Z

src/cmd/upgrade.go

+			"",
+			"",
+			0,
+			[]string{"sh", "-c", pkgline},


I was thinking about this over the past few weeks in the context of the NVIDIAScape security issue, and it struck me that someone can trick a user into using a malicious image that contains a harmful command in its c.gh.containers.toolbx.package-manager.update label.

It will be wise to prompt the user with the command that will be run before running it. The user can use the --assumeyes if they want to override the prompt. Look for the askForConfirmation function for an existing example of this.

This makes me wonder if we should have variants of the c.gh.containers.toolbx.package-manager.update label that use an assume yes option for the package manager and don't. It will be bad if a dnf --assumeyes upgrade breaks the container without giving the user a way to opt out of it as usual.

Immediately after I submitted the comment, it struck me that a malicious image can already trick Toolbx into doing bad things.

Such as, the entry point of Toolbx containers rely on the mount(8) binary. So, if there's an image that has replaced that binary with something else, then toolbox enter can lead to bad things.

We could re-implement the parts of mount(8) that Toolbx needs in Go to avoid this, but then someone can replace the bash(1) binary with something else, and so on.

So, I suppose, the security argument doesn't really hold?

Even then, maybe we should offer a prompt and show what's about to happen just for the sake of politeness? Just like we do before downloading an image.

I am still wondering if this means we should have a prompt before the package manager is invoked, or after it's invoked but before the packages are downloaded and changed, or both.

Probably the best approach would be to tell the user the update command then prompt them and if the user wants via a flag skip it but by default they will be told about it.
And to be honest we should probably have a vetted compatibility list like distrobox.

Probably the best approach would be to tell the user the update command then prompt them and if the user wants via a flag skip it but by default they will be told about it.

You mean prompting the user both before and after invoking the package manager? ie., prompting the user that dnf upgrade will be called, then prompting the user to proceed with what dnf upgrade wants to do?

I suspect we could avoid the first prompt and only inform the user that dnf upgrade is going to be run, if we are sure that it won't generate a lot of network traffic. Otherwise, it will be bad for users with limited Internet connectivity.

I am beginning to think that having too many prompts is annoying, and it's better than the alternative of potentially rudely surprising the users by not letting them have a say.

And to be honest we should probably have a vetted compatibility list like distrobox.

How do you want to implement that?

The first step for declaring full support for an OS is to run the CI on hosts with that OS, which isn't a trivial task. Do you want to skip the upgrade command for those that are on the compatibility list?

I think it makes sense to have a confirmation prompt before running the package manager if the command has some kind of --assumeyes argument. If it doesn't, then confirmation can happen after invocation.

Foxboron · 2025-09-12T07:24:00Z

images/arch/Containerfile

 FROM docker.io/library/archlinux:base-devel

 LABEL com.github.containers.toolbox="true" \
+      com.github.containers.toolbox.package-manager.update="sudo pacman -Syu --noconfirm" \


The issue is that this is not going to work that reliably. pacman is going to prompt for some resolutions and that will lock things up. You could run something along the lines of sudo sh -c 'yes | pacman -Syu --noconfirm' but you might end up in a situation where the keyring is sufficiently outdated for this to work.

sudo sh -c 'sudo pacman -Sy archlinux-keyring; yes | pacman -Su --noconfirm'

or similar could work but there is no guarantees as Arch Linux is not built around the assumptions that unattended upgrades are supported.

I see, interesting. Thanks for that insight, @Foxboron

In that case, my vote is to not add the label to the arch-toolbox image, and leave it as explicitly unsupported. It's better to not advertise things to users that are not meant to work.

silverhadch · 2025-09-12T07:34:36Z

@debarshiray @Foxboron
Thanks for the Feedback once i finished migrating my System to NixOS, i will apply the suggestions.

silverhadch requested a review from debarshiray as a code owner July 14, 2025 12:03

debarshiray requested changes Jul 23, 2025

View reviewed changes

debarshiray mentioned this pull request Jul 23, 2025

Remind users about software updates #580

Open

silverhadch force-pushed the kde-kontainer-upgrade branch from 5d98d38 to 403527c Compare July 27, 2025 19:13

silverhadch requested a review from debarshiray July 28, 2025 15:02

debarshiray reviewed Aug 12, 2025

View reviewed changes

src/cmd/utils.go Outdated Show resolved Hide resolved

silverhadch requested review from Foxboron and Jmennius as code owners August 15, 2025 07:19

silverhadch requested a review from debarshiray August 15, 2025 07:36

silverhadch added 6 commits August 18, 2025 20:50

Add Upgrade Functionality

729e7e8

Signed-off-by: Hadi Chokr <[email protected]>

Add missing sudo calls.

3d8efa0

Signed-off-by: Hadi Chokr <[email protected]>

No Flag Container

2193cff

Signed-off-by: Hadi Chokr <[email protected]>

Use Metadate instead

e0568a6

Signed-off-by: Hadi Chokr <[email protected]>

Update Docs.

fc77ef4

Signed-off-by: Hadi Chokr <[email protected]>

Update utils.go

9a22e47

Signed-off-by: Hadi Chokr <[email protected]>

silverhadch added 8 commits August 18, 2025 20:50

Add Label to Arch Toolbx

9129f1d

Signed-off-by: Hadi Chokr <[email protected]>

Add Label to Ubuntu 25.04

9d52ebb

Signed-off-by: Hadi Chokr <[email protected]>

Add Label to Ubuntu 24.04 LTS

7135809

Signed-off-by: Hadi Chokr <[email protected]>

Add Label to Ubuntu 24.10

25e6a57

Signed-off-by: Hadi Chokr <[email protected]>

Create 111-upgrade.bats

ed07005

Signed-off-by: Hadi Chokr <[email protected]>

Update meson.build

8545d43

Signed-off-by: Hadi Chokr <[email protected]>

Update 111-upgrade.bats

b8988e5

Signed-off-by: Hadi Chokr <[email protected]>

Improve Tests.

61e54a6

Signed-off-by: Hadi Chokr <[email protected]>

silverhadch force-pushed the kde-kontainer-upgrade branch from 25d04bd to 61e54a6 Compare August 18, 2025 17:50

debarshiray requested changes Sep 12, 2025

View reviewed changes

Foxboron reviewed Sep 12, 2025

View reviewed changes

silverhadch mentioned this pull request Sep 21, 2025

Feature Request: Support for Fedora Toolbox in BoxBuddy Dvlv/BoxBuddyRS#171

Closed

Uh oh!

Add Upgrade Functionality #1683

Are you sure you want to change the base?

Add Upgrade Functionality #1683

Uh oh!

Conversation

silverhadch commented Jul 14, 2025

toolbox upgrade: Add package manager detection and upgrade capability

Key Features

Supported Package Managers

Usage Examples

Implementation Details

Uh oh!

softwarefactory-project-zuul bot commented Jul 14, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jul 17, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jul 19, 2025

Uh oh!

debarshiray left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

debarshiray Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

silverhadch commented Jul 23, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jul 27, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jul 28, 2025

Uh oh!

silverhadch commented Jul 28, 2025

Uh oh!

softwarefactory-project-zuul bot commented Jul 28, 2025

Uh oh!

silverhadch commented Aug 8, 2025

Uh oh!

debarshiray left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

softwarefactory-project-zuul bot commented Aug 13, 2025

Uh oh!

silverhadch commented Aug 15, 2025

Uh oh!

softwarefactory-project-zuul bot commented Aug 15, 2025

Uh oh!

softwarefactory-project-zuul bot commented Aug 15, 2025

Uh oh!

silverhadch commented Aug 16, 2025

Uh oh!

softwarefactory-project-zuul bot commented Aug 16, 2025

Uh oh!

softwarefactory-project-zuul bot commented Aug 18, 2025

Uh oh!

debarshiray 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!

debarshiray left a comment •

edited

Loading

debarshiray Sep 12, 2025 •

edited

Loading