dinitctl: show the service path in the "status" command output by mobin-2008 · Pull Request #550 · davmac314/dinit

mobin-2008 · 2026-05-31T12:38:16Z

Use the existing functionality to show the service path of currently loaded service.

Fixes #508

davmac314 · 2026-06-01T10:36:15Z

Someone was already working on this (#511). It does look like that effort stalled, but could you confirm with them please before we proceed with this new PR, out of politeness.

It would be good if you could communicate what you are intending to work on before you start doing it, that will help avoid this sort of situation.

mobin-2008 · 2026-06-01T22:43:09Z

Someone was already working on this (#511). It does look like that effort stalled, but could you confirm with them please before we proceed with this new PR, out of politeness.

I asked him and I'm waiting for his response.

It would be good if you could communicate what you are intending to work on before you start doing it, that will help avoid this sort of situation.

Yes. I should did more than assigning issue (#508) to myself.

davmac314 · 2026-06-02T01:09:04Z

Let's give it 3 days to wait for an answer. In the meantime, can you please close this PR and re-open after that time (I assume you have properly self-reviewed, if not please do that before re-opening).

mobin-2008 · 2026-06-10T20:49:30Z

I forgot to reopen this PR before force pushing my branch :(
I need to open another PR.
@davmac314 Is that OK?

davmac314 · 2026-06-10T22:06:49Z

Create a new branch from your current one (dinit_show_service_dir) as a backup, do a hard reset on dinit_show_service_dir to the commit 4a646c595af27fe98f0c381fe2ea13feea78484f, force-push, re-open the PR, then do a hard reset to the backup branch.

davmac314 · 2026-06-11T08:30:59Z

As per the contribution guide, you should specify what testing has been done when opening a PR. Can you do that now please?

Can you also confirm that you're otherwise following the process, and have self-reviewed?

mobin-2008 · 2026-06-11T09:55:48Z

As per the contribution guide, you should specify what testing has been done when opening a PR. Can you do that now please?

Changes tested against these cases:

$ src/dinitctl status kanshi
Service: kanshi (/home/mobin/.config/dinit.d/kanshi)
    State: STARTED
    Activation: start due to dependent(s)
    Process ID: 19268

$ src/dinitctl status boot
Service: boot (/run/turnstiled/1000/srv.1229/boot)
    State: STARTED
    Activation: explicitly started

# src/dinitctl status logger@kmsg
Service: logger@kmsg (/etc/dinit.d/logger)
    State: STARTED
    Activation: start due to dependent(s)
    Process ID: 606

Can you also confirm that you're otherwise following the process, and have self-reviewed?

Yes.

davmac314 · 2026-06-11T10:23:40Z

Can you also confirm that you're otherwise following the process, and have self-reviewed?

Yes.

It seems like you just pushed changes after opening the PR - that's not the process, and we've talked about that before! - and yet you are now saying, just a few minutes later, that you are following the process.

Please read the CONTRIBUTING and PR-PROCESS guides, in full. This is the last time I will allow you grace for this..

davmac314 · 2026-06-11T10:31:57Z


-    // Issue STATUS request
    {
+        // Prepare to show the service path in the output later down


"Service path" isn't a thing. You're talking about a service description file path. Don't make up terminology please.

Two questions:

"Prepare to show" is not clear. What is this code actually doing?

Why do you feel the output "later down" is significant enough that it needs to be mentioned here?

"Service path" isn't a thing. You're talking about a service description file path. Don't make up terminology please.

OK. Will be fixed.

Two questions:

* "Prepare to show" is not clear. What is this code actually doing?

It's preparing a variable (service_path) to be used for showing the service path in the output later down. The code shows how this preparation works.

* Why do you feel the output "later down" is significant enough that it needs to be mentioned here?

Because it feels weird to me that there is a random get_service_description_dir before issuing STATUS. This is here to mention it's going to be used for showing the service path in the output later down the code and you need to keep looking for its usage.

It's preparing a variable (service_path) to be used for showing the service path in the output later down.

What does "preparing" mean in this case? (Also, can you explain it without referring to a variable? Variables are everywhere and I can see the variables in the code).

The code shows how this preparation works.

It shouldn't be necessary to read the code to understand what a comment means. The comment is supposed to explain the code, not the other way around.

What is the specific purpose of the comment here? Eg Is it explaining something that you think is difficult to understand, or is it just summarising what the following section of code does to help navigating the code, or something else?

This is here to mention it's going to be used for showing the service path in the output later down the code and you need to keep looking for its usage

Isn't that normal though? There are heaps of places where some value is determined so that it can be used later - that's basically every variable assignment! - so does it really need to be explained in the comment? Do you see any other comments that do that?

Because it feels weird to me that there is a random get_service_description_dir before issuing STATUS

The comment doesn't explain why get_service_description_dir is called at all, though.

Sorry, that's a bit of an overload of questions. Can we focus on these for now:

What does "preparing" mean in this case?

("Preparing a variable" means nothing to me. What do you mean exactly?)

and

What is the specific purpose of the comment here? Eg Is it explaining something that you think is difficult to understand, or is it just summarising what the following section of code does to help navigating the code, or something else?

("Preparing a variable" means nothing to me. What do you mean exactly?)

The original comment was this:

// Get the service description directory to show the service path in the output later down

I thought it is a bad idea to repeat what the code does in this comment, so I replaced it with "prepare" which is also bad, because everything up to the issuing the STATUS request is just preparation.

What is the specific purpose of the comment here? Eg Is it explaining something that you think is difficult to understand, or is it just summarising what the following section of code does to help navigating the code, or something else?

To be faithful to the style of this function, I thought it needs a comment explaining the section below. I mean it does

just summarising what the following section of code does to help navigating the code

but now I think it doesn't need to a comment explaining it, I just misunderstood the style.

I thought it is a bad idea to repeat what the code does in this comment

It is fine to explain what a block of code does (at a slightly higher level than the code itself) with a comment.

If the comment is summarising the section of code though, then it should focus on what this section of code does, not non-specific things such as that it is "preparing" something "to be output later down". Those words (quoted) don't give any useful information to someone reading the comment.

but now I think it doesn't need to a comment explaining it

It is fine and good to have a comment here, that summarises what the code is doing. That is why I asked: what does this code actually do? (I know what it does - but I want you to explain it, in a way that would be useful as a comment).

So again: what does this code actually do?

So again: what does this code actually do?

It ~~constructs~~ resolves the service description path.

Yes. This would make a reasonable comment; "constructs" is ok (but a little ambiguous because constructing an object is a thing, and that's not really what is meant). "resolves" is also ok, but also has ambiguity because "resolve" has a special meaning with file paths (see https://stackoverflow.com/questions/67187401/what-exactly-does-it-mean-to-resolve-a-path). I would personally use "determines".

davmac314 · 2026-06-11T10:34:08Z

        }

-        cout << "Service: " << service_name << "\n"
+        cout << "Service: " << service_name << " (" << service_path << ")" << "\n"


Don't output it here. Output it with an appropriate heading (maybe 'File:') as with other status elements.

Feature design should really be discussed before working on it - that's also part of the documented process.

I think adding File is good.

It would also have been a good idea to check whether the file is up-to-date and report if not, much like dinitctl start now does.

It would also have been a good idea to check whether the file is up-to-date and report if not, much like dinitctl start now does.

How to display it? Using the same message like in start? On top of status output or after writing entries?

Also something funny happened when testing it. I setup a minimal dinit.d:

$ ls /tmp/dinit.d/ boot srv $ cat /tmp/dinit.d/* type = internal waits-for: srv type = process command = /usr/bin/sleep infinity #ldaskd kas

Then I tried to hit the message for modified service but I didn't. I straced the dinitctl call and saw something funny:

$ strace dinitctl -p /tmp/dinit.sock start srv ... socket(AF_UNIX, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_UNIX, sun_path="/tmp/dinit.sock"}, 18) = 0 write(3, "\0", 1) = 1 read(3, ":\1\0\6\0", 1024) = 5 write(3, "\2\3\0srv", 6) = 6 read(3, ";\2\0\0\0\0\2", 1019) = 7 write(3, "\26\0\0\0\0\0", 6) = 6 read(3, "M\10\0\0\0dinit.d/", 1012) = 13 newfstatat(AT_FDCWD, "dinit.d//srv", 0x7fff483c41c0, 0) = -1 ENOENT (No such file or directory) write(3, "\3\0\0\0\0\0", 6) = 6 read(3, "=", 999) = 1 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0 write(1, "Service (already) started.\n", 27Service (already) started. ) = 27 exit_group(0) = ? +++ exited with 0 +++

I ran Dinit as dinit -d dinit.d/ -p dinit.sock. I shouldn't specify a relative path as services directory ~~with trailing slash~~ or this is a bug that needs to be fixed?

I shouldn't specify directory with trailing slash or this is a bug that needs to be fixed?

~~A little of both. Can you open an issue please.~~

Sorry, I misunderstood you. No, this is not an error. The problem is not that you specified a trailing slash (multiple slashes are allowed between path components), it is that you used a relative path. Perhaps that should be made to work, let me think on it.

(But, it is not something you need to consider for this PR. Please proceed and process in the same way that dinitctl start does).

How to display it? Using the same message like in start?

In start it's a warning specifically because the user may have forgotten to reload the service and as a result the original version of the service description will be used instead to start the service. That doesn't apply here so I don't understand why we would use the same message.

On top of status output

What do you mean by that?

or after writing entries?

I think it makes sense to keep the information with the filename, either on the same line or just after.

What do you mean by that?

I mean something like this:

Note: service description may have changed; use 'dinitctl reload srv' to apply changes. Service: srv File: /tmp/dinit.d//srv State: STARTED Activation: start due to dependent(s) Process ID: 25183

I think it makes sense to keep the information with the filename, either on the same line or just after.

So something like this?

Service: srv File: /tmp/dinit.d//srv Note: service description may have changed; use 'dinitctl reload srv' to apply changes. State: STARTED Activation: start due to dependent(s) Process ID: 25183

So something like this?

No, as I said earlier:

In start it's a warning specifically because the user may have forgotten to reload the service and as a result the original version of the service description will be used instead to start the service. That doesn't apply here so I don't understand why we would use the same message.

What you posted above isn't substantially different from the warning that dinitctl start prints.

The modification status is part of the status. So display it as part of the status. " (modified since loaded)" after the filename would do it, for example. Or suitable information on the next line, as part of the status, not as some "note".

davmac314 · 2026-06-11T10:38:48Z

Please answer questions above and then I will complete the review.

mobin-2008 · 2026-06-16T15:56:01Z

that's not the process, and we've talked about that before! - and yet you are now saying, just a few minutes later, that you are following the process.

Feature design should really be discussed before working on it - that's also part of the documented process.

Now I see how half-baked this PR is, I try my best to fix it. I answered your questions and also asked a question for better understanding the current design. If the feedback is still negative, I would mark this PR as draft until it gets to the point of being up to the standard.

davmac314 · 2026-06-16T21:58:52Z

Now I see how half-baked this PR is, I try my best to fix it. I answered your questions

There's still a question pending - see above.

Once that's resolved I'll complete the review. Thanks.

davmac314 · 2026-06-18T22:12:35Z

+        const char *at_ptr = strchr(service_name, '@');
+        if (at_ptr != nullptr) {
+            service_base_name = string_view(service_name, static_cast<size_t>(at_ptr - service_name));
+        }


The strip_service_arg function already exists; use it instead of replicating the functionality.

davmac314 · 2026-06-18T22:15:47Z

        }

-        cout << "Service: " << service_name << "\n"
+        cout << "Service: " << service_name << " (" << service_path << ")" << "\n"


It would also have been a good idea to check whether the file is up-to-date and report if not, much like dinitctl start now does.

davmac314 · 2026-06-18T22:18:25Z

 {
    using std::cout;
    using std::cerr;
+    using std::string;


I wouldn't normally add using for a class that's only used a handful of times.

davmac314 · 2026-06-18T22:20:04Z

Ok, I've completed the review, please make changes and push once ready (after self-review).

mobin-2008 · 2026-06-22T19:21:15Z

~~I applied all the suggested fixes, added a check for modified service descriptions and self-reviewed the changes. Changes are tested against these cases:~~
Sorry for the noise. I just realised that it's not ready for review. Please don't start the review process.

$ src/dinitctl status kanshi
Service: kanshi
    File: /home/mobin/.config/dinit.d/kanshi
    State: STARTED
    Activation: start due to dependent(s)
    Process ID: 1368

$ src/dinitctl status boot
Service: boot
    File: /run/turnstiled/1000/srv.1224/boot (modified since loaded)
    State: STARTED
    Activation: explicitly started

# src/dinitctl status logger@kmsg
Service: logger@kmsg
    File: /etc/dinit.d/logger
    State: STARTED
    Activation: start due to dependent(s)
    Process ID: 589

mobin-2008 · 2026-06-24T11:10:56Z

Sorry for the noise. I just realised that it's not ready for review. Please don't start the review process.

There was a problem because of how I reviewed commits (git diff HEAD~2), the second commit introduced a logic that should be a part of first commit and only be expanded in the second commit.

I applied all the suggested fixes, added a check for modified service descriptions (see the new commit) and self-reviewed the changes. Changes are tested against these cases:

$ src/dinitctl status kanshi
Service: kanshi
    File: /home/mobin/.config/dinit.d/kanshi
    State: STARTED
    Activation: start due to dependent(s)
    Process ID: 1440

$ src/dinitctl status boot
Service: boot
    File: /run/turnstiled/1000/srv.1297/boot (modified since loaded)
    State: STARTED
    Activation: explicitly started

# src/dinitctl status logger@kmsg
Service: logger@kmsg
    File: /etc/dinit.d/logger
    State: STARTED
    Activation: start due to dependent(s)
    Process ID: 587

davmac314

Commit messages:

Also use the newer "SERVICESTATUS6" protocol request if daemon supports
it

Don't drop articles (in "if daemon").
This isn't the point of the change. If you're explaining an implementation detail that was necessary for the change, then make that clear with appropriate language.

Add a "File" field to service status showing the path of the service
description file for the currently loaded service.

Don't drop articles (in "to service status").
Remove redundant/implicit/obvious information ("for the currently loaded service")

davmac314 · 2026-06-24T23:03:27Z

+        // Check the service description file hasn't changed. We already located said file, so stat
+        // it to find the modification time, then compare that with the modification time according
+        // to dinit.


Nit: You've basically copied the comment from start_stop_service, but this is a different context.

In that context a few things need to be done to do the modification check: locate the service file (get the service directory and append the service name), issue a SERVICESTATUS6 request, and then check the file time. That's why the comment is more than just a single line.

In this context, the code block is nice and short and doesn't need the same level of explanation.

You don't have to change this, but in future please don't blindly take comments from elsewhere. It's much better if you try to come up with a reasonable comment yourself, I think practicing that would be worthwhile.

I don't change this and I will try to come up with a reasonable comment myself next time.

davmac314 · 2026-06-24T23:04:47Z

+                if (dinit_sdf_time.tv_sec != file_time.tv_sec
+                        || dinit_sdf_time.tv_nsec != file_time.tv_nsec) {
+                    sdf_has_changed = true;


sdf_has_changed = dinit_sdf_time.tv_sec != ...(etc)

you don't need if here.

davmac314 · 2026-06-25T00:03:45Z

-        unsigned status_buf_size = proto_version < 5 ? STATUS_BUFFER_SIZE : STATUS_BUFFER5_SIZE;
+        // Determine the service description path
+        std::string sdf_path;
+        if (proto_version >= 3) {


There's no need to deal with protocol versions before 3, that's ridiculously old now.

davmac314 · 2026-06-25T00:29:50Z

+        char status_req_id;
+        unsigned status_buf_size;
+        switch (proto_version) {
+            case 6:
+                status_req_id = (char)cp_cmd::SERVICESTATUS6;
+                status_buf_size = STATUS_BUFFER6_SIZE;
+                break;
+            case 5:
+                status_req_id = (char)cp_cmd::SERVICESTATUS5;
+                status_buf_size = STATUS_BUFFER5_SIZE;
+                break;
+            default:
+                status_req_id = (char)cp_cmd::SERVICESTATUS;
+                status_buf_size = STATUS_BUFFER_SIZE;
+                break;
+        }


You don't need 16 lines of code for this. It was 2 previously, it shouldn't be much more than that.

This doesn't correctly handle future protocol versions (7+), it's going to fall back to pre-5 status in those cases. (That corresponds to dinit-0.18.0, which we don't really need to support any more anyway, though there is support elsewhere in the code so it's good to be consistent for now).

davmac314 · 2026-06-25T00:41:08Z

+        std::string sdf_path;
+        if (proto_version >= 3) {
+            std::string sd_dir = get_service_description_dir(socknum, rbuffer, handle);
+            std::string service_base_name = string_view(service_name,


Don't allocate a string unnecessarily

davmac314 · 2026-06-25T00:41:18Z

+        if (proto_version >= 3) {
+            std::string sd_dir = get_service_description_dir(socknum, rbuffer, handle);
+            std::string service_base_name = string_view(service_name,
+                    static_cast<size_t>(strip_service_arg(service_name) - service_name));


Surely this cast isn't needed?

I don't think so but regardless, I removed the additional strings and by using the std::string::append(const char *__first, const char *__last) the whole subtraction can be removed.

davmac314 · 2026-06-25T00:49:07Z

+            if (sdf_has_changed) {
+                cout << " (modified since loaded)";
+            }


condense to one line

Add a "File" field to the service status showing the path of the service description file. Addresses davmac314#508

mobin-2008 · 2026-06-25T21:17:10Z

Fixed the commit messages, applied the requested changes and self-reviewed the changes.

Changes are tested against these cases:

$ src/dinitctl status kanshi
Service: kanshi
    File: /home/mobin/.config/dinit.d/kanshi
    State: STARTED
    Activation: start due to dependent(s)
    Process ID: 1353

$ src/dinitctl status boot
Service: boot
    File: /run/turnstiled/1000/srv.1207/boot (modified since loaded)
    State: STARTED
    Activation: explicitly started

# src/dinitctl status logger@kmsg
Service: logger@kmsg
    File: /etc/dinit.d/logger
    State: STARTED
    Activation: start due to dependent(s)
    Process ID: 589

davmac314 · 2026-06-25T23:49:18Z

Changes are tested against these cases:

You don't have to say this each time, especially when you are just repeating what you said before. The testing details are supposed to be in the PR summary.

davmac314

Also use the newer "SERVICESTATUS6" protocol request if daemon supports it

Don't drop articles (in "if daemon").

This isn't the point of the change. If you're explaining an implementation detail that was necessary for the change, then make that clear with appropriate language.

The 2nd point wasn't addressed. It still says exactly what I quoted above (except that the "the" article has been added as per first point, thanks).

This change wasn't "also". It was fundamental to the main change.

davmac314 · 2026-06-25T23:53:20Z

+        char status_req_id = (proto_version >= 6) ? (char)cp_cmd::SERVICESTATUS6
+                : (proto_version == 5) ? (char)cp_cmd::SERVICESTATUS5
+                : (char)cp_cmd::SERVICESTATUS;


Use extra parentheses (/) to make the expression more clear. Same below.

davmac314 · 2026-06-25T23:56:52Z

+        cout << "\n";
+        cout << "    State: ";


Combine into one line, there's no need to output two literal strings one after the other, just output a single literal string.

Show "(modified since loaded)" at the end of the "File" field when the service description file has changed since it was loaded. Use the newer "SERVICESTATUS6" protocol request to implement this feature. This is required to get the modification time of the service description file when dinit loaded the service. Fallback to the older protocol requests when the daemon doesn't support the newer.

mobin-2008 · 2026-06-26T00:26:52Z

The 2nd point wasn't addressed. It still says exactly what I quoted above (except that the "the" article has been added as per first point, thanks).

I think this new push does address your point. I removed the "also" and made it clear that it's used for implementing this feature.

davmac314

Commit comment:

Fallback to the older protocol requests when the daemon doesn't support the newer.

newer one.

Given that the commit message is supposed to be focusing on the functional change, this talk of fallback to older protocol should really have some sort of explanation of what the functional effect of this fallback actually is.

davmac314 · 2026-06-26T01:09:50Z

+        char status_req_id = ((proto_version >= 6) ? (char)cp_cmd::SERVICESTATUS6
+                : (proto_version == 5) ? (char)cp_cmd::SERVICESTATUS5
+                : (char)cp_cmd::SERVICESTATUS);
+        unsigned status_buf_size = ((proto_version >= 6) ? STATUS_BUFFER6_SIZE
+                : (proto_version == 5) ? STATUS_BUFFER5_SIZE : STATUS_BUFFER_SIZE);


This is not what I meant. I'm struggling to understand why you put the parentheses where you did.

Adding parentheses around the whole expression doesn't make it easier to understand - just adding '(' at the beginning of a complicated expression, and ')' at the end of it, doesn't make it clearer, it just adds noise.

The parentheses around the conditions aren't really useful either. They're not complicated conditions.

The original expression was:

unsigned status_buf_size = (proto_version >= 6) ? STATUS_BUFFER6_SIZE : (proto_version == 5) ? STATUS_BUFFER5_SIZE : STATUS_BUFFER_SIZE;

That's a double ? : operator combination and you need to make clear which parts are which and how the operands bind (i.e. the associativity). The expression is particularly unclear to anyone who is uncertain of the precedence/associativity of the '? :' operator.

Use parentheses to make the precedence/binding clear. That means, in this case, put them around the second '? :' subexpression, i.e. the 2nd alternative to the first '? :'. Then you're removing the syntactic ambiguity, and allowing to easily identify the two alternatives for the first operator without having to mentally parse the expression.

If you didn't understand this, then ask (as you should've asked if you didn't understand in the first place).

mobin-2008 added A-Importance: Normal Enhancement/New Feature Improving things or introduce new feature C-dinitctl Things about dinitctl labels May 31, 2026

mobin-2008 closed this Jun 2, 2026

mobin-2008 mentioned this pull request Jun 4, 2026

Let dinitctl print service file path #511

Closed

mobin-2008 reopened this Jun 10, 2026

mobin-2008 force-pushed the dinit_show_service_dir branch from 4a646c5 to d03c4d5 Compare June 10, 2026 22:12

mobin-2008 force-pushed the dinit_show_service_dir branch from d03c4d5 to c4be545 Compare June 11, 2026 09:55

davmac314 reviewed Jun 11, 2026

View reviewed changes

mobin-2008 commented Jun 16, 2026

View reviewed changes

Comment thread src/dinitctl.cc

davmac314 requested changes Jun 18, 2026

View reviewed changes

mobin-2008 mentioned this pull request Jun 19, 2026

dinitctl service description file access can fail if service directory is not absolute path #557

Closed

mobin-2008 force-pushed the dinit_show_service_dir branch from c4be545 to 6964af8 Compare June 22, 2026 19:21

mobin-2008 force-pushed the dinit_show_service_dir branch from 6964af8 to e1598a0 Compare June 24, 2026 11:10

davmac314 requested changes Jun 25, 2026

View reviewed changes

dinitctl: show the service description file path in service status

3884e89

Add a "File" field to the service status showing the path of the service description file. Addresses davmac314#508

mobin-2008 force-pushed the dinit_show_service_dir branch from e1598a0 to 57afa42 Compare June 25, 2026 21:17

davmac314 requested changes Jun 26, 2026

View reviewed changes

mobin-2008 force-pushed the dinit_show_service_dir branch from 57afa42 to 79e39e3 Compare June 26, 2026 00:26

mobin-2008 mentioned this pull request Jun 26, 2026

Reintrodoucing FreeBSD CI #558

Open

davmac314 requested changes Jun 27, 2026

View reviewed changes

Uh oh!

Conversation

mobin-2008 commented May 31, 2026

Uh oh!

davmac314 commented Jun 1, 2026

Uh oh!

mobin-2008 commented Jun 1, 2026

Uh oh!

davmac314 commented Jun 2, 2026

Uh oh!

mobin-2008 commented Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davmac314 commented Jun 10, 2026

Uh oh!

davmac314 commented Jun 11, 2026

Uh oh!

mobin-2008 commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davmac314 commented Jun 11, 2026

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!

mobin-2008 Jun 16, 2026 • 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!

mobin-2008 Jun 18, 2026 • 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!

Choose a reason for hiding this comment

Uh oh!

mobin-2008 Jun 18, 2026 • 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!

davmac314 Jun 18, 2026 • 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!

davmac314 commented Jun 11, 2026

Uh oh!

Uh oh!

mobin-2008 commented Jun 16, 2026

Uh oh!

davmac314 commented Jun 16, 2026

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!

davmac314 commented Jun 18, 2026

Uh oh!

mobin-2008 commented Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mobin-2008 commented Jun 10, 2026 •

edited

Loading

mobin-2008 commented Jun 11, 2026 •

edited

Loading

mobin-2008 Jun 16, 2026 •

edited

Loading

mobin-2008 Jun 18, 2026 •

edited

Loading

mobin-2008 Jun 18, 2026 •

edited

Loading

davmac314 Jun 18, 2026 •

edited

Loading

mobin-2008 commented Jun 22, 2026 •

edited

Loading

mobin-2008 Jun 25, 2026 •

edited

Loading

davmac314 commented Jun 25, 2026 •

edited

Loading

davmac314 left a comment •

edited

Loading