Oof, the reviewer used an AUR helper that hid the post-install instructions among a deluge of messages! Ze had a point that I should have those instructions in the reviewer-only README too, I’ll admit. I’ve spent the last thirty minutes doing that.
⁂

No, that is not what I did within the logged time. A very helpful user commented on the AUR page that I had an issue stemming from the redis→valkey migration last year. I was adding us to the redis user group while depending on valkey!
Remembering my sympathy for the redis founder’s account of the events, I decided to fix this by supporting both, by adding to both the redis and valkey groups and depending on “redis”, which valkey also provides.
(What does that mean? Arch’s pacman has a nifty feature—provides—so that valkey can label itself as providing all the features of the redis package, which it does. Well, almost, minus the user-group name change, anyways.)
⁂

The reviewer also exposed a problem in the immich-admin script when ze mistakely tried to launch immich with it. Firstly, I neglected to mention that the script probably shouldn’t be used, as the systemd service wraps around it—a service I didn’t mention either. 🥀. Secondly, it now fails when not called from its working directory. I’ve fixed this by replacing the symlink with a short script that first cd-s to the correct directory, and of course adding that to the README.
Finally, I’ve updated the nginx config to the proper format (with an events {} section) and dropped migration instructions for too-old versions, as promised in the document containing migration instructions. Past 9 months mean you get sent off from the womb into the wild before you are replaced with our best instructions yet we are so proud to present you with at this year’s worldwide instruction conferen

A yay for interchangeable parts. That’s right, use yay or paru instead. Interchange those blasted bloasted TUIs. Start a revolution. /hj

Very inefficient work today again, partly because it turned out something I did last time didn’t commit. Another 20 minutes of interface things later, I somehow still feel very powerful. JetBrains IDEs are magic.
Since last time, we’ve got two new candidate maintainers popping in to review changes (using suspiciously LLM-sounding language, still …), and thus it’s natural that I increase my work by two as well. I followed up on two more pull requests.
⁂

The first one was somewhat simple. There’s a zsh script I put into the root of the project to detect changes in the tests against real-life sample code, and it turns out the trap I added to clean up temp files after early termination forgot to terminate the code. I wasted unlogged time shell-reading the zsh manual, which advertised an extremely outdated and incomplete online version, until I realized there was in fact a current and complete online manual. 🥀
In summary, zsh trap functions replace the single slot of the function to execute upon the kill signal. That’s very elegant, actually. I initially added the trap code upon suggestion from Coderabbit AI pull-request review and this devious devilous leporine tried to make it so we could never kill the machines. I’m scared. /j
⁂

The second one actually took quite a bit of thought. cpplint has a feature to warn on C-style casts to suggest more specific C++ casts instead. The PR was to make it stop detecting function pointers that take a pointer argument as casts if they happened to be marked noexcept. My original solution added an exception to noexcepts, which a candidate maintainer reviewer found was overly broad and suppressing casts of the bool value of the noexcept operator. Which, though niche, actually does seem plausible.
I drew up two different solutions, and decided to ask the JetBrains powered LLM-with-no-name which one was better. It correctly identified that the optional group could simply not be matched and is probably less optimized than the identical lookbehind, but then kept insisting function p. So I put it to death.
I proclaimed my own lookbehind creation, for only man can make divine. After a hiccup involving my misunderstanding of the difference between lookbehinds and lookaheads (Dear Past Me: duh), I settled for detecting an unspaced closing parenthesis because non–function pointer cases of such syntax would surely be formatted with a space by sane minds. coderabbit AI, which notably lacks a mind, agreed.

Even if it’s all machine, the project (tracker) finally seems alive.

WELCOME TO THE EXPERIMENT

we will now cheese stardance’s algorithm into giving me tons of views
and i will explain how
jump to the bottom to skip the technical stuff

how stardance’s algorithm shows things:

so it checks for actions in the last 7 days and here are the most
important ones by order:

• likes
• reposts
• views
• project followers
• comments
  BUT stardance also recommends content based on WHO liked followed the
  project etc and thats the key

instructions

i need you to leave a comment just with your project and if its cool i
will promote it here
then i need you to like repost and follow the project thats it

special people

these people should be the key to everything here they all are from one
specific interest and should make me pop up to everyone thats the same
and that intrest is: i dont know, i will try to tag all the people that i
think the project they work on is very universal

for the special people

its very important each of you do the instructions thats why i tagged
you
we will start with the person i stole this idea from and all the people
he tagged:
@jam06452
@vejas
@kingvon
@Keyboard1000n17
@SeradedStripes
@Rupnil
and others
@Lightfury
@PAPER_01
@sol4r_on_hackclub
@tjingi_
@water

also

lets add funny pictures for engagement and a cat + dog

Wow, it’s been a long time since I’ve worked on this. I had to spend a lot of time re-learning my PyCharm workflows. I had to solve some interesting font issues with my IDEs and relearn PyCharm’s great Git interface. (Seriously, why is the push button not in the UI if you don’t have a commit to commit?)

I got a tip from another candidate maintainer that my previous refactoring broke support for Pytest 8, so now we require Pytest 9.
Then it turned out PyCharm failed to detect coverage because uv couldn’t resolve dependencies because Pytest 9 dropped support for Python 3.9, which we listed as supported, so now we require Python 3.10.
I am … not sure how to feel, as Pytest isn’t required to run the package! I’m probably going to write union types as X | Y and add some case statements to justify this bump.

