Arch Linux User Repository

Tried to install this today, but it won't compile. I'm getting a git-lfs error:

$ git-lfs smudge doc/user-manual/docs/assets/initial-01.png Error downloading object: doc/user-manual/docs/assets/initial-01.png (229c2ba): Smudge error: Error downloading doc/user-manual/docs/assets/initial-01.png (229c2ba1a77a3d595f36f8c1a1f96f6e9f2ed8112595812aee97366d38447a94): error transferring "229c2ba1a77a3d595f36f8c1a1f96f6e9f2ed8112595812aee97366d38447a94": [0] remote missing object 229c2ba1a77a3d595f36f8c1a1f96f6e9f2ed8112595812aee97366d38447a94

Hello mhoeher,
thank you for intention to adjust the deps :)
Regarding the empty variables: This is one way to use it, yes. :D But on the contrary it makes it easier for anybody who looks at the PKGBUILD to see what is used in the PKGBUILD. Probably therefore the guideline to remove unused variables :)
Reading the response regarding the submodules.. I'm not sure if we are on the same page or if I'm misunderstood something.
Just to make it (hopefully) clear: My intention wasn't to suggest to add every dep as a separate package to the AUR (although this is generally preferred ;D ). The suggested change was to push the submodules as actively downloaded sources instead of "silently" done by git. Which allows just updating the existing sources instead of redownloading everything after a new version is released and possible reuse from other PKGBUILDs if they're using the same submodule/source (again. Not in the context of a separate package :D). The checkout itself is still done by git which the context of .gitmodules.
But that change would just be a nice addition, not a must have. And sometimes it is outright impossible without tinkering with the make files in use. So do what you see best in that case :)

Hi TrialnError,

about cmake and ninja: You are right, both are build time dependencies. I'll adjust the PKGBUILD accordingly.

I can also remove the empty variables - I basically just kept them as a reference (I'm not a daily user of pacman/pkgbuild and hence having them "in sight" helps me in this case).

As for the submodules: I actually am quite happy with the way the current setup is. As I need to develop and maintain the app itself plus builds for several target platforms and configurations, I want to keep effort as low as possible. For built-in, statically linked dependencies as the ones pulled in via the submodules, using them allows me to have a single source of truth for the used versions of all involved repositories (regardless of the target platform/package format) I build for.

Having to list these dependencies once more in the PKGBUILD will very likely lead to broken packages down the line, so I'd rather avoid this ;-)

Are cmake and ninja really runtime dependencies?
I would assume those are only makedepends

Edit: Additional remark. Empty variables should be removed from a PKGBUILD and submodule handling could be adjusted

I just installed this via "yay -S opentodolist" and when I try to launch it using "OpenTodoList" I get the following error:

OpenTodoList: error while loading shared libraries: libqlmdb-qt6.so.1.2.1: cannot open shared object file: No such file or directory

Googling has not helped. Any ideas or is there something I maybe did wrong with my install command? Any help is appreciated!!

@wxg4net This code is "legacy". Some time back, the app used to build some dependencies "in source" instead of using the system wide available ones. This introduced some conflicts which prevented OpenTodoList and those affected dependencies being installed as package side-by-side. Hence, these commands were necessary to remove those files and make sure OpenTodoList doesn't introduce any conflicts.

In theory, these two lines could be removed (although they should do no harm, as the app is build as a single, self-contained executable with no library and even if there'd be a library, the APIs are currently not meant to be used by other consumers, so including header files also wouldn't make no sense).

Hope that answers your question ;-)

Why were the dependencies removed? [code] rm -rf \ $pkgdir/usr/include/ \ $pkgdir/usr/lib/ [/code]

That failure is rather due to the build environment used. I just retriggered a build on the CI server, which uses plain Arch Linux within a Docker container: https://gitlab.com/rpdev/opentodolist/-/jobs/3031808837

From the output of the log you linked, it seems some other container system (maybe systemd-nspawn?) is used. I think that within that kind of container, there's some issue. Because the build itself runs - some of the unit tests fail. Interestingly, the failing tests are the ones that use the cache - which uses LMDB to cache the items for fast access.

Build fails in clean chroot: log