stdenv: add meta.repository field by lolbinarycat · Pull Request #294347 · NixOS/nixpkgs

lolbinarycat · 2024-03-08T20:17:32Z

Description of changes

the new meta.repository will, by default (i.e. unless it is specified manually by the package), pull its value from src.meta.homepage, which is set by fetchFromGitHub and other fetchFrom* functions. if this cannot be found, it will be set to null.

rationale for name: chosen to make sense if added to search.nixos.org. meta.sourceCode or meta.sourceTree would make sense if not for the fact that search results already have a "Source" field which points to the location of the package.nix file in nixpkgs.

Things done

checked that the meta field is readable for packages built with stdenv and rustPlatform.buildRustPackage
checked that the meta field correctly defaults to null for packages that use fetchzip
checked that derivations are not changed, so this PR will not cause any rebuilds

Add a 👍 reaction to pull requests you find important.

lolbinarycat · 2024-03-14T22:11:55Z

@Mindavi note that meta.repository does not default to meta.homepage, it defaults to src.meta.homepage, which is automatically set by fetchers such as fetchFromGitHub to point to the source repository.

setting meta.homepage will not affect meta.repository

AndersonTorres · 2024-03-15T22:32:44Z

doc/stdenv/meta.chapter.md

Not every repository is HTTP(S)-browsable.
Indeed FTPs were a very common thing some short time ago, and there are projects of hosting forges on I2P networks.

Further, automatically filling this attribute is not a good idea. It should be explicitly set when desired.

Suggested change

HTTP-browsable source tree of the package. Automatically set if the package uses a `fetchFrom*` fetcher for its `src`. Example: `https://github.com/forthy42/gforth`

Source repository of the package.

Examples:

- `https://git.savannah.gnu.org/git/gforth.git`

- `https://github.com/NixOS/nixops`

- `https://nest.pijul.com/pijul/pijul`

Not every repository is HTTP(S)-browsable.

no, but meta.repository is specifically for http-browsable source trees. it exists for maintainer convenience and to be displayed by sites like search.nixos.org

Why only HTTP-browsable repositories? Why such discrimination?

because this field is meant to be presented via a web browser.

would you accept a gemini or gopher link as a value for meta.homepage?

Yes, I would.

Not a long time ago browsers displayed Gopher and even FTP. They dropped this because of code base cleanup.

What will be next? Dropping non-conformant forges like viewcvs?

Further, with some hack modern web browsers can rely on extensions that allow looking at those sites.

Further, special purpose clients still exist for them.

Further, Emacs has support for them:

https://www.emacswiki.org/emacs/CategoryGopher/

https://www.emacswiki.org/emacs/AngeFtp/

@AndersonTorres could you elaborate on this?

Further, automatically filling this attribute is not a good idea. It should be explicitly set when desired.

I think this actually a great idea! When fetching from a repo, linking to that exact repo seems to be the sane thing to do, and exactly what I would expect as a user. Of course there are cases where that isn't possible (if you have multiple sources, when fetching from an unknown forge that we don't know how to translate, etc.), but those are the only ones that should be handled manually, IMO.

The other option of adding the new meta field to every single package manually results in additional (and unnecessary) maintainer load.

AndersonTorres · 2024-03-15T22:35:27Z

pkgs/development/coq-modules/serapi/default.nix

Why this change?

because without it, ofborg-eval fails due to niche consequences of lazy evaluation.

basically, evaluating meta now evaluates src, which causes problems for this package specifically.

Rewording it, your meta.eyecandy field broke Nixpkgs.

@AndersonTorres If you want your criticism to be meaningful I'd suggest not leaving it up for interpretation.

How exactly is this open to interpretation? Asking sincerely.

Creating a meta.XYZ field introduced a breaking change.
A breaking change in an otherwise completely unrelated piece of code.

How can this possibly differ from

Rewording it, your meta.eyecandy field broke Nixpkgs.

?

I don't consider useful metadata to be eye candy, that's why I'm asking for clarification.

How that relates to the field's relationship to the derivations src attribute is the actual question we should be following up.

I don't consider useful metadata to be eye candy, that's why I'm asking for clarification.

Neither me. Indeed Aleksanaa coninced me of a similar idea.

However the arguments from this PR's creator about which values are acceptable revolve around eyecandy.
The usefulness of this new field, according to themm, is basically "only HTTP-browsable values are allowed because I want to see them on my web browser that supports only HTTP".