We might finally get a new maintainer to actually review my code! I fear that he’s using AI to write sentences, though… I really hope his code isn’t AI.
At least it seems that it isn’t, because he’s overcomplicating things. He correctly pointed out that the form LLU instead of ULL is also often used as a literal suffix (that we would need to detect) and that the insensitivity should be an inline group instead of flag, but then came up with this monstrosity: (?i:(?:U(?:LL?)?|(?:LL?)U?)?). I confirmed that the more orthodox (?i:U|UL|ULL|L|LL|LU|LLU) was faster (and readable!), that (?i) is a real thing (wow! thanks pythoma), ran tests, and committed the changes straight from GitHub after spending way too much time figuring out how the PR tab in PyCharm worked. An overcomplication to end an exploration of overcomplications.

I swear I saw “immich-core-plugin”. Turns out it was corePlugin→immich-plugin-core. Oops.

Edit: The last reviewer ignored the link to the README and said there was not README present in the source code link. Unfortunately AUR’s nature makes it bad for me to have a README in the branch where the source code is, so now the source code is under the master branch.

so, one/two weeks/worth in one devlog, come at me.

usually to accommodate a new upstream update, all you need is to put in the checksum for the new tarball download. but this time RapidOCR decided to finally replace their deprecated setup.py building with PEP 517 (a.k.a. normal Python packaging).
they also used to rely on the user downloading a zip file of the models for the bundled configuration from the artifacts for v1.1.0—no way to tell when you’d need to redownload that! it seems upstream relied on the user only needing to download from PyPI, which to be fair is the vast majority of usecases—lucky for non-Arch-ers, not lucky for me.
⁂

so figuring out the commands to replace python setup.py build with was the easy part: it’s called “standards-based packaging” because the command is python -m build --wheel --no-isolation no matter what exactly the pyproject.toml does. one small problem: the build needs a version, which RapidOCR provides dynamically by reading the latest tag from git. as you may realize, git information is not included in the tarball downloads typically used for such large repos, including in this package. thankfully this was even easier to patch out than setup.py’s behavior to fetch the version from PyPI (what)
⁂

next was the new way to download models. apparently all it took for the change was someone to complain that the process was “opaque” (not the word I’d use). it’s true that it was difficult to verify… but at least it was easier to wrap your head around than its replacement: a 133-line Python script!
i tried to follow its code around but eventually my feeble line decided its takings were excessively HIGH (ooh the G in the font is cool). so i exercized the reverse-engineer’s first approach: run it and see what it does. it downloaded three models and from my reading of the code, it seemed to reference a default_models.yaml. sure enough, all the download links were in there.
thus the obvious approach was to also download these links and update them every release. and it worked! after the minor hiccup of needing a MANIFEST.in to tell python -m installer to also ship the model files in the wheel we would install.
⁂

it’s through this yaml-reading that I discovered how RapidOCR in fact supported a ton of different models. there were nearly 300 options mentioned by default_models.yaml alone! ordinarily python-rapidocr would be able to search this directory of models and download them, but on Arch it’s installed into a system directory that it cannot modify. same for the config file. so I thought I could simply get at least the configuration part to work by symlinking it from /etc (and thus improve the discoverability of this feature).
it turned out this would break upgrading the package, and only on Arch would it break upgrading the package. i first heard this “attempting to write {config file} outside the target directory” bug in a vague comment raised by another AUR user who used Claude to give a completely incorrect blathering on how to fix it, which is exactly why I somehow decided to run Claude myself.
I wouldn’t have been able to discover the issue’s location by myself… as the bug was in fact within python -m installer! the 1.0.0 release used Path.resolve() to validate paths. if said path actually did exist on the system as a symlink, resolve() would output the ultimate target of that symlink instead of only eliminating ./s and ../s. and thus python -m installer followed the symlink to /etc/ which was decidedly outside /usr/.
the solution is to force people to build the 1.0.1 release (which accidentally fixed this bug by optimizing the resolve() step) because Arch for some reason hasn’t yet shipped this update from May… because though its PMs are all hella chill and nice, the sole maintainer is kinda on vacation
vote me for package maintainer

at first downloads were failing because Steam was downloading shader cache updates for Train Sim World, dangit.

obviously it turned out I had more to do. i forgot to adapt all of the changed paths: cli/→packages/cli/, plugins/→packages/plugin-core/, and corePlugin→plugins/immich-core-plugin (ooh they released plugins!). i also discovered that the build was in fact not reproducible just by adding build ID as we do timestamp the geodata, so let’s incorporate that. now i have to deal with the updates to mise configuration

first step is obvious: check the list of changes to server/Dockerfile. that specifies the recipe to create the Docker image—essentially packaging instructions that’ve already been written for us. it wasn’t much, thankfully (unlike the RapidOCR changes…): they separated out an additional plugin SDK we’d need to build and now explicitly build the dependent SDKs first.
the migration to pnpm 11 also meant --frozen-lockfile needs to be passed to the install command, so i took this opportunity to put such relevant flags after the subcommand portion of the command as well. finally let’s clarify the pkgdesc cuz why not