AndersonTorres · 2024-03-15T22:40:00Z

pkgs/stdenv/generic/check-meta.nix

As I said before, we should not rely on setting this automatically.

Since you and @Aleksanaa are arguing for including this, it should be explicitly set by the package maintainer, never inferred.

Further it should be a list of repositories, since it is very common a repo having backup mirrors.

it is clear that you are misunderstanding the point of this field.

it is not for use by update scripts, that is what src.gitRepoUrl is for.

As I said before, we should not rely on setting this automatically.

you say this, but you do not specify why.

please give an example of when setting this automatically would lead to undesired behavior. several (most?) of the meta.* fields are set automatically.

NB packagers would have to explicitly set it to null if there's no browsable repo

if there's no browsable repo, src.meta.homepage will not be set, and thus meta.repository will not be set either.

it is clear that you are misunderstanding the point of this field.

It is clear you gave no reason why this field should point to an HTTP-browsable site to begin with.

it is not for use by update scripts, that is what src.gitRepoUrl is for.

This is irrelevant.
First, nothing hinders this field to be useful for other applications besides search.nixos.org. Second, nothing should hinder this field to be used by other applications besides search.nixos.org.

Third, what is the relevance? When I said this should be made for update scripts?
I merely suggested this could be a multi-valued field, since this is a typical occurrence in nature.

As I said before, we should not rely on setting this automatically.

you say this, but you do not specify why.

please give an example of when setting this automatically would lead to undesired behavior. several (most?) of the meta.* fields are set automatically.

Behold!

It is clear you gave no reason why this field should point to an HTTP-browsable site to begin with.

it is supposed to be presented to the user via sites like search.nixos.org

therefore it should be a link that can be opened by a browser

This is irrelevant.

the existance of a similar but semantically different field is extremely relevant.

there is no reason for this field to represent a machine-readable git repository, as there is already another field that represents that.

First, nothing hinders this field to be useful for other applications besides search.nixos.org.
Second, nothing should hinder this field to be used by other applications besides search.nixos.org.

yes, that is correct. any other application that wants a human-readable, HTTP-browseable source code repository can use this field, because that is what this field represents.

Third, what is the relevance? When I said this should be made for update scripts?

yes, that is exactly the relevance

I merely suggested this could be a multi-valued field, since this is a typical occurrence in nature.

yes, while mirror repositories are common, i don't think modeling that is worth the added complexity.

most fetchers already handle mirrors in some way

having the user pick from a list of mirrors may cause confusion, needlessly clutter the UI, and make using the value more difficult

if you can show me a practical usecase where multiple values would be helpful, i can update this to allow multiple values.

some packages have multiple sources, like trellis, and thus multiple repositories.

fair enough.

mweinelt

Chances are, that with the introduction of repository, the homepage field will lead to more end-user facing documentation, which is totally fine.

But if the repository URL is now auto-computed, that means there is no actual link in the package definition to follow, which is a downgrade for the development experience.

Note that this will be the third URL in meta: homepage, downloadPage and now repository. I wonder specifically about the redundancy between downloadPage and repository.

piegamesde · 2024-03-19T16:52:27Z

Honestly, between downloadPage and repository I prefer the latter. Given that I use NixOS and can just get the software with nix-shell -p or whatever, I rarely have any need to visit a project's downloads page. However, visiting a repository is a common use case.

eclairevoyant · 2024-03-19T17:23:56Z

why this field should point to an HTTP-browsable site to begin with

The use cases I personally have are:

Checking upstream for reports of issues and perhaps fixes for the issues I run into at build-/run-time (for packaging)
Debugging issues that aren't reported (for packaging, usually)
Cursory examination of the code (as an end-user)

None of these entail any interest in contributing any code upstream, nor is it even git-specific (!) as some of the other discussion implied - projects using hg, fossil, etc. often have browsable repos as well.

Secondly, when I was new to nixpkgs, I found it fairly confusing to click "Source" on the search page and end up in nixpkgs. I guess this is how other distros (Arch, Debian) also work, it's not as if nixpkgs is unique in this regard, but it's not intuitive to necessarily show packaging concerns on the search page. And if we are doing so already, then I don't see the scope creep of showing yet another useful link with relevance to packaging (and disambiguating them properly, e.g. "nixpkgs source" vs "upstream source" or such).

But if the repository URL is now auto-computed, that means there is no actual link in the package definition to follow

I can see that, but I'd think that preferable to a bunch of PR churn (thinking back to meta.mainProgram). In that case it was far more important to ensure it was set correctly, if at all, whereas in this case of meta.repository, I'd rather not have a bunch of new PRs just to set the one field on existing packages, or even force contributors to set such a field on new packages.

if you can show me a practical usecase where multiple values would be helpful

Mirrors exist to at least increase availability; if one repo is down, I'd still like to be able to view the source.

lolbinarycat · 2024-03-19T19:49:00Z

Chances are, that with the introduction of repository, the homepage field will lead to more end-user facing documentation, which is totally fine.

But if the repository URL is now auto-computed, that means there is no actual link in the package definition to follow, which is a downgrade for the development experience.

we could set a guideline that at least one of homepage or repository has to have an actual value withing the derivation expression.

Note that this will be the third URL in meta: homepage, downloadPage and now repository. I wonder specifically about the redundancy between downloadPage and repository.

fourth, actually, changelog also exists.
downloadPage is described as "The page where a link to the current version can be found". it's not clear if that refers to binaries, source tarballs, or both. additionally, it is not widely used as far as i can tell.

lolbinarycat · 2024-03-19T20:16:48Z

@eclairevoyant

when I was new to nixpkgs, I found it fairly confusing to click "Source" on the search page and end up in nixpkgs. I guess this is how other distros (Arch, Debian) also work, it's not as if nixpkgs is unique in this regard, but it's not intuitive to necessarily show packaging concerns on the search page. And if we are doing so already, then I don't see the scope creep of showing yet another useful link with relevance to packaging (and disambiguating them properly, e.g. "nixpkgs source" vs "upstream source" or such).

this exact disambiguation is one of the reasons i didn't name it something like sourceCode.

i think if you just put an "upstream repository" link next to the links in the search results that would be fine, but i suppose that's a problem for another time.

Mirrors exist to at least increase availability; if one repo is down, I'd still like to be able to view the source.

that's certainly a nice thought in theory, but here's what would be needed to be able to use it in practice:

the repository needs to have a mirror. this is only really common for popular projects.
package maintainers need to manually add and maintain a list of available mirrors. there is mirrorsFile, but i don't think it's available at runtime.
the repository needs to go down
you need to be able to find the url of that mirror, either by manually checking the derivation file, or by it somehow being presented on serach.nixos.org (which doesn't even handle multiple homepage values currently)

is it worth the effort to do all that just so you don't have to use the wayback machine or search "PACKAGE_NAME source code mirror"?

it would be a fairly simple change to make check-meta allow multiple values, but i'm mostly concerned about the additional work that it will require in search.nixos.org (mainly in figuring out how to display multiple repos)

AndersonTorres · 2024-03-20T01:30:49Z

It is clear you gave no reason why this field should point to an HTTP-browsable site to begin with.

it is supposed to be presented to the user via sites like search.nixos.org

First, this is a backwards thinking: Nixpkgs can exist without the search engine, the search engine can't exist without Nixpkgs.

Second, what is the problem in providing a pointer to a repository that is not HTTP-reachable? Why the search engine can't return non-HTTP links as pieces of info?

There is a truckload of non-HTTP-links info already, such as licenses, descriptions, platforms...

Or should we provide an OSI link for each license and another for each broken platform?

therefore it should be a link that can be opened by a browser

Again, eycandy.
Non Sequitur. A pointer to a repository is still a point to a repository regardless the browser's capabilities of reaching and ~~eyecanding~~ rendering it.

This is irrelevant.

the existance of a similar but semantically different field is extremely relevant.

Can you follow the context of what I wrote? "This is irrelevant" is explained right below: being useful to automation scripts is not a demerit for a pointer to a repository.

there is no reason for this field to represent a machine-readable git repository, as there is already another field that represents that.

No, there is not.

Relying on src.some-obfuscated-ill-documented-field-never-intended-to-be-exported is a really bad idea.
One year ago a change in the algorithms that generated git archive tarballs caused a massive haul over the Internet: https://lwn.net/Articles/921787/

Curiously Nixpkgs was not affected because our fetchers do not deal with the archives but rather with their contents.

Hell, we have in-house examples!
The whole pkgs/data/fonts needed to be rewrote because some leaked implementation details of fetchzip changed!

yes, that is exactly the relevance

The relevance of meta.repository is helping update scripts?

yes, while mirror repositories are common, i don't think modeling that is worth the added complexity.

You can easily replicate the meta.license approach.

And, complexity? You are complaining about complexity, when you are writing such a complicated code that it broke an otherwise completely unrelated code?

1. most fetchers already handle mirrors in some way

Why are you bringing the fetchers?
Can you fix in a single subject?

Just because your meta code broke some fetcher, it does not follow we should talk about both.

2. having the user pick from a list of mirrors may cause confusion, needlessly clutter the UI, and make using the value more difficult

A user (that is indeed a programmer) that should be used to multi-valued fields?
We already have lists of maintainers, licenses and platforms, and no one complained about confusion, needless clutter, and difficulties of using the value.
The search.nixos.org webmaster is free to pick only the head of meta.repository if the "cluttering" is such a serious concern.

if you can show me a practical usecase where multiple values would be helpful, i can update this to allow multiple values.

Oh boi....

You yourself employed an unofficial mirror to GForth!

https://github.com/forthy42/gforth

Gforth mirror on GitHub (original is on Savannah)

Or what? Savannah is not eyecandy enough when compared to GitHub's bells and whistles for mentally-overloaded programmers?

https://git.savannah.gnu.org/cgit/gforth.git/

lolbinarycat · 2024-03-20T03:39:29Z

stop saying "eyecandy"

i don't care about appearances.

you keep telling me what i want, and i'm tired of it.

AndersonTorres · 2024-03-22T02:31:28Z

I want to pick some ideas tomorrow.
But I want to bring an idea that was said to me yesterday:

meta.repository is an attribute suitable for srcs, especially those made from fetchFrom.*.
The outer derivation can/should inherit it, instead of overloading src.meta.homepage.

lolbinarycat · 2024-03-22T16:03:43Z

meta.repository is an attribute suitable for srcs, especially those made from fetchFrom.*. The outer derivation can/should inherit it, instead of overloading src.meta.homepage.

i can try to make fetchFrom* set src.meta.repository in addition to src.meta.homepage, but removing an existing field seems like a great way to break existing tools.

AndersonTorres · 2024-03-24T00:42:22Z

I said nothing about removing fields. (Which is a bit ironic!)

But this is irrelevant - you are not convinced about defining meta.repositories as a list while you are still using an unofficial mirror as an example...

lolbinarycat · 2024-03-24T00:47:21Z

ok so instead of meta.repository = src.meta.homepage, you want meta.repository = src.meta.repository = src.meta.homepage?

AndersonTorres · 2024-03-24T00:51:55Z

ok so instead of meta.repository = src.meta.homepage, you want meta.repository = src.meta.repository = src.meta.homepage?

meta.repository = src.meta.repository should suffice.

lolbinarycat · 2024-03-24T01:57:44Z

ok, but src.meta.repository does not currently exist.

as i understand it, you want to introduce it as a new field that will have a value identical to src.meta.homepage in all cases.

AndersonTorres · 2024-03-24T02:33:06Z

ok, but src.meta.repository does not currently exist.

Yes, and it is a chicken-egg problem.

lolbinarycat · 2024-03-24T18:43:08Z

can we just add the field in it's current state then come back and add src.meta.repository in a second PR?

AndersonTorres · 2024-03-25T03:17:37Z

Yes, but Can we just make the field a list, like in meta.license?

After all you did not answered the arguments about making it a list of URLs, even after still using a MIRROR of GFORTH in your example.

Ah! Another reason for keeping mirrors: SLAPPers and preservation of abandonware!

pkgs/stdenv/generic/check-meta.nix

AndersonTorres · 2024-03-29T14:32:52Z

pkgs/stdenv/generic/check-meta.nix

Hum, another suggestion:

Since you are grabbing src.meta.homepage regardless its existence (and dealing with the non-existence gracefully), please grab the yet-non-existent src.meta.repository too.

@Aleksanaa any objection? I would 👍 to listen.

If you want a different implementation, please open another PR yourself. The author's purpose is already very clear.

This is not a different implementation, just an add-on. Have you read the "too" in the end?

well, it's merged now, so you are free to open your own PR that builds on top of it.

I don't wanna lose my vacation days.

(You know what?...)
#300286

lolbinarycat · 2024-03-29T18:42:36Z

@a-n-n-a-l-e-e squashed!

ghost

built stdenv & tests on aarch64/x64 darwin

adisbladis · 2024-03-30T06:26:13Z

The implementation in this PR suffers from some performance issues.
Addressed in #300177.

To future nixpkgs mergers:
check-meta.nix is one of the hottest nixpkgs paths and any performance hit here is noticeable.
Please check the ofborg performance report before merging.

stdenv/check-meta: Fix performance regressions introduced in #294347

K900 · 2024-03-30T14:21:06Z

This broke eval for packages where src can fail to eval, which is pretty much every package with binary-only sources. Reverting in #300247, this will need to be fixed and relanded along with #300177.

Revert #294347 (and #300177)

ghost · 2024-03-30T14:26:27Z

The implementation in this PR suffers from some performance issues. Addressed in #300177.

To future nixpkgs mergers: check-meta.nix is one of the hottest nixpkgs paths and any performance hit here is noticeable. Please check the ofborg performance report before merging.

looked at the performance and it was less than 0.2 % increase in cpu time. however, other eval runs reported different increases with the same change which seems that the perf result for the change is lost in the noise. additionally, it doesn't appear that #300177 has any effect when compared to no-op changes like r-ryantm updates.

ghost · 2024-03-30T14:26:43Z

This broke eval for packages where src can fail to eval, which is pretty much every package with binary-only sources. Reverting in #300247, this will need to be fixed and relanded along with #300177.

blurg. thanks for reverting.

ghost · 2024-03-30T15:18:08Z

This broke eval for packages where src can fail to eval, which is pretty much every package with binary-only sources. Reverting in #300247, this will need to be fixed and relanded along with #300177.

blurg. thanks for reverting.

https://hydra.nixos.org/build/254689522/nixlog/1/tail
nix-instantiate -A brscan4 --show-trace --argstr system aarch64-linux

lolbinarycat · 2024-03-30T16:47:36Z

This broke eval for packages where src can fail to eval, which is pretty much every package with binary-only sources.

shouldn't a binary-only package like that just lack the src attribute altogether? or it would just point to a binary tarball?

the code should check if src exists before trying to access it.

also, a specific example would be appreciated so i can replicate the issue.

lolbinarycat · 2024-03-30T17:00:28Z

the brscan4 failure seems to be exclusive to aarch64, since nix eval .#brscan4.meta works fine on my end.

K900 · 2024-03-30T17:14:01Z

It is specific to platforms where it's not supported, because that's where it throws, yes.

lolbinarycat · 2024-03-30T18:49:04Z

what do people think about just wrapping this in tryEval or deepSeq so this doesn't happen?

lolbinarycat · 2024-03-30T18:53:41Z

hmm problem is tryEval doesn't catch index errors (and idk why i thought deepseq would do anything)

lolbinarycat · 2024-03-30T19:02:07Z

alternatively, we could make it default to nil or an empty list, and remove the optional and //, that way evaluating other meta attributes doesn't evaluate repository.

AndersonTorres · 2024-03-30T19:45:49Z

Some useful ideas on catching throws can be found on this nice code from @matejc (in memerian from Nixpkgs):

https://blog.matejc.com/blogs/myblog/generate-package-info

lolbinarycat · 2024-03-30T19:57:29Z

tryEval doesn't catch the kind of error that is causing eval to fail. try builtins.tryEval ({}.a) in the repl to see.

i opted instead to just try to avoid the error.

AndersonTorres · 2024-03-30T20:02:52Z

builtins.hasAttr doesn't work?

lolbinarycat · 2024-03-30T20:57:59Z

we already use the ? operator to check if src has the relevant fields, but the problem is, just evaluating src enough to check if it has an attribute is sometimes enough to cause an unrecoverable error. the only other option would be making sure src evaluates on every package, even on unsupported platforms.

lolbinarycat · 2024-03-30T21:01:41Z

these packages may as well be setting src = if builtins.currentSystem == "aarch64-linux" then abort "someerror" else realsrc

AndersonTorres · 2024-03-30T22:37:45Z

Aborts, contrary to throws, are not catch-able - this needs another thing...

lolbinarycat · 2024-04-01T17:26:33Z

pkgs/stdenv/generic/check-meta.nix

+          then
+            [ attrs.src ]
+          else
+            lib.filter (src: src ? meta.homepage) attrs.srcs;


i just noticed something while testing a rewrite: this filter statement needs to be moved outside the if, because otherwise the case of attrs.src not having a meta attribute is not handled.

fixing this in the newest version

lolbinarycat requested review from Ericson2314 and piegamesde as code owners March 8, 2024 20:17

github-actions bot added 8.has: documentation This PR adds or changes documentation 6.topic: stdenv Standard environment labels Mar 8, 2024

lolbinarycat marked this pull request as draft March 8, 2024 21:05

ofborg bot added 8.has: clean-up This PR removes packages or removes other cruft 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. labels Mar 8, 2024

lolbinarycat marked this pull request as ready for review March 9, 2024 00:28

This was referenced Mar 11, 2024

add field to package info for link to upstream repository. NixOS/nixos-search#741

Open

stdenv: make meta.position overridable #295973

Closed

Mindavi added the 9.needs: community feedback This needs feedback from more community members. label Mar 14, 2024

AndersonTorres suggested changes Mar 15, 2024

View reviewed changes

mweinelt reviewed Mar 19, 2024

View reviewed changes

ghost reviewed Mar 29, 2024

View reviewed changes

pkgs/stdenv/generic/check-meta.nix Outdated Show resolved Hide resolved

AndersonTorres reviewed Mar 29, 2024

View reviewed changes

stdenv: add meta.repository field

7e1443a

lolbinarycat force-pushed the meta.repository branch from 00f8f07 to 7e1443a Compare March 29, 2024 18:41

ghost approved these changes Mar 29, 2024

View reviewed changes

ghost merged commit 2809c84 into NixOS:master Mar 29, 2024

adisbladis mentioned this pull request Mar 30, 2024

stdenv/check-meta: Fix performance regressions introduced in #294347 #300177

Merged

13 tasks

adisbladis added a commit that referenced this pull request Mar 30, 2024

Merge pull request #300177 from adisbladis/meta-repository-perf-fixups

bff4c55

stdenv/check-meta: Fix performance regressions introduced in #294347

K900 added a commit that referenced this pull request Mar 30, 2024

Merge pull request #300247 from K900/revert-294347-etc

42b1ad9

Revert #294347 (and #300177)

AndersonTorres mentioned this pull request Mar 30, 2024

stdenv: add meta.repository attribute to fetchers #300286

Closed

13 tasks

lolbinarycat commented Apr 1, 2024

View reviewed changes

AndersonTorres mentioned this pull request Jul 8, 2024

scripts/update: Set nix-update-script by default #325074

Closed

13 tasks

This pull request was closed.

-HTTP-browsable source tree of the package. Automatically set if the package uses a `fetchFrom*` fetcher for its `src`. Example: `https://github.com/forthy42/gforth`
+Source repository of the package.
+Examples:
+- `https://git.savannah.gnu.org/git/gforth.git`
+- `https://github.com/NixOS/nixops`
+- `https://nest.pijul.com/pijul/pijul`

Uh oh!

Conversation

lolbinarycat commented Mar 8, 2024

Description of changes

Things done

Uh oh!

lolbinarycat commented Mar 14, 2024

Uh oh!

AndersonTorres Mar 15, 2024 • 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!

AndersonTorres Mar 19, 2024 • 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!

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!

AndersonTorres Mar 19, 2024 • 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!

AndersonTorres Mar 15, 2024 • 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!

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!

mweinelt left a comment

Choose a reason for hiding this comment

Uh oh!

piegamesde commented Mar 19, 2024

Uh oh!

eclairevoyant commented Mar 19, 2024

Uh oh!

lolbinarycat commented Mar 19, 2024

Uh oh!

lolbinarycat commented Mar 19, 2024

Uh oh!

AndersonTorres commented Mar 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lolbinarycat commented Mar 20, 2024

Uh oh!

AndersonTorres commented Mar 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lolbinarycat commented Mar 22, 2024

AndersonTorres Mar 15, 2024 •

edited

Loading

AndersonTorres Mar 19, 2024 •

edited

Loading

AndersonTorres Mar 19, 2024 •

edited

Loading

AndersonTorres Mar 15, 2024 •

edited

Loading

AndersonTorres commented Mar 20, 2024 •

edited

Loading

AndersonTorres commented Mar 22, 2024 •

edited

Loading

AndersonTorres commented Mar 24, 2024 •

edited

Loading

AndersonTorres commented Mar 25, 2024 •

edited

Loading

AndersonTorres Mar 29, 2024 •

edited

Loading

AndersonTorres Mar 29, 2024 •

edited

Loading